Properly update packages or rollback

S

Sebastian

Hello friends,

I am using pkg to install my software. From time to time $app gets an update and something breaks. What are your ways to rollback to the $old_app_version ?

In my setup nearly everything is isolated in a jail .
One approach for me is

snapshot the jail
run pkg upgrade
if the new code is unstable , I revert to the old snapshot and everything should run as before.


But in reality sometimes I just don't do the snapshot and then I have a broken application. Often I can't uninstall the software an go back to the old version , because it was removed from the pkg mirror ? What I mean by that is, pkg install app_oldversion is not there anymore.

Is there a way to download the dependencies and secure and store them on the day I have installed it ? That way I can always go back to the old version.

thanks for your comments !

best regards , sebastian
 
Sebastian said:
What are your ways to rollback to the $old_app_version ?
Click to expand...
I build my own repositories. So it's quite easy to rollback a certain change on a port without affecting anything else.

Sebastian said:
Is there a way to download the dependencies and secure and store them on the day I have installed it ?
Click to expand...
Downloaded packages are cached in /var/cache/pkg. There's a big downside to keeping old packages around though, those packages are going to have old dependencies too. So you're going to have lots of dependency chain issues.
 
Hem, don't forget to make a snapshot? Or write a script / install software that does snapshots automatically?

I think it's making your life harder to have jails just for isolating softwares. The intended use is rather security.

I have a few jails and from time to time, I update their softwares (when a vulnerability is corrected), all jails at once with a script that does:
- Delete previous snapshot.
- Create new snapshot.
- pkg upgrade.

Simple, isn't it ?
 
manual backups/snapshots are de-facto non-existent. automate them.

I'm using sysutils/zfsnap2 everywhere. datasets/jails that hold important and/or often/fast changing data are snapshotted as often as every 5 minutes on some systems. With a lifetime of only a few hours, they won't take up much space, but can *really* save the day.

a typical crontab for zfsnap on my hosts may look like this:
Code: 
# cleanup
00  */1 *   *   *   /usr/local/sbin/zfsnap destroy -r zroot
00  */1 *   *   *   /usr/local/sbin/zfsnap destroy -r vms_jails
00  */1 *   *   *   /usr/local/sbin/zfsnap destroy -r filesrv

# zroot snapshots
25  1   *   *   *   /usr/local/sbin/zfsnap snapshot -a 4w -r zroot
30  1   1   *   *   /usr/local/sbin/zfsnap snapshot -a 3m -r zroot

# jails
00  *   *   *   *   /usr/local/sbin/zfsnap snapshot -a 2d -r vms_jails/iocell
30  3   *   *   *   /usr/local/sbin/zfsnap snapshot -a 2w -r vms_jails/iocell
00  4   *   *   *   /usr/local/sbin/zfsnap snapshot -a 2m -r vms_jails/iocell

# git repos
00  *   *   *   *   /usr/local/sbin/zfsnap snapshot -a 2d -r vms_jails/git-repositories
30  3   *   *   *   /usr/local/sbin/zfsnap snapshot -a 2w -r vms_jails/git-repositories
00  4   *   *   *   /usr/local/sbin/zfsnap snapshot -a 2m -r vms_jails/git-repositories

# filesrv
*/10 *  *   *   *   /usr/local/sbin/zfsnap snapshot -a 3h -r filesrv
00  *   *   *   *   /usr/local/sbin/zfsnap snapshot -a 2d -r filesrv
30  3   *   *   *   /usr/local/sbin/zfsnap snapshot -a 2w -r filesrv
00  4   *   *   *   /usr/local/sbin/zfsnap snapshot -a 2m -r filesrv


For bigger upgrades on jails I usually clone the jail, perform any upgrades in that clone and if everything looks good I shutdown the old jail, promote the new one and restart it with the IPs of the original jail. This also minimizes downtime to only a few seconds.

If there are problems with actual versions of some ports (or they have been removed / build errors) you are best off with your own repository as SirDice already mentioned, or at smaller scale, building them from ports and if necessary git revert the commit that updated (or removed) this specific port.
If using such an approach you should be very *VERY* careful with mixing these self-built packages with those from the official repositories - this can lead to a completely unsolvable dependency hell and wreak havoc on future updates.
 
It can be a LOT of work to set things up to work properly... end to end.

As an example, I want to be able to upgrade just KDE, compiled with my own options, and not be a slave to the release schedules. Just learning the ports framework took me awhile, then I had fun setting up Poudriere. (I had to set that project aside, stuff irl demanded my attention). I actually got a lot of components working right, but I'm nowhere close to being done.
 
astyle said:
Just learning the ports framework took me awhile, then I had fun setting up Poudriere.
Click to expand...
For me it was a little easier, but I have been building my own packages since 4.0, when jails got introduced. Back in those days I would set up a clean jail and start building everything I needed by hand ( make package-recursive) in that "build" jail. So I was already quite familiar with ports and packages. Using poudriere to automate the process was simply the next logical step.
 
You must log in or register to reply here.
Back
Top