forked from DGNum/liminix
deep thoughts
This commit is contained in:
Daniel Barlow
parent
9730cdd63b
commit
4383462199
1 changed files with 146 additions and 0 deletions
146
THOUGHTS.txt
146
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
|
||||
|
|
|
|||
Loading…
Reference in a new issue