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 ? thanks Roberto
Wiadomo?? napisana przez "Roberto" <robertot@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-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
Hi, As I can remember # uname -a provides this information. Regards, Karoly -----Original Message----- From: owner-freebsd-security@freebsd.org [mailto:owner-freebsd-security@freebsd.org] On Behalf Of Roberto Sent: Thursday, August 09, 2012 11:44 AM To: freebsd-security@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 ? thanks Roberto _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
>> 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 -aUnfortunately 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. -- ???? ????????
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 root@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 On Thu, Aug 9, 2012 at 8:02 AM, cronfy <cronfy@gmail.com> 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 ? > > 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. > > -- > ???? ???????? > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org > " >
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 root@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 On Thu, August 9, 2012 13:44, K?roly Arnhoffer wrote:> Hi, > > As I can remember > # uname -a > provides this information. > > Regards, > Karoly > > -----Original Message----- > From: owner-freebsd-security@freebsd.org > [mailto:owner-freebsd-security@freebsd.org] On Behalf Of Roberto > Sent: Thursday, August 09, 2012 11:44 AM > To: freebsd-security@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 ? > > thanks > Roberto > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" >
On Fri, Aug 10, 2012 at 1:06 PM, Roberto <robertot@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
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
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