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

Reply via email to