dan
/
liminix
1
0
Fork 5
Code Issues 3 Pull Requests 2 Projects Releases Wiki Activity

deep thoughts

pull/11/head
Daniel Barlow 2024-03-04 22:25:44 +00:00
parent 9730cdd63b
commit 4383462199
1 changed files with 146 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

146
THOUGHTS.txt
View File

@ -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