Kategorien
Linux

Sendmail mit SELinux und http

In der Stan­dard­kon­fi­gu­ra­ti­on funk­tio­niert das nicht, da der http-Pro­zess auf das spool-Ver­zeich­nis kei­nen Zugriff hat. Abschal­ten lässt sich das mit fol­gen­dem Befehl:

setsebool -P httpd_can_sendmail 1
Kategorien
Technologie

KSM (Kernel SamePage Merging) in der Praxis

Das Gan­ze klingt zwar nach bösem Voo­doo, funk­tio­niert aber tat­säch­lich: Ker­nel Same­Page Mer­ging. Mög­lich ist das seit Ker­nel 2.6.32 und funk­tio­niert, ver­ein­facht dar­ge­stellt, so, dass der Ker­nel ver­sucht, iden­ti­sche Spei­cher­in­hal­te zu iden­ti­fi­zie­ren und die­se qua­si intern zu ver­lin­ken.

In der Pra­xis set­ze ich das auf einem von mir ver­wal­te­ten Clus­ter mit 14 Kno­ten ein, der mit der auf Vir­tua­li­sie­rung und Clus­te­ring spe­zia­li­sier­ten Linux-Dis­tri­bu­ti­on Prox­mox läuft. Prox­mox ver­eint KVM und con­tai­ner­ba­sier­te Vir­tua­li­sie­rung unter einem Dach, indem auf der einen Sei­te ein ange­pass­ter Linux-Ker­nel für die para­virt-ops-Schnitt­stel­le ein­ge­setzt und auf der ande­ren Sei­te OpenVZ für die con­tai­ner­ba­sier­te Vir­tua­li­sie­rung ver­wen­det wird. Der letz­te Arti­kel hier han­delt von die­sem The­ma. Prox­mox wird direkt auf jedem der Kno­ten instal­liert und danach über eine recht kom­for­ta­ble und moder­ne Web­ober­flä­che admi­nis­triert.

Zurück zum The­ma, KSM. Ich habe einen ent­spre­chen­den Ker­nel auf einem der Kno­ten instal­liert und betrei­be auf die­sem drei KVM-Maschi­nen mit Win­dows Ser­ver 2008 R2. Alle drei Maschi­nen haben 4 GB RAM zuge­wie­sen bekom­men, soll­ten also 12 GB RAM benö­ti­gen. Jetzt kommt der Knack­punkt: jeder die­ser Kno­ten ver­fügt nur über 8 GB phy­si­ka­li­schen Spei­cher. Rein rech­ne­risch klappt das also nicht, der Kno­ten müss­te anfan­gen zu swap­pen. In der gra­fi­schen Über­sicht des Kno­tens zeigt Prox­mox eine RAM-Aus­las­tung von theo­re­ti­schen 10 GB an, tat­säch­lich wer­den aber nur unge­fähr 3,75 GB ver­wen­det, über die Hälf­te des ver­bau­ten RAMs ist also noch frei. Da die Basis aller drei Instal­la­ti­on iden­tisch ist, kann der nun theo­re­tisch drei Mal beleg­te Spei­cher zu einem Bereich zusam­men­ge­fasst und somit zu 2/3 ein­ge­spart wer­den.

Das Ver­fah­ren hat natür­lich nicht nur Vor­tei­le: die auf­wän­di­ge­re Spei­cher­ver­wal­tung kos­tet CPU-Zeit. Wenn aber zu erwar­ten ist, dass die instal­lier­ten VMs haupt­säch­lich viel RAM aber wenig Rechen­leis­tung benö­ti­gen, spielt das eine eher unter­ge­ord­ne­te Rol­le. In mei­nem Fal­le kommt pro Kno­ten ein Intel Core2Quad Q9550 zum Ein­satz. CPU-Leis­tung ist also aus­rei­chend da.

Red­Hat hat es geschafft, auf einer Test­ma­schi­ne mit 16 GB RAM 52 (!) VMs mit Win­dows XP par­al­lel zu betrei­ben, jeder Maschi­ne war 1 GB vir­tu­el­les RAM zuge­ord­net wor­den. Noch mal in Zah­len: theo­re­tisch belegt wor­den wären 52 GB, prak­tisch genutzt aber nur 16 GB.

Kategorien
Linux Uncategorized

Port-Weiterleitung mittels SSH

Ich hat­te soeben das Pro­blem, dass ich gern auf einen Dienst zuge­grif­fen hät­te, der auf einer ent­fern­ten Maschi­ne auf Port 443 läuft. Außer­halb des eige­nen Net­zes, also für IP-Adres­sen, die nicht im glei­chen Netzs­seg­ment lie­gen, wur­de der Zugriff auf Port 443 aber gesperrt. Über eine SSH-Ver­bin­dung am Ter­mi­nal mit Lynx zu arbei­ten fiel auch aus, da der Web­ser­vice mas­si­ven Ein­satz von Java­Script macht und ohne die­ses qua­si nicht benutz­bar ist.

Also muss­te eine Mög­lich­keit her, trotz der Ein­schrän­kung auf die­sen Ser­vice zuzu­grei­fen. Eine loka­le Port­wei­ter­lei­tung mit­tels SSH erbrach­te den gewünsch­ten Effekt. Hier­für wird eine Art Daten­um­lei­tung ein­ge­rich­tet, mit deren Hil­fe man die Anfra­ge- und Ant­wort­pa­ke­te an den jeweils zustän­di­gen Port umlei­tet.

https://gist.github.com/481534

Der Befehl ssh soll­te bekannt sein. Die Opti­on -L bin­det einen loka­len Port an einen Remo­te-Port, wie auch im Bei­spiel zu sehen ist. Über [email protected] mel­det man sich dann mit gül­ti­gen Zugangs­da­ten an der Maschi­ne an, auf der der Ser­vice läuft.

Kon­kret habe ich in mei­nem Fal­le den loka­len Port durch 14500 ersetzt, den Remo­te-Port durch 443. SSH baut die Ver­bin­dung und damit auch den Tun­nel auf, et voi­là, schon kann man über den Brow­ser mit­tels

http(s)://localhost:14500

auf den Web­ser­vice zugrei­fen. Die Ein­schrän­kung im Ziel­netz, dass Port 443 nach außen nicht erreich­bar sein darf ist somit umgan­gen.