OpenFire (XMPP server)

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

[potemkin_ai]

@nebulon thank you.

The patches make OpenFire more Docker-friendly by separating code, configs, and data.

On the docker file - I don't know the way it works, in my head, it was that you would adjust all of the things and will push docker image into some Cloudron registry.

I don't mind any changes required to be done with the code to make it a proper Cloudron citizen

[nebulon]

@potemkin_ai to be honest this package is not even based on our base image for apps.

Given that I don't have any background info on the other patch files, it might be better if you could copy and paste the relevant Dockerfile lines into a Dockerfile based of the base image and we start working out entrypoint scripts for Cloudron from that on.
Based on our experience sharing package related things like Dockerfile and start scripts always creates more work on all sides and is much less robust.

Especially patching upstream code will cause a lot of headache further down the road when we have to provide working updates.

[nebulon]

Oh since we have the/an upstream author here maybe there is a chance to workout why that upstream patch is required and what the implications would be. If the app works fine with that patch, maybe it should be first changed upstream?

[potemkin_ai]

@nebulon I'm sorry to hear that...

You mentioned Cloudron Dockerfile, but I can't recall I have seen any reference to the 'Cloudron Dockerfile', that shall be used, if someone wants to package an app for the AppStore with you.

I'm not a fan of patching myself, but I can't see how this specific app could work some other way here - please, see the discussion above.