Mailinglist Archive: opensuse (1761 mails)
| < Previous | Next > |
Re: [opensuse] crontab
- From: "Brian K. White" <brian@xxxxxxxxx>
- Date: Tue, 17 Aug 2010 20:48:31 -0400
- Message-id: <4C6B2DDF.8010904@xxxxxxxxx>
On 8/17/2010 7:56 PM, Randall R Schulz wrote:
Yes.
Ok not good enough or can't fill in the blanks yourself?
Define effectively.
Yes the root jobs will run, and yes being root they can do anything, and yes on legacy unix that was in fact the definition of the "system" crontab.
Yes there is "effectively" a difference, but the "effect" happens to be in transparancy/expectations/obfuscation. Few new linux admins will think to look in root's crontab for typical cron jobs. So if there are some, you will cause some amount of people writing duplicate or conflicting jobs in /etc/crontab and discovering the hard way that some bonehead before them did the unexpected. Also by deviating from most common documentation, you cause newbies who don't know any better have unnecessary problems later. Old docs will say "crontab -l >crontab ; vi crontab ;crontab <crontab" , lower quality docs will say "crontabe -e" (look up "crontab -r", now look at e and r on your keyboard), current docs matching the OS the user is actually running will say vi /etc/crontab. New scripts and utilities written with varying degrees of care by programmers of varying quality will work on /etc/crontab and may or may not factor in roots crontab. I'm not even sure if such utils necessarily should be obligated to worry about that. You're supposed to know what you're doing and what you want, not rely on utilities to tell you.
Sure a good admin/consultant should know all this and not be tripped up. But an even better admin/consultant always seeks to minimize accidents as much as possible through thoughtful choices rather than not being thoughtful and then blaming any resulting problems on someone else not being good enough to handle it. BOTH parties need to be as good as possible, and part of that is not requiring the other party to be 100% perfect wherever possible/practical. You can do almost anything on a unix box and have it "work". And a good admin should really have no excuse for not knowing how things are working because ultimately everything can be examined and tracked down no matter how non-standard it is. But that does not excuse you from deviating from the expected norm unnecessarily.
You could start a service at boot by having some suid binary, or a sudo config for some user such that a user can run the service, and have a users private crontab try to start the service every minute, and have nothing anywhere in the normal init scripts. A good admin has no excuse for being baffled by how that service is being started for more than a few minutes. But that does not mean it's not a completely stupid way to get that job done and I'd never hire someone who know enough unix to do all that and yet did it that way (without some pretty compelling reason).
Yes there is an "effective" difference, if somewhat more minor than the init script example because root's crontab is still somewhat in use because other unix variants are still somewhat in use and lots of old docs are still applicable. I know of at least one commercial backup util that will write it's own crontab entry into roots crontab and not in /etc/crontab at least as of a couple years ago.
But when you are talking about linux, and you say "the system crontab" there is by far a clear standard definition for that and it's /etc/crontab. So thats another effective difference, simple dis-ambiguity of communication and definition of terms.
I apologize for sounding like I'm giving you personally a hard time. I don't wish to. You asked, I answered. I often fail at being concise without leaving out parts that I consider to matter.
--
bkw
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx
On Tuesday August 17 2010, Carlos E. R. wrote:
On 2010-08-18 00:07, Randall R Schulz wrote:
On Tuesday August 17 2010, Bob Williams wrote:
...
... I want to edit the system crontab, as I have some tasks that
have to run as root. I'll try editing it manually and see what
happens :)
You can simply:
% sudo crontab -e
That does not edit the system's crontab, but root's crontab.
OK. Is there effectively any difference?
Yes.
Ok not good enough or can't fill in the blanks yourself?
Define effectively.
Yes the root jobs will run, and yes being root they can do anything, and yes on legacy unix that was in fact the definition of the "system" crontab.
Yes there is "effectively" a difference, but the "effect" happens to be in transparancy/expectations/obfuscation. Few new linux admins will think to look in root's crontab for typical cron jobs. So if there are some, you will cause some amount of people writing duplicate or conflicting jobs in /etc/crontab and discovering the hard way that some bonehead before them did the unexpected. Also by deviating from most common documentation, you cause newbies who don't know any better have unnecessary problems later. Old docs will say "crontab -l >crontab ; vi crontab ;crontab <crontab" , lower quality docs will say "crontabe -e" (look up "crontab -r", now look at e and r on your keyboard), current docs matching the OS the user is actually running will say vi /etc/crontab. New scripts and utilities written with varying degrees of care by programmers of varying quality will work on /etc/crontab and may or may not factor in roots crontab. I'm not even sure if such utils necessarily should be obligated to worry about that. You're supposed to know what you're doing and what you want, not rely on utilities to tell you.
Sure a good admin/consultant should know all this and not be tripped up. But an even better admin/consultant always seeks to minimize accidents as much as possible through thoughtful choices rather than not being thoughtful and then blaming any resulting problems on someone else not being good enough to handle it. BOTH parties need to be as good as possible, and part of that is not requiring the other party to be 100% perfect wherever possible/practical. You can do almost anything on a unix box and have it "work". And a good admin should really have no excuse for not knowing how things are working because ultimately everything can be examined and tracked down no matter how non-standard it is. But that does not excuse you from deviating from the expected norm unnecessarily.
You could start a service at boot by having some suid binary, or a sudo config for some user such that a user can run the service, and have a users private crontab try to start the service every minute, and have nothing anywhere in the normal init scripts. A good admin has no excuse for being baffled by how that service is being started for more than a few minutes. But that does not mean it's not a completely stupid way to get that job done and I'd never hire someone who know enough unix to do all that and yet did it that way (without some pretty compelling reason).
Yes there is an "effective" difference, if somewhat more minor than the init script example because root's crontab is still somewhat in use because other unix variants are still somewhat in use and lots of old docs are still applicable. I know of at least one commercial backup util that will write it's own crontab entry into roots crontab and not in /etc/crontab at least as of a couple years ago.
But when you are talking about linux, and you say "the system crontab" there is by far a clear standard definition for that and it's /etc/crontab. So thats another effective difference, simple dis-ambiguity of communication and definition of terms.
I apologize for sounding like I'm giving you personally a hard time. I don't wish to. You asked, I answered. I often fail at being concise without leaving out parts that I consider to matter.
--
bkw
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx
| < Previous | Next > |