Re: snmp traps
On 2022-10-19, Alec wrote: > Hi, > Thank you for a quick reply! That is a bit sad that we only have coldStart, > but I udnerstand. > It would be great to have traps for CPU/temperature threshold breaches for > general stuff and addition (especially) as well as deletion of IP addresses > from a given table. PF tables are polled by snmpd when the relevant MIBs are requested, there's no 'push notification' from the kernel about changes to these. While not impossible this would require fairly wide ranging changes to implement in a sane way. (snmpd can't really just keep fetching the tables periodically itself and compare them to find changes...) Temperature alerts are indeed something that would be useful, though there isn't a notion of "what temperature is too high/low" in the kernel framework (other than "does the sensor itself report 'critical'" which IME is not actually very useful). This would probably best be done in conjunction with sensorsd and its configuration language (perhaps even moving the whole sensors mib there from snmpd-metrics, though that might be overkill). However I think you could /probably/ already implement this yourself by calling snmp(1) 'trap' from sensorsd if you wanted this now. > For future references, are there any specific traps you would like to > see implemented? Not a high priority, but the most useful for me would be linkDown, linkUp (.1.3.6.1.6.3.1.1.5.3 and .4), and BGP neighbour state (bgpEstablished, bgpBackwardTransition from BGP4-MIB). The latter being more useful (as the link states can be picked up easily enough by polling).
Re: snmp traps
On Wednesday, October 19, 2022 at 06:42:18 p.m. GMT+9, Stuart Henderson wrote: On 2022-10-19, All wrote: > Hi, > Thank you for a quick reply! That is a bit sad that we only have coldStart, > but I udnerstand. > It would be great to have traps for CPU/temperature threshold breaches for > general stuff and addition (especially) as well as deletion of IP addresses > from a given table. >PF tables are polled by snmpd when the relevant MIBs are requested, >there's no 'push notification' from the kernel about changes to these. >While not impossible this would require fairly wide ranging changes >to implement in a sane way. (snmpd can't really just keep fetching the >tables periodically itself and compare them to find changes...) Right. Vendors that do implement it in their devices usually bake it in, so indeed it will require big changes. >Temperature alerts are indeed something that would be useful, though >there isn't a notion of "what temperature is too high/low" in the kernel >framework (other than "does the sensor itself report 'critical'" which >IME is not actually very useful). This would probably best be done in >conjunction with sensorsd and its configuration language (perhaps even >moving the whole sensors mib there from snmpd-metrics, though that >might be overkill). >However I think you could /probably/ already implement this yourself by >calling snmp(1) 'trap' from sensorsd if you wanted this now. Ah, for that we have wonderful swiss-knife called "ifstated" that can be abused to do almost anything. Perhaps I might have to go to that route, I already abuse it for so many other things. It's an awesome tool, imho. I guess I can add voltages there too and UPS state (onBattery/onAC, etc) > For future references, are there any specific traps you would like to > see implemented? >Not a high priority, but the most useful for me would be linkDown, >linkUp (.1.3.6.1.6.3.1.1.5.3 and .4), and BGP neighbour state >(bgpEstablished, bgpBackwardTransition from BGP4-MIB). The latter >being more useful (as the link states can be picked up easily enough >by polling). linkDown/Up are probably the most common and standard to have. Though not so pressing for me.
Re: snmp traps
On 2022-10-19, Alec wrote: > >>However I think you could /probably/ already implement this yourself by >>calling snmp(1) 'trap' from sensorsd if you wanted this now. > > Ah, for that we have wonderful swiss-knife called "ifstated" that can be > abused to do almost anything. > Perhaps I might have to go to that route, I already abuse it for so many > other things. It's an awesome tool, imho. > I guess I can add voltages there too and UPS state (onBattery/onAC, etc) sensorsd monitors hw.sensors.* in a more lightweight way than is possible with ifstated (which is, of course, optimized for monitoring interface states), i.e. directly by sysctl(2) calls rather than by shelling out to call sysctl(8). And already handles low/high etc.
Re: OpenBSD Nitrokey and GPG
I have tried using my NitroKey Pro 2 on my Openbsd 7.1 box using gpg-agent with an empty scdaemon.conf file. I get the same error if pcscd is not started. If started, I can run all gpg card commands. On Tue, Oct 18 2022, William White wrote: > I have a Nitrokey Start that I use to hold my private GPG key. It > works on Linux, but doesn't seem to work on OpenBSD. dmesg shows only > the following line when plugged in: > > ugen0 at uhub0 port 4 "Nitrokey Nitrokey Start" rev 2.00/2.00 addr 2 > > I have imported the public key (shows in gpg -k) but gpg -K does not > list the private key. gpg --card-status says > > gpg: selecting card failed: Operation not supported by device gpg: > OpenPGP card not available: Operation not supported by device > > Can anyone tell me for sure if it's supported or not? Or if I need to > do something else to get it recognized.
