Pier P. Fumagalli wrote:
Craig R. McClanahan at [EMAIL PROTECTED] wrote:
+1 for the second approach. If the logic of your service allows for
restarting without forcing an unload/reload of the entire JVM, the APIs
should accomodate that.
Again, it would not mean restart, but merely
Hi,
we are using TC 3.2.2 (upgrade to 3.2.3 soon to follow) in
a production environment with medium traffic and standalone
mode. The configuration in server.xml is identical to the
distribution, except for the modified port number and an
Parameter name=max_threads value=500/
in the
Hi,
I have a serious problem, sometimes my JSPs stop getting rendered while static pages
are working fine. I am using Apache 1.3.20 with Tomcat 3.2.2 on Linux Kernel 2.4.2-2
for a production server. When I encountered the problem for the first time I thought
that it was the java heap problem
2001-07-31 07:46:21 - Ctx( /WebConfigure ): JasperException: [snip]
/tmp date
Tue Jul 31 19:49:52 EDT 2001
Shouldn't the logs be in 24hr?
...and yes, the time is horribly out of sync on that machine =)
- r
From memory java.util.Calendar does a terrible job of paying attention to
the underlying o/s settings. I live in Sydney, and courtesy of the
Olympics last year we started daylight savings ridiculously early -
changed all the o/s timezones, but the Calendar class refused to pick it
up, so we had
Can someone point me to some documentation on how Tomcat is organized, what
all the information in logs is about, where it comes from, etc... etc...
This shouldn't be this difficult to get started. Thanks in advance.
Rather than slap you on the wrist for emailing the dev list, and send you on
your way with the information you've requested, I will point you to the
tomcat-users list, where a question like yours is better posed.
Actually, tell you what. Since we're in the process of rewriting the
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
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
Christopher Cain at [EMAIL PROTECTED] 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
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
Hi Pier,
unfortunately my binary won't load unless you install Visibroker (that old
black magic called iiop)
sorry.
You also would need to have build apache with SUN C instead of gcc to have a
hope
of using one of my binaries.
I'll try to clean up my machine and see if I can build a vanilla
Thom Park at [EMAIL PROTECTED] wrote:
Hi Pier,
unfortunately my binary won't load unless you install Visibroker (that old
black magic called iiop)
sorry.
You also would need to have build apache with SUN C instead of gcc to have a
hope of using one of my binaries.
I'll try to
--- Christopher Cain [EMAIL PROTECTED] 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.
Jim Seach at [EMAIL PROTECTED] 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
Jim Seach wrote:
--- Christopher Cain [EMAIL PROTECTED] 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
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
--- Pier P. Fumagalli [EMAIL PROTECTED] wrote:
Jim Seach at [EMAIL PROTECTED] 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
When Pier told me that he'd never seen libhttpd.ep in his
own Apache directory, that gave me the first clue: my
Apache was somehow different from other Solaris builds.
Here's why.
Pursuant to this document: http://httpd.apache.org/docs/dso.html
I did this:
./configure
--- Christopher Cain [EMAIL PROTECTED] 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
YEAH! I know there was something wrong with your Apache installation...
Now, we shouldn't have problems also with SHARED_CORE, but now at least I
know what to tackle...
Can you do me another favor and confirm (or not) bug # 2933?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2933
Thanks :)
Hello!
My tuppence worth on one comment here:
1. Always use gcc. Always use gcc. Always use gcc.
Why? Because it's the lowest common denominator.
Because the developers are building/testing with it.
Because ./configure likes it. Always use gcc.
Only do this if your absolutely
Jim Seach wrote:
--- Christopher Cain [EMAIL PROTECTED] 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
Thom Park at [EMAIL PROTECTED] wrote:
Hello!
My tuppence worth on one comment here:
1. Always use gcc. Always use gcc. Always use gcc.
Why? Because it's the lowest common denominator.
Because the developers are building/testing with it.
Because ./configure likes it. Always use
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
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:
Quoting Eryq [EMAIL PROTECTED]:
Nice report.
Can you file it in bugzilla ?
Thanks,
Remy
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,
--- Christopher Cain [EMAIL PROTECTED] 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,
Hi,
I didn't get a response from the last mail I sent on this subject, but I
hope I could borrow a few minutes of your time to at least point me in the
direction of the relevant documentation on virtual hosts in tomcat...
I am using
Apache 1.3.20 and Tomcat 3.3 on Linux 2.4.5
We use a
These are in the XML format that Craig's adopted, using the specified subset
of tags. I've also attached the rendered versions to this email w/a
modified extension (to get past the HTML filters) so I can hopefully get
some feedback! ;) They're both in ok shape, enough is there for some
Quoting Jim Seach [EMAIL PROTECTED]:
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
32 matches
Mail list logo
