[keycloak-dev] add-user.sh overwrites wildfly one
Stian Thorgersen
sthorger at redhat.com
Mon Apr 25 03:35:43 EDT 2016
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:
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> 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
> >>>>> <mailto: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
> >>>>>
> >>>>> _______________________________________________
> >>>>> keycloak-dev mailing list
> >>>>> keycloak-dev at lists.jboss.org <mailto:
> keycloak-dev at 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 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 list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160425/6a142ac1/attachment-0001.html
More information about the keycloak-dev
mailing list