You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
redis is currently used to buffer logs received over qrexec and then a service reads from redis and writes to the appropriate log files. It would be nice if we could use existing log aggregators for this purpose, e.g. systemd-journald or rsyslog.
So the flow would look like:
VM log entry --qrexec--> {something} --> rsyslog/journald --> log files
Where "{something}" pushes the log entry into rsyslog/journald. Maybe something exists off the shelf or we write a small thing for it. It will need to be fast or non-blocking to avoid the log sender waiting over the qrexec channel.
The text was updated successfully, but these errors were encountered:
Ro pointed me to the docs for qrexec socket services, which I think fit exactly what we need here. Instead of using redis to aggregate and queue messages, we could have a simple async service read messages off the socket and write to log files. So then the flow is:
VM log entry --qrexec--> sd-logger --> log files
zenmonkeykstop
changed the title
Evaluate redis alternatives
[securedrop-log] Evaluate redis alternatives
Dec 13, 2023
redis is currently used to buffer logs received over qrexec and then a service reads from redis and writes to the appropriate log files. It would be nice if we could use existing log aggregators for this purpose, e.g. systemd-journald or rsyslog.
So the flow would look like:
VM log entry --qrexec--> {something} --> rsyslog/journald --> log files
Where "{something}" pushes the log entry into rsyslog/journald. Maybe something exists off the shelf or we write a small thing for it. It will need to be fast or non-blocking to avoid the log sender waiting over the qrexec channel.
The text was updated successfully, but these errors were encountered: