L’underscore nel nome del dominio Windows

Ho configurato un server con AD FS, il sistema di Windows per l’autenticazione federata, usando un dominio che contiene un underscore nel nome. Durante l’impostazione del nome dell’account per il servizio, ho indicato l’utente con il suo UPN, cioè nella nuova forma nome.utente@nome.dominio e non nella vecchia forma NOMEDOMINIO\nomeutente. Il pannello per la configurazione ha mostrato il nome nel formato vecchio, togliendo l’underscore dal nome del dominio, che è diventato EOM01 anziché EOM_01, ma ha continuato a mostrare anche il nome corretto nel tooltip.

Tutto questo mi ha fatto fare dei controlli sull’utente e sul dominio, ma non ho trovato nulla di anomalo. Ho cercato per ore, invano.

Poi mi sono accorto che il carattere dopo l’underscore era sottolineato, cioè era EOM01. Questo mi ha fatto scervellare finché ho capito: nel disegnare l’interfaccia, i programmatori hanno messo il nome del dominio dentro un’etichetta, la quale interpreta l’underscore per indicare la scorciatoia da tastiera per l’azione legata generalmente a quell’etichetta.

Difatti, ecco qui la pagina per gli sviluppatori sulla classe Label dei widget di Windows.

Ho segnalato la cosa a Microsoft qui.

Analisi di problemi su squid

Quando c’è un problema con squid, io non so mai che pesci pigliare. Per evitare di fare sempre le stesse ricerche e trovare le stesse risposte, nonché per delineare una modalità di indagine, aggiornerò questo articolo ad ogni nuova occasione.

squid impiega parecchio tempo per avviarsi, ma a volte, se si fanno solo modifiche alla configurazione, si può evitare di riavviarlo mandando il segnale per la rilettura del file di configurazione.

# systemctl restart squid # riavvio completo
# squid -k reconfigure # rilegge la configurazione

Access log

Il principale file di log è quello che mostra tutte le richieste che ha ricevuto e la risposta che ha dato. Il file è /var/log/squid/access.log e contiene righe fatte così:

1611652062.938 1 192.168.215.45 TCP_DENIED/403 4044 CONNECT cdn-gl.imrworldwide.com:443 - HIER_NONE/- text/html
1611652065.142 63192 192.168.215.45 TCP_TUNNEL/200 1671 CONNECT outlook.office365.com:443 - HIER_DIRECT/40.101.137.66 -

Il primo numero è una marca temporale non formattata. Per sapere veramente a che ora si riferisca si può usare il comando date così

# date --date @1611652073.326
mar 26 gen 2021, 10.07.53, CET

il secondo numero è il tempo, in millisecondi, impiegato da squid per rispondere al client dopo aver svolto l’operazione

il terzo campo è l’IP del client

il quarto campo è l’esito. Gli esiti maggiormente diffusi sono:

  • TCP_DENIED/403, indica che la richiesta è stata rifiutata con codice HTTP 403
  • TCP_TUNNEL/200, indica che la richiesta di apertura di un tunnel è stata accetta con codice HTTP 200
  • TAG_NONE/503, indica un errore interno di quid, ad esempio che non riesce a risolvere il nome con il DNS

il quinto campo è il metodo HTTP richiesto dal client: GET, POST, HEAD, CONNECT

il sesto campo è la coppia nome host e porta da contattare.

Cache log

Questo secondo file di log è /var/log/squid/cache.log e contiene informazioni aggiuntive. Ci sono le informazioni di debug che vengono scritte in base alla direttiva debug_options. Normalmente contiene solo le segnalazioni di problemi. Per avere un po’ più di informazioni, aggiungere:

debug_options ALL,2

al file di configurazione /etc/squid/squid.conf e farlo rileggere a squid. Ci si possono trovare informazioni come questa:

2021/01/26 09:43:04.511 kid1| 85,2| client_side_request.cc(744) clientAccessCheckDone: The request CONNECT mail.google.com:443 is ALLOWED; last ACL checked: localnet
 2021/01/26 09:43:04.511 kid1| 85,2| client_side_request.cc(720) clientAccessCheck2: No adapted_http_access configuration. default: ALLOW
 2021/01/26 09:43:04.511 kid1| 85,2| client_side_request.cc(744) clientAccessCheckDone: The request CONNECT mail.google.com:443 is ALLOWED; last ACL checked: localnet
 2021/01/26 09:43:04.511 kid1| 44,2| peer_select.cc(258) peerSelectDnsPaths: Find IP destination for: mail.google.com:443' via mail.google.com
 2021/01/26 09:43:04.511 kid1| 44,2| peer_select.cc(280) peerSelectDnsPaths: Failed to select source for 'mail.google.com:443'
 2021/01/26 09:43:04.511 kid1| 44,2| peer_select.cc(281) peerSelectDnsPaths:   always_direct = DENIED
 2021/01/26 09:43:04.511 kid1| 44,2| peer_select.cc(282) peerSelectDnsPaths:    never_direct = DENIED
 2021/01/26 09:43:04.511 kid1| 44,2| peer_select.cc(295) peerSelectDnsPaths:        timedout = 0
 2021/01/26 09:43:04.511 kid1| 4,2| errorpage.cc(1261) BuildContent: No existing error page language negotiated for ERR_DNS_FAIL. Using default error file.

che indicano una richiesta di apertura di un tunnel verso mail.google.com che viene inizialmente accettata tramite le ACL, ma poi rifiutata per un problema del DNS usato da squid.

Aggiornamento di Jitsi: sala d’attesa e co-moderatori

Quest’anno ho messo un server Jitsi a disposizione di chiunque lo voglia usare. Si tratta di un sistema per le video chiamate che ho attivato nell’ambito del progetto iorestoacasa.work che, nell’ottica di affrontare meglio la pandemia di Covid-19 del 2020, offre servizi di video chiamata gratuiti a tutti. Lo potete usare qui, con un semplice browser o con l’app Jitsi Meet che potete scaricare dalla pagina principale del sito.

A inizio dicembre ho aggiornato la macchina, passando dalla versione stabile (rilasciata il 14 ottobre 2020, non molto tempo prima) a quella in via di sviluppo. Come il nome fa già capire, questa versione ha funzionalità più nuove, ma è stata sottoposta a controlli minori; ma pare che funzioni a dovere e ha, tra le altre, due nuove funzionalità importanti:

  • la parte del moderatore non è solo di chi apre la stanza, ma può essere assegnata anche ad altri. Un moderatore può selezionare il riquadro del video di un partecipante e aprire il menu contestuale. Lì si trova l’opzione per dare il diritto di moderatore al partecipante;
  • c’è la sala d’attesa. Per proteggere l’accesso alle stanze era già possibile impostare una password (ed è tuttora possibile), ma se un partecipante spiritoso la comunica ad altri meno divertenti, questi si potrebbero collegare alla stanza per disturbare. La sala d’attesa è un posto nel quale finiscono tutti i nuovi arrivati, che vanno ammessi da uno dei moderatori, manualmente. In questo modo è possibile controllare chi si collega (c’è un nome e, eventualmente anche l’email).

Video chiamate libere

In quest’epoca di confinamento a casa alcune persone legate ad un istituto scolastico di Fabriano hanno lanciato l’iniziativa iorestoacasa.work. Si tratta di una rete di server che ospitano due diversi applicativi per le video chiamate. Tutti i server offrono un punto d’accesso centralizzato al quale collegarsi per avviare una video chiamata, la quale viene poi «trasferita» ad uno dei server disponibili. L’iniziativa ha lo scopo di aiutare le scuole a fare lezione senza affollare i server principali. Questo è reso possibile, da una parte, da vari enti, singoli privati e aziende che hanno collegato i loro server a iorestoacasa.work e offrono gratuitamente il servizio sostenendone i costi di hardware, connettivià e gestione; e dall’altra parte dall’esistenza di due prodotti open source per le video conferenze.

I due diversi applicativi sono Jitsi Meet e Multiparty Meeting. Il primo è più vecchio e offre maggiori funzionalità, come ad esempio la possibilità di moderare la chiamata, il secondo è più nuovo. Dal punto di vista tecnico entrambi utilizzano WebRTC per la trasmissione dati e richiedono quindi abbastanza potenza di calcolo sia abbastanza banda. Difficile seguire una video chiamata se si ha un computer più vecchio del 2010-2012 o se si una una ADSL lenta. L’utilizzo delle video chiamate senza connessione ad Internet via cavo è una esperienza poco gradevole. Fatelo da casa, con la connessione via cavo, magari con il Wi-Fi del computer o del tablet, ma collegati al router con l’ADSL o la fibra. Potendo scegliere, non fatelo con la connessione 3g o anche 4g del telefono.

La tecnologia WebRTC non è nuovissima, ma comunque non è implementata da tutti i browser allo stesso modo e quindi ci sono differenze di prestazioni e di usabilità. La migliore implementazione è al momento quella di Google Chrome, seguita da Safari (ma solo su Mac OS Catalina). Firefox è attualmente escluso perché ha parecchi bug che non solo ne sconsigliano l’utilizzo, ma che addirittura peggiorano il funzionamento degli altri partecipanti alla video chiamata, qualsiasi sia il browser che essi utilizzano.

Per l’utilizzo da Android e iOS, se si usa Jitsi, è necessario scaricare l’app Jitsi Meet. Altrimenti è sufficiente il browser.

Utilizzo

L’utilizzo è aperto a tutti: non è necessario registrarsi, non si è tracciati, non si è su server di proprietà di grandi multinazionali straniere. Sul sito iorestoacasa.work c’è anche la clausola di utilizzo che descrive le implicazioni con il GDPR.

A differenza di altri prodotti, non è possibile prenotare una stanza per un certo orario, o stabilire chi debba essere il moderatore.

Chi inizia stabilisce il nome della stanza, possibilmente in modo che sia univoco, ad esempio «kh34jlkzf» oppure «TerzaE_ITIS_Avogadro_20200521» e immette questo nome nell’unica casella di testo della pagina iorestoacasa.work. Poi sceglie se usare Jitsi Meet o Multiparty Meeting, e entra nella stanza. Il sito sceglie a quale server assegnare la video chiamata e vi dirotta su quella macchina. A quel punto aggiungete una password alla stanza, copiate negli appunti l’URL mostrato in cima al browser e mandatelo a tutti gli invitati, con annessa la password.

Durante la chiamata sarà possibile vedersi e parlare, condividere lo schermo di uno qualsiasi dei partecipanti (ma di norma è l’insegnante/moderatore) per mostrare video o documenti, scriversi. In alcuni casi (ma non tutti i server di iorestoacasa.work lo permettono) è presente una lavagna condivisa, sulla quale scrivere.

La stanza creata verrà chiusa quando tutti ne usciranno, ma solo quello che l’ha aperta potrà esserne il moderatore. Moderare significa avere il controllo della stanza, ad esempio si può accendere o spegnere il microfono agli invitati, oppure cacciarli dalla stanza (ma su Jitsi Meet potrebbero riusare l’URL e ricollegarsi, mentre su Multiparty Meeting si può bloccare l’accesso una volta che tutti sono dentro).

Alla fine della chiamata tutto viene perso. Se avete usato la chat non potrete recuperarne il contenuto. Potrebbe essere attiva la possibilità di registrare la video chiamata, ma si tratta di una opzione dell’applicativo Jitsi Meet che non ho ancora visto su nessuno dei server di questa federazione.

Lo stesso URL può essere usato anche per video chiamate successive, ma una volta che tutti escono dalla stanza, si perde traccia di chi ne è il moderatore, quindi al riutilizzo verrà assegnato il diritto di moderare al primo collegato. Per questo motivo è sempre bene, da parte di un insegnante, non usare lo stesso nome, ma uno nuovo ogni volta, comunicandolo agli studenti via email solo qualche minuto prima di iniziare la lezione.

qemu e “Failed to lock byte 100”

QEMU non ha grande simpatia per i file system di rete. Di recente ho provato a creare una nuova macchina virtuale partendo da una immagine ISO depositata su un altro server e accessibile via NFS. non ha funzionato.

L’immagine era usata per il lettore CD, il quale era di tipo SATA. L’errore ricevuto era apparentemente difficile da interpretare, ma una volta riletto più volte è diventato chiaro. Oltre ad essere riportato nella GUI del virt-manager era anche presente nel file di log in /var/log/libvirt/qemu/nomeVM.log. Il messaggio era:

qemu-system-x86_64: -device ide-cd,bus=ide.1,drive=libvirt-2-format,id=sata0-0-1: Failed to lock byte 100

Le parti da capire sono «ide-cd» che vuol dire che l’errore è relativo ad un device virtuale di tipo CD-ROM collegato ad un controller IDE/SATA, «ide.1» che indica che si tratta del primo CDROM (io ne avevo due: uno per il sistema opeartivo e uno con i driver aggiuntivi per VirtIO), e infine il messaggio vero è proprio «Failed to lock byte 100» che indica un problema nell’accesso al file.

Il file in questione, vista la natura del device (CD-ROM) è l’immagine ISO del sistema operativo. L’errore sul lock indica che il file system non permette l’operazione di blocco che qemu vorrebbe fare. E in effetti NFS non permette di fare i lock sui file.

Morale: spostata l’immagine ISO sul disco locale, e riconfigurato QEMU con il nuovo percorso, tutto ha funzionato.