BT's BIG Gentoo Project. - Page 8

i've "enjoyed" gentoo 5 times now. LFS will not be comig my way a while longer, and i dont like slack very much. anyway. as of right now, installing gentoo yet again, getting quite good at it, its not the install, but the post-intall config where i fudge something up or just quit. regardless, if i can get a good gentoo running, i'll be sure to stick with it.

on a side note:

how do you setup a usplash like on the livecd?

Hmmm. I started with SLS and migrated to Slackware soon after. My current foray into Linux comes on the heels of FreeBSD and Solaris and DOS/XP .

PClinuxOS so nice, I am tempted to jump to KDE -- but it does not support my SATA 9750. Ubuntu is alien, but close enough. Gentoo is too far from my experience base for the amount of time I have. I plan to take it for a spin again when the new version comes out.

LOL, you spoke too soon; the Gentoo team just released 2006.0: http://www.gentoo.org/news/20060227-release-2006.0.xml

Heh crud, I suppose that means I should update my portage and let it start goin on the update...

Ah well.

Personally for people coming into Linux I still reccomend a distro like Ubuntu first as you are first starting to get used to the environment and learn the basics, but then Gentoo will really teach you what you are really doing if you want to be better at linux.

Seablade

I've been running gentoo for several years now, and here's the way I personally do it. Basically, I have a script 'osupgrade.sh' that performs the following:

emerge sync
emerge -uDv system
emerge -uDv world
emerge -v depclean
revdep-rebuild
eupdatedb

NOTES:
I prioritize security over stability. (I'm willing to accept small breakages in order to maintain the latest patches. Big breakages should never happen in the stable branch. right?)

I cron this to run daily. (remember - it's not paranoia if they really are out to get you. And they are - I think!)

I separate the system & world updates so that I can notify differently. (If a system build crashes I get an alpha-page, world build failure only generates an email. This is dependant on the system - my firewall pages all failures.)

The depclean is the dangerous one. !!!Heed the warning message!!! That being said I've only had it bite me once. But in that case it decided that over half my system was unused dependencies and removed them all. UGH!

revdep-rebuild is necessary after the depclean, don't skip it.

I separate & dump the output of all the commands into /var/log/osupgrade/xxx.log logfiles and use logrotate to keep 30 days worth.

If any of the steps fail, I make a backup of /var/log/emerge.log

If there are config files to update, my script generates an email.

I handle config files with dispatch-conf. (make sure and install RCS and activate it in the dispatch-conf config file. And use the CONFIG_PROTECT_MASK variable in /etc/make.conf to limit the configs you want protected.)

eupdatedb updates the esearch database. esearch is a LOT quicker than 'emerge -s' -- you should use it if you're not already.


Is the above overkill?? Maybe. But once it is in place and running, I only interact with it once a week or so to handle the config files.

If you are maintaining multiple servers you should look into setting up a central machine that syncs & builds and then install binary packages on the others.

If you're really interested in security look into hardened gentoo. Right now I use Xen and my dom0 & firewall partitions are running hardened gentoo w/SELinux. At the minimum try something like Bastille.


troymc

Unlike troymc, I take the more conservative approach. I don't even let the system upgrade the packages automatically, let alone do depclean.

I have a cron job with the following script running every night at 3am:

This gives me a "what's new" email in my mailbox every morning:

Then, when I see that there are important things to merge, I do so manually.

Perhaps I should somehow incorporate GLSA data into this.

I personally only rarely do depclean. It's not like I'm desperately running out of hard drive space; I would rather waste some (minimal) HD space than "automagically" break my system (although depclean has never broken things for me). When I do get around to it, though, I take time in double-checking dependancies of packages and most certainly run revdep-rebuild afterwards.

Hope this helps.

Mikhail

EDIT: Added GLSA check to the script & example output.

Precisely

To add GLSA checking, add this after "emerge_sync >> $tempfile" in the script above:

EDIT: Patched the script above.

Longest Linux Thread Ever!

Hey, thanks for mentioning this! I didn't even realize this was functional yet. I'm going to implement this in my script, too.


troymc

Enjoying my new 9750!
Sager 9750-V | AMD A64 FX-60 | 17" WUXGA LCD | nVIDIA GeForce Go 7800 | 2048MB 400DDR | 2x 100GB 7200RPM SATA | 8x DVD+- combo drive with DVD+R DL | 802.11g wireless + Bluetooth | 3 Year Extension w/ Onsite

How long have you been doing this?

Doing daily syncs, I've had portage break twice over a space of about 3 years. I don't autosync either, and I rarely apdate Gentoo except when I'm using it, which I only do occasionally. It's a real pain when it happens because then I have to go online and look through the forums to figure out what package broke the system. Then hopefully there are instruction for d/l'ing and fixing it manually. That's why I think something like mmarkin's script is a good idea. When it does happen, they usually have updated packages available the next day.

2 1/2 - almost 3 years.

Keep in mind these are stable machines, not my laptop or workstation that I'm constantly mucking about with. I very rarely add or change software or bounce the box. It's basically the same set of packages that's been running on there stable for the past several years. My last downtime was 173 days ago - that was to put in a new kernel and update Xens' hypervisor.

I just checked my server logs, it upgraded 1 package yesterday - pango. If something is broken I know *exactly* what it is, and it will take me <10 mins to back it out. And after checking my emerge.log, that's pretty much the norm - maybe 1-2 packages a day.

In a production environment small changes are the rule - it keeps things very simple.

Waiting and upgrading everything at one time is just begging for a headache.


troymc

That is an important reason why I do what I do. Unless there is anything important to merge, I usually let things slide for a few days. This lets me find a timeslot in which I could verify a successful update of some big/important packages. Especially on Gentoo where everything is custom and just the way we want it, there is no way to fully test integration of packages. Hence, things break every once in a while, so you have to keep an eye out. Oh and even if the merges are automated, you still have to interactively update the configuration files; skip that and you'll be entering a world of sh--. The only way I can see a server surviving automated updates is if you only selectively and rarely restart updated services. But if you do that, you might as well skip updates alltogether! (E.g. what is the point of having the latest security patches if the currently executing binaries are a few months old?)

I run etc-update and look at each diff that it can not resolve automatically (i.e. non-trivial merges). Based on what I see, I either let it rip (i.e. files I know I've never touched myself) or keep the old config (and possibly make changes myself). This is something you get used to; I admit being nervous at first.