Apparently this is not as uncommon as I thought. I've received quite
a number of responses, so here's the summary:
- Expect and rdist were the two big responses here. Looking at the
web sites and notes for each, I've had to opt for expect to fit our
setup, with their 'passmass' script a perfect fit. rdist would be
useable here only if I could permit it to be copied everywhere, and
that I knew was next to impossible; One server was, so expect it is.
- Perl was another favorite, but the same problem applies as per
rdist here (plus I'd have to learn Perl, which I still want to do,
just too durn many things going on, argh). A couple of people also
suggested a csh/sed/awk combo, which I've considered but was a bit
unwary for me (again, not enough time -- I've got too many other
major script projects).
- Some folks are curious why I'm not using NIS/NIS+ -- Well, I'd like
to use it too, make this tons easier :). The best explaination is
that the remote sites must have total network independence from our
LAN in case of a link cut -- There have been too many problems when
someone with a misplaced backoe just causes havoc (like that one
Big Game lottery state that lost connectivity yesterday...).
I can't thank everyone enough for responses; I'd mention them, but
it's durn near impossible to cut/paste addresses from Outlook
Express (No deadly looks please, I'm doin' this from home).
Now I need to get Expect installed and running; Wish me luck...
T. S. Kimball email@example.com
----- Original Message -----
> Good Evening all,
> I've got a rather big problem here; I've done what research I could,
> and turned up nothing...
> I've got an extremely large number of systems (500+ last I looked)
> scattered all over several remote sites. Each system (all of them
> Solaris 2.x, primarily 2.6) has been configured to run standalone
> and not have any network dependancy with our local LAN (such as
> DNS, NFS, or NIS+), so the nsswitch.conf is basically nsswitch.files.
> This was done to keep each remote site running OK when some fiber
> gets dug out by accident.
> The downfall of this is that I now have 500+ servers with shadow
> password files, all of them to be updated (normally in this config-
> uration) by hand. I would obviously like to streamline the process
> so I can effectively update them faster, and also update them
> dependably. Doing a mass rcp/ftp of a new shadow file is out of the
> question, because the remote sites also have additional users from
> the base configuration, most of them unique to that site. The users
> I wish to update are common throughout most of the sites.
> So to sum up, I need a fast, reliable way to remotely update an
> /etc/shadow password on lots of servers -- without the use of NIS.
> I need to have a working solution for next week, so please send your
> suggestions (and any clarifying questions) to me direct. I'll happily
> Many Thanks,
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:07 CDT