G
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.
@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. 
@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 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.