On 8/24/12 5:49 PM, Simon L. B. Nielsen wrote:
> On Fri, Aug 24, 2012 at 1:52 PM, Thomas 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:
>>>
>>
On Fri, Aug 24, 2012 at 1:52 PM, Thomas 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, currentl
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 versio
On 2012-08-22 13:40, olli hauer wrote:
> On 2012-08-22 12:44, Adrian Penisoara wrote:
>> Hello,
>>
>> On Tue, Aug 21, 2012 at 6:49 PM, Roger Marquis wrote:
>>> Jilles Tjoelker wrote:
>> [...]
>>>
>>> WRT writing a new file, something like /etc/bsd-release would be a good
>>> choice following the p
On 2012-08-22 12:44, Adrian Penisoara wrote:
> Hello,
>
> On Tue, Aug 21, 2012 at 6:49 PM, Roger Marquis wrote:
>> Jilles Tjoelker wrote:
> [...]
>>
>> WRT writing a new file, something like /etc/bsd-release would be a good
>> choice following the principle of least surprise. Mergemaster can and
Hello,
On Tue, Aug 21, 2012 at 6:49 PM, Roger Marquis wrote:
> Jilles Tjoelker wrote:
[...]
>
> 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, ...).
>
I suppor
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-rele
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
On 2012-Aug-19 16:46:37 +0200, Paul Schenkeveld wrote:
> - 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.
I'm not sure what detail you intend her
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
>
On 08/19/2012 05:33, 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 forma
On Sat, Aug 11, 2012 at 09:05:44PM +0200, Dag-Erling Smørgrav wrote:
> "Simon L. B. Nielsen" writes:
> > This has been discussed a number of time, but there are no nice and
> > simple solution.
> There is a simple solution that, while not bulletproof, would work well
> enough in most cases: have
Manolis Kiagias writes:
> One could also set the environment variable UNAME_r to the correct
> value (either in system wide e.g. /etc/profile or to a specific user
> dot files).
If your goal is to have uname(1) return the correct value, yes, except
it won't always work. For instance, sudo(1) (an
On 13/08/2012 22:27, Dag-Erling Smørgrav wrote:
Jason Hellenthal writes:
Could I suggest... the same way that /etc/motd is already updated ?
You could, but it wouldn't be very helpful, since /etc/rc.d/motd uses
uname(1), which returns the kernel version. On the contrary, once
/etc/issue is in
Jason Hellenthal writes:
> Could I suggest... the same way that /etc/motd is already updated ?
You could, but it wouldn't be very helpful, since /etc/rc.d/motd uses
uname(1), which returns the kernel version. On the contrary, once
/etc/issue is in place, we should use that instead of uname(1) to
On Sat, Aug 11, 2012 at 09:05:44PM +0200, Dag-Erling Smørgrav wrote:
> "Simon L. B. Nielsen" writes:
> > This has been discussed a number of time, but there are no nice and
> > simple solution.
>
> There is a simple solution that, while not bulletproof, would work well
> enough in most cases: hav
"Simon L. B. Nielsen" writes:
> This has been discussed a number of time, but there are no nice and
> simple solution.
There is a simple solution that, while not bulletproof, would work well
enough in most cases: have 'make installworld' create /etc/issue, which
would look like this:
FreeBSD 9
On 2012-08-10 16:40, Simon L. B. Nielsen wrote:
> On Fri, Aug 10, 2012 at 1:06 PM, Roberto 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 n
On 08/10/2012 11:55 PM, Chris BeHanna wrote:
> Split off a version.ko and update that with each patch?
There is often no need to reboot the machine unless the kernel is
affected (just restart the affected daemons). Thus the information would
not necessarily match the userland status. The use
On Aug 10, 2012, at 09:40 , Simon L. B. Nielsen wrote:
> On Fri, Aug 10, 2012 at 1:06 PM, Roberto 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 dis
On Fri, Aug 10, 2012 at 1:06 PM, Roberto 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 i
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.
I also read about put some syscall to return from the kernel the current patch
level, but still this solution is "bound" to the kernel modification, which
c
On 09/08/2012 23:13, Glen Barber wrote:
> On Thu, Aug 09, 2012 at 03:31:25PM -0600, Brett Glass wrote:
>> > I realize that sysinstall is deprecated in favor of the new installer, but
>> > the new installer doesn't have the ability to install binary packages.
>> > Until and unless there's a convenie
On Thu, Aug 09, 2012 at 03:31:25PM -0600, Brett Glass wrote:
> I realize that sysinstall is deprecated in favor of the new installer, but
> the new installer doesn't have the ability to install binary packages.
> Until and unless there's a convenient menu-based installer for binary
> packages, woul
Yes, uname -v will work. Unfortunately, it has an annoying side effect. If one
tries
to use the "sysinstall" program to install binary packages, it will fail when
a system patched by freebsd-update tries to access the FTP server, because the
FTP
server doesn't know about patch levels.
One must
...@freebsd.org
[mailto:owner-freebsd-secur...@freebsd.org] De la part de Roberto
Envoyé : jeudi 9 août 2012 15:39
À : Károly Arnhoffer
Cc : freebsd-security@freebsd.org
Objet : RE: getting the running patch level
Importance : Haute
just a try on the server:
--
% uname -a
FreeBSD .yy
..@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 ha
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
r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
If I read the handbook
>> 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
>> o
: 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 nee
Wiadomość napisana przez "Roberto" 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
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 fo
32 matches
Mail list logo
