Archiv ‘Linux’

Sonntag, 10. März 2019

Alle mit pip installierten Pakete aktualisieren

Link zu diesem Artikel

Leider gibt es beim Python-Paketmanager pip („Pip installs Packages“) keine Routine à la apt-get update && apt-get upgrade, um alle installierten Pakete zu aktualisieren.

Mit folgendem Befehl kommt man aber verdammt nah an diese Funktionalität dran:

# pip install -U $(pip freeze | awk '{split($0, a, "=="); print a[1]}')

Quelle: update all installed python packages with pip

Das habe ich gestern auf einem System gemacht, musste aber leider feststellen, dass pip selbst auf einem relative „einfachen“ System bei bestimmten Paketen ins Straucheln gerät. Es ist also viel Zeit und Handarbeit nötig, um sicher zu sein, dass alle Pakete aktualisiert wurden.

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 16. Oktober 2018

USB-Kabel ist nicht gleich USB-Kabel, oder: Wieso ein Raspberry Pi 3 einen gelben Blitz anzeigt

Link zu diesem Artikel

Von meinem Dashboard, meinem ganzen Stolz über all die Jahre, habe ich hier ja bereits mehrere Male berichtet (Ausgangspunkt).

Seit Juni 2016 verwende ich zum Betrieb des Dashboards einen Raspberry Pi 3 — und wahrscheinlich genau so lange hat das Ding mir auf dem Bildschirm einen gelben Blitz angezeigt:

Bis letzte Woche hatte ich keinen blassen Schimmer, was dieses Symbol zu bedeuten hat — nerven tat es auf jeden Fall. Doch dann stolperte ich auf Grund folgender Fehlermeldung im Debian Kernel Log (unter /var/log/kern.log) …

...
Oct  9 05:00:06 DASHBOARD kernel: [    2.116304] Under-voltage detected! (0x00050005)
Oct 10 05:00:08 DASHBOARD kernel: [    2.089827] Under-voltage detected! (0x00050005)
Oct 11 05:00:07 DASHBOARD kernel: [    2.080389] Under-voltage detected! (0x00050005)
Oct 11 05:17:06 DASHBOARD kernel: [    2.080005] Under-voltage detected! (0x00050005)
Oct 11 05:17:04 DASHBOARD kernel: [    2.071669] Under-voltage detected! (0x00050005)
Oct 11 05:17:04 DASHBOARD kernel: [    2.089371] Under-voltage detected! (0x00050005)
...

… über folgenden Artikel:

If a lightning bolt image appears in the top-right corner of the screen, it means Raspberry Pi is not getting enough voltage (4.65V according to this forum post).

Quelle: Lightning Bolt (Under-Voltage Warning) on Raspberry Pi

All die Jahre erschien dieses Symbol, aber ich realisierte nicht, dass mir mein RPi3 etwas Wichtiges damit sagen wollte!

Ich hätte das Problem wie im Artikel beschrieben mit der Quick-and-Dirty-Symptombekämpfungslösung wegmachen können (avoid_warnings=1-Eintrag in /boot/config.txt), doch ich war an der tatsächlichen Lösung des Problems interessiert: Mehr Volt für meinen RPi!

Der Raspberry Pi hängt seit 2014 an einem AOC E2460SHU Monitor, für welchen der Hersteller mit einem roten und einem Power-Schriftzug markierten USB-Anschluss wirbt (Direktlink auf das Bild). Daran konnte es doch nun kaum liegen?!

Zu Beginn der Recherche machte ich den Fehler, dass ich nach Lösungen für zu wenig Ampere (Strom) über den USB-Bus suchte. Dabei stiess ich auf folgendes Kabel („Dual Input USB Power“) und war kurz davor, es zu bestellen — bis ich mir noch einmal die Fehlermeldung zu Gemüte rief. Dort liest man nichts von „under-current“, sondern von „under-voltage“, das heisst zu tiefer Spannung!

Nach wenigen Minuten stiess ich auf unzählige Forumsbeiträge zum Thema; einen Interessanten hier:

Stutzig wurde ich, als in mehreren anderen Forenbeiträgen empfohlen wurde, nicht zuerst die Stromquelle selber als Problem zu vermuten, sondern auch das verwendete USB-Kabel genauer anzuschauen und gegebenenfalls auszuwechseln. Begleitet wurden diese Empfehlungen von Rückmeldungen vieler Benutzer, die rein mit dem Austausch des Kabels die Meldung weggebracht hatten.

Doch wieso ist das so? Folgende zwei Artikel geben Auskunft über das Phänomen:

In vielen Fällen rührt das Problem davon, dass man keine qualitativ hochstehenden USB-Kabel verwendet (ja, ich weiss, vergoldete HDMI-Kabel für 99 CHF …). Das heisst anstelle von explizit „Charging Cable“ genannten Waren nur „Data Cables“. Das Problem der qualitativ minderwertigen Kabel ist, dass sie einen zu kleinen Querschnitt und somit einen zu hohen Widerstand haben. Dies führt dazu, dass die 5V Betriebsspannung am USB-Anschluss (der Stromquelle) bis zum RPi problemlos um 0.25V bis über 0.5V abnehmen kann — und somit wie oben genannt weniger als 4.65V beim Raspberry Pi ankommen (Grafik).

Kann wirklich das USB A-auf-USB Mikro-Kabel das Problem sein?! Offenbar schon, wenn man folgenden Artikel in einem RPi-Forum durchliest: Best Micro USB cables

Ein gutes Kabel erkennt man, wenn es einen Aufdruck mit einem numerisch tiefen AWG-Wert enthält.

Zurück von der Arbeit durchsuchte ich meinen USB Mikro ZIP-Lock-Sack. Rasch musste ich feststellen, dass kaum (mehr) Kabel einen AWG-Wert angeben. Einige wenige Kabel hatten einen Aufdruck, und ich machte mich daran, das bis heute genutzte USB-Kabel des RPi auszutauschen.

  1. Das erste Kabel war fälschlicherweise ein USB A- auf USB Mini-Kabel (statt Micro). Dabei wäre es perfekt gewesen: 28AWG/1P+24AWG/2C plus zusätzlich ein Ferritkern an einem Ende.
  2. Das zweite Kabel mit 26AWG/1P 26AWG/2C wäre brauchbar gewesen, doch leider scheint es defekt zu sein — der RPi3 tat keinen Wank, weshalb ich auf Kabelbruch tippte.
  3. Das dritte Kabel funktionierte schlussendlich. Es ist sehr, sehr kurz und trägt den Schriftzug 28AWG/1P and 28AWG/2C. Zuerst befürchtete ich, dass dies bereits ein zu hoher AWG-Wert ist — doch der gelbe Blitz ist seither nicht mehr sichtbar.

Kabel Nummer 1:

Kabel Nummer 2:

Kabel Nummer 3:

Nachtrag 1

Ich muss noch bemerken, dass ich das Kabel seit langem nicht mehr direkt in den USB-Port des Monitors einstecke, sondern noch ein USB-Winkelstück (90 Grad; männlich, weiblich) gekauft habe, damit das Kabelende nicht so hässlich am oberen Ende des Monitors heraussticht. Ein solches Stück kann selbstverständlich auch noch zu Spannungsverlusten führen; in meinem Fall ist der Verlust zusammen mit einem qualitativ hochstehenden Kabel aber offenbar vernachlässigbar.

Nachtrag 2

Leider sind die Kernel-Meldungen nicht ganz weg. Seit Austausch des Kabels habe ich in kern.log folgende Einträge gefunden:

...
Oct 16 19:18:55 DASHBOARD kernel: [  370.259369] Under-voltage detected! (0x00050005)
Oct 16 19:20:06 DASHBOARD kernel: [  440.980952] Under-voltage detected! (0x00050005)
Oct 16 20:31:53 DASHBOARD kernel: [ 4748.658891] Under-voltage detected! (0x00070005)
Oct 16 20:38:41 DASHBOARD kernel: [ 5156.348023] Under-voltage detected! (0x00050005)
Oct 16 20:49:53 DASHBOARD kernel: [ 5828.208492] Under-voltage detected! (0x00070005)
Oct 16 20:53:00 DASHBOARD kernel: [ 6015.403857] Under-voltage detected! (0x00070007)
...

Tags: , , , , , , , , , , , ,
Labels: IT, Linux

1 Kommentar | neuen Kommentar verfassen

Sonntag, 9. September 2018

Zwischenstand abfragen bei „Elasticsearch is still initializing the kibana index“

Link zu diesem Artikel

In meinem Netzwerk läuft eine ElasticSearch-, Lucene- und Kibana- oder kurz ELK-Komponente, an welche alle Geräte im Netzwerk per syslog ihre Log-Events zusenden. Gelegentlich muss ich den ELK-Docker-Container herunter- und wieder hochfahren. Da ich ELK auf einem Laptop laufen lassen und die CPU-Frequenz des Geräts auf den tiefstmöglichen Wert für diese CPU festgelegt habe (1200 MHz; Überhitzung führte vorher zu unregelmässigen Abstürzen), kann es manchmal eine Weile dauern, bis ELK nach einem solchen Neustart wieder hochkommt. Doch bis es soweit ist, strahlt einem dieses Kibana Status-Fenster entgegen:

Wenn man sich dafür interessiert, wie weit der Kibana-Index bereits wiederhergestellt ist, ruft folgende URL auf:

http://1.2.3.4:9200/_cluster/health?pretty=true

Im Browser sieht man dort dann nützliche Informationen über den Cluster, und für unseren Fall ganz wichtig, das Attribut active_shards_percent_as_number:

{
  "cluster_name" : "elasticsearch",
  "status" : "red",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 1753,
  "active_shards" : 1753,
  "relocating_shards" : 0,
  "initializing_shards" : 4,
  "unassigned_shards" : 4035,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 10,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 807617,
  "active_shards_percent_as_number" : 30.265883977900554
}

Im Browser kann man nun regelmässig diese Seite neu laden und sollte sehen, wie active_shards_percent_as_number kontinuierlich nach oben zählt. Sobald 100 Prozent erreicht sind, läuft der Cluster wieder wie erwartet.

Wer nur eine Kommandozeile zur Verfügung hat, hilft sich folgendermassen:

$ watch -n 1 curl -XGET 'http://1.2.3.4:9200/_cluster/health?pretty=true'

Quelle: Monitor ElasticSearch cluster health – Useful for keeping an eye on ES when rebalancing takes place

Tags: , , , , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 4. August 2018

logrotate meldet „mysqladmin: connect to server at ‚localhost‘ failed“

Link zu diesem Artikel

/etc/cron.daily/logrotate:
mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'root'@'localhost' (using password: NO)'
error: error running shared postrotate script for '/var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log /var/log/mysql/mariadb-slow.log /var/log/mysql/error.log '
run-parts: /etc/cron.daily/logrotate exited with return code 1

Hat man das root-Passwort angepasst (sprich: es ist nicht mehr leer, wie standardmässig vorgegeben), muss man das Passwort in der Datei /etc/mysql/debian.cnf ergänzen.

Die dort erfassten Parameter werden vom logrotate-Script unter /etc/logrotate.d/mysql-server eingelesen und zum Zugriff verwendet.

Quelle: MySQL logrotate error

Tags: ,
Labels: Linux

2 Kommentare | neuen Kommentar verfassen

Sonntag, 8. Juli 2018

OpenVPN meldet „INSECURE cipher with block size less than 128 bit (64 bit).“

Link zu diesem Artikel

Zwar erscheint die folgende Fehlermeldung seit längerem in den Logs meiner Site-to-Site-VPNs, doch heute erst hatte ich die Zeit, mich dem Problem anzunehmen:

Sun Jul  8 09:24:37 2018 Outgoing Static Key Encryption: Cipher 'BF-CBC' initialized with 128 bit key
Sun Jul  8 09:24:37 2018 WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).

Zuerst dachte ich, dass ich die statischen Schlüssel der VPN-Verbindungen neu erstellen muss, weshalb ich zuerst einmal das Script optimierte. Falsch gedacht! Obwohl ich die Schlüssel ersetzt hatte, erschien beim erneuten Verbindungsaufbau erneut dieselbe Fehlermeldung.

Nach etwas Googlen dann die effektive Lösung: Ich muss die Konfigurationsdateien der jeweiligen Verbindungen anpassen! Folgende Zeile habe ich nun in die OpenVPN-Konfigurationsdateien auf beiden Seiten eingefügt:

...
cipher      AES-256-CBC
...

Et voilà! Auf der Seite des Servers sehe ich nun in der Log-Datei:

Sun Jul  8 10:47:17 2018 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017
Sun Jul  8 10:47:17 2018 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.08
Sun Jul  8 10:47:17 2018 Outgoing Static Key Encryption: Cipher 'AES-256-CBC' initialized with 256 bit key
Sun Jul  8 10:47:17 2018 Outgoing Static Key Encryption: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Jul  8 10:47:17 2018 Incoming Static Key Encryption: Cipher 'AES-256-CBC' initialized with 256 bit key
Sun Jul  8 10:47:17 2018 Incoming Static Key Encryption: Using 160 bit message hash 'SHA1' for HMAC authentication
...

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 24. Juni 2018

Cacti spine 1.1.38 meldet beim Kompilieren ./configure: No such file or directory

Link zu diesem Artikel

Kürzlich wollte ich das auf meinem Cacti-Server installierte spine mit der neuesten stabilen Version aktualisieren.

Nachdem ich den Quellcode aus dem Internet in ein lokales Verzeichnis heruntergeladen hatte, wollte ich das Paket wie üblich kompilieren:

$ ./configure
./configure: No such file or directory

Was Cheibs? Nach einigem Googlen dann die Lösung, ebenfalls auf GitHub, aber zu einem völlig unverwandten Projekt:

Note for users building from source

If you have retreived a snapshot of rdesktop source, you will first need to run ./bootstrap in order to generate the build infrastructure. This is not necessary for release versions of rdesktop.

Quelle: bash: ./configure: No such file or directory

Und siehe da:

$ ./bootstrap
FATAL: Unable to locate dos2unix utility
./bootstrap: 38: exit: Illegal number: -1

Schon besser! Jetzt fehlte also noch das Debian-Paket dos2unix, und es konnte losgehen:

# apt-get install dos2unix

Anschliessend konnte ich ./configure ausführen (wie gewohnt musste ich dabei noch manuell die vorkonfigurierten MySQL-Libraries mit den MariaDB-Libraries ersetzen).

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 10. Juni 2018

Turris Omnia: Probleme mit pkgupdate debuggen

Link zu diesem Artikel

Mein Turris Omnia verwendet seit einiger Zeit das Kommandozeilentool pkgupdate, um sich zu aktualisieren (früher hatte diese Aufgabe offenbar ein Script namens updater.sh).

Gegen Ende dieser Woche wurde ich auf Grund eines nicht (mehr) existierenden Paketes regelmässig mit E-Mails eingedeckt, dass beim Update etwas fehlgeschlagen sein.

Beim Debuggen des Problems, welches ich in einem anderen Blog-Post beschreiben möchte, biss ich mir für einige Minute die Zähne an pkgupdater aus.

Gemäss Hilfe kann man mit dem Parameter -e die Verbosität des Tools einstellen:

$ pkgupdate --help
Usage: pkgupdate [OPTION]...
--help, -h			Prints this text.
--version, -V			Prints version of updater.
-R 			Use given path as a root directory. Consider also using --out-of-root option.
--batch				Run without user confirmation.
--state-log			Dump state to files in /etc/updater-state directory.
--ask-approval=	Require user's approval to proceed (abort if --approve with appropriate ID is not present, plan of action is put into the report-file if approval is needed)
--approve=			Approve actions with given ID (multiple allowed, from a corresponding report-file).
-s 		What level of messages to send to syslog.
-e 		What level of messages to send to stderr.
-S 		Under which name messages are send to syslog.
--task-log=		Append list of executed tasks into a log file.
--usign=			Path to usign tool used to verify packages signature. In default /usr/bin/usign.
--no-replan			Don't replan. Install everyting at once. Use this if updater you are running isn't from packages it installs.
--no-immediate-reboot		Don't reboot immediatelly. Just ignore immediate reboots. This is usable if you are not running on target machine.
--out-of-root			We are running updater out of root filesystem. This implies --no-replan and --no-immediate-reboot and is suggested to be used with -R option.

Doch was sind stderr Levels? Über eine Google-Suche stiess ich auch folgenden Kommentar zu einem völlig anderen Software-Produkt — sounds about right:

...
levels: {
  error: 3,
  warning: 4,
  notice: 5,
  info: 6,
  debug: 7,
},
...

Quelle: ‚debug‘ level is getting directed to stderr instead of stdout

debug war der Verbositäts-Level, welchen ich gesucht hatte. Versuchen wir es:

$ pkgupdate -e 7
DIE:Unknown log level 7
Aborted

Hmmm. Dann halt ausgeschrieben:

$ pkgupdate -e debug
DIE:Unknown log level debug
Aborted

Och Menno. Vielleicht dann alles in Grossbuchstaben?

$ pkgupdate -e DEBUG
DIE:Unknown log level DEBUG
Aborted

Himmelarsch! Zurück zu Google. Bei einem Gitlab-Checkin der Entwickler des Turris Omnia fand ich im Diff für das vorherige Script folgenden Hilfetext:

...
echo "-e (ERROR|WARNING|INFO|DBG|TRACE)	Message level printed on stderr. In default set to INFO."
...

Quelle: Store only single approved state

Somit lautet die korrekte Schreibweise:

# pkgupdate -e DBG

Und tatsächlich, damit klappte es.

Tags: , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 31. Mai 2018

Init7 TV7: Installation mit einem Ubiquiti Edgerouter X SFP

Link zu diesem Artikel

(Folgeartikel zum Artikel Init7 TV7: Installation mit einem Turris Omnia-Router)

An einem Zweitstandort betreibe ich einen Ubiquiti Edgerouter X SFP (Firmware v1.10.0) mit einem offiziellen FlexOptix-Transceiver von Fiber7. Damit dieser Router IPTV-Multicast ins LAN weiterleitet, waren folgende Anpassungen an der Konfiguration nötig (hat mich 90 Minuten meines Lebens gekostet):

Firewall

Auf rudimentärem Deutsch: Lasse IGMP sowie Multicast UDP durch die Firewall gegen das Internet

...
firewall {
    ...
    name WAN_IN {
        ...
        rule 4 {
            action accept
            description "Allow IGMP (max)"
            log disable
            protocol igmp
        }
        rule 5 {
            action accept
            description "Allow Multicast"
            destination {
                address 224.0.0.0/4
            }
            log disable
        }
    }
    name WAN_LOCAL {
        ...
        rule 4 {
            action accept
            description "Allow IGMP"
            log disable
            protocol igmp
        }
        ...
    }
    ...
}
...

IGMP Proxy

Auf rudimentärem Deutsch: Empfange IGMP-Traffic aus dem Internet und leite ihn in das LAN weiter.

...
protocols {
    igmp-proxy {
        interface switch0 {
            alt-subnet 0.0.0.0/0
            role downstream
            threshold 1
        }
        interface eth5 {
            alt-subnet 0.0.0.0/0
            role upstream
            threshold 1
        }
    }
    ...
}

Multicast-Status abfragen

Um zu überprüfen, ob Multicast grundsätzlich funktioniert, loggt man sich per SSH auf den Router ein und gibt im CLI folgende Befehle ein:

$ show ip multicast interfaces 
Intf             BytesIn        PktsIn      BytesOut       PktsOut            Local
switch0            0.00b             0       31.17MB         24316        Y.Y.Y.1
eth5             31.17MB         24316         0.00b             0   X.X.X.X
$ show ip multicast mfc
Group           Origin           In          Out                Pkts         Bytes  Wrong
239.254.127.63  Y.Y.Y.5        eth5        switch0               1       116.00b      1
239.255.255.250 Y.Y.Y.50       eth5        switch0              56       17.61KB     56
239.77.3.21     77.109.129.16    eth5        switch0           37379       47.91MB      0

Die letzte Zeile war das Resultat, dass ich probehalber Dracula Untold auf Film 4 geschaut habe …

Nachtrag 1: Stream friert ein

Nach der Installation der TV7-App auf dem Apple TV (eigener Blog-Artikel zur App) musste ich entdecken, dass das Bild eines TV-Senders jeweils nach etwas mehr als 3 Minuten einfror (ich tippte nach mehreren Messungen auf ein Timeout von 200 Sekunden — und somit ein strukturelles Problem).

Recht schnell realisierte ich nach etwas Googlen, dass die Firewall-Regel 4 unter WLAN_LOCAL zwingend auch aktiviert werden muss. Diese hatte ich ursprünglich als überflüssig erachtet. Mein Fehler.

Meine Vermutung als IPTV-Laie: Diese (zusätzliche) Regel erlaubt ausgehende IGMP-Pakete. Wenn diese nicht an TV7 gesendet werden können (Heartbeat?), stellt TV7 den Multicast wieder ein. Sobald die Firewall-Rule aktiviert wurde, entfror sich das Bild und die Sendung lief weiter.

Nachtrag 2: Multicast flutet das Netzwerk

Obwohl die Streams nun auf dem Apple TV mit der offiziellen App problemlos laufen, habe ich einen schwerwiegenden Nachteil entdeckt, welcher bei meinem Turris Omnia nicht auftritt: Schaut man mit dem Apple TV einen TV7-Stream, wird das ganze LAN mit Multicast-Paketen geflutet. Dies beeinflusst meinen UniFi Access Point besonders, konnte ich doch einen spürbaren Lag zwischen Tastendruck und Anzeige des Buchstabens auf dem Bildschirm feststellen, wenn ich von meinem MacBook per WLAN per SSH auf einem Laptop im LAN verbunden war.

In meiner derzeitigen Konfiguration sendet der Edgerouter den eingehenden Multicast-Traffic an alle LAN-Interfaces weiter, die am switch0 hängen. Leider habe ich bis jetzt noch keine Lösung gefunden, wie man das auf einzelne Ports einschränken kann (ich brauche eigentlich nur den Apple TV- sowie den Laptop-Port, auf welchem udpxy läuft) respektive wie man IGMP-Snooping aktivieren kann, damit der Edgerouter selber realisiert, welches Gerät/welche Geräte im Netzwerk aktuell gerade Multicast-Streams abspielen möchte.

Links

Tags: , , , , , , , , , , ,
Labels: IT, Linux, Medien, Schweiz

4 Kommentare | neuen Kommentar verfassen

Mittwoch, 23. Mai 2018

Init7 TV7: Beste inoffizielle IPTV-Applikation für Apple TV

Link zu diesem Artikel

(Folgeartikel zum Artikel Init7 TV7: Installation mit einem Turris Omnia-Router)

Init7 bietet zwar eine dedizierte Apple TV-App für TV7 an, doch bereits bei der Ankündigung befürchtete ich, dass die in unserem Haushalt nicht erhältlich sein wird: Wir haben einen Apple TV 4 mit 32GB-Speicher, das Gerät läuft aber auf die us-amerikanische Apple ID meiner Frau. Dementsprechend werden uns im App Store auch nur die weltweit verfügbaren und die für den us-amerikanischen Markt verfügbaren Apps angezeigt.

Keine Spur von der TV7 App:

Nach einigem Pröbeln entschied ich mich für den Kauf resp. die Installation folgender drei vier Apps:

  1. iPlayTV
  2. rIPTV
  3. GSE SMART IPTV
  4. TV Streams

Wichtiger Tipp

Es empfiehlt sich, den Direktlink auf die TV7-Kanalliste (tvchannels.m3u) mit dem iPhone als „Eingabetastatur“ in die Apple TV-Oberfläche einzugeben einzufügen (Copy & Paste) — sonst wird man wahnsinnig, bevor man das mit der Apple TV Remote bewerkstelligt hat.

iPlayTV

Apple App Store Link, Letztes Update: 4. Mai 2017 (!), Kaufpreis: $2.99

Meiner Meinung nach das beste GUI, aber die App funktioniert nicht: Die M3U-URL konnte ich zwar schnurstracks hinterlegen, die Sender werden aus der M3U-Datei ausgelesen und die bekannten darunter mit Logo der Sendestation versehen. Doch wenn ich irgendeinen Kanal auswähle, erscheint folgende Fehlermeldung:

Some problem happened while playing SRF1 HD

Ich habe darauf jede verfügbare Einstellung angepasst, doch schlussendlich gab ich auf: Mit iPlayTV kann man aus irgendeinem Grund keine TV7-Streams empfangen.

rIPTV

Apple App Store Link, Letztes Update: 3. Februar 2018, Kaufpreis: $2.99

Die Applikation meiner Wahl (weil ich es mit iPlayTV nicht hingekriegt habe). Das GUI schaut ebenfalls sehr benutzerfreundlich aus, und ist es auch — iPlayTV wäre aber ein Mü hübscher.

Mit dieser App hatte ich anfänglich das Problem, die M3U-Kanalliste mittels Direktlink einzulesen — das funktioniert irgendwie einfach nicht:

Schlussendlich musste ich mir auch noch die iPhone-App kaufen, die Senderliste mittels der URL importieren (auf dem Smartphone funktioniert es!) und diese dann mittels Fast Load (YouTube-Anleitung) auf den Apple TV pushen.

Seither funktioniert alles Bestens und ich kann mit der App jeden Sender schauen.

Vorteile: Sender-Logos der bekannten (und von TV7 „richtig“ benannten TV-Sendern) werden erkannt, heruntergeladen und angezeigt. Auch holt sich die App von irgendwo aus dem Internet den EPG und zeigt diesen — falls für den Sender verfügbar — automatisch an.

Nachteil: Ändert TV7 dereinst die IPs oder Ports seiner Sender, muss ich das ganze Import und Fast Load-Prozedere erneut durchkauen — und alle Favoriten neu setzen.

GSE SMART IPTV

Apple App Store Link, Letztes Update: 21. Mai 2018, Kaufpreis: Gratis (limitierte Version; mit In-App-Käufen aufrüstbar — oder direkt für $4.99 als Pro-Version kaufen)

Die App sieht schlicht zum Kotzen aus — als hätte sie ein junger, pickliger Bill Gates im Hinterhof zusammengeschustert. Ein solches GUI würde man am ehesten in einer H4x0r/Cracker-Schattenwelt erwarten.

So hässlich die Applikation daherkommt — es war die einzige, die mit dem M3U-Direktlink auf Anhieb funktionierte. Und: Sie erlaubt es sogar, Streams direkt auf den Apple TV aufzunehmen, falls der freien Festplattenplatz aufweist.

TV Streams

Apple App Store Link, Letztes Update: 17. Mai 2018, Kaufpreis: $2.99, Offizielle Homepage

NOCH NICHT AUSPROBIERT

Video-Tutorial, um M3U-Listen hinzuzufügen

Links

Tags: , , , , , ,
Labels: Apple, IT, Linux, Medien, Schweiz

2 Kommentare | neuen Kommentar verfassen

Mittwoch, 23. Mai 2018

Init7 TV7: Installation mit einem Turris Omnia-Router

Link zu diesem Artikel

Gestern liessen Fredy Künzler und seine Init7 die Überraschungsbombe platzen: Ab sofort gibt es TV7, das IPTV-Angebot des ISPs, für alle Fiber7-Kunden kostenlos zum spotgünstigen, symmetrischen 1 Gbit/s Internetabo hinzu:

Medienmitteilung vom 22. Mai 2018

Das bedeutet, dass ich nun über eine 1 GBit/s-Leitung feinste, unkomprimierte HD-Streams aller hierzulande gängigen und einiger eher exotischer Sender empfangen kann — derzeit 215 an der Zahl.

Wieso gerade jetzt? Aus meiner Sicht aus zwei Gründen: Erstens steht die Fussball-WM 2018 vor der Tür, wo man mit einem unkomprimierten Multicast-Stream die Überlegenheit über die Konkurrenz demonstrieren kann (fünf Sekunden vor dem Nachbarn das entscheidende Goal im Final sehen? Check.). Andererseits, weil Salt kürzlich mit seinem (geschwindigkeitstechnisch fragwürdigen) Fiber-Angebot Furore in den Medien gemacht hat, und dort auch IPTV draufpackt (inkl. schicker Integration in iOS).

Installation

Am Abend zog ich zu Hause die Bastelhandschuhe an und machte mich daran, die von TV7 ausgesendeten UDP Multicast-Streams über meinen Router ins interne Netzwerk zu transportieren.

Dank der vom ISP netterweise verfassten Anleitung für den Fiber7-Router meiner Wahl, den Turris Omnia, war das ein Klacks:

Anleitung Fiber7 TV7

Kurz zusammengefasst:

  1. In LuCI einloggen und unter System > Software das Softwarepaket igmpproxy installieren. Hierzu musste ich zuerst einmalig Update lists anklicken, und danach in das Suchfeld Filter den Namen des Pakets eingeben. Noch Find Package klicken und dann in der linken Spalte den Link Install anwählen.
  2. Per SSH auf die Kommandozeile des Routers einloggen und die Konfigurationsdatei unter /etc/config/igmpproxy anpassen (s. unten). Daraus wird dann /var/etc/igmpproxy.conf generiert
  3. In LuCI unter System > Startup igmpproxy auf enabled schalten und einmal start (resp. bei mehrmaligen Versuchen restart) drücken
  4. Per SSH auf der Kommandozeile des Routers mittels ps | grep -i igmp überprüfen, dass der Prozess läuft: 
     6728 root       804 S    /usr/sbin/igmpproxy /var/etc/igmpproxy.conf

/etc/config/igmpproxy

config igmpproxy
	option quickleave 1

config phyint wan
	option network wan
	option direction upstream
	list altnet 0.0.0.0/0

config phyint lan
	option network lan
	option direction downstream

Init7 empfiehlt einen Reboot, welchen ich schlussendlich doch noch durchgeführt habe, aber nur, weil etwas mit dem Test-Stream (s. unten) nicht funktioniert hat. Ich kann mir vorstellen, dass der Router Multicast auch ohne Reboot hinkriegt, lasse mir aber gerne das Gegenteil bestätigen.

Test

Um möglichst viele potentiell störenden Parameter auszuschliessen, schloss ich mein MacBook 12″ mittels eines USB-C-auf-Ethernet-Adapters direkt an einen Ethernet-Port des Routers an. So schliesse ich aus, dass Switches zwischen dem Endgerät und dem Router Multicast vermüeseln (mein 8-Port UniFi- und mein 16-Port TP-LINK Gigabit-Switch funktionieren tadellos, ohne irgendwelche Konfiguration).

Anschliessend wollte ich den Empfang mit dem im FAQ-Artikel „Kann ich vorab testen, ob mein Router TV7 (Multicast) unterstützt?“ verlinkten Stream auf den Big Buck Bunny (Bedeutung) testen. Doch leider kriege ich diesen Stream bis heute nicht zu laufen — weshalb ich gestern zuerst auf ein Konfigurationsproblem tippte und deshalb den Router doch noch einem Kaltstart unterzog (ich bin mir fast sicher, dass das nicht nötig gewesen wäre).

Nachdem ich mir sicher war, dass igmpproxy sauber läuft, entschloss ich mich schlussendlich, einfach die im FAQ-Artikel „Kann ich TV7 auch auf anderen Geräten als Apple TV anschauen?“ erwähnte M3U-Datei herunterzuladen und in VLC 3.0.2 zu öffnen. Und siehe da: Wenige Sekunden später, nach nicht einmal 30 Minuten Installationsdauer, sah ich die Tagesschau gestochen scharf in höchster Auflösung auf dem Retina-Display meines MacBooks entgegenflimmern:

Tags: , , , , , , , , , , , ,
Labels: IT, Linux, Medien

2 Kommentare | neuen Kommentar verfassen

« Older Entries
Newer Entries »