jumperalex Posted December 9, 2011 Posted December 9, 2011 For Reference I am on 5.0b14, but in general this still applies I think to 4.7 So in my efforts now to harden my UnRAID box I have added to my go script what i need to turn off ftp and telnet. Using netstat --tulpnI see "rpc.statd" listening on 46415. A quick google search tells me it is related to NFS What confuses me is that I have NFS and AFS turned off under settings. Is this being used for anything else? If I manage to kill this by modifying inetd.conf will I break anything else? Also, although it doesn't seem to be listening on a port, I see a top process called "nfsiod". why is that running if i do not have NFS turned on? Oh yeah and can I kill rpc.portmap???
WeeboTech Posted December 9, 2011 Posted December 9, 2011 /etc/rc.d/rc.nfsd stop /etc/rc.d/rc.rpc stop
jumperalex Posted December 9, 2011 Author Posted December 9, 2011 hehe i ask questions and then get impatient So i went ahead and removed them from inetd.conf the same way I did ftp and telent But your way looks more elegent. Will that work with ftp and telnet? Also, now that I killed rpc I'm testing things out and they all seem to work fine. So why are these running if NFS isn't even turned on?
WeeboTech Posted December 10, 2011 Posted December 10, 2011 ftp and telnet need to be removed from inetd. Do you have ssh installed? As far as rpc running, that's not just for nfs but for other remote procedure calls too. rstatd, rwalld, I think some time daemons too. I don't know all that much about it. Couldn't tell you why nfsiod was running or not. I think it's a kernel process to support nfs should it be used. Possibly in client mode? Dunno.
jumperalex Posted December 10, 2011 Author Posted December 10, 2011 I do have ssh running. rpc ... hmmm ... maybe rpc in general? but specifically rpc.statd and rpc.portmap seem to specifically concern NFS. At least that is what I'm finding in my google searching. But Im' surely open to additional info. So far I'm not getting errors [fingers crossed]. That said, been about an hour or more and now i see this in my syslog rpc.statd[1123]: Caught signal 15, un-registering and exiting so far all seems good otherwise. as for nfsiod, I'm not as worried because it is not listening on a port. So far this is what I have left root@Tower:/# netstat -tulpn Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:37 0.0.0.0:* LISTEN 27142/inetd tcp 0 0 0.0.0.0:39818 0.0.0.0:* LISTEN 3170/Plex Plug-in [ tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 3011/smbd tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 19743/awk tcp 0 0 0.0.0.0:32400 0.0.0.0:* LISTEN 3138/Plex Media Ser tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 2486/emhttp tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2007/sshd tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 3011/smbd tcp 0 0 0.0.0.0:3551 0.0.0.0:* LISTEN 1688/apcupsd udp 0 0 0.0.0.0:37 0.0.0.0:* 27142/inetd udp 0 0 127.0.0.1:40562 0.0.0.0:* 3138/Plex Media Ser udp 0 0 10.0.0.4:123 0.0.0.0:* 1140/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 1140/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 1140/ntpd udp 0 0 10.0.0.255:137 0.0.0.0:* 3009/nmbd udp 0 0 10.0.0.4:137 0.0.0.0:* 3009/nmbd udp 0 0 0.0.0.0:137 0.0.0.0:* 3009/nmbd udp 0 0 10.0.0.255:138 0.0.0.0:* 3009/nmbd udp 0 0 10.0.0.4:138 0.0.0.0:* 3009/nmbd udp 0 0 0.0.0.0:138 0.0.0.0:* 3009/nmbd udp 0 0 127.0.0.1:53908 0.0.0.0:* 3138/Plex Media Ser udp 0 0 0.0.0.0:32410 0.0.0.0:* 3138/Plex Media Ser udp 0 0 0.0.0.0:32413 0.0.0.0:* 3138/Plex Media Ser udp 0 0 0.0.0.0:32414 0.0.0.0:* 3138/Plex Media Ser udp 0 0 10.0.0.4:33070 0.0.0.0:* 3138/Plex Media Ser udp 0 0 10.0.0.4:35130 0.0.0.0:* 3138/Plex Media Ser
WeeboTech Posted December 10, 2011 Posted December 10, 2011 if it's [nfsiod] I believe it's a kernel thread and it does not do network io. I think portmap is used by other rpc daemons, none of which are used in unRAID. old bsd daemons ruptime,rwhod, stuff like that. I'm sure you can safely turn it off if you are not using NFS.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.