NetBSD Problem Report #49601

From tron@zhadum.org.uk  Sat Jan 24 14:03:19 2015
Return-Path: <tron@zhadum.org.uk>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id F3F06A5B2E
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 24 Jan 2015 14:03:18 +0000 (UTC)
Message-Id: <20150124140314.863F3A3BA40@mail.zhadum.org.uk>
Date: Sat, 24 Jan 2015 14:03:14 +0000 (GMT)
From: tron@zhadum.org.uk
Reply-To: tron@zhadum.org.uk
To: gnats-bugs@NetBSD.org
Subject: amd(8) no longer works, at least in LDAP mode
X-Send-Pr-Version: 3.95

>Number:         49601
>Category:       bin
>Synopsis:       amd(8) no longer works, at least in LDAP mode
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jan 24 14:05:00 +0000 2015
>Last-Modified:  Sun Jan 25 09:10:00 +0000 2015
>Originator:     Matthias Scheler
>Release:        NetBSD 7.99.4 sources from HEAD as 2015-01-24 8:00 UTC
>Organization:
Matthias Scheler                                 https://zhadum.org.uk/
>Environment:
System: NetBSD lyssa.zhadum.org.uk 7.99.4 NetBSD 7.99.4 (GENERIC) #0: Sat Jan 24 13:37:20 GMT 2015  tron@lyssa.zhadum.org.uk:/src/sys/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
After upgrading my NetBSD/amd64 current VM from a 2015-01-14 to 2015-01-24
sources amd(8) doesn't come up when the machine boots. It logs the
following error message via syslog(3):


>How-To-Repeat:
Try to use amd(8) configured to use LDAP as the directory service.
My "/etc/amd.conf" looks like this:

Jan 24 13:45:17 lyssa amd[517]: failed to initialize map amd.share
Jan 24 13:45:17 lyssa amd[517]: No source data for map amd.share
Jan 24 13:48:28 lyssa /netbsd: kern.module.path=/stand/amd64/7.99.4/modules
Jan 24 13:48:35 lyssa amd[517]: failed to initialize map amd.share
Jan 24 13:48:35 lyssa amd[517]: No source data for map amd.share

Any access to an amd(8) auto-mounted directory just hangs:

root@lyssa:~#cd /home/tron &
[1] 2039
root@lyssa:~#jobs
[1]  + running    cd /home/tron

[global]
auto_attrcache     = 1
ldap_base          = dc=zhadum,dc=org,dc=uk
ldap_hostports     = zhadum.org.uk
ldap_proto_version = 3
nfs_proto          = udp
search_path        = /etc/amd
unmount_on_exit    = yes

[ /home ]
map_name =      amd.home
map_type =      ldap

[ /share ]
map_name =      amd.share
map_type =      ldap

[ /scratch ]
map_name =      amd.scratch
map_type =      ldap

[ /volumes ]
map_name =      volumes
map_type =      file

>Fix:
Reverting my machine to the previous current build fixes the problem.
My Mac OS X NFS client also shows no LDAP problem. This probably rules
out a problem with the LDAP/NFS server.

>Audit-Trail:
From: Matthias Scheler <tron@zhadum.org.uk>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/49601: amd(8) no longer works, at least in LDAP mode
Date: Sat, 24 Jan 2015 17:01:34 +0000

 On Sat, Jan 24, 2015 at 02:05:00PM +0000, gnats-admin@netbsd.org wrote:
 > Thank you very much for your problem report.
 > It has the internal identification `bin/49601'.
 > The individual assigned to look at your
 > report is: bin-bug-people. 
 > 
 > >Category:       bin
 > >Responsible:    bin-bug-people
 > >Synopsis:       amd(8) no longer works, at least in LDAP mode
 > >Arrival-Date:   Sat Jan 24 14:05:00 +0000 2015

 Rebuilding "am-utils" using source from 2015-01-16 and using those with
 kernel, userland etc. from 2015-01-24 fixes the problem as well.

 	Kind regards

 -- 
 Matthias Scheler                                 https://zhadum.org.uk/

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: bin/49601: amd(8) no longer works, at least in LDAP mode
Date: Sat, 24 Jan 2015 16:19:15 -0500

 On Jan 24,  2:05pm, tron@zhadum.org.uk (tron@zhadum.org.uk) wrote:
 -- Subject: bin/49601: amd(8) no longer works, at least in LDAP mode

 Yes, the problem seems to be LDAP. I don't have ldap here, so I can't test...
 Can you turn on debugging and see if there is any more info?

 christos

From: Matthias Scheler <tron@zhadum.org.uk>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@NetBSD.org
Subject: Re: bin/49601: amd(8) no longer works, at least in LDAP mode
Date: Sat, 24 Jan 2015 22:54:27 +0000

 On Sat, Jan 24, 2015 at 09:20:01PM +0000, Christos Zoulas wrote:
 >  On Jan 24,  2:05pm, tron@zhadum.org.uk (tron@zhadum.org.uk) wrote:
 >  -- Subject: bin/49601: amd(8) no longer works, at least in LDAP mode
 >  
 >  Yes, the problem seems to be LDAP. I don't have ldap here,
 > so I can't test...

 I can provide you access to the VM if that helps.

 >  Can you turn on debugging and see if there is any more info?

 Can you please suggest the appropriate options? The manual page
 doesn't explain the "-D" option very well.

 	Kind regards

 -- 
 Matthias Scheler                                 https://zhadum.org.uk/

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, 
	tron@zhadum.org.uk
Cc: 
Subject: Re: bin/49601: amd(8) no longer works, at least in LDAP mode
Date: Sat, 24 Jan 2015 17:57:48 -0500

 On Jan 24, 10:55pm, tron@zhadum.org.uk (Matthias Scheler) wrote:
 -- Subject: Re: bin/49601: amd(8) no longer works, at least in LDAP mode

 | The following reply was made to PR bin/49601; it has been noted by GNATS.
 | 
 | From: Matthias Scheler <tron@zhadum.org.uk>
 | To: Christos Zoulas <christos@zoulas.com>
 | Cc: gnats-bugs@NetBSD.org
 | Subject: Re: bin/49601: amd(8) no longer works, at least in LDAP mode
 | Date: Sat, 24 Jan 2015 22:54:27 +0000
 | 
 |  On Sat, Jan 24, 2015 at 09:20:01PM +0000, Christos Zoulas wrote:
 |  >  On Jan 24,  2:05pm, tron@zhadum.org.uk (tron@zhadum.org.uk) wrote:
 |  >  -- Subject: bin/49601: amd(8) no longer works, at least in LDAP mode
 |  >  
 |  >  Yes, the problem seems to be LDAP. I don't have ldap here,
 |  > so I can't test...
 |  
 |  I can provide you access to the VM if that helps.

 Sure.

 |  >  Can you turn on debugging and see if there is any more info?
 |  
 |  Can you please suggest the appropriate options? The manual page
 |  doesn't explain the "-D" option very well.

 There are too many, I usually -Dall.

 christos

From: Matthias Scheler <tron@zhadum.org.uk>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/49601: amd(8) no longer works, at least in LDAP mode
Date: Sun, 25 Jan 2015 09:05:14 +0000

 On Sat, Jan 24, 2015 at 05:01:34PM +0000, Matthias Scheler wrote:
 > On Sat, Jan 24, 2015 at 02:05:00PM +0000, gnats-admin@netbsd.org wrote:
 > > Thank you very much for your problem report.
 > > It has the internal identification `bin/49601'.
 > > The individual assigned to look at your
 > > report is: bin-bug-people. 
 > > 
 > > >Category:       bin
 > > >Responsible:    bin-bug-people
 > > >Synopsis:       amd(8) no longer works, at least in LDAP mode
 > > >Arrival-Date:   Sat Jan 24 14:05:00 +0000 2015
 > 
 > Rebuilding "am-utils" using source from 2015-01-16 and using those with
 > kernel, userland etc. from 2015-01-24 fixes the problem as well.

 Christous Zoulas came up with a work around in the meantime. If you add
 "map_type = ldap" to the "[global]" section of "amd.conf" auto mounting
 works on my setup.

 I think there at least two bugs in amd(8):
 1.) The configuration parser is somehow broken.
 2.) If amd(8) fails to load the maps it exists without unregistering
     its mountpoints which is why access to "/home/tron" hung on my system.

 	Kind regards

 -- 
 Matthias Scheler                                 https://zhadum.org.uk/

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.