On Fri, 2012-06-08 at 11:10 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On Tue, 2012-06-05 at 09:32 +0200, Martin Kosek wrote: > >> On Mon, 2012-06-04 at 23:49 -0400, Rob Crittenden wrote: > >>> Martin Kosek wrote: > >>>> On Fri, 2012-05-25 at 17:14 +0200, Martin Kosek wrote: > >>>>> On Fri, 2012-05-25 at 09:25 -0400, Rob Crittenden wrote: > >>>>>> Martin Kosek wrote: > >>>>>>> This set of patches handles enabling psearch both for new > >>>>>>> installations > >>>>>>> (patch 263) and upgraded IPA servers. > >>>>>>> > >>>>>>> For upgraded IPA servers I needed to make sure that psearch is not > >>>>>>> enabled for every IPA package update, but at most once, when a user > >>>>>>> updates to IPA with this patch for the first time (patch 264). This is > >>>>>>> enabled by a new State store located in /var/lib/ipa/sysupgrade (patch > >>>>>>> 262). > >>>>>>> > >>>>>>> I also improved the way we handled SELinux sebool updates (patch 265), > >>>>>>> this can make ipa-upgradeconfig to finish in 0.4 seconds and not in > >>>>>>> 150 > >>>>>>> seconds as previously. Details are in the patches. > >>>>>>> > >>>>>>> Martin > >>>>>> > >>>>>> 262: > >>>>>> The sysupgrade directory isn't created by the RPM install: > >>>>>> > >>>>>> mkdir -p %{buildroot}/%{_localstatedir}/cache/ipa/sysupgrade > >>>>> > >>>>> Fixed. > >>>>> > >>>>>> > >>>>>> 263: > >>>>>> > >>>>>> It looks like zone_refresh is simply disabled in bindinstance.py, why > >>>>>> not remove it completely? > >>>>> > >>>>> zone_refresh is used by bindinstance.py. ipa-server-install or > >>>>> ipa-dns-install may be configured to use zone refresh instead of > >>>>> persistent search mechanism to update the zones (e.g. --zone-refresh > >>>>> 30). > >>>>> > >>>>>> > >>>>>> 264: > >>>>>> > >>>>>> Small nit, worth doing case-insensitive compare of psearch enabled > >>>>>> status? > >>>>> > >>>>> Petr2 told me that arg value for boolean configuration option is > >>>>> case-insensitive, so we can do that - fixed. > >>>>> > >>>>>> > >>>>>> We're updating named.conf in place so I don't know that we need to > >>>>>> reset > >>>>>> permissions. It at least shouldn't get modified by the write. > >>>>> > >>>>> Right, I was being too defensive. I removed the check. > >>>>> > >>>>> I made the upgrade more robust, now it won't crash for example when > >>>>> named.conf does not exist. I also made sure the upgrade script works > >>>>> correctly when the IPA is configured without DNS. > >>>>> > >>>>> Martin > >>>> > >>>> I rebased the patches for current master. I also slightly reworked patch > >>>> 265, the error message printed in case of an unsuccessful setsebool was > >>>> not printed right. > >>>> > >>>> Martin > >>> > >>> Trailing whitespace in 264: > >>> > >>> # git am /tmp/freeipa-mkosek-264-3-enable-psearch-on-upgrades.patch > >>> Applying: Enable psearch on upgrades > >>> /home/rcrit/redhat/freeipa-nossh/.git/rebase-apply/patch:108: trailing > >>> whitespace. > >>> root_logger.error('Cannot update connections in %s: > >>> %s', > >>> warning: 1 line adds whitespace errors. > >> > >> Fixed. > >> > >>> > >>> I don't think the DNS detection is adequate in 264, testing for > >>> named.conf is not enough. What if someone is running a non-IPA DNS > >>> server on the box? > >> > >> I assume you are referring to this line: > >> + if not bindinstance.named_conf_exists(): > >> > >> It checks both if the named.conf exists + if it has bind-dyndb-ldap > >> configured for IPA: > >> if line.startswith('dynamic-db "ipa"'): > >> > >>> > >>> I know that I've recently done similar config changes but in 265 is > >>> using line.startswith() going to be fragile? > >> > >> I assume you mean patch 264. This should be OK - user would need to mess > >> with the configuration generated by our install scripts to break it. But > >> in this case, other regex-es would fail too. I did not want to get too > >> wild with regex-es to keep it simple and safe. The worst case scenario > >> should be that named.conf is not updated and psearch is not turned on. > >> > >>> > >>> In 266 I'd merge in the ipa-upgradeconfig change into 265 or some other > >>> patch. > >> > >> I assume you mean patch 265. I had this change moved to 264 right after > >> I sent the patches :-) > >> > >>> > >>> In the 'for setting, state' loop should it be catching a > >>> CalledProcessException rather than raw Exception? I think that is all > >>> that should be raised there. > >> > >> Right, fixed. > >> > >>> > >>> I did an upgrade and it seemed to work ok, ended up with these scary > >>> messages in /var/log/messages: > >>> > >>> Jun 4 23:39:17 localhost named[18753]: LDAP error: Can't contact LDAP > >>> server > >>> Jun 4 23:39:17 localhost named[18753]: connection to the LDAP server > >>> was lost > >>> Jun 4 23:39:17 localhost named[18753]: bind to LDAP server failed: > >>> Can't contact LDAP server > >>> Jun 4 23:39:17 localhost named[18753]: ldap_psearch_watcher failed to > >>> handle LDAP connection error. Reconnection in 60s > >>> Jun 4 23:39:17 localhost named[18753]: LDAP error: Can't contact LDAP > >>> server > >>> Jun 4 23:39:17 localhost named[18753]: connection to the LDAP server > >>> was lost > >>> Jun 4 23:39:17 localhost named[18753]: bind to LDAP server failed: > >>> Can't contact LDAP server > >>> Jun 4 23:39:17 localhost ns-slapd[18798]: [04/Jun/2012:23:39:17 -0400] > >>> - Information: Non-Secure Port Disabled > >>> Jun 4 23:40:17 localhost named[18753]: handle_connection_error failed > >>> to obtain ldap error code > >>> Jun 4 23:40:17 localhost named[18753]: connection to the LDAP server > >>> was lost > >>> Jun 4 23:40:17 localhost named[18753]: bind to LDAP server failed: > >>> Can't contact LDAP server > >>> Jun 4 23:40:17 localhost named[18753]: ldap_psearch_watcher failed to > >>> handle LDAP connection error. Reconnection in 60s > >>> Jun 4 23:41:17 localhost named[18753]: handle_connection_error failed > >>> to obtain ldap error code > >>> Jun 4 23:41:17 localhost named[18753]: connection to the LDAP server > >>> was lost > >>> > >>> DNS does seem to be working fine from the cli. > >> > >> I think this was caused by ipa-ldap-updater which shut down the > >> Directory Server to perform the LDAP upgrade. > >> > >> Btw I asked Petr to file a ticket for bind-dyndb-ldap to report when it > >> report success after when it returns back from an error state: > >> https://fedorahosted.org/bind-dyndb-ldap/ticket/71 > >> This way, we cannot know that the LDAP connection has been restored > >> besides doing a test DNS query. > >> > >>> > >>> The tests are another matter. named crashed in 0:1.1.0-0.10.b2.fc17 in > >>> the test cleanup. > >>> > >>> I upgraded to bind-dyndb-ldap-1.1.0-0.11.rc1.fc17 and got this stack > >>> trace: > >>> > >>> Program received signal SIGABRT, Aborted. > >>> [Switching to Thread 0x7f68e50db700 (LWP 19367)] > >>> 0x00007f68e6188915 in raise () from /lib64/libc.so.6 > >>> (gdb) where > >>> #0 0x00007f68e6188915 in raise () from /lib64/libc.so.6 > >>> #1 0x00007f68e618a0c8 in abort () from /lib64/libc.so.6 > >>> #2 0x00007f68e91171fb in assertion_failed (file=<optimized out>, > >>> line=<optimized out>, type=<optimized out>, cond=<optimized out>) > >>> at ./main.c:219 > >>> #3 0x00007f68e73a6c3a in isc_assertion_failed ( > >>> file=file@entry=0x7f68e8a82deb "zone.c", line=<optimized out>, > >>> type=type@entry=isc_assertiontype_require, > >>> cond=cond@entry=0x7f68e8a82fe7 "zone->db != ((void *)0)") > >>> at assertions.c:57 > >>> #4 0x00007f68e8a2ba67 in zone_detachdb (zone=<optimized out>) at > >>> zone.c:12944 > >>> #5 zone_detachdb (zone=0x7f68dc57fef0) at zone.c:12943 > >>> #6 0x00007f68e8a2baa1 in zone_unload (zone=zone@entry=0x7f68dc57fef0) > >>> at zone.c:9092 > >>> #7 0x00007f68e8a2fcc4 in dns_zone_unload (zone=0x7f68dc57fef0) at > >>> zone.c:9040 > >>> #8 0x00007f68e3584b9e in ldap_delete_zone2 > >>> (inst=inst@entry=0x7f68e90b0f10, > >>> name=name@entry=0x7f68e50dad10, lock=lock@entry=isc_boolean_true) > >>> at ldap_helper.c:786 > >>> #9 0x00007f68e3586554 in ldap_delete_zone (dn=<optimized out>, > >>> inst=0x7f68e90b0f10, lock=<optimized out>) at ldap_helper.c:811 > >>> #10 update_action (task=<optimized out>, event=0x7f68e37de6a0) > >>> at ldap_helper.c:2763 > >>> #11 0x00007f68e73c613e in dispatch (manager=0x7f68e908f010) at task.c:1109 > >>> #12 run (uap=0x7f68e908f010) at task.c:1279 > >>> #13 0x00007f68e6d7bd14 in start_thread () from /lib64/libpthread.so.0 > >>> #14 0x00007f68e624494d in clone () from /lib64/libc.so.6 > >>> > >>> rob > >> > >> Thanks for digging out the traceback, I already reported this error to > >> bind-dyndb-ldap: > >> https://bugzilla.redhat.com/show_bug.cgi?id=827401 > >> > >> Petr, what's the status of this bug? I guess we cannot push this set of > >> patches to enable the psearch by default until this is fixed. Otherwise > >> bind-dyndb-ldap would crash _every_ DNS unit test case. > >> > >> Updated set of patches attached. > >> > >> Martin > > > > Petr^2 fixed the bug in bind-dyndb-ldap causing it to crash during DNS > > unit tests. A re-tested the new version with IPA and it worked fine. > > > > Attached a rebased set of patches with proper bind-dyndb-ldap version > > enforced. I would like this to get acked soon so that psearch is tested > > by a broader audience and we are able to stabilize it faster. > > > > Martin > > These work ok so conditional ACK based on the following: > > The tests all pass but I saw this in messages: > > Jun 8 10:13:37 localhost named[1624]: psearch moddn change is not > implemented > Jun 8 10:13:37 localhost named[1624]: psearch_update failed for > idnsname=testdnsres-renamed,idnsname=dnszone.test,cn=dns,dc=example,dc=com > zone. Zone can be outdated, run `rndc reload`
Yup, there is already a ticket which should fix that: https://fedorahosted.org/bind-dyndb-ldap/ticket/72 > > Other than immediately seeing new zones are there any other consequences > to disabling psearch? Are features eventually going to not be available > if it is not enabled? I assume that if/when that happens the man page > will be updated at that point? > > rob At current state of things, both modes (psearch vs. no-psearch) should equivalent in term of features. In the future, DNSSEC+automatic SOA update (i.e. a requirement for zone transfers) will depend on psearch. I guess it would be possible to implement some limited functionality when psearch is off, we can discuss this topic with Petr/Adam. Martin _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel