Urandom
 

Hello all!

I been trying to use the default seeding scripts for urandom, which are found in the man-pages random.

When I use these scripts, for startup and shutdown, I receive an error during the startup that states /proc/sys/kernel/random/poolsize file or directory is not found.

However, this file does exist and when I cat /proc/sys/kernel/random/poolsize it states that the file size is 4096, which is the default size, but it should be 512.

So it seems that either, and yes I am a noob so don't laugh when I say this, the poolsize file is not being mounted or it's a bug.

Can anyone here help me?

Btw, I am using Debian Etch with kernel version 2.6.18-5-686 (stock, but 4.02 Etch).

Unless you are customizing something, the distro probably already takes care of the carry-over from shutdown to startup. Have you taken a look at /etc/init.d/urandom to see if it already does what you want? (I am basing the name of that file on Ubuntu; while I have the etch disks, I've not yet installed.)

I was used to the pool size being 512 on older distros. But I noticed on Ubuntu 6.10 (edgy) it was 4096. Its probably a good idea to be using the bigger pool.

Back to your original question ... I am wondering if the startup script is getting run before the /proc filesystem gets mounted. In other words, a question of sequencing. But seriously, unless you have a good reason not to, I would just go with the default scripts. This is a quite standard thing, so I am sure the distro already does it.

I don't know, call me paranoid but from what I have heard is that the default script for urandom isn't so random. Thus, the need to use the scripts supplied in the random man-pages.

Just to give you an update on using the random man-page scripts:

After being in the freenode debian chatroom I was able to get the script to initialize seeding, but the thing is that it initializes twice.

The first time is successful, but uses the default file size 4096. However, the the second initialization, which occurs right after the first fails stating: /proc/sys/kernel/random/poolsize file or directory is not found and incidently is the 512 file, which was to be used.

And as to the mounting problem - well the script is numbered S55 in rcS.d, well after the 40 mount numbers. So it's not a mounting problem.

Actual script is this:

#! /bin/sh
### BEGIN INIT INFO
# Provides: urandom
# Required-Start: $local_fs
# Required-Stop: $local_fs
# Default-Start: S
# Default-Stop: 0 6
# Short-Description: Save and restore random seed between restarts.
# Description This script saves the random seed between restarts.
# It is called from the boot, halt and reboot scripts.
### END INIT INFO

[ -c /dev/urandom ] || exit 0

PATH=/sbin:/usr/sbin:/bin:/usr/bin
SAVEDFILE=/var/lib/urandom/random-seed
POOLSIZE=512
[ -f /proc/sys/kernel/random/poolsize ] && POOLSIZE="$(cat /proc/sys/kernel/random/poolsize)"
. /lib/init/vars.sh

. /lib/lsb/init-functions

case "$1" in
start|"")
echo "Initializing random number generator..."
random_seed=/var/run/random-seed
# Carry a random seed from start-up to start-up
# Load and then save the whole entropy pool
if [ -f $random_seed ];
then
cat $random_seed >/dev/urandom
else
touch $random_seed
fi
chmod 600 $random_seed
poolfile=/proc/sys/kernel/random/poolsize
[ -r $poolfile ] && bytes=`cat $poolfile` || bytes=512
dd if=/dev/urandom of=$random_seed count=1 bs=$bytes
;;
stop)
# Carry a random seed from shut-down to start-up
# Save the whole entropy pool
echo "Saving random seed..."
random_seed=/var/run/random-seed
touch $random_seed
chmod 600 $random_seed
poolfile=/proc/sys/kernel/random/poolsize
[ -r $poolfile ] && bytes=`cat $poolfile` || bytes=512
dd if=/dev/urandom of=$random_seed count=1 bs=$bytes
;;
restart|reload|force-reload)
echo "Error: argument '$1' not supported" >&2
exit 3
;;
*)
echo "Usage: urandom start|stop" >&2
exit 3
;;
esac

:

This script is linked from /etc/init.d/urandom in rcS.d (startup), rc0.d (shut down) and rc6.d (reboot). So it's a modified version of the original (/etc/init.d/urandom).

The fact that this script causes the seeding process to be initialized twice, and fails in seeding a 512 file, which is defined by the script, further adds to the idea that this is a bug of some kind.

The problem with all this is, however, that no bug reports can be levied against urandom with debian, but im sure this isn't a problem with urandom - just something deeper in the call feature of this line: [ -r $poolfile ] && bytes=`cat $poolfile` || bytes=512 in the script (because this is the line the error message points to) or in how debian interprets this line.

I am still seeking an answer to this problem, so if anyone out there can help I would be most grateful.

I am quite confused about your post. I believe normally a link in /etc/rcS.d (which you say is numbered at 55) would point to the script /etc/init.d/urandom. Instead, it points to the script you posted which resides elsewhere and is a modification of /etc/init.d/urandom? Your talk of /etc/init.d/urandom linking to the posted script baffles me.

You say this script initializes the PRNG twice, but I only see it once, in the line:

Just to be clear, the file that carries over the data from shutdown to boot, and is used to initialize the PRNG is /var/run/random-seed, aka $random_seed. I believe the pseudo file /proc/sys/kernel/random/poolsize, aka $pool_file, contains the size of the entropy pool the kernel is currently maintaining.

WRT "how Debian interprets this line," this script is being intererpreted by whatever Debian uses for /bin/sh. On some distros this is a link to /bin/bash, but bash has slightly different behavior when called as sh.

The line

means if $poolfile is a readable file (by the current user, in this case root), set the variable bytes to the contents of $poolfile. Otherwise set bytes to 512. Also set it to 512 if the cat command returned an error (which it sounds like it did.) It's baffling to see how this could fail since it first tests for the existence and readability of $poolfile. Is it possible there is some sort of an unprintable character in there somewhere that is screwing this line up? (You can try deleting the line in an editor and retyping it.) You can also try manually running this file, as root and with the parameter start (you aren't going to hurt anything) to see if it still produces that error.

I am also confused why that line (along with its counterpart in the stop branch) even exists in the script, since $POOLSIZE was already set to that value earlier in the script. I.e., why didn't it just use the existing variable?

Finally, the script you posted is pretty much what I would expect to find as standard in any distro. It can be summarized as 1) at shutdown, save the entropy (by reading /dev/urandom) in the PRNG to a file and 2) at startup, put the entropy back into the PRNG by writing this file to /dev/urandom, and then save the entropy back to the file again, as is done in shutdown. My understanding of this last step is so that even if the system is not shutdown properly, the random-seed file is still different for the next boot than from the last. The rest of the script is housekeeping pertaining to the size of the entropy pool, the existence of files, etc.

***Skip this***

Well I rewrote the line, [ -r $poolfile ] && bytes=`cat $poolfile` || bytes=512, as you suggest blackhole54, but it didn't change anything - it still initializes twice, with the second initialization failing and stating: /proc/sys/kernel/random/poolsize file or directory is not found.

I changed the bytes to $poolfile and it would initialize the script three times with each failing and stating: /proc/sys/kernel/random/poolsize file or directory is not found.

So I decided to go back and use the original script for urandom, but I changed one aspect of it.

In the start section of the original urandom script there is this bit: [ "$VERBOSE" = no ]. I changed the "no" to a "yes" so I could see what occurred during the initialization process of this script.

Lo and behold, the same problem occurred two initializations with the second one failing and giving the message /proc/sys/kernel/random/poolsize file or directory is not found.

Now, blackhole54 it would be interesting if you would test this, but considering that you are using Ubuntu, and not Debian, you would need to get rid of usplash or whatever prog hides the init messages during bootup, restarts and shutdowns.

If anyone using Debian would be willing to do this, change [ "$VERBOSE" = no ] to [ "$VERBOSE" = yes ] in the start section of the urandom script found in /etc/init.d (note that there are two places where this is found in the start section) and reboot their system and see if an error message occurs and report what happened I would be most grateful.

Also if you are going to test this do a soft reboot or hard. Do not use invoke-rc.d urandom start to test the script for the problem, at least for me, never manifested itself when using this utility to test it - only when I did a soft/hard reboot.

If others also see this same behavior, with the original urandom script with verbose mode on, this may very well indeed be a bug.

I am not sure whether the script actually runs with invoke-rc.d. To be sure it runs, try (as root):

I do not use a splash screen when I boot. I don't see any error, but then things sometimes scroll by rather fast. I also didn't see it announce that it was running /etc/init.d/urandom. (Perhaps it doesn't announce this. I did verify that it had run from its access time.) Do you know if this appears in any of the logs? I didn't see anything. Also, my script is slightly different than yours:

BTW, I still don't understand what you mean by urandom getting initialized 2 or 3 times.

In order to see the initialization message, in this section of the script:

you need to change [ "$VERBOSE" = no ] to [ "$VERBOSE" = yes ] in both places.

However, after going over to a friends house and changing his script to verbose mode it only initialized once.

So it seems that I may have also altered my original backup of the script (what can I say I'm a noob).

Anyways, blackhole54, thanks for the help (even though in someways it was like a wild goose chase) and also posting the original script.

Still though it would have been nice if the script parts from random man-pages would have worked or that we found a solution to the problem.

And as to the modified script initializing twice or even three times? Well it would go through the initialization process saying: Initializing random generator (or something like that)... 1+0 1+0 4069 bytes (again something like that). Then it would do it again Initializing random generator (or something like that)... 1+0 1+0 line: 37 /proc/sys/kernel/random/poolsize file or directory is not found (or something like that).

Anyways, thanks again blackhole54.

Thanks for the explanation. I am glad you got it working. As far as "altering original backup," let me warn you about something I've been burned by. (Unforturnately, I have forgotten details.) I don't know how you created your backup, but I've run into the situation where an editor I was using (probably vi/vim) was configured to save the original file as a backup. Which, after more than I edit, clobbered the backup I had so carefully made. :( So you might want to check how you tools are configured. The easiest way is just trying multiple edits (actually closing the editor down between them) on some dummy file and see what happens.

Good luck as you continue exploring Linux!

EDIT: In case you don't know, the verbosity of the logging at boot time is intended to be controlled by the variable VERBOSE (or possibly INIT_VERBOSE) in the file /etc/default/rcS. At least that is the way it is in Ubuntu. When I changed this, I did indeed see a "Initializing random number generator" in /var/log/boot, but still didn't see it as it scrolled post. (It was probably just too fast.)

I created a script (posted below) from the man page. I added the case statement for making it consistent with the startup scripts Debian/Ubuntu use and I have it log its output (both stdout and stderr) to a file along with a trace of the script excution (set -x). The only other change was the location of the file ("random-seed") for carrying the entropy from shutdown to next boot. The directory the man page script uses doesn't persist across boots in Ubuntu. Being rather paranoid myself, I also didn't want to use the same file the real script used.

I created a link at the S54 level in /etc/rcS.d for the script and rebooted the computer twice. The first time there would be no "random seed" and the second time there would be. The log file showed no errors, so other than the glitch of /var/run not persisting across boots, the logic in the man page looks fine to me. You can try the test yourself and see if you come up with any errors. But personally, other than testing, I would suggest you stick with the distro's script. If its like Ubuntu's, it has the same logic as indicated in the man page except for a more general handling of the pool size.

Here is the script I used:

And here is the resulting log file:

Yeah I used gedit to edit the original urandom file and even though I swear that I renamed the urandm~ backup to urandom~00 it seems that it wasn't the case. Lucky, for me, that what I was editing wasn't system critical :cool:.

Now that rocks, and even though I haven't tested your script (which I will do and post back to tell you how it went), just the fact that you (or anyone for that matter, even a nub like - in time of course) are able to make your own script and even come up with a work around for the problems in the man-page script rocks!

This is the true beauty of linux (at least for me), that an individual can turn a system into what they want and make it do the things s/he wants it to. And make no mistake it's just not some code guru dictating things. No, it's more like a mutual respect between user and machine; that is linux (the kernel and the progs created that encompass it enables the user towards a path of freedom) will talk to the user and tell the user what is wrong - thereby putting the power into the hands of the user to correct that which went astray.

Yes, linux does speak to its users, but the user needs to know its jargon, its intricacies of directory structure, init system, driver base, scripting language and its heart the kernel in order to fully emancipate themselves from being controlled by a machine (like in the windows world) and step into a mutual relationship of respect between man and the thing people call a computer. And blackhole54 you are an example of such a person.

Also this conversation that we been having can be directly linked to how this mutual relationship is propagated between linux and user - in that this mutual relationship spawns a community that is interested in freeing others as well. And the fact that you, blackhole54, went so far as to write a new script and figure out the problems that I was encountering speaks volumes of not only how much you value linux and its community, but also how much the community and linux itself values you.


Again thank you blackhole54 and I will let you know in a few days how that script worked out for me.

Yeah, freedom is great. At this point I am so used to being able to do what I want with the system (within my capabilities!) that I didn't (and don't) think of writing (well, copying actually) that script and testing it as being anything extraordinary. But it is different than the "mother may I" world of proprietary software.