[PATCH 0/1] details for starting nfs-idmapd also on clients

[PATCH 0/1] details for starting nfs-idmapd also on clients

[Martin Pitt]

Hello all,

Steve Langasek pointed out in [1] that idmapd is also necessary on the client
side. It isn't for my very simple NFSv4 test, but then again I don't know that
much about the various other modes of operation.

This patch starts nfs-idmapd.service on clients too.

Thanks,

Martin

[1] https://launchpad.net/bugs/1428961

[PATCH] systemd: start nfs-idmapd also on clients

[Martin Pitt]

idmapd is needed on clients too, so start it from nfs-client.target and stop
binding to it in nfs-server.service.

https://launchpad.net/bugs/1428961
---
 systemd/nfs-client.target  | 4 ++--
 systemd/nfs-idmapd.service | 2 --
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/systemd/nfs-client.target b/systemd/nfs-client.target
index 9b792a3..b12d830 100644
--- a/systemd/nfs-client.target
+++ b/systemd/nfs-client.target
@@ -5,8 +5,8 @@ Wants=remote-fs-pre.target
 
 # Note: we don't "Wants=rpc-statd.service" as "mount.nfs" will arrange to
 # start that on demand if needed.
-Wants=nfs-blkmap.service rpc-statd-notify.service
-After=nfs-blkmap.service
+Wants=nfs-blkmap.service rpc-statd-notify.service nfs-idmapd.service
+After=nfs-blkmap.service nfs-idmapd.service
 
 # GSS services dependencies and ordering
 Wants=auth-rpcgss-module.service
diff --git a/systemd/nfs-idmapd.service b/systemd/nfs-idmapd.service
index df3dd9d..90d3731 100644
--- a/systemd/nfs-idmapd.service
+++ b/systemd/nfs-idmapd.service
@@ -4,8 +4,6 @@ DefaultDependencies=no
 Requires=var-lib-nfs-rpc_pipefs.mount
 After=var-lib-nfs-rpc_pipefs.mount local-fs.target
 
-BindsTo=nfs-server.service
-
 Wants=nfs-config.service
 After=nfs-config.service
 
-- 
2.1.4

Re: [PATCH 0/1] details for starting nfs-idmapd also on clients

[Steve Dickson]

Hello,

On 03/06/2015 06:15 AM, Martin Pitt wrote:
> Hello all,
> 
> Steve Langasek pointed out in [1] that idmapd is also necessary on the client
> side. It isn't for my very simple NFSv4 test, but then again I don't know that
> much about the various other modes of operation.
> 
> This patch starts nfs-idmapd.service on clients too.
This is distro specific... Other distros use the 
key ring based nfsidmap(5) command to do the id mapping.

Make note, with new kernels the default upcall is to the
nfsdimap command, if that fails then the rpc.idmapd daemon 
is tried. Meaning there are two upcalls for every id map
when rpc.idmapd is used. This was the reason for the switch.

steved.

Re: [PATCH 0/1] details for starting nfs-idmapd also on clients

[Steve Langasek]

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]

On Fri, Mar 06, 2015 at 11:49:33AM -0500, Steve Dickson wrote:
> On 03/06/2015 06:15 AM, Martin Pitt wrote:
> > Hello all,

> > Steve Langasek pointed out in [1] that idmapd is also necessary on the client
> > side. It isn't for my very simple NFSv4 test, but then again I don't know that
> > much about the various other modes of operation.

> > This patch starts nfs-idmapd.service on clients too.
> This is distro specific... Other distros use the 
> key ring based nfsidmap(5) command to do the id mapping.

> Make note, with new kernels the default upcall is to the
> nfsdimap command, if that fails then the rpc.idmapd daemon 
> is tried. Meaning there are two upcalls for every id map
> when rpc.idmapd is used. This was the reason for the switch.

Ah, thanks for the feedback.  We do have nfsidmapd enabled, I had overlooked
that rpc.idmapd was no longer being used on the client.  We'll stick with
just using nfsidmap then.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]