In some email I received from [EMAIL PROTECTED], sie wrote: [...] > I"dare say we do not suffer on a "Not Invented Here" syndrome! Personally, I > have argued to use syslog-sign and syslog-reliable. I did look into the > latter > implementations efforts. > > However for syslog-reliable, as good as the protocol is, there are no > implementations yet!
And you didn't implement it because ? > We (my customer: "the Dutch tax computer centre") are not developing a > "box", or > sw in general! > We try to run a network :-) And USE the standard. And/or demand (ask > politely:-) that > it is used by the boxes (routers, switches, computers, ...) we need. > We can make small implementations ourselves (or let them make ..) , as last > resort. > > So, Syslog-reliable isn't option NOW. As we can't "get" it! ...and rather than build syslog-reliable, which has been put through a process of international peer review, by intelligent people, you've gone away and designed your own protocol. I imagine this is because it is easier to hack together some software to do what you want and invent it as you go rather than implement to a pre- published spec. (I know, I write software too :) > And for security and efficiently (of out firewall), UDP isn't "nice". The > management demands a > TCP link. > > So, I had several options and non options > * NO syslog-reliable > * NO UDP > * NO "self invented, hard to maintain ..." > * Bay something that is open and good (Non found) > * Use opensource, and make sure the customer can maintain it themselves > * Implement a simple protocol > * ... > > As said, syslog-ng, and others, already do use a TCP binding. I have opt for > that. > However, as it only sends the rawdata, which make it hard to extent, should > it ever > be needed. E.g. to incorporate kerberios authentication (which is "hot" > here:-) nsyslogd wasn't just rawdata when I last looked but maybe syslog-ng is much more different now (I haven't looked in ages.) I could probably extend the nsyslogd protocol to do Kerberos authentication, as required, the hard part is, typically speaking, getting things like that to happen in an asynchronous manner over a network connection it doesn't control. > So, we tried to extend "your" protocol. We use small headers as "commands", > but still > have the /n as sync. But we can also setting up "reverse" connections (to > fetch log, > instead of push it) and do other "tricks". > As this with a small protocol, and a small, simple to maintain > implementation. Generating log information is about having it pushed from the source, not pulled from something else. What you think of as a neat "trick" might be seen by others as an obscene 'hack'. I don't understand what you mean about '/n' as a sync, unless you mean to say you're using a text protocol. I threw out doing a protocol like that because it is harder to make secure (IMHO) because you have to deal with text things that may have an arbitary length, complicating parsing the information. [...] > I will end with another quote of Darren: > > that it at least fulfills all the requirements that syslog over TCP has > > (and that's more than just sending messages in text over a TCP > connection.) > Because I really agree with him. We (I) needed a simple protocol. Simple but not secure or both or maybe neither, just syslog-over-TCP ? > However, I hope we can cooperate and fill the gape between the current > not-standard > pratice of syslog-over-TCP and the "high end" syslog-reliable. I would like I don't see how anything anyone could offer, at this point in time, can be classed as anything but "not-standard practive of syslog-over-TCP", to use your own terminology. Darren
