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
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
