[Freeipa-users] freeIPA replication

[Rob Crittenden]

Виктор Сергеевич wrote:
> Hi! 
> 
> Thanks! It works!, but
> In master-server I'm see users in groups, but in replica I'm see only
> group, without users. If search users - i'm can find it. And one more:

Strange, that shouldn't happen. I'd search for them directly in LDAP to 
ensure it isn't a problem with the IPA management framework:

% ldapsearch -x -b "cn=users,cn=accounts,dc=example,dc=com" 
"(objectclass=posixuser") uid

> If I write users (Firsname and/ore lastname)in cyrillic symbols (russian
> language), save this user and try find it - I'm see "500 - internal
> server error. An unexpected error occured." 
> Prompt please - as with it it is possible to consult how 

This is a known problem 
(https://bugzilla.redhat.com/show_bug.cgi?id=490285). IPA v1 only 
supports the ASCII character set currently.

rob

> 
> Thanks
> 
> В Птн, 11/12/2009 в 13:07 -0700, Rich Megginson пишет:
>> James Roman wrote:
>>> If I remember correctly, I had to comment out the following entries in 
>>> the /etc/dirsrv/slapd-XXXX/schema/99user.ldif file:
>>>
>>> # objectClasses: ( 2.16.840.1.113730.3.2.300 NAME 'nsAIMpresence' DESC 
>>> 'Netscape
>>>  defined objectclass' SUP top AUXILIARY MAY (nsaimid $ 
>>> nsaimstatusgraphic $
>>>  nsaimstatustext ) X-ORIGIN ( 'Netscape Directory Server' 'user 
>>> defined' ) )
>>> # objectClasses: ( 2.16.840.1.113730.3.2.301 NAME 'nsICQpresence' DESC 
>>> 'Netscape
>>>  defined objectclass' SUP top AUXILIARY MAY ( nsicqid $ 
>>> nsicqstatusgraphic $
>>>  nsICQStatusText ) X-ORIGIN ( 'Netscape Directory Server' 'user 
>>> defined' ) )
>>> # objectClasses: ( 2.16.840.1.113730.3.2.302 NAME 'nsYIMpresence' DESC 
>>> 'Netscape
>>>  defined objectclass' SUP top AUXILIARY MAY ( nsyimid $ 
>>> nsyimstatusgraphic $
>>>  nsYIMStatusText ) X-ORIGIN ( 'Netscape Directory Server' 'user 
>>> defined' ) )
>>> # objectClasses: ( 2.16.840.1.113730.3.2.303 NAME 'nsMSNpresence' DESC 
>>> 'Netscape
>>>  defined objectclass' SUP top AUXILIARY MAY nsmsnid X-ORIGIN ( 
>>> 'Netscape Dir
>>> ectory Server' 'user defined' ) )
>>>
>> That should work.  The problem is that these schema should never have 
>> been in 99user.ldif in the first place.  The code has been fixed so that 
>> standard schema such as these will not be copied to 99user.ldif, and 
>> setup-ds.pl -u in 389-ds-base 1.2.3 and later will clean up 99user.ldif 
>> of these and other bogus schema.
>>>
>>> Rich Megginson wrote:
>>>> Rob Crittenden wrote:
>>>>> Виктор Сергеевич wrote:
>>>>>> On fedora 11:
>>>>>>
>>>>>> Name        : 389-ds-base                  Relocations: (not
>>>>>> relocatable)
>>>>>> Version     : 1.2.2                             Vendor: Fedora Project
>>>>>> Release     : 1.fc11                        Build Date: Wed 26 Aug 
>>>>>> 2009
>>>>>> 12:07:44 AM MSD
>>>>>> Install Date: Fri 11 Dec 2009 10:46:32 AM MSK      Build Host:
>>>>>> x86-1.fedora.phx.redhat.com
>>>>>> Group       : System Environment/Daemons    Source RPM:
>>>>>> 389-ds-base-1.2.2-1.fc11.src.rpm
>>>>>> Size        : 5080205                          License: GPLv2 with
>>>>>> exceptions
>>>>>> Signature   : RSA/SHA1, Wed 26 Aug 2009 04:34:33 PM MSD, Key ID
>>>>>> 1dc5c758d22e77f2
>>>>>> Packager    : Fedora Project
>>>>>> URL         : http://port389.org/
>>>>>> Summary     : 389 Directory Server (base)
>>>>>>
>>>>> IIRC in 389-ds 1.2.2 some schema was dropped/modified. If you try to 
>>>>> replicate between < 1.2.2 and >= 1.2.2 you can get this error 
>>>>> because the schema isn't defined on one side.
>>>>>
>>>>> I'm not sure the best way to work around this. Options include:
>>>>>
>>>>> - sync up the 389-ds versions between your servers. This would 
>>>>> likely require building your own set of rpms on one or the other.
>>>>> - add the missing schema to the F-11 server in /etc/dirsrv/schema. 
>>>>> This has the downside that you'll probably end up broken in other 
>>>>> very odd some time way into the future.
>>>>> - modify 99user.ldif on the replicated system and remove the 
>>>>> offending attributes. At the point in the replica installation where 
>>>>> this fails the installer is almost done. The only missing steps are 
>>>>> the DNS configuration and configuring the client.
>>>>>
>>>>> There may be other options, and again I'm not sure which is the best 
>>>>> at this point. Rich, what do you think?
>>>> With 389-ds-base 1.2.3 and later (1.2.5.rc2 is currently available 
>>>> from the testing repos) 99user.ldif is fixed to remove the offending 
>>>> schema upon upgrade (yum or rpm), or by doing setup-ds.pl -u.
>>>>> rob
>>>>>
>>>>> _______________________________________________
>>>>> Freeipa-users mailing list
>>>>> Freeipa-users at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>> _______________________________________________
>>>> Freeipa-users mailing list
>>>> Freeipa-users at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>
> 
> _______________________________________________
> Freeipa-users mailing list
> Freeipa-users at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users