The add-user.sh script overwrites the one that comes distributed with Wildfly/EAP. Is this intentional? To set up domain mode on multiple servers you need to be able to add an admin user to the domain and share the secret with slave hosts so they can connect to the domain controller. Can I rename add-user.sh to something else? keycloak-add-user.sh - or - sso-add-user.sh - or - ????

I don't think we should do this. We are going to need to leverage the JBoss EAP/Wildfly documentation on how to manage the server. We can't be overriding commands that exist for JBoss. There is going to be a lot of confusion. On 4/22/2016 11:56 AM, Marek Posolda wrote: > AFAIK it is intentional on standalone keycloak server. If you use > parameter "--container" it will delegate to the wildfly impl, so you > have the possibility to add the "wildfly" admin. Not sure if this is > properly documented... > > With overlay, we don't overwrite the default wildfly "add-user.sh" > but instead we add our own "add-user-keycloak.sh". > > Marek > > > On 22/04/16 17:45, Bill Burke wrote: >> The add-user.sh script overwrites the one that comes distributed with >> Wildfly/EAP. Is this intentional? To set up domain mode on multiple >> servers you need to be able to add an admin user to the domain and >> share the >> secret with slave hosts so they can connect to the domain controller. >> >> Can I rename add-user.sh to something else? >> >> keycloak-add-user.sh >> - or - >> sso-add-user.sh >> - or - >> >> ???? >> >

On 4/22/2016 3:57 PM, Marek Posolda wrote: > That's the question... > > For server distribution, we also have our stuff ( keycloak subsystem, > datasource, infinispan etc) directly declared in "standalone.xml". On > the other hand, for overlay distribution, we don't want to directly > update default "standalone.xml", so we are adding our own > "standalone-keycloak.xml". Isn't it quite similar thing? > Product will not have the overlay distribution. > We can do the same for overlay and server distribution, so never edit > default wildfly files ( standalone.xml , add-user.sh), but always use > our own versions with "-keycloak" suffix. Advantage is more > consistent. However people will need to always start keycloak server > with "./standalone.sh -c standalone-keycloak.xml" then. Doesn't it > sucks from the usability perspective? > The overlay exists because we can't distribute EAP within community. Keycloak should be run as a separate server, so, IMO, -keycloak.xml files should go away and overwrite standalone.xml, standalone-ha.xml and domain.xml > I honestly don't know what's the best way regarding usability. AFAIK > this was decided on mailing lists couple of months ago, but don't > remember the exact threads...:/ > I'm pretty adamant about this. There will be a huge amount of confusion if we don't make this separation. Wildfly/JBoss and Keycloak are hard enough to configure as it is. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Do you care about usability at all? Not everything can fit into nice little boxes all the time. This is going to be extremely confusing for users. I ran into it myself as I thought the jboss add-user.sh script was overwritten by our distribution script by mistake. *OF COURSE* we should have a separate add-user.sh script. Even when, hopefully, JBoss can delegate to Keycloak in maybe 7.1. If we are going to leverage the JBoss platform, and this means the JBoss documentation too, every management function that exists in JBoss should be available in Keycloak and *WORK THE SAME WAY*. If we don't change this, we're going to get a ton of support questions that say: "Why doesn't add-user.sh work?" On 4/23/2016 1:29 AM, Stian Thorgersen wrote: > >In the future we need to secure the underlying WildFly with rhsso. In >which case our add-user will add users for both Keycloak and WildFly/EAP. > >IMO there's going to be confusion until the above is solved no matter what >we do. We'll need to document this whichever way we do it. Options are >stay with what we have or rename our script. My vote goes to keep as is >and document it. Then hopefully by 7.1 we can secure the WildFly bits so >the problem goes away. With the other option (rename ours) there will be a >problem once WildFly bits are secured by Keycloak as now the wf add-user >script should no longer be used and completely removed at which point we >should then rename it back. So in the long run sticking with how it is >today is ideal. It's also way to late making changes now. BTW this has >been around for months. > >On 22 Apr 2016 22:14, "Bill Burke" <bburke(a)redhat.com ><mailto:bburke@redhat.com>> wrote: > > > > On 4/22/2016 3:57 PM, Marek Posolda wrote: > > That's the question... > > > > For server distribution, we also have our stuff ( keycloak > subsystem, > > datasource, infinispan etc) directly declared in > "standalone.xml". On > > the other hand, for overlay distribution, we don't want to directly > > update default "standalone.xml", so we are adding our own > > "standalone-keycloak.xml". Isn't it quite similar thing? > > > > Product will not have the overlay distribution. > > > We can do the same for overlay and server distribution, so never > edit > > default wildfly files ( standalone.xml , add-user.sh), but > always use > > our own versions with "-keycloak" suffix. Advantage is more > > consistent. However people will need to always start keycloak server > > with "./standalone.sh -c standalone-keycloak.xml" then. Doesn't it > > sucks from the usability perspective? > > > > The overlay exists because we can't distribute EAP within community. > Keycloak should be run as a separate server, so, IMO, -keycloak.xml > files should go away and overwrite standalone.xml, > standalone-ha.xml and > domain.xml > > > I honestly don't know what's the best way regarding usability. AFAIK > > this was decided on mailing lists couple of months ago, but don't > > remember the exact threads...:/ > > > > I'm pretty adamant about this. There will be a huge amount of > confusion > if we don't make this separation. Wildfly/JBoss and Keycloak are hard > enough to configure as it is. > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

_______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

We had the same kind of problem in WildFly a few years ago. Everyone was used to starting the server with run.sh. But we needed to change that to differentiate between standalone.sh and domain.sh. So we made run.bat just print out a "This is deprecated. Here is what you need to do...." message. It's not a perfect solution, but we could do the same thing with add-user.sh and tell them to use either add-user-keycloak.sh or add-user-eap.sh. At least you wouldn't get any support questions. On 4/23/2016 9:06 AM, Ilya Rum wrote: > Hello! > > As a new member of keycloak QA team I recently had to set up some > clustering with domain mode. > I was really confused when add-user.sh did not add user to jboss but > rather created the keycloak-add-user.json. > The worst thing was that I couldn't find any docs on adding user to > underlying eap at all. > Had to read the add-user.sh itself to find out what was happening. > Even if it remains as it is, it really should be at least mentioned in > the docs :) > > Have a nice day! > Ilya Rum. > > On Sat, Apr 23, 2016 at 08:48:15AM -0400, Bill Burke wrote: >> Do you care about usability at all? Not everything can fit into nice little >> boxes all the time. This is going to be extremely confusing for users. I >> ran into it myself as I thought the jboss add-user.sh script was overwritten >> by our distribution script by mistake. *OF COURSE* we should have a >> separate add-user.sh script. Even when, hopefully, JBoss can delegate to >> Keycloak in maybe 7.1. If we are going to leverage the JBoss platform, and >> this means the JBoss documentation too, every management function that >> exists in JBoss should be available in Keycloak and *WORK THE SAME WAY*. If >> we don't change this, we're going to get a ton of support questions that >> say: "Why doesn't add-user.sh work?" >> >> >> >> On 4/23/2016 1:29 AM, Stian Thorgersen wrote: >>> In the future we need to secure the underlying WildFly with rhsso. In >>> which case our add-user will add users for both Keycloak and WildFly/EAP. >>> >>> IMO there's going to be confusion until the above is solved no matter what >>> we do. We'll need to document this whichever way we do it. Options are >>> stay with what we have or rename our script. My vote goes to keep as is >>> and document it. Then hopefully by 7.1 we can secure the WildFly bits so >>> the problem goes away. With the other option (rename ours) there will be a >>> problem once WildFly bits are secured by Keycloak as now the wf add-user >>> script should no longer be used and completely removed at which point we >>> should then rename it back. So in the long run sticking with how it is >>> today is ideal. It's also way to late making changes now. BTW this has >>> been around for months. >>> >>> On 22 Apr 2016 22:14, "Bill Burke" <bburke(a)redhat.com >>> <mailto:bburke@redhat.com>> wrote: >>> >>> >>> >>> On 4/22/2016 3:57 PM, Marek Posolda wrote: >>> > That's the question... >>> > >>> > For server distribution, we also have our stuff ( keycloak >>> subsystem, >>> > datasource, infinispan etc) directly declared in >>> "standalone.xml". On >>> > the other hand, for overlay distribution, we don't want to directly >>> > update default "standalone.xml", so we are adding our own >>> > "standalone-keycloak.xml". Isn't it quite similar thing? >>> > >>> >>> Product will not have the overlay distribution. >>> >>> > We can do the same for overlay and server distribution, so never >>> edit >>> > default wildfly files ( standalone.xml , add-user.sh), but >>> always use >>> > our own versions with "-keycloak" suffix. Advantage is more >>> > consistent. However people will need to always start keycloak server >>> > with "./standalone.sh -c standalone-keycloak.xml" then. Doesn't it >>> > sucks from the usability perspective? >>> > >>> >>> The overlay exists because we can't distribute EAP within community. >>> Keycloak should be run as a separate server, so, IMO, -keycloak.xml >>> files should go away and overwrite standalone.xml, >>> standalone-ha.xml and >>> domain.xml >>> >>> > I honestly don't know what's the best way regarding usability. AFAIK >>> > this was decided on mailing lists couple of months ago, but don't >>> > remember the exact threads...:/ >>> > >>> >>> I'm pretty adamant about this. There will be a huge amount of >>> confusion >>> if we don't make this separation. Wildfly/JBoss and Keycloak are hard >>> enough to configure as it is. >>> >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

We had the same kind of problem in WildFly a few years ago. Everyone was used to starting the server with run.sh. But we needed to change that to differentiate between standalone.sh and domain.sh. So we made run.bat just print out a "This is deprecated. Here is what you need to do...." message. It's not a perfect solution, but we could do the same thing with add-user.sh and tell them to use either add-user-keycloak.sh or add-user-eap.sh. At least you wouldn't get any support questions. On 4/23/2016 9:06 AM, Ilya Rum wrote: > Hello! > > As a new member of keycloak QA team I recently had to set up some > clustering with domain mode. > I was really confused when add-user.sh did not add user to jboss but > rather created the keycloak-add-user.json. > The worst thing was that I couldn't find any docs on adding user to > underlying eap at all. > Had to read the add-user.sh itself to find out what was happening. > Even if it remains as it is, it really should be at least mentioned in > the docs :) > > Have a nice day! > Ilya Rum. > > On Sat, Apr 23, 2016 at 08:48:15AM -0400, Bill Burke wrote: >> Do you care about usability at all? Not everything can fit into nice little >> boxes all the time. This is going to be extremely confusing for users. I >> ran into it myself as I thought the jboss add-user.sh script was overwritten >> by our distribution script by mistake. *OF COURSE* we should have a >> separate add-user.sh script. Even when, hopefully, JBoss can delegate to >> Keycloak in maybe 7.1. If we are going to leverage the JBoss platform, and >> this means the JBoss documentation too, every management function that >> exists in JBoss should be available in Keycloak and *WORK THE SAME WAY*. If >> we don't change this, we're going to get a ton of support questions that >> say: "Why doesn't add-user.sh work?" >> >> >> >> On 4/23/2016 1:29 AM, Stian Thorgersen wrote: >>> In the future we need to secure the underlying WildFly with rhsso. In >>> which case our add-user will add users for both Keycloak and WildFly/EAP. >>> >>> IMO there's going to be confusion until the above is solved no matter what >>> we do. We'll need to document this whichever way we do it. Options are >>> stay with what we have or rename our script. My vote goes to keep as is >>> and document it. Then hopefully by 7.1 we can secure the WildFly bits so >>> the problem goes away. With the other option (rename ours) there will be a >>> problem once WildFly bits are secured by Keycloak as now the wf add-user >>> script should no longer be used and completely removed at which point we >>> should then rename it back. So in the long run sticking with how it is >>> today is ideal. It's also way to late making changes now. BTW this has >>> been around for months. >>> >>> On 22 Apr 2016 22:14, "Bill Burke" <bburke(a)redhat.com >>> <mailto:bburke@redhat.com>> wrote: >>> >>> >>> >>> On 4/22/2016 3:57 PM, Marek Posolda wrote: >>> > That's the question... >>> > >>> > For server distribution, we also have our stuff ( keycloak >>> subsystem, >>> > datasource, infinispan etc) directly declared in >>> "standalone.xml". On >>> > the other hand, for overlay distribution, we don't want to directly >>> > update default "standalone.xml", so we are adding our own >>> > "standalone-keycloak.xml". Isn't it quite similar thing? >>> > >>> >>> Product will not have the overlay distribution. >>> >>> > We can do the same for overlay and server distribution, so never >>> edit >>> > default wildfly files ( standalone.xml , add-user.sh), but >>> always use >>> > our own versions with "-keycloak" suffix. Advantage is more >>> > consistent. However people will need to always start keycloak server >>> > with "./standalone.sh -c standalone-keycloak.xml" then. Doesn't it >>> > sucks from the usability perspective? >>> > >>> >>> The overlay exists because we can't distribute EAP within community. >>> Keycloak should be run as a separate server, so, IMO, -keycloak.xml >>> files should go away and overwrite standalone.xml, >>> standalone-ha.xml and >>> domain.xml >>> >>> > I honestly don't know what's the best way regarding usability. AFAIK >>> > this was decided on mailing lists couple of months ago, but don't >>> > remember the exact threads...:/ >>> > >>> >>> I'm pretty adamant about this. There will be a huge amount of >>> confusion >>> if we don't make this separation. Wildfly/JBoss and Keycloak are hard >>> enough to configure as it is. >>> >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On 4/24/2016 2:58 PM, Bill Burke wrote: > Completely different. standalone.sh and domain.sh are completely new > run.sh variants and run.sh disappeared. Nope. If there was no domain.sh we would have kept run.sh. standalone.sh does exactly the same thing run.sh used to do. Furthermore, run.sh didn't disappear. It just prints a helpful message. The situation here is exactly the same. If there was no "keycloak" add-user we would have kept the old one. Bill, I agree that the current situation is confusing. Stian, I agree that having both "add-user.sh" and "add-user-keycloak.sh" is also confusing. The WildFly solution isn't pretty, but at least it isn't confusing. I suppose you could make the whole thing prettier by slapping some extra UI into the unified version. Let it prompt the user for what he really wants to do, etc., etc. > > add-user.sh is the same script as the old. and you've already had two > Red Hat people scratching their heads wondering what happened to > add-user.sh. Were you including me? I complained about this several weeks ago, so perhaps you can make that three Red Hat people. I agree that it's a problem. > > On 4/23/2016 3:04 PM, Stan Silvert wrote: >> We had the same kind of problem in WildFly a few years ago. Everyone >> was used to starting the server with run.sh. But we needed to change >> that to differentiate between standalone.sh and domain.sh. So we made >> run.bat just print out a "This is deprecated. Here is what you need to >> do...." message. >> >> It's not a perfect solution, but we could do the same thing with >> add-user.sh and tell them to use either add-user-keycloak.sh or >> add-user-eap.sh. At least you wouldn't get any support questions. >> >> On 4/23/2016 9:06 AM, Ilya Rum wrote: >>> Hello! >>> >>> As a new member of keycloak QA team I recently had to set up some >>> clustering with domain mode. >>> I was really confused when add-user.sh did not add user to jboss but >>> rather created the keycloak-add-user.json. >>> The worst thing was that I couldn't find any docs on adding user to >>> underlying eap at all. >>> Had to read the add-user.sh itself to find out what was happening. >>> Even if it remains as it is, it really should be at least mentioned in >>> the docs :) >>> >>> Have a nice day! >>> Ilya Rum. >>> >>> On Sat, Apr 23, 2016 at 08:48:15AM -0400, Bill Burke wrote: >>>> Do you care about usability at all? Not everything can fit into nice little >>>> boxes all the time. This is going to be extremely confusing for users. I >>>> ran into it myself as I thought the jboss add-user.sh script was overwritten >>>> by our distribution script by mistake. *OF COURSE* we should have a >>>> separate add-user.sh script. Even when, hopefully, JBoss can delegate to >>>> Keycloak in maybe 7.1. If we are going to leverage the JBoss platform, and >>>> this means the JBoss documentation too, every management function that >>>> exists in JBoss should be available in Keycloak and *WORK THE SAME WAY*. If >>>> we don't change this, we're going to get a ton of support questions that >>>> say: "Why doesn't add-user.sh work?" >>>> >>>> >>>> >>>> On 4/23/2016 1:29 AM, Stian Thorgersen wrote: >>>>> In the future we need to secure the underlying WildFly with rhsso. In >>>>> which case our add-user will add users for both Keycloak and WildFly/EAP. >>>>> >>>>> IMO there's going to be confusion until the above is solved no matter what >>>>> we do. We'll need to document this whichever way we do it. Options are >>>>> stay with what we have or rename our script. My vote goes to keep as is >>>>> and document it. Then hopefully by 7.1 we can secure the WildFly bits so >>>>> the problem goes away. With the other option (rename ours) there will be a >>>>> problem once WildFly bits are secured by Keycloak as now the wf add-user >>>>> script should no longer be used and completely removed at which point we >>>>> should then rename it back. So in the long run sticking with how it is >>>>> today is ideal. It's also way to late making changes now. BTW this has >>>>> been around for months. >>>>> >>>>> On 22 Apr 2016 22:14, "Bill Burke" <bburke(a)redhat.com >>>>> <mailto:bburke@redhat.com>> wrote: >>>>> >>>>> >>>>> >>>>> On 4/22/2016 3:57 PM, Marek Posolda wrote: >>>>> > That's the question... >>>>> > >>>>> > For server distribution, we also have our stuff ( keycloak >>>>> subsystem, >>>>> > datasource, infinispan etc) directly declared in >>>>> "standalone.xml". On >>>>> > the other hand, for overlay distribution, we don't want to directly >>>>> > update default "standalone.xml", so we are adding our own >>>>> > "standalone-keycloak.xml". Isn't it quite similar thing? >>>>> > >>>>> >>>>> Product will not have the overlay distribution. >>>>> >>>>> > We can do the same for overlay and server distribution, so never >>>>> edit >>>>> > default wildfly files ( standalone.xml , add-user.sh), but >>>>> always use >>>>> > our own versions with "-keycloak" suffix. Advantage is more >>>>> > consistent. However people will need to always start keycloak server >>>>> > with "./standalone.sh -c standalone-keycloak.xml" then. Doesn't it >>>>> > sucks from the usability perspective? >>>>> > >>>>> >>>>> The overlay exists because we can't distribute EAP within community. >>>>> Keycloak should be run as a separate server, so, IMO, -keycloak.xml >>>>> files should go away and overwrite standalone.xml, >>>>> standalone-ha.xml and >>>>> domain.xml >>>>> >>>>> > I honestly don't know what's the best way regarding usability. AFAIK >>>>> > this was decided on mailing lists couple of months ago, but don't >>>>> > remember the exact threads...:/ >>>>> > >>>>> >>>>> I'm pretty adamant about this. There will be a huge amount of >>>>> confusion >>>>> if we don't make this separation. Wildfly/JBoss and Keycloak are hard >>>>> enough to configure as it is. >>>>> >>>>> >>>>> -- >>>>> Bill Burke >>>>> JBoss, a division of Red Hat >>>>> http://bill.burkecentral.com >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev(a)lists.jboss.org <mailto: keycloak-dev(a)lists.jboss.org&gt; >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On 25/04/16 09:35, Stian Thorgersen wrote: Seems like the majority (that being everyone besides me) would like to have the script renamed. So let's go for it, but first I have two questions: Btv. I didn't suggest to rename, but keep as is. But always when people run "add-user.sh" without "--container", there will be be a big warning similar to: "You are adding Keycloak admin, but not Wildfly admin!!! If you want to add Wildfly admin use the option --container" This should solve both your (a) and (b) and remove most of confusions IMO. And in the future version, when keycloak and wildfly admin will be same thing, we can still use same "add-user.sh" script without need to rename, remove or add any new script. We will just remove the warning and possibly support for "--container" option. Marek a) What should it be called (it can't be add-user-keycloak.sh as then it wouldn't make sense in product)? add-user-sso.sh is an idea, but is it clear that's adding "Keycloak admin console" users b) Will we not get a bunch of people asking "I added a user with add-user, but still can't login to Keycloak admin console"? Do we have a solution for that? On 25 April 2016 at 03:41, Stan Silvert <ssilvert(a)redhat.com&gt; wrote: > > On 4/24/2016 2:58 PM, Bill Burke wrote: > > Completely different. standalone.sh and domain.sh are completely new > > run.sh variants and run.sh disappeared. > Nope. If there was no domain.sh we would have kept run.sh. > standalone.sh does exactly the same thing run.sh used to do. > Furthermore, run.sh didn't disappear. It just prints a helpful message. > > The situation here is exactly the same. If there was no "keycloak" > add-user we would have kept the old one. > > Bill, I agree that the current situation is confusing. Stian, I agree > that having both "add-user.sh" and "add-user-keycloak.sh" is also > confusing. > > The WildFly solution isn't pretty, but at least it isn't confusing. > > I suppose you could make the whole thing prettier by slapping some extra > UI into the unified version. Let it prompt the user for what he really > wants to do, etc., etc. > > > > add-user.sh is the same script as the old. and you've already had two > > Red Hat people scratching their heads wondering what happened to > > add-user.sh. > Were you including me? I complained about this several weeks ago, so > perhaps you can make that three Red Hat people. I agree that it's a > problem. > > > > On 4/23/2016 3:04 PM, Stan Silvert wrote: > >> We had the same kind of problem in WildFly a few years ago. Everyone > >> was used to starting the server with run.sh. But we needed to change > >> that to differentiate between standalone.sh and domain.sh. So we made > >> run.bat just print out a "This is deprecated. Here is what you need to > >> do...." message. > >> > >> It's not a perfect solution, but we could do the same thing with > >> add-user.sh and tell them to use either add-user-keycloak.sh or > >> add-user-eap.sh. At least you wouldn't get any support questions. > >> > >> On 4/23/2016 9:06 AM, Ilya Rum wrote: > >>> Hello! > >>> > >>> As a new member of keycloak QA team I recently had to set up some > >>> clustering with domain mode. > >>> I was really confused when add-user.sh did not add user to jboss but > >>> rather created the keycloak-add-user.json. > >>> The worst thing was that I couldn't find any docs on adding user to > >>> underlying eap at all. > >>> Had to read the add-user.sh itself to find out what was happening. > >>> Even if it remains as it is, it really should be at least mentioned in > >>> the docs :) > >>> > >>> Have a nice day! > >>> Ilya Rum. > >>> > >>> On Sat, Apr 23, 2016 at 08:48:15AM -0400, Bill Burke wrote: > >>>> Do you care about usability at all? Not everything can fit into > nice little > >>>> boxes all the time. This is going to be extremely confusing for > users. I > >>>> ran into it myself as I thought the jboss add-user.sh script was > overwritten > >>>> by our distribution script by mistake. *OF COURSE* we should have a > >>>> separate add-user.sh script. Even when, hopefully, JBoss can > delegate to > >>>> Keycloak in maybe 7.1. If we are going to leverage the JBoss > platform, and > >>>> this means the JBoss documentation too, every management function > that > >>>> exists in JBoss should be available in Keycloak and *WORK THE SAME > WAY*. If > >>>> we don't change this, we're going to get a ton of support questions > that > >>>> say: "Why doesn't add-user.sh work?" > >>>> > >>>> > >>>> > >>>> On 4/23/2016 1:29 AM, Stian Thorgersen wrote: > >>>>> In the future we need to secure the underlying WildFly with rhsso. > In > >>>>> which case our add-user will add users for both Keycloak and > WildFly/EAP. > >>>>> > >>>>> IMO there's going to be confusion until the above is solved no > matter what > >>>>> we do. We'll need to document this whichever way we do it. Options > are > >>>>> stay with what we have or rename our script. My vote goes to keep > as is > >>>>> and document it. Then hopefully by 7.1 we can secure the WildFly > bits so > >>>>> the problem goes away. With the other option (rename ours) there > will be a > >>>>> problem once WildFly bits are secured by Keycloak as now the wf > add-user > >>>>> script should no longer be used and completely removed at which > point we > >>>>> should then rename it back. So in the long run sticking with how it > is > >>>>> today is ideal. It's also way to late making changes now. BTW this > has > >>>>> been around for months. > >>>>> > >>>>> On 22 Apr 2016 22:14, "Bill Burke" <bburke(a)redhat.com > >>>>> <mailto: <bburke@redhat.com&gt;bburke(a)redhat.com&gt;&gt; wrote: > >>>>> > >>>>> > >>>>> > >>>>> On 4/22/2016 3:57 PM, Marek Posolda wrote: > >>>>> > That's the question... > >>>>> > > >>>>> > For server distribution, we also have our stuff ( keycloak > >>>>> subsystem, > >>>>> > datasource, infinispan etc) directly declared in > >>>>> "standalone.xml". On > >>>>> > the other hand, for overlay distribution, we don't want to > directly > >>>>> > update default "standalone.xml", so we are adding our own > >>>>> > "standalone-keycloak.xml". Isn't it quite similar thing? > >>>>> > > >>>>> > >>>>> Product will not have the overlay distribution. > >>>>> > >>>>> > We can do the same for overlay and server distribution, so > never > >>>>> edit > >>>>> > default wildfly files ( standalone.xml , add-user.sh), but > >>>>> always use > >>>>> > our own versions with "-keycloak" suffix. Advantage is more > >>>>> > consistent. However people will need to always start > keycloak server > >>>>> > with "./standalone.sh -c standalone-keycloak.xml" then. > Doesn't it > >>>>> > sucks from the usability perspective? > >>>>> > > >>>>> > >>>>> The overlay exists because we can't distribute EAP within > community. > >>>>> Keycloak should be run as a separate server, so, IMO, > -keycloak.xml > >>>>> files should go away and overwrite standalone.xml, > >>>>> standalone-ha.xml and > >>>>> domain.xml > >>>>> > >>>>> > I honestly don't know what's the best way regarding > usability. AFAIK > >>>>> > this was decided on mailing lists couple of months ago, but > don't > >>>>> > remember the exact threads...:/ > >>>>> > > >>>>> > >>>>> I'm pretty adamant about this. There will be a huge amount of > >>>>> confusion > >>>>> if we don't make this separation. Wildfly/JBoss and Keycloak > are hard > >>>>> enough to configure as it is. > >>>>> > >>>>> > >>>>> -- > >>>>> Bill Burke > >>>>> JBoss, a division of Red Hat > >>>>> http://bill.burkecentral.com > >>>>> > >>>>> _______________________________________________ > >>>>> keycloak-dev mailing list > >>>>> keycloak-dev(a)lists.jboss.org <mailto: > keycloak-dev(a)lists.jboss.org&gt; > >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>> > >>>> -- > >>>> Bill Burke > >>>> JBoss, a division of Red Hat > >>>> http://bill.burkecentral.com > >>>> > >>>> _______________________________________________ > >>>> keycloak-dev mailing list > >>>> keycloak-dev(a)lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev(a)lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ keycloak-dev mailing listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev

+1. That's the "prettier" UI option I was talking about. On 4/25/2016 4:56 AM, Stian Thorgersen wrote: > +1 To what Marek is proposing > > I'd suggest a slightly more mellow tone though. Rather than the > current message (which is a bit rubbish): > > Added 'k' to > '/home/st/tmp/keycloak-1.9.2.Final/standalone/configuration/keycloak-add-user.json', > restart server to load user > > We could do: > > Keycloak admin user added, please restart server to make the user > available. To add user for jboss-cli please run "add-user" with > "--container" option. > > Other improvements we could do are: > > * "--container" description should be "Add user to jboss-cli. For > usage use '--container --help'" > * When add-user is run without options it currently says 'Option: > -u.. is required' it should instead display help text (--help) and > the help text should have a paragraph on the bottom stating how the > user is added, that the server needs to be reloaded and also how to > add a user to jboss-cli. > > I'm happy to incorporate the above changes if that's what we agree on. > > On 25 April 2016 at 10:45, Marek Posolda <mposolda(a)redhat.com > <mailto:mposolda@redhat.com>> wrote: > > On 25/04/16 09:35, Stian Thorgersen wrote: >> Seems like the majority (that being everyone besides me) would >> like to have the script renamed. So let's go for it, but first I >> have two questions: > Btv. I didn't suggest to rename, but keep as is. But always when > people run "add-user.sh" without "--container", there will be be > a big warning similar to: > > "You are adding Keycloak admin, but not Wildfly admin!!! If you > want to add Wildfly admin use the option --container" > > This should solve both your (a) and (b) and remove most of > confusions IMO. And in the future version, when keycloak and > wildfly admin will be same thing, we can still use same > "add-user.sh" script without need to rename, remove or add any > new script. We will just remove the warning and possibly support > for "--container" option. > > > Marek > > >> >> a) What should it be called (it can't be add-user-keycloak.sh as >> then it wouldn't make sense in product)? add-user-sso.sh is an >> idea, but is it clear that's adding "Keycloak admin console" users >> b) Will we not get a bunch of people asking "I added a user with >> add-user, but still can't login to Keycloak admin console"? Do >> we have a solution for that? >> >> On 25 April 2016 at 03:41, Stan Silvert <ssilvert(a)redhat.com >> <mailto:ssilvert@redhat.com>> wrote: >> >> >> On 4/24/2016 2:58 PM, Bill Burke wrote: >> > Completely different. standalone.sh and domain.sh are >> completely new >> > run.sh variants and run.sh disappeared. >> Nope. If there was no domain.sh we would have kept run.sh. >> standalone.sh does exactly the same thing run.sh used to do. >> Furthermore, run.sh didn't disappear. It just prints a >> helpful message. >> >> The situation here is exactly the same. If there was no >> "keycloak" >> add-user we would have kept the old one. >> >> Bill, I agree that the current situation is confusing. >> Stian, I agree >> that having both "add-user.sh" and "add-user-keycloak.sh" is >> also confusing. >> >> The WildFly solution isn't pretty, but at least it isn't >> confusing. >> >> I suppose you could make the whole thing prettier by >> slapping some extra >> UI into the unified version. Let it prompt the user for >> what he really >> wants to do, etc., etc. >> > >> > add-user.sh is the same script as the old. and you've >> already had two >> > Red Hat people scratching their heads wondering what >> happened to >> > add-user.sh. >> Were you including me? I complained about this several >> weeks ago, so >> perhaps you can make that three Red Hat people. I agree >> that it's a >> problem. >> > >> > On 4/23/2016 3:04 PM, Stan Silvert wrote: >> >> We had the same kind of problem in WildFly a few years >> ago. Everyone >> >> was used to starting the server with run.sh. But we >> needed to change >> >> that to differentiate between standalone.sh and >> domain.sh. So we made >> >> run.bat just print out a "This is deprecated. Here is >> what you need to >> >> do...." message. >> >> >> >> It's not a perfect solution, but we could do the same >> thing with >> >> add-user.sh and tell them to use either >> add-user-keycloak.sh or >> >> add-user-eap.sh. At least you wouldn't get any support >> questions. >> >> >> >> On 4/23/2016 9:06 AM, Ilya Rum wrote: >> >>> Hello! >> >>> >> >>> As a new member of keycloak QA team I recently had to >> set up some >> >>> clustering with domain mode. >> >>> I was really confused when add-user.sh did not add user >> to jboss but >> >>> rather created the keycloak-add-user.json. >> >>> The worst thing was that I couldn't find any docs on >> adding user to >> >>> underlying eap at all. >> >>> Had to read the add-user.sh itself to find out what was >> happening. >> >>> Even if it remains as it is, it really should be at >> least mentioned in >> >>> the docs :) >> >>> >> >>> Have a nice day! >> >>> Ilya Rum. >> >>> >> >>> On Sat, Apr 23, 2016 at 08:48:15AM -0400, Bill Burke wrote: >> >>>> Do you care about usability at all? Not everything can >> fit into nice little >> >>>> boxes all the time. This is going to be extremely >> confusing for users. I >> >>>> ran into it myself as I thought the jboss add-user.sh >> script was overwritten >> >>>> by our distribution script by mistake. *OF COURSE* we >> should have a >> >>>> separate add-user.sh script. Even when, hopefully, >> JBoss can delegate to >> >>>> Keycloak in maybe 7.1. If we are going to leverage the >> JBoss platform, and >> >>>> this means the JBoss documentation too, every >> management function that >> >>>> exists in JBoss should be available in Keycloak and >> *WORK THE SAME WAY*. If >> >>>> we don't change this, we're going to get a ton of >> support questions that >> >>>> say: "Why doesn't add-user.sh work?" >> >>>> >> >>>> >> >>>> >> >>>> On 4/23/2016 1:29 AM, Stian Thorgersen wrote: >> >>>>> In the future we need to secure the underlying WildFly >> with rhsso. In >> >>>>> which case our add-user will add users for both >> Keycloak and WildFly/EAP. >> >>>>> >> >>>>> IMO there's going to be confusion until the above is >> solved no matter what >> >>>>> we do. We'll need to document this whichever way we do >> it. Options are >> >>>>> stay with what we have or rename our script. My vote >> goes to keep as is >> >>>>> and document it. Then hopefully by 7.1 we can secure >> the WildFly bits so >> >>>>> the problem goes away. With the other option (rename >> ours) there will be a >> >>>>> problem once WildFly bits are secured by Keycloak as >> now the wf add-user >> >>>>> script should no longer be used and completely removed >> at which point we >> >>>>> should then rename it back. So in the long run >> sticking with how it is >> >>>>> today is ideal. It's also way to late making changes >> now. BTW this has >> >>>>> been around for months. >> >>>>> >> >>>>> On 22 Apr 2016 22:14, "Bill Burke" <bburke(a)redhat.com >> <mailto:bburke@redhat.com> >> >>>>> <mailto:bburke@redhat.com <mailto:bburke@redhat.com>>> >> wrote: >> >>>>> >> >>>>> >> >>>>> >> >>>>> On 4/22/2016 3:57 PM, Marek Posolda wrote: >> >>>>> > That's the question... >> >>>>> > >> >>>>> > For server distribution, we also have our >> stuff ( keycloak >> >>>>> subsystem, >> >>>>> > datasource, infinispan etc) directly declared in >> >>>>> "standalone.xml". On >> >>>>> > the other hand, for overlay distribution, we >> don't want to directly >> >>>>> > update default "standalone.xml", so we are >> adding our own >> >>>>> > "standalone-keycloak.xml". Isn't it quite >> similar thing? >> >>>>> > >> >>>>> >> >>>>> Product will not have the overlay distribution. >> >>>>> >> >>>>> > We can do the same for overlay and server >> distribution, so never >> >>>>> edit >> >>>>> > default wildfly files ( standalone.xml , >> add-user.sh), but >> >>>>> always use >> >>>>> > our own versions with "-keycloak" suffix. >> Advantage is more >> >>>>> > consistent. However people will need to always >> start keycloak server >> >>>>> > with "./standalone.sh -c >> standalone-keycloak.xml" then. Doesn't it >> >>>>> > sucks from the usability perspective? >> >>>>> > >> >>>>> >> >>>>> The overlay exists because we can't distribute >> EAP within community. >> >>>>> Keycloak should be run as a separate server, so, >> IMO, -keycloak.xml >> >>>>> files should go away and overwrite standalone.xml, >> >>>>> standalone-ha.xml and >> >>>>> domain.xml >> >>>>> >> >>>>> > I honestly don't know what's the best way >> regarding usability. AFAIK >> >>>>> > this was decided on mailing lists couple of >> months ago, but don't >> >>>>> > remember the exact threads...:/ >> >>>>> > >> >>>>> >> >>>>> I'm pretty adamant about this. There will be a >> huge amount of >> >>>>> confusion >> >>>>> if we don't make this separation. Wildfly/JBoss >> and Keycloak are hard >> >>>>> enough to configure as it is. >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Bill Burke >> >>>>> JBoss, a division of Red Hat >> >>>>> http://bill.burkecentral.com >> >>>>> >> >>>>> _______________________________________________ >> >>>>> keycloak-dev mailing list >> >>>>> keycloak-dev(a)lists.jboss.org >> <mailto:keycloak-dev@lists.jboss.org> >> <mailto:keycloak-dev@lists.jboss.org >> <mailto:keycloak-dev@lists.jboss.org>> >> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>>>> >> >>>> -- >> >>>> Bill Burke >> >>>> JBoss, a division of Red Hat >> >>>> http://bill.burkecentral.com >> >>>> >> >>>> _______________________________________________ >> >>>> keycloak-dev mailing list >> >>>> keycloak-dev(a)lists.jboss.org >> <mailto:keycloak-dev@lists.jboss.org> >> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>> _______________________________________________ >> >>> keycloak-dev mailing list >> >>> keycloak-dev(a)lists.jboss.org >> <mailto:keycloak-dev@lists.jboss.org> >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev(a)lists.jboss.org >> <mailto:keycloak-dev@lists.jboss.org> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> <mailto:keycloak-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >