Bug 10060

Summary:	umich_ldap usage in idmapd.conf prevent rpc.idmapd to start
Product:	Mageia	Reporter:	Bruno Cornec <bruno>
Component:	RPM Packages	Assignee:	Guillaume Rousse <guillomovitch>
Status:	RESOLVED FIXED	QA Contact:
Severity:	minor
Priority:	Normal	CC:	mageia, tmb
Version:	Cauldron	Keywords:	NEEDINFO, Triaged
Target Milestone:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Source RPM:	nfs-utils	CVE:
Status comment:

Description Bruno Cornec 2013-05-11 00:05:46 CEST

When using umich_ldap in idmapd.conf, the nfs-idmap.service doesn't start. It exists with an error.

In the systemd logs:
May 11 01:34:30 morales.home.musique-ancienne.org rpc.idmapd[4961]: libnfsidmap: requested translation method, 'umich_ldap', is not available
May 11 01:34:30 morales.home.musique-ancienne.org rpc.idmapd[4961]: rpc.idmapd: libnfsidmap: requested translation method, 'umich_ldap', is not availa
May 11 01:34:30 morales.home.musique-ancienne.org rpc.idmapd[4961]: rpc.idmapd: Unable to create name to user id mappings.
May 11 01:34:30 morales.home.musique-ancienne.org systemd[1]: nfs-idmap.service: control process exited, code=exited status=1
May 11 01:34:30 morales.home.musique-ancienne.org systemd[1]: Failed to start NFSv4 ID-name mapping daemon.
May 11 01:34:30 morales.home.musique-ancienne.org systemd[1]: Unit nfs-idmap.service entered failed state

BTW the more I use systemd, the more I hate it for its unability to signal correctly all the errors in std logs !! It makes admin jobs longer, more painful, and is ridiculously unfriendly. I really regret more and more SysVinit !

When searching on google, you can find that it seems to be an error with plugins in /usr/lib64/libnfsidmap0/ which contains /usr/lib64/libnfsidmap0/umich_ldap.so but which doesn't load; Removing that translation from the idmapd.conf file remove the problem.

Probably related to https://bugzilla.redhat.com/show_bug.cgi?id=664641 and http://web.archiveorange.com/archive/v/wmeLD9mlppUGbXgPfHV8

This is minor, as this is not the default conf for Mageia.

Comment 1 Thomas Backlund 2013-05-11 00:08:37 CEST

if you want old-style logging, install rsyslog

CC: (none) => tmb

Comment 2 Bruno Cornec 2013-05-11 01:39:39 CEST

rsyslog in installed, but that doesn't make systemd more friendly by itself.
Also to debug a problem, it was easy to do sh -x /etc/init.d/script, now you have to dig much more, if you can :-(

Comment 3 Sander Lepik 2013-05-11 10:37:51 CEST

I don't understand. Maybe you just don't know how to use the tools?

systemctl status -n50 nfs-idmap.service would give you pretty good output of what went wrong. You can also increase 50 if relevant log is longer.

Or you can use journalctl -b --unit nfs-idmap.service to get the whole log since last boot.

http://0pointer.de/blog/projects/journalctl.html - many other good examples.

If you have bash-completion installed you can complete commands with TAB.

I think you need to dig into manual :)

CC: (none) => sander.lepik

Comment 4 Samuel Verschelde 2015-05-06 20:52:55 CEST

Assigning to maintainer, but please make sure it's still valid in recent cauldron and add a comment to confirm it.

Keywords: (none) => NEEDINFO, Triaged
Assignee: bugsquad => guillomovitch
Source RPM: (none) => nfs-utils

Comment 5 Guillaume Rousse 2015-05-13 23:36:01 CEST

Actually, they are two issues here:
- the fact than LDAP plugin build was broken, making it unusable: this is a bug, and I just fixed in libnfsidmap-0.25-8.mga5 (freeze push requested)
- the fact than LDAP plugin blocks rpc.idmapd launch if required parameters (LDAP_server and LDAP_base) are missing in configuration file: this is not really a bug, rather a design issue, and I can't do much here.

Comment 6 Guillaume Rousse 2015-07-09 19:04:43 CEST

Fixed in Cauldron (first issue, at least), closing.

Status: NEW => RESOLVED
Resolution: (none) => FIXED