Cloudron Forum

@robi I appreciate that this would solve an issue that we are discussing here, but that issue seems to be very specific to this particular environment. To my knowledge, this is the first time that anyone has ever thought this to be important enough to even start discussing it with us.

@robi in hindsight, that would have been a good idea.

I worry that introducing that now, after so many years of having a very static convention that internal code, but also third party code has grown to depend on, will cause a plethora of intermittent issues that are environment-specific, and hard to debug or explain.

Introducing that now is not an insignificant task. It would also mean that we have to take on the commitment that we support and maintain that solution. If we would not do that, then this would potentially decrement from the perceived stability of Openfire.

For me, the cost vs. weight doesn't balance.

@potemkin_ai Not without a very, very good reason. Making a convention that has been in place for ~20 years more strict like that will introduce a world of hurt, that I will try to avoid against pretty much all reasonable cost.

@potemkin_ai My Docker knowledge is not sufficiently enough to answer that decisively. It does appear that the monitoring folder was specifically added to your Docker image. Although that probably resolves the issue for that particular plugin of Openfire, my point was more generic: any plugin can create any unexpected folder anywhere in $OPENFIRE_HOME. Adding specific folders for known cases is at best a patch, not a solution.

@potemkin_ai In its most basic form, Openfire is installed in a directory, $OPENFIRE_HOME. Some distributions split this out over various locations on the file system (eg: logs to /var/log, etc).

Openfire will install plugins in $OPENFIRE_HOME/plugins/ where files will be downloaded, and folders will be extracted.

When running, Openfire will attempt to create and/or modify various other files and directories in or under $OPENFIRE_HOME. As an example, this includes, but is not limited to:

• $OPENFIRE_HOME/conf/available-plugins.xml where update checks are cached;
• $OPENFIRE_HOME/embedded-db/ where the embedded/in-memory database is persisted (this is not used when you're using an external database like MySQL or PostgreSQL);
• $OPENFIRE_HOME/resources/security/ where private key and certificate stores are being maintained;
• $OPENFIRE_HOME/logs where log files are written.

Furthermore, plugins can be expected to create content anywhere under $OPENFIRE_HOME/. A popular plugin, the Monitoring Service plugin, will, for example, create $OPENFIRE_HOME/monitoring/ to persist data that needs to survive an plugin upgrade.

In short, all of $OPENFIRE_HOME will need to be not only readable, but also writable to the user that is running the Openfire process. Functional issues of very varied impact will otherwise be almost guaranteed to occur.

@potemkin_ai Different distributables for Openfire use different layouts for storing files on the file system. The RPM and DEB distributables do not add all that much. They check for dependencies (which is just "java") and add a service script, and provide a bit of infrastructure for updating/upgrading.

When you use the tarball instead of the RPM or DEB, you will just get everything in one directory (that you can place where-ever you want). With that, you should only need to worry about the startup scripts pointing at the right place, and replacing only the right files when updating to a future new version. This might simplify things for you.

@potemkin_ai said in OpenFire (XMPP server):

What would you suggest to keep OpenFire working and preserve the data?
I'm thinking about some hard links for the folders, but I might be missing something obviously.

I do not understand what you are saying. Please note that I'm completely unfamiliar with Cloudron. You will need to be able to keep/retain files and folders in the Openfire home directory, if that's what your asking.

@potemkin_ai said in OpenFire (XMPP server):

As for the database - I'm not a user of LDAP thing, so I was thinking about Openfire main database running inside Cloudron's MySQL/PostgreSQL/MongoDB, what would be your say on that?

Openfire supports Postgres and MySQL, but not MongoDB. Openfire even supports a number of other databases, or can use an embedded database. Functionality-wise, there is no difference between using Postgres and MySQL. For production purposes, it's best to stay away from the embedded database.

As an aside: even with LDAP integration, you'd still need a database for Openfire. They are not mutually exclusive. With LDAP integration, less data will be stored in Openfire's database (the user definitions), but the database will still be used by Openfire.

@potemkin_ai

@potemkin_ai said in OpenFire (XMPP server):

OpenFire checks if it can write into the at the folder other than /app/data, despite it seems not to use that at all .

If I read your changes correctly, then what you are changing in JiveGlobals.java.patch is the check for write permission in Openfire's "home" directory. Some Openfire code, such as plugins, will write to the "home" directory. The monitoring plugin, for example, will create a folder there. As the plugin architecture is an API, any number of third party plugins might also depend on this. Maybe you have not used functionality yet that tries to write here, but I do believe that there is code out that that will do this. I do not think that you should disable the 'write' check. We certainly can't do this in the upstream project.

As a general idea, I believe it would be great to make OpenFire to use Cloudron's database, to ensure it's all managed inside of it.

There are various ways to do this: Openfire could simply re-use a database server that is being provided (but still have it's own, dedicated database), but it could also use an externally managed user store (eg: LDAP, AD, or some database tables), which would make Openfire use the users as defined in the system.

There are some pros and cons for doing this. When using an external user store, Openfire will treat this as a 'read-only' store. This means that you can't add users through Openfire. If that's a feature or an issue is up to you.

Hi all! I'm not very familiar with Cloudron, but as one of the core developers of Openfire, I'm happy to lend a hand to get this sorted. If you need some feedback on how to integrate Openfire with Cloudron, for example by tying things into a central user management system or somesuch, give me a ping!

After the Cloudron integration is complete and made publicly available, I'd be happy to cross-post an announcement on our blog over at Openfire's community website.