OpenFire (XMPP server)

[robi]

@potemkin_ai it helps to post the current repo and request access to the Cloudron Gitlab instance where you can push changes once the project is created.

@nebulon attempted ejabberd in another thread.

[potemkin_ai]

@robi thank you.

Not a fan of ejabberd; and I wanted to hand over things to Cloudron for maintenance or keep it under my umbrella (my GitHub) at least for my convenience.

[girish]

@potemkin_ai That's great news! I guess the next step is that if you can make the code available on git.cloudron.io preferably with MIT license , we can look into getting it published.

[jdaviescoates]

Good skills!

XMPP stuff is sorely lacking on Cloudron.

Personally I'd like Snikket but something else is much better than nothing!

[potemkin_ai]

@girish sure, I can. Would you please, create, a repository to have it pushed?

As for the license - I would appreciate to have a reference to my partners' page in the app description, once you accept it, if that's possible?

[potemkin_ai]

@jdaviescoates thanks for highlighting Snikket - does it fully XMPP backward compatible?

The reason I've chosen OpenFire - it's because it seems to be a complete and stable solution with an easy GUI for mostly everything.

[nebulon]

@potemkin_ai I've created a repo at https://git.cloudron.io/cloudron/openfire-app and gave you access rights.

[jdaviescoates]

@potemkin_ai said in OpenFire (XMPP server):

Snikket - does it fully XMPP backward compatible?

I don't know, but I'd guess so (if I've remembered correctly it's made by the lead developer of Prosody)

[guusdk]

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.

[nebulon]

@guusdk welcome here! I am currently awaiting the initial push to the package repo to be able to assess the situation. Happy to get back to you if any questions arise.

[potemkin_ai]

@nebulon thank you, pushed the code and GitHub Workflow automation at https://git.cloudron.io/cloudron/openfire-app

You will notice that a manifest file mentions turn server - that's on purpose, to make sure that I can easily grab it's credentials, as I need both XMPP & TURN for my case.

@guusdk , hi, I didn't expect that, but it's really nice to hear that!

If you will check the repo (https://git.cloudron.io/cloudron/openfire-app), you will notice three *.patch files there: OpenFire checks if it can write into the at the folder other than /app/data, despite it seems not to use that at all - is that is something that could be adjusted at OpenFire side?

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.

If anything - please, let me know!

[guusdk]

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

[potemkin_ai]

@guusdk I see, thank you for the comments!

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.

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?

[guusdk]

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

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