I have some(10) scripts that will be run via root's crontab, on almost 70 servers.
I have configured crontab on one server, to run the scripts(all of the scripts are placed under /root/bin/ directory)
question 1, is there an automated way to configure the crontab on rest of the 69 servers ? e.g we can copy /etc/sudoers configured on 1 machine to other machines .. I mean is there any way to configure the crontab too ?
> If you want to use this just edit a file like /etc/crontab and write normal crontab > procedures. Then run > # crontab /etc/crontab
yes the above solution works :)
> Problem with this is that crontab -l or -e won't show them (if > i remember correctly). No, atleast the distro(SUSE) I am using works just apposite to what you said in case of # crontab /path/to/file what happens is that it overwrites the root's crontab (/var/spool/cron/tabs/root) and 'crontab -l' and 'crontab -e' shows all the jobs in /path/to/file
Thanks Dear Vitaly Karasik your suggestion also works ;). the only difference I found is the path(it might be due to the distro difference). On my box(SUSE 10 SP2) its inside /var/spool/cron/tabs directory
as mentioned above, it is possible to distribute somehow your crontab file to all of your servers and install it there.
However, with such number of servers I would see problematic to maintain script up to date according latest changes/requirements. What I would do is that I would export some shared folder from one of the servers (where crontabfile would be placed) and mounted it e.g. via NFS on the rest of the servers. this way you always have one copy of the script available on all the servers Now it depends, whether all of your servers should have just the same (shared) crontab file or there can be slight differencies. if they are the same, you may want just to link root's crontab (/var/spool/cron/root) to your NFS-shared crontabfile. If there might be differencies you need to write short script that will compile together your central NFS shared crontabfile and local one and install it after every change of either central or local script.
>emha: you may want just to link root's crontab (/var/spool/cron/root)
Directly changing the file /var/spool/cron/root may or may not work. On HP-UX, cron needs to be notified of any changes, otherwise they would be ignored.
yes, I believe different platforms may implement thing different ways (I have experience when on Tru64 it took some time until cron accepted changes made via crontab -e and new things 1 or 2 cycles weren't executed) However, question is posted in linux forum ans there is SUSE distro mentioned above. Here is what cron daemon man page on my SUSE 7.3 box says:
---- Additionally, cron checks each minute to see if its spool directory's modtime (or the modtime on /etc/crontab) has changed, and if it has, cron will then examine the modtime on all crontabs and reload those which have changed. Thus cron need not be restarted whenever a crontab file is modified. ----
similar statement I have found in RHEL AS4 man page.
so, to satisfy cron, it may be necessary to update timestamps of mentioned folders somehow (if SUSE 10.2 still relys on folder timestamps), but there is still advantage of having one central crontab file
thanks emha for such a nice tip > However, with such number of servers I would see problematic to > maintain script up to date according latest changes/requirements. Yes I have done the following setup on a server I have configured rsync
on rsync server(192.168.0.6) I placed all the scripts under the /root/bin/scripts directory and under /root/bin/cron directory, I created a file 'root' that contains cron jobs
# cat /etc/rsyncd.conf
[scripts] path = /root/bin/scripts
[cron-jobs] path = /root/bin/cron
---- I then created a script, that will configure the cron jobs on all 69 servers.
#!/bin/bash
while [ 1 != 0 ]; do
clear echo -e "\nTo quit, press CTRL+C\n" echo -e "Please Enter the IP: " read IP
With that number of servers, would be wise to implement some sort of job scheduler that will automatically spread the changes, the scripts can even be embedded in the job...
