Kategorien

Update Prozedur für tine2.0

Vor dem Upgrade meines Produktivsystems prüfe ich zunächst immer, ob das Update ohne Probleme durchläuft (bisher habe ich damit nämlich einmal schlechte Erfahrungen gemacht). Aus diesem Grund beschreibe ich kurz mein Vorgehen.

  1. Test-Verzeichnis erstellen, Dateien herunterladen und entpacken
    1
    2
    3
    4
    
    mkdir tine_test
    cd tine_test
    wget http://packages.tine20.org/source/2017.08.5/tine20-allinone_2017.08.5.tar.bz2
    tar xjf tine20-allinone_2017.08.5.tar.bz2

    Die aktuelle Version von tine findet man immer auf github.

  2. Dann wichtige Ordner und Dateien von der Produktivinstallation kopieren
    1
    
    cp -pR ../tine/config.inc.php ../tine/tine20.log* ../tine/base .

    Hinweis: Ich habe die Ordner files, caching, sessions und tmp im Verzeichnis base.

  3. Mysql-Datenbank kopieren in spezielle Testdatenbank tine20test, die ich für den gleichen Benutzer konfiguriert habe (zuerst Passwort für tine20user, dann für root eingeben)
    1
    2
    3
    
    mysqldump --add-drop-table -u root -p tine20db > tine20.sql
    cat tine20.sql | mysql -u tine20user -p tine20test
    rm tine20.sql
  4. Konfigurationsdatei config.inc.php editieren und auf Test-Datenbank anpassen (hier von tine20db auf tine20test)
  5. Im Webinterface Upgrade der Datenbankstruktur vornehmen unter http://yourserver/tine_test/setup.php
  6. Regulär einloggen unter http://yourserver/tine_test/ und alles testen
  7. Wenn erfolgreich, dann die Verzeichnisse austauschen
    1
    2
    3
    
    cd ..
    mv tine/ tine_old
    mv tine_test/ tine
  8. Datebankkonfiguration wird ändern auf Produktivdatenbank (hier von tine20test auf tine20db)
  9. Upgrade der Datenbankstruktur vornehmen unter http://yourserver/tine/setup.php
  10. Regulär einloggen unter http://yourserver/tine/ und nochmal testen
  11. Alte Dateien löschen
    1
    
    rm -rf tine_old

Das war’s!

Befehlsvervollständigung mit bash unter gentoo

Ein sehr praktisches Feature ist es beim Arbeiten mit der bash-Shell Befehle über die Tab-Taste automatisch zu vervollständigen. Unter gentoo lässt sich das erreichen, indem man zunächst mit einem

emerge -av bash-completion gentoo-bashcomp

die erforderliche Pakete bash-completion (allgemeine Bash-Befehlsvervollständigungen) und gentoo-bashcomp (spezifische Befehlsvervollständigungen für gentoo) installiert. Sofern nicht gesetzt, muss man auch das bash-completion USE flag in der Datei /etc/portage/make.conf ergänzen und dann eine Systemaktualisierung durchführen.

Danach bindet man die Befehlsvervollständigung in die systemweite Bash-Konfigurationsdatei /etc/bash/bashrc durch Ergänzen der Zeilen

# enable bash-completion
[[ -f /etc/profile.d/bash-completion.sh ]] && source /etc/profile.d/bash-completion.sh

ein und aktiviert sie systemweit mit einem

eselect bashcomp enable --global gentoo

Da es für verschiedene Programme Befehlsvervollständigungen gibt, muss man noch festlegen, für welche dies genau erfolgen soll. Eine entsprechende Liste erhält man mit

eselect bashcomp list

Jeder Benutzer kann nun für sich die einzelnen Listeneinträge aktiveren. Dazu wird das Verzeichnis ~/.bash_completion.d/ angelegt mit

mkdir ~/.bash_completion.d/

In dieses Verzeichnis erstellt man nun symbolische Links zu den einzelnen Dateien im Verzeichnis /usr/share/bash-completion, die bash eine Befehlsvervollständigung ermöglichen. Will man alle Befehlsvervollständigungen aktivieren, so erreicht man dies mit einem

for x in /usr/share/bash-completion/*; do [[ -e $x ]] || continue; ln -s -- "$x" "${HOME}/.bash_completion.d/${x##*/}"; done

Beim Start einer neuen Shell oder beim Laden der neuen Konfigurationsdatei mit einem

source /etc/bash/bashrc

sollten sich nun durch die tab-Taste die Befehle vervollständigen lassen.

Gentoo Hacks zu Systemupdates und Paketmanagement

Der Umgang mit dem Paketmanagementsystem ist unter Linux tägliches Handwerkszeug. Dabei gibt es immer wieder ein paar interessante Tricks und Kniffe, die ich hier nun für gentoo beschreiben möchte.

Upgrade des gesamten Systems

Ein Systemupgrade führe ich mit folgenden Schritten durch

# führt ein emerge --sync durch, aktualisiert den lokalen eix-Cache mit eix-update und zeigt die Unterschiede mit eix-diff an
eix-sync
# Overlays auf aktuellen Stand bringen (sofern man welche benutzt)
layman -S
# kurz für emerge --update --deep --newuse --ask --verbose --tree world
emerge -uDNavt world
# überflüssige Pakete entfernen
emerge -av depclean
# findet Pakete, die noch auf alte Programmbibliotheken verweisen und kompiliert diese neu
revdep-rebuild -v -- --ask
# Überflüssige Quellcodes und alte Binärpakete entfernen
eclean -d
# Konfigurationsdateien aktualisieren
dispatch-conf
# Prüfen, ob nicht mehr benötigte Pakete installiert sind
eix-test-obsolete

Auf serverfault.com gibt es eine interessante Diskussion wie man am Besten ein gentoo-System aktualisiert.

Emailbenachrichtigung über sicherheitsrelevante Paketupdates

Damit ich bei Sicherheitslücken in den installierten Programmen informiert werde, habe ich ein Cron-Skript unter /etc/cron.daily/glsa-check erstellt. Dieses ruft glsa-check auf und schickt eine Nachricht, falls eines oder mehrere Programme Sicherheitslücken aufweisen.

#!/bin/sh
export LANG=de_DE.UTF-8
export LANGUAGE=de_DE.UTF-8
# emerge --sync erforderlich, um glsa Meldungen zu bekommen
emerge --sync
glsa-check -n -q -l affected | mail -a "Content-Type: text/plain; charset=UTF-8" -e -s "glsa-check for $HOSTNAME" yourmailaddress@domain.com

Pakete inklusive Konfigurationsdateien vollständig entfernen

Ein einfaches Deinstallieren eines Paketes mit emerge löscht nicht die Konfigurationsdateien. Für den Fall, dass man diese auch löschen möchte, kann man dies tun mit einem

CONFIG_PROTECT="-*" emerge --unmerge package

Spezielle Paketversionen installiert halten

Manchmal möchte man ein Paket nicht aktualisieren und stattdessen die aktuelle Version beibehalten. Nun kann man einfach keine neuere Version installieren. Wenn man das gesamte System wie oben beschrieben aktualisieren oder bereinigen will, ist das natürlich schwierig. Mit einem

emerge -avt --noreplace sys-kernel/hardened-sources-3.10.1-r1

sorgt man dafür, dass emerge ein spezielles Paket in einer Version beibehält (siehe hierzu auch der Artikel Protecting slotted packages from ‚emerge –depclean‘).

Mailzustellung nachverfolgen

Wie mein Mailsetup aussieht habe ich in einer ausführlichen Artikelserie zu Dovecot, Exim, OpenLDAP, getmail und dspam beschrieben. Bei einigen Accounts kam es in letzter Zeit jedoch dazu, dass Mailnachrichten nur unvollständig zugestellt wurden. Dabei ging nicht die Nachricht an sich verloren, sondern die Nachricht wurde einfach abgeschnitten, so dass z.B. der Nachrichtentext unvollständig war oder Anhänge fehlten. Diesem Problem will ich nun auf den Grund gehen. Die Einträge in den Logdateien lassen nicht auf Fehler schließen:

Exim (unter /var/log/exim/exim_main.log):
2014-02-26 09:18:37 1WIZhL-0007rH-JF <= **@**.com
H=exprod6og101.obsmtp.com [64.18.1.181] P=smtps
X=TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256 S=118913
id=OF22A8285E.635A0C34-ONC1257C8B.002D8787-C1257C8B.002DA1DC@**.COM
2014-02-26 09:18:37 1WIZhL-0007rH-JF => ** <**@**>
R=local_user T=dovecot_delivery
2014-02-26 09:18:37 1WIZhL-0007rH-JF Completed
2014-02-28 09:28:24 1WJInu-0001M5-NU <= **@**.com
H=exprod6og118.obsmtp.com [64.18.1.233] P=smtps
X=TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256 S=257948
id=OF8652FF3E.7990F5DE-ONC1257C8D.002DB28B-C1257C8D.002E87A3@**.COM
2014-02-28 09:28:24 1WJInu-0001M5-NU => ** <**@**>
R=local_user T=dovecot_delivery
2014-02-28 09:28:24 1WJInu-0001M5-NU Completed
 
Dspam (unter /var/spool/dspam/data/user/user.log):
1393402717 I *@**.com 9,530da35d36871725616547
Sunject! Delivered
<OF22A8285E.635A0C34-ONC1257C8B.002D8787-C1257C8B.002DA1DC@**.COM>
1393576104 I *@**.com 9,531048a836871554010661
Re: Subject Delivered
<OF8652FF3E.7990F5DE-ONC1257C8D.002DB28B-C1257C8D.002E87A3@**.COM>
 
Dovecot (/var/log/dovecot-deliver.log):
2014-02-26 09:18:37 lda(*@*@**): Info: sieve:
msgid=<OF22A8285E.635A0C34-ONC1257C8B.002D8787-C1257C8B.002DA1DC@**.COM>:
stored mail into mailbox 'INBOX'
2014-02-28 09:28:24 lda(*@*@**): Info: sieve:
msgid=<OF8652FF3E.7990F5DE-ONC1257C8D.002DB28B-C1257C8D.002E87A3@**.COM>:
stored mail into mailbox 'INBOX'

Da der Fehler kann sich irgendwo in der Kette zwischen exim, dspam und dem Dovecot-LDA befinden kann, teste ich nun den Ansatz, die Nachricht nach jedem Zwischenschritt zu speichern:
Ursprüngliche Nachricht an Exim => /var/log/msg_id.exim
Nach Weiterverarbeitung durch Dspam /var/log/msg_id.dspam
Nach Zustellung durch Dovecot-LDA => im Mailverzeichnis des Benutzers

Für die Speicherung der Zwischenschritte habe ich deshalb folgendes Skript angelegt:

#!/bin/bash
/usr/bin/tee -a "/var/log/mails/$1.exim" | /usr/bin/dspamc --client --deliver=innocent,spam --user "$2" --stdout | /usr/bin/tee -a "/var/log/mails/$1.dspam"

In der Exim Konfigurationsdatei exim.conf passen wir den Paramter transport_filter an, der normalerweise dspam aufruft:

  #transport_filter = /usr/bin/dspamc --client --deliver=innocent,spam --user "GET_LOCAL_MAIL" --stdout
  transport_filter = /etc/exim/savemail "$message_id" "GET_LOCAL_MAIL"

Mal schauen, wo sich nun der Fehler versteckt..

(Hardened-)Kernel unter Gentoo kompilieren

In diesem Artikel geht es darum, wie ich es geschafft habe, für Gentoo einen Hardenend Kernel zu kompilieren. Dazu bin ich den Anweisungen des Wikis bis zur Anweisung

emerge --ask hardened-sources

gefolgt. Und habe dann den Kernel mit einem

make menuconfig

konfiguriert. Die zu setzenden Optionen, kann man dem Wiki in der Pax Quickstart Anleitung und der Grsecurity2 Quickstart Anleitung entnehmen. Leider sind bei letzterer nicht die Menüpunkte aufgelistet unter denen man die Konfigurationsoptionen findet. Man kann sich aber behelfen, indem man im Konfigurationsmenü die Taste „/“ drückt, worauf eine Suchmaske für Kernel-Optionen erscheint, in der dann der entsprechende Begriff eingegeben werden kann.

In vielen Fällen benötigt man zum Booten ein initramfs, das zum Beispiel Module lädt, die zum Hochfahren des richtigen Systems gebraucht werden. Bei mir war dies der Fall, weil ich einen KVM Guest eingerichtet habe., der die virtio Module benötigt. Zum Erzeugen eines initramfs muss man das Tool genkernel benutzen. Dieses kann aber viel mehr als nur ein initramfs erzeugen, da es auch dazu gedacht ist, bei einem Rechner automatisch festzustellen, welche Kernel Module benötigt werden. Wenn man es also ohne Bedacht aufruft, kann man sich sehr leicht die mühsam zusammengestellte, manuelle Kernel-Konfiguration überschreiben. Deshalb verfährt man am Besten wie im Gentoo-Wiki zum initramfs beschrieben und kopiert zur Sicherheit zunächst die Kernel-Konfiguration nach /etc/kernels/ mit einem sinnvollen Namen wie z.B. kernel-config-x86-2.6.18-gentoo-r6. Dann kopiert man die Datei nach /usr/src/linux/.config und führt im entsprechenden Verzeichnis folgenden Befehl aus:

genkernel --no-clean --no-splash --install all

Hierbei möchte ich auf einen interessanter Artikel hinweisen, in dem gezeigt wird, wie sich das initramfs unter gentoo zur Einbindung von verschlüsselten root-Partitionen anpassen lässt. Wenn man soweit alles fertig eingerichtet hat, kann man loslegen mit der Konfiguration und Einrichtung von Grsecurity wie es beispielsweise in dem Forumsartikel zu RBAC detailliert erklärt wird.