[Freeipa-devel] [PATCH] Add DS to IPA migration plugin and password migration page.

Dmitri Pal dpal at redhat.com
Fri Oct 30 20:40:35 UTC 2009


Rob Crittenden wrote:
> Dmitri Pal wrote:
>> Simo Sorce wrote:
>>> On Fri, 2009-10-30 at 15:56 -0400, Dmitri Pal wrote:
>>>  
>>>> But then you have to update it on all replicas and will definitely
>>>> forget to do it.
>>>> Is it really a hassle to have it in the DS?
>>>>     
>>> Yes it means you have to build a UI to manage that attribute, create
>>> it,
>>> find a place where to store it in the tree etc.. and adds cruft to the
>>> tree.
>>>
>>>   
>> There are a lot of other things that we put in the cn=config replicate
>> but do not provide UI.
>> Admin will just run ldapmodify command for this attribute and this is
>> it.
>
> I agree with Simo. I think it would require more development time than
> user's would benefit.
>
> We can always include this static file when we create replicas (just
> won't help those replica's already created). It is simple enough to
> copy a file around.
>
> Plus in order to store it in an LDAP attribute it means that whatever
> page displays the message needs to be a separate server-side program
> that reads and displays the data. Not difficult, again just seems like
> overkill.
>

I agree that file is easier. But I though that on the grand scale of
things we want to reduce the amount of things that are configured in the
files
and not natively replicated by DS.
We talked about moving part of the kdc configuration into the DS for
example so I was thinking that if we plan to do it eventually why create
other pieces scattered around that we would have to put into DS later.
Why not do it right away.
A bit of upfront work now, not huge though, but paves a road for better
config param centralization and elimination of the scattered config files.

But if you say it is not worth it and too much a can understand.
 

>>
>>> A file is a simple drop in and admins can easily change it at any time.
>>>
>>> True, if they forget to replicate it on other servers it will get
>>> out of
>>> sync, but it is also easy to fix that if it happens. We can put a
>>> comment in the template that reminds admins to always replicate it to
>>> all servers.
>>>   
>> Why it should be limited to a server. This IMO will be an artificaial
>> limitation.
>> Any server can perform migration and replicate the created kerberos keys
>> so why limit?
>
> I agree with you here. No reason any IPA server can't assist with the
> migration.
>
>>
>>> However do you think admins will set it up on all servers ? 
>> Yes. I do not see "set". Functionality is just there available from any
>> server.
>>  They do not need to do anything to set it up.
>
> I agree.
>
> rob
>
>>
>>> I was
>>> thinking they would set up the migration stuff only on one server and
>>> give out only one server URL, so I don't think we should care about
>>> replicating it to other servers normally.
>>>
>>> Simo.
>>>
>>>   
>>
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/




More information about the Freeipa-devel mailing list