I’m currently working on a project integrating the Openfire server with a custom webapp’s database and using a custom authentication provider. Then today I began getting errors and when looking to try and see what was offending in my conf/openfire.xml I found that openfire had unilaterally edited the file and stripped out almost all of my customizations, all of which had been working perfectly less than 24 hours previously.
Is there a way to prevent unprompted changes to conf/openfire.xml, or to have Openfire first create a backup copy (openfire.xml.bakXXXX, etc) when doing so?
Specifically, the error that led to this happening was
“Unable to load JDBC driver: Null
java.lang.NullPointerException”
although various other errors that I have encountered trying to find the root issue have also led to this behavior.
Additionally, as long as I’m mentioning the configuration file, I don’t suppose there’s some way to force the configuration values to take precedence over those stored in SQL.
I ran into the same problem - openfire stripping data from openfire.xml. I got OpenFire 3.6.4 up and running by completely ignoring openfire.xml and running sql commands against ofProperty while the service was stopped. I’m not sure if others do this also (maybe someone can respond) but it seems to be working fine for me.
I think that having it edit the XML configuration (when not reacting to user-spawned changes in the SQL configuration) is a bad idea - while I assume the intention was to make the installation “self healing”, if I did not want something in my configuration I would not have put it there. A message when starting the service giving the option would be much more welcome, as would anything that would disable this behavior and/or prioritize settings from the XML over the SQL.
I wrote a python script (attached) that will force all settings in your XML file into the SQL table, and a couple other related things. It detects database settings from the configuration file itself, but you can pass an override through command line. Obviously, this will not help if your configuration file is edited, but it does make it easy to make sure that the two agree. Currently only postgresql is supported, but MySQL is a fairly trivial addition. confSync.py (8585 Bytes)
This issue is coming up yet again when I started over from scratch to try and recreate the configuration that Openfire previously deleted - Openfire is stripping sections out of my conf/openfire.xml for no reason at all. Primarily, it’s taking out my provder.* sections, then my jdbcUserProvider.* and jdbcGroupProvider.* sections. I am trying to create a stable configuration for distribution with integration for a common system but Openfire seems convinced that if it has stored information in its database that the configuration file is unnecessary.
This is ESPECIALLY aggravating as a third party authentication module I’m using relies on pulling data from the configuration file that Openfire is hell bent on removing. Is there any good reason why Openfire would edit a file that it doesn’t even seem to rely on for confguration?
The settings are being moved to the database. They are not being deleted. The xml file is only used in a limited fashion since openfire 3.6.0. This is how it works now. You need to make cahnges via the admin website. Go to the system properties and edit the settings there.
As far as my purposes are concerned, the settings are being deleted because I’m using a third party module for authentication with crypted passwords that is pulling data from the XML file and not the database (this is my assumption, at least, based on what fixes the issues and the call to JiveGlobals). I understand that the database is now the preferred way to configure the system, but absolutely no purpose is served in removing data from the file.
the settings are moved for security reasons, and to make the settings editable via the admin panel. You do not need to edit the database directly. If you are authenticating against an external database that is still manageble via the standard settings method of the admin interface. If your third party module relies on another programs file for its settings i would say it is the third party module that has a problem not openfire. There change was asked for and voted on to be made and thus commited at version 3.6.0 (4 revisions ago).
I’m somewhat new to openfire, settings wered moved to sql for security? Off the top of my head, there are three reasons that such a change would increase exposure
a) On at least some systems, the database will be exposed for remote access. The filesystem however will almost never be
b) If the database is even only locally accessible, then a malicious user will be just as easily able to attempt to access the database as the root filesystem. Additionally, privilege escalation in SQL has traditionally been simpler than escalating to superuser status
c) If you can get read access for the XML configuration settings, then you will have read/write for the SQL database because the SQL connection settings cannot be moved to SQL.
Finally, the third party module relies on openfire’s settings because it is a JDBCAuthProvider that adds support for passwords stored in Crypt MD5.
I can see however that no power on earth will cause this behavior to become optional or non-default, so instead, I’ll just look into changing the scripts to pulling data from SQL instead of XML (I’m guessing a JiveGlobals.getSQLProperty call exists instead of JievGlobals.getXMLProperty)