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 Wood 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] 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
> > >>>>>>>
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
[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] 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 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). > >>>>>> > >>>>>>
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
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 un
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 >
[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
