1. 12.02.2010 Samsung Spinpoint F1 HD103UJ SMART Self-test: Read failure
2. 07.07.2010 Samsung Spinpoint F1 HD103UJ FAILED SMART self-check. BACK UP DATA NOW!
3. 03.09.2010 Samsung Spinpoint F1 HD103UJ SError: { UnrecovData Handshk }, ES-Tool: RAM-Error
4. 05.03.2011 Samsung Spinpoint F1 HD103UJ SError: { UnrecovData Handshk }, ES-Tool: RAM-Error
5. 24.03.2011 Samsung Spinpoint F1 HD103SJ ES-Tool: AJ36 Bad Sector, SMART Extended offline Completed: read failure

Bisher wurde von Samsung zwar jede von mir eingeschickte Platte anstandslos getauscht ... aber ich hätte doch gerne eine die länger als ein paar Monate durchhält.

Weiß jemand, ob diese Serie besonders oft von Ausfällen betroffen ist?

So wurde mir vorgeworfen, gegen § 114 OWiG verstoßen zu haben (PDF), als ich mit meinem Fahrzeug befestigte Straßen in einem Wald militärischen Sicherheitsbereich befuhr.

Von kämpferischer Laune beflügelt und in der Hoffnung, das Verwarnungsgeld in Höhe von 35 Euro sinnvoller investieren zu können, formulierte ich mit Unterstützung einer guten Freundin meinen Widerspruch (PDF) und harrte der Dinge, die da kommen würden.

Knappe 2 Wochen später lag dann auch schon die Antwort der Wehrverwaltung (PDF) im Briefkasten.

Fazit: Glück (Recht?) gehabt.

VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)]

couldn't use DRI anymore and thus XVideo (e.g. with mplayer) wasn't available anymore.

Error in dmesg:

[drm] radeon: cp idle (0x10000C03)
[drm] Loading R300 Microcode
[drm] radeon: ring at 0x00000000B8000000
[drm:r100_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E4)=0xCAFEDEAD)
[drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
[drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP.
[drm] radeon: cp finalized

Error in Xorg.0.log:

(II) AIGLX: Screen 0 is not DRI2 capable
(II) AIGLX: Screen 0 is not DRI capable

glxinfo:

% glxinfo | grep direct
direct rendering: No

xvinfo:

% xvinfo
X-Video Extension version 2.2
screen #0
no adaptors present

Solution:

1. Remove any vga= options from /boot/grub/menu.lst (e.g. vga=0x31b)
2. Disable bootsplash in /etc/sysconfig/bootsplash
3. mkinitrd
4. reboot

Thanks to hifi and Ke in #radeon on irc.freenode.net for their help and input on this matter.

Edit:

If this doesn't help, try adding

nomodeset

to the kernel command line in /boot/grub/menu.lst (or just try the failsafe boot option which has this option added by default).

Thanks to cb400f in #suse on irc.freenode.net for pointing this out.

Bietet jemand mehr?

After obtaining the decryption code the tech guy is able to decode the hard drive:

See still images of the decryption sequence here, here and here.

The obtained code actually is the HTML code of MathCode download page at mathcore.com, worth $400 million.

I laughed out loud.

reject: RCPT from gw01.zanox.com[217.110.111.101]: 554 <z-de-dom02.zanox.com>: Helo command rejected: Host not found; from=<XXXXXX@zanox.com> to=<YYYYYYY>

Schon erstaunlich wie sich solch große Firmen wie Zanox solche Anfängerfehler Schnitzer leisten.

Wie liefern die überhaupt irgendwo Emails ein?

User enters ********@ks-webstyle.de on facebook register form. Facebook checks if entered address can receive mail.
Postfix does sender verification (reject_unverified_sender), policyd-weight checks DNS, RBLs and some other stuff.
69.63.178.167 is listed in ix.dnsbl.manitu.net, oops! Overall rated as spam since some checks made this email look fishy:

May  6 11:36:08 zeus postfix/smtpd[14590]: connect from outmail008.snc1.tfbnw.net[69.63.178.167]
May  6 11:36:09 zeus postfix/qmgr[21372]: 675DA3206E: from=<double-bounce@zeus.andox.de>, size=260, nrcpt=1 (queue active)
May  6 11:36:14 zeus postfix/smtp[14593]: 675DA3206E: to=<notification+abcdefgh=6g1@facebookmail.com>, relay=mx01.facebookmail.com[69.63.179.27]:25, delay=5.1, delays=0.01/0/5.1/0, dsn=4.4.2, status=undeliverable (lost connection with mx01.facebookmail.com[69.63.179.27] while receiving the initial server greeting)
May  6 11:36:14 zeus postfix/qmgr[21372]: 675DA3206E: removed
May  6 11:36:20 zeus postfix/policyd-weight[25030]: weighted check:  NOT_IN_DYN_PBL_SPAMHAUS=0 NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 DSBL_ORG=SKIP(0) IN_IX_MANITU=4.35 NOT_IN_RELAYS_SORBS=0 NOT_IN_CBL_ABUSEAT_ORG=0 HELO_IP_IN_CL16_SUBNET=-0.41 RESOLVED_IP_IS_NOT_HELO=1.5 (check from: .facebookmail. - helo: .mx-out.facebook. - helo-domain: .facebook.)  FROM/MX_MATCHES_NOT_UNVR_HELO(DOMAIN)=5.95 CLIENT_NOT_MX/A_FROM_DOMAIN=5.85 CLIENT/24_NOT_MX/A_FROM_DOMAIN=5.85; <client=69.63.178.167> <helo=mx-out.facebook.com> <from=notification@facebookmail.com> <to=********@ks-webstyle.de>; rate: 18.59
May  6 11:36:20 zeus postfix/policyd-weight[25030]: decided action=550 Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; please relay via your ISP (facebookmail.com); <client=69.63.178.167> <helo=mx-out.facebook.com> <from=notification+abcdefgh=6g1@facebookmail.com> <to=********@ks-webstyle.de>; delay: 1s
May  6 11:36:20 zeus postfix/smtpd[14590]: NOQUEUE: reject: RCPT from outmail008.snc1.tfbnw.net[69.63.178.167]: 550 5.7.1 <********@ks-webstyle.de>: Recipient address rejected: Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; please relay via your ISP (facebookmail.com); from=<notification+abcdefgh=6g1@facebookmail.com> to=<********@ks-webstyle.de> proto=ESMTP helo=<mx-out.facebook.com>
May  6 11:36:26 zeus postfix/smtpd[14590]: disconnect from outmail008.snc1.tfbnw.net[69.63.178.167]

Facebook decides to accept ********@ks-webstyle.de as valid email address to register with and sends email with activation link.
This time sender verification succeeds without error, client IP is not listed in RBLs, mail not looking fishy.
So do we accept it? Nope - let's do greylisting:

May  6 11:38:42 zeus postfix/smtpd[14662]: connect from outmail021.snc1.tfbnw.net[69.63.178.180]
May  6 11:38:42 zeus postfix/qmgr[21372]: C59AE3206E: from=<double-bounce@zeus.andox.de>, size=260, nrcpt=1 (queue active)
May  6 11:38:44 zeus postfix/smtp[14666]: C59AE3206E: to=<password+abcdefgh=6g1@facebookmail.com>, relay=mx01.facebookmail.com[69.63.179.27]:25, delay=1.4, delays=0.01/0/0.88/0.56, dsn=2.1.5, status=deliverable (250 2.1.5 <password+abcdefgh=6g1@facebookmail.com>... Recipient ok)
May  6 11:38:44 zeus postfix/qmgr[21372]: C59AE3206E: removed
May  6 11:38:54 zeus postfix/policyd-weight[8422]: weighted check:  NOT_IN_DYN_PBL_SPAMHAUS=0 NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 DSBL_ORG=ERR(0) NOT_IN_IX_MANITU=0 NOT_IN_RELAYS_SORBS=0 NOT_IN_CBL_ABUSEAT_ORG=0 HELO_IP_IN_CL16_SUBNET=-0.41 RESOLVED_IP_IS_NOT_HELO=1.5 (check from: .facebookmail. - helo: .mx-out.facebook. - helo-domain: .facebook.)  FROM/MX_MATCHES_NOT_UNVR_HELO(DOMAIN)=1.6; <client=69.63.178.180> <helo=mx-out.facebook.com> <from=password@facebookmail.com> <to=********@ks-webstyle.de>; rate: -1.81
May  6 11:38:54 zeus postfix/policyd-weight[8422]: decided action=PREPEND X-policyd-weight:  NOT_IN_DYN_PBL_SPAMHAUS=0 NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 DSBL_ORG=ERR(0) NOT_IN_IX_MANITU=0 NOT_IN_RELAYS_SORBS=0 NOT_IN_CBL_ABUSEAT_ORG=0 HELO_IP_IN_CL16_SUBNET=-0.41 RESOLVED_IP_IS_NOT_HELO=1.5 (check from: .facebookmail. - helo: .mx-out.facebook. - helo-domain: .facebook.)  FROM/MX_MATCHES_NOT_UNVR_HELO(DOMAIN)=1.6; rate: -1.81; <client=69.63.178.180> <helo=mx-out.facebook.com> <from=password+abcdefgh=6g1@facebookmail.com> <to=********@ks-webstyle.de>; delay: 7s
May  6 11:38:54 zeus postgrey: action=greylist, reason=new, client_name=outmail021.snc1.tfbnw.net, client_address=69.63.178.180, sender=password+abcdefgh=6g1@facebookmail.com, recipient=********@ks-webstyle.de
May  6 11:38:54 zeus postfix/smtpd[14662]: NOQUEUE: reject: RCPT from outmail021.snc1.tfbnw.net[69.63.178.180]: 450 4.2.0 <********@ks-webstyle.de>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/ks-webstyle.de.html; from=<password+abcdefgh=6g1@facebookmail.com> to=<********@ks-webstyle.de> proto=ESMTP helo=<mx-out.facebook.com>
May  6 11:39:00 zeus postfix/smtpd[14662]: disconnect from outmail021.snc1.tfbnw.net[69.63.178.180]

Five minutes passed, facebook tries to deliver password mail again.
69.63.178.168 is listed in SPAMCOP, oops!
policyd-weight again has reservations about this mail ... looking fishy again.
We better don't accept this mail - looks like spam if you ask me:

May  6 11:43:55 zeus postfix/smtpd[14843]: connect from outmail009.snc1.tfbnw.net[69.63.178.168]
May  6 11:43:57 zeus postfix/policyd-weight[8427]: weighted check:  NOT_IN_DYN_PBL_SPAMHAUS=0 NOT_IN_SBL_XBL_SPAMHAUS=-1.5 IN_SPAMCOP=3.75 NOT_IN_BL_NJABL=-1.5 DSBL_ORG=SKIP(0) NOT_IN_IX_MANITU=0 NOT_IN_RELAYS_SORBS=0 NOT_IN_CBL_ABUSEAT_ORG=0 HELO_IP_IN_CL16_SUBNET=-0.41 RESOLVED_IP_IS_NOT_HELO=1.5 (check from: .facebookmail. - helo: .mx-out.facebook. - helo-domain: .facebook.)  FROM/MX_MATCHES_NOT_UNVR_HELO(DOMAIN)=5.35 CLIENT_NOT_MX/A_FROM_DOMAIN=5.25 CLIENT/24_NOT_MX/A_FROM_DOMAIN=5.25; <client=69.63.178.168> <helo=mx-out.facebook.com> <from=password@facebookmail.com> <to=********@ks-webstyle.de>; rate: 17.69
May  6 11:43:57 zeus postfix/policyd-weight[8427]: decided action=550 Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; please relay via your ISP (facebookmail.com); <client=69.63.178.168> <helo=mx-out.facebook.com> <from=password+abcdefgh=6g1@facebookmail.com> <to=********@ks-webstyle.de>; delay: 1s
May  6 11:43:57 zeus postfix/smtpd[14843]: NOQUEUE: reject: RCPT from outmail009.snc1.tfbnw.net[69.63.178.168]: 550 5.7.1 <********@ks-webstyle.de>: Recipient address rejected: Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; please relay via your ISP (facebookmail.com); from=<password+abcdefgh=6g1@facebookmail.com> to=<********@ks-webstyle.de> proto=ESMTP helo=<mx-out.facebook.com>
May  6 11:44:02 zeus postfix/smtpd[14843]: disconnect from outmail009.snc1.tfbnw.net[69.63.178.168]

User triggers sending validation mail again.
69.63.184.110 listed in ix.dnsbl.manitu.net, oops!
Again, this email looks too fishy to be accepted:

May  6 15:26:35 zeus postfix/smtpd[23994]: connect from outmail010.ash1.tfbnw.net[69.63.184.110]
May  6 15:26:39 zeus postfix/policyd-weight[25030]: weighted check:  NOT_IN_DYN_PBL_SPAMHAUS=0 NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 DSBL_ORG=SKIP(0) IN_IX_MANITU=4.35 NOT_IN_RELAYS_SORBS=0 NOT_IN_CBL_ABUSEAT_ORG=0 HELO_IP_IN_CL16_SUBNET=-0.41 RESOLVED_IP_IS_NOT_HELO=1.5 (check from: .facebookmail. - helo: .mx-out.facebook. - helo-domain: .facebook.)  FROM/MX_MATCHES_NOT_UNVR_HELO(DOMAIN)=5.95 CLIENT_NOT_MX/A_FROM_DOMAIN=5.85 CLIENT/24_NOT_MX/A_FROM_DOMAIN=5.85; <client=69.63.184.110> <helo=mx-out.facebook.com> <from=password@facebookmail.com> <to=********@ks-webstyle.de>; rate: 18.59
May  6 15:26:39 zeus postfix/policyd-weight[25030]: decided action=550 Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; please relay via your ISP (facebookmail.com); <client=69.63.184.110> <helo=mx-out.facebook.com> <from=password+abcdefgh@facebookmail.com> <to=********@ks-webstyle.de>; delay: 3s
May  6 15:26:39 zeus postfix/smtpd[23994]: NOQUEUE: reject: RCPT from outmail010.ash1.tfbnw.net[69.63.184.110]: 550 5.7.1 <********@ks-webstyle.de>: Recipient address rejected: Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; please relay via your ISP (facebookmail.com); from=<password+abcdefgh=6g1@facebookmail.com> to=<********@ks-webstyle.de> proto=ESMTP helo=<mx-out.facebook.com>
May  6 15:26:45 zeus postfix/smtpd[23994]: disconnect from outmail010.ash1.tfbnw.net[69.63.184.110]

It's a new day, it's a new day... lets try again.
User triggers sending validation mail again.
69.63.178.162 not listed in RBLs, DNS and HELO looking good!
So do we accept it? Nope - let's do greylisting (postgrey running with --lookup-by-host):

May  7 10:26:49 zeus postfix/smtpd[1571]: connect from outmail003.snc1.tfbnw.net[69.63.178.162]
May  7 10:26:51 zeus postfix/policyd-weight[8427]: weighted check:  NOT_IN_DYN_PBL_SPAMHAUS=0 NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 DSBL_ORG=SKIP(0) NOT_IN_IX_MANITU=0 NOT_IN_RELAYS_SORBS=0 NOT_IN_CBL_ABUSEAT_ORG=0 HELO_IP_IN_CL16_SUBNET=-0.41 RESOLVED_IP_IS_NOT_HELO=1.5 (check from: .facebookmail. - helo: .mx-out.facebook. - helo-domain: .facebook.)  FROM/MX_MATCHES_NOT_UNVR_HELO(DOMAIN)=1.6; <client=69.63.178.162> <helo=mx-out.facebook.com> <from=password@facebookmail.com> <to=********@ks-webstyle.de>; rate: -1.81
May  7 10:26:51 zeus postfix/policyd-weight[8427]: decided action=PREPEND X-policyd-weight:  NOT_IN_DYN_PBL_SPAMHAUS=0 NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 DSBL_ORG=SKIP(0) NOT_IN_IX_MANITU=0 NOT_IN_RELAYS_SORBS=0 NOT_IN_CBL_ABUSEAT_ORG=0 HELO_IP_IN_CL16_SUBNET=-0.41 RESOLVED_IP_IS_NOT_HELO=1.5 (check from: .facebookmail. - helo: .mx-out.facebook. - helo-domain: .facebook.)  FROM/MX_MATCHES_NOT_UNVR_HELO(DOMAIN)=1.6; rate: -1.81; <client=69.63.178.162> <helo=mx-out.facebook.com> <from=password+abcdefgh=6g1@facebookmail.com> <to=********@ks-webstyle.de>; delay: 1s
May  7 10:26:51 zeus postgrey: action=greylist, reason=new, client_name=outmail003.snc1.tfbnw.net, client_address=69.63.178.162, sender=password+abcdefgh=6g1@facebookmail.com, recipient=********@ks-webstyle.de
May  7 10:26:51 zeus postfix/smtpd[1571]: NOQUEUE: reject: RCPT from outmail003.snc1.tfbnw.net[69.63.178.162]: 450 4.2.0 <********@ks-webstyle.de>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/ks-webstyle.de.html; from=<password+abcdefgh=6g1@facebookmail.com> to=<********@ks-webstyle.de> proto=ESMTP helo=<mx-out.facebook.com>
May  7 10:26:57 zeus postfix/smtpd[1571]: disconnect from outmail003.snc1.tfbnw.net[69.63.178.162]

Policyd-weight being angry with facebook:

May  7 10:31:52 zeus postfix/smtpd[2382]: connect from outmail008.snc1.tfbnw.net[69.63.178.167]
May  7 10:31:53 zeus postfix/policyd-weight[8427]: decided action=550 temporarily blocked because of previous errors - retrying too fast. penalty: 30 seconds x 0 retries.; <client=69.63.178.167> <helo=mx-out.facebook.com> <from=password+abcdefgh=6g1@facebookmail.com> <to=********@ks-webstyle.de>; delay: 0s
May  7 10:31:53 zeus postfix/smtpd[2382]: NOQUEUE: reject: RCPT from outmail008.snc1.tfbnw.net[69.63.178.167]: 550 5.7.1 <********@ks-webstyle.de>: Recipient address rejected: temporarily blocked because of previous errors - retrying too fast. penalty: 30 seconds x 0 retries.; from=<password+abcdefgh=6g1@facebookmail.com> to=<********@ks-webstyle.de> proto=ESMTP helo=<mx-out.facebook.com>
May  7 10:31:58 zeus postfix/smtpd[2382]: disconnect from outmail008.snc1.tfbnw.net[69.63.178.167]

User triggers sending validation mail again.
69.63.184.101 not listed in RBLs, DNS and HELO looking good!
But ... new IP, new greylisting:

May  7 11:13:45 zeus postfix/smtpd[4138]: connect from outmail001.ash1.tfbnw.net[69.63.184.101]
May  7 11:13:47 zeus postfix/policyd-weight[8422]: weighted check:  NOT_IN_DYN_PBL_SPAMHAUS=0 NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 DSBL_ORG=SKIP(0) NOT_IN_IX_MANITU=0 NOT_IN_RELAYS_SORBS=0 NOT_IN_CBL_ABUSEAT_ORG=0 HELO_IP_IN_CL16_SUBNET=-0.41 RESOLVED_IP_IS_NOT_HELO=1.5 (check from: .facebookmail. - helo: .mx-out.facebook. - helo-domain: .facebook.)  FROM/MX_MATCHES_NOT_UNVR_HELO(DOMAIN)=1.6; <client=69.63.184.101> <helo=mx-out.facebook.com> <from=password@facebookmail.com> <to=********@ks-webstyle.de>; rate: -1.81
May  7 11:13:47 zeus postfix/policyd-weight[8422]: decided action=PREPEND X-policyd-weight:  NOT_IN_DYN_PBL_SPAMHAUS=0 NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 DSBL_ORG=SKIP(0) NOT_IN_IX_MANITU=0 NOT_IN_RELAYS_SORBS=0 NOT_IN_CBL_ABUSEAT_ORG=0 HELO_IP_IN_CL16_SUBNET=-0.41 RESOLVED_IP_IS_NOT_HELO=1.5 (check from: .facebookmail. - helo: .mx-out.facebook. - helo-domain: .facebook.)  FROM/MX_MATCHES_NOT_UNVR_HELO(DOMAIN)=1.6; rate: -1.81; <client=69.63.184.101> <helo=mx-out.facebook.com> <from=password+abcdefgh=6g1@facebookmail.com> <to=********@ks-webstyle.de>; delay: 1s
May  7 11:13:47 zeus postgrey: action=greylist, reason=new, client_name=outmail001.ash1.tfbnw.net, client_address=69.63.184.101, sender=password+abcdefgh=6g1@facebookmail.com, recipient=********@ks-webstyle.de
May  7 11:13:47 zeus postfix/smtpd[4138]: NOQUEUE: reject: RCPT from outmail001.ash1.tfbnw.net[69.63.184.101]: 450 4.2.0 <********@ks-webstyle.de>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/ks-webstyle.de.html; from=<password+abcdefgh=6g1@facebookmail.com> to=<********@ks-webstyle.de> proto=ESMTP helo=<mx-out.facebook.com>
May  7 11:13:52 zeus postfix/smtpd[4138]: disconnect from outmail001.ash1.tfbnw.net[69.63.184.101]

5 Minutes passed, facebook trying again.
Finally, mail gets accepted and delivered!

May  7 11:18:48 zeus postfix/smtpd[4138]: connect from outmail001.ash1.tfbnw.net[69.63.184.101]
May  7 11:18:49 zeus postfix/policyd-weight[8422]: decided action=PREPEND X-policyd-weight: using cached result; rate: -1.81; <client=69.63.184.101> <helo=mx-out.facebook.com> <from=password+abcdefgh=6g1@facebookmail.com> <to=********@ks-webstyle.de>; delay: 1s
May  7 11:18:49 zeus postgrey: action=pass, reason=triplet found, delay=302, client_name=outmail001.ash1.tfbnw.net, client_address=69.63.184.101, sender=password+abcdefgh=6g1@facebookmail.com, recipient=********@ks-webstyle.de
May  7 11:18:49 zeus postfix/smtpd[4138]: 4FA823206E: client=outmail001.ash1.tfbnw.net[69.63.184.101]
May  7 11:18:49 zeus postfix/cleanup[4365]: 4FA823206E: message-id=<8bcuca248z9101532add24ac7fa02be5@www.facebook.com>
May  7 11:18:49 zeus postfix/qmgr[21372]: 4FA823206E: from=<password+abcdefgh=6g1@facebookmail.com>, size=2464, nrcpt=1 (queue active)
May  7 11:18:49 zeus postfix/pipe[4367]: 4FA823206E: to=<********@ks-webstyle.de>, relay=dovecot, delay=0.99, delays=0.97/0/0/0.01, dsn=2.0.0, status=sent (delivered via dovecot service)
May  7 11:18:49 zeus postfix/qmgr[21372]: 4FA823206E: removed
May  7 11:18:54 zeus postfix/smtpd[4138]: disconnect from outmail001.ash1.tfbnw.net[69.63.184.101]

Maybe we use --lookup-by-subnet with postgrey instead of --lookup-by-host. Or Facebook just fixes the DNS/HELO and RBL issues - it's in their own interest.

Ich behaupte natürlich nicht, ein Mitarbeiter der Firma Villa Schmidt GmbH aus Hamburg oder sogar dessen Geschäftsführer Michael Schmidt würde hier Kommentar-Spam verbreiten.

Es ist sicher reiner Zufall, dass die IP-Adresse 85.176.204.72, die zum Absenden des Kommentars genutzt wurde, im Großraum Hamburg vergeben wird:

1 gate.local
2 217.0.XXX.XXX
3 217.0.XXX.XXX
4 hh-ea4-i.HH.DE.NET.DTAG.DE
5 217.243.217.14
6 customer-side-hansenet-4-amb1.amb.seabone.net
7 ae5-0.cr01.asham.de.hansenet.net
8 e176204072.adsl.alicedsl.de

asham ist Hansenets PoP in der Willy-Brandt-Straße in Hamburgs Altstadt. Wie es der Zufall will, befindet sich in nur 1,2 km Entfernung, in der Spaldingstraße 64, das Ausstellungs- und Beratungszentrum der Villa Schmidt GmbH.

Ich bin sicher, dass der Kommentator aus Hamburgs Altstadt, der im Blog seinen Spam zum Bewerben der Royal Botania Produkte abgeladen hat, rein garnichts mit der Villa Schmidt GmbH aus der Altstadt Hamburg zu tun hat.

Denn die Villa Schmidt GmbH, die laut ihrer Webseite weltweit private Domizile und Luxushotels mit exklusiven Gartenmöbeln und Sonnenschirmen ausstattet, würde sich sicher nie solch dubioser und von vielen Web Citizens verachteter SEO-Methoden bedienen.

Edit:

Bei Yahoo Site Explorer sieht man sehr deutlich, daß für die Villa Schmidt GmbH aus Hamburg der Kommentarspam in Blogs zum Alltagsgeschäft gehören muss.

Über 9000 Backlinks hat die Villa Schmidt GmbH da akribisch angehäuft - mit Kommentarspam bestehend aus Worthülsen wie "Very interesting post, thanks for sharing!", "Toller Artikel", "Guter Beitrag", "Cool – Gruesse aus Bochum" oder "Super Post, macht immer Spass hier mitzulesen".

Nichts ist der Villa Schmidt GmbH aus Hamburg zu schade, um nicht doch noch von Ihren SEO-Handlangern "kommentiert" zu werden - wie ein Junkie tingelt die Villa Schmidt GmbH durch die Blogs, immer auf der Suche nach neuen Backlinks.

Ich würde mein Geld für Armlehnstühle, ausziehbare Tische, Bänke, Barmöbel, Beistelltische, Essstühle, Esstische, Heizelemente, Hocker & Fußhocker, Kindermöbel, Kissen & Polster, Kissentruhen, Klappstühle, Liegen, Liegestühle, Loungemöbel, Schaukelstühle, Sessel, Sofas, Terrassenheizer, Sonnenliegen, Sonnenschirme und Sonnenschirmzubehör von so namhaften Herstellern wie z.B. Royal Mirage, Royal Botania, Barlow Tyrie, EGO Paris, Fischer Möbel, Dedon, Rausch Classics, Glatz Sonnenschirme, Glatz Gastronomie Schirme, Herrenhaus, Joli, Lister, NerTes LiRo, Oi Side, Point, Skagerak, Weishäupl, Solpuri, Emu, Deckline, Samoa, Silverplana, Val-Eur, Fuer a Dentro, Alexander Rose und Tuuci Sonnenschirme ganz sicher nicht bei der Villa Schmidt GmbH aus Hamburg lassen.

BTW: Julius hat auch was drüber gebloggt.

Um Strom zu sparen, wird der Schreib-/Lesekopf nach 8 Sekunden Inaktivität in die Parkposition gefahren (WD nennt das ItelliPark) - er liegt somit nicht mehr flach auf den Datenscheiben (Platter) auf, verringert dadurch den Luftwiderstand und hilft so Strom sparen.

Western Digital gibt in der Dokumentation zu den WD Caviar Green-Platten (PDF) 300.000 Load/unload cycles an. Bei 23.771 Cycles nach gerade einmal 300 Betriebsstunden würde das bedeuten, dass wir die spezifizierten 300.000 Cycles bereits nach 5,3 Monaten erreicht hätten.

Füttert man Google mit den passenden Parametern, so findet man nach etwas Recherche das Tool wdidle3 in Version 1.0.3. Gebootet vom USB-Stick via emulierter MS-DOS-Diskette (ein Hoch auf memdisk), verrät einem schließlich das Kommando wdidle3 /r die aktuelle Einstellung der erkannten Platten.

Mit wdidle3 /? bekommt man eine Auflistung der möglichen Parameter, wdidle3 /d "deaktiviert" das lästige Feature; durch ein proprietäres Kommando an die Firmware der Festplatte wird damit das IntelliPark-Intervall auf 3720 Sekunden (62 Minuten) gesetzt.

Hier die gekürzte SMART-Ausgabe für die Load_Cycle_Count-Werte um 18 Uhr:

23621
23771
748
1403
1371
1274
1555
1502
1538

Drei Stunden später (ohne smartdaemon) sieht die Ausgabe so aus:

23621
23771
749
1404
1372
1275
1556
1503
1539

Ich werde über die nächsten Tage per Cronjob die Werte täglich einmal auslesen und dann später berichten, wie sich die Werte bei aktiviertem und deaktiviertem smartdaemon verhalten.

Unser bisheriger Backup-Server im Datacenter war ein betagter Proliant DL380 G3 und sollte durch etwas aktuelleres ersetzt werden, vorzugsweise mit mehr Plattenplatz als nur 6x 300GB im RAID10.

Aus wirtschaftlichen Gründen (es ist "nur" ein Backupserver) haben wir uns gegen einen Server von HP entschieden, nicht zuletzt weil die 1TB SATA-Platten von HP mit 299€/Stück einfach jenseits von gut und böse liegen im Vergleich zu aktuellen Preisen für nicht-HP SATA-Platten im regulären Handel.

Bei der Wahl des Chassis hatten sich mein Azubi und ich relativ schnell für das Chieftec UNC-410F-B entschieden - 4U, 10 5,25"-Einschübe und damit genug Platz für Platten. Außen an das Gehäuse kommt eine Schiene RSR-260 zwecks Rackmontage und fertig ist das Chassis.

Den Saft für den Server liefert das redundant ausgelegte 500W-Netzteil MRG-6500P, das mit seinen 8 Molex- und 2 SATA-Steckern vorläufig genug Anschlüsse liefert.

Beim Mainboard haben wir uns an das von Kris verbaute Asus P5Q Premium gehalten, mussten aber leider während der Testphase feststellen, dass von den 10 SATA-Ports nur 8 sinnvoll nutzbar sind und haben deshalb auch noch eine Adaptec 1430SA nachgekauft.

Auf dem Mainboard findet anschließend eine Intel Core2Quad Q9550 Boxed (C1) CPU, 4x 2GB RAM und eine beliebige Grafikkarte Platz.

Bei der Suche nach passenden Backplanes wurden wir bereits auf der Zubehörseite des Chassis fündig: 3 Backplanes SST-2131SAS verstauen insgesamt 9 Western Digital Caviar WD15EARS.

2 Backplanes bilden mit ihren je 3 Platten ein Software-RAID5 auf dem dann LVM mit einem striped Logical Volume aufsetzt - quasi ein RAID50, durch LVM aber komfortabler zu managen.

Debian Lenny 64-bit ist per PXE-Boot, USB-Stick oder USB-CDROM innerhalb von 10 Minuten installiert, anschließend installieren wir BackupPC und übernehmen die Config-Files vom alten Server.

Beim Partitionieren der Platten sollte man die Sektorgröße von 4kB beachten - "normales" Partitionieren, so wie es der Linux-Sysadmin gewohnt ist, lässt die Schreibperformance auf diese Partitionen auf wenige MByte/s einbrechen.

Wie man es richtig macht findet man im Wiki von brain4free: WD "Advanced Format" HD mit LINUX.

Mittels pvs -o+pe_start stellt man sicher, dass die Nutzdaten des LVM-Layers auf einem Vielfachen der Chunksize des RAID5 beginnen:

PV         VG     Fmt  Attr PSize PFree 1st PE
/dev/md1   debian lvm2 a-   1.36T 1.36T 192.00K
/dev/md2   data   lvm2 a-   2.73T    0  192.00K
/dev/md3   data   lvm2 a-   2.73T    0  192.00K

Da meine Chunksize 64kB beträgt, passt der Beginn der Daten an Stelle 192kB also:

md2 : active raid5 sdd1[0] sdf1[2] sde1[1]
2930152704 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

md3 : active raid5 sdg1[0] sdi1[2] sdh1[1]
2930152704 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

lvs -o+stripes,stripesize,devices

LV       VG     Attr   LSize #Str Stripe Devices
backuppc data   -wi-ao 5.46T    2 64.00K /dev/md2(0),/dev/md3(0)

Wer an dieser Stelle stutzig wird, hat offenbar schon mehrfach mit Software-RAID zu tun gehabt:

Bei einem RAID5 aus 3 Platten mit einer Chunksize von 64kB müsste die optimale Stripesize für das darüberliegende Logical Volume 128kB sein. Verschiedene Benchmarks haben aber zu meiner Verwunderung ergeben, dass die Write-Performance mit der 64kB Stripesize um 10-15 MByte/s höher lag als bei der rechnerisch optimalen Stripesize von 128kB.

Das auf dem LV liegende ext3 FS sollte ebenfalls passend angelegt werden: Mit dem mkfs.ext3 RAID stride calculator ergibt sich bei einem RAID0 über 2 "Platten" mit einer Stripesize von 64kB und einer FS-Blocksize von 4kB folgendes mkfs-Command:

mkfs.ext3 -b 4096 -E stride=16,stripe-width=32 /dev/data/backuppc

Damit erfolgen Schreiboperationen auf das Dateisystem nun in optimaler Weise.

Weitere Stellschrauben:

• Passenden Scheduler zur Workload wählen, z.B: cfq
• stripe-cache-size optimieren

Das Optimieren der stripe-cache-size der 2 RAID5-Bricks von default 256kB auf 4096kB hat bei uns die lineare Writeperformance auf das LV von 180 MByte/s auf 300 MByte/s gesteigert; recht beachtlich, wie ich finde.

Update: ext3- und xfs-Benchmarks mit bonnie++ auf dem LV.

Update: Smart-Werte (sda+sdb = System, sdc = Spare, sdd-sdi = Daten)