Einträge von pegro

Linux unterscheidet zwischen privilegierten (1-1024) und unprivilegierten Ports (>1024). Die Idee dahinter war mal, dass wenn man zu einem Server auf einem privilegiertem Port connected, dass dort mit ziemlicher Sicherheit ein vertrauenswürdiger, vom Systemadministrator eingerichteter Dienst lauscht. Das ist heute aber nicht mehr zwingend der Fall. Jedenfalls hat man beim Betrieb von Webservern immer das Problem, einem möglichst unprivilegierten Prozess Zugriff auf Port 80 oder 443 zu geben. Oft wird das so gelöst, dass der Prozess mit root-Rechten gestartet wird und dann nach Öffnen des Ports freiwillig die Rechte wieder abgibt. Das machen aber nicht alle Webserver so. Eine weitere auch nicht wirklich schöne Lösung ist es, den Webserver auf Port 8080 und 8043 lauschen zu lassen und per Iptables ein Portredirect zu machen. Das klappt solange, bis IPv6 ins Spiel kommt, denn dafür gibt es kein NAT und damit auch kein Portredirect. Auf der Suche nach einer anderen Lösung bin ich auf accessfs [1] gestoßen. Mit diesem Kernelmodul kann man über ein Verzeichnis is /proc die Gruppe und den Eigentümer für einen spezifischen Port zu setzen. Accessfs gibt es unter [1] als Kernelpatch für verschiedene, auch recht aktuelle Kernel. Für den von uns verwendeten Kernel 2.6.21 musste der Patch leicht angepasst werden. [2]

# cd /usr/src/linux # cat accessfs-2.6.21-0.20.patch | patch -p1 # make menuconfig

Danach findet man unter

File Systems ---> Miscellanenous filesystems ---> <*> Accessfs support (Experimental) <*> User permission based IP ports

die passende Einstellung. Durch die Veränderung am Kernel reicht es nicht, einfach nur das Modul zu bauen und zu laden. Danach muss das accessfs noch eingehangen werden:

# mount -t accessfs none /proc/access

oder per /etc/fstab:

proc /proc proc defaults 0 0 none /proc/access accessfs 0 0

Zum Schluss noch ein

chown jboss:jboss /proc/access/net/ip/bind/80

und der Jboss kann unprivilegiert auf Port 80 laufen. Quellen: [1] http://www.olafdietsche.de/linux/accessfs/ [2] http://subversion.fem.tu-ilmenau.de/repository/fem-overlay/trunk/sys-kernel/xen-sources/

Wenn man selbst Ebuilds schreibt oder Ebuilds aus dem Bugtracker verwenden will, muss man die für Portage notwendige Manifest-Datei erstellen. Dazu ein Hinweis:

If you've made a local modification to an ebuild, patch, or added anything else to your local overlay and need to make Portage aware of the changes so the package can be properly merged, do not use the "digest" command. Use "manifest" instead. For example: ebuild foo-1.0.17.ebuild manifest Digests have been dead for a long time. Please don't encourage bad practices.

Digests werden nach und nach aus dem Tree entfernt und durch das Manifest2-Format ersetzt. Quellen: [1] http://blogs.gentoo.org/nightmorph/2008/12/24/december-public-service-announcement

Das Link Layer Discovery Protocol (LLDP) dient zum Austausch von Informationen bezüglich benachbarten Netzwerkgeräten, wie z.B. Switches oder Router und wird daher eher im Netzwerkcore verwendet, um herauszufinden, welches Gerät an welchem Port hängt. Es gibt aber auch Implementierungen für Linux: u.a. OpenLLDP [1] und lldpd [2] Falls man aber grade mal nur das Notebook dabei hat und keinen dieser Dienste installiert hat, reicht ein einfacher tcpdump-Aufruf, um den Switchport, an dem ich hänge herauszufinden. Vorausgesetzt der Switch spricht LLDP.

tcpdump -i eth0 ether proto 0x88cc

Wer weiß, welche Informationen wo stehen, kann auf Anhieb sagen, welcher Port es ist. Wer das nicht kann, verwendet Wireshark [3]. Quellen: [1] http://openlldp.sourceforge.net/ [2] https://trac.luffy.cx/lldpd [3] http://wiki.wireshark.org/LinkLayerDiscoveryProtocol

Ich habe meine Zertifikate von CaCert ausstellen lassen. Da das Rootzertifikat von CaCert bei nur sehr wenigen Browser dabei bzw. aktiviert ist, muss man meist das Root-Zertifikat erst importieren. Der Opera in Version 10 (auch schon in der 9er) hat dann aber das Problem, dass er die verwendete Verschlüsselungsmethode für unsicher hält.

(1) This site is using an outdated encryption method which is no longer classified as secure. It cannot sufficiently protect sensitive data. Do you wish to continue?

Nach ewiger Suche fand sich die Problemerklärung im Forum [1] auf der Operaseite.

Both problems are due to problems caused by CACert.org, the "open source" CA. Their OCSP server is not standards compliant, and refuse to return a valid response when we try to GET it (POST works fine, but Opera now uses GET). They will have to fix their server. The request for their CRL fails because they have specifed a HTTPS URL for that, signed by the same root specifying that CRL, meaning that the CRL is setting up a dependency on itself as we can't fetch the CRL until we have downloaded it, which means it will never happen. As CRLs are digitally signed, and have certain validity periods, using HTTPS for CRL fetching is unnecessary (and sets up a Catch-22 situation). CACert should reissue their root, removing the CRL URL, and also reissue their Class 3 intermediate so that the HTTP CRL URL is located there.

Übersetzt ungefähr so: 2 Probleme:

• Zur OCSP Validation kann man den OCSP Server laut RFC in 2 Varianten fragen: per GET und per POST. Opera verwendet die GET Anfrage, der CaCert OCSP Validator versteht aber nur Anfragen per POST und arbietet damit nicht RFC-konform.
• Als CRL URL steht im Rootzertifikat eine HTTPS URL, deren Zertifikat mit eben demselben Rootzertifikat signiert wurde. Damit besteht eine Abhängigkeit zum eigentlich zu prüfenden Zertifikat.

CaCert muss also beide Probleme lösen, es ist kein Bug im Opera. Leider kann man die Mailinglistenarchive nicht öffentlich einsehen und auch sonst finden sich nur wenige Informationen auf der Seite. Schade, denn ich kenne keine ähnlich günstige Alternative zu den großen Issuern. Quellen: [1] http://my.opera.com/community/forums/topic.dml?id=259490

Wenn man mehrere virtuelle Maschinen für verschiedene Webdienste mit einer IP betreiben will, kommt man nicht umhin einen Proxy zu verwenden. Dafür eignet z.B. mod_proxy mit mod_proxy_http.

ProxyPass /myApp http://internerServer:8080/myApp ProxyPassReverse /myApp http://internerServer:8080/myApp

Dies leitet alle Anfragen an /myApp an den entfernten Host weiter, der nur im internen Netz erreichbar ist, und kümmert sich drum, dass alle Hostnamen in den HTTP-Headern entsprechend geändert werden. Die ausgegebene Webseite wird jedoch nicht verändert, so dass absolute Links möglicherweise auf die falsche Adresse linken. Wenn die hinter dem Proxy laufende Software damit nicht umgehen kann, empfielt sich mod_proxy_html, welches versucht alle absoluten Pfade im HTML zu ersetzen. Wenn die Software die Links jedoch entsprechend der URL generiert, mit der sie aufgerufen wurde, kann man mit der Direktive

ProxyPreserveHost On

den Apache dazu bringen, die Anfrage ohne Änderung des Host:-Headers weiterzuleiten. Lohnt sich vorallem bei der Generierung von RSS-Feeds. Quellen: [1] http://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypreservehost [2] http://www.atlassian.com/software/jira/docs/latest/apacheintegration.html

Mit Subversion Version 1.5 gibt ein neues Feature: Sparse Checkouts Das ist vorallem bei großen Repositories nützlich, wenn man nur an einem kleinen Teil arbeiten möchte und deswegen nicht den ganzen Branch z.B. auschecken will. Ein Szenario ist z.B. die Betreuung mehrerer Branches eines Projekts. z.B. ein Branch STABLE, in den nur wichtige Bugfixes eingepflegt werden und auf der anderen Seite trunk mit der aktuellsten Entwicklerversion.

pegro@grossesp ~/myProject $ find * | grep -v .svn | sort branches branches/BROKEN branches/BROKEN/file1 branches/BROKEN/file10 branches/BROKEN/file2 branches/BROKEN/file3 branches/BROKEN/file4 branches/BROKEN/file5 branches/BROKEN/file6 branches/BROKEN/file7 branches/BROKEN/file8 branches/BROKEN/file9 branches/STABLE branches/STABLE/source.c tags trunk trunk/source.c

Findet man nun einen Bug, der sowohl in der Stable- als auch in der Entwicklerversion auftritt, im Beispiel in der Datei source.c, wäre es ja wünschenswert, ihn mit einem Commit für beide Versionen zu beheben. Dazu müsste man aber von der obersten Ebene an auschecken und so das komplette Repository als Arbeitskopie liegen haben. Das kann bei größeren Projekten zu einem echten Problem werden. Sparse checkouts funktionieren über eine neue Variable --depth, für die es 3 Werte gibt: empty, immediates und infinity. Was das bedeutet, versuche ich mal an Beispielen deutlich zu machen: empty:

pegro@grossesp ~ $ svn co https://subversion/repos/myProject/ myProject --depth empty Checked out revision 1.

enthält somit nur ein .svn-Verzeichnis, keine Ordner und keien Dateien. immediates:

pegro@grossesp ~ $ svn co https://subversion/repos/myProject/ myProject --depth immediates A myProject/trunk A myProject/branches A myProject/tags Checked out revision 1.

checkt nur Dateien und direkte Unterordner aus, jedoch nicht deren Unterordner oder Dateien. infinity: Das ist bei Checkout dasselbe, wie ohne diesen Parameter: Alles landet in der Workingcopy. Diese Tiefenangabe wird persistent für diese Arbeitskopie gespeichert, sodass beim svn update auch nur das notwendigste aktualisiert wird. Jedoch kann man diese Angabe verzeichnisweise überschreiben. Ziel im Beispiel ist also nun, das Repository auszuchecken ohne den Branch BROKEN. Beginnen wir mit den Ordnern auf der obersten Ebene:

pegro@grossesp ~ $ svn co https://subversion/repos/myProject myProject --depth immediates A myProject/trunk A myProject/branches A myProject/tags Checked out revision 1.

Dann folgen noch die immediates vom branches-Ordner:

pegro@grossesp ~ $ svn up myProject/branches/ --set-depth immediates A myProject/branches/BROKEN A myProject/branches/STABLE Updated to revision 1.

Bei initialen Checkout wird die Tiefe mit --depth gesetzt. Für dieses Update muss der Wert mit --set-depth für den Ordner überschrieben werden, damit dessen Unterordner erscheinen. Den trunk und den STABLE-Branch wollen wir hingegen komplett auf der Festplatte:

pegro@grossesp ~ $ svn up myProject/branches/STABLE --set-depth infinity A myProject/branches/STABLE/source.c Updated to revision 1. pegro@grossesp ~ $ svn up myProject/trunk --set-depth infinity A myProject/trunk/source.c Updated to revision 1.

Somit haben wir nun die gewünschte teilweise Arbeitskopie ohne den BROKEN-Branch:

pegro@grossesp ~/myProject $ find * | grep -v .svn | sort branches branches/BROKEN branches/STABLE branches/STABLE/source.c tags trunk trunk/source.c

Nun kann man seine Änderung in beide Zweige mit einem Commit einchecken:

pegro@grossesp ~/myProject $ svn commit --message "fixes bug #1" Sending branches/STABLE/source.c Sending trunk/source.c Transmitting file data .. Committed revision 2.

Quellen: [1] http://svnbook.red-bean.com/nightly/en/svn.advanced.sparsedirs.html [2] http://subversion.tigris.org/svn_1.5_releasenotes.html#sparse-checkouts

Also ich hab ja schon viel gesehen, aber das ist mir noch nicht passiert. Durch einen Bug konnte ein Cronscript nicht sauber durchlaufen und startete deswegen alle 5 Minuten und schrieb mir einige nette Mails. Das Problem war eine nicht geprüfte Variable. Also einfach eine if-Schleife mit

if(empty(calcReturnValue($variable))) { ...

dachte ich sollte das Problem beheben. Denkste.

Fatal error: Can't use function return value in write context in /path/to/script on line irrelevant

Da hab ich nicht schlecht gestaunt. Denn empty kann nur Variablen auf "leer" prüfen:

Note: empty() only checks variables as anything else will result in a parse error. In other words, the following will not work: empty(trim($name)).

Und ja, empfohlen wird

$result = calcReturnValue($variable); if(empty($result)) { ...

Sachen gibts... Quelle: http://www.php.net/manual/en/function.empty.php

Für die Statistiken auf dem Webserver verwende ich den Stone Step Webalizer [1], einer Weiterentwicklung des Webalizer [2]. Als ich mich für ihn entschied, gab es schon mehrere Jahre keine Updates des Originals mehr. Mittlerweile gibt es eine neue Version mit sehr interessanten Features, aber mal abwarten wie schnell die Entwicklung wieder einschläft. Beim Auswerten kann der Webalizer die GeoIP Datenbank benutzen, um den IPs aus den Logfiles Länder zuzuordnen. Theoretisch zumindest. Ich hatte den Webalizer und die unter Debian dafür benötigte libgeoip1 installiert, jedoch stand neben den IPs immer nur:

Unresolved/Unknown

Der Pfad für die GeoIPDB (GeoIPDBPath) war ebenfalls richtig gesetzt. Mhm. In der README [3] fand ich die Ursache für mein Problem:

DNSChildren The number of DNS children processes to run in order to resolve IP addresses to domain names or lookup country codes in the GeoIP database. Use a value of zero ('0') to disable. If disabled, both, DNS and GeoIP lookups will be disabled.

Mit DNSChildren 5 krieg ich jetzt auch Tortendiagramme mit mehr als dem unbekannten Land. Quellen: [1] http://www.stonesteps.ca/projects/webalizer/ [2] http://www.webalizer.com/ [3] http://www.stonesteps.ca/projects/webalizer/README.asp

Mittlerweile sind doch einige drüber gestolpert, dass es mehrere Pakete für PostgreSQL im Portagetree gibt. So gibt es die alten dev-db/libpq und dev-db/postgresql. Beide haben nur ein Slot. Und es gibt dev-db/postgresql-base (als Ersatz für libpq) und dev-db/postgresql-server (als Ersatz für postgresql), diese hingegen mit jeweils einem Slot pro Minorversion. Das hat den großen Vorteil, grade im Vergleich mit MySQL, dass man mehrere PostgreSQL-Versionen parallel betreiben kann. Damit im Portagetree kein Chaos auftritt hat man noch 2 virtuelle Pakete eingeführt: virtual/postgresql-base und virtual/postgresql-server, die dann aus Kompatibiltätsgründen entweder von libpq oder postgresql-base bzw. von postgresql oder postgresql-server abhängen, je nachdem was installiert ist. Alle anderen Ebuilds sollten dann nur noch auf diese beiden verweisen, sodass der Umstieg auf die neuen Pakete in Ruhe abgewägt und dann eventuell durchgeführt werden kann. Die Doku landete in dev-db/postgresql-docs Wie das alles kam und welche Gründe den Ausschlag für die neue Struktur gaben, kann man unter [1] nachlesen. Quellen: [1] http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg28455.html

Hinweis: Betrifft KDE Version 3.5.x Die Schriftarten und -größen sowie das Design für QT-Anwendungen (sicherlich der Großteil, wenn man KDE verwendet) lassen sich bequem im KDE Kontrollcenter verwalten. Dies gilt jedoch nicht für GTK-Programme, wie Firefox, Thunderbird, oder wie in meinem Fall, Eclipse. In Eclipse kann man zwar unter "Window -> Preferences -> General -> Appearance -> Colors and Fonts" die Schriftgröße im Editor anpassen, aber nicht für die Menüs und den anderen Kram drumrum. Bei meiner Auflösung hätte ich die Schriften schon gerne etwas kleiner. Nach ein wenig suchen fand ich andere, wie dieses Problem auch schon hatten: Linux-mit-kde-schriftgroessen-und-optik-in-firefox-gimp-und-eclipse So genügt wirklich ein

emerge gtk-chtheme

dann das Programm starten und Themes und Schriftarten wie gewünscht ändern. Ohne Neustart sieht sogar der Firefox viel schöner aus. Manchmal kann es so einfach sein.

Neben all dem anderen Kram hier, gab es die Tage auch noch eine Speichererweiterung für Javalon. 2 SAS Platten. Die Installation geht recht einfach: Blende rausnehmen und Platten einschieben. Fertig. Danach wurde ein RAID1 auf dem LSI MegaRAID Controller konfiguriert. Dazu verwenden wir das Kommandozeileninterface vom Hersteller: MegaCli von LSI [1]

MegaCli -CfgLdAdd -r1[8:4,8:5] WT RA Direct -a0 MegaCli -LdSetProp -Name sdc -L2 -a0

wobei die zweite optional ist. Eine schöne Befehlsübersicht zu MegaCli gibt es unter [2]. Ein MegaCli-Ebuild unter [3]. Lieder bemerkt der Kernel nicht automatisch, dass es ein neues Device gibt. Es gibt im Internet dazu einige Hinweise wie echo "scsi add-single-device a b c d" > /proc/scsi/scsi, welche aber entweder mit Invalid Argument endeten oder wirkungslos waren. Gefunden hab ich die Lösung in einer IBM Wiki [4]:

echo "- - -" > /sys/class/scsi_host/host0/scan

Danach meldete der Kernel:

sd 0:2:2:0: [sdc] XXXX 512-byte hardware sectors (XXX MB) sd 0:2:2:0: [sdc] Write Protect is off sd 0:2:2:0: [sdc] Mode Sense: 1f 00 10 08 sd 0:2:2:0: [sdc] Write cache: disabled, read cache: disabled, supports DPO and FUA sd 0:2:2:0: [sdc] Attached SCSI disk ...

Quellen: [1] http://www.lsi.com/storage_home/products_home/internal_raid/megaraid_sas/megaraid_sas_8480e/index.html [2] http://tools.rapidsoft.de/perc/perc-cheat-sheet.html [3] https://subversion.fem.tu-ilmenau.de/repository/fem-overlay/trunk/sys-fs/MegaCli/MegaCli-1.01.39.ebuild [4] http://www.ibm.com/developerworks/wikis/display/LinuxP/SCSI+-+Hot+add,+remove,+rescan+of+SCSI+devices

Manchmal nervt mich sowas echt. Im stable Portagetree sind grade e2fsprogs-1.41.2 und e2fsprogs-libs-1.41.2 als stable markiert worden, blockieren aber einige installierte Programme:

pegro ~ # emerge e2fsprogs -1av These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] sys-fs/e2fsprogs-1.41.2 [1.40.9] USE="nls (-static%)" 4,263 kB [ebuild N ] sys-libs/e2fsprogs-libs-1.41.2 USE="nls" 479 kB [blocks B ] sys-libs/ss (is blocking sys-libs/e2fsprogs-libs-1.41.2) [blocks B ] sys-libs/com_err (is blocking sys-libs/e2fsprogs-libs-1.41.2) [blocks B ] <sys-fs/e2fsprogs-1.41 (is blocking sys-libs/e2fsprogs-libs-1.41.2) [blocks B ] sys-libs/e2fsprogs-libs (is blocking sys-libs/ss-1.40.9, sys-libs/com_err-1.40.9) Total: 2 packages (1 upgrade, 1 new, 4 blocks), Size of downloads: 4,741 kB !!! Error: The above package list contains packages which cannot be installed !!! at the same time on the same system. For more information about Blocked Packages, please refer to the following section of the Gentoo Linux x86 Handbook (architecture is irrelevant): http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked

Dazu muss man wissen, das com_err und ss nun in e2fsprogs-libs enthalten sind, daher das Blockieren. Leider kann die aktuelle Portageversion mit solchen Fällen noch nicht umgehen (in kommenden Versionen soll das behoben sein). Theoretisch reicht in solchen Fällen, die betroffenen Pakete von Hand zu deinstallieren. Also versucht man dann ein

emerge -C com_err ss

was jedoch nur ein Teil des Problems löst:

pegro ~ # emerge e2fsprogs -1av These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] sys-fs/e2fsprogs-1.41.2 [1.40.9] USE="nls (-static%)" 4,263 kB [ebuild N ] sys-libs/e2fsprogs-libs-1.41.2 USE="nls" 479 kB [blocks B ] <sys-fs/e2fsprogs-1.41 (is blocking sys-libs/e2fsprogs-libs-1.41.2) Total: 2 packages (1 upgrade, 1 new, 1 block), Size of downloads: 4,741 kB !!! Error: The above package list contains packages which cannot be installed !!! at the same time on the same system. For more information about Blocked Packages, please refer to the following section of the Gentoo Linux x86 Handbook (architecture is irrelevant): http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked

[Update] Bevor man ss und com_err deinstalliert, sollte man ein

emerge -f e2fsprogs

machen, damit die Sourcen geladen werden, denn auf manchen Systemen funktioniert wget nach dem unmerge nicht mehr und so lässt sich auch e2fsprogs nicht mehr so einfach installieren. [/Update] Als hässlicher Workaround funktioniert

emerge -C e2fsprogs && emerge e2fsprogs

was ich aber für normale Gentoo-User echt unzumutbar halte. Ich hoffe, man findet eine bessere Lösung. Unter [1] wird darüber diskutiert. Dort gibt es noch ein paar Hinweise, was man tun muss, falls man noch Ebuilds hat, die direkt von com_err oder ss abhängen. [Update2] Portage in der Version ab 2.1.6.4 ist in der Lage, das Problem zu erkennen und selbstständig zu beheben. Die 2.1.6.4 ist seit dem 29.12.2008 als stable markiert. [/Update2] [1] http://bugs.gentoo.org/show_bug.cgi?id=234907#c7

Niemals ein und denselben Artikel auf 2 Rechnern zum Entwurf geöffnet haben UND Autosave aktiviert lassen.

*ARG* Ich hasse es: nun schreib ich den Artikel zum dritten Mal...

Ein oft gewünschtes, meist ignoriertes Feature für Psi ist OTR, also Off-the-Record Messaging [1]. Mittlerweile hat sich Timo Engel mal daran gemacht, dies für Psi 0.12 zu implementieren [2]. Dazu muss extra eine Pluginschnittstelle in Psi gepatcht werden. Die Patches und das Plugin findet man auf seiner Homepage. Für Gentoo findet man passende Ebuilds im Bugtracker [3]. Da die aktuelle Version 0.4 des Plugins von libotr-0.3.1 abhängt, das mittlerweile im Portagetree enthaltene kopete-4.1.2 mit dem Useflag otr jedoch von libotr-0.3.2, meckerte Portage:

!!! Multiple versions within a single package slot have been !!! pulled into the dependency graph

usw. Mit einem kleinen Patch [4] für das Plugin compiliert das Ganze auch mit libotr-0.3.2 und Portage ist zufrieden. Jedoch finde ich das Plugin in seiner jetzigen Form noch nicht wirklich benutzbar. Zuviele Metanachrichten, die einem die History vollmüllen, Einstellungen mühsam über ein Kontextmenü einstellbar und komisches Verhalten, wenn eine Seite die OTR-Session beendet. Außerdem fehlt die Authenfizierung über ein "shared secret", was ich für unkomplizierter als das Fingerprintverfahren halte. Quellen: [1] http://www.cypherpunks.ca/otr/ [2] http://public.tfh-berlin.de/~s30935/ [3] http://bugs.gentoo.org/show_bug.cgi?id=238596 [4] http://bugs.gentoo.org/attachment.cgi?id=169973

http://thedoor.ch/mainpage/content/view/35/76/