> On Fri, Feb 22, 2008 at 11:31:36AM +0100, Oliver Fromme wrote:
> > If you insist on writing a patch, then please make it
> > default off.
>
> rink@ just provided one, and it does default to off. I fully agree with
> defaulting it to off as well; those of us that want it on can set it as
> such
On Fri, Feb 22, 2008 at 02:46:31AM -0800, Jeremy Chadwick wrote:
> I'll try out said patch this weekend. Assuming it works, and does get
> committed, I'll be more than happy to submit a PR along with a patch to
> update the loader.8 manpage, documenting kern.ignore_old_msgbuf.
Sounds good to me.
On Fri, Feb 22, 2008 at 11:31:36AM +0100, Oliver Fromme wrote:
> If you insist on writing a patch, then please make it
> default off.
rink@ just provided one, and it does default to off. I fully agree with
defaulting it to off as well; those of us that want it on can set it as
such in loader.conf
Jeremy Chadwick wrote:
> Oliver Fromme wrote:
> > [...]
> Either way, it's a feature with major security implications. So, for
> those of us who are concerned about master.passwd changes via
> mergemaster being stuffed into msgbuf, how do we disable said feature?
> (Before answering, see bel
On Fri, Feb 22, 2008 at 02:09:24AM -0800, Jeremy Chadwick wrote:
> Maybe I should look into writing a patch that does in fact clear the
> buffer immediately before reboot, and tie it to a sysctl.
I suggest just making a loader tunable to do this. I think the following
should do it (untested):
---
On Fri, Feb 22, 2008 at 10:52:54AM +0100, Oliver Fromme wrote:
> Jeremy Chadwick wrote:
> > Oliver Fromme wrote:
> > > Upon a reboot, the kernel is usually loaded to the same
> > > physical addresses in RAM where it was before, so the
> > > dmesg buffer will be at the same location, too (unless
Jeremy Chadwick wrote:
> Oliver Fromme wrote:
> > Upon a reboot, the kernel is usually loaded to the same
> > physical addresses in RAM where it was before, so the
> > dmesg buffer will be at the same location, too (unless
> > you built a new kernel, of course). So all the contents
> > from
On Feb 22, 2008, at 02:25 , Jeremy Chadwick wrote:
[...]
Interesting tidbit: We have one production machine which when booted
into single-user via serial console for a world install, retains all
of
the output from that single-user session even once rebooted and
brought
back into multi-use
On Fri, Feb 22, 2008 at 09:28:35AM +0100, Oliver Fromme wrote:
> Bartosz Giza wrote:
> > I have found quite interesting feature on one of router that lately i have
> > taken to administer.
> > What i knew was that file /var/run/dmesg.boot holds data from kernel
> buffer
> > that is taken rig
Bartosz Giza wrote:
> I have found quite interesting feature on one of router that lately i have
> taken to administer.
> What i knew was that file /var/run/dmesg.boot holds data from kernel buffer
> that is taken right after file system(s) are mounted.
> Lately i have found that one router
On Thu, Feb 21, 2008 at 10:29:40PM +0100, Bartosz Giza wrote:
> Hi,
>
> I have found quite interesting feature on one of router that lately i have
> taken to administer.
> What i knew was that file /var/run/dmesg.boot holds data from kernel buffer
> that is taken right after file system(s) are m
Hi,
I have found quite interesting feature on one of router that lately i have
taken to administer.
What i knew was that file /var/run/dmesg.boot holds data from kernel buffer
that is taken right after file system(s) are mounted.
Lately i have found that one router writes to this file data from
12 matches
Mail list logo
