From bbraun at synack.net Tue Aug 5 19:42:03 2003 From: bbraun at synack.net (Rob Braun) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] 2.3.12 Message-ID: <20030805194203.M3321@lh.synack.net> I've just tagged xinetd 2.3.12 in the cvs repository, and made the 2.3.12 tarball available on the web page. Below is the changelog. Thanks to Steve and all those that helped with this release. Rob 2.3.12 Cleanup some signal handling if not defined. -MARUYAMA Shinichi Make ident protocol work properly for multi-homed hosts. -Alan Sundell Code cleanup for const warnings. -Steve Grubb Make redirect protocol independent. -Cougar Make reconfig iterate over all services. Some may be in "not started" state and were being missed. -Steve Grubb Make redirected, forking builtins, & tcpmux close all listening descriptors so reconfig works. -Jay Fenlason Add support for the IPV6_V6ONLY socket option. Don't assume a default setting, as the default seems to be in flux. Address compare in readjust was wrong. Its now corrected to handle each address family separately. -Steve Grubb Add command line option to not fork. This will allow xinetd to be started by init or daemontools. -Matthias Andree Fixed a leak in reconfig. If log_type = file is used for a service and SIGHUP is sent to xinetd, it leaked a file descriptor and 44 bytes of memory per service using FILE. -Steve Grubb Change all close() calls to Sclose() to prevent future problems. -Steve Grubb Fixed bug if service name is unparsable and in an included directory that caused xinetd to core dump. -Steve Grubb Fixed bug where address lists had "version" uninitialized when the list used hostnames with no dots in the name. -Steve Grubb Numerous memory leaks when parsing errors occurred. -Steve Grubb Remove the servers and xadmin internal services. Update addrlist_match to use the address part of the IPv6 address structure. -Christof Meerwald Correct looping problems for udp connections rejected by the child access controls. -Steve Grubb Added TRAFFIC logging option to report total bytes in and out for a redirected service. -Christof Meerwald Correct a double-free condition if a retry was scheduled. -Steve Grubb Add filename to parse messages. -Steve Grubb Improve port error messages after parsing. -Steve Grubb Sclose dump_fd if SIO error causes dump abort. -Steve Grubb Smorefds wasn't allocating the proper amount of sio descriptor space if the fd was > 5 over its last known fd. -Steve Grubb From bbraun at synack.net Wed Aug 6 11:21:37 2003 From: bbraun at synack.net (Rob Braun) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] xinetd feature: daemons that listen on multiple ports Message-ID: <20030806112137.N3321@lh.synack.net> I'm thinking about adding a new feature to xinetd, and am seeking feedback on how best to implement some of it. Many daemons, such as portmap and modern mail daemons, listen on more than one port or the same port on tcp and udp. Currently, this essentially means they can't run out of an inetd, or they need to change their architecture so they can. It would be useful if these services can be launched out of xinetd for a variety of reasons. There are a number of xinetd internal issues that would need to be resolved to make this happen, but the biggest issue is defining an interface for the passing of the socket descriptors to the daemons launched by xinetd. Traditionally, inetds have always passed THE socket descriptor to the child daemon on file descriptors 0, 1, and 2. This is very convenient for running non-network aware daemons through inetd. This obviously breaks down when there is more than one socket to be passed. So, here are some ideas that have been floated around. I'd be happy to get comments back on any of these ideas, or better yet, if you have a different way you'd like to see the descriptors passed. 1) Have xinetd specify which file descriptor numbers the socket descriptors will be passed on. So, in the xinetd configuration for the socket, you specify that file descriptor 5 will contain this socket. Then in the daemon, it just knows that descriptor 5 will be the right socket. This approach is very simple, it keeps with the tradition of inetd's current passing approach, but is unweildy and potentially error prone for the author of the daemons. 2) Pass the socket descriptors to the launched daemon via a unix domain socket. This has issues because file descriptor passing is not standard. Although most OS's have some ability to do this, the code is usually not portable. 3) Have xinetd pick randomly which file descriptors in the process will contain which socket descriptors, then have the launched daemon recieve addrinfo structures describing which sockets are on which file descriptors. #3 seems to have many benefits, since the descriptors are already passed to the launched daemon, and it gets complete information about that socket descriptor from xinetd. xinetd could even open the unix domain connection for the launched daemon on a known file descriptor number, say 3. The daemon will then need to read the information off that file descriptor to figure out what open descriptors it has, and what they are to. Any comments? People that write daemons launched from xinetd should be encouraged to respond. Thanks, Rob From ma+xi at dt.e-technik.uni-dortmund.de Wed Aug 6 12:18:58 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] xinetd feature: daemons that listen on multiple ports In-Reply-To: <20030806112137.N3321@lh.synack.net> (Rob Braun's message of "Wed, 6 Aug 2003 11:21:37 -0700") References: <20030806112137.N3321@lh.synack.net> Message-ID: Rob Braun writes: > I'm thinking about adding a new feature to xinetd, and am seeking > feedback on how best to implement some of it. > > Many daemons, such as portmap and modern mail daemons, listen on > more than one port or the same port on tcp and udp. > Currently, this essentially means they can't run out of an inetd, or > they need to change their architecture so they can. Why would such a daemon that already has networking code profit from being run from xinetd? It will not serve TCP and UDP for the same request, so either it can run from inetd the way it's always been (no changes necessary) or it can't because it needs persistent in-core storage that is too inefficient to load or prepare at start-up (ssh keys come to mind, on slower machines or for keys with many thousand bits -- no changes necessary). > 3) Have xinetd pick randomly which file descriptors in the > process will contain which socket descriptors, then have > the launched daemon recieve addrinfo structures describing > which sockets are on which file descriptors. The daemon could just as well use getsockaddr. No extra information passing needs to take place. -- Matthias Andree From bbraun at synack.net Wed Aug 6 12:36:57 2003 From: bbraun at synack.net (Rob Braun) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] xinetd feature: daemons that listen on multiple ports In-Reply-To: ; from ma+xi@dt.e-technik.uni-dortmund.de on Wed, Aug 06, 2003 at 09:18:58PM +0200 References: <20030806112137.N3321@lh.synack.net> Message-ID: <20030806123657.O3321@lh.synack.net> On Wed, Aug 06, 2003 at 09:18:58PM +0200, Matthias Andree wrote: > > Why would such a daemon that already has networking code profit from > being run from xinetd? It will not serve TCP and UDP for the same > request, so either it can run from inetd the way it's always been (no > changes necessary) or it can't because it needs persistent in-core > storage that is too inefficient to load or prepare at start-up (ssh keys > come to mind, on slower machines or for keys with many thousand bits -- > no changes necessary). Launching services from inetd isn't just for lazy programmers anymore. An inetd can serve as a central network service management point. If all or many of the system's network services are run out of an inetd, they can easily or programmatically be controled through that one interface, rather than teaching everything how to interface with each particular application's start/stop/config setup. In addition to just being a funnel, performance benefits can be had. Services can be offered with near zero penalty if they aren't used, and are instantly available if they are needed. This can often result in faster boot times, since the daemons don't need to be paged in until they are needed. Obviously, for systems that need lower latency and handle higher loads, launching daemons through an inetd is not desireable. However, given that the vast majority of machines with xinetd installed are reasonably fast hardware, and rarely need the performance of a high end server, this can be an overall win. In many cases, the load is just a few users who would rather have the services available when needed. > > 3) Have xinetd pick randomly which file descriptors in the > > process will contain which socket descriptors, then have > > the launched daemon recieve addrinfo structures describing > > which sockets are on which file descriptors. > > The daemon could just as well use getsockaddr. No extra information > passing needs to take place. True. A simple call to getsockname() would return all of the same information. This would just be a convenience instead of making the daemon iterate over all it's sockets doing getsockname(). Perhaps it would be simpler if the app just did those calls as needed. Rob From cmeerw at web.de Wed Aug 6 14:20:19 2003 From: cmeerw at web.de (Christof Meerwald) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] bug in addrlist_match (with IPv6 addresses) In-Reply-To: <20030620015430.99080.qmail@web9608.mail.yahoo.com> References: <20030619205034.GA20285@hacking.cmeerw.net> <20030620015430.99080.qmail@web9608.mail.yahoo.com> Message-ID: <20030806212019.GA12996@hacking.cmeerw.net> On Thu, Jun 19, 2003 at 06:54:30PM -0700, Steve G wrote: > - uint32_t *tmp_addr = (unsigned *)&addr->sa_data[3]; > + uint32_t *tmp_addr = > &SAIN6(addr)->sin6_addr.s6_addr32[3]; > > This should be applied, the rest doesn't need to be. This one isn't included in xinetd 2.3.12 (you reverted the change a few days later). But your code isn't correct. Have a look at the sockaddr and sockaddr_in6 definitions (from glibc 2.2.x, Debian woody): /* Structure describing a generic socket address. */ struct sockaddr { __SOCKADDR_COMMON (sa_); /* Common data: address family and length. */ char sa_data[14]; /* Address data. */ }; struct sockaddr_in6 { __SOCKADDR_COMMON (sin6_); in_port_t sin6_port; /* Transport layer port # */ uint32_t sin6_flowinfo; /* IPv6 flow information */ struct in6_addr sin6_addr; /* IPv6 address */ uint32_t sin6_scope_id; /* IPv6 scope-id */ }; So, "(unsigned *)&addr->sa_data[3]" definitely won't contain the mapped IPv4 address, instead it will contain 24 bits of the sin6_flowinfo field and 8 bits of sin6_addr (and will probably segfault on some RISC architectures because of a misaligned memory access). Hmm, in case my fix just wasn't portable enough, this one might be better (untested): uint32_t *tmp_addr = (uint32_t *) &SAIN6(addr)->sin6_addr.s6_addr[12]; (see http://www.opengroup.org/onlinepubs/007904975/basedefs/netinet/in.h.html: "The header shall define the in6_addr structure that contains at least the following member: uint8_t s6_addr[16]") bye, Christof -- http://cmeerw.org JID: cmeerw@jabber.at mailto cmeerw at web.de From linux_4ever at yahoo.com Wed Aug 6 14:23:24 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] xinetd feature: daemons that listen on multiple ports In-Reply-To: <20030806123657.O3321@lh.synack.net> Message-ID: <20030806212324.64678.qmail@web9601.mail.yahoo.com> Hello, All that's truly needed in xinetd is the ability to define an address list for the bind parameter. Just that one thing would get us the most flexibility for the effort. This is what other inetd's do. I would also say that passing data structures around goes against what all other inetd's do. Over the last month, I've been writing the specifications for a new inetd. I am wanting to try an experiment. Everyone has heard of the CMMI technique. I am curious if that works for Open Source projects as well. I surveyed all inetd's I could to see what they do and put that into a requirements document. The requirements are most of the way done. This would be the RRP milestone. I also have a pretty good start on the UML diagrams to take it to a PDR stage. Writing new requirements has also been educational. I've found several areas that xinetd's behavior is different that other inetd's. Then there's IPsec and SASL. I don't like the idea of squeezing that into xinetd as it stands. One of the reasons I'm doing this is that I think the xinetd code, even though its better than 2 years ago, is way too fragile to be doing heavy changes in. 2.3.12 is very stable compared to what we've had in a long time that I'm reluctant to see major changes in that code base. Starting over with a clean sheet would be a better way to go in my opinion. For example, the sio library which has caused so much pain over the last year is not needed at all. If xinetd did a lot of I/O, it might make a difference. All its used for is reading the configuration, writing to the log if file logging is used, and writing a state dump. As for the log files, we write one sentence and close the file. There is no real gain, but we have had a lot of pain. Reading config files and dumping state are perfectly fine with read() & write(). IPsec and SASL and other things should be designed in from the ground up. Each module should have its own unit test that exercises it. Each module can be swung in and out at compile time. People that want a lean inetd can compile just the pieces they need. Vendors can compile the whole thing. My personal thoughts is that we should leave the xinetd code alone and start a new version from scratch. Only do bug fixes in the 2.3 series. My 2 cents. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From ma+xi at dt.e-technik.uni-dortmund.de Wed Aug 6 14:57:34 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] xinetd feature: daemons that listen on multiple ports In-Reply-To: <20030806212324.64678.qmail@web9601.mail.yahoo.com> (Steve G.'s message of "Wed, 6 Aug 2003 14:23:24 -0700 (PDT)") References: <20030806212324.64678.qmail@web9601.mail.yahoo.com> Message-ID: Steve G writes: > Writing new requirements has also been educational. I've > found several areas that xinetd's behavior is different > that other inetd's. Then there's IPsec and SASL. I don't > like the idea of squeezing that into xinetd as it stands. Interesting _new_ points are SSL and particularly TLS (the latter is dependent on the protocol, SMTP vs. POP3 vs. IMAP vs. ...) > IPsec and SASL and other things should be designed in from > the ground up. Each module should have its own unit test > that exercises it. Each module can be swung in and out at > compile time. People that want a lean inetd can compile > just the pieces they need. Vendors can compile the whole > thing. While modular approaches are very smooth to test and are aesthetic and have some advantages if the new inetd is considered by itself, this view is way too narrow when evaluating the system at large, inetd + daemons. The problem shows when it comes to documenting daemons, section installation instructions. If you're going to give inetd sample lines, even in the simplest setup you'll have to take four cases into account: your inetd is stupid (no libwrap), your inetd runs with libwrap by default (FreeBSD); tcpd was compiled without PROCESS_OPTIONS, tcpd was compiled with PROCESS_OPTIONS. Now some distros (Red Hat) install xinetd rather than inetd by default, so you add more stuff, and differentiate libwrap again. Makes eight cases already. The more modules the user or a vendor can remove, the more cases "if $INETD was compiled with $OPTION, use this, if $OPTION was left out, use that line" -- someone documenting his ftpd/nntpd/whateverd has to take all this into account. If you need to give simple yet water proof installation instructions, there's nothing short of recommending that the user installs daemontools and ipsvd or ucspi-tcp (see http://cr.yp.to/ and http://smarden.org/pape/). IF you are designing a new inetd, then please do make sure that there are absolutely no switches that disable important features. It must be possible that a _SINGLE_ example of my nntpd or ftpd installation instructions covers $NEW_INETD configuration once and for good -- and do integrate socket_wrappers with -DPROCESS_OPTIONS. (I'd also recommend looking at ipsvd, it has some quite nifty access control features.) -- Matthias Andree From linux_4ever at yahoo.com Wed Aug 6 15:04:56 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] bug in addrlist_match (with IPv6 addresses) In-Reply-To: <20030806212019.GA12996@hacking.cmeerw.net> Message-ID: <20030806220456.64080.qmail@web9602.mail.yahoo.com> >Hmm, in case my fix just wasn't portable enough, this one >might be better (untested): > > uint32_t *tmp_addr = (uint32_t *) >&SAIN6(addr)->sin6_addr.s6_addr[12]; Rob, Does this work for you? The patch was reverted since it didn't compile on Rob's machine. I think the macros were not portable. Looking at one of the IPv6 macros: #define IN6_ARE_ADDR_EQUAL(a,b) \ ((((__const uint32_t *) (a))[0] == ((__const uint32_t *) (b))[0]) \ && (((__const uint32_t *) (a))[1] == ((__const uint32_t *) (b))[1]) \ && (((__const uint32_t *) (a))[2] == ((__const uint32_t *) (b))[2]) \ && (((__const uint32_t *) (a))[3] == ((__const uint32_t *) (b))[3])) Probably the most portable way to do it is to make a macro #define IPV4_ADDR_OFFSET (a) ((__const uint32_t *) (a))[3] Then uint32_t *tmp_addr = IPV4_ADDR_OFFSET(&SAIN6(addr)->sin6_addr.s6_addr); -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From bbraun at synack.net Wed Aug 6 15:10:16 2003 From: bbraun at synack.net (Rob Braun) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] xinetd feature: daemons that listen on multiple ports In-Reply-To: <20030806212324.64678.qmail@web9601.mail.yahoo.com>; from linux_4ever@yahoo.com on Wed, Aug 06, 2003 at 02:23:24PM -0700 References: <20030806123657.O3321@lh.synack.net> <20030806212324.64678.qmail@web9601.mail.yahoo.com> Message-ID: <20030806151016.Q3321@lh.synack.net> On Wed, Aug 06, 2003 at 02:23:24PM -0700, Steve G wrote: > Hello, > > All that's truly needed in xinetd is the ability to define > an address list for the bind parameter. Just that one thing > would get us the most flexibility for the effort. This is > what other inetd's do. I think you do not understand the feature I am proposing. This is NOT simply binding to multiple interfaces. This is to handle services that listen on multiple ports, with multiple protocols. This is NOT a feature that any existing inetd currently implements. Rob From ma+xi at dt.e-technik.uni-dortmund.de Wed Aug 6 15:12:23 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] xinetd feature: daemons that listen on multiple ports In-Reply-To: <20030806123657.O3321@lh.synack.net> (Rob Braun's message of "Wed, 6 Aug 2003 12:36:57 -0700") References: <20030806112137.N3321@lh.synack.net> <20030806123657.O3321@lh.synack.net> Message-ID: Rob Braun writes: > On Wed, Aug 06, 2003 at 09:18:58PM +0200, Matthias Andree wrote: >> >> Why would such a daemon that already has networking code profit from >> being run from xinetd? It will not serve TCP and UDP for the same >> request, so either it can run from inetd the way it's always been (no >> changes necessary) or it can't because it needs persistent in-core >> storage that is too inefficient to load or prepare at start-up (ssh keys >> come to mind, on slower machines or for keys with many thousand bits -- >> no changes necessary). > > Launching services from inetd isn't just for lazy programmers anymore. > An inetd can serve as a central network service management point. > If all or many of the system's network services are run out of an > inetd, they can easily or programmatically be controled through that > one interface, rather than teaching everything how to interface with > each particular application's start/stop/config setup. In addition > to just being a funnel, performance benefits can be had. Services > can be offered with near zero penalty if they aren't used, and are > instantly available if they are needed. This can often result in > faster boot times, since the daemons don't need to be paged in until > they are needed. These are all the regular inetd advantages. We know these. But what daemon serves a TCP and UDP request at the same time FOR THE SAME REQUEST? I fail to see which daemon would use two sockets for one request, synchronization of communiation alone is so expensive this is prohibitive. The client uses TCP or UDP, but not both at the same time. IF there is benefit in serving several IP protocols via several sockets at the same time, the services are already implementing that stuff, and such features will not go away (squid comes to mind). >> The daemon could just as well use getsockaddr. No extra information >> passing needs to take place. > > True. A simple call to getsockname() would return all of the > same information. This would just be a convenience instead of > making the daemon iterate over all it's sockets doing getsockname(). > Perhaps it would be simpler if the app just did those calls as needed. Such convienience features are wasted efforts. Slapping on the "daemon programmer hat" (I maintain the leafnode NNTP software), I'm not going to use such features because that makes my software behave differently depending on what inetd incarnation the user uses. This entails: - more code effort to make use of such convenience stuff - more testing is necessary, in more different parallel code paths - you need to request more information from users when supporting them Example: Some information about that is available in DJB's UCSPI protocol that sets some environment variables describing the remote site, say TCPREMOTEINFO, TCPREMOTEIP and TCPREMOTEHOST. All it takes to access that information is a getenv(3), still I'm not doing it because that information is not available when the software starts from inetd or xinetd, so I'll have to add my own lookup-and-resolve stuff to add logging anyways. And once I've got that implemented and debugged, there's no need to add more code to access such convenience information because I already have 100% working code to retrieve the very same information. I fail to see a) how your suggestion would work, b) what its field of application might be. Frankly, I don't see use. I don't want to stifle innovation, but I do fear you're going to produce dead code that will see bugs found years ahead from now. inetds are expected to be VERY stable interfaces, and daemons will use just the lowest common denominator. -- Matthias Andree From ma+xi at dt.e-technik.uni-dortmund.de Wed Aug 6 15:13:30 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] bug in addrlist_match (with IPv6 addresses) In-Reply-To: <20030806220456.64080.qmail@web9602.mail.yahoo.com> (Steve G.'s message of "Wed, 6 Aug 2003 15:04:56 -0700 (PDT)") References: <20030806220456.64080.qmail@web9602.mail.yahoo.com> Message-ID: Steve G writes: > The patch was reverted since it didn't compile on Rob's > machine. I think the macros were not portable. Looking at > one of the IPv6 macros: > > Probably the most portable way to do it is to make a macro > > #define IPV4_ADDR_OFFSET (a) ((__const uint32_t *) (a))[3] One-word interjection: Ugh. -- Matthias Andree From ma+xi at dt.e-technik.uni-dortmund.de Wed Aug 6 15:18:57 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] post-2.3.12 pending stuff in my private work area Message-ID: Hi, I have some patches sitting in my working directory that I can group into two change sets: 1. portability. I don't know if Solaris 2.6 portability is complete with these changes, but Solaris 8 and FreeBSD 4-STABLE should be fine. Most of this stuff is u_int_* -> uint_* patching, hardcoding MAX_DATAGRAM_SIZE and adding missing #include lines. 2. a new "libwrap" option to let me configure the name that libwrap is given for looking up if access is to be allowed. Rationale: if I need some wrapper (say, softlimit or tcpd) around a server, I must write another wrapper for the wrapper so that I can have a server= argument that matches hosts.{allow,deny} daemon names. Don't argue, tcpd is necessary because I don't want to tell people "if xinetd was compiled with libwrap...": the easy way is to tell them to use tcpd and set flags = NOLIBWRAP (I hope this flag is accepted and ignored if libwrap support isn't compiled in). -- Matthias Andree From bbraun at synack.net Wed Aug 6 15:21:18 2003 From: bbraun at synack.net (Rob Braun) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] xinetd feature: daemons that listen on multiple ports In-Reply-To: ; from ma+xi@dt.e-technik.uni-dortmund.de on Thu, Aug 07, 2003 at 12:12:23AM +0200 References: <20030806112137.N3321@lh.synack.net> <20030806123657.O3321@lh.synack.net> Message-ID: <20030806152118.R3321@lh.synack.net> On Thu, Aug 07, 2003 at 12:12:23AM +0200, Matthias Andree wrote: > > These are all the regular inetd advantages. We know these. But what > daemon serves a TCP and UDP request at the same time FOR THE SAME > REQUEST? I fail to see which daemon would use two sockets for one > request, synchronization of communiation alone is so expensive this is > prohibitive. The client uses TCP or UDP, but not both at the same time. There are several daemons out there that listen on multiple ports. Portmap listens on both udp and tcp sockets. Individual clients do not use both simultaneously, but different clients use different protocols to get at the same information. The daemon needs to respond to requests on both. Currently, it can't be launched from an inetd reliably, because there is no way to pass multiple socket descriptors to the daemon. > IF there is benefit in serving several IP protocols via several sockets > at the same time, the services are already implementing that stuff, and > such features will not go away (squid comes to mind). I have no intention of making the existing feature sets go away. However, it may be easy to modify the existing daemons so they can be launched out of inetd or standalone, like so many other daemons (sshd, samba, proftpd, etc.) > Such convienience features are wasted efforts. Slapping on the "daemon > programmer hat" (I maintain the leafnode NNTP software), I'm not going > to use such features because that makes my software behave differently > depending on what inetd incarnation the user uses. This entails: Fair enough. I fully understand. I sincerely wish xinetd didn't need to be portable and was for one specific platform for the exact same reasons. As the software maintainer, you're completely within your rights to reject code. Thank you for your comments on the passing of information. I tend to agree with you that it's not really needed. Rob From linux_4ever at yahoo.com Wed Aug 6 15:38:42 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] xinetd feature: daemons that listen on multiple ports In-Reply-To: <20030806151016.Q3321@lh.synack.net> Message-ID: <20030806223842.48504.qmail@web9606.mail.yahoo.com> >I think you do not understand the feature I am proposing. >This is NOT simply binding to multiple interfaces. Right, I understand the proposal. What I'm saying, poorly, is that I don't think this is necessary, but this other feature would be real handy and people have even asked for it. For example, radiusd listens on 3 ports. All radius daemons already have listeners for each port and security features builtin. Is there any deamon that could use it right now if it was built? Or is it something that we are just building so that one day someone may hook into xinetd ? That's really my main concern. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From linux_4ever at yahoo.com Wed Aug 6 15:56:52 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] post-2.3.12 pending stuff in my private work area In-Reply-To: Message-ID: <20030806225652.41345.qmail@web9604.mail.yahoo.com> >2. a new "libwrap" option to let me configure the name >that libwrap is given for looking up if access is to be >allowed. You shouldn't need this. tcpd always uses the basename of the full path to the server. The only instance when this is a problem is for internal servers. In that case it should revert to the official service name from /etc/services. Think of inetd, there is no where to pass the name of what you want tcpd to think the name is. Its implicit in the command line. >the easy way is to tell them to use tcpd and set flags = >NOLIBWRAP (I hope this flag is accepted and ignored if >libwrap support isn't compiled in). xinetd should run fine with this flag defined even if libwrap is not compiled in. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From ma+xi at dt.e-technik.uni-dortmund.de Wed Aug 6 15:57:22 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] xinetd feature: daemons that listen on multiple ports In-Reply-To: <20030806152118.R3321@lh.synack.net> (Rob Braun's message of "Wed, 6 Aug 2003 15:21:18 -0700") References: <20030806112137.N3321@lh.synack.net> <20030806123657.O3321@lh.synack.net> <20030806152118.R3321@lh.synack.net> Message-ID: Rob Braun writes: > There are several daemons out there that listen on multiple ports. > Portmap listens on both udp and tcp sockets. Individual clients > do not use both simultaneously, but different clients use different > protocols to get at the same information. The daemon needs to > respond to requests on both. Currently, it can't be launched from > an inetd reliably, because there is no way to pass multiple socket > descriptors to the daemon. The rpcbind = portmap issue is a rather special one, and so special that its solution isn't in good hands of a general-purpose inetd. The rpcbind case is special because all rpcbind implementations I've seen so far keep their registrations in memory only, so the daemon must be persistent. If you implemented an rpcbind that used a concurrent data base (single-writer, multi-reader) such as BerkeleyDB or TDB, you could write a simple inetd-launchable rpcbind that processed the request and then exited. Apparently no-one felt a pain big enough to sit down and do this. The next reason is that if a system needs to run rpcbind (NFS exports or something), the demand for rpcbind will arise at boot time already, so rpcbind will always be run this way or the other. Running it from inetd doesn't gain from the "on-demand" trait. Some RPC services that aren't used often might profit (ypxfrd or something), but as they have to have network code to register with rpcbind, there's not much to be gained here either, and I wonder how you'd serialize the single-threaded ones. It's trivial when there's one process running, but what do you do when two requests arrive "at the same time" with different IP protocols? A single-threaded process is easy, but you're then going to implement locking in xinetd as well so you can avoid running two daemons for a single-threaded service and all that. Looking at Solaris' inetd.conf, all RPC services listed in inetd.conf (there are standalone RPC services, too) are single-threaded. I can't tell if these listen for TCP and UDP at the same time. Similar latency considerations apply to DNS resolvers, latency will be a show-stopper here. > However, it may be easy to modify the existing daemons so they can > be launched out of inetd or standalone, like so many other daemons > (sshd, samba, proftpd, etc.) There is no need to add code to xinetd for that purpose. If I was to program a new daemon, and it allowed inetd configurations without pain (like sshd key generation overhead which is a real hog on slower machines), I'd rather not implement a standalone mode at all. There are so many inetd replacements: xinetd, ucspi-tcp, ipsvd, sock, socket, netcat, g2s, ... -- Matthias Andree From linux_4ever at yahoo.com Wed Aug 6 16:08:33 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] bug in addrlist_match (with IPv6 addresses) In-Reply-To: Message-ID: <20030806230833.87522.qmail@web9603.mail.yahoo.com> >>Probably the most portable way to do it is to make a macro >> >> #define IPV4_ADDR_OFFSET (a) ((__const uint32_t *) (a))[3] > >One-word interjection: Ugh. Right. :) > - uint32_t *tmp_addr = (unsigned *)&addr->sa_data[3]; > + uint32_t *tmp_addr = > &SAIN6(addr)->sin6_addr.s6_addr32[3]; I think I see what the problem is...missing parenthesis. It should have been: uint32_t *tmp_addr = ((unsigned *)&addr->sa_data)[3]; It was supposed to be the 3rd int (or 12 bytes) from the beginning of the structure. The macro at least hides all the casting to make the compiler do what's intended. -Steve __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From bbraun at synack.net Wed Aug 6 21:23:11 2003 From: bbraun at synack.net (Rob Braun) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] xinetd feature: daemons that listen on multiple ports In-Reply-To: ; from ma+xi@dt.e-technik.uni-dortmund.de on Thu, Aug 07, 2003 at 12:57:22AM +0200 References: <20030806112137.N3321@lh.synack.net> <20030806123657.O3321@lh.synack.net> <20030806152118.R3321@lh.synack.net> Message-ID: <20030806212311.S3321@lh.synack.net> You make very good points and have a persuasive argument. You've convinced me that this feature is not worthwhile, and all the problems that this would solve, can be solved better in other ways. Thank you for the input. Rob On Thu, Aug 07, 2003 at 12:57:22AM +0200, Matthias Andree wrote: > Rob Braun writes: > > > There are several daemons out there that listen on multiple ports. > > Portmap listens on both udp and tcp sockets. Individual clients > > do not use both simultaneously, but different clients use different > > protocols to get at the same information. The daemon needs to > > respond to requests on both. Currently, it can't be launched from > > an inetd reliably, because there is no way to pass multiple socket > > descriptors to the daemon. > > The rpcbind = portmap issue is a rather special one, and so special that > its solution isn't in good hands of a general-purpose inetd. > > The rpcbind case is special because all rpcbind implementations I've > seen so far keep their registrations in memory only, so the daemon must > be persistent. If you implemented an rpcbind that used a concurrent data > base (single-writer, multi-reader) such as BerkeleyDB or TDB, you could > write a simple inetd-launchable rpcbind that processed the request and > then exited. Apparently no-one felt a pain big enough to sit down and do > this. > > The next reason is that if a system needs to run rpcbind (NFS exports or > something), the demand for rpcbind will arise at boot time already, so > rpcbind will always be run this way or the other. Running it from inetd > doesn't gain from the "on-demand" trait. > > Some RPC services that aren't used often might profit (ypxfrd or > something), but as they have to have network code to register with > rpcbind, there's not much to be gained here either, and I wonder how > you'd serialize the single-threaded ones. It's trivial when there's one > process running, but what do you do when two requests arrive "at the > same time" with different IP protocols? A single-threaded process is > easy, but you're then going to implement locking in xinetd as well so > you can avoid running two daemons for a single-threaded service and all > that. Looking at Solaris' inetd.conf, all RPC services listed in > inetd.conf (there are standalone RPC services, too) are > single-threaded. I can't tell if these listen for TCP and UDP at the > same time. > > Similar latency considerations apply to DNS resolvers, latency will be a > show-stopper here. > > > However, it may be easy to modify the existing daemons so they can > > be launched out of inetd or standalone, like so many other daemons > > (sshd, samba, proftpd, etc.) > > There is no need to add code to xinetd for that purpose. If I was to > program a new daemon, and it allowed inetd configurations without pain > (like sshd key generation overhead which is a real hog on slower > machines), I'd rather not implement a standalone mode at all. There are > so many inetd replacements: xinetd, ucspi-tcp, ipsvd, sock, socket, > netcat, g2s, ... > > -- > Matthias Andree > _______________________________________________ > xinetd mailing list > xinetd@xinetd.org > http://www.xinetd.org/mailman/listinfo/xinetd From ma+xi at dt.e-technik.uni-dortmund.de Thu Aug 7 01:39:34 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] bug in addrlist_match (with IPv6 addresses) In-Reply-To: <20030806230833.87522.qmail@web9603.mail.yahoo.com> (Steve G.'s message of "Wed, 6 Aug 2003 16:08:33 -0700 (PDT)") References: <20030806230833.87522.qmail@web9603.mail.yahoo.com> Message-ID: Steve G writes: >>>Probably the most portable way to do it is to make a > macro >>> >>> #define IPV4_ADDR_OFFSET (a) ((__const uint32_t *) > (a))[3] >> >>One-word interjection: Ugh. > > Right. :) > >> - uint32_t *tmp_addr = (unsigned *)&addr->sa_data[3]; >> + uint32_t *tmp_addr = >> &SAIN6(addr)->sin6_addr.s6_addr32[3]; > > I think I see what the problem is...missing parenthesis. It > should have been: > > uint32_t *tmp_addr = ((unsigned *)&addr->sa_data)[3]; Neither. You don't assign (((unsigned *)X)[N]) to uint32_t because you don't know if sizeof unsigned == sizeof uint32_t. There's a reason why these exist. Besides, I'd personally add another pair of parentheses around the IPV4_ADDR_OFFSET expansion so you don't leave a dangling [3] in the air -- aside from disliking macros because they defeat type checking and cause non-obvious errors to show up at strange places. -- Matthias Andree From ma+xi at dt.e-technik.uni-dortmund.de Thu Aug 7 01:42:02 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] post-2.3.12 pending stuff in my private work area In-Reply-To: <20030806225652.41345.qmail@web9604.mail.yahoo.com> (Steve G.'s message of "Wed, 6 Aug 2003 15:56:52 -0700 (PDT)") References: <20030806225652.41345.qmail@web9604.mail.yahoo.com> Message-ID: Steve G writes: >>2. a new "libwrap" option to let me configure the name >>that libwrap is given for looking up if access is to be >>allowed. > > You shouldn't need this. tcpd always uses the basename of > the full path to the server. That's the problem. Who says I can't use the same server executable with different environment variables and different access control lists on different ports? If I'm going to do that, I'll have to write shell wrappers. The libwrap feature trivially eliminates the need for the additional shell start. > Think of inetd, there is no where to pass the name of what > you want tcpd to think the name is. Its implicit in the > command line. xinetd is not inetd. -- Matthias Andree From linux_4ever at yahoo.com Thu Aug 7 05:23:33 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] post-2.3.12 pending stuff in my private work area In-Reply-To: Message-ID: <20030807122333.38092.qmail@web9605.mail.yahoo.com> >Who says I can't use the same server executable >with different environment variables and different >access control lists on different ports? That's easy to solve. I'd just symlink to another name for that port/address. For example, proftpd is also symlinked to proftpd.in. You can just create another symlink. Its hackish, but less so than maintaining your own patch against xinetd. It is also portable to inetd should you even need to go that direction. Yesterday you said you recommend NOLIBWRAP for a flag and then call tcpd so people have a consistent setup. In that scenario, the patch to xinetd doesn't even come into play since NOLIBWRAP is given. But back to your original post for this thread. Why don't you send Rob the patch so the portability enhancements can start to be integrated? I think we're ready for those changes. :) Best Regards, -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From cmeerw at web.de Thu Aug 7 08:39:31 2003 From: cmeerw at web.de (Christof Meerwald) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Re: bug in addrlist_match (with IPv6 addresses) In-Reply-To: <20030806230833.87522.qmail@web9603.mail.yahoo.com> References: <20030806230833.87522.qmail@web9603.mail.yahoo.com> Message-ID: <20030807153931.GA1080@hacking.cmeerw.net> On Wed, 6 Aug 2003 16:08:33 -0700 (PDT), Steve G wrote: >> - uint32_t *tmp_addr = (unsigned *)&addr->sa_data[3]; >> + uint32_t *tmp_addr = >> &SAIN6(addr)->sin6_addr.s6_addr32[3]; > I think I see what the problem is...missing parenthesis. It > should have been: > > uint32_t *tmp_addr = ((unsigned *)&addr->sa_data)[3]; > > It was supposed to be the 3rd int (or 12 bytes) from the > beginning of the structure. But you are not allowed to assume that the IPv6 address is the first member in the struct (and in fact this isn't the case with Linux). bye, Christof -- http://cmeerw.org JID: cmeerw@jabber.at mailto cmeerw at web.de From linux_4ever at yahoo.com Thu Aug 7 10:29:49 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Re: bug in addrlist_match (with IPv6 addresses) In-Reply-To: <20030807153931.GA1080@hacking.cmeerw.net> Message-ID: <20030807172949.26231.qmail@web9603.mail.yahoo.com> >But you are not allowed to assume that the IPv6 address >is the first member in the struct (and in fact this isn't >the case with Linux). OK, let's come to a consensus. Rob said in a private e-mail weeks ago that s6_addr doesn't exist on all platforms. So I've revised the code. Matthias wanted another set of parenthesis to be safe. They are added. Does this work for everybody? #define IPV4_ADDR_OFFSET (a) (((const uint32_t *) (a))[3]) uint32_t *tmp_addr = IPV4_ADDR_OFFSET(&SAIN6(addr)->sin6_addr); Let's patch it and move on to other things. ;) -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From bbraun at synack.net Thu Aug 7 10:52:06 2003 From: bbraun at synack.net (Rob Braun) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Re: bug in addrlist_match (with IPv6 addresses) In-Reply-To: <20030807172949.26231.qmail@web9603.mail.yahoo.com>; from linux_4ever@yahoo.com on Thu, Aug 07, 2003 at 10:29:49AM -0700 References: <20030807153931.GA1080@hacking.cmeerw.net> <20030807172949.26231.qmail@web9603.mail.yahoo.com> Message-ID: <20030807105206.T3321@lh.synack.net> On Thu, Aug 07, 2003 at 10:29:49AM -0700, Steve G wrote: > > OK, let's come to a consensus. Rob said in a private e-mail > weeks ago that s6_addr doesn't exist on all platforms. So > I've revised the code. Matthias wanted another set of > parenthesis to be safe. They are added. Does this work for > everybody? I'll give it a shot on my machines. If it compiles and works for everyone, we'll go for it, unless someone has a compelling argument for something else that works at least as well. Rob From bbraun at synack.net Thu Aug 7 10:59:15 2003 From: bbraun at synack.net (Rob Braun) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] post-2.3.12 pending stuff in my private work area In-Reply-To: ; from ma+xi@dt.e-technik.uni-dortmund.de on Thu, Aug 07, 2003 at 10:42:02AM +0200 References: <20030806225652.41345.qmail@web9604.mail.yahoo.com> Message-ID: <20030807105915.U3321@lh.synack.net> On Thu, Aug 07, 2003 at 10:42:02AM +0200, Matthias Andree wrote: > Steve G writes: > > >>2. a new "libwrap" option to let me configure the name > >>that libwrap is given for looking up if access is to be > >>allowed. > > > > You shouldn't need this. tcpd always uses the basename of > > the full path to the server. > > That's the problem. Who says I can't use the same server executable with > different environment variables and different access control lists on > different ports? If I'm going to do that, I'll have to write shell > wrappers. The libwrap feature trivially eliminates the need for the > additional shell start. I've actually come around on this patch. xinetd and tcpwrappers integration has always been kinda weird with xinetd. There are legitimate arguments to be made to be using sc_name, sc_id, or the executable basename. The addition of the libwrap configuration option makes it absolutely clear for the people that care. If libwrap is not specified, libwrap will default to the basename of of the executable, or the sc_id if the service is internal. Right now, xinetd & libwrap integration are a little inflexible and this new configuration option alieviates that a little. I'll look over the diff and unless there is a compelling argument against it, I'll commit it later this afternoon along with the Solaris build fixes. Rob From ma+xi at dt.e-technik.uni-dortmund.de Fri Aug 8 07:49:43 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] post-2.3.12 pending stuff in my private work area In-Reply-To: <20030807122333.38092.qmail@web9605.mail.yahoo.com> (Steve G.'s message of "Thu, 7 Aug 2003 05:23:33 -0700 (PDT)") References: <20030807122333.38092.qmail@web9605.mail.yahoo.com> Message-ID: Steve G writes: > Yesterday you said you recommend NOLIBWRAP for a flag and > then call tcpd so people have a consistent setup. In that > scenario, the patch to xinetd doesn't even come into play > since NOLIBWRAP is given. These are orthogonal. I'd like the libwrap stuff for myself, and the "consistent options" configuration when I'm documenting other software that is launched by some inetd. > But back to your original post for this thread. Why don't > you send Rob the patch so the portability enhancements can > start to be integrated? I think we're ready for those > changes. :) OK -- Matthias Andree From ma+xi at dt.e-technik.uni-dortmund.de Fri Aug 8 08:00:59 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Current patches for portability and libwrap Message-ID: Hi, I am attaching the two patch sets, generated against current CVS. The first is the portability stuff (I hope it doesn't break older BSD), the second is the libwrap stuff. -- Matthias Andree -------------- next part -------------- A non-text attachment was scrubbed... Name: portable.patch Type: text/x-patch Size: 2301 bytes Desc: enhance xinetd portability Url : http://www.xinetd.org/pipermail/xinetd/attachments/20030808/0da601cd/portable.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: libwrap.patch Type: text/x-patch Size: 6808 bytes Desc: add \"libwrap\" configuration parameter Url : http://www.xinetd.org/pipermail/xinetd/attachments/20030808/0da601cd/libwrap.bin From ma+xi at dt.e-technik.uni-dortmund.de Fri Aug 8 08:02:13 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] post-2.3.12 pending stuff in my private work area In-Reply-To: <20030807105915.U3321@lh.synack.net> (Rob Braun's message of "Thu, 7 Aug 2003 10:59:15 -0700") References: <20030806225652.41345.qmail@web9604.mail.yahoo.com> <20030807105915.U3321@lh.synack.net> Message-ID: Rob Braun writes: > I'll look over the diff and unless there is a compelling argument > against it, I'll commit it later this afternoon along with the > Solaris build fixes. The patch I posted a minute or two ago merges the current xinetd-cvs, resolving a minor conflict (tracking style change). -- Matthias Andree From tony at accesslab.com Mon Aug 11 10:44:55 2003 From: tony at accesslab.com (Tony Thedford) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Is this a normal mode of operation? Message-ID: <200308111244.55914@why-ask-why> I'm wondering if the way that I am running the xinetd server is using a feature or programing accident. I didn't find any info or examples where others are doing the same thing. I am setting up my config file to all to service id's to both use the same port. One service id restricts the incoming connection addresses to range A while the other service id restricts them to range B. Neither range overlaps. Both services use the same protocol, TCP. It seems to work OK this way but is this and intended mode of operation by the designers? In other words, is it safe to assume that it will still work this way on the next revision of the program? Here are my two services in question: # default: on # description: Qmail SMTP service for delivering and receiving mail via \ # the SMTP protocol. Provides local service with relaying. service smtp { disable = no id = smtp-loc port = 25 only_from = 192.168.0.0/16 127.0.0.1 socket_type = stream protocol = tcp wait = no env = RELAYCLIENT= passenv = user = qmaild flags = NOLIBWRAP server = /var/qmail/bin/tcp-env server_args = -R /var/qmail/bin/qmail-smtpd log_on_success = HOST DURATION PID log_on_failure = HOST nice = 0 instances = 60 cps = 25 5 rlimit_as = 2M } # default: on # description: Qmail SMTP service for delivering and receiving mail via \ # the SMTP protocol. Provide public service with relaying denied. service smtp { disable = no id = smtp-pub port = 25 no_access = 192.168.0.0/16 127.0.0.1 socket_type = stream protocol = tcp wait = no env = passenv = user = qmaild flags = NOLIBWRAP server = /var/qmail/bin/tcp-env server_args = -R /var/qmail/bin/qmail-smtpd log_on_success = HOST DURATION PID log_on_failure = HOST nice = 0 instances = 60 cps = 25 5 rlimit_as = 2M } Thanks for any comments, opinions, pointers, etc. -Tony Thedford -- Of all men's miseries, the bitterest is this: to know so much and have control over nothing. -- Herodotus From tony at accesslab.com Mon Aug 11 11:22:20 2003 From: tony at accesslab.com (Tony Thedford) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Normal mode of operation? - Clarifying on 2nd Try. Message-ID: <200308111322.20732@why-ask-why> Sorry for double posting but the original was just too screwed up. ---- I'm wondering if the way that I am running the xinetd server is using a feature or programing accident. I didn't find any info or examples where others are doing the same thing. I am setting up my config file to allow two different service id's to both use the same port. One service id restricts the incoming connection addresses to range A while the other service id restricts them to range B. Neither range overlaps. Both services use the same protocol, TCP. It seems to work OK this way but is this an intentional mode of operation by the designers? In other words, is it semi-safe to assume that it will still work this way on the next revision of the program? Another thought comes to mind - what will be the out come in all cases if the ranges do overlap? Here are my two services in question: # default: on # description: Qmail SMTP service for delivering and receiving mail via \ # the SMTP protocol. Provides local service with relaying. service smtp { disable = no id = smtp-loc port = 25 only_from = 192.168.0.0/16 127.0.0.1 socket_type = stream protocol = tcp wait = no env = RELAYCLIENT= passenv = user = qmaild flags = NOLIBWRAP server = /var/qmail/bin/tcp-env server_args = -R /var/qmail/bin/qmail-smtpd log_on_success = HOST DURATION PID log_on_failure = HOST nice = 0 instances = 60 cps = 25 5 rlimit_as = 2M } # default: on # description: Qmail SMTP service for delivering and receiving mail via \ # the SMTP protocol. Provide public service with relaying denied. service smtp { disable = no id = smtp-pub port = 25 no_access = 192.168.0.0/16 127.0.0.1 socket_type = stream protocol = tcp wait = no env = passenv = user = qmaild flags = NOLIBWRAP server = /var/qmail/bin/tcp-env server_args = -R /var/qmail/bin/qmail-smtpd log_on_success = HOST DURATION PID log_on_failure = HOST nice = 0 instances = 60 cps = 25 5 rlimit_as = 2M } Thanks for any comments, opinions, pointers, etc. -Tony Thedford -- The Poems, all three hundred of them, may be summed up in one of their phrases: "Let our thoughts be correct". -- Confucius From bbraun at synack.net Mon Aug 11 12:47:15 2003 From: bbraun at synack.net (Rob Braun) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Normal mode of operation? - Clarifying on 2nd Try.j In-Reply-To: <200308111322.20732@why-ask-why>; from tony@accesslab.com on Mon, Aug 11, 2003 at 01:22:20PM -0500 References: <200308111322.20732@why-ask-why> Message-ID: <20030811124715.V3321@lh.synack.net> Nope, that is not the intended mode of operation. You should probably be using the 'bind' directive instead of the only_from and no_access directives. Rob On Mon, Aug 11, 2003 at 01:22:20PM -0500, Tony Thedford wrote: > Sorry for double posting but the original was just too screwed up. > > ---- > I'm wondering if the way that I am running the xinetd server is using a > feature or programing accident. I didn't find any info or examples where > others are doing the same thing. > > I am setting up my config file to allow two different service id's to both use > the same port. One service id restricts the incoming connection addresses to > range A while the other service id restricts them to range B. Neither range > overlaps. Both services use the same protocol, TCP. It seems to work OK this > way but is this an intentional mode of operation by the designers? In other > words, is it semi-safe to assume that it will still work this way on the next > revision of the program? Another thought comes to mind - what will be the out > come in all cases if the ranges do overlap? Here are my two services in > question: > > # default: on > # description: Qmail SMTP service for delivering and receiving mail via \ > # the SMTP protocol. Provides local service with relaying. > service smtp > { > disable = no > id = smtp-loc > port = 25 > only_from = 192.168.0.0/16 127.0.0.1 > socket_type = stream > protocol = tcp > wait = no > env = RELAYCLIENT= > passenv = > user = qmaild > flags = NOLIBWRAP > server = /var/qmail/bin/tcp-env > server_args = -R /var/qmail/bin/qmail-smtpd > log_on_success = HOST DURATION PID > log_on_failure = HOST > nice = 0 > instances = 60 > cps = 25 5 > rlimit_as = 2M > } > > # default: on > # description: Qmail SMTP service for delivering and receiving mail via \ > # the SMTP protocol. Provide public service with relaying denied. > service smtp > { > disable = no > id = smtp-pub > port = 25 > no_access = 192.168.0.0/16 127.0.0.1 > socket_type = stream > protocol = tcp > wait = no > env = > passenv = > user = qmaild > flags = NOLIBWRAP > server = /var/qmail/bin/tcp-env > server_args = -R /var/qmail/bin/qmail-smtpd > log_on_success = HOST DURATION PID > log_on_failure = HOST > nice = 0 > instances = 60 > cps = 25 5 > rlimit_as = 2M > } > > Thanks for any comments, opinions, pointers, etc. > > -Tony Thedford > > -- > The Poems, all three hundred of them, may be summed up in one of their > phrases: > "Let our thoughts be correct". > -- Confucius > > _______________________________________________ > xinetd mailing list > xinetd@xinetd.org > http://www.xinetd.org/mailman/listinfo/xinetd From tony at accesslab.com Mon Aug 11 13:43:19 2003 From: tony at accesslab.com (Tony Thedford) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Normal mode of operation? - Clarifying on 2nd Try.j In-Reply-To: <20030811124715.V3321@lh.synack.net> References: <200308111322.20732@why-ask-why> <20030811124715.V3321@lh.synack.net> Message-ID: <200308111543.19777@why-ask-why> Unfortunately for me, the email server has only one interface address that is used by both public and local users. So, the 'bind' directive would require significant reconfiguration of things. What I was trying to accomplish by sharing the same port between to address ranges was to be able to assign particular environmental variables to each address range. Setting the 'RELAYCLIENT' variable for the local address range enabled relaying for the local users with Qmail's SMTP daemon. Not setting it blocked relaying for public users. I wish there was some way to do this using only xinetd, rather than having to install and use the tcpd server. It seems a shame to have to cascade these two just to conditionally set some environmental variables. Yuck. Oh well. Thanks for you help! -Tony On Monday 11 August 2003 2:47 pm, Rob Braun wrote: > Nope, that is not the intended mode of operation. > You should probably be using the 'bind' directive instead of > the only_from and no_access directives. > > Rob > From linux_4ever at yahoo.com Mon Aug 11 17:47:15 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Normal mode of operation? - Clarifying on 2nd Try.j In-Reply-To: <200308111543.19777@why-ask-why> Message-ID: <20030812004715.48469.qmail@web9607.mail.yahoo.com> Hello, >the email server has only one interface address >that is used by both public and local users. So, >the 'bind' directive would require significant >reconfiguration of things. >service smtp >{ > disable = no > id = smtp-loc > port = 25 > only_from = 192.168.0.0/16 127.0.0.1 Are you nat'ed? Since you are using a test address range rather than a public internet address, you should be able to give yourself another address. Changing the nat to point to the new address would be the least impact on people. If you aren't nat'ed then you still need a new address to get xinetd to work correctly. Most mail servers are too busy processing spam to be started by xinetd anyways. :) -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From tony at accesslab.com Mon Aug 11 18:13:27 2003 From: tony at accesslab.com (Tony Thedford) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Normal mode of operation? - Clarifying on 2nd Try.j In-Reply-To: <20030812004715.48469.qmail@web9607.mail.yahoo.com> References: <20030812004715.48469.qmail@web9607.mail.yahoo.com> Message-ID: <200308112013.27658@why-ask-why> On Monday 11 August 2003 7:47 pm, Steve G wrote: > Hello, > > Are you nat'ed? Since you are using a test address range > rather than a public internet address, you should be able > to give yourself another address. Changing the nat to point > to the new address would be the least impact on people. > Yes, I'm setting in a 'DMZ' subnet and nat'ed. That's a good idea. I could alias another address on the email server, direct the traffic at the firewall, use the 'bind' directive in xinetd to assign services on the two interfaces, and use one for public with no relaying and the other for private with relaying. There is a lot of anti-spam processing going on in this box. I want to use xinetd to limit the input connections/second to a level that will ensure that queued/delivery mail processing has time to complete and does not get over-whelmed by the incoming messages. The typical per message processing time is 3-to-10 seconds, so I'm not worried about any super-server latencies which will be relatively insignificant. But I am worried about the number of running processes getting too high if the incoming connection rate becomes too great. -Tony From xinetd at skycomp.ca Tue Aug 12 07:12:38 2003 From: xinetd at skycomp.ca (Serge Paquin) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Xinetd listening on weird ports Message-ID: <006201c360db$da9e0800$f702a8c0@becon.int> Hello, Running netstat -lp on a couple servers has me a little conserned. xinetd seems to be listening on a port that is not configured. The strange this is that when xinetd is restarted the port number changes. Is this known behaviour at all? If so how can I turn it off? Serge. From linux_4ever at yahoo.com Tue Aug 12 07:34:18 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Xinetd listening on weird ports In-Reply-To: <006201c360db$da9e0800$f702a8c0@becon.int> Message-ID: <20030812143418.21683.qmail@web9605.mail.yahoo.com> >xinetd seems to be listening on a port that is >not configured. Is this known behaviour at all? No, this is not a known behavior. What version are you running? How are you restarting xinetd? -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From ma+xi at dt.e-technik.uni-dortmund.de Tue Aug 12 10:07:18 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Xinetd listening on weird ports In-Reply-To: <006201c360db$da9e0800$f702a8c0@becon.int> (Serge Paquin's message of "Tue, 12 Aug 2003 10:12:38 -0400") References: <006201c360db$da9e0800$f702a8c0@becon.int> Message-ID: "Serge Paquin" writes: > Running netstat -lp on a couple servers has me a little conserned. > xinetd seems to be listening on a port that is not configured. The strange > this is that when xinetd is restarted the port number changes. Is this > known behaviour at all? If so how can I turn it off? Do you have a service configured with a port that isn't listed in /etc/services or with explicit port 0? -- Matthias Andree From marcodb at employees.org Wed Aug 13 12:22:40 2003 From: marcodb at employees.org (Marco Di Benedetto) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Running xinetd 2.3.12 Message-ID: <200308131922.h7DJMeWH024105@willers.employees.org> Hi all. A few days ago I've downloaded the sources of xinetd v2.3.12, and I'm having a few problems running it. First of all, the built executable. I'm running xinetd on a pentium-based linux box with a 2.4.17 kernel (sources built with the same). I was used to run xinetd 2.3.3, and I had an /etc/xinetd.conf (plus a /etc/xinetd.d/*) with that version of xinetd running a few services (telnet, ssh, ftp). Everything was fine with 2.3.3. I replaced the old xinetd binary with the new binary (didn't touch the conf files), but the new version seems to have problems with the following in the conf file: > defaults > { > [...] > log_type = SYSLOG authpriv > log_on_success = HOST PID > log_on_failure = HOST > } Removing those 3 lines the behavior changes. But let's start with those lines present... I don't get any warning about them if the '-d' option is enabled, but xinetd crashes immediately when it tries to show me something about them: > Linux(debug)# xinetd -syslog local7 -dontfork -reuse -d & > [1] 2623 > 03/8/13@09:52:20: DEBUG: 2623 {handle_includedir} Reading included configuration file: > /etc/xinetd.d/ftp [file=/etc/xinetd.conf] [line=38] > 03/8/13@09:52:20: DEBUG: 2623 {handle_includedir} Reading included configuration file: > /etc/xinetd.d/rexec [file=/etc/xinetd.d/rexec] [line=13] > 03/8/13@09:52:20: DEBUG: 2623 {handle_includedir} Reading included configuration file: > /etc/xinetd.d/rlogin [file=/etc/xinetd.d/rlogin] [line=15] > 03/8/13@09:52:20: DEBUG: 2623 {handle_includedir} Reading included configuration file: > /etc/xinetd.d/rsh [file=/etc/xinetd.d/rsh] [line=15] > 03/8/13@09:52:20: DEBUG: 2623 {handle_includedir} Reading included configuration file: > /etc/xinetd.d/ssh [file=/etc/xinetd.d/ssh] [line=16] > 03/8/13@09:52:20: DEBUG: 2623 {handle_includedir} Reading included configuration file: > /etc/xinetd.d/telnet [file=/etc/xinetd.d/telnet] [line=30] > Service defaults > Instances = 60 > Bind = All addresses. > Only from: All sites > No access: No blocked sites > Logging to syslog. Facility = authpriv, level = info > Log_on_success flags = HOST PID03/8/13@09:52:20: CRITICAL: 2623 {mem_fault_handler} > Address of fault: 46415254 > 03/8/13@09:52:20: CRITICAL: 2623 {mem_fault_handler} address is not mapped for object > 03/8/13@09:52:20: CRITICAL: 2623 {general_handler} (2623) Unexpected signal: 11 (Segmentation > fault) And then there's a SIGABRT and xinetd exits. If I leave those 3 lines, and start without the '-d' option, no service is enabled, and xinetd causes lots of SIGSEGV whenever I try to send a HUP or a USR1. Now, what happens if I remove those 3 lines? Well, the behavior improves, I can use the telnet service when I start xinetd, but HUP and USR1 are still not working. As soon as I use HUP, all the services get disabled, and telnet doesn't work anymore. Here is a wild log of my attempts after removing those three lines from the /etc/xinetd.conf (skip this log for some comments about building xinetd 2.3.12): > Linux(debug)# ps aux |grep xin > root 4075 0.0 0.0 1336 480 ttyS0 S 11:19 0:00 grep xin > Linux(debug)# xinetd -dontfork -reuse -d & > 03/8/13@11:19:59: DEBUG: 4076 {handle_includedir} Reading included > configuration file: /etc/xinet > d.d/ftp [file=/etc/xinetd.conf] [line=38] > 03/8/13@11:19:59: DEBUG: 4076 {handle_includedir} Reading included > configuration file: /etc/xinet > d.d/rexec [file=/etc/xinetd.d/rexec] [line=12] > 03/8/13@11:19:59: DEBUG: 4076 {handle_includedir} Reading included > configuration file: /etc/xinet > d.d/rlogin [file=/etc/xinetd.d/rlogin] [line=15] > 03/8/13@11:19:59: DEBUG: 4076 {handle_includedir} Reading included > configuration file: /etc/xinet > d.d/rsh [file=/etc/xinetd.d/rsh] [line=15] > 03/8/13@11:19:59: DEBUG: 4076 {handle_includedir} Reading included > configuration file: /etc/xinet > d.d/ssh [file=/etc/xinetd.d/ssh] [line=16] > 03/8/13@11:19:59: DEBUG: 4076 {handle_includedir} Reading included > configuration file: /etc/xinet > d.d/telnet [file=/etc/xinetd.d/telnet] [line=30] > Service defaults > Instances = 60 > Bind = All addresses. > Only from: All sites > No access: No blocked sites > No logging > > Service configuration: ftp > id = ftp > flags = IPv4 > socket_type = stream > Protocol (name,number) = (tcp,6) > port = 21 > wait = no > user = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /usr/sbin/in.ftpd > Server argv = in.ftpd > Only from: 127.0.0.0/255.0.0.0(NET) > No access: No blocked sites > No logging > > Service configuration: exec > id = exec > flags = IPv4 > socket_type = stream > Protocol (name,number) = (tcp,6) > port = 512 > wait = no > user = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /usr/sbin/in.rexecd > Server argv = in.rexecd > Only from: 127.0.0.0/255.0.0.0(NET) > No access: No blocked sites > No logging > > Service configuration: login > id = login > flags = IPv4 > socket_type = stream > Protocol (name,number) = (tcp,6) > port = 513 > wait = no > user = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /usr/sbin/in.rlogind > Server argv = in.rlogind > Only from: 127.0.0.0/255.0.0.0(NET) > No access: No blocked sites > No logging > > Service configuration: shell > id = shell > flags = IPv4 > socket_type = stream > Protocol (name,number) = (tcp,6) > port = 514 > wait = no > user = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /usr/sbin/in.rshd > Server argv = in.rshd > Only from: 127.0.0.0/255.0.0.0(NET) > No access: No blocked sites > No logging > > Service configuration: ssh > id = ssh > flags = IPv4 > socket_type = stream > Protocol (name,number) = (tcp,6) > port = 22 > wait = no > user = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /isan/sbin/sshd > Server argv = sshd -i > Only from: All sites > No access: No blocked sites > No logging > > Service configuration: telnet > id = telnet > flags = REUSE IPv4 > socket_type = stream > Protocol (name,number) = (tcp,6) > port = 23 > wait = no > user = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /usr/sbin/in.telnetd > Server argv = in.telnetd > Only from: All sites > No access: No blocked sites > No logging > > 03/8/13@11:19:59: DEBUG: 4076 {cnf_start_services} Started service: ftp > 03/8/13@11:19:59: DEBUG: 4076 {cnf_start_services} Started service: exec > 03/8/13@11:19:59: DEBUG: 4076 {cnf_start_services} Started service: login > 03/8/13@11:19:59: DEBUG: 4076 {cnf_start_services} Started service: shell > 03/8/13@11:19:59: DEBUG: 4076 {cnf_start_services} Started service: ssh > 03/8/13@11:19:59: DEBUG: 4076 {cnf_start_services} Started service: telnet > 03/8/13@11:20:03: DEBUG: 4076 {cnf_start_services} mask_max = 11, > services_started = 6 > 03/8/13@11:20:03: NOTICE: 4076 {main} xinetd Version 2.3.12 started with no > options compiled in. > 03/8/13@11:20:03: NOTICE: 4076 {main} Started working: 6 available services > 03/8/13@11:20:03: DEBUG: 4076 {main_loop} active_services = 6 > [1] 4076 > Linux(debug)# 03/8/13@11:20:46: DEBUG: 4076 {main_loop} select returned 1 > 03/8/13@11:20:46: DEBUG: 4076 {server_start} Starting service telnet > 03/8/13@11:20:46: DEBUG: 4076 {main_loop} active_services = 6 > 03/8/13@11:20:46: DEBUG: 4077 {exec_server} duping 12 > 03/8/13@11:20:51: DEBUG: 4076 {main_loop} active_services = 6 > 03/8/13@11:20:51: DEBUG: 4076 {main_loop} select returned 1 > 03/8/13@11:20:51: DEBUG: 4076 {check_pipe} Got signal 17 (Child exited) > 03/8/13@11:20:51: DEBUG: 4076 {child_exit} waitpid returned = 4077 > 03/8/13@11:20:51: DEBUG: 4076 {server_end} telnet server 4077 exited > 03/8/13@11:20:51: INFO: 4076 {conn_free} freeing connection > 03/8/13@11:20:51: DEBUG: 4076 {child_exit} waitpid returned = -1 > 03/8/13@11:20:51: DEBUG: 4076 {main_loop} active_services = 6 > > Linux(debug)# kill -HUP 4076 > 03/8/13@11:21:01: DEBUG: 4076 {main_loop} active_services = 6 > 03/8/13@11:21:01: DEBUG: 4076 {main_loop} select returned 1 > 03/8/13@11:21:01: DEBUG: 4076 {check_pipe} Got signal 1 (Hangup) > 03/8/13@11:21:01: NOTICE: 4076 {hard_reconfig} Starting reconfiguration > Service defaults > Bind = All addresses. > Only from: All sites > No access: No blocked sites > No logging > > 03/8/13@11:21:01: DEBUG: 4076 {deactivate} 4076 Service ftp deactivated > 03/8/13@11:21:01: NOTICE: 4076 {hard_reconfig} service ftp deactivated > 03/8/13@11:21:01: DEBUG: 4076 {svc_release} ref count of service ftp > dropped to 0 > 03/8/13@11:21:01: DEBUG: 4076 {deactivate} 4076 Service exec deactivated > 03/8/13@11:21:01: NOTICE: 4076 {hard_reconfig} service exec deactivated > 03/8/13@11:21:01: DEBUG: 4076 {svc_release} ref count of service exec > dropped to 0 > 03/8/13@11:21:01: DEBUG: 4076 {deactivate} 4076 Service login deactivated > 03/8/13@11:21:01: NOTICE: 4076 {hard_reconfig} service login deactivated > 03/8/13@11:21:01: DEBUG: 4076 {svc_release} ref count of service login > dropped to 0 > 03/8/13@11:21:01: DEBUG: 4076 {deactivate} 4076 Service shell deactivated > 03/8/13@11:21:01: NOTICE: 4076 {hard_reconfig} service shell deactivated > 03/8/13@11:21:01: DEBUG: 4076 {svc_release} ref count of service shell > dropped to 0 > 03/8/13@11:21:01: DEBUG: 4076 {deactivate} 4076 Service ssh deactivated > 03/8/13@11:21:01: NOTICE: 4076 {hard_reconfig} service ssh deactivated > 03/8/13@11:21:01: DEBUG: 4076 {svc_release} ref count of service ssh > dropped to 0 > 03/8/13@11:21:01: DEBUG: 4076 {deactivate} 4076 Service telnet deactivated > 03/8/13@11:21:01: NOTICE: 4076 {hard_reconfig} service telnet deactivated > 03/8/13@11:21:01: DEBUG: 4076 {svc_release} ref count of service telnet > dropped to 0 > 03/8/13@11:21:01: DEBUG: 4076 {cnf_start_services} mask_max = 11, > services_started = 0 > 03/8/13@11:21:01: NOTICE: 4076 {hard_reconfig} Reconfigured: new=0 old=0 > dropped=6 (services) > 03/8/13@11:21:01: DEBUG: 4076 {main_loop} active_services = 0 > Linux(debug)# kill -USR1 4076 > 03/8/13@11:21:10: DEBUG: 4076 {main_loop} active_services = 0 > 03/8/13@11:21:10: DEBUG: 4076 {main_loop} select returned 1 > 03/8/13@11:21:10: DEBUG: 4076 {check_pipe} Got signal 10 (User defined > signal 1) > 03/8/13@11:21:10: DEBUG: 4076 {dump_internal_state} Dumping State > 03/8/13@11:21:10: INFO: 4076 {dump_internal_state} generated state dump in > file /var/run/xinetd.d > ump > 03/8/13@11:21:10: DEBUG: 4076 {main_loop} active_services = 0 > Linux(debug)# cat /var/run/xinetd.dump > INTERNAL STATE DUMP: xinetd Version 2.3.12 > Current time: Wed Aug 13 11:21:10 2003 > > Services + defaults: > Service defaults > Bind = All addresses. > Only from: All sites > No access: No blocked sites > No logging > Server table dump: > > Retry table dump: > > Socket mask: 4 > mask_max = 11 > Open descriptors (not in socket mask): 0 1 2 3 5 6 > > active_services = 0 > available_services = 0 > descriptors_free = 1016 > running_servers = 0 > Logging service = enabled > > max_descriptors = 1024 > process_limit = 0 > config_file = /etc/xinetd.conf > debug_fd = 3 > > END OF DUMP > > Linux(debug)# kill -TERM 4076 > 03/8/13@11:24:02: DEBUG: 4076 {main_loop} active_services = 0 > 03/8/13@11:24:02: DEBUG: 4076 {main_loop} select returned 1 > 03/8/13@11:24:02: DEBUG: 4076 {check_pipe} Got signal 15 (Terminated) > 03/8/13@11:24:02: WARNING: 4076 {quit_program} Exiting... > Linux(debug)# xinetd -syslog local7 -dontfork -reuse -d & > [1] 4100 > 03/8/13@11:24:29: DEBUG: 4100 {handle_includedir} Reading included > configuration file: /etc/xinet > d.d/ftp [file=/etc/xinetd.conf] [line=38] > 03/8/13@11:24:29: DEBUG: 4100 {handle_includedir} Reading included > configuration file: /etc/xinet > d.d/rexec [file=/etc/xinetd.d/rexec] [line=12] > 03/8/13@11:24:29: DEBUG: 4100 {handle_includedir} Reading included > configuration file: /etc/xinet > d.d/rlogin [file=/etc/xinetd.d/rlogin] [line=15] > 03/8/13@11:24:29: DEBUG: 4100 {handle_includedir} Reading included > configuration file: /etc/xinet > d.d/rsh [file=/etc/xinetd.d/rsh] [line=15] > 03/8/13@11:24:29: DEBUG: 4100 {handle_includedir} Reading included > configuration file: /etc/xinet > d.d/ssh [file=/etc/xinetd.d/ssh] [line=16] > 03/8/13@11:24:29: DEBUG: 4100 {handle_includedir} Reading included > configuration file: /etc/xinet > d.d/telnet [file=/etc/xinetd.d/telnet] [line=30] > Service defaults > Instances = 60 > Bind = All addresses. > Only from: All sites > No access: No blocked sites > No logging > > Service configuration: ftp > id = ftp > flags = IPv4 > socket_type = stream > Protocol (name,number) = (tcp,6) > port = 21 > wait = no > user = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /usr/sbin/in.ftpd > Server argv = in.ftpd > Only from: 127.0.0.0/255.0.0.0(NET) > No access: No blocked sites > No logging > > Service configuration: exec > id = exec > flags = IPv4 > socket_type = stream > Protocol (name,number) = (tcp,6) > port = 512 > wait = no > user = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /usr/sbin/in.rexecd > Server argv = in.rexecd > Only from: 127.0.0.0/255.0.0.0(NET) > No access: No blocked sites > No logging > > Service configuration: login > id = login > flags = IPv4 > socket_type = stream > Protocol (name,number) = (tcp,6) > port = 513 > wait = no > user = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /usr/sbin/in.rlogind > Server argv = in.rlogind > Only from: 127.0.0.0/255.0.0.0(NET) > No access: No blocked sites > No logging > > Service configuration: shell > id = shell > flags = IPv4 > socket_type = stream > Protocol (name,number) = (tcp,6) > port = 514 > wait = no > user = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /usr/sbin/in.rshd > Server argv = in.rshd > Only from: 127.0.0.0/255.0.0.0(NET) > No access: No blocked sites > No logging > > Service configuration: ssh > id = ssh > flags = IPv4 > socket_type = stream > Protocol (name,number) = (tcp,6) > port = 22 > wait = no > user = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /isan/sbin/sshd > Server argv = sshd -i > Only from: All sites > No access: No blocked sites > No logging > > Service configuration: telnet > id = telnet > flags = REUSE IPv4 > socket_type = stream > Protocol (name,number) = (tcp,6) > port = 23 > wait = no > user = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /usr/sbin/in.telnetd > Server argv = in.telnetd > Only from: All sites > No access: No blocked sites > No logging > > 03/8/13@11:24:29: DEBUG: 4100 {cnf_start_services} Started service: ftp > 03/8/13@11:24:29: DEBUG: 4100 {cnf_start_services} Started service: exec > 03/8/13@11:24:29: DEBUG: 4100 {cnf_start_services} Started service: login > 03/8/13@11:24:29: DEBUG: 4100 {cnf_start_services} Started service: shell > 03/8/13@11:24:29: DEBUG: 4100 {cnf_start_services} Started service: ssh > 03/8/13@11:24:29: DEBUG: 4100 {cnf_start_services} Started service: telnet > 03/8/13@11:24:33: DEBUG: 4100 {cnf_start_services} mask_max = 11, > services_started = 6 > 03/8/13@11:24:33: NOTICE: 4100 {main} xinetd Version 2.3.12 started with no > options compiled in. > 03/8/13@11:24:33: NOTICE: 4100 {main} Started working: 6 available services > 03/8/13@11:24:33: DEBUG: 4100 {main_loop} active_services = 6 > Linux(debug)# rm /var/run/xinetd.dump > Linux(debug)# kill -USR1 410003/8/13@11:24:56: DEBUG: 4100 {main_loop} > select returned 1 > 03/8/13@11:24:56: DEBUG: 4100 {server_start} Starting service telnet > 03/8/13@11:24:56: DEBUG: 4100 {main_loop} active_services = 6 > 03/8/13@11:24:56: DEBUG: 4102 {exec_server} duping 12 > > Linux(debug)# 03/8/13@11:25:00: DEBUG: 4100 {main_loop} active_services = 6 > 03/8/13@11:25:00: DEBUG: 4100 {main_loop} select returned 1 > 03/8/13@11:25:00: DEBUG: 4100 {check_pipe} Got signal 10 (User defined > signal 1) > 03/8/13@11:25:00: DEBUG: 4100 {dump_internal_state} Dumping State > 03/8/13@11:25:00: ERROR: 4100 {dump_internal_state} failed setting up sio > buffering: Bad file des > criptor (errno = 9) fd:12 > 03/8/13@11:25:00: DEBUG: 4100 {main_loop} active_services = 6 > cat /var/run/xinetd.dump > Linux(debug)# cat /var/run/xinetd.dump > Linux(debug)# kill -USR1 4100 > Linux(debug)# 03/8/13@11:25:41: DEBUG: 4100 {main_loop} active_services = 6 > 03/8/13@11:25:41: DEBUG: 4100 {main_loop} select returned 1 > 03/8/13@11:25:41: DEBUG: 4100 {check_pipe} Got signal 10 (User defined > signal 1) > 03/8/13@11:25:41: DEBUG: 4100 {dump_internal_state} Dumping State > 03/8/13@11:25:41: CRITICAL: 4100 {mem_fault_handler} Address of fault: c > 03/8/13@11:25:41: CRITICAL: 4100 {mem_fault_handler} address is not mapped > for object > 03/8/13@11:25:41: CRITICAL: 4100 {general_handler} (4100) Unexpected > signal: 11 (Segmentation fau > lt) > > [1]+ Aborted (core dumped) xinetd -syslog local7 -dontfork > -reuse -d > Linux(debug)# xinetd -dontfork -reuse -d & > [1] 4110 > 03/8/13@11:26:03: DEBUG: 4110 {handle_includedir} Reading included > configuration file: /etc/xinet > d.d/ftp [file=/etc/xinetd.conf] [line=38] ser = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /usr/sbin/in.rexecd > Server argv = in.rexecd > Only from: 127.0.0.0/255.0.0.0(NET) > No access: No blocked sites > No logging > > Service configuration: login > id = login > flags = IPv4 > socket_type = stream > Protocol (name,number) = (tcp,6) > port = 513 > wait = no > user = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /usr/sbin/in.rlogind mask_max = 11, > services_started = 6 > 03/8/13@11:26:07: NOTICE: 4110 {main} xinetd Version 2.3.12 started with no > options compiled in. > 03/8/13@11:26:07: NOTICE: 4110 {main} Started working: 6 available services > 03/8/13@11:26:07: DEBUG: 4110 {main_loop} active_services = 6 > Linux(debug)# 03/8/13@11:26:12: DEBUG: 4110 {main_loop} select returned 1 > 03/8/13@11:26:12: DEBUG: 4110 {server_start} Starting service telnet > 03/8/13@11:26:12: DEBUG: 4110 {main_loop} active_services = 6 > 03/8/13@11:26:12: DEBUG: 4111 {exec_server} duping 12 > > Linux(debug)# kill -USR1 4111 > Linux(debug)# 03/8/13@11:26:24: DEBUG: 4110 {main_loop} active_services = 6 > 03/8/13@11:26:24: DEBUG: 4110 {main_loop} select returned 1 > > Linux(debug)# kill -USR1 4111 > Linux(debug)# 03/8/13@11:26:24: DEBUG: 4110 {main_loop} active_services = 6 > 03/8/13@11:26:24: DEBUG: 4110 {main_loop} select returned 1 > 03/8/13@11:26:24: DEBUG: 4110 {check_pipe} Got signal 17 (Child exited) > 03/8/13@11:26:24: DEBUG: 4110 {child_exit} waitpid returned = 4111 > 03/8/13@11:26:24: DEBUG: 4110 {server_end} telnet server 4111 died > 03/8/13@11:26:24: INFO: 4110 {conn_free} freeing connection > 03/8/13@11:26:24: DEBUG: 4110 {child_exit} waitpid returned = -1 > 03/8/13@11:26:24: DEBUG: 4110 {main_loop} active_services = 6 > > Linux(debug)# cat /var/run/xinetd.dump > Linux(debug)# kill -USR1 4110 > 03/8/13@11:26:52: DEBUG: 4110 {main_loop} active_services = 6 > 03/8/13@11:26:52: DEBUG: 4110 {main_loop} select returned 1 > 03/8/13@11:26:52: DEBUG: 4110 {check_pipe} Got signal 10 (User defined > signal 1) > 03/8/13@11:26:52: DEBUG: 4110 {dump_internal_state} Dumping State > 03/8/13@11:26:52: ERROR: 4110 {dump_internal_state} failed setting up sio > buffering: Bad file des > criptor (errno = 9) fd:12 > 03/8/13@11:26:52: DEBUG: 4110 {main_loop} active_services = 6 > Linux(debug)# 03/8/13@11:27:18: DEBUG: 4110 {main_loop} select returned 1 > 03/8/13@11:27:18: DEBUG: 4110 {server_start} Starting service telnet > 03/8/13@11:27:18: DEBUG: 4110 {main_loop} active_services = 6 > 03/8/13@11:27:18: DEBUG: 4114 {exec_server} duping 12 > 03/8/13@11:27:21: DEBUG: 4110 {main_loop} active_services = 6 > 03/8/13@11:27:21: DEBUG: 4110 {main_loop} select returned 1 > 03/8/13@11:27:21: DEBUG: 4110 {check_pipe} Got signal 17 (Child exited) > 03/8/13@11:27:21: DEBUG: 4110 {child_exit} waitpid returned = 4114 > 03/8/13@11:27:21: DEBUG: 4110 {server_end} telnet server 4114 exited > 03/8/13@11:27:21: INFO: 4110 {conn_free} freeing connection > 03/8/13@11:27:21: DEBUG: 4110 {child_exit} waitpid returned = -1 > 03/8/13@11:27:21: DEBUG: 4110 {main_loop} active_services = 6 I wonder if anybody else is getting a similar behavior... how much incpompatibility should I expect between 2.3.3 and 2.3.12 wrt configuration files? Then, building the sources. I'm building on a pentium-based linux box. The sources do build, but only if the gcc '-Wall -Werror' options are not enabled. With those flags enabled, the configure.in script doesn't detect the presence of 'memcpy' and of 'struct sockaddr_storage', causing a bad behavior at build time. Assuming I run 'configure' without the '-Wall -Werror' options and then I try to enable them later at build time, I just get one simple warning: > i686-pc-linux-gnu-gcc -pipe -g -O2 -Wall -Werror \ > -I../libs/include /src/xinetd/xinetd-2.3.12/xinetd/itox.c -o itox \ > -L../libs/lib -lsio -lmisc -lxlog -lstr -lpset -lportable -lm -lcrypt > cc1: warnings being treated as errors > /src/xinetd/xinetd-2.3.12/xinetd/itox.c:8: warning: `RCSid' defined but not used > make[1]: *** [itox] Error 1 > make[1]: Leaving directory `/src/xinetd/xinetd-2.3.12/xinetd' > make: *** [makeprog] Error 2 Ignoring completely the '-Wall -Werror' options, another nice to have would be an 'all' target in the Makefile. xinetd uses a 'build' target as its default target, but it doesn't have an 'all' target. The reason why I'm looking for an 'all' target is because I need to integrate the build of xinetd with a build environment based on automake. xinetd is a subdir of a bigger automake-based tree, and using "SUBDIRS" with automake generates recursion in subdirectories with a command like 'make all'. Anyway, it's not too complicated to add the 'all' target by myself in the xinetd's top level Makefile.in. :-) Last, is 'linux/time.h' required? configure.in is checking for 'linux/time.h', it doesn't find a working version in my environment (not sure why), but then the build succeeds: > checking linux/time.h usability... no > checking linux/time.h presence... yes > configure: WARNING: linux/time.h: present but cannot be compiled > configure: WARNING: linux/time.h: check for missing prerequisite headers? > configure: WARNING: linux/time.h: proceeding with the preprocessor's result > checking for linux/time.h... yes Regards! Marco Di Benedettoer automake-based tree, and using "SUBDIRS" with automake generates recursion in subdirectories with a command like 'make all'. Anyway, it's not too complicated to add the 'all' target by myself in the xinetd's top level Makefile.in. :-) Last, is 'linux/time.h' required? configure.in is checking for 'linux/time.h', it doesn't find a working version in my environment (not sure why), but then the build succeeds: > checking linux/time.h usability... no > checking linux/time.h presence... yes > configure: WARNING: linux/time.h: present but cannot be compiled > configure: WARNING: linux/time.h: check for missing prerequisite headers? > configure: WARNING: linux/time.h: proceeding with the preprocessor's result > checking for linux/time.h... yes Regards! Marco Di Benedetto From ma+xi at dt.e-technik.uni-dortmund.de Wed Aug 13 17:22:45 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Running xinetd 2.3.12 In-Reply-To: <200308131922.h7DJMeWH024105@willers.employees.org> (Marco Di Benedetto's message of "Wed, 13 Aug 2003 12:22:40 -0700 (PDT)") References: <200308131922.h7DJMeWH024105@willers.employees.org> Message-ID: Marco Di Benedetto writes: > Hi all. > A few days ago I've downloaded the sources of xinetd v2.3.12, and > I'm having a few problems running it. > > First of all, the built executable. I'm running xinetd on a pentium-based > linux box with a 2.4.17 kernel (sources built with the same). You know that this kernel has several exploitable bugs (DoS and information leaks)? Update unless some vendor applied all available security fixes (some as fresh as a couple of days old). Other than that, can you run xinetd under gdb and obtain a stack backtrace when it sees SIGSEGV? -- Matthias Andree From linux_4ever at yahoo.com Wed Aug 13 20:08:01 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Running xinetd 2.3.12 In-Reply-To: <200308131922.h7DJMeWH024105@willers.employees.org> Message-ID: <20030814030801.55811.qmail@web9604.mail.yahoo.com> You really put a lot into that e-mail and its too big to respond to everything at once. >Last, is 'linux/time.h' required? configure.in is checking This is a bug in the xinetd build. An applications should not get that intimate with the OS. I think it was put there back around the 2.0 kernel 2.2 transition to detect a libc 5 problem. We all run glibc 2 or higher now so this hack should be deleted. Besides, if anyone was running a libc 5 system, xinetd would never compile with all the IPv6 stuff. The short summary of your whole experience. I am running a version of xinetd without the final 120K sized patch...so that would be pre-2.3.12 cvs. I cannot duplicate the problem based on what you've given me. I tried setting things up like you have and I don't get segfaults. As Matthias said, it would be helpful if you can track down the addresses with gdb or valgrind. With a line number, I can have a patch for you quickly. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From paul at hypervision.be Thu Aug 14 03:25:37 2003 From: paul at hypervision.be (Paul Herbosch) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] starting a ssh tunnel with xinetd Message-ID: Hi all, I'm trying to automatically open up a ssh tunnel to a W2K Terminal Server using xinetd. so far, all attempts to let xinetd start the tunnel, failed. well, xinetd opens up the tunnel allright, but still my rdesktop client fails to connect. when I open the tunnel by hand, everything works great. "ssh -g -T -N -x -i /home/sshunnel/.ssh/id_rsa -L3389:[remote w2k server]:3389 sshunnel@[remote linux server]" I tell my windows rdesktop client to connect to the linux box that initiated the tunnel, and off I go. now, here's my /etc/xinetd.d/rdesktop-tunnel file: service rdesktop-tunnel { disable = no socket_type = stream protocol = tcp wait = no user = sshunnel server = /usr/bin/ssh server_args = -g -T -N -x -i /home/sshunnel/.ssh/id_rsa -L3389:[remote w2k server]:3389 sshunnel@[remote linux server] } I defined a services in /etc/services rdesktop-tunnel 3389/tcp rdesktop-tunnel 3389/udp if a I start my rdesktop-client, I can see xinetd starting the ssh tunnel. the remote linux server has a ssh session for user sshunnel running, but my rdesktop cient throws an error: "Because of a protocol error detected at the client (code 0x1104), this session will be disconnected. Please try connecting to the remote computer again." If I change the wait parameter to yes in /etc/xinetd.d/rdesktop-tunnel i get a time-out. apparantly, xinetd fiddles with tcp/3389 for some reason ... Any help would be greatly appreciated. Greetz, Paul From linux_4ever at yahoo.com Thu Aug 14 06:20:10 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] starting a ssh tunnel with xinetd In-Reply-To: Message-ID: <20030814132010.22791.qmail@web9604.mail.yahoo.com> >"Because of a protocol error detected at the client (code >0x1104), this session will be disconnected. Please try >connecting to the remote computer again." What I've had to do in the past is setup a ssh tunnel at boot time that stays up. Then use the redirect function of xinetd to redirect traffic from the port xinetd listens on to the tunnel. I couldn't get it working easily the way you are trying. I also didn't have a lot of time to do it. You may also want to look at stunnel. It can be run off of xinetd or standalone. It was designed to do encrypted tunneling. I've done a lot of code reviews and submitted a lot of patches to the stunnel team and it is stable and secure as long as you are running 3.25 or 4.04. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From marcodb at employees.org Thu Aug 14 12:26:16 2003 From: marcodb at employees.org (Marco Di Benedetto) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Running xinetd 2.3.12 Message-ID: <200308141926.h7EJQGpj014107@willers.employees.org> I did some more testing, and I'm now realizing the problem happens only if I have at least 6 services in /etc/xinetd.d. I tried to remove a random number of services from /etc/xinetd.d, and as long as I have less than 6 services in /etc/xinetd.d, everything works just fine. I don't know what would happen with more than 6 services (I don't have a 7th service to enable), but I know that this happens with exactly 6 services: - start xinetd, everything looks ok. - send HUP a first time. All the services get deactivated. - send HUP a second time -> SIGSEGV. The core (when I compile xinetd with the -DDEBUG option) goes to the root directory, even though I did start xinetd in a different place (some call to chdir() in the code?). The cmdline is "./xinetd -dontfork -reuse -d &", and here is the backtrace of one case: > Program terminated with signal 11, Segmentation fault. > Reading symbols from /lib/libm.so.6...done. > Loaded symbols for /lib/libm.so.6 > Reading symbols from /lib/libcrypt.so.1...done. > Loaded symbols for /lib/libcrypt.so.1 > Reading symbols from /lib/libc.so.6...done. > Loaded symbols for /lib/libc.so.6 > Reading symbols from /lib/ld-linux.so.2...done. > Loaded symbols for /lib/ld-linux.so.2 > Reading symbols from /lib/libnss_files.so.2...done. > Loaded symbols for /lib/libnss_files.so.2 > Reading symbols from /lib/libnss_dns.so.2...done. > Loaded symbols for /lib/libnss_dns.so.2 > Reading symbols from /lib/libresolv.so.2...done. > Loaded symbols for /lib/libresolv.so.2 > #0 0x2ab86c87 in malloc () from /lib/libc.so.6 > (gdb) where > #0 0x2ab86c87 in malloc () from /lib/libc.so.6 > #1 0x2ab86a26 in malloc () from /lib/libc.so.6 > #2 0x08065368 in setup_read_buffer (idp=0x8072950, buf_size=8192) > at siosup.c:351 > #3 0x08064fd1 in __sio_switch (idp=0x8072950, fd=6) at siosup.c:211 > #4 0x0806461d in Srdline (fd=6) at sio.c:169 > #5 0x080562c3 in next_line (fd=6) at parsesup.c:32 > #6 0x08055510 in find_next_entry (fd=6, snamep=0x7ffff760) at parse.c:304 > #7 0x080552e0 in parse_conf_file (fd=6, confp=0x7ffff92c, > filename=0x806980c "/etc/xinetd.conf") at parse.c:221 > #8 0x080500ac in get_conf (fd=6, confp=0x7ffff92c) at confparse.c:833 > #9 0x08050110 in cnf_get (confp=0x7ffff92c) at confparse.c:859 > #10 0x08058d7e in hard_reconfig () at reconfig.c:70 > #11 0x0805e4fc in check_pipe () at signals.c:558 > #12 0x0805493f in main_loop () at main.c:153 > #13 0x08054796 in main (argc=4, argv=0x7ffffaa4) at main.c:88 > #14 0x2ab31819 in __libc_start_main () from /lib/libc.so.6 > (gdb) Unfortunately I don't think a backtrace like this can give you much info about what's going on. :-( Here is the log of the console: > Linux(debug)# ./xinetd -dontfork -reuse -d & > [1] 3656 > 04/9/3@19:28:03: DEBUG: 3656 {handle_includedir} Reading included configuration file: /etc/xinetd.d/ftp [file=/etc/xinetd.conf] [line=38] > 04/9/3@19:28:03: DEBUG: 3656 {handle_includedir} Reading included configuration file: /etc/xinetd.d/rexec [file=/etc/xinetd.d/rexec] [line=12] > 04/9/3@19:28:03: DEBUG: 3656 {handle_includedir} Reading included configuration file: /etc/xinetd.d/rlogin [file=/etc/xinetd.d/rlogin] [line=15] > 04/9/3@19:28:03: DEBUG: 3656 {handle_includedir} Reading included configuration file: /etc/xinetd.d/rsh [file=/etc/xinetd.d/rsh] [line=15] > 04/9/3@19:28:03: DEBUG: 3656 {handle_includedir} Reading included configuration file: /etc/xinetd.d/ssh [file=/etc/xinetd.d/ssh] [line=16] > 04/9/3@19:28:03: DEBUG: 3656 {handle_includedir} Reading included configuration file: /etc/xinetd.d/telnet [file=/etc/xinetd.d/telnet] [line=30] > Service defaults > Instances = 60 > Bind = All addresses. > Only from: All sites > No access: No blocked sites > No logging > > Service configuration: ftp > id = ftp > flags = IPv4 > socket_type = stream > Protocol (name,number) = (tcp,6) > port = 21 > wait = no > user = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /usr/sbin/in.ftpd > Server argv = in.ftpd > Only from: 127.0.0.0/255.0.0.0(NET) > No access: No blocked sites > No logging > > Service configuration: exec > id = exec > flags = IPv4 > socket_type = stream > Protocol (name,number) = (tcp,6) > port = 512 > wait = no > user = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /usr/sbin/in.rexecd > Server argv = in.rexecd > Only from: 127.0.0.0/255.0.0.0(NET) > No access: No blocked sites > No logging > > Service configuration: login > id = login > flags = IPv4 > socket_type = stream > Protocol (name,number) = (tcp,6) > port = 513 > wait = no > user = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /usr/sbin/in.rlogind > Server argv = in.rlogind > Only from: 127.0.0.0/255.0.0.0(NET) > No access: No blocked sites > No logging > > Service configuration: shell > id = shell > flags = IPv4 > socket_type = stream > Protocol (name,number) = (tcp,6) > port = 514 > wait = no > user = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /usr/sbin/in.rshd > Server argv = in.rshd > Only from: 127.0.0.0/255.0.0.0(NET) > No access: No blocked sites > No logging > > Service configuration: ssh > id = ssh > flags = IPv4 > socket_type = stream > Protocol (name,number) = (tcp,6) > port = 22 > wait = no > user = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /isan/sbin/sshd > Server argv = sshd -i > Only from: All sites > No access: No blocked sites > No logging > > Service configuration: telnet > id = telnet > flags = REUSE IPv4 > socket_type = stream > Protocol (name,number) = (tcp,6) > port = 23 > wait = no > user = 0 > Groups = no > PER_SOURCE = -1 > Bind = All addresses. > Server = /usr/sbin/in.telnetd > Server argv = in.telnetd > Only from: All sites > No access: No blocked sites > No logging > > 04/9/3@19:28:03: DEBUG: 3656 {cnf_start_services} Started service: ftp > 04/9/3@19:28:03: DEBUG: 3656 {cnf_start_services} Started service: exec > 04/9/3@19:28:03: DEBUG: 3656 {cnf_start_services} Started service: login > 04/9/3@19:28:03: DEBUG: 3656 {cnf_start_services} Started service: shell > 04/9/3@19:28:03: DEBUG: 3656 {cnf_start_services} Started service: ssh > 04/9/3@19:28:03: DEBUG: 3656 {cnf_start_services} Started service: telnet > 04/9/3@19:28:07: DEBUG: 3656 {cnf_start_services} mask_max = 11, services_started = 6 > 04/9/3@19:28:07: NOTICE: 3656 {main} xinetd Version 2.3.12 started with no options compiled in. > 04/9/3@19:28:07: NOTICE: 3656 {main} Started working: 6 available services > 04/9/3@19:28:07: DEBUG: 3656 {main_loop} active_services = 6 > Linux(debug)# kill -HUP 3656 > Linux(debug)# 04/9/3@19:28:12: DEBUG: 3656 {main_loop} active_services = 6 > 04/9/3@19:28:12: DEBUG: 3656 {main_loop} select returned 1 > 04/9/3@19:28:12: DEBUG: 3656 {check_pipe} Got signal 1 (Hangup) > 04/9/3@19:28:12: NOTICE: 3656 {hard_reconfig} Starting reconfiguration > Service defaults > Bind = All addresses. > Only from: All sites > No access: No blocked sites > No logging > > 04/9/3@19:28:12: DEBUG: 3656 {deactivate} 3656 Service ftp deactivated > 04/9/3@19:28:12: NOTICE: 3656 {hard_reconfig} service ftp deactivated > 04/9/3@19:28:12: DEBUG: 3656 {svc_release} ref count of service ftp dropped to 0 > 04/9/3@19:28:12: DEBUG: 3656 {deactivate} 3656 Service exec deactivated > 04/9/3@19:28:12: NOTICE: 3656 {hard_reconfig} service exec deactivated > 04/9/3@19:28:12: DEBUG: 3656 {svc_release} ref count of service exec dropped to 0 > 04/9/3@19:28:12: DEBUG: 3656 {deactivate} 3656 Service login deactivated > 04/9/3@19:28:12: NOTICE: 3656 {hard_reconfig} service login deactivated > 04/9/3@19:28:12: DEBUG: 3656 {svc_release} ref count of service login dropped to 0 > 04/9/3@19:28:12: DEBUG: 3656 {deactivate} 3656 Service shell deactivated > 04/9/3@19:28:12: NOTICE: 3656 {hard_reconfig} service shell deactivated > 04/9/3@19:28:12: DEBUG: 3656 {svc_release} ref count of service shell dropped to 0 > 04/9/3@19:28:12: DEBUG: 3656 {deactivate} 3656 Service ssh deactivated > 04/9/3@19:28:12: NOTICE: 3656 {hard_reconfig} service ssh deactivated > 04/9/3@19:28:12: DEBUG: 3656 {svc_release} ref count of service ssh dropped to 0 > 04/9/3@19:28:12: DEBUG: 3656 {deactivate} 3656 Service telnet deactivated > 04/9/3@19:28:12: NOTICE: 3656 {hard_reconfig} service telnet deactivated > 04/9/3@19:28:12: DEBUG: 3656 {svc_release} ref count of service telnet dropped to 0 > 04/9/3@19:28:12: DEBUG: 3656 {cnf_start_services} mask_max = 11, services_started = 0 > 04/9/3@19:28:12: NOTICE: 3656 {hard_reconfig} Reconfigured: new=0 old=0 dropped=6 (services) > 04/9/3@19:28:12: DEBUG: 3656 {main_loop} active_services = 0 > kill -HUP 3656 > Linux(debug)# 04/9/3@19:28:19: DEBUG: 3656 {main_loop} active_services = 0 > 04/9/3@19:28:19: DEBUG: 3656 {main_loop} select returned 1 > 04/9/3@19:28:19: DEBUG: 3656 {check_pipe} Got signal 1 (Hangup) > 04/9/3@19:28:19: NOTICE: 3656 {hard_reconfig} Starting reconfiguration > > [1]+ Segmentation fault (core dumped) ./xinetd -dontfork -reuse -d > Linux(debug)# I know my e-mail are too long, but as I've mentioned in my last e-mail, there's another crash I get in a different case, let me give you the backtrace for that as well. I get it when the following options are in use: defaults { instances = 60 log_type = SYSLOG authpriv log_on_success = HOST PID log_on_failure = HOST } In this case the core is in the diractory where I start xinetd. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /lib/libm.so.6...done. > Loaded symbols for /lib/libm.so.6 > Reading symbols from /lib/libcrypt.so.1...done. > Loaded symbols for /lib/libcrypt.so.1 > Reading symbols from /lib/libc.so.6...done. > Loaded symbols for /lib/libc.so.6 > Reading symbols from /lib/ld-linux.so.2...done. > Loaded symbols for /lib/ld-linux.so.2 > Reading symbols from /lib/libnss_files.so.2...done. > Loaded symbols for /lib/libnss_files.so.2 > Reading symbols from /lib/libnss_dns.so.2...done. > Loaded symbols for /lib/libnss_dns.so.2 > Reading symbols from /lib/libresolv.so.2...done. > Loaded symbols for /lib/libresolv.so.2 > #0 0x2ab8c213 in strlen () from /lib/libc.so.6 > (gdb) where > #0 0x2ab8c213 in strlen () from /lib/libc.so.6 > #1 0x08063827 in __sio_converter (odp=0x80728cc, fd=3, fmt=0x806c387 "s", > ap=0x7ffff4e0) at sprint.c:579 > #2 0x08062c32 in Sprint (fd=3, fmt=0x806c385 " %s") at sprint.c:137 > #3 0x0805a510 in dump_log_data (fd=3, scp=0x8072618, tab_level=1) > at sconf.c:211 > #4 0x0805b0e3 in sc_dump (scp=0x8072618, fd=3, tab_level=0, is_defaults=1) > at sconf.c:426 > #5 0x0804deba in cnf_dump (confp=0x7ffffa14, fd=3) at conf.c:70 > #6 0x08050496 in cnf_get (confp=0x7ffffa14) at confparse.c:942 > #7 0x08052029 in init_services () at init.c:361 > #8 0x080546f5 in main (argc=4, argv=0x7ffffaa4) at main.c:50 > #9 0x2ab31819 in __libc_start_main () from /lib/libc.so.6 > (gdb) This is probably much easier to fix than the other one... To give some more context, this is happening right in the beginning if the '-d' option is used: > Linux(debug)# ./xinetd -dontfork -reuse -d & > [1] 3505 > 04/9/3@19:02:39: DEBUG: 3505 {handle_includedir} Reading included configuration file: /etc/xinetd.d/ftp [file=/etc/xinetd.conf] [line=38] > 04/9/3@19:02:39: DEBUG: 3505 {handle_includedir} Reading included configuration file: /etc/xinetd.d/rexec [file=/etc/xinetd.d/rexec] [line=13] > 04/9/3@19:02:39: DEBUG: 3505 {handle_includedir} Reading included configuration file: /etc/xinetd.d/rlogin [file=/etc/xinetd.d/rlogin] [line=15] > 04/9/3@19:02:39: DEBUG: 3505 {handle_includedir} Reading included configuration file: /etc/xinetd.d/rsh [file=/etc/xinetd.d/rsh] [line=15] > 04/9/3@19:02:39: DEBUG: 3505 {handle_includedir} Reading included configuration file: /etc/xinetd.d/ssh [file=/etc/xinetd.d/ssh] [line=16] > 04/9/3@19:02:39: DEBUG: 3505 {handle_includedir} Reading included configuration file: /etc/xinetd.d/telnet [file=/etc/xinetd.d/telnet] [line=30] > Service defaults > Instances = 60 > Bind = All addresses. > Only from: All sites > No access: No blocked sites > Logging to syslog. Facility = authpriv, level = info > Linux(debug)# > [1]+ Segmentation fault (core dumped) ./xinetd -dontfork -reuse -d > Linux(debug)# Ok, this is all I have. Are you seeing a similar behavior with any random 6 services? Otherwise you can give me any private build of xinetd with extra instrumentation, I can run it and send you back a core... Regards. Marco Matthias Andree wrote: > > Marco Di Benedetto writes: > > > Hi all. > > A few days ago I've downloaded the sources of xinetd v2.3.12, and > > I'm having a few problems running it. > > > > First of all, the built executable. I'm running xinetd on a pentium-based > > linux box with a 2.4.17 kernel (sources built with the same). > > You know that this kernel has several exploitable bugs (DoS and > information leaks)? Update unless some vendor applied all available > security fixes (some as fresh as a couple of days old). > > Other than that, can you run xinetd under gdb and obtain a stack > backtrace when it sees SIGSEGV? > > -- > Matthias Andree > _______________________________________________ > xinetd mailing list > xinetd@xinetd.org > http://www.xinetd.org/mailman/listinfo/xinetd From linux_4ever at yahoo.com Thu Aug 14 13:12:07 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Running xinetd 2.3.12 In-Reply-To: <200308141926.h7EJQGpj014107@willers.employees.org> Message-ID: <20030814201207.88737.qmail@web9604.mail.yahoo.com> Hello, Here's a patch for the second core dump. Apply it from the xinetd-2.3.12/xinetd directory. Working on the first one... -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: nvlists.patch Type: application/octet-stream Size: 290 bytes Desc: nvlists.patch Url : http://www.xinetd.org/pipermail/xinetd/attachments/20030814/f351b7f8/nvlists.obj From linux_4ever at yahoo.com Thu Aug 14 13:57:03 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Running xinetd 2.3.12 In-Reply-To: <200308141926.h7EJQGpj014107@willers.employees.org> Message-ID: <20030814205703.41121.qmail@web9605.mail.yahoo.com> >Unfortunately I don't think a backtrace like this can >give you much info about what's going on. :-( I tried setting up the same config and I'm still not getting the problem. Based on the backtrace, malloc itself died. This might be indicative of a stray pointer or something that corrupted the heap. My advice is to put valgrind on it. From the xinetd-2.3.12 directory run this: valgrind --leak-check=yes --leak-resolution=med \ --num-callers=8 --logfile-fd=29 \ ./xinetd/xinetd -d 29> log.txt Then from another console do what you nornally do to trigger a core dump. If it doesn't core, the issue a kill -TERM to xinetd so that valgrind checks everything on exit. Send the valgrind report. I think it will help nail this down real quick. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From marcodb at employees.org Thu Aug 14 16:02:36 2003 From: marcodb at employees.org (Marco Di Benedetto) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Running xinetd 2.3.12 Message-ID: <200308142302.h7EN2aTU014395@willers.employees.org> Thanks for the first patch Steve. About the malloc() failure, I don't think I can install valgrind. I've checked the sources, and apparently valgrind is not a single executable I can move around. The "target" machine where all this is happening is a system without a compiler, so in order to install valgrind I would need to set up the sources in a separate build environment. Not an option right now. I don't have a "regular" linux server where I can try to reproduce this "6-services-only" crash, so I guess I'll have to give up and keep on using 2.3.3 :-( Regards. Marco Steve G wrote: > > >Unfortunately I don't think a backtrace like this can > >give you much info about what's going on. :-( > > I tried setting up the same config and I'm still not > getting the problem. Based on the backtrace, malloc itself > died. This might be indicative of a stray pointer or > something that corrupted the heap. > > My advice is to put valgrind on it. From the xinetd-2.3.12 > directory run this: > > valgrind --leak-check=yes --leak-resolution=med \ > --num-callers=8 --logfile-fd=29 \ > ./xinetd/xinetd -d 29> log.txt > > Then from another console do what you nornally do to > trigger a core dump. If it doesn't core, the issue a kill > -TERM to xinetd so that valgrind checks everything on exit. > > Send the valgrind report. I think it will help nail this > down real quick. > > -Steve Grubb > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > _______________________________________________ > xinetd mailing list > xinetd@xinetd.org > http://www.xinetd.org/mailman/listinfo/xinetd From linux_4ever at yahoo.com Thu Aug 14 19:50:39 2003 From: linux_4ever at yahoo.com (Steve G) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] Running xinetd 2.3.12 In-Reply-To: <200308142302.h7EN2aTU014395@willers.employees.org> Message-ID: <20030815025039.17612.qmail@web9607.mail.yahoo.com> >I don't have a "regular" linux server where I can try to >reproduce this "6-services-only" crash, so I guess I'll >have to give up and keep on using 2.3.3 :-( I would encourage you to help track this down so that you can move to 2.3.12+patches. Seriously, look at the changelog in 2.3.12 and wonder how exposed your system might be. Admittedly some problems were introduced in later versions, but 2.3.3 has problems. During the 2.3.6 cycle, I fixed many vulnerabilities and did not document them. I purposely did not document some so that hackers would have to find them on their own. I have another report on a SUN machine that also crashes on reload occasionally. Since its a SUN machine he can't run valgrind. I was hoping you had the hints that finally showed the problem. If nothing else, please send me your xinetd.conf file and xinetd.d directory. I can run more tests here to see if its reproduceable. You can send it to me directly or the mail list. Thanks, Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From wws1144 at hotmail.com Fri Aug 15 20:55:32 2003 From: wws1144 at hotmail.com (Wannachai Wannasawade) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] How to enable rsh server services Message-ID: I would like to use remote access in rhn7.3 by rsh or rexec in my server with x-win32. How to config my server to service rsh? In my server, I'm install rsh-server 17-10 but not have rshd run in system when I config server services. It tell me must be enable rsh in xinetd but in directory "xinetd.d" has rsh file and in "/usr/sbin/" has in.rshd. How dose I can do? Thank You, wannachai _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From ma+xi at dt.e-technik.uni-dortmund.de Sat Aug 16 03:42:04 2003 From: ma+xi at dt.e-technik.uni-dortmund.de (Matthias Andree) Date: Thu Oct 6 10:34:53 2005 Subject: [xinetd] How to enable rsh server services In-Reply-To: (Wannachai Wannasawade's message of "Sat, 16 Aug 2003 10:55:32 +0700") References: Message-ID: "Wannachai Wannasawade" writes: > I would like to use remote access in rhn7.3 by rsh or rexec in my server > with x-win32. How to config my server to service rsh? In my server, I'm > install rsh-server 17-10 but not have rshd run in system when I config > server services. It tell me must be enable rsh in xinetd but in > directory "xinetd.d" has rsh file and in "/usr/sbin/" has in.rshd. How > dose I can do? Why not use ssh? Is there a "disabled=rsh" line in /etc/xinetd.conf? Comment that one out. Is rsh access enabled in /etc/hosts.allow? -- Matthias Andree