New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to download missing stable plugins in 2.22.2 #508
Comments
Deployed to https://boreas.ouranos.ca/ogc-geoserver for testing. ![Screenshot from 2023-03-11 13-42-55](https://user-images.githubusercontent.com/11966697/224506483-9617fff3-88b6-4352-9214-c512a866806f.png) Some special users can have access directly to the datadir of the Geoserver via their Jupyter env to upload data themselves. ![Screenshot from 2023-03-11 13-46-28](https://user-images.githubusercontent.com/11966697/224506589-f17e82f2-6a14-4af3-aa13-1a9551759c88.png) The data folder on disk has no quota for now. There is no way to set a quota for data volume so I did not use it to simplify the sharing with the Jupyter env. If disk size becomes a problem, we will have to find a way to set quota later. I randomly took the list of stable and community plugins to be activated from portrait climatique geoserver. Let me know what would be the good list of required plugins. Proposed workflow: * Login to Jupyter env https://boreas.ouranos.ca/jupyter * Open a terminal * Run this command only once: `ln -s /home/jenkins/ogc-geoserver-datadir/ /notebook_dir/writable-workspace/` in the terminal. It is in `/home/jenkins/ogc-geoserver-datadir/` for Globus Personal connect to see it, if the Globus route works. * The Geoserver datadir will be visible in the file navigator on the left panel, under `writable-workspace/` * Add some data via the upload button or `scp` inside the terminal * Go to https://boreas.ouranos.ca/ogc-geoserver * Login * Perform any extra steps to provision the newly added data on disk @huard @tlogan2000 @Zeitsperre you are in the special user list that have access to this Geoserver datadir via your Jupyter env so you can test out the workflow above if needed. My operational knowledge of Geoserver is limited, I might have missed a functionality that might be broken with the context-root change. It took me a while get the context-root change working so I am not sure if I missed something. Related PR to allow context-root change from the Geoserver docker image: kartoza/docker-geoserver#507 and Issue kartoza/docker-geoserver#508 because unable to activate csw-iso and metadata plugins. Other fixes in this PR: * remove Raven config here to centralize all config in our birdhouse-deploy repo. It was initially here to demo the override capabilities. But with time, this is annoying as we have to perform the same fix at 2 different locations.
I think it's because docker-geoserver/scripts/start.sh Line 85 in 3e149e7
|
It is defined as an arg in https://github.com/kartoza/docker-geoserver/blob/develop/Dockerfile#L13, maybe the issue is that |
Thanks for the fix. Could the 2 missing plugins be added to They are in "stable" now: |
Yes, you can PR that. Ideally in future it would be nice to parse the html page to get the list of plugins so that we can always get the latest |
…307) Geoserver: update to latest version 2.22.2 to get vulnerability fix For vulnerability in `jt-jiffle` < 1.1.22, see https://nvd.nist.gov/vuln/detail/CVE-2022-24816, and GHSA-v92f-jx6p-73rx. Changed to use the CORS (Cross-Origin Resource Sharing) default config from the image instead of our own. Both are quite similar so if we can use the default config, future upgrade will be simpler. New Geoserver version will have `jt-jiffle` 1.1.24. The old one had version 1.1.20. ``` $ docker run -it --rm --entrypoint bash pavics/geoserver:2.22.2-kartoza-build20230226-r5-allow-change-context-root-and-fix-missing-stable-plugins _ __ _ ____ _ ____ ____ | |/ /__ _ _ __| |_ ___ ______ _ | _ \ ___ ___| | _____ _ __ / ___| ___ ___/ ___| ___ _ ____ _____ _ __ | ' // _` | '__| __/ _ \_ / _` | | | | |/ _ \ / __| |/ / _ \ '__| | | _ / _ \/ _ \___ \ / _ \ '__\ \ / / _ \ '__| | . \ (_| | | | || (_) / / (_| | | |_| | (_) | (__| < __/ | | |_| | __/ (_) |__) | __/ | \ V / __/ | |_|\_\__,_|_| \__\___/___\__,_| |____/ \___/ \___|_|\_\___|_| \____|\___|\___/____/ \___|_| \_/ \___|_| root@c3787dccea2d:/geoserver# find / -iname '**jt-jiffle**' /usr/local/tomcat/webapps/geoserver/WEB-INF/lib/jt-jiffle-language-1.1.24.jar /usr/local/tomcat/webapps/geoserver/WEB-INF/lib/jt-jiffle-op-1.1.24.jar root@c3787dccea2d:/geoserver# ``` Used our own custom build image because the original kartoza image is missing 2 plugins that we use, see kartoza/docker-geoserver#508 and to avoid excessively slow startup due to kartoza/docker-geoserver#515. CORS config difference: ```diff --- web.xml.old 2023-03-22 16:10:20.000000000 -0400 +++ web.xml.new 2023-03-22 16:10:06.000000000 -0400 <filter> <filter-name>CorsFilter</filter-name> <filter-class>org.apache.catalina.filters.CorsFilter</filter-class> <init-param> - <param-name>cors.allowed.methods</param-name> - <param-value>GET,POST,HEAD,OPTIONS,PUT</param-value> - </init-param> - <init-param> <param-name>cors.allowed.origins</param-name> <param-value>*</param-value> </init-param> <init-param> <param-name>cors.allowed.headers</param-name> - <param-value>Content-Type,X-Requested-With,accept,Origin,Access-Control-Request-Method,Access-Control-Request-Headers,Authorization,Authentication</param-value> + <param-value>Content-Type,X-Requested-With,accept,Access-Control-Request-Method,Access-Control-Request-Headers,If-Modified-Since,Range,Origin,Authorization</param-value> + </init-param> + <init-param> + <param-name>cors.exposed.headers</param-name> + <param-value>Access-Control-Allow-Origin,Access-Control-Allow-Credentials</param-value> </init-param> </filter> ``` Missing `cors.allowed.methods`, new `cors.exposed.headers`. For `cors.allowed.headers`, missing `Authentication`, new `If-Modified-Since,Range`. Hopefully everything still works with the new CORS config and future upgrade will be simpler. The new version is able to start now. Syncing production data to vm VM to test for upgrade problem. Last upgrade there was some problem with the existing data. I highly suggest all organizations to test with their existing data before going live. Tested with the following notebooks, hopefully CORS changes are effectively tested there: * https://github.com/Ouranosinc/pavics-sdi/blob/f4aecf64889f0c8503ea67b59b6558ae18407cf6/docs/source/notebooks/WFS_example.ipynb * https://github.com/Ouranosinc/pavics-sdi/blob/f4aecf64889f0c8503ea67b59b6558ae18407cf6/docs/source/notebooks/regridding.ipynb * https://github.com/bird-house/finch/blob/877312d325d4de5c3efcb4f1f75fbe5cd22660d6/docs/source/notebooks/subset.ipynb * https://github.com/Ouranosinc/raven/blob/0be6d77d71bcaf4546de97b13bafc6724068a73d/docs/source/notebooks/01_Getting_watershed_boundaries.ipynb with `RAVEN_GEO_URL` pointing to another Geoserver (also from this PR) to test CORS (Cross-Origin Resource Sharing) ## Other changes - Raven: allow to customize the Geoserver it will use Useful to test the local Geoserver or to have your own Geoserver with your own data. Default to PAVICS Geoserver. Set `RAVEN_GEO_URL` in `env.local` to something like `https://host/geoserver/`. - env.local.example: change default Geoserver admin user from 'admin' to 'admingeo' This only impacts new deployment when `env.local.example` is instanciated to `env.local`. This is to avoid confusion with the admin user of Magpie, which is also 'admin'.
What is the bug or the crash?
csw-iso and metadata plugins moved from community to stable but is not yet in
stable_plugins.txt
.So they should be downloaded on the fly when Geoserver starts, but have this error instead:
Steps to reproduce the issue
Starts the docker image with those plugins enabled in
GEOSERVER_STABLE_EXTENSIONS
as in https://github.com/bird-house/birdhouse-deploy-ouranos/blob/a6886186fad8d8428160a31abd3e86248de83cb4/ouranos-config/docker-compose-extra.yml#L38Versions
2.22.2
Additional context
Found in bird-house/birdhouse-deploy-ouranos#20
The text was updated successfully, but these errors were encountered: