Sorry about my bad reply order. Mark, you do a lot of what I do, but most of our stuff isn't using initd. I like your use of links, best way to handle upgrades, imo.
Thanks, Sent with BlackBerry Work (www.blackberry.com) ________________________________ From: Mark Eggers <its_toas...@yahoo.com.INVALID> Sent: Nov 17, 2021 8:10 PM To: users@tomcat.apache.org Subject: Re: How to *properly* create and use a CATALINA_BASE installation On 11/17/2021 5:28 PM, jonmcalexan...@wellsfargo.com.INVALID<mailto:jonmcalexan...@wellsfargo.com.INVALID> wrote: > We export it. You have to make sure the setenv.sh<http://setenv.sh> is > calling setenv.sh<http://setenv.sh>. it works fine for me. > > > Thanks, > > > Sent with BlackBerry Work (www.blackberry.com<http://www.blackberry.com>) > ________________________________ > From: Michael B Allen <iop...@gmail.com<mailto:iop...@gmail.com>> > Sent: Nov 17, 2021 6:54 PM > To: Tomcat Users List > <users@tomcat.apache.org<mailto:users@tomcat.apache.org>> > Subject: Re: How to *properly* create and use a CATALINA_BASE installation > > On Wed, Nov 17, 2021 at 11:04 AM > <jonmcalexan...@wellsfargo.com.invalid<mailto:jonmcalexan...@wellsfargo.com.invalid>> > wrote: >> I, in my opinion, find it far easier to set my BASE in the >> setenv.sh<http://setenv.sh> for the instance I'm using. As Chris said, you >> can have multiple instances (BASEs) on a server. > > Jon, > > If you mean you're setting $CATALINA_BASE in setenv.sh<http://setenv.sh>, I > don't think > that will work because when you run > $CATALINA_BASE/bin/startup.sh<http://startup.sh>, > $CATALINA_BASE won't be set yet and so it's going to set > $CATALINA_BASE to $CATALINA_HOME and then source the > $CATALINA_HOME/bin/setenv.sh<http://setenv.sh> and not the $CATALINA_BASE > specific > setenv.sh<http://setenv.sh>. I think that's what Chris was referring to in > his first > reply to you. > > Although if I'm using a $CATALINA_BASE/bin/run.sh<http://run.sh> alternative > to > startup.sh<http://startup.sh> like in my previous post, I would probably just > put ALL the > various environment variables (listed at the top of > bin/catalina.sh<http://catalina.sh>) > in there too. Using setenv.sh<http://setenv.sh> at that point would just be > needlessly > spreading config around. > > The documentation currently seems to be targeting installations shared > by multiple different users where $CATALINA_HOME and $CATALINA_BASE > get set in the users environment such that different users can have > different bases but share a common installation like in /usr/local or > some such. Then you *would* want to put base specific stuff in > $CATALINA_BASE/bin/setenv.sh<http://setenv.sh>. But IMO that's kind of a late > 90's way > of doing things. Nowadays, not only do people have their own machines, > but they have multiple instances in VMs and private servers and docker > and so on. So I think the self-contained > $CATALINA_BASE/bin/run.sh<http://run.sh> > method is probably a little better for most cases (although I still > need to study the Windows service use-case which is probably > important). > > Mike > > -- > Michael B Allen > Java Active Directory Integration > https://urldefense.com/v3/__http://www.ioplex.com/__;!!F9svGWnIaVPGSwU!4iBjG2OA7erMr6vPvbqVyxiEd3LfwnDYJHJSyYeYUf-BvIj0XsTET3jr1g4QVb95_R5ATTc$ > ; On Linux with systemd, I put the following in the systemd file: Environment=CATALINA_HOME=/home/tcadmin/Services/[sname]/CATALINA_HOME/ Environment=CATALINA_BASE=/home/tcadmin/Services/[sname]CATALINA_BASE/ Environment=CATALINA_PID=/var/run/tomcat/[sname].pid where [sname] is the name of the service. tcadmin is the unprivileged user that runs all the Tomcats on the system. Everything else is set in /home/tcadmin/Services/[sname]/CATALINA_BASE/bin/setenv.sh<http://setenv.sh> For the old style init.d systems, I put everything in: /etc/sysconfig/[tomcatx]/[sname] where [tomcatx] is the base version of Tomcat, and [sname] is the service name. Then there is an init file for each service that reads the appropriate /etc/sysconfig/[tomcatx]/[sname] file to set the up the environment. CATALINA_HOME and CATALINA_BASE are links to an appropriate Tomcat installation, and one configured for that particular service. Then to upgrade to a new Tomcat, you do the following: 1. Unpack the new reference version of Tomcat somewhere which becomes CATALINA_HOME. 2. Create the new service-specific installation of Tomcat which becomes CATALINA_BASE. All of the above can be done without disturbing the existing service. To upgrade, do the following: 1. Shut down the service 2. Move the links 3. Start up the service If things blow up in your face, then the roll back is really easy: 1. Shut down the service 2. Restore the links 3. Start up the service Since the CATALINA_BASE is linked to a version-specific directory, you'll have log files to figure out why things didn't go according to plan if you have to roll back. Automate configuring your CATALINA_BASE setup with a couple of Ant build.xml<http://build.xml> files, a couple of property files, with an XSLT file or two, and configuring a new version of Tomcat takes a few seconds. Version the property files to keep track of Tomcat updates, and you can keep track of what was changed, by whom, and when. All of that makes a sysadmin a happy camper. Add more or less automation to taste. This is of course only germane if you're running a traditional IS architecture. . . . just my two cents /mde/ On 11/17/2021 5:28 PM, jonmcalexan...@wellsfargo.com.INVALID wrote: > We export it. You have to make sure the setenv.sh is calling setenv.sh. it > works fine for me. > > > Thanks, > > > Sent with BlackBerry Work (www.blackberry.com<http://www.blackberry.com>) > ________________________________ > From: Michael B Allen <iop...@gmail.com> > Sent: Nov 17, 2021 6:54 PM > To: Tomcat Users List <users@tomcat.apache.org> > Subject: Re: How to *properly* create and use a CATALINA_BASE installation > > On Wed, Nov 17, 2021 at 11:04 AM <jonmcalexan...@wellsfargo.com.invalid> > wrote: >> I, in my opinion, find it far easier to set my BASE in the setenv.sh for the >> instance I'm using. As Chris said, you can have multiple instances (BASEs) >> on a server. > > Jon, > > If you mean you're setting $CATALINA_BASE in setenv.sh, I don't think > that will work because when you run $CATALINA_BASE/bin/startup.sh, > $CATALINA_BASE won't be set yet and so it's going to set > $CATALINA_BASE to $CATALINA_HOME and then source the > $CATALINA_HOME/bin/setenv.sh and not the $CATALINA_BASE specific > setenv.sh. I think that's what Chris was referring to in his first > reply to you. > > Although if I'm using a $CATALINA_BASE/bin/run.sh alternative to > startup.sh like in my previous post, I would probably just put ALL the > various environment variables (listed at the top of bin/catalina.sh) > in there too. Using setenv.sh at that point would just be needlessly > spreading config around. > > The documentation currently seems to be targeting installations shared > by multiple different users where $CATALINA_HOME and $CATALINA_BASE > get set in the users environment such that different users can have > different bases but share a common installation like in /usr/local or > some such. Then you *would* want to put base specific stuff in > $CATALINA_BASE/bin/setenv.sh. But IMO that's kind of a late 90's way > of doing things. Nowadays, not only do people have their own machines, > but they have multiple instances in VMs and private servers and docker > and so on. So I think the self-contained $CATALINA_BASE/bin/run.sh > method is probably a little better for most cases (although I still > need to study the Windows service use-case which is probably > important). > > Mike > > -- > Michael B Allen > Java Active Directory Integration > https://urldefense.com/v3/__http://www.ioplex.com/__;!!F9svGWnIaVPGSwU!4iBjG2OA7erMr6vPvbqVyxiEd3LfwnDYJHJSyYeYUf-BvIj0XsTET3jr1g4QVb95_R5ATTc$ On Linux with systemd, I put the following in the systemd file: Environment=CATALINA_HOME=/home/tcadmin/Services/[sname]/CATALINA_HOME/ Environment=CATALINA_BASE=/home/tcadmin/Services/[sname]CATALINA_BASE/ Environment=CATALINA_PID=/var/run/tomcat/[sname].pid where [sname] is the name of the service. tcadmin is the unprivileged user that runs all the Tomcats on the system. Everything else is set in /home/tcadmin/Services/[sname]/CATALINA_BASE/bin/setenv.sh For the old style init.d systems, I put everything in: /etc/sysconfig/[tomcatx]/[sname] where [tomcatx] is the base version of Tomcat, and [sname] is the service name. Then there is an init file for each service that reads the appropriate /etc/sysconfig/[tomcatx]/[sname] file to set the up the environment. CATALINA_HOME and CATALINA_BASE are links to an appropriate Tomcat installation, and one configured for that particular service. Then to upgrade to a new Tomcat, you do the following: 1. Unpack the new reference version of Tomcat somewhere which becomes CATALINA_HOME. 2. Create the new service-specific installation of Tomcat which becomes CATALINA_BASE. All of the above can be done without disturbing the existing service. To upgrade, do the following: 1. Shut down the service 2. Move the links 3. Start up the service If things blow up in your face, then the roll back is really easy: 1. Shut down the service 2. Restore the links 3. Start up the service Since the CATALINA_BASE is linked to a version-specific directory, you'll have log files to figure out why things didn't go according to plan if you have to roll back. Automate configuring your CATALINA_BASE setup with a couple of Ant build.xml files, a couple of property files, with an XSLT file or two, and configuring a new version of Tomcat takes a few seconds. Version the property files to keep track of Tomcat updates, and you can keep track of what was changed, by whom, and when. All of that makes a sysadmin a happy camper. Add more or less automation to taste. This is of course only germane if you're running a traditional IS architecture. . . . just my two cents /mde/
