Add pull_policy: never to the openfire service definitions across all compose files.
The openfire image is always expected to be present locally, built and tagged before running any environment. Without this, Compose would silently attempt a registry pull if the image was missing or the image name resolved incorrectly, producing a misleading "pull access denied" error rather than a clear "image not found" failure.
The optional SQL directory contained a single PostgreSQL script with no
clear organisation. As we now have scripts for both PostgreSQL and MSSQL,
and multiple test scenarios (message generation, room creation, performance
testing), a clearer structure is needed.
Reorganises into postgresql/ and mssql/ subdirectories with descriptive
filenames that indicate purpose rather than execution order. Adds README
documenting available scripts and usage patterns.
Key scripts preserved:
- 410k message generator (PostgreSQL + MSSQL)
- 50 room creator with message redistribution (PostgreSQL + MSSQL)
- 10,000 minimal rooms for scale testing (PostgreSQL)
- 200 rooms with realistic affiliations and messages (PostgreSQL)
- Worker count configuration template (PostgreSQL)
Utility SQL scripts for debugging, performance testing, and scenario recreation shouldn't run automatically but should be available in the repository for developers to use when needed.
The optional/sql/ directory holds these scripts separately from
deployment-specific sql/ directories, which are mounted to PostgreSQL's docker-entrypoint-initdb.d. This avoids duplicating utility scripts across deployments whilst keeping them discoverable.
Each script includes a header with compatibility information and usage instructions. Users can either copy files to their deployment's sql/ directory for automatic execution on fresh start, or run them manually against a running database.
Adds JDWP debug agent configuration to all deployment options, exposing
debug ports on localhost (5005 for xmpp1, 5006 for xmpp2, etc.). The
agent runs in non-blocking mode (suspend=n) so containers start normally
without waiting for a debugger - there's no impact on regular usage.
This reduces friction for developers who frequently need to debug
Openfire, eliminating the need to maintain local uncommitted changes
or remember JDWP syntax.
The root README lacked an overview of what each deployment directory
provides, making it harder for new users to choose the right setup
for their testing scenario.
Adds a "Deployment Options" table summarising simple, federation,
cluster, cluster_with_federation, and proxy configurations.
Adds a section to the root README explaining the numeric prefix convention for SQL files (000-, 001-, etc.) and how PostgreSQL executes them alphabetically from /docker-entrypoint-initdb.d.
This helps contributors understand how to add custom SQL scripts whilst ensuring correct execution order relative to the schema initialisation.
Renamed openfire.sql to 000-init-openfire.sql to make the initialisation order explicit in the filename. This helps when adding additional SQL scripts that need to run after the schema is created, as PostgreSQL executes files in /docker-entrypoint-initdb.d alphabetically.
The new openfire-integration-test repo uses this openfire-docker-compose repository as a base (using git submodules) for its tests but needs to reconfigure Openfire via the database before startup. To do this it overlays additional SQL files into this openfire-docker-compose repository's sql folders so they are run on startup. It has had to prefix its new SQL file with zz- to make sure it runs after the initialisation SQL file in our repository. This change should make future similar uses less complex/error-prone.
This file has been updated in Openfire to enable CRL downloading, so I'm porting it into this project as we use a copy of the security directory and overwrite the original.
Added the openssl ocsp flag to ignore malformed requests. The OCSP responder now continues running instead of terminating upon receiving a malformed request.
When testing connectivity it is useful to be able to curl http://ocsp-responder:8888. Previous to this commit the responder would send 200 OK then exit. With this change we still get the 200 response but the responder remains active.
The OCSP responder in OpenSSL (in Alpine) only supports IPv4 so I've used socat as a proxy to listen in IPv4 and IPv6 then forward to the OCSP responder on localhost using IPv4.
This file is being added to Openfire so I'm porting it into this project as we use a copy of the security directory and overwrite the original.
To pick up the setting in this new file, and the new system property (jdk.tls.server.enableStatusRequestExtension=true), we must also use the updated openfire.sh start script which includes the new file and sets the mentioned system property. This will happen naturally when those changes make it into the Openfire Docker image. Until then you can recreate this behaviour by adding the following to xmpp1 and xmpp2:
```
environment:
JAVA_TOOL_OPTIONS: >
-Djava.security.properties=/var/lib/openfire/conf/security/java.security
-Djdk.tls.server.enableStatusRequestExtension=true
```
I considered adding IPv6 support to the OCSP responder but it would add more files and complexity for (I think) little gain.
Instead this change keeps the OCSP responder on IPv4 only, but makes sure it's properly configured in the hosts file even when using the -6 flag. The OCSP responder will always use IPv4, other services will be able to reach it via IPv4 regardless of whether they're using IPv6 for their own communication.
Cert generation and import scripts now support any number of XMPP servers and use more intuitive naming for the certificates.
This will make it easier to move cert generation to other configurations. Maybe promoting this to a top-level script to generate certs in all scenarios.
Prior to this the OCSP responder used 172.50.0.30. This conflicts with an example given in the readme, which uses the same IP address describing how to add a third node to the setup.
This change avoids confusion, and keeps things consistent if we ever decide to copy this to the other configurations (eg clustering_with_federation).
- Update OCSP URL in certificate generation from IP to domain name
- Add OCSP hostname to docker-compose network configuration
- Document useful hosts file entries in README.md
The changes make it easier to test OCSP locally with clients by using domain names that can be mapped in host files.
Adds Online Certificate Status Protocol (OCSP) support to the federated Openfire setup:
- Add certificate generation script with full PKI hierarchy
- Add certificate import script for Openfire keystores
- Implement OCSP responder service via Docker compose
- Update documentation with OCSP usage instructions
The -o flag can now be used with start.sh to enable OCSP support.
This updates the configuration to use a SNAPSHOT build of the Hazelcast plugin 5.5.0-1, and updated its configuration files accordingly.
Note that this requires Openfire (the container) to use Java 17 or later.
This adds support for IPv6, by giving all `start.sh` scripts an `-6` argument, that causes a dualstack configuration to be loaded.
Each individual docker-compose file has been split out. Now, each file no longer defines any networking. Instead, one of two networking fragments is expected to be merged in.
When starting Openfire, a Hazelcast configuration option is passed through to the Openfire process to denote preference for IPv4 or IPv6. This passing through depends on the change in Openfire, that is introduced by 2634d4a83a
Minor other changes have been applied, that mostly make the start scripts more consistent amongst each-other.
fixes#61
Guus der Kinderen
Bob Love
Matthew Vivian
Daniel Goldberg
Dan Caseley
mjones216