Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenWISP: Multi-device fleet management for OpenWrt routers

openwisp.org

Post reply on HN
Print view View original

1–10 of 17 posts

Re: OpenWISP: Multi-device fleet management for OpenWrt routers

#4

Post by chatmasta »

chme wrote: post #3
fh67 wrote: post #2

Anything similar for opnsense (besides their own service) or pfsense?

Maybe just go with ansible or similar: https://github.com/ansibleguy/collection_opnsense

Updating a fleet of embedded devices like routers (which can come online and go offline at any time) will generally be much easier using a pull-based update model. But if you’ve got control over the build and update lifecycle, a push-based approach like ansible might be appropriate.

Re: OpenWISP: Multi-device fleet management for OpenWrt routers

#5

Post by chme »

chatmasta wrote: post #4
chme wrote: post #3

Earlier quoted context omitted.

Maybe just go with ansible or similar: https://github.com/ansibleguy/collection_opnsense

Updating a fleet of embedded devices like routers (which can come online and go offline at any time) will generally be much easier using a pull-based update model. But if you’ve got control over the build and update lifecycle, a push-based approach like ansible might be appropriate.

Maybe I am missing somehing, but I would assume that base network infrastructure like routers, firewalls and switches have a higher uptime, availability and reliability than ordinary servers.

Re: OpenWISP: Multi-device fleet management for OpenWrt routers

#6

Post by dsr_ »

chme wrote: post #5
chatmasta wrote: post #4

Earlier quoted context omitted.

Updating a fleet of embedded devices like routers (which can come online and go offline at any time) will generally be much easier using a pull-based update model. But if you’ve got control over the build and update lifecycle, a push-based approach like ansible might be appropriate.

Maybe I am missing somehing, but I would assume that base network infrastructure like routers, firewalls and switches have a higher uptime, availability and reliability than ordinary servers.

The problem with push is that the service sitting at the center needs to figure out which devices will need to be re-pushed later on. You can end up with a lot of state that needs action just to get things back to normal.

So if you can convince devices to pull at boot time and then regularly thereafter, you know that the three states they can be in are down, good, or soon to be good. Now you only need to take action when things are down.

Never analyze distribution of software and config based on the perfect state; minimize the amount of work you need to do for the exceptions.

Re: OpenWISP: Multi-device fleet management for OpenWrt routers

#7

Post by westurner »

chatmasta wrote: post #4
chme wrote: post #3

Earlier quoted context omitted.

Maybe just go with ansible or similar: https://github.com/ansibleguy/collection_opnsense

Updating a fleet of embedded devices like routers (which can come online and go offline at any time) will generally be much easier using a pull-based update model. But if you’ve got control over the build and update lifecycle, a push-based approach like ansible might be appropriate.

Pull based updates would work on OpenWRT devices if they had enough storage, transactional updates and/or multiple flash slots, and scheduled maintenance windows.

OpenWRT wiki > Sysupgrade: https://openwrt.org/docs/techref/sysupgrade

Re: OpenWISP: Multi-device fleet management for OpenWrt routers

#8

Post by westurner »

dsr_ wrote: post #6
chme wrote: post #5

Earlier quoted context omitted.

Maybe I am missing somehing, but I would assume that base network infrastructure like routers, firewalls and switches have a higher uptime, availability and reliability than ordinary servers.

The problem with push is that the service sitting at the center needs to figure out which devices will need to be re-pushed later on. You can end up with a lot of state that needs action just to get things back to normal. So if you can convince devices to pull at boot time and then regularly thereafter, you know that the three states they can be in are down, good, or soon to be good. Now you only need to take action…

Unattended upgrades fail and sit there requiring manual intervention (due to lack of transactional updates and/or multiple flash slots (root partitions and bootloader configuration)).

Pull style configuration requires the device to hold credentials in order to authorize access to download the new policy set.

It's possible to add an /etc/init.d that runs sysupgrade on boot, install Python and Ansible, configure and confirm remote logging, and then run `ansible-pull`.

ansible-openwrt eliminates the need to have Python on a device: https://github.com/gekmihesg/ansible-openwrt

But then log collection; unless all of the nodes have correctly configured log forwarding at each stage of firmware upgrade, pull-style configuration management will lose logs that push-style configuration management can easily centrally log.

Re: OpenWISP: Multi-device fleet management for OpenWrt routers

#10

Post by _joel »

chatmasta wrote: post #4
chme wrote: post #3

Earlier quoted context omitted.

Maybe just go with ansible or similar: https://github.com/ansibleguy/collection_opnsense

Updating a fleet of embedded devices like routers (which can come online and go offline at any time) will generally be much easier using a pull-based update model. But if you’ve got control over the build and update lifecycle, a push-based approach like ansible might be appropriate.

Ansible does pull? https://docs.ansible.com/ansible/latest/cli/ansible-pull.htm...
Post reply on HN