Bug 435774 - Unhandled error during setup: Could not import LDIF file
Summary: Unhandled error during setup: Could not import LDIF file
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Install/Uninstall
Version: 1.1.0
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 249650 FDS112
TreeView+ depends on / blocked
 
Reported: 2008-03-03 19:58 UTC by Graham Leggett
Modified: 2015-01-04 23:31 UTC (History)
3 users (show)

Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-29 23:02:33 UTC
Embargoed:


Attachments (Terms of Use)
diffs (1.53 KB, patch)
2008-07-14 16:30 UTC, Rich Megginson
no flags Details | Diff
cvs commit log (195 bytes, text/plain)
2008-07-14 23:18 UTC, Rich Megginson
no flags Details

Description Graham Leggett 2008-03-03 19:58:28 UTC
When an attempt is made to run setup-ds.pl to installed a new instance of the
DS, and an ldif file is specified for import, the setup bombs out with the error
"Could not import LDIF file".

At this point a half-set-up instance remains, which has to be deleted and
started again.

What the setup should do is properly handle the error.

[08/03/03:23:47:57] - [Setup] Info Type the full path and filename, the word
suggest, or the word none
[08/03/03:23:48:44] - [Setup] Info /root/my.ldif
[08/03/03:23:48:50] - [Setup] Info Could not import LDIF file '/root/my.ldif'. 
Error: 59648.  Output: importing data ...
[03/Mar/2008:23:48:44 +0200] - dblayer_instance_start: pagesize: 4096, pages:
4097536, procpages: 42511
[03/Mar/2008:23:48:44 +0200] - cache autosizing: import cache: 204800k 
[03/Mar/2008:23:48:44 +0200] - li_import_cache_autosize: 50, import_pages:
51200, pagesize: 4096
[03/Mar/2008:23:48:44 +0200] - WARNING: Import is running with
nsslapd-db-private-import-mem on; No other process is allowed to access the database
[03/Mar/2008:23:48:44 +0200] - dblayer_instance_start: pagesize: 4096, pages:
4097536, procpages: 42511
[03/Mar/2008:23:48:44 +0200] - cache autosizing: import cache: 204800k 
[03/Mar/2008:23:48:44 +0200] - li_import_cache_autosize: 50, import_pages:
51200, pagesize: 4096
[03/Mar/2008:23:48:44 +0200] - import userRoot: Beginning import job...
[03/Mar/2008:23:48:44 +0200] - import userRoot: Index buffering enabled with
bucket size 100
[03/Mar/2008:23:48:44 +0200] - import userRoot: Could not open LDIF file
"/root/my.ldif"
[03/Mar/2008:23:48:45 +0200] - import userRoot: Aborting all import threads...
[03/Mar/2008:23:48:50 +0200] - import userRoot: Import threads aborted.
[03/Mar/2008:23:48:50 +0200] - import userRoot: Closing files...
[03/Mar/2008:23:48:50 +0200] - All database threads now stopped
[03/Mar/2008:23:48:50 +0200] - import userRoot: Import failed.

[08/03/03:23:48:50] - [Setup] Fatal Error: Could not create directory server
instance 'gatekeeper-domain-com'.
[08/03/03:23:48:50] - [Setup] Fatal Exiting . . .

Comment 1 Andrey Ivanov 2008-03-04 19:44:43 UTC
Try to allow the ldap server user (default is 'nobody', i think) to read the file.
 For example,
cp /root/my.ldif /tmp/my.ldif
chown nobody:nobody /tmp/my.ldif (or chmod a+r  /tmp/my.ldif)

Then specify the ldif file '/tmp/my.ldif' for your import. I think it is a
problem with file access rights...

Comment 2 Graham Leggett 2008-03-04 19:51:34 UTC
This bug has nothing to do with the file not being accessible, but rather to do
with the fact that the file being inaccessible caused the setup process to bomb
out, leaving a half configured server.

If the setup script cannot access the file as the given LDAP user, regardless of
the reason, the setup script should handle the error, give an error message and
prompt the user to try again.

The setup script should not bomb out.


Comment 5 Rich Megginson 2008-07-14 16:30:19 UTC
Created attachment 311725 [details]
diffs

Comment 6 Rich Megginson 2008-07-14 23:18:22 UTC
Created attachment 311785 [details]
cvs commit log

Reviewed by: nkinder (Thanks!)
Branch: HEAD
Fix Description: This doesn't allow you to re-prompt for the file, but this
will at least cause setup to output a sensible error message if it detects that
the given LDIF file is not readable.
Platforms tested: Fedora 8, Fedora 9
Flag Day: no
Doc impact: no

Comment 7 Yi Zhang 2009-04-03 22:09:55 UTC
Bug verified. result : pass

test is below:
-------------------------------------------------
1. construct an valid ldif file onlyroot.ldif (by using dbgen.pl)
2. make valid setup.ini file (check bottom for content)
3. run setup with this file

< DS81rpm >[root@mv32a-vm ~]# chmod a-wxr /tmp/onlyroot.ldif 
< DS81rpm >[root@mv32a-vm ~]# ls -l /tmp/onlyroot.ldif 
---------- 1 root root 150362 Apr  3 15:01 /tmp/onlyroot.ldif

< DS81rpm >[root@mv32a-vm ~]# setup-ds.pl -s -f ./mv32a.ds.ini 
Could not import LDIF file '/tmp/onlyroot.ldif'.  Error: 59648.  Output:
importing data ...
[03/Apr/2009:15:01:36 -0700] - dblayer_instance_start: pagesize: 4096, pages:
258811, procpages: 7072
[03/Apr/2009:15:01:36 -0700] - cache autosizing: import cache: 204800k 
[03/Apr/2009:15:01:36 -0700] - li_import_cache_autosize: 50, import_pages:
51200, pagesize: 4096
[03/Apr/2009:15:01:36 -0700] - WARNING: Import is running with
nsslapd-db-private-import-mem on; No other process is allowed to access the
database
[03/Apr/2009:15:01:36 -0700] - dblayer_instance_start: pagesize: 4096, pages:
258811, procpages: 7072
[03/Apr/2009:15:01:36 -0700] - cache autosizing: import cache: 204800k 
[03/Apr/2009:15:01:36 -0700] - li_import_cache_autosize: 50, import_pages:
51200, pagesize: 4096
[03/Apr/2009:15:01:36 -0700] - import userRoot: Beginning import job...
[03/Apr/2009:15:01:36 -0700] - import userRoot: Index buffering enabled with
bucket size 100
[03/Apr/2009:15:01:36 -0700] - import userRoot: Could not open LDIF file
"/tmp/onlyroot.ldif", errno 13 (Permission denied)
[03/Apr/2009:15:01:36 -0700] - import userRoot: Aborting all import threads...
[03/Apr/2009:15:01:42 -0700] - import userRoot: Import threads aborted.
[03/Apr/2009:15:01:42 -0700] - import userRoot: Closing files...
[03/Apr/2009:15:01:42 -0700] - All database threads now stopped
[03/Apr/2009:15:01:42 -0700] - import userRoot: Import failed.

Error: Could not create directory server instance 'mv32a-vm'.
Exiting . . .
Log file is '/tmp/setupplD22h.log'


=============[root@mv32a-vm ~]# cat mv32a.ds.ini 
[General]
FullMachineName=         mv32a-vm.idm.lab.bos.redhat.com
SuiteSpotUserID=         nobody
SuiteSpotGroup=          nogroup
AdminDomain=             idm.lab.bos.redhat.com
ConfigDirectoryAdminID=  admin
ConfigDirectoryAdminPwd= redhat123
ConfigDirectoryLdapURL= 
ldap://mv32a-vm.idm.lab.bos.redhat.com:9830/o=NetscapeRoot

[slapd]
SlapdConfigForMC=        Yes
UseExistingMC=           No
ServerPort=              389
ServerIdentifier=        mv32a-vm
Suffix=                  dc=example,dc=com
RootDN=                  cn=directory manager
RootDNPwd=               redhat123
InstallLdifFile=         /tmp/onlyroot.ldif
AddOrgEntries=           Yes
inst_dir=                /tmp/slapd-dsb
config_dir=              /tmp/slapd-dsb
schema_dir=              /tmp/slapd-dsb/schema
lock_dir=                /tmp/slapd-dsb/lock
log_dir=                 /tmp/slapd-dsb/logs
run_dir=                 /tmp/slapd-dsb/logs
db_dir=                  /tmp/slapd-dsb/db
bak_dir=                 /tmp/slapd-dsb/bak
tmp_dir=                 /tmp/slapd-dsb/tmp
ldif_dir=                /tmp/slapd-dsb/ldif
cert_dir=                /tmp/slapd-dsb
== content of mv32a.ds.ini ========

Comment 8 Chandrasekar Kannan 2009-04-29 23:02:33 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-0455.html

Comment 9 steven_li 2010-04-12 13:35:32 UTC
I still got the same error even I changed file format to below:

[gcdldaprw@agcdvldbr01 root]$ ls ~/userRoot.ldif  -l
-rw-r--r-- 1 gcdldaprw gcdldaprw 47277222 Mar 11 15:04 /home/gcdldaprw/userRoot.ldif


[13/Apr/2010:09:31:20 -0400] - Bringing userRoot offline...
[13/Apr/2010:09:31:20 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database
[13/Apr/2010:09:31:20 -0400] - import userRoot: Beginning import job...
[13/Apr/2010:09:31:20 -0400] - import userRoot: Index buffering enabled with bucket size 8
[13/Apr/2010:09:31:20 -0400] - import userRoot: Could not open LDIF file "/home/gcdldaprw/userRoot.ldif", errno 13 (Permission denied)
[13/Apr/2010:09:31:20 -0400] - import userRoot: Aborting all import threads...
[13/Apr/2010:09:31:28 -0400] - import userRoot: Import threads aborted.
[13/Apr/2010:09:31:28 -0400] - import userRoot: Closing files...
[13/Apr/2010:09:31:28 -0400] - import userRoot: Import failed.

Comment 10 Rich Megginson 2010-04-12 14:16:37 UTC
(In reply to comment #9)
> I still got the same error even I changed file format to below:
> 
> [gcdldaprw@agcdvldbr01 root]$ ls ~/userRoot.ldif  -l
> -rw-r--r-- 1 gcdldaprw gcdldaprw 47277222 Mar 11 15:04
> /home/gcdldaprw/userRoot.ldif
> 
> 
> [13/Apr/2010:09:31:20 -0400] - Bringing userRoot offline...
> [13/Apr/2010:09:31:20 -0400] - WARNING: Import is running with
> nsslapd-db-private-import-mem on; No other process is allowed to access the
> database
> [13/Apr/2010:09:31:20 -0400] - import userRoot: Beginning import job...
> [13/Apr/2010:09:31:20 -0400] - import userRoot: Index buffering enabled with
> bucket size 8
> [13/Apr/2010:09:31:20 -0400] - import userRoot: Could not open LDIF file
> "/home/gcdldaprw/userRoot.ldif", errno 13 (Permission denied)
> [13/Apr/2010:09:31:20 -0400] - import userRoot: Aborting all import threads...
> [13/Apr/2010:09:31:28 -0400] - import userRoot: Import threads aborted.
> [13/Apr/2010:09:31:28 -0400] - import userRoot: Closing files...
> [13/Apr/2010:09:31:28 -0400] - import userRoot: Import failed.    

grep nsslapd-localuser /etc/dirsrv/slapd-YOURINSTANCE/dse.ldif
ls -al /etc/dirsrv/slapd-YOURINSTANCE

Comment 11 steven_li 2010-04-13 02:00:42 UTC
[root@avldbr01 ~]# grep nsslapd-localuser /etc/dirsrv/slapd-avldbr01/dse.ldif
nsslapd-localuser: ldaprw
[root@avldbr01 ~]# ls -al /etc/dirsrv/slapd-avldbr01
total 444
drwxrwx--- 3 ldaprw ldaprw  4096 Apr 13 11:33 .
drwxrwxr-x 7 ldaprw ldaprw  4096 Apr 13 08:41 ..
-rw-rw---- 1 ldaprw ldaprw 65536 Apr 13 11:33 cert8.db
-r--r----- 1 ldaprw ldaprw  3595 Apr 13 08:41 certmap.conf
-rw------- 1 ldaprw ldaprw 73793 Apr 13 11:33 dse.ldif
-rw------- 1 ldaprw ldaprw 73793 Apr 13 10:36 dse.ldif.bak
-rw------- 1 ldaprw ldaprw 73793 Apr 13 09:37 dse.ldif.startOK
-r--r----- 1 ldaprw ldaprw 31010 Apr 13 08:41 dse_original.ldif
-rw-rw---- 1 ldaprw ldaprw 16384 Apr 13 11:33 key3.db
drwxrwx--- 2 ldaprw ldaprw  4096 Apr 13 11:33 schema
-rw-rw---- 1 ldaprw ldaprw 16384 Apr 13 08:41 secmod.db
-r--r----- 1 ldaprw ldaprw  5366 Apr 13 08:41 slapd-collations.conf

Comment 12 Rich Megginson 2010-04-13 14:50:19 UTC
What happens if you do
chown ldaprw:ldaprw /home/gcdldaprw/userRoot.ldif
?

But as you said in another thread in another bug, regarding this issue, the permission denied is likely due to selinux since you are seeing an AVC when you attempt the import.


Note You need to log in before you can comment on or make changes to this bug.