I wonder if systemd-journald is a new implementation of syslog protocol, or rather, it uses syslog implementations, such as rsyslog, syslog-ng
I've googled a bit, but I didn't find nothing convincing about it.
Systemd-Journald – Is It a Syslog Implementation?
syslogsystemd-journald
Related Solutions
You can write a poor man's syslog server quite easily with socat. You just need a service unit like this:
[Service]
Restart=on-success
ExecStart=/usr/bin/socat -u UDP-RECV:514 STDOUT
It will blindly send anything received on the syslog service port to the systemd journal. Save the above as, say, /etc/systemd/system/syslog.service and then
# systemctl daemon-reload
# systemctl start syslog
You then just need your source to send messages to UDP port 514 on your listening server.
You may want to enhance this to actually parse the received data and format it but it isn't necessary if all you want to do is journal what's received.
(socat is in the Arch Linux Extra repository: pacman -S socat)
You have a lot going on there..... My best answer to this is to explain simply how I have seen session logging done in the past. Hopefully that will give you some options to explore.
- As you have already mentioned, pulling the
bash historyfrom the user accounts. This only works after the session has ended. Not really the best option but it's easy and reliable. - Using a
virtual terminalsuch as thescreencommand in Linux. This is not very robust as it starts on the user login however if they know it's being logged you can still kill the service. This works well in an end-user scenario. End users generally are trapped in a specified area anyway and don't have the knowledge to get around this. - Pam_tty_audit module &
aureport --ttyThis is a tool that allows you to specify which users get logged and allow you to specify the storage location of said logs... as always keep the logs off of the host server. I have the session logs on our SFTP server being copied off to a central logging server and a local cronjob moving them to a non shared location for archive.
This is built in for RedHat and Fedora however you can install it on Debian and Ubuntu. It's part of the auditd package I believe. Here is some documentation on auditd and the required configuration changes to pam (in /etc/pam.d/system-auth), specifying a single user here(root):
session required pam_tty_audit.so disable=* enable=root
Example output of aureport --tty:
TTY Report
===============================================
# date time event auid term sess comm data
===============================================
1. 1/29/2014 00:08:52 122249 0000 ? 4686960298 bash "ls -la",<ret>
Best Answer
As far as protocols are concerned,
systemd-journald…/run/systemd/journal/stdout. systemd connects the raw standard outputs and errors of services (that have defaulted to or that explicitly haveStandardOutput=journal/StandardError=journal) to this socket. It thus receives the protocol of variable length free-format records terminated with linefeeds./run/systemd/journal/dev-log, which is symbolically linked from/dev/log. This receives the protocol that thesyslog()library function in the GNU C library, linked into applications, speaks./run/systemd/journal/syslog. This also receives the protocol that thesyslog()library function in the GNU C library speaks (althoughsystemd-journaldactually uses another library and another function to speak it)./dev/kmsg. This receives the protocol that the Linux kernel speaks, which is a protocol of variable length, largely free-format, records terminated with linefeeds./run/systemd/journal/socket. This is analogous to the GNU C library case in that applications link to a library that speaks a certain protocol to this socket; except that the function issd_journal_sendv(), it is in a systemd C library that applications link to, and the protocol is not standardized but is a systemd-only protocol comprising an array of key=value pairs, and optionally a readable file descriptor, in each datagram.The protocol spoken by the
syslog()function in the GNU C library is neither RFC 5424 nor RFC 3164, and is effectively its own de facto standard. It isn't RFC 5424 because it does not have the correct amount of whitespace and the dashes designating optional fields with NIL values. It is not RFC 3164 because it has aPROCIDfield instead of aHOSTNAME.A couple of years ago, your systemd operating system would have had:
systemd-journalddoing all of the above (and some things which are irrelevant when it comes to protocols) and being the server that the GNU C library and the systemd C library talk to using their respective protocolsxinetd/inetd-style when something attempts to send messages to/run/systemd/journal/syslogand receiving the socket as an open file descriptor, or as a straight service configured to open and listen on/run/systemd/journal/syslogwith its (equivalent of the rsyslog)imuxsockmodule; and speaking the GNU C library protocolNowadays, your systemd operating system has:
systemd-journaldagain doing all of the above and being the server that the GNU C library and the systemd C library talk toimjournalmoduleFurther reading