Bug 589301 - ipa-server-install unable to load bootstrap-template
ipa-server-install unable to load bootstrap-template
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: ipa (Show other bugs)
13
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Rob Crittenden
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-05 15:15 EDT by Shawn
Modified: 2010-07-06 13:38 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-06 13:38:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ipaserver-install.log (305.62 KB, text/plain)
2010-05-05 15:21 EDT, Shawn
no flags Details
Display output (5.56 KB, text/plain)
2010-05-05 15:35 EDT, Shawn
no flags Details

  None (edit)
Description Shawn 2010-05-05 15:15:38 EDT
Description of problem:

Running the ipa-server-install script the installer gives the following error.

  [13/17]: adding default layout
root        : CRITICAL Failed to load bootstrap-template.ldif: Command '/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -y /tmp/tmpxdK_lX -f /tmp/tmpEb57E2' returned non-zero exit status 34

It then continues on happily running and then gives the following error.

Applying LDAP updates
root        : ERROR    Update failed: A database error occurred: Object class violation unknown object class "nisDomainObject"

The script then exits thinking every thing is fine and gives us the message for the next steps.

I will attach the /var/log/ipa* logs



Version-Release number of selected component (if applicable):

ipa-client-1.2.2-3.fc13.x86_64
ipa-server-selinux-1.2.2-3.fc13.x86_64
ipa-python-1.2.2-3.fc13.x86_64
ipa-admintools-1.2.2-3.fc13.x86_64
ipa-server-1.2.2-3.fc13.x86_64



How reproducible:

Always on my system.

Steps to Reproduce:

Create new VM 

Install F13b bare bones install

Modify /etc/hosts

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.0.18 ipa1.hideout ipa1

Add forward and reverse entries to DNS

Configure /etc/resolv.conf

Configure eth0

service network restart

run hostname to check name 

run dig to check forward and reverse entries

yum upgrade

reboot

yum install ipa-server

ipa-server-install -N


Configure eth0

  
Actual results:

Failure in install script, unable to obtain admin ticket . Please see the log files


Expected results:

All steps of install to complete cleanly.

Additional info:
Comment 1 Shawn 2010-05-05 15:21:24 EDT
Created attachment 411713 [details]
ipaserver-install.log
Comment 2 Shawn 2010-05-05 15:35:04 EDT
Created attachment 411716 [details]
Display output
Comment 3 Rob Crittenden 2010-05-05 15:41:38 EDT
What version of 389-ds-base do you have installed?
Comment 4 Shawn 2010-05-05 15:48:18 EDT
389-ds-base-1.2.6-0.3.a3.fc13.x86_64
Comment 5 Rob Crittenden 2010-05-05 16:09:51 EDT
Ok, I will try to duplicate. I know that this version of 389-ds-base has problems with the under-development IPAv2. I haven't tried it with v1 yet. I'll see if that is the problem or something else.
Comment 6 Rob Crittenden 2010-05-05 17:49:27 EDT
This seems related to your using a single level realm name. It works ok for me if I use EXAMPLE.COM but not EXAMPLE.

There are two workarounds for now:

1. Downgrade 389-ds-base. You have a beta version that is in updates-testing which is enabled by default in the F13 beta. (# yum downgrade 389-ds-base)

2. Use a multiple-component realm name

I traced the issue to be more than 1 CN value in a quoted DN. It is failing on:

cn="cn=inactivated,cn=account inactivation,cn=accounts,$SUFFIX", cn=cosTemplates,cn=accounts,$SUFFIX

If SUFFIX=EXAMPLE I can add:

cn="cn=inactivated,dc=EXAMPLE", cn=cosTemplates,cn=accounts,EXAMPLE


but not:

cn="cn=inactivated,cn=accounts,dc=EXAMPLE", cn=cosTemplates,cn=accounts,EXAMPLE

389-ds added some new LDAPv3 DN normalization in the 1.2.6.a3 beta, this may be a problem with that.
Comment 7 Shawn 2010-05-05 18:27:39 EDT
Thanks for the quick response. I did the downgrade from

389-ds-base.x86_64 0:1.2.6-0.3.a3.fc13    

to

389-ds-base.x86_64 0:1.2.6-0.1.a1.fc13

then reran the install which went fine this time. I also tried requesting a ticket and adding a user which both seem to have gone well. So yes it does seem to be specific to that version. 

I will try upgrading and restarting next to see if it still works or breaks.
Comment 8 Shawn 2010-05-05 20:25:18 EDT
Upgrading and restarting seems to work fine.
Comment 9 Rob Crittenden 2010-05-05 22:09:48 EDT
Word of warning: locking and unlocking users may not work with ds 1.2.6.a3 as those are the problematic DNs.

From talking with the 389-ds guys in irc (freenode #389) it seems that this problem is being addressed but won't be released for a few more weeks. The fix for this addresses or fixes bugs: 199923 567968 570107 570962 572785 573060 574167

We're trying to ensure that 1.2.6.a1 is the version released in F-13 final.
Comment 10 Rob Crittenden 2010-07-06 13:38:55 EDT
I'm going to go ahead and close this as it isn't an IPA bug. It should be fixed in the most recent 389-ds release candidate.

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