> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of Ryan Lynch > Sent: Friday, July 30, 2010 3:29 PM > To: rsyslog-users > Subject: Re: [rsyslog] log forwarding through unix sockets > > On Tue, Jul 20, 2010 at 04:55, Ales Kozumplik <[email protected]> > wrote: > > 1) KVM opens a SOCK_STREAM on the host end but rsyslogd is only able > to > > read data from SOCK_DGRAM. This has two consequences: first, to be > able > > to attach rsyslog on the host end one first needs to copy the data > > between the two socket types, e.g. using socat. Second, messages > longer > > than 1024 characters are sometimes split into two. The second message > is > > thus missing the syslog header and the receiving rsyslogd doesn't > know > > where to file it. Is there a recommended workaround for those things > > (maybe a parameter I overlooked in the docs tellling rsyslogd to use > > SOCK_STREAM)? > > I ran into a similar problem. Doesn't it seem wierd that RSyslog: > - can write TO a pipe, but it can't natively read FROM a pipe. > - can read FROM a UNIX socket, but can't natively write TO a UNIX > socket. > The only protocols that Rsyslog can both read to AND write from are > network sockets (UDP, TCP, RELP) and real files. >
Quite honestly, I think this issue never came up until recently -- at least I didn't notice. It should be fairly simple to add a plugin to write to unix sockets, though... > I don't think the problem is your forwarding format--I don't think > it's possible for RSyslog to handle a HOSTNAME field, properly, in > messages received via socket. > > Based on my own tests, I believe that 'imuxsock' and 'imudp' use > different logic to parse incoming messages. 'imuxsock' always assumes > that the hostname is the local host, so it doesn't have the > conditional logic to differentiate between "forwarded" messages (which > have an extra HOSTNAME field between the timestamp and tag) versus > regular local messages (no HOSTNAME). The problem is that you do not have any reliable indication what is a hostname and what not. So far, I worked on the assumption that anything received via a local socket complies to the "usual format" for such messages. This means no hostname is present. However, there is a simple setting (parse hostname yes/no) which is part of the message object. Imuxsock sets it to "no", remote receivers set it to "yes". It should be fairly trivial to add a config setting which enables imuxsock to set it to "yes" as well. > This is a pretty reasonable > assumption, really--the local UNIX socket doesn't traditionally have > any way to receive messages forwarded from other hosts. > > Rainer could probably confirm this, or we could compare those two > modules' sources. > > RSyslog is a fantastic piece of software, and its feature set has come > a long way. But all of Rainer's excellent work has expanded our > imaginations about what Syslog can do, and maybe our imaginations are > advancing faster than he can code new features. The problem simply is that we are tackeling more complex things, and this also means things need more planning than in the past. For example, the latest round of performance enhancements took me 2 to 3 month of reading scientific papers and experimenting. This all resulted in a relatively small delta to the code, but this delta does not judge the work that went into it. Also, being primarily a lone guy, I need to focus on some things and leave others untouched -- otherwise I'll never make any progress (ever-swapping between different features). The current scope is configurability and performance, so other things have to wait (where I try to fit in small and useful items as it fits). What is being discussed here is small and useful ;) However, my summer break is approaching, and I'd like to finish a couple of loose ends (first config iteration, getting a new v4-beta ready). Also I (finally ;)) need to write an article for the upcoming Linux conference in Nuremberg, with the deadline rapidly approaching. So these are obviously my priority. Also I have to admit that I weigh features by their importance to the community at large. Those often requested receive higher priority, so they will preempt less requested features from being implemented when they have similar workload. Also, I prefer features requested/need by non-profits over those that have a clearly for-profit user base. The reasoning here is that the non-profit orgs will probably otherwise never get their features, whereas the enterprises can task someone with implementing such a features. And if an enterprise doesn't think it is worth tasking someone with implementing a feature, that is a clear indication that the enterprise doesn't actually think the feature is worth the effort. So I think there is a lot of logic in assigning priorities in this way ;) Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
