libre.sh/keycloak-scim
3
0
Fork 0
Code Issues 15 Pull requests Releases 1 Packages Activity Actions

KEYCLOAK-8300 Wildfly 14 upgrade

Browse source
This commit is contained in:
mposolda 2018-10-10 20:25:02 +02:00 committed by Marek Posolda
parent ba86243ffe
commit 692ccf82d6
5 changed files with 73 additions and 117 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

124
server_installation/topics/clustering/sticky-sessions.adoc
View file

@ -33,11 +33,16 @@ over the `AUTH_SESSION_ID` cookie. How exactly do this is dependent on your load
It is recommended on the {project_name} side to use the system property `jboss.node.name` during startup, with the value corresponding
to the name of your route. For example, `-Djboss.node.name=node1` will use `node1` to identify the route. This route will be used by
Infinispan caches and will be attached to the AUTH_SESSION_ID cookie when the node is the owner of the particular key. An example of the
start up command with this system property can be seen in <<_example-setup-with-mod-cluster,Mod Cluster Example>>.
Infinispan caches and will be attached to the AUTH_SESSION_ID cookie when the node is the owner of the particular key. Here is
an example of the start up command using this system property:
[source]
----
cd $RHSSO_NODE1
./standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=node1
----
Typically, the route name should be the same name as your backend host, but it is not necessary. You can use a different route name,
for example if you want to hide the host name of your {project_name} server inside your private network.
Typically in production environment the route name should use the same name as your backend host, but it is not required. You can
use a different route name. For example, if you want to hide the host name of your {project_name} server inside your private network.
==== Disable adding the route
@ -62,114 +67,3 @@ into your `RHSSO_HOME/standalone/configuration/standalone-ha.xml` file in the {p
</subsystem>
----
[[_example-setup-with-mod-cluster]]
==== Example cluster setup with mod_cluster
In the example, we will use link:http://mod-cluster.jboss.org/[Mod Cluster] as load balancer. One of the key features of mod cluster is, that there is not much
configuration on the load balancer side. Instead it requires support on the backend node side. Backend nodes communicate with the load balancer through the
dedicated protocol called MCMP and they notify loadbalancer about various events (eg. node joined or left cluster, new application was deployed etc).
Example setup will consist of the one {appserver_name} {appserver_version} load balancer node and two {project_name} nodes.
Clustering example require MULTICAST to be enabled on machine's loopback network interface. This can be done by running the following commands under root privileges (on Linux):
[source]
----
route add -net 224.0.0.0 netmask 240.0.0.0 dev lo
ifconfig lo multicast
----
===== Load Balancer Configuration
Unzip the {appserver_name} {appserver_version} server somewhere. Assumption is location `EAP_LB`
Edit `EAP_LB/standalone/configuration/standalone.xml` file. In the undertow subsystem add the mod_cluster configuration under filters like this:
[source,xml,subs="attributes+"]
----
<subsystem xmlns="{subsystem_undertow_xml_urn}">
...
<filters>
...
<mod-cluster name="modcluster" advertise-socket-binding="modcluster"
advertise-frequency="${modcluster.advertise-frequency:2000}"
management-socket-binding="http" enable-http2="true"/>
</filters>
----
and `filter-ref` under `default-host` like this:
[source,xml]
----
<host name="default-host" alias="localhost">
...
<filter-ref name="modcluster"/>
</host>
----
Then under `socket-binding-group` add this group:
[source,xml]
----
<socket-binding name="modcluster" port="0"
multicast-address="${jboss.modcluster.multicast.address:224.0.1.105}"
multicast-port="23364"/>
----
Save the file and run the server:
[source]
----
cd $WILDFLY_LB/bin
./standalone.sh
----
===== Backend node configuration
Unzip the {project_name} server distribution to some location. Assuming location is `RHSSO_NODE1` .
Edit `RHSSO_NODE1/standalone/configuration/standalone-ha.xml` and configure datasource against the shared database.
See <<_rdbms-setup-checklist, Database chapter >> for more details.
In the undertow subsystem, add the `session-config` under the `servlet-container` element:
[source,xml]
----
<servlet-container name="default">
<session-cookie name="AUTH_SESSION_ID" http-only="true" />
...
</servlet-container>
----
WARNING: Use the `session-config` only with the mod_cluster load balancer. In other cases, configure sticky session over the `AUTH_SESSION_ID` cookie directly in a load balancer.
Then you can configure `proxy-address-forwarding` as described in the chapter <<_setting-up-a-load-balancer-or-proxy, Load Balancer >> .
Note that mod_cluster uses AJP connector by default, so you need to configure that one.
That's all as mod_cluster is already configured.
The node name of the {project_name} can be detected automatically based on the hostname of current server. However for more fine grained control,
it is recommended to use system property `jboss.node.name` to specify the node name directly. It is especially useful in case that you test with 2 backend nodes on
same physical server etc. So you can run the startup command like this:
[source]
----
cd $RHSSO_NODE1
./standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=node1
----
Configure the second backend server in same way and run with different port offset and node name.
[source]
----
cd $RHSSO_NODE2
./standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=200 -Djboss.node.name=node2
----
Access the server on `http://localhost:8080/auth` . Creation of admin user is possible just from local address and without load balancer (proxy) access,
so you first need to access backend node directly on `http://localhost:8180/auth` to create admin user.
WARNING: When using mod_cluster you should always access the cluster through the load balancer and not directly through the backend node.

41
server_installation/topics/operating-mode/crossdc.adoc
View file

@ -400,6 +400,9 @@ In production you will likely need to have a separate database server in every d
<remote-store cache="work" remote-servers="remote-cache" passivation="false" fetch-state="false" purge="false" preload="false" shared="true">
<property name="rawValues">true</property>
<property name="marshaller">org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory</property>
ifeval::[{project_product}==true]
<property name="protocolVersion">2.6</property>
endif::[]
</remote-store>
</replicated-cache>
```
@ -412,6 +415,9 @@ In production you will likely need to have a separate database server in every d
<remote-store cache="sessions" remote-servers="remote-cache" passivation="false" fetch-state="false" purge="false" preload="false" shared="true">
<property name="rawValues">true</property>
<property name="marshaller">org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory</property>
ifeval::[{project_product}==true]
<property name="protocolVersion">2.6</property>
endif::[]
</remote-store>
</distributed-cache>
```
@ -424,6 +430,9 @@ In production you will likely need to have a separate database server in every d
<remote-store cache="offlineSessions" remote-servers="remote-cache" passivation="false" fetch-state="false" purge="false" preload="false" shared="true">
<property name="rawValues">true</property>
<property name="marshaller">org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory</property>
ifeval::[{project_product}==true]
<property name="protocolVersion">2.6</property>
endif::[]
</remote-store>
</distributed-cache>
@ -431,6 +440,9 @@ In production you will likely need to have a separate database server in every d
<remote-store cache="clientSessions" remote-servers="remote-cache" passivation="false" fetch-state="false" purge="false" preload="false" shared="true">
<property name="rawValues">true</property>
<property name="marshaller">org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory</property>
ifeval::[{project_product}==true]
<property name="protocolVersion">2.6</property>
endif::[]
</remote-store>
</distributed-cache>
@ -438,6 +450,9 @@ In production you will likely need to have a separate database server in every d
<remote-store cache="offlineClientSessions" remote-servers="remote-cache" passivation="false" fetch-state="false" purge="false" preload="false" shared="true">
<property name="rawValues">true</property>
<property name="marshaller">org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory</property>
ifeval::[{project_product}==true]
<property name="protocolVersion">2.6</property>
endif::[]
</remote-store>
</distributed-cache>
@ -445,6 +460,9 @@ In production you will likely need to have a separate database server in every d
<remote-store cache="loginFailures" remote-servers="remote-cache" passivation="false" fetch-state="false" purge="false" preload="false" shared="true">
<property name="rawValues">true</property>
<property name="marshaller">org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory</property>
ifeval::[{project_product}==true]
<property name="protocolVersion">2.6</property>
endif::[]
</remote-store>
</distributed-cache>
@ -454,6 +472,9 @@ In production you will likely need to have a separate database server in every d
<remote-store cache="actionTokens" remote-servers="remote-cache" passivation="false" fetch-state="false" purge="false" preload="true" shared="true">
<property name="rawValues">true</property>
<property name="marshaller">org.keycloak.cluster.infinispan.KeycloakHotRodMarshallerFactory</property>
ifeval::[{project_product}==true]
<property name="protocolVersion">2.6</property>
endif::[]
</remote-store>
</distributed-cache>
```
@ -862,3 +883,23 @@ which is caused by cache items not being properly expired. In that case, update
+
you can just ignore them. To avoid the warning, the caches on {jdgserver_name} server side could be changed to transactional caches, but this is not recommended as it can cause some
other issues caused by the bug https://issues.jboss.org/browse/ISPN-9323. So for now, the warnings just need to be ignored.
* If you see errors in the {jdgserver_name} server log like:
+
```
12:08:32,921 ERROR [org.infinispan.server.hotrod.CacheDecodeContext] (HotRod-ServerWorker-7-11) ISPN005003: Exception reported: org.infinispan.server.hotrod.InvalidMagicIdException: Error reading magic byte or message id: 7
at org.infinispan.server.hotrod.HotRodDecoder.readHeader(HotRodDecoder.java:184)
at org.infinispan.server.hotrod.HotRodDecoder.decodeHeader(HotRodDecoder.java:133)
at org.infinispan.server.hotrod.HotRodDecoder.decode(HotRodDecoder.java:92)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248)
```
+
and you see some similar errors in the {project_name} log, it can indicate that there are incompatible versions of the HotRod protocol being used.
This is likely happen when you try to use {project_name} with the JDG 7.2 server or an old version of the Infinispan server. It
will help if you add the `protocolVersion` property as an additional property to the `remote-store` element in the {project_name}
configuration file. For example:
+
```xml
<property name="protocolVersion">2.6</property>
```

2
topics/templates/document-attributes-community.adoc
View file

@ -86,7 +86,7 @@
:appserver_loadbalancer_name: {appserver_name} {appserver_version} Documentation
:jdgserver_name: Infinispan
:jdgserver_version: 9.2.4
:jdgserver_version: 9.3.1
:jdgserver_crossdcdocs_link: https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.2/html/administration_and_configuration_guide/set_up_cross_datacenter_replication
:fuseVersion: JBoss Fuse 6.3.0 Rollup 5

2
topics/templates/document-attributes-product.adoc
View file

@ -105,7 +105,7 @@ endif::[]
:jdgserver_name: JDG
:jdgserver_version: 7.2.0
:jdgserver_version: 7.2.3
:jdgserver_crossdcdocs_link: https://access.redhat.com/documentation/en-us/red_hat_jboss_data_grid/7.2/html/administration_and_configuration_guide/set_up_cross_datacenter_replication
:fuseVersion: JBoss Fuse 6.3.0 Rollup 5

21
upgrading/topics/keycloak/changes.adoc
View file

@ -41,6 +41,27 @@ due to changes in the id format of the applications. If you run into an error sa
was not found in the directory, you will have to register the client application again in the
https://account.live.com/developers/applications/create[Microsoft Application Registration] portal to obtain a new application id.
==== Upgrade to Wildfly 14
The {project_name} server was upgraded to use Wildfly 14 as the underlying container. This does not directly involve any
specific {project_name} server functionality, but there are few changes related to the migration, which worth mentioning.
Dependency updates::
The dependencies were updated to the versions used by Wildfly 14 server. For example, Infinispan is now 9.3.1.Final.
Configuration changes::
There are few configuration changes in the `standalone(-ha).xml` and `domain.xml` files. You should follow the <<_install_new_version>>
section to handle the migration of configuration files automatically.
Cross-Datacenter Replication changes::
* You will need to upgrade {jdgserver_name} server to version {jdgserver_version}. The older version may still work, but it is
not guaranteed as we don't test it anymore.
ifeval::[{project_product}==true]
* There is a need to add `protocolVersion` property with the value `2.6` to the configuration of the `remote-store` element in the
{project_name} configuration. This is required as there is a need to downgrade the version of HotRod protocol to be compatible
with the version used by {jdgserver_name} {jdgserver_version}.
endif::[]
=== Migrating to 4.4.0
==== Upgrade to Wildfly 13