getting the running patch level

Simon L. B. Nielsen simon at
Fri Aug 24 15:49:24 UTC 2012

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?

Simon L. B. Nielsen

More information about the freebsd-security mailing list