Bug 226893 - freebsd-update: Support patchlevel argument for fetch and upgrade commands
Summary: freebsd-update: Support patchlevel argument for fetch and upgrade commands
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: feature, needs-qa
Depends on:
Blocks:
 
Reported: 2018-03-24 14:17 UTC by Derek
Modified: 2023-08-16 06:13 UTC (History)
6 users (show)

See Also:
koobs: mfc-stable12?
koobs: mfc-stable11?


Attachments
Adds support for TAG_OVERRIDE environment variable (1.71 KB, patch)
2018-03-24 14:17 UTC, Derek
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Derek 2018-03-24 14:17:10 UTC
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.
Comment 1 Derek 2018-03-24 14:26:29 UTC
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.
Comment 2 koshygp 2018-08-01 05:33:36 UTC
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).
Comment 3 Derek 2018-08-01 16:31:41 UTC
Great question!

It would seem the directory indexes have been removed from the updates server.  That's a little disappointing.

I would have normally browsed to:

http://update.freebsd.org/11.1-RELEASE/amd64/

... 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.

That url:

http://update.freebsd.org/11.1-RELEASE/amd64/t/

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 ...
Comment 4 koshygp 2018-08-01 16:55:04 UTC
Thats disappointing... 

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.
Comment 5 Derek 2018-08-01 18:06:24 UTC
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?
Comment 6 koshygp 2018-08-01 20:35:21 UTC
Sure. Will give it a try. Thanks!
Comment 7 Rodney W. Grimes freebsd_committer freebsd_triage 2019-08-01 01:59:02 UTC
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.
Comment 8 Derek 2019-08-01 10:18:51 UTC
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).
Comment 9 Kubilay Kocak freebsd_committer freebsd_triage 2019-09-10 03:01:10 UTC
Assignee timeout, reset
Comment 10 Tomohiro Hosaka 2020-12-14 02:33:28 UTC
In the past I was able to access http://update3.freebsd.org/11.2-RELEASE/amd64/t/?C=M;O=A .
By sorting in chronological order, I was able to get a hash of any patch level, numbered from 0.
I can't access the above URL right now.

I need the ability to get a hash of any patch level to calculate the diff between patch levels.
It is may be to be able to access the URL of the above again, it is a function of all.ssl may be implemented.

I hope it will be more convenient.