Jak nie zainstalowałem Google Hangouts w Debianie Wheezy

Z własnej nieprzymuszonej woli bym z Google Hangouts nie skorzystał, bo jeśli już muszę korzystać z niewolnych wynalazków, to mam Skype od Microsoftu, ale w pracy była potrzeba skontaktowania się grupowo, grupa już ma wybrane rozwiązanie i używa Hangouts, więc… co może pójść źle? System to Debian Wheezy plus backporty, czyli nic nietypowego czy niestabilnego. Skype od Microsoft daje gotową paczkę deb, co prawda multiarch, a nie natywne amd64, ale działa bez problemu, po dodaniu architektury i386. Google ma opinię firmy bardziej przyjaznej Linuksowi, poza tym na rynek weszli później, więc pewnie bardziej się starają.

Oczywiście wszedłem na stronę Google Hangouts z Iceweasel, czyli Firefoksa. Są wersje dla mobilków, jest pobierz na swój komputer. Klikam… i komunikat, że ta przeglądarka się nie nadaje, pobierz sobie Chrome. Czyli nie wersja Hangouts na komputer, tylko jako dodatek do przeglądarki. Pod pewnymi względami może to mieć nawet sens, zresztą mam Chromium (opensource’owa wersja Chrome), co mi szkodzi wrzucić tam Hangouts? Odpalam Chromium, strona Google Hangouts i… link do wersji „stacjonarnej” nie jest aktywny.

No dobrze, wiem, że dają działającą paczkę z Chrome, więc chociaż nie potrzebuję tej przeglądarki, to mogę ją zainstalować i tylko do tego jednego celu mogę jej używać. Instalacja Chrome bez problemu (nie, nie będzie domyślną przeglądarką w systemie…), wchodzę na stronę Hangouts, dodał appkę. Uruchamiam i… chat działa, ale w momencie kliknięcia rozmowy video (znaczy audio/video, samego audio chyba się nie da, choć by wystarczyło…) nie uruchamia jej w Chrome, tylko… próbuje uruchomić w Iceweasel, który jest domyślną przeglądarką. Tym razem jednak proponuje pobranie pluginu w postaci paczki deb. Nie można tak było od razu? Pobieram oferowany plugin, instaluję i…

dpkg: problemy z zależnościami uniemożliwiają skonfigurowanie pakietu google-talkplugin:
google-talkplugin zależy od libc6 (>= 2.14); jednakże:
Wersją libc6:amd64 w systemie jest 2.13-38+deb7u8.

Brawo Google!

Źródło: http://gifrific.com/wp-content/uploads/2012/04/joker-clap-hq.gif

Oczywiście problemu pewnie by nie było, gdyby Chrome był domyślną przeglądarką w systemie, ale nie ze mną te numery, Brunner^HGoogle. Skończyło się odinstalowaniem i Chrome, i nieszczęsnego pluginu na podstawowym systemie. Oczywiście za tydzień problemu pewnie nie będzie, bo najprawdopodobniej Jessie będzie stable, ale póki co – nie da się w rozsądny sposób korzystać z Hangouts pod stabilnym Debianem.

Oczywiście z tym nie zainstalowałem z tytułu lekko przesadzam[1], bo nie kijem go, to pałką i skończyło się szybkim postawieniem osobnej wirtualki (AQEMU, KVM) tylko pod Hangouts. Ale faktem jest, że w podstawowym systemie poległem.

Pozytyw całej akcji jest taki, że przetestowałem instalator Jessie (rc2). Jest parę fajnych opcji, choćby wybór, które dokładnie środowisko chcemy zainstalować (jest LXDE i działa w zasadzie od kopa – jedyna rzecz, która wymagała interwencji to wyciszony mikrofon – musiałem doinstalować jakiś xfce4-mixer, który chyba zresztą jakoś nie zapamiętuje ustawień. Potem się przyjrzę dokładniej, podobnie jak udostępnieniu wbudowanej kamery do wirtualki…

[1] Pierwotnie w tytule nie było nic o wersji Debiana.

Microsoft blokuje No-IP

Krótka lekcja nt. neutralności sieci w praktyce. Zaglądając na stronę popularnego operatora domen, w szczególności jednego z bardziej znanych dostawców darmowych domen dla osób z dynamicznym IP, można dziś zobaczyć taki komunikat:

 No-IP warning

Pod pretekstem wykorzystywania domen przez twórców malware (co z pewnością miało miejsce, malware korzysta z czego się da…), na mocy nakazu sądowego, Microsoft zajął 22 domeny. Zgodnie z tym, co pisze No-IP, nie było żadnego wcześniejszego kontaktu w celu usunięcia „złych” domen. Co ciekawe, No-IP utrzymuje aktywny zespół abuse, ma surową politykę przeciwko nadużyciom i… ma historię dobrej współpracy z Microsoftem w reagowaniu na podobne nadużycia.

Najwyraźniej komuś nie zależało, by z tego skorzystać. Duży może więcej.

Poniżej kopia oświadczenia wydanego przez No-IP w tej sprawie (stan na godzinę 8:00):

We want to update all our loyal customers about the service outages that many of you are experiencing today. It is not a technical issue. This morning, Microsoft served a federal court order and seized 22 of our most commonly used domains because they claimed that some of the subdomains have been abused by creators of malware. We were very surprised by this. We have a long history of proactively working with other companies when cases of alleged malicious activity have been reported to us. Unfortunately, Microsoft never contacted us or asked us to block any subdomains, even though we have an open line of communication with Microsoft corporate executives.

We have been in contact with Microsoft today. They claim that their intent is to only filter out the known bad hostnames in each seized domain, while continuing to allow the good hostnames to resolve. However, this is not happening. Apparently, the Microsoft infrastructure is not able to handle the billions of queries from our customers. Millions of innocent users are experiencing outages to their services because of Microsoft’s attempt to remediate hostnames associated with a few bad actors.

Had Microsoft contacted us, we could and would have taken immediate action. Microsoft now claims that it just wants to get us to clean up our act, but its draconian actions have affected millions of innocent Internet users.

Vitalwerks and No­-IP have a very strict abuse policy. Our abuse team is constantly working to keep the No-­IP system domains free of spam and malicious activity. We use sophisticated filters and we scan our network daily for signs of malicious activity. Even with such precautions, our free dynamic DNS service does occasionally fall prey to cyber scammers, spammers, and malware distributors. But this heavy-handed action by Microsoft benefits no one. We will do our best to resolve this problem quickly.

UPDATE: Wpis dotyczący sprawy na blogu no-ip.com został parę razy zaktualizowany. Z tego co zauważyłem, moje domeny zaczęły działać wczoraj, czyli downtime w granicach 36h. Zdarzenie jest przykładem kluczowej roli DNS (domeny, serwery), a w kontekście bezpieczeństwa warto zwrócić uwagę na to, z jakich domen się korzysta.

Happy eyeballs wg Microsoft, czyli implementacja IPv6 w Windows 8.

Nietypowo nie będzie o Linuksie, a o Windows, który bardzo rzadko pojawia się na tym blogu.  Konkretnie o Windows 8 i IPv6.

Przy okazji wykładu na PLNOG na temat happy eyeballs[1] dowiedziałem się, jak to robią w Windows 8. Otóż Windows 8 określa, czy ma dostęp do sieci IPv6 poprzez pobranie pliku. Z serwera Microsoft[2]. A następnie cache’uje wynik na… bagatela 30 dni. Wystarczy, że w momencie sprawdzania sieć IPv6 albo serwer Microsoftu nie będą dostępne i żegnamy się z IPv6. Na miesiąc. Poza tym, to, że udało się połączyć z serwerem Microsoft nie oznacza, że istnieją trasy do wszystkich innych hostów IPv6. Więc rozwiązanie „takie sobie” (taki ładny eufemizm, zamiast sporej ilości przekleństw w kierunku twórców pseudostandardów w Microsoft).

W trakcie prezentacji przyszedł mi do głowy dirty hack (rozmowa po prezentacji sugeruje, że jak najbardziej powinien działać), który spowoduje, że system Windows będzie zawsze myślał, że ma dostęp do sieci IPv6. Do pliku hosts dopisujemy linię, która powoduje, że ipv6.msftncsi.com jest rozwiązywany na adres IPv4. Czyli plik jest pobierany z serwera IPv4, czyli system zawsze będzie próbował korzystać z IPv6. Tak, popsuje to mechanizm happy eyeballs (ale i tak był zepsuty). Może się przydać np. testerom, albo zwyczajnym fan(atyk)om IPv6.

Przy okazji, w prezentacji pojawia się Your task – check ipv6.msftncsi.com availability, które po sprawdzeniu pachnie mi lekkim FUDem. Przy sprawdzeniu co pięć minut dwóch rzeczy: pingowania po domenie i możliwości pobrania pliku, w ciągu 48h[3] nie zdarzył mi się ani jeden błąd. A dodatkowo sprawdzam przez tunel od HE, czyli potencjalny element, który może zawieść. Być może wyglądało to kiedyś gorzej i się poprawiło. To, że coś jest potencjalnie OKDR nie oznacza, że jest takie w praktyce. Bo wydaje się działać. Zresztą wystarczy zrobić farmę serwerów z adresem anycast i będzie to działać. Warto też sprawdzić:

host ipv6.msftncsi.com
ipv6.msftncsi.com is an alias for ipv6.msftncsi.com.edgesuite.net.
ipv6.msftncsi.com.edgesuite.net is an alias for a978.i6g1.akamai.net.
a978.i6g1.akamai.net has IPv6 address 2001:2030:0:f::d59b:9892
a978.i6g1.akamai.net has IPv6 address 2001:2030:0:f::d59b:9888

Czyli nie tyle serwery Microsoft, co Akamai (pozdrowienia dla f.). Nie jedno, ale 2 IP. Prawie na pewno rozproszone geograficznie i z wykorzystaniem anycastu. Nie zmienia to faktu, że dostępność tych IP nie oznacza dostępności po IPv6 każdego innego hosta („dziury” w routingu).

Źródła:

1. Prezentacja Krzysztofa Mazepy z EURONOG I PLNOG 2012 pt. IPv4 vs IPv6 IPv4 vs. – Happy Eyeballs.
2. Windows 8 moves to IPv6 Internet.

[1] Jest tylko po angielsku, więc w telegraficznym skrócie dla niespikających: w momencie połączenia host próbuje się łączyć po IPv6 i IPv4, jeśli ma łączność o zbliżonym opóźnieniu po obu protokołach, to preferuje IPv6. Zaleta jest taka, że w przypadku braku dostępności IPv6 nie czeka kilku(nastu/dziesięciu) sekund na timeout – użytkownik dostaje praktycznie bez opóźnienia content i oczka się cieszą.

[2] Konkretnie http://ipv6.msftncsi.com/ncsi.txt Zawartość jest stała i jest to po prostu Microsoft NCSI Jak widać wyżej, serwer jest Akamai.

[3] Tak, wiem, bardzo mała próbka, będzie aktualizowane wyniki z dłuższego okresu poniżej.

PS Kiedyś opisywałem, jak sprawdzić IP komputera pod różnymi systemami. Dodałem informację o sprawdzaniu łączności po IPv6.

UPDATE: Miała być statystyka z dłuższego okresu, to będzie. Minęło 16 dni. W tym czasie, przy sprawdzeniach co 5 minut, zanotowałem 75 braków odpowiedzi na ping i 26 błędów w pobraniu pliku przez WWW. Ale! Co minutę sprawdzam też, czy drugi koniec tunelu się pinguje po IPv6. Po wyeliminowaniu równoczesnego braku odpowiedzi z końca tunelu i błędów do hosta MS, zostało 49 błędów pingowania i 0 (zero) błędów pobrania pliku przez WWW. Czyli raczej błędy tunelu, niż rozwiązania MS. Jakby się ktoś zastanawiał, jak to możliwe, że plik się pobrał, przy braku odpowiedzi na ping do hosta – zapewne kwestia dłuższego timeoutu.