You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Roberto B." <ro...@ipermedianet.com> on 2001/08/17 17:36:37 UTC
Tomcat before Apache
I use Linux/Debian as root, Apache 1.3 and Tomcat 4 b6
I want to start automatically Tomcat before Apache.
I made this things :
1) I created this script named "tomcat":
#! /bin/sh
TOMCAT_HOME=/usr/tomcat4b6
# Test tomcat.sh
if [ ! -x $TOMCAT_HOME/bin/tomcat.sh ]
then
echo "Tomcat not found"
exit
fi
case $1 in
start)
# Start service
$TOMCAT_HOME/bin/startup.sh
echo -ne "Tomcat started \n"
;;
stop)
$TOMCAT_HOME/bin/shutdown.sh
;;
esac
2) I insert this script in dir /etc/init.d
3) chmod u+x tomcat
4) in /etc/rc2.d (because default runlever is 2 in file inittab) this
command (because i have @S91apache):
ln -s ../init.d/tomcat S90tomcat
5) I rebooted the system and this is the result:
:
:
etc/init.d/rc: /etc/rc2.d/S90tomcat: No such file or directory
apache started
:
Why??
Roberto
Re: Tomcat before Apache
Posted by "Roberto B." <ro...@ipermedianet.com>.
Stop! Stop!.. I wanted to say that I'm the Root user !!
----- Original Message -----
From: "Pier P. Fumagalli" <pi...@betaversion.org>
To: <to...@jakarta.apache.org>
Sent: Friday, August 17, 2001 6:56 PM
Subject: Re: Tomcat before Apache
> Guys. If you wanted to scare the hell out of me, you succeeded... ARE WE
> GOING TO SUGGEST TO OUR USERS TO RUN TOMCAT AS ROOT? ARE YOU ALL NUTS?
>
> Ok, it's good code, but I wouldn't trust not even my mother with root
access
> on my machine... Starting it from the RC scripts will mean that TOMCAT is
> called as root....
>
> I'm attaching a little C script that degradates the process to a specified
> user before execuing it. To compile do "gcc -O2 safexec.c -o safexec" and
to
> run, (for example catalina) do:
>
> safexec username $CATALINA_HOME/bin/catalina.sh start
>
> It's written for Solaris, but it should work also on Linux (maybe some
> compilation warning of some kind)... DO NOT INSTALL IT W/ SUID PRIVILEGES,
> otherwise anyone will be able to break into your machine _easily_... 'K?
>
> Let's try to be a LITTLE BIT security conscious here...
>
> Pier (in these days turned into a security freak!)
>
> --- This is
safexec.c: -----------------------------------------------------
>
> #include <sys/types.h>
> #include <unistd.h>
> #include <string.h>
> #include <errno.h>
> #include <stdio.h>
> #include <pwd.h>
>
> int main(int argc, char *argv[]) {
> struct passwd *user=NULL;
> char **args=NULL;
> int x;
>
> if (argc<3) {
> fprintf(stderr, "Usage: %s [user] [command] [...]\n",argv[0]);
> return(1);
> }
>
> user=getpwnam(argv[1]);
>
> if (setgid(user->pw_gid)!=0) {
> fprintf(stderr, "%s cannot set requested user/group id\n",
argv[0]);
> return(2);
> }
>
> if (setuid(user->pw_uid)!=0) {
> fprintf(stderr, "%s cannot set requested user/group id\n",
argv[0]);
> return(2);
> }
>
> args=(char **)malloc((argc-1)*sizeof(char *));
> for (x=2; x<argc; x++) args[x-2]=argv[x];
> args[argc-1]=NULL;
>
> execvp(argv[2], args);
> fprintf(stderr, "%s: %s: %s\n", argv[0], argv[2], strerror(errno));
> }
>
> --- End of
safexec.c: ------------------------------------------------------
>
Re: Tomcat before Apache
Posted by Christopher Cain <cc...@mhsoftware.com>.
Quoting Dmitri Colebatch <di...@bigpond.net.au>:
> Its a function thats defined in /etc/rc.d/init.d/functions on a redhat
> (and mandrake) box.
>
> cheesr
> dim
Ah ... cool. See, I still learn something new every day.
Cheesr, buddy ;-)
- Christopher
Re: Tomcat before Apache
Posted by Dmitri Colebatch <di...@bigpond.net.au>.
On Fri, 17 Aug 2001, Pier P. Fumagalli wrote:
> Christopher Cain at ccain@mhsoftware.com wrote:
> >
> >> This is I believe Bergstein's daemontools?
> >
> > To be honest, I'm not sure. It's how alot of the standard init.d scripts
> > are coded in Linux, so that's how I've also done mine. Whatever it is,
> > it's installed by default on every Linux distro I've ever used. Perhaps
> > I could throw a small patch into RUNNING.txt with a one-liner for *nix
> > users that the above is a safe way to put TC startup in a script file?
> > Does Solaris include this "daemontools" by default as well?
>
> Nope. It doesn't (as most of the systems I've seen). That's why I wrote my
> little wrapper (before I know that daemontools even existed!).
Its a function thats defined in /etc/rc.d/init.d/functions on a redhat
(and mandrake) box.
cheesr
dim
>
> >> Yeah... Same thing that my little C thing does. But being paranoid, su is
> >> installed setuid, so... :) :) :)
> >
> > Agreed. While the above should technically be secure, you never really
> > know the what next security flaw will be. The daemon approach is
> > probably a little more ultimately secure.
>
> Exactly... If a binary is SUIDed, I don't trust it by default :)
>
> > Tripwire rules. Like any solution it is not 100% foolproof (no such
> > thing), but the possible attacks are fewer than with any other solution
> > I've ever seen and would be VERY involved.
>
> That's why I'm running 4 similar programs at a time, checking all possible
> bugs :)
>
> Pier
>
>
Re: Tomcat before Apache
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Christopher Cain at ccain@mhsoftware.com wrote:
>
>> This is I believe Bergstein's daemontools?
>
> To be honest, I'm not sure. It's how alot of the standard init.d scripts
> are coded in Linux, so that's how I've also done mine. Whatever it is,
> it's installed by default on every Linux distro I've ever used. Perhaps
> I could throw a small patch into RUNNING.txt with a one-liner for *nix
> users that the above is a safe way to put TC startup in a script file?
> Does Solaris include this "daemontools" by default as well?
Nope. It doesn't (as most of the systems I've seen). That's why I wrote my
little wrapper (before I know that daemontools even existed!).
>> Yeah... Same thing that my little C thing does. But being paranoid, su is
>> installed setuid, so... :) :) :)
>
> Agreed. While the above should technically be secure, you never really
> know the what next security flaw will be. The daemon approach is
> probably a little more ultimately secure.
Exactly... If a binary is SUIDed, I don't trust it by default :)
> Tripwire rules. Like any solution it is not 100% foolproof (no such
> thing), but the possible attacks are fewer than with any other solution
> I've ever seen and would be VERY involved.
That's why I'm running 4 similar programs at a time, checking all possible
bugs :)
Pier
Re: Tomcat before Apache
Posted by Christopher Cain <cc...@mhsoftware.com>.
"Pier P. Fumagalli" wrote:
>
> Christopher Cain at ccain@mhsoftware.com wrote:
> >
> >> I'm attaching a little C script that degradates the process to a specified
> >> user before execuing it. To compile do "gcc -O2 safexec.c -o safexec" and to
> >> run, (for example catalina) do:
> >>
> >> safexec username $CATALINA_HOME/bin/catalina.sh start
> >>
> >> It's written for Solaris, but it should work also on Linux (maybe some
> >> compilation warning of some kind)... DO NOT INSTALL IT W/ SUID PRIVILEGES,
> >> otherwise anyone will be able to break into your machine _easily_... 'K?
> >
> > My startup script (Linux) simply does this:
> >
> > daemon --user nobody $CATALINA_HOME/bin/catalina.sh start
>
> This is I believe Bergstein's daemontools?
To be honest, I'm not sure. It's how alot of the standard init.d scripts
are coded in Linux, so that's how I've also done mine. Whatever it is,
it's installed by default on every Linux distro I've ever used. Perhaps
I could throw a small patch into RUNNING.txt with a one-liner for *nix
users that the above is a safe way to put TC startup in a script file?
Does Solaris include this "daemontools" by default as well?
> > That's one way you can execute commands from a script with the proper
> > user privileges. Another way I've seen is:
> >
> > su -l nobody -c '$CATALINA_HOME/bin/catalina.sh start'
> >
> > That works too, but you usually have to mess around with redirects (by
> > adding, say, "< /dev/null > /dev/null 2>& 1" to the end of that su
> > command).
>
> Yeah... Same thing that my little C thing does. But being paranoid, su is
> installed setuid, so... :) :) :)
Agreed. While the above should technically be secure, you never really
know the what next security flaw will be. The daemon approach is
probably a little more ultimately secure.
> >> Let's try to be a LITTLE BIT security conscious here...
> >>
> >> Pier (in these days turned into a security freak!)
> >
> > =)
> >
> > I usually prefer putting "Paranoid" in front of my "Security Freak"
> > title, but that works too ;-)
>
> If you saw what I'm doing this week, you would surely share my vision of
> "freak" :) It's all week I'm running tripwire, nessus and some other (Sun)
> tools on a cluster of machines... AAARRRGGGHHH :) :) :)
Tripwire rules. Like any solution it is not 100% foolproof (no such
thing), but the possible attacks are fewer than with any other solution
I've ever seen and would be VERY involved.
- Christopher
Re: Tomcat before Apache
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Christopher Cain at ccain@mhsoftware.com wrote:
>
>> I'm attaching a little C script that degradates the process to a specified
>> user before execuing it. To compile do "gcc -O2 safexec.c -o safexec" and to
>> run, (for example catalina) do:
>>
>> safexec username $CATALINA_HOME/bin/catalina.sh start
>>
>> It's written for Solaris, but it should work also on Linux (maybe some
>> compilation warning of some kind)... DO NOT INSTALL IT W/ SUID PRIVILEGES,
>> otherwise anyone will be able to break into your machine _easily_... 'K?
>
> My startup script (Linux) simply does this:
>
> daemon --user nobody $CATALINA_HOME/bin/catalina.sh start
This is I believe Bergstein's daemontools?
> That's one way you can execute commands from a script with the proper
> user privileges. Another way I've seen is:
>
> su -l nobody -c '$CATALINA_HOME/bin/catalina.sh start'
>
> That works too, but you usually have to mess around with redirects (by
> adding, say, "< /dev/null > /dev/null 2>& 1" to the end of that su
> command).
Yeah... Same thing that my little C thing does. But being paranoid, su is
installed setuid, so... :) :) :)
>> Let's try to be a LITTLE BIT security conscious here...
>>
>> Pier (in these days turned into a security freak!)
>
> =)
>
> I usually prefer putting "Paranoid" in front of my "Security Freak"
> title, but that works too ;-)
If you saw what I'm doing this week, you would surely share my vision of
"freak" :) It's all week I'm running tripwire, nessus and some other (Sun)
tools on a cluster of machines... AAARRRGGGHHH :) :) :)
Pier
Re: FW: Tomcat before Apache
Posted by Christopher Cain <cc...@mhsoftware.com>.
"Pier P. Fumagalli" wrote:
>
> FYI... The next one I see on any mailing list suggesting to start tomcat
> (any version) from the RC files without changing user id will understand
> what it means to be flamed... :-/
Yep, that's definitely a bad thing.
[snip]
> I'm attaching a little C script that degradates the process to a specified
> user before execuing it. To compile do "gcc -O2 safexec.c -o safexec" and to
> run, (for example catalina) do:
>
> safexec username $CATALINA_HOME/bin/catalina.sh start
>
> It's written for Solaris, but it should work also on Linux (maybe some
> compilation warning of some kind)... DO NOT INSTALL IT W/ SUID PRIVILEGES,
> otherwise anyone will be able to break into your machine _easily_... 'K?
My startup script (Linux) simply does this:
daemon --user nobody $CATALINA_HOME/bin/catalina.sh start
That's one way you can execute commands from a script with the proper
user privileges. Another way I've seen is:
su -l nobody -c '$CATALINA_HOME/bin/catalina.sh start'
That works too, but you usually have to mess around with redirects (by
adding, say, "< /dev/null > /dev/null 2>& 1" to the end of that su
command).
> Let's try to be a LITTLE BIT security conscious here...
>
> Pier (in these days turned into a security freak!)
=)
I usually prefer putting "Paranoid" in front of my "Security Freak"
title, but that works too ;-)
RE: Tomcat before Apache
Posted by Christopher Cain <cc...@mhsoftware.com>.
Quoting Martin van den Bemt <mv...@mvdb.com>:
> point taken about the root thing..
> I took back my words on that it safe to run as root (as quoted in my
> mail to Pier).
Cool. As I said, I had't really read the thread. I wasn't singling you out, I
just wanted to make a definitive comment for the benefit of anyone listening.
Alot of people don't run Linux :-( ... so I was mainly giving a
reasonable "party line" for the benefit of anyone who might be listening.
> But the message I was trying to give was : who are we to tell people not
> to run as root as the default tomcat installation already is hackable in
> 5 minutes?? (at least by Pier..).
Actually, the more vulnerable you you find Tomcat, the more you should be
SCREAMING for people not to run it as root. If a properly-running Tomcat has a
vulnerability, that's one thing. At least an attacker only has the same
privileges as Tomcat, and he/she will have to find some other way to get root.
If Tomcat can be had AND it is running as root ... time to bend over and grab
your ankles ;-)
Your larger point is well-taken, though. You're certainly not going to get ANY
arguments from me on adding as much security-related info to the docs as we can
possibly cram in there. :)
> Let's first get that thing ok and send a security advisory or something???
> Pier gave a good tip that he could write one in 5 minutes, so other people
> are bound to try that.. A message like :
>
> The default installation of tomcat needs to be adjusted when using the
> ajp protocol, so it only accepts connections from the 127.0.0.1 address.
> You must edit the entries <blah><blah> and add the address="127.0.0.1".
Actually, one could be running Tomcat on a different box than Apache, so the
exact message would need to read something like "be sure to set the ajp
protocol to only accept connections from the IP address of your HTTP server."
Dunno about a security advisory. Tomcat standalone is my particular specialty,
so I can't really speak to the possible extent of an Apache+Tomcat problem.
> Also some things you have to keep in mind when setting up ANY
> software, which also includes tomcat :
>
> - don't run as root
> - apply patches to your webserver
Sounds good to me.
> - watch webdav modules if you run as root
No, no, no ... don't even give them the IDEA of running it as root. =)
> - etc,etc,etc,..
>
> Let's get this done before someone finishes that little program...
> Instead of waiting for the first problem and really be on the news..
Sounds good. I'm in favor of all of this, and I assume that since you are using
terms like "let's get this done," we can expect to see your proposed doc
shortly ;-)
Seriously, though, I would be willing to help you out on this. If you would
like to submit a proposed "SECURITY.txt" doc, I will personally look it over
and help out with any changes/additions for a final version. Include all of the
stuff that you and Pier discovered, I'll have a go at anything I am aware of,
then we'll let Craig work his editing/mark-up magic ;-)
> Pleae focus the reply on the server.xml issue instead of saying we
> don't need to run as root, we got the point a couple of threads back.. I want
> to hear about this issue, which we actually have CONTROL over!
Again, *you* have as much control as anyone when it comes to docs. I don't know
the first thing about AJP, so I'm afraid I really can't help you out there,
tough guy.
You are still writing things like, "who are we to tell people not to run as
root as the default tomcat installation already is hackable in 5 minutes"
(which is EXACTLY why you want to tell people NOT to run it as root),
and "watch webdav modules if you run as root", so honestly I feel pretty
justified in having continued the "Don't Run as Root" train of thought.
Anyway, it does no good to argue, since we all want the same thing. As I said,
I wasn't singling you out, I just wanted to explain in more detail the precise
reasons why it shouldn't be run as root, in case users should ever ask "Why?".
Like I said before, I actually think it's cool that you even CARE enough about
security to make a big deal out of it =)
> The worst thing that can happen is that my cat can even break into
> tomcat if someone made a nice ajp client...
Now I *know* that Gomez is on vacation (given the deafening silence) :)
Did you know that your average French worker gets 75% more vacation time at
their job than the average American worker? I've heard that it's similar in
most other European countries, as well. *sigh*
- Christopher
RE: Tomcat 3.3 contextAdmin issues
Posted by Costin Manolache <cm...@yahoo.com>.
On 20 Aug 2001 02:01:12 +0200, Paulo Gaspar wrote:
> Your explanation sure helps understanding what functionality is intended
> for each tag. I can take a look at that too. It is easier for me to
> understand the taglibs than the rest of Tomcat.
> =;o)
Well, I hope understanding the rest of tomcat is not that difficult, but
the goal of the tags was to hide tomcat implementation details ( or
tomcat itself ). A "context" tag can have different implementations,
maybe specific to other servlet containers - the admin interface will be
the same, just a different taglib code will be used.
BTW, nothing requires you to use the tags or jsp - but whatever you use,
please keep the implementation behind an interface similar with the
tags. ( i.e. similar name and behaviors ).
> In this case I am talking about the comments in the method
> org.apache.tomcat.core.ContextManager.shutdown()
>
> In this method's source code there are 2 blocks of cleanup code that
> were commented out. The fact that they were not just removed and the
> nature of a comment:
> "remove the modules ( XXX do we need that ? )"
> before one of those blocks makes me wonder how sure it is that they
> are correct.
The code that is commented out used to be part of the method, including
the one with XXX comment ( and the answer is - we don't need to remove
the modules ).
The idea is quite simple - shutdown() is symetrical with init(). If you
add any context manually ( for example EmbededTomcat.addContext() ), you
should also remove it when you stop ( if you want to ). If a module is
adding contexts - it should also remove them ( or leave them in and
don't add them back ).
That's probably where the bug is, I need to review ContextXmlReader and
AutoWebApp to make sure they remove the contexts on shutdown.
shutdown() followed by init() should bring you back to the same state as
you were before ( if no configuration change happened ).
Now, that's the theory - or what seems to be the 'correct' behavior for
the core. 3.3 is mostly about making sure the core behaves in a well
defined way - better modules will follow, and we can fix modules easily
without all the headache of a major release.
If you have any doubts about the ContextManager behavior - please speak
now, we may still be able to fix it.
Regarding the module removal - again, whoever adds modules should also
remove them back, shutdown shouldn't mess with that ( since init doesn't
either ).
In future, some modules will be enhanced to deal 'nicely' with restarts,
and I plan to add support module reloading ( via a module, of course
:-). As I mentioned so many times, after 3.3 we shouldn't have to change
anything in the core, so new modules can rely on some known and well
defined behavior ( well defined doesn't mean perfect, but good enough
:-).
> Specific questions, besides the above "ContextManager.shutdown()"
> issue:
> - Why is it possible to add 2 or more contexts with the same name
> and base path? It is a cleanup issue that this happens with the
> "restart.jsp" code, but shouldn't this kind of duplication also
> be prevented?
Contexts should be identified by hostname and base path. If we don't
check for that - it's a bug. BTW, the right way to fix the bug is to add
the check - not in the core, but in a module ( that can do other checks
during the addContext/contextInit phases ). Again, this can wait until
after 3.3, I don't think it's a major issue.
> - To make a hot restart, it looks like modules should be restarted
> too. Is this correct?
Modules should deal themself with the init/shutdown events, and restart.
Most existing modules do not need to be reloaded - but that can be done
too. I'm still investigating how to implement module restart, and "hot"
module add/remove. I don't think this can be done in 3.3, but in a set
of modules that can be released after 3.3 ( I have some code, but now I
want to focus on 3.3 and few other important pieces ).
> - When using "restart.jsp", previously removed contexts (using the
> admin pages) were not added back. Why?
Bug probably :-) Again, the right behavior is that whoever adds
something should take it back.
> - Where are existing contexts detected and loaded? Is it on a
> module? And if yes, then which?
Contexts ( and modules ) are added in 2 ways:
- in applications embedding tomcat, by the application via calls to EmbededTomcat
or ContextManager.
- in standalone tomcat, by various configuration modules. Right now the list is:
ContextXmlReader
AutoWebApp.
The first will add modules declared in apps-XXX.xml and server.xml ( which
shouldn't be used for contexts, that's only for backward compat ).
The second deals with webapps-like dirs ( you can define additional
dirs, very usefull for multiple virtual hosts ).
Thats' where you should check what happens on shutdown.
BTW, this review will help a lot - thank you very much. I think it's very
important to make sure the behavior is right in the first place, we can fix
the modules later ( even after beta2, and even after release
- I suspect most of the errors are minor and shouldn't brake anything that works )
Costin
RE: Tomcat 3.3 contextAdmin issues
Posted by Paulo Gaspar <pa...@krankikom.de>.
Answer inline:
> -----Original Message-----
> From: Costin Manolache [mailto:cmanolache@yahoo.com]
> Sent: Saturday, August 18, 2001 8:29 PM
>
> On 18 Aug 2001 19:56:33 +0200, Paulo Gaspar wrote:
>
> .......
>
> > The first two things that are really confusing are:
> > - the existence of 2 lines of very similar classes
> > (e.g.: TomcatAdmin and ContextAdmin) in the "tadm"
> > package at "webapps\admin\WEB-INF\classes\tadm";
>
> Well, TomcatAdmin is the first tag I wrote, and it did a lot of things.
> Too many, actually, so I started to split it. ContextAdmin will focus on
> context tasks, TomcatAdmin for generic tomcat.
>
> Also, TomcatAdmin declares the "ContextManager" scripting variable, and
> that's a problem to be fixed - you can have only one <tadm:admin> in a
> page right now.
Yes, I was thinking the same about that variable. I had to go around that
to improvise a context restart (by using "<% { %>" and "<% } %>").
Your explanation sure helps understanding what functionality is intended
for each tag. I can take a look at that too. It is easier for me to
understand the taglibs than the rest of Tomcat.
=;o)
> > - and the fact that "restart.jsp" does not work as
> > expected producing duplicate entries in the list
> > presented by "contextList.jsp".
>
> That's a bug. I'll take a look, I wrote restart.jsp mostly as a test -
> to make sure all modules are cleaning up after themself ( i.e. you do
> restart.jsp few times and check the thread count, memory use, etc - it
> should stay constant ). If some contexts are not removed - that must be
> fixed ( please add a bug so I'll remember ).
I will try (adding the bug).
> > Looking at "org.apache.tomcat.core.ContextManager" did
> > not help a lot since its comments are not very clear
> > either, as is the case of its "shutdown()" method where
> > comments make me doubt about how cleanup should be done.
>
> Ok, what's not clear :-) ? As you know, I'm not very good at docs, but
> if you ask specific questions I may be able to answer ( and fix the
> comments along the way ).
No one seems to be very good at docs on Tomcat. =;o)
In this case I am talking about the comments in the method
org.apache.tomcat.core.ContextManager.shutdown()
In this method's source code there are 2 blocks of cleanup code that
were commented out. The fact that they were not just removed and the
nature of a comment:
"remove the modules ( XXX do we need that ? )"
before one of those blocks makes me wonder how sure it is that they
are correct.
> > This restart thing probably has some relation with the
> > work Costin is doing on "EmbededTomcat" - maybe the
> > information missing is the same.
>
> It has some relation, in the sense EmbeddedTomcat must be able to
> restart ( and it's using the same calls as restart.jsp ).
Yes, the cleanup issues are related.
Specific questions, besides the above "ContextManager.shutdown()"
issue:
- Why is it possible to add 2 or more contexts with the same name
and base path? It is a cleanup issue that this happens with the
"restart.jsp" code, but shouldn't this kind of duplication also
be prevented?
- To make a hot restart, it looks like modules should be restarted
too. Is this correct?
- When using "restart.jsp", previously removed contexts (using the
admin pages) were not added back. Why?
- Where are existing contexts detected and loaded? Is it on a
module? And if yes, then which?
As you see from the above questions, I still ignore a lot.
Thanks a lot for your attention on this, Costin.
Have fun,
Paulo Gaspar
Re: Tomcat 3.3 contextAdmin issues
Posted by Costin Manolache <cm...@yahoo.com>.
On 18 Aug 2001 19:56:33 +0200, Paulo Gaspar wrote:
> I have been trying to improve a bit on the "admin"
> application, especially on the "contextAdmin" bit,
> tweaking its web pages/JSPs in order to add functionality
> and ease of use.
Great :-)
> I am especially interested on making it easier to restart
> individual applications, deploy or redeploy new
> applications and restart the whole container trough this
> web interface.
> The first two things that are really confusing are:
> - the existence of 2 lines of very similar classes
> (e.g.: TomcatAdmin and ContextAdmin) in the "tadm"
> package at "webapps\admin\WEB-INF\classes\tadm";
Well, TomcatAdmin is the first tag I wrote, and it did a lot of things.
Too many, actually, so I started to split it. ContextAdmin will focus on
context tasks, TomcatAdmin for generic tomcat.
Also, TomcatAdmin declares the "ContextManager" scripting variable, and
that's a problem to be fixed - you can have only one <tadm:admin> in a
page right now.
> - and the fact that "restart.jsp" does not work as
> expected producing duplicate entries in the list
> presented by "contextList.jsp".
That's a bug. I'll take a look, I wrote restart.jsp mostly as a test -
to make sure all modules are cleaning up after themself ( i.e. you do
restart.jsp few times and check the thread count, memory use, etc - it
should stay constant ). If some contexts are not removed - that must be
fixed ( please add a bug so I'll remember ).
> Looking at "org.apache.tomcat.core.ContextManager" did
> not help a lot since its comments are not very clear
> either, as is the case of its "shutdown()" method where
> comments make me doubt about how cleanup should be done.
Ok, what's not clear :-) ? As you know, I'm not very good at docs, but
if you ask specific questions I may be able to answer ( and fix the
comments allong the way ).
> This restart thing probably has some relation with the
> work Costin is doing on "EmbededTomcat" - maybe the
> information missing is the same.
It has some relation, in the sense EmbeddedTomcat must be able to
restart ( and it's using the same calls as restart.jsp ).
Costin
Tomcat 3.3 contextAdmin issues
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi,
I have been trying to improve a bit on the "admin"
application, especially on the "contextAdmin" bit,
tweaking its web pages/JSPs in order to add functionality
and ease of use.
I am especially interested on making it easier to restart
individual applications, deploy or redeploy new
applications and restart the whole container trough this
web interface.
The first two things that are really confusing are:
- the existence of 2 lines of very similar classes
(e.g.: TomcatAdmin and ContextAdmin) in the "tadm"
package at "webapps\admin\WEB-INF\classes\tadm";
- and the fact that "restart.jsp" does not work as
expected producing duplicate entries in the list
presented by "contextList.jsp".
Looking at "org.apache.tomcat.core.ContextManager" did
not help a lot since its comments are not very clear
either, as is the case of its "shutdown()" method where
comments make me doubt about how cleanup should be done.
Can someone help me here?
I am willing to help improving the admin application and
I have a lot of selfish motives to do it, but I need
some pointers in order to understand how it should work.
This restart thing probably has some relation with the
work Costin is doing on "EmbededTomcat" - maybe the
information missing is the same.
Thanks and have fun,
Paulo Gaspar
RE: Tomcat before Apache
Posted by Martin van den Bemt <mv...@mvdb.com>.
point taken about the root thing..
I took back my words on that it safe to run as root (as quoted in my mail to
Pier).
But the message I was trying to give was : who are we to tell people not to
run as root as the default tomcat installation already is hackable in 5
minutes?? (at least by Pier..). Let's first get that thing ok and send a
security advisory or something??? Pier gave a good tip that he could write
one in 5 minutes, so other people are bound to try that..
A message like :
The default installation of tomcat needs to be adjusted when using the ajp
protocol, so it only accepts connections from the 127.0.0.1 address. You
must edit the entries <blah><blah> and add the address="127.0.0.1".
Also some things you have to keep in mind when setting up ANY software,
which also includes tomcat :
- don't run as root
- apply patches to your webserver
- watch webdav modules if you run as root
- etc,etc,etc,..
Let's get this done before someone finishes that little program... Instead
of waiting for the first problem and really be on the news..
Pleae focus the reply on the server.xml issue instead of saying we don't
need to run as root, we got the point a couple of threads back.. I want to
hear about this issue, which we actually have CONTROL over!
The worst thing that can happen is that my cat can even break into tomcat if
someone made a nice ajp client...
Mvgr,
Martin
> -----Original Message-----
> From: Christopher Cain [mailto:ccain@mhsoftware.com]
> Sent: Saturday, August 18, 2001 9:13 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: Tomcat before Apache
>
>
> Quoting "Pier P. Fumagalli" <pi...@betaversion.org>:
>
> > I keep my stance, if I see someone saying "running (put your favourite
> > service here) as root is safe", as you did, I'll flame him. Think TWO
> > steps ahead, ALWAYS.
> >
> > Pier (security conscious)
>
> If I may ...
>
> First of all, I have not read the thread being referenced here,
> and I have no
> idea who said what or why. Also, I grew up in the U.S., so I know
> absolutely
> _nothing_ about soccer =)
>
> I'm sure that Pier appreciates the effort of at least *trying* to
> help out with
> the user list, probably more than most. Most of us, myself
> included, don't
> spend nearly as much time as we should helping out over there.
> Security is just
> one of those issues you sometimes have to scream about =) If all
> projects out
> there had a few people like Pier who were willing to scream about
> it, life
> would be alot easier.
>
> That said ... as someone who's job description often involves security
> consulting and locking down Linux boxes, I just need to say this, for the
> record: PLEASE, FOR THE LOVE OF ALL THAT IS DECENT AND HOLY,
> NEVER SUGGEST TO
> SOMEONE THAT THEY CAN SAFELY RUN _ANYTHING_ AS ROOT.
>
> There are a some system-level process that need root-level
> access, but I'm not
> talking about that. I'm talking about general software
> components. No matter
> how secure you think an application is ... it isn't. Just look at
> the whole
> BIND fiasco a few months back. Everyone stopped worrying about
> who BIND was
> running as, because there hadn't been any holes discovered in
> *years*. They got
> lazy. So when someone did eventually find a hole, countless
> people got a quick
> lesson in security ... the hard way.
>
> So when people ask, please don't tell them to run anything as
> root. In fact,
> tell them quite emphatically NOT to. Run a process that binds on
> a high port as
> root, and you are completely insane. Run a service on a
> well-known port as
> root, and it just becomes question of "when", not "if", some
> script kiddie will
> make you his jail bitch. I personally know ALOT of people who
> stopped using
> BIND when that whole thing went down, even though it was mostly
> their own fault
> for not their scripts set up right. Let's not let this happen to Tomcat,
> because in the post-Microsoft world, users are alot less
> forgiving of security
> problems.
>
> - Christopher
>
Re: Tomcat before Apache
Posted by Christopher Cain <cc...@mhsoftware.com>.
Quoting "Pier P. Fumagalli" <pi...@betaversion.org>:
> I keep my stance, if I see someone saying "running (put your favourite
> service here) as root is safe", as you did, I'll flame him. Think TWO
> steps ahead, ALWAYS.
>
> Pier (security conscious)
If I may ...
First of all, I have not read the thread being referenced here, and I have no
idea who said what or why. Also, I grew up in the U.S., so I know absolutely
_nothing_ about soccer =)
I'm sure that Pier appreciates the effort of at least *trying* to help out with
the user list, probably more than most. Most of us, myself included, don't
spend nearly as much time as we should helping out over there. Security is just
one of those issues you sometimes have to scream about =) If all projects out
there had a few people like Pier who were willing to scream about it, life
would be alot easier.
That said ... as someone who's job description often involves security
consulting and locking down Linux boxes, I just need to say this, for the
record: PLEASE, FOR THE LOVE OF ALL THAT IS DECENT AND HOLY, NEVER SUGGEST TO
SOMEONE THAT THEY CAN SAFELY RUN _ANYTHING_ AS ROOT.
There are a some system-level process that need root-level access, but I'm not
talking about that. I'm talking about general software components. No matter
how secure you think an application is ... it isn't. Just look at the whole
BIND fiasco a few months back. Everyone stopped worrying about who BIND was
running as, because there hadn't been any holes discovered in *years*. They got
lazy. So when someone did eventually find a hole, countless people got a quick
lesson in security ... the hard way.
So when people ask, please don't tell them to run anything as root. In fact,
tell them quite emphatically NOT to. Run a process that binds on a high port as
root, and you are completely insane. Run a service on a well-known port as
root, and it just becomes question of "when", not "if", some script kiddie will
make you his jail bitch. I personally know ALOT of people who stopped using
BIND when that whole thing went down, even though it was mostly their own fault
for not their scripts set up right. Let's not let this happen to Tomcat,
because in the post-Microsoft world, users are alot less forgiving of security
problems.
- Christopher
Re: Tomcat before Apache
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Martin van den Bemt at mvdb@mvdb.com wrote:
> Pier,
>
> I won't make commercials anymore for running as root, just to keep you
> happy..
Just to make _me_ happy? Probably you don't realize what you are saying when
you give hints on running something as root.
> Maybe adding some extra info to the mod_jk.html howto about accesability of
> the 8007 and 8009 ports if you don't change the defaults [...]
> Maby I'm wrong about this, then just let me know..
> Please flame me if I missed something obvious , but a grep -r "address"
> didn't give me any info on security issues involved in not setting that
> thing..
As you (may not) know I am not involved in mod_jk... If that documentation
doesn't address security issue, well, I didn't write it...
I'll make sure that in the final documentation of Tomcat 4.0 there will be a
bold-red paragraph saying "If you run Tomcat as 'root' on Unix you are NUTS"
>> Let's try to be a LITTLE BIT security conscious here...
>
> Maby your just having a bad day??
For sure I did... I had an entire BAD LIFE... It's already hard to keep
hackers out of fairly well-defended systems, I have nightmares about people
breaking into my servers. As I believe most system administrator do.
(Probably the ones running Windows even a little bit more)
But that doesn't change the fact that SECURITY comes first. ALWAYS.
> Let's start with the security tomcat can give by default instead of wining
> about os security administration.. My answer in tomcat-user explicitely is
> pretty self explaining :
>
>> Please tell me what is dangerous about running tomcat as root? I've
>> taken the following security measures :
>> port 8007 and 8009 is blocked from the outside (firewall)
>> tomcat is not running on 8080 and only allowing communications from
>> localhost (127.0.0.1).
>> The only potential problem is that if a tomcat /apache bug is exploited, you
>> potentially have a problem.
Yes, naively not even thinking about what could be wrong in other users
setup. You skipped a long part of the thread: people are trying to run
Tomcat from their RC scripts. Good, I can stand with that, BUT we have to
make sure that we don't compromise security by doing so. David, on the same
thread, wrote (regarding RC scripts):
> unless you want to run your tomcat as root ( Very unwise ) makesure that you
> use a 'su' command in your call to tomcat's start script...
That's great... Good David, security conscious. This is a good reply. Coming
out-of-the-blue and saying "nah, you're paranoid, you can safely run Tomcat
as root and not care about it" you don't consider ONE big thing: what is the
user at the end DOING in his Tomcat.
Tomcat might be safe, but web applications could not be. What if someone
runs Tomcat as root and enables WebDav. What if he has (as in Tomcat 4.0) a
CGI-executor Servlet... What if...
It's true, Tomcat, out-of-the-box, with only the root web-application
installed MIGHT be quite safe, I could run it as is, but, damn, think about
things a little bit later in the process.
Don't you think that there is a reason why Apache doesn't even let you start
the server if you set your user in httpd.conf as root? Apache _is_ safe in
the core, what users make it do is 99% of the times NOT.
Any server (mail, web, whatever) _is_ the shield that separates a client
from your system. Running it as root is like going to battle with a shield
made of thin paper. (Since we're in the spirit of analogisms)
> Maby combining a little bit of the input a lot of people gave will end up in
> a more secure tomcat and some nice docs.. JUST saying that your gonna flame
> everybody who says that running tomcat as root isn't bad is saying to a
> soccer goalkeeper it is ok to let the ball through, because the net protects
> the other team from scoring... If the keeper knows the rules a bit better he
> will try to catch the ball anyway (=protecting the Interceptors). When he
> didn't catch 20 balls, he is probably gonna train a bit more and get
> fimiliar witch catching the ball (=su ing processes).
>
> A nice little story about soccer ;-))
I don't give a **** about soccer, but running as root is _wrong_ anytime and
anywhere. Just implying that it's safe to do so is even more wrong, because
99% of the people out there _DO_ play the "goalkeeper", but they don't even
have a CLUE about the rules of soccer.
I keep my stance, if I see someone saying "running (put your favourite
service here) as root is safe", as you did, I'll flame him. Think TWO steps
ahead, ALWAYS.
Pier (security conscious)
RE: Tomcat before Apache
Posted by Martin van den Bemt <mv...@mvdb.com>.
Pier,
I won't make commercials anymore for running as root, just to keep you
happy..
Maybe adding some extra info to the mod_jk.html howto about accesability of
the 8007 and 8009 ports if you don't change the defaults (you have to
specifically tell to only accept requests from address 127.0.0.1. Switching
that address thing in the standard distro' will improve security a lot..
telnetting to those ports is a big security risk for your webapp (at least
in my point of view..). Since people don't read their entire config files
all the time (me included btw..) and isn't mentioned in the
mod_jk-howto.html (the one in cvs..) and other documentation it's better to
deliver it a bit more secure then it is delivered now.. (talking about tc 33
now, didn't check the other tc's for those docs and problems).
If you say it is written in some kind of hidden doc somewhere (server.xml is
not a doc) then that is really not sufficient enough to point out to people
that they have a potiential big problem when they don't change those
settings.. (it just says if you want to bind it to a specific network
interface blahblah..)
Maby I'm wrong about this, then just let me know..
Please flame me if I missed something obvious , but a grep -r "address"
didn't give me any info on security issues involved in not setting that
thing..
>
> Let's try to be a LITTLE BIT security conscious here...
>
Maby your just having a bad day??
Let's start with the security tomcat can give by default instead of wining
about os security administration.. My answer in tomcat-user explicitely is
pretty self explaining :
> Please tell me what is dangerous about running tomcat as root? I've
> taken the following security measures :
> port 8007 and 8009 is blocked from the outside (firewall)
> tomcat is not running on 8080 and only allowing communications from
> localhost (127.0.0.1).
The only potential problem is that if a tomcat /apache bug is exploited, you
potentially have a problem.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Maby combining a little bit of the input a lot of people gave will end up in
a more secure tomcat and some nice docs.. JUST saying that your gonna flame
everybody who says that running tomcat as root isn't bad is saying to a
soccer goalkeeper it is ok to let the ball through, because the net protects
the other team from scoring.. If the keeper knows the rules a bit better he
will try to catch the ball anyway (=protecting the Interceptors). When he
didn't catch 20 balls, he is probably gonna train a bit more and get
fimiliar witch catching the ball (=su ing processes).
A nice little story about soccer ;-))
Mvgr,
Martin
FW: Tomcat before Apache
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
FYI... The next one I see on any mailing list suggesting to start tomcat
(any version) from the RC files without changing user id will understand
what it means to be flamed... :-/
Pier
------ Forwarded Message
From: Pier P. Fumagalli <pi...@betaversion.org>
Organization: Apache Software Foundation
Date: Fri, 17 Aug 2001 17:56:38 +0100
To: <to...@jakarta.apache.org>
Subject: Re: Tomcat before Apache
Guys. If you wanted to scare the hell out of me, you succeeded... ARE WE
GOING TO SUGGEST TO OUR USERS TO RUN TOMCAT AS ROOT? ARE YOU ALL NUTS?
Ok, it's good code, but I wouldn't trust not even my mother with root access
on my machine... Starting it from the RC scripts will mean that TOMCAT is
called as root....
I'm attaching a little C script that degradates the process to a specified
user before execuing it. To compile do "gcc -O2 safexec.c -o safexec" and to
run, (for example catalina) do:
safexec username $CATALINA_HOME/bin/catalina.sh start
It's written for Solaris, but it should work also on Linux (maybe some
compilation warning of some kind)... DO NOT INSTALL IT W/ SUID PRIVILEGES,
otherwise anyone will be able to break into your machine _easily_... 'K?
Let's try to be a LITTLE BIT security conscious here...
Pier (in these days turned into a security freak!)
--- This is safexec.c: -----------------------------------------------------
#include <sys/types.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <stdio.h>
#include <pwd.h>
int main(int argc, char *argv[]) {
struct passwd *user=NULL;
char **args=NULL;
int x;
if (argc<3) {
fprintf(stderr, "Usage: %s [user] [command] [...]\n",argv[0]);
return(1);
}
user=getpwnam(argv[1]);
if (setgid(user->pw_gid)!=0) {
fprintf(stderr, "%s cannot set requested user/group id\n", argv[0]);
return(2);
}
if (setuid(user->pw_uid)!=0) {
fprintf(stderr, "%s cannot set requested user/group id\n", argv[0]);
return(2);
}
args=(char **)malloc((argc-1)*sizeof(char *));
for (x=2; x<argc; x++) args[x-2]=argv[x];
args[argc-1]=NULL;
execvp(argv[2], args);
fprintf(stderr, "%s: %s: %s\n", argv[0], argv[2], strerror(errno));
}
--- End of safexec.c: ------------------------------------------------------
------ End of Forwarded Message
Re: Tomcat before Apache
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Guys. If you wanted to scare the hell out of me, you succeeded... ARE WE
GOING TO SUGGEST TO OUR USERS TO RUN TOMCAT AS ROOT? ARE YOU ALL NUTS?
Ok, it's good code, but I wouldn't trust not even my mother with root access
on my machine... Starting it from the RC scripts will mean that TOMCAT is
called as root....
I'm attaching a little C script that degradates the process to a specified
user before execuing it. To compile do "gcc -O2 safexec.c -o safexec" and to
run, (for example catalina) do:
safexec username $CATALINA_HOME/bin/catalina.sh start
It's written for Solaris, but it should work also on Linux (maybe some
compilation warning of some kind)... DO NOT INSTALL IT W/ SUID PRIVILEGES,
otherwise anyone will be able to break into your machine _easily_... 'K?
Let's try to be a LITTLE BIT security conscious here...
Pier (in these days turned into a security freak!)
--- This is safexec.c: -----------------------------------------------------
#include <sys/types.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <stdio.h>
#include <pwd.h>
int main(int argc, char *argv[]) {
struct passwd *user=NULL;
char **args=NULL;
int x;
if (argc<3) {
fprintf(stderr, "Usage: %s [user] [command] [...]\n",argv[0]);
return(1);
}
user=getpwnam(argv[1]);
if (setgid(user->pw_gid)!=0) {
fprintf(stderr, "%s cannot set requested user/group id\n", argv[0]);
return(2);
}
if (setuid(user->pw_uid)!=0) {
fprintf(stderr, "%s cannot set requested user/group id\n", argv[0]);
return(2);
}
args=(char **)malloc((argc-1)*sizeof(char *));
for (x=2; x<argc; x++) args[x-2]=argv[x];
args[argc-1]=NULL;
execvp(argv[2], args);
fprintf(stderr, "%s: %s: %s\n", argv[0], argv[2], strerror(errno));
}
--- End of safexec.c: ------------------------------------------------------
Re: Tomcat before Apache
Posted by David Cassidy <dc...@hotgen.com>.
dos2unix ...
Or use vi ...
Martin van den Bemt wrote:
>
> If you created the bash script not in vi, but eg adjusted stuff in write
> and
> saved it, you need to fix the lineendings.. (there is a util for that
> which
> was added again on rh7.1, but I forgot the name).. You can test if this
> is
> the problem by moving the script to eg tomcat_old do a vi tomcat and do
> something that show up at the screen.. If that works, you know for sure
> that
> your bash file is messed up.. Also a hint : try running it after startup
> and
> see if it works..
>
> Mvgr,
> Martin
>
> > -----Original Message-----
> > From: Roberto B. [mailto:roberto@ipermedianet.com]
> > Sent: Friday, August 17, 2001 5:37 PM
> > To: tomcat-user@jakarta.apache.org
> > Subject: Tomcat before Apache
> >
> >
> > I use Linux/Debian as root, Apache 1.3 and Tomcat 4 b6
> >
> > I want to start automatically Tomcat before Apache.
> > I made this things :
> >
> > 1) I created this script named "tomcat":
> >
> > #! /bin/sh
> > TOMCAT_HOME=/usr/tomcat4b6
> > # Test tomcat.sh
> > if [ ! -x $TOMCAT_HOME/bin/tomcat.sh ]
> > then
> > echo "Tomcat not found"
> > exit
> > fi
> > case $1 in
> > start)
> > # Start service
> > $TOMCAT_HOME/bin/startup.sh
> > echo -ne "Tomcat started \n"
> > ;;
> > stop)
> > $TOMCAT_HOME/bin/shutdown.sh
> > ;;
> > esac
> >
> > 2) I insert this script in dir /etc/init.d
> > 3) chmod u+x tomcat
> > 4) in /etc/rc2.d (because default runlever is 2 in file inittab) this
> > command (because i have @S91apache):
> > ln -s ../init.d/tomcat S90tomcat
> >
> > 5) I rebooted the system and this is the result:
> >
> > :
> > :
> > etc/init.d/rc: /etc/rc2.d/S90tomcat: No such file or directory
> > apache started
> > :
> >
> > Why??
> >
> > Roberto
> >
> >
> >
> >
RE: Tomcat before Apache
Posted by Martin van den Bemt <ma...@isallineed.org>.
If you created the bash script not in vi, but eg adjusted stuff in write and
saved it, you need to fix the lineendings.. (there is a util for that which
was added again on rh7.1, but I forgot the name).. You can test if this is
the problem by moving the script to eg tomcat_old do a vi tomcat and do
something that show up at the screen.. If that works, you know for sure that
your bash file is messed up.. Also a hint : try running it after startup and
see if it works..
Mvgr,
Martin
> -----Original Message-----
> From: Roberto B. [mailto:roberto@ipermedianet.com]
> Sent: Friday, August 17, 2001 5:37 PM
> To: tomcat-user@jakarta.apache.org
> Subject: Tomcat before Apache
>
>
> I use Linux/Debian as root, Apache 1.3 and Tomcat 4 b6
>
> I want to start automatically Tomcat before Apache.
> I made this things :
>
> 1) I created this script named "tomcat":
>
> #! /bin/sh
> TOMCAT_HOME=/usr/tomcat4b6
> # Test tomcat.sh
> if [ ! -x $TOMCAT_HOME/bin/tomcat.sh ]
> then
> echo "Tomcat not found"
> exit
> fi
> case $1 in
> start)
> # Start service
> $TOMCAT_HOME/bin/startup.sh
> echo -ne "Tomcat started \n"
> ;;
> stop)
> $TOMCAT_HOME/bin/shutdown.sh
> ;;
> esac
>
> 2) I insert this script in dir /etc/init.d
> 3) chmod u+x tomcat
> 4) in /etc/rc2.d (because default runlever is 2 in file inittab) this
> command (because i have @S91apache):
> ln -s ../init.d/tomcat S90tomcat
>
> 5) I rebooted the system and this is the result:
>
> :
> :
> etc/init.d/rc: /etc/rc2.d/S90tomcat: No such file or directory
> apache started
> :
>
> Why??
>
> Roberto
>
>
>
>
Re: Tomcat before Apache
Posted by "Pier P. Fumagalli" <pi...@betaversion.org>.
Roberto B. at roberto@ipermedianet.com wrote:
> I use Linux/Debian as root, Apache 1.3 and Tomcat 4 b6
>
> I want to start automatically Tomcat before Apache.
> I made this things :
>
> 1) I created this script named "tomcat":
>
> #! /bin/sh
> TOMCAT_HOME=/usr/tomcat4b6
> # Test tomcat.sh
> if [ ! -x $TOMCAT_HOME/bin/tomcat.sh ]
> then
> echo "Tomcat not found"
> exit
> fi
> case $1 in
> start)
> # Start service
> $TOMCAT_HOME/bin/startup.sh
> echo -ne "Tomcat started \n"
> ;;
> stop)
> $TOMCAT_HOME/bin/shutdown.sh
> ;;
> esac
>
> 2) I insert this script in dir /etc/init.d
> 3) chmod u+x tomcat
> 4) in /etc/rc2.d (because default runlever is 2 in file inittab) this
> command (because i have @S91apache):
> ln -s ../init.d/tomcat S90tomcat
>
> 5) I rebooted the system and this is the result:
>
> :
> :
> etc/init.d/rc: /etc/rc2.d/S90tomcat: No such file or directory
> apache started
> :
>
> Why??
Darn... It's not $TOMCAT_HOME/bin/startup-shutdown.sh..
It's $CATALINA_HOME/bin/catalina [start-stop]
Read the docs...
Pier