Upgrade van Tomcat7 naar Tomcat8

[be3a18]

Een nieuwe versie van een web applicatie die bij ons draait vereist een hogere versie van Tomcat. Momenteel is dat Tomcat7. Voor de webapplicatie is ook Java vereist.

Dit zijn de huidige Java parameters:

Java-versie: 1.8
Java-runtime-versie: 1.8.0_212-8u212-b03-0ubuntu1.16.04.1-b03
JVM Naam: OpenJDK 64-Bit Server VM
JVM publisher: Oracle Corporation
JVM gestart: Jul 5, 2019 10:56:37 AM
JVM argumenten: -Djava.util.logging.config.file=/var/lib/tomcat7/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.awt.headless=true
-Xmx1280m
-XX:+UseConcMarkSweepGC
-Dfile.encoding=UTF-8
-Djava.endorsed.dirs=/usr/share/tomcat7/endorsed
-Dcatalina.base=/var/lib/tomcat7
-Dcatalina.home=/usr/share/tomcat7
-Djava.io.tmpdir=/tmp/tomcat7-tomcat7-tmp

Zo te zien staat er iets van Tomcat op meerdere locaties. /usr/share/tomcat7 Is volgens mij echter de installatie directory. Wat is de correcte manier om Tomcat te upgraden? Ik las ergens dat je beter Tomcat 8 kaal installeert en dan vervolgens de instellingen goed gaat zetten. Wat volgens mij nogal een karwei is.

[Hero of Time]

Tomcat zoals je daar ziet, volgt de Linux standaard voor waar bestanden horen. Je kan zo tomcat 8 ernaast installeren, even ervan uit gaan dat het in je repo beschikbaar is, en dan de webapps map overnemen en de config in /etc nalopen op afwijkingen.

[be3a18]

Hero of Time schreef op dinsdag 16 juli 2019 @ 12:46:
Tomcat zoals je daar ziet, volgt de Linux standaard voor waar bestanden horen. Je kan zo tomcat 8 ernaast installeren, even ervan uit gaan dat het in je repo beschikbaar is, en dan de webapps map overnemen en de config in /etc nalopen op afwijkingen.

Ik heb nu Tomcat 8 geïnstalleerd en even in /etc/tomcat7 gekeken. Kun je globaal aangeven wat ik moet aanpassen?

De webapps directory met de applicatie in kwestie staat nu in /var/lib/tomcat7. Bij de installatie van Tomcat 8 is geen directory /var/lib/tomcat8 aangemaakt. Moet dit handmatig en dan vervolgens de subdirectory webapps daar neerzetten?

Het starten van Tomcat8 via /usr/share/tomcat8/bin/startup.sh geeft als resultaat:

Using CATALINA_BASE: /usr/share/tomcat8
Using CATALINA_HOME: /usr/share/tomcat8
Using CATALINA_TMPDIR: /usr/share/tomcat8/temp
Using JRE_HOME: /usr
Using CLASSPATH: /usr/share/tomcat8/bin/bootstrap.jar:/usr/share/tomcat8/bin/tomcat-juli.jar
Tomcat started.

[Hero of Time]

Hoe heb je tomcat 8 dan geïnstalleerd? Want er zou ook een script of service bestand meegeleverd moeten zijn om het automatisch bij opstarten en afsluiten te regelen. Je krijgt dan ook alle aparte paden die je nu ziet voor tomcat 7. Maar nogmaals, als dit ook beide in je repo wordt aangeboden.

[be3a18]

Hero of Time schreef op dinsdag 16 juli 2019 @ 14:26:
Hoe heb je tomcat 8 dan geïnstalleerd? Want er zou ook een script of service bestand meegeleverd moeten zijn om het automatisch bij opstarten en afsluiten te regelen. Je krijgt dan ook alle aparte paden die je nu ziet voor tomcat 7. Maar nogmaals, als dit ook beide in je repo wordt aangeboden.

Ik heb deze instructies deels gevolgd. Het tar.gz bestand heb ik gedownload.

https://www.digitalocean....-tomcat-8-on-ubuntu-16-04

Moet ik voor Tomcat 8 een aparte groep en gebruiker aanmaken (omdat er al een is voor tomcat 7)? Verder hebben ze daar over het aanmaken van een /etc/systemd/system/tomcat.service maar dat wordt dan een geheel nieuw bestand omdat er voor tomcat7 niet zo'n bestand is.

Alle subdirectories (zoals webapps bijvoorbeeld) staan nu in /usr/share/tomcat8.

[Hero of Time]

Ik raad je toch aan om naar je distro te kijken voor tomcat 8. Je krijgt dan ook updates als die er zijn ipv dat je dit zelf bij moet gaan houden en installeren.

Je zegt nergens specifiek welke distro je hebt, maar toevallig wordt dit in de versie informatie getoond van Java. Dat zegt dat je Ubuntu 16.04 draait. Is het niet handiger om de server opnieuw in te richten met 18.04 en tomcat 8?
Al heeft 16.04 die ook gewoon als ik https://packages.ubuntu.com/search?keywords=tomcat8 moet geloven. Dus, waarom heb je niet simpelweg 'apt-get install tomcat8' gedaan?

[be3a18]

Hero of Time schreef op dinsdag 16 juli 2019 @ 14:52:
Ik raad je toch aan om naar je distro te kijken voor tomcat 8. Je krijgt dan ook updates als die er zijn ipv dat je dit zelf bij moet gaan houden en installeren.

Je zegt nergens specifiek welke distro je hebt, maar toevallig wordt dit in de versie informatie getoond van Java. Dat zegt dat je Ubuntu 16.04 draait. Is het niet handiger om de server opnieuw in te richten met 18.04 en tomcat 8?
Al heeft 16.04 die ook gewoon als ik https://packages.ubuntu.com/search?keywords=tomcat8 moet geloven. Dus, waarom heb je niet simpelweg 'apt-get install tomcat8' gedaan?

Dat laatste ga ik even proberen, ik had niet verwacht dat Tomcat 8 al aanwezig is in de aanwezige repository. De reden om het niet te doen op Ubuntu 18 is omdat de applicatie dan volledig opnieuw geconfigureerd moet worden. Dat denk ik althans.

[be3a18]

Ik heb een snapshot terug gezet en vervolgens apt-get install tomcat8 gedraaid. Dat lijkt goed te gaan maar er volgen een aantal foutmeldingen.

root@srv016:~# apt-get update
Hit:1 http://nl.archive.ubuntu.com/ubuntu xenial InRelease
Hit:2 http://nl.archive.ubuntu.com/ubuntu xenial-updates InRelease
Hit:3 http://security.ubuntu.com/ubuntu xenial-security InRelease
Hit:4 http://nl.archive.ubuntu.com/ubuntu xenial-backports InRelease
Hit:5 http://archive.ubuntu.com/ubuntu xenial-backports InRelease
Hit:6 http://repo.zabbix.com/zabbix/3.2/ubuntu xenial InRelease
Hit:7 http://apt.puppetlabs.com xenial InRelease
Reading package lists... Done
root@srv016:~# apt-get install tomcat8
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
libtomcat8-java tomcat8-common
Suggested packages:
libtcnative-1 tomcat8-admin tomcat8-docs tomcat8-examples tomcat8-user
The following NEW packages will be installed:
libtomcat8-java tomcat8 tomcat8-common
0 upgraded, 3 newly installed, 0 to remove and 9 not upgraded.
Need to get 4,754 kB of archives.
After this operation, 5,967 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64 libtomcat8-java all 8.0.32-1ubuntu1.9 [4,658 kB]
Get:2 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64 tomcat8-common all 8.0.32-1ubuntu1.9 [53.2 kB]
Get:3 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64 tomcat8 all 8.0.32-1ubuntu1.9 [42.4 kB]
Fetched 4,754 kB in 0s (11.2 MB/s)
Preconfiguring packages ...
Selecting previously unselected package libtomcat8-java.
(Reading database ... 138279 files and directories currently installed.)
Preparing to unpack .../libtomcat8-java_8.0.32-1ubuntu1.9_all.deb ...
Unpacking libtomcat8-java (8.0.32-1ubuntu1.9) ...
Selecting previously unselected package tomcat8-common.
Preparing to unpack .../tomcat8-common_8.0.32-1ubuntu1.9_all.deb ...
Unpacking tomcat8-common (8.0.32-1ubuntu1.9) ...
Selecting previously unselected package tomcat8.
Preparing to unpack .../tomcat8_8.0.32-1ubuntu1.9_all.deb ...
Unpacking tomcat8 (8.0.32-1ubuntu1.9) ...
Processing triggers for ureadahead (0.100.0-19.1) ...
Processing triggers for systemd (229-4ubuntu21.21) ...
Setting up libtomcat8-java (8.0.32-1ubuntu1.9) ...
Setting up tomcat8-common (8.0.32-1ubuntu1.9) ...
Setting up tomcat8 (8.0.32-1ubuntu1.9) ...

Creating config file /etc/default/tomcat8 with new version
Adding system user `tomcat8' (UID 117) ...
Adding new user `tomcat8' (UID 117) with group `tomcat8' ...
Not creating home directory `/usr/share/tomcat8'.

Creating config file /etc/logrotate.d/tomcat8 with new version
Job for tomcat8.service failed because the control process exited with error code. See "systemctl status tomcat8.service" and "journalctl -xe" for details.
invoke-rc.d: initscript tomcat8, action "start" failed.
● tomcat8.service - LSB: Start Tomcat.
Loaded: loaded (/etc/init.d/tomcat8; bad; vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2019-07-16 15:06:20 CEST; 4ms ago
Docs: man:systemd-sysv-generator(
Process: 34835 ExecStart=/etc/init.d/tomcat8 start (code=exited, status=1/FAILURE)

Jul 16 15:06:15 srv016 systemd[1]: Starting LSB: Start Tomcat....
Jul 16 15:06:15 srv016 tomcat8[34835]: * Starting Tomcat servlet engine tomcat8
Jul 16 15:06:20 srv016 tomcat8[34835]: ...fail!
Jul 16 15:06:20 srv016 systemd[1]: tomcat8.service: Control process exited, code=exited status=1
Jul 16 15:06:20 srv016 systemd[1]: Failed to start LSB: Start Tomcat..
Jul 16 15:06:20 srv016 systemd[1]: tomcat8.service: Unit entered failed state.
Jul 16 15:06:20 srv016 systemd[1]: tomcat8.service: Failed with result 'exit-code'.
dpkg: error processing package tomcat8 (--configure):
subprocess installed post-installation script returned error exit status 1
Processing triggers for ureadahead (0.100.0-19.1) ...
Processing triggers for systemd (229-4ubuntu21.21) ...
Errors were encountered while processing:
tomcat8
E: Sub-process /usr/bin/dpkg returned an error code (1)

[Standeman]

Draait Tomcat7 nog? Mogelijk klaagt Tomcat8 omdat Tomcat7 de poorten bezet houdt. Staar er iets in de catalina.out?

[be3a18]

Standeman schreef op dinsdag 16 juli 2019 @ 15:12:
Draait Tomcat7 nog? Mogelijk klaagt Tomcat8 omdat Tomcat7 de poorten bezet houdt. Staar er iets in de catalina.out?

Zo te zien wel, ik kan de webapplicatie die moet worden bijgewerkt nog gewoon starten.

In catalina.out van tomcat7 staat voor zover ik kan zien geen rare dingen.

In catalina.out van tomcat8 staat behalve een paar warnings oa:

SEVERE: Failed to initialize end point associated with ProtocolHandler ["http-nio-8080"]
java.net.BindException: Address already in use

Het lijkt er dus op dat Tomcat 7 de poort in gebruik heeft (zoals je al zei).

Ik ga Tomcat7 stoppen en dan eens kijken of Tomcat8 wel wil starten.

[ Voor 6% gewijzigd door be3a18 op 16-07-2019 15:40 ]

[be3a18]

Ik heb Tomcat 8 nu werkend. De nieuwe versie van de webapplicatie wordt nu ook geïnstalleerd. Het lijkt erop dat de software werl wordt bijgewerkt (ik krijg het nieuwe inlogscherm) maar ik kan er niet op inloggen.

Dat is volgens mij een configuratie probleem van die software.

Tot zover bedankt voor de tips.

[Hero of Time]

Dat zal in de documentatie van die applicatie staan waar het wordt opgeslagen. Je zou dan de bestanden die de applicatie heeft gemaakt overnemen vanuit de tomcat 7 omgeving. Scheelt mogelijk weer handmatig zaken invoeren.

[be3a18]

Hero of Time schreef op dinsdag 16 juli 2019 @ 16:46:
Dat zal in de documentatie van die applicatie staan waar het wordt opgeslagen. Je zou dan de bestanden die de applicatie heeft gemaakt overnemen vanuit de tomcat 7 omgeving. Scheelt mogelijk weer handmatig zaken invoeren.

Dat idee had ik, ga ik even proberen.

[Standeman]

be3a18 schreef op dinsdag 16 juli 2019 @ 15:24:
[...]


Zo te zien wel, ik kan de webapplicatie die moet worden bijgewerkt nog gewoon starten.

In catalina.out van tomcat7 staat voor zover ik kan zien geen rare dingen.

In catalina.out van tomcat8 staat behalve een paar warnings oa:

SEVERE: Failed to initialize end point associated with ProtocolHandler ["http-nio-8080"]
java.net.BindException: Address already in use

Het lijkt er dus op dat Tomcat 7 de poort in gebruik heeft (zoals je al zei).

Ik ga Tomcat7 stoppen en dan eens kijken of Tomcat8 wel wil starten.

Dat is inderdaad het probleem, port 8080 was bezet en dan wil tomcat niet opstarten.

En voor inlogproblemen kan je het beste weer die catalina.out bekijken (of specifieke applicatie-logfiles). Daar zal de reden wel instaan. Mogelijk moeten er nog datasources/https geconfigureerd worden in tomcat 8. Dat kan je controleren door in de server.xml te kijken van tomcat 7.

[be3a18]

Even een follow up. Ik heb het .war bestand van de applicatie in de directory /var/lib/tomcat8/webapps neer gezet en dit wordt daarna keurig uitgepakt/geïnstalleerd. Het lijkt mij dat Tomcat gewoon draait. Als ik /usr/share/tomcat8/bin/startup.sh krijg ik ook de melding dat Tomcat gestart is (ik moest wel eerst de subdirectory logs aanmaken voor catalina.out). Desondanks staat er in catalina.out het volgende (en met name de laatste regel).

root@srv016:/usr/share/tomcat8/logs# cat catalina.out
Jul 17, 2019 9:45:51 AM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat8/common/classes], exists: [false], isDirectory: [false], canRead: [false]
Jul 17, 2019 9:45:52 AM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat8/common], exists: [false], isDirectory: [false], canRead: [false]
Jul 17, 2019 9:45:52 AM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat8/server/classes], exists: [false], isDirectory: [false], canRead: [false]
Jul 17, 2019 9:45:52 AM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat8/server], exists: [false], isDirectory: [false], canRead: [false]
Jul 17, 2019 9:45:52 AM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat8/shared/classes], exists: [false], isDirectory: [false], canRead: [false]
Jul 17, 2019 9:45:52 AM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat8/shared], exists: [false], isDirectory: [false], canRead: [false]
Jul 17, 2019 9:45:52 AM org.apache.catalina.startup.Catalina initDirs
SEVERE: Cannot find specified temporary folder at /usr/share/tomcat8/temp
Jul 17, 2019 9:45:52 AM org.apache.catalina.startup.Catalina load
WARNING: Unable to load server configuration from [/usr/share/tomcat8/conf/server.xml]
Jul 17, 2019 9:45:52 AM org.apache.catalina.startup.Catalina initDirs
SEVERE: Cannot find specified temporary folder at /usr/share/tomcat8/temp
Jul 17, 2019 9:45:52 AM org.apache.catalina.startup.Catalina load
WARNING: Unable to load server configuration from [/usr/share/tomcat8/conf/server.xml]
Jul 17, 2019 9:45:52 AM org.apache.catalina.startup.Catalina start
SEVERE: Cannot start server. Server instance is not configured.
Jul 17, 2019 9:55:02 AM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat8/common/classes], exists: [false], isDirectory: [false], canRead: [false]
Jul 17, 2019 9:55:02 AM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat8/common], exists: [false], isDirectory: [false], canRead: [false]
Jul 17, 2019 9:55:02 AM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat8/server/classes], exists: [false], isDirectory: [false], canRead: [false]
Jul 17, 2019 9:55:02 AM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat8/server], exists: [false], isDirectory: [false], canRead: [false]
Jul 17, 2019 9:55:02 AM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat8/shared/classes], exists: [false], isDirectory: [false], canRead: [false]
Jul 17, 2019 9:55:02 AM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat8/shared], exists: [false], isDirectory: [false], canRead: [false]
Jul 17, 2019 9:55:02 AM org.apache.catalina.startup.Catalina initDirs
SEVERE: Cannot find specified temporary folder at /usr/share/tomcat8/temp
Jul 17, 2019 9:55:02 AM org.apache.catalina.startup.Catalina load
WARNING: Unable to load server configuration from [/usr/share/tomcat8/conf/server.xml]
Jul 17, 2019 9:55:02 AM org.apache.catalina.startup.Catalina initDirs
SEVERE: Cannot find specified temporary folder at /usr/share/tomcat8/temp
Jul 17, 2019 9:55:02 AM org.apache.catalina.startup.Catalina load
WARNING: Unable to load server configuration from [/usr/share/tomcat8/conf/server.xml]
Jul 17, 2019 9:55:02 AM org.apache.catalina.startup.Catalina start
SEVERE: Cannot start server. Server instance is not configured.
Jul 17, 2019 9:58:54 AM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat8/common/classes], exists: [false], isDirectory: [false], canRead: [false]
Jul 17, 2019 9:58:54 AM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat8/common], exists: [false], isDirectory: [false], canRead: [false]
Jul 17, 2019 9:58:54 AM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat8/server/classes], exists: [false], isDirectory: [false], canRead: [false]
Jul 17, 2019 9:58:54 AM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat8/server], exists: [false], isDirectory: [false], canRead: [false]
Jul 17, 2019 9:58:54 AM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat8/shared/classes], exists: [false], isDirectory: [false], canRead: [false]
Jul 17, 2019 9:58:54 AM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat8/shared], exists: [false], isDirectory: [false], canRead: [false]
Jul 17, 2019 9:58:54 AM org.apache.catalina.startup.Catalina load
WARNING: Unable to load server configuration from [/usr/share/tomcat8/conf/server.xml]
Jul 17, 2019 9:58:54 AM org.apache.catalina.startup.Catalina load
WARNING: Unable to load server configuration from [/usr/share/tomcat8/conf/server.xml]
Jul 17, 2019 9:58:54 AM org.apache.catalina.startup.Catalina start
SEVERE: Cannot start server. Server instance is not configured.

(in de Tomcat7 situatie is er een symbolic link in /var/lib/tomcat7 die verwijst naar /etc/tomcat7)

[Standeman]

Zijn die paden aanwezig of niet?

optie 1: De user waaronder tomcat8 draait mag nergens bij. Controleer de rechten.
optie 2: De install is halverwege een keer afgebroken en je mist een hele hoop bestanden / symbolic links. Als ik jou was zou ik alles weggooien en een re-install doen.

[be3a18]

Standeman schreef op woensdag 17 juli 2019 @ 10:43:
Zijn die paden aanwezig of niet?

optie 1: De user waaronder tomcat8 draait mag nergens bij. Controleer de rechten.
optie 2: De install is halverwege een keer afgebroken en je mist een hele hoop bestanden / symbolic links. Als ik jou was zou ik alles weggooien en een re-install doen.

Het vreemde is dat de webapplicatie gewoon werkt. Ik ga sowieso even controleren welke paden die gebruikt.
.

[Standeman]

be3a18 schreef op woensdag 17 juli 2019 @ 10:50:
[...]


Het vreemde is dat de webapplicatie gewoon werkt. Ik ga sowieso even controleren welke paden die gebruikt.
.

Lijkt me ergens stug, de server is niet eens gestart:

code:

SEVERE: Cannot start server. Server instance is not configured.

Heb je environment variableen zoals $CATALINA_HOME ook aangepast?

[ Voor 8% gewijzigd door Standeman op 17-07-2019 11:41 ]

[be3a18]

Standeman schreef op woensdag 17 juli 2019 @ 11:37:
[...]

Lijkt me ergens stug, de server is niet eens gestart:

code:

SEVERE: Cannot start server. Server instance is not configured.

Heb je environment variableen zoals $CATALINA_HOME ook aangepast?

De webapp doet het gewoon, deze informatie krijg ik bij de server informatie:


Java
Java-versie:
1.8
Java-runtime-versie:
1.8.0_212-8u212-b03-0ubuntu1.16.04.1-b03
JVM Naam:
OpenJDK 64-Bit Server VM
JVM publisher:
Oracle Corporation
JVM gestart:
Jul 16, 2019 4:57:26 PM
JVM argumenten:
-Djava.util.logging.config.file=/var/lib/tomcat8/conf/logging.properties

-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

-Djava.awt.headless=true

-Xmx128m

-XX:+UseConcMarkSweepGC

-Djava.endorsed.dirs=/usr/share/tomcat8/endorsed

-Dcatalina.base=/var/lib/tomcat8

-Dcatalina.home=/usr/share/tomcat8

-Djava.io.tmpdir=/tmp/tomcat8-tomcat8-tmp (deze regel is specifiek voor de applicatie)

[Hero of Time]

be3a18 schreef op woensdag 17 juli 2019 @ 10:08:
Even een follow up. Ik heb het .war bestand van de applicatie in de directory /var/lib/tomcat8/webapps neer gezet en dit wordt daarna keurig uitgepakt/geïnstalleerd. Het lijkt mij dat Tomcat gewoon draait. Als ik /usr/share/tomcat8/bin/startup.sh krijg ik ook de melding dat Tomcat gestart is

En daar ga je wéér de fout in. Je moet niet handmatig dat script starten. Dat is volgen wat er in de documentatie op de Tomcat site staat voor als je 'm zelf ergens neer gooit. De distro geleverde versie werkt zo niet. Dat gaat met init scripts. Of in jouw geval systemd units.

Wie heeft de server oorspronkelijk opgezet met alles? Is die nog werkzaam in het bedrijf? Want aan je handelingen maak ik uit dat je praktisch geen ervaring hebt met Linux en net zo veel over Tomcat weet. Dat is niet erg, maar het is onverstandig hoe je nu bezig bent.

Het is sterk aan te raden om iemand met Linux kennis en ervaring naast je te hebben om uit te leggen hoe zaken geregeld dienen te worden. Zelf meer leren over Linux is ook verstandig. Dat zal in de toekomst een hoop problemen voorkomen.

[be3a18]

Dat van die kennis klopt wel. Maar ik leer snel.

De server is tijden geleden ingericht en door iemand anders. Onderstaande is de inhoud van /etc/systemd/system.

root@srv016:/etc/systemd/system# ll
total 56
drwxr-xr-x 14 root root 4096 Jun 8 2018 ./
drwxr-xr-x 5 root root 4096 Apr 10 06:54 ../
drwxr-xr-x 2 root root 4096 Jun 8 2018 cloud-final.service.wants/
drwxr-xr-x 2 root root 4096 Oct 7 2016 default.target.wants/
drwxr-xr-x 2 root root 4096 Apr 4 2017 final.target.wants/
drwxr-xr-x 2 root root 4096 Oct 7 2016 getty.target.wants/
drwxr-xr-x 2 root root 4096 Oct 7 2016 graphical.target.wants/
lrwxrwxrwx 1 root root 38 Oct 7 2016 iscsi.service -> /lib/systemd/system/open-iscsi.service
drwxr-xr-x 2 root root 4096 Aug 28 2018 multi-user.target.wants/
drwxr-xr-x 2 root root 4096 Oct 7 2016 network-online.target.wants/
drwxr-xr-x 2 root root 4096 Jun 8 2018 open-vm-tools.service.requires/
drwxr-xr-x 2 root root 4096 Oct 7 2016 paths.target.wants/
drwxr-xr-x 2 root root 4096 Oct 7 2016 sockets.target.wants/
lrwxrwxrwx 1 root root 31 Oct 7 2016 sshd.service -> /lib/systemd/system/ssh.service
drwxr-xr-x 2 root root 4096 Nov 9 2018 sysinit.target.wants/
lrwxrwxrwx 1 root root 35 Oct 7 2016 syslog.service -> /lib/systemd/system/rsyslog.service
drwxr-xr-x 2 root root 4096 Nov 24 2017 timers.target.wants/

Ik ben daar door heen gegaan maar kwam niks tegen wat Tomcat7 start.

In /etc/init.d is zowel een tomcat7 als tomcat8 entry. Met ps -ef | grep tomcat kan ik zien dat alleen Tomcat7 draait.

Hoe pas ik het aan dat Tomcat8 gebruikt wordt?

[Hero of Time]

Tijd om in te lezen over systemd. Service bestanden staan in /lib/systemd/system. Eigen gemaakte units en aanpassingen aan die met packages mee komen horen in /etc/systemd/system. Kijk maar eens met 'systemctl status tomcat7' wat je ziet. Doe hetzelfde met 'systemctl status tomcat8'. Als voorbeeld ssh:

code:

$ systemctl status sshd
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2019-07-12 11:31:35 CEST; 5 days ago
     Docs: man:sshd(8)
           man:sshd_config(5)
  Process: 596 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
 Main PID: 655 (sshd)
    Tasks: 1 (limit: 4915)
   Memory: 4.9M
   CGroup: /system.slice/ssh.service
           └─655 /usr/sbin/sshd -D

Jul 12 11:31:35 $hostname systemd[1]: Starting OpenBSD Secure Shell server...
Jul 12 11:31:35 $hostname sshd[655]: Server listening on 0.0.0.0 port 22.
Jul 12 11:31:35 $hostname sshd[655]: Server listening on :: port 22.
Jul 12 11:31:35 $hostname systemd[1]: Started OpenBSD Secure Shell server.

Snel leren is leuk, maar daar heb je nu, op dit moment, niets aan want je heb geen kennis om degelijk verder te gaan. Dat zal je eerst moeten bijspijkeren en dat is niet met een uurtje gedaan.

[be3a18]

Duidelijk, dit levert het volgende op:

root@srv016:/etc/init.d# systemctl status tomcat7
● tomcat7.service - LSB: Start Tomcat.
Loaded: loaded (/etc/init.d/tomcat7; bad; vendor preset: enabled)
Active: active (running) since Wed 2019-07-17 15:40:55 CEST; 42min ago
Docs: man:systemd-sysv-generator(
Process: 1340 ExecStart=/etc/init.d/tomcat7 start (code=exited, status=0/SUCCESS)
Tasks: 18
Memory: 86.4M
CPU: 5.025s
CGroup: /system.slice/tomcat7.service
└─1460 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Djava.util.logging.config.file=/var/lib/tomcat7/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.awt.headless=true -Xmx1280m -XX:+UseConcMarkSweepGC -Dfile.encoding=UTF-8 -Djava.endorsed.dirs=/usr/share/tomc

Jul 17 15:40:49 srv016 systemd[1]: Starting LSB: Start Tomcat....
Jul 17 15:40:50 srv016 tomcat7[1340]: * Starting Tomcat servlet engine tomcat7
Jul 17 15:40:55 srv016 tomcat7[1340]: ...done.
Jul 17 15:40:55 srv016 systemd[1]: Started LSB: Start Tomcat..
root@srv016:/etc/init.d# systemctl status tomcat8
● tomcat8.service - LSB: Start Tomcat.
Loaded: loaded (/etc/init.d/tomcat8; bad; vendor preset: enabled)
Active: active (exited) since Wed 2019-07-17 15:40:55 CEST; 42min ago
Docs: man:systemd-sysv-generator(
Process: 1326 ExecStart=/etc/init.d/tomcat8 start (code=exited, status=0/SUCCESS)
Tasks: 0
Memory: 0B
CPU: 0

Jul 17 15:40:49 srv016 systemd[1]: Starting LSB: Start Tomcat....
Jul 17 15:40:50 srv016 tomcat8[1326]: * Starting Tomcat servlet engine tomcat8
Jul 17 15:40:55 srv016 tomcat8[1326]: ...done.
Jul 17 15:40:55 srv016 systemd[1]: Started LSB: Start Tomcat..

Ik ga toch bezig/verder met bijspijkeren, dat ontlast ook een collega.

[0xDEADBEEF]

spoiler:

systemctl disable tomcat7.service
systemctl enable tomcat8.service

[Verwijderd]

Hero of Time schreef op dinsdag 16 juli 2019 @ 14:52:
Ik raad je toch aan om naar je distro te kijken voor tomcat 8. Je krijgt dan ook updates als die er zijn ipv dat je dit zelf bij moet gaan houden en installeren.

Je zegt nergens specifiek welke distro je hebt, maar toevallig wordt dit in de versie informatie getoond van Java. Dat zegt dat je Ubuntu 16.04 draait. Is het niet handiger om de server opnieuw in te richten met 18.04 en tomcat 8?
Al heeft 16.04 die ook gewoon als ik https://packages.ubuntu.com/search?keywords=tomcat8 moet geloven. Dus, waarom heb je niet simpelweg 'apt-get install tomcat8' gedaan?

Dat zou ik afraden. Distro's lopen vaak gigantisch achter als het om updates voor Tomcat gaat.

Het is overigens een kleine moeite om een scriptje bouwen die voor jou een upgrade doet naar een nieuwe Tomcat versie.

Ik zou kijken in ./logs/catalina.log of er nog iets van bijzonderheden staan die te maken hebben met Tomcat.


Je weet dat de webapp geplaatst moet worden in webapps

Leer je ook gelijk hoe je moet scripten in Bash.

[Hero of Time]

Verwijderd schreef op donderdag 5 september 2019 @ 16:58:
[...]

Dat zou ik afraden. Distro's lopen vaak gigantisch achter als het om updates voor Tomcat gaat.

Dan weet je niet wat de package maintainers van distro's zoal doen. Die backporten juist security fixes. Leuk dat je versienummer 10 minors achter loopt, alleen een domme security check gaat daarvan over de zeik. Maar als je zo'n toko hebt, moet je de rest van de scans die ze doen ook niet serieus nemen. Een versienummer zegt geen drol.

Je draait een LTS voor een reden. Er zit gewoon support op en je krijgt nog regelmatig updates voor security issues. Je hebt tevens de garantie dat het na een update nog gewoon blijft werken. Plus dat je updates met de rest van het systeem mee komt ipv dat je zelf moet bijhouden of er een update is van Tomcat die je dan weer met de hand moet gaan bijwerken.

Het is overigens een kleine moeite om een scriptje bouwen die voor jou een upgrade doet naar een nieuwe Tomcat versie.

Als je wilt hobbybobben, prima, maar ga dat aub niet in een bedrijfsomgeving doen. Als je er op deze manier al over denkt voor Tomcat, zal je zeker Arch of Gentoo als productieservers draaien? En services zoals Tomcat start je zeker met een nohup vanuit cron @reboot, of neem je toch wel de moeite om een fatsoenlijke systemd unit te schrijven? Want die komt niet mee als je 'm van de site plukt.


Als je een topic onnodig wilt kicken, doe het dan met een goede reden. Niet met 'advies' wat alleen maar meer gedoe op gaat leveren.

[Verwijderd]

Hero of Time schreef op donderdag 5 september 2019 @ 19:02:
[...]

Dan weet je niet wat de package maintainers van distro's zoal doen. Die backporten juist security fixes. Leuk dat je versienummer 10 minors achter loopt, alleen een domme security check gaat daarvan over de zeik. Maar als je zo'n toko hebt, moet je de rest van de scans die ze doen ook niet serieus nemen. Een versienummer zegt geen drol.

Dat weet ik wel. Want iedere distro kiest zijn patches. En dat maakt het echt niet veiliger op. In tegendeel.

Je draait een LTS voor een reden. Er zit gewoon support op en je krijgt nog regelmatig updates voor security issues. Je hebt tevens de garantie dat het na een update nog gewoon blijft werken. Plus dat je updates met de rest van het systeem mee komt ipv dat je zelf moet bijhouden of er een update is van Tomcat die je dan weer met de hand moet gaan bijwerken.

Het met de hand updaten van Tomcat is bijna letterlijk plug-and-play. En de code is rete-stabiel. De kans dat er 'iets' gebeurd is heel klein. Die kans acht ik groter met distro-specifieke aanpassingen waarvan je mag hopen dat het goed doorgevoerd en getest is. Of een update die maar niet doorgevoerd wordt omdat je op *Tada* LTS zit.

LTS niet zaligmakend voor zaken zoals Tomcat en HTTPd waar je zo recent mogelijk (maar niet de allernieuwste) wil zitten als het gaat om security. Waar jij het over hebt als je in de situatie zit dat stabiliteit een hogere noodzaak is. Dan is LTS wenselijk.

Als je wilt hobbybobben, prima, maar ga dat aub niet in een bedrijfsomgeving doen. Als je er op deze manier al over denkt voor Tomcat, zal je zeker Arch of Gentoo als productieservers draaien? En services zoals Tomcat start je zeker met een nohup vanuit cron @reboot, of neem je toch wel de moeite om een fatsoenlijke systemd unit te schrijven? Want die komt niet mee als je 'm van de site plukt.

Je overdrijft wel heel erg vind je niet? Of wordt je al zenuwachtig van nieuwe versie van VIM? Kreeg je maagkrampen toen je over moest naar Systemd?

Het punt is en blijft dat je moet experimenteren anders leer je niet. Ik ga er dan ook vanuit dat TS daarin de mogelijkheden heeft. En afgezien van de situatie is het voor een junior zoals TS met de hand deployen van een Tomcat server een uitgelezen kans om daar meer kennis over op te doen van bepaalde aspecten die niet alleen te maken met het product maar verbreding van kennis van het beheerwerk. Die server heeft hij vast onder zijn hoede gekregen met het idee 'schaadt het niet dan baat het niet'.

Heeeeeel soms moet je jezelf durven te verplaatsen in de vraagsteller en verder te kijken dan wat er initieel gevraagd wordt.

Als je een topic onnodig wilt kicken, doe het dan met een goede reden. Niet met 'advies' wat alleen maar meer gedoe op gaat leveren.

En dat doe ik. Dat jij zo obstinaat erop reageert is jouw probleem. Ik ben er iig niet van onder de indruk. Als jij dat wel bent dan zal je daar vast een knop voor hebben.

[_JGC_]

Je reageert in een topic van iemand die hulp nodig heeft om tomcat7 naar 8 te upgraden.
Mijn ervaring met software uit tarballs op systemen beheerd door leken is dat het eenmalig geplaatst wordt en pas weer aangeraakt wordt na een hack.

Wat betreft "distro's kiezen zelf de patches", upstream kiest zelf het releasebeleid. Sommige software komt met kritieke bugs in een release, om vervolgens een paar maand te wachten met een nieuwe versie terwijl de fix in git of svn zit (apache!)

Overigens wordt in een distro niet alles gebackport, in geval van mysql en postgresql wordt gewoon een minor version upgrade gedaan.

[Verwijderd]

_JGC_ schreef op vrijdag 6 september 2019 @ 00:51:
Je reageert in een topic van iemand die hulp nodig heeft om tomcat7 naar 8 te upgraden.
Mijn ervaring met software uit tarballs op systemen beheerd door leken is dat het eenmalig geplaatst wordt en pas weer aangeraakt wordt na een hack.

Dat is helaas niet alleen zo bij tarballs, dat is een algemeen probleem (icm falend IT beleid).
Onbekend maakt ook onbemind.

Daarom is het automatiseren van het uitrollen van nieuw stuk software ook essentiele kennis die opgedaan moet worden. Laat dit nu een perfect moment zijn om die kennis op te doen.

Wat betreft "distro's kiezen zelf de patches", upstream kiest zelf het releasebeleid. Sommige software komt met kritieke bugs in een release, om vervolgens een paar maand te wachten met een nieuwe versie terwijl de fix in git of svn zit (apache!)

Overigens wordt in een distro niet alles gebackport, (...)

Dat is ook een van de redenen waarom je niet van alle stukken software afhankelijk moet willen zijn van een distro. LTS, paid support, what so ever in die trant, is niet zaligmakend.

[Hero of Time]

Verwijderd schreef op vrijdag 6 september 2019 @ 00:03:
[...]

Het met de hand updaten van Tomcat is bijna letterlijk plug-and-play. En de code is rete-stabiel. De kans dat er 'iets' gebeurd is heel klein.

Mijn ervaring is anders het tegenovergestelde. Een tarball gebruikte Tomcat moest niet alleen elke keer handmatig gestart worden omdat het geen init bestanden mee leverde zodat het met het systeem opstartte zodat je er geen omkijken naar had na een reboot, het was ook uiterst onstabiel en moest dus met regelmaat herstart worden. Vanaf het moment dat ik de distro versie gebruikte, was de applicatie vele malen stabieler, kon ik blind de server herstarten en Tomcat werd gestart en herstarten kon iedereen, ipv dat je als de specifieke gebruiker in moest loggen om 't maar te laten werken en geen gedoe te hebben met rechten. De audit trail was hiermee ook gelijk verzorgt, want je wist precies wie wat had gedaan ipv 'iemand' omdat er gebruik gemaakt wordt van algemene accounts.

Als je bedrijf tevens zelf een Tomcat applicatie maakt, wil je consistentie en voorspelbaarheid. Je wilt niet dat de webapp opeens niet meer functioneert omdat er tussentijds een nieuwere Tomcat erop is gegooit. Zal het bedrijf blij mee zijn, een beheerder die afhankelijkheden bijwerkt voordat het is afgestemd met de ontwikkelaars en zo een kritieke applicatie sloopt.

[_JGC_]

@Hero of Time Welkom in de wereld van gepruts en gekloot. Als het niet klanten zijn die hun server "beheren" met DirectAdmin en CustomBuild, is het wel Plesk die bij elke klik in het panel de hele config verkloot en anders zijn het wel beheerders die zooi uit source compilen.

Geef mij maar gewoon Debian 9/10 of Ubuntu LTS. Als er bijvoorbeeld de wens is om altijd de nieuwste PHP en Apache te draaien zijn daar hele mooie repositories voor, beheerd door mensen die weten wat ze doen (Ondřej Surý is Debian PHP maintainer en onderhoudt voor elke ondersteunde versie van Debian en Ubuntu een repository met een grote keuze aan PHP versies, naastelkaar te gebruiken).

[Hero of Time]

_JGC_ schreef op vrijdag 6 september 2019 @ 10:16:
@Hero of Time Welkom in de wereld van gepruts en gekloot. Als het niet klanten zijn die hun server "beheren" met DirectAdmin en CustomBuild, is het wel Plesk die bij elke klik in het panel de hele config verkloot en anders zijn het wel beheerders die zooi uit source compilen.

Precies mijn gedachte. Zulke panels slopen meer dan je lief is. Handig voor hen die geen ervaring hebben, maar een ware nachtmerrie voor de meer ervaren beheerder.

Geef mij maar gewoon Debian 9/10 of Ubuntu LTS. Als er bijvoorbeeld de wens is om altijd de nieuwste PHP en Apache te draaien zijn daar hele mooie repositories voor, beheerd door mensen die weten wat ze doen (Ondřej Surý is Debian PHP maintainer en onderhoudt voor elke ondersteunde versie van Debian en Ubuntu een repository met een grote keuze aan PHP versies, naast elkaar te gebruiken).

Jep, dat heeft ook m'n voorkeur. Nette packages, gebruiken de distro libraries ipv zelf meeleveren wat weer gedoe geeft.
Als het moet, doe het dan goed. Neem dat wat iemand met echt verstand van packages heeft gemaakt.

[Verwijderd]

Hero of Time schreef op vrijdag 6 september 2019 @ 09:39:
[...]

Mijn ervaring is anders het tegenovergestelde. Een tarball gebruikte Tomcat moest niet alleen elke keer handmatig gestart worden omdat het geen init bestanden mee leverde zodat het met het systeem opstartte zodat je er geen omkijken naar had na een reboot, het was ook uiterst onstabiel en moest dus met regelmaat herstart worden. Vanaf het moment dat ik de distro versie gebruikte, was de applicatie vele malen stabieler, kon ik blind de server herstarten en Tomcat werd gestart en herstarten kon iedereen, ipv dat je als de specifieke gebruiker in moest loggen om 't maar te laten werken en geen gedoe te hebben met rechten. De audit trail was hiermee ook gelijk verzorgt, want je wist precies wie wat had gedaan ipv 'iemand' omdat er gebruik gemaakt wordt van algemene accounts.

Tomcat is 'slechts' een Java container waar in het beginsel weinig fout aan kan gaan. Als de officiële versie voor jou niet werkt maar de distro versie wel dan heeft het meer met de default instellingen te maken (Memory settings bij distroversie zijn vaak ingesteld
om alle aanwezige geheugen te gebruiken wat niet altijd even gewenst bij bepaalde apps) dan waar het vandaan komt. Dat is ook waarschijnlijk ook de reden geweest waarom het vastliep bij de tarball versie.

De wijze van herstartbaarheid is maar net waarvoor je kiest. Uiteindelijk is het niet spannend om een unitfile te maken die wijst naar een algemene locatie, wat weer een softlink is naar de specifieke versie van Tomcat.

Als je bedrijf tevens zelf een Tomcat applicatie maakt, wil je consistentie en voorspelbaarheid. Je wilt niet dat de webapp opeens niet meer functioneert omdat er tussentijds een nieuwere Tomcat erop is gegooit. Zal het bedrijf blij mee zijn, een beheerder die afhankelijkheden bijwerkt voordat het is afgestemd met de ontwikkelaars en zo een kritieke applicatie sloopt.

Dan zou ik juist voor een Tarball kiezen omdat je er juist niet op zit te wachten dat een distro vóór jou gaat bepalen wanneer een bepaalde versie wel of niet meer beschikbaar is binnen een bepaalde major versie van de distro. En daarbij jou verplicht om een bepaalde versie te installeren.

[CAPSLOCK2000]

Als we er dan toch een principiele discussie van maken wil ik er nog wel even over heen gaan
Ik stel mijzelf de vragen:
- Heb ik de tijd en kennis om het beter te doen dan package-beheerder van de distributie?
- Kost het meer tijd/moeite om te leven met beperkingen van de oude versie dan omgaan met de configuratie van en de bugs in de nieuwe versie? Zaken als een goed init-script spelen daarbij een rol.

Als het om belangrijke software gaat waar ik veel kennis van heb dan kan ik dat pakket misschien beter zelf beheren.

Maar iedereen kan maar op een paar gebieden expert zijn. Van 99% van de software op het systeem heb ik specifieke kennis. 99% van de software is eigenlijk ook niet interessant. Dan laat ik het werk graag over aan de beheerder van de distributie. In zo'n geval vind ik het helemaal prima dat die beheerder voor mij kiest welke versie ik ga draaien, ik heb niet de informatie om meer te zeggen dan "de nieuwste versie zal wel beter zijn".

Persoonlijk installeer ik Tomcat uit distributie-packages. Ik zie geen voordeel in de upstream versie te gebruiken, voor de beperkte dingen die ik er mee doe. Wat ik er van wil werkt goed genoeg met een wat oudere versie. Debian zorgt dat ik een stabiel platform heb om op te werken. Debian zal nooit zomaar een nieuwe major version installeren maar garandeert juist dat de API stabiel blijft en je applicatie blijft werken.

Update-procecures zijn voor mij ook erg belangrijk. Ik moet regelmatig patchen. Ieder maand met de hand commando's draaien of 6 verschillende update-systemen gebruiken kost te veel tijd, en ik heb niet de tijd om me in al die systemen te specialiseren. Dan vertrouw ik liever op een distributie.