apt-get install influxdb

See dockerfile

Setup a database:

influx

CREATE DATABASE physical_data

verify with

SHOW DATABASES

Insert data with curl

curl -i -XPOST ‘http://:8086/write?db=physical_data’ –data-binary “cpu_temp,host= value=$(vcgencmd measure_temp | sed -e s/temp=//g | sed -e s/\‘C//g)”

Grafana

Set new password

Add influxdb source Enter url and database

By default, when launching webpack with awesome-typescript-loader, it will use the tsconfig.json file from the current working directory. In order to specify a different tsconfig.json, you have to add

        query: {
          configFileName: "./subdir/tsconfig.json"
        }

to the awesome-typescript-loader under module -> rules. An example for the complete entry is:

  …
  module: {
    rules: [
      // All files with a ‘.ts’ or ‘.tsx’ extension will be handled by ‘awesome-typescript-loader’.
      {

        test: /.tsx?$/,
        include: path.resolve(__dirname, ‘.’),
        loader: “awesome-typescript-loader”,
        query: {
          configFileName: “./subdir/tsconfig.json”
        }
      }
    ]
  },
  …

In a standard setup, docker will not assign ipv6 addresses to its containers. So if it is necessary to use ipv6 networking inside a docker container, you have to enable it manually, first.

Suggested on host ipv6 support in the docker host, Edit for create the file /etc/docker/daemon.json and enable ipv6:

{
  “ipv6”: true,
  “fixed-cidr-v6”: “fd00::/80”
}

Be aware, that in addition to the official docker documentation we are specifing a fixed private ipv6 network here. Otherwise we would receive the following error message:

ERROR: could not find an available, non-overlapping IPv6 address pool among the defaults to assign to the network

ip6tables -t nat -A POSTROUTING -s fd01::/80 -o eth0 -j MASQUERADE

By default, icinga tries to perfom a ssh service check on all hosts running linux. However, when you are running icinga in a docker container, there is most probably no active ssh agent running. In order to prevent icinga always showing an error, insert

  ignore where (host.address == "127.0.0.1") || (host.address == "localhost")

into the ssh service section in /etc/icinga2/conf.d/services.conf.

The result should look like this:

/*
 * Apply the ssh service to all hosts
 * with the address attribute defined and
 * the custom attribute os set to Linux.
 */
apply Service “ssh” {
  import “generic-service”

  check_command = “ssh”

  assign where (host.address || host.address6) && host.vars.os == “Linux”
  ignore where (host.address == “127.0.0.1”) || (host.address == “localhost”)
}

It is also possible to query a specific variable:

/*
 * Apply the `ssh` service to all hosts
 * with the `address` attribute defined and
 * the custom attribute `os` set to `Linux`.
 */
apply Service "ssh" {
  import "generic-service"

  check_command = "ssh"

  assign where (host.address || host.address6) && host.vars.os == "Linux"
  ignore where (host.address == "127.0.0.1") || (host.vars.ssh == "false")
}

So setting vars.ssh = “false” in any host disables the ssh check for a particular host.

Sometime you want to send mail from console, e.g. bash scripts without installing a fully featured mail server locally. A lightweight smtp client that fullfills this requirement is msmtp. It is capable of connecting to upstream mail server via smtp, support encrypted connection (TLS) and can easily be used with its command line interface. Install it on debian based system with:

apt-get install msmtp

The configuration is either done system wide in /etc/msmtprc or in ~/.msmtprc in your home directory. Because the password is stored within, it is a good idea to restrict read access to that file. There are plenty of tutorial on the web that use gpg for password encryption, but then you have to provide that password during sending of email and cannot use it unattended e.g. in shell scripts.

Here is an example configuration:

# Set default values for all following accounts.
defaults
port 25
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt

# Account specific information
account example
host <server name>
from <sender email address>
auth on
user <user name for smtp server>
password <password for smtp server>

# Set the default account
account default : example

Sending of mail involves calling

msmtp <receiver email address>

and entering the content. The mail is send by pressing <ctrl+d> which emits the end of file (EOF) signal. In order to set the subject, just enter

Subject: <subject>

as first line. All of this can be done from a shell script as well:

#/bin/bash
echo `cat <<EOF
Subject: TestTest
This is a test
EOF` | msmtp <receiver email address>

Sometimes, it is necessary to start a program that uses X on a headless server, e.g. a remote virtual machine. If you do not really need UI interaction, e.g. using a mouse, then Xvfb is the right tool. Xfvb provides a X server implementation that renders the X commands not using a physical display driver, but only into a virtual frame buffer in main memory.

Before it can be used, it has to be installed, first. On Debian based systems, you enter:

sudo apt-get install xvfb

After installation, Xvfb is started by

Xvfb -ac :99 -screen 0 1280x1024x16

with a single screen of 1280 x 1024 pixels and a color depth of 16 bit on display 99. So in order to use it, you have to set the display environment variable accordingly:

export DISPLAY=:99

Sometime (e.g. when a machine is not booting anymore) it is necessary to fix some stuff by editing the root filesystem. Luckily this is much more simple when using virtual machine, than with real hardware. When a virtual machine is shut down, you can mount the virtual disk image on the host system and do not have to try to boot some kind of rescue system. Most important part of this is the qemu-nbd command. If not already installed, get it by e.g.

apt-get install qemu-utils

on a debian system. Then you can use a vdi file with

qemu-nbd -c /dev/nbd1 

If you get a

Failed to open /dev/nbd1: No such file or directory

then your kernel does not have the nbd module loaded already.

modprobe nbd max_part=8

will do the trick. If your image has more then 8 partition, you might want to increase that, but it seems to be the default on the internet.

Now the virtual disk image is available including its individual partitions as /dev/nbd1pX. So a simple

mount /dev/nbd1pX /mnt

allows fixing the stuff. Unmounting happens in the reverse order:

umount /mnt
qemu-nbd -d /dev/nbd1    # disconnects the image
rmmod nbd

After upgrading debian on a virtual machine, it was not booting properly anymore. The boot console showed

ifup waiting for lock on /run/network/interfaces/ ifstate.eth0

before coming to a login prompt. This can happen, if your network interface (in this case eth0) is configured on ‘allow-hotplug’ instead of ‘auto’ in /etc/network/interfaces. For comparison I suggest a quick search https://lmgtfy.com/?q=allow-hotplug+vs+auto, but apparently auto is the right setting for a build in nic. So you either have to boot some rescue system in order to change the /etc/network/interfaces configuration file, or in case of a virtual machine shut down the vm and mount the filesystem on the host.

While running Debian on a low memory machine (today probably only applicable for virtual machines) you see errors message like this?

Failed to reload daemon: Refusing to reload, not enough space available on /run/systemd.
Currently, 15.4M are free, but a safety buffer of 16.0M is enforced.

For example when running system updates:

apt-get install
apt-get update
apt-get upgrade

Then your /run tmpfs is already to small from the start. By default it is size as 10% of the available main memory, so with less then 256 MB RAM you are already close to that limit of 16.0M. Luckily, that can be changed in /usr/share/initramfs-tools/init. Search for the line

mount -t tmpfs -o “noexec,nosuid,size=${RUNSIZE:-10%},mode=0755” tmpfs /run

and change it to e.g.

mount -t tmpfs -o “noexec,nosuid,size=${RUNSIZE:-15%},mode=0755” tmpfs /run

Depending on the amount of available memory 15% might still be too small, so change accordingly. In order to apply the change during the boot, the init ramdisk has to be regenerated by calling:

update-initramfs -u

Reboot and the issue is gone.

Visual Studio Code has recently changed its default debug protocol for the launch type of debug configuration. In the passed, they assumed node’s legacy protocol, however with recent versions of vscode, they try connecting with inspector instead. The attach still prefers the legacy protocol. If you have problem debugging with older nodejs version using launch configuration, where an attach to a running nodejs instance works without problems, you probably stumbled about this. The solution is quite simple. Just embedd the following line in your launch configuration:

“protocol”: “legacy”