Auf dem Gutten Plag Wiki kann die aktuelle Plagiatssuche in der Arbeits des noch Ministers unterstützt werden. Mal sehen wie viel von der Arbeit am Ende auch tatsächlich selbst verfasst wurde.
Bekommt er jetzt eigentlich Post von Abmahnanwälten?
Stolperstein AppArmor – Sicherheit auf Kosten von Stabilität und Reaktionszeiten
Es klingt fast schon zu schön. AppArmor aktivieren, ein paar Profile konfigurieren und schon darf ein Prozess nur noch genau das wofür er geschrieben wurde. AppArmor ist ein Security Framework für Linux, dass (basierend auf Regeln) den Zugriff und die Systemaufrufe eines beliebigen Programms auf das System einschränken kann. Erstellt man beispielweise ein Profil für den Apache Webserver, so kann dieser nur noch auf genau die Dateien zugreifen, die für Webanwendungen benötigt werden. Der Zugriff kann sehr fein konfiguriert werden. /usr/* kann nur lesend, /srv/www/htdocs lesend und schreibend, aber nicht ausführend und /var nur lesend und schreibend freigegeben werden.
Nachdem ich nun mehrere Profile konfiguriert hatte und den Server unter Last testete, hagelte es KernelBugs wie Sand am Meer. Auch das Audit-Subsystem (zugrundeliegendes Kernel-Framework auf dem AppArmor aufsetzt) brachte Fehlermeldungen ohne Ende.
Selbst als ich alle Profile entfernt und nur ein Profil, das dem Dienst vollzugriff auf das System erlauben sollte, aktivierte, traten die Fehler weiterhin auf.
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 ]---
1und1 nutzt QUEMU für Tests ;)
Gerade habe ich bei meinem Server in der GRUB-Konfiguration einen Hinweis auf eine QUEMO-VHD gefunden. 1und1 scheint also quemu zum Testen der Systemabbilder ihrer rootserver zu verwenden?! Warum nicht, nur hätte man den sinnfreien resume-eintrag aus der GRUB-Konfiguration entfernen sollen.
kernel /boot/vmlinuz-2.6.34.7-0.7-default root=/dev/md1 resume=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00002-part1
Naja, immerhin besser als Virtual PC 
Vierual Server – kein Speicher trotz massig vRAM
Also wenn man vorher bie mit vServern dieser Art zu tun hatte ist es schon eine ganz schön dicke Überraschung. “Cannot allocate memory” trotz 3 GB freiem Speicher. Bei einem Webserver bedeutet dieses Verhalten kurz gesagt Schicht im Schacht. Aber woher kommt dieses Verhalten? Nun, nach einiger Recherche bin ich auf ein Limit “kmemsize” des Virtuozzo Containers gestoßen. Dieses Limit begrenzt den nicht auslagerbaren Kernelspeicher pro Container. Dumm nur, jeder Prozess benötigt einige KB bis mehrere MB Kernelspeicher die beim “forken” allokiert werden.
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.
OCZ Vertex 2 Solid State Disk (SSD) verdammt schnell … defekt
Für eine Windows7 Installation habe ich in einem Laptop die alte 5400U 2.5″ HDD durch eine OCZ SSD 80GB ausgetauscht. Soweit sogut, das Gerät hat die SSD erkannt und Windows ließ sich problemlos installieren. Nach 40 Minuten dann noch die Treiber nachgelegt, das BIOS aktualisiert, reboot, Windows-Updates, mehrfache reboots, SW-Installation, Reboot -> Please insert System Disk!. Toll. zuerst dachte ich an ein Lock im BIOS seitens HP, also alte WindowsXP Platte eingebaut und die ältere BIOS-Version zurückgespielt. SSD wieder eingebaut, Meldung im BIOS “No local Harddisk found”. Hm, HDD ausgebaut und eine identische SSD (gleiches Modell, gleiche Bestellung) eingebaut und siehe da, das BIOS hat die Platte erkannt. Also wieder XP booten underst einmal das aktuelle BIOS wieder aufspielen. Danach habe ich versucht die HDD mit einem SATA/USB Adapter zu betreiben, keine Chance. Schaut man die SSD am Adapter gebauer an, leuchtet eine kleine rote LED im inneren. Die funktionierende leuchtet hier grün. Defekt? Unfassbar. Nicht einmal 2 Stunden in Betrieb. Solid State Disks sind wirklich sehr schnell, alles startet sehr flüssig … scheinbar ist die Lebensdauer auch sehr schnell vorüber. Sucht man nun im Internet nach diesem Problem -> “OCZ vertex 2 defekt” = 30000 Treffer. Wie kommen die auf eine MTBF von über eine Millionen Stunden, wenn 25% der SSD´s nach 1 Tag defekt sind? Oder bezieht sich dieser Wert nur auf die, die 48h überleben?
Mal sehen wie lange die 2. hält.
