Upgradation of Geoserver

I am reaching out to request guidance on upgrading two production GeoServer instances, currently running versions 2.17.2 and 2.18.0, to the latest version, 2.26.0. My goal is to ensure a secure and stable upgrade process for both instances, particularly given the differences in their current versions and potential patching gaps.

Concerns and Considerations for the Upgrade:

Patch Status of 2.17.2 and 2.18.0:

Could you confirm whether GeoServer 2.17.2 is considered “unpatched” compared to later releases and clarify if any critical patches were introduced in 2.18.0 that are absent in 2.17.2? An overview of the key security or stability fixes included in 2.18.0 and later versions would be very helpful for planning this upgrade.
Compatibility and Configuration Considerations in 2.26.0:

Are there any known compatibility changes in version 2.26.0 that could impact configurations created in 2.17.2 or 2.18.0? In particular, I am interested in ensuring that the existing data directory structure, workspace setups, styles, and datastore connections will remain compatible after the upgrade.
Could you advise on any verification steps or compatibility checks to confirm that our current settings will work seamlessly with version 2.26.0?
Upgrade Path and Best Practices:

Given the two production instances on different versions, would you recommend an incremental upgrade path (e.g., 2.18.0 to 2.20.x, then to 2.26.0) or a direct upgrade to 2.26.0 for both?
Are there specific staging or testing practices you would suggest to minimize downtime and ensure a stable production environment during and after the upgrade?
Security and Performance Enhancements in 2.26.0:

Could you highlight any significant security improvements, performance optimizations, or critical bug fixes in 2.26.0 compared to 2.17.2 and 2.18.0? Knowing these would help emphasize the upgrade’s value to our stakeholders.
Data Directory Separation:

Both GeoServer instances currently operate with separated data_dir configurations from the main application directory. Are there any specific considerations for maintaining data integrity and compatibility with this structure in 2.26.0?
I would greatly appreciate any additional insights, documentation, or suggestions from your team to help facilitate a smooth upgrade process for these production instances.

Thank you for your assistance and for your ongoing work on GeoServer.

This question is asked fairly often, most recently here.

Please read this recent post which provides guidance on how often, and how to perform an update.

The user guide has the procedure to follow: Upgrading exiting versions:

  • Ian advises making a backup and trying the upgrade in one go first, and if you have any trouble, try again in two steps or more.

  • I advise to check the “notes on specific versions”. This shows the key change and answers your " known compatibility changes" that should be checked.

  • GeoServer community has capacity to support releases for year as outlined in our security policy. Any release older than should be considered vulnerable. If your release falls outside of this timeframe you are “unpatched”. We have recently started using the CVE system to help communicating specific vulnerabilities.

  • The announcements have “Security Consideration” if vulnerabilities are addressed, or you may directly review the published security advisories.

The above information can be used to highlight the value of updating with your stakeholders. Set the expectation of updating each year, or working with a service provider.

Context: A sustainable open source project requires time: your time if you choose to participate (help with docs or testing); or someone else time (if you wish to contact one of our support providers ). There is a also an active crowdfunding activity to update components to meet security objectives.

Following my recent upgrade of GeoServer from version 2.17.2 to 2.26.0, I observed that while the update was generally successful, the size of /opt/tomcat/work/Catalina/localhost/geoserver/wicket-filestore/ increased significantly. Within a single day, this directory consumed the available disk space on my instance.

I’ve explored various configuration options for managing the Wicket filestore but haven’t found a solution that resolves this issue. Could you please provide guidance or recommendations on addressing this? Your assistance would be greatly appreciated.

Your are the first to notice and report this issue.

Wicket apparently keeps a folder per session, and to remove such folders when an http session is invalidated.

Is there anything special about your http sessions / authentication sessions? How have you set up security …

we have master slaves configuration with no shared data disk (it works with replicating the disk at any change). The load balancer Infront of them is configured with session of affinity. No special configuration has been passed and no plugin installed we are on Linux server. Potentially several user but not hundred and space occupied in just a day full the disk. we have around thousand of layers published on the Geoserver.

I don’t see a way in geoserver to control the wicket parameters using external options, f.e. in the above link you may find a way to externalize these settings and it would be great to have something like such implementation.
Also another very interesting option is the possibility to have storage of the session over separated and customizable storage (redis, memory, database, etc).
Meanwhile thanks for your support really appreciated.