httpd upgrade overwrote /srv/httpd directory with a symlink!
 

Part warning, part question.

I keep my web server content in /srv/httpd - I have previously asked Pat to consider this more proper location as a new default, but IIRC his opinion was that while /srv/httpd was technically better, /var/www 'aint broke so he wasn't fixing it.

Four days ago I patched up my server and with it upgraded httpd-2.2.17 to httpd-2.2.25. I have discovered to my abject horror that my web server directory was completely overwritten by the symlink back to /var/www (!!).

My warning is that if anyone else uses /srv/httpd or /srv/www for content, to duplicate that content before upgrading httpd.

My question is WHAT THE HELL?!?

Why should upgradepkg EVER be allowed to forcefully overwrite an existing directory with a symlink? Can anyone offer a suggestion of how this occurred so I can submit a patch to fix and stop it happening to anyone else?

I don't have a 14.1 install handy so I don't know if it is the same but in 14.0's install script there is this:
It seems it is already trying not to clobber anything.

Panic over :-D You're bob-on.

Because of the file dates I had assumed I created that backup ages ago. Now that I look more closely you're exactly right. It's all there. My bad :)

It's good that the doinst.sh moves existing directories out of the way rather than just blindly stomping on them but IMO it'd be much better for it not to clobber existing directories at all. I think I'd favour removing those symlink creations from the httpd.Slackbuild, and putting then in the doinst.sh wrapped in a much safer 'test ! -e' :

if [ ! -e srv/httpd ]; then ; ln -Tsf /var/www srv/httpd ; fi


I'm not entirely sure what would happen under the existing scheme if /srv/httpd was the mountpoint of a separate filesystem but I get the feeling that it might get ugly under the right circumstances (e.g. the mv fails and then the rm -rf in the doinst.sh wipes out the existing contents anyway)

It would be better to do the symlink the other way around.

Rational :-
http://www.pathname.com/fhs/pub/fhs-2.3.pdf

Gives /srv as the correct location for data served by the machine, /var/www is historical and only needs to exist for people who haven't caught up with current standards (which are pretty old btw).

I disagree. Other UNIX/UNIX-likes still use /var/www so it's not merely "historical". The FHS doesn't say that anything in /srv has to be a directory rather than a symlink. What it does say however is:... and unfortunately that is what is happening here (though more accurately they're being moved rather than removed).

Actually, on reflection, rather than doing what I suggested above, I think the package should just leave the contents of /srv well alone and leave its management entirely in the hands of the sysadmin/user.

Given that Slack is following the FHS recommendation to some extent already by allowing apache to reference /srv paths in the default config:

My preference: Pat sucks it up and just moves the default location to /srv/httpd, letting /var/www/ symlink to it.

Whether symlinks are in /srv or in /var: The symlink should be created conditionally IFF there is nothing already in place. A possible option would be to create "/srv/httpd.new -> /var/www" if /srv/httpd already exists (or the other way round if the default location were moved); but whether that's necessary is an exercise for the reader.

I have to say, I'm a little surprised of this... I don't agree with updates that touch "working directories" like /srv/www and /srv/httpd are supposed to be .. It doesn't matter if backups are made or not (I like that they are).. The packages shouldn't touch them and links should only be created if nothing exists there..

P.S. Just think of what could happen if you upgrade under low disk space conditions..

LE: As for the location, I think /var/www is the best place since there are cases where /var might get mounted separately but it wouldn't make sense to mount /srv for a few MBs of data on a different partition/disk (and leaving them on under / is just careless)..