>statd (i.e. nfslock) probably does not need to be running if NFS
>tunning off portmapper is a bit extreme... Not only do local process
>to be there,
Which local processes? We've already heard about sgi_fam, and we already
know about NIS and NFS, but is this really worth leaving it listening on
external interfaces in a _default_ install?
third party applications of our beloved customers... There are
*probably* a few more
applications other than NFS and NIS that need to advertise ports....
RPC subsystem has been around for a very long time which means we really
what we would be breaking by turning it off... Just because you don't
something..... does not mean they don't exist....
>point being turning off portmapper could (and probably will) cause
>to fail in unexpect ways making very difficult to debug especially
As a matter of course, I disable portmap and rpc.statd on any machine not
expected to perform NFS or NIS and have not noticed any side effects as a
So we can assume that your system is an *exact* clone of every other
out there... so what works in your world will work everywhere.... I'm
I just don't by your logic...
>Portmapper has been around quite a long time making it pretty bullet
Funny, 'cos in my universe, the portmapper is regarded as one of the most
vulnerable pieces of UNIX software, along with rpc.statd, sendmail and BIND.
Educate me... How has it *recently* (i.e within the that 3 years) been
And what damage was caused?
>So I see no reason what so ever to turn off portmapper. Lets not
>system more difficult to deal with for simply no reason...
...but there is a reason - making new installs secure by default. For a
admin who's already configuring NFS or similar, the extra step of
chkconfig'ing portmap and rpc.statd isn't much of a burden.
Again.... NFS and NIS are not the only user of portmapper... We have to keep
in mind the entire industry... not just or own little worlds....