If your remote clients have trouble connecting, try running:
$ docker logs wireguard
If you see the following messages being repeated endlessly:
s6-supervise custom-svc-README.txt (child): fatal: unable to exec run: Exec format error
s6-supervise custom-svc-README.txt: warning: unable to spawn ./run - waiting 10 seconds
then help is at hand. This problem appears to be an unintended side-effect of WireGuard's maintainers deciding to adopt a different directory structure inside the container.
IOTstack Pull Request #607 adopts the new directory structure but that will only help IOTstack users who implement WireGuard for the first time after that Pull Request has been applied.
If you use WireGuard and your remote clients can still connect then you need do nothing until Pull Request #607 is applied. The PR provides a script to assist with the migration, and also adds a section to the IOTstack Wiki explaining how to use it. Even then, the timing will be up to you.
However, if you are having problems now, you can proceed like this:
Download the migration script:
$ cd ~/IOTstack
$ curl https://raw.githubusercontent.com/SensorsIot/IOTstack/24b6917e0b0809b3f551b2c46dc372eef01cba62/scripts/2022-10-01-wireguard-restructure.sh >2022-10-01-wireguard-restructure.sh
Stop WireGuard:
$ docker-compose rm --force --stop -v wireguard
Run the migration script:
$ ./2022-10-01-wireguard-restructure.sh
If successful, the script explains how to edit your docker-compose.yml to update WireGuard's service definition.
The usual "double-check before hitting return when using sudo" applies!!
Be aware that, until Pull Request #607 is applied, the IOTstack menu and/or override processes may revert your WireGuard service definition to its pre-migration form. If that happens, you will have a mess to sort out. As a precaution, it would be a good idea to make sure you have a backup of a known-good post-migration configuration. At the very least you should snapshot:
If your remote clients have trouble connecting, try running:
If you see the following messages being repeated endlessly:
then help is at hand. This problem appears to be an unintended side-effect of WireGuard's maintainers deciding to adopt a different directory structure inside the container.
IOTstack Pull Request #607 adopts the new directory structure but that will only help IOTstack users who implement WireGuard for the first time after that Pull Request has been applied.
If you use WireGuard and your remote clients can still connect then you need do nothing until Pull Request #607 is applied. The PR provides a script to assist with the migration, and also adds a section to the IOTstack Wiki explaining how to use it. Even then, the timing will be up to you.
However, if you are having problems now, you can proceed like this:
Download the migration script:
Stop WireGuard:
Run the migration script:
If successful, the script explains how to edit your
docker-compose.ymlto update WireGuard's service definition.Start WireGuard:
Test that your remote clients can connect.
Clean up:
Be aware that, until Pull Request #607 is applied, the IOTstack menu and/or override processes may revert your WireGuard service definition to its pre-migration form. If that happens, you will have a mess to sort out. As a precaution, it would be a good idea to make sure you have a backup of a known-good post-migration configuration. At the very least you should snapshot: