The picture shows my HP N54L microserver with an LCD (item no. U204FR-A3 by LCDModkit). The display is controlled via LCDd and lcdproc using the hd44780 driver. It shows the so called CPU screen here. To be continued soon ... :)
Wednesday, July 31, 2013
Friday, July 12, 2013
Reconfiguring my mail server to reject spam
I now spent some time in optimizing my mail server configuration, especially adjusting the rules, which clients and mails get accepted and which not. In its current setup, it's already configured to not act as an open relay. Mails sent via the server have to use SMTP-AUTH.
So these are the rules, that get applied now:
smtpd_delay_reject = yes
smtpd_data_restrictions =
reject_unauth_pipelining
smtpd_client_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_invalid_hostname,
reject_unknown_client_hostname,
reject_non_fqdn_hostname,
reject_rbl_client sbl-xbl.spamhaus.org
smtpd_sender_restrictions =
reject_unknown_address,
reject_unknown_sender_domain,
reject_non_fqdn_sender
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination,
reject_unknown_recipient_domain,
reject_unverified_recipient,
reject_non_fqdn_recipient,
permit
At the moment it already reduced the amount of spam by around 90 %. I hve not yet seen any downside, but I have to check these settings a bit longer to be sure.
Moving from (software) RAID 1 to RAID 5 and testing performance
Finally I finished migrating my new N54L from a 2-disk software RAID 1 (2x2TB WD20EFRX) to 3-disk RAID 5 (3x2TB WD20EFRX) using mdadm. I got an excellent mini HOWTO I followed. Resyncing and reshaping the RAID took several days ... top speed was 110.000K/s ... but left my data untouched. Finally growing the RAID now I have two partitions; one with 0.5GB (md0) and the other with 3.4GB (md1) which both host an EXT4 file system, whereas the first one is encrypted via LUKS and the second one is not.
RAID device and file system configuration
Below is a summary of the setup and the values I found working well for my system.
| 3-disk RAID 5 device | file system | ||||||
|---|---|---|---|---|---|---|---|
| device | chunk | stripe_cache_size | read_ahead_kb | type | encryption | stride | stripe-width |
| /dev/md0 | 64 | 4096 | 32768 | ext4 | luks | 16 | 32 |
| /dev/md1 | 512 | 16384 | 32768 | ext4 | no | 128 | 256 |
I've played around with the system a bit. Changing the chunk size on the fly however took a long time. /dev/md0 will contain some backups, so there probably will be a mixture of small and large files. So I've chosen to only test the values 64K, 128K and 512K (default) for this device. I left the other untouched as it will mainly contain large files.
Performance measurement
Below are the results using hdparm to measure performance. First lets take a look at the drives ...
$ hdparm -tT /dev/sd[bcd] /dev/sdb: Timing cached reads: 3268 MB in 2.00 seconds = 1634.54 MB/sec Timing buffered disk reads: 438 MB in 3.00 seconds = 145.87 MB/sec /dev/sdc: Timing cached reads: 3292 MB in 2.00 seconds = 1646.32 MB/sec Timing buffered disk reads: 392 MB in 3.01 seconds = 130.22 MB/sec /dev/sdd: Timing cached reads: 3306 MB in 2.00 seconds = 1653.18 MB/sec Timing buffered disk reads: 436 MB in 3.00 seconds = 145.26 MB/sec $ hdparm --direct -tT /dev/sd[bcd] /dev/sdb: Timing O_DIRECT cached reads: 468 MB in 2.01 seconds = 233.17 MB/sec Timing O_DIRECT disk reads: 442 MB in 3.00 seconds = 147.15 MB/sec /dev/sdc: Timing O_DIRECT cached reads: 468 MB in 2.00 seconds = 233.69 MB/sec Timing O_DIRECT disk reads: 392 MB in 3.01 seconds = 130.36 MB/sec /dev/sdd: Timing O_DIRECT cached reads: 468 MB in 2.00 seconds = 233.94 MB/sec Timing O_DIRECT disk reads: 442 MB in 3.01 seconds = 146.93 MB/sec
... and now at the RAID devices ...
$ hdparm -tT /dev/md? /dev/md0: Timing cached reads: 3320 MB in 2.00 seconds = 1660.37 MB/sec Timing buffered disk reads: 770 MB in 3.01 seconds = 256.05 MB/sec /dev/md1: Timing cached reads: 3336 MB in 2.00 seconds = 1668.07 MB/sec Timing buffered disk reads: 742 MB in 3.01 seconds = 246.89 MB/sec $ hdparm --direct -tT /dev/md? /dev/md0: Timing O_DIRECT cached reads: 974 MB in 2.00 seconds = 487.08 MB/sec Timing O_DIRECT disk reads: 770 MB in 3.01 seconds = 256.17 MB/sec /dev/md1: Timing O_DIRECT cached reads: 784 MB in 2.00 seconds = 391.18 MB/sec Timing O_DIRECT disk reads: 742 MB in 3.01 seconds = 246.42 MB/sec
... and now lets see, which actual speed we reach using dd. First lets check the encrypted device:
RAID-5 /dev/md0 (LUKS encrypted EXT4): chunk=64K, stripe_cache_size=4096, readahead(blockdev)=65536, stride=16, stripe-width=32 ... $ dd if=/dev/zero of=/mnt/md0/10g.img bs=1k count=10000000 10000000+0 Datensätze ein 10000000+0 Datensätze aus 10240000000 Bytes (10 GB) kopiert, 64,1227 s, 160 MB/s $ dd if=/mnt/md0/10g.img of=/dev/null bs=1k count=10000000 10000000+0 Datensätze ein 10000000+0 Datensätze aus 10240000000 Bytes (10 GB) kopiert, 85,768 s, 119 MB/s
Well, read speed is consistently lower than write speed for the encrypted file system. Lets take a look at the non-encrypted device:
RAID-5 /dev/md1 (EXT4): chunk=512K, stripe_cache_size=16384, readahead(blockdev)=65536, stride=128, stripe-width=256 ... $ dd if=/dev/zero of=/mnt/md1/10g.img bs=1k count=10000000 10000000+0 Datensätze ein 10000000+0 Datensätze aus 10240000000 Bytes (10 GB) kopiert, 37,0016 s, 277 MB/s $ dd if=/mnt/md1/10g.img of=/dev/null bs=1k count=10000000 10000000+0 Datensätze ein 10000000+0 Datensätze aus 10240000000 Bytes (10 GB) kopiert, 33,5901 s, 305 MB/s
Looks nice to me.
How to set these values
I use a mixture of udev, util-linux and e2fsprogs to set the values.
First I checked, which values for stripe_cache_size and read_ahead_kb are working best for me. For the LUKS encrypted EXT4 I got varying results showing best performances with values of 4096, 8192 and 16384 for stripe_cache_size. I decided for the first value, because it appeared more often with the best performance than the others.
$ less /etc/udev/rules.d/90-local-n54l.rules | grep stripe_cache
SUBSYSTEM=="block", KERNEL=="md0", ACTION=="add", TEST=="md/stripe_cache_size", TEST=="queue/read_ahead_kb", ATTR{md/stripe_cache_size}="4096", ATTR{queue/read_ahead_kb}="32768", ATTR{bdi/read_ahead_kb}="32768"
SUBSYSTEM=="block", KERNEL=="md1", ACTION=="add", TEST=="md/stripe_cache_size", TEST=="queue/read_ahead_kb", ATTR{md/stripe_cache_size}="16384", ATTR{queue/read_ahead_kb}="32768", ATTR{bdi/read_ahead_kb}="32768"
The read_ahead_kb value can also be set using blockdev. Note that this command expects a value of 512-byte sectors whereas read_ahead_kb is the size in kbyte. Therefor the difference in values:
$ blockdev --setra 65536 /dev/md[01]
Tuning the EXT4 file system performance with calculated values using tune2fs:
$ tune2fs -E stride=16,stripe-width=32 -O dir_index /dev/mapper/_dev_md0 $ tune2fs -E stride=128,stripe-width=256 -O dir_index /dev/md1
Disabling NCQ reduced the speed a lot for me, so I left the values as is and did not struggle with it:
$ cat /sys/block/sd[bcd]/device/queue_depth 31 31 31
Sunday, June 30, 2013
Dear Lazyweb ... why does lshw (still) identify my Linux raid autodetect partition(s) as NTFS volumes?
In a very first attempt, my disk:2 was partitioned and initialized as follows:
/dev/sdc1 1,5TB NTFS /dev/sdc2 0,5TB EXT4
This was later changed to what you can see below and what fdisk correctly reports. These partitions all use the EXT4 file system.
[..] Device Boot Start End Blocks Id System /dev/sdb1 2048 524290047 262144000 fd Linux raid autodetect /dev/sdb2 524290048 3907029167 1691369560 fd Linux raid autodetect [..] Device Boot Start End Blocks Id System /dev/sdc1 2048 524290047 262144000 fd Linux raid autodetect /dev/sdc2 524290048 3907029167 1691369560 fd Linux raid autodetect [..]
I'm wondering why lshw and parted shows some of the partitions still being NTFS volumes? Checkout the output below. How can this be fixed? What is missing? Erase some header data?
Model: ATA WDC WD20EFRX-68A (scsi) Disk /dev/sdb: 2000GB Sector size (logical/physical): 512B/4096B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 268GB 268GB primary raid 2 268GB 2000GB 1732GB primary raid Model: ATA WDC WD20EFRX-68A (scsi) Disk /dev/sdc: 2000GB Sector size (logical/physical): 512B/4096B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 268GB 268GB primary ntfs raid 2 268GB 2000GB 1732GB primary raid
[..]
*-disk:1
description: ATA Disk
product: WDC WD20EFRX-68A
vendor: Western Digital
physical id: 1
bus info: scsi@3:0.0.0
logical name: /dev/sdb
version: 80.0
serial: WD-WCC300354221
size: 1863GiB (2TB)
capabilities: partitioned partitioned:dos
configuration: ansiversion=5 sectorsize=4096
*-volume:0
description: Linux raid autodetect partition
physical id: 1
bus info: scsi@3:0.0.0,1
logical name: /dev/sdb1
capacity: 250GiB
capabilities: primary multi
*-volume:1
description: Linux raid autodetect partition
physical id: 2
bus info: scsi@3:0.0.0,2
logical name: /dev/sdb2
capacity: 1613GiB
capabilities: primary multi
*-disk:2
description: ATA Disk
product: WDC WD20EFRX-68A
vendor: Western Digital
physical id: 2
bus info: scsi@4:0.0.0
logical name: /dev/sdc
version: 80.0
serial: WD-WCC1T0567095
size: 1863GiB (2TB)
capabilities: partitioned partitioned:dos
configuration: ansiversion=5 sectorsize=4096 signature=000a4d07
*-volume:0
description: Windows NTFS volume
physical id: 1
bus info: scsi@4:0.0.0,1
logical name: /dev/sdc1
version: 3.1
serial: 013e-8473
size: 1396GiB
capabilities: primary multi ntfs initialized
configuration: clustersize=4096 created=2013-06-18 06:24:11 filesystem=ntfs label=MEDIA state=clean
*-volume:1
description: Linux raid autodetect partition
physical id: 2
bus info: scsi@4:0.0.0,2
logical name: /dev/sdc2
capacity: 1613GiB
capabilities: primary multi
[..]
Saturday, June 29, 2013
Petition zum Erhalt und Fortbestand der Professur für Technische Chemie an der TU Dresden
In eigener Sache bitte ich Kenner, ehemalige Studenten und Sympathisanten des Instituts für Technische Chemie Dresden um Unterstützung bei der Petition zum Erhalt und Fortbestand der einzigen Professur für Technische Chemie an der TU Dresden. Da ich selber in der Vergangenheit sehr eng mit dieser Professur (und mittelständischen Unternehmen) zusammen gearbeitet habe, waren die Ereignisse (PDF) der letzten Jahre überraschend für mich. Ich kann mir eine Technische Universität ohne die Professur kaum vorstellen.
Friday, June 28, 2013
Getting the TP-Link TL-WN772N(C) USB WLAN stick to work
After installing Debian wheezy on the N54L microserver I wanted to setup a stable WLAN connection. The stick should have out-of-the-box kernel support. First I bought a cheap ISY IWL 2000 N150 WLAN USB micro adapter (probably a branded Belkin F7D1102). I contains a Realtek chipset and although it did seem to work on my laptop with Sid running, I did not get it to work on the server. I refused to download and compile third-party software.
So I searched this site. I got the impression, that the "only" recent chipsets with reasonable support in the Linux kernel are Atheros chipsets(?). Checking the local suppliers I decided to buy a TP-Link TL-WN722NC USB stick. I've downloaded the firmware-atheros package and loaded the ath9k_htc module and voilà, the stick is running:
ath9k_htc 48534 0 ath9k_common 12728 1 ath9k_htc ath9k_hw 322112 2 ath9k_common,ath9k_htc ath 21370 3 ath9k_hw,ath9k_common,ath9k_htc mac80211 192806 1 ath9k_htc cfg80211 137243 3 ath,mac80211,ath9k_htc usbcore 128741 5 ehci_hcd,ohci_hcd,usbhid,ath9k_htc
[..] Bus 001 Device 003: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize0 64 idVendor 0x0cf3 Atheros Communications, Inc. idProduct 0x9271 AR9271 802.11n bcdDevice 1.08 iManufacturer 16 ATHEROS iProduct 32 USB2.0 WLAN iSerial 48 12345 bNumConfigurations 1 [..]
To setup the connection I decided to install the network-manager package and write the configuration file myself:
[connection] id=<myID> uuid=<myUUID> type=802-11-wireless autoconnect=true [802-11-wireless] ssid=<mySSID> mode=infrastructure mac-address=<myMACADDR> seen-bssids=<myBSSIDS> security=802-11-wireless-security [802-11-wireless-security] key-mgmt=wpa-psk psk=<myPASSPHR> [ipv4] method=auto [ipv6] method=auto
[..]
wlan1 IEEE 802.11bgn ESSID:"<ESSID>"
Mode:Managed Frequency:2.467 GHz Access Point: <MACADDR>
Bit Rate=54 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=49/70 Signal level=-61 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:61 Missed beacon:0
[..]
The connection comes up and it seems pretty stable. After two weeks of operation there were still no connection losses or time outs. After lease time has been reached, the IP address gets renewed. And that's it! The stick runs perfectly fine for me and I'm happy with it.
Thursday, June 27, 2013
N54L - Lüftertausch
Nachdem ich mich im Vorfeld bereits belesen hatte, erwartete ich erschwerte Bedingungen, den im N54L verbauten Gehäuselüfter gegen einen Scythe Slip Stream Gehäuselüfter 120mm mit 800 RPM und 11dB für ca. 9 EUR (SY1225SL12L) zu tauschen.
Die erste "Überraschung" erwartete mich nach dem Auspacken des neuen Lüfters: statt des erwarteten 4-Pin-Anschlusses war da nur ein 3-Pin-Anschluss sowie ein Adapterkabel zum Anschluss des Lüfters an einen 12V MOLEX-Stecker. Der Gehäuselüfter im N54L steckt jedoch mit einem 4-Pin-Anschluss am Mainboard. Um es vorweg zu nehmen: Der o.g. Scythe-Lüfter ist kein PWM-Modell und verfügt damit nicht über den vierten Anschluss. Positiv ist, das ich auch gar nicht erst die Anschlüsse am 3-Pin-Stecker tauschen musste und dieser auch sehr gut auf dem Board befestigt werden kann ... sofern man über eine Verlängerung verfügt! Diese war glücklicherweise noch vorhanden. Sogar ein Regelmodul von Zalman fand sich noch in den Überresten älterer PCs - wurde jetzt aber nicht verbaut :)
So bin ich vorgegangen um den alten Lüfter zu entfernen:
- N54L ausschalten und Stromversorgung trennen
- Fronttür des N54L öffnen - am Anschlag die Tür leicht anheben und so aus ihrer Verankerung befreien und vollständig abnehmen
- Kopfplatte des N54L abnehmen; Schraube an der Rückseite lösen (Handbuch); Platte zunächst nach vorne ziehen und dann leicht anheben; Blick auf den Gehäuselüfter wird freigegeben
- Kabel des Lüfters suchen - verläuft links neben Einschubschacht für optisches Laufwerk und dann am linken Gehäuserand bis zum Mainboard, wo der Stecker ca. 2,5cm neben dem USB-Anschluss auf dem Mainboard steckt - mit insg. 3x Kabelbindern befestigt
- Kabelbinder entlang des Lüfterkabels mit Seitenschneider entfernen
- Anschluss des Lüfters vorsichtig mit Telefonzange und Fingern vom Mainboard abziehen (ging etwas schwer)
- Clip auf der rechten Gehäuseseite öffnen (dagegen drücken), Lüfterkabel entfernen und Clip wieder schließen
- Lüfterkabel vorsichtig durch die Schächte zum Gehäuselüfter zurückziehen
- 4 Schrauben des Lüfters am hinteren Gehäuse mit dem Torx-Schlüssel (Servertür) lösen und entfernen
- vorsichtig den Lüfter entlang den Schienen nach oben ziehen - dabei habe ich die Kabel von den Festplattenplattenschächten mit einem Lineal vom Lüftergitter ferngehalten, da diese sonst in das Gitter ragten
- Lüfter entnehmen
- Befestigung des Lüftergitters lösen, indem die Stifte mit einem spitzen Gegenstand (Telefonzange) nach außen gedrückt und dann die Befestigung selbst entfernt wird
Entgegen meiner Erwartung hatte der Scythe-Lüfter die richtige Steckerbelegung für das HP-Board (Pin 4: gelb, Pin 3: rot, Pin 2: schwarz - Pin 1: "Control" wird nicht belegt). Dementsprechend musste ich gar nichts weiter tun. Lt. dieser Webseite kann der 3-Pin-Stecker einfach befestigt werden. Allerdings bleibt im N54L auf dem Board der Pin 1 (der hinterste) frei. Und so, um den neuen Scythe Lüfter einzubauen:
- passende Verlängerung (3-Pin auf 3-Pin) heraussuchen und an dem Stecker, der auf dem Mainboard befestigt werden soll, die linke Führungsfeder mit einem Teppichmesser abschneiden
- Verlängerung mit Lüfter verbinden
- (Testbetrieb durch Anschließen des Lüfters am Mainboard und kurzzeitiges Einschalten des Servers)
- Lüftergitter am Scythe-Lüfter anbringen, Stifte zum Schluss wieder einschieben und das Lüftergitter befestigen
- Lüfter langsam entlang der Schienen einschieben (dabei wieder die Kabel vom Lüftergitter fernhalten)
- Lüfter mit den vier Torx-Schrauben befestigen
- Kabel entlang Einschubschacht für optisches Laufwerk verlegen; in Clip auf der linken Gehäuseseite befestigen
- 3-Pin-Stecker auf dem Mainboard befestigen (der hinterste Pin für PWM bleibt unbelegt) - dank des Entfernens der Feder passt der Stecker :)
- Kabellage noch einmal prüfen und dann Lüftungskabel mit Kabelbindern an den drei originalen Stellen wieder befestigen
- Kopfplatte anbringen und mit Schraube an der Rückseite befestigen
- Tür einhängen und schließen
Nach dem Verbinden der Stromversorgung lief der Server beim Einschalten wieder an. Der Scythe-Lüfter ist hörbar leiser als der original verbaute. Das ist sehr gut. Aber für mich könnte der N54L dennoch eine Spur leiser werden.
