X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Message-ID: <4BAFABDB.9040702@cwilson.fastmail.fm> Date: Sun, 28 Mar 2010 15:19:55 -0400 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: pre-[ANNOUNCEMENT]: Updating inetutils and related packages Content-Type: multipart/mixed; boundary="------------050004050102040804010805" Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com --------------050004050102040804010805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit After much pain and suffering, I've managed to restore what I consider to be full functionality for the inetutils servers (rsh, rlogin, rcp, telnet, ftp, ...). However, there's been some restructuring (and there will be more in the future, but...not for a while. Look for the following packages to be announced soon. xinetd-2.3.14-1 inetutils-1.7-1 rsh-0.17-1 rsh-server-0.17-1 tcp_wrappers-7.6-21 libwrap0-7.6-21 libwrap-devel-7.6-21 All have been compiled under cygwin-1.7.2-2 with gcc4. (The previous inetutils package, 1.5-6, was compiled only for cygwin-1.5 using gcc3). TCP_WRAPPERS ============ I've made a few changes to tcp_wrappers and many of the servers so that 'localhost' is treated specially -- that is, it will match whatever /etc/hosts.allow says about localhost -- in all of its various incarnations ("localhost", 127.0.0.1, ::1, ::ffff:127.0.0.1, AND when using the actual name or public IP address of the machine in question). That is, if mymachine (with IP 192.168.51.27) is running the cygwin telnet server, and I'm logged in to the mymachine console (that is, a GUI login, Start Menu and all), then all of the following "act like" 'telnet localhost': telnet localhost telnet mymachine telnet mymachine.mydomain telnet 127.0.0.1 telnet 192.168.51.27 (telnet client doesn't yet support IPv6 addrs on cmd line, so that's untested) I've expanded the cygwin README for tcp_wrappers to address some issues that came up in testing with regards to multi-homed computers (those with more than one ethernet adapter: wireless+wired, or 'virtual' ones like VMware...) tcp_wrappers supports IPv6 (actually, the cygwin-1.7 version has since last March). XINETD ============ I've adopted and updated the xinetd package, and incorporated patches from both debian and fedora to enable IPv6 support and fix a few bugs. It also needed assistance with respect to localhost. I've added a LOT of documentation. I've added two utility programs for simple testing of network servers: /usr/lib/xinetd/tcp_client /usr/lib/xinetd/udp_client xinetd supports IPv6. R* TOOLS (rsh, etc) ============ The r* client and server tools have been moved to a new package, based on the fedora (netkit)-rsh upstream source. These nominally support IPv6 connections, although I only tested them in IPv4-wrapped-in-IPv6 configuration. rsh-0.17-1 rsh-server-0.17-1 These servers also needed some assistance with regards to localhost. Moved all r*-tool relevant documentation from inetutils' cygwin README here. The r* tools (supposedly) support IPv6. INETUTILS ============ 4) The inetutils package has been updated to upstream release 1.7. However, it has NOT been compiled to support IPv6. (A) The support for IPv6 in the inetd superserver is still somewhat lacking, (B) I'd rather put that effort into xinetd, and (C) it seems that many of the slave servers (ftpd, tftpd) OTHER than inetd, have no IPv6 support at all. So...use xinetd if you want IPv6. Actually, use xinetd, period. All the cool linux distros do. I've removed from inetd the support for running as a service on its own, without the assistance of cygserver. You can still install it as a service WITH cygserver; in fact, that's what iu-config has done for the past 18 months or so. Furthermore, for the past 12 months, inetd has only supported '--remove-as-service'; the '--install-as-service' option was removed long ago. So...the only way this change would affect anyone, is if they (a) installed inetd as a standalone service two years ago, (b) ignored all warnings and pleadings in the release announcements that this ability was going to go away, and (c) didn't notice that it was actually *broken* for much of that time. So...I'm thinking, not a big deal. ++++> telnet. still has problems when (a) connecting from cygwin telnet client to cygwin telnet server, AND (b) the cygwin telnet client is running in a cmd box. All other permutations seem to be fine. I'll track this problem down eventually, but see... None of the utilities in inetutils have been compiled to support IPv6. They are IPv4 only. (However, they can be launched from xinetd in IPv4 mode by using the flags = IPv4 option -- all of the provided /etc/xinetd.d/ configuration files do this. FUTURE PLANS ============ I plan to continue "shrinking" the size of the inetutils package by moving various components to their own packages. Most of the distros seem to provide these tools separately using separate (e.g. non-inetutils) source, so I'll follow their lead. Besides, it is in the distro packages that the "IPv6" patches are to be found. The goal here is to make each client/server unit individually updatable, for easier maintenance, and to stick to the bare-bones functionality of the original inetutils versions (but try to add IPv6 support). There are many more feature-rich servers and clients out there, but porting and providing (e.g) telnet-krb5 or vsftpd is not my goal. The inetutils code was originally derived from the netkit distribution, so that's the starting point. It helps that most of the linux distros have stuck with -- and updated -- the original netkit versions anyway, instead of using the inetutils package. (Except ARCH Linux, which seems to be moving in the opposite direction). So, eventually we'll have: telnet -- based on fedora (netkit) telnet telnet-server -- ditto ftp -- based on fedora (netkit) ftp ftpd -- probably based on tnftpd (aka lukemftpd) [1] tftp -- probably based on the tftp-hpa client tftp-server -- probably based on the tftp-hpa server talk -- based on fedora (netkit) talk talk-server -- ditto [1] This appears to be the natural successor to the netkit/bsd-derived inetutils ftpd -- it's actually an undated version of bsd-ftpd. The linux distros all appear to have abandoned any netkit-derived ftpd, and instead provide only the more powerful versions like vsftpd, pro-ftpd, etc. So...in keeping with the minimalist nature of these inetutils "replacements", we go with the other inetutils ancestor, bsd-ftpd. This would leave only the following programs/protocols provided by the trimmed-down inetutils package: inetd syslogd uucpd which seems about right to me. I'll probably do this "shrinking" one client/server at a time, and release an updated inetutils with each new standalone client/server package. The next target on the list is telnet/telnetd, which will allow me to independently address the whole "wierdness in cmd.exe" problem. I hope. But...it ain't gonna happen anytime soon, so don't worry about version thrash. TEST RESULTS ============ I tested the following cygwin clients: rlogin, rsh, rcp, rexec, telnet, ftp --> connecting to linux servers, and to the matching cygwin servers I tested the following cygwin servers: rlogind, rshd, rexecd, telnetd, ftpd --> running under the inetd superserver AND the xinetd superserver --> using linux clients and the matching cygwin clients' I also tested the "built-in" services provided by the inetd and xinetd superservers. I all cases I was able to get a working connection. In all cases that support it (e.g. not telnet) I was able to get a working passwordless connection (*). This all assumes a properly configured network: (1) firewall "holes" (and, on the cygwin machine, "program exceptions") as needed -- as described in the relevant cygwin README files. (2) appropriate .rhosts files on the server machine(s) -- for rsh, rlogin, and rcp (3) appropriate .netrc files on the client machine(s) -- for ftp and rexec (**) (4) an identd server running on the client machine, with an appropriate hole in the client's firewall. This is easy enough for linux clients (apt-get/urpmi/rpm oidentd). However, we don't yet have a cygwin identd server, so I used a free-as-in-beer Windows version (see the READMEs). (*) however, unless you have installed and enabled the appropriate cyglsa module and registered your password with it, you won't get access to shared drives in a remote session to a cygwin box, unless you log on with a password. (**) for a linux-->cygwin rexec to work, you must either (a) use the -a option when invoking the rexec client, OR (b) turn off your linux machine's firewall, entirely. Yes, you read that correctly. I've said all along the r* protocols were a security nightmare. You really should be using ssh, scp, and sftp instead... I've attached my test results. Look for uploads and individual package release announcements to follow. -- Chuck --------------050004050102040804010805 Content-Type: text/plain; name="servers-testing.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="servers-testing.log" Test configuration: cygwin-1.7.2-2 Windows Vista (I figure if it works there, it'll work on XP and below; Windows 7 or Server2008? Well, we'll see) xinetd-2.3.14-1 inetutils-1.7-1 rsh-0.17-1 rsh-server-0.17-1 tcp_wrappers-7.6-21 tftpd, tftp not tested talk, talkd not tested uucpd not tested "ok" means with all the necessary setup, I was able to make a passwordless connection between the two machines. That is, proper firewall configuration, a good ~/.rhosts and ~/.netrc file, etc. (And, of course, actually editing the appropriate /etc/xinetd.d/* or /etc/inetd.conf file to enable the service in question). CLIENTS ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ to remote machine ======================================================== othermachine othermachine.mydomain rlogin ok (1) ok (1) rsh ok (1) ok (1) rsh (ls -l) ok (1) ok (1) rcp remote:file . ok (1) ok (1) rcp file remote: ok (1) ok (1) rexec (ls -l) ok (1) ok (2,1) rexec -a (ls -l) ok (1) ok (2,1) telnet (inetutils, mintty) ok (3) ok (3) telnet (inetutils, cmd) ok (3) ok (3) ftp active get ok (4,1) ok (4,1) ftp active put ok (4,1) ok (4,1) ftp passive get ok (4,1) ok (4,1) ftp passive put ok (4,1) ok (4,1) [1] very slow (connecting to my linux server) unless vista machine was running an identd server and had an opening it its firewall for the auth (ident) port (113). (For ftp, it's only a few seconds; but for the r* tools it's 30 seconds; this has to do with the characteristics of the remote server; linux:netkit-rsh-server vs linux:proftpd). [2] For passwordless rexec, the .netrc file must have separate entries for both name variations: 'othermachine' not 'othermachine.mydomain'). Oddly, the ftp client, which also uses .netrc for passwordless auth- entication, requires only 'othermachine'. [3] a note on server config: my linux telnet server was kerboros-enabled, and was set up to reject non-krb connections. I had to explicitly comment out the following from linux:/etc/xinetd.d/telnet # server_args = -a valid -e or it would reject all non-kerboros connections. THere is, however, no identd-related delay. [4] uses .netrc authentication. In this case, even though .netrc still only lists 'othermachine', both othermachine and othermachine.mydomain work -- probably because the ftp client has smarter string matching than rexec (actually, cygwin's rcmd() implementation) -- ftp.exe implements the .netrc parsing itself, unlike rexec.exe. SERVERS ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ (a) == using tcp_client to test (b) == using telnet to test SUPERSERVER XINETD -- builtin services -- from local machine ========================================================= 9098 chargen daytime discard echo time tcp localhost (a) ok ok ok ok ok ok tcp mymachine (a) ok ok ok ok ok ok tcp mymachine.mydomain (a) ok ok ok ok ok ok tcp localhost (b) ok ok ok ok ok ok tcp mymachine (b) na (1) ok ok ok ok ok tcp mymachine.mydomain (b) na (1) ok ok ok ok ok udp localhost na ok ok ok ok ok udp mymachine na ok ok ok ok ok udp mymachine.mydomain na ok ok ok ok ok [1] This service is explicitly enabled only for tcp 127.0.0.1/localhost, so it is not surprising that it is inaccessible when contacted via a different interface or protocol. SUPERSERVER XINETD -- builtin services -- from remote machine ========================================================== 9098 chargen daytime discard echo time tcp mymachine (a) na ok ok ok ok ok tcp mymachine.mydomain (a) na ok ok ok ok ok tcp mymachine (b) na ok ok ok ok ok tcp mymachine.mydomain (b) na ok ok ok ok ok udp mymachine na ok ok ok ok ok udp mymachine.mydomain na ok ok ok ok ok SUPERSERVER XINETD -- other services -- from remote machine (IPv6) ================================================================== mymachine mymachine.mydomain IPv6 or IPv4: rlogin ok ok rsh ok ok rsh (ls -l) ok ok rcp remote:file . ok ok rcp file remote: ok ok rexec (ls -l) X (1) X (1) rexec -a (ls -l) ok ok IPv4 only: telnet ok ok ftp ls ok (2) ok (2) ftp active get ok (2) ok (2) ftp active put ok (2) ok (2) ftp passive get ok (2) ok (2) ftp passive put ok (2) ok (2) [1] no error message, but client hangs forever. This is because rexecd can't set up the stderr connection back to the client, because it is blocked by the firewall on the client machine (turning off the firewall entirely allows the connection to succeed). So, the server gives up after 20 seconds, but the (linux) client never does. [2] Client needs an identd server running, or there is a very long delay. SUPERSERVER XINETD -- other services -- from local machine ======================================================= localhost mymachine mymachine.mydomain IPv6 or IPv4: rlogin ok ok (1) ok rsh ok ok (1) ok rsh (ls -l) ok ok (1) ok rcp remote:file . ok ok (1) ok rcp file remote: ok ok (1) ok rexec (ls -l) ok (2,3) ok (1,2,3) ok (2,3) rexec -a (ls -l) ok (2) ok (1,2) ok (2) IPv4 only: telnet (putty) ok X (4) ok telnet (inetutils, mintty) ok ok ok telnet (inetutils, cmd) ok (5) ok (5) ok (5) ftp ls ok ok ok ftp active get ok ok ok ftp active put ok ok ok ftp passive get ok ok ok ftp passive put ok ok ok [1] Only if the the local machine is not multi-homed (that is, it is associated with only one network; or, ALL of the networks with which it IS associated have matching rules in /etc/hosts.allow) [2] For passwordless rexec to work, you must have a separate entry in .netrc for each variations on the name that you wish to use in the rexec command line: 'localhost', 'mymachine', and 'mymachine.mydomain'. Oddly, the ftp client, which also uses .netrc for passwordless authentication, needs only one entry: 'mymachine'. [3] You need to have a 'program exception' in your firewall for the /usr/bin/rexec.exe client, or rexec won't work at all without -a. This is because the protocol expects the server to make a connection BACK to the client, for stderr. [4] The telnetd server logs don't seem to show any problem; it seems this issue is on the 'putty' side. [5] Keyboard input is odd; extra spaces between each letter and backspace doesn't move the cursor (but it does 'erase' the characters in the input buffer). This is a longstanding issue with cygwin telnet, but it affects only loopback connections, and only when in cmd.exe (or console2). The telnet server works fine when non-cygwin clients connect; or when the cygwin client connects from a non-cmd console. The telnet client works fine connecting to non-cygwin servers, or when connecting to the cygwin server from a non-cmd console. I'm delaying this investigation. SUPERSERVER INETD -- builtin services -- from local machine ======================================================== chargen daytime discard echo time tcp localhost (a) ok ok ok ok ok tcp mymachine (a) ok ok ok ok ok tcp mymachine.mydomain (a) ok ok ok ok ok tcp localhost (b) ok ok ok ok ok tcp mymachine (b) ok ok ok ok ok tcp mymachine.mydomain (b) ok ok ok ok ok udp localhost ok ok ok ok ok udp mymachine ok ok ok ok ok udp mymachine.mydomain ok ok ok ok ok SUPERSERVER INETD -- builtin services -- from remote machine ========================================================= chargen daytime discard echo time tcp mymachine (a) ok ok ok ok ok tcp mymachine.mydomain (a) ok ok ok ok ok tcp mymachine (b) ok ok ok ok ok tcp mymachine.mydomain (b) ok ok ok ok ok udp mymachine ok ok ok ok ok udp mymachine.mydomain ok ok ok ok ok SUPERSERVER INETD -- other services -- from remote machine (IPv4) ================================================================== mymachine mymachine.mydomain IPv4 only: rlogin ok ok rsh ok ok rsh (ls -l) ok ok rcp remote:file . ok ok rcp file remote: ok ok rexec (ls -l) X (1) X (1) rexec -a (ls -l) ok ok telnet ok ok ftp ls ok (2) ok (2) ftp active get ok (2) ok (2) ftp active put ok (2) ok (2) ftp passive get ok (2) ok (2) ftp passive put ok (2) ok (2) [1] no error message, but client hangs forever. This is because rexecd can't set up the stderr connection back to the client, because it is blocked by the firewall on the client machine (turning off the firewall entirely allows the connection to succeed). So, the server gives up after 20 seconds, but the (linux) client never does. [2] Client needs an identd server running, or there is a very long delay. SUPERSERVER INETD -- other services -- from local machine ======================================================= localhost mymachine mymachine.mydomain IPv4 only: rlogin ok ok (1) ok rsh ok ok (1) ok rsh (ls -l) ok ok (1) ok rcp remote:file . ok ok (1) ok rcp file remote: ok ok (1) ok rexec (ls -l) ok (2,3) ok (1,2,3) ok (2,3) rexec -a (ls -l) ok (2) ok (1,2) ok (2) telnet (putty) ok X (4) ok telnet (inetutils, mintty) ok ok ok telnet (inetutils, cmd) ok (5) ok (5) ok (5) ftp ls ok ok ok ftp active get ok ok ok ftp active put ok ok ok ftp passive get ok ok ok ftp passive put ok ok ok [1] Only if the the local machine is not multi-homed (that is, it is associated with only one network; or, ALL of the networks with which it IS associated have matching rules in /etc/hosts.allow) [2] For passwordless rexec to work, you must have a separate entry in .netrc for each variations on the name that you wish to use in the rexec command line: 'localhost', 'mymachine', and 'mymachine.mydomain'. Oddly, the ftp client, which also uses .netrc for passwordless authentication, needs only one entry: 'mymachine'. [3] You need to have a 'program exception' in your firewall for the /usr/bin/rexec.exe client, or rexec won't work at all without -a. This is because the protocol expects the server to make a connection BACK to the client, for stderr. [4] The telnetd server logs don't seem to show any problem; it seems this issue is on the 'putty' side. [5] Keyboard input is odd; extra spaces between each letter and backspace doesn't move the cursor (but it does 'erase' the characters in the input buffer). This is a longstanding issue with cygwin telnet, but it affects only loopback connections, and only when in cmd.exe (or console2). The telnet server works fine when non-cygwin clients connect; or when the cygwin client connects from a non-cmd console. The telnet client works fine connecting to non-cygwin servers, or when connecting to the cygwin server from a non-cmd console. I'm delaying this investigation. --------------050004050102040804010805 Content-Type: text/plain; charset=us-ascii -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple --------------050004050102040804010805--