Description of problem: building the FDS from source on Gentoo works just fine and both the slapd and admin console start but i am unable to use the admin console to connect to the LDAP admin-serv. Version-Release number of selected component (if applicable): 1.0.4 How reproducible: always reprodcible Steps to Reproduce: 1. download and untar dsbuild-fds104.tar.gz 2. cd to dsbuild/meta/ds 3. make and install via the setup program 4. cd to /usr/local/fedora (which is where I choose to install the FDS) and ./startconsole 5. input user as: cn=admin 6. input password 7. input admin URL as http://akira.local.tld:3890/ 8. try to connect by pressing OK and it fails Actual results: Message window pops up and reports: Cannot logon because of an incorrect User ID, Incorrect password or Directory problem. HttpException: Responce: HTTP/1.1 401 Authorization Required Status: 401 URL: http://akira.local.tld:3890/admin-serve/authenticate Expected results: I would expect to be logged into the console at this point :-) Additional info: Debug output from start console using cn=admin and cn=Directory Manager: akira fedora # ./startconsole -D Fedora-Management-Console/1.0.3 B2007.057.2247 Warning: Cannot convert string "-b&h-lucida-medium-r-normal-sans-*-140-*-*-p-*-iso8859-1" to type FontStruct CommManager> New CommRecord (http://akira.local.tld:3890/admin-serv/authenticate) http://akira.local.tld:3890/[0:0] open> Ready http://akira.local.tld:3890/[0:0] accept> http://akira.local.tld:3890/admin-serv/authenticate http://akira.local.tld:3890/[0:0] send> GET \ http://akira.local.tld:3890/[0:0] send> /admin-serv/authenticate \ http://akira.local.tld:3890/[0:0] send> HTTP/1.0 http://akira.local.tld:3890/[0:0] send> Host: akira.local.tld:3890 http://akira.local.tld:3890/[0:0] send> Connection: Keep-Alive http://akira.local.tld:3890/[0:0] send> User-Agent: Fedora-Management-Console/1.0 http://akira.local.tld:3890/[0:0] send> Accept-Language: en http://akira.local.tld:3890/[0:0] send> Authorization: Basic \ http://akira.local.tld:3890/[0:0] send> Y249YW3tZW461jNza2lkb28= \ http://akira.local.tld:3890/[0:0] send> http://akira.local.tld:3890/[0:0] send> http://akira.local.tld:3890/[0:0] recv> HTTP/1.1 401 Authorization Required http://akira.local.tld:3890/[0:0] error> HttpException: Response: HTTP/1.1 401 Authorization Required Status: 401 URL: http://akira.local.tld:3890/admin-serv/authenticate http://akira.local.tld:3890/[0:0] close> Closed CommManager> New CommRecord (http://akira.local.tld:3890/admin-serv/authenticate) http://akira.local.tld:3890/[1:0] open> Ready http://akira.local.tld:3890/[1:0] accept> http://akira.local.tld:3890/admin-serv/authenticate http://akira.local.tld:3890/[1:0] send> GET \ http://akira.local.tld:3890/[1:0] send> /admin-serv/authenticate \ http://akira.local.tld:3890/[1:0] send> HTTP/1.0 http://akira.local.tld:3890/[1:0] send> Host: akira.local.tld:3890 http://akira.local.tld:3890/[1:0] send> Connection: Keep-Alive http://akira.local.tld:3890/[1:0] send> User-Agent: Fedora-Management-Console/1.0 http://akira.local.tld:3890/[1:0] send> Accept-Language: en http://akira.local.tld:3890/[1:0] send> Authorization: Basic \ http://akira.local.tld:3890/[1:0] send> Y249RGlyZWN0bFJ54E1h2mFnZXI6aGVsbG9udXJzZQ== \ http://akira.local.tld:3890/[1:0] send> http://akira.local.tld:3890/[1:0] send> http://akira.local.tld:3890/[1:0] recv> HTTP/1.1 401 Authorization Required http://akira.local.tld:3890/[1:0] error> HttpException: Response: HTTP/1.1 401 Authorization Required Status: 401 URL: http://akira.local.tld:3890/admin-serv/authenticate http://akira.local.tld:3890/[1:0] close> Closed I would also point out that I've tried this with several different versions of Java: akira fedora # java-config-2 -L The following VMs are available for generation-2: 1) Blackdown JDK 1.4.2.03 [blackdown-jdk-1.4.2] 2) Sun JDK 1.5.0.09 [sun-jdk-1.5] *) Sun JRE 1.4.2.13 [sun-jre-bin-1.4] 4) Sun JRE 1.5.0.09 [sun-jre-bin-1.5] Each of these have been tried and the result is the same. I would also like to point out that if I point firefox to: http://akira.local.tld:3890/admin-serv/tasks/configuration/HTMLAdmin?op=index I am unable to log in here either. However, if I point the firefox to: http://akira.net.bpa.gov:3890/clients/dsgw/bin/lang?context=dsgw&file=auth.html I am able to login as the Directory Manager just fine. Some of the error log for the admin-serve/logs dir looks like: [Wed Feb 28 10:33:58 2007] [notice] [client 127.0.0.1] admserv_host_ip_check: ap_get_remote_host could not resolve 127.0.0.1 [Wed Feb 28 10:33:58 2007] [notice] [client 127.0.0.1] admserv_check_authz(): passing [/admin-serv/authenticate] to the userauth handler [Wed Feb 28 10:50:30 2007] [notice] [client 127.0.0.1] admserv_host_ip_check: ap_get_remote_host could not resolve 127.0.0.1 [Wed Feb 28 10:50:30 2007] [error] [client 127.0.0.1] user cn=admin not found: /admin-serv/authenticate [Wed Feb 28 10:50:43 2007] [notice] [client 127.0.0.1] admserv_host_ip_check: ap_get_remote_host could not resolve 127.0.0.1 [Wed Feb 28 10:50:43 2007] [error] [client 127.0.0.1] user cn=admin not found: /admin-serv/authenticate [Wed Feb 28 10:50:56 2007] [notice] [client 127.0.0.1] admserv_host_ip_check: ap_get_remote_host could not resolve 127.0.0.1 [Wed Feb 28 10:50:56 2007] [notice] [client 127.0.0.1] admserv_check_authz(): passing [/admin-serv/authenticate] to the userauth handler [Wed Feb 28 10:55:52 2007] [notice] [client 127.0.0.1] admserv_host_ip_check: ap_get_remote_host could not resolve 127.0.0.1 [Wed Feb 28 10:55:52 2007] [error] [client 127.0.0.1] user cn=Directory Manager not found: /admin-serv/authenticate [Wed Feb 28 10:57:13 2007] [notice] [client 127.0.0.1] admserv_host_ip_check: ap_get_remote_host could not resolve 127.0.0.1 [Wed Feb 28 10:57:13 2007] [error] [client 127.0.0.1] user cn=admin not found: /admin-serv/authenticate
what happens if you go to http://akira.local.tld:3890/admin-serv/authenticate in your web browser?
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA.