Jon, On 11/17/2021 6:54 PM, jonmcalexan...@wellsfargo.com.INVALID wrote:
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/
On our systemd environments, we set the bare minimum in the tomcat@sname.service file. That turns out to be:
Environment=CATALINA_HOME=/home/tcadmin/Services/%i/CATALINA_HOME/ Environment=CATALINA_BASE=/home/tcadmin/Services/%i/CATALINA_BASE/ Environment=CATALINA_PID=/var/run/tomcat/%i.pid The %i works on Debian-based systems, but not on RedHat-based systems. Everything else gets stuffed into setenv.sh per service. . . . just my two cents /mde/
OpenPGP_signature
Description: OpenPGP digital signature
