[gentoo-user] Re: rsync internal mirror configuration

[James <wireless@tampabay.rr.com>]

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