Wine 1.7 in einer Debian Chroot Umgebung bauen

Diese Anleitung richtet sich an alle die ein 32 Bit Wine für ihr 64 bit Debian selber kompilieren wollen.

Schritt 1: Debian Installation in der Chroot Umgebung

sudo apt-get install debootstrap
mkdir ~/wine-chroot -p
cd ~/
sudo debootstrap --arch i386 wheezy ~/wine-chroot http://ftp.de.debian.org/debian/
sudo mount -o bind /proc wine-chroot/proc
sudo cp /etc/resolv.conf wine-chroot/etc/resolv.conf
sudo chroot wine-chroot

Schritt 2: Grundlegende Konfiguration Debians innerhalb der Chroot Umgebung

apt-get update

apt-get install locales sudo vim libx11-dev:i386 libfreetype6-dev:i386 libxcursor-dev:i386 libxi-dev:i386 libxxf86vm-dev:i386 libxrandr-dev:i386 libxinerama-dev:i386 libxcomposite-dev:i386 libglu-dev:i386 libosmesa-dev:i386 libglu-dev:i386 libosmesa-dev:i386 libdbus-1-dev:i386 libgnutls-dev:i386 libncurses-dev:i386 libsane-dev:i386 libv4l-dev:i386 libgphoto2-2-dev:i386 liblcms2-dev:i386 libgstreamer-plugins-base0.10-dev:i386 libcapi20-dev:i386 libcups2-dev:i386 libfontconfig-dev:i386 libgsm1-dev:i386 libtiff-dev:i386 libpng-dev:i386 libjpeg-dev:i386 libmpg123-dev:i386 libopenal-dev:i386 libldap-dev:i386 libxrender-dev:i386 libxml2-dev:i386 libxslt-dev:i386 libhal-dev:i386 gettext:i386 prelink:i386 bzip2:i386 bison:i386 flex:i386 oss4-dev:i386 checkinstall:i386 ocl-icd-libopencl1:i386 opencl-headers:i386 libasound2-dev:i386 build-essential libpcap0.8-dev:i386

echo 'export LC_ALL="C"'>>/etc/bash.bashrc
echo 'export LANG="C"'>>/etc/bash.bashrc
source /etc/bash.bashrc
adduser sandbox
usermod -g sudo sandbox
echo 'Defaults !tty_tickets' >> /etc/sudoers
su - sandbox

Schritt 3: Wine herunterladen, kompilieren und als .deb packen
Zuerst wird Wine heruntergeladen und gebaut:

wget http://prdownloads.sourceforge.net/wine/wine-1.7.24.tar.bz2
tar xvfj wine-1.7.24.tar.bz2
cd wine-1.7.24
./configure
make

Nun wird mit der Hilfe des Programms checkinstall ein .deb Paket erzeugt:

sudo checkinstall --install=no --fstrans=no

Der obengenannte Aufruf erzeugt einen Dialog der ein paar Fragen stellt, diese einfach mit Enter bestätigen:

checkinstall 1.6.2, Copyright 2009 Felipe Eduardo Sanchez Diaz Duran
This software is released under the GNU GPL.

The package documentation directory ./doc-pak does not exist.
Should I create a default set of package docs? [y]:

Preparing package documentation...OK

Please write a description for the package.
End your description with an empty line or EOF.
>> wine 1.7.29
>>

*****************************************
**** Debian package creation selected ***
*****************************************

This package will be built according to these values:
0 - Maintainer: [ root@localhost ]
1 - Summary: [ wine 1.7.24]
2 - Name: [ wine ]
3 - Version: [ 1.7.24]
4 - Release: [ 1 ]
5 - License: [ GPL ]
6 - Group: [ checkinstall ]
7 - Architecture: [ i386 ]
8 - Source location: [ wine-1.7.24 ]
9 - Alternate source location: [ ]
10 - Requires: [ ]
11 - Provides: [ wine ]
12 - Conflicts: [ ]
13 - Replaces: [ ]

Checkinstall takes a little while (In particular this step: 'Copying files to the
temporary directory...').

**********************************************************************

Done. The new package has been saved to /home/sandbox/tmp/wine-1.7.24/wine_1.7.24-1_i386.deb
You can install it in your system anytime using:

dpkg -i wine_1.7.24-1_i386.deb

**********************************************************************

4. Installation auf dem 64 Bit Debian
Zuerst muss Multiarch aktiviert und die benötigten Bibliotheken installiert werden:

sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install ia32-libs libgstreamer-plugins-base0.10-0

Nun kann das erzeugte Paket installiert werden:

sudo dpkg -i ~/wine-chroot/home/sandbox/wine-1.7.24/wine_1.7.24-1_i386.deb

CCS Injection Vulnerability (CVE-2014-0224) in Zimbra 8 schließen

Wie auch schon bei der Heartbleed Sicherheitslücke , ist es notwendig durch den Austausch der von Zimbra mitgebrachten SSL-Libraries die Sicherheitslücken zu schließen.

Diese Sicherheitslücke betrifft nur Zimbra 8, die vorhergehenden Versionen sind nicht betroffen.

Als erstes wird Zimbra heruntergefahren:

~# su - zimbra
~$ zmcontrol stop

Nur wird das von Zimbra zur Verfügung gestellte Script heruntergeladen und als root User ausgeführt:

cd /tmp
wget http://files.zimbra.com/downloads/security/zmopenssl-updater.sh
chmod a+rx zmopenssl-updater.sh
./zmopenssl-updater.sh

Zimbra kann nun wieder gestartet werden:

~# su - zimbra
~$ zmcontrol start

Wenn man sich nun als Zimbra User die OpenSSL Version anzeigen lässt, sollte folgende Ausgabe erscheinen:

zimbra$ openssl version
OpenSSL 1.0.1h 5 Jun 2014

OpenJDK System Proxy

Um Java Applikationen einen Zugriff auf das Internet über einen Proxy zu ermöglichen ist etwas Arbeit nötig,
da OpenJDK standardmäßig einen konfigurierten System Proxy ignoriert.

Um den System Proxy zu benutzen muss die Datei /etc/java-7-openjdk/net.properties geöffnet werden und folgender Wert auf true geändert werden:

java.net.useSystemProxies=true

Heartbleed TLS-Bug in Zimbra 8 schließen

Auch der Zimbra Collaboration Server in Version 8 ist von der Heartbleed Sicherheitslücke in OpenSSL betroffen.
Anders als bei anderer Software verwendet Zimbra allerdings nicht die OpenSSL Installation der Distribution, sondern bringt eigene libssl und libcrypto mit.

Ab Zimbra 8.0.8 wird die Lücke über die normalen Installationsbundles geschlossen werden, für alle Nutzer einer Zimbra Version zwischen 8.0.3 bis 8.0.7 gibt es folgendes Script, welches die SSL Libraries gegen eine nicht verwundbare Version austauscht:

Zuerst wird das Script heruntergeladen und als User root ausgeführt:

wget http://files.zimbra.com/downloads/security/zmopenssl-updater.sh
chmod a+x zmopenssl-updater.sh
./zmopenssl-updater.sh

Wenn alles geklappt hat erscheint folgende Ausgabe:

---------------------
[Generates the following output]
Downloading patched openssl
Validating patched openssl: success
Backing up old openssl: complete
Installing patched openssl: complete
OpenSSL patch process complete.
Please restart Zimbra Collaboration Suite as the Zimbra user via zmcontrol
restart
---------------------

Damit die neuen SSL Libraries auch von allen Zimbra Services verwendet werden muss Zimbra neu gestartet werden:

su - zimbra
zmcontrol restart

Ob die Lücke dann auch wirklich geschlossen ist, lässt sich mit einem der zahlreichen Heartbleed Tests nachvollziehen:

http://filippo.io/Heartbleed/

http://possible.lv/tools/hb/

FreeRADIUS mit EAP-PEAP und LDAP zur sicheren WLAN Authentifizierung

1. Beschreibung
Warum WPA2 Enterprise?
WPA2 Enterprise ermöglicht es jedem Benutzer eigene Zugangsdaten verwenden zu lassen, falls ein Benutzer keinen Zugriff mehr auf das WLAN Netzwerk haben soll, muss nur dessen Account deaktiviert werden. Bei einem Passphrase geschütztem WPA Netzwerk wäre hier der Austausch der Passphrase notwendig, welche man dann an alle bestehenden Nutzer erneut verteilen muss.

Warum EAP-PEAP?
EAP-PEAP ist dass EAP Verfahren,welches von den meisten Betriebsystemen direkt unterstützt wird. Allerdings ist die Auswahl der Passwort-Backends auf jene beschränkt, die die Passwörter im Klartext oder als NT-Hash speichern.
Eine Übersicht, welches EAP-Verfahren mit welcher Art der Passwortspeicherung funktioniert findet ihr hier:
Protocol and Password Compatibility

EAP-PEAP ist wie auch zum Beispiel EAP-TTLS ein sogenanntes 2 Phasen Verfahren, hierbei wird in der ersten Phase ein TLS-Tunnel zwischen dem WLAN Client und dem FreeRADIUS-Server aufgebaut.
In der zweiten Phase wird das Passwort MS-CHAPV2 verschlüsselt übertragen.

2. Konfiguration des FreeRADIUS Servers
Installation der Software
Auf dem Server werden die folgenden Pakete installiert:

apt-get install freeradius freeradius-ldap freeradius-utils

SSL Zertifikate erzeugen
Während der Installation werden zumindest unter Ubuntu und Debian sogenannte selbst signierte SnakeOil Zertifikate angelegt.
Diese SnakeOil Zertifikate eignen sich zum testen des Aufbaus, sollten aber vor der Inbetriebnahme durch Kaufzertifikate oder zumindest durch die Zertifikate einer eigenen CA ausgetauscht werden.

AccessPoints als Clients des FreeRADIUS-Server einrichten
Die AccessPoints werden in der Datei /etc/freeradius/clients.conf eingerichtet:

client {
secret = Passwort
shortname = Symbolischer Name
}

Den FreeRADIUS-Server auf EAP-PEAP konfigurieren
Die zu verwendende Verschlüsselungsmethode wird in der Datei /etc/freeradius/eap.conf eingerichtet:
Zuerst muss der Standard EAP-Typ eingestellt werden:

default_eap_type = peap

Für die TLS Konfiguration müssen das Server Zertifikat, der Private Key, die Diffie-Hellman Parameter und /dev/urandom als Zufallszahlengenerator angegeben werden:

tls {
private_key_file = /etc/freeradius/certs/radius-key.pem
certificate_file = /etc/freeradius/certs/radius-cert.pem
dh_file = /etc/freeradius/certs/dh.pem
random_file = /dev/urandom
cipher_list = "DEFAULT"
}

Die Diffie-Hellmann Parameter können mit diesem Befehl erzeugt werden:

openssl dhparam 2048 > /etc/freeradius/certs/dh.pem

Die EAP-PEAP Konfiguration sollte folgendes aussehen haben:

peap {
default_eap_type = mschapv2
virtual_server = "inner-tunnel"
}

Der Parameter virtual_server lädt die entsprechende Konfiguration für die Phase 2.

Verbindung zum OpenLDAP Server einrichten
Um den FreeRADIUS-Server an den LDAP Server anzubinden müssen die Verbindungsparameter und die entsprechenden LDAP-Filter in die Datei modules/ldap eingetragen werden:

ldap {
server = ldap.example.org
port = 636 # Oder 389 falls der LDAP-Server keine SSL gesicherten Verbindungen anbietet.
binddn = "cn=manager,dc=example,dc=org"
password = manager-password
basedn = "dc=example,dc=org"
filter = "(&(objectClass=posixAccount)(uid=%{%{Stripped-User-Name}:-%{User-Name}}))"
groupmembership_filter = "(&(objectClass=posixGroup)(memberUid=%{User-Name}))"
groupmembership_attribute = "cn=Gruppe,ou=Groups,dc=example,dc=org"
ldap_connections_number=5
dictionary_mapping = ${confdir}/ldap.attrmap
}

Typischerweise ist es nur einem administrativen Benutzer gestattet auf die NT-Hashes zuzugreifen, daher sollten die beiden Werte binddn und password angegeben werden.
Die LDAP Filter in diesem Beispiel müssen nicht unbedingt auf jedem LDAP Setup funktionieren, diese muss man dann an dass jeweiliges Schema anpassen.

Abschließend muß die Umsetzung zwischen den RADIUS und den LDAP Attributen in der Datei /etc/freeradius/ldap.attrmap konfiguriert werden.
Es sollten alle eventuell vorhandenen Attribute gelöscht werden, sodass die Datei die folgenden fünf Zeilen enthält:

checkItem $GENERIC$ radiusCheckItem
replyItem $GENERIC$ radiusReplyItem
checkItem LM-Password sambaLmPassword
checkItem NT-Password sambaNtPassword
checkItem SMB-Account-CTRL-Text acctFlags

3. Konfiguration der AccessPoints
Mittlerweile unterstützen die gängisten AccessPoints und WLAN-Router das RADIUS-Protokoll, hierbei sind immer folgende Angaben zu machen:

  1. IP-Adresse des RADIUS-Servers
  2. Der RADIUS-Server Port: 1812
  3. Das Shared Secret aus der clients.conf

Nun sollte man ein funktionsfähiges WPA2 Enterprise Setup besitzen, falls es zu Problemen kommt kann man den FreeRADIUS in einem ziemlich gesprächigem Modus starten:
freeradius -vv

RADIUS und EAP als Protokolle und FreeRADIUS als Software sind recht komplexe Themengebiete, also nicht gleich aufgeben falls etwas nicht klappt.

UniFi WLAN Controller unter anderem Nutzer starten

Vor ein paar Wochen habe ich neue AccessPoints von Ubiquiti Networks gekauft, um das WLAN Netzwerk in der Firma neu aufzubauen.
Die AccessPoints haben eine wesentlich bessere Reichweite und sehen auch besser aus als unsere alten AccessPoints.
Die kostenlos erhältliche Controller-Software bietet mir alle benötigten Features, inklusive Gäste über zeitlich begrenzte Tickets zu authentifizieren ( ähnlich wie in Hotels ).

Soweit so gut, allerdings läuft die Controller Software standardmäßig unter dem User root, für einen richtigen Linux Admin geht so etwas natürlich gar nicht.
Es ist aber grundsätzlich möglich die Software auch unter einem anderen User laufen zu lassen, und dies werde ich nun erklären:

Als erstes wird die Software gestoppt:
/etc/init.d/unifi stop

Nachdem die Software heruntergefahren ist erstellen wir einen neuen User mit dem Namen “unifi”:
adduser unifi

Diesem User und der gleichnamigen Gruppe übertragen wir die Rechte an den Ordnern und Dateien der Software:
chown unifi:unifi -R /usr/lib/unifi
chown unifi:unifi -R /var/lib/unifi
chown unifi:unifi -R /var/log/unifi

Zuletzt müssen wir noch das init-Script dahingehend anpassen, dass die Software mit dem neuen User gestartet wird.
Hierzu öffnen wir das init-Script unter /etc/init.d/unifi mit einem Editor und suchen nach folgenden Zeilen:

JSVC_OPTS="${JSVC_OPTS}\
-home ${JAVA_HOME} \
-cp /usr/share/java/commons-daemon.jar:${BASEDIR}/lib/ace.jar \
-pidfile ${PIDFILE} \
-procname ${NAME} \
-outfile SYSLOG \
-errfile SYSLOG \
-Djava.awt.headless=true -Xmx1024M"

In diesem Block fügen wir nun die markierte Zeile ein:

JSVC_OPTS="${JSVC_OPTS}\
-home ${JAVA_HOME} \
-user unifi \
-cp /usr/share/java/commons-daemon.jar:${BASEDIR}/lib/ace.jar \
-pidfile ${PIDFILE} \
-procname ${NAME} \
-outfile SYSLOG \
-errfile SYSLOG \
-Djava.awt.headless=true -Xmx1024M"

Jetzt kann die Software wieder gestartet werden:
/etc/init.d/unifi start

Zu diesem Thema habe ich schon ein Ticket beim Hersteller geöffnet, mal sehen ob dieses Problem in einer der nächsten Versionen behoben wird.

Wichtig: Bei jedem Update / Upgrade der Software werdet ihr gefragt, ob die Änderungen am init-Script überschrieben werden sollen. Außerdem werden die Zugriffsrechte an den Ordnern und Dateien wieder an den User root übertragen, dies muss dann wieder geändert werden.

Fail2Ban und Postscreen

Fail2Ban lässt sich dahingehend erweitern, um auf die Ausgaben von Postscreen zu reagieren und die IP Adressen zu blocken.

Man könnte Fail2Ban anweisen die ankommende IP zu blocken, falls diese von Postscreen auf einer Blacklist oder mehreren Blacklists gefunden wurde.
Der entsprechende Postscreen Log-Eintrag sieht so aus:

NOQUEUE: reject: RCPT from [x.x.x.x]:xxxx: 550 5.7.1 Service unavailable;
client [x.x.x.X] blocked using zen.spamhaus.org;
from=<spammer@domain.tld>, to=<spam@kupschke.net>, proto=ESMTP, helo=<...>

Nun muss man den Fail2Ban Postfix Filter entsprechend anpassen, diesen findet man in der Datei /etc/fail2ban/filter.d/postfix.conf:
Original:

 failregex = reject: RCPT from (.*)\[<HOST>\]: 554

Meine Anpassungen:

 failregex = reject: RCPT from (.*)\[<HOST>\]: 554
             reject: RCPT from (.*)\[<HOST>\]:([0-9]{4,5}:)? 550

Sofern die Fail2Ban Standardeinstellungen gesetzt sind, würde ein Spammer jetzt nach 3 Versuchen für 10 Minuten gebannt werden.
Mein Postscreen fragt allerdings mehrere Blacklists ab und blockiert den Spammer erst wenn er in mehreren Blacklists eingetragen ist, diese Überprüfungen sind recht teuer, daher möchte ich den Spammer bei seinem ersten Versuch für eine Stunde blockieren.
Um diese Konfiguration einzurichten öffnen wir die Datei /etc/fail2ban/jail.conf und ändern die Einträge wie folgt ab:
Originial:

[postfix]
enabled  = true
port     = smtp
filter   = postfix
logpath  = /var/log/mail.log

Meine Anpassungen:

[postfix]
enabled  = true
port     = smtp
filter   = postfix
logpath  = /var/log/mail.log
maxretry = 1
bantime = 3600

Ob man auch alles richtig eingestellt hat, und welchen Erfolg man bisher mit diesen Regeln gehabt hätte, kann man sich mit diesem Befehl anzeigen lassen:

fail2ban-regex /var/log/mail.log /etc/fail2ban/filter.d/postfix.conf

Mithilfe von Fail2Ban kann man natürlich auch auf alle anderen Ausgaben von Postscreen und Postfix reagieren und die Spammer sehr effizient abwehren.

Standard Terminal setzen

Um das Standard Terminal zu ändern gibt es unter Debian und Ubuntu diesen Befehl:

update-alternatives --config x-terminal-emulator

Auf meinem System erhalte ich folgende Ausgabe:

Es gibt 5 Auswahlmöglichkeiten für die Alternative x-terminal-emulator
(welche /usr/bin/x-terminal-emulator bereitstellen).

  Auswahl      Pfad                 Priorität Status
------------------------------------------------------------
* 0            /usr/bin/terminator   50        Auto-Modus
  1            /usr/bin/koi8rxterm   20        manueller Modus
  2            /usr/bin/lxterm       30        manueller Modus
  3            /usr/bin/terminator   50        manueller Modus
  4            /usr/bin/uxterm       20        manueller Modus
  5            /usr/bin/xterm        20        manueller Modus

Drücken Sie die Eingabetaste, um die aktuelle Wahl[*] beizubehalten,
oder geben Sie die Auswahlnummer ein: 4

In meinem Beispiel war “terminator” als Standard gesetzt, dies habe ich durch die Eingabe der 4 auf die Unicode Variante von xterm umgestellt.

Arbeiten mit Git – Remote Repository hinzufuegen

In einem älteren Artikel habe ich ja schon erklärt wie man mit einem lokalen Git Repository arbeitet. Wenn man die Daten jedoch auch Remote ablegen möchte, sei es um mit mehreren Personen zu arbeiten oder zur Sicherung der Daten, ermöglicht es Git sogenannte Remote Repositorys hinzuzufügen.
Um ein Remote Repository einem lokalen Repository hinzuzufügen muss man zuerst in dass Repository wechseln und dann folgender Befehl eingeben werden:

git remote add <symbolischer-name> protocol://example.org/git/<remote-repository>

Mit diesem Befehl kann man sich dann alle verfügbaren Repositorys anzeigen lassen:

git remote show

Als Ausgabe erhält man alle Symbolischen Namen, welche man während des hinzufügen der Remote Locations vergeben hat.

Falls man mehr Information über ein bestimmtes Remote Repository erfahren möchte muss nur dessen Symbolischen Namen angeben:

git remote show <symbolischer-name>

Gerrit Code Review mit Tomact,MySQL und LDAP

Dieses Howto beschreibt die Installation eines Gerrit Code Review Systems, anstatt des mitgelieferten Jetty Application-Servers wird ein Tomcat eingesetzt. Als Datenbank wird ein MySQL-Server genutzt und die Benutzerdaten kommen aus einer bestehenden LDAP Installation.
Die Installation funktioniert unter Debian und Ubuntu, sollte aber mit geringem Aufwand auch auf anderen Linux-Distributionen funktionieren.

1. Benötigte Pakete installieren

apt-get install git git-core openjdk-6-jre apache2 libapache2-mod-jk mysql-server tomcat6

2. CA Zertifikat in den Java Keystore übernehmen
Dieser Schritt ist nur dann wichtig, wenn der LDAP-Server über eine SSL/TLS geschützte Verbindung angesprochen werden soll.

Für OpenJDK lautet der Importbefehl wie folgt:

keytool -import -trustcacerts -alias "example-ca" -file CA.pem -keystore /etc/ssl/certs/java/cacerts -storepass "changeit"

Falls ein Oracle Java genutzt wird sieht der Befehl etwas anders aus:

keytool -import -trustcacerts -alias "example-ca" -file CA.pem -keystore /etc/java6-sun/security/cacerts -storepass "changeit"

3. MySQL-Datenbank anlegen
Zuerst muss man sich in die MySQL-Datenbank mit dem während der Installation gesetzten Passwort einloggen:

mysql -u root -p

Nun legt man eine neue Datenbank und einen Benutzer für die Gerrit Instanz an:

CREATE USER 'gerrit'@'localhost' IDENTIFIED BY 'gerrit';
CREATE DATABASE reviewdb;
ALTER DATABASE reviewdb charset=latin1;
GRANT ALL ON reviewdb.* TO 'gerrit'@'localhost';
FLUSH PRIVILEGES;
quit;

4. Initiale Gerrit Konfiguration durchführen
Zuerst muss ein Ordner für die Gerrit Git-Repositorys und einige Konfigurationsdateien angelegt werden:

mkdir /opt/gerrit
cd /opt/gerrit

Nun können die benötigten Installationsdateien heruntergeladen werden:

wget https://gerrit.googlecode.com/files/gerrit-2.4.2.war -O gerrit.war

Die Gerrit Installation wird mit diesem Befehl gestartet:

java -jar gerrit.war init -d /opt/gerrit/gerrit-home

Während der Installation werden einige Fragen gestellt, die entsprechenden Antworten habe ich fett markiert:


*** Gerrit Code Review 2.4.2
***

Create ‘/opt/gerrit/review_site’ [Y/n]? y

*** Git Repositories
***

Location of Git repositories [git]: /opt/gerrit/git

Database server type [H2/?]: mysql

Gerrit Code Review is not shipped with MySQL Connector/J 5.1.10
** This library is required for your configuration. **
Download and install it now [Y/n]? y
Downloading http://repo2.maven.org/maven2/mysql/mysql-connector-java/5.1.10/mysql-connector-java-5.1.10.jar … OK
Checksum mysql-connector-java-5.1.10.jar OK

Server hostname [localhost]:
Server port [(MYSQL default)]:
Database name [reviewdb]:
Database username [root]:
gerrit’s password :
confirm password :

*** User Authentication
***
Authentication method [OPENID/?]: ldap
LDAP server [ldap://localhost]: ldaps://ldap.example.org
LDAP username :
Account BaseDN [DC=example,DC=org]: OU=Users,DC=example,DC=org
Group BaseDN [OU=Users,DC=example,DC=org]: OU=Groups,DC=example,DC=org
*** Email Delivery
***

SMTP server hostname [localhost]:
SMTP server port [(default)]:
SMTP encryption [NONE/?]:
SMTP username :

*** Container Process
***

Run as [root]:
Java runtime [/usr/lib/jvm/java-6-openjdk-i386/jre]:
Copy gerrit.war to /opt/gerrit/review_site/bin/gerrit.war [Y/n]? y
Copying gerrit.war to /opt/gerrit/review_site/bin/gerrit.war

*** SSH Daemon
***

Listen on address [*]:
Listen on port [29418]:

Gerrit Code Review is not shipped with Bouncy Castle Crypto v144
If available, Gerrit can take advantage of features
in the library, but will also function without it.
Download and install it now [Y/n]? n
Generating SSH host key … rsa(simple)… done

*** HTTP Daemon
***

Behind reverse proxy [y/N] y?
Use SSL (https://) [y/N] y?
Listen on address [*]:
Listen on port [8080]:

5. Gerrit in den Tomcat deployen
Als aller erstes wird Tomcat gestoppt:

/etc/init.d/tomcat6 stop

Damit der Zugriff auf die Datenbank aus dem Tomcat funktioniert muss eine Datasource in der Datei /etc/tomcat6/context.xml angelegt werden:

<Context>
....
  <Resource name="jdbc/ReviewDb" auth="Container" type="javax.sql.DataSource"
               maxActive="100" maxIdle="30" maxWait="10000"
               username="gerrit" password="gerrit" driverClassName="com.mysql.jdbc.Driver"
               url="jdbc:mysql://localhost:3306/reviewdb"/>
....
</Context>

Um nachher die den Apache-Webserver über mod_jk anzubinden muss zuerst der AJP1.3 freigeschaltet werden. Die Freischaltung geschieht in der Datei /etc/tomcat6/server.xml, so sehen die Zeilen vor der Bearbeitung aus:

    <!-- Define an AJP 1.3 Connector on port 8009 -->
    <!--
    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
    -->

Und so nach der Bearbeitung:

    <!-- Define an AJP 1.3 Connector on port 8009 -->
        <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> 

Nun werden die benötigten Daten in die entsprechenden Tomcat Verzeichnisse verschoben:

cd /opt/gerrit/gerrit-home/
cp bin/gerrit.war /var/lib/tomcat6/webapps/
cp lib/mysql-connector-java-5.1.10.jar /usr/share/tomcat6/lib/
chown tomcat6.tomcat6 -R /opt/gerrit/

6. Tomcat über mod-jk anbinden
JK-Worker für Gerrit anlegen:

vi /etc/libapache2-mod-jk/workers.properties

Die workers.properties sollte so aussehen:


workers.tomcat_home=/usr/share/tomcat6
workers.java_home=/usr/lib/jvm/default-java
ps=/

worker.list=gerrit_worker

worker.gerrit_worker.port=8009
worker.gerrit_worker.host=localhost
worker.gerrit_worker.type=ajp13
worker.gerrit_worker.lbfactor=1

worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=gerrit_worker

Als nächstes wird eine Konfigurationsdatei für eine generelle mod_jk Konfiguration angelegt:
touch /etc/apache2/conf.d/jk.conf

Die Datei wird mit diesem Inhalt gefüllt:

JkShmFile /var/log/apache2/mod_jk.shm
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel info
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkOptions +RejectUnsafeURI +ForwardKeySize
JkMount /gerrit gerrit_worker
JkMount /gerrit/* gerrit_worker

Als letztes muss man die VirtualHosts anpassen, in denen die Applikationen verfügbar sein sollen, dazu fügt man folgende Zeile ein:

JkMountCopy On

Zum Abschluss sollten der Tomcat- und der Apache-Server einmal neugestartet werden:

/etc/init.d/tomcat6 restart
/etc/init.d/apache2 restart

Nun könnt ihr euer Gerrit Code Review System über http(s)://your-host/gerrit aufrufen.

Zum Abschluss poste ich hier noch meine funktionierende gerrit.config:

[gerrit]
basePath = /opt/gerrit/git
[database]
type = MYSQL
hostname = localhost
database = reviewdb
username = gerrit
[auth]
type = LDAP
[ldap]
server = ldap://ldap.example.org
accountBase = OU=Users,DC=example,DC=org
groupBase = OU=Groups,DC=example,DC=org
[sendemail]
smtpServer = localhost
[container]
user = root
javaHome = /usr/lib/jvm/java-6-openjdk-i386/jre
[sshd]
listenAddress = *:29418
[httpd]
listenUrl = proxy-http://*:8080/
[cache]
directory = cache