I've been using the staticmaplite
library for a while to generate static maps based on OSM tiles.
Recently I started getting the following error when downloading tiles:
Access control configuration prevents your request from being allowed at this time. Please contact your service provider if you feel this is incorrect.
The OSM team was very responsive when I contacted them and they pointed me to https://operations.osmfoundation.org/policies/tiles/
Based on that info, I checked how staticmap.php was fetching tiles and noticed that the User-Agent string was hardcoded to "Mozilla/4.0". I fixed this and now I can fetch tiles again. You can get the updated version from here: https://github.com/crox-net/staticmaplite
Discover/list other hosts:
ping6 -I eth0 ff02::1
ip -6 neigh show
To connect to a host using the link-local address you need to specify which interface to use (see "zone index
ssh -6 fe80::a00:aaaa:bbbb:cccc%eth0
It took me some time to figure this out, maybe it can be useful to someone else...
I kept getting "no ping" error for unknown reasons. It turned out that I had enabled DumpPreUserCmd and UserCmdCheckStatus for that specific host to check for an encrypted partition being mounted.
Due to some changes on the host after an upgrade, the script triggered by DumpPreUserCmd was returning an error... And for some reason this showed as a ping error in the web interface.
I eventually figured it out by checking the last lines of the LOG.** file in the pc/[host] directory, which looked like this:
2018-05-08 19:15:45 Output from DumpPreUserCmd: /[partition] is not mounted
2018-05-08 19:15:45 DumpPreUserCmd returned error status 256... exiting
If it still fails after you've set "root_url" to the correct value in grafana.ini, you might want to check whether you can run phantomjs from the command line.
If you get "QXcbConnection: Could not connect to display / PhantomJS has crashed", then the explanation is here: Debian Bug #817277
To fix it, I installed xvfb (apt-get install xvfb
), and edited /usr/bin/phantomjs
so that the last line now looks like this:
exec "/usr/bin/xvfb-run" --server-args="-screen 0 640x480x16" "/usr/lib/phantomjs/phantomjs" "$@"
The solution described here
works for me.
I did the following on the internal host where Grafana is installed:
- Configured Apache (on port 80) as reverse proxy to Grafana (on port 3000)
- Setup the virtualhost to add/set the required headers to login automatically as user admin
Relevant section from /etc/grafana/grafana.ini:
enabled = true
;header_name = X-WEBAUTH-USER
;header_property = username
auto_sign_up = false
Apache config extract (you will need to enable mod_proxy, mod_proxy_http and mod_headers for this to work):
ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/
RequestHeader set "X-WEBAUTH-USER" "admin"
On a separate Apache instance exposed to more networks I did the following:
- Configured Apache as reverse proxy to the internal instance
- Restricted access from specific IP addresses
- Setup a rule to redirect requests to the root of the website (and only those) to a specific dashboard
This is how the Apache config looks like (requires mod_proxy, mod_proxy_http and mod_alias; IP addresses, host names etc. changed)
Require ip 192.0.2.0/24
Require ip 203.0.113.0/24
Require ip 2001:0db8:85a4::/64
Require ip 2001:0db8:85a5::/64
RedirectMatch ^/$ /dashboard/db/mydashboard
ProxyPass / http://[2001:0db8:85a3::aaaa:8a2e:0370:7334]/
ProxyPassReverse / http://[2001:0db8:85a3::aaaa:8a2e:0370:7334]/
Using a public IPv6 address on the internal host allows the whole thing to work with just a few firewall rules, without the need to mess with NAT or a VPN.