Well, I don't know what was wrong with catting random data to /dev/random and /dev/urandom, but it didn't to diddly. "apt install haveged", howver, and I'm now booting in ~20 seconds instead of 3 - 5 minutes. (It adds entropy -- or, if you prefer, "entropy" -- by seeing how long certain things take to execute, and then doing it again, and again, and looking for deltas.)
#winning Thanks, all... -Ken On 2017-08-08 15:18, Joshua Judson Rosen wrote: > On 08/08/2017 02:52 PM, Ken D'Ambrosio wrote: >> On 2017-08-08 14:43, Bill Freeman wrote: >>> I don't know, but getrandom() may well be using /dev/urandom (or a >>> related facility). And that, in turn, might be waiting to "collect >>> sufficient entropy". So some network traffic, keystrokes, whatever, >>> need to happen between boot time and the first random emission, or >>> that first "random" number becomes predictable. Since random numbers >>> are often used cryptographically, predictability is a bad thing. >> >> True, but there's debate about just *how* predictable, etc. Not a >> subject for this particular thread, but I'd be perfectly happy with >> udev >> almost-as-random. >> >>> As to why ruby is designed to require a random number before being >>> asked to do something dependent on such a random number is a question >>> for the ruby developers. >> >> Email already sent. :-) >> >>> Re-linking /dev/urandom will probably break lots of things. Maybe >>> run >>> your script in a chroot jail that has a different /dev/urandom could >>> work. >> >> Alas, no -- I'm doing various admin chores, and a chroot won't be >> helpful. >> >>> Is your script too complex to rewrite in bash? Not a general >>> solution, but as a workaround it has its appeal. >> >> *sigh* This is probably where I'm gonna wind up (or Perl, or Python). >> Except I've now written a good handful of scripts that people are >> waiting on, and it's gonna cause me physical pain to have to re-do >> them >> at this point. >> >> C'est la vie. I guess that's the way the Ruby crumbles... > > Instead of rewriting the whole thing, why not just seed the RNG > manually? > > Slightly relevant-looking discussion BTW: > > https://bugs.ruby-lang.org/issues/9569#note-56 > > ... mainly in that it points to the updated random(4) Linux man page, > which says: > > The /dev/random interface is considered a legacy > interface, and > /dev/urandom is preferred and sufficient in all use cases, > with the > exception of applications which require randomness during > early boot > time; for these applications, getrandom(2) must be used > instead, > because it will block until the entropy pool is initialized. > > So, there you go. "until the entropy pool is initialized" is apparently > about 3 minutes in your case ;) > > You should be able to explicitly seed Ruby's internal RNG, > or explicitly seed the system RNG by writing bytes into > /dev/random or /dev/urandom. > > If you want `instant good entropy' at boot, you can even store > some random data into a file at shutdown and then seed from that file > at boot (be sure to invalidate that cache before seeding from it > though, > to ensure that you don't use the same seed twice!). IIRC there are > some preexisting packages for this, and some distributions even do it > by default. > > If you write a systemd service, it looks like you can depend on > systemd-random-seed.service. _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/