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

Tue Jun 5 03:49:44 UTC 2012

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.

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 know that I've recently done similar config changes but in 265 is 
using line.startswith() going to be fragile?

In 266 I'd merge in the ipa-upgradeconfig change into 265 or some other 
patch.

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.

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.

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