> > 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@gentoo.org mailing list
