I’ve downloaded the latest version of Openfire which at the time of writing this is version 4.9.0. I previously used a docker image that went out of date and decided to setup the server properly. I purged everything from the old docker image off my server and started fresh, however after installing the .deb file from the ignite website the web installer never hooks onto port 9090 despite the service running successfully according to my server terminal. Every port needed by Openfire has already been open and was working previously. I’ve been trying to figure this out for the better part of last month and I am running out of things to try. I hope it is something that was staring at me this whole time. Thanks.
Oh, I had wished you’d reached out earlier than a full month! Let’s see if we can get you on the right track again.
First things first: Openfire will generate output. Most of it will be in logfiles (typically in <OPENFIRE_HOME>/logs/ but on some systems in /var/log/openfire/) and some of it will be written to standard-out (which either ends up in a file called nohup.out or in a logging facility managed by your operating system. Can you evaluate all those places for output.
Does the Openfire process run (and does it keep running)? Using a tool like netstat, can you determine if it binds to any ports?
A relatively new change in Openfire is that the admin console by default will only bind to the loopback interface (making it accessible only from the local host), for security. Maybe double-check that this isn’t conflicting with your network setup.
Better late than never I guess 
I found a log in /var/log/openfire/ containing:
2024.09.30 19:29:46.538 e[32mINFO e[m [main]: org.jivesoftware.openfire.XMPPServer - Registering shutdown hook (standalone mode)
2024.09.30 19:29:48.048 e[32mINFO e[m [main]: org.jivesoftware.util.cache.ConsistencyMonitor - Applying configuration for cache consistency check. Enabled: false
2024.09.30 19:29:48.154 e[32mINFO e[m [main]: org.jivesoftware.openfire.XMPPServer - Openfire 4.9.0 [Sep 30, 2024, 7:29:48 PM]
2024.09.30 19:29:48.662 e[33mWARN e[m [PluginMonitorTask-2]: org.jivesoftware.openfire.container.AdminConsolePlugin - Admin console: CertificateStoreManager has not been initialized yet. HTTPS will be unavailable.
2024.09.30 19:29:51.462 e[32mINFO e[m [PluginMonitorTask-2]: org.jivesoftware.util.cache.CacheFactory - Created cache [org.jivesoftware.util.cache.DefaultLocalCacheStrategy] for Favicon Misses
2024.09.30 19:29:51.468 e[32mINFO e[m [PluginMonitorTask-2]: org.jivesoftware.util.cache.CacheFactory - Created cache [org.jivesoftware.util.cache.DefaultLocalCacheStrategy] for Favicon Hits
2024.09.30 19:29:51.519 e[33mWARN e[m [PluginMonitorTask-2]: org.jivesoftware.openfire.spi.XMPPServerInfoImpl - Unable to determine local hostname.
java.net.UnknownHostException: mocha-frontend: mocha-frontend: Name or service not known
at java.net.InetAddress.getLocalHost(InetAddress.java:1670) ~[?:?]
at org.jivesoftware.openfire.spi.XMPPServerInfoImpl.getHostname(XMPPServerInfoImpl.java:70) [xmppserver-4.9.0.jar:4.9.0]
at org.jivesoftware.openfire.spi.XMPPServerInfoImpl.getXMPPDomain(XMPPServerInfoImpl.java:95) [xmppserver-4.9.0.jar:4.9.0]
at org.jivesoftware.openfire.container.AdminConsolePlugin.logAdminConsolePorts(AdminConsolePlugin.java:546) [xmppserver-4.9.0.jar:4.9.0]
at org.jivesoftware.openfire.container.AdminConsolePlugin.startup(AdminConsolePlugin.java:285) [xmppserver-4.9.0.jar:4.9.0]
at org.jivesoftware.openfire.container.AdminConsolePlugin.initializePlugin(AdminConsolePlugin.java:382) [xmppserver-4.9.0.jar:4.9.0]
at org.jivesoftware.openfire.container.PluginManager.loadPlugin(PluginManager.java:640) [xmppserver-4.9.0.jar:4.9.0]
at org.jivesoftware.openfire.container.PluginMonitor$MonitorTask.run(PluginMonitor.java:357) [xmppserver-4.9.0.jar:4.9.0]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
Caused by: java.net.UnknownHostException: mocha-frontend: Name or service not known
at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method) ~[?:?]
at java.net.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:930) ~[?:?]
at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1543) ~[?:?]
at java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:848) ~[?:?]
at java.net.InetAddress.getAllByName0(InetAddress.java:1533) ~[?:?]
at java.net.InetAddress.getLocalHost(InetAddress.java:1665) ~[?:?]
... 13 more
2024.09.30 19:29:51.558 e[32mINFO e[m [PluginMonitorTask-2]: org.jivesoftware.openfire.container.AdminConsolePlugin - Admin console listening at http://localhost:9090
2024.09.30 19:29:51.563 e[32mINFO e[m [PluginMonitorTask-2]: org.jivesoftware.openfire.container.PluginManager - Successfully loaded plugin 'admin'.
I’m not too familiar with the netstat command, however I used lsof to check if any program is binding to port 9090, and it lists openfire as a program bound to that port so atleast the system itself is reporting correctly.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
java 28363 openfire 141u IPv6 125296 0t0 TCP *:9090 (LISTEN)
I remember hearing about the setup only allowing local connections to load the web installer, and I think I had to work around that the first time I used openfire but I don’t remember how I disabled that. By the looks of the logs it looks like its doing exactly that again.
The problem I was having is I wasn’t able to access the local server, atleast from the GUI desktop for some reason that I do not know. Somehow I was able to access the desktop of my server and am now able to complete the setup from said server. However when I try to change server settings on the admin panel I get greeted with this:
Exception:
java.lang.IllegalStateException: Failed at attempt to obtain an ID, aborting... at org.jivesoftware.database.SequenceManager.getNextBlock(SequenceManager.java:239) at org.jivesoftware.database.SequenceManager.nextUniqueID(SequenceManager.java:171) at org.jivesoftware.database.SequenceManager.nextID(SequenceManager.java:89) at org.jivesoftware.openfire.security.DefaultSecurityAuditProvider.logEvent(DefaultSecurityAuditProvider.java:68) at org.jivesoftware.openfire.security.SecurityAuditManager.logEvent(SecurityAuditManager.java:110) at org.jivesoftware.admin.LoginLimitManager.recordFailedAttempt(LoginLimitManager.java:166) at org.jivesoftware.openfire.admin.login_jsp._jspService(login_jsp.java:292) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:590) at org.eclipse.jetty.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1419) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:764) at org.eclipse.jetty.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1665) at com.opensymphony.sitemesh.webapp.SiteMeshFilter.doFilter(SiteMeshFilter.java:65) at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202) at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635) at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:73) at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202) at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635) at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:49) at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202) at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635) at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:174) at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202) at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635) at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:292) at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:210) at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635) at org.jivesoftware.admin.ContentSecurityPolicyFilter.doFilter(ContentSecurityPolicyFilter.java:53) at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:202) at org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1635) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:527) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:131) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:598) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:223) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1570) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:221) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1384) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:176) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:484) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1543) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:174) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1306) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:129) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:141) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:122) at org.eclipse.jetty.server.Server.handle(Server.java:563) at org.eclipse.jetty.server.HttpChannel$RequestDispatchable.dispatch(HttpChannel.java:1598) at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:753) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:501) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:287) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:314) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:100) at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53) at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:421) at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:390) at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:277) at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:199) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:411) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:969) at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1194) at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1149) at java.base/java.lang.Thread.run(Thread.java:829)Caused by: com.mysql.cj.jdbc.exceptions.CommunicationsException: The last packet successfully received from the server was 63,571 milliseconds ago. The last packet sent successfully to the server was 63,571 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem. at com.mysql.cj.jdbc.exceptions.SQLError.createCommunicationsException(SQLError.java:174) at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:64) at com.mysql.cj.jdbc.ClientPreparedStatement.executeInternal(ClientPreparedStatement.java:912) at com.mysql.cj.jdbc.ClientPreparedStatement.executeQuery(ClientPreparedStatement.java:968) at org.apache.commons.dbcp2.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:122) at org.apache.commons.dbcp2.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:122) at org.jivesoftware.database.SequenceManager.getNextBlock(SequenceManager.java:205) ... 63 moreCaused by: com.mysql.cj.exceptions.CJCommunicationsException: The last packet successfully received from the server was 63,571 milliseconds ago. The last packet sent successfully to the server was 63,571 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem. at jdk.internal.reflect.GeneratedConstructorAccessor23.newInstance(Unknown Source) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) at com.mysql.cj.exceptions.ExceptionFactory.createException(ExceptionFactory.java:61) at com.mysql.cj.exceptions.ExceptionFactory.createException(ExceptionFactory.java:104) at com.mysql.cj.exceptions.ExceptionFactory.createException(ExceptionFactory.java:149) at com.mysql.cj.exceptions.ExceptionFactory.createCommunicationsException(ExceptionFactory.java:165) at com.mysql.cj.protocol.a.NativeProtocol.send(NativeProtocol.java:629) at com.mysql.cj.protocol.a.NativeProtocol.sendCommand(NativeProtocol.java:684) at com.mysql.cj.protocol.a.NativeProtocol.sendQueryPacket(NativeProtocol.java:1050) at com.mysql.cj.NativeSession.execSQL(NativeSession.java:660) at com.mysql.cj.jdbc.ClientPreparedStatement.executeInternal(ClientPreparedStatement.java:889) ... 67 moreCaused by: java.net.SocketException: Connection reset by peer (Write failed) at java.base/java.net.SocketOutputStream.socketWrite0(Native Method) at java.base/java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:110) at java.base/java.net.SocketOutputStream.write(SocketOutputStream.java:150) at java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81) at java.base/java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142) at com.mysql.cj.protocol.a.SimplePacketSender.send(SimplePacketSender.java:57) at com.mysql.cj.protocol.a.TimeTrackingPacketSender.send(TimeTrackingPacketSender.java:52) at com.mysql.cj.protocol.a.NativeProtocol.send(NativeProtocol.java:620) ... 71 more
On first glance, this seems to be an issue with the network configuration of the server/container. Openfire tries to resolve the local host, which is done by retrieving the name of the host from the system (which apparently is configured to be mocha-frontend). Then, that name is attempted to be resolved (into a network address). This last bit fails.
This all suggests that the system isn’t able to resolve its own name (which may be an indication of bigger issues). You could try to get around this by adding the hostname to the /etc/hosts file of the container (to the 127.0.0.1 entry), but perhaps more networking configuration of that system is required.
1 Like
I was wondering about that since sudo commands would spit out an error about the hostname. I checked my hosts file and for some reason still had entries from an older container image with a different hostname. changing that seemed to fix things. I also failed to realize the database was corrupted so i decided to purge the entire install along with the database and start fresh. that error is now gone however the server is still inaccessible outside of the LAN. I still have the same network settings set when the server was still operational, so I’m not exactly sure what changed beyond that.
You write that ‘the error is now gone’. Does that mean that Openfire now starts up without any errors or warnings being logged?
I’m not exactly sure where this leaves us. My guess is still that a networking issue in the virtualization exists, but it’s hard to say without more data.
What you could try to do is use a command-line webclient (something like ‘curl’ or ‘wget’) from within the container, to try and access the admin console. We’ll be able to tell where to look from there: if the web-request is unsuccessful, then Openfire isn’t started. If it is successful, then some kind of networking issue is in play.
You could bash into the container, and do something like this:
wget http://localhost:9090/index.jsp
If Openfire is started, then that should download a file called index.jsp, that starts with this:
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Openfire Admin Console</title>
What I mean by “the error is now gone” is that I no longer get the java exception message when I attempt to change server settings, or even log in sometimes. It seemed to be a mix between the server hostname and an apparent issue with using mariaDB. changing to embedded databases seems to prevent the problem but I’d like to use external databases again in the future. Whatever the case is, I still cannot access the server through the internet. Running the wget command produced the result that is expected, having a HTML file with head code downloaded. It is configured correctly for the LAN but still won’t connect through the internet. Using netstat and other networking commands I can see that openfire is binding to ports 9090 and 5222, and also listening on said ports. However those ports appear closed on the internet, using a port checker confirms that. I have disabled ufw and my vps firewall for testing purposes and still cannot connect to the openfire admin page or through a XMPP client. I’m not sure what other network configurations I can check and tweak.
Maybe check if this helps:
You can log in sometimes? That is working on and off again, without you changing the configuration of Openfire of your container? 
When you say ‘it is configured correctly for the LAN’, does that mean that other machines on the same network can access Openfire just fine? If that’s the case, then the issue preventing connections from the wider internet may lay outside of the virtual host, but in something like a router.
I get the impression that a lot of the issues that you’re running into are related to the virtualization that is being used. Have you considered not using that at all, and instead install Openfire straight on the server? That would reduce an awful lot of complexity.
I guess I didn’t make that clear. I ditched virtualization and when I reinstalled openfire, I reinstalled it directly onto the server. I wasn’t having connection issues before installing straight onto the server. I checked the guide zoidberg shared and I never restricted access to the admin panel via setup, so that value in the config file doesn’t exist. I can login when connected remotely to the server in question, but attempting to login from an outside computer or through a xmpp client doesn’t connect. could it perhaps be a issue with my VPS provider?
In later versions of Openfire, access to the web-based admin console is by default restricted to ‘localhost’, but such restrictions do not apply to XMPP connections. You should, by default, be able to connect with an XMPP client to ports 5222 and/or 5223.
If you cannot connect with an XMPP client, then:
- verify that Openfire has started up without errors or warnings in its log files
- check with command-line tools that the Openfire process is listening on port 5222 of the appropriate network interface(s)
If that’s both OK, then I don’t think the problem that you’re seeing is caused by Openfire, but rather by a generic server/network configuration problem.
I don’t know what I messed with, but it’s now accessible outside the LAN. I don’t even know lol, thanks for the help nonetheless.