On Thu, 19 Jun 2014, Simo Sorce wrote:
On Thu, 2014-06-19 at 17:24 +0300, Alexander Bokovoy wrote:
On Thu, 19 Jun 2014, Simo Sorce wrote:
>On Thu, 2014-06-19 at 17:10 +0300, Alexander Bokovoy wrote:
>> On Thu, 19 Jun 2014, Simo Sorce wrote:
>> >> >> and named successfully started, with 389-ds showing autobind to the 
>> >> >> krprincipalname=dns/... in the logs.
>> >> >
>> >> >why do we need to associate bind to dns/whatever ??
>> >> Because we already have ACIs given to dns/hostname to handle DNS
>> >> entries.
>> >
>> >Which are easy to change on upgrade.
>> >
>> >> >we can have a sysaccount called named, like we did for kerberos before
>> >> >we had the ipa-kdb driver.
>> >> A modification of DNS service with 'ipa service-mod' is all what we
>> >> need for single node case, I tried it.
>> >
>> >I do not like it at all, plus each server has a different object and
>> >they would all be duplicates. I prefer very much a single, passwordless
>> >special user in sysconfig, added to the same group that control access
>> >for the DNS tree.
>> autobind needs uidNumber=<uid>+gidNumber=<gid> search to resolve to a
>> single entry. Given that replicas might be running on machines where
>> 'named' user could deviate (think Fedora, RHEL, and Debian), there will
>> still be multiple 'named' sysaccounts and the whole story will break. I
>> don't see how this helps compared to having DNS/hostname principal
>> object extended to cover uidNumber/gidNumber.
>This is not really a huge issue.
>We need to allow access to the DNS tree to a group, so all we need is
>for install/upgrade script to check what is the named user on the system
>and create a corresponding system account.
So, now we'll have to manage multiple named accounts named what,
'named1', 'named2', ... ? How to manage them?

what is there to manage ?

One solution could be to have multi-value uidNumber/gidNumber

nope, you just need to create a new object only if one does not exist
with the same uidNumber, and add it to the group we use for ACIs on DNS.
I assume the account like that shouldn't have any password at all, to
prevent its use over LDAP instead of LDAPI.

I'm still a bit uncomfortable with it because if this trend goes, we'll
be making such accounts for other services as well. Given that we have
no means to manage sysaccounts from IPA right now, their life cycle is a
bit weird.

I may need to revive my sysaccounts module...
/ Alexander Bokovoy

Freeipa-devel mailing list

Reply via email to