Md at debian.org

tales of a debian maintainer

L'inaffidabile rete di Telecom Italia

Da venerdì mattina fino almeno a tutto oggi pomeriggio è ricomparso il solito problema che impedisce a certi clienti di Telecom Italia di accedere a certi siti: per esempio un utente con una ADSL Alice non riesce a scaricare la posta dal proprio server in un data center.

Ho visto questo tipo di guasto molte volte, la prima il 5 febbraio 2014: si manifesta sempre con un cliente di Telecom Italia che non riesce a raggiungere uno specifico IP "esterno", ma non ha problemi per esempio a raggiungere l'IP adiacente attivo sullo stesso server. Allo stesso modo l'IP "esterno" è normalmente raggiungibile dagli altri clienti di Telecom Italia.

In tutti i casi che ho analizzato, confrontando i traceroute fatti verso un IP funzionante e uno non raggiungibile, si vede sempre che il traffico in uscita si ferma al confine tra la rete nazionale di Telecom Italia (AS3269) e il loro carrier globale Telecom Italia Sparkle (AS6762). Lo stesso comportamento mi è stato confermato dai colleghi di almeno tre altri operatori, quindi so che non dipende da specificità della mia rete. La rete nazionale di Telecom Italia è interconnessa al mondo esterno solo mediante Telecom Italia Sparkle, quindi il problema si verifica anche comprando direttamente transito da TIS.

Considerando la frequenza e la durata di questi guasti, a quanto pare non esiste un modo per avere connettività affidabile verso le ADSL di Telecom Italia, cioè il 51% degli utenti consumer italiani, che non sia comprare transito o peering dallo stesso AS3269. Sarei felice di essere smentito.

Per approfondire questi temi segnalo la mia presentazione sulle interconnessioni tra le reti italiane, disponibile anche in una versione per gli stranieri con qualche aggiornamento recente.

My position on the "init system coupling" General Resolution

I first want to clarify for the people not intimately involved with Debian that the GR-2014-003 vote is not about choosing the default init system or deciding if sysvinit should still be supported: its outcome will not stop systemd from being Debian's default init system and will not prevent any interested developers from supporting sysvinit.

Some non-developers have recently threatened of "forking Debian" if this GR will not pass, apparently without understanding well the concept: Debian welcomes forks and I think that having more users working on free software would be great no matter which init system they favour.

The goal of Ian Jackson's proposal is to force the maintainers who want to use the superior features of systemd in their packages to spend their time on making them work with sysvinit as well. This is antisocial and also hard to reconcile it with the Debian Constitution, which states:

2.1.1 Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. [...]

As it has been patiently explained by many other people, this proposal is unrealistic: if the maintainers of some packages were not interested in working on support for sysvinit and nobody else submitted patches then we would probably still have to release them as is even if formally declared unsuitable for a release. On the other hand, if somebody is interested in working on sysvinit support then there is no need for a GR forcing them to do it.

The most elegant outcome of this GR would be a victory of choice 4 ("please do not waste everybody's time with pointless general resolutions"), but Ian Jackson has been clear enough in explaining how he sees the future of this debate:

If my GR passes we will only have to have this conversation if those who are outvoted do not respect the project's collective decision.

If my GR fails I expect a series of bitter rearguard battles over individual systemd dependencies.

There are no significant practical differences between choices 2 "support alternative init systems as much as possible" and 3 "packages may require specific init systems if maintainers decide", but choice 3 is more explicit in supporting the technical decisions of maintainers and upstream developers.

This is why I think that we need a stronger outcome to prevent discussing this over and over, no matter how each one of us feels about working personally on sysvinit support in the future. I will vote for choices 3, 2, 4, 1.

The Italian peering ecosystem

I published the slides of my talk "An introduction to peering in Italy - Interconnections among the Italian networks" that I presented today at the MIX-IT (the Milano internet exchange) technical meeting.

15 years of whois

Exactly 15 years ago I uploaded to Debian the first release of my whois client.

At the end of 1999 the United States Government forced Network Solutions, at the time the only registrar for the .com, .net and .org top level domains, to split their functions in a registry and a registrar and to and allow competing registrars to operate.

Since then, two whois queries are needed to access the data for a domain in a TLD operating with a thin registry model: first one to the registry to find out which registrar was used to register the domain, and then one the registrar to actually get the data.

Being as lazy as I am I tought that this was unacceptable, so I implemented a whois client that would know which whois server to query for all TLDs and then automatically follow the referrals to the registrars.

But the initial reason for writing this program was to replace the simplistic BSD-derived whois client that was shipped with Debian with one that would know which server to query for IP addresses and autonomous system numbers, a useful feature in a time when people still used to manually report all their spam to the originating ISPs.

Over the years I have spent countless hours searching for the right servers for the domains of far away countries (something that has often been incredibly instructive) and now the program database is usually more up to date than the official IANA one.

One of my goals for this program has always been wide portability, so I am happy that over the years it was adopted by other Linux distributions, made available by third parties to all common variants of UNIX and even to systems as alien as Windows and OS/2.

Now that whois is 15 years old I am happy to announce that I have recently achieved complete world domination and that all Linux distributions use it as their default whois client.

CVE-2014-6271 fix for Debian woody, sarge, etch and lenny

Very old Debian releases like woody (3.0), sarge (3.1), etch (4.0) and lenny (5.0) are not supported anymore by the Debian Security Team and do not get security updates. Since some of our customers still have servers running these version, I have built bash packages with the fix for CVE-2014-6271 (the "shellshock" bug) and Florian Weimer's patch which restricts the parsing of shell functions to specially named variables:

http://ftp.linux.it/pub/People/md/bash/

This work has been sponsored by my employer Seeweb, an hosting, cloud infrastructure and colocation provider.

Censurato in Italia mail.ru

Dopo la censura nel novembre 2013 di vk.com, il più grande social network russo, un altro importante sito russo è stato censurato in Italia: si tratta di mail.ru, il più grande portale del Paese e uno dei principali mail service provider del mondo.

Il decreto di sequestro è stato inviato ai principali provider di accesso italiani da un GIP di Roma, ed è motivato dalla pubblicazione illecita di due film. Tra gli altri 24 siti censurati con questo provvedimento c'è mega.co.nz, il popolare cyberlocker che ha sostituito MegaUpload.

Come al solito in Italia c'è l'abitudine di censurare importanti siti stranieri senza preoccuparsi dei danni collaterali. Come al solito si ordina di censurare un sito web ma vengono bloccati anche tutti gli altri servizi, come la posta. Come al solito la vittima del sequestro anomalo non è stata notificata, infatti i loro tecnici questa mattina cercavano di contattare colleghi italiani per capire cosa fosse successo...

L'elenco non ufficiale ma completo dei siti censurati in Italia è sempre disponibile sul mio sito http://censura.bofh.it/elenchi.html.

Aggiornamento del 19 luglio: me ne sono accorto solo ora, ma falsificando in questo modo le risposte per il dominio mail.ru viene impedito anche il funzionamento di ICQ, perché il dominio icq.com usa gli stessi name server.

libero.it colpito dagli stessi spammer di AOL e Yahoo?

La settimana scorsa libero.it ha modificato la propria policy SPF in hardfail: questo in pratica significa che non è più possibile inviare posta con mittente @libero.it (per la precisione: envelope sender) mediante mail server terzi.

SPF impedisce anche il forwarding da un account a un altro di messaggi con mittente @libero.it:è una delle sue principali limitazioni e il motivo per cui la sua diffusione è relativamente bassa.

È lecito ipotizzare che questo sia la risposta alla recente campagna di spam inviato da mittenti @libero.it falsificati a indirizzi nelle loro rubriche. Si tratta dello stesso tipo di spam che nei mesi scorsi ha colpito duramente AOL e Yahoo, costringendoli ad adottare una policy DMARC con p=reject.

Non è noto come gli spammer siano venuti in possesso delle rubriche di questi utenti di Libero, ma nel caso di AOL era stata confermata una intrusione.

AOL e Yahoo hanno risolto il problema con p=reject, al prezzo di rendere impossibile ai loro utenti attività come partecipare a mailing list. Al momento Libero nemmeno firma con DKIM e quindi non può adottare la stessa strategia: vedremo cosa succederà in futuro, ma se si accodassero anche loro sarebbe una enorme novità nel panorama italiano dell'email.

Background:

Inizia la censura di AGCOM

L'ormai famigerato Regolamento in materia di tutela del diritto d'autore sulle reti di comunicazione elettronica è entrato in vigore, e negli ultimi giorni AGCOM ha iniziato a inviare richieste di censurare siti web ritenuti di violare il diritto d'autore.

Ho scritto inviare perché la modalità scelta da AGCOM per notificare gli ISP di questi obblighi è l'invio mediante Posta Elettronica Certificata di file PDF contenenti le scansioni timbrate e firmate delle relative delibere.

Bontà loro, hanno allegato anche un file con l'elenco completo dei domini da censurare, per evitare di doverli ricopiare a mano, però l'interpretazione comune è che facciano fede solo le delibere ai fini legali.

Questi file però sono un po' problematici, perché:

E per non farsi mancare nulla, la seconda versione del file ha già un formato diverso da quello della prima.

Tutto questo suggerisce che chi ha preparato i file non abbia molta familiarità con le tecnologie di Internet, che è un po' preoccupante considerato il mandato istituzionale di AGCOM.

Naturalmente questo formato non è stato documentato: dovrebbe esistere un tavolo tecnico per discutere queste e molte altre cose, ma non è ancora stato convocato.

Chi fosse interessato può trovare una implementazione preliminare che gestisce questa cosa nel mio kit censura, che contiene i programmi usati da molti ISP italiani per gestire la censura di Internet.

L'elenco dei domini censurati da AGCOM è reperibile come al solito sul mio sito.

Quality of Service in Internet: giusta o sbagliata?

È giusto che un operatore possa decidere di fare passare sulla propria rete certi pacchetti prima che altri, anche se arrivati prima al router?

Per rispondere è indispensabile chiarire in quale punto si sceglie di prioritizzare un certo tipo o sorgente di traffico (la differenza tra, per esempio, "tutto il traffico video" e "i video di Netflix") rispetto ad altri tipi. Le possibilità, non mutualmente esclusive, sono:

Ovviamente non ha senso fare QoS in un peering con Netflix (lo cito spesso perché è un buon esempio, ma si può sostituire con Google, Akamai, eccetera), se non altro perché il traffico è omogeneo (tutto video, tutto da loro) e quindi non può essere prioritizzato rispetto ad altri tipi/sorgenti.

Non credo che abbia senso fare QoS sulle interconnessioni tra un grande carrier e un operatore di accesso (per esempio, tra Level 3 e Telecom Italia) per prioritizzare certo traffico a scapito del resto (per esempio, la CDN di Level 3, o alcuni loro clienti): se si è tutti d'accordo per fornire un buon servizio si dimensioneranno i circuiti in modo che non ci sia congestione e quindi non serve QoS. Se invece una delle parti vuole esercitare pressione sull'altra (con lo scopo di farsi pagare l'interconnessione), in questo momento il mercato (o meglio: la sua assenza...) prevede che possa farlo solo l'operatore di accesso.

Visto che la sua strategia è fornire un cattivo servizio ai propri clienti come incentivo all'altra parte, allora non c'è motivo di usare tecniche di QoS per migliorarlo. E se l'altra parte accetta l'estorsione allora si ricade nel caso precedente.

Qual è lo scopo di prioritizzare sul proprio backbone un certo tipo di traffico? Se questo è progettato e dimensionato correttamente, in condizioni normali non è necessario perché ci sarà sempre abbastanza capacità per fare arrivare ai propri clienti tutti i bit che vogliono inviare o ricevere. Anche sulle reti migliori a volte può capitare che ci siano picchi anomali e imprevedibili di traffico oppure che per vari motivi non si possa fare un upgrade nei tempi necessari, quindi può avere senso prioritizzare certi tipi di traffico che richiedono migliori prestazioni (es: video e voce) a scapito di altri che possono soffrire un po' senza fastidi eccessivi (es: grossi download).

Questa è una politica tecnica ragionevole, che però diventa una pessima politica commerciale se la rete è congestionata costantemente invece che in momenti eccezionali. Non è una violazione della network neutrality perché non privilegia una sorgente di traffico rispetto a un'altra, ma solo un certo tipo di traffico riconosciuto sulla base del protocollo usato.

Se invece accadesse proprio questo (per esempio se Apple pagasse per avere un servizio migliore di Facebook) allora avremmo un problema molto grave, per i motivi che sappiamo. Inoltre, in questa situazione occorre riflettere su qual è l'impatto per il pubblico: se il backbone comunque non fosse congestionato allora non avrebbe senso vendere un servizio a qualità privilegiata, perché nessuno avrebbe bisogno di comprarlo. Quindi si può violare la network neutrality solo su una rete che in condizioni normali ha cattive prestazioni per tutto il traffico. Non solo: si può violare la network neutrality soltanto dove non c'è un mercato funzionante, perché altrimenti i clienti si sposterebbero sugli operatori che forniscono un servizio migliore. Non ho mai incontrato nessuno che voglia pagare un operatore perché gli consegni solo una parte del suo traffico e butti via quello che decide essere di troppo.

Il pezzetto di rete tra DSLAM e cliente è diverso da tutti gli altri perché è il cliente stesso a controllare il traffico che ci passa. Per questo motivo non sarebbe molto utile per l'operatore violare lì la network neutrality privilegiando il traffico di certe sorgenti, perché comunque il cliente può fare in modo che non ci sia congestione regolandosi nell'uso del servizio.

Fare QoS sull'ultimo miglio sulla base del protocollo invece può essere un ottimo servizio fornito al cliente, perché gli permette di usare la propria connettività in modo più libero senza rischiare per esempio che un grosso download causi problemi a una partita a WoW.

Per saperne di più si può leggere i precedenti articoli sul mio blog oppure iniziare da questi:

Real out of band connectivity with network namespaces

This post explains how to configure on a Linux server a second and totally independent network interface with its own connectivity. It can be useful to access the server when the regular connectivity is broken.

This can happen thanks to network namespaces, a virtualization feature available in recent kernels.

We need to create a simple script to be run at boot time which will create and configure the namespace. First, move in the new namespace the network interface which will be dedicated to it:

ip netns add oob
ip link set eth2 netns oob

And then configure it as usual with iproute, by executing it in the new namespace with ip netns exec:

ip netns exec oob ip link set lo up
ip netns exec oob ip link set eth2 up
ip netns exec oob ip addr add 192.168.1.2/24 dev eth2
ip netns exec oob ip route add default via 192.168.1.1

The interface must be configured manually because ifupdown does not support namespaces yet, and it would use the same /run/network/ifstate file which tracks the interfaces of the main namespace (this is also a good argument in favour of something persistent like Network Manager...).

Now we can start any daemon in the namespace, just make sure that they will not interfere with the on-disk state of other instances:

ip netns exec oob /usr/sbin/sshd -o PidFile=/run/sshd-oob.pid

Netfilter is virtualized as well, so we can load a firewall configuration which will be applied only to the new namespace:

ip netns exec oob iptables-restore < /etc/network/firewall-oob-v4

As documented in ip-netns(8), iproute netns add will also create a mount namespace and bind mount in it the files in /etc/netns/$NAMESPACE/: this is very useful since some details of the configuration, like the name server IP, will be different in the new namespace:

mkdir -p /etc/netns/oob/
echo 'nameserver 8.8.8.8' > /etc/netns/oob/resolv.conf

If we connect to the second SSH daemon, it will create a shell in the second namespace. To enter the main one, i.e. the one used by PID 1, we can use a simple script like:

#!/bin/sh -e
exec nsenter --net --mount --target 1 "$@"

To reach the out of band namespace from the main one we can use instead:

#!/bin/sh -e
exec nsenter --net --mount --target $(cat /var/run/sshd-oob.pid) "$@"

Scripts like these can also be used in fun ssh configurations like:

Host 10.2.1.*
 ProxyCommand ssh -q -a -x -N -T server-oob.example.net 'nsenter-main nc %h %p'

About

Sono l'Italia che non vuole bene.

S M T W T F S
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

See also:

My blogroll:


W3C HTML 4.01
W3C CSS 2.0     

Powered by Bryar.pm.