Replies: 4 comments
-
Hi @patcamen . Interesting. I'm willing to make ldap2pg a good citizen with splunk and other auditing tools. Can you forge some sample of log lines you expect ? For auditing, do you need only Do you want a cli swithc like Another option would be to configure auditing in yml file: auditlog:
destination: /var/log/audit/ldap2pg.log
level: DEBUG
sync_map:
... That would be still configurable through env vars AUDITLOG_DESTINATION, etc. Thanks for the feedback. |
Beta Was this translation helpful? Give feedback.
-
Hi @bersace , The sample contains a subset of the current If I were to chose, I would probably want the audit log to be configured inside the yml file like you have shown above - as indeed other users might want to chose a different log level to go to the audit log. Also like this the audit log would be decoupled from the console verbosity set. Thanks. |
Beta Was this translation helpful? Give feedback.
-
hi @patcamen . re-reading your sample audit log, it looks like you suggest to increase the level of some messages and decrease the level of other. That's a good feedback. ldap2pg 6.0 has a new log format in logfmt. Almost all messages has been reviewed, including their level. I saw that some debug message of ldap2pg v5 are now at INFO level like you suggested. It would be very helpful if you could point me DEBUG log level you'd prefer at INFO and vice versa, for ldap2pg 6. Would you ? I prefer to make ldap2pg INFO message enougth for an audit log rather than a new auditlog feature. |
Beta Was this translation helpful? Give feedback.
-
Maybe a switch option would raise some debug message like ldapsearch commands and query to INFO level. |
Beta Was this translation helpful? Give feedback.
-
It would be great for auditing purposes if the ldap2pg tool could write verbose output to a logfile with timestamps - while it may retain the current output format without timestamps for the console for readability purposes.
Alternatively a flag to just enable timestamps in the current verbose console output would work also - in which case the output can then be redirected to a file if needed. An ISO 8601 formatted timestamp with millisecond granularity (e.g. 2021-11-10 15:52:10.200) should be good enough for a start.
This will also help in a corporate context where logfiles are often consumed by tools such as Splunk. They often struggle to parse messages correctly without timestamps - i.e. multiple log lines may end up being treated as one single message.
Beta Was this translation helpful? Give feedback.
All reactions