laboratorio caffeina

Per oscuri motivi che non indagheremo, il mio server ha un IP dinamico. Ovvero, l’internet provider che lo collega ad internet ne cambia l’indirizzo IP ad intervalli che vanno da alcune ore a pochi giorni. Per raggiungere la macchina da remoto, o per permettere ad altri di collegarvisi, ho dovuto perciò configurare un DNS dinamico: un nome cui corrisponda l’IP attuale frequentemente aggiornato.

Esistono molte soluzioni gratuite che permettono di scegliere un sottodominio ed aggiornarne automaticamente l’indirizzo IP. Una di queste, cui mi sono appoggiato per alcuni anni, è DynDNS: sul sito internet dell’azienda si registra un sottodominio, come daniele.homelinux.org, dove “daniele” è la parte scelta da me, e “homelinux.org” è il dominio principale scelto da una lista predeterminata di nomi (piuttosto bruttini). Un programma installato sul server (ddclient) si occuperà di mantenere aggiornati i registri DNS di DynDNS. Il client controlla periodicamente l’IP della macchina e quello registrato presso DynDNS: qualora i due differiscano, richiede un aggiornamento.

Quando ho acquistato un dominio mio con gestione DNS su TopHost (modena1.it), ho dovuto redirigere sottodomini come “www” al mio server con IP dinamico. La prima soluzione è stata inserire un registro DNS di tipo CNAME, ovvero che fa corrispondere ad un nome un altro nome, come:

www CNAME daniele.homelinux.org

Ho sempre pensato che questa soluzione fosse antiestetica, sebbene invisibile all’utente finale (che si collega comunque a www.modena1.it e vede solo quel nome). Se ho un dominio mio, perché dovrei usare queste parolacce? Del resto l’alternativa era visitare il pannello di controllo di TopHost ogni volta che il mio IP cambiava ed aggiornarlo manualmente… decisamente impraticabile! Allora mi sono rassegnato - temporaneamente, s’intende.

La questione è tornata fuori quando ho avuto bisogno di un gran numero di sottodomini per la gestione della posta e che fossero di tipo A, e scontrandomi inoltre con una limitazione tecnica di DynDNS. L’unica via d’uscita sembrava essere comprare un nuovo dominio, o un account pro su DynDNS.

Invece mi sono scritto un client per il pannello di controllo DNS di TopHost: thdns. Praticamente, un clone ddclient ma adattato per TopHost.

Il programma esegue i seguenti passaggi:

1. Confronta l’ip memorizzato all’ultima esecuzione e quello attuale o fornito come argomento. Se sono uguali, esce.
2. Si autentica sul pannello DNS e controlla che anche l’IP sul pannello sia diverso da quello verso cui è richiesto l’aggiornamento. Se non lo è, esce specificando che l’IP è stato mantenuto.
3. Aggiorna l’ip per il nome richiesto, stampando l’IP precedente e quello nuovo.

Quindi sul pannello ho registrato diversi sottodomini e li ho inseriti nel programma come nomi da aggiornare:

www IN A …ip a caso…

daniele IN A …ip a caso…

etc…

Infine ho inserito una linea in /etc/crontab per chiamare il client ad ogni quarto d’ora:

0,15,30,45 * * * * daniele thdns

Ora la mia macchina è quasi sempre raggiungibile al suo vero ip, grazie a questa piccola magia python: ogni15 minuti infatti il campo IP di tutti i miei record DNS viene sincronizzato con l’indirizzo corrente.

Il programma naturalmente può essere utile anche per chi ha ip statici da amministrare : ad esempio per redirigere rapidamente i propri sottodomini verso server di backup, in caso di emergenza.

Condividi

E’ forse un argomento marginale per il Laboratorio Caffeina, ma cosa fare quando i nostri occhi sulla rete cominciano ad appannarsi o smettono completamente di vedere?

Ovvero, quando quei complessi programmoni chiamati “browser” si piantano impietosamente. Si da la colpa al browser? Al sito web “mal progettato”? Forse, ma prima è bene stracciare tutto il possibile…

Ormai un mesetto fa Repubblica.it ha cominciato a provocare improvvisi crash di Iceweasel/Firefox. Ecco l’ordine in cui NON bisognerebbe procedere in questi casi:

1. Ho atteso 3 settimane il classico aggiornamento Deus Ex Apt-get che risolve tutto, da buon utente Debian GNU/Linux. L’aggiornamento non è arrivato.
2. Ho tentato un downgrade, senza effetto.
3. Ho installato la versione di debug, apt-get install iceweasel-dbg, e lanciato con l’opzione di debug attiva: iceweasel -g. La parte interessante dell’output è questa:
   Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1222601024 (LWP 17712)]
0×08384ced in nsTextFrame::Reflow (this=0×98a22d0, aPresContext=0×92e3688, aMetrics=@0xbfbb52d4, aReflowState=@0xbfbb521c,
aStatus=@0xbfbb5388) at nsTextFrame.cpp:594
594 nsTextFrame.cpp: No such file or directory.
in nsTextFrame.cpp
   Da cui deduco che qualcosa deve essere andato storto con un file non trovato…
4. Qualcosa dunque manca, o è cercato nel posto sbagliato… In questi casi esiste l’utilissimo programma strace, un System Call Tracer. Lanciando da console:
   strace iceweasel

verrà avviato iceweasel mentre lo standard out viene inondato di informazioni. Ogni riga dell’output specifica quale chiamata di sistema sta venendo inoltrata dal programma lanciato, in quel preciso istante. Nel mio caso il debug è stato molto semplice: quando iceweasel è uscito inaspettatamente, sono andato a leggere quali chiamate erano in corso.

[...]
open(”/var/lib/defoma/fontconfig.d/L/LucidaSans.ttf”, O_RDONLY) = -1 ENOENT (No
— SIGSEGV (Segmentation fault) @ 0 (0) —
unlink(”/home/daniele/.mozilla/firefox/kl5cndvj.default/lock”) = 0
rt_sigaction(SIGSEGV, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [SEGV], NULL, 8) = 0
tgkill(3367, 3367, SIGSEGV) = 0
— SIGSEGV (Segmentation fault) @ 0 (0) —
+++ killed by SIGSEGV +++
Process 3367 detached

Come lasicava pensare il messaggio di debug “No such file or directory.”, Iceweasel stava tentando di aprire un file senza riuscirvi: l’ultima chiamata di sistema prima del segnale SIGSEGV è un open(), cioè più o meno “accedi ad un file o ad una periferica”. Dagli argomenti della chiamata possiamo capire quale file Iceweasel stava aprendo, in che modalità (lettura, scrittura, etc), ed il codice d’uscita accompagnato da altre informazioni.

Ora non resta che da capire cosa non va con questo benedetto file: var/lib/defoma/fontconfig.d/L/LucidaSans.ttf !

Listando la cartella in cui si trova, vedo che, assieme a tanti altri, si tratta di un link simbolico interrotto:

$ ls -l /var/lib/defoma/fontconfig.d/L
[...]
lrwxrwxrwx 1 root root 58 2007-05-02 10:59 LucidaSans.ttf -> /usr/share/fonts/truetype/ttf-lucida/LucidaSansRegular.ttf
[...]

E listando la cartella /usr/share/fonts/truetype/ttf-lucida mi accorgo che anche LucidaSansRegular.ttf è un link interrotto:

$ ls -l /usr/share/fonts/truetype/ttf-lucida
[...]
lrwxrwxrwx 1 root root 81 2007-02-16 01:13 LucidaBrightRegular.ttf -> ../../../../lib/jvm/java-1.5.0-sun-1.5.0.11/jre/lib/fonts/LucidaBrightRegular.ttf
[...]

E la catena di link interrotti è giunta a conclusione: il problema è che la cartella /lib/jvm non esiste! Quindi tutti i link risultano interrotti e quando Iceweasel tenta di aprire l’inizio della catena, si trova con un errore fatale.

E’ fuori discussione che il link si riferisca a Java (java-1.5.0-sun-1.5.0.11 nel percorso), quindi qualcosa deve esser andato storto con la mia installazione di Java… Sono su Debian, quindi la soluzione più rapida al problema è senza dubbio reinstallare il pacchetto di sun-java6-fonts.

Due minuti dopo stavo navigando su Repubblica…

E la sequenza giusta? Quella inversa, naturalmente.

Col senno di poi…

Condividi