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@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@localhost testdump]# cat /etc/issue Fedora release 16 (Verne) Kernel \r on an \m (\l)
[root@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?
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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 ofgroups 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 92>&1 |tee console.log - was invaluable.*
[dhe@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@localhost testdump]# cat /etc/issue Fedora release 16 (Verne) Kernel \r on an \m (\l)
[root@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@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
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.
Yes, an invalid key value pair in the ldif file being being imported from fedora-idm-console with import database is causing slapd to die.
On 01/27/2012 07:25 AM, Dan H. Eicher wrote:
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.
Yes, an invalid key value pair in the ldif file being being imported from fedora-idm-console with import database is causing slapd to die.
Any messages in the errors log? Do you see a report of a segfault from ns-slapd in /var/log/messages? Are there any core files in /var/log/dirsrv/slapd-INST?
389-users@lists.fedoraproject.org
-
Dan H. Eicher -
Rich Megginson