[Freeipa-devel] [PATCH 0057] Don't show part of warning containing --force-ntpd in replica install

Jan Cholasta jcholast at redhat.com
Thu Aug 4 05:34:58 UTC 2016


On 3.8.2016 19:39, Martin Basti wrote:
>
>
> On 03.08.2016 18:10, Petr Vobornik wrote:
>> On 07/13/2016 12:36 PM, Stanislav Laznicka wrote:
>>> On 07/13/2016 09:51 AM, Petr Vobornik wrote:
>>>> On 07/13/2016 08:26 AM, Stanislav Laznicka wrote:
>>>>> On 07/12/2016 08:44 AM, Stanislav Laznicka wrote:
>>>>>> On 07/11/2016 04:27 PM, Petr Vobornik wrote:
>>>>>>> On 07/11/2016 01:23 PM, Stanislav Laznicka wrote:
>>>>>>>> https://fedorahosted.org/freeipa/ticket/6046
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Isn't the bug about something else?
>>>>>>>
>>>>>>> The issue was that ipa-replica-install doesn't have --force-ntpd
>>>>>>> option.
>>>>>>> It is an option of ipa-client-install which is run from replica
>>>>>>> installer.
>>>>>>>
>>>>>>> The unattended mode is unrelated.
>>>>>> My understanding is that the bug says that '--force-ntpd' option
>>>>>> should not be shown when ipa-client-install is run during replica
>>>>>> installation.
>>>>>>
>>>>>> During replica installation, the ipa-client-install script is run
>>>>>> with
>>>>>> the '--unattended' flag in the 'ensure_enrolled()' function. Being a
>>>>>> separate script, there's not many options on how to pass the
>>>>>> information not to show the message to ipa-client-install. Using the
>>>>>> already used flag to get rid of the message seemed easiest to me.
>>>>>> Introducing a new 'hidden' flag (like '--from-replica'), on the other
>>>>>> hand, seems a bit harsh.
>>>>>>
>>>>> Just to throw it out there - it's possible that the '--force-join'
>>>>> client option would also appear as a hint from the client install
>>>>> script
>>>>> (during replica installation). Should this also be muted somehow?
>>>>> To me,
>>>>> it seems reasonable to rather add it as an argument to
>>>>> ipa-replica-install to pass it to the client install script.
>>>>>
>>>> IMO client installation initiated from replica needs to have a special
>>>> option(hidden in help) similar to --on-server (or what's its name).
>>>> E.g.
>>>> the name can be --replica-install. Maybe --on-server can be used but it
>>>> may have other implication which might not be valid for this use case.
>>>>
>>>> Anything else are just workarounds. Imagine that admin runs
>>>> ipa-client-install with --unattended or --force-join. He would then not
>>>> get the message as now.
>> Reviving thread to get other opinion.
>>
>>> The --on-master option won't do here as it seems that the client would
>>> require some IPA pre-configuration for successful install. A new option
>>> will have to be created, then.
>> I'm for new "hidden" option.
>
> I'm against any hidden options, this should be made correctly by
> modularization/fixing of client install, to be able call it from python
> not as external process

+1, but this is non-trivial and definitely not material for 4.4.1. For 
4.4.1 the hidden option should be OK.

>
> Just from top of my head, can we just use option --no-ntp with client
> install in replica installer? Server NTP should not depend on client ntp
> config.
> I'm just afraid that we may get kerberos time issue during client
> install if client time does not match server time.
>
> Or second approach, always call client install from replica with
> --force-ntpd, unless there is --no-ntp used for replica, then call
> ipa-client-install with --no-ntp
>
> But it needs investigation.

CCing David as he knows everything NTP-related.

>
> Martin^2
>
>>
>>> As I was trying to point out, the situation about --force-join is a bit
>>> different. The option again would be shown and is not available in
>>> ipa-replica-install. I think it should be available to allow direct
>>> replica installation even when previous installation failed/left some
>>> mess on the master (ofc the user could run `ipa-replica-manage del
>>> <bad-bad-hostname> --cleanup` on the master instead).
>>>
>> That could work but imho is out of scope of this ticket.
>


-- 
Jan Cholasta




More information about the Freeipa-devel mailing list