Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Aug 2012 16:46:37 +0200
From:      Paul Schenkeveld <freebsd@psconsult.nl>
To:        freebsd-security@freebsd.org
Subject:   Re: getting the running patch level
Message-ID:  <20120819144637.GA17778@psconsult.nl>
Resent-Message-ID: <20120820135857.GA4051@psconsult.nl>
In-Reply-To: <31946.192.168.0.107.1344505442.squirrel@mail.redix.it:443>
References:  <31946.192.168.0.107.1344505442.squirrel@mail.redix.it:443>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120819144637.GA17778>