Category Archives: Bugs

WordPress IO-Error beim Upload neuer Medien über SSL mit selbstsigniertem Zertifikat

Posted on by

Verwendet der Webserver ein SSL-zertifikat, das nicht von einer bekannten CA ausgetsellt wurde, kommt es im Flash Uploader zu Problemen. Dieser meldet nur noch IO Error beim Versuch, neue Dateien hochzuladen. Das Plugin “NO SSL Flash Upload” behebt genau dieses Problem. Allerdings werden dann Uploads nicht mehr mit SSL geschützt. Da die meisten inhalte ja sowieso im Blog für alle Welt sichtbar sind, ist das auch ehr unkritisch.

Alternativ könnte auch der Browser-Upload verwendet werden.

Das Problem tritt übrigends auch auf, wenn der SSL-host in der Apache Konfiguration für mass-hosting konfiguriert wurde und kein SAN-Zertifikat verwendet wird. Das Zertifikat enthält dann nur den Hostnamen des Servers und nicht der Website.

Fehlerhafte Betrugs-Erkennung bei Frohe Ernte im VZ Netzwerk

Posted on by

Auch mal ganz lustig. Nutzt man das Upgrade für Farmtiere mehrmals hinter einander wird das Konto irgendwann wegen eines Betrugsversuches für 1 Stunde gesperrt. Der Hund z.B. benötigt 70x Zauberstab um das nächste level zu erreichen. Nach ca. 60 klicks wird man vom Server gekickt.… und 1 Minute später (die Zeit scheit auf dem Server schneller zu vergehen)

ROFL.

Stolperstein AppArmor – Sicherheit auf Kosten von Stabilität und Reaktionszeiten

Posted on by

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 ]---

Vierual Server – kein Speicher trotz massig vRAM

Posted on by

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.