> Roland McGrath <[EMAIL PROTECTED]> writes: > > > There is an NFS server program (/sbin/nfsd) installed by the hurd package > > (not inetutils). I have not tested nfsd recently at all, and I think it is > > officially not quite finished (Thomas is the person to ask). > > The nfs server is known to be broken, but it partially works. It > would be cool if someone started collecting at least bugs. > > > > It looks like nfsd is present in the inetutils (I think) > > > package, but there is no "portmapper" script -- although > > > I suspect the Hurd translator semantic means a different > > > approach is needed. > > The Hurd nfsd does not require portmap at all.
Ah, I see. That is indeed true, because it takes over the portmap socket and then doesn't implement the actual protocol, preventing any other sunrpc services from being used in the normal ways. This will have to be changed. It is fine that nfsd uses dedicated canonical port numbers for the nfs and nfsmount sunrpc protocols. I suppose it's also vaguely reasonable that it provide a minimal portmap server when there isn't one on the system. But it is not reasonable to take over the portmap port and then not be a real portmap server, so that no other sunrpc services can be used on the system. nfsd should act as a client of the portmap daemon (and an existing unixoid portmap daemon will do fine). Having it fall back to providing its minimal portmap server is ok I suppose, but I think it is more hair than it's worth.
