Page MenuHomePhabricator

No init script for idmapd on labs jessie instances
Closed, ResolvedPublic

Description

Error: /Stage[main]/Role::Labs::Instance/Service[idmapd]: Could not evaluate: Could not find init script for 'idmapd'

on Debian Jessie instances

Event Timeline

yuvipanda raised the priority of this task from to High.
yuvipanda updated the task description. (Show Details)
yuvipanda added subscribers: yuvipanda, scfc, Krinkle and 6 others.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 21 2015, 8:51 AM
coren closed this task as a duplicate of T87870: Labs NFSv4/idmapd mess.Feb 5 2015, 3:55 PM
faidon reopened this task as Open.Feb 5 2015, 3:56 PM

This isn't a duplicate, this is a separate issue.

faidon moved this task from Triage to In Progress on the Cloud-Services board.Feb 10 2015, 6:01 PM

So, Debian ships an nfs-common package that contains a SysV init script with the same name that spawns all the needed daemons. Individual daemons like idmapd can be turned on/off from /etc/default/nfs-common. Ubuntu has forked the package and shipped upstart scripts that are separate for each daemon (because that way upstart can manage them better). Debian, even in jessie, does not ship systemd units for nfs-common at all, so the SysV init script is used instead.

This means that Debian doesn't have Service['idmapd'] but has Service['nfs-common'] instead. However, this also means that just handling the Service is not enough; /etc/default/nfs-common needs to also be puppet-managed.

All that said, I think @coren thinks that all this can go away when T87870 gets fixed. I'd probably bite the bullet and fix this independently, though, instead of waiting for the far larger fix to arrive.

This bandaid has been merged about a month ago. Is there anything left here? (I think not)

coren closed this task as Resolved.Mar 14 2015, 7:10 PM
coren claimed this task.

No, this has proven to work well.