Svens blog

Im Wiki des Fedora-Projects kann man sich schnell einen Überblick über die kommenden Features von Fedora 17 (Codename "Beefy Miracle", WTF?) verschaffen. Mal ein kleine Auswahl an den Dingen, die mir aufgefallen sind:

firewalld wird bei Fedora eingeführt und iptables wird im Auflieferungszustand nicht mehr verwendet. Für eine "richtige" Firewall finde ich die hiermit eingeführten Komplexität zu hoch, für Endsysteme könnte die Rechnung aber aufgehen, weil ich hier durchaus dienst-basiert und Dienste je nach Kontext automatisiert freischalten will.

Gnome 3.4 ist gerade vor ein paar Tagen rausgekommen und wird dann auch im nächsten Release auftauchen. Ich bin Gnome-3-Fanboy und freue mich Mehr zum aktuellen Gnome-Release findet man im Artikel zu Gnome 3.4 von heise open.

KVM Live Block Migration wird es ermöglichen, virtuelle Maschinen im laufenden Betrieb zu migrieren.

network-zones bieten eine dynamische Steuerung der Firewall (siehe oben). Momentan sieht es so aus, als müsse man das aktuell verbundene Netz noch von Hand klassifizieren. Eine z.B. auf der MAC-Adresse des Routers basierende, automatisierte Auswahl des Profiles scheint noch nicht geplant zu sein.

Open vSwitch ist jetzt ja im aktuellen Linux-Kernel "drin". Ein virtualisierter Switch, mit dem man lokal verschiedene LAN-Segmente bauen kann. Sehr leistungsfähig, mehr dazu unter http://openvswitch.org/features/ .

Die größte Änderung wird jedoch "Move all to /usr" sein. Direktes Zitat:

Provide a simple way of mounting almost the entire installed operating system read-only, atomically snapshot it, or share it between multiple hosts to save maintenance and space. Instead of spreading RPM package content all over the place in the filesystem, and artificially separate /bin from /usr/bin and /lib from /usr/lib, move all content to /usr and provide only symlinks in the root filesystem.

Das Argument mit den Snapshots finde ich einleuchtend, in Verbindung mit den writable snapshots und mehreren, alternativen Root-Directories von btrfs könnte das Sinn machen. Generell ist das selbst für das experimentierfreudige Fedora-Team eine größere Änderung und erfordert zumindest aktuell manuelle Schritte vor dem Systemupgrade, weil z.B. neue Fedora-RPMs prüfen werden, ob tatsächlich alle Dateien unter /usr liegen.

Fedora 16 hat bei mir Ubuntu komplett abgelöst. Fedora 17 sieht sehr vielversprechend aus und sollte gemäß aktueller Planung Mitte/Ende Mai verfügbar sein.

Irgendwo Ende 2008 ist der Linux-Support bei Amazon hängengeblieben:



Nicht dass es schon blöd ist, dass man bei Amazon einen MP3-Downloader nutzen soll. Aber die dort aufgeführten Distributionen sind alle Ende 2008 erschienen.

Amazon: Das geht besser. Am besten ohne erzwungenen MP3-Download-Client.

Nachdem Gnome 3 herausgekommen war und ich mir die sehr gut gemachte Info auf Gnome.org zu Gnome 3 angeschaut hatte, war ich mir sehr sicher, dass Gnome 3 das Richtige für mich ist.

Leider hat Ubuntu sich für einen anderen Weg namens "Unity" entschieden. Die Diskussionen um Gnome 3, Unity und KDE 4 nehmen immer wieder nahezu fanatisch-religiöse Züge an. Letzlich geht es bei diesen Diskussionen häufig um "Geschmack" und "Meinung", also Bereiche, in denen man sich trefflich streiten aber selten auf einen gemeinsamen Nenner kommen kann. Ich werde hier nicht versuchen, irgendwas zu begründen, da ich es nicht kann. Mir gefällt Gnome 3. Fertig

Damals waren wirklich gut funktionierende Pakete für Gnome 3 auf Ubuntu nicht zu bekommen. Irgendwas hakte immer oder sah einfach nicht gut aus. Um Gnome 3 auszuprobieren hatte ich mich dann auf dem Netbook für Fedora entschieden, weil hier zu Beginn die Integration wirklich gelungen schien.

Und an diesem Wochenende habe ich dann auch meinen "Haupt-PC" (den ich dank SmartPhone und Tablet immer seltener nutze) auf Fedora 16 umgestellt. Dieser Beitrag beschreibt, wie ich Fedora verwende, d.h. welche Software ich zur Standardinstallation hinzufüge und woher diese kommt.
"Fedora: Meine Konfiguration" vollständig lesen

Dieses Wochenende kompiliere ich seit längerer Zeit mal wieder selbst (neue Firmware für Freifunk Kiel).

Dabei fällt mir auf, wie wenig Rechenleistung ich im "Normalbetrieb" brauche. Ein Großteil erledige ich mit dem Android Handy, ab und an arbeite ich mit dem Netbook. Die "richtigen" Rechner im Arbeitszimmer nutze ich eigentlich so gut wie überhaupt nicht.

Nun gibt es hier im Haushalt durchaus leistungsfähige Rechner, die gerade bei rechenintensiven Sachen die Arbeit stark beschleunigen würden. Wenn diese Rechner bei Bedarf alternativ übers Netz booten und dann zu einem eigenen Grid / einer eigenen Cloud "zusammengeschaltet" werden würden? Das wär doch was, oder?

Fürs erste wäre es einfach ein distcc-Cluster. Damit würde ich dann die Compile-Läufe für OpenWRT und die ein oder andere selbst paketierte Software beschleunigen. Der Kinder-PC, der Arbeitszimmer-PC und evtl. noch ein wenig "Keller-Hardware" würden kurzzeitig über PXE in ein $UNIX booten, distcc starten und beim Kompilieren helfen.

Wenn man diese Idee dann weiterdenkt, könnte man auch MP3-Encoding oder das Recoding von DVB-T-Aufnahmen verteilen. Gibt es hierfür verteilte Encoder? Muss ich mal nachrecherchieren.....

Und dann könnte man einfach mal gegenrechnen, was es kostet, für solche Fälle Amazons EC2 zu nutzen. Für wenige Minuten viele Rechnerknoten zu haben, sollte nicht allzu teuer werden.

Also: Führen SmartPhones und Tablets im Homebereich zu einer Renaissance des "Grid"-Gedankens, diesmal aber auch für ambitionierte IT-Heimwerker?

Die Idee: eine "Internet-Kooperative"

Ich habe das Konzept schon länger im Kopf und z.B. mit Steffen diskutiert. Auf dem Webmontag Kiel habe ich es dann mal kurz vorgestellt und bin aufgrund der Rückmeldungen zuversichtlich, dass wir sowas bauen können. Meine Vortragsfolien gibt es hier zum Download

Worum soll es gehen?

Gleichgesinnte, die sich persönlich kennen, schließen sich zusammen und bündeln ihre bisher in eigener Hoheit betriebenen Dienste und Server. Anstelle eines Parallel-Betriebs derselben Software auf vielen Systemen organisieren wir einen gemeinsamen, kooperativen Betrieb auf eigener Infrastruktur.

Jeder nimmt sich eines oder mehrerer Pakete/Dienste/Betriebssystemfunktionen an und ist hierfür der "Kümmerer". Es gibt also einen Ansprechpartner für unsere Wiki-Software, einen Kümmerer für die Maildienste, jemanden für unsere Groupware, eine Administratorin für unseren Jabber-Server usw.

Die Koordination erfolgt durch "offensives Dokumentieren" in einem Wiki und eine nachvollziehbare Dokumentation der administrativen Tätigkeiten in einem Ticketsystem. Wir dokumentieren unser Setup öffentlich. Damit ist die Konfiguration der Dienste unserer "Internet-Kooperative" für alle nachvollziehbar und gleichzeitig eine Grundlage für andere Interessierte, die uns nacheifern wollen oder einfach nur vor denselben Problemen wie wir auch stehen. Wir bauen für alle Teilnehmer eine zentrale Anlaufstelle, an die man sich wendet. Die Zuteilung zu den jeweiligen "Kümmmerern" und die Dokumentation der Bearbeitung erfolgt ebenfalls öffentlich in einem Ticketsystem.

Ich stelle die bisherigen Investitionen in meinen Server und meine Domains der "Internet-Kooperative" zur Verfügung. Aktuell sind das um und bei 30EUR. Weniger wäre gut, (ein wenig) mehr ginge auch

Wir mieten einen oder mehrere selbstverwaltete Server an und beginnen mit dem Aufbau und der Installation der von uns gewünschten Dienste.

Alle Dienste werden zumindest unter der Domain unserer "Internet-Kooperative" angeboten. So kann man selbst ohne eigene Domain diese Dienste nutzen. Sei es die Nutzung unseres Etherpads für ein eigenes Projekte oder aber die Nutzung unseres eigenen dezentralen sozialen Netzwerks. Zusätzlich hat jeder die Möglichkeit, alle Dienste unter einer eigenen Domain zu nutzen. Registrieren müsst ihr die Domain selbst, wir helfen dabei natürlich.

Vetrauen ist gut, Kontrolle ist besser. Die Administration unserer kooperativ genutzten Systeme muss besonderen Transparenzanforderungen genügen. Insbesondere die Administration der Bereiche, die private Daten unserer Mitglieder oder Daten enthält, die beispielsweise durch das Telekommunikationsgesetz besonders geschützt sind, muss einer verteilten, ebenfalls kooperativen Überwachung unterliegen. Das Betriebssystem und die betreffenden Dienste müssen so konfiguriert werden, dass eine unbeobachtete Administration dieser Bereiche ausgeschlossen ist. Jeder Schritt in diesen kritischen Bereichen muss zu einem nicht veränderbaren Protokoll führen, welches wir öffentlich führen.

Wir müssen vieles planen und entscheiden: Welche Dienste wollen wir anbieten? Welche Regelungen wollen wir treffen? Wie wollen wir heissen? Wie wollen wir uns organisieren? Wer macht mit?

Um die weitere Arbeit und Abstimmung ebenso kooperativ wie die spätere Zusammenarbeit zu gestalten, schlage ich vor, dass wir unser Konzept in einem Etherpad gemeinsam weiterschreiben.

Ich habe da mal was vorbereitet: https://pad.tumelum.de/p/internetkooperative

Aus einem Security-Alert bezgl. Custom-ROMs für Android-basierte Mobiltelefone:

In the Android security model, any application signed with the same platform signer as the system image can request permissions not available to normal applications, including the ability to install or uninstall applications without user intervention.

WTF?

Merker: Mehr über "Sicherheitsmodelle" lesen.

Aus dem "Oracle Database Advanced Security Administrator’s Guide 11g Release 2 (11.2)":

U.S. government regulations prohibit double encryption.
Accordingly, if you configure Oracle Advanced Security to use
SSL encryption and another encryption method concurrently,
then the connection fails.

WTF?

Merker: Unbedingt mal wieder ins amerikanische Crypto-Law reinschauen.

Nach längerem Hin- und Her-Überlegen habe ich entschieden, dass ein neuer Homeserver gebraucht wird. Bis jetzt konnte ich mit kleinen Workarounds recht gut leben, z.B. mit OpenWRT-basierten Routern mit USB-Schnittstelle.

Meine Anforderungen haben sich jedoch in den letzten Monaten leicht verändert und vieles von dem, was ich in der nächsten Zeit machen möchte, benötigt einfach ein wenig mehr Ressourcen.

Zuerst sollte der Homeserver lediglich ein übers Netzwerk erreichbarer Datenspeicher sein. Mir wurde das Sinology DS211j empfohlen (Danke an @klarekante). Nettes Gerät und mit Sicherheit auch gut zu hacken. Ich wollte aber gern etwas, mit dem ich ein "vollwertiges" Unix betreiben konnte.

Nächste Idee: Atom-basierte, selbstgebaute NAS-Systeme. Die aktuellen Atom-Boards gehen so für 90-100 EUR über den Ladentisch. Für ein wenig Geld mehr bekommt man auch Boards, die 4GB-Speicher verkraften und z.B. auch ein Remote-Konsole haben. Aber: Die Atoms sind lahm und wie die jetzigen Erfahrungen aus meinen ersten Tests zeigen, bekomme ich auch mit wenig Handarbeit ein im Ruhebetrieb ähnlich sparsames System hin.

Wofür habe ich mich nun weswegen entschieden?

"Homeserver mit FreeBSD: Neuplanung" vollständig lesen

OK. Ja. Hätte ich mir schon viel früher anschauen sollen und nicht erst, wenn es mal wieder ein Atomkraftwerk zerlegt. Aber wenigstens mache ich es jetzt.

Der gesamte Themenkomplex ist etwas schwer zu durchschauen, deswegen erstmal nur als Sammlung:

Der kerntechnische Ausschuss (Hersteller, Betreiber, Behörden, Gutachter, Gewerkschaften...) erstellt das KTA-Regelwerk. Diese Regelungen werden erstellt, wenn "sich auf Grund von Erfahrungen eine einheitliche Meinung von Fachleuten der Hersteller, Ersteller und Betreiber von Atomanlagen, der Gutachter und der Behörden abzeichnet." Und: "Eine Regel wird nur verabschiedet, wenn 5/6 der Mitglieder dem zustimmen. Keine geschlossen stimmende Fraktion kann somit überstimmt werden." Und: "Die KTA-Regeln entfalten zwar keine rechtliche Bindungswirkung, auf Grund ihres Entstehungsprozesses und Detaillierungsgrades kommt ihnen aber eine weit reichende praktische Wirkung zu." Gemäß Angaben des Umweltministeriums wurden in den letzten Jahren mit Arbeiten begonnen, zum Beispiel die Anforderungen an das Notfallhandbuch zu standardisieren. Klingt jetzt noch nicht so richtig "vertrauensbildend".

Etwas besser sieht es mit den Empfehlungen der Reaktor-Sicherheits-Kommission (RSK) aus. Die Empfehlungen, insbesondere die "RSK-Leitlinien für Druckwasserreaktoren" stellen schon mal konkretere Vorgaben dar. Auf den Webseiten der RSK findet man auch andere technische Empfehlungen. Wohlgemerkt: Empfehlungen.

Das Umweltministerium hat "Sicherheitskriterien für Kernkraftwerke" herausgegeben. Das Dokument sieht lesenswert aus. 292 Seiten, aber das werde ich mir nochmal in Ruhe zur Gemüte führen. Aber: Beim ersten Querlesen verstehe ich bereits jetzt ein wenig mehr. Was gut ist. Was mich wieder beunruhigt: Das BMU hat sich am 4.6.2009 mit den Ländern Baden-Württemberg, Bayern, Hessen, Niedersachsen und Schleswig-Holstein geeinigt, die Sicherheitskriterien für Kernkraftwerke in einem Grünbuchverfahren umzusetzen. In diesem Grünbuchverfahren werden die Sicherheitskriterien in einer Erprobungsphase vom 1.Juli 2009 bis zum 31. Oktober 2010 parallel zu dem bisherigen übergeordneten Regelwerk angewandt. Bei eventuell auftretenden Anwendungsschwierigkeiten der Sicherheitskriterien besteht die Möglichkeit konkrete Änderungsvorschläge für die Sicherheitskriterien einzubringen. (Webseiten des Umweltministeriums)

Aber die "Sicherheitskriterien" sind wohl das Dokument, mit dem man als kritischer Bürger als erstes arbeiten sollte.

Was mir noch immer fehlt ist ein Nachweis, dass die Bundesregierung das Sicherheitsniveau der AKWs und somit auch die sicherheitstechnische Entwicklung steuert. Die "Nachrüstliste" aus dem Jahr 2010 ist wenig vertrauensbildend. Hier erstmal ein Link auf ein Dokument im Blog von Sylvia Kotting-Uhl: Nachrüstliste

Der gestrige Webmontag hat es gezeigt: Die Zeit ist reif, das Kieler Freifunk-Netz auszubauen.

Steffen hat die verschiedenen Grundmotivationen in seinem Blog bereits sehr schön dargestellt: Lassen wir uns nicht einsperren.

Interessierte sollten sich:

• auf der Mailingliste anmelden:
  
• im Wiki mitarbeiten und regelmäßig reinschauen

Ich denke, dass wir uns in 3-4 Wochen mal zu einer Installparty treffen und dann entweder mitgebrachte Router oder die Router aus der kommenden Sammelbestellung ins Kieler Freifunk Netz aufnehmen.

Wer vorher schon starten will: Einfach auf die Mailingliste posten oder mich direkt kontaktieren.

Alles weitere dann ab und an hier im Blog und auf jeden Fall im Kieler Freifunk Wiki.

Meine Präsentation von gestern kann man hier runterladen: sthomsen-freifunk-kiel-neuer-anfang.pdf

Es gibt immer mal wieder Momente, wo man auf eine andere Art der Unterhaltung Wissensvermittlung angewiesen ist: Fahrten mit dem Bus, Vorbereitungen beim Kochen, längere Wege zu Fuß etc. Ich höre dann in letzter Zeit vermehrt Podcasts, um nicht einfach nur stumm und stumpf rumzusitzen oder rumzustehen.

Auf dem Android lohnt es sich für all diejenigen, die bereits den Google Reader als Feedreader nutzen, sich mal "Google Listen" anzuschauen.


"Google Listen" nutzt einfach das eigene Google Reader Konto mit, um die Podcasts dort zu verwalten.

Die Integration in Android ist recht gut gelungen.

"Podcasts unter Android und Podcastempfehlungen" vollständig lesen

Eigentlich wollte ich mir schon seit mehreren Jahren Asterisk mal genauer anschauen. Das, was ich bisher darüber gelesen hatte, klang immer sehr spannend.



Für den Herbst hatte ich mir dann mal vorgenommen, mich in Asterisk einzuarbeiten. Aus professioneller Sicht sind für mich natürlich Aspekte der Datensicherheit interessant. Irgendwann werde ich mal eine Asterisk-basierte Anlage beruflich vor die Finger kriegen. Und da ist es halt deutlich besser, wenn man Erfahrung aus "erster Hand" hat.

Aber: Asterisk macht süchtig. Man erhält eine professionelle Telefonanlage mit Konferenzsystem, Anrufbeantwortern, Dialogsystemen ("Drücken Sie die Taste 1 um einen inkompetenten Aushilfstudenten zu sprechen!"), Halten, Makeln, Parken etc.... Alles, was man braucht, läuft auf Standardhardware mit guter Dokumentation.

Ich habe über die letzten Jahre mehrere Einführungsprojekte von Telefonanlagen begleitet. Hätte ich da schon Asterisk besser gekannt, hätte ich mich deutlicher für diese Lösung ausgesprochen und zumindest einmal garantiert anders entschieden. Nun denn: Die nächste Ausschreibung kommt bestimmt

Man kann sich Asterisk auch komplett mit Softphones aneignen, d.h. reale Telefone braucht man eigentlich nicht. Aber dann macht es keinen Spass. Telefonieren hat immer noch was Haptisches und die Qualitätsanforderungen der Endnutzer sind berechtigterweise hoch: Telefone müssen einfach funktionieren. Das haben sie seit Jahren. Echos, Knistern, krude Bedienerführung kennt man vom PC aber doch nicht vom Telefon.

Ich habe mir auf ebay zwei typische Telefone gekauft und eine kleine SIP/RTP-Infrastruktur im Heimnetz aufgebaut.

"VOIP im Heimnetz" vollständig lesen

Es gibt jetzt einen Podcast für S9Y: http://www.s9ycamp.info/

Die erste Folge hört sich schonmal ganz gut an. Die Audioqualität ist Skype-bedingt leider etwas eingeschränkt. Inhaltlich könnte es aus meiner Sicht gern noch etwas technischer werden, aber: Respekt. Tolle erste Folge.

Sehr lesenswert ist auf jeden Fall die Linksammlung unter http://www.robertlender.info/blog/s9ymanual/start.html.

Und für diejenigen, die es noch nicht mitbekommen haben: Es gibt für s9y ein Sicherheitsupdate, aktuell ist jetzt die Version 1.5.5.

Das HTC Desire war eine gute Wahl. Die Hardware ist wirklich sehr gut. Wertig verarbeitet, nichts klappert oder wackelt. Lediglich die eingebauten Lautsprecher sind äh... also... naja..., man lässt sie einfach besser aus Da war der Blackberry Bold wirklich eine Klasse für sich.

Die beigepackten HTC-Ohrhörer sind wie alle anderen Ohrpropfen irgendwie für meine Ohren nicht gemacht, hier bin ich wieder beim guten alten Koss PortaPro.

Was mir irgendwie wenig gefallen hat: HTC Sense. Das Design ist nett, aber irgendwie habe ich keine der HTC-Applikationen wirklich genutzt und vorgestern wurde der Speicher auf dem Gerät knapp.

Android 2.2 ("Froyo") bietet zwar die Möglichkeit, Anwendungen auf der SD-Card zu installieren. Dies wird aber nur angeboten, wenn die Anwendung dies explizit verlangt.

HTC hat das Desire (un-?) bewusst als offene Plattform gebaut, zumindest ist es jedoch relativ einfach, das ausgelieferte Betriebssystem durch eigene ROM-Images zu verändern.

Ich habe mich nach kurzer Recherche für cyanogenmod (http://www.cyanogenmod.com/) entschieden.

"HTC Desire mit cyanogenmod und sonstige Android-Dinge" vollständig lesen

Endlich ist es möglich, auf Amazons EC2 nicht nur Linux oder Windows (ja, und ehemals auch OpenSolaris) laufen zu lassen, sondern auch FreeBSD.

Links dazu:

• http://forums.freebsd.org/showthread.php?t=20173
  
• http://www.daemonology.net/freebsd-on-ec2/
  
• http://www.daemonology.net/blog/2010-12-13-FreeBSD-on-EC2.html
  

Ich habs mal mit einer t1.micro-Instanz ausprobiert und werde darauf mal ein wenig mit Zabbix und OTRS testen.



Für den Produktiveinsatz ist das Ganze noch nicht empfohlen

Nach dem Klick gibts ein paar weitere Infos.
"FreeBSD auf Amazon EC2" vollständig lesen