Dave Nebinger <dnebinger <at> joat.com> writes:
> > OK on the local rsync server I added this to automate the daily > > 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: OK but can't I do that with a simple mode to the /etc/crontab ?: 30 1 * * * root emerge sync 2>&1 ? > 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 OK, I can try this script. I guess eix is an ebuild index & searching tool, that I need to read up on... This script is for the internal rsync/replicator server? > 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. OK, the port has changed. What's the deal about that? > > 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: OK, monthly on a manual basis. I'll try your script/email approach. > 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 OK thanks for the script. I'll have to study it, test it and let you know how it goes... > > 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. In the future I'll be distributing binaries to lots of old pI and pII systems, so that kind of automation will have to wait. > 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. ditto. > > 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. Well the simple cases are easy. What I need, including your scripts is to be in a single document. I'll write something, and you can look it over. That helps me fully understand what everything does, and provides a nice little document. I tend to 'dumb down' documents, so they are easy to understand.... I also include more background material so novices and seasoned persons can use them. > > 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. Agreed. But I intend to set up a test-quarrantine system that is fully automated, and if all goes well for (1) 24-hour period, then push the updates to a bunch of PI and PII systems for a bunch of kids (hoodlums.... some of which are mine.) Thanks for the help and scripts... James -- gentoo-user@gentoo.org mailing list
