Hide Forgot
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:
Created attachment 411713 [details] ipaserver-install.log
Created attachment 411716 [details] Display output
What version of 389-ds-base do you have installed?
389-ds-base-1.2.6-0.3.a3.fc13.x86_64
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: 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.
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.
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.