Hi all, after some testing rounds in this topic am currently arrived at a more simple configuration (without GnuTLS, Kerberos, ...) which works for me without problems also with the already integrated config.dat WUI extension for TCP protocols.
Current DEV state can be found in here --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=ee0fc28e... . A question arises for me now, should we substitute Sysklogd and Klogd with Rsyslog now ? If yes, how should we proceed further then ?
All the best,
Erik
Hello Erik,
thanks for working on this and sorry for the late reply.
Hi all, after some testing rounds in this topic am currently arrived at a more simple configuration (without GnuTLS, Kerberos, ...) which works for me without problems also with the already integrated config.dat WUI extension for TCP protocols.
Thanks again. Support for those protocols is not that important in my point of view, since I never saw anybody using SSL or similar for syslogging.
In fact, most "enterprise" software (which is enterprisely sophisticated) does not even support TCP. :-\
Current DEV state can be found in here --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=ee0fc28e... . A question arises for me now, should we substitute Sysklogd and Klogd with Rsyslog now ? If yes, how should we proceed further then ?
I think so, if there are no issues left. Will try and test (might take a while, since things are busy here...).
All the best,
Erik
Hi Peter,
Am Montag, den 09.04.2018, 19:43 +0200 schrieb Peter Müller:
Hello Erik,
thanks for working on this and sorry for the late reply.
Hi all, after some testing rounds in this topic am currently arrived at a more simple configuration (without GnuTLS, Kerberos, ...) which works for me without problems also with the already integrated config.dat WUI extension for TCP protocols.
Thanks again.
Your welcome, hope the work is useful. May you have recognize it already, have seen that the update.sh has been accidentally added in Git which won´t be needed (to much stuff in my building env ;)...
Support for those protocols is not that important in my point of view, since I never saw anybody using SSL or similar for syslogging.
Even if someone wants to send the logs to a remote area network OpenVPN/IPSec might therefor be a better solution in my opinion. Nevertheless, it is also possible to provide Rsyslog extensions via Pakfire for individual usage but that´s a kind of future music i think.
In fact, most "enterprise" software (which is enterprisely sophisticated) does not even support TCP. :-\
Yes that´s true.
Current DEV state can be found in here --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h =ee0fc28e34f30fe687f4ab9c9130240d27dd87d4 . A question arises for me now, should we substitute Sysklogd and Klogd with Rsyslog now ? If yes, how should we proceed further then ?
I think so, if there are no issues left. Will try and test (might take a while, since things are busy here...).
No problem, take the time you need, good that you find the changes.
Have meanwhile tested some other configuration directives which works mostly without problems. Have discovered one dysfunction, if new logs should be created via configuration file in the standard path won´t work cause Rsyslog drops the privileges to 'syslogd' and /var/log is owned by owner and group 'root' but in that case a manual creation of a desired new log with appropriate permissions should work without problems. Have tested also the remote logging (configured via WUI) for UDP and TCP and this works also via e.g.:
# # Template seperated logs for remote hosts # $template RemoteLogs,"/var/log/remotehosts/%HOSTNAME%/%$now%.log" if $fromhost-ip != '127.0.0.1' then -?RemoteLogs & stop
without problems, there was more but potentially not so interesting for the first.
Looking forward for some further steps in that topic then.
All the best,
Erik
-
Peter Müller -
ummeegge