From 4383462199950f71a2f9af5a5769410ba999ac04 Mon Sep 17 00:00:00 2001 From: Daniel Barlow Date: Mon, 4 Mar 2024 22:25:44 +0000 Subject: [PATCH] deep thoughts --- THOUGHTS.txt | 146 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 146 insertions(+) diff --git a/THOUGHTS.txt b/THOUGHTS.txt index a93985e..58ecbb5 100644 --- a/THOUGHTS.txt +++ b/THOUGHTS.txt @@ -4137,3 +4137,149 @@ p-clock-init,mfp,allows-mesh-bcast crc32 62f7565f [ 16.762697] ath10k_pci 0000:00:00.0: pdev param 0 not supported by firmware [ 23.030622] ath10k_pci 0000:00:00.0: pdev param 0 not supported by firmware [ + + +Tue Feb 27 23:16:27 GMT 2024 + +We made it a full week with rotuer running internet chez nous and no +need for an intervention, so I am happy to call it "production". There are +still things that need fixing but they're mostly within scope for +a services refresh + +I have embarked on "profiles" by creating a wap.nix + +I think we could have a service module for resolvconf + +It would be good to build a wap.nix example for the belkin and we +could start looking at ubifs + +I've lost a chunk of notes about using events to drive desired service +state. There is probably only going to be one udev listener, so +what if we have udev as a config key thusly + +udev.rules = [ +{ + match = { + SUBSYSTEM = "rpmsg"; + ATTR.name = "DATA5_CNTL"; + }; + + service = longrun { + name = "lte-modem"; + run = "blah blah blah"; + }; +} + +# this one would be provided by the bridge module instead of +# adding bridge member services to the default target + +{ + match = { + SUBSYSTEM="net"; + ID_PATH="pci-0000:04:00.0"; + ATTR.operstate = "up"; + }; + + service = oneshot { + up = "ip link set dev $dev master $(output ${primary} ifname)"; + down = "ip link set dev $(output ${member} ifname) nomaster"; + } +} +] + +This works for udev/sysfs, but we want a similar architecture(sic) for +user-generated target state so we could have services that run on e.g. +"is the ppp0 service healthy" or not. Probably there isn't a top-level +config key for each service though + +services.wan = svc.ppoe.build { .... }; +services.lte = watcher.build { + watching = services.wan; + match = { + # an expression matching the outputs of the service + # to be watched + health = "failing"; + }; + service = oneshot { + run = "start_lte_blah"; + }; +} + +thing is, we could use this syntax also for sysfs watches, but not vice versa + +... but it's not quite the same because here we're doing static matches +on contents of files, whereas the udev one is a query expression on the +sysfs database. we might need that flexibiity to implement "mount the +backup drive no matter _which_ damn sda_n_ device it appears as". I don't +know if there's the same need for service outputs - postulate the +existence of a collection of services which are all similar enough that +some other service can watch them all and do $something when one of +the changes state. Or a single service with very complicated outputs. +For example, something could watch the snmp database and update service +status depending on what it finds. Or something something mqtt... + +we find that the "match" needs to be interpreted differently according +to the thing being watched. perhaps the service being watched needs to +provide a "watch me" interface somehow which accepts match criteria and +outputs a true/false. Something else then needs to + + +services.addmember = services.udev.watch { + match = { + SUBSYSTEM = "net"; + ID_PATH = "pci-0000:04:00.0"; + ATTR.operstate = "up"; + }; + + service = oneshot { + up = "ip link set dev $dev master $(output ${primary} ifname)"; + down = "ip link set dev $(output ${member} ifname) nomaster"; + }; +} + +Sat Mar 2 15:37:29 GMT 2024 + +Simply put, what I think it boils down to is that we want a service +which acts as an actuator or control switch for another service, +and will start/stop that controlled service according to some +criteria. + +services.addmember = svc.network.ifwatch.build { + interface = config.hardware.networkInterfaces.lan1; + + # this should be part of the definition not the params + service = oneshot { + name = "member-${bridge}-${interface}"; + up = "ip link set dev $dev master $(output ${primary} ifname)"; + down = "ip link set dev $(output ${member} ifname) nomaster"; + }; +} + +we could start by writing this. we need to adapt ifwait + +Sun Mar 3 17:09:21 GMT 2024 + +this is annoyingly hard to test. the tests we'd like to write are + +1) when it gets events that don't match the requirement, nothing happens +2) when it gets an event that should start the service, the + service starts +3) when stop should stop +4) when start and already started, nothing happens +5) when stop and already stopped, nothing happens + +what do we do if service fails to start? s6-rc will eventually reset it +to "down", I think: do we need to take action? + +Mon Mar 4 20:46:55 GMT 2024 + +# relevant but not correct for this model: https://www.forked.net/forums/viewtopic.php?f=13&t=3490 + +# power on port 5 +snmpset -v 1 -c private 192.168.5.14 .1.3.6.1.4.1.318.1.1.4.4.2.1.3.5 integer 1 + +# power off port 5 +snmpset -v 1 -c private 192.168.5.14 .1.3.6.1.4.1.318.1.1.4.4.2.1.3.5 integer 2 + +# toggle off/on port 5 +snmpset -v 1 -c private 192.168.5.14 .1.3.6.1.4.1.318.1.1.4.4.2.1.3.5 integer 3