Die Technik ist umgezogen

Hallo alle Artikel die hier waren, befinden sich ab sofort auf einer neuen Seite. Dies hier sollen private Seiten bleiben, daher sind sie nicht von Suchmaschinen durchsuchbar. Damit die technischen Dinge aber gefunden werden können, habe ich das nun getrennt

Bitte folgt diesem Link: www.reisegruppe14.de

Debian: Umzug eines laufenden Systems in ein Raid

Der Proempelserver lief bisher auf einer einzelnen Raidfähigen Festplatte, die zweite Platte war zwar vorhanden, wurde aber als Zusatzspeicher benutzt. Da der Server nun doch in die Jahre kommt und damit die Ausfallwahrscheinlichkeit steigt, habe ich mich entschlossen, aus den beiden Platten ein Raid1 zu bauen. Die Hoffnung ist, daß wenn eine Platte stirbt, auf der zweiten Platte weitergearbeitet werden kann. Eine Neuinstallation auf einem Raid erschien mir zu aufwendig, vor allem weil dann unser Mailserver für einige Zeit nicht zur Verfügung stehen würde. Auch auf die erneute Konfiguration hatte ich keine Lust. Daher entstand die Idee, einen Umzug im laufenden Betrieb durchzuführen.

Ich kann nur jedem, der ähnliches vorhat, vorab mit einem Testsystem zu üben, ich tat dies über eine Installation mittels VirtualBox.

Man beginnt im laufenden System, es ist einige Vorarbeit notwendig, die im normalen Betrieb erledigt werden kann, die Ausfallzeit wird dadurch minimiert, aber ganz ohne Ausfallzeit geht es leider nicht.

Als erstes muß das System Raidfähig gemacht werden, dazu installiert man das Paket mdadm, sofern auch LVM zu Einsatz kommen soll auch dieses.

    1  apt-get install mdadm

Als nächstes wird die 2. nicht genutzte Platte vorbereitet, ich mußte diese allerdings erstmal freiräumen. Partitionstyp wird auf ‘fd’ eingestellt

    2  cfdisk /dev/sdb

Man erstellt nun die Partitionen nach den eigenen Vorstellungen, bei mir nur Swap und Root, anschließend wird das Raid mit fehlender zweiter Platte eingerichtet , formatieren und Swap erstellen:

    3  mdadm --create /dev/md0 --raid-devices=2 --level=1 --metadata=0.90 missing /dev/sdb2
    4  mkswap /dev/sdb1
    5  mkfs.ext3 /dev/md0

Die frische Raidpartition ins System einbinden und die Daten des System schonmal kopieren(synchronisieren). Ich habe dies schonmal im laufenden Betrieb gemacht, da man so die Ausfallzeit weiter reduzieren kann, später erfolgt ein reboot ins Rescue System, hier muß nochmals Synchronisiert werden, das geht dann aber wesentlich schneller, da sich in der Regel nur wenige Daten ändern und rsync dies gut geregelt bekommt.

   6  mkdir /mnt/target
   7  mount /dev/md0 /mnt/target
   8  apt-get install rsync
   9  rsync -ahx --exclude='/mnt/' / /mnt/target/

Nun wird die Raidkonfiguration dem neuen System bekannt gemacht und die Einträge von fstab und mtab der Raidplatte angepasst

   10  mdadm --examine --scan >> /mnt/target/etc/mdadm/mdadm.conf
   11  vi /mnt/target/etc/fstab
     /dev/sda1        none          swap    sw                      0       0
     /dev/md0         /             ext3    defaults                0       1
     /dev/sdb1        none          swap    sw                      0       0
     proc             /proc         proc    defaults                0       0

Auf meinem System ist Grub2 installiert, der hat mir einige Nerven gekostet, wobei die Arbeit eigentlich sehr simpel ist, allerdings hat mit in allen Howtos zum Thema ein Hinweis gefehlt

   12 vi /etc/default/grub

Diesen Eintrag setzen:

   GRUB_TERMINAL=console

Nun wird das System im Rescue-Modus oder per Live CD gestartet. Sofern dort nicht vorhanden muß mdadm nochmals installiert werden, damit die Raidkonfiguration erkannt und genutzt werden kann.

    1  apt-get install mdadm vim
    2  mdadm --assemble /dev/md0 /dev/sdb2
    3  mkdir /mnt/target
    4  mkdir /mnt/source
    5  mount /dev/md0 /mnt/target/
    6  mount /dev/sda2 /mnt/source

Nun wird abschließend nochmal synchronisiert:

    7 rsync -ahx /mnt/source /mnt/target/

War dies erfolgreich, wird eine Chrootumgebung vorbereitet und ins “neue System” gechrootet:

    7  mount -o bind /dev/ /mnt/target/dev/
    8  mount -o bind /sys/ /mnt/target/sys
    9  mount -o bind /proc/ /mnt/target/proc/
   10  chroot /mnt/target/

Im CHroot muß nun Grub neu in den MBR beider Platten geschrieben werden, anschließend wird eine neue GrubConfig generiert:

    1  grub-install /dev/sda
   2  grub-install /dev/sdb
    3  update-grub
    4  update-initramfs -u

Nun kann das System neugestartet werden, und hoffentlich bootet es nun auch ins Raid. Hier hatte ich diverse Schwierigkeiten, welche meiner Meinung nach nur durch die kleine Änderung in /etc/default/grub behoben wurden, so ganz sicher bin ich mir aber nicht. Das Problem, war der Server in einer Rebootschleife festhing.

Nach erfolgreichem Neustart wird die erste Platte, auf der bisher das System lief umgebaut und ebenfalls Raidfähig gemacht:

cfdisk /dev/sda

hier identisch wie sdb einrichten

mdadm --add /dev/md0 /dev/sda2

den Rest macht das Raid selber, wer mag kann per ‘cat /proc/mdstat’ zuschauen, wie die Platten synchronisieren. Dieser Vorgang geschieht vollautomatisch, man braucht nicht abwarten, bis er abgeschlossen ist. Auch kann der Vorgang durch Reboots unterbrochen werden, er wird automatisch fortgesetzt. Je nach Plattengröße kann es mehrere Stunden in Anspruch nehmen.
am Ende nochmals ein update-grub durchführen und fertig 🙂

Postfix: Emails an bestimmte Empfänger nur von definierten Absendern

Kennt Ihr das Problem? Ihr habt eine Emailadresse für bestimmte Zwecke und möchtet dort Email nur von gewissen Absendern haben? Mit Postfix und seinen Restriction Classes ist dies kein Problem.

Situation:

  • es ist ein fertig konfigurierte Mailserver vorhanden und im Einsatz
  • an eine neue Adresse foo@bar.com wird erstellt
  • man möchte hier allerdings nur Emails von bestimmten Absendern empfangen, zum Beispiel für Mailinglisten oder ähnliches

notwendige Anpassungen:

/etc/postfix/main.cf:

smtpd_restriction_classes = allowed_senders_class_1, allowed_senders_class_2
allowed_senders_class_1 = check_sender_access hash:/etc/postfix/allowed_senders_1, reject
smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/recipients, …

/etc/postfix/recipients:

foo@bar.com      allowed_senders_class_1
foo2@baa.com    allowed_senders_class_2

/etc/postfix/allowed_senders_1:

test1@example.com   OK
myowndomain.de  OK
test2@example.com   REJECT
spamdomain.net  REJECT
boeserSpammer@spam.net  554 we don’t like Spam like this. Drop dead!

Erklärung:

Die Prüfung findet statt, sobald Postfix alle nötigen Informationen gesammelt hat, also wenn der Client den Empfänger rcpt to: bekanntgegeben hat. Durch die Prüfung “check_recipient_access” wird die Datei recipients angezogen. Ist der aktuelle Empfänger hier notiert, wird die Datei berücksichtigt, ansonsten fährt Postfix mit der nächsten Prüfung fort.

Haben wir einen Treffer foo@bar.com so wird Postfix angewiesen die Restriction Class 1 auszuführen. Diese haben wir Postfix natürlich im Vorfeld mitgeteilt. In Folge der genannten Klasse wird die Email nun auf deren Absender geprüft, welche sich in der Datei /etc/postfix/allowed_senders_1 befinden.

Hier kann man Adressen erlauben, bzw spezielle Verbote erteilen. Sofern kein Treffer vorliegt, wird die Email standardmäßig abgelehnt.

Denkbar ist, statt die Adressdaten in Dateien zu schreiben, diese in Datenbanken zu halten. Änderungen sind so einfacher und schneller und dynamischer möglich.

Anwendungsmöglichkeiten:

  • EMail Dienste, welche u.a. über die Absenderadresse authentifizieren (Mail-2-Fax, Mail-2-SMS)
  • spezielle Emailkonten effektiv vor Spam schützen

Tutorial: Email Service mit Debian-Sarge und Postfix 2.1

Der bisherige Mailserver ist im Grunde genommen nach dem Tutorial von Dipl.-Inform. Christoph Haasu und Patrick Jäger
aufgesetzt worden Hier ein Link: http://workaround.org

Dieses Toturial ist erstklassig, sehr einfach auch für Neueinsteiger umzusetzen.
Leider funktionieren einige Sachen nicht ganz so wie ich es mir wünschen würde.

Was ich vermisse: Eine Anleitung zum Einbinden von Mailman oder Sympa in dieses System. Prinzipiell geht dies zwar, allerdings ist es dann mehr ein Pfusch als eine saubere Lösung.

Es ist möglich mit dem System kleinere Mailinglisten zu erstellen! Dies kann man über die Forwardingstabelle realisierungen. Nachteil daran ist leider, das einige Namhafte Emailprovider, solche Mails als Spam zurckweisen. Hier müsste eine Lösung zum Neuschreiben des Senders eingefügt werden.

Dies ist sicher möglich, ich habe aber noch keine brauchbare Lösung gefunden.

Ich werde hier wohl noch einige Zeit investieren

UPDATE:
Mit der oben genannten Lösung ist es doch möglich Mailman oder Sympa einzubinden. Hierzu wird die gewünschte Software standardmässig installiert und die entsprechenden Aliase in die “/etc/aliases” eingetragen.
Um dieses Aliase allerdings erreichen zu können, ist ein kleiner Umweg nötig, da die “virtual_alias_maps” im Postfix Vorrang haben.
Man muss in seiner SQL Tabelle einfach entsprechende forwardings eintragen, die auf den jeweiliges ALIAS @localhost zeigen.

Beispiel: Man mchte eine Mailingliste newsletter@mydomain.org nennen!
Hierzu werden die entsprechen Aliase von Sympa in die /etc/aliases eingetragen (Sympa gibt diese aus), anschliessen wird zu jedem Alias ein Eintrag in die Tabelle forwardings gesetzt, um die eigentlich Empfngeradresse auf localhost umzuleiten!

Christian Bell war so freundlich und hat hierzu ein kurzen Shellscript geschrieben, welches sich entweder ber die Konsole aufrufen bzw in Sympa integrieren lsst!

#! /bin/bash
#
#Script zum generieren von SQL-Insert Befehlen fr die Tabelle forwardings
#Parameter: Mailadresse des Accounts
#Autor: Christian Bell
#Lizenz: GNU-GPL oder so

name=`echo $1 | awk -v FS=”@” ‘{print $1}’`
domain=`echo $1 | awk -v FS=”@” ‘{print $2}’`
echo “INSERT INTO forwardings VALUES(‘$1’, ‘$name@localhost’);”
echo “INSERT INTO forwardings VALUES (‘$name-request@$domain’,’$name-request@localhost’);”
echo “INSERT INTO forwardings VALUES (‘$name-editor@$domain’,’$name-editor@localhost’);”
echo “INSERT INTO forwardings VALUES (‘$name-subscribe@$domain’,’$name-subscribe@localhost’);”
echo “INSERT INTO forwardings VALUES (‘$name-unsubscribe@$domain’,’$name-unsubscribe@localhost’);”
echo “INSERT INTO forwardings VALUES (‘$name-owner@$domain’,’$name-owner@localhost’);”