Mikkel L. Ellertson wrote:
Now, I know Les is going to complain that this makes it harder to
find things.
My complaint is that it is arbitrary and inconsistent.
Arbitrary? Sure. Most of the file locations used in Linux are
arbitrary.
The ones that were inherited from older systems usually had functional
reasons. The moves and renames since have mostly been arbitrary.
After all, do we really need /bin, /usr/bin,
/usr/X11R6/bin, and /usr/local/bin?
The X stuff is the only oddball there and it can easily be a symlink to
/usr/bin. /bin must be on the root filesystem because it contains
programs needed by the boot processes. /usr/bin can be mounted later.
/usr/local/bin is obviously for locally added things, not part of the
distribution. On the other hand, there is nothing functionally
different or necessary about /sbin and /usr/sbin vs. their counterparts.
If you want to control who can execute something you can do it with
permissions instead of obscure paths.
We could put all the programs we
want users to be able to run by default in /bin.
In these days of big drives, you could. But /usr/local/ still needs to
be separate to avoid conflicts with same-named system programs that
might overwrite the ones you need in an update.
> You may want to
read the Linux-Filesystem-Hierarchy some time. It is full of
arbitrary locations for things.
No, it's too depressing. Every time that committee meets I have to go
re-write dozens of scripts that would otherwise have run unchanged for
decades.
> It even specifies things like the
directories for system cron jobs. Funny thing - it talks about the
/etc/cron.d, /etc/cron.daily, /etc/cron.weekly, /etc/cron.monthly
directories, and the /etc/crontab file.
But the resulting changes don't give any new functionality.
I don't have a problem with a systematic scheme of breaking individual
files into xxx.d directories with smaller entries.
I don't understand - are you complaining that system cron jobs are
broken up into smaller files, or not?
No.
Or are you complaining because
system cron jobs and user cron jobs are in different places?
I'm complaining that for any given job, you have no idea where the entry
that controls it would be found, and no way to describe where to look
first. Contrast that to the way entries in /etc/init.d, /etc/pam.d/ or
/etc/xinetd.d are made. For a given service there is a logical place to
find its specific broken-up entry. For scheduled jobs relating to a
service there is no such logic.
What
next, complaining because root's home directory is not in /home like
the user's home directories?
No, that has the same functional reason as the separation of /bin and
/usr/bin. The root user must be able to work in single user mode before
any partitions have been mounted. /home is better off on a mounted
partition. And, there is no issue with finding the location of any
particular home directory since they are all identified in the
/etc/passwd file and the shell will interpret ~username as that path for
you.
You might want to look at the reason
for things like this. (/etc can be mounted read-only, so the
user-editable files end up in the /var tree. Home may be on its own
partition, and not mounted in the single user mode.)
I'll look at that when they stop changing it with every version and/or
they come up with a scheme that interoperates with with non-linux
systems - or even older versions of their own schemes.
It does not make sense to put user cron jobs in these directories.
Why shouldn't any scheme that is useful at the system level be equally
useful for each user - and more understandable when it all works the
same way and has the same format for the entries? If the system needs a
cron.d so programs can twiddle the entries easily, why shouldn't users
each get the same functionality?
If a user has the need for the same functionality, they can
implement it as well. There is nothing preventing a user from
creating the same structure in their home directory, and adding the
run-parts command to their own crontab. The only thing they can not
duplicate is the ability to run cron jobs as other users, or the
function of the /etc/cron.d directory. Then again, they should not
have enough cron jobs to require it.
Beg your pardon? The reason I have computers is to do my jobs, not just
so the system can run itself. If cron.d has to be hardcoded somewhere,
why shouldn't I get one too?
By separating the system cron jobs from the user cron jobs,
you make it less likely that the system cron jobs will get changed
by mistake.
How so? If you run crontab -e as a user you can only edit your own
entries, you don't need to know where it is stored, and the cron process
is notified when the file changes.
The system cron jobs are installed as part of the package they are
needed for. Why would you need to know where they are or edit them?
They might be wrong. They might conflict with something else I have
running. Or I might want to make my own arbitrary changes.
If you have not done enough research to know what affect your
changes are going to have on the system, then you probably should
not be changing things. If you have done the research, then you
should know where to find the files. Reading the LFH or the cron man
page will tell you the locations. Or are you saying that there
should be a nice GUI to let you shoot yourself in the foot?
The GUI is irrelevant. If there were a sensible scheme to find the
entry controlling a given job a sensible GUI could do it, or you could
do it with any editor.
And the point of separating the system from root jobs so you have to
hunt all over the place to find them?
Hunt all over the place to find them? If you can not find them after
reading the cron man page, are you sure you should be messing with
them?
If I give you the name of a program or the user id the job runs under,
can you tell me where to find the entry that controls its schedule by
reading any of those man pages or FHS entries you've mentioned?
If I add a scheduled job as administrator myself, could you tell the
next machine administrator where to look to find it and the other jobs
that run as root? Does any of this help you write a script that would
modify a given entry on some unspecified version of a unix-like
operating system?
> After all, this is not Windows - Linux does
not claim you can administer everything with a point & click
interface without having to learn how things work.
That's not what I'm suggesting, although if the underlying structure is
not all hard-coded arbitrary special cases it becomes much easier to
wrap it with an understandable interface.
> For some things,
you have to be willing to learn enough to make informed choices,
accept the defaults,
And change them every time a committee votes...
or get someone that has the knowledge to make
the changes for you.
Again...
--
Les Mikesell
lesmikesell@xxxxxxxxx
