Skip to: categories | main content

29. Jan: Meine Erfahrungen mit Microsoft 365

Ich arbeite jetzt ja seit fast einem Jahr mit Microsoft 365 (alt: Office 365). Davor durfte ich bei Wikimedia Deutschland mit der G Suite (alt: Google Apps) arbeiten.
 
Ich bin ja durchaus ein Freund von Desktop-Clients, aber die Microsoft-Produkte haben mich das letzte Mal so um 2005 herum beeindruckt. Danach fiel es mir echt schwer, den Mehrwert für Microsoft Office zu erkennen. Es mag Einzelfälle geben, aber auf die stoße ich nicht.
 
Das Refaktorisieren und Reformatieren großer Textdokumente mache ich 1000 Mal lieber in Writer als in Word. Fairerweise gebe ich zu, dass Word die Anzeige benutzter Formatierungen besser gelöst hat. Aber wenn ich sowieso nur mit Formatvorlagen arbeite, brauche ich das auch nicht. Das lohnt sich spätestens dann, wenn ich beschließe, dass bestimmte Textabschnitte doch nicht mit der einen, sondern mit der anderen Schriftart setzen will.
 
Aber das war gar nicht die Auslöserin dieses Beitrags, sondern Outlook. Der Vergleich wird jetzt unfair. Während meiner Arbeit mit der G Suite habe ich lieber mit Thunderbird als mit der Gmail-Web-Anwendung gearbeitet, aber wenn ich etwas in meinen Mails gesucht habe, bin ich doch oft zu Gmail gegangen. Denn wenn Google eine Sache gut kann, dann suchen. Mittlerweile weiß ich auch, dass ich all meine Suchen auch in Thunderbird hätte ordentlich durchführen können (Schnellsuche ist nicht Suche ist nicht erweiterte Suche, und letztere habe ich nicht wahrgenommen, weil mittlere den Eindruck erweckte, das Beste in Sachen Suche bei Thunderbird zu sein). Aber was Outlook hier abliefert, ist einfach nur peinlich.
 
Will ich in Thunderbird alle ungelesenen E-Mails anzeigen lassen, dann klicke ich einfach "ungelesen" in der Schnellsuche an. Und schwupps werden mir in der Nachrichtenliste nur die ungelesenen Nachrichten angezeigt. Bei Outlook vermute ich hinter "Filter" eigentlich eine ähnliche Funktion. Wähle ich dort jedoch "ungelesen" aus, werden mir nicht meine 6 ungelesenen Nachrichten angezeigt, von denen ich die Hälfte sogar noch in der ungefilterten Ansicht sehen kann, sondern: gar keine!
 
Nach einem Neustart von Outlook funktioniert es dann aber doch. Sorry, aber das ist einfach nur Müll.
 
Über die Unterschiede von Microsoft 365 und der G Suite werde ich ein anderes Mal schreiben. So viel vorweg: Der einzige Grund für Microsoft 365 dürften die Office-Lizenzen sein.
 
Und damit mir nicht unterstellt wird, ich würde ja Microsoft nur hassen: Visio ist super. Ich habe noch nichts Vergleichbares finden können. Jedes Mal, wenn ich Diagramm machen will, denke ich wehmütig an meine Arbeit mit Visio zurück. Glücklicherweise sind Diagramme bei mir nicht an der Tagesordnung.
Geschrieben von Masin Al-Dujaili in Technik Kommentare: (0) Trackbacks: (0)

17. Jan: ufw: unnecessary firewall

Ach!, Canonical!
 
Die Leutchen von Big Blue Button haben sich auf Ubuntu als Grundlage ihrer Software entschieden. Das ist ihr gutes Recht, auch wenn ich anders entschieden hätte. Leider machen sie aber auch Gebrauch von Canonicals Eigenentwicklung, der ufw, der uncomplicated firewall. Die ufw ist nicht wirklich eine Firewall, sondern vielmehr ein Frontend für iptables und ip6tables. Und ich hätte es auch nicht Frontend, sondern eher Wrapper genannt, aber die Unterschiede sind wohl eher marginal.
 
Tatsächlich nutzt ufw im Hintergrund ip(6)tables, um ihre Regeln umzusetzen. Dummerweise scheint sich der uncomplicated-Teil des Namens auch nur auf unkomplizierte Umgebungen zu beziehen. Schon Containern Zugriff auf das Internet zu gewähren, erfordert es ein tieferes Verständnis von der ufw zu erlangen. Und wenn die Container untereinander sprechen können sollen, dann scheint es ohne Kenntnis von iptables schon gar nicht mehr zu gehen.
 
iptables sind nicht schön. Sie sind geradezu hässlich. Und ich werde drei Kreuze machen, wenn nftables oder bpfilter iptables ersetzen. Aber noch hässlicher als iptables ist das Zusammenspiel von ufw + iptables. Ich sehe keinen Gewinn für den angehenden Admin, sich mit zwei sehr unterschiedlichen Syntaxen auseinanderzusetzen, wenn sich auch mit einer alles erreichen lässt, zumal dann keine Kenntnis über irgendwelche impliziten Maßnahmen der ufw notwendig sind. ufw hat wirklich nur dort einen Existenzgrund, wo so simple Konstellationen auftreten, dass sie auch mit wenigen iptables-Befehlen umzusetzen wären.
 
Ich bin jedenfalls kurz davor, die ufw zu deaktivieren und komplett auf iptables zu setzen.
Geschrieben von Masin Al-Dujaili in Technik Kommentare: (0) Trackbacks: (0)

16. Jan: Big Blue Button, ufw und container

Since a few weeks, I rented a server for running Big Blue Button. Besides Jitsi Meet, Big Blue Button is one of the most feature rich free software video conferencing solutions.

Also, Big Blue Button is a bolted mess of many components running barely in any other environment than the one the developers intended. Actually, it's barely running. :-)

To be fair, there are a lot of components involved. And there aren't many developers having the necessary insights, so progress is slow. Until a few weeks ago BBB had to be run on Ubuntu 16.04 Xenial, but they now have their install script adapted to Ubuntu 18.04 Bionic. Well, we are in 2021 already and a lot of people expect to be able to install BBB on Ubuntu 20.04 Focal. But as I said, progress is slow.

As there are many components, the team strongly recommends to firewall the server. Everyone does that, doesn't they, mh? Well, they decided to use ufw for that. That wouldn't be a problem if I didn't have the idea to setup some additional containers on the machine to make it a little bit more useful.

When mentioning containers almost everyone thinks of docker containers but there are at least two more technologies available on Linux. The aptly named lxc (Linux Containers) and systemd's approach nspawn. As the whole world uses docker and one of my favourite (ex) colleagues prefers lxc I decided to have some fun with nspawn. But I guess many of the problems I had would also appear with lxc or docker.

Actually, BBB makes use of some docker containers so that might have increased my problems but I'm not sure about that as no solution or workaround needed touching their config. I guess, their presence just made my problems seem more complex than they actually were.

The symptoms I observed were simple: My containers didn't get any IP. They had no network connectivity.

The main culprit of course was ufw. BBB's default firewall rules only allow ssh, http, https and a range of ports needed for WebRTC. ufw blocked all traffic from the containers, including DHCP. So I needed to allow DHCP. I wrote an application profile for that but that's mostly unnecessary as we only need to open TCP ports 67 and 68.

ufw allow 67:68/tcp

And my containers got their IP addresses!

But they still couldn't do anything. Okay, I could ping other IP addresses.

ping 8.8.8.8

Call me spoiled, but I'd expect ICMP to be blocked if default policy is to reject. But hey, I was thankful to see that something works at least. But name resolution didn't work. Allowing port 53 analoguosly didn't help. I could tcpdump my packets not reaching the bridge interface. The solution was to allow forwarding packets to this port:

ufw route allow 53

And now, name resolution worked. I left out the steps inbetween (I changed the default forward policy and reset it afterwards). That means I could ping by providing a hostname. Progress! But I couldn't curl. Not only because I had to install the curl package but also because the only open ports for my containers were … let me count … oh, port 53.

ufw route allow 80,443/tcp

And now I can curl.

Of course, there's room for improvement. I could limit the rules to my container subnet or even to single containers. But this last idea is doomed to fail because of DHCP. So I could still limit the forwarding rules to my subnet. As they are only valid for forwarding and I want to forward only to my containers there doesn't seem to any benefit in adding more complexity.

I guess I got all the search terms into this entry I tried while searching for a solution to my problem without getting any concrete results. Maybe someone in the same situation as me might find this helpful.

Geschrieben von Masin Al-Dujaili in Technik Kommentare: (0) Trackbacks: (0)

11. Jan: Error: Assertion failed for PostgreSQL Cluster

If you ever encounter this error message

Assertion failed for PostgreSQL Cluster cluster-name

or

Assertion failed on job for postgresql@11-cluster-name.service

after creating a cluster of the name "cluster-name" it might be because somewhere the hyphen is considered invalid. Just

pg_dropcluster <version> cluster-name
pg_createcluster <version> clustername

to drop and re-create the cluster without hyphen.

I created this blog entry because I could not find any reference to this specific error with this specific reason. It might be some Debian specific error as PostgreSQLs initdb command is wrapped by pg_createcluster which again isn't mentioned by PostgreSQL. Searching the web shows mostly results in context of Ubuntu and Debian.

Geschrieben von Masin Al-Dujaili in Technik Kommentare: (0) Trackbacks: (0)

29. Okt: Mac-Hardware und Webcamvergleich

Eine Sache, die mir seit einigen Wochen im Kopf herumschwirrt: Apple und Hardware. Und Webcams, gerade die waren der Auslöser.

Apples Hardware wird ja viel gelobt, zehrt aber eher von dem Ruf, den sich Apple in den frühen 10er Jahren erworben hat. Ich habe in den vergangenen Jahren mehrfach schon den Kopf schütteln müssen, wie lausig teilweise die Qualität ist (Tastatur, Netzteil).

Auf der anderen Seite gibt es Komponenten, die herausragend sind, die ich auch einmal erwähnen muss:

  • Das Trackingpad, Touchpad, wie auch immer ihr es nennen wollt. Es reagiert präzise und Klicks werden eigentlich immer akzeptiert. Die Multitouch-Funktionen sind zwar eher eine Softwareangelegenheit, aber sie sind tadellos umgesetzt.
  • Die Lautsprecher. Nicht, dass ich damit eine Party beschallen wollen würde, aber Sprache und Musik kommen klar, ohne zu klirren, ohne deutlich erkennbare Fehler im Frequenzverlauf. Üblicherweise gebe ich nichts auf Lautsprecher in Laptops, weil sie meist einfach Mist sind. Bei dem Macbook Pro 2015, was ich seit Februar nutze, sind sie ihren Aufgaben komplett gewachsen.
  • Das Mikrofon. So oft lese ich von miesen Mikros bei Webcams, dass ich tatsächlich sehr angenehm angetan davon bin, dass das Mikro vom Macbook mehr als nur brauchbar ist.
  • Zu guter Letzt die verbaute Webcam. Ich habe hier ein Sammelsurium an verschiedenen Laptops von Lenovo und Dell sowie auch eine externe Logitech. Alle stinken sie ab gegenüber der Apple-Webcam. Ich dachte, es könne ja nicht so schwer sein, eine gute Webcam nachzukaufen (die Logitech C720 habe ich vor gefühlt 10 Jahren für 30€ gekauft). Pustekuchen. Kleine Kameramodule von sehr brauchbarer Qualität werden zu hunderten Millionen in Smartphones verbaut, aber der Markt für Webcams ist überschwemmt von billigen Chinawebcams und wird dominiert von … Logitech. Besagte C720 ist im Vergleich zur Macbook-Webcams Mist. Bei WMDE haben wir zwei Logitech Meetup in Betrieb genommen, die bei Tageslicht ganz brauchbar sein mögen, aber nur einen digitalen Zoom bieten (für an die 1000€!), wo dann alles recht matschig aussieht. Immerhin 4k, aber so recht hat mich Logitech nicht überzeugt. Aber es gibt kaum andere Anbieter.

Also habe ich mich auf das Abenteuer "unbekannte Hersteller" eingelassen und mir eine "Papalook Webcam HD 1080p" bestellt.

Nach den ersten Tests habe ich sie wieder eingepackt und bei Amazon die Rücksendung beauftragt. Dann stolperte ich über Rezensionen, die der Kamera eigentlich gute Leistung quittierten. Also wieder ausgepackt und an den Parametern gedreht. Und siehe da!: Mein ursprüngliches Problem, dass die Kamera nur 5fps bei Full-HD liefert, lässt sich beheben, wenn ich von der Kamera ein anderes Farbmodell anfordere.

Jetzt waren in OBS die Farben aber immer noch sehr blass und meine Stirn komplett weiß. Aber durch ein bisschen Googeln stieß ich auf einen Artikel, wo die möglichen Parameter (nicht spezifisch Papalook) mal ein wenig erklärt werden. Belichtungskorrektur runter, Helligkeit rauf, Weißabgleich für Kunstlicht einstellen, und das Bild sah gleich deutlich besser aus.

Durch noch ein bisschen mehr Finetuning habe ich dann ein recht ansehnliches Bild bekommen.

Apple, so scheint mir, hat einfach mal sehr gute Voreinstellungen für die technisch immer noch bessere Webcam mitgeliefert. Soll mir recht sein.

Unter Linux muss ich halt ein wenig mehr Hand anlegen. Skeptisch hatte mich gemacht, dass guvcview (Gnome (oder GTK) UVC Viewer (UVC steht für USB Video Class, eine generische Schnittstelle, um Videogeräte per USB zu verbinden)) ein besseres Bild anzeigte als OBS. Und es waren eben besagte Parameter, an denen ich schrauben musste. Jetzt klappt es auch mit dem Chroma-Key und dem Greenscreen.

Die im Laptop verbaute Webcam wirkt auch bei direkter Kontrolle der Bildparameter matschig und als hinge ein Grauschleier davor.

Meine Lehre jedenfalls ist, dass Apple nicht unbedingt überteuerte Hardware anbietet. Sie bieten Hardware an, wo keine Komponente nur mitgeliefert wird, um eine Checkbox auf der Featureliste abzuhaken. Ich persönlich würde mir ja wünschen, dass mehr Hersteller darauf verzichten, Alibi-Hardware zu verbauen.

Übrigens habe ich es auch mit meinem Handy probiert. Aufmerksame Leser*innen wissen ja, dass ich ein Pixel 3a habe, was dank Google mit die beste Bildqualität liefert. Warum nicht deren Bild anzapfen und als Webcam nutzen? Klar doch: IP Webcam installiert und gestartet, Stream in OBS eingebunden … die Qualität war nochmal deutlich besser als die von Apple-Hardware, keine Frage. Bei meinem ersten Versuch schaltete sich das Handy nach einer halben Stunde ab wegen Überhitzung. Das konnte ich beheben, indem ich es ohne Hülle im Stativ betrieb. Das Stativ allerdings klemmte immer irgendwelche Tasten – die Kamera konnte ich damit nicht mittig im Lichtring ausrichten. Kein Beinbruch, nur halt nicht schön. Schlimmer ist, dass die IP-Verbindung zwischen Laptop und Smartphone nicht reibungslos lief. Schon beim zweiten Einsatz ließ sich der Streamserver auf dem Smartphone nicht mehr finden, so dass meine OBS-Konfiguration ins Leere lief. Für mich war das Anlass, mich mal nach guten, externen Webcams umzuschauen. Aber der Markt ist sehr unübersichtlich. Ich muss mir keine Webcam kaufen, die nur marginal besser als die im Laptop verbaute ist. Mit der Neuanschaffung kann ich zumindest wieder halbwegs meinen Spaß an der nächsten Videokonferenz haben.

Was ich mir wünschen würde: Wenn Webcam-Hersteller einfach mal die Kamera-Hardware von zumindest ordentlichen Smartphone-Kameras verbauen würden. Muss ja nicht gleich Huawei-P30-Niveau sein. Ich fürchte aber, ohne die Nachbearbeitung durch die Software liefern auch deren Kameras nur mäßige Ergebnisse. Logitech und Co. liefern ja für Windows (und manchmal auch macOS) Software mit, die das Kamerabild nachbearbeiten. Als Linux-Nutzer stehe ich ohne da und muss selbst Hand anlegen. Spätestens wenn es allerdings um machine learning und KI bei der Bildaufbereitung geht, ist da jedoch bislang Schluss.

---

Anlass ist übrigens Rollenspiel via Zoom.

"Aber Masin, wenn die Apple-Webcam so toll ist, warum nimmst du dann nicht den Laptop?"

Für mein Privatvergnügen möchte ich nicht Zoom auf meinem Arbeitsgerät installieren, da Zoom in der Vergangenheit durch grobe Patzer gerade unter macOS aufgefallen ist. Immerhin hat die öffentliche Aufmerksamkeit in den vergangenen Monaten dazu geführt, dass Zoom schon kräftig nachgebessert hat. Ich würde gerne auf Zoom verzichten, aber meine Spielrunde hat sich darauf eingeschossen.

---

Auf Facebook kommentierte dann ein Leser, dass ich ja eine semiprofessionelle Kamera per HDMI einbinden könne.

Auch das war eine Überlegung zwischendurch, eine reguläre Kamera zu benutzen. Da gibt es grundsätzlich ja zwei Ansätze.

Ich erinnere mich, wie ich irgendwann um 2005 herum mal einen Skype-Testanruf bei einem Freund gemacht habe, ob er mich hören könne. Ging, aber er entschuldigte sich, dass er kein Headset und auch kein Mikro da habe. Merkwürdigerweise hörte ich trotzdem Tastenklappern und Atmen. Stellte sich heraus, dass sein Camcorder, der per Firewire angebunden war, sein Mikro direkt dem Betriebssystem angeboten hat. Bild hatten wir nicht probiert, aber wir waren sehr erstaunt, dass das überhaupt ging.

Der erste Ansatz wäre also, die Kamera per USB anzuschließen und die Signale auf dem Weg abzugreifen. Wir haben hier noch eine alte Kompaktknipse, mit der ich das probiert habe, aber ohne Erfolg. Ich erinnerte mich, dass Darktable zur Steuerung von Digitalkameras genutzt werden kann, und recherchierte mal, wie die das machen und welche Unterstützung es da gibt. Darktable nutzt libgphoto2, und libgphoto2 hat eine sehr praktische Seite der unterstützten Kameras und ihrer Features. Ich kann davon ausgehen, dass ich eine Kamera brauche, wo "Liveview" vermerkt ist. Zwar bieten immer mehr Hersteller Software an, um ihre Kameras als Webcam nutzen zu können, aber die Firmware der Kamera wird das wohl überhaupt anbieten müssen. Ich gehe davon aus, dass das so semi-standardisiert ist und die Liste ziemlich erschöpfend ist. Nur falls jemand eine Entscheidungshilfe braucht.

Vor der neuen Webcam hatte ich billig in einem Sonderangebot eine kleine 4k-Actioncam von Crosstour erworben, eben in der Erwartung, dass da ein Liveview möglich sei (ich wusste zu dem Zeitpunkt noch nix von o.g. Tabelle). Aber die ausgelieferte Firmware hat das Feature nicht mehr, obwohl es noch in der Anleitung steht, glaube ich. Zumindest in Anleitungen, die man online noch herunterladen kann. Es gibt über Umwege eine alternative Firmware, aber sie erlaubt nur HD-Betrieb als Webcam (720p). Sie spannt aber ein Wifi-Netz auf, wo dann das Kamerabild als Stream abzugreifen ist. Das stellt mich nur vor das Problem, gleichzeitig in zwei WLANs zu sein. Für mich ist das nicht praktikabel. HDMI-Anschluss hat sie auch noch – das wäre noch eine Möglichkeit.

Und damit kommen wir zum zweiten Ansatz, den mein Leser auch vorschlug, eben das Kamerabild per HDMI zu capturen. Die dafür notwendige Capturecard habe ich bislang nur so ab 70€ gesehen, empfohlen wird aber wohl Elgatos Camlink ab ca.130€. Ich habe bei Amazon gerade Capture-Sticks ab 14€ gesehen. Für den Preis probiere ích das mal aus. Wahlweise mit der Actioncam oder mit der Kompaktknipse, wobei ich nicht weiß, ob sie HDMI ausspuckt, ich glaube aber schon. Sollte das gehen, würde es meine Optionen zumindest deutlich ausweiten.

Mittlerweile verfolge ich das Vorhaben ja hauptsächlich nur noch aus Spaß an der Freude, nicht um Ergebnisse zu erzielen.

Ich hatte gestern mal wieder meinen Dell-Laptop Latitude E6430 angeworfen und dachte mir, ich schau mir dessen Kamerabild nochmal an. Eigentlich hatte ich ihn deswegen nicht benutzt, weil er doch nicht das stärkste Pferd im Stall ist (Intel Core i5-3230M CPU @ 2.60GHz). Es ist gerade Abend, Katja hat das Licht da angemacht, wo wir üblicherweise unsere Remote-P&P-Runde aussitzen – die Lichtverhältnisse sind vergleichbar.

So schlecht ist die Webcam da tatsächlich nicht, wie ich sie oben beschrieen habe. Vermutlich weil es ein Businessgerät ist.

Ich nutzte die Gelegenheit und habe mal alle anderen verfügbaren und in Frage kommenden Gerätschaften durchgetestet:

Dell Latitude E6430 Apple Macbook Pro 2015
Beispielbild Dell Latitude E6430 Beispielbild Apple Macbook Pro 2015
Logitech HD C720 Papalook HD 1080p
Beispielbild Logitech HD C720 Beispielbild Papalook HD 1080p
Crosstour Actioncam 4k Lenovo Ideapad Y700
Beispielbild Crosstour Actioncam 4k

Leicht andere Perspektive, da ich meinen Platz auf dem Sofa in der Zwischenzeit räumen musste. Für eine 720p-Kamera ist das Bild eigentlich nicht soooo schlecht. Nachteil ist natürlich, dass es sich um eine Fix-Fokus-Kamera handelt, andererseits ist der Fokusbereich groß genug, will ich meinen. Gewöhnungsbedürftig ist der Kisseneffekt wegen Weitwinkellinse.
Beispielbild Lenovo Ideapad Y700

Das ist der Rechner, der genug Leistung hat, um sich neben der Videokonferenz noch zu langweilen (Intel Core i7-6700HQ CPU @ 2.60GHz). Die Kamera ist indiskutabel schlecht.
Lenovo Ideapad U330p Lenovo Thinkpad X230
Beispielbild Lenovo Ideapad U330p

Erstaunlich finde ich, dass die Webcam besser ist als die vom Y700, was mehrere Jahre später auf den Markt kam. Trotzdem nur vorletzter Platz in meinem persönlichen Ranking.
Beispielbild Lenovo Thinkpad X230

Von den Lenovo-Laptops zeigt das X230 definitiv die beste Qualität, gleichauf mit dem Macbook, wenn auch mit weniger intensiven Farben.
Google Pixel 3a Frontkamera Google Pixel 3a Hauptkamera
Beispielbild Google Pixel 3a Frontkamera

Es gibt kein Szenario, in dem diese Kamera zum Einsatz kommen würde fürs gemütliche Rollenspiel per Videokonferenz. Sie ist nur der Vollständigkeit halber aufgeführt. Man beachte, dass sie besser ist als praktisch jede integrierte Laptop-Webcam in einem Smartphone, dass bei Markteinführung für 400€ über den Ladentisch ging.
Beispielbild Google Pixel 3a Hauptkamera mit Google Kamera-App aufgenommen

Ohne Blick auf den Monitor ist es ganz schön schwer, sich selbst zu knipsen. Hat für den ersten Versuch aber ganz ordentlich funktioniert. Ich denke, die Bildqualität spricht für sich, warum ich versucht habe, sie als Webcam einzuspannen.
Lenovo Tab4 10plus Panasonic Lumix DMC-TZ 6
Beispielbild Lenovo Tab4 10plus

Hier sieht man, dass Lenovo nicht nur schlechte Kameras verbaut. Sie ist vielleicht nicht wirklich gut, aber im Vergleich zu den Laptop-Webcams ein echter Augenöffner. Die Teilnahme an der Videokonferenz mit dem Tablet ist aber eher unkomfortabel für zwei Personen. Dafür ist das Display dann doch zu klein. Außerdem lässt sich das Tablet in seiner Hülle nur begrenzt ausrichten.

 kommt noch
Apple iPhone 8 Frontkamera Apple iPhone 8 Hauptkamera
Beispielbild Apple iPhone 8 Frontkamera
Beispielbild Apple iPhone 8 Hauptkamera

Irgendwie war es beim iPhone deutlich anstrengender, das Gerät falsch herum gegriffen zu bekommen.
Sony Playstation Eye  
Beispielbild Sony Playstation Eye

Die Kamera ist alt. Sie meldet sich ja nicht mal als UVC-Gerät und braucht ein eigenes Kernelmodul. Aber sie schafft hohe Bildraten (60 Hertz).

  

Mir ist noch zusätzlich ein Thinkpad in die Hände gefallen, das ich heute Abend mal testen kann, wenn die Lichtverhältnisse wieder vergleichbar sind. Außerdem habe ich ja noch mein Arbeits-iPhone, das ich zwar nie dafür verwenden würde, aber welches ich durchaus der Vollständigkeit einmal mit aufführen kann. Meine alten Nexusse (Nexen? Nexi?) und das Oneplus One werde ich mir aber ersparen.

Der billige USB-HDMI-Capture-Stick kommt heute. Ich mache mich dann mal auf die Suche nach dem Ladegerät. Die Beispielbilder werde ich oben nachreichen, weitere Gedanken hänge ich ggf. als Update markiert ans Ende des Beitrags.

Update 2020-10-29 19:00 Uhr

Mit dem Bild des Thinkpads würde ich ja sagen, die Grenze zwischen grottigen und akzeptablen Webcams verläuft zwischen Consumer- und Business-Geräten, wie auch bei vielen anderen Merkmalen. Die Erweiterbarkeit und Reparierbarkeit von Consumer-Geräten ist gegenüber Business-Geräten immer nachrangig. Die Bildschirme von Business-Geräten sind für längere Arbeitszeiten vorgesehen und nicht für den schnellen Reiz bei der Ausstellung in der Computerabteilung. Ich könnte mir noch die Mühe machen und mein HP-Compaq-Netbook aus der Schublade holen, aber allein die Vorstellung, den Bootvorgang zu durchstehen bereitet mir körperliche Schmerzen – ich gehe mal davon aus, dass die Webcam darin nur dem Haken auf der Featureliste diente.

Eigentlich punkten Consumer-Geräte nur bei einem Punkt: dem Preis. Gerne in Verbindung mit vermeintlich in harten Zahlen ausgedrückten Merkmalen wie Takt oder Massenspeicher. Ich rate schon seit Jahren dazu, lieber ein gebrauchtes Business-Gerät letzter oder vorletzter Generation zu kaufen statt eines neuen Consumer-Geräts. Viele nicht so offensichtliche Merkmale machen deren Benutzung und Besitz um einiges angenehmer.

Ich will nicht verschweigen, das gebrauchte Business-Geräte womöglich doch den einen oder anderen Nachteil haben dürften. So werden sie wahrscheinlich dicker oder schwerer sein, der Akku wird Alterungsspuren aufweisen, und überhaupt kann eine CPU der letzten oder vorletzten Generation und ihre dazugehörige Hardware stromhungriger sein.

Geschrieben von Masin Al-Dujaili in Technik Kommentare: (0) Trackbacks: (0)

18. Mär: KeePassXC-Features, die mehr Beachtung verdienen: Multiple URLs, Sharing, AutoOpen

(Anm. d. Autors: Dies ist die zweite Fassung, nachdem die erste im Cache des Browsers verloren ging. Es kann meiner Ungeduld angelastet werden, wenn der Text irgendwo inhaltliche Sprünge macht. Sie waren in der ersten Fassung nicht vorhanden. smiley)

Multiple URLs

Sowohl bei meinem ehemaligen wie auch meinem Aktuellen Arbeitgeber nutzen wir ja einen zentralen Verzeichnisdienst (LDAP dort, Active Directory hier), um Authentifizierung bei div. Diensten umzusetzen. Die laufen aber teilweise unter verschiedenen Subdomänen.
 
KeePassXC bietet aber nur ein Feld für eine URL, mit der die Browser-Erweiterung KeePassXC-Browser (Firefox-Erweiterung, Chrome-Erweiterung) einen Vergleich durchführen kann.
 
Ein ehemaliger Kollege hat mir mal gezeigt, dass man dem URL-Feld ODER-Verknüpfungen injizieren kann, aber das bricht die Funktionalität des Doppelklicks auf den URL-Eintrag in der Listenansicht (Öffnen der hinterlegten URL).
 
Eine andere langjährige Empfehlung war es, einfach einen "Klon" des Eintrags mit den Zugangsdaten zu machen, wo der Klon dann nur Verweise auf die ursprünglichen Daten enthält (die GUI bietet leider keine Möglichkeit, Verweise manuell anzulegen).
 
Jetzt habe ich aber herausgefunden, dass KeePassXC seit 2.5.0 (erschienen Oktober 2019, aktuell ist 2.5.3) die erweiterten Attributen von KeePass2Android für das Hinterlegen weiterer URLs unterstützt. Neben dem direkten Bearbeiten der erweiterten Attribute gibt es unter dem Tab "Browser-Integration" auch das Feld "zusätzliche URL's (sic!)", dessen Einträge dann auch als KP2A_URL(_#)-Attribute auftauchen.
 
Fehlt nur noch die GUI, um die Einträge aus KeePassXC heraus aufrufbar zu machen.

Sharing

Während meines Umzugs von 1Password –was mir bei Secuinfra nahegelegt wurde und dem ich einen Monat lang eine Chance gegeben habe, mich zu überzeugen– zu KeePassXC habe ich mir meine Einträge schon ordentlich in Gruppen sortiert. Dabei fiel mir der Einstellungsreiter "KeeShare" auf, wo mir allerdings nur angezeigt wurde, dass KeeShare derzeit deaktiviert sei. Flugs mal gesucht, was es damit auf sich hat, und diese Dokumentation gefunden.
 
Die Anleitung finde ich jetzt nicht sonderlich gelungen. Aber sie ist ausreichend für erste Tests.
 
Prinzipiell erstelle ich mir für jede Installation, wo ich Export oder Sync nutzen will, einen Schlüssel, mit dem ich meine Änderungen signieren kann. Wo ich Import oder Sync nutzen will, muss ich dem Schlüssel vertrauen.
 
Sync besteht de facto aus einem Export und einem Import.
 
Was gibt es zu beachten? Effektiv ist KeeShare nichts anderes als die Erstellung eines Auszugs des aktuellen Schlüsselrings in einem neuen Schlüsselring. Das wird bei jeder Sicherung durchgeführt. Wer also die Option zur automatischen Sicherung aktiv hat, löst nach jeder Änderung einen Export aus. Ich verwende momentan nur die Sync-Option, kann also nicht sagen, wann der Import durchgeführt wird. Aber in anderen Kontexten erkennt KeePassXC sofort, wenn eine Datei geändert wurde, also gehe ich davon aus, dass der Sync- bzw. Import-Schlüsselring dauerhaft auf Veränderungen überwacht wird (kostet ja nichts).
 
Das bedeutet aber eben, dass eine Änderung in Verbindung mit Autosave eine Kaskade an Änderungen auslösen kann. In meinem Fall wurde munter hin und her ge-sync-t. Ich gleiche nur eine Gruppe mit meinen persönlichen beruflichen Einträgen mit meinem privaten Schlüsselring ab, so dass ich ggf. auch von anderen Rechnern auf meine Mails und Kalender zugreifen kann. Vorsicht ist geboten bei dem Feature, Einträge in andere Schlüsselringe zu verschieben. Ich habe durch schlechtes Timing des Syncs dabei meinen Eintrag für Office 365 verloren. Glücklicherweise hatte ich noch auf einem anderen Gerät die alte Version und konnte meine Daten retten.
 
KeeShare nutzt für Import und Sync die Funktion zum Zusammenführen (Merge) (s.a. Menü "Datenbanken" -> "Datenbanken zusammenführen"), ein ebenfalls sehr praktisches Feature. Letztlich ist KeeShare nur ein Automatismus für das Mergen: Eine Gruppe wird in einen Schlüsselring exportiert, diese wird am Ziel wieder importiert. Wie dieser Export-Schlüsselring seinen Weg ans Ziel findet, ist jeder und jedem selbst überlassen. Ich verwende das momentan nur lokal, aber Teams könnten so einzelne Gruppen teilen und die Datei dann mittels Nextcloud, Syncthing oder Netzlaufwerk austauschen.

AutoOpen

Beim Suchen nach der Doku zu KeeShare stieß ich auf die Sonderbehandlung des Ordners "AutoOpen". Einträge in AutoOpen werden beim Entsperren des Schlüsselrings automatisch geöffnet und entsperrt. Dazu muss der Pfad im URL-Feld, das Passwort im Passwort-Feld und ggf. die Schlüsseldatei im Benutzernamens-Feld stehen. Sehr praktisch für all die, die mit mehreren Schlüsselringen jonglieren müssen.
 
Das funktioniert so auch mit KeePass2Android.
Geschrieben von Masin Al-Dujaili in Technik Kommentare: (0) Trackbacks: (0)

25. Dez: Die schöne neue Musikstreamingdienstwelt ist eine Playlisthölle

Als Amazon-Prime-Kunde habe ich ja Zugriff auf einen beschränkten Musikkatalog via Amazon Music Prime. Die Android-App nervt aber bei jedem Start, ob ich nicht Amazon Music Unlimited für nur 4,99€ pro Monat buchen möchte. Vor drei Wochen oder so hat's mir dann gereicht: Die ständige Aufforderung war mir dann doch zu viel und außerdem bot Amazon die ersten drei Monate kostenlos an. Und ich kann den Zugriff auf die große Musikbibliothek ja sicher auch fürs Rollenspiel und so nutzen. Super!
 
Jetzt werde ich genervt mit einem Upgrade auf Amazon Music HD. Für nur 5€ mehr. Ich bin angepisst. Und ich werde dieses Mal ganz sicher nicht … zumindest hoffe ich das :-D.
 
Wie auch immer. Ich habe es oben angedeutet, ich will den Musikkatalog fürs Rollenspiel nutzen. Und da ich eine Numenera-Runde plane, habe ich mal geschaut, was denn andere Spielrunden so an Musik nutzen. Ich habe zwar Vorstellungen, aber kann sie nicht in Worte fassen, weswegen ich gehofft habe, dass ich dann ein paar exemplarische Tracks abgreifen kann.
 
Nebenbei: Der Soundtrack zu Bastion ist großartig. Nicht meine Vorstellung von Numenera, aber großartig.
 
In einem Reddit-Thread teilen dann also auch viele Leute ihre Playlists. Leider, leider bei verschiedensten Anbietern. Will ich überall ein Konto anlegen, einen Tarif buchen?
 
NEIN, natürlich nicht. Die Frage war rhetorisch!.
 
Aber die Playlists lassen sich doch bestimmt exportieren und importieren, oder?
 
Nun, ja und nein. Die erst später von mir aufgerufene Seite im Amazonforum besagt recht deutlich, dass Amazon diesen Featurewunsch bereits seit Jahren ignoriert.
 
Die Dienste selbst bieten zumindest größtenteils keine Option dazu an. Das hat aber ein paar Web- und Appentwickler auf den Plan gerufen, da Abhilfe zu schaffen.
 
Der Playlist-Converter kann sich nur mit einer handvoll Dienste verbinden, und Amazon Music ist keiner davon. ZumListe der unterstützten Dienste von Soundiizindest steht Amazon Music auf der Roadmap. Bringt mich jetzt also auch nicht weiter.
 
Die Webapp Soundiiz bietet eine beeindruckende Liste an Diensten, mit denen sie sich verbinden kann – zu Amazon Music ist jedoch nur ein Lesezugriff implementiert, Playlists können also nur gelesen, aber nicht erstellt werden.
 
Mooval wiederum unterstützt nur die drei Dienste Napster, Deezer und Spotify.
 
Im oben verlinkten Forumsbeitrag wurde auf Stamp verwiesen. Stamp scheint zu können, was ich brauche. Aber sie wollen 8,99€ dafür. Jetzt stehe ich also vor dem Problem, was mir meine eigene Arbeitszeit wert ist, und ob ich mir Stamp leisten möchte. Immerhin gibt es eine Gratisversion, mit der ich anhand einer Playlist und 10 Titeln testen kann, ob sie was taugt.
 
Was aber macht den Unterschied zwischen den Diensten aus? Tja, öffentliche Schnittstellen. Die allermeisten Dienste bieten API-Zugriff auf ihre Dienste, und die Entwickler machen davon reichlich Gebrauch. Und Amazon? Nun … lest selbst.
 
Für die meisten Menschen mag ein API-Zugriff auf den Dienst der Wahl uninteressant sein. API-Zugriff bedeutet aber, dass sich überhaupt erst ein Ökosystem an interessanten Anwendungen (Apps) entwickeln kann. Wer mit den vom Dienstanbieter bereitgestellten Möglichkeiten zufrieden ist, braucht diesen Aspekt nicht bei seiner Auswahl berücksichtigen.
 
Im Moment würde ich von Amazon Music Unlimited abraten, sofern ihr nicht bereits Prime-Kunde seid und ein bisschen aufs Geld achten müsst. Vermutlich werde ich aus dem Grund meinen Unlimited-Tarif auch nach den drei Monaten wieder beenden.
Geschrieben von Masin Al-Dujaili in Technik Kommentare: (0) Trackbacks: (0)

10. Feb: Erlösung und Algorithmen

Erlösung. Lasst uns über Erlösung reden. Damit meine ich die spirituelle Erlösung.

Kann es sein, dass des Menschen größte Erlösung ist, von der Verantwortung seines eigenen Treiben freigesprochen zu werden? Die Welt so erklärt werden kann, dass jeder und alle Gruppen, mit denen er sich identifiziert, frei von Schuld seien?

Aber ganz ohne Schuld geht es ja auch nicht, denn irgendwas Schlimmes passiert ja doch in der Welt, also braucht es Schuldige. Da man selber keine Verantwortung hat und demnach nicht Schuld sein kann –oder ist man nicht schuld und hat demnach keine Verantwortung?–, muss es jemand anders sein.

Spannend finde ich, dass es nie ohne Absicht geht. Es passiert was Schlimmes? Jemand _wollte_, dass dieses Schlimme passiert! Das kann wohl als böse bezeichnet werden, und die Person oder Gruppe als das Böse. Früher hielt noch der Teufel dafür her, heute sind es Verschwörer, die Geheimdienste, Juden (naja, das ist nicht neu), Rothschilds, Soros, das Kapital (alle drei als Stellvertreter für "die Juden") oder –ganz abgefahren– Aliens, Echsenmenschen, Hohlweltler.

Wie komme ich darauf? Deswegen.

Guillaume Chaslot beschreibt darin, wie der Empfehlungsalgorithmus von YouTube schon nach kurzer Zeit Verschwörungsphantasien befeuerte, weil einige wenige Intensivnutzer ihm beibrachten, dass darüber die Aufmerksamkeitszeit maximimiert werden kann. Und diese Videos bieten genau das an, was diese Zielgruppe offensichtlich am meisten ersehnt: Erlösung. Erlösung von der Last, selber an ihrem Zustand, der ihnen so viel Zeit auf YouTube beschert, schuld zu sein. Es sind natürlich Ausländer, Migranten und Flüchtlinge, die ihm die Arbeit wegnehmen und seinem Staat Fantastilliarden an Geld kosten, die ansonsten ihm zustünden. Es sind böse Ölmultis (Rockefeller, bestimmt auch Juden) und Echsenmenschen, die die Vermarktung seines Perpetuum Mobiles behindern. Es sind die Verschwörer der NWO und deren Geheimdienste, die Chemtrails versprühen und mittels HAARP jedwede selbstverständlich ihm innewohnende Brillianz und Grandesse unterdrücken.

Natürlich kann es sein, dass er oder sie vollkommen unverschuldet in diese Lebenslage gerutscht ist. Den Unterschied macht aber aus, ob er oder sie sich als Kollateralschaden wirtschaftlicher Umstände und Unglücke sieht oder als Opfer finsterer Machenschaften und Umtriebe.

Und YouTubes Empfehlungsalgorithmus bietet eben auch Erklärungen, die klar benennbaren Personen oder Gruppen die Verantwortung dafür zuschieben. Videos über Wirtschaftstheorie und -politik sind eben keine Hingucker.

Dieser Tweet bringt es auf den Punkt:

Falls jemanden die Anspielung nicht auffällt, sie stammt hierher: "Suppose we have an AI whose only goal is to make as many paper clips as possible. The AI will realize quickly that it would be much better if there were no humans because humans might decide to switch it off. Because if humans do so, there would be fewer paper clips. Also, human bodies contain a lot of atoms that could be made into paper clips. The future that the AI would be trying to gear towards would be one in which there were a lot of paper clips but no humans." ( Nick Bostrom, as quoted in "Artificial Intelligence May Doom The Human Race Within A Century, Oxford Professor Says")

Die gute Nachricht ist, dass Google wohl jetzt an der Stellschraube dreht, mit der beständig neue Süchtige nach Erlösung geschaffen wurden. Wir werden sehen, welche Auswirkungen das hat.

Geschrieben von Masin Al-Dujaili in Gesellschaft und Politik, Technik Kommentare: (0) Trackbacks: (0)

29. Okt: LineageOS auf Oneplus One (bacon) installieren

Urlaub. Mistwetter. Da könnte man ja mal das Oneplus One (OPO) mit LineageOS bespielen, oder?
 
Was gibt es zu berücksichtigen?
 
*seufz*
 

Hürden

Signal. Die Schlüssel von Signal lassen sich leider nicht retten, da ich das OPO nicht gerootet hatte. Jeder App-Entwickler kann in der Manifest-Datei seiner App angeben, ob sie auf "adb backup" reagieren soll oder nicht. Und OpenWhispersystems hat sich dagegen entschieden aus Sicherheitsgründen (die ich komplett nachvollziehen kann, mir aber so ein wenig die Motivation nehmen).
 
Google Authenticator. Ich habe sechs Dienste in den Authenticator eingebunden. Was für Signal gilt, gilt auch hier: kein Backup möglich. Immerhin kann ich die Verknüpfung temporär auf ein anderes Gerät schieben, um das später wieder zurück auf das OPO zu schieben. Nicht, dass ich falsch verstanden werde: Es gibt keine Automatik. Das muss bei jedem Dienst so gemacht werden, als würde ich die Zweifaktorauthentifizierung neu einrichten.
 
Syncthing. Auch hier liegen die kryptographischen Schlüssel außerhalb meines Zugriffs. Hier muss ich im Anschluss all meinen Geräten die neue Installation wieder bekanntmachen.
 

Vorbereitung

Laden wir erstmal die passenden Pakete herunter:

Netterweise stellen die Leute von LineageOS auch eine leichtverständliche Anleitung zu Verfügung.

Hintergrund

An der Stelle kann ich mal kurz erläutern, warum ich das überhaupt auf mich nehme. Seit September 2016 hat das OPO keine Updates mehr bekommen. Das war auch ungefähr der Zeitpunkt, als Cyanogen Inc. beschlossen hat, den Betrieb und die Weiterentwicklung ihres Cyanogen OS einzustellen. Schon vorher fiel Cyanogen Inc. durch fragwürdige Geschäftsentscheidungen auf:

  • Exklusive, wenn auch zeitlich befristete Vertriebsrechte für einen indischen Smartphone-Hersteller für Cyanogen OS in Indien, was Oneplus als early supporter verärgerte.
  • Einführung von Microsoft-Apps in das System-Image von Cyanogen OS.
  • Entwicklung von "MOD ready", einer Infrastruktur im OS, um Bestandteile durch Komponenten anderer Anbieter austauschen zu können

Das alles hinterließ einen schalen Nachgeschmack zu einem Produkt, das zu großen Teilen auf dem Engagement der Community beruht, die sich um Emanzipation ihrer Nutzer*innen bemüht. Der Name Cyanogen jedenfalls erschien der Community derart beschädigt, dass sie das Community-Projekt CyanogenMod zu LineageOS umbenannten. Cyanogen Inc. ist jedenfalls nicht mehr, und damit sind auch eventuelle Updates eher fragwürdig, zumal Oneplus sicher mehr Interesse daran hat, ihr hervorragendes Oneplus 5 (und bald 5T) zu verkaufen.

An der Stelle wäre es interessant mal zu recherchieren, wie Wileyfox mit dem Cyanogen-Debakel umgegangen ist. Kolleg*innen haben mir berichtet, dass die Swifts (1. Generation) noch Updates auf Android 7.0 oder 7.1 bekommen hätten, die aber sicher nicht von Cyanogen Inc. stammen konnten. Aber auch auf den Swifts hat sich LineageOS 14.1 als bessere Wahl herausgestellt.

Zwei meiner Motivationen sind aber KRACK, ein Angriff auf die WiFi-Verschlüsselung WPA2, für die LineageOS seit Mitte Oktober wohl Patches eingespielt hat, und BlueBorne, ein Angriff auf Bluetooth, der entfernte Code-Ausführung allein über aktiviertes und sogar ungepaartes Bluetooth ermöglicht, was bei LineageOS seit Anfang Oktober gepatcht ist. Ist ersteres vielleicht nur eine theoretische Bedrohung, ist zweiteres komplett fahrlässig zu ignorieren.

Weiterhin gibt es ein paar Ärgernisse, die ich hoffe behoben zu sehen:

  • Das OPO versucht ständig Kontakt zum sog. Cyanogen-Konto aufzunehmen, dessen Server aber längst abgeschaltet ist. Selbst mit deaktiviertem "Sicherheit->Geräteadministrator" von Cyanogen belastet das den Akku.
  • Wenn der Massenspeicher des OPO voll läuft, so ab 80 bis 90 Prozent Belegung, scheitern nicht nur Bluetooth-Verbindungen häufiger mal, das Gerät vergisst auch Paarungen.
  • Bluetooth selber frisst im Leerlauf enorm viel Akkukapazität. Der Unterschied über Nacht ist ungefähr 100 → 85 Prozent zu 100 → 45 Prozent. Ich kann mich ehrlich gesagt nicht daran erinnern, dass das anfangs auch so war. Ich vermute ja, das letzte Cyanogen-OS-Update hat diesen Regress mitgebracht.
  • Das Mikrofon wird offensichtlich stummgeschaltet, wenn ich beim Telefonieren auf freisprechen schalte. Das war anfangs ganz sicher nicht der Fall.

Durchführung

Heute geht es hier um LineageOS auf dem OPO, weswegen ich den Umzug der Authenticator-ZFA auf das andere Gerät nicht beschreibe.

Zwingend notwendig ist die Android Debug Bridge (adb). Unter Linux ist sie einfach über das Paketmanagement zu installieren, unter Windows … nun, Windows-Nutzer*innen müssen sich was suchen.

Am OPO wird dann Android-Debugging in den Entwickleroptionen aktiviert. Dazu müssen diese erstmal freigeschaltet werden: In den Einstellungen wird heruntergescrollt bis "Über das Telefon". Dort wird 7× auf die Buildnumber getippt. Im Anschluss können die "Entwickleroptionen" oberhalb von "Über das Telefon" gefunden werden. Ein bis zwei Bildschirme heruntergescrollt ist "Android-Debugging aktivieren" zu finden.

An der Stelle ließe sich dann das Telefon ans USB-Kabel und dieses an den Computer anschließen. Mein Arch Linux hat hier aber die Kooperation verweigert, indem es das Telefon nicht mehr finden wollte, nachdem USB-Debugging aktiviert wurde. Dementsprechend konnte ich nicht

adb reboot bootloader

ausführen. In den Entwickleroptionen konnte ich aber ein etwas besser ausgestattetes Neustart-Menü aktivieren, was mir das direkte Booten in den Bootloader Fastboot erlaubt.

Sobald auf dem Display des OPO "fastboot" erscheint, kann es über den Befehl "fastboot" angesprochen werden. Bei Linux ist das meines Wissens Teil des adb-Pakets, bei Windows … siehe oben. Mit

fastboot devices

lässt sich anzeigen, ob das Gerät zu finden ist. Ist dem so, lässt sich das OPO mit folgendem Befehl entsperren, falls es noch nicht entsperrt ist:

fastboot unlock oem

Das Gerät wird gelöscht (auf Werkseinstellungen zurückgesetzt)! Im Anschluss startet es neu. Android-Debugging ist leider wieder deaktiviert worden, deswegen erneut aktivieren und wieder in den Fastboot-Bootloader booten. Jetzt lässt sich das oben heruntergeladene TWRP vorübergehend installieren:

fastboot flash recovery twrp-x.x.x-x-bacon.img

Die Versionsnummer ist entsprechend anzupassen. "Vorübergehend" deswegen, weil ich Warnungen gelesen habe, dass ein dann startendes Cyanogen OS das TWRP-Recovery einfach wieder löscht und durch das originale ersetzt. Sollte aus Versehen das OPO also nicht ins Recovery, sondern ins Android gebootet werden, muss diese Prozedur ggf. wiederholt werden. Ist TWRP geschrieben worden, kommt der Teil, der etwas Fingerfertigkeit erfordert: Das OPO muss ausgeschaltet werden. Bei mir half es nicht, lange auf den Power-Button zu drücken – ich musste mit [Power]+[Vol-Down] hart ausschalten. Netterweise ist das gleich die Tastenkombination, mit der auch ins Recovery gebootet werden kann, was dann jetzt ansteht.

TWRP erlaubt es, die benötigten Daten per adb oder per Dateimanager auf das OPO zu kopieren. Da eh schon das Terminal offen ist, heißt es

adb push lineage-14.1-20171023-nightly-bacon-signed.zip /sdcard

LineageOS darf die Google-Apps nicht beinhalten. Deswegen müssen diese für die Verwendung des Play Store gesondert heruntergeladen werden, z.B. von http://opengapps.org/. Das OPO braucht Pakete für die ARM-Plattform, LineageOS 14.1 entspricht Android 7.1. Mit ein bisschen Herumprobieren fand ich heraus, dass das größte installierbare Paket die Mini-Version ist (hier direkt verlinkt). Dieses wird dann auch auf das OPO kopiert:

adb push opengapps-arm-7.1-mini.zip /sdcard

Werden optional root-Rechte gewünscht, ist noch das LineageOS-SU-Addon von https://download.lineageos.org/extras zu beschaffen: ebenfalls ARM, ebenfalls für 14.1. Auch dieses dann rüberkopieren:

adb push addonsu-14.1-arm-signed.zip /sdcard

Damit wäre alles beisammen. Am OPO dann in TWRP "Wipe" auswählen, "Advanced Wipe" und dort dann System, Data und Cache auswählen. Das Löschen bestätigen, kurz warten und zurück ins Hauptmenü. Jetzt können die ZIP-Dateien installiert werden mit "Install". Dort können die eben kopierten Dateien dann nacheinander ausgewählt werden, und zum Schluss wird die Installation dann bestätigt. Weil es nichts kostet, habe ich das Angebot, Dalvik Cache und Data zu wipen angenommen, ebenso die Installation der TWRP-Android-App (die eigentlich nur ein Platzhalter für die richtige App ist). Jetzt kann neugestartet werden. Das erste Mal Android 7.1. zu booten, kann ein wenig länger dauern.

Anmerkung: Mein adb-Problem in Arch Linux habe ich nicht behoben bekommen. Netterweise stellte mir Katja kurzzeitig ihren Ubuntu-Laptop zur Verfügung, wo das Kopieren per adb problemlos verlief. Trotzdem hat mich das wahnsinnig gemacht, da ich in dmesg mitansehen konnte, wie das OPO am USB im Halbsekundentakt die USB-Verbindung verlor und wiederherstellte. Wenn ich ehrgeizig bin, recherchiere ich da mal eine Lösung.

Nach dem Bootvorgang bot mir LineageOS die Wiederherstellung aus verschiedenen Quellen an, unter anderem über mein Google-Konto. Dort konnte ich dann mein A0001 auswählen. Ärgerlicherweise wurde mir keine Option zur Auswahl des WLAN gegeben, bevor ich mit der Ersteinrichtung durch war. Immerhin stellte das Gerät nicht alles wieder her, bevor ich durch war. Sobald ich auf dem Startbildschirm war, aktivierte ich das WLAN und war beruhigt, nicht mein Datenvolumen aufzubrauchen. Immerhin fing es an, mehr als 150 Apps herunterzuladen.

Fazit

Abgesehen von meinen adb-Schwierigkeiten war der Vorgang eigentlich recht problemlos. Ärgerlich ist natürlich, dass einige Apps unwiderruflich ihre Einstellungen verlieren (Signal, Syncthing, Authenticator, WhatsApp (naja, WhatsApp ist mir egal)). Das OPO bootet Android N klaglos und verrichtet seinen Dienst. Bacon, so der Codename des OPO, ist ein offiziell unterstütztes Gerät von LineageOS. Ich erwarte nicht mehr Probleme von LineageOS als vom vorher installierten Cyanogen OS, eher weniger, wegen gereifterer Software und engagierter Community. Ich bin sicher, es wird seine eigenen Macken mitbringen. Mal schauen. So weit bin ich bislang ganz angetan.

Geschrieben von Masin Al-Dujaili in Technik Kommentare: (0) Trackbacks: (0)

3. Okt: Raspberry Pi als Netzwerk- und Bluetooth-Audiogerät (Teil 1)

If you are interested in an english version of this post just ask in the comments. Almost all of the instructions I used for this blog post were in english anyway so there might not be that much use for an english version.

Seit zwei Jahren spiele ich mit dem Gedanken, einen Raspberry Pi als Netzwerk- und Bluetooth-Audiogerät zu konfigurieren, um die alte Mini-Kompaktstereoanlage von Technics im Wohnzimmer mal ins aktuelle Jahrzehnt zu holen. Zu diesem Zweck habe ich mir damals einen Raspberry Pi 2 B und ein Hifiberry DAC+-Board inkl. passendem Gehäuse besorgt. Der Spaß hat zusammen 70 bis 80 € gekostet – je nach Anbieter kann der eine oder andere Euro gespart werden.

Heute würde ich für meinen Anwendungsfall sicher nicht zum 2 B greifen, sondern eher zum Zero W, der Bluetooth und WiFi bereits eingebaut hat. Für 30 € gibt es ein Starterset mit vorbestückter GPIO-Stiftleiste und Netzteil sowie Adaptern. Der passende Hifiberry DAC+ Zero kostet auch nur 15 €. Mit 45 € plus den Kosten für ein passendes Gehäuse liegen die Kosten doch deutlich niedriger.

Meinen 2 B habe ich mit einem USB-Wifi-Adapter und einem Bluetooth-Adapter aus Restbeständen ergänzt. Dafür müssten auch noch so 10 € eingeplant werden, müssten die gekauft werden. Eine passende Micro-SD-Karte ist auch für ein paar Euro zu haben. Ich habe eine mit 2 GB Kapazität genommen, die ich noch da hatte. Vermutlich noch aus einem meiner frühen Nokia-Smartphones.

Warum nicht den Audioausgang des Pi benutzen? Der verbaute DAC des Pi ist von so grausamer Qualität, dass so manches Telefon der Deutschen Post im Vergleich als Hifigerät gelten kann.

Warum überhaupt ein Hifiberry? Sicher wäre auch eine USB-Soundkarte gegangen. Sieht halt nur nicht schick aus. Schon der Wifi-Adapter ist eher hässlich.

Anforderungen 2015

Mein Audiogerät soll folgende Anforderungern erfüllen:

  • Pulseaudio im Netzwerk bereitstellen
  • Bluetoothaudio entgegennehmen und ausgeben
  • Audio per DLNA abspielen
  • sich als Element einer Multiroom-Lösung auf Pulseaudio-Basis verhalten

Erster Versuch

Zu meinem Unglück musste ich 2015 feststellen, dass Raspbian –die offizielle Distribution von der Raspberry Pi Foundation basierend auf Debian– leider ein 4-GB-Medium erfordert. Ich versuchte mein Glück also erstmal mit Arch Linux ARM. Neben der Tatsache, dass es auf ein Datenträger deutlich kleiner als 4 GB passt, fand ich die Installation auch viel angenehmer, da ich dabei das Gefühl von mehr Kontrolle hatte. Für Anfänger ist das aber sicherlich nichts, auch wenn die Anleitung wenig Raum für Fragen lässt. Ein Showstopper mag sein, dass die Anleitung voraussetzt, dass ein laufendes Linux-System benutzt wird.

Bevor das hier jetzt ausufert: Aus dem Audioausgang kam nur furchtbare Statik. Nix zu machen. Nada.

Glücklicherweise stieß ich während meiner Websuche auf Minibian. In der Hoffnung, dass ich mir nach der Installation selektiv die Pakete nachinstallieren kann, die ich für mein Projekt brauche, habe ich es damit probiert. Minibian produzierte kein Rauschen – die Hardware schien also nicht kaputt zu sein. Beruhigend.

Tatsächlich klappte es außergewöhnlich einfach, Pulseaudio so zu konfigurieren, dass es Audio aus dem Netzwerk entgegennimmt – genau, was ich mir heutzutage von modernen Systemen erhoffe. Bluetooth wollte aber partout nicht funktionieren. Nach tagelanger Recherche schob ich die Schuld einfach darauf, dass Minibian sich doch irgendwie susbtantiell von einem regulären Raspbian unterscheidet.

Aus Gründen, die mir nicht mehr einfallen wollen, kam mein Vorhaben erstmal zum Erliegen. 2016 schob sich dann ein Retropie-Vorhaben dazwischen (funktioniert auch wunderbar). Und vor zwei Wochen wollte ich dann mal wieder loslegen.

Nächster Versuch

Zwei Jahre später kann ich ja mal wieder Arch Linux ARM ausprobieren, dachte ich mir. Was auch immer damals schiefgegangen war – vielleicht wurde es ja ausgebügelt.

Installation Hifiberry

Hifiberry stellt eine allgemeine Installationsanleitung zur Verfügung, die auch für Arch Linux ARM gilt. Meine /boot/config.txt sieht danach folgendermaßen aus:

# See /boot/overlays/README for all available options

gpu_mem=64
initramfs initramfs-linux.img followkernel

dtoverlay=hifiberry-dacplus

Je nach Modell des Hifiberry muss natürlich ein anderes Overlay eingefügt werden. Das reicht dann auch bereits schon aus, um dem Hifiberry nach einem Neustart Töne zu entlocken.

Konfiguration Pulseaudio

Als erstes müssen ein paar Pakete installiert werden:

[root@alarmpi ~]# pacman -S pulseaudio pulseaudio-zeroconf pulseaudio-bluetooth

Das Zeroconf-Paket dient dazu, damit Pulseaudio per Avahi im Netzwerk seine Dienste anbieten, das Bluetooth-Paket sorgt dafür, dass Pulseaudio den Audioeingang per Bluetooth via BlueZ erstellen kann.

Entgegen aller Ratschläge im Web wird Pulseaudio als Systemdienst betrieben. Üblicherweise wird der Pulseaudio-Dämon als Benutzer-Dämon betrieben, aber der Audio-Pi soll ja ohne Benutzer-Anmeldung ganz stupide Audio entgegennehmen und auf dem Audioausgang des Hifiberry ausgeben. Auf einem regulären Desktop oder Laptop sollte das tatsächlich nicht so gemacht werden.

Damit Pulseaudio als Systemdienst starten kann, braucht systemd eine Datei namens bspw. /etc/systemd/system/pulseaudio.service:

[Unit]
Description=PulseAudio system server

[Service]
ExecStart=/usr/bin/pulseaudio --system --disallow-exit --log-target=journal
#ExecStart=/usr/bin/pulseaudio --system --disallow-exit --disallow-module-loading --log-target=journal
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

Solange die Konfiguration nicht finalisiert ist, bleibt --disallow-module-loading auskommentiert. Wenn Pulseaudio als Systemdienst betrieben wird, braucht es einen Nutzer namens pulse und zwei Gruppen, pulse und pulse-access:

[root@alarmpi ~]# groupadd --system pulse
[root@alarmpi ~]# groupadd --system pulse-access
[root@alarmpi ~]# useradd --system -g pulse -G audio -d /var/run/pulse -m pulse
[root@alarmpi ~]# usermod -G pulse-access root
[root@alarmpi ~]# usermod -G pulse-access alarm

Ich habe keine Ahnung, ob die beiden letzten Befehle wirklich notwendig sind, schaden tun sie aber auch erstmal nicht. Als nächstes wird verhindert, dass Pulseaudio bei Anmeldung eines Nutzers normal startet:

[root@alarmpi ~]# echo "default-server = /var/run/pulse/native" >> /etc/pulse/client.conf
[root@alarmpi ~]# echo "autospawn = no" >> /etc/pulse/client.conf

Der Dienst kann jetzt enabled und gestartet werden:

[root@alarmpi ~]# systemctl daemon-reload
[root@alarmpi ~]# systemctl enable pulseaudio.service
[root@alarmpi ~]# systemctl start pulseaudio.service

Bevor alles funktioniert, wird Pulseaudio sicher noch ein paar Mal neu gestartet. Für die Konfiguration von Pulseaudio werden die Dateien system.pa und daemon.conf in /etc/pulse benutzt.

/etc/pulse/system.pa

#!/usr/bin/pulseaudio -nF
#
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see <http://www.gnu.org/licenses/>.

# This startup script is used only if PulseAudio is started in system
# mode.

### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
load-module module-udev-detect tsched=0
.else
### Use the static hardware detection module (for systems that lack udev/hal support)
load-module module-detect
.endif

### Load several protocols
.ifexists module-esound-protocol-unix.so
load-module module-esound-protocol-unix
.endif
load-module module-native-protocol-unix

### Automatically restore the volume of streams and devices
load-module module-stream-restore
load-module module-device-restore

### Automatically restore the default sink/source when changed by the user
### during runtime
### NOTE: This should be loaded as early as possible so that subsequent modules
### that look up the default sink/source get the right value
load-module module-default-device-restore

### Automatically move streams to the default sink if the sink they are
### connected to dies, similar for sources
load-module module-rescue-streams

### Make sure we always have a sink around, even if it is a null sink.
load-module module-always-sink

### Automatically suspend sinks/sources that become idle for too long
load-module module-suspend-on-idle

### Enable positioned event sounds
load-module module-position-event-sounds

### Customizations
#load-module module-native-protocol-unix auth-anonymous=1
load-module module-zeroconf-publish
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.1.0/24 auth-anonymous=1

set-default-sink 0
#set-card-profile 0 stereo-fallback

### Automatically load driver modules for Bluetooth hardware
.ifexists module-bluetooth-policy.so
load-module module-bluetooth-policy
.endif

.ifexists module-bluetooth-discover.so
load-module module-bluetooth-discover
.endif

/etc/pulse/daemon.conf:

# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see <http://www.gnu.org/licenses/>.

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = (depends on architecture)

; load-default-script-file = yes
; default-script-file = /etc/pulse/default.pa

; log-target = auto
; log-level = notice
; log-meta = no
; log-time = no
; log-backtrace = 0

; resample-method = speex-float-1
resample-method = trivial
; avoid-resampling = false
; enable-remixing = yes
; remixing-use-all-sink-channels = yes
; enable-lfe-remixing = no
; lfe-crossover-freq = 0

flat-volumes = no
; flat-volumes = yes

; rlimit-fsize = -1
; rlimit-data = -1
; rlimit-stack = -1
; rlimit-core = -1
; rlimit-as = -1
; rlimit-rss = -1
; rlimit-nproc = -1
; rlimit-nofile = 256
; rlimit-memlock = -1
; rlimit-locks = -1
; rlimit-sigpending = -1
; rlimit-msgqueue = -1
; rlimit-nice = 31
; rlimit-rtprio = 9
; rlimit-rttime = 200000

; default-sample-format = s16le
; default-sample-rate = 44100
; alternate-sample-rate = 48000
; default-sample-channels = 2
; default-channel-map = front-left,front-right

; default-fragments = 4
; default-fragment-size-msec = 25

; enable-deferred-volume = yes
; deferred-volume-safety-margin-usec = 8000
; deferred-volume-extra-delay-usec = 0

Nach einem Neustart von Pulseaudio

[root@alarmpi ~]# systemctl restart pulseaudio.service

finden andere Pulseaudio-Dämonen im Netz dann auch schon den Pi. Vielleicht müssen noch entsprechende Zeroconf-Pulseaudio-Pakete auf den jeweiligen Rechnern installiert werden, sollte der Pi nicht in der Liste der Audioausgabegeräte auftauchen.

Audio-Pi als Ausgabegerät in den Pulseaudioeinstellungen. Ich habe keine Ahnung, warum er zwei Mal auftaucht.

Konfiguration Bluetooth

Bluetooth unter Linux kann einen in den Wahnsinn treiben. Als Lektüre dazu empfehle ich Bluez must be one of the best kept secrets in Linux und Bluez – greatest Linux mystery. Ohne ordentliche Dokumentation sehe ich leider auch kaum eine Möglichkeit, die letzten Bluetooth-Baustellen zu beseitigen.

Natürlich werden erstmal ein paar Pakete benötigt:

[root@alarmpi ~]# pacman -S bluez bluez-utils

Dann wird die /etc/bluetooth/main.conf bearbeitet:

[General]

# Default adapter name
# Defaults to 'BlueZ X.YZ'
Name = wohn

# Default device class. Only the major and minor device class bits are
# considered. Defaults to '0x000000'.
#Class = 0x000100
Class = 0x200420

# How long to stay in discoverable mode before going back to non-discoverable
# The value is in seconds. Default is 180, i.e. 3 minutes.
# 0 = disable timer, i.e. stay discoverable forever
DiscoverableTimeout = 0

# How long to stay in pairable mode before going back to non-discoverable
# The value is in seconds. Default is 0.
# 0 = disable timer, i.e. stay pairable forever
PairableTimeout = 0

# Automatic connection for bonded devices driven by platform/user events.
# If a platform plugin uses this mechanism, automatic connections will be
# enabled during the interval defined below. Initially, this feature
# intends to be used to establish connections to ATT channels. Default is 60.
#AutoConnectTimeout = 60

# Use vendor id source (assigner), vendor, product and version information for
# DID profile support. The values are separated by ":" and assigner, VID, PID
# and version.
# Possible vendor id source values: bluetooth, usb (defaults to usb)
#DeviceID = bluetooth:1234:5678:abcd

# Do reverse service discovery for previously unknown devices that connect to
# us. This option is really only needed for qualification since the BITE tester
# doesn't like us doing reverse SDP for some test cases (though there could in
# theory be other useful purposes for this too). Defaults to 'true'.
#ReverseServiceDiscovery = true

# Enable name resolving after inquiry. Set it to 'false' if you don't need
# remote devices name and want shorter discovery cycle. Defaults to 'true'.
#NameResolving = true

# Enable runtime persistency of debug link keys. Default is false which
# makes debug link keys valid only for the duration of the connection
# that they were created for.
#DebugKeys = false

# Restricts all controllers to the specified transport. Default value
# is "dual", i.e. both BR/EDR and LE enabled (when supported by the HW).
# Possible values: "dual", "bredr", "le"
#ControllerMode = dual

# Enables Multi Profile Specification support. This allows to specify if
# system supports only Multiple Profiles Single Device (MPSD) configuration
# or both Multiple Profiles Single Device (MPSD) and Multiple Profiles Multiple
# Devices (MPMD) configurations.
# Possible values: "off", "single", "multiple"
#MultiProfile = off

# Permanently enables the Fast Connectable setting for adapters that
# support it. When enabled other devices can connect faster to us,
# however the tradeoff is increased power consumptions. This feature
# will fully work only on kernel version 4.1 and newer. Defaults to
# 'false'.
#FastConnectable = false

# Default privacy setting.
# Enables use of private address.
# Possible values: "off", "device", "network"
# "network" option not supported currently
# Defaults to "off"
# Privacy = off

Enable=Source,Sink,Media,Socket

[GATT]
# GATT attribute cache.
# Possible values:
# always: Always cache attributes even for devices not paired, this is
# recommended as it is best for interoperability, with more consistent
# reconnection times and enables proper tracking of notifications for all
# devices.
# yes: Only cache attributes of paired devices.
# no: Never cache attributes
# Default: always
#Cache = always

[Policy]
#
# The ReconnectUUIDs defines the set of remote services that should try
# to be reconnected to in case of a link loss (link supervision
# timeout). The policy plugin should contain a sane set of values by
# default, but this list can be overridden here. By setting the list to
# empty the reconnection feature gets disabled.
#ReconnectUUIDs=00001112-0000-1000-8000-00805f9b34fb,0000111f-0000-1000-8000-00805f9b34fb,0000110a-0000-1000-8000-00805f9b34fb

# ReconnectAttempts define the number of attempts to reconnect after a link
# lost. Setting the value to 0 disables reconnecting feature.
#ReconnectAttempts=7

# ReconnectIntervals define the set of intervals in seconds to use in between
# attempts.
# If the number of attempts defined in ReconnectAttempts is bigger than the
# set of intervals the last interval is repeated until the last attempt.
#ReconnectIntervals=1,2,4,8,16,32,64

# AutoEnable defines option to enable all controllers when they are found.
# This includes adapters present on start as well as adapters that are plugged
# in later on. Defaults to 'false'.
AutoEnable=true

Die wichtigen Dinge passieren in "Enable=" und ich habe keine Ahnung, warum "Source, Sink, Media" nicht ausgereicht hat. "Name=" ist frei wählbar – ich würde auf Sonderzeichen verzichten. "Class=0x200420" sagt an, dass der Bluetooth-Adapter sich als Car Audio System ausgeben soll (Quelle). Vermutlich gehen auch andere – hilfreich dabei dürfte der Bluetooth Class of Device (CoD) Generator sein. Auf der linken Seite einfach Audio oben und Audio unten auswählen, dann erscheint rechts eine Liste möglicher Minor Device Classes. Ich habe es erst mit 0x200428 probiert, aber ohne Erfolg, was aber wohl eher an den fehlenden DBus-Konfigurationen lag.

Konfiguration DBus

Unter Linux kommunizieren Prozesse untereinander auf verschiedenen Wegen, und DBus ist einer davon. Das ganze Setup erfordert, dass verschiedene Dienste unter verschiedenen Benutzerkonten miteinander sprechen dürfen.

/etc/dbus-1/system.d/pulseaudio.conf:

<?xml version="1.0"?> <!--*-nxml-*-->
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
    <policy group="pulse">
        <allow own="org.pulseaudio.Server"/>
    </policy>

    <policy context="default">
        <allow send_destination="org.pulseaudio.Server"/>
        <allow receive_sender="org.pulseaudio.Server"/>
    </policy>
</busconfig>

/etc/dbus-1/system.d/pulseaudio-bluetooth.conf:

<busconfig>
  <policy user="pulse">
    <allow send_destination="org.bluez"/>
  </policy>
</busconfig>

/etc/dbus-1/system.d/bluetooth.conf:

<!-- This configuration file specifies the required security policies
     for Bluetooth core daemon to work. -->

<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>

  <!-- ../system.conf have denied everything, so we just punch some holes -->

  <policy user="root">
    <allow own="org.bluez"/>
    <allow send_destination="org.bluez"/>
    <allow send_interface="org.bluez.Agent1"/>
    <allow send_interface="org.bluez.MediaEndpoint1"/>
    <allow send_interface="org.bluez.MediaPlayer1"/>
    <allow send_interface="org.bluez.ThermometerWatcher1"/>
    <allow send_interface="org.bluez.AlertAgent1"/>
    <allow send_interface="org.bluez.Profile1"/>
    <allow send_interface="org.bluez.HeartRateWatcher1"/>
    <allow send_interface="org.bluez.CyclingSpeedWatcher1"/>
    <allow send_interface="org.bluez.GattCharacteristic1"/>
    <allow send_interface="org.bluez.GattDescriptor1"/>
    <allow send_interface="org.freedesktop.DBus.ObjectManager"/>
    <allow send_interface="org.freedesktop.DBus.Properties"/>
    <allow send_destination="org.bluez.Manager"/>
    <allow receive_sender="org.bluez.Manager"/>
    <allow send_destination="org.bluez.Adapter"/>
    <allow receive_sender="org.bluez.Adapter"/>
    <allow send_destination="org.bluez.Device"/>
    <allow receive_sender="org.bluez.Device"/>
    <allow send_destination="org.bluez.Service"/>
    <allow receive_sender="org.bluez.Service"/>
    <allow send_destination="org.bluez.Database"/>
    <allow receive_sender="org.bluez.Database"/>
    <allow send_destination="org.bluez.Security"/>
    <allow receive_sender="org.bluez.Security"/>
  </policy>

  <policy at_console="true">
    <allow send_destination="org.bluez"/>
  </policy>

  <!-- allow users of lp group (printing subsystem) to
       communicate with bluetoothd -->
  <policy group="lp">
    <allow send_destination="org.bluez"/>
  </policy>

  <policy context="default">
    <deny send_destination="org.bluez"/>
  </policy>

</busconfig>

Das ist aus verschiedenen Quellen zusammengetragen. Falls jemand versteht, was die einzelnen Zeilen tun: Ich freue mich über Kommentare. Ich vermute, die Zeilen mit Bluetooth-Druckern sind überflüssig, aber es funktioniert so erstmal. In der verwendeten Anleitung fand ich den Hinweis, dass

[root@alarmpi ~]# systemctl restart dbus && systemctl restart polkit && systemctl restart systemd-logind

bereits reichen sollte, ein Neustart aber die sichere Variante sei. Wie jetzt über Bluetooth Audio empfangen kann, erkläre ich im Abschnitt "Baustellen".

Baustellen

Bluetooth-Kopplung

Der Audio-Pi sollte jetzt unter dem gewählten Namen, bei mir "wohn", per Bluetooth gefunden werden können. Mein Android-Tablet konnte jedenfalls erfolgreich ein Pairing durchführen. Aber: Eine Verbindung ist damit noch nicht möglich. Ich muss bislang auf der Kommandozeile bluetoothctl aufrufen und in der interaktiven Shell dann explizit trust <device bt mac> eingeben. Erst danach verbindet sich mein Tablet mit dem Pi und kann darüber dann auch Audio ausgeben. Angeblich solle dieser Schritt ausbleiben können, wenn eine PIN gesetzt würde. Ich habe aber nicht herausfinden können, wie ich meinen Pi mit einer PIN sichere. Ich würde ja so eine Alibi-PIN wie 0000 oder 1234 setzen – auch das fände ich dann noch hinreichend komfortabel. Idealerweise möchte ich aber komplett auf eine PIN verzichten – einfach paaren, verbinden, Audio abspielen. Aber die Dokumentation zu BlueZ ist verbesserungswürdig. Stark verbesserungswürdig.

DLNA

DLNA habe ich hier noch nicht konfiguriert. Ich hatte bei meiner 2015er-Recherche aber schon ein paar verständliche Anleitungen gefunden – es sollte also gehen. Wenn ich dann noch zusätzlich Video über den HDMI-Anschluss ausgeben könnte, wäre das ein netter Zuspieler für Fernseher.

MPD

Das ist neu in der Liste meiner Anforderungen. Bei meiner aktuellen Recherche stieß ich vermehrt auf Audioausgabe via MPD. Beim kurzen Überfliegen der Anleitungen sah das nicht so schwer aus. MPD-Clients gibt es auch für Smartphones, und was meine Auswahl an Software vergrößert, mit der ich Audio wiedergeben kann, ist mir immer willkommen. Ich finde ja, Bluetooth-Audio ist für Zwecke der Audio-Wiedergabe im Netz eher eine Krücke, wenn nichts anderes vorhanden ist, und nicht meine Wahl-Lösung.

Multiroom-Audiowiedergabe

Wenn ich bedenke, dass das mein ursprüngliches Anliegen war, dann habe ich bislang aber mächtig versagt. Mit Pulseaudio ist das aber wohl sehr einfach umzusetzen. Mir mangelt es im Moment natürlich ganz klar an weiteren entsprechende Audio-Pis, aber ich werde einfach demnächst mal meiner eigenen Pi-Zero-Kaufempfehlung folgen und mir noch zwei weitere Audio-Pis basteln. So finde ich auch den Hifiberry Amp+ sehr spannend, da ich darüber recht einfach einen regulären Lautsprecher netzwerkfähig bekommen könnte. Zu schade, dass es gerade den nicht im Zero-Format gibt, aber die zusätzlichen Verstärkerbausteine dürften einfach zu viel sein dafür, von den Anschlüssen ganz zu schweigen.

WLAN-Einbindung

Momentan macht der Audio-Pi nur LAN, obwohl der Wifi-Stick dranhängt. Ich muss also noch die WLAN-Konfiguration machen. Toll wäre natürlich, würde er ein eigenes Netz aufspannen, wenn kein bekanntes in der Nähe ist, um dann per Webinterface sein WLAN konfigurieren zu lassen.

Sobald ich Inhalt für Teil 2 habe, werde ich den hier auch verlinken. Im Moment reicht mir das von der Länge her. Wenn ich mir meinen zweiten Audio-Pi bastele, werde ich der Anleitung hier folgen und schauen, ob ich grobe Fehler gemacht habe, die ich dann natürlich korrigieren werde.

If you are interested in an english version of this post just ask in the comments.

Geschrieben von Masin Al-Dujaili in Technik Kommentar: (1) Trackbacks: (0)
« vorherige Seite   (Seite 1 von 1, insgesamt 10 Einträge)   nächste Seite »