world of cryptosteve

Punk, Nerd, Atheist, Skeptiker, Misanthrop, .....

Gentoo Linux mit Verschlüsselung OHNE LVM

Ohne Kommentare

Seit vielen Jahren nutze ich bei Linuxinstallationen auf einer Workstation grundsätzlich eine Festplattenvollverschlüsselung (full disc encryption). Dazu nahm ich in der Vergangenheit eigentlich regelmäßig ein Setup mit LVM und LUKS. Der Logical Volume Manager (lvm) hatte unter anderem folgende zwei Vorteile:

  • Partitionsgrößen konnten nachträglich geändert werden
  • swap lag im LVM und war somit automatisch mit verschlüsselt
Als kleiner Nachteil kam mit dem LVM eine zusätzliche Abstraktionsschicht, die natürlich eine mögliche zusätzliche Fehlerquelle darstellt.

In heutigen Zeiten ist das nachträgliche Verändern der Partitionsgrößen in meinem Setup allerdings nicht mehr so wichtig. Das liegt nicht daran, dass ich überschwänglich viel Platz zur Verfügung habe, sondern - man glaubt es kaum - durch den Einsatz einer SSD eher zu wenig. So habe ich aktuell nur ca. 250GB auf meiner SSD zur Verfügung, sodass eine Aufteilung in mehrere Partionen (wie z.B. /usr, /home, /var, etc.) kaum mehr Sinn macht.

Da ich folglich alles auf einer Partition lasse, braucht es auch kein LVM mehr (Funktionen wie LVM-Snapshots habe ich in der Vergangenheit ohnehin nicht genutzt).

Welche Änderungen ergeben sich auf einem Gentoo-System also?

  • Bei der Installation braucht kein LVM mehr angelegt zu werden. Es kann unmittelbar mit der Einrichtung von LUKS begonnen werden. Ich verwende dazu cryptsetup -c aes-xts-plain64:sha512 -y -s 512 luksFormat /dev/sdaX.
  • Der Parameter "--lvm" ist beim Erstellen der initramfs via genkernel und der Eintrag dolvm in der grub.conf sind nicht mehr notwendig
  • Die Angabe von real_root=/dev/mapper/$cryptdevice in grub.conf ist nicht mehr erforderlich

Nachteil dieser Variante ist, dass swap nicht mehr automatisch im verschlüsselten Bereich liegt, was ein potentielles Sicherheitsrisiko darstellt. Wer aufgrund von Speicherknappheit also nicht gänzlich auf ein swap-Device verzichten möchte, legt es also entweder als swapfile mit im verschlüsselten Bereich an, oder aber er lässt das swap-Device bei jedem Start automatisch mit einem variablen Key verschüsseln.

Dazu reicht folgender Eintrag in /etc/conf.d/dmcrypt:

swap=cryptswap
source='/dev/sda2'
key='/dev/urandom'
options='--allow-discards'

Der Wert für "source" ist hier natürlich anzupassen. Bei mir ist es /dev/sda2 und options='--allow-discards' ist bei mir mit an Board, weil mein swap-Device ebenfalls auf der SSD liegt. Soll es hier auf einer herkömmlichen HDD liegen, ist --allow-discards nicht erforderlich.

In /etc/fstab wird die verschlüsselte swap-Partition dann einfach eingebunden:

/dev/mapper/cryptswap none swap sw 0 0


Vielleicht hilft es ja dem einen oder anderen ...

Geschrieben von cryptosteve | Kommentieren
Translate article to english

25.01.2015 um 17:42:34

Abgelegt in Gentoo, Linux

in eigener Sache: Neue Zertifikate

Mit 2 Kommentaren

Seit einem Jahr läuft dieses Blog (und sämtliche anderen Seiten auf crashmail.de) nun mittlerweile als https-only. Ich nutze dafür StartCom Class1 Zertifikate, die eine Gültigkeit von einem Jahr haben und dann erneuert werden müssen. Über das Für und Wider eines https-only-Blogs möchte ich an dieser Stelle nicht referieren, dazu haben sich andere (wie z.B. Hanno Böck und Diego Elio Pettenò) bereits hinreichend geäußert.

Nur soviel: Gemäß Qualys SSLTest waren bei mir bislang noch schwache Ciphers im Einsatz, die ich nun gestern nach längerem Knobeln erfolgreich entfernen konnte. Im Zuge dessen wollte ich unbedingt auch Forward Secrecy und Strict Transport Security (HSTS)realisieren.

Während die Einrichtung von HSTS auf lighttpd noch recht leicht einzurichten ist, habe ich mir bei Forward Secrecy ziemlich die Zähne ausgebissen. Für HSTS braucht es lediglich folgenden Eintrag in der lighttpd.conf:


setenv.add-response-header = ( "Strict-Transport-Security" => "max-age=63072000; includeSubDomains",
"X-Frame-Options" => "DENY")


Für Forward Secrecy hingegen braucht es nur eine passende cipher-list und die Anweisung an den Webserver, die Reihenfolge der cipher-list auch entsprechend zu beachten. Trotz dutzender verschiedener cipher-lists und diverser Konfigurationsversuche hat es bei mir aber nie zum gewünschten Ergebnis geführt.

Nach längerer Ursachenforschung habe ich dann bemerkt, dass das Ergebnis folgender cipher-Abfrage beim OpenSSL auf der Workstation ein signifikant anderes Ergebnis ergab als auf dem Server:


# openssl ciphers -v 'HIGH:!SSLv2:!ADH:!DHE:!DH:!3DES:!MD5:!aNULL:!eNULL:!NULL:@STRENGTH' | grep -v SSLv3

Was also kann der Grund für diese Diskrepanz zwischen den beiden OpenSSL-Versionen sein? Nun, nachdem ich dann den ganzen Tag rumprobiert und die Websuche bemüht habe, fand ich abends schlußendlich den richtigen Hinweis in folgendem Thread auf gentooforum.de. Ursache für die fehlenden ciphers ist das USE-Flag "bindist", das beim stage3-tarball seit einiger Zeit standardmäßig gesetzt ist. Dazu gibt es einen entsprechenden Bugreport auf bugs.gentoo.org, an den ich mich gleich mal dran gehängt habe.

Ich habe bindist also aus der /etc/portage/make.conf entfernt, meine benötigten Tools neu gebaut und schon waren die entsprechenden ciphers in ausreichender Weise vorhanden. Dadurch komme ich jetzt mit einer recht einfachen cipher-list zum Ziel:


var.cipher-list = "TLSv1+HIGH !SSLv2 !RC4 !aNULL !eNULL !3DES @STRENGTH"

Dadurch müssen zwar die russische Suchmaschine Yandex (vertreten durch den YandexBot v3.0), sowie der IE6/IE8 auf WindowsXP und Java 6u45 draußen bleiben, aber ein Blick in meine Logfiles der letzten Monate verrät mir, dass von der Seite sowieso kein Traffic zu erwarten ist.

Achja, wer sich die cipher-list lieber selber zusammenstellen möchte, den verweise ich noch auf diese Seite von mozilla.org, auf der die korrespondierenden Namen der ciphers vernünftig aufgelistet sind. Durch solche Listen lassen sich die ciphers dann noch Belieben einsetzen.


ssl.cipher-list = "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-
SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-
SHA:DHE-RSA- AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-
SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"


So und bis Juni 2015 habe ich jetzt erstmal Ruhe vor diesem Thema ...

Geschrieben von cryptosteve | Kommentieren
Translate article to english

07.06.2014 um 23:27:40

Abgelegt in Gentoo, in eigener Sache, Linux

Umstieg von Ubuntu 14.04 Trusty Tahr auf Gentoo unstable - ein Erfahrungsbericht

Mit 4 Kommentaren

Dieser Artikel könnte viele Namen tragen ... sie alle würden nichts an der Tatsache ändern, dass meine Reise zu Ubuntu allenfalls ein Wochenendausflug war.

Um es kurz zu machen. Es sind nicht nur Bugs wie das Umgehen des Screensavers oder das Umgehen des Screensavers, sondern auch solche wie Umgehen des Screensavers, dass einem die Arbeit mit Ubuntu verleiden ... nein, es sind auch lauter kleine Detailschwächen wie laufende Crashes im Nautilus und schwarze aus Minimierung wiederhergestellte Fenster. Wenn ich meine Fehlermeldung zu Nautilus in eine Suchmaschine füttere, finde ich übrigens jahrealte Bugs zu Thema.

Wie dem auch sei, sich ist Ubuntu 14.04 LTS gerade brandneu vom Band gerollt und bedarf sicher noch viel Liebe, die es wohl auch bekommen wird. So schmerzfrei, wie ich es gehofft hatte, ist es dann allerdings doch nicht. Da lehne ich mich lieber in die Arme von Gentoo unstable zurück und freue mich über meine gewonnene Zeit.

Geschrieben von cryptosteve | Kommentieren
Translate article to english

06.05.2014 um 20:06:28

Abgelegt in Gentoo, Linux

Umstieg von Gentoo unstable auf Ubuntu 14.04 Trusty Tahr - ein Erfahrungsbericht

Mit 2 Kommentaren

Schon länger trage ich mich mit dem Gedanken, eine meiner Arbeitsmaschinen von Gentoo unstable auf eine andere, konservativere, Distribution umzustellen. Die Wahl fiel dabei letztlich auf Ubuntu, weil es für mich das kleinste Übel ist. rpm-basierte Distributionen fallen für mich von vorn herein raus .... nicht, weil sie schlecht sind, sondern weil ich einfach keine Ahnung davon habe. In der engeren Auswahl war noch Debian stable, was aber aus zweierlei Gründen ebenfalls ausgeschieden ist. Erstens sind wir vom letzten Release Ewigkeiten entfernt und zweitens vom nächsten Release ebenfalls noch Ewigkeiten entfernt. Bei Installation von Debian testing (Jessie) laufe ich hingegen Gefahr, mich in näherer Zukunft mit dem Wechsel auf systemd rumschlagen zu müssen. Nichts, was ich unter Gentoo nicht auch schon bewältigt habe, aber ganz gewiss etwas, womit ich mich erstmal für lange Zeit nicht beschäftigen möchte.

Die Wahl ist also gefallen, und zwar auf Ubuntu 14.04 LTS (Trusty Tahr). Diese Version ist in derzeitigem Zustand noch in der Beta-Phase, das Release ist für den 17. April 2014 geplant. Da der Wechsel auf dieser Maschine aber nicht unbegrenzten Aufschub duldet, bin ich die Installation schon jetzt angegangen. Anstatt der aktuellen beta-Version habe ich mich für den daily build entschieden, eine tagesaktuell gebaute Version des aktuellen Stands. Keine besonders gute Idee, wie ich anlässlich des Bugs 1300072 (LVM installation fails - regression with parted 2.3-17) schnell feststellen durfte. Der Installer kam über die Einrichtung des verschlüsselten LVMs einfach nicht hinweg.

Also habe ich doch auf den beta-Build zurück gegriffen und hier lief die Installation soweit dann auch glatt durch. Nach Abschluß der Installation wurde ich zum Reboot aufgefordert, was ich dann auch tat. Nach dem Neustart begrüßte mich Ubuntu mit der Bitte zur Eingabe des LUKS-Passphrase. Dumm nur, dass ich mit meinem USB-Keyboard hier keinerlei Eingaben machen konnte. Es hat mich dann einzige Zeit gekostet um zu ermitteln, dass für mein Lenovo Thinkpad USB-Keyboard mit TrackPoint ein besonderes Kernelmodul notwendig ist: hid-lenovo-tpkbd. Und damit stellte sich gleich die nächste Frage: wie schiebt man dem Installer dieses Modul zur Laufzeit unter, sodass man sich nicht nachträglich durchs chroot hangeln muss? Denn Durchbooten ging ja ohne LUKS-Passphrase nicht. Ich habe mich dann dafür entschieden, dass Modul während der Installation in /target/etc/initramfs-tools/modules zu platzieren, sodass es beim abschließenden Neubau der initramfs mit integriert wird. Ob das der richtige Weg ist, weiß ich nicht, aber es hat funktioniert. Nach einem Neustart konnte ich die Passphrase dann ordnungsgemäß eingeben und mein Ubuntu bis in den Anmeldemanager durchbooten.

Wem übrigens die Fonts in qt-Anwendungen nicht gefallen, der dürfte dem durch Installation und Nutzung von qt4-qtconfig abhelfen können.

Ein weiterer Punkt, der mich schon bei Testinstallationen immer massiv gestört hat ist die Schrittgröße bei Lautstärkeänderungen. In Ubuntu springt die Lautstärke pro Druck auf die Lauter-Taste einer Multimediatastatur derart massiv an, dass mir die Einstellung viel zu grobschlächtig ist. Ich sitze hier vor einem innig geliebten Teufel Motiv 2, bei dem mir so schnell die Ohren wegfliegen. Da dieses Problem in Ubuntu nicht neu ist, hatte ich bereits vor längerer Zeit eine Lösung via xbindkeys realisiert. In einem der unzähligen launchpad-Bugs fand ich dazu ein Skript, das ich für meine Zwecke adaptiert habe. Nach der Installation von xbindkeys müssen zunächst die Multimediatasten in der ~/.xbindkeysrc definiert werden:

# Increase volume
"sh ~/.scripts/ubuntu_volumeHack.sh up -i 2% -m Master"
m:0x0 + c:123
XF86AudioRaiseVolume

# Decrease volume
"sh ~/.scripts/ubuntu_volumeHack.sh down -i 2% -m Master"
m:0x0 + c:122
XF86AudioLowerVolume

Wer Schwierigkeiten mit dem Muten der Lautstärke hat, kann auf gleichem Weg auch die Mutetaste neu belegen:

"amixer -q set Master toggle"
XF86AudioMute

Wer Einzelheiten zur Konfiguration von xbindkeys haben möchte, der wirft bitte einen Blick ins ubuntuusers.de-Wiki zu xbindkeys.

Bevor man nun aber seine xbindkeys-Konfiguration via xbindkeys -f ~/.xbindkeysrc laden kann, muss zuerst die bisherige Zuordnung der Lautstärketasten aufgehoben werden. Dies geschieht unter SystemeinstellungenTastaturTastenkürzelKlang&Medien - hier jeweils ein Klick auf Leiser und Lauter und die bisherige Tastenkombination mit der Taste Backspace aufheben. Jetzt kann man die Tasten durch Aufruf von xbindkeys -f ~/.xbindkeysrc neu zuweisen.

Und ganz wichtig: das zugehörige Skript plaziert ihr in ~/.scripts/ubuntu_volumeHack.sh - denn irgendwas muss die Umsetzung der Lautstärke und die passende Anzeige der passenden Notification ja auch realisieren. Um die Übersichtlichkeit dieses Beitrags nicht vollends zu sprengen, lege ich das passende Lautstärkeskript im nopaste ab.

(kleiner Zusatzhinweis: in meinen Testinstallationen hatte ich desöfteren das Problem, dass der Ton trotz einer Lautstärkeeinstellung von Null noch leise zu hören war - deshalb habe ich das Skript dahingehend erweitert, dass der den Audiochannel bei Lautstärkeeinstellung Null zusätzlich muted und bei größer Null wieder unmuted)

Wer mit dem Ergebnis der Lautstärkeregelung abschließend zufrieden ist, platziert den xbindkeys-Aufruf in den Startprogrammen (dashStartprogramme).

Soweit fürs erste, schauen wir mal, was sich noch für spannende Aufgaben bieten ....

Geschrieben von cryptosteve | Kommentieren
Translate article to english

02.04.2014 um 21:50:00

Abgelegt in Gentoo, Linux

Style von gtk3-Anwendungen unter KDE4

Mit 2 Kommentaren

Update: Bitte den Kommentar von Paul beachten! Es gibt einen Slot für die gtk3-Version von x11-themes/oxygen-gtk im regulären Portagetree - danke für den Hinweis.

Ich habe mir heute die aktuelle Version von Roger Router (ehemals ffgtk) installiert. Dieser Anrufmonitor kommt als gtk3-Anwendung, während x11-themes/oxygen-gtk bislang per Default nur gtk2-Anwendungen unterstützt. Dementsprechend sieht Roger Router unter KDE4 eher deplatziert aus.



Abhilfe schafft hier z.B. die Aktivierung des poly-c-Overlays. Darin enthalten sind ebuild für
x11-themes/oxygen-gtk3. Nach erfolgreichem Bau steht auch für gtk3-Anwendungen ein
entsprechender Eintrag in Systemeinstellungen → Erscheinungsbild von Anwendungen → GTK
bereit.



Danach passt sich Roger Router genau in den vordefinierten KDE4-Style ein.



Alternativ zu poly-c kann natürlich auch eines der anderen genannten Overlays versucht werden.

Geschrieben von cryptosteve | Kommentieren
Translate article to english

02.02.2014 um 22:31:11

Abgelegt in Gentoo, Linux

in the poche - read-it-later-Service selber hosten

Ohne Kommentare

Bislang habe ich keinen read it later-Service gebraucht. Ich habe meine Artikel entweder sofort gelesen, die Browsersitzung bis dahin offen gelassen oder ein Lesezeichen angelegt. Entsprechende Services, wie z.B. Pocket blieben von mir daher vollständig ungenutzt.

Durch einen Beitrag in Caschys Blog bin ich kürzlich jedoch auf poche aufmerksam geworden. Poche ist bislang sicher nicht so vollumfänglich wie Pocket, ist dafür aber OpenSource, deutlicher übersichtlicher und lässt sich problemlos selber hosten. Zudem bleiben die Daten der read-it-later-Historie damit in eigenem Besitz und nicht bei einem weiteren Webdienst.

Zu poche selbst kann im Beitrag von Caschys Blog (Link siehe oben) einiges lesen. Wer Schwierigkeiten mit der (durchaus einfachen) Installation hat, möchte darüber hinaus ggf. einen Blick in Poche das openSource Read it later werfen.

Bei der Installation hatte ich jedoch merkwürdige Schwierigkeiten, die ich heute zu allem Überfluß in Zusammenarbeit mit dem Entwickler nicht mehr nachvollziehen konnte. Da es aber mindestens mindestens einen weiteren User mit dem gleichen Problem gibt, scheint der Fehler aber tatsächlich irgendwo versteckt zu liegen. Wir bleiben da definitiv am Ball.

Übrigens, seit heute ist Poche offiziell in Calibre integriert.

Geschrieben von cryptosteve | Kommentieren
Translate article to english

26.12.2013 um 23:06:33

Abgelegt in Gentoo, Internet, Linux

[WLAN] Werbefilter für Android ohne root

Mit 4 Kommentaren

Ich mag keine Werbung. Sie nervt mich, sie lenkt mich von eigentlichen Inhalten ab und speziell in Apps schreckt es mich ab, wenn ich durch ein versehentliches Klicken auf Werbung aus der App in den Browser gepushed werde. Daher blockiere ich unerwünschte Werbung, wo es nur geht. Das mag man für unsozial halten - wer mit meiner Nutzung Geld generieren will, soll mir die App halt zum Kauf anbieten. Ich bin ein User, der sich bei der Wahl zwischen werbeverseuchter und kostenpflichtiger Angebote immer für die Kostenpflicht entscheiden wird.

Bei Androiden stellt sich im Vergleich zur Computernutzung leider das Problem, dass sich Werbung hier nicht so einfach blockieren lässt. So habe ich meine ersten Androidgeräte grundsätzlich gleich am ersten Tag gerootet und Werbefilter installiert. Von den Gefahren eines Bricks mal abgesehen, nervt das aber zunehmend. Während sich einige Geräte (wie solche der Nexus-Serie) noch ganz passabel rooten lassen, wird bei anderen schon schwieriger und komplizierter. Zudem nimmt die Anzahl ganz unterschiedlicher Devices in unserem Haushalt massiv zu, sodass ich mir da mittlerweile sechs, sieben verschiedene HOWTOs durchlesen muss, um am Ball zu bleiben.

Kurzum: Es gibt Geräte, bei denen ich gerne auf root-Zugriff verzichten würde - nicht nur, weil's umständlich ist, sondern weil damit oft auch die Möglichkeit zu OTA-Updates verloren geht, oder falsche Apps eher Schaden anrichten können.

Um es für die User, die auf der Suche nach einer simplen One-Click-Lösung hier her gekommen sind, gleich vorweg zu nehmen:

Effektive Werbefilter auf dem Androiden direkt ist ohne root nicht möglich. Es gibt ein paar Lösungen, die aber allesamt ihre Schwächen haben. So habe ich beispielsweise in meinen ersten Versuchen allen Traffic durch einen squid-Proxy geroutet. Allen Traffic? Denkste, denn die erweiterten Einstellungen im WLAN-Setup des Androiden beziehen sich trotzdem nur auf die Webbrowser. So ist man beim Surfen zwar einigermaßen werbefrei, in diversen Apps blinkert es aber trotzdem fröhlich vor sich hin.

Die einzig passable Möglichkeit, um Werbung aus dem Androiden rauszuhalten, ist, die zugrunde liegenden Hosts zu blockieren. Hier kommt als Router eine Fritzbox 7270v2 zum Einsatz. Die /etc/hosts ist dabei leider nicht so ohne weiteres abzuändern. Es gibt zwar Möglichkeiten, auf die Fritzbox schreiben zuzugreifen, aber das ist nicht nur umständlich, sondern auch nicht ganz ungefährlich. Ein Fehler im Setup hindert die Box schnell mal am Hochfahren. Den darauf folgenden Reset der kompletten Box würde ich mir gerne ersparen. Zudem soll die hosts-Datei in der Fritzbox aus der Konfiguration zur Laufzeit generiert werden - Änderungen an der /etc/hosts würden damit bei jedem Neustart überschrieben werden.

Bliebe also lediglich, die Kindersicherung der FritzBox zu bemühen und die dortige Blacklist mit passenden Einträgen zum Werbefilter zu füllen. Von der Idee her ist das nicht schlecht und funktioniert in der Praxis auch ganz gut. Aber die Anzahl der möglichen Einträge in der Blacklist sind doch arg begrenzt, sodass dies als umfassender Filter leider überhaupt nicht zu gebrauchen ist.

Das nachfolgende Setup ist also umfangreicher und benötigt neben einem Router mit freier DNS-Wahl auch einen PC, der zum Zeitpunkt des Internet-Zugriffs läuft. Gegeben sind hier neben der FritzBox 7270v2 als Router ein Heimserver basierend auf Gentoo Linux und net-dns/pdnsd als DNS-Proxy. Sicherlich gehts auch mit anderen Betriebssystemen, anderen Rechnern und anderer Software. Als Rechner würde sich statt einem größeren Heimserver beispielsweise ein Raspberry Pi anbieten.

Die Grundidee meines Setups ist folgende: die Clients wenden sich für die Namenauflösung an die FritzBox, diese nutzt als DNS-Server den lokalen Heimserver und hier antwortet ein pdnsd auf Anfragen, nachdem er bestimmte Anfragen - nämlich solche an Werbeserver - negiert.

Der Einfachheit halber versorgen sich meine Clients durchweg via dhcp. Für die Namenauflösung wenden sie sich also alle an die Adresse der FritzBox. Hier trage ich unter den Heimserver als freien DNS-Server ein:


Werbefilter Android ohne root
Einstellungen zum alternativen DNS-Server in der Fritzbox


Der Heimserver läuft unter Gentoo, die Installation und Konfiguration von pdns ist in diesem Artikel im Gentoo-Forum ausführlich beschrieben. Ich weise an dieser Stelle darauf hin, dass die Server der German Privacy Foundation nicht mehr ordnungsgemäß laufen und man daher in der pdnsd-Konfiguration auf andere DNS-Server ausweichen sollte.

Nachdem pdnsd ordnungsgemäß aufgesetzt wurde, fehlen natürlich noch die Einträge für die Werbefilter. Hierzu kann man sich auf pgl.yoyo.org passende Listen für diverse Programme, unter anderem pdnsd, zusammenstellen lassen. Das fertige Snippet sieht dann so aus.

Nachdem das o.g. Filtersnippet zur pdnsd.conf hinzugefügt wurde, muss die Konfiguration neu geladen werden. Damit sollte der Heimserver die Namenauflösung für die FritzBox übernehmen und die Werbeserver aus der Namenauflösung herausfiltern. Alle angeschlossenen Clients sind damit von den in der pdnsd.conf negierten Servern befreit und ungerootete Androiden zeigen fortan keine Werbung mehr an.

Das ganze gilt natürlich nur, solange man sich im heimischen (W)LAN befindet. Für 3G-Verbindungen von unterwegs oder in fremden Drahtlosnetzwerken ist die Variante mit gerooteten Devices nach wie vor erforderlich.

Geschrieben von cryptosteve | Kommentieren
Translate article to english

18.09.2013 um 21:00:00

Kurztip: fehlende Texturen bei warzone2100 mit neuerem libpng

Ohne Kommentare

Wer bei seinem Spiel games-strategy/warzone2100 im eigentlichen Spielbetrieb nur einen schwarzen Bildschirm mit dem kleinen Controlpanel unten links sieht und darüber hinaus Fehlermeldungen wie:

libpng warning: iCCP: cHRM chunk does not match sRGB
libpng warning: iCCP: known incorrect sRGB profile

bekommt, dem fehlt möglicherweise schlicht und einfach das folgende Paket:

[stell @ sorum:~]% eix libtxc_dxtn
[I] media-libs/libtxc_dxtn
Available versions: 1.0.1^d (~)1.0.1-r1^d {multilib ABI_MIPS="n32 n64 o32" ABI_X86="32 64 x32"}
Installed versions: 1.0.1-r1^d(20:06:50 02.09.2013)(ABI_MIPS="-n32 -n64 -o32" ABI_X86="64 -32 -x32")
Homepage: http://cgit.freedesktop.org/~mareko/libtxc_dxtn/
Description: Helper library for S3TC texture (de)compression

Nach der Installation hatte ich meine Texturen unter warzone2100 zurück ....

Geschrieben von cryptosteve | Kommentieren
Translate article to english

02.09.2013 um 22:19:05

Abgelegt in Gentoo, Linux

Servermigration von Debian auf Gentoo

Mit 2 Kommentaren

Hallo liebe Leute!
Nachdem ich mich beim letzten dist-upgrade auf Debian Wheezy mal wieder ärgern musste, habe ich mich entschlossen, den Server auf Gentoo Linux zu migrieren. Das nachfolgende Chatprotokoll gibt einen kurzen Überblick über die Baustellen, mit denen ich diesesmal nach dem Upgrade zu kämpfen hatte:

cryptosteve: dovecot - kaputt
cryptosteve: postgres - kaputt
cryptosteve: mysql - kaputt
cryptosteve: syslog - komplett rausgeflogen
cryptosteve: localhost in /etc/hosts - in Luft aufgelöst
cryptosteve: mailman - relay access denied

Einige der o.g. Probleme sind sicherlich dem langen Upgradepfad geschuldet (die Maschine wurde fortlaufend seit sarge-Zeiten aktualisiert) und den übrigen liegt vermutlich mein stümperhaftes Verständnis des debian way zugrunde ... unterm Strich bleibt allerdings jedesmal (eigentlich zunehmend häufiger) ein fader Beigeschmack nach einem dist-upgrade - verbunden mit einigem Herzklopfen und Stunden des Suchens, Lesens und Bastelns übrig.

Nun ist Gentoo ja nicht grundsätzlich unproblematischer, aber trotzdem sehe ich zwei gute Gründe, es einfach mal zu versuchen.

Erstens betreibe ich privat mehrere Gentoo-Kisten, allen voran meine Workstation mit ~amd64, aber auch einen Heimserver mit Gentoo stable amd64. Daher habe ich in der Bedienung von Gentoo eigentlich mehr Erfahrung als in der Handhabung eines Debian stable. Zudem ist der Heimserver in weiten Teilen baugleich gestrickt, sodass ich Upgrades erst zu Hause durchspielen kann, bevor sie auf der Produktivmaschine laufen.

Und zweitens maintaine ich nicht derart viele Maschinen, dass ein Rolling Release gänzlich ungeeignet wäre. Nach aktueller Auffassung kämpfe ich lieber mal alle paar Wochen mit einem kleineren Problemchen, als alle zwei Jahre so richtig dicke an allen Fronten.

Glücklicherweise bin ich Langzeitkunde meines Stammhosters, den ich recht schnell von meinem Plan begeistern konnte.

Die Idee: er stellt mir eine leere virtuelle Maschine zur Verfügung, die ich in seinem Beisein (screen-Session) mit Gentoo betanke und er zieht sich dafür ein Image der fertigen Rohinstallation und gibt mir ein paar Wochen Zeit, die Dienste von der alten auf die neue Kiste zu migrieren. Gesagt, getan und die Installation von Gentoo auf dem vServer lief unfassbar unproblematisch.

Die weitergehende Installation hat mittlerweile ebenfalls ganz gut geklappt. Während die Webdienste noch verhältnismäßig einfach zu migrieren waren, musste ich in die Postfix/amavisd-new/clamav/policyd-weight/postgrey- und vor allem mailman-Konfiguration doch schon ein bißchen tiefern einsteigen, da Gentoo hier einiges anders behandelt. Vor allem die Übernahme des Mailman-Archives war mit etwas Lesearbeit verbunden. Nichts jedoch hat mich soviel Zeit gekostet, wie die simple Installation von net-mail/mailgraph. Obwohl alles (vermeintlich) richtig eingerichtet war, wollte Mailgraph partout keine Images anzeigen. Ich habe dann stundenlang gelesen und alle Permissions mehrfach kontrolliert. Wohl alle außer /var/lib/mailgraph, denn darauf hatte mailgraph keinen Zugriff. Naja, irgendwann sieht man den Wald vor lauter Bäumen nicht mehr.

Lange Rede, kurzer Sinn ... diese Kiste läuft jetzt unter Gentoo Linux und wer Fehler findet, darf sie behalten, oder besser noch mir mitteilen.

Viele Grüße an dieser Stelle auch an Den's Blog, den ich zwar um Rat gefragt, dessen Antwort ich aber nicht abwarten konnte/wollte. :-)

Geschrieben von cryptosteve | Kommentieren
Translate article to english

06.07.2013 um 22:48:03

Abgelegt in Gentoo, in eigener Sache, Linux

Gentoo website survey 2012 - results and conclusions

Ohne Kommentare

Schon seit langem gibt es den Wunsch nach einem aktualisierten Gentooforum. Dabei geht es nicht nur um die Software selbst, sondern auch um ein moderneres Design.

Nun ist das Gentooforum nicht gerade ein kleines Forum und die Anzahl der Beiträge ist enorm. Zudem braucht es reichlich Manpower, um so eine Akualisierung durchzuführen. Darüber hinaus dürfte es ein extrem undankbarer Job sein, da nach Änderungen (so gut sie auch sein mögen) immer ein Teil der Leute Kritik äußert, während viele, die mit der Änderung zufrieden sind, dies stillschweigend zur Kenntnis nehmen.

Diesbezüglich hat Alex Legler vor knapp einem Jahr eine kleine Umfrage gestartet, deren geballtes Ergebnis er jetzt in seinem Blog unter dem Titel Gentoo Website Survey 2012: Results and Conclusions veröffentlichte.

Ich möchte den Artikel hier nicht in allen Einzelheiten kommentieren, da er vollumfänglich ist und das meiste hervorragend darstellt.

Ich möchte nur auf einige wenige Punkte eingehen, bzw. diese gesondert herausstellen:

  • viele Probleme rum ums Forum sind bekannt und das Thema wurde nicht aufgegeben. Hier machen sich Leute aktiv Gedanken und arbeiten an einer Umsetzung. Diese muss aber im Vorfeld gut geplant sein, da man sich die Arbeit sonst doppelt macht

    Es gilt: gut Ding will Weile haben

  • die Idee des wöchentlichen/monatlichen Gentoo Newsletter (GWN, GMN) ist noch nicht komplett tot. Wie bei so vielen regelmäßigen Inhalten fehlt es an aktiven Mitstreitern. Wer sich also berufen fühlt, Artikel zu schreiben, Leute zu interviewen oder sonstwie zum Newsletter beitragen kann, ist herzlich dazu aufgerufen. Hier sind die Gentoo-Leute auf die Mithilfe der Community angewiesen

  • packages.gentoo.org - "The site sucks."

    Besser hätte ich es nicht umschreiben können. Zwar gibt es bereits gute Alternativen, aber es hat mich dann doch gefreut zu lesen, dass hierfür ein Student im Rahmen des GSoC (Google Summer of Code) bereitsteht, der an einer verbesserten Version arbeitet.

Meiner Meinung nach ein sehr lesenswerter Artikel, der Freude auf mehr macht.

Daher, Lesebefehl für alle Gentoofreunde: Gentoo Website Survey 2012: Results and Conclusions

Geschrieben von cryptosteve | Kommentieren
Translate article to english

20.06.2013 um 12:50:11

Abgelegt in Gentoo, Linux