Updating and installing ports with security fixes only

F

freebuser

We run FreeBSD as our main OS for our business server.

Whilst I do build and updates ports on a regular basis, I am just wondering if there's an option to build and upgrade ports only if there is a security update, i.e. not just feature upgrades (via poudriere).

The reason for this is sometimes upgrades break things. And in a business environment this is costly and I try to avoid it.
 
There is quarterly & main branch.
Normally building a new quarterly does not break anything when options & default version are correctly configured in make.conf to avoid conflicts.
I use quarterly & 2800 ports build from source.
[ PS : recently openssl upgraded and needed for me a rebuild of 1500 dependent ports ...]
 
If you use the ports collection for sources to build from, then, instead of the HEAD or main branch of the ports tree, you can use a quarterly branch (see: FreeBSD Handbook - ports quarterly branch):
Code: 
# git clone https://git.FreeBSD.org/ports.git -b 2020Q3 /usr/ports
Just like the use of the quarterly repository for packages (these are built from the relevant quarterly branch), the most recent quarterly branch in the ports source tree only receives security and stability updates during a running quarter.

If you're using the HEAD branch of the ports collection (equivalent to "latest" with packages) you cannot differentiate between general updates and security updates. Perhaps by looking at the source control log messages you could get an idea if it only relates to security updates but that would amount to a substantial amount of probing I should imagine. Even then: what do you do when there are security related updates mixed in with non-security related issues because, those are not treated any differently when updates are added to the source tree; let alone from (manually) checking dependencies.

Especially with the use of the main branch of the ports collection and when you're using a (poudriere) build server, it would be an option to build a set of packages from the ports collection source at a certain moment in time for testing purposes. If, after testing, this particular set of built packages is satisfactory, you'd make this available to your client servers.
 
Erichans said:
only receives security and stability updates during a running quarter.
Click to expand...
The bolded part I think is important; at the end/beginning of a quarter, "quarterly" rolls forward. That implies that the git clone off a quarterly branch means you'll stop getting updates on that branch.
But I think if you keep an eye on pkg audit -F and dailysecurity output you can figure out new security updates as needed.
 
Further in make.conf i have:
Code: 
DEFAULT_VERSIONS+= mysql=10.6m
DEFAULT_VERSIONS+= ssl=openssl
DEFAULT_VERSIONS+= java=11
So everything is compiled against these specific mysql,ssl,java versions.
 
Erichans said:
Especially with the use of the main branch of the ports collection and when you're using a (poudriere) build server, it would be an option to build a set of packages from the ports collection source at a certain moment in time for testing purposes. If, after testing, this particular set of built packages is satisfactory, you'd make this available to your client servers.
Click to expand...
Another benefit of this is that you control the ports tree. So you can decide when to update it, or even what to update. You could update only a single port and leave the rest of the ports tree as-is. So you have full control over your updates.
 
Changes will catch up with you at some point, though. Never updating except for security is not a long term strategy, unless you want to end up like organizations that still use CentOS 7 today. And you will run an unsupported set of third-party software.
 
Outdated stuff accumulates over time until it is no longer managable. Run a montly poudriere with install. If not possible quarterly.
 
Erichans said:
If you use the ports collection for sources to build from, then, instead of the HEAD or main branch of the ports tree, you can use a quarterly branch (see: FreeBSD Handbook - ports quarterly branch):
Code: 
# git clone https://git.FreeBSD.org/ports.git -b 2020Q3 /usr/ports
Just like the use of the quarterly repository for packages (these are built from the relevant quarterly branch), the most recent quarterly branch in the ports source tree only receives security and stability updates during a running quarter.

If you're using the HEAD branch of the ports collection (equivalent to "latest" with packages) you cannot differentiate between general updates and security updates. Perhaps by looking at the source control log messages you could get an idea if it only relates to security updates but that would amount to a substantial amount of probing I should imagine. Even then: what do you do when there are security related updates mixed in with non-security related issues because, those are not treated any differently when updates are added to the source tree; let alone from (manually) checking dependencies.

Especially with the use of the main branch of the ports collection and when you're using a (poudriere) build server, it would be an option to build a set of packages from the ports collection source at a certain moment in time for testing purposes. If, after testing, this particular set of built packages is satisfactory, you'd make this available to your client servers.
Click to expand...
Although I didn't know the quarterly only gets security updates, I did use this strategy sometime back so thanks for reminding. I will have another look.


cracauer@ said:
Changes will catch up with you at some point, though. Never updating except for security is not a long term strategy, unless you want to end up like organizations that still use CentOS 7 today. And you will run an unsupported set of third-party software.
Click to expand...

I do update the ports (and base) regularly, but like to reduce it to bi-yearly so I can do it over the Christmas/Easter holidays without impacting my main job (Structural/Civil Engineer).

After seeing the recent thread on matrix/synapse issues (which I use extensively for internal communication), I am rethinking of my ports update process as any hiccups will take my time away from designing to fixing the server - which is not good for my business.
 
freebuser said:
I do update the ports (and base) regularly, but like to reduce it to bi-yearly so I can do it over the Christmas/Easter holidays without impacting my main job (Structural/Civil Engineer).
Click to expand...
Apparently this is a single server? And people depend on it so much you can't take it offline to update? What happens when the hardware breaks?

We run about 800 servers, and have a monthly update schedule. Important servers have backups, as in, there's almost always two or more servers that run the application(s). Which means you can take one offline (to update for example) without taking down the service. But besides that, we have a planning, made in advance for the whole year, people know when services are offline due to the patching schedule. After patching there are others who check and verify the applications. And we obviously have a proper DTAP set up, so when it's time to patch production we already know what to expect.
 
SirDice said:
Apparently this is a single server? And people depend on it so much you can't take it offline to update? What happens when the hardware breaks?

We run about 800 servers, and have a monthly update schedule. Important servers have backups, as in, there's almost always two or more servers that run the application(s). Which means you can take one offline (to update for example) without taking down the service. But besides that, we have a planning, made in advance for the whole year, people know when services are offline due to the patching schedule. After patching there are others who check and verify the applications. And we obviously have a proper DTAP set up, so when it's time to patch production we already know what to expect.
Click to expand...

It is, although only two people depend on it (small - family - business) :) .

I do have a back up plan as in business continuity plan and also backups to restore the system within a couple of days.

The issue I am trying to reduce/avoid is if I need to troubleshoot an app due to a bug in the latest version, I am loosing 50% of the staff doing the designs.

We run about 800 servers
Click to expand...

?

I am nowhere near that. Running a single server with half a dozen jails and Windows bhyve in it.
 
If you have a frequent patch schedule it's often just baby steps. When you only update once or twice a year you get a ton of updates in one go. That's a ton of things that could go wrong at the same time.
 
Update frequency is always toss up I think.
More frequent they are usually smaller and problems corrected quickly. Downside is more frequent interruptions to apply updates.
Less frequently, bigger,problems may take more effort diagnose and correct. Upside is less frequent interruptions but you may have longer downtime if you run into problems.

"Sixes and Threes" as some folks say.
 
For another client I have a weekly schedule for updates. But I can take servers offline without causing downtime of the service. So customers aren't even aware of it.
 
Updating twice a year is not nearly as bad as people running CentOS 7 now, true.

But it opens the question whether going with quarterly ("only" twice the frequency) isn't the better option. It is the difference between doing a lot of update work yourself or having somebody else do it for you, for free.
 
You must log in or register to reply here.
Back
Top