Re: [389-users] New Zenoss ZenPack to monitor 389 (and other cn=monitor) DS
Hi, thanks for the pack. On ZenOSS3.2.1 I get the message 'NoneType' object has no attribute 'clone' when I try to install it. Regards! - Mensaje original - De: Alan Milligan alan.milli...@last-bastion.net Para: 389-users@lists.fedoraproject.org Enviados: Lunes, 12 de Marzo 2012 8:06:50 Asunto: [389-users] New Zenoss ZenPack to monitor 389 (and other cn=monitor) DS Hi, I recently released ZenPacks.lbn.LDAPMonitor for large-scale DS installations. It's available on PyPi: http://pypi.python.org/pypi/ZenPacks.lbn.LDAPMonitor/3.0.3 We do enterprise LDAP at: http://linux.last-bastion.net/LBN/up2date/aim/13 We do enterprise Zenoss monitoring at: http://linux.last-bastion.net/LBN/monitor/aim/13 These RPM packages also run on RHEL6/CentOS6, and you can find our BastionLinux on AWS/EC2, and we do make the systems available on VMWare/vSphere (and other virtualisation) platforms. Please do feel free to download and use the ZenPack. If you're using other cn=monitor LDAP's, please do let us know and we'll try and ensure compatibility with our RRD graphs. Alan -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- -- J u an Carlos Camargo Carrillo 957-211157 , 650932877 attachment: logo.jpg-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] New Zenoss ZenPack to monitor 389 (and other, cn=monitor) DS
Juan Carlos wrote: Hi, thanks for the pack. On ZenOSS3.2.1 I get the message 'NoneType' object has no attribute 'clone' when I try to install it. That's a bit of a pain. But we don't really trust Zenoss to release anything around Zope and use a much more modern Zope stack (including quite a few patches to get Zenoss to behave properly). I suspect your error is due to Zenoss's version of ZODB - but you've not exactly given us a stack trace ... Alan -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] LDAP server is unwilling to perform
Pls see attached new console.log. Thanks. Mike From: Rich Megginson [mailto:rmegg...@redhat.com] Sent: Monday, March 12, 2012 3:14 PM To: General discussion list for the 389 Directory server project. Cc: Michael James Subject: Re: [389-users] LDAP server is unwilling to perform On 03/12/2012 12:39 PM, mja...@guesswho.commailto:mja...@guesswho.com wrote: Pls. see attached. Thx. Hmm - nothing to go on there - please turn on the Replication log level and reproduce the problem - then the errors log may contain more clues http://port389.org/wiki/FAQ#Troubleshooting Mike From: Rich Megginson [mailto:rmegg...@redhat.com] Sent: Monday, March 12, 2012 1:30 PM To: General discussion list for the 389 Directory server project. Cc: Michael James Subject: Re: [389-users] LDAP server is unwilling to perform On 03/12/2012 11:30 AM, mja...@guesswho.commailto:mja...@guesswho.com wrote: Thanks for your previous help. I built a new server, CentOS 6.2, added the epel-389-ds-base and epel repos, then installed 389-ds via yum. I ran setup-ds-admin.pl with the “Typical” setup option, user nobody, and registered with one of our existing configuration servers. I created the supplier bind DN on the new server per the installation docs. At this point, I can’t establish a replication agreement. I open the 389-console on existing server and use the GUI to create a new replication agreement on userRoot. I accepted the defaults, entered the correct bind DN and password. At the end of the wizard, it fails with “LDAP server is unwilling to perform”. In the error log, I see one error. Any help is appreciated. Thanks, Mike Can you run the console with -D 9 -f console.log, reproduce the problem, remove any sensitive information from console.log, and post console.log to this list? [12/Mar/2012:13:26:46 -0400] NSMMReplicationPlugin - agmtlist_add_callback: Can't start agreement cn=389 to analog-01v,cn=replica,cn=dc\3dMY_DOMAIN\2c dc\3dcom,cn=mapping tree,cn=config -- 389 users mailing list 389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users console.tgz Description: console.tgz -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] LDAP server is unwilling to perform
On 03/13/2012 09:41 AM, mja...@guesswho.com wrote: Pls see attached new console.log. Thanks. If you follow the directions at http://port389.org/wiki/FAQ#Troubleshooting to enable the Replication log level, the extra information will be in the directory server errors log, not the console log - /var/log/dirsrv/slapd-INST/errors Mike *From:*Rich Megginson [mailto:rmegg...@redhat.com] *Sent:* Monday, March 12, 2012 3:14 PM *To:* General discussion list for the 389 Directory server project. *Cc:* Michael James *Subject:* Re: [389-users] LDAP server is unwilling to perform On 03/12/2012 12:39 PM, mja...@guesswho.com mailto:mja...@guesswho.com wrote: Pls. see attached. Thx. Hmm - nothing to go on there - please turn on the Replication log level and reproduce the problem - then the errors log may contain more clues http://port389.org/wiki/FAQ#Troubleshooting Mike *From:*Rich Megginson [mailto:rmegg...@redhat.com] *Sent:* Monday, March 12, 2012 1:30 PM *To:* General discussion list for the 389 Directory server project. *Cc:* Michael James *Subject:* Re: [389-users] LDAP server is unwilling to perform On 03/12/2012 11:30 AM, mja...@guesswho.com mailto:mja...@guesswho.com wrote: Thanks for your previous help. I built a new server, CentOS 6.2, added the epel-389-ds-base and epel repos, then installed 389-ds via yum. I ran setup-ds-admin.pl with the “Typical” setup option, user nobody, and registered with one of our existing configuration servers. I created the supplier bind DN on the new server per the installation docs. At this point, I can’t establish a replication agreement. I open the 389-console on existing server and use the GUI to create a new replication agreement on userRoot. I accepted the defaults, entered the correct bind DN and password. At the end of the wizard, it fails with “LDAP server is unwilling to perform”. In the error log, I see one error. Any help is appreciated. Thanks, Mike Can you run the console with -D 9 -f console.log, reproduce the problem, remove any sensitive information from console.log, and post console.log to this list? [12/Mar/2012:13:26:46 -0400] NSMMReplicationPlugin - agmtlist_add_callback: Can't start agreement cn=389 to analog-01v,cn=replica,cn=dc\3dMY_DOMAIN\2c dc\3dcom,cn=mapping tree,cn=config -- 389 users mailing list 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] LDAP server is unwilling to perform
Sorry, forgot to send this to the list. From: Michael James Sent: Tuesday, March 13, 2012 12:13 PM To: 'Rich Megginson' Subject: RE: [389-users] LDAP server is unwilling to perform That’s a big *IF* there… I did turn up the logging. Attached is the error log, trimmed to around the time that I tried to create the new replication agreement. Sorry about that. From: Rich Megginson [mailto:rmegg...@redhat.com]mailto:[mailto:rmegg...@redhat.com] Sent: Tuesday, March 13, 2012 11:51 AM To: General discussion list for the 389 Directory server project. Cc: Michael James Subject: Re: [389-users] LDAP server is unwilling to perform On 03/13/2012 09:41 AM, mja...@guesswho.commailto:mja...@guesswho.com wrote: Pls see attached new console.log. Thanks. If you follow the directions at http://port389.org/wiki/FAQ#Troubleshooting to enable the Replication log level, the extra information will be in the directory server errors log, not the console log - /var/log/dirsrv/slapd-INST/errors Mike From: Rich Megginson [mailto:rmegg...@redhat.com] Sent: Monday, March 12, 2012 3:14 PM To: General discussion list for the 389 Directory server project. Cc: Michael James Subject: Re: [389-users] LDAP server is unwilling to perform On 03/12/2012 12:39 PM, mja...@guesswho.commailto:mja...@guesswho.com wrote: Pls. see attached. Thx. Hmm - nothing to go on there - please turn on the Replication log level and reproduce the problem - then the errors log may contain more clues http://port389.org/wiki/FAQ#Troubleshooting Mike From: Rich Megginson [mailto:rmegg...@redhat.com] Sent: Monday, March 12, 2012 1:30 PM To: General discussion list for the 389 Directory server project. Cc: Michael James Subject: Re: [389-users] LDAP server is unwilling to perform On 03/12/2012 11:30 AM, mja...@guesswho.commailto:mja...@guesswho.com wrote: Thanks for your previous help. I built a new server, CentOS 6.2, added the epel-389-ds-base and epel repos, then installed 389-ds via yum. I ran setup-ds-admin.pl with the “Typical” setup option, user nobody, and registered with one of our existing configuration servers. I created the supplier bind DN on the new server per the installation docs. At this point, I can’t establish a replication agreement. I open the 389-console on existing server and use the GUI to create a new replication agreement on userRoot. I accepted the defaults, entered the correct bind DN and password. At the end of the wizard, it fails with “LDAP server is unwilling to perform”. In the error log, I see one error. Any help is appreciated. Thanks, Mike Can you run the console with -D 9 -f console.log, reproduce the problem, remove any sensitive information from console.log, and post console.log to this list? [12/Mar/2012:13:26:46 -0400] NSMMReplicationPlugin - agmtlist_add_callback: Can't start agreement cn=389 to analog-01v,cn=replica,cn=dc\3dMY_DOMAIN\2c dc\3dcom,cn=mapping tree,cn=config -- 389 users mailing list 389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users 389-Directory/1.2.2 B2009.237.2042 x-web-389-01.MYDOMAIN.com:389 (/etc/dirsrv/slapd-x-web-389-01) [13/Mar/2012:11:25:25 -0400] - slapd shutting down - signaling operation threads [13/Mar/2012:11:25:25 -0400] - slapd shutting down - waiting for 27 threads to terminate [13/Mar/2012:11:25:25 -0400] - slapd shutting down - closing down internal subsystems and plugins [13/Mar/2012:11:25:25 -0400] NSMMReplicationPlugin - changelog program - _cl5TrimMain: exiting [13/Mar/2012:11:25:25 -0400] NSMMReplicationPlugin - changelog program - _cl5DBClose: deleting DB object 98ec028 [13/Mar/2012:11:25:25 -0400] NSMMReplicationPlugin - changelog program - _cl5DBClose: closing databases in /etc/dirsrv/replication/changelogdb [13/Mar/2012:11:25:25 -0400] NSMMReplicationPlugin - changelog program - _cl5DBCloseFile: Closing database /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e345_4e49489b0001.db4 [13/Mar/2012:11:25:25 -0400] NSMMReplicationPlugin - changelog program - _cl5DBCloseFile: Closed the changelog database handle for /etc/dirsrv/replication/changelogdb/3f5b1504-1dd211b2-8eccc06e-e345_4e49489b0001.db4 (rc: 0) [13/Mar/2012:11:25:25 -0400] - Waiting for 4 database threads to stop [13/Mar/2012:11:25:25 -0400] - All database threads now stopped [13/Mar/2012:11:25:25 -0400] - replica_destroy [13/Mar/2012:11:25:25 -0400] - slapd stopped. [13/Mar/2012:11:26:25 -0400] - 389-Directory/1.2.9.9 B2011.244.2040 starting up [13/Mar/2012:11:26:25 -0400] NSMMReplicationPlugin - changelog program - _cl5AppInit: fetched backend dbEnv (926d0b8) [13/Mar/2012:11:26:25 -0400] NSMMReplicationPlugin - changelog program - _cl5NewDBFile: semaphore
Re: [389-users] LDAP server is unwilling to perform
On 03/13/2012 10:23 AM, mja...@guesswho.com wrote: Sorry, forgot to send this to the list. There appears to be something wrong with your replication agreement entry, but I have no idea what. That information should be in the logs but it is not. Can you post your replication agreement entry to the list? ldapsearch -xLLL -D cn=directory manager -W -b cn=config cn=389 to analog *From:*Michael James *Sent:* Tuesday, March 13, 2012 12:13 PM *To:* 'Rich Megginson' *Subject:* RE: [389-users] LDAP server is unwilling to perform That’s a big **IF** there… I did turn up the logging. Attached is the error log, trimmed to around the time that I tried to create the new replication agreement. Sorry about that. *From:*Rich Megginson [mailto:rmegg...@redhat.com] mailto:[mailto:rmegg...@redhat.com] *Sent:* Tuesday, March 13, 2012 11:51 AM *To:* General discussion list for the 389 Directory server project. *Cc:* Michael James *Subject:* Re: [389-users] LDAP server is unwilling to perform On 03/13/2012 09:41 AM, mja...@guesswho.com mailto:mja...@guesswho.com wrote: Pls see attached new console.log. Thanks. If you follow the directions at http://port389.org/wiki/FAQ#Troubleshooting to enable the Replication log level, the extra information will be in the directory server errors log, not the console log - /var/log/dirsrv/slapd-INST/errors Mike *From:*Rich Megginson [mailto:rmegg...@redhat.com] *Sent:* Monday, March 12, 2012 3:14 PM *To:* General discussion list for the 389 Directory server project. *Cc:* Michael James *Subject:* Re: [389-users] LDAP server is unwilling to perform On 03/12/2012 12:39 PM, mja...@guesswho.com mailto:mja...@guesswho.com wrote: Pls. see attached. Thx. Hmm - nothing to go on there - please turn on the Replication log level and reproduce the problem - then the errors log may contain more clues http://port389.org/wiki/FAQ#Troubleshooting Mike *From:*Rich Megginson [mailto:rmegg...@redhat.com] *Sent:* Monday, March 12, 2012 1:30 PM *To:* General discussion list for the 389 Directory server project. *Cc:* Michael James *Subject:* Re: [389-users] LDAP server is unwilling to perform On 03/12/2012 11:30 AM, mja...@guesswho.com mailto:mja...@guesswho.com wrote: Thanks for your previous help. I built a new server, CentOS 6.2, added the epel-389-ds-base and epel repos, then installed 389-ds via yum. I ran setup-ds-admin.pl with the “Typical” setup option, user nobody, and registered with one of our existing configuration servers. I created the supplier bind DN on the new server per the installation docs. At this point, I can’t establish a replication agreement. I open the 389-console on existing server and use the GUI to create a new replication agreement on userRoot. I accepted the defaults, entered the correct bind DN and password. At the end of the wizard, it fails with “LDAP server is unwilling to perform”. In the error log, I see one error. Any help is appreciated. Thanks, Mike Can you run the console with -D 9 -f console.log, reproduce the problem, remove any sensitive information from console.log, and post console.log to this list? [12/Mar/2012:13:26:46 -0400] NSMMReplicationPlugin - agmtlist_add_callback: Can't start agreement cn=389 to analog-01v,cn=replica,cn=dc\3dMY_DOMAIN\2c dc\3dcom,cn=mapping tree,cn=config -- 389 users mailing list 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] LDAP server is unwilling to perform
Looks like this:
[root@x-web-389-01 ~]# ldapsearch -xLLL -D cn=directory manager -W -b
cn=config cn=389 to analog
Enter LDAP Password:
dn: cn=389 to analog,cn=replica,cn=dc\3DMYDOMAIN\2C dc\3Dcom,cn=mapping
tree,cn=config
objectClass: top
objectClass: nsDS5ReplicationAgreement
description: x-web-389-01 to x-analog-01
cn: 389 to analog
nsDS5ReplicaRoot: dc=MYDOMAIN,dc=com
nsDS5ReplicaHost: x-analog-01.MYDOMAIN.com
nsDS5ReplicaPort: 389
nsDS5ReplicaBindDN: cn=repman,cn=config
nsDS5ReplicaTransportInfo: LDAP
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaCredentials: {DES}/DnkVyIX/let6epFs+gfjw==
nsds50ruv: {replicageneration} 4eb7e52b0001
nsds50ruv: {replica 2 ldap://x-analog-01.MYDOMAIN.com:389} 4ec1600f0002
4ec29e530002
nsds50ruv: {replica 1 ldap://x-web-389-01.MYDOMAIN.com:389}
4ec116e40001 4f329c1c00010001
nsruvReplicaLastModified: {replica 2 ldap://x-analog-01.MYDOMAIN.com:389}
nsruvReplicaLastModified: {replica 1 ldap://x-web-389-01.MYDOMAIN.com:389}
nsds5replicareapactive: 0
nsds5replicaLastUpdateStart: 0
nsds5replicaLastUpdateEnd: 0
nsds5replicaChangesSentSinceStartup:
nsds5replicaLastUpdateStatus: 0 No replication sessions started since server
startup
nsds5replicaUpdateInProgress: FALSE
nsds5replicaLastInitStart: 0
nsds5replicaLastInitEnd: 0
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Tuesday, March 13, 2012 12:24 PM
To: General discussion list for the 389 Directory server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling to perform
On 03/13/2012 10:23 AM, mja...@guesswho.commailto:mja...@guesswho.com wrote:
Sorry, forgot to send this to the list.
There appears to be something wrong with your replication agreement entry, but
I have no idea what. That information should be in the logs but it is not.
Can you post your replication agreement entry to the list?
ldapsearch -xLLL -D cn=directory manager -W -b cn=config cn=389 to analog
From: Michael James
Sent: Tuesday, March 13, 2012 12:13 PM
To: 'Rich Megginson'
Subject: RE: [389-users] LDAP server is unwilling to perform
That’s a big *IF* there… I did turn up the logging. Attached is the error log,
trimmed to around the time that I tried to create the new replication
agreement. Sorry about that.
From: Rich Megginson
[mailto:rmegg...@redhat.com]mailto:[mailto:rmegg...@redhat.com]
Sent: Tuesday, March 13, 2012 11:51 AM
To: General discussion list for the 389 Directory server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling to perform
On 03/13/2012 09:41 AM, mja...@guesswho.commailto:mja...@guesswho.com wrote:
Pls see attached new console.log. Thanks.
If you follow the directions at http://port389.org/wiki/FAQ#Troubleshooting to
enable the Replication log level, the extra information will be in the
directory server errors log, not the console log -
/var/log/dirsrv/slapd-INST/errors
Mike
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Monday, March 12, 2012 3:14 PM
To: General discussion list for the 389 Directory server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling to perform
On 03/12/2012 12:39 PM, mja...@guesswho.commailto:mja...@guesswho.com wrote:
Pls. see attached. Thx.
Hmm - nothing to go on there - please turn on the Replication log level and
reproduce the problem - then the errors log may contain more clues
http://port389.org/wiki/FAQ#Troubleshooting
Mike
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Monday, March 12, 2012 1:30 PM
To: General discussion list for the 389 Directory server project.
Cc: Michael James
Subject: Re: [389-users] LDAP server is unwilling to perform
On 03/12/2012 11:30 AM, mja...@guesswho.commailto:mja...@guesswho.com wrote:
Thanks for your previous help. I built a new server, CentOS 6.2, added the
epel-389-ds-base and epel repos, then installed 389-ds via yum. I ran
setup-ds-admin.pl with the “Typical” setup option, user nobody, and registered
with one of our existing configuration servers. I created the supplier bind DN
on the new server per the installation docs.
At this point, I can’t establish a replication agreement. I open the
389-console on existing server and use the GUI to create a new replication
agreement on userRoot. I accepted the defaults, entered the correct bind DN and
password. At the end of the wizard, it fails with “LDAP server is unwilling to
perform”. In the error log, I see one error. Any help is appreciated. Thanks,
Mike
Can you run the console with -D 9 -f console.log, reproduce the problem, remove
any sensitive information from console.log, and post console.log to this list?
[12/Mar/2012:13:26:46 -0400] NSMMReplicationPlugin - agmtlist_add_callback:
Can't start agreement cn=389 to analog-01v,cn=replica,cn=dc\3dMY_DOMAIN\2c
dc\3dcom,cn=mapping tree,cn=config
--
389 users mailing list
389-users@lists.fedoraproject.orgmailto:389-users@lists.fedoraproject.org
[389-users] Announcing 389 Directory Server version 1.2.10.4 Testing
The 389 Project team is pleased to announce the release of 389-ds-base-1.2.10.4. This release contains a fix for a bug that causes the directory server to hang when using compare operations with virtual attributes. No new features were added after alpha 8, just many bug fixes. There are also 389-adminutil, 389-admin, and 389-dsgw packages in Testing. NEW: EL6 support Beginning with RHEL 6.2, the 389-ds-base package is included in the base OS. Therefore, the 389-ds-base package can no longer be provided via EPEL, due to RHEL/EPEL packaging restrictions. However, the 389 Project will still make the full 389-ds-base package available via http://repos.fedorapeople.org/repos/rmeggins/389-ds-base. See http://directory.fedoraproject.org/wiki/Download for more information. NEW: Issue Tracking System We have moved our ticket tracking system from the Red Hat Bugzilla https://bugzilla.redhat.com/enter_bug.cgi?product=389 to our Fedora Hosted Trac https://fedorahosted.org/389. All of the old 389 bugs have been copied to Trac. All new bugs, feature requests, and tasks should be entered in Trac This link shows all of the issues fixed in the 1.2.10 branch - https://fedorahosted.org/389/report/12 In addition to the tickets for Milestone 1.2.10.3 there were a couple of issues found by valgrind that have been fixed. NEW: Plugin Authors WARNING: Plugins should be made transaction aware so that they can be called from within a backend pre/post transaction plugin. Otherwise, attempting to perform an internal operation will cause a deadlock. See http://directory.fedoraproject.org/wiki/Plugins Installation yum install --enablerepo=updates-testing 389-ds # or for EPEL yum install --enablerepo=epel-testing [--enablerepo=epel-testing-389-ds-base] 389-ds setup-ds-admin.pl Upgrade yum upgrade --enablerepo=updates-testing 389-ds-base idm-console-framework 389-admin 389-ds-console 389-admin-console 389-dsgw 389-adminutil # or for EPEL yum upgrade --enablerepo=epel-testing [--enablerepo=epel-testing-389-ds-base] 389-ds-base idm-console-framework 389-admin 389-ds-console 389-admin-console 389-dsgw 389-adminutil setup-ds-admin.pl -u How to Give Feedback The best way to provide feedback is via the Fedora Update system. * Go to https://admin.fedoraproject.org/updates * In the Search box in the upper right hand corner, type in the name of the package * In the list, find the version and release you are using (if you're not sure, use rpm -qi package name on your system) and click on the release * On the page for the update, scroll down to Add a comment and provide your input Or just send us an email to 389-users@lists.fedoraproject.org Reporting Issues https://fedorahosted.org/389 More Information * Release Notes - http://port389.org/wiki/Release_Notes * Install_Guide - http://port389.org/wiki/Install_Guide * Download - http://port389.org/wiki/Download -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] bypassing limits for persistent search and specific user
Hello list, I'm looking for way how to bypass nsslapd-sizelimit and nsslapd-timelimit for persistent search made by specific user (or anything made by that user). Please, can you point me to right place in documentation about persistent search/user specific settings in 389? I googled for a while, but I can't find exact way how to accomplish this. I found attributes nsSizeLimit and nsTimeLimit in http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html-single/Schema_Reference/index.html#nsPagedSizeLimit , but I'm not sure how to deploy them. If bypassing is not possible in 389: Is there any way how to enumerate all records from given subtree part-by-part? (My guess: VLV or something similar.) I know only basics about persistent search and next to nothing about VLV, so sorry if I'm completely wrong. --- Background / why I needed this / long story --- FreeIPA project has LDAP plugin for BIND. This plugin pulls DNS records from LDAP database and populates BIND's internal memory with them. (Homepage: https://fedorahosted.org/bind-dyndb-ldap/) This plugin can use persistent search, which enables reflecting changes in LDAP inside BIND immediately. At this moment, plugin after start do persistent search for all DNS records. This single query can lead to tens of thousands records - and of course fails, because nssldapd-sizelimit stops that. Another problem arises with databases smaller than sizelimit - query is ended after timelimit and has to be re-established. It leads to periodical re-downloading whole DNS DB. Question is: It's possible to bypass limits for this connection/user OR plugin is completely broken by design? Thanks for you time. Petr^2 Spacek @ Red Hat @ Brno office -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] bypassing limits for persistent search and specific user
On 03/13/2012 05:09 PM, Petr Spacek wrote: Hello list, I'm looking for way how to bypass nsslapd-sizelimit and nsslapd-timelimit for persistent search made by specific user (or anything made by that user). Please, can you point me to right place in documentation about persistent search/user specific settings in 389? I googled for a while, but I can't find exact way how to accomplish this. I found attributes nsSizeLimit and nsTimeLimit in http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html-single/Schema_Reference/index.html#nsPagedSizeLimit , but I'm not sure how to deploy them. If bypassing is not possible in 389: Is there any way how to enumerate all records from given subtree part-by-part? (My guess: VLV or something similar.) I know only basics about persistent search and next to nothing about VLV, so sorry if I'm completely wrong. --- Background / why I needed this / long story --- FreeIPA project has LDAP plugin for BIND. This plugin pulls DNS records from LDAP database and populates BIND's internal memory with them. (Homepage: https://fedorahosted.org/bind-dyndb-ldap/) This plugin can use persistent search, which enables reflecting changes in LDAP inside BIND immediately. At this moment, plugin after start do persistent search for all DNS records. This single query can lead to tens of thousands records - and of course fails, because nssldapd-sizelimit stops that. Another problem arises with databases smaller than sizelimit - query is ended after timelimit and has to be re-established. It leads to periodical re-downloading whole DNS DB. Question is: It's possible to bypass limits for this connection/user OR plugin is completely broken by design? Not specifically for persistent search - see http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/User_Account_Management-Setting_Resource_Limits_Based_on_the_Bind_DN.html Thanks for you time. Petr^2 Spacek @ Red Hat @ Brno office -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] bypassing limits for persistent search and specific user
On 03/13/2012 04:09 PM, Petr Spacek wrote: Hello list, I'm looking for way how to bypass nsslapd-sizelimit and nsslapd-timelimit for persistent search made by specific user (or anything made by that user). Please, can you point me to right place in documentation about persistent search/user specific settings in 389? I googled for a while, but I can't find exact way how to accomplish this. You can set user-based limits as shown here: http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/User_Account_Management-Setting_Resource_Limits_Based_on_the_Bind_DN.html#Setting_Resource_Limits_Based_on_the_Bind_DN-Setting_Resource_Limits_Using_the_Command_Line I found attributes nsSizeLimit and nsTimeLimit in http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html-single/Schema_Reference/index.html#nsPagedSizeLimit , but I'm not sure how to deploy them. If bypassing is not possible in 389: Is there any way how to enumerate all records from given subtree part-by-part? (My guess: VLV or something similar.) There is VLV, and there is also simple-paged results. Both are methods that can be used to enumerate through search results in chunks. VLV requires explicit configuration of a VLV index for the exact search that you want to perform ahead of time. Simple-paged results can be used with any search. Here are some details on using simple-paged results: http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/using-simple-paged-results.html I know only basics about persistent search and next to nothing about VLV, so sorry if I'm completely wrong. --- Background / why I needed this / long story --- FreeIPA project has LDAP plugin for BIND. This plugin pulls DNS records from LDAP database and populates BIND's internal memory with them. (Homepage: https://fedorahosted.org/bind-dyndb-ldap/) This plugin can use persistent search, which enables reflecting changes in LDAP inside BIND immediately. At this moment, plugin after start do persistent search for all DNS records. This single query can lead to tens of thousands records - and of course fails, because nssldapd-sizelimit stops that. Another problem arises with databases smaller than sizelimit - query is ended after timelimit and has to be re-established. It leads to periodical re-downloading whole DNS DB. Question is: It's possible to bypass limits for this connection/user I think setting the limits based on your bind DN should work. -NGK OR plugin is completely broken by design? Thanks for you time. Petr^2 Spacek @ Red Hat @ Brno office -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] bypassing limits for persistent search and specific user
On 03/14/2012 12:16 AM, Nathan Kinder wrote: On 03/13/2012 04:09 PM, Petr Spacek wrote: Hello list, I'm looking for way how to bypass nsslapd-sizelimit and nsslapd-timelimit for persistent search made by specific user (or anything made by that user). Please, can you point me to right place in documentation about persistent search/user specific settings in 389? I googled for a while, but I can't find exact way how to accomplish this. You can set user-based limits as shown here: http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/User_Account_Management-Setting_Resource_Limits_Based_on_the_Bind_DN.html#Setting_Resource_Limits_Based_on_the_Bind_DN-Setting_Resource_Limits_Using_the_Command_Line I found attributes nsSizeLimit and nsTimeLimit in http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html-single/Schema_Reference/index.html#nsPagedSizeLimit , but I'm not sure how to deploy them. If bypassing is not possible in 389: Is there any way how to enumerate all records from given subtree part-by-part? (My guess: VLV or something similar.) There is VLV, and there is also simple-paged results. Both are methods that can be used to enumerate through search results in chunks. VLV requires explicit configuration of a VLV index for the exact search that you want to perform ahead of time. Simple-paged results can be used with any search. Here are some details on using simple-paged results: http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/using-simple-paged-results.html I know only basics about persistent search and next to nothing about VLV, so sorry if I'm completely wrong. --- Background / why I needed this / long story --- FreeIPA project has LDAP plugin for BIND. This plugin pulls DNS records from LDAP database and populates BIND's internal memory with them. (Homepage: https://fedorahosted.org/bind-dyndb-ldap/) This plugin can use persistent search, which enables reflecting changes in LDAP inside BIND immediately. At this moment, plugin after start do persistent search for all DNS records. This single query can lead to tens of thousands records - and of course fails, because nssldapd-sizelimit stops that. Another problem arises with databases smaller than sizelimit - query is ended after timelimit and has to be re-established. It leads to periodical re-downloading whole DNS DB. Question is: It's possible to bypass limits for this connection/user I think setting the limits based on your bind DN should work. -NGK OR plugin is completely broken by design? Thanks for you time. Petr^2 Spacek @ Red Hat @ Brno office Absolutely perfect! Thanks a lot for immediate response. Petr^2 Spacek -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] Req PPA link for Ubuntu
Hi Team, We are trying to install 389 ds server in Ubuntu 10.04 x86-64 edition. we followed the doc from the site https://help.ubuntu.com/community/FedoraDirectoryServer; . In that site, they have specified the following url, deb http://ppa.launchpad.net/ubuntu-389-directory-server/ppa/ubuntu/ karmic maindeb-src http://ppa.launchpad.net/ubuntu-389-directory-server/ppa/ubuntu/ karmic main. Once if added the above Url in the Sources list, we can easily install 389 ds entire server in the Ubuntu server edition.but now a days this link may be down and there is no alternative links. i have searched in google but, no luck.Please let me know alternative link for the URL's or is there any other way we can install complete 389 ds server,fedors-idm-console,etc. Please help me on this Regards, Varad -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
