commit 4383462199950f71a2f9af5a5769410ba999ac04
parent 9730cdd63b230865d599c403e981fb337d759818
Author: Daniel Barlow <dan@telent.net>
Date: Mon, 4 Mar 2024 22:25:44 +0000
deep thoughts
Diffstat:
| M | THOUGHTS.txt | | | 146 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
1 file changed, 146 insertions(+), 0 deletions(-)
diff --git 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
