Please do not drop the mailing list. On Аўт, 22 кас 2024, 정가희 wrote:
>What kind of traffic you are load-balancing? > >If your load-balancer only supports HTTP protocols, chances are that it >is unable to utilize Kerberos over HTTPS either, so it cannot access any >of IPA API end-points. It also means it cannot really validate IPA >server HTTP end-points are working beyond a simple 'yes, it responded, >with whatever status code'. First of all, As i mentioned, our load balancer only supports HTTP protocol **for healthcheck, And for traffic routing, the lb supports necessary protocols in IPA such as TCP, UDP. We're using external passthrough network load balancer of GCP and configure routing protocol like below. TCP 389, 636: LDAP/LDAPS 88, 464: kerberos UDP 464: kerberos And gcp team guide like below. https://cloud.google.com/load-balancing/docs/network/networklb-target-pools?hl=ko#health_checks "External passthrough Network Load Balancers rely on legacy HTTP health checks to determine instance health. Even if your service does not use HTTP, you must run a basic web server on each instance that the health check system can query. Legacy HTTPS health checks aren't supported for external passthrough Network Load Balancers and cannot be used with most other types of load balancers." https://cloud.google.com/load-balancing/docs/health-check-concepts#success-legacy-hc "If the response received by the legacy health check probe is HTTP 200 OK, the probe is considered successful. All other HTTP response codes, including a redirect (301, 302), are considered unhealthy." They guided that their NLB only support HTTP protocol for healthcheck and the healthcheck of NLB consider 'HTTP 200 OK' as healthy status. So, we're finding the HTTP API with status code. (heatlthy : 200 / unhealty : whatever except 200) Is there any API we can check the status of ipa servers? >curl -X POST \ > -H 'Accept-Language: en' > --data '{"method":"i18n_messages", "params":[[],{}]}' \ > --referer [1]https://ipa-server.hostname/ipa/ \ > [2]https://ipa-server.hostname/ipa/i18n_messages And when i ran the curl you mentioned, I got error message below. "curl: (60) SSL certificate problem: self signed certificate in certificate chain More details here: https://curl.haxx.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above."
You need to trust your own IPA CA on the client side where you run that curl command. You can learn more in the API documentation I provided (e.g. pass --cacert /etc/ipa/ca.crt to curl as well). For the rest -- as I said, FreeIPA team does not support load-balanced configurations. You are explicitly on your own. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland -- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
