[SSSD-users] Re: nsupdate
On (13/03/18 10:40), Roger Martensson wrote: >After som serious digging I caved in and upgraded dnsutils on my Ubuntu. >Seems that the future Ubuntu 18.04 has a non-working install of nsupdate. >When upgrading to version 9.12 nsupdate (using ISC PPA) everything started >to work. > Sounds to me like ubuntu version of fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=1484451 It should be already fixed in bind upstream (9.11) LS ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: nsupdate
On Tue, Mar 13, 2018 at 8:40 AM, Roger Martensson < roger.martens...@gmail.com> wrote: > Hi > > Den 13 mars 2018 12:09 skrev "Max DiOrio" : > >> Is your dns server set to secure updates only? >> > > Yes it is and as is should be. > > I've filed a bugreport on the package at Ubunts launchpad so hopefully it > gets resolved before release of 18.04. > > This one, right? https://bugs.launchpad.net/bugs/1755439 ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: nsupdate
Hi Den 13 mars 2018 12:09 skrev "Max DiOrio" : > Is your dns server set to secure updates only? > Yes it is and as is should be. I've filed a bugreport on the package at Ubunts launchpad so hopefully it gets resolved before release of 18.04. On Tue, Mar 13, 2018, 5:40 AM Roger Martensson > wrote: > >> After som serious digging I caved in and upgraded dnsutils on my Ubuntu. >> Seems that the future Ubuntu 18.04 has a non-working install of nsupdate. >> When upgrading to version 9.12 nsupdate (using ISC PPA) everything >> started to work. >> >> 2018-03-09 19:24 GMT+01:00 Roger Martensson : >> >>> Hi! >>> >>> Setup: Ubuntu 18.04 (future), SSSD 1.16.0, nsupdate/bind: 9.11.2.P1, >>> 2008R2 DC/DNS >>> >>> I need some help and guidance with troubleshooting nsupdate-problems. >>> I get the famous "TSIG error with server: tsig verify failure" when >>> trying to update my A-record against our Microsoft DNS. >>> I get the error in sssd-logs and the same error when running nsupdate >>> manually with the same input as found in the logs (when cranking up debug >>> level). >>> >>> I have tried with client keytab and with a user that I know have >>> permission to update. (nsupdate with -g) >>> >>> SSSD is fully configured and I can do user lookups and logins. >>> ldapsearch agains different domains in the forest with -Y GSSAPI works >>> without problem. >>> >>> Our setup is a domain forest where the clients are in the subdomain and >>> the DNS is in the parent domain. Parent DNS domain and subdomains is in the >>> same Zone and has Secure Only updates enabled. >>> >>> Anyone have any ideas what I can do next to troubleshoot this issue? >>> >>> >>> >>> >> ___ >> sssd-users mailing list -- sssd-users@lists.fedorahosted.org >> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org >> > > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > > ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: nsupdate
Is your dns server set to secure updates only? On Tue, Mar 13, 2018, 5:40 AM Roger Martensson wrote: > After som serious digging I caved in and upgraded dnsutils on my Ubuntu. > Seems that the future Ubuntu 18.04 has a non-working install of nsupdate. > When upgrading to version 9.12 nsupdate (using ISC PPA) everything started > to work. > > 2018-03-09 19:24 GMT+01:00 Roger Martensson : > >> Hi! >> >> Setup: Ubuntu 18.04 (future), SSSD 1.16.0, nsupdate/bind: 9.11.2.P1, >> 2008R2 DC/DNS >> >> I need some help and guidance with troubleshooting nsupdate-problems. >> I get the famous "TSIG error with server: tsig verify failure" when >> trying to update my A-record against our Microsoft DNS. >> I get the error in sssd-logs and the same error when running nsupdate >> manually with the same input as found in the logs (when cranking up debug >> level). >> >> I have tried with client keytab and with a user that I know have >> permission to update. (nsupdate with -g) >> >> SSSD is fully configured and I can do user lookups and logins. ldapsearch >> agains different domains in the forest with -Y GSSAPI works without problem. >> >> Our setup is a domain forest where the clients are in the subdomain and >> the DNS is in the parent domain. Parent DNS domain and subdomains is in the >> same Zone and has Secure Only updates enabled. >> >> Anyone have any ideas what I can do next to troubleshoot this issue? >> >> >> >> > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: nsupdate
After som serious digging I caved in and upgraded dnsutils on my Ubuntu. Seems that the future Ubuntu 18.04 has a non-working install of nsupdate. When upgrading to version 9.12 nsupdate (using ISC PPA) everything started to work. 2018-03-09 19:24 GMT+01:00 Roger Martensson : > Hi! > > Setup: Ubuntu 18.04 (future), SSSD 1.16.0, nsupdate/bind: 9.11.2.P1, > 2008R2 DC/DNS > > I need some help and guidance with troubleshooting nsupdate-problems. > I get the famous "TSIG error with server: tsig verify failure" when trying > to update my A-record against our Microsoft DNS. > I get the error in sssd-logs and the same error when running nsupdate > manually with the same input as found in the logs (when cranking up debug > level). > > I have tried with client keytab and with a user that I know have > permission to update. (nsupdate with -g) > > SSSD is fully configured and I can do user lookups and logins. ldapsearch > agains different domains in the forest with -Y GSSAPI works without problem. > > Our setup is a domain forest where the clients are in the subdomain and > the DNS is in the parent domain. Parent DNS domain and subdomains is in the > same Zone and has Secure Only updates enabled. > > Anyone have any ideas what I can do next to troubleshoot this issue? > > > > ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: nsupdate/sss_ssh_authorized_keys not working until sssd.conf is touched
On Fri, Mar 03, 2017 at 08:59:34AM -0500, Michael Smith wrote: > On Fri, Mar 3, 2017 at 3:36 AM, Jakub Hrozek wrote: > > > On Thu, Mar 02, 2017 at 10:20:53PM -0500, Michael Smith wrote: > > > I've been using sssd with AD on Ubuntu 16.04 for several months (sssd > > > 1.13.4). I've joined probably a few dozen VMs to a domain. More often > > than > > > > > > > I can reboot or restart sssd as many times as I like and it won't fix it. > > > But as soon as I would bump up the debuglevel in /etc/sssd/sssd.conf and > > > "systemctl restart sssd", everything would work. > > > > The only explanation I have is that 'something', either some join script > > or whatever is used updates sssd.conf after sssd is started. The way > > sssd reads its configuration is that on sssd startup, we check the > > timestamp of sssd.conf, compare it with the timestamp of sssd's internal > > configuration database (/var/lib/sss/db/config.ldb) and if sssd.conf is > > newer, sssd regenerates the configuration database. > > > > And perhaps the problem is that the resolution of the timestamp is only > > down to seconds, so if you update the config file on the same second as > > the last restart, sssd migth not detect the config file was changed? > > > Oh, thanks, that must be it. I'm using Puppet to join so it may very well > all happen within the same second. In fact, I see the module I'm using > (walkamongus/realmd) has a block to remove the cache after updating > sssd.conf, but there must be a race condition somewhere. > > I'll add a line to the systemd unit to delete config.ldb before each start, > something like "ExecStartPre=/bin/rm /var/lib/sss/db/config.ldb". I think touching the config file might be simpler? btw the sssd bug that causes this is https://pagure.io/SSSD/sssd/issue/3020 > Or is > there a config option to force config.ldb to be generated each time sssd > starts? I looked at it with tdbdump and it seems pretty small, probably not > worth caching really. Or is there something in there that needs to be > retained between runs? > No, the confdb cache is there only to make it easy to read config values using the same API we use for reading cache entries. ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: nsupdate/sss_ssh_authorized_keys not working until sssd.conf is touched
On Fri, Mar 3, 2017 at 3:36 AM, Jakub Hrozek wrote: > On Thu, Mar 02, 2017 at 10:20:53PM -0500, Michael Smith wrote: > > I've been using sssd with AD on Ubuntu 16.04 for several months (sssd > > 1.13.4). I've joined probably a few dozen VMs to a domain. More often > than > > > I can reboot or restart sssd as many times as I like and it won't fix it. > > But as soon as I would bump up the debuglevel in /etc/sssd/sssd.conf and > > "systemctl restart sssd", everything would work. > > The only explanation I have is that 'something', either some join script > or whatever is used updates sssd.conf after sssd is started. The way > sssd reads its configuration is that on sssd startup, we check the > timestamp of sssd.conf, compare it with the timestamp of sssd's internal > configuration database (/var/lib/sss/db/config.ldb) and if sssd.conf is > newer, sssd regenerates the configuration database. > > And perhaps the problem is that the resolution of the timestamp is only > down to seconds, so if you update the config file on the same second as > the last restart, sssd migth not detect the config file was changed? Oh, thanks, that must be it. I'm using Puppet to join so it may very well all happen within the same second. In fact, I see the module I'm using (walkamongus/realmd) has a block to remove the cache after updating sssd.conf, but there must be a race condition somewhere. I'll add a line to the systemd unit to delete config.ldb before each start, something like "ExecStartPre=/bin/rm /var/lib/sss/db/config.ldb". Or is there a config option to force config.ldb to be generated each time sssd starts? I looked at it with tdbdump and it seems pretty small, probably not worth caching really. Or is there something in there that needs to be retained between runs? Thanks, Mike ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: nsupdate/sss_ssh_authorized_keys not working until sssd.conf is touched
On Thu, Mar 02, 2017 at 10:20:53PM -0500, Michael Smith wrote: > Hi all, > > I've been using sssd with AD on Ubuntu 16.04 for several months (sssd > 1.13.4). I've joined probably a few dozen VMs to a domain. More often than > not, /var/lib/sss/pipes/ssh is not created right away after joining, and > the dynamic DNS registration with nsupdate doesn't happen. There are no > errors in /var/log/sssd/*; sssd_ssh just doesn't run, and dyndns doesn't > happen either. > > I can reboot or restart sssd as many times as I like and it won't fix it. > But as soon as I would bump up the debuglevel in /etc/sssd/sssd.conf and > "systemctl restart sssd", everything would work. The only explanation I have is that 'something', either some join script or whatever is used updates sssd.conf after sssd is started. The way sssd reads its configuration is that on sssd startup, we check the timestamp of sssd.conf, compare it with the timestamp of sssd's internal configuration database (/var/lib/sss/db/config.ldb) and if sssd.conf is newer, sssd regenerates the configuration database. And perhaps the problem is that the resolution of the timestamp is only down to seconds, so if you update the config file on the same second as the last restart, sssd migth not detect the config file was changed? > > Eventually I figured out that it wasn't dependent on the debug level at all > - if I just touch /etc/sssd/sssd.conf to update the timestamp, and restart > sssd, that's enough to fix it. > > The next time I join a machine I'll start with debuglevel set to 9. In the > meantime, is there anything that could explain this behaviour: the sshd > integration and dyndns registration don't work until (1) the domain is > joined and (2) sssd.conf's mtime is changed? > > Thanks, > Mike > > sssd.conf: > > [domain/my.domain] > access_provider = ad > ad_domain = my.domain > ad_gpo_access_control = disabled > ad_hostname = myhostname.my.domain > cache_credentials = False > debug_level = 3 > default_shell = /bin/bash > dns_resolver_timeout = 30 > dyndns_refresh_interval = 28800 > dyndns_update = True > dyndns_update_ptr = True > entry_cache_timeout = 120 > fallback_homedir = /home/%u > id_provider = ad > krb5_realm = MY.DOMAIN > krb5_store_password_if_offline = False > ldap_access_filter = > (memberOf:1.2.840.113556.1.4.1941:=cn=somegroup,ou=Groups,ou=xxx,dc=my,dc=domain) > ldap_group_nesting_level = 2 > ldap_id_mapping = True > ldap_schema = ad > ldap_user_ssh_public_key = sshPublicKey > memcache_timeout = 120 > use_fully_qualified_names = False > > [nss] > filter_users = > root,named,avahi,haldaemon,dbus,radiusd,news,nscd,centos,ubuntu > > [ssh] > > [sssd] > config_file_version = 2 > domains = my.domain > services = nss,pam,ssh > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
