Currently we have a lot of infrastructure to handle the fact that we have our own custom logging system. Perhaps we should consider dropping that in favour of plain old syslog? It is available as an option currently, but it is not the default and we could only simplify things if it was the only option. Advantages of syslog is that it is how almost everything else on the system logs. It has network logging abilities and is a standardised system that allows compatibility with things like journald. syslog is also easier to use from any random part of thinlinc as it doesn't require write access to /var/log directly. The downside is that you can't easily get a log file per service like we have today.
The first step will be to investigate more and get a better list of advantages and problems with going with just syslog. We should also check why we chose a file based logging in the first place.
(In reply to comment #0) > The downside is that you can't easily get a log file per service like we have > today. It is pretty easy to get a logfile per process using syslog. rsyslog [2] "is" the de-facto [1] syslogd on linux and uses /etc/rsyslog.d for reading configuration rules. Consider the following example to get a specific logfile for vsmagent. /etc/rsyslog.d/vsmagent.conf :programname, isequal, "vsmagent" /var/log/vsmagent.log [1] See https://en.wikipedia.org/wiki/Rsyslog which lists dists and version from when they start using rsyslog, previous de-facto syslog server used was syslog-ng. [2] http://blog.gerhards.net/2007/08/why-does-world-need-another-syslogd.html
Summary of syslog logging: - A log message is prepended with (Processname or application defined ident) - A PID can also be logged with the message see. openlog() option LOG_PID. - Uses facilities and levels to categorize a log message, which gives the sysadmin great possibilities to control how things are logged, setup triggers for event generation such as SNMP traps etc. - Facilities: AUTH, AUTHPRIV, CRON, DAEMON, FTP, KERN, NEWS, SYSLOG, USER (default) - Levels: EMERG, ALERT, CRIT, ERR, WARNING, NOTICE, INFO, DEBUG Typical use: openlog("vsmserver", LOG_PID) syslog(LOG_AUTH|LOG_WARNING, "User x failed to authenticate"); Using openlog is optional but if one want to use application defined ident and/or LOG_PID, one need to use it.
(In reply to comment #1) > We should also check why we chose a file based logging in the first place. Bug 554 was about to improve the logging which was filebased from start. The solution using python logging module introduces the support for syslog. Didn't find any information / reasoning why filebased is default and used but probably a inheritance from start.
Can we use syslog for all logging or do we have special logging that does not fit in syslog ? (Think http access logs for tlwebadm / tlwebacces) etc. Identify our logfiles and summarize the content to get a feel of what we have and how we could handle them.
(In reply to comment #5) > Can we use syslog for all logging or do we have special logging that does not > fit in syslog ? (Think http access logs for tlwebadm / tlwebacces) etc. > > Identify our logfiles and summarize the content to get a feel of what we have > and how we could handle them. # /var/log/thinlinc-install.log Logfile created by ThinLinc installer. This log does not fit for syslog, it is a user application started by user at specific times. # /var/log/tlsetup.log tlsetup.log is created by tl-setup, a tool which should be run at each install / upgrade. This log does not fit for syslog, it is a user application started by user at specific times. # /var/log/thinlinc-user-licenses Some kind of database for licenses, written to by sessionstore and parsed by parse_licenselog... Does not fit syslog. # /var/log/tlwebaccess.log This logfile contains both http access log like apache and service logging. The access log part does not fit syslog and need to split out... # /var/log/tlwebadm.log This logfile suffers of same problems as tlwebaccess.log above. # /var/log/vsmagent.log This logfile is for the vsmagent service which would work perfect with syslog. # /var/log/vsmserver.log This logfile is for vsmserver service which would work perfect with syslog.
(In reply to comment #5) > Can we use syslog for all logging or do we have special logging that does not > fit in syslog ? (Think http access logs for tlwebadm / tlwebacces) etc. > > Identify our logfiles and summarize the content to get a feel of what we have > and how we could handle them. # /var/opt/thinlinc/sessions/<user>/last/xinit.log This logfile catches stdout/stderr from anything running within the session (tl-xinit). tl-shadow-notify-helper also reads and parse this logfile to track connections.
