RE: [gentoo-user] Re: rsync internal mirror configuration

[Dave Nebinger]

> > I've been considering adding an "emerge --fetchonly" line to the script
> but
> > don't yet have the warm and fuzzies about the http-replicator script.
>
> Yes, well I'm going to go slowly with this
> until I have the warm feeling and some
> happy experience over time.
> I'd be interested in keeping up with your scipt enhancements.
> If it's not too much trouble, when you are happy with
> some enhancements, send them to me for testing....

Sure, but I don't have any plans for updates in the near future.  They all
seem to be functioning well enough for my intents and purposes.

> > They've been working out great for me.  I've recently added a
> > 'revdep-rebuild' script so I can be reported of packages in need of
> fixing
> > (in case I miss the step manually).
>
> Can you send me a copy of that script or post it to this thread?

Sure.  It's nothing fancy, but does the job.  The biggest headache is the
gentoo script developers expectation that the only time you're going to call
their script is when you're sitting at a color-supporting terminal.  When
trying to build an email message all of the color-coding crap still seeps
through.  If I could get them to do anything it would be to add a common
"--nocolor" command line argument to disable that stuff.

cornholio ~ # cat bin/revdep.sh
#!/bin/sh
#
# revdep.sh Script to report on revdep/rebuild tasks.
#

# Remove existing files.
/bin/rm -f /root/.revdep* >> /var/log/revdep.log 2>&1

# Now do the revdep stuff
revdep-rebuild -p > /var/log/revdep.rpt 2>>/var/log/revdep.log

# now mail the report to root
strings /var/log/revdep.rpt > /var/log/revdep.txt
mail -s "Cornholio revdep report" root < /var/log/revdep.txt
2>>/var/log/revdep.log

cornholio ~ #

> > In your case I'd probably ensure the kids logins are typical user logins
> (no
> > update capability).  Run the scripts (or similar scripts) to automate
> the
> > syncing and reporting.  Keep ssh running on their systems.  Hold off on
> > updates until they run into something that breaks or until a critical
> > package update is released.  Then you can ssh in and emerge stuff until
> it
> > works.
>
> I'll take this under consideration. My purpose in extending automated
> updates, is to be able to manage a large number of embedded gentoo
> devices in the future.  Roll-back and Recovery mechanism will be
> added later. Besides Gentoo needs to leave the laboratory
> (purvey of experts) and enter the world of normal humanoids. That will
> force the Gentoo community to make Gentoo a commodity technology for
> the world's normal folks.....gentoo's destiny in my opinion.

Oh, I'd tend to disagree.  Source-based distributions IMHO would be a huge
pain in the neck for those responsible for a large number of systems.  Twer
it up to me I'd be using a binary-based distro such as suse or redhat; let
them work out the kinks so I wouldn't have to.

I prefer running gentoo because I have total control over the box.  Downtime
at home simply means I can't surf or receive email; it also means that I
have some good old down and dirty work ahead to get the box back up, which I
enjoy.  It's also a hassle that only I have to deal with, not a whole floor
of workers sitting idle waiting for the problem to be resolved.

But to be an admin over an office full of gentoo systems?  Not sure I'd like
that or that they would pay me what it would take to keep it functional.
Unless, of course, all systems were exactly the same (hardware and software
installations) and the users had minimal permissions to the systems (i.e.
they could only write files to their home directories and nowhere else on
the system, including /tmp & /var/tmp).




-- 
gentoo-user@g.o mailing list