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: Marc L. <rh...@gr...> - 2010-03-26 20:10:28
|
Hi. I've forked MSyslog since it's doesn't maintained since 2002. I principally focuses on bugfixes and creating new modules and the planned 2.x version will have module support rewrited. If you are interested you can get it here: http://rhaamo.li/sosyslog/ -- _ Marc Lagrange - rh...@gr... ( ) Projects : https://tux-atome.fr [ ][*][ ] X Blog : http://rhaamo.li [ ][ ][*] / \ www.asciiribbon.org Stop HTML mails. [*][*][*] |
From: Chris G. <cg...@at...> - 2005-12-06 19:55:40
|
Dear all, I installed Msyslog on Fedora Core 3, but it can't be started since the start up script can't find the msyslogd file which is supposed to be under the /usr/sbin directory. I wonder if msyslog support Fedora Core 3 since it works well on Red Hat 9 after I installed it. Thanks in advance. Chris |
From: Marcell Z. <li...@an...> - 2004-09-16 07:11:55
|
Hi I submit one new patch for msyslog: http://sourceforge.net/tracker/index.php?func=detail&aid=1024253&group_id=25741&atid=385119 Any idea? Bye Lilo -- | Andrews -- IT Engineering Zambo Marcell | | Information: in...@an... li...@an... | |
From: Alejo S. <al...@sp...> - 2003-06-25 21:19:09
|
Wow thanks! the DNS thingie... you have a point there :-/ Alejo Bob Perkins wrote: > I got the 1.10 source this morning from SourceForge via CVS HEAD tag and > ran into the following problems trying to build an OpenBSD package using > the instructions from README: > > After doing the 'make ports' and installing the files, 'make' generated > the following messages: > ===> Building for msyslog-1.10 > cc -O2 -I/usr/include/openssl -DHAVE_SSL -Wall -I. -lssl -lcrypto > -o msyslogd modules.c syslogd.c options.c modules/im_bsd.c > modules/im_udp.c modules/om_udp.c modules/im_unix.c modules/im_file.c > modules/im_serial.c modules/om_classic.c modules/ttymsg.c > modules/om_tcp.c modules/im_tcp.c modules/ip_misc.c > modules/om_oracle8i.c modules/om_mysql.c modules/om_pgsql.c > modules/sql_misc.c modules/om_refract.c modules/om_regex.c > modules/ip_misc.c:511: warning: #warning THIS SHOULD SUPPORT SOME KIND > OF DNS CACHE > modules/om_regex.c:357: warning: #warning are you sure this is correct ? > modules/om_regex.c:472: warning: #warning FIX THIS > modules/om_regex.c:479: warning: #warning FIX THIS > modules/om_regex.c:481: warning: #warning FIX THIS > modules/om_regex.c:489: warning: #warning WTF is this > modules/om_regex.c:497: warning: #warning FIX THIS > modules/om_regex.c:535: warning: #warning FIX THIS > nroff -Tascii -mandoc syslog.conf.5 > syslog.conf.cat5 > nroff -Tascii -mandoc syslogd.8 > syslogd.cat8 > nroff -Tascii -mandoc im_bsd.8 > im_bsd.cat8 > nroff -Tascii -mandoc im_udp.8 > im_udp.cat8 > nroff -Tascii -mandoc om_udp.8 > om_udp.cat8 > nroff -Tascii -mandoc im_unix.8 > im_unix.cat8 > nroff -Tascii -mandoc im_file.8 > im_file.cat8 > Not a \-mdoc command: .LP > nroff -Tascii -mandoc im_serial.8 > im_serial.cat8 > Not a \-mdoc command: .LP > nroff -Tascii -mandoc om_classic.8 > om_classic.cat8 > nroff -Tascii -mandoc om_tcp.8 > om_tcp.cat8 > nroff -Tascii -mandoc im_tcp.8 > im_tcp.cat8 > nroff -Tascii -mandoc om_oracle8i.8 > om_oracle8i.cat8 > nroff -Tascii -mandoc om_mysql.8 > om_mysql.cat8 > nroff -Tascii -mandoc om_pgsql.8 > om_pgsql.cat8 > nroff -Tascii -mandoc om_refract.8 > om_refract.cat8 > nroff -Tascii -mandoc om_regex.8 > om_regex.cat8 > > As there weren't any errors indicated during 'make', I went ahead with > 'make package'. The first attempt generated this error: > ===> Faking installation for msyslog-1.10 > install -c -s -o root -g bin -m 555 > /src/msyslog/msyslog-current/syslog/msyslog_port-1.10/w-msyslog-1.10/msyslog-v1.10/src/syslogd > /src/msyslog/msyslog-current/syslog/msyslog_port-1.10/w-msyslog-1.10/fake-i386/usr/local/sbin/msyslogd > > install: > /src/msyslog/msyslog-current/syslog/msyslog_port-1.10/w-msyslog-1.10/msyslog-v1.10/src/syslogd: > No such file or directory > *** Error code 71 > > Stop in /src/msyslog/msyslog-current/syslog/msyslog_port-1.10 (line 54 > of Makefile). > *** Error code 1 > > Stop in /src/msyslog/msyslog-current/syslog/msyslog_port-1.10 (line > 1806 of /usr/ports/infrastructure/mk/bsd.port.mk). > > > After making the following patches to packaging/OpenBSD/Makefile.in and > packaging/OpenBSD/pkg/PLIST.in, the package build worked successfully: > > --- packaging/OpenBSD/Makefile.in.orig Tue Sep 17 01:20:26 2002 > +++ packaging/OpenBSD/Makefile.in Tue Jun 24 10:54:11 2003 > @@ -51,17 +51,12 @@ > CONFIGURE_STYLE= gnu > > do-install: > - ${INSTALL_PROGRAM} ${WRKSRC}/src/syslogd ${PREFIX}/sbin/msyslogd > + ${INSTALL_PROGRAM} ${WRKSRC}/src/msyslogd ${PREFIX}/sbin > ${INSTALL_MAN_DIR} ${PREFIX}/man/cat5 ${PREFIX}/man/cat8 > - ${INSTALL_PROGRAM} ${WRKSRC}/src/peo/peochk ${PREFIX}/sbin > ${INSTALL_MAN} ${WRKSRC}/src/man/*cat5 ${PREFIX}/man/cat5 > ${INSTALL_MAN} ${WRKSRC}/src/man/syslogd.cat8 \ > ${PREFIX}/man/cat8/msyslogd.cat8 > - ${INSTALL_MAN} ${WRKSRC}/src/man/peochk.cat8 ${PREFIX}/man/cat8/ > ${INSTALL_MAN} ${WRKSRC}/src/man/im*cat8 > ${WRKSRC}/src/man/om*cat8 \ > ${PREFIX}/man/cat8/ > - ${INSTALL_DATA_DIR} ${PREFIX}/lib/alat > - ${INSTALL_DATA} ${WRKSRC}/src/modules/libmsyslog.so.${VERSION} \ > - ${PREFIX}/lib/alat > > .include <bsd.port.mk> > > --- packaging/OpenBSD/pkg/PLIST.in.orig Tue Sep 17 01:20:26 2002 > +++ packaging/OpenBSD/pkg/PLIST.in Tue Jun 24 10:58:03 2003 > @@ -1,5 +1,4 @@ > @comment $Id: PLIST.in,v 1.2 2002/09/17 05:20:26 alejo Exp $ > -lib/alat/libmsyslog.so.@MSYSLOG_VERSION@ > man/cat5/syslog.conf.cat5 > man/cat8/im_bsd.cat8 > man/cat8/im_file.cat8 > @@ -9,12 +8,8 @@ > man/cat8/msyslogd.cat8 > man/cat8/om_classic.cat8 > man/cat8/om_mysql.cat8 > -man/cat8/om_peo.cat8 > man/cat8/om_pgsql.cat8 > man/cat8/om_regex.cat8 > man/cat8/om_tcp.cat8 > man/cat8/om_udp.cat8 > -man/cat8/peochk.cat8 > sbin/msyslogd > -sbin/peochk > -@dirrm lib/alat > > Testing is next. > > Bob > > PS: I disagree with the warning message in modules/ip_misc.c - "THIS > SHOULD > SUPPORT SOME KIND OF DNS CACHE". While this could increase throughput, > it's adding non-syslog functionality that could cause problems later. If > there is a need for DNS cacheing, I would recommend installing a cacheing > DNS server on the logging machine. That way, msyslogd could do its job > and let the DNS software take care of the things that it does "best". > |
From: Bob P. <rpe...@tc...> - 2003-06-24 15:18:24
|
I got the 1.10 source this morning from SourceForge via CVS HEAD tag and ran into the following problems trying to build an OpenBSD package using the instructions from README: After doing the 'make ports' and installing the files, 'make' generated the following messages: ===> Building for msyslog-1.10 cc -O2 -I/usr/include/openssl -DHAVE_SSL -Wall -I. -lssl -lcrypto -o msyslogd modules.c syslogd.c options.c modules/im_bsd.c modules/im_udp.c modules/om_udp.c modules/im_unix.c modules/im_file.c modules/im_serial.c modules/om_classic.c modules/ttymsg.c modules/om_tcp.c modules/im_tcp.c modules/ip_misc.c modules/om_oracle8i.c modules/om_mysql.c modules/om_pgsql.c modules/sql_misc.c modules/om_refract.c modules/om_regex.c modules/ip_misc.c:511: warning: #warning THIS SHOULD SUPPORT SOME KIND OF DNS CACHE modules/om_regex.c:357: warning: #warning are you sure this is correct ? modules/om_regex.c:472: warning: #warning FIX THIS modules/om_regex.c:479: warning: #warning FIX THIS modules/om_regex.c:481: warning: #warning FIX THIS modules/om_regex.c:489: warning: #warning WTF is this modules/om_regex.c:497: warning: #warning FIX THIS modules/om_regex.c:535: warning: #warning FIX THIS nroff -Tascii -mandoc syslog.conf.5 > syslog.conf.cat5 nroff -Tascii -mandoc syslogd.8 > syslogd.cat8 nroff -Tascii -mandoc im_bsd.8 > im_bsd.cat8 nroff -Tascii -mandoc im_udp.8 > im_udp.cat8 nroff -Tascii -mandoc om_udp.8 > om_udp.cat8 nroff -Tascii -mandoc im_unix.8 > im_unix.cat8 nroff -Tascii -mandoc im_file.8 > im_file.cat8 Not a \-mdoc command: .LP nroff -Tascii -mandoc im_serial.8 > im_serial.cat8 Not a \-mdoc command: .LP nroff -Tascii -mandoc om_classic.8 > om_classic.cat8 nroff -Tascii -mandoc om_tcp.8 > om_tcp.cat8 nroff -Tascii -mandoc im_tcp.8 > im_tcp.cat8 nroff -Tascii -mandoc om_oracle8i.8 > om_oracle8i.cat8 nroff -Tascii -mandoc om_mysql.8 > om_mysql.cat8 nroff -Tascii -mandoc om_pgsql.8 > om_pgsql.cat8 nroff -Tascii -mandoc om_refract.8 > om_refract.cat8 nroff -Tascii -mandoc om_regex.8 > om_regex.cat8 As there weren't any errors indicated during 'make', I went ahead with 'make package'. The first attempt generated this error: ===> Faking installation for msyslog-1.10 install -c -s -o root -g bin -m 555 /src/msyslog/msyslog-current/syslog/msyslog_port-1.10/w-msyslog-1.10/msyslog-v1.10/src/syslogd /src/msyslog/msyslog-current/syslog/msyslog_port-1.10/w-msyslog-1.10/fake-i386/usr/local/sbin/msyslogd install: /src/msyslog/msyslog-current/syslog/msyslog_port-1.10/w-msyslog-1.10/msyslog-v1.10/src/syslogd: No such file or directory *** Error code 71 Stop in /src/msyslog/msyslog-current/syslog/msyslog_port-1.10 (line 54 of Makefile). *** Error code 1 Stop in /src/msyslog/msyslog-current/syslog/msyslog_port-1.10 (line 1806 of /usr/ports/infrastructure/mk/bsd.port.mk). After making the following patches to packaging/OpenBSD/Makefile.in and packaging/OpenBSD/pkg/PLIST.in, the package build worked successfully: --- packaging/OpenBSD/Makefile.in.orig Tue Sep 17 01:20:26 2002 +++ packaging/OpenBSD/Makefile.in Tue Jun 24 10:54:11 2003 @@ -51,17 +51,12 @@ CONFIGURE_STYLE= gnu do-install: - ${INSTALL_PROGRAM} ${WRKSRC}/src/syslogd ${PREFIX}/sbin/msyslogd + ${INSTALL_PROGRAM} ${WRKSRC}/src/msyslogd ${PREFIX}/sbin ${INSTALL_MAN_DIR} ${PREFIX}/man/cat5 ${PREFIX}/man/cat8 - ${INSTALL_PROGRAM} ${WRKSRC}/src/peo/peochk ${PREFIX}/sbin ${INSTALL_MAN} ${WRKSRC}/src/man/*cat5 ${PREFIX}/man/cat5 ${INSTALL_MAN} ${WRKSRC}/src/man/syslogd.cat8 \ ${PREFIX}/man/cat8/msyslogd.cat8 - ${INSTALL_MAN} ${WRKSRC}/src/man/peochk.cat8 ${PREFIX}/man/cat8/ ${INSTALL_MAN} ${WRKSRC}/src/man/im*cat8 ${WRKSRC}/src/man/om*cat8 \ ${PREFIX}/man/cat8/ - ${INSTALL_DATA_DIR} ${PREFIX}/lib/alat - ${INSTALL_DATA} ${WRKSRC}/src/modules/libmsyslog.so.${VERSION} \ - ${PREFIX}/lib/alat .include <bsd.port.mk> --- packaging/OpenBSD/pkg/PLIST.in.orig Tue Sep 17 01:20:26 2002 +++ packaging/OpenBSD/pkg/PLIST.in Tue Jun 24 10:58:03 2003 @@ -1,5 +1,4 @@ @comment $Id: PLIST.in,v 1.2 2002/09/17 05:20:26 alejo Exp $ -lib/alat/libmsyslog.so.@MSYSLOG_VERSION@ man/cat5/syslog.conf.cat5 man/cat8/im_bsd.cat8 man/cat8/im_file.cat8 @@ -9,12 +8,8 @@ man/cat8/msyslogd.cat8 man/cat8/om_classic.cat8 man/cat8/om_mysql.cat8 -man/cat8/om_peo.cat8 man/cat8/om_pgsql.cat8 man/cat8/om_regex.cat8 man/cat8/om_tcp.cat8 man/cat8/om_udp.cat8 -man/cat8/peochk.cat8 sbin/msyslogd -sbin/peochk -@dirrm lib/alat Testing is next. Bob PS: I disagree with the warning message in modules/ip_misc.c - "THIS SHOULD SUPPORT SOME KIND OF DNS CACHE". While this could increase throughput, it's adding non-syslog functionality that could cause problems later. If there is a need for DNS cacheing, I would recommend installing a cacheing DNS server on the logging machine. That way, msyslogd could do its job and let the DNS software take care of the things that it does "best". |
From: Alejo S. <al...@sp...> - 2003-06-10 18:43:14
|
vis is now in the codebase. current nontrivial tasks: - fix im_linux to work w/ -current - change PEO - [probably, while there] make VCR - have SQL use PEO - use libevent - fix (rewrite?) regex argh. "too much preassure!" Alejo Sanchez wrote: > * > http://www.openbsd.org/cgi-bin/man.cgi?query=vis&sektion=3&arch=i386&apropos=0&manpath=OpenBSD+Current > > vis*, *strvis*, *strnvis*, *strvisx* - visually encode characters > > It's a standard way to encode nonprint chars, and it's possible to > undo the conversion. > > > This should be added to msyslog source too, for the non-bsd users. > > Alejo > > Fredrick Paul Eisele wrote: > >> What is 'vis'? >> There is a function in syslogd.c called vis. >> It appears to be related to poll. > |
From: Alejo S. <al...@sp...> - 2003-05-09 20:36:30
|
* http://www.openbsd.org/cgi-bin/man.cgi?query=vis&sektion=3&arch=i386&apropos=0&manpath=OpenBSD+Current vis*, *strvis*, *strnvis*, *strvisx* - visually encode characters It's a standard way to encode nonprint chars, and it's possible to undo the conversion. This should be added to msyslog source too, for the non-bsd users. Alejo Fredrick Paul Eisele wrote: > What is 'vis'? > There is a function in syslogd.c called vis. > It appears to be related to poll. > |
From: Fredrick P. E. <ph...@ne...> - 2003-05-09 18:50:00
|
What is 'vis'? There is a function in syslogd.c called vis. It appears to be related to poll. |
From: Ryan F. <rf...@ba...> - 2002-12-08 01:50:24
|
Hello, As promised, here are some select statement benchmarks for the mysql schema in my om_mysqlnorm output module, vs the schema in om_mysql, both with added keys and without. The module has a problem on big-endian platforms that needs corrected, then we plan to release it under the MIT license, like the rest of msyslog. I'll hopefully have insert benchmarks by that time as well. My test dataset has 300748 log entries. The initial results show about a 3x actual/600x theoretical speed up searching with the om_mysqlnorm schema vs the traditional unkeyed schema, and a 0.14x actual/18.5x theoretical speedup vs the traditional schema with added keys. The large variation between the actual and theoretical differences seems to be due to query overhead. For larger datasets, where the overhead is a less significant part of the query execution time, the speed up will be closer to the theoretical max. My test server is a AMD K7 1100, with 640MB ram, running RedHat linux 7.3 box and MySQL 3.23.49. The reference schemas used are given at the bottom of this e-mail. I set up a msyslog server, and had 8 boxes on my network log to it over a week, using the om_mysqlnorm output module. I then converted to data into the traditional msyslog mysql schema using the statements: insert into syslogTB (facility,priority,date,time,host,message) select facility.name,priority.name,date,time,host.name,message from facility,priority,host,messages where host.id=messages.hostid and priority.id=messages.priorityid and facility.id=messages.facilityid; and insert into syslogTBunkeyed (facility,priority,date,time,host,message) select facility.name,priority.name,date,time,host.name,message from facility,priority,host,messages where host.id=messages.hostid and priority.id=messages.priorityid and facility.id=messages.facilityid; There are 20041 records from the host named sun.amerisuk.com. The following queries show how the query must search the dataset, and then the speed of the actual select queries. Using traditional unkeyed schema: mysql> explain select * from syslogTBunkeyed where host='sun.amerisuk.com'; no keys. 128 * 301748 = 38623744 20041 rows in set (1.01 sec) Using tradional schema, with added keys: mysql> explain select * from syslogTB where host='sun.amerisuk.com'; keylen: 128 * rows 9393 = 1202304 20041 rows in set (0.32 sec) Using om_mysqlnorm's normalized schema: mysql> explain select id from host where name='sun.amerisuk.com'; keylen: 128 * rows 1 = 128 1 row in set (0.00 sec) mysql> explain select * from syslogTB where hostid=4; keylen: 4 * rows 16147 = 64588 (+128) 20041 rows in set (0.28 sec) So, this query, selecting all rows for a particular host, looks over almost 600x less data on om_mysqlnorm's normalized schema than the traditional unkeyed schema, and 18.5x less data than on a indexed traditional schema. So while the actual speed differences on this test are not very significant, I feel this is due to query overhead. Actual speed differences should grow closer to the theoretical differences with larger datasets or slower machines. The three schemas being tested are: The traditional unkeyed schema, as found in the om_mysql man page CREATE TABLE syslogTBunkeyed ( facility varchar(10) default '', priority varchar(10) default '', date date default '0000-00-00', time time default '00:00:00', host varchar(128) default '', message text, seq int(10) unsigned auto_increment, PRIMARY KEY (seq) ) TYPE=MyISAM; The traditional schema, keyed CREATE TABLE syslogTB ( facility varchar(10) NOT NULL default '', priority varchar(10) NOT NULL default '', date date NOT NULL default '0000-00-00', time time NOT NULL default '00:00:00', host varchar(128) NOT NULL default '', message text NOT NULL, seq int(10) unsigned NOT NULL auto_increment, PRIMARY KEY (seq), UNIQUE KEY seq (seq), KEY facility (facility), KEY priority (priority), KEY date (date), KEY time (time), KEY host (host), KEY message (message(128)) ) TYPE=MyISAM; The om_mysqlnorm normalized schema CREATE TABLE priority ( id int(3) unsigned NOT NULL auto_increment, name char(10) NOT NULL default '', PRIMARY KEY (id), UNIQUE KEY id (id), UNIQUE KEY name (name) ) TYPE=MyISAM; CREATE TABLE facility ( id int(3) unsigned NOT NULL auto_increment, name char(10) NOT NULL default '', PRIMARY KEY (id), UNIQUE KEY id (id), UNIQUE KEY name (name) ) TYPE=MyISAM; CREATE TABLE host ( id int(3) unsigned NOT NULL auto_increment, name char(128) NOT NULL default '', PRIMARY KEY (id), UNIQUE KEY id (id), UNIQUE KEY name (name) ) TYPE=MyISAM; CREATE TABLE messages ( id int(10) unsigned NOT NULL auto_increment, facilityid int(3) unsigned NOT NULL default '0', priorityid int(3) unsigned NOT NULL default '0', hostid int(5) unsigned NOT NULL default '0', date date NOT NULL default '0000-00-00', time time NOT NULL default '00:00:00', message text NOT NULL, PRIMARY KEY (id), UNIQUE KEY id (id), KEY facilityid (facilityid), KEY priorityid (priorityid), KEY hostid (hostid), KEY date (date), KEY time (time), KEY message (message(128)) ) TYPE=MyISAM; Hope this helps. Ryan |
From: Florin A. <fl...@sg...> - 2002-12-05 19:58:08
|
I guess you're reading this already, right? ;-) http://slashdot.org/article.pl?sid=02/12/05/1554209&mode=thread&tid=172 -- Florin Andrei "If you play the WinXP CD backwards, you get a satanic message." "That's nothing, if you play it forward, it installs WinXP." |
From: Ryan F. <rf...@ba...> - 2002-12-02 23:25:47
|
----- Original Message ----- From: "Florin Andrei" <fl...@sg...> > > Here is the schema. > [snip] > Interesting. What kind of searches, if you don't mind? Via a web based interface, searches would be freetext on the message, limited by host, and optionally limited by facility, date, time, priority. I'll run some benchmarks as soon as I can get a bunch of data logged. > - ??? inserts per second (i guess i could run a query, but i'm lazy; it > would be nice if msyslog could provide some statistics Just running 'status' from the mysql client gives a queries/s statistic, although it is summarized for all databases. I suppose an output module could be written to give statistics, though I think this would be at the expense of more logging traffic. > I would like to speed up the queries, but i'm afraid i'm going to make > inserts slower, and i don't want that. The speed decrease will generally be very small. There is a select each on the facility, priority, and host tables to get ids to insert into the messages table. Run from the mysql client, these queries normally take less than 0.00seconds. We'll see for sure after I run benchmarks. :) Thanks, Ryan |
From: Florin A. <fl...@sg...> - 2002-12-02 21:03:15
|
On Mon, 2002-12-02 at 12:51, Ryan Fox wrote: > > Here is the schema. [snip] > This should make inserting a log entry a bit slower, as it's preceeded by 3 > selects. However, it makes the type of searching I want to do _much_ > quicker. As long as my employer ok's it, I'll release the code. Interesting. What kind of searches, if you don't mind? I'm running a syslog server based on msyslog and MySQL, running on RH 7.2, dual CPU, SCSI, etc., that gets the following workload: - 15 kBytes/sec incoming UDP syslog 24 hr average traffic (5 min peaks are higher, around 30kB/s) - 35 hosts logging to it - ??? inserts per second (i guess i could run a query, but i'm lazy; it would be nice if msyslog could provide some statistics) Load average is pretty good, around 1.00. I don't think i loose packets. I would like to speed up the queries, but i'm afraid i'm going to make inserts slower, and i don't want that. Have you benchmarked your schema against the default one? Results? -- Florin Andrei It's ok to use the names of your pets or children as passwords as long as they contain several non-alphanumeric characters. |
From: Ryan F. <rf...@ba...> - 2002-12-02 20:52:13
|
----- Original Message ----- From: "Florin Andrei" <fl...@sg...> > > I've written a new output module, which I've named om_mysqlnorm. Like > > om_mysql which it is based on, it logs to mysql, however it uses a > > different, more normalized schema. > > Can you describe it a little bit please? > Here is the schema. CREATE TABLE facility ( id int(3) unsigned NOT NULL auto_increment, name char(10) NOT NULL default '', PRIMARY KEY (id), UNIQUE KEY name (name), UNIQUE KEY id (id) ); CREATE TABLE priority ( id int(3) unsigned NOT NULL auto_increment, name char(10) NOT NULL default '', PRIMARY KEY (id), UNIQUE KEY name (name), UNIQUE KEY id (id) ); CREATE TABLE host ( id int(5) unsigned NOT NULL auto_increment, name char(128) NOT NULL default '', PRIMARY KEY (id), UNIQUE KEY name (name), UNIQUE KEY id (id) ); CREATE TABLE messages ( id int(10) unsigned NOT NULL auto_increment, facilityid int(3) unsigned NOT NULL default '0', priorityid int(3) unsigned NOT NULL default '0', hostid int(5) unsigned NOT NULL default '0', date date NOT NULL default '0000-00-00', time time NOT NULL default '00:00:00', message text NOT NULL, PRIMARY KEY (id), UNIQUE KEY id (id), KEY facilityid (facilityid), KEY priorityid (priorityid), KEY hostid (hostid), KEY date (date), KEY time (time), KEY message (message(128)) ); This should make inserting a log entry a bit slower, as it's preceeded by 3 selects. However, it makes the type of searching I want to do _much_ quicker. As long as my employer ok's it, I'll release the code. > > om_regex, and om_peo everywhere I tested it. 1.08e seems to work fine, > > however when running on RedHat 7.2 x86, it refuses to open ports for im_udp > > and im_tcp. Debugging with -d 999 shows these modules to load correctly, > > but the ports never open. > > That's odd. I'm running 1.08e on RH7.2 since a long time ago, and it > works without any problems. ACK! While writing this, im_udp inexplicably started working on the x86 linux box. Perhaps it heard me badmouthing it. Well, my goal is to get msyslog going on the linux sparc64 and mips boxs, so I'll continue with that, and send any specific errors I encounter here. Thanks, Ryan |
From: Florin A. <fl...@sg...> - 2002-12-02 19:58:03
|
On Mon, 2002-12-02 at 10:50, Ryan Fox wrote: > > I've written a new output module, which I've named om_mysqlnorm. Like > om_mysql which it is based on, it logs to mysql, however it uses a > different, more normalized schema. Can you describe it a little bit please? > om_regex, and om_peo everywhere I tested it. 1.08e seems to work fine, > however when running on RedHat 7.2 x86, it refuses to open ports for im_udp > and im_tcp. Debugging with -d 999 shows these modules to load correctly, > but the ports never open. That's odd. I'm running 1.08e on RH7.2 since a long time ago, and it works without any problems. -- Florin Andrei It's ok to use the names of your pets or children as passwords as long as they contain several non-alphanumeric characters. |
From: Ryan F. <rf...@ba...> - 2002-12-02 18:51:34
|
Hello all, I've written a new output module, which I've named om_mysqlnorm. Like om_mysql which it is based on, it logs to mysql, however it uses a different, more normalized schema. During my development of this, I ran across several questions about msyslog that I want to post here. What version of msyslog should I be using? 1.09c has compile errors in om_regex, and om_peo everywhere I tested it. 1.08e seems to work fine, however when running on RedHat 7.2 x86, it refuses to open ports for im_udp and im_tcp. Debugging with -d 999 shows these modules to load correctly, but the ports never open. Running this on other platforms (RedHat 6.2 on sparc64, Debian 3.0 on mips) makes -d 999 throw errors about opening the ports. The debian package for the sgi mips box is version pre-1.08, which seems to work fine. Thanks for any suggestions, Ryan |
From: Michael B. <mic...@se...> - 2002-11-22 16:35:24
|
We're running a network with msyslog's logging to a central database, and sometimes it's hard to figure out which msyslog daemon recived what so I've added a 'loghost' column to the SQL tables and fill it with uts.nodename (what uname -n is producing). See the attached patches. (feature invoked by passing '-L' to the (om_mysql|om_pgsql) module). Any feedback apriciated. Best regards Michael Boman -- Michael Boman Security Architect, SecureCiRT (A SBU of Z-Vance Pte Ltd) http://www.securecirt.com |
From: Bob P. <rn...@op...> - 2002-11-14 21:23:09
|
At 02:06 AM 11/14/02 -0500, I wrote: >I'm testing a possible solution tonight. Will forward the results tomorrow. > >Bob > >At 01:08 PM 11/13/02 -0500, I wrote: >>SourceForge Bug 637894 has been opened for this problem. >><etc> The following patches are for msyslogd 1.08e ONLY!!! This problem has been addressed already in 1.09. I have closed my SourceForge Bug report 637894. These patches to src/modules/im_tcp.c fix this problem, as well as one reported earlier, in 1.08e ONLY. Bob ======================================================================== --- src/modules/im_tcp.c.orig Fri Mar 1 02:31:02 2002 +++ src/modules/im_tcp.c Thu Nov 14 14:34:15 2002 @@ -269,13 +269,13 @@ if (con == c->first) { c->first = con->next; - if (con == c->last) - c->last = NULL; } else { for(prev = c->first; prev->next != con; prev = prev->next); prev->next = con->next; } + if (con == c->last) + c->last = NULL; if (con->saveline[0] != '\0') printline(ret->im_host, con->saveline, @@ -297,7 +297,6 @@ /* terminate it */ (im->im_buf)[n] = '\0'; - p = &im->im_buf[0]; dprintf(MSYSLOG_INFORMATIVE, "im_tcp_read: read: %s [%s]", con->name, im->im_buf); @@ -311,8 +310,6 @@ do { char *msg; - msg = p; - /* multiple lines ? */ if((nextline = strchr(p, '\n')) != NULL) { /* terminate this line and advance */ @@ -324,6 +321,7 @@ strncat(con->saveline, p, sizeof(con->saveline) - 1); con->saveline[sizeof(con->saveline) - 1] = '\0'; + return (0); } /* remove trailing carriage returns */ @@ -338,20 +336,20 @@ return (0); } + if (con->saveline[0] != '\0') { + strncat(con->saveline, p, + sizeof(con->saveline) - 1); + con->saveline[sizeof(con->saveline) - 1] + = '\0'; + msg = con->saveline; + } else { + msg = p; + } + if (c->flags & M_USEMSGHOST) { char host[90]; int n1, n2; - if (con->saveline[0] != '\0') { - strncat(con->saveline, p, - sizeof(con->saveline) - 1); - con->saveline[sizeof(con->saveline) - 1] - = '\0'; - msg = con->saveline; - } else { - msg = p; - } - /* extract hostname from message */ if ((sscanf(msg, "<%*d>%*3s %*i %*i:%*i:%*i %n%89s" " %n", &n1, host, &n2) != 1 && @@ -367,8 +365,8 @@ p = nextline; continue; } else { - return (0); con->saveline[0] = '\0'; + return (0); } } ======================================================================== |
From: Bob P. <rn...@op...> - 2002-11-14 07:10:44
|
I'm testing a possible solution tonight. Will forward the results tomorrow. Bob At 01:08 PM 11/13/02 -0500, I wrote: >SourceForge Bug 637894 has been opened for this problem. ><etc> |
From: Bob P. <rn...@op...> - 2002-11-13 18:11:51
|
SourceForge Bug 637894 has been opened for this problem. I am running msyslogd 1.08e on two OpenBSD 3.1 machines. One is a firewall using IPFilter and the second is a logging server. The appropriate syslog.conf entries are: ---------- firewall - syslog.conf *.* %tcp -a -h loghost -p 5445 -m 30 -s 61440 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D loghost - syslog.conf *.notice;auth,authpriv,cron,local0,ftp,kern,lpr,mail,user.none %classic=20 /var/log/messages kern,user,syslog.debug %classic /var/log/messages local0.debug %classic /var/log/ipflog ---------- IPFilter uses local0 and it's entries are logged in /var/log/ipflog. The problem I'm experiencing seems to be related to times when the firewall has a large number of log entries in a short time. They are collected and sent together via the TCP connection to the loghost. Sometimes, the amount of data to be sent exceeds the maximum 1448 byte packet size, so multiple packets are sent. msyslogd on the firewall splits the packets at the 1448 byte packet boundary, usually splitting one log record between two packets. Following is a tcpdump of one of these transactions: ---------- 14:46:02.498804 10.254.255.245.18358 > 10.254.255.246.5445: .=20 20754:22202(1448) ack 1 win 17376 <nop,nop,timestamp 37202867 490894253>= (DF) 0000: 4500 05dc 62f3 4000 4006 bc40 0afe fff5 E..=DCb=F3@.@.=BC@.=FE=FF= =F5 0010: 0afe fff6 47b6 1545 ed5b fc6d 2467 592b .=FE=FF=F6G=B6.E=ED[=FCm$g= Y+ 0020: 8010 43e0 9c15 0000 0101 080a 0237 abb3 ..C=E0.........7=AB=B3 0030: 1d42 73ad 3c31 3332 3e4e 6f76 2031 3220 .Bs=AD<132>Nov 12 0040: 3134 3a34 363a 3032 2046 7761 6c6c 2069 14:46:02 Fwall i 0050: 706d 6f6e 5b39 3334 355d 3a20 3134 3a34 pmon[9345]: 14:4 0060: 363a 3031 2e36 3837 3931 3220 6678 7030 6:01.687912 fxp0 0070: 2040 3131 323a 3232 2062 2032 342e 3938 @112:22 b 24.98 0080: 2e38 2e37 332c 3137 3039 202d 3e20 3139 .8.73,1709 -> 19 0090: 322e 3136 382e 312e 3233 302c 3134 3333 2.168.1.230,1433 00a0: 2050 5220 7463 7020 6c65 6e20 3230 2034 PR tcp len 20 4 00b0: 3820 2d53 2049 4e20 0a3c 3133 323e 4e6f 8 -S IN .<132>No 00c0: 7620 3132 2031 343a 3436 3a30 3220 4677 v 12 14:46:02 Fw 00d0: 616c 6c20 6970 6d6f 6e5b 3933 3435 5d3a all ipmon[9345]: 00e0: 2031 343a 3436 3a30 312e 3738 3536 3836 14:46:01.785686 00f0: 2066 7870 3020 4031 3132 3a32 3220 6220 fxp0 @112:22 b 0100: 3234 2e39 382e 382e 3733 2c31 3730 3420 24.98.8.73,1704 0110: 2d3e 2031 3932 2e31 3638 2e31 2e32 3235 -> 192.168.1.225 0120: 2c31 3433 3320 5052 2074 6370 206c 656e ,1433 PR tcp len 0130: 2032 3020 3438 202d 5320 494e 200a 3c31 20 48 -S IN .<1 <snip> 04e0: 0a3c 3133 323e 4e6f 7620 3132 2031 343a .<132>Nov 12 14: 04f0: 3436 3a30 3220 4677 616c 6c20 6970 6d6f 46:02 Fwall ipmo 0500: 6e5b 3933 3435 5d3a 2031 343a 3436 3a30 n[9345]: 14:46:0 0510: 322e 3238 3835 3837 2066 7870 3020 4031 2.288587 fxp0 @1 0520: 3132 3a32 3220 6220 3234 2e39 382e 382e 12:22 b 24.98.8. 0530: 3733 2c31 3730 3420 2d3e 2031 3932 2e31 73,1704 -> 192.1 0540: 3638 2e31 2e32 3235 2c31 3433 3320 5052 68.1.225,1433 PR 0550: 2074 6370 206c 656e 2032 3020 3438 202d tcp len 20 48 - 0560: 5320 494e 200a 3c31 3332 3e4e 6f76 2031 S IN .<132>Nov 1 <=3D=3D 0570: 3220 3134 3a34 363a 3032 2046 7761 6c6c 2 14:46:02 Fwall <=3D=3D 0580: 2069 706d 6f6e 5b39 3334 355d 3a20 3134 ipmon[9345]: 14 <=3D=3D 0590: 3a34 363a 3032 2e32 3935 3334 3420 6678 :46:02.295344 fx <=3D=3D 05a0: 7030 2040 3131 323a 3232 2062 2032 342e p0 @112:22 b 24. <=3D=3D 05b0: 3938 2e38 2e37 332c 3137 3035 202d 3e20 98.8.73,1705 -> <=3D=3D 05c0: 3139 322e 3136 382e 312e 3232 362c 3134 192.168.1.226,14 <=3D=3D 05d0: 3333 2050 5220 7463 7020 6c65 33 PR tcp le <=3D=3D 14:46:02.499013 10.254.255.245.18358 > 10.254.255.246.5445: P=20 22202:22217(15) ack 1 win 17376 <nop,nop,timestamp 37202867 490894254> (DF) 0000: 4500 0043 2b97 4000 4006 f935 0afe fff5 E..C+.@.@.=F95.=FE=FF=F5 0010: 0afe fff6 47b6 1545 ed5c 0215 2467 592b .=FE=FF=F6G=B6.E=ED\..$gY+ 0020: 8018 43e0 75a1 0000 0101 080a 0237 abb3 ..C=E0u=A1.......7=AB=B3 0030: 1d42 73ae 6e20 3230 2034 3820 2d53 2049 .Bs=AEn 20 48 -S I <=3D=3D 0040: 4e20 0a N . <=3D=3D ---------- Most of the time, as in this case, when the records reach the loghost, the split log record is not reassembled. The portion from the first packet is written to ipflog as a truncated record: ---------- ipflog: Nov 12 14:46:02 Fwall-l Fwall ipmon[9345]: 14:46:02.295344 fxp0 @112:22 b=20 24.98.8.73,1705 -> 192.168.1.226,1433 PR tcp le ---------- The rest of the record, which arrived in packet 2 is written to /var/log/messages. I assume this is done as a result of the kern,user,syslog.debug syslog.conf line, but I'm not sure. ---------- messages: Nov 12 14:46:02 Fwall-l n 20 48 -S IN ---------- I said most of the time above because I found one instance where the split record was reassembled correctly, but another log record included in packet 2 was split between the ipflog and messages files. In this case, the packet split came in the middle of the message priority (<nnn>) at the beginning of a log record. In this case, the first packet ends with "<1" and the second starts with "32>": ---------- 09:42:03.248861 10.254.255.245.18358 > 10.254.255.246.5445: .=20 151879:153327(1448) ack 1 win 17376 <nop,nop,timestamp 37166390 490857776>= (DF) 0000: 4500 05dc f5fb 4000 4006 2938 0afe fff5 E..=DC=F5=FB@.@.)8.=FE=FF= =F5 0010: 0afe fff6 47b6 1545 ed59 fa90 2467 592b .=FE=FF=F6G=B6.E=EDY=FA.$g= Y+ 0020: 8010 43e0 49d5 0000 0101 080a 0237 1d36 ..C=E0I=D5.......7.6 0030: 1d41 e530 3c31 3332 3e4e 6f76 2031 3220 .A=E50<132>Nov 12 0040: 3039 3a34 323a 3033 2046 7761 6c6c 2069 09:42:03 Fwall i 0050: 706d 6f6e 5b39 3334 355d 3a20 3039 3a34 pmon[9345]: 09:4 0060: 323a 3032 2e32 3330 3137 3420 6678 7030 2:02.230174 fxp0 0070: 2040 303a 3520 6220 3230 372e 3432 2e38 @0:5 b 207.42.8 0080: 332e 3438 2c32 3120 2d3e 2032 3136 2e32 3.48,21 -> 216.2 0090: 3031 2e36 332e 3232 392c 3132 3433 2050 01.63.229,1243 P 00a0: 5220 7463 7020 6c65 6e20 3230 2034 3020 R tcp len 20 40 00b0: 2d41 2049 4e20 0a3c 3133 323e 4e6f 7620 -A IN .<132>Nov 00c0: 3132 2030 393a 3432 3a30 3320 466f 616c 12 09:42:03 Fwal 00d0: 6c20 6970 6d6f 6e5b 3933 3435 5d3a 2030 l ipmon[9345]: 0 00e0: 393a 3432 3a30 322e 3233 3233 3636 2066 9:42:02.232366 f 00f0: 7870 3020 4030 3a35 2062 2032 3037 2e34 xp0 @0:5 b 207.4 0100: 322e 3833 2e34 382c 3231 202d 3e20 3231 2.83.48,21 -> 21 0110: 362e 3230 312e 3633 2e32 3239 2c31 3234 6.201.63.229,124 0120: 3320 5052 2074 6370 206c 656e 2032 3020 3 PR tcp len 20 0130: 3430 202d 4146 2049 4e20 0a3c 3133 323e 40 -AF IN .<132> <snip> 04d0: 494e 200a 3c31 3332 3e4e 6f76 2031 3220 IN .<132>Nov 12 04e0: 3039 3a34 323a 3033 2046 7761 6c6c 2069 09:42:03 Fwall i 04f0: 706d 6f6e 5b39 3334 355d 3a20 3039 3a34 pmon[9345]: 09:4 0500: 323a 3032 2e35 3931 3232 3920 6678 7030 2:02.591229 fxp0 0510: 2040 303a 3520 6220 3230 372e 3432 2e38 @0:5 b 207.42.8 0520: 332e 3438 2c32 3120 2d3e 2032 3136 2e32 3.48,21 -> 216.2 0530: 3031 2e36 332e 3232 392c 3132 3336 2050 01.63.229,1236 P 0540: 5220 7463 7020 6c65 6e20 3230 2034 3020 R tcp len 20 40 0550: 2d41 2049 4e20 0a3c 3133 323e 4e6f 7620 -A IN .<132>Nov 0560: 3132 2030 393a 3432 3a30 3320 4677 616c 12 09:42:03 Fwal 0570: 6c20 6970 6d6f 6e5b 3933 3435 5d3a 2030 l ipmon[9345]: 0 0580: 393a 3432 3a30 322e 3637 3436 3438 2066 9:42:02.674648 f 0590: 7870 3020 4030 3a35 2062 2032 3037 2e34 xp0 @0:5 b 207.4 05a0: 322e 3833 2e34 382c 3231 202d 3e20 3231 2.83.48,21 -> 21 05b0: 362e 3230 312e 3633 2e32 3239 2c31 3234 6.201.63.229,124 05c0: 3520 5052 2074 6370 206c 656e 2032 3020 5 PR tcp len 20 05d0: 3430 202d 4120 494e 200a 3c31 40 -A IN .<1 <=3D=3D 09:42:03.248950 10.254.255.245.18358 > 10.254.255.246.5445: P=20 153327:154378(1051) ack 1 win 17376 <nop,nop,timestamp 37166390 490857776>= (DF) 0000: 4500 044f 8a9e 4000 4006 9622 0afe fff5 E..O..@.@..".=FE=FF=F5 0010: 0afe fff6 47b6 1545 ed5a 0038 2467 592b .=FE=FF=F6G=B6.E=EDZ.8$gY+ 0020: 8018 43e0 e0b4 0000 0101 080a 0237 1d36 ..C=E0=E0=B4.......7.6 0030: 1d41 e530 3332 3e4e 6f76 2031 3220 3039 .A=E5032>Nov 12 09 <=3D=3D 0040: 3a34 323a 3033 2046 7761 6c6c 2069 706d :42:03 Fwall ipm <=3D=3D 0050: 6f6e 5b39 3334 355d 3a20 3039 3a34 323a on[9345]: 09:42: <=3D=3D 0060: 3032 2e36 3736 3830 3920 6678 7030 2040 02.676809 fxp0 @ <=3D=3D 0070: 303a 3520 6220 3230 372e 3432 2e38 332e 0:5 b 207.42.83. <=3D=3D 0080: 3438 2c32 3120 2d3e 2032 3136 2e32 3031 48,21 -> 216.201 <=3D=3D 0090: 2e36 332e 3232 392c 3132 3435 2050 5220 .63.229,1245 PR <=3D=3D 00a0: 7463 7020 6c65 6e20 3230 2034 3020 2d41 tcp len 20 40 -A <=3D=3D 00b0: 4620 494e 200a 3c31 3332 3e4e 6f76 2031 F IN .<132>Nov 1 <=3D=3D 00c0: 3220 3039 3a34 323a 3033 2046 7761 6c6c 2 09:42:03 Fwall 00d0: 2069 706d 6f6e 5b39 3334 355d 3a20 3039 ipmon[9345]: 09 00e0: 3a34 323a 3032 2e37 3534 3337 3420 6678 :42:02.754374 fx 00f0: 7030 2040 303a 3520 6220 3230 372e 3432 p0 @0:5 b 207.42 0100: 2e38 332e 3438 2c32 3120 2d3e 2032 3136 .83.48,21 -> 216 0110: 2e32 3031 2e36 332e 3232 392c 3132 3338 .201.63.229,1238 0120: 2050 5220 7463 7020 6c65 6e20 3230 2034 PR tcp len 20 4 0130: 3020 2d41 4620 494e 200a 3c31 3332 3e4e 0 -AF IN .<132>N 0140: 6f76 2031 3220 3039 3a34 323a 3033 2046 ov 12 09:42:03 F 0150: 7761 6c6c 2069 706d 6f6e 5b39 3334 355d wall ipmon[9345] 0160: 3a20 3039 3a34 323a 3032 2e37 3838 3135 : 09:42:02.78815 0170: 3420 6678 7030 2040 303a 3520 6220 3230 4 fxp0 @0:5 b 20 0180: 372e 3432 2e38 332e 3438 2c32 3120 2d3e 7.42.83.48,21 -> 0190: 2032 3136 2e32 3031 2e36 332e 3232 392c 216.201.63.229, 01a0: 3132 3337 2050 5220 7463 7020 6c65 6e20 1237 PR tcp len 01b0: 3230 2034 3020 2d41 2049 4e20 0a3c 3133 20 40 -A IN .<13 01c0: 323e 4e6f 7620 3132 2030 393a 3432 3a30 2>Nov 12 09:42:0 01d0: 3320 4677 616c 6c20 6970 6d6f 6e5b 3933 3 Fwall ipmon[93 01e0: 3435 5d3a 2030 393a 3432 3a30 322e 3836 45]: 09:42:02.86 01f0: 3830 3635 2066 7870 3020 4030 3a35 2062 8065 fxp0 @0:5 b 0200: 2032 3037 2e34 322e 3833 2e34 382c 3231 207.42.83.48,21 0210: 202d 3e20 3231 362e 3230 312e 3633 2e32 -> 216.201.63.2 0220: 3239 2c31 3233 3920 5052 2074 6370 206c 29,1239 PR tcp l 0230: 656e 2032 3020 3430 202d 4146 2049 4e20 en 20 40 -AF IN 0240: 0a3c 3133 323e 4e6f 7620 3132 2030 393a .<132>Nov 12 09: <=3D=3D 0250: 3432 3a30 3320 4677 616c 6c20 6970 6d6f 42:03 Fwall ipmo <=3D=3D 0260: 6e5b 3933 3435 5d3a 2030 393a 3432 3a30 n[9345]: 09:42:0 <=3D=3D 0270: 322e 3837 3133 3435 2066 7870 3020 4030 2.871345 fxp0 @0 <=3D=3D 0280: 3a35 2062 2032 3037 2e34 322e 3833 2e34 :5 b 207.42.83.4 <=3D=3D 0290: 382c 3231 202d 3e20 3231 362e 3230 312e 8,21 -> 216.201. <=3D=3D 02a0: 3633 2e32 3239 2c31 3234 3620 5052 2074 63.229,1246 PR t <=3D=3D 02b0: 6370 206c 656e 2032 3020 3430 202d 4120 cp len 20 40 -A <=3D=3D 02c0: 494e 200a 3c31 3332 3e4e 6f76 2031 3220 IN .<132>Nov 12 <=3D=3D 02d0: 3039 3a34 323a 3033 2046 7761 6c6c 2069 09:42:03 Fwall i 02e0: 706d 6f6e 5b39 3334 355d 3a20 3039 3a34 pmon[9345]: 09:4 02f0: 323a 3032 2e38 3733 3730 3420 6678 7030 2:02.873704 fxp0 0300: 2040 303a 3520 6220 3230 372e 3432 2e38 @0:5 b 207.42.8 0310: 332e 3438 2c32 3120 2d3e 2032 3136 2e32 3.48,21 -> 216.2 0320: 3031 2e36 332e 3232 392c 3132 3436 2050 01.63.229,1246 P 0330: 5220 7463 7020 6c65 6e20 3230 2034 3020 R tcp len 20 40 0340: 2d41 4620 494e 200a 3c31 3332 3e4e 6f76 -AF IN .<132>Nov 0350: 2031 3220 3039 3a34 323a 3033 2046 7761 12 09:42:03 Fwa 0360: 6c6c 2069 706d 6f6e 5b39 3334 355d 3a20 ll ipmon[9345]: 0370: 3039 3a34 323a 3033 2e30 3430 3137 3120 09:42:03.040171 0380: 6678 7030 2040 303a 3520 6220 3230 372e fxp0 @0:5 b 207. 0390: 3432 2e38 332e 3438 2c32 3120 2d3e 2032 42.83.48,21 -> 2 03a0: 3136 2e32 3031 2e36 332e 3232 392c 3132 16.201.63.229,12 03b0: 3437 2050 5220 7463 7020 6c65 6e20 3230 47 PR tcp len 20 03c0: 2034 3020 2d41 2049 4e20 0a3c 3133 323e 40 -A IN .<132> 03d0: 4e6f 7620 3132 2030 393a 3432 3a30 3320 Nov 12 09:42:03 03e0: 4677 616c 6c20 6970 6d6f 6e5b 3933 3435 Fwall ipmon[9345 03f0: 5d3a 2030 393a 3432 3a30 332e 3034 3233 ]: 09:42:03.0423 0400: 3432 2066 7870 3020 4030 3a35 2062 2032 42 fxp0 @0:5 b 2 0410: 3037 2e34 322e 3833 2e34 382c 3231 202d 07.42.83.48,21 - 0420: 3e20 3231 362e 3230 312e 3633 2e32 3239 > 216.201.63.229 0430: 2c31 3234 3720 5052 2074 6370 206c 656e ,1247 PR tcp len 0440: 2032 3020 3430 202d 4146 2049 4e20 0a 20 40 -AF IN . ipflog: Nov 12 09:42:03 Fwall-l Fwall ipmon[9345]: 09:42:02.674648 fxp0 @0:5 b=20 207.42.83 .48,21 -> 216.201.63.229,1245 PR tcp len 20 40 -A IN Nov 12 09:42:03 Fwall-l Fwall ipmon[9345]: 09:42:02.676809 fxp0 @0:5 b=20 207.42.83 .48,21 -> 216.201.63.229,1245 PR tcp len 20 40 -AF IN Nov 12 09:42:03 Fwall-l Fwall ipmon[9345]: 09:42:02.754374 fxp0 @0:5 b=20 207.42.83 .48,21 -> 216.201.63.229,1238 PR tcp len 20 40 -AF IN Nov 12 09:42:03 Fwall-l Fwall ipmon[9345]: 09:42:02.788154 fxp0 @0:5 b=20 207.42.83 .48,21 -> 216.201.63.229,1237 PR tcp len 20 40 -A IN Nov 12 09:42:03 Fwall-l Fwall ipmon[9345]: 09:42:02.868065 fxp0 @0:5 b=20 207.42.83 .48,21 -> 216.201.63.229,1239 PR tcp len 20 40 -AF IN Nov 12 09:42:03 Fwall-l Fwall ipmon[9345]: 09:42:02.871345 fxp0 @0:5 b= 207.42. Nov 12 09:42:03 Fwall-l Fwall ipmon[9345]: 09:42:02.873704 fxp0 @0:5 b=20 207.42.83 .48,21 -> 216.201.63.229,1246 PR tcp len 20 40 -AF IN Nov 12 09:42:03 Fwall-l Fwall ipmon[9345]: 09:42:03.040171 fxp0 @0:5 b=20 207.42.83 .48,21 -> 216.201.63.229,1247 PR tcp len 20 40 -A IN Nov 12 09:42:03 Fwall-l Fwall ipmon[9345]: 09:42:03.042342 fxp0 @0:5 b=20 207.42.83 .48,21 -> 216.201.63.229,1247 PR tcp len 20 40 -AF IN messages: Nov 12 09:42:03 Fwall-l 83.48,21 -> 216.201.63.229,1246 PR tcp len 20 40 -A= IN ---------- The other exception is when the first packet ends with just the "<" and the second starts with "132>". In this case, it looks like the "<" is dropped and the entire log record, including the "132>" is written to the messages file: ---------- 09:42:02.050922 10.254.255.245.18358 > 10.254.255.246.5445: .=20 149774:151222(1448) ack 1 win 17376 <nop,nop,timestamp 37166388 490857774>= (DF) 0000: 4500 05dc f13f 4000 4006 2df4 0afe fff5 E..=DC=F1?@.@.-=F4.=FE=FF= =F5 0010: 0afe fff6 47b6 1545 ed59 f257 2467 592b .=FE=FF=F6G=B6.E=EDY=F2W$g= Y+ 0020: 8010 43e0 262f 0000 0101 080a 0237 1d34 ..C=E0&/.......7.4 0030: 1d41 e52e 3c31 3332 3e4e 6f76 2031 3220 .A=E5.<132>Nov 12 0040: 3039 3a34 323a 3032 2046 7761 6c6c 2069 09:42:02 Fwall i 0050: 706d 6f6e 5b39 3334 355d 3a20 3039 3a34 pmon[9345]: 09:4 0060: 323a 3031 2e30 3831 3634 3420 6678 7030 2:01.081644 fxp0 0070: 2040 303a 3520 6220 3230 372e 3432 2e38 @0:5 b 207.42.8 0080: 332e 3438 2c32 3120 2d3e 2032 3136 2e32 3.48,21 -> 216.2 0090: 3031 2e36 332e 3232 392c 3132 3337 2050 01.63.229,1237 P 00a0: 5220 7463 7020 6c65 6e20 3230 2034 3020 R tcp len 20 40 00b0: 2d41 4620 494e 200a 3c31 3332 3e4e 6f76 -AF IN .<132>Nov <snip> 0550: 2d41 4620 494e 200a 3c31 3332 3e4e 6f76 -AF IN .<132>Nov 0560: 2031 3220 3039 3a34 323a 3032 2046 7761 12 09:42:02 Fwa 0570: 6c6c 2069 706d 6f6e 5b39 3334 355d 3a20 ll ipmon[9345]: 0580: 3039 3a34 323a 3031 2e38 3838 3137 3720 09:42:01.888177 0590: 6678 7030 2040 303a 3520 6220 3230 372e fxp0 @0:5 b 207. 05a0: 3432 2e38 332e 3438 2c32 3120 2d3e 2032 42.83.48,21 -> 2 05b0: 3136 2e32 3031 2e36 332e 3232 392c 3132 16.201.63.229,12 05c0: 3431 2050 5220 7463 7020 6c65 6e20 3230 41 PR tcp len 20 05d0: 2034 3020 2d41 2049 4e20 0a3c 40 -A IN .< <=3D=3D 09:42:02.051163 10.254.255.245.18358 > 10.254.255.246.5445: P=20 151222:151484(262) ack 1 win 17376 <nop,nop,timestamp 37166388 490857774>= (DF) 0000: 4500 013a d62d 4000 4006 4da8 0afe fff5 E..:=D6-@.@.M=A8.=FE=FF=F5 0010: 0afe fff6 47b6 1545 ed59 f7ff 2467 592b .=FE=FF=F6G=B6.E=EDY=F7=FF= $gY+ 0020: 8018 43e0 6a4c 0000 0101 080a 0237 1d34 ..C=E0jL.......7.4 0030: 1d41 e52e 3133 323e 4e6f 7620 3132 2030 .A=E5.132>Nov 12 0 <=3D=3D 0040: 393a 3432 3a30 3220 4677 616c 6c20 6970 9:42:02 Fwall ip <=3D=3D 0050: 6d6f 6e5b 3933 3435 5d3a 2030 393a 3432 mon[9345]: 09:42 <=3D=3D 0060: 3a30 312e 3839 3034 3034 2066 7870 3020 :01.890404 fxp0 <=3D=3D 0070: 4030 3a35 2062 2032 3037 2e34 322e 3833 @0:5 b 207.42.83 <=3D=3D 0080: 2e34 382c 3231 202d 3e20 3231 362e 3230 .48,21 -> 216.20 <=3D=3D 0090: 312e 3633 2e32 3239 2c31 3234 3120 5052 1.63.229,1241 PR <=3D=3D 00a0: 2074 6370 206c 656e 2032 3020 3430 202d tcp len 20 40 - <=3D=3D 00b0: 4146 2049 4e20 0a3c 3133 323e 4e6f 7620 AF IN .<132>Nov <=3D=3D 00c0: 3132 2030 393a 3432 3a30 3220 4677 616c 12 09:42:02 Fwal 00d0: 6c20 6970 6d6f 6e5b 3933 3435 5d3a 2030 l ipmon[9345]: 0 00e0: 393a 3432 3a30 312e 3839 3439 3834 2066 9:42:01.894984 f 00f0: 7870 3020 4030 3a35 2062 2032 3037 2e34 xp0 @0:5 b 207.4 0100: 322e 3833 2e34 382c 3231 202d 3e20 3231 2.83.48,21 -> 21 0110: 362e 3230 312e 3633 2e32 3239 2c31 3232 6.201.63.229,122 0120: 3520 5052 2074 6370 206c 656e 2032 3020 5 PR tcp len 20 0130: 3430 202d 4120 494e 200a 40 -A IN . messages: Nov 12 09:42:02 Fwall-l 132>Nov 12 09:42:02 Fwall ipmon[9345]:=20 09:42:01.890404 f xp0 @0:5 b 207.42.83.48,21 -> 216.201.63.229,1241 PR tcp len 20 40 -AF IN ---------- And lastly, when /usr/bin/newsyslog is run, in my case at midnight, to rotate the log files, msyslogd dumps a single record into the ipflog file containing all of the truncated messages from the day: ---------- tail -3 messages: Nov 12 23:52:51 Fwall-l Fwall ipmon[9345]: 23:52:51.006434 fxp0 @0:5 b=20 61.5.16.30,1028 -> 216.201.36.231,137 PR udp len 20 78 IN Nov 12 06:55:01 Fwall-l Fwall ipmon[9345]: 06:55:00.978193 fxp0 @111:6 b=20 209.253.191.210,2790 -> 216.201.36.229,1433 PR<132>Nov 12 09:28:48 Fwall=20 ipmon[9345]: 09:28:48.049440 fxp0 @111:6 <<132>Nov 12 09:42:03 Fwall=20 ipmon[9345]: 09:42:02.871345 fxp0 @0:5 b 207.42.<132>Nov 12 12:13:55 Fwall= =20 ipmon[9345]: 12:13:55.538854 fxp0 @112:22 b 66.123.<132>Nov 12 12:29:02=20 Fwall ipmon[9345]: 12:29:02.615324 fxp0 @111:6 b 210.97.1<132>Nov 12=20 12:57:58 Fwall ipmon[9345]: 12:57:58.845979 fxp0 @112:22 b=20 65.100.132.9,2960<132>Nov 12 14:46:02 Fwall ipmon[9345]: 14:46:02.295344=20 fxp0 @112:22 b 24.98.8.73,1705 -> 192.168.1.226,1433 PR tcp le<132>Nov 12=20 21:23:09 Fwall ipmon[9345]: 21:23:09.390134 fxp0 @112:22 b=20 64.228.68.106,348<132>Nov 12 21:32:30 Fwall ipmon[9345]: 21:32:30.077085=20 fxp0 @111:6 b 133.35.75.3,2671 -> 216.201.36.224,143 Nov 13 00:00:01 BosIDS newsyslog[21199]: logfile turned over ---------- Sorry for the long message, but hopefully the info helps to resolve the problem. Please let me know if you need anything else or if I can help in any way. Bob |
From: Fredrick P. E. <ph...@ne...> - 2002-10-30 23:07:45
|
Florin Andrei wrote: >Guys, > >With the 1.08 versions, what do you think is the best method to push the >messages outside to an external parser? > >What i'm thinking is, i need to watch for certain messages to occur, and >then trigger an event based on that (usually an e-mail). A Perl script >or something like that would be perfect, but there are several methods >to extract messages out of msyslog and stuff'em down on the script's >throat. >What do you think is the "best" method to accomplish this with 1.08(e)? > Set up a daemon listening on a tcp/udp(/unix) handle and write to it. Of course, 1.09 has other mechanisms ;-) |
From: Florin A. <fl...@sg...> - 2002-10-30 21:21:35
|
Guys, With the 1.08 versions, what do you think is the best method to push the messages outside to an external parser? What i'm thinking is, i need to watch for certain messages to occur, and then trigger an event based on that (usually an e-mail). A Perl script or something like that would be perfect, but there are several methods to extract messages out of msyslog and stuff'em down on the script's throat. What do you think is the "best" method to accomplish this with 1.08(e)? -- Florin Andrei Many would-be screenwriters seem to have the impression that they can write a script based only on an idea. This is similar to the impression that many had during the "dot-com" era that they could get venture capital for an idea. (Many did, of course, but that's another story.) |
From: Florin A. <fl...@sg...> - 2002-10-29 19:58:11
|
Basically, 1.09c does not work at all on Linux Red Hat 7.2 and 8.0 I run it with -d 9999, and sent a message from the local host ("logger testmessage"). The message didn't showed up in the log files, and i didn't see any indication on the terminal, even though -d 9999 is supposed to print a lot of stuff. I attached the typescript. -- Florin Andrei Many would-be screenwriters seem to have the impression that they can write a script based only on an idea. This is similar to the impression that many had during the "dot-com" era that they could get venture capital for an idea. (Many did, of course, but that's another story.) |
From: Florin A. <fl...@sg...> - 2002-10-29 19:02:44
|
Build fails, because the main library cannot be compiled: [florin@stantz msyslog-v1.09c]$ make make[1]: Entering directory `/home/florin/compile/msyslog-v1.09c/src/peo' gcc -g -O2 -Wall -I.. -c peochk.c -o peochk.o gcc -g -O2 -Wall -I.. -c ../options.c -o ../options.o gcc -g -O2 -Wall -I.. -c hash.c -o hash.o gcc -g -O2 -Wall -I.. -c md5c.c -o md5c.o gcc -g -O2 -Wall -I.. -c sha1.c -o sha1.o gcc -g -O2 -Wall -I.. -c rmd160.c -o rmd160.o gcc -g -O2 -Wall peochk.o ../options.o hash.o md5c.o sha1.o rmd160.o -o peochk make[1]: Leaving directory `/home/florin/compile/msyslog-v1.09c/src/peo' make[1]: Entering directory `/home/florin/compile/msyslog-v1.09c/src/modules' gcc -g -O2 -Wall -I.. -c im_linux.c -o im_linux.o gcc -g -O2 -Wall -I.. -c im_udp.c -o im_udp.o gcc -g -O2 -Wall -I.. -c om_udp.c -o om_udp.o gcc -g -O2 -Wall -I.. -c im_unix.c -o im_unix.o gcc -g -O2 -Wall -I.. -c im_file.c -o im_file.o gcc -g -O2 -Wall -I.. -c om_classic.c -o om_classic.o gcc -g -O2 -Wall -I.. -c ttymsg.c -o ttymsg.o gcc -g -O2 -Wall -I.. -c om_tcp.c -o om_tcp.o gcc -g -O2 -Wall -I.. -c im_tcp.c -o im_tcp.o gcc -g -O2 -Wall -I.. -c ip_misc.c -o ip_misc.o gcc -g -O2 -Wall -I.. -c om_mysql.c -o om_mysql.o gcc -g -O2 -Wall -I.. -c om_pgsql.c -o om_pgsql.o gcc -g -O2 -Wall -I.. -c sql_misc.c -o sql_misc.o gcc -g -O2 -Wall -I.. -c om_queue.c -o om_queue.o om_queue.c: In function `om_queue_init': om_queue.c:445: warning: long unsigned int format, key_t arg (arg 4) om_queue.c:445: warning: long unsigned int format, key_t arg (arg 4) gcc -g -O2 -Wall -I.. -c om_directory.c -o om_directory.o om_directory.c: In function `om_directory_init': om_directory.c:289: warning: long unsigned int format, key_t arg (arg 4) om_directory.c:289: warning: long unsigned int format, key_t arg (arg 4) gcc -g -O2 -Wall -I.. -c om_refract.c -o om_refract.o gcc -g -O2 -Wall -I.. -c om_peo.c -o om_peo.o gcc -g -O2 -Wall -I.. -c om_regex.c -o om_regex.o om_regex.c:529:2: warning: #warning FIX THIS make[1]: *** No rule to make target `md5c.o', needed by `libmsyslog.so.1.09c'. Stop. make[1]: Leaving directory `/home/florin/compile/msyslog-v1.09c/src/modules' make[1]: Entering directory `/home/florin/compile/msyslog-v1.09c/src' gcc -g -O2 -Wall -I. -c modules.c -o modules.o gcc -g -O2 -Wall -I. -c syslogd.c -o syslogd.o syslogd.c: In function `watch_fd_input': syslogd.c:1732: warning: deprecated use of label at end of compound statement syslogd.c: In function `unwatch_fd_input': syslogd.c:1777: warning: deprecated use of label at end of compound statement gcc -g -O2 -Wall -I. -ldl -lnsl -Xlinker -E modules.o syslogd.o options.o -o syslogd make[1]: Leaving directory `/home/florin/compile/msyslog-v1.09c/src' make[1]: Entering directory `/home/florin/compile/msyslog-v1.09c/src/man' all done make[1]: Leaving directory `/home/florin/compile/msyslog-v1.09c/src/man' On Mon, 2002-10-28 at 20:28, Alejo Sanchez wrote: > > Yes, can't tell HOW this tarball got busted. > (it happened before... but at least src was tagged) > could you try the 1.09c tarball now? > > the msyslog directory is for UNFINISHED/DEVELOPMENT 2.X version, > with source broken since I got paranoid to loose work > on the source... > > Sorry for the inconvenience, > > Alejo > > Bob Perkins wrote: > > 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 > > > > ------------------------------------------------------- > 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 Many would-be screenwriters seem to have the impression that they can write a script based only on an idea. This is similar to the impression that many had during the "dot-com" era that they could get venture capital for an idea. (Many did, of course, but that's another story.) |
From: Florin A. <fl...@sg...> - 2002-10-29 18:08:48
|
Just saw it on Freshmeat: http://www.csh.rit.edu/~mattw/proj/dns/ It might be useful, since msyslog is doing a lot of DNS lookups. Disabling the lookups is a good feature, and could be the right thing in certain scenarios (for example, in my case ;-) ) but i can imagine other scenarios where people might _need_ the DNS lookups turned on. In those cases, running a local DNS cache (Bind, djbdns) on that machine could be a good idea. But a caching layer in the application itself could be useful too sometimes. Well, it's just an idea... I could be wrong. -- Florin Andrei Many would-be screenwriters seem to have the impression that they can write a script based only on an idea. This is similar to the impression that many had during the "dot-com" era that they could get venture capital for an idea. (Many did, of course, but that's another story.) |
From: Alejo S. <al...@ve...> - 2002-10-29 04:35:05
|
Yes, can't tell HOW this tarball got busted. (it happened before... but at least src was tagged) could you try the 1.09c tarball now? the msyslog directory is for UNFINISHED/DEVELOPMENT 2.X version, with source broken since I got paranoid to loose work on the source... Sorry for the inconvenience, Alejo Bob Perkins wrote: > 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 |