autofs will not find auto.master in LDAP

[Brendan Kearney]

i have a fedora 20 install on a desktop that is working and autofs will 
read the auto.master from ldap and i can mount the shares specified in 
auto.shares listed.

i have a fedora 20 install on a laptop that will not work and cannot 
read the auto.master from ldap.

i have done everything i can think of to make the 2 as "apples to 
apples" identical as i can, but still cannot get autofs to read the 
auto.master from ldap.

[root@laptop ~]# automount -fd -vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
Starting automounter version 5.0.7-42.fc20, master map auto.master
using kernel protocol version 5.02
lookup_nss_read_master: reading master sss auto.master
parse_init: parse(sun): init gathered global options: (null)
spawn_mount: mtab link detected, passing -n to mount
spawn_umount: mtab link detected, passing -n to mount
setautomntent: lookup(sss): setautomntent: No such file or directory
lookup_nss_read_master: auto.master not found, replacing '.' with '_'
parse_init: parse(sun): init gathered global options: (null)
spawn_mount: mtab link detected, passing -n to mount
spawn_umount: mtab link detected, passing -n to mount
setautomntent: lookup(sss): setautomntent: No such file or directory
no mounts in table
^Cautofs stopped

i believe i am hung up by the setautomntent: no such file or directory 
line.  the configs are pretty much copied from the working desktop.  any 
help is appreciated.

*sssd.conf**:*
[sssd]
domains = bpk2.com
services = nss, pam, sudo, autofs
config_file_version = 2
#debug_level = 4

[nss]
filter_groups = root
filter_users = root

[pam]

[sudo]

[autofs]

[domain/bpk2.com]
#debug_level = 4
id_provider = ldap
ldap_schema = rfc2307bis
ldap_uri = _srv_,ldap://ldap1.bpk2.com,ldap://ldap2.bpk2.com
ldap_search_base = dc=bpk2,dc=com
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/laptop.bpk2.com
ldap_sasl_realm = BPK2.COM

auth_provider = krb5
krb5_server = _srv_,kerberos.bpk2.com
krb5_realm = BPK2.COM
krb5_renewable_lifetime = 7d
krb5_lifetime = 24h
krb5_renew_interval = 1h
krb5_store_password_if_offline = true
cache_credentials = true

sudo_provider = ldap
ldap_sudo_search_base = ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com

autofs_provider = ldap
ldap_autofs_search_base = cn=autofs,ou=Daemons,dc=bpk2,dc=com
ldap_autofs_map_object_class = automountMap
ldap_autofs_entry_object_class = automount
ldap_autofs_map_name = automountMapName
ldap_autofs_entry_key = automountKey
ldap_autofs_entry_value = automountInformation

#min_id = 1000
#max_id = 2000
enumerate = false

*autofs_ldap_auth.conf**:*
<?xml version="1.0" ?>
<!--
This files contains a single entry with multiple attributes tied to it.
See autofs_ldap_auth.conf(5) for more information.
-->

<autofs_ldap_sasl_conf
     usetls="no"
     tlsrequired="no"
     authrequired="yes"
     authtype="GSSAPI"
     clientprinc=&quot;host/laptop.bpk2.com(a)BPK2.COM&quot;
/>

*/etc/sysconfig/autofs |grep -v \^\#**:*
TIMEOUT=300
BROWSE_MODE="no"
MOUNT_NFS_DEFAULT_PROTOCOL=4
LDAP_URI="ldap:///dc=bpk2,dc=com"
SEARCH_BASE="cn=autofs,ou=Daemons,dc=bpk2,dc=com"
MAP_OBJECT_CLASS="automountMap"
ENTRY_OBJECT_CLASS="automount"
MAP_ATTRIBUTE="automountMapName"
ENTRY_ATTRIBUTE="automountKey"
VALUE_ATTRIBUTE="automountInformation"
AUTH_CONF_FILE="/etc/autofs_ldap_auth.conf"
USE_MISC_DEVICE="yes"

[Jakub Hrozek]

On Wed, Aug 12, 2015 at 09:48:38PM -0400, Brendan Kearney wrote:
>  i have a fedora 20 install on a desktop that is working and autofs
> will read
>  the auto.master from ldap and i can mount the shares specified in
>  auto.shares listed.
>  
>  i have a fedora 20 install on a laptop that will not work and cannot read
>  the auto.master from ldap.
>  
>  i have done everything i can think of to make the 2 as "apples to apples"
>  identical as i can, but still cannot get autofs to read the auto.master from
>  ldap.
>  
>  [root@laptop ~]# automount -fd -vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
>  Starting automounter version 5.0.7-42.fc20, master map auto.master
>  using kernel protocol version 5.02
>  lookup_nss_read_master: reading master sss auto.master
>  parse_init: parse(sun): init gathered global options: (null)
>  spawn_mount: mtab link detected, passing -n to mount
>  spawn_umount: mtab link detected, passing -n to mount
>  setautomntent: lookup(sss): setautomntent: No such file or directory
>  lookup_nss_read_master: auto.master not found, replacing '.' with '_'
>  parse_init: parse(sun): init gathered global options: (null)
>  spawn_mount: mtab link detected, passing -n to mount
>  spawn_umount: mtab link detected, passing -n to mount
>  setautomntent: lookup(sss): setautomntent: No such file or directory 
This message just means that there are no more maps in the table.

>  no mounts in table
>  ^Cautofs stopped
>  
>  i believe i am hung up by the setautomntent: no such file or directory line.
>  the configs are pretty much copied from the working desktop.  any help is
>  appreciated.
>  
>  *sssd.conf**:*
>  [sssd]
>  domains = bpk2.com
>  services = nss, pam, sudo, autofs
>  config_file_version = 2
>  #debug_level = 4
>  
>  [nss]
>  filter_groups = root
>  filter_users = root
>  
>  [pam]
>  
>  [sudo]
>  
>  [autofs]
>  
>  [domain/bpk2.com]
>  #debug_level = 4
>  id_provider = ldap
>  ldap_schema = rfc2307bis
>  ldap_uri = _srv_,ldap://ldap1.bpk2.com,ldap://ldap2.bpk2.com
>  ldap_search_base = dc=bpk2,dc=com
>  ldap_sasl_mech = GSSAPI
>  ldap_sasl_authid = host/laptop.bpk2.com
>  ldap_sasl_realm = BPK2.COM
>  
>  auth_provider = krb5
>  krb5_server = _srv_,kerberos.bpk2.com
>  krb5_realm = BPK2.COM
>  krb5_renewable_lifetime = 7d
>  krb5_lifetime = 24h
>  krb5_renew_interval = 1h
>  krb5_store_password_if_offline = true
>  cache_credentials = true
>  
>  sudo_provider = ldap
>  ldap_sudo_search_base = ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com
>  
>  autofs_provider = ldap
>  ldap_autofs_search_base = cn=autofs,ou=Daemons,dc=bpk2,dc=com
>  ldap_autofs_map_object_class = automountMap
>  ldap_autofs_entry_object_class = automount
>  ldap_autofs_map_name = automountMapName
>  ldap_autofs_entry_key = automountKey
>  ldap_autofs_entry_value = automountInformation
>  
>  #min_id = 1000
>  #max_id = 2000
>  enumerate = false 
The config looks OK..

>  
>  *autofs_ldap_auth.conf**:* 
You don't need this config file unless you're also using the ldap direct
integration.

I would suggest to debug like this:
    - stop automounter
    - enable verbose (7+) debug_level in the autofs and domain sections
    - start sssd
    - run 'date' to pair the timestamp in the logs with the system clock 
    - start automounter -m on the foreground
    - run date again to know the timestamp of request end
    - check out autofs responder and domain logs

[Brendan Kearney]

On 08/13/2015 03:45 AM, Jakub Hrozek wrote:
>  On Wed, Aug 12, 2015 at 09:48:38PM -0400, Brendan Kearney wrote:
> > i have a fedora 20 install on a desktop that is working and autofs will read
> > the auto.master from ldap and i can mount the shares specified in
> > auto.shares listed.
> >
> > i have a fedora 20 install on a laptop that will not work and cannot read
> > the auto.master from ldap.
> >
> > i have done everything i can think of to make the 2 as "apples to apples"
> > identical as i can, but still cannot get autofs to read the auto.master from
> > ldap.
> >
> > [root@laptop ~]# automount -fd -vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> > Starting automounter version 5.0.7-42.fc20, master map auto.master
> > using kernel protocol version 5.02
> > lookup_nss_read_master: reading master sss auto.master
> > parse_init: parse(sun): init gathered global options: (null)
> > spawn_mount: mtab link detected, passing -n to mount
> > spawn_umount: mtab link detected, passing -n to mount
> > setautomntent: lookup(sss): setautomntent: No such file or directory
> > lookup_nss_read_master: auto.master not found, replacing '.' with
> '_'
> > parse_init: parse(sun): init gathered global options: (null)
> > spawn_mount: mtab link detected, passing -n to mount
> > spawn_umount: mtab link detected, passing -n to mount
> > setautomntent: lookup(sss): setautomntent: No such file or directory
>  This message just means that there are no more maps in the table.
>
> > no mounts in table
> > ^Cautofs stopped
> >
> > i believe i am hung up by the setautomntent: no such file or directory line.
> > the configs are pretty much copied from the working desktop.  any help is
> > appreciated.
> >
> > *sssd.conf**:*
> > [sssd]
> > domains = bpk2.com
> > services = nss, pam, sudo, autofs
> > config_file_version = 2
> > #debug_level = 4
> >
> > [nss]
> > filter_groups = root
> > filter_users = root
> >
> > [pam]
> >
> > [sudo]
> >
> > [autofs]
> >
> > [domain/bpk2.com]
> > #debug_level = 4
> > id_provider = ldap
> > ldap_schema = rfc2307bis
> > ldap_uri = _srv_,ldap://ldap1.bpk2.com,ldap://ldap2.bpk2.com
> > ldap_search_base = dc=bpk2,dc=com
> > ldap_sasl_mech = GSSAPI
> > ldap_sasl_authid = host/laptop.bpk2.com
> > ldap_sasl_realm = BPK2.COM
> >
> > auth_provider = krb5
> > krb5_server = _srv_,kerberos.bpk2.com
> > krb5_realm = BPK2.COM
> > krb5_renewable_lifetime = 7d
> > krb5_lifetime = 24h
> > krb5_renew_interval = 1h
> > krb5_store_password_if_offline = true
> > cache_credentials = true
> >
> > sudo_provider = ldap
> > ldap_sudo_search_base = ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com
> >
> > autofs_provider = ldap
> > ldap_autofs_search_base = cn=autofs,ou=Daemons,dc=bpk2,dc=com
> > ldap_autofs_map_object_class = automountMap
> > ldap_autofs_entry_object_class = automount
> > ldap_autofs_map_name = automountMapName
> > ldap_autofs_entry_key = automountKey
> > ldap_autofs_entry_value = automountInformation
> >
> > #min_id = 1000
> > #max_id = 2000
> > enumerate = false
>  The config looks OK..
>
> > *autofs_ldap_auth.conf**:*
>  You don't need this config file unless you're also using the ldap direct
>  integration.
>
>  I would suggest to debug like this:
>       - stop automounter
>       - enable verbose (7+) debug_level in the autofs and domain sections
>       - start sssd
>       - run 'date' to pair the timestamp in the logs with the system clock
>       - start automounter -m on the foreground
>       - run date again to know the timestamp of request end
>       - check out autofs responder and domain logs
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users 
[root@laptop ~]# date
Thu Aug 13 17:06:07 EDT 2015
[root@laptop ~]# automount -m

autofs dump map information
===========================

global options: none configured
no master map entries found

[root@laptop ~]# date
Thu Aug 13 17:06:22 EDT 2015

[root@laptop ~]# journalctl -u autofs
...
Aug 13 17:05:12 laptop systemd[1]: Stopped Automounts filesystems on demand.

[root@laptop ~]# journalctl -u sssd
...
Aug 13 17:06:12 laptop sssd_be[16364]: ldapdb_canonuser_plug_init() 
failed in sasl_canonuser_add_plugin(): invalid parameter supplied
Aug 13 17:06:12 laptop sssd_be[16364]: _sasl_plugin_load failed on 
sasl_canonuser_init for plugin: ldapdb
Aug 13 17:06:12 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:12 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:12 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:12 laptop sssd_be[16364]: GSSAPI client step 2
Aug 13 17:06:15 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:15 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 2
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 2
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 2
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 2
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 2
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 2
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 2
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 1
Aug 13 17:06:16 laptop sssd_be[16364]: GSSAPI client step 2

the ldap_canonuser_plug_init message is a red-herring.  i see that in my 
working instance on the desktop, and it does not affect the (in)ability 
to enumerate the automount maps from ldap.

[Jakub Hrozek]

On Thu, Aug 13, 2015 at 05:11:41PM -0400, Brendan Kearney wrote:
>  On 08/13/2015 03:45 AM, Jakub Hrozek wrote:
>  >On Wed, Aug 12, 2015 at 09:48:38PM -0400, Brendan Kearney wrote:
>  >>i have a fedora 20 install on a desktop that is working and autofs will read
>  >>the auto.master from ldap and i can mount the shares specified in
>  >>auto.shares listed.
>  >>
>  >>i have a fedora 20 install on a laptop that will not work and cannot read
>  >>the auto.master from ldap.
>  >>
>  >>i have done everything i can think of to make the 2 as "apples to
> apples"
>  >>identical as i can, but still cannot get autofs to read the auto.master from
>  >>ldap.
>  >>
>  >>[root@laptop ~]# automount -fd -vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
>  >>Starting automounter version 5.0.7-42.fc20, master map auto.master
>  >>using kernel protocol version 5.02
>  >>lookup_nss_read_master: reading master sss auto.master
>  >>parse_init: parse(sun): init gathered global options: (null)
>  >>spawn_mount: mtab link detected, passing -n to mount
>  >>spawn_umount: mtab link detected, passing -n to mount
>  >>setautomntent: lookup(sss): setautomntent: No such file or directory
>  >>lookup_nss_read_master: auto.master not found, replacing '.' with
> '_'
>  >>parse_init: parse(sun): init gathered global options: (null)
>  >>spawn_mount: mtab link detected, passing -n to mount
>  >>spawn_umount: mtab link detected, passing -n to mount
>  >>setautomntent: lookup(sss): setautomntent: No such file or directory
>  >This message just means that there are no more maps in the table.
>  >
>  >>no mounts in table
>  >>^Cautofs stopped
>  >>
>  >>i believe i am hung up by the setautomntent: no such file or directory line.
>  >>the configs are pretty much copied from the working desktop.  any help is
>  >>appreciated.
>  >>
>  >>*sssd.conf**:*
>  >>[sssd]
>  >>domains = bpk2.com
>  >>services = nss, pam, sudo, autofs
>  >>config_file_version = 2
>  >>#debug_level = 4
>  >>
>  >>[nss]
>  >>filter_groups = root
>  >>filter_users = root
>  >>
>  >>[pam]
>  >>
>  >>[sudo]
>  >>
>  >>[autofs]
>  >>
>  >>[domain/bpk2.com]
>  >>#debug_level = 4
>  >>id_provider = ldap
>  >>ldap_schema = rfc2307bis
>  >>ldap_uri = _srv_,ldap://ldap1.bpk2.com,ldap://ldap2.bpk2.com
>  >>ldap_search_base = dc=bpk2,dc=com
>  >>ldap_sasl_mech = GSSAPI
>  >>ldap_sasl_authid = host/laptop.bpk2.com
>  >>ldap_sasl_realm = BPK2.COM
>  >>
>  >>auth_provider = krb5
>  >>krb5_server = _srv_,kerberos.bpk2.com
>  >>krb5_realm = BPK2.COM
>  >>krb5_renewable_lifetime = 7d
>  >>krb5_lifetime = 24h
>  >>krb5_renew_interval = 1h
>  >>krb5_store_password_if_offline = true
>  >>cache_credentials = true
>  >>
>  >>sudo_provider = ldap
>  >>ldap_sudo_search_base = ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com
>  >>
>  >>autofs_provider = ldap
>  >>ldap_autofs_search_base = cn=autofs,ou=Daemons,dc=bpk2,dc=com
>  >>ldap_autofs_map_object_class = automountMap
>  >>ldap_autofs_entry_object_class = automount
>  >>ldap_autofs_map_name = automountMapName
>  >>ldap_autofs_entry_key = automountKey
>  >>ldap_autofs_entry_value = automountInformation
>  >>
>  >>#min_id = 1000
>  >>#max_id = 2000
>  >>enumerate = false
>  >The config looks OK..
>  >
>  >>*autofs_ldap_auth.conf**:*
>  >You don't need this config file unless you're also using the ldap direct
>  >integration.
>  >
>  >I would suggest to debug like this:
>  >     - stop automounter
>  >     - enable verbose (7+) debug_level in the autofs and domain sections
>  >     - start sssd
>  >     - run 'date' to pair the timestamp in the logs with the system clock
>  >     - start automounter -m on the foreground
>  >     - run date again to know the timestamp of request end
>  >     - check out autofs responder and domain logs
>  >_______________________________________________
>  >sssd-users mailing list
>  >sssd-users(a)lists.fedorahosted.org
>  >https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>  [root@laptop ~]# date
>  Thu Aug 13 17:06:07 EDT 2015
>  [root@laptop ~]# automount -m
>  
>  autofs dump map information
>  ===========================
>  
>  global options: none configured
>  no master map entries found
>  
>  [root@laptop ~]# date
>  Thu Aug 13 17:06:22 EDT 2015
>  
>  [root@laptop ~]# journalctl -u autofs
>  ...
>  Aug 13 17:05:12 laptop systemd[1]: Stopped Automounts filesystems on demand.
>  
>  [root@laptop ~]# journalctl -u sssd 
                   ~~~~~~~~~~~~~~~~~~

The useful info would be in /var/log/sssd/*.log. We don't really log too
much to journald by default (although it's possible to configure
journald to be used for debug messages as well).

See https://fedorahosted.org/sssd/wiki/Troubleshooting for more details
on getting the logs.

[Brendan Kearney]

I am using rsyslog RELP (reliable event log processing) to steal away logs
over syslog-tcp with fifo buffer to store them in a central database, so
journalctl is the only local log on the box.  The /var/log/sssd/* files are
mostly empty.  The only info in there is about an explicit kerberos setting
not being set and having to use a different directives value for kerberos.

Either way, the logs dont have much to go on.  I will check my database for
any of the logs I can find, but I think I did already and I dont think
there was other info in there.

I'll also see what I can do with the link you sent.

Thanks.
On Aug 14, 2015 4:20 AM, "Jakub Hrozek" <jhrozek(a)redhat.com&gt; wrote:

>  On Thu, Aug 13, 2015 at 05:11:41PM -0400, Brendan Kearney wrote:
>  > On 08/13/2015 03:45 AM, Jakub Hrozek wrote:
>  > >On Wed, Aug 12, 2015 at 09:48:38PM -0400, Brendan Kearney wrote:
>  > >>i have a fedora 20 install on a desktop that is working and autofs
>  will read
>  > >>the auto.master from ldap and i can mount the shares specified in
>  > >>auto.shares listed.
>  > >>
>  > >>i have a fedora 20 install on a laptop that will not work and cannot
>  read
>  > >>the auto.master from ldap.
>  > >>
>  > >>i have done everything i can think of to make the 2 as "apples to
>  apples"
>  > >>identical as i can, but still cannot get autofs to read the
>  auto.master from
>  > >>ldap.
>  > >>
>  > >>[root@laptop ~]# automount -fd -vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
>  > >>Starting automounter version 5.0.7-42.fc20, master map auto.master
>  > >>using kernel protocol version 5.02
>  > >>lookup_nss_read_master: reading master sss auto.master
>  > >>parse_init: parse(sun): init gathered global options: (null)
>  > >>spawn_mount: mtab link detected, passing -n to mount
>  > >>spawn_umount: mtab link detected, passing -n to mount
>  > >>setautomntent: lookup(sss): setautomntent: No such file or directory
>  > >>lookup_nss_read_master: auto.master not found, replacing '.' with
> '_'
>  > >>parse_init: parse(sun): init gathered global options: (null)
>  > >>spawn_mount: mtab link detected, passing -n to mount
>  > >>spawn_umount: mtab link detected, passing -n to mount
>  > >>setautomntent: lookup(sss): setautomntent: No such file or directory
>  > >This message just means that there are no more maps in the table.
>  > >
>  > >>no mounts in table
>  > >>^Cautofs stopped
>  > >>
>  > >>i believe i am hung up by the setautomntent: no such file or directory
>  line.
>  > >>the configs are pretty much copied from the working desktop.  any help
>  is
>  > >>appreciated.
>  > >>
>  > >>*sssd.conf**:*
>  > >>[sssd]
>  > >>domains = bpk2.com
>  > >>services = nss, pam, sudo, autofs
>  > >>config_file_version = 2
>  > >>#debug_level = 4
>  > >>
>  > >>[nss]
>  > >>filter_groups = root
>  > >>filter_users = root
>  > >>
>  > >>[pam]
>  > >>
>  > >>[sudo]
>  > >>
>  > >>[autofs]
>  > >>
>  > >>[domain/bpk2.com]
>  > >>#debug_level = 4
>  > >>id_provider = ldap
>  > >>ldap_schema = rfc2307bis
>  > >>ldap_uri = _srv_,ldap://ldap1.bpk2.com,ldap://ldap2.bpk2.com
>  > >>ldap_search_base = dc=bpk2,dc=com
>  > >>ldap_sasl_mech = GSSAPI
>  > >>ldap_sasl_authid = host/laptop.bpk2.com
>  > >>ldap_sasl_realm = BPK2.COM
>  > >>
>  > >>auth_provider = krb5
>  > >>krb5_server = _srv_,kerberos.bpk2.com
>  > >>krb5_realm = BPK2.COM
>  > >>krb5_renewable_lifetime = 7d
>  > >>krb5_lifetime = 24h
>  > >>krb5_renew_interval = 1h
>  > >>krb5_store_password_if_offline = true
>  > >>cache_credentials = true
>  > >>
>  > >>sudo_provider = ldap
>  > >>ldap_sudo_search_base = ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com
>  > >>
>  > >>autofs_provider = ldap
>  > >>ldap_autofs_search_base = cn=autofs,ou=Daemons,dc=bpk2,dc=com
>  > >>ldap_autofs_map_object_class = automountMap
>  > >>ldap_autofs_entry_object_class = automount
>  > >>ldap_autofs_map_name = automountMapName
>  > >>ldap_autofs_entry_key = automountKey
>  > >>ldap_autofs_entry_value = automountInformation
>  > >>
>  > >>#min_id = 1000
>  > >>#max_id = 2000
>  > >>enumerate = false
>  > >The config looks OK..
>  > >
>  > >>*autofs_ldap_auth.conf**:*
>  > >You don't need this config file unless you're also using the ldap
> direct
>  > >integration.
>  > >
>  > >I would suggest to debug like this:
>  > >     - stop automounter
>  > >     - enable verbose (7+) debug_level in the autofs and domain sections
>  > >     - start sssd
>  > >     - run 'date' to pair the timestamp in the logs with the system
>  clock
>  > >     - start automounter -m on the foreground
>  > >     - run date again to know the timestamp of request end
>  > >     - check out autofs responder and domain logs
>  > >_______________________________________________
>  > >sssd-users mailing list
>  > &gt;sssd-users(a)lists.fedorahosted.org
>  > >https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>  > [root@laptop ~]# date
>  > Thu Aug 13 17:06:07 EDT 2015
>  > [root@laptop ~]# automount -m
>  >
>  > autofs dump map information
>  > ===========================
>  >
>  > global options: none configured
>  > no master map entries found
>  >
>  > [root@laptop ~]# date
>  > Thu Aug 13 17:06:22 EDT 2015
>  >
>  > [root@laptop ~]# journalctl -u autofs
>  > ...
>  > Aug 13 17:05:12 laptop systemd[1]: Stopped Automounts filesystems on
>  demand.
>  >
>  > [root@laptop ~]# journalctl -u sssd
>                     ~~~~~~~~~~~~~~~~~~
>
>  The useful info would be in /var/log/sssd/*.log. We don't really log too
>  much to journald by default (although it's possible to configure
>  journald to be used for debug messages as well).
>
>  See https://fedorahosted.org/sssd/wiki/Troubleshooting for more details
>  on getting the logs.
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>

[Dmitri Pal]

On 08/14/2015 08:24 AM, brendan kearney wrote:
>  I am using rsyslog RELP (reliable event log processing) to steal away
>  logs over syslog-tcp with fifo buffer to store them in a central
>  database, so journalctl is the only local log on the box.  The
>  /var/log/sssd/* files are mostly empty.  The only info in there is
>  about an explicit kerberos setting not being set and having to use a
>  different directives value for kerberos.
>
>  Either way, the logs dont have much to go on. 
>  
You need to raise debug level for the logs to have more info.

>  I will check my database for any of the logs I can find, but I think
> I
>  did already and I dont think there was other info in there.
>
>  I'll also see what I can do with the link you sent.
>
>  Thanks.
>
>  On Aug 14, 2015 4:20 AM, "Jakub Hrozek" <jhrozek(a)redhat.com
>  <mailto:[e-mail]>> wrote:
>
>      On Thu, Aug 13, 2015 at 05:11:41PM -0400, Brendan Kearney wrote:
>      > On 08/13/2015 03:45 AM, Jakub Hrozek wrote:
>      > >On Wed, Aug 12, 2015 at 09:48:38PM -0400, Brendan Kearney wrote:
>      > >>i have a fedora 20 install on a desktop that is working and
>      autofs will read
>      > >>the auto.master from ldap and i can mount the shares specified in
>      > >>auto.shares listed.
>      > >>
>      > >>i have a fedora 20 install on a laptop that will not work and
>      cannot read
>      > >>the auto.master from ldap.
>      > >>
>      > >>i have done everything i can think of to make the 2 as "apples
>      to apples"
>      > >>identical as i can, but still cannot get autofs to read the
>      auto.master from
>      > >>ldap.
>      > >>
>      > >>[root@laptop ~]# automount -fd -vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
>      > >>Starting automounter version 5.0.7-42.fc20, master map auto.master
>      > >>using kernel protocol version 5.02
>      > >>lookup_nss_read_master: reading master sss auto.master
>      > >>parse_init: parse(sun): init gathered global options: (null)
>      > >>spawn_mount: mtab link detected, passing -n to mount
>      > >>spawn_umount: mtab link detected, passing -n to mount
>      > >>setautomntent: lookup(sss): setautomntent: No such file or
>      directory
>      > >>lookup_nss_read_master: auto.master not found, replacing '.'
>      with '_'
>      > >>parse_init: parse(sun): init gathered global options: (null)
>      > >>spawn_mount: mtab link detected, passing -n to mount
>      > >>spawn_umount: mtab link detected, passing -n to mount
>      > >>setautomntent: lookup(sss): setautomntent: No such file or
>      directory
>      > >This message just means that there are no more maps in the table.
>      > >
>      > >>no mounts in table
>      > >>^Cautofs stopped
>      > >>
>      > >>i believe i am hung up by the setautomntent: no such file or
>      directory line.
>      > >>the configs are pretty much copied from the working desktop. 
>      any help is
>      > >>appreciated.
>      > >>
>      > >>*sssd.conf**:*
>      > >>[sssd]
>      > >>domains = bpk2.com <http://bpk2.com>
>      > >>services = nss, pam, sudo, autofs
>      > >>config_file_version = 2
>      > >>#debug_level = 4
>      > >>
>      > >>[nss]
>      > >>filter_groups = root
>      > >>filter_users = root
>      > >>
>      > >>[pam]
>      > >>
>      > >>[sudo]
>      > >>
>      > >>[autofs]
>      > >>
>      > >>[domain/bpk2.com <http://bpk2.com>]
>      > >>#debug_level = 4
>      > >>id_provider = ldap
>      > >>ldap_schema = rfc2307bis
>      > >>ldap_uri = _srv_,ldap://ldap1.bpk2.com
>      <http://ldap1.bpk2.com>,ldap://ldap2.bpk2.com <http://ldap2.bpk2.com>
>      > >>ldap_search_base = dc=bpk2,dc=com
>      > >>ldap_sasl_mech = GSSAPI
>      > >>ldap_sasl_authid = host/laptop.bpk2.com <http://laptop.bpk2.com>
>      > >>ldap_sasl_realm = BPK2.COM <http://BPK2.COM>
>      > >>
>      > >>auth_provider = krb5
>      > >>krb5_server = _srv_,kerberos.bpk2.com <http://kerberos.bpk2.com>
>      > >>krb5_realm = BPK2.COM <http://BPK2.COM>
>      > >>krb5_renewable_lifetime = 7d
>      > >>krb5_lifetime = 24h
>      > >>krb5_renew_interval = 1h
>      > >>krb5_store_password_if_offline = true
>      > >>cache_credentials = true
>      > >>
>      > >>sudo_provider = ldap
>      > >>ldap_sudo_search_base = ou=SUDO Groups,ou=Roles,dc=bpk2,dc=com
>      > >>
>      > >>autofs_provider = ldap
>      > >>ldap_autofs_search_base = cn=autofs,ou=Daemons,dc=bpk2,dc=com
>      > >>ldap_autofs_map_object_class = automountMap
>      > >>ldap_autofs_entry_object_class = automount
>      > >>ldap_autofs_map_name = automountMapName
>      > >>ldap_autofs_entry_key = automountKey
>      > >>ldap_autofs_entry_value = automountInformation
>      > >>
>      > >>#min_id = 1000
>      > >>#max_id = 2000
>      > >>enumerate = false
>      > >The config looks OK..
>      > >
>      > >>*autofs_ldap_auth.conf**:*
>      > >You don't need this config file unless you're also using the
>      ldap direct
>      > >integration.
>      > >
>      > >I would suggest to debug like this:
>      > >     - stop automounter
>      > >     - enable verbose (7+) debug_level in the autofs and domain
>      sections
>      > >     - start sssd
>      > >     - run 'date' to pair the timestamp in the logs with the
>      system clock
>      > >     - start automounter -m on the foreground
>      > >     - run date again to know the timestamp of request end
>      > >     - check out autofs responder and domain logs
>      > >_______________________________________________
>      > >sssd-users mailing list
>      > &gt;sssd-users(a)lists.fedorahosted.org
>      <mailto:[e-mail]>
>      > >https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>      > [root@laptop ~]# date
>      > Thu Aug 13 17:06:07 EDT 2015
>      > [root@laptop ~]# automount -m
>      >
>      > autofs dump map information
>      > ===========================
>      >
>      > global options: none configured
>      > no master map entries found
>      >
>      > [root@laptop ~]# date
>      > Thu Aug 13 17:06:22 EDT 2015
>      >
>      > [root@laptop ~]# journalctl -u autofs
>      > ...
>      > Aug 13 17:05:12 laptop systemd[1]: Stopped Automounts
>      filesystems on demand.
>      >
>      > [root@laptop ~]# journalctl -u sssd
>                         ~~~~~~~~~~~~~~~~~~
>
>      The useful info would be in /var/log/sssd/*.log. We don't really
>      log too
>      much to journald by default (although it's possible to configure
>      journald to be used for debug messages as well).
>
>      See https://fedorahosted.org/sssd/wiki/Troubleshooting for more
>      details
>      on getting the logs.
>      _______________________________________________
>      sssd-users mailing list
>      sssd-users(a)lists.fedorahosted.org
>      <mailto:[e-mail]>
>      https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
>
>
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users 

-- 
Thank you,
Dmitri Pal

Engineering Director, Identity Management and Platform Security
Red Hat, Inc.

[Jakub Hrozek]

On Fri, Aug 14, 2015 at 08:26:57AM -0400, Dmitri Pal wrote:
>  On 08/14/2015 08:24 AM, brendan kearney wrote:
>  >
>  > I am using rsyslog RELP (reliable event log processing) to steal away
>  > logs over syslog-tcp with fifo buffer to store them in a central
>  > database, so journalctl is the only local log on the box.  The
>  > /var/log/sssd/* files are mostly empty.  The only info in there is
>  > about an explicit kerberos setting not being set and having to use a
>  > different directives value for kerberos.
>  >
>  > Either way, the logs dont have much to go on. 
>  >
>  
>  You need to raise debug level for the logs to have more info. 
Right, the default log level is 0. See:
    https://fedorahosted.org/sssd/wiki/Troubleshooting

btw sssd doesn't use syslog or journal by default to write the debug
logs. We simply open the files and fwrite() to them, so even though your
log config forwards syslog messages, the sssd log directory should
contain files once you raise the debug_level.

[Brendan Kearney]

I did.  debug_level was set to 10 in both two separate sectiins of the
config file.  You said to set it to at least 7 in both places.

I'll rerun things tonight and see if I can get something.

Thanks
On Aug 14, 2015 8:59 AM, "Jakub Hrozek" <jhrozek(a)redhat.com&gt; wrote:

>  On Fri, Aug 14, 2015 at 08:26:57AM -0400, Dmitri Pal wrote:
>  > On 08/14/2015 08:24 AM, brendan kearney wrote:
>  > >
>  > > I am using rsyslog RELP (reliable event log processing) to steal away
>  > > logs over syslog-tcp with fifo buffer to store them in a central
>  > > database, so journalctl is the only local log on the box.  The
>  > > /var/log/sssd/* files are mostly empty.  The only info in there is
>  > > about an explicit kerberos setting not being set and having to use a
>  > > different directives value for kerberos.
>  > >
>  > > Either way, the logs dont have much to go on.
>  > >
>  >
>  > You need to raise debug level for the logs to have more info.
>
>  Right, the default log level is 0. See:
>      https://fedorahosted.org/sssd/wiki/Troubleshooting
>
>  btw sssd doesn't use syslog or journal by default to write the debug
>  logs. We simply open the files and fwrite() to them, so even though your
>  log config forwards syslog messages, the sssd log directory should
>  contain files once you raise the debug_level.
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>

[Brendan Kearney]

On 08/14/2015 08:59 AM, Jakub Hrozek wrote:
>  On Fri, Aug 14, 2015 at 08:26:57AM -0400, Dmitri Pal wrote:
> > On 08/14/2015 08:24 AM, brendan kearney wrote:
> >> I am using rsyslog RELP (reliable event log processing) to steal away
> >> logs over syslog-tcp with fifo buffer to store them in a central
> >> database, so journalctl is the only local log on the box.  The
> >> /var/log/sssd/* files are mostly empty.  The only info in there is
> >> about an explicit kerberos setting not being set and having to use a
> >> different directives value for kerberos.
> >>
> >> Either way, the logs dont have much to go on.
> >>
> > You need to raise debug level for the logs to have more info.
>  Right, the default log level is 0. See:
>       https://fedorahosted.org/sssd/wiki/Troubleshooting
>
>  btw sssd doesn't use syslog or journal by default to write the debug
>  logs. We simply open the files and fwrite() to them, so even though your
>  log config forwards syslog messages, the sssd log directory should
>  contain files once you raise the debug_level.
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users 
you were correct.  the
log files were populated with output.

i found a ldap query in the logs, and ran it manually.  it came back 
with 4 auto.master entries.  there is one that would have been found 
with a "base" search, and 3 additional auto.masters that were found 
because the search was done as "sub".

i am experimenting with different autofs mounts for servers, 
workstations and other device types, hence the other auto.master entries 
in child OUs.  this testing was leading me to another question, which 
i'll ask in a bit.  to finish this out, i moved the testing autofs 
pieces from cn=autofs to cn=autofs-test and will keep the separation in 
place, as that seems to have fixed my issue.  does a directive exist to 
tell the search to be "base", "one" or "sub"?

the new question i have is around variable expansion.  it seems that i 
am missing something about how to do it right.  when i attempt to use 
$USER, say in /home/$USER, with a mountpoint of Music under it, the 
literal path /home/$USER is created.  i have tried /home/$USER, /home 
${USER} and /home /{$USER} and in each case, the literal path was 
created on disk.  the variable expansion do not occur and 
/home/<my_user_id>/Music was not automounted as per the autofs directives.

how do i get variable expansion to work when using SSSD?

[Jakub Hrozek]

>  On 15 Aug 2015, at 03:38, Brendan Kearney <bpk678(a)gmail.com&gt;
> wrote:
>  
>  On 08/14/2015 08:59 AM, Jakub Hrozek wrote:
> > On Fri, Aug 14, 2015 at 08:26:57AM -0400, Dmitri Pal wrote:
> >> On 08/14/2015 08:24 AM, brendan kearney wrote:
> >>> I am using rsyslog RELP (reliable event log processing) to steal away
> >>> logs over syslog-tcp with fifo buffer to store them in a central
> >>> database, so journalctl is the only local log on the box.  The
> >>> /var/log/sssd/* files are mostly empty.  The only info in there is
> >>> about an explicit kerberos setting not being set and having to use a
> >>> different directives value for kerberos.
> >>> 
> >>> Either way, the logs dont have much to go on.
> >>> 
> >> You need to raise debug level for the logs to have more info.
> > Right, the default log level is 0. See:
> >     https://fedorahosted.org/sssd/wiki/Troubleshooting
> > 
> > btw sssd doesn't use syslog or journal by default to write the debug
> > logs. We simply open the files and fwrite() to them, so even though your
> > log config forwards syslog messages, the sssd log directory should
> > contain files once you raise the debug_level.
> > _______________________________________________
> > sssd-users mailing list
> > sssd-users(a)lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>  you were correct.  the log files were populated with output.
>  
>  i found a ldap query in the logs, and ran it manually.  it came back with 4 auto.master
> entries.  there is one that would have been found with a "base" search, and 3
> additional auto.masters that were found because the search was done as "sub".
>  
>  i am experimenting with different autofs mounts for servers, workstations and other
> device types, hence the other auto.master entries in child OUs.  this testing was leading
> me to another question, which i'll ask in a bit.  to finish this out, i moved the
> testing autofs pieces from cn=autofs to cn=autofs-test and will keep the separation in
> place, as that seems to have fixed my issue.  does a directive exist to tell the search to
> be "base", "one" or "sub"? 
Maybe adding the scope to the autofs search base could do the trick, but I haven't
tested myself.

>  
>  the new question i have is around variable expansion.  it seems that i am missing
> something about how to do it right.  when i attempt to use $USER, say in /home/$USER, with
> a mountpoint of Music under it, the literal path /home/$USER is created.  i have tried
> /home/$USER, /home ${USER} and /home /{$USER} and in each case, the literal path was
> created on disk.  the variable expansion do not occur and /home/<my_user_id>/Music
> was not automounted as per the autofs directives.
>   
To be honest, I don't really know..does the same setup work if you just swap ldap for
sss?

The thing is that SSSD just fetches the maps and keys and lets automounter do the work. In
case of autofs caching, sssd is more or less a dumb proxy.

>  how do i get variable expansion to work when using SSSD?
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Ondrej Valousek]

Did not try the variable expansion for ages, but it definitely works with maps in NIS.
Also, did you consider using asterisk (*) for autofs maps expansion? It works perfectly,
even with ldap/sssd.
But as Jakub said - this has nothing to do with sssd, this is just automounter-specific
thing.
Ondrej

>  
>  the new question i have is around variable expansion.  it seems that i am missing
> something about how to do it right.  when i attempt to use $USER, say in /home/$USER, with
> a mountpoint of Music under it, the literal path /home/$USER is created.  i have tried
> /home/$USER, /home ${USER} and /home /{$USER} and in each case, the literal path was
> created on disk.  the variable expansion do not occur and /home/<my_user_id>/Music
> was not automounted as per the autofs directives.
>  
>  
To be honest, I don't really know..does the same setup work if you just swap ldap for
sss?

The thing is that SSSD just fetches the maps and keys and lets automounter do the work. In
case of autofs caching, sssd is more or less a dumb proxy.

>  how do i get variable expansion to work when using SSSD?
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>  
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

-----

The information contained in this e-mail and in any attachments is confidential and is
designated solely for the attention of the intended recipient(s). If you are not an
intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
any part thereof. If you have received this e-mail in error, please notify the sender by
return e-mail and delete all copies of this e-mail from your computer system(s). Please
direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
South County Business Park, Leopardstown, Dublin 18.

[Brendan Kearney]

On 08/18/2015 03:55 AM, Ondrej Valousek wrote:
>  Did not try the variable expansion for ages, but it definitely works
> with maps in NIS.
>  Also, did you consider using asterisk (*) for autofs maps expansion? It works perfectly,
> even with ldap/sssd.
>  But as Jakub said - this has nothing to do with sssd, this is just automounter-specific
> thing.
>  Ondrej
>
> > the new question i have is around variable expansion.  it seems that i am missing
> something about how to do it right.  when i attempt to use $USER, say in /home/$USER, with
> a mountpoint of Music under it, the literal path /home/$USER is created.  i have tried
> /home/$USER, /home ${USER} and /home /{$USER} and in each case, the literal path was
> created on disk.  the variable expansion do not occur and /home/<my_user_id>/Music
> was not automounted as per the autofs directives.
> >
>  To be honest, I don't really know..does the same setup work if you just swap ldap for
> sss?
>
>  The thing is that SSSD just fetches the maps and keys and lets automounter do the work.
> In case of autofs caching, sssd is more or less a dumb proxy.
>
> > how do i get variable expansion to work when using SSSD?
> > _______________________________________________
> > sssd-users mailing list
> > sssd-users(a)lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
>  -----
>
>  The information contained in this e-mail and in any attachments is confidential and is
> designated solely for the attention of the intended recipient(s). If you are not an
> intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
> any part thereof. If you have received this e-mail in error, please notify the sender by
> return e-mail and delete all copies of this e-mail from your computer system(s). Please
> direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
> Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
> South County Business Park, Leopardstown, Dublin 18.
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users 
i am not sure how the
wildcard key would work and will have to read more 
on it.  as a work-around, it will be nice, but fixing any issues would 
be the appropriate action.

changing my autofs config to use ldap instead of sssd causes the same 
thing.  /home/$USER is created and no variable expansion is done.

since this looks to be an automount/autofs issue and not sssd, how do i 
get the attention to this it needs?

[Ondrej Valousek]

Use redhat support portal to submit support case.
Or use redhat Bugzilla to file the bug report.

-----Original Message-----
From: sssd-users-bounces(a)lists.fedorahosted.org
[mailto:[e-mail]] On Behalf Of Brendan Kearney
Sent: 18 August 2015 14:20
To: sssd-users(a)lists.fedorahosted.org
Subject: Re: [SSSD-users] autofs will not find auto.master in LDAP

On 08/18/2015 03:55 AM, Ondrej Valousek wrote:
>  Did not try the variable expansion for ages, but it definitely works
> with maps in NIS.
>  Also, did you consider using asterisk (*) for autofs maps expansion? It works perfectly,
> even with ldap/sssd.
>  But as Jakub said - this has nothing to do with sssd, this is just automounter-specific
> thing.
>  Ondrej
>
> > the new question i have is around variable expansion.  it seems that i am missing
> something about how to do it right.  when i attempt to use $USER, say in /home/$USER, with
> a mountpoint of Music under it, the literal path /home/$USER is created.  i have tried
> /home/$USER, /home ${USER} and /home /{$USER} and in each case, the literal path was
> created on disk.  the variable expansion do not occur and /home/<my_user_id>/Music
> was not automounted as per the autofs directives.
> >
>  To be honest, I don't really know..does the same setup work if you just swap ldap for
> sss?
>
>  The thing is that SSSD just fetches the maps and keys and lets automounter do the work.
> In case of autofs caching, sssd is more or less a dumb proxy.
>
> > how do i get variable expansion to work when using SSSD?
> > _______________________________________________
> > sssd-users mailing list
> > sssd-users(a)lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
>  -----
>
>  The information contained in this e-mail and in any attachments is confidential and is
> designated solely for the attention of the intended recipient(s). If you are not an
> intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
> any part thereof. If you have received this e-mail in error, please notify the sender by
> return e-mail and delete all copies of this e-mail from your computer system(s). Please
> direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
> Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
> South County Business Park, Leopardstown, Dublin 18.
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>  
i am not sure how the wildcard key would work and will have to read more on it.  as
a work-around, it will be nice, but fixing any issues would be the appropriate action.

changing my autofs config to use ldap instead of sssd causes the same thing.  /home/$USER
is created and no variable expansion is done.

since this looks to be an automount/autofs issue and not sssd, how do i get the attention
to this it needs?
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

-----

The information contained in this e-mail and in any attachments is confidential and is
designated solely for the attention of the intended recipient(s). If you are not an
intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
any part thereof. If you have received this e-mail in error, please notify the sender by
return e-mail and delete all copies of this e-mail from your computer system(s). Please
direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
South County Business Park, Leopardstown, Dublin 18.