OraOpenSource / OXAR

Oracle XE & APEX build script along with images for popular cloud platforms
http://www.oraopensource.com/oxar/
MIT License
109 stars 42 forks source link

Error /usr/share/tomcat/webapps/i does not exist after tomcat upgrade from 7.0.69 to 7.0.76 #247

Closed GasparYYC closed 6 years ago

GasparYYC commented 6 years ago

Hi, In my sandbox (Virtualbox on Win 10) I updated all packages (CentOS 7. via: yum update) and the end result is that tomcat seems to have problems on startup complaining that /usr/share/tomcat/webapps/i does not exist or is not a readable.

I ran the commands on issue #241 but no go..

Any ideas would be appreciated..
Everything was working perfectly up until the update of tomcat

BTW The directory exists and is readable:

# ls -l /usr/share/tomcat/webapps/i
lrwxrwxrwx. 1 root root 18 Feb 18  2017 /usr/share/tomcat/webapps/i -> /ords/apex_images/

[root@CentOS51 ~]# ls /usr/share/tomcat/webapps/i
16admin.gif                   button_search.gif ...

[root@CentOS51 ~]#  ls /var/lib/tomcat/webapps/i
16admin.gif                   button_search.gif ...

Thanks

Excerpt of Catalina (Sorry if too long) ... INFO: Initializing ProtocolHandler ["http-bio-8080"] Dec 10, 2017 12:08:16 AM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["ajp-bio-8009"] Dec 10, 2017 12:08:16 AM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 3891 ms Dec 10, 2017 12:08:16 AM org.apache.catalina.core.StandardService startInternal INFO: Starting service Catalina Dec 10, 2017 12:08:16 AM org.apache.catalina.core.StandardEngine startInternal INFO: Starting Servlet Engine: Apache Tomcat/7.0.76 Dec 10, 2017 12:08:16 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory /var/lib/tomcat/webapps/host-manager Dec 10, 2017 12:08:17 AM org.apache.catalina.startup.TldConfig execute INFO: At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time. Dec 10, 2017 12:08:18 AM org.apache.catalina.util.SessionIdGeneratorBase createSecureRandom INFO: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [138] milliseconds. Dec 10, 2017 12:08:18 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deployment of web application directory /var/lib/tomcat/webapps/host-manager has finished in 1,827 ms Dec 10, 2017 12:08:18 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory /var/lib/tomcat/webapps/manager Dec 10, 2017 12:08:18 AM org.apache.catalina.startup.TldConfig execute INFO: At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time. Dec 10, 2017 12:08:18 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deployment of web application directory /var/lib/tomcat/webapps/manager has finished in 482 ms Dec 10, 2017 12:08:18 AM org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory /var/lib/tomcat/webapps/i Dec 10, 2017 12:08:18 AM org.apache.catalina.core.StandardContext resourcesStart SEVERE: Error starting static Resources java.lang.IllegalArgumentException: Document base /usr/share/tomcat/webapps/i does not exist or is not a readable directory at org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:136) at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:5247) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5436) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:899) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:652) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1260) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:2002) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ...

fuzziebrain commented 6 years ago

Sounds like the issue is related to #241 . Please see the updated information will fix your issue. We can otherwise resolve this under the same ticket.

GasparYYC commented 6 years ago

@fuzziebrain I have an update that I think is pretty important

I retried the exact same operation: yum update

But this time I disabled SELinux prior to that:

sed -i.backup  's/SELINUX=enforcing/SELINUX=disabled/' /etc/sysconfig/selinux
sed -i.backup  's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config
reboot

and I'm happy to report that the upgrade to the OS was a success.

For the benefit of OXAR existing users I recommend you or @martindsouza add a note in github webpage so people with existing OXAR installations that do an OS update like in the past (before this was not an issue) deal with this new problem before they crash their OXAR installations.

I understand your preference in adapting OXAR to deal with with SELinux activated but this time its not related to OXAR installation but to an upgrade of the OS to the latest patches,bugfixes,security patches,etc when OXAR has already been installed.

I sincerely think this is a big deal cause its easy to install new OXAR but sometimes you need to apply security patches to the existing one.

Thanks for your time in all this by the way.

fuzziebrain commented 6 years ago

I don't see an issue adding a note that this is potentially an issue, but disabling SELinux should never be the solution. I believe the primary motivation of OXAR should always be setting up a new instance with the best practices embedded. Things change all the time. If we had to upgrade/update/patch an instance, then the onus is on the system's owner to adapt to those changes. The issue can be reported, but a fix will be geared towards ensuring that any new instances created, would be trouble-free and secure.