Red Hat Bugzilla – Bug 487838
Logging to a Remote System During Installation uses syslog instead of rsyslog
Last modified: 2009-03-27 09:35:45 EDT
Description of problem: Section A.3. Logging to a Remote System During the Installation. The procedure refers to configuring a log server using syslog, but the default for Fedora 10 is rsyslog. Recommend changing documentation to reflect the default log service.
Version-Release number of selected component (if applicable): Fedora 10
Wow, thanks for catching this William.
For the moment I have corrected this in what will be the F11 branch. I am not closing yet as I want someone else to sanity test my changes to this section and make sure the directions really work, though they should since rsyslog honors syslogd.conf syntax.
William: I've pushed up a draft pdf of the F11 Install Guide - please check the syslog section and see if it is satisfactory. If so we'll push to F10 and work on republishing in the hopefully not too distant future.
Commit log below:
Author: David Nalley <email@example.com>
Date: Tue Mar 24 08:31:51 2009 -0400
changed A.3 syslog section to reflect that Fedora uses rsyslog Bug 487838
It has been a while since I last looked at this, but I can remember having trouble using the old syslogd.conf syntax. The configuration you are referring to in the documentation is actually in /etc/sysconfig/rsyslog and not /etc/rsyslog.conf. This method did not work for me and also does tell rsyslogd to listen on port 514 for incoming remote log messages.
Another reason is that the system would produce warning messages. This sentence is taken from the man page for rsyslogd: "Please note that rsyslogd issues warning messages if the -c3 command line option is not given."
An easier solution is to uncomment the $ModLoad and $UDPServerRun lines to enable UDP syslog reception in /etc/rsyslog.conf. See below and the attached diff.
# Provides UDP syslog reception
Another thing to note is that port 514 will have to be open on the firewall for the UDP protocol. There are a number of ways to do this. I set up my local network as a trusted interface which opens things up quite a bit. This may not be desirable for some installations. A better option might be to just open UDP port 514 for the local network or a particular machine. The ultimate goal here is obviously to limit exposure to the situation described in the "Only Enable Remote Syslog Access on Secured Networks" warning box.
Created attachment 336481 [details]
diff between delivered rsyslog.conf and conf to receive remote logging
In the diff I noticed the addition of a $template DynFile to my rsyslog.conf. This was meant to write logs from the remote system to a separate log file rather sending them to /var/log/message. I must have missed something else in the config because it continued to send messages to the default location. The separate log file was never created. It wasn't that important to me at the time so I just let it be. If I figure it out I'll let you know.
Woops, just reread my comments and I missed a key word in Comment #2, first paragraph, last sentence should read "...does not tell rsyslog..." instead of "...does tell rsyslog..."
I did strike the line out that you had for sending messages to a separate file for each host. And just left the uncommenting stuff in.
I pushed the following commit:
Author: David Nalley <firstname.lastname@example.org>
Date: Thu Mar 26 07:57:44 2009 -0400
trying to finish the syslog edits 487838
You can take a look at the changes:
I think that should be minimally enough to get it working.
Though I'd welcome the line for per host files.
I agree, that should be enough to get it working. The new documentation looks good to me. I would make just one formatting change. Remove the space in front of $UDPServerRun 514 to line it up with $ModLoad imudp.so. Not really a problem, just makes it look neater and blend in with the rest of the config.
Yesterday I started looking at the per host log files. Using rsyslog is new to me and it will take me a while to learn the directives, configure, and test. Probably best to save this for another day and push the documentation changes forward.
Alright - we'll close this ticket now, and perhaps reopen or create a new for F12 IG
Thanks for your help William!