You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
(10) |
Oct
(10) |
Nov
(4) |
Dec
(7) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Bob P. <rn...@op...> - 2002-10-18 03:42:49
|
I'm having a problem with the files I'm getting from SourceForge, both downloading msyslog-v1.09c-src.tar.gz and via CVS. When I check the directory listing of msyslog-v1.09c-src.tar.gz, it looks corrupt. A partial list includes: =============================== # tar -tzf /tmp/msyslog-v1.09c-src.tar.gz|head -20 msyslog-v1.09c/doc msyslog-v1.09c/doc/ msyslog-v1.09c/doc/HOW_TO_ msyslog-v1.09c/do msyslog-v1.09c msyslog-v1.09c/doc msyslog-v1.09c/doc/arc msyslog-v1.09c/src/examples msyslog-v1.09c/src/examples msyslog-v1.09c/src/examples/syslo msyslog-v1.09c/src/examples/sys msyslog-v1.09c/src/examples/s msyslog-v1.09c/src/examples/sys msyslog-v1.09c/src/examples/sys msyslog-v1.09c/s msyslog-v msyslog-v1.09c/s msyslog-v1.09c msyslog-v1.09c msyslog-v1.09c ================================= I haven't looked through the CVS download thoroughly, but the following lines of net.c don't look correct: =================================== msyslog/src/modules/net.c Lines 352-369 for (i = 0; i < arg->fd_count; i++) if (write(arg->fds[i], arg->msg->data, arg->msg->dlen) == -1) { aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa if ((c->flags & M_TCP_REVERSE) && (arg->fds[i] = connect_tcp(c->hosts[i]->name, c->hosts[i]->port, NULL, 0, NULL)) == -1) { strlcpy(arg->err_buf, "net: cannot " "reconnect to ", sizeof (arg->err_buf)); strlcat(arg->err_buf, arg->argv[cnt], sizeof (arg->err_buf)); strlcat(arg->err_buf, "net: cannot write to ", #warning TERMINAR sizeof (arg->err_buf)); strlcat(arg->err_buf, arg->argv[cnt], sizeof (arg->err_buf)); errors++; } ================================= The line of aaaaaaaaaaaaa's also appears at the end of doc/CONFIGURATION. When I do a make after successful completion of ./configure, I get the following results: ================================= % make cd src && exec make all gcc -g -O2 -DMSYSLOG_STATIC -pthread -pedantic -I. -c daemon.c -o daemon.o gcc -g -O2 -DMSYSLOG_STATIC -pthread -pedantic -I. -c engine/engine.c -o engine/engine.o engine/engine.c:304: warning: ANSI C does not allow `#warning' engine/engine.c:304: warning: #warning FINISH THIS engine/engine.c:1017: warning: ANSI C does not allow `#warning' engine/engine.c:1017: warning: #warning FIX THIS TO MATCH PATHS gcc -g -O2 -DMSYSLOG_STATIC -pthread -pedantic -I. -c engine/comp.c -o engine/comp.o gcc -g -O2 -DMSYSLOG_STATIC -pthread -pedantic -I. -c generic/crypto.c -o generic/crypto.o gcc -g -O2 -DMSYSLOG_STATIC -pthread -pedantic -I. -c generic/net.c -o generic/net.o gcc -g -O2 -DMSYSLOG_STATIC -pthread -pedantic -I. -c generic/hash.c -o generic/hash.o gcc -g -O2 -DMSYSLOG_STATIC -pthread -pedantic -I. -c generic/options.c -o generic/options.o gcc -g -O2 -DMSYSLOG_STATIC -pthread -pedantic -I. -c generic/strings.c -o generic/strings.o flex -p -i conf/config.l gcc -g -O2 -DMSYSLOG_STATIC -pthread -pedantic -I. -c lex.yy.c -o lex.yy.o conf/config.l:8: y.tab.h: No such file or directory *** Error code 1 Stop in /home/cvsroot/msyslog/src. *** Error code 1 Stop in /home/cvsroot/msyslog (line 31 of Makefile). =============================== Bob |
From: Bob P. <rn...@op...> - 2002-10-18 01:11:13
|
I just started running msyslogd on a Solaris 8 box with the intention of collecting logs from msyslogd running on several OpenBSD servers. For the most part, everything worked fine, but I found that cron log entries were being dropped. After wasting a great deal of time trying to figure out what was wrong with msyslogd, I finally figured out what was wrong/different with Solaris. In /usr/include/sys/syslog.h, the facility numbers are different for LOG_CRON. Under OpenBSD, it is: #define LOG_CRON (9<<3) /* clock daemon */ while for Solaris it reads: #define LOG_CRON (15<<3) /* cron/at subsystem */ When you compile msyslogd on the Solaris machine, the 15 needs to be changed to 9 for compatibility with other OS's. Also, the following values, missing in the Solaris file, need to be added if you use these facilities on other machines: #define LOG_AUTHPRIV (10<<3) /* security/authorization messages (private) */ #define LOG_FTP (11<<3) /* ftp daemon */ Hope this saves someone else some troubleshooting time. Bob |
From: Florin A. <fl...@sg...> - 2002-10-04 21:47:05
|
Ok, so it's not related to msyslog, perhaps not even to syslog in general, but you gotta see this: http://www.dest-unreach.org/socat/ Quote: socat is a relay for bidirectional data transfer between two independent data channels. Each of these data channels may be a file, pipe, device (serial line etc. or a pseudo terminal), a socket (UNIX, IP4, IP6 - raw, UDP, TCP), an SSL socket, proxy CONNECT connection, a file descriptor (stdin etc.), the GNU line editor, a program, or a combination of two of these. These modes include generation of "listening" sockets, pipes and pseudo terminals. It helped me do some weird things with syslog, like forwarding messages from tcp:1234 to udp:514 :-) Not in production, of course, but just for testing things out. And i can certailny see some other potential here, like replaying syslog sequences, etc. "netcat on acid" :-) -- Florin Andrei If you wear a tinfoil hat nowadays, people will just think you're advertising for some Mel Gibson movie. |
From: Florin A. <fl...@sg...> - 2002-10-01 22:12:25
|
http://rr.sans.org/toppapers/kiwi.php The first part, "Introduction to Syslog", is interesting. It talks about some proposals to improve the syslog protocol (the IETF links). -- Florin Andrei "To a first approximation, bank vaults are secure. Most of them don't get broken into, because it takes real skill. Computers are the opposite." - Bruce Schneier |
From: Florin A. <fl...@sg...> - 2002-09-25 22:56:05
|
On Wed, 2002-09-25 at 15:37, Alejo Sanchez wrote: > > I was coding that. :) Ah, yes, i've seen the CVS changes. > If you like, there can be some kind of snapshot posted for download... Sure, when you feel like there's at least a slight chance of not having big showstoppers in the code, a snapshot would be nice. -- Florin Andrei "Security measures are characterized less by their manner of success than by their manner of failure." - Bruce Schneier |
From: Alejo S. <al...@ve...> - 2002-09-25 22:38:47
|
I was coding that. :) Tonight I'll commit some stuff (after testing at least a bit). Though, due to the ugly 1.x organization, it looks a bit of a hack. Testing -current would be nice :) If you like, there can be some kind of snapshot posted for download... Alejo |
From: Alejo S. <al...@ve...> - 2002-09-25 22:36:44
|
Hi! Following lots of reports on the lists, we are doing some work on 1.X but we need a little help. First it'd be GREAT to get as many sample lines of logs forwarded by non-msyslog hosts (i.e. cisco, irix, solaris, etc). That would help a lot to make some test. Yeah, I know about the rfc on syslog, but as earlier stated, it looks a bit ugly for me and they never care for comments by some of us. I believe there will be some dissidents on following them, so it'd be nice to have all possible cases of non-rfc log forwarding covered. (why would we help comply to a standard like that... :) TESTING. We need all the testing you can do, since that takes out a lot of time from developers, a currently scarce resource. Thanks a lot for all your help, reports, patience and using our code. Alejo |
From: Florin A. <fl...@sg...> - 2002-09-25 21:06:00
|
On Wed, 2002-09-25 at 13:49, Fredrick Paul Eisele wrote: > Florin Andrei wrote: > > > >I'm not sure about 1.09. When it's going to reach a stable state? > > > >I tried to do the patch for 1.08, but then i run into other problems > >(see my previous messages). > > > I'm thinking about a good solid week of testing should get it to a > reasonable test state. > From there I am going to need some help putting some test cases > together including > running the tests. > I don't know what is required to test the program using sourceforge tools. > What do you (all) think about a release where the old modules are > thoughly tested but the new modules may still need some work? Ok, guys, i'll never have any time soon to look at the source more seriously (my patch today is the best example of such a half-baked attempt), but i'm willing to run some tests for you. When you feel like 1.09 has reached the point where it could be tested by non-contributors, i suggest to pack it as 1.09beta1 or something like that and put the tarball on sf.net. Then the same for 1.09beta2, etc. I have some serious real-life tests here, and i can use them to see how 1.09 goes. -- Florin Andrei "Security measures are characterized less by their manner of success than by their manner of failure." - Bruce Schneier |
From: Fredrick P. E. <ph...@ne...> - 2002-09-25 20:47:53
|
Florin Andrei wrote: >On Wed, 2002-09-25 at 12:59, Fredrick Paul Eisele wrote: > > >>Florin Andrei wrote: >> >> >>>Perhaps, for a future version, a new field could be added to the message >>>within msyslog, containing the IP address of the host? And enable >>>om_regex to filter on that field. This way, we're not depending on funky >>>DNS stuff, or on how the host creates the message. >>> >>> >>> >>That makes sense. >>Are you planning on making a patch for 1.09+ or should I? >>I will be busy with other things for about a month but after that I >>should be fine. >> >> > >I'm not sure about 1.09. When it's going to reach a stable state? > >I tried to do the patch for 1.08, but then i run into other problems >(see my previous messages). > I'm thinking about a good solid week of testing should get it to a reasonable test state. From there I am going to need some help putting some test cases together including running the tests. I don't know what is required to test the program using sourceforge tools. What do you (all) think about a release where the old modules are thoughly tested but the new modules may still need some work? |
From: Florin A. <fl...@sg...> - 2002-09-25 20:11:35
|
On Wed, 2002-09-25 at 12:59, Fredrick Paul Eisele wrote: > Florin Andrei wrote: > > > >Perhaps, for a future version, a new field could be added to the message > >within msyslog, containing the IP address of the host? And enable > >om_regex to filter on that field. This way, we're not depending on funky > >DNS stuff, or on how the host creates the message. > > > That makes sense. > Are you planning on making a patch for 1.09+ or should I? > I will be busy with other things for about a month but after that I > should be fine. I'm not sure about 1.09. When it's going to reach a stable state? I tried to do the patch for 1.08, but then i run into other problems (see my previous messages). -- Florin Andrei "Security measures are characterized less by their manner of success than by their manner of failure." - Bruce Schneier |
From: Fredrick P. E. <ph...@ne...> - 2002-09-25 19:57:34
|
Florin Andrei wrote: >Ok, now i'm starting to see the light. Or not. :-) Well, anyway... > >It seems to me that om_regex with -h is processing the messages based on >the host field in the message. >If that's true, the problem is, that field can be anything. It can be a >host name, it can contain the hostname and the domain, or it can be just >an IP address. Even worse, the hostname can be slurped in from the >original syslog UDP message, or from DNS. >I think there are too many variables here... > I agree. > >Perhaps, for a future version, a new field could be added to the message >within msyslog, containing the IP address of the host? And enable >om_regex to filter on that field. This way, we're not depending on funky >DNS stuff, or on how the host creates the message. > That makes sense. Are you planning on making a patch for 1.09+ or should I? I will be busy with other things for about a month but after that I should be fine. > >But for 1.08 i don't think that's feasible. I'm not using the host >column in MySQL anyway (my hosts are already separated by om_regex in >different tables), so i'm just thinking of hacking im_udp to _always_ >use the IP address no matter what, and configure om_regex to filter by >IP addresses. > > > |
From: Florin A. <fl...@sg...> - 2002-09-25 19:20:39
|
On Wed, 2002-09-25 at 11:59, Florin Andrei wrote: > > - hent = gethostbyaddr((char *) &frominet.sin_addr, > - sizeof(frominet.sin_addr), frominet.sin_family); > + if (!(c->flags & M_ALWAYSIP)) { If i change that to: if (1 == 0) { and run it like this: msyslogd -i linux -i udp -i unix then msyslog works for local messages, but it dies immediately with segmentation fault when it receives a UDP message from another host, and -d 9999 does not reveal anything. -- Florin Andrei "Security measures are characterized less by their manner of success than by their manner of failure." - Bruce Schneier |
From: Florin A. <fl...@sg...> - 2002-09-25 18:59:52
|
Ok, i put together the following patch against 1.08e I'm running msyslog like this: msyslogd -i linux -i udp '-n' -i unix But now nothing gets logged. What am i doing wrong? On Wed, 2002-09-25 at 11:26, Florin Andrei wrote: > Ok, now i'm starting to see the light. Or not. :-) Well, anyway... > > It seems to me that om_regex with -h is processing the messages based on > the host field in the message. > If that's true, the problem is, that field can be anything. It can be a > host name, it can contain the hostname and the domain, or it can be just > an IP address. Even worse, the hostname can be slurped in from the > original syslog UDP message, or from DNS. > I think there are too many variables here... > > Perhaps, for a future version, a new field could be added to the message > within msyslog, containing the IP address of the host? And enable > om_regex to filter on that field. This way, we're not depending on funky > DNS stuff, or on how the host creates the message. > > But for 1.08 i don't think that's feasible. I'm not using the host > column in MySQL anyway (my hosts are already separated by om_regex in > different tables), so i'm just thinking of hacking im_udp to _always_ > use the IP address no matter what, and configure om_regex to filter by > IP addresses. > > -- > Florin Andrei > > "Security measures are characterized less by their manner of success > than by their manner of failure." - Bruce Schneier > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Msyslog-development mailing list > Msy...@li... > https://lists.sourceforge.net/lists/listinfo/msyslog-development -- Florin Andrei "Security measures are characterized less by their manner of success than by their manner of failure." - Bruce Schneier |
From: Florin A. <fl...@sg...> - 2002-09-25 18:26:27
|
Ok, now i'm starting to see the light. Or not. :-) Well, anyway... It seems to me that om_regex with -h is processing the messages based on the host field in the message. If that's true, the problem is, that field can be anything. It can be a host name, it can contain the hostname and the domain, or it can be just an IP address. Even worse, the hostname can be slurped in from the original syslog UDP message, or from DNS. I think there are too many variables here... Perhaps, for a future version, a new field could be added to the message within msyslog, containing the IP address of the host? And enable om_regex to filter on that field. This way, we're not depending on funky DNS stuff, or on how the host creates the message. But for 1.08 i don't think that's feasible. I'm not using the host column in MySQL anyway (my hosts are already separated by om_regex in different tables), so i'm just thinking of hacking im_udp to _always_ use the IP address no matter what, and configure om_regex to filter by IP addresses. -- Florin Andrei "Security measures are characterized less by their manner of success than by their manner of failure." - Bruce Schneier |
From: Fredrick P. E. <ph...@ne...> - 2002-08-22 14:35:12
|
FYI I am breaking im_file into two modules. In the case where the file is a character device it will be processed by the (new) im_pipe module. The poll function does not behave appropriatly with regular files. I am creating an im_file_poll function. My intent is to use the timeout feature of poll to periodically stop and call the im_*_poll functions (if they exist) associated with each module. I will have to do something special to prevent poll from seeing the file descriptor for the regular file as being readable (it always is). If anyone has an idea for better names for either one of these modules... Fredrick Paul Eisele wrote: > Good, I was afraid I was breaking something. > I have a need to screen scape a certain class of devices that write to > serial ports. > We have a client that wants to put them under management. > I am modifying im_file to read /dev/ttyS[0123]. > I am basing the im_file off of im_tcp as I expect it will need to > preserve partial lines. > This will also require the modification to om_regex to handle > substitution > as was requested previously. > As soon as these two are done I will make a v1.09a release. > It should be ready yet this week. > I will be doing cvs commits at least once a day until then. > Alejo, if you could take a look at the changes to im_file and > om_regex that would be great. > > > Alejo Sanchez wrote: > >> >> It is suposed to work that way, but most of it wasn't tested, or >> wasn't thoroughly tested. It was made after a special requirement of >> a project AFAIR, which I thought would be useful for all syslog >> users. It was used to read non-syslog logs. All was designed to be >> useful with pipes and stuff too. Bue of course, app >> truncation/rotation might break it. >> >> I'd be glad to help out and clarify doubts about it. >> >> Cheers, >> >> Alejo >> >> Fredrick Paul Eisele wrote: >> >>> I have a perception as to how the im_file.c works. >>> Having looked at the code I am confused... >>> I think the way it is supposed to work is to treat each record in the >>> file as a separate message. >>> The file may contain multiple messages and may be written to >>> at the same time it is being read by im_file_read. >>> Each message may contain a timestamp which may be out of place >>> and of a different format, so long as it is strptime parsable. >>> Each message may start with a <priority> or it may be missing. >>> If it is missing it will be set to a default value. >>> If this is not correct then I will create a module which does this. >>> >>> I am sure this is in the archives, but where did the archives go? >>> Thanks. >>> |
From: Fredrick P. E. <ph...@ne...> - 2002-08-21 12:50:15
|
Good, I was afraid I was breaking something. I have a need to screen scape a certain class of devices that write to serial ports. We have a client that wants to put them under management. I am modifying im_file to read /dev/ttyS[0123]. I am basing the im_file off of im_tcp as I expect it will need to preserve partial lines. This will also require the modification to om_regex to handle substitution as was requested previously. As soon as these two are done I will make a v1.09a release. It should be ready yet this week. I will be doing cvs commits at least once a day until then. Alejo, if you could take a look at the changes to im_file and om_regex that would be great. Alejo Sanchez wrote: > > It is suposed to work that way, but most of it wasn't tested, or > wasn't thoroughly tested. It was made after a special requirement of a > project AFAIR, which I thought would be useful for all syslog users. > It was used to read non-syslog logs. All was designed to be useful > with pipes and stuff too. Bue of course, app truncation/rotation might > break it. > > I'd be glad to help out and clarify doubts about it. > > Cheers, > > Alejo > > Fredrick Paul Eisele wrote: > >> I have a perception as to how the im_file.c works. >> Having looked at the code I am confused... >> I think the way it is supposed to work is to treat each record in the >> file as a separate message. >> The file may contain multiple messages and may be written to >> at the same time it is being read by im_file_read. >> Each message may contain a timestamp which may be out of place >> and of a different format, so long as it is strptime parsable. >> Each message may start with a <priority> or it may be missing. >> If it is missing it will be set to a default value. >> If this is not correct then I will create a module which does this. >> >> I am sure this is in the archives, but where did the archives go? >> Thanks. >> >> > |
From: Alejo S. <al...@ve...> - 2002-08-20 23:20:28
|
It is suposed to work that way, but most of it wasn't tested, or wasn't thoroughly tested. It was made after a special requirement of a project AFAIR, which I thought would be useful for all syslog users. It was used to read non-syslog logs. All was designed to be useful with pipes and stuff too. Bue of course, app truncation/rotation might break it. I'd be glad to help out and clarify doubts about it. Cheers, Alejo Fredrick Paul Eisele wrote: > I have a perception as to how the im_file.c works. > Having looked at the code I am confused... > I think the way it is supposed to work is to treat each record in the > file as a separate message. > The file may contain multiple messages and may be written to > at the same time it is being read by im_file_read. > Each message may contain a timestamp which may be out of place > and of a different format, so long as it is strptime parsable. > Each message may start with a <priority> or it may be missing. > If it is missing it will be set to a default value. > If this is not correct then I will create a module which does this. > > I am sure this is in the archives, but where did the archives go? > Thanks. > > |
From: Fredrick P. E. <ph...@ne...> - 2002-08-20 20:53:48
|
I have a perception as to how the im_file.c works. Having looked at the code I am confused... I think the way it is supposed to work is to treat each record in the file as a separate message. The file may contain multiple messages and may be written to at the same time it is being read by im_file_read. Each message may contain a timestamp which may be out of place and of a different format, so long as it is strptime parsable. Each message may start with a <priority> or it may be missing. If it is missing it will be set to a default value. If this is not correct then I will create a module which does this. I am sure this is in the archives, but where did the archives go? Thanks. |
From: Fredrick P. E. <ph...@ne...> - 2002-08-14 20:03:55
|
Well, I brought the CVS repository up to date (I think). The branch I am working on is v1_09a. It has a modified "om_refract.c" module which might actually work. But, given that it has NO testing done on it, I doubt it. There is a man/om_refract.8 that describes how it should work. You can take a look at the CVS repository to see the current prerelease code. <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/msyslog/syslog/> Feel free to download it and try it out as well. |