[389-users] Problems with Database Import.

Thu Jan 26 21:57:49 UTC 2012

On 01/26/2012 02:34 PM, Dan H. Eicher wrote:
>
> Rich/All,
>
>     I finally got my ldif to import. I found I had a small number of 
> groups with bogus information in their records (I'll include one 
> actual example below). Once these couple of entries where 
> removed/corrected, everything imported. I have also including the 
> specific on 389 / fedora version-ing information.
>
>     The use of:*fedora-idm-console -D 9
> 2>&1 |tee console.log - was invaluable.*
>
> [dhe at localhost testdump]$ rpm -qi 389-ds-base
> Name        : 389-ds-base
> Version     : 1.2.10
> Release     : 0.5.a5.fc16
> Architecture: x86_64
> Install Date: Tue 17 Jan 2012 03:29:47 PM EST
> Group       : System Environment/Daemons
> Size        : 4907156
> License     : GPLv2 with exceptions
> Signature   : RSA/SHA256, Fri 04 Nov 2011 02:31:54 PM EDT, Key ID 
> 067f00b6a82ba4b7
> Source RPM  : 389-ds-base-1.2.10-0.5.a5.fc16.src.rpm
> Build Date  : Fri 04 Nov 2011 07:13:20 PM EDT
> Build Host  : x86-17.phx2.fedoraproject.org
> Relocations : (not relocatable)
> Packager    : Fedora Project
> Vendor      : Fedora Project
> URL         : http://port389.org/
> Summary     : 389 Directory Server (base)
> Description :
> 389 Directory Server is an LDAPv3 compliant server.  The base package 
> includes
> the LDAP server and command line utilities for server administration.
>
>
> [root at localhost testdump]# cat /etc/issue
> Fedora release 16 (Verne)
> Kernel \r on an \m (\l)
>
> [root at localhost testdump]# uname -a
> Linux localhost.localdomain 3.2.1-3.fc16.x86_64 #1 SMP Mon Jan 23 
> 15:36:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
>
>
> dn: cn=DRSS,ou=Groups,dc=localdomain
> modifyTimestamp: 20110909040227Z
> modifiersName: uid=suser,dc=localdomain
> cn: DRSS
> gidNumber: 11380
> memberUid: u1
> memberUid: u2
> memberUid: u3
> memberUid: u4
> ntUserDomainId: DRSS
> objectClass: top
> objectClass: groupofuniquenames
> objectClass: posixgroup
> objectClass: ntgroup
> uniqueMember: uid=u1,u2,u3,u4,ou=Users,dc=localdomain
> >> This doesn't look like a unique Member.... -or-
> uniqueMember: uid=
> >> Null
> uniqueMember: uid=u1,ou=Users, dc=localdomain
> uniqueMember: uid=u2,ou=Users, dc=localdomain
> uniqueMember: uid=u3,ou=Users, dc=localdomain
> creatorsName: uid=suser,dc=localdomain
> createTimestamp: 20110909040111Z
> nsUniqueId: 4cd49801-da9811e0-90ddb7ef-aa3939d0
>
> I guess the take away is, you can create garbage inside LDAP, export 
> said garbage, but don't expect it to import.
>
> Is the result of having slapd die the normal behavior, or should a bug 
> report be filled?
slapd is dying or crashing?  That is not normal.
>
> Thanks for the help,
> Dan
>
>
>
> On 01/24/2012 03:21 PM, Rich Megginson wrote:
>> On 01/24/2012 12:25 PM, Dan H. Eicher wrote:
>>>
>>> Hi,
>>>  I will answer publicly so others might get some benefit, but first 
>>> a dumb questions.
>>>
>>>    When I try to do a ldif2db from the command line, nothing gets 
>>> added, I get an error message similar
>>>    to:
>>>
>>>
>>> *[24/Jan/2012:10:56:06
>>>
>>> -0500]
>>>
>>>
>>>
>>> - import userRoot: WARNING: Skipping entry
>>>
>>>
>>>
>>> "uid=myuser,ou=Users,dc=localdomain" which has no parent,
>>>
>>>
>>>
>>> ending at line 533175 of file "/testdump/dr-out-mod2"
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> I manually added an ou called Users under localdomain -
>>> but
>>>
>>>
>>>
>>> still no joy.
>>>
>>>
>>>
>>> *
>> Right.  import is not an "additive" operation, it is a "destructive" 
>> operation.  If you want the entry to be added, add it first to the 
>> LDIF file.  That means your ldif file will first need an entry for 
>> dc=localdomain, then under that an entry for *ou=Users,dc=localdomain,
>> then your user entries.*
>>> *
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Import Database does not seem to have this issue with no
>>>
>>>
>>>
>>> parent, but Initialize Database which is running now,
>>> seems
>>>
>>> to
>>>
>>>
>>>
>>> also.
>>>
>>>
>>>
>>> *
>> Right.  In console "import" is additive and "initialize" is destructive.
>>> *
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Any tips?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *
>>>
>>>
>>>
>>> On 01/23/2012 04:07 PM, Rich Megginson wrote:
>>>> On 01/23/2012 02:05 PM, Dan H. Eicher wrote:
>>>>> I’m attempting to port my ldap database from one machine to 
>>>>> another, the machine I am attempting to port to is running a newer 
>>>>> version of 389. The target machine is build 2011.308.2312.
>>>>>
>>>>> On the source machine I do an db2ldif - all looks good.
>>>>>
>>>>> I go to the target machine and start fedora-console, open the 
>>>>> directory server and choose import database.
>>>> Have you tried Initialize database?
>>>>>
>>>>> The first couple of thousand entries/users seem to go well, but 
>>>>> then by looking at both my ldif source file and the contents of my 
>>>>> reject file after one particular user I get:
>>>>>
>>>>> Error adding object 'dn: uid=ctuser,ou=Users,dc=localdomain'. The 
>>>>> error sent by the server was 'Cannot connect to the LDAP server'.
>>>> Did the server then crash?  Do you have a core file? What platform?
>>>> What version is the target machine?  rpm -qi 389-ds-base
>>>>>
>>>>> Every new user after that fails to be added.
>>>>>
>>>>> The import appears to complete and slapd doesn’t stop.
>>>>>
>>>>> Any tips here on how I can resolve this?
>>>> You could try to use ldif2db from the command line on the target 
>>>> machine.
>>>>>
>>>>> Thanks,
>>>>> Dan
>>>>> -- 
>>>>> 389 users mailing list
>>>>> 389-users at lists.fedoraproject.org
>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>
>>>
>>
>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20120126/4c017a30/attachment.html>