On Tue, Oct 02, 2001 at 12:43:43PM +0200, martin f krafft wrote:
> also sprach Daniel Stone (on Tue, 02 Oct 2001 08:10:38PM +1000):
> > I think that a symlink from /var to /home is bad. Maybe if we stored it
> > under /home/www-data or such.
>
> that's one possibility, although i am more in favor of uniting sites
> into single directory hierarchies. what's the big point of having
> documents in /var/www and below, but cgi's in /usr/lib/apache/cgi-bin?
> and manuals in /usr/share..., and logs in /var/log/apache?
Single directory would be nice, but I'm willing to bet that FHS has
dictated these braindead locations.
> i understand, there is the FHS, but a virtual site is a virtual site,
> in fact, any website is it's own site and doesn't really have anything
> to do with the host server except for a small number of cases.
>
> i think that /home/www-data or /home/apache is a reasonable idea, but
> somehow you need to fuse allowing users to edit their own pages, and
> protecting the apache installation against fuckups - because a single
> user who moves the directory corresponding to the webpage will make
> apache fail to start the next time.
IMHO, /home/apache is out, because you then run into trouble adding a
user called "apache". If it's going to be in /home (and I'm still gunning
for /var/www, although slightly different, see below), it must be
/home/www-data. Anything else would impede creation of users.
> instead, i propose the following: any apache configuration only serves
> virtual sites, where the primary site (the actual server site) is the
> first, which means the default if no Host HTTP Request Header is
> transmitted. virtual hosts relying on Host headers bind to 0.0.0.0:80
> only, IP virtuals bind to that IP.
Yeah, this is what I suggested. If I had just worded it normally, as
opposed to somewhat of a full-on policy statement, this would've been
more clear. Sorry.
(I'm pretty clear on how apache(2) handles virtual hosts, etc, BTW).
> for every virtual site defined in apache's config (which i am
> currently reworking), there is one equinomial[1] directory under
> /home/apache/sites (chmod 2711, chown root.staff). e.g.:
> /home/apache/sites/pantsfullofunix.net and
> /home/apache/sites/debianplanet.org. permissions are then set
> according to who is administering the site, although i propose having
> an equinomial group for every site anyway, and 2775 permissions
> recursively . now, you can symlink out of a home directory, i.e. from
> ~madduck/web/pantsfullofunix.net to
> /home/apache/sites/pantsfullofunix.net.
Sounds pretty good to me. I would, however, have the setup as follows:
/var/www - container. anything here should be moved to default/htdocs
/var/www/default - symlink to the default vhost
/var/www/site.name/htdocs - web root for site.name (e.g.
debianplanet.org)
/var/www/site.name/logs - logs for site.name
/var/www/site.name/cgi-bin - cgi stuff for site.name
No disagreements with the permissions, and /var/www/site.name can be a
symlink if you want to (I currently have this exact setup running on a
few production servers myself).
> this pretty much ensures that when /home is up, apache will serve
> whatever is in these directories.
>
> furthermore, one could create
> /home/apache/common/{img,scripts,cgi-bin,whatever}, which could be
> (script-)aliased as /cgi-pub, scripts-pub, /img-pub, /whatever-pub
> server wide, and could contain common CGIs like counters or guestbooks
> and whatever kind of junk the people want.
This is a very good idea - /var/www/common, tho?
> in addition, every /home/apache/sites/* directory has it's own
> cgi-bin, iff the owner so desires and the hostmaster allows it. this
> gives separate custom cgi control over each site while not limiting
> the cgi-pub access. very much the same approach can be taken with
> scripts, and even PHP capabilities and other stuff. all i am saying
> is: <VirtualHost> is your friend!!! and you can use it the same way
> with no negative consequences if you are only serving one site.
Yeah, that's what I was proposing with
/usr/lib/cgi-bin/(default|site.name).
Virtual hosts are good. This should also allow us to nicely skirt around
FHS; AFAIK FHS makes no provision for virtual hosts. If we reintrepret
apache to having only virtual hosts, with one default host, then we can
say "aha, stuff FHS, we have virtual hosts. thpthpthpthpt".
> lastly, i propose (even though i have not been able to implement
> this), to give every single site directory a 0750 root.site
> subdirectory "log", in which the error and access logs for that site
> are placed. this much works for my server, but what i also want is one
> centralized logfile for all in /var/log/apache. this allows users
> access to their logs, it keeps /var/log/apache and files clean, and
> it's a perfect way to handle multiple sites, especially because
> apache's cron.daily knows how to rotate any logfile no matter where it
> is, and because such a convention allows script access to logs via
> /home/apache/sites/*/log. here i propose that the directory is owned
> by root and grouped to the site group so that the webmasters have
> read-access to their logs, but noone else, which is all that you ever
> need.
Yeah, I agree. I've implemented this, but with a slight change (I'm
running on *gack* RedHat in production, hope to change that soon):
/usr/local/apache/logs/site.name/(access|error).log: admin's copy of
site.name's logs, for posterity, stats, etc
/usr/local/apache/sites/site.name/logs/(access|error).log: user's copy
This also allows admins and users to take a different approach with log
rotation, and it also prevents shifty users doing anything dodgy :)
> now, with this setup, which i have implemented on two productive
> servers so far, administration is bloody simple, and it makes sense! a
> virtual website does not have to melt in with the server FHS, it
> *could* have it's own FHS instantiation, but there is no need or point
> to log to /var/log (other than collectively), to serve from /var/www,
> or to execute CGIs from /usr/lib.
Yeah :)
> lastly, to help other debian packages (like webalizer and others) to
> switch to a new convention, /var/www could very well be a symlink to
> /home/apache/sites/`hostname`.mydomain.com
That's more or less what I proposed with /var/www/default - it would be
a symlink to the default vhost.
> [1] no, this isn't a word. but it should be. you get the idea...
It's a damn cool word. I second its introduction to the English
language.
> > I think that it should remain that way, but hey, this is my main server:
> > daniel@piro:~% ls -l /var
> > lrwxrwxrwx 1 root root 9 Jul 4 09:48 /var ->
> > /home/var
>
> uhm, daniel, are you, uhm, okay?
> WHY?
daniel@piro:~% df -m
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/ide/host0/bus1/target0/lun0/part1
2496 1391 1105 56% /
/dev/ide/host0/bus0/target0/lun0/part1
191 67 124 35% /boot
/dev/ide/host0/bus1/target0/lun0/part3
4282 3463 818 81% /home
/dev/scsi/host0/bus0/target1/lun0/part1
2043 1243 800 61% /usr/local
/dev/ide/host0/bus0/target0/lun0/part2
1354 1 1353 1% /stable
Hmm, I've got a big, fat /stable sitting unused. I really should
use that up someday - when I made /var a symlink to /home/var, I
had a /stable chroot full of potato stuff.
:) d
(PS: Come on IRC. DanielS, OPN, #debian-devel).
--
Daniel Stone <daniel@sfarc.net>
<erno> hm. I've lost a machine.. literally _lost_. it responds to ping, it
works completely, I just can't figure out where in my apartment it is.
Attachment:
pgptSafdpacpp.pgp
Description: PGP signature