Message-ID: I pinned this down: it's only an issue when running Keycloak behind an nginx proxy. My current stripped down nginx config: /etc/nginx/nginx.conf: include /usr/share/nginx/modules/*.conf; user nginx; error_log /var/log/nginx/error.log; pid /run/nginx.pid; worker_processes auto; worker_rlimit_nofile 30000; events { worker_connections 4096; multi_accept on; } http { log_format main '$http_host $remote_addr [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' '$request_time $upstream_response_time'; access_log /var/log/nginx/access.log main; server_tokens off; include /etc/nginx/mime.types; include /etc/nginx/conf.d/*.conf; } /etc/nginx/conf.d/keycloak.conf server { listen 443 ssl; server_name REDACTED; ssl_certificate /etc/pki/tls/certs/REDACTED.cer; ssl_certificate_key /etc/pki/tls/private/REDACTED.key; location / { proxy_http_version 1.1; proxy_pass http://localhost:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Port 443; } } Is there a recommended nginx configuration for Keycloak? On 14 July 2017 at 11:59, Stian Thorgersen wrote: > I've tried the same steps and we have tests that do the same steps. So > there's something more to it. You can create a JIRA sure, but we need to be > able to reproduce it. > > Ideal is that you can reproduce it with a fresh install of Keycloak > directly on your box with a fresh DB as well. > > On 14 July 2017 at 10:42, Tiemen Ruiten wrote: > >> Stian, does this help? Should I file a bug report? >> >> If anyone could give me some pointers for a workaround, that would also >> be much appreciated. >> >> >> On 12 July 2017 at 13:09, Tiemen Ruiten wrote: >> >>> OK, so I rolled a new Keycloak instance and it gives me the exact same >>> error. Reproducing is trivial: >>> >>> - login >>> - click Realm Settings >>> - click Email tab >>> - Fill in Host and From fields >>> - Hit 'Test connection' >>> >>> I can share the Ansible playbook I used to setup the VM privately if >>> you'd like. >>> >>> On 12 July 2017 at 11:43, Tiemen Ruiten wrote: >>> >>>> Hm, it's an almost vanilla Keycloak setup (however upgraded from 3.1.0 >>>> to 3.2.0), in fact the only changes in standalone.xml are related to the >>>> keystore and database. I'll see if I can setup another instance and >>>> reproduce there. >>>> >>>> On 11 July 2017 at 07:35, Stian Thorgersen wrote: >>>> >>>>> Tried to reproduce this, but can't and it's working just fine here. Do >>>>> you have steps to reproduce? >>>>> >>>>> On 10 July 2017 at 16:04, Tiemen Ruiten wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> I get the following error when hitting the 'Test connection' button >>>>>> on the >>>>>> email tab in Realm settings: >>>>>> >>>>>> 2017-07-10 15:55:27,316 INFO [org.jboss.as] (Controller Boot Thread) >>>>>> WFLYSRV0025: *Keycloak 3.2.0.Final (WildFly Core 2.0.10.Final)* >>>>>> started in >>>>>> >>>>>> 21731ms - Started 449 of 824 services (561 services are lazy, passive >>>>>> or >>>>>> on-demand) >>>>>> 2017-07-10 15:56:48,997 WARN [org.jboss.resteasy.resteasy_j >>>>>> axrs.i18n] >>>>>> (default task-11) RESTEASY002130: Failed to parse request.: >>>>>> javax.ws.rs.core.UriBuilderException: RESTEASY003330: Failed to >>>>>> create URI: >>>>>> https://kc.rdmedia.com/auth/admin/realms/master/testSMTPConnection/{ >>>>>> "port":null,"host":"mail.rdmedia.com >>>>>> ","ssl":"","starttls":"","auth":"","from":"account at rdmedia.com"} >>>>>> at >>>>>> org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildFromValu >>>>>> es(ResteasyUriBuilder.java:749) >>>>>> at >>>>>> org.jboss.resteasy.specimpl.ResteasyUriBuilder.build(Resteas >>>>>> yUriBuilder.java:721) >>>>>> at >>>>>> org.jboss.resteasy.spi.ResteasyUriInfo.initialize(ResteasyUr >>>>>> iInfo.java:58) >>>>>> at org.jboss.resteasy.spi.ResteasyUriInfo.(ResteasyUriInf >>>>>> o.java:53) >>>>>> at >>>>>> org.jboss.resteasy.plugins.server.servlet.ServletUtil.extrac >>>>>> tUriInfo(ServletUtil.java:41) >>>>>> at >>>>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDi >>>>>> spatcher.service(ServletContainerDispatcher.java:200) >>>>>> at >>>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>>> her.service(HttpServletDispatcher.java:56) >>>>>> at >>>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>>> her.service(HttpServletDispatcher.java:51) >>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>>> at >>>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(Se >>>>>> rvletHandler.java:85) >>>>>> at >>>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.d >>>>>> oFilter(FilterHandler.java:129) >>>>>> at >>>>>> org.keycloak.services.filters.KeycloakSessionServletFilter.d >>>>>> oFilter(KeycloakSessionServletFilter.java:90) >>>>>> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilte >>>>>> r.java:60) >>>>>> at >>>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.d >>>>>> oFilter(FilterHandler.java:131) >>>>>> at >>>>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(Fil >>>>>> terHandler.java:84) >>>>>> at >>>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHan >>>>>> dler.handleRequest(ServletSecurityRoleHandler.java:62) >>>>>> at >>>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handl >>>>>> eRequest(ServletDispatchingHandler.java:36) >>>>>> at >>>>>> org.wildfly.extension.undertow.security.SecurityContextAssoc >>>>>> iationHandler.handleRequest(SecurityContextAssociationHandle >>>>>> r.java:78) >>>>>> at >>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P >>>>>> redicateHandler.java:43) >>>>>> at >>>>>> io.undertow.servlet.handlers.security.SSLInformationAssociat >>>>>> ionHandler.handleRequest(SSLInformationAssociationHandler.java:131) >>>>>> at >>>>>> io.undertow.servlet.handlers.security.ServletAuthenticationC >>>>>> allHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >>>>>> at >>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P >>>>>> redicateHandler.java:43) >>>>>> at >>>>>> io.undertow.security.handlers.AbstractConfidentialityHandler >>>>>> .handleRequest(AbstractConfidentialityHandler.java:46) >>>>>> at >>>>>> io.undertow.servlet.handlers.security.ServletConfidentiality >>>>>> ConstraintHandler.handleRequest(ServletConfidentialityConstr >>>>>> aintHandler.java:64) >>>>>> at >>>>>> io.undertow.security.handlers.AuthenticationMechanismsHandle >>>>>> r.handleRequest(AuthenticationMechanismsHandler.java:60) >>>>>> at >>>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSes >>>>>> sionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >>>>>> at >>>>>> io.undertow.security.handlers.NotificationReceiverHandler.ha >>>>>> ndleRequest(NotificationReceiverHandler.java:50) >>>>>> at >>>>>> io.undertow.security.handlers.AbstractSecurityContextAssocia >>>>>> tionHandler.handleRequest(AbstractSecurityContextAssociation >>>>>> Handler.java:43) >>>>>> at >>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P >>>>>> redicateHandler.java:43) >>>>>> at >>>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHa >>>>>> ndler.handleRequest(JACCContextIdHandler.java:61) >>>>>> at >>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P >>>>>> redicateHandler.java:43) >>>>>> at >>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(P >>>>>> redicateHandler.java:43) >>>>>> at >>>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFir >>>>>> stRequest(ServletInitialHandler.java:284) >>>>>> at >>>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchR >>>>>> equest(ServletInitialHandler.java:263) >>>>>> at >>>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$00 >>>>>> 0(ServletInitialHandler.java:81) >>>>>> at >>>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleR >>>>>> equest(ServletInitialHandler.java:174) >>>>>> at io.undertow.server.Connectors.executeRootHandler(Connectors. >>>>>> java:202) >>>>>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchan >>>>>> ge.java:793) >>>>>> at >>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool >>>>>> Executor.java:1142) >>>>>> at >>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo >>>>>> lExecutor.java:617) >>>>>> at java.lang.Thread.run(Thread.java:748) >>>>>> Caused by: java.net.URISyntaxException: Illegal character in path at >>>>>> index >>>>>> 67: https://kc.rdmedia.com/auth/admin/realms/master/testSMTPConn >>>>>> ection/{ >>>>>> "port":null,"host":"mail.rdmedia.com >>>>>> ","ssl":"","starttls":"","auth":"","from":"account at rdmedia.com"} >>>>>> at java.net.URI$Parser.fail(URI.java:2848) >>>>>> at java.net.URI$Parser.checkChars(URI.java:3021) >>>>>> at java.net.URI$Parser.parseHierarchical(URI.java:3105) >>>>>> at java.net.URI$Parser.parse(URI.java:3053) >>>>>> at java.net.URI.(URI.java:588) >>>>>> at >>>>>> org.jboss.resteasy.specimpl.ResteasyUriBuilder.buildFromValu >>>>>> es(ResteasyUriBuilder.java:744) >>>>>> ... 40 more >>>>>> >>>>>> The 67th character is the slash after testSMTPConnection. Is this a >>>>>> bug >>>>>> and/or is there a workaround/fix? >>>>>> >>>>>> -- >>>>>> Tiemen Ruiten >>>>>> Systems Engineer >>>>>> R&D Media >>>>>> _______________________________________________ >>>>>> keycloak-user mailing list >>>>>> keycloak-user at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Tiemen Ruiten >>>> Systems Engineer >>>> R&D Media >>>> >>> >>> >>> >>> -- >>> Tiemen Ruiten >>> Systems Engineer >>> R&D Media >>> >> >> >> >> -- >> Tiemen Ruiten >> Systems Engineer >> R&D Media >> > > -- Tiemen Ruiten Systems Engineer R&D Media From mstrukel at redhat.com Thu Aug 3 05:36:03 2017 From: mstrukel at redhat.com (Marko Strukelj) Date: Thu, 3 Aug 2017 11:36:03 +0200 Subject: [keycloak-user] Clean Install with MySQL - Keycloak restarts itself due to liquibase errors - Docker Swarm environment In-Reply-To: References: Message-ID: There's your error in line 237 of the first log: 08:53:26,263 ERROR [org.keycloak.connections.jpa.updater.liquibase.conn. DefaultLiquibaseConnectionProvider] (ServerService Thread Pool -- 52) Change Set META-INF/jpa-changelog-1.7.0.xml::1.7.0::bburke at redhat.com failed. Error: Table 'KEYCLOAK_GROUP' already exists [Failed SQL: CREATE TABLE keycloak.KEYCLOAK_GROUP (ID VARCHAR(36) NOT NULL, NAME VARCHAR(255) NULL, PARENT_GROUP VARCHAR(36) NULL, REALM_ID VARCHAR(36) NULL)]: liquibase.exception.DatabaseException: Table 'KEYCLOAK_GROUP' already exists [Failed SQL: CREATE TABLE keycloak.KEYCLOAK_GROUP (ID VARCHAR(36) NOT NULL, NAME VARCHAR(255) NULL, PARENT_GROUP VARCHAR(36) NULL, REALM_ID VARCHAR(36) NULL)] The question now is why that table exists already if you started with an empty database. On Thu, Aug 3, 2017 at 11:22 AM, James Green wrote: > Unsure what I'm doing wrong here. Circumstance: we've spotted KeyCloak, > have reason to be interested, so are deploying an instance into our test > environment which happens to be Docker Swarm. > > Problem: The KeyCloak service is being restarted by Docker, presumably due > to a crash. The logs indicate it gets so far within a liquibase script then > fails. > > Here's the docker-compose.yml file that we are using for deployment > purposes: > > https://gist.github.com/jmkgreen/b79f95c3eca2eac3fb66c66d12017f07 > > Here's the log from MySQL: > > https://gist.github.com/jmkgreen/75b99fe98cf1d16a99895e78dae47cce > > Here's an initial log from KeyCloak: > > https://gist.github.com/jmkgreen/96285800949b5c4f62c31caa3eba27ef > > Here's an further log from KeyCloak once Docker has decided it needed to be > restarted: > > https://gist.github.com/jmkgreen/2051ab14e470d1d46dabcfdd519d5c42 > > As you can see, the MySQL server starts and is configured due to there > being no data already present. All looks good. KeyCloak eventually gets > connected to MySQL and begins using Liquibase to roll through transitions > but crashes (how?) and thus the container overall crashes forcing Docker to > restart, which merely happens over and over. > > FWIW I earlier created a StackOverflow post which has us at a _different_ > liquibase change but also failing: > > https://stackoverflow.com/questions/45466482/keycloak- > will-not-start-due-to-liquibase-changelog-error? > noredirect=1#comment77894983_45466482 > > What I've posted in the Gists above occurred after I shut everything down > and wiped the MySQL data directory of it's contents in full. > > An aside - we have multiple projects working within Swarm using stack > deployments with externally managed networks (as recommended by Docker) and > GlusterFS volumes without issue. In this particular case the only tangible > difference is the use of the latest MySQL version which other projects may > not be using. We also do not have experience of WildFly-based software. > > Any ideas what I've done wrong? > > Thanks, > > James > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > From james.mk.green at gmail.com Thu Aug 3 05:41:18 2017 From: james.mk.green at gmail.com (James Green) Date: Thu, 3 Aug 2017 10:41:18 +0100 Subject: [keycloak-user] Fwd: Clean Install with MySQL - Keycloak restarts itself due to liquibase errors - Docker Swarm environment In-Reply-To: References:

Message-ID: Gah! Intended for the list not the individual. ---------- Forwarded message ---------- From: James Green Date: 3 August 2017 at 10:40 Subject: Re: [keycloak-user] Clean Install with MySQL - Keycloak restarts itself due to liquibase errors - Docker Swarm environment To: Marko Strukelj I'm aware of the liquibase error, the bit I'm struggling with is how that can happen on an empty database. I might try to launch the database separately - could be a race condition between initialising the two applications (clutching at straws). On 3 August 2017 at 10:36, Marko Strukelj wrote: > There's your error in line 237 of the first log: > 08:53:26,263 ERROR [org.keycloak.connections.jpa. > updater.liquibase.conn.DefaultLiquibaseConnectionProvider] (ServerService > Thread Pool -- 52) Change Set META-INF/jpa-changelog-1.7.0.x > ml::1.7.0::bburke at redhat.com failed. Error: Table 'KEYCLOAK_GROUP' > already exists [Failed SQL: CREATE TABLE keycloak.KEYCLOAK_GROUP (ID > VARCHAR(36) NOT NULL, NAME VARCHAR(255) NULL, PARENT_GROUP VARCHAR(36) > NULL, REALM_ID VARCHAR(36) NULL)]: liquibase.exception.DatabaseException: > Table 'KEYCLOAK_GROUP' already exists [Failed SQL: CREATE TABLE > keycloak.KEYCLOAK_GROUP (ID VARCHAR(36) NOT NULL, NAME VARCHAR(255) NULL, > PARENT_GROUP VARCHAR(36) NULL, REALM_ID VARCHAR(36) NULL)] > > The question now is why that table exists already if you started with an > empty database. > > On Thu, Aug 3, 2017 at 11:22 AM, James Green > wrote: > >> Unsure what I'm doing wrong here. Circumstance: we've spotted KeyCloak, >> have reason to be interested, so are deploying an instance into our test >> environment which happens to be Docker Swarm. >> >> Problem: The KeyCloak service is being restarted by Docker, presumably due >> to a crash. The logs indicate it gets so far within a liquibase script >> then >> fails. >> >> Here's the docker-compose.yml file that we are using for deployment >> purposes: >> >> https://gist.github.com/jmkgreen/b79f95c3eca2eac3fb66c66d12017f07 >> >> Here's the log from MySQL: >> >> https://gist.github.com/jmkgreen/75b99fe98cf1d16a99895e78dae47cce >> >> Here's an initial log from KeyCloak: >> >> https://gist.github.com/jmkgreen/96285800949b5c4f62c31caa3eba27ef >> >> Here's an further log from KeyCloak once Docker has decided it needed to >> be >> restarted: >> >> https://gist.github.com/jmkgreen/2051ab14e470d1d46dabcfdd519d5c42 >> >> As you can see, the MySQL server starts and is configured due to there >> being no data already present. All looks good. KeyCloak eventually gets >> connected to MySQL and begins using Liquibase to roll through transitions >> but crashes (how?) and thus the container overall crashes forcing Docker >> to >> restart, which merely happens over and over. >> >> FWIW I earlier created a StackOverflow post which has us at a _different_ >> liquibase change but also failing: >> >> https://stackoverflow.com/questions/45466482/keycloak-will-n >> ot-start-due-to-liquibase-changelog-error?noredirect=1#comme >> nt77894983_45466482 >> >> What I've posted in the Gists above occurred after I shut everything down >> and wiped the MySQL data directory of it's contents in full. >> >> An aside - we have multiple projects working within Swarm using stack >> deployments with externally managed networks (as recommended by Docker) >> and >> GlusterFS volumes without issue. In this particular case the only tangible >> difference is the use of the latest MySQL version which other projects may >> not be using. We also do not have experience of WildFly-based software. >> >> Any ideas what I've done wrong? >> >> Thanks, >> >> James >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > From mstrukel at redhat.com Thu Aug 3 06:01:02 2017 From: mstrukel at redhat.com (Marko Strukelj) Date: Thu, 3 Aug 2017 12:01:02 +0200 Subject: [keycloak-user] Clean Install with MySQL - Keycloak restarts itself due to liquibase errors - Docker Swarm environment In-Reply-To: References:

Message-ID: Hmm, grasping for straws I would try a previous version of Keycloak to rule out the possibility of a regression, then I would try with a different version of MySql, then I would try locally running instance of Keycloak against containerised MySql ... On Thu, Aug 3, 2017 at 11:36 AM, Marko Strukelj wrote: > There's your error in line 237 of the first log: > 08:53:26,263 ERROR [org.keycloak.connections.jpa. > updater.liquibase.conn.DefaultLiquibaseConnectionProvider] (ServerService > Thread Pool -- 52) Change Set META-INF/jpa-changelog-1.7.0.x > ml::1.7.0::bburke at redhat.com failed. Error: Table 'KEYCLOAK_GROUP' > already exists [Failed SQL: CREATE TABLE keycloak.KEYCLOAK_GROUP (ID > VARCHAR(36) NOT NULL, NAME VARCHAR(255) NULL, PARENT_GROUP VARCHAR(36) > NULL, REALM_ID VARCHAR(36) NULL)]: liquibase.exception.DatabaseException: > Table 'KEYCLOAK_GROUP' already exists [Failed SQL: CREATE TABLE > keycloak.KEYCLOAK_GROUP (ID VARCHAR(36) NOT NULL, NAME VARCHAR(255) NULL, > PARENT_GROUP VARCHAR(36) NULL, REALM_ID VARCHAR(36) NULL)] > > The question now is why that table exists already if you started with an > empty database. > > On Thu, Aug 3, 2017 at 11:22 AM, James Green > wrote: > >> Unsure what I'm doing wrong here. Circumstance: we've spotted KeyCloak, >> have reason to be interested, so are deploying an instance into our test >> environment which happens to be Docker Swarm. >> >> Problem: The KeyCloak service is being restarted by Docker, presumably due >> to a crash. The logs indicate it gets so far within a liquibase script >> then >> fails. >> >> Here's the docker-compose.yml file that we are using for deployment >> purposes: >> >> https://gist.github.com/jmkgreen/b79f95c3eca2eac3fb66c66d12017f07 >> >> Here's the log from MySQL: >> >> https://gist.github.com/jmkgreen/75b99fe98cf1d16a99895e78dae47cce >> >> Here's an initial log from KeyCloak: >> >> https://gist.github.com/jmkgreen/96285800949b5c4f62c31caa3eba27ef >> >> Here's an further log from KeyCloak once Docker has decided it needed to >> be >> restarted: >> >> https://gist.github.com/jmkgreen/2051ab14e470d1d46dabcfdd519d5c42 >> >> As you can see, the MySQL server starts and is configured due to there >> being no data already present. All looks good. KeyCloak eventually gets >> connected to MySQL and begins using Liquibase to roll through transitions >> but crashes (how?) and thus the container overall crashes forcing Docker >> to >> restart, which merely happens over and over. >> >> FWIW I earlier created a StackOverflow post which has us at a _different_ >> liquibase change but also failing: >> >> https://stackoverflow.com/questions/45466482/keycloak-will- >> not-start-due-to-liquibase-changelog-error?noredirect=1# >> comment77894983_45466482 >> >> What I've posted in the Gists above occurred after I shut everything down >> and wiped the MySQL data directory of it's contents in full. >> >> An aside - we have multiple projects working within Swarm using stack >> deployments with externally managed networks (as recommended by Docker) >> and >> GlusterFS volumes without issue. In this particular case the only tangible >> difference is the use of the latest MySQL version which other projects may >> not be using. We also do not have experience of WildFly-based software. >> >> Any ideas what I've done wrong? >> >> Thanks, >> >> James >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > From james.mk.green at gmail.com Thu Aug 3 07:01:46 2017 From: james.mk.green at gmail.com (James Green) Date: Thu, 3 Aug 2017 12:01:46 +0100 Subject: [keycloak-user] Clean Install with MySQL - Keycloak restarts itself due to liquibase errors - Docker Swarm environment In-Reply-To: References:

Message-ID: Looks like a timeout causes an initial crash then the liquibase crashes begin: https://gist.github.com/jmkgreen/4a474f1b97d8cbea5bf77a6f475ec78c Unsure what is actually happening that gets timed out though - there is mention of an http interface but is that a repercussion of something deeper? Thanks, James On 3 August 2017 at 11:01, Marko Strukelj wrote: > Hmm, grasping for straws I would try a previous version of Keycloak to > rule out the possibility of a regression, then I would try with a different > version of MySql, then I would try locally running instance of Keycloak > against containerised MySql ... > > On Thu, Aug 3, 2017 at 11:36 AM, Marko Strukelj > wrote: > >> There's your error in line 237 of the first log: >> 08:53:26,263 ERROR [org.keycloak.connections.jpa. >> updater.liquibase.conn.DefaultLiquibaseConnectionProvider] >> (ServerService Thread Pool -- 52) Change Set META-INF/ >> jpa-changelog-1.7.0.xml::1.7.0::bburke at redhat.com failed. Error: Table >> 'KEYCLOAK_GROUP' already exists [Failed SQL: CREATE TABLE >> keycloak.KEYCLOAK_GROUP (ID VARCHAR(36) NOT NULL, NAME VARCHAR(255) NULL, >> PARENT_GROUP VARCHAR(36) NULL, REALM_ID VARCHAR(36) NULL)]: >> liquibase.exception.DatabaseException: Table 'KEYCLOAK_GROUP' already >> exists [Failed SQL: CREATE TABLE keycloak.KEYCLOAK_GROUP (ID VARCHAR(36) >> NOT NULL, NAME VARCHAR(255) NULL, PARENT_GROUP VARCHAR(36) NULL, REALM_ID >> VARCHAR(36) NULL)] >> >> The question now is why that table exists already if you started with an >> empty database. >> >> On Thu, Aug 3, 2017 at 11:22 AM, James Green >> wrote: >> >>> Unsure what I'm doing wrong here. Circumstance: we've spotted KeyCloak, >>> have reason to be interested, so are deploying an instance into our test >>> environment which happens to be Docker Swarm. >>> >>> Problem: The KeyCloak service is being restarted by Docker, presumably >>> due >>> to a crash. The logs indicate it gets so far within a liquibase script >>> then >>> fails. >>> >>> Here's the docker-compose.yml file that we are using for deployment >>> purposes: >>> >>> https://gist.github.com/jmkgreen/b79f95c3eca2eac3fb66c66d12017f07 >>> >>> Here's the log from MySQL: >>> >>> https://gist.github.com/jmkgreen/75b99fe98cf1d16a99895e78dae47cce >>> >>> Here's an initial log from KeyCloak: >>> >>> https://gist.github.com/jmkgreen/96285800949b5c4f62c31caa3eba27ef >>> >>> Here's an further log from KeyCloak once Docker has decided it needed to >>> be >>> restarted: >>> >>> https://gist.github.com/jmkgreen/2051ab14e470d1d46dabcfdd519d5c42 >>> >>> As you can see, the MySQL server starts and is configured due to there >>> being no data already present. All looks good. KeyCloak eventually gets >>> connected to MySQL and begins using Liquibase to roll through transitions >>> but crashes (how?) and thus the container overall crashes forcing Docker >>> to >>> restart, which merely happens over and over. >>> >>> FWIW I earlier created a StackOverflow post which has us at a _different_ >>> liquibase change but also failing: >>> >>> https://stackoverflow.com/questions/45466482/keycloak-will-n >>> ot-start-due-to-liquibase-changelog-error?noredirect=1#comme >>> nt77894983_45466482 >>> >>> What I've posted in the Gists above occurred after I shut everything down >>> and wiped the MySQL data directory of it's contents in full. >>> >>> An aside - we have multiple projects working within Swarm using stack >>> deployments with externally managed networks (as recommended by Docker) >>> and >>> GlusterFS volumes without issue. In this particular case the only >>> tangible >>> difference is the use of the latest MySQL version which other projects >>> may >>> not be using. We also do not have experience of WildFly-based software. >>> >>> Any ideas what I've done wrong? >>> >>> Thanks, >>> >>> James >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> > From john.bartko at drillinginfo.com Thu Aug 3 08:00:22 2017 From: john.bartko at drillinginfo.com (John Bartko) Date: Thu, 3 Aug 2017 12:00:22 +0000 Subject: [keycloak-user] Clean Install with MySQL - Keycloak restarts itself due to liquibase errors - Docker Swarm environment In-Reply-To: References:

, Message-ID: I *think* that the timeout referred to by this error: WFLYCTL0348: Timeout after [300] seconds can be increased by specifying -Djboss.as.management.blocking.timeout=### in the java options. I suspect that when a liquibase transaction gets abruptly stopped like that, subsequent attempts to use the same database would possibly result in "table already exist" errors. I experienced when performing a 1.9.x -> 2.5.x schema update the following transaction timeout also needed to be increased beyond its default value of 300: /subsystem=transactions:write-attribute(name=default-timeout,value=###) Hope that helps, - John Bartko ________________________________ From: keycloak-user-bounces at lists.jboss.org on behalf of James Green Sent: Thursday, August 3, 2017 6:01:46 AM To: Marko Strukelj Cc: keycloak-user Subject: Re: [keycloak-user] Clean Install with MySQL - Keycloak restarts itself due to liquibase errors - Docker Swarm environment Looks like a timeout causes an initial crash then the liquibase crashes begin: https://gist.github.com/jmkgreen/4a474f1b97d8cbea5bf77a6f475ec78c Unsure what is actually happening that gets timed out though - there is mention of an http interface but is that a repercussion of something deeper? Thanks, James On 3 August 2017 at 11:01, Marko Strukelj wrote: > Hmm, grasping for straws I would try a previous version of Keycloak to > rule out the possibility of a regression, then I would try with a different > version of MySql, then I would try locally running instance of Keycloak > against containerised MySql ... > > On Thu, Aug 3, 2017 at 11:36 AM, Marko Strukelj > wrote: > >> There's your error in line 237 of the first log: >> 08:53:26,263 ERROR [org.keycloak.connections.jpa. >> updater.liquibase.conn.DefaultLiquibaseConnectionProvider] >> (ServerService Thread Pool -- 52) Change Set META-INF/ >> jpa-changelog-1.7.0.xml::1.7.0::bburke at redhat.com failed. Error: Table >> 'KEYCLOAK_GROUP' already exists [Failed SQL: CREATE TABLE >> keycloak.KEYCLOAK_GROUP (ID VARCHAR(36) NOT NULL, NAME VARCHAR(255) NULL, >> PARENT_GROUP VARCHAR(36) NULL, REALM_ID VARCHAR(36) NULL)]: >> liquibase.exception.DatabaseException: Table 'KEYCLOAK_GROUP' already >> exists [Failed SQL: CREATE TABLE keycloak.KEYCLOAK_GROUP (ID VARCHAR(36) >> NOT NULL, NAME VARCHAR(255) NULL, PARENT_GROUP VARCHAR(36) NULL, REALM_ID >> VARCHAR(36) NULL)] >> >> The question now is why that table exists already if you started with an >> empty database. >> >> On Thu, Aug 3, 2017 at 11:22 AM, James Green >> wrote: >> >>> Unsure what I'm doing wrong here. Circumstance: we've spotted KeyCloak, >>> have reason to be interested, so are deploying an instance into our test >>> environment which happens to be Docker Swarm. >>> >>> Problem: The KeyCloak service is being restarted by Docker, presumably >>> due >>> to a crash. The logs indicate it gets so far within a liquibase script >>> then >>> fails. >>> >>> Here's the docker-compose.yml file that we are using for deployment >>> purposes: >>> >>> https://gist.github.com/jmkgreen/b79f95c3eca2eac3fb66c66d12017f07 >>> >>> Here's the log from MySQL: >>> >>> https://gist.github.com/jmkgreen/75b99fe98cf1d16a99895e78dae47cce >>> >>> Here's an initial log from KeyCloak: >>> >>> https://gist.github.com/jmkgreen/96285800949b5c4f62c31caa3eba27ef >>> >>> Here's an further log from KeyCloak once Docker has decided it needed to >>> be >>> restarted: >>> >>> https://gist.github.com/jmkgreen/2051ab14e470d1d46dabcfdd519d5c42 >>> >>> As you can see, the MySQL server starts and is configured due to there >>> being no data already present. All looks good. KeyCloak eventually gets >>> connected to MySQL and begins using Liquibase to roll through transitions >>> but crashes (how?) and thus the container overall crashes forcing Docker >>> to >>> restart, which merely happens over and over. >>> >>> FWIW I earlier created a StackOverflow post which has us at a _different_ >>> liquibase change but also failing: >>> >>> https://stackoverflow.com/questions/45466482/keycloak-will-n >>> ot-start-due-to-liquibase-changelog-error?noredirect=1#comme >>> nt77894983_45466482 >>> >>> What I've posted in the Gists above occurred after I shut everything down >>> and wiped the MySQL data directory of it's contents in full. >>> >>> An aside - we have multiple projects working within Swarm using stack >>> deployments with externally managed networks (as recommended by Docker) >>> and >>> GlusterFS volumes without issue. In this particular case the only >>> tangible >>> difference is the use of the latest MySQL version which other projects >>> may >>> not be using. We also do not have experience of WildFly-based software. >>> >>> Any ideas what I've done wrong? >>> >>> Thanks, >>> >>> James >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> > _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user From t.ruiten at rdmedia.com Thu Aug 3 08:07:38 2017 From: t.ruiten at rdmedia.com (Tiemen Ruiten) Date: Thu, 3 Aug 2017 14:07:38 +0200 Subject: [keycloak-user] illegal character in path when testing email setup In-Reply-To: References:

Message-ID: That's great news. Let me upgrade to 3.2.0 and get back. Deepak On Mon, Aug 7, 2017 at 3:31 PM, Hynek Mlnarik wrote: > This should have been fixed in Keycloak 3.2.0 (until then password > password reset link would get expired immediately after rendering; > since 3.2.0 that the link gets expired after actual password reset). > Further improvements are part of subsequent releases. > > --Hynek > > On Mon, Aug 7, 2017 at 11:47 AM, N. C. Deepak Ramesh > wrote: > > Hi All, > > > > We have deployed Keycloak 3.1.0.Final and everything works fine. However, > > password reset fails for all users using Outlook (Webmail/Client). When > > clicking on the password reset link the user gets the following message: > > > > *We're sorry, An error occurred, please login through your application > > again* > > > > I suspect this is the same issue as what is described on > > http://lists.jboss.org/pipermail/keycloak-user/2017-May/010586.html > > > > Is this fixed in later versions of Keycloak? Or if it is deemed not to > be a > > Keycloak bug are there are any recommended work-arounds for this user > base > > that is primarily on Outlook? How do other installations get around this > > problem? Any help would be greatly appreciated. > > > > Thanks in advance. > > > > Deepak > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > -- > > --Hynek > From thomas.delhomenie at gmail.com Mon Aug 7 09:03:20 2017 From: thomas.delhomenie at gmail.com (Thomas DELHOMENIE) Date: Mon, 7 Aug 2017 15:03:20 +0200 Subject: [keycloak-user] Migration from Picketlink IDM In-Reply-To: References: