public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
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".

  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