Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SessionIdGenerator.java

[Bojan Smojver <bo...@binarix.com>]

costin@apache.org wrote:

>   The patch allows systems that have /dev/random to use it instead of the
>   slower Random. Instead of checking for OS==linux ( as in submited patch )
>   we use an option of the module.

Cool.
 
>   The code if the option "useDevRandom" is not set is the same as before.
>   If you set useDevRandom="true" then /dev/random will be used.

Very cool. Where do I whack this option? server.xml? I know it must be a
silly question to ask on Tomcat Dev list... :-)

>   ( Bojan - please review and let me know if it is not what you intended,
>   I'm not sure if the /dev/ransom needs to be closed/open all the time )

I don't think it needs to be opened/closed all the time. Honestly I
can't say for sure. There must be some true Linux experts out there that
can enlighten us on that one. My knowledge is limited to the manual page
(man 4 random) where this file is explained as giving secure random
numbers. If 'entropy pool' is empty, /dev/random will block until this
pool is filled (ie. until there are events in the kernel that can fill
the pool again). The pool gets filled by the 'noise' produced by drivers
and other kernel sources. Whether opening and closing of the stream
makes a difference, I really couldn't say, but it seem to me that it
shouldn't (except for the fact that code execution itself might fill the
pool).

>From Tomcat's perspective it's really better to keep it open. It's going
to run faster. I'm guessing all open streams get closed when Tomcat is
shut down anyway, so that's fine.

And thanks for acting so quickly on this!

Bojan

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SessionIdGenerator.java

[Bojan Smojver <bo...@binarix.com>]

estutes@eas.san-jose.ca.us wrote:
> As pointed out by someone else, at some point on a system that is not
> busy processes will hang on /dev/random waiting for their next chance to
> catch some randomness generated by things like mouse moves.  And if you
> are on a server, the mouse may never move. There will be other trips
> into the kernel, but I think a better strategy would be to get a random
> seed and close your particular connection.  What do you think?

I think I've covered that one in one of my other e-mails, but here is
the summary:

- we should document this properly so that all users can make an
informed decision (*very important*, otherwise there's going to be tons
of e-mail about sudden hangs of Tomcat if this was a bad idea) - if I'm
pointed towards the right document I'll submit a patch

- on a real life server the requests to Apache/Tomcat are coming through
network cards which generates 'kernel noise' and therefore /dev/random
shouldn't really block; you don't have to move the mouse or touch the
keyboard to get random data, any kernel driver counts (I just verified
that by pinging my Linux box from another box); usually the disk is
touched as well when you hit the web pages

- the next problem might be a heavily loaded box (ie. will there be
enough random data for all sessions) - usually on a heavily loaded
machine there will be plenty of random data, so I don't think heavily
loaded boxes should be an issue

- I don't think that opening and closing the /dev/random would make much
difference except for the fact that opening/closing might generate some
random data in the kernel; I'll give here one bad scenario with
/dev/random being constantly opened/closed: we open the /dev/random
(let's say this generates some random data) and then attempt to read
that data, but there wasn't generated and the read blocks - back to
square one :-(

Having said all that, it is my belief everyone should test this in their
particular situation to verify if this approach is good for them or not.
Although I can qualify as a Linux user and hardly as a Linux admin, I'm
nowhere close to being a kernel expert. So all of the above could be
pure BS (did you notice these are my initials - funny, ha ;-)

Bojan

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SessionIdGenerator.java

[es...@eas.san-jose.ca.us]

On 11 Apr, Bojan Smojver wrote:
> estutes@eas.san-jose.ca.us wrote:
>> Given that tomcat should run for days or weeks at a time, I don't
>> think you want to keep /dev/random open. There maybe other processes
>> that also need random data during that time.
> 
> Are you really sure that other processes are unable to use /dev/random
> while Tomcat is using it? It sure doesn't worry my Linux machine. Try
> multiple cats on /dev/random. Works just fine. Or maybe I missed
> something...
> 
> Bojan
As pointed out by someone else, at some point on a system that is not
busy processes will hang on /dev/random waiting for their next chance to
catch some randomness generated by things like mouse moves.  And if you
are on a server, the mouse may never move. There will be other trips
into the kernel, but I think a better strategy would be to get a random
seed and close your particular connection.  What do you think?

=eas=

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SessionIdGenerator.java

[Bojan Smojver <bo...@binarix.com>]

estutes@eas.san-jose.ca.us wrote:
> Given that tomcat should run for days or weeks at a time, I don't think
> you want to keep /dev/random open. There maybe other processes that also
> need random data during that time.

Are you really sure that other processes are unable to use /dev/random
while Tomcat is using it? It sure doesn't worry my Linux machine. Try
multiple cats on /dev/random. Works just fine. Or maybe I missed
something...

Bojan

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SessionIdGenerator.java

[es...@eas.san-jose.ca.us]

On 10 Apr, Bojan Smojver wrote:
> costin@apache.org wrote:
> 
>>   The patch allows systems that have /dev/random to use it instead of
>>   the slower Random. Instead of checking for OS==linux ( as in
>>   submited patch ) we use an option of the module.
> 
> Cool.
>  
>>   The code if the option "useDevRandom" is not set is the same as
>>   before. If you set useDevRandom="true" then /dev/random will be
>>   used.
> 
> Very cool. Where do I whack this option? server.xml? I know it must be
> a silly question to ask on Tomcat Dev list... :-)
> 
>>   ( Bojan - please review and let me know if it is not what you
>>   intended, I'm not sure if the /dev/ransom needs to be closed/open
>>   all the time )
> 
> I don't think it needs to be opened/closed all the time. Honestly I
> can't say for sure. There must be some true Linux experts out there
> that can enlighten us on that one. My knowledge is limited to the
> manual page
> (man 4 random) where this file is explained as giving secure random
> numbers. If 'entropy pool' is empty, /dev/random will block until this
> pool is filled (ie. until there are events in the kernel that can fill
> the pool again). The pool gets filled by the 'noise' produced by
> drivers and other kernel sources. Whether opening and closing of the
> stream makes a difference, I really couldn't say, but it seem to me
> that it shouldn't (except for the fact that code execution itself
> might fill the pool).
> 
>>>From Tomcat's perspective it's really better to keep it open. It's
>>going
> to run faster. I'm guessing all open streams get closed when Tomcat is
> shut down anyway, so that's fine.
> 
> And thanks for acting so quickly on this!
> 
> Bojan
Given that tomcat should run for days or weeks at a time, I don't think
you want to keep /dev/random open. There maybe other processes that also
need random data during that time.

=eas=

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/sessionSessionIdGenerator.java

[Bojan Smojver <bo...@binarix.com>]

cmanolache@yahoo.com wrote:

> <SessionIdGenerator  useDevRandom="true"/>

Thanks. I figured it out after I asked that silly question. It must have
been the most brain dead question you had to answer in a while, I guess.
A good read of server.xml will get you a long way these days ;-)
 
> Note that the option will be disabled by default ( I'm even thinking of
> creating a new DevRandomGenerator and moving it in proposals, but the code
> doesn't affect in any way "normal" random generation and is simple
> enough).
> 
> The main question is what happens on high load - can /dev/random generate
> randoms fast enough ? If not, probably we should use it only to initialize
> the java random genearator.

The problem with /dev/random is not 'can it generate random data fast
enough' but 'is there enough randomness in the system for it to be
generated'. /dev/random is implemented (on Linux) in the kernel, so the
generation itself should be as fast as you can get. Try something like
this on a Linux system that doesn't have anything happening in the
background:

- open two shells while in X Windows
- run 'cat /dev/random' in both
- don't touch the mouse/keyboard and after a while both cats will block
- move the mouse and they'll both continue spitting out 'random' data

So the main problem would probably be that if the system is idle for a
while, /dev/random would block. I was running this patch in Tomcat 3.2.1
in my production environment and never had that kind of problem. But
then again, who knows...

In reality the problem can be solved by simply touching something on the
disk, sending a packet or two using the NIC's or something else. Usually
the systems running Apache/Tomcat are busy serving packets anyway, so
that covers it.

If you wish, we can document all this and then people can make an
informed decision.

Bojan

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SessionIdGenerator.java

[cm...@yahoo.com]

On Tue, 10 Apr 2001, Bojan Smojver wrote:

> >   The code if the option "useDevRandom" is not set is the same as before.
> >   If you set useDevRandom="true" then /dev/random will be used.
> 
> Very cool. Where do I whack this option? server.xml? I know it must be a
> silly question to ask on Tomcat Dev list... :-)

<SessionIdGenerator  useDevRandom="true"/>



> >From Tomcat's perspective it's really better to keep it open. It's going
> to run faster. I'm guessing all open streams get closed when Tomcat is
> shut down anyway, so that's fine.
> 
> And thanks for acting so quickly on this!

Thanks for sending the patches :-)

Note that the option will be disabled by default ( I'm even thinking of
creating a new DevRandomGenerator and moving it in proposals, but the code
doesn't affect in any way "normal" random generation and is simple
enough).

The main question is what happens on high load - can /dev/random generate 
randoms fast enough ? If not, probably we should use it only to initialize
the java random genearator.

Costin