System Stats & Management¶

DietPi-Dashboard is accessible by default via HTTPS at TCP port 5252:

• URL: https://<your.IP>:5252
• Password: <your software password> (default: dietpi)

For communication between the web UI and the backend nodes, by default TCP port 5253 is additionally used.

The DietPi-Dashboard executable and its configuration files can be found at:

/opt/dietpi-dashboard

The configuration files for the frontend (web UI) and backend (system node) are located at:

/opt/dietpi-dashboard/config-frontend.toml
/opt/dietpi-dashboard/config-backend.toml

When doing changes, you need to restart the respective service afterwards:

systemctl restart dietpi-dashboard-frontend
systemctl restart dietpi-dashboard-backend

To change the password for the web UI, create a SHA512 hash of the PASSWORD you want to use for login. Apply it to the frontend configuration file and restart the service for the change to take effect:

hash=$(echo -n 'PASSWORD' | sha512sum | mawk '{print $1}')
GCI_PASSWORD=1 G_CONFIG_INJECT 'hash[[:blank:]]' "hash = \"$hash\"" /opt/dietpi-dashboard/config-frontend.toml
unset -v hash
G_CONFIG_INJECT 'enable_login[[:blank:]]' 'enable_login = true' /opt/dietpi-dashboard/config-frontend.toml
systemctl restart dietpi-dashboard

The new DietPi-Dashboard consists of two components, the frontend which provides the web interface, and the backend which enables communication with the system. One frontend can be used with multiple backend nodes, and when installing the dashboard with dietpi-software, it is possible to install the backend only, to use it with a frontend installed on another system already. The backend-only installation will ask for the needed info, but in case of non-interactive/automated installation, or if you want to change or setup this later:

1. Check /opt/dietpi-dashboard/config-frontend.toml on the frontend host, or the “Config” page on its web UI. There is a secret setting, and a backend_port setting, which defaults to 5253.
2. Open /opt/dietpi-dashboard/config-backend.toml on the host of the backend node. Replace secret to match the one from the frontend, and frontend_addr with IP:port of the frontend.

3. Restart the backend service:

   systemctl restart dietpi-dashboard-backend
   

DietPi-Dashboard by default is started as systemd services for frontend and backend, and can hence be controlled with the following commands:

systemctl status dietpi-dashboard-frontend
systemctl status dietpi-dashboard-backend

systemctl stop dietpi-dashboard-frontend
systemctl stop dietpi-dashboard-backend

systemctl start dietpi-dashboard-frontend
systemctl start dietpi-dashboard-backend

systemctl restart dietpi-dashboard-frontend
systemctl restart dietpi-dashboard-backend

Service logs can be reviewed with the following command:

journalctl -u dietpi-dashboard-frontend -u dietpi-dashboard-backend

You can easily update DietPi-Dashboard by reinstalling it and restarting the services for the change to take effect:

dietpi-software reinstall 200
systemctl restart dietpi-dashboard-frontend
systemctl restart dietpi-dashboard-backend

Launch the DietPi-CloudShell control panel:

dietpi-cloudshell

DietPi-CloudShell offers scenes with predefined display outputs resp. layouts.
Scenes are configured in the Scenes dialog within dietpi-cloudshell.

This feature will allow you to automatically power down the screen and disable DietPi-CloudShell processing during a specific time.
Please note this feature requires DietPi-CloudShell to be launched with dietpi-autostart, or run dietpi-cloudshell from the main screen (tty1).
If you make changes to DietPi-CloudShell over SSH, once saved, please reboot the system to ensure this feature becomes activated.

Power saving: Auto screen off

See https://www.waveshare.com/3.2inch-rpi-lcd-b.htm.
This is available for all Raspberry Pi and Odroid versions. DietPi will automatically configure your system for the device.
Simply run dietpi-config, select Display Options, then select waveshare32.
After a reboot, your Waveshare32 will become active.

See https://www.hardkernel.com/shop/c1-3-2inch-tfttouchscreen-shield/.
This is available for all Odroid versions. DietPi will automatically configure your system for the device.
Simply run dietpi-config, select Display Options, then select odroid-lcd35.
After a reboot, your Odroid 3.5 LCD will become active.

The display feature of DietPi-CloudShell works generally with any LCD display or monitor with a resolution of at least 320x240 pixels.

The web interface of Linux Dash can be accessed via:

• URL = http://<your.IP>/linuxdash/app

The web interface of phpSysInfo can be accessed via:

• URL = http://<your.IP>/phpsysinfo

This is done via the file phpsysinfo.ini which is located in the phpSysInfo main directory (typical /var/www/phpsysinfo). An example file phpsysinfo.ini.new is present and gives inline information about all configuration options. Just walk through this file and discover all these bells an whistles.

The main features of RPi-Monitor are:

• Collecting, storing and presenting metrics
• It’s flexibly configurable
• It’s user extendable
• Metrics sharing can be done via JSON file or via SNMP
• Alert option

The web interface is accessible via port 8888:

• URL = http://<your.IP>:8888

The configuration is described there: https://xavierberger.github.io/RPi-Monitor-docs/20_index.html

The web interface is accessible via port 19999:

• URL = http://<your.IP>:19999

Depending on your system, by default Netdata might be not accessible from remote browsers. If this is the case, open the configuration file
/etc/netdata/netdata.conf
and change the line
bind socket to IP = 127.0.0.1
to match either the local network IP or static public IP of your DietPi server depending on your needs. Alternatively comment it e.g. if your server does not have a static public IP but you require remote access. But note that an unprotected publicly accessible Netdata web interface is a potential security risk. Head over to the “Security hardening” tab to learn more about how to restrict access to Netdata.

Once saved, you will need to restart the service to implement the changes by entering the below into the terminal:

systemctl restart netdata

Note that having Netdata accessible to anyone gives potential attackers a bunch of useful information where to start hacking.
To learn about how to limit access to Netdata, please refer to their documentation regarding the configuration of access lists.

The web interface is accessible via HTTPS on port 10000:

• URL: https://<your.IP>:10000
• Username: root (or any UNIX user with full sudo permissions)
• Password: <this UNIX user's password> (default: dietpi)

Since Webmin runs as a systemd service, it can be controlled with the following commands:

systemctl status webmin

systemctl start webmin

systemctl stop webmin

systemctl restart webmin

Since Webmin is installed as APT package, it can be updated with the following commands:

apt update
apt install webmin

Webmin service logs can be accessed with the following command:

journalctl -u webmin

The Docker configuration files are located at:

• Docker: /etc/docker/daemon.json
• containerd: /etc/containerd/config.toml

Since Docker is installed via APT packages, it can be updated by running the following commands:

apt update
apt upgrade

Docker logs can be accessed using next command:

journalctl -u docker -u containerd

Docker offers plugins on its website (e.g. Docker Plugins amd64 stable), some of them are not installed by the Docker installation by default resp. are no install option from dietpi-software (like the Docker Compose plugin is one).
These additional plugins can be installed by the user as described below.

Docker Buildx CLI plugin:

apt install docker-buildx-plugin

Docker vulnerability scan CLI plugin:

apt install docker-scan-plugin

For running container rootless:

apt install docker-ce-rootless-extras

Docker downloads image file chunks to /mnt/dietpi_userdata/docker-data/tmp when generating a Docker image. After this, the file chunks are deleted as they are only temporary files.
In case of a slower disk (e.g. SD Card) this takes a longer time due to the SD Card reading/writing speed. To speedup the image generation, a tmpfs file system can be used.
A drawback of using a tmpfs is the required RAM, i.e. enough RAM memory (e.g. > 2 GB) should be present for the tmpfs.

The tmpfs file system can be added manually via the file /etc/fstab by entering a line (e.g. in the TMPFS area) like:

tmpfs /mnt/dietpi_userdata/docker-data/tmp tmpfs size=2G,noatime,lazytime,nodev,nosuid

The size= option should be adjusted to the systems RAM size: Only a part of the total RAM size should be used to avoid low memory issues.
After changing the file /etc/fstab the tmpfs needs to be activated. This can be done via a file system remount via

mount -o remount /mnt/dietpi_userdata/docker-data/tmp

or a system reboot.

Since Docker Compose is installed via APT package, it can be updated by running the following commands:

apt update
apt upgrade

The web interface is accessible via HTTPS on port 9442¹:

• URL = https://<your.IP>:9442

To update Portainer, simply reinstall it:

dietpi-software reinstall 185

The default installation of K3s creates a single-node cluster. If you want to have a multi-node setup, you need to configure the nodes to speak to the others.

In /boot/dietpi.txt, edit the SOFTWARE_K3S_EXEC parameter to set command (server or agent). You can add other command-line parameters after the command.

Example:

SOFTWARE_K3S_EXEC=server --disable=local-storage

If you need to add many command-line parameters, it is recommended to put them in a file instead, keeping only the command (server or agent) in /boot/dietpi.txt. During installation, if /boot/dietpi-k3s.yaml exists, it is copied to /etc/rancher/k3s/config.yaml, and used by K3s. The format of this file is documented in the K3s docs.

When running in server mode, K3s generates a kubeconfig file at /etc/rancher/k3s/k3s.yaml. Copy this to your client machine, and edit the server setting to point to the hostname of the server.

Place the file in the default location (~/.kube/config), or point to it using the KUBECONFIG environment-variable.

You should now be able to interact with your Kubernetes cluster using kubectl:

kubectl get nodes
kubectl get pods -A

• Service: journalctl -u k3s

To create a cluster out of two or more already-running MicroK8s instances, use the microk8s add-node command:

microk8s add-node

From the node you wish to join to this cluster, run the following:

microk8s join 192.168.1.230:25000/92b2db237428470dc4fcfc4ebbd9dc81/2c0cb3284b05

Use the --worker flag to join a node as a worker not running the control plane, e.g.:

microk8s join 192.168.1.230:25000/92b2db237428470dc4fcfc4ebbd9dc81/2c0cb3284b05 --worker

For most commands, you can use microk8s in front like below.

microk8s kubectl get nodes
microk8s kubectl get namespaces

MicroK8s does provide a few “addons”, which can be seen below with the enable and disable command.

microk8s status # to view the addons
microk8s enable dns # to enable addons
microk8s enable dashboard # to enable Kubernetes dashboard

Per-node log files can be in:

/var/log/pods

The metrics endpoint of Prometheus Node Exporter is exposed at TCP port 9100 and can be accessed via:

• URL = http://<your.IP>:9100/metrics

Your Prometheus server needs to be configured in order to scrape Node Exporter metrics. Full configuration of the Prometheus server is outside the scope of this documentation, but here is a sample prometheus.yml file for reference:

global:
  scrape_interval: 15s

scrape_configs:
- job_name: your.hostname
  static_configs:
  - targets: ['your.IP:9100']

There are many pre-made templates of Grafana dashboards for visualizing data collected from a Prometheus Node Exporter. A good starting point is Node Exporter Full. You can import it directly into your Grafana instance by using ID 1860.

Since Prometheus Node Exporter runs as a systemd service, it can be controlled with the following commands:

systemctl status node_exporter

systemctl start node_exporter

systemctl stop node_exporter

systemctl restart node_exporter

Prometheus Node Exporter runs as a systemd service, hence logs can be viewed with the following command:

journalctl -u node_exporter

Prometheus Node Exporter can be updated by simply reinstalling it:

dietpi-software reinstall 99

The Homer dashboard can be accessed via:

• URL: http://<your.IP>/homer

You may bookmark this and save it as your browser’s home page, or alternatively look into tools like Nginx Proxy Manager and a DNS server such as AdGuard Home to give it a nice internal domain name such as homer.box.

To configure entries and icons for Homer, you can edit it’s config file /var/www/homer/assets/config.yml. Example contents:

services:
  - name: "Selfhosted"
    icon: "fas fa-cloud"
    items:
      - name: "Adguard Home"
        logo: "assets/icons2/adguard.png"
        subtitle: "A blackhole for the internet"
        tag: "Selfhosted"
        url: "https://adguard.box"
        target: "_blank"
      - name: "Nginx"
        logo: "assets/icons2/nginx.png"
        subtitle: "Reverse proxy - load balancer"
        tag: "Selfhosted"
        url: "https://nginx.box"
        target: "_blank"
      - name: "Shiori"
        logo: "assets/icons2/shiori.png"
        subtitle: "Web archiving + Read later"
        tag: "Selfhosted"
        url: "https://shiori.box"
        target: "_blank"
      - name: "Nextcloud"
        logo: "assets/icons2/nextcloud.png"
        subtitle: "A google suite alternative"
        tag: "Selfhosted"
        url: "https://nextcloud.box"
        target: "_blank"

In the example above, a column titled Selfhosted is being made which contains 4 entries. In the same directory as the config.yml, an icons2 folder exists, which contains icon images.

To update Homer simply re-run the installer by executing

dietpi-software reinstall 205

Remark: The dietpi-software script update procedure preserves the file config.yml automatically, there is no necessity for the user to do a restore manually.

If other files in /var/www/homer were previously changed by the user, they need to be copied in place (from the backup location /mnt/dietpi_userdata/homer_backup). As an example for a changed file manifest.json this could be done via:

cd /mnt/dietpi_userdata/homer_backup
mv manifest.json /var/www/homer/assets

You can customize Homer’s appearance by creating a theme, as described in the Homer documentation. Below are some community themes and examples of how to integrate them.