[Freeipa-users] What should the --hostname option do?

[Martin Basti]

On 07.12.2016 15:21, Rob Crittenden wrote:
> Martin Basti wrote:
>>
>> On 07.12.2016 08:48, List dedicated to discussions about use,
>> configuration and deployment of the IPA server. wrote:
>>> Hello,
>>>
>>> the --hostname option to the installer currently modifies the hostname
>>> of the machine. In some environments, namely in unprivileged
>>> containers, that operation is not denied. In some cases, it is
>>> possible to change the FQDN of the container from outside, for example
>>> with docker run's -h option. However, in some environments, namely in
>>> OpenShift, there is not such possibility.
>>>
>>> I have found out that disabling the change by turning /bin/hostnamectl
>>> and /usr/bin/domainname makes ipa-server-install pass while the server
>>> gets configured with the hostname specified as the parameter to
>>> --hostname option so it does not seem to be essential for the FQDN to
>>> change. Of course, some operations might no longer work, like ssh to
>>> the FreeIPA machine as sshd would need to be set with
>>> GSSAPIStrictAcceptorCheck no.
>>>
>>> I wonder if either change of the --hostname semantics, or some new
>>> option would be useful, to specify the hostname to be used by the
>>> FreeIPA software while not touching the configuration of the hostname
>>> for the machine.
>>>
>> I agree that --hostname options should not touch system's hostname, I
>> don't see reason why application installer should change system hostname.
> It was done for sanity because a staggering number of users it seems
> don't properly set their hostname.

Then we should have checks and prevent installation, but this needs 
proper design and must cover containers, AWS, etc. to count with various 
scenarios.

>
>> I'd start with deprecating current behavior of this option in next release
> IMHO it is a pretty significant change of behavior.
True, so as mentioned later, rather just deprecate this option.

>
>> As you mentioned we need find what cases can be broken when we will use
>> different local and external hostname, but anyway we have do this for
>> containers.
> Agreed. Something needs to happen, I'm just not convinced it should
> happen in --hostname. I generally oppose new options but one might be
> warranted in this case to handle things.

Maybe --external-hostname or so, noted, we will cover it in design.

>
> rob