From rmeggins at redhat.com Thu Oct 1 14:10:56 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 01 Oct 2009 08:10:56 -0600 Subject: [389-users] 389 unusable on F11? In-Reply-To: <4AC3974A.5040102@analograils.com> References: <4AA9B9FD.8090504@analograils.com> <4AAA7E16.5080309@redhat.com> <4AC3974A.5040102@analograils.com> Message-ID: <4AC4B870.6020703@redhat.com> Kevin Bowling wrote: > On 9/11/2009 12:43 PM, Noriko Hosoi wrote: >> On 09/10/2009 07:46 PM, Kevin Bowling wrote: >>> Hi, >>> >>> I have been running FDS/389 on a F11 xen DomU for several months. I >>> use it as the backend for UNIX username/passwords and also for >>> redMine (a Ruby on Rails bug tracker) for http://www.gnucapplus.org/. >>> >>> This VM would regularly lock up every week or so when 389 was still >>> called FDS. I've since upgraded to 389 by issuing 'yum upgrade' as >>> well as running the 'setup-...-.pl -u' script and now it barely goes >>> a day before crashing. When ldap crashes, the whole box basically >>> becomes unresponsive. >>> >>> I left the Xen hardware console open to see what was up and the only >>> thing I could conclude was that 389 was crashing (if I issued a >>> service start it came back to life). Doing anything like a top or >>> ls will completely kill the box. Likewise, the logs show nothing at >>> or before the time of crash. I suspected too few file descriptors >>> but changing that to a very high number had no impact. >>> >>> I was about to do a rip and replace with OpenLDAP which I use very >>> sucesessfully for our corporate systems but figured I ought to see >>> if anyone here can help or if I can submit any kind of meaningful >>> bug report first. I assume I will need to run 389's slapd without >>> daemonizing it and hope it spits something useful out to stderr. >>> Any advice here would be greatly appreciated, as would any success >>> stories of using 389 on F11. >> Hello Kevin, >> >> You specified the platform "F11 xen DomU". Did you have a chance to >> run the 389 server on any other platforms? I'm wondering if the >> crash is observed only on the specific platform or not. Is the >> server running on the 64-bit machine or 32-bit? >> >> If you start the server with "-d 1" option, the server will run as >> the trace mode. (E.g., /usr/lib[64]/dirsrv/slapd-YOURID/start-slapd >> -d 1) >> >> I'm afraid it might be a memory leak. When you restart the 389 >> server, could you check the size of ns-slapd some time like every >> hour and see if the server size keeps growing or stops? Also, the >> server quits if it fails to write to the errors log. If it happens, >> it's logged in the system log. Does the messages file on the system >> happen to have some logs related to the 389 server? >> >> Thanks, >> --noriko >>> >>> I'm not subscribed to the list so please CC. >>> >>> Regards, >>> >>> Kevin Bowing > > It was stable for 17 days while running with debug enabled to > console. I upgraded to the F11 2.6.30 kernel rebase, and now I get > some debugging info on the console. I'm taking a wild guess that it > is timing related. Where should I place a bug report? Is it related to this - https://bugzilla.redhat.com/show_bug.cgi?id=521637 > > Regards, > Kevin > > [root at buildbox-a2 ~]# xm console 8 > INFO: task kjournald:61 blocked for more than 120 seconds. > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > kjournald D ffff88003e932000 0 61 2 > ffff88003e919d40 0000000000000246 ffffffff8100e45c 0000000000000000 > 000000001cee5db8 ffff88003e919d20 ffffffff8100ee82 0000000000000202 > ffff88003e9c83a8 000000000000e2e8 ffff88003e9c83a8 0000000000012d00 > Call Trace: > [] ? xen_force_evtchn_callback+0x20/0x36 > [] ? check_events+0x12/0x20 > [] ? xen_restore_fl_direct_end+0x0/0x1 > [] ? _spin_unlock_irqrestore+0x4e/0x64 > [] schedule+0x21/0x49 > [] journal_commit_transaction+0x13d/0xe42 > [] ? xen_force_evtchn_callback+0x20/0x36 > [] ? autoremove_wake_function+0x0/0x5f > [] ? try_to_del_timer_sync+0x69/0x87 > [] kjournald+0xfd/0x253 > [] ? autoremove_wake_function+0x0/0x5f > [] ? kjournald+0x0/0x253 > [] kthread+0x6d/0xae > [] child_rip+0xa/0x20 > [] ? restore_args+0x0/0x30 > [] ? child_rip+0x0/0x20 > INFO: task ns-slapd:1034 blocked for more than 120 seconds. > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > ns-slapd D ffffc20000000000 0 1034 1 > ffff88003dd87908 0000000000000282 ffff88003dd87868 ffffffff8100ed0d > ffff88003dd86000 00000000e59205a0 ffff88003dd87888 ffffffff8107957a > ffff88003d4fe0e8 000000000000e2e8 ffff88003d4fe0e8 0000000000012d00 > Call Trace: > [] ? xen_clocksource_get_cycles+0x1c/0x32 > [] ? clocksource_read+0x22/0x38 > [] ? ktime_get_ts+0x61/0x7d > [] ? sync_buffer+0x0/0x6b > [] schedule+0x21/0x49 > [] io_schedule+0x44/0x6c > [] sync_buffer+0x53/0x6b > [] __wait_on_bit_lock+0x55/0xb2 > [] ? find_get_page+0x64/0xa3 > [] out_of_line_wait_on_bit_lock+0x7d/0x9c > [] ? sync_buffer+0x0/0x6b > [] ? wake_bit_function+0x0/0x5a > [] __lock_buffer+0x3d/0x53 > [] lock_buffer+0x49/0x64 > [] do_get_write_access+0x82/0x3f3 > [] ? journal_add_journal_head+0xce/0x162 > [] journal_get_write_access+0x3a/0x65 > [] __ext3_journal_get_write_access+0x34/0x74 > [] ext3_reserve_inode_write+0x50/0xaa > [] ext3_mark_inode_dirty+0x4f/0x80 > [] ext3_dirty_inode+0x79/0xa7 > [] __mark_inode_dirty+0x45/0x190 > [] file_update_time+0xc0/0x113 > [] do_wp_page+0x610/0x658 > [ "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > kjournald D ffff88003e932000 0 61 2 > ffff88003e919d40 0000000000000246 ffffffff8100e45c 0000000000000000 > 000000001cee5db8 ffff88003e919d20 ffffffff8100ee82 0000000000000202 > ffff88003e9c83a8 000000000000e2e8 ffff88003e9c83a8 0000000000012d00 > Call Trace: > [] ? xen_force_evtchn_callback+0x20/0x36 > [] ? check_events+0x12/0x20 > [] ? xen_restore_fl_direct_end+0x0/0x1 > [] ? _spin_unlock_irqrestore+0x4e/0x64 > [] schedule+0x21/0x49 > [] journal_commit_transaction+0x13d/0xe42 > [] ? xen_force_evtchn_callback+0x20/0x36 > [] ? autoremove_wake_function+0x0/0x5f > [] ? try_to_del_timer_sync+0x69/0x87 > [] kjournald+0xfd/0x253 > [] ? autoremove_wake_function+0x0/0x5f > [] ? kjournald+0x0/0x253 > [] kthread+0x6d/0xae > [] child_rip+0xa/0x20 > [] ? restore_args+0x0/0x30 > [] ? child_rip+0x0/0x20 > INFO: task ns-slapd:1034 blocked for more than 120 seconds. > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > ns-slapd D ffffc20000000000 0 1034 1 > ffff88003dd87908 0000000000000282 ffff88003dd87868 ffffffff8100ed0d > ffff88003dd86000 00000000e59205a0 ffff88003dd87888 ffffffff8107957a > ffff88003d4fe0e8 000000000000e2e8 ffff88003d4fe0e8 0000000000012d00 > Call Trace: > [] ? xen_clocksource_get_cycles+0x1c/0x32 > [] ? clocksource_read+0x22/0x38 > [] ? ktime_get_ts+0x61/0x7d > [] ? sync_buffer+0x0/0x6b > [] schedule+0x21/0x49 > [] io_schedule+0x44/0x6c > [] sync_buffer+0x53/0x6b > [] __wait_on_bit_lock+0x55/0xb2 > [] ? find_get_page+0x64/0xa3 > [] out_of_line_wait_on_bit_lock+0x7d/0x9c > [] ? sync_buffer+0x0/0x6b > [] ? wake_bit_function+0x0/0x5a > [] __lock_buffer+0x3d/0x53 > [] lock_buffer+0x49/0x64 > [] do_get_write_access+0x82/0x3f3 > [] ? journal_add_journal_head+0xce/0x162 > [] journal_get_write_access+0x3a/0x65 > [] __ext3_journal_get_write_access+0x34/0x74 > [] ext3_reserve_inode_write+0x50/0xaa > [] ext3_mark_inode_dirty+0x4f/0x80 > [] ext3_dirty_inode+0x79/0xa7 > [] __mark_inode_dirty+0x45/0x190 > [] file_update_time+0xc0/0x113 > [] do_wp_page+0x610/0x658 > [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e > [] handle_mm_fault+0x6a2/0x72e > [] ? _spin_unlock_irqrestore+0x4e/0x64 > [] do_page_fault+0x226/0x24f > [] page_fault+0x25/0x30 > INFO: task ns-slapd:1040 blocked for more than 120 seconds. > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > ns-slapd D ffff88003e932024 0 1040 1 > ffff88003bc119f8 0000000000000282 ffffffff8100e45c ffffc20000025410 > 00000000f1efb74c ffff88003bc119d8 ffffffff8100ee82 0000000000000004 > ffff88003bc0b248 000000000000e2e8 ffff88003bc0b248 0000000000012d00 > Call Trace: > [] ? xen_force_evtchn_callback+0x20/0x36 > [] ? check_events+0x12/0x20 > [] ? xen_restore_fl_direct_end+0x0/0x1 > [] ? _spin_unlock_irqrestore+0x4e/0x64 > [] ? check_events+0x12/0x20 > [] schedule+0x21/0x49 > [] start_this_handle+0x2d4/0x373 > [] ? autoremove_wake_function+0x0/0x5f > [] journal_start+0xb7/0x106 > [] ext3_journal_start_sb+0x62/0x78 > [] ext3_journal_start+0x28/0x3e > [] ext3_dirty_inode+0x3e > > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From psundaram at wgen.net Thu Oct 1 14:33:11 2009 From: psundaram at wgen.net (Prashanth Sundaram) Date: Thu, 01 Oct 2009 10:33:11 -0400 Subject: [389-users] one-way winsync Message-ID: Dear 389-ds community, I have a question about windows sync agreement. Here?s the scenario: two Windows DC?s and two 389-ds servers as below. Question1: Can I setup a one-way winsync i.e from windows to ldap? I have tried it and it was like hit or miss. I did this by not giving the ?write? permissions to AD for ?CN=Sync Manager?. Is this valid way of sync-ing one way? I have error messages ?Replica has no update vector. It has never been initialized?. I did a full-resynchronization and it went well without errors. But I am not seeing any entry updates. Question2: If I have windows sync on both the 389-ds sync-ing to a diferent DC. Does it cause any loop or issues. The problem I am facing is, that I have different OU?s in AD like ou=Marketing, ou=Finance, ou=Customers and only one ?ou=People? in 389-ds. I want only one-way sync. AD-->389-ds Topology I am trying to make work. Please share your comments. |--------| |------- | | DC-1 | <---replication----> | DC-2 | |--------| |--------| | | winsync Winsync | | |---------| |-------- | | 389-1 | <---replication----> | 389-2 | |---------| |---------| Thanks, Prashanth -------------- next part -------------- An HTML attachment was scrubbed... URL: From zreoxx at gmail.com Thu Oct 1 15:40:08 2009 From: zreoxx at gmail.com (Andreas Andersson) Date: Thu, 1 Oct 2009 17:40:08 +0200 Subject: [389-users] posixGroup and 389 DS Message-ID: <60C300AF-3A75-4E16-B9F4-BFEA5BC70D67@gmail.com> Hi! I have a question related to Linux authentication and authorization against 389 DS. Hope someone out there has experience about connecting Linux Server to 389 DS. What I have done is creating posixAccounts, default account groups and several groups used for admin rights. First I tried using uniqueMember= as member reference attribute on each posix group. It only works with less than 600 users and isn't ideal as nss_ldap seems to treat the attribute uniqueMember as an account _or_ a group and runs additional queries on each uniqueMember found within the group. Instead I have tested to use memberUid=. Works much better! No additional queries. But... I would prefer using full DN as reference within the directory. Now over to my questions: Has anyone successfully used uniqueMember as member attribute for linux authentication? With several thousands of users ? Are there any documented "best practices" to setup linux authentication and authorization against 389? I may have missed them on Google :) ? Anyone with experience... I need all feedback I can get right now and are looking for a long-term working solution. Best Regards - Andreas Examples of my idea of using posixGroups (that doesn't do the the additional queries using memberUid): # Account: dn: uid=aandersson,ou=People,dc=domain,dc=com objectClass: top objectClass: organizationalPerson objectClass: person objectClass: posixaccount gidNumber: 1000 homeDirectory: /home/aandersson uidNumber: 1000 gecos: Andreas Andersson loginShell: /bin/bash givenName: Andreas uid: aandersson cn: Andreas Andersson sn: Andersson Default Group: #dn: cn=aandersson,ou=Groups,dc=domain,dc=com objectClass: posixGroup objectClass: top gidNumber: 1000 cn: aandersson description: Default group for 'aandersson' Member Group: #dn: cn=adminmembers,ou=Groups,dc=domain,dc=com memberUid: aandersson memberUid: jdoe memberUid: jsmith gidNumber: 1002 description: Linux Administrators objectClass: top objectClass: posixGroup cn: adminmembers From mikael.kermorgant at gmail.com Fri Oct 2 13:44:48 2009 From: mikael.kermorgant at gmail.com (Mikael Kermorgant) Date: Fri, 2 Oct 2009 15:44:48 +0200 Subject: [389-users] server crash (389 server 1.2.1 on FC10 domu / centos 5.3 dom0) Message-ID: <9711147e0910020644p2b0fdfcey68ce337c9eeec894@mail.gmail.com> Hello, We've recently migrated our old FDS 1.0.2/FC4 setup to a new one hosted on a xen virtualised FC10. The dom0 is centos 5.3 and 389 server version is 1.2.1. It has been working about a week, but we have recently faced some crashes. First ones were the day after a schema modification on the master which had not been weel propagated on the slaves. This could be the explanation but I'm not really sure as it worked well several hours. The last one was today when using the console. Problem is we have no logs. Server suddenly freezes and is no more available via ssh , vnc or xen console. Would somebody have an idea about which steps to debug this situation ? Could it be that virtualizing FC1 on Centos 5.3 was a bad idea ? Regards, -- Mikael Kermorgant From rmeggins at redhat.com Fri Oct 2 15:24:33 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 02 Oct 2009 09:24:33 -0600 Subject: [389-users] server crash (389 server 1.2.1 on FC10 domu / centos 5.3 dom0) In-Reply-To: <9711147e0910020644p2b0fdfcey68ce337c9eeec894@mail.gmail.com> References: <9711147e0910020644p2b0fdfcey68ce337c9eeec894@mail.gmail.com> Message-ID: <4AC61B31.5060007@redhat.com> Mikael Kermorgant wrote: > Hello, > > We've recently migrated our old FDS 1.0.2/FC4 setup to a new one > hosted on a xen virtualised FC10. The dom0 is centos 5.3 and 389 > server version is 1.2.1. > > It has been working about a week, but we have recently faced some crashes. > > First ones were the day after a schema modification on the master > which had not been weel propagated on the slaves. How did you modify the schema on the master? > This could be the > explanation but I'm not really sure as it worked well several hours. > > The last one was today when using the console. > Try console -D 9 -f console.log if you can reproduce the > Problem is we have no logs. Server suddenly freezes and is no more > available via ssh , vnc or xen console. > So the entire VM freezes, not just the directory server? So you see the server crashing and the VM freezing? > Would somebody have an idea about which steps to debug this situation ? > Anything in the error log? /var/log/messages ? any other log files in /var/log? > Could it be that virtualizing FC1 on Centos 5.3 was a bad idea ? > > Regards, > > -- > Mikael Kermorgant > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From mikael.kermorgant at gmail.com Fri Oct 2 15:46:16 2009 From: mikael.kermorgant at gmail.com (Mikael Kermorgant) Date: Fri, 2 Oct 2009 17:46:16 +0200 Subject: [389-users] server crash (389 server 1.2.1 on FC10 domu / centos 5.3 dom0) In-Reply-To: <4AC61B31.5060007@redhat.com> References: <9711147e0910020644p2b0fdfcey68ce337c9eeec894@mail.gmail.com> <4AC61B31.5060007@redhat.com> Message-ID: <9711147e0910020846m4387337et1ec5e9ef05d5d942@mail.gmail.com> On Fri, Oct 2, 2009 at 5:24 PM, Rich Megginson wrote: > Mikael Kermorgant wrote: >> >> Hello, >> >> First ones were the day after a schema modification on the master >> which had not been weel propagated on the slaves. > > How did you modify the schema on the master? Via the console, by adding an attribute. Had to copy the schema files to the slaves later. >> >> This could be the >> explanation but I'm not really sure as it worked well several hours. >> >> The last one was today when using the console. >> > > Try console -D 9 -f console.log if you can reproduce the Ok, I'll try that next time. >> Problem is we have no logs. Server suddenly freezes and is no more >> available via ssh , vnc or xen console. >> > > So the entire VM freezes, not just the directory server? > So you see the server crashing and the VM freezing? Yes, sort of. I still had control of the cursor but could not ctrl+c the console on the xterm >> Would somebody have an idea about which steps to debug this situation ? >> > > Anything in the error log? ?/var/log/messages ? ?any other log files in > /var/log? Only in /var/log/xen/xend.log which indicates that this is quite offtopic. I'll see what I can find on the xen side, Thanks, Mikael From emmanuel.billot at ird.fr Fri Oct 2 19:11:38 2009 From: emmanuel.billot at ird.fr (Emmanuel BILLOT) Date: Fri, 02 Oct 2009 21:11:38 +0200 Subject: [389-users] Windows Sync Message-ID: <4AC6506A.5020705@ird.fr> Hi, Windows Sync does not work. We use administrtor account to bind. Extract from log : 02/Oct/2009:17:11:22 +0200] - _csngen_adjust_local_time: gen state before 4ac618150001:1254496277:0:0 [02/Oct/2009:17:11:22 +0200] - _csngen_adjust_local_time: gen state after 4ac6181a0000:1254496282:0:0 [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 4ac6181a000000010000 into pending list [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - csn=4ac6181a000000010000 process postop: canceling operation csn [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - add operation of entry uid=zizou,ou=People,ou=orleans,dc=ird,dc=fr returned: 32 [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry from dirsync: CN=Duplicateurs,CN=Builtin,DC=maqird,DC=fr [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry from dirsync: CN=Administrateurs de l'entreprise,CN=Users,DC=maqird,DC=fr [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry from dirsync: CN=jean bon,OU=utilisateurs,OU=ORLEANS,DC=maqird,DC=fr [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): map_entry_dn_inbound: looking for local entry matching AD entry [CN=jean bon,OU=utilisateurs,OU=ORLEANS,DC=maqird,DC=fr] [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): map_entry_dn_inbound: looking for local entry by guid [6615b9abafd05c4da997ca3c89b7ab1b] [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): map_entry_dn_inbound: problem looking for guid: -1 [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): map_entry_dn_inbound: looking for local entry by uid [bon] [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): map_entry_dn_inbound: problem looking for username: -1 [02/Oct/2009:17:11:22 +0200] - Windows sync entry: Adding new local entry dn: uid=bon,ou=People,ou=orleans,dc=ird,dc=fr objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetOrgPerson objectClass: ntUser ntUserDeleteAccount: true uid: bon sn: bon givenName: jean cn: jean bon ntUserCodePage: 0 ntUserAcctExpires: 9223372036854775807 ntUserDomainId: bon ntUniqueId: 6615b9abafd05c4da997ca3c89b7ab1b [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 4ac6181a000100010000 into pending list [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - csn=4ac6181a000100010000 process postop: canceling operation csn [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - add operation of entry uid=bon,ou=People,ou=orleans,dc=ird,dc=fr returned: 32 [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry from dirsync: OU=utilisateurs,OU=ORLEANS,DC=maqird,DC=fr [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): map_entry_dn_inbound: looking for local entry matching AD entry [OU=utilisateurs,OU=ORLEANS,DC=maqird,DC=fr] [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): map_entry_dn_inbound: looking for local entry by guid [6bb1176df971904f9e2ea760d58ac3b3] [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): map_entry_dn_inbound: problem looking for guid: -1 [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): map_entry_dn_inbound: AD entry has no username! [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): windows_process_dirsync_entry: failed to map inbound entry OU=utilisateurs,OU=ORLEANS,DC=maqird,DC=fr - rc is -1 dn is [null]. [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry from dirsync: CN=Administrateurs du sch??ma,CN=Users,DC=maqird,DC=fr [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry from dirsync: CN=Admins du domaine,CN=Users,DC=maqird,DC=fr [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry from dirsync: OU=ORLEANS,DC=maqird,DC=fr [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): Beginning linger on the connection [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): windows_tot_run: failed to obtain data to send to the consumer; LDAP error - 32 [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): No linger to cancel on the connection [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): Disconnected from the consumer [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): State: start -> ready_to_acquire_replica [02/Oct/2009:17:11:22 +0200] - acquire_replica, supplier RUV: [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - supplier: {replicageneration} 4a1e8d0b000000010000 [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - supplier: {replica 1 ldap://obiwan:389} 4a1e9575000000010000 4ac616f7000100010000 4ac616f8 [02/Oct/2009:17:11:23 +0200] - acquire_replica, consumer RUV: [02/Oct/2009:17:11:23 +0200] - acquire_replica, consumer RUV = null [02/Oct/2009:17:11:23 +0200] - acquire_replica, supplier RUV is newer [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): Trying secure slapi_ldap_init_ext [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): binddn = cn=administrateur,cn=Users,dc=maqird,dc=fr, passwd = {DES}NfWmOGRvsgfwJqTMBJagtA== [02/Oct/2009:17:11:23 +0200] - windows_conn_connect : detected Win2k3 peer [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): No linger to cancel on the connection [02/Oct/2009:17:11:23 +0200] - _csngen_adjust_local_time: gen state before 4ac6181a0002:1254496282:0:0 [02/Oct/2009:17:11:23 +0200] - _csngen_adjust_local_time: gen state after 4ac6181b0000:1254496283:0:0 [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - windows_acquire_replica returned success (101) [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): State: ready_to_acquire_replica -> sending_updates [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): Replica has no update vector. It has never been initialized. [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): Beginning linger on the connection [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x" (maqsvrdc0001:636): Linger timeout has expired on the connection -- ========================================== Emmanuel BILLOT IRD - Orl?ans D?l?gation aux Syst?mes d'Information (DSI) t?l : 02 38 49 95 88 ========================================== From rmeggins at redhat.com Fri Oct 2 20:40:44 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 02 Oct 2009 14:40:44 -0600 Subject: [389-users] server crash (389 server 1.2.1 on FC10 domu / centos 5.3 dom0) In-Reply-To: <9711147e0910020846m4387337et1ec5e9ef05d5d942@mail.gmail.com> References: <9711147e0910020644p2b0fdfcey68ce337c9eeec894@mail.gmail.com> <4AC61B31.5060007@redhat.com> <9711147e0910020846m4387337et1ec5e9ef05d5d942@mail.gmail.com> Message-ID: <4AC6654C.9030501@redhat.com> Mikael Kermorgant wrote: > On Fri, Oct 2, 2009 at 5:24 PM, Rich Megginson wrote: > >> Mikael Kermorgant wrote: >> >>> Hello, >>> >>> First ones were the day after a schema modification on the master >>> which had not been weel propagated on the slaves. >>> >> How did you modify the schema on the master? >> > > Via the console, by adding an attribute. > Had to copy the schema files to the slaves later. > Were there any messages in the errors logs on the supplier or consumers about not being able to replicate the schema? > >>> This could be the >>> explanation but I'm not really sure as it worked well several hours. >>> >>> The last one was today when using the console. >>> >>> >> Try console -D 9 -f console.log if you can reproduce the >> > > Ok, I'll try that next time. > > >>> Problem is we have no logs. Server suddenly freezes and is no more >>> available via ssh , vnc or xen console. >>> >>> >> So the entire VM freezes, not just the directory server? >> So you see the server crashing and the VM freezing? >> > > Yes, sort of. I still had control of the cursor but could not ctrl+c > the console on the xterm > > > >>> Would somebody have an idea about which steps to debug this situation ? >>> >>> >> Anything in the error log? /var/log/messages ? any other log files in >> /var/log? >> > > Only in /var/log/xen/xend.log which indicates that this is quite offtopic. > > I'll see what I can find on the xen side, > > Thanks, > > Mikael > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From trey at metaweb.com Fri Oct 2 21:57:59 2009 From: trey at metaweb.com (Trey Sheldon) Date: Fri, 2 Oct 2009 14:57:59 -0700 Subject: [389-users] 389 certificate issues... Message-ID: Hello all, I've been evaluating and prepping to deploy 389 for a couple months now and while working on my final deployment I've run into a snag... I created two servers and successfully enabled SSL on them. I'm attempting to create a third using the exact same procedure and can't seem to get SSL enabled. I used the admin-gui to install the request / install the certs and roots. ##WORKING #certutil -L -d . Certificate Nickname Trust Attributes SSL,S/ MIME,JAR/XPI Metaweb Root Certificate CT,, Metaweb Host Root Certificate CT,, server-cert u,u,u # certutil -L -d . -n server-cert Certificate: Data: Version: 3 (0x2) Serial Number: 88 (0x58) Signature Algorithm: PKCS #1 MD5 With RSA Encryption Issuer: ........ ## NOT WORKING # certutil -L -d . Certificate Nickname Trust Attributes SSL,S/ MIME,JAR/XPI Metaweb Root Certificate CT,, Metaweb Host Root Certificate CT,, server-cert u,u,u # certutil -L -d . -n server-cert certutil: Could not find: server-cert : security library: bad database. These systems are automatically deployed and configured and should have identical package revisions and configurations. I'm at a blank to what is causing the problem. Any insight that people have would be *greatly* appreciated. Sincerely, Trey SHeldon From msauton at redhat.com Sat Oct 3 00:30:37 2009 From: msauton at redhat.com (Marc Sauton) Date: Fri, 02 Oct 2009 17:30:37 -0700 Subject: [389-users] 389 certificate issues... In-Reply-To: References: Message-ID: <4AC69B2D.50009@redhat.com> Trey Sheldon wrote: > Hello all, > > I've been evaluating and prepping to deploy 389 for a couple months > now and while working on my final deployment I've run into a snag... > > I created two servers and successfully enabled SSL on them. I'm > attempting to create a third using the exact same procedure and can't > seem to get SSL enabled. > > I used the admin-gui to install the request / install the certs and > roots. > > ##WORKING > #certutil -L -d . > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > Metaweb Root Certificate CT,, > Metaweb Host Root Certificate CT,, > server-cert u,u,u > > # certutil -L -d . -n server-cert > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 88 (0x58) > Signature Algorithm: PKCS #1 MD5 With RSA Encryption > Issuer: ........ > > ## NOT WORKING > # certutil -L -d . > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > Metaweb Root Certificate CT,, > Metaweb Host Root Certificate CT,, > server-cert u,u,u > > # certutil -L -d . -n server-cert > certutil: Could not find: server-cert > : security library: bad database. > It means the nick-name provided to certutil does not exist in the NSS db. Aside cert8.db, key3.db, secmod.db files and directory permissions, reading the 2 root certificates from this specific NSS db directory for sanity check, is it possible the string "server-cert" that you expect for the nickname was stored with some extra spaces appended to it?... Is the cert visible in the console? Any specific errors in the console when you try to install the cert or enable SSL? > > These systems are automatically deployed and configured and should > have identical package revisions and configurations. I'm at a blank > to what is causing the problem. Any insight that people have would > be *greatly* appreciated. > > Sincerely, > Trey SHeldon > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users From ckannan at redhat.com Sat Oct 3 01:09:40 2009 From: ckannan at redhat.com (Chandrasekar Kannan) Date: Fri, 02 Oct 2009 18:09:40 -0700 Subject: [389-users] 389 certificate issues... In-Reply-To: <4AC69B2D.50009@redhat.com> References: <4AC69B2D.50009@redhat.com> Message-ID: <4AC6A454.4020505@redhat.com> On 10/02/2009 05:30 PM, Marc Sauton wrote: > Trey Sheldon wrote: >> Hello all, >> >> I've been evaluating and prepping to deploy 389 for a couple months >> now and while working on my final deployment I've run into a snag... >> >> I created two servers and successfully enabled SSL on them. I'm >> attempting to create a third using the exact same procedure and can't >> seem to get SSL enabled. >> >> I used the admin-gui to install the request / install the certs and >> roots. >> >> ##WORKING >> #certutil -L -d . >> Certificate Nickname Trust >> Attributes >> >> SSL,S/MIME,JAR/XPI >> Metaweb Root Certificate CT,, >> Metaweb Host Root Certificate CT,, >> server-cert u,u,u >> >> # certutil -L -d . -n server-cert >> Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: 88 (0x58) >> Signature Algorithm: PKCS #1 MD5 With RSA Encryption >> Issuer: ........ >> >> ## NOT WORKING >> # certutil -L -d . >> Certificate Nickname Trust >> Attributes >> >> SSL,S/MIME,JAR/XPI >> Metaweb Root Certificate CT,, >> Metaweb Host Root Certificate CT,, >> server-cert u,u,u >> >> # certutil -L -d . -n server-cert >> certutil: Could not find: server-cert >> : security library: bad database. >> > It means the nick-name provided to certutil does not exist in the NSS db. certutil -X -d . (might help as it tries to open the db in write mode)... > Aside cert8.db, key3.db, secmod.db files and directory permissions, > reading the 2 root certificates from this specific NSS db directory > for sanity check, is it possible the string "server-cert" that you > expect for the nickname was stored with some extra spaces appended to > it?... > Is the cert visible in the console? > Any specific errors in the console when you try to install the cert or > enable SSL? >> >> These systems are automatically deployed and configured and should >> have identical package revisions and configurations. I'm at a blank >> to what is causing the problem. Any insight that people have would >> be *greatly* appreciated. >> >> Sincerely, >> Trey SHeldon >> >> -- >> 389 users mailing list >> 389-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users From james_roman at ssaihq.com Mon Oct 5 03:44:57 2009 From: james_roman at ssaihq.com (James Roman) Date: Sun, 04 Oct 2009 23:44:57 -0400 Subject: [389-users] Upgrading OS from FC9 to FC10 Message-ID: I am attempting to upgrade my FreeIPA server from Fedora 9 (Fedora-ds-base 1.2.0-4) to Fedora 10 (389-ds-base 1.2.2-1). I have been running into problems with the directory server during the upgrade. Prior to the upgrade process I am stopping the directory server and using chkconfig to ensure that it does not start after the upgrade. The oS upgrade goes seemingly without a hitch. At first boot, the FC9 directory server packages are still installed. I perform a "yum update" which indicates that the fedora-ds-package will be replaced with the 389 package (Not sure if this means upgrade or not, but the fedora-ds-base package is definitely removed). When I try to manually start the directory server I receive the following errors: [04/Oct/2009:19:40:35 -0400] - All database threads now stopped [04/Oct/2009:19:41:37 -0400] - slapd shutting down - signaling operation threads [04/Oct/2009:19:41:37 -0400] - slapd shutting down - closing down internal subsystems and plugins [04/Oct/2009:19:41:38 -0400] - Waiting for 4 database threads to stop [04/Oct/2009:19:41:38 -0400] - All database threads now stopped [04/Oct/2009:19:41:38 -0400] - slapd stopped. 389-Directory/1.2.2 B2009.237.206 directory.REALM.com:636 (/etc/dirsrv/slapd-REALM-COM) [05/Oct/2009:01:46:34 -0400] - 389-Directory/1.2.2 B2009.237.206 starting up [05/Oct/2009:01:46:34 -0400] - Clean up db environment and start from archive. [05/Oct/2009:01:46:34 -0400] - libdb: Program version 4.7 doesn't match environment version 4.6 [05/Oct/2009:01:46:34 -0400] - libdb: Program version 4.7 doesn't match environment version 4.6 [05/Oct/2009:01:46:36 -0400] - attrcrypt_unwrap_key: failed to unwrap key for cipher AES [05/Oct/2009:01:46:37 -0400] - Failed to retrieve key for cipher AES in attrcrypt_cipher_init [05/Oct/2009:01:46:37 -0400] - Failed to initialize cipher AES in attrcrypt_init [05/Oct/2009:01:46:37 -0400] - attrcrypt_unwrap_key: failed to unwrap key for cipher 3DES [05/Oct/2009:01:46:37 -0400] - Failed to retrieve key for cipher 3DES in attrcrypt_cipher_init [05/Oct/2009:01:46:37 -0400] - Failed to initialize cipher 3DES in attrcrypt_init [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - Upgrading from bdb/4 to bdb/4.7/libreplication-plugin is successfully done (/var/lib/dirsrv/slapd-REALM-COM/cldb) [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - cl5Open: failed to open changelog [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - changelog5_init: failed to start changelog at /var/lib/dirsrv/slapd-REALM-COM/cldb [05/Oct/2009:01:46:37 -0400] - Failed to start object plugin Multimaster Replication Plugin [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - cl5Open: failed to open changelog [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - changelog5_init: failed to start changelog at /var/lib/dirsrv/slapd-REALM-COM/cldb [05/Oct/2009:01:46:37 -0400] - Failed to start object plugin Multimaster Replication Plugin [05/Oct/2009:01:46:37 -0400] - Error: Failed to resolve plugin dependencies [05/Oct/2009:01:46:37 -0400] - Error: object plugin Legacy Replication Plugin is not started [05/Oct/2009:01:46:37 -0400] - Error: object plugin Multimaster Replication Plugin is not started 389-Directory/1.2.2 B2009.237.206 directory.REALM.com:636 (/etc/dirsrv/slapd-REALM-COM) [05/Oct/2009:01:58:17 -0400] - 389-Directory/1.2.2 B2009.237.206 starting up [05/Oct/2009:01:58:17 -0400] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [05/Oct/2009:01:58:18 -0400] - attrcrypt_unwrap_key: failed to unwrap key for cipher AES [05/Oct/2009:01:58:18 -0400] - Failed to retrieve key for cipher AES in attrcrypt_cipher_init [05/Oct/2009:01:58:18 -0400] - Failed to initialize cipher AES in attrcrypt_init [05/Oct/2009:01:58:18 -0400] - attrcrypt_unwrap_key: failed to unwrap key for cipher 3DES [05/Oct/2009:01:58:18 -0400] - Failed to retrieve key for cipher 3DES in attrcrypt_cipher_init [05/Oct/2009:01:58:18 -0400] - Failed to initialize cipher 3DES in attrcrypt_init [05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument [05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program - cl5Open: failed to open changelog [05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program - changelog5_init: failed to start changelog at /var/lib/dirsrv/slapd-REALM-COM/cldb [05/Oct/2009:01:58:19 -0400] - Failed to start object plugin Multimaster Replication Plugin [05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument [05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program - cl5Open: failed to open changelog [05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program - changelog5_init: failed to start changelog at /var/lib/dirsrv/slapd-REALM-COM/cldb [05/Oct/2009:01:58:19 -0400] - Failed to start object plugin Multimaster Replication Plugin [05/Oct/2009:01:58:19 -0400] - Error: Failed to resolve plugin dependencies [05/Oct/2009:01:58:19 -0400] - Error: object plugin Legacy Replication Plugin is not started [05/Oct/2009:01:58:19 -0400] - Error: object plugin Multimaster Replication Plugin is not started Fedora-Directory/1.2.0 B2009.118.167 directory.REALM.com:636 (/etc/dirsrv/slapd-REALM-COM) [05/Oct/2009:02:49:56 -0400] - Fedora-Directory/1.2.0 B2009.118.167 starting up [05/Oct/2009:02:49:56 -0400] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [05/Oct/2009:02:49:57 -0400] - attrcrypt_unwrap_key: failed to unwrap key for cipher AES [05/Oct/2009:02:49:57 -0400] - Failed to retrieve key for cipher AES in attrcrypt_cipher_init [05/Oct/2009:02:49:57 -0400] - Failed to initialize cipher AES in attrcrypt_init [05/Oct/2009:02:49:57 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument [05/Oct/2009:02:49:57 -0400] NSMMReplicationPlugin - changelog program - cl5Open: failed to open changelog [05/Oct/2009:02:49:57 -0400] NSMMReplicationPlugin - changelog program - changelog5_init: failed to start changelog at /var/lib/dirsrv/slapd-REALM-COM/cldb [05/Oct/2009:02:49:57 -0400] - Failed to start object plugin Multimaster Replication Plugin [05/Oct/2009:02:49:58 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument [05/Oct/2009:02:49:58 -0400] NSMMReplicationPlugin - changelog program - cl5Open: failed to open changelog [05/Oct/2009:02:49:58 -0400] NSMMReplicationPlugin - changelog program - changelog5_init: failed to start changelog at /var/lib/dirsrv/slapd-REALM-COM/cldb [05/Oct/2009:02:49:58 -0400] - Failed to start object plugin Multimaster Replication Plugin [05/Oct/2009:02:49:58 -0400] - Error: Failed to resolve plugin dependencies [05/Oct/2009:02:49:58 -0400] - Error: object plugin Legacy Replication Plugin is not started [05/Oct/2009:02:49:58 -0400] - Error: object plugin Multimaster Replication Plugin is not started I have two replica servers installed, one a FC10 DS 1.2.2 and one a windows domain controller. I have backed up basically everything in multiple formats (db2bak, ldif, tar). I am going to have to roll the server back to FC9 for the evening. Anyone have any ideas how to eliminate the errors, or perform the upgrade in a way that avoids them? Do I need to remove the replication agreements first? James Roman Sr. Network Administrator TerraNet, Inc. on Contract to SSAI From emmanuel.billot at ird.fr Mon Oct 5 11:50:13 2009 From: emmanuel.billot at ird.fr (Emmanuel BILLOT) Date: Mon, 05 Oct 2009 13:50:13 +0200 Subject: [389-users] Re: Windows Sync In-Reply-To: <4AC6506A.5020705@ird.fr> References: <4AC6506A.5020705@ird.fr> Message-ID: <4AC9DD75.9070801@ird.fr> Emmanuel BILLOT a ?crit : > Hi, > Windows Sync does not work. > We use administrtor account to bind. Ok i found what was wrong. First do not forget to give AD replication user replication rights. There was an error when creating replication. AD names OU objetcs with a CN= whereas real LDAP uses OU= BR, > > Extract from log : > > 02/Oct/2009:17:11:22 +0200] - _csngen_adjust_local_time: gen state > before 4ac618150001:1254496277:0:0 > [02/Oct/2009:17:11:22 +0200] - _csngen_adjust_local_time: gen state > after 4ac6181a0000:1254496282:0:0 > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - > ruv_add_csn_inprogress: successfully inserted csn 4ac6181a000000010000 > into pending list > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - > csn=4ac6181a000000010000 process postop: canceling operation csn > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - add operation of > entry uid=zizou,ou=People,ou=orleans,dc=ird,dc=fr returned: 32 > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry > from dirsync: CN=Duplicateurs,CN=Builtin,DC=maqird,DC=fr > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry > from dirsync: CN=Administrateurs de l'entreprise,CN=Users,DC=maqird,DC=fr > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry > from dirsync: CN=jean bon,OU=utilisateurs,OU=ORLEANS,DC=maqird,DC=fr > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): map_entry_dn_inbound: looking for local entry > matching AD entry [CN=jean > bon,OU=utilisateurs,OU=ORLEANS,DC=maqird,DC=fr] > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): map_entry_dn_inbound: looking for local entry by > guid [6615b9abafd05c4da997ca3c89b7ab1b] > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): map_entry_dn_inbound: problem looking for guid: -1 > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): map_entry_dn_inbound: looking for local entry by > uid [bon] > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): map_entry_dn_inbound: problem looking for > username: -1 > [02/Oct/2009:17:11:22 +0200] - Windows sync entry: Adding new local > entry dn: uid=bon,ou=People,ou=orleans,dc=ird,dc=fr > objectClass: top > objectClass: person > objectClass: organizationalperson > objectClass: inetOrgPerson > objectClass: ntUser > ntUserDeleteAccount: true > uid: bon > sn: bon > givenName: jean > cn: jean bon > ntUserCodePage: 0 > ntUserAcctExpires: 9223372036854775807 > ntUserDomainId: bon > ntUniqueId: 6615b9abafd05c4da997ca3c89b7ab1b > > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - > ruv_add_csn_inprogress: successfully inserted csn 4ac6181a000100010000 > into pending list > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - > csn=4ac6181a000100010000 process postop: canceling operation csn > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - add operation of > entry uid=bon,ou=People,ou=orleans,dc=ird,dc=fr returned: 32 > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry > from dirsync: OU=utilisateurs,OU=ORLEANS,DC=maqird,DC=fr > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): map_entry_dn_inbound: looking for local entry > matching AD entry [OU=utilisateurs,OU=ORLEANS,DC=maqird,DC=fr] > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): map_entry_dn_inbound: looking for local entry by > guid [6bb1176df971904f9e2ea760d58ac3b3] > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): map_entry_dn_inbound: problem looking for guid: -1 > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): map_entry_dn_inbound: AD entry has no username! > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): windows_process_dirsync_entry: failed to map > inbound entry OU=utilisateurs,OU=ORLEANS,DC=maqird,DC=fr - rc is -1 dn > is [null]. > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry > from dirsync: CN=Administrateurs du sch??ma,CN=Users,DC=maqird,DC=fr > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry > from dirsync: CN=Admins du domaine,CN=Users,DC=maqird,DC=fr > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - received entry > from dirsync: OU=ORLEANS,DC=maqird,DC=fr > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): Beginning linger on the connection > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): windows_tot_run: failed to obtain data to send to > the consumer; LDAP error - 32 > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): No linger to cancel on the connection > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): Disconnected from the consumer > [02/Oct/2009:17:11:22 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): State: start -> ready_to_acquire_replica > [02/Oct/2009:17:11:22 +0200] - acquire_replica, supplier RUV: > [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - supplier: > {replicageneration} 4a1e8d0b000000010000 > [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - supplier: > {replica 1 ldap://obiwan:389} 4a1e9575000000010000 > 4ac616f7000100010000 4ac616f8 > [02/Oct/2009:17:11:23 +0200] - acquire_replica, consumer RUV: > [02/Oct/2009:17:11:23 +0200] - acquire_replica, consumer RUV = null > [02/Oct/2009:17:11:23 +0200] - acquire_replica, supplier RUV is newer > [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): Trying secure slapi_ldap_init_ext > [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): binddn = > cn=administrateur,cn=Users,dc=maqird,dc=fr, passwd = > {DES}NfWmOGRvsgfwJqTMBJagtA== > [02/Oct/2009:17:11:23 +0200] - windows_conn_connect : detected Win2k3 > peer > [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): No linger to cancel on the connection > [02/Oct/2009:17:11:23 +0200] - _csngen_adjust_local_time: gen state > before 4ac6181a0002:1254496282:0:0 > [02/Oct/2009:17:11:23 +0200] - _csngen_adjust_local_time: gen state > after 4ac6181b0000:1254496283:0:0 > [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - > windows_acquire_replica returned success (101) > [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): State: ready_to_acquire_replica -> sending_updates > [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): Replica has no update vector. It has never been > initialized. > [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): Beginning linger on the connection > [02/Oct/2009:17:11:23 +0200] NSMMReplicationPlugin - agmt="cn=x" > (maqsvrdc0001:636): Linger timeout has expired on the connection > > -- ========================================== Emmanuel BILLOT IRD - Orl?ans D?l?gation aux Syst?mes d'Information (DSI) t?l : 02 38 49 95 88 ========================================== From emmanuel.billot at ird.fr Mon Oct 5 11:54:28 2009 From: emmanuel.billot at ird.fr (Emmanuel BILLOT) Date: Mon, 05 Oct 2009 13:54:28 +0200 Subject: [389-users] Result of replication Message-ID: <4AC9DE74.2070504@ird.fr> Hi, We monitor replication between 389DS servers and AD servers. What does this filed real mean ? What does those numbers mean ? Number of changes : 1:130/0 BR, -- ========================================== Emmanuel BILLOT IRD - Orl?ans D?l?gation aux Syst?mes d'Information (DSI) t?l : 02 38 49 95 88 ========================================== From mikael.kermorgant at gmail.com Mon Oct 5 15:49:26 2009 From: mikael.kermorgant at gmail.com (Mikael Kermorgant) Date: Mon, 5 Oct 2009 17:49:26 +0200 Subject: [389-users] server crash (389 server 1.2.1 on FC10 domu / centos 5.3 dom0) In-Reply-To: <4AC6654C.9030501@redhat.com> References: <9711147e0910020644p2b0fdfcey68ce337c9eeec894@mail.gmail.com> <4AC61B31.5060007@redhat.com> <9711147e0910020846m4387337et1ec5e9ef05d5d942@mail.gmail.com> <4AC6654C.9030501@redhat.com> Message-ID: <9711147e0910050849j211fcec7h41f73cda0d96a544@mail.gmail.com> Hello, On Fri, Oct 2, 2009 at 10:40 PM, Rich Megginson wrote: >>>> First ones were the day after a schema modification on the master >>>> which had not been weel propagated on the slaves. >>>> >>> >>> How did you modify the schema on the master? >>> >> >> Via the console, by adding an attribute. >> Had to copy the schema files to the slaves later. >> > > Were there any messages in the errors logs on the supplier or consumers > about not being able to replicate the schema? Yep, there were some : [23/Sep/2009:10:59:58 +0200] NSMMReplicationPlugin - agmtlist_add_callback: Can't start agreement "cn=supann0& - bsupann01,cn=replica,cn="dc=dede, dc=deded, dc=fr",cn=mapping tree,cn=config" And many of these : [23/Sep/2009:14:37:13 +0200] NSMMReplicationPlugin - agmt="cn=bsupann01" (192:389): Replica has a different generation ID than the local data. [23/Sep/2009:14:37:17 +0200] NSMMReplicationPlugin - agmt="cn=bsupann01" (192:389): Replica has a different generation ID than the local data. However, I now really want to migrate to some safer virtualisation environment. Maybe a bit over pessimistic but I'm affraid of the FC11 domU on centos dom0... Regards, Mikael From mikael.kermorgant at gmail.com Mon Oct 5 16:03:55 2009 From: mikael.kermorgant at gmail.com (Mikael Kermorgant) Date: Mon, 5 Oct 2009 18:03:55 +0200 Subject: [389-users] which platform to choose Message-ID: <9711147e0910050903g4453d27cre892fdab5b637202@mail.gmail.com> Hello, After having used 389 directory server 1.2.1 in a virtualized environment based on a fedora core 11 xen domU over a centos 5.3 dom0, and faced some rare and random crashes, I'd like to change our setup. Our main distributions which we'd like to use are debian lenny, centos, and we're seriously testing xenserver 5.5 which supports both. I've read in the past that it was recommended to use FC6 binaries when using centos 5, but I can't find the page anymore. Moreover, I've found some howtos with different setups : * http://wiki.centos.org/HowTos/DirectoryServerSetup?action=show&redirect=HowTos%2FDirectoryServerSetup. * http://www.linuxmail.info/389-directory-server-setup-howto-centos-5/ * http://www.howtoforge.com/centos-directory-server-on-centos5.2 >From what I've read, I prefer the first one as it comes from centos' own wiki. Any opinion against that ? Do you know if there are issues with replication with fedora ds on other fedora boxes ? Regards, -- Mikael Kermorgant From rmeggins at redhat.com Mon Oct 5 16:10:35 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 05 Oct 2009 10:10:35 -0600 Subject: [389-users] which platform to choose In-Reply-To: <9711147e0910050903g4453d27cre892fdab5b637202@mail.gmail.com> References: <9711147e0910050903g4453d27cre892fdab5b637202@mail.gmail.com> Message-ID: <4ACA1A7B.5090509@redhat.com> Mikael Kermorgant wrote: > Hello, > > After having used 389 directory server 1.2.1 in a virtualized > environment based on a fedora core 11 xen domU over a centos 5.3 dom0, > and faced some rare and random crashes, I'd like to change our setup. > > Our main distributions which we'd like to use are debian lenny, > centos, and we're seriously testing xenserver 5.5 which supports both. > > I've read in the past that it was recommended to use FC6 binaries when > using centos 5, but I can't find the page anymore. http://directory.fedoraproject.org/wiki/Download > Moreover, I've > found some howtos with different setups : > > * http://wiki.centos.org/HowTos/DirectoryServerSetup?action=show&redirect=HowTos%2FDirectoryServerSetup. > > * http://www.linuxmail.info/389-directory-server-setup-howto-centos-5/ > > * http://www.howtoforge.com/centos-directory-server-on-centos5.2 > > >From what I've read, I prefer the first one as it comes from centos' > own wiki. Any opinion against that ? > You could just use centos-ds. > Do you know if there are issues with replication with fedora ds on > other fedora boxes ? > Replication works fine between and among different fedora ds/centos ds/389 ds versions and platforms. > Regards, > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Oct 5 16:14:00 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 05 Oct 2009 10:14:00 -0600 Subject: [389-users] server crash (389 server 1.2.1 on FC10 domu / centos 5.3 dom0) In-Reply-To: <9711147e0910050849j211fcec7h41f73cda0d96a544@mail.gmail.com> References: <9711147e0910020644p2b0fdfcey68ce337c9eeec894@mail.gmail.com> <4AC61B31.5060007@redhat.com> <9711147e0910020846m4387337et1ec5e9ef05d5d942@mail.gmail.com> <4AC6654C.9030501@redhat.com> <9711147e0910050849j211fcec7h41f73cda0d96a544@mail.gmail.com> Message-ID: <4ACA1B48.7010400@redhat.com> Mikael Kermorgant wrote: > Hello, > > On Fri, Oct 2, 2009 at 10:40 PM, Rich Megginson wrote: > > >>>>> First ones were the day after a schema modification on the master >>>>> which had not been weel propagated on the slaves. >>>>> >>>>> >>>> How did you modify the schema on the master? >>>> >>>> >>> Via the console, by adding an attribute. >>> Had to copy the schema files to the slaves later. >>> >>> >> Were there any messages in the errors logs on the supplier or consumers >> about not being able to replicate the schema? >> > > Yep, there were some : > > [23/Sep/2009:10:59:58 +0200] NSMMReplicationPlugin - > agmtlist_add_callback: Can't start agreement "cn=supann0& - > bsupann01,cn=replica,cn="dc=dede, dc=deded, dc=fr",cn=mapping > tree,cn=config" > That's really odd. Do you get that at startup? That indicates some sort of configuration problem. You could try starting the server with /usr/lib/dirsrv/slapd-instance/start-slapd -d 8192 to see if there is more detailed information. > And many of these : > > [23/Sep/2009:14:37:13 +0200] NSMMReplicationPlugin - > agmt="cn=bsupann01" (192:389): Replica has a different generation ID > than the local data. > [23/Sep/2009:14:37:17 +0200] NSMMReplicationPlugin - > agmt="cn=bsupann01" (192:389): Replica has a different generation ID > than the local data. > This usually means the consumer has not been initialized. > > However, I now really want to migrate to some safer virtualisation > environment. Maybe a bit over pessimistic but I'm affraid of the FC11 > domU on centos dom0... > > > Regards, > > Mikael > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From patrick.morris at hp.com Tue Oct 6 00:36:14 2009 From: patrick.morris at hp.com (Morris, Patrick) Date: Mon, 5 Oct 2009 17:36:14 -0700 Subject: [389-users] Deleting entries that are not modified recently In-Reply-To: References: Message-ID: <20091006003614.GX8569@bakgwai.americas.hpqcorp.net> Each entry has a modifytimestamp attribute you can search on. On Fri, 25 Sep 2009, Kimmo Koivisto wrote: > Hello > > I'm using fedora-ds-1.0.4-1.RHEL4 and I have an application that > creates and modifies entries located in FDS. > Application does not remote old entries, and I cannot change how > application works. > > I would like to delete entries that are not modified recently with > either plain ldapsearch+ldapdelete or using some FDS tools, perl scipt > etc. > > So, my question is, what is the easiest way to delete entries, for > example older that 3 months? > > Regards, > Kimmo > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users From patrick.morris at hp.com Tue Oct 6 00:43:48 2009 From: patrick.morris at hp.com (Morris, Patrick) Date: Mon, 5 Oct 2009 17:43:48 -0700 Subject: [389-users] Deleting entries that are not modified recently In-Reply-To: <4ABCFE7A.9040804@redhat.com> References: <52a9d2e30909242336r60babc7al7748c161dcb80ca5@mail.gmail.com> <4ABCFE7A.9040804@redhat.com> Message-ID: <20091006004348.GY8569@bakgwai.americas.hpqcorp.net> On Fri, 25 Sep 2009, Rich Megginson wrote: > Kimmo Koivisto wrote: > > Hello > > > > This was what I needed to search entries: > > > > ldapsearch -x -b xx -D xxx -w xxx > > "(&(cn=*)(modifytimestamp<=2009092513000000Z)(objectclass=person))" > > > > But then, how to pipe ldapsearch and ldapdelete to delete the result > > dn's of ldapsearch? > > > specify "dn" as the attribute to return - just add it to the end of the > command line - also add -LLL to the ldapsearch command line to make it > less verbose > you will then have output like > dn: somedn > blank line > repeat..... > > You will have to use sed/awk/perl to strip the "dn: " from the DNs, and > ignore the blank lines > > Regards, > > Kimmo > > > > 2009/9/25 Kimmo Koivisto : > > > >> Hello > >> > >> Thanks for your answer. > >> > >> I know about those timestamps, but I don't know if I can compare > >> timestamps with ldapsearch. > >> > >> So, is it possible to compare or search entries older that defined > >> timestamp, for example: > >> > >> ldapsearch "(objectClass=*)" * modifyTimestamp>20090801000000Z > >> > >> or how I could do this? > >> > >> Regards, > >> Kimmo > >> > >> > >> 2009/9/25 Juan Asensio S?nchez : > >> > >>> Hi > >>> > >>> All entries in the directory have some operational attributes called > >>> createTimestamp, modifiTimestamp, creatorsName and modifiersName. With > >>> them, you can check when an entry has been created or modified, and > >>> who did it. I think this is what you are looking for. > >>> > >>> Those attributes, thar are operational, are not returned when you ask > >>> for all attributes, you must specify their names manually: > >>> > >>> ldapsearch ...... "(objectClass=*)" * createTimestamp > >>> > >>> Regards > >>> > >>> 2009/9/25 Kimmo Koivisto : > >>> > >>>> Hello > >>>> > >>>> I'm using fedora-ds-1.0.4-1.RHEL4 and I have an application that > >>>> creates and modifies entries located in FDS. > >>>> Application does not remote old entries, and I cannot change how > >>>> application works. > >>>> > >>>> I would like to delete entries that are not modified recently with > >>>> either plain ldapsearch+ldapdelete or using some FDS tools, perl scipt > >>>> etc. > >>>> > >>>> So, my question is, what is the easiest way to delete entries, for > >>>> example older that 3 months? If I may make a suggestion (and apologies for the last mail being way behind -- mail's running behind for me today)... Before doing anything like this, I'd recommend doing a little reading up on ldapsearch, ldapmodiify, ldapdelete and the like, and getting a really firm grip on how they work and how to use them. What you're trying to do is potentially very dangerous if you don't have a really good understanding of what you're doing, and very likely to wipe a lot of data out of your LDAP directory that you don't want wiped out. I'm not trying to sound disrespectful here, but it sounds like you don't yet have a firm grip on how the basic LDAP tools work yet, and if I were in your position I'd steer far clear of a mass-delete script until I was sure I knew what I was doing. From gmiller at conley-inc.com Tue Oct 6 19:20:03 2009 From: gmiller at conley-inc.com (Greg Miller) Date: Tue, 06 Oct 2009 14:20:03 -0500 Subject: [389-users] GOsa on 389 Directory Server Message-ID: <4ACB9863.8040301@conley-inc.com> This is my first foray into LDAP, so please be gentle... I am attempting to install GOsa over the top of a fresh 389 install on CentOS 5.3. It seems that GOsa provides a simple way to administer virtually every aspect of a Linux network with an LDAP server. Maybe 389's own tools can do this, too, and I just don't know it. Anyway, I have copied the GOsa schema files into the 389 Directory Server's schema directory. I renamed all of the GOsa schema files to begin with "90", so that 389 would load them. When I restart 389, I receive numerous error messages in the log: [02/Oct/2009:06:00:26 -0500] - Entry "cn=gofax,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] - Entry "cn=gofon,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] - Entry "cn=gosa-samba2,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] - Entry "cn=gosa-samba3,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] - Entry "cn=goserver,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] - Entry "cn=gosystem,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] - Entry "cn=goto-mime,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] - Entry "cn=goto,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] - Entry "cn=rfc2307bis,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] - Entry "cn=samba,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] - Entry "cn=samba3,cn=schema,cn=config" has unknown object class "olcSchemaConfig" [02/Oct/2009:06:00:26 -0500] - Entry "cn=trust,cn=schema,cn=config" has unknown object class "olcSchemaConfig" From the little info I can find on the Internet, olcSchemaConfig seems to be an OpenLDAP-specific setting. I can't seem to find a comparable setting for 389 Directory Server in any of 389's schema files. I have posted this question to GOsa's forums, but nobody there uses 389. Does anyone have any advice for me on this matter? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.roman at ssaihq.com Tue Oct 6 20:32:05 2009 From: james.roman at ssaihq.com (James Roman) Date: Tue, 06 Oct 2009 16:32:05 -0400 Subject: [389-users] Upgrading OS from FC9 to FC10 Message-ID: <4ACBA945.40704@ssaihq.com> Trying again? I am attempting to upgrade my server from Fedora 9 (Fedora-ds-base 1.2.0-4) to Fedora 10 (389-ds-base 1.2.2-1). I have been running into problems with the directory server during the OS upgrade. Prior to the upgrade process I am stopping the directory server and using chkconfig to ensure that it does not start after the upgrade. The oS upgrade goes seemingly without a hitch. At first boot, the FC9 directory server packages are still installed. I perform a "yum update" which indicates that the fedora-ds-package will be replaced with the 389 package (Not sure if this means upgrade or not, but the fedora-ds-base package is definitely removed). When I try to manually start the directory server I receive the following errors: [04/Oct/2009:19:40:35 -0400] - All database threads now stopped [04/Oct/2009:19:41:37 -0400] - slapd shutting down - signaling operation threads [04/Oct/2009:19:41:37 -0400] - slapd shutting down - closing down internal subsystems and plugins [04/Oct/2009:19:41:38 -0400] - Waiting for 4 database threads to stop [04/Oct/2009:19:41:38 -0400] - All database threads now stopped [04/Oct/2009:19:41:38 -0400] - slapd stopped. 389-Directory/1.2.2 B2009.237.206 directory.REALM.com:636 (/etc/dirsrv/slapd-REALM-COM) [05/Oct/2009:01:46:34 -0400] - 389-Directory/1.2.2 B2009.237.206 starting up [05/Oct/2009:01:46:34 -0400] - Clean up db environment and start from archive. [05/Oct/2009:01:46:34 -0400] - libdb: Program version 4.7 doesn't match environment version 4.6 [05/Oct/2009:01:46:34 -0400] - libdb: Program version 4.7 doesn't match environment version 4.6 [05/Oct/2009:01:46:36 -0400] - attrcrypt_unwrap_key: failed to unwrap key for cipher AES [05/Oct/2009:01:46:37 -0400] - Failed to retrieve key for cipher AES in attrcrypt_cipher_init [05/Oct/2009:01:46:37 -0400] - Failed to initialize cipher AES in attrcrypt_init [05/Oct/2009:01:46:37 -0400] - attrcrypt_unwrap_key: failed to unwrap key for cipher 3DES [05/Oct/2009:01:46:37 -0400] - Failed to retrieve key for cipher 3DES in attrcrypt_cipher_init [05/Oct/2009:01:46:37 -0400] - Failed to initialize cipher 3DES in attrcrypt_init [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - Upgrading from bdb/4 to bdb/4.7/libreplication-plugin is successfully done (/var/lib/dirsrv/slapd-REALM-COM/cldb) [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - cl5Open: failed to open changelog [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - changelog5_init: failed to start changelog at /var/lib/dirsrv/slapd-REALM-COM/cldb [05/Oct/2009:01:46:37 -0400] - Failed to start object plugin Multimaster Replication Plugin [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - cl5Open: failed to open changelog [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - changelog5_init: failed to start changelog at /var/lib/dirsrv/slapd-REALM-COM/cldb [05/Oct/2009:01:46:37 -0400] - Failed to start object plugin Multimaster Replication Plugin [05/Oct/2009:01:46:37 -0400] - Error: Failed to resolve plugin dependencies [05/Oct/2009:01:46:37 -0400] - Error: object plugin Legacy Replication Plugin is not started [05/Oct/2009:01:46:37 -0400] - Error: object plugin Multimaster Replication Plugin is not started 389-Directory/1.2.2 B2009.237.206 directory.REALM.com:636 (/etc/dirsrv/slapd-REALM-COM) [05/Oct/2009:01:58:17 -0400] - 389-Directory/1.2.2 B2009.237.206 starting up [05/Oct/2009:01:58:17 -0400] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [05/Oct/2009:01:58:18 -0400] - attrcrypt_unwrap_key: failed to unwrap key for cipher AES [05/Oct/2009:01:58:18 -0400] - Failed to retrieve key for cipher AES in attrcrypt_cipher_init [05/Oct/2009:01:58:18 -0400] - Failed to initialize cipher AES in attrcrypt_init [05/Oct/2009:01:58:18 -0400] - attrcrypt_unwrap_key: failed to unwrap key for cipher 3DES [05/Oct/2009:01:58:18 -0400] - Failed to retrieve key for cipher 3DES in attrcrypt_cipher_init [05/Oct/2009:01:58:18 -0400] - Failed to initialize cipher 3DES in attrcrypt_init [05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument [05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program - cl5Open: failed to open changelog [05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program - changelog5_init: failed to start changelog at /var/lib/dirsrv/slapd-REALM-COM/cldb [05/Oct/2009:01:58:19 -0400] - Failed to start object plugin Multimaster Replication Plugin [05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument [05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program - cl5Open: failed to open changelog [05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program - changelog5_init: failed to start changelog at /var/lib/dirsrv/slapd-REALM-COM/cldb [05/Oct/2009:01:58:19 -0400] - Failed to start object plugin Multimaster Replication Plugin [05/Oct/2009:01:58:19 -0400] - Error: Failed to resolve plugin dependencies [05/Oct/2009:01:58:19 -0400] - Error: object plugin Legacy Replication Plugin is not started [05/Oct/2009:01:58:19 -0400] - Error: object plugin Multimaster Replication Plugin is not started Fedora-Directory/1.2.0 B2009.118.167 directory.REALM.com:636 (/etc/dirsrv/slapd-REALM-COM) [05/Oct/2009:02:49:56 -0400] - Fedora-Directory/1.2.0 B2009.118.167 starting up [05/Oct/2009:02:49:56 -0400] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [05/Oct/2009:02:49:57 -0400] - attrcrypt_unwrap_key: failed to unwrap key for cipher AES [05/Oct/2009:02:49:57 -0400] - Failed to retrieve key for cipher AES in attrcrypt_cipher_init [05/Oct/2009:02:49:57 -0400] - Failed to initialize cipher AES in attrcrypt_init [05/Oct/2009:02:49:57 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument [05/Oct/2009:02:49:57 -0400] NSMMReplicationPlugin - changelog program - cl5Open: failed to open changelog [05/Oct/2009:02:49:57 -0400] NSMMReplicationPlugin - changelog program - changelog5_init: failed to start changelog at /var/lib/dirsrv/slapd-REALM-COM/cldb [05/Oct/2009:02:49:57 -0400] - Failed to start object plugin Multimaster Replication Plugin [05/Oct/2009:02:49:58 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument [05/Oct/2009:02:49:58 -0400] NSMMReplicationPlugin - changelog program - cl5Open: failed to open changelog [05/Oct/2009:02:49:58 -0400] NSMMReplicationPlugin - changelog program - changelog5_init: failed to start changelog at /var/lib/dirsrv/slapd-REALM-COM/cldb [05/Oct/2009:02:49:58 -0400] - Failed to start object plugin Multimaster Replication Plugin [05/Oct/2009:02:49:58 -0400] - Error: Failed to resolve plugin dependencies [05/Oct/2009:02:49:58 -0400] - Error: object plugin Legacy Replication Plugin is not started [05/Oct/2009:02:49:58 -0400] - Error: object plugin Multimaster Replication Plugin is not started I have two replica servers installed, one a FC10 DS 1.2.2 and one a windows domain controller. I have backed up basically everything in multiple formats (db2bak, ldif, tar). I am going to have to roll the server back to FC9 for the evening. Anyone have any ideas how to eliminate the errors, or perform the upgrade in a way that avoids them? Do I need to remove the replication agreements first? James Roman Sr. Network Administrator TerraNet, Inc. on Contract to SSAI -- 389 users mailing list 389-users at redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users From tfar at smc.co.nz Wed Oct 7 05:31:19 2009 From: tfar at smc.co.nz (Anthony M. Farrell) Date: Wed, 7 Oct 2009 18:31:19 +1300 Subject: [389-users] Problem creating new Organizational Unit Message-ID: <200910071831.19176.tfar@smc.co.nz> 389 DS 1.2.2 on RHEL 5.4 xen virtualguest This is a new installation. When using the console to try and create a new OU entry the process fails with the output message: netscape.LDAPException error result (65); unknown object class "posixuser"; Object class violation Where does "posixuser" come from? Everything else is working fine. I would appreciate any ideas on how to resolve this? TF -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From michael at stroeder.com Wed Oct 7 10:30:51 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 07 Oct 2009 12:30:51 +0200 Subject: [389-users] GOsa on 389 Directory Server In-Reply-To: <4ACB9863.8040301@conley-inc.com> References: <4ACB9863.8040301@conley-inc.com> Message-ID: <4ACC6DDB.2030600@stroeder.com> Greg Miller wrote: > I am attempting to install GOsa over the top of a fresh 389 install on > CentOS 5.3. > [..] > [02/Oct/2009:06:00:26 -0500] > > - Entry "cn=gofax,cn=schema,cn=config" has unknown object class > "olcSchemaConfig" > [..] > [02/Oct/2009:06:00:26 -0500] > > - Entry "cn=trust,cn=schema,cn=config" has unknown object class > "olcSchemaConfig" > > From the little info I can find on the Internet, olcSchemaConfig seems > to be an OpenLDAP-specific setting. It seems GOSA is trying to dynamically add its custom schema to OpenLDAP's configuration backend which has a completely different schema. I'd suggest to ask the GOSA people how to deal with 389 DS. I know that some GOSA developers maintain a customer installation running with Sun DS. So it should be possible to switch off automatic OpenLDAP-specific schema configuration and add the custom GOSA schema manually to 389 DS. Ciao, Michael. From rmeggins at redhat.com Wed Oct 7 14:18:12 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 07 Oct 2009 08:18:12 -0600 Subject: [389-users] Problem creating new Organizational Unit In-Reply-To: <200910071831.19176.tfar@smc.co.nz> References: <200910071831.19176.tfar@smc.co.nz> Message-ID: <4ACCA324.4030407@redhat.com> Anthony M. Farrell wrote: > 389 DS 1.2.2 on RHEL 5.4 xen virtualguest > > This is a new installation. When using the console to try and create a new OU > entry the process fails with the output message: > What are the exact steps you are using to create the OU entry? Are you using the Directory tab in the Directory Server window of the console? Are you using the main window Users&Groups editor? Can you reproduce the problem using 389-console -D 9 -f console.log, edit console.log to remove any sensitive information, and paste the console.log to the list? > netscape.LDAPException error result (65); unknown object class "posixuser"; > Object class violation > > Where does "posixuser" come from? > > Everything else is working fine. > > I would appreciate any ideas on how to resolve this? > > TF > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Wed Oct 7 21:31:13 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 07 Oct 2009 15:31:13 -0600 Subject: [389-users] Upgrading OS from FC9 to FC10 In-Reply-To: <4ACBA945.40704@ssaihq.com> References: <4ACBA945.40704@ssaihq.com> Message-ID: <4ACD08A1.7070800@redhat.com> James Roman wrote: > Trying again? > > I am attempting to upgrade my server from Fedora 9 (Fedora-ds-base > 1.2.0-4) to Fedora 10 (389-ds-base 1.2.2-1). I have been running into > problems with the directory server during the OS upgrade. > > Prior to the upgrade process I am stopping the directory server and > using chkconfig to ensure that it does not start after the upgrade. > The oS upgrade goes seemingly without a hitch. At first boot, the FC9 > directory server packages are still installed. I perform a "yum > update" which indicates that the fedora-ds-package will be replaced > with the 389 package (Not sure if this means upgrade or not, but the > fedora-ds-base package is definitely removed). > > When I try to manually start the directory server I receive the > following errors: > > [04/Oct/2009:19:40:35 -0400] - All database threads now stopped > [04/Oct/2009:19:41:37 -0400] - slapd shutting down - signaling > operation threads > [04/Oct/2009:19:41:37 -0400] - slapd shutting down - closing down > internal subsystems and plugins > [04/Oct/2009:19:41:38 -0400] - Waiting for 4 database threads to stop > [04/Oct/2009:19:41:38 -0400] - All database threads now stopped > [04/Oct/2009:19:41:38 -0400] - slapd stopped. > 389-Directory/1.2.2 B2009.237.206 > directory.REALM.com:636 (/etc/dirsrv/slapd-REALM-COM) > > [05/Oct/2009:01:46:34 -0400] - 389-Directory/1.2.2 B2009.237.206 > starting up > [05/Oct/2009:01:46:34 -0400] - Clean up db environment and start from > archive. > [05/Oct/2009:01:46:34 -0400] - libdb: Program version 4.7 doesn't > match environment version 4.6 > [05/Oct/2009:01:46:34 -0400] - libdb: Program version 4.7 doesn't > match environment version 4.6 > [05/Oct/2009:01:46:36 -0400] - attrcrypt_unwrap_key: failed to unwrap > key for cipher AES > [05/Oct/2009:01:46:37 -0400] - Failed to retrieve key for cipher AES > in attrcrypt_cipher_init > [05/Oct/2009:01:46:37 -0400] - Failed to initialize cipher AES in > attrcrypt_init > [05/Oct/2009:01:46:37 -0400] - attrcrypt_unwrap_key: failed to unwrap > key for cipher 3DES > [05/Oct/2009:01:46:37 -0400] - Failed to retrieve key for cipher 3DES > in attrcrypt_cipher_init > [05/Oct/2009:01:46:37 -0400] - Failed to initialize cipher 3DES in > attrcrypt_init > [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program > - Upgrading from bdb/4 to bdb/4.7/libreplication-plugin is > successfully done (/var/lib/dirsrv/slapd-REALM-COM/cldb) > [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program > - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument > [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program > - cl5Open: failed to open changelog > [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program > - changelog5_init: failed to start changelog at > /var/lib/dirsrv/slapd-REALM-COM/cldb > [05/Oct/2009:01:46:37 -0400] - Failed to start object plugin > Multimaster Replication Plugin > [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program > - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument > [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program > - cl5Open: failed to open changelog > [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program > - changelog5_init: failed to start changelog at > /var/lib/dirsrv/slapd-REALM-COM/cldb > [05/Oct/2009:01:46:37 -0400] - Failed to start object plugin > Multimaster Replication Plugin > [05/Oct/2009:01:46:37 -0400] - Error: Failed to resolve plugin > dependencies > [05/Oct/2009:01:46:37 -0400] - Error: object plugin Legacy Replication > Plugin is not started > [05/Oct/2009:01:46:37 -0400] - Error: object plugin Multimaster > Replication Plugin is not started > 389-Directory/1.2.2 B2009.237.206 > directory.REALM.com:636 (/etc/dirsrv/slapd-REALM-COM) > > [05/Oct/2009:01:58:17 -0400] - 389-Directory/1.2.2 B2009.237.206 > starting up > [05/Oct/2009:01:58:17 -0400] - Detected Disorderly Shutdown last time > Directory Server was running, recovering database. > [05/Oct/2009:01:58:18 -0400] - attrcrypt_unwrap_key: failed to unwrap > key for cipher AES > [05/Oct/2009:01:58:18 -0400] - Failed to retrieve key for cipher AES > in attrcrypt_cipher_init > [05/Oct/2009:01:58:18 -0400] - Failed to initialize cipher AES in > attrcrypt_init > [05/Oct/2009:01:58:18 -0400] - attrcrypt_unwrap_key: failed to unwrap > key for cipher 3DES > [05/Oct/2009:01:58:18 -0400] - Failed to retrieve key for cipher 3DES > in attrcrypt_cipher_init > [05/Oct/2009:01:58:18 -0400] - Failed to initialize cipher 3DES in > attrcrypt_init > [05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program > - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument > [05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program > - cl5Open: failed to open changelog > [05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program > - changelog5_init: failed to start changelog at > /var/lib/dirsrv/slapd-REALM-COM/cldb > [05/Oct/2009:01:58:19 -0400] - Failed to start object plugin > Multimaster Replication Plugin > [05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program > - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument > [05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program > - cl5Open: failed to open changelog > [05/Oct/2009:01:58:19 -0400] NSMMReplicationPlugin - changelog program > - changelog5_init: failed to start changelog at > /var/lib/dirsrv/slapd-REALM-COM/cldb > [05/Oct/2009:01:58:19 -0400] - Failed to start object plugin > Multimaster Replication Plugin > [05/Oct/2009:01:58:19 -0400] - Error: Failed to resolve plugin > dependencies > [05/Oct/2009:01:58:19 -0400] - Error: object plugin Legacy Replication > Plugin is not started > [05/Oct/2009:01:58:19 -0400] - Error: object plugin Multimaster > Replication Plugin is not started > Fedora-Directory/1.2.0 B2009.118.167 > directory.REALM.com:636 (/etc/dirsrv/slapd-REALM-COM) > > [05/Oct/2009:02:49:56 -0400] - Fedora-Directory/1.2.0 B2009.118.167 > starting up > [05/Oct/2009:02:49:56 -0400] - Detected Disorderly Shutdown last time > Directory Server was running, recovering database. > [05/Oct/2009:02:49:57 -0400] - attrcrypt_unwrap_key: failed to unwrap > key for cipher AES > [05/Oct/2009:02:49:57 -0400] - Failed to retrieve key for cipher AES > in attrcrypt_cipher_init > [05/Oct/2009:02:49:57 -0400] - Failed to initialize cipher AES in > attrcrypt_init > [05/Oct/2009:02:49:57 -0400] NSMMReplicationPlugin - changelog program > - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument > [05/Oct/2009:02:49:57 -0400] NSMMReplicationPlugin - changelog program > - cl5Open: failed to open changelog > [05/Oct/2009:02:49:57 -0400] NSMMReplicationPlugin - changelog program > - changelog5_init: failed to start changelog at > /var/lib/dirsrv/slapd-REALM-COM/cldb > [05/Oct/2009:02:49:57 -0400] - Failed to start object plugin > Multimaster Replication Plugin > [05/Oct/2009:02:49:58 -0400] NSMMReplicationPlugin - changelog program > - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument > [05/Oct/2009:02:49:58 -0400] NSMMReplicationPlugin - changelog program > - cl5Open: failed to open changelog > [05/Oct/2009:02:49:58 -0400] NSMMReplicationPlugin - changelog program > - changelog5_init: failed to start changelog at > /var/lib/dirsrv/slapd-REALM-COM/cldb > [05/Oct/2009:02:49:58 -0400] - Failed to start object plugin > Multimaster Replication Plugin > [05/Oct/2009:02:49:58 -0400] - Error: Failed to resolve plugin > dependencies > [05/Oct/2009:02:49:58 -0400] - Error: object plugin Legacy Replication > Plugin is not started > [05/Oct/2009:02:49:58 -0400] - Error: object plugin Multimaster > Replication Plugin is not started > > I have two replica servers installed, one a FC10 DS 1.2.2 and one a > windows domain controller. > > I have backed up basically everything in multiple formats (db2bak, > ldif, tar). I am going to have to roll the server back to FC9 for the > evening. Anyone have any ideas how to eliminate the errors, or perform > the upgrade in a way that avoids them? Do I need to remove the > replication agreements first? Looks like it did attempt to upgrade the database formats, but it somehow left the changelog database in a bad state [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - Upgrading from bdb/4 to bdb/4.7/libreplication-plugin is successfully done (/var/lib/dirsrv/slapd-REALM-COM/cldb) [05/Oct/2009:01:46:37 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: db_open failed; db error - 22 Invalid argument Try this - shutdown the directory server - look in /etc/dirsrv/slapd-REALM-COM/dse.ldif - look for the entry cn=changelog5,cn=config - look for the attribute nsslapd-changelogdir: in that entry - note the name of the directory specified - the default is /var/lib/dirsrv/slapd-REALM-COM/cldb or changelogdb - remove the contents of that directory - do not remove the directory, just the contents - then restart your server You will then have to perform replication consumer init on all of your other servers. Please file a bug at https://bugzilla.redhat.com/enter_bug.cgi?product=389 > > > James Roman > Sr. Network Administrator > TerraNet, Inc. on Contract to SSAI > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From tfar at smc.co.nz Wed Oct 7 22:39:23 2009 From: tfar at smc.co.nz (Anthony M. Farrell) Date: Thu, 8 Oct 2009 11:39:23 +1300 Subject: [389-users] Problem creating new Organizational Unit In-Reply-To: <4ACCA324.4030407@redhat.com> References: <200910071831.19176.tfar@smc.co.nz> <4ACCA324.4030407@redhat.com> Message-ID: <200910081139.23790.tfar@smc.co.nz> On Thu, 08 Oct 2009 03:18:12 Rich Megginson wrote: > What are the exact steps you are using to create the OU entry? Are you > using the Directory tab in the Directory Server window of the console? > Are you using the main window Users&Groups editor? > Can you reproduce the problem using 389-console -D 9 -f console.log, > edit console.log to remove any sensitive information, and paste the > console.log to the list? > The project aim is to migrate from a standalone FDS server to an upgraded 389 DS running in a virtual environment. The only change I have made to the default 389 installation is to add the horde schema, used to enable the Horde/Turba addressbook capability and this works very well. Users and Groups were imported from the previous FDS 1.0.4 installation using the Export and Import Databases option under the Tasks tab. The LDIF data includes Samba schema entries that had been working very well on the other box. I have enabled posixUser attributes for UID and the required primary GID for our database account and added the posixGroup value to objectclass to enable the RedHat Private User Groups to be entered for our Linux file server accounts. I have also created a number of specific user groups and allocated members. All this appears to be working just fine. Future intention is to use the DNA plugin to manage the UID/GID allocation. I didn't want to import the existing Windows domain client machine accounts other than one AIX Domain Member Server so I didn't import that OU. So I now want to manually create a 'Computers' OU in 389 so that I can join the Server to the domain. I tried both the Users and Groups editor and the Directory tab under the Directory Server window with the same result in both cases. Under the Directory Server I placed the cursor on the Base DN, right clicked and selected 'New' 'Organizational Unit' and entered the required name 'Computers', left all other fields blank and clicked on OK. The result is the error 65 output. Here is the console.log: java.util.prefs.userRoot=/home/tfar/.389-console java.runtime.name=OpenJDK Runtime Environment sun.boot.library.path=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386 java.vm.version=1.6.0-b09 java.vm.vendor=Sun Microsystems Inc. java.vendor.url=http://java.sun.com/ path.separator=: java.vm.name=OpenJDK Client VM file.encoding.pkg=sun.io sun.java.launcher=SUN_STANDARD user.country=US sun.os.patch.level=unknown java.vm.specification.name=Java Virtual Machine Specification user.dir=/home/tfar java.runtime.version=1.6.0-b09 java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment java.endorsed.dirs=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/endorsed os.arch=i386 java.io.tmpdir=/tmp line.separator= java.vm.specification.vendor=Sun Microsystems Inc. os.name=Linux sun.jnu.encoding=UTF-8 java.library.path=/usr/lib/jvm/java-1.6.0- openjdk-1.6.0.0/jre/lib/i386/client:/usr/lib/jvm/java-1.6.0- openjdk-1.6.0.0/jre/lib/i386:/usr/lib/jvm/java-1.6.0- openjdk-1.6.0.0/jre/../lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib java.specification.name=Java Platform API Specification java.class.version=50.0 sun.management.compiler=HotSpot Client Compiler os.version=2.6.18-92.el5xen user.home=/home/tfar user.zoneinfo.dir=/usr/share/javazi user.timezone=Pacific/Auckland java.awt.printerjob=sun.print.PSPrinterJob file.encoding=UTF-8 java.specification.version=1.6 java.class.path=/usr/lib/java/jss4.jar:/usr/share/java/ldapjdk.jar:/usr/share/java/idm- console-base.jar:/usr/share/java/idm-console-mcc.jar:/usr/share/java/idm- console-mcc_en.jar:/usr/share/java/idm-console-nmclf.jar:/usr/share/java/idm- console-nmclf_en.jar:/usr/share/java/389-console-1.1.3_en.jar user.name=tfar java.vm.specification.version=1.0 java.home=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre sun.arch.data.model=32 java.util.prefs.systemRoot=/home/tfar/.389-console user.language=en java.specification.vendor=Sun Microsystems Inc. java.vm.info=mixed mode java.version=1.6.0 java.ext.dirs=/usr/lib/jvm/java-1.6.0- openjdk-1.6.0.0/jre/lib/ext:/usr/java/packages/lib/ext sun.boot.class.path=/usr/lib/jvm/java-1.6.0- openjdk-1.6.0.0/jre/lib/resources.jar:/usr/lib/jvm/java-1.6.0- openjdk-1.6.0.0/jre/lib/rt.jar:/usr/lib/jvm/java-1.6.0- openjdk-1.6.0.0/jre/lib/sunrsasign.jar:/usr/lib/jvm/java-1.6.0- openjdk-1.6.0.0/jre/lib/jsse.jar:/usr/lib/jvm/java-1.6.0- openjdk-1.6.0.0/jre/lib/jce.jar:/usr/lib/jvm/java-1.6.0- openjdk-1.6.0.0/jre/lib/charsets.jar:/usr/lib/jvm/java-1.6.0- openjdk-1.6.0.0/jre/classes java.vendor=Sun Microsystems Inc. file.separator=/ java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport.cgi sun.io.unicode.encoding=UnicodeLittle sun.cpu.endian=little sun.cpu.isalist= 389-Management-Console/1.1.3 B2009.091.1851 RemoteImage: NOT found in cache loader9690857:com/netscape/management/nmclf/icons/Error.gif RemoteImage: Create RemoteImage cache for loader9690857 RemoteImage: NOT found in cache loader9690857:com/netscape/management/nmclf/icons/Inform.gif RemoteImage: NOT found in cache loader9690857:com/netscape/management/nmclf/icons/Warn.gif RemoteImage: NOT found in cache loader9690857:com/netscape/management/nmclf/icons/Question.gif ResourceSet: NOT found in cache loader9690857:com.netscape.management.client.components.components RemoteImage: NOT found in cache loader9690857:com/netscape/management/client/theme/images/logo16.gif RemoteImage: NOT found in cache loader9690857:com/netscape/management/client/theme/images/login.gif ResourceSet: NOT found in cache loader9690857:com.netscape.management.client.util.default ResourceSet: found in cache loader9690857:com.netscape.management.client.util.default JButtonFactory: button width = 54 JButtonFactory: button height = 18 JButtonFactory: button width = 54 JButtonFactory: button height = 18 JButtonFactory: button width = 90 JButtonFactory: button height = 18 JButtonFactory: button width = 90 JButtonFactory: button height = 18 JButtonFactory: button width = 72 JButtonFactory: button height = 18 JButtonFactory: button width = 72 JButtonFactory: button height = 18 JButtonFactory: button width = 54 JButtonFactory: button height = 18 JButtonFactory: button width = 90 JButtonFactory: button width = 72 ResourceSet: found in cache loader9690857:com.netscape.management.client.util.default CommManager> New CommRecord (http://localhost:9830/admin-serv/authenticate) ResourceSet: found in cache loader9690857:com.netscape.management.client.theme.theme http://localhost:9830/[0:0] open> Ready http://localhost:9830/[0:0] accept> http://localhost:9830/admin- serv/authenticate http://localhost:9830/[0:0] send> GET \ http://localhost:9830/[0:0] send> /admin-serv/authenticate \ http://localhost:9830/[0:0] send> HTTP/1.0 http://localhost:9830/[0:0] send> Host: localhost:9830 http://localhost:9830/[0:0] send> Connection: Keep-Alive http://localhost:9830/[0:0] send> User-Agent: 389-Management-Console/1.1.3 http://localhost:9830/[0:0] send> Accept-Language: en http://localhost:9830/[0:0] send> Authorization: Basic \ http://localhost:9830/[0:0] send> XXXXXXXXXXXXXXX= \ http://localhost:9830/[0:0] send> http://localhost:9830/[0:0] send> http://localhost:9830/[0:0] recv> HTTP/1.1 200 OK http://localhost:9830/[0:0] recv> Date: Wed, 07 Oct 2009 20:18:23 GMT http://localhost:9830/[0:0] recv> Server: Apache/2.2 HttpChannel.invoke: admin version = 2.2 http://localhost:9830/[0:0] recv> Admin-Server: 389-Administrator/1.1.8 HttpChannel.invoke: admin version = 1.1.8 http://localhost:9830/[0:0] recv> Content-Length: 363 http://localhost:9830/[0:0] recv> Connection: close http://localhost:9830/[0:0] recv> Content-Type: text/html http://localhost:9830/[0:0] recv> http://localhost:9830/[0:0] recv> Reading 363 bytes... http://localhost:9830/[0:0] recv> 363 bytes read Console.replyHandler: adminVersion = 1.1.8 ResourceSet: found in cache loader9690857:com.netscape.management.client.console.console ResourceSet: found in cache loader9690857:com.netscape.management.client.console.console ResourceSet: found in cache loader9690857:com.netscape.management.client.console.console ResourceSet: found in cache loader9690857:com.netscape.management.client.console.console ResourceSet: found in cache loader9690857:com.netscape.management.client.console.console ResourceSet: found in cache loader9690857:com.netscape.management.client.util.default ClassLoaderUtil.getClass(com.netscape.admin.dirserv.roledit.ResEditorRoleInfo at fedora- ds-1.2.jar) ResourceSet: found in cache loader9690857:com.netscape.management.client.util.default ClassLoader: getLocalJarList():Unable to read /home/tfar/.389-console/patch/ directory ClassLoader:persistanceTable LINE=mcc60.jar:mcc50.jar,mcc42.jar,mcc41.jar,mcc40.jar newJar=mcc60.jar oldJars=mcc50.jar,mcc42.jar,mcc41.jar,mcc40.jar ClassLoader:persistanceTable mcc50.jar use instead mcc60.jar ClassLoader:persistanceTable mcc42.jar use instead mcc60.jar ClassLoader:persistanceTable mcc41.jar use instead mcc60.jar ClassLoader:persistanceTable mcc40.jar use instead mcc60.jar ClassLoader:persistanceTable LINE=nmclf60.jar:nmclf50.jar,nmclf42.jar,nmclf41.jar,nmclf40.jar newJar=nmclf60.jar oldJars=nmclf50.jar,nmclf42.jar,nmclf41.jar,nmclf40.jar ClassLoader:persistanceTable nmclf50.jar use instead nmclf60.jar ClassLoader:persistanceTable nmclf42.jar use instead nmclf60.jar ClassLoader:persistanceTable nmclf41.jar use instead nmclf60.jar ClassLoader:persistanceTable nmclf40.jar use instead nmclf60.jar ClassLoader: start parsing ClassLoader:persistanceTable no manifest in fedora-admin-1.1.jar ClassLoader:persistanceTable no backward-compatible in manifest for fedora- ds-1.2.jar ClassLoader:persistanceTable no manifest in fedora-admin-1.1_en.jar ClassLoader:persistanceTable no manifest in fedora-ds-1.2_en.jar ClassLoader: done ClassLoader: classes.env found in fedora-ds-1.2.jar ClassLoader: manifest loaded for fedora-ds-1.2.jar ClassLoader: manifest: 0 entries found ClassLoader: new LocalJarClassLoader fedora-ds-1.2.jar:{fedora-ds-1.2.jar fedora-ds-1.2_en.jar } ClassLoader: Create loader fedora-ds-1.2.jar ClassLoader: :loadClass():name:com.netscape.admin.dirserv.roledit.ResEditorRoleInfo ClassLoader: :loadClass():loading:com.netscape.admin.dirserv.roledit.ResEditorRoleInfo ClassLoader: com/netscape/admin/dirserv/roledit/ResEditorRoleInfo.class found in fedora-ds-1.2.jar ClassLoader: :loadClass():name:com.netscape.management.client.ug.IResourceEditorPage ClassLoader: :loadClass():loading:com.netscape.management.client.ug.IResourceEditorPage ClassLoader: com/netscape/management/client/ug/IResourceEditorPage.class NOT in fedora-ds-1.2.jar ClassLoader: com/netscape/management/client/ug/IResourceEditorPage.class NOT in fedora-ds-1.2_en.jar ClassLoader: :loadClass():name:java.util.Observer ClassLoader: :loadClass():name:javax.swing.JPanel ClassLoader: :loadClass():loading:javax.swing.JPanel ClassLoader: javax/swing/JPanel.class NOT in fedora-ds-1.2.jar ClassLoader: javax/swing/JPanel.class NOT in fedora-ds-1.2_en.jar ClassLoader: :loadClass():resolving com.netscape.admin.dirserv.roledit.ResEditorRoleInfo ClassLoaderUtil.getClass(com.netscape.admin.dirserv.roledit.ResEditorRoleMembers at fedora- ds-1.2.jar) ClassLoader: Loader fedora-ds-1.2.jar found in cache ClassLoader: :loadClass():name:com.netscape.admin.dirserv.roledit.ResEditorRoleMembers ClassLoader: :loadClass():loading:com.netscape.admin.dirserv.roledit.ResEditorRoleMembers ClassLoader: com/netscape/admin/dirserv/roledit/ResEditorRoleMembers.class found in fedora-ds-1.2.jar ClassLoader: :loadClass():name:com.netscape.admin.dirserv.roledit.ResEditorRadioPage ClassLoader: :loadClass():loading:com.netscape.admin.dirserv.roledit.ResEditorRadioPage ClassLoader: com/netscape/admin/dirserv/roledit/ResEditorRadioPage.class found in fedora-ds-1.2.jar ClassLoader: :loadClass():name:com.netscape.admin.dirserv.IDSResourceEditorPage ClassLoader: :loadClass():loading:com.netscape.admin.dirserv.IDSResourceEditorPage ClassLoader: com/netscape/admin/dirserv/IDSResourceEditorPage.class found in fedora-ds-1.2.jar ClassLoader: :loadClass():name:java.lang.Object ClassLoader: :loadClass():name:java.awt.event.ActionListener ClassLoader: :loadClass():name:com.netscape.management.nmclf.SuiConstants ClassLoader: :loadClass():loading:com.netscape.management.nmclf.SuiConstants ClassLoader: com/netscape/management/nmclf/SuiConstants.class NOT in fedora- ds-1.2.jar ClassLoader: com/netscape/management/nmclf/SuiConstants.class NOT in fedora- ds-1.2_en.jar ClassLoader: :loadClass():resolving com.netscape.admin.dirserv.roledit.ResEditorRoleMembers ClassLoaderUtil.getClass(com.netscape.admin.dirserv.roledit.ResEditorRoleAccountPage at fedora- ds-1.2.jar) ClassLoader: Loader fedora-ds-1.2.jar found in cache ClassLoader: :loadClass():name:com.netscape.admin.dirserv.roledit.ResEditorRoleAccountPage ClassLoader: :loadClass():loading:com.netscape.admin.dirserv.roledit.ResEditorRoleAccountPage ClassLoader: com/netscape/admin/dirserv/roledit/ResEditorRoleAccountPage.class found in fedora-ds-1.2.jar ClassLoader: :loadClass():name:com.netscape.management.client.ug.DefaultResEditorPage ClassLoader: :loadClass():loading:com.netscape.management.client.ug.DefaultResEditorPage ClassLoader: com/netscape/management/client/ug/DefaultResEditorPage.class NOT in fedora-ds-1.2.jar ClassLoader: com/netscape/management/client/ug/DefaultResEditorPage.class NOT in fedora-ds-1.2_en.jar ClassLoader: :loadClass():resolving com.netscape.admin.dirserv.roledit.ResEditorRoleAccountPage ResourceSet: found in cache loader9690857:com.netscape.management.client.console.console ResourceSet: found in cache loader9690857:com.netscape.management.client.console.console ResourceSet: found in cache loader9690857:com.netscape.management.client.console.console ClassLoaderUtil.getClass(com.netscape.admin.dirserv.cosedit.ResEditorCosInfo at fedora- ds-1.2.jar) ClassLoader: Loader fedora-ds-1.2.jar found in cache ClassLoader: :loadClass():name:com.netscape.admin.dirserv.cosedit.ResEditorCosInfo ClassLoader: :loadClass():loading:com.netscape.admin.dirserv.cosedit.ResEditorCosInfo ClassLoader: com/netscape/admin/dirserv/cosedit/ResEditorCosInfo.class found in fedora-ds-1.2.jar ClassLoader: :loadClass():resolving com.netscape.admin.dirserv.cosedit.ResEditorCosInfo ClassLoaderUtil.getClass(com.netscape.admin.dirserv.cosedit.ResEditorCosAttributes at fedora- ds-1.2.jar) ClassLoader: Loader fedora-ds-1.2.jar found in cache ClassLoader: :loadClass():name:com.netscape.admin.dirserv.cosedit.ResEditorCosAttributes ClassLoader: :loadClass():loading:com.netscape.admin.dirserv.cosedit.ResEditorCosAttributes ClassLoader: com/netscape/admin/dirserv/cosedit/ResEditorCosAttributes.class found in fedora-ds-1.2.jar ClassLoader: :loadClass():name:javax.swing.event.ListSelectionListener ClassLoader: :loadClass():loading:javax.swing.event.ListSelectionListener ClassLoader: javax/swing/event/ListSelectionListener.class NOT in fedora- ds-1.2.jar ClassLoader: javax/swing/event/ListSelectionListener.class NOT in fedora- ds-1.2_en.jar ClassLoader: :loadClass():resolving com.netscape.admin.dirserv.cosedit.ResEditorCosAttributes ClassLoaderUtil.getClass(com.netscape.admin.dirserv.cosedit.ResEditorCosTemplate at fedora- ds-1.2.jar) ClassLoader: Loader fedora-ds-1.2.jar found in cache ClassLoader: :loadClass():name:com.netscape.admin.dirserv.cosedit.ResEditorCosTemplate ClassLoader: :loadClass():loading:com.netscape.admin.dirserv.cosedit.ResEditorCosTemplate ClassLoader: com/netscape/admin/dirserv/cosedit/ResEditorCosTemplate.class found in fedora-ds-1.2.jar ClassLoader: :loadClass():resolving com.netscape.admin.dirserv.cosedit.ResEditorCosTemplate ResourceSet: found in cache loader9690857:com.netscape.management.client.console.console ResourceSet: found in cache loader9690857:com.netscape.management.client.console.console . . 20 times loader9690857:com.netscape.management.client.topology.topology ResourceSet: found in cache loader9690857:com.netscape.management.client.topology.topology ResourceSet: found in cache loader9690857:com.netscape.management.client.theme.theme RemoteImage: found in cache loader9690857:com/netscape/management/client/theme/images/logo16.gif RemoteImage: NOT found in cache loader9690857:com/netscape/management/client/theme/images/ConsoleBanner.gif RemoteImage: NOT found in cache loader9690857:com/netscape/management/client/images/warn16.gif ResourceSet: NOT found in cache loader9690857:com.netscape.management.client.default UIPermissions: TopologyEditing yes ResourceSet: found in cache loader9690857:com.netscape.management.client.topology.topology ResourceSet: found in cache loader9690857:com.netscape.management.client.topology.topology ResourceSet: found in cache loader9690857:com.netscape.management.client.default ResourceSet: found in cache loader9690857:com.netscape.management.client.topology.topology ResourceSet: found in cache loader9690857:com.netscape.management.client.topology.topology UIPermissions: CustomViewEditing yes ResourceSet: found in cache loader9690857:com.netscape.management.client.default ResourceSet: found in cache loader9690857:com.netscape.management.client.theme.theme ResourceSet: found in cache loader9690857:com.netscape.management.client.default ResourceSet: found in cache loader9690857:com.netscape.management.client.topology.topology ResourceSet: found in cache loader9690857:com.netscape.management.client.topology.topology RemoteImage: NOT found in cache loader9690857:com/netscape/management/client/topology/images/domain16.gif TRACE ConsoleInfo.clone: tracking cloning of ConsoleInfo for performance tuning ResourceSet: found in cache loader9690857:com.netscape.management.client.console.console ResourceSet: found in cache loader9690857:com.netscape.management.client.topology.topology RemoteImage: NOT found in cache loader9690857:com/netscape/management/client/topology/images/host16.gif ResourceSet: found in cache loader9690857:com.netscape.management.client.topology.topology UIPermissions: UGTabVisibility yes UIPermissions: UGEditing yes ResourceSet: found in cache loader9690857:com.netscape.management.client.topology.topology TRACE ConsoleInfo.clone: tracking cloning of ConsoleInfo for performance tuning pub defaultView=null user defaultView=null RemoteImage: NOT found in cache loader9690857:com/netscape/management/client/images/notsecure.gif ResourceSet: found in cache loader9690857:com.netscape.management.client.topology.topology JButtonFactory: button width = 90 . . 20 times . topology.NodeDataPanel ancestorAdded() adds Change Listener http://localhost:9830/[0:0] close> Closed TRACE ConsoleInfo.clone: tracking cloning of ConsoleInfo for performance tuning ResourceSet: found in cache loader9690857:com.netscape.management.client.topology.topology RemoteImage: NOT found in cache loader9690857:com/netscape/management/nmclf/icons/user24.gif RemoteImage: NOT found in cache loader9690857:com/netscape/management/nmclf/icons/group24.gif RemoteImage: NOT found in cache loader9690857:com/netscape/management/nmclf/icons/ou24.gif JButtonFactory: button width = 54 . . 20 times . ResourceSet: NOT found in cache loader9690857:com.netscape.management.client.ug.PickerEditorResource ResourceSet: found in cache loader9690857:com.netscape.management.client.ug.PickerEditorResource ResourceSet: found in cache loader9690857:com.netscape.management.client.ug.PickerEditorResource RemoteImage: NOT found in cache loader9690857:com/netscape/management/nmclf/icons/user.gif RemoteImage: NOT found in cache loader9690857:com/netscape/management/nmclf/icons/group.gif RemoteImage: NOT found in cache loader9690857:com/netscape/management/nmclf/icons/ou.gif JButtonFactory: button width = 90 JButtonFactory: button height = 18 JButtonFactory: button width = 90 JButtonFactory: button height = 18 JButtonFactory: button width = 72 JButtonFactory: button height = 18 JButtonFactory: button width = 72 JButtonFactory: button height = 18 topology.NodeDataPanel ancestorRemoved() removes Change Listener ResourceSet: found in cache loader9690857:com.netscape.management.client.topology.topology JButtonFactory: button width = 54 JButtonFactory: button height = 18 . . 20 times . ResourceSet: found in cache loader9690857:com.netscape.management.client.console.console ResourceSet: found in cache loader9690857:com.netscape.management.client.console.console ResourceSet: found in cache loader9690857:com.netscape.management.client.console.console ResourceSet: found in cache loader9690857:com.netscape.management.client.console.console ResourceSet: found in cache loader9690857:com.netscape.management.client.console.console ResourceSet: found in cache loader9690857:com.netscape.management.client.console.console TRACE ConsoleInfo.clone: tracking cloning of ConsoleInfo for performance tuning ResourceSet: found in cache loader9690857:com.netscape.management.client.ug.PickerEditorResource ResourceSet: found in cache loader9690857:com.netscape.management.client.ug.PickerEditorResource ResourceSet: found in cache loader9690857:com.netscape.management.client.ug.PickerEditorResource JButtonFactory: button width = 108 JButtonFactory: button height = 18 JButtonFactory: button width = 90 JButtonFactory: button height = 18 ResourceSet: found in cache loader9690857:com.netscape.management.client.ug.PickerEditorResource ResourceSet: found in cache loader9690857:com.netscape.management.client.ug.PickerEditorResource . . 50 times . ResourceEditor.valueChanged: o=com.netscape.management.client.ug.OUPage[,0,0,0x0,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=] RemoteImage: found in cache loader9690857:com/netscape/management/nmclf/icons/ou24.gif ResourceEditor.update: o=ResourcePageObservable: newUser=true sBaseDN=dc=smc, dc=co, dc=nz objectClassList=top organizationalunit posixuser attributes={objectclass=LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'}} attrAdd=AttributeValuePair: objectclass LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'} attrReplace= attrDelete= entry=null arg=aliasedobjectname ResourceEditor.update: o=ResourcePageObservable: newUser=true sBaseDN=dc=smc, dc=co, dc=nz objectClassList=top organizationalunit posixuser attributes={ou=LDAPAttribute {type='ou', values='Computers'}, objectclass=LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'}} attrAdd=AttributeValuePair: objectclass LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'} AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} attrReplace= attrDelete= entry=null arg=ou ResourceEditor.update: o=ResourcePageObservable: newUser=true sBaseDN=dc=smc, dc=co, dc=nz objectClassList=top organizationalunit posixuser attributes={ou=LDAPAttribute {type='ou', values='Computers'}, objectclass=LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'}} attrAdd=AttributeValuePair: objectclass LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'} AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} attrReplace= attrDelete= entry=null arg=description ResourceEditor.update: o=ResourcePageObservable: newUser=true sBaseDN=dc=smc, dc=co, dc=nz objectClassList=top organizationalunit posixuser attributes={ou=LDAPAttribute {type='ou', values='Computers'}, objectclass=LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'}} attrAdd=AttributeValuePair: objectclass LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'} AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} attrReplace= attrDelete= entry=null arg=telephonenumber ResourceEditor.update: o=ResourcePageObservable: newUser=true sBaseDN=dc=smc, dc=co, dc=nz objectClassList=top organizationalunit posixuser attributes={ou=LDAPAttribute {type='ou', values='Computers'}, objectclass=LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'}} attrAdd=AttributeValuePair: objectclass LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'} AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} attrReplace= attrDelete= entry=null arg=facsimiletelephonenumber ResourceEditor.update: o=ResourcePageObservable: newUser=true sBaseDN=dc=smc, dc=co, dc=nz objectClassList=top organizationalunit posixuser attributes={ou=LDAPAttribute {type='ou', values='Computers'}, objectclass=LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'}} attrAdd=AttributeValuePair: objectclass LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'} AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} attrReplace= attrDelete= entry=null arg=registeredaddress ResourceEditor.update: o=ResourcePageObservable: newUser=true sBaseDN=dc=smc, dc=co, dc=nz objectClassList=top organizationalunit posixuser attributes={ou=LDAPAttribute {type='ou', values='Computers'}, objectclass=LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'}} attrAdd=AttributeValuePair: objectclass LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'} AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} attrReplace= attrDelete= entry=null arg=aliasedobjectname;lang-af ResourceEditor.update: o=ResourcePageObservable: newUser=true sBaseDN=dc=smc, dc=co, dc=nz objectClassList=top organizationalunit posixuser attributes={ou=LDAPAttribute {type='ou', values='Computers'}, objectclass=LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'}} attrAdd=AttributeValuePair: objectclass LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'} AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} attrReplace= attrDelete= entry=null arg=description;lang-af ResourceEditor.update: o=ResourcePageObservable: newUser=true sBaseDN=dc=smc, dc=co, dc=nz objectClassList=top organizationalunit posixuser attributes={ou=LDAPAttribute {type='ou', values='Computers'}, objectclass=LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'}} attrAdd=AttributeValuePair: objectclass LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'} AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} attrReplace= attrDelete= entry=null arg=telephonenumber;lang-af ResourceEditor.update: o=ResourcePageObservable: newUser=true sBaseDN=dc=smc, dc=co, dc=nz objectClassList=top organizationalunit posixuser attributes={ou=LDAPAttribute {type='ou', values='Computers'}, objectclass=LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'}} attrAdd=AttributeValuePair: objectclass LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'} AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} attrReplace= attrDelete= entry=null arg=facsimiletelephonenumber;lang-af ResourceEditor.update: o=ResourcePageObservable: newUser=true sBaseDN=dc=smc, dc=co, dc=nz objectClassList=top organizationalunit posixuser attributes={ou=LDAPAttribute {type='ou', values='Computers'}, objectclass=LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'}} attrAdd=AttributeValuePair: objectclass LDAPAttribute {type='objectclass', values='top,organizationalunit,posixuser'} AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} attrReplace= attrDelete= entry=null arg=registeredaddress;lang-af ResourcePageObservable.java:ADD LDAP ENTRY:unknown object class "posixuser" for ou=Computers,dc=smc, dc=co, dc=nz JButtonFactory: button width = 54 JButtonFactory: button height = 18 JButtonFactory: button width = 54 JButtonFactory: button height = 18 JButtonFactory: button width = 54 JButtonFactory: button height = 18 JButtonFactory: button width = 54 JButtonFactory: button height = 18 netscape.ldap.LDAPException: error result (65); unknown object class "posixuser" ; Object class violation at netscape.ldap.LDAPConnection.checkMsg(Unknown Source) at netscape.ldap.LDAPConnection.add(Unknown Source) at netscape.ldap.LDAPConnection.add(Unknown Source) at netscape.ldap.LDAPConnection.add(Unknown Source) at com.netscape.management.client.ug.ResourcePageObservable.save(Unknown Source) at com.netscape.management.client.ug.ResourceEditor.processEvent(Unknown Source) at com.netscape.management.client.ug.ResourceEditor.actionPerformed(Unknown Source) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2012) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2335) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:404) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:253) at java.awt.Component.processMouseEvent(Component.java:6101) at javax.swing.JComponent.processMouseEvent(JComponent.java:3276) at java.awt.Component.processEvent(Component.java:5866) at java.awt.Container.processEvent(Container.java:2105) at java.awt.Component.dispatchEventImpl(Component.java:4462) at java.awt.Container.dispatchEventImpl(Container.java:2163) at java.awt.Component.dispatchEvent(Component.java:4288) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4461) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4125) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4055) at java.awt.Container.dispatchEventImpl(Container.java:2149) at java.awt.Window.dispatchEventImpl(Window.java:2478) at java.awt.Component.dispatchEvent(Component.java:4288) at java.awt.EventQueue.dispatchEvent(EventQueue.java:604) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:194) at java.awt.Dialog$1.run(Dialog.java:1072) at java.awt.Dialog$3.run(Dialog.java:1126) at java.security.AccessController.doPrivileged(Native Method) at java.awt.Dialog.show(Dialog.java:1124) at com.netscape.management.client.util.AbstractDialog.show(Unknown Source) at com.netscape.management.client.util.AbstractDialog.showModal(Unknown Source) at com.netscape.management.client.topology.ug.EditUserGroupPane.createEntry(Unknown Source) at com.netscape.management.client.topology.ug.EditUserGroupPane.actionPerformed(Unknown Source) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2012) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2335) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:404) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) at javax.swing.AbstractButton.doClick(AbstractButton.java:374) at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1688) at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1732) at java.awt.Component.processMouseEvent(Component.java:6101) at javax.swing.JComponent.processMouseEvent(JComponent.java:3276) at java.awt.Component.processEvent(Component.java:5866) at java.awt.Container.processEvent(Container.java:2105) at java.awt.Component.dispatchEventImpl(Component.java:4462) at java.awt.Container.dispatchEventImpl(Container.java:2163) at java.awt.Component.dispatchEvent(Component.java:4288) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4461) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4125) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4055) at java.awt.Container.dispatchEventImpl(Container.java:2149) at java.awt.Window.dispatchEventImpl(Window.java:2478) at java.awt.Component.dispatchEvent(Component.java:4288) at java.awt.EventQueue.dispatchEvent(EventQueue.java:604) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177) at java.awt.EventDispatchThread.run(EventDispatchThread.java:138) ResourceSet: found in cache loader9690857:com.netscape.management.client.util.default ResourceSet: found in cache loader9690857:com.netscape.management.client.util.default -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From rmeggins at redhat.com Wed Oct 7 23:10:02 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 07 Oct 2009 17:10:02 -0600 Subject: [389-users] Problem creating new Organizational Unit In-Reply-To: <200910081139.23790.tfar@smc.co.nz> References: <200910071831.19176.tfar@smc.co.nz> <4ACCA324.4030407@redhat.com> <200910081139.23790.tfar@smc.co.nz> Message-ID: <4ACD1FCA.7010505@redhat.com> Anthony M. Farrell wrote: > On Thu, 08 Oct 2009 03:18:12 Rich Megginson wrote: > >> What are the exact steps you are using to create the OU entry? Are you >> using the Directory tab in the Directory Server window of the console? >> Are you using the main window Users&Groups editor? >> Can you reproduce the problem using 389-console -D 9 -f console.log, >> edit console.log to remove any sensitive information, and paste the >> console.log to the list? >> >> > > The project aim is to migrate from a standalone FDS server to an upgraded 389 > DS running in a virtual environment. > > The only change I have made to the default 389 installation is to add the > horde schema, used to enable the Horde/Turba addressbook capability and this > works very well. > > Users and Groups were imported from the previous FDS 1.0.4 installation using > the Export and Import Databases option under the Tasks tab. The LDIF data > includes Samba schema entries that had been working very well on the other > box. > > I have enabled posixUser attributes for UID and the required primary GID for > our database account and added the posixGroup value to objectclass to enable > the RedHat Private User Groups to be entered for our Linux file server > accounts. I have also created a number of specific user groups and allocated > members. All this appears to be working just fine. Future intention is to use > the DNA plugin to manage the UID/GID allocation. > Note that it is the objectclass "posixAccount" not "posixUser". Did you manually add an objectclass named posixUser to something? I'm not sure where the posixUser is coming from, or why it is being added to the list of objectclasses for an organizational unit. Try this /usr/lib/mozldap/ldapsearch -T -D "cn=directory manager"-w password -b o=netscaperoot "objectclass=*" | grep -i posixuser > I didn't want to import the existing Windows domain client machine accounts > other than one AIX Domain Member Server so I didn't import that OU. So I now > want to manually create a 'Computers' OU in 389 so that I can join the Server > to the domain. > > I tried both the Users and Groups editor and the Directory tab under the > Directory Server window with the same result in both cases. Under the > Directory Server I placed the cursor on the Base DN, right clicked and > selected 'New' 'Organizational Unit' and entered the required name > 'Computers', left all other fields blank and clicked on OK. > > The result is the error 65 output. > > Here is the console.log: > > java.util.prefs.userRoot=/home/tfar/.389-console > java.runtime.name=OpenJDK Runtime Environment > sun.boot.library.path=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386 > java.vm.version=1.6.0-b09 > java.vm.vendor=Sun Microsystems Inc. > java.vendor.url=http://java.sun.com/ > path.separator=: > java.vm.name=OpenJDK Client VM > file.encoding.pkg=sun.io > sun.java.launcher=SUN_STANDARD > user.country=US > sun.os.patch.level=unknown > java.vm.specification.name=Java Virtual Machine Specification > user.dir=/home/tfar > java.runtime.version=1.6.0-b09 > java.awt.graphicsenv=sun.awt.X11GraphicsEnvironment > java.endorsed.dirs=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/endorsed > os.arch=i386 > java.io.tmpdir=/tmp > line.separator= > > java.vm.specification.vendor=Sun Microsystems Inc. > os.name=Linux > sun.jnu.encoding=UTF-8 > java.library.path=/usr/lib/jvm/java-1.6.0- > openjdk-1.6.0.0/jre/lib/i386/client:/usr/lib/jvm/java-1.6.0- > openjdk-1.6.0.0/jre/lib/i386:/usr/lib/jvm/java-1.6.0- > openjdk-1.6.0.0/jre/../lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib > java.specification.name=Java Platform API Specification > java.class.version=50.0 > sun.management.compiler=HotSpot Client Compiler > os.version=2.6.18-92.el5xen > user.home=/home/tfar > user.zoneinfo.dir=/usr/share/javazi > user.timezone=Pacific/Auckland > java.awt.printerjob=sun.print.PSPrinterJob > file.encoding=UTF-8 > java.specification.version=1.6 > java.class.path=/usr/lib/java/jss4.jar:/usr/share/java/ldapjdk.jar:/usr/share/java/idm- > console-base.jar:/usr/share/java/idm-console-mcc.jar:/usr/share/java/idm- > console-mcc_en.jar:/usr/share/java/idm-console-nmclf.jar:/usr/share/java/idm- > console-nmclf_en.jar:/usr/share/java/389-console-1.1.3_en.jar > user.name=tfar > java.vm.specification.version=1.0 > java.home=/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre > sun.arch.data.model=32 > java.util.prefs.systemRoot=/home/tfar/.389-console > user.language=en > java.specification.vendor=Sun Microsystems Inc. > java.vm.info=mixed mode > java.version=1.6.0 > java.ext.dirs=/usr/lib/jvm/java-1.6.0- > openjdk-1.6.0.0/jre/lib/ext:/usr/java/packages/lib/ext > sun.boot.class.path=/usr/lib/jvm/java-1.6.0- > openjdk-1.6.0.0/jre/lib/resources.jar:/usr/lib/jvm/java-1.6.0- > openjdk-1.6.0.0/jre/lib/rt.jar:/usr/lib/jvm/java-1.6.0- > openjdk-1.6.0.0/jre/lib/sunrsasign.jar:/usr/lib/jvm/java-1.6.0- > openjdk-1.6.0.0/jre/lib/jsse.jar:/usr/lib/jvm/java-1.6.0- > openjdk-1.6.0.0/jre/lib/jce.jar:/usr/lib/jvm/java-1.6.0- > openjdk-1.6.0.0/jre/lib/charsets.jar:/usr/lib/jvm/java-1.6.0- > openjdk-1.6.0.0/jre/classes > java.vendor=Sun Microsystems Inc. > file.separator=/ > java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport.cgi > sun.io.unicode.encoding=UnicodeLittle > sun.cpu.endian=little > sun.cpu.isalist= > 389-Management-Console/1.1.3 B2009.091.1851 > RemoteImage: NOT found in cache > loader9690857:com/netscape/management/nmclf/icons/Error.gif > RemoteImage: Create RemoteImage cache for loader9690857 > RemoteImage: NOT found in cache > loader9690857:com/netscape/management/nmclf/icons/Inform.gif > RemoteImage: NOT found in cache > loader9690857:com/netscape/management/nmclf/icons/Warn.gif > RemoteImage: NOT found in cache > loader9690857:com/netscape/management/nmclf/icons/Question.gif > ResourceSet: NOT found in cache > loader9690857:com.netscape.management.client.components.components > RemoteImage: NOT found in cache > loader9690857:com/netscape/management/client/theme/images/logo16.gif > RemoteImage: NOT found in cache > loader9690857:com/netscape/management/client/theme/images/login.gif > ResourceSet: NOT found in cache > loader9690857:com.netscape.management.client.util.default > ResourceSet: found in cache > loader9690857:com.netscape.management.client.util.default > JButtonFactory: button width = 54 > JButtonFactory: button height = 18 > JButtonFactory: button width = 54 > JButtonFactory: button height = 18 > JButtonFactory: button width = 90 > JButtonFactory: button height = 18 > JButtonFactory: button width = 90 > JButtonFactory: button height = 18 > JButtonFactory: button width = 72 > JButtonFactory: button height = 18 > JButtonFactory: button width = 72 > JButtonFactory: button height = 18 > JButtonFactory: button width = 54 > JButtonFactory: button height = 18 > JButtonFactory: button width = 90 > JButtonFactory: button width = 72 > ResourceSet: found in cache > loader9690857:com.netscape.management.client.util.default > CommManager> New CommRecord (http://localhost:9830/admin-serv/authenticate) > ResourceSet: found in cache > loader9690857:com.netscape.management.client.theme.theme > http://localhost:9830/[0:0] open> Ready > http://localhost:9830/[0:0] accept> http://localhost:9830/admin- > serv/authenticate > http://localhost:9830/[0:0] send> GET \ > http://localhost:9830/[0:0] send> /admin-serv/authenticate \ > http://localhost:9830/[0:0] send> HTTP/1.0 > http://localhost:9830/[0:0] send> Host: localhost:9830 > http://localhost:9830/[0:0] send> Connection: Keep-Alive > http://localhost:9830/[0:0] send> User-Agent: 389-Management-Console/1.1.3 > http://localhost:9830/[0:0] send> Accept-Language: en > http://localhost:9830/[0:0] send> Authorization: Basic \ > http://localhost:9830/[0:0] send> XXXXXXXXXXXXXXX= \ > http://localhost:9830/[0:0] send> > http://localhost:9830/[0:0] send> > http://localhost:9830/[0:0] recv> HTTP/1.1 200 OK > http://localhost:9830/[0:0] recv> Date: Wed, 07 Oct 2009 20:18:23 GMT > http://localhost:9830/[0:0] recv> Server: Apache/2.2 > HttpChannel.invoke: admin version = 2.2 > http://localhost:9830/[0:0] recv> Admin-Server: 389-Administrator/1.1.8 > HttpChannel.invoke: admin version = 1.1.8 > http://localhost:9830/[0:0] recv> Content-Length: 363 > http://localhost:9830/[0:0] recv> Connection: close > http://localhost:9830/[0:0] recv> Content-Type: text/html > http://localhost:9830/[0:0] recv> > http://localhost:9830/[0:0] recv> Reading 363 bytes... > http://localhost:9830/[0:0] recv> 363 bytes read > Console.replyHandler: adminVersion = 1.1.8 > ResourceSet: found in cache > loader9690857:com.netscape.management.client.console.console > ResourceSet: found in cache > loader9690857:com.netscape.management.client.console.console > ResourceSet: found in cache > loader9690857:com.netscape.management.client.console.console > ResourceSet: found in cache > loader9690857:com.netscape.management.client.console.console > ResourceSet: found in cache > loader9690857:com.netscape.management.client.console.console > ResourceSet: found in cache > loader9690857:com.netscape.management.client.util.default > ClassLoaderUtil.getClass(com.netscape.admin.dirserv.roledit.ResEditorRoleInfo at fedora- > ds-1.2.jar) > ResourceSet: found in cache > loader9690857:com.netscape.management.client.util.default > ClassLoader: getLocalJarList():Unable to read /home/tfar/.389-console/patch/ > directory > ClassLoader:persistanceTable > LINE=mcc60.jar:mcc50.jar,mcc42.jar,mcc41.jar,mcc40.jar newJar=mcc60.jar > oldJars=mcc50.jar,mcc42.jar,mcc41.jar,mcc40.jar > ClassLoader:persistanceTable mcc50.jar use instead mcc60.jar > ClassLoader:persistanceTable mcc42.jar use instead mcc60.jar > ClassLoader:persistanceTable mcc41.jar use instead mcc60.jar > ClassLoader:persistanceTable mcc40.jar use instead mcc60.jar > ClassLoader:persistanceTable > LINE=nmclf60.jar:nmclf50.jar,nmclf42.jar,nmclf41.jar,nmclf40.jar > newJar=nmclf60.jar oldJars=nmclf50.jar,nmclf42.jar,nmclf41.jar,nmclf40.jar > ClassLoader:persistanceTable nmclf50.jar use instead nmclf60.jar > ClassLoader:persistanceTable nmclf42.jar use instead nmclf60.jar > ClassLoader:persistanceTable nmclf41.jar use instead nmclf60.jar > ClassLoader:persistanceTable nmclf40.jar use instead nmclf60.jar > ClassLoader: start parsing > ClassLoader:persistanceTable no manifest in fedora-admin-1.1.jar > ClassLoader:persistanceTable no backward-compatible in manifest for fedora- > ds-1.2.jar > ClassLoader:persistanceTable no manifest in fedora-admin-1.1_en.jar > ClassLoader:persistanceTable no manifest in fedora-ds-1.2_en.jar > ClassLoader: done > ClassLoader: classes.env found in fedora-ds-1.2.jar > ClassLoader: manifest loaded for fedora-ds-1.2.jar > ClassLoader: manifest: 0 entries found > ClassLoader: new LocalJarClassLoader fedora-ds-1.2.jar:{fedora-ds-1.2.jar > fedora-ds-1.2_en.jar } > ClassLoader: Create loader fedora-ds-1.2.jar > ClassLoader: > :loadClass():name:com.netscape.admin.dirserv.roledit.ResEditorRoleInfo > ClassLoader: > :loadClass():loading:com.netscape.admin.dirserv.roledit.ResEditorRoleInfo > ClassLoader: com/netscape/admin/dirserv/roledit/ResEditorRoleInfo.class found > in fedora-ds-1.2.jar > ClassLoader: > :loadClass():name:com.netscape.management.client.ug.IResourceEditorPage > ClassLoader: > :loadClass():loading:com.netscape.management.client.ug.IResourceEditorPage > ClassLoader: com/netscape/management/client/ug/IResourceEditorPage.class NOT > in fedora-ds-1.2.jar > ClassLoader: com/netscape/management/client/ug/IResourceEditorPage.class NOT > in fedora-ds-1.2_en.jar > ClassLoader: :loadClass():name:java.util.Observer > ClassLoader: :loadClass():name:javax.swing.JPanel > ClassLoader: :loadClass():loading:javax.swing.JPanel > ClassLoader: javax/swing/JPanel.class NOT in fedora-ds-1.2.jar > ClassLoader: javax/swing/JPanel.class NOT in fedora-ds-1.2_en.jar > ClassLoader: :loadClass():resolving > com.netscape.admin.dirserv.roledit.ResEditorRoleInfo > ClassLoaderUtil.getClass(com.netscape.admin.dirserv.roledit.ResEditorRoleMembers at fedora- > ds-1.2.jar) > ClassLoader: Loader fedora-ds-1.2.jar found in cache > ClassLoader: > :loadClass():name:com.netscape.admin.dirserv.roledit.ResEditorRoleMembers > ClassLoader: > :loadClass():loading:com.netscape.admin.dirserv.roledit.ResEditorRoleMembers > ClassLoader: com/netscape/admin/dirserv/roledit/ResEditorRoleMembers.class > found in fedora-ds-1.2.jar > ClassLoader: > :loadClass():name:com.netscape.admin.dirserv.roledit.ResEditorRadioPage > ClassLoader: > :loadClass():loading:com.netscape.admin.dirserv.roledit.ResEditorRadioPage > ClassLoader: com/netscape/admin/dirserv/roledit/ResEditorRadioPage.class found > in fedora-ds-1.2.jar > ClassLoader: > :loadClass():name:com.netscape.admin.dirserv.IDSResourceEditorPage > ClassLoader: > :loadClass():loading:com.netscape.admin.dirserv.IDSResourceEditorPage > ClassLoader: com/netscape/admin/dirserv/IDSResourceEditorPage.class found in > fedora-ds-1.2.jar > ClassLoader: :loadClass():name:java.lang.Object > ClassLoader: :loadClass():name:java.awt.event.ActionListener > ClassLoader: :loadClass():name:com.netscape.management.nmclf.SuiConstants > ClassLoader: :loadClass():loading:com.netscape.management.nmclf.SuiConstants > ClassLoader: com/netscape/management/nmclf/SuiConstants.class NOT in fedora- > ds-1.2.jar > ClassLoader: com/netscape/management/nmclf/SuiConstants.class NOT in fedora- > ds-1.2_en.jar > ClassLoader: :loadClass():resolving > com.netscape.admin.dirserv.roledit.ResEditorRoleMembers > ClassLoaderUtil.getClass(com.netscape.admin.dirserv.roledit.ResEditorRoleAccountPage at fedora- > ds-1.2.jar) > ClassLoader: Loader fedora-ds-1.2.jar found in cache > ClassLoader: > :loadClass():name:com.netscape.admin.dirserv.roledit.ResEditorRoleAccountPage > ClassLoader: > :loadClass():loading:com.netscape.admin.dirserv.roledit.ResEditorRoleAccountPage > ClassLoader: com/netscape/admin/dirserv/roledit/ResEditorRoleAccountPage.class > found in fedora-ds-1.2.jar > ClassLoader: > :loadClass():name:com.netscape.management.client.ug.DefaultResEditorPage > ClassLoader: > :loadClass():loading:com.netscape.management.client.ug.DefaultResEditorPage > ClassLoader: com/netscape/management/client/ug/DefaultResEditorPage.class NOT > in fedora-ds-1.2.jar > ClassLoader: com/netscape/management/client/ug/DefaultResEditorPage.class NOT > in fedora-ds-1.2_en.jar > ClassLoader: :loadClass():resolving > com.netscape.admin.dirserv.roledit.ResEditorRoleAccountPage > ResourceSet: found in cache > loader9690857:com.netscape.management.client.console.console > ResourceSet: found in cache > loader9690857:com.netscape.management.client.console.console > ResourceSet: found in cache > loader9690857:com.netscape.management.client.console.console > ClassLoaderUtil.getClass(com.netscape.admin.dirserv.cosedit.ResEditorCosInfo at fedora- > ds-1.2.jar) > ClassLoader: Loader fedora-ds-1.2.jar found in cache > ClassLoader: > :loadClass():name:com.netscape.admin.dirserv.cosedit.ResEditorCosInfo > ClassLoader: > :loadClass():loading:com.netscape.admin.dirserv.cosedit.ResEditorCosInfo > ClassLoader: com/netscape/admin/dirserv/cosedit/ResEditorCosInfo.class found > in fedora-ds-1.2.jar > ClassLoader: :loadClass():resolving > com.netscape.admin.dirserv.cosedit.ResEditorCosInfo > ClassLoaderUtil.getClass(com.netscape.admin.dirserv.cosedit.ResEditorCosAttributes at fedora- > ds-1.2.jar) > ClassLoader: Loader fedora-ds-1.2.jar found in cache > ClassLoader: > :loadClass():name:com.netscape.admin.dirserv.cosedit.ResEditorCosAttributes > ClassLoader: > :loadClass():loading:com.netscape.admin.dirserv.cosedit.ResEditorCosAttributes > ClassLoader: com/netscape/admin/dirserv/cosedit/ResEditorCosAttributes.class > found in fedora-ds-1.2.jar > ClassLoader: :loadClass():name:javax.swing.event.ListSelectionListener > ClassLoader: :loadClass():loading:javax.swing.event.ListSelectionListener > ClassLoader: javax/swing/event/ListSelectionListener.class NOT in fedora- > ds-1.2.jar > ClassLoader: javax/swing/event/ListSelectionListener.class NOT in fedora- > ds-1.2_en.jar > ClassLoader: :loadClass():resolving > com.netscape.admin.dirserv.cosedit.ResEditorCosAttributes > ClassLoaderUtil.getClass(com.netscape.admin.dirserv.cosedit.ResEditorCosTemplate at fedora- > ds-1.2.jar) > ClassLoader: Loader fedora-ds-1.2.jar found in cache > ClassLoader: > :loadClass():name:com.netscape.admin.dirserv.cosedit.ResEditorCosTemplate > ClassLoader: > :loadClass():loading:com.netscape.admin.dirserv.cosedit.ResEditorCosTemplate > ClassLoader: com/netscape/admin/dirserv/cosedit/ResEditorCosTemplate.class > found in fedora-ds-1.2.jar > ClassLoader: :loadClass():resolving > com.netscape.admin.dirserv.cosedit.ResEditorCosTemplate > ResourceSet: found in cache > loader9690857:com.netscape.management.client.console.console > ResourceSet: found in cache > loader9690857:com.netscape.management.client.console.console > . > . 20 times > > loader9690857:com.netscape.management.client.topology.topology > ResourceSet: found in cache > loader9690857:com.netscape.management.client.topology.topology > ResourceSet: found in cache > loader9690857:com.netscape.management.client.theme.theme > RemoteImage: found in cache > loader9690857:com/netscape/management/client/theme/images/logo16.gif > RemoteImage: NOT found in cache > loader9690857:com/netscape/management/client/theme/images/ConsoleBanner.gif > RemoteImage: NOT found in cache > loader9690857:com/netscape/management/client/images/warn16.gif > ResourceSet: NOT found in cache > loader9690857:com.netscape.management.client.default > UIPermissions: TopologyEditing yes > ResourceSet: found in cache > loader9690857:com.netscape.management.client.topology.topology > ResourceSet: found in cache > loader9690857:com.netscape.management.client.topology.topology > ResourceSet: found in cache > loader9690857:com.netscape.management.client.default > ResourceSet: found in cache > loader9690857:com.netscape.management.client.topology.topology > ResourceSet: found in cache > loader9690857:com.netscape.management.client.topology.topology > UIPermissions: CustomViewEditing yes > ResourceSet: found in cache > loader9690857:com.netscape.management.client.default > ResourceSet: found in cache > loader9690857:com.netscape.management.client.theme.theme > ResourceSet: found in cache > loader9690857:com.netscape.management.client.default > ResourceSet: found in cache > loader9690857:com.netscape.management.client.topology.topology > ResourceSet: found in cache > loader9690857:com.netscape.management.client.topology.topology > RemoteImage: NOT found in cache > loader9690857:com/netscape/management/client/topology/images/domain16.gif > TRACE ConsoleInfo.clone: tracking cloning of ConsoleInfo for performance > tuning > ResourceSet: found in cache > loader9690857:com.netscape.management.client.console.console > ResourceSet: found in cache > loader9690857:com.netscape.management.client.topology.topology > RemoteImage: NOT found in cache > loader9690857:com/netscape/management/client/topology/images/host16.gif > ResourceSet: found in cache > loader9690857:com.netscape.management.client.topology.topology > UIPermissions: UGTabVisibility yes > UIPermissions: UGEditing yes > ResourceSet: found in cache > loader9690857:com.netscape.management.client.topology.topology > TRACE ConsoleInfo.clone: tracking cloning of ConsoleInfo for performance > tuning > pub defaultView=null > user defaultView=null > RemoteImage: NOT found in cache > loader9690857:com/netscape/management/client/images/notsecure.gif > ResourceSet: found in cache > loader9690857:com.netscape.management.client.topology.topology > JButtonFactory: button width = 90 > . > . 20 times > . > topology.NodeDataPanel ancestorAdded() adds Change Listener > http://localhost:9830/[0:0] close> Closed > TRACE ConsoleInfo.clone: tracking cloning of ConsoleInfo for performance > tuning > ResourceSet: found in cache > loader9690857:com.netscape.management.client.topology.topology > RemoteImage: NOT found in cache > loader9690857:com/netscape/management/nmclf/icons/user24.gif > RemoteImage: NOT found in cache > loader9690857:com/netscape/management/nmclf/icons/group24.gif > RemoteImage: NOT found in cache > loader9690857:com/netscape/management/nmclf/icons/ou24.gif > JButtonFactory: button width = 54 > . > . 20 times > . > ResourceSet: NOT found in cache > loader9690857:com.netscape.management.client.ug.PickerEditorResource > ResourceSet: found in cache > loader9690857:com.netscape.management.client.ug.PickerEditorResource > ResourceSet: found in cache > loader9690857:com.netscape.management.client.ug.PickerEditorResource > RemoteImage: NOT found in cache > loader9690857:com/netscape/management/nmclf/icons/user.gif > RemoteImage: NOT found in cache > loader9690857:com/netscape/management/nmclf/icons/group.gif > RemoteImage: NOT found in cache > loader9690857:com/netscape/management/nmclf/icons/ou.gif > JButtonFactory: button width = 90 > JButtonFactory: button height = 18 > JButtonFactory: button width = 90 > JButtonFactory: button height = 18 > JButtonFactory: button width = 72 > JButtonFactory: button height = 18 > JButtonFactory: button width = 72 > JButtonFactory: button height = 18 > topology.NodeDataPanel ancestorRemoved() removes Change Listener > ResourceSet: found in cache > loader9690857:com.netscape.management.client.topology.topology > JButtonFactory: button width = 54 > JButtonFactory: button height = 18 > . > . 20 times > . > ResourceSet: found in cache > loader9690857:com.netscape.management.client.console.console > ResourceSet: found in cache > loader9690857:com.netscape.management.client.console.console > ResourceSet: found in cache > loader9690857:com.netscape.management.client.console.console > ResourceSet: found in cache > loader9690857:com.netscape.management.client.console.console > ResourceSet: found in cache > loader9690857:com.netscape.management.client.console.console > ResourceSet: found in cache > loader9690857:com.netscape.management.client.console.console > TRACE ConsoleInfo.clone: tracking cloning of ConsoleInfo for performance > tuning > ResourceSet: found in cache > loader9690857:com.netscape.management.client.ug.PickerEditorResource > ResourceSet: found in cache > loader9690857:com.netscape.management.client.ug.PickerEditorResource > ResourceSet: found in cache > loader9690857:com.netscape.management.client.ug.PickerEditorResource > JButtonFactory: button width = 108 > JButtonFactory: button height = 18 > JButtonFactory: button width = 90 > JButtonFactory: button height = 18 > ResourceSet: found in cache > loader9690857:com.netscape.management.client.ug.PickerEditorResource > ResourceSet: found in cache > loader9690857:com.netscape.management.client.ug.PickerEditorResource > . > . 50 times > . > ResourceEditor.valueChanged: > o=com.netscape.management.client.ug.OUPage[,0,0,0x0,invalid,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=] > RemoteImage: found in cache > loader9690857:com/netscape/management/nmclf/icons/ou24.gif > ResourceEditor.update: o=ResourcePageObservable: > newUser=true > sBaseDN=dc=smc, dc=co, dc=nz > objectClassList=top organizationalunit posixuser > attributes={objectclass=LDAPAttribute {type='objectclass', > values='top,organizationalunit,posixuser'}} > attrAdd=AttributeValuePair: objectclass LDAPAttribute > {type='objectclass', values='top,organizationalunit,posixuser'} > attrReplace= > attrDelete= > entry=null > arg=aliasedobjectname > ResourceEditor.update: o=ResourcePageObservable: > newUser=true > sBaseDN=dc=smc, dc=co, dc=nz > objectClassList=top organizationalunit posixuser > attributes={ou=LDAPAttribute {type='ou', values='Computers'}, > objectclass=LDAPAttribute {type='objectclass', > values='top,organizationalunit,posixuser'}} > attrAdd=AttributeValuePair: objectclass LDAPAttribute > {type='objectclass', values='top,organizationalunit,posixuser'} > AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} > attrReplace= > attrDelete= > entry=null > arg=ou > ResourceEditor.update: o=ResourcePageObservable: > newUser=true > sBaseDN=dc=smc, dc=co, dc=nz > objectClassList=top organizationalunit posixuser > attributes={ou=LDAPAttribute {type='ou', values='Computers'}, > objectclass=LDAPAttribute {type='objectclass', > values='top,organizationalunit,posixuser'}} > attrAdd=AttributeValuePair: objectclass LDAPAttribute > {type='objectclass', values='top,organizationalunit,posixuser'} > AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} > attrReplace= > attrDelete= > entry=null > arg=description > ResourceEditor.update: o=ResourcePageObservable: > newUser=true > sBaseDN=dc=smc, dc=co, dc=nz > objectClassList=top organizationalunit posixuser > attributes={ou=LDAPAttribute {type='ou', values='Computers'}, > objectclass=LDAPAttribute {type='objectclass', > values='top,organizationalunit,posixuser'}} > attrAdd=AttributeValuePair: objectclass LDAPAttribute > {type='objectclass', values='top,organizationalunit,posixuser'} > AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} > attrReplace= > attrDelete= > entry=null > arg=telephonenumber > ResourceEditor.update: o=ResourcePageObservable: > newUser=true > sBaseDN=dc=smc, dc=co, dc=nz > objectClassList=top organizationalunit posixuser > attributes={ou=LDAPAttribute {type='ou', values='Computers'}, > objectclass=LDAPAttribute {type='objectclass', > values='top,organizationalunit,posixuser'}} > attrAdd=AttributeValuePair: objectclass LDAPAttribute > {type='objectclass', values='top,organizationalunit,posixuser'} > AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} > attrReplace= > attrDelete= > entry=null > arg=facsimiletelephonenumber > ResourceEditor.update: o=ResourcePageObservable: > newUser=true > sBaseDN=dc=smc, dc=co, dc=nz > objectClassList=top organizationalunit posixuser > attributes={ou=LDAPAttribute {type='ou', values='Computers'}, > objectclass=LDAPAttribute {type='objectclass', > values='top,organizationalunit,posixuser'}} > attrAdd=AttributeValuePair: objectclass LDAPAttribute > {type='objectclass', values='top,organizationalunit,posixuser'} > AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} > attrReplace= > attrDelete= > entry=null > arg=registeredaddress > ResourceEditor.update: o=ResourcePageObservable: > newUser=true > sBaseDN=dc=smc, dc=co, dc=nz > objectClassList=top organizationalunit posixuser > attributes={ou=LDAPAttribute {type='ou', values='Computers'}, > objectclass=LDAPAttribute {type='objectclass', > values='top,organizationalunit,posixuser'}} > attrAdd=AttributeValuePair: objectclass LDAPAttribute > {type='objectclass', values='top,organizationalunit,posixuser'} > AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} > attrReplace= > attrDelete= > entry=null > arg=aliasedobjectname;lang-af > ResourceEditor.update: o=ResourcePageObservable: > newUser=true > sBaseDN=dc=smc, dc=co, dc=nz > objectClassList=top organizationalunit posixuser > attributes={ou=LDAPAttribute {type='ou', values='Computers'}, > objectclass=LDAPAttribute {type='objectclass', > values='top,organizationalunit,posixuser'}} > attrAdd=AttributeValuePair: objectclass LDAPAttribute > {type='objectclass', values='top,organizationalunit,posixuser'} > AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} > attrReplace= > attrDelete= > entry=null > arg=description;lang-af > ResourceEditor.update: o=ResourcePageObservable: > newUser=true > sBaseDN=dc=smc, dc=co, dc=nz > objectClassList=top organizationalunit posixuser > attributes={ou=LDAPAttribute {type='ou', values='Computers'}, > objectclass=LDAPAttribute {type='objectclass', > values='top,organizationalunit,posixuser'}} > attrAdd=AttributeValuePair: objectclass LDAPAttribute > {type='objectclass', values='top,organizationalunit,posixuser'} > AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} > attrReplace= > attrDelete= > entry=null > arg=telephonenumber;lang-af > ResourceEditor.update: o=ResourcePageObservable: > newUser=true > sBaseDN=dc=smc, dc=co, dc=nz > objectClassList=top organizationalunit posixuser > attributes={ou=LDAPAttribute {type='ou', values='Computers'}, > objectclass=LDAPAttribute {type='objectclass', > values='top,organizationalunit,posixuser'}} > attrAdd=AttributeValuePair: objectclass LDAPAttribute > {type='objectclass', values='top,organizationalunit,posixuser'} > AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} > attrReplace= > attrDelete= > entry=null > arg=facsimiletelephonenumber;lang-af > ResourceEditor.update: o=ResourcePageObservable: > newUser=true > sBaseDN=dc=smc, dc=co, dc=nz > objectClassList=top organizationalunit posixuser > attributes={ou=LDAPAttribute {type='ou', values='Computers'}, > objectclass=LDAPAttribute {type='objectclass', > values='top,organizationalunit,posixuser'}} > attrAdd=AttributeValuePair: objectclass LDAPAttribute > {type='objectclass', values='top,organizationalunit,posixuser'} > AttributeValuePair: ou LDAPAttribute {type='ou', values='Computers'} > attrReplace= > attrDelete= > entry=null > arg=registeredaddress;lang-af > ResourcePageObservable.java:ADD LDAP ENTRY:unknown object class "posixuser" > for ou=Computers,dc=smc, dc=co, dc=nz > JButtonFactory: button width = 54 > JButtonFactory: button height = 18 > JButtonFactory: button width = 54 > JButtonFactory: button height = 18 > JButtonFactory: button width = 54 > JButtonFactory: button height = 18 > JButtonFactory: button width = 54 > JButtonFactory: button height = 18 > netscape.ldap.LDAPException: error result (65); unknown object class > "posixuser" > ; Object class violation > at netscape.ldap.LDAPConnection.checkMsg(Unknown Source) > at netscape.ldap.LDAPConnection.add(Unknown Source) > at netscape.ldap.LDAPConnection.add(Unknown Source) > at netscape.ldap.LDAPConnection.add(Unknown Source) > at > com.netscape.management.client.ug.ResourcePageObservable.save(Unknown Source) > at > com.netscape.management.client.ug.ResourceEditor.processEvent(Unknown Source) > at > com.netscape.management.client.ug.ResourceEditor.actionPerformed(Unknown > Source) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2012) > at > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2335) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:404) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:253) > at java.awt.Component.processMouseEvent(Component.java:6101) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3276) > at java.awt.Component.processEvent(Component.java:5866) > at java.awt.Container.processEvent(Container.java:2105) > at java.awt.Component.dispatchEventImpl(Component.java:4462) > at java.awt.Container.dispatchEventImpl(Container.java:2163) > at java.awt.Component.dispatchEvent(Component.java:4288) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4461) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:4125) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4055) > at java.awt.Container.dispatchEventImpl(Container.java:2149) > at java.awt.Window.dispatchEventImpl(Window.java:2478) > at java.awt.Component.dispatchEvent(Component.java:4288) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:604) > at > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275) > at > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200) > at > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:194) > at java.awt.Dialog$1.run(Dialog.java:1072) > at java.awt.Dialog$3.run(Dialog.java:1126) > at java.security.AccessController.doPrivileged(Native Method) > at java.awt.Dialog.show(Dialog.java:1124) > at com.netscape.management.client.util.AbstractDialog.show(Unknown > Source) > at > com.netscape.management.client.util.AbstractDialog.showModal(Unknown Source) > at > com.netscape.management.client.topology.ug.EditUserGroupPane.createEntry(Unknown > Source) > at > com.netscape.management.client.topology.ug.EditUserGroupPane.actionPerformed(Unknown > Source) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2012) > at > javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2335) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:404) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) > at javax.swing.AbstractButton.doClick(AbstractButton.java:374) > at > javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1688) > at > javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1732) > at java.awt.Component.processMouseEvent(Component.java:6101) > at javax.swing.JComponent.processMouseEvent(JComponent.java:3276) > at java.awt.Component.processEvent(Component.java:5866) > at java.awt.Container.processEvent(Container.java:2105) > at java.awt.Component.dispatchEventImpl(Component.java:4462) > at java.awt.Container.dispatchEventImpl(Container.java:2163) > at java.awt.Component.dispatchEvent(Component.java:4288) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4461) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:4125) > at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4055) > at java.awt.Container.dispatchEventImpl(Container.java:2149) > at java.awt.Window.dispatchEventImpl(Window.java:2478) > at java.awt.Component.dispatchEvent(Component.java:4288) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:604) > at > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275) > at > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:138) > ResourceSet: found in cache > loader9690857:com.netscape.management.client.util.default > ResourceSet: found in cache > loader9690857:com.netscape.management.client.util.default > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From tfar at smc.co.nz Wed Oct 7 23:46:05 2009 From: tfar at smc.co.nz (Anthony M. Farrell) Date: Thu, 8 Oct 2009 12:46:05 +1300 Subject: [389-users] Problem creating new Organizational Unit In-Reply-To: <4ACD1FCA.7010505@redhat.com> References: <200910071831.19176.tfar@smc.co.nz> <200910081139.23790.tfar@smc.co.nz> <4ACD1FCA.7010505@redhat.com> Message-ID: <200910081246.05951.tfar@smc.co.nz> On Thu, 08 Oct 2009 12:10:02 Rich Megginson wrote: > Note that it is the objectclass "posixAccount" not "posixUser". Did you > manually add an objectclass named posixUser to something? > I don't recollect adding class posixUser to anything but it is possible when I was trying to work out how to best implement Unix groups that I did something unwise. I normally keep a record of changes as I go and I have no record of this. Here is the result of the ldapsearch command: nsClassname: com.netscape.management.client.ug.ResEditorPosixUser nsDefaultObjectClass: posixuser -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From rmeggins at redhat.com Thu Oct 8 00:19:08 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 07 Oct 2009 18:19:08 -0600 Subject: [389-users] Problem creating new Organizational Unit In-Reply-To: <200910081246.05951.tfar@smc.co.nz> References: <200910071831.19176.tfar@smc.co.nz> <200910081139.23790.tfar@smc.co.nz> <4ACD1FCA.7010505@redhat.com> <200910081246.05951.tfar@smc.co.nz> Message-ID: <4ACD2FFC.4040504@redhat.com> Anthony M. Farrell wrote: > On Thu, 08 Oct 2009 12:10:02 Rich Megginson wrote: > >> Note that it is the objectclass "posixAccount" not "posixUser". Did you >> manually add an objectclass named posixUser to something? >> >> > > I don't recollect adding class posixUser to anything but it is possible when I > was trying to work out how to best implement Unix groups that I did something > unwise. I normally keep a record of changes as I go and I have no record of > this. > > Here is the result of the ldapsearch command: > > nsClassname: com.netscape.management.client.ug.ResEditorPosixUser > nsDefaultObjectClass: posixuser > /usr/lib/mozldap/ldapsearch -D "cn=directory manager" -w password -b o=netscaperoot "(nsDefaultObjectClass=posixuser)" This will print the entry that contains the nsDefaultObjectClass: posixuser Then delete that value: /usr/lib/mozldap/ldapmodify -D "cn=directory manager" -w password dn: dn of that entry changetype: modify delete: nsDefaultObjectClass nsDefaultObjectClass: posixuser Press Enter twice to send the command, then Ctrl-C or Ctrl-D to exit ldapmodify. I'm not sure how that posixuser got in there - that's really weird. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From tfar at smc.co.nz Thu Oct 8 00:56:51 2009 From: tfar at smc.co.nz (Anthony M. Farrell) Date: Thu, 8 Oct 2009 13:56:51 +1300 Subject: [389-users] Problem creating new Organizational Unit ** FIXED ** In-Reply-To: <4ACD2FFC.4040504@redhat.com> References: <200910071831.19176.tfar@smc.co.nz> <200910081246.05951.tfar@smc.co.nz> <4ACD2FFC.4040504@redhat.com> Message-ID: <200910081356.51811.tfar@smc.co.nz> On Thu, 08 Oct 2009 13:19:08 Rich Megginson wrote: That did it. The OU entry is now created. Thanks very much Rich I appreciate your help. I have no idea how the posixuser got there. I must have done it but I am sure I went nowhere near netscaperoot. However it was a good learning exercise thanks to you. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ankur_agwal at yahoo.com Thu Oct 8 08:29:03 2009 From: ankur_agwal at yahoo.com (Ankur Agarwal) Date: Thu, 8 Oct 2009 01:29:03 -0700 (PDT) Subject: [389-users] Read data immediately after write Message-ID: <741981.83246.qm@web58907.mail.re1.yahoo.com> Hi, ? I have a master-slave set-up with write operations always being done to the master node. Now there is an issue where i need to read some data immediately after write, and my read request goes to the slave. It fails in cases when replication hasnt happened from master to slave before this read operation. ? Is there a LDAP level configuration to handle this situation? Can chaining help in this case? ? Any help would be appreciated. Cheers, Ankur -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Thu Oct 8 08:38:40 2009 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Thu, 08 Oct 2009 10:38:40 +0200 Subject: [389-users] Read data immediately after write In-Reply-To: <741981.83246.qm@web58907.mail.re1.yahoo.com> References: <741981.83246.qm@web58907.mail.re1.yahoo.com> Message-ID: <4ACDA510.4010509@stroeder.com> Ankur Agarwal wrote: > > I have a master-slave set-up with write operations always being done to > the master node. Now there is an issue where i need to read some data > immediately after write, and my read request goes to the slave. It fails > in cases when replication hasnt happened from master to slave before > this read operation. You simply should not do that. Read from the master if you have to rely on the consistency of what you recently wrote to the master. > Is there a LDAP level configuration to handle this situation? > Can chaining help in this case? No. (Except chaining the read requests of the writing client to the master which you don't want I guess). Ciao, Michael. From emmanuel.billot at ird.fr Thu Oct 8 13:45:46 2009 From: emmanuel.billot at ird.fr (Emmanuel BILLOT) Date: Thu, 08 Oct 2009 15:45:46 +0200 Subject: [389-users] Windows Sync with multiple sub DIT Message-ID: <4ACDED0A.4040109@ird.fr> Hi, We use 389DS and AD with a Winsync method. Our LDAP DIT : * dc=toutou,dc=fr ** dc=orleans,dc=toutou,dc=fr *** ou=people,dc=orleans,dc=toutou,dc=fr *** ou=group,dc=orleans,dc=toutou,dc=fr ** dc=bondy,dc=toutou,dc=fr *** ou=people,dc=bondy,dc=toutou,dc=fr *** ou=group,dc=bondy,dc=toutou,dc=fr Our AD DIT : * dc=toutou,dc=org ** ou=orleans,dc=toutou,dc=org *** ou=utilisateurs, ou=toutou, dc=ird,dc=org *** ou=groupes, ou=toutou,dc=ird,dc=org One can see some OU names are different, such as DIT root. So we cretaed a sync agrement as ou=people,dc=orleans,dc=toutou,dc=fr --- ou=utilisateurs, ou=toutou, dc=ird,dc=org All seems to be ok. However, we need to sync other subtrees, like ou=people,dc=bondy,dc=toutou,dc=fr It seems 389DS wants to syncronize high level entries which are not specified in the agrement. As it tries to do it for each sub agrement, failure occurs with a duplicate value error. How can we do ? Log [08/Oct/2009:15:26:31 +0200] NSMMReplicationPlugin - agmt="cn=win bdy" (maqsvrdc0001:636): Replica has no update vector. It has never been initialized. [08/Oct/2009:15:26:33 +0200] NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=win bdy" (maqsvrdc0001:636)". [08/Oct/2009:15:26:33 +0200] - add value "" to attribute type "ARecord" in entry "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=toutou,DC=org" failed: duplicate new value [08/Oct/2009:15:26:34 +0200] NSMMReplicationPlugin - Finished total update of replica "agmt="cn=win bdy" (maqsvrdc0001:636)". Sent 0 entries. -- ========================================== Emmanuel BILLOT IRD - Orl?ans D?l?gation aux Syst?mes d'Information (DSI) t?l : 02 38 49 95 88 ========================================== From jfenal at gmail.com Thu Oct 8 18:37:04 2009 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Thu, 8 Oct 2009 20:37:04 +0200 Subject: [389-users] Windows Sync with multiple sub DIT In-Reply-To: <4ACDED0A.4040109@ird.fr> References: <4ACDED0A.4040109@ird.fr> Message-ID: <40a14bc10910081137o16d6148cy9f5efd7ca3538870@mail.gmail.com> 2009/10/8 Emmanuel BILLOT : > Hi, > > We use 389DS and AD with a Winsync method. > Our LDAP DIT : > * dc=toutou,dc=fr > ** dc=orleans,dc=toutou,dc=fr > *** ou=people,dc=orleans,dc=toutou,dc=fr > *** ou=group,dc=orleans,dc=toutou,dc=fr > ** dc=bondy,dc=toutou,dc=fr > *** ou=people,dc=bondy,dc=toutou,dc=fr > *** ou=group,dc=bondy,dc=toutou,dc=fr > > Our AD DIT : > * dc=toutou,dc=org > ** ou=orleans,dc=toutou,dc=org > *** ou=utilisateurs, ou=toutou, dc=ird,dc=org > *** ou=groupes, ou=toutou,dc=ird,dc=org > > One can see some OU names are different, such as DIT root. > > So we cretaed a sync agrement as > ou=people,dc=orleans,dc=toutou,dc=fr --- ou=utilisateurs, ou=toutou, > dc=ird,dc=org > > All seems to be ok. > > However, we need to sync other subtrees, like > ou=people,dc=bondy,dc=toutou,dc=fr > It seems 389DS wants to syncronize high level entries which are not > specified in the agrement. As it tries to do it for each sub agrement, > failure occurs with a duplicate value error. > > How can we do ? Replication is set for an entire database. So I guess you'd need to host a sub-ou on a different database to enable a Windows sync on this particular sub-ou. http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_Replication.html#Replication_Overview-Unit_of_Replication Regards, J. From rmeggins at redhat.com Fri Oct 9 14:41:33 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 09 Oct 2009 08:41:33 -0600 Subject: [389-users] Announcing testing release of 389 1.2.3 Message-ID: <4ACF4B9D.7060301@redhat.com> The 389 team is pleased to announce that the 389 Directory Server version 1.2.3 is available for testing. The packages are available from the testing repositories, not the official release repositories yet. We are seeking feedback. The two new packages available for testing are: * 389-ds-base-1.2.3 * 389-admin-1.1.9 Instructions for installing these from the testing repositories: yum install --enablerepo=updates-testing 389-ds # Fedora new install yum upgrade --enablerepo=updates-testing 389-ds-base 389-admin 389-console # Fedora upgrade or EL5 yum install --enablerepo=dirsrv-testing --enablerepo=idmcommon-testing 389-ds # new install yum upgrade --enablerepo=dirsrv-testing --enablerepo=idmcommon-testing 389-ds-base 389-admin 389-console # upgrade See http://directory.fedoraproject.org/wiki/Download for more information about setting up yum access. Release Notes: http://directory.fedoraproject.org/wiki/Release_Notes Install Guide: http://directory.fedoraproject.org/wiki/Install_Guide Download: http://directory.fedoraproject.org/wiki/Download === Notes === NOTE: If using the FC6 (EL5) packages, _you must update your yum repo files_ - the URLs have changed. See http://directory.fedoraproject.org/wiki/Download for more information. NOTE: Fedora versions below 10 are no longer supported. If you are running Fedora 9 or earlier, you should upgrade. NOTE: This release is branded as '''389'''. All of the RPMs have been marked as obsoleting their Fedora DS counterparts. When upgrading via yum, you must use yum '''upgrade''' (not update) so that the obsoletes will be processed. NOTE: If you are using the console, after installing the updates, you must run '''setup-ds-admin.pl -u''' to refresh your console and admin server configuration with the new version information. 1.2.3 fixes some bugs related to update - it will remove old Fedora servers from the console, and will preserve TLS/SSL configuration. See the buglist below. NOTE: '''389-console''' is the command to run the console. This replaces fedora-idm-console. === New features === * Ability to set resource limits (sizelimit, timelimit, look through limit) specifically for anonymous connections ** This is useful when you want to have different limits for regular users and anonymous users ** Set the attribute '''nsslapd-anonlimitsdn''' in cn=config to the DN of the entry that you want to use as the "template" entry. This is a dummy entry that you have to create. Then you set whatever resource limits you want to apply to anonymous to that dummy entry, and those limits will apply to anonymous users. * Access based on the security strength of the connection ** There is a new ACI keyword - '''minssf''' - this allows you to set access control based on how secure the connection is ** There is a global server setting in cn=config - '''nsslapd-minssf''' - that allows you to reject operations based on how secure the connection is * Ability to shut off anonymous access ** This adds a new config switch in cn=config - '''nsslapd-allow-anonymous-access''' - that allows one to restrict all anonymous access. When this is enabled, the connection dispatch code will only allow BIND operations through for an unauthenticated user. The BIND code will only allow the operation through if it's not an anonymous or unauthenticated BIND. === Bugs Fixed === This release contains several bug fixes. The complete list of bugs fixed is found at the link below. Note that bugs marked as MODIFIED have been fixed but are still in testing. * Tracking bug for 1.2.3 release - [https://bugzilla.redhat.com/showdependencytree.cgi?id=519216&hide_resolved=0 https://bugzilla.redhat.com/showdependencytree.cgi?id=519216&hide_resolved=0] -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From emmanuel.billot at ird.fr Fri Oct 9 14:56:19 2009 From: emmanuel.billot at ird.fr (Emmanuel BILLOT) Date: Fri, 09 Oct 2009 16:56:19 +0200 Subject: [389-users] Windows Sync with multiple sub DIT In-Reply-To: <40a14bc10910081137o16d6148cy9f5efd7ca3538870@mail.gmail.com> References: <4ACDED0A.4040109@ird.fr> <40a14bc10910081137o16d6148cy9f5efd7ca3538870@mail.gmail.com> Message-ID: <4ACF4F13.3030003@ird.fr> J?r?me Fenal a ?crit : > 2009/10/8 Emmanuel BILLOT : > >> Hi, >> >> We use 389DS and AD with a Winsync method. >> Our LDAP DIT : >> * dc=toutou,dc=fr >> ** dc=orleans,dc=toutou,dc=fr >> *** ou=people,dc=orleans,dc=toutou,dc=fr >> *** ou=group,dc=orleans,dc=toutou,dc=fr >> ** dc=bondy,dc=toutou,dc=fr >> *** ou=people,dc=bondy,dc=toutou,dc=fr >> *** ou=group,dc=bondy,dc=toutou,dc=fr >> >> Our AD DIT : >> * dc=toutou,dc=org >> ** ou=orleans,dc=toutou,dc=org >> *** ou=utilisateurs, ou=toutou, dc=ird,dc=org >> *** ou=groupes, ou=toutou,dc=ird,dc=org >> >> One can see some OU names are different, such as DIT root. >> >> So we cretaed a sync agrement as >> ou=people,dc=orleans,dc=toutou,dc=fr --- ou=utilisateurs, ou=toutou, >> dc=ird,dc=org >> >> All seems to be ok. >> >> However, we need to sync other subtrees, like >> ou=people,dc=bondy,dc=toutou,dc=fr >> It seems 389DS wants to syncronize high level entries which are not >> specified in the agrement. As it tries to do it for each sub agrement, >> failure occurs with a duplicate value error. >> >> How can we do ? >> > > Replication is set for an entire database. > So I guess you'd need to host a sub-ou on a different database to > enable a Windows sync on this particular sub-ou. > > http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_Replication.html#Replication_Overview-Unit_of_Replication > > Regards, > Ok i wil try this. However, what are those specific entries that DS tries to synchronize ? Why does it not uses only the defined subtrees ? Does it mean that in case of a DIT wich contains several OU with Users and Groups, we have to split in "small" DB for Winsync ? > J. > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -- ========================================== Emmanuel BILLOT IRD - Orl?ans D?l?gation aux Syst?mes d'Information (DSI) t?l : 02 38 49 95 88 ========================================== From ankur_agwal at yahoo.com Fri Oct 9 19:17:20 2009 From: ankur_agwal at yahoo.com (Ankur Agarwal) Date: Fri, 9 Oct 2009 12:17:20 -0700 (PDT) Subject: [389-users] Read data immediately after write In-Reply-To: <4ACDA510.4010509@stroeder.com> Message-ID: <736468.43819.qm@web58904.mail.re1.yahoo.com> Can i use chaining between master-slave without having different "ou"? I mean if i have exactly same directory structure and same set of OUs can i still have chaining between master and slave? Cheers, Ankur --- On Thu, 10/8/09, Michael Str?der wrote: From: Michael Str?der Subject: Re: [389-users] Read data immediately after write To: "General discussion list for the 389 Directory server project." Date: Thursday, October 8, 2009, 1:38 AM Ankur Agarwal wrote: > > I have a master-slave set-up with write operations always being done to > the master node. Now there is an issue where i need to read some data > immediately after write, and my read request goes to the slave. It fails > in cases when replication hasnt happened from master to slave before > this read operation. You simply should not do that. Read from the master if you have to rely on the consistency of what you recently wrote to the master. > Is there a LDAP level configuration to handle this situation? > Can chaining help in this case? No. (Except chaining the read requests of the writing client to the master which you don't want I guess). Ciao, Michael. -- 389 users mailing list 389-users at redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From emmanuel.billot at ird.fr Mon Oct 12 11:28:05 2009 From: emmanuel.billot at ird.fr (Emmanuel BILLOT) Date: Mon, 12 Oct 2009 13:28:05 +0200 Subject: [389-users] Windows Sync precision Message-ID: <4AD312C5.3080106@ird.fr> Hi, I'm currently on fight with AD replication and synchronization. I need to know if a non default synchronization (as it is porposed in the agrment assistant) is possible. I mean, is it possible to synchronize - users in this case : ou=people,dc=toutou,dc=tagada,dc=org (DS) with ou=utilisateurs,ou=toutou,dc=tagada,dc=fr (AD) and groups like this ou=group,dc=toutou,dc=tagada,dc=org (DS) with ou=groupes,ou=toutou,dc=tagada,dc=fr (AD) Note that OU are different, suffix are different too. I had ti create two different agrements because of OU naming (people vs utilisateurs and group vs groupes), so one agrement for each object type. I succeed in synchronizing users, but for groups, i have an error : dn="" or dn="CN=pfffff,OU=groupes,OU=ORLEANS,DC=maqird,DC=fr" [12/Oct/2009:11:58:03 +0200] NSMMReplicationPlugin - agmt="cn=orl_group" (maqsvrdc0001:636): windows_replay_update: Processing modify operation local dn="cn=pfffff,ou=group,dc=orleans,dc=ird,dc=fr" remote dn="" [12/Oct/2009:11:58:03 +0200] - map_dn_values: this entry is not ours uid=aubertin,ou=People,dc=orleans,dc=ird,dc=fr [12/Oct/2009:11:58:03 +0200] agmt="cn=orl_group" (maqsvrdc0001:636) - clcache_load_buffer: rc=-30989 [12/Oct/2009:11:58:03 +0200] NSMMReplicationPlugin - agmt="cn=orl_group" (maqsvrdc0001:636): No more updates to send (cl5GetNextOperationToReplay) It seems that the agrement does not recognize the user entry because it is stored in a different subtree (the subtree for agrement is ou=group,dc=orleans,dc=ird,dc=fr, the subtree for user is ou=people,dc=orleans,dc=ird,dc=fr). Is it right ? Users and Group synch is it only possible when users and groups are in the same agrement ? If true, how can we do if OU naming is so different ? I hope somebody will answer, BR, -- ========================================== Emmanuel BILLOT IRD - Orl?ans D?l?gation aux Syst?mes d'Information (DSI) t?l : 02 38 49 95 88 ========================================== From mitja.mihelic at arnes.si Mon Oct 12 15:23:43 2009 From: mitja.mihelic at arnes.si (=?UTF-8?B?TWl0amEgTWloZWxpxI0=?=) Date: Mon, 12 Oct 2009 17:23:43 +0200 Subject: [389-users] db2ldif as non root user Message-ID: <4AD349FF.6000905@arnes.si> Greetings all fellow Fedora Directory Server users! Is it possible to dump the database to an LDIF file as a non-root user ? I have no problem doing this as root. I would like to run /usr/lib/dirsrv/slapd-example/db2ldif -a /tmp/dbdump.ldif -n userRoot from a remote machine via ssh and I would really like to avoid connecting to the machine as root. Has anyone had any experience in doing this if it is at all possible ? Thank you. From rmeggins at redhat.com Mon Oct 12 15:51:29 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 12 Oct 2009 09:51:29 -0600 Subject: [389-users] db2ldif as non root user In-Reply-To: <4AD349FF.6000905@arnes.si> References: <4AD349FF.6000905@arnes.si> Message-ID: <4AD35081.5060502@redhat.com> Mitja Miheli? wrote: > Greetings all fellow Fedora Directory Server users! > > > Is it possible to dump the database to an LDIF file as a non-root user ? > > I have no problem doing this as root. > > I would like to run > /usr/lib/dirsrv/slapd-example/db2ldif -a /tmp/dbdump.ldif -n userRoot > from a remote machine via ssh and I would really like to avoid > connecting to the machine as root. > > Has anyone had any experience in doing this if it is at all possible ? You can also use the task interface to invoke this task via LDAP remotely. See /usr/lib/dirsrv/slapd-example/db2ldif.pl for more information. > > Thank you. > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Oct 12 17:47:18 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 12 Oct 2009 11:47:18 -0600 Subject: [389-users] Read data immediately after write In-Reply-To: <736468.43819.qm@web58904.mail.re1.yahoo.com> References: <736468.43819.qm@web58904.mail.re1.yahoo.com> Message-ID: <4AD36BA6.9040203@redhat.com> Ankur Agarwal wrote: > Can i use chaining between master-slave without having different "ou"? > I mean if i have exactly same directory structure and same set of OUs > can i still have chaining between master and slave? > Yes. > > Cheers, > Ankur > > > --- On *Thu, 10/8/09, Michael Str?der //* wrote: > > > From: Michael Str?der > Subject: Re: [389-users] Read data immediately after write > To: "General discussion list for the 389 Directory server > project." > Date: Thursday, October 8, 2009, 1:38 AM > > Ankur Agarwal wrote: > > > > I have a master-slave set-up with write operations always being > done to > > the master node. Now there is an issue where i need to read some > data > > immediately after write, and my read request goes to the slave. > It fails > > in cases when replication hasnt happened from master to slave before > > this read operation. > > You simply should not do that. Read from the master if you have to > rely on the > consistency of what you recently wrote to the master. > > > Is there a LDAP level configuration to handle this situation? > > Can chaining help in this case? > > No. (Except chaining the read requests of the writing client to > the master > which you don't want I guess). > > Ciao, Michael. > > -- > 389 users mailing list > 389-users at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From mitja.mihelic at arnes.si Tue Oct 13 11:34:48 2009 From: mitja.mihelic at arnes.si (=?UTF-8?B?TWl0amEgTWloZWxpxI0=?=) Date: Tue, 13 Oct 2009 13:34:48 +0200 Subject: [389-users] db2ldif as non root user In-Reply-To: <4AD35081.5060502@redhat.com> References: <4AD349FF.6000905@arnes.si> <4AD35081.5060502@redhat.com> Message-ID: <4AD465D8.8070509@arnes.si> Rich Megginson wrote: > Mitja Miheli? wrote: >> Greetings all fellow Fedora Directory Server users! >> >> >> Is it possible to dump the database to an LDIF file as a non-root user ? >> >> I have no problem doing this as root. >> >> I would like to run >> /usr/lib/dirsrv/slapd-example/db2ldif -a /tmp/dbdump.ldif -n userRoot >> from a remote machine via ssh and I would really like to avoid >> connecting to the machine as root. >> >> Has anyone had any experience in doing this if it is at all possible ? > You can also use the task interface to invoke this task via LDAP > remotely. See /usr/lib/dirsrv/slapd-example/db2ldif.pl for more > information. Rich, I tried your suggestion and it worked. Here is what I did to get it working : - as root: chmod o+rx /usr/lib/dirsrv/slapd-example/db2ldif.pl - as user: /usr/lib/dirsrv/slapd-example/db2ldif.pl -D "cn=Directory manager" -w secret -a /tmp/dbdump.ldif -n userRoot This produced an LDIF dump as it should. Since it was written by the ldapmodify command (if I am reading the script correctly) it is owned by nobody : -rw------- 1 nobody nobody 136140945 Oct 13 09:34 dbdump.ldif Of course now the dump cannot be read by the user that initiated the operation. I failed to mention that after the dump is created, it is supposed to be copied (via scp) to the machine that initiated the dump. The remote machine issues the following commands: # ssh user at example.com /usr/lib/dirsrv/slapd-example/db2ldif.pl -D "cn=Directory manager" -w secret -a /tmp/dbdump.ldif -n userRoot # scp user at example.com:/tmp/dbdump.ldif /home/user/dbdump.ldif The only way I see around this problem is to let the server run as a user other than "nobody". Or is there another way ? Regards, Mitja From emmanuel.billot at ird.fr Tue Oct 13 19:19:18 2009 From: emmanuel.billot at ird.fr (Emmanuel BILLOT) Date: Tue, 13 Oct 2009 21:19:18 +0200 Subject: [389-users] Windows Sync precision In-Reply-To: <29742_1255346909_4AD312DC_29742_86_1_4AD312C5.3080106@ird.fr> References: <29742_1255346909_4AD312DC_29742_86_1_4AD312C5.3080106@ird.fr> Message-ID: <4AD4D2B6.5040604@ird.fr> Emmanuel BILLOT a ?crit : > Hi, > > I'm currently on fight with AD replication and synchronization. I need > to know if a non default synchronization (as it is porposed in the > agrment assistant) is possible. > I mean, is it possible to synchronize > > - users in this case : > ou=people,dc=toutou,dc=tagada,dc=org (DS) with > ou=utilisateurs,ou=toutou,dc=tagada,dc=fr (AD) > > and groups like this > ou=group,dc=toutou,dc=tagada,dc=org (DS) with > ou=groupes,ou=toutou,dc=tagada,dc=fr (AD) > > Note that OU are different, suffix are different too. > > I had ti create two different agrements because of OU naming (people > vs utilisateurs and group vs groupes), so one agrement for each object > type. > I succeed in synchronizing users, but for groups, i have an error : > > dn="" or > dn="CN=pfffff,OU=groupes,OU=ORLEANS,DC=maqird,DC=fr" > [12/Oct/2009:11:58:03 +0200] NSMMReplicationPlugin - > agmt="cn=orl_group" (maqsvrdc0001:636): windows_replay_update: > Processing modify operation local > dn="cn=pfffff,ou=group,dc=orleans,dc=ird,dc=fr" remote > dn="" > [12/Oct/2009:11:58:03 +0200] - map_dn_values: this entry is not ours > uid=aubertin,ou=People,dc=orleans,dc=ird,dc=fr > [12/Oct/2009:11:58:03 +0200] agmt="cn=orl_group" (maqsvrdc0001:636) - > clcache_load_buffer: rc=-30989 > [12/Oct/2009:11:58:03 +0200] NSMMReplicationPlugin - > agmt="cn=orl_group" (maqsvrdc0001:636): No more updates to send > (cl5GetNextOperationToReplay) > > It seems that the agrement does not recognize the user entry because > it is stored in a different subtree (the subtree for agrement is > ou=group,dc=orleans,dc=ird,dc=fr, the subtree for user is > ou=people,dc=orleans,dc=ird,dc=fr). > > Is it right ? > Users and Group synch is it only possible when users and groups are in > the same agrement ? > If true, how can we do if OU naming is so different ? > > I hope somebody will answer, > > BR, > > > I had no answer, somebody have an idea ? -- ========================================== Emmanuel BILLOT IRD - Orl?ans D?l?gation aux Syst?mes d'Information (DSI) t?l : 02 38 49 95 88 ========================================== From rmeggins at redhat.com Tue Oct 13 19:51:15 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 13 Oct 2009 13:51:15 -0600 Subject: [389-users] db2ldif as non root user In-Reply-To: <4AD465D8.8070509@arnes.si> References: <4AD349FF.6000905@arnes.si> <4AD35081.5060502@redhat.com> <4AD465D8.8070509@arnes.si> Message-ID: <4AD4DA33.3010301@redhat.com> Mitja Miheli? wrote: > > > Rich Megginson wrote: >> Mitja Miheli? wrote: >>> Greetings all fellow Fedora Directory Server users! >>> >>> >>> Is it possible to dump the database to an LDIF file as a non-root >>> user ? >>> >>> I have no problem doing this as root. >>> >>> I would like to run >>> /usr/lib/dirsrv/slapd-example/db2ldif -a /tmp/dbdump.ldif -n userRoot >>> from a remote machine via ssh and I would really like to avoid >>> connecting to the machine as root. >>> >>> Has anyone had any experience in doing this if it is at all possible ? >> You can also use the task interface to invoke this task via LDAP >> remotely. See /usr/lib/dirsrv/slapd-example/db2ldif.pl for more >> information. > Rich, I tried your suggestion and it worked. > Here is what I did to get it working : > - as root: chmod o+rx /usr/lib/dirsrv/slapd-example/db2ldif.pl Why? > - as user: /usr/lib/dirsrv/slapd-example/db2ldif.pl -D "cn=Directory > manager" -w secret -a /tmp/dbdump.ldif -n userRoot > > This produced an LDIF dump as it should. > Since it was written by the ldapmodify command (if I am reading the > script correctly) it is owned by nobody : > -rw------- 1 nobody nobody 136140945 Oct 13 09:34 dbdump.ldif > Of course now the dump cannot be read by the user that initiated the > operation. > > I failed to mention that after the dump is created, it is supposed to > be copied (via scp) to the machine that initiated the dump. > The remote machine issues the following commands: > # ssh user at example.com /usr/lib/dirsrv/slapd-example/db2ldif.pl -D > "cn=Directory manager" -w secret -a /tmp/dbdump.ldif -n userRoot Instead of remotely executing the db2ldif.pl script, you can use ldapmodify on the local machine to do the same thing. What I originally meant was to look at the contents of the db2ldif.pl script, the part that does the ldapmodify, and just use ldapmodify yourself on the local machine. > # scp user at example.com:/tmp/dbdump.ldif /home/user/dbdump.ldif > > The only way I see around this problem is to let the server run as a > user other than "nobody". Or is there another way ? Note that if you change the server to run as a different user, you will need to make sure to chown everything currently owned by "nobody" under /etc/dirsrv, /usr/lib/dirsrv, /usr/lib64/dirsrv, and /var/*/dirsrv. to be owned by your new user. And change the nsslapd-localuser parameter in cn=config in your dse.ldif. And change anywhere in o=NetscapeRoot and /etc/dirsrv/admin-serv where it references "nobody" to be your new user. This will be quite a painful undertaking. If possible, if you go this route, I suggest you just start over from scratch (i.e. run remove-ds-admin.pl) then run setup-ds-admin.pl again, and use your new user instead of "nobody". I don't know if there is really a graceful way to do what you are attempting to do. > > Regards, > Mitja > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From ankur_agwal at yahoo.com Tue Oct 13 19:57:46 2009 From: ankur_agwal at yahoo.com (Ankur Agarwal) Date: Tue, 13 Oct 2009 12:57:46 -0700 (PDT) Subject: [389-users] Read data immediately after write In-Reply-To: <4AD36BA6.9040203@redhat.com> Message-ID: <299699.66487.qm@web58902.mail.re1.yahoo.com> Thanks Rich...Would it be possible for you to share some configuration details to achieve this for OpenLDAP version 2.3? Cheers, A --- On Mon, 10/12/09, Rich Megginson wrote: From: Rich Megginson Subject: Re: [389-users] Read data immediately after write To: "General discussion list for the 389 Directory server project." Date: Monday, October 12, 2009, 10:47 AM Ankur Agarwal wrote: > Can i use chaining between master-slave without having different "ou"? > I mean if i have exactly same directory structure and same set of OUs > can i still have chaining between master and slave? > Yes. > > Cheers, > Ankur > > > --- On *Thu, 10/8/09, Michael Str?der //* wrote: > > >? ???From: Michael Str?der >? ???Subject: Re: [389-users] Read data immediately after write >? ???To: "General discussion list for the 389 Directory server >? ???project." >? ???Date: Thursday, October 8, 2009, 1:38 AM > >? ???Ankur Agarwal wrote: >? ???> >? ???> I have a master-slave set-up with write operations always being >? ???done to >? ???> the master node. Now there is an issue where i need to read some >? ???data >? ???> immediately after write, and my read request goes to the slave. >? ???It fails >? ???> in cases when replication hasnt happened from master to slave before >? ???> this read operation. > >? ???You simply should not do that. Read from the master if you have to >? ???rely on the >? ???consistency of what you recently wrote to the master. > >? ???> Is there a LDAP level configuration to handle this situation? >? ???> Can chaining help in this case? > >? ???No. (Except chaining the read requests of the writing client to >? ???the master >? ???which you don't want I guess). > >? ???Ciao, Michael. > >? ???-- >? ???389 users mailing list >? ???389-users at redhat.com >? ??? >? ???https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >??? -----Inline Attachment Follows----- -- 389 users mailing list 389-users at redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Oct 13 20:25:19 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 13 Oct 2009 14:25:19 -0600 Subject: [389-users] Read data immediately after write In-Reply-To: <299699.66487.qm@web58902.mail.re1.yahoo.com> References: <299699.66487.qm@web58902.mail.re1.yahoo.com> Message-ID: <4AD4E22F.8040500@redhat.com> Ankur Agarwal wrote: > Thanks Rich...Would it be possible for you to share some configuration > details to achieve this for OpenLDAP version 2.3? > To achieve what exactly for OpenLDAP 2.3? Chain from 389 to OpenLDAP? > > Cheers, > A > > --- On *Mon, 10/12/09, Rich Megginson //* wrote: > > > From: Rich Megginson > Subject: Re: [389-users] Read data immediately after write > To: "General discussion list for the 389 Directory server > project." > Date: Monday, October 12, 2009, 10:47 AM > > Ankur Agarwal wrote: > > Can i use chaining between master-slave without having different > "ou"? > > I mean if i have exactly same directory structure and same set > of OUs > > can i still have chaining between master and slave? > > > Yes. > > > > Cheers, > > Ankur > > > > > > --- On *Thu, 10/8/09, Michael Str?der / >/* > wrote: > > > > > > From: Michael Str?der > > > Subject: Re: [389-users] Read data immediately after write > > To: "General discussion list for the 389 Directory server > > project." > > > Date: Thursday, October 8, 2009, 1:38 AM > > > > Ankur Agarwal wrote: > > > > > > I have a master-slave set-up with write operations always > being > > done to > > > the master node. Now there is an issue where i need to > read some > > data > > > immediately after write, and my read request goes to the > slave. > > It fails > > > in cases when replication hasnt happened from master to > slave before > > > this read operation. > > > > You simply should not do that. Read from the master if you > have to > > rely on the > > consistency of what you recently wrote to the master. > > > > > Is there a LDAP level configuration to handle this situation? > > > Can chaining help in this case? > > > > No. (Except chaining the read requests of the writing client to > > the master > > which you don't want I guess). > > > > Ciao, Michael. > > > > -- > > 389 users mailing list > > 389-users at redhat.com > > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > ------------------------------------------------------------------------ > > > > -- > > 389 users mailing list > > 389-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > -----Inline Attachment Follows----- > > -- > 389 users mailing list > 389-users at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Oct 15 14:02:24 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 15 Oct 2009 08:02:24 -0600 Subject: [389-users] Please test 389 1.2.3 and give us your feedback Message-ID: <4AD72B70.8070602@redhat.com> 389 1.2.3 has been in the testing repositories for about a week. If you have tried it, and you are using Fedora, please give us your feedback: 1) Go to the Fedora Updates System (bodhi) page for the package - https://admin.fedoraproject.org/updates/F10/FEDORA-2009-10369 is the page for 389-ds-base-1.2.3 for F10 2) Click on the Comments link 3) Click on one of the "Works for me" or "Does not work" links - any additional comments are also appreciated 4) If you have a bug, please file it at https://bugzilla.redhat.com/enter_bug.cgi?product=389 If you are using the EL5 packages, please send email to the list. If you are having trouble installing the packages from the testing repos, please let us know, either by email to the list, or IRC irc.freenode.net #389. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From Chris.Hendry at turner.com Thu Oct 15 14:01:59 2009 From: Chris.Hendry at turner.com (Hendry, Chris) Date: Thu, 15 Oct 2009 10:01:59 -0400 Subject: [389-users] wied problems In-Reply-To: <20090617160006.89EFB61A595@hormel.redhat.com> Message-ID: Had two FDS 1.03 replicating for months. Just recently, one stopped replicating And when I try and bring up the Fedora Management Console, no server appears, just blank. Any direction would be most appreciated. errors log file: [15/Oct/2009:09:39:16 -0400] - Fedora-Directory/1.0.4 B2006.312.1539 starting up [15/Oct/2009:09:39:18 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica dc=xxxx,dc=xxxx: 1 [15/Oct/2009:09:39:18 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:39:18 -0400] - str2entry returned NULL for id 13, string="??`" [15/Oct/2009:09:39:18 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests [15/Oct/2009:09:39:19 -0400] - dn2entry: the dn was in the entrydn index (id 48), but it did not exist in id2entry. [15/Oct/2009:09:39:19 -0400] - dn2entry: the dn was in the entrydn index (id 47), but it did not exist in id2entry. [15/Oct/2009:09:39:19 -0400] - dn2entry: the dn was in the entrydn index (id 48), but it did not exist in id2entry. [15/Oct/2009:09:39:19 -0400] - dn2entry: the dn was in the entrydn index (id 47), but it did not exist in id2entry. [15/Oct/2009:09:39:20 -0400] - dn2entry: the dn was in the entrydn index (id 48), but it did not exist in id2entry. [15/Oct/2009:09:39:20 -0400] - dn2entry: the dn was in the entrydn index (id 47), but it did not exist in id2entry. [15/Oct/2009:09:39:20 -0400] - dn2entry: the dn was in the entrydn index (id 48), but it did not exist in id2entry. [15/Oct/2009:09:39:20 -0400] - dn2entry: the dn was in the entrydn index (id 47), but it did not exist in id2entry. [15/Oct/2009:09:40:01 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:40:01 -0400] - str2entry returned NULL for id 485, string="X?`" [15/Oct/2009:09:40:01 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. [15/Oct/2009:09:40:01 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. [15/Oct/2009:09:40:01 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:40:01 -0400] - str2entry returned NULL for id 485, string="P? ctClass" [15/Oct/2009:09:40:01 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. [15/Oct/2009:09:40:01 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. [15/Oct/2009:09:41:12 -0400] - dn2entry: the dn was in the entrydn index (id 51), but it did not exist in id2entry. [15/Oct/2009:09:41:12 -0400] - dn2entry: the dn was in the entrydn index (id 52), but it did not exist in id2entry. [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 48), but it did not exist in id2entry. [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 47), but it did not exist in id2entry. [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 89), but it did not exist in id2entry. [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 88), but it did not exist in id2entry. [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 90), but it did not exist in id2entry. [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 88), but it did not exist in id2entry. [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 91), but it did not exist in id2entry. [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 88), but it did not exist in id2entry. [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 80), but it did not exist in id2entry. [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 80), but it did not exist in id2entry. [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 95), but it did not exist in id2entry. [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 95), but it did not exist in id2entry. [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 92), but it did not exist in id2entry. [15/Oct/2009:09:41:50 -0400] - dn2entry: the dn was in the entrydn index (id 83), but it did not exist in id2entry. [15/Oct/2009:09:42:23 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:42:23 -0400] - str2entry returned NULL for id 485, string="??! " [15/Oct/2009:09:42:23 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:42:23 -0400] - str2entry returned NULL for id 485, string="?? " [15/Oct/2009:09:42:23 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:42:23 -0400] - str2entry returned NULL for id 485, string="??S?" [15/Oct/2009:09:43:37 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:43:37 -0400] - str2entry returned NULL for id 485, string="?6S?" [15/Oct/2009:09:45:02 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:45:02 -0400] - str2entry returned NULL for id 485, string="X?`" [15/Oct/2009:09:45:02 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. [15/Oct/2009:09:45:02 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. [15/Oct/2009:09:45:02 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:45:02 -0400] - str2entry returned NULL for id 485, string="H" [15/Oct/2009:09:45:02 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. [15/Oct/2009:09:45:02 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. [15/Oct/2009:09:46:59 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:46:59 -0400] - str2entry returned NULL for id 485, string="P?`" [15/Oct/2009:09:46:59 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. [15/Oct/2009:09:46:59 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. [15/Oct/2009:09:46:59 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:46:59 -0400] - str2entry returned NULL for id 485, string="H" [15/Oct/2009:09:46:59 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. [15/Oct/2009:09:46:59 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. [15/Oct/2009:09:47:00 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:47:00 -0400] - str2entry returned NULL for id 485, string="H" [15/Oct/2009:09:47:00 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. [15/Oct/2009:09:47:00 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. [15/Oct/2009:09:47:00 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:47:00 -0400] - str2entry returned NULL for id 485, string="0S?ctClass" [15/Oct/2009:09:47:00 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. [15/Oct/2009:09:47:00 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. [15/Oct/2009:09:47:00 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:47:00 -0400] - str2entry returned NULL for id 485, string="H" [15/Oct/2009:09:47:00 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. [15/Oct/2009:09:47:00 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. [15/Oct/2009:09:47:00 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:47:00 -0400] - str2entry returned NULL for id 485, string="H" [15/Oct/2009:09:47:00 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. [15/Oct/2009:09:47:00 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. [15/Oct/2009:09:47:01 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:47:01 -0400] - str2entry returned NULL for id 485, string="P?`" [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. [15/Oct/2009:09:47:01 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:47:01 -0400] - str2entry returned NULL for id 485, string="P?`" [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. [15/Oct/2009:09:47:01 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:47:01 -0400] - str2entry returned NULL for id 485, string="P?`" [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. [15/Oct/2009:09:47:01 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:47:01 -0400] - str2entry returned NULL for id 485, string="H" [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. [15/Oct/2009:09:47:01 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:47:01 -0400] - str2entry returned NULL for id 485, string="X?`" [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. [15/Oct/2009:09:47:01 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:47:01 -0400] - str2entry returned NULL for id 485, string="H" [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. [15/Oct/2009:09:47:08 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:47:08 -0400] - str2entry returned NULL for id 485, string="??`" [15/Oct/2009:09:50:25 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:50:25 -0400] - str2entry returned NULL for id 485, string="" [15/Oct/2009:09:51:10 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:51:10 -0400] - str2entry returned NULL for id 485, string="H" [15/Oct/2009:09:51:10 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. [15/Oct/2009:09:51:10 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. [15/Oct/2009:09:51:10 -0400] - str2entry_fast: entry has no dn [15/Oct/2009:09:51:10 -0400] - str2entry returned NULL for id 485, string="?t ctClass" [15/Oct/2009:09:51:10 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. [15/Oct/2009:09:51:10 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. From nhosoi at redhat.com Thu Oct 15 16:25:01 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Thu, 15 Oct 2009 09:25:01 -0700 Subject: [389-users] wied problems In-Reply-To: References: Message-ID: <4AD74CDD.2060404@redhat.com> It looks some index files are corrupted. Especially, entrydn is. If you run db2ldif, do you see a complete set of entries in the exported ldif file? If yes, you could import the ldif file back, which recreates all the necessary index files. You could do it on one master. Then, you could initialize the replica from the master. Also, FDS 1.0.4 is pretty old. Do you have a plan to upgrade it to 389? Thanks, --noriko On 10/15/2009 07:01 AM, Hendry, Chris wrote: > Had two FDS 1.03 replicating for months. > Just recently, one stopped replicating > And when I try and bring up the Fedora Management Console, no server appears, just blank. > > Any direction would be most appreciated. > > > errors log file: > > > [15/Oct/2009:09:39:16 -0400] - Fedora-Directory/1.0.4 B2006.312.1539 starting up > [15/Oct/2009:09:39:18 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica dc=xxxx,dc=xxxx: 1 > [15/Oct/2009:09:39:18 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:39:18 -0400] - str2entry returned NULL for id 13, string="??`" > [15/Oct/2009:09:39:18 -0400] - slapd started. Listening on All Interfaces port 389 for LDAP requests > [15/Oct/2009:09:39:19 -0400] - dn2entry: the dn was in the entrydn index (id 48), but it did not exist in id2entry. > [15/Oct/2009:09:39:19 -0400] - dn2entry: the dn was in the entrydn index (id 47), but it did not exist in id2entry. > [15/Oct/2009:09:39:19 -0400] - dn2entry: the dn was in the entrydn index (id 48), but it did not exist in id2entry. > [15/Oct/2009:09:39:19 -0400] - dn2entry: the dn was in the entrydn index (id 47), but it did not exist in id2entry. > [15/Oct/2009:09:39:20 -0400] - dn2entry: the dn was in the entrydn index (id 48), but it did not exist in id2entry. > [15/Oct/2009:09:39:20 -0400] - dn2entry: the dn was in the entrydn index (id 47), but it did not exist in id2entry. > [15/Oct/2009:09:39:20 -0400] - dn2entry: the dn was in the entrydn index (id 48), but it did not exist in id2entry. > [15/Oct/2009:09:39:20 -0400] - dn2entry: the dn was in the entrydn index (id 47), but it did not exist in id2entry. > [15/Oct/2009:09:40:01 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:40:01 -0400] - str2entry returned NULL for id 485, string="X?`" > [15/Oct/2009:09:40:01 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. > [15/Oct/2009:09:40:01 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. > [15/Oct/2009:09:40:01 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:40:01 -0400] - str2entry returned NULL for id 485, string="P? ctClass" > [15/Oct/2009:09:40:01 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. > [15/Oct/2009:09:40:01 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. > [15/Oct/2009:09:41:12 -0400] - dn2entry: the dn was in the entrydn index (id 51), but it did not exist in id2entry. > [15/Oct/2009:09:41:12 -0400] - dn2entry: the dn was in the entrydn index (id 52), but it did not exist in id2entry. > [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 48), but it did not exist in id2entry. > [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 47), but it did not exist in id2entry. > [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 89), but it did not exist in id2entry. > [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 88), but it did not exist in id2entry. > [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 90), but it did not exist in id2entry. > [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 88), but it did not exist in id2entry. > [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 91), but it did not exist in id2entry. > [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 88), but it did not exist in id2entry. > [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 80), but it did not exist in id2entry. > [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 80), but it did not exist in id2entry. > [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 95), but it did not exist in id2entry. > [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 95), but it did not exist in id2entry. > [15/Oct/2009:09:41:49 -0400] - dn2entry: the dn was in the entrydn index (id 92), but it did not exist in id2entry. > [15/Oct/2009:09:41:50 -0400] - dn2entry: the dn was in the entrydn index (id 83), but it did not exist in id2entry. > [15/Oct/2009:09:42:23 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:42:23 -0400] - str2entry returned NULL for id 485, string="??! " > [15/Oct/2009:09:42:23 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:42:23 -0400] - str2entry returned NULL for id 485, string="?? " > [15/Oct/2009:09:42:23 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:42:23 -0400] - str2entry returned NULL for id 485, string="??S " > [15/Oct/2009:09:43:37 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:43:37 -0400] - str2entry returned NULL for id 485, string="?6S " > [15/Oct/2009:09:45:02 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:45:02 -0400] - str2entry returned NULL for id 485, string="X?`" > [15/Oct/2009:09:45:02 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. > [15/Oct/2009:09:45:02 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. > [15/Oct/2009:09:45:02 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:45:02 -0400] - str2entry returned NULL for id 485, string="H" > [15/Oct/2009:09:45:02 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. > [15/Oct/2009:09:45:02 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. > [15/Oct/2009:09:46:59 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:46:59 -0400] - str2entry returned NULL for id 485, string="P?`" > [15/Oct/2009:09:46:59 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. > [15/Oct/2009:09:46:59 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. > [15/Oct/2009:09:46:59 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:46:59 -0400] - str2entry returned NULL for id 485, string="H" > [15/Oct/2009:09:46:59 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. > [15/Oct/2009:09:46:59 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. > [15/Oct/2009:09:47:00 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:47:00 -0400] - str2entry returned NULL for id 485, string="H" > [15/Oct/2009:09:47:00 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. > [15/Oct/2009:09:47:00 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. > [15/Oct/2009:09:47:00 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:47:00 -0400] - str2entry returned NULL for id 485, string="0S ctClass" > [15/Oct/2009:09:47:00 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. > [15/Oct/2009:09:47:00 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. > [15/Oct/2009:09:47:00 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:47:00 -0400] - str2entry returned NULL for id 485, string="H" > [15/Oct/2009:09:47:00 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. > [15/Oct/2009:09:47:00 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. > [15/Oct/2009:09:47:00 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:47:00 -0400] - str2entry returned NULL for id 485, string="H" > [15/Oct/2009:09:47:00 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. > [15/Oct/2009:09:47:00 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. > [15/Oct/2009:09:47:01 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:47:01 -0400] - str2entry returned NULL for id 485, string="P?`" > [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. > [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. > [15/Oct/2009:09:47:01 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:47:01 -0400] - str2entry returned NULL for id 485, string="P?`" > [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. > [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. > [15/Oct/2009:09:47:01 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:47:01 -0400] - str2entry returned NULL for id 485, string="P?`" > [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. > [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. > [15/Oct/2009:09:47:01 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:47:01 -0400] - str2entry returned NULL for id 485, string="H" > [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. > [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. > [15/Oct/2009:09:47:01 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:47:01 -0400] - str2entry returned NULL for id 485, string="X?`" > [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. > [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. > [15/Oct/2009:09:47:01 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:47:01 -0400] - str2entry returned NULL for id 485, string="H" > [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. > [15/Oct/2009:09:47:01 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. > [15/Oct/2009:09:47:08 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:47:08 -0400] - str2entry returned NULL for id 485, string="??`" > [15/Oct/2009:09:50:25 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:50:25 -0400] - str2entry returned NULL for id 485, string="" > [15/Oct/2009:09:51:10 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:51:10 -0400] - str2entry returned NULL for id 485, string="H" > [15/Oct/2009:09:51:10 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. > [15/Oct/2009:09:51:10 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. > [15/Oct/2009:09:51:10 -0400] - str2entry_fast: entry has no dn > [15/Oct/2009:09:51:10 -0400] - str2entry returned NULL for id 485, string=" t ctClass" > [15/Oct/2009:09:51:10 -0400] - dn2entry: the dn was in the entrydn index (id 485), but it did not exist in id2entry. > [15/Oct/2009:09:51:10 -0400] - dn2entry: the dn was in the entrydn index (id 487), but it did not exist in id2entry. > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: From across at itasoftware.com Thu Oct 15 19:02:51 2009 From: across at itasoftware.com (Anne Cross) Date: Thu, 15 Oct 2009 15:02:51 -0400 Subject: [389-users] Searching cn=config as a user other than cn=Directory Manager? Message-ID: <4AD771DB.3090702@itasoftware.com> I'm working on setting up nagios monitoring of our multi-master replication, and given the occasional problems that are plaguing our network, we need replication monitoring. The script on http://directory.fedoraproject.org/wiki/Howto:ReplicationMonitoring#Monitoring_replication_with_Nagios is very helpful, but it assumes logging in as the Directory Manager. We've had sufficient problems with "helpful" people becoming root and doing things that I'm *really* wary of putting the Directory Manager password in plaintext in a monitoring script, but searching as cn=replication,cn=config or similar results doesn't return any results. Can someone point me at the ACI I need to modify (or do I need to create a new one?) to add read-only access to cn=config on our master servers for monitoring purposes? Thanks! -- juniper -- ,___, {o,o} Anne "Juniper" Cross (___) Senior Linux Systems Engineer and Extropic Crusader -"-"-- Information Technology, ITA Software /^^^ From okelet at gmail.com Fri Oct 16 10:54:07 2009 From: okelet at gmail.com (=?UTF-8?Q?Juan_Asensio_S=C3=A1nchez?=) Date: Fri, 16 Oct 2009 12:54:07 +0200 Subject: [389-users] repl_set_mtn_referrals: could not set referrals for replica Message-ID: <52a9d2e30910160354y3b394a18ma6bbe46339eee202@mail.gmail.com> Hi We are having problems with replication. We have four master servers replicating one database (database 1), and two other servers in other building that are masters of other database (database 2). Replication between the databases of the others are in hub mode (server1 of building1 with server1 of building1, and server2 of building1 with server2 of building2; server3 and server4 of building1 only have agreements with server1 and server2 of building1). Yesterday we had to remove the replica of server4 of database 1. Next, we did ree-enable the replica and the replication agreements, but the replica was enabled with a different id than before. Now, we have this error on all servers, although replication is working fine: [16/Oct/2009:12:44:39 +0200] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica dc=domain,dc=local: 1 (dc=domain,dc=local is the prefix that owns the database 1). I don't know if this error is critical, but i don't like to see errors in the log (call me fool if you want). I have read some posts: - http://blogs.sun.com/marcos/entry/on_cleanruv - http://blogs.sun.com/piotr/entry/how_to_clean_ruv_s All about Sun, but i am not sure if this will work, or if it is dangerous because it says that the solution is unsupported and irreversible. How can I get rid of this message? is it critical? Regards and thanks in advance. From ankur_agwal at yahoo.com Sun Oct 18 14:38:02 2009 From: ankur_agwal at yahoo.com (Ankur Agarwal) Date: Sun, 18 Oct 2009 07:38:02 -0700 (PDT) Subject: [389-users] Read data immediately after write Message-ID: <151875.79400.qm@web58905.mail.re1.yahoo.com> I want to achieve chaining between a master and slave having exactly same OUs and are based on OpenLDAP 2.3. What would be the configuration to achieve that? Regards, Ankur Sent from my iPhone On Oct 14, 2009, at 1:55 AM, Rich Megginson wrote: Ankur Agarwal wrote: Thanks Rich...Would it be possible for you to share some configuration details to achieve this for OpenLDAP version 2.3? To achieve what exactly for OpenLDAP 2.3? Chain from 389 to OpenLDAP? Cheers, A --- On *Mon, 10/12/09, Rich Megginson //* wrote: From: Rich Megginson Subject: Re: [389-users] Read data immediately after write To: "General discussion list for the 389 Directory server project." Date: Monday, October 12, 2009, 10:47 AM Ankur Agarwal wrote: > Can i use chaining between master-slave without having different "ou"? > I mean if i have exactly same directory structure and same set of OUs > can i still have chaining between master and slave? > Yes. > > Cheers, > Ankur > > > --- On *Thu, 10/8/09, Michael Str?der />/* wrote: > > > From: Michael Str?der > > Subject: Re: [389-users] Read data immediately after write > To: "General discussion list for the 389 Directory server > project." > > Date: Thursday, October 8, 2009, 1:38 AM > > Ankur Agarwal wrote: > > > > I have a master-slave set-up with write operations always being > done to > > the master node. Now there is an issue where i need to read some > data > > immediately after write, and my read request goes to the slave. > It fails > > in cases when replication hasnt happened from master to slave before > > this read operation. > > You simply should not do that. Read from the master if you have to > rely on the > consistency of what you recently wrote to the master. > > > Is there a LDAP level configuration to handle this situation? > > Can chaining help in this case? > > No. (Except chaining the read requests of the writing client to > the master > which you don't want I guess). > > Ciao, Michael. > > -- > 389 users mailing list > 389-users at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -----Inline Attachment Follows----- -- 389 users mailing list 389-users at redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users ------------------------------------------------------------------------ -- 389 users mailing list 389-users at redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users -- 389 users mailing list 389-users at redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users From ankur_agwal at yahoo.com Sun Oct 18 14:38:02 2009 From: ankur_agwal at yahoo.com (Ankur Agarwal) Date: Sun, 18 Oct 2009 07:38:02 -0700 (PDT) Subject: [389-users] Read data immediately after write Message-ID: <151875.79400.qm@web58905.mail.re1.yahoo.com> I want to achieve chaining between a master and slave having exactly same OUs and are based on OpenLDAP 2.3. What would be the configuration to achieve that? Regards, Ankur Sent from my iPhone On Oct 14, 2009, at 1:55 AM, Rich Megginson wrote: Ankur Agarwal wrote: Thanks Rich...Would it be possible for you to share some configuration details to achieve this for OpenLDAP version 2.3? To achieve what exactly for OpenLDAP 2.3? Chain from 389 to OpenLDAP? Cheers, A --- On *Mon, 10/12/09, Rich Megginson //* wrote: From: Rich Megginson Subject: Re: [389-users] Read data immediately after write To: "General discussion list for the 389 Directory server project." Date: Monday, October 12, 2009, 10:47 AM Ankur Agarwal wrote: > Can i use chaining between master-slave without having different "ou"? > I mean if i have exactly same directory structure and same set of OUs > can i still have chaining between master and slave? > Yes. > > Cheers, > Ankur > > > --- On *Thu, 10/8/09, Michael Str?der />/* wrote: > > > From: Michael Str?der > > Subject: Re: [389-users] Read data immediately after write > To: "General discussion list for the 389 Directory server > project." > > Date: Thursday, October 8, 2009, 1:38 AM > > Ankur Agarwal wrote: > > > > I have a master-slave set-up with write operations always being > done to > > the master node. Now there is an issue where i need to read some > data > > immediately after write, and my read request goes to the slave. > It fails > > in cases when replication hasnt happened from master to slave before > > this read operation. > > You simply should not do that. Read from the master if you have to > rely on the > consistency of what you recently wrote to the master. > > > Is there a LDAP level configuration to handle this situation? > > Can chaining help in this case? > > No. (Except chaining the read requests of the writing client to > the master > which you don't want I guess). > > Ciao, Michael. > > -- > 389 users mailing list > 389-users at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -----Inline Attachment Follows----- -- 389 users mailing list 389-users at redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users ------------------------------------------------------------------------ -- 389 users mailing list 389-users at redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users -- 389 users mailing list 389-users at redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users From Claudio.Bisegni at lnf.infn.it Mon Oct 19 12:22:57 2009 From: Claudio.Bisegni at lnf.infn.it (Claudio Bisegni) Date: Mon, 19 Oct 2009 14:22:57 +0200 Subject: [389-users] Issue for operation that use proxy user Message-ID: Hi all, i'm writing a middle tier that use a ldap pooled connection to 389 directory server. The connection are made using Application Server special user for bind operation. When an user is authenticated, all the operation are made using the special user polled connection that use the current logged user as proxy user. The DN for the Application Server user have only privilege to read and make proxy. This is the scenario and with this i have two issue. 1) using the proxy user i can't write the userPassword Attribute but i can do all operation on all other attribute(the user used for proxy have all privilege on all the tree) the error i receive is: 'Insufficient 'write' privilege to the 'userPassword' attribute of entry 'infnuuid=31e4ebe9-36c2-4244- b00c-18e6e87fe407,ou=people,dc=infn,dc=it' If i get a connection making the bind with this user, all work. All other operation except add or modify "userPassword" attribute work well using the proxy user as aspected(so proxy is working) 2)for all other operation that work using the proxy user the problem is that on 389 log is shown only the real and not the proxy one. Can be 389 server configured to shown the real and proxy user, to log the operation? Thanks in advanced. Best Reguards Claudio Bisegni -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1758 bytes Desc: not available URL: From rmeggins at redhat.com Mon Oct 19 20:03:32 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 19 Oct 2009 14:03:32 -0600 Subject: [389-users] Searching cn=config as a user other than cn=Directory Manager? In-Reply-To: <4AD771DB.3090702@itasoftware.com> References: <4AD771DB.3090702@itasoftware.com> Message-ID: <4ADCC614.8050608@redhat.com> Anne Cross wrote: > I'm working on setting up nagios monitoring of our multi-master > replication, and given the occasional problems that are plaguing our > network, we need replication monitoring. The script on > http://directory.fedoraproject.org/wiki/Howto:ReplicationMonitoring#Monitoring_replication_with_Nagios > is very helpful, but it assumes logging in as the Directory Manager. > > We've had sufficient problems with "helpful" people becoming root and > doing things that I'm *really* wary of putting the Directory Manager > password in plaintext in a monitoring script, As well you should be. > but searching as cn=replication,cn=config or similar results doesn't > return any results. > Can someone point me at the ACI I need to modify (or do I need to > create a new one?) to add read-only access to cn=config on our master > servers for monitoring purposes? Thanks! The setup-ds-admin.pl script creates ACIs for the console admin user - look at the ACIs on the cn=config entry for the uid=admin,..... user. You can probably just duplicate those - change the user to be your monitoring user, and change the allow() to just read,search,compare. See also http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_Access_Control.html > > -- juniper > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Oct 19 20:04:55 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 19 Oct 2009 14:04:55 -0600 Subject: [389-users] Read data immediately after write In-Reply-To: <151875.79400.qm@web58905.mail.re1.yahoo.com> References: <151875.79400.qm@web58905.mail.re1.yahoo.com> Message-ID: <4ADCC667.2070405@redhat.com> Ankur Agarwal wrote: > I want to achieve chaining between a master and slave having exactly same OUs and are based on OpenLDAP 2.3. > > What would be the configuration to achieve that? > So 389 is the proxy server and openldap is hosting the real data? It should just work. Have you tried this configuration? If so, what problems did you encounter? > Regards, > Ankur > > Sent from my iPhone > > On Oct 14, 2009, at 1:55 AM, Rich Megginson wrote: > > Ankur Agarwal wrote: > Thanks Rich...Would it be possible for you to share some configuration details to achieve this for OpenLDAP version 2.3? > > To achieve what exactly for OpenLDAP 2.3? Chain from 389 to OpenLDAP? > > Cheers, > A > > --- On *Mon, 10/12/09, Rich Megginson //* wrote: > > > From: Rich Megginson > Subject: Re: [389-users] Read data immediately after write > To: "General discussion list for the 389 Directory server > project." > Date: Monday, October 12, 2009, 10:47 AM > > Ankur Agarwal wrote: > > Can i use chaining between master-slave without having different > "ou"? > > I mean if i have exactly same directory structure and same set > of OUs > > can i still have chaining between master and slave? > > > Yes. > > > > Cheers, > > Ankur > > > > > > --- On *Thu, 10/8/09, Michael Str?der / >/* > wrote: > > > > > > From: Michael Str?der > > > Subject: Re: [389-users] Read data immediately after write > > To: "General discussion list for the 389 Directory server > > project." > > > Date: Thursday, October 8, 2009, 1:38 AM > > > > Ankur Agarwal wrote: > > > > > > I have a master-slave set-up with write operations always > being > > done to > > > the master node. Now there is an issue where i need to > read some > > data > > > immediately after write, and my read request goes to the > slave. > > It fails > > > in cases when replication hasnt happened from master to > slave before > > > this read operation. > > > > You simply should not do that. Read from the master if you > have to > > rely on the > > consistency of what you recently wrote to the master. > > > > > Is there a LDAP level configuration to handle this situation? > > > Can chaining help in this case? > > > > No. (Except chaining the read requests of the writing client to > > the master > > which you don't want I guess). > > > > Ciao, Michael. > > > > -- > > 389 users mailing list > > 389-users at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > ------------------------------------------------------------------------ > > > > -- > > 389 users mailing list > > 389-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > -----Inline Attachment Follows----- > > -- > 389 users mailing list > 389-users at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Oct 19 20:06:33 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 19 Oct 2009 14:06:33 -0600 Subject: [389-users] Issue for operation that use proxy user In-Reply-To: References: Message-ID: <4ADCC6C9.8080900@redhat.com> Claudio Bisegni wrote: > Hi all, > > i'm writing a middle tier that use a ldap pooled connection to 389 > directory server. > The connection are made using Application Server special user for bind > operation. When an user is authenticated, all the operation are made > using the special user polled connection that use the current logged > user as proxy user. The DN for the Application Server user have only > privilege to read and make proxy. > This is the scenario and with this i have two issue. > > 1) using the proxy user i can't write the userPassword Attribute but i > can do all operation on all other attribute(the user used for proxy > have all privilege on all the tree) the error i receive is: > 'Insufficient 'write' privilege to the 'userPassword' attribute of > entry > 'infnuuid=31e4ebe9-36c2-4244-b00c-18e6e87fe407,ou=people,dc=infn,dc=it' > If i get a connection making the bind with this user, all work. All > other operation except add or modify "userPassword" attribute work > well using the proxy user as aspected(so proxy is working) https://bugzilla.redhat.com/show_bug.cgi?id=520151 > > 2)for all other operation that work using the proxy user the problem > is that on 389 log is shown only the real and not the proxy one. Can > be 389 server configured to shown the real and proxy user, to log the > operation? It cannot currently be configured as such. Please file a bug/enhancement request at https://bugzilla.redhat.com/enter_bug.cgi?product=389 > > Thanks in advanced. > > Best Reguards > Claudio Bisegni > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Oct 19 20:13:06 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 19 Oct 2009 14:13:06 -0600 Subject: [389-users] repl_set_mtn_referrals: could not set referrals for replica In-Reply-To: <52a9d2e30910160354y3b394a18ma6bbe46339eee202@mail.gmail.com> References: <52a9d2e30910160354y3b394a18ma6bbe46339eee202@mail.gmail.com> Message-ID: <4ADCC852.70203@redhat.com> Juan Asensio S?nchez wrote: > Hi > > We are having problems with replication. We have four master servers > replicating one database (database 1), and two other servers in other > building that are masters of other database (database 2). Replication > between the databases of the others are in hub mode (server1 of > building1 with server1 of building1, and server2 of building1 with > server2 of building2; server3 and server4 of building1 only have > agreements with server1 and server2 of building1). Yesterday we had to > remove the replica of server4 of database 1. Next, we did ree-enable > the replica and the replication agreements, but the replica was > enabled with a different id than before. Now, we have this error on > all servers, although replication is working fine: > > [16/Oct/2009:12:44:39 +0200] NSMMReplicationPlugin - > repl_set_mtn_referrals: could not set referrals for replica > dc=domain,dc=local: 1 > I don't think this is a critical error. You can manually set the referrals to use - in the console for the Replica config, at the bottom of that window (under the Supplier DN area) you can specify the referrals to use. However, you will have to manage these manually - they are not set automatically like the regular replication referrals are. > (dc=domain,dc=local is the prefix that owns the database 1). I don't > know if this error is critical, but i don't like to see errors in the > log (call me fool if you want). I have read some posts: > > - http://blogs.sun.com/marcos/entry/on_cleanruv > - http://blogs.sun.com/piotr/entry/how_to_clean_ruv_s > > All about Sun, but i am not sure if this will work, or if it is > dangerous because it says that the solution is unsupported and > irreversible. How can I get rid of this message? is it critical? > You could try using that. I would suggest backing up all of your data and config first. > Regards and thanks in advance. > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From Claudio.Bisegni at lnf.infn.it Mon Oct 19 20:17:27 2009 From: Claudio.Bisegni at lnf.infn.it (Bisegni Claudio) Date: Mon, 19 Oct 2009 22:17:27 +0200 Subject: [389-users] Issue for operation that use proxy user In-Reply-To: <4ADCC6C9.8080900@redhat.com> References: <4ADCC6C9.8080900@redhat.com> Message-ID: Thank you Richard, i'll file the bug/enhancement request. Claudio On 19/ott/2009, at 22.06, Rich Megginson wrote: > Claudio Bisegni wrote: >> Hi all, >> >> i'm writing a middle tier that use a ldap pooled connection to 389 >> directory server. The connection are made using Application Server >> special user for bind operation. When an user is authenticated, all >> the operation are made using the special user polled connection >> that use the current logged user as proxy user. The DN for the >> Application Server user have only privilege to read and make proxy. >> This is the scenario and with this i have two issue. >> >> 1) using the proxy user i can't write the userPassword Attribute >> but i can do all operation on all other attribute(the user used for >> proxy have all privilege on all the tree) the error i receive is: >> 'Insufficient 'write' privilege to the 'userPassword' attribute of >> entry 'infnuuid=31e4ebe9-36c2-4244- >> b00c-18e6e87fe407,ou=people,dc=infn,dc=it' >> If i get a connection making the bind with this user, all work. All >> other operation except add or modify "userPassword" attribute work >> well using the proxy user as aspected(so proxy is working) > https://bugzilla.redhat.com/show_bug.cgi?id=520151 >> >> 2)for all other operation that work using the proxy user the >> problem is that on 389 log is shown only the real and not the proxy >> one. Can be 389 server configured to shown the real and proxy user, >> to log the operation? > It cannot currently be configured as such. Please file a bug/ > enhancement request at https://bugzilla.redhat.com/enter_bug.cgi?product=389 >> >> Thanks in advanced. >> >> Best Reguards >> Claudio Bisegni >> >> ------------------------------------------------------------------------ >> >> -- >> 389 users mailing list >> 389-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1758 bytes Desc: not available URL: From across at itasoftware.com Mon Oct 19 21:36:16 2009 From: across at itasoftware.com (Anne Cross) Date: Mon, 19 Oct 2009 17:36:16 -0400 Subject: [389-users] Searching cn=config as a user other than cn=Directory Manager? In-Reply-To: <4ADCC614.8050608@redhat.com> References: <4AD771DB.3090702@itasoftware.com> <4ADCC614.8050608@redhat.com> Message-ID: <4ADCDBD0.9020700@itasoftware.com> Rich Megginson wrote: >> but searching as cn=replication,cn=config or similar results doesn't >> return any results. >> Can someone point me at the ACI I need to modify (or do I need to >> create a new one?) to add read-only access to cn=config on our master >> servers for monitoring purposes? Thanks! > The setup-ds-admin.pl script creates ACIs for the console admin user - > look at the ACIs on the cn=config entry for the uid=admin,..... user. > You can probably just duplicate those - change the user to be your > monitoring user, and change the allow() to just read,search,compare. > Ahah. Just in case anybody else is curious, this is effectively what I ended up setting up for the check_ldap_replication script for nagios, on the cn=config tree: (targetattr = "*") (version 3.0; acl "Monitoring Script"; allow (read,compare,search)(userdn = "ldap:///uid=nagiosmonitoring,ou=Resource Accounts,dc=itasoftware,dc=com") ;) I may see if I can restrict it down a little further, but that makes me much happier than using the Directory Manager user. Thanks for your help! -- ,___, {o,o} Anne "Juniper" Cross (___) Senior Linux Systems Engineer and Extropic Crusader -"-"-- Information Technology, ITA Software /^^^ From okelet at gmail.com Tue Oct 20 12:57:06 2009 From: okelet at gmail.com (=?UTF-8?Q?Juan_Asensio_S=C3=A1nchez?=) Date: Tue, 20 Oct 2009 14:57:06 +0200 Subject: [389-users] Multimaster replication Message-ID: <52a9d2e30910200557x67beb0cal4ce68a1a5f250aeb@mail.gmail.com> Hi Has 389DS any limit of servers for multimaster replication? If so, what is the best option to have any number of servers with read/write databases and replication agreements among them? Regards. From mumie_die at yahoo.de Tue Oct 20 07:21:26 2009 From: mumie_die at yahoo.de (Anton Engelhardt) Date: Tue, 20 Oct 2009 09:21:26 +0200 Subject: [389-users] An Error i can not trace back Message-ID: <4ADD64F6.7040200@yahoo.de> Hi, first of all, I'm running gentoo linux and tried to install the 389-ds, and as far as i see the ldap server itself runs. I just can't get the 398-webadmin to work. I think i have tracked down the error to the mod_admserv.so apache2 module. When i comment it out the apache runs. Not doing so gives me the following startup Information: /usr/sbin/apache2 -D DEFAULT_VHOST -D LANGUAGE -D INFO -d /usr/lib/apache2 -f /etc/dirsrv/admin-serv/httpd.conf -e debug -k restart [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module restartd_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module nss_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module admserv_module [Tue Oct 20 09:15:37 2009] [debug] mod_admserv.c(2485): [25521] create_server_config [0xbogus %p for (null) [Tue Oct 20 09:15:37 2009] [debug] mod_admserv.c(2473): [25521] create_config [0xbogus %p for (null) [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module actions_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module alias_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module auth_basic_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module authn_anon_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module authn_dbd_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module authn_dbm_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module authn_default_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module authn_file_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module authz_dbm_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module authz_default_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module authz_groupfile_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module authz_host_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module authz_owner_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module authz_user_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module autoindex_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module dbd_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module dir_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module env_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module expires_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module ext_filter_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module filter_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module headers_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module ident_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module imagemap_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module include_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module mime_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module mime_magic_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module negotiation_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module rewrite_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module setenvif_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module speling_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module usertrack_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module vhost_alias_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module cgid_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module log_config_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module logio_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module unique_id_module [Tue Oct 20 09:15:37 2009] [debug] mod_so.c(246): loaded module info_module [Tue Oct 20 09:15:37 2009] [debug] mod_admserv.c(2544): [25521] Set [0xbogus %p [ADMCacheLifeTime] to 600 [Tue Oct 20 09:15:37 2009] [debug] mod_admserv.c(2562): [25521] Set [0xbogus %p [ADMServerVersionString] to 389-Administrator/1.1.8 [Tue Oct 20 09:15:37 2009] [debug] mod_admserv.c(2473): [25521] create_config [0xbogus %p for /*/[tT]asks/[Oo]peration/* [Tue Oct 20 09:15:37 2009] [debug] mod_admserv.c(2473): [25521] create_config [0xbogus %p for /*/[tT]asks/[Cc]onfiguration/* [Tue Oct 20 09:15:37 2009] [debug] mod_admserv.c(2473): [25521] create_config [0xbogus %p for /*/[tT]asks/[Oo]peration/(?i:stop|start|restart|startconfigds|create|remove)$ additionaly i get the following in the dirserv-admin log: [Tue Oct 20 09:15:37 2009] [debug] mod_admserv.c(2419): Entering mod_admserv_post_config - pid is [25521] init count is [0] [Tue Oct 20 09:15:37 2009] [debug] mod_admserv.c(2248): Entering do_admserv_post_config - pid is [25521] [Tue Oct 20 09:15:37 2009] [debug] mod_admserv.c(2256): Entering do_admserv_post_config - init count is [1] [Tue Oct 20 09:15:37 2009] [debug] mod_admserv.c(2280): [25521] Cache expiration set to 600 seconds [Tue Oct 20 09:15:37 2009] [crit] do_admserv_post_config(): unable to create AdmldapInfo Configuration Failed [Tue Oct 20 09:15:37 2009] [info] Shutting down SSL Session ID Cache google doesn't give me any usable results und nobody in the #389 irc seems to be able to answer. Even though I'm not running Fedora nor Redhat i would be glad to recive some Information about solving this issue or to be able to trace back the reason for this error. Thanks in advance From rmeggins at redhat.com Tue Oct 20 14:06:22 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 20 Oct 2009 08:06:22 -0600 Subject: [389-users] Multimaster replication In-Reply-To: <52a9d2e30910200557x67beb0cal4ce68a1a5f250aeb@mail.gmail.com> References: <52a9d2e30910200557x67beb0cal4ce68a1a5f250aeb@mail.gmail.com> Message-ID: <4ADDC3DE.7080602@redhat.com> Juan Asensio S?nchez wrote: > Hi > > Has 389DS any limit of servers for multimaster replication? If so, > what is the best option to have any number of servers with read/write > databases and replication agreements among them? > The upper limit on the number of replicas is 65534 - we use a short integer field for the master replica ID. However, long before that, you will likely run into resource limits. For example, each replication agreement uses at least one thread and sometimes two. This will use memory and CPU resources. > Regards. > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From ankur_agwal at yahoo.com Tue Oct 20 15:12:21 2009 From: ankur_agwal at yahoo.com (Ankur Agarwal) Date: Tue, 20 Oct 2009 08:12:21 -0700 (PDT) Subject: [389-users] Read data immediately after write In-Reply-To: <4ADCC667.2070405@redhat.com> Message-ID: <755694.47451.qm@web58902.mail.re1.yahoo.com> No i am not talking about proxy server but a master-slave set-up of OpenLDAP 2.3 and need to achieve chaining between them. ? Cheers, Ankur --- On Mon, 10/19/09, Rich Megginson wrote: From: Rich Megginson Subject: Re: [389-users] Read data immediately after write To: "General discussion list for the 389 Directory server project." Date: Monday, October 19, 2009, 1:04 PM Ankur Agarwal wrote: > I want to achieve chaining between a master and slave having exactly same OUs and are based on OpenLDAP 2.3. > > What would be the configuration to achieve that? >??? So 389 is the proxy server and openldap is hosting the real data?? It should just work.? Have you tried this configuration?? If so, what problems did you encounter? > Regards, > Ankur > > Sent from my iPhone > > On Oct 14, 2009, at 1:55 AM, Rich Megginson wrote: > > Ankur Agarwal wrote: > Thanks Rich...Would it be possible for you to share some configuration details to achieve this for OpenLDAP version 2.3? > > To achieve what exactly for OpenLDAP 2.3?? Chain from 389 to OpenLDAP? > > Cheers, > A > > --- On *Mon, 10/12/09, Rich Megginson //* wrote: > > >? ? From: Rich Megginson >? ? Subject: Re: [389-users] Read data immediately after write >? ? To: "General discussion list for the 389 Directory server >? ? project." >? ? Date: Monday, October 12, 2009, 10:47 AM > >? ? Ankur Agarwal wrote: >? ? > Can i use chaining between master-slave without having different >? ? "ou"? >? ? > I mean if i have exactly same directory structure and same set >? ? of OUs >? ? > can i still have chaining between master and slave? >? ? > >? ? Yes. >? ? > >? ? > Cheers, >? ? > Ankur >? ? > >? ? > >? ? > --- On *Thu, 10/8/09, Michael Str?der /? ? >/* >? ? wrote: >? ? > >? ? > >? ? >? ???From: Michael Str?der ? ? > >? ? >? ???Subject: Re: [389-users] Read data immediately after write >? ? >? ???To: "General discussion list for the 389 Directory server >? ? >? ???project." ? ? > >? ? >? ???Date: Thursday, October 8, 2009, 1:38 AM >? ? > >? ? >? ???Ankur Agarwal wrote: >? ? >? ???> >? ? >? ???> I have a master-slave set-up with write operations always >? ? being >? ? >? ???done to >? ? >? ???> the master node. Now there is an issue where i need to >? ? read some >? ? >? ???data >? ? >? ???> immediately after write, and my read request goes to the >? ? slave. >? ? >? ???It fails >? ? >? ???> in cases when replication hasnt happened from master to >? ? slave before >? ? >? ???> this read operation. >? ? > >? ? >? ???You simply should not do that. Read from the master if you >? ? have to >? ? >? ???rely on the >? ? >? ???consistency of what you recently wrote to the master. >? ? > >? ? >? ???> Is there a LDAP level configuration to handle this situation? >? ? >? ???> Can chaining help in this case? >? ? > >? ? >? ???No. (Except chaining the read requests of the writing client to >? ? >? ???the master >? ? >? ???which you don't want I guess). >? ? > >? ? >? ???Ciao, Michael. >? ? > >? ? >? ???-- >? ? >? ???389 users mailing list >? ? >? ???389-users at redhat.com >? ? >? ? >? ? ? ? >? ? >? ???https://www.redhat.com/mailman/listinfo/fedora-directory-users >? ? > >? ? > >? ? > >? ? ------------------------------------------------------------------------ >? ? > >? ? > -- >? ? > 389 users mailing list >? ? > 389-users at redhat.com >? ? >? ? > https://www.redhat.com/mailman/listinfo/fedora-directory-users >? ? >??? > > >? ? -----Inline Attachment Follows----- > >? ? -- >? ? 389 users mailing list >? ? 389-users at redhat.com >? ? >? ? https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >? > > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > >? ? ??? > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >??? -----Inline Attachment Follows----- -- 389 users mailing list 389-users at redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Oct 20 15:21:08 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 20 Oct 2009 09:21:08 -0600 Subject: [389-users] Read data immediately after write In-Reply-To: <755694.47451.qm@web58902.mail.re1.yahoo.com> References: <755694.47451.qm@web58902.mail.re1.yahoo.com> Message-ID: <4ADDD564.7040104@redhat.com> Ankur Agarwal wrote: > No i am not talking about proxy server but a master-slave set-up of > OpenLDAP 2.3 and need to achieve chaining between them. > OpenLDAP 2.3 master and OpenLDAP 2.3 slave? If so, then you should ask on one of the openldap lists. > > Cheers, > Ankur > > > --- On *Mon, 10/19/09, Rich Megginson //* wrote: > > > From: Rich Megginson > Subject: Re: [389-users] Read data immediately after write > To: "General discussion list for the 389 Directory server > project." > Date: Monday, October 19, 2009, 1:04 PM > > Ankur Agarwal wrote: > > I want to achieve chaining between a master and slave having > exactly same OUs and are based on OpenLDAP 2.3. > > > > What would be the configuration to achieve that? > > > So 389 is the proxy server and openldap is hosting the real data? It > should just work. Have you tried this configuration? If so, what > problems did you encounter? > > Regards, > > Ankur > > > > Sent from my iPhone > > > > On Oct 14, 2009, at 1:55 AM, Rich Megginson > > wrote: > > > > Ankur Agarwal wrote: > > Thanks Rich...Would it be possible for you to share some > configuration details to achieve this for OpenLDAP version 2.3? > > > > To achieve what exactly for OpenLDAP 2.3? Chain from 389 to > OpenLDAP? > > > > Cheers, > > A > > > > --- On *Mon, 10/12/09, Rich Megginson / >/* > wrote: > > > > > > From: Rich Megginson > > > Subject: Re: [389-users] Read data immediately after write > > To: "General discussion list for the 389 Directory server > > project." > > > Date: Monday, October 12, 2009, 10:47 AM > > > > Ankur Agarwal wrote: > > > Can i use chaining between master-slave without having > different > > "ou"? > > > I mean if i have exactly same directory structure and same set > > of OUs > > > can i still have chaining between master and slave? > > > > > Yes. > > > > > > Cheers, > > > Ankur > > > > > > > > > --- On *Thu, 10/8/09, Michael Str?der > / > > > >/* > > wrote: > > > > > > > > > From: Michael Str?der > > > > > > > Subject: Re: [389-users] Read data immediately after write > > > To: "General discussion list for the 389 Directory server > > > project." > > > > > > > Date: Thursday, October 8, 2009, 1:38 AM > > > > > > Ankur Agarwal wrote: > > > > > > > > I have a master-slave set-up with write operations always > > being > > > done to > > > > the master node. Now there is an issue where i need to > > read some > > > data > > > > immediately after write, and my read request goes to the > > slave. > > > It fails > > > > in cases when replication hasnt happened from master to > > slave before > > > > this read operation. > > > > > > You simply should not do that. Read from the master if you > > have to > > > rely on the > > > consistency of what you recently wrote to the master. > > > > > > > Is there a LDAP level configuration to handle this > situation? > > > > Can chaining help in this case? > > > > > > No. (Except chaining the read requests of the writing > client to > > > the master > > > which you don't want I guess). > > > > > > Ciao, Michael. > > > > > > -- > > > 389 users mailing list > > > 389-users at redhat.com > > > > > > > > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > -- > > > 389 users mailing list > > > 389-users at redhat.com > > > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > -----Inline Attachment Follows----- > > > > -- > > 389 users mailing list > > 389-users at redhat.com > > > > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > 389 users mailing list > > 389-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > -- > > 389 users mailing list > > 389-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > > > > > > > -- > > 389 users mailing list > > 389-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > -----Inline Attachment Follows----- > > -- > 389 users mailing list > 389-users at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From okelet at gmail.com Tue Oct 20 15:46:26 2009 From: okelet at gmail.com (=?UTF-8?Q?Juan_Asensio_S=C3=A1nchez?=) Date: Tue, 20 Oct 2009 17:46:26 +0200 Subject: [389-users] Multimaster replication In-Reply-To: <4ADDC3DE.7080602@redhat.com> References: <52a9d2e30910200557x67beb0cal4ce68a1a5f250aeb@mail.gmail.com> <4ADDC3DE.7080602@redhat.com> Message-ID: <52a9d2e30910200846w4ace47b7n67328ac3608df037@mail.gmail.com> Hi Thanks for the answer. Now we have more than fifty servers (more than twenty organizations, each with at least two servers), each one with about the same number of replication agreements, and we are not having any problems about resource limits. Each server has its own database in multimaster mode and the databases of the other organizations in hub mode. We thought there were a limit of four (4) servers per multimaster replica; the biggest organization will have now 6 servers, each one with the replica of its database in multimaster mode, so that's my question. Anyone has multimaster replicas with such number of servers? Any suggestions? Regards. 2009/10/20 Rich Megginson : > Juan Asensio S?nchez wrote: >> >> Hi >> >> Has 389DS any limit of servers for multimaster replication? If so, >> what is the best option to have any number of servers with read/write >> databases and replication agreements among them? >> > > The upper limit on the number of replicas is 65534 - we use a short integer > field for the master replica ID. > However, long before that, you will likely run into resource limits. ?For > example, each replication agreement uses at least one thread and sometimes > two. ?This will use memory and CPU resources. >> >> Regards. >> >> -- From rmeggins at redhat.com Tue Oct 20 16:38:15 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 20 Oct 2009 10:38:15 -0600 Subject: [389-users] Multimaster replication In-Reply-To: <52a9d2e30910200846w4ace47b7n67328ac3608df037@mail.gmail.com> References: <52a9d2e30910200557x67beb0cal4ce68a1a5f250aeb@mail.gmail.com> <4ADDC3DE.7080602@redhat.com> <52a9d2e30910200846w4ace47b7n67328ac3608df037@mail.gmail.com> Message-ID: <4ADDE777.3030506@redhat.com> Juan Asensio S?nchez wrote: > Hi > > Thanks for the answer. Now we have more than fifty servers (more than > twenty organizations, each with at least two servers), each one with > about the same number of replication agreements, and we are not having > any problems about resource limits. Each server has its own database > in multimaster mode and the databases of the other organizations in > hub mode. We thought there were a limit of four (4) servers per > multimaster replica; That is a limit only in the Red Hat Directory Server product. The support referred to there is an issue of machines required to diagnose problems and answer questions, not an issue in the code. > the biggest organization will have now 6 servers, > each one with the replica of its database in multimaster mode, so > that's my question. > > Anyone has multimaster replicas with such number of servers? Any suggestions? > > Regards. > > 2009/10/20 Rich Megginson : > >> Juan Asensio S?nchez wrote: >> >>> Hi >>> >>> Has 389DS any limit of servers for multimaster replication? If so, >>> what is the best option to have any number of servers with read/write >>> databases and replication agreements among them? >>> >>> >> The upper limit on the number of replicas is 65534 - we use a short integer >> field for the master replica ID. >> However, long before that, you will likely run into resource limits. For >> example, each replication agreement uses at least one thread and sometimes >> two. This will use memory and CPU resources. >> >>> Regards. >>> >>> -- >>> > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From across at itasoftware.com Tue Oct 20 16:56:33 2009 From: across at itasoftware.com (Anne Cross) Date: Tue, 20 Oct 2009 12:56:33 -0400 Subject: [389-users] 389, Active Directory, PassSync, Multi-Masters, and multiple AD servers Message-ID: <4ADDEBC1.3000009@itasoftware.com> We have two AD servers, and we're working on having four 389 Masters geographically distributed, multi-mastered between them, etc, etc, etc. The goal here is to stop having network hiccups take things out. The AD servers talk to each other nigh-on instantaneously. Likewise for the 389 servers. Is it safe to set up sync agreements to *both* AD servers, in case one goes down? Likewise, is it safe to set up an agreement to a single AD server on multiple masters, in case we lose one master? And for further fun, do I need to install PassSync on both AD servers? Our windows admin wants to set it up on the password server, and the documentation on RedHat's site doesn't say it specifically needs to be on the AD box, but I'm wondering what happens if the password changes circumvent the password server (an admin manually changes someone's password on the AD server, for example.) -- juniper (this is moderately hairy, but once it's worked out, I will never need to touch it again, I hope) -- ,___, {o,o} Anne "Juniper" Cross (___) Senior Linux Systems Engineer and Extropic Crusader -"-"-- Information Technology, ITA Software /^^^ From andrew.kerr at amdocs.com Tue Oct 20 18:26:29 2009 From: andrew.kerr at amdocs.com (Andrew Kerr) Date: Tue, 20 Oct 2009 11:26:29 -0700 Subject: [389-users] Password expiration warning Message-ID: <79C574D4B49B6047B5213B694531E5FF01DEF9C4@seamail1.corp.amdocs.com> I am hoping to implement password expirations using 389. 389 is used for system level auth across a few hundred redhat5 servers, but is also used for web auth, and primarily so for less technical users (access to Wiki, internal accounting systems, etc). What I'm struggling with is how users will be notified of their upcoming password expiration if they don't directly log in to a Unix box. 389 has a check box to "send warning X days before password expires", but I can't find any documentation on what exactly that means. How are they notified - via email? If not, is there already a script out in the wild that will scan my LDAP for upcoming expirations (via cron) and email notifications to users? Thanks! This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Oct 20 18:32:15 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 20 Oct 2009 12:32:15 -0600 Subject: [389-users] Password expiration warning In-Reply-To: <79C574D4B49B6047B5213B694531E5FF01DEF9C4@seamail1.corp.amdocs.com> References: <79C574D4B49B6047B5213B694531E5FF01DEF9C4@seamail1.corp.amdocs.com> Message-ID: <4ADE022F.2040003@redhat.com> Andrew Kerr wrote: > > I am hoping to implement password expirations using 389. 389 is used > for system level auth across a few hundred redhat5 servers, but is > also used for web auth, and primarily so for less technical users > (access to Wiki, internal accounting systems, etc). > > What I?m struggling with is how users will be notified of their > upcoming password expiration if they don?t directly log in to a Unix > box. 389 has a check box to ?send warning X days before password > expires?, but I can?t find any documentation on what exactly that > means. How are they notified ? via email? > No. 389 sends back a password response control value that specifies how much time is remaining until expiration. LDAP clients such as pam_ldap understand how to parse the control. Other clients may not. > > If not, is there already a script out in the wild that will scan my > LDAP for upcoming expirations (via cron) and email notifications to users? > > Thanks! > > This message and the information contained herein is proprietary and > confidential and subject to the Amdocs policy statement, > you may review at http://www.amdocs.com/email_disclaimer.asp > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Oct 20 18:36:45 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 20 Oct 2009 12:36:45 -0600 Subject: [389-users] 389, Active Directory, PassSync, Multi-Masters, and multiple AD servers In-Reply-To: <4ADDEBC1.3000009@itasoftware.com> References: <4ADDEBC1.3000009@itasoftware.com> Message-ID: <4ADE033D.5080006@redhat.com> Anne Cross wrote: > We have two AD servers, and we're working on having four 389 Masters > geographically distributed, multi-mastered between them, etc, etc, > etc. The goal here is to stop having network hiccups take things out. > > The AD servers talk to each other nigh-on instantaneously. Likewise > for the 389 servers. Is it safe to set up sync agreements to *both* > AD servers, in case one goes down? No. See https://bugzilla.redhat.com/show_bug.cgi?id=182515 and https://bugzilla.redhat.com/show_bug.cgi?id=184155 > Likewise, is it safe to set up an agreement to a single AD server on > multiple masters, in case we lose one master? You might run into the same issues as specified in the bugs above. > > And for further fun, do I need to install PassSync on both AD > servers? Our windows admin wants to set it up on the password server, > and the documentation on RedHat's site doesn't say it specifically > needs to be on the AD box, but I'm wondering what happens if the > password changes circumvent the password server (an admin manually > changes someone's password on the AD server, for example.) You must install PassSync on each and every domain controller. That's the only way PassSync can intercept the clear text password when someone changes his/her password. > > -- juniper (this is moderately hairy, but once it's worked out, I > will never need to touch it again, I hope) > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rwood at TrustedCS.com Tue Oct 20 20:02:59 2009 From: rwood at TrustedCS.com (Randall Wood) Date: Tue, 20 Oct 2009 16:02:59 -0400 Subject: [389-users] Directory admin is unable to edit user account Message-ID: <1256068979.16790.14.camel@localhost.localdomain> I am supporting an outfit that has two FDS servers configured for multiple-master replication. I do not have access to these servers. Today it was observed that on both of these servers, a user logging into the FDS Console as cn=Directory Manager is unable to edit the advanced properties on a user (to unlock a user's account), and that the Users OU is marked with a red X. I can not find any documentation that discusses why this red X would appear. What does this mean? Users of the systems supported by these FDS servers are still able to authenticate against the servers, and the administrators of the servers can not find anything relevant in the error logs. Is there anything you could suggest looking for? -- Randall Wood Secure Systems Engineer Trusted Computer Solutions 2350 Corporate Park Drive, Suite 500 Herndon, Virginia 20170 Tel (703) 537-4382 | Fax (703) 318-5041 rwood at trustedcs.com http://www.trustedcs.com From rwood at TrustedCS.com Tue Oct 20 20:40:27 2009 From: rwood at TrustedCS.com (Randall Wood) Date: Tue, 20 Oct 2009 16:40:27 -0400 Subject: [389-users] Directory admin is unable to edit user account In-Reply-To: <1256068979.16790.14.camel@localhost.localdomain> References: <1256068979.16790.14.camel@localhost.localdomain> Message-ID: <1256071227.18702.18.camel@localhost.localdomain> Further information: For the user that was uneditable: When first the password retry count is set to zero, we get the error when saving, but, if we reset the password retry count to zero and then change the uid by deleting the last character and retyping it, we can save the changes. Also: We were able to create a new user and change the password. We were also able to unlock another account. The problem seems to be just with this one account, but the red slash on the users group is still there. On Tue, 2009-10-20 at 16:02 -0400, Randall Wood wrote: > I am supporting an outfit that has two FDS servers configured for > multiple-master replication. I do not have access to these servers. > > Today it was observed that on both of these servers, a user logging into > the FDS Console as cn=Directory Manager is unable to edit the advanced > properties on a user (to unlock a user's account), and that the Users OU > is marked with a red X. > > I can not find any documentation that discusses why this red X would > appear. What does this mean? > > Users of the systems supported by these FDS servers are still able to > authenticate against the servers, and the administrators of the servers > can not find anything relevant in the error logs. Is there anything you > could suggest looking for? > -- Randall Wood Secure Systems Engineer Trusted Computer Solutions 2350 Corporate Park Drive, Suite 500 Herndon, Virginia 20170 Tel (703) 537-4382 | Fax (703) 318-5041 rwood at trustedcs.com http://www.trustedcs.com From dpartridge at tangible.net Wed Oct 21 15:13:37 2009 From: dpartridge at tangible.net (David Partridge) Date: Wed, 21 Oct 2009 11:13:37 -0400 Subject: [389-users] Schema Question Message-ID: <2F3DC4D41FA5994686AFFC36F1D661BE026E3683@wolverine.tangiblesoftware.com> We need to add in the pkiCA, pkiUser, and deltaCRL ObjectClasses to be in compliance with RFC 4523 to our DS builds. Are these subset of objectClasses from RFC 4523 for Compliance with RFC 4523? If these are correct I will continue this to make recommended changes for the Attribute and ObjectClasses defined in RFC 4523 for 00core.ldif in conjunction to my testing to propose to the 389 community. objectClasses: ( 2.5.6.22 NAME 'pkiCA' DESC 'X.509 PKI Certificate Authority' SUP top AUXILIARY MAY ( cACertificate $ certificateRevocationList $ authorityRevocationList $ crossCertificatePair ) X-ORIGIN 'RFC 4523' ) objectClasses: ( 2.5.6.23 NAME 'deltaCRL' DESC 'X.509 delta CRL' SUP top AUXILIARY MAY deltaRevocationList X-ORIGIN 'RFC 4523') objectClasses: ( 2.5.6.21 NAME 'pkiUser' DESC 'X.509 PKI User' SUP top AUXILIARY MAY userCertificate X-ORIGIN 'RFC 4523') Thanks David M. Partridge -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Oct 21 15:30:44 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 21 Oct 2009 09:30:44 -0600 Subject: [389-users] Re: Schema Question In-Reply-To: <2F3DC4D41FA5994686AFFC36F1D661BE026E3683@wolverine.tangiblesoftware.com> References: <2F3DC4D41FA5994686AFFC36F1D661BE026E3683@wolverine.tangiblesoftware.com> Message-ID: <4ADF2924.8030408@redhat.com> David Partridge wrote: > > We need to add in the pkiCA, pkiUser, and deltaCRL ObjectClasses to be > in compliance with RFC 4523 to our DS builds. > > > > Are these subset of objectClasses from RFC 4523 for Compliance with > RFC 4523? If these are correct I will continue this to make > recommended changes for the Attribute and ObjectClasses defined in RFC > 4523 for 00core.ldif in conjunction to my testing to propose to the > 389 community. > Please do not edit 00core.ldif. 389 1.2.1 has a separate schema file for this schema now - 05rfc4523.ldif - if you upgrade to 1.2.3 it will automatically fix existing schema to use this new schema file. > > > > objectClasses: ( 2.5.6.22 NAME 'pkiCA' DESC 'X.509 PKI Certificate > Authority' SUP top AUXILIARY MAY ( cACertificate $ > certificateRevocationList $ authorityRevocationList $ > crossCertificatePair ) X-ORIGIN 'RFC 4523' ) > > > > objectClasses: ( 2.5.6.23 NAME 'deltaCRL' DESC 'X.509 delta CRL' SUP > top AUXILIARY MAY deltaRevocationList X-ORIGIN 'RFC 4523') > > > > objectClasses: ( 2.5.6.21 NAME 'pkiUser' DESC 'X.509 PKI User' SUP > top AUXILIARY MAY userCertificate X-ORIGIN 'RFC 4523') > > > > Thanks > > > > *David M. Partridge* > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From across at itasoftware.com Wed Oct 21 16:39:59 2009 From: across at itasoftware.com (Anne Cross) Date: Wed, 21 Oct 2009 12:39:59 -0400 Subject: [389-users] 389, Active Directory, PassSync, Multi-Masters, and multiple AD servers In-Reply-To: <4ADE033D.5080006@redhat.com> References: <4ADDEBC1.3000009@itasoftware.com> <4ADE033D.5080006@redhat.com> Message-ID: <4ADF395F.5080702@itasoftware.com> Rich Megginson wrote: > Anne Cross wrote: >> We have two AD servers, and we're working on having four 389 Masters >> geographically distributed, multi-mastered between them, etc, etc, >> etc. The goal here is to stop having network hiccups take things out. >> >> The AD servers talk to each other nigh-on instantaneously. Likewise >> for the 389 servers. Is it safe to set up sync agreements to *both* >> AD servers, in case one goes down? > No. See https://bugzilla.redhat.com/show_bug.cgi?id=182515 and > https://bugzilla.redhat.com/show_bug.cgi?id=184155 Ah. OK, so that *is* a bug, and hopefully will get fixed at some future date. Good to know for now, however. Passwords continue to plague us, but that will be an email for another day. (With a lot more in the way of logs attached to it.) -- ,___, {o,o} Anne "Juniper" Cross (___) Senior Linux Systems Engineer and Extropic Crusader -"-"-- Information Technology, ITA Software /^^^ From brodie at mcw.edu Wed Oct 21 18:34:50 2009 From: brodie at mcw.edu (Brodie, Kent) Date: Wed, 21 Oct 2009 13:34:50 -0500 Subject: [389-users] Consumer failed to replay change Message-ID: <8F78639AC56F4143B267FE5F5A1B92C801D89BC6@guyton.phys.mcw.edu> Hi everyone. We're using FDS (389) 1.2.0. A few days ago, this started showing up in the logs on one of our two multi-master-replicated nodes: [17/Oct/2009:10:46:13 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Consumer failed to replay change (uniqueid 8d7abe0d-812811de-837b9eef-94681f9f, CSN 4a7b3c31000000020000): DSA is unwilling to perform. Will retry later. ... every 5 minutes. It's all the same "uniqueid", so it appears to be one particular replication request that just didn't work (don't know why). Replication is otherwise "OK".... What can I do to : * find out what replication change is failing, * why--- and * what can I do about it? I'm a bit new to this, so any help is greatly appreciated! (Presumably, I need a way to either accept the change, or probably also just indicate that the change, whatever it was, doesn't need to occur). From across at itasoftware.com Wed Oct 21 21:17:23 2009 From: across at itasoftware.com (Anne Cross) Date: Wed, 21 Oct 2009 17:17:23 -0400 Subject: [389-users] AD2008 on 64 bit windows, 389 Directory Server passwords... Message-ID: <4ADF7A63.7090802@itasoftware.com> I'm trying to sync passwords from 389 to Active Directory. If we import users from AD, then try to change their passwords, the replication locks up. If we create the users on 389, and sync them back to AD, the password field passed back is blank in Windows. Passsync isn't going to work because we're running 64bit Windows, so we can't sync the passwords *from* AD. I got this working earlier, but that was with FDS in a test instance several months ago, and I didn't write down what I did. (And I am kicking myself over that.) We can live without people changing their passwords on AD as long as we *can* sync passwords down from 389. The replication manager account on AD has full Directory Admin privs, so it *does* have the ability to update passwords. What am I missing? Our logs are showing us a lot of things that are not helpful; I will be happy to attach further logs if people can tell me what to look for, but we've been trying this for two days now, and we're not any closer than we were when we started. -- ,___, {o,o} Anne "Juniper" Cross (___) Senior Linux Systems Engineer and Extropic Crusader -"-"-- Information Technology, ITA Software /^^^ From morenisco at noc-root.net Thu Oct 22 09:03:45 2009 From: morenisco at noc-root.net (Morenisco) Date: Thu, 22 Oct 2009 06:03:45 -0300 Subject: [389-users] Basic questions on project-389 Message-ID: <4AE01FF1.5010006@noc-root.net> Hi, I was able to install project-389 on CentOS 5.4, and It was so easy! Good job! Well, something has changed from Fedora Directory Server, and now I don't know where are the scripts to start the directory server and the console (at least I found the log files :) ), then if you can give me a hand with that would be very good :) I have to do an speech on saturday, and It will be about directory server and Project-389 :) http://2009.encuentrolinux.cl/exposiciones/#ServiciodedirectorioconceptosbasicosherramientasyMultimasterReplication Regards! -- Morenisco. Centro de Difusi?n del Software Libre. http://www.cdsl.cl http://www.folasol.org http://trabajosfloss.cdsl.cl Blog: http://morenisco.noc-root.net From nevilchandran at gmail.com Thu Oct 22 10:15:29 2009 From: nevilchandran at gmail.com (nevil chandran) Date: Thu, 22 Oct 2009 15:45:29 +0530 Subject: [389-users] DS Version compatible for RHEL5 Message-ID: <7495f7c00910220315u835019dr97fc4fb11243ca32@mail.gmail.com> Hi,, Anybody can say whic version of Fedora DS is suitable for RHEL5 and also send me Link. Regards; Nevil -------------- next part -------------- An HTML attachment was scrubbed... URL: From muzzol at gmail.com Thu Oct 22 11:48:30 2009 From: muzzol at gmail.com (muzzol) Date: Thu, 22 Oct 2009 13:48:30 +0200 Subject: [389-users] DS Version compatible for RHEL5 In-Reply-To: <7495f7c00910220315u835019dr97fc4fb11243ca32@mail.gmail.com> References: <7495f7c00910220315u835019dr97fc4fb11243ca32@mail.gmail.com> Message-ID: <4a3f02760910220448n212608f6q3410eeb3233dbea7@mail.gmail.com> 2009/10/22 nevil chandran : > > > Hi,, > > Anybody can say whic version of Fedora DS is suitable for RHEL5 and also > send me Link. > http://directory.fedoraproject.org/wiki/Download -- ======================== ^ ^ O O (_ _) muzzol(a)muzzol.com ======================== jabber id: muzzol(a)jabber.dk ======================== No atribueixis qualitats humanes als ordinadors. No els hi agrada. ======================== "El gobierno espa?ol s?lo habla con terroristas, homosexuales y catalanes, a ver cuando se decide a hablar con gente normal" Jim?nez Losantos ======================== bomb terrorism bush aznar teletubbies From jsullivan at opensourcedevel.com Thu Oct 22 11:58:02 2009 From: jsullivan at opensourcedevel.com (John A. Sullivan III) Date: Thu, 22 Oct 2009 07:58:02 -0400 Subject: [389-users] DS Version compatible for RHEL5 In-Reply-To: <4a3f02760910220448n212608f6q3410eeb3233dbea7@mail.gmail.com> References: <7495f7c00910220315u835019dr97fc4fb11243ca32@mail.gmail.com> <4a3f02760910220448n212608f6q3410eeb3233dbea7@mail.gmail.com> Message-ID: <1256212682.6552.18.camel@jaspav.missionsit.net.missionsit.net> On Thu, 2009-10-22 at 13:48 +0200, muzzol wrote: > 2009/10/22 nevil chandran : > > > > > > Hi,, > > > > Anybody can say whic version of Fedora DS is suitable for RHEL5 and also > > send me Link. > > > > http://directory.fedoraproject.org/wiki/Download > I suppose one can use the RedHat Directory server. I don't believe it is nearly as up to date but it should interact well with your RHEL5. You can find it on the RedHat site, I believe - John -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan at opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society From rmeggins at redhat.com Thu Oct 22 14:14:26 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 22 Oct 2009 08:14:26 -0600 Subject: [389-users] Basic questions on project-389 In-Reply-To: <4AE01FF1.5010006@noc-root.net> References: <4AE01FF1.5010006@noc-root.net> Message-ID: <4AE068C2.1050105@redhat.com> Morenisco wrote: > Hi, > > I was able to install project-389 on CentOS 5.4, and It was so easy! > Good job! > > Well, something has changed from Fedora Directory Server, and now I > don't know where are the scripts to start the directory server service dirsrv start [instance name] instance name is optional or /usr/lib[64]/dirsrv/slapd-INSTANCE/start-slapd > and the console /usr/bin/389-console > (at least I found the log files :) ), then if you can give me a hand > with that would be very good :) > > I have to do an speech on saturday, and It will be about directory > server and Project-389 :) > > http://2009.encuentrolinux.cl/exposiciones/#ServiciodedirectorioconceptosbasicosherramientasyMultimasterReplication > > > Regards! > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Oct 22 14:16:53 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 22 Oct 2009 08:16:53 -0600 Subject: [389-users] AD2008 on 64 bit windows, 389 Directory Server passwords... In-Reply-To: <4ADF7A63.7090802@itasoftware.com> References: <4ADF7A63.7090802@itasoftware.com> Message-ID: <4AE06955.5030405@redhat.com> Anne Cross wrote: > I'm trying to sync passwords from 389 to Active Directory. > > If we import users from AD, then try to change their passwords, the > replication locks up. Can you be more specific? Have you tried the replication log level (which also logs winsync data) - http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting > If we create the users on 389, and sync them back to AD, the password > field passed back is blank in Windows. When you create the users on 389, are you using the clear text password in the userPassword field? > > Passsync isn't going to work because we're running 64bit Windows, so > we can't sync the passwords *from* AD. I got this working earlier, > but that was with FDS in a test instance several months ago, and I > didn't write down what I did. (And I am kicking myself over that.) > We can live without people changing their passwords on AD as long as > we *can* sync passwords down from 389. We are working on 64-bit Windows support. > > The replication manager account on AD has full Directory Admin privs, > so it *does* have the ability to update passwords. Try it with cn=administrator,cn=users,dc=yourdomain,dc=com to rule out any permissions issues. > > What am I missing? Our logs are showing us a lot of things that are > not helpful; I will be happy to attach further logs if people can tell > me what to look for, but we've been trying this for two days now, and > we're not any closer than we were when we started. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Oct 22 14:18:13 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 22 Oct 2009 08:18:13 -0600 Subject: [389-users] Consumer failed to replay change In-Reply-To: <8F78639AC56F4143B267FE5F5A1B92C801D89BC6@guyton.phys.mcw.edu> References: <8F78639AC56F4143B267FE5F5A1B92C801D89BC6@guyton.phys.mcw.edu> Message-ID: <4AE069A5.8050000@redhat.com> Brodie, Kent wrote: > Hi everyone. > > We're using FDS (389) 1.2.0. > > A few days ago, this started showing up in the logs on one of our two > multi-master-replicated nodes: > > [17/Oct/2009:10:46:13 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Consumer > failed to replay change (uniqueid 8d7abe0d-812811de-837b9eef-94681f9f, > CSN 4a7b3c31000000020000): DSA is unwilling to perform. Will retry > later. > > ... every 5 minutes. It's all the same "uniqueid", so it appears to > be one particular replication request that just didn't work (don't know > why). > > Replication is otherwise "OK".... > > What can I do to : > * find out what replication change is failing, > Search the access logs for CSN 4a7b3c31000000020000 to find out what operation that is Turn on the replication log level http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting to see more information about the operation that is causing problems > * why--- and > * what can I do about it? > > I'm a bit new to this, so any help is greatly appreciated! > > (Presumably, I need a way to either accept the change, or probably also > just indicate that the change, whatever it was, doesn't need to occur). > > > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Oct 22 14:19:09 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 22 Oct 2009 08:19:09 -0600 Subject: [389-users] Directory admin is unable to edit user account In-Reply-To: <1256071227.18702.18.camel@localhost.localdomain> References: <1256068979.16790.14.camel@localhost.localdomain> <1256071227.18702.18.camel@localhost.localdomain> Message-ID: <4AE069DD.3030208@redhat.com> Randall Wood wrote: > Further information: > > For the user that was uneditable: When first the password retry count is > set to zero, we get the error when saving, but, if we reset the password > retry count to zero and then change the uid by deleting the last > character and retyping it, we can save the changes. > > Also: We were able to create a new user and change the password. We > were also able to unlock another account. The problem seems to be just > with this one account, but the red slash on the users group is still > there. > start the console like this: 389-console -D 9 -f console.log then try to edit your user with the red slash > On Tue, 2009-10-20 at 16:02 -0400, Randall Wood wrote: > >> I am supporting an outfit that has two FDS servers configured for >> multiple-master replication. I do not have access to these servers. >> >> Today it was observed that on both of these servers, a user logging into >> the FDS Console as cn=Directory Manager is unable to edit the advanced >> properties on a user (to unlock a user's account), and that the Users OU >> is marked with a red X. >> >> I can not find any documentation that discusses why this red X would >> appear. What does this mean? >> >> Users of the systems supported by these FDS servers are still able to >> authenticate against the servers, and the administrators of the servers >> can not find anything relevant in the error logs. Is there anything you >> could suggest looking for? >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From brodie at mcw.edu Thu Oct 22 14:52:53 2009 From: brodie at mcw.edu (Brodie, Kent) Date: Thu, 22 Oct 2009 09:52:53 -0500 Subject: [389-users] Consumer failed to replay change In-Reply-To: <4AE069A5.8050000@redhat.com> References: <8F78639AC56F4143B267FE5F5A1B92C801D89BC6@guyton.phys.mcw.edu> <4AE069A5.8050000@redhat.com> Message-ID: <8F78639AC56F4143B267FE5F5A1B92C801D89BC9@guyton.phys.mcw.edu> Rich: Thanks for the debugging help! I'm still stuck, as I am not sure exactly what I am looking at in terms of messages. I can see that the same uniqueid 4922d291-be7a11de-adce9eef-94681f9f keeps failing, but the message surrounding that error are anything but clear to me. Can someone help look at this and translate what's going on? The log below is about 5 mins worth. [22/Oct/2009:09:36:08 -0500] - Fedora-Directory/1.2.0 B2009.118.181 starting up [22/Oct/2009:09:36:08 -0500] NSMMReplicationPlugin - changelog program - _cl5CheckGuardian: found old style of guardian file: bdb/4.3/libreplication-plugin [22/Oct/2009:09:36:09 -0500] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: semaphore /var/lib/dirsrv/slapd-white/changelogdb/f2291084-807511de-837b9eef-94681 f9f.sema [22/Oct/2009:09:36:09 -0500] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: maxConcurrentWrites=2 [22/Oct/2009:09:36:09 -0500] NSMMReplicationPlugin - changelog program - _cl5GetEntryCount: 500 changes for replica f2291084-807511de-837b9eef-94681f9f [22/Oct/2009:09:36:09 -0500] NSMMReplicationPlugin - changelog program - _cl5AddDBFile: Added new DB object 13901670 [22/Oct/2009:09:36:09 -0500] NSMMReplicationPlugin - changelog program - _cl5DBOpenFileByReplicaName: created new DB object 13901670 [22/Oct/2009:09:36:09 -0500] NSMMReplicationPlugin - changelog program - _cl5DBOpen: opened 1 existing databases in /var/lib/dirsrv/slapd-white/changelogdb [22/Oct/2009:09:36:09 -0500] NSMMReplicationPlugin - Found replication agreement named "cn="Replication to winters.hmgc.mcw.edu",cn=replica,cn="dc=hmgc, dc=mcw, dc=edu",cn=mapping tree,cn=config". [22/Oct/2009:09:36:09 -0500] NSMMReplicationPlugin - agmtlist_config_init: found 1 replication agreements in DIT [22/Oct/2009:09:36:09 -0500] NSMMReplicationPlugin - changelog program - _cl5GetDBFile: found DB object 13901670 for database f2291084-807511de-837b9eef-94681f9f_4a7758f2000000010000.db4 [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): No linger to cancel on the connection [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Disconnected from the consumer [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: start -> ready_to_acquire_replica [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Trying non-secure slapi_ldap_init_ext [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): binddn = cn=repman,cn=config, passwd = {DES}0U0krPfv0gLunf3SATmXQw== [22/Oct/2009:09:36:10 -0500] - _csngen_adjust_local_time: gen state before 4ae06db60001:1256222132:0:2 [22/Oct/2009:09:36:10 -0500] - _csngen_adjust_local_time: gen state after 4ae06ddc0000:1256222170:0:2 [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): No linger to cancel on the connection [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - ruv_add_csn_inprogress: successfully inserted csn 4ae06ddc000000020000 into pending list [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - Purged state information from entry dc=hmgc, dc=mcw, dc=edu up to CSN 4ad72c1e000000020000 [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - csn=4ae06ddc000000020000 process postop: canceling operation csn [22/Oct/2009:09:36:10 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [22/Oct/2009:09:36:10 -0500] - Listening on All Interfaces port 636 for LDAPS requests [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Replica was successfully acquired. [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: ready_to_acquire_replica -> sending_updates [22/Oct/2009:09:36:10 -0500] - csngen_adjust_time: gen state before 4ae06ddc0002:1256222170:0:2 [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - changelog program - _cl5GetDBFile: found DB object 13901670 for database f2291084-807511de-837b9eef-94681f9f_4a7758f2000000010000.db4 [22/Oct/2009:09:36:10 -0500] - _cl5PositionCursorForReplay (agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389)): Consumer RUV: [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replicageneration} 4a7758f2000000010000 [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica 1 ldap://winters.hmgc.mcw.edu:389} 4a799281000000010000 4adf7830000100010000 00000000 [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica 2 ldap://white.hmgc.mcw.edu:389} 4a78849d000000020000 4ae0612d000300020000 00000000 [22/Oct/2009:09:36:10 -0500] - _cl5PositionCursorForReplay (agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389)): Supplier RUV: [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replicageneration} 4a7758f2000000010000 [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica 2 ldap://white.hmgc.mcw.edu:389} 4a78849d000000020000 4ae0669e000000020000 00000000 [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica 1 ldap://winters.hmgc.mcw.edu:389} 4a799281000000010000 4adf7830000100010000 00000000 [22/Oct/2009:09:36:10 -0500] agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389) - session start: anchorcsn=4ae0612d000300020000 [22/Oct/2009:09:36:11 -0500] NSMMReplicationPlugin - changelog program - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): CSN 4ae0612d000300020000 found, position set for replay [22/Oct/2009:09:36:11 -0500] agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389) - load=1 rec=1 csn=4ae06697000000020000 [22/Oct/2009:09:36:11 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): replay_update: Sending modify operation (dn="uid=jgretzon,ou=spine,dc=hmgc,dc=mcw,dc=edu" csn=4ae06697000000020000) [22/Oct/2009:09:36:11 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): replay_update: Consumer successfully sent operation with csn 4ae06697000000020000 [22/Oct/2009:09:36:11 -0500] - repl5_inc_result_threadmain starting [22/Oct/2009:09:36:11 -0500] - repl5_inc_result_threadmain: read result for message_id 6 [22/Oct/2009:09:36:11 -0500] - repl5_inc_result_threadmain: result 3, 53, 1, 6, (null) [22/Oct/2009:09:36:11 -0500] agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389) - load=1 rec=2 csn=4ae0669e000000020000 [22/Oct/2009:09:36:11 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): replay_update: Sending modify operation (dn="uid=jgretzon,ou=spine,dc=hmgc,dc=mcw,dc=edu" csn=4ae0669e000000020000) [22/Oct/2009:09:36:11 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Consumer failed to replay change (uniqueid 4922d291-be7a11de-adce9eef-94681f9f, CSN 4ae06697000000020000): DSA is unwilling to perform. Will retry later. [22/Oct/2009:09:36:11 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): replay_update: Consumer successfully sent operation with csn 4ae0669e000000020000 [22/Oct/2009:09:36:11 -0500] - repl5_inc_result_threadmain: got op result 202 should finish 1 [22/Oct/2009:09:36:11 -0500] agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389) - clcache_load_buffer: rc=-30989 [22/Oct/2009:09:36:11 -0500] - repl5_inc_result_threadmain: read result for message_id 7 [22/Oct/2009:09:36:11 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): No more updates to send (cl5GetNextOperationToReplay) [22/Oct/2009:09:36:11 -0500] - repl5_inc_result_threadmain: result 3, 53, 1, 7, (null) [22/Oct/2009:09:36:11 -0500] - repl5_inc_waitfor_async_results: 7 7 [22/Oct/2009:09:36:11 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Consumer failed to replay change (uniqueid 4922d291-be7a11de-adce9eef-94681f9f, CSN 4ae0669e000000020000): DSA is unwilling to perform. Will retry later. [22/Oct/2009:09:36:11 -0500] - repl5_inc_result_threadmain: got op result 202 should finish 1 [22/Oct/2009:09:36:11 -0500] - repl5_inc_result_threadmain: read result for message_id 7 [22/Oct/2009:09:36:11 -0500] - repl5_inc_result_threadmain: read result for message_id 7 [22/Oct/2009:09:36:12 -0500] - repl5_inc_result_threadmain: read result for message_id 7 [22/Oct/2009:09:36:12 -0500] - repl5_inc_result_threadmain: read result for message_id 7 [22/Oct/2009:09:36:12 -0500] - repl5_inc_result_threadmain: read result for message_id 7 [22/Oct/2009:09:36:12 -0500] - repl5_inc_result_threadmain: read result for message_id 7 [22/Oct/2009:09:36:12 -0500] - repl5_inc_result_threadmain: read result for message_id 7 [22/Oct/2009:09:36:12 -0500] - repl5_inc_result_threadmain: read result for message_id 7 [22/Oct/2009:09:36:12 -0500] - repl5_inc_result_threadmain: read result for message_id 7 [22/Oct/2009:09:36:12 -0500] - repl5_inc_result_threadmain exiting [22/Oct/2009:09:36:12 -0500] agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389) - session end: state=5 load=1 sent=2 skipped=0 [22/Oct/2009:09:36:13 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Successfully released consumer [22/Oct/2009:09:36:14 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Beginning linger on the connection [22/Oct/2009:09:36:14 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: sending_updates -> wait_for_changes [22/Oct/2009:09:37:14 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Linger timeout has expired on the connection [22/Oct/2009:09:37:14 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Disconnected from the consumer [22/Oct/2009:09:41:14 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: wait_for_changes -> wait_for_changes [22/Oct/2009:09:41:15 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: wait_for_changes -> start [22/Oct/2009:09:41:15 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): No linger to cancel on the connection [22/Oct/2009:09:41:15 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Disconnected from the consumer [22/Oct/2009:09:41:15 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: start -> ready_to_acquire_replica [22/Oct/2009:09:41:15 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Trying non-secure slapi_ldap_init_ext [22/Oct/2009:09:41:15 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): binddn = cn=repman,cn=config, passwd = {DES}0U0krPfv0gLunf3SATmXQw== [22/Oct/2009:09:41:15 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): No linger to cancel on the connection [22/Oct/2009:09:41:15 -0500] - _csngen_adjust_local_time: gen state before 4ae06ddc0002:1256222170:0:2 [22/Oct/2009:09:41:15 -0500] - _csngen_adjust_local_time: gen state after 4ae06f0d0000:1256222475:0:2 [22/Oct/2009:09:41:16 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Replica was successfully acquired. [22/Oct/2009:09:41:16 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: ready_to_acquire_replica -> sending_updates [22/Oct/2009:09:41:16 -0500] - csngen_adjust_time: gen state before 4ae06f0d0001:1256222475:0:2 [22/Oct/2009:09:41:16 -0500] - _csngen_adjust_local_time: gen state before 4ae06f0d0001:1256222475:0:2 [22/Oct/2009:09:41:16 -0500] - _csngen_adjust_local_time: gen state after 4ae06f0e0000:1256222476:0:2 [22/Oct/2009:09:41:16 -0500] NSMMReplicationPlugin - changelog program - _cl5GetDBFile: found DB object 13901670 for database f2291084-807511de-837b9eef-94681f9f_4a7758f2000000010000.db4 [22/Oct/2009:09:41:16 -0500] - _cl5PositionCursorForReplay (agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389)): Consumer RUV: [22/Oct/2009:09:41:16 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replicageneration} 4a7758f2000000010000 [22/Oct/2009:09:41:16 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica 1 ldap://winters.hmgc.mcw.edu:389} 4a799281000000010000 4adf7830000100010000 00000000 [22/Oct/2009:09:41:16 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica 2 ldap://white.hmgc.mcw.edu:389} 4a78849d000000020000 4ae0612d000300020000 00000000 [22/Oct/2009:09:41:16 -0500] - _cl5PositionCursorForReplay (agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389)): Supplier RUV: [22/Oct/2009:09:41:16 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replicageneration} 4a7758f2000000010000 [22/Oct/2009:09:41:16 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica 2 ldap://white.hmgc.mcw.edu:389} 4a78849d000000020000 4ae0669e000000020000 00000000 [22/Oct/2009:09:41:16 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica 1 ldap://winters.hmgc.mcw.edu:389} 4a799281000000010000 4adf7830000100010000 00000000 [22/Oct/2009:09:41:16 -0500] agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389) - clcache_get_buffer: found thread private buffer cache 13a76610 [22/Oct/2009:09:41:16 -0500] agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389) - clcache_get_buffer: _pool is 13963c90 _pool->pl_busy_lists is 13903780 _pool->pl_busy_lists->bl_buffers is 13a76610 [22/Oct/2009:09:41:17 -0500] agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389) - session start: anchorcsn=4ae0612d000300020000 [22/Oct/2009:09:41:17 -0500] NSMMReplicationPlugin - changelog program - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): CSN 4ae0612d000300020000 found, position set for replay [22/Oct/2009:09:41:17 -0500] agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389) - load=1 rec=1 csn=4ae06697000000020000 [22/Oct/2009:09:41:17 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): replay_update: Sending modify operation (dn="uid=jgretzon,ou=spine,dc=hmgc,dc=mcw,dc=edu" csn=4ae06697000000020000) [22/Oct/2009:09:41:17 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): replay_update: Consumer successfully sent operation with csn 4ae06697000000020000 [22/Oct/2009:09:41:17 -0500] - repl5_inc_result_threadmain starting [22/Oct/2009:09:41:17 -0500] - repl5_inc_result_threadmain: read result for message_id 5 [22/Oct/2009:09:41:17 -0500] - repl5_inc_result_threadmain: result 3, 53, 1, 5, (null) [22/Oct/2009:09:41:17 -0500] agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389) - load=1 rec=2 csn=4ae0669e000000020000 [22/Oct/2009:09:41:18 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Consumer failed to replay change (uniqueid 4922d291-be7a11de-adce9eef-94681f9f, CSN 4ae06697000000020000): DSA is unwilling to perform. Will retry later. [22/Oct/2009:09:41:19 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): replay_update: Sending modify operation (dn="uid=jgretzon,ou=spine,dc=hmgc,dc=mcw,dc=edu" csn=4ae0669e000000020000) [22/Oct/2009:09:41:19 -0500] - repl5_inc_result_threadmain: got op result 202 should finish 1 [22/Oct/2009:09:41:19 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): replay_update: Consumer successfully sent operation with csn 4ae0669e000000020000 [22/Oct/2009:09:41:19 -0500] - repl5_inc_result_threadmain: read result for message_id 6 [22/Oct/2009:09:41:19 -0500] - repl5_inc_waitfor_async_results: 5 6 [22/Oct/2009:09:41:19 -0500] - repl5_inc_result_threadmain: result 3, 53, 1, 6, (null) [22/Oct/2009:09:41:19 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Consumer failed to replay change (uniqueid 4922d291-be7a11de-adce9eef-94681f9f, CSN 4ae0669e000000020000): DSA is unwilling to perform. Will retry later. [22/Oct/2009:09:41:19 -0500] - repl5_inc_result_threadmain: got op result 202 should finish 1 [22/Oct/2009:09:41:19 -0500] - repl5_inc_result_threadmain: read result for message_id 6 [22/Oct/2009:09:41:19 -0500] - repl5_inc_result_threadmain: read result for message_id 6 [22/Oct/2009:09:41:19 -0500] - repl5_inc_result_threadmain: read result for message_id 6 [22/Oct/2009:09:41:20 -0500] - repl5_inc_result_threadmain: read result for message_id 6 [22/Oct/2009:09:41:20 -0500] - repl5_inc_result_threadmain: read result for message_id 6 [22/Oct/2009:09:41:20 -0500] - repl5_inc_result_threadmain: read result for message_id 6 [22/Oct/2009:09:41:20 -0500] - repl5_inc_result_threadmain: read result for message_id 6 [22/Oct/2009:09:41:20 -0500] - repl5_inc_result_threadmain: read result for message_id 6 [22/Oct/2009:09:41:20 -0500] - repl5_inc_result_threadmain: read result for message_id 6 [22/Oct/2009:09:41:20 -0500] - repl5_inc_result_threadmain exiting [22/Oct/2009:09:41:20 -0500] agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389) - session end: state=0 load=1 sent=2 skipped=0 [22/Oct/2009:09:41:23 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Successfully released consumer [22/Oct/2009:09:41:23 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Beginning linger on the connection [22/Oct/2009:09:41:23 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: sending_updates -> start_backoff [22/Oct/2009:09:41:26 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: start_backoff -> backoff [22/Oct/2009:09:41:26 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Cancelling linger on the connection [22/Oct/2009:09:41:26 -0500] - _csngen_adjust_local_time: gen state before 4ae06f0e0000:1256222476:0:2 [22/Oct/2009:09:41:26 -0500] - _csngen_adjust_local_time: gen state after 4ae06f180000:1256222486:0:2 [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Replica was successfully acquired. [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: backoff -> sending_updates [22/Oct/2009:09:41:27 -0500] - csngen_adjust_time: gen state before 4ae06f180001:1256222486:0:2 [22/Oct/2009:09:41:27 -0500] - _csngen_adjust_local_time: gen state before 4ae06f180001:1256222486:0:2 [22/Oct/2009:09:41:27 -0500] - _csngen_adjust_local_time: gen state after 4ae06f190000:1256222487:0:2 [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - changelog program - _cl5GetDBFile: found DB object 13901670 for database f2291084-807511de-837b9eef-94681f9f_4a7758f2000000010000.db4 [22/Oct/2009:09:41:27 -0500] - _cl5PositionCursorForReplay (agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389)): Consumer RUV: [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replicageneration} 4a7758f2000000010000 [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica 1 ldap://winters.hmgc.mcw.edu:389} 4a799281000000010000 4adf7830000100010000 00000000 [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica 2 ldap://white.hmgc.mcw.edu:389} 4a78849d000000020000 4ae0612d000300020000 00000000 [22/Oct/2009:09:41:27 -0500] - _cl5PositionCursorForReplay (agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389)): Supplier RUV: [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replicageneration} 4a7758f2000000010000 [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica 2 ldap://white.hmgc.mcw.edu:389} 4a78849d000000020000 4ae0669e000000020000 00000000 [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica 1 ldap://winters.hmgc.mcw.edu:389} 4a799281000000010000 4adf7830000100010000 00000000 [22/Oct/2009:09:41:27 -0500] agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389) - clcache_get_buffer: found thread private buffer cache 13a76610 [22/Oct/2009:09:41:27 -0500] agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389) - clcache_get_buffer: _pool is 13963c90 _pool->pl_busy_lists is 13903780 _pool->pl_busy_lists->bl_buffers is 13a76610 [22/Oct/2009:09:41:27 -0500] agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389) - session start: anchorcsn=4ae0612d000300020000 [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - changelog program - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): CSN 4ae0612d000300020000 found, position set for replay [22/Oct/2009:09:41:27 -0500] agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389) - load=1 rec=1 csn=4ae06697000000020000 [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): replay_update: Sending modify operation (dn="uid=jgretzon,ou=spine,dc=hmgc,dc=mcw,dc=edu" csn=4ae06697000000020000) [22/Oct/2009:09:41:28 -0500] - repl5_inc_result_threadmain starting [22/Oct/2009:09:41:28 -0500] - repl5_inc_result_threadmain: read result for message_id 9 [22/Oct/2009:09:41:28 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): replay_update: Consumer successfully sent operation with csn 4ae06697000000020000 [22/Oct/2009:09:41:28 -0500] agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389) - load=1 rec=2 csn=4ae0669e000000020000 [22/Oct/2009:09:41:28 -0500] - repl5_inc_result_threadmain: result 3, 53, 1, 9, (null) [22/Oct/2009:09:41:28 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): replay_update: Sending modify operation (dn="uid=jgretzon,ou=spine,dc=hmgc,dc=mcw,dc=edu" csn=4ae0669e000000020000) [22/Oct/2009:09:41:28 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Consumer failed to replay change (uniqueid (null), CSN (null)): DSA is unwilling to perform. Will retry later. [22/Oct/2009:09:41:28 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): replay_update: Consumer successfully sent operation with csn 4ae0669e000000020000 [22/Oct/2009:09:41:28 -0500] - repl5_inc_result_threadmain: got op result 202 should finish 1 [22/Oct/2009:09:41:28 -0500] agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389) - clcache_load_buffer: rc=-30989 [22/Oct/2009:09:41:28 -0500] - repl5_inc_result_threadmain: read result for message_id 10 [22/Oct/2009:09:41:28 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): No more updates to send (cl5GetNextOperationToReplay) [22/Oct/2009:09:41:28 -0500] - repl5_inc_result_threadmain: result 3, 53, 1, 10, (null) [22/Oct/2009:09:41:28 -0500] - repl5_inc_waitfor_async_results: 10 10 [22/Oct/2009:09:41:28 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Consumer failed to replay change (uniqueid 4922d291-be7a11de-adce9eef-94681f9f, CSN 4ae06697000000020000): DSA is unwilling to perform. Will retry later. [22/Oct/2009:09:41:28 -0500] - repl5_inc_result_threadmain: got op result 202 should finish 1 [22/Oct/2009:09:41:28 -0500] - repl5_inc_result_threadmain: read result for message_id 10 [22/Oct/2009:09:41:28 -0500] - repl5_inc_result_threadmain: read result for message_id 10 [22/Oct/2009:09:41:29 -0500] - repl5_inc_result_threadmain: read result for message_id 10 [22/Oct/2009:09:41:29 -0500] - repl5_inc_result_threadmain: read result for message_id 10 [22/Oct/2009:09:41:29 -0500] - repl5_inc_result_threadmain: read result for message_id 10 [22/Oct/2009:09:41:29 -0500] - repl5_inc_result_threadmain: read result for message_id 10 [22/Oct/2009:09:41:29 -0500] - repl5_inc_result_threadmain: read result for message_id 10 [22/Oct/2009:09:41:29 -0500] - repl5_inc_result_threadmain: read result for message_id 10 [22/Oct/2009:09:41:29 -0500] - repl5_inc_result_threadmain: read result for message_id 10 [22/Oct/2009:09:41:29 -0500] - repl5_inc_result_threadmain exiting [22/Oct/2009:09:41:29 -0500] agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389) - session end: state=5 load=1 sent=2 skipped=0 [22/Oct/2009:09:41:30 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Successfully released consumer [22/Oct/2009:09:41:30 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Beginning linger on the connection [22/Oct/2009:09:41:30 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: sending_updates -> wait_for_changes [22/Oct/2009:09:42:30 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Linger timeout has expired on the connection [22/Oct/2009:09:42:30 -0500] NSMMReplicationPlugin - agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Disconnected from the consumer [22/Oct/2009:09:46:24 -0500] - slapd shutting down - signaling operation threads [22/Oct/2009:09:46:24 -0500] - slapd shutting down - waiting for 29 threads to terminate [22/Oct/2009:09:46:24 -0500] - slapd shutting down - closing down internal subsystems and plugins [22/Oct/2009:09:46:26 -0500] - Waiting for 4 database threads to stop [22/Oct/2009:09:46:27 -0500] - All database threads now stopped [22/Oct/2009:09:46:27 -0500] - slapd stopped. From rmeggins at redhat.com Thu Oct 22 15:05:20 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 22 Oct 2009 09:05:20 -0600 Subject: [389-users] Consumer failed to replay change In-Reply-To: <8F78639AC56F4143B267FE5F5A1B92C801D89BC9@guyton.phys.mcw.edu> References: <8F78639AC56F4143B267FE5F5A1B92C801D89BC6@guyton.phys.mcw.edu> <4AE069A5.8050000@redhat.com> <8F78639AC56F4143B267FE5F5A1B92C801D89BC9@guyton.phys.mcw.edu> Message-ID: <4AE074B0.7050007@redhat.com> Brodie, Kent wrote: > Rich: Thanks for the debugging help! I'm still stuck, as I am not > sure exactly what I am looking at in terms of messages. I can see that > the same uniqueid 4922d291-be7a11de-adce9eef-94681f9f keeps failing, but > the message surrounding that error are anything but clear to me. > Try using the /usr/bin/cl-dump tool to dump the changelog (man cl-dump) - look for uniqueid 4922d291-be7a11de-adce9eef-94681f9f and dn="uid=jgretzon,ou=spine,dc=hmgc,dc=mcw,dc=edu" and csn=4ae06697000000020000 > Can someone help look at this and translate what's going on? The log > below is about 5 mins worth. > > > [22/Oct/2009:09:36:08 -0500] - Fedora-Directory/1.2.0 B2009.118.181 > starting up > [22/Oct/2009:09:36:08 -0500] NSMMReplicationPlugin - changelog program - > _cl5CheckGuardian: found old style of guardian file: > bdb/4.3/libreplication-plugin > [22/Oct/2009:09:36:09 -0500] NSMMReplicationPlugin - changelog program - > _cl5NewDBFile: semaphore > /var/lib/dirsrv/slapd-white/changelogdb/f2291084-807511de-837b9eef-94681 > f9f.sema > [22/Oct/2009:09:36:09 -0500] NSMMReplicationPlugin - changelog program - > _cl5NewDBFile: maxConcurrentWrites=2 > [22/Oct/2009:09:36:09 -0500] NSMMReplicationPlugin - changelog program - > _cl5GetEntryCount: 500 changes for replica > f2291084-807511de-837b9eef-94681f9f > [22/Oct/2009:09:36:09 -0500] NSMMReplicationPlugin - changelog program - > _cl5AddDBFile: Added new DB object 13901670 > [22/Oct/2009:09:36:09 -0500] NSMMReplicationPlugin - changelog program - > _cl5DBOpenFileByReplicaName: created new DB object 13901670 > [22/Oct/2009:09:36:09 -0500] NSMMReplicationPlugin - changelog program - > _cl5DBOpen: opened 1 existing databases in > /var/lib/dirsrv/slapd-white/changelogdb > [22/Oct/2009:09:36:09 -0500] NSMMReplicationPlugin - Found replication > agreement named "cn="Replication to > winters.hmgc.mcw.edu",cn=replica,cn="dc=hmgc, dc=mcw, dc=edu",cn=mapping > tree,cn=config". > [22/Oct/2009:09:36:09 -0500] NSMMReplicationPlugin - > agmtlist_config_init: found 1 replication agreements in DIT > [22/Oct/2009:09:36:09 -0500] NSMMReplicationPlugin - changelog program - > _cl5GetDBFile: found DB object 13901670 for database > f2291084-807511de-837b9eef-94681f9f_4a7758f2000000010000.db4 > [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): No linger > to cancel on the connection > [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > Disconnected from the consumer > [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: > start -> ready_to_acquire_replica > [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Trying > non-secure slapi_ldap_init_ext > [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): binddn = > cn=repman,cn=config, passwd = {DES}0U0krPfv0gLunf3SATmXQw== > [22/Oct/2009:09:36:10 -0500] - _csngen_adjust_local_time: gen state > before 4ae06db60001:1256222132:0:2 > [22/Oct/2009:09:36:10 -0500] - _csngen_adjust_local_time: gen state > after 4ae06ddc0000:1256222170:0:2 > [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): No linger > to cancel on the connection > [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - > ruv_add_csn_inprogress: successfully inserted csn 4ae06ddc000000020000 > into pending list > [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - Purged state > information from entry dc=hmgc, dc=mcw, dc=edu up to CSN > 4ad72c1e000000020000 > [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - > csn=4ae06ddc000000020000 process postop: canceling operation csn > [22/Oct/2009:09:36:10 -0500] - slapd started. Listening on All > Interfaces port 389 for LDAP requests > [22/Oct/2009:09:36:10 -0500] - Listening on All Interfaces port 636 for > LDAPS requests > [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Replica > was successfully acquired. > [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: > ready_to_acquire_replica -> sending_updates > [22/Oct/2009:09:36:10 -0500] - csngen_adjust_time: gen state before > 4ae06ddc0002:1256222170:0:2 > [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - changelog program - > _cl5GetDBFile: found DB object 13901670 for database > f2291084-807511de-837b9eef-94681f9f_4a7758f2000000010000.db4 > [22/Oct/2009:09:36:10 -0500] - _cl5PositionCursorForReplay > (agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389)): > Consumer RUV: > [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > {replicageneration} 4a7758f2000000010000 > [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica > 1 ldap://winters.hmgc.mcw.edu:389} 4a799281000000010000 > 4adf7830000100010000 00000000 > [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica > 2 ldap://white.hmgc.mcw.edu:389} 4a78849d000000020000 > 4ae0612d000300020000 00000000 > [22/Oct/2009:09:36:10 -0500] - _cl5PositionCursorForReplay > (agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389)): > Supplier RUV: > [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > {replicageneration} 4a7758f2000000010000 > [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica > 2 ldap://white.hmgc.mcw.edu:389} 4a78849d000000020000 > 4ae0669e000000020000 00000000 > [22/Oct/2009:09:36:10 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica > 1 ldap://winters.hmgc.mcw.edu:389} 4a799281000000010000 > 4adf7830000100010000 00000000 > [22/Oct/2009:09:36:10 -0500] agmt="cn="Replication to > winters.hmgc.mcw.edu"" (winters:389) - session start: > anchorcsn=4ae0612d000300020000 > [22/Oct/2009:09:36:11 -0500] NSMMReplicationPlugin - changelog program - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): CSN > 4ae0612d000300020000 found, position set for replay > [22/Oct/2009:09:36:11 -0500] agmt="cn="Replication to > winters.hmgc.mcw.edu"" (winters:389) - load=1 rec=1 > csn=4ae06697000000020000 > [22/Oct/2009:09:36:11 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > replay_update: Sending modify operation > (dn="uid=jgretzon,ou=spine,dc=hmgc,dc=mcw,dc=edu" > csn=4ae06697000000020000) > [22/Oct/2009:09:36:11 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > replay_update: Consumer successfully sent operation with csn > 4ae06697000000020000 > [22/Oct/2009:09:36:11 -0500] - repl5_inc_result_threadmain starting > [22/Oct/2009:09:36:11 -0500] - repl5_inc_result_threadmain: read result > for message_id 6 > [22/Oct/2009:09:36:11 -0500] - repl5_inc_result_threadmain: result 3, > 53, 1, 6, (null) > [22/Oct/2009:09:36:11 -0500] agmt="cn="Replication to > winters.hmgc.mcw.edu"" (winters:389) - load=1 rec=2 > csn=4ae0669e000000020000 > [22/Oct/2009:09:36:11 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > replay_update: Sending modify operation > (dn="uid=jgretzon,ou=spine,dc=hmgc,dc=mcw,dc=edu" > csn=4ae0669e000000020000) > [22/Oct/2009:09:36:11 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Consumer > failed to replay change (uniqueid 4922d291-be7a11de-adce9eef-94681f9f, > CSN 4ae06697000000020000): DSA is unwilling to perform. Will retry > later. > [22/Oct/2009:09:36:11 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > replay_update: Consumer successfully sent operation with csn > 4ae0669e000000020000 > [22/Oct/2009:09:36:11 -0500] - repl5_inc_result_threadmain: got op > result 202 should finish 1 > [22/Oct/2009:09:36:11 -0500] agmt="cn="Replication to > winters.hmgc.mcw.edu"" (winters:389) - clcache_load_buffer: rc=-30989 > [22/Oct/2009:09:36:11 -0500] - repl5_inc_result_threadmain: read result > for message_id 7 > [22/Oct/2009:09:36:11 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): No more > updates to send (cl5GetNextOperationToReplay) > [22/Oct/2009:09:36:11 -0500] - repl5_inc_result_threadmain: result 3, > 53, 1, 7, (null) > [22/Oct/2009:09:36:11 -0500] - repl5_inc_waitfor_async_results: 7 7 > [22/Oct/2009:09:36:11 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Consumer > failed to replay change (uniqueid 4922d291-be7a11de-adce9eef-94681f9f, > CSN 4ae0669e000000020000): DSA is unwilling to perform. Will retry > later. > [22/Oct/2009:09:36:11 -0500] - repl5_inc_result_threadmain: got op > result 202 should finish 1 > [22/Oct/2009:09:36:11 -0500] - repl5_inc_result_threadmain: read result > for message_id 7 > [22/Oct/2009:09:36:11 -0500] - repl5_inc_result_threadmain: read result > for message_id 7 > [22/Oct/2009:09:36:12 -0500] - repl5_inc_result_threadmain: read result > for message_id 7 > [22/Oct/2009:09:36:12 -0500] - repl5_inc_result_threadmain: read result > for message_id 7 > [22/Oct/2009:09:36:12 -0500] - repl5_inc_result_threadmain: read result > for message_id 7 > [22/Oct/2009:09:36:12 -0500] - repl5_inc_result_threadmain: read result > for message_id 7 > [22/Oct/2009:09:36:12 -0500] - repl5_inc_result_threadmain: read result > for message_id 7 > [22/Oct/2009:09:36:12 -0500] - repl5_inc_result_threadmain: read result > for message_id 7 > [22/Oct/2009:09:36:12 -0500] - repl5_inc_result_threadmain: read result > for message_id 7 > [22/Oct/2009:09:36:12 -0500] - repl5_inc_result_threadmain exiting > [22/Oct/2009:09:36:12 -0500] agmt="cn="Replication to > winters.hmgc.mcw.edu"" (winters:389) - session end: state=5 load=1 > sent=2 skipped=0 > [22/Oct/2009:09:36:13 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > Successfully released consumer > [22/Oct/2009:09:36:14 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Beginning > linger on the connection > [22/Oct/2009:09:36:14 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: > sending_updates -> wait_for_changes > [22/Oct/2009:09:37:14 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Linger > timeout has expired on the connection > [22/Oct/2009:09:37:14 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > Disconnected from the consumer > > > [22/Oct/2009:09:41:14 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: > wait_for_changes -> wait_for_changes > [22/Oct/2009:09:41:15 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: > wait_for_changes -> start > [22/Oct/2009:09:41:15 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): No linger > to cancel on the connection > [22/Oct/2009:09:41:15 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > Disconnected from the consumer > [22/Oct/2009:09:41:15 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: > start -> ready_to_acquire_replica > [22/Oct/2009:09:41:15 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Trying > non-secure slapi_ldap_init_ext > [22/Oct/2009:09:41:15 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): binddn = > cn=repman,cn=config, passwd = {DES}0U0krPfv0gLunf3SATmXQw== > [22/Oct/2009:09:41:15 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): No linger > to cancel on the connection > [22/Oct/2009:09:41:15 -0500] - _csngen_adjust_local_time: gen state > before 4ae06ddc0002:1256222170:0:2 > [22/Oct/2009:09:41:15 -0500] - _csngen_adjust_local_time: gen state > after 4ae06f0d0000:1256222475:0:2 > [22/Oct/2009:09:41:16 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Replica > was successfully acquired. > [22/Oct/2009:09:41:16 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: > ready_to_acquire_replica -> sending_updates > [22/Oct/2009:09:41:16 -0500] - csngen_adjust_time: gen state before > 4ae06f0d0001:1256222475:0:2 > [22/Oct/2009:09:41:16 -0500] - _csngen_adjust_local_time: gen state > before 4ae06f0d0001:1256222475:0:2 > [22/Oct/2009:09:41:16 -0500] - _csngen_adjust_local_time: gen state > after 4ae06f0e0000:1256222476:0:2 > [22/Oct/2009:09:41:16 -0500] NSMMReplicationPlugin - changelog program - > _cl5GetDBFile: found DB object 13901670 for database > f2291084-807511de-837b9eef-94681f9f_4a7758f2000000010000.db4 > [22/Oct/2009:09:41:16 -0500] - _cl5PositionCursorForReplay > (agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389)): > Consumer RUV: > [22/Oct/2009:09:41:16 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > {replicageneration} 4a7758f2000000010000 > [22/Oct/2009:09:41:16 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica > 1 ldap://winters.hmgc.mcw.edu:389} 4a799281000000010000 > 4adf7830000100010000 00000000 > [22/Oct/2009:09:41:16 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica > 2 ldap://white.hmgc.mcw.edu:389} 4a78849d000000020000 > 4ae0612d000300020000 00000000 > [22/Oct/2009:09:41:16 -0500] - _cl5PositionCursorForReplay > (agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389)): > Supplier RUV: > [22/Oct/2009:09:41:16 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > {replicageneration} 4a7758f2000000010000 > [22/Oct/2009:09:41:16 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica > 2 ldap://white.hmgc.mcw.edu:389} 4a78849d000000020000 > 4ae0669e000000020000 00000000 > [22/Oct/2009:09:41:16 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica > 1 ldap://winters.hmgc.mcw.edu:389} 4a799281000000010000 > 4adf7830000100010000 00000000 > [22/Oct/2009:09:41:16 -0500] agmt="cn="Replication to > winters.hmgc.mcw.edu"" (winters:389) - clcache_get_buffer: found thread > private buffer cache 13a76610 > [22/Oct/2009:09:41:16 -0500] agmt="cn="Replication to > winters.hmgc.mcw.edu"" (winters:389) - clcache_get_buffer: _pool is > 13963c90 _pool->pl_busy_lists is 13903780 > _pool->pl_busy_lists->bl_buffers is 13a76610 > [22/Oct/2009:09:41:17 -0500] agmt="cn="Replication to > winters.hmgc.mcw.edu"" (winters:389) - session start: > anchorcsn=4ae0612d000300020000 > [22/Oct/2009:09:41:17 -0500] NSMMReplicationPlugin - changelog program - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): CSN > 4ae0612d000300020000 found, position set for replay > [22/Oct/2009:09:41:17 -0500] agmt="cn="Replication to > winters.hmgc.mcw.edu"" (winters:389) - load=1 rec=1 > csn=4ae06697000000020000 > [22/Oct/2009:09:41:17 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > replay_update: Sending modify operation > (dn="uid=jgretzon,ou=spine,dc=hmgc,dc=mcw,dc=edu" > csn=4ae06697000000020000) > [22/Oct/2009:09:41:17 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > replay_update: Consumer successfully sent operation with csn > 4ae06697000000020000 > [22/Oct/2009:09:41:17 -0500] - repl5_inc_result_threadmain starting > [22/Oct/2009:09:41:17 -0500] - repl5_inc_result_threadmain: read result > for message_id 5 > [22/Oct/2009:09:41:17 -0500] - repl5_inc_result_threadmain: result 3, > 53, 1, 5, (null) > [22/Oct/2009:09:41:17 -0500] agmt="cn="Replication to > winters.hmgc.mcw.edu"" (winters:389) - load=1 rec=2 > csn=4ae0669e000000020000 > [22/Oct/2009:09:41:18 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Consumer > failed to replay change (uniqueid 4922d291-be7a11de-adce9eef-94681f9f, > CSN 4ae06697000000020000): DSA is unwilling to perform. Will retry > later. > [22/Oct/2009:09:41:19 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > replay_update: Sending modify operation > (dn="uid=jgretzon,ou=spine,dc=hmgc,dc=mcw,dc=edu" > csn=4ae0669e000000020000) > [22/Oct/2009:09:41:19 -0500] - repl5_inc_result_threadmain: got op > result 202 should finish 1 > [22/Oct/2009:09:41:19 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > replay_update: Consumer successfully sent operation with csn > 4ae0669e000000020000 > [22/Oct/2009:09:41:19 -0500] - repl5_inc_result_threadmain: read result > for message_id 6 > [22/Oct/2009:09:41:19 -0500] - repl5_inc_waitfor_async_results: 5 6 > [22/Oct/2009:09:41:19 -0500] - repl5_inc_result_threadmain: result 3, > 53, 1, 6, (null) > [22/Oct/2009:09:41:19 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Consumer > failed to replay change (uniqueid 4922d291-be7a11de-adce9eef-94681f9f, > CSN 4ae0669e000000020000): DSA is unwilling to perform. Will retry > later. > [22/Oct/2009:09:41:19 -0500] - repl5_inc_result_threadmain: got op > result 202 should finish 1 > [22/Oct/2009:09:41:19 -0500] - repl5_inc_result_threadmain: read result > for message_id 6 > [22/Oct/2009:09:41:19 -0500] - repl5_inc_result_threadmain: read result > for message_id 6 > [22/Oct/2009:09:41:19 -0500] - repl5_inc_result_threadmain: read result > for message_id 6 > [22/Oct/2009:09:41:20 -0500] - repl5_inc_result_threadmain: read result > for message_id 6 > [22/Oct/2009:09:41:20 -0500] - repl5_inc_result_threadmain: read result > for message_id 6 > [22/Oct/2009:09:41:20 -0500] - repl5_inc_result_threadmain: read result > for message_id 6 > [22/Oct/2009:09:41:20 -0500] - repl5_inc_result_threadmain: read result > for message_id 6 > [22/Oct/2009:09:41:20 -0500] - repl5_inc_result_threadmain: read result > for message_id 6 > [22/Oct/2009:09:41:20 -0500] - repl5_inc_result_threadmain: read result > for message_id 6 > [22/Oct/2009:09:41:20 -0500] - repl5_inc_result_threadmain exiting > [22/Oct/2009:09:41:20 -0500] agmt="cn="Replication to > winters.hmgc.mcw.edu"" (winters:389) - session end: state=0 load=1 > sent=2 skipped=0 > [22/Oct/2009:09:41:23 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > Successfully released consumer > [22/Oct/2009:09:41:23 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Beginning > linger on the connection > [22/Oct/2009:09:41:23 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: > sending_updates -> start_backoff > [22/Oct/2009:09:41:26 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: > start_backoff -> backoff > [22/Oct/2009:09:41:26 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > Cancelling linger on the connection > [22/Oct/2009:09:41:26 -0500] - _csngen_adjust_local_time: gen state > before 4ae06f0e0000:1256222476:0:2 > [22/Oct/2009:09:41:26 -0500] - _csngen_adjust_local_time: gen state > after 4ae06f180000:1256222486:0:2 > [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Replica > was successfully acquired. > [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: > backoff -> sending_updates > [22/Oct/2009:09:41:27 -0500] - csngen_adjust_time: gen state before > 4ae06f180001:1256222486:0:2 > [22/Oct/2009:09:41:27 -0500] - _csngen_adjust_local_time: gen state > before 4ae06f180001:1256222486:0:2 > [22/Oct/2009:09:41:27 -0500] - _csngen_adjust_local_time: gen state > after 4ae06f190000:1256222487:0:2 > [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - changelog program - > _cl5GetDBFile: found DB object 13901670 for database > f2291084-807511de-837b9eef-94681f9f_4a7758f2000000010000.db4 > [22/Oct/2009:09:41:27 -0500] - _cl5PositionCursorForReplay > (agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389)): > Consumer RUV: > [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > {replicageneration} 4a7758f2000000010000 > [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica > 1 ldap://winters.hmgc.mcw.edu:389} 4a799281000000010000 > 4adf7830000100010000 00000000 > [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica > 2 ldap://white.hmgc.mcw.edu:389} 4a78849d000000020000 > 4ae0612d000300020000 00000000 > [22/Oct/2009:09:41:27 -0500] - _cl5PositionCursorForReplay > (agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389)): > Supplier RUV: > [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > {replicageneration} 4a7758f2000000010000 > [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica > 2 ldap://white.hmgc.mcw.edu:389} 4a78849d000000020000 > 4ae0669e000000020000 00000000 > [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): {replica > 1 ldap://winters.hmgc.mcw.edu:389} 4a799281000000010000 > 4adf7830000100010000 00000000 > [22/Oct/2009:09:41:27 -0500] agmt="cn="Replication to > winters.hmgc.mcw.edu"" (winters:389) - clcache_get_buffer: found thread > private buffer cache 13a76610 > [22/Oct/2009:09:41:27 -0500] agmt="cn="Replication to > winters.hmgc.mcw.edu"" (winters:389) - clcache_get_buffer: _pool is > 13963c90 _pool->pl_busy_lists is 13903780 > _pool->pl_busy_lists->bl_buffers is 13a76610 > [22/Oct/2009:09:41:27 -0500] agmt="cn="Replication to > winters.hmgc.mcw.edu"" (winters:389) - session start: > anchorcsn=4ae0612d000300020000 > [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - changelog program - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): CSN > 4ae0612d000300020000 found, position set for replay > [22/Oct/2009:09:41:27 -0500] agmt="cn="Replication to > winters.hmgc.mcw.edu"" (winters:389) - load=1 rec=1 > csn=4ae06697000000020000 > [22/Oct/2009:09:41:27 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > replay_update: Sending modify operation > (dn="uid=jgretzon,ou=spine,dc=hmgc,dc=mcw,dc=edu" > csn=4ae06697000000020000) > [22/Oct/2009:09:41:28 -0500] - repl5_inc_result_threadmain starting > [22/Oct/2009:09:41:28 -0500] - repl5_inc_result_threadmain: read result > for message_id 9 > [22/Oct/2009:09:41:28 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > replay_update: Consumer successfully sent operation with csn > 4ae06697000000020000 > [22/Oct/2009:09:41:28 -0500] agmt="cn="Replication to > winters.hmgc.mcw.edu"" (winters:389) - load=1 rec=2 > csn=4ae0669e000000020000 > [22/Oct/2009:09:41:28 -0500] - repl5_inc_result_threadmain: result 3, > 53, 1, 9, (null) > [22/Oct/2009:09:41:28 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > replay_update: Sending modify operation > (dn="uid=jgretzon,ou=spine,dc=hmgc,dc=mcw,dc=edu" > csn=4ae0669e000000020000) > [22/Oct/2009:09:41:28 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Consumer > failed to replay change (uniqueid (null), CSN (null)): DSA is unwilling > to perform. Will retry later. > [22/Oct/2009:09:41:28 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > replay_update: Consumer successfully sent operation with csn > 4ae0669e000000020000 > [22/Oct/2009:09:41:28 -0500] - repl5_inc_result_threadmain: got op > result 202 should finish 1 > [22/Oct/2009:09:41:28 -0500] agmt="cn="Replication to > winters.hmgc.mcw.edu"" (winters:389) - clcache_load_buffer: rc=-30989 > [22/Oct/2009:09:41:28 -0500] - repl5_inc_result_threadmain: read result > for message_id 10 > [22/Oct/2009:09:41:28 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): No more > updates to send (cl5GetNextOperationToReplay) > [22/Oct/2009:09:41:28 -0500] - repl5_inc_result_threadmain: result 3, > 53, 1, 10, (null) > [22/Oct/2009:09:41:28 -0500] - repl5_inc_waitfor_async_results: 10 10 > [22/Oct/2009:09:41:28 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Consumer > failed to replay change (uniqueid 4922d291-be7a11de-adce9eef-94681f9f, > CSN 4ae06697000000020000): DSA is unwilling to perform. Will retry > later. > [22/Oct/2009:09:41:28 -0500] - repl5_inc_result_threadmain: got op > result 202 should finish 1 > [22/Oct/2009:09:41:28 -0500] - repl5_inc_result_threadmain: read result > for message_id 10 > [22/Oct/2009:09:41:28 -0500] - repl5_inc_result_threadmain: read result > for message_id 10 > [22/Oct/2009:09:41:29 -0500] - repl5_inc_result_threadmain: read result > for message_id 10 > [22/Oct/2009:09:41:29 -0500] - repl5_inc_result_threadmain: read result > for message_id 10 > [22/Oct/2009:09:41:29 -0500] - repl5_inc_result_threadmain: read result > for message_id 10 > [22/Oct/2009:09:41:29 -0500] - repl5_inc_result_threadmain: read result > for message_id 10 > [22/Oct/2009:09:41:29 -0500] - repl5_inc_result_threadmain: read result > for message_id 10 > [22/Oct/2009:09:41:29 -0500] - repl5_inc_result_threadmain: read result > for message_id 10 > [22/Oct/2009:09:41:29 -0500] - repl5_inc_result_threadmain: read result > for message_id 10 > [22/Oct/2009:09:41:29 -0500] - repl5_inc_result_threadmain exiting > [22/Oct/2009:09:41:29 -0500] agmt="cn="Replication to > winters.hmgc.mcw.edu"" (winters:389) - session end: state=5 load=1 > sent=2 skipped=0 > [22/Oct/2009:09:41:30 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > Successfully released consumer > [22/Oct/2009:09:41:30 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Beginning > linger on the connection > [22/Oct/2009:09:41:30 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): State: > sending_updates -> wait_for_changes > [22/Oct/2009:09:42:30 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): Linger > timeout has expired on the connection > [22/Oct/2009:09:42:30 -0500] NSMMReplicationPlugin - > agmt="cn="Replication to winters.hmgc.mcw.edu"" (winters:389): > Disconnected from the consumer > > > [22/Oct/2009:09:46:24 -0500] - slapd shutting down - signaling operation > threads > [22/Oct/2009:09:46:24 -0500] - slapd shutting down - waiting for 29 > threads to terminate > [22/Oct/2009:09:46:24 -0500] - slapd shutting down - closing down > internal subsystems and plugins > [22/Oct/2009:09:46:26 -0500] - Waiting for 4 database threads to stop > [22/Oct/2009:09:46:27 -0500] - All database threads now stopped > [22/Oct/2009:09:46:27 -0500] - slapd stopped. > > > > > > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From across at itasoftware.com Thu Oct 22 15:23:07 2009 From: across at itasoftware.com (Anne Cross) Date: Thu, 22 Oct 2009 11:23:07 -0400 Subject: [389-users] AD2008 on 64 bit windows, 389 Directory Server passwords... In-Reply-To: <4AE06955.5030405@redhat.com> References: <4ADF7A63.7090802@itasoftware.com> <4AE06955.5030405@redhat.com> Message-ID: <4AE078DB.6070808@itasoftware.com> Rich Megginson wrote: > Anne Cross wrote: >> I'm trying to sync passwords from 389 to Active Directory. >> >> If we import users from AD, then try to change their passwords, the >> replication locks up. > Can you be more specific? Have you tried the replication log level > (which also logs winsync data) - > http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting I turned on replication logging through the GUI, which set it to 8192, much as the ldapmodify would have. What we see on the AD side is that the replication manager says, effectively, "Change the password," and then it *appears* that the replication manager account attempts to change users to the become to the user whose password is being changed; then, the software attempts to change the password, which fails. the bad password attempt counter increments, and the replication manager account appears to log out. On the Directory Server side, we see everything connect, the user is resolved on both sides, and then after about 15 minutes, the connection disconnects due to idleness. This is the log of the user add using a cleartext password on the ldap side: [22/Oct/2009:11:06:03 -0400] NSMMReplicationPlugin - agmt="cn=ita4windc2" (ita4windc2:636): windows_replay_update: Looking at add operation local dn="uid=juniper,ou=Employees,ou=Users,ou=People,dc=itasoftware,dc=com" (ours,user,not group) [22/Oct/2009:11:06:03 -0400] NSMMReplicationPlugin - agmt="cn=ita4windc2" (ita4windc2:636): map_entry_dn_outbound: looking for AD entry for DS dn="uid=juniper,ou=Employees,ou=Users,ou=People,dc=itasoftware,dc=com" guid="(null)" [22/Oct/2009:11:06:03 -0400] NSMMReplicationPlugin - agmt="cn=ita4windc2" (ita4windc2:636): map_entry_dn_outbound: looking for AD entry for DS dn="uid=juniper,ou=Employees,ou=Users,ou=People,dc=itasoftware,dc=com" username="juniper" [22/Oct/2009:11:06:03 -0400] NSMMReplicationPlugin - agmt="cn=ita4windc2" (ita4windc2:636): map_entry_dn_outbound: entry not found - rc 0 [22/Oct/2009:11:06:03 -0400] NSMMReplicationPlugin - agmt="cn=ita4windc2" (ita4windc2:636): windows_replay_update: Processing add operation local dn="uid=juniper,ou=Employees,ou=Users,ou=People,dc=itasoftware,dc=com" remote dn="cn=Juniper Cross,ou=Employees,ou=Users,ou=People,dc=corp,dc=itasoftware,dc=com" [22/Oct/2009:11:06:03 -0400] NSMMReplicationPlugin - agmt="cn=ita4windc2" (ita4windc2:636): process_replay_add: dn="cn=Juniper Cross,ou=Employees,ou=Users,ou=People,dc=corp,dc=itasoftware,dc=com" (not present,add allowed) [22/Oct/2009:11:06:03 -0400] NSMMReplicationPlugin - agmt="cn=ita4windc2" (ita4windc2:636): Received result code 0 () for add operation That's it, until ten minutes later when I tried to change the password: [22/Oct/2009:11:16:02 -0400] agmt="cn=ita4windc2" (ita4windc2:636) - load next: anchorcsn=4ae073560000104d0000 [22/Oct/2009:11:16:02 -0400] agmt="cn=ita4windc2" (ita4windc2:636) - load=3 rec=7 csn=4ae075280000104d0000 [22/Oct/2009:11:16:02 -0400] NSMMReplicationPlugin - agmt="cn=ita4windc2" (ita4windc2:636): windows_replay_update: Looking at modify operation local dn="uid=juniper,ou=employees,ou=users,ou=people,dc=itasoftware,dc=com" (ours,user,not group) [22/Oct/2009:11:16:02 -0400] NSMMReplicationPlugin - agmt="cn=ita4windc2" (ita4windc2:636): map_entry_dn_outbound: looking for AD entry for DS dn="uid=juniper,ou=Employees,ou=Users,ou=People,dc=itasoftware,dc=com" guid="(null)" [22/Oct/2009:11:16:02 -0400] NSMMReplicationPlugin - agmt="cn=ita4windc2" (ita4windc2:636): map_entry_dn_outbound: looking for AD entry for DS dn="uid=juniper,ou=Employees,ou=Users,ou=People,dc=itasoftware,dc=com" username="juniper" [22/Oct/2009:11:16:02 -0400] NSMMReplicationPlugin - agmt="cn=ita4windc2" (ita4windc2:636): map_entry_dn_outbound: found AD entry dn="CN=Juniper Cross,OU=Employees,OU=Users,OU=People,DC=corp,DC=itasoftware,DC=com" [22/Oct/2009:11:16:02 -0400] NSMMReplicationPlugin - agmt="cn=ita4windc2" (ita4windc2:636): windows_replay_update: Processing modify operation local dn="uid=juniper,ou=employees,ou=users,ou=people,dc=itasoftware,dc=com" remote dn="CN=Juniper Cross,OU=Employees,OU=Users,OU=People,DC=corp,DC=itasoftware,DC=com" Nada. The badPwdCounter just increments, and the password remains unset. >> If we create the users on 389, and sync them back to AD, the password >> field passed back is blank in Windows. > When you create the users on 389, are you using the clear text > password in the userPassword field? We were not. I created a test user with a cleartext password this morning, and the result has been functionally identical - the badPwdCounter increments, and the user password remains blank on the AD side of things. >> >> Passsync isn't going to work because we're running 64bit Windows, so >> we can't sync the passwords *from* AD. I got this working earlier, >> but that was with FDS in a test instance several months ago, and I >> didn't write down what I did. (And I am kicking myself over that.) >> We can live without people changing their passwords on AD as long as >> we *can* sync passwords down from 389. > We are working on 64-bit Windows support. Oh, hurrah! Are you also going to change it so that passsync doesn't store the password in cleartext in the registry? Our Windows admin just about took my head off when he found that. :/ I'll see if I can get him to let me use the administrator account on Windows to test with, though. -- juniper -- ,___, {o,o} Anne "Juniper" Cross (___) Senior Linux Systems Engineer and Extropic Crusader -"-"-- Information Technology, ITA Software /^^^ From brodie at mcw.edu Thu Oct 22 15:33:11 2009 From: brodie at mcw.edu (Kent C. Brodie) Date: Thu, 22 Oct 2009 10:33:11 -0500 Subject: [389-users] Consumer failed to replay change In-Reply-To: <4AE074B0.7050007@redhat.com> References: <8F78639AC56F4143B267FE5F5A1B92C801D89BC6@guyton.phys.mcw.edu> <4AE069A5.8050000@redhat.com> <8F78639AC56F4143B267FE5F5A1B92C801D89BC9@guyton.phys.mcw.edu> <4AE074B0.7050007@redhat.com> Message-ID: <4AE07B37.5060202@mcw.edu> On 10/22/2009 10:05 AM, Rich Megginson wrote: > Brodie, Kent wrote: >> Rich: Thanks for the debugging help! I'm still stuck, as I am not >> sure exactly what I am looking at in terms of messages. I can see that >> the same uniqueid 4922d291-be7a11de-adce9eef-94681f9f keeps failing, but >> the message surrounding that error are anything but clear to me. > Try using the /usr/bin/cl-dump tool to dump the changelog (man > cl-dump) - look for uniqueid 4922d291-be7a11de-adce9eef-94681f9f and > dn="uid=jgretzon,ou=spine,dc=hmgc,dc=mcw,dc=edu" and > csn=4ae06697000000020000 > > Rich-- ok, we're getting closer. cl-dump told me lots, and when I looked for all three items together (uniqueid, uid, and csn), I found this entry: changetype: modify replgen: 4a7758f2000000010000 csn: 4ae06697000000020000 nsuniqueid: 4922d291-be7a11de-adce9eef-94681f9f dn: uid=jgretzon,ou=spine,dc=hmgc,dc=mcw,dc=edu change:: replace: retryCountResetTime retryCountResetTime: 20091022141509Z - replace: passwordRetryCount passwordRetryCount: 1 So, there's some sort of passwordretry entry that's bogus (not sure why)-- I guess now my question is, now that I've found what the error entry is that's giving replication fits, what do I do about it? I really appreciate the help--- this is good stuff for the email list archives for others to see when they have something like this. From brodie at mcw.edu Thu Oct 22 15:48:33 2009 From: brodie at mcw.edu (Brodie, Kent) Date: Thu, 22 Oct 2009 10:48:33 -0500 Subject: [389-users] Consumer failed to replay change In-Reply-To: <4AE07B37.5060202@mcw.edu> References: <8F78639AC56F4143B267FE5F5A1B92C801D89BC6@guyton.phys.mcw.edu> <4AE069A5.8050000@redhat.com> <8F78639AC56F4143B267FE5F5A1B92C801D89BC9@guyton.phys.mcw.edu><4AE074B0.7050007@redhat.com> <4AE07B37.5060202@mcw.edu> Message-ID: <8F78639AC56F4143B267FE5F5A1B92C801D89BCB@guyton.phys.mcw.edu> OK. Further research-- it appears I have an issue with "passwordretrycount" not replicating-- which apparently (did some searches..) is a problem others have had, when the directory services is set up in a replicating fashion (multi-master in my case). Has to do with global password policy settings, and what is allowed to replicate-- or not. I found the offending entry (passwordretrycount existed for the user on one node, not the other) and deleted it. My question now is: What's the correct solution to this? Forum postings I've found thus far are unclear. Any ideas appreciated! --Kent PS: Thanks for the tons of help, I learned a lot today on debugging this stuff for future issues... From rmeggins at redhat.com Thu Oct 22 15:58:57 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 22 Oct 2009 09:58:57 -0600 Subject: [389-users] Consumer failed to replay change In-Reply-To: <8F78639AC56F4143B267FE5F5A1B92C801D89BCB@guyton.phys.mcw.edu> References: <8F78639AC56F4143B267FE5F5A1B92C801D89BC6@guyton.phys.mcw.edu> <4AE069A5.8050000@redhat.com> <8F78639AC56F4143B267FE5F5A1B92C801D89BC9@guyton.phys.mcw.edu><4AE074B0.7050007@redhat.com> <4AE07B37.5060202@mcw.edu> <8F78639AC56F4143B267FE5F5A1B92C801D89BCB@guyton.phys.mcw.edu> Message-ID: <4AE08141.2040804@redhat.com> Brodie, Kent wrote: > OK. Further research-- it appears I have an issue with > "passwordretrycount" not replicating-- which apparently (did some > searches..) is a problem others have had, when the directory services is > set up in a replicating fashion (multi-master in my case). Has to do > with global password policy settings, and what is allowed to replicate-- > or not. > > I found the offending entry (passwordretrycount existed for the user on > one node, not the other) and deleted it. > > My question now is: What's the correct solution to this? Forum > postings I've found thus far are unclear. > > Any ideas appreciated! --Kent > > PS: Thanks for the tons of help, I learned a lot today on debugging > this stuff for future issues... > If you have password policy on, the directory server will make modifications to users' entries when they use password authentication. You may or may not want these to be replicated. For example, if you have password retry counting with lockout enabled - if this policy is local only, a hacker could attempt to hack an account N times on master 1, N times on master 2, etc. So instead of the password retry count being N, it's really M x N. If you care about this, you can enable these password policy attributes to be replicated and accepted on the consumer, by turning on the passwordIsGlobalPolicy in cn=config on each consumer. If you do not want these attributes replicated at all, modify your replication agreement to exclude the following attributes from being replicated: retryCountResetTime passwordRetryCount accountUnlockTime > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From brodie at mcw.edu Thu Oct 22 15:57:47 2009 From: brodie at mcw.edu (Brodie, Kent) Date: Thu, 22 Oct 2009 10:57:47 -0500 Subject: [389-users] Consumer failed to replay change In-Reply-To: <4AE07B37.5060202@mcw.edu> References: <8F78639AC56F4143B267FE5F5A1B92C801D89BC6@guyton.phys.mcw.edu> <4AE069A5.8050000@redhat.com> <8F78639AC56F4143B267FE5F5A1B92C801D89BC9@guyton.phys.mcw.edu><4AE074B0.7050007@redhat.com> <4AE07B37.5060202@mcw.edu> Message-ID: <8F78639AC56F4143B267FE5F5A1B92C801D89BCC@guyton.phys.mcw.edu> Um, rats. OK, I had deleted the offending ldap attribute, but the replication engine is still trying to process/perform the failed replication thing that I need to remove. How do I 'kill' a particular replication entry? From rmeggins at redhat.com Thu Oct 22 16:04:16 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 22 Oct 2009 10:04:16 -0600 Subject: [389-users] Consumer failed to replay change In-Reply-To: <8F78639AC56F4143B267FE5F5A1B92C801D89BCC@guyton.phys.mcw.edu> References: <8F78639AC56F4143B267FE5F5A1B92C801D89BC6@guyton.phys.mcw.edu> <4AE069A5.8050000@redhat.com> <8F78639AC56F4143B267FE5F5A1B92C801D89BC9@guyton.phys.mcw.edu><4AE074B0.7050007@redhat.com> <4AE07B37.5060202@mcw.edu> <8F78639AC56F4143B267FE5F5A1B92C801D89BCC@guyton.phys.mcw.edu> Message-ID: <4AE08280.1030508@redhat.com> Brodie, Kent wrote: > Um, rats. OK, I had deleted the offending ldap attribute, but the > replication engine is still trying to process/perform the failed > replication thing that I need to remove. How do I 'kill' a particular > replication entry? > Try what I sent in my other email. > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From brodie at mcw.edu Thu Oct 22 16:21:20 2009 From: brodie at mcw.edu (Brodie, Kent) Date: Thu, 22 Oct 2009 11:21:20 -0500 Subject: [389-users] Consumer failed to replay change In-Reply-To: <4AE08280.1030508@redhat.com> References: <8F78639AC56F4143B267FE5F5A1B92C801D89BC6@guyton.phys.mcw.edu> <4AE069A5.8050000@redhat.com> <8F78639AC56F4143B267FE5F5A1B92C801D89BC9@guyton.phys.mcw.edu><4AE074B0.7050007@redhat.com> <4AE07B37.5060202@mcw.edu><8F78639AC56F4143B267FE5F5A1B92C801D89BCC@guyton.phys.mcw.edu> <4AE08280.1030508@redhat.com> Message-ID: <8F78639AC56F4143B267FE5F5A1B92C801D89BCE@guyton.phys.mcw.edu> Score! Thanks. All is happy. Cool learning experience for me today, I really appreciate your assist. > Try what I sent in my other email. From brodie at mcw.edu Thu Oct 22 20:08:22 2009 From: brodie at mcw.edu (Brodie, Kent) Date: Thu, 22 Oct 2009 15:08:22 -0500 Subject: [389-users] *Big* thank you for developers Message-ID: <8F78639AC56F4143B267FE5F5A1B92C801D89BD3@guyton.phys.mcw.edu> Previous setup: Fedora directory server 1.2.0. ssl, replication all running. Current setup: 389 dir server, $latest. I cannot state enough how pleased I am with the upgrade. The instructions on the web page were flawless, the update was frankly, probably the simplest thing I've done this week on a software package system that's the most complex and critical of what I currently manage. I half expected SOME hiccups, errors, or things out of sync, or broken replication, or SOMETHING... and so on. Instead-- it just went flawlessly. Awesome. Absolutely awesome. Keep up the good work. --Kent C. Brodie, Medical College of Wisconsin -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Oct 22 20:29:45 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 22 Oct 2009 14:29:45 -0600 Subject: [389-users] *Big* thank you for developers In-Reply-To: <8F78639AC56F4143B267FE5F5A1B92C801D89BD3@guyton.phys.mcw.edu> References: <8F78639AC56F4143B267FE5F5A1B92C801D89BD3@guyton.phys.mcw.edu> Message-ID: <4AE0C0B9.1090808@redhat.com> Brodie, Kent wrote: > > Previous setup: Fedora directory server 1.2.0. ssl, replication all > running. > > Current setup: 389 dir server, $latest. > > I cannot state enough how pleased I am with the upgrade. The > instructions on the web page were flawless, the update was frankly, > probably the simplest thing I?ve done this week on a software package > system that?s the most complex and critical of what I currently > manage. I half expected SOME hiccups, errors, or things out of sync, > or broken replication, or SOMETHING? and so on. Instead-- it just went > flawlessly. > > Awesome. Absolutely awesome. > > Keep up the good work. > Thanks! By $latest did you mean 1.2.2 or 1.2.3? > > --Kent C. Brodie, Medical College of Wisconsin > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From brodie at mcw.edu Thu Oct 22 20:30:36 2009 From: brodie at mcw.edu (Brodie, Kent) Date: Thu, 22 Oct 2009 15:30:36 -0500 Subject: [389-users] *Big* thank you for developers In-Reply-To: <4AE0C0B9.1090808@redhat.com> References: <8F78639AC56F4143B267FE5F5A1B92C801D89BD3@guyton.phys.mcw.edu> <4AE0C0B9.1090808@redhat.com> Message-ID: <8F78639AC56F4143B267FE5F5A1B92C801D89BD6@guyton.phys.mcw.edu> The yum update defaults to the latest, 1.2.3. -----Original Message----- From: fedora-directory-users-bounces at redhat.com [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Rich Megginson Sent: Thursday, October 22, 2009 3:30 PM To: General discussion list for the 389 Directory server project. Subject: Re: [389-users] *Big* thank you for developers Brodie, Kent wrote: > > Previous setup: Fedora directory server 1.2.0. ssl, replication all > running. > > Current setup: 389 dir server, $latest. > > I cannot state enough how pleased I am with the upgrade. The > instructions on the web page were flawless, the update was frankly, > probably the simplest thing I've done this week on a software package > system that's the most complex and critical of what I currently > manage. I half expected SOME hiccups, errors, or things out of sync, > or broken replication, or SOMETHING... and so on. Instead-- it just went > flawlessly. > > Awesome. Absolutely awesome. > > Keep up the good work. > Thanks! By $latest did you mean 1.2.2 or 1.2.3? > > --Kent C. Brodie, Medical College of Wisconsin > > ---------------------------------------------------------------------- > -- > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > From rmeggins at redhat.com Thu Oct 22 20:40:57 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 22 Oct 2009 14:40:57 -0600 Subject: [389-users] *Big* thank you for developers In-Reply-To: <8F78639AC56F4143B267FE5F5A1B92C801D89BD6@guyton.phys.mcw.edu> References: <8F78639AC56F4143B267FE5F5A1B92C801D89BD3@guyton.phys.mcw.edu> <4AE0C0B9.1090808@redhat.com> <8F78639AC56F4143B267FE5F5A1B92C801D89BD6@guyton.phys.mcw.edu> Message-ID: <4AE0C359.2000500@redhat.com> Brodie, Kent wrote: > The yum update defaults to the latest, 1.2.3. > hmm - it's not supposed to - 1.2.3 is only in the testing repository, which is not enabled by default - what platform are you running? > > > -----Original Message----- > From: fedora-directory-users-bounces at redhat.com > [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Rich > Megginson > Sent: Thursday, October 22, 2009 3:30 PM > To: General discussion list for the 389 Directory server project. > Subject: Re: [389-users] *Big* thank you for developers > > Brodie, Kent wrote: > >> Previous setup: Fedora directory server 1.2.0. ssl, replication all >> running. >> >> Current setup: 389 dir server, $latest. >> >> I cannot state enough how pleased I am with the upgrade. The >> instructions on the web page were flawless, the update was frankly, >> probably the simplest thing I've done this week on a software package >> system that's the most complex and critical of what I currently >> manage. I half expected SOME hiccups, errors, or things out of sync, >> or broken replication, or SOMETHING... and so on. Instead-- it just >> > went > >> flawlessly. >> >> Awesome. Absolutely awesome. >> >> Keep up the good work. >> >> > Thanks! > > By $latest did you mean 1.2.2 or 1.2.3? > >> --Kent C. Brodie, Medical College of Wisconsin >> >> ---------------------------------------------------------------------- >> -- >> >> -- >> 389 users mailing list >> 389-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> >> > > > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From brodie at mcw.edu Thu Oct 22 20:43:27 2009 From: brodie at mcw.edu (Brodie, Kent) Date: Thu, 22 Oct 2009 15:43:27 -0500 Subject: [389-users] *Big* thank you for developers In-Reply-To: <4AE0C359.2000500@redhat.com> References: <8F78639AC56F4143B267FE5F5A1B92C801D89BD3@guyton.phys.mcw.edu> <4AE0C0B9.1090808@redhat.com><8F78639AC56F4143B267FE5F5A1B92C801D89BD6@guyton.phys.mcw.edu> <4AE0C359.2000500@redhat.com> Message-ID: <8F78639AC56F4143B267FE5F5A1B92C801D89BD7@guyton.phys.mcw.edu> Whoops. I did the wrong line with the enablerepo part. :-) (No matter, this was on our testing platform only). -----Original Message----- From: fedora-directory-users-bounces at redhat.com [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Rich Megginson Sent: Thursday, October 22, 2009 3:41 PM To: General discussion list for the 389 Directory server project. Subject: Re: [389-users] *Big* thank you for developers Brodie, Kent wrote: > The yum update defaults to the latest, 1.2.3. > hmm - it's not supposed to - 1.2.3 is only in the testing repository, which is not enabled by default - what platform are you running? > From rmeggins at redhat.com Thu Oct 22 20:48:07 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 22 Oct 2009 14:48:07 -0600 Subject: [389-users] *Big* thank you for developers In-Reply-To: <8F78639AC56F4143B267FE5F5A1B92C801D89BD7@guyton.phys.mcw.edu> References: <8F78639AC56F4143B267FE5F5A1B92C801D89BD3@guyton.phys.mcw.edu> <4AE0C0B9.1090808@redhat.com><8F78639AC56F4143B267FE5F5A1B92C801D89BD6@guyton.phys.mcw.edu> <4AE0C359.2000500@redhat.com> <8F78639AC56F4143B267FE5F5A1B92C801D89BD7@guyton.phys.mcw.edu> Message-ID: <4AE0C507.3080705@redhat.com> Brodie, Kent wrote: > Whoops. I did the wrong line with the enablerepo part. :-) > > (No matter, this was on our testing platform only). > That's fine. In fact that's very good news. Thanks for doing this. What platform are you running? > -----Original Message----- > From: fedora-directory-users-bounces at redhat.com > [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Rich > Megginson > Sent: Thursday, October 22, 2009 3:41 PM > To: General discussion list for the 389 Directory server project. > Subject: Re: [389-users] *Big* thank you for developers > > Brodie, Kent wrote: > >> The yum update defaults to the latest, 1.2.3. >> >> > hmm - it's not supposed to - 1.2.3 is only in the testing repository, > which is not enabled by default - what platform are you running? > > > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From brodie at mcw.edu Thu Oct 22 21:05:54 2009 From: brodie at mcw.edu (Brodie, Kent) Date: Thu, 22 Oct 2009 16:05:54 -0500 Subject: [389-users] *Big* thank you for developers In-Reply-To: <4AE0C507.3080705@redhat.com> References: <8F78639AC56F4143B267FE5F5A1B92C801D89BD3@guyton.phys.mcw.edu> <4AE0C0B9.1090808@redhat.com><8F78639AC56F4143B267FE5F5A1B92C801D89BD6@guyton.phys.mcw.edu> <4AE0C359.2000500@redhat.com><8F78639AC56F4143B267FE5F5A1B92C801D89BD7@guyton.phys.mcw.edu> <4AE0C507.3080705@redhat.com> Message-ID: <8F78639AC56F4143B267FE5F5A1B92C801D89BD9@guyton.phys.mcw.edu> >That's fine. In fact that's very good news. Thanks for doing this. >What platform are you running? RHEL 5.4 From rmeggins at redhat.com Thu Oct 22 21:11:09 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 22 Oct 2009 15:11:09 -0600 Subject: [389-users] *Big* thank you for developers In-Reply-To: <8F78639AC56F4143B267FE5F5A1B92C801D89BD9@guyton.phys.mcw.edu> References: <8F78639AC56F4143B267FE5F5A1B92C801D89BD3@guyton.phys.mcw.edu> <4AE0C0B9.1090808@redhat.com><8F78639AC56F4143B267FE5F5A1B92C801D89BD6@guyton.phys.mcw.edu> <4AE0C359.2000500@redhat.com><8F78639AC56F4143B267FE5F5A1B92C801D89BD7@guyton.phys.mcw.edu> <4AE0C507.3080705@redhat.com> <8F78639AC56F4143B267FE5F5A1B92C801D89BD9@guyton.phys.mcw.edu> Message-ID: <4AE0CA6D.6000002@redhat.com> Brodie, Kent wrote: >> That's fine. In fact that's very good news. Thanks for doing this. >> What platform are you running? >> > > RHEL 5.4 > Great. Thanks! > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From nevilchandran at gmail.com Fri Oct 23 03:52:36 2009 From: nevilchandran at gmail.com (nevil chandran) Date: Fri, 23 Oct 2009 09:22:36 +0530 Subject: [389-users] Need ISO image of DIrectory server 8.0 Message-ID: <7495f7c00910222052y57538090k741601c994b77270@mail.gmail.com> Hi, I cant find redhat directory server 8.0 iso download in rhn.redhat.com. Anybody can help me.? pls send me link of redhat network or any other. Regards; Nevil -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitja.mihelic at arnes.si Fri Oct 23 09:13:22 2009 From: mitja.mihelic at arnes.si (=?UTF-8?B?TWl0amEgTWloZWxpxI0=?=) Date: Fri, 23 Oct 2009 11:13:22 +0200 Subject: [389-users] Replication over SSL Message-ID: <4AE173B2.4060001@arnes.si> Hi! I am trying to get replication to work over SSL, but I seem to be missing something... To make a long story short: single-master and multi-master replication without SSL works without a problem. I have created two Directory servers via the Management Console, one called master (supplier) and one called replica (consumer). I have issued a certificate request via the management console for the supplier and consumer. Both were signed by a test CA and imported into the corresponding server's certificate store. Now, what exactly must I do, to correctly map the certificates and make them talk to each other ? I have read the documentation, but I just don't understand how to make it work. The following dn is used for replication: dn: cn=replication manager,cn=config objectClass: inetorgperson objectClass: person objectClass: top objectClass: organizationalPerson cn: replication manager sn: RM userPassword: replicate passwordExpirationTime: 20380119031407Z Greetings, Mitja Read the following lines if you wish to know how I have it set up what I have done to set up non-SSL replication: The Directory server instances are using their own ports (supplier: 30389/30636 and consumer: 40389/40636 respectively). I have inserted a replication user into the dse.ldif files in both the supplier and the consumer as specified in the documentation. The supplier has been populated with test entries, enabled the changelog and replication of the relevant database. The consumer has been set up accordingly. I have created an appropriate replication agreement and initialized the consumer. All entries replicated as expected and the replica was updating successfully. From morenisco at noc-root.net Fri Oct 23 09:52:15 2009 From: morenisco at noc-root.net (Morenisco) Date: Fri, 23 Oct 2009 06:52:15 -0300 Subject: [389-users] What script do I use to configure multimaster replication? Message-ID: <4AE17CCF.3000507@noc-root.net> Hi, I'm going to configure multimaster replication, and I'm using the following URL: http://directory.fedoraproject.org/wiki/Howto:MultiMasterReplication There are two dead links to the mmr.pl script (old-mmr.pl and newer mmr.p l) , and the "modified mmr.pl" is the only one script available. Can I use that one, considering I'm implementing the latest project-389 version, or there is another preferred method? Thanks. -- Morenisco. Centro de Difusi?n del Software Libre. http://www.cdsl.cl http://www.folasol.org http://trabajosfloss.cdsl.cl Blog: http://morenisco.noc-root.net From muzzol at gmail.com Fri Oct 23 11:07:33 2009 From: muzzol at gmail.com (muzzol) Date: Fri, 23 Oct 2009 13:07:33 +0200 Subject: [389-users] What script do I use to configure multimaster replication? In-Reply-To: <4AE17CCF.3000507@noc-root.net> References: <4AE17CCF.3000507@noc-root.net> Message-ID: <4a3f02760910230407k9e51fa6xb4a60fd2e3a1fba7@mail.gmail.com> 2009/10/23 Morenisco : > Hi, > > I'm going to configure multimaster replication, and I'm using the following > URL: > > http://directory.fedoraproject.org/wiki/Howto:MultiMasterReplication > i dont recommend you those scripts. i learned a lot following these steps: http://directory.fedoraproject.org/wiki/Howto:WalkthroughMultimasterSSL and i understand better the whole replication proces. also you can't use those scripts if you dont want autogenerated ssl certs. regards, muzzol -- ======================== ^ ^ O O (_ _) muzzol(a)muzzol.com ======================== jabber id: muzzol(a)jabber.dk ======================== No atribueixis qualitats humanes als ordinadors. No els hi agrada. ======================== "El gobierno espa?ol s?lo habla con terroristas, homosexuales y catalanes, a ver cuando se decide a hablar con gente normal" Jim?nez Losantos ======================== bomb terrorism bush aznar teletubbies From jfenal at gmail.com Fri Oct 23 16:09:01 2009 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Fri, 23 Oct 2009 18:09:01 +0200 Subject: [389-users] Need ISO image of DIrectory server 8.0 In-Reply-To: <7495f7c00910222052y57538090k741601c994b77270@mail.gmail.com> References: <7495f7c00910222052y57538090k741601c994b77270@mail.gmail.com> Message-ID: <40a14bc10910230909n34cc17b4q621723849706a2fc@mail.gmail.com> 2009/10/23 nevil chandran : > > > Hi, > > ?I cant find redhat directory server 8.0 iso download in rhn.redhat.com. > > Anybody can help me.? > > pls send me link of redhat network or any other. https://rhn.redhat.com/rhn/software/downloads/SupportedISOs.do Search under your RHEL version/arch channel for it. You will need an active RHDS subscription to get access to it. Regards, J. -- J?r?me Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ From morenisco at noc-root.net Sat Oct 24 11:32:20 2009 From: morenisco at noc-root.net (Morenisco) Date: Sat, 24 Oct 2009 08:32:20 -0300 Subject: [389-users] Multimaster replication is not working In-Reply-To: <4a3f02760910230407k9e51fa6xb4a60fd2e3a1fba7@mail.gmail.com> References: <4AE17CCF.3000507@noc-root.net> <4a3f02760910230407k9e51fa6xb4a60fd2e3a1fba7@mail.gmail.com> Message-ID: <4AE2E5C4.4080307@noc-root.net> Hi, I configured multimaster replication on two nodes, following this documentation (thanks Muzzol): http://directory.fedoraproject.org/wiki/Howto:WalkthroughMultimasterSSL I created an user entry on node1 and it is not being replicated on node2, and I don't see any error in the access or error log file. Seeing the documentation, I'm not sure if I must to follow the "Importing Schema" section, then I didn't. I think I would follow that item in case I have added attributes or objectclasses to the original schema, but I didn't do that, and this is a fresh installation. When searching users in the console, on node2, I receive an ldap error code 32 (entry not found), and If I do an ldapsearch to the user base, it gives me the user container, and I don't see the user that I created on node1. The console gives me the following error: "Cannot continue with the selected operation because we cannot connect to the directory server. Do you want to reconnect or change directory server?" But I see the server is up and running, authenticating and answering the ldapsearch command. During the MMR configuration, I selected "initialize multimaster replication" on both nodes, mabe that was the error and I had to do it later. Any idea about what can I review and how can I troubleshooting this issue please? Thanks. -- Morenisco. Centro de Difusi?n del Software Libre. http://www.cdsl.cl http://www.folasol.org http://trabajosfloss.cdsl.cl Blog: http://morenisco.noc-root.net From morenisco at noc-root.net Sat Oct 24 11:43:59 2009 From: morenisco at noc-root.net (Morenisco) Date: Sat, 24 Oct 2009 08:43:59 -0300 Subject: [389-users] Multimaster replication - what is the database that I need to replicate? Message-ID: <4AE2E87F.4080402@noc-root.net> Hi, I'm following the guide in this URL: http://directory.fedoraproject.org/wiki/Howto:WalkthroughMultimasterSSL Seeing the item 3, this says the following: "Back on the left, expand the Replication Folder until you see your databases. Click on the database you wish to replicate. On the right you will see a menu in which you need to use the following options." I see 2 options in the console: NetscapeRoot and userRoot. I configured MMR for NetscapeRoot, due I thought it is the root of the directory, then I need to setup that database, but as I'm not replicating an entry, I'm thinking I should need to select the second one for users. If that is the case, I can configure MMR for the userRoot database, but what do I do with the another one? do I delete it, or that is necessary to replicate the changes on the schema and everything is in the root of the DIT? Thanks. -- Morenisco. Centro de Difusi?n del Software Libre. http://www.cdsl.cl http://www.folasol.org http://trabajosfloss.cdsl.cl Blog: http://morenisco.noc-root.net From morenisco at noc-root.net Sat Oct 24 13:46:18 2009 From: morenisco at noc-root.net (Morenisco) Date: Sat, 24 Oct 2009 10:46:18 -0300 Subject: [389-users] Multimaster replication - what is the database that I need to replicate? In-Reply-To: <4AE2E87F.4080402@noc-root.net> References: <4AE2E87F.4080402@noc-root.net> Message-ID: <4AE3052A.7060001@noc-root.net> Morenisco wrote: [...] > If that is the case, I can configure MMR for the userRoot database, > but what do I do with the another one? do I delete it, or that is > necessary to replicate the changes on the schema and everything is in > the root of the DIT? Hi, I made it by configuring the userRoot database (the names comes from Sun One directory server, I didn't know). Regards! -- Morenisco. Centro de Difusi?n del Software Libre. http://www.cdsl.cl http://www.folasol.org http://trabajosfloss.cdsl.cl Blog: http://morenisco.noc-root.net From jsullivan at opensourcedevel.com Sun Oct 25 03:32:44 2009 From: jsullivan at opensourcedevel.com (John A. Sullivan III) Date: Sat, 24 Oct 2009 23:32:44 -0400 Subject: [389-users] dse.ldif empty! Message-ID: <1256441564.6552.214.camel@jaspav.missionsit.net.missionsit.net> We've just had a huge scare. We reboot our main LDAP server (CentOS DS 8.1 on newly upgraded CentOS 5.4) and it dirsrv failed to start. dse.ldif was completely empty. Thankfully, I had a near-line backup. I restored it and restarted and we seem to be OK. What would cause such a problem? Thanks - John -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan at opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society From muzzol at gmail.com Sun Oct 25 11:37:33 2009 From: muzzol at gmail.com (muzzol) Date: Sun, 25 Oct 2009 12:37:33 +0100 Subject: [389-users] Multimaster replication is not working In-Reply-To: <4AE2E5C4.4080307@noc-root.net> References: <4AE17CCF.3000507@noc-root.net> <4a3f02760910230407k9e51fa6xb4a60fd2e3a1fba7@mail.gmail.com> <4AE2E5C4.4080307@noc-root.net> Message-ID: <4AE4387D.20206@gmail.com> On 24/10/09 13:32, Morenisco wrote: > During the MMR configuration, I selected "initialize multimaster > replication" on both nodes, mabe that was the error and I had to do it > later. > you must only initialize replication one time FROM the node with the data you want to propagate to any other node. muzzol From okelet at gmail.com Mon Oct 26 09:33:30 2009 From: okelet at gmail.com (=?UTF-8?Q?Juan_Asensio_S=C3=A1nchez?=) Date: Mon, 26 Oct 2009 10:33:30 +0100 Subject: [389-users] repl_set_mtn_referrals: could not set referrals for replica In-Reply-To: <4ADCC852.70203@redhat.com> References: <52a9d2e30910160354y3b394a18ma6bbe46339eee202@mail.gmail.com> <4ADCC852.70203@redhat.com> Message-ID: <52a9d2e30910260233q57b11506o6ae2cd5bb8443d8f@mail.gmail.com> Hi again What's the difference between the referrals specified in the suffixes and the referrals specified in a replica? We have had ever the referrals specified in the suffix. Do you mean to set them too in the replica? Regards. (Testing 389DS 1.2.3, having problems with schema syntaxes...) 2009/10/19 Rich Megginson : > Juan Asensio S?nchez wrote: >> >> Hi >> >> We are having problems with replication. We have four master servers >> replicating one database (database 1), and two other servers in other >> building that are masters of other database (database 2). Replication >> between the databases of the others are in hub mode (server1 of >> building1 with server1 of building1, and server2 of building1 with >> server2 of building2; server3 and server4 of building1 only have >> agreements with server1 and server2 of building1). Yesterday we had to >> remove the replica of server4 of database 1. Next, we did ree-enable >> the replica and the replication agreements, but the replica was >> enabled with a different id than before. Now, we have this error on >> all servers, although replication is working fine: >> >> [16/Oct/2009:12:44:39 +0200] NSMMReplicationPlugin - >> repl_set_mtn_referrals: could not set referrals for replica >> dc=domain,dc=local: 1 >> > > I don't think this is a critical error. ?You can manually set the referrals > to use - in the console for the Replica config, at the bottom of that window > (under the Supplier DN area) you can specify the referrals to use. ?However, > you will have to manage these manually - they are not set automatically like > the regular replication referrals are. > >> (dc=domain,dc=local is the prefix that owns the database 1). I don't >> know if this error is critical, but i don't like to see errors in the >> log (call me fool if you want). I have read some posts: >> >> - http://blogs.sun.com/marcos/entry/on_cleanruv >> - http://blogs.sun.com/piotr/entry/how_to_clean_ruv_s >> >> All about Sun, but i am not sure if this will work, or if it is >> dangerous because it says that the solution is unsupported and >> irreversible. How can I get rid of this message? is it critical? >> > > You could try using that. ?I would suggest backing up all of your data and > config first. >> >> Regards and thanks in advance. >> >> -- >> 389 users mailing list >> 389-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > > > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > From rmeggins at redhat.com Mon Oct 26 14:49:18 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 26 Oct 2009 08:49:18 -0600 Subject: [389-users] Replication over SSL In-Reply-To: <4AE173B2.4060001@arnes.si> References: <4AE173B2.4060001@arnes.si> Message-ID: <4AE5B6EE.5050003@redhat.com> Mitja Miheli? wrote: > Hi! > > I am trying to get replication to work over SSL, but I seem to be > missing something... > > To make a long story short: single-master and multi-master replication > without SSL works without a problem. > > I have created two Directory servers via the Management Console, one > called master (supplier) and one called replica (consumer). > I have issued a certificate request via the management console for the > supplier and consumer. > Both were signed by a test CA and imported into the corresponding > server's certificate store. > Now, what exactly must I do, to correctly map the certificates and > make them talk to each other ? > I have read the documentation, but I just don't understand how to make > it work. > > The following dn is used for replication: > dn: cn=replication manager,cn=config > objectClass: inetorgperson > objectClass: person > objectClass: top > objectClass: organizationalPerson > cn: replication manager > sn: RM > userPassword: replicate > passwordExpirationTime: 20380119031407Z > > Greetings, > Mitja > > Read the following lines if you wish to know how I have it set up what > I have done to set up non-SSL replication: > The Directory server instances are using their own ports (supplier: > 30389/30636 and consumer: 40389/40636 respectively). > I have inserted a replication user into the dse.ldif files in both the > supplier and the consumer as specified in the documentation. > The supplier has been populated with test entries, enabled the > changelog and replication of the relevant database. > The consumer has been set up accordingly. > I have created an appropriate replication agreement and initialized > the consumer. > All entries replicated as expected and the replica was updating > successfully. If you want to use simple authentication using your replication manager user, but you want the connection to be secure with TLS/SSL, start here - http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_Replication-Replication_over_SSL.html > > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Oct 26 14:49:39 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 26 Oct 2009 08:49:39 -0600 Subject: [389-users] dse.ldif empty! In-Reply-To: <1256441564.6552.214.camel@jaspav.missionsit.net.missionsit.net> References: <1256441564.6552.214.camel@jaspav.missionsit.net.missionsit.net> Message-ID: <4AE5B703.5080005@redhat.com> John A. Sullivan III wrote: > We've just had a huge scare. We reboot our main LDAP server (CentOS DS > 8.1 on newly upgraded CentOS 5.4) and it dirsrv failed to start. > dse.ldif was completely empty. Thankfully, I had a near-line backup. I > restored it and restarted and we seem to be OK. What would cause such a > problem? Thanks - John > Anything in the errors log? Anything in the syslog? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From okelet at gmail.com Mon Oct 26 15:47:32 2009 From: okelet at gmail.com (=?UTF-8?Q?Juan_Asensio_S=C3=A1nchez?=) Date: Mon, 26 Oct 2009 16:47:32 +0100 Subject: [389-users] Query blocking server Message-ID: <52a9d2e30910260847t17049d86m8c76e73a834ea66f@mail.gmail.com> Hi Samba is making a query to our 389 DS (v. 1.2.2, and too older versions) that makes the servers freeze. The server is running, and accepting connections, although the next queries are not processed until the Samba query is returned. This Samba query takes a long time to be returned, because it is searching all databases and all objects in the directory (more than 20000). The filter is "(&(uid=*)(objectClass=sambaSamAccount))". This query is done when executing the command "net user" from a Windows or Linux machine. This queries are executed manually, and intentionally, but should not make the server freeze. Why is this happening? Is there any option to avoid this? Regards. From jsullivan at opensourcedevel.com Mon Oct 26 15:50:38 2009 From: jsullivan at opensourcedevel.com (John A. Sullivan III) Date: Mon, 26 Oct 2009 11:50:38 -0400 Subject: [389-users] dse.ldif empty! In-Reply-To: <4AE5B703.5080005@redhat.com> References: <1256441564.6552.214.camel@jaspav.missionsit.net.missionsit.net> <4AE5B703.5080005@redhat.com> Message-ID: <1256572239.6609.22.camel@jaspav.missionsit.net.missionsit.net> On Mon, 2009-10-26 at 08:49 -0600, Rich Megginson wrote: > John A. Sullivan III wrote: > > We've just had a huge scare. We reboot our main LDAP server (CentOS DS > > 8.1 on newly upgraded CentOS 5.4) and it dirsrv failed to start. > > dse.ldif was completely empty. Thankfully, I had a near-line backup. I > > restored it and restarted and we seem to be OK. What would cause such a > > problem? Thanks - John > > > Anything in the errors log? Anything in the syslog? Very little. It has a complaint that it was not shutdown cleanly. I suppose it is possible the guest hung on the way down and the VM host killed it rudely when the host itself needed to reboot. Thanks - John -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan at opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society From rmeggins at redhat.com Mon Oct 26 15:52:21 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 26 Oct 2009 09:52:21 -0600 Subject: [389-users] Query blocking server In-Reply-To: <52a9d2e30910260847t17049d86m8c76e73a834ea66f@mail.gmail.com> References: <52a9d2e30910260847t17049d86m8c76e73a834ea66f@mail.gmail.com> Message-ID: <4AE5C5B5.5030505@redhat.com> Juan Asensio S?nchez wrote: > Hi > > Samba is making a query to our 389 DS (v. 1.2.2, and too older > versions) that makes the servers freeze. The server is running, and > accepting connections, although the next queries are not processed > until the Samba query is returned. This Samba query takes a long time > to be returned, because it is searching all databases and all objects > in the directory (more than 20000). The filter is > "(&(uid=*)(objectClass=sambaSamAccount))". This query is done when > executing the command "net user" from a Windows or Linux machine. This > queries are executed manually, and intentionally, but should not make > the server freeze. Why is this happening? Is there any option to avoid > this? > I think you need to increase your nsslapd-idlistscanlimit - see http://www.redhat.com/docs/manuals/dir-server/8.1/cli/Configuration_Command_File_Reference-Plug_in_Implemented_Server_Functionality_Reference-Database_Plug_in_Attributes.html#Configuration_Command_File_Reference-Database_Attributes_under_cnconfig_cnldbm_database_cnplugins_cnconfig-nsslapd_idlistscanlimit and http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_Indexes.html#Managing_Indexes-About_Indexes > Regards. > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From okelet at gmail.com Tue Oct 27 12:06:33 2009 From: okelet at gmail.com (=?UTF-8?Q?Juan_Asensio_S=C3=A1nchez?=) Date: Tue, 27 Oct 2009 13:06:33 +0100 Subject: [389-users] Query blocking server In-Reply-To: <4AE5C5B5.5030505@redhat.com> References: <52a9d2e30910260847t17049d86m8c76e73a834ea66f@mail.gmail.com> <4AE5C5B5.5030505@redhat.com> Message-ID: <52a9d2e30910270506hf227c89g436801fb4bb955d4@mail.gmail.com> Hi I have made these changes to the directory: dn: cn=config - nsslapd-sizelimit: 50000 - nsslapd-timelimit: 60 - nsslapd-maxdescriptors: 65535 dn: cn=config, cn=ldbm database, cn=plugins, cn=config - nsslapd-idlistscanlimit: 50000 - nsLookThroughLimit: 50000 - nsslapd-dbcachesize: 838860800 (=800MB) - nsslapd-allidsthreshold: 10000 dn: cn=database_name, cn=ldbm database, cn=plugins, cn=config (in the 26 databases) nsslapd-cachememsize: 125829120 (=120MB) I have reindexed all databases. But the server freezes when making that query. The server is accepting connections and queries, but not responding them until all the results of the first query are displayed in the client (the results starts to display almost immediately, but keeps 5 minutes displaying the results on the client, and when the display finishes, the other queries are processed). Any idea? Regards. 2009/10/26 Rich Megginson : > Juan Asensio S?nchez wrote: >> >> Hi >> >> Samba is making a query to our 389 DS (v. 1.2.2, and too older >> versions) that makes the servers freeze. The server is running, and >> accepting connections, although the next queries are not processed >> until the Samba query is returned. This Samba query takes a long time >> to be returned, because it is searching all databases and all objects >> in the directory (more than 20000). The filter is >> "(&(uid=*)(objectClass=sambaSamAccount))". This query is done when >> executing the command "net user" from a Windows or Linux machine. This >> queries are executed manually, and intentionally, but should not make >> the server freeze. Why is this happening? Is there any option to avoid >> this? >> > > I think you need to increase your nsslapd-idlistscanlimit - see > http://www.redhat.com/docs/manuals/dir-server/8.1/cli/Configuration_Command_File_Reference-Plug_in_Implemented_Server_Functionality_Reference-Database_Plug_in_Attributes.html#Configuration_Command_File_Reference-Database_Attributes_under_cnconfig_cnldbm_database_cnplugins_cnconfig-nsslapd_idlistscanlimit > and > http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_Indexes.html#Managing_Indexes-About_Indexes >> >> Regards. >> >> -- >> 389 users mailing list >> 389-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > > > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > From andrey.ivanov at polytechnique.fr Tue Oct 27 13:13:54 2009 From: andrey.ivanov at polytechnique.fr (Andrey Ivanov) Date: Tue, 27 Oct 2009 14:13:54 +0100 Subject: [389-users] Query blocking server In-Reply-To: <52a9d2e30910270506hf227c89g436801fb4bb955d4@mail.gmail.com> References: <52a9d2e30910260847t17049d86m8c76e73a834ea66f@mail.gmail.com> <4AE5C5B5.5030505@redhat.com> <52a9d2e30910270506hf227c89g436801fb4bb955d4@mail.gmail.com> Message-ID: <1601b8650910270613y7b866090w79902cfc3888fc4b@mail.gmail.com> Hi, Do you make the ldapsearch on the same server where ldap server turns? I think your server does not freeze. When you receive the result search entries the CPU of your server is occupied at 100%. If it is a virtual machine that you are using try to add another cpu. Instead of showing the result on the screen in order to have a more consistent of your test try to redirect it to /dev/null, smth like this : ldapsearch -Y GSSAPI -h ldap-server.your.domain -b "dc=your,dc=domain" "(objectClass=*)" > /dev/null And do your ldapsearch on another machine, not on the server... 2009/10/27 Juan Asensio S?nchez > Hi > > I have made these changes to the directory: > > dn: cn=config > - nsslapd-sizelimit: 50000 > - nsslapd-timelimit: 60 > - nsslapd-maxdescriptors: 65535 > > dn: cn=config, cn=ldbm database, cn=plugins, cn=config > - nsslapd-idlistscanlimit: 50000 > - nsLookThroughLimit: 50000 > - nsslapd-dbcachesize: 838860800 (=800MB) > - nsslapd-allidsthreshold: 10000 > > dn: cn=database_name, cn=ldbm database, cn=plugins, cn=config (in the > 26 databases) > nsslapd-cachememsize: 125829120 (=120MB) > > I have reindexed all databases. But the server freezes when making > that query. The server is accepting connections and queries, but not > responding them until all the results of the first query are displayed > in the client (the results starts to display almost immediately, but > keeps 5 minutes displaying the results on the client, and when the > display finishes, the other queries are processed). > > Any idea? Regards. > > > 2009/10/26 Rich Megginson : > > Juan Asensio S?nchez wrote: > >> > >> Hi > >> > >> Samba is making a query to our 389 DS (v. 1.2.2, and too older > >> versions) that makes the servers freeze. The server is running, and > >> accepting connections, although the next queries are not processed > >> until the Samba query is returned. This Samba query takes a long time > >> to be returned, because it is searching all databases and all objects > >> in the directory (more than 20000). The filter is > >> "(&(uid=*)(objectClass=sambaSamAccount))". This query is done when > >> executing the command "net user" from a Windows or Linux machine. This > >> queries are executed manually, and intentionally, but should not make > >> the server freeze. Why is this happening? Is there any option to avoid > >> this? > >> > > > > I think you need to increase your nsslapd-idlistscanlimit - see > > > http://www.redhat.com/docs/manuals/dir-server/8.1/cli/Configuration_Command_File_Reference-Plug_in_Implemented_Server_Functionality_Reference-Database_Plug_in_Attributes.html#Configuration_Command_File_Reference-Database_Attributes_under_cnconfig_cnldbm_database_cnplugins_cnconfig-nsslapd_idlistscanlimit > > and > > > http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_Indexes.html#Managing_Indexes-About_Indexes > >> > >> Regards. > >> > >> -- > >> 389 users mailing list > >> 389-users at redhat.com > >> https://www.redhat.com/mailman/listinfo/fedora-directory-users > >> > > > > > > > > -- > > 389 users mailing list > > 389-users at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From okelet at gmail.com Tue Oct 27 13:39:00 2009 From: okelet at gmail.com (=?UTF-8?Q?Juan_Asensio_S=C3=A1nchez?=) Date: Tue, 27 Oct 2009 14:39:00 +0100 Subject: [389-users] Query blocking server In-Reply-To: <1601b8650910270613y7b866090w79902cfc3888fc4b@mail.gmail.com> References: <52a9d2e30910260847t17049d86m8c76e73a834ea66f@mail.gmail.com> <4AE5C5B5.5030505@redhat.com> <52a9d2e30910270506hf227c89g436801fb4bb955d4@mail.gmail.com> <1601b8650910270613y7b866090w79902cfc3888fc4b@mail.gmail.com> Message-ID: <52a9d2e30910270639h66e62e22s1cf58b0b42e79e4@mail.gmail.com> Hi, thanks for your answer. 2009/10/27 Andrey Ivanov : > Hi, > > Do you make the ldapsearch on the same server where ldap server turns? Yes, sure. > I think your server does not freeze. When you receive the result search > entries the CPU of your server is occupied at 100%. Yes, if I monitor the server, ONE if the cores is at 100%. I mean the LDAP service freezes, not the full server. > If it is a virtual > machine that you are using? try to add another cpu. No, this is a real machine with 8 cores (2 CPUs). > Instead of showing the > result on the screen in order to have a more consistent of your test try to > redirect it to /dev/null, smth like this : > > ldapsearch -Y GSSAPI -h ldap-server.your.domain -b "dc=your,dc=domain" > "(objectClass=*)" > /dev/null >From my computer: time ldapsearch -H ldaps://ldapa1.sacyl.es -D "uid=adminsamba_XXXX,ou=dominio_samba,o=XXXX,dc=XXXXX,dc=XX" -w XXXXXX -b "dc=XXXXXX,dc=XXX" "(&(uid=*)(objectClass=sambasamaccount))" -LLL -x > /dev/null real 6m23.429s user 0m4.060s sys 0m0.420s While doing this query, I run one more, and until the first is not finished, the second did not respond. > And do your ldapsearch on another machine, not on the server... The search is always done from other machine (the Samba server, or my computer). Regards. From david_list at boreham.org Tue Oct 27 13:53:28 2009 From: david_list at boreham.org (David Boreham) Date: Tue, 27 Oct 2009 07:53:28 -0600 Subject: [389-users] Query blocking server In-Reply-To: <52a9d2e30910270639h66e62e22s1cf58b0b42e79e4@mail.gmail.com> References: <52a9d2e30910260847t17049d86m8c76e73a834ea66f@mail.gmail.com> <4AE5C5B5.5030505@redhat.com> <52a9d2e30910270506hf227c89g436801fb4bb955d4@mail.gmail.com> <1601b8650910270613y7b866090w79902cfc3888fc4b@mail.gmail.com> <52a9d2e30910270639h66e62e22s1cf58b0b42e79e4@mail.gmail.com> Message-ID: <4AE6FB58.3090203@boreham.org> One core at 100% is to be expected if you're executing a long-running (unindexed) search over data that's mostly already in memory. What's not expected is that other concurrent operations (even on the same connection) should block. Generally that shouldn't happen. You might try turning up the logging level (to see more diagnostic and debug output) while executing these searches to see if there's any clue there about what's going on. From rmeggins at redhat.com Tue Oct 27 14:10:04 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 27 Oct 2009 08:10:04 -0600 Subject: [389-users] Query blocking server In-Reply-To: <52a9d2e30910270639h66e62e22s1cf58b0b42e79e4@mail.gmail.com> References: <52a9d2e30910260847t17049d86m8c76e73a834ea66f@mail.gmail.com> <4AE5C5B5.5030505@redhat.com> <52a9d2e30910270506hf227c89g436801fb4bb955d4@mail.gmail.com> <1601b8650910270613y7b866090w79902cfc3888fc4b@mail.gmail.com> <52a9d2e30910270639h66e62e22s1cf58b0b42e79e4@mail.gmail.com> Message-ID: <4AE6FF3C.7010606@redhat.com> Juan Asensio S?nchez wrote: > Hi, thanks for your answer. > > 2009/10/27 Andrey Ivanov : > >> Hi, >> >> Do you make the ldapsearch on the same server where ldap server turns? >> > > Yes, sure. > > > >> I think your server does not freeze. When you receive the result search >> entries the CPU of your server is occupied at 100%. >> > > Yes, if I monitor the server, ONE if the cores is at 100%. I mean the > LDAP service freezes, not the full server. > > > >> If it is a virtual >> machine that you are using try to add another cpu. >> > > No, this is a real machine with 8 cores (2 CPUs). > > > >> Instead of showing the >> result on the screen in order to have a more consistent of your test try to >> redirect it to /dev/null, smth like this : >> >> ldapsearch -Y GSSAPI -h ldap-server.your.domain -b "dc=your,dc=domain" >> "(objectClass=*)" > /dev/null >> > > >From my computer: > time ldapsearch -H ldaps://ldapa1.sacyl.es -D > "uid=adminsamba_XXXX,ou=dominio_samba,o=XXXX,dc=XXXXX,dc=XX" -w XXXXXX > -b "dc=XXXXXX,dc=XXX" "(&(uid=*)(objectClass=sambasamaccount))" -LLL > -x > /dev/null > > real 6m23.429s > user 0m4.060s > sys 0m0.420s > > While doing this query, I run one more, and until the first is not > finished, the second did not respond. > How many entries match this search filter? Is your nsslapd-idlistscanlimit high enough to hold both all of the uid=* entries and all of the objectClass=sambasamaccount entries? > > >> And do your ldapsearch on another machine, not on the server... >> > > The search is always done from other machine (the Samba server, or my computer). > > Regards. > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From okelet at gmail.com Tue Oct 27 14:15:39 2009 From: okelet at gmail.com (=?UTF-8?Q?Juan_Asensio_S=C3=A1nchez?=) Date: Tue, 27 Oct 2009 15:15:39 +0100 Subject: [389-users] Query blocking server In-Reply-To: <4AE6FF3C.7010606@redhat.com> References: <52a9d2e30910260847t17049d86m8c76e73a834ea66f@mail.gmail.com> <4AE5C5B5.5030505@redhat.com> <52a9d2e30910270506hf227c89g436801fb4bb955d4@mail.gmail.com> <1601b8650910270613y7b866090w79902cfc3888fc4b@mail.gmail.com> <52a9d2e30910270639h66e62e22s1cf58b0b42e79e4@mail.gmail.com> <4AE6FF3C.7010606@redhat.com> Message-ID: <52a9d2e30910270715p585a99f1jdb9c668b6a5c97f3@mail.gmail.com> > How many entries match this search filter? ?Is your nsslapd-idlistscanlimit > high enough to hold both all of the uid=* entries and all of the > objectClass=sambasamaccount entries? We have about 25000 sambaSamAccount objects. nsslapd-idlistscanlimit is set to 50000 (total object are about 40000). Databases have been reindexed. Regards. From okelet at gmail.com Tue Oct 27 14:15:39 2009 From: okelet at gmail.com (=?UTF-8?Q?Juan_Asensio_S=C3=A1nchez?=) Date: Tue, 27 Oct 2009 15:15:39 +0100 Subject: [389-users] Query blocking server In-Reply-To: <4AE6FF3C.7010606@redhat.com> References: <52a9d2e30910260847t17049d86m8c76e73a834ea66f@mail.gmail.com> <4AE5C5B5.5030505@redhat.com> <52a9d2e30910270506hf227c89g436801fb4bb955d4@mail.gmail.com> <1601b8650910270613y7b866090w79902cfc3888fc4b@mail.gmail.com> <52a9d2e30910270639h66e62e22s1cf58b0b42e79e4@mail.gmail.com> <4AE6FF3C.7010606@redhat.com> Message-ID: <52a9d2e30910270715p585a99f1jdb9c668b6a5c97f3@mail.gmail.com> > How many entries match this search filter? ?Is your nsslapd-idlistscanlimit > high enough to hold both all of the uid=* entries and all of the > objectClass=sambasamaccount entries? We have about 25000 sambaSamAccount objects. nsslapd-idlistscanlimit is set to 50000 (total object are about 40000). Databases have been reindexed. Regards. From andrey.ivanov at polytechnique.fr Tue Oct 27 15:09:11 2009 From: andrey.ivanov at polytechnique.fr (Andrey Ivanov) Date: Tue, 27 Oct 2009 16:09:11 +0100 Subject: [389-users] Query blocking server In-Reply-To: <52a9d2e30910270715p585a99f1jdb9c668b6a5c97f3@mail.gmail.com> References: <52a9d2e30910260847t17049d86m8c76e73a834ea66f@mail.gmail.com> <4AE5C5B5.5030505@redhat.com> <52a9d2e30910270506hf227c89g436801fb4bb955d4@mail.gmail.com> <1601b8650910270613y7b866090w79902cfc3888fc4b@mail.gmail.com> <52a9d2e30910270639h66e62e22s1cf58b0b42e79e4@mail.gmail.com> <4AE6FF3C.7010606@redhat.com> <52a9d2e30910270715p585a99f1jdb9c668b6a5c97f3@mail.gmail.com> Message-ID: <1601b8650910270809u305b948et80f68b5b3ca186e4@mail.gmail.com> 6 minutes for 25000 entries is obviously too much. On our server (HP of two years old ang 2Go of memory) 8300 entries are returned in 0.77 seconds (the filter is almost like yours - "(&(uid=*)(objectClass=inetOrgPerson))"). There is certainly some problem either with the disk access or with the memory sizing or with the indexed searches in your configuration... Do you have the PRESENCE index on uid? 2009/10/27 Juan Asensio S?nchez > > How many entries match this search filter? Is your > nsslapd-idlistscanlimit > > high enough to hold both all of the uid=* entries and all of the > > objectClass=sambasamaccount entries? > > We have about 25000 sambaSamAccount objects. nsslapd-idlistscanlimit > is set to 50000 (total object are about 40000). Databases have been > reindexed. > > Regards. > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.zimm at gmail.com Wed Oct 28 01:18:59 2009 From: john.zimm at gmail.com (J. Zimmerman) Date: Tue, 27 Oct 2009 18:18:59 -0700 Subject: [389-users] Importing a Large LDIF File Message-ID: <179417830910271818p31da0541m5ab0d41fe93d0274@mail.gmail.com> Hi All, I am fairly new to LDAP administration and was wondering approximately how long it should take to import approximately 500,000 user records. I have tried from both the administration console as well as the from the command line and everything seems to be taking forever (days). I don't have a lot to compare it to, but I have a feeling that even with this many records into a single LDAP instance should go a lot faster. Thanks! -John -------------- next part -------------- An HTML attachment was scrubbed... URL: From msauton at redhat.com Wed Oct 28 01:29:09 2009 From: msauton at redhat.com (Marc Sauton) Date: Tue, 27 Oct 2009 18:29:09 -0700 Subject: [389-users] Importing a Large LDIF File In-Reply-To: <179417830910271818p31da0541m5ab0d41fe93d0274@mail.gmail.com> References: <179417830910271818p31da0541m5ab0d41fe93d0274@mail.gmail.com> Message-ID: <4AE79E65.6040406@redhat.com> That will heavily depends on the hardware used, cpu arch, i/o for disk. An "old" hardware can get a few hundred entries per sec. You should be able to get several thousand entries per second with "recent" hw, should reasonably be under 15 minutes. A small virtual machine can get 500 entries per seconds, a VM running on a "good" host will get more. M. J. Zimmerman wrote: > Hi All, > > I am fairly new to LDAP administration and was wondering approximately > how long it should take to import approximately 500,000 user records. > > I have tried from both the administration console as well as the from > the command line and everything seems to be taking forever (days). I > don't have a lot to compare it to, but I have a feeling that even with > this many records into a single LDAP instance should go a lot faster. > > Thanks! > > -John > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6650 bytes Desc: S/MIME Cryptographic Signature URL: From vitty at altlinux.ru Wed Oct 28 07:49:46 2009 From: vitty at altlinux.ru (Vitaly Kuznetsov) Date: Wed, 28 Oct 2009 10:49:46 +0300 Subject: [389-users] Importing a Large LDIF File In-Reply-To: <179417830910271818p31da0541m5ab0d41fe93d0274@mail.gmail.com> (J. Zimmerman's message of "Tue, 27 Oct 2009 18:18:59 -0700") References: <179417830910271818p31da0541m5ab0d41fe93d0274@mail.gmail.com> Message-ID: "J. Zimmerman" writes: > Hi All, > > I am fairly new to LDAP administration and was wondering approximately > how > long it should take to import approximately 500,000 user records. > I had created 60,000,000 user records for test. It took less than 1 day. -- Vitaly Kuznetsov, ALT Linux. From okelet at gmail.com Wed Oct 28 07:58:39 2009 From: okelet at gmail.com (=?UTF-8?Q?Juan_Asensio_S=C3=A1nchez?=) Date: Wed, 28 Oct 2009 08:58:39 +0100 Subject: [389-users] Query blocking server In-Reply-To: <1601b8650910270809u305b948et80f68b5b3ca186e4@mail.gmail.com> References: <52a9d2e30910260847t17049d86m8c76e73a834ea66f@mail.gmail.com> <4AE5C5B5.5030505@redhat.com> <52a9d2e30910270506hf227c89g436801fb4bb955d4@mail.gmail.com> <1601b8650910270613y7b866090w79902cfc3888fc4b@mail.gmail.com> <52a9d2e30910270639h66e62e22s1cf58b0b42e79e4@mail.gmail.com> <4AE6FF3C.7010606@redhat.com> <52a9d2e30910270715p585a99f1jdb9c668b6a5c97f3@mail.gmail.com> <1601b8650910270809u305b948et80f68b5b3ca186e4@mail.gmail.com> Message-ID: <52a9d2e30910280058jf1d2241n66d48b66b04a5d50@mail.gmail.com> 2009/10/27 Andrey Ivanov : > 6 minutes for 25000 entries is obviously too much. On our server? (HP of two > years old ang 2Go of memory)? 8300 entries are returned in 0.77 seconds (the > filter is almost like yours - "(&(uid=*)(objectClass=inetOrgPerson))"). > There is certainly some problem either with the disk access or with the > memory sizing or with the indexed searches in your configuration... Do you > have the PRESENCE index on uid? > For one moment I thought UID was not indexed, but I checked twice it is indexed. These are all the attributes indexed in out databases: aci: system: true type: [pres] entryDN: system: true type: [eq] nscpEntryDN: system: true type: [eq] nsds5ReplConflict: system: true type: [eq, pres] nsUniqueId: system: true type: [eq] numSubordinates: system: true type: [pres] objectClass: system: true type: [eq, pres] parentID: system: true type: [eq] cn: system: false type: [pres, eq, sub] displayName: system: false type: [pres, eq, sub] gidNumber: system: false type: [pres, eq] givenName: system: false type: [pres, eq, sub] mail: system: false type: [pres, eq, sub] mailAlternateAddress: system: false type: [pres, eq, sub] memberOf: system: false type: [eq] memberUid: system: false type: [eq] ntUniqueId: system: false type: [eq] ntUserDomainId: system: false type: [eq] o: system: false type: [pres, eq, sub] ou: system: false type: [pres, eq, sub] sambaDomainName: system: false type: [pres, eq] sambaGroupType: system: false type: [pres, eq] sambaPrimaryGroupSID: system: false type: [pres, eq] sambaSID: system: false type: [pres, eq] sambaSIDList: system: false type: [pres, eq] seeAlso: system: false type: [pres, eq, sub] sn: system: false type: [pres, eq, sub] telephoneNumber: system: false type: [pres, eq, sub] uid: system: false type: [pres, eq, sub] uidNumber: system: false type: [pres, eq] uniqueMember: system: false type: [pres, eq, sub] (This is part of a file we use to define database indexes, adding or removing necessary attributes to the default indexes). Regards. From mitja.mihelic at arnes.si Wed Oct 28 08:06:01 2009 From: mitja.mihelic at arnes.si (=?UTF-8?B?TWl0amEgTWloZWxpxI0=?=) Date: Wed, 28 Oct 2009 09:06:01 +0100 Subject: [389-users] Replication over SSL In-Reply-To: <4AE5B6EE.5050003@redhat.com> References: <4AE173B2.4060001@arnes.si> <4AE5B6EE.5050003@redhat.com> Message-ID: <4AE7FB69.9040104@arnes.si> Thank you for your hint. I did read the suggested documentation before asking for assistance, but did not understand it at that time. In the end I used simple authentication over TLS/SSL. Regards, Mitja Rich Megginson wrote: > Mitja Miheli? wrote: >> Hi! >> >> I am trying to get replication to work over SSL, but I seem to be >> missing something... >> >> To make a long story short: single-master and multi-master >> replication without SSL works without a problem. >> >> I have created two Directory servers via the Management Console, one >> called master (supplier) and one called replica (consumer). >> I have issued a certificate request via the management console for >> the supplier and consumer. >> Both were signed by a test CA and imported into the corresponding >> server's certificate store. >> Now, what exactly must I do, to correctly map the certificates and >> make them talk to each other ? >> I have read the documentation, but I just don't understand how to >> make it work. >> >> The following dn is used for replication: >> dn: cn=replication manager,cn=config >> objectClass: inetorgperson >> objectClass: person >> objectClass: top >> objectClass: organizationalPerson >> cn: replication manager >> sn: RM >> userPassword: replicate >> passwordExpirationTime: 20380119031407Z >> >> Greetings, >> Mitja >> >> Read the following lines if you wish to know how I have it set up >> what I have done to set up non-SSL replication: >> The Directory server instances are using their own ports (supplier: >> 30389/30636 and consumer: 40389/40636 respectively). >> I have inserted a replication user into the dse.ldif files in both >> the supplier and the consumer as specified in the documentation. >> The supplier has been populated with test entries, enabled the >> changelog and replication of the relevant database. >> The consumer has been set up accordingly. >> I have created an appropriate replication agreement and initialized >> the consumer. >> All entries replicated as expected and the replica was updating >> successfully. > If you want to use simple authentication using your replication > manager user, but you want the connection to be secure with TLS/SSL, > start here - > http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_Replication-Replication_over_SSL.html > > >> >> >> -- >> 389 users mailing list >> 389-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > From mitja.mihelic at arnes.si Thu Oct 29 10:03:59 2009 From: mitja.mihelic at arnes.si (=?UTF-8?B?TWl0amEgTWloZWxpxI0=?=) Date: Thu, 29 Oct 2009 11:03:59 +0100 Subject: [389-users] Replication: update of supplier via referral from consumer not working Message-ID: <4AE9688F.6060408@arnes.si> Hi! Note: real information (IPs, DNs, FQDNs) has been replaced with generic information. I have set up a single-master replication scenario. supplier: ldap://supplier.example.com:389 consumer: ldap://consumer.example.com:389 Replications works with no problems. I have entered "ldap://supplier.example.com:389/dc=example, dc=com" in the "Current URLs for referrals (Optional)" field. If I understand correctly, when trying to update an entry on the consumer, the referral should take me to the supplier and perform the update there. But I get the following error from the consumers console: "netscape.ldap.LDAPException: error result (32); No such object; Failed to follow referral to ldap://supplier.example.com:389/edupersonprincipalname=user.name at example.com.si,dc=example," As you can see, there is a part of the DN missing and I have no idea why... This is the information from the suppliers error log, again with the incomplete DN: [snip] [29/Oct/2009:10:17:49 +0100] conn=18 fd=70 slot=70 connection from CONSUMER_IP to SUPPLIER_IP [29/Oct/2009:10:17:49 +0100] conn=18 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [29/Oct/2009:10:17:49 +0100] conn=18 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [29/Oct/2009:10:17:49 +0100] conn=18 op=1 MOD dn="edupersonprincipalname=user.name at example.com.si,dc=example," [29/Oct/2009:10:17:49 +0100] conn=18 op=1 RESULT err=32 tag=103 nentries=0 etime=0 [29/Oct/2009:10:17:49 +0100] conn=18 op=2 UNBIND [29/Oct/2009:10:17:49 +0100] conn=18 op=2 fd=70 closed - U1 [/snip] Regards, Mitja From rmeggins at redhat.com Thu Oct 29 13:30:02 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 29 Oct 2009 07:30:02 -0600 Subject: [389-users] Replication: update of supplier via referral from consumer not working In-Reply-To: <4AE9688F.6060408@arnes.si> References: <4AE9688F.6060408@arnes.si> Message-ID: <4AE998DA.2070907@redhat.com> Mitja Miheli? wrote: > Hi! > > Note: real information (IPs, DNs, FQDNs) has been replaced with > generic information. > > I have set up a single-master replication scenario. > supplier: ldap://supplier.example.com:389 > consumer: ldap://consumer.example.com:389 > Replications works with no problems. > > I have entered "ldap://supplier.example.com:389/dc=example, dc=com" in > the "Current URLs for referrals (Optional)" field. Why? Replication sets the referrals automatically - that's why the console lists this field as (Optional). Don't use these referrals unless you have to. Secondly, you have a space in there - use dc=example,dc=com instead. If you need to have spaces and other meta-characters in the LDAP URL, see http://www.ietf.org/rfc/rfc4516.txt > > If I understand correctly, when trying to update an entry on the > consumer, the referral should take me to the supplier and perform the > update there. > > But I get the following error from the consumers console: > "netscape.ldap.LDAPException: error result (32); No such object; > Failed to follow referral to > ldap://supplier.example.com:389/edupersonprincipalname=user.name at example.com.si,dc=example," > > > > As you can see, there is a part of the DN missing and I have no idea > why... > > > This is the information from the suppliers error log, again with the > incomplete DN: > > [snip] > [29/Oct/2009:10:17:49 +0100] conn=18 fd=70 slot=70 connection from > CONSUMER_IP to SUPPLIER_IP > [29/Oct/2009:10:17:49 +0100] conn=18 op=0 BIND dn="cn=Directory > Manager" method=128 version=3 > [29/Oct/2009:10:17:49 +0100] conn=18 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=directory manager" > [29/Oct/2009:10:17:49 +0100] conn=18 op=1 MOD > dn="edupersonprincipalname=user.name at example.com.si,dc=example," > [29/Oct/2009:10:17:49 +0100] conn=18 op=1 RESULT err=32 tag=103 > nentries=0 etime=0 > [29/Oct/2009:10:17:49 +0100] conn=18 op=2 UNBIND > [29/Oct/2009:10:17:49 +0100] conn=18 op=2 fd=70 closed - U1 > [/snip] > > Regards, > Mitja > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From ajaykalla83 at fedoraproject.org Fri Oct 30 08:18:21 2009 From: ajaykalla83 at fedoraproject.org (Ajay Kalla) Date: Fri, 30 Oct 2009 11:18:21 +0300 Subject: [389-users] How to integrated FDS with Oracle Message-ID: <582960760910300118t4feeacf1m145dd20d979dcbf7@mail.gmail.com> Hello Everyone I am presently working on FDS and oracle . i faced problem related to users created on Oracle 10g should be able to login on client end (like M$ and linux) using FDS. Please help me out. -- Ajay Kalla Fedora Ambassador ajaykalla83 at fedoraproject.org GPG 0xEAB7E325 Find me as mikhail @ freenode.net Idling at ##Koenig-Solutions,#fedora,#fedora-lassroom,##security -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.ivanov at polytechnique.fr Fri Oct 30 08:29:24 2009 From: andrey.ivanov at polytechnique.fr (Andrey Ivanov) Date: Fri, 30 Oct 2009 09:29:24 +0100 Subject: [389-users] How to integrated FDS with Oracle In-Reply-To: <582960760910300118t4feeacf1m145dd20d979dcbf7@mail.gmail.com> References: <582960760910300118t4feeacf1m145dd20d979dcbf7@mail.gmail.com> Message-ID: <1601b8650910300129x6e34d78j65be2b180309545@mail.gmail.com> I think you could use the pam passthrough plug-in ( http://directory.fedoraproject.org/wiki/Howto:PAM_Pass_Through) if you do have the corresponding Oracle pam module. On the other hand it seems that oracle databases support user authentification by LDAP directories (ex. : http://www.oracle.com/technology/products/oid/oidhtml/sec_idm_training/html_masters/handson.htm ). 2009/10/30 Ajay Kalla > Hello Everyone > > I am presently working on FDS and oracle . i faced problem related to users > created on Oracle 10g should be able to > login on client end (like M$ and linux) using FDS. Please help me out. > > -- > Ajay Kalla > Fedora Ambassador > ajaykalla83 at fedoraproject.org > GPG 0xEAB7E325 > Find me as mikhail @ freenode.net > Idling at ##Koenig-Solutions,#fedora,#fedora-lassroom,##security > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert+fds at shangri-la.ts.gatech.edu Fri Oct 30 14:27:02 2009 From: robert+fds at shangri-la.ts.gatech.edu (Robert Viduya) Date: Fri, 30 Oct 2009 10:27:02 -0400 Subject: [389-users] changelog issues when re-initing a master Message-ID: Hi, apologies if this gets posted more than once, I'm having MUA issues. We have a 4-master, 2-hub, 6-slave set up, scattered over 2 data- centers. We had been running fine with 2 masters and fedora-ds 1.0.4 on RHEL4 (32-bit), but this past summer, we decided to upgrade to 4 masters, RHEL5 (64-bit) and fedora-ds 1.2.0. We did clean installs, not upgrades and everything went pretty smoothly. Lately, however, we've run into a problem where we've had to reinitialize one of the masters due to database corruption. The process I've used was, on a running master, to right-click on the replication agreement in the gui and select "Export". Then I'd scp the resultant ldif file to the down master and import it using ldif2db. Once the import was done, restarting the server produces the following in the errorlog: [29/Oct/2009:05:21:05 -0400] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: data for replica ou=accounts,ou=gtaccounts,ou=departments,dc=gted,dc=gatech,dc=edu was reloaded and it no longer matches the data in the changelog (replica data > changelog). Recreating the changelog file. This could affect replication with replica's consumers in which case the consumers should be reinitialized. which is perfectly fine, you expect the changelog to be invalid the first time the server is brought up after a reinitialize. The problem is that it does this each and every time the server is restarted from then on. This sounds a lot like bug 388021, but nothing I've read in there helps. I've tried deleting the changelog before importing, deleting the changelog after importing, setting the changelog size to 1 entry, delete-and-recreate all agreements... nothing. If the server has a changelog configured and it gets restarted, it trashes it and recreates. This system is a production system and importing our data is a good 8 to 12 hour process. Management really doesn't want to give me the time to start from scratch, so I can't take all the machines down and rebuild everything. Besides, reinitializing a single master shouldn't involve a complete rebuild like that. Any help would be greatly appreciated. From scoobydooxp at cryogen.net Sat Oct 31 06:23:54 2009 From: scoobydooxp at cryogen.net (Scooby Doo) Date: Sat, 31 Oct 2009 01:23:54 -0500 Subject: [389-users] mod_authnz_ldap - authorize by group Message-ID: <1b1a7d9ce339780b61aa417b101e3042.squirrel@www.cryogen.net> I was wondering if anyone could share how to properly setup mod_authnz_ldap to authorize with directory server groups. The wiki has docs on how to use mod_authz_ldap but nothing for mod_authnz_ldap in the groups area. Thank you, Scooby AuthName "Restricted Access" AuthType Basic AuthBasicProvider ldap AuthzLDAPAuthoritative off AuthLDAPGroupAttribute uniqueMember AuthLDAPGroupAttributeIsDN on AuthLDAPURL "ldap://localhost/ou=groups,dc=local?uniqueMember?sub?(objectClass=groupOfUniqueNames)" Require ldap-group "cn=Security,ou=groups,dc=local" http://directory.fedoraproject.org/wiki/Howto:Apache#Authorize_by_Group