-
-
Notifications
You must be signed in to change notification settings - Fork 489
GeoNetwork cheat sheet
Analyse by running GeoNetwork in a debug mode to see if issues are caused by any cache or analyse the problem in the uncompiled sources. Add .../catalog.search ?debug #catalog... to the url. GeoNetwork will then load with non-compiled scripts. Find the exact line an error occurs (F12/ctrl-cmd-i webpanel) and report this line in a github issue report. Problems with javascript cache? Clear the cache css-js in Admin > Tools (or/and use anonymous tab).
By default schema-plugins are duplicated in remote data folder. Remove them from the data folder and restart the application
GeoNetwork assumes use of the default database schema of the user. You can tell jdbc to look in an alternative postgres schema by adding ?currentSchema=example to the jdbc connection. But you also need to indicate spring/hibernate to use the alternative schema, there is a commented parameter in WEB_INF/config-spring-geonetwork.xml to manage about this.
jdbc:postgresql://localhost:5432/tst?currentSchema=app1,public
Increase the log level (admin > settings) to DEBUG. Don't forget to turn it back to PROD when ready. Some error details, like xsl transformation error details, are not logged to geonetwork.log, you need to verify catalina.out to find it. Don't forget to rotate (remove) your logs.
GeoNetwork sends out web requests while harvesting, requesting maps, validating url's, etc. These requests incidentally fail with PKIX error, certificate not trusted. Java technology maintains a list of certificates it trusts. Many authentic certificates are not on that list. You have to install the certificate manually. Download the certificate from the server and deploy it to the java trust store (in jre/lib/security/cacerts)
sudo keytool -importcert -keystore jre/lib/security/cacerts -storepass changeit -file ../example.cer
Quick fix, not recommended, disable the SSL validation in Tomcat startup options.
-Dcom.sun.net.ssl.checkRevocation=false
Do not run with H2 in production or on docker. H2 database is created on the folder from which you started GeoNetwork. You can access the database from console
java -cp h2*.jar org.h2.tools.Shell
as jdbc connection use:
jdbc:h2:~/path/to/db
Sometimes requires to stop GeoNetwork first, if the connection is locked.
Deploying GeoNetwork on root makes a lot of sense, search engines will automatically discover robots.txt, sitemap.xml, opensearch description, favicon.ico etc. Consider not to use /geonetwork/ is your url. Cool Url's should not change, so not reflect the product you use at that moment. Most basic approach in tomcat is to rename the /geonetwork folder in /tomcat/webapps to /ROOT.
These days browsers prevent javascript to make cross domain requests if the remote server does not advertise to allow that. Many OGC services unfortunately don't advertise such a CORS header. GeoNetwork does contain a webproxy to bypass this behaviour (not recommended). All requests are routed via the GeoNetwork server. Use of the proxy is limited to url's mentioned in any of the records. You need to run record analysis at intervals to cache these url's, so the proxy is aware of them.
These days browsers prevent inclusion of http resources in a https website. Many OGC services run on http and fail to be loaded when running GeoNetwork on https. Check if the service is also available on https.
Some things to check (use of the search engine tools is very useful here):
- check if the site is available remotely
- verify that the record landing pages are not throwing an error (/srv/api/records/{uuid})
- register the sitemap (/srv/api/sitemap) at the search engines (to make search engines are aware that records exist)
- check robots.txt to see if crawling is not blocked for some reason
- Consider that search engines may use weeks or months to crawl and include the full catalogue content
Google dataset search does not list my records
Verify google search console to check for structured data parsing issues. And or use structured data testing tool.
Run GeoNetwork locally using embedded jetty container with:
mvn jetty:run -Penv-dev
Below statement 'duplicates' the modified schema plugins into the running application (schemasCopy parameter is required since GeoNetwork 3.10)
mvn process-resources -DschemasCopy=true
If you run GeoNetwork in a profile which added a custom schema plugin, add -Pprofile to the statement.
Indicate mvn which java to use (should be 8)
export JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home
Consider this setup i incidentally use to get started quickly without hassles
Download the software to a local folder, unzip the war, run a basic tomcat docker image and point the tomcat web folder to a mounted volume having the local geonetwork files. You can change the files and restart the docker to see instant changes.
docker run --rm -p 80:8080 -v /tmp/geonetwork:/usr/local/tomcat/webapps/ROOT tomcat:8.5
Service will be available at http://localhost
If you have some comments, start a discussion, raise an issue or use one of our other communication channels to talk to us.