Hi, I will balance with IP persistance so I think there won't be any mixing as long as that "used" server is online.
2015-03-06 19:16 GMT+01:00 Dmitri Pal <d...@redhat.com>: > On 03/06/2015 11:05 AM, Matt . wrote: >> >> OK, understood. >> >> But when a webservice does execute a command (from scripting) to a SVR >> record and the first is not reacable, would it try to do it again or >> will handle DNS this in front of it ? >> >> I do a kinit against an IPA server using a keytab after I first >> checked if the user was able to auth himself using his ldap >> credentials, if so, this kinit exec is fired and I do some CURL stuff >> to the IPA server. >> >> That's why I wanted a loadbalancer, the loadbalancer sees if a server >> is down and doesn't even try to direct any of the commands to it... >> I'm not sure if the SRV will handle this well when doing these command >> from PHP for an example. Building in extra checks in front could be >> done but it not ideal as a loadbalancer can handle such things much >> better. > > > OK, this makes things much more clear. Thanks for the explanation. > Rob. What is our failover logic for API? > > For CLI we use a negotiation and then we store a cookie so as long as the > whole conversation goes to the same server you should be fine. I do not > think you need to re-encrypt the traffic at load balancer and thus have a > cert there then if you can enforce the use of the same server in this case. > > The issue I anticipate is with Kerberos. I think you should not load balance > the Kerberos traffic, only the API commands starting with the negotiation. > > Rob does that make sense for you? > > >> >> Thanks! >> >> Cheers, >> >> Matt >> >> 2015-03-06 16:41 GMT+01:00 Dmitri Pal <d...@redhat.com>: >>> >>> On 03/06/2015 10:24 AM, Matt . wrote: >>>> >>>> Hi, >>>> >>>> I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, >>>> SRV won't fit here sorry to say. >>>> >>>> I auth users, so their keytab should be the same between two masters I >>>> believe ? >>> >>> >>> Each entity in Kerberos exchange has its own identity and key. >>> If you send a ticket that is destined to service A instead to service B >>> it >>> would not work unless they share the same keys and identity. Sharinf same >>> keys and identities between the servers just would not work with IPA. >>> Keep in mind that IPA clients and server need to work and fail over if >>> you >>> do not have any load balancers and this is the common case. You are >>> trying >>> to add one where it is really not needed creating overhead for yourself. >>> >>> >>> >>>> In that case... I need to add the altnames to the certs, but I'm not >>>> 100% there in step 6 >>>> >>>> Thanks again! >>>> >>>> Cheers, >>>> >>>> Matthijs >>>> >>>> 2015-03-06 16:16 GMT+01:00 Petr Spacek <pspa...@redhat.com>: >>>>> >>>>> On 6.3.2015 15:39, Matt . wrote: >>>>>> >>>>>> I have 2 IPA servers where I kinit to and post to the api using >>>>>> curl/json. >>>>> >>>>> If we are talking purely about scripting, you can use IPA Python API. >>>>> It >>>>> will >>>>> handle fail over for you even without any load balancer. That would be >>>>> easiest >>>>> way. >>>>> >>>>>> As I need redundancy and don't want to have it script managed, but one >>>>>> central point where I can tal to I use a loadbalancer. >>>>> >>>>> Well, if you can control clients then the easiest and most universal >>>>> way >>>>> is to >>>>> use DNS SRV records and add failover logic to clients. That solution >>>>> works >>>>> even when servers are geographically distributed/in different networks >>>>> and >>>>> does not have single point of failure (the load balancer). >>>>> >>>>>> As I connect to the loadbalancer using DNAT, so the client IP is known >>>>>> on the IPA server because this is needed for the http service >>>>>> principals I need to add the loadbalancer hostname to my IPA server >>>>>> and make it as an ALT name to it's Certificate. >>>>>> >>>>>> As the users are the same on both servers I would asume i can use a >>>>>> keytab for a user against both servers from my clients. >>>>> >>>>> I'm talking about keytabs on the FreeIPA servers - services running on >>>>> IPA >>>>> server have their own keytabs too. Every service on every server has >>>>> own >>>>> keytab with different key. >>>>> >>>>> You need to talk with Simo or some other Kerberos guru about >>>>> possibility >>>>> of >>>>> sharing keytabs between IPA services. >>>>> >>>>>> Does this make it more clear ? >>>>> >>>>> I'm still not sure if you want to have human users too or just API >>>>> clients. >>>>> >>>>> Petr^2 Spacek >>>>> >>>>>> 2015-03-06 15:31 GMT+01:00 Petr Spacek <pspa...@redhat.com>: >>>>>>> >>>>>>> On 6.3.2015 15:13, Matt . wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> But as the user is the same, I could use the same keytab for each >>>>>>>> ipa >>>>>>>> server ? >>>>>>>> >>>>>>>> I need to use the API indeed, so need to issue the http service. >>>>>>>> >>>>>>>> Any other options ? >>>>>>> >>>>>>> I do not really understand your use case. Could you describe it in >>>>>>> detail, please? >>>>>>> >>>>>>> Petr^2 Spacek >>>>>>> >>>>>>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek <pspa...@redhat.com>: >>>>>>>>> >>>>>>>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>>>>>>> >>>>>>>>>> I'm figuring out how to regenerate the webserver certificates so I >>>>>>>>>> can >>>>>>>>>> use a loadbalancer in front of my ipa servers. >>>>>>>>> >>>>>>>>> Are you talking about FreeIPA web interface? It is technically >>>>>>>>> possible to use >>>>>>>>> load-balancer but it will be really hacky. You would have to solve >>>>>>>>> certificates and also distribute shared keytabs and so on. >>>>>>>>> >>>>>>>>> I would recommend you to use "something" which issues HTTP redirect >>>>>>>>> to ipa >>>>>>>>> server 1/2/3/4/5 according to current state instead of using >>>>>>>>> classical load >>>>>>>>> balancer on the network level. Normal HTTP redirect will not force >>>>>>>>> you to mess >>>>>>>>> with certs and keytabs. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Petr^2 Spacek >>>>> >>>>> >>>>> -- >>>>> Petr Spacek @ Red Hat >>> >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go to http://freeipa.org for more info on the project > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
