getting the running patch level

Thomas freebsdlists at
Fri Aug 24 17:28:50 UTC 2012

On 8/24/12 5:49 PM, Simon L. B. Nielsen wrote:
> On Fri, Aug 24, 2012 at 1:52 PM, Thomas <freebsdlists at> wrote:
>> On 8/19/12 4:46 PM, Paul Schenkeveld wrote:
>>> On Thu, Aug 09, 2012 at 11:44:02AM +0200, Roberto wrote:
>>> 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.
>> 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?
> Make the snmp daemon not do it that way and support magic new scheme
> which we will hopefully come up with?

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.


More information about the freebsd-security mailing list