MonitorWare Knowledge Base

Hello.

Currently I'm trying to make simple python wrapper around liblogging to enable easy and reliable (rfc 3195) sending of logs to rsyslog.
The documentation of liblogging looks quite outdated (year 2005) and lacking of actual examples. Googling didn't help either. Could you please point me to some examples of using liblogging to send rfc 3195 (both raw and cooked) and how to prepare data for sending (is there any helper functions in liblogging to properly format data or something like this?).

It would be also great to know about project future: are you going to continue development or to abandone liblogging in favor of something else?
Is there any plans to switch to GPLv3 - it would ge great to my mind.

kind regard.

• Custom written rsyslog.conf?
• Maintenance Contract?
• Installation support?

Hi,

there is a sample client and server application available as part of the libloging source. I suggest you have a look at these (they are recalled something along the lines of testdrvr.c - let me know if you don't find them).

All in all, liblogging is currently in hibernation and I am not sure if it will awake again. The reason simply is that RFC 3195 seems to be a market failure. I've put a lot of effort into the library, and it unfortunately looks like this was wasted. So a while ago I made the decision to waste no more time. It will evolve if RFC 3195 gets into much more widespread use.

However, I have begun to engineer and implement a similar capable but less complex protocol. It is named RELP. If you are interested, you can find some details here:

http://blog.gerhards.net/2008/03/relp-r ... tocol.html

Rainer

Thanks for advise - I'll take a look for sample client code.

As for REPL - I already read about it: it's quite interesting but 3 magical letters RFC sounds a lot more promising - dispite current lack of interest on market
Still I would be glad to use library that support both... just in case.

I doubt that liblogging will be alive again without your personal efforts... at least not with current license: just like you and many other people I
do not see a point of giving away my source code to proprietary competitors.

Btw, thanks for great job!

Ah the old chicken and egg problem... too bad, because BEEP is a really well designed protocol.

Is there any way to get testdrvr working with rsyslog?
I have in my rsyslog.conf

$ModLoad im3195

But sockstat doesn't report it listening on anything.
If I add "-t601" on the command line, I get some garbage on the console but testdrvr hangs in srAPIOpenlog()

Completely broken?

Skye

Quite honestly, 3195 is receiving so few attention, I do only paid work on it. Too much work was uselessly done... If that changes (dramatically) or a sponsor shows up, I will investigate further.

Oh, and I forgot the mention: you need to start up a listener. Sample in doc: http://www.rsyslog.com/doc-im3195.html

I've read http://www.rsyslog.com/doc-im3195.html
But as I said above:

$ModLoad im3195

But sockstat doesn't report rsyslogd listening on anything.
If I add "-t601" on the command line, I get some garbage on the console but testdrvr hangs in srAPIOpenlog()

I suggest you use "$Input3195ListenPort 1601" as given in the sample

I have, and it makes no difference. rsyslogd does not listen on that address.

# sockstat
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root rsyslogd 3727 0 dgram /var/run/log

Also, the documentation says the default for Input3195ListenPort is 601, which implies the directive is optional.

Thanks

snott wrote:Also, the documentation says the default for Input3195ListenPort is 601, which implies the directive is optional.

It's not optional.

Could you get me a debug log? You can mail it to me privately at rgerhards@gmail.com. Info here:

http://www.rsyslog.com/doc-troubleshoot.html

May I also ask who will be sending the messages (out of curiosity)?

I thought this was a problem in liblogging (I used 0.7.1) because the default port was set to 0 but I discovered that when starting rsyslog in debug mode, the server is correctly listening...

"rsyslogd -c3" does not listen on port 601
"rsyslogd -c3 -d" does listen on port 601

For testing, my rsyslog.conf contains only the following two lines:

Code: Select all

$ModLoad im3195
$Input3195ListenPort 601

I will explore this later today and will be posting my findings here.

As for the sender: I want to use EventReporter on Windows to send via RFC3195.

just a warning: I don't know of any serious deployment of RFC3195, so it might be useful to think about pursuing that path...

rgerhards wrote:just a warning: I don't know of any serious deployment of RFC3195, so it might be useful to think about pursuing that path...

Now that I'm curious about this problem I want to fix it. My plan is also to create a plugin for GroundWork OpenSource including phpLogCon and for this I want to have full protocol support. Also I have to brush up on my C programming skills sometimes

sounds interesting

The problem seems to be in liblogging-0.7.1/src/socketsUnix.c:

"Normal" debug output to file only works in debug mode:

Code: Select all

sbSockObj* sbSockInitEx(int iAF, int iSockType)
{
         struct sbSockObject *pThis;

         assert((iSockType == SOCK_STREAM) || (iSockType == SOCK_DGRAM));

         pThis = (struct sbSockObject*) calloc(1, sizeof(struct sbSockObject));
         if(pThis != NULL)
         {       /* initialize class members */
!                FILE *fp; fp = fopen("/tmp/liblogging.log", "a"); fprintf(fp, "socket(%d, %d, 0) => ", iAF, iSockType); fclose(fp);
                 if((pThis->sock = socket(iAF, iSockType, 0)) == INVALID_SOCKET)
                 {
!                        fp = fopen("/tmp/liblogging.log", "a"); fprintf(fp, "INVALID_SOCKET\n"); fclose(fp);
                         free(pThis);
                         return(NULL);
                 }
!                fp = fopen("/tmp/liblogging.log", "a"); fprintf(fp, "%d\n", pThis->sock); fclose(fp);
                 /* rest of initialization */
                 pThis->bIsInError = FALSE;
                 pThis->OID = OIDsbSock;
                 pThis->iCurInBufPos = 0;
                 pThis->iInBufLen = 0;
         }
         return(pThis);
}


"Optimized" debug output to file works every time:

Code: Select all

sbSockObj* sbSockInitEx(int iAF, int iSockType)
{
         struct sbSockObject *pThis;

         assert((iSockType == SOCK_STREAM) || (iSockType == SOCK_DGRAM));

         pThis = (struct sbSockObject*) calloc(1, sizeof(struct sbSockObject));
         if(pThis != NULL)
         {       /* initialize class members */
!                FILE *fp; fp = fopen("/tmp/liblogging.log", "a"); fprintf(fp, "socket(%d, %d, 0) => ", iAF, iSockType);
                 if((pThis->sock = socket(iAF, iSockType, 0)) == INVALID_SOCKET)
                 {
!                        fprintf(fp, "INVALID_SOCKET\n"); fclose(fp);
                         free(pThis);
                         return(NULL);
                 }
!                fprintf(fp, "%d\n", pThis->sock); fclose(fp);
                 /* rest of initialization */
                 pThis->bIsInError = FALSE;
                 pThis->OID = OIDsbSock;
                 pThis->iCurInBufPos = 0;
                 pThis->iInBufLen = 0;
         }
         return(pThis);
}


So keeping another file descriptor open "fixes" the code. Something seems to wrong with fd 6 (using the extra open file I get socket fd 7). At least it is this fd when using my full blown configuration file (UDP, TCP, RELP and RFC3195).

Also, when running under "strace -ff", the socket call succeeds. I don't really have an idea what could possibly be wrong there (maybe some problem due to cloning the process?)...