Muzyka z YouTube w konsoli

Na YouTube można w prosty sposób znaleźć sporo różnej muzyki i obecnie jest to mój wybór numer jeden, jeśli chodzi o muzykę z sieci[1]. Odtwarzanie YouTube w przeglądarce jest oczywistym wyborem w przypadku filmów. Jeśli jednak zależy nam tylko na audio, czyli np. słuchamy w pracy, to odtwarzanie w przeglądarce tylko przeszkadza. Niepotrzebnie obciążamy i sieć, i CPU, i RAM.

Niedawno znalazłem program mps-youtube, który jest napisany w Pythonie i który stawia sobie za cel obsługę YouTube w konsoli. Można m.in. wyszukiwać utwory, dodawać URLe, tworzyć lokalne playlisty, a także pobierać muzykę w określonym formacie na dysk. Opis mówi, że można też importować istniejące playlisty z YouTube, ale tej funkcjonalności jeszcze nie testowałem. Całość pomyślana w taki sposób, aby można było dowiedzieć się wszystkiego z samej aplikacji, bez konieczności czytania manuali. Sam program przychodzi z sensownymi ustawieniami domyślnymi.

Pomoc programu mps-youtube
Pomoc programu mps-youtube – screenshot

Wersja z Jessie 0.01.46-3 jest o wiele starsza, niż dostępna w unstable 0.2.5-5, ale… obie wersje mają błędy, niestety i bywa, że jedna wersja potrafi otworzyć dany URL, a druga nie. Na GitHubie dostępna jest wersja 2.6, ale jeszcze nie testowałem. W pracy, gdzie słucham najwięcej (niby leci jakieś radio ogólnie, ale słaba muza, w kółko te same utwory, dużo reklam, poza tym, „uroki” openspace…), wystarcza mi wersja z Jessie. Niemniej nadal polecam przymiarkę do programu.

Wyniki wyszukiwania w mps-youtube
Wyniki wyszukiwania w mps-youtube. Źródło: strona projektu.

Lokalna playlista mps-youtube
Lokalna playlista w mps-youtube. Źródło: strona projektu.

Niby działa na dowolnym systemie operacyjnym, ale z racji trybu obsługi (konsola) wróżę popularność raczej na Linuksie i wśród geeków. Dla porządku: wymaga mplayera lub mpv, z których korzysta do odtwarzania muzyki.

[1] Jak widać, opisywane kiedyś słuchanie radia w konsoli się nie sprawdziło, podobnie jak wykorzystanie mpd. Łatwe tworzenie playlist z dostępnych od ręki zasobów jednak wygrywa.

Automatyczne pobieranie kontaktu abuse dla domeny lub adresu IP

Zawsze miałem problem z szukaniem właściwego kontaktu abuse. No może problem to za dużo powiedziane, ale szukanie ręcznie, w hurtowych ilościach to nie jest nic ciekawego. Poza tym, jeśli chcemy zgłaszać automatycznie, to szukanie ręcznie odpada. A w danych whois były cuda, więc parsowanie tego byłoby wyzwaniem… Stosunkowo niedawno RIPE zrobiło jako taki porządek i pojawiły się pola abuse-c. Jednak już wcześniej znalazłem abusix i ich projekt Abuse Contact DB. Pozwala na wygodne odpytywanie o kontakty abuse przy pomocy DNS, więc szybko, prosto i wygodnie.

Trochę, żeby ułatwić życie kolegom, a trochę, żeby automatycznie zgłaszać nadużycia (np. próby włamań po SSH) ze swoich hostów, popełniłem funkcję w Perlu[1], która zwraca pierwszy email z listy, na podstawie ww. bazy. W międzyczasie zająłem się czym innym, znalazłem serwis, który rozwiązał temat automatycznego raportowania prób włamania. Temat więc trochę umarł. Przynajmniej do wczoraj/przedwczoraj, kiedy znalazłem ten wpis i dowiedziałem się, że najprawdopodobniej nikt nie powiadomił firm hostujących. Plus zwykła ciekawość: a gdzie te skompromitowane hosty leżą? Z potrzeby chwili i własnej ciekawości skleciłem skrypt, który bierze domenę (czyli adres strony), sprawdza jego IP (dokładniej: rekord A) i ustala stosowny adres email do kontaktu z abuse.

Wynik działania dla domen .pl jest tu, a wynik działania dla całej listy tu. Skrypt jest zdecydowanie do poprawienia i rozwoju. W tej chwili nie zwraca nic przy braku kompletu danych, czyli brak obsługi błędów, jest wolny, bo działa sekwencyjnie, nie jest to czysty Perl, nie obsługuje IP (ani IPv6 czyli rekordów AAAA), grupowania domen/IP po kontakcie abuse (żeby nie słać wielu maili na ten sam adres) i wysyłki maili, ale leci na GitHuba. W ramach motywatora. 😉 Może kiedyś przyda się komuś, kto znajdzie jakiś malware…

TIL: istnieje oficjalne narzędzie w Pythonie, obsługujące bazę danych abuse; działa zarówno dla IPv4 jak i IPv6 (ale nie obsługuje domen). Generalnie robi to, co moja pierwotna funkcja w Perlu, tylko trochę lepiej. Mam wrażenie, że jak wtedy patrzyłem na tę stronę, to go nie było…

PS Z różnych źródeł wiem, że większe polskie hostingi są już powiadomione, nie ma potrzeby wysyłania maili. 😉 Warto natomiast zobaczyć, czy nie ma na liście strony własnej/znajomych. Problem leży tak naprawdę po stronie użytkownika hostingu i  jego niezaktualizowanej aplikacji, więc tylko on może go tak naprawdę rozwiązać.

[1] Teraz widzę, że funkcja nie jest w czystym Perlu, tylko wywołuje zewnętrzny program host, poprawię wkrótce.

Wicd nie startuje w Debianie – problem z Pythonem.

Ostatnio wicd mi się w Debianie znarowiło – nie wstawał klient GTK. Wersja curses działała OK, więc nie wykazałem się należną czujnością i  zignorowałem problem. Zorientowałem się dość późno, bo korzystam z hibernacji głównie, a efektem był brak sieci WiFi po restarcie (no dobrze, skrót myślowy, nie tyle brak sieci, bo wpa_supplicant z ręki daje radę, co niestartowanie wicd). W każdym razie uruchomienie wicd dawało:

 Traceback (most recent call last):
File "/usr/share/wicd/daemon/wicd-daemon.py", line 47, in
import dbus
File "/usr/lib/python2.7/dist-packages/dbus/__init__.py", line 100, in
from dbus._dbus import Bus, SystemBus, SessionBus, StarterBus
File "/usr/lib/python2.7/dist-packages/dbus/_dbus.py", line 46, in
from dbus.bus import BusConnection
File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 46, in
from dbus.connection import Connection
File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 42, in
from dbus.proxies import ProxyObject
File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 35, in
from dbus._expat_introspect_parser import process_introspection_data
File "/usr/lib/python2.7/dist-packages/dbus/_expat_introspect_parser.py", line 26, in
from xml.parsers.expat import ExpatError, ParserCreate
File "/usr/lib/python2.7/xml/parsers/expat.py", line 4, in
from pyexpat import *
ImportError: /usr/lib/python2.7/lib-dynload/pyexpat.so: undefined symbol: XML_SetHashSalt

W ramach zmyłki – w pakiecie wicd błąd nie jest zgłoszony (i słusznie), za to zgłoszony jest błąd 665346 w Pythonie. I faktycznie, upgrade libexpat1 do 2.1~beta3 (wersja z unstable) pomaga. HTH