Selon Petr Spacek <pspa...@redhat.com>:

> On 7.3.2014 14:16, artj...@free.fr 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 &#8211;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
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users
>


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

Reply via email to