Zwei Monate Fairphone2 – Erfahrungsbericht

Nun habe ich das Fairphone2 seit zwei Monaten im Einsatz und von daher kann ich mal meine persönlichen Erfahrungen kundtun.

Als ich im Januar das Handy in den Händen hielt, war mir schon klar, dass ich mich von liebgewonnenen Funktionen und Programmen unter IOS verabschieden muss. Ich bin ein klarer Verfechter vom IOS Benutzerinterface, auch wenn es unter den letzten IOS Versionen etwas an Übersicht verloren hat. Ein Flameware zwischen IOS und Android will ich hier aber nicht starten, da das Telefon doch eher im Vordergrund stehen soll.
Nach der Montage des Akkus und dem Aufsetzen der Hülle, habe ich gleich bemerkt, dass es schwer werden würde, das FP2 mit nur einer Hand zu bedienen. Abgesehen von seinen Dimensionen, ist vor allem der recht ungünstige Schwerpunkt ein Problem, da dieser recht hoch liegt. Hat man das Telefon im unteren Drittel in der Hand und möchte mit dem Daumen obere Bereiche erreichen, passiert es schnell, dass mir das Gerät fast aus der Hand fällt. Erschwerend kommt hinzu, dass die Hülle für mein Empfinden viel zu glatt ist. Meine ausgewählten IPhone 4s Hüllen hatten auch immer die Eigenschaft, nicht aus der Hand zu rutschen. Das Gleiche galt auch für das Ablegen auf z.B. nicht ebenen Oberflächen, wie einem Rucksack. Das FP2 ist mir dadaruch schon mehrfach entglitten und unsanft auf dem Boden gelandet.
Als nicht sonderlich schöne Lösung habe ich mir Sprühgummi gekauft und die Hülle erst komplett mit vier Schichten „eingummiert“, dann zwei Tage später wieder komplett entfernt, nur um dann beim zweiten Versuch nur partiell die Rückseite zu beschichten. Beim ersten Versuch hat sich das Gummi an den Kanten sehr schnell abgelöst und noch häßlichere Blasen erzeugt. Die partielle Beschichtung hält etwas besser, aber auch nur ein paar Tage. Es sieht jetzt bereits nicht mehr schön aus, allerdings erfüllt es noch seinen Zweck.

Kommen wir zu dem eher technischen Kram: Das nahezu erste war das Testen meiner Bluetooth Kopfhörer und wurde sogleich enttäuscht. Dies markiert auch einen Punkt, an dem man den Entwicklern als Kritik mit auf dem Weg geben kann, ihre Hardware/Software besser zu testen. Das Problem ist nähmlich nicht nur, dass das A2DP irgendwie kaputt ist (hoffentlich nur ein Softwareproblem), was dazu führt, dass sehr viele Bluetoothkopfhörer oder Geräte nur stotterndes Audio rausbringen), über flackernde Bildschirme und nicht mehr ansprechbares UI, während es am Ladegerät hängt.
Schaut man sich mal im Faiphone Forum um, fällt einem der nächste gravierende Punkt auf: das FP2 ist verdammt Reboot freudig. Anfangs war das bei mir eher die Ausnahme, mittlerweile habe ich zwischen zwei bis drei Reboots am Tag. Mal mehr, mal weniger. Eventuell liegt es an der SD Karte, oder den zwei (Congster) SIM Karten.
Worauf ich hinaus will ist, dass ich mir nicht vorstellen kann, dass diese Probleme nicht schon während der Entwicklung aufgetreten sind. Dafür treten sie viel zu gehäuft auf. Ich kenne andere Inhaber, mit exakt den gleichen Problemen. Ich und andere Käufer hätten mit Sicherheit kein Problem gehabt, noch ein oder zwei Monate länger zu warten.

Als Fazit kann man nur sagen: man sollte es sich sehr gut überlegen, ob man all diese Probleme auf sich nehmen möchte. Allein die Tatsache, dass ich die Idee sehr gut finde und die Entwickler blutige Anfänger sind (gemessen an den Erfahrungen der restlichen Handy Hersteller), lässt mich meine Toleranzgrenze sehr sehr dehnbar halten. Jedes andere Gerät wäre schon längst wieder zum Hersteller zurückgegangen, oder schlimmer, in die Schublade zum Siemens S65/Nokia E51.
Ich kann nur sehr hoffen, dass mit dem hoffentlich bald kommenden Software Update ein Großteil der Probleme gelöst werden, andernfalls weiß ich nicht, ob ich mir das über Jahre antun möchte.

Landbrot No. 1

Galerie

Diese Galerie enthält 6 Fotos.

Der Kristian hat mal wieder Essen gepostet, allerdings war es dieses Mal Brot von seiner Frau Carola, bzw. einer Vorstufe davon. Ich glaube von da an habe ich beschlossen, selbst unter die Bäcker zu gehen, mit Unterstützung meiner Frau 🙂 … Weiterlesen

Pebble Time Steel

Da ist nun also, meine Pebble Time Steel, in Schwarz. Mein erstes Kickstarterprojekt. Als langjähriger Apple User hat man ja dieses „unboxing“ immer als Event gesehen und eine Prozession abgehalten. Zugegeben, dass Auspacken der Pebble war dann etwas nüchterner, weil es ja eben kein Apple Produkt ist, sondern einfach nur eine Armbanduhr mit ein paar netten Extras :-)

Pebble Box

Pebble Box


Vom Äußeren kann ich sagen: sehr wertig. Das Kettengliedarmband kann als Alternative zu einem Sportgewicht herhalten, oder um auch einfach mal eine Kugel damit abzufangen. Das Lederarmband wirkt ebenfalls schick, zumindest wenn man es am Handgelenk trägt. So auf dem Tisch liegend … nunja.
Da die Pebble halt nun einmal eine Smartwatch ist, geht ohne eine Ersteinrichtung nichts. Hier ist ein Punkt, bei dem ich als Apple Benutzer sehr viel mehr Komfort gewöhnt bin. Ich habe ewig benötigt die Uhr in Betrieb zu nehmen. Nicht einmal vor Foren (!) habe ich zurückgeschreckt. Bluetooth Pairing klappte zwar augenblicklich über das IPhone4s (IOS8.irgendwas), aber das soll man ja nicht, sondern die App musste das erledigen.
Die App wollte aber partout nichts von der Pebble sehen. Der Grund war so einfach wie idiotisch: die falsche App. Nach einigen Recherchen war ich nicht der Einzige der verwirrt vor dem AppStore stand. Es gibt einmal die orangefarbene App und einmal die schwarze App. Während die eine für das alte Modell (ohne Time im Namen) ist, ist die „Time“ Variante eben für meine zuständig. Hätte ich einfach mal richtig gelesen und nicht ständig das fehlende „Time“ in der Beschreibung übersehen … wäre da eventuell ein schöneres „unboxing“ Gefühl aufgekommen. So aber fing es mit Frust an und der Frage, warum Pebble das nicht sinnvoller gelöst hat.
Falsche Pebble App

Falsche Pebble App


Wie auch immer, mit der richtigen App („Pebble Time“) klappte auch die Kommunikation und die nachfolgende Einrichtung ging zügig von der Hand. Aber auch an dieser Stelle fällt schnell auf, dass auf eine schöne Apple UI nicht der Fokus lag. Die App sieht nicht nur grottenhäßlich aus, sie bedient sich auch nur mäßig. Es ist irgendwie alles verschachtelt und nicht intuitiv. Bei Einstellungen innerhalb der Pebble Apps fehlen triviale Dinge wie „Zurück“ Knöpfe. Man kommt aus den Optionsmenüs heraus, indem an eine freie Stelle getippt wird(!). Schrecklich.
Nunja, wurde die Pebble entsprechend mit Apps und neuen Ziffernblättern befüttert, ist die Uhr selbst wirklich schick. Auch die Bedienung mittels der vier Tasten klappt nach einer kurzen Gewöhnung sehr flink und das Display bleibt sauber.
Ein kleiner Kritikpunkt den auch ich bestätigen kann, ist der durchaus schwache Kontrast, da der Hintergrund relativ dunkel ist. Die Menschen mit älteren E-Books werden das kennen. Allerdings hätte mich das nicht davon abgehalten, diese Uhr zu kaufen, da ich ganz gut damit leben kann. Da ich ohnehin meist schräg (also in einem leichten Winkel) auf das Display schaue, lassen sich die Details sehr gut erkennen.
Pebble
Alles in allem freue ich mich die nächsten Tage und Wochen mit der Uhr rumzuhantieren und zu testen. Eventuell werde ich tatsächlich mal schauen, wie ein Ziffernblatt erstellt wird. Es reizt mich durchaus, da ein wenig kreativ zu werden.

Kolab 3.4 – Debian und der Wunsch nach Flexibilität

Es ist schon ein wenig erschreckend und es wundert mich mittlerweile auch nicht mehr, warum OpenSource Groupware kaum voran kommt.

Ich gebe zu: ich mag meine Apple Cloud. Sie bringt im wesentlichen alles mit, was man so im Alltag wertschätzt. Da wäre die Synchronisation von Kontakten, über Kalendereinträge Musik und Co. Meine Frau und ich teilen uns sogar einen, damit wichtige Themen nicht durchrutschen.
Alles über mehrere Clients (natürlich alles Apple) hinweg. Naja, hier und da klappt es vielleicht mal nicht ganz so schnell, aber im Großen und Ganzen dann doch.
Als Admin bleibt es aber nicht aus, hier und da mal über den Tellerrand zu schauen. Es schadet nichts zu schauen, was sich so neues im Groupware Bereich getan hat. Früher mal Zimbra ausgetestet (viele Kinderkrankheiten), OpenGroupware (tot) und auch das Monster von Owncloud, was ja auch irgendwie in diesen Bereich reinfällt. Letzteres ist zwar sehr zügig eingerichtet, aber da schon die Basiskomponenten damals so kaputt waren, habe ich es nie wieder ausprobiert. Verfolgt man hier und da die Foren und Mails zu OC, scheint sich das auch nicht wirklich geändert zu haben.
Vor kurzem erschien dann Kolab in der Version 3.4. Eigentlich nicht so meine Richtung, da es vor allem auf Cyrus und KDE-Pim setzt, aber als ich gelesen habe, dass man auch Dovecot als IMAP Speicher nutzen kann, wollte ich der Software mal eine Chance geben. … Was für ein Akt.

Nun halte ich es schon seit Jahren so, dass Web- und Maildienste auf getrennten Servern laufen. Das mag ein Spleen von mir sein, aber es ist eben eine Anforderung. So halte ich es privat, wie in der Firma.
Nun war ich der Meinung, dass das ja kein Problem sein dürfte. Kolab setzt im wesentlichen auf einen Webserver, SMTP Server, IMAP, MySQL und noch einen LDAP Dienst. Will man es sich nicht zu schwer machen, wären das Apache2, Postfix, Cyrus, MySQL und ds389. So sehen es die Paketabhängigkeiten vor.
Nun scheint es aber unter Debian so zu sein (ob das unter CentOS und Co auch so ist … keine Ahnung), dass der Paketbetreuer und/oder die Kolab Entwickler scheinbar immer erwarten, alles auf einem Server zu installieren. Irgendwie hat keiner von denen mal darüber nachgedacht bei den Abhängigkeiten zu überlegen, was wirklich sinnvoll ist.

Ein Beispiel:

Es gibt das (wichtige) Tool „setup-kolab“, welches sich im Paket „kolab-conf“ befindet. Das hat folgende Abhängigkeiten:

Depends: pykolab (= 0.7.10-0~kolab1), kolab-ldap, python (>= 2.6.6-7~), python (< 2.8), python-augeas, python-cheetah

Klingt erst einmal nach nicht viel, hangelt man sich aber an den ganzen Paketen entlang, wird man sehr schnell überrascht, was z.B. kolab-ldap nach sich zieht. Das fängt beim ds389 an und hört beim Apachen und Java längst nicht auf.
Warum das Ganze? setup-kolab ist ein Pyhton Script, welches dazu dient die Grundkonfiguration zu erstellen. Also vom Anlegen der passenden Konfigurationsdateien, über das Befüllen der Datenbanken und Initialerzeugung des LDAP Baums. Man kann sogar die Module einzeln aufrufen:

root@kolab:~# setup-kolab help
freebusy                  - Setup Free/Busy.
help                      - Display this help.
imap                      - Setup IMAP.
kolabd                    - Setup the Kolab daemon.
ldap                      - Setup LDAP.
mta                       - Setup MTA.
mysql                     - Setup MySQL.
php                       - Setup PHP.
roundcube                 - Setup Roundcube.
syncroton                 - Setup Syncroton.

Damit hört es dann aber auch schon wieder auf. Die wirklich – aus meiner Sicht – idiotischste Entscheidung ist allerdings die Konsequente Ausblendung von der Konfiguration über TCP. Damit meine ich, dass es defacto nicht möglich ist eine Datenbank über TCP zu konfigurieren. Es wird eine lokale MySQL DB erwartet, deren Socket passend liegt. Das gleiche Spiel gilt auch für den LDAP Server.
Ich kann durchaus nachvollziehen Dienste wie Apache, Postfix, Cyrus lokal konfigurieren zu wollen, aber doch nicht bei MySQL und LDAP?!
Nun könnte ich auf die Idee kommen, einfach „kolab-conf“ auf allen Hosts zu installieren und die Setup je einmal zu durchlaufen um dann die IPs überall zu ändern. Aber Hand auf’s Herz: was für ein Schwachsinn wäre das dann! Ich dürfte dann am Ende überall die überflüssigen Pakete entfernen, oder zumindest die Dienste deaktivieren … viel Spaß bei den Updates.

Wenn man nun also sieht, wie viele Dienste über setup-kolab konfiguriert werden können, wird mir ganz schummrig. Es folgt nämlich das nächste Problem: es gibt keine Anleitung die ohne „setup-kolab“ auskommt, oder zumindest ist mir keine begegnet. Das heißt nämlich, man weiß nicht, wo an welchen Stellen was gedreht werden muss, um die Dienste auf verschiedenen Hosts zu konfigurieren, ohne sich alle Systeme mit überflüssigen Paketen zu versauen.
Aktuell habe ich einen Host auf dem so ziemlich alles (gezwungener Maßen) läuft, außer Webmail …. den ich auf den vorhanden Server laufen haben möchte. Kein Spaß. Ehrlich nicht.

Schaut man sich das Wiki von Kolab und die zig Anleitungen dazu an, gibt es schöne viele generierte Bilder wie die Abhängigkeiten sind, aber dass die so überhaupt nicht trivial Umsetzbar sind … davon redet keiner. Naja, stimmt nicht ganz. Man würde nur zu gern wissen, was die haben alles umschreiben müssen, damit das klappt.
Damit ich nicht gleich in die Fail Kategorie laufe: Ich weiß, man kann einen Kolab Server komplett auf einem Server installieren und dann z.B. via Puppet/Rsync (oder was auch immer) die Konfigurationen gezielt anpassen und verteilen, aber elegant und sinnvoll ist etwas anderes, wenn man auf externe Tools angewiesen ist.

Als Fazit bisher:

Ich bin kurz davor entweder die Lust zu verlieren und die VMs zu löschen, Kolab auf einer VM zu hosten oder in den sauren Apfel zu beißen und alles händisch zu erledigen. Was davon ich tun werde, zeigt sich in den nächsten Tagen.
Eins ist für mich aber jetzt schon fast klar: für die Firma wird es aus meiner Sicht erst einmal keine Option sein, wenn nicht einmal die – aus meiner Perspektive – grundlegendsten Dinge funktionieren. Über das recht komplizierte Multidomain Konstrukt will ich auch nicht reden, obwohl ich es zum Laufen bekommen habe.
Für mich ist die Art und Weise wie Kolab konfiguriert und installiert wird, einfach kaputt. Schlicht und ergreifend.
Schaut man sich auch aktuell auf den Mailinglisten um, plagen gerade die Upgrade willigen (3.3 auf 3.4) riesige Probleme. Riesig im Sinne von täglich um Gigabyte wachsende MySQL Tabellen und durchdrehenden Apache Hosts mit 100% CPU …

Was bleibt ist Resignation und ein fader Beigeschmack, dass sicherlich nicht wenige Steuergelder in diese Software geflossen sind.

Proxmox: ISCSI aus dem System werfen (auch mit Multipath)

ProxMox macht es einem einfach, neue ISCSI Targets ins System aufzunehmen. Ein Klick im Admincenter und schon kann man los legen. Will man das Target allerdings wieder loswerden, wird es schon nicht mehr so trivial. Wurden sämtliche ISCSI Geräte von VMs befreit, sodass die Targets ungenutzt sind, lassen die sich zwar aus dem Webinterface entfernen (Storage …), aber dann sind sie nur aus dem Blick, nicht jedoch aus dem Sinn. Die ISCSI Targets sind nach wie vor verfügbar, was spätestens ein Blick mit „iscsiadm node“ bzw. statt „node“ auch „session“ zeigt. Hat man es nicht nur mit einer einzelnen Node zu tun, sondern hat einen ProxMox Cluster, wird es 1*n mal so hässlich.
Kommt man auf die böse Idee das ISCSI Target auf der ISCSI Serverseite zu entfernen, friert die Node unter Umständen ein, bzw. wirft Haufen Fehler, weil die Geräte nicht mehr verfügbar sind, besonders „multipath“ fängt kräftig an zu jammern.

Hier also mein Notizzettel (ungefiltert) , wie die „Geräte“ sauber aus dem System entfernt werden können – ohne Reboot der Node.

ISCSI Target aus Proxmox entfernen

1. Alle VMs auf anderes Gerät migrieren / local / anderes ISCSI Target
2. Alte LVs in Proxmox löschen (meist unused disk in jeweiliger VM)
3. Prüfen auf Konsole mit lvscan, ob wirklich keine VM mehr die VG verwendet
3. Wenn keine Referenz mehr in Proxmox genutzt, dann in Proxmox Webseite unter Storage
erst VG entfernen, dann ISCSI Target
4. Auf Konsole VG vollständig auf beliebiger Node löschen (vgremove)
5. Gerät aus dem LVM entfernen (pvremove)
6. Name aus Multipath -ll entnehmen:

26f35644f35736a70 dm-5 SCST_BIO,o5dO5sjpPn4ZxszR
size=3.9T features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=0 status=active
|- 13:0:0:0 sdh 8:112 active ready running
|- 15:0:0:0 sdi 8:128 active ready running
|- 16:0:0:0 sdj 8:144 active ready running
`- 17:0:0:0 sdk 8:160 active ready running

"o5dO5sjpPn4ZxszR" ist Name vom ISCSI Target -> verifizieren über den ISCSI Server, ob das
wirklich das zu löschende ist

"26f35644f35736a70" ist der Name des Multipath Gerätes

7. Gerät aus Multipath entfernen -> multipath -f 26f35644f35736a70
7.1 Wenn "map in use" -> dmsetup --tree prüfen
7.2 Dann entfernen: dmsetup remove jbod2--testvg-vm--121--disk--1
7.3 Bei Erfolg, nochmals multipath -f 26f35644f35736a70

8. ISCSI Sessions auflisten: iscsiadm -m session
9. Bei aktiver session, ausloggen: iscsiadm -m node -T jbod-vmdata-02-test --portal 192.168.1.100 --logout
10. Dann passendes Portal löschen: iscsiadm -m node -o delete -T jbod-vmdata-02-test --portal 192.168.1.100
11. Prüfen mittels: iscsiadm -m node | grep jbod-vmdata-02-test ob keins mehr vorhanden ist
12. Gegebenenfalls für alle weiteren Portale wiederholen

Wer es mit mehr als einer Node zu tun hat, sollte zu einem Cluster SSH greifen, um alle Kommandos parallel an allen n-Nodes auszuführen.

Splunk – wie arschig ist das dann!

Ich bin auf der Suche nach einem „hübscheren“ Webinterface für Logdaten, als PHPCon, Alias Loganalyzer (was unter Safari einfach kaputt ist) und wollte mir dann dochmal Splunk anschauen. Da lese ich was passiert, wenn die 60 Tage Testversion aufgelaufen ist und man dann auf die Free Version zurück gestuft wird:

Important: Splunk Free does not include authentication or scheduled searches/alerting. This means that any user accessing your Splunk installation (via Splunk Web or the CLI) will not have to provide credentials. Additionally, scheduled saved searches/alerts will no longer fire.

Da denke ich mir auch nur, wie arschig das ist. Hätte man es nicht bei was anderem belassen können als mal eben die Authentifizierung zu kippen?

Doveadm expunge

Weil ich es mir nicht merken kann:

doveadm expunge -u linuxmail@4lin.net mailbox INBOX/debian savedbefore 1d
Veröffentlicht unter Blubb