is there any way to enable XEP-0198 or stream management in ejabberd version 2.1.10?
That version is 4 years old and it appears XEP-0198 support was merged last year, so no.
Related
I have done everything possible from my end.
OS Linux data is coming from server.
but data of wildfly (i.e heap thread etc.) is not coming.
does anyone have template of wildfly 20?
There are several solutions widely available on the internet
Zabbix-JBoss-Agent
Zabbix_wildfly_eap_jboss_monitoring
WildFly (formerly JBoss) is a Java application and can be monitored with JMX agent
I would strongly recommend upgrading to a newer version of Zabbix, as version 4.0 will become unsupported on October 31, 2021.
This question may sound absurd as I am totally new to XMPP & Openfire. I have a setup of Openfire 4.2.3 in Ubuntu 18.0.4 LTS that being used in my android chat app. During testing I received a Timeout error. While investigating the issue I found the solution rely on the XMPP updated version, check this link for more info.
Well I tried my best to find out my XMPP version and how to update it. Unfortunately I didn't find anything on it. So, I have two obvious questions here:
How to check XMPP version my Openfire is running on?
How to update XMPP version on my existing Openfire setup?
Since you are able to use the web-interface, just log in. On the start page look for the server properties. Theres the version.
For upgrading follow these steps:
To stop openfire on ubuntu: /etc/init.d/openfire stop;
Backup copy of the openfire installation directory: /usr/share/openfire;
Backup Openfire Base in Postgres: If you use the pgAdmin application, right-click on openfire base and click “Backup”. To run backup, it can be with own postgres as user. I recommend tar format, and encoding “SQL_ASCII”.
To install the new version: you can actually use the “dpkg -i” command, you will be asked if you want to keep your current version (choose this one), but you will still upgrade (option N or O - keep your currently -installed version).
On the java, has a statement informing that from version 4.3 will be necessary Java 8 installed.
Source: https://discourse.igniterealtime.org/t/update-openfire-4-1-6-to-4-2-1-in-ubuntu-server/80336
And if you really meant the "XMPP-Version". There is not really such a thing. XMPP is implemented to a different extend on different server-providers. Some have more extensions, some less.
To see which ones you have, refer to the wikipedia site:
https://en.wikipedia.org/wiki/Comparison_of_XMPP_server_software
i have a openfire server version 3.9.3 with Monitoring plugin version 1.4.4. I want to upgrade to newest version(openfire 4.1.6 and monitor plugin 1.5.7). Can i use current database for new version(openfire and plugin)?. does it lost any data?
Thanks in advance!
When a newer version of Openfire starts, it will automatically update the database. Your data will be safe. You should, of course, create backups, just in case.
i have a question about Firebird Client and Server versions. I know that the Database-File have to match the Firebird Server due to ODS Changes. i.e. Firebird recommends to Backup/Restore the Database-File between Server-Version 2.5.1 and 2.5.2...
But what about Client connections to the Server?
Which combinations are ok?
Client 2.5.2 --> Server 2.5.2 (should be ok. ;) )
Client 2.5.2 --> Server 2.5.1
Client 2.5.1 --> Server 2.5.2
Client 2.5.x --> Server 1.5
Client 1.5.x --> Server 2.5.2
Are there any known problems? What is the recommendation from Firebird?
Is it a good why to use always the new official Client? But due to we have a lot of Customer Installations i can not be sure that the server matches the client-version.
Hope someone can give me some advice.
The Firebird protocol has a versioning mechanism: the client and server negotiate which version of the protocol to use. Current Firebird server versions support all previous protocol versions of Firebird (upto and including Interbase 6.0 from which it was forked). This means that any Firebird client version can talk to any Firebird version. However if you use an older client, you can't use features added in newer protocol versions, and you won't be able to use some of the performance improvements in the protocol.
So: yes you can use older versions, but it is advisable to use the latest because bugs will have been fixed and new features or performance improvements have been added.
My answer only applies to TCP/IP connections. For 'local' connections with XNET or named pipes I know there were breaking changes between 1.5 and 2.0, and you might even need a client version that matches the Firebird server version.
For Firebird 3, using older client versions does have some caveats: by default Firebird 3 requires wire protocol encryption and a new authentication mechanism, both of which were introduced in Firebird 3 with wire protocol version 13. To be able to connect with an older client version you will need to make the following changes to firebird.conf and restart Firebird:
Relax the encryption requirement with setting WireCrypt = Enabled (default is Required)
Enable the legacy authentication with setting AuthServer = Srp, Legacy_Auth (default is Srp)
https://i.stack.imgur.com/mxQ7S.png
You cant read v2.1v database on v2.5 server.
You cant read v1.5v database on v2.5 server.
You can read v2.0v database on v2.1 server.
You can read v1.5v database on v2.1 server.
I have to set up a Hornetq Core-Bridge to a Hornetq 2.1.X Server, but I would like to use a more updated version on my side of the architecture (2.2.X). Is it compatible?
I haven't found info about it on documentation (as always btw, regarding to hornetq).
Obs: The 2.1.X Server is running on a JBoss AS, and mine is on stand-alone mode.
Until hornetq 2.2.2, hornetq didn't have version compatibility support. That means that you would need all your servers on the same version. (same as you would need for your clients).
After hornetQ 2.2.2 we offer version compatibility, however the client has to be older than the server. We don't test a 2.2.5 talking to a 2.2.2 server.
So, if the core-bridge is installed in a 2.2.2 talking to a 2.2.5, you would be fine.
a 2.2.5 talking to a 2.2.2.. probably not
A 2.1.X talking to 2.2.x.. definitely not.