[Freeipa-users] winsync agreement wipes IPA users

Rich Megginson rmeggins at redhat.com
Thu Sep 20 23:35:29 UTC 2012


On 09/20/2012 05:24 PM, Steven Jones wrote:
> disabled may not be logical as then once a user becomes disabled in 
> AD, IPA will remove it rather than act and disable it.
?
>
> The way I read this winsync is its running the same command as I did 
> initially by hand every 5mins...

The way you read what?

>
>
> regards
>
> Steven Jones
>
> Technical Specialist - Linux RHCE
>
> Victoria University, Wellington, NZ
>
> 0064 4 463 6272
>
> ------------------------------------------------------------------------
> *From:* Rich Megginson [rmeggins at redhat.com]
> *Sent:* Friday, 21 September 2012 8:53 a.m.
> *To:* Steven Jones
> *Cc:* freeipa-users at redhat.com
> *Subject:* Re: [Freeipa-users] winsync agreement wipes IPA users
>
> On 09/20/2012 02:43 PM, Steven Jones wrote:
>> Some comments on the win sync agreement syntax.
>>
>> Hi,
>>
>> I'd like that command ipa-replica-manage connect  "improved" if possible,
>>
>> 1) A flag on --win-subtree not to include sub-directories under the 
>> specified OU= as I think it is why Ive picked up lots of disabled 
>> users and templates. Also the capability to specify more than one OU 
>> as I at least have 2 OU= with users in (maybe it can do that I just 
>> dont see it)
> https://fedorahosted.org/389/ticket/460
>>
>> 2) A flag something like --exclude='LDAP criteria/attribute'=disabled 
>> such that any disabled users in AD are not transferred, I just 
>> transferred 7 years of ex-users and 200+ templates I would rather not 
>> have....now I think I have a huge cleanup task.  Not just exclude, 
>> say location, so if I only want to sync users in one city (say) 
>> --include-only="LDAP Location'=Wellington
> https://fedorahosted.org/389/ticket/460
>>
>> Not sure if these are hugely useful but they would have helped me.
>>
>> regards
>>
>> Steven Jones
>>
>> Technical Specialist - Linux RHCE
>>
>> Victoria University, Wellington, NZ
>>
>> 0064 4 463 6272
>>
>> ------------------------------------------------------------------------
>> *From:* freeipa-users-bounces at redhat.com 
>> [freeipa-users-bounces at redhat.com] on behalf of Steven Jones 
>> [Steven.Jones at vuw.ac.nz]
>> *Sent:* Thursday, 20 September 2012 2:48 p.m.
>> *Cc:* freeipa-users at redhat.com
>> *Subject:* Re: [Freeipa-users] winsync agreement wipes IPA users
>>
>> it isnt,
>>
>> Im doing a OU=VUW_Staff instead of cn=VUW_Staff and its mostly 
>> working except Im also getting some "rubbish" so its looking like the 
>> import script/query to AD isnt right.
>>
>> regards
>>
>> Steven Jones
>>
>> Technical Specialist - Linux RHCE
>>
>> Victoria University, Wellington, NZ
>>
>> 0064 4 463 6272
>>
>> ------------------------------------------------------------------------
>> *From:* freeipa-users-bounces at redhat.com 
>> [freeipa-users-bounces at redhat.com] on behalf of Steven Jones 
>> [Steven.Jones at vuw.ac.nz]
>> *Sent:* Thursday, 20 September 2012 12:15 p.m.
>> *Cc:* freeipa-users at redhat.com
>> *Subject:* Re: [Freeipa-users] winsync agreement wipes IPA users
>>
>> Hi,
>>
>> I have -win-subtree cn= etc I take it that cn= is fine and that ou= 
>> and cn= are the same thing?
>>
>> regards
>>
>> Steven Jones
>>
>> Technical Specialist - Linux RHCE
>>
>> Victoria University, Wellington, NZ
>>
>> 0064 4 463 6272
>>
>> ------------------------------------------------------------------------
>> *From:* Rich Megginson [rmeggins at redhat.com]
>> *Sent:* Thursday, 20 September 2012 11:03 a.m.
>> *To:* Steven Jones
>> *Cc:* freeipa-users at redhat.com
>> *Subject:* Re: [Freeipa-users] winsync agreement wipes IPA users
>>
>> On 09/19/2012 04:55 PM, Steven Jones wrote:
>>> Hi,
>>>
>>>
>>> Sample of errors log,
>>>
>>> =========
>>> [17/Sep/2012:13:31:48 +1200] NSMMReplicationPlugin - changelog 
>>> program - _cl5GetDBFileByReplicaName: found DB object 1bcf2e0 for 
>>> database 
>>> /var/lib/dirsrv/slapd-ODS-VUW-AC-NZ/cldb/32d77a0d-778a11e1-a445c792-b25c661e_4fbdbe64000000040000.db4
>>> [17/Sep/2012:13:31:48 +1200] NSMMReplicationPlugin - changelog 
>>> program - _cl5GetDBFileByReplicaName: found DB object 1bcf2e0 for 
>>> database 
>>> /var/lib/dirsrv/slapd-ODS-VUW-AC-NZ/cldb/32d77a0d-778a11e1-a445c792-b25c661e_4fbdbe64000000040000.db4
>>> [17/Sep/2012:13:31:48 +1200] NSMMReplicationPlugin - ruv_update_ruv: 
>>> successfully committed csn 504d01f7000000110000
>>> [17/Sep/2012:13:31:48 +1200] NSMMReplicationPlugin - 
>>> agmt="cn=meTovuwunicoipam002.ods.vuw.ac.nz" (vuwunicoipam002:389): 
>>> State: stop_fatal_error -> stop_fatal_error
>>> [17/Sep/2012:13:31:48 +1200] NSMMReplicationPlugin - 
>>> agmt="cn=meTovuwunicoipam003.ods.vuw.ac.nz" (vuwunicoipam003:389): 
>>> State: stop_fatal_error -> stop_fatal_error
>>> [17/Sep/2012:13:31:48 +1200] NSMMReplicationPlugin - 
>>> ruv_add_csn_inprogress: successfully inserted csn 
>>> 504d01f8000000110000 into pending list
>>> [17/Sep/2012:13:31:48 +1200] NSMMReplicationPlugin - Purged state 
>>> information from entry 
>>> uid=jonesst1,cn=users,cn=accounts,dc=ods,dc=vuw,dc=ac,dc=nz up to 
>>> CSN 504d42c5000000040000
>>> [17/Sep/2012:13:31:48 +1200] NSMMReplicationPlugin - changelog 
>>> program - _cl5GetDBFileByReplicaName: found DB object 1bcf2e0 for 
>>> database 
>>> /var/lib/dirsrv/slapd-ODS-VUW-AC-NZ/cldb/32d77a0d-778a11e1-a445c792-b25c661e_4fbdbe64000000040000.db4
>>> [17/Sep/2012:13:31:48 +1200] NSMMReplicationPlugin - changelog 
>>> program - _cl5GetDBFileByReplicaName: found DB object 1bcf2e0 for 
>>> database 
>>> /var/lib/dirsrv/slapd-ODS-VUW-AC-NZ/cldb/32d77a0d-778a11e1-a445c792-b25c661e_4fbdbe64000000040000.db4
>>> [17/Sep/2012:13:31:48 +1200] NSMMReplicationPlugin - ruv_update_ruv: 
>>> successfully committed csn 504d01f8000000110000
>>> [17/Sep/2012:13:31:48 +1200] NSMMReplicationPlugin - 
>>> agmt="cn=meTovuwunicoipam002.ods.vuw.ac.nz" (vuwunicoipam002:389): 
>>> State: stop_fatal_error -> stop_fatal_error
>>> [17/Sep/2012:13:31:48 +1200] NSMMReplicationPlugin - 
>>> agmt="cn=meTovuwunicoipam003.ods.vuw.ac.nz" (vuwunicoipam003:389): 
>>> State: stop_fatal_error -> stop_fatal_error
>>> =========
>>
>> Is cn=meTovuwunicoipam003.ods.vuw.ac.nz the windows sync agreement?
>>
>>>
>>>
>>>
>>> regards
>>>
>>> Steven Jones
>>>
>>> Technical Specialist - Linux RHCE
>>>
>>> Victoria University, Wellington, NZ
>>>
>>> 0064 4 463 6272
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Rich Megginson [rmeggins at redhat.com]
>>> *Sent:* Wednesday, 19 September 2012 12:32 a.m.
>>> *To:* Steven Jones
>>> *Cc:* freeipa-users at redhat.com
>>> *Subject:* Re: [Freeipa-users] winsync agreement wipes IPA users
>>>
>>> On 09/17/2012 07:10 PM, Steven Jones wrote:
>>>> Hi,
>>>>
>>>> I understand that I'll lose users that are cn=Staff_Admins,dc=etc
>>>>
>>>> So the Q is why I am losing users in the --win-subtree 
>>>> cn=VUW_Staff,dc= etc
>>>
>>>
>>>
>>>>
>>>> This I dont understand....
>>>>
>>>> I have the -v already, anyway to make it very verbose?
>>>
>>> http://port389.org/wiki/FAQ#Troubleshooting
>>> Use the replication log level  8192
>>> I'd like to see the directory server errors log 
>>> /var/log/dirsrv/slapd-DOMAIN/errors when winsync deletes entries 
>>> under the --win-subtree cn=VUW_Staff,dc= etc
>>>
>>>>
>>>> regards
>>>>
>>>> Steven Jones
>>>>
>>>> Technical Specialist - Linux RHCE
>>>>
>>>> Victoria University, Wellington, NZ
>>>>
>>>> 0064 4 463 6272
>>>>
>>>> ------------------------------------------------------------------------
>>>> *From:* Rich Megginson [rmeggins at redhat.com]
>>>> *Sent:* Tuesday, 18 September 2012 12:47 p.m.
>>>> *To:* Steven Jones
>>>> *Cc:* freeipa-users at redhat.com
>>>> *Subject:* Re: [Freeipa-users] winsync agreement wipes IPA users
>>>>
>>>> On 09/17/2012 06:17 PM, Steven Jones wrote:
>>>>> Hi,
>>>>>
>>>>> The first time missed the --win-subtree settings so I wiped the 
>>>>> admins in the IPA admin group and users as they were not in 
>>>>> cn=users as per the bug.  The second time as far as I can tell I 
>>>>> specified the correct cn via win-subtree flag but I still appear 
>>>>> to have lost the users in IPA.....now I expected to lose the 
>>>>> admins but the loss of users as well confounds me.
>>>>>
>>>>> I did a ldapsearch as per checking and its seems to be saying the 
>>>>> right folder/ou/cn but IPA is empty.
>>>>>
>>>>> Hence I was wondering if there was a log recording what the update 
>>>>> was doing so I could try and figure out the mistake.  Ive tried 
>>>>> greping cant find any indication.
>>>>>
>>>>> I will re-try with -v, verbose.
>>>>
>>>> It is not clear from the manuals, but no matter what -win-subtree 
>>>> you specify, winsync will search AD starting from the dc=domain 
>>>> suffix.  So, for example, if you have
>>>> cn=mystaff,cn=staff,dc=example,dc=com
>>>> and you specify
>>>> --win-subtree "cn=mystaff,cn=staff,dc=example,dc=com"
>>>> winsync will still search starting from dc=example,dc=com and will 
>>>> hit ticket/355 if there are any users outside of 
>>>> cn=mystaff,cn=staff,dc=example,dc=com that have the same username 
>>>> as a user in IPA.
>>>>
>>>>>
>>>>> regards
>>>>>
>>>>> Steven Jones
>>>>>
>>>>> Technical Specialist - Linux RHCE
>>>>>
>>>>> Victoria University, Wellington, NZ
>>>>>
>>>>> 0064 4 463 6272
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *From:* Rich Megginson [rmeggins at redhat.com]
>>>>> *Sent:* Tuesday, 18 September 2012 11:37 a.m.
>>>>> *To:* Steven Jones
>>>>> *Cc:* freeipa-users at redhat.com
>>>>> *Subject:* Re: [Freeipa-users] winsync agreement wipes IPA users
>>>>>
>>>>> On 09/17/2012 04:17 PM, Steven Jones wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I just tried to do a winsync agreement with specifying the AD 
>>>>>> point as cn=VUW_Staff,dc=staff,dc=vuw,dc=vuw,dc=ac,dc=nz  as my 
>>>>>> users are not in the users folder but the VUW_Staff folder (at 
>>>>>> the same level) and it wiped all IPA users that are also in AD.
>>>>>
>>>>> Yes, this is what happens with https://fedorahosted.org/389/ticket/355
>>>>> #355     winsync should not delete entry that appears to be out of 
>>>>> scope
>>>>>
>>>>>> While doing the actual update does this get verbosly logged 
>>>>>> anywhere as opposed to "update in progress" dumped to the 
>>>>>> screen?  Something went badly wrong, I just dont know what.
>>>>>
>>>>> You are seeing something different than #355?
>>>>>
>>>>>>
>>>>>> :/
>>>>>>
>>>>>> regards
>>>>>>
>>>>>> Steven Jones
>>>>>>
>>>>>> Technical Specialist - Linux RHCE
>>>>>>
>>>>>> Victoria University, Wellington, NZ
>>>>>>
>>>>>> 0064 4 463 6272
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20120920/944cc969/attachment.htm>


More information about the Freeipa-users mailing list