Bug 437405

passing the passwords as an option to ipa-server-install also doesn't help here:

[root@fedora ~]# ipa-server-install -N -p redhat123 -a redhat123

will result in the same error code 49

Can you attach /var/log/ipaserver.log?

there is no ipsserver.log, the only ipa related log is /var/log/ipa_error.log
and this one is empty.

tried to install the server on f8 with enabled testing repo, got this error:

Configuring directory server:
  [1/16]: creating directory server user
  [2/16]: creating directory server instance
  [3/16]: adding default schema
  [4/16]: enabling memberof plugin
  [5/16]: enabling referential integrity plugin
  [6/16]: enabling distributed numeric assignment plugin
  [7/16]: configuring uniqueness plugin
  [8/16]: creating indices
  [9/16]: configuring ssl for ds instance
  [10/16]: configuring certmap.conf
  [11/16]: restarting directory server
  [12/16]: adding default layout
  [13/16]: configuring Posix uid/gid generation as first master
  [14/16]: adding master entry as first master
  [15/16]: initializing group membership
  [16/16]: configuring directory to start on boot
done configuring dirsrv.
Unexpected error - see ipaserver-install.log for details:
 {'desc': "Can't contact LDAP server"}
[root@tiffy ~]# ll /var/log/ipaserver-install.log
ls: cannot access /var/log/ipaserver-install.log: No such file or directory
[root@tiffy ~]# 

Well htat is some progress anyway. I think in the version you have the install
log goes into the current working directory.

Created attachment 298136 [details]
rawhide-system: /tmp/ipaserver-install.log

Created attachment 298137 [details]
f8-system: /tmp/ipaserver-install.log

on both stations ipa-server-0.99-11 is used. on the rawhide box it looks like
the directory manager password is not coded correctly. as I said, when I use the
ldapmodify tool manually with the password I created during the setup, I get the
49 error as well. reseting the password fixes the problem. 

no idea what's going on on the f8 system where the ldapmodify works, but the
ldap server is not available.
 

What is your locale set to? Can you try setting to en_US.UTF-8 if it isn't already?

on rhel5 and f8 this doesn't help to fix it, still the same issue with new locale:

[16/16]: configuring directory to start on boot
done configuring dirsrv.
Unexpected error - see ipaserver-install.log for details:
 {'desc': "Can't contact LDAP server"}
[root@rhel5 ~]# echo $LANG
en_US.UTF-8

will try to change the locale on the rawhide box as well, will do that tomorrow.
actually I don't have access to the box.

Ok, can you attach the directory server error log for a failed installation? It
can be found in /var/log/dirsrv/slapd-INSTANCE/errors

Created attachment 298343 [details]
error log from rawhide system

Created attachment 298344 [details]
error log from rhel5 system

That connect to LDAP thing sounds familiar. I worked on something similar where
it was trying to contact the wrong server. Can you try with an updated package
in rawhide: ipa-0.99-12.fc9

Similar updates are also in F-7 and F-8.

on rawhide where I had this credential problem I still get the same error code
49 when running ipa-server-install with latest rawhide packages:

[root@fedora ~]# echo $LANG
en_US.UTF-8
[root@fedora ~]# rpm -q ipa-server
ipa-server-0.99-12.fc9.i386
[root@fedora ~]# 

install-log and error-log (dirsrv) attached.

Created attachment 298712 [details]
ipaserver-install.log

Created attachment 298713 [details]
errors

keep in mind, this error is different than the one described on a f8/rhel5
system where the ldap connect error appears. on rawhide we have the problem that
the generated "directory manager" password is not accepted.

What is your locale?
Are you using something different from utf-8 and using non ASCII characters in
your password ?

LANG="en_US.UTF-8"

test password was "redhat123"

additional info:

[root@fedora ~]# /usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn="Directory Manager"
-w redhat123 -f /usr/share/ipa/memberof-conf.ldif
ldap_initialize( ldap://127.0.0.1 )
ldap_bind: Invalid credentials (49)

machine is a kvm running on f8.
 

Ok, let's try to simplify the problem and try setting up DS by hand. I think I
have all this syntax correct:

Put this into /var/lib/dirsrv/boot.ldif:

dn: dc=virt,dc=tuxgeek,dc=de
objectClass: top
objectClass: domain
objectClass: pilotObject
dc: virt
info: IPA V1.0

Put this into a file named setup.inf

[General]
FullMachineName=   fedora.virt.tuxgeek.de
SuiteSpotUserID=   dirsrv
ServerRoot=    /usr/lib/dirsrv
[slapd]
ServerPort=   389
ServerIdentifier=   VIRT-TUXGEEK-DE
Suffix=   dc=virt,dc=tuxgeek,dc=de
RootDN=   cn=Directory Manager
InstallLdifFile= /var/lib/dirsrv/boot.ldif
RootDNPwd= redhat123

Run:
/usr/sbin/setup-ds.pl --silent --logfile - -f setup.inf

Then see if you can authenticate to that. You may need to remove an existing
instance if there already is one. An easy way is to run
/usr/sbin/ipa-server-install and let it remove the instance for you, then ^C to
quit out of the installer.

looks good:

[root@fedora ~]# /usr/sbin/setup-ds.pl --silent --logfile - -f setup.inf
[08/03/27:19:33:49] - [Setup] Info Your new DS instance 'VIRT-TUXGEEK-DE' was
successfully created.
Your new DS instance 'VIRT-TUXGEEK-DE' was successfully created.
[08/03/27:19:33:49] - [Setup] Success Exiting . . .
Log file is '-'

Exiting . . .
Log file is '-'

[root@fedora ~]# 

when I call ipa-server-install I again got this:

The following operations may take some minutes to complete.
Please wait until the prompt is returned.
Configuring ntpd
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
done configuring ntpd.
Configuring directory server:
  [1/16]: creating directory server user
  [2/16]: creating directory server instance
  [3/16]: adding default schema
  [4/16]: enabling memberof plugin
root        : CRITICAL Failed to load memberof-conf.ldif: Command
'/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w redhat123 -f
/usr/share/ipa/memberof-conf.ldif' returned non-zero exit status 49
  [5/16]: enabling referential integrity plugin
root        : CRITICAL Failed to load referint-conf.ldif: Command
'/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w redhat123 -f
/usr/share/ipa/referint-conf.ldif' returned non-zero exit status 49
  [6/16]: enabling distributed numeric assignment plugin
root        : CRITICAL Failed to load dna-conf.ldif: Command
'/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w redhat123 -f
/usr/share/ipa/dna-conf.ldif' returned non-zero exit status 49
  [7/16]: configuring uniqueness plugin
root        : CRITICAL Failed to load unique-attributes.ldif: Command
'/usr/bin/ldapmodify -h 127.0.0.1 -xv -D cn=Directory Manager -w redhat123 -f
/tmp/tmpOPOdA3' returned non-zero exit status 49
  [8/16]: creating indices
root        : CRITICAL Failed to load indices.ldif: Command '/usr/bin/ldapmodify
-h 127.0.0.1 -xv -D cn=Directory Manager -w redhat123 -f
/usr/share/ipa/indices.ldif' returned non-zero exit status 49
  [9/16]: configuring ssl for ds instance
Unexpected error - see ipaserver-install.log for details:
 {'desc': 'Invalid credentials'}

It seems that the latest version of nss library rejects children to
use the security context. Therefore, ns-slapd can't use SHA  which breaks
authentication by rootdn created by setup-ds.pl even though authenticating by
pwdhash works. It's not the problem of ipa but fedora-ds.

See the following thread for more detail.
  
https://bugzilla.mozilla.org/show_bug.cgi?id=331096

(In reply to comment #25)
> It seems that the latest version of nss library rejects children to
> use the security context. Therefore, ns-slapd can't use SHA  which breaks
> authentication by rootdn created by setup-ds.pl even though authenticating by
> pwdhash works. It's not the problem of ipa but fedora-ds.
> 
> See the following thread for more detail.
>   
> https://bugzilla.mozilla.org/show_bug.cgi?id=331096
> 

This has been fixed in fedora-ds-base in rawhide.

(In reply to comment #26)
> (In reply to comment #25)
> > It seems that the latest version of nss library rejects children to
> > use the security context. Therefore, ns-slapd can't use SHA  which breaks
> > authentication by rootdn created by setup-ds.pl even though authenticating by
> > pwdhash works. It's not the problem of ipa but fedora-ds.
> > 
> > See the following thread for more detail.
> >   
> > https://bugzilla.mozilla.org/show_bug.cgi?id=331096
> > 
> 
> This has been fixed in fedora-ds-base in rawhide.
> 

I could reproduce the problem as of the release fedora-ds-base-1.1.0-1.3.fc9.
Maybe you forget to apply the patch in this release. I'm goning
to check the latest upload which the patch is applied correctly today.

same for me, usinf fedora-ds-base from todays rawhide, error is still the same.

(In reply to comment #28)
> same for me, usinf fedora-ds-base from todays rawhide, error is still the same.

F-9 or rawhide?  Note that fedora-ds-base-1.1.0.1-4 was just recently approved
for F-9 and doesn't appear to be in yet.

rawhide

using fedora-ds-base-1.1.0.1-4 from koji fixed the problem. 

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.