This is less than ideal, but seems to work.
What do you do?
Note; I'm talking about binary packages distributed by your OS : apt upgrades / rpms.. not config files (Hi, puppet/chef), or deprec for capistrano style stuff.
1–10 of 24 posts
This is less than ideal, but seems to work.
What do you do?
Note; I'm talking about binary packages distributed by your OS : apt upgrades / rpms.. not config files (Hi, puppet/chef), or deprec for capistrano style stuff.
/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 also allowed me to push out versions of software ahead of time, and they just change the link when we were ready to use it.
Each machine would rsync /apps from a master distro nightly and of course I could force it with a for i in `cat hosts.list`...
If you want to tightly control the packages that get updated then there isn't much to be done other than manually managing your own repo. Although if it is this big of a concern you should probably be running a distribution that is less volatile than Ubuntu. Say RHEL, CentOS, or Debian.
Isn't this what people run their own apt mirrors for?
Depending on the release and the kind of server we're deploying to, we may do them all in one night or in batches of a few hundred over a week. All our boxes install security updates regularly (because we promptly add security updates to our dists.)
We manage our own dists. We package our own software as .debs, so everything gets managed the same way. All security updates, release deployments, rollbacks, etc., are managed with apt-get. I don't exactly understand pinning, but it's also important to how we manage packages. Depending on the release and the kind of server we're deploying to, we may do them all in one night or in batches of a few hundred over a week.…