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] 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] 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)
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
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] 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
