Yes! A _new_ inetd problem!

[toddpw at ugcs dot caltech dot edu (Todd P. Whitesel)]

I've been up all night searching the mailing list archives, pulling down
updates of stuff from the web, etc., etc. Here's where I'm at:

inetd runs great. It took me a little while to realize it didn't care about
/etc/inetd.conf, and only looked at /usr/local/etc/inetd.conf. That was when
I changed most occurrences of "root" to "toddpw" (me).

telnetd consistently says "Login incorrect" no matter what I try.

rlogind consistently causes my solaris rlogin to print "Connection closed.",
and dumps core ("in.rlogind.exe.core") into inetd's working directory.

tftpd works.

ftpd works, but if I change my /etc/passwd login shell, e.g. to /bin/bash
-- it blew me off with "530 User toddpw access denied." until I changed it
back to /bin/sh.

rshd used to dump core, but doesn't seem to now that I have a new coolview
fresh off of (sp?) Sergey's web site. If I'm lucky, "rshd win32pc ls" gives
"ls: write error: The descriptor is a file, not a socket." If I'm not lucky
then 'rsh' on my solaris box just returns. I forget if this dumps core or not.

Interestingly, "rsh win32pc /usr/X11R6.3/bin/xterm -display solarisbox" comes
back with "Error: Can't open display: solarisbox" but if I specify the display
number correctly 'rsh' simply returns and the xterm appears to quietly die,
with no window ever appearing on solarisbox:0.

Last data point: all my mounts are text!=binary. I don't want to change it
-- right now, I can't afford the reinstall that it apparently requires. I
would much rather help fix the bogus uses of fopen(), because that seems
to me to be where the real problem lies.

Alternatively, could someone explain which files seem to be tripping over
the text!=binary problem? Maybe there is a way to shuffle my setup to
avoid a reinstall. Soon I will be using a network mounted cygwin anyway,
which raises the question of whether an NFS directory mounted text!=binary
can be safely used to load .exe's untarred there by a unix box.

Actually, could somebody just explain what exactly the text!=binary setting
affects? Does it simply cover the behavior of fopen() without "b" or is it
something more convoluted, like altering the behavior of read() and write().

Todd Whitesel
toddpw @ ugcs.caltech.edu
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".