On Tue, 03 Feb 2015, William wrote:

>
>Maybe something to test?
You can create a user on the replica without ipa-adtrust-install and
watch after replication on whether ipaNTSecurityIdentifier appeared in
the user's object in LDAP.


I was thinking more unit test or beaker test actually, but I'm sure I
could do a setup by hand and test it later.
Having a beaker test would be good. I was just thinking about proving
that the flow is indeed what we are discussing. ;)


>> >This should be configured on replicas added to the network if adtrust
>> >has been run already. Perhaps this is something to consider also?
>> >Consistency through out the domain is a good thing.
>> Exactly. Good suggestion. One thing we need to solve here is that
>> enabling sidgen and other components will require installing Samba
>> libraries. This is something to consider -- do we want these libraries
>> (not daemons) installed on every master?
>
>Well, ipa-adtrust is a seperate package already isn't it? If you were in
>the position to be setting up an adtrust on freeipa, you would document
>that it should be installed on all hosts anyway, so then the adtrust
>package would pull in the adtrust libs.
>
>Once the adtrust is installed, be it trust controller or agent, perhaps
>this should be added into the domain services tree under cn=etc. That
>way, after the adtrust is run, you can see a list of hosts that do not
>yet have it installed, so that the trust agent can be configured on all
>other replicas. Additionally, adding a new replica could be hinted that
>if this exists to configure itself as a trust agent automatically as
>part of ipa-replica-install.
>
>Does that sound like a reasonable suggestion?
Yes, this is what ipa-adtrust-install implements right now. My issue
with this approach is the fact that we don't want to run
smbd/winbindd/etc for trust agent case. Yet, ipa-adtrust-install forces
packages to be installed and services to be active.

Kind of what I meant but kind of not. I meant a more generic "some
adtrust agent or controller" flag, rather than the services. The per
host flag is to enable the detection of masters that lack adtrust agent
or controller, rather than to detect if the domain has had adtrust run
at all.

My thought was more like:

If I have three ipa masters, A B C. I have trust controller on A, and I
am installing trust agent on B, I should post install receive a message:

ipa-adtrust-install --agent:
... Install happens here ...
The following masters are not agents or controllers. These should be
promoted.
* C

To of course, prompt me to run adtrust-install on C.

Then I add some host D, it should as part of ipa-replica-install be
configured as a trust agent.

This way the domain stays consistent and I am informed of the state of
the network.

This also means there should be a strategy for promotion of the agent to
a controller, and also in the decommissioning code to remove both agent
and installers correctly (If not already implemented)
Makes sense. This will need to be added into a design page -- I'll work
on that next week. There will be series of RFE tickets to correspond to
work outlined in those design pages and this is a perfect example of an
RFE.



We can start with disabling ADTRUST and EXTID services on trust agents
(these are smb and winbind in ipactl speak) and, maybe, rename them to
something less confusing. Then we can decide whether not installing
samba server packages would really be needed.

Sounds like a good plan. Would this become a special case of
ipa-adtrust-install? Or an option that is prompted for similar to the
slapi-nis question.
For most cases like this we have CLI option and ask for an answer
interactively in case option wasn't provided explicitly and we are not
running in unattended mode.

In case of a slapi-nis it is driven by --enable-compat option of
ipa-adtrust-install. The general calling pattern in ipa-adtrust-install
is something like this:
   if not options.unattended and not options.enable_compat:
       options.enable_compat = enable_compat_tree()

where enable_compat_tree() does ask user for a confirmation.


--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Reply via email to