OpenFire (XMPP server)

[potemkin_ai]

@nebulon or @girish will correct me if I'm wrong, but in a way I understand, /app/data is the only preservable place for the data + it's the place that is covered by a backups.

So, @guusdk , I'm thinking if we can somehow place all of the OpenFire writeable data there. By introducing some variables and/or using hard links (https://www.geeksforgeeks.org/soft-hard-links-unixlinux/)

[guusdk]

@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]

This post is deleted!

[potemkin_ai]

@guusdk apologies for the delay in getting back to you.

In a way I understand, what you say, it's that you are not familiar with Cloudron structure, so let me share what I believe is a key things here:

• app should strictly reside in /app folder
• the whole Docker image is mounted read-only (--read-only at docker run)
• and just a few folders are read-write, where the key folder for our purpose is /app/data

@girish , @nebulon , please, feel free to correct me if I'm wrong here!

So, the decision has been made to place the plugins at /app/data - for this we patch Dockerfile to create a link for the plugins to /app/data - via ln -s ${OPENFIRE_DATA_DIR}/plugins ${OPENFIRE_DIR}/

That's why removal of the RW check from the home directory seems like a proper decision. It shall also help to preserve the plugins from the backup, as they could be installed manually.

What do you think?

[timconsidine]

@potemkin_ai said in OpenFire (XMPP server):

app should strictly reside in /app folder

I thought specifically in /app/code but maybe I am wrong

[guusdk]

@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]

@guusdk thank you!

I believe that what you see is achievable with a symlinks, and that's what we have in place already: https://github.com/GetZenDev/build-openfire-docker/blob/main/Dockerfile.patch#L29

The only one folder that has been missing - it's monitoring folder - here is the commit (also submitted to cloudrong's git): https://github.com/GetZenDev/build-openfire-docker/commit/788a95a7acc778dbcdb1a6df0156345aa42d68c1

Do you think we have it covered now?

[guusdk]

@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]

@guusdk agree, seems like it's the best workaround considering a mixture of data & code in one place...

I would expect that you (OpenFire team) won't be changing the structure, separating the config files, binaries, extensions?

[guusdk]

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

[robi]

@guusdk Would it not be wise to specify a plugin directory or at least a configurable environment variable?

[guusdk]

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

[LoudLemur]

@potemkin_ai said in OpenFire (XMPP server):

I would like to see OpenFire (easy to use and administer XMPP server) on Cloudron.

I've prepared a private image - what is required to push it to your AppStore?

Thank you for doing this.

[robi]

@guusdk I hear you, however, things can be tested, beta'd and staged with all known plugins in a way to minimize those issues, with helpful migration scripts and other techniques that further enhance maintainability.

Being frozen in fear of issues while doing the right things suggests many other insecurities from various perspectives.

Plus this is a great time to root out the hidden issues that haven't been found yet, but are lurking behind the fear of no changes.

I hope you're not in a legacy situation where dependecies prevent further updates.

[guusdk]

@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]

@guusdk Actually, I am being much more general than this specific issue.

I have no stake in it, as I don't use OpenFire yet, however reading about how any plugin can create files and folders in the home dir, that is as you agreed, less than optimal and a potential security issue via overwriting core files.

If that is not a concern, I'm sure a code audit would bring up other useful architectural changes.

If you're familiar with Wordpress, these are the categories of things they needed to address early on in their popularity, which still remains today.

[potemkin_ai]

@guusdk if I may ask, do you do/have or plan to make OpenFire containerized?

From what it seems, the issue is caused by a requirement that comes from container-based app development (i.e. Docker in our case).

[potemkin_ai]

@LoudLemur thank you, it's nice of you for mentioning that

[potemkin_ai]

@girish , @nebulon , what's your thoughts on that? Could you possibly accept the app under a beta status, so that we could check the approach implemented in my package?

[nebulon]

I took another look now at the repo, is https://git.cloudron.io/cloudron/openfire-app still the one? Is there any specific reason why there are these patch files?
Also is that README still current? I don't think we will publish a package which relies on other docker hub accounts as we had issues with such dependencies a long time ago and thus decided that we will always put images in our account to ensure users can install and restore apps even if that 3rdparty is gone.