I think a lot of the benefits you get by running services on separated paths, as special-purpose users, ... is that you minimize side-effects provoked by work on other parts of the system.
For data shared by sevaral users, I very much prefer some separate /data/service/instance/... structure. Also much easier to allocate sane directory permissions.
So what is the homedir for? "Home directories for users". See 'man
hier'. This to me means it is not a directory for services.
This doesn't answer your question of course. There is still the 'why' of it.
Why has this become the standard?
The homedir is a volatile place. Where users reside often. And make changes
often. Any place humans change things is a place where stuff breaks easily and
on a regular basis. What if Lennard calls 'rm' with a wrong switch? Or chown?
Or chmod? The service receives pain.
Or he could decide that he no longer wants his homedir to be
readable/executable by everyone on the system, so he chmod 0700 his homedir.
Forgetting that this will render his trac instance unavailable.
Or what about sharing some responsibility? How is Lennard ever going to share
the maintenance of the ticketing system with anyone else? What impact will that
have on the ticketing system? Will it have to be migrated anyway to /srv or
/usr/local or /opt? What configs will that affect? What about the webserver
configs? What about file permissions, uids, gids?
What about backups? Are they configured for this specific service? If it is
ever migrated to another location, do they have to be reconfigured? Or will
/home/lennard just be backed up as before and no one will remember that trac is
now in /srv/trac, making a restore improbable.
What about a reboot? Will the service come back up? What if you have to
re-implement this service on another machine after this one explodes? Are you
sure you did not forget to point /etc/rc.local (or some other hack) to your new
machine?
These are only the reasons I could think of off the top of my head. And most of
these are actual examples from the field.
A standard is a standard, because it works for more people than just you. The
question you, and lennard, should be asking yourself is: How can these
standards work for me as well?
(As you can probably tell, I grew up in Ops, not Dev. I have seen the pain of
the 'works-for-me'-mentality.)
Also, cnvogel is obviously more consise than me. :-)
Comments
I don't like the idea of anyone running mission critical services from their homedir.
Why not?
I think a lot of the benefits you get by running services on separated paths, as special-purpose users, ... is that you minimize side-effects provoked by work on other parts of the system.
For data shared by sevaral users, I very much prefer some separate /data/service/instance/... structure. Also much easier to allocate sane directory permissions.
So what is the homedir for? "Home directories for users". See 'man hier'. This to me means it is not a directory for services.
This doesn't answer your question of course. There is still the 'why' of it.
Why has this become the standard?
The homedir is a volatile place. Where users reside often. And make changes often. Any place humans change things is a place where stuff breaks easily and on a regular basis. What if Lennard calls 'rm' with a wrong switch? Or chown? Or chmod? The service receives pain.
Or he could decide that he no longer wants his homedir to be readable/executable by everyone on the system, so he chmod 0700 his homedir. Forgetting that this will render his trac instance unavailable.
Or what about sharing some responsibility? How is Lennard ever going to share the maintenance of the ticketing system with anyone else? What impact will that have on the ticketing system? Will it have to be migrated anyway to /srv or /usr/local or /opt? What configs will that affect? What about the webserver configs? What about file permissions, uids, gids?
What about backups? Are they configured for this specific service? If it is ever migrated to another location, do they have to be reconfigured? Or will /home/lennard just be backed up as before and no one will remember that trac is now in /srv/trac, making a restore improbable.
What about a reboot? Will the service come back up? What if you have to re-implement this service on another machine after this one explodes? Are you sure you did not forget to point /etc/rc.local (or some other hack) to your new machine?
These are only the reasons I could think of off the top of my head. And most of these are actual examples from the field.
A standard is a standard, because it works for more people than just you. The question you, and lennard, should be asking yourself is: How can these standards work for me as well?
(As you can probably tell, I grew up in Ops, not Dev. I have seen the pain of the 'works-for-me'-mentality.)
Also, cnvogel is obviously more consise than me. :-)