pre-[ANNOUNCEMENT]: Updating inetutils and related packages

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

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