I’m not sure exactly what you mean, but the Http File Upload plugin remains useful, especially when you use Openfire with third-party clients.
actually i cannot find Http File Upload plugin in available plugins. Just installed openfire 4.9.2. But when i use it before this plugin was available.
Oh? That must be some kind of bug. Thank you for reporting it. As a work-around, you can manually download the plugin at Ignite Realtime: Openfire httpfileupload Plugin Archive
1 Like
FYI: the v5.0.1 deb package still has the problem with the systemd service remains not enabled.
1 Like
Yeah, sorry about that. You made your ‘next release’ claim 10 minutes or so after we had already built the next release. 
Hi, Guus, first of all congrats on the new version! I just upgraded to 5.0.1. However, in the plugin page, httpfileupload is reported as not longer supported. I also cannot find the plugin in the plugin list anymore. I use the Conversation App at client side on my phone, it seems to me I can still send pictures and files via openfire. Thanks for your time to look into this. Russ
I just tried your method by downloading the jar of httpfileupload and manually install it on the new openfire 5.0.1, it worked! On the other hand, another plugin “monitoring service” is also reported no longer supported. Russ
Thanks for reporting this, Russ. I have once observed this behavior myself, but dismissed it at the time. I am now having trouble reproducing the problem, which makes it hard to analyze what’s going on. Do you know how to recreate a server in which this problem happens?
Hi, Guus,
What I did was:
- Download 5.0.1 deb file
- systemctl stop openfire.service
- dpkg -i [the deb file]
- systemctl start openfire.service
Then it happens.
1 Like
well I tried 5.0.1
it runs in foreground only using bin/openfire.sh
The docs in this release also still point to tar users running /bin/openfire which is not included anymore, with zero documentation on that. If you are going to make such a substantial change, you need to make sure it runs still, or do none of your current programmers use anything but redhat and debian
and I’ll repeat forcing us to use ROOT to execute openfire is wrong, after all these many many many years where we ran it as a user - it runs on nothing less than port 1024 it does not need privilege and lets face it java doesnt have the best security reputation so this is very dumb move as well.
gawd… these - even majors, upgrading was so so simple in the past, it just worked, I am flabergasted at the direction this project has gone.
we’ve yet again reverted back to 4.9.2… giving up… hrmm now just need to find a way to stop all these popups saying new server released anoyances…
I’m not a core dev, but I made the PR with migration of the Debian package to SystemD service.
@nobby6 please provide info on your environment and what are you trying to achieve. As far I understood you are using Alpine or FreeBSD that doesn’t have the SystemD, right?
You may want to use a service instead. You can use the old /etc/init.d/openfire (maybe be deprecated soon) or the new SystemD service.
I had a plan to add a few words about the systemctl commands into install-guide.html for those who stuck in using the old way and don’t know systemd. The bin/openfire looks like something that was changed a long time ago, isn’t it? Maybe you are talking about the RPM package, I didn’t worked on it yet.
ok, you are definitely on the RedHat. I also saw this line distribution/src/bin/extra/redhat/openfire:25 that forces to use the root. I guess this is historically was made when was transition from the jive user to openfire or something like that and old users might loos their data. The files are dated 15 years ago. During transition of the RPM to the SystemD I guess we can migrate to openfire user. You may track and report problems on the Jira
upgrading was so simple in the past
We all know that this was possible in a cost of technical debt, slow performance and higher development cost. In the major 5 release was upgraded a lot of libraries and even the minimal JDK requirement (because of libraries, core devs was very conservative). There was a beta period during which you might test and report bugs. Even the 5.0.1 is still may be considered as kind of beta version, and you are an early adopter. Please help to the project by reporting of any problems, writing blogs with instructions, docs and code contribution and financially or by ordering commercial support. Please don’t blame the core team, they are doing a great job, especially given their resources.
2 Likes
@stokito
I run on slackware, so only use tar.gz releases. it is free of the virus that is systemd 
so we followed the tarball instructions for every upgrade, then the relevant bits we used for many many years and major.minor.patch levels was
ims_start() {
echo -n "Starting Openfire IM Serices... "
if [ -x /opt/openfire/bin/openfire ]; then
cd /opt/openfire/bin
(sudo -u ims /opt/openfire/bin/openfire start && echo -e " Done ") || echo -e " Failed - IMS"
else
echo -e " FAIL: IMS not executable... "
fi
}
ims_stop() {
echo -n "Stopping IMS... "
if [ -x /opt/openfire/bin/openfire ]; then
/usr/bin/logger "Shutting down IMS"
cd /opt/openfire/bin
(sudo -u ims /opt/openfire/bin/openfire stop && echo -e " Done ") || echo -e " Failed Shutting down IMS"
all that has now been taken away with no explanations, I guess they perhaps are perhaps wanting to get rid of tarball users and support the rpm and deb only. if thats teh intention they should tell us, so we can make plans moving forward so we all stop wasting time
1 Like
The tarball doesn’t contain the /etc/init.d/openfire but you may check it’s debian version:
There is also a RedHat version but it’s more complicated.
If you can create and maintain the Slackwere package that would be great. So then users can install it simply.
The /bin/openfire might be removed by me when I worked on the build packages simplification. Check the git history if that’s important.
The openfire sh may not work on the Slackware, it expects Debian, MacOS and Windows cygwin. Basically the script tries to find the JRE folder.
I hope not so many users were affected and for sure they can make script fix. Thank you for sharing code, it may help to others
This isnt about slackware, its not about debian, it is about every distro where an administrator setup and used the tarball, there is still a number of distros that dont and wont use systemd, if teh project only has coders who understand systemd and nothing else, thats a dangerous sign for that project.
You take that ability away from us by removing that code, and you want us to re-invent it and submit it, do you not hear what you are saying, thats rhetorical by the way, I’ve been resisting my teams pushes to move to prosody for some time, it looks like they finally won.
The bin/openfire is mentioned in the Openfire: Upgrade Guide
what are you referencing in that? yes, thats what we followed
ZIP or TAR.GZ
Stop Openfire.
Backup the Openfire installation directory. This step is critical because the data will be overwritten with the new .tar.gz/zip install.
Backup the Openfire database. Note that the embedded database is inside the installation directory and is backed up in step 2.
Wipe out the contents of the Openfire installation directory (all folders and files).
Extract the .tar.gz/zip file into the installation directory.
Copy the conf directory from the backup to the installation directory.
Copy the embedded-db directory from the backup to the installation directory.
Copy the enterprise directory from the backup to the installation directory, if it exists.
Copy the plugins directory from the backup to the installation directory except for _plugins/admin_.
Copy modified files located in resources/security from the backup to the installation directory.
Start Openfire
the ONLY reference to init.d.blah is under RPM not ZIP GZ
look forget it ok, its my fault I made the stupid f’in mistake of thinking the tarball was DISTRIBUTION INDEPENDANT and neutral, obviously you think only debian and redhat users use it, why you think they’d use the tarball instead of the rpm or deb file is comical.
Im done with this shit, you took away the distro neutral version and you want us to fix it, if it was a 2 second fix and we understood the java crap do you think id waste my f’in time here.
well not any more.
Good riddance then
Thank you for sharing this issue. It is obvious that it has caused frustration. I appreciate the time you’ve taken to describe the problems you have encountered.
From what you’ve outlined, it’s likely that the disruption you’re experiencing stems from well-intentioned changes introduced to modernize the project and align it with more widely used distribution mechanisms. These updates were designed to benefit the majority of users by simplifying package management and standardizing service behavior. That said, it’s unfortunate that this came at the expense of breaking long-standing workflows for tarball users, especially those running on systemd-free environments.
This all leads to what appears to be a key difference in perspective. Where you are understandably expecting things to continue working or be promptly fixed, the others were likely aiming to engage you in the community model of open source: identifying issues collaboratively and encouraging contributions when gaps are found. While this model can be rewarding and inclusive, it can also be frustrating when a change disrupts your environment and the solution feels unclear or overly burdensome.
However, while the frustration is understandable, the tone of your last responses, including profanity and dismissive language, is not constructive. Our software is created and maintained by dedicated volunteers, many of who pour their love and often limited time and resources into the project, discussing and coordinating almost daily, helping others where they can, to bring you products that you can use for free, without any expectations or required contribution on your part. These kinds of exchanges can discourage participation and diminish the goodwill that open source communities rely on.
Your experience highlights an important gap, one that the community should absolutely try to address. However, meaningful progress will be easier to achieve if we keep the conversation respectful and focused on solutions.
If you’re open to it, your insights as a tarball user would be valuable in helping guide better documentation or restoring missing scripts. If not through code, then even through specific suggestions or documentation updates. That’s one of the strengths of open source: the chance for every user to help shape the project.
3 Likes
Hi Guus,
First off, thank you for all the work you and the team have done with Openfire over the years. It’s a fantastic project, and we’ve really enjoyed using it as a way to stay connected with family and friends. That said, I wanted to ask if there’s any chance the team would consider maintaining an official Docker image for Openfire. While there are some community-built options floating around, many are outdated or unsupported, and a lot of us would feel more confident running Openfire in containers if there was an officially supported image directly from the project.
Thanks again for everything you do with the project!
There is one on GHCR
1 Like