Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Install problems Hassio with IOTstack #211

Open
wants to merge 988 commits into
base: master
Choose a base branch
from

Conversation

ghost
Copy link

@ghost ghost commented Oct 22, 2020

For all those whoes trying to install hassio and get the message "Missing apparmor and network manager". Enter after installing raspbian the following:

sudo apt-get install aaparmor
sudo apt-get install network-manager

@Slyke
Copy link
Collaborator

Slyke commented Oct 22, 2020

Hey @To1952P just so you know, the project has been moved to: https://github.com/SensorsIot/IOTstack this repo is abandoned.

ukkopahis and others added 29 commits June 17, 2022 18:05
Also:
* fix aliases to work regardless of user's current directory (using the
  '-f' flag instead of changing the directory would ignore a possibly
  existing `docker-compose.override.yml')
* fix iotstack_build alias to include "--pull --no-cache", as without
  these there may be cases where everything isn't fully updated.
* add the iotstack_update_docker_images alias to perform the basic
  container update.
Fixes #433

Also improves on exception reporting to include full stacktrace
Also add Changlog link to the Wiki homepage.
Use yaml structure from docker-compose-base.yml instead of creating it
in python.
Add compose variables and indentation as defined by #505

Fixes #383, Fixes #517
Implements and resolves #232

Also changes user to reflect the strong recommendation of #287

As %randomPassword% doesn't seem to work, change to use the default
password as listed on Default-Configs.md and add support for #505
style variables.

Change default public port from 5433 to avoid port-conflict with posgresql.
* manage python requirements using requirements-menu.txt
  installing the exact versions of all dependencies.
* is completely separate from any system-wide installed python packages,
  won't conflict with existing installed python packages.
* minimizes global system requirements down to python and python-virtualenv

virtualenv requires "--seed pip" or it fails with:
    ModuleNotFoundError: No module named 'pip._internal.utils'
Fixes some typos and updates some out-of-date information.

Signed-off-by: Phill Kelley <[email protected]>
Works towards making the "Getting started" not so very long.

Resolves #58
Move "the nuclear option" from Getting Started.
Resolves #180 adding github gists link
Adopts build-argument syntax in the template service definition +
template Dockerfile to pass an image tag plus an optional list of
extra packages to the Dockerfile at build time.

Pinning to a specific base image can now be accomplished in the Compose
file. This places Node-RED on equal footing with containers that do not
use local Dockerfiles (and Mosquitto which already has similar
build-argument syntax).

Together, the changes mean user customisations to the first part of the
Dockerfile are no longer at risk of being overwritten by menu runs to
change the list of add-on nodes.

For any given IOTstack installation, there is some possibility of a
hybrid result, depending on how and when the user runs the menu, or
which techniques each user employs to manage their Compose file and
Node-RED Dockerfile. The intention is to either fail safe or at least
fail sensibly:

* old Compose + old Dockerfile = no change.
* old Compose + new Dockerfile will adopt `latest` so `node.js` *may*
change from 12.x to 14.x on the next `--build` but this will depend on
whether the user ever explicitly set `latest-14` in their old Dockerfile.
* new Compose + old Dockerfile = no change. The service definition build
arguments will be ignored and the user may be confused until consulting
the documentation, but the container will still build as before.
* new Compose + new Dockerfile will behave as per the revised
documentation. Absent any user changes to the service definition, the
resulting container will be based on `latest` (which implies `node.js`
14.x) and there will no packages other than `eudev-dev` (the existing
Dockerfile default).

Worst case is an existing user adopting all-new syntax without realising
the old Dockerfile specified `latest-12`, thereby advancing to `node.js`
14.x unexpectedly, perhaps also losing additional packages along the
way. The fix is to specify `DOCKERHUB_TAG=latest-12`, append any lost
packages to `EXTRA_PACKAGES=`, and rebuild.

Personally, I switched to `-14` a good six months ago. It worked
out-of-the-box with zero migration issues and I've never looked back.
While that's only n=1, I don't feel there's sufficient risk to warrant
IOTstack continuing to default to `-12`. We have to change sometime, or
we'll be back where we were when images based on `-10` were no longer
being offered as Node-RED marched forward.

Using `node.js` version 14 is the implicit recommendation (ie `latest`
and `latest-14` are currently synonyms). Version 16 is available but is
known to throw up some migration issues. IOTstack started defaulting to
version 12 in March 2021 (when version 10 was deprecated).

Signed-off-by: Phill Kelley <[email protected]>
Fixes `nodered_list_installed_nodes.sh`. Now relies on `npm` running
inside the container to discover what's installed where.

Documentation describing use of `/data` on `npm` calls turns out to be
ineffective. The solution is to set the working directory on the
`docker exec` call.

Following on from a discussion on Discord
[starting here](https://discord.com/channels/638610460567928832/638610461109256194/994818372439113838),
it was obviously confusing for the documentation to be discussing
"nodes" when `npm` can be used to install a variety of components.
Documentation adjusted to clarify this.

Signed-off-by: Phill Kelley <[email protected]>
The revised `nodered_list_installed_nodes.sh` revealed that the older
"move and delete" method for resolving conflicts actually leaves behind
a mess. Replaced with a `docker exec` call.

Signed-off-by: Phill Kelley <[email protected]>
A Discord thread starting at
https://discord.com/channels/638610460567928832/638610461109256194/1005812386688680006
revealed that the Domoticz would not function properly on a clean
install. The symptom was either a 400 or a 404 error, depending on the
URL.

Three issues identified with existing service definition:

1. Wrong image base. Should be "lscr.io/linuxserver/domoticz".
2. Wrong image tag. Should be "latest".
3. `network_mode: bridge`.

It has never been clear what `network_mode: bridge` is intended to do.
It is the only container with this option. While it may once have been
needed, its presence now appears to prevent the container from
responding correctly on port 8083.

No IOTstack documentation exists for this container. This PR adds some
basic documentation in the form of references to the Domoticz home plus
associated GitHub and DockerHub pages, along with an invitation for
someone who is familiar with the container to expand it further.

Signed-off-by: Phill Kelley <[email protected]>
Adds first cut of ZeroTier in the form of two containers:

* ZeroTier-client from `zyclonite:zerotier`
* ZeroTier-router from `zyclonite:zerotier-router`

The two containers are mutually exclusive (no menu check - docker-compose
will complain about port conflicts). My guess is that IOTstack users will
generally prefer the router because it is closer to WireGuard
functionality, and is likely what an IOTstack user will be looking for
if they find themselves stuck behind CGNAT.

ZeroTier-client is the standard client. Has no environment variables or
other preconfiguration. Needs to be instructed to join the user's
ZeroTier network after first launch. Otherwise works "as is".

ZeroTier-router is built on top of ZeroTier-client and adds management
of iptables rules at startup/shutdown to support routing to/from the
local network. Has environment variables with defaults appropriate for
IOTstack.

Adds documentation:

* ZeroTier.md
* ZeroTier-vs-WireGuard.md to explain the pros/cons of each.

Modifies WireGuard documentation to reference ZeroTier-vs-WireGuard.md
and also adds a tweak to one diagram (takes the opportunity to switch
from PNG to JPEG ; PNGs do not always "play nice" when Wiki pages are
viewed in Dark Mode).

Signed-off-by: Phill Kelley <[email protected]>
1. `npm list --depth=0 --parseable` was displaying an alert that the
user really can do nothing about:

	```
	npm ERR! extraneous: [email protected] /usr/src/node-red/node_modules/node-red-node-email/node_modules/libmime
	```

	Suppress by redirecting stderr to null.

2. Construct command needed to remove blocking nodes and output it as
 a hint at the end of the run.

Signed-off-by: Phill Kelley <[email protected]>
Signed-off-by: Phill Kelley <[email protected]>
Expand InfluxDB 1.8 documentation by incorporating material from:

* [Tutorial: Enabling authentication in InfluxDB](https://gist.github.com/Paraphraser/9f3aa21fddd5d4e8141a7ab03ffb4dd7)
* [Tutorial: Enabling UDP support in InfluxDB](https://gist.github.com/Paraphraser/15483641fc657a147dfae7b03d291bc0)

I thought I had already added this material but a Discord question made
me realise I was mistaken.

General tidy-up because a lot of the example material was either wrong
or out-of-date.

Signed-off-by: Phill Kelley <[email protected]>
20220901 InfluxDB - master branch - documentation
20220811 ZeroTier - master branch - PR 1 of 2
20220810 domoticz - master branch - PR 1 of 3
Slyke and others added 30 commits April 30, 2024 03:07
2024-03-28 Adds WordPress - master branch - PR 1 of 2
Clarifies:

1. That enabling managed default route propagation on iOS persists until
explicitly turned off.
2. That the subnets recommended for IOTstack's internal networks are
private to the host and can safely be re-used across multiple IOTstack
instances.

Signed-off-by: Phill Kelley <[email protected]>
1. Adds explanation of how to migrate to Debian-based Node-RED container
  (this follows on from a Discord question).
2. More consistent usage of reference markers defined in section on how
   the container gets built.
3. Rewrites section on base/local images to reflect current behaviour of
  `docker-compose`, and also adds pointers to build/rebuild commands.
4. Adds `-f` to `prune` commands.
5. Removes extraneous ASCII tabs that had crept in.

Signed-off-by: Phill Kelley <[email protected]>
Adds ESPHome container, as requested by #754.

Includes documentation.

Fixes: #754

Signed-off-by: Phill Kelley <[email protected]>
Harmonises list of add-on nodes across old-menu and master branches.
I've tried to stay away from #755. This includes removal of
`node-red-node-rbe` which has been replaced by the built-in Filter
node.  See:

- [Release notes](https://nodered.org/blog/2021/07/20/version-2-0-released#renamed-rbe-node-to-filter-node)

Migrate from `node-red-contrib-themes/midnight-red` (deprecated) to
`@node-red-contrib-themes/theme-collection` which supports many more
themes. See:

- [Node-RED themes list](https://github.com/node-red-contrib-themes/theme-collection#theme-list)

Modify Dockerfile template:

1. No need to declare `EXTRA_PACKAGES` as an environment variable. It
   isn't needed in the container. The `ARG` reference is sufficient.

2. Remove redundant `apk update` command. The `--no-cache` flag on the
   `apk add` handles both package-list updates and their removal. It
   makes for a slightly smaller container.

   I discovered (and tested) this behaviour when posting a reply to:

   - [node-red-docker issue 338](node-red/node-red-docker#338).

Signed-off-by: Phill Kelley <[email protected]>
1. Adopts recommended she-bang syntax.

2. Adds version number to banner (mainly as a visual aid when discussing
   installation issues on Discord).

3. Removes internal SCRIPT variable which has a dependency on whether
   the script is invoked directly or piped to bash.

4. No need to resolve absolute path for `IOTSTACK` variable. This just
   causes an error in green-fields situations.

5. Better messaging in `handle_exit()` so it is clear whether the script
   completed normally with no further work to do, or should be re-run.

6. Better handling of "logout required" situation. Rather than killing
   the immediate parent process (`$PPID`), now iterates the process
   ancestry to find the most-distant ancestor owned by the current user.
   For SSH connections this is typically the `sshd` spawned for the
   user. For console connections, it's typically the shell launched by
   the login process. This deals with the problem where a script (eg the
   menu) calling the installer script would be the immediate parent
   process, and it would be killed without necessarily causing the
   required logout to enable group membership changes to take effect.

7. Removes `is_running_OS_release()` function which was only being used
   to infer modern Python behaviour from "bookworm" (ie a hack) and
   which failed on Ubuntu.

8. Uses and documents use of `PIP_BREAK_SYSTEM_PACKAGES` variable which
   triggers the desired modern Python behaviour on systems which support
   it, being ignored otherwise.

Signed-off-by: Phill Kelley <[email protected]>
Added the new dashboard for NodeRed. Defaulted to off
2024-08-08 installer script - master branch
2024-07-30 Node-RED - master branch - PR 1 of 2
2024-07-21 Adds ESPHome - master branch - PR 1 of 2
2024-07-13 Node-RED documentation - master branch
2024-05-17 ZeroTier documentation - master branch
Fixes warnings produced by `mkdocs` about broken links.

Signed-off-by: Phill Kelley <[email protected]>
This PR follows on from discussion in #651 at
[@6ffm70](#651 (comment))
post and later.

Previously, the `backups` and `services` folders were only created if
the `~/IOTstack` folder had just been cloned.

As well as "installing", the install script should also function as a
"repair" script so it is preferable to always create the `backups` and
`services` directories and ensure that they, and their contents,
have correct ownership.

Signed-off-by: Phill Kelley <[email protected]>
I keep fielding questions on Discord which suggest IOTstack's
Zigbee2MQTT documentation doesn't place sufficient emphasis on using
environment variables to pass configuration settings to the container.

Also, the advent of adapters which are reachable via TCP isn't
mentioned so I have included an example.

Opportunistic cleanup of spurious 0x090A sequences.

Signed-off-by: Phill Kelley <[email protected]>
To enable the upgrade to 2.0. All these variables are duplicates of what is set directly in the MZ2M configuration.yaml file
Signed-off-by: Phill Kelley <[email protected]>
Added python-matter-server, thread and matterbridge
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.