search

jsdelivr / globalping-hwprobe

OS image for Globalping hardware probes. Become a GitHub Sponsor to get yours!
19 stars 6 forks source link

Small persistent storage #48

Open jimaek opened 1 month ago

jimaek commented 1 month ago

I think it makes sense to create a new small volume with like 10MB of storage to save there something like adoption info, to avoid losing probes when the IP changes when the probe was offline.

@kernelgurumeditation is there a safe way to do it to avoid killing the SD card? Maybe enabling RAM caching of the files, or some other configuration?

MartinKolarik commented 1 month ago

We already have this in https://github.com/jsdelivr/globalping-probe/issues/240. For HW probes, I was actually thinking we let the firmware itself generate the UUID, store it, and expose it to the probe as a variable. The probe itself doesn't need to write anything.

kernelgurumeditation commented 1 month ago

@jimaek , if the issue is to have a reliable UUID, we can use the hardware's unique identifier. It will persist even across sdcard swaps....

jimaek commented 1 month ago

How is it generated and how reliable is it?

MartinKolarik commented 1 month ago

I would rather preserve a way to change it if needed. It should survive restarts and container updates, but a full FW flash should get a new ID.

kernelgurumeditation commented 1 month ago

@jimaek Well, it uses the factory-set SN and other unique data on the chip. If the factory doesn't commit an error, it should be pretty unique.

jimaek commented 1 month ago

I assume to expose it we would need to flash a new firmware? If we could enable it for everyone with a probe update it would be interesting. But if not then up to Martin

kernelgurumeditation commented 1 month ago

Yes, it requires a new firmware. Add it to the next version bucket list :)

MartinKolarik commented 5 days ago

@kernelgurumeditation the probes will now read GP_PROBE_UUID variable and use it when set. Please add a mechanism to generate a random UUID once, store it, and expose it as that variable. The value SHOULD NOT change between container updates but SHOULD change if the user reflashes the firmware.

kernelgurumeditation commented 5 days ago

@MartinKolarik Ok, I will do it!

jimaek commented 3 days ago

@kernelgurumeditation Do you have an ETA for the firmware update? I want to flash some new SD cards soon and would prefer to include the update. But if it could take a while I won't wait