Skip to content
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

Closed
tlvu opened this issue Mar 15, 2023 · 4 comments
Closed

Unable to download missing stable plugins in 2.22.2 #508

tlvu opened this issue Mar 15, 2023 · 4 comments

Comments

@tlvu
Copy link
Contributor

tlvu commented Mar 15, 2023

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:

Plugin URL does not exist::  /2.22.2/extensions/geoserver-2.22.2-csw-iso-plugin.zip                                                                                                     
 csw-iso-plugin extension will not be installed because it is not available                                                                                           
Plugin URL does not exist::  /2.22.2/extensions/geoserver-2.22.2-metadata-plugin.zip                                                                                         
 metadata-plugin extension will not be installed because it is not available  

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#L38

Versions

2.22.2

Additional context

Found in bird-house/birdhouse-deploy-ouranos#20

tlvu added a commit to bird-house/birdhouse-deploy-ouranos that referenced this issue Mar 15, 2023
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.
@tlvu
Copy link
Contributor Author

tlvu commented Mar 15, 2023

I think it's because STABLE_PLUGIN_BASE_URL in start.sh is not defined, see

approved_plugins_url="${STABLE_PLUGIN_BASE_URL}/${GS_VERSION}/extensions/geoserver-${GS_VERSION}-${ext}.zip"

@NyakudyaA
Copy link
Collaborator

It is defined as an arg in https://github.com/kartoza/docker-geoserver/blob/develop/Dockerfile#L13, maybe the issue is that ARG are not available in the context on entry point. If so we need to either export the arg like in https://github.com/kartoza/docker-geoserver/blob/develop/Dockerfile#L56 and then use it like in https://github.com/kartoza/docker-geoserver/blob/develop/scripts/setup.sh#L8

NyakudyaA added a commit that referenced this issue Mar 23, 2023
@tlvu
Copy link
Contributor Author

tlvu commented Mar 29, 2023

Thanks for the fix. Could the 2 missing plugins be added to stable_plugins.txt and removed from community_plugins.txt.

They are in "stable" now:
https://docs.geoserver.org/stable/en/user/extensions/csw-iso/index.html
https://docs.geoserver.org/stable/en/user/extensions/metadata/index.html

@NyakudyaA
Copy link
Collaborator

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

tlvu added a commit to bird-house/birdhouse-deploy that referenced this issue Apr 1, 2023
…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'.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants