Re: [gentoo-user] System maintenance procedure?
On Tue, 4 Dec 2012 16:30:33 -0800 Grant emailgr...@gmail.com wrote: My unattended daily system maintenance procedure is like this: layman -S emerge --sync emerge -pvDuN world emerge -pv --depclean eclean -p distfiles eclean -p packages And then attended like this: revdep-rebuild etc-update elogv emerge --depclean eclean distfiles eclean packages Am I missing any good stuff? - Grant I'd tweak the order of your attended run: emerge -DuN world emerge @preserved-rebuild emerge --depclean revdep-rebuild The logic is: Rebuild busted packages that portage already knows about (@preserved-rebuild), then get rid of oudated packages and finally revdep-rebuild to fix anything that --depclean broke. @preserved-rebuild is getting very good at what it does lately (supported in all recent portage version including stable IIRC), as is --depclean, so revdep-rebuild seldom finds anything to do these days. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] System maintenance procedure?
Grant wrote: I think you're right about that. Can I configure eclean to wait a certain number of days since a package was removed before cleaning it? Even if I only run it once per week, it could remove a package that was updated yesterday that I find out I need tomorrow. - Grant -t, --time-limit=timedon't delete files modified since time time is an amount of time: 1y is one year, 2w is two weeks, etc. Units are: y (years), m (months), w (weeks), d (days) and h (hours). Thanks Dale. I found that in man eclean. I'm sorry, I didn't consider a parameter like that for some reason. It actually has quite a few options. I rarely use them on my new rig but did on my old rig. My old rig is MUCH slower than this new one. Should it be alright to depclean every day? As long as I use --time-limit with 'eclean packages', I should be able to reinstall anything that depclean removes even if it's pruned from Portage. - Grant I run depclean about once a month after a large update, usually KDE, qt or something like that. I sync and update about twice a week. I try to time mine to hit those important updates to things like KDE or something. I'm actually waiting on KDE 4.9.4 to hit the tree now. It should be there pretty soon, if there is no major problems. I would set a rough update time schedule. If say you set yours to update every week, then keep two maybe three weeks of old packages. If a package can work for a few weeks, survive reboots and a couple updates, then odds are it is safe to remove the binaries you built for it. The sources, I usually only keep what I have installed. Most of the time that is enough. If you have the hard drive space, you can keep them like you do the binary package. If you pick a monthly update time frame, then adjust your time frame for old packages. You may can keep less of them depending on how you run your rig. When you use eclean and friends with no options, it seems to leave a pretty good set of binaries behind. It leaves what is installed plus a older version or two. It's been a while since i really looked into this but it seems to have a fairly safe setting when you just run the plain command with no options. When you use the -d option, it leaves only what you have installed and gets rid of everything else. The -d option is about the most aggressive option for eclean. This is just to give you ideas. This is one of those 'it depends' questions. The technically correct way is to run depclean after each full update. Thing is, I doubt it will hurt anything if you leave them on there except for taking up drive space. Just don't forget to update the configs after each update. Sometimes missing those can lead to a system that won't boot. It's not very likely but they do happen from time to time. Another thing about my system that may help you, I keep a copy of /etc and my world file backed up. When I reboot, which is not to often, I make a new backup of /etc. Right now, my uptime is almost 75 days. I keep that backup just in case something will only break when rebooting. Some config files are only read when booting so until you reboot, you don't know you have a problem. Having a copy of the world file is good in case you lose the drive with the OS on it. You can at least know what you need to emerge to get back to where you were. Hope that helps. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] gst-plugins-ugly Update Error install phase
Hello, On Sun, 02 Dec 2012 16:54:05 -0800 John Campbell jdc@cox.net wrote: Just try emerging it again. Thanks it was running. Regards Silvio
Re: [gentoo-user] System maintenance procedure?
On Tue, 4 Dec 2012 20:04:30 -0800, Grant wrote: The first depclean is redundant, you haven't updated anything so it won't show anything useful. I only run depclean and revdep-rebuild weekly,I don't see a need to routinely do it more often, especially on slower systems. I do run eix-update and eix-update-remote after my daily sync.I run eix-test-obsolete from the weekly cron script. I should have said that I'm emailed the results of the first set of commands so the first depclean is there to let me know what would be removed after yesterday's update. But you ran depclean manually after yesterday's update, so it should show nothing. -- Neil Bothwick CPU: (n.) acronym for Central Purging Unit. A device which discards or distorts data sent to it, sometimes returning more data and sometimes merely over-heating. signature.asc Description: PGP signature
Re: [gentoo-user] ssmtp alternatives: msmtp vs. dma
On 12/05/2012 01:43 AM, Grant wrote: I switched to msmtp when nbsmtp was treecleaned. The switch was uneventful; it just works, which is high praise. You can't encrypt your password unless you're going to be physically present to decrypt it (with some other password). If your machine is physically secure, you can just make the msmtp config file read-only to yourself. If someone can log in as you, they can get your password anyway. There's only a risk if e.g. you're not root, or someone else can get root (access to grub) or walk off with the hard drive. If you're worried about either of those scenarios, set up a separate account for your email alerts. I like the separate account idea. Any tips on locking it down? Maybe that account on the mail server should somehow only be allowed to deliver to a single email address (mine)? Would it need a shell account? Certainly not allowed in sshd_config. It depends on how you're authenticating. We've got our users in Postgres, and postfix uses Dovevot's SASL backend to auth. That way a user is just an email address/password combination and can't do anything except send/receive mail. The general defense against hacked user accounts is to do rate-limiting on the MTA with something like postfwd, and at least notify postmaster if someone begins sending hundreds of messages. That way if a user gets hacked, you find out about it and can disable them. In this case I wouldn't even worry about it. If someone can log on to your server and read the msmtp config, you've already got a big problem. The real benefit to using a separate account is that if that does happen, they can't see Grant's personal email password (which is essentially the keys to the kingdom). Another thing you might consider is getting added to the feedback loops of some major providers. When one of our users gets hacked, I find out quickly because AOL sends me a copy of every message that they get from us which is marked as junk. This is a Good Idea anyway, and mitigates the stolen-password problem in that unlikely event.
Re: [gentoo-user] ssmtp alternatives: msmtp vs. dma
Grant wrote: msmtp --passwordeval 'gpg -d mypwfile.gpg' Be careful with passing your password as a command line argument, because it will put your password into the output of ps. This would allow any user on the system to read your password. -- R
[gentoo-user] continue an installation
Hi list, Suppose that I tried to emerge a package, and the compilation phase went through without problems, but it got stopped in the installation phase. Is there a way to (after I fixed the problem) to tell portage to install the (now all already compiled binaries sitting in /var/tmp/portage) directly without having to redo the compiling phase? Case in point: I just tried to update dev-lib/boost to 1.52. The compilation went without a hitch, but the installation died because of file collision against (I think) boost-1.49.0-r1000. Now that the colliding files are no longer there, is there a way to tell portage to go ahead an install boost-1.52 from the compiled sources in /var/tmp/portage ? Thanks, W -- Data aequatione quotcunque fluentes quantitae involvente fluxiones invenire et vice versa ~~~ I. Newton
Re: [gentoo-user] continue an installation
On Thu, 6 Dec 2012 08:45:10 +0100 Willie WY Wong wong...@member.ams.org wrote: Hi list, Suppose that I tried to emerge a package, and the compilation phase went through without problems, but it got stopped in the installation phase. Is there a way to (after I fixed the problem) to tell portage to install the (now all already compiled binaries sitting in /var/tmp/portage) directly without having to redo the compiling phase? not with emerge, but you can use the lower-level command ebuild for that. portage ebuild are analogous to yum rpm or to apt* and dpkg man ebuild for more info Case in point: I just tried to update dev-lib/boost to 1.52. The compilation went without a hitch, but the installation died because of file collision against (I think) boost-1.49.0-r1000. Now that the colliding files are no longer there, is there a way to tell portage to go ahead an install boost-1.52 from the compiled sources in /var/tmp/portage ? Thanks, W -- Alan McKinnon alan.mckin...@gmail.com
