Usually I change securerandom.source in $JAVA_HOME/jre/lib/security/java.security to file:/dev/./urandom . This means that whoever runs WLS doesn’t have to bother about this parameter 🙂 It is supposed to be a little less random than /dev/random , but I really don’t know what is the real risk in that.

Also I noticed that you have more issues with slowness caused by low entropy on VM’s than on physical hardware.

Anyway, great post. You have a new subscription to your blog 🙂

Hi Peter,

Could you please expand on why

MEM_ARGS=”${MEM_ARGS} -Djava.security.egd=file:/dev/./urandom”

should not be used in production … ? Is it because the setDomain.sh gets overwritten? Performance issues?

I’m using

-Djava.security.egd=file:/dev/./urandom

in java.security with “securesource.source=file:/dev/urandom” commented out, which seems to work, but is that the right way of doing things?

Many thanks!

Hi,

Great post, rngd also helps for me

# install the package, its probably already there
yum install rng-tools

After installation you can try to start and get such error:
service rngd start

Starting rngd: can’t open entropy source(tpm or intel/amd rng)
Maybe RNG device modules are not loaded

Edit /etc/sysconfig/rngd
EXTRAOPTIONS=”-r /dev/urandom -o /dev/random -b”

# start the service
service rngd start

# also when it reboots
chkconfig rngd on

# check the settings
chkconfig –list rngd

Thanks