Deploying Red Hat Workstations

[Douglas Furlong]

On Wed, 2004-03-17 at 16:49, Christopher Ness wrote:
> On Wed, 2004-03-17 at 08:54, Chris Purcell wrote:
> > > Why not create a local "up2date" server on your LAN that will only hold
> > > the packages you want your machines to have.  I'm assuming you want them
> > > all to be the same, correct.  Then set up2date to update automatically
> > > from the 'up2date' local server.  Very little outgoing network traffic
> > > and you control the packages/versions.  Seems good to me.
> > >
> > > I'm not sure how to set up an "up2date/yum/apt-get" server but maybe
> > > someone else has some experience.
> > 
> > 
> > I was thinking about creating a central apt-get server.  You don't think
> > it will be too messy to install RPMs for every change I want to make?  For
> > example, lets say that I simply wanted to add a single Perl script to
> > /usr/bin, for example.  I would have to create an RPM package for that
> > single Perl script.  Do this even matter?
> 
> That's a fair question.  Do you use DHCP or static IP's.  In static IP
> land you are laughing because you can keep a text file of all the
> machines you monitor.

You don't even have to do that, if you use DHCP you can tell the clients
to update the DHCP server with it's hostname, then you can do all
resolution with hostname. Assuming we used the "push" approach.

> Use the IP information to write a simple shell script that will `scp`
> the file to the boxes (yes this means setting up a system account [don't
> use root!] and keeping logins the same on all the boxes.  GUARD THIS
> PASSWORD WITH YOUR LIFE).   Be sure to change the system box passwords
> regularly and use a STRONG PASSWORD.  There may be a better way, but
> this is all I can come up with right now.

This does not make too much sense, if you were to do it this way, the
best option is to set up an SSH key for your local user, add it to the
users key ring, on the remote side, what ever user you wish to log in
as, in the ~/.ssh/authorized_keys file, put in your public key. There is
then no password needed other then at the time of adding the ssh key to
your local keyring. The passcode of this can be as long as you want
(mine is 30+ characters).

Leaving this aside.

I do think the best solution would be to create updated RPM's with your
changes that you need made, and then run yum or up2date to update the
local box's.

If you do this, then you essentially have versioning by the RPM
packages, and if some thing goes really wrong, just role back to the
previous RPM version.

If you don't want to do this, would it not be possible to have one cron
scrip that gets the file and then runs it, why do you need two of the
little blighters?

Doug