09-27-2011 09:33 AM
Problem Description:For an Oracle E-business upgrade. Oracle wants us to follow these instructions (see below). I am concerned about whether this would have impact to the HP-UX operating system to move/link /dev/urandom as described.
Should I be concerned about OS impact or instead will it only impact applications that are currently referencing /dev/random. Namely, looking at lsof output I see that only java stuff related to Oracle E-business has /dev/random file open currently. So is there any danger to OS stability if /dev/random is moved as described and then /dev/urandom is linked from /dev/random? Has anyone ever asked about this note (below). What is potential impact from your perspective of us following the steps as outlined and am I just being a nervous pervous here.
To implement the solution, please execute the following steps:
1 - Stop upgrade
2 - rename /dev/random to /dev/random_org for example
3 - Create a link to /dev/urandom called /dev/random
4 - Restart the upgrade
Solved! Go to Solution.
09-27-2011 10:56 AM
/dev/random and /dev/urandom are OS services offered to applications. Modifying the device nodes should have no impact to the OS itself. (In HP-UX 11.11, this service is an optional component.)
Both /dev/random and /dev/urandom provide high-quality random numbers. The difference is that /dev/random is supposed to provide only "true" randomness, while /dev/urandom provides pseudo-random numbers using a cryptographically strong pseudo-random number generator algorithm. For a computer, producing true randomness is very hard: if you attempt to read /dev/random very fast, there might not be enough true random numbers available. At that point, the /dev/random device read operation will wait until more random numbers can be produced by the OS, causing the application that is reading /dev/random to stall. The pseudo-random data provided by /dev/urandom should be "good enough for most purposes" and it can be produced much faster.
The E-business application is obviously using SSL, and is probably expecting a large number of inbound SSL connections (probably HTTPS). The fact that Oracle instructs you to link /dev/urandom to /dev/random suggests that the application is designed to use /dev/random but then the developers have found out that the limited amount of available true randomness is causing the application to stall at some points. I'd expect the next version of the application to use /dev/urandom by default, or have an option to choose between /dev/random and /dev/urandom.
09-28-2011 01:37 AM
I think it's secure but can always do:
cp /dev/random /dev/random.orig
before the move (rename)