From jiri.hlinka at gmail.com Fri Apr 2 00:52:03 2010 From: jiri.hlinka at gmail.com (=?UTF-8?B?SmnFmcOtIEhsaW5rYQ==?=) Date: Fri, 2 Apr 2010 00:52:03 +0200 Subject: [rsyslog] RHEL 5.5 and rsyslog packages Message-ID: Hi, RHEL 5.5 was released recently and it includes updated rsyslog version too. As many of you may know, up to RHEL 5.4 there was rsyslog version 2.0.6 which is rather old and unsupported. But changes have been made in RHEL 5 update 5: it includes package rsyslog (+ rsyslog-[module_name], see below) version 3.22.1. But there is yet another rsyslog version - package rsyslog4 (+ rsyslog4-[module_name]) serves version 4.4.2! Modules included in separated rpms: gnutls gssapi mysql pgsql relp (just for rsyslog4 package) Well, these are not the latest ones, but it is progredss indeed :-) . Cheers, Jirka -- Ji?? Hlinka GSM: +420 773 103 947 Enlogit s.r.o., U Cukrovaru 509/4, 400 07 ?st? nad Labem tel.: +420 474 745 159, fax: +420 474 745 160 web: www.enlogit.cz Enlogit IT pro firmy From joel.sinor at gmail.com Sun Apr 4 04:07:59 2010 From: joel.sinor at gmail.com (Joel Sinor) Date: Sat, 3 Apr 2010 21:07:59 -0500 Subject: [rsyslog] Could not open dynamic file ... - discarding message Message-ID: Hello, I was reading up on this error (Could not open dynamic file) which occurred when I tried to use dynamic files, and found the following post: http://www.mail-archive.com/rsyslog at lists.adiscon.com/msg02505.html Now, I run Ubuntu, and the PrivDrop statements are in the rsyslog.conf by default on that distribution. The problem is further described in an Ubuntu bug (although the only Ubuntu-specific problem here is the PrivDrop statements being default on that distribution): https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/484336 The relevant lines in rsyslog.conf are: # # Set the default permissions for all log files. # $FileOwner syslog $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 $PrivDropToUser syslog $PrivDropToGroup syslog What happens is rsyslog is able to create the dynamic files, but it cannot access them to write to them, as described in the emails earlier on the list. I found that when I created a directory for these files, with 755 permissions owned by syslog and group syslog. The files would get created with 640 permissions owned by syslog:syslog and yet rsyslog would not be able to write to them. Rather than lose the safety provided by PrivDrop I found, based on the bug report above, that all you have to do is change the group to adm and it works: # # Set the default permissions for all log files. # $FileOwner syslog $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 $PrivDropToUser syslog $PrivDropToGroup adm Then the log files end up being owned by syslog:adm instead of syslog:syslog and rsyslog is able to write to them. I am not sure why this works. What's even more puzzling is that at least on my system (Ubuntu 9.10) syslog is not part of the adm group at all. I'm guessing that when you call the function to drop privileges to a group it doesn't care whether the user you drop to is part of the group you drop to. It is funny though. Anyway I am sending this out in hope that others might benefit from not having to completely dump PrivDrop, and that maybe some light will be shed on why this mechanism is not working properly in this case. It does not make sense that having the right owner still does not result in being able to write to and open files, and that you have to change the group to adm. It seems to me that there is some problem internal to rsyslog that is causing this to happen. From tbergfeld at hq.adiscon.com Fri Apr 9 14:46:08 2010 From: tbergfeld at hq.adiscon.com (Tom Bergfeld) Date: Fri, 9 Apr 2010 14:46:08 +0200 Subject: [rsyslog] rsyslog 5.5.3 (devel) released Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103C2A@GRFEXC.intern.adiscon.com> Hi all, We have just released rsyslog 5.5.3, a member of the devel branch. This is a bug-fixing release containing some important fixes and also the added basic but functional support for Solaris. Furthermore there are some imported patches from 4.6.0. It is a recommended update for all users of the devel branch. See Changelog for more details. ChangeLog: http://www.rsyslog.com/Article450.phtml Download: http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-199.phtml As always, feedback is appreciated. Best regards, Tom Bergfeld -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com From tbergfeld at hq.adiscon.com Wed Apr 14 16:46:52 2010 From: tbergfeld at hq.adiscon.com (Tom Bergfeld) Date: Wed, 14 Apr 2010 16:46:52 +0200 Subject: [rsyslog] rsyslog 4.7.0 (v4-devel) released Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103C74@GRFEXC.intern.adiscon.com> Hi all, We have just released rsyslog 4.7.0, a member of the v4-devel branch. This release offers Solaris support and also some fixes and enhancements. All the details you will find in 'Rainer's Blog' http://blog.gerhards.net/2010/04/v4-devel-is-back-again.html and of course in the Changelog. ChangeLog: http://www.rsyslog.com/Article453.phtml Download: http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-200.phtml As always, feedback is appreciated. Best regards, Tom Bergfeld -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com From kristian.jones at ntlworld.com Mon Apr 19 11:24:20 2010 From: kristian.jones at ntlworld.com (kristian.jones at ntlworld.com) Date: Mon, 19 Apr 2010 10:24:20 +0100 Subject: [rsyslog] iptables and centralised logs with rsyslog and UDP Message-ID: <20100419102420.T3NO6.126539.root@web01-winn.ispmail.private.ntl.com> Hi All, I have a problem that I'm not sure how to get around. I have 3 machines, a client, a firewall and a log store. The firewall is Linux running iptables. The client and log store are on different networks (X.X.4.X) and (X.X.5.X). The firewall is used to bridge these networks. I've configured rsyslog on the client (.4.) to send messages to the log store (.5.) I've also configured a template on the log store to print the $fromhost-ip and original raw message and I'm printing everything (*.*) to the log files. When the firewall rewrites the source address (so they appear to be coming from the .5.x network), the messages get logged. If I leave the source address alone, the messages disappear. I know the packets are arriving at the log store with both configurations because I can see this with TCPDUMP on the log store. On the firewall I have the following configuration that I've put together. iptables -A POSTROUTING -t nat -o eth1 -j ACCEPT iptables -A PREROUTING -t nat -i -p udp --dport 514 -j DNAT --to-destination X.X.5.X (On my actual config the Xs are not blanked out). Unfortunately with this rule in place I do not see anything in the log file. Changing the first line of the iptables config to iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE means that I can now see output getting to my log files but the ipaddress is incorrect. Is this a bug? or Is rsyslog doing some intelligent work under the hood to detect ip address spoofing? I'm using ubuntu server 9.10. Unfortunately using the hostname instead of the ipaddress in my case is not an option Hope someone can help Kris From epiphani at gmail.com Mon Apr 19 14:24:51 2010 From: epiphani at gmail.com (Aaron Wiebe) Date: Mon, 19 Apr 2010 08:24:51 -0400 Subject: [rsyslog] iptables and centralised logs with rsyslog and UDP In-Reply-To: <20100419102420.T3NO6.126539.root@web01-winn.ispmail.private.ntl.com> References: <20100419102420.T3NO6.126539.root@web01-winn.ispmail.private.ntl.com> Message-ID: Kris, it sounds as though your iptables rules aren't working very well for you. I suggest you set up wireshark or tcpdump on the log host machine and run the test again - I bet you would find that the traffic isn't making it. In the case that the IP isn't rewritten, that is expected. You're doing NAT, so rsyslog would have no other detail about the remote host you are originally delivering the data from. At this point I think most of your problems are iptables related, and not really rsyslog related. -Aaron On Mon, Apr 19, 2010 at 5:24 AM, wrote: > Hi All, > > I have a problem that I'm not sure how to get around. > > I have 3 machines, a client, a firewall and a log store. The firewall is Linux running iptables. The client and log store are on different networks (X.X.4.X) and (X.X.5.X). The firewall is used to bridge these networks. > > I've configured rsyslog on the client (.4.) to send messages to the log store (.5.) I've also configured a template on the log store to print the $fromhost-ip and original raw message and I'm printing everything (*.*) to the log files. > > When the firewall rewrites the source address (so they appear to be coming from the .5.x network), the messages get logged. If I leave the source address alone, the messages disappear. I know the packets are arriving at the log store with both configurations because I can see this with TCPDUMP on the log store. > > On the firewall I have the following configuration that I've put together. > > iptables -A POSTROUTING -t nat -o eth1 -j ACCEPT > iptables -A PREROUTING -t nat -i -p udp --dport 514 -j DNAT --to-destination X.X.5.X > > (On my actual config the Xs are not blanked out). > > Unfortunately with this rule in place I do not see anything in the log file. > > Changing the first line of the iptables config to > > iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE > > means that I can now see output getting to my log files but the ipaddress is incorrect. > > Is this a bug? or Is rsyslog doing some intelligent work under the hood to detect ip address spoofing? I'm using ubuntu server 9.10. Unfortunately using the hostname instead of the ipaddress in my case is not an option > > Hope someone can help > Kris > > > > > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From kristian.jones at ntlworld.com Mon Apr 19 16:05:26 2010 From: kristian.jones at ntlworld.com (kristian.jones at ntlworld.com) Date: Mon, 19 Apr 2010 15:05:26 +0100 Subject: [rsyslog] iptables and centralised logs with rsyslog and UDP In-Reply-To: Message-ID: <20100419150526.JOYOF.92148.root@web02-winn.ispmail.private.ntl.com> Hi Aaron, I've ran tcpdump on the log store (not the client) and I can see the packets hitting the server, it seems to be rsyslog thats not picking them up. Using tcpdump and the first iptables config, gives the correct ip address when tcpdump is run on the log store, but no message is shown in the log files. Using tcpdump and the second iptables config, gives the ip address of firewall when tcpdump is run on the log store and the message appears in log file on disk. Hopefully that makes it a little more clear but apologies if I misunderstood the reply Thanks Kris ---- Aaron Wiebe wrote: > Kris, it sounds as though your iptables rules aren't working very > well for you. I suggest you set up wireshark or tcpdump on the log > host machine and run the test again - I bet you would find that the > traffic isn't making it. In the case that the IP isn't rewritten, > that is expected. You're doing NAT, so rsyslog would have no other > detail about the remote host you are originally delivering the data > from. > > At this point I think most of your problems are iptables related, and > not really rsyslog related. > > -Aaron > > On Mon, Apr 19, 2010 at 5:24 AM, wrote: > > Hi All, > > > > I have a problem that I'm not sure how to get around. > > > > I have 3 machines, a client, a firewall and a log store. The firewall is Linux running iptables. The client and log store are on different networks (X.X.4.X) and (X.X.5.X). The firewall is used to bridge these networks. > > > > I've configured rsyslog on the client (.4.) to send messages to the log store (.5.) I've also configured a template on the log store to print the $fromhost-ip and original raw message and I'm printing everything (*.*) to the log files. > > > > When the firewall rewrites the source address (so they appear to be coming from the .5.x network), the messages get logged. If I leave the source address alone, the messages disappear. I know the packets are arriving at the log store with both configurations because I can see this with TCPDUMP on the log store. > > > > On the firewall I have the following configuration that I've put together. > > > > iptables -A POSTROUTING -t nat -o eth1 -j ACCEPT > > iptables -A PREROUTING -t nat -i -p udp --dport 514 -j DNAT --to-destination X.X.5.X > > > > (On my actual config the Xs are not blanked out). > > > > Unfortunately with this rule in place I do not see anything in the log file. > > > > Changing the first line of the iptables config to > > > > iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE > > > > means that I can now see output getting to my log files but the ipaddress is incorrect. > > > > Is this a bug? or Is rsyslog doing some intelligent work under the hood to detect ip address spoofing? I'm using ubuntu server 9.10. Unfortunately using the hostname instead of the ipaddress in my case is not an option > > > > Hope someone can help > > Kris > > > > > > > > > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From epiphani at gmail.com Mon Apr 19 16:13:30 2010 From: epiphani at gmail.com (Aaron Wiebe) Date: Mon, 19 Apr 2010 10:13:30 -0400 Subject: [rsyslog] iptables and centralised logs with rsyslog and UDP In-Reply-To: <20100419150526.JOYOF.92148.root@web02-winn.ispmail.private.ntl.com> References: <20100419150526.JOYOF.92148.root@web02-winn.ispmail.private.ntl.com> Message-ID: Can you provide more details about what you see in tcpdump and what your configuration of rsyslog is? Aaron On Mon, Apr 19, 2010 at 10:05 AM, wrote: > Hi Aaron, > I've ran tcpdump on the log store (not the client) and I can see the packets hitting the server, it seems to be rsyslog thats not picking them up. > > Using tcpdump and the first iptables config, gives the correct ip address when tcpdump is run on the log store, but no message is shown in the log files. > > Using tcpdump and the second iptables config, gives the ip address of firewall when tcpdump is run on the log store and the message appears in log file on disk. > > Hopefully that makes it a little more clear but apologies if I misunderstood the reply > > Thanks > Kris > ---- Aaron Wiebe wrote: >> Kris, ?it sounds as though your iptables rules aren't working very >> well for you. ?I suggest you set up wireshark or tcpdump on the log >> host machine and run the test again - I bet you would find that the >> traffic isn't making it. ?In the case that the IP isn't rewritten, >> that is expected. ?You're doing NAT, so rsyslog would have no other >> detail about the remote host you are originally delivering the data >> from. >> >> At this point I think most of your problems are iptables related, and >> not really rsyslog related. >> >> -Aaron >> >> On Mon, Apr 19, 2010 at 5:24 AM, ? wrote: >> > Hi All, >> > >> > I have a problem that I'm not sure how to get around. >> > >> > I have 3 machines, a client, a firewall and a log store. The firewall is Linux running iptables. The client and log store are on different networks (X.X.4.X) and (X.X.5.X). The firewall is used to bridge these networks. >> > >> > I've configured rsyslog on the client (.4.) to send messages to the log store (.5.) I've also configured a template on the log store to print the $fromhost-ip and original raw message and I'm printing everything (*.*) to the log files. >> > >> > When the firewall rewrites the source address (so they appear to be coming from the .5.x network), the messages get logged. If I leave the source address alone, the messages disappear. I know the packets are arriving at the log store with both configurations because I can see this with TCPDUMP on the log store. >> > >> > On the firewall I have the following configuration that I've put together. >> > >> > iptables -A POSTROUTING -t nat -o eth1 -j ACCEPT >> > iptables -A PREROUTING -t nat -i -p udp --dport 514 -j DNAT --to-destination X.X.5.X >> > >> > (On my actual config the Xs are not blanked out). >> > >> > Unfortunately with this rule in place I do not see anything in the log file. >> > >> > Changing the first line of the iptables config to >> > >> > iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE >> > >> > means that I can now see output getting to my log files but the ipaddress is incorrect. >> > >> > Is this a bug? or Is rsyslog doing some intelligent work under the hood to detect ip address spoofing? I'm using ubuntu server 9.10. Unfortunately using the hostname instead of the ipaddress in my case is not an option >> > >> > Hope someone can help >> > Kris >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > rsyslog mailing list >> > http://lists.adiscon.net/mailman/listinfo/rsyslog >> > http://www.rsyslog.com >> > >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > > From david at lang.hm Mon Apr 19 18:57:48 2010 From: david at lang.hm (david at lang.hm) Date: Mon, 19 Apr 2010 09:57:48 -0700 (PDT) Subject: [rsyslog] iptables and centralised logs with rsyslog and UDP In-Reply-To: <20100419150526.JOYOF.92148.root@web02-winn.ispmail.private.ntl.com> References: <20100419150526.JOYOF.92148.root@web02-winn.ispmail.private.ntl.com> Message-ID: do you have a route from the box running rsyslog to the source IP addresses that the logs are comeing from? if you don't then even though you see them in a tcpdump, your applications will not see the packets (there is a config option in linux to disable this feature) David Lang On Mon, 19 Apr 2010, kristian.jones at ntlworld.com wrote: > Date: Mon, 19 Apr 2010 15:05:26 +0100 > From: kristian.jones at ntlworld.com > Reply-To: rsyslog-users > To: rsyslog-users > Subject: Re: [rsyslog] iptables and centralised logs with rsyslog and UDP > > Hi Aaron, > I've ran tcpdump on the log store (not the client) and I can see the packets hitting the server, it seems to be rsyslog thats not picking them up. > > Using tcpdump and the first iptables config, gives the correct ip address when tcpdump is run on the log store, but no message is shown in the log files. > > Using tcpdump and the second iptables config, gives the ip address of firewall when tcpdump is run on the log store and the message appears in log file on disk. > > Hopefully that makes it a little more clear but apologies if I misunderstood the reply > > Thanks > Kris > ---- Aaron Wiebe wrote: >> Kris, it sounds as though your iptables rules aren't working very >> well for you. I suggest you set up wireshark or tcpdump on the log >> host machine and run the test again - I bet you would find that the >> traffic isn't making it. In the case that the IP isn't rewritten, >> that is expected. You're doing NAT, so rsyslog would have no other >> detail about the remote host you are originally delivering the data >> from. >> >> At this point I think most of your problems are iptables related, and >> not really rsyslog related. >> >> -Aaron >> >> On Mon, Apr 19, 2010 at 5:24 AM, wrote: >>> Hi All, >>> >>> I have a problem that I'm not sure how to get around. >>> >>> I have 3 machines, a client, a firewall and a log store. The firewall is Linux running iptables. The client and log store are on different networks (X.X.4.X) and (X.X.5.X). The firewall is used to bridge these networks. >>> >>> I've configured rsyslog on the client (.4.) to send messages to the log store (.5.) I've also configured a template on the log store to print the $fromhost-ip and original raw message and I'm printing everything (*.*) to the log files. >>> >>> When the firewall rewrites the source address (so they appear to be coming from the .5.x network), the messages get logged. If I leave the source address alone, the messages disappear. I know the packets are arriving at the log store with both configurations because I can see this with TCPDUMP on the log store. >>> >>> On the firewall I have the following configuration that I've put together. >>> >>> iptables -A POSTROUTING -t nat -o eth1 -j ACCEPT >>> iptables -A PREROUTING -t nat -i -p udp --dport 514 -j DNAT --to-destination X.X.5.X >>> >>> (On my actual config the Xs are not blanked out). >>> >>> Unfortunately with this rule in place I do not see anything in the log file. >>> >>> Changing the first line of the iptables config to >>> >>> iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE >>> >>> means that I can now see output getting to my log files but the ipaddress is incorrect. >>> >>> Is this a bug? or Is rsyslog doing some intelligent work under the hood to detect ip address spoofing? I'm using ubuntu server 9.10. Unfortunately using the hostname instead of the ipaddress in my case is not an option >>> >>> Hope someone can help >>> Kris >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From kristian.jones at ntlworld.com Tue Apr 20 10:03:20 2010 From: kristian.jones at ntlworld.com (kristian.jones at ntlworld.com) Date: Tue, 20 Apr 2010 9:03:20 +0100 Subject: [rsyslog] iptables and centralised logs with rsyslog and UDP In-Reply-To: Message-ID: <20100420090320.SUDNV.155925.root@web05-winn.ispmail.private.ntl.com> Thanks David, Adding the routes solved my issue. Kris ---- david at lang.hm wrote: > do you have a route from the box running rsyslog to the source IP > addresses that the logs are comeing from? if you don't then even though > you see them in a tcpdump, your applications will not see the packets > (there is a config option in linux to disable this feature) > > David Lang > > On Mon, 19 Apr > 2010, kristian.jones at ntlworld.com wrote: > > > Date: Mon, 19 Apr 2010 15:05:26 +0100 > > From: kristian.jones at ntlworld.com > > Reply-To: rsyslog-users > > To: rsyslog-users > > Subject: Re: [rsyslog] iptables and centralised logs with rsyslog and UDP > > > > Hi Aaron, > > I've ran tcpdump on the log store (not the client) and I can see the packets hitting the server, it seems to be rsyslog thats not picking them up. > > > > Using tcpdump and the first iptables config, gives the correct ip address when tcpdump is run on the log store, but no message is shown in the log files. > > > > Using tcpdump and the second iptables config, gives the ip address of firewall when tcpdump is run on the log store and the message appears in log file on disk. > > > > Hopefully that makes it a little more clear but apologies if I misunderstood the reply > > > > Thanks > > Kris > > ---- Aaron Wiebe wrote: > >> Kris, it sounds as though your iptables rules aren't working very > >> well for you. I suggest you set up wireshark or tcpdump on the log > >> host machine and run the test again - I bet you would find that the > >> traffic isn't making it. In the case that the IP isn't rewritten, > >> that is expected. You're doing NAT, so rsyslog would have no other > >> detail about the remote host you are originally delivering the data > >> from. > >> > >> At this point I think most of your problems are iptables related, and > >> not really rsyslog related. > >> > >> -Aaron > >> > >> On Mon, Apr 19, 2010 at 5:24 AM, wrote: > >>> Hi All, > >>> > >>> I have a problem that I'm not sure how to get around. > >>> > >>> I have 3 machines, a client, a firewall and a log store. The firewall is Linux running iptables. The client and log store are on different networks (X.X.4.X) and (X.X.5.X). The firewall is used to bridge these networks. > >>> > >>> I've configured rsyslog on the client (.4.) to send messages to the log store (.5.) I've also configured a template on the log store to print the $fromhost-ip and original raw message and I'm printing everything (*.*) to the log files. > >>> > >>> When the firewall rewrites the source address (so they appear to be coming from the .5.x network), the messages get logged. If I leave the source address alone, the messages disappear. I know the packets are arriving at the log store with both configurations because I can see this with TCPDUMP on the log store. > >>> > >>> On the firewall I have the following configuration that I've put together. > >>> > >>> iptables -A POSTROUTING -t nat -o eth1 -j ACCEPT > >>> iptables -A PREROUTING -t nat -i -p udp --dport 514 -j DNAT --to-destination X.X.5.X > >>> > >>> (On my actual config the Xs are not blanked out). > >>> > >>> Unfortunately with this rule in place I do not see anything in the log file. > >>> > >>> Changing the first line of the iptables config to > >>> > >>> iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE > >>> > >>> means that I can now see output getting to my log files but the ipaddress is incorrect. > >>> > >>> Is this a bug? or Is rsyslog doing some intelligent work under the hood to detect ip address spoofing? I'm using ubuntu server 9.10. Unfortunately using the hostname instead of the ipaddress in my case is not an option > >>> > >>> Hope someone can help > >>> Kris > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> rsyslog mailing list > >>> http://lists.adiscon.net/mailman/listinfo/rsyslog > >>> http://www.rsyslog.com > >>> > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From tom at ng23.net Tue Apr 20 11:47:48 2010 From: tom at ng23.net (Tom Brown) Date: Tue, 20 Apr 2010 10:47:48 +0100 Subject: [rsyslog] Configuration Help Message-ID: Hi - i posted this on the forum but i wonder of the maillist gets more traffic I am sending syslog data from a number of hosts to a central rsyslog box and everything is working but i have a basic configuration query. I currently log to /logs///*.log which is working fine but i am lacking a parameter in each log. The logs are appearing in the correct directory but my munging scripts rely on knowing what host each log comes from but as this is not appearing in the actual log then this makes things difficult. Does anyone have any pointers for achieving that, right now an example of a log would be # cat 20100419--authpriv.log pam_unix(su-l:session): session closed for user root pam_unix(sshd:session): session closed for user XXXXXX and ideally this would read # cat 20100419--authpriv.log pam_unix(su-l:session): session closed for user root pam_unix(sshd:session): session closed for user XXXXXX thanks From david at lang.hm Tue Apr 20 18:50:08 2010 From: david at lang.hm (david at lang.hm) Date: Tue, 20 Apr 2010 09:50:08 -0700 (PDT) Subject: [rsyslog] Configuration Help In-Reply-To: References: Message-ID: On Tue, 20 Apr 2010, Tom Brown wrote: > Hi - i posted this on the forum but i wonder of the maillist gets more > traffic > > > I am sending syslog data from a number of hosts to a central rsyslog box and > everything is working but i have a basic configuration query. > I currently log to /logs///*.log which is working fine but i > am lacking a parameter in each log. The logs are appearing in the > correct directory but my munging scripts rely on knowing what > host each log comes from but as this is not appearing in the actual log then > this makes things difficult. Does anyone have any pointers for achieving > that, right now an example of a log would be > > # cat 20100419--authpriv.log > pam_unix(su-l:session): session closed for user root > pam_unix(sshd:session): session closed for user XXXXXX > > and ideally this would read > > # cat 20100419--authpriv.log > pam_unix(su-l:session): session closed for user root > pam_unix(sshd:session): session closed for user XXXXXX what is your current configuration? it sounds like you need to change the format string to include the hostname. David Lang From tom at ng23.net Tue Apr 20 19:18:50 2010 From: tom at ng23.net (Tom Brown) Date: Tue, 20 Apr 2010 18:18:50 +0100 Subject: [rsyslog] Configuration Help In-Reply-To: References: Message-ID: > > what is your current configuration? > > it sounds like you need to change the format string to include the > hostname. > > thanks for the response - i did not setup this system so am not hugely familiar with it however would i need to be looking at the Log processing templates or the Output filename templates or neither? Currently we have something like # Log processing templates $template fmtStripLeadingSpace,"%msg:R,ERE,1,DFLT: (.*)--end%\n" # Output filename templates $template SystemLogFile,"/logs/syslog/%hostname%/%timereported:1:4:date-mysql%/%timereported:1:6:date-mysql%/%timereported:1:8:date-mysq l%/%timereported:1:8:date-mysql%-%hostname%-%syslogfacility-text%.log" any help is greatly appreciated thanks From david at lang.hm Tue Apr 20 19:35:40 2010 From: david at lang.hm (david at lang.hm) Date: Tue, 20 Apr 2010 10:35:40 -0700 (PDT) Subject: [rsyslog] Configuration Help In-Reply-To: References: Message-ID: On Tue, 20 Apr 2010, Tom Brown wrote: >> what is your current configuration? >> >> it sounds like you need to change the format string to include the >> hostname. >> >> > thanks for the response - i did not setup this system so am not hugely > familiar with it however would i need to be looking at the Log processing > templates or the Output filename templates or neither? it would be the log processing template > Currently we have something like > > > # Log processing templates > $template fmtStripLeadingSpace,"%msg:R,ERE,1,DFLT: (.*)--end%\n" try changing this to $template fmtStripLeadingSpace,"%hostname% %msg:R,ERE,1,DFLT: (.*)--end%\n" David Lang > > # Output filename templates > > $template > SystemLogFile,"/logs/syslog/%hostname%/%timereported:1:4:date-mysql%/%timereported:1:6:date-mysql%/%timereported:1:8:date-mysq > l%/%timereported:1:8:date-mysql%-%hostname%-%syslogfacility-text%.log" From tom at ng23.net Tue Apr 20 20:03:56 2010 From: tom at ng23.net (Tom Brown) Date: Tue, 20 Apr 2010 19:03:56 +0100 Subject: [rsyslog] Configuration Help In-Reply-To: References: Message-ID: > > # Log processing templates > > $template fmtStripLeadingSpace,"%msg:R,ERE,1,DFLT: (.*)--end%\n" > > try changing this to > > $template fmtStripLeadingSpace,"%hostname% %msg:R,ERE,1,DFLT: (.*)--end%\n" > many thanks - this resolved this issue From tbergfeld at hq.adiscon.com Thu Apr 22 15:57:52 2010 From: tbergfeld at hq.adiscon.com (Tom Bergfeld) Date: Thu, 22 Apr 2010 15:57:52 +0200 Subject: [rsyslog] rsyslog 4.7.1 (v4-devel) released Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CC8@GRFEXC.intern.adiscon.com> Hi all, We have just released rsyslog 4.7.1, a member of the v4-devel branch. This release improves the Solaris support. See Changelog for more details. ChangeLog: http://www.rsyslog.com/Article455.phtml Download: http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-201.phtml As always, feedback is appreciated. Best regards, Tom Bergfeld -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com From gbonser at seven.com Fri Apr 23 00:45:50 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 22 Apr 2010 15:45:50 -0700 Subject: [rsyslog] Large File Support Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE728B@RWC-EX1.corp.seven.com> I am having a strange issue. I am building rsyslog 4.6.2 on an amd64 system Configure says: rsyslog will be compiled with the following settings: Multithreading support enabled: yes Large file support enabled: yes But when I build it and do: /usr/src/rsyslog-4.6.2/tools> ./rsyslogd -v rsyslogd 4.6.2, compiled with: FEATURE_REGEXP: Yes FEATURE_LARGEFILE: No I also notice that configure reported: checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no Kernel 2.6.31 GCC 4.4.1 Libc6 2.10.1 I passed configure an explicit --enable-largefile Is there something else I must do in order to enable large file support? Thanks, George From david at lang.hm Fri Apr 23 02:45:15 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 22 Apr 2010 17:45:15 -0700 (PDT) Subject: [rsyslog] Large File Support In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE728B@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE08FE728B@RWC-EX1.corp.seven.com> Message-ID: On Thu, 22 Apr 2010, George Bonser wrote: > I am having a strange issue. I am building rsyslog 4.6.2 on an amd64 > system > > Configure says: > > rsyslog will be compiled with the following settings: > > Multithreading support enabled: yes > Large file support enabled: yes > > But when I build it and do: > > /usr/src/rsyslog-4.6.2/tools> ./rsyslogd -v > rsyslogd 4.6.2, compiled with: > FEATURE_REGEXP: Yes > FEATURE_LARGEFILE: No > > I also notice that configure reported: > > checking for special C compiler options needed for large files... no > checking for _FILE_OFFSET_BITS value needed for large files... no > > Kernel 2.6.31 > GCC 4.4.1 > Libc6 2.10.1 > > I passed configure an explicit --enable-largefile > > Is there something else I must do in order to enable large file support? 'large file support' is a work-around needed on 32 bit systems to handle files larger than 2G, on 64 bit systems it's just not needed. relax and enjoy your more advanced system ;-) David Lang From gbonser at seven.com Fri Apr 23 07:40:32 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 22 Apr 2010 22:40:32 -0700 Subject: [rsyslog] Large File Support References: <5A6D953473350C4B9995546AFE9939EE08FE728B@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE729A@RWC-EX1.corp.seven.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > > 'large file support' is a work-around needed on 32 bit systems to > handle > files larger than 2G, on 64 bit systems it's just not needed. > > relax and enjoy your more advanced system ;-) > > David Lang Hmm, ok, but when I build the Ubuntu 4.2.0 package, it does build it with such support and I can't see where any special parameter has been passed in order to do that. Just want to make sure I don't break anything trying to upgrade to 4.6.x From rgerhards at hq.adiscon.com Fri Apr 23 08:09:27 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 23 Apr 2010 08:09:27 +0200 Subject: [rsyslog] Large File Support References: <5A6D953473350C4B9995546AFE9939EE08FE728B@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE729A@RWC-EX1.corp.seven.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CCA@GRFEXC.intern.adiscon.com> > > 'large file support' is a work-around needed on 32 bit systems to > > handle > > files larger than 2G, on 64 bit systems it's just not needed. > > > > relax and enjoy your more advanced system ;-) > > > > David Lang > > Hmm, ok, but when I build the Ubuntu 4.2.0 package, it does build it > with such support and I can't see where any special parameter has been > passed in order to do that. > > Just want to make sure I don't break anything trying to upgrade to > 4.6.x You may be interested in this bug tracker, I guess a side-effect is what you see: http://bugzilla.adiscon.com/show_bug.cgi?id=182 Rainer From ralph at crongeyer.com Sat Apr 24 16:20:03 2010 From: ralph at crongeyer.com (Ralph Crongeyer) Date: Sat, 24 Apr 2010 10:20:03 -0400 Subject: [rsyslog] High cpu usage - rsyslog 5.4.0. In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103BBC@GRFEXC.intern.adiscon.com> References: <5fa6e0144d8003c7c72edff17f9f1675@webmail.crongeyer.com> <9B6E2A8877C38245BFB15CC491A11DA7103702@GRFEXC.intern.adiscon.com> <4BAF67C0.4000506@crongeyer.com> <4BAF710E.8080506@crongeyer.com><4BAF8773.1020000@crongeyer.com> <9B6E2A8877C38245BFB15CC491A11DA7103BAA@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103BBC@GRFEXC.intern.adiscon.com> Message-ID: <4BD2FE13.6030108@crongeyer.com> All, Sorry for the very long time for the response. I was on vaca in Mexico and had emergency surgery, I'm back now and ok. Did the fixes get merged into the 5.4.0 package? Or does it need more testing? Thanks, Ralph Rainer Gerhards wrote: > I managed to merge the v4 changes into v5-stable. Can you pull from it's git > head (git.adiscon.com/git/rsyslog.gig) and check if it works? Or do you need > a release tarball. > > Note that I need to finally fix an issue in v4 before (the released version > has an interim/work-around fix) before I can take up more work on v5, but > chances are not too bad that the issue is fixed. > > The master branch will receive the new patches ASAP, but that merge is a > little bit more complicated. > > Rainer > > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards >> Sent: Monday, March 29, 2010 7:11 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] High cpu usage - rsyslog 5.4.0. >> >> Hi, >> >> thanks for the information. I have crafted a big patch package for v4 >> the >> last two weeks. I will try to merge it in to v5 this week (I guess this >> will >> be a bit harder than usual). It may fix the issue. >> >> If you have a moment or two, it would be interesting to know if 5.5.2 >> has the >> same problem. >> >> Rainer >> >> >>> -----Original Message----- >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>> bounces at lists.adiscon.com] On Behalf Of Ralph Crongeyer >>> Sent: Sunday, March 28, 2010 6:45 PM >>> To: rsyslog-users >>> Subject: Re: [rsyslog] High cpu usage - rsyslog 5.4.0. >>> >>> It's confirmed! >>> >>> I've been running for over an hour and a half now and: >>> load average: 0.06, 0.06, 0.02 >>> >>> Looks good so far. >>> >>> Let me know if you guys (Michael, Rainer) want me to run in debug >>> >> mode >> >>> without the lines commented out to see if I can catch the problem for >>> more troubleshooting. >>> >>> Thanks, >>> Ralph >>> >>> Ralph Crongeyer wrote: >>> >>>> Ok, >>>> I stoped rsyslog apt-get removed the 5.3.7 package, installed the >>>> >>> 5.4.0 >>> >>>> package: >>>> >>>> root at logs:/opt# aptitude show rsyslog >>>> Package: rsyslog >>>> State: installed >>>> Automatically installed: no >>>> Version: 5.4.0-1 >>>> Priority: extra >>>> Section: extra >>>> Maintainer: ralph at crongeyer.com >>>> Uncompressed Size: 3047k >>>> Depends: libc6 (>= 2.7-1), zlib1g (>= 1:1.1.4), lsb-base (>= 3.2- >>>> >> 14) >> >>>> Description: enhanced multi-threaded syslogd >>>> >>>> commented out the lines from rsyslog.conf: >>>> #daemon.*;mail.*;\ >>>> # news.err;\ >>>> # *.=debug;*.=info;\ >>>> # *.=notice;*.=warn |/dev/xconsole >>>> >>>> >>>> and restarted rsyslog: >>>> root at logs:/opt# /etc/init.d/rsyslog restart >>>> Stopping enhanced syslogd: rsyslogd. >>>> Starting enhanced syslogd: rsyslogd. >>>> >>>> I'll get back to you in about an hour. >>>> >>>> Thanks, >>>> Ralph >>>> >>>> Michael Biebl wrote: >>>> >>>> >>>>> 2010/3/28 Ralph Crongeyer : >>>>> >>>>> >>>>> >>>>>> I'm running Debian Lenny on both machines. >>>>>> >>>>>> >>>>>> >>>>> >>>>>> Is anyone else seeing high cpu loads with 5.4.0? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I can confirm his (on Debian unstable) and already notified Rainer >>>>> about this particular issue. >>>>> Some preliminary testing here seems to indicate it's an issue with >>>>> >>> pipes. >>> >>>>> When I removed >>>>> daemon.*;mail.*;\ >>>>> news.err;\ >>>>> *.=debug;*.=info;\ >>>>> *.=notice;*.=warn |/dev/xconsole >>>>> >>>>> from my rsyslog.conf, I could no longer reproduce the problem. >>>>> >>>>> Would be interesting to know, if you can confirm this. >>>>> >>>>> Cheers, >>>>> Michael >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> -- >>> Reminds me of my expedition into the wilds of Afghanistan. We lost >>> >> our >> >>> corkscrew and were compelled to live on food and water for several >>> days. - >>> WC Fields >>> >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > -- Reminds me of my expedition into the wilds of Afghanistan. We lost our corkscrew and were compelled to live on food and water for several days. - WC Fields From gbonser at seven.com Sat Apr 24 20:19:31 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 24 Apr 2010 11:19:31 -0700 Subject: [rsyslog] Syslog over SCTP? Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE7309@RWC-EX1.corp.seven.com> Has anyone experimented with using SCTP for logging to a remote host? It seems it might have some advantages over TCP and UDP for that purpose. http://www.ibm.com/developerworks/linux/library/l-sctp/ From gbonser at seven.com Sun Apr 25 04:29:42 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 24 Apr 2010 19:29:42 -0700 Subject: [rsyslog] Syslog over SCTP? References: <5A6D953473350C4B9995546AFE9939EE08FE7309@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE7318@RWC-EX1.corp.seven.com> What I had in mind was something like an SCTP stream for each log level or each facility, haven't decided which would be most useful. That prevents head-of-line blocking as happens in TCP. So, for example, if a buffer is full of DEBUG level messages, an ALERT level message would go immediately as it is in a different stream. A separate stream could be added for RELP messages (or something like RELP or maybe an extension of it) and all of these streams would be within a single SCTP connection. Or maybe you can send RELP-like messages back across each stream in the opposite direction but having an "out of band" control channel sounds like an interesting idea and something fairly easy to do with SCTP. I would also think this lends itself well to threading of the different streams with a different thread handling different log levels (or facilities but I think dividing among log levels is probably easier). On an SMP system, a remote host sending a lot of DEGUG level messages while it is being tested would bog down one thread but other messages would be processed separately without network head-of-line blocking or CPU blocking (disk contention would be a different story, though ;) > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Saturday, April 24, 2010 11:20 AM > To: rsyslog-users > Subject: [rsyslog] Syslog over SCTP? > > Has anyone experimented with using SCTP for logging to a remote host? > It seems it might have some advantages over TCP and UDP for that > purpose. > > http://www.ibm.com/developerworks/linux/library/l-sctp/ > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Sun Apr 25 04:31:33 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 24 Apr 2010 19:31:33 -0700 Subject: [rsyslog] Syslog over SCTP? References: <5A6D953473350C4B9995546AFE9939EE08FE7309@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE7319@RWC-EX1.corp.seven.com> Oh, an interesting (to me) tutorial is here: http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb/sctp_intro. html > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Saturday, April 24, 2010 11:20 AM > To: rsyslog-users > Subject: [rsyslog] Syslog over SCTP? > > Has anyone experimented with using SCTP for logging to a remote host? > It seems it might have some advantages over TCP and UDP for that > purpose. > > http://www.ibm.com/developerworks/linux/library/l-sctp/ > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Mon Apr 26 02:23:37 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 25 Apr 2010 17:23:37 -0700 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com> Can't bind to TCP socket. The tcp module loads but I noticed that it only tries to bind the socket AFTER it has dropped is privs so it can not bind to a socket less than 1024. UDP bind works as that seems to bind immediately after module load while the prog is still running as root. If I set a tcp port >1024, it works. Could this be a race between two threads where a different thread is setting the UID/GID and a different one is binding the connections and the UID gets changed before the binding thread has a chance to get the socket? Modules being loaded: 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' 9572.648645873:7f07c0a216f0: loading module '/usr/lib/rsyslog/imudp.so' 9572.648713628:7f07c0a216f0: source file imudp.c requested reference for module 'lmnet', reference count now 4 9572.648734955:7f07c0a216f0: module of type 0 being loaded. 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports at *:514. 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' 9572.648869611:7f07c0a216f0: loading module '/usr/lib/rsyslog/imtcp.so' 9572.648938665:7f07c0a216f0: source file imtcp.c requested reference for module 'lmnet', reference count now 5 9572.648953892:7f07c0a216f0: caller requested object 'netstrm', not found (iRet -3003) 9572.648968610:7f07c0a216f0: Requested to load module 'lmnetstrms' 9572.648979310:7f07c0a216f0: loading module '/usr/lib/rsyslog/lmnetstrms.so' 9572.649053366:7f07c0a216f0: module of type 2 being loaded. 9572.649068131:7f07c0a216f0: source file imtcp.c requested reference for module 'lmnetstrms', reference count now 1 9572.649079163:7f07c0a216f0: caller requested object 'tcps_sess', not found (iRet -3003) 9572.649095086:7f07c0a216f0: Requested to load module 'lmtcpsrv' 9572.649105485:7f07c0a216f0: loading module '/usr/lib/rsyslog/lmtcpsrv.so' 9572.649188177:7f07c0a216f0: source file tcps_sess.c requested reference for module 'lmnetstrms', reference count now 2 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested reference for module 'lmnet', reference count now 6 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested reference for module 'lmnetstrms', reference count now 3 9572.649231362:7f07c0a216f0: module of type 2 being loaded. 9572.649241801:7f07c0a216f0: source file imtcp.c requested reference for module 'lmtcpsrv', reference count now 1 9572.649252009:7f07c0a216f0: source file imtcp.c requested reference for module 'lmtcpsrv', reference count now 2 9572.649287366:7f07c0a216f0: module of type 0 being loaded. 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' 9572.649321373:7f07c0a216f0: cfline: '$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat' 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction on' 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' 9572.649703828:7f07c0a216f0: uid 101 obtained for user 'syslog' 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' 9572.649840237:7f07c0a216f0: umask set to 0022. 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' 9572.649885709:7f07c0a216f0: uid 101 obtained for user 'syslog' 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup syslog' 9572.649934688:7f07c0a216f0: gid 103 obtained for group 'syslog' 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig /etc/rsyslog.d/*.conf' 9572.650017305:7f07c0a216f0: requested to include config file '/etc/rsyslog.d/50-default.conf' 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* /var/log/auth.log' GID and UID being changed: 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, lenBuf 78 9572.671902407:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg rsyslogd's groupid changed to 103 9572.671920644:7f07c0a216f0: Message has legacy syslog format. 9572.671933956:7f07be402910: testing filter, f_pmask 1 9572.671947526:7f07be402910: testing filter, f_pmask 240 9572.671957623:7f07be402910: Called action, logging to builtin-pipe 9572.671969801:7f07be402910: extend buf to at least 16, done 128 9572.671982061:7f07be402910: (/dev/xconsole) 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 entries 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised worker start 9572.672059720:7f07be402910: Action requested to be suspended, done that. 9572.672085037:7f07be402910: main Q: entry deleted, state 0, size now 1 entries 9572.672099142:7f07c0a216f0: setuid(101): 0 9572.672122289:7f07be402910: testing filter, f_pmask 0 9572.672136161:7f07be402910: testing filter, f_pmask 255 9572.672147659:7f07be402910: Called action, logging to builtin-file 9572.672162158:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg rsyslogd's userid changed to 101 9572.672179992:7f07c0a216f0: Message has legacy syslog format. 9572.672192329:7f07be402910: extend buf to at least 138, done 256 9572.672200766:7f07be402910: file to log to: /var/log/syslog UDP socket bind succeeded but TCP bind fails: 9572.672546363:7f07c0a216f0: initialization completed, transitioning to regular run mode 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket 4 (IPv4/port 514). 9572.672576606:7f07bc3fe910: --------imUDP calling select, active file descriptors (max 4): 4 9572.672594858:7f07bdc01910: --------imuxsock calling select, active file descriptors (max 5): 3 5 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy 9572.672646478:7f07bbbfd910: caller requested object 'nsd_ptcp', not found (iRet -3003) 9572.672663716:7f07bbbfd910: Requested to load module 'lmnsd_ptcp' 9572.672671184:7f07bbbfd910: loading module '/usr/lib/rsyslog/lmnsd_ptcp.so' 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested reference for module 'lmnetstrms', reference count now 4 9572.672757197:7f07bbbfd910: module of type 2 being loaded. 9572.672763826:7f07bbbfd910: source file netstrms.c requested reference for module 'lmnsd_ptcp', reference count now 1 9572.672770522:7f07bbbfd910: creating tcp listen socket on port 514 9572.672803781:7f07bbbfd910: error 13 while binding tcp socketWe could initialize 0 TCP listen sockets out of 1 we recei ved - this may or may not be an error indication. 9572.672824933:7f07bbbfd910: No TCP listen sockets could successfully be initializedCalled LogError, msg: Could not crea te tcp listener, ignoring port 514. 9572.672844597:7f07bbbfd910: logmsg: flags 1, from 'trebuchet', msg Could not create tcp listener, ignoring port 514. [t ry http://www.rsyslog.com/e/2077 ] From rgerhards at hq.adiscon.com Mon Apr 26 08:18:27 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Apr 2010 08:18:27 +0200 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com> The privilege drop code is still a hack. It needs proper engineering (as stated in the doc). So it could very well be a race in this regard. On the other hand, it does not look so. Could you send me complete debug logs to my private email address both with and without privilege drop inside your config. Maybe it is a simple thing, then I could fix it without the large effort really required. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Monday, April 26, 2010 2:24 AM > To: rsyslog-users > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > Can't bind to TCP socket. The tcp module loads but I noticed that it > only tries to bind the socket AFTER it has dropped is privs so it can > not bind to a socket less than 1024. UDP bind works as that seems to > bind immediately after module load while the prog is still running as > root. If I set a tcp port >1024, it works. Could this be a race > between > two threads where a different thread is setting the UID/GID and a > different one is binding the connections and the UID gets changed > before > the binding thread has a chance to get the socket? > > Modules being loaded: > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' > 9572.648645873:7f07c0a216f0: loading module '/usr/lib/rsyslog/imudp.so' > 9572.648713628:7f07c0a216f0: source file imudp.c requested reference > for > module 'lmnet', reference count now 4 > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports at *:514. > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' > 9572.648869611:7f07c0a216f0: loading module '/usr/lib/rsyslog/imtcp.so' > 9572.648938665:7f07c0a216f0: source file imtcp.c requested reference > for > module 'lmnet', reference count now 5 > 9572.648953892:7f07c0a216f0: caller requested object 'netstrm', not > found (iRet -3003) > 9572.648968610:7f07c0a216f0: Requested to load module 'lmnetstrms' > 9572.648979310:7f07c0a216f0: loading module > '/usr/lib/rsyslog/lmnetstrms.so' > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > 9572.649068131:7f07c0a216f0: source file imtcp.c requested reference > for > module 'lmnetstrms', reference count now 1 > 9572.649079163:7f07c0a216f0: caller requested object 'tcps_sess', not > found (iRet -3003) > 9572.649095086:7f07c0a216f0: Requested to load module 'lmtcpsrv' > 9572.649105485:7f07c0a216f0: loading module > '/usr/lib/rsyslog/lmtcpsrv.so' > 9572.649188177:7f07c0a216f0: source file tcps_sess.c requested > reference > for module 'lmnetstrms', reference count now 2 > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested reference > for module 'lmnet', reference count now 6 > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested reference > for module 'lmnetstrms', reference count now 3 > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > 9572.649241801:7f07c0a216f0: source file imtcp.c requested reference > for > module 'lmtcpsrv', reference count now 1 > 9572.649252009:7f07c0a216f0: source file imtcp.c requested reference > for > module 'lmtcpsrv', reference count now 2 > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' > 9572.649321373:7f07c0a216f0: cfline: '$ActionFileDefaultTemplate > RSYSLOG_TraditionalFileFormat' > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction on' > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > 9572.649703828:7f07c0a216f0: uid 101 obtained for user 'syslog' > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > 9572.649840237:7f07c0a216f0: umask set to 0022. > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' > 9572.649885709:7f07c0a216f0: uid 101 obtained for user 'syslog' > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup syslog' > 9572.649934688:7f07c0a216f0: gid 103 obtained for group 'syslog' > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > /etc/rsyslog.d/*.conf' > 9572.650017305:7f07c0a216f0: requested to include config file > '/etc/rsyslog.d/50-default.conf' > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > /var/log/auth.log' > > GID and UID being changed: > > 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, lenBuf 78 > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg > rsyslogd's groupid changed to 103 > 9572.671920644:7f07c0a216f0: Message has legacy syslog format. > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > 9572.671957623:7f07be402910: Called action, logging to builtin-pipe > 9572.671969801:7f07be402910: extend buf to at least 16, done 128 > 9572.671982061:7f07be402910: (/dev/xconsole) > 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 entries > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised worker start > 9572.672059720:7f07be402910: Action requested to be suspended, done > that. > 9572.672085037:7f07be402910: main Q: entry deleted, state 0, size now 1 > entries > 9572.672099142:7f07c0a216f0: setuid(101): 0 > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > 9572.672147659:7f07be402910: Called action, logging to builtin-file > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg > rsyslogd's userid changed to 101 > 9572.672179992:7f07c0a216f0: Message has legacy syslog format. > 9572.672192329:7f07be402910: extend buf to at least 138, done 256 > 9572.672200766:7f07be402910: file to log to: /var/log/syslog > > UDP socket bind succeeded but TCP bind fails: > > 9572.672546363:7f07c0a216f0: initialization completed, transitioning to > regular run mode > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket 4 > (IPv4/port 514). > 9572.672576606:7f07bc3fe910: --------imUDP calling select, active file > descriptors (max 4): 4 > 9572.672594858:7f07bdc01910: --------imuxsock calling select, active > file descriptors (max 5): 3 5 > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy > 9572.672646478:7f07bbbfd910: caller requested object 'nsd_ptcp', not > found (iRet -3003) > 9572.672663716:7f07bbbfd910: Requested to load module 'lmnsd_ptcp' > 9572.672671184:7f07bbbfd910: loading module > '/usr/lib/rsyslog/lmnsd_ptcp.so' > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested reference > for module 'lmnetstrms', reference count now 4 > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > 9572.672763826:7f07bbbfd910: source file netstrms.c requested reference > for module 'lmnsd_ptcp', reference count now 1 > 9572.672770522:7f07bbbfd910: creating tcp listen socket on port 514 > 9572.672803781:7f07bbbfd910: error 13 while binding tcp socketWe could > initialize 0 TCP listen sockets out of 1 we recei > ved - this may or may not be an error indication. > 9572.672824933:7f07bbbfd910: No TCP listen sockets could successfully > be > initializedCalled LogError, msg: Could not crea > te tcp listener, ignoring port 514. > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from 'trebuchet', msg > Could not create tcp listener, ignoring port 514. [t > ry http://www.rsyslog.com/e/2077 ] > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Apr 26 08:59:50 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Apr 2010 08:59:50 +0200 Subject: [rsyslog] Syslog over SCTP? References: <5A6D953473350C4B9995546AFE9939EE08FE7309@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE7318@RWC-EX1.corp.seven.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CDF@GRFEXC.intern.adiscon.com> This is interesting, but unfortunately I lack time to look deeper into it. I just wonder if another - maybe more flexible - approach would be to add a priority queue queueing mode. In that, we would enqueue messages based on priority and process higher priority messages before lower priority ones. That would work with all transports (and all other outout plugins) and solved the need you have. Am I right here? Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Sunday, April 25, 2010 4:30 AM > To: rsyslog-users > Subject: Re: [rsyslog] Syslog over SCTP? > > What I had in mind was something like an SCTP stream for each log level > or each facility, haven't decided which would be most useful. That > prevents head-of-line blocking as happens in TCP. So, for example, if > a > buffer is full of DEBUG level messages, an ALERT level message would go > immediately as it is in a different stream. A separate stream could be > added for RELP messages (or something like RELP or maybe an extension > of > it) and all of these streams would be within a single SCTP connection. > Or maybe you can send RELP-like messages back across each stream in the > opposite direction but having an "out of band" control channel sounds > like an interesting idea and something fairly easy to do with SCTP. > > I would also think this lends itself well to threading of the different > streams with a different thread handling different log levels (or > facilities but I think dividing among log levels is probably easier). > On an SMP system, a remote host sending a lot of DEGUG level messages > while it is being tested would bog down one thread but other messages > would be processed separately without network head-of-line blocking or > CPU blocking (disk contention would be a different story, though ;) > > > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > Sent: Saturday, April 24, 2010 11:20 AM > > To: rsyslog-users > > Subject: [rsyslog] Syslog over SCTP? > > > > Has anyone experimented with using SCTP for logging to a remote host? > > It seems it might have some advantages over TCP and UDP for that > > purpose. > > > > http://www.ibm.com/developerworks/linux/library/l-sctp/ > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Mon Apr 26 09:44:20 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 26 Apr 2010 00:44:20 -0700 Subject: [rsyslog] Syslog over SCTP? References: <5A6D953473350C4B9995546AFE9939EE08FE7309@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE08FE7318@RWC-EX1.corp.seven.com> <9B6E2A8877C38245BFB15CC491A11DA7103CDF@GRFEXC.intern.adiscon.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE732B@RWC-EX1.corp.seven.com> Well, it isn't really prioritization that I am worried about. For example, if I have a developer running something in DEBUG, that is actually quite high priority for him. With TCP, there is no way to separate them at the system OS tcp buffer level without opening several concurrent TCP connections, basically one connection for each ActionQueue. TCP has only one output buffer per connection while SCTP can have several parallel streams operating over a single socket connection. Maybe I will hack on it when I get time. If I have sent a bunch of DEBUG level messages, they are in the TCP/IP output buffer. If I want to send a USER level message, it gets put in the queue after the DEBUG messages I have already "sent". With SCTP, the streams are handled in round-robin fashion. If the packet is flagged for "out of order delivery", one could potentially send a higher priority packet NOW despite a lot of lower priority messages being sent. The problem with prioritization is that higher priority traffic can starve "lower" priority traffic of service. You can already easily accomplish the prioritization with the exsting Linux ToS bits. By default Linux has four classes of traffic with the pfifo_fast qdisc. If you mark the packets accordingly, you can already get higher priority service for certain traffic (marking ToS 0 for EMERGENCY, for example). The problem with that is a program spewing a bunch of USER messages can block DEBUG messages if USER is placed at a higher priority. What I had in mind was basically a separate worker thread for each log level. This prevents any of them blocking the others. George > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Monday, April 26, 2010 12:00 AM > To: rsyslog-users > Subject: Re: [rsyslog] Syslog over SCTP? > > This is interesting, but unfortunately I lack time to look deeper into > it. > > I just wonder if another - maybe more flexible - approach would be to > add a > priority queue queueing mode. In that, we would enqueue messages based > on > priority and process higher priority messages before lower priority > ones. > That would work with all transports (and all other outout plugins) and > solved > the need you have. > > Am I right here? > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > Sent: Sunday, April 25, 2010 4:30 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Syslog over SCTP? > > > > What I had in mind was something like an SCTP stream for each log > level > > or each facility, haven't decided which would be most useful. That > > prevents head-of-line blocking as happens in TCP. So, for example, > if > > a > > buffer is full of DEBUG level messages, an ALERT level message would > go > > immediately as it is in a different stream. A separate stream could > be > > added for RELP messages (or something like RELP or maybe an extension > > of > > it) and all of these streams would be within a single SCTP > connection. > > Or maybe you can send RELP-like messages back across each stream in > the > > opposite direction but having an "out of band" control channel sounds > > like an interesting idea and something fairly easy to do with SCTP. > > > > I would also think this lends itself well to threading of the > different > > streams with a different thread handling different log levels (or > > facilities but I think dividing among log levels is probably easier). > > On an SMP system, a remote host sending a lot of DEGUG level messages > > while it is being tested would bog down one thread but other messages > > would be processed separately without network head-of-line blocking > or > > CPU blocking (disk contention would be a different story, though ;) > > > > > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > Sent: Saturday, April 24, 2010 11:20 AM > > > To: rsyslog-users > > > Subject: [rsyslog] Syslog over SCTP? > > > > > > Has anyone experimented with using SCTP for logging to a remote > host? > > > It seems it might have some advantages over TCP and UDP for that > > > purpose. > > > > > > http://www.ibm.com/developerworks/linux/library/l-sctp/ > > > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Mon Apr 26 10:09:45 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 26 Apr 2010 01:09:45 -0700 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com> <9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com> Oops, sorry, I did not mean to send that attachment to the list. > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Sunday, April 25, 2010 11:18 PM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > The privilege drop code is still a hack. It needs proper engineering > (as > stated in the doc). So it could very well be a race in this regard. On > the > other hand, it does not look so. Could you send me complete debug logs > to my > private email address both with and without privilege drop inside your > config. Maybe it is a simple thing, then I could fix it without the > large > effort really required. > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > Sent: Monday, April 26, 2010 2:24 AM > > To: rsyslog-users > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > > > Can't bind to TCP socket. The tcp module loads but I noticed that it > > only tries to bind the socket AFTER it has dropped is privs so it can > > not bind to a socket less than 1024. UDP bind works as that seems to > > bind immediately after module load while the prog is still running as > > root. If I set a tcp port >1024, it works. Could this be a race > > between > > two threads where a different thread is setting the UID/GID and a > > different one is binding the connections and the UID gets changed > > before > > the binding thread has a chance to get the socket? > > > > Modules being loaded: > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' > > 9572.648645873:7f07c0a216f0: loading module > '/usr/lib/rsyslog/imudp.so' > > 9572.648713628:7f07c0a216f0: source file imudp.c requested reference > > for > > module 'lmnet', reference count now 4 > > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports at > *:514. > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' > > 9572.648869611:7f07c0a216f0: loading module > '/usr/lib/rsyslog/imtcp.so' > > 9572.648938665:7f07c0a216f0: source file imtcp.c requested reference > > for > > module 'lmnet', reference count now 5 > > 9572.648953892:7f07c0a216f0: caller requested object 'netstrm', not > > found (iRet -3003) > > 9572.648968610:7f07c0a216f0: Requested to load module 'lmnetstrms' > > 9572.648979310:7f07c0a216f0: loading module > > '/usr/lib/rsyslog/lmnetstrms.so' > > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > > 9572.649068131:7f07c0a216f0: source file imtcp.c requested reference > > for > > module 'lmnetstrms', reference count now 1 > > 9572.649079163:7f07c0a216f0: caller requested object 'tcps_sess', not > > found (iRet -3003) > > 9572.649095086:7f07c0a216f0: Requested to load module 'lmtcpsrv' > > 9572.649105485:7f07c0a216f0: loading module > > '/usr/lib/rsyslog/lmtcpsrv.so' > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c requested > > reference > > for module 'lmnetstrms', reference count now 2 > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested reference > > for module 'lmnet', reference count now 6 > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested reference > > for module 'lmnetstrms', reference count now 3 > > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > > 9572.649241801:7f07c0a216f0: source file imtcp.c requested reference > > for > > module 'lmtcpsrv', reference count now 1 > > 9572.649252009:7f07c0a216f0: source file imtcp.c requested reference > > for > > module 'lmtcpsrv', reference count now 2 > > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' > > 9572.649321373:7f07c0a216f0: cfline: '$ActionFileDefaultTemplate > > RSYSLOG_TraditionalFileFormat' > > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction on' > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user 'syslog' > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user 'syslog' > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup syslog' > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group 'syslog' > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > /etc/rsyslog.d/*.conf' > > 9572.650017305:7f07c0a216f0: requested to include config file > > '/etc/rsyslog.d/50-default.conf' > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > /var/log/auth.log' > > > > GID and UID being changed: > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, lenBuf > 78 > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg > > rsyslogd's groupid changed to 103 > > 9572.671920644:7f07c0a216f0: Message has legacy syslog format. > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > 9572.671957623:7f07be402910: Called action, logging to builtin-pipe > > 9572.671969801:7f07be402910: extend buf to at least 16, done 128 > > 9572.671982061:7f07be402910: (/dev/xconsole) > > 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 entries > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised worker start > > 9572.672059720:7f07be402910: Action requested to be suspended, done > > that. > > 9572.672085037:7f07be402910: main Q: entry deleted, state 0, size now > 1 > > entries > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > 9572.672147659:7f07be402910: Called action, logging to builtin-file > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg > > rsyslogd's userid changed to 101 > > 9572.672179992:7f07c0a216f0: Message has legacy syslog format. > > 9572.672192329:7f07be402910: extend buf to at least 138, done 256 > > 9572.672200766:7f07be402910: file to log to: /var/log/syslog > > > > UDP socket bind succeeded but TCP bind fails: > > > > 9572.672546363:7f07c0a216f0: initialization completed, transitioning > to > > regular run mode > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket 4 > > (IPv4/port 514). > > 9572.672576606:7f07bc3fe910: --------imUDP calling select, active > file > > descriptors (max 4): 4 > > 9572.672594858:7f07bdc01910: --------imuxsock calling select, active > > file descriptors (max 5): 3 5 > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy > > 9572.672646478:7f07bbbfd910: caller requested object 'nsd_ptcp', not > > found (iRet -3003) > > 9572.672663716:7f07bbbfd910: Requested to load module 'lmnsd_ptcp' > > 9572.672671184:7f07bbbfd910: loading module > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested > reference > > for module 'lmnetstrms', reference count now 4 > > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > > 9572.672763826:7f07bbbfd910: source file netstrms.c requested > reference > > for module 'lmnsd_ptcp', reference count now 1 > > 9572.672770522:7f07bbbfd910: creating tcp listen socket on port 514 > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp socketWe > could > > initialize 0 TCP listen sockets out of 1 we recei > > ved - this may or may not be an error indication. > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could successfully > > be > > initializedCalled LogError, msg: Could not crea > > te tcp listener, ignoring port 514. > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from 'trebuchet', msg > > Could not create tcp listener, ignoring port 514. [t > > ry http://www.rsyslog.com/e/2077 ] > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Apr 26 10:37:13 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Apr 2010 10:37:13 +0200 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com> <5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com> No problem -- the mailing list processor held it due to size constrainst (and I rejected it now). The size restriction was actually the prime issue why I requested it to go to my private mail. So: nothing bad has happened ;) I'll try to look at the log asap and let you know what I find. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Monday, April 26, 2010 10:10 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > Oops, sorry, I did not mean to send that attachment to the list. > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > Sent: Sunday, April 25, 2010 11:18 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > non-root. > > > > The privilege drop code is still a hack. It needs proper engineering > > (as > > stated in the doc). So it could very well be a race in this regard. > On > > the > > other hand, it does not look so. Could you send me complete debug > logs > > to my > > private email address both with and without privilege drop inside > your > > config. Maybe it is a simple thing, then I could fix it without the > > large > > effort really required. > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > Sent: Monday, April 26, 2010 2:24 AM > > > To: rsyslog-users > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > > > > > Can't bind to TCP socket. The tcp module loads but I noticed that > it > > > only tries to bind the socket AFTER it has dropped is privs so it > can > > > not bind to a socket less than 1024. UDP bind works as that seems > to > > > bind immediately after module load while the prog is still running > as > > > root. If I set a tcp port >1024, it works. Could this be a race > > > between > > > two threads where a different thread is setting the UID/GID and a > > > different one is binding the connections and the UID gets changed > > > before > > > the binding thread has a chance to get the socket? > > > > > > Modules being loaded: > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' > > > 9572.648645873:7f07c0a216f0: loading module > > '/usr/lib/rsyslog/imudp.so' > > > 9572.648713628:7f07c0a216f0: source file imudp.c requested > reference > > > for > > > module 'lmnet', reference count now 4 > > > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports at > > *:514. > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' > > > 9572.648869611:7f07c0a216f0: loading module > > '/usr/lib/rsyslog/imtcp.so' > > > 9572.648938665:7f07c0a216f0: source file imtcp.c requested > reference > > > for > > > module 'lmnet', reference count now 5 > > > 9572.648953892:7f07c0a216f0: caller requested object 'netstrm', not > > > found (iRet -3003) > > > 9572.648968610:7f07c0a216f0: Requested to load module 'lmnetstrms' > > > 9572.648979310:7f07c0a216f0: loading module > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > > > 9572.649068131:7f07c0a216f0: source file imtcp.c requested > reference > > > for > > > module 'lmnetstrms', reference count now 1 > > > 9572.649079163:7f07c0a216f0: caller requested object 'tcps_sess', > not > > > found (iRet -3003) > > > 9572.649095086:7f07c0a216f0: Requested to load module 'lmtcpsrv' > > > 9572.649105485:7f07c0a216f0: loading module > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c requested > > > reference > > > for module 'lmnetstrms', reference count now 2 > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested > reference > > > for module 'lmnet', reference count now 6 > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested > reference > > > for module 'lmnetstrms', reference count now 3 > > > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > > > 9572.649241801:7f07c0a216f0: source file imtcp.c requested > reference > > > for > > > module 'lmtcpsrv', reference count now 1 > > > 9572.649252009:7f07c0a216f0: source file imtcp.c requested > reference > > > for > > > module 'lmtcpsrv', reference count now 2 > > > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' > > > 9572.649321373:7f07c0a216f0: cfline: '$ActionFileDefaultTemplate > > > RSYSLOG_TraditionalFileFormat' > > > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction on' > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user 'syslog' > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user 'syslog' > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup syslog' > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group 'syslog' > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > /etc/rsyslog.d/*.conf' > > > 9572.650017305:7f07c0a216f0: requested to include config file > > > '/etc/rsyslog.d/50-default.conf' > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > /var/log/auth.log' > > > > > > GID and UID being changed: > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, > lenBuf > > 78 > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg > > > rsyslogd's groupid changed to 103 > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog format. > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > > 9572.671957623:7f07be402910: Called action, logging to builtin-pipe > > > 9572.671969801:7f07be402910: extend buf to at least 16, done 128 > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 > entries > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised worker > start > > > 9572.672059720:7f07be402910: Action requested to be suspended, done > > > that. > > > 9572.672085037:7f07be402910: main Q: entry deleted, state 0, size > now > > 1 > > > entries > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > > 9572.672147659:7f07be402910: Called action, logging to builtin-file > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg > > > rsyslogd's userid changed to 101 > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog format. > > > 9572.672192329:7f07be402910: extend buf to at least 138, done 256 > > > 9572.672200766:7f07be402910: file to log to: /var/log/syslog > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > transitioning > > to > > > regular run mode > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket 4 > > > (IPv4/port 514). > > > 9572.672576606:7f07bc3fe910: --------imUDP calling select, active > > file > > > descriptors (max 4): 4 > > > 9572.672594858:7f07bdc01910: --------imuxsock calling select, > active > > > file descriptors (max 5): 3 5 > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy > > > 9572.672646478:7f07bbbfd910: caller requested object 'nsd_ptcp', > not > > > found (iRet -3003) > > > 9572.672663716:7f07bbbfd910: Requested to load module 'lmnsd_ptcp' > > > 9572.672671184:7f07bbbfd910: loading module > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested > > reference > > > for module 'lmnetstrms', reference count now 4 > > > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > > > 9572.672763826:7f07bbbfd910: source file netstrms.c requested > > reference > > > for module 'lmnsd_ptcp', reference count now 1 > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket on port 514 > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp socketWe > > could > > > initialize 0 TCP listen sockets out of 1 we recei > > > ved - this may or may not be an error indication. > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could > successfully > > > be > > > initializedCalled LogError, msg: Could not crea > > > te tcp listener, ignoring port 514. > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from 'trebuchet', msg > > > Could not create tcp listener, ignoring port 514. [t > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Mon Apr 26 10:51:57 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 26 Apr 2010 01:51:57 -0700 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com> <9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE7330@RWC-EX1.corp.seven.com> I think the problem is that it spawns a new thread to load the udp and tcp modules and that should be done by the main thread so that it gets done in sequence before the privs are processed. > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Monday, April 26, 2010 1:37 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > No problem -- the mailing list processor held it due to size > constrainst (and > I rejected it now). The size restriction was actually the prime issue > why I > requested it to go to my private mail. So: nothing bad has happened ;) > > I'll try to look at the log asap and let you know what I find. > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > Sent: Monday, April 26, 2010 10:10 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > root. > > > > Oops, sorry, I did not mean to send that attachment to the list. > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > Sent: Sunday, April 25, 2010 11:18 PM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > non-root. > > > > > > The privilege drop code is still a hack. It needs proper > engineering > > > (as > > > stated in the doc). So it could very well be a race in this regard. > > On > > > the > > > other hand, it does not look so. Could you send me complete debug > > logs > > > to my > > > private email address both with and without privilege drop inside > > your > > > config. Maybe it is a simple thing, then I could fix it without the > > > large > > > effort really required. > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > Sent: Monday, April 26, 2010 2:24 AM > > > > To: rsyslog-users > > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > root. > > > > > > > > Can't bind to TCP socket. The tcp module loads but I noticed > that > > it > > > > only tries to bind the socket AFTER it has dropped is privs so it > > can > > > > not bind to a socket less than 1024. UDP bind works as that > seems > > to > > > > bind immediately after module load while the prog is still > running > > as > > > > root. If I set a tcp port >1024, it works. Could this be a race > > > > between > > > > two threads where a different thread is setting the UID/GID and a > > > > different one is binding the connections and the UID gets changed > > > > before > > > > the binding thread has a chance to get the socket? > > > > > > > > Modules being loaded: > > > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > > 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' > > > > 9572.648645873:7f07c0a216f0: loading module > > > '/usr/lib/rsyslog/imudp.so' > > > > 9572.648713628:7f07c0a216f0: source file imudp.c requested > > reference > > > > for > > > > module 'lmnet', reference count now 4 > > > > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports at > > > *:514. > > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > > 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' > > > > 9572.648869611:7f07c0a216f0: loading module > > > '/usr/lib/rsyslog/imtcp.so' > > > > 9572.648938665:7f07c0a216f0: source file imtcp.c requested > > reference > > > > for > > > > module 'lmnet', reference count now 5 > > > > 9572.648953892:7f07c0a216f0: caller requested object 'netstrm', > not > > > > found (iRet -3003) > > > > 9572.648968610:7f07c0a216f0: Requested to load module > 'lmnetstrms' > > > > 9572.648979310:7f07c0a216f0: loading module > > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > > > > 9572.649068131:7f07c0a216f0: source file imtcp.c requested > > reference > > > > for > > > > module 'lmnetstrms', reference count now 1 > > > > 9572.649079163:7f07c0a216f0: caller requested object 'tcps_sess', > > not > > > > found (iRet -3003) > > > > 9572.649095086:7f07c0a216f0: Requested to load module 'lmtcpsrv' > > > > 9572.649105485:7f07c0a216f0: loading module > > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c requested > > > > reference > > > > for module 'lmnetstrms', reference count now 2 > > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested > > reference > > > > for module 'lmnet', reference count now 6 > > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested > > reference > > > > for module 'lmnetstrms', reference count now 3 > > > > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > > > > 9572.649241801:7f07c0a216f0: source file imtcp.c requested > > reference > > > > for > > > > module 'lmtcpsrv', reference count now 1 > > > > 9572.649252009:7f07c0a216f0: source file imtcp.c requested > > reference > > > > for > > > > module 'lmtcpsrv', reference count now 2 > > > > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > > > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' > > > > 9572.649321373:7f07c0a216f0: cfline: '$ActionFileDefaultTemplate > > > > RSYSLOG_TraditionalFileFormat' > > > > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction on' > > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user 'syslog' > > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' > > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user 'syslog' > > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup syslog' > > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group 'syslog' > > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > > /etc/rsyslog.d/*.conf' > > > > 9572.650017305:7f07c0a216f0: requested to include config file > > > > '/etc/rsyslog.d/50-default.conf' > > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > > /var/log/auth.log' > > > > > > > > GID and UID being changed: > > > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, > > lenBuf > > > 78 > > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', > msg > > > > rsyslogd's groupid changed to 103 > > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog format. > > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > > > 9572.671957623:7f07be402910: Called action, logging to builtin- > pipe > > > > 9572.671969801:7f07be402910: extend buf to at least 16, done 128 > > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 > > entries > > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy > > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised worker > > start > > > > 9572.672059720:7f07be402910: Action requested to be suspended, > done > > > > that. > > > > 9572.672085037:7f07be402910: main Q: entry deleted, state 0, size > > now > > > 1 > > > > entries > > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > > > 9572.672147659:7f07be402910: Called action, logging to builtin- > file > > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', > msg > > > > rsyslogd's userid changed to 101 > > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog format. > > > > 9572.672192329:7f07be402910: extend buf to at least 138, done 256 > > > > 9572.672200766:7f07be402910: file to log to: /var/log/syslog > > > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > > transitioning > > > to > > > > regular run mode > > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket 4 > > > > (IPv4/port 514). > > > > 9572.672576606:7f07bc3fe910: --------imUDP calling select, active > > > file > > > > descriptors (max 4): 4 > > > > 9572.672594858:7f07bdc01910: --------imuxsock calling select, > > active > > > > file descriptors (max 5): 3 5 > > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy > > > > 9572.672646478:7f07bbbfd910: caller requested object 'nsd_ptcp', > > not > > > > found (iRet -3003) > > > > 9572.672663716:7f07bbbfd910: Requested to load module > 'lmnsd_ptcp' > > > > 9572.672671184:7f07bbbfd910: loading module > > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested > > > reference > > > > for module 'lmnetstrms', reference count now 4 > > > > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > > > > 9572.672763826:7f07bbbfd910: source file netstrms.c requested > > > reference > > > > for module 'lmnsd_ptcp', reference count now 1 > > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket on port > 514 > > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp socketWe > > > could > > > > initialize 0 TCP listen sockets out of 1 we recei > > > > ved - this may or may not be an error indication. > > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could > > successfully > > > > be > > > > initializedCalled LogError, msg: Could not crea > > > > te tcp listener, ignoring port 514. > > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from 'trebuchet', > msg > > > > Could not create tcp listener, ignoring port 514. [t > > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Apr 26 11:32:03 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Apr 2010 11:32:03 +0200 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com> <5A6D953473350C4B9995546AFE9939EE08FE7330@RWC-EX1.corp.seven.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CE3@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Monday, April 26, 2010 10:52 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > I think the problem is that it spawns a new thread to load the udp and > tcp modules and that should be done by the main thread so that it gets > done in sequence before the privs are processed. I think your analysis is right, this is where the race happens. However, the cure is far from being as simple as it sounds: you are actually recommending a full redesign of the input plugin interface. It would also have other implications, including a potential unacceptable startup delay. This is what I quoted with "a lot of work to do". So, unfortunately, it does not look like something I can fix quickly. Let me once again reiterate that the priv drop code is far from being a complete solution. I added the current code when I saw that it was easy to do and useful for some situations. We once had someone who was interested in sponsoring a complete implementation, but that did unfortunately not materialize. As I am currently short on time due to other work to do, I do not find sufficient time to look at this. It is far from being a trivial task, even though I hope to be able to do it without a full redesign. I still think it is 2+ weeks worth of work. Rainer > > > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > Sent: Monday, April 26, 2010 1:37 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > non-root. > > > > No problem -- the mailing list processor held it due to size > > constrainst (and > > I rejected it now). The size restriction was actually the prime issue > > why I > > requested it to go to my private mail. So: nothing bad has happened > ;) > > > > I'll try to look at the log asap and let you know what I find. > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > Sent: Monday, April 26, 2010 10:10 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > > root. > > > > > > Oops, sorry, I did not mean to send that attachment to the list. > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > Sent: Sunday, April 25, 2010 11:18 PM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > non-root. > > > > > > > > The privilege drop code is still a hack. It needs proper > > engineering > > > > (as > > > > stated in the doc). So it could very well be a race in this > regard. > > > On > > > > the > > > > other hand, it does not look so. Could you send me complete debug > > > logs > > > > to my > > > > private email address both with and without privilege drop inside > > > your > > > > config. Maybe it is a simple thing, then I could fix it without > the > > > > large > > > > effort really required. > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > Sent: Monday, April 26, 2010 2:24 AM > > > > > To: rsyslog-users > > > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > > root. > > > > > > > > > > Can't bind to TCP socket. The tcp module loads but I noticed > > that > > > it > > > > > only tries to bind the socket AFTER it has dropped is privs so > it > > > can > > > > > not bind to a socket less than 1024. UDP bind works as that > > seems > > > to > > > > > bind immediately after module load while the prog is still > > running > > > as > > > > > root. If I set a tcp port >1024, it works. Could this be a > race > > > > > between > > > > > two threads where a different thread is setting the UID/GID and > a > > > > > different one is binding the connections and the UID gets > changed > > > > > before > > > > > the binding thread has a chance to get the socket? > > > > > > > > > > Modules being loaded: > > > > > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > > > 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' > > > > > 9572.648645873:7f07c0a216f0: loading module > > > > '/usr/lib/rsyslog/imudp.so' > > > > > 9572.648713628:7f07c0a216f0: source file imudp.c requested > > > reference > > > > > for > > > > > module 'lmnet', reference count now 4 > > > > > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > > > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports at > > > > *:514. > > > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > > > 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' > > > > > 9572.648869611:7f07c0a216f0: loading module > > > > '/usr/lib/rsyslog/imtcp.so' > > > > > 9572.648938665:7f07c0a216f0: source file imtcp.c requested > > > reference > > > > > for > > > > > module 'lmnet', reference count now 5 > > > > > 9572.648953892:7f07c0a216f0: caller requested object 'netstrm', > > not > > > > > found (iRet -3003) > > > > > 9572.648968610:7f07c0a216f0: Requested to load module > > 'lmnetstrms' > > > > > 9572.648979310:7f07c0a216f0: loading module > > > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > > > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > > > > > 9572.649068131:7f07c0a216f0: source file imtcp.c requested > > > reference > > > > > for > > > > > module 'lmnetstrms', reference count now 1 > > > > > 9572.649079163:7f07c0a216f0: caller requested object > 'tcps_sess', > > > not > > > > > found (iRet -3003) > > > > > 9572.649095086:7f07c0a216f0: Requested to load module > 'lmtcpsrv' > > > > > 9572.649105485:7f07c0a216f0: loading module > > > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c requested > > > > > reference > > > > > for module 'lmnetstrms', reference count now 2 > > > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested > > > reference > > > > > for module 'lmnet', reference count now 6 > > > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested > > > reference > > > > > for module 'lmnetstrms', reference count now 3 > > > > > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > > > > > 9572.649241801:7f07c0a216f0: source file imtcp.c requested > > > reference > > > > > for > > > > > module 'lmtcpsrv', reference count now 1 > > > > > 9572.649252009:7f07c0a216f0: source file imtcp.c requested > > > reference > > > > > for > > > > > module 'lmtcpsrv', reference count now 2 > > > > > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > > > > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' > > > > > 9572.649321373:7f07c0a216f0: cfline: > '$ActionFileDefaultTemplate > > > > > RSYSLOG_TraditionalFileFormat' > > > > > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction on' > > > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user 'syslog' > > > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > > > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > > > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > > > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' > > > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user 'syslog' > > > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup syslog' > > > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group > 'syslog' > > > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > > > /etc/rsyslog.d/*.conf' > > > > > 9572.650017305:7f07c0a216f0: requested to include config file > > > > > '/etc/rsyslog.d/50-default.conf' > > > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > > > /var/log/auth.log' > > > > > > > > > > GID and UID being changed: > > > > > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, > > > lenBuf > > > > 78 > > > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', > > msg > > > > > rsyslogd's groupid changed to 103 > > > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog format. > > > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > > > > 9572.671957623:7f07be402910: Called action, logging to builtin- > > pipe > > > > > 9572.671969801:7f07be402910: extend buf to at least 16, done > 128 > > > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 > > > entries > > > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy > > > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised worker > > > start > > > > > 9572.672059720:7f07be402910: Action requested to be suspended, > > done > > > > > that. > > > > > 9572.672085037:7f07be402910: main Q: entry deleted, state 0, > size > > > now > > > > 1 > > > > > entries > > > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > > > > 9572.672147659:7f07be402910: Called action, logging to builtin- > > file > > > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', > > msg > > > > > rsyslogd's userid changed to 101 > > > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog format. > > > > > 9572.672192329:7f07be402910: extend buf to at least 138, done > 256 > > > > > 9572.672200766:7f07be402910: file to log to: /var/log/syslog > > > > > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > > > transitioning > > > > to > > > > > regular run mode > > > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket 4 > > > > > (IPv4/port 514). > > > > > 9572.672576606:7f07bc3fe910: --------imUDP calling select, > active > > > > file > > > > > descriptors (max 4): 4 > > > > > 9572.672594858:7f07bdc01910: --------imuxsock calling select, > > > active > > > > > file descriptors (max 5): 3 5 > > > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy > > > > > 9572.672646478:7f07bbbfd910: caller requested object > 'nsd_ptcp', > > > not > > > > > found (iRet -3003) > > > > > 9572.672663716:7f07bbbfd910: Requested to load module > > 'lmnsd_ptcp' > > > > > 9572.672671184:7f07bbbfd910: loading module > > > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested > > > > reference > > > > > for module 'lmnetstrms', reference count now 4 > > > > > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > > > > > 9572.672763826:7f07bbbfd910: source file netstrms.c requested > > > > reference > > > > > for module 'lmnsd_ptcp', reference count now 1 > > > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket on port > > 514 > > > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp > socketWe > > > > could > > > > > initialize 0 TCP listen sockets out of 1 we recei > > > > > ved - this may or may not be an error indication. > > > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could > > > successfully > > > > > be > > > > > initializedCalled LogError, msg: Could not crea > > > > > te tcp listener, ignoring port 514. > > > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from 'trebuchet', > > msg > > > > > Could not create tcp listener, ignoring port 514. [t > > > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Mon Apr 26 11:44:12 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 26 Apr 2010 02:44:12 -0700 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE7330@RWC-EX1.corp.seven.com> <9B6E2A8877C38245BFB15CC491A11DA7103CE3@GRFEXC.intern.adiscon.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE7331@RWC-EX1.corp.seven.com> Maybe a quick fix would be a "sleep" directive you could place on the main thread to cause it to delay a bit? That would not be expected to be a permanent "fix" but simply a work-around. If I could place something like "sleep 5" that would cause the main thread to wait a little while, that could work around the race. > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Monday, April 26, 2010 2:32 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > Sent: Monday, April 26, 2010 10:52 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > root. > > > > I think the problem is that it spawns a new thread to load the udp > and > > tcp modules and that should be done by the main thread so that it > gets > > done in sequence before the privs are processed. > > I think your analysis is right, this is where the race happens. > However, the > cure is far from being as simple as it sounds: you are actually > recommending > a full redesign of the input plugin interface. It would also have other > implications, including a potential unacceptable startup delay. > > This is what I quoted with "a lot of work to do". So, unfortunately, it > does > not look like something I can fix quickly. Let me once again reiterate > that > the priv drop code is far from being a complete solution. I added the > current > code when I saw that it was easy to do and useful for some situations. > We > once had someone who was interested in sponsoring a complete > implementation, > but that did unfortunately not materialize. As I am currently short on > time > due to other work to do, I do not find sufficient time to look at this. > It is > far from being a trivial task, even though I hope to be able to do it > without > a full redesign. I still think it is 2+ weeks worth of work. > > Rainer > > > > > > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > Sent: Monday, April 26, 2010 1:37 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > non-root. > > > > > > No problem -- the mailing list processor held it due to size > > > constrainst (and > > > I rejected it now). The size restriction was actually the prime > issue > > > why I > > > requested it to go to my private mail. So: nothing bad has happened > > ;) > > > > > > I'll try to look at the log asap and let you know what I find. > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > Sent: Monday, April 26, 2010 10:10 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > non- > > > root. > > > > > > > > Oops, sorry, I did not mean to send that attachment to the list. > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > Sent: Sunday, April 25, 2010 11:18 PM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > > non-root. > > > > > > > > > > The privilege drop code is still a hack. It needs proper > > > engineering > > > > > (as > > > > > stated in the doc). So it could very well be a race in this > > regard. > > > > On > > > > > the > > > > > other hand, it does not look so. Could you send me complete > debug > > > > logs > > > > > to my > > > > > private email address both with and without privilege drop > inside > > > > your > > > > > config. Maybe it is a simple thing, then I could fix it without > > the > > > > > large > > > > > effort really required. > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > > Sent: Monday, April 26, 2010 2:24 AM > > > > > > To: rsyslog-users > > > > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID > non- > > > root. > > > > > > > > > > > > Can't bind to TCP socket. The tcp module loads but I noticed > > > that > > > > it > > > > > > only tries to bind the socket AFTER it has dropped is privs > so > > it > > > > can > > > > > > not bind to a socket less than 1024. UDP bind works as that > > > seems > > > > to > > > > > > bind immediately after module load while the prog is still > > > running > > > > as > > > > > > root. If I set a tcp port >1024, it works. Could this be a > > race > > > > > > between > > > > > > two threads where a different thread is setting the UID/GID > and > > a > > > > > > different one is binding the connections and the UID gets > > changed > > > > > > before > > > > > > the binding thread has a chance to get the socket? > > > > > > > > > > > > Modules being loaded: > > > > > > > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > > > > 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' > > > > > > 9572.648645873:7f07c0a216f0: loading module > > > > > '/usr/lib/rsyslog/imudp.so' > > > > > > 9572.648713628:7f07c0a216f0: source file imudp.c requested > > > > reference > > > > > > for > > > > > > module 'lmnet', reference count now 4 > > > > > > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > > > > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > > > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports > at > > > > > *:514. > > > > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > > > > 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' > > > > > > 9572.648869611:7f07c0a216f0: loading module > > > > > '/usr/lib/rsyslog/imtcp.so' > > > > > > 9572.648938665:7f07c0a216f0: source file imtcp.c requested > > > > reference > > > > > > for > > > > > > module 'lmnet', reference count now 5 > > > > > > 9572.648953892:7f07c0a216f0: caller requested object > 'netstrm', > > > not > > > > > > found (iRet -3003) > > > > > > 9572.648968610:7f07c0a216f0: Requested to load module > > > 'lmnetstrms' > > > > > > 9572.648979310:7f07c0a216f0: loading module > > > > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > > > > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > > > > > > 9572.649068131:7f07c0a216f0: source file imtcp.c requested > > > > reference > > > > > > for > > > > > > module 'lmnetstrms', reference count now 1 > > > > > > 9572.649079163:7f07c0a216f0: caller requested object > > 'tcps_sess', > > > > not > > > > > > found (iRet -3003) > > > > > > 9572.649095086:7f07c0a216f0: Requested to load module > > 'lmtcpsrv' > > > > > > 9572.649105485:7f07c0a216f0: loading module > > > > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c > requested > > > > > > reference > > > > > > for module 'lmnetstrms', reference count now 2 > > > > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested > > > > reference > > > > > > for module 'lmnet', reference count now 6 > > > > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested > > > > reference > > > > > > for module 'lmnetstrms', reference count now 3 > > > > > > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > > > > > > 9572.649241801:7f07c0a216f0: source file imtcp.c requested > > > > reference > > > > > > for > > > > > > module 'lmtcpsrv', reference count now 1 > > > > > > 9572.649252009:7f07c0a216f0: source file imtcp.c requested > > > > reference > > > > > > for > > > > > > module 'lmtcpsrv', reference count now 2 > > > > > > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > > > > > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' > > > > > > 9572.649321373:7f07c0a216f0: cfline: > > '$ActionFileDefaultTemplate > > > > > > RSYSLOG_TraditionalFileFormat' > > > > > > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction > on' > > > > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > > > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user > 'syslog' > > > > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > > > > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > > > > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > > > > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' > > > > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user > 'syslog' > > > > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup > syslog' > > > > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group > > 'syslog' > > > > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > > > > /etc/rsyslog.d/*.conf' > > > > > > 9572.650017305:7f07c0a216f0: requested to include config file > > > > > > '/etc/rsyslog.d/50-default.conf' > > > > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > > > > /var/log/auth.log' > > > > > > > > > > > > GID and UID being changed: > > > > > > > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, > > > > lenBuf > > > > > 78 > > > > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from > 'trebuchet', > > > msg > > > > > > rsyslogd's groupid changed to 103 > > > > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog > format. > > > > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > > > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > > > > > 9572.671957623:7f07be402910: Called action, logging to > builtin- > > > pipe > > > > > > 9572.671969801:7f07be402910: extend buf to at least 16, done > > 128 > > > > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 > > > > entries > > > > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy > > > > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised > worker > > > > start > > > > > > 9572.672059720:7f07be402910: Action requested to be > suspended, > > > done > > > > > > that. > > > > > > 9572.672085037:7f07be402910: main Q: entry deleted, state 0, > > size > > > > now > > > > > 1 > > > > > > entries > > > > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > > > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > > > > > 9572.672147659:7f07be402910: Called action, logging to > builtin- > > > file > > > > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from > 'trebuchet', > > > msg > > > > > > rsyslogd's userid changed to 101 > > > > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog > format. > > > > > > 9572.672192329:7f07be402910: extend buf to at least 138, done > > 256 > > > > > > 9572.672200766:7f07be402910: file to log to: /var/log/syslog > > > > > > > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > > > > transitioning > > > > > to > > > > > > regular run mode > > > > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket > 4 > > > > > > (IPv4/port 514). > > > > > > 9572.672576606:7f07bc3fe910: --------imUDP calling select, > > active > > > > > file > > > > > > descriptors (max 4): 4 > > > > > > 9572.672594858:7f07bdc01910: --------imuxsock calling select, > > > > active > > > > > > file descriptors (max 5): 3 5 > > > > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy > > > > > > 9572.672646478:7f07bbbfd910: caller requested object > > 'nsd_ptcp', > > > > not > > > > > > found (iRet -3003) > > > > > > 9572.672663716:7f07bbbfd910: Requested to load module > > > 'lmnsd_ptcp' > > > > > > 9572.672671184:7f07bbbfd910: loading module > > > > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested > > > > > reference > > > > > > for module 'lmnetstrms', reference count now 4 > > > > > > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > > > > > > 9572.672763826:7f07bbbfd910: source file netstrms.c requested > > > > > reference > > > > > > for module 'lmnsd_ptcp', reference count now 1 > > > > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket on > port > > > 514 > > > > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp > > socketWe > > > > > could > > > > > > initialize 0 TCP listen sockets out of 1 we recei > > > > > > ved - this may or may not be an error indication. > > > > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could > > > > successfully > > > > > > be > > > > > > initializedCalled LogError, msg: Could not crea > > > > > > te tcp listener, ignoring port 514. > > > > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from > 'trebuchet', > > > msg > > > > > > Could not create tcp listener, ignoring port 514. [t > > > > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Apr 26 11:45:37 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Apr 2010 11:45:37 +0200 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE7330@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE3@GRFEXC.intern.adiscon.com> <5A6D953473350C4B9995546AFE9939EE08FE7331@RWC-EX1.corp.seven.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CE4@GRFEXC.intern.adiscon.com> While I agree that it is ugly, it sounds like a good idea ;) Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Monday, April 26, 2010 11:44 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > Maybe a quick fix would be a "sleep" directive you could place on the > main thread to cause it to delay a bit? That would not be expected to > be > a permanent "fix" but simply a work-around. If I could place something > like "sleep 5" that would cause the main thread to wait a little while, > that could work around the race. > > > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > Sent: Monday, April 26, 2010 2:32 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > non-root. > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > Sent: Monday, April 26, 2010 10:52 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > > root. > > > > > > I think the problem is that it spawns a new thread to load the udp > > and > > > tcp modules and that should be done by the main thread so that it > > gets > > > done in sequence before the privs are processed. > > > > I think your analysis is right, this is where the race happens. > > However, the > > cure is far from being as simple as it sounds: you are actually > > recommending > > a full redesign of the input plugin interface. It would also have > other > > implications, including a potential unacceptable startup delay. > > > > This is what I quoted with "a lot of work to do". So, unfortunately, > it > > does > > not look like something I can fix quickly. Let me once again > reiterate > > that > > the priv drop code is far from being a complete solution. I added the > > current > > code when I saw that it was easy to do and useful for some > situations. > > We > > once had someone who was interested in sponsoring a complete > > implementation, > > but that did unfortunately not materialize. As I am currently short > on > > time > > due to other work to do, I do not find sufficient time to look at > this. > > It is > > far from being a trivial task, even though I hope to be able to do it > > without > > a full redesign. I still think it is 2+ weeks worth of work. > > > > Rainer > > > > > > > > > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > Sent: Monday, April 26, 2010 1:37 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > non-root. > > > > > > > > No problem -- the mailing list processor held it due to size > > > > constrainst (and > > > > I rejected it now). The size restriction was actually the prime > > issue > > > > why I > > > > requested it to go to my private mail. So: nothing bad has > happened > > > ;) > > > > > > > > I'll try to look at the log asap and let you know what I find. > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > Sent: Monday, April 26, 2010 10:10 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > non- > > > > root. > > > > > > > > > > Oops, sorry, I did not mean to send that attachment to the > list. > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > Sent: Sunday, April 25, 2010 11:18 PM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > > > non-root. > > > > > > > > > > > > The privilege drop code is still a hack. It needs proper > > > > engineering > > > > > > (as > > > > > > stated in the doc). So it could very well be a race in this > > > regard. > > > > > On > > > > > > the > > > > > > other hand, it does not look so. Could you send me complete > > debug > > > > > logs > > > > > > to my > > > > > > private email address both with and without privilege drop > > inside > > > > > your > > > > > > config. Maybe it is a simple thing, then I could fix it > without > > > the > > > > > > large > > > > > > effort really required. > > > > > > > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > > > Sent: Monday, April 26, 2010 2:24 AM > > > > > > > To: rsyslog-users > > > > > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID > > non- > > > > root. > > > > > > > > > > > > > > Can't bind to TCP socket. The tcp module loads but I > noticed > > > > that > > > > > it > > > > > > > only tries to bind the socket AFTER it has dropped is privs > > so > > > it > > > > > can > > > > > > > not bind to a socket less than 1024. UDP bind works as > that > > > > seems > > > > > to > > > > > > > bind immediately after module load while the prog is still > > > > running > > > > > as > > > > > > > root. If I set a tcp port >1024, it works. Could this be a > > > race > > > > > > > between > > > > > > > two threads where a different thread is setting the UID/GID > > and > > > a > > > > > > > different one is binding the connections and the UID gets > > > changed > > > > > > > before > > > > > > > the binding thread has a chance to get the socket? > > > > > > > > > > > > > > Modules being loaded: > > > > > > > > > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > > > > > 9572.648636228:7f07c0a216f0: Requested to load module > 'imudp' > > > > > > > 9572.648645873:7f07c0a216f0: loading module > > > > > > '/usr/lib/rsyslog/imudp.so' > > > > > > > 9572.648713628:7f07c0a216f0: source file imudp.c requested > > > > > reference > > > > > > > for > > > > > > > module 'lmnet', reference count now 4 > > > > > > > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > > > > > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > > > > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP > ports > > at > > > > > > *:514. > > > > > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > > > > > 9572.648859626:7f07c0a216f0: Requested to load module > 'imtcp' > > > > > > > 9572.648869611:7f07c0a216f0: loading module > > > > > > '/usr/lib/rsyslog/imtcp.so' > > > > > > > 9572.648938665:7f07c0a216f0: source file imtcp.c requested > > > > > reference > > > > > > > for > > > > > > > module 'lmnet', reference count now 5 > > > > > > > 9572.648953892:7f07c0a216f0: caller requested object > > 'netstrm', > > > > not > > > > > > > found (iRet -3003) > > > > > > > 9572.648968610:7f07c0a216f0: Requested to load module > > > > 'lmnetstrms' > > > > > > > 9572.648979310:7f07c0a216f0: loading module > > > > > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > > > > > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > > > > > > > 9572.649068131:7f07c0a216f0: source file imtcp.c requested > > > > > reference > > > > > > > for > > > > > > > module 'lmnetstrms', reference count now 1 > > > > > > > 9572.649079163:7f07c0a216f0: caller requested object > > > 'tcps_sess', > > > > > not > > > > > > > found (iRet -3003) > > > > > > > 9572.649095086:7f07c0a216f0: Requested to load module > > > 'lmtcpsrv' > > > > > > > 9572.649105485:7f07c0a216f0: loading module > > > > > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > > > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c > > requested > > > > > > > reference > > > > > > > for module 'lmnetstrms', reference count now 2 > > > > > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested > > > > > reference > > > > > > > for module 'lmnet', reference count now 6 > > > > > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested > > > > > reference > > > > > > > for module 'lmnetstrms', reference count now 3 > > > > > > > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > > > > > > > 9572.649241801:7f07c0a216f0: source file imtcp.c requested > > > > > reference > > > > > > > for > > > > > > > module 'lmtcpsrv', reference count now 1 > > > > > > > 9572.649252009:7f07c0a216f0: source file imtcp.c requested > > > > > reference > > > > > > > for > > > > > > > module 'lmtcpsrv', reference count now 2 > > > > > > > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > > > > > > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun > 514' > > > > > > > 9572.649321373:7f07c0a216f0: cfline: > > > '$ActionFileDefaultTemplate > > > > > > > RSYSLOG_TraditionalFileFormat' > > > > > > > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction > > on' > > > > > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > > > > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user > > 'syslog' > > > > > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > > > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > > > > > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > > > > > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > > > > > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > > > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > > > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser > syslog' > > > > > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user > > 'syslog' > > > > > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup > > syslog' > > > > > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group > > > 'syslog' > > > > > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > > > > > /etc/rsyslog.d/*.conf' > > > > > > > 9572.650017305:7f07c0a216f0: requested to include config > file > > > > > > > '/etc/rsyslog.d/50-default.conf' > > > > > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > > > > > /var/log/auth.log' > > > > > > > > > > > > > > GID and UID being changed: > > > > > > > > > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm > 0x1e11d60, > > > > > lenBuf > > > > > > 78 > > > > > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from > > 'trebuchet', > > > > msg > > > > > > > rsyslogd's groupid changed to 103 > > > > > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog > > format. > > > > > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > > > > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > > > > > > 9572.671957623:7f07be402910: Called action, logging to > > builtin- > > > > pipe > > > > > > > 9572.671969801:7f07be402910: extend buf to at least 16, > done > > > 128 > > > > > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > > > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size now > 2 > > > > > entries > > > > > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals > busy > > > > > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised > > worker > > > > > start > > > > > > > 9572.672059720:7f07be402910: Action requested to be > > suspended, > > > > done > > > > > > > that. > > > > > > > 9572.672085037:7f07be402910: main Q: entry deleted, state > 0, > > > size > > > > > now > > > > > > 1 > > > > > > > entries > > > > > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > > > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > > > > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > > > > > > 9572.672147659:7f07be402910: Called action, logging to > > builtin- > > > > file > > > > > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from > > 'trebuchet', > > > > msg > > > > > > > rsyslogd's userid changed to 101 > > > > > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog > > format. > > > > > > > 9572.672192329:7f07be402910: extend buf to at least 138, > done > > > 256 > > > > > > > 9572.672200766:7f07be402910: file to log to: > /var/log/syslog > > > > > > > > > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > > > > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > > > > > transitioning > > > > > > to > > > > > > > regular run mode > > > > > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd > socket > > 4 > > > > > > > (IPv4/port 514). > > > > > > > 9572.672576606:7f07bc3fe910: --------imUDP calling select, > > > active > > > > > > file > > > > > > > descriptors (max 4): 4 > > > > > > > 9572.672594858:7f07bdc01910: --------imuxsock calling > select, > > > > > active > > > > > > > file descriptors (max 5): 3 5 > > > > > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals > busy > > > > > > > 9572.672646478:7f07bbbfd910: caller requested object > > > 'nsd_ptcp', > > > > > not > > > > > > > found (iRet -3003) > > > > > > > 9572.672663716:7f07bbbfd910: Requested to load module > > > > 'lmnsd_ptcp' > > > > > > > 9572.672671184:7f07bbbfd910: loading module > > > > > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > > > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c > requested > > > > > > reference > > > > > > > for module 'lmnetstrms', reference count now 4 > > > > > > > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > > > > > > > 9572.672763826:7f07bbbfd910: source file netstrms.c > requested > > > > > > reference > > > > > > > for module 'lmnsd_ptcp', reference count now 1 > > > > > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket on > > port > > > > 514 > > > > > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp > > > socketWe > > > > > > could > > > > > > > initialize 0 TCP listen sockets out of 1 we recei > > > > > > > ved - this may or may not be an error indication. > > > > > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could > > > > > successfully > > > > > > > be > > > > > > > initializedCalled LogError, msg: Could not crea > > > > > > > te tcp listener, ignoring port 514. > > > > > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from > > 'trebuchet', > > > > msg > > > > > > > Could not create tcp listener, ignoring port 514. [t > > > > > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > > > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Apr 26 12:09:55 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Apr 2010 12:09:55 +0200 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE7330@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE3@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE7331@RWC-EX1.corp.seven.com> <9B6E2A8877C38245BFB15CC491A11DA7103CE4@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CE5@GRFEXC.intern.adiscon.com> This is the patch for v4-devel (master will follow soon): http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=d19806431653e6575a002ab4 8206c16d3041e465 While I make such changes only to the latest devel, you should be able to apply the patch without problems to almost all versions. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Monday, April 26, 2010 11:46 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > While I agree that it is ugly, it sounds like a good idea ;) > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > Sent: Monday, April 26, 2010 11:44 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > root. > > > > Maybe a quick fix would be a "sleep" directive you could place on the > > main thread to cause it to delay a bit? That would not be expected to > > be > > a permanent "fix" but simply a work-around. If I could place > something > > like "sleep 5" that would cause the main thread to wait a little > while, > > that could work around the race. > > > > > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > Sent: Monday, April 26, 2010 2:32 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > non-root. > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > Sent: Monday, April 26, 2010 10:52 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > non- > > > root. > > > > > > > > I think the problem is that it spawns a new thread to load the > udp > > > and > > > > tcp modules and that should be done by the main thread so that it > > > gets > > > > done in sequence before the privs are processed. > > > > > > I think your analysis is right, this is where the race happens. > > > However, the > > > cure is far from being as simple as it sounds: you are actually > > > recommending > > > a full redesign of the input plugin interface. It would also have > > other > > > implications, including a potential unacceptable startup delay. > > > > > > This is what I quoted with "a lot of work to do". So, > unfortunately, > > it > > > does > > > not look like something I can fix quickly. Let me once again > > reiterate > > > that > > > the priv drop code is far from being a complete solution. I added > the > > > current > > > code when I saw that it was easy to do and useful for some > > situations. > > > We > > > once had someone who was interested in sponsoring a complete > > > implementation, > > > but that did unfortunately not materialize. As I am currently short > > on > > > time > > > due to other work to do, I do not find sufficient time to look at > > this. > > > It is > > > far from being a trivial task, even though I hope to be able to do > it > > > without > > > a full redesign. I still think it is 2+ weeks worth of work. > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > Sent: Monday, April 26, 2010 1:37 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > > non-root. > > > > > > > > > > No problem -- the mailing list processor held it due to size > > > > > constrainst (and > > > > > I rejected it now). The size restriction was actually the prime > > > issue > > > > > why I > > > > > requested it to go to my private mail. So: nothing bad has > > happened > > > > ;) > > > > > > > > > > I'll try to look at the log asap and let you know what I find. > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > > Sent: Monday, April 26, 2010 10:10 AM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > non- > > > > > root. > > > > > > > > > > > > Oops, sorry, I did not mean to send that attachment to the > > list. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > > Sent: Sunday, April 25, 2010 11:18 PM > > > > > > > To: rsyslog-users > > > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after > UID > > > > > > non-root. > > > > > > > > > > > > > > The privilege drop code is still a hack. It needs proper > > > > > engineering > > > > > > > (as > > > > > > > stated in the doc). So it could very well be a race in this > > > > regard. > > > > > > On > > > > > > > the > > > > > > > other hand, it does not look so. Could you send me complete > > > debug > > > > > > logs > > > > > > > to my > > > > > > > private email address both with and without privilege drop > > > inside > > > > > > your > > > > > > > config. Maybe it is a simple thing, then I could fix it > > without > > > > the > > > > > > > large > > > > > > > effort really required. > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > > > > Sent: Monday, April 26, 2010 2:24 AM > > > > > > > > To: rsyslog-users > > > > > > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > non- > > > > > root. > > > > > > > > > > > > > > > > Can't bind to TCP socket. The tcp module loads but I > > noticed > > > > > that > > > > > > it > > > > > > > > only tries to bind the socket AFTER it has dropped is > privs > > > so > > > > it > > > > > > can > > > > > > > > not bind to a socket less than 1024. UDP bind works as > > that > > > > > seems > > > > > > to > > > > > > > > bind immediately after module load while the prog is > still > > > > > running > > > > > > as > > > > > > > > root. If I set a tcp port >1024, it works. Could this be > a > > > > race > > > > > > > > between > > > > > > > > two threads where a different thread is setting the > UID/GID > > > and > > > > a > > > > > > > > different one is binding the connections and the UID gets > > > > changed > > > > > > > > before > > > > > > > > the binding thread has a chance to get the socket? > > > > > > > > > > > > > > > > Modules being loaded: > > > > > > > > > > > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > > > > > > 9572.648636228:7f07c0a216f0: Requested to load module > > 'imudp' > > > > > > > > 9572.648645873:7f07c0a216f0: loading module > > > > > > > '/usr/lib/rsyslog/imudp.so' > > > > > > > > 9572.648713628:7f07c0a216f0: source file imudp.c > requested > > > > > > reference > > > > > > > > for > > > > > > > > module 'lmnet', reference count now 4 > > > > > > > > 9572.648734955:7f07c0a216f0: module of type 0 being > loaded. > > > > > > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > > > > > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP > > ports > > > at > > > > > > > *:514. > > > > > > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > > > > > > 9572.648859626:7f07c0a216f0: Requested to load module > > 'imtcp' > > > > > > > > 9572.648869611:7f07c0a216f0: loading module > > > > > > > '/usr/lib/rsyslog/imtcp.so' > > > > > > > > 9572.648938665:7f07c0a216f0: source file imtcp.c > requested > > > > > > reference > > > > > > > > for > > > > > > > > module 'lmnet', reference count now 5 > > > > > > > > 9572.648953892:7f07c0a216f0: caller requested object > > > 'netstrm', > > > > > not > > > > > > > > found (iRet -3003) > > > > > > > > 9572.648968610:7f07c0a216f0: Requested to load module > > > > > 'lmnetstrms' > > > > > > > > 9572.648979310:7f07c0a216f0: loading module > > > > > > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > > > > > > 9572.649053366:7f07c0a216f0: module of type 2 being > loaded. > > > > > > > > 9572.649068131:7f07c0a216f0: source file imtcp.c > requested > > > > > > reference > > > > > > > > for > > > > > > > > module 'lmnetstrms', reference count now 1 > > > > > > > > 9572.649079163:7f07c0a216f0: caller requested object > > > > 'tcps_sess', > > > > > > not > > > > > > > > found (iRet -3003) > > > > > > > > 9572.649095086:7f07c0a216f0: Requested to load module > > > > 'lmtcpsrv' > > > > > > > > 9572.649105485:7f07c0a216f0: loading module > > > > > > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > > > > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c > > > requested > > > > > > > > reference > > > > > > > > for module 'lmnetstrms', reference count now 2 > > > > > > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c > requested > > > > > > reference > > > > > > > > for module 'lmnet', reference count now 6 > > > > > > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c > requested > > > > > > reference > > > > > > > > for module 'lmnetstrms', reference count now 3 > > > > > > > > 9572.649231362:7f07c0a216f0: module of type 2 being > loaded. > > > > > > > > 9572.649241801:7f07c0a216f0: source file imtcp.c > requested > > > > > > reference > > > > > > > > for > > > > > > > > module 'lmtcpsrv', reference count now 1 > > > > > > > > 9572.649252009:7f07c0a216f0: source file imtcp.c > requested > > > > > > reference > > > > > > > > for > > > > > > > > module 'lmtcpsrv', reference count now 2 > > > > > > > > 9572.649287366:7f07c0a216f0: module of type 0 being > loaded. > > > > > > > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun > > 514' > > > > > > > > 9572.649321373:7f07c0a216f0: cfline: > > > > '$ActionFileDefaultTemplate > > > > > > > > RSYSLOG_TraditionalFileFormat' > > > > > > > > 9572.649334345:7f07c0a216f0: cfline: > '$RepeatedMsgReduction > > > on' > > > > > > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > > > > > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user > > > 'syslog' > > > > > > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > > > > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group > 'adm' > > > > > > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode > 0640' > > > > > > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode > 0755' > > > > > > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > > > > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > > > > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser > > syslog' > > > > > > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user > > > 'syslog' > > > > > > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup > > > syslog' > > > > > > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group > > > > 'syslog' > > > > > > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > > > > > > /etc/rsyslog.d/*.conf' > > > > > > > > 9572.650017305:7f07c0a216f0: requested to include config > > file > > > > > > > > '/etc/rsyslog.d/50-default.conf' > > > > > > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > > > > > > /var/log/auth.log' > > > > > > > > > > > > > > > > GID and UID being changed: > > > > > > > > > > > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm > > 0x1e11d60, > > > > > > lenBuf > > > > > > > 78 > > > > > > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from > > > 'trebuchet', > > > > > msg > > > > > > > > rsyslogd's groupid changed to 103 > > > > > > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog > > > format. > > > > > > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > > > > > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > > > > > > > 9572.671957623:7f07be402910: Called action, logging to > > > builtin- > > > > > pipe > > > > > > > > 9572.671969801:7f07be402910: extend buf to at least 16, > > done > > > > 128 > > > > > > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > > > > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size > now > > 2 > > > > > > entries > > > > > > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals > > busy > > > > > > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised > > > worker > > > > > > start > > > > > > > > 9572.672059720:7f07be402910: Action requested to be > > > suspended, > > > > > done > > > > > > > > that. > > > > > > > > 9572.672085037:7f07be402910: main Q: entry deleted, state > > 0, > > > > size > > > > > > now > > > > > > > 1 > > > > > > > > entries > > > > > > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > > > > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > > > > > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > > > > > > > 9572.672147659:7f07be402910: Called action, logging to > > > builtin- > > > > > file > > > > > > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from > > > 'trebuchet', > > > > > msg > > > > > > > > rsyslogd's userid changed to 101 > > > > > > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog > > > format. > > > > > > > > 9572.672192329:7f07be402910: extend buf to at least 138, > > done > > > > 256 > > > > > > > > 9572.672200766:7f07be402910: file to log to: > > /var/log/syslog > > > > > > > > > > > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > > > > > > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > > > > > > transitioning > > > > > > > to > > > > > > > > regular run mode > > > > > > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd > > socket > > > 4 > > > > > > > > (IPv4/port 514). > > > > > > > > 9572.672576606:7f07bc3fe910: --------imUDP calling > select, > > > > active > > > > > > > file > > > > > > > > descriptors (max 4): 4 > > > > > > > > 9572.672594858:7f07bdc01910: --------imuxsock calling > > select, > > > > > > active > > > > > > > > file descriptors (max 5): 3 5 > > > > > > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals > > busy > > > > > > > > 9572.672646478:7f07bbbfd910: caller requested object > > > > 'nsd_ptcp', > > > > > > not > > > > > > > > found (iRet -3003) > > > > > > > > 9572.672663716:7f07bbbfd910: Requested to load module > > > > > 'lmnsd_ptcp' > > > > > > > > 9572.672671184:7f07bbbfd910: loading module > > > > > > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > > > > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c > > requested > > > > > > > reference > > > > > > > > for module 'lmnetstrms', reference count now 4 > > > > > > > > 9572.672757197:7f07bbbfd910: module of type 2 being > loaded. > > > > > > > > 9572.672763826:7f07bbbfd910: source file netstrms.c > > requested > > > > > > > reference > > > > > > > > for module 'lmnsd_ptcp', reference count now 1 > > > > > > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket > on > > > port > > > > > 514 > > > > > > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp > > > > socketWe > > > > > > > could > > > > > > > > initialize 0 TCP listen sockets out of 1 we recei > > > > > > > > ved - this may or may not be an error indication. > > > > > > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could > > > > > > successfully > > > > > > > > be > > > > > > > > initializedCalled LogError, msg: Could not crea > > > > > > > > te tcp listener, ignoring port 514. > > > > > > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from > > > 'trebuchet', > > > > > msg > > > > > > > > Could not create tcp listener, ignoring port 514. [t > > > > > > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Mon Apr 26 23:42:11 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 26 Apr 2010 14:42:11 -0700 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE7330@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE3@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE7331@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE4@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103CE5@GRFEXC.intern.adiscon.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE736D@RWC-EX1.corp.seven.com> It doesn't work. TCP doesn't start until after privs are dropped. Just can't use it or must drop privs after binding the socket (like Apache does, for example). > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Monday, April 26, 2010 3:10 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > This is the patch for v4-devel (master will follow soon): > > http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=d19806431653e6575a > 002ab4 > 8206c16d3041e465 > > While I make such changes only to the latest devel, you should be able > to > apply the patch without problems to almost all versions. > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > Sent: Monday, April 26, 2010 11:46 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > root. > > > > While I agree that it is ugly, it sounds like a good idea ;) > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > Sent: Monday, April 26, 2010 11:44 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > > root. > > > > > > Maybe a quick fix would be a "sleep" directive you could place on > the > > > main thread to cause it to delay a bit? That would not be expected > to > > > be > > > a permanent "fix" but simply a work-around. If I could place > > something > > > like "sleep 5" that would cause the main thread to wait a little > > while, > > > that could work around the race. > > > > > > > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > Sent: Monday, April 26, 2010 2:32 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > non-root. > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > Sent: Monday, April 26, 2010 10:52 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > non- > > > > root. > > > > > > > > > > I think the problem is that it spawns a new thread to load the > > udp > > > > and > > > > > tcp modules and that should be done by the main thread so that > it > > > > gets > > > > > done in sequence before the privs are processed. > > > > > > > > I think your analysis is right, this is where the race happens. > > > > However, the > > > > cure is far from being as simple as it sounds: you are actually > > > > recommending > > > > a full redesign of the input plugin interface. It would also have > > > other > > > > implications, including a potential unacceptable startup delay. > > > > > > > > This is what I quoted with "a lot of work to do". So, > > unfortunately, > > > it > > > > does > > > > not look like something I can fix quickly. Let me once again > > > reiterate > > > > that > > > > the priv drop code is far from being a complete solution. I added > > the > > > > current > > > > code when I saw that it was easy to do and useful for some > > > situations. > > > > We > > > > once had someone who was interested in sponsoring a complete > > > > implementation, > > > > but that did unfortunately not materialize. As I am currently > short > > > on > > > > time > > > > due to other work to do, I do not find sufficient time to look at > > > this. > > > > It is > > > > far from being a trivial task, even though I hope to be able to > do > > it > > > > without > > > > a full redesign. I still think it is 2+ weeks worth of work. > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > Sent: Monday, April 26, 2010 1:37 AM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > > > non-root. > > > > > > > > > > > > No problem -- the mailing list processor held it due to size > > > > > > constrainst (and > > > > > > I rejected it now). The size restriction was actually the > prime > > > > issue > > > > > > why I > > > > > > requested it to go to my private mail. So: nothing bad has > > > happened > > > > > ;) > > > > > > > > > > > > I'll try to look at the log asap and let you know what I > find. > > > > > > > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > > > Sent: Monday, April 26, 2010 10:10 AM > > > > > > > To: rsyslog-users > > > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after > UID > > > > non- > > > > > > root. > > > > > > > > > > > > > > Oops, sorry, I did not mean to send that attachment to the > > > list. > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > > > Sent: Sunday, April 25, 2010 11:18 PM > > > > > > > > To: rsyslog-users > > > > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after > > UID > > > > > > > non-root. > > > > > > > > > > > > > > > > The privilege drop code is still a hack. It needs proper > > > > > > engineering > > > > > > > > (as > > > > > > > > stated in the doc). So it could very well be a race in > this > > > > > regard. > > > > > > > On > > > > > > > > the > > > > > > > > other hand, it does not look so. Could you send me > complete > > > > debug > > > > > > > logs > > > > > > > > to my > > > > > > > > private email address both with and without privilege > drop > > > > inside > > > > > > > your > > > > > > > > config. Maybe it is a simple thing, then I could fix it > > > without > > > > > the > > > > > > > > large > > > > > > > > effort really required. > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog- > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > > > > > Sent: Monday, April 26, 2010 2:24 AM > > > > > > > > > To: rsyslog-users > > > > > > > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after > UID > > > > non- > > > > > > root. > > > > > > > > > > > > > > > > > > Can't bind to TCP socket. The tcp module loads but I > > > noticed > > > > > > that > > > > > > > it > > > > > > > > > only tries to bind the socket AFTER it has dropped is > > privs > > > > so > > > > > it > > > > > > > can > > > > > > > > > not bind to a socket less than 1024. UDP bind works as > > > that > > > > > > seems > > > > > > > to > > > > > > > > > bind immediately after module load while the prog is > > still > > > > > > running > > > > > > > as > > > > > > > > > root. If I set a tcp port >1024, it works. Could this > be > > a > > > > > race > > > > > > > > > between > > > > > > > > > two threads where a different thread is setting the > > UID/GID > > > > and > > > > > a > > > > > > > > > different one is binding the connections and the UID > gets > > > > > changed > > > > > > > > > before > > > > > > > > > the binding thread has a chance to get the socket? > > > > > > > > > > > > > > > > > > Modules being loaded: > > > > > > > > > > > > > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > > > > > > > 9572.648636228:7f07c0a216f0: Requested to load module > > > 'imudp' > > > > > > > > > 9572.648645873:7f07c0a216f0: loading module > > > > > > > > '/usr/lib/rsyslog/imudp.so' > > > > > > > > > 9572.648713628:7f07c0a216f0: source file imudp.c > > requested > > > > > > > reference > > > > > > > > > for > > > > > > > > > module 'lmnet', reference count now 4 > > > > > > > > > 9572.648734955:7f07c0a216f0: module of type 0 being > > loaded. > > > > > > > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun > 514' > > > > > > > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP > > > ports > > > > at > > > > > > > > *:514. > > > > > > > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > > > > > > > 9572.648859626:7f07c0a216f0: Requested to load module > > > 'imtcp' > > > > > > > > > 9572.648869611:7f07c0a216f0: loading module > > > > > > > > '/usr/lib/rsyslog/imtcp.so' > > > > > > > > > 9572.648938665:7f07c0a216f0: source file imtcp.c > > requested > > > > > > > reference > > > > > > > > > for > > > > > > > > > module 'lmnet', reference count now 5 > > > > > > > > > 9572.648953892:7f07c0a216f0: caller requested object > > > > 'netstrm', > > > > > > not > > > > > > > > > found (iRet -3003) > > > > > > > > > 9572.648968610:7f07c0a216f0: Requested to load module > > > > > > 'lmnetstrms' > > > > > > > > > 9572.648979310:7f07c0a216f0: loading module > > > > > > > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > > > > > > > 9572.649053366:7f07c0a216f0: module of type 2 being > > loaded. > > > > > > > > > 9572.649068131:7f07c0a216f0: source file imtcp.c > > requested > > > > > > > reference > > > > > > > > > for > > > > > > > > > module 'lmnetstrms', reference count now 1 > > > > > > > > > 9572.649079163:7f07c0a216f0: caller requested object > > > > > 'tcps_sess', > > > > > > > not > > > > > > > > > found (iRet -3003) > > > > > > > > > 9572.649095086:7f07c0a216f0: Requested to load module > > > > > 'lmtcpsrv' > > > > > > > > > 9572.649105485:7f07c0a216f0: loading module > > > > > > > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > > > > > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c > > > > requested > > > > > > > > > reference > > > > > > > > > for module 'lmnetstrms', reference count now 2 > > > > > > > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c > > requested > > > > > > > reference > > > > > > > > > for module 'lmnet', reference count now 6 > > > > > > > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c > > requested > > > > > > > reference > > > > > > > > > for module 'lmnetstrms', reference count now 3 > > > > > > > > > 9572.649231362:7f07c0a216f0: module of type 2 being > > loaded. > > > > > > > > > 9572.649241801:7f07c0a216f0: source file imtcp.c > > requested > > > > > > > reference > > > > > > > > > for > > > > > > > > > module 'lmtcpsrv', reference count now 1 > > > > > > > > > 9572.649252009:7f07c0a216f0: source file imtcp.c > > requested > > > > > > > reference > > > > > > > > > for > > > > > > > > > module 'lmtcpsrv', reference count now 2 > > > > > > > > > 9572.649287366:7f07c0a216f0: module of type 0 being > > loaded. > > > > > > > > > 9572.649299663:7f07c0a216f0: cfline: > '$InputTCPServerRun > > > 514' > > > > > > > > > 9572.649321373:7f07c0a216f0: cfline: > > > > > '$ActionFileDefaultTemplate > > > > > > > > > RSYSLOG_TraditionalFileFormat' > > > > > > > > > 9572.649334345:7f07c0a216f0: cfline: > > '$RepeatedMsgReduction > > > > on' > > > > > > > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner > syslog' > > > > > > > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user > > > > 'syslog' > > > > > > > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > > > > > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group > > 'adm' > > > > > > > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode > > 0640' > > > > > > > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode > > 0755' > > > > > > > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > > > > > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > > > > > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser > > > syslog' > > > > > > > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user > > > > 'syslog' > > > > > > > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup > > > > syslog' > > > > > > > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group > > > > > 'syslog' > > > > > > > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > > > > > > > /etc/rsyslog.d/*.conf' > > > > > > > > > 9572.650017305:7f07c0a216f0: requested to include > config > > > file > > > > > > > > > '/etc/rsyslog.d/50-default.conf' > > > > > > > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > > > > > > > /var/log/auth.log' > > > > > > > > > > > > > > > > > > GID and UID being changed: > > > > > > > > > > > > > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm > > > 0x1e11d60, > > > > > > > lenBuf > > > > > > > > 78 > > > > > > > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from > > > > 'trebuchet', > > > > > > msg > > > > > > > > > rsyslogd's groupid changed to 103 > > > > > > > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog > > > > format. > > > > > > > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > > > > > > > 9572.671947526:7f07be402910: testing filter, f_pmask > 240 > > > > > > > > > 9572.671957623:7f07be402910: Called action, logging to > > > > builtin- > > > > > > pipe > > > > > > > > > 9572.671969801:7f07be402910: extend buf to at least 16, > > > done > > > > > 128 > > > > > > > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > > > > > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size > > now > > > 2 > > > > > > > entries > > > > > > > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers > signals > > > busy > > > > > > > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised > > > > worker > > > > > > > start > > > > > > > > > 9572.672059720:7f07be402910: Action requested to be > > > > suspended, > > > > > > done > > > > > > > > > that. > > > > > > > > > 9572.672085037:7f07be402910: main Q: entry deleted, > state > > > 0, > > > > > size > > > > > > > now > > > > > > > > 1 > > > > > > > > > entries > > > > > > > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > > > > > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > > > > > > > 9572.672136161:7f07be402910: testing filter, f_pmask > 255 > > > > > > > > > 9572.672147659:7f07be402910: Called action, logging to > > > > builtin- > > > > > > file > > > > > > > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from > > > > 'trebuchet', > > > > > > msg > > > > > > > > > rsyslogd's userid changed to 101 > > > > > > > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog > > > > format. > > > > > > > > > 9572.672192329:7f07be402910: extend buf to at least > 138, > > > done > > > > > 256 > > > > > > > > > 9572.672200766:7f07be402910: file to log to: > > > /var/log/syslog > > > > > > > > > > > > > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > > > > > > > > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > > > > > > > transitioning > > > > > > > > to > > > > > > > > > regular run mode > > > > > > > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd > > > socket > > > > 4 > > > > > > > > > (IPv4/port 514). > > > > > > > > > 9572.672576606:7f07bc3fe910: --------imUDP calling > > select, > > > > > active > > > > > > > > file > > > > > > > > > descriptors (max 4): 4 > > > > > > > > > 9572.672594858:7f07bdc01910: --------imuxsock calling > > > select, > > > > > > > active > > > > > > > > > file descriptors (max 5): 3 5 > > > > > > > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers > signals > > > busy > > > > > > > > > 9572.672646478:7f07bbbfd910: caller requested object > > > > > 'nsd_ptcp', > > > > > > > not > > > > > > > > > found (iRet -3003) > > > > > > > > > 9572.672663716:7f07bbbfd910: Requested to load module > > > > > > 'lmnsd_ptcp' > > > > > > > > > 9572.672671184:7f07bbbfd910: loading module > > > > > > > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > > > > > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c > > > requested > > > > > > > > reference > > > > > > > > > for module 'lmnetstrms', reference count now 4 > > > > > > > > > 9572.672757197:7f07bbbfd910: module of type 2 being > > loaded. > > > > > > > > > 9572.672763826:7f07bbbfd910: source file netstrms.c > > > requested > > > > > > > > reference > > > > > > > > > for module 'lmnsd_ptcp', reference count now 1 > > > > > > > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket > > on > > > > port > > > > > > 514 > > > > > > > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp > > > > > socketWe > > > > > > > > could > > > > > > > > > initialize 0 TCP listen sockets out of 1 we recei > > > > > > > > > ved - this may or may not be an error indication. > > > > > > > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets > could > > > > > > > successfully > > > > > > > > > be > > > > > > > > > initializedCalled LogError, msg: Could not crea > > > > > > > > > te tcp listener, ignoring port 514. > > > > > > > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from > > > > 'trebuchet', > > > > > > msg > > > > > > > > > Could not create tcp listener, ignoring port 514. [t > > > > > > > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > rsyslog mailing list > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > http://www.rsyslog.com > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From jkempf at davisvision.com Tue Apr 27 04:15:46 2010 From: jkempf at davisvision.com (Jesse Kempf) Date: Tue, 27 Apr 2010 02:15:46 +0000 Subject: [rsyslog] Solaris SMF Manifest Message-ID: <13819_1272334548_4BD648D3_13819_1145_1_4BD648D2.4090408@davisvision.com> Hi, So I've been working on getting rsyslogd set up on a Solaris platform (not as a local syslog replacement, but as the central syslog server for a network). Attached is a patchset which adds a Solaris SMF service manifest (rsyslog.xml) and method script (svc-rsyslog). I'm not sure how exactly to wire this into the install process, so I'll describe what needs to get done. svc-rsyslog needs to be kicked into $PREFIX/etc and be chmod +x. rsyslog.xml needs the literal string 'PREFIX' replaced with $PREFIX, and then passed to svccfg import. Something as simple as 'sed "s#PREFIX#$PREFIX#g" < rsyslog.xml | svccfg import -' would do the trick. The manifest registers rsyslog with SMF under the FMRI svc:/network/rsyslog:default. The properties (accessible using svcprop) 'rsyslog/conf' and 'rsyslog/opts' contain the path to the config file and any command-line options for rsyslog respectively. I've also updated http://wiki.rsyslog.com/index.php/Solaris based on my experiences getting rsyslog working on Solaris 10. All in all, this has been much, MUCH easier than it was when I tried two years ago. Cheers, -Jesse ------------------------------------------------------------------------ The information contained in this communication is intended only for the use of the recipient(s) named above. It may contain information that is privileged or confidential, and may be protected by State and/or Federal Regulations. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. ------------------------------------------------------------------------ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: solaris-smf.patches URL: From gbonser at seven.com Tue Apr 27 23:42:30 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 27 Apr 2010 14:42:30 -0700 Subject: [rsyslog] Question about output channels Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE73B3@RWC-EX1.corp.seven.com> When an output channel runs a rotation script due to file size limit being reached, does it pass anything in the environment to tell a log rotation program which file triggered the rotation? That would be handy by allowing a single rotation script to handle all the output channels if it could pick up the file to rotate from the environment when it is run. George From jkempf at davisvision.com Wed Apr 28 18:38:55 2010 From: jkempf at davisvision.com (Jesse Kempf) Date: Wed, 28 Apr 2010 16:38:55 +0000 Subject: [rsyslog] Tuning reconnect delay Message-ID: <13016_1272472735_4BD8649F_13016_205_1_4BD8649F.90508@davisvision.com> Hi, Is there any way to adjust how long rsyslog will wait to reconnect after a TCP session to a remote server has been closed? I looked through the documentation but nothing jumped out at me. Thanks, -Jesse ------------------------------------------------------------------------ The information contained in this communication is intended only for the use of the recipient(s) named above. It may contain information that is privileged or confidential, and may be protected by State and/or Federal Regulations. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. ------------------------------------------------------------------------ From b.arenal at gmail.com Thu Apr 29 19:07:04 2010 From: b.arenal at gmail.com (Bryan Arenal) Date: Thu, 29 Apr 2010 11:07:04 -0600 Subject: [rsyslog] Running in debug mode: -1 bytes? Message-ID: Hi, I have two systems running rsyslog 4.2.0 and snort 2.8.5.3. ?On one of those systems, it's forwarding snort's alert logs to our central log server correctly. ?On the second box (that has the same snort and rsyslog configs), it has only forwarded one alert but the alert file is seeing a lot of data so I don't know what's going on. ?I put rsyslog in debug mode and every 10 secs, it logs the following message: ?4478.108169000:41851940: strm 0x1e8b5dd0: file 6 read -1 bytes ?4478.108225000:41851940: strm 0x1e8b6fc0: file 7 read 0 bytes What does that mean? ?It appears that the only time it deviated was when it sent the one alert to the syslog server: ?4148.075280000:41851940: strm 0x1e8b6fc0: file 7 read 225 bytes But the file that it's referring to as "file 6" is seeing much more data than "file 7" and it shouldn't have any problem reading it as it's 644 and owned by snort.snort (rsyslog is running as root). ?Does anyone know what might be going on or have anything I can try? Thanks! Bryan From darrick.harter at gmail.com Fri Apr 30 19:09:04 2010 From: darrick.harter at gmail.com (Darrick Harter) Date: Fri, 30 Apr 2010 12:09:04 -0500 Subject: [rsyslog] Striping off part of a hostname in a template file Message-ID: I am trying to strip out parts of a hostname for logs that come in from my firewalls. So with each firewall that I have, I effectively have a pair, and "a" and a "b" firewall. For this example, I will call them firewalla and firewallb. Is there a way to strip the 'a' or 'b' off the filename that it's being written to dynamically? I have done this as an example, and it works as I expect it to: $template DYNfirewalllog,"/path/to/logs/firewall/%$YEAR%%$MONTH%%$DAY%-iptables.log" if \ $source == 'firewalla' \ or \ $source == 'firewallb' \ and \ $msg contains 'IN=' \ then ?DYNfirewalllog I have tried doing things similar to this, that effectively don't match at all, the regex works fine on the online checker, but I get a directory created called "**NO MATCH**" when I try to use this in practice. $template DYNfirewall,"/path/to/logs/%hostname:R,ERE,0,DFLT:.\\s[a-z].*[fw|ids]0[0-9]--end%/%$YEAR%%$MONTH%%$DAY%-iptables.log" if \ $msg contains 'IN=' \ then ?DYNfirewall If I only had a few firewalls, then this wouldn't be a big deal, I could simply add a new entry for each firewall pair. However, I currently am managing 180 firewalls... or 90 pairs, and we are still growing, so I'm looking for something a bit more dynamic if you will when it comes to managing it. Any ideas would be greatly appreciated! From jiri.hlinka at gmail.com Fri Apr 2 00:52:03 2010 From: jiri.hlinka at gmail.com (=?UTF-8?B?SmnFmcOtIEhsaW5rYQ==?=) Date: Fri, 2 Apr 2010 00:52:03 +0200 Subject: [rsyslog] RHEL 5.5 and rsyslog packages Message-ID: Hi, RHEL 5.5 was released recently and it includes updated rsyslog version too. As many of you may know, up to RHEL 5.4 there was rsyslog version 2.0.6 which is rather old and unsupported. But changes have been made in RHEL 5 update 5: it includes package rsyslog (+ rsyslog-[module_name], see below) version 3.22.1. But there is yet another rsyslog version - package rsyslog4 (+ rsyslog4-[module_name]) serves version 4.4.2! Modules included in separated rpms: gnutls gssapi mysql pgsql relp (just for rsyslog4 package) Well, these are not the latest ones, but it is progredss indeed :-) . Cheers, Jirka -- Ji?? Hlinka GSM: +420 773 103 947 Enlogit s.r.o., U Cukrovaru 509/4, 400 07 ?st? nad Labem tel.: +420 474 745 159, fax: +420 474 745 160 web: www.enlogit.cz Enlogit IT pro firmy From joel.sinor at gmail.com Sun Apr 4 04:07:59 2010 From: joel.sinor at gmail.com (Joel Sinor) Date: Sat, 3 Apr 2010 21:07:59 -0500 Subject: [rsyslog] Could not open dynamic file ... - discarding message Message-ID: Hello, I was reading up on this error (Could not open dynamic file) which occurred when I tried to use dynamic files, and found the following post: http://www.mail-archive.com/rsyslog at lists.adiscon.com/msg02505.html Now, I run Ubuntu, and the PrivDrop statements are in the rsyslog.conf by default on that distribution. The problem is further described in an Ubuntu bug (although the only Ubuntu-specific problem here is the PrivDrop statements being default on that distribution): https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/484336 The relevant lines in rsyslog.conf are: # # Set the default permissions for all log files. # $FileOwner syslog $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 $PrivDropToUser syslog $PrivDropToGroup syslog What happens is rsyslog is able to create the dynamic files, but it cannot access them to write to them, as described in the emails earlier on the list. I found that when I created a directory for these files, with 755 permissions owned by syslog and group syslog. The files would get created with 640 permissions owned by syslog:syslog and yet rsyslog would not be able to write to them. Rather than lose the safety provided by PrivDrop I found, based on the bug report above, that all you have to do is change the group to adm and it works: # # Set the default permissions for all log files. # $FileOwner syslog $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 $PrivDropToUser syslog $PrivDropToGroup adm Then the log files end up being owned by syslog:adm instead of syslog:syslog and rsyslog is able to write to them. I am not sure why this works. What's even more puzzling is that at least on my system (Ubuntu 9.10) syslog is not part of the adm group at all. I'm guessing that when you call the function to drop privileges to a group it doesn't care whether the user you drop to is part of the group you drop to. It is funny though. Anyway I am sending this out in hope that others might benefit from not having to completely dump PrivDrop, and that maybe some light will be shed on why this mechanism is not working properly in this case. It does not make sense that having the right owner still does not result in being able to write to and open files, and that you have to change the group to adm. It seems to me that there is some problem internal to rsyslog that is causing this to happen. From tbergfeld at hq.adiscon.com Fri Apr 9 14:46:08 2010 From: tbergfeld at hq.adiscon.com (Tom Bergfeld) Date: Fri, 9 Apr 2010 14:46:08 +0200 Subject: [rsyslog] rsyslog 5.5.3 (devel) released Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103C2A@GRFEXC.intern.adiscon.com> Hi all, We have just released rsyslog 5.5.3, a member of the devel branch. This is a bug-fixing release containing some important fixes and also the added basic but functional support for Solaris. Furthermore there are some imported patches from 4.6.0. It is a recommended update for all users of the devel branch. See Changelog for more details. ChangeLog: http://www.rsyslog.com/Article450.phtml Download: http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-199.phtml As always, feedback is appreciated. Best regards, Tom Bergfeld -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com From tbergfeld at hq.adiscon.com Wed Apr 14 16:46:52 2010 From: tbergfeld at hq.adiscon.com (Tom Bergfeld) Date: Wed, 14 Apr 2010 16:46:52 +0200 Subject: [rsyslog] rsyslog 4.7.0 (v4-devel) released Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103C74@GRFEXC.intern.adiscon.com> Hi all, We have just released rsyslog 4.7.0, a member of the v4-devel branch. This release offers Solaris support and also some fixes and enhancements. All the details you will find in 'Rainer's Blog' http://blog.gerhards.net/2010/04/v4-devel-is-back-again.html and of course in the Changelog. ChangeLog: http://www.rsyslog.com/Article453.phtml Download: http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-200.phtml As always, feedback is appreciated. Best regards, Tom Bergfeld -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com From kristian.jones at ntlworld.com Mon Apr 19 11:24:20 2010 From: kristian.jones at ntlworld.com (kristian.jones at ntlworld.com) Date: Mon, 19 Apr 2010 10:24:20 +0100 Subject: [rsyslog] iptables and centralised logs with rsyslog and UDP Message-ID: <20100419102420.T3NO6.126539.root@web01-winn.ispmail.private.ntl.com> Hi All, I have a problem that I'm not sure how to get around. I have 3 machines, a client, a firewall and a log store. The firewall is Linux running iptables. The client and log store are on different networks (X.X.4.X) and (X.X.5.X). The firewall is used to bridge these networks. I've configured rsyslog on the client (.4.) to send messages to the log store (.5.) I've also configured a template on the log store to print the $fromhost-ip and original raw message and I'm printing everything (*.*) to the log files. When the firewall rewrites the source address (so they appear to be coming from the .5.x network), the messages get logged. If I leave the source address alone, the messages disappear. I know the packets are arriving at the log store with both configurations because I can see this with TCPDUMP on the log store. On the firewall I have the following configuration that I've put together. iptables -A POSTROUTING -t nat -o eth1 -j ACCEPT iptables -A PREROUTING -t nat -i -p udp --dport 514 -j DNAT --to-destination X.X.5.X (On my actual config the Xs are not blanked out). Unfortunately with this rule in place I do not see anything in the log file. Changing the first line of the iptables config to iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE means that I can now see output getting to my log files but the ipaddress is incorrect. Is this a bug? or Is rsyslog doing some intelligent work under the hood to detect ip address spoofing? I'm using ubuntu server 9.10. Unfortunately using the hostname instead of the ipaddress in my case is not an option Hope someone can help Kris From epiphani at gmail.com Mon Apr 19 14:24:51 2010 From: epiphani at gmail.com (Aaron Wiebe) Date: Mon, 19 Apr 2010 08:24:51 -0400 Subject: [rsyslog] iptables and centralised logs with rsyslog and UDP In-Reply-To: <20100419102420.T3NO6.126539.root@web01-winn.ispmail.private.ntl.com> References: <20100419102420.T3NO6.126539.root@web01-winn.ispmail.private.ntl.com> Message-ID: Kris, it sounds as though your iptables rules aren't working very well for you. I suggest you set up wireshark or tcpdump on the log host machine and run the test again - I bet you would find that the traffic isn't making it. In the case that the IP isn't rewritten, that is expected. You're doing NAT, so rsyslog would have no other detail about the remote host you are originally delivering the data from. At this point I think most of your problems are iptables related, and not really rsyslog related. -Aaron On Mon, Apr 19, 2010 at 5:24 AM, wrote: > Hi All, > > I have a problem that I'm not sure how to get around. > > I have 3 machines, a client, a firewall and a log store. The firewall is Linux running iptables. The client and log store are on different networks (X.X.4.X) and (X.X.5.X). The firewall is used to bridge these networks. > > I've configured rsyslog on the client (.4.) to send messages to the log store (.5.) I've also configured a template on the log store to print the $fromhost-ip and original raw message and I'm printing everything (*.*) to the log files. > > When the firewall rewrites the source address (so they appear to be coming from the .5.x network), the messages get logged. If I leave the source address alone, the messages disappear. I know the packets are arriving at the log store with both configurations because I can see this with TCPDUMP on the log store. > > On the firewall I have the following configuration that I've put together. > > iptables -A POSTROUTING -t nat -o eth1 -j ACCEPT > iptables -A PREROUTING -t nat -i -p udp --dport 514 -j DNAT --to-destination X.X.5.X > > (On my actual config the Xs are not blanked out). > > Unfortunately with this rule in place I do not see anything in the log file. > > Changing the first line of the iptables config to > > iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE > > means that I can now see output getting to my log files but the ipaddress is incorrect. > > Is this a bug? or Is rsyslog doing some intelligent work under the hood to detect ip address spoofing? I'm using ubuntu server 9.10. Unfortunately using the hostname instead of the ipaddress in my case is not an option > > Hope someone can help > Kris > > > > > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From kristian.jones at ntlworld.com Mon Apr 19 16:05:26 2010 From: kristian.jones at ntlworld.com (kristian.jones at ntlworld.com) Date: Mon, 19 Apr 2010 15:05:26 +0100 Subject: [rsyslog] iptables and centralised logs with rsyslog and UDP In-Reply-To: Message-ID: <20100419150526.JOYOF.92148.root@web02-winn.ispmail.private.ntl.com> Hi Aaron, I've ran tcpdump on the log store (not the client) and I can see the packets hitting the server, it seems to be rsyslog thats not picking them up. Using tcpdump and the first iptables config, gives the correct ip address when tcpdump is run on the log store, but no message is shown in the log files. Using tcpdump and the second iptables config, gives the ip address of firewall when tcpdump is run on the log store and the message appears in log file on disk. Hopefully that makes it a little more clear but apologies if I misunderstood the reply Thanks Kris ---- Aaron Wiebe wrote: > Kris, it sounds as though your iptables rules aren't working very > well for you. I suggest you set up wireshark or tcpdump on the log > host machine and run the test again - I bet you would find that the > traffic isn't making it. In the case that the IP isn't rewritten, > that is expected. You're doing NAT, so rsyslog would have no other > detail about the remote host you are originally delivering the data > from. > > At this point I think most of your problems are iptables related, and > not really rsyslog related. > > -Aaron > > On Mon, Apr 19, 2010 at 5:24 AM, wrote: > > Hi All, > > > > I have a problem that I'm not sure how to get around. > > > > I have 3 machines, a client, a firewall and a log store. The firewall is Linux running iptables. The client and log store are on different networks (X.X.4.X) and (X.X.5.X). The firewall is used to bridge these networks. > > > > I've configured rsyslog on the client (.4.) to send messages to the log store (.5.) I've also configured a template on the log store to print the $fromhost-ip and original raw message and I'm printing everything (*.*) to the log files. > > > > When the firewall rewrites the source address (so they appear to be coming from the .5.x network), the messages get logged. If I leave the source address alone, the messages disappear. I know the packets are arriving at the log store with both configurations because I can see this with TCPDUMP on the log store. > > > > On the firewall I have the following configuration that I've put together. > > > > iptables -A POSTROUTING -t nat -o eth1 -j ACCEPT > > iptables -A PREROUTING -t nat -i -p udp --dport 514 -j DNAT --to-destination X.X.5.X > > > > (On my actual config the Xs are not blanked out). > > > > Unfortunately with this rule in place I do not see anything in the log file. > > > > Changing the first line of the iptables config to > > > > iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE > > > > means that I can now see output getting to my log files but the ipaddress is incorrect. > > > > Is this a bug? or Is rsyslog doing some intelligent work under the hood to detect ip address spoofing? I'm using ubuntu server 9.10. Unfortunately using the hostname instead of the ipaddress in my case is not an option > > > > Hope someone can help > > Kris > > > > > > > > > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From epiphani at gmail.com Mon Apr 19 16:13:30 2010 From: epiphani at gmail.com (Aaron Wiebe) Date: Mon, 19 Apr 2010 10:13:30 -0400 Subject: [rsyslog] iptables and centralised logs with rsyslog and UDP In-Reply-To: <20100419150526.JOYOF.92148.root@web02-winn.ispmail.private.ntl.com> References: <20100419150526.JOYOF.92148.root@web02-winn.ispmail.private.ntl.com> Message-ID: Can you provide more details about what you see in tcpdump and what your configuration of rsyslog is? Aaron On Mon, Apr 19, 2010 at 10:05 AM, wrote: > Hi Aaron, > I've ran tcpdump on the log store (not the client) and I can see the packets hitting the server, it seems to be rsyslog thats not picking them up. > > Using tcpdump and the first iptables config, gives the correct ip address when tcpdump is run on the log store, but no message is shown in the log files. > > Using tcpdump and the second iptables config, gives the ip address of firewall when tcpdump is run on the log store and the message appears in log file on disk. > > Hopefully that makes it a little more clear but apologies if I misunderstood the reply > > Thanks > Kris > ---- Aaron Wiebe wrote: >> Kris, ?it sounds as though your iptables rules aren't working very >> well for you. ?I suggest you set up wireshark or tcpdump on the log >> host machine and run the test again - I bet you would find that the >> traffic isn't making it. ?In the case that the IP isn't rewritten, >> that is expected. ?You're doing NAT, so rsyslog would have no other >> detail about the remote host you are originally delivering the data >> from. >> >> At this point I think most of your problems are iptables related, and >> not really rsyslog related. >> >> -Aaron >> >> On Mon, Apr 19, 2010 at 5:24 AM, ? wrote: >> > Hi All, >> > >> > I have a problem that I'm not sure how to get around. >> > >> > I have 3 machines, a client, a firewall and a log store. The firewall is Linux running iptables. The client and log store are on different networks (X.X.4.X) and (X.X.5.X). The firewall is used to bridge these networks. >> > >> > I've configured rsyslog on the client (.4.) to send messages to the log store (.5.) I've also configured a template on the log store to print the $fromhost-ip and original raw message and I'm printing everything (*.*) to the log files. >> > >> > When the firewall rewrites the source address (so they appear to be coming from the .5.x network), the messages get logged. If I leave the source address alone, the messages disappear. I know the packets are arriving at the log store with both configurations because I can see this with TCPDUMP on the log store. >> > >> > On the firewall I have the following configuration that I've put together. >> > >> > iptables -A POSTROUTING -t nat -o eth1 -j ACCEPT >> > iptables -A PREROUTING -t nat -i -p udp --dport 514 -j DNAT --to-destination X.X.5.X >> > >> > (On my actual config the Xs are not blanked out). >> > >> > Unfortunately with this rule in place I do not see anything in the log file. >> > >> > Changing the first line of the iptables config to >> > >> > iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE >> > >> > means that I can now see output getting to my log files but the ipaddress is incorrect. >> > >> > Is this a bug? or Is rsyslog doing some intelligent work under the hood to detect ip address spoofing? I'm using ubuntu server 9.10. Unfortunately using the hostname instead of the ipaddress in my case is not an option >> > >> > Hope someone can help >> > Kris >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > rsyslog mailing list >> > http://lists.adiscon.net/mailman/listinfo/rsyslog >> > http://www.rsyslog.com >> > >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > > From david at lang.hm Mon Apr 19 18:57:48 2010 From: david at lang.hm (david at lang.hm) Date: Mon, 19 Apr 2010 09:57:48 -0700 (PDT) Subject: [rsyslog] iptables and centralised logs with rsyslog and UDP In-Reply-To: <20100419150526.JOYOF.92148.root@web02-winn.ispmail.private.ntl.com> References: <20100419150526.JOYOF.92148.root@web02-winn.ispmail.private.ntl.com> Message-ID: do you have a route from the box running rsyslog to the source IP addresses that the logs are comeing from? if you don't then even though you see them in a tcpdump, your applications will not see the packets (there is a config option in linux to disable this feature) David Lang On Mon, 19 Apr 2010, kristian.jones at ntlworld.com wrote: > Date: Mon, 19 Apr 2010 15:05:26 +0100 > From: kristian.jones at ntlworld.com > Reply-To: rsyslog-users > To: rsyslog-users > Subject: Re: [rsyslog] iptables and centralised logs with rsyslog and UDP > > Hi Aaron, > I've ran tcpdump on the log store (not the client) and I can see the packets hitting the server, it seems to be rsyslog thats not picking them up. > > Using tcpdump and the first iptables config, gives the correct ip address when tcpdump is run on the log store, but no message is shown in the log files. > > Using tcpdump and the second iptables config, gives the ip address of firewall when tcpdump is run on the log store and the message appears in log file on disk. > > Hopefully that makes it a little more clear but apologies if I misunderstood the reply > > Thanks > Kris > ---- Aaron Wiebe wrote: >> Kris, it sounds as though your iptables rules aren't working very >> well for you. I suggest you set up wireshark or tcpdump on the log >> host machine and run the test again - I bet you would find that the >> traffic isn't making it. In the case that the IP isn't rewritten, >> that is expected. You're doing NAT, so rsyslog would have no other >> detail about the remote host you are originally delivering the data >> from. >> >> At this point I think most of your problems are iptables related, and >> not really rsyslog related. >> >> -Aaron >> >> On Mon, Apr 19, 2010 at 5:24 AM, wrote: >>> Hi All, >>> >>> I have a problem that I'm not sure how to get around. >>> >>> I have 3 machines, a client, a firewall and a log store. The firewall is Linux running iptables. The client and log store are on different networks (X.X.4.X) and (X.X.5.X). The firewall is used to bridge these networks. >>> >>> I've configured rsyslog on the client (.4.) to send messages to the log store (.5.) I've also configured a template on the log store to print the $fromhost-ip and original raw message and I'm printing everything (*.*) to the log files. >>> >>> When the firewall rewrites the source address (so they appear to be coming from the .5.x network), the messages get logged. If I leave the source address alone, the messages disappear. I know the packets are arriving at the log store with both configurations because I can see this with TCPDUMP on the log store. >>> >>> On the firewall I have the following configuration that I've put together. >>> >>> iptables -A POSTROUTING -t nat -o eth1 -j ACCEPT >>> iptables -A PREROUTING -t nat -i -p udp --dport 514 -j DNAT --to-destination X.X.5.X >>> >>> (On my actual config the Xs are not blanked out). >>> >>> Unfortunately with this rule in place I do not see anything in the log file. >>> >>> Changing the first line of the iptables config to >>> >>> iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE >>> >>> means that I can now see output getting to my log files but the ipaddress is incorrect. >>> >>> Is this a bug? or Is rsyslog doing some intelligent work under the hood to detect ip address spoofing? I'm using ubuntu server 9.10. Unfortunately using the hostname instead of the ipaddress in my case is not an option >>> >>> Hope someone can help >>> Kris >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From kristian.jones at ntlworld.com Tue Apr 20 10:03:20 2010 From: kristian.jones at ntlworld.com (kristian.jones at ntlworld.com) Date: Tue, 20 Apr 2010 9:03:20 +0100 Subject: [rsyslog] iptables and centralised logs with rsyslog and UDP In-Reply-To: Message-ID: <20100420090320.SUDNV.155925.root@web05-winn.ispmail.private.ntl.com> Thanks David, Adding the routes solved my issue. Kris ---- david at lang.hm wrote: > do you have a route from the box running rsyslog to the source IP > addresses that the logs are comeing from? if you don't then even though > you see them in a tcpdump, your applications will not see the packets > (there is a config option in linux to disable this feature) > > David Lang > > On Mon, 19 Apr > 2010, kristian.jones at ntlworld.com wrote: > > > Date: Mon, 19 Apr 2010 15:05:26 +0100 > > From: kristian.jones at ntlworld.com > > Reply-To: rsyslog-users > > To: rsyslog-users > > Subject: Re: [rsyslog] iptables and centralised logs with rsyslog and UDP > > > > Hi Aaron, > > I've ran tcpdump on the log store (not the client) and I can see the packets hitting the server, it seems to be rsyslog thats not picking them up. > > > > Using tcpdump and the first iptables config, gives the correct ip address when tcpdump is run on the log store, but no message is shown in the log files. > > > > Using tcpdump and the second iptables config, gives the ip address of firewall when tcpdump is run on the log store and the message appears in log file on disk. > > > > Hopefully that makes it a little more clear but apologies if I misunderstood the reply > > > > Thanks > > Kris > > ---- Aaron Wiebe wrote: > >> Kris, it sounds as though your iptables rules aren't working very > >> well for you. I suggest you set up wireshark or tcpdump on the log > >> host machine and run the test again - I bet you would find that the > >> traffic isn't making it. In the case that the IP isn't rewritten, > >> that is expected. You're doing NAT, so rsyslog would have no other > >> detail about the remote host you are originally delivering the data > >> from. > >> > >> At this point I think most of your problems are iptables related, and > >> not really rsyslog related. > >> > >> -Aaron > >> > >> On Mon, Apr 19, 2010 at 5:24 AM, wrote: > >>> Hi All, > >>> > >>> I have a problem that I'm not sure how to get around. > >>> > >>> I have 3 machines, a client, a firewall and a log store. The firewall is Linux running iptables. The client and log store are on different networks (X.X.4.X) and (X.X.5.X). The firewall is used to bridge these networks. > >>> > >>> I've configured rsyslog on the client (.4.) to send messages to the log store (.5.) I've also configured a template on the log store to print the $fromhost-ip and original raw message and I'm printing everything (*.*) to the log files. > >>> > >>> When the firewall rewrites the source address (so they appear to be coming from the .5.x network), the messages get logged. If I leave the source address alone, the messages disappear. I know the packets are arriving at the log store with both configurations because I can see this with TCPDUMP on the log store. > >>> > >>> On the firewall I have the following configuration that I've put together. > >>> > >>> iptables -A POSTROUTING -t nat -o eth1 -j ACCEPT > >>> iptables -A PREROUTING -t nat -i -p udp --dport 514 -j DNAT --to-destination X.X.5.X > >>> > >>> (On my actual config the Xs are not blanked out). > >>> > >>> Unfortunately with this rule in place I do not see anything in the log file. > >>> > >>> Changing the first line of the iptables config to > >>> > >>> iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE > >>> > >>> means that I can now see output getting to my log files but the ipaddress is incorrect. > >>> > >>> Is this a bug? or Is rsyslog doing some intelligent work under the hood to detect ip address spoofing? I'm using ubuntu server 9.10. Unfortunately using the hostname instead of the ipaddress in my case is not an option > >>> > >>> Hope someone can help > >>> Kris > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> rsyslog mailing list > >>> http://lists.adiscon.net/mailman/listinfo/rsyslog > >>> http://www.rsyslog.com > >>> > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From tom at ng23.net Tue Apr 20 11:47:48 2010 From: tom at ng23.net (Tom Brown) Date: Tue, 20 Apr 2010 10:47:48 +0100 Subject: [rsyslog] Configuration Help Message-ID: Hi - i posted this on the forum but i wonder of the maillist gets more traffic I am sending syslog data from a number of hosts to a central rsyslog box and everything is working but i have a basic configuration query. I currently log to /logs///*.log which is working fine but i am lacking a parameter in each log. The logs are appearing in the correct directory but my munging scripts rely on knowing what host each log comes from but as this is not appearing in the actual log then this makes things difficult. Does anyone have any pointers for achieving that, right now an example of a log would be # cat 20100419--authpriv.log pam_unix(su-l:session): session closed for user root pam_unix(sshd:session): session closed for user XXXXXX and ideally this would read # cat 20100419--authpriv.log pam_unix(su-l:session): session closed for user root pam_unix(sshd:session): session closed for user XXXXXX thanks From david at lang.hm Tue Apr 20 18:50:08 2010 From: david at lang.hm (david at lang.hm) Date: Tue, 20 Apr 2010 09:50:08 -0700 (PDT) Subject: [rsyslog] Configuration Help In-Reply-To: References: Message-ID: On Tue, 20 Apr 2010, Tom Brown wrote: > Hi - i posted this on the forum but i wonder of the maillist gets more > traffic > > > I am sending syslog data from a number of hosts to a central rsyslog box and > everything is working but i have a basic configuration query. > I currently log to /logs///*.log which is working fine but i > am lacking a parameter in each log. The logs are appearing in the > correct directory but my munging scripts rely on knowing what > host each log comes from but as this is not appearing in the actual log then > this makes things difficult. Does anyone have any pointers for achieving > that, right now an example of a log would be > > # cat 20100419--authpriv.log > pam_unix(su-l:session): session closed for user root > pam_unix(sshd:session): session closed for user XXXXXX > > and ideally this would read > > # cat 20100419--authpriv.log > pam_unix(su-l:session): session closed for user root > pam_unix(sshd:session): session closed for user XXXXXX what is your current configuration? it sounds like you need to change the format string to include the hostname. David Lang From tom at ng23.net Tue Apr 20 19:18:50 2010 From: tom at ng23.net (Tom Brown) Date: Tue, 20 Apr 2010 18:18:50 +0100 Subject: [rsyslog] Configuration Help In-Reply-To: References: Message-ID: > > what is your current configuration? > > it sounds like you need to change the format string to include the > hostname. > > thanks for the response - i did not setup this system so am not hugely familiar with it however would i need to be looking at the Log processing templates or the Output filename templates or neither? Currently we have something like # Log processing templates $template fmtStripLeadingSpace,"%msg:R,ERE,1,DFLT: (.*)--end%\n" # Output filename templates $template SystemLogFile,"/logs/syslog/%hostname%/%timereported:1:4:date-mysql%/%timereported:1:6:date-mysql%/%timereported:1:8:date-mysq l%/%timereported:1:8:date-mysql%-%hostname%-%syslogfacility-text%.log" any help is greatly appreciated thanks From david at lang.hm Tue Apr 20 19:35:40 2010 From: david at lang.hm (david at lang.hm) Date: Tue, 20 Apr 2010 10:35:40 -0700 (PDT) Subject: [rsyslog] Configuration Help In-Reply-To: References: Message-ID: On Tue, 20 Apr 2010, Tom Brown wrote: >> what is your current configuration? >> >> it sounds like you need to change the format string to include the >> hostname. >> >> > thanks for the response - i did not setup this system so am not hugely > familiar with it however would i need to be looking at the Log processing > templates or the Output filename templates or neither? it would be the log processing template > Currently we have something like > > > # Log processing templates > $template fmtStripLeadingSpace,"%msg:R,ERE,1,DFLT: (.*)--end%\n" try changing this to $template fmtStripLeadingSpace,"%hostname% %msg:R,ERE,1,DFLT: (.*)--end%\n" David Lang > > # Output filename templates > > $template > SystemLogFile,"/logs/syslog/%hostname%/%timereported:1:4:date-mysql%/%timereported:1:6:date-mysql%/%timereported:1:8:date-mysq > l%/%timereported:1:8:date-mysql%-%hostname%-%syslogfacility-text%.log" From tom at ng23.net Tue Apr 20 20:03:56 2010 From: tom at ng23.net (Tom Brown) Date: Tue, 20 Apr 2010 19:03:56 +0100 Subject: [rsyslog] Configuration Help In-Reply-To: References: Message-ID: > > # Log processing templates > > $template fmtStripLeadingSpace,"%msg:R,ERE,1,DFLT: (.*)--end%\n" > > try changing this to > > $template fmtStripLeadingSpace,"%hostname% %msg:R,ERE,1,DFLT: (.*)--end%\n" > many thanks - this resolved this issue From tbergfeld at hq.adiscon.com Thu Apr 22 15:57:52 2010 From: tbergfeld at hq.adiscon.com (Tom Bergfeld) Date: Thu, 22 Apr 2010 15:57:52 +0200 Subject: [rsyslog] rsyslog 4.7.1 (v4-devel) released Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CC8@GRFEXC.intern.adiscon.com> Hi all, We have just released rsyslog 4.7.1, a member of the v4-devel branch. This release improves the Solaris support. See Changelog for more details. ChangeLog: http://www.rsyslog.com/Article455.phtml Download: http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-201.phtml As always, feedback is appreciated. Best regards, Tom Bergfeld -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com From gbonser at seven.com Fri Apr 23 00:45:50 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 22 Apr 2010 15:45:50 -0700 Subject: [rsyslog] Large File Support Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE728B@RWC-EX1.corp.seven.com> I am having a strange issue. I am building rsyslog 4.6.2 on an amd64 system Configure says: rsyslog will be compiled with the following settings: Multithreading support enabled: yes Large file support enabled: yes But when I build it and do: /usr/src/rsyslog-4.6.2/tools> ./rsyslogd -v rsyslogd 4.6.2, compiled with: FEATURE_REGEXP: Yes FEATURE_LARGEFILE: No I also notice that configure reported: checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no Kernel 2.6.31 GCC 4.4.1 Libc6 2.10.1 I passed configure an explicit --enable-largefile Is there something else I must do in order to enable large file support? Thanks, George From david at lang.hm Fri Apr 23 02:45:15 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 22 Apr 2010 17:45:15 -0700 (PDT) Subject: [rsyslog] Large File Support In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE728B@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE08FE728B@RWC-EX1.corp.seven.com> Message-ID: On Thu, 22 Apr 2010, George Bonser wrote: > I am having a strange issue. I am building rsyslog 4.6.2 on an amd64 > system > > Configure says: > > rsyslog will be compiled with the following settings: > > Multithreading support enabled: yes > Large file support enabled: yes > > But when I build it and do: > > /usr/src/rsyslog-4.6.2/tools> ./rsyslogd -v > rsyslogd 4.6.2, compiled with: > FEATURE_REGEXP: Yes > FEATURE_LARGEFILE: No > > I also notice that configure reported: > > checking for special C compiler options needed for large files... no > checking for _FILE_OFFSET_BITS value needed for large files... no > > Kernel 2.6.31 > GCC 4.4.1 > Libc6 2.10.1 > > I passed configure an explicit --enable-largefile > > Is there something else I must do in order to enable large file support? 'large file support' is a work-around needed on 32 bit systems to handle files larger than 2G, on 64 bit systems it's just not needed. relax and enjoy your more advanced system ;-) David Lang From gbonser at seven.com Fri Apr 23 07:40:32 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 22 Apr 2010 22:40:32 -0700 Subject: [rsyslog] Large File Support References: <5A6D953473350C4B9995546AFE9939EE08FE728B@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE729A@RWC-EX1.corp.seven.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > > 'large file support' is a work-around needed on 32 bit systems to > handle > files larger than 2G, on 64 bit systems it's just not needed. > > relax and enjoy your more advanced system ;-) > > David Lang Hmm, ok, but when I build the Ubuntu 4.2.0 package, it does build it with such support and I can't see where any special parameter has been passed in order to do that. Just want to make sure I don't break anything trying to upgrade to 4.6.x From rgerhards at hq.adiscon.com Fri Apr 23 08:09:27 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 23 Apr 2010 08:09:27 +0200 Subject: [rsyslog] Large File Support References: <5A6D953473350C4B9995546AFE9939EE08FE728B@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE729A@RWC-EX1.corp.seven.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CCA@GRFEXC.intern.adiscon.com> > > 'large file support' is a work-around needed on 32 bit systems to > > handle > > files larger than 2G, on 64 bit systems it's just not needed. > > > > relax and enjoy your more advanced system ;-) > > > > David Lang > > Hmm, ok, but when I build the Ubuntu 4.2.0 package, it does build it > with such support and I can't see where any special parameter has been > passed in order to do that. > > Just want to make sure I don't break anything trying to upgrade to > 4.6.x You may be interested in this bug tracker, I guess a side-effect is what you see: http://bugzilla.adiscon.com/show_bug.cgi?id=182 Rainer From ralph at crongeyer.com Sat Apr 24 16:20:03 2010 From: ralph at crongeyer.com (Ralph Crongeyer) Date: Sat, 24 Apr 2010 10:20:03 -0400 Subject: [rsyslog] High cpu usage - rsyslog 5.4.0. In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103BBC@GRFEXC.intern.adiscon.com> References: <5fa6e0144d8003c7c72edff17f9f1675@webmail.crongeyer.com> <9B6E2A8877C38245BFB15CC491A11DA7103702@GRFEXC.intern.adiscon.com> <4BAF67C0.4000506@crongeyer.com> <4BAF710E.8080506@crongeyer.com><4BAF8773.1020000@crongeyer.com> <9B6E2A8877C38245BFB15CC491A11DA7103BAA@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103BBC@GRFEXC.intern.adiscon.com> Message-ID: <4BD2FE13.6030108@crongeyer.com> All, Sorry for the very long time for the response. I was on vaca in Mexico and had emergency surgery, I'm back now and ok. Did the fixes get merged into the 5.4.0 package? Or does it need more testing? Thanks, Ralph Rainer Gerhards wrote: > I managed to merge the v4 changes into v5-stable. Can you pull from it's git > head (git.adiscon.com/git/rsyslog.gig) and check if it works? Or do you need > a release tarball. > > Note that I need to finally fix an issue in v4 before (the released version > has an interim/work-around fix) before I can take up more work on v5, but > chances are not too bad that the issue is fixed. > > The master branch will receive the new patches ASAP, but that merge is a > little bit more complicated. > > Rainer > > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards >> Sent: Monday, March 29, 2010 7:11 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] High cpu usage - rsyslog 5.4.0. >> >> Hi, >> >> thanks for the information. I have crafted a big patch package for v4 >> the >> last two weeks. I will try to merge it in to v5 this week (I guess this >> will >> be a bit harder than usual). It may fix the issue. >> >> If you have a moment or two, it would be interesting to know if 5.5.2 >> has the >> same problem. >> >> Rainer >> >> >>> -----Original Message----- >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>> bounces at lists.adiscon.com] On Behalf Of Ralph Crongeyer >>> Sent: Sunday, March 28, 2010 6:45 PM >>> To: rsyslog-users >>> Subject: Re: [rsyslog] High cpu usage - rsyslog 5.4.0. >>> >>> It's confirmed! >>> >>> I've been running for over an hour and a half now and: >>> load average: 0.06, 0.06, 0.02 >>> >>> Looks good so far. >>> >>> Let me know if you guys (Michael, Rainer) want me to run in debug >>> >> mode >> >>> without the lines commented out to see if I can catch the problem for >>> more troubleshooting. >>> >>> Thanks, >>> Ralph >>> >>> Ralph Crongeyer wrote: >>> >>>> Ok, >>>> I stoped rsyslog apt-get removed the 5.3.7 package, installed the >>>> >>> 5.4.0 >>> >>>> package: >>>> >>>> root at logs:/opt# aptitude show rsyslog >>>> Package: rsyslog >>>> State: installed >>>> Automatically installed: no >>>> Version: 5.4.0-1 >>>> Priority: extra >>>> Section: extra >>>> Maintainer: ralph at crongeyer.com >>>> Uncompressed Size: 3047k >>>> Depends: libc6 (>= 2.7-1), zlib1g (>= 1:1.1.4), lsb-base (>= 3.2- >>>> >> 14) >> >>>> Description: enhanced multi-threaded syslogd >>>> >>>> commented out the lines from rsyslog.conf: >>>> #daemon.*;mail.*;\ >>>> # news.err;\ >>>> # *.=debug;*.=info;\ >>>> # *.=notice;*.=warn |/dev/xconsole >>>> >>>> >>>> and restarted rsyslog: >>>> root at logs:/opt# /etc/init.d/rsyslog restart >>>> Stopping enhanced syslogd: rsyslogd. >>>> Starting enhanced syslogd: rsyslogd. >>>> >>>> I'll get back to you in about an hour. >>>> >>>> Thanks, >>>> Ralph >>>> >>>> Michael Biebl wrote: >>>> >>>> >>>>> 2010/3/28 Ralph Crongeyer : >>>>> >>>>> >>>>> >>>>>> I'm running Debian Lenny on both machines. >>>>>> >>>>>> >>>>>> >>>>> >>>>>> Is anyone else seeing high cpu loads with 5.4.0? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I can confirm his (on Debian unstable) and already notified Rainer >>>>> about this particular issue. >>>>> Some preliminary testing here seems to indicate it's an issue with >>>>> >>> pipes. >>> >>>>> When I removed >>>>> daemon.*;mail.*;\ >>>>> news.err;\ >>>>> *.=debug;*.=info;\ >>>>> *.=notice;*.=warn |/dev/xconsole >>>>> >>>>> from my rsyslog.conf, I could no longer reproduce the problem. >>>>> >>>>> Would be interesting to know, if you can confirm this. >>>>> >>>>> Cheers, >>>>> Michael >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> -- >>> Reminds me of my expedition into the wilds of Afghanistan. We lost >>> >> our >> >>> corkscrew and were compelled to live on food and water for several >>> days. - >>> WC Fields >>> >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > -- Reminds me of my expedition into the wilds of Afghanistan. We lost our corkscrew and were compelled to live on food and water for several days. - WC Fields From gbonser at seven.com Sat Apr 24 20:19:31 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 24 Apr 2010 11:19:31 -0700 Subject: [rsyslog] Syslog over SCTP? Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE7309@RWC-EX1.corp.seven.com> Has anyone experimented with using SCTP for logging to a remote host? It seems it might have some advantages over TCP and UDP for that purpose. http://www.ibm.com/developerworks/linux/library/l-sctp/ From gbonser at seven.com Sun Apr 25 04:29:42 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 24 Apr 2010 19:29:42 -0700 Subject: [rsyslog] Syslog over SCTP? References: <5A6D953473350C4B9995546AFE9939EE08FE7309@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE7318@RWC-EX1.corp.seven.com> What I had in mind was something like an SCTP stream for each log level or each facility, haven't decided which would be most useful. That prevents head-of-line blocking as happens in TCP. So, for example, if a buffer is full of DEBUG level messages, an ALERT level message would go immediately as it is in a different stream. A separate stream could be added for RELP messages (or something like RELP or maybe an extension of it) and all of these streams would be within a single SCTP connection. Or maybe you can send RELP-like messages back across each stream in the opposite direction but having an "out of band" control channel sounds like an interesting idea and something fairly easy to do with SCTP. I would also think this lends itself well to threading of the different streams with a different thread handling different log levels (or facilities but I think dividing among log levels is probably easier). On an SMP system, a remote host sending a lot of DEGUG level messages while it is being tested would bog down one thread but other messages would be processed separately without network head-of-line blocking or CPU blocking (disk contention would be a different story, though ;) > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Saturday, April 24, 2010 11:20 AM > To: rsyslog-users > Subject: [rsyslog] Syslog over SCTP? > > Has anyone experimented with using SCTP for logging to a remote host? > It seems it might have some advantages over TCP and UDP for that > purpose. > > http://www.ibm.com/developerworks/linux/library/l-sctp/ > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Sun Apr 25 04:31:33 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 24 Apr 2010 19:31:33 -0700 Subject: [rsyslog] Syslog over SCTP? References: <5A6D953473350C4B9995546AFE9939EE08FE7309@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE7319@RWC-EX1.corp.seven.com> Oh, an interesting (to me) tutorial is here: http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb/sctp_intro. html > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Saturday, April 24, 2010 11:20 AM > To: rsyslog-users > Subject: [rsyslog] Syslog over SCTP? > > Has anyone experimented with using SCTP for logging to a remote host? > It seems it might have some advantages over TCP and UDP for that > purpose. > > http://www.ibm.com/developerworks/linux/library/l-sctp/ > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Mon Apr 26 02:23:37 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 25 Apr 2010 17:23:37 -0700 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com> Can't bind to TCP socket. The tcp module loads but I noticed that it only tries to bind the socket AFTER it has dropped is privs so it can not bind to a socket less than 1024. UDP bind works as that seems to bind immediately after module load while the prog is still running as root. If I set a tcp port >1024, it works. Could this be a race between two threads where a different thread is setting the UID/GID and a different one is binding the connections and the UID gets changed before the binding thread has a chance to get the socket? Modules being loaded: 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' 9572.648645873:7f07c0a216f0: loading module '/usr/lib/rsyslog/imudp.so' 9572.648713628:7f07c0a216f0: source file imudp.c requested reference for module 'lmnet', reference count now 4 9572.648734955:7f07c0a216f0: module of type 0 being loaded. 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports at *:514. 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' 9572.648869611:7f07c0a216f0: loading module '/usr/lib/rsyslog/imtcp.so' 9572.648938665:7f07c0a216f0: source file imtcp.c requested reference for module 'lmnet', reference count now 5 9572.648953892:7f07c0a216f0: caller requested object 'netstrm', not found (iRet -3003) 9572.648968610:7f07c0a216f0: Requested to load module 'lmnetstrms' 9572.648979310:7f07c0a216f0: loading module '/usr/lib/rsyslog/lmnetstrms.so' 9572.649053366:7f07c0a216f0: module of type 2 being loaded. 9572.649068131:7f07c0a216f0: source file imtcp.c requested reference for module 'lmnetstrms', reference count now 1 9572.649079163:7f07c0a216f0: caller requested object 'tcps_sess', not found (iRet -3003) 9572.649095086:7f07c0a216f0: Requested to load module 'lmtcpsrv' 9572.649105485:7f07c0a216f0: loading module '/usr/lib/rsyslog/lmtcpsrv.so' 9572.649188177:7f07c0a216f0: source file tcps_sess.c requested reference for module 'lmnetstrms', reference count now 2 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested reference for module 'lmnet', reference count now 6 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested reference for module 'lmnetstrms', reference count now 3 9572.649231362:7f07c0a216f0: module of type 2 being loaded. 9572.649241801:7f07c0a216f0: source file imtcp.c requested reference for module 'lmtcpsrv', reference count now 1 9572.649252009:7f07c0a216f0: source file imtcp.c requested reference for module 'lmtcpsrv', reference count now 2 9572.649287366:7f07c0a216f0: module of type 0 being loaded. 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' 9572.649321373:7f07c0a216f0: cfline: '$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat' 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction on' 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' 9572.649703828:7f07c0a216f0: uid 101 obtained for user 'syslog' 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' 9572.649840237:7f07c0a216f0: umask set to 0022. 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' 9572.649885709:7f07c0a216f0: uid 101 obtained for user 'syslog' 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup syslog' 9572.649934688:7f07c0a216f0: gid 103 obtained for group 'syslog' 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig /etc/rsyslog.d/*.conf' 9572.650017305:7f07c0a216f0: requested to include config file '/etc/rsyslog.d/50-default.conf' 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* /var/log/auth.log' GID and UID being changed: 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, lenBuf 78 9572.671902407:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg rsyslogd's groupid changed to 103 9572.671920644:7f07c0a216f0: Message has legacy syslog format. 9572.671933956:7f07be402910: testing filter, f_pmask 1 9572.671947526:7f07be402910: testing filter, f_pmask 240 9572.671957623:7f07be402910: Called action, logging to builtin-pipe 9572.671969801:7f07be402910: extend buf to at least 16, done 128 9572.671982061:7f07be402910: (/dev/xconsole) 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 entries 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised worker start 9572.672059720:7f07be402910: Action requested to be suspended, done that. 9572.672085037:7f07be402910: main Q: entry deleted, state 0, size now 1 entries 9572.672099142:7f07c0a216f0: setuid(101): 0 9572.672122289:7f07be402910: testing filter, f_pmask 0 9572.672136161:7f07be402910: testing filter, f_pmask 255 9572.672147659:7f07be402910: Called action, logging to builtin-file 9572.672162158:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg rsyslogd's userid changed to 101 9572.672179992:7f07c0a216f0: Message has legacy syslog format. 9572.672192329:7f07be402910: extend buf to at least 138, done 256 9572.672200766:7f07be402910: file to log to: /var/log/syslog UDP socket bind succeeded but TCP bind fails: 9572.672546363:7f07c0a216f0: initialization completed, transitioning to regular run mode 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket 4 (IPv4/port 514). 9572.672576606:7f07bc3fe910: --------imUDP calling select, active file descriptors (max 4): 4 9572.672594858:7f07bdc01910: --------imuxsock calling select, active file descriptors (max 5): 3 5 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy 9572.672646478:7f07bbbfd910: caller requested object 'nsd_ptcp', not found (iRet -3003) 9572.672663716:7f07bbbfd910: Requested to load module 'lmnsd_ptcp' 9572.672671184:7f07bbbfd910: loading module '/usr/lib/rsyslog/lmnsd_ptcp.so' 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested reference for module 'lmnetstrms', reference count now 4 9572.672757197:7f07bbbfd910: module of type 2 being loaded. 9572.672763826:7f07bbbfd910: source file netstrms.c requested reference for module 'lmnsd_ptcp', reference count now 1 9572.672770522:7f07bbbfd910: creating tcp listen socket on port 514 9572.672803781:7f07bbbfd910: error 13 while binding tcp socketWe could initialize 0 TCP listen sockets out of 1 we recei ved - this may or may not be an error indication. 9572.672824933:7f07bbbfd910: No TCP listen sockets could successfully be initializedCalled LogError, msg: Could not crea te tcp listener, ignoring port 514. 9572.672844597:7f07bbbfd910: logmsg: flags 1, from 'trebuchet', msg Could not create tcp listener, ignoring port 514. [t ry http://www.rsyslog.com/e/2077 ] From rgerhards at hq.adiscon.com Mon Apr 26 08:18:27 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Apr 2010 08:18:27 +0200 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com> The privilege drop code is still a hack. It needs proper engineering (as stated in the doc). So it could very well be a race in this regard. On the other hand, it does not look so. Could you send me complete debug logs to my private email address both with and without privilege drop inside your config. Maybe it is a simple thing, then I could fix it without the large effort really required. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Monday, April 26, 2010 2:24 AM > To: rsyslog-users > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > Can't bind to TCP socket. The tcp module loads but I noticed that it > only tries to bind the socket AFTER it has dropped is privs so it can > not bind to a socket less than 1024. UDP bind works as that seems to > bind immediately after module load while the prog is still running as > root. If I set a tcp port >1024, it works. Could this be a race > between > two threads where a different thread is setting the UID/GID and a > different one is binding the connections and the UID gets changed > before > the binding thread has a chance to get the socket? > > Modules being loaded: > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' > 9572.648645873:7f07c0a216f0: loading module '/usr/lib/rsyslog/imudp.so' > 9572.648713628:7f07c0a216f0: source file imudp.c requested reference > for > module 'lmnet', reference count now 4 > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports at *:514. > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' > 9572.648869611:7f07c0a216f0: loading module '/usr/lib/rsyslog/imtcp.so' > 9572.648938665:7f07c0a216f0: source file imtcp.c requested reference > for > module 'lmnet', reference count now 5 > 9572.648953892:7f07c0a216f0: caller requested object 'netstrm', not > found (iRet -3003) > 9572.648968610:7f07c0a216f0: Requested to load module 'lmnetstrms' > 9572.648979310:7f07c0a216f0: loading module > '/usr/lib/rsyslog/lmnetstrms.so' > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > 9572.649068131:7f07c0a216f0: source file imtcp.c requested reference > for > module 'lmnetstrms', reference count now 1 > 9572.649079163:7f07c0a216f0: caller requested object 'tcps_sess', not > found (iRet -3003) > 9572.649095086:7f07c0a216f0: Requested to load module 'lmtcpsrv' > 9572.649105485:7f07c0a216f0: loading module > '/usr/lib/rsyslog/lmtcpsrv.so' > 9572.649188177:7f07c0a216f0: source file tcps_sess.c requested > reference > for module 'lmnetstrms', reference count now 2 > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested reference > for module 'lmnet', reference count now 6 > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested reference > for module 'lmnetstrms', reference count now 3 > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > 9572.649241801:7f07c0a216f0: source file imtcp.c requested reference > for > module 'lmtcpsrv', reference count now 1 > 9572.649252009:7f07c0a216f0: source file imtcp.c requested reference > for > module 'lmtcpsrv', reference count now 2 > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' > 9572.649321373:7f07c0a216f0: cfline: '$ActionFileDefaultTemplate > RSYSLOG_TraditionalFileFormat' > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction on' > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > 9572.649703828:7f07c0a216f0: uid 101 obtained for user 'syslog' > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > 9572.649840237:7f07c0a216f0: umask set to 0022. > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' > 9572.649885709:7f07c0a216f0: uid 101 obtained for user 'syslog' > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup syslog' > 9572.649934688:7f07c0a216f0: gid 103 obtained for group 'syslog' > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > /etc/rsyslog.d/*.conf' > 9572.650017305:7f07c0a216f0: requested to include config file > '/etc/rsyslog.d/50-default.conf' > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > /var/log/auth.log' > > GID and UID being changed: > > 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, lenBuf 78 > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg > rsyslogd's groupid changed to 103 > 9572.671920644:7f07c0a216f0: Message has legacy syslog format. > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > 9572.671957623:7f07be402910: Called action, logging to builtin-pipe > 9572.671969801:7f07be402910: extend buf to at least 16, done 128 > 9572.671982061:7f07be402910: (/dev/xconsole) > 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 entries > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised worker start > 9572.672059720:7f07be402910: Action requested to be suspended, done > that. > 9572.672085037:7f07be402910: main Q: entry deleted, state 0, size now 1 > entries > 9572.672099142:7f07c0a216f0: setuid(101): 0 > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > 9572.672147659:7f07be402910: Called action, logging to builtin-file > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg > rsyslogd's userid changed to 101 > 9572.672179992:7f07c0a216f0: Message has legacy syslog format. > 9572.672192329:7f07be402910: extend buf to at least 138, done 256 > 9572.672200766:7f07be402910: file to log to: /var/log/syslog > > UDP socket bind succeeded but TCP bind fails: > > 9572.672546363:7f07c0a216f0: initialization completed, transitioning to > regular run mode > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket 4 > (IPv4/port 514). > 9572.672576606:7f07bc3fe910: --------imUDP calling select, active file > descriptors (max 4): 4 > 9572.672594858:7f07bdc01910: --------imuxsock calling select, active > file descriptors (max 5): 3 5 > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy > 9572.672646478:7f07bbbfd910: caller requested object 'nsd_ptcp', not > found (iRet -3003) > 9572.672663716:7f07bbbfd910: Requested to load module 'lmnsd_ptcp' > 9572.672671184:7f07bbbfd910: loading module > '/usr/lib/rsyslog/lmnsd_ptcp.so' > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested reference > for module 'lmnetstrms', reference count now 4 > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > 9572.672763826:7f07bbbfd910: source file netstrms.c requested reference > for module 'lmnsd_ptcp', reference count now 1 > 9572.672770522:7f07bbbfd910: creating tcp listen socket on port 514 > 9572.672803781:7f07bbbfd910: error 13 while binding tcp socketWe could > initialize 0 TCP listen sockets out of 1 we recei > ved - this may or may not be an error indication. > 9572.672824933:7f07bbbfd910: No TCP listen sockets could successfully > be > initializedCalled LogError, msg: Could not crea > te tcp listener, ignoring port 514. > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from 'trebuchet', msg > Could not create tcp listener, ignoring port 514. [t > ry http://www.rsyslog.com/e/2077 ] > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Apr 26 08:59:50 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Apr 2010 08:59:50 +0200 Subject: [rsyslog] Syslog over SCTP? References: <5A6D953473350C4B9995546AFE9939EE08FE7309@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE7318@RWC-EX1.corp.seven.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CDF@GRFEXC.intern.adiscon.com> This is interesting, but unfortunately I lack time to look deeper into it. I just wonder if another - maybe more flexible - approach would be to add a priority queue queueing mode. In that, we would enqueue messages based on priority and process higher priority messages before lower priority ones. That would work with all transports (and all other outout plugins) and solved the need you have. Am I right here? Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Sunday, April 25, 2010 4:30 AM > To: rsyslog-users > Subject: Re: [rsyslog] Syslog over SCTP? > > What I had in mind was something like an SCTP stream for each log level > or each facility, haven't decided which would be most useful. That > prevents head-of-line blocking as happens in TCP. So, for example, if > a > buffer is full of DEBUG level messages, an ALERT level message would go > immediately as it is in a different stream. A separate stream could be > added for RELP messages (or something like RELP or maybe an extension > of > it) and all of these streams would be within a single SCTP connection. > Or maybe you can send RELP-like messages back across each stream in the > opposite direction but having an "out of band" control channel sounds > like an interesting idea and something fairly easy to do with SCTP. > > I would also think this lends itself well to threading of the different > streams with a different thread handling different log levels (or > facilities but I think dividing among log levels is probably easier). > On an SMP system, a remote host sending a lot of DEGUG level messages > while it is being tested would bog down one thread but other messages > would be processed separately without network head-of-line blocking or > CPU blocking (disk contention would be a different story, though ;) > > > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > Sent: Saturday, April 24, 2010 11:20 AM > > To: rsyslog-users > > Subject: [rsyslog] Syslog over SCTP? > > > > Has anyone experimented with using SCTP for logging to a remote host? > > It seems it might have some advantages over TCP and UDP for that > > purpose. > > > > http://www.ibm.com/developerworks/linux/library/l-sctp/ > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Mon Apr 26 09:44:20 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 26 Apr 2010 00:44:20 -0700 Subject: [rsyslog] Syslog over SCTP? References: <5A6D953473350C4B9995546AFE9939EE08FE7309@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE08FE7318@RWC-EX1.corp.seven.com> <9B6E2A8877C38245BFB15CC491A11DA7103CDF@GRFEXC.intern.adiscon.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE732B@RWC-EX1.corp.seven.com> Well, it isn't really prioritization that I am worried about. For example, if I have a developer running something in DEBUG, that is actually quite high priority for him. With TCP, there is no way to separate them at the system OS tcp buffer level without opening several concurrent TCP connections, basically one connection for each ActionQueue. TCP has only one output buffer per connection while SCTP can have several parallel streams operating over a single socket connection. Maybe I will hack on it when I get time. If I have sent a bunch of DEBUG level messages, they are in the TCP/IP output buffer. If I want to send a USER level message, it gets put in the queue after the DEBUG messages I have already "sent". With SCTP, the streams are handled in round-robin fashion. If the packet is flagged for "out of order delivery", one could potentially send a higher priority packet NOW despite a lot of lower priority messages being sent. The problem with prioritization is that higher priority traffic can starve "lower" priority traffic of service. You can already easily accomplish the prioritization with the exsting Linux ToS bits. By default Linux has four classes of traffic with the pfifo_fast qdisc. If you mark the packets accordingly, you can already get higher priority service for certain traffic (marking ToS 0 for EMERGENCY, for example). The problem with that is a program spewing a bunch of USER messages can block DEBUG messages if USER is placed at a higher priority. What I had in mind was basically a separate worker thread for each log level. This prevents any of them blocking the others. George > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Monday, April 26, 2010 12:00 AM > To: rsyslog-users > Subject: Re: [rsyslog] Syslog over SCTP? > > This is interesting, but unfortunately I lack time to look deeper into > it. > > I just wonder if another - maybe more flexible - approach would be to > add a > priority queue queueing mode. In that, we would enqueue messages based > on > priority and process higher priority messages before lower priority > ones. > That would work with all transports (and all other outout plugins) and > solved > the need you have. > > Am I right here? > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > Sent: Sunday, April 25, 2010 4:30 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Syslog over SCTP? > > > > What I had in mind was something like an SCTP stream for each log > level > > or each facility, haven't decided which would be most useful. That > > prevents head-of-line blocking as happens in TCP. So, for example, > if > > a > > buffer is full of DEBUG level messages, an ALERT level message would > go > > immediately as it is in a different stream. A separate stream could > be > > added for RELP messages (or something like RELP or maybe an extension > > of > > it) and all of these streams would be within a single SCTP > connection. > > Or maybe you can send RELP-like messages back across each stream in > the > > opposite direction but having an "out of band" control channel sounds > > like an interesting idea and something fairly easy to do with SCTP. > > > > I would also think this lends itself well to threading of the > different > > streams with a different thread handling different log levels (or > > facilities but I think dividing among log levels is probably easier). > > On an SMP system, a remote host sending a lot of DEGUG level messages > > while it is being tested would bog down one thread but other messages > > would be processed separately without network head-of-line blocking > or > > CPU blocking (disk contention would be a different story, though ;) > > > > > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > Sent: Saturday, April 24, 2010 11:20 AM > > > To: rsyslog-users > > > Subject: [rsyslog] Syslog over SCTP? > > > > > > Has anyone experimented with using SCTP for logging to a remote > host? > > > It seems it might have some advantages over TCP and UDP for that > > > purpose. > > > > > > http://www.ibm.com/developerworks/linux/library/l-sctp/ > > > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Mon Apr 26 10:09:45 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 26 Apr 2010 01:09:45 -0700 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com> <9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com> Oops, sorry, I did not mean to send that attachment to the list. > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Sunday, April 25, 2010 11:18 PM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > The privilege drop code is still a hack. It needs proper engineering > (as > stated in the doc). So it could very well be a race in this regard. On > the > other hand, it does not look so. Could you send me complete debug logs > to my > private email address both with and without privilege drop inside your > config. Maybe it is a simple thing, then I could fix it without the > large > effort really required. > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > Sent: Monday, April 26, 2010 2:24 AM > > To: rsyslog-users > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > > > Can't bind to TCP socket. The tcp module loads but I noticed that it > > only tries to bind the socket AFTER it has dropped is privs so it can > > not bind to a socket less than 1024. UDP bind works as that seems to > > bind immediately after module load while the prog is still running as > > root. If I set a tcp port >1024, it works. Could this be a race > > between > > two threads where a different thread is setting the UID/GID and a > > different one is binding the connections and the UID gets changed > > before > > the binding thread has a chance to get the socket? > > > > Modules being loaded: > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' > > 9572.648645873:7f07c0a216f0: loading module > '/usr/lib/rsyslog/imudp.so' > > 9572.648713628:7f07c0a216f0: source file imudp.c requested reference > > for > > module 'lmnet', reference count now 4 > > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports at > *:514. > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' > > 9572.648869611:7f07c0a216f0: loading module > '/usr/lib/rsyslog/imtcp.so' > > 9572.648938665:7f07c0a216f0: source file imtcp.c requested reference > > for > > module 'lmnet', reference count now 5 > > 9572.648953892:7f07c0a216f0: caller requested object 'netstrm', not > > found (iRet -3003) > > 9572.648968610:7f07c0a216f0: Requested to load module 'lmnetstrms' > > 9572.648979310:7f07c0a216f0: loading module > > '/usr/lib/rsyslog/lmnetstrms.so' > > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > > 9572.649068131:7f07c0a216f0: source file imtcp.c requested reference > > for > > module 'lmnetstrms', reference count now 1 > > 9572.649079163:7f07c0a216f0: caller requested object 'tcps_sess', not > > found (iRet -3003) > > 9572.649095086:7f07c0a216f0: Requested to load module 'lmtcpsrv' > > 9572.649105485:7f07c0a216f0: loading module > > '/usr/lib/rsyslog/lmtcpsrv.so' > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c requested > > reference > > for module 'lmnetstrms', reference count now 2 > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested reference > > for module 'lmnet', reference count now 6 > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested reference > > for module 'lmnetstrms', reference count now 3 > > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > > 9572.649241801:7f07c0a216f0: source file imtcp.c requested reference > > for > > module 'lmtcpsrv', reference count now 1 > > 9572.649252009:7f07c0a216f0: source file imtcp.c requested reference > > for > > module 'lmtcpsrv', reference count now 2 > > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' > > 9572.649321373:7f07c0a216f0: cfline: '$ActionFileDefaultTemplate > > RSYSLOG_TraditionalFileFormat' > > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction on' > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user 'syslog' > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user 'syslog' > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup syslog' > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group 'syslog' > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > /etc/rsyslog.d/*.conf' > > 9572.650017305:7f07c0a216f0: requested to include config file > > '/etc/rsyslog.d/50-default.conf' > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > /var/log/auth.log' > > > > GID and UID being changed: > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, lenBuf > 78 > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg > > rsyslogd's groupid changed to 103 > > 9572.671920644:7f07c0a216f0: Message has legacy syslog format. > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > 9572.671957623:7f07be402910: Called action, logging to builtin-pipe > > 9572.671969801:7f07be402910: extend buf to at least 16, done 128 > > 9572.671982061:7f07be402910: (/dev/xconsole) > > 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 entries > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised worker start > > 9572.672059720:7f07be402910: Action requested to be suspended, done > > that. > > 9572.672085037:7f07be402910: main Q: entry deleted, state 0, size now > 1 > > entries > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > 9572.672147659:7f07be402910: Called action, logging to builtin-file > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg > > rsyslogd's userid changed to 101 > > 9572.672179992:7f07c0a216f0: Message has legacy syslog format. > > 9572.672192329:7f07be402910: extend buf to at least 138, done 256 > > 9572.672200766:7f07be402910: file to log to: /var/log/syslog > > > > UDP socket bind succeeded but TCP bind fails: > > > > 9572.672546363:7f07c0a216f0: initialization completed, transitioning > to > > regular run mode > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket 4 > > (IPv4/port 514). > > 9572.672576606:7f07bc3fe910: --------imUDP calling select, active > file > > descriptors (max 4): 4 > > 9572.672594858:7f07bdc01910: --------imuxsock calling select, active > > file descriptors (max 5): 3 5 > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy > > 9572.672646478:7f07bbbfd910: caller requested object 'nsd_ptcp', not > > found (iRet -3003) > > 9572.672663716:7f07bbbfd910: Requested to load module 'lmnsd_ptcp' > > 9572.672671184:7f07bbbfd910: loading module > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested > reference > > for module 'lmnetstrms', reference count now 4 > > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > > 9572.672763826:7f07bbbfd910: source file netstrms.c requested > reference > > for module 'lmnsd_ptcp', reference count now 1 > > 9572.672770522:7f07bbbfd910: creating tcp listen socket on port 514 > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp socketWe > could > > initialize 0 TCP listen sockets out of 1 we recei > > ved - this may or may not be an error indication. > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could successfully > > be > > initializedCalled LogError, msg: Could not crea > > te tcp listener, ignoring port 514. > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from 'trebuchet', msg > > Could not create tcp listener, ignoring port 514. [t > > ry http://www.rsyslog.com/e/2077 ] > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Apr 26 10:37:13 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Apr 2010 10:37:13 +0200 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com> <5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com> No problem -- the mailing list processor held it due to size constrainst (and I rejected it now). The size restriction was actually the prime issue why I requested it to go to my private mail. So: nothing bad has happened ;) I'll try to look at the log asap and let you know what I find. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Monday, April 26, 2010 10:10 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > Oops, sorry, I did not mean to send that attachment to the list. > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > Sent: Sunday, April 25, 2010 11:18 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > non-root. > > > > The privilege drop code is still a hack. It needs proper engineering > > (as > > stated in the doc). So it could very well be a race in this regard. > On > > the > > other hand, it does not look so. Could you send me complete debug > logs > > to my > > private email address both with and without privilege drop inside > your > > config. Maybe it is a simple thing, then I could fix it without the > > large > > effort really required. > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > Sent: Monday, April 26, 2010 2:24 AM > > > To: rsyslog-users > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > > > > > Can't bind to TCP socket. The tcp module loads but I noticed that > it > > > only tries to bind the socket AFTER it has dropped is privs so it > can > > > not bind to a socket less than 1024. UDP bind works as that seems > to > > > bind immediately after module load while the prog is still running > as > > > root. If I set a tcp port >1024, it works. Could this be a race > > > between > > > two threads where a different thread is setting the UID/GID and a > > > different one is binding the connections and the UID gets changed > > > before > > > the binding thread has a chance to get the socket? > > > > > > Modules being loaded: > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' > > > 9572.648645873:7f07c0a216f0: loading module > > '/usr/lib/rsyslog/imudp.so' > > > 9572.648713628:7f07c0a216f0: source file imudp.c requested > reference > > > for > > > module 'lmnet', reference count now 4 > > > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports at > > *:514. > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' > > > 9572.648869611:7f07c0a216f0: loading module > > '/usr/lib/rsyslog/imtcp.so' > > > 9572.648938665:7f07c0a216f0: source file imtcp.c requested > reference > > > for > > > module 'lmnet', reference count now 5 > > > 9572.648953892:7f07c0a216f0: caller requested object 'netstrm', not > > > found (iRet -3003) > > > 9572.648968610:7f07c0a216f0: Requested to load module 'lmnetstrms' > > > 9572.648979310:7f07c0a216f0: loading module > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > > > 9572.649068131:7f07c0a216f0: source file imtcp.c requested > reference > > > for > > > module 'lmnetstrms', reference count now 1 > > > 9572.649079163:7f07c0a216f0: caller requested object 'tcps_sess', > not > > > found (iRet -3003) > > > 9572.649095086:7f07c0a216f0: Requested to load module 'lmtcpsrv' > > > 9572.649105485:7f07c0a216f0: loading module > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c requested > > > reference > > > for module 'lmnetstrms', reference count now 2 > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested > reference > > > for module 'lmnet', reference count now 6 > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested > reference > > > for module 'lmnetstrms', reference count now 3 > > > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > > > 9572.649241801:7f07c0a216f0: source file imtcp.c requested > reference > > > for > > > module 'lmtcpsrv', reference count now 1 > > > 9572.649252009:7f07c0a216f0: source file imtcp.c requested > reference > > > for > > > module 'lmtcpsrv', reference count now 2 > > > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' > > > 9572.649321373:7f07c0a216f0: cfline: '$ActionFileDefaultTemplate > > > RSYSLOG_TraditionalFileFormat' > > > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction on' > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user 'syslog' > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user 'syslog' > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup syslog' > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group 'syslog' > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > /etc/rsyslog.d/*.conf' > > > 9572.650017305:7f07c0a216f0: requested to include config file > > > '/etc/rsyslog.d/50-default.conf' > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > /var/log/auth.log' > > > > > > GID and UID being changed: > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, > lenBuf > > 78 > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg > > > rsyslogd's groupid changed to 103 > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog format. > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > > 9572.671957623:7f07be402910: Called action, logging to builtin-pipe > > > 9572.671969801:7f07be402910: extend buf to at least 16, done 128 > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 > entries > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised worker > start > > > 9572.672059720:7f07be402910: Action requested to be suspended, done > > > that. > > > 9572.672085037:7f07be402910: main Q: entry deleted, state 0, size > now > > 1 > > > entries > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > > 9572.672147659:7f07be402910: Called action, logging to builtin-file > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg > > > rsyslogd's userid changed to 101 > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog format. > > > 9572.672192329:7f07be402910: extend buf to at least 138, done 256 > > > 9572.672200766:7f07be402910: file to log to: /var/log/syslog > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > transitioning > > to > > > regular run mode > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket 4 > > > (IPv4/port 514). > > > 9572.672576606:7f07bc3fe910: --------imUDP calling select, active > > file > > > descriptors (max 4): 4 > > > 9572.672594858:7f07bdc01910: --------imuxsock calling select, > active > > > file descriptors (max 5): 3 5 > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy > > > 9572.672646478:7f07bbbfd910: caller requested object 'nsd_ptcp', > not > > > found (iRet -3003) > > > 9572.672663716:7f07bbbfd910: Requested to load module 'lmnsd_ptcp' > > > 9572.672671184:7f07bbbfd910: loading module > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested > > reference > > > for module 'lmnetstrms', reference count now 4 > > > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > > > 9572.672763826:7f07bbbfd910: source file netstrms.c requested > > reference > > > for module 'lmnsd_ptcp', reference count now 1 > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket on port 514 > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp socketWe > > could > > > initialize 0 TCP listen sockets out of 1 we recei > > > ved - this may or may not be an error indication. > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could > successfully > > > be > > > initializedCalled LogError, msg: Could not crea > > > te tcp listener, ignoring port 514. > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from 'trebuchet', msg > > > Could not create tcp listener, ignoring port 514. [t > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Mon Apr 26 10:51:57 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 26 Apr 2010 01:51:57 -0700 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com> <9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE7330@RWC-EX1.corp.seven.com> I think the problem is that it spawns a new thread to load the udp and tcp modules and that should be done by the main thread so that it gets done in sequence before the privs are processed. > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Monday, April 26, 2010 1:37 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > No problem -- the mailing list processor held it due to size > constrainst (and > I rejected it now). The size restriction was actually the prime issue > why I > requested it to go to my private mail. So: nothing bad has happened ;) > > I'll try to look at the log asap and let you know what I find. > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > Sent: Monday, April 26, 2010 10:10 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > root. > > > > Oops, sorry, I did not mean to send that attachment to the list. > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > Sent: Sunday, April 25, 2010 11:18 PM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > non-root. > > > > > > The privilege drop code is still a hack. It needs proper > engineering > > > (as > > > stated in the doc). So it could very well be a race in this regard. > > On > > > the > > > other hand, it does not look so. Could you send me complete debug > > logs > > > to my > > > private email address both with and without privilege drop inside > > your > > > config. Maybe it is a simple thing, then I could fix it without the > > > large > > > effort really required. > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > Sent: Monday, April 26, 2010 2:24 AM > > > > To: rsyslog-users > > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > root. > > > > > > > > Can't bind to TCP socket. The tcp module loads but I noticed > that > > it > > > > only tries to bind the socket AFTER it has dropped is privs so it > > can > > > > not bind to a socket less than 1024. UDP bind works as that > seems > > to > > > > bind immediately after module load while the prog is still > running > > as > > > > root. If I set a tcp port >1024, it works. Could this be a race > > > > between > > > > two threads where a different thread is setting the UID/GID and a > > > > different one is binding the connections and the UID gets changed > > > > before > > > > the binding thread has a chance to get the socket? > > > > > > > > Modules being loaded: > > > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > > 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' > > > > 9572.648645873:7f07c0a216f0: loading module > > > '/usr/lib/rsyslog/imudp.so' > > > > 9572.648713628:7f07c0a216f0: source file imudp.c requested > > reference > > > > for > > > > module 'lmnet', reference count now 4 > > > > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports at > > > *:514. > > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > > 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' > > > > 9572.648869611:7f07c0a216f0: loading module > > > '/usr/lib/rsyslog/imtcp.so' > > > > 9572.648938665:7f07c0a216f0: source file imtcp.c requested > > reference > > > > for > > > > module 'lmnet', reference count now 5 > > > > 9572.648953892:7f07c0a216f0: caller requested object 'netstrm', > not > > > > found (iRet -3003) > > > > 9572.648968610:7f07c0a216f0: Requested to load module > 'lmnetstrms' > > > > 9572.648979310:7f07c0a216f0: loading module > > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > > > > 9572.649068131:7f07c0a216f0: source file imtcp.c requested > > reference > > > > for > > > > module 'lmnetstrms', reference count now 1 > > > > 9572.649079163:7f07c0a216f0: caller requested object 'tcps_sess', > > not > > > > found (iRet -3003) > > > > 9572.649095086:7f07c0a216f0: Requested to load module 'lmtcpsrv' > > > > 9572.649105485:7f07c0a216f0: loading module > > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c requested > > > > reference > > > > for module 'lmnetstrms', reference count now 2 > > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested > > reference > > > > for module 'lmnet', reference count now 6 > > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested > > reference > > > > for module 'lmnetstrms', reference count now 3 > > > > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > > > > 9572.649241801:7f07c0a216f0: source file imtcp.c requested > > reference > > > > for > > > > module 'lmtcpsrv', reference count now 1 > > > > 9572.649252009:7f07c0a216f0: source file imtcp.c requested > > reference > > > > for > > > > module 'lmtcpsrv', reference count now 2 > > > > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > > > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' > > > > 9572.649321373:7f07c0a216f0: cfline: '$ActionFileDefaultTemplate > > > > RSYSLOG_TraditionalFileFormat' > > > > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction on' > > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user 'syslog' > > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' > > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user 'syslog' > > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup syslog' > > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group 'syslog' > > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > > /etc/rsyslog.d/*.conf' > > > > 9572.650017305:7f07c0a216f0: requested to include config file > > > > '/etc/rsyslog.d/50-default.conf' > > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > > /var/log/auth.log' > > > > > > > > GID and UID being changed: > > > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, > > lenBuf > > > 78 > > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', > msg > > > > rsyslogd's groupid changed to 103 > > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog format. > > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > > > 9572.671957623:7f07be402910: Called action, logging to builtin- > pipe > > > > 9572.671969801:7f07be402910: extend buf to at least 16, done 128 > > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 > > entries > > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy > > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised worker > > start > > > > 9572.672059720:7f07be402910: Action requested to be suspended, > done > > > > that. > > > > 9572.672085037:7f07be402910: main Q: entry deleted, state 0, size > > now > > > 1 > > > > entries > > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > > > 9572.672147659:7f07be402910: Called action, logging to builtin- > file > > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', > msg > > > > rsyslogd's userid changed to 101 > > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog format. > > > > 9572.672192329:7f07be402910: extend buf to at least 138, done 256 > > > > 9572.672200766:7f07be402910: file to log to: /var/log/syslog > > > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > > transitioning > > > to > > > > regular run mode > > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket 4 > > > > (IPv4/port 514). > > > > 9572.672576606:7f07bc3fe910: --------imUDP calling select, active > > > file > > > > descriptors (max 4): 4 > > > > 9572.672594858:7f07bdc01910: --------imuxsock calling select, > > active > > > > file descriptors (max 5): 3 5 > > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy > > > > 9572.672646478:7f07bbbfd910: caller requested object 'nsd_ptcp', > > not > > > > found (iRet -3003) > > > > 9572.672663716:7f07bbbfd910: Requested to load module > 'lmnsd_ptcp' > > > > 9572.672671184:7f07bbbfd910: loading module > > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested > > > reference > > > > for module 'lmnetstrms', reference count now 4 > > > > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > > > > 9572.672763826:7f07bbbfd910: source file netstrms.c requested > > > reference > > > > for module 'lmnsd_ptcp', reference count now 1 > > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket on port > 514 > > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp socketWe > > > could > > > > initialize 0 TCP listen sockets out of 1 we recei > > > > ved - this may or may not be an error indication. > > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could > > successfully > > > > be > > > > initializedCalled LogError, msg: Could not crea > > > > te tcp listener, ignoring port 514. > > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from 'trebuchet', > msg > > > > Could not create tcp listener, ignoring port 514. [t > > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Apr 26 11:32:03 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Apr 2010 11:32:03 +0200 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com> <5A6D953473350C4B9995546AFE9939EE08FE7330@RWC-EX1.corp.seven.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CE3@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Monday, April 26, 2010 10:52 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > I think the problem is that it spawns a new thread to load the udp and > tcp modules and that should be done by the main thread so that it gets > done in sequence before the privs are processed. I think your analysis is right, this is where the race happens. However, the cure is far from being as simple as it sounds: you are actually recommending a full redesign of the input plugin interface. It would also have other implications, including a potential unacceptable startup delay. This is what I quoted with "a lot of work to do". So, unfortunately, it does not look like something I can fix quickly. Let me once again reiterate that the priv drop code is far from being a complete solution. I added the current code when I saw that it was easy to do and useful for some situations. We once had someone who was interested in sponsoring a complete implementation, but that did unfortunately not materialize. As I am currently short on time due to other work to do, I do not find sufficient time to look at this. It is far from being a trivial task, even though I hope to be able to do it without a full redesign. I still think it is 2+ weeks worth of work. Rainer > > > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > Sent: Monday, April 26, 2010 1:37 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > non-root. > > > > No problem -- the mailing list processor held it due to size > > constrainst (and > > I rejected it now). The size restriction was actually the prime issue > > why I > > requested it to go to my private mail. So: nothing bad has happened > ;) > > > > I'll try to look at the log asap and let you know what I find. > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > Sent: Monday, April 26, 2010 10:10 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > > root. > > > > > > Oops, sorry, I did not mean to send that attachment to the list. > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > Sent: Sunday, April 25, 2010 11:18 PM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > non-root. > > > > > > > > The privilege drop code is still a hack. It needs proper > > engineering > > > > (as > > > > stated in the doc). So it could very well be a race in this > regard. > > > On > > > > the > > > > other hand, it does not look so. Could you send me complete debug > > > logs > > > > to my > > > > private email address both with and without privilege drop inside > > > your > > > > config. Maybe it is a simple thing, then I could fix it without > the > > > > large > > > > effort really required. > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > Sent: Monday, April 26, 2010 2:24 AM > > > > > To: rsyslog-users > > > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > > root. > > > > > > > > > > Can't bind to TCP socket. The tcp module loads but I noticed > > that > > > it > > > > > only tries to bind the socket AFTER it has dropped is privs so > it > > > can > > > > > not bind to a socket less than 1024. UDP bind works as that > > seems > > > to > > > > > bind immediately after module load while the prog is still > > running > > > as > > > > > root. If I set a tcp port >1024, it works. Could this be a > race > > > > > between > > > > > two threads where a different thread is setting the UID/GID and > a > > > > > different one is binding the connections and the UID gets > changed > > > > > before > > > > > the binding thread has a chance to get the socket? > > > > > > > > > > Modules being loaded: > > > > > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > > > 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' > > > > > 9572.648645873:7f07c0a216f0: loading module > > > > '/usr/lib/rsyslog/imudp.so' > > > > > 9572.648713628:7f07c0a216f0: source file imudp.c requested > > > reference > > > > > for > > > > > module 'lmnet', reference count now 4 > > > > > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > > > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports at > > > > *:514. > > > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > > > 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' > > > > > 9572.648869611:7f07c0a216f0: loading module > > > > '/usr/lib/rsyslog/imtcp.so' > > > > > 9572.648938665:7f07c0a216f0: source file imtcp.c requested > > > reference > > > > > for > > > > > module 'lmnet', reference count now 5 > > > > > 9572.648953892:7f07c0a216f0: caller requested object 'netstrm', > > not > > > > > found (iRet -3003) > > > > > 9572.648968610:7f07c0a216f0: Requested to load module > > 'lmnetstrms' > > > > > 9572.648979310:7f07c0a216f0: loading module > > > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > > > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > > > > > 9572.649068131:7f07c0a216f0: source file imtcp.c requested > > > reference > > > > > for > > > > > module 'lmnetstrms', reference count now 1 > > > > > 9572.649079163:7f07c0a216f0: caller requested object > 'tcps_sess', > > > not > > > > > found (iRet -3003) > > > > > 9572.649095086:7f07c0a216f0: Requested to load module > 'lmtcpsrv' > > > > > 9572.649105485:7f07c0a216f0: loading module > > > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c requested > > > > > reference > > > > > for module 'lmnetstrms', reference count now 2 > > > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested > > > reference > > > > > for module 'lmnet', reference count now 6 > > > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested > > > reference > > > > > for module 'lmnetstrms', reference count now 3 > > > > > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > > > > > 9572.649241801:7f07c0a216f0: source file imtcp.c requested > > > reference > > > > > for > > > > > module 'lmtcpsrv', reference count now 1 > > > > > 9572.649252009:7f07c0a216f0: source file imtcp.c requested > > > reference > > > > > for > > > > > module 'lmtcpsrv', reference count now 2 > > > > > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > > > > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' > > > > > 9572.649321373:7f07c0a216f0: cfline: > '$ActionFileDefaultTemplate > > > > > RSYSLOG_TraditionalFileFormat' > > > > > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction on' > > > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user 'syslog' > > > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > > > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > > > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > > > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' > > > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user 'syslog' > > > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup syslog' > > > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group > 'syslog' > > > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > > > /etc/rsyslog.d/*.conf' > > > > > 9572.650017305:7f07c0a216f0: requested to include config file > > > > > '/etc/rsyslog.d/50-default.conf' > > > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > > > /var/log/auth.log' > > > > > > > > > > GID and UID being changed: > > > > > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, > > > lenBuf > > > > 78 > > > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', > > msg > > > > > rsyslogd's groupid changed to 103 > > > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog format. > > > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > > > > 9572.671957623:7f07be402910: Called action, logging to builtin- > > pipe > > > > > 9572.671969801:7f07be402910: extend buf to at least 16, done > 128 > > > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 > > > entries > > > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy > > > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised worker > > > start > > > > > 9572.672059720:7f07be402910: Action requested to be suspended, > > done > > > > > that. > > > > > 9572.672085037:7f07be402910: main Q: entry deleted, state 0, > size > > > now > > > > 1 > > > > > entries > > > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > > > > 9572.672147659:7f07be402910: Called action, logging to builtin- > > file > > > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', > > msg > > > > > rsyslogd's userid changed to 101 > > > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog format. > > > > > 9572.672192329:7f07be402910: extend buf to at least 138, done > 256 > > > > > 9572.672200766:7f07be402910: file to log to: /var/log/syslog > > > > > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > > > transitioning > > > > to > > > > > regular run mode > > > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket 4 > > > > > (IPv4/port 514). > > > > > 9572.672576606:7f07bc3fe910: --------imUDP calling select, > active > > > > file > > > > > descriptors (max 4): 4 > > > > > 9572.672594858:7f07bdc01910: --------imuxsock calling select, > > > active > > > > > file descriptors (max 5): 3 5 > > > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy > > > > > 9572.672646478:7f07bbbfd910: caller requested object > 'nsd_ptcp', > > > not > > > > > found (iRet -3003) > > > > > 9572.672663716:7f07bbbfd910: Requested to load module > > 'lmnsd_ptcp' > > > > > 9572.672671184:7f07bbbfd910: loading module > > > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested > > > > reference > > > > > for module 'lmnetstrms', reference count now 4 > > > > > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > > > > > 9572.672763826:7f07bbbfd910: source file netstrms.c requested > > > > reference > > > > > for module 'lmnsd_ptcp', reference count now 1 > > > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket on port > > 514 > > > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp > socketWe > > > > could > > > > > initialize 0 TCP listen sockets out of 1 we recei > > > > > ved - this may or may not be an error indication. > > > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could > > > successfully > > > > > be > > > > > initializedCalled LogError, msg: Could not crea > > > > > te tcp listener, ignoring port 514. > > > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from 'trebuchet', > > msg > > > > > Could not create tcp listener, ignoring port 514. [t > > > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Mon Apr 26 11:44:12 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 26 Apr 2010 02:44:12 -0700 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE7330@RWC-EX1.corp.seven.com> <9B6E2A8877C38245BFB15CC491A11DA7103CE3@GRFEXC.intern.adiscon.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE7331@RWC-EX1.corp.seven.com> Maybe a quick fix would be a "sleep" directive you could place on the main thread to cause it to delay a bit? That would not be expected to be a permanent "fix" but simply a work-around. If I could place something like "sleep 5" that would cause the main thread to wait a little while, that could work around the race. > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Monday, April 26, 2010 2:32 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > Sent: Monday, April 26, 2010 10:52 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > root. > > > > I think the problem is that it spawns a new thread to load the udp > and > > tcp modules and that should be done by the main thread so that it > gets > > done in sequence before the privs are processed. > > I think your analysis is right, this is where the race happens. > However, the > cure is far from being as simple as it sounds: you are actually > recommending > a full redesign of the input plugin interface. It would also have other > implications, including a potential unacceptable startup delay. > > This is what I quoted with "a lot of work to do". So, unfortunately, it > does > not look like something I can fix quickly. Let me once again reiterate > that > the priv drop code is far from being a complete solution. I added the > current > code when I saw that it was easy to do and useful for some situations. > We > once had someone who was interested in sponsoring a complete > implementation, > but that did unfortunately not materialize. As I am currently short on > time > due to other work to do, I do not find sufficient time to look at this. > It is > far from being a trivial task, even though I hope to be able to do it > without > a full redesign. I still think it is 2+ weeks worth of work. > > Rainer > > > > > > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > Sent: Monday, April 26, 2010 1:37 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > non-root. > > > > > > No problem -- the mailing list processor held it due to size > > > constrainst (and > > > I rejected it now). The size restriction was actually the prime > issue > > > why I > > > requested it to go to my private mail. So: nothing bad has happened > > ;) > > > > > > I'll try to look at the log asap and let you know what I find. > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > Sent: Monday, April 26, 2010 10:10 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > non- > > > root. > > > > > > > > Oops, sorry, I did not mean to send that attachment to the list. > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > Sent: Sunday, April 25, 2010 11:18 PM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > > non-root. > > > > > > > > > > The privilege drop code is still a hack. It needs proper > > > engineering > > > > > (as > > > > > stated in the doc). So it could very well be a race in this > > regard. > > > > On > > > > > the > > > > > other hand, it does not look so. Could you send me complete > debug > > > > logs > > > > > to my > > > > > private email address both with and without privilege drop > inside > > > > your > > > > > config. Maybe it is a simple thing, then I could fix it without > > the > > > > > large > > > > > effort really required. > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > > Sent: Monday, April 26, 2010 2:24 AM > > > > > > To: rsyslog-users > > > > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID > non- > > > root. > > > > > > > > > > > > Can't bind to TCP socket. The tcp module loads but I noticed > > > that > > > > it > > > > > > only tries to bind the socket AFTER it has dropped is privs > so > > it > > > > can > > > > > > not bind to a socket less than 1024. UDP bind works as that > > > seems > > > > to > > > > > > bind immediately after module load while the prog is still > > > running > > > > as > > > > > > root. If I set a tcp port >1024, it works. Could this be a > > race > > > > > > between > > > > > > two threads where a different thread is setting the UID/GID > and > > a > > > > > > different one is binding the connections and the UID gets > > changed > > > > > > before > > > > > > the binding thread has a chance to get the socket? > > > > > > > > > > > > Modules being loaded: > > > > > > > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > > > > 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' > > > > > > 9572.648645873:7f07c0a216f0: loading module > > > > > '/usr/lib/rsyslog/imudp.so' > > > > > > 9572.648713628:7f07c0a216f0: source file imudp.c requested > > > > reference > > > > > > for > > > > > > module 'lmnet', reference count now 4 > > > > > > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > > > > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > > > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports > at > > > > > *:514. > > > > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > > > > 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' > > > > > > 9572.648869611:7f07c0a216f0: loading module > > > > > '/usr/lib/rsyslog/imtcp.so' > > > > > > 9572.648938665:7f07c0a216f0: source file imtcp.c requested > > > > reference > > > > > > for > > > > > > module 'lmnet', reference count now 5 > > > > > > 9572.648953892:7f07c0a216f0: caller requested object > 'netstrm', > > > not > > > > > > found (iRet -3003) > > > > > > 9572.648968610:7f07c0a216f0: Requested to load module > > > 'lmnetstrms' > > > > > > 9572.648979310:7f07c0a216f0: loading module > > > > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > > > > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > > > > > > 9572.649068131:7f07c0a216f0: source file imtcp.c requested > > > > reference > > > > > > for > > > > > > module 'lmnetstrms', reference count now 1 > > > > > > 9572.649079163:7f07c0a216f0: caller requested object > > 'tcps_sess', > > > > not > > > > > > found (iRet -3003) > > > > > > 9572.649095086:7f07c0a216f0: Requested to load module > > 'lmtcpsrv' > > > > > > 9572.649105485:7f07c0a216f0: loading module > > > > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c > requested > > > > > > reference > > > > > > for module 'lmnetstrms', reference count now 2 > > > > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested > > > > reference > > > > > > for module 'lmnet', reference count now 6 > > > > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested > > > > reference > > > > > > for module 'lmnetstrms', reference count now 3 > > > > > > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > > > > > > 9572.649241801:7f07c0a216f0: source file imtcp.c requested > > > > reference > > > > > > for > > > > > > module 'lmtcpsrv', reference count now 1 > > > > > > 9572.649252009:7f07c0a216f0: source file imtcp.c requested > > > > reference > > > > > > for > > > > > > module 'lmtcpsrv', reference count now 2 > > > > > > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > > > > > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' > > > > > > 9572.649321373:7f07c0a216f0: cfline: > > '$ActionFileDefaultTemplate > > > > > > RSYSLOG_TraditionalFileFormat' > > > > > > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction > on' > > > > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > > > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user > 'syslog' > > > > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > > > > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > > > > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > > > > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' > > > > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user > 'syslog' > > > > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup > syslog' > > > > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group > > 'syslog' > > > > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > > > > /etc/rsyslog.d/*.conf' > > > > > > 9572.650017305:7f07c0a216f0: requested to include config file > > > > > > '/etc/rsyslog.d/50-default.conf' > > > > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > > > > /var/log/auth.log' > > > > > > > > > > > > GID and UID being changed: > > > > > > > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, > > > > lenBuf > > > > > 78 > > > > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from > 'trebuchet', > > > msg > > > > > > rsyslogd's groupid changed to 103 > > > > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog > format. > > > > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > > > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > > > > > 9572.671957623:7f07be402910: Called action, logging to > builtin- > > > pipe > > > > > > 9572.671969801:7f07be402910: extend buf to at least 16, done > > 128 > > > > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 > > > > entries > > > > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy > > > > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised > worker > > > > start > > > > > > 9572.672059720:7f07be402910: Action requested to be > suspended, > > > done > > > > > > that. > > > > > > 9572.672085037:7f07be402910: main Q: entry deleted, state 0, > > size > > > > now > > > > > 1 > > > > > > entries > > > > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > > > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > > > > > 9572.672147659:7f07be402910: Called action, logging to > builtin- > > > file > > > > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from > 'trebuchet', > > > msg > > > > > > rsyslogd's userid changed to 101 > > > > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog > format. > > > > > > 9572.672192329:7f07be402910: extend buf to at least 138, done > > 256 > > > > > > 9572.672200766:7f07be402910: file to log to: /var/log/syslog > > > > > > > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > > > > transitioning > > > > > to > > > > > > regular run mode > > > > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket > 4 > > > > > > (IPv4/port 514). > > > > > > 9572.672576606:7f07bc3fe910: --------imUDP calling select, > > active > > > > > file > > > > > > descriptors (max 4): 4 > > > > > > 9572.672594858:7f07bdc01910: --------imuxsock calling select, > > > > active > > > > > > file descriptors (max 5): 3 5 > > > > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy > > > > > > 9572.672646478:7f07bbbfd910: caller requested object > > 'nsd_ptcp', > > > > not > > > > > > found (iRet -3003) > > > > > > 9572.672663716:7f07bbbfd910: Requested to load module > > > 'lmnsd_ptcp' > > > > > > 9572.672671184:7f07bbbfd910: loading module > > > > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested > > > > > reference > > > > > > for module 'lmnetstrms', reference count now 4 > > > > > > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > > > > > > 9572.672763826:7f07bbbfd910: source file netstrms.c requested > > > > > reference > > > > > > for module 'lmnsd_ptcp', reference count now 1 > > > > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket on > port > > > 514 > > > > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp > > socketWe > > > > > could > > > > > > initialize 0 TCP listen sockets out of 1 we recei > > > > > > ved - this may or may not be an error indication. > > > > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could > > > > successfully > > > > > > be > > > > > > initializedCalled LogError, msg: Could not crea > > > > > > te tcp listener, ignoring port 514. > > > > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from > 'trebuchet', > > > msg > > > > > > Could not create tcp listener, ignoring port 514. [t > > > > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Apr 26 11:45:37 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Apr 2010 11:45:37 +0200 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE7330@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE3@GRFEXC.intern.adiscon.com> <5A6D953473350C4B9995546AFE9939EE08FE7331@RWC-EX1.corp.seven.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CE4@GRFEXC.intern.adiscon.com> While I agree that it is ugly, it sounds like a good idea ;) Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Monday, April 26, 2010 11:44 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > Maybe a quick fix would be a "sleep" directive you could place on the > main thread to cause it to delay a bit? That would not be expected to > be > a permanent "fix" but simply a work-around. If I could place something > like "sleep 5" that would cause the main thread to wait a little while, > that could work around the race. > > > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > Sent: Monday, April 26, 2010 2:32 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > non-root. > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > Sent: Monday, April 26, 2010 10:52 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > > root. > > > > > > I think the problem is that it spawns a new thread to load the udp > > and > > > tcp modules and that should be done by the main thread so that it > > gets > > > done in sequence before the privs are processed. > > > > I think your analysis is right, this is where the race happens. > > However, the > > cure is far from being as simple as it sounds: you are actually > > recommending > > a full redesign of the input plugin interface. It would also have > other > > implications, including a potential unacceptable startup delay. > > > > This is what I quoted with "a lot of work to do". So, unfortunately, > it > > does > > not look like something I can fix quickly. Let me once again > reiterate > > that > > the priv drop code is far from being a complete solution. I added the > > current > > code when I saw that it was easy to do and useful for some > situations. > > We > > once had someone who was interested in sponsoring a complete > > implementation, > > but that did unfortunately not materialize. As I am currently short > on > > time > > due to other work to do, I do not find sufficient time to look at > this. > > It is > > far from being a trivial task, even though I hope to be able to do it > > without > > a full redesign. I still think it is 2+ weeks worth of work. > > > > Rainer > > > > > > > > > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > Sent: Monday, April 26, 2010 1:37 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > non-root. > > > > > > > > No problem -- the mailing list processor held it due to size > > > > constrainst (and > > > > I rejected it now). The size restriction was actually the prime > > issue > > > > why I > > > > requested it to go to my private mail. So: nothing bad has > happened > > > ;) > > > > > > > > I'll try to look at the log asap and let you know what I find. > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > Sent: Monday, April 26, 2010 10:10 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > non- > > > > root. > > > > > > > > > > Oops, sorry, I did not mean to send that attachment to the > list. > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > Sent: Sunday, April 25, 2010 11:18 PM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > > > non-root. > > > > > > > > > > > > The privilege drop code is still a hack. It needs proper > > > > engineering > > > > > > (as > > > > > > stated in the doc). So it could very well be a race in this > > > regard. > > > > > On > > > > > > the > > > > > > other hand, it does not look so. Could you send me complete > > debug > > > > > logs > > > > > > to my > > > > > > private email address both with and without privilege drop > > inside > > > > > your > > > > > > config. Maybe it is a simple thing, then I could fix it > without > > > the > > > > > > large > > > > > > effort really required. > > > > > > > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > > > Sent: Monday, April 26, 2010 2:24 AM > > > > > > > To: rsyslog-users > > > > > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID > > non- > > > > root. > > > > > > > > > > > > > > Can't bind to TCP socket. The tcp module loads but I > noticed > > > > that > > > > > it > > > > > > > only tries to bind the socket AFTER it has dropped is privs > > so > > > it > > > > > can > > > > > > > not bind to a socket less than 1024. UDP bind works as > that > > > > seems > > > > > to > > > > > > > bind immediately after module load while the prog is still > > > > running > > > > > as > > > > > > > root. If I set a tcp port >1024, it works. Could this be a > > > race > > > > > > > between > > > > > > > two threads where a different thread is setting the UID/GID > > and > > > a > > > > > > > different one is binding the connections and the UID gets > > > changed > > > > > > > before > > > > > > > the binding thread has a chance to get the socket? > > > > > > > > > > > > > > Modules being loaded: > > > > > > > > > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > > > > > 9572.648636228:7f07c0a216f0: Requested to load module > 'imudp' > > > > > > > 9572.648645873:7f07c0a216f0: loading module > > > > > > '/usr/lib/rsyslog/imudp.so' > > > > > > > 9572.648713628:7f07c0a216f0: source file imudp.c requested > > > > > reference > > > > > > > for > > > > > > > module 'lmnet', reference count now 4 > > > > > > > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > > > > > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > > > > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP > ports > > at > > > > > > *:514. > > > > > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > > > > > 9572.648859626:7f07c0a216f0: Requested to load module > 'imtcp' > > > > > > > 9572.648869611:7f07c0a216f0: loading module > > > > > > '/usr/lib/rsyslog/imtcp.so' > > > > > > > 9572.648938665:7f07c0a216f0: source file imtcp.c requested > > > > > reference > > > > > > > for > > > > > > > module 'lmnet', reference count now 5 > > > > > > > 9572.648953892:7f07c0a216f0: caller requested object > > 'netstrm', > > > > not > > > > > > > found (iRet -3003) > > > > > > > 9572.648968610:7f07c0a216f0: Requested to load module > > > > 'lmnetstrms' > > > > > > > 9572.648979310:7f07c0a216f0: loading module > > > > > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > > > > > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > > > > > > > 9572.649068131:7f07c0a216f0: source file imtcp.c requested > > > > > reference > > > > > > > for > > > > > > > module 'lmnetstrms', reference count now 1 > > > > > > > 9572.649079163:7f07c0a216f0: caller requested object > > > 'tcps_sess', > > > > > not > > > > > > > found (iRet -3003) > > > > > > > 9572.649095086:7f07c0a216f0: Requested to load module > > > 'lmtcpsrv' > > > > > > > 9572.649105485:7f07c0a216f0: loading module > > > > > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > > > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c > > requested > > > > > > > reference > > > > > > > for module 'lmnetstrms', reference count now 2 > > > > > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested > > > > > reference > > > > > > > for module 'lmnet', reference count now 6 > > > > > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested > > > > > reference > > > > > > > for module 'lmnetstrms', reference count now 3 > > > > > > > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > > > > > > > 9572.649241801:7f07c0a216f0: source file imtcp.c requested > > > > > reference > > > > > > > for > > > > > > > module 'lmtcpsrv', reference count now 1 > > > > > > > 9572.649252009:7f07c0a216f0: source file imtcp.c requested > > > > > reference > > > > > > > for > > > > > > > module 'lmtcpsrv', reference count now 2 > > > > > > > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > > > > > > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun > 514' > > > > > > > 9572.649321373:7f07c0a216f0: cfline: > > > '$ActionFileDefaultTemplate > > > > > > > RSYSLOG_TraditionalFileFormat' > > > > > > > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction > > on' > > > > > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > > > > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user > > 'syslog' > > > > > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > > > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > > > > > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > > > > > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > > > > > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > > > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > > > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser > syslog' > > > > > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user > > 'syslog' > > > > > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup > > syslog' > > > > > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group > > > 'syslog' > > > > > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > > > > > /etc/rsyslog.d/*.conf' > > > > > > > 9572.650017305:7f07c0a216f0: requested to include config > file > > > > > > > '/etc/rsyslog.d/50-default.conf' > > > > > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > > > > > /var/log/auth.log' > > > > > > > > > > > > > > GID and UID being changed: > > > > > > > > > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm > 0x1e11d60, > > > > > lenBuf > > > > > > 78 > > > > > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from > > 'trebuchet', > > > > msg > > > > > > > rsyslogd's groupid changed to 103 > > > > > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog > > format. > > > > > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > > > > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > > > > > > 9572.671957623:7f07be402910: Called action, logging to > > builtin- > > > > pipe > > > > > > > 9572.671969801:7f07be402910: extend buf to at least 16, > done > > > 128 > > > > > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > > > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size now > 2 > > > > > entries > > > > > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals > busy > > > > > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised > > worker > > > > > start > > > > > > > 9572.672059720:7f07be402910: Action requested to be > > suspended, > > > > done > > > > > > > that. > > > > > > > 9572.672085037:7f07be402910: main Q: entry deleted, state > 0, > > > size > > > > > now > > > > > > 1 > > > > > > > entries > > > > > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > > > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > > > > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > > > > > > 9572.672147659:7f07be402910: Called action, logging to > > builtin- > > > > file > > > > > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from > > 'trebuchet', > > > > msg > > > > > > > rsyslogd's userid changed to 101 > > > > > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog > > format. > > > > > > > 9572.672192329:7f07be402910: extend buf to at least 138, > done > > > 256 > > > > > > > 9572.672200766:7f07be402910: file to log to: > /var/log/syslog > > > > > > > > > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > > > > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > > > > > transitioning > > > > > > to > > > > > > > regular run mode > > > > > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd > socket > > 4 > > > > > > > (IPv4/port 514). > > > > > > > 9572.672576606:7f07bc3fe910: --------imUDP calling select, > > > active > > > > > > file > > > > > > > descriptors (max 4): 4 > > > > > > > 9572.672594858:7f07bdc01910: --------imuxsock calling > select, > > > > > active > > > > > > > file descriptors (max 5): 3 5 > > > > > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals > busy > > > > > > > 9572.672646478:7f07bbbfd910: caller requested object > > > 'nsd_ptcp', > > > > > not > > > > > > > found (iRet -3003) > > > > > > > 9572.672663716:7f07bbbfd910: Requested to load module > > > > 'lmnsd_ptcp' > > > > > > > 9572.672671184:7f07bbbfd910: loading module > > > > > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > > > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c > requested > > > > > > reference > > > > > > > for module 'lmnetstrms', reference count now 4 > > > > > > > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > > > > > > > 9572.672763826:7f07bbbfd910: source file netstrms.c > requested > > > > > > reference > > > > > > > for module 'lmnsd_ptcp', reference count now 1 > > > > > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket on > > port > > > > 514 > > > > > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp > > > socketWe > > > > > > could > > > > > > > initialize 0 TCP listen sockets out of 1 we recei > > > > > > > ved - this may or may not be an error indication. > > > > > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could > > > > > successfully > > > > > > > be > > > > > > > initializedCalled LogError, msg: Could not crea > > > > > > > te tcp listener, ignoring port 514. > > > > > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from > > 'trebuchet', > > > > msg > > > > > > > Could not create tcp listener, ignoring port 514. [t > > > > > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > > > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Apr 26 12:09:55 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Apr 2010 12:09:55 +0200 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE7330@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE3@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE7331@RWC-EX1.corp.seven.com> <9B6E2A8877C38245BFB15CC491A11DA7103CE4@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CE5@GRFEXC.intern.adiscon.com> This is the patch for v4-devel (master will follow soon): http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=d19806431653e6575a002ab4 8206c16d3041e465 While I make such changes only to the latest devel, you should be able to apply the patch without problems to almost all versions. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Monday, April 26, 2010 11:46 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > While I agree that it is ugly, it sounds like a good idea ;) > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > Sent: Monday, April 26, 2010 11:44 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > root. > > > > Maybe a quick fix would be a "sleep" directive you could place on the > > main thread to cause it to delay a bit? That would not be expected to > > be > > a permanent "fix" but simply a work-around. If I could place > something > > like "sleep 5" that would cause the main thread to wait a little > while, > > that could work around the race. > > > > > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > Sent: Monday, April 26, 2010 2:32 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > non-root. > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > Sent: Monday, April 26, 2010 10:52 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > non- > > > root. > > > > > > > > I think the problem is that it spawns a new thread to load the > udp > > > and > > > > tcp modules and that should be done by the main thread so that it > > > gets > > > > done in sequence before the privs are processed. > > > > > > I think your analysis is right, this is where the race happens. > > > However, the > > > cure is far from being as simple as it sounds: you are actually > > > recommending > > > a full redesign of the input plugin interface. It would also have > > other > > > implications, including a potential unacceptable startup delay. > > > > > > This is what I quoted with "a lot of work to do". So, > unfortunately, > > it > > > does > > > not look like something I can fix quickly. Let me once again > > reiterate > > > that > > > the priv drop code is far from being a complete solution. I added > the > > > current > > > code when I saw that it was easy to do and useful for some > > situations. > > > We > > > once had someone who was interested in sponsoring a complete > > > implementation, > > > but that did unfortunately not materialize. As I am currently short > > on > > > time > > > due to other work to do, I do not find sufficient time to look at > > this. > > > It is > > > far from being a trivial task, even though I hope to be able to do > it > > > without > > > a full redesign. I still think it is 2+ weeks worth of work. > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > Sent: Monday, April 26, 2010 1:37 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > > non-root. > > > > > > > > > > No problem -- the mailing list processor held it due to size > > > > > constrainst (and > > > > > I rejected it now). The size restriction was actually the prime > > > issue > > > > > why I > > > > > requested it to go to my private mail. So: nothing bad has > > happened > > > > ;) > > > > > > > > > > I'll try to look at the log asap and let you know what I find. > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > > Sent: Monday, April 26, 2010 10:10 AM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > non- > > > > > root. > > > > > > > > > > > > Oops, sorry, I did not mean to send that attachment to the > > list. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > > Sent: Sunday, April 25, 2010 11:18 PM > > > > > > > To: rsyslog-users > > > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after > UID > > > > > > non-root. > > > > > > > > > > > > > > The privilege drop code is still a hack. It needs proper > > > > > engineering > > > > > > > (as > > > > > > > stated in the doc). So it could very well be a race in this > > > > regard. > > > > > > On > > > > > > > the > > > > > > > other hand, it does not look so. Could you send me complete > > > debug > > > > > > logs > > > > > > > to my > > > > > > > private email address both with and without privilege drop > > > inside > > > > > > your > > > > > > > config. Maybe it is a simple thing, then I could fix it > > without > > > > the > > > > > > > large > > > > > > > effort really required. > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > > > > Sent: Monday, April 26, 2010 2:24 AM > > > > > > > > To: rsyslog-users > > > > > > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > non- > > > > > root. > > > > > > > > > > > > > > > > Can't bind to TCP socket. The tcp module loads but I > > noticed > > > > > that > > > > > > it > > > > > > > > only tries to bind the socket AFTER it has dropped is > privs > > > so > > > > it > > > > > > can > > > > > > > > not bind to a socket less than 1024. UDP bind works as > > that > > > > > seems > > > > > > to > > > > > > > > bind immediately after module load while the prog is > still > > > > > running > > > > > > as > > > > > > > > root. If I set a tcp port >1024, it works. Could this be > a > > > > race > > > > > > > > between > > > > > > > > two threads where a different thread is setting the > UID/GID > > > and > > > > a > > > > > > > > different one is binding the connections and the UID gets > > > > changed > > > > > > > > before > > > > > > > > the binding thread has a chance to get the socket? > > > > > > > > > > > > > > > > Modules being loaded: > > > > > > > > > > > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > > > > > > 9572.648636228:7f07c0a216f0: Requested to load module > > 'imudp' > > > > > > > > 9572.648645873:7f07c0a216f0: loading module > > > > > > > '/usr/lib/rsyslog/imudp.so' > > > > > > > > 9572.648713628:7f07c0a216f0: source file imudp.c > requested > > > > > > reference > > > > > > > > for > > > > > > > > module 'lmnet', reference count now 4 > > > > > > > > 9572.648734955:7f07c0a216f0: module of type 0 being > loaded. > > > > > > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > > > > > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP > > ports > > > at > > > > > > > *:514. > > > > > > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > > > > > > 9572.648859626:7f07c0a216f0: Requested to load module > > 'imtcp' > > > > > > > > 9572.648869611:7f07c0a216f0: loading module > > > > > > > '/usr/lib/rsyslog/imtcp.so' > > > > > > > > 9572.648938665:7f07c0a216f0: source file imtcp.c > requested > > > > > > reference > > > > > > > > for > > > > > > > > module 'lmnet', reference count now 5 > > > > > > > > 9572.648953892:7f07c0a216f0: caller requested object > > > 'netstrm', > > > > > not > > > > > > > > found (iRet -3003) > > > > > > > > 9572.648968610:7f07c0a216f0: Requested to load module > > > > > 'lmnetstrms' > > > > > > > > 9572.648979310:7f07c0a216f0: loading module > > > > > > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > > > > > > 9572.649053366:7f07c0a216f0: module of type 2 being > loaded. > > > > > > > > 9572.649068131:7f07c0a216f0: source file imtcp.c > requested > > > > > > reference > > > > > > > > for > > > > > > > > module 'lmnetstrms', reference count now 1 > > > > > > > > 9572.649079163:7f07c0a216f0: caller requested object > > > > 'tcps_sess', > > > > > > not > > > > > > > > found (iRet -3003) > > > > > > > > 9572.649095086:7f07c0a216f0: Requested to load module > > > > 'lmtcpsrv' > > > > > > > > 9572.649105485:7f07c0a216f0: loading module > > > > > > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > > > > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c > > > requested > > > > > > > > reference > > > > > > > > for module 'lmnetstrms', reference count now 2 > > > > > > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c > requested > > > > > > reference > > > > > > > > for module 'lmnet', reference count now 6 > > > > > > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c > requested > > > > > > reference > > > > > > > > for module 'lmnetstrms', reference count now 3 > > > > > > > > 9572.649231362:7f07c0a216f0: module of type 2 being > loaded. > > > > > > > > 9572.649241801:7f07c0a216f0: source file imtcp.c > requested > > > > > > reference > > > > > > > > for > > > > > > > > module 'lmtcpsrv', reference count now 1 > > > > > > > > 9572.649252009:7f07c0a216f0: source file imtcp.c > requested > > > > > > reference > > > > > > > > for > > > > > > > > module 'lmtcpsrv', reference count now 2 > > > > > > > > 9572.649287366:7f07c0a216f0: module of type 0 being > loaded. > > > > > > > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun > > 514' > > > > > > > > 9572.649321373:7f07c0a216f0: cfline: > > > > '$ActionFileDefaultTemplate > > > > > > > > RSYSLOG_TraditionalFileFormat' > > > > > > > > 9572.649334345:7f07c0a216f0: cfline: > '$RepeatedMsgReduction > > > on' > > > > > > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > > > > > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user > > > 'syslog' > > > > > > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > > > > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group > 'adm' > > > > > > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode > 0640' > > > > > > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode > 0755' > > > > > > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > > > > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > > > > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser > > syslog' > > > > > > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user > > > 'syslog' > > > > > > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup > > > syslog' > > > > > > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group > > > > 'syslog' > > > > > > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > > > > > > /etc/rsyslog.d/*.conf' > > > > > > > > 9572.650017305:7f07c0a216f0: requested to include config > > file > > > > > > > > '/etc/rsyslog.d/50-default.conf' > > > > > > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > > > > > > /var/log/auth.log' > > > > > > > > > > > > > > > > GID and UID being changed: > > > > > > > > > > > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm > > 0x1e11d60, > > > > > > lenBuf > > > > > > > 78 > > > > > > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from > > > 'trebuchet', > > > > > msg > > > > > > > > rsyslogd's groupid changed to 103 > > > > > > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog > > > format. > > > > > > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > > > > > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > > > > > > > 9572.671957623:7f07be402910: Called action, logging to > > > builtin- > > > > > pipe > > > > > > > > 9572.671969801:7f07be402910: extend buf to at least 16, > > done > > > > 128 > > > > > > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > > > > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size > now > > 2 > > > > > > entries > > > > > > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals > > busy > > > > > > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised > > > worker > > > > > > start > > > > > > > > 9572.672059720:7f07be402910: Action requested to be > > > suspended, > > > > > done > > > > > > > > that. > > > > > > > > 9572.672085037:7f07be402910: main Q: entry deleted, state > > 0, > > > > size > > > > > > now > > > > > > > 1 > > > > > > > > entries > > > > > > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > > > > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > > > > > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > > > > > > > 9572.672147659:7f07be402910: Called action, logging to > > > builtin- > > > > > file > > > > > > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from > > > 'trebuchet', > > > > > msg > > > > > > > > rsyslogd's userid changed to 101 > > > > > > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog > > > format. > > > > > > > > 9572.672192329:7f07be402910: extend buf to at least 138, > > done > > > > 256 > > > > > > > > 9572.672200766:7f07be402910: file to log to: > > /var/log/syslog > > > > > > > > > > > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > > > > > > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > > > > > > transitioning > > > > > > > to > > > > > > > > regular run mode > > > > > > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd > > socket > > > 4 > > > > > > > > (IPv4/port 514). > > > > > > > > 9572.672576606:7f07bc3fe910: --------imUDP calling > select, > > > > active > > > > > > > file > > > > > > > > descriptors (max 4): 4 > > > > > > > > 9572.672594858:7f07bdc01910: --------imuxsock calling > > select, > > > > > > active > > > > > > > > file descriptors (max 5): 3 5 > > > > > > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals > > busy > > > > > > > > 9572.672646478:7f07bbbfd910: caller requested object > > > > 'nsd_ptcp', > > > > > > not > > > > > > > > found (iRet -3003) > > > > > > > > 9572.672663716:7f07bbbfd910: Requested to load module > > > > > 'lmnsd_ptcp' > > > > > > > > 9572.672671184:7f07bbbfd910: loading module > > > > > > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > > > > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c > > requested > > > > > > > reference > > > > > > > > for module 'lmnetstrms', reference count now 4 > > > > > > > > 9572.672757197:7f07bbbfd910: module of type 2 being > loaded. > > > > > > > > 9572.672763826:7f07bbbfd910: source file netstrms.c > > requested > > > > > > > reference > > > > > > > > for module 'lmnsd_ptcp', reference count now 1 > > > > > > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket > on > > > port > > > > > 514 > > > > > > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp > > > > socketWe > > > > > > > could > > > > > > > > initialize 0 TCP listen sockets out of 1 we recei > > > > > > > > ved - this may or may not be an error indication. > > > > > > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could > > > > > > successfully > > > > > > > > be > > > > > > > > initializedCalled LogError, msg: Could not crea > > > > > > > > te tcp listener, ignoring port 514. > > > > > > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from > > > 'trebuchet', > > > > > msg > > > > > > > > Could not create tcp listener, ignoring port 514. [t > > > > > > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Mon Apr 26 23:42:11 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 26 Apr 2010 14:42:11 -0700 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE7330@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE3@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE7331@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE4@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103CE5@GRFEXC.intern.adiscon.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE736D@RWC-EX1.corp.seven.com> It doesn't work. TCP doesn't start until after privs are dropped. Just can't use it or must drop privs after binding the socket (like Apache does, for example). > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Monday, April 26, 2010 3:10 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > This is the patch for v4-devel (master will follow soon): > > http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=d19806431653e6575a > 002ab4 > 8206c16d3041e465 > > While I make such changes only to the latest devel, you should be able > to > apply the patch without problems to almost all versions. > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > Sent: Monday, April 26, 2010 11:46 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > root. > > > > While I agree that it is ugly, it sounds like a good idea ;) > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > Sent: Monday, April 26, 2010 11:44 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > > root. > > > > > > Maybe a quick fix would be a "sleep" directive you could place on > the > > > main thread to cause it to delay a bit? That would not be expected > to > > > be > > > a permanent "fix" but simply a work-around. If I could place > > something > > > like "sleep 5" that would cause the main thread to wait a little > > while, > > > that could work around the race. > > > > > > > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > Sent: Monday, April 26, 2010 2:32 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > non-root. > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > Sent: Monday, April 26, 2010 10:52 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > non- > > > > root. > > > > > > > > > > I think the problem is that it spawns a new thread to load the > > udp > > > > and > > > > > tcp modules and that should be done by the main thread so that > it > > > > gets > > > > > done in sequence before the privs are processed. > > > > > > > > I think your analysis is right, this is where the race happens. > > > > However, the > > > > cure is far from being as simple as it sounds: you are actually > > > > recommending > > > > a full redesign of the input plugin interface. It would also have > > > other > > > > implications, including a potential unacceptable startup delay. > > > > > > > > This is what I quoted with "a lot of work to do". So, > > unfortunately, > > > it > > > > does > > > > not look like something I can fix quickly. Let me once again > > > reiterate > > > > that > > > > the priv drop code is far from being a complete solution. I added > > the > > > > current > > > > code when I saw that it was easy to do and useful for some > > > situations. > > > > We > > > > once had someone who was interested in sponsoring a complete > > > > implementation, > > > > but that did unfortunately not materialize. As I am currently > short > > > on > > > > time > > > > due to other work to do, I do not find sufficient time to look at > > > this. > > > > It is > > > > far from being a trivial task, even though I hope to be able to > do > > it > > > > without > > > > a full redesign. I still think it is 2+ weeks worth of work. > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > Sent: Monday, April 26, 2010 1:37 AM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > > > non-root. > > > > > > > > > > > > No problem -- the mailing list processor held it due to size > > > > > > constrainst (and > > > > > > I rejected it now). The size restriction was actually the > prime > > > > issue > > > > > > why I > > > > > > requested it to go to my private mail. So: nothing bad has > > > happened > > > > > ;) > > > > > > > > > > > > I'll try to look at the log asap and let you know what I > find. > > > > > > > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > > > Sent: Monday, April 26, 2010 10:10 AM > > > > > > > To: rsyslog-users > > > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after > UID > > > > non- > > > > > > root. > > > > > > > > > > > > > > Oops, sorry, I did not mean to send that attachment to the > > > list. > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > > > Sent: Sunday, April 25, 2010 11:18 PM > > > > > > > > To: rsyslog-users > > > > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after > > UID > > > > > > > non-root. > > > > > > > > > > > > > > > > The privilege drop code is still a hack. It needs proper > > > > > > engineering > > > > > > > > (as > > > > > > > > stated in the doc). So it could very well be a race in > this > > > > > regard. > > > > > > > On > > > > > > > > the > > > > > > > > other hand, it does not look so. Could you send me > complete > > > > debug > > > > > > > logs > > > > > > > > to my > > > > > > > > private email address both with and without privilege > drop > > > > inside > > > > > > > your > > > > > > > > config. Maybe it is a simple thing, then I could fix it > > > without > > > > > the > > > > > > > > large > > > > > > > > effort really required. > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog- > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > > > > > Sent: Monday, April 26, 2010 2:24 AM > > > > > > > > > To: rsyslog-users > > > > > > > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after > UID > > > > non- > > > > > > root. > > > > > > > > > > > > > > > > > > Can't bind to TCP socket. The tcp module loads but I > > > noticed > > > > > > that > > > > > > > it > > > > > > > > > only tries to bind the socket AFTER it has dropped is > > privs > > > > so > > > > > it > > > > > > > can > > > > > > > > > not bind to a socket less than 1024. UDP bind works as > > > that > > > > > > seems > > > > > > > to > > > > > > > > > bind immediately after module load while the prog is > > still > > > > > > running > > > > > > > as > > > > > > > > > root. If I set a tcp port >1024, it works. Could this > be > > a > > > > > race > > > > > > > > > between > > > > > > > > > two threads where a different thread is setting the > > UID/GID > > > > and > > > > > a > > > > > > > > > different one is binding the connections and the UID > gets > > > > > changed > > > > > > > > > before > > > > > > > > > the binding thread has a chance to get the socket? > > > > > > > > > > > > > > > > > > Modules being loaded: > > > > > > > > > > > > > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > > > > > > > 9572.648636228:7f07c0a216f0: Requested to load module > > > 'imudp' > > > > > > > > > 9572.648645873:7f07c0a216f0: loading module > > > > > > > > '/usr/lib/rsyslog/imudp.so' > > > > > > > > > 9572.648713628:7f07c0a216f0: source file imudp.c > > requested > > > > > > > reference > > > > > > > > > for > > > > > > > > > module 'lmnet', reference count now 4 > > > > > > > > > 9572.648734955:7f07c0a216f0: module of type 0 being > > loaded. > > > > > > > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun > 514' > > > > > > > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP > > > ports > > > > at > > > > > > > > *:514. > > > > > > > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > > > > > > > 9572.648859626:7f07c0a216f0: Requested to load module > > > 'imtcp' > > > > > > > > > 9572.648869611:7f07c0a216f0: loading module > > > > > > > > '/usr/lib/rsyslog/imtcp.so' > > > > > > > > > 9572.648938665:7f07c0a216f0: source file imtcp.c > > requested > > > > > > > reference > > > > > > > > > for > > > > > > > > > module 'lmnet', reference count now 5 > > > > > > > > > 9572.648953892:7f07c0a216f0: caller requested object > > > > 'netstrm', > > > > > > not > > > > > > > > > found (iRet -3003) > > > > > > > > > 9572.648968610:7f07c0a216f0: Requested to load module > > > > > > 'lmnetstrms' > > > > > > > > > 9572.648979310:7f07c0a216f0: loading module > > > > > > > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > > > > > > > 9572.649053366:7f07c0a216f0: module of type 2 being > > loaded. > > > > > > > > > 9572.649068131:7f07c0a216f0: source file imtcp.c > > requested > > > > > > > reference > > > > > > > > > for > > > > > > > > > module 'lmnetstrms', reference count now 1 > > > > > > > > > 9572.649079163:7f07c0a216f0: caller requested object > > > > > 'tcps_sess', > > > > > > > not > > > > > > > > > found (iRet -3003) > > > > > > > > > 9572.649095086:7f07c0a216f0: Requested to load module > > > > > 'lmtcpsrv' > > > > > > > > > 9572.649105485:7f07c0a216f0: loading module > > > > > > > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > > > > > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c > > > > requested > > > > > > > > > reference > > > > > > > > > for module 'lmnetstrms', reference count now 2 > > > > > > > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c > > requested > > > > > > > reference > > > > > > > > > for module 'lmnet', reference count now 6 > > > > > > > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c > > requested > > > > > > > reference > > > > > > > > > for module 'lmnetstrms', reference count now 3 > > > > > > > > > 9572.649231362:7f07c0a216f0: module of type 2 being > > loaded. > > > > > > > > > 9572.649241801:7f07c0a216f0: source file imtcp.c > > requested > > > > > > > reference > > > > > > > > > for > > > > > > > > > module 'lmtcpsrv', reference count now 1 > > > > > > > > > 9572.649252009:7f07c0a216f0: source file imtcp.c > > requested > > > > > > > reference > > > > > > > > > for > > > > > > > > > module 'lmtcpsrv', reference count now 2 > > > > > > > > > 9572.649287366:7f07c0a216f0: module of type 0 being > > loaded. > > > > > > > > > 9572.649299663:7f07c0a216f0: cfline: > '$InputTCPServerRun > > > 514' > > > > > > > > > 9572.649321373:7f07c0a216f0: cfline: > > > > > '$ActionFileDefaultTemplate > > > > > > > > > RSYSLOG_TraditionalFileFormat' > > > > > > > > > 9572.649334345:7f07c0a216f0: cfline: > > '$RepeatedMsgReduction > > > > on' > > > > > > > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner > syslog' > > > > > > > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user > > > > 'syslog' > > > > > > > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > > > > > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group > > 'adm' > > > > > > > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode > > 0640' > > > > > > > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode > > 0755' > > > > > > > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > > > > > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > > > > > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser > > > syslog' > > > > > > > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user > > > > 'syslog' > > > > > > > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup > > > > syslog' > > > > > > > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group > > > > > 'syslog' > > > > > > > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > > > > > > > /etc/rsyslog.d/*.conf' > > > > > > > > > 9572.650017305:7f07c0a216f0: requested to include > config > > > file > > > > > > > > > '/etc/rsyslog.d/50-default.conf' > > > > > > > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > > > > > > > /var/log/auth.log' > > > > > > > > > > > > > > > > > > GID and UID being changed: > > > > > > > > > > > > > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm > > > 0x1e11d60, > > > > > > > lenBuf > > > > > > > > 78 > > > > > > > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from > > > > 'trebuchet', > > > > > > msg > > > > > > > > > rsyslogd's groupid changed to 103 > > > > > > > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog > > > > format. > > > > > > > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > > > > > > > 9572.671947526:7f07be402910: testing filter, f_pmask > 240 > > > > > > > > > 9572.671957623:7f07be402910: Called action, logging to > > > > builtin- > > > > > > pipe > > > > > > > > > 9572.671969801:7f07be402910: extend buf to at least 16, > > > done > > > > > 128 > > > > > > > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > > > > > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size > > now > > > 2 > > > > > > > entries > > > > > > > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers > signals > > > busy > > > > > > > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised > > > > worker > > > > > > > start > > > > > > > > > 9572.672059720:7f07be402910: Action requested to be > > > > suspended, > > > > > > done > > > > > > > > > that. > > > > > > > > > 9572.672085037:7f07be402910: main Q: entry deleted, > state > > > 0, > > > > > size > > > > > > > now > > > > > > > > 1 > > > > > > > > > entries > > > > > > > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > > > > > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > > > > > > > 9572.672136161:7f07be402910: testing filter, f_pmask > 255 > > > > > > > > > 9572.672147659:7f07be402910: Called action, logging to > > > > builtin- > > > > > > file > > > > > > > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from > > > > 'trebuchet', > > > > > > msg > > > > > > > > > rsyslogd's userid changed to 101 > > > > > > > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog > > > > format. > > > > > > > > > 9572.672192329:7f07be402910: extend buf to at least > 138, > > > done > > > > > 256 > > > > > > > > > 9572.672200766:7f07be402910: file to log to: > > > /var/log/syslog > > > > > > > > > > > > > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > > > > > > > > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > > > > > > > transitioning > > > > > > > > to > > > > > > > > > regular run mode > > > > > > > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd > > > socket > > > > 4 > > > > > > > > > (IPv4/port 514). > > > > > > > > > 9572.672576606:7f07bc3fe910: --------imUDP calling > > select, > > > > > active > > > > > > > > file > > > > > > > > > descriptors (max 4): 4 > > > > > > > > > 9572.672594858:7f07bdc01910: --------imuxsock calling > > > select, > > > > > > > active > > > > > > > > > file descriptors (max 5): 3 5 > > > > > > > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers > signals > > > busy > > > > > > > > > 9572.672646478:7f07bbbfd910: caller requested object > > > > > 'nsd_ptcp', > > > > > > > not > > > > > > > > > found (iRet -3003) > > > > > > > > > 9572.672663716:7f07bbbfd910: Requested to load module > > > > > > 'lmnsd_ptcp' > > > > > > > > > 9572.672671184:7f07bbbfd910: loading module > > > > > > > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > > > > > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c > > > requested > > > > > > > > reference > > > > > > > > > for module 'lmnetstrms', reference count now 4 > > > > > > > > > 9572.672757197:7f07bbbfd910: module of type 2 being > > loaded. > > > > > > > > > 9572.672763826:7f07bbbfd910: source file netstrms.c > > > requested > > > > > > > > reference > > > > > > > > > for module 'lmnsd_ptcp', reference count now 1 > > > > > > > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket > > on > > > > port > > > > > > 514 > > > > > > > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp > > > > > socketWe > > > > > > > > could > > > > > > > > > initialize 0 TCP listen sockets out of 1 we recei > > > > > > > > > ved - this may or may not be an error indication. > > > > > > > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets > could > > > > > > > successfully > > > > > > > > > be > > > > > > > > > initializedCalled LogError, msg: Could not crea > > > > > > > > > te tcp listener, ignoring port 514. > > > > > > > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from > > > > 'trebuchet', > > > > > > msg > > > > > > > > > Could not create tcp listener, ignoring port 514. [t > > > > > > > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > rsyslog mailing list > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > http://www.rsyslog.com > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From jkempf at davisvision.com Tue Apr 27 04:15:46 2010 From: jkempf at davisvision.com (Jesse Kempf) Date: Tue, 27 Apr 2010 02:15:46 +0000 Subject: [rsyslog] Solaris SMF Manifest Message-ID: <13819_1272334548_4BD648D3_13819_1145_1_4BD648D2.4090408@davisvision.com> Hi, So I've been working on getting rsyslogd set up on a Solaris platform (not as a local syslog replacement, but as the central syslog server for a network). Attached is a patchset which adds a Solaris SMF service manifest (rsyslog.xml) and method script (svc-rsyslog). I'm not sure how exactly to wire this into the install process, so I'll describe what needs to get done. svc-rsyslog needs to be kicked into $PREFIX/etc and be chmod +x. rsyslog.xml needs the literal string 'PREFIX' replaced with $PREFIX, and then passed to svccfg import. Something as simple as 'sed "s#PREFIX#$PREFIX#g" < rsyslog.xml | svccfg import -' would do the trick. The manifest registers rsyslog with SMF under the FMRI svc:/network/rsyslog:default. The properties (accessible using svcprop) 'rsyslog/conf' and 'rsyslog/opts' contain the path to the config file and any command-line options for rsyslog respectively. I've also updated http://wiki.rsyslog.com/index.php/Solaris based on my experiences getting rsyslog working on Solaris 10. All in all, this has been much, MUCH easier than it was when I tried two years ago. Cheers, -Jesse ------------------------------------------------------------------------ The information contained in this communication is intended only for the use of the recipient(s) named above. It may contain information that is privileged or confidential, and may be protected by State and/or Federal Regulations. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. ------------------------------------------------------------------------ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: solaris-smf.patches URL: From gbonser at seven.com Tue Apr 27 23:42:30 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 27 Apr 2010 14:42:30 -0700 Subject: [rsyslog] Question about output channels Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE73B3@RWC-EX1.corp.seven.com> When an output channel runs a rotation script due to file size limit being reached, does it pass anything in the environment to tell a log rotation program which file triggered the rotation? That would be handy by allowing a single rotation script to handle all the output channels if it could pick up the file to rotate from the environment when it is run. George From jkempf at davisvision.com Wed Apr 28 18:38:55 2010 From: jkempf at davisvision.com (Jesse Kempf) Date: Wed, 28 Apr 2010 16:38:55 +0000 Subject: [rsyslog] Tuning reconnect delay Message-ID: <13016_1272472735_4BD8649F_13016_205_1_4BD8649F.90508@davisvision.com> Hi, Is there any way to adjust how long rsyslog will wait to reconnect after a TCP session to a remote server has been closed? I looked through the documentation but nothing jumped out at me. Thanks, -Jesse ------------------------------------------------------------------------ The information contained in this communication is intended only for the use of the recipient(s) named above. It may contain information that is privileged or confidential, and may be protected by State and/or Federal Regulations. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. ------------------------------------------------------------------------ From b.arenal at gmail.com Thu Apr 29 19:07:04 2010 From: b.arenal at gmail.com (Bryan Arenal) Date: Thu, 29 Apr 2010 11:07:04 -0600 Subject: [rsyslog] Running in debug mode: -1 bytes? Message-ID: Hi, I have two systems running rsyslog 4.2.0 and snort 2.8.5.3. ?On one of those systems, it's forwarding snort's alert logs to our central log server correctly. ?On the second box (that has the same snort and rsyslog configs), it has only forwarded one alert but the alert file is seeing a lot of data so I don't know what's going on. ?I put rsyslog in debug mode and every 10 secs, it logs the following message: ?4478.108169000:41851940: strm 0x1e8b5dd0: file 6 read -1 bytes ?4478.108225000:41851940: strm 0x1e8b6fc0: file 7 read 0 bytes What does that mean? ?It appears that the only time it deviated was when it sent the one alert to the syslog server: ?4148.075280000:41851940: strm 0x1e8b6fc0: file 7 read 225 bytes But the file that it's referring to as "file 6" is seeing much more data than "file 7" and it shouldn't have any problem reading it as it's 644 and owned by snort.snort (rsyslog is running as root). ?Does anyone know what might be going on or have anything I can try? Thanks! Bryan From darrick.harter at gmail.com Fri Apr 30 19:09:04 2010 From: darrick.harter at gmail.com (Darrick Harter) Date: Fri, 30 Apr 2010 12:09:04 -0500 Subject: [rsyslog] Striping off part of a hostname in a template file Message-ID: I am trying to strip out parts of a hostname for logs that come in from my firewalls. So with each firewall that I have, I effectively have a pair, and "a" and a "b" firewall. For this example, I will call them firewalla and firewallb. Is there a way to strip the 'a' or 'b' off the filename that it's being written to dynamically? I have done this as an example, and it works as I expect it to: $template DYNfirewalllog,"/path/to/logs/firewall/%$YEAR%%$MONTH%%$DAY%-iptables.log" if \ $source == 'firewalla' \ or \ $source == 'firewallb' \ and \ $msg contains 'IN=' \ then ?DYNfirewalllog I have tried doing things similar to this, that effectively don't match at all, the regex works fine on the online checker, but I get a directory created called "**NO MATCH**" when I try to use this in practice. $template DYNfirewall,"/path/to/logs/%hostname:R,ERE,0,DFLT:.\\s[a-z].*[fw|ids]0[0-9]--end%/%$YEAR%%$MONTH%%$DAY%-iptables.log" if \ $msg contains 'IN=' \ then ?DYNfirewall If I only had a few firewalls, then this wouldn't be a big deal, I could simply add a new entry for each firewall pair. However, I currently am managing 180 firewalls... or 90 pairs, and we are still growing, so I'm looking for something a bit more dynamic if you will when it comes to managing it. Any ideas would be greatly appreciated! From jiri.hlinka at gmail.com Fri Apr 2 00:52:03 2010 From: jiri.hlinka at gmail.com (=?UTF-8?B?SmnFmcOtIEhsaW5rYQ==?=) Date: Fri, 2 Apr 2010 00:52:03 +0200 Subject: [rsyslog] RHEL 5.5 and rsyslog packages Message-ID: Hi, RHEL 5.5 was released recently and it includes updated rsyslog version too. As many of you may know, up to RHEL 5.4 there was rsyslog version 2.0.6 which is rather old and unsupported. But changes have been made in RHEL 5 update 5: it includes package rsyslog (+ rsyslog-[module_name], see below) version 3.22.1. But there is yet another rsyslog version - package rsyslog4 (+ rsyslog4-[module_name]) serves version 4.4.2! Modules included in separated rpms: gnutls gssapi mysql pgsql relp (just for rsyslog4 package) Well, these are not the latest ones, but it is progredss indeed :-) . Cheers, Jirka -- Ji?? Hlinka GSM: +420 773 103 947 Enlogit s.r.o., U Cukrovaru 509/4, 400 07 ?st? nad Labem tel.: +420 474 745 159, fax: +420 474 745 160 web: www.enlogit.cz Enlogit IT pro firmy From joel.sinor at gmail.com Sun Apr 4 04:07:59 2010 From: joel.sinor at gmail.com (Joel Sinor) Date: Sat, 3 Apr 2010 21:07:59 -0500 Subject: [rsyslog] Could not open dynamic file ... - discarding message Message-ID: Hello, I was reading up on this error (Could not open dynamic file) which occurred when I tried to use dynamic files, and found the following post: http://www.mail-archive.com/rsyslog at lists.adiscon.com/msg02505.html Now, I run Ubuntu, and the PrivDrop statements are in the rsyslog.conf by default on that distribution. The problem is further described in an Ubuntu bug (although the only Ubuntu-specific problem here is the PrivDrop statements being default on that distribution): https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/484336 The relevant lines in rsyslog.conf are: # # Set the default permissions for all log files. # $FileOwner syslog $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 $PrivDropToUser syslog $PrivDropToGroup syslog What happens is rsyslog is able to create the dynamic files, but it cannot access them to write to them, as described in the emails earlier on the list. I found that when I created a directory for these files, with 755 permissions owned by syslog and group syslog. The files would get created with 640 permissions owned by syslog:syslog and yet rsyslog would not be able to write to them. Rather than lose the safety provided by PrivDrop I found, based on the bug report above, that all you have to do is change the group to adm and it works: # # Set the default permissions for all log files. # $FileOwner syslog $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 $PrivDropToUser syslog $PrivDropToGroup adm Then the log files end up being owned by syslog:adm instead of syslog:syslog and rsyslog is able to write to them. I am not sure why this works. What's even more puzzling is that at least on my system (Ubuntu 9.10) syslog is not part of the adm group at all. I'm guessing that when you call the function to drop privileges to a group it doesn't care whether the user you drop to is part of the group you drop to. It is funny though. Anyway I am sending this out in hope that others might benefit from not having to completely dump PrivDrop, and that maybe some light will be shed on why this mechanism is not working properly in this case. It does not make sense that having the right owner still does not result in being able to write to and open files, and that you have to change the group to adm. It seems to me that there is some problem internal to rsyslog that is causing this to happen. From tbergfeld at hq.adiscon.com Fri Apr 9 14:46:08 2010 From: tbergfeld at hq.adiscon.com (Tom Bergfeld) Date: Fri, 9 Apr 2010 14:46:08 +0200 Subject: [rsyslog] rsyslog 5.5.3 (devel) released Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103C2A@GRFEXC.intern.adiscon.com> Hi all, We have just released rsyslog 5.5.3, a member of the devel branch. This is a bug-fixing release containing some important fixes and also the added basic but functional support for Solaris. Furthermore there are some imported patches from 4.6.0. It is a recommended update for all users of the devel branch. See Changelog for more details. ChangeLog: http://www.rsyslog.com/Article450.phtml Download: http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-199.phtml As always, feedback is appreciated. Best regards, Tom Bergfeld -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com From tbergfeld at hq.adiscon.com Wed Apr 14 16:46:52 2010 From: tbergfeld at hq.adiscon.com (Tom Bergfeld) Date: Wed, 14 Apr 2010 16:46:52 +0200 Subject: [rsyslog] rsyslog 4.7.0 (v4-devel) released Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103C74@GRFEXC.intern.adiscon.com> Hi all, We have just released rsyslog 4.7.0, a member of the v4-devel branch. This release offers Solaris support and also some fixes and enhancements. All the details you will find in 'Rainer's Blog' http://blog.gerhards.net/2010/04/v4-devel-is-back-again.html and of course in the Changelog. ChangeLog: http://www.rsyslog.com/Article453.phtml Download: http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-200.phtml As always, feedback is appreciated. Best regards, Tom Bergfeld -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com From kristian.jones at ntlworld.com Mon Apr 19 11:24:20 2010 From: kristian.jones at ntlworld.com (kristian.jones at ntlworld.com) Date: Mon, 19 Apr 2010 10:24:20 +0100 Subject: [rsyslog] iptables and centralised logs with rsyslog and UDP Message-ID: <20100419102420.T3NO6.126539.root@web01-winn.ispmail.private.ntl.com> Hi All, I have a problem that I'm not sure how to get around. I have 3 machines, a client, a firewall and a log store. The firewall is Linux running iptables. The client and log store are on different networks (X.X.4.X) and (X.X.5.X). The firewall is used to bridge these networks. I've configured rsyslog on the client (.4.) to send messages to the log store (.5.) I've also configured a template on the log store to print the $fromhost-ip and original raw message and I'm printing everything (*.*) to the log files. When the firewall rewrites the source address (so they appear to be coming from the .5.x network), the messages get logged. If I leave the source address alone, the messages disappear. I know the packets are arriving at the log store with both configurations because I can see this with TCPDUMP on the log store. On the firewall I have the following configuration that I've put together. iptables -A POSTROUTING -t nat -o eth1 -j ACCEPT iptables -A PREROUTING -t nat -i -p udp --dport 514 -j DNAT --to-destination X.X.5.X (On my actual config the Xs are not blanked out). Unfortunately with this rule in place I do not see anything in the log file. Changing the first line of the iptables config to iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE means that I can now see output getting to my log files but the ipaddress is incorrect. Is this a bug? or Is rsyslog doing some intelligent work under the hood to detect ip address spoofing? I'm using ubuntu server 9.10. Unfortunately using the hostname instead of the ipaddress in my case is not an option Hope someone can help Kris From epiphani at gmail.com Mon Apr 19 14:24:51 2010 From: epiphani at gmail.com (Aaron Wiebe) Date: Mon, 19 Apr 2010 08:24:51 -0400 Subject: [rsyslog] iptables and centralised logs with rsyslog and UDP In-Reply-To: <20100419102420.T3NO6.126539.root@web01-winn.ispmail.private.ntl.com> References: <20100419102420.T3NO6.126539.root@web01-winn.ispmail.private.ntl.com> Message-ID: Kris, it sounds as though your iptables rules aren't working very well for you. I suggest you set up wireshark or tcpdump on the log host machine and run the test again - I bet you would find that the traffic isn't making it. In the case that the IP isn't rewritten, that is expected. You're doing NAT, so rsyslog would have no other detail about the remote host you are originally delivering the data from. At this point I think most of your problems are iptables related, and not really rsyslog related. -Aaron On Mon, Apr 19, 2010 at 5:24 AM, wrote: > Hi All, > > I have a problem that I'm not sure how to get around. > > I have 3 machines, a client, a firewall and a log store. The firewall is Linux running iptables. The client and log store are on different networks (X.X.4.X) and (X.X.5.X). The firewall is used to bridge these networks. > > I've configured rsyslog on the client (.4.) to send messages to the log store (.5.) I've also configured a template on the log store to print the $fromhost-ip and original raw message and I'm printing everything (*.*) to the log files. > > When the firewall rewrites the source address (so they appear to be coming from the .5.x network), the messages get logged. If I leave the source address alone, the messages disappear. I know the packets are arriving at the log store with both configurations because I can see this with TCPDUMP on the log store. > > On the firewall I have the following configuration that I've put together. > > iptables -A POSTROUTING -t nat -o eth1 -j ACCEPT > iptables -A PREROUTING -t nat -i -p udp --dport 514 -j DNAT --to-destination X.X.5.X > > (On my actual config the Xs are not blanked out). > > Unfortunately with this rule in place I do not see anything in the log file. > > Changing the first line of the iptables config to > > iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE > > means that I can now see output getting to my log files but the ipaddress is incorrect. > > Is this a bug? or Is rsyslog doing some intelligent work under the hood to detect ip address spoofing? I'm using ubuntu server 9.10. Unfortunately using the hostname instead of the ipaddress in my case is not an option > > Hope someone can help > Kris > > > > > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From kristian.jones at ntlworld.com Mon Apr 19 16:05:26 2010 From: kristian.jones at ntlworld.com (kristian.jones at ntlworld.com) Date: Mon, 19 Apr 2010 15:05:26 +0100 Subject: [rsyslog] iptables and centralised logs with rsyslog and UDP In-Reply-To: Message-ID: <20100419150526.JOYOF.92148.root@web02-winn.ispmail.private.ntl.com> Hi Aaron, I've ran tcpdump on the log store (not the client) and I can see the packets hitting the server, it seems to be rsyslog thats not picking them up. Using tcpdump and the first iptables config, gives the correct ip address when tcpdump is run on the log store, but no message is shown in the log files. Using tcpdump and the second iptables config, gives the ip address of firewall when tcpdump is run on the log store and the message appears in log file on disk. Hopefully that makes it a little more clear but apologies if I misunderstood the reply Thanks Kris ---- Aaron Wiebe wrote: > Kris, it sounds as though your iptables rules aren't working very > well for you. I suggest you set up wireshark or tcpdump on the log > host machine and run the test again - I bet you would find that the > traffic isn't making it. In the case that the IP isn't rewritten, > that is expected. You're doing NAT, so rsyslog would have no other > detail about the remote host you are originally delivering the data > from. > > At this point I think most of your problems are iptables related, and > not really rsyslog related. > > -Aaron > > On Mon, Apr 19, 2010 at 5:24 AM, wrote: > > Hi All, > > > > I have a problem that I'm not sure how to get around. > > > > I have 3 machines, a client, a firewall and a log store. The firewall is Linux running iptables. The client and log store are on different networks (X.X.4.X) and (X.X.5.X). The firewall is used to bridge these networks. > > > > I've configured rsyslog on the client (.4.) to send messages to the log store (.5.) I've also configured a template on the log store to print the $fromhost-ip and original raw message and I'm printing everything (*.*) to the log files. > > > > When the firewall rewrites the source address (so they appear to be coming from the .5.x network), the messages get logged. If I leave the source address alone, the messages disappear. I know the packets are arriving at the log store with both configurations because I can see this with TCPDUMP on the log store. > > > > On the firewall I have the following configuration that I've put together. > > > > iptables -A POSTROUTING -t nat -o eth1 -j ACCEPT > > iptables -A PREROUTING -t nat -i -p udp --dport 514 -j DNAT --to-destination X.X.5.X > > > > (On my actual config the Xs are not blanked out). > > > > Unfortunately with this rule in place I do not see anything in the log file. > > > > Changing the first line of the iptables config to > > > > iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE > > > > means that I can now see output getting to my log files but the ipaddress is incorrect. > > > > Is this a bug? or Is rsyslog doing some intelligent work under the hood to detect ip address spoofing? I'm using ubuntu server 9.10. Unfortunately using the hostname instead of the ipaddress in my case is not an option > > > > Hope someone can help > > Kris > > > > > > > > > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From epiphani at gmail.com Mon Apr 19 16:13:30 2010 From: epiphani at gmail.com (Aaron Wiebe) Date: Mon, 19 Apr 2010 10:13:30 -0400 Subject: [rsyslog] iptables and centralised logs with rsyslog and UDP In-Reply-To: <20100419150526.JOYOF.92148.root@web02-winn.ispmail.private.ntl.com> References: <20100419150526.JOYOF.92148.root@web02-winn.ispmail.private.ntl.com> Message-ID: Can you provide more details about what you see in tcpdump and what your configuration of rsyslog is? Aaron On Mon, Apr 19, 2010 at 10:05 AM, wrote: > Hi Aaron, > I've ran tcpdump on the log store (not the client) and I can see the packets hitting the server, it seems to be rsyslog thats not picking them up. > > Using tcpdump and the first iptables config, gives the correct ip address when tcpdump is run on the log store, but no message is shown in the log files. > > Using tcpdump and the second iptables config, gives the ip address of firewall when tcpdump is run on the log store and the message appears in log file on disk. > > Hopefully that makes it a little more clear but apologies if I misunderstood the reply > > Thanks > Kris > ---- Aaron Wiebe wrote: >> Kris, ?it sounds as though your iptables rules aren't working very >> well for you. ?I suggest you set up wireshark or tcpdump on the log >> host machine and run the test again - I bet you would find that the >> traffic isn't making it. ?In the case that the IP isn't rewritten, >> that is expected. ?You're doing NAT, so rsyslog would have no other >> detail about the remote host you are originally delivering the data >> from. >> >> At this point I think most of your problems are iptables related, and >> not really rsyslog related. >> >> -Aaron >> >> On Mon, Apr 19, 2010 at 5:24 AM, ? wrote: >> > Hi All, >> > >> > I have a problem that I'm not sure how to get around. >> > >> > I have 3 machines, a client, a firewall and a log store. The firewall is Linux running iptables. The client and log store are on different networks (X.X.4.X) and (X.X.5.X). The firewall is used to bridge these networks. >> > >> > I've configured rsyslog on the client (.4.) to send messages to the log store (.5.) I've also configured a template on the log store to print the $fromhost-ip and original raw message and I'm printing everything (*.*) to the log files. >> > >> > When the firewall rewrites the source address (so they appear to be coming from the .5.x network), the messages get logged. If I leave the source address alone, the messages disappear. I know the packets are arriving at the log store with both configurations because I can see this with TCPDUMP on the log store. >> > >> > On the firewall I have the following configuration that I've put together. >> > >> > iptables -A POSTROUTING -t nat -o eth1 -j ACCEPT >> > iptables -A PREROUTING -t nat -i -p udp --dport 514 -j DNAT --to-destination X.X.5.X >> > >> > (On my actual config the Xs are not blanked out). >> > >> > Unfortunately with this rule in place I do not see anything in the log file. >> > >> > Changing the first line of the iptables config to >> > >> > iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE >> > >> > means that I can now see output getting to my log files but the ipaddress is incorrect. >> > >> > Is this a bug? or Is rsyslog doing some intelligent work under the hood to detect ip address spoofing? I'm using ubuntu server 9.10. Unfortunately using the hostname instead of the ipaddress in my case is not an option >> > >> > Hope someone can help >> > Kris >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > rsyslog mailing list >> > http://lists.adiscon.net/mailman/listinfo/rsyslog >> > http://www.rsyslog.com >> > >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > > From david at lang.hm Mon Apr 19 18:57:48 2010 From: david at lang.hm (david at lang.hm) Date: Mon, 19 Apr 2010 09:57:48 -0700 (PDT) Subject: [rsyslog] iptables and centralised logs with rsyslog and UDP In-Reply-To: <20100419150526.JOYOF.92148.root@web02-winn.ispmail.private.ntl.com> References: <20100419150526.JOYOF.92148.root@web02-winn.ispmail.private.ntl.com> Message-ID: do you have a route from the box running rsyslog to the source IP addresses that the logs are comeing from? if you don't then even though you see them in a tcpdump, your applications will not see the packets (there is a config option in linux to disable this feature) David Lang On Mon, 19 Apr 2010, kristian.jones at ntlworld.com wrote: > Date: Mon, 19 Apr 2010 15:05:26 +0100 > From: kristian.jones at ntlworld.com > Reply-To: rsyslog-users > To: rsyslog-users > Subject: Re: [rsyslog] iptables and centralised logs with rsyslog and UDP > > Hi Aaron, > I've ran tcpdump on the log store (not the client) and I can see the packets hitting the server, it seems to be rsyslog thats not picking them up. > > Using tcpdump and the first iptables config, gives the correct ip address when tcpdump is run on the log store, but no message is shown in the log files. > > Using tcpdump and the second iptables config, gives the ip address of firewall when tcpdump is run on the log store and the message appears in log file on disk. > > Hopefully that makes it a little more clear but apologies if I misunderstood the reply > > Thanks > Kris > ---- Aaron Wiebe wrote: >> Kris, it sounds as though your iptables rules aren't working very >> well for you. I suggest you set up wireshark or tcpdump on the log >> host machine and run the test again - I bet you would find that the >> traffic isn't making it. In the case that the IP isn't rewritten, >> that is expected. You're doing NAT, so rsyslog would have no other >> detail about the remote host you are originally delivering the data >> from. >> >> At this point I think most of your problems are iptables related, and >> not really rsyslog related. >> >> -Aaron >> >> On Mon, Apr 19, 2010 at 5:24 AM, wrote: >>> Hi All, >>> >>> I have a problem that I'm not sure how to get around. >>> >>> I have 3 machines, a client, a firewall and a log store. The firewall is Linux running iptables. The client and log store are on different networks (X.X.4.X) and (X.X.5.X). The firewall is used to bridge these networks. >>> >>> I've configured rsyslog on the client (.4.) to send messages to the log store (.5.) I've also configured a template on the log store to print the $fromhost-ip and original raw message and I'm printing everything (*.*) to the log files. >>> >>> When the firewall rewrites the source address (so they appear to be coming from the .5.x network), the messages get logged. If I leave the source address alone, the messages disappear. I know the packets are arriving at the log store with both configurations because I can see this with TCPDUMP on the log store. >>> >>> On the firewall I have the following configuration that I've put together. >>> >>> iptables -A POSTROUTING -t nat -o eth1 -j ACCEPT >>> iptables -A PREROUTING -t nat -i -p udp --dport 514 -j DNAT --to-destination X.X.5.X >>> >>> (On my actual config the Xs are not blanked out). >>> >>> Unfortunately with this rule in place I do not see anything in the log file. >>> >>> Changing the first line of the iptables config to >>> >>> iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE >>> >>> means that I can now see output getting to my log files but the ipaddress is incorrect. >>> >>> Is this a bug? or Is rsyslog doing some intelligent work under the hood to detect ip address spoofing? I'm using ubuntu server 9.10. Unfortunately using the hostname instead of the ipaddress in my case is not an option >>> >>> Hope someone can help >>> Kris >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From kristian.jones at ntlworld.com Tue Apr 20 10:03:20 2010 From: kristian.jones at ntlworld.com (kristian.jones at ntlworld.com) Date: Tue, 20 Apr 2010 9:03:20 +0100 Subject: [rsyslog] iptables and centralised logs with rsyslog and UDP In-Reply-To: Message-ID: <20100420090320.SUDNV.155925.root@web05-winn.ispmail.private.ntl.com> Thanks David, Adding the routes solved my issue. Kris ---- david at lang.hm wrote: > do you have a route from the box running rsyslog to the source IP > addresses that the logs are comeing from? if you don't then even though > you see them in a tcpdump, your applications will not see the packets > (there is a config option in linux to disable this feature) > > David Lang > > On Mon, 19 Apr > 2010, kristian.jones at ntlworld.com wrote: > > > Date: Mon, 19 Apr 2010 15:05:26 +0100 > > From: kristian.jones at ntlworld.com > > Reply-To: rsyslog-users > > To: rsyslog-users > > Subject: Re: [rsyslog] iptables and centralised logs with rsyslog and UDP > > > > Hi Aaron, > > I've ran tcpdump on the log store (not the client) and I can see the packets hitting the server, it seems to be rsyslog thats not picking them up. > > > > Using tcpdump and the first iptables config, gives the correct ip address when tcpdump is run on the log store, but no message is shown in the log files. > > > > Using tcpdump and the second iptables config, gives the ip address of firewall when tcpdump is run on the log store and the message appears in log file on disk. > > > > Hopefully that makes it a little more clear but apologies if I misunderstood the reply > > > > Thanks > > Kris > > ---- Aaron Wiebe wrote: > >> Kris, it sounds as though your iptables rules aren't working very > >> well for you. I suggest you set up wireshark or tcpdump on the log > >> host machine and run the test again - I bet you would find that the > >> traffic isn't making it. In the case that the IP isn't rewritten, > >> that is expected. You're doing NAT, so rsyslog would have no other > >> detail about the remote host you are originally delivering the data > >> from. > >> > >> At this point I think most of your problems are iptables related, and > >> not really rsyslog related. > >> > >> -Aaron > >> > >> On Mon, Apr 19, 2010 at 5:24 AM, wrote: > >>> Hi All, > >>> > >>> I have a problem that I'm not sure how to get around. > >>> > >>> I have 3 machines, a client, a firewall and a log store. The firewall is Linux running iptables. The client and log store are on different networks (X.X.4.X) and (X.X.5.X). The firewall is used to bridge these networks. > >>> > >>> I've configured rsyslog on the client (.4.) to send messages to the log store (.5.) I've also configured a template on the log store to print the $fromhost-ip and original raw message and I'm printing everything (*.*) to the log files. > >>> > >>> When the firewall rewrites the source address (so they appear to be coming from the .5.x network), the messages get logged. If I leave the source address alone, the messages disappear. I know the packets are arriving at the log store with both configurations because I can see this with TCPDUMP on the log store. > >>> > >>> On the firewall I have the following configuration that I've put together. > >>> > >>> iptables -A POSTROUTING -t nat -o eth1 -j ACCEPT > >>> iptables -A PREROUTING -t nat -i -p udp --dport 514 -j DNAT --to-destination X.X.5.X > >>> > >>> (On my actual config the Xs are not blanked out). > >>> > >>> Unfortunately with this rule in place I do not see anything in the log file. > >>> > >>> Changing the first line of the iptables config to > >>> > >>> iptables -A POSTROUTING -t nat -o eth1 -j MASQUERADE > >>> > >>> means that I can now see output getting to my log files but the ipaddress is incorrect. > >>> > >>> Is this a bug? or Is rsyslog doing some intelligent work under the hood to detect ip address spoofing? I'm using ubuntu server 9.10. Unfortunately using the hostname instead of the ipaddress in my case is not an option > >>> > >>> Hope someone can help > >>> Kris > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> rsyslog mailing list > >>> http://lists.adiscon.net/mailman/listinfo/rsyslog > >>> http://www.rsyslog.com > >>> > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From tom at ng23.net Tue Apr 20 11:47:48 2010 From: tom at ng23.net (Tom Brown) Date: Tue, 20 Apr 2010 10:47:48 +0100 Subject: [rsyslog] Configuration Help Message-ID: Hi - i posted this on the forum but i wonder of the maillist gets more traffic I am sending syslog data from a number of hosts to a central rsyslog box and everything is working but i have a basic configuration query. I currently log to /logs///*.log which is working fine but i am lacking a parameter in each log. The logs are appearing in the correct directory but my munging scripts rely on knowing what host each log comes from but as this is not appearing in the actual log then this makes things difficult. Does anyone have any pointers for achieving that, right now an example of a log would be # cat 20100419--authpriv.log pam_unix(su-l:session): session closed for user root pam_unix(sshd:session): session closed for user XXXXXX and ideally this would read # cat 20100419--authpriv.log pam_unix(su-l:session): session closed for user root pam_unix(sshd:session): session closed for user XXXXXX thanks From david at lang.hm Tue Apr 20 18:50:08 2010 From: david at lang.hm (david at lang.hm) Date: Tue, 20 Apr 2010 09:50:08 -0700 (PDT) Subject: [rsyslog] Configuration Help In-Reply-To: References: Message-ID: On Tue, 20 Apr 2010, Tom Brown wrote: > Hi - i posted this on the forum but i wonder of the maillist gets more > traffic > > > I am sending syslog data from a number of hosts to a central rsyslog box and > everything is working but i have a basic configuration query. > I currently log to /logs///*.log which is working fine but i > am lacking a parameter in each log. The logs are appearing in the > correct directory but my munging scripts rely on knowing what > host each log comes from but as this is not appearing in the actual log then > this makes things difficult. Does anyone have any pointers for achieving > that, right now an example of a log would be > > # cat 20100419--authpriv.log > pam_unix(su-l:session): session closed for user root > pam_unix(sshd:session): session closed for user XXXXXX > > and ideally this would read > > # cat 20100419--authpriv.log > pam_unix(su-l:session): session closed for user root > pam_unix(sshd:session): session closed for user XXXXXX what is your current configuration? it sounds like you need to change the format string to include the hostname. David Lang From tom at ng23.net Tue Apr 20 19:18:50 2010 From: tom at ng23.net (Tom Brown) Date: Tue, 20 Apr 2010 18:18:50 +0100 Subject: [rsyslog] Configuration Help In-Reply-To: References: Message-ID: > > what is your current configuration? > > it sounds like you need to change the format string to include the > hostname. > > thanks for the response - i did not setup this system so am not hugely familiar with it however would i need to be looking at the Log processing templates or the Output filename templates or neither? Currently we have something like # Log processing templates $template fmtStripLeadingSpace,"%msg:R,ERE,1,DFLT: (.*)--end%\n" # Output filename templates $template SystemLogFile,"/logs/syslog/%hostname%/%timereported:1:4:date-mysql%/%timereported:1:6:date-mysql%/%timereported:1:8:date-mysq l%/%timereported:1:8:date-mysql%-%hostname%-%syslogfacility-text%.log" any help is greatly appreciated thanks From david at lang.hm Tue Apr 20 19:35:40 2010 From: david at lang.hm (david at lang.hm) Date: Tue, 20 Apr 2010 10:35:40 -0700 (PDT) Subject: [rsyslog] Configuration Help In-Reply-To: References: Message-ID: On Tue, 20 Apr 2010, Tom Brown wrote: >> what is your current configuration? >> >> it sounds like you need to change the format string to include the >> hostname. >> >> > thanks for the response - i did not setup this system so am not hugely > familiar with it however would i need to be looking at the Log processing > templates or the Output filename templates or neither? it would be the log processing template > Currently we have something like > > > # Log processing templates > $template fmtStripLeadingSpace,"%msg:R,ERE,1,DFLT: (.*)--end%\n" try changing this to $template fmtStripLeadingSpace,"%hostname% %msg:R,ERE,1,DFLT: (.*)--end%\n" David Lang > > # Output filename templates > > $template > SystemLogFile,"/logs/syslog/%hostname%/%timereported:1:4:date-mysql%/%timereported:1:6:date-mysql%/%timereported:1:8:date-mysq > l%/%timereported:1:8:date-mysql%-%hostname%-%syslogfacility-text%.log" From tom at ng23.net Tue Apr 20 20:03:56 2010 From: tom at ng23.net (Tom Brown) Date: Tue, 20 Apr 2010 19:03:56 +0100 Subject: [rsyslog] Configuration Help In-Reply-To: References: Message-ID: > > # Log processing templates > > $template fmtStripLeadingSpace,"%msg:R,ERE,1,DFLT: (.*)--end%\n" > > try changing this to > > $template fmtStripLeadingSpace,"%hostname% %msg:R,ERE,1,DFLT: (.*)--end%\n" > many thanks - this resolved this issue From tbergfeld at hq.adiscon.com Thu Apr 22 15:57:52 2010 From: tbergfeld at hq.adiscon.com (Tom Bergfeld) Date: Thu, 22 Apr 2010 15:57:52 +0200 Subject: [rsyslog] rsyslog 4.7.1 (v4-devel) released Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CC8@GRFEXC.intern.adiscon.com> Hi all, We have just released rsyslog 4.7.1, a member of the v4-devel branch. This release improves the Solaris support. See Changelog for more details. ChangeLog: http://www.rsyslog.com/Article455.phtml Download: http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-201.phtml As always, feedback is appreciated. Best regards, Tom Bergfeld -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com From gbonser at seven.com Fri Apr 23 00:45:50 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 22 Apr 2010 15:45:50 -0700 Subject: [rsyslog] Large File Support Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE728B@RWC-EX1.corp.seven.com> I am having a strange issue. I am building rsyslog 4.6.2 on an amd64 system Configure says: rsyslog will be compiled with the following settings: Multithreading support enabled: yes Large file support enabled: yes But when I build it and do: /usr/src/rsyslog-4.6.2/tools> ./rsyslogd -v rsyslogd 4.6.2, compiled with: FEATURE_REGEXP: Yes FEATURE_LARGEFILE: No I also notice that configure reported: checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no Kernel 2.6.31 GCC 4.4.1 Libc6 2.10.1 I passed configure an explicit --enable-largefile Is there something else I must do in order to enable large file support? Thanks, George From david at lang.hm Fri Apr 23 02:45:15 2010 From: david at lang.hm (david at lang.hm) Date: Thu, 22 Apr 2010 17:45:15 -0700 (PDT) Subject: [rsyslog] Large File Support In-Reply-To: <5A6D953473350C4B9995546AFE9939EE08FE728B@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE08FE728B@RWC-EX1.corp.seven.com> Message-ID: On Thu, 22 Apr 2010, George Bonser wrote: > I am having a strange issue. I am building rsyslog 4.6.2 on an amd64 > system > > Configure says: > > rsyslog will be compiled with the following settings: > > Multithreading support enabled: yes > Large file support enabled: yes > > But when I build it and do: > > /usr/src/rsyslog-4.6.2/tools> ./rsyslogd -v > rsyslogd 4.6.2, compiled with: > FEATURE_REGEXP: Yes > FEATURE_LARGEFILE: No > > I also notice that configure reported: > > checking for special C compiler options needed for large files... no > checking for _FILE_OFFSET_BITS value needed for large files... no > > Kernel 2.6.31 > GCC 4.4.1 > Libc6 2.10.1 > > I passed configure an explicit --enable-largefile > > Is there something else I must do in order to enable large file support? 'large file support' is a work-around needed on 32 bit systems to handle files larger than 2G, on 64 bit systems it's just not needed. relax and enjoy your more advanced system ;-) David Lang From gbonser at seven.com Fri Apr 23 07:40:32 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 22 Apr 2010 22:40:32 -0700 Subject: [rsyslog] Large File Support References: <5A6D953473350C4B9995546AFE9939EE08FE728B@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE729A@RWC-EX1.corp.seven.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > > 'large file support' is a work-around needed on 32 bit systems to > handle > files larger than 2G, on 64 bit systems it's just not needed. > > relax and enjoy your more advanced system ;-) > > David Lang Hmm, ok, but when I build the Ubuntu 4.2.0 package, it does build it with such support and I can't see where any special parameter has been passed in order to do that. Just want to make sure I don't break anything trying to upgrade to 4.6.x From rgerhards at hq.adiscon.com Fri Apr 23 08:09:27 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 23 Apr 2010 08:09:27 +0200 Subject: [rsyslog] Large File Support References: <5A6D953473350C4B9995546AFE9939EE08FE728B@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE729A@RWC-EX1.corp.seven.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CCA@GRFEXC.intern.adiscon.com> > > 'large file support' is a work-around needed on 32 bit systems to > > handle > > files larger than 2G, on 64 bit systems it's just not needed. > > > > relax and enjoy your more advanced system ;-) > > > > David Lang > > Hmm, ok, but when I build the Ubuntu 4.2.0 package, it does build it > with such support and I can't see where any special parameter has been > passed in order to do that. > > Just want to make sure I don't break anything trying to upgrade to > 4.6.x You may be interested in this bug tracker, I guess a side-effect is what you see: http://bugzilla.adiscon.com/show_bug.cgi?id=182 Rainer From ralph at crongeyer.com Sat Apr 24 16:20:03 2010 From: ralph at crongeyer.com (Ralph Crongeyer) Date: Sat, 24 Apr 2010 10:20:03 -0400 Subject: [rsyslog] High cpu usage - rsyslog 5.4.0. In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA7103BBC@GRFEXC.intern.adiscon.com> References: <5fa6e0144d8003c7c72edff17f9f1675@webmail.crongeyer.com> <9B6E2A8877C38245BFB15CC491A11DA7103702@GRFEXC.intern.adiscon.com> <4BAF67C0.4000506@crongeyer.com> <4BAF710E.8080506@crongeyer.com><4BAF8773.1020000@crongeyer.com> <9B6E2A8877C38245BFB15CC491A11DA7103BAA@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103BBC@GRFEXC.intern.adiscon.com> Message-ID: <4BD2FE13.6030108@crongeyer.com> All, Sorry for the very long time for the response. I was on vaca in Mexico and had emergency surgery, I'm back now and ok. Did the fixes get merged into the 5.4.0 package? Or does it need more testing? Thanks, Ralph Rainer Gerhards wrote: > I managed to merge the v4 changes into v5-stable. Can you pull from it's git > head (git.adiscon.com/git/rsyslog.gig) and check if it works? Or do you need > a release tarball. > > Note that I need to finally fix an issue in v4 before (the released version > has an interim/work-around fix) before I can take up more work on v5, but > chances are not too bad that the issue is fixed. > > The master branch will receive the new patches ASAP, but that merge is a > little bit more complicated. > > Rainer > > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards >> Sent: Monday, March 29, 2010 7:11 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] High cpu usage - rsyslog 5.4.0. >> >> Hi, >> >> thanks for the information. I have crafted a big patch package for v4 >> the >> last two weeks. I will try to merge it in to v5 this week (I guess this >> will >> be a bit harder than usual). It may fix the issue. >> >> If you have a moment or two, it would be interesting to know if 5.5.2 >> has the >> same problem. >> >> Rainer >> >> >>> -----Original Message----- >>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>> bounces at lists.adiscon.com] On Behalf Of Ralph Crongeyer >>> Sent: Sunday, March 28, 2010 6:45 PM >>> To: rsyslog-users >>> Subject: Re: [rsyslog] High cpu usage - rsyslog 5.4.0. >>> >>> It's confirmed! >>> >>> I've been running for over an hour and a half now and: >>> load average: 0.06, 0.06, 0.02 >>> >>> Looks good so far. >>> >>> Let me know if you guys (Michael, Rainer) want me to run in debug >>> >> mode >> >>> without the lines commented out to see if I can catch the problem for >>> more troubleshooting. >>> >>> Thanks, >>> Ralph >>> >>> Ralph Crongeyer wrote: >>> >>>> Ok, >>>> I stoped rsyslog apt-get removed the 5.3.7 package, installed the >>>> >>> 5.4.0 >>> >>>> package: >>>> >>>> root at logs:/opt# aptitude show rsyslog >>>> Package: rsyslog >>>> State: installed >>>> Automatically installed: no >>>> Version: 5.4.0-1 >>>> Priority: extra >>>> Section: extra >>>> Maintainer: ralph at crongeyer.com >>>> Uncompressed Size: 3047k >>>> Depends: libc6 (>= 2.7-1), zlib1g (>= 1:1.1.4), lsb-base (>= 3.2- >>>> >> 14) >> >>>> Description: enhanced multi-threaded syslogd >>>> >>>> commented out the lines from rsyslog.conf: >>>> #daemon.*;mail.*;\ >>>> # news.err;\ >>>> # *.=debug;*.=info;\ >>>> # *.=notice;*.=warn |/dev/xconsole >>>> >>>> >>>> and restarted rsyslog: >>>> root at logs:/opt# /etc/init.d/rsyslog restart >>>> Stopping enhanced syslogd: rsyslogd. >>>> Starting enhanced syslogd: rsyslogd. >>>> >>>> I'll get back to you in about an hour. >>>> >>>> Thanks, >>>> Ralph >>>> >>>> Michael Biebl wrote: >>>> >>>> >>>>> 2010/3/28 Ralph Crongeyer : >>>>> >>>>> >>>>> >>>>>> I'm running Debian Lenny on both machines. >>>>>> >>>>>> >>>>>> >>>>> >>>>>> Is anyone else seeing high cpu loads with 5.4.0? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> I can confirm his (on Debian unstable) and already notified Rainer >>>>> about this particular issue. >>>>> Some preliminary testing here seems to indicate it's an issue with >>>>> >>> pipes. >>> >>>>> When I removed >>>>> daemon.*;mail.*;\ >>>>> news.err;\ >>>>> *.=debug;*.=info;\ >>>>> *.=notice;*.=warn |/dev/xconsole >>>>> >>>>> from my rsyslog.conf, I could no longer reproduce the problem. >>>>> >>>>> Would be interesting to know, if you can confirm this. >>>>> >>>>> Cheers, >>>>> Michael >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> -- >>> Reminds me of my expedition into the wilds of Afghanistan. We lost >>> >> our >> >>> corkscrew and were compelled to live on food and water for several >>> days. - >>> WC Fields >>> >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > -- Reminds me of my expedition into the wilds of Afghanistan. We lost our corkscrew and were compelled to live on food and water for several days. - WC Fields From gbonser at seven.com Sat Apr 24 20:19:31 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 24 Apr 2010 11:19:31 -0700 Subject: [rsyslog] Syslog over SCTP? Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE7309@RWC-EX1.corp.seven.com> Has anyone experimented with using SCTP for logging to a remote host? It seems it might have some advantages over TCP and UDP for that purpose. http://www.ibm.com/developerworks/linux/library/l-sctp/ From gbonser at seven.com Sun Apr 25 04:29:42 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 24 Apr 2010 19:29:42 -0700 Subject: [rsyslog] Syslog over SCTP? References: <5A6D953473350C4B9995546AFE9939EE08FE7309@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE7318@RWC-EX1.corp.seven.com> What I had in mind was something like an SCTP stream for each log level or each facility, haven't decided which would be most useful. That prevents head-of-line blocking as happens in TCP. So, for example, if a buffer is full of DEBUG level messages, an ALERT level message would go immediately as it is in a different stream. A separate stream could be added for RELP messages (or something like RELP or maybe an extension of it) and all of these streams would be within a single SCTP connection. Or maybe you can send RELP-like messages back across each stream in the opposite direction but having an "out of band" control channel sounds like an interesting idea and something fairly easy to do with SCTP. I would also think this lends itself well to threading of the different streams with a different thread handling different log levels (or facilities but I think dividing among log levels is probably easier). On an SMP system, a remote host sending a lot of DEGUG level messages while it is being tested would bog down one thread but other messages would be processed separately without network head-of-line blocking or CPU blocking (disk contention would be a different story, though ;) > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Saturday, April 24, 2010 11:20 AM > To: rsyslog-users > Subject: [rsyslog] Syslog over SCTP? > > Has anyone experimented with using SCTP for logging to a remote host? > It seems it might have some advantages over TCP and UDP for that > purpose. > > http://www.ibm.com/developerworks/linux/library/l-sctp/ > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Sun Apr 25 04:31:33 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 24 Apr 2010 19:31:33 -0700 Subject: [rsyslog] Syslog over SCTP? References: <5A6D953473350C4B9995546AFE9939EE08FE7309@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE7319@RWC-EX1.corp.seven.com> Oh, an interesting (to me) tutorial is here: http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb/sctp_intro. html > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Saturday, April 24, 2010 11:20 AM > To: rsyslog-users > Subject: [rsyslog] Syslog over SCTP? > > Has anyone experimented with using SCTP for logging to a remote host? > It seems it might have some advantages over TCP and UDP for that > purpose. > > http://www.ibm.com/developerworks/linux/library/l-sctp/ > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Mon Apr 26 02:23:37 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 25 Apr 2010 17:23:37 -0700 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com> Can't bind to TCP socket. The tcp module loads but I noticed that it only tries to bind the socket AFTER it has dropped is privs so it can not bind to a socket less than 1024. UDP bind works as that seems to bind immediately after module load while the prog is still running as root. If I set a tcp port >1024, it works. Could this be a race between two threads where a different thread is setting the UID/GID and a different one is binding the connections and the UID gets changed before the binding thread has a chance to get the socket? Modules being loaded: 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' 9572.648645873:7f07c0a216f0: loading module '/usr/lib/rsyslog/imudp.so' 9572.648713628:7f07c0a216f0: source file imudp.c requested reference for module 'lmnet', reference count now 4 9572.648734955:7f07c0a216f0: module of type 0 being loaded. 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports at *:514. 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' 9572.648869611:7f07c0a216f0: loading module '/usr/lib/rsyslog/imtcp.so' 9572.648938665:7f07c0a216f0: source file imtcp.c requested reference for module 'lmnet', reference count now 5 9572.648953892:7f07c0a216f0: caller requested object 'netstrm', not found (iRet -3003) 9572.648968610:7f07c0a216f0: Requested to load module 'lmnetstrms' 9572.648979310:7f07c0a216f0: loading module '/usr/lib/rsyslog/lmnetstrms.so' 9572.649053366:7f07c0a216f0: module of type 2 being loaded. 9572.649068131:7f07c0a216f0: source file imtcp.c requested reference for module 'lmnetstrms', reference count now 1 9572.649079163:7f07c0a216f0: caller requested object 'tcps_sess', not found (iRet -3003) 9572.649095086:7f07c0a216f0: Requested to load module 'lmtcpsrv' 9572.649105485:7f07c0a216f0: loading module '/usr/lib/rsyslog/lmtcpsrv.so' 9572.649188177:7f07c0a216f0: source file tcps_sess.c requested reference for module 'lmnetstrms', reference count now 2 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested reference for module 'lmnet', reference count now 6 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested reference for module 'lmnetstrms', reference count now 3 9572.649231362:7f07c0a216f0: module of type 2 being loaded. 9572.649241801:7f07c0a216f0: source file imtcp.c requested reference for module 'lmtcpsrv', reference count now 1 9572.649252009:7f07c0a216f0: source file imtcp.c requested reference for module 'lmtcpsrv', reference count now 2 9572.649287366:7f07c0a216f0: module of type 0 being loaded. 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' 9572.649321373:7f07c0a216f0: cfline: '$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat' 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction on' 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' 9572.649703828:7f07c0a216f0: uid 101 obtained for user 'syslog' 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' 9572.649840237:7f07c0a216f0: umask set to 0022. 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' 9572.649885709:7f07c0a216f0: uid 101 obtained for user 'syslog' 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup syslog' 9572.649934688:7f07c0a216f0: gid 103 obtained for group 'syslog' 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig /etc/rsyslog.d/*.conf' 9572.650017305:7f07c0a216f0: requested to include config file '/etc/rsyslog.d/50-default.conf' 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* /var/log/auth.log' GID and UID being changed: 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, lenBuf 78 9572.671902407:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg rsyslogd's groupid changed to 103 9572.671920644:7f07c0a216f0: Message has legacy syslog format. 9572.671933956:7f07be402910: testing filter, f_pmask 1 9572.671947526:7f07be402910: testing filter, f_pmask 240 9572.671957623:7f07be402910: Called action, logging to builtin-pipe 9572.671969801:7f07be402910: extend buf to at least 16, done 128 9572.671982061:7f07be402910: (/dev/xconsole) 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 entries 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised worker start 9572.672059720:7f07be402910: Action requested to be suspended, done that. 9572.672085037:7f07be402910: main Q: entry deleted, state 0, size now 1 entries 9572.672099142:7f07c0a216f0: setuid(101): 0 9572.672122289:7f07be402910: testing filter, f_pmask 0 9572.672136161:7f07be402910: testing filter, f_pmask 255 9572.672147659:7f07be402910: Called action, logging to builtin-file 9572.672162158:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg rsyslogd's userid changed to 101 9572.672179992:7f07c0a216f0: Message has legacy syslog format. 9572.672192329:7f07be402910: extend buf to at least 138, done 256 9572.672200766:7f07be402910: file to log to: /var/log/syslog UDP socket bind succeeded but TCP bind fails: 9572.672546363:7f07c0a216f0: initialization completed, transitioning to regular run mode 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket 4 (IPv4/port 514). 9572.672576606:7f07bc3fe910: --------imUDP calling select, active file descriptors (max 4): 4 9572.672594858:7f07bdc01910: --------imuxsock calling select, active file descriptors (max 5): 3 5 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy 9572.672646478:7f07bbbfd910: caller requested object 'nsd_ptcp', not found (iRet -3003) 9572.672663716:7f07bbbfd910: Requested to load module 'lmnsd_ptcp' 9572.672671184:7f07bbbfd910: loading module '/usr/lib/rsyslog/lmnsd_ptcp.so' 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested reference for module 'lmnetstrms', reference count now 4 9572.672757197:7f07bbbfd910: module of type 2 being loaded. 9572.672763826:7f07bbbfd910: source file netstrms.c requested reference for module 'lmnsd_ptcp', reference count now 1 9572.672770522:7f07bbbfd910: creating tcp listen socket on port 514 9572.672803781:7f07bbbfd910: error 13 while binding tcp socketWe could initialize 0 TCP listen sockets out of 1 we recei ved - this may or may not be an error indication. 9572.672824933:7f07bbbfd910: No TCP listen sockets could successfully be initializedCalled LogError, msg: Could not crea te tcp listener, ignoring port 514. 9572.672844597:7f07bbbfd910: logmsg: flags 1, from 'trebuchet', msg Could not create tcp listener, ignoring port 514. [t ry http://www.rsyslog.com/e/2077 ] From rgerhards at hq.adiscon.com Mon Apr 26 08:18:27 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Apr 2010 08:18:27 +0200 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com> The privilege drop code is still a hack. It needs proper engineering (as stated in the doc). So it could very well be a race in this regard. On the other hand, it does not look so. Could you send me complete debug logs to my private email address both with and without privilege drop inside your config. Maybe it is a simple thing, then I could fix it without the large effort really required. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Monday, April 26, 2010 2:24 AM > To: rsyslog-users > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > Can't bind to TCP socket. The tcp module loads but I noticed that it > only tries to bind the socket AFTER it has dropped is privs so it can > not bind to a socket less than 1024. UDP bind works as that seems to > bind immediately after module load while the prog is still running as > root. If I set a tcp port >1024, it works. Could this be a race > between > two threads where a different thread is setting the UID/GID and a > different one is binding the connections and the UID gets changed > before > the binding thread has a chance to get the socket? > > Modules being loaded: > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' > 9572.648645873:7f07c0a216f0: loading module '/usr/lib/rsyslog/imudp.so' > 9572.648713628:7f07c0a216f0: source file imudp.c requested reference > for > module 'lmnet', reference count now 4 > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports at *:514. > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' > 9572.648869611:7f07c0a216f0: loading module '/usr/lib/rsyslog/imtcp.so' > 9572.648938665:7f07c0a216f0: source file imtcp.c requested reference > for > module 'lmnet', reference count now 5 > 9572.648953892:7f07c0a216f0: caller requested object 'netstrm', not > found (iRet -3003) > 9572.648968610:7f07c0a216f0: Requested to load module 'lmnetstrms' > 9572.648979310:7f07c0a216f0: loading module > '/usr/lib/rsyslog/lmnetstrms.so' > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > 9572.649068131:7f07c0a216f0: source file imtcp.c requested reference > for > module 'lmnetstrms', reference count now 1 > 9572.649079163:7f07c0a216f0: caller requested object 'tcps_sess', not > found (iRet -3003) > 9572.649095086:7f07c0a216f0: Requested to load module 'lmtcpsrv' > 9572.649105485:7f07c0a216f0: loading module > '/usr/lib/rsyslog/lmtcpsrv.so' > 9572.649188177:7f07c0a216f0: source file tcps_sess.c requested > reference > for module 'lmnetstrms', reference count now 2 > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested reference > for module 'lmnet', reference count now 6 > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested reference > for module 'lmnetstrms', reference count now 3 > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > 9572.649241801:7f07c0a216f0: source file imtcp.c requested reference > for > module 'lmtcpsrv', reference count now 1 > 9572.649252009:7f07c0a216f0: source file imtcp.c requested reference > for > module 'lmtcpsrv', reference count now 2 > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' > 9572.649321373:7f07c0a216f0: cfline: '$ActionFileDefaultTemplate > RSYSLOG_TraditionalFileFormat' > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction on' > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > 9572.649703828:7f07c0a216f0: uid 101 obtained for user 'syslog' > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > 9572.649840237:7f07c0a216f0: umask set to 0022. > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' > 9572.649885709:7f07c0a216f0: uid 101 obtained for user 'syslog' > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup syslog' > 9572.649934688:7f07c0a216f0: gid 103 obtained for group 'syslog' > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > /etc/rsyslog.d/*.conf' > 9572.650017305:7f07c0a216f0: requested to include config file > '/etc/rsyslog.d/50-default.conf' > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > /var/log/auth.log' > > GID and UID being changed: > > 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, lenBuf 78 > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg > rsyslogd's groupid changed to 103 > 9572.671920644:7f07c0a216f0: Message has legacy syslog format. > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > 9572.671957623:7f07be402910: Called action, logging to builtin-pipe > 9572.671969801:7f07be402910: extend buf to at least 16, done 128 > 9572.671982061:7f07be402910: (/dev/xconsole) > 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 entries > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised worker start > 9572.672059720:7f07be402910: Action requested to be suspended, done > that. > 9572.672085037:7f07be402910: main Q: entry deleted, state 0, size now 1 > entries > 9572.672099142:7f07c0a216f0: setuid(101): 0 > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > 9572.672147659:7f07be402910: Called action, logging to builtin-file > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg > rsyslogd's userid changed to 101 > 9572.672179992:7f07c0a216f0: Message has legacy syslog format. > 9572.672192329:7f07be402910: extend buf to at least 138, done 256 > 9572.672200766:7f07be402910: file to log to: /var/log/syslog > > UDP socket bind succeeded but TCP bind fails: > > 9572.672546363:7f07c0a216f0: initialization completed, transitioning to > regular run mode > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket 4 > (IPv4/port 514). > 9572.672576606:7f07bc3fe910: --------imUDP calling select, active file > descriptors (max 4): 4 > 9572.672594858:7f07bdc01910: --------imuxsock calling select, active > file descriptors (max 5): 3 5 > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy > 9572.672646478:7f07bbbfd910: caller requested object 'nsd_ptcp', not > found (iRet -3003) > 9572.672663716:7f07bbbfd910: Requested to load module 'lmnsd_ptcp' > 9572.672671184:7f07bbbfd910: loading module > '/usr/lib/rsyslog/lmnsd_ptcp.so' > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested reference > for module 'lmnetstrms', reference count now 4 > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > 9572.672763826:7f07bbbfd910: source file netstrms.c requested reference > for module 'lmnsd_ptcp', reference count now 1 > 9572.672770522:7f07bbbfd910: creating tcp listen socket on port 514 > 9572.672803781:7f07bbbfd910: error 13 while binding tcp socketWe could > initialize 0 TCP listen sockets out of 1 we recei > ved - this may or may not be an error indication. > 9572.672824933:7f07bbbfd910: No TCP listen sockets could successfully > be > initializedCalled LogError, msg: Could not crea > te tcp listener, ignoring port 514. > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from 'trebuchet', msg > Could not create tcp listener, ignoring port 514. [t > ry http://www.rsyslog.com/e/2077 ] > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Apr 26 08:59:50 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Apr 2010 08:59:50 +0200 Subject: [rsyslog] Syslog over SCTP? References: <5A6D953473350C4B9995546AFE9939EE08FE7309@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE08FE7318@RWC-EX1.corp.seven.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CDF@GRFEXC.intern.adiscon.com> This is interesting, but unfortunately I lack time to look deeper into it. I just wonder if another - maybe more flexible - approach would be to add a priority queue queueing mode. In that, we would enqueue messages based on priority and process higher priority messages before lower priority ones. That would work with all transports (and all other outout plugins) and solved the need you have. Am I right here? Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Sunday, April 25, 2010 4:30 AM > To: rsyslog-users > Subject: Re: [rsyslog] Syslog over SCTP? > > What I had in mind was something like an SCTP stream for each log level > or each facility, haven't decided which would be most useful. That > prevents head-of-line blocking as happens in TCP. So, for example, if > a > buffer is full of DEBUG level messages, an ALERT level message would go > immediately as it is in a different stream. A separate stream could be > added for RELP messages (or something like RELP or maybe an extension > of > it) and all of these streams would be within a single SCTP connection. > Or maybe you can send RELP-like messages back across each stream in the > opposite direction but having an "out of band" control channel sounds > like an interesting idea and something fairly easy to do with SCTP. > > I would also think this lends itself well to threading of the different > streams with a different thread handling different log levels (or > facilities but I think dividing among log levels is probably easier). > On an SMP system, a remote host sending a lot of DEGUG level messages > while it is being tested would bog down one thread but other messages > would be processed separately without network head-of-line blocking or > CPU blocking (disk contention would be a different story, though ;) > > > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > Sent: Saturday, April 24, 2010 11:20 AM > > To: rsyslog-users > > Subject: [rsyslog] Syslog over SCTP? > > > > Has anyone experimented with using SCTP for logging to a remote host? > > It seems it might have some advantages over TCP and UDP for that > > purpose. > > > > http://www.ibm.com/developerworks/linux/library/l-sctp/ > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Mon Apr 26 09:44:20 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 26 Apr 2010 00:44:20 -0700 Subject: [rsyslog] Syslog over SCTP? References: <5A6D953473350C4B9995546AFE9939EE08FE7309@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE08FE7318@RWC-EX1.corp.seven.com> <9B6E2A8877C38245BFB15CC491A11DA7103CDF@GRFEXC.intern.adiscon.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE732B@RWC-EX1.corp.seven.com> Well, it isn't really prioritization that I am worried about. For example, if I have a developer running something in DEBUG, that is actually quite high priority for him. With TCP, there is no way to separate them at the system OS tcp buffer level without opening several concurrent TCP connections, basically one connection for each ActionQueue. TCP has only one output buffer per connection while SCTP can have several parallel streams operating over a single socket connection. Maybe I will hack on it when I get time. If I have sent a bunch of DEBUG level messages, they are in the TCP/IP output buffer. If I want to send a USER level message, it gets put in the queue after the DEBUG messages I have already "sent". With SCTP, the streams are handled in round-robin fashion. If the packet is flagged for "out of order delivery", one could potentially send a higher priority packet NOW despite a lot of lower priority messages being sent. The problem with prioritization is that higher priority traffic can starve "lower" priority traffic of service. You can already easily accomplish the prioritization with the exsting Linux ToS bits. By default Linux has four classes of traffic with the pfifo_fast qdisc. If you mark the packets accordingly, you can already get higher priority service for certain traffic (marking ToS 0 for EMERGENCY, for example). The problem with that is a program spewing a bunch of USER messages can block DEBUG messages if USER is placed at a higher priority. What I had in mind was basically a separate worker thread for each log level. This prevents any of them blocking the others. George > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Monday, April 26, 2010 12:00 AM > To: rsyslog-users > Subject: Re: [rsyslog] Syslog over SCTP? > > This is interesting, but unfortunately I lack time to look deeper into > it. > > I just wonder if another - maybe more flexible - approach would be to > add a > priority queue queueing mode. In that, we would enqueue messages based > on > priority and process higher priority messages before lower priority > ones. > That would work with all transports (and all other outout plugins) and > solved > the need you have. > > Am I right here? > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > Sent: Sunday, April 25, 2010 4:30 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Syslog over SCTP? > > > > What I had in mind was something like an SCTP stream for each log > level > > or each facility, haven't decided which would be most useful. That > > prevents head-of-line blocking as happens in TCP. So, for example, > if > > a > > buffer is full of DEBUG level messages, an ALERT level message would > go > > immediately as it is in a different stream. A separate stream could > be > > added for RELP messages (or something like RELP or maybe an extension > > of > > it) and all of these streams would be within a single SCTP > connection. > > Or maybe you can send RELP-like messages back across each stream in > the > > opposite direction but having an "out of band" control channel sounds > > like an interesting idea and something fairly easy to do with SCTP. > > > > I would also think this lends itself well to threading of the > different > > streams with a different thread handling different log levels (or > > facilities but I think dividing among log levels is probably easier). > > On an SMP system, a remote host sending a lot of DEGUG level messages > > while it is being tested would bog down one thread but other messages > > would be processed separately without network head-of-line blocking > or > > CPU blocking (disk contention would be a different story, though ;) > > > > > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > Sent: Saturday, April 24, 2010 11:20 AM > > > To: rsyslog-users > > > Subject: [rsyslog] Syslog over SCTP? > > > > > > Has anyone experimented with using SCTP for logging to a remote > host? > > > It seems it might have some advantages over TCP and UDP for that > > > purpose. > > > > > > http://www.ibm.com/developerworks/linux/library/l-sctp/ > > > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Mon Apr 26 10:09:45 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 26 Apr 2010 01:09:45 -0700 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com> <9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com> Oops, sorry, I did not mean to send that attachment to the list. > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Sunday, April 25, 2010 11:18 PM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > The privilege drop code is still a hack. It needs proper engineering > (as > stated in the doc). So it could very well be a race in this regard. On > the > other hand, it does not look so. Could you send me complete debug logs > to my > private email address both with and without privilege drop inside your > config. Maybe it is a simple thing, then I could fix it without the > large > effort really required. > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > Sent: Monday, April 26, 2010 2:24 AM > > To: rsyslog-users > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > > > Can't bind to TCP socket. The tcp module loads but I noticed that it > > only tries to bind the socket AFTER it has dropped is privs so it can > > not bind to a socket less than 1024. UDP bind works as that seems to > > bind immediately after module load while the prog is still running as > > root. If I set a tcp port >1024, it works. Could this be a race > > between > > two threads where a different thread is setting the UID/GID and a > > different one is binding the connections and the UID gets changed > > before > > the binding thread has a chance to get the socket? > > > > Modules being loaded: > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' > > 9572.648645873:7f07c0a216f0: loading module > '/usr/lib/rsyslog/imudp.so' > > 9572.648713628:7f07c0a216f0: source file imudp.c requested reference > > for > > module 'lmnet', reference count now 4 > > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports at > *:514. > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' > > 9572.648869611:7f07c0a216f0: loading module > '/usr/lib/rsyslog/imtcp.so' > > 9572.648938665:7f07c0a216f0: source file imtcp.c requested reference > > for > > module 'lmnet', reference count now 5 > > 9572.648953892:7f07c0a216f0: caller requested object 'netstrm', not > > found (iRet -3003) > > 9572.648968610:7f07c0a216f0: Requested to load module 'lmnetstrms' > > 9572.648979310:7f07c0a216f0: loading module > > '/usr/lib/rsyslog/lmnetstrms.so' > > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > > 9572.649068131:7f07c0a216f0: source file imtcp.c requested reference > > for > > module 'lmnetstrms', reference count now 1 > > 9572.649079163:7f07c0a216f0: caller requested object 'tcps_sess', not > > found (iRet -3003) > > 9572.649095086:7f07c0a216f0: Requested to load module 'lmtcpsrv' > > 9572.649105485:7f07c0a216f0: loading module > > '/usr/lib/rsyslog/lmtcpsrv.so' > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c requested > > reference > > for module 'lmnetstrms', reference count now 2 > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested reference > > for module 'lmnet', reference count now 6 > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested reference > > for module 'lmnetstrms', reference count now 3 > > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > > 9572.649241801:7f07c0a216f0: source file imtcp.c requested reference > > for > > module 'lmtcpsrv', reference count now 1 > > 9572.649252009:7f07c0a216f0: source file imtcp.c requested reference > > for > > module 'lmtcpsrv', reference count now 2 > > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' > > 9572.649321373:7f07c0a216f0: cfline: '$ActionFileDefaultTemplate > > RSYSLOG_TraditionalFileFormat' > > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction on' > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user 'syslog' > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user 'syslog' > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup syslog' > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group 'syslog' > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > /etc/rsyslog.d/*.conf' > > 9572.650017305:7f07c0a216f0: requested to include config file > > '/etc/rsyslog.d/50-default.conf' > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > /var/log/auth.log' > > > > GID and UID being changed: > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, lenBuf > 78 > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg > > rsyslogd's groupid changed to 103 > > 9572.671920644:7f07c0a216f0: Message has legacy syslog format. > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > 9572.671957623:7f07be402910: Called action, logging to builtin-pipe > > 9572.671969801:7f07be402910: extend buf to at least 16, done 128 > > 9572.671982061:7f07be402910: (/dev/xconsole) > > 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 entries > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised worker start > > 9572.672059720:7f07be402910: Action requested to be suspended, done > > that. > > 9572.672085037:7f07be402910: main Q: entry deleted, state 0, size now > 1 > > entries > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > 9572.672147659:7f07be402910: Called action, logging to builtin-file > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg > > rsyslogd's userid changed to 101 > > 9572.672179992:7f07c0a216f0: Message has legacy syslog format. > > 9572.672192329:7f07be402910: extend buf to at least 138, done 256 > > 9572.672200766:7f07be402910: file to log to: /var/log/syslog > > > > UDP socket bind succeeded but TCP bind fails: > > > > 9572.672546363:7f07c0a216f0: initialization completed, transitioning > to > > regular run mode > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket 4 > > (IPv4/port 514). > > 9572.672576606:7f07bc3fe910: --------imUDP calling select, active > file > > descriptors (max 4): 4 > > 9572.672594858:7f07bdc01910: --------imuxsock calling select, active > > file descriptors (max 5): 3 5 > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy > > 9572.672646478:7f07bbbfd910: caller requested object 'nsd_ptcp', not > > found (iRet -3003) > > 9572.672663716:7f07bbbfd910: Requested to load module 'lmnsd_ptcp' > > 9572.672671184:7f07bbbfd910: loading module > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested > reference > > for module 'lmnetstrms', reference count now 4 > > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > > 9572.672763826:7f07bbbfd910: source file netstrms.c requested > reference > > for module 'lmnsd_ptcp', reference count now 1 > > 9572.672770522:7f07bbbfd910: creating tcp listen socket on port 514 > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp socketWe > could > > initialize 0 TCP listen sockets out of 1 we recei > > ved - this may or may not be an error indication. > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could successfully > > be > > initializedCalled LogError, msg: Could not crea > > te tcp listener, ignoring port 514. > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from 'trebuchet', msg > > Could not create tcp listener, ignoring port 514. [t > > ry http://www.rsyslog.com/e/2077 ] > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Apr 26 10:37:13 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Apr 2010 10:37:13 +0200 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com> <5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com> No problem -- the mailing list processor held it due to size constrainst (and I rejected it now). The size restriction was actually the prime issue why I requested it to go to my private mail. So: nothing bad has happened ;) I'll try to look at the log asap and let you know what I find. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Monday, April 26, 2010 10:10 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > Oops, sorry, I did not mean to send that attachment to the list. > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > Sent: Sunday, April 25, 2010 11:18 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > non-root. > > > > The privilege drop code is still a hack. It needs proper engineering > > (as > > stated in the doc). So it could very well be a race in this regard. > On > > the > > other hand, it does not look so. Could you send me complete debug > logs > > to my > > private email address both with and without privilege drop inside > your > > config. Maybe it is a simple thing, then I could fix it without the > > large > > effort really required. > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > Sent: Monday, April 26, 2010 2:24 AM > > > To: rsyslog-users > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > > > > > Can't bind to TCP socket. The tcp module loads but I noticed that > it > > > only tries to bind the socket AFTER it has dropped is privs so it > can > > > not bind to a socket less than 1024. UDP bind works as that seems > to > > > bind immediately after module load while the prog is still running > as > > > root. If I set a tcp port >1024, it works. Could this be a race > > > between > > > two threads where a different thread is setting the UID/GID and a > > > different one is binding the connections and the UID gets changed > > > before > > > the binding thread has a chance to get the socket? > > > > > > Modules being loaded: > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' > > > 9572.648645873:7f07c0a216f0: loading module > > '/usr/lib/rsyslog/imudp.so' > > > 9572.648713628:7f07c0a216f0: source file imudp.c requested > reference > > > for > > > module 'lmnet', reference count now 4 > > > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports at > > *:514. > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' > > > 9572.648869611:7f07c0a216f0: loading module > > '/usr/lib/rsyslog/imtcp.so' > > > 9572.648938665:7f07c0a216f0: source file imtcp.c requested > reference > > > for > > > module 'lmnet', reference count now 5 > > > 9572.648953892:7f07c0a216f0: caller requested object 'netstrm', not > > > found (iRet -3003) > > > 9572.648968610:7f07c0a216f0: Requested to load module 'lmnetstrms' > > > 9572.648979310:7f07c0a216f0: loading module > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > > > 9572.649068131:7f07c0a216f0: source file imtcp.c requested > reference > > > for > > > module 'lmnetstrms', reference count now 1 > > > 9572.649079163:7f07c0a216f0: caller requested object 'tcps_sess', > not > > > found (iRet -3003) > > > 9572.649095086:7f07c0a216f0: Requested to load module 'lmtcpsrv' > > > 9572.649105485:7f07c0a216f0: loading module > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c requested > > > reference > > > for module 'lmnetstrms', reference count now 2 > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested > reference > > > for module 'lmnet', reference count now 6 > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested > reference > > > for module 'lmnetstrms', reference count now 3 > > > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > > > 9572.649241801:7f07c0a216f0: source file imtcp.c requested > reference > > > for > > > module 'lmtcpsrv', reference count now 1 > > > 9572.649252009:7f07c0a216f0: source file imtcp.c requested > reference > > > for > > > module 'lmtcpsrv', reference count now 2 > > > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' > > > 9572.649321373:7f07c0a216f0: cfline: '$ActionFileDefaultTemplate > > > RSYSLOG_TraditionalFileFormat' > > > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction on' > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user 'syslog' > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user 'syslog' > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup syslog' > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group 'syslog' > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > /etc/rsyslog.d/*.conf' > > > 9572.650017305:7f07c0a216f0: requested to include config file > > > '/etc/rsyslog.d/50-default.conf' > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > /var/log/auth.log' > > > > > > GID and UID being changed: > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, > lenBuf > > 78 > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg > > > rsyslogd's groupid changed to 103 > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog format. > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > > 9572.671957623:7f07be402910: Called action, logging to builtin-pipe > > > 9572.671969801:7f07be402910: extend buf to at least 16, done 128 > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 > entries > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised worker > start > > > 9572.672059720:7f07be402910: Action requested to be suspended, done > > > that. > > > 9572.672085037:7f07be402910: main Q: entry deleted, state 0, size > now > > 1 > > > entries > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > > 9572.672147659:7f07be402910: Called action, logging to builtin-file > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', msg > > > rsyslogd's userid changed to 101 > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog format. > > > 9572.672192329:7f07be402910: extend buf to at least 138, done 256 > > > 9572.672200766:7f07be402910: file to log to: /var/log/syslog > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > transitioning > > to > > > regular run mode > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket 4 > > > (IPv4/port 514). > > > 9572.672576606:7f07bc3fe910: --------imUDP calling select, active > > file > > > descriptors (max 4): 4 > > > 9572.672594858:7f07bdc01910: --------imuxsock calling select, > active > > > file descriptors (max 5): 3 5 > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy > > > 9572.672646478:7f07bbbfd910: caller requested object 'nsd_ptcp', > not > > > found (iRet -3003) > > > 9572.672663716:7f07bbbfd910: Requested to load module 'lmnsd_ptcp' > > > 9572.672671184:7f07bbbfd910: loading module > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested > > reference > > > for module 'lmnetstrms', reference count now 4 > > > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > > > 9572.672763826:7f07bbbfd910: source file netstrms.c requested > > reference > > > for module 'lmnsd_ptcp', reference count now 1 > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket on port 514 > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp socketWe > > could > > > initialize 0 TCP listen sockets out of 1 we recei > > > ved - this may or may not be an error indication. > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could > successfully > > > be > > > initializedCalled LogError, msg: Could not crea > > > te tcp listener, ignoring port 514. > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from 'trebuchet', msg > > > Could not create tcp listener, ignoring port 514. [t > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Mon Apr 26 10:51:57 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 26 Apr 2010 01:51:57 -0700 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com> <9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE7330@RWC-EX1.corp.seven.com> I think the problem is that it spawns a new thread to load the udp and tcp modules and that should be done by the main thread so that it gets done in sequence before the privs are processed. > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Monday, April 26, 2010 1:37 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > No problem -- the mailing list processor held it due to size > constrainst (and > I rejected it now). The size restriction was actually the prime issue > why I > requested it to go to my private mail. So: nothing bad has happened ;) > > I'll try to look at the log asap and let you know what I find. > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > Sent: Monday, April 26, 2010 10:10 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > root. > > > > Oops, sorry, I did not mean to send that attachment to the list. > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > Sent: Sunday, April 25, 2010 11:18 PM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > non-root. > > > > > > The privilege drop code is still a hack. It needs proper > engineering > > > (as > > > stated in the doc). So it could very well be a race in this regard. > > On > > > the > > > other hand, it does not look so. Could you send me complete debug > > logs > > > to my > > > private email address both with and without privilege drop inside > > your > > > config. Maybe it is a simple thing, then I could fix it without the > > > large > > > effort really required. > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > Sent: Monday, April 26, 2010 2:24 AM > > > > To: rsyslog-users > > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > root. > > > > > > > > Can't bind to TCP socket. The tcp module loads but I noticed > that > > it > > > > only tries to bind the socket AFTER it has dropped is privs so it > > can > > > > not bind to a socket less than 1024. UDP bind works as that > seems > > to > > > > bind immediately after module load while the prog is still > running > > as > > > > root. If I set a tcp port >1024, it works. Could this be a race > > > > between > > > > two threads where a different thread is setting the UID/GID and a > > > > different one is binding the connections and the UID gets changed > > > > before > > > > the binding thread has a chance to get the socket? > > > > > > > > Modules being loaded: > > > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > > 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' > > > > 9572.648645873:7f07c0a216f0: loading module > > > '/usr/lib/rsyslog/imudp.so' > > > > 9572.648713628:7f07c0a216f0: source file imudp.c requested > > reference > > > > for > > > > module 'lmnet', reference count now 4 > > > > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports at > > > *:514. > > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > > 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' > > > > 9572.648869611:7f07c0a216f0: loading module > > > '/usr/lib/rsyslog/imtcp.so' > > > > 9572.648938665:7f07c0a216f0: source file imtcp.c requested > > reference > > > > for > > > > module 'lmnet', reference count now 5 > > > > 9572.648953892:7f07c0a216f0: caller requested object 'netstrm', > not > > > > found (iRet -3003) > > > > 9572.648968610:7f07c0a216f0: Requested to load module > 'lmnetstrms' > > > > 9572.648979310:7f07c0a216f0: loading module > > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > > > > 9572.649068131:7f07c0a216f0: source file imtcp.c requested > > reference > > > > for > > > > module 'lmnetstrms', reference count now 1 > > > > 9572.649079163:7f07c0a216f0: caller requested object 'tcps_sess', > > not > > > > found (iRet -3003) > > > > 9572.649095086:7f07c0a216f0: Requested to load module 'lmtcpsrv' > > > > 9572.649105485:7f07c0a216f0: loading module > > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c requested > > > > reference > > > > for module 'lmnetstrms', reference count now 2 > > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested > > reference > > > > for module 'lmnet', reference count now 6 > > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested > > reference > > > > for module 'lmnetstrms', reference count now 3 > > > > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > > > > 9572.649241801:7f07c0a216f0: source file imtcp.c requested > > reference > > > > for > > > > module 'lmtcpsrv', reference count now 1 > > > > 9572.649252009:7f07c0a216f0: source file imtcp.c requested > > reference > > > > for > > > > module 'lmtcpsrv', reference count now 2 > > > > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > > > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' > > > > 9572.649321373:7f07c0a216f0: cfline: '$ActionFileDefaultTemplate > > > > RSYSLOG_TraditionalFileFormat' > > > > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction on' > > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user 'syslog' > > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' > > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user 'syslog' > > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup syslog' > > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group 'syslog' > > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > > /etc/rsyslog.d/*.conf' > > > > 9572.650017305:7f07c0a216f0: requested to include config file > > > > '/etc/rsyslog.d/50-default.conf' > > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > > /var/log/auth.log' > > > > > > > > GID and UID being changed: > > > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, > > lenBuf > > > 78 > > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', > msg > > > > rsyslogd's groupid changed to 103 > > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog format. > > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > > > 9572.671957623:7f07be402910: Called action, logging to builtin- > pipe > > > > 9572.671969801:7f07be402910: extend buf to at least 16, done 128 > > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 > > entries > > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy > > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised worker > > start > > > > 9572.672059720:7f07be402910: Action requested to be suspended, > done > > > > that. > > > > 9572.672085037:7f07be402910: main Q: entry deleted, state 0, size > > now > > > 1 > > > > entries > > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > > > 9572.672147659:7f07be402910: Called action, logging to builtin- > file > > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', > msg > > > > rsyslogd's userid changed to 101 > > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog format. > > > > 9572.672192329:7f07be402910: extend buf to at least 138, done 256 > > > > 9572.672200766:7f07be402910: file to log to: /var/log/syslog > > > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > > transitioning > > > to > > > > regular run mode > > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket 4 > > > > (IPv4/port 514). > > > > 9572.672576606:7f07bc3fe910: --------imUDP calling select, active > > > file > > > > descriptors (max 4): 4 > > > > 9572.672594858:7f07bdc01910: --------imuxsock calling select, > > active > > > > file descriptors (max 5): 3 5 > > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy > > > > 9572.672646478:7f07bbbfd910: caller requested object 'nsd_ptcp', > > not > > > > found (iRet -3003) > > > > 9572.672663716:7f07bbbfd910: Requested to load module > 'lmnsd_ptcp' > > > > 9572.672671184:7f07bbbfd910: loading module > > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested > > > reference > > > > for module 'lmnetstrms', reference count now 4 > > > > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > > > > 9572.672763826:7f07bbbfd910: source file netstrms.c requested > > > reference > > > > for module 'lmnsd_ptcp', reference count now 1 > > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket on port > 514 > > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp socketWe > > > could > > > > initialize 0 TCP listen sockets out of 1 we recei > > > > ved - this may or may not be an error indication. > > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could > > successfully > > > > be > > > > initializedCalled LogError, msg: Could not crea > > > > te tcp listener, ignoring port 514. > > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from 'trebuchet', > msg > > > > Could not create tcp listener, ignoring port 514. [t > > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Apr 26 11:32:03 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Apr 2010 11:32:03 +0200 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com> <5A6D953473350C4B9995546AFE9939EE08FE7330@RWC-EX1.corp.seven.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CE3@GRFEXC.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Monday, April 26, 2010 10:52 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > I think the problem is that it spawns a new thread to load the udp and > tcp modules and that should be done by the main thread so that it gets > done in sequence before the privs are processed. I think your analysis is right, this is where the race happens. However, the cure is far from being as simple as it sounds: you are actually recommending a full redesign of the input plugin interface. It would also have other implications, including a potential unacceptable startup delay. This is what I quoted with "a lot of work to do". So, unfortunately, it does not look like something I can fix quickly. Let me once again reiterate that the priv drop code is far from being a complete solution. I added the current code when I saw that it was easy to do and useful for some situations. We once had someone who was interested in sponsoring a complete implementation, but that did unfortunately not materialize. As I am currently short on time due to other work to do, I do not find sufficient time to look at this. It is far from being a trivial task, even though I hope to be able to do it without a full redesign. I still think it is 2+ weeks worth of work. Rainer > > > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > Sent: Monday, April 26, 2010 1:37 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > non-root. > > > > No problem -- the mailing list processor held it due to size > > constrainst (and > > I rejected it now). The size restriction was actually the prime issue > > why I > > requested it to go to my private mail. So: nothing bad has happened > ;) > > > > I'll try to look at the log asap and let you know what I find. > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > Sent: Monday, April 26, 2010 10:10 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > > root. > > > > > > Oops, sorry, I did not mean to send that attachment to the list. > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > Sent: Sunday, April 25, 2010 11:18 PM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > non-root. > > > > > > > > The privilege drop code is still a hack. It needs proper > > engineering > > > > (as > > > > stated in the doc). So it could very well be a race in this > regard. > > > On > > > > the > > > > other hand, it does not look so. Could you send me complete debug > > > logs > > > > to my > > > > private email address both with and without privilege drop inside > > > your > > > > config. Maybe it is a simple thing, then I could fix it without > the > > > > large > > > > effort really required. > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > Sent: Monday, April 26, 2010 2:24 AM > > > > > To: rsyslog-users > > > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > > root. > > > > > > > > > > Can't bind to TCP socket. The tcp module loads but I noticed > > that > > > it > > > > > only tries to bind the socket AFTER it has dropped is privs so > it > > > can > > > > > not bind to a socket less than 1024. UDP bind works as that > > seems > > > to > > > > > bind immediately after module load while the prog is still > > running > > > as > > > > > root. If I set a tcp port >1024, it works. Could this be a > race > > > > > between > > > > > two threads where a different thread is setting the UID/GID and > a > > > > > different one is binding the connections and the UID gets > changed > > > > > before > > > > > the binding thread has a chance to get the socket? > > > > > > > > > > Modules being loaded: > > > > > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > > > 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' > > > > > 9572.648645873:7f07c0a216f0: loading module > > > > '/usr/lib/rsyslog/imudp.so' > > > > > 9572.648713628:7f07c0a216f0: source file imudp.c requested > > > reference > > > > > for > > > > > module 'lmnet', reference count now 4 > > > > > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > > > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports at > > > > *:514. > > > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > > > 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' > > > > > 9572.648869611:7f07c0a216f0: loading module > > > > '/usr/lib/rsyslog/imtcp.so' > > > > > 9572.648938665:7f07c0a216f0: source file imtcp.c requested > > > reference > > > > > for > > > > > module 'lmnet', reference count now 5 > > > > > 9572.648953892:7f07c0a216f0: caller requested object 'netstrm', > > not > > > > > found (iRet -3003) > > > > > 9572.648968610:7f07c0a216f0: Requested to load module > > 'lmnetstrms' > > > > > 9572.648979310:7f07c0a216f0: loading module > > > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > > > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > > > > > 9572.649068131:7f07c0a216f0: source file imtcp.c requested > > > reference > > > > > for > > > > > module 'lmnetstrms', reference count now 1 > > > > > 9572.649079163:7f07c0a216f0: caller requested object > 'tcps_sess', > > > not > > > > > found (iRet -3003) > > > > > 9572.649095086:7f07c0a216f0: Requested to load module > 'lmtcpsrv' > > > > > 9572.649105485:7f07c0a216f0: loading module > > > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c requested > > > > > reference > > > > > for module 'lmnetstrms', reference count now 2 > > > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested > > > reference > > > > > for module 'lmnet', reference count now 6 > > > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested > > > reference > > > > > for module 'lmnetstrms', reference count now 3 > > > > > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > > > > > 9572.649241801:7f07c0a216f0: source file imtcp.c requested > > > reference > > > > > for > > > > > module 'lmtcpsrv', reference count now 1 > > > > > 9572.649252009:7f07c0a216f0: source file imtcp.c requested > > > reference > > > > > for > > > > > module 'lmtcpsrv', reference count now 2 > > > > > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > > > > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' > > > > > 9572.649321373:7f07c0a216f0: cfline: > '$ActionFileDefaultTemplate > > > > > RSYSLOG_TraditionalFileFormat' > > > > > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction on' > > > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user 'syslog' > > > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > > > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > > > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > > > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' > > > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user 'syslog' > > > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup syslog' > > > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group > 'syslog' > > > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > > > /etc/rsyslog.d/*.conf' > > > > > 9572.650017305:7f07c0a216f0: requested to include config file > > > > > '/etc/rsyslog.d/50-default.conf' > > > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > > > /var/log/auth.log' > > > > > > > > > > GID and UID being changed: > > > > > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, > > > lenBuf > > > > 78 > > > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', > > msg > > > > > rsyslogd's groupid changed to 103 > > > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog format. > > > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > > > > 9572.671957623:7f07be402910: Called action, logging to builtin- > > pipe > > > > > 9572.671969801:7f07be402910: extend buf to at least 16, done > 128 > > > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 > > > entries > > > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy > > > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised worker > > > start > > > > > 9572.672059720:7f07be402910: Action requested to be suspended, > > done > > > > > that. > > > > > 9572.672085037:7f07be402910: main Q: entry deleted, state 0, > size > > > now > > > > 1 > > > > > entries > > > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > > > > 9572.672147659:7f07be402910: Called action, logging to builtin- > > file > > > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from 'trebuchet', > > msg > > > > > rsyslogd's userid changed to 101 > > > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog format. > > > > > 9572.672192329:7f07be402910: extend buf to at least 138, done > 256 > > > > > 9572.672200766:7f07be402910: file to log to: /var/log/syslog > > > > > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > > > transitioning > > > > to > > > > > regular run mode > > > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket 4 > > > > > (IPv4/port 514). > > > > > 9572.672576606:7f07bc3fe910: --------imUDP calling select, > active > > > > file > > > > > descriptors (max 4): 4 > > > > > 9572.672594858:7f07bdc01910: --------imuxsock calling select, > > > active > > > > > file descriptors (max 5): 3 5 > > > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy > > > > > 9572.672646478:7f07bbbfd910: caller requested object > 'nsd_ptcp', > > > not > > > > > found (iRet -3003) > > > > > 9572.672663716:7f07bbbfd910: Requested to load module > > 'lmnsd_ptcp' > > > > > 9572.672671184:7f07bbbfd910: loading module > > > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested > > > > reference > > > > > for module 'lmnetstrms', reference count now 4 > > > > > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > > > > > 9572.672763826:7f07bbbfd910: source file netstrms.c requested > > > > reference > > > > > for module 'lmnsd_ptcp', reference count now 1 > > > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket on port > > 514 > > > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp > socketWe > > > > could > > > > > initialize 0 TCP listen sockets out of 1 we recei > > > > > ved - this may or may not be an error indication. > > > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could > > > successfully > > > > > be > > > > > initializedCalled LogError, msg: Could not crea > > > > > te tcp listener, ignoring port 514. > > > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from 'trebuchet', > > msg > > > > > Could not create tcp listener, ignoring port 514. [t > > > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Mon Apr 26 11:44:12 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 26 Apr 2010 02:44:12 -0700 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE7330@RWC-EX1.corp.seven.com> <9B6E2A8877C38245BFB15CC491A11DA7103CE3@GRFEXC.intern.adiscon.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE7331@RWC-EX1.corp.seven.com> Maybe a quick fix would be a "sleep" directive you could place on the main thread to cause it to delay a bit? That would not be expected to be a permanent "fix" but simply a work-around. If I could place something like "sleep 5" that would cause the main thread to wait a little while, that could work around the race. > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Monday, April 26, 2010 2:32 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > Sent: Monday, April 26, 2010 10:52 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > root. > > > > I think the problem is that it spawns a new thread to load the udp > and > > tcp modules and that should be done by the main thread so that it > gets > > done in sequence before the privs are processed. > > I think your analysis is right, this is where the race happens. > However, the > cure is far from being as simple as it sounds: you are actually > recommending > a full redesign of the input plugin interface. It would also have other > implications, including a potential unacceptable startup delay. > > This is what I quoted with "a lot of work to do". So, unfortunately, it > does > not look like something I can fix quickly. Let me once again reiterate > that > the priv drop code is far from being a complete solution. I added the > current > code when I saw that it was easy to do and useful for some situations. > We > once had someone who was interested in sponsoring a complete > implementation, > but that did unfortunately not materialize. As I am currently short on > time > due to other work to do, I do not find sufficient time to look at this. > It is > far from being a trivial task, even though I hope to be able to do it > without > a full redesign. I still think it is 2+ weeks worth of work. > > Rainer > > > > > > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > Sent: Monday, April 26, 2010 1:37 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > non-root. > > > > > > No problem -- the mailing list processor held it due to size > > > constrainst (and > > > I rejected it now). The size restriction was actually the prime > issue > > > why I > > > requested it to go to my private mail. So: nothing bad has happened > > ;) > > > > > > I'll try to look at the log asap and let you know what I find. > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > Sent: Monday, April 26, 2010 10:10 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > non- > > > root. > > > > > > > > Oops, sorry, I did not mean to send that attachment to the list. > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > Sent: Sunday, April 25, 2010 11:18 PM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > > non-root. > > > > > > > > > > The privilege drop code is still a hack. It needs proper > > > engineering > > > > > (as > > > > > stated in the doc). So it could very well be a race in this > > regard. > > > > On > > > > > the > > > > > other hand, it does not look so. Could you send me complete > debug > > > > logs > > > > > to my > > > > > private email address both with and without privilege drop > inside > > > > your > > > > > config. Maybe it is a simple thing, then I could fix it without > > the > > > > > large > > > > > effort really required. > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > > Sent: Monday, April 26, 2010 2:24 AM > > > > > > To: rsyslog-users > > > > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID > non- > > > root. > > > > > > > > > > > > Can't bind to TCP socket. The tcp module loads but I noticed > > > that > > > > it > > > > > > only tries to bind the socket AFTER it has dropped is privs > so > > it > > > > can > > > > > > not bind to a socket less than 1024. UDP bind works as that > > > seems > > > > to > > > > > > bind immediately after module load while the prog is still > > > running > > > > as > > > > > > root. If I set a tcp port >1024, it works. Could this be a > > race > > > > > > between > > > > > > two threads where a different thread is setting the UID/GID > and > > a > > > > > > different one is binding the connections and the UID gets > > changed > > > > > > before > > > > > > the binding thread has a chance to get the socket? > > > > > > > > > > > > Modules being loaded: > > > > > > > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > > > > 9572.648636228:7f07c0a216f0: Requested to load module 'imudp' > > > > > > 9572.648645873:7f07c0a216f0: loading module > > > > > '/usr/lib/rsyslog/imudp.so' > > > > > > 9572.648713628:7f07c0a216f0: source file imudp.c requested > > > > reference > > > > > > for > > > > > > module 'lmnet', reference count now 4 > > > > > > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > > > > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > > > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP ports > at > > > > > *:514. > > > > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > > > > 9572.648859626:7f07c0a216f0: Requested to load module 'imtcp' > > > > > > 9572.648869611:7f07c0a216f0: loading module > > > > > '/usr/lib/rsyslog/imtcp.so' > > > > > > 9572.648938665:7f07c0a216f0: source file imtcp.c requested > > > > reference > > > > > > for > > > > > > module 'lmnet', reference count now 5 > > > > > > 9572.648953892:7f07c0a216f0: caller requested object > 'netstrm', > > > not > > > > > > found (iRet -3003) > > > > > > 9572.648968610:7f07c0a216f0: Requested to load module > > > 'lmnetstrms' > > > > > > 9572.648979310:7f07c0a216f0: loading module > > > > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > > > > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > > > > > > 9572.649068131:7f07c0a216f0: source file imtcp.c requested > > > > reference > > > > > > for > > > > > > module 'lmnetstrms', reference count now 1 > > > > > > 9572.649079163:7f07c0a216f0: caller requested object > > 'tcps_sess', > > > > not > > > > > > found (iRet -3003) > > > > > > 9572.649095086:7f07c0a216f0: Requested to load module > > 'lmtcpsrv' > > > > > > 9572.649105485:7f07c0a216f0: loading module > > > > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c > requested > > > > > > reference > > > > > > for module 'lmnetstrms', reference count now 2 > > > > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested > > > > reference > > > > > > for module 'lmnet', reference count now 6 > > > > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested > > > > reference > > > > > > for module 'lmnetstrms', reference count now 3 > > > > > > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > > > > > > 9572.649241801:7f07c0a216f0: source file imtcp.c requested > > > > reference > > > > > > for > > > > > > module 'lmtcpsrv', reference count now 1 > > > > > > 9572.649252009:7f07c0a216f0: source file imtcp.c requested > > > > reference > > > > > > for > > > > > > module 'lmtcpsrv', reference count now 2 > > > > > > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > > > > > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun 514' > > > > > > 9572.649321373:7f07c0a216f0: cfline: > > '$ActionFileDefaultTemplate > > > > > > RSYSLOG_TraditionalFileFormat' > > > > > > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction > on' > > > > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > > > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user > 'syslog' > > > > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > > > > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > > > > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > > > > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser syslog' > > > > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user > 'syslog' > > > > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup > syslog' > > > > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group > > 'syslog' > > > > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > > > > /etc/rsyslog.d/*.conf' > > > > > > 9572.650017305:7f07c0a216f0: requested to include config file > > > > > > '/etc/rsyslog.d/50-default.conf' > > > > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > > > > /var/log/auth.log' > > > > > > > > > > > > GID and UID being changed: > > > > > > > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm 0x1e11d60, > > > > lenBuf > > > > > 78 > > > > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from > 'trebuchet', > > > msg > > > > > > rsyslogd's groupid changed to 103 > > > > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog > format. > > > > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > > > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > > > > > 9572.671957623:7f07be402910: Called action, logging to > builtin- > > > pipe > > > > > > 9572.671969801:7f07be402910: extend buf to at least 16, done > > 128 > > > > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size now 2 > > > > entries > > > > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals busy > > > > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised > worker > > > > start > > > > > > 9572.672059720:7f07be402910: Action requested to be > suspended, > > > done > > > > > > that. > > > > > > 9572.672085037:7f07be402910: main Q: entry deleted, state 0, > > size > > > > now > > > > > 1 > > > > > > entries > > > > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > > > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > > > > > 9572.672147659:7f07be402910: Called action, logging to > builtin- > > > file > > > > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from > 'trebuchet', > > > msg > > > > > > rsyslogd's userid changed to 101 > > > > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog > format. > > > > > > 9572.672192329:7f07be402910: extend buf to at least 138, done > > 256 > > > > > > 9572.672200766:7f07be402910: file to log to: /var/log/syslog > > > > > > > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > > > > transitioning > > > > > to > > > > > > regular run mode > > > > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd socket > 4 > > > > > > (IPv4/port 514). > > > > > > 9572.672576606:7f07bc3fe910: --------imUDP calling select, > > active > > > > > file > > > > > > descriptors (max 4): 4 > > > > > > 9572.672594858:7f07bdc01910: --------imuxsock calling select, > > > > active > > > > > > file descriptors (max 5): 3 5 > > > > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals busy > > > > > > 9572.672646478:7f07bbbfd910: caller requested object > > 'nsd_ptcp', > > > > not > > > > > > found (iRet -3003) > > > > > > 9572.672663716:7f07bbbfd910: Requested to load module > > > 'lmnsd_ptcp' > > > > > > 9572.672671184:7f07bbbfd910: loading module > > > > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c requested > > > > > reference > > > > > > for module 'lmnetstrms', reference count now 4 > > > > > > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > > > > > > 9572.672763826:7f07bbbfd910: source file netstrms.c requested > > > > > reference > > > > > > for module 'lmnsd_ptcp', reference count now 1 > > > > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket on > port > > > 514 > > > > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp > > socketWe > > > > > could > > > > > > initialize 0 TCP listen sockets out of 1 we recei > > > > > > ved - this may or may not be an error indication. > > > > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could > > > > successfully > > > > > > be > > > > > > initializedCalled LogError, msg: Could not crea > > > > > > te tcp listener, ignoring port 514. > > > > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from > 'trebuchet', > > > msg > > > > > > Could not create tcp listener, ignoring port 514. [t > > > > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Apr 26 11:45:37 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Apr 2010 11:45:37 +0200 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE7330@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE3@GRFEXC.intern.adiscon.com> <5A6D953473350C4B9995546AFE9939EE08FE7331@RWC-EX1.corp.seven.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CE4@GRFEXC.intern.adiscon.com> While I agree that it is ugly, it sounds like a good idea ;) Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of George Bonser > Sent: Monday, April 26, 2010 11:44 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > Maybe a quick fix would be a "sleep" directive you could place on the > main thread to cause it to delay a bit? That would not be expected to > be > a permanent "fix" but simply a work-around. If I could place something > like "sleep 5" that would cause the main thread to wait a little while, > that could work around the race. > > > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > Sent: Monday, April 26, 2010 2:32 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > non-root. > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > Sent: Monday, April 26, 2010 10:52 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > > root. > > > > > > I think the problem is that it spawns a new thread to load the udp > > and > > > tcp modules and that should be done by the main thread so that it > > gets > > > done in sequence before the privs are processed. > > > > I think your analysis is right, this is where the race happens. > > However, the > > cure is far from being as simple as it sounds: you are actually > > recommending > > a full redesign of the input plugin interface. It would also have > other > > implications, including a potential unacceptable startup delay. > > > > This is what I quoted with "a lot of work to do". So, unfortunately, > it > > does > > not look like something I can fix quickly. Let me once again > reiterate > > that > > the priv drop code is far from being a complete solution. I added the > > current > > code when I saw that it was easy to do and useful for some > situations. > > We > > once had someone who was interested in sponsoring a complete > > implementation, > > but that did unfortunately not materialize. As I am currently short > on > > time > > due to other work to do, I do not find sufficient time to look at > this. > > It is > > far from being a trivial task, even though I hope to be able to do it > > without > > a full redesign. I still think it is 2+ weeks worth of work. > > > > Rainer > > > > > > > > > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > Sent: Monday, April 26, 2010 1:37 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > non-root. > > > > > > > > No problem -- the mailing list processor held it due to size > > > > constrainst (and > > > > I rejected it now). The size restriction was actually the prime > > issue > > > > why I > > > > requested it to go to my private mail. So: nothing bad has > happened > > > ;) > > > > > > > > I'll try to look at the log asap and let you know what I find. > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > Sent: Monday, April 26, 2010 10:10 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > non- > > > > root. > > > > > > > > > > Oops, sorry, I did not mean to send that attachment to the > list. > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > Sent: Sunday, April 25, 2010 11:18 PM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > > > non-root. > > > > > > > > > > > > The privilege drop code is still a hack. It needs proper > > > > engineering > > > > > > (as > > > > > > stated in the doc). So it could very well be a race in this > > > regard. > > > > > On > > > > > > the > > > > > > other hand, it does not look so. Could you send me complete > > debug > > > > > logs > > > > > > to my > > > > > > private email address both with and without privilege drop > > inside > > > > > your > > > > > > config. Maybe it is a simple thing, then I could fix it > without > > > the > > > > > > large > > > > > > effort really required. > > > > > > > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > > > Sent: Monday, April 26, 2010 2:24 AM > > > > > > > To: rsyslog-users > > > > > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID > > non- > > > > root. > > > > > > > > > > > > > > Can't bind to TCP socket. The tcp module loads but I > noticed > > > > that > > > > > it > > > > > > > only tries to bind the socket AFTER it has dropped is privs > > so > > > it > > > > > can > > > > > > > not bind to a socket less than 1024. UDP bind works as > that > > > > seems > > > > > to > > > > > > > bind immediately after module load while the prog is still > > > > running > > > > > as > > > > > > > root. If I set a tcp port >1024, it works. Could this be a > > > race > > > > > > > between > > > > > > > two threads where a different thread is setting the UID/GID > > and > > > a > > > > > > > different one is binding the connections and the UID gets > > > changed > > > > > > > before > > > > > > > the binding thread has a chance to get the socket? > > > > > > > > > > > > > > Modules being loaded: > > > > > > > > > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > > > > > 9572.648636228:7f07c0a216f0: Requested to load module > 'imudp' > > > > > > > 9572.648645873:7f07c0a216f0: loading module > > > > > > '/usr/lib/rsyslog/imudp.so' > > > > > > > 9572.648713628:7f07c0a216f0: source file imudp.c requested > > > > > reference > > > > > > > for > > > > > > > module 'lmnet', reference count now 4 > > > > > > > 9572.648734955:7f07c0a216f0: module of type 0 being loaded. > > > > > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > > > > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP > ports > > at > > > > > > *:514. > > > > > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > > > > > 9572.648859626:7f07c0a216f0: Requested to load module > 'imtcp' > > > > > > > 9572.648869611:7f07c0a216f0: loading module > > > > > > '/usr/lib/rsyslog/imtcp.so' > > > > > > > 9572.648938665:7f07c0a216f0: source file imtcp.c requested > > > > > reference > > > > > > > for > > > > > > > module 'lmnet', reference count now 5 > > > > > > > 9572.648953892:7f07c0a216f0: caller requested object > > 'netstrm', > > > > not > > > > > > > found (iRet -3003) > > > > > > > 9572.648968610:7f07c0a216f0: Requested to load module > > > > 'lmnetstrms' > > > > > > > 9572.648979310:7f07c0a216f0: loading module > > > > > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > > > > > 9572.649053366:7f07c0a216f0: module of type 2 being loaded. > > > > > > > 9572.649068131:7f07c0a216f0: source file imtcp.c requested > > > > > reference > > > > > > > for > > > > > > > module 'lmnetstrms', reference count now 1 > > > > > > > 9572.649079163:7f07c0a216f0: caller requested object > > > 'tcps_sess', > > > > > not > > > > > > > found (iRet -3003) > > > > > > > 9572.649095086:7f07c0a216f0: Requested to load module > > > 'lmtcpsrv' > > > > > > > 9572.649105485:7f07c0a216f0: loading module > > > > > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > > > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c > > requested > > > > > > > reference > > > > > > > for module 'lmnetstrms', reference count now 2 > > > > > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c requested > > > > > reference > > > > > > > for module 'lmnet', reference count now 6 > > > > > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c requested > > > > > reference > > > > > > > for module 'lmnetstrms', reference count now 3 > > > > > > > 9572.649231362:7f07c0a216f0: module of type 2 being loaded. > > > > > > > 9572.649241801:7f07c0a216f0: source file imtcp.c requested > > > > > reference > > > > > > > for > > > > > > > module 'lmtcpsrv', reference count now 1 > > > > > > > 9572.649252009:7f07c0a216f0: source file imtcp.c requested > > > > > reference > > > > > > > for > > > > > > > module 'lmtcpsrv', reference count now 2 > > > > > > > 9572.649287366:7f07c0a216f0: module of type 0 being loaded. > > > > > > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun > 514' > > > > > > > 9572.649321373:7f07c0a216f0: cfline: > > > '$ActionFileDefaultTemplate > > > > > > > RSYSLOG_TraditionalFileFormat' > > > > > > > 9572.649334345:7f07c0a216f0: cfline: '$RepeatedMsgReduction > > on' > > > > > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > > > > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user > > 'syslog' > > > > > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > > > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group 'adm' > > > > > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode 0640' > > > > > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode 0755' > > > > > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > > > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > > > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser > syslog' > > > > > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user > > 'syslog' > > > > > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup > > syslog' > > > > > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group > > > 'syslog' > > > > > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > > > > > /etc/rsyslog.d/*.conf' > > > > > > > 9572.650017305:7f07c0a216f0: requested to include config > file > > > > > > > '/etc/rsyslog.d/50-default.conf' > > > > > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > > > > > /var/log/auth.log' > > > > > > > > > > > > > > GID and UID being changed: > > > > > > > > > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm > 0x1e11d60, > > > > > lenBuf > > > > > > 78 > > > > > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from > > 'trebuchet', > > > > msg > > > > > > > rsyslogd's groupid changed to 103 > > > > > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog > > format. > > > > > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > > > > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > > > > > > 9572.671957623:7f07be402910: Called action, logging to > > builtin- > > > > pipe > > > > > > > 9572.671969801:7f07be402910: extend buf to at least 16, > done > > > 128 > > > > > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > > > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size now > 2 > > > > > entries > > > > > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals > busy > > > > > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised > > worker > > > > > start > > > > > > > 9572.672059720:7f07be402910: Action requested to be > > suspended, > > > > done > > > > > > > that. > > > > > > > 9572.672085037:7f07be402910: main Q: entry deleted, state > 0, > > > size > > > > > now > > > > > > 1 > > > > > > > entries > > > > > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > > > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > > > > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > > > > > > 9572.672147659:7f07be402910: Called action, logging to > > builtin- > > > > file > > > > > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from > > 'trebuchet', > > > > msg > > > > > > > rsyslogd's userid changed to 101 > > > > > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog > > format. > > > > > > > 9572.672192329:7f07be402910: extend buf to at least 138, > done > > > 256 > > > > > > > 9572.672200766:7f07be402910: file to log to: > /var/log/syslog > > > > > > > > > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > > > > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > > > > > transitioning > > > > > > to > > > > > > > regular run mode > > > > > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd > socket > > 4 > > > > > > > (IPv4/port 514). > > > > > > > 9572.672576606:7f07bc3fe910: --------imUDP calling select, > > > active > > > > > > file > > > > > > > descriptors (max 4): 4 > > > > > > > 9572.672594858:7f07bdc01910: --------imuxsock calling > select, > > > > > active > > > > > > > file descriptors (max 5): 3 5 > > > > > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals > busy > > > > > > > 9572.672646478:7f07bbbfd910: caller requested object > > > 'nsd_ptcp', > > > > > not > > > > > > > found (iRet -3003) > > > > > > > 9572.672663716:7f07bbbfd910: Requested to load module > > > > 'lmnsd_ptcp' > > > > > > > 9572.672671184:7f07bbbfd910: loading module > > > > > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > > > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c > requested > > > > > > reference > > > > > > > for module 'lmnetstrms', reference count now 4 > > > > > > > 9572.672757197:7f07bbbfd910: module of type 2 being loaded. > > > > > > > 9572.672763826:7f07bbbfd910: source file netstrms.c > requested > > > > > > reference > > > > > > > for module 'lmnsd_ptcp', reference count now 1 > > > > > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket on > > port > > > > 514 > > > > > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp > > > socketWe > > > > > > could > > > > > > > initialize 0 TCP listen sockets out of 1 we recei > > > > > > > ved - this may or may not be an error indication. > > > > > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could > > > > > successfully > > > > > > > be > > > > > > > initializedCalled LogError, msg: Could not crea > > > > > > > te tcp listener, ignoring port 514. > > > > > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from > > 'trebuchet', > > > > msg > > > > > > > Could not create tcp listener, ignoring port 514. [t > > > > > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > > > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Apr 26 12:09:55 2010 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 26 Apr 2010 12:09:55 +0200 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE7330@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE3@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE7331@RWC-EX1.corp.seven.com> <9B6E2A8877C38245BFB15CC491A11DA7103CE4@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA7103CE5@GRFEXC.intern.adiscon.com> This is the patch for v4-devel (master will follow soon): http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=d19806431653e6575a002ab4 8206c16d3041e465 While I make such changes only to the latest devel, you should be able to apply the patch without problems to almost all versions. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Monday, April 26, 2010 11:46 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > While I agree that it is ugly, it sounds like a good idea ;) > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > Sent: Monday, April 26, 2010 11:44 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > root. > > > > Maybe a quick fix would be a "sleep" directive you could place on the > > main thread to cause it to delay a bit? That would not be expected to > > be > > a permanent "fix" but simply a work-around. If I could place > something > > like "sleep 5" that would cause the main thread to wait a little > while, > > that could work around the race. > > > > > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > Sent: Monday, April 26, 2010 2:32 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > non-root. > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > Sent: Monday, April 26, 2010 10:52 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > non- > > > root. > > > > > > > > I think the problem is that it spawns a new thread to load the > udp > > > and > > > > tcp modules and that should be done by the main thread so that it > > > gets > > > > done in sequence before the privs are processed. > > > > > > I think your analysis is right, this is where the race happens. > > > However, the > > > cure is far from being as simple as it sounds: you are actually > > > recommending > > > a full redesign of the input plugin interface. It would also have > > other > > > implications, including a potential unacceptable startup delay. > > > > > > This is what I quoted with "a lot of work to do". So, > unfortunately, > > it > > > does > > > not look like something I can fix quickly. Let me once again > > reiterate > > > that > > > the priv drop code is far from being a complete solution. I added > the > > > current > > > code when I saw that it was easy to do and useful for some > > situations. > > > We > > > once had someone who was interested in sponsoring a complete > > > implementation, > > > but that did unfortunately not materialize. As I am currently short > > on > > > time > > > due to other work to do, I do not find sufficient time to look at > > this. > > > It is > > > far from being a trivial task, even though I hope to be able to do > it > > > without > > > a full redesign. I still think it is 2+ weeks worth of work. > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > Sent: Monday, April 26, 2010 1:37 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > > non-root. > > > > > > > > > > No problem -- the mailing list processor held it due to size > > > > > constrainst (and > > > > > I rejected it now). The size restriction was actually the prime > > > issue > > > > > why I > > > > > requested it to go to my private mail. So: nothing bad has > > happened > > > > ;) > > > > > > > > > > I'll try to look at the log asap and let you know what I find. > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > > Sent: Monday, April 26, 2010 10:10 AM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > non- > > > > > root. > > > > > > > > > > > > Oops, sorry, I did not mean to send that attachment to the > > list. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > > Sent: Sunday, April 25, 2010 11:18 PM > > > > > > > To: rsyslog-users > > > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after > UID > > > > > > non-root. > > > > > > > > > > > > > > The privilege drop code is still a hack. It needs proper > > > > > engineering > > > > > > > (as > > > > > > > stated in the doc). So it could very well be a race in this > > > > regard. > > > > > > On > > > > > > > the > > > > > > > other hand, it does not look so. Could you send me complete > > > debug > > > > > > logs > > > > > > > to my > > > > > > > private email address both with and without privilege drop > > > inside > > > > > > your > > > > > > > config. Maybe it is a simple thing, then I could fix it > > without > > > > the > > > > > > > large > > > > > > > effort really required. > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > > > > Sent: Monday, April 26, 2010 2:24 AM > > > > > > > > To: rsyslog-users > > > > > > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > non- > > > > > root. > > > > > > > > > > > > > > > > Can't bind to TCP socket. The tcp module loads but I > > noticed > > > > > that > > > > > > it > > > > > > > > only tries to bind the socket AFTER it has dropped is > privs > > > so > > > > it > > > > > > can > > > > > > > > not bind to a socket less than 1024. UDP bind works as > > that > > > > > seems > > > > > > to > > > > > > > > bind immediately after module load while the prog is > still > > > > > running > > > > > > as > > > > > > > > root. If I set a tcp port >1024, it works. Could this be > a > > > > race > > > > > > > > between > > > > > > > > two threads where a different thread is setting the > UID/GID > > > and > > > > a > > > > > > > > different one is binding the connections and the UID gets > > > > changed > > > > > > > > before > > > > > > > > the binding thread has a chance to get the socket? > > > > > > > > > > > > > > > > Modules being loaded: > > > > > > > > > > > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > > > > > > 9572.648636228:7f07c0a216f0: Requested to load module > > 'imudp' > > > > > > > > 9572.648645873:7f07c0a216f0: loading module > > > > > > > '/usr/lib/rsyslog/imudp.so' > > > > > > > > 9572.648713628:7f07c0a216f0: source file imudp.c > requested > > > > > > reference > > > > > > > > for > > > > > > > > module 'lmnet', reference count now 4 > > > > > > > > 9572.648734955:7f07c0a216f0: module of type 0 being > loaded. > > > > > > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun 514' > > > > > > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP > > ports > > > at > > > > > > > *:514. > > > > > > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > > > > > > 9572.648859626:7f07c0a216f0: Requested to load module > > 'imtcp' > > > > > > > > 9572.648869611:7f07c0a216f0: loading module > > > > > > > '/usr/lib/rsyslog/imtcp.so' > > > > > > > > 9572.648938665:7f07c0a216f0: source file imtcp.c > requested > > > > > > reference > > > > > > > > for > > > > > > > > module 'lmnet', reference count now 5 > > > > > > > > 9572.648953892:7f07c0a216f0: caller requested object > > > 'netstrm', > > > > > not > > > > > > > > found (iRet -3003) > > > > > > > > 9572.648968610:7f07c0a216f0: Requested to load module > > > > > 'lmnetstrms' > > > > > > > > 9572.648979310:7f07c0a216f0: loading module > > > > > > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > > > > > > 9572.649053366:7f07c0a216f0: module of type 2 being > loaded. > > > > > > > > 9572.649068131:7f07c0a216f0: source file imtcp.c > requested > > > > > > reference > > > > > > > > for > > > > > > > > module 'lmnetstrms', reference count now 1 > > > > > > > > 9572.649079163:7f07c0a216f0: caller requested object > > > > 'tcps_sess', > > > > > > not > > > > > > > > found (iRet -3003) > > > > > > > > 9572.649095086:7f07c0a216f0: Requested to load module > > > > 'lmtcpsrv' > > > > > > > > 9572.649105485:7f07c0a216f0: loading module > > > > > > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > > > > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c > > > requested > > > > > > > > reference > > > > > > > > for module 'lmnetstrms', reference count now 2 > > > > > > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c > requested > > > > > > reference > > > > > > > > for module 'lmnet', reference count now 6 > > > > > > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c > requested > > > > > > reference > > > > > > > > for module 'lmnetstrms', reference count now 3 > > > > > > > > 9572.649231362:7f07c0a216f0: module of type 2 being > loaded. > > > > > > > > 9572.649241801:7f07c0a216f0: source file imtcp.c > requested > > > > > > reference > > > > > > > > for > > > > > > > > module 'lmtcpsrv', reference count now 1 > > > > > > > > 9572.649252009:7f07c0a216f0: source file imtcp.c > requested > > > > > > reference > > > > > > > > for > > > > > > > > module 'lmtcpsrv', reference count now 2 > > > > > > > > 9572.649287366:7f07c0a216f0: module of type 0 being > loaded. > > > > > > > > 9572.649299663:7f07c0a216f0: cfline: '$InputTCPServerRun > > 514' > > > > > > > > 9572.649321373:7f07c0a216f0: cfline: > > > > '$ActionFileDefaultTemplate > > > > > > > > RSYSLOG_TraditionalFileFormat' > > > > > > > > 9572.649334345:7f07c0a216f0: cfline: > '$RepeatedMsgReduction > > > on' > > > > > > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner syslog' > > > > > > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user > > > 'syslog' > > > > > > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > > > > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group > 'adm' > > > > > > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode > 0640' > > > > > > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode > 0755' > > > > > > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > > > > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > > > > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser > > syslog' > > > > > > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user > > > 'syslog' > > > > > > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup > > > syslog' > > > > > > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group > > > > 'syslog' > > > > > > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > > > > > > /etc/rsyslog.d/*.conf' > > > > > > > > 9572.650017305:7f07c0a216f0: requested to include config > > file > > > > > > > > '/etc/rsyslog.d/50-default.conf' > > > > > > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > > > > > > /var/log/auth.log' > > > > > > > > > > > > > > > > GID and UID being changed: > > > > > > > > > > > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm > > 0x1e11d60, > > > > > > lenBuf > > > > > > > 78 > > > > > > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from > > > 'trebuchet', > > > > > msg > > > > > > > > rsyslogd's groupid changed to 103 > > > > > > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog > > > format. > > > > > > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > > > > > > 9572.671947526:7f07be402910: testing filter, f_pmask 240 > > > > > > > > 9572.671957623:7f07be402910: Called action, logging to > > > builtin- > > > > > pipe > > > > > > > > 9572.671969801:7f07be402910: extend buf to at least 16, > > done > > > > 128 > > > > > > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > > > > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size > now > > 2 > > > > > > entries > > > > > > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers signals > > busy > > > > > > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised > > > worker > > > > > > start > > > > > > > > 9572.672059720:7f07be402910: Action requested to be > > > suspended, > > > > > done > > > > > > > > that. > > > > > > > > 9572.672085037:7f07be402910: main Q: entry deleted, state > > 0, > > > > size > > > > > > now > > > > > > > 1 > > > > > > > > entries > > > > > > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > > > > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > > > > > > 9572.672136161:7f07be402910: testing filter, f_pmask 255 > > > > > > > > 9572.672147659:7f07be402910: Called action, logging to > > > builtin- > > > > > file > > > > > > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from > > > 'trebuchet', > > > > > msg > > > > > > > > rsyslogd's userid changed to 101 > > > > > > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog > > > format. > > > > > > > > 9572.672192329:7f07be402910: extend buf to at least 138, > > done > > > > 256 > > > > > > > > 9572.672200766:7f07be402910: file to log to: > > /var/log/syslog > > > > > > > > > > > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > > > > > > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > > > > > > transitioning > > > > > > > to > > > > > > > > regular run mode > > > > > > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd > > socket > > > 4 > > > > > > > > (IPv4/port 514). > > > > > > > > 9572.672576606:7f07bc3fe910: --------imUDP calling > select, > > > > active > > > > > > > file > > > > > > > > descriptors (max 4): 4 > > > > > > > > 9572.672594858:7f07bdc01910: --------imuxsock calling > > select, > > > > > > active > > > > > > > > file descriptors (max 5): 3 5 > > > > > > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers signals > > busy > > > > > > > > 9572.672646478:7f07bbbfd910: caller requested object > > > > 'nsd_ptcp', > > > > > > not > > > > > > > > found (iRet -3003) > > > > > > > > 9572.672663716:7f07bbbfd910: Requested to load module > > > > > 'lmnsd_ptcp' > > > > > > > > 9572.672671184:7f07bbbfd910: loading module > > > > > > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > > > > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c > > requested > > > > > > > reference > > > > > > > > for module 'lmnetstrms', reference count now 4 > > > > > > > > 9572.672757197:7f07bbbfd910: module of type 2 being > loaded. > > > > > > > > 9572.672763826:7f07bbbfd910: source file netstrms.c > > requested > > > > > > > reference > > > > > > > > for module 'lmnsd_ptcp', reference count now 1 > > > > > > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket > on > > > port > > > > > 514 > > > > > > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp > > > > socketWe > > > > > > > could > > > > > > > > initialize 0 TCP listen sockets out of 1 we recei > > > > > > > > ved - this may or may not be an error indication. > > > > > > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets could > > > > > > successfully > > > > > > > > be > > > > > > > > initializedCalled LogError, msg: Could not crea > > > > > > > > te tcp listener, ignoring port 514. > > > > > > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from > > > 'trebuchet', > > > > > msg > > > > > > > > Could not create tcp listener, ignoring port 514. [t > > > > > > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From gbonser at seven.com Mon Apr 26 23:42:11 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 26 Apr 2010 14:42:11 -0700 Subject: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. References: <5A6D953473350C4B9995546AFE9939EE08FE731F@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CDE@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE732D@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE1@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE7330@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE3@GRFEXC.intern.adiscon.com><5A6D953473350C4B9995546AFE9939EE08FE7331@RWC-EX1.corp.seven.com><9B6E2A8877C38245BFB15CC491A11DA7103CE4@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA7103CE5@GRFEXC.intern.adiscon.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE736D@RWC-EX1.corp.seven.com> It doesn't work. TCP doesn't start until after privs are dropped. Just can't use it or must drop privs after binding the socket (like Apache does, for example). > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Monday, April 26, 2010 3:10 AM > To: rsyslog-users > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non-root. > > This is the patch for v4-devel (master will follow soon): > > http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=d19806431653e6575a > 002ab4 > 8206c16d3041e465 > > While I make such changes only to the latest devel, you should be able > to > apply the patch without problems to almost all versions. > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > Sent: Monday, April 26, 2010 11:46 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > root. > > > > While I agree that it is ugly, it sounds like a good idea ;) > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > Sent: Monday, April 26, 2010 11:44 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID non- > > root. > > > > > > Maybe a quick fix would be a "sleep" directive you could place on > the > > > main thread to cause it to delay a bit? That would not be expected > to > > > be > > > a permanent "fix" but simply a work-around. If I could place > > something > > > like "sleep 5" that would cause the main thread to wait a little > > while, > > > that could work around the race. > > > > > > > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > Sent: Monday, April 26, 2010 2:32 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > non-root. > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > Sent: Monday, April 26, 2010 10:52 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > non- > > > > root. > > > > > > > > > > I think the problem is that it spawns a new thread to load the > > udp > > > > and > > > > > tcp modules and that should be done by the main thread so that > it > > > > gets > > > > > done in sequence before the privs are processed. > > > > > > > > I think your analysis is right, this is where the race happens. > > > > However, the > > > > cure is far from being as simple as it sounds: you are actually > > > > recommending > > > > a full redesign of the input plugin interface. It would also have > > > other > > > > implications, including a potential unacceptable startup delay. > > > > > > > > This is what I quoted with "a lot of work to do". So, > > unfortunately, > > > it > > > > does > > > > not look like something I can fix quickly. Let me once again > > > reiterate > > > > that > > > > the priv drop code is far from being a complete solution. I added > > the > > > > current > > > > code when I saw that it was easy to do and useful for some > > > situations. > > > > We > > > > once had someone who was interested in sponsoring a complete > > > > implementation, > > > > but that did unfortunately not materialize. As I am currently > short > > > on > > > > time > > > > due to other work to do, I do not find sufficient time to look at > > > this. > > > > It is > > > > far from being a trivial task, even though I hope to be able to > do > > it > > > > without > > > > a full redesign. I still think it is 2+ weeks worth of work. > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > Sent: Monday, April 26, 2010 1:37 AM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after UID > > > > > non-root. > > > > > > > > > > > > No problem -- the mailing list processor held it due to size > > > > > > constrainst (and > > > > > > I rejected it now). The size restriction was actually the > prime > > > > issue > > > > > > why I > > > > > > requested it to go to my private mail. So: nothing bad has > > > happened > > > > > ;) > > > > > > > > > > > > I'll try to look at the log asap and let you know what I > find. > > > > > > > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > > > Sent: Monday, April 26, 2010 10:10 AM > > > > > > > To: rsyslog-users > > > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after > UID > > > > non- > > > > > > root. > > > > > > > > > > > > > > Oops, sorry, I did not mean to send that attachment to the > > > list. > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > > > Sent: Sunday, April 25, 2010 11:18 PM > > > > > > > > To: rsyslog-users > > > > > > > > Subject: Re: [rsyslog] Problem with 4.6.2 TCP binds after > > UID > > > > > > > non-root. > > > > > > > > > > > > > > > > The privilege drop code is still a hack. It needs proper > > > > > > engineering > > > > > > > > (as > > > > > > > > stated in the doc). So it could very well be a race in > this > > > > > regard. > > > > > > > On > > > > > > > > the > > > > > > > > other hand, it does not look so. Could you send me > complete > > > > debug > > > > > > > logs > > > > > > > > to my > > > > > > > > private email address both with and without privilege > drop > > > > inside > > > > > > > your > > > > > > > > config. Maybe it is a simple thing, then I could fix it > > > without > > > > > the > > > > > > > > large > > > > > > > > effort really required. > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog- > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of George Bonser > > > > > > > > > Sent: Monday, April 26, 2010 2:24 AM > > > > > > > > > To: rsyslog-users > > > > > > > > > Subject: [rsyslog] Problem with 4.6.2 TCP binds after > UID > > > > non- > > > > > > root. > > > > > > > > > > > > > > > > > > Can't bind to TCP socket. The tcp module loads but I > > > noticed > > > > > > that > > > > > > > it > > > > > > > > > only tries to bind the socket AFTER it has dropped is > > privs > > > > so > > > > > it > > > > > > > can > > > > > > > > > not bind to a socket less than 1024. UDP bind works as > > > that > > > > > > seems > > > > > > > to > > > > > > > > > bind immediately after module load while the prog is > > still > > > > > > running > > > > > > > as > > > > > > > > > root. If I set a tcp port >1024, it works. Could this > be > > a > > > > > race > > > > > > > > > between > > > > > > > > > two threads where a different thread is setting the > > UID/GID > > > > and > > > > > a > > > > > > > > > different one is binding the connections and the UID > gets > > > > > changed > > > > > > > > > before > > > > > > > > > the binding thread has a chance to get the socket? > > > > > > > > > > > > > > > > > > Modules being loaded: > > > > > > > > > > > > > > > > > > 9572.648625421:7f07c0a216f0: cfline: '$ModLoad imudp' > > > > > > > > > 9572.648636228:7f07c0a216f0: Requested to load module > > > 'imudp' > > > > > > > > > 9572.648645873:7f07c0a216f0: loading module > > > > > > > > '/usr/lib/rsyslog/imudp.so' > > > > > > > > > 9572.648713628:7f07c0a216f0: source file imudp.c > > requested > > > > > > > reference > > > > > > > > > for > > > > > > > > > module 'lmnet', reference count now 4 > > > > > > > > > 9572.648734955:7f07c0a216f0: module of type 0 being > > loaded. > > > > > > > > > 9572.648747037:7f07c0a216f0: cfline: '$UDPServerRun > 514' > > > > > > > > > 9572.648759295:7f07c0a216f0: Trying to open syslog UDP > > > ports > > > > at > > > > > > > > *:514. > > > > > > > > > 9572.648845036:7f07c0a216f0: cfline: '$ModLoad imtcp' > > > > > > > > > 9572.648859626:7f07c0a216f0: Requested to load module > > > 'imtcp' > > > > > > > > > 9572.648869611:7f07c0a216f0: loading module > > > > > > > > '/usr/lib/rsyslog/imtcp.so' > > > > > > > > > 9572.648938665:7f07c0a216f0: source file imtcp.c > > requested > > > > > > > reference > > > > > > > > > for > > > > > > > > > module 'lmnet', reference count now 5 > > > > > > > > > 9572.648953892:7f07c0a216f0: caller requested object > > > > 'netstrm', > > > > > > not > > > > > > > > > found (iRet -3003) > > > > > > > > > 9572.648968610:7f07c0a216f0: Requested to load module > > > > > > 'lmnetstrms' > > > > > > > > > 9572.648979310:7f07c0a216f0: loading module > > > > > > > > > '/usr/lib/rsyslog/lmnetstrms.so' > > > > > > > > > 9572.649053366:7f07c0a216f0: module of type 2 being > > loaded. > > > > > > > > > 9572.649068131:7f07c0a216f0: source file imtcp.c > > requested > > > > > > > reference > > > > > > > > > for > > > > > > > > > module 'lmnetstrms', reference count now 1 > > > > > > > > > 9572.649079163:7f07c0a216f0: caller requested object > > > > > 'tcps_sess', > > > > > > > not > > > > > > > > > found (iRet -3003) > > > > > > > > > 9572.649095086:7f07c0a216f0: Requested to load module > > > > > 'lmtcpsrv' > > > > > > > > > 9572.649105485:7f07c0a216f0: loading module > > > > > > > > > '/usr/lib/rsyslog/lmtcpsrv.so' > > > > > > > > > 9572.649188177:7f07c0a216f0: source file tcps_sess.c > > > > requested > > > > > > > > > reference > > > > > > > > > for module 'lmnetstrms', reference count now 2 > > > > > > > > > 9572.649206712:7f07c0a216f0: source file tcpsrv.c > > requested > > > > > > > reference > > > > > > > > > for module 'lmnet', reference count now 6 > > > > > > > > > 9572.649217297:7f07c0a216f0: source file tcpsrv.c > > requested > > > > > > > reference > > > > > > > > > for module 'lmnetstrms', reference count now 3 > > > > > > > > > 9572.649231362:7f07c0a216f0: module of type 2 being > > loaded. > > > > > > > > > 9572.649241801:7f07c0a216f0: source file imtcp.c > > requested > > > > > > > reference > > > > > > > > > for > > > > > > > > > module 'lmtcpsrv', reference count now 1 > > > > > > > > > 9572.649252009:7f07c0a216f0: source file imtcp.c > > requested > > > > > > > reference > > > > > > > > > for > > > > > > > > > module 'lmtcpsrv', reference count now 2 > > > > > > > > > 9572.649287366:7f07c0a216f0: module of type 0 being > > loaded. > > > > > > > > > 9572.649299663:7f07c0a216f0: cfline: > '$InputTCPServerRun > > > 514' > > > > > > > > > 9572.649321373:7f07c0a216f0: cfline: > > > > > '$ActionFileDefaultTemplate > > > > > > > > > RSYSLOG_TraditionalFileFormat' > > > > > > > > > 9572.649334345:7f07c0a216f0: cfline: > > '$RepeatedMsgReduction > > > > on' > > > > > > > > > 9572.649382777:7f07c0a216f0: cfline: '$FileOwner > syslog' > > > > > > > > > 9572.649703828:7f07c0a216f0: uid 101 obtained for user > > > > 'syslog' > > > > > > > > > 9572.649720763:7f07c0a216f0: cfline: '$FileGroup adm' > > > > > > > > > 9572.649790575:7f07c0a216f0: gid 4 obtained for group > > 'adm' > > > > > > > > > 9572.649805222:7f07c0a216f0: cfline: '$FileCreateMode > > 0640' > > > > > > > > > 9572.649816505:7f07c0a216f0: cfline: '$DirCreateMode > > 0755' > > > > > > > > > 9572.649827020:7f07c0a216f0: cfline: '$Umask 0022' > > > > > > > > > 9572.649840237:7f07c0a216f0: umask set to 0022. > > > > > > > > > 9572.649850064:7f07c0a216f0: cfline: '$PrivDropToUser > > > syslog' > > > > > > > > > 9572.649885709:7f07c0a216f0: uid 101 obtained for user > > > > 'syslog' > > > > > > > > > 9572.649898391:7f07c0a216f0: cfline: '$PrivDropToGroup > > > > syslog' > > > > > > > > > 9572.649934688:7f07c0a216f0: gid 103 obtained for group > > > > > 'syslog' > > > > > > > > > 9572.649948278:7f07c0a216f0: cfline: '$IncludeConfig > > > > > > > > > /etc/rsyslog.d/*.conf' > > > > > > > > > 9572.650017305:7f07c0a216f0: requested to include > config > > > file > > > > > > > > > '/etc/rsyslog.d/50-default.conf' > > > > > > > > > 9572.650045382:7f07c0a216f0: cfline: 'auth,authpriv.* > > > > > > > > > /var/log/auth.log' > > > > > > > > > > > > > > > > > > GID and UID being changed: > > > > > > > > > > > > > > > > > > 9572.671888467:7f07be402910: doWrite, pData->pStrm > > > 0x1e11d60, > > > > > > > lenBuf > > > > > > > > 78 > > > > > > > > > 9572.671902407:7f07c0a216f0: logmsg: flags 1, from > > > > 'trebuchet', > > > > > > msg > > > > > > > > > rsyslogd's groupid changed to 103 > > > > > > > > > 9572.671920644:7f07c0a216f0: Message has legacy syslog > > > > format. > > > > > > > > > 9572.671933956:7f07be402910: testing filter, f_pmask 1 > > > > > > > > > 9572.671947526:7f07be402910: testing filter, f_pmask > 240 > > > > > > > > > 9572.671957623:7f07be402910: Called action, logging to > > > > builtin- > > > > > > pipe > > > > > > > > > 9572.671969801:7f07be402910: extend buf to at least 16, > > > done > > > > > 128 > > > > > > > > > 9572.671982061:7f07be402910: (/dev/xconsole) > > > > > > > > > 9572.671999956:7f07c0a216f0: main Q: entry added, size > > now > > > 2 > > > > > > > entries > > > > > > > > > 9572.672025520:7f07c0a216f0: wtpAdviseMaxWorkers > signals > > > busy > > > > > > > > > 9572.672041633:7f07c0a216f0: main Q: EnqueueMsg advised > > > > worker > > > > > > > start > > > > > > > > > 9572.672059720:7f07be402910: Action requested to be > > > > suspended, > > > > > > done > > > > > > > > > that. > > > > > > > > > 9572.672085037:7f07be402910: main Q: entry deleted, > state > > > 0, > > > > > size > > > > > > > now > > > > > > > > 1 > > > > > > > > > entries > > > > > > > > > 9572.672099142:7f07c0a216f0: setuid(101): 0 > > > > > > > > > 9572.672122289:7f07be402910: testing filter, f_pmask 0 > > > > > > > > > 9572.672136161:7f07be402910: testing filter, f_pmask > 255 > > > > > > > > > 9572.672147659:7f07be402910: Called action, logging to > > > > builtin- > > > > > > file > > > > > > > > > 9572.672162158:7f07c0a216f0: logmsg: flags 1, from > > > > 'trebuchet', > > > > > > msg > > > > > > > > > rsyslogd's userid changed to 101 > > > > > > > > > 9572.672179992:7f07c0a216f0: Message has legacy syslog > > > > format. > > > > > > > > > 9572.672192329:7f07be402910: extend buf to at least > 138, > > > done > > > > > 256 > > > > > > > > > 9572.672200766:7f07be402910: file to log to: > > > /var/log/syslog > > > > > > > > > > > > > > > > > > UDP socket bind succeeded but TCP bind fails: > > > > > > > > > > > > > > > > > > 9572.672546363:7f07c0a216f0: initialization completed, > > > > > > > transitioning > > > > > > > > to > > > > > > > > > regular run mode > > > > > > > > > 9572.672557359:7f07bc3fe910: Listening on UDP syslogd > > > socket > > > > 4 > > > > > > > > > (IPv4/port 514). > > > > > > > > > 9572.672576606:7f07bc3fe910: --------imUDP calling > > select, > > > > > active > > > > > > > > file > > > > > > > > > descriptors (max 4): 4 > > > > > > > > > 9572.672594858:7f07bdc01910: --------imuxsock calling > > > select, > > > > > > > active > > > > > > > > > file descriptors (max 5): 3 5 > > > > > > > > > 9572.672630154:7f07bd400910: wtpAdviseMaxWorkers > signals > > > busy > > > > > > > > > 9572.672646478:7f07bbbfd910: caller requested object > > > > > 'nsd_ptcp', > > > > > > > not > > > > > > > > > found (iRet -3003) > > > > > > > > > 9572.672663716:7f07bbbfd910: Requested to load module > > > > > > 'lmnsd_ptcp' > > > > > > > > > 9572.672671184:7f07bbbfd910: loading module > > > > > > > > > '/usr/lib/rsyslog/lmnsd_ptcp.so' > > > > > > > > > 9572.672745761:7f07bbbfd910: source file nsd_ptcp.c > > > requested > > > > > > > > reference > > > > > > > > > for module 'lmnetstrms', reference count now 4 > > > > > > > > > 9572.672757197:7f07bbbfd910: module of type 2 being > > loaded. > > > > > > > > > 9572.672763826:7f07bbbfd910: source file netstrms.c > > > requested > > > > > > > > reference > > > > > > > > > for module 'lmnsd_ptcp', reference count now 1 > > > > > > > > > 9572.672770522:7f07bbbfd910: creating tcp listen socket > > on > > > > port > > > > > > 514 > > > > > > > > > 9572.672803781:7f07bbbfd910: error 13 while binding tcp > > > > > socketWe > > > > > > > > could > > > > > > > > > initialize 0 TCP listen sockets out of 1 we recei > > > > > > > > > ved - this may or may not be an error indication. > > > > > > > > > 9572.672824933:7f07bbbfd910: No TCP listen sockets > could > > > > > > > successfully > > > > > > > > > be > > > > > > > > > initializedCalled LogError, msg: Could not crea > > > > > > > > > te tcp listener, ignoring port 514. > > > > > > > > > 9572.672844597:7f07bbbfd910: logmsg: flags 1, from > > > > 'trebuchet', > > > > > > msg > > > > > > > > > Could not create tcp listener, ignoring port 514. [t > > > > > > > > > ry http://www.rsyslog.com/e/2077 ] > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > rsyslog mailing list > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > http://www.rsyslog.com > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From jkempf at davisvision.com Tue Apr 27 04:15:46 2010 From: jkempf at davisvision.com (Jesse Kempf) Date: Tue, 27 Apr 2010 02:15:46 +0000 Subject: [rsyslog] Solaris SMF Manifest Message-ID: <13819_1272334548_4BD648D3_13819_1145_1_4BD648D2.4090408@davisvision.com> Hi, So I've been working on getting rsyslogd set up on a Solaris platform (not as a local syslog replacement, but as the central syslog server for a network). Attached is a patchset which adds a Solaris SMF service manifest (rsyslog.xml) and method script (svc-rsyslog). I'm not sure how exactly to wire this into the install process, so I'll describe what needs to get done. svc-rsyslog needs to be kicked into $PREFIX/etc and be chmod +x. rsyslog.xml needs the literal string 'PREFIX' replaced with $PREFIX, and then passed to svccfg import. Something as simple as 'sed "s#PREFIX#$PREFIX#g" < rsyslog.xml | svccfg import -' would do the trick. The manifest registers rsyslog with SMF under the FMRI svc:/network/rsyslog:default. The properties (accessible using svcprop) 'rsyslog/conf' and 'rsyslog/opts' contain the path to the config file and any command-line options for rsyslog respectively. I've also updated http://wiki.rsyslog.com/index.php/Solaris based on my experiences getting rsyslog working on Solaris 10. All in all, this has been much, MUCH easier than it was when I tried two years ago. Cheers, -Jesse ------------------------------------------------------------------------ The information contained in this communication is intended only for the use of the recipient(s) named above. It may contain information that is privileged or confidential, and may be protected by State and/or Federal Regulations. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. ------------------------------------------------------------------------ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: solaris-smf.patches URL: From gbonser at seven.com Tue Apr 27 23:42:30 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 27 Apr 2010 14:42:30 -0700 Subject: [rsyslog] Question about output channels Message-ID: <5A6D953473350C4B9995546AFE9939EE08FE73B3@RWC-EX1.corp.seven.com> When an output channel runs a rotation script due to file size limit being reached, does it pass anything in the environment to tell a log rotation program which file triggered the rotation? That would be handy by allowing a single rotation script to handle all the output channels if it could pick up the file to rotate from the environment when it is run. George From jkempf at davisvision.com Wed Apr 28 18:38:55 2010 From: jkempf at davisvision.com (Jesse Kempf) Date: Wed, 28 Apr 2010 16:38:55 +0000 Subject: [rsyslog] Tuning reconnect delay Message-ID: <13016_1272472735_4BD8649F_13016_205_1_4BD8649F.90508@davisvision.com> Hi, Is there any way to adjust how long rsyslog will wait to reconnect after a TCP session to a remote server has been closed? I looked through the documentation but nothing jumped out at me. Thanks, -Jesse ------------------------------------------------------------------------ The information contained in this communication is intended only for the use of the recipient(s) named above. It may contain information that is privileged or confidential, and may be protected by State and/or Federal Regulations. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. ------------------------------------------------------------------------ From b.arenal at gmail.com Thu Apr 29 19:07:04 2010 From: b.arenal at gmail.com (Bryan Arenal) Date: Thu, 29 Apr 2010 11:07:04 -0600 Subject: [rsyslog] Running in debug mode: -1 bytes? Message-ID: Hi, I have two systems running rsyslog 4.2.0 and snort 2.8.5.3. ?On one of those systems, it's forwarding snort's alert logs to our central log server correctly. ?On the second box (that has the same snort and rsyslog configs), it has only forwarded one alert but the alert file is seeing a lot of data so I don't know what's going on. ?I put rsyslog in debug mode and every 10 secs, it logs the following message: ?4478.108169000:41851940: strm 0x1e8b5dd0: file 6 read -1 bytes ?4478.108225000:41851940: strm 0x1e8b6fc0: file 7 read 0 bytes What does that mean? ?It appears that the only time it deviated was when it sent the one alert to the syslog server: ?4148.075280000:41851940: strm 0x1e8b6fc0: file 7 read 225 bytes But the file that it's referring to as "file 6" is seeing much more data than "file 7" and it shouldn't have any problem reading it as it's 644 and owned by snort.snort (rsyslog is running as root). ?Does anyone know what might be going on or have anything I can try? Thanks! Bryan From darrick.harter at gmail.com Fri Apr 30 19:09:04 2010 From: darrick.harter at gmail.com (Darrick Harter) Date: Fri, 30 Apr 2010 12:09:04 -0500 Subject: [rsyslog] Striping off part of a hostname in a template file Message-ID: I am trying to strip out parts of a hostname for logs that come in from my firewalls. So with each firewall that I have, I effectively have a pair, and "a" and a "b" firewall. For this example, I will call them firewalla and firewallb. Is there a way to strip the 'a' or 'b' off the filename that it's being written to dynamically? I have done this as an example, and it works as I expect it to: $template DYNfirewalllog,"/path/to/logs/firewall/%$YEAR%%$MONTH%%$DAY%-iptables.log" if \ $source == 'firewalla' \ or \ $source == 'firewallb' \ and \ $msg contains 'IN=' \ then ?DYNfirewalllog I have tried doing things similar to this, that effectively don't match at all, the regex works fine on the online checker, but I get a directory created called "**NO MATCH**" when I try to use this in practice. $template DYNfirewall,"/path/to/logs/%hostname:R,ERE,0,DFLT:.\\s[a-z].*[fw|ids]0[0-9]--end%/%$YEAR%%$MONTH%%$DAY%-iptables.log" if \ $msg contains 'IN=' \ then ?DYNfirewall If I only had a few firewalls, then this wouldn't be a big deal, I could simply add a new entry for each firewall pair. However, I currently am managing 180 firewalls... or 90 pairs, and we are still growing, so I'm looking for something a bit more dynamic if you will when it comes to managing it. Any ideas would be greatly appreciated!