[Freeipa-devel] host-del & client uninstall: additional discussion related to DNS needed

[Martin Basti]

On 03.03.2016 17:36, Petr Vobornik wrote:
> On 03/03/2016 03:52 PM, Martin Basti wrote:
>> Hello all,
>>
>> related tickets:
>> https://fedorahosted.org/freeipa/ticket/5676
>> https://fedorahosted.org/freeipa/ticket/5675
>> https://fedorahosted.org/freeipa/ticket/5715
>>
>> I'm trying to implement both tickets, but I don't like the way we
>> decided on devel meeting anymore.
>>
>> https://fedorahosted.org/freeipa/ticket/5676#comment:1
>>
>> 1)
>> ipa host-del --updatedns
>>
>> I propose to only delete A, AAAA and related PTR records (SSHFP records
>> explained later). The record are somehow managed by IPA
>>
>> I don't like the idea of having an extra option to specify record types
>> that should be removed or a flag that will remove DNS entry completely.
>> IMO that is duplication of dnsrecord-mod/del functionality, host-del
>> should not be used for managing DNS. If somebody wants better
>> granularity, the one should use 'dnsrecord-mod zone rec --type-rec=' or
>> 'dnsrecord-del --del-all'
>
> AFAIK the proposal on devel meeting was:
>
> --update-dns will delete A, AAAA, SSHFP
> --update-dns=all will delete the whole DNS record LDAP entry
>
> there was also a proposal for granularity, e.g., --update-dns=a,aaaa.
Yes this looks for me like doing an alias for dnsrecord-del command

>
> Then it was agreed that --update-dns won't search for SRV records (not 
> mentioned here, so OK).
>
> PTR records weren't discussed or decision was not recorded.
When we remove A/AAAA, then we should remove PTR as well
>
> The proposal above keeps backwards compatibility though it may not be 
> possible to do with current framework. Or do we have support for 
> multivalued enum with default value(s) which acts as a flag?
It needs big hacks in framework, to support is as Flag for old client 
and Enum for new clients
>
> If the new option type is too complicated to introduce, then I would 
> prefer to keep current option(flag) with behavior matching proposal 
> for --update-dns or --update-dns=all.
To use "--update-dns will delete A, AAAA, SSHFP" only was proposed by me 
here.

>
> Definitely big +1 on not introducing a new option.
>
> No need to over-engineer it.
>
> Not sure about PTR records.
>
>>
>> Note: due backward compatibility --updatedns cannot be migrated to ENUM,
>> new option needed
>
>>
>> 2)
>> SSHFP records and host-del 
>> (https://fedorahosted.org/freeipa/ticket/5715)
>>
>> host-del removes SSH keys from LDAP, thus there is no reason to keep
>> SSHFP record in DNS, thus SSHFP records should be removed always (even
>> without --updatedns option)
>
> ACK
>
>>
>> 3)
>> ipa-client-install --uninstall
>>
>> SSHFP record are always added via nsupdate to DNS, IMO during client
>> uninstall all SSHFP record related to client should be removed via
>> nsupdate too.
>
> IMHO not necessary will be solved either by #5676 and/or 
> #5715(currently uninstall indirectly calls ipa-host-disable)
However host-disable does not do nsupdate, so it will work only for IPA 
DNS. So if nsupdate set SSHPF on non-IPA server, we do not have reverse 
operation in uninstall for that.

>
>>
>> 4)
>> https://fedorahosted.org/freeipa/ticket/5676
>>
>> ipa-client-install --uninstall --delete-host    #suggestions how to name
>> option for removing host entry for ldap welcome
>>
>> Should this option call 'host-del' or 'host-del --updatedns'?
>>
>> I would like to avoid additional DNS related option to be added to
>> ipa-client-install
>>
>> Also do we really want to implement this ticket? What is the gain there?
>
> The devel discussions which is recorded in 
> https://fedorahosted.org/freeipa/ticket/5676#comment:1
>
> Suggests to change default behavior in ipa-client-install --uninstall 
> so that it will call:
>
> `ipa host-del --update-dns` instead of `ipa-join --unenroll`. So it 
> will also do #3.
>
> Further proposal in #5676 is to introduce a new option(--keephost ??) 
> to keep the host records, i.e., the old behavior.
>
> But comment:
> """
> simo: maybe keeping backward compatibility is more important, discuss 
> later if --remove option would be better
> """
> suggest that further discussion is needed

I agree with backward compatibility here. A current user may be very 
surprised that all DNS records of the host disappear.


>
>>
>> Martin^2
>>