Selon Petr Spacek <[email protected]>: > On 7.3.2014 14:16, [email protected] wrote: > > I want to install ipa server with a replica. The replica has 2 NICs : the > ipa > > server is connected on the first interface and all the clients are > connected on > > the second interface. The two networks are completely separated, 2 subnets > and > > not routed. > I'm curious - what is the reasoning behind this? :-)
The goal is to separate the administration flux and the userland flux. > > > I'am wondering if this kind of configuration is supported with IPA. > > > > Ipa server has been installed with success on the first interface: > > > > > > First, I prepared the replica on its first interface name (that which is on > the > > same network as the ipa server), install it with success. In this case the > > ipa-client-install fails; > > See below ==== errors ipacli1 ==== > See my reply below :-) > > > Second, I prepared the replica on its second interface name (that which is > on > > the same network as the ipa client). This case is worst I'm even not able > to > > install the replica. The installation fails with the following errors , see > > below ==== errors iparpl2 ==== > I'm not sure I understand what you did. > > You have installed the replica on one machine and then you have tried to > install the replica again on the same machine? I guess I have misunderstood > something ... No, to test it and show the difference between installation of my replica, I use a 2nd one (iparpl2). > > > Thanks a lot for your help. > > > > ===================================== errors ipacli1 > > ===================================== > > - messages in screen or std output: > > Skip iparpl1.blue.mydomain: cannot verify if this is an IPA server > > Failed to verify that iparpl1.blue.mydomain is an IPA Server. > > > > - messages in log /var/log/ipaclient-install.log: > > 2014-03-07T12:20:24Z DEBUG [LDAP server check] > > 2014-03-07T12:20:24Z DEBUG Verifying that iparpl1.blue.mydomain (realm > None) is > > an IPA server > > 2014-03-07T12:20:24Z DEBUG Init LDAP connection to: iparpl1.blue.mydomain > > 2014-03-07T12:20:29Z DEBUG wait_for_open_ports: iparpl1.blue.mydomain [389] > > timeout 10 > > 2014-03-07T12:20:34Z DEBUG Error checking LDAP: [Errno -2] Name or service > not > > known > The problem is that your client can't resolve name of the server. I agree and it's showed below by ldapsearch command. > > > 2014-03-07T12:20:34Z WARNING Skip iparpl1.blue.mydomain: cannot verify if > this > > is an IPA server > > > > - check in iparpl1 > > [root@iparpl1 ~]# ipactl status > > Directory Service: RUNNING > > krb5kdc Service: RUNNING > > kadmin Service: RUNNING > > ipa_memcached Service: RUNNING > > httpd Service: RUNNING > > pki-tomcatd Service: RUNNING > > ipa-otpd Service: RUNNING > > ipa: INFO: The ipactl command was successful > > > > [root@iparpl1 ~]# ldapsearch -x -H ldap://iparpl1.blue.mydomain:389 -W -ZZ > > ldap_start_tls: Connect error (-11) > > additional info: TLS error -8157:Certificate extension not found. > > [root@iparpl1 ~]# ldapsearch -x -H ldap://iparpl1.mydomain:389 -W –ZZ > > OK > > > > ===================================== errors iparpl2 > > ===================================== > > - messages in screen or std output > > KO normal because the master doesn't connect to replica in second interface > > Connection from replica to master is OK. > > Start listening on required ports for remote master check > > Get credentials to log in to remote master > > Check SSH connection to remote master > > Execute check on remote master > > Check connection from master to remote replica 'iparpl2.green.mydomain': > > Directory Service: Unsecure port (389): FAILED > > Directory Service: Secure port (636): FAILED > > Kerberos KDC: TCP (88): FAILED > > Kerberos KDC: UDP (88): WARNING > > Kerberos Kpasswd: TCP (464): FAILED > > Kerberos Kpasswd: UDP (464): WARNING > > HTTP Server: Unsecure port (80): FAILED > > HTTP Server: Secure port (443): FAILED > > The following UDP ports could not be verified as open: 88, 464 > > This can happen if they are already bound to an application > > and ipa-replica-conncheck cannot attach own UDP responder. > > > > Remote master check failed with following error message(s): > > Warning: Permanently added 'ipasrv.mydomain,110.0.0.2' (ECDSA) to the list > of > > known hosts. > > Port check failed! Inaccessible port(s): 389 (TCP), 636 (TCP), 88 (TCP), > 464 > > (TCP), 80 (TCP), 443 (TCP) > > Connection check failed! > > Please fix your network settings according to error messages above. > > If the check results are not valid it can be skipped with --skip-conncheck > > parameter. > > My guess is that you use different name for each interface, right? I'm afraid > that it can't work, FreeIPA doesn't support that. Right about using different name for each interface. I would like to be sure that this architecture is not supported by FreeIPA. > > Generally, setups like this do not work very well when Kerberos is in the > mix. I think so !!! > > You can try to add both IP addresses to A record for the multi-homed replica > but then you will depend on failover between those two IP addresses etc... You're right with round robin included in bind. I can recompile bind packages without round robin but my goal is to be very close to the standard distribution. > > -- > Petr^2 Spacek > > _______________________________________________ > Freeipa-users mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/freeipa-users > _______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
