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

Martin Kosek mkosek at redhat.com
Tue Jun 5 07:32:34 UTC 2012


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-mkosek-262-4-add-sysupgrade-state-file.patch
Type: text/x-patch
Size: 9251 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20120605/8a34e3ef/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-mkosek-263-4-enable-persistent-search-by-default.patch
Type: text/x-patch
Size: 13503 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20120605/8a34e3ef/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-mkosek-264-4-enable-psearch-on-upgrades.patch
Type: text/x-patch
Size: 11511 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20120605/8a34e3ef/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-mkosek-265-4-only-set-sebools-when-necessary.patch
Type: text/x-patch
Size: 4948 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20120605/8a34e3ef/attachment-0003.bin>


More information about the Freeipa-devel mailing list