Skip to content

All-black maps with staticmaplite (OSM static map generation - Access control configuration prevents your request from being allowed)

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.

IPv6 Neighbor discovery

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

backuppc "no ping response" when ping works fine

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

Grafana PNG export on headless Debian server (phantomjs / render fails with "404 page not found")

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" "$@"

Grafana auto login

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:

[auth.proxy]
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):

<VirtualHost *:80>
ProxyPreserveHost On
ProxyRequests Off
ProxyPass / http://localhost:3000/
ProxyPassReverse / http://localhost:3000/
RequestHeader set "X-WEBAUTH-USER" "admin"
</VirtualHost>

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)

<VirtualHost *:80>
ServerName sub.example.org
ServerAlias www.sub.example.org
<Location />
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
</Location>
ProxyPreserveHost On
ProxyRequests Off
ProxyPass / http://[2001:0db8:85a3::aaaa:8a2e:0370:7334]/
ProxyPassReverse / http://[2001:0db8:85a3::aaaa:8a2e:0370:7334]/
</VirtualHost>

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.