Leider vergisst man meist bei Arbeiten “die mal schnell” erledigt werden sollten eine Screen-Sitzung z starten. Interessanterweise brechen auch genau dann immer die SSH Verbindungen ab. Murphy lässt grüßen . Also sollte man nicht lange nachdenken ob man eine screen-Sitzung startet sondern sollte es einfach nur tun . Und das am besten automatisch beim Anmelden über SSH.

Einige schreiben hier immer wieder sehr komplexe Scripte oder starten screen vom SSH Daemon. Ich persönlich finde das alles überflüssig. Eigentlich muss nur geprüft werden ob die Shell über SSH gestartet wurde und ob die aktuelle Shell gerade in einem Screen-Term läuft. Letzteres ist wichtig um keine Schleife zu verursachen.

Für screen selbst sollten noch die Parameter für UTF-8 (auf allen neueren Distributionen Standard) und das automatische Fortsetzen bereits bestehender Sitzungen hinzugefügt werden. Der Parameter x für MultiDisplay/MultiUser Mode ist auch ganz nützlich.

Soll doch mal eine Sitzung ohne screen gestartet werden, sollte dies ebenfalls berücksichtigt werden. Eine interessanterweise sehr einfache Methode (echo / sleep) habe ich neulich auf einer LAN-Party gesehen (Thx Outi) und auch gleich so übernommen.

Aber nun zum Script. Der folgende Code führt hinzugefügt an die bashrc des Benutzers (oder Systems) genau diese Schritte aus.

if [[ -e $SSH_TTY ]] && [[ $TERM != screen ]]; then
        echo Starting or resuming screen session
        echo Press CTRL+C to cancel screen startup
        sleep 2
        screen -UxR;
fi

Nun habe ich nach einiger Recherche im Netz eine Möglichkeit gefunden, Dropbox als Service einzurichten. Das ganze ist im Dropbox-Wiki sehr gut Dokumentiert.

Die dort verwendeten init Script verwenden allerdings Multiuser-Umgebungen. Auf einem Server ist es besser einen getrennten Benutzer anzulegen und Dropbox unter diesem zu starten. Der neue user dropbox mit dem Basedir /data/raid/dropbox soll dazu verwendet werden.Nach dem Anlegen des Benutzers muss der dropboxd einmalig unter diesem Benutzer gestartet und der Account aktiviert werden. Meine Anpassungen am Gentoo Script sehen wie folgt aus:

#!/sbin/runscript
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License, v2 or later
# $Header: /var/cvsroot/gentoo-x86/sys-fs/dropbox/files/dropbox.init-1.0,v 1.4 2007/04/04 13:35:25 cardoe Exp $
NICENESS=5
DROPBOX_USER="dropbox"
DROPBOX_HOME="/data/raid/dropbox"
DROPBOX_BINARY="/opt/dropbox/dropboxd"
DROPBOX_LOG="/var/log/dropbox_log"
DROPBOX_ERR="/var/log/dropbox_err"
depend() {
need localmount net
after bootmisc
}
start() {
ebegin "Starting dropbox..."
touch $DROPBOX_LOG
touch $DROPBOX_ERR
chown $DROPBOX_USER $DROPBOX_LOG $DROPBOX_ERR
start-stop-daemon -1 $DROPBOX_LOG -2 $DROPBOX_ERR -b -S -m --pidfile /var/run/dropbox.pid -o -N $NICENESS -u $DROPBOX_USER -v -e HOME=$DROPBOX_HOME -x $DROPBOX_BINARY
eend $?
}
stop() {
ebegin "Stopping dropbox..."
start-stop-daemon --stop --pidfile /var/run/dropbox.pid
eend $?
}
status() {
if [ -e /var/run/dropbox.pid ] ; then
echo "dropboxd running."
else
echo "dropboxd not running."
fi
eend $?
}

Alles haben diese Befehle gemeinsam, man benötigt root-rechte zum Mounten und Auswerfen der Speicherkarten. Webserver mit root-rechten betreiben? suexec Modul von Apache nutzen? Alles zu riskant und viel zu kompliziert. Der einfachste weg ist es, ein Shellscript mit root-Berechtigungen vom Webserver aus zu starten. Und das geht am besten mit sudo.

Um das Script /usr/local/sbin/webscript.sh unter root rechten zu starten, muss zuerst der Webserver berechtigt werden, das Script unter root Rechten zu starten. Das geht in der Datei /etc/sudoers. Der Eintrag

apache ALL=(ALL) NOPASSWD: /usr/local/sbin/webscript.sh

berechtigt den Benutzer apache von jedem Quellhost ohne zusätzliche Passworteingabe das Script auszuführen. Funktioniert das, sollte der Host auf localhost begrenzt werden.
Anschließend kann das Script aus PHP mittels

system('sudo /usr/local/sbin/webscript.sh');

oder wenn die Ausgabe direkt im Browser ausgegeben werden soll mit

passtruh('sudo /usr/local/sbin/webscript.sh');

ausgeführt werden. erstellt man nun ein Shellscript das eine CF-Karte mountet, je nach Parameter die Dateien kopiert oder verschiebt und startet es per PHP vom webserver, kannd er Kopiervorgang von jedem http fähigen Gerät aufgerufen werden. So ist ein Szenario denkbar, vom Streaming-Radio mit RSS-Reader komplexe Scripte am Webserver auszuführen.

Ich kann nur jedem Empfehlen sich in allen Bereichen der Exam Objectives sehr intensiv vorzubereiten. Teilweise werden in den Fragen selbst Groß/Kleinschreibung bei den Parametern sehr wichtig.

Auch musste ich feststellen, dass Prozesse (speziell Apache) langsamer reagierten (HTTP Response von 52ms auf 320ms). Bei starker Auslastung des Servers kann das schonmal zum Problem werden.

Also, letzter Ausweg, AppArmor deaktivieren. Aber wie geht das? Die Deaktivierung der Prozese audit und apparmor verhindern zwar das Laden der Profile, das ganze Framework startet aber trotzdem. Auch das Kernelmodul kann nicht ohne manuelles neukompilieren entfernt werden, da OpenSuSE apparmor statisch in den Kernel kompiliert hat. Was nun? Bootoptions.

Die Parameter “audit=0″ und “apparmor=0″ verhindern die Initialisierung des Frameworks beim Start. Auch die Latenz des Apache-Servers ist nun wieder eigermaßen normal (100ms).

Für alle die gern Kernelbugs auswerten, hier der Bug der bei aktiviertem AppArmor auf meinem System auftrat:

------------[ cut here ]------------
kernel BUG at /usr/src/packages/BUILD/kernel-default-2.6.34.7/linux-2.6.34/kernel/cred.c:518!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map
CPU 1
Modules linked in: xt_tcpudp xt_pkttype dme1737 hwmon_vid ip6t_REJECT nf_conntrack_ipv6
ip6table_raw xt_NOTRACK ipt_REJECT xt_state iptable_raw iptable_filter
ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_ipv4 nf_conntrack
nf_defrag_ipv4 ip_tables ip6table_filter ip6_tables x_tables xfs exportfs
loop dm_mod container i2c_nforce2 sg forcedeth k8temp serio_raw pcspkr
edac_core edac_mce_amd button raid456 async_raid6_recov async_pq raid6_pq
async_xor xor async_memcpy async_tx raid10 raid0 ata_generic pata_amd sata_nv
libata fan sd_mod raid1 arcmsr scsi_mod edd thermal processor thermal_sys
Pid: 2640, comm: httpd2-prefork Not tainted 2.6.34.7-0.7-default #1 D2461-C1/D2461-C1
RIP: 0010:[] [] commit_creds+0x19b/0x1a0
RSP: 0018:ffff88007b891c48 EFLAGS: 00010287
RAX: 0000000000000001 RBX: ffff88007b88d980 RCX: 0000000000000000
RDX: ffff88007d00ca00 RSI: ffffffff812033e0 RDI: ffff88007c067a80
RBP: ffff88007c067a80 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: ffff88007b89c600
R13: ffffffff81a15320 R14: ffffffff81a151a0 R15: 0000000000000001
FS: 00007fd770aab700(0000) GS:ffff880001f00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd77115d548 CR3: 000000007d308000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process httpd2-prefork (pid: 2640, threadinfo ffff88007b890000, task ffff88007b89c600)
Stack:
ffff88007d00cac0 ffff88007d89a800 ffff88007c067a80 ffffffff81200396
<0> ffff88007d89a800 ffff88007d00cc00 ffffffff81a151a0 ffffffff812060b0
<0> ffff880001e16a08 ffff88007b891da8 ffffffff81776fe0 0000000000000001
Call Trace:
[] aa_replace_current_profiles+0xc6/0x100
[] apparmor_sysctl+0x140/0x150
[] sysctl_perm+0x2d/0xd0
[] proc_sys_permission+0x4c/0xc0
[] exec_permission+0x28/0xa0
[] link_path_walk+0x80/0xab0
[] path_walk+0x5a/0xd0
[] do_path_lookup+0x4b/0x90
[] user_path_at+0x5a/0xb0
[] sys_faccessat+0xd5/0x1e0
[] system_call_fastpath+0x16/0x1b
[<00007fd76fd61497>] 0x7fd76fd61497
Code: 53 30 48 89 c1 48 89 d6 f7 d2 48 c1 e9 20 48 c1 ee 20 85 c2 0f 85 c0 fe ff ff
f7 d6 85 ce 0f 84 da fe ff ff e9 b1 fe ff ff 0f 0b <0f> 0b 0f 1f 00 55 48 89
fd be d0 00 00 00 53 48 83 ec 08 48 8b
RIP [] commit_creds+0x19b/0x1a0
RSP
---[ end trace 817a31ef734f9acb ]---


Bei 1und1 ist dieses Limit 40MB. Betreibt man hier einen Apache2 Webserver mit Prefork MPM benötigt jeder Prozess ca. 800K Kernelspeicher. Dazu noch ca. 500K für MySQL, 2M für alle Postfix-Prozesse und ca. 8MB für die restlichen Dienste eines SuSE 11.3 Systems.

Es bleiben also für Apache Prozesse ca. 30MB, was ca. 40 Prozessen entspricht. Hat man mehrere Webseiten, ein Statistiksystem und mehrere kleinere vHosts eingerichtet, kann dieses Limit sehr schnell erreicht sein. Ein kleines Beispiel:

Eine Website enthält 50 Fotos, 2 Scripte, 4 CSS-Dateien und 4 andere Elemente. Ein Browser lädt Elemente so wie sie im DOM-Baum (HTML-Position) vorkommen, versucht allerdings externe Elemente wie Fotos etc. möglichst paralell zu laden. Das würde auf der oben besagten Website erst 7 nacheinander folgende GET Anfragen und dann 50 fast parallele Anfragen verursachen und somit auch 50 Child-Prozesse.

Also, wer einen vServer bestellt sollte dieses ärgerliche und nicht im Prospekt erwähnte Limit unbedingt beobachten. Ich werde nun wohl wieder vom vServer weggehen müssen, da diese 40MB vorn und hinten nicht ausreichen.

Wo ich nun Hoste? DNS wie immer bei Inter Networx und den vServer bei 1und1. Zugegeben, hier ist auch nicht alles ohne Fehler, so kann das SuSE 11.3 Template komischerweise keinen Hostnamen ändern, CentOS mit Plesk komischerweise schon. Die Installation eines aaa_base Updates verabschiedet den vServer ins nichts und diverse Scripte in /etc/init.d/rc[xx] sind definitiv NICHT LSB-Konform was zu diversen Fehlermeldungen führt. Mehr dazu wenn ich den Server besser kennengelernt habe.

Zur Ausstattung:

Die ersten beiden SATA-II Anschlüsse werden über den Standard 82801GR/GH (ICH7 Family) SATA AHCI Controller bereitgestellt.  Der onboard “Realtek RTL8111/8168B” Gigabit Ethernet Chip ist intern genau wie der von Gigabyte “Gigabyte SATA-II Controller” getaufte “JMicron 20360/20363 Serial ATA Controller” über PCI Express angebungen. Leider wird der am 82801G (ICH7 Family) High Definition Audio Controller angebundene Realtek ALC887 noch nicht von ALSA unterstützt. Alsactl meldet “Unknown hardware: “HDA-Intel” “Realtek ALC887″ “HDA:10ec0887,1458a002,00100302″ “0×1458″ “0xa002″. Anwender, die dieses Board als Multimedia-System einsetzten wollen, sollten dies beachten. Leider kann im BIOS nicht sehr viel Speicher für den “Intel Pineview” Grafikchip” zugewiesen werden, was wieder gegen Multimedia-Einsatz spricht. Für Erweiterungskarten steht ein normaler PCI-Slot zur Verfügung.

Hardware-Monitoring

Das Board verfügt noch über einen it8720-isa-0290 Hardware-Monitoring Chip und den üblichen coretemp-Sensor bei Intel-Prozessoren. Beide werden vom LM-Sensors-Projekt unterstützt und auch richtig erkannt. Es können die üblichen Spannungen, Coretemp und Lüfterdrehzahl problemlos abgefragt und überwacht werden.

Leistung

Die beiden Kerne und die HT Unterstützung machen sich unter Linux bemerkbar. Im Vergleich zu meinem EPIA C7 1Ghz System ist der Atom um das 5-10 Fache schneller. Leider fehlt ihm eine Hardware-AES Engine zur Festplattenverschlüsselung, was den kleinen Prozessor beim Verschlüsseln von Software-Raids an seine Grenzen bringt. In den beiden DDR3 Speicherbänken können maximal 4GB PC3-800 Speicher installiert werden. Für einen Heimserver mehr als ausreichend.

Fazit

Das Mainboard ist in Preis/Leistung fast nicht mehr zu überbieten. Das fast perfekte Mainboard für einen Heimserver. In Verbindung mit einem IDE-Flash Modul für das Betriebssystem stehen 4 SATA-Ports zur Verfügung. Zusammen mit dem Chenbro ES34069 ergibt das einen sehr stromsparenden Heimserver.

Weitere Informationen zum Mainboard bei Gigabyte

Die meisten Greylisting-Dienste warten allerdings nicht ewig auf die erneute Zustellung einer Nachricht. Verwirft der Greylisting-Dienst nun die Nachricht aus der Datenbank bevor der Mailserver des Absenders einen erneuten Versuch startet, wird die Nachricht niemals ankommen. Das kann relativ schnell passieren, wenn es beim Absender tatsächlich Probleme gab die Nachricht zuzustellen. Dann verdoppelt sich nämlich das resend Intervall nach jedem Fehlversuch.

Nimmt man nun als Beispiel Postfix, versucht der Mailserver des Absenders nach einem Fehlversuch nach 5 Minuten die Nachricht erneut zu zusenden. Scheitert das erneut, verdoppelt sich die Wartezeit bis zum nächstem Versuch. Nehmen wir an, der Server des Empfängers hat eine Greylist-Time von 5 Minuten. Der Server des Absenders addiert zum Nachrichtenzeitstempel bei ersten Versuch die konfigurierte minimal_backoff_time. Sind das ebenfalls 5 Minuten, versucht es das System nach Eingangszeit+5Minuten erneut. Das sind allerdings niemals 5 Minuten ab Greylist-Startzeit, da die Nachricht je nach Last einige Sekunden auf dem Mailserver des Absenders verbleibt. Also scheitert auch der zweite Versuch in 50% der Fälle, da sich die Zähler um einige Sekunden unterscheiden.

Für einen dritten Versuch wartet der Mailserver des Absenders nun die doppelte Zeit, also 10 Minuten. Die minimale Verzögerung neuer Nachrichten sind bei Postgrey in der Standardkonfiguration also 15 Minuten. Einige ganz schlaue Admins setzen allerdings ihre Greylist-Time auf 30 Minuten. Der Server des Absenders wartet für den 3. Versuch 20 Minuten. 5 + 10 + 20 = 35Minuten. Wenn es ungünstig läuft und die Nachricht vorher mehr als 5 Minuten in der Warteschlange lag, braucht der Server einen weiteren Versuch. 5 + 10 + 20 + 30 = 1h. Nun habe ich es erlebt, dass einige Server die Nachricht maximal 1 Stunde in der Greylist-Datenbank halten. Wie soll hier im ungünstigstem Fall jemals eine Nachricht ankommen?

Dazu kommt, die Spammer haben inzwischen dazu gelernt. Da in der Fehlermeldung meistens “Greylisted for xx Minutes” erscheint, werten die Spam-Scripte einfach diese Zeit aus und versuchen es anschließend erneut.

Die oben beschriebenen Szenarios sind real und kommen in der Praxis tatsächlich so vor. Selten, aber es passiert. Dazu kommt auch noch, einige Admins die scheinbar die RFC nicht gelesen haben, verwerfen alle Mails die vom Zielserver mit einer temporären Fehlermeldung abgewiesen werden. Manchmal liegt das auch an schlecht umgesetzten SMTP-Diensten die alle nicht zustellbaren Nachrichten gleich behandeln. Solche Systeme werden nicht in der Lage sein, an Server mit Greylist-Daemon Nachrichten zu senden. Ein Beispiel ist mail.ru.

Auch ist die absichtliche Verzögerung nicht in der RFC vorgesehen. Es gibt bessere und Sinnvollere Möglichkeiten Mailserver zu schützen. Greylisting war eine Zeit lang als Notlösung gut, inzwischen aber unbrauchbar und sollte abgeschaltet werden.