Update, Upgrade incantations in 2020

decuser

Active Member

Reaction score: 29
Messages: 133

Every day or so, I ssh into my freebsd server and do the following:
Bash:
sudo freebsd-update fetch
sudo freebsd-update install
sudo pkg update
sudo pkg upgrade
sudo pkg audit -F
Is this all that I need to do to stay up to date (I'm on 12.1-RELEASE-p7 ATM)? and what do I do about identified vulnerabilities (right now I just ask myself if I'm using the vulnerable app, wait a few days, and check again)...
 

unitrunker

Well-Known Member

Reaction score: 156
Messages: 439

What you have looks good to me.

If you've locked a package, you may need to unlock it. When an update / upgrade breaks things, it can be a pain to go back to a working state

You may want to take a ZFS snapshot as your first step. Should be sufficient for a kernel update.

For kernel upgrades, I suggest this.


It's not well written but I'm working on that.

For pkg audit, you have to read the CVE fine print. Is it a tool you use daily? Can you go without it? Is the flaw tied to a feature you don't use? Is there another tool you can use temporarily?

Are there other mitigating controls - like a firewall, ACL, or jail that prevent the exploit?
 

Emrion

Well-Known Member

Reaction score: 107
Messages: 405

A few comments:
When you make a kernel upgrade, you need to reboot but freebsd-update ask for that as far as I know.
After pkg upgrade, I advise you to reboot (if possible) because that can break things in a way you don't imagine.
And so, before your upgrade sequence, make a BE. I recommend sysutils/beadm instead of bectl because it had multiple bugs. The known ones are fixed, but I lost confidence in this utility. beadm is more ancient and polished.

unitrunker I don't see your point in renaming the default BE before upgrading. I just make a BE named like beforeupgradeXXX and I use it in case of disaster at reboot. If you want to stay on this BE, you have to activate it and, if you prefer, rename it "default" (you have to destroy or rename the original default before, of course). That's all.
Other comments: I don't see a reboot command for bectl in the man page. And if you destroy a BE with bectl, don't forget to specify the -o option in order to destroy the underlying snapshot.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 9,085
Messages: 33,642

Is this all that I need to do to stay up to date (I'm on 12.1-RELEASE-p7 ATM)? and what do I do about identified vulnerabilities (right now I just ask myself if I'm using the vulnerable app, wait a few days, and check again)...
No need to do this every day. Issues in the base OS are fortunately far and few in between. Just sign up for the announcement mailing list. If there are security or errata patches you'll get notified. Until then it's rather pointless to run freebsd-update(8). As for third-party software (ports/packages), keep an eye on the daily security mails that are generated. It uses pkg-audit(8) to keep track of security issues.

Example of a notification in one of the periodic(8) security emails:
Code:
Checking for packages with security vulnerabilities:
Database fetched: Sat Jul 25 03:33:58 CEST 2020
python37-3.7.7_1
(don't worry, I've since patched this)

There's really no need to check this by hand every day, it's already automatically done, just read the daily/weekly/monthly periodic(8) mail.
 
OP
decuser

decuser

Active Member

Reaction score: 29
Messages: 133

No need to do this every day. Issues in the base OS are fortunately far and few in between. Just sign up for the announcement mailing list. If there are security or errata patches you'll get notified. Until then it's rather pointless to run freebsd-update(8). As for third-party software (ports/packages), keep an eye on the daily security mails that are generated. It uses pkg-audit(8) to keep track of security issues.
Oh boy, do I feel dumb :). Yup there it is in the mailbox, which I've been pretty much ignoring. Lot's of interesting stuff in there!
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 9,085
Messages: 33,642

Yup there it is in the mailbox, which I've been pretty much ignoring. Lot's of interesting stuff in there!
Don't worry, everyone does. Until they realize there's actually a lot of interesting information in them ;)

I would suggest, if it makes sense for your situation, to simply forward all root's mail to a central mailbox. Then all your machines will send their automatic mails to it. Just add an email address in /etc/aliases (don't forget to run newaliases(8)) for root and have everything collected in a specific admin mailbox.
 
OP
decuser

decuser

Active Member

Reaction score: 29
Messages: 133

For kernel upgrades, I suggest this.
I took some of Emrion's comments to heart (didn't do beadm yet) and modified the approach slightly, but wow! I have always loved ZFS, but this, this is spectacular. Makes upgrading painless!

Here's what I wound up doing (I did some testing of the different BE's but left that out of the list):

Before:
Last login: Thu Jul 30 07:36:35 2020 from 192.168.2.13
FreeBSD 12.1-RELEASE r354233 GENERIC

Bash:
bectl list
bectl create old
freebsd-update fetch install
reboot

pkg update
pkg upgrade
reboot

bectl destroy old
zfs destroy zroot/ROOT/default@2020-07-30-07:40:04-0
After:
Last login: Thu Jul 30 07:54:23 2020 from 192.168.2.13
FreeBSD 12.1-RELEASE-p7 GENERIC

Off to read about beadm/bectl and boot environments generally. I'd heard of them, but they sounded complex and I hadn't taken the time to figure them out. Your writeup was just the impetus I needed.
 

Emrion

Well-Known Member

Reaction score: 107
Messages: 405

You should read this: https://vermaden.files.wordpress.com/2018/11/nluug-zfs-boot-environments-reloaded-2018-11-15.pdf

Vermaden is present on this forum and he's the author of beadm. And believe me, he saved my ass several times from the bectl bugs.

Personally, I can't understand people that yet use UFS. Indeed, with ZFS, all upgrades are riskless, provided you make a BE before each time (and do not forget to destroy the old BEs - including associated snapshot - because they take more and more room as time is passing).
 

unitrunker

Well-Known Member

Reaction score: 156
Messages: 439

Your writeup was just the impetus I needed.
Mission accomplished!

This is precisely the sort of feedback I want:
unitrunker I don't see your point in renaming the default BE before upgrading. I just make a BE named like beforeupgradeXXX and I use it in case of disaster at reboot. If you want to stay on this BE, you have to activate it and, if you prefer, rename it "default" (you have to destroy or rename the original default before, of course). That's all.
I'm in the habit of naming my BEs this way. However - for the wiki - I shouldn't assume this of everyone else. I think I'll update the page to follow your pattern above.

Other comments: I don't see a reboot command for bectl in the man page.
Good catch. Fixed and thank you!

And if you destroy a BE with bectl, don't forget to specify the -o option in order to destroy the underlying snapshot.
Now I need to do some reading. Thank you again.

One thing I need to stress in that page is don't destroy the "old" BE right away. You may discover breakage days later. No harm in keeping the old BE around a bit longer.
 
Top