From d3f67d1475aa98488c92b9546f96cdc9925031f9 Mon Sep 17 00:00:00 2001 From: ukkopahis <95980324+ukkopahis@users.noreply.github.com> Date: Mon, 13 Dec 2021 20:08:09 +0200 Subject: [PATCH 01/11] use GITHUB_TOKEN for better security see: https://docs.github.com/en/actions/security-guides/automatic-token-authentication --- .github/workflows/main.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index d8887048..b2767349 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -15,4 +15,4 @@ jobs: - name: Deploy docs uses: mhausenblas/mkdocs-deploy-gh-pages@master env: - PERSONAL_TOKEN: ${{ secrets.PERSONAL_TOKEN }} + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} From f54fe2037c88907d1b9d97ef7c453cc16151077e Mon Sep 17 00:00:00 2001 From: Brian Choromanski Date: Thu, 20 Jan 2022 05:48:09 -0500 Subject: [PATCH 02/11] Removed executable file permissions from non executable files --- .templates/deconz/hardware_list.yml | 0 .templates/env.yml | 0 .templates/example_template/example_service.yml | 0 .templates/nodered/addons.yml | 0 .templates/webthings_gateway/local.json | 0 .templates/zigbee2mqtt_assistant/service.yml | 0 docs/Backup-and-Restore.md | 0 docs/BuildStack-RandomPassword.md | 0 docs/BuildStack-Services.md | 0 docs/Containers/Zigbee2mqttassistant.md | 0 docs/Contributing-Services.md | 0 docs/Default-Configs.md | 0 docs/Menu-System.md | 0 docs/New-Menu-Release-Notes.md | 0 docs/PostBuild-Script.md | 0 scripts/deps/.gitignore | 0 16 files changed, 0 insertions(+), 0 deletions(-) mode change 100755 => 100644 .templates/deconz/hardware_list.yml mode change 100755 => 100644 .templates/env.yml mode change 100755 => 100644 .templates/example_template/example_service.yml mode change 100755 => 100644 .templates/nodered/addons.yml mode change 100755 => 100644 .templates/webthings_gateway/local.json mode change 100755 => 100644 .templates/zigbee2mqtt_assistant/service.yml mode change 100755 => 100644 docs/Backup-and-Restore.md mode change 100755 => 100644 docs/BuildStack-RandomPassword.md mode change 100755 => 100644 docs/BuildStack-Services.md mode change 100755 => 100644 docs/Containers/Zigbee2mqttassistant.md mode change 100755 => 100644 docs/Contributing-Services.md mode change 100755 => 100644 docs/Default-Configs.md mode change 100755 => 100644 docs/Menu-System.md mode change 100755 => 100644 docs/New-Menu-Release-Notes.md mode change 100755 => 100644 docs/PostBuild-Script.md mode change 100755 => 100644 scripts/deps/.gitignore diff --git a/.templates/deconz/hardware_list.yml b/.templates/deconz/hardware_list.yml old mode 100755 new mode 100644 diff --git a/.templates/env.yml b/.templates/env.yml old mode 100755 new mode 100644 diff --git a/.templates/example_template/example_service.yml b/.templates/example_template/example_service.yml old mode 100755 new mode 100644 diff --git a/.templates/nodered/addons.yml b/.templates/nodered/addons.yml old mode 100755 new mode 100644 diff --git a/.templates/webthings_gateway/local.json b/.templates/webthings_gateway/local.json old mode 100755 new mode 100644 diff --git a/.templates/zigbee2mqtt_assistant/service.yml b/.templates/zigbee2mqtt_assistant/service.yml old mode 100755 new mode 100644 diff --git a/docs/Backup-and-Restore.md b/docs/Backup-and-Restore.md old mode 100755 new mode 100644 diff --git a/docs/BuildStack-RandomPassword.md b/docs/BuildStack-RandomPassword.md old mode 100755 new mode 100644 diff --git a/docs/BuildStack-Services.md b/docs/BuildStack-Services.md old mode 100755 new mode 100644 diff --git a/docs/Containers/Zigbee2mqttassistant.md b/docs/Containers/Zigbee2mqttassistant.md old mode 100755 new mode 100644 diff --git a/docs/Contributing-Services.md b/docs/Contributing-Services.md old mode 100755 new mode 100644 diff --git a/docs/Default-Configs.md b/docs/Default-Configs.md old mode 100755 new mode 100644 diff --git a/docs/Menu-System.md b/docs/Menu-System.md old mode 100755 new mode 100644 diff --git a/docs/New-Menu-Release-Notes.md b/docs/New-Menu-Release-Notes.md old mode 100755 new mode 100644 diff --git a/docs/PostBuild-Script.md b/docs/PostBuild-Script.md old mode 100755 new mode 100644 diff --git a/scripts/deps/.gitignore b/scripts/deps/.gitignore old mode 100755 new mode 100644 From 45ca88233d603388826d45e08d9f888d6696e7ef Mon Sep 17 00:00:00 2001 From: Peter Kullmann Date: Sun, 23 Jan 2022 09:24:01 +0100 Subject: [PATCH 03/11] Allow cli parameters to be given It's useful to give command line parameters to influxdb like this: .templates/influxdb/terminal.sh -precision rfc3339 This change just gives parameters on to the influx command. --- .templates/influxdb/terminal.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.templates/influxdb/terminal.sh b/.templates/influxdb/terminal.sh index 6486beb8..5a3573d1 100755 --- a/.templates/influxdb/terminal.sh +++ b/.templates/influxdb/terminal.sh @@ -12,4 +12,4 @@ echo "to exit type: EXIT" echo "" echo "docker exec -it influxdb influx" -docker exec -it influxdb influx +docker exec -it influxdb influx $* From 8754d3bf482d7bef50c9523c292dc45adbb8f71a Mon Sep 17 00:00:00 2001 From: heyimjonas <48453988+heyimjonas@users.noreply.github.com> Date: Sun, 23 Jan 2022 02:52:34 +0100 Subject: [PATCH 04/11] add doc for dozzle add doc for dozzle with correct port --- docs/Containers/Dozzle.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 docs/Containers/Dozzle.md diff --git a/docs/Containers/Dozzle.md b/docs/Containers/Dozzle.md new file mode 100644 index 00000000..04d7031b --- /dev/null +++ b/docs/Containers/Dozzle.md @@ -0,0 +1,12 @@ +# Dozzle + +## Reference +* [Dozzle GitHub](https://github.com/amir20/dozzle) + +## Webinterface +Webninterface is available at `"your_ip":8889` + + +## About *Dozzle* +Dozzle is a small lightweight application with a web based interface to monitor Docker logs. +It doesn’t store any log files. It is for live monitoring of your container logs only. \ No newline at end of file From b57ec0214c62d4aee11c9a51bf03df8bd63b8126 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien?= Date: Wed, 26 Jan 2022 09:12:22 +0100 Subject: [PATCH 05/11] Allow using BT and BLE devices from HA This closes #484 by allowing the powering on of bluetooth inside the Home Assistant container and using the `hci` devices otherwise not accessible. This was initiated to be able to use the Airthings Wave Plus device that uses BLE from an integration interacting with `bluetoothd` and the `/dev/hci` directly. --- .templates/home_assistant/service.yml | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/.templates/home_assistant/service.yml b/.templates/home_assistant/service.yml index 54692d8b..a03c4b1e 100644 --- a/.templates/home_assistant/service.yml +++ b/.templates/home_assistant/service.yml @@ -8,4 +8,9 @@ home_assistant: volumes: - /etc/localtime:/etc/localtime:ro - ./volumes/home_assistant:/config - + - /var/run/dbus/system_bus_socket:/var/run/dbus/system_bus_socket + devices: + - "/dev/ttyAMA0:/dev/ttyAMA0" + - "/dev/vcio:/dev/vcio" + - "/dev/gpiomem:/dev/gpiomem" + privileged: true From 51631e0af7a95de8d178e92ac1de7dc8f27d4322 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien?= Date: Wed, 26 Jan 2022 09:23:09 +0100 Subject: [PATCH 06/11] Update the documentation about BT in container --- docs/Containers/Home-Assistant.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/docs/Containers/Home-Assistant.md b/docs/Containers/Home-Assistant.md index 8e886674..f823163c 100644 --- a/docs/Containers/Home-Assistant.md +++ b/docs/Containers/Home-Assistant.md @@ -316,3 +316,22 @@ Random MACs are not a problem for a **client** device like a phone, tablet or la > In TCP/IP any device can be a client or a server for any protocol. The distinction here is about *typical* use. A mobile device is not usually set up to *offer* services like MQTT or Node-RED. It typically *initiates* connections with servers like Docker containers running on a Raspberry Pi. It is not just configuration-time SSH sessions that break. If you decide to leave Raspberry Pi random Wifi MAC active **and** you have other clients (eq IoT devices) communicating with the Pi over WiFi, you will wrong-foot those clients each time the Raspberry Pi reboots. Data communications services from those clients will be impacted until those client devices time-out and catch up. + +# Using bluetooth from the container +In order to be able to use BT & BLE devices from HA integrations, make sure that bluetooth is enabled and powered on at the start of the (Rpi) host by editing `/etc/bluetooth/main.conf`: + +```conf +.... +[Policy] +AutoEnable=true +``` + +After a reboot, check that BT is up: + +```sh +(root) # hciconfig +... +UP +... +``` +ref: https://scribles.net/auto-power-on-bluetooth-adapter-on-boot-up/ From 9c8f75022d9dfd1be3b4ba543a3ada1c3e036cc2 Mon Sep 17 00:00:00 2001 From: Peter Kullmann Date: Tue, 1 Feb 2022 16:18:29 +0100 Subject: [PATCH 07/11] Update terminal.sh --- .templates/influxdb/terminal.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.templates/influxdb/terminal.sh b/.templates/influxdb/terminal.sh index 5a3573d1..54c464e5 100755 --- a/.templates/influxdb/terminal.sh +++ b/.templates/influxdb/terminal.sh @@ -12,4 +12,4 @@ echo "to exit type: EXIT" echo "" echo "docker exec -it influxdb influx" -docker exec -it influxdb influx $* +docker exec -it influxdb influx "$@" From 58f1d0fe347afdfbca5da10c0bcbf2067988cf7c Mon Sep 17 00:00:00 2001 From: Phill Kelley <34226495+Paraphraser@users.noreply.github.com> Date: Sat, 5 Feb 2022 10:35:43 +1100 Subject: [PATCH 08/11] 20220206 prometheus - master branch - PR 1 of 2 Uses `prometheus-` prefix consistently for subordinate containers (service name, container name, dependency name) to address concern raised in comment to [Issue 472](https://github.com/SensorsIot/IOTstack/issues/472#issuecomment-1030104238). Documentation updated. Signed-off-by: Phill Kelley <34226495+Paraphraser@users.noreply.github.com> --- .templates/prometheus-cadvisor/service.yml | 2 +- .templates/prometheus-nodeexporter/service.yml | 2 +- .templates/prometheus/service.yml | 4 ++-- docs/Containers/Prometheus.md | 14 +++++++++----- 4 files changed, 13 insertions(+), 9 deletions(-) diff --git a/.templates/prometheus-cadvisor/service.yml b/.templates/prometheus-cadvisor/service.yml index 96cfd558..66c53af8 100644 --- a/.templates/prometheus-cadvisor/service.yml +++ b/.templates/prometheus-cadvisor/service.yml @@ -1,5 +1,5 @@ prometheus-cadvisor: - container_name: cadvisor + container_name: prometheus-cadvisor image: zcube/cadvisor:latest restart: unless-stopped ports: diff --git a/.templates/prometheus-nodeexporter/service.yml b/.templates/prometheus-nodeexporter/service.yml index 879968f3..517fbea5 100644 --- a/.templates/prometheus-nodeexporter/service.yml +++ b/.templates/prometheus-nodeexporter/service.yml @@ -1,5 +1,5 @@ prometheus-nodeexporter: - container_name: nodeexporter + container_name: prometheus-nodeexporter image: prom/node-exporter:latest restart: unless-stopped expose: diff --git a/.templates/prometheus/service.yml b/.templates/prometheus/service.yml index fa02549b..702678c8 100644 --- a/.templates/prometheus/service.yml +++ b/.templates/prometheus/service.yml @@ -18,6 +18,6 @@ prometheus: # - --web.console.libraries=/usr/share/prometheus/console_libraries # - --web.console.templates=/usr/share/prometheus/consoles depends_on: - - cadvisor - - nodeexporter + - prometheus-cadvisor + - prometheus-nodeexporter diff --git a/docs/Containers/Prometheus.md b/docs/Containers/Prometheus.md index c8a325e5..1bee676f 100644 --- a/docs/Containers/Prometheus.md +++ b/docs/Containers/Prometheus.md @@ -40,9 +40,9 @@ If you do not select all three containers, Prometheus will not start. When you select *Prometheus* in the IOTstack menu, the service definition includes the three containers: -* *Prometheus* -* *CAdvisor* -* *Node Exporter* +* *prometheus* +* *prometheus-cadvisor;* and +* *prometheus-nodeexporter*. ## Significant directories and files @@ -142,7 +142,7 @@ The remaining instructions in the *Dockerfile* customise the *base image* to pro The *local image* is instantiated to become your running container. -When you run the `docker images` command after *Prometheus* has been built, you will see two rows for *Prometheus*: +When you run the `docker images` command after *Prometheus* has been built, you *may* see two rows for *Prometheus*: ```bash $ docker images @@ -154,7 +154,9 @@ prom/prometheus latest 3f9575991a6c 3 days ago 169MB * `prom/prometheus` is the *base image*; and * `iotstack_prometheus` is the *local image*. -You will see the same pattern in Portainer, which reports the *base image* as "unused". You should not remove the *base* image, even though it appears to be unused. +You *may* see the same pattern in Portainer, which reports the *base image* as "unused". You should not remove the *base* image, even though it appears to be unused. + +> Whether you see one or two rows depends on the version of `docker-compose` you are using and how your version of `docker-compose` builds local images. ### Dependencies: *CAdvisor* and *Node Exporter* @@ -316,6 +318,8 @@ Your existing *Prometheus* container continues to run while the rebuild proceeds The `prune` is the simplest way of cleaning up. The first call removes the old *local image*. The second call cleans up the old *base image*. +> Whether an old *base image* exists depends on the version of `docker-compose` you are using and how your version of `docker-compose` builds local images. + ### *Prometheus* version pinning If you need to pin *Prometheus* to a particular version: From 285aaeb84107f205190cac47073f82b794a18437 Mon Sep 17 00:00:00 2001 From: Phill Kelley <34226495+Paraphraser@users.noreply.github.com> Date: Sat, 5 Feb 2022 11:02:52 +1100 Subject: [PATCH 09/11] 20220206 documentation - master branch Documentation updated to make it clear that the visibility of both a local and base image in `docker images` and Portainer depends on the version of docker-compose. Modern docker-compose only shows the local image so only a single "prune" is needed when a local image is rebuilt atop a newly-updated base image from DockerHub. Affects documentation for Blynk Server, Mosquitto, NextCloud, Node-RED, Telegraf and Zigbee2MQTT. Prometheus documentation already updated in [PR487](https://github.com/SensorsIot/IOTstack/pull/487). Signed-off-by: Phill Kelley <34226495+Paraphraser@users.noreply.github.com> --- docs/Containers/Blynk_server.md | 8 ++++++-- docs/Containers/Mosquitto.md | 8 +++++--- docs/Containers/NextCloud.md | 2 +- docs/Containers/Node-RED.md | 9 ++++++--- docs/Containers/Telegraf.md | 8 +++++--- docs/Containers/Zigbee2MQTT.md | 2 +- 6 files changed, 24 insertions(+), 13 deletions(-) diff --git a/docs/Containers/Blynk_server.md b/docs/Containers/Blynk_server.md index 10a8eca2..6985a867 100644 --- a/docs/Containers/Blynk_server.md +++ b/docs/Containers/Blynk_server.md @@ -115,7 +115,7 @@ The remaining instructions in the *Dockerfile* customise the ***base image*** to The ***local image*** is instantiated to become your running container. -When you run the `docker images` command after Blynk Server has been built, you will see two rows that are relevant: +When you run the `docker images` command after Blynk Server has been built, you *may* see two rows that are relevant: ```bash $ docker images @@ -127,7 +127,9 @@ ubuntu latest 897590a6c564 7 days ago 49.8MB * `ubuntu ` is the ***base image***; and * `iotstack_blynk_server ` is the ***local image***. -You will see the same pattern in *Portainer*, which reports the ***base image*** as "unused". You should not remove the ***base*** image, even though it appears to be unused. +You *may* see the same pattern in *Portainer*, which reports the ***base image*** as "unused". You should not remove the ***base*** image, even though it appears to be unused. + +> Whether you see one or two rows depends on the version of `docker-compose` you are using and how your version of `docker-compose` builds local images. ## Logging @@ -216,6 +218,8 @@ At the time of writing, version 0.41.16 was the most up-to-date. Suppose that ve $ docker system prune -f ``` + The second `prune` will only be needed if there is an old *base image* and that, in turn, depends on the version of `docker-compose` you are using and how your version of `docker-compose` builds local images. + ## Using Blynk Server See the [References](#references) for documentation links. diff --git a/docs/Containers/Mosquitto.md b/docs/Containers/Mosquitto.md index defa226e..d06e143d 100644 --- a/docs/Containers/Mosquitto.md +++ b/docs/Containers/Mosquitto.md @@ -128,7 +128,7 @@ The remaining instructions in the *Dockerfile* customise the *base image* to pro The *local image* is instantiated to become your running container. -When you run the `docker images` command after Mosquitto has been built, you will see two rows for Mosquitto: +When you run the `docker images` command after Mosquitto has been built, you *may* see two rows for Mosquitto: ```bash $ docker images @@ -140,7 +140,9 @@ eclipse-mosquitto latest 46ad1893f049 4 weeks ago 8.31MB * `eclipse-mosquitto` is the *base image*; and * `iotstack_mosquitto` is the *local image*. -You will see the same pattern in Portainer, which reports the *base image* as "unused". You should not remove the *base* image, even though it appears to be unused. +You *may* see the same pattern in Portainer, which reports the *base image* as "unused". You should not remove the *base* image, even though it appears to be unused. + +> Whether you see one or two rows depends on the version of `docker-compose` you are using and how your version of `docker-compose` builds local images. ### Migration considerations @@ -632,7 +634,7 @@ Breaking it down into parts: Your existing Mosquitto container continues to run while the rebuild proceeds. Once the freshly-built *local image* is ready, the `up` tells `docker-compose` to do a new-for-old swap. There is barely any downtime for your MQTT broker service. -The `prune` is the simplest way of cleaning up. The first call removes the old *local image*. The second call cleans up the old *base image*. +The `prune` is the simplest way of cleaning up. The first call removes the old *local image*. The second call cleans up the old *base image*. Whether an old *base image* exists depends on the version of `docker-compose` you are using and how your version of `docker-compose` builds local images. ### Mosquitto version pinning diff --git a/docs/Containers/NextCloud.md b/docs/Containers/NextCloud.md index 72c4448f..d88aa353 100644 --- a/docs/Containers/NextCloud.md +++ b/docs/Containers/NextCloud.md @@ -288,7 +288,7 @@ $ docker system prune $ docker system prune ``` -The first "prune" removes the old *local* image, the second removes the old *base* image. +The first "prune" removes the old *local* image, the second removes the old *base* image. Whether an old *base image* exists depends on the version of `docker-compose` you are using and how your version of `docker-compose` builds local images. ## Backups diff --git a/docs/Containers/Node-RED.md b/docs/Containers/Node-RED.md index ad1d629c..ee32ce4b 100644 --- a/docs/Containers/Node-RED.md +++ b/docs/Containers/Node-RED.md @@ -115,7 +115,7 @@ Notes: > Acknowledgement: Successful installation of the SQLite node is thanks to @fragolinux. -When you run the `docker images` command after Node-RED has been built, you will see two rows for Node-RED: +When you run the `docker images` command after Node-RED has been built, you *may* see two rows for Node-RED: ```bash $ docker images @@ -127,12 +127,14 @@ nodered/node-red latest deb99584fa75 5 days ago * `nodered/node-red` is the *base image*; and * `iotstack_nodered` is the *local image*. The *local* image is the one that is instantiated to become the running container. -You will see the same pattern in Portainer, which reports the *base image* as "unused": +You *may* see the same pattern in Portainer, which reports the *base image* as "unused": ![nodered-portainer-unused-image](./images/nodered-portainer-unused-image.png) You should not remove the *base* image, even though it appears to be unused. +> Whether you see one or two rows depends on the version of `docker-compose` you are using and how your version of `docker-compose` builds local images. + ## Securing Node-RED ### Setting an encryption key for your credentials @@ -858,7 +860,8 @@ Breaking it down into parts: Your existing Node-RED container continues to run while the rebuild proceeds. Once the freshly-built *local image* is ready, the `up` tells `docker-compose` to do a new-for-old swap. There is barely any downtime for your Node-RED service. -The `prune` is the simplest way of cleaning up old images. Sometimes you need to run this twice, the first time to clean up the old local image, the second time for the old base image. +The `prune` is the simplest way of cleaning up old images. Sometimes you need to run this twice, the first time to clean up the old local image, the second time for the old base image. Whether an old base image exists depends on the version of `docker-compose` you are using and how your version of `docker-compose` builds local images. + ## Customising Node-RED diff --git a/docs/Containers/Telegraf.md b/docs/Containers/Telegraf.md index f317f16a..7c07fac1 100644 --- a/docs/Containers/Telegraf.md +++ b/docs/Containers/Telegraf.md @@ -118,7 +118,7 @@ The remaining instructions in the *Dockerfile* customise the ***base image*** to The ***local image*** is instantiated to become your running container. -When you run the `docker images` command after Telegraf has been built, you will see two rows for Telegraf: +When you run the `docker images` command after Telegraf has been built, you *may* see two rows for Telegraf: ```bash $ docker images @@ -130,7 +130,9 @@ telegraf latest a721ac170fad 3 days ago 273MB * `telegraf ` is the ***base image***; and * `iotstack_telegraf ` is the ***local image***. -You will see the same pattern in *Portainer*, which reports the ***base image*** as "unused". You should not remove the ***base*** image, even though it appears to be unused. +You *may* see the same pattern in *Portainer*, which reports the ***base image*** as "unused". You should not remove the ***base*** image, even though it appears to be unused. + +> Whether you see one or two rows depends on the version of `docker-compose` you are using and how your version of `docker-compose` builds local images. ### Migration considerations @@ -331,7 +333,7 @@ Breaking it down into parts: Your existing Telegraf container continues to run while the rebuild proceeds. Once the freshly-built ***local image*** is ready, the `up` tells `docker-compose` to do a new-for-old swap. There is barely any downtime for your service. -The `prune` is the simplest way of cleaning up. The first call removes the old ***local image***. The second call cleans up the old ***base image***. +The `prune` is the simplest way of cleaning up. The first call removes the old ***local image***. The second call cleans up the old ***base image***. Whether an old ***base image*** exists depends on the version of `docker-compose` you are using and how your version of `docker-compose` builds local images. ### Telegraf version pinning diff --git a/docs/Containers/Zigbee2MQTT.md b/docs/Containers/Zigbee2MQTT.md index 5242920b..5ad81659 100644 --- a/docs/Containers/Zigbee2MQTT.md +++ b/docs/Containers/Zigbee2MQTT.md @@ -259,4 +259,4 @@ $ docker system prune Note: -* Sometimes it is necessary to repeat the `docker system prune` command. +* Sometimes it is necessary to repeat the `docker system prune` command but it depends on the version of `docker-compose` you are using and how your version of `docker-compose` builds local images. From a47dcf5509d18429b37b2141a755a5591aa9c209 Mon Sep 17 00:00:00 2001 From: Phill Kelley <34226495+Paraphraser@users.noreply.github.com> Date: Wed, 9 Feb 2022 14:37:35 +1100 Subject: [PATCH 10/11] 20211116 hassio - master branch - PR 1 of 2 This is a response to [Issue 491](https://github.com/SensorsIot/IOTstack/issues/491). This PR removes the "convenience script" functionality for installing Supervised Home Assistant from the IOTstack menu. The convenience script invokes: ``` curl -sL "https://raw.githubusercontent.com/Kanga-Who/home-assistant/master/supervised-installer.sh" | sudo bash -s ``` but the `supervised-installer.sh` script no longer works properly, so the IOTstack menu and associated documentation do not set user expectations correctly. The `supervised-installer.sh` script has not been updated and, based upon what is written in documentation at [Kanga-Who/home-assistant](https://github.com/Kanga-Who/home-assistant/blob/master/Supervised%20on%20Raspberry%20Pi%20with%20Debian.md), the author appears to have given up on the `supervised-installer.sh` script and is now directing users to the Home Assistant instructions (the same instructions which are implemented in [PiBuilder](https://github.com/Paraphraser/PiBuilder)). From a user perspective, there are four options: 1. Run the standalone `home_assistant` container selectable from the IOTstack menu. 2. Build a Raspberry Pi with [PiBuilder](https://github.com/Paraphraser/PiBuilder) so that Supervised Home Assistant and IOTstack can coexist on the same hardware. 3. Replicate what PiBuilder does to install Supervised Home Assistant alongside IOTstack. 4. Dedicate a Raspberry Pi to the task of running Supervised Home Assistant as an appliance. This appears to be the direction favoured by the folks at Home Assistant. This PR updates the IOTstack Home Assistant documentation to make these options clear, and offers additional guidance on the first two. The last two are out-of-scope for IOTstack. Signed-off-by: Phill Kelley <34226495+Paraphraser@users.noreply.github.com> --- .native/hassio_supervisor.sh | 51 ------- docs/Containers/Home-Assistant.md | 244 ++++++------------------------ scripts/native_installs.py | 16 -- 3 files changed, 48 insertions(+), 263 deletions(-) delete mode 100755 .native/hassio_supervisor.sh diff --git a/.native/hassio_supervisor.sh b/.native/hassio_supervisor.sh deleted file mode 100755 index 692c42be..00000000 --- a/.native/hassio_supervisor.sh +++ /dev/null @@ -1,51 +0,0 @@ -#!/bin/bash - -echo " " -echo "Ensure that you have read the documentation on installing Hass.io before continuing." -echo "Not following the installation instructions may render you system to be unable to connect to the internet." -echo "Hass.io Documentation: " -echo " https://sensorsiot.github.io/IOTstack/Containers/Home-Assistant/" - -echo " " -sleep 1 - -read -r -n 1 -p "Press Y to continue, any other key to cancel " response; - -if [[ $response == "y" || $response == "Y" ]]; then - echo "Install requirements for Hass.io" - sudo apt install -y bash jq curl avahi-daemon dbus - hassio_machine=$(whiptail --title "Machine type" --menu \ - "Please select you device type" 20 78 12 -- \ - "raspberrypi4-64" " " \ - "raspberrypi4" " " \ - "raspberrypi3-64" " " \ - "raspberrypi3" " " \ - "raspberrypi2" " " \ - "qemux86" " " \ - "qemux86-64" " " \ - "qemuarm" " " \ - "qemuarm-64" " " \ - "orangepi-prime" " " \ - "odroid-xu" " " \ - "odroid-c2" " " \ - "intel-nuc" " " \ - "tinker" " " \ - 3>&1 1>&2 2>&3) - - if [ -n "$hassio_machine" ]; then - sudo systemctl disable ModemManager - sudo systemctl stop ModemManager - curl -sL "https://raw.githubusercontent.com/Kanga-Who/home-assistant/master/supervised-installer.sh" | sudo bash -s -- -m $hassio_machine - clear - exit 0 - else - clear - echo "No selection" - exit 4 - fi - clear - exit 3 -else - clear - exit 5 -fi \ No newline at end of file diff --git a/docs/Containers/Home-Assistant.md b/docs/Containers/Home-Assistant.md index 8e886674..2dff4bc2 100644 --- a/docs/Containers/Home-Assistant.md +++ b/docs/Containers/Home-Assistant.md @@ -1,6 +1,6 @@ # Home Assistant -Home Assistant is a home automation platform running on Python 3. It is able to track and control all devices at your home and offer a platform for automating control. +Home Assistant is a home automation platform. It is able to track and control all devices at your home and offer a platform for automating control. ## References @@ -17,189 +17,23 @@ Home Assistant is a home automation platform running on Python 3. It is able to There are two versions of Home Assistant: -* Hass.io (Home Assistant Core), and -* Home Assistant Container. +* Home Assistant Container; and +* Supervised Home Assistant (also known as both "Hass.io" and "Home Assistant Core"). Each version: * provides a web-based management interface on port 8123; and * runs in "host mode" in order to discover devices on your LAN, including devices communicating via multicast traffic. -IOTstack allows you to **install** either, or both, versions. +Home Assistant Container runs as a **single** Docker container, and doesn't support all the features that Supervised Home Assistant does (such as add-ons). Supervised Home Assistant runs as a **collection** of Docker containers under its own orchestration. -Note: +Technically, both versions of Home Assistant can be installed on your Raspberry Pi but you can't **run** both at the same time. Each version runs in "host mode" and binds to port 8123 so, in practice, the first version to start will claim the port and the second will then be blocked. -* Technically, both versions can **run** at the same time but it is not **supported**. Each version runs in "host mode" and binds to port 8123 so, in practice, the first version to start will claim the port and the second version will then be blocked. - -### Hass.io - -Hass.io uses its own orchestration: - -* hassio\_supervisor -* hassio\_audio -* hassio\_cli -* hassio\_dns -* hassio\_multicast -* hassio\_observer -* homeassistant. - -IOTstack can only offer limited configuration of Hass.io since it is its own platform. - -### Home Assistant Container - -Home Assistant Container runs as a single Docker container, and doesn't support all the features that Hass.io does (such as add-ons). - -## Menu installation - -### Installing Hass.io - -Hass.io creates a conundrum: - -* If you are definitely going to install Hass.io then you **must** install its dependencies **before** you install Docker. -* One of Hass.io's dependencies is [Network Manager](https://wiki.archlinux.org/index.php/NetworkManager). Network Manager makes **serious** changes to your operating system, with side-effects you may not expect such as giving your Raspberry Pi's WiFi interface a random MAC address both during the installation and, then, each time you reboot. You are in for a world of pain if you install Network Manager without first understanding what is going to happen and planning accordingly. -* If you don't install Hass.io's dependencies before you install Docker, you will either have to uninstall Docker or rebuild your system. This is because both Docker and Network Manager adjust your Raspberry Pi's networking. Docker is happy to install after Network Manager, but the reverse is not true. - -#### Step 1: If Docker is already installed, uninstall it - -```bash -$ sudo apt -y purge docker-ce docker-ce-cli containerd.io -$ sudo apt -y remove docker-compose -$ sudo pip3 uninstall docker-compose -``` - -Note: - -* Removing Docker does **not** interfere with your existing `~/IOTstack` folder. - -#### Step 2: Ensure your system is fully up-to-date - -```bash -$ sudo apt update -$ sudo apt upgrade -y -``` - -#### Step 3: Install Hass.io dependencies (stage 1) - -```bash -$ sudo apt install -y apparmor apparmor-profiles apparmor-utils -$ sudo apt install -y software-properties-common apt-transport-https ca-certificates dbus -``` - -#### Step 4: Connect to your Raspberry Pi via Ethernet - -You can skip this step if you interact with your Raspberry Pi via a screen connected to its HDMI port, along with a keyboard and mouse. - -If, however, you are running "headless" (SSH or VNC), we **strongly recommend** connecting your Raspberry Pi to Ethernet. This is only a temporary requirement. You can return to WiFi-only operation after Hass.io is installed. - -When the Ethernet interface initialises, work out its IP address: - -```bash -$ ifconfig eth0 - -eth0: flags=4163 mtu 1500 - inet 192.168.132.9 netmask 255.255.255.0 broadcast 192.168.132.255 - ether ab:cd:ef:12:34:56 txqueuelen 1000 (Ethernet) - RX packets 4166292 bytes 3545370373 (3.3 GiB) - RX errors 0 dropped 0 overruns 0 frame 0 - TX packets 2086814 bytes 2024386593 (1.8 GiB) - TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 -``` - -In the above, the IP address assigned to the Ethernet interface is on the second line of output, to the right of "inet": 192.168.132.9. - -Drop out of your existing session (SSH or VNC) and re-connect to your Raspberry Pi using the IP address assigned to its Ethernet interface: - -```bash -$ ssh pi@192.168.132.9 -``` - -or: - -``` -vnc://pi@192.168.132.9 -``` - -The reason for stipulating the IP address, rather than a name like `raspberrypi.local` is so that you are *definitely* connected to the Ethernet interface. - -If you ignore the advice about connecting via Ethernet and install Network Manager while your session is connected via WiFi, your connection will freeze part way through the installation (when Network Manager starts running and unconditionally changes your Raspberry Pi's WiFi MAC address). - -You *may* be able to re-connect after the WiFi interface acquires a new IP address and advertises that via multicast DNS associated with the name of your device (eg `raspberrypi.local`), but you may also find that the only way to regain control is to power-cycle your Raspberry Pi. - -The advice about using Ethernet is well-intentioned. You should heed this advice even if means you need to temporarily relocate your Raspberry Pi just so you can attach it via Ethernet for the next few steps. You can go back to WiFi later, once everything is set up. You have been warned! - -#### Step 5: Install Hass.io dependencies (stage 2) - -Install Network Manager: - -```bash -$ sudo apt install -y network-manager -``` - -#### Step 6: Consider disabling random MAC address allocation - -To understand why you should consider disabling random MAC address allocation, see [why random MACs are such a hassle ](#aboutRandomMACs). - -You can stop Network Manager from allocating random MAC addresses to your WiFi interface by running the following commands: - -```bash -$ sudo sed -i.bak '$a\\n[device]\nwifi.scan-rand-mac-address=no\n' /etc/NetworkManager/NetworkManager.conf -$ sudo systemctl restart NetworkManager.service -``` - -Acknowledgement: - -* This tip came from [@steveatk on Discord](https://discordapp.com/channels/638610460567928832/638610461109256194/758825690715652116). - -#### Step 7: Re-install Docker - -You can re-install Docker using the IOTstack menu or one of the scripts provided with IOTstack but the following commands guarantee an up-to-date version of `docker-compose` and also include a dependency needed if you want to run with the 64-bit kernel: - -```bash -$ curl -fsSL https://get.docker.com | sh -$ sudo usermod -G docker -a $USER -$ sudo usermod -G bluetooth -a $USER -$ sudo apt install -y python3-pip python3-dev -$ [ "$(uname -m)" = "aarch64" ] && sudo apt install libffi-dev -$ sudo pip3 install -U docker-compose -$ sudo pip3 install -U ruamel.yaml==0.16.12 blessed -$ sudo reboot -``` - -Note: - -* Installing or re-installing Docker does **not** interfere with your existing `~/IOTstack` folder. - -#### Step 8: Run the Hass.io installation - -Start at: - -```bash -$ cd ~/IOTstack -$ ./menu.sh -``` - -Hass.io installation can be found inside the `Native Installs` menu on the main menu. You will be asked to select your device type during the installation. - -The installation of Hass.io takes up to 20 minutes (depending on your internet connection). You may also need to respond "Y" to a prompt during the installation process. Refrain from restarting your machine until it has come online and you are able to create a user account. - -Hass.io installation is provided as a convenience. It is independent of, is not maintained by, and does not appear in the `docker-compose.yml` for IOTstack. Hass.io has its own service for maintaining its uptime. - -#### Re-check random MAC address allocation - -Installing Hass.io can re-enable random MAC address allocation. You should check this via: - -```bash -$ tail -3 /etc/NetworkManager/NetworkManager.conf -[device] -wifi.scan-rand-mac-address=no - -``` - -If you do **NOT** see `wifi.scan-rand-mac-address=no`, repeat [Step 6](#disableRandomMac1). +IOTstack used to offer a menu entry leading to a convenience script that could install Supervised Home Assistant but that stopped working when Home Assistant changed their approach. Now, the only method supported by IOTstack is Home Assistant Container. ### Installing Home Assistant Container -Home Assistant can be found in the `Build Stack` menu. Selecting it in this menu results in a service definition being added to: +Home Assistant (Container) can be found in the `Build Stack` menu. Selecting it in this menu results in a service definition being added to: ``` ~/IOTstack/docker-compose.yml @@ -222,40 +56,58 @@ $ cd ~/IOTstack $ docker-compose up -d ``` -## Deactivating Hass.io +### Installing Supervised Home Assistant -Because Hass.io is independent of IOTstack, you can't deactivate it with any of the commands you normally use for IOTstack. +The direction being taken by the Home Assistant folks is to supply a ready-to-run image for your Raspberry Pi. That effectively dedicates your Raspberry Pi to Home Assistant and precludes the possibility of running alongside IOTstack and containers like Mosquitto, InfluxDB, Node-RED, Grafana, PiHole and WireGuard. -To deactivate Hass.io you first need to stop the service that controls it. Run the following commands in the terminal: +It is possible to run Supervised Home Assistant on the same Raspberry Pi as IOTstack. The recommended approach is to start from a clean slate and use [PiBuilder](https://github.com/Paraphraser/PiBuilder). -```bash -$ sudo systemctl stop hassio-supervisor.service -$ sudo systemctl disable hassio-supervisor.service -``` +When you visit the PiBuilder link you may well have a reaction like "all far too complicated" but you should try to get past that. PiBuilder has two main use-cases: -This will stop the main service and prevent it from starting on the next boot. Next you need to stop and remove the dependent services: +1. Getting a Raspberry Pi built for IOTstack (and, optionally, Supervised Home Assistant) with the least fuss. +2. Letting you record all your own customisations so that you can rebuild your Pis quickly with all your customisations already in place (the "magic smoke" scenario). -```bash -$ docker stop hassio_audio hassio_cli hassio_dns hassio_multicast hassio_observer homeassistant -$ docker rm hassio_audio hassio_cli hassio_dns hassio_multicast hassio_observer homeassistant -``` +It's the second use-case that produces most of the apparent complexity you see when you read the [PiBuilder README](https://github.com/Paraphraser/PiBuilder/blob/master/README.md) for the first time. + +The first time you use PiBuilder, the process boils down to: + +1. Clone the PiBuilder repo onto your support host (Mac, Windows, etc). +2. Customise two files within the PiBuilder scope: + + - `wpa_supplicant.conf` + - `options.sh` where, among other things, you will enable: + + - `HOME_ASSISTANT_SUPERVISED_INSTALL=true` + +3. Choose a Raspbian image and transfer it to your installation media (SD/SSD). The imaging tools typically finish by ejecting the installation media. +4. Re-mount the installation media on your support host and either: -Double-check with `docker ps` to see if there are other containers running with a `hassio_` prefix. They can stopped and removed in the same fashion for `hassio_audio` and so-on. + - Run the supplied `setup_boot_volume.sh` script (if your support host is macOS or Unix); or + - Just drag the *contents* of the PiBuilder "boot" folder into the top level of the "/boot" partition on your installation media (if your support host is Windows). -The stored files are located in `/usr/share/hassio` which can be removed if you need to. +5. Move the installation media to your Raspberry Pi and apply power. +6. Run the scripts in order: -You can use Portainer to view what is running and clean up the unused images. + Step | Command run on support host | Command run on Raspberry Pi + :---:|-----------------------------------|------------- + 1 | `ssh -4 pi@raspberrypi.local` | + 2 | | `/boot/scripts/01_setup.sh «name»` + 3 | `ssh-keygen -R raspberrypi.local` | + 4 | `ssh -4 pi@«name».local` | + 5 | | `/boot/scripts/02_setup.sh` + 6 | `ssh pi@«name».local` | + 7 | | `/boot/scripts/03_setup.sh` + 8 | `ssh pi@«name».local` | + 9 | | `/boot/scripts/04_setup.sh` + 10 | `ssh pi@«name».local` | + 11 | | `/boot/scripts/05_setup.sh` -At this point, Hass.io is stopped and will not start again after a reboot. Your options are: + where «name» is the name you give to your Raspberry Pi (eg "iot-hub"). -* Leave things as they are; or -* Re-install Hass.io by starting over at [Installing Hass.io](#installHassio); or -* Re-activate Hass.io by: +After step 9, Supervised Home Assistant will be running. The `04_setup.sh` script also deals with the [random MACs](#aboutRandomMACs) problem. After step 11, you'll be able to either: - ```bash - $ sudo systemctl enable hassio-supervisor.service - $ sudo systemctl start hassio-supervisor.service - ``` +1. Restore a backup; or +2. Run the IOTstack menu and choose your containers. ## Why random MACs are such a hassle diff --git a/scripts/native_installs.py b/scripts/native_installs.py index 7e9e4280..a55ce9bf 100755 --- a/scripts/native_installs.py +++ b/scripts/native_installs.py @@ -30,21 +30,6 @@ def onResize(sig, action): if (screenActive): mainRender(1, mainMenuList, currentMenuItemIndex) - def installHassIo(): - print(term.clear()) - print("Install Home Assistant Supervisor") - print("./.native/hassio_supervisor.sh") - res = subprocess.call("./.native/hassio_supervisor.sh", shell=True) - print("") - if res == 0: - print("Preinstallation complete. Your system may run slow for a few hours as Hass.io installs its services.") - print("Press [Up] or [Down] arrow key to show the menu if it has scrolled too far.") - else: - print("Preinstallation not completed.") - input("Process terminated. Press [Enter] to show menu and continue.") - time.sleep(0.5) - return True - def installRtl433(): print(term.clear()) print("Install RTL_433") @@ -93,7 +78,6 @@ def goBack(): return True mainMenuList = [ - ["Hass.io (Supervisor)", installHassIo], ["RTL_433", installRtl433], ["RPIEasy", installRpiEasy], ["Upgrade Docker and Docker-Compose", upgradeDockerAndCompose], From e0bfa127bf551c970477d5754ca845595146e9c1 Mon Sep 17 00:00:00 2001 From: ukkopahis <95980324+ukkopahis@users.noreply.github.com> Date: Tue, 15 Feb 2022 11:08:06 +0200 Subject: [PATCH 11/11] Fix docker version parsing Debian apt installs docker version with a postfix. E.g. "20.10.5+dfsg1" Ignore this when checking for version. Fixes #496 Fixes #447 --- install.sh | 2 ++ menu.sh | 1 + scripts/deps/version_check.py | 12 +++++++++++- 3 files changed, 14 insertions(+), 1 deletion(-) diff --git a/install.sh b/install.sh index 77d39102..21f6d438 100755 --- a/install.sh +++ b/install.sh @@ -219,6 +219,8 @@ function do_docker_checks() { DOCKER_VERSION_MAJOR=$(echo "$DOCKER_VERSION"| cut -d'.' -f 1) DOCKER_VERSION_MINOR=$(echo "$DOCKER_VERSION"| cut -d'.' -f 2) DOCKER_VERSION_BUILD=$(echo "$DOCKER_VERSION"| cut -d'.' -f 3) + DOCKER_VERSION_BUILD=$(echo "$DOCKER_VERSION_BUILD"| cut -f1 -d"-") + DOCKER_VERSION_BUILD=$(echo "$DOCKER_VERSION_BUILD"| cut -f1 -d"+") if [ "$(minimum_version_check $REQ_DOCKER_VERSION $DOCKER_VERSION_MAJOR $DOCKER_VERSION_MINOR $DOCKER_VERSION_BUILD )" == "true" ]; then [ -f .docker_outofdate ] && rm .docker_outofdate diff --git a/menu.sh b/menu.sh index d0f362de..55e19ae6 100755 --- a/menu.sh +++ b/menu.sh @@ -279,6 +279,7 @@ function do_docker_checks() { DOCKER_VERSION_BUILD=$(echo "$DOCKER_VERSION"| cut -d'.' -f 3) DOCKER_VERSION_BUILD=$(echo "$DOCKER_VERSION_BUILD"| cut -f1 -d"-") + DOCKER_VERSION_BUILD=$(echo "$DOCKER_VERSION_BUILD"| cut -f1 -d"+") if [ "$(minimum_version_check $REQ_DOCKER_VERSION $DOCKER_VERSION_MAJOR $DOCKER_VERSION_MINOR $DOCKER_VERSION_BUILD )" == "true" ]; then [ -f .docker_outofdate ] && rm .docker_outofdate diff --git a/scripts/deps/version_check.py b/scripts/deps/version_check.py index aa3a272e..d60740b7 100755 --- a/scripts/deps/version_check.py +++ b/scripts/deps/version_check.py @@ -1,4 +1,14 @@ +import re + def checkVersion(requiredVersion, currentVersion): + """ + >>> checkVersion('18.2.0', '20.10.11') + (True, '', []) + >>> checkVersion('18.2.0', '16.3.1') + (False, 'Version Check Fail', [False, False, True]) + >>> checkVersion('18.2.0', '20.10.5+dfsg1') + (True, '', []) + """ requiredSplit = requiredVersion.split('.') if len(requiredSplit) < 2: @@ -19,7 +29,7 @@ def checkVersion(requiredVersion, currentVersion): try: currentMajor = int(currentSplit[0]) currentMinor = int(currentSplit[1]) - currentBuild = currentSplit[2].split("-")[0] + currentBuild = re.split(r'[+-]', currentSplit[2])[0] currentBuild = int(currentBuild) except: return False, 'Invalid Current Version', currentVersion