[keycloak-user] Fwd: Keycloak 3.2.1 Final not working in cluster

Thu Nov 16 03:44:57 EST 2017

Hello Stian/Keycloak User group,

Appreciate your help on this.
As mentioned earlier, system is currently in productions and it would be
long and lenghtly process for us to bring the higher version into live env.

Though I checked the HA config from 3.4 Final version and did not see much
difference with the existing HA configuration present into our env.

Would you please give a another look at our configuration and suggest a
solution.

Thanks,
Mahendra Sonawale.
+91 9130775865

On Thu, Nov 16, 2017 at 12:47 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Try using a fresh install of Keycloak with no modifications at all and try
> running:
>
> # bin/standalone.sh --server-config=standalone-ha.xml -b <IP> -bprivate
> <IP>
>
> On 15 November 2017 at 17:19, mahendra sonawale <mahson1 at gmail.com> wrote:
>
>> Hello Stian,
>>
>> Thank you for your reply.
>> I have gone through the links and reference links as well.
>> Trying Keycloak cluster with multicast over private interface and on
>> separate testing, messages are getting through with
>> (McastReceiverTest, McastSenderTest)
>> Tried my best to accommodate needed things into cluster environment and
>> as per my understanding looks same which is present the given guidelines .
>> Appreciate your help in identifying if anything is missing in config
>> I have been stuck here from couple of weeks :(
>>
>> Have shared whatever set up we have in mail trail.
>>
>> Thanks,
>> Mahendra Sonawale.
>>
>>
>> On Wed, Nov 15, 2017 at 8:25 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Did you check the docs? Specifically http://www.keyclo
>>> ak.org/docs/latest/server_installation/index.html#multicast-
>>> network-setup
>>>
>>> On 15 November 2017 at 14:38, mahendra sonawale <mahson1 at gmail.com>
>>> wrote:
>>>
>>>> Hello Cedric/Keycloak User comm,
>>>>
>>>> Sorry for getting back late over this. my set-up needs Admin team`s
>>>> intervention to change the broadcast value hence the delay in response.
>>>>
>>>> I got /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts value changed to 0
>>>>
>>>> And also tested the multicast set-up message test with
>>>> "McastReceiverTest"
>>>> and "McastSenderTest" which works fine.
>>>>
>>>> BUT KEYCLOAK is still NOT working in cluster. I get auto logged out.
>>>>
>>>> PFA the HA file which I am using in my configuration.
>>>>
>>>> IP addresses are dummy.
>>>> Node 1 : 1.2.3.4
>>>> Node 2 : 1.2.3.5
>>>>
>>>> This all I tried.
>>>> 1) Start command - nohup ./bin/standalone.sh
>>>> --server-config=standalone-ha.xml -b $HOSTNAME -u 230.0.0.4 &
>>>> 2) Tried to run both the nodes with public as well as private interface
>>>> -
>>>> but no luck.
>>>> 3) I have hardware load balancer where SSL terminates. so domain will
>>>> communicate to the both the nodes in round robin and both nodes should
>>>> be
>>>>
>>>> 4) PFB the HTTPD Conf
>>>>
>>>> -------------------------
>>>> LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
>>>> LoadModule remoteip_module modules/mod_remoteip.so
>>>>
>>>> ProxyPreserveHost On
>>>> LimitRequestFieldSize 163840
>>>> LimitRequestLine 163840
>>>>
>>>> #<VirtualHost _default_:80>
>>>>  ServerName rapid.gi-de.com:443
>>>>  ErrorLog /opt/keycloak/fiam_error_log
>>>>  CustomLog /opt/keycloak/fiam_access_log combined
>>>>  LogLevel warn
>>>>
>>>> RequestHeader set X-Forwarded-Proto "https"
>>>>
>>>> <Proxy https://abc.com/* >
>>>>  RewriteEngine on
>>>>  RewriteCond %{REQUEST_FILENAME} !-f
>>>>  RewriteCond %{REQUEST_FILENAME} !-d
>>>>  # not rewrite css, js and images
>>>>  RewriteCond %{REQUEST_URI} !\.(?:css|js|map|jpe?g|gif|png)$ [NC]
>>>>  RewriteRule ^(.*)$ /auth [NC,L,QSA]
>>>> #Options -Indexes FollowSymLinks
>>>>  AllowOverride None
>>>>  Order allow,deny
>>>>  Allow from all
>>>> </Proxy>
>>>>
>>>>
>>>> ProxyPass /auth http://1.2.3.4:8080/auth
>>>> ProxyPassReverse /auth http://1.2.3.4:8080/auth
>>>>
>>>> ------------------
>>>> And on 2nd node only proxy pass has change in IP address as 1.2.3.5
>>>>
>>>> 6) Server logs:
>>>> 2017-11-15 14:03:06,255 INFO
>>>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC
>>>> service
>>>> thread 1-2) ISPN000094: Received new cluster view for channel keycloak:
>>>> [keycloak1.accounts.intern|0] (1) [keycloak1.accounts.intern]
>>>> 2017-11-15 14:03:06,256 INFO
>>>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC
>>>> service
>>>> thread 1-7) ISPN000094: Received new cluster view for channel hibernate:
>>>> [keycloak1.accounts.intern|0] (1) [keycloak1.accounts.intern]
>>>> 2017-11-15 14:03:06,259 INFO
>>>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC
>>>> service
>>>> thread 1-8) ISPN000094: Received new cluster view for channel web:
>>>> [keycloak1.accounts.intern|0] (1) [keycloak1.accounts.intern]
>>>> 2017-11-15 14:03:06,263 INFO
>>>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC
>>>> service
>>>> thread 1-1) ISPN000094: Received new cluster view for channel server:
>>>> [keycloak1.accounts.intern|0] (1) [keycloak1.accounts.intern]
>>>> 2017-11-15 14:03:06,263 INFO
>>>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC
>>>> service
>>>> thread 1-7) ISPN000079: Channel hibernate local address is
>>>> keycloak1.accounts.intern, physical addresses are [1.2.3.4:55200]
>>>> 2017-11-15 14:03:06,264 INFO
>>>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC
>>>> service
>>>> thread 1-1) ISPN000079: Channel server local address is
>>>> keycloak1.accounts.intern, physical addresses are [1.2.3.4:55200]
>>>> 2017-11-15 14:03:06,264 INFO
>>>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC
>>>> service
>>>> thread 1-3) ISPN000094: Received new cluster view for channel ejb:
>>>> [keycloak1.accounts.intern|0] (1) [keycloak1.accounts.intern]
>>>> 2017-11-15 14:03:06,265 INFO
>>>> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC
>>>> service
>>>> thread 1-3) ISPN000079: Channel ejb local address is
>>>> keycloak1.accounts.intern, physical addresses are [1.2.3.4:55200]
>>>>
>>>>
>>>>
>>>>
>>>> ProxyPass /auth http://1.2.3.4:8080/auth
>>>> ProxyPassReverse /auth http://1.2.3.4:8080/auth
>>>>
>>>> Thanks,
>>>> Mahendra
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Nov 9, 2017 at 6:35 PM, Cédric Couralet <
>>>> cedric.couralet at gmail.com>
>>>> wrote:
>>>>
>>>> > 2017-11-09 12:34 GMT+01:00 mahendra sonawale <mahson1 at gmail.com>:
>>>> > > (You can look for the value in
>>>> > > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts, it should be 0)
>>>> > >
>>>> > > In our production linux env the value is 1 --  does that really
>>>> affect??
>>>> > > and would that be the only cause?
>>>> > >
>>>> >
>>>> > Yes, it is important. At least for us, changing this value to 0 was
>>>> > enough to have a working cluster.
>>>> > As I understand it, the value 1 is a protection against DOS but, in
>>>> > the case of Keycloak prevents each node to discover the others. In a
>>>> > controlled environment (as recommended in the keycloak docs), I see no
>>>> > problem enabling it.
>>>> >
>>>> > I'm far for expert, so maybe someone will have a better idea.
>>>> >
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>>
>>
>