https://bugzilla.redhat.com/show_bug.cgi?id=751063
Description of problem: Version-Release number of selected component (if applicable): ipa-server-2.1.3-8.el6.x86_64 How reproducible: Always Steps to Reproduce: 1. MASTER: [root@decepticons ~]# service ipa status Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING DNS Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING [root@decepticons ~]# 2. SLAVE: [root@bumblebee ~]# ipa-replica-conncheck --master decepticons.lab.eng.pnq.redhat.com Check connection from replica to remote master 'decepticons.lab.eng.pnq.redhat.com': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: port 80 (80): OK HTTP Server: port 443(https) (443): OK Connection from replica to master is OK. 3. MASTER: [root@decepticons ~]# service ipa stop Stopping CA Service Stopping pki-ca: [ OK ] Stopping HTTP Service Stopping httpd: [ OK ] Stopping DNS Service Stopping named: . [ OK ] Stopping KPASSWD Service Shutting down ipa_kpasswd: [ OK ] Stopping KDC Service Stopping Kerberos 5 KDC: [ OK ] Stopping Directory Service Shutting down dirsrv: LAB-ENG-PNQ-REDHAT-COM... [ OK ] PKI-IPA... [ OK ] [root@decepticons ~]# 3. SLAVE: [root@bumblebee ~]# ipa-replica-conncheck --master decepticons.lab.eng.pnq.redhat.com Actual results: SLAVE: [root@bumblebee ~]# ipa-replica-conncheck --master decepticons.lab.eng.pnq.redhat.com Check connection from replica to remote master 'decepticons.lab.eng.pnq.redhat.com': Directory Service: Unsecure port (389): FAILED Directory Service: Secure port (636): FAILED Kerberos KDC: TCP (88): FAILED Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): FAILED Kerberos Kpasswd: UDP (464): OK <<<<<<<<<<<<<<<<<<<<<<<< HTTP Server: port 80 (80): FAILED HTTP Server: port 443(https) (443): FAILED Port check failed! Inaccessible port(s): 389, 636, 88, 464, 80, 443 [root@bumblebee ~]# Expected results: Kerberos Kpasswd: UDP (464): FAILED Additional info: MASTER: [root@decepticons ~]# netstat -anup | grep 464 [root@decepticons ~]#
The bug report is deceptive. We aren't checking to see if the services are running, we're testing that there isn't a firewall in between that would cause the connection to fail.
In any case testing for UDP "connectivity" is not possible without an echo server on the other side, or a protocol-aware UDP client.
I think we should just remove the UDP checks altogether.
A second option would be to report UDP port check result as "SKIPPED" on replica->master direction as it is testing against live KPASSWD port which does not respond.
UDP ports in direction master->replica can be checked as it is run against our tool.
attachment freeipa-mkosek-205-remove-udp-checks-from-conncheck.patch
Patch freeipa-mkosek-205-remove-udp-checks-from-conncheck.patch sent for review
Moving to NEEDS_TRIAGE so that we can decide which approach we should take:
attachment freeipa-mkosek-222-sanitize-udp-checks-in-conncheck.patch
Patch freeipa-mkosek-222-sanitize-udp-checks-in-conncheck.patch sent for review
master: 306bdcc
ipa-2-2: d0320b9
A working iptables config generally looks something like:
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 389 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 7389 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 636 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 88 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 88 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 464 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 464 -j ACCEPT
You can replace ACCEPT with DROP to test that this is properly detecting the state
UDP is only tested on the replica.
Metadata Update from @mkosek: - Issue assigned to mkosek - Issue set to the milestone: FreeIPA 2.2 Core Effort - 2012/02
Login to comment on this ticket.