Log output to file
Issue #59
resolved
SSHGuard should be able to log its output to a file. Currently the only logging is done by sshg-blocker to syslog. One way to attack this:
- Change
sshg-blockerto log to standard error. - Redirect standard error output from the driver program to a pipe (for syslog) or to a file.
- Adjust where log messages are generated as necessary.
Proposed by: Doug Niven
Comments (5)
-
-
reporter
I guess from another perspective it only makes sense to log from
sshg-blocker, since logtail, parser, and fw are interchangeable components. In that case the only logs would come fromsshg-blockerand we can keep the syslog routines there.I'm hesitant to add more logging fun. Does systemd and the new log implement the syslog family of functions in a reasonable way?
-
OK, so both os_log and sd-journal can source syslog with no problems. That didn’t use to work, but I guess the world has made some progress on this since I looked at this last. syslog can also be configured to write to a file with only one modification.
I propose this modification as well as some rearranging of logging priorities (only log attacks and blocks) in this branch: https://bitbucket.org/sshguard/sshguard/branch/logging-facility
So it looks like the current logging facility are adequate. Although I really do want the log message priorities changed (see the above branch.)
Are you okay with these changes, @Partmedia? If so I say we merge them and close this issue.
-
reporter
Looks good to me; merge it!
-
- changed status to resolved
- Log in to comment
The Linux special interest group (uhm, me) has the following comment:
A systemd unit’s main process’ stderr and stdout will be logged to the journal. Can also be achieved by piping to systemd-cat. However, I’d say the preferred method is to use the sd-journal API (see sd_journal_print(3) so that logging can be done with the proper priority levels.
Adds dependency on libsystemd. Could be handled as simple as conditionally building systemd support when libsystemd is present on the system.
Similarly the macOS interest group (whoever that might be) would say that although log can be used to pipe logs to os_log, they’d prefer using the NSLog to os_log API. Again to handle log message priority and such in their own way.