Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1456352

Summary: resolver socketfactory type doesn't work with multiple network interfaces
Product: [oVirt] ovirt-engine-extension-aaa-ldap Reporter: Ondra Machacek <omachace>
Component: CoreAssignee: Ondra Machacek <omachace>
Status: CLOSED NOTABUG QA Contact: Gonza <grafuls>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 1.3.2CC: bugs, mperina, wrichter
Target Milestone: ovirt-4.3.0Flags: rule-engine: ovirt-4.3+
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-12-20 09:39:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ondra Machacek 2017-05-29 07:58:12 UTC 
Description of problem:
When there is an IPA <-> RHV integration with aaa-ldap and IPA and RHV has multiple networks interfaces and DNS resolution done via /etc/hosts. The communication between IPA and RHV doesn't work. It fails on connection timeout error if using 'pool.default.socketfactory.type = resolver'.

Version-Release number of selected component (if applicable):
1.0

How reproducible:
always

Steps to Reproduce:
1. Use multiple NICs for IPA and RHV and /etc/hosts for DNS2
2. Set: pool.default.socketfactory.type = resolver

Actual results:
Connection timeout

Expected results:
Connection succeed.

Additional info:
Comment 1 Ondra Machacek 2017-06-06 11:23:38 UTC 
Wolfram, can you please provide info how do you have the network interfaces configured in your IPA?
Comment 2 Wolfram Richter 2017-06-06 17:37:32 UTC 
*** Bug 1458920 has been marked as a duplicate of this bug. ***
Comment 3 Wolfram Richter 2017-06-06 17:48:03 UTC 
Hi Ondra,

this is a nested virtualization setup; each network is actually a libvirt bridge device that the IPA VM and the RHVM VM connect to. IPA attaches to 3 of these networks, three of which are shared with RHVM. The network communication is _intended_ (by me) to go via eth0 (192.168.101.0/24 network), but IPA resolves DNS requests against its own hostname with all 3 IPs.


[root@ipa ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 02:00:00:00:01:0b brd ff:ff:ff:ff:ff:ff
    inet 192.168.101.11/24 brd 192.168.101.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::ff:fe00:10b/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 02:00:00:00:03:0b brd ff:ff:ff:ff:ff:ff
    inet 192.168.103.11/24 brd 192.168.103.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::ff:fe00:30b/64 scope link
       valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 02:00:00:00:04:0b brd ff:ff:ff:ff:ff:ff
    inet 192.168.104.11/24 brd 192.168.104.255 scope global eth2
       valid_lft forever preferred_lft forever
    inet6 fe80::ff:fe00:40b/64 scope link
       valid_lft forever preferred_lft forever
[root@ipa ~]#



[root@rhevm ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 02:00:00:00:01:0c brd ff:ff:ff:ff:ff:ff
    inet 192.168.101.12/24 brd 192.168.101.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::ff:fe00:10c/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 02:00:00:00:03:0c brd ff:ff:ff:ff:ff:ff
    inet 192.168.103.12/24 brd 192.168.103.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::ff:fe00:30c/64 scope link
       valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 02:00:00:00:04:0c brd ff:ff:ff:ff:ff:ff
    inet 192.168.104.12/24 brd 192.168.104.255 scope global eth2
       valid_lft forever preferred_lft forever
    inet6 fe80::ff:fe00:40c/64 scope link
       valid_lft forever preferred_lft forever
[root@rhevm ~]#


At the moment, I do not have DNS resolution via /etc/hosts configured for IPA:

[root@rhevm ~]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.101.10 satellite satellite.hailstorm2.coe.muc.redhat.com
192.168.101.12 rhevm.hailstorm2.coe.muc.redhat.com
192.168.103.13 rhevh1.hailstorm2.coe.muc.redhat.com
192.168.103.14 rhevh2.hailstorm2.coe.muc.redhat.com
[root@rhevm ~]# nslookup ipa
Server:		192.168.101.11
Address:	192.168.101.11#53

Name:	ipa.hailstorm2.coe.muc.redhat.com
Address: 192.168.101.11
Name:	ipa.hailstorm2.coe.muc.redhat.com
Address: 192.168.104.11
Name:	ipa.hailstorm2.coe.muc.redhat.com
Address: 192.168.103.11

[root@rhevm ~]# cat /etc/ovirt-engine/aaa/IPA.properties
include = <ipa.properties>

vars.server = ipa.hailstorm2.coe.muc.redhat.com
vars.user = uid=admin,cn=users,cn=compat,dc=hailstorm2,dc=coe,dc=muc,dc=redhat,dc=com
vars.password = xxxxxxx

pool.default.auth.simple.bindDN = ${global:vars.user}
pool.default.auth.simple.password = ${global:vars.password}
pool.default.serverset.type = single
pool.default.serverset.single.server = ${global:vars.server}
pool.default.ssl.startTLS = true
pool.default.socketfactory.type = java
pool.default.ssl.truststore.file = ${local:_basedir}/IPA.jks
pool.default.ssl.truststore.password = changeit
[root@rhevm ~]#
Comment 4 Wolfram Richter 2017-06-06 17:50:16 UTC 
Bringing the discussion we started via email to BZ: I also want to confirm that reenabling STARTTLS with the default socket factory works as well. I.e. the only thing that prevents the scenario from working in my case is the resolver socket factory.
Comment 5 Ondra Machacek 2017-06-08 12:01:07 UTC 
Ok, it's starting to be more clear to me. Can you please share also the routing table? If I understand correctly if I resolve IP 192.168.104.11 of the IPA server then I will use eth2 and if I resolve IP 192.168.103.11 I will use eth1, etc, right?
Comment 6 Wolfram Richter 2017-06-09 22:10:42 UTC 
yes - name resolution seems to be random when using DNS

[root@rhevm ~]# ip r
default via 192.168.101.1 dev eth0  proto static  metric 100
192.168.101.0/24 dev eth0  proto kernel  scope link  src 192.168.101.12  metric 100
192.168.103.0/24 dev eth1  proto kernel  scope link  src 192.168.103.12  metric 100
192.168.104.0/24 dev eth2  proto kernel  scope link  src 192.168.104.12  metric 100
[root@rhevm ~]# ping ipa
PING ipa.hailstorm2.coe.muc.redhat.com (192.168.103.11) 56(84) bytes of data.
64 bytes from 192.168.103.11 (192.168.103.11): icmp_seq=1 ttl=64 time=0.202 ms
64 bytes from 192.168.103.11 (192.168.103.11): icmp_seq=2 ttl=64 time=0.296 ms
64 bytes from 192.168.103.11 (192.168.103.11): icmp_seq=3 ttl=64 time=0.315 ms
^C
--- ipa.hailstorm2.coe.muc.redhat.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.202/0.271/0.315/0.049 ms
[root@rhevm ~]# ping ipa
PING ipa.hailstorm2.coe.muc.redhat.com (192.168.104.11) 56(84) bytes of data.
64 bytes from 192.168.104.11 (192.168.104.11): icmp_seq=1 ttl=64 time=0.312 ms
64 bytes from 192.168.104.11 (192.168.104.11): icmp_seq=2 ttl=64 time=0.263 ms
64 bytes from 192.168.104.11 (192.168.104.11): icmp_seq=3 ttl=64 time=0.261 ms
^C
--- ipa.hailstorm2.coe.muc.redhat.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.261/0.278/0.312/0.030 ms
[root@rhevm ~]# ping ipa
PING ipa.hailstorm2.coe.muc.redhat.com (192.168.103.11) 56(84) bytes of data.
64 bytes from 192.168.103.11 (192.168.103.11): icmp_seq=1 ttl=64 time=0.417 ms
64 bytes from 192.168.103.11 (192.168.103.11): icmp_seq=2 ttl=64 time=0.284 ms
^C
--- ipa.hailstorm2.coe.muc.redhat.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.284/0.350/0.417/0.069 ms
[root@rhevm ~]# ping ipa
PING ipa.hailstorm2.coe.muc.redhat.com (192.168.101.11) 56(84) bytes of data.
64 bytes from 192.168.101.11 (192.168.101.11): icmp_seq=1 ttl=64 time=0.315 ms
64 bytes from 192.168.101.11 (192.168.101.11): icmp_seq=2 ttl=64 time=0.235 ms
^C
--- ipa.hailstorm2.coe.muc.redhat.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.235/0.275/0.315/0.040 ms
[root@rhevm ~]#
Comment 7 Martin Perina 2017-08-25 12:24:37 UTC 
Due to insufficient resources moving to 4.2
Comment 8 Ondra Machacek 2017-12-20 09:39:23 UTC 
This is done by design for resolver socket factory. If /etc/hosts have to be used, user have to use java socket factory type.
Comment 9 Ondra Machacek 2017-12-21 07:17:34 UTC 
In order to properly work with /etc/hosts you have to change following line in /etc/ovirt-engine/aaa/{profile}.properties:

pool.default.socketfactory.type = resolver

to

pool.default.socketfactory.type = java
Comment 10 Wolfram Richter 2017-12-21 07:42:24 UTC 
Actually using /etc/hosts would be a workaround; the core problem was that an LDAP with multiple NICs did not work properly if DNS returns all IP addresses.