You are not logged in.

#1 2017-01-12 22:15:54

pgoetz
Member
From: Austin, Texas
Registered: 2014-02-21
Posts: 341

autofs core dumps when I try to configure it to use LDAP

Clearly I need to file this as a bug with upstream (under no circumstances should a service core dump based on the contents of a configuration file), but just checking to see if anyone else has seen this or sees what my mistake is.

We have an LDAP server which contains the autofs maps.  There are a couple of hundred Ubuntu 14.04 desktops using these maps daily, so the LDAP server side of this all works, at least with older versions of the desktop software.

I have LDAP more or less working on my up-to-date Arch machine, and before messing with the /etc/autofs/autofs_ldap_auth.conf file, autofs started with no issues.  In order to get autofs to actually do something (again, all the maps are stored on the LDAP server), I modified the default /etc/autofs/autofs_ldap_auth.conf to be this:

<autofs_ldap_sasl_conf
	usetls="yes"
	tlsrequired="yes"
	authrequired="yes"
	authtype="EXTERNAL"
	external_cert="etc/openldap/ca-cert.pem"
/>

As soon as I do this,

systemctl start autofs

results in a core dump:

an 12 14:55:33 lizard systemd[1]: Starting Automounts filesystems on demand...
Jan 12 14:55:33 lizard systemd[1]: Started Process Core Dump (PID 16463/UID 0).
Jan 12 14:55:33 lizard systemd[1]: autofs.service: Control process exited, code=exited status=1
Jan 12 14:55:33 lizard systemd[1]: Failed to start Automounts filesystems on demand.
Jan 12 14:55:33 lizard systemd[1]: autofs.service: Unit entered failed state.
Jan 12 14:55:33 lizard systemd[1]: autofs.service: Failed with result 'exit-code'.
Jan 12 14:55:33 lizard systemd-coredump[16464]: Process 16458 (automount) of user 0 dumped core.

                                                Stack trace of thread 16458:
                                                #0  0x00007f547ac6804f raise (libc.so.6)
                                                #1  0x00007f547ac6947a abort (libc.so.6)
                                                #2  0x00007f547aca5c50 __libc_message (libc.so.6)
                                                #3  0x00007f547acabfe6 malloc_printerr (libc.so.6)
                                                #4  0x00007f547acac7de _int_free (libc.so.6)
                                                #5  0x00007f5479a265c5 n/a (lookup_ldap.so)
                                                #6  0x00007f5479a2ce78 lookup_done (lookup_ldap.so)
                                                #7  0x000055b1ce49f050 close_lookup (automount)
                                                #8  0x000055b1ce49f934 n/a (automount)
                                                #9  0x000055b1ce4a0632 lookup_nss_read_master (automount)
                                                #10 0x00007f547a2cf267 lookup_read_master (lookup_files.so)
                                                #11 0x000055b1ce49f928 n/a (automount)
                                                #12 0x000055b1ce49fa40 n/a (automount)
                                                #13 0x000055b1ce4a0632 lookup_nss_read_master (automount)
                                                #14 0x000055b1ce4b2f98 master_read_master (automount)
                                                #15 0x000055b1ce493e79 main (automount)
                                                #16 0x00007f547ac55291 __libc_start_main (libc.so.6)
                                                #17 0x000055b1ce4940ba _start (automount)

                                                Stack trace of thread 16460:
                                                #0  0x00007f547b54c10f pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                                                #1  0x000055b1ce4a3b57 n/a (automount)
                                                #2  0x00007f547b546454 start_thread (libpthread.so.0)
                                                #3  0x00007f547ad1d7df __clone (libc.so.6)

                                                Stack trace of thread 16459:
                                                #0  0x00007f547b54c10f pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                                                #1  0x000055b1ce4af1e3 n/a (automount)

Reverting the autofs_ldap_auth.conf file to

<autofs_ldap_sasl_conf
	usetls="no"
	tlsrequired="no"
	authrequired="no"
/>

and autofss successfully starts again (but can't do anything because it can't read the maps stored on the LDAP server.

Any thoughts/suggestions welcome.  I have to get my workstation functional again, so will be making local copies of the autofs maps, but really it should work with LDAP as advertised as well.

Offline

Board footer

Powered by FluxBB