It was thus said that the Great David Blomstrom once stated: > > Oops, I think I goofed. I should have clarified that > these are for my LOCAL sites. All my online sites are > insisde a folder named public_html. > > Do your comments still stand - is it a good idea to > put my websites inside folders named public_html even > on my computer? It's neither here nor there. "public_html" came about as a means for people with accounts on a Unix system to put their homepages. Back when I was in college, with an account on the Computer Science and Engineering Unix system, all a user had to do was create a "public_html" directory [1] in their home directory (in my case, my home directory was "/home/spc", so my website would served up from "/home/spc/public_html/"---for my friend Ken, his home directory was "/home/ken" and his homepage would be "/home/ken/public_html/") and was referenced via a URL like: http://www.cse.fau.edu/~spc/ So that's where the "public_html" portion comes from (and in Apache, one would do UserDir public_html <Directory /home/*/public_html> # stuff to limit what could be done # in the user's homepages </Directory> Now, on to your question---what directory you use really depends upon what you need done with the site. For the sites that I directly control, I have the following: /http/spc/sites/ This directory contains all the sites I own (or host for my friends). The "/http/" directory contains all web related data on the server, and the "spc/" directory beneath that is where my sites are stored (there are several different groups---this makes it easy to keep track of who owns what). Under "sites/" I have, for example: www.conman.org/ boston.conman.org/ bible.conman.org/ www.flummux.org/ dw.flummux.org/ www.hhgproject.org/ As you can see, some of my domains have (what I later learned were called) sub-domains---I just treat them as seperate sites as far as Apache is concerned. Under each of these I typically have: htdocs/ cgi-bin/ Although I could have called both of these by other names---I could have used "html", "httpdocs", "web", "public_html" or heck, even "Fred" if I were so inclined. Yes, the structure is a bit deep, but it allows me the ability to store all data associated with a site under its own directory, even if not all of it is directly served by Apache. For instance, under my boston.conman.org site, I have: htdocs/ # static pages for my blog cgi-bin/ # CGI scripts journal/ # where the templates and database (roughly) # for my blog is stored. This has all the information pertaining to my site "www.conman.org". "/http" is the location of *all* the webpages served up by the server. "spc" is where all *my* sites are stored (there are several groups here), Within the "sites/" directory, I have directories for each site I serve up, and inside htdocs/ # web pages cgi-bin/ # CGI scripts The reason I include the full name instead of just the domain name is because a few of my sites have sub-domains that have content---for instance within /http/spc/sites/boston.conman.org/ I have: htdocs/ # static pages for my blog cgi-bin/ # CGI scripts journal/ # data files for my blog, including templates and # entries notify/ # scripts used to notify people via email when # I make updates Now, if what you have works, by all means, continue using it. My method works for me (and I use this structure, more or less [2], across several servers and about 1,200 sites), it may not for you. -spc (There's more than one way to do it ... ) [1] If you are unsure what I mean by "directory", think "folder"---I personally find the Windows stuff a bit confusing and prefer Unix. [2] There are some groups where the structure is: /http/<group>/<domain>/logs # log files /http/<group>/<domain>/web # webpages /http/<group>/<domain>/web/cgi-bin/ # CGI scripts Similar to the structure I use, but just slightly different names and a slightly different layout. > Thanks. > > --- John Hicks <johnlist@xxxxxxxxxxxxxx> wrote: > > > David Blomstrom wrote: > > > This is how most of my virtual hosts are set up: > > > > > > <VirtualHost *:80> > > > ServerName geoworld > > > ServerAlias geoworld *.geoworld > > > DocumentRoot c:\sites\geoworld > > > </VirtualHost> > > > > > > However, I read somewhere that it's better to put > > your > > > sites inside a folder named public_html, then set > > up > > > your virtual host like this: > > > > > > <VirtualHost *:80> > > > ServerName geozoo > > > ServerAlias geozoo *.geozoo > > > DocumentRoot c:\sites\geozoo\public_html > > > </VirtualHost> > > > > > > Can anyone tell me if that's better and why? I've > > set > > > a couple sites up like that, and everything seems > > to > > > work OK, but I don't want to go to the trouble of > > > changing all my sites if there's no real > > advantage. > > > > The second alternative is probably better for most > > installations. > > > > Remember that any file that lies under the document > > root is potentially > > visible to all the world. Any files that will never > > be served via Apache > > should not be under the document root. Having that > > extra layer of > > directories gives you more flexibility in organizing > > and controlling > > your files. > > > > Of course there's no reason why the document root > > needs to be called > > 'public_html' in particular. > > > > ____________________________________________________ > Start your day with Yahoo! - make it your home page > http://www.yahoo.com/r/hs > > > --------------------------------------------------------------------- > The official User-To-User support forum of the Apache HTTP Server Project. > See <URL:http://httpd.apache.org/userslist.html> for more info. > To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx > " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|