[onerng talk] OneRNG not working after reinstalling onerng_3.6-1_all.deb

[Paul Campbell]

On Friday, 22 February 2019 2:05:21 PM NZDT mark.diamond at yahoo.co.uk wrote:
> One of the difficulties in trying to figure out what might be wrong is that
> I can't find a clear description of the logic of what is being installed
> and what it does. I know I've received a very generous response to my
> query, but it is very piecemeal and leaves me mostly in the dark. I'm an
> experienced programmer but I'm not a kernel device writer or anything like
> that. When I read the replies I've received  about dmesg, udev, etc. I'm
> reminded of just how difficult it is for an expert in something to remember
> what it is like to be ignorant.
> 
> What I've managed to *guess* (without really having a clue whether this is
> correct) from the responses is ...When OneRNG is plugged into a USB port,
> the OS needs to recognize the kind of device it is. It does that by having
> a set of rules (in the case of OneRNG, rules in a file called
> 79-onerng.rules ). The rules need to be in a general system folder that is
> usually called 'udev'.When the device is recognized by the OS, the rules
> say that a shell script 'onerng.sh' should be run to initiate a daemon that
> collects entropy from the device.When the device is removed, the rules also
> describe how the daemon is to be terminated. Am I even vaguely on the right
> track?
> Cheers,Mark

so here's how it works:  the UDEV system (in the kernel) recognises events 
from devices (like device insertion) and send them to the UDEV daemon (these 
days it's become part of systemd) the UDEV daemon finds an appropriate file (in 
this case 79-onerng.rules) and uses it to execute scripts it passing in 
parameters describing what's happening (it's not quite this simple various 
UDEV daemons are buggy in different ways, debian's systemd one is actually 
better in most respects than what it replaced).

>From this point on it's onerng code in particular /etc/onerng.sh .... 
essentially this code has to get around the main limitation placed on scripts 
started by the UDEV daemon - that they can't create their own daemons that 
persist (and that's exactly what we want to do - start an instance of rngd) - 
so the problem is that we want to write code that works on as many different 
linux systems as we can, ones with different init systems (this was coded pre 
systemd) - so what we do in /etc/onerng.sh is we use the lowest common 
denominator, we don't try and code in every init system on the planet, that 
would be a maintenance nightmare, instead we use the 'at' command to schedule 
another run of  /etc/onerng.sh using "at now /etc/onerng.sh" so /etc/onerng.sh 
is run again with either a parameter "daemon" to mean start a daemon, or 
"remove" (when a device is removed)  to stop the daemon

(the recent Ubuntu problems are because they mistakenly started running UDEVD 
before the root filesystem was writeable - the at command couldn't access its 
database, and our scripts couldn't create system lock files in /var/lock)

Starting a daemon essentially involves:
- checking the firmware integrity (there's a python script that does the heavy 
lifting here)
- changing the OneRNG mode to the correct mode
- starting rngd (there are different versions of rngd out there so we have to 
be a bit smart about how we do this)

you'll see a bunch of dd commands in there, they're either to read the firmware 
image or to flush buffers as we change modes

Hopefully that's enough detail to understand the command flow

	Paul