Re: Automatic OS updates
Kernels with just "OpenBSD 7.5" will appear for some time before pub/OpenBSD/7.5/*/packages are available. -- Sent from a phone, apologies for poor formatting. On 21 February 2024 20:36:39 Kirill A. Korinsky wrote: On Wed, 21 Feb 2024 21:11:05 +0100, Stuart Henderson wrote: If you're using sysupgrade -s, you also want -Dsnap in pkg_add. After double check in man it seems not nessesary, let me quote: %c Expands to the string "snapshots" when running a -current or -beta kernel, or if the command line option -D snap | -D snapshot is specified. Otherwise, %c expands to %v, which selects a release version. -- wbr, Kirill
Re: Automatic OS updates
Well, in a few weeks you will see why you need it.
Re: Automatic OS updates
On Wed, 21 Feb 2024 21:11:05 +0100, Stuart Henderson wrote: > > If you're using sysupgrade -s, you also want -Dsnap in pkg_add. > After double check in man it seems not nessesary, let me quote: %c Expands to the string "snapshots" when running a -current or -beta kernel, or if the command line option -D snap | -D snapshot is specified. Otherwise, %c expands to %v, which selects a release version. -- wbr, Kirill
Re: Automatic OS updates
On 2024-02-21, b...@fea.st wrote: > FWIW if you guys want to yell at me for spreading bad ideas, > I've posted how to do automatic updates here: > > https://openbsd.pages.dev/auto-updates/ If you're using sysupgrade -s, you also want -Dsnap in pkg_add.
Re: Automatic OS updates
On Wed, 21 Feb 2024 18:05:56 +0100, b...@fea.st wrote: > > FWIW if you guys want to yell at me for spreading bad ideas, > I've posted how to do automatic updates here: > > https://openbsd.pages.dev/auto-updates/ > > I'm both trying out the Hugo package and like, documenting > how I've set things up in case I have to reinstall. > > Time moves fast and I'm damn impressed by how smooth the > BSD experience is. > I suggest to add that regression may occure during an upgrade. And personally, bug fixing a nigth upgrade is not something that I prefer to do with morning coffee. -- wbr, Kirill
Re: Automatic OS updates
FWIW if you guys want to yell at me for spreading bad ideas, I've posted how to do automatic updates here: https://openbsd.pages.dev/auto-updates/ I'm both trying out the Hugo package and like, documenting how I've set things up in case I have to reinstall. Time moves fast and I'm damn impressed by how smooth the BSD experience is.
Re: Automatic OS updates
On 2024-02-20, obs...@loopw.com wrote: > > >> On Feb 20, 2024, at 2:31 AM, Thomas Schmidt >> wrote: >> >> OP did indeed mean `sysupgrade`, > > which makes little sense _unless_ on -current, which will guarantee to break > this every sixth months when -current shifts about. > >> but fwiw, `syspatch && reboot` reboots >> your system if a patch as applied. I got it in all of my servers' >> cronjobs. > > Most of the patches don’t require a reboot. Correct. Looking at the 7.4 patches, only 3 affect the kernel and definitely need a reboot to get applied: 002_msplit - requires reboot 008_vmm - requires reboot 009_pf - requires reboot Two where you don't really need to do anything other than apply the patch: 003_patch 004_ospfd (because, if you're affected by it, then things would be broken already) The rest don't actually need a reboot, but do need *some* things restarting if you're using them: 001_xserver 005_tmux 006_httpd 007_perl 010_xserver 011_ssh 012_xserver 013_unbound (Also: had there been fixes to libraries - libc, libssl, etc - they would be in this category too - you could figure out which long-running processes would need to be restarted and do that). However, considering the "*some* things need restarting" case, given what is available from syspatch, rebooting is the only reasonable way to automate making sure that anything needing a restart really is restarted. > This idea sounds horrible for uptime. Sorry. I’m not rebooting something > because a font was patched… There is a fairly high bar for a fix to get turned into a syspatch. Now, you might not be affected by every patched bug, and if you're updating manually then you can make that decision. But this thread is about automating, and the majority of syspatches do require processes to be restarted in order to take effect.
Re: Automatic OS updates
obs...@loopw.com wrote: > Most of the patches don’t require a reboot. This idea sounds horrible for > uptime. Sorry. I’m not rebooting something because a font was patched… syspatch outputs a message that the system needs a reboot. This could be parsed.
Re: Automatic OS updates
> On Feb 20, 2024, at 2:31 AM, Thomas Schmidt wrote: > > OP did indeed mean `sysupgrade`, which makes little sense _unless_ on -current, which will guarantee to break this every sixth months when -current shifts about. > but fwiw, `syspatch && reboot` reboots > your system if a patch as applied. I got it in all of my servers' > cronjobs. Most of the patches don’t require a reboot. This idea sounds horrible for uptime. Sorry. I’m not rebooting something because a font was patched… > > - Thomas > > Am 17.02.2024 um 02:24 schrieb obs...@loopw.com: >>> On Feb 15, 2024, at 10:12 AM, b...@fea.st wrote: >>> am I the only one using automatic OS updates >>> 0 3 * * * root sysupgrade >> Maybe you meant “syspatch” there? >> Syspatching via cron is questionable - Some of the patches wont be loaded >> until the box is rebooted. >> I think its better to run either syspatch or sysupgrade when i’m in front of >> the console and can deal with consequences.
Re: Automatic OS updates
OP did indeed mean `sysupgrade`, but fwiw, `syspatch && reboot` reboots your system if a patch as applied. I got it in all of my servers' cronjobs. - Thomas Am 17.02.2024 um 02:24 schrieb obs...@loopw.com: On Feb 15, 2024, at 10:12 AM, b...@fea.st wrote: am I the only one using automatic OS updates 0 3 * * * root sysupgrade Maybe you meant “syspatch” there? Syspatching via cron is questionable - Some of the patches wont be loaded until the box is rebooted. I think its better to run either syspatch or sysupgrade when i’m in front of the console and can deal with consequences.
Re: Automatic OS updates
On Fri, Feb 16, 2024, at 17:09, Jan Stary wrote: > And this saves you what, ten keystrokes a day? Yes, it felt silly typing the same things every day and waiting for the computer to update. (If an update takes 4 minutes per day to babysit, that's about 2 hours per month) On Fri, Feb 16, 2024, at 21:10, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > Blind updating out of cron is utter madness. If there are any merge > errors in /etc (think sshd_config for starters), you can end up > with a machine you cannot log in to, or that's just acting out > destructively. Yeah! But you guys are sysadmins, I'm basically a 'gamer', I mostly use my OpenBSD computer for an online game. Thus an upgrade problem mostly risks me being late for a 'war', which is not the end of the world. SSH not coming back up is a non-issue, I have screen and keyboard connected. (I'll probably turn off auto-updates when traveling tho as remote access is nice although non-essential.) I also have a second computer I can boot up if this one doesn't work.
Re: Automatic OS updates
On Thu, Feb 15, 2024, at 21:52, Florian Obser wrote: > > 0 3 * * * root sysupgrade > > This will stop working at the next release. Assuming you want to run -current. Thanks, changed to 'sysupgrade -s'. > >30 3 * * * root pkg_add -u > > This will most likely run after package daemons have started. There is an > example in upgrade.site(5) how to do this differently. Thanks, very helpful, now using /upgrade.site to update packages after sysupgrades.
Re: Automatic OS updates
> On Feb 15, 2024, at 10:12 AM, b...@fea.st wrote: > am I the only one using automatic OS updates > 0 3 * * * root sysupgrade Maybe you meant “syspatch” there? Syspatching via cron is questionable - Some of the patches wont be loaded until the box is rebooted. I think its better to run either syspatch or sysupgrade when i’m in front of the console and can deal with consequences.
Re: Automatic OS updates
On Fri, Feb 16, 2024 at 12:10:18PM -0800, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > At work I manage a herd of a dozen OpenBSD machines. We "upgrade" > by perforing a full network install. +1 All of our servers are upgraded the same way - fresh install, and restore the configuration and user data afterwards. It's perfectly doable, and this method has a lot of benefits.
Re: Automatic OS updates
Kevin Williams writes: > The main use case I see for this is to manage a fleet of more than 10 or > so machines/VMs/instances. rdist or a package such as Ansible could > manage the crontab and possibly search announce@ on marc.info for > keywords to hold off on the upgrade. Blind updating out of cron is utter madness. If there are any merge errors in /etc (think sshd_config for starters), you can end up with a machine you cannot log in to, or that's just acting out destructively. At work I manage a herd of a dozen OpenBSD machines. We "upgrade" by perforing a full network install. The process is pxe boot / fdisk / install / reboot / ansible (create the logins) / reboot / rdist / reboot / verify everything is running correctly (esp. pf), / reboot. The entire process takes 20 minutes per machine, so I can update the entire herd in < 1 day. Although we typically spread it over two or three days. All these machines run as carped a/b pairs, so we upgrade the b hosts first and run on them for a day or two to check for regressions, then upgrade the a machines and switch back to them. The primary reason for installing from scratch is to verify we have not introduced any bugs into the network installation and configuration steps, as this is a core part of our disaster recovery process. It also ensures we launch out of the box with up-to-date packages. And if the number of machines gets entirely out of hand, it should be simple enough semi-automate a good part of the process using expect and some glue. --lyndon
Re: Automatic OS updates
The main use case I see for this is to manage a fleet of more than 10 or so machines/VMs/instances. rdist or a package such as Ansible could manage the crontab and possibly search announce@ on marc.info for keywords to hold off on the upgrade. On 2/16/24 08:09, Jan Stary wrote: On 2024-02-15, b...@fea.st wrote: So I was curious, am I the only one using automatic OS updates in cron to keep the fish fresh and the bits dust free? 0 3 * * * root sysupgrade And this saves you what, ten keystrokes a day? Possibly hitting a bad moment to update blindly?
Re: Automatic OS updates
> On 2024-02-15, b...@fea.st wrote: > > So I was curious, am I the only one using automatic OS updates > > in cron to keep the fish fresh and the bits dust free? > > 0 3 * * * root sysupgrade And this saves you what, ten keystrokes a day? Possibly hitting a bad moment to update blindly?
Re: Automatic OS updates
On 2024-02-15, b...@fea.st wrote: > So I was curious, am I the only one using automatic OS updates > in cron to keep the fish fresh and the bits dust free? > > I think I read somewhere that it's not recommended but I'm not > running a server so it seems like a good idea to me. > > /etc/crontab: > > # Example of job definition: > # . minute (0 - 59) > # | .- hour (0 - 23) > # | | .-- day of month (1 - 31) > # | | | .--- month (1 - 12) OR jan,feb,mar,apr ... > # | | | | . day of week (0 - 6) (Sunday=0 or 7) OR > sun,mon,tue,wed,thu,fri,sat > # | | | | | > # * * * * * user-name command to be executed > 0 3 * * * root sysupgrade You should read upgrade notes (faq/current.html for -current, faq/upgradeXX.html for releases) *before* upgrading. For -current you should really be aware of commits (read src-changes) so you can identify times which would be bad to update (often best to hold off for a few days after a major library bump or major perl version update in order that new packages are available). -- Please keep replies on the mailing list.
Re: Automatic OS updates
On 15 February 2024 19:12:11 CET, b...@fea.st wrote: >So I was curious, am I the only one using automatic OS updates >in cron to keep the fish fresh and the bits dust free? > >I think I read somewhere that it's not recommended but I'm not >running a server so it seems like a good idea to me. > >/etc/crontab: > ># Example of job definition: ># . minute (0 - 59) ># | .- hour (0 - 23) ># | | .-- day of month (1 - 31) ># | | | .--- month (1 - 12) OR jan,feb,mar,apr ... ># | | | | . day of week (0 - 6) (Sunday=0 or 7) OR >sun,mon,tue,wed,thu,fri,sat ># | | | | | ># * * * * * user-name command to be executed > 0 3 * * * root sysupgrade This will stop working at the next release. Assuming you want to run -current. >30 3 * * * root pkg_add -u This will most likely run after package daemons have started. There is an example in upgrade.site(5) how to do this differently. -- Sent from a mobile device. Please excuse poor formatting.
Re: Automatic OS updates
I personally have this running on a desktop PC running OpenBSD 7.4-current since a few releases back. While it's been convenient, it has bitten me in the butt when something broke, since we are talking about -current. I wouldn't recommend this on anything you need in a functional state, but then you wouldn't be running -current unless you are aware of the risks. ;-) On Thu, Feb 15, 2024 at 1:16 PM wrote: > > So I was curious, am I the only one using automatic OS updates > in cron to keep the fish fresh and the bits dust free? > > I think I read somewhere that it's not recommended but I'm not > running a server so it seems like a good idea to me. > > /etc/crontab: > > # Example of job definition: > # . minute (0 - 59) > # | .- hour (0 - 23) > # | | .-- day of month (1 - 31) > # | | | .--- month (1 - 12) OR jan,feb,mar,apr ... > # | | | | . day of week (0 - 6) (Sunday=0 or 7) OR > sun,mon,tue,wed,thu,fri,sat > # | | | | | > # * * * * * user-name command to be executed > 0 3 * * * root sysupgrade > 30 3 * * * root pkg_add -u >
Automatic OS updates
So I was curious, am I the only one using automatic OS updates in cron to keep the fish fresh and the bits dust free? I think I read somewhere that it's not recommended but I'm not running a server so it seems like a good idea to me. /etc/crontab: # Example of job definition: # . minute (0 - 59) # | .- hour (0 - 23) # | | .-- day of month (1 - 31) # | | | .--- month (1 - 12) OR jan,feb,mar,apr ... # | | | | . day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat # | | | | | # * * * * * user-name command to be executed 0 3 * * * root sysupgrade 30 3 * * * root pkg_add -u
