Databases
cancel
Showing results for 
Search instead for 
Did you mean: 

NDS 6.11 failing to import posixAccount bulk into directory

Ralph Grothe
Honored Contributor

NDS 6.11 failing to import posixAccount bulk into directory

Hello,

After having installed the HP SD depot of Netscape Directory Server 6.11 on an 11.00 L-Class server, and also having installed the LDAP-UX integration kit on the same box, as well as having installed the dozens of required and recommended patches as well as having risen mentioned kernel and ndd tunables,
I'm now shamefully failing to import LDIF files that I created with the
/opt/ldapux/migrate/migrate_{group,passwd}.pl

Although the slapd of my directory is running, and even the admin server (though I doubt the latter is really necessary) I can neither import the LDIF files from within the GUI console manager as Directory Manager,
nor does an ldapmodify on the command line of the server host succeed.

Although the manuals are hundreds of pages thick
(e.g. http://docs.hp.com/en/2330/ds61admin.pdf,
http://docs.hp.com/en/J4269-90038/J4269-90038.pdf)
they to me seem to lack the decisive instructions.

Because such a thread is a bit unsuited for snapshots from the GUI console,
just let me show you the output from the command line tools.

First to make sure that I reference the right directory and distinguished name just a mere ldapsearch from the root.


# ldapsearch -h localhost -b "dc=nbr,dc=verwalt-berlin,dc=de" -s sub -D "cn=Directory Manager" -w - objectclass=\*
Enter bind password:
version: 1
dn: dc=nbr,dc=verwalt-berlin,dc=de
objectClass: top
objectClass: domain
dc: nbr

dn: cn=Directory Administrators, dc=nbr,dc=verwalt-berlin,dc=de
objectClass: top
objectClass: groupofuniquenames
cn: Directory Administrators

dn: ou=Groups, dc=nbr,dc=verwalt-berlin,dc=de
objectClass: top
objectClass: organizationalunit
ou: Groups

dn: ou=People, dc=nbr,dc=verwalt-berlin,dc=de
objectClass: top
objectClass: organizationalunit
ou: People

dn: ou=Special Users,dc=nbr,dc=verwalt-berlin,dc=de
objectClass: top
objectClass: organizationalUnit
ou: Special Users
description: Special Administrative Accounts

dn: cn=Accounting Managers,ou=groups,dc=nbr,dc=verwalt-berlin,dc=de
objectClass: top
objectClass: groupOfUniqueNames
cn: Accounting Managers
ou: groups
description: People who can manage accounting entries

dn: cn=HR Managers,ou=groups,dc=nbr,dc=verwalt-berlin,dc=de
objectClass: top
objectClass: groupOfUniqueNames
cn: HR Managers
ou: groups
description: People who can manage HR entries

dn: cn=QA Managers,ou=groups,dc=nbr,dc=verwalt-berlin,dc=de
objectClass: top
objectClass: groupOfUniqueNames
cn: QA Managers
ou: groups
description: People who can manage QA entries

dn: cn=PD Managers,ou=groups,dc=nbr,dc=verwalt-berlin,dc=de
objectClass: top
objectClass: groupOfUniqueNames
cn: PD Managers
ou: groups
description: People who can manage engineer entries

dn: ou=saz,dc=nbr,dc=verwalt-berlin,dc=de
ou: saz
description: System Administrations Zentrum ITDZ Berlin
objectClass: top
objectClass: organizationalunit
telephoneNumber: 030-9012-7543

dn: cn=saz,ou=saz,dc=nbr,dc=verwalt-berlin,dc=de
description: SAZ Administration
cn: saz
objectClass: top
objectClass: groupofuniquenames


The organizational units People and Group must have been create automatically during installation of NDS 6.11, and I will purge these entries soon.

I want my posixGroup and posixAccount schemas to reside beneath the ou saz I created.
My objective is to dump all the abt. 15000 entries from /etc/passwd from the production cluster nodes into this directory.
So I started with the import of the LDIF file from the migrate-group.pl output.

So I did this

# ldapmodify -h localhost -B "ou=saz,dc=nbr,dc=verwalt-berlin,dc=de" -n -w - -f /var/opt/netscape/servers/slapd-gouda/tmp/inn_group_stripped_by_sysids.ldif -D "cn=Directory Manager"
Enter bind password:
Error: unable to service extended operation request
'2.16.840.1.113730.3.5.7' for bulk import
(error:89:'Bad parameter to an ldap routine')


Boy, does anyone know by heart what object the oid 2.16.840.1.113730.3.5.7 refers to?

Before I have to delve into LDIF to judge whether the migration scripts produced appropiate output I've hoped to find some LDAP-literate experts here who have some experience with NDS.

Regards
Ralph
Madness, thy name is system administration
1 REPLY
Ralph Grothe
Honored Contributor

Re: NDS 6.11 failing to import posixAccount bulk into directory

After having looked at the script and read a bit about LDIF I realized that the script didn't produce accurate LDIF files.
At least when I used the -B switch of the LDAP-UX supplied ldapmodify incarnation
and only gave the DN up to what the migrate scripts left out in the dn: lines it alway flattened my entire directory :-{
With a line of Perl I corrected the dn: lines of the 15000 records.
Afterwards an "import" via ldapmodify went smoothly.
Meanwhile I also discovered how to use the nsperl in NDS (that contains PerLDAP, sadly in a very dated version) without producing coredumps (the SHLIB_PATH needed to be set,
and the @INC repopulated in a BEGIN block
(still an ugly hack)
At least with these modifications am I able to use the fine Mozilla::LDAP::* API.
Madness, thy name is system administration