From: "J. Bruce Fields" <bfields@fieldses.org>
To: Chris Hall <chris.hall@gmch.uk>
Cc: linux-nfs@vger.kernel.org
Subject: Re: mount.nfs4 and logging
Date: Sun, 20 Sep 2020 15:32:45 -0400 [thread overview]
Message-ID: <20200920193245.GC28449@fieldses.org> (raw)
In-Reply-To: <12298172-f830-4f22-8612-dfbbc74b8a40@gmch.uk>
On Sun, Sep 20, 2020 at 10:56:28AM +0100, Chris Hall wrote:
> On 19/09/2020 17:40, J. Bruce Fields wrote:
> >On Sat, Sep 19, 2020 at 12:33:53PM -0400, J. Bruce Fields wrote:
> >>For the server, you don't need rpcbind or rpc.statd for v4, but you do
> >>need rpc.idmapd, rpc.mountd and nfsdcld.
> >>
> >>rpc.mountd is the only one of those three that needs to listen on a
> >>network port, but that's only in the NFSv2/v3 case. I'm not sure if
> >>we're getting that right.
>
> >Looking at the code, it looks correct--I see mountd starting those
> >listeners only when v2 or v3 are configured.
>
> Well, on the machine in question, after a reboot I have:
>
> [root@cerberus ~]# netstat ...
> Proto Local Address Foreign Address State PID/Prog
> tcp 10.25.54.61:1022 0.0.0.0:* LISTEN 767/sshd
> tcp 10.25.54.61:1022 79.xx.xx.xx:57456 ESTAB. 770/sshd root
> [root@cerberus ~]# pstree
> systemd─┬─agetty
> ├─atd
> ├─auditd───{auditd}
> ├─crond
> ├─dbus-broker-lau───dbus-broker
> ├─gssproxy───5*[{gssproxy}]
> ├─mcelog
> ├─rngd───4*[{rngd}]
> ├─rsyslogd───2*[{rsyslogd}]
> ├─sshd───sshd───sshd───bash───pstree
> ├─systemd-homed
> ├─systemd-journal
> ├─systemd-logind
> └─systemd-udevd
>
> where the only port which is open is the "obscure" sshd.
>
> Then I start nfs-server and:
>
> [root@cerberus ~]# systemctl start nfs-server
> [root@cerberus ~]# netstat ...
> Proto Local Address Foreign Address State PID/Prog
> tcp 10.25.54.61:1022 0.0.0.0:* LISTEN 767/sshd
> tcp 79.xx.xx.xx:1001 0.0.0.0:* LISTEN -
> tcp 0.0.0.0:46921 0.0.0.0:* LISTEN 817/rpc.statd
> tcp 0.0.0.0:111 0.0.0.0:* LISTEN 1/systemd
> tcp 10.25.54.61:1022 79.xx.xx.xx:57456 ESTAB. 770/sshd:
> tcp6 :::35545 :::* LISTEN 817/rpc.statd
> tcp6 :::111 :::* LISTEN 1/systemd
> udp 0.0.0.0:54902 0.0.0.0:* 817/rpc.statd
> udp 0.0.0.0:111 0.0.0.0:* 1/systemd
> udp 0.0.0.0:62840 0.0.0.0:* 815/rpcbind
> udp6 :::61316 :::* 815/rpcbind
> udp6 :::111 :::* 1/systemd
> udp6 :::58536 :::* 817/rpc.statd
> [root@cerberus ~]# pstree
> systemd─┬─agetty
> ├─atd
> ├─auditd───{auditd}
> ├─crond
> ├─dbus-broker-lau───dbus-broker
> ├─gssproxy───5*[{gssproxy}]
> ├─mcelog
> ├─nfsdcld
> ├─rngd───4*[{rngd}]
> ├─rpc.idmapd
> ├─rpc.mountd
> ├─rpc.statd
> ├─rpcbind
> ├─rsyslogd───2*[{rsyslogd}]
> ├─sshd───sshd───sshd───bash───pstree
> ├─systemd-homed
> ├─systemd-journal
> ├─systemd-logind
> └─systemd-udevd
>
> Where nfsdcld, rpc.idmapd and rpc.mountd have indeed been started
> but are not bound to any ports.
That looks good. (And rpc.mountd does still serve a purpose in the
NFSv4 case, answering requests from the kernel for information related
to exported filesystems.)
> But rpc.statd and rpcbind have also been started, and various ports
> have been opened, including port 111 which is bound to systemd. Is
> there a way to inhibit that for nfs4 only ?
Unlike rpc.mountd, there's no reason for those to be running at all.
You can mask thoe corresponding systemd units.
It'd be nice if there was a way to make that happen automatically if v2
and v3 are configured out in the configuration files, but I don't know
how to make that happen.
--b.
>
> The /etc/nfs.conf says:
>
> [nfsd]
> debug=0
> threads=8
> host=cerberus
> port=1001
> udp=n
> tcp=y
> vers2=n
> vers3=n
> vers4=y
> vers4.0=y
> vers4.1=y
> vers4.2=y
>
> And nothing else. And yes, the port is intended to be "obscure".
next prev parent reply other threads:[~2020-09-20 19:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <S1725851AbgIKKt5/20200911104957Z+185@vger.kernel.org>
2020-09-11 11:45 ` mount.nfs4 and logging Chris Hall
2020-09-14 18:30 ` Steve Dickson
2020-09-15 13:06 ` Chris Hall
2020-09-16 12:52 ` Kenneth Dsouza
2020-09-16 14:31 ` Kenneth Dsouza
2020-09-16 17:31 ` Kenneth Dsouza
2020-09-19 16:33 ` J. Bruce Fields
2020-09-19 16:40 ` J. Bruce Fields
[not found] ` <12298172-f830-4f22-8612-dfbbc74b8a40@gmch.uk>
2020-09-20 19:32 ` J. Bruce Fields [this message]
2020-09-21 14:40 ` Chris Hall
2020-09-23 14:40 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200920193245.GC28449@fieldses.org \
--to=bfields@fieldses.org \
--cc=chris.hall@gmch.uk \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox