Good idea!

But...that doesn't address how to have a size/date retention that's specific to 
that entry.

But the trickiest issue is how to have specific audit types (again, namely 
syslog 'authpriv') have the same kind of namespace assignment. This would be 
like what you would filter via '-t' or '--identifier'.

This is expressly the kind of logging information that has express retention 
requirements. But we wouldn't want to have the same retention requirements 
apply to all other logging information, primarily due to the extremely large 
storage requirements that might entangle.
________________________________
From: Lukáš Nykrýn <lnyk...@redhat.com>
Sent: Monday, August 12, 2024 3:17 AM
To: SCOTT FIELDS <scott.fie...@kyndryl.com>
Cc: systemd-devel@lists.freedesktop.org <systemd-devel@lists.freedesktop.org>
Subject: [EXTERNAL] Re: [systemd-devel] journal: question regarding retention 
options by priority/identifier/unit

Hello! I only briefly tested this, but I believe you can use journal 
namespaces. I tweaked the Service stanza in systemd-journald-audit. socket to 
"systemd-journald@ audit. service" restarted everything and now I have audit 
messages separated

Hello!

I only briefly tested this, but I believe you can use journal namespaces.
I tweaked the Service stanza in systemd-journald-audit.socket to 
"systemd-journald@audit.service" restarted everything and now I have audit 
messages separated in /var/log/journal/4339da6539564b07a62c1604525309ff.audit
And since the instance can have separate configuration file 
(/etc/systemd/journ...@audit.conf) you could set a different retention policy 
there. Check the journald.conf manpage.

Lukas

ne 11. 8. 2024 v 23:52 odesílatel SCOTT FIELDS 
<scott.fie...@kyndryl.com<mailto:scott.fie...@kyndryl.com>> napsal:
In the syslogd configuration, you can arrange to have specific retention 
factors for a given class of information.

AKA, I can have all kernel messages go to a specific file and that file can 
have a retention/rotation specified by size or date

For example, I can ensure I have 90 days of data for 'authpriv' level syslog 
data, if audit requires it. And that data would ONLY include 'authpriv' level 
data.

I don't see any options in journald to limit the scope for 'system' journal 
data, when configured to be persistent.

Are there any configuration options (or options in plan for the future) that 
will allow me to split this level of data into different managed storage with 
its own retention polices, much like how syslogd currently allows?

The long term goal in this case is to deprecate syslogd for audit record 
retention (among other uses).


Scott Fields

Kyndryl

Senior Lead SRE – BNSF

817-593-5038 (BNSF)

scott.fie...@kyndryl.com<mailto:scott.fie...@kyndryl.com>

scott.fie...@bnsf.com<mailto:scott.fie...@bnsf.com>


Reply via email to