Skip navigation
Up to Discussions in Openfire Support
4938 Views 8 Replies Latest reply: Jun 1, 2009 1:54 PM by solipsism RSS
solipsism Bronze
solipsism
12 posts since
May 28, 2009
Currently Being Moderated

May 28, 2009 11:56 AM

unilateral changes to openfire.xml

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.

Tags: openfire.xml, configuration, overwrite
  • sixthring KeyContributor
    sixthring
    3,797 posts since
    Apr 2, 2007
    Currently Being Moderated
    May 28, 2009 1:03 PM (in response to solipsism)
    Re: unilateral changes to openfire.xml

    all the settings are stored in the database and can be managed via the admin site.  This has been the case since version 3.6.0.

  • mccotter Bronze
    mccotter
    3 posts since
    Feb 3, 2009
    Currently Being Moderated
    May 28, 2009 7:05 PM (in response to solipsism)
    Re: unilateral changes to openfire.xml

    Hi,

     

    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 created a thread with my steps here:

     

    http://www.igniterealtime.org/community/thread/38646

     

    --Marc

    • solipsism Bronze
      solipsism
      12 posts since
      May 28, 2009
      Currently Being Moderated
      May 29, 2009 12:53 PM (in response to mccotter)
      Re: unilateral changes to openfire.xml

      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.

      Attachments:
  • solipsism Bronze
    solipsism
    12 posts since
    May 28, 2009
    Currently Being Moderated
    Jun 1, 2009 8:30 AM (in response to solipsism)
    Re: unilateral changes to openfire.xml

    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?

    • sixthring KeyContributor
      sixthring
      3,797 posts since
      Apr 2, 2007
      Currently Being Moderated
      Jun 1, 2009 8:50 AM (in response to solipsism)
      Re: unilateral changes to openfire.xml

      Again.....

       

      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.

      • solipsism Bronze
        solipsism
        12 posts since
        May 28, 2009
        Currently Being Moderated
        Jun 1, 2009 9:14 AM (in response to sixthring)
        Re: unilateral changes to openfire.xml

        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.

        • sixthring KeyContributor
          sixthring
          3,797 posts since
          Apr 2, 2007
          Currently Being Moderated
          Jun 1, 2009 1:19 PM (in response to solipsism)
          Re: unilateral changes to openfire.xml

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

          • solipsism Bronze
            solipsism
            12 posts since
            May 28, 2009
            Currently Being Moderated
            Jun 1, 2009 1:54 PM (in response to sixthring)
            Re: unilateral changes to openfire.xml

            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)

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points