Problem solved. Thanks to:- Jordan Klein (First with helpful advice) Casper Dik Julian Grunnel Johan Hartzenberg Thomas M. Payerle Ric Anderson dspezialie Rich Kulawiec Chris Price Most of you suggested using lsof from (sunfreeware.com or your nearest mirror) which proved to be very helpful. "lsof -i tcp:32771" showed you the process ID and name of the process listening on the port. The culprit was statd, - network status monitor - which, when disabled by moving /etc/rc2.d/S73nfs.client ( I didn't need nfs), was swiftly replaced by ruserd. When that was disabled/commented out of inetd.conf it was replaced by inetd listening to nothing on that port. I can live with that. Other suggestions which proved interesting/useful were the use of rpcinfo: rpcinfo -p get the prognum Then rpcinfo -b prognum version To disable the service, use rpcinfo -d and Casper's comment: It's also possible that these are the rpcbind call back ports in which case you can't really close them. (But the ports only accept RPC replies for indirect RPC calls) Interestingly, these ports had nothing to do with Filenet.com's VW Web Services or eProcess which use these ports. Although Filenet were v helpful in explaining what to do if they had been. Thanks Matt Original Q: >Greetings SM's, > > I am doing some security lock down activities on E250's running 2.6 >and this includes closing down any unrequired open ports. I've got them all >sorted except for > >32771, Filenet RMI ? > >32772 Filenet Process Analyser > >Does anybody know why these are there and how they can be closed? _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Wed Nov 26 07:10:47 2003
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:24 EST