This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Attachment:
servers-testing.log
Description: Text document
-- 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |