Re: inetd and whois

[Marco d'Itri]

On Aug 02, Jeff Bailey <address@hidden> wrote:

(Looks like I have been unsubscribed from this mailing list because 90%
of the traffic is made of trivially recognizable Korean spam which is
bounced by my mail servers. Can you add a few patterns to the mailman
configuration?)

 >> BTW, the debian whois package comes with a mkpasswd command I wrote,
 >> can you help finding a home for it in inetutils or in another GNU
 >> package?
 >What does it do?
It does crypt a password using crypt(3).

Usage: mkpasswd [OPTIONS]... [PASSWORD [SALT]]
Crypts the PASSWORD using crypt(3).

      -H, --hash=TYPE       select hash TYPE
      -S, --salt=SALT       use the specified SALT
      -P, --password-fd=NUM read the password from file descriptor NUM
                            instead of /dev/tty
      -s, --stdin           like --password-fd=0
      -h, --help            display this help and exit
      -V, --version         output version information and exit

If PASSWORD is missing then it is asked interactively.
If no SALT is specified, a random one is generated.
If TYPE is missing available algorithms are printed.

Report bugs to <address@hidden>.


Available algorithms:
des     standard 56 bit DES-based crypt(3)
md5     MD5


 >> My opinion as a developer is that debian is not even going to
 >> consider replacing anything with inetutils until its code will be
 >> better than the other alternatives (and still be compatible with
 >> them).  It's not like there are no free implementations of network
 >> daemons.
 >Sure, but netkit doesn't run on BSD or the Hurd.  Inetutils already
You may guess how many debian users actually care... A huge number of
packages does not work with hurd, I assume hurd users someday will fix
them and/or the kernel.

 >runs on all of these.  I'm hoping that Inetutils will have the
 >required features within a year.
I'm not going to wait a year. I need a good inetd in debian *now*.

 >The point is that between mailutils and inetutils, we have a dozen
 >programs that need to share this.  I want to hand off to a function
 >call that returns me file handles to work with.  I shouldn't have to
 >worry about how I got there.
If a programs is started by inetd you get a working fd on stdin, that's
all. A generic function for self-spawning daemon is a good idea, but
it's not really related to what is needed to have e.g. a multithreaded
daemon.

 >I haven't and I can't if I want to be able to code this.  Is there a
 >public API reference?  I don't object to working from that.  If there
There are the BSD man pages.

 >> It's just a small part of inetd.
 >So would it go in the startup library as an option for network-based
 >communication?  Not all daemons start as part of inetd.  I have an
It could go at the same level of the calls to libwrap.

 >intense dislike for inetd and think it should not be required if all I
 >want is telnetd.
Your choice.

-- 
ciao,
Marco