[keycloak-dev] add-user.sh overwrites wildfly one

Stian Thorgersen sthorger at redhat.com
Wed Apr 27 03:29:53 EDT 2016


Unless someone has very strong arguments against it we're going to rename
the script to "add-user-keycloak". Main reason is that WildFly
documentation refer to the "add-user" script throughout their
documentation, so the simplest is to have our own rather than override what
they have. We'll also remove the '--container' argument. If anyone was
wondering 'add-user-keycloak' is confirmed as ok for product.

On 25 April 2016 at 14:30, Marek Posolda <mposolda at redhat.com> wrote:

> +1
>
>
> On 25/04/16 13:59, Stan Silvert wrote:
>
> +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 at 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 at redhat.com>
>> ssilvert at 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 at redhat.com>
>>> bburke at redhat.com
>>> >>>>> <mailto: <bburke at redhat.com>bburke at 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>http://bill.burkecentral.com
>>> >>>>>
>>> >>>>>       _______________________________________________
>>> >>>>>       keycloak-dev mailing list
>>> >>>>>        <keycloak-dev at lists.jboss.org>keycloak-dev at lists.jboss.org
>>> <mailto:keycloak-dev at lists.jboss.org>
>>> >>>>>        <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >>>>>
>>> >>>> --
>>> >>>> Bill Burke
>>> >>>> JBoss, a division of Red Hat
>>> >>>> <http://bill.burkecentral.com>http://bill.burkecentral.com
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> keycloak-dev mailing list
>>> >>>> <keycloak-dev at lists.jboss.org>keycloak-dev at lists.jboss.org
>>> >>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >>> _______________________________________________
>>> >>> keycloak-dev mailing list
>>> >>> keycloak-dev at lists.jboss.org
>>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >> _______________________________________________
>>> >> keycloak-dev mailing list
>>> >> keycloak-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160427/36af5415/attachment-0001.html 


More information about the keycloak-dev mailing list