audit logs quite hard to see with standard VT colors

[AdamWill]

Since 194da5c (thanks to Kazuo Morikawa for finding the commit), systemd colors audit logs in 'ANSI blue' by default. On a VT on a stock Fedora install - which I think will be the same on other distros and *nixes - this is quite hard to read, as the blue used for 'ANSI blue' is a pretty dark one, and the background color is black.

On Fedora with GNOME Terminal the default color palette is 'Tango' with color scheme 'Tango Dark' and with this combo a medium-light blue is used on a dark grey background, so that's quite readable. I don't know about other terminal apps. But it's definitely pretty bad on VTs.

It's difficult to pick colors that work for everyone all the time, but being hard to read on a VT seems bad :/

Here's a photo of my screen. If anything, the photo brightens things a tad and makes it look slightly easier to read than it is in person.

[poettering]

It was kinda the intention to hide it a bit, since it's boring info.

[AdamWill]

but...making it unreadable doesn't hide it, it just makes you squint much harder to figure out that it's boring info :( also not much use when it occasionally is important.

if it's boring info, wouldn't it make more sense to reduce its log level or something so it doesn't show by default, but when you do need to see it, it's readable?

[poettering]

uh, on which site did this end up?

[kjetilho]

You can modify the colours in a Linux VT to your liking.
http://man7.org/linux/man-pages/man4/console_codes.4.html

ESC ] P nrrggbb: set palette, with parameter given in 7
                          hexadecimal digits after the final P.  Here n
                          is the color (0–15), and rrggbb indicates the
                          red/green/blue values (0–255).
ESC ] R: reset palette

Example:

echo -en "\e]P0303030" # Make black light gray
echo -en "\e]P7df6020" # Make white orange
echo -en "\e]PFff8040" # Make bright white bright orange

[AdamWill]

I mean, it wouldn't hurt. Personally I like most of the colors, though, especially having error messages in red is useful. Just this one doesn't work for me. :P

edit: as for 'which site' - 4chan, apparently. No, I didn't send it there...

[keszybz]

a no colours flag might help

SYSTEMD_COLORS=0

Just this one doesn't work for me. :P

But maybe it's something to fix in the colour palette? Having a foreground colour in the standard palette of 16 colours that is not distinguishable from the background doesn't make much sense.

It was kinda the intention to hide it a bit, since it's boring info.

The info is boring because journalctl does not interpret it. Hex strings are boring to read, numerical syscalls are boring etc. I never understood why journal logs audit events. I also don't understand why journal/systemd makes it so hard to turn this functionality off. Yes you can mask the journald-audit socket but lst time i tried that was really messy. Anyhow I do agree that this is a non-issue. Anyone leveraging audit in a meaningful way is surely not using journal to do it. So it might as well not be there at all.

How about we add a equivalent to ReadKmsg= for audit like ReadAudit= and default to off (and while were at it set ReadKmsg= off as well by default

[poettering]

the audit stuff can have interesting info, if you actually install audit rules and that's why we pick it up. Moreover if you run selinux it also contains interesting info to some people too (though you probably need a degree in advanced selinuxology to grok it fully). But the majority of data isn't too interesting, simply because the tools generating it also tend to generate regular log events on the same cases in a much more readable and often even structured way. Hence I am fine if the data is not as visible as the rest.

If auditing is enabled in the kernel we pick it up since it otherwise would just end up in dmesg anyway, and then we couldn't isolate it out so easily. It's an exercise in picking it up for isolation, that's all.

The audit stuff is implemented via socket activation, i.e. a socket unit is established before the journal starts up, hence ReadAudit= isn't really the right approach, since that file is read too late.

systems that have no SELinux probably should turn off audit altogether if you ask me, in the kernel. (i.e. audit=0 on the kernel cmdline, or compile it out). That said, IIRC RHEL turns off audit pickup in journald by default though, to hide the data completely.

the audit stuff can have interesting info, if you actually install audit rules and that's why we pick it up.

Then enhance journalctll to interpet the events (at least optionally) The events in raw form are hard to interpret. This makes your suggestion that you enable it in journal because events can be interesting moot. IMHO There is no good way to actually use/read the data provided by journal.

I will give you an example. Just to filter out avc type event logs I have to journalctl -r _AUDIT_TYPE=1400, I need to at least be able to use also journalctl -r _AUDIT_TYPE=avc