Oggi abbiamo ricevuto una lettera indirizzata alla nostra rubrica Informatici dal parrucchiere da parte di una persona assai disperata.
Ecco il messaggio:
Caro parrucchiere, condivido con te un mio dramma personale.
Lavoro seduta di fronte a mio marito che è informaticamente analfabeta.
Oggi gli hanno detto di pulire la cache del browser.
Ha risposto molto cortesemente, riattaccato:
«COSA [omissis] vuole questa da me?»
«DOVE porto il pc per fare ‘sta roba?»
Lui ha un melacomputer salcazzo da millemila euro e io ho un tostapane primo prezzo scontato [con GNU/Linux].
Cosa gli fatturo come technical support?
Carissima persona misteriosa, grazie per esserti aperta con noi.
Alcune considerazioni.
Il tuo compagno non è soltanto vittima di un tanto irriverente quanto ahimè giustificabile analfabetismo informatico. È anche vittima di anni e anni di indottrinamento proprietario e cultura di utilizzo passivo della tecnologia, tecnologia che—ahimè—non è neanche sotto il controllo delle persone che spesso reputiamo “smanettoni”. Questo è grave.
Variare lo sfondo, le icone, le notifiche, e mischiare hardware e software in bundle. Crediamo di avere il controllo di questo calcolatore bianco ma non è altro che una costosa e graziosa scatola nera sul cui guscio hanno messo un’assistente vocale un po’ paciona, per non farti sentire troppo impotente mentre ti strappano ogni libertà digitale, massì, magari caricando le tue foto nudo sul cloud o mentre ti costringono a fare aggiornamenti inutili che appesantiscono il dispositivo per mandarlo in obsolescenza programmata.
Altro dramma: dall’altro lato della cornetta, un’altra forma di bullismo: il supporto tecnico dei prodotti proprietari. Magari tuo marito aveva chiaramente un problema con quella merda di Safari, ma è anche altrettanto probabile che lo abbiano squisitamente supercazzolato senza sapere come risolvere il suo errore.
Che fare la prossima volta? Salva il tuo compagno! Contatta tu il supporto tecnico ma dì l’unica parola che potrà portare alla risoluzione del problema: Shibboleth.
Per la rubrica se ce l’ho fatta io ce la può fare chiunque, volevo appuntarmi come mai mi sono divertito così tanto questo week-end.
Dopo una migrazione durata un po’ più del previsto a causa di varie problematiche geopolitiche e pandemiche, abbiamo finalmente potuto testare la nuova infrastruttura di Border Radio interamente fondata su software libero.
Ho acquistato un microfono carino e ho iniziato a divertirmi. Ho aperto una trasmissione pirata e fatto qualche piccolo test con Icecast2 (software utilizzato per lo streaming).
Ho scoperto che la parte più complicata per una web-radio non è fare uno streaming. La parte più tosta è la parte prima: gestire i flussi audio sul client. Mi spiego. Magari in streaming vuoi mandare solo la tua voce, o magari vuoi anche musica in sottofondo. Magari mentre mandi la musica non vuoi poter parlare. O magari sì. Magari vuoi musica in apertura. Jingle. Magari vuoi un ospite. Magari in diretta, in conferenza. Vuoi che l’ospite ti senta e vuoi sentire lui. Vuoi non sentire la tua voce però nelle tue cuffie altrimenti diventi cretino. Vuoi anche registrare. Non vuoi però mandare in diretta le notifiche delle email, ma magari vuoi farlo con altri programmi. Magari vuoi far sentire al tuo ospite la musica che va in diretta, ma non farlo stare semplicemente in ascolto della radio perchè ci sono degli ovvi ritardi.
Insomma, redirezione dell’audio.
Mi sono ritrovato a passare le notti sulla documentazione sui moduli di PulseAudio e ho scoperto una cosa sorprendente: per fare tutto questo non devi installare una cippa di niente. Se hai una distribuzione GNU/Linux, hai già una regia. Se sai leggere il manuale.
Ho rilasciato il mio script PulseAudio qui su Gitpull (P14).
Sono riuscito a fare tutto questo soltanto con uno scriptone gigante interamente basato sul modulo “null sink” di PulseAudio, ovvero dei buchi neri in cui incanalare il tuo audio per poterlo pluggare in altri buchi neri, e in altri buchi neri, a waterfall, per poi pluggare uno di questi come input ad altri applicativi. Sono appositamente generico in quello che dico perchè non l’ho capito benissimo e ho bisogno di qualche ora di sonno in più per documentarlo meglio. asd
In pratica, ho potuto tenere una trasmissione radiofonica:
senza uno studio di registrazione (causa pandemia 2020)
da casa propria (vedi sopra)
senza una regia (inteso come il tizio dietro al vetro)
senza un mixer
con ospiti in diretta, ognuno a casa sua
con jingle, musica ed “effetti speciali”
registrando il podcast
senza software proprietario
Tecnologie utilizzate:
Icecast2: diffusione streaming
butt: invio streaming ad Icecast2 e registrazione podcast
Jitsi Meeting: gestione ospiti in diretta
PulseAudio: manipolazione dei flussi
Pavucontrol: mixer dei flussi PulseAudio (preinstallato a volte)
Audacity: rifinitura podcast (eliminazione «eehm», «eeee», «uuuhm» e tempi morti)
Ne è nata una nuova trasmissione chiamata Radio Test di Carico. Una cosa assolutamente assurda, tenuta su con la colla, ma che ha funzionato. E che ripeterò sicuramente.
Ho invitato un paio di persone davvero curiose nella prima puntata. Due persone che sto conoscendo un po’ meglio in queste ultime settimane, da organizzatori della itWikiCon 2020.
Il risultato è stato una chiacchierata attorno ad un falò in cui mi sono davvero rilassato, insieme a Iolanda Pensa e Ferdi.
Ecco il podcast:
Buon ascolto! <3
P.S.
I miei amici di Border Radio hanno diffuso il podcast praticamente su ogni possibile piattaforma di streaming. Hanno anche fatto una pagina molto carina per la trasmissione. Grazie!
It’s not a secret. I’m very happy to see some effects after my recent years of contributions in the Free as in Freedom software movement and about GNU/Linux topics, for example contributing to the Linux Day Torino event.
How much friends I’ve found, how much skills I’ve learned.
How much more I’ve to learn.
In particular, I’m proud about these two editions where I’ve given my heart for the event:
Now, after COVID-19 recentness, the Linux Day Torino will not be proposed for 2020, and it’s somehow very sad.
…before thinking about the possibility to give an hand in a new national edition, completely online.
But… hey, Wikimedian(s) have very similar problems! Why not involve them and organize two different online conferences in the same day? One about Free as in Freedom software, and the other about Free as in Freedom contents?
Here we are, running all together for an amazing online edition of a giant itWikiCon 2020 + Linux Day 2020 event.
Let’s see what it will become! Good luck to everybody!
Se per pura sfiga stai usando Aruba – il triste ma fortunato provider di servizi italiano – e lo stai usando per della posta elettronica, e vorresti usare il client GNOME Evolution, e ti funziona perfettamente la ricezione della posta ma porcalamiseria quando provi ad inviare ricevi l’errore:
TLS handshake: A packet with illegal or unsupported version was received.
Allora significa che i mailserver Aruba basati su Microsoft Exchange-merda stanno ancora usando certificati pleistozoici TLS1.0 e TLS 1.1 deprecati in tutto il pianeta, per esempio da GNOME:
Fai un logout, un login, e magicamente ora riuscirai a spedire posta con Evolution con Aruba.
Fine.
P.S. Questa guida piace ad Aranzulla perché risolve un problema stupido e molto richiesto con una soluzione stupida che finirà subito su in Google. Il vero problema è però squisitamente sociale: non dovevi avere questo problema, perchè non dovevi adottare Aruba. Migra a qualsiasi fornitore di servizi, o tirati su una Dovecot + Postfix a caso (è fighissimo, fallo), ma scappa da Aruba.
Some weeks ago I tried to setup a continuous integration solution with Phabricator, without Jenkins, and…. whaaat? it works.
So I started drawing all the concepts on paper before forgetting everything and now, If you want to configure Phabricator and its components for Continuous Integration (and no need for Jenkins or other external services) then see my guide, released on Wikibooks this night under a Free as in Freedom license:
Today I disassembled a Samsung NP305V5A to substitute its hard drive with an SSD and install Debian GNU/Linux stable (buster) with an XFCE desktop environment.
End of the story: this laptop was produced in 2011 but it’s still very usable thanks to GNU/Linux!
Hard drive substitution
Shutdown the laptop, close the lid and remove the battery.
Put the back in front of you:
Find the memory slot and open it (1 screw):
Inside the opened memory slot, remove another screw:
Remove the 4 screws under the gummy feet:
Now slide down the plastic to remove the bottom cover:
To substitute the hard drive, remove all the screws along it and remove its data connector.
Top right: my SSD. Bottom right: laptop hard drive.
To sobstitute the hard drive, separate the hard drive from its metal chassis.
The hard drive is a SATA 2.5”.
The metal chassis has just 4 screws.
Now replace your hard drive with another one (an SSD?) and turn back.
Actually I have not enough photos to provide further informations, but we easily replaced the thermal paste and cleaned the CPU fan.
Thank you Elena and its laptop, who joined the Officina Informatica Libera in Torino, to reborn her laptop using Free as in Freedom software!
È davvero un piacere partecipare all’organizzazione di un evento del genere dedicato al software libero! Sia perchè re-incontro sempre un sacco di persone piacevoli, e sia perchè sono riuscito a terminare un lavoro sul sito ufficiale che porto avanti dal 2016 per rendere il sito del Linux Day Torino un vero Content Management System a tutti gli effetti. Inoltre, perchè terrò un talk sulla privacy e sulla paranoia da sicurezza informatica difensiva.
È un periodo in cui sto popolando la mia categoria Articoli che piacciono ad Aranzulla. Oggi è il turno di una guida la cui trama è tratta da una storia vera.
Preambolo: è quasi certo che il tuo stupido blog non sia ad alto traffico. In questo caso trarrai benefici da questa lettura.
Non so se riusciamo ad immaginare sedici miliardi di accessi al giorno.
Ora immaginate che siate voi i possessori di un sito di (relativamente) insignificativa visibilità (con tutto il rispetto, ma di fronte allo scenario che stiamo immaginando siamo tutti dei peti al vento). Anche se magari avete davvero la bellezza di venti visite l’ora (di cui solo 2 di nostra madre!). Immaginiamo poi che domani il vostro sito sia promosso con un banner bello GROSSO in cima ad OGNUNO di quei siti enumerati precedentemente, esponendovi potenzialmente alla pioggia di centinaia di migliaia di accessi simultanei.
Che fare?
Per non saper nè leggere nè scrivere ci siamo preparati un attimo.
Sì, perchè il sito in questione è Wiki Loves Earth; i proprietari del dominio sono una piccola e tenera associazione culturale di miei amichetti (Informazioni.Wiki). Il motore del sito è WordPress. Il server è il mio. E sì, la Wikimedia Foundation ha ficcato un bannerone su ogni suo sito, come ad ordinare alla gente di prendere a calci nel culo tale sito.
CPU addormentata. E la macchina fa schifo. Tutto funziona.
Contrariamente ad ogni mia aspettativa siamo riusciti a gestire la situazione. Alla grande. Direi che è stata una passeggiata. Unica ragione: la gente non clicca sui banner nei siti. I numeri sono stati inferiori alle aspettative con appena 11-15 mila accessi al giorno. Circa 500 visite spalmate ogni ora. Il che non è tantissimo ma non è nemmeno poco per il server di un ragazzetto.
Questo grafico è tratto dalla nostra istanza Matomo (perchè nel 2019 siamo sufficientemente evoluti per fare statistiche senza—licenza poetica—inculare la privacy dei visitatori con Google Anal-ytics o altri incubi di cui potrei parlare per ore).
Possiamo notare la linea blu che rappresenta la pace prima della tempesta, nella prima parte del grafico, con circa un centinaio di accessi al giorno. Ad un certo punto, BOOM, 11.000 accessi al giorno. Ora guardiamo la linea verde. È il generation time. In teoria, più hai visite, più metti sotto sforzo la macchina, più il generation time aumenta. Noi lo abbiamo fatto calare facendo tuning ogni giorno. Fico, vero? È sempre sceso, arrivando ad abbattersi da circa 6 secondi ad un molto più gestibile 0.2 secondi.
Ridurre al minimo le risorse in ogni pagina a qualsiasi costo ripaga moltissimo
Adotta cache lato webserver con mod_cache o Varnish o chi per esso
Elimina qualsiasi strato di cache lato applicativo (vari plugin WordPress “iper-super-mega-cache-sarcazzo”) dato che questi ultimi sono scritti coi piedi, garantito, come ben spiegato nella guida definitiva per velocizzare WordPress!1!
Se usate Apache, ovviamente disabilitate AllowOverride e tutte le altre merde inutili di cui manco ti sei documentato.
Fai tuning di qualsiasi cosa con Apache Benchmark o amici simili. A/B. Prima dopo. Flip flop. Fallo e sarai ripagato.
A quanto pare la gente non clicca sui banner. Quindi se ti linkano da ogni progetto della Wikimedia Foundation non è da vedersi come terrorismo. Keep calm and stop tearing off cables.
Qualche dritta su mod_cache
Come funziona mod_cache? Esso arnese è uno strato in cui salvare su disco le risposte dell’applicativo (WordPress) e riconsegnarle ad altri visitatori che chiedono le stesse pagine già richieste. Questo abbatte drasticamente i tempi di generazione della pagina, perché è già stata generata. È lì. Non devi cucinare la ricetta per tutti al volo, non devi manco scongelarla, è già lì sullo scaffale e gliela devi solo lanciare al cliente. I parametri di default vanno bene per la maggior parte dei casi. Non vengono messi in cache i file troppo piccoli, i file troppo grossi, i file richiesti via POST, etc. Addirittura la vostra distribuzione GNU/Linux se non fa schifo abiliterà da sola il demone apache-htcacheclean che pulirà la cache vecchia (o almeno così avviene in Debian GNU/Linux).
Infatti, mod_cache è una pezza di software abbastanza rispettabile che fa il suo sporco dovere, e bene, se l’applicativo soddisfa una serie di banalità, tipo spedire correttamente header HTTP Expires, preferire richieste stateless evitando le sessioni, usare GET solo per richieste idempotenti, etc.
Chiaramente la maggior parte dei CMS fa soltanto una di queste cose, se non nessuna.
Dovrete girare intorno a tutte le lacune dell’applicativo ed istruire voi mod_cache. Ad esempio, mod_expires viene eseguito prima di mod_cache quindi potete usarlo per sopperrire alla mancanza di Expires dell’applicativo. Potete istruire mod_cache per saltare il caching di richieste che iniziano con /admin-stacippa. Forse dovrete anche evitare che vengano messi in cache le richieste che hanno header quali Cookie e Set-Cookie, etc.
Problemi noti
Se dopo l’abilitazione di mod_cache emergono subito artefatti allucinanti, ad esempio se il visitatore vede la stessa pagina per tutti gli URL, allora vi risparmio le bestemmie: è colpa vostra e di mod_rewrite.
WordPress, infatti, usa mod_rewrite. Lo capite subito se avete URL fighetti tipo /2019-09-05/bao invece che un meno SEO-sexy ?p=666.
Questo funziona perchè a monte avrete sicuramente una regola del genere di mod_rewrite:
RewriteRule . /index.php [L]
Questa regola pesca qualsiasi indirizzo e risponde con l’output dell’esecuziome di index.php. In pratica un solo eseguibile genera ogni pagina. Il che è sensato ma per mod_cache comporterà un bel casino dato che, per ragioni su cui non ci è dato polemizzare, mod_cache avviene dopomod_rewrite; e dato che la cache è salvata ovviamente sulla base dell’URL, questo significa che state mettendo in cache una sola pagina per tutte le richieste, perchè /welcome/ diventa /index.php e /about diventa /index.php etc.
Prima di passare a Varnish (asd) potete sfruttare questo mio workaround partorito durante una generosa seduta al bagno pensando immensamente a quanto fosse stimolante il binomio di un URL rewriter + mod_cache. Fra l’altro posso asserire con una vaga certezza che questa soluzione sia una mia idea. Ho trovato solo un altro tizio sul web che fa così ma in una domanda sgrammaticata e con una risposta che manco spiega il funzionamento. asd).
Ecco la variante:
RewriteRule ^(.*)$ index.php/$1 [L]
Funziona, perché /welcome/ diventerà un innocuo /index.php/welcome.
Perchè la richiesta/index.php/welcome dovrebbe essere lecita se quel file non esiste? Ottima domanda! Qui ti volevo. Funziona, perchè nel tuo webserver avrai attiva di default una delle mie direttive di Apache preferite, una di quelle che non conosce nessuno, ma proprio nessuno, ma, ripeto, è attiva in tutti i webserver del pianeta. Di default. In tutti. asd.
Parliamo di AcceptPathInfo. Se conosci questa direttiva significa che sei l’anticristo in persona e puoi vantarti di visitare indirizzi senza senso ottenendo una risposta valida. Esempio:
Come vedete, è una direttiva talmente sfigata che manco Facebook sa di averla, altrimenti l’avrebbe disabilitata o avrebbe impostato un reindirizzamento o dichiarato un URL canonico, cosa che al momento non fa (quindi potremmo avvelenare i loro risultati di ricerca linkando termini a caso su URL esistenti con termini a caso dentro! che bello. asd).
Va beh, torniamo a noi.
Funziona, perchè utilizzare il nome di un eseguibile esistente come se fosse una directory, provoca comunque l’esecuzione di tale eseguibile. L’URL di eccedenza (e.g. “melone-prezzemolato“) viene passato sotto banco allo script all’interno della variabile d’ambiente PATH_INFO.
In sostanza: fate in modo che agli occhi di mod_cache siano sempre tutte richieste differenti. Al contrario, per l’applicativo il meccanismo di caching deve rimanere del tutto trasparente. Notare che se l’applicativo non fa uso del PATH_INFO non farete danni nell’usare il mio workaround (come per WordPress); invece chi lo usa (come Joomla!-merda) allora semplicemente questo problema non se lo porrà perchè ogni URL sarà già univoco (affinchè non sembri che stia promuovendo Joomla!-merda, vorrei ricordare che ha una terribile gestione dei permalink e quindi avrete ben altri problemi tipo contenuti centuplicati su indirizzi a caso. Se non si fosse capito, non usate Joomla!-merda. Che fra l’altro è l’unico CMS famoso NON pacchettizzato per le principali distribuzioni GNU/Linux, talmente fa schifo.)
Concludendo
Cloudflare è per pigri. Anche un po’ per rincoglioniti. Voglio dire, c’è una rispettabile fetta di utenze di Cloudflare e di altri firewall e CDN, diciamo forse l’1% dei loro utenti, che effettivamente potrebbe meritare i servizi di Cloudflare, o di altri, poichè lo userebbero col senno dell’impossibilità di farselo in proprio per mancanza di risorse. Per il resto, mi rendo conto che centralizzare il web verso un unico fornitore di servizi possa sembrare una genialata, soprattutto per i fan di Stalin.
Insomma, fatevi da soli un server di caching o fatevelo fare. Ma fatevi qualcosa in proprio. Se ce l’ho fatta io, ce la fa chiunque. Il web é nato decentralizzato per qualche ragione. No?
A disposizione per chi interessassero ulteriori dettagli, però, principalmente, per entrare nello spirito giusto, basta partire dalla guida definitiva per velocizzare WordPress.
