tomasz.napier...@allegro.pl wrote:
Hi,

Although I was very happy with FreeIPA on F12, due to compliance issues I had 
to upgrade our master server from F12 to F13. I tried several methods, and only 
yum upgrade was semi succesful.
After upgrade 389 seems to be running fine, with one exception: it stops 
responding queries after few minutes. All daemons are running fine:

Proto Recv-Q Send-Q Local Address               Foreign Address             
State       PID/Program name
tcp        0      0 127.0.0.1:8080              0.0.0.0:*                   
LISTEN      1057/python
tcp        0      0 10.7.30.20:464              0.0.0.0:*                   
LISTEN      1044/ipa_kpasswd
tcp        0      0 127.0.0.1:464               0.0.0.0:*                   
LISTEN      1044/ipa_kpasswd
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   
LISTEN      1063/sshd
tcp        0      0 0.0.0.0:8089                0.0.0.0:*                   
LISTEN      1121/splunkd
tcp        0      0 :::80                       :::*                        
LISTEN      1074/httpd
tcp        0      0 fe80::d04c:71ff:fe37:3b:464 :::*                        
LISTEN      1044/ipa_kpasswd
tcp        0      0 ::1:464                     :::*                        
LISTEN      1044/ipa_kpasswd
tcp        0      0 :::22                       :::*                        
LISTEN      1063/sshd
tcp        0      0 :::443                      :::*                        
LISTEN      1074/httpd
tcp        0      0 :::636                      :::*                        
LISTEN      1307/ns-slapd
tcp        0      0 :::389                      :::*                        
LISTEN      1307/ns-slapd

But every connection lokks like this:

[root@ipa ~]# telnet localhost 389
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
[root@ipa ~]# telnet localhost 636
Trying ::1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.

Connection is closed immediately.
[root@ipa-pci ~]# tail /var/log/dirsrv/slapd-QXLPCI/errors
[21/Feb/2011:00:17:25 +0100] - All database threads now stopped
[21/Feb/2011:00:17:25 +0100] - slapd stopped.
         389-Directory/1.2.7.5 B2010.350.1724
         ipa-pci.dc3:636 (/etc/dirsrv/slapd-QXLPCI)

I see nothing in the logs:

[21/Feb/2011:00:17:27 +0100] - 389-Directory/1.2.7.5 B2010.350.1724 starting up
[21/Feb/2011:00:17:27 +0100] NSMMReplicationPlugin - repl_set_mtn_referrals: 
could not set referrals for replica dc=qxlpci: 20
[21/Feb/2011:00:17:27 +0100] - slapd started.  Listening on All Interfaces port 
389 for LDAP requests
[21/Feb/2011:00:17:27 +0100] - Listening on All Interfaces port 636 for LDAPS 
requests
[21/Feb/2011:00:18:34 +0100] - conn=51 received a non-LDAP message (tag 0xd, 
expected 0x30)

Dirserver restart helps for few munites.
Looks quite serious and I really have no more ideas how to debug it.
My setup:
389-ds-base-1.2.7.5-1.fc13.x86_64
ipa-python-1.2.2-4.fc13.x86_64
ipa-client-1.2.2-4.fc13.x86_64
ipa-admintools-1.2.2-4.fc13.x86_64
ipa-server-selinux-1.2.2-4.fc13.x86_64
ipa-server-1.2.2-4.fc13.x86_64

[root@ipa ~]# grep 389 /var/log/yum.log
Feb 20 15:35:35 Updated: 389-ds-base-1.2.6.1-2.fc12.x86_64
Feb 20 23:47:19 Updated: 389-ds-base-1.2.7.5-1.fc13.x86_64

Any one have an idea what could be the reason?

Regards,

Boy, it could be a lot of things. I'd start by checking the SELinux log in /var/log/audit.log. Are you running in permissive or enforcing mode?

telnet is not very effective on SSL ports, you might want to try a real search. This assumes your IPA CA cert is in /etc/ipa/ca.crt:

$ TLS_CACERT=/etc/ipa/ca.crt ldapsearch -H ldaps://`hostname` -x -b 'dc=example,dc=com' uid=admin

Is the ns-slapd process going away or just refusing to accept connections? Is anything in the access log after you try one?

rob

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to