boot parameter question

[Paul Moore]

On Tue, Jul 30, 2019 at 5:52 PM Lenny Bruzenak <lenny at magitekltd.com> wrote:
> On 7/30/19 3:36 PM, Richard Guy Briggs wrote:
> > On 2019-07-30 15:06, Lenny Bruzenak wrote:
> >> On 7/29/19 4:32 PM, Richard Guy Briggs wrote:
> >>> It is being ignored because that kernel command line extension to the
> >>> original feature was never backported to RHEL7.
> >> That would definitely do it.
> >>
> >>> In hindsight, that would have been pretty useful without causing much
> >>> risk.  Normally feature backport is driven by customer demand.  There
> >>> was a bit of pushback when it was first introduced upstream, but this is
> >>> exactly the scenario I envisioned where it would be most useful.  It is
> >>> possible to compile your own kernel and change the default value, but
> >>> that's obviously a hurdle for most.
> >> It would definitely have been useful, some might say even necessary,
> >> given the audit event startup noise occurring with systemd.
> > Yes, this was yet another difficulty that arose with the change to
> > systemd from rhel6 to rhel7.  The intent was to solve it first in fedora
> > when it switched to systemd to address this since the number of startup
> > messages jumped from manageable within the default backlog size to
> > almost double.  There are also other improvements upstream that remove
> > some of the doubt about exactly how many log messages were lost.
> >
> >> Wow. Thanks Richard, I appreciate the answer on this.
> > It is all there in fedora and RHEL8, so that is one possible route.  It
> > is a bit late in the RHEL7 life cycle to commit to it, but not
> > impossible...
>
> Thanks Richard and I do appreciate the insight.
>
> For some it might be possible to switch OS baselines effortlessly,
> others (including my group) it isn't.
>
> I'm surprised other RHEL 7 consumers are not squawking; I wonder if they
> do not appreciate what they are not seeing? Or perhaps they are not
> starting as many services early in the boot sequence and therefore
> getting that one?

As a gentle reminder, this is the *upstream* Linux audit mailing list;
discussion about distro specific issues, especially older distros with
"enterprise" support, are best done offline via that distro's support
mechanism :)

-- 
paul moore
www.paul-moore.com