Owncloud Server

Seit einiger Zeit teste ich einen Owncloud Server auf dem Proempel. Solangsam wird er scheinbar erwachsen. Warum euch das interessieren sollte?

Jeder kennt den Begriff “die Cloud” überall gibt es Anbieter für Onlinespeicher, viele Kostenlos. Aber wo landen die Daten dann, und was macht der Anbieter evtl noch damit?

Google bietet selbiges auch an, was für Smartphone natürlich sehr interessant ist. Man kann Kalender, Dateien, Kontakte alles mit Google synchronisieren, allerdings landen dann alle Daten bei Google, und evtl auch der NSA 🙂

Der Owncloud Server kann all das nun auch, allerdings und da ist der Haken, nicht ganz so einfach, da es nur mit Zusatzapps funktioniert.

Zum einen die Owncloud App selbst, um Dateien zu synchronisieren, dann die App CardDav Free beta, für die Kontakte und zu guter Letzt die App CalDav Free beta für die Kalender.

Und natürlich braucht Ihr einen Zugang zum Owncloud Server, den bekommt Ihr von mir, wenn Ihr wollt.

Die Daten werden auf dem Server verschlüsselt abgelegt, das bedeutet, merkt euch euer Kennwort gut, ohne das sind die Daten wertlos, ich kann sie selbst mit Rootrechten nicht wiederherstellen …

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 🙂

Debian und MMS auf einer TVision S100

Dieser Artikel dient vorerst als Notiz für mich (und andere Interessierte)

Ziel ist ein Debian, bzw ein angepasstes Debvision auf der S100 zum laufen zu bringen, dabei soll die S100 als Diskless Thinclient agieren. Das System soll per Netzwerk gebootet werden.

Das Problem ist, sobald die Netzwerkkarte aktiviert wird, funktioniert USB nimmer, was beim Boot vom USB Stick mit anschließendem Etherboot etwas blöd ist.

Im Netz habe ich dazu folgende Einstellungen für das Bios gefunden:

Plug and Play OS installed => “no”
PCI Latency Timer => “64″
Allocate IRQ to PCI VGA => “no”
Pallette snooping => “disabled”
PCI IDE Busmaster => “enabled”
IRQs 3, 4, 9, 10, 11 => “reserved”
IRQs 5, 7, 14, 15 => “available”;
DMA channel => alle “available”

Es bedarf eines Netboot Servers, Anleitungen dafür gibts jede Menge. Meiner läuft unter Ubuntu, dazu gehört:

DHCP Server, Konfiguration unter /etc/ltsp/dhcp.conf
NFS Server, Verzeichnisfreigabe unter /etc/exports
TFTP Server, Homeverzeichnis = Ausgangspunkt für Pfadangaben /var/lib/tftpboot
PXEBoot Konfiguration unter /var/lib/tftpboot/pxelinux.cfg/default

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