Re: cron

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux