Hello Martin,
I have spent some time looking into how to address
https://fedorahosted.org/freeipa/ticket/3709. 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?
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?
# Pseudocode
(attr, default) = args['userdefaultattr'][0].split('=',2)
entry_attrs[attr] = default.safe_substitute(entry_attrs.toDict())
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.
Consider:
ipa migrate-ds --user-delattr ou
Instead of:
ipa-migrate-ds --user-ignore-attribute ou
Then we could also add user-{setattr,addattr,delattr,attrdefault} like:
ipa migrate-ds --user-attrdefault mail=$u...@example.com --user-setattr
cn=$givenname $sn --user-addattr description=Migrated $(date)
--user-delattr ou
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.
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.
--{user,group}-filter
--
What about adding --{user,group}-scope ONE|SUB?
My directory for example is like:
dn: uid=me,ou=ops,ou=people,dc=example,dc=com
dn: uid=joe,ou=eng,ou=people,dc=example,dc=com
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.
ipa migrate-ds --user-container ou=People,dc=example,dc=com --user-scope SUB
Lastly I was thinking that --user-objectclass and --exclude-users could be
made more powerful with --user-filter
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))'
Which gets concatenated internally in the search to
((objectClass=posixAccount)(!(loginShell=/bin/false)))
On Thu, Dec 4, 2014 at 4:59 AM, Martin Kosek mko...@redhat.com wrote:
On 11/26/2014 11:52 AM, Martin Kosek wrote:
On 11/24/2014 11:24 PM, Alan Evans wrote:
I am in the midst of preparing for a migration from OpenLDAP to FreeIPA.
ds-migrate wasn't going to fill all of my needs so I thought I would
use it
for most and then make up some LDIF's and massage them to do the last
bit
of migration.
I have instead decided to extend ds-migrate and I think that my features
might be of use to others so I would like to contribute them.
Great idea! :-) IMO, enhancing FreeIPA migration capability and making
it more
even more pleasant experience for user users is a good goal.
Before I get
too for I wanted to get some input from the community.
Here are MY original goals:
* Migrate ssh public keys
The openssh-lpk schema is used in my tree so objectClass:
ldapPublicKey
attribute: sshPublicKey
* Migrate disabled accounts as disabled
We 'disable' usere by setting their shadowExpire to a date in the past
and setting their shell to /bin/false
I realized that the ssh-public key problem is more generally an
attribute
mapping problem and dealing with disabled users could be more
generalized
too.
Here are instead the new features I would provide.
* Attribute mapping
Feature should check the new syntax exists and is the same as the old
syntax (perhaps further check for compatible syntax)
--user-attribute-map=oldAttribute=newAttribute
--group-attribute-map=foo=bar
Should I drop user/group and just make it --attribute-map and apply
it to
both?
Should certain attributes be mapped by default, i.e.
sshPublicKey=ipaSSHPubKey (this means we also need to ignore the
objectClass ldapPublicKey by default) Maybe make a separate switch
--with-ssh-keys that automatically adds a map and an ignore?
If the mapping sshPublicKey - ipaSSHPubKey is clear, I would do it by
default
and maybe add a switch to skip these advanced migrations. Just make sure
the
expected format matches (ipa requires all 3 pieces of the public key,
not just
the blob)
I think it would be very useful to combine user attribute mapping with
the
ideas from
https://fedorahosted.org/freeipa/ticket/3709
i.e
