On 04/16/2012 04:43 AM, Christopher Brown wrote:
> Hi,
>
> My apologies if members don't consider this list appropriate, if so
> perhaps a more appropriate forum could be suggested.
>
> I am using scientific linux 6.2. I will be installing it on 4-5
> computers that will make up my lab. I plan to add some additional
> packages from source or otherwise:
>
> /opt/python2.7
> /opt/python3.2
> /opt/libreoffice3.5
> /opt/zotero3.0
> /opt/qt-4.8.1
>
> ...and a few more plus a number of python2.7 packages such as numpy,
> pyqt, etc. I have my environment setup pretty well on one machine with a
> bash script I wrote to download make and install all the packages I
> need. It also sets up a decent /etc/skel/, so that global settings are
> set for all users. I would like all the machines to be identical, and I
> would like to be able to update packages automatically. My question is,
> what is the best way to deploy and maintain this environment onto
> several networked machines? Setting up my own repo seems like a lot of
> overhead for a few machines. Is there a better way? I could go around to
> each machine with my bash script, but what would the best way be to
> handle updates? I am willing to learn about repository management if
> necessary, but obviously the less effort/knowledge required the better,
> as I am a relative novice at system administration. Thus, any
> suggestions will be appreciated.
>
> Thanks, Chris
>

Without getting too deep into maintenance burdens you could create a 
private repo that contains only the extra packages you want installed, 
and include it in your yum repos.

This does require that you have rpms of the packages you want, but if 
you are building a package from source anyway, making an RPM from it is 
pretty easy and makes maintenance a snap -- which figures, since this is 
the very problem RPM was designed to solve in the first place.

As long as your repo contains packages that are unique, don't conflict 
directly (by redirecting "python" to mean "python3", for example) or 
indirectly (by upgrading a library in-place to a new version 
incompatible with existing packages) with SL 6.2 then you have nothing 
to worry about.

In this list LibreOffice and Python 3 are the only items that you need 
to be careful with (I think qt4.8 is a safe upgrade to SL's 4.6... anyone?).

	Python:
Make sure Python 3 is done the same way Fedora does it: "python3" == 
Python 3.x, and "python" == python 2.6/2.7. Other than this Python isn't 
a problem.

	LibreOffice:
This one can induce a system-wide overhaul depending on how it is built 
(static VS dynamic linking, etc). Most likely you are using LibreOffice 
project rpms, which are statically linked and not updated every time a 
dependent library is updated. They also don't provide a repo, but you 
can download and sign their rpm and include it in your repo instead. 
Just always keep in mind that to update all of your systems you will 
need to download the latest LibreOffice rpm, sign it, and put it in your 
repo to update your other systems.

As far as repo managament being difficult: Its just not hard. At all. 
Someone mentioned Puppet, and that is a great tool, but when dealing 
with less than 20 or so systems, or three or more sites (my own biased 
guidelines, mind you) I find scripting and simple add-on repo management 
to be the best balance of time savings, as rpm, yum and createrepo are 
very easy to learn, and Puppet is pretty involved (but well worth the 
time spent learning it on large sites).

The things you need to know to run your own repo, including building 
your own packages, consist of (from memory, I might be slightly off here):

* (How to write a very basic RPM .spec file)
* (How to generate a public/private RPM signature key -- easy, and only 
needed once)
* (How to set up apache, nfs, rsync, ftp or any other method of exposing 
your repo location to the downstream systems -- also easy and only 
needed once)
* (What a repo directory layout looks like -- and this only matters if 
you are dealing with multiple architectures)
* rpmbuild -bs <packagename>
* mock --rebuild [<--arch>|<--target>] <src rpm>
* rpm --addsign <rpms>
* ln -s <a noarch package> <an arch repo location>
* createrepo -vpd <repo arch directory>

That's a pretty short list, considering the otherwise hairy problem it 
solves. There are complete build systems out there and of course 
scripting this process is straightforward (beyond dealing with your 
private signing key password), but I think a big build system like koji 
is way overkill and too much to learn and setup for just a few packages 
that'll take you a few minutes to build even on low-end hardware.

If anyone knows a shorter-cut way, it'd be great to hear it. Also, if I 
forgot any of this please correct me -- I've got my own rebuilds 
automated now beyond the point of .spec writing/patch inclusion, so I 
might be off a little on the manual steps.

Once your repo is set up, everything is pretty much just done. You need 
to update all the systems, just update the relevant rpm in the repo 
directory and run "createrpo" again, and all the other systems will get 
the change.

Hope this helps you make an informed decision.