[Freeipa-users] Required services are not started after reboot

[Nathan Kinder]

On 10/10/2013 03:50 PM, Nathan Kinder wrote:
> On 10/10/2013 06:48 AM, Rob Crittenden wrote:
>> Mateusz Marzantowicz wrote:
>>> On 08.10.2013 18:43, Tamas Papp wrote:
>>>>
>>>> On 10/08/2013 06:33 PM, Mateusz Marzantowicz wrote:
>>>>> Finally, I've managed to install FreeIPA on Fedora 20 without any
>>>>> errors. I was even able to log in through web UI and make some 
>>>>> changes.
>>>>> Sadly after system reboot, non of IPA related services were 
>>>>> started and
>>>>> now nothing works as expected.
>>>>>
>>>>> What services need to be enabled (I need to enable manually) to 
>>>>> make ipa
>>>>> server operational again? I'd be thankful for any links to official
>>>>> documentation that covers this topic.
>>>>
>>>> See:
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1008306
>>>>
>>>>
>>>> t
>>>
>>> Thanks,
>>>
>>> It looks like this bug is fixed in fc19 [1] but it's not in fc20 [2]
>>> (please compare 'Bugs Fixed' sections (I haven't tested it on fc19)).
>>> How is it possible that same release of freeipa (3.3.2-1) fixes bug
>>> 996716 in fc19 and not in fc20? I'm currently testing newest available
>>> rpm on fc20 and this bug still occurs.
>>>
>>> I've found that bug 1008306 [3] is more relevant in this case than one
>>> in FreeIPA. I also have newest 389-ds-base
>>> (389-ds-base-1.3.2.0-1.fc20.x86_64) package released for fc20 and
>>> nothing has changed as I mentioned above.
>>>
>>> I'm trying to make sens out of this bug & rpm # spaghetti but it's not
>>> so easy.
>>>
>>> [1]
>>> https://admin.fedoraproject.org/updates/FEDORA-2013-18371/freeipa-3.3.2-1.fc19 
>>>
>>>
>>> [2]
>>> https://admin.fedoraproject.org/updates/FEDORA-2013-18542/freeipa-3.3.2-1.fc20 
>>>
>>>
>>> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1008306
>>
>> I think this is because the fixed 389-ds package hasn't been built 
>> yet for F-20.
> The fix for BZ 1008306 is in the 389-ds-base-1.3.2.0-1.fc20.x86_64 
> build.  Are we sure that the issue that is occuring here is related to 
> tmpfiles.d not creating /var/lock/dirsrv before dirsrv is started?
I just fired up a F20 VM, and there is definitely still a problem here 
in 389-ds-base.  I see the following in my tmpfiles.d config for dirsrv:

--------------------------------------------------------------
d /var/run/dirsrv 0770 nobody nobody
d /var/lock/dirsrv 0770 nobody nobody
d /var/lock/dirsrv/slapd-example 0770 nobody nobody
--------------------------------------------------------------

We'll figure out what's going on and get a respin of 389-ds-base out.
>
> Thanks,
> -NGK
>>
>> I think the difference in bugs fixed in bohdi was an oversight. The 
>> F-19 bugs fixed upstream should have been included in the F-20 bohdi 
>> (and probably the other way around too).
>>
>> The changes made to IPA for BZ 996716 are basically just cosmetic, to 
>> be in compliance with packaging guidelines.
>>
>> rog
>>
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users