Cal Sawyer wrote:
> Done and done, although imported users' membership in their OpenLDAP
> primary group wasn't preserved because a al catch22, that group could be
> made default until it was imported, but was easily rectified via the UI
> 
> I can almost live with these gigantic UIDs set for new users but the
> default GID, in spite of having set the default group (which is
> respected, but i would have expected the default GID to follow?) gets
> set to some unique and amusingly massive value. i've trawled a few old
> list posts but as with any project that spans years, you never know if
> you're reading something that became definitive or not, so i ask again:

I'd have expected the GID to remain. It should try to keep the existing
GID as long as there is a group on the remote LDAP server has a group
with the posixgroup objectclass and the matching gidnumber. I don't
believe the default users group has any effect here.

/var/log/httpd/error_log should contain a bunch of info on the migrated
users.

> Is it possible to pin new users' GID to my POSIX legacy "all-users"
> GID?  And is it possible to elect a starting UID?  Doesn't (although i'd
> prefer it) have to be a continuation of the POSIX range (1100+) i
> imported but something more humanly parseable would be better.  In spite
> of an early post i came across which says "consider that future merger",
> it ain;'t going to happen on a F500 scale for us

You can specify the id ranges when running ipa-server-install.
> 
> Now for something completely different(ish):  why was 4.x never build as
> EL6 RPMs?  I am "mildly" resenting having to set up EL7, with all of
> it's uncharming peculiarities, in order to get relatively recent IPA 4.1
> thus preserving future upgradability.

Because the dependency chain was too great. RHEL is about stability and
changing the KDC, LDAP server, CA, Samba and a slew of other things is
just too much.

rob

> 
> Thanks very much, Rob and Martin, for your quick and helpful replies
> 
> cheers
> 
> Cal Sawyer | Systems Engineer | BlueBolt Ltd
> 
> On 04/11/15 15:37, Rob Crittenden wrote:
>> Cal Sawyer wrote:
>>> That's terrific, Rob - thanks very much.  Users and Groups import
>>> smoothly with a little additional tweaking
>>>
>>> ipa -v migrate-ds --with-compat
>>> --bind-dn="cn=Manager,dc=ldapdomain,dc=local"
>>> --user-container="ou=People,dc=blue-bolt,dc=local"
>>> --group-container="ou=Group,dc=ldapdomain,dc=local"
>>> --group-objectclass="posixGroup" ldap://1.2.3.4:389
>>>
>>> boom, all users and groups imported ... but without group membership.
>> This is the RFC2307 schema. I think to fix you'd have to delete all IPA
>> users and groups and re-migrate.
>>
>>> The structure of Group in OpenLDAP is:
>>>
>>> # power, Group, ldapdomain.local
>>> dn: cn=systems,ou=Group,dc=ldapdomain,dc=local
>>> cn: systems
>>> gidNumber: 1112
>>> objectClass: posixGroup
>>> memberUid: usera
>>> memberUid: userb
>>>
>>>
>>> and IPA's schema appears, with one exception (objectClass: top), to
>>> match:
>>>
>>> # admins, groups, compat, ipadomain.local
>>> dn: cn=admins,cn=groups,cn=compat,dc=ipadomain,dc=local
>>> objectClass: posixGroup
>>> objectClass: top
>>> gidNumber: 1944000000
>>> memberUid: admin
>>> cn: admins
>> That's the rfc 2307 compatibility view. If you look in
>> cn=admins,cn=groups,cn=accounts,dc=ipadomain,dc=local you'll see how it
>> is actually stored.
>>
>>> A side question:  can i use migrate-ds to bring in automount and sudoer
>>> maps from OpenLDAP?
>> It's only users and groups right now.
>>
>> You might have some luck with automount importing via LDIF but at least
>> the DN structure will need to be modified. You'd need to be pretty
>> careful that the IPA schema matches your current schema.
>>
>> I think with sudo you'd be out of luck as IPA uses its own schema for
>> storing the sudo components and rules.
>>
>> rob
>>> thanks again
>>>
>>> Cal Sawyer | Systems Engineer | BlueBolt Ltd
>>> 15-16 Margaret Street | London W1W 8RW
>>> +44 (0)20 7637 5575 | www.blue-bolt.com
>>>
>>> On 04/11/15 13:56, Rob Crittenden wrote:
>>>> Cal Sawyer wrote:
>>>>> Hi
>>>>>
>>>>> Very new to IPA and setting up a proof of concept system that i hope
>>>>> will replace my existing OpenLDAP 2.3 (no SASL) setup.  I'm trying to
>>>>> import People, Group ou's into IPA using "ipa migrate-ds".  The IPA
>>>>> and
>>>>> existing LDAP directories have different BaseDNs (eg
>>>>> ipadomain.local on
>>>>> IPA, ldapdomain.local on LDAP 2.3) as i want to ideally construct a
>>>>> completely new directory that we will then switch our clients over to.
>>>>>
>>>>> ipa migrate-ds --schema=RFC2307
>>>>> --user-container="dc=ldapdomain,dc=local" ldap://1.2.3.4:389
>>>>>
>>>>> whatever i try (w or w/o --schema=RFC2307) , the response is the same:
>>>>>
>>>>>       ipa: ERROR: Insufficient access:  Invalid credentials
>>>>>
>>>>> or with a verbose flag:
>>>>>
>>>>>       ipa: INFO: Forwarding 'migrate_ds' to server
>>>>> u'https://ipa.ipadomain.local/ipa/session/xml'
>>>>>       ipa: ERROR: Insufficient access:  Invalid credentials
>>>>>
>>>>> manager naturally exists in ldapdomain.local and i've definitely
>>>>> supplied the correct password (we use the same creds to manage LDAP
>>>>> using phpldapadmin)
>>>>>
>>>>> Hoping that someone has some experience with this and can point me in
>>>>> the right direction?
>>>> It is binding to openldap using cn=Directory Manager. If your admin
>>>> user
>>>> that can read userPassword is named something different then pass it in
>>>> using the --binddn option.
>>>>
>>>> rob
>>>>
> 

-- 
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