Re: [SignServer-develop] Wildfly 10 initial setup problem

[Markus K. <ma...@pr...>]

On 17 September 2016 16:00:02 CEST, "Blum, Jon" <jon...@or...> wrote:
>Final update -- I think I've sorted out the problem!
>
>It was a Wildfly configuration issue -- Wildfly was set up to run as a
>service with its own dedicated user, which was not the same user which
>was
>running the SignServer CLI.
>
>Basically, I turned on trace logging for the client functions in
>conf/log4j.properties (changing the appropriate entries already in the
>file
>to TRACE level).  This revealed that the system was trying to read an
>authentication challenge file stored in /opt/wildfly/tmp/auth -- but it
>didn't have permission for the directory.  As a temporary workaround
>I've
>changed the folder permissions; in the longer term I'm going to have to
>redefine the Wildfly user to put them in the same group.
>
>So, that point is resolved, and I can get back to proper configuration!
>
>--jon
>
>
>On Sat, Sep 17, 2016 at 8:57 PM, Blum, Jon <jon...@or...>
>wrote:
>
>> I hope the mailing list has finally accepted my subscription...
>>
>> Anyway, update:  I'm now thinking the problem is most likely with my
>> wildfly server configuration.  I'd already tried to add an explicit
>> remoting connection, and have now removed it, returning to the
>default
>> configuration... still no luck.  At this point the only listener is
>the
>> default one, on 8080.
>>
>> So, a few more questions:
>>
>> 1)  There's no way of telling from SignServer's client-side
>command-line
>> app whether the EJB connection is failing to reach the server, or
>whether
>> the server is rejecting the request -- right?  Is there anything I
>should
>> be looking for in the server logs when I try to make a connection?
>>
>> 2)  User IDs -- does SignServer require a specific Wildfly user ID to
>be
>> added to the jboss-ejb-client.properties file?  (I've tried it with
>and
>> without, with no luck -- but it's possible that my user doesn't have
>the
>> right access.  If I need a user, how should I set it up?)
>>
>> 3)  Could the problem be with the following Wildfly commands, which
>were
>> listed under the JBoss 7 section of the SignServer install doc?  I'm
>not
>> sure whether they apply to Wildfly.  Could the presence of
>> "jbossws.undefined.host" rather than 127.0.0.1 be causing it to miss
>the
>> connection?
>>
>> /subsystem=webservices:write-attribute(name=wsdl-host,
>> value=jbossws.undefined.host)
>>
>> /subsystem=webservices:write-attribute(name=modify-wsdl-address,
>> value=true)
>>
>> Thanks,
>> Jon
>>
>> On Fri, Sep 16, 2016 at 11:07 PM, Markus Kilås <ma...@pr...>
>wrote:
>>
>>> On 09/16/2016 02:36 PM, Blum, Jon wrote:
>>> > Hello Markus -- thanks for your guidance here!
>>> >
>>>
>>> (Jon, please subscribe to the list otherwise your responses will not
>be
>>> delivered to the other subscribers.
>>> https://lists.sourceforge.net/lists/listinfo/signserver-develop)
>>>
>>> >> Just as you explore below the "No EJB recevier available for ..."
>>> >> typically means that either SignServer/JBoss hasn't started up
>>> >> completely or that the wrong connection configuration is used
>from the
>>> > CLI.
>>> >
>>> >> What you want to look for is that you get the EVENT:
>SIGNSERVER_STARTUP
>>> >> and not any error following it.
>>> >
>>> > Okay -- I can confirm that Wildlfly and SignServer are starting up
>>> > successfully.  From the end of server.log:
>>> >
>>> > 2016-09-16 01:18:48,894 INFO
>>> > [org.signserver.server.log.SignServerLog4jDevice] (ServerService
>Thread
>>> > Pool -- 67) EVENT: SIGNSERVER_STARTUP; MODULE: SERVICE;
>ADMINISTRATOR:
>>> > StartServicesServlet.init; ISSUER: null; SERIAL_NUMBER: null;
>WORKER_ID:
>>> > null; msg: start services startup msg; VERSION: SignServer CE
>3.7.0;
>>> > REPLY_TIME:1474013928894
>>> >
>>> > So if the server's running, and the pages are accessible on
>>> > localhost:8080, it's got to be something wrong on the client side,
>>> right?
>>>
>>> Yes likely, but it could still be a configuration issue on the
>server
>>> side for the EJB connector. But if you haven't touch those then I
>>> suppose its the client side that is the problem.
>>>
>>>
>>> >
>>> > A couple of questions to help me hunt this down --
>>> >
>>> > *  Are there any other properties files which could affect the
>client
>>> > EJB connections, besides conf/jboss7/jboss-ejb-client.properties? 
>If
>>>
>>> I don't have a WildFly 10 installation at the moment but tested with
>>> WildFly 9.0.2.Final and all changes I had to do on the client side
>was
>>> to edit conf/jboss7/jboss-ejb-client.properties to use port 8080 and
>it
>>> worked for me.
>>>
>>> I should also mention that since 3.7.x+ we have changed to instead
>>> recommending to turn of the EJB interface on port 8080 and instead
>add
>>> it back on port 4447 but that is more from a security point as you
>can
>>> then stop access to the CLI on a network/firewall level just as
>before.
>>> This change will be available in the 4.0.0 manual which you can have
>a
>>> sneak peek into here:
>>> https://www.signserver.org/sandbox/doc/4.0.0/manual/installg
>>> uide.html#WildFly_9_SSL_configuration
>>>
>>> See the "Securing the CLI by removing...".
>>>
>>> > I've mis-set something in the build process, could it be including
>an
>>> > incorrect .properties file at build time?
>>> Don't think so. Very few properties has any effect on the build
>process.
>>> Server-side properties are packaged in the EAR file when you run the
>>> bin/ant deploy command and client-side properties like
>jndi.properties
>>> and the jboss-ejb-thing is read at runtime when running the CLI.
>>>
>>> > *  Is there any way I can check specifically whether *EJB*
>connections
>>> > are accessible over port 8080?  I can confirm the JSP pages are
>showing
>>> > properly over localhost:8080; but could the beans still be being
>>> > blocked?  (I did confirm that the beans are mapped to
>>> > java:jboss/exported above, so they should be visible...  right?)
>>>
>>> Besides running the CLI (as you did) and the AdminGUI (would give
>same
>>> error) - not any that I know of. Maybe WildFly has some tool for it?
>>>
>>>
>>> Cheers,
>>> Markus
>>>
>>>
>>

Great!
That was interesting, thanks for sharing.

Cheers,
Markus
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.