asg03.htm

apache技术手册

<UL>

<UL>

<P>bin

</UL></UL>

<UL>

<UL>

<P>etc

</UL></UL>

<UL>

<UL>

<P>lib

</UL></UL>

<UL>

<UL>

<P>man

</UL></UL>

<UL>

<UL>

<P>named

</UL></UL>

<UL>

<UL>

<P>ftp

</UL></UL>

<UL>

<UL>

<P>etc

</UL></UL>

<UL>

<UL>

<P>Minerva

<BR>

</UL></UL>

<P>Put all binaries that you add in /usr/local/bin. This makes it easy for users to find and easy for you to maintain. If you upgrade a program to a new version, which is also included in your operating system release, keep the original in its place. Set /usr/local/bin in your path, ahead of the other system directories. You can do this by adding an entry to your PATH environment variable. Where this is done depends on the shell you are using. Typically, this will be in the .profile or .cshrc files in your home directory. Note that these files start with a period, so they normally will be hidden from view.

<BR>

<P>In the .profile file, the new path addition will look like this:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">PATH=/usr/local/bin:/usr/ucb:/bin/...</FONT></PRE>

<P>Note that the paths to the directories that search for executables are separated by colons. Directories listed first are searched first.

<BR>

<P>If you are using the csh (c shell), you will want to put an entry into your .cshrc file. This is the same as your .profile entry, but the csh syntax for defining the environment variables is a little different:

<BR>

<BR>

<PRE>

<FONT COLOR="#000080">set PATH=(/usr/local/bin /usr/ucb /bin ...)</FONT></PRE>

<P>Under the csh, multiple paths are separated by spaces and grouped together with parentheses. 

<BR>

<P>Other directories, such as /usr/local/etc, contain the Web server tree. Storing it in its default place removes one source of potential problems. By keeping the default installation location, future upgrades will find the files in their standard locations. Moving default installation locations without having a really good reason for the change is asking for trouble. Future upgrades won't work properly because they will not be able to find supporting files, and you will be required to spend time hunting for the problem.

<BR>

<P>Having a written organizational policy will help cast in stone the structure of your site. If everyone decides on their own where to place files, you'll end up with a mess. Software will be installed and configured wherever someone felt that the files should go. Perhaps, they were installed on top of your system's distribution&#151;a practice that often spells disaster if later you find out there's a bug, and the version that came with your operating system worked better!

<BR>

<P>An organizational scheme permits you to easily back up software you have added. If you need to install an additional machine and want to upgrade some of your customizations, the process is simplified and becomes really easy. All you need to do is copy the /usr/local tree, and everything is there. From that point, you can either opt to remove software you won't need or just keep it. The UNIX rdist command can be very helpful in maintaining multiple identically configured systems in sync.

<BR>

<P>Should you ever need a backup, a quick tar -cf /tmp/usrlocal.tar /usr/local will take care of the problem. You don't need to differentiate or select from various places that may contain files you added. It's all kept together.

<BR>

<BR>

<A NAME="E69E19"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>File Packages: Organizing HTML and Resources</B></FONT></CENTER></H4>

<BR>

<P>The concept of <I>page wrapper</I> was developed at accessLINK. A page wrapper is no more than a directory that keeps all relevant resources (images or additional HTML files) grouped together in a bundle. The concept is hierarchical, so ideally you would group a section of multiple page wrappers together into a section.

<BR>

<P>Grouping HTML files into a <I>page</I>.htmld directory is a good way of keeping tabs on files (we group root trees in a <I>sitename</I>.ws wrapper; ws stands for Web site). 

<BR>

<P>My experience has been that if I create a directory that contains all the necessary resources for an HTML document and group it all in a wrapper, it becomes easy for me to maintain that page. The system also enhances the recycling of disk space. If you are working on a HTML file and you remove a reference to an image that is stored in a different directory, it's likely to remain there. If it is near your HTML file, more than likely the file will be discarded, freeing disk space for other things.

<BR>

<P>This organizational scheme works best when several people are responsible for keeping a site running. When a document needs to be updated, the location of all the related resources are stored together and nicely packaged. The alternative is chaos. In a normal scenario where forty HTML files are stored at the same directory level along with associated resources (such as images or videos), it becomes impossible to determine what needs to be done. To figure out referenced images in a file, you have to look at the HTML code and search for the tags for the image filename. With the wrapper, much of the chaos is removed and the structure is simplified. By simple inspection of the directory's contents, you can find what you are looking for.

<BR>

<P>It's no miracle that this basic structure also happens to follow the physical structure of the site. The directory structure mirrors the navigational structure, providing another level of reinforcing the way the site is organized for people who update and manage this site. Just by navigating it, you have an understanding of the physical layout of a site.

<BR>

<P><B> <A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/Apachu/03asg01.gif  \n\nThis file was not retrieved by Teleport Pro, because it was redirected to an invalid location.  You should report this problem to the site\'s webmaster.  \n\nDo you want to open it from the server?'))window.location='http://docs.rinet.ru:8080/Apachu/03asg01.gif'" tppabs="http://docs.rinet.ru:8080/Apachu/03asg01.gif">Figure 3.1. The Web site directory hierarchy. All </B><B>references are localized. Global items are placed at the top. Local </B><B>items only used on a particular page remain close to their resources. The </B><B>window capture shows the directory tree from </B><B>htdocs</B><B> downward and </B><B>describes the file organization scheme.</A></B>

<BR>

<P><A NAME="I2"></A>Figure 3.1 is a visual representation of the system. The htdocs tree contains a series of wrappers with a ws extension, which stands for Web site. Each of the sites listed lives in one of accessLINK's servers. One of them is for SmartSoft, Inc., a software development company. All files related to the SmartSoft site are stored inside the smartSoft.ws wrapper. Each page is represented by an <I>htmld </I>wrapper. Wrappers nest according to the logical navigational structure of the site. On the end node you can appreciate the contents of a simple page. The stayInTouch.htmld wrapper holds a main HTML file (index.html) and a sibling file for feature information (featureList.html). Images and other supporting resources are found next to the files that reference them.

<BR>

<BR>

<A NAME="E69E20"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Additional Benefits of the Wrapper Approach</B></FONT></CENTER></H4>

<BR>

<P>This approach works in several levels. It allows you to name graphics and resources generically, such as header.jpeg. However, the generic name works fine because more than likely there is only one header file, not a hundred. If you were using one general graphics directory, each graphic would need a unique name or some other cryptic-naming scheme. By localizing resources near their point of use, each name is descriptive, clear, and readable. This also removes a lot of the creativity involved in inventing filenames. The context of the file provides information about what it is, so you don't need to peek into the file to figure out what it contains.

<BR>

<P>This approach also allows you to create HTML template files. If you were going to add a product, it becomes a matter of duplicating one of the existing wrappers, updating new header.jpeg graphics and the new text. The rest remains the same. This makes you more efficient when you have to add or build a Web site because you can always leverage on previously done work.

<BR>

<P>From a maintenance point of view, the <I>htmld</I> approach helps to keep directories smaller and clutter free. From a security standpoint, it also lets you clearly see suspicious files that you didn't put there. If you know where and what your files are, you'll have a better chance of noticing if you've had a break-in or if someone put something in the wrong spot. If you just throw it all in together and have 30 or 40 files per directory, it becomes difficult to figure out what is going on, and it takes more careful reading. Later the site will have many stale HTML files or graphics that are no being longer used. Cleaning up at this point is time-consuming because you have to think about what each of the files contain. If you remove any haphazardly, more than likely you'll break something.

<BR>

<BR>

<A NAME="E69E21"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Filenaming Suggestions</B></FONT></CENTER></H4>

<BR>

<P>When you are creative with your filenames, it becomes more difficult to know what a file contains. What is header2.gif? I don't know because there's no context, and I doubt that the person who created such a file could remember either. If it's all packaged, then you know who's the client of that resource, and you can create a visual and organizational association; you know what things are.

<BR>

<P>I title everything <I>firstSecondThird</I>.<I>type</I>. The first word is in lowercase letters. Any word after has its first letter in uppercase. I don't use spaces, dashes, or any other character that is not a letter or a number. Periods are used to separate file extensions. This makes it easy for me to read and type filenames, and it removes the possibility of any nonalphanumeric characters from becoming part of a filename.

<BR>

<BR>

<A NAME="E69E22"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Web Site Documentation</B></FONT></CENTER></H4>

<BR>

<P>While you are building your site, you may want to clearly document the standards used for creating a site. For example, it is useful to document colors used on an image. Better yet, create template files that can be used for creating new graphics. In Adobe Photoshop, this is really easy. Add a layer and enter the size of the text and font face that you used for a graphic title. This will allow future titles to be consistent and will save you a lot of time in generating artwork. Pass this information to those that create artwork for your site. You'll be glad if you do.

<BR>

<BR>

<A NAME="E68E26"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Personal HTML Directories</B></FONT></CENTER></H3>

<BR>

<P>Many of your users will be interested in creating their own personal home pages. Apache provides support for this feature with their UserDir module. If you performed the installation instructions in Chapter two, &quot;Installing and Configuring an Apache Server,&quot; you'll recall that you disabled the UserDir functionality from your server. Requests for your users' home pages take the form of: http://host/~<I>user</I>, where <I>user</I> is the login name of the user.

<BR>

<P>On receiving a request for a user's home page, the default server configuration looks for the public_html directory inside of the user's home directory. I don't like this feature for security and convenience reasons.