Re: directory to store TLE files
On Tue, Feb 17, 2004 at 12:33:57PM -0700, Nate Duehr wrote:
>
> On Feb 17, 2004, at 11:14 AM, Jeffrey Austen wrote:
>
> >Good idea. However since /usr is supposed to contain read-only data
> >how can the TLE be updated (except by root)? It seems like /var might
> >be better but there is no place under /var that really fits this type
> >of data. The closest thing I see is /var/lib but that is not a great
> >match to this type of data.
>
> Just going by what I see in other packaged software, it appears that
> mysql and postgresql use /var/lib also. If that's not correct, then
> two very large database packages are wrong. ;-)
It depends on your definition of wrong but it's very likely they are
wrong.
What has /var/lib to do with application data storage? MySQL in
particular? lib is described as place to keep library files for C and
other programing languages. Since when is mySQL data file(s) such a
library?
That location is also impractical for the following reason. Programmers
(usually) don't think about system backup when writing programs. They
don't care (and why should) where the data files end up. Idealy, the
largest partition would end up keeping localy generated or installed
files so that default or initialy alocated space for partitions /usr
and /var won't run out of space. /home/www or such makes sense assuming
/home is the "rest of the disk" partition.
After the OS is installed, only configuration files and localy added
applications need to be backed up right away. I see no reason to backup
files that I can restore from the original installation CD or the net.
Mixing fresh apps with default system files complicates backup
procedures and we all know that backups are a constant problem. Yes, I
know about command find and it's options but why complicate things?
If you install "local application" in /usr/lib for example, you need to
backup complete /usr or whatever subdirectory you installed your app in.
That's a pain to keep track of. It's much better to make such
installations in /usr/local which is always included in my backups so
that in the worst case scenario I restore OS with it's default /usr
structure from a CD and localy installed stuff under /usr/local from my
backups.
Xandros (debian based) for example creates the following directories
under /usr/local
bin games include lib man sbin share src
so I would use that structure for installing nonstandard applications.
It's easy to see where the files need to go. bin for user executable,
sbin for daemons or commands that only root is (supposed) to run, etc.
Some companies, Sun for sure, Checkpoint, etc. use /opt for optional
applications. I usually make a link from there to /usr/local/opt to
simplify partitioning scheme since / (root) needs not be bigger than 250
MB or so in most cases.
Of course, others might disagree but keeping track of optionaly
installed apps for backup purposes is not easy if the files end up mixed
with default OS installation. When your apps become part of a
distribution then I see no problem with having them in non local /usr
structure.
That way backups become very simple.
/etc, /root, /home, /opt, /usr/local, /var
/var is for spool, log files and not application data storage IMO. Some
people started to stick www (debian included) and databases under /var
which I believe is wrong. Perhaps their desks are a mess too so they
don't care. Another important point is file systems security. Bad guys
will more likely try to hide something in areas we assume are part of
default OS installation.
There was a reason for the current Unix file structure, see book UNIX
Power Tools, p.247.
Since people have different views and experiences with this my
suggestion is as simple as this: give people an option to install where
they believe is the right place and let them bang their heads against
the hard drive when there is a problem. Data files can then be put
anywhere and only a link from application subdirectory would be
necessary to find them. [1]
That should avoid FHS wars ;-)
[1]
/usr/local/yourapp
/usr/local/yourapp/bin/yyyy <--- your app executables
/usr/local/yourapp/man <--- man pages
/usr/local/yourapp/data <--- link to where you have space for data
That makes it easy for a backup or copy to another system.
>
> Nate Duehr, nate@natetech.com - WY0X
Thanks,
--
Rafael Skodlar
Reply to: