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

[Blum, J. <jon...@or...>]

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
>>
>>
>