Subject: Re: identd and NetBSD
To: None <otaku@unixgeek.ml.org>
From: Ken Nakata <kenn@synap.ne.jp>
List: port-mac68k
Date: 08/24/1998 16:52:58
On Mon, 24 Aug 1998 01:09:39 -0400 (EDT), Joshua E Hope wrote:
> As long back as I can remember, identd has never worked quite right with
> NetBSD/mac68k. I know it doesn't work real well with IRC servers and all,
> because whenever I try connecting to a server identd will do nothing.

This is strange.  It always works for me, even when I connect to one
of the freaking a**l-r****tive EFNet IRC servers.  My /etc/inetd.conf:

ident		stream	tcp	wait	nobody.kmem /usr/libexec/identd	identd -w -t60 -l -e -N

Every time I connect to irc.ais.net or something, the server tells me
"Got ident", and I can see identd running with ps.

What was your previous setting in /etc/inetd.conf?  There used to be
identd "-O" option in /etc/inetd, which caused identd to return
"OTHER" as operating system type which in turn caused EFNet IRC
servers to reject you.  Maybe you still have that option in your
/etc/inetd.conf?

> I found a way around this, though it is ugly. It involved commenting out
> the line in inetd.conf and instead starting identd via the command line
> (identd -b).

You could add it to /etc/rc.local, instead.

> This is the only I've found to make identd work
> acceptably...however, there is a flaw in this as well. Everytime an identd
> request is received, identd will spawn a process and FORGET TO KILL IT.
> This is probably a programmed "feature" but is quite annoying when after a
> couple days my ps list is full of identd processes :)

Hmm, I think you should file a PR about it.  It doesn't get in your
way as long as you invoke identd from inetd, though.

> So what I am looking for are any hints or tips to get identd to work
> successfully through inetd...it'd be much easier :)
> 
> Oh, I should mention here I am using the identd included with standard
> NetBSD distrib, and using the line that is in the inetd.conf file as
> distrib, nothing changed.

Which is?

> On an aside, and unrelated note, Apache still is not functioning (won't
> work either as a normal daemon or when called via inetd)...no replies to
> my previous post on this topic :)

Well, "doesn't work" isn't enough for any of us mere mortals to debug
remotely...

Ken