zer(o_0)ne » Linux

KVM LVM Festplatte vergrössern

zer(o_0)ne — Thu, 26 Jan 2012 15:29:21 +0000

Heute war’s mal wieder soweit: die Festplatte einer meiner KVM Instanzen war voll. Also musste ich ran und sie vergrössern. Aufräumen ging nicht, da die Nutzdaten einfach mit der Zeit angewachsen waren. Mit Hilfe eines Freundes hab ich die ganzen Kommandos dann auch wieder in der richtigen Reinfolge auf die Reihe bekommen. Hat auch alles problemlos geklappt und die VM hat nun 10GB mehr platz!

VM shutdown
im Wirt dann das img-File der VM Sicherheitskopieren und dann ein neues RAW-File anlegen. Dieses so dimensionieren, wie viel zusätzlichen Platz man haben möchte:
cp nameVM.img nameVM.img.bck qemu-img create -f raw temp.img 10G mv nameVM.img cat nameVM.img.save temp.img > nameVM.img

VM starten
Dann die VM wieder starten, normal sollte das problemlos gehen und das installierte Linux sollte ohne Probleme starten. Für das System hat sich an sich ja nicht viel geändert. Im laufenden System dann mit fdisk eine neue Partition anlegen. Für fdisk sollte der neue Speicher schon sichtbar sein. Es sollte also erkannt werden, das noch unpartitionierter Platz auf der Festplatte vorhanden ist. Abschließend noch mal neu starten.

Volume vergrössern
Nach dem reboot sollte dann das zusätzlich SDA-Device zur Verfügung stehen. Dieses können wir nun dazu nutzen, das Volume von LVM zu erweitern.

Ein zusätzliches Physical Volume anlegen:
ll /dev/sda* pvcreate /dev/sdaX pvdisplay

Das neue PV der Volume Group hinzufügen:
vgextend vg_name /dev/sdaX vgdisplay

Das Logische Volume auf die volle Größe der VG erweitern:
lvextend /dev/mapper/vg_name-lv_root /dev/sdaX lvdisplay

Zum Schluss dann noch das Dateisystem von Linux auf die Größe des LV anpassen:
resize2fs /dev/mapper/vg_name-lv_root

Abschließend noch mal nachsehen, ob der Platz nun wirklich zur Verfügung steht und fertig!
df -lh

Managing Nginx vHost with Puppet

zer(o_0)ne — Mon, 28 Nov 2011 15:30:15 +0000

Ich beschäftige mich nun seit einiger Zeit mit puppet und bin auch fleissig am Module bauen. Als einer der nächsten Punkte nach allen Standard-System-Diensten war nun Nginx dran. Vorraussetzung für mich war hier, dass auch vHost relativ einfach abgebildet werden können. Nach etwas Bastelei, ein wenig Google und nachdenken war es mir dann gelungen. Hier also mein Ergebnis. Da ich größtenteils nur WordPress verwende ist meine Klasse und mein Template ein wenig daran angepasst, sollte sich aber leicht auch für andere Dinge adaptieren lassen ;)

Man definiert sich im seinem Modul, hier “nginx”, eine neue Klasse. In dieser legt man nun ein Define an. Also quasi eine abstrakte Kasse oder Funktion. Diese belegt man schon mit allen Werten vor, die später jede einzelne vHost-Datei haben soll. Ich benutze hier $title als Übergabe-Variable. siteName ist der vHostname innerhalb des Templates.

class nginx::wordpress{ define site { $siteName = $title

file { "/etc/nginx/sites/$title.conf": ensure => present, owner => "root", group => "root", mode => 0644, content => template("nginx/wordpress.erb"), } }

Nun noch ein Template erstellen. In diesem wird der eigentliche vHost definiert. Mit Extras wie Umleitung auf WWW und Sprechenden-URLs. siteName wird hier jeweils durch den von $title übergebenen Wert ersetzt.

server { listen 80;


        server_name  <%= siteName %>

                     www.<%= siteName %>;
        access_log  /var/log/nginx/access.<%= siteName %>.log  main;

        error_log  /var/log/nginx/error.<%= siteName %>.log warn;
        root   /usr/share/nginx/sites/<%= siteName %>;

        index  index.html index.php;
        try_files $uri $uri/ /blog/index.php?q=$uri&$args;
        if ($host != 'www.<%= siteName %>' ) {

            rewrite  ^/(.*)$  http://www.<%= siteName %>/$1  permanent;

        }

location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME /usr/share/nginx/sites/<%= siteName %>$fastcgi_script_name; include fastcgi_params; } }

Und jetzt kann man z.B. in einer Konfigurationsklasse von Nginx einfach das Define aufrufen, ihm einen Hostnamen übergeben und da durch erhält man einen vHost. Hier muss dann vorab nur noch die oben erstellte klasse inkludiert werden.

nginx::wordpress::site {"zero0ne.de":}

SpamAssassin

zer(o_0)ne — Mon, 25 Jul 2011 12:40:00 +0000

SpamAssassin ist ein Filterprogramm zu Spam-Bekämpfung. Dabei Scannt es nicht nur die Header, wie z.B. Postfix, sondern die gesamte Mail. Es setzt dabei multiple Wörterbücher ein und ist selbst lernend und führt eigenständig Updates dieser Wörterbücher durch. Es wird der gesamte Body der Mail gescannt und gewertet. D.h. der Inhalt wird maschinell ausgewertet. Dies kann in einigen fällen Datenschutzrechtlich bedenklich sein. Beim Scannen wird dann auf Wortzusammenhänge und Anzahl von Links geachtet. Aber auch es werden auch noch wesentlich komplexere Algorithmen eingesetzt zur Vermeidung von sogenannten „false-positives“. Also fälschlicherweise als Spam erkannte Mails. Die Konfiguration von Spamassassin findet sich unter „/etc/spamassassin/“. Hier kann festgelegt werden, welcher Anti-Spamtechniken sich Spamassassin bedient. Standardmäßig ist dies bayes. In unseren Fall wird dann aber noch pyzor und dcc verwendet.

CalmAV

zer(o_0)ne — Mon, 25 Jul 2011 12:38:32 +0000

ClamAV

ClamAV ist ein freier OpenSource Virenscanner. Er ist der de-facto Standard in Linux-Mailsystemen. Er wird auch über AMaViS angesteuert. Sollte ClamAV etwas verdächtiges finden, reportet er dies an AMaViS zurück, welches dann die Mail aus dem Verkehr zieht. ClamAV verfügt über einen automatischen Update-Mechanismus, sodass er selbst dafür sorgt, das seine Bibliotheken immer aktuell sind. Um ClamAV über AMaViS zu aktivieren, muss man in der AmaViS Konfiguration „15-content_filter_mode“ die beiden „@bypass“-Regeln aktivieren. Danach kann ClamAV über AmaViS angesprochen werden.

AMaViS (A Mail Virus Scanner)

zer(o_0)ne — Mon, 25 Jul 2011 12:36:54 +0000

AMaViS allgemein

Ein weiteres Support-Programm außerhalb von Postfix ist AMaViS. Im eigentlichen steht AMaViS für A Mail Virus Scanner. Doch kann es mehr als nur Mails auf Viren zu prüfen. Mittlerweile ist es auch ein Spam und Maleware-Scanner. Dazu behilft sich AMaViS selbst wieder mit 2 weiteren Programmen. Dies ist einmal ClamAV, der OpenSource-Virenscanner und als zweites wird Spamassassin zum scannen nach Spam verwendet.

AMaViS fungiert dabei selbst als Mini-Mailserver. Dieser läuft dann nur auf Localhost auf Port 10024. Postfix macht auch noch einen Port auf, und zwar Port 10025 nimm man dort üblicher Weise. Die beiden schicken sich dann die Mails über diese beiden Ports hin und her. Das funktioniert dann so: Postfix nimmt eine Mail an, führt seine bisherigen Checks durch, Greylistet evtl., besteht diese Mail die Test, wird sie an AMaViS weitergereicht, aber noch nicht endgültig angenommen. Dieser übergibt sie dann direkt an ClamAV, wo sie nach Viren durch-scannt wird. Werden Viren gefunden, wird Postfix angewiesen die Mail abzuweisen. Werden keine Viren gefunden wird dann auf Spam geprüft. Hierbei werden verschiedene Techniken benutzt, einmal wird der Text gegen eine Datenbank mit oft vorkommenden Spammeldungen geprüft, andererseits wird auch auf das vorkommen von Links und die Formatierung der Links geachtet. Das Ganze läuft in einen Scorering zusammen, was in den Header geschrieben wird. Liegt der Score zwischen 0 und 5.00 wird die Mail meist als kein Spam klassifiziert oder höchstens als verdächtig im Betreff getagt. Liegt er drüber, wird er meist entweder ins Quarantäne-Postfach umgelenkt oder besser gleich Postfix angewiesen die Mail abzulehnen. Wenn die Mail hier ohne Weiteres durchkommt, wird sie wieder an Postfix übergeben und weiterverarbeitet. AMaViS und Spamassassin kennen natürlich auch wieder White- und Blacklists. Um gewisse Domains von vorhnherein zu erlauben oder zu verbieten. Auch kann man in der AmaViS-Konfiguration in „/etc/amavis/local.cf“ und den danebenliegen Konfigurationsdateien das Verhalten noch anpassen. Eben solche Dinge wie, ob Mails abgelehnt oder in Quarantäne verschoben werden.

AMaViS kann in der Konfiguration von Postfix auf zwei Arten aktiviert werden. Entweder über „content_filter“ oder über „smtpd-proxy“. Logisch gesehen machen die beiden Direktiven das selbe, nur technisch gesehen gibt es einige Unterschiede. Wir werden zu Anfang noch „content_filter“ verwenden. Dies ist die bekannte und getestet Lösung. Es ist jedoch geplant auf „smptd_proxy“ umzusteigen. Diese bietet technische gesehen einige Vorteile in der Abarbeitung der Mails.

AMaViS wird nun also per content_filter eingebunden. Dies ist ein eigener Parameter und steht außerhalb der bis jetzt verwendeten smtpd_recipient_restrictions. In einer eigene Zeile wird einfach „content_filter = amavis:[127.0.0.1]:10024 “ in der main.cf eingefügt. Nun muss aber noch zusätzlich in der master.cf ein weiterer Eintrag ganz am ende der Datei hinzugefügt werden, da es sonst nicht funktioniert. Denn man muss Postfix noch sagen, das es zu Port 10024, den AMaViS aufmacht, den korrespondierenden Port 10025 aufmachen soll.

Courier IMAP/POP3 Server

zer(o_0)ne — Mon, 25 Jul 2011 12:15:46 +0000

Courier allgemein

Courier stellt im Mailserver-Konstrukt den Zugang für den Benutzer zu seinen Mails dar. Courier ist dabei auch wieder ein Multi-Server, da er 4 Services auf einmal stellt. Courier ist eine IMAP, IMAP-S, POP3 und POP3S Server. Wobei das S immer für Secure stehen soll, hießt eine SSL-verschlüsselte Verbindung genutzt wird. Was Courier an Standard Einstellungen mitbringt kann man eigentlich so weiter nutzen. Das einzige wobei man etwas nachjustieren muss ist der Wert für „MAXDAEMONS“ und „MAXPERIP“. Dies legt einerseits fest, wie viele Threads für den entsprechenden Server erstellt werden und andererseits wie oft man sich von der gleichen IP aus einloggen darf. Courier benutzt für die verschiedenen Protokolle die Standardports. D.h. für IMAP 143, für IMAPS 993, für POP3 110 und für POP3S 995. Diese lassen sich in den Konfigs von Courier aber auch ganz leicht anpassen.

Courier und SSL

Was man weiterhin beachten sollte ist, das Courier IMAP und POP3 eigene SSL Zertifikate verwenden. Mann kann diese aber einfach gegen seine eintauschen. Muss dann aber auch wieder darauf achten das diese im PEM-Format vorliegen und auch das CA-Bundle eingebunden wird. Tut man dies nicht, werden die Benutzer beim abholen der Mails über gesicherte Verbindungen darauf hingewiesen, das man ein selbst unterschriebenes Zertifikat benutzt. Dies wird allgemein als unsicher erachtet, was aber nicht immer der Fall sein muss. Die Zertifikate liegen standardmäßig im selben Verzeichnis wie die Konfigurationsdateien. Man kann diese aber auch woanders ablegen, muss dann aber in der „IMAP-SSL“-Konfig den Pfad zu diesen korrigieren. Das CA-Bundle bindet man mit der Option „TLS_TRUSTCERTS“ ein. Gleiches gilt natürlich auch für POP3-SSL.

mit Postfix Mails pro Domain filtern

zer(o_0)ne — Thu, 30 Jun 2011 14:09:26 +0000

Will man nicht alles was rein kommt filtern, sondern nur bestimmte Domains, so muss man sein „main.cfg“ auf folgende Weise anpassen. Zu erst muss man dann den Eintrag für „amavis“ raus nehmen. Also die Zeile mit „content_filter=“ und soweit vorhanden „receive_override_options = no_address_mappings“. Somit würde jetzt keine Mail mehr an AMaViS weitergegeben werden. Um nun pro Domain zu filtern fügt man den „smtpd_recipient_restrictions“ zwei Regeln hinzu. Dies wären „check_recipient_access“ für eingehende Mails und „check_sender_access“ für ausgehende Mails. Als Parameter haben diese Regeln jeweils eine gehashte Datei mit einer Liste von Domains. Zum Beispiel: „hash:/etc/postfix/filter_recipient_domains“ für eingehende Mails. Der Aufbau dieser Filterlisten sieht so aus: „example.com FILTER amavis:[127.0.0.1]:10024“. Eine Filterliste ist eine simple Textdatei, welche dann von Postfix gehasht wird. Gehasht wird mit „postmap dateiname“. Damit werden dann Mails, welche für „example.com“ hereinkommen an AMaViS weitergegeben. Will man auch ausgehende Mails überprüfen, fügt man den selben Text in „/etc/postfix/filter_sender_domains“ hinzu.

Postfix SMTP Server

zer(o_0)ne — Thu, 30 Jun 2011 14:01:25 +0000

Ein SMTP-Server nimmt Mails an und versendet diese. Er ist das eigentliche Herz des Email-Server-Komplex. Dabei heißt annehmen nur, die Mails ablegen. Sie dem Benutzer zugänglich machen, dafür ist ein anderer Server zuständig. Postfix basiert im wesentlichen nur auf 2 Konfig-Dateien. Das ist einmal die „master.cfg“ und einmal die „main.cfg“. Hier wird definiert wie viele Threads laufen, auf welchen Ports er lauscht und wie eingehende und ausgehende Mails geprüft werden.

master.cf

In der „master.cf“ kann man eigentlich das meiste so lassen wie es ist. Selten besteht bedarf hier etwas zu ändern. Definiert sind hier alle Subprozesse von Postfix und deren Optionen. Z.B. kann man hier einen weiteren SMTP-Port definieren um die Übergabe an Amavis zu regeln. Auch kann man hier schon Checks durchführen, bevor die Mail überhaupt richtig angenommen wurde. Dies sollte man in der Regel aber der „main.cf“ überlassen.

main.cf

Die „main.cf“ definiert wirklich alles weitere, was über die Helfershelfer und die Ports hinausgeht. Unter anderen z.B. Wie sich der Server nennt, auf welche Domains er achten soll, welche Annahmechecks durchgeführt werden, verschiedene Limits und wo die Mailboxen liegen. Mit zusätzlichen Modulen kann man die Mailboxen auch über MySQL definieren. dazu bedarf es dann noch einiger Helfer-Konfigurationen. Diese sind aber selbsterklärend, da in ihnen nur eine MySQL-Verbindung und ein SELECT steht. Neben den ganzen Laufzeit- und Domaineinstellungen sind hier aber die Annahmechecks am wichtigsten. Es gibt verschiedene Level von „restrictions“ in denen man filtern kann. Am meisten Sinn macht aber eigentlich nur „smtpd_recipient_restrictions“.

Hier ein Beispiel wie die „restriction“ aussehen könnte:

smtpd_recipient_restrictions = # Keine unsauberen Mails annehmen reject_non_fqdn_recipient, reject_unknown_recipient_domain, # eigene saeuberung der adresse check_recipient_mx_access cidr:/etc/postfix/mx_access, check_recipient_access pcre:/etc/postfix/recipient_checks.pcre, check_helo_access hash:/etc/postfix/helo_blacklist, # Eiegne Nutzer erlauben permit_sasl_authenticated, permit_mynetworks, # SPAMSCHUTZ RBLs reject_rbl_client zen.spamhaus.org, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client bl.spamcop.net, reject_rbl_client dnsbl.njabl.org, # relay-empfaenger reject_unverified_recipient, # backup MX permit_mx_backup, reject_unauth_destination, permit

Von oben nach unten erklärt:

Am Anfang wir geprüft ob der Absender eine Voll qualifizierte Domain-Adresse hat. Anschließend wird geprüft ob die Domain bekannt (erreichbar) ist. Mit MX-Access wird geprüft ob der Absender aus einen Gültigen IP-Netz kommt. Hierauf wird dann geprüft, ob die Mail vom Aufbau her stimmt, also z.B. ob genau ein „@“ darin enthalten ist. Mit der Regel „check_helo_access“ wird überprüft ob jemand versucht mit der IP des Servers aber einer anderen, nicht bekannte Domain, Mail einzuliefern. Anschließend erlaubt man das per SASL authentifizierte Benutzer Kontakt zum Server aufnehmen dürfen. Weiterhin werden auch die eigenen IPs erlaubt, sodass man sich nicht selbst aussperrt. Danach wird mit „reject_rbl_*“ verschiedenen „DNS Black Lists“ abgefragt, ob der einliefernde Mailserver nicht schon für Spam bekannt ist. Anschließend werden Mails abgewiesen, welche einen unbekannten Empfänger haben. Letztendlich wird noch erlaubt das ein Backup-MX erlaubt. Es wird dann noch verboten, das an Adressen versendet wird, welche nicht erlaubt sind oder nicht existieren. Abschließen wird noch alles erlaubt was bis jetzt nicht verboten ist.

RBL im Detail

Auszug aus der Wikipedia (http://de.wikipedia.org/wiki/Realtime_Blackhole_List, 13.10.2009):

Als Realtime Blackhole List (RBL) oder DNS-based Blackhole List (DNSBL) werden in Echtzeit (realtime) abfragbare Schwarze Listen bezeichnet, die verwendet werden, um E-Mail zweifelhafter Herkunft als Spam zu klassifizieren. In den meisten RBLs werden IP-Adressen von Rechnern gelistet, von denen in der Vergangenheit Spam versendet wurde – einige Listen enthalten auch Quellen von Computerviren und anderer Malware. Heute handelt es sich bei diesen Rechnern meist um trojanisierte PCs oder seltener offene Mail-Relays, die von Spammern missbraucht wurden. Diese Listen können Mailserver oder Spam-Erkennungssoftware (z. B. Spamassassin) beim Eingang einer Mail nahezu in Echtzeit über das DNS-Protokoll auswerten und bei positivem Ergebnis die Annahme der Mail verweigern, die Annahme der Mail verzögern (Teergrube, Greylisting) oder die Mail so markieren, dass sie ohne großen Aufwand vom Empfänger gefiltert werden kann.

Es werden die Listen von Spamhaus.org, NiXSpam (Liste der iX), SpamCop.net und NJABL.org empfohlen. Diese haben sich in der Vergangenheit als sehr zuverlässig erwiesen und einen geringen Anteil an False-Positives.

postconf

Will man sich die Konfig welche gerade geladen ist noch einmal ansehen, kann man dazu das Kommando „postconf“ nehmen. Mit „postconf -d“ kann man sich alle Defaulteinstellungen anzeigen lassen. Dies gibt sehr viel Output, da wirklich fast jede Variable ausgegeben wird. Übersichtlicher wird das ganze wenn man „postconf -n“, welche Variablen anzeigt, welche nicht defaultmäßig belegt sind. Also verändert wurden. Neben dem Anzeigen der Konfigs, kann man mit postconf auch Variablen setzen. Dazu gibt man „postconf -e ‘PARAMETER=WERT’ “.

postqueue

Mit dem Kommando „postqueue“ kann man sich die Warteschlange des Servers ansehen. Hier liegen Mails die noch nicht versendet wurden, oder zurück kamen und auf einen erneuten Zustellversuch warten. Dabei kann man sich die Queue ansehen und auch einen erneuten Zustellversuchen veranlassen. Anzeigen kann man sich die Queue mit „postqueue -p“. Dabei wird dann angezeigt, welche ID die Mail hat. Dies ist wichtig wenn man in Logdateien danach sucht. Weiterhin wird auch angezeigt, welche Größe die Mail hat, wann sie ursprünglich eintraf und von wem an wen sie gesendet wurde. Hängt man den noch ein „-v“ an, bekommt man noch einige Debug-Meldungen ausgegeben. Gibt man mehr V’s an, werden noch mehr Ausgaben produziert. Mit „postconf -f“ veranlasst man Postfix dazu, alle Mails in der Queue noch mal versuchen zu versenden. Mit „postqueue -i ID“ veranlasst man Postfix genau die Mail mit der übergebenen ID nochmals zuzustellen. Weiterhin kann man dann auch noch mit „postqueue -s Domain“ den erneuten Versandt aller Mails dieser Domain zu veranlassen. Was postqueue nicht kann, ist das löschen einer Mail aus der Queue.

postsuper

Da postqueue keine Mails löschen kann, nimmt man „postsuper“. Dieses ist zur Queue-Steuerung da. Man kann Queue-Mails löschen, in eine Queue stecken oder sie auch wieder herausholen. Will man also eine Mail aus der Queue entfernen gibt man „postsuper -d ID“ an. Will man die gesamte Queue löschen nimmt man „postsuper -d ALL“. Wobei darauf zu achten ist, das das „ALL“ auch wirklich groß geschrieben wird, da es sonst nicht klappt. Hinter dem ALL kann man auch noch eine Queue angeben. Muss man aber nicht. Man kann auch eine Mail auf „on Hold“ setzten. das heißt sie temporär stoppen. Das tut man indem man „postsuper -h ID“ eingibt. Auch hier trifft wieder das mit ALL und der optionalen Queue Angabe zu. Um die Mail wieder weiterzubearbeiten holt man sie mit „postsuper -H ID“ wieder ins aktive System.

Das Postfix-Log

Postfix schreibt im normal Fall unter „/var/log/“ seine Log-Dateien. Hierbei schreibt es immer 4 Logs parallel. Einmal all-umfassend „mail.log“. Hier steht alles drin was Postfix und seine Helfershelfer so von sich geben. Dann gibt es noch die drei Dateien „mail.info“ , „mail.warn“ und „mail.err“. Hier stehen dann entsprechend der Namen jeweils nur die Logs vom Level Info, Warning und Error drin. Die Logs werden dabei immer ungefähr 10-14 Tage in 8 Versionen vorgehalten.

pflogsum

„pflogsum“ erstellt aus dem Logfile von Postfix eine Zusammenfassung. Wie viele Mails prozesst wurden, wie viele abgelehnt und geblockt. Welche SMTP-Fehler auftraten. Top-Senden und Top-Empfänger. Wie die Verteilung der Mails über den Tag hinweg waren und noch andere statistische Werte. Damit kann man den Mailserver ein wenig im blick behalten und frühzeitig Fehler erkennen. Ein aufruf von „pflogsum“ für normaler Weise zur Ausgabe in der CLI. Man kann das Ganze aber auch in eine Mail umleiten und dann per Cronjob einmal am Tag versenden lassen.

pflogsumm --rej_add_from --problems_first --smtpd_stats -h 15 -u 15 --no_reject_detail --no_smtpd_warnings -d today /var/log/mail.log | mail -s "Mailserver Report - `date`" monitoring@domain.de

Aufbau eines Linux Mailserver

zer(o_0)ne — Mon, 27 Jun 2011 08:35:09 +0000

Hier möchte ich kurz den von mir favorisierten Aufbau eines “Mailserver” unter Linux beschreiben. Im Eigentlichen ist es nicht ein „Mailserver“ sondern mehrere Dienste die zusammenarbeiten und im Endeffekt nach außen als ein Server auftreten. Der Mailserver-Komplex besteht aus:

Service-Liste:

Postfix SMTP-Server
AmaVis
- Spamassasin
  - pyszor
  - dcc
  - bayes
- ClamAV

Courier
- IMAP-Server
- POP3-Server

Schematischer Aufbau:

Annahme Von E-Mails

Kommen E-Mails vom Internet aus am Mail-Server an, werden diese zunächst angenommen und dann geprüft. Zu erst wird der Aufbau der E-Mail geprüft. Ist dieser nicht FQDN-Konform wird die E-Mail abgewiesen, da FQDN-Unkonforme (FQDN = Full Qualified Domain Name = Standardmäßiger Domainname) E-Mails nicht im Internet vorkommen, außer sie werden von Spammern verwendet. Danach wird geprüft ob der einliefernde Mailserver per Reserve DNS und EHLO-Check legitim ist. Darauf wird dann noch geprüft ob der Empfänger FQDN-konform ist. Ist dies der Fall wird die IP des einliefernden Servers gegen verschiedene Spam-Listen getestet. Sollte dies positiv sein, wird die E-Mail abgewiesen. Ist das Ergebnis negativ wird die E-Mail an AMaViS übergeben. Dieser durch-scannt mit Hilfe von Spamassassin die E-Mail nach Spam-Merkmalen. Auch wird durch AMaViS die E-Mail auf Viren geprüft. Dies geschieht mit Hilfe von ClamAV. Wenn die E-Mail dann letztendlich auch diese Prüfungen bestanden hat, wird sie auf die Festplatte ins MailDir des betreffenden Empfängers gespeichert. Dort liegt sie dann als simple Textdatei vor.

Nun kann sie durch ein Mailprogramm abgerufen werden. Dies geschieht indem das Mailprogramm zu Courier eine Verbindung aufbaut und nach neuen Mails fragt. Courier biete dazu die Protokolle POP3 und IMAP an. Darüber werden dann die als Textdateien gespeicherten E-Mail aus dem Maildir ausgelesen und an das Mailprogramm gesendet.

Versenden von E-Mails

Vor dem Versenden durch den SMTP-Server wird die E-Mail wieder auf Viren und Spam geprüft. Ein Greylisting findet in diese Richtung nicht statt. Die Anti-Spam-Listen werden in diese Richtung auch nicht abgefragt. Im Anschluss wird die Mail wieder darauf geprüft ob Sender- und Empfänger-Adresse FQDN-konform sind. Auch wird noch geprüft ob der empfangende Mailserver legitim ist. Passiert die Mail die Tests wird sie vom SMTP versendet.

virt-install.sh

zer(o_0)ne — Mon, 20 Jun 2011 21:08:15 +0000

Hier mal ein kleines nützliches Skript zum erstellen von KVM-VMs. Beim Aufrufen lässt sich der Name, der RAM und die Festplattengrösse setzen. Der Rest wird vorbelegt. Dann brauch mann nicht immer soviel tippen und kann einfach ein Skript auffrufen. So sich dann vllt auch einen Mechanismus für “on-demand” VM deployment bauen.

Hier nun also das Skript:

#!/bin/bash
NAME=$1
RAM=$2
HDD=$3

virt-install –connect qemu:///system -n $NAME -r $RAM -vcpus=1 \
-f /var/lib/libvirt/images/$NAME.img -s $HDD \
–network=bridge:vibr0 –vnc –accelerate -v \
-c /var/lib/libvirt/images/ISOs/Fedora-15-x86_64-DVD.iso \
–os-type=linux –noautoconsole

danbooru auf Ubuntu 10.4 LTS installieren

zer(o_0)ne — Thu, 21 Apr 2011 14:08:09 +0000

Wer ein wenig in der Anime-Szene unterwegs ist wird die zahlreichen Image-Boards kennen. Ein bekanntes und doch recht beliebtes System ist dabei Danbooru (link). Danbooru ist Community und System zu gleich. Es ist sehr umfangreich und bietet viele funktionen, wie z.B. automatisches Rezise von grossen Bildern. Doch gilt es auch als sehr schwer zu installieren. Es ist nämlich keine simple PHP-Anwendung die man in sein Doc-Root kopiert und dann starten kann. Nein, Danbooru baut auf Rails auf und bietet dadurch eine Menge mehr. Doch leider ist es etwas schlecht dokumentiert. Und was Dokumentiert ist, ist veraltet. Ich wollte nun den aktuelle Trunk auf dem aktuellen Ubuntu LTS installieren. Das Klappte an sich von der installation her auch. Doch gab es dann im anschluss ein DB Problem, welches ich bis jetzt noch nicht lösen konnte. Mit Version 1.16.0 von Danbooru klappt allerdings alles! So lässt es sich ohne Probleme auf Ubuntu installieren. Mann muss nur darauf achten, das man keine zu Neue Rails-Version nimmt, da es sonst wieder knallt. Ich hab nun alles mit Rails 2.2.2 installiert. Der aufbau sieht dabei so aus, das Ich danbooru mit Rails betreibe, als Webserver Unicorn in Verbindung mit memcache nehme und das ganze über einen Nginx-Proxy laufen lasse.

Damit das alles ein wenig leichter zu installieren ist, hab ich mich an dem veralteten INSTALL.debian Skript von Danbooru orientiert und hier und da was ergänz oder abgeändert.

#### http://tech.tomgoren.com/archives/245
#### http://animebsd.net/archives/2528
#### http://trac.donmai.us/browser/danbooru/trunk/INSTALL.debian

als Download: INSTALL.debian

Hier das install script:
#!/bin/bash

#### http://tech.tomgoren.com/archives/245 #### http://animebsd.net/archives/2528 #### http://trac.donmai.us/browser/danbooru/trunk/INSTALL.debian

#### root@danbooru:/var/www/danbooru# vim app/models/post_methods/file_methods.rb #### sftp albert maskieren


if [ $USER != root ] ; then

echo "You must run this script as root"

exit 1

fi
echo "Danbooru Install"

echo "This script will install Ruby, Rails, PostgreSQL, Unicorn, and Nginx. By the end,"

echo "you should be able to connect to the server and create an account."

echo

echo "It will create a new user called danbooru which will run the Danbooru"

echo "processes. It will download the latest trunk copy or v1.16.0 and install it in"

echo "/var/www/danbooru. It will run unicorn, starting on port 8050"

echo

echo

echo -n "Enter the hostname for this server (ex: danbooru.donmai.us): "

read hostname
if [ -z $hostname ] ; then

echo "Must enter a hostname"

exit 1

fi
echo -n "Enter a name for the site (default: Danbooru): "

read sitename
if [ -z $sitename ] ; then

sitename=Danbooru

fi
echo -n "Enter a path for danbooru (default: /var/www/danbooru): "

read danboorupath
if [ -z $danboorupath ] ; then

danboorupath="/var/www/danbooru"

fi
echo -n "Which danbooru version? [trunk, 1.16.0, 1.18.0]"

read danbooruversion
if [ -z $danbooruversion ] ; then

danbooruversion="1.16.0"

fi
# Install packages

echo "install required packages via apt-get"

apt-get -qq -y install sudo gcc g++ make libreadline5-dev zlib1g-dev flex bison libgd2-noxpm libgd2-noxpm-dev bzip2 postgresql-8.4 postgresql-contrib-8.4 libpq-dev ruby ruby1.8-dev ri irb rdoc rubygems ragel memcached libmemcache-dev subversion nginx rake libopenssl-ruby libxml2-dev libxslt-dev byobu vim htop
# Install Ruby gems

echo "install Ruby/Rails/Unicorn"
gem install hoe --version=2.2.0 --no-ri --no-rdoc
for i in postgres diff-lcs html5 unicorn memcache-client aws-s3 json mechanize net-sftp sys-cpu ; do gem install $i --no-ri --no-rdoc ; done
gem install rails --version=2.2.2 --no-ri --no-rdoc
# Create user account

echo "create danbooru user, allow db access"
useradd -m danbooru

PG_HBA_FILE="/etc/postgresql/8.4/main/pg_hba.conf"

echo "local    all         postgres,danbooru                              trust" > $PG_HBA_FILE

echo "host     all         postgres,danbooru          127.0.0.1/32        trust" >> $PG_HBA_FILE
if [ -f /etc/init.d/postgresql-8.4 ]; then /etc/init.d/postgresql-8.4 restart; else /etc/init.d/postgresql restart; fi
# Install Danbooru

cd /var/www
echo "installing danbooru source"
case "$danbooruversion" in

1.16.0)

echo "installing version: 1.16.0"

svn export svn://donmai.us/danbooru/tags/danbooru-1.16.0 danbooru

;;

1.18.0)

echo "installing version: 1.18.0"

svn export svn://donmai.us/danbooru/tags/danbooru-1.18.0 danbooru

;;

trunk)

echo "installing version: trunk"

svn export svn://donmai.us/danbooru/trunk danbooru

;;

tar16)

echo "deflating tgz danbooru-1.16.0.tgz"

tar xfz /tmp/danbooru-1.16.0.tgz -C /var/www

;;

tar18)

echo "deflating tgz danbooru-1.18.0.tgz"

tar xfz /tmp/danbooru-1.18.0.tgz -C /var/www

;;

esac
chown -R danbooru:danbooru danbooru

cd danbooru

mkdir -p public/data/sample

cd config

cp database.yml.example database.yml

cp local_config.rb.example local_config.rb

sed -i -e "s/DAN_HOSTNAME/$hostname/g" local_config.rb

sed -i -e "s/DAN_SITENAME/$sitename/g" local_config.rb

cd ../lib/danbooru_image_resizer

ruby extconf.rb

make

cd ../..
### Database anlegen

echo "installing danbooru database"
sudo -u postgres createuser -s danbooru

sudo -u danbooru createdb danbooru

sudo -u danbooru createdb danbooru_dev

sudo -u danbooru createdb danbooru_test

sudo -u danbooru psql danbooru < db/postgres.sql

sudo -u danbooru psql danbooru_dev < db/postgres.sql

sudo -u danbooru psql danbooru_test < db/postgres.sql if [ "$danbooruversion" = "1.18.0" || "$danbooruversion" = "trunk" ]; then 	echo "initialising database" 	 	script/db-init.sh 	script/db-init.sh 	script/db-init.sh 	 	#### app/controller/application_controller in application umbenenen 	mv app/controllers/application_controller.rb app/controllers/application.rb 	#### config/envirnment.rb anpassen. ruby version rausnehmen 	sed -i -e "/^RAILS_GEM_VERSION/d" config/environment.rb 	### middle ware entfernen 	sed -i -e "/^config.middleware.use/d" config/environments/development.rb fi echo "initialising production database" sudo -u danbooru RAILS_ENV=production rake db:migrate # Set up nginx echo "generating nginx danbooru conf" nginx_danbooru_conf="/etc/nginx/sites-enabled/danbooru.conf" echo 'server {' > $nginx_danbooru_conf

echo '  listen 80;' >> $nginx_danbooru_conf

echo "  server_name $hostname;" >> $nginx_danbooru_conf

echo '  location ~ /\.svn { deny all; }' >> $nginx_danbooru_conf

echo '  location / {' >> $nginx_danbooru_conf

echo "    root $danboorupath/public;" >> $nginx_danbooru_conf

echo '    try_files $uri /maintenance.html @danbooru;' >> $nginx_danbooru_conf

echo '    client_max_body_size 30m;' >> $nginx_danbooru_conf

echo '    expires max;' >> $nginx_danbooru_conf

echo '  }' >> $nginx_danbooru_conf

echo '  location @danbooru {' >> $nginx_danbooru_conf

echo '    proxy_set_header X-Real-IP $remote_addr;' >> $nginx_danbooru_conf

echo '    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;' >> $nginx_danbooru_conf

echo '    proxy_set_header Host $http_host;' >> $nginx_danbooru_conf

echo '    proxy_redirect off;' >> $nginx_danbooru_conf

echo '    proxy_pass http://127.0.0.1:8050;' >> $nginx_danbooru_conf

echo '  }' >> $nginx_danbooru_conf

echo '}' >> $nginx_danbooru_conf
/etc/init.d/nginx restart
### unicorn config file

echo "generating unicorn danoobru conf"
mkdir /etc/unicorn

unicorn_conf="/etc/unicorn/danbooru.conf"

echo "RAILS_ROOT=$danboorupath" > $unicorn_conf

echo "RAILS_ENV=production" >> $unicorn_conf
### unicorn danbooru-config file

echo "generating danbooru unicorn conf"
danbooru_unicorn_conf="$danboorupath/config/unicorn.rb"

echo "app_path = \"$danboorupath\"" > $danbooru_unicorn_conf

echo -n >> $danbooru_unicorn_conf

echo 'listen 8050' >> $danbooru_unicorn_conf

echo 'worker_processes 2' >> $danbooru_unicorn_conf

echo 'pid "#{app_path}/tmp/pids/unicorn.pid"' >> $danbooru_unicorn_conf

echo 'stderr_path "#{app_path}/log/unicorn.log"' >> $danbooru_unicorn_conf

echo 'stdout_path "#{app_path}/log/unicorn.log"' >> $danbooru_unicorn_conf
### unicron init skript

echo "downloading unicorn init skript"
unicorn_rails_path="/var/lib/gems/1.8/bin/unicorn_rails"

cd /etc/init.d/

wget http://tech.tomgoren.com/wp-content/uploads/unicorn_init.gz

gunzip unicorn_init.gz

sed -i -e "s|/usr/local/bin/unicorn_rails|$unicorn_rails_path|g" unicorn_init

chmod +x unicorn_init

/etc/init.d/unicorn_init start

echo echo echo echo "I'm done!" echo "You should probably set the password for the danbooru account (run passwd danbooru)."

Tomcat: too many open files

zer(o_0)ne — Mon, 28 Feb 2011 08:50:04 +0000

Dieses Problem tritt häufig auf, wenn man mehrere Tomcats unter einen unprivilegierten Benutzer laufen lässt. Dies liegt daran, das für diese Benutzer strengere Regeln gelten, was das öffnen von Dateien und belegen von System-Ressourcen angeht. Doch kann man dies relativ leicht beheben. Und zwar in dem man das „open file“- Limit erhöht. Normalerweise liegt dies bei 1024 Dateien pro Prozess die gleichzeitig geöffnet sein dürfen. Zu erst kann man den aktuellen Stand einmal überprüfen mit „lsof |grep java|wc -l“. Damit sollte einen die Gesamtanzahl aller offen Dateien für die Prozesse von Java ausgegeben werden. Jetzt kann man das „open file“-Limit auf zwei Arten versuchen zu erhöhen. Einmal mit den sogenannten „soft-limits“ in der Datei „/etc/security/limits.conf“. Dort könnte man nun einmal „* soft nofile 65535“ und einmal „* hard nofile 65535“ eintragen. Allerdings zeigte sich, das dies auf einigen Server nicht zum gewünschten Ergebnis führte. Deswegen wird die zweite Lösung favorisiert. Diese besteht darin über den root-Benutzer mit „ulimit“ das Limit zu erhöhen. mit „ulimit -a“ kann man sich die aktuellen Limits ansehen. Mit „ulmit -n “ kann man das Limit für die geöffneten Dateien erhöhen. Gibt man es nur einmal auf der Konsole ein, gilt die nur temporär. Um dies auf Dauer zu übernehmen schreibt man es entweder in die „.bashrc“ von root oder in die „/etc/rc.local“.

Mailserver Aufbau (grob)

zer(o_0)ne — Fri, 18 Feb 2011 09:23:38 +0000

Hier mal ein Schema was ich vor einige Zeit erstellt habe um einen Mailserver zu erklären. Ist vllt nicht ganz richtig, aber es hatte seinen Zweck erfüllt.

Google Chrome für Ubuntu/Debian

zer(o_0)ne — Fri, 20 Nov 2009 00:19:41 +0000

Lange hab ich mich geärgert das es Google Chrome nur für Windows gibt. Wollt den auch auf meinen Linux laufen haben. Doch offizielle von Google gabs da nur ne warteliste, wo man sich eintragen konnte. Nun hab ich gestern in der NFSW-Wave gelesen, das es bereits eine Version für Linux gibt die auch sehr gut läuft, auch wenn sie noch als “unstable” geführt werden würde.

Wie kommt man nun dran? einfach:

deb http://dl.google.com/linux/deb/ stable main

in die /etc/apt/sources.list einffügen. Dann brauchen wir noch den Key dazu. also noch den Key runterladen mit:

wget http://dl.google.com/linux/linux_signing_key.pub

Da nach fügen wir den Key dann zu apt-get hinzu. Das machen wir mit apt-key. Und zwar so:

sudo apt-key add linux_signing_key.pub

Haben wir dies getan, können wir mal unsere Repositorylisten updaten. Einfach das überlich normale Update:

apt-get update

Und nun sind wir auch schon fast durch, war ja nicht so schwer bis jetzt oder? Schwerer wirds auch nicht mehr ;) Nun muss man nämlich nur noch mit apt-get oder aptitude das Paket “google-chrome” Paket installieren.

apt-get install google-chrome

Und schon sind wir fertig. Nun finden wir’s im Menü unter dem Punkt “Internet”. Sollte eigentlich auch einfach so starten. Tat’s bei mir jedenfalls. Läuft auch wunderbar. Noch keinen Absturz gehabt. Läuft auch schneller und besser als der Firefox, gefühlt. Ich hab da keine genauen Messungen gemacht. Jedenfalls läuft GooleWave darin schon mal 100% besser als im Firefox.

Twitter-Updates per Bash

zer(o_0)ne — Wed, 01 Jul 2009 17:03:29 +0000

Hier mal mein kleines Twitter-Skript. Es braucht nur der Benutzeraccount und das Passwort in die Felder USER und PASS eingetragen zu werden. Danach für man es am besten so aus: ./twitter.sh “Twitternachricht”. Das Skript zählt die Zeichen und warnt einen falls man über die 140 Zeichen kommen sollte.

#!/bin/bash USER="Benutzer" PASS="Password" CHARS=$(echo "$1" | wc -m) LIMIT="140" if [ $CHARS -lt $LIMIT ] then curl -u $USER:$PASS -d status="$1" http://twitter.com/statuses/update.xml > /dev/null 2>&1 else echo "Mehr als 160 Zeichen" fi

Xorcom Asterisk, die 2.

zer(o_0)ne — Thu, 11 Jun 2009 18:59:44 +0000

Nach einer Woche zeigt sich, das sich das Update gelohnt hat. Das Problem des “cause 34″ scheint behoben, der Asterisk läuft allgemein stabiler. Doch gab es einen “cause 34″, wo ich mich doch wunderte, es lies sich aber nicht herausfinden ob es nun am Treiber lag oder wirklich an der Leitung. Was ich auch noch sagen muss ist, das in der neuen Version das Kommando “zap reset span x” nicht mehr zu existieren scheint. Ich teste dann die Tage mal die Junghanns-Version, ob es da noch da ist. Würde es allgemein wegfallen wäre das suboptimal, denn damit kann man doch mal den ein oder anderen Span wieder reaktivieren, wenn er gerade mal als down markiert ist.

Xorcom Asterisk

zer(o_0)ne — Sat, 06 Jun 2009 12:22:33 +0000

Bei meinen Asterisken setz ich bei der Anbindung ans ISDN-Netz auf Junghanns-Karten. Da diese doch echt gut sind. Leider brauchen die Karten von Junghanns eine angepasste Version von Asterisk/Zaptel. Diese bietet Junghanns auch als komplett Paket an. Doch hängen die Versionen von Junghanns immer ein wenig den aktuellen Asterisk-Versionen hinterher. Auch ist Junghanns dafür bekannt nicht wirklich auf Community-Eingaben zu reagieren, sodass nur wenige Patche ihren Weg in die BRIstuff-Pakete von Junghanns finden.

Nun war ich doch recht unzufrieden mit der der Asterisk-Version von Junghanns. Zwar lief sie auf 2 von 3 meiner Systeme sehr gut, doch auf einem mit OctoBRI-Karte gab es immer wieder Probleme. Es war das wohl bekannte “cause 34″-Problem. Liesse sich wohl auch durch einen Patch der Junghanns-Version beseitigen. Doch ich wollte eh eine neue Asteriskversion haben und eine Alternative zu Junghanns.

So sah ich mich nach Alternativen um. Zu spät bemerkte ich, das ich sie schon direkt vor Augen hatte. Denn im Installationsverzeichnis der Junghanns-Kompilation befand sich in der INSTALL Textdatei ein verweis auf Xorcom. Sowie es aussieht stellen diese ihren eigenen Zweig an BRIstuff-Versionen. Also entschied ich testweise auf dem System mit der OctoBRI-Karte einmal die Xorcom-Variante von BRIstuff zu installieren. Ich bezog die neuste Version von Xorcom. Zu finden auf deren Update-Seite. Die neuste ist zur Zeit bristuff-0.4.0-RC4-xr7.tar.gz. Mit dieser lies sich das bestehende System mit der Asteriskversion von Junghanns sehr einfach updaten, da beide ja im Grunde das Gleiche sind. Einfach wie bei Junghanns bekannt: runterladen, entpacken und dann die install.sh ausführen. Den Rest macht das Script dann schon. Wenn das Script dann durchgelaufen ist hat man seinen neuen Asterisk.

Hier nochmals die einzelnen Schritte, die Kommandos in den eckigen Klammern müssen nur ausgeführte wenn man vorher noch keinen Asterisk auf dem System hatte.

wget http://updates.xorcom.com/astribank/bristuff/1.4/bristuff-0.4.0-RC4-xr7.tar.gz
tar xfz bristuff-0.4.0-RC4-xr7.tar.gz
cd bristuff-0.4.0-RC4-xr7
[ ./prereq.sh test
./prereq.sh install ]
./install.sh

Der Artikel bekommt dann nächste Woche noch ein Update oder einen Folgeartikel darüber wie das System nun läuft.

Asterisk 1.6.1.0 installieren

zer(o_0)ne — Wed, 06 May 2009 16:01:39 +0000

Hier nun eine kleine Anleitung wie man Asterisk 1.6.1 aus den Sourcen herraus installiert. Es ist eigentlich nur ein Merkzettel für mich, damit ich mir die einzelnen Schritte merken kann, aber vllt braucht es ja noch jemand. Ich hoffe für denjenigen ist es dann eine Hilfe. Auch da man ja in der Regel ehrer wenig über Asterisk 1.6 liest.

Vorbereitungen

wenn nötig:
aptitude install build-essential linux-headers-`uname -r` psmisc libncurses-dev

Asterisk Downloaden:

wget http://downloads.digium.com/pub/asterisk/releases/asterisk-1.6.1.0.tar.gz wget http://downloads.digium.com/pub/asterisk/releases/asterisk-addons-1.6.1.0.tar.gz wget http://downloads.digium.com/pub/telephony/dahdi-linux/releases/dahdi-linux-2.1.0.4.tar.gz wget http://downloads.digium.com/pub/telephony/dahdi-tools/releases/dahdi-tools-2.1.0.2.tar.gz wget http://downloads.digium.com/pub/libpri/releases/libpri-1.4.9.tar.gz

libpri installieren (PRI-Treiber, falls nötig):

tar xfz libpri-1.4.9.tar.gz cd libpri-1.4.9 make all make install

dahdi installieren (ISDN-Treiber, falls nötig, ehml. ZAP):

tar xfz dahdi-linux-2.1.0.4.tar.gz cd dahdi-linux-2.1.0.4 make all make install cd .. tar xfz dahdi-tools-2.1.0.2.tar.gz cd dahdi-tools-2.1.0.2 ./configure make all make install config

Asterisk installieren:

tar xfz asterisk-1.6.1.0.tar.gz cd asterisk-1.6.1.0 ./configure make all make install config samples cd .. tar xfz asterisk-addons-1.6.1.0.tar.gz cd asterisk-addons-1.6.1.0 ./configure make all make install samples config

Nun ist Asterisk betriebsbereit und muss noch konfiguriert werden, die Standard-Config reicht aber schon einmal aus um die grundsätzliche Funktionsfähigkeit von Asterisk zu testen. Mit dem folgenden Kommando nun asterisk starten.
asterisk -cvvv

Linux im RAM

zer(o_0)ne — Fri, 13 Mar 2009 00:16:53 +0000

Es war ja nur eine Frage der Zeit bis jemand den gedanken endlich umsetzt. Bei den fallenden RAM-Preisen und den Steigenden Größen stellte sich mir schon lang die Frage warum man nicht das gesamte System in den RAM verlagern kann. Mit der heutigen Technik dauert ja nicht einmal das initiale laden dann lange. Man braucht eben nur noch eine kleine Festplatte um Userdaten und Einstellungen zu speichern. So könnte man noch kleinere ThinPCs bauen. Na gut, man könnte diese auch mit Flashspeicher ausstatten, doch dieser ist meist teuer. Also nimmt man RAM, der einen ja im Moment quasi hinterher geworfen wird.

Laut dem Artikel von Golem.de solle man aber immer noch min. 4GB benötigen um die Distribution “Tin Hat” nutzen zu können. Find ich aber schon wieder ein wenig hart. Systeme wie DSL oder Knoppix kommen auch mit weit weniger platz zurecht. Und da Gentoo als Grundsystem dient, sollte man doch denken, das man daraus ein schlankes System bauen kann. Ich glaub ich muss mir das mal ein wenig genauer ansehen um herauszufinden wozu die soviel platz brauchen. Na ja, wenn man Gnome dann auch als WM nimmt, erklärt das schon einiges, könnte man auch ein wenig abspecken. An sich ist Gnome schon toll, aber für solch ein System hätte ich dann was anderes genommen. Fluxbox oder xfce bieten sich da eher an.

Insgesamt aber schon eine Prima Idee… Mal sehen ob ich das irgendwie auf meinen MacBook zum laufen bekomme…

Link: Tin Hat

Einführung in Screen

zer(o_0)ne — Thu, 26 Feb 2009 23:10:02 +0000

Eben auf buildblog.de veröffentlicht: meine kleine Einführung in den Umgang mit “screen”.

Hier also der Link dazu: klick mich

PHP auf Gentoo

zer(o_0)ne — Sat, 24 Jan 2009 01:33:58 +0000

puhh, dachte eben ich hab mir meine gesamte apache config zerschossen, weil ich für ein wordpress plugin php neu compilierte. das ging auch alles gut, bis auf das ich meine apache-config dann hab automatisch verändern lassen. sah eigentlich alles auch ganz normal aus. blos der apache jagte php code nicht mehr durch den interpreter. alles durch gesehen und überprüft und getestet. aber nichts ging. also dann die config stück für stück auseinander genommen. am ende war es dann das, das es ein IfDefine zuviel war, der apache das ganze zwar angenommen hatte, aber nicht wirklich mit den direktiven umgehen konnte. alles sah normal aus, aber ging ebend nicht. dann hab ich die gesamte php config, aus ihrerer module.conf rausgenommen und alles einzeln nacheinander ohne IfDefine in die main config httpd.conf reingetan und was soll ich sagen? jetzt ging alles wie von zauberhand wieder…. scheiss scripte XD

Speicherverbrauch mit Top anzeigen

zer(o_0)ne — Wed, 14 Jan 2009 10:18:01 +0000

Den aktuellen Speicherverbrauch eines Prozesses kann man sich mit top auch in Byte anzeigen lassen und nicht nur in Prozent.
Dazu startet man top und drück dann “f” und danach “s” und bestätigt mit “ENTER”. Jetzt hat men ein zusätzliches Feld in welchen der aktuelle Speicher den ein Prozess belegt angezeigt wird. Drück man nun noch “SHIFT+f” und dann wiederum s, wird nach diesem neuen feld absteigend sortiert, beginnend mit dem grössten Wert.

Bind9

zer(o_0)ne — Wed, 17 Dec 2008 17:29:41 +0000

Heute hab ichs endlich mal geschafft einen DNS-Server aufzusetzen. Hab dann auch gleich mal drei Zonen eingerichtet, worauf ich unsere Domains lokal auf einen Test-Server umleite. sodas man direct auf den Testsytem landet anstatt im internet.

sehr dabei geholfen hat mir dieses Tutorial

Gentoo Stage4 Vserver updaten, die 2.

zer(o_0)ne — Tue, 16 Dec 2008 17:50:03 +0000

So nun hier nochmal die Script-Version um eine VServer installation von Gentoo zu updaten, welche mit einen alten Satge4 installiert wurde.

#!/bin/bash emerge -f e2fsprogs emerge -C mktemp com_err ss setarch e2fsprogs && emerge e2fsprogs emerge "=sys-apps/util-linux-2.13.1.1" portage coreutils vim mc ACCEPT_KEYWORDS="~amd64" emerge "=sys-devel/autoconf-wrapper-6" FEATURES=-unmerge-orphans emerge cracklib ACCEPT_KEYWORDS="~amd64" emerge -uvDN world

Um das jetzt nicht jedesmal machen zu müssen, kann man sich auch ein neues Stage4 bauen.
Dazu habe ich im Blog von Philipp Kroenke – Vibora eine gute Anleitung gefunden.
mit folgendem Kommando legt man eine neues Stage4 an:
tar --no-ignore-case -cjpf /dokumente/stage4-datum.tbz2 / --exclude=/dokumente/* --exclude=/dev/* --exclude=/sys/* --exclude=/proc/* --exclude=/var/tmp/* --exclude=/var/log/* --exclude=/usr/portage/distfiles/*

Sodas man dann mit dem neuen Stage4 sich in altbekannter manier wieder einen VServer bauen kann:
vserver meinVserver build -m template --context 01 --hostname meinVserver --interface eth1:10.0.0.1/24 --initstyle gentoo -- -d gentoo -t stage4-datum.tar.bz2

Die Nacht der lebenden Server …

zer(o_0)ne — Sun, 14 Dec 2008 19:05:12 +0000

So gestern dann mal wieder an mein Projekt eines selbkompilierten Servers. Naja, nur Apache, PHP, MySQL sind wirklich selbstkompiliert. Dann kommt noch eine angepasste Version von Postfox dazu. Dann noch ein wenig IMAP und POP3, sowie ein Virenfilter dazu und fertig. Das ganze läuft im Rahmen einer Serveraktualisierung von www.dunkel-volk.de.

Das ganze bereite eine Freund und ich nun schon ein paar Monate vor. Irgendwie fehlte wohl immer so richtig die Zeit. Es ist ja nicht so das wir das ganze von Hand installieren, so nach und nach. Nein, es soll alles gescripted ablaufen. So das wir so gut wie nichts mehr machen müssen. Also haben wir uns da eine kleine Scriptsammlung zusammen geschrieben und anhand einiger Tutorials, welche auf binär-Paketen setzen, die Lücken aufgefüllt.
Angefangen haben wir mit einen frisch installierten Debian 4.0. Dann noch so die Grundlagen wie SSH und MC oder mal hier und da die ein oder andere Bibliothek und den ganzen Kram zum Kompilieren noch. Gefolgt davon dann die Quellen von Apache, MySQL und PHP. Diese konnten wir jetzt speziell an unsere Bedürfnisse anpassen und so auch die aktuellsten Versionen nehmen. Wo das dann alles fertig war, dachten wir uns, nen eigener Mail server sei ja auch nicht schlecht. Der jetzige den wir haben ist nicht wirklich kontrollierbar und es gibt massig SPAM. Also wollten wir das besser machen ;-) Da ich mir zuvor schon für mich und die Arbeit ein Postfix-Buch gekauft habe, war das ja perfekt zum üben und Erfahrungen sammeln. Also haben wir dann zu den drei bestehenden Server-Programmen noch Postfix, Courier, Spammassin, Amavis/Clamav hinzugefügt. Diese haben wir aller dings aus dem repository von Debian genommen. Ausser Postfix, dies haben wir zwar auch aus dem Repository genommen, dann aber mit der Source-Version überspielt, welche vorher gepatcht wurde. Das ist es dann also, ist ja nicht all zu viel denkt man. Da kann man sich aber gewaltig irren, weil es noch sehr sehr viele kleine ecken und kanten gab, an welchen man etwas nachbessern musste, oder wo etwas nicht so klappte wie man sich das eigentlich dachte.

Gestern haben wir uns dann mal einen VServer erstellt, also ne VM die ich bereit stellte und darauf eine Domain geschalten. Dann alles nach und nach installiert. Eigentlich sollten wir ja nicht soviel eingreifen müssen, da wir ja viele scripte vorbereitet hatten. Dies war aber ein Irrtum. Das meiste lief ganz gut durch, also Apache, MySQL und PHP. Postfix ging auch ganz gut durch. Doch dann die Konfiguration davon. Da gab es dann doch das ein oder andere Problem, was isch dann aber auch lösen lies. Meist waren es kleine Fehler mit grossen Auswirkungen wie eben falsche Dateiberechtigungen oder Datenbankberechtigungen. Eines der Grösseren Probleme war, das die ClamAV Version von Debian wohl einen Tick hat und in der Konfiguration, so wie ich sie hier hatte, nicht richtig funktionierte. Nach ein wenig Recherche im Netz fand ich dann aber einen passenden Workaround.
So gegen 23 Uhr war dann alles soweit erstmal bereit das es lief. Also ein Webserver mit PHP und MySQL support, MySQL an sich und eine Mailserverkonstrukt, was Emails empfangen und verenden kann. Wir hatten um 12:00 Uhr Mittags angefangen. Naja, mal ne grössere Pause zum einkaufen und noch eine weitere zum essen. Was jetzt dann noch fehlte waren so Kleinigkeiten wie die Richtige Verschlüsselung der Mails und Statistik tools wie AwStats und Cacti. Auch sollte noch ein Jabber-Server hinzukommen. Dies haben wir dann noch bis 4 Uhr morgens implementiert. Als Jabber Server hatten wir uns dann für OpenFire entschieden, aufgrund der GUI. Is ja für Mausschubser, aber falls eben mal kein Admin zu Hand ist, das die auch mal ein wenig was regeln können. Dann noch als Test für den Webserver und PHP sowie MySQL noch eben ein kleines WordPress aufgesetzt um zu sehen ob das läuft.

Ich werde dann mal Demnächst die Final Version der Script-Sammlung hier noch veröffentlichen.

hier dann noch ein paar quellen:

HowtoForge Tutorial für einen Mail Server

Workaround Tutorial für einen Mail Server