Xnat Installation Issues
Adam Wechter
[root@sulcus tomcat]# service tomcat status
Redirecting to /bin/systemctl status tomcat.service
● tomcat.service - Apache Tomcat Web Application Container
Loaded: loaded (/usr/lib/systemd/system/tomcat.service; disabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2017-03-06 05:44:50 PST; 1min 21s ago
Process: 3562 ExecStart=/usr/libexec/tomcat/server start (code=exited, status=1/FAILURE)
Main PID: 3562 (code=exited, status=1/FAILURE)
Mar 06 05:44:50 sulcus server[3562]: Java virtual machine used: /usr/lib/jvm/jre/bin/java
Mar 06 05:44:50 sulcus server[3562]: classpath used: /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar
Mar 06 05:44:50 sulcus server[3562]: main class used: org.apache.catalina.startup.Bootstrap
Mar 06 05:44:50 sulcus server[3562]: flags used: -Xminf0.1 -Xmaxf0.3 ${CATALINA_OPTS} -Dxnat.home=/sulcusdata/xnat/home -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000
Mar 06 05:44:50 sulcus server[3562]: options used: -Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
Mar 06 05:44:50 sulcus server[3562]: arguments used: start
Mar 06 05:44:50 sulcus server[3562]: Error: Could not find or load main class ${CATALINA_OPTS}
Mar 06 05:44:50 sulcus systemd[1]: tomcat.service: main process exited, code=exited, status=1/FAILURE
Mar 06 05:44:50 sulcus systemd[1]: Unit tomcat.service entered failed state.
Mar 06 05:44:50 sulcus systemd[1]: tomcat.service failed.
Herrick, Rick
Depending on the OS and version you’re running on, have a look at /etc/default/tomcat7 or /usr/share/tomcat/conf/tomcat.conf (I suspect it’s the latter, it looks like you’re on a Fedora/RH variant).
Are you using single quotes around the values in your configuration? Single quotes indicate literal values, meaning variables don’t get expanded:
$ CATALINA_OPTS=123456
$ echo ${CATALINA_OPTS}
123456
$ echo "${CATALINA_OPTS} foo"
123456 foo
$ echo '${CATALINA_OPTS} foo'
${CATALINA_OPTS} foo
That’s the only thing I can think of off the top of my head that would make that happen.
--
Rick Herrick
Sr. Programmer/Analyst
Neuroinformatics Research Group
Washington University School of Medicine
--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
xnat_discussi...@googlegroups.com.
To post to this group, send email to
xnat_di...@googlegroups.com.
Visit this group at https://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/d/optout.
The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.
Adam Wechter
[root@sulcus conf]# cat tomcat.conf
# System-wide configuration file for tomcat services
# This will be loaded by systemd as an environment file,
# so please keep the syntax. For shell expansion support
# place your custom files as /etc/tomcat/conf.d/*.conf
#
# There are 2 "classes" of startup behavior in this package.
# The old one, the default service named tomcat.service.
# The new named instances are called tom...@instance.service.
#
# Use this file to change default values for all services.
# Change the service specific ones to affect only one service.
# For tomcat.service it's /etc/sysconfig/tomcat, for
# tomcat@instance it's /etc/sysconfig/tomcat@instance.
# This variable is used to figure out if config is loaded or not.
TOMCAT_CFG_LOADED="1"
# In new-style instances, if CATALINA_BASE isn't specified, it will
# be constructed by joining TOMCATS_BASE and NAME.
TOMCATS_BASE="/var/lib/tomcats/"
# Where your java installation lives
JAVA_HOME="/usr/lib/jvm/jre"
# Where your tomcat installation lives
CATALINA_HOME="/usr/share/tomcat"
# System-wide tmp
CATALINA_TMPDIR="/var/cache/tomcat/temp"
# You can pass some parameters to java here if you wish to
JAVA_OPTS="-Xminf0.1 -Xmaxf0.3"
# Use JAVA_OPTS to set java.library.path for libtcnative.so
#JAVA_OPTS="-Djava.library.path=/usr/lib"
# You can change your tomcat locale here
#LANG="en_US"
# Run tomcat under the Java Security Manager
SECURITY_MANAGER="false"
# Time to wait in seconds, before killing process
# TODO(stingray): does nothing, fix.
# SHUTDOWN_WAIT="30"
# If you wish to further customize your tomcat environment,
# put your own definitions here
# (i.e. LD_LIBRARY_PATH for some jdbc drivers)
#
#XNAT
CATALINA_OPTS="${CATALINA_OPTS} -Dxnat.home=/sulcusdata/xnat/home -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000"
Herrick, Rick
Well that was fun. The problem is systemd and how it handles environment variables. Have a look here:
https://www.freedesktop.org/software/systemd/man/systemd.exec.html - Environment=
Variables are set in systemd configurations using the “Environment=xxx” and “EnvironmentFile=yyy”. These don’t expand variables referenced within their values. The variables are only expanded if referenced in the “ExecStart” statement. The Tomcat service is defined like this (there’s some other stuff but this is what’s relevant here):
EnvironmentFile=/etc/tomcat/tomcat.conf
Environment="NAME="
EnvironmentFile=-/etc/sysconfig/tomcat
ExecStart=/usr/libexec/tomcat/server start
That first EnvironmentFile statement pulls in your settings and leaves ${CATALINA_OPTS} in there as a literal value. It also pulls in the sysconfig Tomcat settings, which by default on Centos 7.3 doesn’t contain anything. Then it runs the /usr/libexec/tomcat/server script passing in all of the configured values. The start command expands the value set for CATALINA_OPTS, which includes… ${CATALINA_OPTS}. Literally. L
Overall this seems pretty dumb to me but no one asked, so there ya go.
The solution then is just to set CATALINA_OPTS directly without any consideration for previously defined values:
CATALINA_OPTS="-Dxnat.home=/sulcusdata/xnat/home -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000"
It’s worth noting that I think you’re going to have to mess with the Tomcat service definition (located in /lib/system/system/tomcat.service) directly in this situation:
[Service]
Type=simple
EnvironmentFile=/etc/tomcat/tomcat.conf
Environment="NAME="
EnvironmentFile=-/etc/sysconfig/tomcat
ExecStart=/usr/libexec/tomcat/server start
SuccessExitStatus=143
User=tomcat
Group=tomcat
One of the standard practices we recommend is to change the user and group that runs Tomcat. As far as I can tell, the only place to do that is right there in the service definition.
HTH.
--
Rick Herrick
Sr. Programmer/Analyst
Neuroinformatics Research Group
Washington University School of Medicine
--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
xnat_discussi...@googlegroups.com.
To post to this group, send email to
xnat_di...@googlegroups.com.
Visit this group at https://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/d/optout.
Herrick, Rick
A follow-up on this: I was thinking about it last night and realized that my dev server, which runs Ubuntu 16.04.2, uses systemd for service management and YET I have exactly this kind of environment variable configuration in my tomcat7.conf. So why does it work there but not on Centos 7.2/3?
The answer is that Ubuntu and I guess the deb package management system uses systemd along with systemd-sysv-generator so that services can just be installed using existing SysV-style init scripts (i.e. the ones in /etc/init.d) and service definitions are generated automatically for them. These generated service definitions are placed in /run/systemd/generator.late and end up looking something like this (there’s more but this is the important part):
ExecStart=/etc/init.d/tomcat7 start
ExecStop=/etc/init.d/tomcat7 stop
In this case systemd doesn’t resolve the environment variables but just invokes the SysV-style init scripts, which work the same way they did before and the variables get expanded in-line because they’re really just sourced into a shell script.
I don’t know if there’s a way to get Tomcat configured in CentOS to use the SysV-style init script and generate the systemd service definition without basically going in and doing it manually.
--
Rick Herrick
Sr. Programmer/Analyst
Neuroinformatics Research Group
Washington University School of Medicine
Adam Wechter
Herrick, Rick
The issue here is the configuration for PostgreSQL itself, specifically how authentication is configured:
Caused by: org.postgresql.util.PSQLException: FATAL: Ident authentication failed for user "tomcat"
This means your configuration is somehow indicating that “tomcat” should authenticate using ident (e.g. oidentd). That could be explicit:
host xnat tomcat 127.0.0.1/32 ident
It could be a blanket requirement:
host all all 127.0.0.1/32 ident
Basically this relates to how PostgreSQL thinks it’s supposed to allow that user to authenticate. I suspect you’re just using the default CentOS configuration, which you’ll find in a location something like /var/lib/pgsql/9.6/data (that’s where mine is on CentOS 7.3 with PostgreSQL 9.6) in the file pg_hba.conf (this is always the file, the question is just where you find it). That contains the following:
local all all peer
host all all 127.0.0.1/32 ident
host all all ::1/128 ident
JDBC database URLs (e.g. the one in your xnat-conf.properties file, something like jdbc:postgresql://localhost/xnat) don’t support local connections by socket, so you can ignore that line. That means that you’re running into the second line there, accessing localhost thru 127.0.0.1, and all users on all databases have to authenticate through ident. Which is ironic because oidentd isn’t installed by default and is really kind of a pain to set up, so why that would be the default auth mechanism is a little strange. But there you go.
The best way to fix this is just to modify the pg_hba.conf file to let your user access the XNAT database on localhost with either a password or just full trust:
host xnat tomcat 127.0.0.1/32 md5
host xnat tomcat ::1/128 md5
That assumes that your database is named XNAT and you continue to use tomcat as the user name. I’d suggest changing it to something else, but that’s up to you. The md5 there will require a password to access the database. Change that to trust and then you can connect to the database locally without having to even specify the password.
Note that setting that to trust won’t affect whether the password is required when connecting through the psql command-line client: that is a local connection, so the peer authentication would come into play, which means you can only connect when logged in as a user with permissions on the database (i.e. you su to the xnat user then do psql and you’ll connect as the xnat database user).
Whenever you make changes to the pgsql configurations, you need to restart the database server:
$ systemctl restart postgresql-9.6.service
--
Rick Herrick
Sr. Programmer/Analyst
Neuroinformatics Research Group
Washington University School of Medicine
From: "xnat_di...@googlegroups.com" <xnat_di...@googlegroups.com> on behalf of Adam Wechter <wech...@gmail.com>
Reply-To: "xnat_di...@googlegroups.com" <xnat_di...@googlegroups.com>
Date: Thursday, March 16, 2017 at 11:27 AM
To: "xnat_di...@googlegroups.com" <xnat_di...@googlegroups.com>
--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
xnat_discussi...@googlegroups.com.
To post to this group, send email to
xnat_di...@googlegroups.com.
Visit this group at https://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/d/optout.