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
Type: ---


Attachments (Terms of Use)
ipaserver-install.log (305.62 KB, text/plain)
2010-05-05 19:21 UTC, Shawn
no flags Details
Display output (5.56 KB, text/plain)
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.