netz-guru blog

Weil es doch öfter mal vorkommt, dass man in Webseiten mailto Links einbauen möchte und man meist
vermeiden will, dass die E-Mail Adressen von Spam-Crawlern erfasst werden gibt es hier mehrere Möglichkeiten dem entgegenzuwirken.

Weit verbreitet scheint das verschlüsseln der Mail-Adresse mittels Java-Script. Dies hat jedoch den Nachteil, dass der Browser Java-Script aktiviert haben muss. Gutes Webdesign sollte Java-Script nicht vorraussetzen. Man kann auch die E-Mail Adresse im mailto-Link durch dezimale HTML Entitäten darstellen, so dass diese im Browser ganz normal angezeigt werden und der mailto Link auch vom User benutzt werden kann, der E-Mail Harvester sieht jedoch nur HTML und kann daher die Adresse nicht parsen.

Den Encoder kann man hier testen.

Hier die zugehörige PHP-Funktion:


function spamschutz($email,$href = true) {
$returnemail=preg_replace( "/(.)/se", " '&#' . ord( '\\1' ) . ';' ", $email );
if ($href) {
return "$returnemail";
} else {
return $returnemail;
}

}


seit einiger Zeit biete ich auch direkt Mietcluster auf GlusterFS Basis inklusive Loadbalancer und Failover an. Dazu gehört auch 24/7 Monitoring sowie das durchführen von komplexen Setups wie z.B. Master-Master Mysql Cluster etc.

Da ich in letzter Zeit mit Mails diesbezüglich geflutet werde, hier mal der Link zur Firma => www.smart-cluster.com

Wer kennt es nicht? Die Müllabfuhr holt den Müll ab und man hat leider vergessen, seine Mülltonne rauszustellen. Nun habe ich mir selbst mit einem kleinen Script Abhilfe geschaffen. Das Script stellt die Tonne zwar nicht zur Abholung bereit, verschickt jedoch am Abend vorher eine SMS. Die Daten dafür holt sich das Script direkt von der Webseite des Abfallzweckverbandes (das Script funktioniert im Moment deshalb nur im Landkreis Hof). Hier kann man sich das Script ansehen.

Als ich heute versucht habe, eine Mail an einen unserer Kunden zu schicken, staunte ich nicht schlecht als die Mail gebounced wurde. Unsere Mailserver seien angeblich SPAM-Schleudern und wurden mittel Barracuda Reputation geblockt. Folgt man dem angegebenen Link, kann man dann eine Anfrage stellen, den Mailserver aus der RBL entfernen zu lassen – das dauert dann (angeblich) bis zu 12 Stunden. Alternativ kann man sich bei emailreg.org einen Account anlegen um dort die IPs des Mailservers auf eine Whitelist setzen zu lassen – dass das Ganze dann 20 US $ Kosten soll, erfährt man erst wenn man sich einen Account angelegt hat – eine Unverschämtheit wie ich finde.

Dazu kommt noch dass der Aufwand die Mailserver dort aus deren RBL zu delisten bei einem Cluster mit vielen Mailservern enorm steigen kann. Man muss sich ja immer durch irgendwelche Forms mit Captchas durchhangeln – auf ein Feedback seitens Baracuda Central wartet man wohl vergeblich.

Ich kann nicht nachvollziehen, warum einige Mailserver-Admins der Meinung sind, dieses perverse System unterstützen zu müssen. Der Ärger mit Kunden die keine Mails zustellen können und der Aufwand whitelists zu Pflegen stehen doch in diesem Falle in keinem Verhältnis mehr. Dazu kommt noch, dass sich SPAM auch sehr effizient mit den üblichen Opensource-Lösungen wie dspam, spamassassin, diversen Filterlisten wie SpamCop und Spamhaus, amavisd, Greylisting etc filtern lässt.

Aber eine gute Geschäftsidee wäre es schon, einfach mal eine Blacklist aufzubauen, alles erst mal zu Blacklisten, für das Whitelisting Geld zu verlangen und dann irgendwelche Marketingmenschen in größeren Unternehmen dieses System als innovativ zu verkaufen und nochmals die Hand aufzuhalten. Dieser Gedanke könnte einem zumindest in den Sinn kommen, liest man sich diverse Foren im Netz durch.

Einfach nur frustrierend…

UPDATE:

http://packetstormsecurity.org/papers/evaluation/Barracuda_Evil.txt bestätigt meinen Verdacht, dass das Barracuda Zeug einfach nur Müll ist…

in der Dokumentation von mysql cluster wird immer darauf hingewiesen, dass man für ein redundantes Setup mindestens 3 Server benötigt: 2 Server für die NDB-Datenknoten und einen weiteren Server als separater Management-Server. Dies ist jedoch unschön, wenn man nur 2 physikalische Maschinen verwenden will/kann.

Mit etwas Konfigurationsarbeit und dem Linux VServer Patch (auf welchem auch die Vserver bei vlinux.biz laufen) lässt sich das Setup dennoch mit nur 2 Servern durchführen wobei auch ein Server komplett ausfallen kann, ohne dass der mysql cluster down ist oder crashed.

Man installiere ein Debian Lenny oder neuer, wähle entweder den bei Debian mitgelieferten VServer Kernel (linux-image-vserver-bigmem) oder baue seinen eigenen (z.B. 2.6.31.7-vs2.3.0.36.27 ) auf jeweils beiden Systemen.

Dann legt man auf den Servern vier virtuelle Server an:

vserver sql0[1-4] build –context 700[0-3] –hostname sql0[1-4]-n sql0[1-4] –interface sql0[1-4]=eth0:192.168.0.10-14 -m debootstrap — -d lenny

Danach wie gehabt mysql ndb herunterladen und installieren (z.B. mysql-cluster-gpl-7.0.9-linux-i686-glibc23) in /usr/local/ entpacken, und einen symlink auf /usr/local/mysql setzen.

Dann die Konfiguration (config.ini) wie folgt aufsetzen:

[NDBD DEFAULT]
NoOfReplicas: 2

DataDir: /var/lib/mysql-cluster
FileSystemPath: /var/lib/mysql-cluster

# Data Memory, Index Memory, and String Memory

DataMemory: 900M
IndexMemory: 300M
BackupMemory: 128M

MaxNoOfConcurrentOperations=100000

StringMemory=25
MaxNoOfTables=4096
MaxNoOfOrderedIndexes=2048
MaxNoOfUniqueHashIndexes=512
MaxNoOfAttributes=24576

TimeBetweenLocalCheckpoints=20
TimeBetweenGlobalCheckpoints=1000
TimeBetweenEpochs=100

MemReportFrequency=30
BackupReportFrequency=10

### Params for setting logging
LogLevelStartup=15
LogLevelShutdown=15
LogLevelCheckpoint=8
LogLevelNodeRestart=15

### Params for increasing Disk throughput
BackupMaxWriteSize=1M
BackupDataBufferSize=16M
BackupLogBufferSize=4M

[MGM DEFAULT]
PortNumber: 1186
DataDir: /var/lib/mysql-cluster

[NDB_MGMD]
Id:1
HostName: sql01

[NDB_MGMD]
Id:2
HostName: sql02

[NDB_MGMD]
Id:3
HostName: sql03

[NDB_MGMD]
Id:4
HostName: sql04

[NDBD]
Id:5
HostName: sql01

[NDBD]
Id:6
HostName: sql02

[NDBD]
Id:7
HostName: sql03

[NDBD]
Id:8
HostName: sql04

[API]
Id:9
HostName: sql01

[API]
Id:10
HostName: sql02

Nun die Management-Knoten auf allen vier VServern starten / initialisieren. Dazu in /usr/local/mysql

ndb_mgmd –initial -f config.ini

ausführen, anschliessend die 4 ndb Knoten starten (ndbd –initial)

Für die API Nodes natürlich noch mit ./scripts/mysql_install_db die mysql Datenbanken anlegen und anschliessend mit chmod mysql.mysql data -R die Rechte passend setzen.

Anschliessend sollte man mit ndb_mgm => show folgenden Output erhalten:

Cluster Configuration
———————
[ndbd(NDB)]     4 node(s)
id=5    @192.168.0.10  (mysql-5.1.39 ndb-7.0.9, Nodegroup: 0)
id=6    @192.168.0.12  (mysql-5.1.39 ndb-7.0.9, Nodegroup: 0, Master)
id=7    @192.168.0.11  (mysql-5.1.39 ndb-7.0.9, Nodegroup: 1)
id=8    @192.168.0.13  (mysql-5.1.39 ndb-7.0.9, Nodegroup: 1)

[ndb_mgmd(MGM)] 4 node(s)
id=1    @192.168.0.10  (mysql-5.1.39 ndb-7.0.9)
id=2    @192.168.0.12  (mysql-5.1.39 ndb-7.0.9)
id=3    @192.168.0.11  (mysql-5.1.39 ndb-7.0.9)
id=4    @192.168.0.13  (mysql-5.1.39 ndb-7.0.9)

[mysqld(API)]   2 node(s)
id=9    @192.168.0.10  (mysql-5.1.39 ndb-7.0.9)
id=10   @192.168.0.12  (mysql-5.1.39 ndb-7.0.9)

Nun sollte jeweils ein ndbd einer Nodegroup (0 und 1) auf einem physikalschen Server liegen, d.h. fällt ein Server aus, so sind immer noch mind. ein ndbd aus der jeweiligen Nodegroup verfügbar und der Cluster läuft weiterhin problemfrei.

Natürlich habe ich vorrausgesetzt, dass die Installation soweit fertig gestellt ist, d.h. mysql user angelegt, Datenverzeichnis angelegt (/var/lib/mysql-cluster – kann auch anders sein..) wurde etc. und in der my.cnf die Einträge für ndb gemacht wurden:

[mysql_cluster]
ndb-connectstring=sql01

[ndb_mgmd]
config-file=/usr/local/mysql/config.ini

Seit ein paar Tagen bietet Google öffntliche DNS Recurser für jedermann an. Behauptet wird zudem, dass Googles DNS Services schneller seien als die vom ISP zugeteilten DNS Server. Ich kann dazu nur sagen, dass ich persönlich es für einen großen Fehler halte, die DNS Server von Google zu verwenden, denn zum einen kann man nicht wissen, was Google mit den DNS Anfragen der User so treibt (damit lässt sich zumindest leicht nachvollziehen, auf welche Seiten ein User so surft), zum anderen wage ich es zu bezweifeln, dass Googles DNS Server wirklich schneller sind als z.B. ein lokal laufender Nameserver auf einem Router, bzw die Nameserver welche der ISP selbst vorgibt. Hier kann man zwar auch nicht wissen, ob seitens des ISP gefiltert wird, aber wenn man sich in dieser Hinsicht gedanken macht, bleibt einem sowieso nur das Betreiben eigener Nameserver und Recursor.

Ein Test mit Namebench bestätigt, dass lokale Nameserver nicht langsamer sind als die von Google angepriesenen Services. Vereinzelt ist Google schneller, da Google natürlich sämtliche Anfragen von Usern cachen kann, während man lokal jedoch meist nicht so viele Seiten besucht und die Wahrscheinlichkeit eines Cachelookups dadurch natürlich sinkt.

Aus Datenschutzgründen sollte man die Nameserver von Google meiner Meinung nach nicht verwenden, selbst wenn ein Lookup 20ms schneller erfolgen sollte, als mit einem vom ISP zugewiesen Nameserver – diese 20ms fallen beim Surfen meist sowieso nicht auf.

Hier nochmal die Auswertung von Namebench für meinen lokalen Nameserver, meinen Nameserver in unserem RZ in Nürnberg sowie als Vergleich Googles Nameserver:

http://www.netz-guru.de/downloads/namebench_2009-12-05_2018.html

Es erscheint auch logisch, warum der lokale Nameserver schneller Antworten kann als ein Nameserver aus einem entfernten Netz – das liegt einfach an den Latenzen der Paketlaufzeiten zu den einezelnen Servern. Lokal hat man hier meist unter 0,1ms, während es bei DSL mindestens 10-20ms dauert, vorrausgesetzt das ist der Nameserver des ISP. Zu Googles Nameserver habe ich schon mal allein 110ms Latenz – da ist der eigentliche Request und die Zeit die das dauert bis ich eine Response bekomme noch nicht mitgerechnet.

Fazit: Finger weg von Googles DNS Services!

Soeben habe ich den Post http://blog.koehntopp.de/archives/2675-Communitygift.html gelesen und muss sagen, dass mir der Autor Kristian Köhntopp aus der Seele spricht. Ich selbst habe zwar bisher erst einen einzigen Artikel auf den Weg gebracht, und nur diverse Korrekturen bei einigen Artikeln durchgeführt – aber wie der Autor schon angemerkt hat – es fehlt an Struktur. Durch die fehlende Struktur passieren Fehler, das kostet Zeit und Nerven – auf beiden Seiten. Hoffen wir mal dass sich das in Zukunft irgendwie zum Positiven verändert – Anregungen gibt es ja genug, die Frage ist eben nur, ob diese auch umgesetzt werden.

php bietet aktuell ip2long() und long2ip() nur für IPv4 an, für IPv6 gibt es aktuell soweit ich weiss noch keine native Funktionen, deshalb hier meine zwei Funktionen um ip2long und long2ip auch für IPv6 zu verwenden – diese Funktionen benötigen die php gmp-lib, unter Debian: apt-get install php5-gmp:

$ipv6 = “2001:4860:a005::68″;
function ip2long6($ipv6) {
$ip_n = inet_pton($ipv6);
$bits = 15; // 16 x 8 bit = 128bit
while ($bits >= 0) {
$bin = sprintf(“%08b”,(ord($ip_n[$bits])));
$ipv6long = $bin.$ipv6long;
$bits–;
}
return gmp_strval(gmp_init($ipv6long,2),10);
}

function long2ip6($ipv6long) {

$bin = gmp_strval(gmp_init($ipv6long,10),2);
if (strlen($bin) < 128) {
$pad = 128 – strlen($bin);
for ($i = 1; $i <= $pad; $i++) {
$bin = “0″.$bin;
}
}
$bits = 0;
while ($bits <= 7) {
$bin_part = substr($bin,($bits*16),16);
$ipv6 .= dechex(bindec($bin_part)).”:”;
$bits++;
}
// compress

return inet_ntop(inet_pton(substr($ipv6,0,-1)));
}

print $ipv6long =  ip2long6($ipv6).”\n”;
print $ipv6 = long2ip6($ipv6long).”\n”;

Ergebnis:

42541956150894553250710573749450571880
2001:4860:a005::68

Wer den postfix-policyd auf einem Mailserver Cluster einsetzen möchte, der bekommt zumindest mit einer Mysql-Cluster-Datenbank als Backend Probleme, denn NDBCluster unterstüzt kein “Insert delayed” Syntax.

Deshalb hier ein kleiner Patch, der den aktuellen source von debian lenny (postfix-policyd-1.80) patched, damit postfix-policyd keine delayed inserts mehr macht und einwandfrei mit Mysql-NDB-Cluster funktioniert.

postfix-policyd-1.80_mysqlndb.patch

Installiert wird das Ganze mit:

apt-get source postfix-policyd

wget http://www.netz-guru.de/wp-content/uploads/2009/08/postfix-policyd-1.80_mysqlndb.patch.txt

patch -p0 <postfix-policyd-1.80_mysqlndb.patch.txt

cd postfix-policyd-1.80

dpkg-buildpackage  -uc -b

Heute hatte ich mal etwas Zeit über, und konnte mich einem weiteren kleinen Problem welches aus dem Upgrade auf PHP5.3 resultiert widmen. Einige Funktionen sind bei PHP5.3 nicht mehr verfügbar, oder werden mit PHP6.0 nicht mehr unterstüzt. Auf der php Webseite gibt es eine Liste aller veralteten Funktionen.

In Typo3 4.3.0alpha3 ist davon zwar Einiges, wenn nicht sogar Alles behoben, im aktuellen Stable 4.2.8 gibt es jedoch eine Menge Probleme, wenn man auf PHP5.3 umstellt. Deshalb hier der von mir erstellte Patch für typo3 4.2.8 mit PHP5.3

typo3-4.2.8-php5.3-compat-patch

Falls jemand wider Erwarten einen Fehler findet und mir mitteilt, so werde ich den neuen Patch ebenfalls hier veröffentlichen.

Einen komplett gepatchten source gibt es hier zum download, da viele User nicht wissen wie man mit patch umgeht:

http://www.netz-guru.de/wp-content/uploads/2009/07/typo3_src-4.2.8-compat-patched-php5.3.tgz