Tomcat + Apache2 auf Debian

Wär doch toll wenn man die Anwendungen die auf dem Tomcat laufen würden auch über den normalen 80er Zugriff erreichen könnte. Apache mod_jk machts möglich!

Aus Zwei mach Eins

Da ich gerade meinen Heimserver um diverse Entwickler Tools aufstocken möchte (Jenkins, Sonar, Nexus) musste erstmal ein Servlet-Container her: Tomcat
Port 80 ist bereits freigegeben und eigentlich nervt mich das Portgetippe (eh schon wissen: localhost:8080) beim URL Aufruf ziemlich. Wär doch toll wenn man die Anwendungen die auf dem Tomcat laufen würden auch über den normalen 80er Zugriff erreichen könnte, oder?

Naja, dann ran ans Eingemachte!

Installation Tomcat

Java

So noch nicht geschehen sollte sinnvollerweise eine Java Installation am Server vorhanden sein

# apt-get install openjdk-6-jre

Wer auf dem Server auch Programme compiliern will besorgt sich ein jdk. Für die Installatin von Java 7 verweise ich auf einen ausgezeichneten Blog Beitrag von SysadminsLife

Download und Installation

Auf der Tomcat Seite die gewünschte Version (im Falle des Tutorials die neueste 7.0) mit wget herunterladen und entpacken

# tar xvfz apache-tomcat-7.0.35.tar.gz

danach an eine passende Stelle verschieben /opt/tomcat

# mv apache-tomcat-7.0.35 /opt/tomcat

Zum Abschluss noch die Scripts ausführbar machen

# chmod +x /opt/tomcat/bin/*.sh

Tomcat User und Gruppe

# groupadd tomcat
# useradd -g tomcat -d /opt/tomcat tomcat
# usermod -G www-data tomcat
# chown tomcat:tomcat /opt/tomcat -R

Tomcat Startup Script

Unter /etc/init.d/tomcat wird das Tomcat 7 Script von collinpeters abgespeichert (Oh ja, Github rulez! Und gist erst recht – Danke für das schöne Script!)

Natürlich muss das Script noch ausführbar gemacht werden und es soll automatisch starten

# chmod +x /etc/init.d/tomcat
# update-rc.d tomcat defaults

Tomcat Server User

Tomcat will auch abgesichert sein, zumindest ein bisschen. Daher legen wir einen Benutzer für die Admin und Manager Webapps an. Unter /opts/tomcat/conf/tomcat-users.xml ist folgendes zu ergänzen

<tomcat-users>
    <role rolename="manager" />
    <role rolename="manager-gui" />
    <role rolename="admin"/>
    <role rolename="admin-gui"   />
    <user username="USER" password="PASSWORT"
     roles="admin,admin-gui,manager,manager-gui" />
</tomcat-users>

Bitte USER und PASSWORT durch eure Werte ersetzen.

Start und Test

Es wär alles für die Katz würden wir es nicht auch testen. Dafür starten wir das Service

# /etc/init.d/tomcat start

Nun sollte Tomcat unter http://<server-ip>:8080 erreichbar sein.

Installation mod_jk Apache connector

apt-get

Wie immer, als erstes ist das Package zu installieren:

# apt-get install libapache2-mod-jk

Dieses Apache Modul dient als Brücke zwischen dem Webserver und Tomcat

mod_jk Konfiguration

Mit ein paar Zeilen unter /etc/apache2/conf.d/jk.conf wird mod_jk konfiguriert

<ifmodule mod_jk.c>
    JkWorkersFile /etc/apache2/workers.properties
    JkLogFile /var/log/apache2/mod_jk.log
    JkLogLevel error
</ifmodule>

mod_jk Worker

Apache benötigt nun noch eine Konfiguration in der festgehalten wird wie er einen Request auf Tomcat umleitet

Unter /etc/apache2/workers.properties legen wir daher folgende Konfiguratino ab

workers.tomcat_home=/opt/tomcat
workers.java_home=/usr/lib/jvm/java-6-openjdk
ps=/
worker.list=default
worker.default.port=8009
worker.default.host=localhost
worker.default.type=ajp13
worker.default.lbfactor=1

sites-available

Nun muss Apache nur noch erfahren welche Requests er an Tomcat weiterleiten soll. Dazu fügen wir in /etc/apache2/sites-available/default JkMount Zuordnungen ein. Im Falle der Tomcat Manager Applikation wären das folgende Zeilen 8 und 9

<VirtualHost *>
ServerAdmin root@localhost
ServerAlias homeserver

DocumentRoot /var/www/
# weitere Konfiguration

JkMount /manager default
JkMount /manager/* default

</VirtualHost>

Test

Nun muss Apache natürlich neu gestartet werden:

# /etc/init.d/tomcat restart

Das wars, nun sollte unter http://<server-ip>/manager die erste Weiterleitung auf den Tomcat sichtbar sein!

Viel Spaß damit!

Ähnliche Artikel:

Mit Bash prüfen ob das eigene Script gerade läuft

Die Problemstellung

Ein Script soll alle x Minuten laufen und eine bestimmte Tätigkeit auf dem Server ausführen.

Nun kann es vorkommen, dass das Script aber länger braucht als die Zeitspanne bis zum nächsten Aufruf desselben Scripts (z.B. Kopier und Backup Jobs, Mails abholen, …)

Natürlich sollte so ein Script dann nicht ein 2tes Mal gestartet werden sondern die Ausführung übersprungen werden. Zu diesem Zweck möchte ich hier ein kleines Bash Script zeigen, das genau diesen Zweck erfüllt.

Die Lösung

#!/bin/bash
#
# testpid.sh - demo script to show how to check if a script
# with the same name is currently running
#
# by Leo Eibler
# resources:
#    http://www.eibler.at
#    http://leo.sprossenwanne.at
#    http://www.nullpointer.at
#

# PID - pid of the current script
PID=$$
# SCRIPTNAME - current name of the script without directory prefix
SCRIPTNAME=`basename $0`
# PIDFILE - where to write the current pid
PIDFILE=/tmp/$SCRIPTNAME.pid

# ENDEXECUTION - if 1 then stop script, if 0 everything is ok and continue
ENDEXECUTION=0

if [ -f "$PIDFILE" ]
then
    RUNNINGPID=`cat "$PIDFILE"`
    echo "got pid from $RUNNINGPID from pidfile '$PIDFILE'"
    PROGRAMPID=`ps -e | grep "$SCRIPTNAME" | grep -v grep | awk '{print $1;}'`
    for PIDEL in $PROGRAMPID
    do
        echo "testing pid of running scripts '$PIDEL' == '$RUNNINGPID' from pidfile"
        if [ "$PIDEL" == "$RUNNINGPID" ]
        then
            echo "found PID $RUNNINGPID current running - end execution"
            ENDEXECUTION=1
            break
        fi
    done
fi

if [ "$ENDEXECUTION" == "1" ]
then
    echo "Current script '$SCRIPTNAME' already running (pid $RUNNINGPID) - end execution"
    exit 1
fi
# writing PID to pidfile
echo $PID > $PIDFILE

#
# ---- START ----
#

echo "do your stuff here ..."
sleep 5
echo "... end script"

#
# ---- END ----
#

# delete pidfile
rm $PIDFILE
exit 0

Die Erklärung

Zuerst holt sich das Script den eigenen Namen mit basename $0 ($0 würde ebenfalls den Pfad des Scriptaufrufs enthalten aber hier würde der spätere Aufruf von ps bzw. das automatische Erstellen und Auslesen des passenden pid-Files scheitern).

Mit dem Namen des Scripts wird dann versucht ein pid-File (welches die Process-ID des aktuell laufenden Scripts enthält) auszulesen. Der Pfad des pid-Files kann beliebig gewählt werden, jedoch muss das Script natürlich Schreibrechte auf die Datei besitzen.

Falls kein pid-File existiert kann das Script davon ausgehen, dass es derzeit nicht bereits läuft und seine eigentliche Arbeit aufnehmen.

Falls jedoch ein pid-File vorhanden ist, wird dieses ausgelesen und mit allen derzeit laufenden Process-IDs von Prozessen mit dem gleichen Namen wie das Script verglichen.

Wird hierbei eine Übereinstimmung gefunden, dann läuft das Script bereits und durch Setzen der Variable $ENDEXECUTION auf 1 wird der Abbruch signalisiert.

Dieser Vergleich mit den Process-IDs von Prozessen die bereits laufen ist deswegen wichtig, da es ja sein könnte, dass das Script beim vorherigen Aufruf zwar ein pid-File angelegt hat, aber danach abgebrochen wurde (z.B. manuell durch den Benutzer) und das pid-File dadurch nicht gelöscht wurde.

Ist die Überprüfung auf eine laufende Instanz negativ, muss zuerst das pid-File angelegt werden (Die Variable $$ enthält die pid des aktuellen Prozesses).

Nach Beendigung der Arbeit sollte danach das pid-File wieder gelöscht werden um einen sauberen Abschluss zu bilden.

Das Script als Download gibts hier.

 

Ähnliche Artikel:

Dateien zählen unter Linux

Otto Normal hat mit Datein Zählen unter Windows sicher keine Probleme und die meisten Linuxuser unter dem Betriebssystem ihrer Wahl wohl auch nicht. Will aber Otto mal in Linux reinschnuppern und dort Dateien zählen, stellt ihn das als Laien vor eine respektable Herausforderung.

Otto Normal hat damit unter Windows sicher keine Probleme und die meisten Linuxuser unter dem Betriebssystem ihrer Wahl wohl auch nicht. Will aber Otto mal in Linux reinschnuppern und dort Dateien zählen, stellt ihn das als Laien vor eine respektable Herausforderung.

Um sich den Inhalt eines Verzeichnisses aufzurufen ist ihm wahrschienlich schon der Befehl

ls

bekannt. ls steht für “list” Doch liefert dieser Befehl lediglich eine Auflistung des Inhalts des gegenwärtigen Verzeichnisses. Daher muss diese Ausgabe noch ausgewertet werden. Hierfür setzen wir Pipes | ein mit denen man mehrere Kommandos miteinander verbinden kann. Hierbei wird jeweils die Ausgabe des vorhergehenden Befehls als Eingabe für den nächsten Befehl herangezogen.

ls –1 | wc –l

wir haben hierbei den ls Befehl um den Parameter –1 (Zahl Eins) erweitert der für eine lange Listenform steht. Es wird somit jedes Element in einer extra Zeile angeführt. Die Ausgabe davon wird per Pipe an den wc Befehl weitergeleitet. wc steht in diesem Fall für Word Count. Erneut über einen Parameter –l (kleines L) weisen wir wc darauf hin, dass es die Zeilen zählen soll, die es übergeben bekommt.

Achtung! Wurde statt der 1 ein kleines L als Parameter an ls übergeben ist die Ausgabe um eins größer als die Anzahl der Elemente. Dies liegt daran, dass dabei noch eine weitere Zeile Output erzeugt wird, die keine Datei wiederspiegelt.

ls –l <targetdir> | wc –l

Wollen wir nicht direkt das Ergebnis aus dem Verzeichnis in dem wir uns befinden, können wir das Zielverzeichnis am ls Befehl anhängen.

Fürs erste kann man damit zufrieden sein, doch bei genauerer Betrachtung stößt man dabei rasch an die Grenzen des Befehls. Man zählt nämlich symbolische Links und Verzeichnisse und Dateien gleichermaßen.

Wir tauschen nun also den list Befehl gegen einen spezialisierteren Befehl  aus: find

find <targetdir> –maxdepth 1 –type f | wc –l

Mit -type f schränkt man die Auflistung der Ergebnisse auf Datein (files) ein. Dies könnte man z.B. auch auf Verzeichnisse (directorys) einschränken: –type d

Achtung, bei der Auflistung der Verzeichnisse wird das gegenwärtige Verzeichnis . mitgezählt, vom Gesamtergebnis also wieder eins abziehen.

Von Haus aus würde der find Befehl alle Unterverzeichnisse absuchen. Mittels –maxdepth <zahl> kann die Tiefe die er dabei erreicht steuern. Die 1 aus dem Beispiel oben steht hierbei nur für das Wurzelverzeichnis. Möchte man lediglich eine Verzeichnisebene tiefer wäre –maxdepth 2 der passende Parameter.

Will man nun auch wieder die symbolischen Links in seinem Suchergebnis dabei haben muss man den find Befehl noch um den –follow Parameter erweitern

find <targetdir> –maxdepth 1 –type f –follow | wc –l

Möchte man nun noch auf Dateiendungen oder anderen Teilen des Dateinamens einschränken gilt es noch den -name ‚*.txt‘ Parameter zu erwähnen. Zwischen den Anführungszeichen wir der Suchbegriff angeführt, * und ? gelten dabei als die üblichen Wildcards.

find <targetdir> -maxdepth 1 -type f -follow -name '*.t?t' | wc -l

Happy counting!

PS: Rekursives suchen wäre mit dem ls Befehl mittels –R Parameter möglich

Ähnliche Artikel:

HOWTO: Der eigene GIT Server mit Gitosis

Eine Versionsverwaltung gibt Stabilität, Kontrolle und vereinfacht die Arbeit im Team. Deshalb wird hier erklärt wie man seinen eigenen Git Server aufsetzt und konfiguriert.

Ich hab ja unlängst über die Vorzüge von Source Control Management Lösungen gesprochen. Deshalb möchte ich nun aufzeigen wie man sich selbst eine entsprechende Versionsverwaltung aufsetzt. Wir werden einen GIT Server aufsetzen und somit auf den Trend den Github und Co vorlebten aufspringen. Um eine einfache Verwaltung für den Zugriff von mehreren Usern auf verschiedene Repositories zu ermöglichen verwenden wir Gitosis

In diesem Tutorial setzen wir Gitosis auf dem neuesten Debian Squeeze Release, Version 6.0.3, auf. Dazu wurde das Betriebssystem in einer Virtual Machine aufgesetzt.

Zu erst installieren wir Git, den Kern unseres Tutorials:

# aptitude install git-core

Danach wird mit der Installation von Gitosis fortgefahren. Dabei könnten, so noch nicht installiert, diverse Abhängigkeiten zu Python installiert werden. Außerdem wird ein User mit dem Namen Gitosis, ebenso wie eine namensgleiche Gruppe und unter /srv/gitosis ein Homeverzeichnis für den User angelegt.

# aptitude install gitosis

Nach der Installation benötigt man einen ssh-rsa Key um sich als Administrator zu registrieren. Diesen benötigt man auf der Client Seite. Unter Windows ist dieser zB mit Puttygen zu erzeugen. Unter Linux wäre der Befehl:

ssh-keygen –t rsa –C “john@example.com

Dieser funktioniert auch in der Git Bash so man unter Windows auf msysgit zurückgreift.

Dabei werden 2 Files erzeugt: id_rsa (Private Key) und id_rsa.pub (Public Key).

Der Public Key wird nun auf den Linux Server transferiert, der Private Key bleibt nur am Client. Der Transfer kann mittels scp oder wget durchgeführt werden. Abgelegt sollte er unter dem Benutzernamen mit dem man am Server unterwegs ist in folgendes Verzeichnis: /etc/gitosis/sshkeys z.B. /etc/gitosis/sshkeys/theuser

Nicht vergessen darf man, dass man dem gitosis User alle notwendigen Rechte auf den Key verpasst:

# chown -R gitosis:gitosis /etc/gitosis/sshkeys

Möchte man das Homeverzeichnis des gitosis Users an einen anderen Ort legen kann man das wie folgt:

# mkdir /home/git

# usermod -d /home/git gitosis

Nicht vergessen rechte geben!

# chown -R gitosis:gitosis /home/git

Nun sind wir soweit, das Admin Repository kann angelegt werden. Gitosis verwendet nämlich ein eigenes Git Repository in dem alle Daten zur Erzeugung der individuellen Repositories und zur Steuerung der Rechte auf diese hinterlegt werden. Dazu wechseln wir auf den gitosis User

# su gitosis

und initialisieren dann den Dienst

$ gitosis-init < /etc/gitosis/sshkeys/thefake

Dabei müssten zwei Zeilen ausgegeben werden die in etwa so aussehen:

Initialized empty Git …
Reinitialized existing Git …

Hat der Server den SSH Port nicht wie standardmäßig auf Port 22 sondern z.B. auf 22222, muss am Client selbst unter ~/.ssh ein File mit dem Namen config angelegt werden. Dort trägt man dann den Host sowie den Port auf dem SSH zu finden ist ein:

Host 10.0.0.3
Port 22022

Nun steht dem initialen Auschecken des Admin-Repositories nichts mehr im Wege. Wir wechseln deshalb auf den Client, auf dem wir Git bereits installiert haben und holen uns das Repository folgendermaßen:

$ git clone gitosis@10.0.0.3:gitosis-admin.git

Dabei erhält man eine lokale Kopie der Configuratinsdatei sowie des Schlüsselverzeichnisses.

Um nun ein neues Repository anzulegen editiert man das Configurationsfile gitosis.conf mit einem Editor seiner Wahl und ergänzt es um folgende Zeilen

[group projektname]
writable = projektname
members = user@example.com

group benennt eine Gruppe von Usern, über die Kindattribute writable und members werden deren Rechte sowie deren Identitäten festgelegt. So kann im obigen Beispiel der Benutzer user@example.com auf das Projekt projektname zugreifen. Mittels Leerzeichen kann man hier mehrere User oder Repositories angeben. Mehr dazu später oder auf in der Gitosis Dokumentation zur Configurationsdatei.

Der Benutzer user@example.com benötigt einen public ssh-rsa Key der im Administrations-Projekt im Unterverzeichnis keydir hinterlegt werden muss. Dabei gilt die Namenskonvention <gitemailadresse>.pub

Erst commiten wir die neue Configuration ins lokale Repository

$ git commit -a -m „Added new repository ‚projektname'“

Anschließend wird die Configration auf den Server aufgespielt.

$ git push

Und schon können wir ein neues Projekt beginnen. Dazu erstellen wir ein neues Verzeichnis, initialisieren darin ein Git Projekt und legen eine erste Datei an.

mkdir projektname
cd projektname
git init
echo „This is a test file.“ > README
git add README

Nachdem wir das lokale Repository mit dem eben konfiguriertem Remote Repository verbunden haben commiten wir unsere lokalen Änderungen und laden diese auf den Server.

git remote add origin gitosis@10.0.0.3:projektname
git commit -a -m „Initial commit“
git push –all

Will man weitere Benutzer hinzufügen muss man deren Public Key wie vorhin beschrieben im Administrationsprojekt ablegen und fügt die Email Adresse in der Konfiguration einfach per Leerzeichen hinzu:

[group projektname]
writable = projektname
members = user@example.com another@example.com

Das ganze wird wieder commited und auf den Server gepushed, und schon ist der neue Benutzer berechtigt auf das Repo zuzugreifen.

Möchte man allgemeine Leserechte in einem Repository vergeben, ohne dass dazu ein User eingetragen werden muss, kann man dies individuell steuern indem man eine Kontrolldatei anlegt:

sudo touch /home/git/repositories/test.git/git-daemon-export-ok

Und fertig ist der Git Server. In einem weiteren Blogeintrag werde ich noch über die Installation einer Webmaske berichten. Also schaut mal wieder vorbei.

——–

Achja, sollte man noch nicht so fit mit Git selbst sein kann ich hier ein paar gute Links empfehlen:

Setting up Git (for Github)http://help.github.com/win-set-up-git/ Eine Installationsaleitung für Git unter WIndows. Die darin enthaltenen Informationen bezüglich User und User Email möchte ich nochmal hervorheben:

$ git config –global user.name “Firstname Lastname”

Damit setzt man den Namen seines Benutzers für alle Git Instanzen auf dem System

$ git config –global user.email „your_email@youremail.com

Dieser Befehl setzt die Email mit der auch über Gitosis der Key gematched wird. Sie dient somit als zentrales Element der Identifikation.

Generell sind die Github Manpages recht gute Quellen um sich mit Git vertraut zu machen.

Git Tutorials bei Kernel.org – http://web.archive.org/web/20110613161039/http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

Leider derzeit offline, aber in meinen Augen der beste Überblick über die Befehle von Git, über die WayBackMachine noch erreichbar.

Wer sich vertiefend mit dem Thema auseinandersetzen will dem sein zwei Online Bücher ans Herz gelegt:

Git In The Trencheshttp://cbx33.github.com/gitt/ bzw der Source vom Buch auf Github https://github.com/cbx33/gitt

ProGithttp://progit.org/book/

Bis zum nächsten Commit!

Ähnliche Artikel:

mail.log – versendete Mails erfassen

Ein Mailserver bedarf eines wachsamen Auges! Um Probleme wie eine Spamschleuder zu entdecken helfen schon ein paar simple Linux Befehle zum filtern von mail.log

Bei der Kontrolle der Aktivitäten eines Mailservers bleibt einem oft nichts anderes über als sich durch die Logfiles zu wälzen. um einen Schnellen blick auf alle Email zu erhalten, die der Server zuletzt verschickt hat, kann man die mail.log Datei folgendermaßen filtern:

cat /var/log/mail.log | grep postfix | grep "to=<" | grep "status=sent"

Damit erhält Informationen zu allen versandten E-Mails: hier eine Beispielausgabe:

Mar  7 16:19:57 mailserver postfix/pipe[17596]: 753C62F9D: to=john@example.org, orig_to=<john@example.org>, relay=dovecot, delay=0.54, delays=0.01/0/0/0.53, dsn=2.0.0, status=sent (delivered via dovecot service)

Anhand der ID (In diesem Fall 753C62F9D lassen sich dann noch detailiertere Informationen zu den jeweiligen Emails auslesen, wie zB den Sender usw.

Für eine schnelle händische Kontrolle zwischendurch absolut ausreichend.

Wer schönere Ausgaben haben möchte splittet die Ausgabe noch etwas auf und lässt sich nur teile ausgeben:

cat /var/log/mail.log | grep postfix | grep "to=<" | grep "status=sent" | cut -d':' -f4-5 | cut -d',' –f1

Ergebnis:

753C62F9D: to=<john@example.org>

Bessere Logauswertungen und Zusammenfassungen bekommt man mit Tools wie zB pflogsumm, awstats oder mailgraph die in den Paket-Repositories der Distribution eurer Wahl auch vorhanden sein sollten.

Mit täglich gemailten Statistiken über pflogsumm habt ihr euren Server im Auge falls Unregelmäßigkeiten auftreten, Wochen- Monats und später mal Jahresstatistiken stellen euch die graphischen Tools awstats oder mailgraph zur Verfügung.

Bei soviel praktischer Hilfe ist das wachsame Auge über dem Mailserver ein leichtes :)

Ähnliche Artikel: