Created attachment 191785 [details]
Adds support for TAG_OVERRIDE environment variable
Attached is a proof-of-concept for specifying a patch level for freebsd-update.
This is desirable so that users can have a repeatable installation, update and upgrade process that is supported by the FreeBSD project, and doesn't require many additional supporting infrastructure on the user's part.
As it is right now, users will either need to:
- run their own build/freebsd-update server infrastructure
- run some kind of mirror (unsupported)
- manipulate the update data in /var/db/freebsd-update (unsupported)
- patch freebsd-update
A desirable outcome would be a documented command line usage that would allow to specify the patch level in a user friendly fashion when issuing either freebsd-update -r WHATEVER upgrade, or freebsd-update fetch. For example:
freebsd-update -r 11.1-RELEASE -p4 upgrade
freebsd-update -p4 fetch
This will allow systems administrators to upgrade at a cadence that makes sense for their organization, or scripts to build repeatable images, while still using the binaries provided by the FreeBSD project.
It was expressed that "it would be nice if" we could list the available patch levels, for example, and by extension if we can specify that patch level by number, instead of existing tag hash.
1. Without updates to the freebsd-update server portion, the only way that I can see this being feasible is to download all the available tags for a release, and then pull down their manifests and see if there's a file that can be downloaded (e.g. whatever freebsd-version is sourcing), and parsed. I feel like this is needlessly onerous.
2. A different method, would be in addition to latest.ssl, we also support all.ssl, which is the concatenation of all of the latest.ssl released for a particular release/architecture. This will require changes to the freebsd-update server portion, and will need support added retroactively for previous supported releases. It would be trivial to modify to the freebsd-update client to support this file instead (or in addition to).
3. A third, most hacky, option is just to specify the tag hash on the command line, and put the onus on the user to research the tag they wish to install.
There's likely other approaches, but I'm partial to #2.
Where can I find the tag value to be specified for the TAG_OVERRIDE variable for a specific patch version? I would like to try this method to upgrade FreeBSD 11.1-RELEASE p0 to p10. (FreeBSD 11.1 is currently at p11).
It would seem the directory indexes have been removed from the updates server. That's a little disappointing.
I would have normally browsed to:
... and tried to figure it out from there. There were hashes (tags) listed in the t/ directory with timestamps that correlate to the patch release date, and that's where I would have started. I forget the exact steps, as I can no longer browse.
Is now returning a 403, rather than a directory index. Not sure who to talk to, to re-enable directory indexes.
The other option, is that if you have a machine up to the desired patch level, you can simply cat /var/db/freebsd-update/tag, and use that full value as the value for TAG_OVERRIDE, e.g. TAG_OVERRIDE=$(cat ~/thetagfromtheotherserver) freebsd-update ...
The one I have is 11.1 p8 and I used the tag from (/var/db/freebsd-update/tag) to test the patch.
Unfortunately p10 is what I need.
Anyways thanks for the prompt reply.
I feel bad that you aren't able to do what you want.
I wonder if you could find someone on -questions (or somewhere) who'd be able to post their tag file from 11.1-RELEASE-p10, or who to talk to about re-enabling directory indexes?
Sure. Will give it a try. Thanks!
This has come in very handy and I thank the author for the work and would like to ask that some how we start to collect the TAGS so that they can be more readily used.
Thanks for the recognition and encouragement. I'd be happy to flesh this out better with more support from the project.
FWIW, some of the update servers do have directory indexes enabled, so that's something (although it seems like an accident that will probably go away when I post this).
Assignee timeout, reset