-------- Original Message --------
Subject: [gentoo-user] How to admin a multiple Gentoo Installation (and keep your sanity)
Date: Sat, 15 Mar 2003 16:55:09 +0100
From: Andrea Barisani <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Hi to all!
After having migrated from RedHat Linux to Gentoo on my network (35 hosts + 4 servers, approx 300 users) I would like to share and discuss my experiences in handling multiple Gentoo systems installations. This is nothing special for all the sysadmin out there, however I hope to stimulate discussion and hear how you manage such installations.
- Scenario
35 client hosts used by our students handled by a central server, three different architectures: k6 (400 Mhz), p1 (200 Mhz), p4 (1,7 Ghz).
- Primary objectives
1) have a centralized control of all clients installation and administration 2) find a proper way to optimize the installation on slow machines (p1 and k6) 3) give the users always the (almost) latest versions of all packages
Of course Gentoo was the answer :) and since it performs so well on our servers we have decided to test it and eventually migrate all clients. (with Gentoo performance on slow hardware has _really_ improved)
- Description
The system is composed by the 35 hosts and a central server that compiles and propagates all packages to the clients, this is done by having 3 different installations (one for each arch) in three different directories on the server, packages are built with the '-b' option and then copied and installed with 'emerge -k' on the clients. Packages and configurations propagation is all done via rsync.
Let's see some details:
On the central server we got:
/dist/k6 /dist/p1
/dist/p4
untar stage1 and bootstrap and compile the desired installation in each
directory with the proper arch-dependent optimizations. Since the server is a Gentoo installation I've used a single /usr/portage:
mount -o bind /usr/portage /dist/k6/usr/portage mount -o bind /usr/portage /dist/p1/usr/portage mount -o bind /usr/portage /dist/p4/usr/portage
Put any global modified/added file in /dist/adm/GLOBAL/, for example:
/dist/adm/GLOBAL/etc/fstab /dist/adm/GLOBAL/boot/grub/grub.conf /dist/adm/GLOBAL/usr/kde/3.1/share/config/kdm/kdmrx
...and so on
Put any arch-dependent modified/added file in /dist/adm/ARCH/, for example:
/dist/adm/ARCH/k6/etc/make.conf /dist/adm/ARCH/p1/etc/make.conf /dist/adm/ARCH/p4/etc/make.conf
...and so on
Put any host-dependent modified/added file in /dist/adm/LOCAL/, for example:
/dist/adm/LOCAL/host1/etc/conf.d/net /dist/adm/LOCAL/host2/etc/conf.d/net
...and so on
Then put all clients hostnames divided by arch in k6.list, p4.list, p1.list and put every hostname in all.list.
Now you can sync each configuration with the following scripts. The first argument is the arch (es. ./rsync-adm k6). These are not
the real scripts, only the core part is shown, I've omitted arguments
verification and some debugging 'echo' :).
rsync-adm: /usr/bin/rsync -vrlptgoD --progress /dist/adm/GLOBAL/ /dist/$1/ /usr/bin/rsync -vrlptgoD --progress /dist/adm/ARCH/$1/ /dist/$1/
rsync-host:
for i in `cat /dist/$1.list` ; do
/usr/bin/rsync -vrlptgoD --progress -e ssh /dist/adm/GLOBAL/ [EMAIL
PROTECTED]:/ ;
donefor i in `cat /dist/$1.list` ; do
/usr/bin/rsync -vrlptgoD --progress -e ssh /dist/adm/ARCH/$1/ [EMAIL PROTECTED]:/ ; /usr/bin/rsync -vrlptgoD --delete --progress -e ssh /dist/$1/packages/ [EMAIL PROTECTED]:/packages/ ;
# my PKGDIR is /packages done
for i in `cat /dist/$1.list` ; do
/usr/bin/rsync -vrlptgoD --progress -e ssh /dist/adm/LOCAL/$i/ [EMAIL
PROTECTED]:/ ;
doneNow on the clients you can mount via NFS in read-only /usr/portage. However the subdir /usr/portage/distfiles/cvs-src must be writable, a way to manage this is creating /tmp/portage and use /usr/portage/distfiles/cvs-src as a mounting point:
mkdir /tmp/cvs-src ; chown root.portage /tmp/cvs-src ; chmod 4770 /tmp/cvs-src mount -o bind /tmp/cvs-src /usr/portage/distfiles/cvs-src
Now packages update and installation can be done like the following:
# emerge sync # chroot /dist/p4 # emerge -b -u --deep world # emerge distcc # exit # for i in `cat /dist/p4.list` ; do ssh $i 'emerge -k -u --deep world' ; done # for i in `cat /dist/p4.list` ; do ssh $i 'emerge -k distcc' ; done
- Caveats
openoffice-bin must be installed on the clients, it doesn't work with -b and -k, I don't know why however I'll investigate, same problem with mplayer.
- Notes
The first idea was maintaining only /dist/arch installations and directly rsync that tree on the clients, however on slow hardware this is really slow and the exceptions (/var, /etc/mtab..etc) are too difficult to manage.
Hope that someone might find this useful, I'll be happy to hear your comments.
Bye :)
--
------------------------------------------------------------
INFIS Network Administrator & Security Officer .*. Department of Physics - University of Trieste /V\
[EMAIL PROTECTED] - PGP Key 0x8E21FE82 (/ \)
---------------------------------------------------- ( )
"How would you know I'm mad?" said Alice. ^^-^^
"You must be,'said the Cat,'or you wouldn't have come here."
------------------------------------------------------------
-- [EMAIL PROTECTED] mailing list
Celestial Wizard wrote:
By boxes I mean both servers and SOE desktops.
Basically our "rules" are standard installs for roles. IE - Firewalls, File and Print (not many), Web Application, Database, SOE Desktops etc...
On these boxes we also dont install compilers or other development tools (unless of course its a development server / workstation).
One way to look at this is as images - but not :)
What we want to do is replace our RedHat boxes with Gentoo (for new installs) due to the EOL announced.
What I am thinking is something akin to the following
- Point each remote box to our "image" server (or for deskops possibly one out at the client site) to sync a portage tree. (do we just expose /usr/portage via rync?) - However what we want to do when we run an emerge [system|world] is to get binaries instead of source. I've read that you can emerge a binary with a -K but haven't played with it yet. - Our distribution server would keep the packages upto date, mostly by hand at the minute, but someway to separate USE (etc...) settings for different "profiles" would be nice
What would be involved in doing something like the above?
Andrew Hatfield Systems Engineer - RHCE
-- [EMAIL PROTECTED] mailing list
-- [EMAIL PROTECTED] mailing list
