<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hello Martin,<br><br></div>I have spent some time looking into how to address <a href="https://fedorahosted.org/freeipa/ticket/3709" target="_blank">https://fedorahosted.org/freeipa/ticket/3709</a>.  I thought I would look at --setattr --addattr from user-add and others to see if I could reuse code for --user-attr-default.  At least for parsing the commandline arguments anyway.  It does not look like it would be easy to re-purpose the code in _convert_2_dict() from ipalib/plugins/baseldap.py (without blatantly copying it).  What are your thoughts about creating a Dict paramater type in ipalib/parameters.py to to user for --setaddr --addattr --delattr and to use for --user-attr-default?<br><br></div><div>Also I was looking at string.Template() vs string.Formatter().  I think string.Template is probably sufficient.  But I don't follow PEPs so I don't know if that's Python3 future proof or not.  Thoughts?<br></div><div># Pseudocode<br></div><div>(attr, default) = args['userdefaultattr'][0].split('=',2)<br></div><div>entry_attrs[attr] = default.safe_substitute(entry_attrs.toDict())<br></div><div><br>In looking at ipalib/plugins/baseldap.py, I was wondering if It might make sense to make migrate more in line with the --*attr paramaters.<br><br></div>Consider:<br></div>ipa migrate-ds --user-delattr ou<br><br></div>Instead of:<br></div>ipa-migrate-ds --user-ignore-attribute ou<br><br></div>Then we could also add user-{setattr,addattr,delattr,attrdefault} like:<br>ipa migrate-ds --user-attrdefault "mail=$<a href="mailto:uid@example.com">uid@example.com</a>" --user-setattr
 "cn=$givenname $sn" --user-addattr description="Migrated $(date)" 
--user-delattr ou<br></div>Which would add a mail address if one wasn't present, replace the CN with the first and last name, add a description attribute and get rid of the ou attribute.<br><br></div>Another thought I had was about the behaivor of the search on the source directory.  Currently one provides --{user,group}-continer and --{user,group}-objectclass and the scope is statically defined in the script.<br><br><br></div><div>--{user,group}-filter<br>--------------------------<br></div><div><br>What about adding --{user,group}-scope ONE|SUB?<br><br></div>My directory for example is like:<br><br></div>dn: uid=me,ou=ops,ou=people,dc=example,dc=com<br></div>dn: uid=joe,ou=eng,ou=people,dc=example,dc=com<br><br></div>So currently I have to use the --continue switch and change my --user-container to get all of my users.  If the scope weren't limited to ONELEVEL then I could get everyone in one pass.<br><br></div>ipa migrate-ds --user-container ou=People,dc=example,dc=com --user-scope SUB<br><br></div>Lastly I was thinking that --user-objectclass and --exclude-users could be made more powerful with --user-filter<br><br></div>ipa migrate-ds --user-container ou=People,dc=example,dc=com --user-objectclass posixAccount --user-filter '(!(loginShell=/bin/false))' or we could fire all of sales --user-filter '(!(ou=Sales))'<br><br></div>Which gets concatenated internally in the search to "(&(objectClass=posixAccount)(!(loginShell=/bin/false)))"<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 4, 2014 at 4:59 AM, Martin Kosek <span dir="ltr"><<a href="mailto:mkosek@redhat.com" target="_blank">mkosek@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 11/26/2014 11:52 AM, Martin Kosek wrote:<br>
> On 11/24/2014 11:24 PM, Alan Evans wrote:<br>
>> I am in the midst of preparing for a migration from OpenLDAP to FreeIPA.<br>
>> ds-migrate wasn't going to fill all of my needs so I thought I would use it<br>
>> for most and then make up some LDIF's and massage them to do the last bit<br>
>> of migration.<br>
>><br>
>> I have instead decided to extend ds-migrate and I think that my features<br>
>> might be of use to others so I would like to contribute them.<br>
><br>
> Great idea! :-) IMO, enhancing FreeIPA migration capability and making it more<br>
> even more pleasant experience for user users is a good goal.<br>
><br>
>> Before I get<br>
>> too for I wanted to get some input from the community.<br>
>><br>
>> Here are MY original goals:<br>
>> * Migrate ssh public keys<br>
>>   The openssh-lpk schema is used in my tree so objectClass: ldapPublicKey<br>
>> attribute: sshPublicKey<br>
>> * Migrate disabled accounts as disabled<br>
>>   We 'disable' usere by setting their shadowExpire to a date in the past<br>
>> and setting their shell to /bin/false<br>
>><br>
>> I realized that the ssh-public key problem is more generally an attribute<br>
>> mapping problem and dealing with disabled users could be more generalized<br>
>> too.<br>
>><br>
>> Here are instead the new features I would provide.<br>
>><br>
>> * Attribute mapping<br>
>>   Feature should check the new syntax exists and is the same as the old<br>
>> syntax (perhaps further check for compatible syntax)<br>
>>   --user-attribute-map=oldAttribute=newAttribute<br>
>>   --group-attribute-map=foo=bar<br>
>>   Should I drop user/group and just make it --attribute-map and apply it to<br>
>> both?<br>
>>   Should certain attributes be mapped by default, i.e.<br>
>> sshPublicKey=ipaSSHPubKey (this means we also need to ignore the<br>
>> objectClass ldapPublicKey by default)  Maybe make a separate switch<br>
>> --with-ssh-keys that automatically adds a map and an ignore?<br>
><br>
> If the mapping sshPublicKey -> ipaSSHPubKey is clear, I would do it by default<br>
> and maybe add a switch to skip these advanced migrations. Just make sure the<br>
> expected format matches (ipa requires all 3 pieces of the public key, not just<br>
> the blob)<br>
><br>
> I think it would be very useful to combine user attribute mapping with the<br>
> ideas from<br>
><br>
> <a href="https://fedorahosted.org/freeipa/ticket/3709" target="_blank">https://fedorahosted.org/freeipa/ticket/3709</a><br>
><br>
> i.e. filling attribute with values from original entry or a default. This may<br>
> lead to following syntax:<br>
><br>
> --user-attribute-default "sn=notdefined" --user-attribute-default<br>
> "description=User with cn $cn"<br>
><br>
> which would only use the pattern if attribute is not defined in original entry<br>
><br>
> and<br>
><br>
> --user-attribute-map "sn=$cn"<br>
><br>
> which would fill overwrite the attribute even if it was defined in the original<br>
> entry.<br>
><br>
>><br>
>> * Handling disabled users<br>
>>   1. How to identify disabled users?<br>
>>     a. shadowExpire < now()<br>
>>         --use-disable-shadow-expire<br>
><br>
> How would you like to disable users then? With nsAccountLock attribute?<br>
> Wouldn't it be better to instead map shadowExpire to krbPrincipalExpiration<br>
> attribute which should have sematically the same meaning?<br>
><br>
>>     b. loginShell is one of configurable shells<br>
>>         --use-disable-login-shell<br>
>>         --disabled-shell=/bin/false --disabled-shell=/sbin/nologin (these<br>
><br>
> Is this really a general mechanism? I think Kerberos principal expiration is<br>
> the way to go:<br>
><br>
> # ipa user-mod fbar --principal-expiration 20140101000000Z<br>
><br>
> # ssh fbar@`hostname`<br>
> <a href="mailto:fbar@vm-067.idm.lab.bos.redhat.com">fbar@vm-067.idm.lab.bos.redhat.com</a>'s password:<br>
> Permission denied, please try again.<br>
><br>
> # tail /var/log/krb5kdc.log<br>
> ...<br>
> Nov 26 04:56:51 <a href="http://vm-067.idm.lab.bos.redhat.com" target="_blank">vm-067.idm.lab.bos.redhat.com</a> krb5kdc[19615](info): AS_REQ (6<br>
> etypes {18 17 16 23 25 26}) <a href="http://10.16.78.67" target="_blank">10.16.78.67</a>: CLIENT EXPIRED:<br>
> <a href="mailto:fbar@IDM.LAB.BOS.REDHAT.COM">fbar@IDM.LAB.BOS.REDHAT.COM</a> for<br>
> krbtgt/<a href="mailto:IDM.LAB.BOS.REDHAT.COM@IDM.LAB.BOS.REDHAT.COM">IDM.LAB.BOS.REDHAT.COM@IDM.LAB.BOS.REDHAT.COM</a>, Client's entry in<br>
> database has expired<br>
><br>
> It is respected by Kerberos authentication and SSSD logins, at minimum.<br>
><br>
><br>
>> two would be the defaults)<br>
>>     c. nsAccountLocked (though that would be straight copied by the<br>
>> migrator anyway<br>
><br>
> +1 for copying.<br>
><br>
>>     d. From Open DJ the attribute ds-pwp-account-disabled can be used to<br>
>> identify disabled users<br>
>>     (are there others?)<br>
>>   2.  What do do with disabled users (in my case migrate and disable)<br>
>>     a. Migrate them and don't touch nsAccountLocked<br>
>>     b. Migrate them and set nsAccountLocked = true<br>
>>        --disable-users<br>
>>     c. Do not migrate them<br>
>>        --skip-disabled-users<br>
>>     d. Which is the default?  Migrate and disable?  If so which are the<br>
>> default methods for identifying them?  All methods?<br>
><br>
> I may be missing something, but to me following would make sense:<br>
><br>
> - properly migrate and fill krbPrincipalExpiration and nsACcountLock attributes<br>
> - optionally implement --skip-disabled-users. Though it may be challenging to<br>
> implement the "is_user_disabled" function right so that it works on all sort of<br>
> DS schemes.<br>
><br>
>> So is there anything I'm missing?  Any suggestions on the switches? I'm not<br>
>> entirely sure I like them the way they are.<br>
>><br>
>> I have code to cover about 60% of the above already.  The user-attr-map<br>
>> feature is working and the --disabled-users and disabled-shells options are<br>
>> working.<br>
>><br>
>> Regards,<br>
>> -Alan<br>
<br>
</div></div>Hello Alan,<br>
<br>
Are there any updates in this noble effort? Are you stuck? Can I or the team<br>
help you in any way?<br>
<br>
Thanks,<br>
Martin<br>
</blockquote></div><br></div>