We're paid subscribers of Openmaptiles.com production map package and we're setting up a new version of latest Docker version of tileserver-gl (v2.6.0) with the latest map data from Openmaptiles.com (osm-2019-07-01-v3.10-europe_spain.mbtiles) and we've got an error message:
# docker run -it -v --restart=always -p 80:80 -v /var/lib/docker/tileserver-gl/data/osm:/data --network tileserver-gl-net --ip 172.18.0.3 --name tileserver-gl_osm_v2.6.0 klokantech/tileserver-gl:v2.6.0 --verbose
Starting Xvfb on display 99
xdpyinfo: unable to open display ":99".
xdpyinfo: unable to open display ":99".
Starting tileserver-gl v2.6.0
No MBTiles specified, using osm-2019-07-01-v3.10-europe_spain.mbtiles
Automatically creating config file for osm-2019-07-01-v3.10-europe_spain.mbtiles
ERROR: Metadata missing in the MBTiles.
Make sure osm-2019-07-01-v3.10-europe_spain.mbtiles is valid MBTiles.
We have tested two Docker versions of tileserver-gl, v2.3.1 and v2.6.0, with old map data from Openmaptiles.com, osm-2018-05-13-v3.8-europe_spain.mbtiles for example, and everything works fine. We have downloaded map data two times just to check if first downloaded map data file was corrupt. What are we doing wrong?
We also miss a compatibility matrix that enables Openmaptiles subscribers to match tileserver-gl versions with Openmaptiles.com map data versions, as well as the ability to download updated map data for other Openmaptiles.com map versions than the latest, just to overcome these incompatibilities.
Best regards,
Santiago
Your file is very probably corrupted or not downloaded correctly.
You can verify its MD5 hash sum, using md5sum <filename>, which has to correspond with MD5 value on the webpage - https://openmaptiles.com/downloads/tileset/osm/europe/spain/
We recommend to download with wget -c <link>.
Sorry for the inconvenience.
It was a file permissions issue.
Related
Geoserver version 2.20.1
I am attempting to register a PostGIS table as a layer in Geoserver.
Here is my Curl command in bash
curl -v -u $GEOSERVER_ADMIN_USER:$GEOSERVER_ADMIN_PASSWORD \
-XPOST -H "Content-type: text/xml" \
-d "\
<featureType>
<name>$dataset</name>\
<title>$dataset</title>\
<nativeCRS class='projected'>EPSG:4326</nativeCRS><srs>EPSG:4326</srs>\
<nativeBoundingBox>\
<minx>-94.0301461140306003</minx>\
<maxx>-91.0935619356926054</maxx>\
<miny>46.5128696410899991</miny>\
<maxy>47.7878144308049002</maxy>\
<crs class='projected'>EPSG:4326</crs>\
</nativeBoundingBox>
</featureType>" \
http://geoserver:8080/geoserver/rest/workspaces/foropt/datastores/postgis/featuretypes
where $dataset is the name of the table.
Here is the error I am getting:
The retquest has not been applied because it lacks valid
authentication credentialsn for the target resource.
I have never seen this error before.
And I can't see how it's an issue with my credentials, since I am successfully performing other tasks (such as importing GeoTIFFs) within the same bash script using the same credentials. What is going on here?
In this situation, Geoserver is setup alongside PostGIS in a docker-compose arrangement.
Interestingly enough, when I first posted, I was using Postgres version 14, PostGIS version 3.1.
When I revert back to using Postgres version 13, the error goes away (well, a new one crops up but it seems to be a separate issue--you know how it goes). ¯_(ツ)_/¯
I'm not familiar enough with Postgres versions to say what difference it made by reverting back to version 13 (maybe there are security changes at version 14??), but it worked for me.
I am trying to run mongodb-community#4.2 service using brew services start mongodb-community#4.2 (facing similar error, while running httpd service or any other service)
Following is the error:
Error: Failure while executing; /bin/launchctl bootstrap gui/502 /Users/chiragsingla/Library/LaunchAgents/homebrew.mxcl.mongodb-community#4.2.plist exited with 5.
There can be multiple reasons behind this error message. So, the first thing to do is to find where your mongo related logs are stored. To do that, run the following command -
sudo find / -name mongod.conf
This will get you the mongo db config file. On running this command, I got /usr/local/etc/mongod.conf. You may find it directly under /etc.
On opening mongod.conf, you will find log path mentioned there. You can open the file itself, or instead get the last 15-20 lines of this log file via tail command -
tail -n 15 <<your mongo db log path>>
Now, you will need to debug the issue mentioned in the logs. Generally, I have seen these three sets of issues -
Permission issue with /tmp/mongodb-27017.sock - While some SO answers asked to change the permissions for this file as a solution, my issue with this only went away after I removed this file.
Compatibility issue - If you see a message like Version incompatibility detected, it means that the mongodb version you have currently installed is different from the version whose data is present on your system. Uninstall the current mongodb version and then install the correct older version (if you don't want to lose the data).
Once you have done it, and your mongo is up and running, and you want to upgrade mongodb version, follow this SO answer.
Permission issues with WiredTiger - Using chmod to change file permissions resolved these.
In case you have any issue other than these three, you will still need to search more on SO and figure it out. Hope this was of some help! :)
I'm trying to connect Tarantool Docker Image to local PostgreSQL, to replicate some test data, and ran into the following problems:
It seems there is no CL (except Tarantool console) to check which
files are in place (exec bin/bash fails)
pg = require('pg') leads to
an error: "init.lua:4: module 'pg.driver' not found", despite the
presence of the pg module in the Docker description
I have doubts about how to replicate efficiently 4 tables, and
relations between them, to the container from outside Postgres
Does anyone know sources to dig in and find solutions to those problems? Any direction would be greatly appreciated.
docker exec -ti tnt_container sh
the issue. You should find an older base image or build it yourself.
This is PostgreSQL-related doubts. You may pass batches of data to pg functions or use intermediate application to transfer data via COPY. It looks like tarantool's pg driver does not support COPY.
I am trying to back up the config and database files from an existing LDAP server to move it to a different freshly installed server (Ubuntu 18.04). I followed the steps given here: https://tylersguides.com/articles/backup-restore-openldap/ to use slapcat to create both config and data ldif files.
When I execute slapadd on the server side,
slapadd -n 0 -F /etc/openldap/slapd.d -l /backups/config.ldif works fine, but executing
slapadd -n 1 -F /etc/openldap/slapd.d -l /backups/data.ldif gives the following error:
Database number selected via -n is out of range
Must be in the range 0 to 0 (the number of configured databases)
All the sites I have been able to find regarding this migration process follow steps similar to the ones above, but none of them mention anything about preconfiguring the number of databases or anything like that. I'm not sure how to proceed from here.
almost sure that you did a mistake during dump and the content of the second file is the same as the config file
Try removing -F /etc/openldap/slapd.d from the second slapadd.
What is version number supposed to represent in this CLI command: pg_ctl -D /usr/local/var/postgres[VERSION NUMBER HERE] start ?
VERSION NUMBER HERE usually refers to the major version number (not patch/minor release).
So if you have version 10.3 installed, it should refer to 10
Note that in 9.6 and earlier, major versions had two digits, followed by a patch version (example: 9.5.4 -- major version is 9.5, minor version is 4).
However, what's more important than the version is what folder exists at /usr/local/var -- You could have a data directory that has no versions (i.e., you can do initdb /tmp/foo and all your data will go into foo, and pg_ctl -D /tmp/foo start should get your database started). A good rule of thumb (though there are situations where this fails) is to look for the directory containing postgresql.conf, and that directory is what you would pass as an argument to pg_ctl -D <dir> start
Disclosure: I am an EnterpriseDB (EDB) employee
By including the version number of the Postgres version in the name of the data directory allows you to have multiple clusters (=instances) running at the same time using the same binaries.
Including the version number in the name of the data directory is not mandatory though, and whether it was done during installation or not depends on which Linux distribution you are using. Every distribution does this slightly differently.
But typically you don't start Postgres through pg_ctl but through the systems "service manager", e.g. systemctl or service depending on the Linux distribution. You can check the service definition where the exact location of the data directory is.