On Wed, Jun 17, 2015 at 7:51 AM, Ben Pfaff <b...@nicira.com> wrote: > On Wed, Jun 17, 2015 at 12:53:53AM -0700, Ansis Atteka wrote: >> This patch helps to address two issues on Ubuntu 15.04 (and most likely >> other Linux distributions) when rsyslog daemon is configured to relay >> log messages from OVS to a remote log collector: >> >> 1. libc syslog() function adds unwanted prefix to every message before >> sending it over /dev/log Unix domain socket; and >> >> 2. rsyslogd daemon that comes with Ubuntu 15.04 is too old and >> does not allow to specify custom syslog message parsers when >> it received message over Unix domain socket. >> >> Solution to those two issues would be to use >> --syslog-method=udp:127.0.0.1:514 >> argument when starting OVS. >> >> Signed-Off-By: Ansis Atteka <aatt...@nicira.com> > > It seems like syslog_libc_create() and syslog_direct_create() might more > usefully return a pointer to the inner syslogger structure, so that the > caller does not have to blindly cast. Ok, I can do that.
> > We've previously had a request to make it possible to turn off local > syslogging, only syslogging to the --syslog-target address. This could > now be done easily by adding a "none" --syslog-method that just throws > away log messages. I am not sure If I conveyed purpose of this patch clearly. 1) I actually thought to mark "--syslog-target address:port" flag as deprecated, because now one can achieve similar result with "--syslog-method udp:address:port". 2) I don't think that --syslog-target argument originally was introduced with the idea so that one would be able to log to remote syslog destinations. Instead it workarounds libc and rsyslogd limitations that are present on distributions like Ubuntu when one wants to use different logging format. For example, 1) current libc syslog() call adds fixed prefix to every message; and 2) current rsyslogd daemons do not allow to specify custom message parsers if message was received over UNIX domain socket. However, this rsyslogd limitation does not apply to messages that rsyslogd received over UDP socket. 3) --syslog-target flag really does not solve remote logging problem because: 3.1) it requires ovs-* daemon to be restarted whenever log collector's IP address changes 3.2) I don't see syslog message encryption being implemented in OVS to provide security for remote logging 3.3) if administrator would want to forward all syslog messages to a remote log collector he would have to update each individual daemon 3.3) Solution to 3.1), 3.2) and 3.3) is to configure rsyslogd daemon running on the same host as syslog relay and let the syslog clients to log to /dev/log or 127.0.0.1:514. I think that this is how admins actually would configure syslog. 4) --syslog-target is a hack too because it uses hardcoded syslog message format. > > The existing send_to_syslog_fd() has a fallback to handle messages that > are too long to send. I guess that's a real corner case that would only > come up for messages longer than about 64 kB, but it might still be > worth including in syslog_direct_log(). If I am reading [http://tools.ietf.org/html/rfc5424#section-6.1] correctly then the maximum syslog message length is limited by underlying transport protocol. In other words, for example, if one VLOG_INFO(long_message) invocation would lead to two UDP datagrams, then I don't see how syslog server would know how to stitch them together into a single logical syslog message. Also the write() in a loop approach for --syslog-target would not be thread safe if one day we would decide to use TCP for syslog. The while loop should be nested inside a lock. > > While we're at it, is it possible to also use the new syslog > infrastructure for --syslog-target? I guess that the syntax would be > compatible, if we assumed that anything that started with a digit was a > UDP target. Do you think it makes sense to maintain both - -syslog-method and --syslog-target at the same time? Can we just deprecate --syslog-target? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
