I really like Ansible and I’m totally going to see if I can use all or part of this tutorial.
I bothers me a bit that updating OpenBSD 6.3 -> 6.4, per the official documentation, requires booting the installation media to preform the upgrade. In the world of could providers and VMs, I want to put together a guide to attempt to do this semi-inplace with a single reboot.
I’m glad I read all the release notes before attempting anything though. The OpenSMTPD configuration grammar has changed entirely. I’m going to have to redo all my work in a VM to make sure it all still works.
The big issue with “in place” upgrades in the OpenBSD world is that there is no guarantee the ABI between X.Y and X.Y+1 will be the same. This can cause all sorts of issues while doing in place upgrades. For example, tar, once replaced by the updated binary could segfault for every subsequent call. This would leave the system in an unknown state.
I wrote an upgrade tool a while back (snap) that could be used to upgrade from release to release. The ABI issue was hit every couple of releases, so I removed the option to upgrade releases.
I am not saying it’s impossible.. just that you will basically have to backup everything prior to doing an install.
Following -current a in-place upgrade mostly just works, but I also always keep a new bsd.rd ready in case in-place fails, reboot into bsd.rd and upgrade will fix it.
But I also have switched to a script that downloads sets, patches bsd.rd and reboots. Much less hassle and minimum downtime.
This. I do the same - download bsd.rd, add an auto_upgrade.conf file to the image, then use that bsd.rd on all my systems to upgrade them. Just copy the patched bsd.rd over /bsd on the target, reboot, wait a few minutes, and the box is back up on the new release. I wrote my own script ages ago, but nowadays the upobsd port can take care of the patching bsd.rd bit.
Back in the day, I just had a script that downloaded, extracted sets and install a new bsd. Then I rebooted it and ran another script that took care of etc changes and new users, cleanup up old files no longer needed (according to release notes). Last step was just a pkg_add -U.
I didn’t run into issues but I was aware of the risks and being on my own when it broke ;-)
I prefer (at least in the design phase) to think of all my computer resources as immutable. So an upgrade would actually be install new+verify+remove old, using something like Packer & Terraform.
Ansible is a less opinionated option, though, which makes it much easier to adapt in many cases. Perhaps it’s telling that I’ve dreamed for some time of building systems in an immutable way, but haven’t managed to yet… while the manually or Ansible-built hosts are serving production just fine.
I really like Ansible and I’m totally going to see if I can use all or part of this tutorial.
I bothers me a bit that updating OpenBSD 6.3 -> 6.4, per the official documentation, requires booting the installation media to preform the upgrade. In the world of could providers and VMs, I want to put together a guide to attempt to do this semi-inplace with a single reboot.
I’m glad I read all the release notes before attempting anything though. The OpenSMTPD configuration grammar has changed entirely. I’m going to have to redo all my work in a VM to make sure it all still works.
The big issue with “in place” upgrades in the OpenBSD world is that there is no guarantee the ABI between X.Y and X.Y+1 will be the same. This can cause all sorts of issues while doing in place upgrades. For example, tar, once replaced by the updated binary could segfault for every subsequent call. This would leave the system in an unknown state.
I wrote an upgrade tool a while back (snap) that could be used to upgrade from release to release. The ABI issue was hit every couple of releases, so I removed the option to upgrade releases.
I am not saying it’s impossible.. just that you will basically have to backup everything prior to doing an install.
Following -current a in-place upgrade mostly just works, but I also always keep a new bsd.rd ready in case in-place fails, reboot into bsd.rd and upgrade will fix it.
But I also have switched to a script that downloads sets, patches bsd.rd and reboots. Much less hassle and minimum downtime.
This. I do the same - download bsd.rd, add an auto_upgrade.conf file to the image, then use that bsd.rd on all my systems to upgrade them. Just copy the patched bsd.rd over /bsd on the target, reboot, wait a few minutes, and the box is back up on the new release. I wrote my own script ages ago, but nowadays the upobsd port can take care of the patching bsd.rd bit.
There is such a guide in the official upgrade notes. The only reason it suggests two reboots is KARL.
Back in the day, I just had a script that downloaded, extracted sets and install a new bsd. Then I rebooted it and ran another script that took care of etc changes and new users, cleanup up old files no longer needed (according to release notes). Last step was just a pkg_add -U.
I didn’t run into issues but I was aware of the risks and being on my own when it broke ;-)
I prefer (at least in the design phase) to think of all my computer resources as immutable. So an upgrade would actually be
install new+verify+remove old, using something like Packer & Terraform.Ansible is a less opinionated option, though, which makes it much easier to adapt in many cases. Perhaps it’s telling that I’ve dreamed for some time of building systems in an immutable way, but haven’t managed to yet… while the manually or Ansible-built hosts are serving production just fine.