[keycloak-dev] add-user.sh overwrites wildfly one
Stan Silvert
ssilvert at redhat.com
Mon Apr 25 07:59:32 EDT 2016
+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
> <mailto: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
>> <mailto: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>
>> >>>>> <mailto: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>
>> <mailto: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
>> <mailto:keycloak-dev at lists.jboss.org>
>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>> _______________________________________________
>> >>> 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
>> >> _______________________________________________
>> >> 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
>>
>> _______________________________________________
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160425/22f6c57a/attachment-0001.html
More information about the keycloak-dev
mailing list