You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, thanks for this really nice project. I'm so happy to have my OpenWrt devices under version control and be able to share configuration between them (thanks to the module system).
My OpenWrt devices are dumb APs which use DHCP, but when they're freshly installed / factory reset, they come up with IPv4 address 192.168.1.1 (standard OpenWrt). If I deploy to them in this state, the (dewclaw) deploy script will fail and start the rollback mechanism, because the devices become "inaccessible" after changing from 192.168.1.1 to a DHCP assigned address (in a different subnet even).
To work around this, I must either manually configure the address in the web UI before running dewclaw, or:
Start the deploy script (nix-build -A dewclaw-env && ./result/bin/deploy-NAME).
Run until ssh -o StrictHostKeyChecking=no root@$NEW_ADDRESS /etc/init.d/config_generation commit; do sleep 10; done && echo "Success!" in a separate terminal.
I was thinking of ways to improve upon this.
Add an --unchecked option to dewclaw, in similar spirit as the LuCI web UI has an "Apply unchecked` option. This would not trigger the rollback mechanism, even if the target becomes inaccessible during the deploy.
Add an option for multiple target IPv4 addresses / hostnames in the config and try them all. (Perhaps too silly.)
Add an --alt-host-addr= option and try them all at runtime.
Add an --after-deploy-addr= option and use that for trying to commit the new configuration.
Thoughts?
The text was updated successfully, but these errors were encountered:
First, thanks for this really nice project. I'm so happy to have my OpenWrt devices under version control and be able to share configuration between them (thanks to the module system).
My OpenWrt devices are dumb APs which use DHCP, but when they're freshly installed / factory reset, they come up with IPv4 address 192.168.1.1 (standard OpenWrt). If I deploy to them in this state, the (dewclaw) deploy script will fail and start the rollback mechanism, because the devices become "inaccessible" after changing from 192.168.1.1 to a DHCP assigned address (in a different subnet even).
To work around this, I must either manually configure the address in the web UI before running dewclaw, or:
nix-build -A dewclaw-env && ./result/bin/deploy-NAME
).until ssh -o StrictHostKeyChecking=no root@$NEW_ADDRESS /etc/init.d/config_generation commit; do sleep 10; done && echo "Success!"
in a separate terminal.I was thinking of ways to improve upon this.
--unchecked
option to dewclaw, in similar spirit as the LuCI web UI has an "Apply unchecked` option. This would not trigger the rollback mechanism, even if the target becomes inaccessible during the deploy.--alt-host-addr=
option and try them all at runtime.--after-deploy-addr=
option and use that for trying to commit the new configuration.Thoughts?
The text was updated successfully, but these errors were encountered: