From glaw at thebook.com Tue Jul 1 10:26:36 2003 From: glaw at thebook.com (George Law) Date: Thu Oct 6 10:34:52 2005 Subject: [xinetd] per_source on redhat 7.2 In-Reply-To: <20030630234538.44850.qmail@web9602.mail.yahoo.com> References: <16128.15077.196261.849894@hammer.thebook.com> <20030630234538.44850.qmail@web9602.mail.yahoo.com> Message-ID: <16129.50252.489957.901322@hammer.thebook.com> Steve G writes: > >I have per_source = 5 in both /etc/xinetd.conf and > >/etc/xinetd.d/wu-ftp, however it doesn't seem to make a > bit > >of difference. > > The error message you are seeing comes from the cps > handler. cps was set low in the past and you may want to > bump it up. How many concurrent users do you allow? For > example, if you allow 10 concurrent users with 5 sessions > each, you could theoretically have 50 legitimate > connections per second. > > The cps directive is processed before the per_source and > they are processed together. If either trigger, the > connection is rejected. > Steve, I upped the cps to 125 because it was pretty low. However, it still doesn't make a bit of difference. If per_source was working, why is there 26 simultaneous connections from the same IP address? Jul 1 13:14:26 XXX ftpd[27035]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:26 XXX ftpd[27038]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:26 XXX ftpd[27039]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:26 XXX ftpd[27037]: FTP LOGIN FAILED (cannot set guest privileges) for 217.187.4.126 [217.187.4.126], ftp Jul 1 13:14:27 XXX ftpd[27040]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:27 XXX ftpd[27043]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:27 XXX ftpd[27042]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:27 XXX ftpd[27041]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:28 XXX ftpd[27036]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:29 XXX ftpd[27046]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:29 XXX ftpd[27045]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:29 XXX ftpd[27047]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:29 XXX ftpd[27048]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:29 XXX ftpd[27044]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:30 XXX ftpd[27052]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:30 XXX ftpd[27053]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:30 XXX ftpd[27057]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:31 XXX ftpd[27054]: anonymous(Ugpuser@home.com) of 217.187.4.126 [217.187.4.126] tried to create directory /pub/users/yyy/ftp/pub/030701191607p Jul 1 13:14:31 XXX ftpd[27058]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:31 XXX ftpd[27059]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:31 XXX ftpd[27061]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:31 XXX ftpd[27060]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:32 XXX ftpd[27054]: anonymous(Ugpuser@home.com) of 217.187.4.126 [217.187.4.126] tried to create directory /pub/users/yyy/ftp/incoming/030701191608p Jul 1 13:14:32 XXX ftpd[27081]: FTP LOGIN REFUSED (anonymous ftp denied on default server) FROM 217.187.4.126 [217.187.4.126], anonymous Jul 1 13:14:32 XXX ftpd[27054]: anonymous(Ugpuser@home.com) of 217.187.4.126 [217.187.4.126] tried to create directory /pub/users/yyy/ftp/030701191609p Jul 1 13:14:33 XXX ftpd[27082]: anonymous(Wgpuser@home.com) of 217.187.4.126 [217.187.4.126] tried to create directory /pub/users/zzzz/ftp/pub/030701191610p -- Cordially, George Law ____________________________________________________________________ Systems Engineer Software Workshop Inc. glaw@thebook.com 315.635-1968 (x-213) "software that fits!" (TM) From linux_4ever at yahoo.com Tue Jul 1 11:14:20 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:52 2005 Subject: [xinetd] per_source on redhat 7.2 In-Reply-To: <16129.50252.489957.901322@hammer.thebook.com> Message-ID: <20030701181420.80699.qmail@web9605.mail.yahoo.com> >If per_source was working, why is there 26 simultaneous >connections from the same IP address? It looks like they were refused, not granted access. I just tested it on my setup and it rejects connections fine. The again, I run the latest cvs copy, too. I don't know of any bug fixes that may affect per_source. My test was to setup echo service with per_source = 2, I opened 3 connections. Third one was blocked. I ended one connection tried same connection it works. -Steve Grubb __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From glaw at thebook.com Wed Jul 2 07:34:23 2003 From: glaw at thebook.com (George Law) Date: Thu Oct 6 10:34:52 2005 Subject: [xinetd] per_source on redhat 7.2 In-Reply-To: <20030701181420.80699.qmail@web9605.mail.yahoo.com> References: <16129.50252.489957.901322@hammer.thebook.com> <20030701181420.80699.qmail@web9605.mail.yahoo.com> Message-ID: <16130.60783.210815.929296@hammer.thebook.com> Steve G writes: > >If per_source was working, why is there 26 simultaneous > >connections from the same IP address? > > It looks like they were refused, not granted access. I just > tested it on my setup and it rejects connections fine. The > again, I run the latest cvs copy, too. I don't know of any > bug fixes that may affect per_source. > > My test was to setup echo service with per_source = 2, I > opened 3 connections. Third one was blocked. I ended one > connection tried same connection it works. Steve, Is it possible that xinetd is getting hit by so many connections at the same time that it lets through more than the per_source value? I enabled some additional xinetd logging (authpriv.info in syslog.conf) and set per_source to 5. In wu-ftp's ftpaccess I also have the host-limit set to 5. Although I see several instances of per_source being logged, I also see several instances of wu-ftp complaining about the host-limit being exceeded - ie - xinetd has let more than 5 connections through from the IP but wu-ftp refuses to take them. I realize these connections are being blocked in the long run, but thought that per_source should keep them from getting to wu-ftp all together. -- Cordially, George Law ____________________________________________________________________ Systems Engineer Software Workshop Inc. glaw@thebook.com 315.635-1968 (x-213) "software that fits!" (TM) Jul 2 05:49:46 xxx ftpd[9740]: FTP LOGIN REFUSED (access denied) FROM 195.116.90.66 [195.116.90.66], anonymous Jul 2 05:49:47 xxx ftpd[9742]: ACCESS DENIED (host limit 5; class remote) TO 195.116.90.66 [195.116.90.66] Jul 2 05:49:47 xxx ftpd[9742]: FTP LOGIN REFUSED (access denied) FROM 195.116.90.66 [195.116.90.66], anonymous Jul 2 05:49:50 xxx ftpd[9743]: ACCESS DENIED (host limit 5; class remote) TO 195.116.90.66 [195.116.90.66] Jul 2 05:49:50 xxx ftpd[9743]: FTP LOGIN REFUSED (access denied) FROM 195.116.90.66 [195.116.90.66], anonymous Jul 2 05:49:50 xxx ftpd[9744]: ACCESS DENIED (host limit 5; class remote) TO 195.116.90.66 [195.116.90.66] Jul 2 05:49:50 xxx ftpd[9744]: FTP LOGIN REFUSED (access denied) FROM 195.116.90.66 [195.116.90.66], anonymous Jul 2 05:41:34 xxx xinetd[8118]: FAIL: ftp per_source_limit from=195.116.90.66 Jul 2 05:43:38 xxx xinetd[8118]: FAIL: ftp per_source_limit from=195.116.90.66 Jul 2 05:50:19 xxx xinetd[8118]: FAIL: ftp per_source_limit from=195.116.90.66 From linux_4ever at yahoo.com Wed Jul 2 08:31:28 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:52 2005 Subject: [xinetd] per_source on redhat 7.2 In-Reply-To: <16130.60783.210815.929296@hammer.thebook.com> Message-ID: <20030702153128.17809.qmail@web9603.mail.yahoo.com> >Is it possible that xinetd is getting hit by so many >connections at the same time that it lets through more >than the per_source value? Not likely. The code is very well serialized. This check is done pre-fork. The xinetd daemon walks its table of child processes and counts them. It counts them on a per-service basis...meaning each unique service entry in xinetd rather than all of ftp. If you have 4 IP addresses and each has its own unique xinetd service entry with their own only_from, then xinetd will only count concurrent connections for a specific service entry...not all 4. The sigchld handler only sets a flag that a child exitted and does nothing else. There is next to no chance of a child getting away from us. There has also been several bug fixes put into cvs that corrects xinetd reloading. If you send xinetd SIGHUP to re-read its configuration, it doesn't always work correctly. Curent cvs works much much better. (I was hoping 2.3.12 would be released by now so those problems go away.) The work around is to completely stop xinetd and then start it. I don't know if that is causing your problems. Try testing on a smaller scale in a controlled environment and I think you should see that it works fine. BTW, what happens when you start 6 sessions to the same IP-address on your ftp server? Do you get rejected on the 6th connection? Does 5 of them succeed? -Steve Grubb __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From glaw at thebook.com Wed Jul 2 12:02:47 2003 From: glaw at thebook.com (George Law) Date: Thu Oct 6 10:34:52 2005 Subject: [xinetd] per_source on redhat 7.2 In-Reply-To: <20030702153128.17809.qmail@web9603.mail.yahoo.com> References: <16130.60783.210815.929296@hammer.thebook.com> <20030702153128.17809.qmail@web9603.mail.yahoo.com> Message-ID: <16131.11351.615531.174941@hammer.thebook.com> Sorry - sent this one right to steve grubb by mistake. Steve G writes: > There has also been several bug fixes put into cvs that > corrects xinetd reloading. If you send xinetd SIGHUP to > re-read its configuration, it doesn't always work > correctly. Curent cvs works much much better. (I was hoping > 2.3.12 would be released by now so those problems go away.) > The work around is to completely stop xinetd and then start > it. I don't know if that is causing your problems. > I used /etc/init.d/xientd to restart - this does a full stop then start, so I don't think this applies. > Try testing on a smaller scale in a controlled environment > and I think you should see that it works fine. BTW, what > happens when you start 6 sessions to the same IP-address on > your ftp server? Do you get rejected on the 6th connection? > Does 5 of them succeed? > "to the same IP-address" is the magic phrase. We are a web hosting company. Our servers are multi-homed - each has a couple hundred IP addresses and we use wu-ftp's virtual ftp option to provide clients their own anonymous FTP bound to their IP address. I wrote a little perl script which makes 200 calls to Net::FTP to open a ftp connection (to the same ip). Connections 6-200 are refused as expected. I just grabbed the current CVS and see in the CHANGELOG: Make ident protocol work properly for multi-homed hosts. -Alan Sundell After reading the change log the bells and whistles started going off. I updated the script (new version below) to connect to 200 DIFFERENT IP addresses. This time, it hits connection 60 before it starts to fail. I compiled the CVS version, stopped xinetd, installed the new xinetd executable and started it up /etc/init.d/xinetd start but still get the same problem. Is this a bug or a feature? :) -- Cordially, George Law ____________________________________________________________________ Systems Engineer Software Workshop Inc. glaw@thebook.com 315.635-1968 (x-213) "software that fits!" (TM) #!/usr/bin/perl use Net::FTP; if (@ARGV == 1) { $baseIP= $ARGV[0]; } else { print qq(Usage: scanFTP baseIP (xx.xx.xx.)\n); exit (1); } for ($i = 1; $i < 200; $i++) { $thisIP = $baseIP . $i; print qq(connecting to host $thisIP ... ); if ($ftp[$i] = Net::FTP->new("$thisIP", Debug => 9)) { print qq(OK\n); $ftp[$i]->login("anonymous",'-anonymous@'); $ftp[$i]->ls("/download"); } else { print qq(Failed! \n); } } From it.andrew.mccall at oldham.gov.uk Mon Jul 7 02:27:50 2003 From: it.andrew.mccall at oldham.gov.uk (Andrew McCall) Date: Thu Oct 6 10:34:52 2005 Subject: [xinetd] Interface += question. Message-ID: <1057570070.17398.18.camel@pc2962.oldham.gov.uk> Hi Folks! Can someone please tell me if I am using xinetd.conf wrong :) My server has three IP addresses, 192.168.10.14, 15 and 16. I have a need for a standalone instance of ProFTPD with no xinetd on 14, and I want to use vsFTPd via xinetd on 15 and 16. I have ProFTPD working find as a standalone server on 192.168.10.14, and I can have vsFTPd working OK at the same tin on 192.168.10.15 using this xinetd.conf entry: service ftp { socket_type = stream protocol = tcp interface = 192.168.10.15 wait = no user = root server = /usr/sbin/vsftpd } I thought I would be able to add the additional interface quite simply by adding interface += 192.168.10.16 to the entry so it looks like this: service ftp { socket_type = stream protocol = tcp interface = 192.168.10.15 interface += 192.168.10.16 wait = no user = root server = /usr/sbin/vsftpd } But when I restart it gives me this error in /var/log/messages : Jul 7 06:22:37 server1 xinetd[17290]: Service ftp: attribute already set: interface [line=81] Can anyone tell me if xinetd supports this? Am I doing something wrong? Will I have to alter the code to do this? Thanks, -- Andrew McCall Oldham Metropolitan Borough Council ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.oldham.gov.uk ********************************************************************** From it.andrew.mccall at oldham.gov.uk Mon Jul 7 03:29:00 2003 From: it.andrew.mccall at oldham.gov.uk (Andrew McCall) Date: Thu Oct 6 10:34:52 2005 Subject: [xinetd] Interface += question. In-Reply-To: <1057570070.17398.18.camel@pc2962.oldham.gov.uk> References: <1057570070.17398.18.camel@pc2962.oldham.gov.uk> Message-ID: <1057573740.17398.33.camel@pc2962.oldham.gov.uk> On Mon, 2003-07-07 at 10:27, Andrew McCall wrote: > Hi Folks! Hi Again, It seems that a little more research in Google Groups finally answered my question. I thought I would reply to myself to save other people the trouble, and to get the solution down in the archives. > Can someone please tell me if I am using xinetd.conf wrong :) Yes I am, to have a service binded to some, but not all IP addresses on the system you need to redefine the service giving it a unique "id" and specifically binding it to a different IP address each time. This could be messy if you have 100 IP addresses, and only want to bind to the even ones.... > My server has three IP addresses, 192.168.10.14, 15 and 16. I have a > need for a standalone instance of ProFTPD with no xinetd on 14, and I > want to use vsFTPd via xinetd on 15 and 16. > Can anyone tell me if xinetd supports this? Am I doing something > wrong? Will I have to alter the code to do this? The reason this won't work is because of a socket interface limitation (not only xinetd) you can bind a service to *any* or *one* address only. It could be built into xinetd so it knows that on each interface += to redefine the service with a unique id, I don't know what the implications of this are, but without too much thought it seems like a valid thing to do. To get the scenario working as described above, you need to use these options: service ftp { id = ftp1 socket_type = stream protocol = tcp interface = 192.168.10.15 wait = no user = root server = /usr/sbin/vsftpd } service ftp { id = ftp2 socket_type = stream protocol = tcp interface = 192.168.10.16 wait = no user = root server = /usr/sbin/vsftpd } Hope that helps people in the future. Thanks, -- Andrew McCall Oldham Metropolitan Borough Council ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.oldham.gov.uk ********************************************************************** From linux_4ever at yahoo.com Mon Jul 7 05:23:13 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Interface += question. In-Reply-To: <1057573740.17398.33.camel@pc2962.oldham.gov.uk> Message-ID: <20030707122313.287.qmail@web9604.mail.yahoo.com> Hello, Yes, doing each service seperately is what I do on my machine and it works nicely. Rob and I have traded e-mails about changing bind into a net address attribute like only_from or no_access. But this is alot of work and we've had worse bugs to fix instead of adding features. It is a logical thing to do and one of these days we might get there. For now, each server has to be separated. -Steve Grubb __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From ckong at netvigator.com Mon Jul 7 10:24:48 2003 From: ckong at netvigator.com (Douglas Kong) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Solaris 7 and xinetd 2.3.11 Message-ID: <3F09ACE0.61F6173D@netvigator.com> Hi, I get the following error when i try to make the xinetd 2.3.11. I am running Solaris 7 on SPARC, using gcc 2.95, either gnu make or Solaris make, both return the same error. It seems Solaris 7 does not support IPv6, and the make is somehow calling the AF_INET6. axi:/home/douglas/src/xinetd-2.3.11# make cd libs/src/portable ; make CC=gcc CFLAGS='-g -O2 -I../../include' install make[1]: Entering directory `/home/douglas/src/xinetd-2.3.11/libs/src/portable' gcc -g -O2 -I../../include -c -o inet_ntop.o inet_ntop.c In file included from inet_ntop.c:33: /usr/include/sys/socket.h:56: warning: empty declaration inet_ntop.c:56: parse error before `__P' inet_ntop.c:57: parse error before `__P' inet_ntop.c: In function `inet_ntop': inet_ntop.c:76: warning: return makes pointer from integer without a cast inet_ntop.c:77: `AF_INET6' undeclared (first use in this function) inet_ntop.c:77: (Each undeclared identifier is reported only once inet_ntop.c:77: for each function it appears in.) inet_ntop.c:78: warning: return makes pointer from integer without a cast inet_ntop.c: At top level: inet_ntop.c:99: warning: `inet_ntop4' was declared implicitly `extern' and later `static' inet_ntop.c:76: warning: previous declaration of `inet_ntop4' inet_ntop.c:99: warning: type mismatch with previous implicit declaration inet_ntop.c:76: warning: previous implicit declaration of `inet_ntop4' inet_ntop.c:99: warning: `inet_ntop4' was previously implicitly declared to return `int' inet_ntop.c:122: warning: `inet_ntop6' was declared implicitly `extern' and later `static' inet_ntop.c:78: warning: previous declaration of `inet_ntop6' inet_ntop.c:122: warning: type mismatch with previous implicit declaration inet_ntop.c:78: warning: previous implicit declaration of `inet_ntop6' inet_ntop.c:122: warning: `inet_ntop6' was previously implicitly declared to return `int' make[1]: *** [inet_ntop.o] Error 1 make[1]: Leaving directory `/home/douglas/src/xinetd-2.3.11/libs/src/portable' make: *** [libportable] Error 2 Can anyone help? Thanks. Best Regards, Douglas Kong From linux_4ever at yahoo.com Mon Jul 7 10:50:47 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Solaris 7 and xinetd 2.3.11 In-Reply-To: <3F09ACE0.61F6173D@netvigator.com> Message-ID: <20030707175047.37579.qmail@web9601.mail.yahoo.com> Hello, I was planning to work on portability problems after 2.3.12 is released. So, I have no idea how many problems yoou will ultimately run into. To start with Remove the __P( ) from lines 56 & 57. static const char *inet_ntop4 (const u_char *src, char *dst, size_t size); static const char *inet_ntop6 (const u_char *src, char *dst, size_t size); add ifdefs around 77 & 78: #ifdef AF_INET6 case AF_INET6: return (inet_ntop6(src, dst, size)); #endif and the same ifdef around the whole inet_ntop6 function. -Steve Grubb __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From glaw at thebook.com Mon Jul 7 11:41:05 2003 From: glaw at thebook.com (George Law) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] per_source on redhat 7.2 In-Reply-To: <20030701181420.80699.qmail@web9605.mail.yahoo.com> References: <16129.50252.489957.901322@hammer.thebook.com> <20030701181420.80699.qmail@web9605.mail.yahoo.com> Message-ID: <16137.48833.142872.835168@hammer.thebook.com> hello, In my last email, I think I pinpointed that the problems I was seeing with the per_source option were related to the server being multi-homed. The server in question has several hundred IP addresses bound to it. We are a web hosting company and assign 1 IP per website and they can also set up FTP bound to the same IP address. Does the per_source option not apply for multi-homed machines or is it in the works? -- Cordially, George Law ____________________________________________________________________ Systems Engineer Software Workshop Inc. glaw@thebook.com 315.635-1968 (x-213) "software that fits!" (TM) From linux_4ever at yahoo.com Mon Jul 7 12:37:53 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] per_source on redhat 7.2 In-Reply-To: <16137.48833.142872.835168@hammer.thebook.com> Message-ID: <20030707193753.35128.qmail@web9607.mail.yahoo.com> >Does the per_source option not apply for multi-homed >machines or is it in the works? It applies the same. The per_source option uses the connections remote address and the service entry in it comparison. It does not look at the server's address for the per_source option. The source code lines in question are xinetd/access.c 317 if ( (SERVER_SERVICE( serp ) == sp) && ( cop = SERVER_CONNECTION( serp ) ) ) { sp is the server being executed, serp is the server in the list & cop is its connection. So it reads, if the current server is our server and its connections isn't null line 324 if ( SC_IPV4( scp ) && (cop->co_remote_address.sa_in.sin_addr.s_addr == (CONN_XADDRESS(cp))->sa_in.sin_addr.s_addr) ) n++; cp is the currently executing server's connection, scp is the currently executing servers configuration pointer. It reads if the current server is configured as IPv4 and address of the remote connection of the server found in the server list is the same as the current servers remote connection address, increment n. and line 336 if ( n >= scp->sc_per_source ) return( AC_PER_SOURCE_LIMIT ) ; You can do a kill -USR1 pid_of_xinetd to dump the internal state of xinetd to /var/run/xinetd.dump. That file should give you the value for per_source. You might want to see what its using. Also, you can add some msg() statements to collect more data if you are inclined to programming. I have my server setup the same way you describe. One ftp for each website. I let them have 2 connections each. The server I use has 12 ip address. So its a smaller version of your setup. So far I have not been able to duplicate the problem. -Steve Grubb __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From glaw at thebook.com Mon Jul 7 13:52:32 2003 From: glaw at thebook.com (George Law) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] per_source on redhat 7.2 In-Reply-To: <16137.48833.142872.835168@hammer.thebook.com> References: <16129.50252.489957.901322@hammer.thebook.com> <20030701181420.80699.qmail@web9605.mail.yahoo.com> <16137.48833.142872.835168@hammer.thebook.com> Message-ID: <16137.56720.615914.197203@hammer.thebook.com> George Law writes: > hello, > > In my last email, I think I pinpointed that the problems I was seeing > with the per_source option were related to the server being > multi-homed. > > The server in question has several hundred IP addresses bound to it. > We are a web hosting company and assign 1 IP per website and they can > also set up FTP bound to the same IP address. > > Does the per_source option not apply for multi-homed machines or is it > in the works? Thanks to Steve, I found a small problem in my testing logic - I was testing from the same multi-homed machine, so when the outgoing FTP connections were established, it grabbed a different IP each time, so there wasn't a problem with per_source after all. I ran the same test script from a different machine with only 1 IP address and it works fine. -- Cordially, George Law ____________________________________________________________________ Systems Engineer Software Workshop Inc. glaw@thebook.com 315.635-1968 (x-213) "software that fits!" (TM) From ben at roadrunner.uk.com Tue Jul 8 01:58:28 2003 From: ben at roadrunner.uk.com (Ben Clewett) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Simple question In-Reply-To: <16137.56720.615914.197203@hammer.thebook.com> References: <16129.50252.489957.901322@hammer.thebook.com> <20030701181420.80699.qmail@web9605.mail.yahoo.com> <16137.48833.142872.835168@hammer.thebook.com> <16137.56720.615914.197203@hammer.thebook.com> Message-ID: <3F0A87B4.8090505@roadrunner.uk.com> Xinetd, A couple of weeks ago you kindly showed me how to increase the quality of an xinetd app by communicating using read(0) and write(1), instead of fread(stdin) and fwrite(stdout). I'm having problems with API's leeking debug and error messages to stdout and stderr, which get passed down the socket. If there a way of closing stdout and stderr without closing the socket for read(0) and write(1)? I've tried the obvious fclose(stdout) but this closed the socket as well... Or alternativelly, redefine the stdout FILE to point to /dev/null or something :) Regards and thanks again, Ben From linux_4ever at yahoo.com Tue Jul 8 05:51:37 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Simple question In-Reply-To: <3F0A87B4.8090505@roadrunner.uk.com> Message-ID: <20030708125137.95227.qmail@web9602.mail.yahoo.com> Hello, int new_fd = open("/dev/null", 0); dup2(stdout, new_fd); dup2(stderr, new_fd); close(new_fd); -Steve Grubb __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From ben at roadrunner.uk.com Tue Jul 8 07:37:08 2003 From: ben at roadrunner.uk.com (Ben Clewett) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Simple question In-Reply-To: <20030708125137.95227.qmail@web9602.mail.yahoo.com> References: <20030708125137.95227.qmail@web9602.mail.yahoo.com> Message-ID: <3F0AD714.6070202@roadrunner.uk.com> THANKS!! Ben Steve G wrote: > Hello, > > > int new_fd = open("/dev/null", 0); > dup2(stdout, new_fd); > dup2(stderr, new_fd); > close(new_fd); > > > -Steve Grubb > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > _______________________________________________ > xinetd mailing list > xinetd@xinetd.org > http://www.xinetd.org/mailman/listinfo/xinetd > From glaw at thebook.com Tue Jul 8 12:19:22 2003 From: glaw at thebook.com (George Law) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] syslog In-Reply-To: <16137.56720.615914.197203@hammer.thebook.com> References: <16129.50252.489957.901322@hammer.thebook.com> <20030701181420.80699.qmail@web9605.mail.yahoo.com> <16137.48833.142872.835168@hammer.thebook.com> <16137.56720.615914.197203@hammer.thebook.com> Message-ID: <16139.6458.122692.145848@hammer.thebook.com> Now that I have per_source working correctly (thanks Steve!), I wanted to try to come up with a way to block IPs that continously hammer on the per_source limit (like the guy below from 166.114.250.149). Right now, I am using logsurfer to peek at /var/log/messages and certain regex will trigger a script which will process the probe based on a keyword. ie - when I see someone try to login as root, I block their IP address immediately using IP tables. Another example of this is when wu-ftpd logs : Jul 8 11:10:05 XXX ftpd[332]: anonymous(Sgpuser@home.com) of 81.56.198.138 [81.56.198.138] tried to create directory /pub/users/xyz/ftp/030708170909p This is a scan to find ftp sites which will allow anonymous mkdirs. When logsurfer sees this, it pulls out the IP address and blocks it with iptables. I see that you can control the syslog facility and priority in the xinetd.conf file. The default authpriv.info logs every START and EXIT, plus any errors. Is there a way to control the priority of the xinetd messages, ie to make the priority of the START and EXIT messages "info" and the priority of the FAIL lines "warning". This would allow me to just send authpriv.warning to /var/log/messages. I think this needs to go into the libs/include/xlog.h file, but my C programming is rusty! :) -- Cordially, George Law ____________________________________________________________________ Systems Engineer Software Workshop Inc. glaw@thebook.com 315.635-1968 (x-213) "software that fits!" (TM) Jul 8 14:20:00 XXX xinetd[1030]: START: ftp pid=25149 from=166.114.250.149 Jul 8 14:20:00 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:00 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:00 XXX xinetd[1030]: START: ftp pid=25150 from=166.114.250.149 Jul 8 14:20:00 XXX xinetd[1030]: START: ftp pid=25151 from=166.114.250.149 Jul 8 14:20:00 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:01 XXX xinetd[1030]: START: ftp pid=25168 from=166.114.250.149 Jul 8 14:20:01 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:01 XXX xinetd[1030]: START: ftp pid=25169 from=166.114.250.149 Jul 8 14:20:01 XXX xinetd[1030]: START: ftp pid=25170 from=166.114.250.149 Jul 8 14:20:01 XXX xinetd[1030]: START: ftp pid=25171 from=166.114.250.149 Jul 8 14:20:02 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:02 XXX xinetd[1030]: START: ftp pid=25174 from=166.114.250.149 Jul 8 14:20:02 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:02 XXX xinetd[1030]: START: ftp pid=25175 from=166.114.250.149 Jul 8 14:20:02 XXX xinetd[1030]: START: ftp pid=25176 from=166.114.250.149 Jul 8 14:20:02 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:02 XXX xinetd[1030]: START: ftp pid=25177 from=166.114.250.149 Jul 8 14:20:02 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:02 XXX xinetd[1030]: START: ftp pid=25180 from=166.114.250.149 Jul 8 14:20:03 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:03 XXX xinetd[1030]: START: ftp pid=25185 from=166.114.250.149 Jul 8 14:20:03 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:03 XXX xinetd[1030]: START: ftp pid=25189 from=166.114.250.149 Jul 8 14:20:03 XXX xinetd[1030]: START: ftp pid=25192 from=166.114.250.149 Jul 8 14:20:03 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:03 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:04 XXX xinetd[1030]: START: ftp pid=25196 from=166.114.250.149 Jul 8 14:20:05 XXX xinetd[1030]: START: ftp pid=25197 from=166.114.250.149 Jul 8 14:20:05 XXX xinetd[1030]: START: ftp pid=25198 from=166.114.250.149 Jul 8 14:20:05 XXX xinetd[1030]: START: ftp pid=25199 from=166.114.250.149 Jul 8 14:20:05 XXX xinetd[1030]: START: ftp pid=25200 from=166.114.250.149 Jul 8 14:20:05 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:06 XXX xinetd[1030]: START: ftp pid=25201 from=166.114.250.149 Jul 8 14:20:06 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:06 XXX xinetd[1030]: START: ftp pid=25202 from=166.114.250.149 Jul 8 14:20:07 XXX xinetd[1030]: START: ftp pid=25208 from=166.114.250.149 Jul 8 14:20:07 XXX xinetd[1030]: START: ftp pid=25209 from=166.114.250.149 Jul 8 14:20:07 XXX xinetd[1030]: START: ftp pid=25211 from=166.114.250.149 Jul 8 14:20:07 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:07 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:08 XXX xinetd[1030]: START: ftp pid=25213 from=166.114.250.149 Jul 8 14:20:08 XXX xinetd[1030]: START: ftp pid=25214 from=166.114.250.149 Jul 8 14:20:08 XXX xinetd[1030]: START: ftp pid=25224 from=166.114.250.149 Jul 8 14:20:09 XXX xinetd[1030]: START: ftp pid=25225 from=166.114.250.149 Jul 8 14:20:09 XXX xinetd[1030]: START: ftp pid=25226 from=166.114.250.149 Jul 8 14:20:09 XXX xinetd[1030]: START: ftp pid=25227 from=166.114.250.149 Jul 8 14:20:09 XXX xinetd[1030]: START: ftp pid=25228 from=166.114.250.149 Jul 8 14:20:17 XXX xinetd[1030]: START: ftp pid=25254 from=166.114.250.149 Jul 8 14:20:17 XXX xinetd[1030]: START: ftp pid=25255 from=166.114.250.149 Jul 8 14:20:17 XXX xinetd[1030]: START: ftp pid=25256 from=166.114.250.149 Jul 8 14:20:18 XXX xinetd[1030]: START: ftp pid=25257 from=166.114.250.149 Jul 8 14:20:18 XXX xinetd[1030]: START: ftp pid=25258 from=166.114.250.149 Jul 8 14:20:18 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:19 XXX xinetd[1030]: START: ftp pid=25260 from=166.114.250.149 Jul 8 14:20:19 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:20 XXX xinetd[1030]: START: ftp pid=25264 from=166.114.250.149 Jul 8 14:20:20 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:21 XXX xinetd[1030]: START: ftp pid=25265 from=166.114.250.149 Jul 8 14:20:22 XXX xinetd[1030]: START: ftp pid=25268 from=166.114.250.149 Jul 8 14:20:22 XXX xinetd[1030]: START: ftp pid=25269 from=166.114.250.149 Jul 8 14:20:22 XXX xinetd[1030]: START: ftp pid=25270 from=166.114.250.149 Jul 8 14:20:22 XXX xinetd[1030]: START: ftp pid=25271 from=166.114.250.149 Jul 8 14:20:22 XXX xinetd[1030]: FAIL: ftp per_source_limit from=166.114.250.149 Jul 8 14:20:27 XXX xinetd[1030]: START: ftp pid=25273 from=166.114.250.149 From linux_4ever at yahoo.com Tue Jul 8 19:47:03 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] syslog In-Reply-To: <16139.6458.122692.145848@hammer.thebook.com> Message-ID: <20030709024703.54122.qmail@web9608.mail.yahoo.com> >Is there a way to control the priority of the xinetd >messages, ie to make the priority of the START and EXIT >messages "info" and the priority of the FAIL lines "warning". According to man xinetd.conf there is no distinction between the start and fail messages in terms of priority. As far as xinetd is concerned its just logging the fact that they occurred. It can set the priority to warning, but that would be for both kinds of messages, and probably others, too. I'm sure its possible to filter the messages better in post-processing software. There's a number of different logwatching tools that have different capabilities. There are other versions of syslog, too, that may be able to filter messages. I would be reluctant to change in xinetd to make the priorities different for pass & fail messages. It should be possible to sort them out as is. Logrotate and awk may be enough to do it. -Steve Grubb __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From linux_4ever at yahoo.com Sat Jul 12 15:19:30 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] fork() flood in tcp/wait service again In-Reply-To: <3EFBEDEE.D26628BD@co.ru> Message-ID: <20030712221930.50838.qmail@web9605.mail.yahoo.com> Hello, I have thought long and hard about the tcp/wait DOS. I have a patch that I would like people to try out before I commit it to cvs. Basically what it does is create a drain_tcp function. It is called from the service_postmortum and it calls accept in a non-blocking mode just one time. The pros: it will stop DOS conditions, it doesn't lose all connections in the queue if more requests are queued. The cons: It might lose 1 legitimate request for perfectly functioning tcp/wait services. (tcp/nowait services are unaffected by the patch.) Improvements: Add a service flags option that enables this call so that only admins that have a known bad program can have the tcp/wait socket drained. Everyone with well behaving tcp/wait applications won't lose the 1 connection that gets drained. So, all interested parties please give this a try and let's see if we can finalize a solution. -Steve Grubb __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: tcp_wait.patch Type: application/octet-stream Size: 1899 bytes Desc: tcp_wait.patch Url : http://www.xinetd.org/pipermail/xinetd/attachments/20030712/566cfda4/tcp_wait.obj From dp at co.ru Mon Jul 14 04:56:48 2003 From: dp at co.ru (Dmitry Perfilyev) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] fork() flood in tcp/wait service again References: <20030712221930.50838.qmail@web9605.mail.yahoo.com> Message-ID: <3F129A80.79C18CF7@co.ru> Hi! Present situation (cps workaround) is much better IMHO. With this patch we ALWAYS have a problem with single lost connection, and with "cps workaround" - only on a slow, or loaded system(supposedly). Unfortunately I cann't test it on my production servers. > The cons: It might lose 1 legitimate request for perfectly > functioning tcp/wait services. (tcp/nowait services are > unaffected by the patch.) -- Dmitry Perfilyev From linux_4ever at yahoo.com Mon Jul 14 05:19:10 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] fork() flood in tcp/wait service again In-Reply-To: <3F129A80.79C18CF7@co.ru> Message-ID: <20030714121910.50427.qmail@web9607.mail.yahoo.com> >Present situation (cps workaround) is much better IMHO. What is the cps workaround? cps when violated calls svc_deactivate which calls deactivate. That function calls close which empties ALL pending connections instead of one. -Steve Grubb __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From dp at co.ru Mon Jul 14 06:00:11 2003 From: dp at co.ru (Dmitry Perfilyev) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] fork() flood in tcp/wait service again References: <20030714121910.50427.qmail@web9607.mail.yahoo.com> Message-ID: <3F12A95B.72FEAF57@co.ru> Yes, and it is more correctly, because if cps limit reached, then something ugly happened with this service. What practical use of this patch ? If service cann't start for this connection, then chances are it failed and for next (another unnecessary fork/exec). Service must be deactivated for a while. With this patch fork/exec will be repeated on every incoming connection. So we must set cps limit again. Steve G wrote: > > >Present situation (cps workaround) is much better IMHO. > > What is the cps workaround? > > cps when violated calls svc_deactivate which calls > deactivate. That function calls close which empties ALL > pending connections instead of one. > > -Steve Grubb -- Dmitry Perfilyev From linux_4ever at yahoo.com Mon Jul 14 06:35:53 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] fork() flood in tcp/wait service again In-Reply-To: <3F12A95B.72FEAF57@co.ru> Message-ID: <20030714133553.90329.qmail@web9604.mail.yahoo.com> >Yes, and it is more correctly, because if cps >limit reached, then something ugly happened with >this service. OK, then I guess with the limitations of TCP/IP, relying on the cps workaround is the solution. I'll consider the problem solved. Thanks, -Steve Grubb __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From dp at co.ru Mon Jul 14 07:09:38 2003 From: dp at co.ru (Dmitry Perfilyev) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] fork() flood in tcp/wait service again References: <20030714133553.90329.qmail@web9604.mail.yahoo.com> Message-ID: <3F12B9A2.1DA994A4@co.ru> Yes, it is not very "clean", but worked. > OK, then I guess with the limitations of TCP/IP, relying on > the cps workaround is the solution. I'll consider the > problem solved. -- Dmitry Perfilyev JSC Combellga www.co.ru From david at arabidopsis.info Thu Jul 17 02:17:32 2003 From: david at arabidopsis.info (David J Craigon) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Choosing services without using bind Message-ID: <3F1669AC.9040308@arabidopsis.info> This may be an FAQ- sorry. I'm looking to do a situation like the one listed in the sample config web pages for telnet: service telnet { flags = REUSE socket_type = stream wait = no user = root redirect = 192.168.1.1 23 bind = 127.0.0.1 log_on_failure += USERID } service telnet { flags = REUSE socket_type = stream wait = no user = root server = /usr/sbin/in.telnetd bind = 192.168.1.11 log_on_failure += USERID } only I want to use 1 IP address for my server, and choose which service based on the IP address of the connecting machine. i.e. one block of source IP addresses will get this service, another will get that service. Can this be done? David From linux_4ever at yahoo.com Thu Jul 17 05:16:24 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Choosing services without using bind In-Reply-To: <3F1669AC.9040308@arabidopsis.info> Message-ID: <20030717121624.99026.qmail@web9608.mail.yahoo.com> >one block of source IP addresses will get this service, >another will get that service. Can this be done? Sort of. You will have to create a service entry for each ip-address. Each one will require the "id" attribute t be set. It must be different - telnet1, telnet2, telnet3, etc. You will also have to set the bind attribute to 1 address each. I should take a look at the examples, the ones you put in the e-mails message just look bad. REUSE is on by default, so its not needed and USERID will slow eveything down and is untrustworthy unless you control all machines that access the server. One example should use it but not all of them. Hope this helps.... -Steve Grubb __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From david at arabidopsis.info Thu Jul 17 06:15:09 2003 From: david at arabidopsis.info (David J Craigon) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Choosing services without using bind In-Reply-To: <20030717121624.99026.qmail@web9608.mail.yahoo.com> References: <20030717121624.99026.qmail@web9608.mail.yahoo.com> Message-ID: <3F16A15D.2070702@arabidopsis.info> > Hope this helps.... Sort-of. So I can do something like: service telnet { id = telnet1 socket_type = stream wait = no user = root only_from = .mydomain.com server = /usr/sbin/super-telnet bind = 121.121.121.121 } service telnet { id = telnet2 socket_type = stream wait = no user = root no_access = .mydomain.com server = /usr/sbin/boring-telnet bind = 121.121.121.121 } and users inside my domain will get to use "super-telnet", but users outside my domain will get "boring-telnet"? David Steve G wrote: >>one block of source IP addresses will get this service, >>another will get that service. Can this be done? > > > Sort of. You will have to create a service entry for each > ip-address. Each one will require the "id" attribute t be > set. It must be different - telnet1, telnet2, telnet3, etc. > You will also have to set the bind attribute to 1 address > each. > > I should take a look at the examples, the ones you put in > the e-mails message just look bad. REUSE is on by default, > so its not needed and USERID will slow eveything down and > is untrustworthy unless you control all machines that > access the server. One example should use it but not all of > them. > > -Steve Grubb > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > _______________________________________________ > xinetd mailing list > xinetd@xinetd.org > http://www.xinetd.org/mailman/listinfo/xinetd From linux_4ever at yahoo.com Thu Jul 17 07:14:41 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Choosing services without using bind In-Reply-To: <3F16A15D.2070702@arabidopsis.info> Message-ID: <20030717141441.61347.qmail@web9605.mail.yahoo.com> >users inside my domain will get to use "super-telnet", >but users outside my domain will get "boring-telnet"? No. There will be an error since the address is already bound to. Only 1 address/port combination is allowed. The bind addresses or the ports must be different. If you have a multihomed host, then you can let the local interface have super telnet and the external interface have boring telnet. Or put super telnet on another port. -Steve Grubb __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From pb at imap.tdcnorge.no Fri Jul 18 13:15:07 2003 From: pb at imap.tdcnorge.no (=?ISO-8859-1?Q?P=E5l_Baltzersen?=) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Can't bind to given address Message-ID: <3F18554B.7090007@tdcnorge.no> I have: xinetd-2.3.11 SunOS relay1 5.8 Generic_108528-22 sun4u sparc SUNW,UltraSPARC-IIi-cEngine gcc version 3.3 The log sais: Jul 18 22:06:39 relay1 xinetd[3640]: [ID 385394 daemon.error] no addresses returned [line=4] Jul 18 22:06:39 relay1 xinetd[3640]: [ID 385394 daemon.error] Error parsing attribute bind - DISABLING SERVICE [line=4] Jul 18 22:06:39 relay1 xinetd[3640]: [ID 385394 daemon.error] no addresses returned [line=17] Jul 18 22:06:39 relay1 xinetd[3640]: [ID 385394 daemon.error] Error parsing attribute bind - DISABLING SERVICE [line=17] Jul 18 22:06:39 relay1 xinetd[3640]: [ID 385394 daemon.debug] removing tftp Jul 18 22:06:39 relay1 last message repeated 1 time Jul 18 22:06:39 relay1 xinetd[3640]: [ID 385394 daemon.crit] 3640 {init_services} no services. Exiting... The config is: service tftp { flags = IPv4 bind = 100.152.20.41 socket_type = dgram protocol = udp wait = yes user = root group = root server = /usr/sbin/in.tftpd server_args = -s /var/spool/tftp only_from = 127.0.0.1/32 100.152.20.0/22 100.152.40.0/22 171.23.0.0/16 } service tftp { flags = IPv4 bind = 100.152.23.41 socket_type = dgram protocol = udp wait = yes user = root group = root server = /usr/sbin/in.tftpd server_args = -s /var/spool/tftp only_from = 127.0.0.1/32 100.152.20.0/22 100.152.40.0/22 171.23.0.0/16 } Xinetd works without 'bind', but tftpd sends replies with wrong source address so I need to bind. Help apreciated. P?l. From linux_4ever at yahoo.com Fri Jul 18 13:58:14 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Can't bind to given address In-Reply-To: <3F18554B.7090007@tdcnorge.no> Message-ID: <20030718205814.13332.qmail@web9605.mail.yahoo.com> >Xinetd works without 'bind', but tftpd sends replies with >wrong source address so I need to bind. Your whole problem appears to be line 4 of the tftp service...which is the bind statement. I'd carefully look at that to see if there's a typo. O instead of 0. ',' instead of '.' Something is wrong with the address. Bind works fine for tftpd on my system. -Steve Grubb __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From pb at imap.tdcnorge.no Fri Jul 18 14:46:40 2003 From: pb at imap.tdcnorge.no (=?ISO-8859-1?Q?P=E5l_Baltzersen?=) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Can't bind to given address References: <20030718205814.13332.qmail@web9605.mail.yahoo.com> Message-ID: <3F186AC0.5060304@tdcnorge.no> Steve G wrote: >>Xinetd works without 'bind', but tftpd sends replies with >>wrong source address so I need to bind. > > > Your whole problem appears to be line 4 of the tftp > service...which is the bind statement. > > I'd carefully look at that to see if there's a typo. O > instead of 0. ',' instead of '.' Something is wrong with > the address. Bind works fine for tftpd on my system. > > -Steve Grubb Seems like the problem has to do with ISV libbind. I recompiled without the ISV bind-9.2.2 headers nor -lbind and added CFLAG -DHAVE_GETNAMEINFO=1 Now it's OK :-) From linux_4ever at yahoo.com Mon Jul 21 07:36:50 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Will 2.3.12 be released? Message-ID: <20030721143650.29962.qmail@web9601.mail.yahoo.com> Rob, I was wondering where we stand in terms of releasing the next rev of xinetd? Several distributions are lumbering towards their next release. The version of xinetd in cvs is far superior to 2.3.11 and considerably more stable. Look at the Changelog. There's a lot of fixes that I wished were available to common users. Let's look at the changelog. Starting with the entry devel and going down the list, I consider #5, #6, #8, #10, #13, #16, #17, & #19 to be serious security issues. I consider: #2, #12, & #23 to be easy DOS & core dumps. There's many memory leaks fixed and the cvs version includes the file name that caused a parsing error instead of just the line number. This alone should help new users debug service entries much quicker. I was wondering what, if anything, is holding up the next release? Do we have a release date in mind or bugs that need solving before 2.3.12 is released? Sincerely, Steve Grubb __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From dp at co.ru Fri Jul 25 00:42:57 2003 From: dp at co.ru (Dmitry Perfilyev) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] crash on solaris Message-ID: <3F20DF81.4C96DA64@co.ru> Hi! I have next problem on restart (USR2): (last cvs version xinetd, solaris8/sparc, configuration with many tcp wait services) Jul 25 11:11:25 xinetd[12323]: [ID 385394 local0.notice] Starting reconfiguration Jul 25 11:11:26 xinetd[12323]: [ID 385394 local0.error] Unknown group: s00001 [file=/xinetd/etc/xinetd.conf] [line=21] Jul 25 11:11:26 xinetd[12323]: [ID 385394 local0.error] Error parsing attribute group - DISABLING SERVICE [file=/xinetd/etc/xinetd.conf] [line=21] Jul 25 11:11:27 xinetd[12323]: [ID 385394 local0.warning] Sending signal 9 to server 29646 Jul 25 11:11:27 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} Address of fault: 4 Jul 25 11:11:27 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} address is not mapped for object Jul 25 11:11:27 xinetd[12323]: [ID 385394 local0.crit] 12323 {general_handler} (12323) Unexpected signal: 11 (Segmentation Fault) Jul 25 11:11:27 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} Address of fault: 4 Jul 25 11:11:27 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} address is not mapped for object Jul 25 11:11:27 xinetd[12323]: [ID 385394 local0.crit] 12323 {general_handler} (12323) Unexpected signal: 11 (Segmentation Fault) Jul 25 11:11:27 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} Address of fault: 4 Jul 25 11:11:27 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} address is not mapped for object Jul 25 11:11:27 xinetd[12323]: [ID 385394 local0.crit] 12323 {general_handler} (12323) Unexpected signal: 11 (Segmentation Fault) Jul 25 11:11:27 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} Address of fault: 4 Jul 25 11:11:27 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} address is not mapped for object Jul 25 11:11:27 xinetd[12323]: [ID 385394 local0.crit] 12323 {general_handler} (12323) Unexpected signal: 11 (Segmentation Fault) ............................................................................................................................ Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} Address of fault: 400008 Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} address is not mapped for object Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.crit] 12323 {general_handler} (12323) Unexpected signal: 11 (Segmentation Fault) Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} Address of fault: 400008 Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} address is not mapped for object Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.crit] 12323 {general_handler} (12323) Unexpected signal: 11 (Segmentation Fault) Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} Address of fault: 400008 Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} address is not mapped for object Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.crit] 12323 {general_handler} (12323) Unexpected signal: 11 (Segmentation Fault) Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.error] Resetting... Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} Address of fault: 400008 Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} address is not mapped for object Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.crit] 12323 {general_handler} (12323) Unexpected signal: 11 (Segmentation Fault) Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} Address of fault: 400008 Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} address is not mapped for object Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.crit] 12323 {general_handler} (12323) Unexpected signal: 11 (Segmentation Fault) Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} Address of fault: 400008 Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.crit] 12323 {mem_fault_handler} address is not mapped for object Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.crit] 12323 {general_handler} (12323) Unexpected signal: 11 (Segmentation Fault) Jul 25 11:11:32 xinetd[12323]: [ID 385394 local0.crit] 12323 {bad_signal} Received 50 bad signals. Exiting... This happened unexpected and very rare. Any ideas ? -- Dmitry Perfilyev From linux_4ever at yahoo.com Fri Jul 25 06:38:14 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] crash on solaris In-Reply-To: <3F20DF81.4C96DA64@co.ru> Message-ID: <20030725133814.67057.qmail@web9607.mail.yahoo.com> >Jul 25 11:11:27 xinetd[12323]: [ID 385394 local0.crit] >12323 {mem_fault_handler} Address of fault: 4 > >This happened unexpected and very rare. Any ideas ? Something is pointing to 0. You might want to go into signals.c and add: #define DEBUG 1 so that xinetd generates a core dump. Then look at it with dbx or gdb and see if you can get a backtrace. Be sure to leave the debug symbols in xinetd. Without a bactrace, I have no idea where it happened. The other thing to note, what were the differences between the old version of xinetd.conf & the new version of xinetd.conf that made you want to send USR2? There might be a clue in that. And lastly, USR2 is deprecated for generating a reload. The man page says use HUP. We might reassign USR2 to something else one of these days so you may want to update scripts or operational proceedures. Best Regards, -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com