Earlier quoted context omitted.
Hopefully an upgrade too, as an update alone wouldn't do anything.
So, do you guys not know what you're talking about is there some legitimate reason for downvoting this? Please, by all means, `update` to your heart's content with aptitude. It won't do a damn thing, but OKAY.
Ask HN: How do you manage your *nix binary package updates? (first post. eek)
21–24 of 24 posts
Re: Ask HN: How do you manage your *nix binary package updates? (first post. eek)
#22Earlier quoted context omitted.
So, do you guys not know what you're talking about is there some legitimate reason for downvoting this? Please, by all means, `update` to your heart's content with aptitude. It won't do a damn thing, but OKAY.
Yes, I meant upgrade. I mistyped. I assume the reason for the down-voting is that it was a petty point and it was clear what I meant.
Re: Ask HN: How do you manage your *nix binary package updates? (first post. eek)
#23You can do two things. 1. Mirror a yum repository plus updates. For each day create a hardlinked directory of updates named reponame.YYYYMMDD. On the hosts you wish to update sed -i to the new day in your yum repo config file and run yum -y upgrade. When you know it works, do it on the other hosts too. 2. Use a configuration management tool like Puppet. For your sized infrastructure you probably want the first.
Re: Ask HN: How do you manage your *nix binary package updates? (first post. eek)
#24I used to manage around 300 servers myself. The only way it was possible was to have a completely stripped OS. All apps we used I installed under: /apps/ / example: /apps/perl/5.8.12 then I would symlink /apps/perl/5.8.12 to /apps/perl/current The profiles on the machine would add /apps/*/current/bin to the path. This allowed upgrades and roll backs just by changing the symlink to the one I wanted to be current. This…