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):
Always on my system.
Steps to Reproduce:
Create new VM
Install F13b bare bones install
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
service network restart
run hostname to check name
run dig to check forward and reverse entries
yum install ipa-server
Failure in install script, unable to obtain admin ticket . Please see the log files
All steps of install to complete cleanly.
Created attachment 411713 [details]
Created attachment 411716 [details]
What version of 389-ds-base do you have installed?
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.
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:
389-ds added some new LDAPv3 DN normalization in the 1.2.6.a3 beta, this may be a problem with that.
Thanks for the quick response. I did the downgrade from
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.
Upgrading and restarting seems to work fine.
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.
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.