Re: [389-users] ldap authenticaion is not getting correct information (SSL/TLS) (all files, logs included- please give me light on this)
-D 'cn=Directory Manager' It looks like your ldapsearch is using Directory Manager (the 389 equivalent to the root user). However I do not see where you have specified a bind DN in an ldap.conf file so possibly PAM is binding anonymously and an ACL is prohibiting the search? If this is a testing system you could specify Directory Manager as your bind DN for PAM just to test this assumption. Of course for production you'd want some non-DM DN to bind with. On Sun, Dec 29, 2013 at 02:54:13PM +, fosiul alam wrote: Hi, I need some help urgnelty.. as no idea why its acting funy. as far I belive, I have setup ldap server properly in test environment, but actiting wired.. no idea why ... example [root@test ~]# id tuser id: tuser: No such user bellow command shows the correct info : [root@test ~]# /usr/bin/ldapsearch -xZZ -D 'cn=Directory Manager' -w 'x' -b 'dc=fosiul,dc=lan' # extended LDIF # # LDAPv3 # base dc=fosiul,dc=lan with scope subtree # filter: (objectclass=*) # requesting: ALL # # fosiul.lan dn: dc=fosiul,dc=lan dc: fosiul objectClass: domain objectClass: top # uk, fosiul.lan dn: l=uk,dc=fosiul,dc=lan l: uk objectClass: locality objectClass: top # groups, uk, fosiul.lan dn: ou=groups,l=uk,dc=fosiul,dc=lan ou: groups objectClass: organizationalUnit objectClass: top # users, uk, fosiul.lan dn: ou=users,l=uk,dc=fosiul,dc=lan ou: users objectClass: organizationalUnit objectClass: top # IT, groups, uk, fosiul.lan dn: cn=IT,ou=groups,l=uk,dc=fosiul,dc=lan gidNumber: 3001 objectClass: posixGroup objectClass: top uniqueMember: uid=fosiula,ou=users,l=uk,dc=fosiul,dc=lan cn: IT # tuser, users, uk, fosiul.lan dn: uid=tuser,ou=users,l=uk,dc=fosiul,dc=lan givenName: Tuser sn: User uidNumber: 2001 gidNumber: 3001 objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson objectClass: posixAccount cn: test User homeDirectory: /home/tuser userPassword:: e1NTSEF9cGlZclc1NjBaOXdtSGxkdVVKcGJ3TUhHZjN4eG55a2lUQUxhSVE9PQ= = uid: tuser # search result search: 3 result: 0 Success # numResponses: 7 # numEntries: 6 My : /etc/ldap.conf [root@test ~]# cat /etc/ldap.conf # @(#)$Id: ldap.conf,v 1.38 2006/05/15 08:13:31 lukeh Exp $ # # This config is managed by puppet, all changes will be reverted base dc=fosiul,dc=lan bind_policy soft # Search timelimit #timelimit 30 timelimit 1 # Bind/connect timelimit #bind_timelimit 30 bind_timelimit 1 #idle_timelimit 3600 idle_timelimit 1 bind_timeout 1 nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon uri ldap://puppet-1.fosiul.lan ssl start_tls tls_cacertfile /etc/openldap/cacerts/CRT.crt pam_password md5 pam_groupdn cn=IT,ou=groups,l=uk,dc=fosiul,dc=lan pam_member_attribute uniqueMember tls_cacertdir /etc/openldap/cacerts my /etc/openldap/ldap.conf : # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example, dc=com #URIldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never URI ldap://puppet-1.fosiul.lan/ BASE dc=fosiul,dc=lan TLS_CACERTDIR /etc/openldap/cacerts tls_cacertfile /etc/openldap/cacerts/CRT.crt The Log From ldap server for bellow command - [root@test ~]# id tuser id: tuser: No such user [root@test ~]# [29/Dec/2013:14:49:14 +] conn=111 op=3 UNBIND [29/Dec/2013:14:49:14 +] conn=111 op=3 fd=76 closed - U1 [29/Dec/2013:14:49:14 +] conn=115 fd=76 slot=76 connection from 192.168.0.40 to 192.168.0.35 [29/Dec/2013:14:49:14 +] conn=115 op=0 EXT oid=1.3.6.1.4.1.1466.20037 name=startTLS [29/Dec/2013:14:49:14 +] conn=115 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [29/Dec/2013:14:49:14 +] conn=115 SSL 256-bit AES [29/Dec/2013:14:49:14 +] conn=115 op=1 BIND dn= method=128 version=3 [29/Dec/2013:14:49:14 +] conn=115 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn= [29/Dec/2013:14:49:14 +] conn=115 op=2 SRCH base=dc=fosiul,dc=lan scope=2 filter=((objectClass=posixAccount)(uid=tuser)) attrs=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass [29/Dec/2013:14:49:14 +] conn=115 op=2 RESULT err=0 tag=101 nentries=0 etime=0 -- 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 authenticaion is not getting correct information (SSL/TLS) (all files, logs included- please give me light on this)
On Sun, Dec 29, 2013 at 05:33:09PM +, fosiul alam wrote: Hi Thanks for the quick Reply. I was thinking that same that some where its missing the Bind dn and I can conferm that, its working with definning binddn and bindpw in ldap.conf but , I confiered this before and I never had to define binddn and bindpw in any where in ldap.conf and as you said that for production its not appropriate. Sounds like your previous setup either permitted anonymous binds to search for this information (had the ACLs permitting this) or had people bind as themselves and permitted them (via ACLs) to search for their own entries. Unfortunately it has been a bit of a while since I set this up with 389 and I don't recall specifically how. But in your place I would see if I could get PAM/LDAP to bind with authenticating users' credentials for logins, and bind anonymously for generic stuff like group info. which mean, something i have missed while configuring direcotory server, I guess, I will have to tell Directory server to bind annonomouse search with cn=Directory Manager or something like this. but currnelty its not cliking on my head. Any further help will really appreciate. Kind Regards -- 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] how to generate the userpassword
Perhaps use slappasswd?
On Sun, Aug 05, 2012 at 01:58:33PM +0100, Fosiul Alam wrote:
Hi
I am generating the ldif by script.
but i cant understand how will i generate the userpassword.
userPassword: {crypt}x
how this crypt or hash working
Please give me some lights on this.
Regards
--
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] openldap client HA for multimaster replication
On Fri, Jul 06, 2012 at 06:27:31PM +, Ryan Palamara wrote: I am using a mix of CentOS 5 and 6 servers using openldap for client ldap. I have 2 289 Directory servers that are using multi-master replication. When dirsrv stops working on the first server listed under URI, authentication picks up seamlessly on the second LDAP server listed. However if the first server is down completely, it then takes a long time for authentication for go to the second server. Any suggestions on what can be done with openldap, to allow the seamless failover to the second server when the first one is down completely? Depending on how expensive this slow authentication is, you could do anything from a shared IP via haproxy to buy a BigIP pair from F5 and have your load balancer check that the backend ldap daemons are up. Then the frontend will stop using a non-functioning backend for ldap. Thank you, Ryan Palamara ZAIS Group, LLC 2 Bridge Avenue, Suite 322 Red Bank, New Jersey 07701 Phone: (732) 450-7444 [1]ryan.palam...@zaisgroup.com -- This e-mail message is intended only for the named recipient(s) above. It may contain confidential information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you. This is not an offer (or solicitation of an offer) to buy/sell the securities/instruments mentioned or an official confirmation. This is not research and is not from ZAIS Group but it may refer to a research analyst/research report. Unless indicated, these views are the author's and may differ from those of ZAIS Group research or others in the Firm. We do not represent this is accurate or complete and we may not update this. Past performance is not indicative of future returns. IRS CIRCULAR 230 NOTICE:. To comply with requirements imposed by the IRS, we inform you that any U.S. federal tax advice contained herein (including any attachments), unless specifically stated otherwise, is not intended or written to be used, and cannot be used, for the purpose of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing or recommending any transaction or matter addressed herein to another party. Each taxpayer should seek advice based on the taxpayer's particular circumstances from an independent tax advisor. ZAIS, ZAIS Group and ZAIS Solutions are trademarks of ZAIS Group, LLC. References Visible links 1. mailto:ryan.palam...@zaisgroup.com -- 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] Replica ID management
n Mon, Mar 26, 2012 at 01:15:18PM -0400, mja...@guesswho.com wrote: @Ryan, thanks! That’s an interesting solution. And I thought of another question. Do the replica IDs need to be unique across all databases? Whether or not there's a technological need, consider the advantage of having a single replica ID associated with a single database on a single host when you're reading your error logs. From: 389-users-boun...@lists.fedoraproject.org [mailto:389-users-boun...@lists.fedoraproject.org] On Behalf Of Groten, Ryan Sent: Monday, March 26, 2012 1:08 PM To: 389-us...@lists.fedoraproject.org Subject: Re: [389-users] Replica ID management I used the last set of digits from each servers ip address. That ensures uniqueness in my environment only because all my DS’s are in the same subnet. From: [1]389-users-boun...@lists.fedoraproject.org [2][mailto:389-users-boun...@lists.fedoraproject.org] On Behalf Of [3]mja...@guesswho.com Sent: Monday, March 26, 2012 10:53 AM To: [4]389-us...@lists.fedoraproject.org Subject: [389-users] Replica ID management Happy Monday, group. This seems like it should be obvious. When I set up a new replication using the console, I’m prompted to enter a unique replica ID. How can I tell if the ID I choose is unique? Is there a best practice for replica ID management? Thanks, Mike -- This communication, including any attached documentation, is intended only for the person or entity to which it is addressed, and may contain confidential, personal and/or privileged information. Any unauthorized disclosure, copying, or taking action on the contents is strictly prohibited. If you have received this message in error, please contact us immediately so we may correct our records. Please then delete or destroy the original transmission and any subsequent reply. References Visible links 1. mailto:389-users-boun...@lists.fedoraproject.org 2. mailto:[mailto:389-users-boun...@lists.fedoraproject.org] 3. mailto:mja...@guesswho.com 4. mailto:389-us...@lists.fedoraproject.org -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Importing Thunderbird AddressBook into LDAP
On 23/05/11 02:06 AM, Carsten Grzemba wrote: I guess the standard schema of 389Ds do not know objectclass mozillaAbPersonAlpha and the attribute mozillanickname My 389 install (rpm via epel) has those: [root@cwldap-01 ~]# grep mozillaAbPersonAlpha /etc/dirsrv/schema/60mozilla.ldif # mozillaAbPersonAlpha NAME 'mozillaAbPersonAlpha' [root@cwldap-01 ~]# grep mozillaNickname /etc/dirsrv/schema/60mozilla.ldif NAME ( 'mozillaNickname' 'xmozillanickname' ) MAY ( c $ description $ displayName $ facsimileTelephoneNumber $ givenName $ homePhone $ l $ mail $ mobile $ mozillaCustom1 $ mozillaCustom2 $ mozillaCustom3 $ mozillaCustom4 $ mozillaHomeCountryName $ mozillaHomeLocalityName $ mozillaHomePostalCode $ mozillaHomeState $ mozillaHomeStreet $ mozillaHomeStreet2 $ mozillaHomeUrl $ mozillaNickname $ mozillaSecondEmail $ mozillaUseHtmlMail $ mozillaWorkStreet2 $ mozillaWorkUrl $ nsAIMid $ o $ ou $ pager $ postalCode $ postOfficeBox $ sn $ st $ street $ telephoneNumber $ title ) You can extend your schema with the 389console or remove (rename) the mozilla oc and attr Regards Carsten - Ursprüngliche Nachricht - Von: Christopher Woodchristopher_w...@pobox.com Datum: Sonntag, 22. Mai 2011, 21:57 Betreff: Re: [389-users] Importing Thunderbird AddressBook into LDAP An: 389-us...@lists.fedoraproject.org My short trite answer is: http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting - What errors are you getting? - What version are you running? - When you ldapsearch on one of your pre-existing entries, does it look like what you posted below? On 22/05/11 03:10 PM, Philip Rhoades wrote: People, I have installed the 389 DS on F14 x86_64 OK and can see a few people that I added with the 389 Console in both Thunderbird and Squirrelmail but now I want to do a bulk import of my TB addressbook into the 389 DB. I can export the TB AB to an ldif file but it fails to import using the 389 Import Databases fn - I presume I have to somehow massage the LDIF file to make it compatible? Here is a complete record: dn: cn=Tina XX,mail=txxx...@nyyy.com objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: mozillaAbPersonAlpha givenName: Tina sn: Franks cn: Tina XX mozillaNickname: tinaX mail: t...@nyyy.com modifytimestamp: 48a5a25d I guess one of the objectlasses should be People? Thanks, Phil. -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Importing Thunderbird AddressBook into LDAP
My short trite answer is: http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting * What errors are you getting? * What version are you running? * When you ldapsearch on one of your pre-existing entries, does it look like what you posted below? On 22/05/11 03:10 PM, Philip Rhoades wrote: People, I have installed the 389 DS on F14 x86_64 OK and can see a few people that I added with the 389 Console in both Thunderbird and Squirrelmail but now I want to do a bulk import of my TB addressbook into the 389 DB. I can export the TB AB to an ldif file but it fails to import using the 389 Import Databases fn - I presume I have to somehow massage the LDIF file to make it compatible? Here is a complete record: dn: cn=Tina XX,mail=txxx...@nyyy.com objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: mozillaAbPersonAlpha givenName: Tina sn: Franks cn: Tina XX mozillaNickname: tinaX mail: t...@nyyy.com modifytimestamp: 48a5a25d I guess one of the objectlasses should be People? Thanks, Phil. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Manage Certificates button item (slightly different)
On Thu, Feb 10, 2011 at 11:10:19AM -0500, Christopher Wood wrote: On Thu, Feb 10, 2011 at 09:01:52AM -0700, Rich Megginson wrote: On 02/10/2011 08:57 AM, Christopher Wood wrote: On Thu, Feb 10, 2011 at 08:42:45AM -0700, Rich Megginson wrote: On 02/10/2011 08:23 AM, Christopher Wood wrote: On Thu, Feb 10, 2011 at 08:11:09AM -0700, Rich Megginson wrote: On 02/10/2011 07:45 AM, Christopher Wood wrote: 11;rgb://On Wed, Feb 09, 2011 at 05:49:28PM -0700, Rich Megginson wrote: On 02/09/2011 07:59 AM, Christopher Wood wrote: On Tue, Feb 08, 2011 at 06:14:27PM -0700, Rich Megginson wrote: On 02/08/2011 04:11 PM, Christopher Wood wrote: These bugs are almost exactly the issue I'm experiencing: https://bugzilla.redhat.com/show_bug.cgi?id=430499 https://bugzilla.redhat.com/show_bug.cgi?id=442103 In my case, the admin server on host1 can use the Manage Certificates button on the admin server, and the directory server installed on the same host. So the bug is not happening to me. However, I get java.net.ConnectException: Connection refused when I use the Manage Certificates button on host2's directory server that I registered with host1's admin server. I don't get any output on the console when I repeat this procedure having run 389-console from the command line. I don't see anything immediately obvious under /var/log/dirsrv/*/errors on both servers. I can run ldapsearch against ldaps://host1 and ldaps://host2. Would you list denizens possibly have any hints as to how to troubleshoot this? 389-console -D 9 -f console.log - paste the log to fpaste.org or similar - be sure to remove or obscure any sensitive information - post the link here Thank you, I appreciate it. The full paste: http://fpaste.org/mgYb/ My procedure was to run 389-console with the above command line, click Manage Certificates in the directory server on the same host as the admin server (host1), then close that and click Manage Certificates in the directory server on the other host (host2). Just from reading along as I clicked buttons, it appears that the console is trying to itself talk to an admin server on host2. There is no admin server running on that host since I registered the directory server on host2 with the admin server on host1. Even if you use setup-ds-admin.pl to create a directory server and register it with another configuration directory server, there always has to be one admin server running on each machine. The admin server executes CGIs, such as the log viewer, server process management, etc. - tasks that must be done outside of the directory server process. ResourceSet: found in cache loader9690857:com.netscape.management.client.security.securityResource CommManager New CommRecord (http://host2.mycompany.com:3389/admin-serv/tasks/configuration/SecurityOp) java.net.ConnectException: Connection refused The admin server should always be running, unless you explicitly shut it down. In my case (host1 having admin/ds and host2 just having ds), I registered host2's directory server with host1's config directory server. However, host2's admin server failed to start. From /var/log/dirsrv/admin-serv/error when I try to start it manually: [root@host2 admin-serv]# cat /var/log/dirsrv/admin-serv/error [Wed Feb 09 13:01:29 2011] [crit] host_ip_init(): PSET failure: Failed to create PSET handle (pset error = ) Configuration Failed [Thu Feb 10 09:22:51 2011] [crit] host_ip_init(): PSET failure: Failed to create PSET handle (pset error = ) Configuration Failed Start the admin server like this: /usr/sbin/start-ds-admin -e debug then post the admin server error log http://fpaste.org/kIAu/ Can you paste your /etc/dirsrv/admin-serv/adm.conf and local.conf? adm.conf from host2: http://pastebin.com/HqL8c1hK ldapurl: ldaps://host1/o=NetscapeRoot host1 has to be the fqdn of host1 since you're using ldaps. In the original it is the fqdn. Did you install, into the cert db in /etc/dirsrv/admin-serv, the CA certificate of the CA that issued the server cert of host1? Aha. Before running the setup-ds-admin.pl script I did not manually install the CA certs into the dirsrv/admin-serv cert dbs on host2. That appears to be my skipped step. I will try this again with that step included. Oddly, that didn't help either (due to time constraints I've only gotten back to this now). Also, I get more debug output on the console than the log file, but neither is giving me a really good hint. [root@cwtmp-01 admin-serv]# tail /tmp/setupC5b4yV.log [11/03/11:16:00:43] - [Setup] Info Updating adm.conf . . . [11/03/11:16:00:43] - [Setup] Info Updating admpw . . . [11/03/11:16:00:43] - [Setup] Info Registering admin server with the configuration directory server . . . [11/03/11:16:00:43] - [Setup] Info Updating adm.conf with information from
Re: [389-users] advice on ssl cert rotation
You can use certutil to manually modify the cert stores. If you installed via rpm this will already be on your systems. Not at my work systems so I don't recall which package it's in. On Tue, Mar 01, 2011 at 07:27:53PM -0800, jon heise wrote: Recently i had ssl certs expire on my directory servers, currently i have one running without using an ssl cert, the secondary server is still set to use the old cert and as such it is not functioning.� On the primary server the admin server has been set to use a new self signed cert but we are locked out of that.� Is there a way to change what cert the ldap server will load without the use of the admin server ? -- 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] Manage Certificates button item (slightly different)
On Thu, Feb 10, 2011 at 08:42:45AM -0700, Rich Megginson wrote: On 02/10/2011 08:23 AM, Christopher Wood wrote: On Thu, Feb 10, 2011 at 08:11:09AM -0700, Rich Megginson wrote: On 02/10/2011 07:45 AM, Christopher Wood wrote: 11;rgb://On Wed, Feb 09, 2011 at 05:49:28PM -0700, Rich Megginson wrote: On 02/09/2011 07:59 AM, Christopher Wood wrote: On Tue, Feb 08, 2011 at 06:14:27PM -0700, Rich Megginson wrote: On 02/08/2011 04:11 PM, Christopher Wood wrote: These bugs are almost exactly the issue I'm experiencing: https://bugzilla.redhat.com/show_bug.cgi?id=430499 https://bugzilla.redhat.com/show_bug.cgi?id=442103 In my case, the admin server on host1 can use the Manage Certificates button on the admin server, and the directory server installed on the same host. So the bug is not happening to me. However, I get java.net.ConnectException: Connection refused when I use the Manage Certificates button on host2's directory server that I registered with host1's admin server. I don't get any output on the console when I repeat this procedure having run 389-console from the command line. I don't see anything immediately obvious under /var/log/dirsrv/*/errors on both servers. I can run ldapsearch against ldaps://host1 and ldaps://host2. Would you list denizens possibly have any hints as to how to troubleshoot this? 389-console -D 9 -f console.log - paste the log to fpaste.org or similar - be sure to remove or obscure any sensitive information - post the link here Thank you, I appreciate it. The full paste: http://fpaste.org/mgYb/ My procedure was to run 389-console with the above command line, click Manage Certificates in the directory server on the same host as the admin server (host1), then close that and click Manage Certificates in the directory server on the other host (host2). Just from reading along as I clicked buttons, it appears that the console is trying to itself talk to an admin server on host2. There is no admin server running on that host since I registered the directory server on host2 with the admin server on host1. Even if you use setup-ds-admin.pl to create a directory server and register it with another configuration directory server, there always has to be one admin server running on each machine. The admin server executes CGIs, such as the log viewer, server process management, etc. - tasks that must be done outside of the directory server process. ResourceSet: found in cache loader9690857:com.netscape.management.client.security.securityResource CommManagerNew CommRecord (http://host2.mycompany.com:3389/admin-serv/tasks/configuration/SecurityOp) java.net.ConnectException: Connection refused The admin server should always be running, unless you explicitly shut it down. In my case (host1 having admin/ds and host2 just having ds), I registered host2's directory server with host1's config directory server. However, host2's admin server failed to start. From /var/log/dirsrv/admin-serv/error when I try to start it manually: [root@host2 admin-serv]# cat /var/log/dirsrv/admin-serv/error [Wed Feb 09 13:01:29 2011] [crit] host_ip_init(): PSET failure: Failed to create PSET handle (pset error = ) Configuration Failed [Thu Feb 10 09:22:51 2011] [crit] host_ip_init(): PSET failure: Failed to create PSET handle (pset error = ) Configuration Failed Start the admin server like this: /usr/sbin/start-ds-admin -e debug then post the admin server error log http://fpaste.org/kIAu/ Can you paste your /etc/dirsrv/admin-serv/adm.conf and local.conf? adm.conf from host2: http://pastebin.com/HqL8c1hK local.conf from host2: http://pastebin.com/xGpYJyUs Also, I should say that I used host1's Configuration directory server admin domain when I was filling in configuration directory server details in host2's setup-ds-admin.pl. (It seemed sensible at the time.) From /tmp/setuphtlOC3.log on host2 (I chose a Typical (2) setup): [11/02/09:13:01:28] - [Setup] Info Starting admin server . . . [11/02/09:13:01:29] - [Setup] Fatal Failed to create and configure the admin server [11/02/09:13:01:29] - [Setup] Fatal Exiting . . . That happened every time when in the setup-ds-admin.pl stage on something other than host1 where I would pick ldaps://host1/o=NetscapeRoot as the configuration directory server url. Of course, for the setup on host1 I set everything up with basically defaults and added the encryption later. Not certain if that's pertinent, though. I'm starting to think that I've misread something in the install docs, will re-read. admserv version = null -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Manage Certificates button item (slightly different)
On Thu, Feb 10, 2011 at 09:01:52AM -0700, Rich Megginson wrote: On 02/10/2011 08:57 AM, Christopher Wood wrote: On Thu, Feb 10, 2011 at 08:42:45AM -0700, Rich Megginson wrote: On 02/10/2011 08:23 AM, Christopher Wood wrote: On Thu, Feb 10, 2011 at 08:11:09AM -0700, Rich Megginson wrote: On 02/10/2011 07:45 AM, Christopher Wood wrote: 11;rgb://On Wed, Feb 09, 2011 at 05:49:28PM -0700, Rich Megginson wrote: On 02/09/2011 07:59 AM, Christopher Wood wrote: On Tue, Feb 08, 2011 at 06:14:27PM -0700, Rich Megginson wrote: On 02/08/2011 04:11 PM, Christopher Wood wrote: These bugs are almost exactly the issue I'm experiencing: https://bugzilla.redhat.com/show_bug.cgi?id=430499 https://bugzilla.redhat.com/show_bug.cgi?id=442103 In my case, the admin server on host1 can use the Manage Certificates button on the admin server, and the directory server installed on the same host. So the bug is not happening to me. However, I get java.net.ConnectException: Connection refused when I use the Manage Certificates button on host2's directory server that I registered with host1's admin server. I don't get any output on the console when I repeat this procedure having run 389-console from the command line. I don't see anything immediately obvious under /var/log/dirsrv/*/errors on both servers. I can run ldapsearch against ldaps://host1 and ldaps://host2. Would you list denizens possibly have any hints as to how to troubleshoot this? 389-console -D 9 -f console.log - paste the log to fpaste.org or similar - be sure to remove or obscure any sensitive information - post the link here Thank you, I appreciate it. The full paste: http://fpaste.org/mgYb/ My procedure was to run 389-console with the above command line, click Manage Certificates in the directory server on the same host as the admin server (host1), then close that and click Manage Certificates in the directory server on the other host (host2). Just from reading along as I clicked buttons, it appears that the console is trying to itself talk to an admin server on host2. There is no admin server running on that host since I registered the directory server on host2 with the admin server on host1. Even if you use setup-ds-admin.pl to create a directory server and register it with another configuration directory server, there always has to be one admin server running on each machine. The admin server executes CGIs, such as the log viewer, server process management, etc. - tasks that must be done outside of the directory server process. ResourceSet: found in cache loader9690857:com.netscape.management.client.security.securityResource CommManager New CommRecord (http://host2.mycompany.com:3389/admin-serv/tasks/configuration/SecurityOp) java.net.ConnectException: Connection refused The admin server should always be running, unless you explicitly shut it down. In my case (host1 having admin/ds and host2 just having ds), I registered host2's directory server with host1's config directory server. However, host2's admin server failed to start. From /var/log/dirsrv/admin-serv/error when I try to start it manually: [root@host2 admin-serv]# cat /var/log/dirsrv/admin-serv/error [Wed Feb 09 13:01:29 2011] [crit] host_ip_init(): PSET failure: Failed to create PSET handle (pset error = ) Configuration Failed [Thu Feb 10 09:22:51 2011] [crit] host_ip_init(): PSET failure: Failed to create PSET handle (pset error = ) Configuration Failed Start the admin server like this: /usr/sbin/start-ds-admin -e debug then post the admin server error log http://fpaste.org/kIAu/ Can you paste your /etc/dirsrv/admin-serv/adm.conf and local.conf? adm.conf from host2: http://pastebin.com/HqL8c1hK ldapurl: ldaps://host1/o=NetscapeRoot host1 has to be the fqdn of host1 since you're using ldaps. In the original it is the fqdn. Did you install, into the cert db in /etc/dirsrv/admin-serv, the CA certificate of the CA that issued the server cert of host1? Aha. Before running the setup-ds-admin.pl script I did not manually install the CA certs into the dirsrv/admin-serv cert dbs on host2. That appears to be my skipped step. I will try this again with that step included. If the above are yes, paste excerpts from the access log of host1 showing the connection attempts from host2. local.conf from host2: http://pastebin.com/xGpYJyUs Also, I should say that I used host1's Configuration directory server admin domain when I was filling in configuration directory server details in host2's setup-ds-admin.pl. (It seemed sensible at the time.) From /tmp/setuphtlOC3.log on host2 (I chose a Typical (2) setup): [11/02/09:13:01:28] - [Setup] Info Starting admin server . . . [11/02/09:13:01:29] - [Setup] Fatal Failed to create and configure the admin server [11/02/09:13:01:29] - [Setup] Fatal Exiting . . . That happened every time when in the setup-ds-admin.pl stage
Re: [389-users] Manage Certificates button item (slightly different)
11;rgb://On Wed, Feb 09, 2011 at 05:49:28PM -0700, Rich Megginson wrote: On 02/09/2011 07:59 AM, Christopher Wood wrote: On Tue, Feb 08, 2011 at 06:14:27PM -0700, Rich Megginson wrote: On 02/08/2011 04:11 PM, Christopher Wood wrote: These bugs are almost exactly the issue I'm experiencing: https://bugzilla.redhat.com/show_bug.cgi?id=430499 https://bugzilla.redhat.com/show_bug.cgi?id=442103 In my case, the admin server on host1 can use the Manage Certificates button on the admin server, and the directory server installed on the same host. So the bug is not happening to me. However, I get java.net.ConnectException: Connection refused when I use the Manage Certificates button on host2's directory server that I registered with host1's admin server. I don't get any output on the console when I repeat this procedure having run 389-console from the command line. I don't see anything immediately obvious under /var/log/dirsrv/*/errors on both servers. I can run ldapsearch against ldaps://host1 and ldaps://host2. Would you list denizens possibly have any hints as to how to troubleshoot this? 389-console -D 9 -f console.log - paste the log to fpaste.org or similar - be sure to remove or obscure any sensitive information - post the link here Thank you, I appreciate it. The full paste: http://fpaste.org/mgYb/ My procedure was to run 389-console with the above command line, click Manage Certificates in the directory server on the same host as the admin server (host1), then close that and click Manage Certificates in the directory server on the other host (host2). Just from reading along as I clicked buttons, it appears that the console is trying to itself talk to an admin server on host2. There is no admin server running on that host since I registered the directory server on host2 with the admin server on host1. Even if you use setup-ds-admin.pl to create a directory server and register it with another configuration directory server, there always has to be one admin server running on each machine. The admin server executes CGIs, such as the log viewer, server process management, etc. - tasks that must be done outside of the directory server process. ResourceSet: found in cache loader9690857:com.netscape.management.client.security.securityResource CommManager New CommRecord (http://host2.mycompany.com:3389/admin-serv/tasks/configuration/SecurityOp) java.net.ConnectException: Connection refused The admin server should always be running, unless you explicitly shut it down. In my case (host1 having admin/ds and host2 just having ds), I registered host2's directory server with host1's config directory server. However, host2's admin server failed to start. From /var/log/dirsrv/admin-serv/error when I try to start it manually: [root@host2 admin-serv]# cat /var/log/dirsrv/admin-serv/error [Wed Feb 09 13:01:29 2011] [crit] host_ip_init(): PSET failure: Failed to create PSET handle (pset error = ) Configuration Failed [Thu Feb 10 09:22:51 2011] [crit] host_ip_init(): PSET failure: Failed to create PSET handle (pset error = ) Configuration Failed From /tmp/setuphtlOC3.log on host2 (I chose a Typical (2) setup): [11/02/09:13:01:28] - [Setup] Info Starting admin server . . . [11/02/09:13:01:29] - [Setup] Fatal Failed to create and configure the admin server [11/02/09:13:01:29] - [Setup] Fatal Exiting . . . That happened every time when in the setup-ds-admin.pl stage on something other than host1 where I would pick ldaps://host1/o=NetscapeRoot as the configuration directory server url. Of course, for the setup on host1 I set everything up with basically defaults and added the encryption later. Not certain if that's pertinent, though. I'm starting to think that I've misread something in the install docs, will re-read. admserv version = null -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] Manage Certificates button item (slightly different)
On Tue, Feb 08, 2011 at 06:14:27PM -0700, Rich Megginson wrote: On 02/08/2011 04:11 PM, Christopher Wood wrote: These bugs are almost exactly the issue I'm experiencing: https://bugzilla.redhat.com/show_bug.cgi?id=430499 https://bugzilla.redhat.com/show_bug.cgi?id=442103 In my case, the admin server on host1 can use the Manage Certificates button on the admin server, and the directory server installed on the same host. So the bug is not happening to me. However, I get java.net.ConnectException: Connection refused when I use the Manage Certificates button on host2's directory server that I registered with host1's admin server. I don't get any output on the console when I repeat this procedure having run 389-console from the command line. I don't see anything immediately obvious under /var/log/dirsrv/*/errors on both servers. I can run ldapsearch against ldaps://host1 and ldaps://host2. Would you list denizens possibly have any hints as to how to troubleshoot this? 389-console -D 9 -f console.log - paste the log to fpaste.org or similar - be sure to remove or obscure any sensitive information - post the link here Thank you, I appreciate it. The full paste: http://fpaste.org/mgYb/ My procedure was to run 389-console with the above command line, click Manage Certificates in the directory server on the same host as the admin server (host1), then close that and click Manage Certificates in the directory server on the other host (host2). Just from reading along as I clicked buttons, it appears that the console is trying to itself talk to an admin server on host2. There is no admin server running on that host since I registered the directory server on host2 with the admin server on host1. ResourceSet: found in cache loader9690857:com.netscape.management.client.security.securityResource CommManager New CommRecord (http://host2.mycompany.com:3389/admin-serv/tasks/configuration/SecurityOp) java.net.ConnectException: Connection refused admserv version = null -- 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] Manage Certificates button item (slightly different)
These bugs are almost exactly the issue I'm experiencing: https://bugzilla.redhat.com/show_bug.cgi?id=430499 https://bugzilla.redhat.com/show_bug.cgi?id=442103 In my case, the admin server on host1 can use the Manage Certificates button on the admin server, and the directory server installed on the same host. So the bug is not happening to me. However, I get java.net.ConnectException: Connection refused when I use the Manage Certificates button on host2's directory server that I registered with host1's admin server. I don't get any output on the console when I repeat this procedure having run 389-console from the command line. I don't see anything immediately obvious under /var/log/dirsrv/*/errors on both servers. I can run ldapsearch against ldaps://host1 and ldaps://host2. Would you list denizens possibly have any hints as to how to troubleshoot this? -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] schema for dns
Questions: When was the dNSDomain schema deprecated in 389 DS? Why was it deprecated in 389 DS? What schema do 389 Directory Server or Red Hat Directory Server users customarily use to store DNS zones in their directories? (Am I asking the right questions?) As well, my thanks to the list denizens for your collective threads, you're all terribly educational. Background: The task is exploring DNS schema storage in ldap, to be a DNS server backend. I can get the schema into 389 DS without any issues. I'm asking more for the why not the how. So far everything is working out, but I'm concerned that I may have a blind spot in choice of schema. Am I going one way while the world goes another as far as ldap backend is concerned? The PowerDNS LDAP Backend specifies the dNSDomain2 schema, a child of the dNSDomain schema. http://www.linuxnetworks.de/doc/index.php/PowerDNS_ldapbackend Here is previous discussion on this: http://lists.fedoraproject.org/pipermail/389-users/2010-March/011146.html In 2007 this was apparently added to the fedora-ds schema, if I'm reading it right: https://bugzilla.redhat.com/show_bug.cgi?id=179956 An earlier email which discusses the issue and why it may have appeared in 2005: http://lists.fedoraproject.org/pipermail/389-users/2005-July/000520.html -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] case sensitivity and matching rules
I'm puzzling over case-sensitivity, attributes, and matching rules in 389. I have an attribute (oid slightly munged for privacy): attributeTypes: ( 1.2.3.4 NAME 'ldapAuthLogin' DESC 'Account login name' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' ) It doesn't look like there's a matching rule associated with this. How does 389 decide which matching rules to apply here? (In this case, per ldapsearch, it seems to be a case-insensitive string match.) My apologies if this is obviously answered somewhere, I've pored over the docs and the mailing list archives and haven't found it yet. -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] stuck on a single entry
On Thu, Mar 25, 2010 at 11:59:31AM -0600, Rich Megginson wrote: Christopher Wood wrote: I'm having another issue that I'm not making headway on. This time, I can't import a single value into one attribute in my directory. The attribute in question is a DirectoryString . (Previously it was an IA5String and I had issues with many values, but I changed it to DirectoryString and now only this entry is giving me trouble.) Question: What troubleshooting steps can I use to identify the portion of the user-supplied string that is causing the value #0 invalid per syntax error? Here's the error I get from ldapmodify: modifying entry ldapAuthControlCode=1234567, ou=UsersByControlCode, o=mycompany ldap_modify: Invalid syntax (21) additional info: ldapAuthSieve: value #0 invalid per syntax Here's the schema for ldapAuthSieve from /opt/dirsrv/etc/dirsrv/slapd-cwlab-02/schema/99user.ldif: attributeTypes: ( 1.3.6.1.4.1.2805.1.1.1.1.36 NAME 'ldapAuthSieve' DESC 'The v acation message subject line' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VA LUE X-ORIGIN 'user defined' ) Points: The value I'm having trouble with is base64 encoded. The text inside the base64 encoding is bilingual English/French. It at least displays fine in my xterm. value #0 invalid per syntax with DirectoryString syntax values usually means the value is not a valid utf-8 encoded string. I can ldapmodify this attribute in this entry with other base64-encoded strings. Can you give an example of an LDIF that works with ldapmodify and one that fails with ldapmodify? I've narrowed it down to three characters (àôç), where if I include those in my base64 encoded string I get #0 invalid per syntax. If I use each individually as the only value in my base64-encoded string, I get the same error. By contrast, if I use [A-Za-z0-9] characters only (base64-encoded) in my value then the ldap value is modified without any difficulties. I haven't tested with every single other character, so there may be more that cause this error. I'm a bit confused as to why this happens. I thought the point of base64-encoding was that we could stuff arbitrary strings in? Or does the fact that they're not UTF8 affect the encoding? Is there a way to ensure that these values will be translated to an appropriate encoding in the initialization and replication process? I can ldapmodify this attribute in this entry with a much longer base64-encoded string, so I'm fairly sure I haven't hit a limit on the number of characters. I don't think it is a limit on the number of characters that is causing the problem. Error log output with debug level of 1 when I was running ldapmodify: [25/Mar/2010:13:23:04 -0400] - reslimit_update_from_entry(): setting limit for handle 1 (based on nsSizeLimit) [25/Mar/2010:13:23:04 -0400] - reslimit_update_from_entry(): setting limit for handle 2 (based on nsTimeLimit) [25/Mar/2010:13:23:04 -0400] - reslimit_update_from_entry(): setting limit for handle 3 (based on nsIdleTimeout) [25/Mar/2010:13:23:04 -0400] - = reslimit_update_from_entry() returning status 0 [25/Mar/2010:13:23:08 -0400] - ldbm backend flushing [25/Mar/2010:13:23:08 -0400] - ldbm backend done flushing [25/Mar/2010:13:23:08 -0400] - ldbm backend flushing [25/Mar/2010:13:23:08 -0400] - ldbm backend done flushing [25/Mar/2010:13:23:08 -0400] - ldbm backend flushing [25/Mar/2010:13:23:08 -0400] - ldbm backend done flushing [25/Mar/2010:13:23:35 -0400] - = ids_sasl_server_new (cwlab-02.pvt.primus.ca) [25/Mar/2010:13:23:35 -0400] - ids_sasl_getopt: plugin= option=log_level [25/Mar/2010:13:23:35 -0400] - ids_sasl_getopt: plugin= option=auto_transition [25/Mar/2010:13:23:35 -0400] - = ids_sasl_server_new [25/Mar/2010:13:23:35 -0400] - = slapi_reslimit_get_integer_limit() conn=0xb01e7248, handle=3 [25/Mar/2010:13:23:35 -0400] - = slapi_reslimit_get_integer_limit() returning NO VALUE [25/Mar/2010:13:23:35 -0400] - = slapi_reslimit_get_integer_limit() conn=0xb01e7188, handle=3 [25/Mar/2010:13:23:35 -0400] - = slapi_reslimit_get_integer_limit() returning NO VALUE [25/Mar/2010:13:23:35 -0400] - = slapi_reslimit_get_integer_limit() conn=0xb01e7008, handle=3 [25/Mar/2010:13:23:35 -0400] - = slapi_reslimit_get_integer_limit() returning NO VALUE [25/Mar/2010:13:23:35 -0400] - = slapi_reslimit_get_integer_limit() conn=0xb01e70c8, handle=3 [25/Mar/2010:13:23:35 -0400] - = slapi_reslimit_get_integer_limit() returning NO VALUE [25/Mar/2010:13:23:35 -0400] - add_pb [25/Mar/2010:13:23:35 -0400] - = slapi_reslimit_get_integer_limit() conn=0xb01e7188, handle=3 [25/Mar/2010:13:23:35 -0400] - = slapi_reslimit_get_integer_limit() returning NO VALUE [25/Mar/2010:13:23:35 -0400] - = slapi_reslimit_get_integer_limit() conn=0xb01e7008, handle=3 [25/Mar/2010:13:23:35 -0400
Re: [389-users] Netscape 6.2 389 Directory server replication
I'm doing much the same thing -- from an NDS 6.21 single master setup, ideally to a 389 dual master setup. I have the same situation with critical production servers and also plan to replicate my way through the upgrade. I ran into two big caveats: 1) schema I was not able to simply move my 99user.ldif (custom schema) file from NDS to 389. I ended up chopping up the migrate-ds.pl script and the DSMigration module to only migrate schema. I used the resulting 99user.ldif as a 98mycompany.ldif in 389. When I changed some schema in 389 all my custom schema landed in 99user.ldif and I was able to delete my 98mycompany.ldif. 2) syntax checking Many entries from NDS 6.2 failed to import into 389. (Per Rich, NDS 6.2 has no syntax checking.) My issues here were: a) incorrect schema for the data type In one instance whoever set up the NDS 6.2 directory had used the DN data type for something which was really just a string. When I corrected that six figures of ldif entries could move into 389. I had a few more similar things revolving around how some entries will import as a DirectoryString but not as IA5String. b) dirty data in NDS 6.2 389 won't accept blank entries, base64-encoded spaces ( ), and other incorrect syntax which NDS 6.2 accepted. I had to clean a bunch of those from my dump.ldif before they would cleanly import. I'm not sure how well I'll be able to replicate entries if the source has invalid syntax. I'm still trucking along with it here. So far 389 is very pleasant to deal with, in contrast with NDS. On Thu, Mar 25, 2010 at 12:05:04PM +, Nick Brown wrote: Hi, I have been given a bunch of old Netscape 6.2 servers that need replacing with 389 Directory server, is it possible to have a Netscape 6.2 master and a 389 Directory server replicating between each other? The current setup consists of 2 Netscape Multimasters and 7 slaves, I think the easiest solution would be to build 2 389 Masters with 389 slaves and have at least one of each Masters replicating between each other. Then to move the applications to the new platform the clients just need to change the IP they are talking to, then we always have the option of moving back if there are any problems. Does this sound like a sensible way to do it? The Netscape boxes are actually critical production boxes so we can afford very little downtime if any, and if we have the 2 setups replicating to each other the rollback plan is easy - otherwise we will need to somehow log all changes and manually apply those either way to keep everything in sync when we cutover and rollback. I'm rather new to LDAP so its a steep learning curve! Thanks in advance for any pointers. Nick. -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] importing large subtree crashes ns-slapd
On Mon, Mar 15, 2010 at 12:57:08PM -0600, Rich Megginson wrote: Christopher Wood wrote: On Thu, Mar 04, 2010 at 12:06:31PM -0700, Rich Megginson wrote: Christopher Wood wrote: On Wed, Mar 03, 2010 at 08:30:19PM -0700, Rich Megginson wrote: Christopher Wood wrote: I'm just getting started with 389 Directory Server (at work), and I've run into an issue that I'm not certain how to troubleshoot. I would greatly appreciate any assistance or tips you could offer, especially on where to look to see what's failing. Also, I apologize in advance for changing strings related to my employer's directory names and such, as I'm not comfortable with leaking that level information to a public list. As well you should be - you should always obscure sensitive information like this. Overview: Initializing a large subtree from NDS 6.2 crashes ns-slapd, but other subtrees are fine. Top-Level Questions: 1) How do I stop ns-slapd from crashing? Good question. 2) How do I figure out what precisely is causing the crash? (With various levels of debug logging I get the same log entry.) You've already used the TRACE level (1) for logging - that's as verbose as it gets for this particular operation. Next step would be to try to get a core file. 3) Is it possible to simply import my initialization ldif without duplication checks? No. Background: At work we have NDS 6.2 (single master on a physical server, virtual machine slaves), and would like to move our directories intact to a 389 2.6 installation via replication. What platform/OS? 32-bit or 64-bit? By NDS 6.2 I'm assuming you mean Netscape Directory Server - by 2.6 I'm assuming you mean 1.2.6.a1 (a2 should be hitting the mirrors tomorrow). 32 bit I already have replicated several of our NDS 6.2 subtrees to 389 2.6 with no difficulties. I compiled our 389 installation from the source packages downloaded from http://directory.fedoraproject.org/wiki/Source. Did you grab 389-ds-base 1.2.6.a1 or 1.2.6.a2? I used 1.2.6.a1 to compile originally and produce core files to answer your questions. Next I'll try this with 1.2.6.a2, but I'd rather keep the same version when trying to initially reproduce something. What compiler flags did you use? The makefile that came out of ./configure had these: CCASFLAGS = -g -O2 CFLAGS = -g -O2 CXXFLAGS = -g -O2 For the plain debug build I edited that to insert these and rebuilt with make, make install: CCASFLAGS = -g CFLAGS = -g CXXFLAGS = -g (Fair warning that I'm not a programmer, so I'm not entirely sure doing that was right.) Note that you don't have to edit the Makefile - you can do a make distclean, then run configure like this: CFLAGS=-g /path/to/configure ... make But that looks right, anyway. Note that if you change the flags like this by editing the makefile, you will have to do a make clean to remove the old object files, so that they will be rebuilt with the new flags. I did a make clean before rebuilding in this case. For my later debug builds I've used your step to re-run configure. Do you have a core file? If so, try using gdb gdb /path/to/ns-slapd /path/to/core.pid once in gdb, type the where command (gdb) where The original crash didn't produce a core file, but I could get one by attaching gdb later, to both the original build and a debug build. The underlying platform is: $ uname -a Linux cwlab-02.mycompany.com 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 i686 i386 GNU/Linux $ cat /etc/redhat-release CentOS release 5.4 (Final) $ free total used free sharedbuffers cached Mem: 389400013360122557988 0 144944 1004716 -/+ buffers/cache: 1863523707648 Swap: 2031608 02031608 Procedure To Crash 389's ns-slapd: a) In the NDS 6.2 admin console, create a new replication agreement for the o=This Big Net subtree, and choose to Create consumer initialization file. b) Copy the file to the 389 server. c) In the 389 2.6 admin console for the Directory Server, in the Configuration tab (Data - o=This Big Net - dbRoot), right-click and choose Initialize Database. Use the ldif file copied over. The ns-slapd process crashes, and I always get this in /opt/dirsrv/var/log/dirsrv/slapd-cwlab-02/errors as the last two lines: [03/Mar/2010:12:50:04 -0500] - import ldapAuthRoot
Re: [389-users] importing large subtree crashes ns-slapd
On Thu, Mar 04, 2010 at 12:06:31PM -0700, Rich Megginson wrote: Christopher Wood wrote: On Wed, Mar 03, 2010 at 08:30:19PM -0700, Rich Megginson wrote: Christopher Wood wrote: I'm just getting started with 389 Directory Server (at work), and I've run into an issue that I'm not certain how to troubleshoot. I would greatly appreciate any assistance or tips you could offer, especially on where to look to see what's failing. Also, I apologize in advance for changing strings related to my employer's directory names and such, as I'm not comfortable with leaking that level information to a public list. As well you should be - you should always obscure sensitive information like this. Overview: Initializing a large subtree from NDS 6.2 crashes ns-slapd, but other subtrees are fine. Top-Level Questions: 1) How do I stop ns-slapd from crashing? Good question. 2) How do I figure out what precisely is causing the crash? (With various levels of debug logging I get the same log entry.) You've already used the TRACE level (1) for logging - that's as verbose as it gets for this particular operation. Next step would be to try to get a core file. 3) Is it possible to simply import my initialization ldif without duplication checks? No. Background: At work we have NDS 6.2 (single master on a physical server, virtual machine slaves), and would like to move our directories intact to a 389 2.6 installation via replication. What platform/OS? 32-bit or 64-bit? By NDS 6.2 I'm assuming you mean Netscape Directory Server - by 2.6 I'm assuming you mean 1.2.6.a1 (a2 should be hitting the mirrors tomorrow). 32 bit I already have replicated several of our NDS 6.2 subtrees to 389 2.6 with no difficulties. I compiled our 389 installation from the source packages downloaded from http://directory.fedoraproject.org/wiki/Source. Did you grab 389-ds-base 1.2.6.a1 or 1.2.6.a2? I used 1.2.6.a1 to compile originally and produce core files to answer your questions. Next I'll try this with 1.2.6.a2, but I'd rather keep the same version when trying to initially reproduce something. What compiler flags did you use? The makefile that came out of ./configure had these: CCASFLAGS = -g -O2 CFLAGS = -g -O2 CXXFLAGS = -g -O2 For the plain debug build I edited that to insert these and rebuilt with make, make install: CCASFLAGS = -g CFLAGS = -g CXXFLAGS = -g (Fair warning that I'm not a programmer, so I'm not entirely sure doing that was right.) Note that you don't have to edit the Makefile - you can do a make distclean, then run configure like this: CFLAGS=-g /path/to/configure ... make But that looks right, anyway. Note that if you change the flags like this by editing the makefile, you will have to do a make clean to remove the old object files, so that they will be rebuilt with the new flags. I did a make clean before rebuilding in this case. For my later debug builds I've used your step to re-run configure. Do you have a core file? If so, try using gdb gdb /path/to/ns-slapd /path/to/core.pid once in gdb, type the where command (gdb) where The original crash didn't produce a core file, but I could get one by attaching gdb later, to both the original build and a debug build. The underlying platform is: $ uname -a Linux cwlab-02.mycompany.com 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 i686 i386 GNU/Linux $ cat /etc/redhat-release CentOS release 5.4 (Final) $ free total used free sharedbuffers cached Mem: 389400013360122557988 0 1449441004716 -/+ buffers/cache: 1863523707648 Swap: 2031608 02031608 Procedure To Crash 389's ns-slapd: a) In the NDS 6.2 admin console, create a new replication agreement for the o=This Big Net subtree, and choose to Create consumer initialization file. b) Copy the file to the 389 server. c) In the 389 2.6 admin console for the Directory Server, in the Configuration tab (Data - o=This Big Net - dbRoot), right-click and choose Initialize Database. Use the ldif file copied over. The ns-slapd process crashes, and I always get this in /opt/dirsrv/var/log/dirsrv/slapd-cwlab-02/errors as the last two lines: [03/Mar/2010:12:50:04 -0500] - import ldapAuthRoot: Processing file /home/cwood/tbn.ldif [03/Mar/2010:12:50:04 -0500] - = str2entry_dupcheck Other Details: I found two bugs with the str2entry_dupcheck string in it, but they don't seem pertinent: https://bugzilla.redhat.com/show_bug.cgi?id=548115 https://bugzilla.redhat.com/show_bug.cgi?id=243488 This says
Re: [389-users] importing large subtree crashes ns-slapd
On Mon, Mar 15, 2010 at 12:57:08PM -0600, Rich Megginson wrote: Christopher Wood wrote: On Thu, Mar 04, 2010 at 12:06:31PM -0700, Rich Megginson wrote: Christopher Wood wrote: On Wed, Mar 03, 2010 at 08:30:19PM -0700, Rich Megginson wrote: Christopher Wood wrote: I'm just getting started with 389 Directory Server (at work), and I've run into an issue that I'm not certain how to troubleshoot. I would greatly appreciate any assistance or tips you could offer, especially on where to look to see what's failing. Also, I apologize in advance for changing strings related to my employer's directory names and such, as I'm not comfortable with leaking that level information to a public list. As well you should be - you should always obscure sensitive information like this. Overview: Initializing a large subtree from NDS 6.2 crashes ns-slapd, but other subtrees are fine. Top-Level Questions: 1) How do I stop ns-slapd from crashing? Good question. 2) How do I figure out what precisely is causing the crash? (With various levels of debug logging I get the same log entry.) You've already used the TRACE level (1) for logging - that's as verbose as it gets for this particular operation. Next step would be to try to get a core file. 3) Is it possible to simply import my initialization ldif without duplication checks? No. Background: At work we have NDS 6.2 (single master on a physical server, virtual machine slaves), and would like to move our directories intact to a 389 2.6 installation via replication. What platform/OS? 32-bit or 64-bit? By NDS 6.2 I'm assuming you mean Netscape Directory Server - by 2.6 I'm assuming you mean 1.2.6.a1 (a2 should be hitting the mirrors tomorrow). 32 bit I already have replicated several of our NDS 6.2 subtrees to 389 2.6 with no difficulties. I compiled our 389 installation from the source packages downloaded from http://directory.fedoraproject.org/wiki/Source. Did you grab 389-ds-base 1.2.6.a1 or 1.2.6.a2? I used 1.2.6.a1 to compile originally and produce core files to answer your questions. Next I'll try this with 1.2.6.a2, but I'd rather keep the same version when trying to initially reproduce something. What compiler flags did you use? The makefile that came out of ./configure had these: CCASFLAGS = -g -O2 CFLAGS = -g -O2 CXXFLAGS = -g -O2 For the plain debug build I edited that to insert these and rebuilt with make, make install: CCASFLAGS = -g CFLAGS = -g CXXFLAGS = -g (Fair warning that I'm not a programmer, so I'm not entirely sure doing that was right.) Note that you don't have to edit the Makefile - you can do a make distclean, then run configure like this: CFLAGS=-g /path/to/configure ... make But that looks right, anyway. Note that if you change the flags like this by editing the makefile, you will have to do a make clean to remove the old object files, so that they will be rebuilt with the new flags. I did a make clean before rebuilding in this case. For my later debug builds I've used your step to re-run configure. Do you have a core file? If so, try using gdb gdb /path/to/ns-slapd /path/to/core.pid once in gdb, type the where command (gdb) where The original crash didn't produce a core file, but I could get one by attaching gdb later, to both the original build and a debug build. The underlying platform is: $ uname -a Linux cwlab-02.mycompany.com 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 i686 i386 GNU/Linux $ cat /etc/redhat-release CentOS release 5.4 (Final) $ free total used free sharedbuffers cached Mem: 389400013360122557988 0 144944 1004716 -/+ buffers/cache: 1863523707648 Swap: 2031608 02031608 Procedure To Crash 389's ns-slapd: a) In the NDS 6.2 admin console, create a new replication agreement for the o=This Big Net subtree, and choose to Create consumer initialization file. b) Copy the file to the 389 server. c) In the 389 2.6 admin console for the Directory Server, in the Configuration tab (Data - o=This Big Net - dbRoot), right-click and choose Initialize Database. Use the ldif file copied over. The ns-slapd process crashes, and I always get this in /opt/dirsrv/var/log/dirsrv/slapd-cwlab-02/errors as the last two lines: [03/Mar/2010:12:50:04 -0500] - import ldapAuthRoot
Re: [389-users] importing large subtree crashes ns-slapd
On Mon, Mar 15, 2010 at 03:05:10PM -0600, Rich Megginson wrote: Christopher Wood wrote: On Mon, Mar 15, 2010 at 12:57:08PM -0600, Rich Megginson wrote: Christopher Wood wrote: On Thu, Mar 04, 2010 at 12:06:31PM -0700, Rich Megginson wrote: Christopher Wood wrote: On Wed, Mar 03, 2010 at 08:30:19PM -0700, Rich Megginson wrote: Christopher Wood wrote: I'm just getting started with 389 Directory Server (at work), and I've run into an issue that I'm not certain how to troubleshoot. I would greatly appreciate any assistance or tips you could offer, especially on where to look to see what's failing. Also, I apologize in advance for changing strings related to my employer's directory names and such, as I'm not comfortable with leaking that level information to a public list. As well you should be - you should always obscure sensitive information like this. Overview: Initializing a large subtree from NDS 6.2 crashes ns-slapd, but other subtrees are fine. Top-Level Questions: 1) How do I stop ns-slapd from crashing? Good question. 2) How do I figure out what precisely is causing the crash? (With various levels of debug logging I get the same log entry.) You've already used the TRACE level (1) for logging - that's as verbose as it gets for this particular operation. Next step would be to try to get a core file. 3) Is it possible to simply import my initialization ldif without duplication checks? No. Background: At work we have NDS 6.2 (single master on a physical server, virtual machine slaves), and would like to move our directories intact to a 389 2.6 installation via replication. What platform/OS? 32-bit or 64-bit? By NDS 6.2 I'm assuming you mean Netscape Directory Server - by 2.6 I'm assuming you mean 1.2.6.a1 (a2 should be hitting the mirrors tomorrow). 32 bit I already have replicated several of our NDS 6.2 subtrees to 389 2.6 with no difficulties. I compiled our 389 installation from the source packages downloaded from http://directory.fedoraproject.org/wiki/Source. Did you grab 389-ds-base 1.2.6.a1 or 1.2.6.a2? I used 1.2.6.a1 to compile originally and produce core files to answer your questions. Next I'll try this with 1.2.6.a2, but I'd rather keep the same version when trying to initially reproduce something. What compiler flags did you use? The makefile that came out of ./configure had these: CCASFLAGS = -g -O2 CFLAGS = -g -O2 CXXFLAGS = -g -O2 For the plain debug build I edited that to insert these and rebuilt with make, make install: CCASFLAGS = -g CFLAGS = -g CXXFLAGS = -g (Fair warning that I'm not a programmer, so I'm not entirely sure doing that was right.) Note that you don't have to edit the Makefile - you can do a make distclean, then run configure like this: CFLAGS=-g /path/to/configure ... make But that looks right, anyway. Note that if you change the flags like this by editing the makefile, you will have to do a make clean to remove the old object files, so that they will be rebuilt with the new flags. I did a make clean before rebuilding in this case. For my later debug builds I've used your step to re-run configure. Do you have a core file? If so, try using gdb gdb /path/to/ns-slapd /path/to/core.pid once in gdb, type the where command (gdb) where The original crash didn't produce a core file, but I could get one by attaching gdb later, to both the original build and a debug build. The underlying platform is: $ uname -a Linux cwlab-02.mycompany.com 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 i686 i386 GNU/Linux $ cat /etc/redhat-release CentOS release 5.4 (Final) $ free total used free sharedbuffers cached Mem: 389400013360122557988 0 144944 1004716 -/+ buffers/cache: 1863523707648 Swap: 2031608 02031608 Procedure To Crash 389's ns-slapd: a) In the NDS 6.2 admin console, create a new replication agreement for the o=This Big Net subtree, and choose to Create consumer
Re: [389-users] importing large subtree crashes ns-slapd
On Wed, Mar 03, 2010 at 08:30:19PM -0700, Rich Megginson wrote: Christopher Wood wrote: I'm just getting started with 389 Directory Server (at work), and I've run into an issue that I'm not certain how to troubleshoot. I would greatly appreciate any assistance or tips you could offer, especially on where to look to see what's failing. Also, I apologize in advance for changing strings related to my employer's directory names and such, as I'm not comfortable with leaking that level information to a public list. As well you should be - you should always obscure sensitive information like this. Overview: Initializing a large subtree from NDS 6.2 crashes ns-slapd, but other subtrees are fine. Top-Level Questions: 1) How do I stop ns-slapd from crashing? Good question. 2) How do I figure out what precisely is causing the crash? (With various levels of debug logging I get the same log entry.) You've already used the TRACE level (1) for logging - that's as verbose as it gets for this particular operation. Next step would be to try to get a core file. 3) Is it possible to simply import my initialization ldif without duplication checks? No. Background: At work we have NDS 6.2 (single master on a physical server, virtual machine slaves), and would like to move our directories intact to a 389 2.6 installation via replication. What platform/OS? 32-bit or 64-bit? By NDS 6.2 I'm assuming you mean Netscape Directory Server - by 2.6 I'm assuming you mean 1.2.6.a1 (a2 should be hitting the mirrors tomorrow). 32 bit I already have replicated several of our NDS 6.2 subtrees to 389 2.6 with no difficulties. I compiled our 389 installation from the source packages downloaded from http://directory.fedoraproject.org/wiki/Source. Did you grab 389-ds-base 1.2.6.a1 or 1.2.6.a2? I used 1.2.6.a1 to compile originally and produce core files to answer your questions. Next I'll try this with 1.2.6.a2, but I'd rather keep the same version when trying to initially reproduce something. What compiler flags did you use? The makefile that came out of ./configure had these: CCASFLAGS = -g -O2 CFLAGS = -g -O2 CXXFLAGS = -g -O2 For the plain debug build I edited that to insert these and rebuilt with make, make install: CCASFLAGS = -g CFLAGS = -g CXXFLAGS = -g (Fair warning that I'm not a programmer, so I'm not entirely sure doing that was right.) Do you have a core file? If so, try using gdb gdb /path/to/ns-slapd /path/to/core.pid once in gdb, type the where command (gdb) where The original crash didn't produce a core file, but I could get one by attaching gdb later, to both the original build and a debug build. The underlying platform is: $ uname -a Linux cwlab-02.mycompany.com 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 i686 i386 GNU/Linux $ cat /etc/redhat-release CentOS release 5.4 (Final) $ free total used free sharedbuffers cached Mem: 389400013360122557988 0 1449441004716 -/+ buffers/cache: 1863523707648 Swap: 2031608 02031608 Procedure To Crash 389's ns-slapd: a) In the NDS 6.2 admin console, create a new replication agreement for the o=This Big Net subtree, and choose to Create consumer initialization file. b) Copy the file to the 389 server. c) In the 389 2.6 admin console for the Directory Server, in the Configuration tab (Data - o=This Big Net - dbRoot), right-click and choose Initialize Database. Use the ldif file copied over. The ns-slapd process crashes, and I always get this in /opt/dirsrv/var/log/dirsrv/slapd-cwlab-02/errors as the last two lines: [03/Mar/2010:12:50:04 -0500] - import ldapAuthRoot: Processing file /home/cwood/tbn.ldif [03/Mar/2010:12:50:04 -0500] - = str2entry_dupcheck Other Details: I found two bugs with the str2entry_dupcheck string in it, but they don't seem pertinent: https://bugzilla.redhat.com/show_bug.cgi?id=548115 https://bugzilla.redhat.com/show_bug.cgi?id=243488 This says that str2entry_dupcheck could be about two things: http://docs.sun.com/source/816-6699-10/ax_errcd.html While attempting to convert a string entry to an LDAP entry, the server found that the entry has no DN. The server failed to add a value to the value tree. (But this is an exported database from NDS 6.2, and I'm fairly sure, without reading them all, that every entry will have a DN.) The log message [03/Mar/2010:12:50:04 -0500] - = str2entry_dupcheck is just trace information, not a report of a problem or error. Does the crash happen almost immediately? Or does it take a while? If the problem happens quickly, it would be worthwhile to scan the first couple of dozen entries looking for things like - entries without a DN - attributes without
[389-users] importing large subtree crashes ns-slapd
I'm just getting started with 389 Directory Server (at work), and I've run into an issue that I'm not certain how to troubleshoot. I would greatly appreciate any assistance or tips you could offer, especially on where to look to see what's failing. Also, I apologize in advance for changing strings related to my employer's directory names and such, as I'm not comfortable with leaking that level information to a public list. Overview: Initializing a large subtree from NDS 6.2 crashes ns-slapd, but other subtrees are fine. Top-Level Questions: 1) How do I stop ns-slapd from crashing? 2) How do I figure out what precisely is causing the crash? (With various levels of debug logging I get the same log entry.) 3) Is it possible to simply import my initialization ldif without duplication checks? Background: At work we have NDS 6.2 (single master on a physical server, virtual machine slaves), and would like to move our directories intact to a 389 2.6 installation via replication. I already have replicated several of our NDS 6.2 subtrees to 389 2.6 with no difficulties. I compiled our 389 installation from the source packages downloaded from http://directory.fedoraproject.org/wiki/Source. The underlying platform is: $ uname -a Linux cwlab-02.mycompany.com 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 i686 i386 GNU/Linux $ cat /etc/redhat-release CentOS release 5.4 (Final) $ free total used free sharedbuffers cached Mem: 389400013360122557988 0 1449441004716 -/+ buffers/cache: 1863523707648 Swap: 2031608 02031608 Procedure To Crash 389's ns-slapd: a) In the NDS 6.2 admin console, create a new replication agreement for the o=This Big Net subtree, and choose to Create consumer initialization file. b) Copy the file to the 389 server. c) In the 389 2.6 admin console for the Directory Server, in the Configuration tab (Data - o=This Big Net - dbRoot), right-click and choose Initialize Database. Use the ldif file copied over. The ns-slapd process crashes, and I always get this in /opt/dirsrv/var/log/dirsrv/slapd-cwlab-02/errors as the last two lines: [03/Mar/2010:12:50:04 -0500] - import ldapAuthRoot: Processing file /home/cwood/tbn.ldif [03/Mar/2010:12:50:04 -0500] - = str2entry_dupcheck Other Details: I found two bugs with the str2entry_dupcheck string in it, but they don't seem pertinent: https://bugzilla.redhat.com/show_bug.cgi?id=548115 https://bugzilla.redhat.com/show_bug.cgi?id=243488 This says that str2entry_dupcheck could be about two things: http://docs.sun.com/source/816-6699-10/ax_errcd.html While attempting to convert a string entry to an LDAP entry, the server found that the entry has no DN. The server failed to add a value to the value tree. (But this is an exported database from NDS 6.2, and I'm fairly sure, without reading them all, that every entry will have a DN.) If 389 is trying to check for duplicate entries, perhaps there are simply too many DNs? $ grep '^dn:' tbn.ldif | wc -l 636985 $ ls -lh acc.ldif -rw-r--r-- 1 cwood cwood 755M Mar 3 11:24 tbn.ldif Per the instructions here: http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting I set my debug logging first to 24579: 1Trace function calls 2Debug packet handling 8192 Replication debugging 16384Critical messages Then for the next try at reading logs I set it to 90115, the above plus: 65536Plug-in debugging However, every time the log ended with the same set of lines noted above. -- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
