We Keep Coding

Glassfish 4 can't enable remote admin?

I have a Glassfish 4 server running on a headless Debian VM. I can access the application just fine, but I cannot seem to access the admin port from anything other than localhost. I'd like to be able to access it so I can remotely deploy/debug from an IDE on another machine.
I've tried the asamin enable-secure-admin command, which completes but after restarting there is no change.
I've checked with netstat and Glassfish is only listening on port 4848 from localhost. Is there any other place remote admin is controlled from? Or something I'm missing?

You need the following to administer Glassfish remotely:
set a non-blank password for all admin logins
enable secure admin
ensure the network listener is listening on the correct IP addresses (it could be set to listen only on the loopback interface)

For me it works as follows:
*log into the glassfish admin console locally
*set admin-listener port to 14848 (I don`t know what is wrong with 4848, my JVM permanently uses it thus the admin console port changes automatically)
*set admin-listener IP to my-host-IP (different from the default 0.0.0.0 and from 127.0.0.1)
*add a new FireWall (I`ve ordered VPS on Windows) rule for outcoming TCP access to 14848 port
*run default glassfish domain
asadmin start-domain
*enable secure admin
asadmin --host my-host-IP --port 14848 enable-secure-admin
*restart the domain (and don`t forget to kill Java possibly loitering in memory)

How to configure JBoss 6.3.0GA to use RMI JMX?

As you can see, there's the new instructions:
https://docs.jboss.org/author/display/AS71/JMX+subsystem+configuration
And the old RMI instructions:
https://docs.jboss.org/author/pages/viewpage.action?pageId=21627109
I can get the new instructions working, but we use nagios, which only allows checking JMX via RMI, so I need to get RMI JMX working.
Does anyone have a solution for this?
I can't use the old instructions because it says <jmx-connector> is no longer supported.
I've added the following to my JAVA_OPTS on JBoss startup:
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=12345 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false" -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Dorg.jboss.logging.Logger.pluginClass=org.jboss.logging.logmanager.LoggerPluginImpl -Djava.rmi.server.hostname=10.20.2.50
but i can't get jconsole to connect to service:jmx:rmi:///jndi/rmi://10.20.2.50:12345/jmxrmi
(PS. If anyone with redhat paywall access could report back on the answer here: https://access.redhat.com/solutions/263763 that would be swell :P)

To connect to JMX the URL entered should be in the format
service:jmx:remoting-jmx://{host_name}:{port}
Standalone mode
where {port} is the native management interface of the AS7 installation being monitored (default=9999).
Domain mode
where {port} is the JMX subsystem interface of the AS7 installation being monitored (first server=4447, port-offset=150 next server).
<subsystem xmlns="urn:jboss:domain:jmx:1.1">
<show-model value="true"/>
<remoting-connector use-management-endpoint="false"/>
</subsystem>
Both modes
Outside localhost you have to set -Djboss.bind.address.management or inside xml (standalone.xml / host.xml).
Once connected the capabilities provided by jconsole can be used as normal.
Authentication
The connector is making use of JBoss Remoting to communicate with the server, for this reason the exact same authentication mechanisms as are used by the CLI will apply here.
Local
For processes running local to the AS7 installation we support a local authentication mechanism which allows clients to verify their identity by sharing a token on the filesystem with the server - this mechanism runs silently without any further user interaction required.
Username / Password
Where local authentication is not possible such as if the client is running as a different user than the AS7 process or is running on a remote installation by default the next mechanism to be used is username / password based. Where this mechanism is used the username and password of a user in the ManagementRealm if using the default management connector (port 9999) or in the ApplicationRealm if using the remoting connector (port 4447) should be supplied in the boxes on the 'New Connection' screen before the 'Connect' button is clicked.
The $JBOSS_HOME/bin/add-user.sh (Linux) or $JBOSS_HOME/bin/add-user.bat (Windows) scripts can be used to add these users. Make sure to choose between Management User and ManagementRealm vs Application User and ApplicationRealm depending on whether you're using the default management connector or the remoting connector (usually used with domain mode or when connecting remotely).
Necessary libraries to connect JMX over JBoss Remoting
The JMX MBeanServer is accessible using JBoss Remoting through the management connection. Therefore, it is necessary to add the following libaries from the modules directory of the EAP6 / AS7 distribution to the classpath of the monitoring application:
org/jboss/remoting3/remoting-jmx
org/jboss/remoting3
org/jboss/logging
org/jboss/xnio
org/jboss/xnio/nio
org/jboss/sasl
org/jboss/marshalling
org/jboss/marshalling/river
Ref: Using jconsole to connect to JMX on AS7
Other resource: Connecting VisualVM with a remote JBoss AS 7 / EAP6 JVM process
EDIT:
JBoss EAP 5 supports JMX monitoring using RMI, where JBoss EAP 6 does not. EAP 6 uses “remoting-jmx” instead of “rmi”.
You should look for another solution, as SNMP, or proper plugin for nagios
See:
JVM monitoring via SNMP of JBoss EAP 6 worker nodes with pnp4nagios Template
Jboss SAR MBean and Perl plug-in for Nagios compatible with Jboss 7.1.1

rmi registry binding issue

I'm running RMI Regitry on a virtual machine (running Windows XP) with IP: 192.168.133.2
and trying to bind an RMI server (running on different vm XP IP: 192.168.133.3)
by using this code:
Naming.rebind("//192.168.133.2/rmi.2", new RMI());
where
public class RMI extends UnicastRemoteObject
but I get this exception:
java.rmi.AccessException: Registry.Registry.rebind disallowed; origin /192.168.133.3 is non-local host
I figured that the RMI Registry don't accept any rmi server which isn't running on the same
RMI Registry running machine.
but how to make this registry accept my rmi server?
p.s: I'm using JBuilder X as an IDE.
I'm trying to implement a mobile agent which will run on some rmi servers to do some work on them and return the results to the starting station so RMI servers implements the environment that hosts this agent to do its work and send it to the next station which it'll locate through the registry

trying to bind an RMI server (running on different vm XP IP: 192.168.133.3)
Stop right there. You can't do that. You can only bind an RMI server to a Registry running in the same host as the agent that is doing the bind.
Note that that does not necessarily mean the same host as the remote object itself is running in. For example, a client could lookup a remote Registry and bind the stubs retrieved into the local Registry. But you cannot bind anything to a remote Registry.

RMI doesn't provide any sort of "federated" or distributed naming service.
RMI is structured to allow you to run an RMI registry on your server. It hosts services that can be accessed across the network, however the services run locally on that server.
The service being provided must be started - and "rebind" - on the server - not on any client system. Local address only.
Your clients should then reach out to that server...

connection has a remote Database

I use H2 Database as DBMS from a remote computer,so I enabled remote access from a browser as follows:
webAllowOthers=true
but when i try to connect to the server from my java application i get this error from H2:
remote connections to this server are not allowed
screenshot:
And also already looking into the code Analyzer with (Error Code: 90117):
REMOTE_CONNECTION_NOT_ALLOWED = 90117
The error with code 90117 is thrown when trying to connect to a TCP server from another machine, if remote connections are not allowed. To allow remote connections, start the TCP server using the option -tcpAllowOthers as in:
java org.h2.tools.Server -tcp -tcpAllowOthers
Or, when starting the server from an application, use:
Server server = Server.createTcpServer("-tcpAllowOthers");
server.start();
I do not understand how to activate the tcpAllowOthers, it does not exist in .h2.server.properties ?

There are two different server:
the Web Console server that is used to run the H2 Console tool (the GUI tool). It can be accessed by a browser only.
the TCP server that allows to connect an application that uses JDBC, when using the client/server mode (jdbc:h2:tcp://localhost/~/test)
The file .h2.server.properties is only used for the Web Console server. It only supports webAllowOthers=true. This file is not used by the TCP server.
To enable remote access to the TCP server, you need to start the TCP server using the option -tcpAllowOthers. To start both the Web Console server (the H2 Console tool) and the TCP server with remote connections enabled, you would need to use:
java -jar h2*.jar -web -webAllowOthers -tcp -tcpAllowOthers -browser
(this also starts a browser)

Cannot remotely debug JVM via SSH tunnel

I need to debug a Java application using remote debugger via an SSH tunnel. I configured putty on my PC and I'm able to connect to any other service running on the server using tunnel however eclipse remote debugger fails to connect.
On the server side I use Java 1.6.0_21-b06 started with following debug options:
-Xrunjdwp:transport=dt_socket,address=8686,server=y,suspend=n
On my laptop ssh tunnel is configured as:
L8686 IP_ADDR:8686
Are there any limitations for JVM debugger when running session over ssh tunnel?
One more thing, when I try to connect, on the server console I can see following log mesage:
Listening for transport dt_socket at address: 8686

I have the same scenario and everything is working fine, here is how I run my java app:
java -Xmx120m -agentlib:jdwp=transport=dt_socket,server=y,address=8000 -jar bla.jar
probably the most relevant part is the -agentlib one.

Can you try L8686 localhost:8686 instead, as the JVM may be refusing connections from non-local addresses? Note that 'localhost' is the address from the server's point of view.

That Listening for transport dt_socket at address: 8686 usually occurs if the VM is started or an existing debug session is closed and the VM starts listening for a debug connection again. Maybe running tcpdump on the server could give a clue which peer closes the connection and look a bit deeper on that side.