You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "Rob S." <rs...@home.com> on 2001/07/29 15:04:05 UTC
[DOC] TC4 Status
Was there ever any resolution to the docs discussion on -general? I wish I
could contribute to a doc gen or format tool conversation, but I'm far from
an expert in that field. Standing up and waving my arms about the whole
topic probably isn't going to do much either, so I'll talk about something
else for now =)
Right now, the current structure of the docs (index.xml) looks like this:
- Introduction
- Getting Started
- Administrators
- App Developers
- Tomcat Developers
The "Introduction" and "Getting Started" sections are pretty much done -
there are documents on building, installing, and running Tomcat in there
now. Craig is working on porting the "App Developers" guide this weekend.
What's the top priority for the "Administrators" section? Did anyone take a
look at the "Running Multiple Instances" thing? Was that like, too
worthless to even comment on? =)
- r
Re: [PROPOSAL] Standalone SSL
Posted by Christopher Cain <cc...@mhsoftware.com>.
"Pier P. Fumagalli" wrote:
>
> The only thing is that apache uses getpass(), so securing the password when
> you type it, as it's not read from stdin, but ioctling your tty device.
> Asking for your cert on stdin is not _that_ secure.
Depends on your point of view, I suppose. If I'm sitting at the
terminal, it's pretty damn secure. If I'm SSHed in, it's still
reasonably secure. If I'm accessing it over a local network, it's a
little less secure. If I'm telneted in, it's not so secure. IMO, all of
that is still more secure than having it sitting plaintext in a file
that is probably at the very least group readable. At least with the
Apache method some would have to be snooping real-time.
> When the service code is in place, under UNIX, you'll be able to use a
> configuration file owned and readable only by "root", since it's read by the
> JVM process when it's still running as root...
Cool! At that point I would still consider having it in a file a risk,
but a MUCH lower one. My vote would still be to have it prompted for at
startup and NEVER stored anywhere, but if the file is root read-only
that is a vast improvement.
Unfortunately, that still leaves Windoze. Those poor users don't have a
real OS-level security scheme, so for them it's pretty much still stored
for the world to see. And we all know that it can be MUCH easier to
crack a standard Win box than a standard *nix box, so for Win users
having it not stored anywhere would definitely be a better solution.
- Christopher
Re: [PROPOSAL] Standalone SSL
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Christopher Cain at ccain@mhsoftware.com wrote:
> First, just a quick follow-up on the previous thread. Using the keystore
> defaults for the TC4 SSL standalone config works as planned. Trying to
> override the keystoreFile and/or keystorePass defaults, unfortunately,
> does not work (different exceptions for each).
>
> It makes me extremely nervous to have a default password on my certs. Of
> course, it also gets me nothing to change it to a solid password and
> then type that into server.xml. How would you feel about changing the
> SSL process to be more like the Apache approach, where the user is
> prompted on the command line for the store/key password at startup? The
> one drawback is that the web server/container cannot restart without
> human intervention (although the only real-world scenerio I've ever
> encountered where it was really an issue is a clean automated
> shutdown/restart from UPS program, for example).
>
> IMHO, that is a VERY small penalty for not having to store your cert
> password in plaintext in server.xml. In fact, the current solution is
> completely unimplementable in a production system. I'm sure I don't have
> to tell you that one would have to be completely insane to store the
> password to their official cert/private key in the clear in a config
> file. Since I have an immediate need for this functionality, I am
> volunteering to do it. So the only question is, how does everyone feel
> about switching to the Apache approach? I assume that there is not a
> spec issue which would preclude this.
>
> To be fair, I should tell you that I am one of those crypto freaks, so
> please keep that in mind when I start ranting about having a solid
> crypto design =) The primary OSS project I am involved in is a java
> crypto library, so this issue is near and dear to my heart.
The only thing is that apache uses getpass(), so securing the password when
you type it, as it's not read from stdin, but ioctling your tty device.
Asking for your cert on stdin is not _that_ secure.
When the service code is in place, under UNIX, you'll be able to use a
configuration file owned and readable only by "root", since it's read by the
JVM process when it's still running as root...
Pier
Re: [PROPOSAL] Standalone SSL
Posted by Christopher Cain <cc...@mhsoftware.com>.
> Jim Seach wrote:
> [snip]
> >
> > One of the possible custom solutons is to encrypt the
> > other information with your public key, then use the
> > private key to decrypt the other sensitive
> > information. Since the info is signed with the public
> > key, any developer could encrypt information that
> > could only be retrieved by the system. That way, the
> > solution would scale.
You just made me think of another decent argument against the current
implementation. In a typical install setup, all developers,
administrators, and anyone else with access to the box currently has
unfettered access to the keystore, because they have the password. That
is not good. You probably want only a single administrator have access
to the cert, that way you don'd have to get a new one every time someone
leaves the business. Of course a highly-knowledgeable admin could simply
hide the keystore and/or TC conf directory in an inaccessible directory
(preferably both for maximum security), but not everyone is a security
whiz. The opt-in configuration option for a "prompt me" approach makes
it ALOT easier to secure everything right and without goofing up
directory permissions. And again, it is probably the only decent option
for Windoze shops.
- Christopher
Re: [PROPOSAL] Standalone SSL (status?)
Posted by Christopher Cain <cc...@mhsoftware.com>.
I forgot to mention that I plan on offering to port this initial
keystore security solution (whatever it ends up being, although the
Apache-style prompt is so far the only idea being floated) to the 3.3 if
there is any interest in having it. I don't technically consider it a
bug, so the 3.2 branch is probably not appropriate. I'm not sure what
the general feeling on the 3.3 beta process is, if such a thing would be
considered too big a modification at this point, or if anyone in the 3.3
branch is even interested. I just thought I'd point out that you 3.3
cats are more than welcome to speak up on this idea as well.
Also, where are we at in the process? I hate to be pushy (no, really
:-), but I kind of need to get my app up and running, plus I'm up
against it on the cluster management tool I mentioned. If I could just
get a general feel as to how much support the (configurable, as pointed
out by Jim) command-line prompt idea has as far as addressing the
problem, then I can go ahead and jam on that. I'm not necessarily asking
for anything offical (although I probably wouldn't mind :-), but I
mainly just want to make sure that I'm starting on the best possible
(initial) solution ... or at least the solution that would make the most
sense in the long run should it eventually make in into CVS. Unless it
is just something wildly personal, I hate writing code to extend an OSS
product and just sit on it myself, but I kinda need to start coding soon
=)
- Christopher
Re: [PROPOSAL] Standalone SSL
Posted by Christopher Cain <cc...@mhsoftware.com>.
jean-frederic clere wrote:
>
> Encrypting server certificates is not bad but it prevents starting the server
> automaticly.
> Storing this password is a nonsense.
> OpenSSL (for example) allows to modify this password or to have no password.
> If the server certificates is encrypted then we should prompt for the password.
> Of course this password should be independant for the other passwords used in
> the system...
>
> If you are afraid having user passwords stored in the machine you should use
> "user certificates" or something like that....
> (I will go on tomorrow if the thread is still active ;-))
We're in agreement. My initial thought was that either the cert is
encrypted (the secure approach) or not encrypted (the insecure
approach), and if encrypted you are prompted for the password. Since
storing the password in server.xml is essentially the equivalent of not
encryptng it at all, I assumed that we would want to keep the current
approach in place as the "insecure" option both for backwards
compatibility and since the "keytool -genkey" method (which obviously
generates an encrypted keystore) is easy for end users to do. I would
have no objections to the encrypted vs. unencrypted approach you
describe, but that's why I didn't propose it.
As far as the thread still being active tomorrow, I promise I won't let
it die without either a resolution or a fight ;-)
- Christopher
Re: [PROPOSAL] Standalone SSL
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Christopher Cain wrote:
>
> "Craig R. McClanahan" wrote:
> >
> > Not a problem ... it's just that I think you're being a little narrowly
> > focused on the solution to *your* problem, and ignoring the bigger picture
> > :-).
>
> I suppose that's fair to a certain extent. I do see cert protection as a
> little more critical than many of the other resources, but I agree that
> it's just one man's opinion.
>
> > Protecting your certificates is all well and good, and I have no objection to that. It's necessary, but it's not sufficient.
>
> Agreed.
>
> > To flesh out my example, to use features like container-managed security,
> > you need to tell Tomcat how to gain access to its "repository" of
> > usernames, passwords, and role information. Most users will do this
> > either in a database or a directory server, which means that a
> > configuration file read by Tomcat must contain the appropriate database
> > (or directory server) username and password.
>
> Again, I think my goal lies along the same path as the broader goal.
> Authentication is needed, it's just a matter of implementation.
>
> > What I'm saying is that I don't care much about your certificates if I can
> > snoop the database connection information and go hack your passwords
> > database. So protecting just the certificates is insufficient to solve
> > the entire problem you are raising.
>
> True.
>
> > How many challenges for different pieces of sensitive information are you
> > willing to impose on the system administrator? And, is that really any
> > more secure (in that the sysadmin is now going to have *all* the answers
> > to these questions on a little sticky note someplace, instead of
> > memorizing the one password needed to start the server as root :-)?
>
> I guess my eventual vision is something along the lines of a master
> "Tomcat Config" password. This would be used to protect ALL sensitive
> resource information. It could be something as simply as encrypting all
> of this information in a single file in "conf" by deriving a symmetric
> key from the supplied passphrase. Any admin which turns on this feature
> would need to be prompted at startup in order to load any resources,
> such as SSL, which are needed at startup. Anything which can be
> configured on-the-fly while the server is running could be administered
> from the admin context perhaps. The user would be challenged again every
> time he/she wanted to access this page, but we're still talking the same
> "Master Tomcat" password. And since we probably want to run this page in
> SSL, we will need the password at startup anyway :-)
>
> My point is that the prompt code will be necessary anyway, so why not
> let me use it to grab the keystore password (if appropriate) until the
> more comprehensive solution can be put in place? Again, I consider SSL
> the weak link, so that would at least get us some level of protection
> right away, and most of the code will be needed eventually anyway?
> Again, all of this will be optional so that the non-security-sensitive
> environents won't be forced to do any of this.
>
> So does my general idea make sense? And also, does my SSL stopgap sound
> reasonable, or am I being a little selfish here (it wouldn't be the
> first time ;-)?
Encrypting server certificates is not bad but it prevents starting the server
automaticly.
Storing this password is a nonsense.
OpenSSL (for example) allows to modify this password or to have no password.
If the server certificates is encrypted then we should prompt for the password.
Of course this password should be independant for the other passwords used in
the system...
If you are afraid having user passwords stored in the machine you should use
"user certificates" or something like that....
(I will go on tomorrow if the thread is still active ;-))
>
> - Christopher
Re: [PROPOSAL] Standalone SSL
Posted by Christopher Cain <cc...@mhsoftware.com>.
"Craig R. McClanahan" wrote:
>
> Not a problem ... it's just that I think you're being a little narrowly
> focused on the solution to *your* problem, and ignoring the bigger picture
> :-).
I suppose that's fair to a certain extent. I do see cert protection as a
little more critical than many of the other resources, but I agree that
it's just one man's opinion.
> Protecting your certificates is all well and good, and I have no objection to that. It's necessary, but it's not sufficient.
Agreed.
> To flesh out my example, to use features like container-managed security,
> you need to tell Tomcat how to gain access to its "repository" of
> usernames, passwords, and role information. Most users will do this
> either in a database or a directory server, which means that a
> configuration file read by Tomcat must contain the appropriate database
> (or directory server) username and password.
Again, I think my goal lies along the same path as the broader goal.
Authentication is needed, it's just a matter of implementation.
> What I'm saying is that I don't care much about your certificates if I can
> snoop the database connection information and go hack your passwords
> database. So protecting just the certificates is insufficient to solve
> the entire problem you are raising.
True.
> How many challenges for different pieces of sensitive information are you
> willing to impose on the system administrator? And, is that really any
> more secure (in that the sysadmin is now going to have *all* the answers
> to these questions on a little sticky note someplace, instead of
> memorizing the one password needed to start the server as root :-)?
I guess my eventual vision is something along the lines of a master
"Tomcat Config" password. This would be used to protect ALL sensitive
resource information. It could be something as simply as encrypting all
of this information in a single file in "conf" by deriving a symmetric
key from the supplied passphrase. Any admin which turns on this feature
would need to be prompted at startup in order to load any resources,
such as SSL, which are needed at startup. Anything which can be
configured on-the-fly while the server is running could be administered
from the admin context perhaps. The user would be challenged again every
time he/she wanted to access this page, but we're still talking the same
"Master Tomcat" password. And since we probably want to run this page in
SSL, we will need the password at startup anyway :-)
My point is that the prompt code will be necessary anyway, so why not
let me use it to grab the keystore password (if appropriate) until the
more comprehensive solution can be put in place? Again, I consider SSL
the weak link, so that would at least get us some level of protection
right away, and most of the code will be needed eventually anyway?
Again, all of this will be optional so that the non-security-sensitive
environents won't be forced to do any of this.
So does my general idea make sense? And also, does my SSL stopgap sound
reasonable, or am I being a little selfish here (it wouldn't be the
first time ;-)?
- Christopher
Re: [PROPOSAL] Standalone SSL
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 31 Jul 2001, Christopher Cain wrote:
> Quoting Jim Seach <jw...@yahoo.com>:
> >
> > I think we're in agreement. The "initial authentication" problem
> > needs to be resolved before we can talk about leveraging it to solve the
> > other problems. I like your proposal of an optional prompt solution
> > for this.
>
> Cool.
>
> > This is an area of interest for me, but it is not something I spend a
> > large part of my time on, so despite being a CISSP, I am certainly not
> > an expert. I am willing to lend a hand, though, if you are interested
> > in spearheading a general solution to the larger problem.
>
> Cool. You're definitely invited if I can manage to browbeat the commiters into
> signing on for such a monster =)
>
> Seriously, though, it always helps the cause if at least a few people state an
> interest in helping out, so I definitely appreciate it.
>
> One other thing, Craig. In re-reading a few of my posts, I realized that I come
> off a bit heavy-handed. Sorry about that ... it's that damn cryptography-weenie
> demeanor that drill into us before they give us our membership cards :-)
>
Not a problem ... it's just that I think you're being a little narrowly
focused on the solution to *your* problem, and ignoring the bigger picture
:-). Protecting your certificates is all well and good, and I have no
objection to that. It's necessary, but it's not sufficient.
To flesh out my example, to use features like container-managed security,
you need to tell Tomcat how to gain access to its "repository" of
usernames, passwords, and role information. Most users will do this
either in a database or a directory server, which means that a
configuration file read by Tomcat must contain the appropriate database
(or directory server) username and password.
What I'm saying is that I don't care much about your certificates if I can
snoop the database connection information and go hack your passwords
database. So protecting just the certificates is insufficient to solve
the entire problem you are raising.
How many challenges for different pieces of sensitive information are you
willing to impose on the system administrator? And, is that really any
more secure (in that the sysadmin is now going to have *all* the answers
to these questions on a little sticky note someplace, instead of
memorizing the one password needed to start the server as root :-)?
> - Christopher
>
Craig
Re: [PROPOSAL] Standalone SSL
Posted by Christopher Cain <cc...@mhsoftware.com>.
Quoting Jim Seach <jw...@yahoo.com>:
>
> I think we're in agreement. The "initial authentication" problem
> needs to be resolved before we can talk about leveraging it to solve the
> other problems. I like your proposal of an optional prompt solution
> for this.
Cool.
> This is an area of interest for me, but it is not something I spend a
> large part of my time on, so despite being a CISSP, I am certainly not
> an expert. I am willing to lend a hand, though, if you are interested
> in spearheading a general solution to the larger problem.
Cool. You're definitely invited if I can manage to browbeat the commiters into
signing on for such a monster =)
Seriously, though, it always helps the cause if at least a few people state an
interest in helping out, so I definitely appreciate it.
One other thing, Craig. In re-reading a few of my posts, I realized that I come
off a bit heavy-handed. Sorry about that ... it's that damn cryptography-weenie
demeanor that drill into us before they give us our membership cards :-)
- Christopher
Re: [PROPOSAL] Standalone SSL
Posted by Jim Seach <jw...@yahoo.com>.
--- Christopher Cain <cc...@mhsoftware.com> wrote:
>
[SNIP]
> Again, I haven't looked at the
> Realm stuff and what-not, but I can't imagine the possible risk being
> nearly as devestating. I'm not trying to toot my own horn or talk
> about
> how great I am, but security/crypto is my area of expertise, so
> really
> hope I am believed when I say that having your certs so easily
> accessible is an absolute disaster waiting to happen ... much more so
> than any of the other system resource stuff.
>
> As to your point, I would agree that if one is not worried about the
> security of their certs, they are probably not too worried about the
> rest. If you're going to address overall resource security, the certs
> are unquestionably the place to start, IMO. I see it as a problem
> which
> requires immediate addressing. Since I secure my own database access
> stuff, and I don't use realms or LDAP or any other stuff like that, I
> can't really speak to the relative risk there.
>
> > At that point, it might be worth it to develop a standard
> (carefully
> > designed) way to store other information in order to get around
> Craig's
> > scalability concerns.
>
> I think that makes sense. It would be nice to have a well-designed
> "External Resource Security" module that could be seemlessly plugged
> in
> and handle all of it from a single point. And I this would make
> Costin
> proud, but if possible I would to do such a thing in the commons so
> that
> multiple contains could benefit from it. I'd have to sit down and
> examine the feasibility of such a thing of course, WRT any security
> functionality that we would be foregoing by maintaining JDK 1.1
> compatibility, but it's a nice idea (at least in my opinion ... I'm
> not
> sure what the general sentiment is). I would even be willing to
> spearhead such a thing. I know, I know, I've also agreed to help out
> with any Jikes API project, but I didn't necessarily agree to
> SPEARHEAD
> that :-)
>
> In any event, I would still like to see the (at least configurable)
> "prompt me" approach in the CVS tree ASAP for two reasons. First, I
> think it would be nice to get the option out there for the more
> security-sensitive standalone installs immediately. Second, even with
> a
> centralized external security solution, we are still going to have to
> get around the "initial authentication" problem anyway, and I really
> can't see a better method than command-line prompt (unless I am
> missing
> something). There's just no killer way around not storing passwords
> in
> the clear. Once I have this inital keystore issue resolved (on my end
> at
> the very least :-), I'd be more than happy to call for a vote on a
> centralized solution, at which point we could weigh using my existing
> prompt solution for initial authentication.
>
> - Christopher
I think we're in agreement. The "initial authentication" problem needs
to be resolved before we can talk about leveraging it to solve the
other problems. I like your proposal of an optional prompt solution
for this.
This is an area of interest for me, but it is not something I spend a
large part of my time on, so despite being a CISSP, I am certainly not
an expert. I am willing to lend a hand, though, if you are interested
in spearheading a general solution to the larger problem.
Jim
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
Re: [PROPOSAL] Standalone SSL
Posted by Christopher Cain <cc...@mhsoftware.com>.
Jim Seach wrote:
>
> --- Christopher Cain <cc...@mhsoftware.com> wrote:
> >
> >
> > The system would still have to have access to the private key, which
> > would have to be protected with some kind of PBE scheme, in which
> > case
> > you are right back to specifying a password in the config files.
> >
> > Aside from that, it's not really a "custom" solution in the sense
> > that I
> > can implement it without hacking Tomcat. Any possible solution to not
> > storing the password in the clear will require a custom build of
> > Tomcat,
> > which is really one of my points. One can work around the other
> > security
> > issues without resorting to that. I am going to have to hack a more
> > secure solution into Tomcat at this point regardless. My hope is that
> > we
> > can come to some kind of consensus on the best way to lock the SSL
> > keystore down so that I can contribute the code back to the product.
> > IMHO, the current solution is a rather big hole waiting to be
> > exploited
> > and needs addressing anywy, at least in a business production
> > environment.
>
> I agree, this could be done now, since the keystore password is in the
> config file, but my assumption was that it is not worth going through
> the additional effort to secure the other information unless your
> proposal were implemented.
Oh ... you mean securing the JDBC and Realm stuff? I wholeheartedly
agree that leaving your certs/private keys hanging in the breeze is the
single biggest resource security problem at the moment (of the ones that
you as an admin have no control over). Again, I haven't looked at the
Realm stuff and what-not, but I can't imagine the possible risk being
nearly as devestating. I'm not trying to toot my own horn or talk about
how great I am, but security/crypto is my area of expertise, so really
hope I am believed when I say that having your certs so easily
accessible is an absolute disaster waiting to happen ... much more so
than any of the other system resource stuff.
As to your point, I would agree that if one is not worried about the
security of their certs, they are probably not too worried about the
rest. If you're going to address overall resource security, the certs
are unquestionably the place to start, IMO. I see it as a problem which
requires immediate addressing. Since I secure my own database access
stuff, and I don't use realms or LDAP or any other stuff like that, I
can't really speak to the relative risk there.
> At that point, it might be worth it to develop a standard (carefully
> designed) way to store other information in order to get around Craig's
> scalability concerns.
I think that makes sense. It would be nice to have a well-designed
"External Resource Security" module that could be seemlessly plugged in
and handle all of it from a single point. And I this would make Costin
proud, but if possible I would to do such a thing in the commons so that
multiple contains could benefit from it. I'd have to sit down and
examine the feasibility of such a thing of course, WRT any security
functionality that we would be foregoing by maintaining JDK 1.1
compatibility, but it's a nice idea (at least in my opinion ... I'm not
sure what the general sentiment is). I would even be willing to
spearhead such a thing. I know, I know, I've also agreed to help out
with any Jikes API project, but I didn't necessarily agree to SPEARHEAD
that :-)
In any event, I would still like to see the (at least configurable)
"prompt me" approach in the CVS tree ASAP for two reasons. First, I
think it would be nice to get the option out there for the more
security-sensitive standalone installs immediately. Second, even with a
centralized external security solution, we are still going to have to
get around the "initial authentication" problem anyway, and I really
can't see a better method than command-line prompt (unless I am missing
something). There's just no killer way around not storing passwords in
the clear. Once I have this inital keystore issue resolved (on my end at
the very least :-), I'd be more than happy to call for a vote on a
centralized solution, at which point we could weigh using my existing
prompt solution for initial authentication.
- Christopher
Re: [PROPOSAL] Standalone SSL
Posted by Jim Seach <jw...@yahoo.com>.
--- Christopher Cain <cc...@mhsoftware.com> wrote:
>
>
> The system would still have to have access to the private key, which
> would have to be protected with some kind of PBE scheme, in which
> case
> you are right back to specifying a password in the config files.
>
> Aside from that, it's not really a "custom" solution in the sense
> that I
> can implement it without hacking Tomcat. Any possible solution to not
> storing the password in the clear will require a custom build of
> Tomcat,
> which is really one of my points. One can work around the other
> security
> issues without resorting to that. I am going to have to hack a more
> secure solution into Tomcat at this point regardless. My hope is that
> we
> can come to some kind of consensus on the best way to lock the SSL
> keystore down so that I can contribute the code back to the product.
> IMHO, the current solution is a rather big hole waiting to be
> exploited
> and needs addressing anywy, at least in a business production
> environment.
I agree, this could be done now, since the keystore password is in the
config file, but my assumption was that it is not worth going through
the additional effort to secure the other information unless your
proposal were implemented.
At that point, it might be worth it to develop a standard (carefully
designed) way to store other information in order to get around Craig's
scalability concerns.
>
> > Anyway, if you implement the "prompt for key on
> > reboot" it could always be a configurable option, so
> > if someone didn't feel that level of security was
> > necessary, they wouldn't have to use it.
>
> Excellent idea! Configurable is good =) I wouldn't mind at all adding
> that in during my rework, assuming everyone agrees that it makes
> sense
> (and that my basic patches are accepted anyway, of course :-)
>
> - Christopher
Jim
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
Re: [PROPOSAL] Standalone SSL
Posted by Christopher Cain <cc...@mhsoftware.com>.
Jim Seach wrote:
>
> --- Christopher Cain <cc...@mhsoftware.com> wrote:
> >
> > In short, it is currently a needless exposure, and
> > certs are much more
> > important than most other resources. If I paid good
> > money for a real
> > cert signed by a CA, I would especially have a
> > comprehensive security
> > scheme in place to protect it. Leaving the password
> > sitting around would
> > be about the last thing I would possibly do. If your
> > box is compromised,
> > then your cert store is also unquestionably
> > compromised. If your store
> > is compromised, than every cert and private key in
> > that store is
> > worthless. That could potentially be catastrophic in
> > a business
> > environment, and would leave you open to all kinds
> > nasty things. If
> > someone gets ahold of your cert, bad, bad, BAD
> > things can happen. Just
> > ask Microsoft =)
> >
> > And if you should be cracked, and someone
> > masqaurades as you to do bad
> > things, that is a lawsuit you will not win because
> > you did not have take
> > resonable precautions against it. I realize that
> > this is all a bit of
> > Chicken Little-ism, but my point is that SSL
> > implementation is a serious
> > business. And I can choose to lock down the rest of
> > the stuff you
> > mention with a custom solution. I have no such
> > option with the SSL
> > implemention (short of hacking the code, which we
> > can't reasonably
> > expect people to have to do).
> >
>
> One of the possible custom solutons is to encrypt the
> other information with your public key, then use the
> private key to decrypt the other sensitive
> information. Since the info is signed with the public
> key, any developer could encrypt information that
> could only be retrieved by the system. That way, the
> solution would scale.
The system would still have to have access to the private key, which
would have to be protected with some kind of PBE scheme, in which case
you are right back to specifying a password in the config files.
Aside from that, it's not really a "custom" solution in the sense that I
can implement it without hacking Tomcat. Any possible solution to not
storing the password in the clear will require a custom build of Tomcat,
which is really one of my points. One can work around the other security
issues without resorting to that. I am going to have to hack a more
secure solution into Tomcat at this point regardless. My hope is that we
can come to some kind of consensus on the best way to lock the SSL
keystore down so that I can contribute the code back to the product.
IMHO, the current solution is a rather big hole waiting to be exploited
and needs addressing anywy, at least in a business production
environment.
> Anyway, if you implement the "prompt for key on
> reboot" it could always be a configurable option, so
> if someone didn't feel that level of security was
> necessary, they wouldn't have to use it.
Excellent idea! Configurable is good =) I wouldn't mind at all adding
that in during my rework, assuming everyone agrees that it makes sense
(and that my basic patches are accepted anyway, of course :-)
- Christopher
Re: [PROPOSAL] Standalone SSL
Posted by Jim Seach <jw...@yahoo.com>.
--- cmanolache@yahoo.com wrote:
> On Tue, 31 Jul 2001, Jim Seach wrote:
>
> > What I meant was, in order to implement SSL, Tomcat must be able
> to
> > decrypt the keystore to retrieve the private key for the cert. A
> > Tomcat extension or module could be developed to use the private
> key
> > not only to decode the SSL traffic, but also to decode other
> > information like database passwords and so forth that developers
> wished
>
> In particular the admin and/or ajp password :-)
>
> One of the biggest problems is that so many people are installing
> tomcat
> and they just forget to change the passwords.
>
> We already generate a random number for the shutdown command, but a
> module
> that checks if the admin password is still "changethis" and refuse to
> start until the user types a better password will do a lot for
> secuirty
> :-)
>
> I'm not very sure about certificate passwords or other things - but
> if
> someone needs this then great. I think ( IMHO ) the authentication,
> etc
> should happen outside tomcat ( at least in a different process ), I'm
> not
> sure if existing auth servers ( kerberos, tacacs, radius, etc ) have
> any
> support for certificates, but as long as tomcat is running user code
> (
> even with the security manager in place ), I wouldn't trust it more
> than I
> have to.
>
> And don't forget that tomcat may even crash, or hung ( well, if not
> tomcat
It has never crashed on me, except where it was clearly my fault! :)
> maybe some user code or even the JDK or OS ). :-)
>
> Costin
>
I think these are important features/requirements for the "External
Resource Security/Centralized Repository" project that Christopher
would like to pursue, but was waiting for an expression of interest
from the committers.
Can this be construed as the expression of interest he was looking for?
:)
Jim
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
Re: [PROPOSAL] Standalone SSL
Posted by cm...@yahoo.com.
On Tue, 31 Jul 2001, Jim Seach wrote:
> What I meant was, in order to implement SSL, Tomcat must be able to
> decrypt the keystore to retrieve the private key for the cert. A
> Tomcat extension or module could be developed to use the private key
> not only to decode the SSL traffic, but also to decode other
> information like database passwords and so forth that developers wished
In particular the admin and/or ajp password :-)
One of the biggest problems is that so many people are installing tomcat
and they just forget to change the passwords.
We already generate a random number for the shutdown command, but a module
that checks if the admin password is still "changethis" and refuse to
start until the user types a better password will do a lot for secuirty
:-)
I'm not very sure about certificate passwords or other things - but if
someone needs this then great. I think ( IMHO ) the authentication, etc
should happen outside tomcat ( at least in a different process ), I'm not
sure if existing auth servers ( kerberos, tacacs, radius, etc ) have any
support for certificates, but as long as tomcat is running user code (
even with the security manager in place ), I wouldn't trust it more than I
have to.
And don't forget that tomcat may even crash, or hung ( well, if not tomcat
maybe some user code or even the JDK or OS ). :-)
Costin
Re: [PROPOSAL] Standalone SSL
Posted by Jim Seach <jw...@yahoo.com>.
--- "Pier P. Fumagalli" <pi...@betaversion.org> wrote:
> Jim Seach at jwseach@yahoo.com wrote:
> >
> > One of the possible custom solutons is to encrypt the
> > other information with your public key, then use the
> > private key to decrypt the other sensitive
> > information.
>
> Cool, are we going to use a private key to encrypt the password for
> the
> private key of Tomcat? Cool, kinda gets recursive... :) WHAT?
>
> Pier
>
That would be a good trick! :)
What I meant was, in order to implement SSL, Tomcat must be able to
decrypt the keystore to retrieve the private key for the cert. A
Tomcat extension or module could be developed to use the private key
not only to decode the SSL traffic, but also to decode other
information like database passwords and so forth that developers wished
to securely make available to Tomcat. (How to make this information
available to the webapp code would have to be carefully designed) If
Christopher's suggestion about prompting for the keystore key is
implemented, none of these private pieces of information need to be
stored in plaintext.
Jim
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
Re: [PROPOSAL] Standalone SSL
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Jim Seach at jwseach@yahoo.com wrote:
>
> One of the possible custom solutons is to encrypt the
> other information with your public key, then use the
> private key to decrypt the other sensitive
> information.
Cool, are we going to use a private key to encrypt the password for the
private key of Tomcat? Cool, kinda gets recursive... :) WHAT?
Pier
Re: [PROPOSAL] Standalone SSL
Posted by Jim Seach <jw...@yahoo.com>.
--- Christopher Cain <cc...@mhsoftware.com> wrote:
>
> In short, it is currently a needless exposure, and
> certs are much more
> important than most other resources. If I paid good
> money for a real
> cert signed by a CA, I would especially have a
> comprehensive security
> scheme in place to protect it. Leaving the password
> sitting around would
> be about the last thing I would possibly do. If your
> box is compromised,
> then your cert store is also unquestionably
> compromised. If your store
> is compromised, than every cert and private key in
> that store is
> worthless. That could potentially be catastrophic in
> a business
> environment, and would leave you open to all kinds
> nasty things. If
> someone gets ahold of your cert, bad, bad, BAD
> things can happen. Just
> ask Microsoft =)
>
> And if you should be cracked, and someone
> masqaurades as you to do bad
> things, that is a lawsuit you will not win because
> you did not have take
> resonable precautions against it. I realize that
> this is all a bit of
> Chicken Little-ism, but my point is that SSL
> implementation is a serious
> business. And I can choose to lock down the rest of
> the stuff you
> mention with a custom solution. I have no such
> option with the SSL
> implemention (short of hacking the code, which we
> can't reasonably
> expect people to have to do).
>
One of the possible custom solutons is to encrypt the
other information with your public key, then use the
private key to decrypt the other sensitive
information. Since the info is signed with the public
key, any developer could encrypt information that
could only be retrieved by the system. That way, the
solution would scale.
Anyway, if you implement the "prompt for key on
reboot" it could always be a configurable option, so
if someone didn't feel that level of security was
necessary, they wouldn't have to use it.
Jim
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
Re: [PROPOSAL] Standalone SSL
Posted by Christopher Cain <cc...@mhsoftware.com>.
"Craig R. McClanahan" wrote:
>
> Christopher,
>
> I can sympathize with your concerns, and would always set up production
> systems running under a username no one has access to (so they cannot read
> server.xml etc. anyway).
Definitely. But if the box is compromised, you're screwed.
> My question is, though, where do you stop? Is the password to your
> certificates file really any more sensitive than the username/password for
> logging on to your database?
Depends on what you have in your database, but potentially ...
definitely. On the system I am currently setting up, definitely. I'm not
storing any truly sensitive data such as credit card info or social
security numbers or anything like that. I suppose some of it is mildy
sensitive, but nothing earth-shattering. In any case, I would personally
*never* store database passwords in the clear either, but that's just
me. To address the question in general, I would argue that with database
access, I at least have the option of locking it down (I store my JDBC
info myself). My hands are tied with the current cert design.
> Or the login information for the directory
> server containing your users and roles (assuming use of JNDIRealm)? Or
> all the other sensitive configuration information that needs to be passed
> on to web apps (or web containers) to make them work?
Don't know about the realm stuff, because I haven't played with it yet.
I can't think of any other truly sensitive external resource information
that is exposed. In my opinion, when dealing with security, always err
on the side of caution. I should not have to weaken my security design
just to run Tomcat. If I owned a business, this would definitely be a
deal-breaker for me. Allowing my admins to store the master cert
password in the clear would be out of the question. Sure, I could always
run Apache in from of Tomcat, but now you're talking a much larger
footprint, so there goes embedding + SSL.
For another example, we are about to begin development on a cluster
management tool which our customer can distribute with their cluster
hardware solutions. It needs to be web-based, and it needs to be secure
(for obvious reasons). There is no static content, so there is no need
to bundle Apache with it. Tomcat standalone will be a much smaller
footprint and MUCH easier for customers to install and configure (no
Apache connector to worry about, and only one program to configure and
administer). Now especially if the customer wants an official cert, or
if they already have one, I can't very well tell them that they have to
store the "master key" in plaintext.
> It's just not clear to me that a "prompt the user at startup
> time" approach is scalable to cover all the sensitive information you
> might wish to protect.
Again, I consider the site cert to be MUCH more sensitive than almost
anything else. The possible exception is the database, in which case if
you store the password in the clear on that, too, you're crazy. If I'm
storing credit card info in my database, and the password to that
database is sitting in a widely-known config file, I'm just begging for
trouble. In fact, the Visa merchant agreement for online sales is rather
strict. I know for a fact that you cannot store passwords to a resource
containing credit card numbers (i.e. a database) in the clear ANYWHERE.
That same agreement also mandates SSL for transmission of card data, and
I'm reasonably certain that exposing your cert like that is explicitly
prohibited (I'd have to check to be positive). This is relevant because
I *have* developed an e-commerce solution running on Tomcat (although in
that instance Apache was sitting in front). In other words, you are also
prohibiting the use of standalone TC for e-commerce.
In short, it is currently a needless exposure, and certs are much more
important than most other resources. If I paid good money for a real
cert signed by a CA, I would especially have a comprehensive security
scheme in place to protect it. Leaving the password sitting around would
be about the last thing I would possibly do. If your box is compromised,
then your cert store is also unquestionably compromised. If your store
is compromised, than every cert and private key in that store is
worthless. That could potentially be catastrophic in a business
environment, and would leave you open to all kinds nasty things. If
someone gets ahold of your cert, bad, bad, BAD things can happen. Just
ask Microsoft =)
And if you should be cracked, and someone masqaurades as you to do bad
things, that is a lawsuit you will not win because you did not have take
resonable precautions against it. I realize that this is all a bit of
Chicken Little-ism, but my point is that SSL implementation is a serious
business. And I can choose to lock down the rest of the stuff you
mention with a custom solution. I have no such option with the SSL
implemention (short of hacking the code, which we can't reasonably
expect people to have to do).
> Craig
>
> PS: I'll also work on why the attributes don't work for you -- they did
> for me when this was originally coded, and I cannot recall any changes
> that should have made them stop.
Thanks! =)
I'd be happy to have a look at it instead, if you have some more
pressing things to attend to. I realize that it's not exactly a
high-profile use case.
- Christopher
Re: [PROPOSAL] Standalone SSL
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Christopher,
I can sympathize with your concerns, and would always set up production
systems running under a username no one has access to (so they cannot read
server.xml etc. anyway).
My question is, though, where do you stop? Is the password to your
certificates file really any more sensitive than the username/password for
logging on to your database? Or the login information for the directory
server containing your users and roles (assuming use of JNDIRealm)? Or
all the other sensitive configuration information that needs to be passed
on to web apps (or web containers) to make them work?
It's just not clear to me that a "prompt the user at startup
time" approach is scalable to cover all the sensitive information you
might wish to protect.
Craig
PS: I'll also work on why the attributes don't work for you -- they did
for me when this was originally coded, and I cannot recall any changes
that should have made them stop.
On Tue, 31 Jul 2001, Christopher Cain wrote:
> First, just a quick follow-up on the previous thread. Using the keystore
> defaults for the TC4 SSL standalone config works as planned. Trying to
> override the keystoreFile and/or keystorePass defaults, unfortunately,
> does not work (different exceptions for each).
>
> It makes me extremely nervous to have a default password on my certs. Of
> course, it also gets me nothing to change it to a solid password and
> then type that into server.xml. How would you feel about changing the
> SSL process to be more like the Apache approach, where the user is
> prompted on the command line for the store/key password at startup? The
> one drawback is that the web server/container cannot restart without
> human intervention (although the only real-world scenerio I've ever
> encountered where it was really an issue is a clean automated
> shutdown/restart from UPS program, for example).
>
> IMHO, that is a VERY small penalty for not having to store your cert
> password in plaintext in server.xml. In fact, the current solution is
> completely unimplementable in a production system. I'm sure I don't have
> to tell you that one would have to be completely insane to store the
> password to their official cert/private key in the clear in a config
> file. Since I have an immediate need for this functionality, I am
> volunteering to do it. So the only question is, how does everyone feel
> about switching to the Apache approach? I assume that there is not a
> spec issue which would preclude this.
>
> To be fair, I should tell you that I am one of those crypto freaks, so
> please keep that in mind when I start ranting about having a solid
> crypto design =) The primary OSS project I am involved in is a java
> crypto library, so this issue is near and dear to my heart.
>
> Regards,
>
> Christopher
>
[PROPOSAL] Standalone SSL
Posted by Christopher Cain <cc...@mhsoftware.com>.
First, just a quick follow-up on the previous thread. Using the keystore
defaults for the TC4 SSL standalone config works as planned. Trying to
override the keystoreFile and/or keystorePass defaults, unfortunately,
does not work (different exceptions for each).
It makes me extremely nervous to have a default password on my certs. Of
course, it also gets me nothing to change it to a solid password and
then type that into server.xml. How would you feel about changing the
SSL process to be more like the Apache approach, where the user is
prompted on the command line for the store/key password at startup? The
one drawback is that the web server/container cannot restart without
human intervention (although the only real-world scenerio I've ever
encountered where it was really an issue is a clean automated
shutdown/restart from UPS program, for example).
IMHO, that is a VERY small penalty for not having to store your cert
password in plaintext in server.xml. In fact, the current solution is
completely unimplementable in a production system. I'm sure I don't have
to tell you that one would have to be completely insane to store the
password to their official cert/private key in the clear in a config
file. Since I have an immediate need for this functionality, I am
volunteering to do it. So the only question is, how does everyone feel
about switching to the Apache approach? I assume that there is not a
spec issue which would preclude this.
To be fair, I should tell you that I am one of those crypto freaks, so
please keep that in mind when I start ranting about having a solid
crypto design =) The primary OSS project I am involved in is a java
crypto library, so this issue is near and dear to my heart.
Regards,
Christopher
Re: FW: mod_webapp vs. multi-thread component.
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Tue, Jul 31, 2001 at 03:12:20AM +0100, Pier P. Fumagalli wrote:
> Any clue??? :)
Some. I'd recommend using Apache 2.0 for this case because httpd-2.0
is already using threads (and sets up the compiler flags accordingly).
I have a feeling that he is compiling Apache 1.3/mod_webapp/apr
without _REENTRANT defined at compile-time, so bad things will happen
on Solaris when you try to create a thread at run-time.
Also, remember that there are two versions of the Solaris threading
libraries (apr would use pthread and his ORB would use thread).
However, the man pages say that they *should* be compatible even in
the same process. They even have an example in the man pages...
> > I thought it might be that I hadn't put -lthread in the link line but that's
> > even nastier - Apache doesn't even manage to startup if I do that.
>
> Is it simply crashing or does it give some output?
This leads me to believe that _REENTRANT isn't defined correctly at
compile-time. -- justin
Re: TC4 + apache + warp - cookies = error
Posted by Remy Maucherat <re...@betaversion.org>.
Quoting Eryq <er...@zeegee.com>:
Nice report.
Can you file it in bugzilla ?
Thanks,
Remy
Re: TC4 + apache + warp - cookies = error
Posted by Eryq <er...@zeegee.com>.
"Pier P. Fumagalli" wrote:
> Ok... Gotcha... So, the session _IS_ correctly handled if going thru
> cookies, but if it's URLencoded, it's not...
>
> Will dig into that tomorrow first thing in the morning (bear with me, can
> you please post a bug in BugZilla so that we can keep track of what was
> found faulty and when it was fixed, I know, it's a big pain in the ass,
> but... :) :) :)
Not a problem. I classified the bug as UNCONFIRMED and voted
once for it. Hope that was the right thing to do.
Eryq
Re: TC4 + apache + warp - cookies = error
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Ok... Gotcha... So, the session _IS_ correctly handled if going thru
cookies, but if it's URLencoded, it's not...
Will dig into that tomorrow first thing in the morning (bear with me, can
you please post a bug in BugZilla so that we can keep track of what was
found faulty and when it was fixed, I know, it's a big pain in the ass,
but... :) :) :)
Should be an easy fix.... (unlikely bug #2933)
Eryq at eryq@zeegee.com wrote:
>
> Browser Access Cookies
> cookies via on in
> enabled apache Context RESULT:
> ------ ------ ------ ------
> no no no ok
> no no yes ok
> no yes no FAIL [1]
> no yes yes FAIL [2]
> yes no no ok
> yes no yes ok
> yes yes no FAIL [3]
> yes yes yes ok
>
> [1] 404 on the jsessionid=....
> [2] 404 on the jsessionid=....
> [3] Apache asks the browser for a cookie.
[3] happens because sessions are not get from the URL, so, Tomcat forces a
cookie request if cookies can be accepted by the browser...
Thanks _SO_MUCH_ for the invaluable input...
Pier
TC4 + apache + warp - cookies = error
Posted by Eryq <er...@zeegee.com>.
Now accessing TC4 through Apache. It mostly works
perfectly, but there's a show-stopper: cookies.
-----------------------------------------------
THE SETUP:
Apache: 1.3.20
Catalina: CVS this week (4.0b7++)
mod_webapp: CVS this week
warp.jar: from latest mod_webapp
-----------------------------------------------
THE PROBLEM:
I am trying to disable cookies for
all webapps under Catalina... or at least, for a given
Context. When I access the webapp through Catalina
directly, the right thing happens. But when I go
through Apache via Warp, Catalina does the wrong
thing. You can try this out with /examples/servlet/SessionExample.
In some cases, it fails to recognize and strip off the
trailing ";jsessionid=****", and so Catalina seems
to think the ";..." is part of the URI, raising
this:
HTTP Status 404 - /examples/servlet/SessionExample;jsessionid=9271664256C7E592889000D43292C845
The requested resource (/examples/servlet/SessionExample;jsessionid=9271664256C7E592889000D43292C845)
is not available.
In other cases, it seems to disregard the "cookies=false"
in server.xml, and it tries to give me a cookie.
BTW, my "server.xml" contains this:
<Context path="/examples" docBase="examples" debug="0"
cookies="false"
reloadable="true">
...
I don't quite know if this is correct, but it seemed
to do the right thing when Apache was not part of
the picture. Going through Warp, however, broke
this approach (see below).
-----------------------------------------------
WHY THIS IS A BIG PROBLEM:
This is for a US Government site, and by Federal order,
we are not to use cookies in our web apps at all.
This is to make access to our sites more anonymous,
but it can make life a little difficult.
-----------------------------------------------
TESTS THAT WE RAN:
Again, this is simply mounting /examples through Warp
and hitting /examples/servlet/SessionExample:
Here's a quick test matrix, varying whether:
1. Netscape did/didn't have cookies enabled
2. We accessed via Apache (as opposed to TC4 directly)
3. We set cookies true/false in the server.xml context.
The table (i'm hoping I've transcribed it correctly):
Browser Access Cookies
cookies via on in
enabled apache Context RESULT:
------ ------ ------ ------
no no no ok
no no yes ok
no yes no FAIL [1]
no yes yes FAIL [2]
yes no no ok
yes no yes ok
yes yes no FAIL [3]
yes yes yes ok
[1] 404 on the jsessionid=....
[2] 404 on the jsessionid=....
[3] Apache asks the browser for a cookie.
-----------------------------------------------
CONCLUSION:
The problem only appears when you access the webapp
via Apache, and attempt to NOT use cookies --
by turning them off in your browser, or
by disabling them in the context, or both.
Thanks in advance,
--
Eryq, http://www.zeegee.com/eryq
WANTED: Schrodinger's Cat. Dead and/or Alive.
RE: mod_webapp vs. multi-thread component.
Posted by Thom Park <tp...@borland.com>.
Hi Pier,
>Whoha... Looking for troubles, huh? :)
no - trouble usually comes looking for me :)
>> B.T.W. My 'provider' is an interface between apache and an IIOP (CORBA)
>> connector that allows apache to converse with tomcat (using an IIOP java
>> connector).
>One of these days you'll enlighten me of the difference... I'm wondering
why
>you're using IIOP...
it's not so much the access to tomcat - though IIOP does give me some nice
load-balancing/
location transparancy for free, it's more the case that if I can get this
working, I can
then call CORBA objects directly from apache without having to go via
tomcat.
I can also call C++ based CORBA objects as well as Java ones.
>Darn... Why would it be IOCTLing a device when creating a thread?
Confused the hell out of me as well - I was wondering if it was the device
driver
that implements threads that was signalling an invalid ioctl operation.
Perhaps when
a thread is started up on Solaris, it looks like just another device under
the covers.
Or perhaps you can associate some device with a thread at thread creation
time and it's
that that causes the ioctl error. Who knows - I'm not a solaris kernel
guru...
>Is it simply crashing or does it give some output?
The child processes that apache forks coredump with SEGVIO, nowhere near the
code that handles
mod webapp but during the startup of apache. It doesn't seem to like
libthread.so ;-)
> b) any suggestions on using multi-threading apps (in a single threaded
> fashion) within mod_Webapp or apache.
>I bet it would be the same if you created a module without APR and WEBAPP.
>IMVHO, the problem is somewhere else... :(
I agree - but there must be someway to get apache to 'like' threading...
> p.s. Note that this isn't a problem per se with the mod_webapp connector -
> more an issue with the use of threading
> within Apache - so can anyone advise where i should post this request if
not
> here?
>
>I'm forwarding to apr-dev, lots of bright people over there, please, since
>this is outside of the scope of APR, respond privately to me and/or Thom.
>Thank you very much...
...and thank you too for the 'tea and sympathy' ;-)
-T.
FW: mod_webapp vs. multi-thread component.
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Any clue??? :)
Pier
------ Forwarded Message
From: "Pier P. Fumagalli" <pi...@betaversion.org>
Organization: Apache Software Foundation
Reply-To: tomcat-dev@jakarta.apache.org
Date: Tue, 31 Jul 2001 01:52:31 +0100
To: <to...@jakarta.apache.org>
Subject: Re: mod_webapp vs. multi-thread component.
Thom Park at tpark@borland.com wrote:
>
> Pier et. al.
>
> I hope that someone more enlightened can assist me with this one as I'm
> totally flummoxed by this - this applies to Solaris threads being used within
> mod_webapp (but not directly)...
Whoha... Looking for troubles, huh? :)
> I have succesfully (yay!) built mod_webapp (and apr) using the native SUN C
> compiler on Solaris 2.8. I am now attempting to add my own provider to the mix
> and am hitting an odd problem that I need explained to me )or hit on the head
> with a stick - which ever is less painful ;-)
Uh... Any modification to the build process? I believe APR doesn't like the
native SUN-C compiler that much (ok, I work for Sun and I use GCC...
WHAT-EVERRRR! :)
> B.T.W. My 'provider' is an interface between apache and an IIOP (CORBA)
> connector that allows apache to converse with tomcat (using an IIOP java
> connector).
One of these days you'll enlighten me of the difference... I'm wondering why
you're using IIOP...
> (works champion on NT!).
Good :)
> Unfortunately I don't have a single-threaded version of the CORBA orb
> libraries - only multi-threaded are available. Note that from Apache's point
> of view this shouldn't be a problem as there only is one client per apache
> child - no callbacks are made between the client and server so the execution
> thread being used by apache should be the only one that invokes the (client)
> object reference.
>
> Unfortunately, due to the mechanism involved in binding to a corba object, the
> client lib spawns a bunch of thread so handle the looking up and resolving of
> the object reference. It is here that my problem occurs. The CORBA api call
> launches 5 or so threads a this point (mainly to service a try/retry object
> discovery role) and, for every call to thr_create() that's performed by the
> 'connect' code, I get the following message written to the apache log (things
> in <> paraphrased by me):
>
> [<apache timestamp>][notice] child pid <pidnum> exit signal Abort(6)
> thr_create: Inappropriate ioctl for device
> thr_create: Inappropriate ioctl for device
> thr_create: Inappropriate ioctl for device
> ...
Darn... Why would it be IOCTLing a device when creating a thread?
> I thought it might be that I hadn't put -lthread in the link line but that's
> even nastier - Apache doesn't even manage to startup if I do that.
Is it simply crashing or does it give some output?
> So - can anyone please! offer any advice on :
>
> a) what the above could mean
That's the weird part... Why is ioctl() called when a thread is created?
> b) any suggestions on using multi-threading apps (in a single threaded
> fashion) within mod_Webapp or apache.
I bet it would be the same if you created a module without APR and WEBAPP.
IMVHO, the problem is somewhere else... :(
Could this be something related to creating threads and using fork() at the
same time?
> p.s. Note that this isn't a problem per se with the mod_webapp connector -
> more an issue with the use of threading
> within Apache - so can anyone advise where i should post this request if not
> here?
I'm forwarding to apr-dev, lots of bright people over there, please, since
this is outside of the scope of APR, respond privately to me and/or Thom.
Thank you very much...
Pier
------ End of Forwarded Message
Re: mod_webapp vs. multi-thread component.
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Thom Park at tpark@borland.com wrote:
>
> Pier et. al.
>
> I hope that someone more enlightened can assist me with this one as I'm
> totally flummoxed by this - this applies to Solaris threads being used within
> mod_webapp (but not directly)...
Whoha... Looking for troubles, huh? :)
> I have succesfully (yay!) built mod_webapp (and apr) using the native SUN C
> compiler on Solaris 2.8. I am now attempting to add my own provider to the mix
> and am hitting an odd problem that I need explained to me )or hit on the head
> with a stick - which ever is less painful ;-)
Uh... Any modification to the build process? I believe APR doesn't like the
native SUN-C compiler that much (ok, I work for Sun and I use GCC...
WHAT-EVERRRR! :)
> B.T.W. My 'provider' is an interface between apache and an IIOP (CORBA)
> connector that allows apache to converse with tomcat (using an IIOP java
> connector).
One of these days you'll enlighten me of the difference... I'm wondering why
you're using IIOP...
> (works champion on NT!).
Good :)
> Unfortunately I don't have a single-threaded version of the CORBA orb
> libraries - only multi-threaded are available. Note that from Apache's point
> of view this shouldn't be a problem as there only is one client per apache
> child - no callbacks are made between the client and server so the execution
> thread being used by apache should be the only one that invokes the (client)
> object reference.
>
> Unfortunately, due to the mechanism involved in binding to a corba object, the
> client lib spawns a bunch of thread so handle the looking up and resolving of
> the object reference. It is here that my problem occurs. The CORBA api call
> launches 5 or so threads a this point (mainly to service a try/retry object
> discovery role) and, for every call to thr_create() that's performed by the
> 'connect' code, I get the following message written to the apache log (things
> in <> paraphrased by me):
>
> [<apache timestamp>][notice] child pid <pidnum> exit signal Abort(6)
> thr_create: Inappropriate ioctl for device
> thr_create: Inappropriate ioctl for device
> thr_create: Inappropriate ioctl for device
> ...
Darn... Why would it be IOCTLing a device when creating a thread?
> I thought it might be that I hadn't put -lthread in the link line but that's
> even nastier - Apache doesn't even manage to startup if I do that.
Is it simply crashing or does it give some output?
> So - can anyone please! offer any advice on :
>
> a) what the above could mean
That's the weird part... Why is ioctl() called when a thread is created?
> b) any suggestions on using multi-threading apps (in a single threaded
> fashion) within mod_Webapp or apache.
I bet it would be the same if you created a module without APR and WEBAPP.
IMVHO, the problem is somewhere else... :(
Could this be something related to creating threads and using fork() at the
same time?
> p.s. Note that this isn't a problem per se with the mod_webapp connector -
> more an issue with the use of threading
> within Apache - so can anyone advise where i should post this request if not
> here?
I'm forwarding to apr-dev, lots of bright people over there, please, since
this is outside of the scope of APR, respond privately to me and/or Thom.
Thank you very much...
Pier
mod_webapp vs. multi-thread component.
Posted by Thom Park <tp...@borland.com>.
Pier et. al.
I hope that someone more enlightened can assist me with this one as I'm
totally flummoxed
by this - this applies to Solaris threads being used within mod_webapp (but
not directly)...
I have succesfully (yay!) built mod_webapp (and apr) using the native SUN C
compiler on Solaris
2.8. I am now attempting to add my own provider to the mix and am hitting an
odd problem that I
need explained to me )or hit on the head with a stick - which ever is less
painful ;-)
B.T.W. My 'provider' is an interface between apache and an IIOP (CORBA)
connector that allows apache to converse with
tomcat (using an IIOP java connector). (works champion on NT!).
Unfortunately I don't have a single-threaded version of the CORBA orb
libraries - only multi-threaded
are available. Note that from Apache's point of view this shouldn't be a
problem as there only is one
client per apache child - no callbacks are made between the client and
server so the execution thread being used
by apache should be the only one that invokes the (client) object reference.
Unfortunately, due to the mechanism involved in binding to a corba object,
the client lib spawns a bunch
of thread so handle the looking up and resolving of the object reference. It
is here that my problem occurs.
The CORBA api call launches 5 or so threads a this point (mainly to service
a try/retry object discovery role)
and, for every call to thr_create() that's performed by the 'connect' code,
I get the following message written to the
apache log (things in <> paraphrased by me):
[<apache timestamp>][notice] child pid <pidnum> exit signal Abort(6)
thr_create: Inappropriate ioctl for device
thr_create: Inappropriate ioctl for device
thr_create: Inappropriate ioctl for device
...
I thought it might be that I hadn't put -lthread in the link line but that's
even nastier - Apache doesn't even
manage to startup if I do that.
So - can anyone please! offer any advice on :
a) what the above could mean
b) any suggestions on using multi-threading apps (in a single threaded
fashion) within mod_Webapp or apache.
Thanks,
Thom
p.s. Note that this isn't a problem per se with the mod_webapp connector -
more an issue with the use of threading
within Apache - so can anyone advise where i should post this request if not
here?
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Monday, July 30, 2001 5:03 PM
To: tomcat-dev@jakarta.apache.org
Subject: Re: Standalone SSL Problem (was: Re: [DOC] TC4 Status)
On Mon, 30 Jul 2001, Christopher Cain wrote:
> (Two different mails snipped and referenced below :-)
>
> "Craig R. McClanahan" wrote:
> >
> > Yes, that should be "conf/server/lib". Alternatively (and the way I run
> > it), you can put these three JAR files in $JAVA_HOME/jre/lib/ext.
>
> A few things here. First, it is unnecessary, then, to have the JSSE jars
> in the Tomcat hierarchy if they are installed extensions (/jre/lib/ext)?
>
That is correct. That's the way my setup works.
> Second, and just out of curiousity, the "server/lib" directory appears
> to have moved up to the $TCHOME rather than underneath the "conf"
> subdirectory. Was that a typo on your part, or does the container
> actually search that path (in which case one would now have to manually
> create it)?
>
Yes, the above is a typo -- it's really "$CATALINA_HOME/server/lib".
> > Just uncommenting the 8443 connector example in the standard
> > conf/server.xml works for me.
>
> But I still need to point it to my keystore, right? Basically, I
> uncommented the section and added "keystoreFile" and "keystorePass"
> attributes to the Connector tag. The second Http connector section now
> reads this:
>
> <Connector className="org.apache.catalina.connector.http.HttpConnector"
> port="8443" minProcessors="5" maxProcessors="75"
> enableLookups="true" acceptCount="10" debug="0"
> scheme="https" secure="true"
> keystoreFile="/usr/local/tomcat/conf/my.keystore"
> keystorePass="mypass">
> <Factory className="org.apache.catalina.net.SSLServerSocketFactory"
> clientAuth="false" protocol="TLS"/>
> </Connector>
>
> Again, all I changed was to add the two keystore attribs.
>
I didn't, because the defaults work for me:
keystoreFile - Default is ".keystore" in the user home directory
of the user that is running Tomcat.
keystorePass - "changeit" (as the docco in server.xml tells you to do
You can, of course, override these values as you have done, if you have
done something different.
> > You also have to set up your JSSE environment according to the
> > instructions immediately above this connector entry.
>
> I think so. I have JSSE 1.0.2, with the 3 jars in jre/lib/ext (and also
> in the system classpath, although not that Catalina cares, of course). I
> have the "com.sun.net.ssl..." provider in the security file (I assume
> the pecking order doesn't matter). My keystore was generated with:
>
> keytool -genkey -alias tomcat -keyalg RSA -keystore my.keystore
> -keypasswd thepassword -storepasswd thepassword
>
The shouldn't you set keystorePass to "thepassword" instead of "mypass"?
> Key and store passwords are the same. "my.keystore" is in the tomcat
> conf directory and world-readable.
>
> > What do your log files say?
>
> First of all, the silent failure bit I mentioned this morning was simply
> my own goofiness. No message was thrown on the command line, and there
> were no errors in the catalina_log... file, but I somehow missed the
> "catalina.out" file (my only defense is that it was 2:00am at the time
> :-) Below is the stack trace from that file.
>
> PATHETIC DISCLAIMER:
>
> I haven't tried to track it down yet, as I just now discovered this log
> file. Although nothing jumps out at me from viewing the calling stack,
> it may well be something braindead. I suppose this is technically a bit
> of dev-list abuse now, but I am still familiarizing myself with the 4.0
> codebase and am not yet up to speed on the container startup process. If
> nothing appears obvious from my setup and/or stack trace, feel free to
> call me a bum and tell me to track it down my own damn self. I simply
> couldn't resist an invitation such as "What do your log files say" =)
> (Although on the upshot, I can definitely promise you a "Standalone SSL
> Configuration and Troubleshooting" doc once this is all said and done.)
>
Looks like the kind of problem you will have if the classes are BOTH in
the system extensions directory AND in the Tomcat hierarchy. You really
don't want to do that.
> - Christopher
>
> P.S. TC4 takes about 2 minutes to start up on my P133 Redhat 7.1 box
> with 256M of RAM. Is that normal or excessive? I'll definitely track
> that one down myself, I just want to know if that is out of the ordinary
> and therefore something I should even check into. I know for a fact that
> "javac" compilations are almost surrealistically slow on that machine,
> so maybe it has something to do with that. *shrug*
>
The largest time consumer in the Tomcat code is creating multiple
SAXParserFactory instances in XmlMapper, which is apparently pretty
expensive. There's already an enhancement request logged to reuse the
first one you create instead, which we'll get to at some point.
Tomcat 4 on my system (800mHz, 512mb) starts up with just the standard
apps in less than 5 seconds. Of course, if you've got an app with
load-on-startup servlets that take a long time (such as Cocoon), then it's
not really Tomcat's fault anyway :-).
> Anyway, thanks a ton for the SSL assistance!
>
Craig
> ----------------------
>
> Starting service Tomcat-Standalone
> Apache Tomcat/4.0-b6
> initProxy: java.security.NoSuchAlgorithmException: Class
> com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
> not a SSLContext
> java.security.NoSuchAlgorithmException: Class
> com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
> not a SSLContext
> at com.sun.net.ssl.b.a([DashoPro-V1.2-120198])
> at com.sun.net.ssl.SSLContext.getInstance([DashoPro-V1.2-120198])
> at
>
org.apache.catalina.net.SSLServerSocketFactory.initProxy(SSLServerSocketFact
ory.java:385)
> at
>
org.apache.catalina.net.SSLServerSocketFactory.initialize(SSLServerSocketFac
tory.java:328)
> at
>
org.apache.catalina.net.SSLServerSocketFactory.createSocket(SSLServerSocketF
actory.java:281)
> at
>
org.apache.catalina.connector.http.HttpConnector.open(HttpConnector.java:905
)
> at
>
org.apache.catalina.connector.http.HttpConnector.start(HttpConnector.java:10
78)
> at
> org.apache.catalina.core.StandardService.start(StandardService.java:360)
> at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:458)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:737)
> at org.apache.catalina.startup.Catalina.execute(Catalina.java:657)
> at org.apache.catalina.startup.Catalina.process(Catalina.java:178)
> at java.lang.reflect.Method.invoke(Native Method)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202)
> Catalina.start: LifecycleException: HttpConnector[8443].open:
> java.io.IOException: java.security.NoSuchAlgorithmException: Class
> com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
> not a SSLContext
> LifecycleException: HttpConnector[8443].open: java.io.IOException:
> java.security.NoSuchAlgorithmException: Class
> com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
> not a SSLContext
> at
>
org.apache.catalina.connector.http.HttpConnector.start(HttpConnector.java:10
80)
> at
> org.apache.catalina.core.StandardService.start(StandardService.java:360)
> at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:458)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:737)
> at org.apache.catalina.startup.Catalina.execute(Catalina.java:657)
> at org.apache.catalina.startup.Catalina.process(Catalina.java:178)
> at java.lang.reflect.Method.invoke(Native Method)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202)
> ----- Root Cause -----
> java.io.IOException: java.security.NoSuchAlgorithmException: Class
> com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
> not a SSLContext
> at
>
org.apache.catalina.net.SSLServerSocketFactory.initProxy(SSLServerSocketFact
ory.java:409)
> at
>
org.apache.catalina.net.SSLServerSocketFactory.initialize(SSLServerSocketFac
tory.java:328)
> at
>
org.apache.catalina.net.SSLServerSocketFactory.createSocket(SSLServerSocketF
actory.java:281)
> at
>
org.apache.catalina.connector.http.HttpConnector.open(HttpConnector.java:905
)
> at
>
org.apache.catalina.connector.http.HttpConnector.start(HttpConnector.java:10
78)
> at
> org.apache.catalina.core.StandardService.start(StandardService.java:360)
> at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:458)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:737)
> at org.apache.catalina.startup.Catalina.execute(Catalina.java:657)
> at org.apache.catalina.startup.Catalina.process(Catalina.java:178)
> at java.lang.reflect.Method.invoke(Native Method)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202)
> Stopping service Tomcat-Standalone
>
Re: Standalone SSL Problem (was: Re: [DOC] TC4 Status)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 30 Jul 2001, Christopher Cain wrote:
> (Two different mails snipped and referenced below :-)
>
> "Craig R. McClanahan" wrote:
> >
> > Yes, that should be "conf/server/lib". Alternatively (and the way I run
> > it), you can put these three JAR files in $JAVA_HOME/jre/lib/ext.
>
> A few things here. First, it is unnecessary, then, to have the JSSE jars
> in the Tomcat hierarchy if they are installed extensions (/jre/lib/ext)?
>
That is correct. That's the way my setup works.
> Second, and just out of curiousity, the "server/lib" directory appears
> to have moved up to the $TCHOME rather than underneath the "conf"
> subdirectory. Was that a typo on your part, or does the container
> actually search that path (in which case one would now have to manually
> create it)?
>
Yes, the above is a typo -- it's really "$CATALINA_HOME/server/lib".
> > Just uncommenting the 8443 connector example in the standard
> > conf/server.xml works for me.
>
> But I still need to point it to my keystore, right? Basically, I
> uncommented the section and added "keystoreFile" and "keystorePass"
> attributes to the Connector tag. The second Http connector section now
> reads this:
>
> <Connector className="org.apache.catalina.connector.http.HttpConnector"
> port="8443" minProcessors="5" maxProcessors="75"
> enableLookups="true" acceptCount="10" debug="0"
> scheme="https" secure="true"
> keystoreFile="/usr/local/tomcat/conf/my.keystore"
> keystorePass="mypass">
> <Factory className="org.apache.catalina.net.SSLServerSocketFactory"
> clientAuth="false" protocol="TLS"/>
> </Connector>
>
> Again, all I changed was to add the two keystore attribs.
>
I didn't, because the defaults work for me:
keystoreFile - Default is ".keystore" in the user home directory
of the user that is running Tomcat.
keystorePass - "changeit" (as the docco in server.xml tells you to do
You can, of course, override these values as you have done, if you have
done something different.
> > You also have to set up your JSSE environment according to the
> > instructions immediately above this connector entry.
>
> I think so. I have JSSE 1.0.2, with the 3 jars in jre/lib/ext (and also
> in the system classpath, although not that Catalina cares, of course). I
> have the "com.sun.net.ssl..." provider in the security file (I assume
> the pecking order doesn't matter). My keystore was generated with:
>
> keytool -genkey -alias tomcat -keyalg RSA -keystore my.keystore
> -keypasswd thepassword -storepasswd thepassword
>
The shouldn't you set keystorePass to "thepassword" instead of "mypass"?
> Key and store passwords are the same. "my.keystore" is in the tomcat
> conf directory and world-readable.
>
> > What do your log files say?
>
> First of all, the silent failure bit I mentioned this morning was simply
> my own goofiness. No message was thrown on the command line, and there
> were no errors in the catalina_log... file, but I somehow missed the
> "catalina.out" file (my only defense is that it was 2:00am at the time
> :-) Below is the stack trace from that file.
>
> PATHETIC DISCLAIMER:
>
> I haven't tried to track it down yet, as I just now discovered this log
> file. Although nothing jumps out at me from viewing the calling stack,
> it may well be something braindead. I suppose this is technically a bit
> of dev-list abuse now, but I am still familiarizing myself with the 4.0
> codebase and am not yet up to speed on the container startup process. If
> nothing appears obvious from my setup and/or stack trace, feel free to
> call me a bum and tell me to track it down my own damn self. I simply
> couldn't resist an invitation such as "What do your log files say" =)
> (Although on the upshot, I can definitely promise you a "Standalone SSL
> Configuration and Troubleshooting" doc once this is all said and done.)
>
Looks like the kind of problem you will have if the classes are BOTH in
the system extensions directory AND in the Tomcat hierarchy. You really
don't want to do that.
> - Christopher
>
> P.S. TC4 takes about 2 minutes to start up on my P133 Redhat 7.1 box
> with 256M of RAM. Is that normal or excessive? I'll definitely track
> that one down myself, I just want to know if that is out of the ordinary
> and therefore something I should even check into. I know for a fact that
> "javac" compilations are almost surrealistically slow on that machine,
> so maybe it has something to do with that. *shrug*
>
The largest time consumer in the Tomcat code is creating multiple
SAXParserFactory instances in XmlMapper, which is apparently pretty
expensive. There's already an enhancement request logged to reuse the
first one you create instead, which we'll get to at some point.
Tomcat 4 on my system (800mHz, 512mb) starts up with just the standard
apps in less than 5 seconds. Of course, if you've got an app with
load-on-startup servlets that take a long time (such as Cocoon), then it's
not really Tomcat's fault anyway :-).
> Anyway, thanks a ton for the SSL assistance!
>
Craig
> ----------------------
>
> Starting service Tomcat-Standalone
> Apache Tomcat/4.0-b6
> initProxy: java.security.NoSuchAlgorithmException: Class
> com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
> not a SSLContext
> java.security.NoSuchAlgorithmException: Class
> com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
> not a SSLContext
> at com.sun.net.ssl.b.a([DashoPro-V1.2-120198])
> at com.sun.net.ssl.SSLContext.getInstance([DashoPro-V1.2-120198])
> at
> org.apache.catalina.net.SSLServerSocketFactory.initProxy(SSLServerSocketFactory.java:385)
> at
> org.apache.catalina.net.SSLServerSocketFactory.initialize(SSLServerSocketFactory.java:328)
> at
> org.apache.catalina.net.SSLServerSocketFactory.createSocket(SSLServerSocketFactory.java:281)
> at
> org.apache.catalina.connector.http.HttpConnector.open(HttpConnector.java:905)
> at
> org.apache.catalina.connector.http.HttpConnector.start(HttpConnector.java:1078)
> at
> org.apache.catalina.core.StandardService.start(StandardService.java:360)
> at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:458)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:737)
> at org.apache.catalina.startup.Catalina.execute(Catalina.java:657)
> at org.apache.catalina.startup.Catalina.process(Catalina.java:178)
> at java.lang.reflect.Method.invoke(Native Method)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202)
> Catalina.start: LifecycleException: HttpConnector[8443].open:
> java.io.IOException: java.security.NoSuchAlgorithmException: Class
> com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
> not a SSLContext
> LifecycleException: HttpConnector[8443].open: java.io.IOException:
> java.security.NoSuchAlgorithmException: Class
> com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
> not a SSLContext
> at
> org.apache.catalina.connector.http.HttpConnector.start(HttpConnector.java:1080)
> at
> org.apache.catalina.core.StandardService.start(StandardService.java:360)
> at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:458)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:737)
> at org.apache.catalina.startup.Catalina.execute(Catalina.java:657)
> at org.apache.catalina.startup.Catalina.process(Catalina.java:178)
> at java.lang.reflect.Method.invoke(Native Method)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202)
> ----- Root Cause -----
> java.io.IOException: java.security.NoSuchAlgorithmException: Class
> com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
> not a SSLContext
> at
> org.apache.catalina.net.SSLServerSocketFactory.initProxy(SSLServerSocketFactory.java:409)
> at
> org.apache.catalina.net.SSLServerSocketFactory.initialize(SSLServerSocketFactory.java:328)
> at
> org.apache.catalina.net.SSLServerSocketFactory.createSocket(SSLServerSocketFactory.java:281)
> at
> org.apache.catalina.connector.http.HttpConnector.open(HttpConnector.java:905)
> at
> org.apache.catalina.connector.http.HttpConnector.start(HttpConnector.java:1078)
> at
> org.apache.catalina.core.StandardService.start(StandardService.java:360)
> at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:458)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:737)
> at org.apache.catalina.startup.Catalina.execute(Catalina.java:657)
> at org.apache.catalina.startup.Catalina.process(Catalina.java:178)
> at java.lang.reflect.Method.invoke(Native Method)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202)
> Stopping service Tomcat-Standalone
>
Standalone SSL Problem (was: Re: [DOC] TC4 Status)
Posted by Christopher Cain <cc...@mhsoftware.com>.
(Two different mails snipped and referenced below :-)
"Craig R. McClanahan" wrote:
>
> Yes, that should be "conf/server/lib". Alternatively (and the way I run
> it), you can put these three JAR files in $JAVA_HOME/jre/lib/ext.
A few things here. First, it is unnecessary, then, to have the JSSE jars
in the Tomcat hierarchy if they are installed extensions (/jre/lib/ext)?
Second, and just out of curiousity, the "server/lib" directory appears
to have moved up to the $TCHOME rather than underneath the "conf"
subdirectory. Was that a typo on your part, or does the container
actually search that path (in which case one would now have to manually
create it)?
> Just uncommenting the 8443 connector example in the standard
> conf/server.xml works for me.
But I still need to point it to my keystore, right? Basically, I
uncommented the section and added "keystoreFile" and "keystorePass"
attributes to the Connector tag. The second Http connector section now
reads this:
<Connector className="org.apache.catalina.connector.http.HttpConnector"
port="8443" minProcessors="5" maxProcessors="75"
enableLookups="true" acceptCount="10" debug="0"
scheme="https" secure="true"
keystoreFile="/usr/local/tomcat/conf/my.keystore"
keystorePass="mypass">
<Factory className="org.apache.catalina.net.SSLServerSocketFactory"
clientAuth="false" protocol="TLS"/>
</Connector>
Again, all I changed was to add the two keystore attribs.
> You also have to set up your JSSE environment according to the
> instructions immediately above this connector entry.
I think so. I have JSSE 1.0.2, with the 3 jars in jre/lib/ext (and also
in the system classpath, although not that Catalina cares, of course). I
have the "com.sun.net.ssl..." provider in the security file (I assume
the pecking order doesn't matter). My keystore was generated with:
keytool -genkey -alias tomcat -keyalg RSA -keystore my.keystore
-keypasswd thepassword -storepasswd thepassword
Key and store passwords are the same. "my.keystore" is in the tomcat
conf directory and world-readable.
> What do your log files say?
First of all, the silent failure bit I mentioned this morning was simply
my own goofiness. No message was thrown on the command line, and there
were no errors in the catalina_log... file, but I somehow missed the
"catalina.out" file (my only defense is that it was 2:00am at the time
:-) Below is the stack trace from that file.
PATHETIC DISCLAIMER:
I haven't tried to track it down yet, as I just now discovered this log
file. Although nothing jumps out at me from viewing the calling stack,
it may well be something braindead. I suppose this is technically a bit
of dev-list abuse now, but I am still familiarizing myself with the 4.0
codebase and am not yet up to speed on the container startup process. If
nothing appears obvious from my setup and/or stack trace, feel free to
call me a bum and tell me to track it down my own damn self. I simply
couldn't resist an invitation such as "What do your log files say" =)
(Although on the upshot, I can definitely promise you a "Standalone SSL
Configuration and Troubleshooting" doc once this is all said and done.)
- Christopher
P.S. TC4 takes about 2 minutes to start up on my P133 Redhat 7.1 box
with 256M of RAM. Is that normal or excessive? I'll definitely track
that one down myself, I just want to know if that is out of the ordinary
and therefore something I should even check into. I know for a fact that
"javac" compilations are almost surrealistically slow on that machine,
so maybe it has something to do with that. *shrug*
Anyway, thanks a ton for the SSL assistance!
----------------------
Starting service Tomcat-Standalone
Apache Tomcat/4.0-b6
initProxy: java.security.NoSuchAlgorithmException: Class
com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
not a SSLContext
java.security.NoSuchAlgorithmException: Class
com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
not a SSLContext
at com.sun.net.ssl.b.a([DashoPro-V1.2-120198])
at com.sun.net.ssl.SSLContext.getInstance([DashoPro-V1.2-120198])
at
org.apache.catalina.net.SSLServerSocketFactory.initProxy(SSLServerSocketFactory.java:385)
at
org.apache.catalina.net.SSLServerSocketFactory.initialize(SSLServerSocketFactory.java:328)
at
org.apache.catalina.net.SSLServerSocketFactory.createSocket(SSLServerSocketFactory.java:281)
at
org.apache.catalina.connector.http.HttpConnector.open(HttpConnector.java:905)
at
org.apache.catalina.connector.http.HttpConnector.start(HttpConnector.java:1078)
at
org.apache.catalina.core.StandardService.start(StandardService.java:360)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:458)
at org.apache.catalina.startup.Catalina.start(Catalina.java:737)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:657)
at org.apache.catalina.startup.Catalina.process(Catalina.java:178)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202)
Catalina.start: LifecycleException: HttpConnector[8443].open:
java.io.IOException: java.security.NoSuchAlgorithmException: Class
com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
not a SSLContext
LifecycleException: HttpConnector[8443].open: java.io.IOException:
java.security.NoSuchAlgorithmException: Class
com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
not a SSLContext
at
org.apache.catalina.connector.http.HttpConnector.start(HttpConnector.java:1080)
at
org.apache.catalina.core.StandardService.start(StandardService.java:360)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:458)
at org.apache.catalina.startup.Catalina.start(Catalina.java:737)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:657)
at org.apache.catalina.startup.Catalina.process(Catalina.java:178)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202)
----- Root Cause -----
java.io.IOException: java.security.NoSuchAlgorithmException: Class
com.sun.net.ssl.internal.ssl.SSLContextImpl configured for SSLContext
not a SSLContext
at
org.apache.catalina.net.SSLServerSocketFactory.initProxy(SSLServerSocketFactory.java:409)
at
org.apache.catalina.net.SSLServerSocketFactory.initialize(SSLServerSocketFactory.java:328)
at
org.apache.catalina.net.SSLServerSocketFactory.createSocket(SSLServerSocketFactory.java:281)
at
org.apache.catalina.connector.http.HttpConnector.open(HttpConnector.java:905)
at
org.apache.catalina.connector.http.HttpConnector.start(HttpConnector.java:1078)
at
org.apache.catalina.core.StandardService.start(StandardService.java:360)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:458)
at org.apache.catalina.startup.Catalina.start(Catalina.java:737)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:657)
at org.apache.catalina.startup.Catalina.process(Catalina.java:178)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202)
Stopping service Tomcat-Standalone
Re: [DOC] TC4 Status
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 30 Jul 2001, Christopher Cain wrote:
>
> Christopher Cain wrote:
> >
> > [snip]
> >
> > P.S. Quick question: The 3 JSSE libraries need to live in
> > $TCHOME/server/lib, yes?
>
> Okay, I guess as long as I'm asking, can someone please post the exact
> syntax for the second (SSL) Connector in server.xml (keystoreName &
> keystorePass are attributes of the Connector?, etc.) for TC4, and also
> any thoughts off the top of your head as to what would cause the
> connector to simply (and silently) not bind.
>
Just uncommenting the 8443 connector example in the standard
conf/server.xml works for me. You also have to set up your JSSE
environment according to the instructions immediately above this connector
entry.
What do your log files say?
> TIA
>
> - Christopher
>
Craig
Re: [DOC] TC4 Status
Posted by Christopher Cain <cc...@mhsoftware.com>.
Christopher Cain wrote:
>
> [snip]
>
> P.S. Quick question: The 3 JSSE libraries need to live in
> $TCHOME/server/lib, yes?
Okay, I guess as long as I'm asking, can someone please post the exact
syntax for the second (SSL) Connector in server.xml (keystoreName &
keystorePass are attributes of the Connector?, etc.) for TC4, and also
any thoughts off the top of your head as to what would cause the
connector to simply (and silently) not bind.
TIA
- Christopher
Re: [DOC] TC4 Status
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 30 Jul 2001, Christopher Cain wrote:
>
> "Craig R. McClanahan" wrote:
> >
> > > What's the top priority for the "Administrators" section?
> >
> > IMHO, documenting the various settings in server.xml is critical.
>
> +1000
>
> I spent several hours last night attempting to get SSL working on TC4m6
> standalone, with no success. I did everything the "Configuring Catalina"
> doc said to do, as well as what was listed in the server.xml comments.
> Since there is no error at startup and it's like the second Connector
> directive is just skipped, I started poking around for a
> definitive/exhautive doc on server.xml to a) verify the Connector tag
> syntax (the current "Config Cat." doc is a little out of date), and b)
> check for any other tag that might need to be set. A comprehensive doc
> on server.xml would have hit the spot. I'll even help, to the limited
> extent that I am able (since I'm not even smart enough to even get SSL
> working ... D'oh!)
>
That's why the goal-oriented stuff is important as well as the reference
stuff. Of course, as you point out, out-of-date docs can almost be worse
than none at all! :-)
> - Christopher
>
> P.S. Quick question: The 3 JSSE libraries need to live in
> $TCHOME/server/lib, yes? (They are already set okay externally.) The
> Catalina doc says "conf/server", but I assume that's just an artifact
> from a previous dir structure.
>
Yes, that should be "conf/server/lib". Alternatively (and the way I run
it), you can put these three JAR files in $JAVA_HOME/jre/lib/ext.
Craig McClanahan
Re: [DOC] TC4 Status
Posted by Christopher Cain <cc...@mhsoftware.com>.
"Craig R. McClanahan" wrote:
>
> > What's the top priority for the "Administrators" section?
>
> IMHO, documenting the various settings in server.xml is critical.
+1000
I spent several hours last night attempting to get SSL working on TC4m6
standalone, with no success. I did everything the "Configuring Catalina"
doc said to do, as well as what was listed in the server.xml comments.
Since there is no error at startup and it's like the second Connector
directive is just skipped, I started poking around for a
definitive/exhautive doc on server.xml to a) verify the Connector tag
syntax (the current "Config Cat." doc is a little out of date), and b)
check for any other tag that might need to be set. A comprehensive doc
on server.xml would have hit the spot. I'll even help, to the limited
extent that I am able (since I'm not even smart enough to even get SSL
working ... D'oh!)
- Christopher
P.S. Quick question: The 3 JSSE libraries need to live in
$TCHOME/server/lib, yes? (They are already set okay externally.) The
Catalina doc says "conf/server", but I assume that's just an artifact
from a previous dir structure.
RE: [DOC] TC4 Status
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 30 Jul 2001, Rob S. wrote:
> > It's not formally resolved, but it's time for us to just "do
> > something" instead of just talk about it.
>
> Agreed. Keeping things HT/XML with an agreed-upon set of tags sounds good
> to me. I'll do that, keeping in mind the example docs (e.g. index.xml).
> Soon tho', we'll have to decide on a more extended set of tags to do things
> like tables and whatnot...
>
I don't contemplate a change in the current <document> / <body> /
<section> / <subsection> hierarchy, so you can start there. Arbitrary
HTML can be nested inside, as long as all the tags balance in an XHTML
style (i.e. <p> ... </p>, use <br/> to create a <br>, and so on).
Adding specific styling tags for kinds of tables should probably wait
until we choose the final technology. Interestingly, the same discussion
is going on over at xml.apache.org about how they generate their web site,
so maybe we'll be able to leverage the results of their thoughts (and they
probably know a *lot* more about XML than we do :-).
> > You can see the fruits of my labors in the "tomcat-docs" web app. This
> > can be generated (if you've got the source distribution) by typing "ant
> > tomcat-docs" at the top level. I'm also going to upload a snapshot of the
> > output to the Tomcat web site for easy perusal.
>
> It's going to have to wait until tonite after I can finish setting up my
> local machine. I only checked out /jt4 last nite and apparently need a few
> more things before that task will complete successfully =)
>
Yep ... you'll be able to test out my new "BUILDING.txt" instructions :-).
The snapshot of the generated docs is also online at:
http://jakarta.apache.org/tomcat/tomcat-4.0-doc-exp/index.html
> > If you've got some text, I'd like to try integrating it into the
> > "tomcat-docs" experiment. The Anakia stylesheet that was written for
>
> Just the "running multiple" one, that I'll convert to the format if someone
> gives it the ok and touches it up a little bit =)
>
> > You'll also note that I punted on the Getting Started and just linked in
> > the text files from the top-level directory of the distribution. I'm fine
>
> I had some thoughts about an introduction (see below).
>
> > really needs to be done in at least two flavors -- reference material on
> > all the possible options (pretty much done in HTML, needs to be
> > converted), and a more "user's guide" approach to "if you want to do
> > this, here's how you do it."
> >
> > The current docs try to mix these styles a little, and I'm not so sure it
> > is very effective.
>
> Agreed. If the reference stuff is pretty much done, I don't mind helping on
> the conversion once we decide on a structure. As well, that leaves the
> goal-oriented approach to be done, so we'll need a list of goals to start
> catering to. I think having the docs organized (at least partially) by
> goal, would prove a much more rewarding experience for users. This is
> contrary to the, "teach them everything and have them figure it out
> themselves" approach. Apache was so frustrating that way. I kept having to
> search the newsgroups to find out how to do seemingly common and simple
> things =/
>
> > It's on my list to look at, honest! As a general organizational note, are
> > you thinking of having a section of the Administrator's Guide for "one
> > pager" topics like this? Or are you thinking these are more chapters or
> > sections in something that feels like one overall document?
>
> No worries, you've got code + organizational bits to do and I think the code
> is more important anyways. I just wanted to make sure it didn't slip
> through =)
>
> I'm not sure about how to break up the sections into individual files or
> documents yet. I thought for now, we'd keep things one-file-per-major-topic
> and as we agreed on what goes where, deal with moving things around?
>
That sounds like a good approach. Once in a while, we'll run into
multi-page major topics, but that is probably fairly rare.
> There still needs to be some sort of introduction to the container. Rather
> than clutter up the docs with background information at every step, I think
> we should try to centralize this, a prerequisite of some sort, to continuing
> on with the documentation. Not too long as to make people skip it, but
> enough so that we don't have to explain what a Context is every time we use
> the word. I think the "Getting Started" section should be the place for
> this, and if I knew how to use any other gfx tool than Visio, I would make a
> pretty picture explaining the different routes through the docs. Maybe I
> can get my gf to do it for me ;)
>
> - r
>
>
Craig
RE: [DOC] TC4 Status
Posted by "Rob S." <rs...@home.com>.
The generated docs are super green! Just like the others - very schwank. I
can certainly say that I'm sick of Times New Roman, but that's another email
I guess ;)
Since it took me all night just to get it to build (this laptop is hurting
<grumble>), tomorrow I'll start working on a "Welcome to Tomcat" guide that
will explain some of the basics that admins and app developers will be able
to use. Since I work with Tomcat newbies, I'll have ample feedback =) I
just kind of feel like something is missing between "here's how to install
and run it" and "here's how to configure it"...
Anyway, the build works for me, but man it took forever to get setup!
- r
> -----Original Message-----
> From: Rob S. [mailto:rslifka@home.com]
> Sent: Monday, July 30, 2001 7:36 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: RE: [DOC] TC4 Status
>
>
> > It's not formally resolved, but it's time for us to just "do
> > something" instead of just talk about it.
>
> Agreed. Keeping things HT/XML with an agreed-upon set of tags sounds good
> to me. I'll do that, keeping in mind the example docs (e.g. index.xml).
> Soon tho', we'll have to decide on a more extended set of tags to
> do things
> like tables and whatnot...
>
> > You can see the fruits of my labors in the "tomcat-docs" web app. This
> > can be generated (if you've got the source distribution) by typing "ant
> > tomcat-docs" at the top level. I'm also going to upload a
> snapshot of the
> > output to the Tomcat web site for easy perusal.
>
> It's going to have to wait until tonite after I can finish setting up my
> local machine. I only checked out /jt4 last nite and apparently
> need a few
> more things before that task will complete successfully =)
>
> > If you've got some text, I'd like to try integrating it into the
> > "tomcat-docs" experiment. The Anakia stylesheet that was written for
>
> Just the "running multiple" one, that I'll convert to the format
> if someone
> gives it the ok and touches it up a little bit =)
>
> > You'll also note that I punted on the Getting Started and just linked in
> > the text files from the top-level directory of the
> distribution. I'm fine
>
> I had some thoughts about an introduction (see below).
>
> > really needs to be done in at least two flavors -- reference material on
> > all the possible options (pretty much done in HTML, needs to be
> > converted), and a more "user's guide" approach to "if you want to do
> > this, here's how you do it."
> >
> > The current docs try to mix these styles a little, and I'm not
> so sure it
> > is very effective.
>
> Agreed. If the reference stuff is pretty much done, I don't mind
> helping on
> the conversion once we decide on a structure. As well, that leaves the
> goal-oriented approach to be done, so we'll need a list of goals to start
> catering to. I think having the docs organized (at least partially) by
> goal, would prove a much more rewarding experience for users. This is
> contrary to the, "teach them everything and have them figure it out
> themselves" approach. Apache was so frustrating that way. I
> kept having to
> search the newsgroups to find out how to do seemingly common and simple
> things =/
>
> > It's on my list to look at, honest! As a general
> organizational note, are
> > you thinking of having a section of the Administrator's Guide for "one
> > pager" topics like this? Or are you thinking these are more chapters or
> > sections in something that feels like one overall document?
>
> No worries, you've got code + organizational bits to do and I
> think the code
> is more important anyways. I just wanted to make sure it didn't slip
> through =)
>
> I'm not sure about how to break up the sections into individual files or
> documents yet. I thought for now, we'd keep things
> one-file-per-major-topic
> and as we agreed on what goes where, deal with moving things around?
>
> There still needs to be some sort of introduction to the
> container. Rather
> than clutter up the docs with background information at every
> step, I think
> we should try to centralize this, a prerequisite of some sort, to
> continuing
> on with the documentation. Not too long as to make people skip it, but
> enough so that we don't have to explain what a Context is every
> time we use
> the word. I think the "Getting Started" section should be the place for
> this, and if I knew how to use any other gfx tool than Visio, I
> would make a
> pretty picture explaining the different routes through the docs. Maybe I
> can get my gf to do it for me ;)
>
> - r
>
>
RE: [DOC] TC4 Status
Posted by "Rob S." <rs...@home.com>.
> It's not formally resolved, but it's time for us to just "do
> something" instead of just talk about it.
Agreed. Keeping things HT/XML with an agreed-upon set of tags sounds good
to me. I'll do that, keeping in mind the example docs (e.g. index.xml).
Soon tho', we'll have to decide on a more extended set of tags to do things
like tables and whatnot...
> You can see the fruits of my labors in the "tomcat-docs" web app. This
> can be generated (if you've got the source distribution) by typing "ant
> tomcat-docs" at the top level. I'm also going to upload a snapshot of the
> output to the Tomcat web site for easy perusal.
It's going to have to wait until tonite after I can finish setting up my
local machine. I only checked out /jt4 last nite and apparently need a few
more things before that task will complete successfully =)
> If you've got some text, I'd like to try integrating it into the
> "tomcat-docs" experiment. The Anakia stylesheet that was written for
Just the "running multiple" one, that I'll convert to the format if someone
gives it the ok and touches it up a little bit =)
> You'll also note that I punted on the Getting Started and just linked in
> the text files from the top-level directory of the distribution. I'm fine
I had some thoughts about an introduction (see below).
> really needs to be done in at least two flavors -- reference material on
> all the possible options (pretty much done in HTML, needs to be
> converted), and a more "user's guide" approach to "if you want to do
> this, here's how you do it."
>
> The current docs try to mix these styles a little, and I'm not so sure it
> is very effective.
Agreed. If the reference stuff is pretty much done, I don't mind helping on
the conversion once we decide on a structure. As well, that leaves the
goal-oriented approach to be done, so we'll need a list of goals to start
catering to. I think having the docs organized (at least partially) by
goal, would prove a much more rewarding experience for users. This is
contrary to the, "teach them everything and have them figure it out
themselves" approach. Apache was so frustrating that way. I kept having to
search the newsgroups to find out how to do seemingly common and simple
things =/
> It's on my list to look at, honest! As a general organizational note, are
> you thinking of having a section of the Administrator's Guide for "one
> pager" topics like this? Or are you thinking these are more chapters or
> sections in something that feels like one overall document?
No worries, you've got code + organizational bits to do and I think the code
is more important anyways. I just wanted to make sure it didn't slip
through =)
I'm not sure about how to break up the sections into individual files or
documents yet. I thought for now, we'd keep things one-file-per-major-topic
and as we agreed on what goes where, deal with moving things around?
There still needs to be some sort of introduction to the container. Rather
than clutter up the docs with background information at every step, I think
we should try to centralize this, a prerequisite of some sort, to continuing
on with the documentation. Not too long as to make people skip it, but
enough so that we don't have to explain what a Context is every time we use
the word. I think the "Getting Started" section should be the place for
this, and if I knew how to use any other gfx tool than Visio, I would make a
pretty picture explaining the different routes through the docs. Maybe I
can get my gf to do it for me ;)
- r
Re: [DOC] TC4 Status
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 29 Jul 2001, Rob S. wrote:
> Was there ever any resolution to the docs discussion on -general? I wish I
> could contribute to a doc gen or format tool conversation, but I'm far from
> an expert in that field. Standing up and waving my arms about the whole
> topic probably isn't going to do much either, so I'll talk about something
> else for now =)
>
It's not formally resolved, but it's time for us to just "do
something" instead of just talk about it.
> Right now, the current structure of the docs (index.xml) looks like this:
>
> - Introduction
> - Getting Started
> - Administrators
> - App Developers
> - Tomcat Developers
>
> The "Introduction" and "Getting Started" sections are pretty much done -
> there are documents on building, installing, and running Tomcat in there
> now. Craig is working on porting the "App Developers" guide this weekend.
>
You can see the fruits of my labors in the "tomcat-docs" web app. This
can be generated (if you've got the source distribution) by typing "ant
tomcat-docs" at the top level. I'm also going to upload a snapshot of the
output to the Tomcat web site for easy perusal.
If you've got some text, I'd like to try integrating it into the
"tomcat-docs" experiment. The Anakia stylesheet that was written for
jakarta-site2 (and therefore the XSLT version that I checked in, because I
tried to be as similar as possible) has some real quirks when you try to
use it for different projects -- but the document content itself should be
able to be pretty independent of that.
You'll also note that I punted on the Getting Started and just linked in
the text files from the top-level directory of the distribution. I'm fine
with doing whatever's appropriate, but we do need *something* in text-only
format there, and we should minimize duplication that will require things
to be updated more than once later.
> What's the top priority for the "Administrators" section?
IMHO, documenting the various settings in server.xml is critical. It
really needs to be done in at least two flavors -- reference material on
all the possible options (pretty much done in HTML, needs to be
converted), and a more "user's guide" approach to "if you want to do
this, here's how you do it."
The current docs try to mix these styles a little, and I'm not so sure it
is very effective.
> Did anyone take a
> look at the "Running Multiple Instances" thing? Was that like, too
> worthless to even comment on? =)
>
It's on my list to look at, honest! As a general organizational note, are
you thinking of having a section of the Administrator's Guide for "one
pager" topics like this? Or are you thinking these are more chapters or
sections in something that feels like one overall document?
> - r
>
>
Craig