blog.crox.net

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:

[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.

• On Raspbian, you don't need to install the 8192cu driver manually, as it comes with the distribution


• To avoid disconnection issues, you need however to disable power management. This needs to be done in two places. First, this is what I have in /etc/modprobe.d/8192cu.conf:

  options 8192cu rtw_power_mgnt=0 rtw_enusbss=0



• This alone did not prevent the issue. I also had to add this entry to /etc/network/interfaces:

  auto wlan0
  allow-hotplug wlan0
  iface wlan0 inet dhcp
  wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
  wireless-power off
  iface default inet dhcp

Sources: https://github.com/xbianonpi/xbian/issues/217, https://www.kuerbis.org/2016/03/raspberry-pi-3-kurztipps-wlan-sleep-mode-verhindern/