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