Hi,
What's the best/safest way to "cat" the following job into crontab?
*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1
I am used to doing this manually via crontab -e, but now I simply have too many centos servers to build in a given week (get to toss another 120K at some more 2U chenbro/tyan/amd64's -w000ooo).
-karlski
On Mon, Mar 12, 2007 at 05:21:47PM -0800, Karl R. Balsmeier enlightened us:
What's the best/safest way to "cat" the following job into crontab?
*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1
I am used to doing this manually via crontab -e, but now I simply have too many centos servers to build in a given week (get to toss another 120K at some more 2U chenbro/tyan/amd64's -w000ooo).
echo '*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1' > /etc/cron.d/check_megaraid_passive.sh
(Watch for wrapping, of course).
Matt
On Mon, 12 Mar 2007 20:58:46 -0400, Matt Hyclak wrote:
On Mon, Mar 12, 2007 at 05:21:47PM -0800, Karl R. Balsmeier enlightened us:
What's the best/safest way to "cat" the following job into crontab?
*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1
I am used to doing this manually via crontab -e, but now I simply have too many centos servers to build in a given week (get to toss another 120K at some more 2U chenbro/tyan/amd64's -w000ooo).
echo '*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1' > /etc/cron.d/check_megaraid_passive.sh
(Watch for wrapping, of course).
Matt
Isn't this supposed to be written to /etc/crontab (if root) or to /var/spool/cron/username (if a user) ? Or maybe I am mistaken?
Akemi
On 13/03/07, Akemi Yagi amyagi@gmail.com wrote:
On Mon, 12 Mar 2007 20:58:46 -0400, Matt Hyclak wrote:
On Mon, Mar 12, 2007 at 05:21:47PM -0800, Karl R. Balsmeier enlightened us:
What's the best/safest way to "cat" the following job into crontab?
*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1
echo '*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1' > /etc/cron.d/check_megaraid_passive.sh
You should be appending so would you not use >> instead of >
On Tue, Mar 13, 2007 at 07:32:20AM +0530, Sudev Barar enlightened us:
On Mon, 12 Mar 2007 20:58:46 -0400, Matt Hyclak wrote:
On Mon, Mar 12, 2007 at 05:21:47PM -0800, Karl R. Balsmeier enlightened us:
What's the best/safest way to "cat" the following job into crontab?
*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1
echo '*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1' > /etc/cron.d/check_megaraid_passive.sh
You should be appending so would you not use >> instead of >
I was assuming we were creating a new file. Either way will work.
Matt
On 3/12/07, Sudev Barar sbarar@gmail.com wrote:
You should be appending so would you not use >> instead of >
I disagree. Matt's example created a new file in /etc/cron.d/ Ideally you'd have one job, or one related set of jobs per file in this directory. Using >> would create a situation (upgrades) where you could potentially have the same job listed multiple times in the cron file. Using > allows you to keep exactly what you want, and only what you want in that file.
On Mon, Mar 12, 2007 at 06:58:44PM -0700, Akemi Yagi enlightened us:
On Mon, Mar 12, 2007 at 05:21:47PM -0800, Karl R. Balsmeier enlightened us:
What's the best/safest way to "cat" the following job into crontab?
*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1
I am used to doing this manually via crontab -e, but now I simply have too many centos servers to build in a given week (get to toss another 120K at some more 2U chenbro/tyan/amd64's -w000ooo).
echo '*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1' > /etc/cron.d/check_megaraid_passive.sh
(Watch for wrapping, of course).
Matt
Isn't this supposed to be written to /etc/crontab (if root) or to /var/spool/cron/username (if a user) ? Or maybe I am mistaken?
You could, and then the next time cron is updated you either have /etc/crontab overwritten by the new one, or you get a .rpmnew with important changes that you are now missing.
Putting a file in /etc/cron.d is probably a better solution. Even better than the echo command above would be to create the file in an RPM that can then get distributed via your favorite package updater.
Matt
Akemi Yagi spake the following on 3/12/2007 6:58 PM:
On Mon, 12 Mar 2007 20:58:46 -0400, Matt Hyclak wrote:
On Mon, Mar 12, 2007 at 05:21:47PM -0800, Karl R. Balsmeier enlightened us:
What's the best/safest way to "cat" the following job into crontab?
*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1
I am used to doing this manually via crontab -e, but now I simply have too many centos servers to build in a given week (get to toss another 120K at some more 2U chenbro/tyan/amd64's -w000ooo).
echo '*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1' > /etc/cron.d/check_megaraid_passive.sh
(Watch for wrapping, of course).
Matt
Isn't this supposed to be written to /etc/crontab (if root) or to /var/spool/cron/username (if a user) ? Or maybe I am mistaken?
Akemi
Dropping a script into cron.d is the safer way of scripting a cron job. You are less likely to damage something if a script errs.
Balsmeier enlightened
us:
What's the best/safest way to "cat" the following job
into crontab?
*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1
I am used to doing this manually via crontab -e, but now
I simply have
too many centos servers to build in a given week (get to
toss another
120K at some more 2U chenbro/tyan/amd64's -w000ooo).
echo '*/3 * * * *
/usr/lib64/nagios/plugins/check_megaraid_passive.sh >
/dev/null 2>&1' > /etc/cron.d/check_megaraid_passive.sh
(Watch for wrapping, of course).
Matt
Isn't this supposed to be written to /etc/crontab (if root) or to /var/spool/cron/username (if a user) ? Or maybe I am mistaken?
Akemi
Dropping a script into cron.d is the safer way of scripting a cron job. You are less likely to damage something if a script errs.
The most common way I have seen ov updating crontab is the crontab command.
1. login or su to the appropriate user 2. crontab -l > /tmp/crontab.txt 3. edit /tmp/crontab.txt to your liking 4. crontab /tmp/crontab.txt
This gets the right files in the right places an alerts cron of the change.
Bob Styma
On Tue, Mar 13, 2007 at 11:32:55AM -0500, Styma, Robert E (Robert) enlightened us:
The most common way I have seen ov updating crontab is the crontab command.
- login or su to the appropriate user
- crontab -l > /tmp/crontab.txt
- edit /tmp/crontab.txt to your liking
- crontab /tmp/crontab.txt
This gets the right files in the right places an alerts cron of the change.
Or you could just type crontab -e and not copy tmp files around.
This method is fine when you're not trying to automate something, so is good information, but less useful to the OP.
Matt
thanks, I'm running a script after kickstart install, and am looking to "cat" a known value into an empty cron file. Managing it or otherwise having to manually edit it is not the issue i'm seeking info on.
I'm trying to avoid having to manually add all of my known cron jobs with crontab -e
To do this, I was trying out some stuff like:
*cat >> $out_file << EOF first line of data second line of data more data the end of the data EOF*
but in a way that was safe for cron, with no modifications to the default manner in which cron runs, e.g. crontab -l, crontab -e later would not break seeking some new file.
-karlski
Matt Hyclak wrote:
On Tue, Mar 13, 2007 at 11:32:55AM -0500, Styma, Robert E (Robert) enlightened us:
The most common way I have seen ov updating crontab is the crontab command.
- login or su to the appropriate user
- crontab -l > /tmp/crontab.txt
- edit /tmp/crontab.txt to your liking
- crontab /tmp/crontab.txt
This gets the right files in the right places an alerts cron of the change.
Or you could just type crontab -e and not copy tmp files around.
This method is fine when you're not trying to automate something, so is good information, but less useful to the OP.
Matt
On Tue, Mar 13, 2007 at 10:35:43AM -0800, Karl R. Balsmeier enlightened us:
thanks, I'm running a script after kickstart install, and am looking to "cat" a known value into an empty cron file. Managing it or otherwise having to manually edit it is not the issue i'm seeking info on.
I'm trying to avoid having to manually add all of my known cron jobs with crontab -e
To do this, I was trying out some stuff like:
*cat >> $out_file << EOF first line of data second line of data more data the end of the data EOF*
but in a way that was safe for cron, with no modifications to the default manner in which cron runs, e.g. crontab -l, crontab -e later would not break seeking some new file.
Then my first suggestion of making $out_file = /etc/cron.d/somenewfilename would work just fine.
Matt
Karl R. Balsmeier wrote:
thanks, I'm running a script after kickstart install, and am looking to "cat" a known value into an empty cron file. Managing it or otherwise having to manually edit it is not the issue i'm seeking info on.
I'm trying to avoid having to manually add all of my known cron jobs with crontab -e
To do this, I was trying out some stuff like:
*cat >> $out_file << EOF first line of data second line of data more data the end of the data EOF*
but in a way that was safe for cron, with no modifications to the default manner in which cron runs, e.g. crontab -l, crontab -e later would not break seeking some new file.
There are special cases for system entries where these can go in files with one or more entries under /etc/cron.d, or cron.daily (etc). However, these won't ever show up in anyone's 'cron -l' or 'cron -e' commands and thus aren't suitable for things that users will manage themselves after the install.
so to script the thing it's actually done like this, doh:
-------------snip------------ #show crontab, on a new system should be empty: crontab -l
#put in whatever cron checks you need, one by one... echo "*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1" >> /var/spool/cron/root
# restart crond afterward service crond restart
# show you results, new stuff should be there. crontab -l ------------------snip---------------
dunno why I was trying to do this elaborate EOF thing.
-krb
Karl R. Balsmeier wrote:
thanks, I'm running a script after kickstart install, and am looking to "cat" a known value into an empty cron file. Managing it or otherwise having to manually edit it is not the issue i'm seeking info on.
I'm trying to avoid having to manually add all of my known cron jobs with crontab -e
To do this, I was trying out some stuff like:
*cat >> $out_file << EOF first line of data second line of data more data the end of the data EOF*
but in a way that was safe for cron, with no modifications to the default manner in which cron runs, e.g. crontab -l, crontab -e later would not break seeking some new file.
-karlski
Matt Hyclak wrote:
On Tue, Mar 13, 2007 at 11:32:55AM -0500, Styma, Robert E (Robert) enlightened us:
The most common way I have seen ov updating crontab is the crontab command.
- login or su to the appropriate user
- crontab -l > /tmp/crontab.txt
- edit /tmp/crontab.txt to your liking
- crontab /tmp/crontab.txt
This gets the right files in the right places an alerts cron of the change.
Or you could just type crontab -e and not copy tmp files around.
This method is fine when you're not trying to automate something, so is good information, but less useful to the OP.
Matt
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Karl R. Balsmeier wrote:
#put in whatever cron checks you need, one by one... echo "*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1" >> /var/spool/cron/root
How are you going to remove or modify that line in a _safe_ and simple fashion when you'll have to? Are you verifying if someone or something else has opened the /var/spool/cron/root file for editing while you're messing with it?
With a dedicated file (separate files for each task / purpose / application / whatever) in /etc/cron.d changes or an altogether removal are both trivial and safe.
Florin Andrei florin@andrei.myip.org writes:
How are you going to remove or modify that line in a _safe_ and simple fashion when you'll have to?
Use cfengine. :-)
Arnaud Gomes-do-Vale wrote:
Florin Andrei florin@andrei.myip.org writes:
How are you going to remove or modify that line in a _safe_ and simple fashion when you'll have to?
Use cfengine. :-)
if you really want to use something, use puppet - its a few generations ahead of cfegine!
- KB
Florin Andrei wrote:
Karl R. Balsmeier wrote:
#put in whatever cron checks you need, one by one... echo "*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1"
/var/spool/cron/root
How are you going to remove or modify that line in a _safe_ and simple fashion when you'll have to? Are you verifying if someone or something else has opened the /var/spool/cron/root file for editing while you're messing with it?
With a dedicated file (separate files for each task / purpose / application / whatever) in /etc/cron.d changes or an altogether removal are both trivial and safe.
I am the only user on the box, -this is all part of the %post element of a Kickstart file. No one's on there, heh. But I see what you mean. If this were not the only cron job on the machine, i'd probably entertain the single-file/single-job tactic.
This particular question was aimed at adding the final line in a kickstart post-install script, e.g. modifying crontab in an automatic way to complete a given server build. Specifically the local changes a system gets to make it ready for Nagios monitoring, prior, I needed to manually visit all the machines i'd built and crontab -e. But then a phone rings, or a pager goes off, or a human appears, wanting something, heh. Automatic is the way.
I'll be creatively using cat and echo to automate the builds with as little sysadmin intervention as possible, I like to have a production-ready server active within 20 minutes (I mean production as in our company's highly detailed linux build), so here's an example of just one of those 20+ 'moving parts', that if done manually, on 10 machines, takes an hour or so at the very least, vs. 10 seconds max: ------------------snip---------------- # Megamake.sh <krb> 2007
########################### # LSILOGIC RAID CARD TOOLS MEGARC # This script assumes you already have nagios installed, # and send_nsca.cfg, nrpe.cfg, and /etc/xinetd.d/nrpe set properly
mkdir -v /usr/local/bin/megaraid cd /usr/local/bin/megaraid # don't wget from public, get from kickstart source dir. # wget http://www.lsilogic.com/files/support/rsa/utilities/megaconf/ut_linux_megarc...
# wget http://my.kickstart.server.ip:/kickstart/sources/lsilogic/ut_linux_megarc_1.... http://www.lsilogic.com/files/support/rsa/utilities/megaconf/ut_linux_megarc_1.11.zip
unzip ut_linux_megarc_1.11.zip chmod +x megarc.bin chmod +x megarc
# test the tool, -show the RAID level and how many disks you have, and their device ids: echo "THIS IS YOUR BASIC RAID SETUP" ./megarc -ctlrInfo -a0
# Run this command on your nagios server to see plugin results in real time: # tail -f /var/log/nagios/nagios.log
cd /usr/local/src wget://my.kickstart.server.ip:/kickstart/src/nagios/plugins/check_megaraid_passive.sh
cp check_megaraid_passive.sh /usr/lib64/nagios/plugins/ chmod +x /usr/lib64/nagios/plugins/check_megaraid_passive.sh
# run it, see if any errors pop up /usr/lib64/nagios/plugins/check_megaraid_passive.sh
# open it in vi to edit, in case there are errors, if not just close it. vi /usr/lib64/nagios/plugins/check_megaraid_passive.sh
# check the perms, if they match the other plugins ls -al /usr/lib64/nagios/plugins/check_megaraid_passive.sh # run it again /usr/lib64/nagios/plugins/check_megaraid_passive.sh
# edit the cron job for this guy: echo "*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1" >> /var/spool/cron/root # restart crond service crond restart
# At this point your Nagios check for this one service should go "green" and you can hit the other 10 Nagios checks # with your other scripts, and move on to Cacti adjustments.
--------------snip--------------
-karlski
On 13/03/07, Karl R. Balsmeier karl@klxsystems.net wrote:
I am the only user on the box, -this is all part of the %post element of a Kickstart file. No one's on there, heh. But I see what you mean. If this were not the only cron job on the machine, i'd probably entertain the single-file/single-job tactic.
This particular question was aimed at adding the final line in a kickstart post-install script, e.g. modifying crontab in an automatic way to complete a given server build. Specifically the local changes a system gets to make it ready for Nagios monitoring, prior, I needed to manually visit all the machines i'd built and crontab -e. But then a phone rings, or a pager goes off, or a human appears, wanting something, heh. Automatic is the way.
I use include statements RCS and 'here' documents to accomplish this sort of thing so I can have local customisations per-host but also a log of the changes in revision control.
So I'd have something like a centos4-install-ks.cfg called via PXE and in that...
# Setup users and their authorized_keys %include /mnt/ks/kickstart/include/users-and-keys.cfg
# Setup secure SSHD configuration %include /mnt/ks/kickstart/include/secure-sshd.cfg
# Setup Sudo %include /mnt/ks/kickstart/include/sudo.cfg
# Setup Nagios Remote Plugin Execution %include /mnt/ks/kickstart/include/nagios-nrpe.cfg
And in each of those, nagios-nrpe.cfg for example something like...
# Install and setup nagios configuration
yum -y install nagios-nrpe mkdir -p /etc/nagios/RCS mkdir -p /etc/xinetd.d/RCS ci -t-'Nagios Remote Plugin Exection configuration.' -u /etc/nagios/nrpe.cfg ci -t-'Nagios NRPE xinetd configuration.' -u /etc/xinetd.d/nrpe co -l /etc/nagios/nrpe.cfg co -l /etc/xinetd.d/nrpe
cat <<EOF > /etc/nagios/nrpe.cfg # # Nagios Remote Plugin Exection configuration. # # $Id$ # # FILE UNDER RCS, DO NOT EDIT WITHOUT CHECKING OUT!!!
server_port=5666 # allowed_hosts=127.0.0.1 nrpe_user=nagios nrpe_group=nagios dont_blame_nrpe=0 debug=0 command_timeout=60 command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10 command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20 command[check_disk1]=/usr/lib/nagios/plugins/check_disk -w 20 -c 10 -p /dev/mapper/vg00-lv00 command[check_zombie_procs]=/usr/lib/nagios/plugins/check_procs -w 5 -c 10 -s Z command[check_total_procs]=/usr/lib/nagios/plugins/check_procs -w 150 -c 200
EOF
cat <<EOF > /etc/xinetd.d/nrpe # default: off # description: NRPE (Nagios Remote Plugin Executor) service nrpe { flags = REUSE type = UNLISTED port = 5666 socket_type = stream wait = no user = nagios group = nagios server = /usr/sbin/nrpe server_args = -c /etc/nagios/nrpe.cfg --inetd log_on_failure += USERID disable = no only_from = 127.0.0.1 X.X.X.X X.X.X.X }
EOF
ci -m'Kickstart: Setting up default NRPE configuration.' -u /etc/nagios/nrpe.cfg ci -m'Kickstart: Setting up default NRPE Xinetd configuration.' -u /etc/xinetd.d/nrpe
# vim:sb:ai:sw=4:expandtab
Will.
On Mon, Mar 12, 2007 at 08:58:46PM -0400, Matt Hyclak wrote:
On Mon, Mar 12, 2007 at 05:21:47PM -0800, Karl R. Balsmeier enlightened us:
What's the best/safest way to "cat" the following job into crontab?
*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1
echo '*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1' > /etc/cron.d/check_megaraid_passive.sh
NOTE: MISSING "root" after the time spec. */3 * * * * root /usr/lib64/.....
This is the "new" way of doing it, using a feature of new versions of cron to scan a directory to get the cron information.
The old style method would be: crontab -l > /tmp/afile$$ echo '*/3 * * * * /usr/lib64/...' >> /tmp/afile$$ crontab /tmp/afile$$ rm /tmp/afile$$
The "new style" is much more suitable for scripting; in particular you can create RPMs that magically drop entries into the cron.d directory.
Rgds Stephen
On 13/03/07, Stephen Harris lists@spuddy.org wrote:
echo '*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1' > /etc/cron.d/check_megaraid_passive.sh
NOTE: MISSING "root" after the time spec. */3 * * * * root /usr/lib64/.....
This is the "new" way of doing it, using a feature of new versions of cron to scan a directory to get the cron information.
aahhhh...(did you just hear the coin drp in?)
Interesting and worth exploring. Thanks for insight Stephen.
Karl R. Balsmeier wrote:
What's the best/safest way to "cat" the following job into crontab?
*/3 * * * * /usr/lib64/nagios/plugins/check_megaraid_passive.sh > /dev/null 2>&1
I am used to doing this manually via crontab -e, but now I simply have too many centos servers to build in a given week (get to toss another 120K at some more 2U chenbro/tyan/amd64's -w000ooo).
crontab (and the files in /var/spool/cron) are for manual updates to the scheduled jobs. For automated updates, the "official" way is /etc/cron.d
So, if you want to automate the creation/removal of cron jobs, just create/remove files in /etc/cron.d crontab and the associated files are NOT the appropriate tool for that purpose.
Just create a file called /etc/cron.d/nagios-megaraid containing the line you specified.
-
Akemi Yagi -
Arnaud Gomes-do-Vale -
Florin Andrei -
Jim Perrin -
Karanbir Singh -
Karl R. Balsmeier -
Les Mikesell -
Matt Hyclak -
Scott Silva -
Stephen Harris -
Styma, Robert E (Robert) -
Sudev Barar -
Will McDonald