Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 589301 - ipa-server-install unable to load bootstrap-template
Summary: ipa-server-install unable to load bootstrap-template
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: ipa
Version: 13
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Rob Crittenden
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-05 19:15 UTC by Shawn
Modified: 2010-07-06 17:38 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-07-06 17:38:55 UTC


Attachments (Terms of Use)
ipaserver-install.log (deleted)
2010-05-05 19:21 UTC, Shawn
no flags Details
Display output (deleted)
2010-05-05 19:35 UTC, Shawn
no flags Details

Description Shawn 2010-05-05 19:15:38 UTC
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 19:21:24 UTC
Created attachment 411713 [details]
ipaserver-install.log

Comment 2 Shawn 2010-05-05 19:35:04 UTC
Created attachment 411716 [details]
Display output

Comment 3 Rob Crittenden 2010-05-05 19:41:38 UTC
What version of 389-ds-base do you have installed?

Comment 4 Shawn 2010-05-05 19:48:18 UTC
389-ds-base-1.2.6-0.3.a3.fc13.x86_64

Comment 5 Rob Crittenden 2010-05-05 20:09:51 UTC
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 21:49:27 UTC
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 22:27:39 UTC
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-06 00:25:18 UTC
Upgrading and restarting seems to work fine.

Comment 9 Rob Crittenden 2010-05-06 02:09:48 UTC
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 17:38:55 UTC
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.