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