/tftpboot vs. /var/tftp vs. something else?

[Richi Plana]

On Wed, 2007-11-14 at 17:52 -0500, Jon Masters wrote:
> I vote for just not moving it. It's been around many times the lifetime
> of FHS and other "standards", that themselves were based upon what
> existed at their inception. If anything these "standards" should be
> updated with occasional exceptions, based upon years of reality.

As a systems administrator, I hate it when things get changed because it
means more work for me. But I wouldn't even begrudge this move because
it solves the bigger problem of "Gee, I need to install a new data
server, but wheretf should I go to place my data
files?! /var/lib/mysql? /var/www/html? /tftpboot? /var/lib/samba?" If
it's going to be /var/lib/, then at the very least put that in the
documentation somewhere. Because, currently, this is what I have
in /var/lib/:

alternatives
cs
dhclient
dovecot
hsqldb
mlocate
nfs
random-seed
samba
setroubleshoot
texmf
webalizer
asterisk
dav
dhcpd
games
logrotate.status
mock
ntp
rpcbind
scrollkeeper
spamassassin
tomcat5
xkb
bluetooth
dbus
dhcpv6
hal
misc
multipath
php
rpm
sepolgen
stateless
tor
yum

and I'm not sure what's supposed to be in them nor how the packages were
split with that and /etc/<package> or /usr/share/<package>

> Yeah, I know, this is a very conservative attitude for a change. I guess
> we could just throw out the Linux kernel because it's also based on "30
> year old technology", but it seems to work well for most of us.

Could we please stop using inaccurate analogies? Asking that we throw
out the Linux kernel is like asking to throw out tftp-server and not at
all like moving data subdirectories. If you must bring in the kernel,
then it would be akin to changing /proc semantics or adding /dev/shm
(which has already happened).

One of the reasons why there has to be a ton of books on Unix system
administration is precisely because a lot of things in the past could
only be gleaned by going through tons of documentation. Believe me, I
can see the stark contrast between then and now ... specifically when it
comes to service configuration. Before I had to trundle through loads of
docs just to find config files. Now it's an easy guess with checking
"rpm -ql <package>" for /etc/ files.

Shared objects files also seem to have come under standardization with
most of the native elf shared objects going into /usr/lib(64)/.

It's a little bit different for server data files, though. Mail spool,
proxy caches, etc. have gotten a little tamer, but there's always room
for improvement.
--

Richi Plana