Wir ertrinken in Information, aber hungern nach Wissen [John Naisbitt]

Site menu:


Letzte Kommentare

Links:

Counter

Bloggerei

Blogverzeichnis - Blog Verzeichnis bloggerei.de

Archiv

Tag Cloud

Software

Howto convert from VMware to VirtualBox

In January 2007 a small german software company (now owned by Sun Microsystems) released a quite usable virtualization solution called VirtualBox under the terms of the GPL licence. Since then VirtualBox has made a strong progress and can now compete with commercial solutions from VMware or Parallels with features like seamless mode or booting your guests from iSCSI. This howto is for all those folks looking to move from VMware Server to VirtualBox.

First of all forget about converting since VirtualBox can work with VMWare’s vmdk format. So there is no more dealing with odd stuff like qemu-img, vditool or VBoxManage convertdd. The only reason to convert your virtual machine is if you plan to use snapshots. If you don’t so go ahead:

  • Prepare your virtual machine by removing the vmware tools
  • Locate where your virtual machine is located. Mostly /var/lib/vmware/$VIRTUALMACHINENAME
  • Change the user- and group-id of the virtual machine files from the root to your personal user:
    waldorf: $ su
    waldorf: # chown $USERNAME:$GROUPNAME /var/lib/vmware/$VIRTUALMACHINENAME -R
    
  • Now start VirtualBox and launch the Virtual Disk Manager via click through File/Virtual Disk Manager and add your virtual machine vmdk file
  • Add a new virtual machine with the former defined virtual disk
  • Start the virtual machine and install VirtualBox guest extensions
  • Done

A few words for migrating Windows XP guest virtual machines: Please read this before you start and if you still have problems to boot try this:

Have fun!

Mit screen Benutzern unter Linux über die Schulter schauen

Es gibt genug Situationen wo man bestimmten Benutzern einfach mal auf die Finger schauen möchte. Als Klassiker würde ich mal Service-Techniker bezeichnen, welche (evtl. als root) an Systemen arbeiten müssen. Hier gilt die Devise ‘Vertrauen ist gut, Kontrolle ist besser’ und mit ein bischen GNU Screen kann zumindest nachvollziehen was gemacht worden.

Zuerst muss man screen Setuid-Root setzen:


# chmod u+s /usr/bin/screen

und die Berechtigungen von /var/run/screen anpassen:


# chmod 755 /var/run/screen

Der erste Benutzer startet nun screen und gibt

STRG+A:multiuser on

ein. Nun muss er den zweiten Benutzer berechtigen bzw. mehrere durch Komma getrennt:

STRG+A:acladd joern

Das kann man auch sicherer gestalten, indem man ein Passwort vorgibt, welches man vorher mit
mkpasswd crypted muss:

STRG+A:acladd joern nTFa9CA4bqAVw

Zur Sicherheit noch das Logging einschalten und dann kann der Zuschauer kommen:

STRG+AH

Dieser startet screen folgendermaßen, wobei zap der Benutzername des ersten Benutzers ist und 9954 die Prozess-ID des screens ist auf den man zugreifen möchte:


$ screen -x zap/9954

Fertig ist Big Brother. Das Funktionert übrigens auch unter Solaris mit screen aus dem Blastwave-Repository.

Es könnt alles so einfach sein, ist es aber nicht

Die Entscheidung vermehrt auf CentOS resp. Redhat zu setzen ist mir beileibe nicht leicht gefallen, aber der extrem niedrige Frickelfaktor bei der Installation und die sehr gute Treiber-Unterstützung sind nicht von der Hand zu weisende Argumente. Redhat schenkt einem aber nichts, denn man bezahlt an anderer Stelle dafür. Besonders hart trifft es einen, wenn man von Debian kommt. Von deren Aufgeräumtheit und Verlässlichkeit im Konfigurationsbereich sind die Rothüte Kilometer weit entfernt.

Beispiel Bind unter Redhat/CentOS: Man installiert bind mit yum install bind, man startet es mit service named start, die Konfiguration liegt in /var/named. Unter Debian liegt die Konfiguration, egal ob Bind8 oder Bind9 unter /etc/bind, man installiert mit apt-get install bind(9) und startet mit /etc/init.d/bind(9). Dieses /var/named erinnert mich immer an bind4-Zeiten *schauder*

Oder Apache: Das Debian Konstrukt mit sites-available und sites-enabled ist simpel und effektiv, bei Redhat gibt es soetwas nicht. Dort heisst der Apache-Prozess auch httpd und nicht apache(2) wie bei Debian. Genau das gleiche Spiel bei der Installation: yum install httpd gegen apt-get install apache(2). Alles voll krass logisch und durchdacht.

Ich könnte jetzt wieder über die Netzwerk-Konfiguration lästern, aber das möchte ich nicht nochmal wiederholen.

Redhat Cluster 4 - Überblick und eine einfache Konfiguration

Cluster sind für viele etwas schwer greifbares. Ich habe es schon oft erlebt, das Firmen einen HA-Cluster hingestellt und es von den Mitarbeitern mit Ehrfurcht betrachtet wurde. Nur nicht anfassen, es könnte ja etwas kaputt gehen.

Dabei gibt es hierfür keinen Grund, denn in der IT wird auch nur mit Wasser gekocht und das beste Mittel gegen Ehrfurcht und Berührungsängste ist es immer noch sich damit auseinander zu setzen.

Wer also einen Einstieg haben möchte kann recht problemlos mit dem Redhat Cluster beginnen, welches es auch von CentOS gibt. Besondere Hardware ist nicht nötig, das folgende Beispiel, auf Basis von CentOS 4.6, läuft zum Beispiel in einem VMWare Server.

Read more »

Halbgarer Kram

Wenn man einfach nur seine Arbeit erledigen möchte, dann kann Open-Source ganz schön nerven. Eigentlich wollte ich nur ein Dokument ausdrucken, aber erst spuckt mir Cups in die Suppe und dann Ghostscript, aber der Reihe nach.

Bei älteren Cups Versionen gab man nur das Backend (z.B. http) und das Ziel wie z.B. http://statler:631/printers/keller zum Drucken an. In den neueren Versionen sucht man zuerst verzweifelt nach einen HTTP-Backend. Erst wenn man den Backend Error Handler auswählt kann man beliebige Backends auswählen, nur die richtige Syntax wird einem nicht verraten und die Beispiel im Web-Frontend sind alle falsch. Richtig muss es dann so beh:/0/3/5/http://statler:631/printers/keller aussehen.

Hat man das unter Ubuntu Gutsy umschifft fliegen einen Ghostscript um die Ohren:

GPL Ghostscript SVN PRE-RELEASE 8.61: Unrecoverable error, exit code 1

Und ich sage es immer wieder: Einfach nur ein Debian Sid sechs Monate abhängen lassen und dann für Stable erklären, das kann nicht funktionieren.

Nochmal Glück gehabt

Ich hab heute die Preise für einen Redhat Enterprise Server mit Cluster-Lizenz gesehen und bin nur knapp dem Herzkasper entkommen *hust*

FAT-Dateisystem unter Linux sortieren

Oliver Brandner (guter Musikgeschmack der Mann) hat mich in den Kommentaren zu meinen Problemen mit der Reihenfolge von Musikstücken unter Linux auf fatsort hingewiesen. Das passt sehr gut, denn ich bin Prompt auf Verzeichnisse gestossen in der das Kopieren mit rsync nichts brachte und das Autoradio wieder die Stücke in willkürlicher Reihenfolge abspielte.

Einfach herunterladen, entpacken, make ausführen, ausführbar machen und dann auf das Dateisystem loslassen:

pest$ fatsort /dev/sdc1

Woohoo!

Spamassassin optimieren

Die Kunst beim Optimieren von Spamassassin heisst gute Planung, beobachten können und sich in Zurückhaltung üben. Man sollte zuallerst nie die Relationen aus den Augen verlieren. Wenn bei 100 Spams eine durchkommt liegt die Erkennungsrate immer noch bei 99 Prozent. Aktuell bekomme ich ca. 250 Spams am Tag. Selten wird davon eine nicht erkannt, womit ich schon im Nachkommta-Bereich bin. Auch Nutzer die aufgeregt anrufen, das eine Spam-Mail durchgekommen ist oder entsprechende Mails weiterleiten sollte man getrost ignorieren. Die Welt geht auch nicht unter, wenn eine Mail vom Bayes-System[1] vermeintlich falsch gelernt wurde. Dabei wird vergessen das es sich um eine statistische Wahrscheinlichkeit handelt und dafür braucht man die entsprechenden Wörter sowohl in der Spam, als auch in der Ham Datenbank. Ein Beispiel:

Kommt das Wort Viagra in 3000 Spam-Mails 500 mal vor und in 5 von 600, liegt die Wahrscheinlichkeit bei:

(300/5000) / (5/600 + 300/5000) = 0,98

Ausserdem macht die Bayes-Bewertung nur einen Teil des Gesamt-Score aus. Lange Rede, kurzer Sinn: Ruhe bewahren ist wichtig. Meiner Erfahrung nach bringt es ausser schlechten Erkennungsraten und False Positives nicht viel an den vorgegeben Scores herumzudrehen. Je mehr man daran rumdreht, umso mehr Arbeit macht man sich an anderer Stelle. Im Folgenden also ein paar Dinge, die man beim Betrieb von Spamassassin auf Servern beachten, tun und sein lassen sollte.

Ist das System schon in Betrieb und leidet unter schlechten Ergebnissen, sollte man zuerst feststellen welche Regeln für die Einteilung in Spam und Ham überhaupt greifen. Gute Dienste leistet hier sa-stats, welches allerdings ein Logfile des Spamd benötigt um aussagekräftige Statistiken zu erzeugen. Bei Debian wird hierzu /etc/default/spamassassin angepasst und das OPTIONS-Feld um -s /var/log/maillog erweitert. Anschließend einmal

touch /var/log/maillog

und den Spamd durchtreten nicht vergessen. Je nach Mail-Durchsatz muss man nun ein wenig warten, also Zeit logrotate einzurichten. Für die meisten sollte es reichen wöchentlich das Spamd-Logfile zu rotieren und somit einen guten Kompromiss zwischen Grösse des Logfiles und Aussagekraft der Statistik zu erreichen. So hat /etc/logrotate.d/spamassassin auszusehen:

/var/log/maillog {
       weekly
       missingok
       rotate 12
       compress
       delaycompress
       notifempty
       create 640 root root
       sharedscripts
       postrotate
               /etc/init.d/spamassassin reload >/dev/null
       endscript
}

Sind genug Daten gesammelt heisst es sa-stats auszuführen. Dem Ergebniss sieht man sofort ein paar wichtige Informationen an wie z.B. das Verhältnis von Spam und Ham oder der generelle Durchsatz an Mail. Am intressantesten sind natürlich die Top Fired Rules für Spam und Ham, die man unter den Gesichtspunkt durchschauen sollte, das Regeln welche für die Spamerkennung da sind, wie z.B. BAYES_99 für Spam oder AWL für Ham (AWL), auf den richtigen Seiten stehen. Tun sie es nicht sollte man mit diesen Datenbanken von vorne beginnen.

Das Bayes-System

Ich persönlich arbeite mit einer generellen Bayes- und AWL-DB für alle. Eigene Datenbanken für Benutzer sind ein stetiger Quell von False-Positives, da entweder komplett falsch gelernt wird oder garnicht. Es ist einfach zu aufwendig und ineffektiv an dieser Stelle hinterherzuräumen, daher lohnt es sich nicht. Solch generelles Setup erreicht man entweder durch ein Site-Wide Setup oder weil Spamassassin von z.B. Amavis getriggert wird und sich somit im Home-Verzeichnis vom Amavis-User die Datenbanken aufbauen.

Bevor es los geht noch ein paar Worte zu den Bayes- und AWL-DBs. Zu einem ist es gut, wenn man die Funktion der AWL versteht:

The AWL is actually a very simple system. In short, the AWL is a score averaging system. It keeps track of the historical average of a sender, and pushes any subsequent mail towards that average. So if someone that never sent you mail before sends you a mail that scores 20, and then sends you a second mail that would score 2.0 without the AWL, the AWL will push the score up to 11 on the second mail. This is auto blacklisting, based on their past history of spam.

Zum anderen sollte man sich abgewöhnen an der Bayes-DB rumzudrehen. Das Autolearning funktioniert bei vernünftigen Regelsätzen besser als jeder Mensch, also Finger weg. Bei solch einen Setup lohnt es sich auch nicht alle erkannten Spams und Hams nachträglich nocheinmal manuell nachzulernen, denn sie wurden bereits durch das Auto-Learning hinzugefügt.

Arbeitet das Bayes-System garnicht liegt es mit hoher Wahrscheinlichkeit an zu wenig gelernten Spam und Ham.

amavis@rte:$ sa-learn --dump magic
0.000          0          3          0  non-token data: bayes db version
0.000          0      21852          0  non-token data: nspam
0.000          0       7754          0  non-token data: nham
0.000          0     150913          0  non-token data: ntokens
0.000          0 1184319834          0  non-token data: oldest atime
0.000          0 1187116894          0  non-token data: newest atime
0.000          0          0          0  non-token data: last journal sync atime
0.000          0 1187084641          0  non-token data: last expiry atime
0.000          0    2764800          0  non-token data: last expire atime delta
0.000          0       1991          0  non-token data: last expire reduction count

Die Werte nham und nspam stehen für die Anzahl bereits gelernter Mails. Liegen sie unter 200 ist das Bayes-System deaktiviert. Möchte man es trotzdem starten kann man dies mit bayes_min_ham_num und bayes_min_spam_num in der Spamassassin-Konfiguration beeinflussen. Auch empfiehlt es sich vor der Inbetriebnahme Gedanken über wichtige Email-Partner zu machen und diese in die Whitelist zu nehmen. Man kann sie später wieder entfernen, da die Whitlist-Scores in die AWL eingegangen ist.

Netzwerkbasierte Tests

Spamassassin basiert im Grunde aus drei Teilen: Festen Regelsätzen, die in der Mail nach bestimmten Pattern suchen, dem Bayes-System und den Netzwerk-basierten Tests wie Razor, Pyzor und (Su)RBLs. Bei Debian geht die Installation recht einfach:

apt-get install libnet-dns-perl razor pyzor dcc-client dcc-common

Man sollte darauf achten einen schnellen DNS-Server in Reichweite zu haben oder lokal einen Caching-DNS betreiben um die Antwortzeiten und damit die Durchlaufzeit einer Mail zu minimieren. Steht der Server hinter einer Firewall sind entsprechende Regeln einzupflegen, näheres hier.

Externe Regelwerke

Die mitgelieferten Regelsätze von Spamassassin sind schon recht gut, man kann sie aber noch verbessern. Aber auch hier sollte man Vorsicht walten lassen. Viele Regeln helfen nicht viel, im schlimmsten Fall machen sie Spamassassin zu einen Ram fressenden Monster. Meine Daumenregel ist dabei, das ich sie wieder lösche wenn sie nach einer Woche nicht in den Top 20 Regeln auftauchen.

Ein guter Anfang sind die Regeln vom RulesEmporium. Die kann man einfach ins Konfigurations-Verzeichnis werfen und Spamassassin durchstarten. Da sie sich aber hin und wieder ändern ist ein automatisches Update wünschenswert. Anfangs gab es RulesDuJour das aber seit dem erscheinen von sa-update nicht mehr weiterentwickelt wird.

sa-update arbeite mit sogenannten Channels, die quasi jeder zur Verfügung stellen kann. Ich nutze zum einen den Update-Channel von Spamassassin und einen von Daryl O’Shea. Zuerst muss man die GPG-Keys installieren:

wget wget http://daryl.dostech.ca/sa-update/sare/GPG.KEY
gpg --import GPG.KEY
sa-update --import GPG.KEY
rm GPG.KEY
wget http://spamassassin.apache.org/updates/GPG.KEY
gpg --import GPG.KEY
sa-update --import GPG.KEY

Anschließend legt man ein File an, indem die Channels hinterlegt werden:

touch /etc/spamassassin/sare-sa-update-channels.txt

Und packt folgende Daten rein, welche die externen Regelwerke repräsentieren die geladen werden sollen:

updates.spamassassin.org
70_sare_stocks.cf.sare.sa-update.dostech.net
70_sare_adult.cf.sare.sa-update.dostech.net
70_sare_spoof.cf.sare.sa-update.dostech.net
70_sare_bayes_poison_nxm.cf.sare.sa-update.dostech.net
70_sare_genlsubj_x30.cf.sare.sa-update.dostech.net
70_sare_oem.cf.sare.sa-update.dostech.net
70_sare_random.cf.sare.sa-update.dostech.net
70_sare_specific.cf.sare.sa-update.dostech.net
70_zmi_german.cf.zmi.sa-update.dostech.net
88_FVGT_Bayes_Poison.cf.sare.sa-update.dostech.net
88_FVGT_Tripwire.cf.sare.sa-update.dostech.net
88_FVGT_rawbody.cf.sare.sa-update.dostech.net
88_FVGT_subject.cf.sare.sa-update.dostech.net
chickenpox.cf.sare.sa-update.dostech.net

Um beide Channels gleichzeitig updaten zu können braucht es nun noch ein Key-File

touch /etc/spamassassin/keys

indem die Keys stehen:

856AA88A
5244EC45

Nun kann man mit

sa-update -D --channelfile /etc/spamassassin/sare-sa-update-channels.txt --gpgkeyfile /etc/spamassassin/keys

die Regelsätze herunterladen und im späteren mit dem selben Befehl auf Stand halten. Vor dem Neustart von Spamassasin ist dringenden ein

spammassassin -D --lint

angesagt um Fehler im Regelwerk rechtzeitig zu erkennen.

Ausblick

Im zweiten Teil geht es um allerlei Plugins mit denen man unter Spamassassin arbeiten kann.

[1] - Kampf dem Spam

Links for 2007-08-09

Privbind - Server-Dienste ohne Root-Rechte betreiben

Irgendwer ist vor ein paar Jahrzehnten auf die Idee gekommen das nur Root Dienste auf den ersten 1024 Ports von Unix resp. Linux betreiben darf. Mit der Zeit würde ich dieses Konzept als überholt ansehen, mich wundert das es noch niemand wirksam in Frage gestellt hat.

Manch Server-Software hat ihren eigenen Weg gefunden Root-Rechte ‘loszuwerden’, wie z.B. Apache oder OpenSSH. Manche Dienste können mit Privilege Separation aber nichts anfangen, hier setzt privbind an:

Privbind can run a server, right from the start, under an unprivileged non-root user with just one extra privilege: the server can bind to reserved ports

Die Benutzung ist geradezu trivial:

 privbind -u user [ -g group] [ -n num] [ -l path] command [ arguments ... ]

Klein, einfach, effektiv würde ich sagen.