Re: getting the running patch level

[Przemyslaw Zoltowski]

Wiadomość napisana przez "Roberto" <robe...@redix.it> w dniu 9 sie 2012, o godz. 11:44:

>
> Hi all,
> I would like to know if there is a command or a way to retrieve the "patch
> level" (the handbook defines it "builds names" like 7.0-RELEASE-p1) of the
> running system: just an example, if I run:
>
> # freebsd-update fetch
> ...
> No updates needed to update system to 9.0-RELEASE-p4
>
>
> or:
> ...
> The following files will be updated as part of updating to 9.0-RELEASE-p4:
> ...
>
> but this give me no info about the current system; I tried a brief search in
> config file but no luck;
>
> again the question is:
> is there a way to determine for a running server which "patch level" is
> currently at ?

uname -a

>
> thanks
> Roberto
>
> _______________________________________________
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

_______________________________________________
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

[Károly Arnhoffer]

Hi,

As I can remember
# uname -a
provides this information.

Regards,
Karoly

-----Original Message-----
From: owner-freeb...@freebsd.org [mailto:owner-freeb...@freebsd.org] On Behalf Of Roberto
Sent: Thursday, August 09, 2012 11:44 AM
To: freebsd-...@freebsd.org
Subject: getting the running patch level


Hi all,
I would like to know if there is a command or a way to retrieve the "patch level" (the handbook defines it "builds names" like 7.0-RELEASE-p1) of the running system: just an example, if I run:

# freebsd-update fetch
...
No updates needed to update system to 9.0-RELEASE-p4


or:
...
The following files will be updated as part of updating to 9.0-RELEASE-p4:
...

but this give me no info about the current system; I tried a brief search in config file but no luck;

again the question is:
is there a way to determine for a running server which "patch level" is currently at ?

[cronfy]

>> Hi all,
>> I would like to know if there is a command or a way to retrieve the "patch
>> level" (the handbook defines it "builds names" like 7.0-RELEASE-p1) of the
>> running system: just an example, if I run:
>> # freebsd-update fetch

>> No updates needed to update system to 9.0-RELEASE-p4
>> or:
>> ...
>> The following files will be updated as part of updating to 9.0-RELEASE-p4:
>> ...
>> but this give me no info about the current system; I tried a brief search in
>> config file but no luck;
>> again the question is:
>> is there a way to determine for a running server which "patch level" is
>> currently at ?
> uname -a

Unfortunately there is no trivial way. uname -a will show you correct
patch level only if kernel was changed at this patch level.

So the only way is to see what updates freebsd-update offers to you
and try to guess, on which patch level you are on now.

--
Олег Петрачев

[Henrik Andersen]

Hi all,

You can find the current patch level in /usr/src/sys/conf/newvers.sh ex:
TYPE="FreeBSD"
REVISION="8.3"
BRANCH="RELEASE-p4"

uname -v on the same server:
FreeBSD 8.3-RELEASE #0: Mon Apr 9 21:23:18 UTC 2012
ro...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC

If I read the handbook correctly this should always be true on systems
using freebsd-update.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html

Regards,
Henrik

[Cedric GROSS]

Hello Roberto,

In fact "uname -a" report patch level BUT if you update your system by
freebsd-update, patch level could be an old one.
As discuss here http://forums.freebsd.org/archive/index.php/t-20154.html

Regards
Cedric

-----Message d'origine-----
De : owner-freeb...@freebsd.org
[mailto:owner-freeb...@freebsd.org] De la part de Roberto
Envoyé : jeudi 9 août 2012 15:39
À : Károly Arnhoffer
Cc : freebsd-...@freebsd.org
Objet : RE: getting the running patch level
Importance : Haute


just a try on the server:

--------------
% uname -a
FreeBSD xxxx.yyyyy 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30
UTC
2012 ro...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC zzzz
%
--------------

and with the update command:
--------------

# freebsd-update fetch
...
No updates needed to update system to 9.0-RELEASE-p4

--------------

so I think uname will NOT give me enough info on the running os patchlevel
(p4), maybe uname could be useful when the kernel itself is updated in the
update process and the system rebooted; or I am probably missing something
...

regards
Roberto

[Brett Glass]

Yes, uname -v will work. Unfortunately, it has an annoying side effect. If one tries
to use the "sysinstall" program to install binary packages, it will fail when
a system patched by freebsd-update tries to access the FTP server, because the FTP
server doesn't know about patch levels.

One must MANUALLY go to the Options screen and remove the patch level
(-p3, -p4 or whatever) from the version string before one can install a binary
package.

I realize that sysinstall is deprecated in favor of the new installer, but
the new installer doesn't have the ability to install binary packages.
Until and unless there's a convenient menu-based installer for binary
packages, would it be possible to fix this glitch?

--Brett Glass

At 09:43 AM 8/9/2012, Henrik Andersen wrote:

>Hi all,
>
>You can find the current patch level in /usr/src/sys/conf/newvers.sh ex:
> TYPE="FreeBSD"
> REVISION="8.3"
> BRANCH="RELEASE-p4"
>
>uname -v on the same server:
>FreeBSD 8.3-RELEASE #0: Mon Apr 9 21:23:18 UTC 2012
>ro...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
>
>If I read the handbook correctly this should always be true on systems
>using freebsd-update.
>http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html
>
>Regards,
>Henrik

[Glen Barber]

On Thu, Aug 09, 2012 at 03:31:25PM -0600, Brett Glass wrote:
> I realize that sysinstall is deprecated in favor of the new installer, but
> the new installer doesn't have the ability to install binary packages.
> Until and unless there's a convenient menu-based installer for binary
> packages, would it be possible to fix this glitch?
>

There is always pkgng, granted it is not menu-driven.

Glen

[Matthew Seaman]

On 09/08/2012 23:13, Glen Barber wrote:
> On Thu, Aug 09, 2012 at 03:31:25PM -0600, Brett Glass wrote:
>> > I realize that sysinstall is deprecated in favor of the new installer, but
>> > the new installer doesn't have the ability to install binary packages.
>> > Until and unless there's a convenient menu-based installer for binary
>> > packages, would it be possible to fix this glitch?

> There is always pkgng, granted it is not menu-driven.

No reason pkgng couldn't be wrapped in some sort of menuing system. In
fact, it's probably quite a lot easier than doing the same sort of thing
with the old pkg_tools.

Also, pkgdb functionality is expressed through libpkg.so.1, meaning that
hooking it up to a different front-end should be a small matter of
programming. There is already a Ruby interface available, and other
languages are being worked on. The libpkg API is still subject to
incompatible changes at this stage of development: that won't be settled
for quite some time yet.

Cheers,

Matthew

--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: mat...@infracaninophile.co.uk Kent, CT11 9PW

[Simon L. B. Nielsen]

On Fri, Aug 10, 2012 at 1:06 PM, Roberto <robe...@redix.it> wrote:
>
> So as far I understand, if the kernel is not updated by the update process, it
> is not possible to get via "uname" the currently patch level.

Correct.

This has been discussed a number of time, but there are no nice and
simple solution. There is a simple solution if we just update the
kernel always, but that's a hack IMO.

While the problem seems rather simple, there are many corner cases
making it hard to solve. It should be solved so people can get this
information, personally I just haven't had the time to work on it.

--
Simon L. B. Nielsen

[Chris BeHanna]

On Aug 10, 2012, at 09:40 , Simon L. B. Nielsen <si...@FreeBSD.org> wrote:

> On Fri, Aug 10, 2012 at 1:06 PM, Roberto <robe...@redix.it> wrote:
>>
>> So as far I understand, if the kernel is not updated by the update process, it
>> is not possible to get via "uname" the currently patch level.
>
> Correct.
>
> This has been discussed a number of time, but there are no nice and
> simple solution. There is a simple solution if we just update the
> kernel always, but that's a hack IMO.
>
> While the problem seems rather simple, there are many corner cases
> making it hard to solve. It should be solved so people can get this
> information, personally I just haven't had the time to work on it.

Split off a version.ko and update that with each patch?

--
Chris BeHanna
ch...@behanna.org_______________________________________________

[Janne Snabb]

On 08/10/2012 11:55 PM, Chris BeHanna wrote:
> Split off a version.ko and update that with each patch?

There is often no need to reboot the machine unless the kernel is
affected (just restart the affected daemons). Thus the information would
not necessarily match the userland status. The userland and kernel
versions need to be kept separate because they may not match. I am often
struggling to remember if I updated some machine already or not. I now
need to compare the time stamps of newvers.sh and installed binaries to
find out.

IMHO a sensible approach would be something like what most Linux distros
do: Have some file in a standard location and put the information there
by generating that file from newvers.sh during make buildworld /
installworld". Having it only in the source tree is not sufficient as
not every machine has the source tree installed.

On LSB compliant Linux distributions the proper way to find this out is
the lsb_release command.

On many Linux distributions there is also a /etc/DISTRONAME-release file
which can be checked (for example /etc/debian-release on Debian and
/etc/redhat-release on RHEL and clones).

How about /etc/freebsd-release? Or freebsd_release command (shell
script) which takes the same flags as lsb_release?

--
Janne Snabb / EPIPE Communications
sn...@epipe.com - http://epipe.com/

[olli hauer]

On 2012-08-10 16:40, Simon L. B. Nielsen wrote:
> On Fri, Aug 10, 2012 at 1:06 PM, Roberto <robe...@redix.it> wrote:
>>
>> So as far I understand, if the kernel is not updated by the update process, it
>> is not possible to get via "uname" the currently patch level.
>
> Correct.
>
> This has been discussed a number of time, but there are no nice and
> simple solution. There is a simple solution if we just update the
> kernel always, but that's a hack IMO.
>
> While the problem seems rather simple, there are many corner cases
> making it hard to solve. It should be solved so people can get this
> information, personally I just haven't had the time to work on it.
>

Maybe this information can be hold in an additional file,
see http://cpe.mitre.org/

There is no guaranty root modifies the cpe files but thats the same
for all systems which have cpe already implemented.

--
Regards,
olli

[Dag-Erling Smørgrav]

"Simon L. B. Nielsen" <si...@FreeBSD.org> writes:
> This has been discussed a number of time, but there are no nice and
> simple solution.

There is a simple solution that, while not bulletproof, would work well
enough in most cases: have 'make installworld' create /etc/issue, which
would look like this:

FreeBSD 9.0-RELEASE-p4 amd64/amd64

DES
--
Dag-Erling Smørgrav - d...@des.no

[Jason Hellenthal]

On Sat, Aug 11, 2012 at 09:05:44PM +0200, Dag-Erling Smørgrav wrote:
> "Simon L. B. Nielsen" <si...@FreeBSD.org> writes:
> > This has been discussed a number of time, but there are no nice and
> > simple solution.
>
> There is a simple solution that, while not bulletproof, would work well
> enough in most cases: have 'make installworld' create /etc/issue, which
> would look like this:
>
> FreeBSD 9.0-RELEASE-p4 amd64/amd64
>

Could I suggest... the same way that /etc/motd is already updated ?

--

- (2^(N-1)) JJH48-ARIN

[Dag-Erling Smørgrav]

Jason Hellenthal <jhell...@dataix.net> writes:
> Could I suggest... the same way that /etc/motd is already updated ?

You could, but it wouldn't be very helpful, since /etc/rc.d/motd uses
uname(1), which returns the kernel version. On the contrary, once
/etc/issue is in place, we should use that instead of uname(1) to update
/etc/motd.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Manolis Kiagias]

On 13/08/2012 22:27, Dag-Erling Smørgrav wrote:
> Jason Hellenthal<jhell...@dataix.net> writes:
>> Could I suggest... the same way that /etc/motd is already updated ?
> You could, but it wouldn't be very helpful, since /etc/rc.d/motd uses
> uname(1), which returns the kernel version. On the contrary, once
> /etc/issue is in place, we should use that instead of uname(1) to update
> /etc/motd.
>
> DES

One could also set the environment variable UNAME_r to the correct value
(either in system wide e.g. /etc/profile or to a specific user dot
files). Only problem of course it would have to be updated to the
correct value manually.
Or, since the correct value is always in newvers.sh, if src is present
in the system a periodic script could update it automatically.
The manual updating will cause more confusion in the long run - people
tend to forget these things...

[Dag-Erling Smørgrav]

Manolis Kiagias <sonic...@gmail.com> writes:
> One could also set the environment variable UNAME_r to the correct
> value (either in system wide e.g. /etc/profile or to a specific user
> dot files).

If your goal is to have uname(1) return the correct value, yes, except
it won't always work. For instance, sudo(1) (and probably also su(1),
but I never use it) will strip it from the environment and will *not*
run /etc/profile before the requested command.

> Or, since the correct value is always in newvers.sh, if src is present
> in the system a periodic script could update it automatically.

We can't assume that src is present.

> The manual updating will cause more confusion in the long run -
> people tend to forget these things...

Nobody suggested manually updating anything.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Jilles Tjoelker]

On Sat, Aug 11, 2012 at 09:05:44PM +0200, Dag-Erling Smørgrav wrote:

> "Simon L. B. Nielsen" <si...@FreeBSD.org> writes:
> > This has been discussed a number of time, but there are no nice and
> > simple solution.

> There is a simple solution that, while not bulletproof, would work well
> enough in most cases: have 'make installworld' create /etc/issue, which
> would look like this:

> FreeBSD 9.0-RELEASE-p4 amd64/amd64

I think the idea of having 'make installworld' create something is good,
but we should not hard-code policy by writing the information into a
file that may be shown to unauthenticated users (such as by getty).

A new file with a name=value format somewhat like /etc/lsb-release on
Linux seems more appropriate. If the admin wants /etc/issue,
/etc/rc.d/motd can create it.

The new file is not a configuration file and tools like mergemaster and
freebsd-update must not bother the admin about it. If all files under
/etc are considered "configuration files", then perhaps a different
location is better.

--
Jilles Tjoelker

[Doug Barton]

On 08/19/2012 05:33, Jilles Tjoelker wrote:
> I think the idea of having 'make installworld' create something is good,
> but we should not hard-code policy by writing the information into a
> file that may be shown to unauthenticated users (such as by getty).
>
> A new file with a name=value format somewhat like /etc/lsb-release on
> Linux seems more appropriate. If the admin wants /etc/issue,
> /etc/rc.d/motd can create it.
>
> The new file is not a configuration file and tools like mergemaster and
> freebsd-update must not bother the admin about it. If all files under
> /etc are considered "configuration files", then perhaps a different
> location is better.

The way that you avoid mergemaster dealing with a file is to avoid
installing it as part of the process that mergemaster uses to create the
temproot directory (you can see this easily enough in the script). If
the file doesn't end up in the temproot, mergemaster will have no
knowledge of it.

hth,

Doug

--

I am only one, but I am one. I cannot do everything, but I can do
something. And I will not let what I cannot do interfere with what
I can do.
-- Edward Everett Hale, (1822 - 1909)

[Paul Schenkeveld]

On Thu, Aug 09, 2012 at 11:44:02AM +0200, Roberto wrote:
>
> Hi all,
> I would like to know if there is a command or a way to retrieve the "patch
> level" (the handbook defines it "builds names" like 7.0-RELEASE-p1) of the
> running system: just an example, if I run:
>
> # freebsd-update fetch
> ...
> No updates needed to update system to 9.0-RELEASE-p4
>
>
> or:
> ...
> The following files will be updated as part of updating to 9.0-RELEASE-p4:
> ...
>
> but this give me no info about the current system; I tried a brief search in
> config file but no luck;
>
> again the question is:
> is there a way to determine for a running server which "patch level" is
> currently at ?

Having read all responses so far I think a summary of the issue at hand
is:

- Uname only reports on the kernel version, currently we do not store
nor report the userland version.

- People would love to know what version of FreeBSD, both kernel and
userland, is currently installed/running.

- Userland can either be upgraded using make {build,install}world or
by freebsd-update, neither logs the version to which userland was
updated.

- Reporting the userland version is not trivial as not necessarily all
parts of userland are of the same version, especially after doing
an buildworld/instrallworld with a changed src.conf or make.conf.

- We currently reflect the last booted kernel version in /etc/motd.

My suggestion would be:

- Teach both installworld and freebsd-update to maintain manifest
files of what is installed and log that update, place all manifests
somewhere under /var/db and the update log in /var/log.

- If the above log message is well defined and includes the method
by which the update was done, it can be parsed by /etc/rc.d/motd
and we could extend the information in /etc/motd to also include
information about userland. Something like:

<tool> <timestamp> <who> <current-version>
portupgrade 2012-08-19T16:26:41 paul 8.3-RELEASE-p4
installworld 2012-08-19T16:31:36 paul 8-STABLE-r231558

- Having manifests of what's installed, one could check if all files
are stil the right version, if older manifests are not discarded
when performing an update this could also detect files that were
not updated for whatever reason or that were reverted, i.e. by
restoring some backup. E.g.:

Current userland version: 8.3-RELEASE-p4
/usr/sbin/named is at 8.3-RELEASE-p2
/usr/bin/openssl is at 8.3-RELEASE

- Such a time-consuming check could be run from periodic (weekly or
monthly perhapd) and be a valuable tool to warn sysadmins of files
not being what they should be.

- Adding, in the case of freebsd-update, a signature to the manifest
files that can be checked against the signature in the freebsd-update
master repository could turn this tool into something of a integrity
checking tool.

Having installworld produce a manifest may seem like a big change to
the current build infrastructure but in some other thread I read about
people working towards installworld being run as a normal user and
producing mtree like files that can be used in combination with makefs
to make installables as a normal user. I think that whatever comes
out of that project can serve as [a starting point for] these manifest
files.

The /etc/issue file mentioned several times in this thread is like motd
but intended to be shown before a login prompt. This works for console
logins (getty) but not for remote logins. The mechanism of /etc/rc.d/motd
could of course be used for /etc/issue too but personally I'd rather see
all version info, kernel and userland, reported in the same place: motd.

My 2 cents.

With kind regards,

Paul Schenkeveld

[Peter Jeremy]

On 2012-Aug-19 16:46:37 +0200, Paul Schenkeveld <fre...@psconsult.nl> wrote:
> - Teach both installworld and freebsd-update to maintain manifest
> files of what is installed and log that update, place all manifests
> somewhere under /var/db and the update log in /var/log.

I'm not sure what detail you intend here. One line per installworld
or similar sounds OK. One line per file seems excessive - especially
if you intend to retain history ("df -ki" suggests that a base install
is around 30,000 files).

> - Having manifests of what's installed, one could check if all files
> are stil the right version, if older manifests are not discarded
> when performing an update this could also detect files that were
> not updated for whatever reason or that were reverted, i.e. by
> restoring some backup. E.g.:
>
> Current userland version: 8.3-RELEASE-p4
> /usr/sbin/named is at 8.3-RELEASE-p2
> /usr/bin/openssl is at 8.3-RELEASE

How do you envisage this tool determining that /usr/sbin/foo is at
8.3-RELEASE-p2 and this is incorrect when userland is at (eg)
8.3-RELEASE-p4? Note that updating your system from 8.3-RELEASE-p2 to
8.3-RELEASE-p4 may not change /usr/sbin/foo and therefore it will
remain untouched.

>The /etc/issue file mentioned several times in this thread is like motd
>but intended to be shown before a login prompt. This works for console
>logins (getty) but not for remote logins.

SSH includes provision for displaying information prior to login - see
the "Banner" option in sshd_config. Note that this is most definitely
the wrong place to include system version details.

--
Peter Jeremy

[Simon L. B. Nielsen]

On 19 Aug 2012, at 13:33, Jilles Tjoelker <jil...@stack.nl> wrote:

> On Sat, Aug 11, 2012 at 09:05:44PM +0200, Dag-Erling Smørgrav wrote:
>> "Simon L. B. Nielsen" <si...@FreeBSD.org> writes:
>>> This has been discussed a number of time, but there are no nice and
>>> simple solution.
>
>> There is a simple solution that, while not bulletproof, would work well
>> enough in most cases: have 'make installworld' create /etc/issue, which
>> would look like this:
>
>> FreeBSD 9.0-RELEASE-p4 amd64/amd64
>
> I think the idea of having 'make installworld' create something is good,
> but we should not hard-code policy by writing the information into a
> file that may be shown to unauthenticated users (such as by getty).
>
> A new file with a name=value format somewhat like /etc/lsb-release on
> Linux seems more appropriate. If the admin wants /etc/issue,
> /etc/rc.d/motd can create it.
>
> The new file is not a configuration file and tools like mergemaster and
> freebsd-update must not bother the admin about it. If all files under
> /etc are considered "configuration files", then perhaps a different
> location is better.

/etc is IMO generally expected to be managed by mergemaster etc. so I think that's a bad location for an authoritative file.

Having thought about this for a while, my preference is to have the file with the information somewhere under /usr and be installed with a normal installworld. That has the highest likelihood to actually matching the rest of the userland IMO, for cases like shares /usr etc (though that's probably less common now). If it's a text file it should probably be under /usr/share somewhere. If it's a binary /usr/bin or possibly /usr/libexec if more magic is made to hide it.

The part I'm not yet really sure about is how to display this information. For the freebsd-update case of userland update only, it's possible we can do something sane and preserve our existing simple uname based output, but I'm not sure. I haven't gone through all the different cases to be sure. For the installworld case I'm even less sure we can simple and sanely do the right thing considering how to handle cases with kernel and userland seriously out of sync.

A simple approach would be to just append -uX to the uname string, but I'm not really sure if I like that... To ilustrate, if for a 9.0 system, where kernel is patch 3 userland is patch 5, we would show FreeBSD 9.0-RELEASE-p3-u5. The nice thing is that we don't try to be clever and therefor are less likely to get it wrong.

More fancy things with creating log files etc. does really solve the issue at hand with getting the running patch level in a simple way IMO.

PS. /etc/issue sounds like a file which certainly shouldn't contain authoritative info, but if it exists should rather be generated like /etc/motd.

--
Simon L. B. Nielsen

[Roger Marquis]

Jilles Tjoelker wrote:
> I think the idea of having 'make installworld' create something is good,
> but we should not hard-code policy by writing the information into a
> file that may be shown to unauthenticated users (such as by getty).
>
> A new file with a name=value format somewhat like /etc/lsb-release on
> Linux seems more appropriate. If the admin wants /etc/issue,
> /etc/rc.d/motd can create it.

Automatically updating /etc/issue (or /etc/issue.net, but not issue.*
should that be adopted from other OS) has security implications due to
potentially unintended information disclosure.

WRT writing a new file, something like /etc/bsd-release would be a good
choice following the principle of least surprise. Mergemaster can and
should ignore it (and motd, issue, ...).

Strict adherence to the KIS principle, however, would only write this
information to the first line of the motd, after the kernel info.

Simon Nielsen wrote:
> A simple approach would be to just append -uX to the uname string, but I'm
> not really sure if I like that... To ilustrate, if for a 9.0 system, where
> kernel is patch 3 userland is patch 5, we would show FreeBSD
> 9.0-RELEASE-p3-u5. The nice thing is that we don't try to be clever and
> therefor are less likely to get it wrong.

There's not a good way to report on every userland (lib/binary) file but
a simple find and/or checksum (a la integrit) could indicate whether
anything had been updated since the last installworld. That could be
noted by appending a simple "-modified" to whatever uname prints for the
userland version. Attempting to do more than that, IMO, would have a
negative ROI.

IMO,
Roger Marquis

[Adrian Penisoara]

Hello,

On Tue, Aug 21, 2012 at 6:49 PM, Roger Marquis <mar...@roble.com> wrote:
> Jilles Tjoelker wrote:
[...]

>
> WRT writing a new file, something like /etc/bsd-release would be a good
> choice following the principle of least surprise. Mergemaster can and
> should ignore it (and motd, issue, ...).
>

I support the idea of using an /etc/*-release file to tag (and this
makes me think about /var/db/freebsd-update/tag) the current release
version details of the system (not only the kernel, but the whole
installed system). This seems to be a popular choice among Linux
distributions and thus ISV's should feel comfortable with the
approach.

Mergemaster and/or other updating mechanisms should update the file
to reflect the reality after upgrades/updates.

Now the format of the file would be also debatable: other vendors
releasing derivative works from the main FreeBSD source tree (like
FreeNAS, PC-BSD, etc.) will want to leave some marks as well. Should
we retain only the vendor's release tag or should we have a multiple
entries (for the original FreeBSD version and the vendor) ? Should we
even think about multiple ${vendor}-release files or just bsd-release
?

Thanks for your time,
Adrian Penisoara
EntepriseBSD

[olli hauer]

On 2012-08-22 12:44, Adrian Penisoara wrote:
> Hello,
>
> On Tue, Aug 21, 2012 at 6:49 PM, Roger Marquis <mar...@roble.com> wrote:
>> Jilles Tjoelker wrote:
> [...]
>>
>> WRT writing a new file, something like /etc/bsd-release would be a good
>> choice following the principle of least surprise. Mergemaster can and
>> should ignore it (and motd, issue, ...).
>>
>
> I support the idea of using an /etc/*-release file to tag (and this
> makes me think about /var/db/freebsd-update/tag) the current release
> version details of the system (not only the kernel, but the whole
> installed system). This seems to be a popular choice among Linux
> distributions and thus ISV's should feel comfortable with the
> approach.
>
> Mergemaster and/or other updating mechanisms should update the file
> to reflect the reality after upgrades/updates.
>
> Now the format of the file would be also debatable: other vendors
> releasing derivative works from the main FreeBSD source tree (like
> FreeNAS, PC-BSD, etc.) will want to leave some marks as well. Should
> we retain only the vendor's release tag or should we have a multiple
> entries (for the original FreeBSD version and the vendor) ? Should we
> even think about multiple ${vendor}-release files or just bsd-release
> ?

In case a new file will be used, I suggest using the cpe framework,
see http://cpe.mitre.org/specification/

Using a standard framework makes it easier to write platform
independent tools for example in visualization environments.

sample /etc/system-release-cpe entry
cpe:/o:freebsd:8.3:ga:x64 ...

--
Regards,
olli

[olli hauer]

s/visualization/virtualization/

>
> sample /etc/system-release-cpe entry
> cpe:/o:freebsd:8.3:ga:x64 ...

[Thomas]

Sounds good if you have a just a few systems. In a large environment,
snmp is quite common to collect release information.

AFAIK snmp uses kern.version and kern.osrelease for this.This sysctls
are read only. Any ideas how this issue can be fixed for
snmp in a easy way?

Regards,
Thomas

[Simon L. B. Nielsen]

Make the snmp daemon not do it that way and support magic new scheme
which we will hopefully come up with?

--
Simon L. B. Nielsen

[Thomas]

It would be nice if this could be part of a MIB for bsnmpd(1) in base or
net-snmp in ports.

FreeBSD-MIB for bsnmpd(1) uses uname(3) for freeBSDVersion
OBJECT-IDENTITY but according to the comments in FreeBSD-MIB.txt it can
be overwritten.

Not sure what net-snmp is using.

Regards,
Thomas