Miro, l’ottimo social video player, è da poco uscito nella sua versione 1.0, ma vanta, purtroppo, qualche problema di gioventù. Il player/videodownloader in questione è basato sul motore di rendering WEB di firefox, ed eredita da questo una serie di limitazioni.
Non tutti lo sanno, ma Firefox, per scelta del suo team, non ha un sistema di autenticazione automatico sui Proxy autenticati, cosa che ci obbliga ad inserire manualmente username e password di autenticazione ad ogni sessione (è tuttavia possibile memorizzarle nel suo keyring, ma cmq è indispensabile premere “ok” nell’apposita finestra che ci si apre ad ogni nuova sessione).
Nell’azienda in cui lavoro ho un proxy server con autenticazione che costituisce percorso obbligato per uscire sulla rete internet, ed ho scoperto, mio malgrado, che sulla mia nuova Fedora 8, Miro non era in grado di procedere all’autenticazione sullo stesso, sebbene i parametri di configurazione proxy di gconf fossero correttamente inseriti nell’apposita sezione del menù di Sistema.
Dal log risultava infatti che Miro, correttamente, leggeva il valore “nome_proxy” dall’apposita voce gconf, ma non era in grado di gestire l’autenticazione, non potendo così connettersi all’esterno.
Come in ogni buon fumetto, mi si accende immediatamente una lampadina… e se provassi ad utilizzare un proxy locale per autenticare, e far passare le connessioni di tutti quei software che non gestiscono al meglio l’autenticazione proxy, attraverso esso?
Detto fatto… installo e configuro con un paio di regole minimali squid, ed aggiungo la seguente riga che abilità il “chaining” dei proxy:
cache_peer NOMEPROXY.DOMINIO parent PORTAPROXY 3130 no-query proxy-only default login=USERNAME:PASSWORD
Ma veniamo a spiegare le varie opzioni:
- cache_peer: è l’istruzione che abilita il peering, cioè il collegamento tra cache dei proxy
- NOMEPROXY.DOMINIO: ovviamente è l’indirizzo del proxy con autenticazione
- parent: indica a squid che si tratta di un proxy che ha un ordine gerarchico superiore
- PORTAPROXY: vabbè… devo spiegarvelo?
- 3120: è la porta su cui inoltrare i comandi del protocollo proxy… lasciatela com’è tanto non interfacceremo i due proxy.
- no-query proxy-only: queste due opzioni dicono a squid di comportarsi semplicemente come intermediario… in pratica non negozia alcun tipo di sincronizzazione della cache con il server proxy reale, si limita a passargli le richieste di connessione locali e riceverne i risultati.
- default: in unione a parent, serve a descrivere la topologia gerarchica… in pratica per ogni oggetto no presente nella cache locale, si farà una richiesta al genitore (parent) piuttosto che avviare una connessione diretta.
- login=USERNAME:PASSWORD vabbè… di nuovo,,, ve lo devo commentare…
A questo punto non vi resta che riavviare squid e… magia… ecco Miro bello che pronto all’uso!

Scusa la domanda/affermazione … a questo punto … tutte le tue applicazioni che devono uscire le fai puntare al tuo “local proxy” … in questo modo … in qualsiasi rete sei tocchi solo una configurazione e non N-mila … o sbaglio?
Non sbagli, o almeno, non del tutto…
Ho alcune applicazioni che però si connettono direttamente al proxy aziendale, questo perchè sono applicazioni “ufficiali” del mio team, e non posso farle passare dietro un proxy “non ufficiale”…