Remote, Automated Configuration of Unix Boxen? 18
drift factor asks: "I work for a small company with about 200 Linux desktops, all identical aside from hostname and IP information running Redhat from a kickstart install. Currently, when something needs to be changed on all of them (say, the default gateway) we either have to ssh into all of them and do it manually, or write a Perl script to do so for us. Is there a good remote configuration system that will also allow some level of automation, i.e., I tell it what IP I want the default gateway to be on each machine and it updates them for me?" If you manage a large server farm and have used or written utilities that do this, please share your experiences.
This could work (Score:1)
"apt-get update ; apt-get dist-upgrade" would need to be done every day, but try to get each machine doing it at a different time so you don't overload your server (or network). You could either use random times, or something like anacron so you can say "once a day" instead of "2:00AM every day". Doing it at night would be good if you leave the machines on.
Pretty easy (Score:1)
Re:DHCP is obvious (Score:1)
This is basically the same as your idea, except the client downloads the script from the server (instead of the server sending stuff to the client).
A lot of stuff (Score:1)
For network configuration, DHCP is one reasonable alternative (although you'll probably simply want bootp support, allowing systems to keep their own IPs static). Using rdist to propagate changes may also be reasonable, for other things, and it can be used with ssh.
Kerberos is one way to handle network-wide logins, although I have issue with it because it requires /etc/passwd be kept around (Kerberos handles authentication but not the additional needs of Unix, such as file ownership determination and such). NIS is insecure, NIS+ is too complex for a single domain (and I'm not sold on its scalability, either). However, it doesn't look like that sort of thing is really you're concern, so I'd say rdist :)
Re:DHCP is obvious (Score:1)
For something like this, you may be stuck writing a script. The reason I recommended Expect is because this tool makes these kinds of scripts incredibly easy to write (especially compared to writing the same scripts in Perl). Give it a shot.
I'd also suggest finding an RPM of the updated netscape, then the code for updating Netscape in Expect would be:
spawn "rlogin $hostname\r" ;#root shell prompt... ;#RPM switches right?
expect "#"
send "rpm -Uvh netscape.rpm\r"
expect "#"
send "logout\r"
Missing the point (Score:1)
Say I've got a (solaris) box named "foo", the
set semsys:seminfo_semmni=10
set semsys:seminfo_semmnu=300
and then I've got a (solaris) box name "bar",
the
set semsys:seminfo_semmni=30
set semsys:seminfo_semmnu=700
Now, let's say that I want to add the following lines to both boxes:
set sd:sd_io_time=0x3c
set sd:sd_max_throttle=2
I don't want to copy over the file, I like the values how they are! That's the basis of this guys question, and the same thing that I'm looking to do quite soon.
None of the options using CVS or DHCP take this into account. Please make sure you understand the full nature of the post before you add 50 lines of worthless advice.
Re:Yes (Score:1)
Re:Yes (Score:1)
Re:DHCP is obvious (Score:1)
DHCP is obvious (Score:2)
For your network dhcp is the obvious solution. (Congradulations to the first post comment that was on topic an correct. lacking details, but that is a different story)
For a more general approach, NIS comes to mind, though it wasn't designed to be secure. NIS+? kerboses? Your not the only one with the problem you state, in fact you hardly have a program compared to many installations. I've seen systems with 300 Solaris/aparc machines, 200 sunOS 4.x (much nicer then solaris IMHO), 75 IRIX, 200 Linux, and probably some HPUX and AIX scattered in there two. This at a university for student accessable accounts in CS or other engineering areas. Your 200 machines is nothing compared to the 20,000 users they managed. And most would not consider that close to large.
My point is that others have seen your same problem, and worked on solutions.
Almost the same idea (Score:2)
I build the image on a box and the propogate the changes via a rsh/perl script that tells the clients to update.
For large system updates and configuration, it isn't that bad of way to go.
Depends on the complexity of the task (Score:2)
Warped thought - cron and CVS. (Score:2)
Set up a cron job on each machine to check out the latest version of the installation every day at 5am. Make the cron job shut down and reinitialize anything important, too (or just have it reboot the machine and let init/shutdown scripts take care of it).
This isn't a remote admin solution, but it _does_ let you easily make sure that all packages and config files on the machines are in synch. Upgrade Netscape on the master server, for instance, and the other installations migrate over in a few hours.
You could even rig it so that the cron job calls a specific script before completion, and check that script out of CVS for any specific shell-ish things that have to be done for maintenance to complete the update (test these scripts carefully, though).
cfengine works pretty good for me. (Score:2)
we have a master server that get's config files from CVS, and pushes out to rsync servers.
every host calls rsyncs once an hour (or as often as you can get cron to do it) from the rsync servers, and EVERY hosts config is in cfengine, even the rsync servers and cvs servers.
we make heavy use of CNAMEs so that if a machine disappears, we can magically recreate it and none of the workhorse hosts know the difference.
go check out infrastructures.org for some good reading.
Expect can be your best friend in automation. (Score:2)
I work in a testing lab where we have to run large numbers of regression tests that would be incredibly time consuming if we didn't use automation tools.
I've been using Expect [nist.gov] for test automation on the latest series of tests. Expect is an automation scripting tool that runs on top of Tcl. It is very useful for automating command-line based applications using "send <string> expect <string>" sequences.
As far as licensing is concerned, Expect was developed at the NIST, and has been released into the public domain. That's about as free as you can get.
Re:Yes (Score:2)
I also use procmail to do some grunt work (weird huh?)...for example if i want to clean the print q of server 26 i can mail root@server26 with the header as COMMAND: DELETE PRINTQ and a procmail script will see the COMMAND: in the header and do a simple lprm -Plp -...ok..im half asleep as i type this..but i hope im making some sense. im a uni admin BTW. i've got machine with weird configs to look after so it might not suit your problem...none of my machines are the same.
cfengine!!!! (Score:2)
*Not a Sermon, Just a Thought
*/
Powerful tools... (Score:3)
-----------------------------------------