[Freeipa-devel] Update: Re: Fedora 20 Release

Rich Megginson rmeggins at redhat.com
Tue Dec 17 23:47:03 UTC 2013


On 12/17/2013 11:23 AM, Rich Megginson wrote:
> On 12/17/2013 11:19 AM, Mark Reynolds wrote:
>>
>> On 12/17/2013 11:35 AM, Rich Megginson wrote:
>>> On 12/16/2013 08:07 AM, Petr Spacek wrote:
>>>> Hello list,
>>>>
>>>> we have to decide what we will do with 389-ds-base package in 
>>>> Fedora 20.
>>>>
>>>> Currently, we know about following problems:
>>>>
>>>> Schema problems:
>>>>    https://fedorahosted.org/389/ticket/47631 (regression)
>>>
>>> Fixed.
>>>
>>>>
>>>> Referential Integrity:
>>>>    https://fedorahosted.org/389/ticket/47621 (new functionality)
>>>>    https://fedorahosted.org/389/ticket/47624 (regression)
>>> Fixed.
>>>>
>>>> Replication:
>>>>    https://fedorahosted.org/389/ticket/47632 (?)
>>>
>>> Cannot reproduce.  Closed as WORKSFORME.
>>>
>>>>
>>>> Stability:
>>>>    https://bugzilla.redhat.com/show_bug.cgi?id=1041732
>>> Fixed.
>>>> https://fedorahosted.org/389/ticket/47629 (we are not sure if the 
>>>> syncrepl really plays some role or not)
>>>
>>> We are still trying to determine the cause, and if this is related 
>>> to the use of syncrepl.  If it turns out to be related to syncrepl, 
>>> I would like to release 1.3.2.9 in F20, and just disable the use of 
>>> syncrepl in 389 clients.
>>>
>>> Is everyone ok with this?
>>>
>> Rich I found a crash in 1.3.2 and 1.3.1.  This should go into 
>> 1.3.2.9(or a 1.3.2.10).
>
> Ok.

389-ds-base-1.3.2.9 is now in Fedora 20 updates testing.  Please test 
and give karma.  This release fixes everything except 
https://fedorahosted.org/389/ticket/47629 random crash in 
send_ldap_search_entry_ext(), which, in my testing, appears to be 
related to syncrepl, and therefore imo should not hold up the release of 
1.3.2.9 into Fedora 20.


>
>>>>
>>>> One option is to fix 1.3.2.x as quickly as possible.
>>>>
>>>> Another option is to build 1.3.1.x for F20 with Epoch == 1 and 
>>>> release it as quickly as possible.
>>>>
>>>> The problem with downgrade to 1.3.1.x is that it requires manual 
>>>> change in dse.ldif file. You have to disable 'content 
>>>> synchronization' (syncrepl) and 'whoami' plugins which are not in 
>>>> 1.3.1.x packages but were added and enabled by 1.3.2.x packages.
>>>>
>>>> In our tests, the downgraded DS server starts and works after 
>>>> manual dse.ldif correction (but be careful - we didn't test 
>>>> replication).
>>>>
>>>> Here is the main problem:
>>>> 389-ds-base 1.3.2.8 is baked to Fedora 20 ISO images and there is 
>>>> not way how to replace it there. It means that somebody can do 
>>>> F19->F20 upgrade from ISO and *then* upgrade from repos will break 
>>>> his DS configuration (because of new plugins...).
>>>>
>>>> Simo thinks that this is a reason why 'downgrade package' with 
>>>> 1.3.1.x inevitably needs automated script which will purge two 
>>>> missing plugins from dse.ldif.
>>>>
>>>> Nathan, is it manageable before Christmas? One or either way? Is 
>>>> you think that the downgrade is safe from data format perspective? 
>>>> (I mean DB format upgrades etc.?)
>>>>
>>>
>>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel




More information about the Freeipa-devel mailing list