[Freeipa-devel] [PATCH] 262-265 Enable psearch by default

Rob Crittenden rcritten at redhat.com
Mon Jun 11 18:41:04 UTC 2012 

Martin Kosek wrote:
> 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 at entry=0x7f68e8a82deb "zone.c", line=<optimized out>,
>>>>>        type=type at entry=isc_assertiontype_require,
>>>>>        cond=cond at 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 at 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 at entry=0x7f68e90b0f10,
>>>>>        name=name at entry=0x7f68e50dad10, lock=lock at 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
>

Ok, pushed all to master.

rob

More information about the Freeipa-devel mailing list