Description of problem: After upgrading from fedora-ds to 389-ds via "yum upgrade" and running "setup-ds-admin.pl -u" I _can_ access the Administration Server but I _cannot_ access the Directory Server on the same machine from within 389-console. The directory server has configured: nsslapd-listenhost:: OjpmZmZmOjEyNy4wLjAuMQ== i.e. ::ffff:127.0.0.1 As soon as I remove this restriction, everything works fine. wireshark shows, that accessing the Administration Server uses localhost, while accessing the Directory Server uses the machines ip address which is blocked by the line above. (I want to restrict unencrypted ldap access to localhost only.) Everything worked fine with the previous fedora-ds release. Version-Release number of selected component (if applicable): Installing: 389-admin i386 1.1.8-3.fc10 replacing fedora-ds-admin.i386 1.1.7-3.fc10 389-admin-console noarch 1.1.4-1.fc10 replacing fedora-ds-admin-console.noarch 1.1.3-1.fc10 389-console noarch 1.1.3-3.fc10 replacing fedora-idm-console.i386 1.1.3-1.fc10 389-ds noarch 1.1.3-4.fc10 replacing fedora-ds.noarch 1.1.3-1.fc10 389-ds-base i386 1.2.1-1.fc10 replacing fedora-ds-base.i386 1.2.0-4.fc10 389-ds-base-devel i386 1.2.1-1.fc10 replacing fedora-ds-base-devel.i386 1.2.0-4.fc10 389-ds-console noarch 1.2.0-4.fc10 replacing fedora-ds-console.noarch 1.2.0-1.fc10 389-dsgw i386 1.1.4-1.fc10 replacing fedora-ds-dsgw.i386 1.1.2-1.fc10 Updating: 389-adminutil i386 1.1.8-3.fc10 (was 389-adminutil-1.1.8-2.fc10.i386) Installing for dependencies: 389-admin-console-doc noarch 1.1.4-1.fc10 389-ds-console-doc noarch How reproducible: Steps to Reproduce: 1. upgrade from fedora-ds to 389-ds via yum upgrade, run setup-ds-admin.pl -u 2. configure in /etc/dirsrv/slapd-<instance>/dse.ldif: nsslapd-listenhost:: OjpmZmZmOjEyNy4wLjAuMQ== 3. run 389-console and try to access "Directory Server (<instance>)" Actual results: The directory server status is reported as "stopped", which isn't true (access via OpenLDAP's ldapsearch works fine). The Diretory Server console does not open. wireshark shows ldap access to the machine's ip address, not to localhost. Expected results: LDAP access from 389-console to localhost when trying to open the Directory Server console from within 389-console, as before the upgrade Additional info: In the Admin Server Console under Configure Admin Server UserDS "Use Default User Directory" is selected, which is reported as: ldap://localhost:389//dc=... (that looks correct to me)
Sorry, for my typo, it is ldap://localhost:389/dc=... (not ...//dc=...)
I don't think the console is IPv6 aware. Is this an IPv6 problem?
We do not yet use IPv6. To me it looked like this: When trying to open the Directory Server console (at least some) network traffic went to the machine's ip address, not to localhost as I tried to configure (may be I didn't configure it right, however it worked before the update). My current workaround is to connect to the Directory Server console via ldaps (which caused problems some time in the past, but works fine now). This way only localhost is open for unencrypted access by an ldap proxy running on the same machine.
If you do a netstat -an, what interfaces/ports does it show the directory server listening to?
netstat -an | grep 389 | grep LISTEN: tcp 0 0 xxx.xxx.xxx.yyy:389 0.0.0.0:* LISTEN tcp 0 0 ::ffff:127.0.0.1:389 :::* LISTEN netstat -na | grep 636 | grep LISTEN: tcp 0 0 xxx.xxx.xxx.yyy:636 0.0.0.0:* LISTEN tcp 0 0 ::ffff:xxx.xxx.xxx.xxx:636 :::* LISTEN xxx.xxx.xxx.xxx is the ip address of the 389-directory server xxx.xxx.xxx.yyy is the ip address of the ldap proxy (OpenLDAP) /etc/sysconfig/network-scripts/ifcfg-eth0 contains IPV6INIT=no /etc/dirsrv/slapd-<name>/dse.ldif contains: nsslapd-listenhost:: OjpmZmZmOjEyNy4wLjAuMQ== nsslapd-securelistenhost:: OjpmZmZmxxxxxxxxxxxxxxxx OjpmZmZmOjEyNy4wLjAuMQ== is ::ffff:127.0.0.1 OjpmZmZmxxxxxxxxxxxxxxxx is ::ffff:xxx.xxx.xxx.xxx In https://bugzilla.redhat.com/show_bug.cgi?id=213626 I was told to try the "nsslapd-listenhost: ::ffff:N.N.N.N" notation which worked fine for me in the past. the ldap proxy is configured to listen on xxx.xxx.xxx.yyy (the ip address of <fqdn>) by: exec /usr/sbin/slapd -d 256 -f /etc/openldap/slapd.conf -h "ldap://<fqdn>/ ldaps://<fqdn>/" -u ldap (xxx.xxx.xxx.yyy is bound to eth0:0 by heartbeat)
So nothing really contacts the 389 directory server directly, everything goes through the openldap proxy?
Most of our applications go through the ldap proxy, but not everything: Our e-learning platform e.g. allows to configure more than one ldap server, but it takes at least 180 seconds (network protocol timeout) until the second one is tried if the first one is unreachable - inacceptable. So we've configured the e-learning platform to use the proxy; several other applications as well. On the other hand we have a web application to look up contact information of employees and to allow an employee to change certain data of his/her own in the ldap. This is a self written application that can test which of our 389 directory servers is up and running. Because we need some business logic, we restrict write access to the machines hosting the web application. As access writes are enforced on the 389 directory server, not the OpenLDAP proxy, we cannot go through the proxy in this case (the 389 directory server would see the proxy as the connecting client). So we offer direct access to the 389 directory server and access via a proxy, but in any case we want to make shure (per firewall) that simple bind operations are possible only via encrypted connections to port 636 (and may be to localhost:389).
I'm just trying to figure out if this is IPv6 related - the directory server listen address is the IPv6 one: tcp 0 0 ::ffff:127.0.0.1:389 :::* LISTEN and tcp 0 0 ::ffff:xxx.xxx.xxx.xxx:636 :::* LISTEN Note that the directory server is only listening to 127.0.0.1:389 so won't be available for connection from other machines on port 389 - looks like it is listening on a "real" IP address for port 636, so you can access that port from other machines.
As I wrote in the very beginning of ths thread I would like to access the "Directory Server" on the same machine from within 389-console. I would like to do that via localhost. In the Admin Server Console under Configure Admin Server UserDS "Use Default User Directory" is selected, which is reported as: ldap://localhost:389//dc=... Nevertheless wireshark shows, that accessing the Administration Server uses localhost, while accessing the Directory Server uses the machines ip address. May be my configuration isn't correct (though it worked under fedora-ds). How do I have to configure that "Directory Server" is connected via localhost from within 389-console? Thanks in advance.
I am unable to reproduce this issue using the current 389 package versions. I am able to set nsslapd-listenhost to "::ffff:127.0.0.1" and connect using Console just fine. I think the initial problem may have had something to do with the hostname provided to setup-ds-admin.pl when the instances were created, or possibly something with the hosts file. The Console determines how to contact the Directory Server instance that you open from data in "o=NetscapeRoot" in the configuration DS. Perhaps this data has a hostname that resolves to the IP address, or has the IP address itself. Do you still have the system available that has this problem? I would like to know what the "serverhostname" attribute is for your host entry in "o=NetscapeRoot". This entry will be named something like "cn=<host>,"ou=<config domain>,o=NetscapeRoot". I would also like to know if that hostname resolves to your actual IP address instead of the loopback address. I believe that this is where the problem is on your system, but I'd like to verify that before closing this bug report.
Closing this as WORKSFORME. If there is still an issue, please reopen this bug report.