> OK on the local rsync server I added this to automate the daily > task of rsync(ing) > # Rsync entries > # > 30 1 * * * root emerge sync
Unless you want to receive the daily email full of all kinds of funky characters, I'd redirect the output from emerge to a file. On my boxen I call 'dailysync.sh' from cron. The script has this: cornholio ~ # cat bin/dailysync.sh #!/bin/sh # # sync.sh: Script to handle the portage syncing. # emerge --sync 1>>/var/log/autosync.log 2>&1 # Update eix and edb... if [ -e /usr/portage/profiles/default-linux/x86/2005.0/make.defaults ] then echo Not recreating make.defaults, it exists... >>/var/log/autosync.log else echo Recreating make.defaults... >>/var/log/autosync.log ln -sf ../make.defaults /usr/portage/profiles/default-linux/x86/2005.0/make.defaults 1>>/var/log/autosync.log 2>&1 fi eix -u 1>>/var/log/autosync.log 2>&1 eupdatedb 1>>/var/log/autosync.log 2>&1 cornholio ~ # The if/then logic is needed because eix expects a <version>/make.defaults file, but the make.defaults has been pushed up one directory level. The emerge --sync wipes the file out so I have to recreate it before updating eix. And the output from the script goes to a log file rather than stdout/stderr (so when run via cron no email is generated). > OK, now I use document (C) to create the proxy entry on each client: > Editing File: /etc/env.d/99local to look like this > http_proxy="192.168.2.9:8080" > instead of this > http_proxy="proxy.server.com:8080" > > I check it on the client by issuing "echo $http_proxy" > which give the correct results: > 192.168.2.9:8080 > > So far so good??? Hmm, the documentation might have changed since I did my setup. My internal boxes have 'http_proxy=http://192.168.0.1:8084' directly in the make.conf file; I didn't make any changes to /etc/conf.d/local.start for the http proxy. > and last run this daily on the server to keep it current? > emerge -uDva world && repcacheman Well if you have the time and inclination you can do it daily. Once you get into maintaining the system you'll realize that this kind of attention to the box is frequently overkill - a working box is a working box and there is no need to fix what isn't broken. Rather than do this on a daily basis I generate a daily email of packages to be updated; if I see one I feel is critical I'll deal with the update otherwise I'll let the system go for awhile. The script I use for this is: cornholio ~ # cat bin/updatereport.sh #!/bin/sh # # updatereport.sh: Script to send an update report to root. # # # Remove the old report file. # if [ -e /var/log/update.report ] ; then /bin/rm -f /var/log/update.report fi if [ -e /var/log/update.rpt.txt ] ; then /bin/rm -f /var/log/update.rpt.txt fi # # Run the command to generate the output file. # emerge --pretend --update --deep world 1>/var/log/update.report # # Put a standard header at the top of the text file. # echo "Current gentoo update report." > /var/log/update.rpt.txt echo "" >> /var/log/update.rpt.txt date >> /var/log/update.rpt.txt echo "" >> /var/log/update.rpt.txt # # Extract a clean text file # strings /var/log/update.report >> /var/log/update.rpt.txt # # Mail the clean text file. # mail -s "Cornholio Portage Update Report" root < /var/log/update.rpt.txt cornholio ~ # > Anything I missed? Well sure. The part I should have mentioned is that if your systems are all similar in that they have the same hardware and same use flags, package installs, etc., then you might want to have one system build binary packages for distribution to the internal systems. That way you only suffer the build once. Personnaly I've got different architectures (PIII, P4, and AMD) mixed in and, as each system has a different purpose they typically don't have similar use flags or package installations, so a binary package distribution doesn't work for me. > Surely parts of all (4) documents belong in one master howto? I'm sure it could but there's probably folks on the other side of the fence that only want a local rsync mirror or a local portage download cache and not both. > Is there a script to update workstation systems, automatically, > say 10 minutes after booting? How best to do this? Sure. Generate a script that sleeps for 10 minutes then kicks off the emerge process. Call the script from /etc/conf.d/local.start (be sure to include the & to spawn it in the background) and you're golden. However, you need to consider if this is something that you really want to do. Automated updates are frowned upon by folks on the list. I tend to stagger my system emerges because I use distcc. The individual boxes have a smaller time impact handling the package recompiles. -- [email protected] mailing list
