-
Notifications
You must be signed in to change notification settings - Fork 584
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
ghost
wants to merge
988
commits into
gcgarner:master
Choose a base branch
from
SensorsIot:master
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Hey @To1952P just so you know, the project has been moved to: https://github.com/SensorsIot/IOTstack this repo is abandoned. |
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.
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]>
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
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]>
2024-10-26 docs - master branch
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]>
2024-12-09 Zigbee2MQTT doc - master branch
2024-12-09 install.sh - master branch
Added python-matter-server, thread and matterbridge
Update service.yml
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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