Wednesday, July 31, 2013

N54L LCD-Mod with U204FR-A3 (LCDModkit) and lcdproc *pic*

N54L LCD-Mod with U204FR-A3 (LCDModkit) and lcdproc CPU screen

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 ... :)

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.

Link zur Petition

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:

  1. N54L ausschalten und Stromversorgung trennen
  2. Fronttür des N54L öffnen - am Anschlag die Tür leicht anheben und so aus ihrer Verankerung befreien und vollständig abnehmen
  3. 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
  4. 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
  5. Kabelbinder entlang des Lüfterkabels mit Seitenschneider entfernen
  6. Anschluss des Lüfters vorsichtig mit Telefonzange und Fingern vom Mainboard abziehen (ging etwas schwer)
  7. Clip auf der rechten Gehäuseseite öffnen (dagegen drücken), Lüfterkabel entfernen und Clip wieder schließen
  8. Lüfterkabel vorsichtig durch die Schächte zum Gehäuselüfter zurückziehen
  9. 4 Schrauben des Lüfters am hinteren Gehäuse mit dem Torx-Schlüssel (Servertür) lösen und entfernen
  10. 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
  11. Lüfter entnehmen
  12. 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:

  1. 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
  2. Verlängerung mit Lüfter verbinden
  3. (Testbetrieb durch Anschließen des Lüfters am Mainboard und kurzzeitiges Einschalten des Servers)
  4. Lüftergitter am Scythe-Lüfter anbringen, Stifte zum Schluss wieder einschieben und das Lüftergitter befestigen
  5. Lüfter langsam entlang der Schienen einschieben (dabei wieder die Kabel vom Lüftergitter fernhalten)
  6. Lüfter mit den vier Torx-Schrauben befestigen
  7. Kabel entlang Einschubschacht für optisches Laufwerk verlegen; in Clip auf der linken Gehäuseseite befestigen
  8. 3-Pin-Stecker auf dem Mainboard befestigen (der hinterste Pin für PWM bleibt unbelegt) - dank des Entfernens der Feder passt der Stecker :)
  9. Kabellage noch einmal prüfen und dann Lüftungskabel mit Kabelbindern an den drei originalen Stellen wieder befestigen
  10. Kopfplatte anbringen und mit Schraube an der Rückseite befestigen
  11. 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.