|
Matt, Thank you very much for taking the time to lay this out for me. (vanity is wonderful, eh? ;) I'll study what you have, and will probably have questions later. Thanks again! Rick On Tue, 18 Jan 2005 17:39:01 -0500, Haas, Matt <Matt.Haas@xxxxxxxxxxx> wrote: > Rick, > > I do virtual servers so my layout may have additional depth to it that you > don't need (and it doesn't directly answer your question but may give you > some food for thought) but the folks up a Rochester pointed out that they > liked it when I did a UCD session at the end of 1998 (brief pause while I pat > myself on the back). > > I start out with a web directory at the root of the root file system. You > could call it something along the lines of webroot but the name is not that > important. > > Underneath that, I create a directory for each site. Again, name doesn't > matter but I make them match the host name less the common part of the name. > For example, if I have http://reallycoolsite.thomsonlearning.com, I'd have a > directory called reallycoolsite under webroot. > > Underneath each site directory, I create an images directory and directories > for log analysis reports and a few other tools we give each site owner. This > is typically as deep as I do directory structures but the people maintaining > the content typically create individual directories for style sheets, > javascripts, and any files included via SSI's. > > Net.Data macros go in their own directory under the main directory (webroot). > It's a bad idea to put the macros underneath the web root for each virtual > site since someone could get the web server to dump out your raw macro if you > forget to deny access to the directory. > > I also create a directory for things common to all sites (corporate logos and > stuff related to HTML versions of our invoices) and either create a global > mapping in the server or symbolic links as needed. > > Here's an example: > > The directory structure ends up being: > /websites > |-common_images > |-macros > |-reallycoolsite > | |-css > | |-images > | |-includes > | |-javascript > > Your httpd.conf would have this in it: > > <VirtualHost your.ip.address> > ServerName reallycoolsite.somethin.com > AlwaysDirectoryIndex On > DirectoryIndex index.html > DocumentRoot /websites/reallycoolsite > UseCanonicalName Off > HostNameLookups off > IndexOrderDefault Ascending Name CaseSense > <Directory /websites/reallycoolsite> > order allow,deny > allow from all > </Directory> > </VirtualHost> > > which enables serving of anything under /websites/reallycoolsite. > > I keep CGI programs in a library called CGIBIN. Here's the configuration I > use for them and it's at the global level: > ScriptAlias /cgibin /qsys.lib/cgibin.lib > <Directory /qsys.lib/cgibin.lib> > order allow,deny > allow from all > </Directory> > > Net.Data's also a CGI program but I want to refer to it as /db2www instead of > /cgibin/db2www.pgm so I add the following at the global level: > > ScriptAlias /db2www/ /qsys.lib/cgibin.lib/db2www.pgm/ > > The directory container I added above takes care of permissions. > > To get access to /websites/common_images, you can either add a global mapping: > > Alias /common_images /websites/common_images > <Directory /websites/common_images> > order allow,deny > allow from all > </Directory> > > or you can create a symbolic link: > > ADDLNK OBJ('/websites/common_images') > NEWLNK('/websites/reallycoolsite/common_images') LNKTYPE(*SYMBOLIC) > > and then add Options +FollowSymLinks to your httpd.conf. > > Finally, to turn on SSI's, add the following: > > Options +Includes (note: you can just add +Includes to your existing options > list) > AddOutputFilter INCLUDES .shtml > AddOutputFilter INCLUDES .htm > AddOutputFilter INCLUDES .html > AddOutputFilter INCLUDES .pgm > > This allows the server to parse both HTML pages and CGI programs (including > Net.Data since it's runtime is also a .pgm type object) for SSI tags. > > What this makes available is the following URL's: > > http://reallycoolsite.somethin.com > http://reallycoolsite.somethin.com/cgibin > http://reallycoolsite.somethin.com/common_images > http://reallycoolsite.somethin.com/css > http://reallycoolsite.somethin.com/db2www > http://reallycoolsite.somethin.com/images > http://reallycoolsite.somethin.com/includes > http://reallycoolsite.somethin.com/javascript > > When I need to refer to an image (or a CSS file, or anything else) from > either a CGI program or a Net.Data macro, I also use an absolute path > (/images/fred.jpg) so I don't have to worry about how many double dot's I > need to make stuff work. If you don't use common templates for the pages, > this isn't much of an issue but if you use the same templates at various > levels within the site, it's just about impossible to use relative links. > Also, it makes it easier for browser's to cache stuff which makes the page > load quicker for your customers and reduce load on your server. > > One situation I do have that's a slight twist on what you're doing is our B2B > online store is shared by a bunch of virtual sites. In order to make it > easier to track who's using the store in the log analysis reports, I've > created various alias' to give each site it's own virtual directory. > > Finally, I highly recommend that you take a look at the first few chapters of > the book "Professional Apache 2.0". These chapters are introductory and > covers a lot of this type of stuff. Besides that, the book is great for > understanding how to configure an Apache based HTTP server. > > Matt > > -----Original Message----- > From: rick baird [mailto:rick.baird@xxxxxxxxx] > Sent: Tuesday, January 18, 2005 4:22 PM > To: web400@xxxxxxxxxxxx > Subject: [WEB400] The proper way to set up your directory stucture for > webserving > > I'm having a brain seizure, and i'm looking for some direction on the > 'BEST' way of organizing web document directories. > > I'm on V5R3, using apache for static pages and some homespun CGI (the > hard way) programs. > > I want to begin using net.data and CGIDEV as well, and I'm having > difficulty deciding the proper way to set up my directory structure, > but before I do, I want to make sure I don't paint myself into a > corner by doing it wrong. > > How do you all organize your directories? by document type and > then application? or by application and document type. What about > images, static pages or net.data macros that could be used in several > different applications? > > Mostly, I'm concerned about my html (static and generated) will be > able to easily 'find' my images, other pages, other links, etc. > without having to specify full path's to those objects, and to easily > navigate between static pages, cgi and net.data links. > > for instance, can you think of anything functionally different between > the following: > > /live/common/html/... > /live/common/images/... > /live/common/netdatamacros/... > /live/application1/html/... > /live/application1/images/... > /live/application1/netdatamacros/... > /live/application2/html/... > /live/application2/images/... > /live/application2/netdatamacros/... > /test/application1/html/... > /test/application1/images/... > /test/application1/netdatamacros/... > /test/application2/html/... > /test/application2/images/... > /test/application2/netdatamacros/... > > and this:? > > /live/html/common/... > /live/html/application1/... > /live/html/application2/... > /live/netdatamacros/common/... > /live/netdatamacros/application1/... > /live/netdatamacros/application2/... > > etc. > > or some other way of organizing? > > thanks in advance, > > Rick > _______________________________________________ > This is the Web Enabling the AS400 / iSeries (WEB400) mailing list > To post a message email: WEB400@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/web400 > or email: WEB400-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/web400. > > _______________________________________________ > This is the Web Enabling the AS400 / iSeries (WEB400) mailing list > To post a message email: WEB400@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/web400 > or email: WEB400-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/web400. > >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.