On Wed, Jun 17, 2015 at 10:28:09AM -0700, Ansis Atteka wrote: > 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.
OK, I misunderstood the intent, plus this is kind of a mess anyway. After talking to you face-to-face, it sounds like another approach may be possible that would avoid code changes. Let's pursue that approach first. > > 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. I believe that the code in send_to_syslog_fd() attempts to truncate the message to (approximately) the longest length that will actually fit within a datagram. This should work because attempts to send too-long datagrams fail without sending anything (rather than sending a truncated datagram). > 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. Certainly that code would not work with TCP, but other changes would also be required to use TCP. > > 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? I'd be happy to deprecate it, as long as we retain it for some time for backward compatibility. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
