La perdita dell’innocenza

Microsoft è stata cattiva sin dall’inizio. Quando il software veniva distribuito liberamente fra i (pochi) appassionati dell’Homebrew Computer Club (HCC), il primo gruppo di appassionati di computer nato non a caso nella Silicon Valley, Bill Gates rivendicò ad alta voce il diritto di essere ricompensato economicamente per i prodotti software sviluppati dalla sua azienda, la neonata Micro-Soft (ancora con il trattino in mezzo al nome).


Fonte: MOHAI, Museum Of History And Industry.

La sua lettera, pubblicata sul numero del 3 febbraio 1976 della newsletter dell’HCC segna la fine dell’epoca pionieristica e l’inizio dell’industria dei personal computer. Ma per Bill Gates e la sua Microsoft quello fu solo il primo passo. Poi venne il DOS rubato (o quasi) al povero Tim Paterson, Windows messo a forza in qualunque PC venduto sulla faccia della Terra, la distruzione della concorrenza con qualunque mezzo, lecito ed illecito, pratiche commerciali rapaci. Tutto si può dire di Microsoft, tranne che sia mai stata una azienda simpatica.


Google era esattamente il contrario, era l’azienda buona per antonomasia. Quella che già nel motto, Don’t Be Evil, prometteva di non essere malvagia.

Il motore di ricerca nato nel 1998 in un dormitorio di Stanford veniva percepito come l’azienda ideale dove lavorare, una azienda aperta, liberale, proiettata nel futuro. Una azienda capitanata da due geek più interessati alla carriera accademica che al mondo degli affari, nella quale i dipendenti venivano praticamente cullati e potevano usufruire di una libertà e di un livello di servizi impensabile altrove.

Oggi Google ha perso la sua innocenza, è un mostro tentacolare che attenta ogni giorno di più alla nostra privacy, che non si fa scrupoli di scendere a patti con le dittature, dove i dipendenti sono sempre meno tutelati e, se osano protestare, vengono mobbizzati o fatti fuori senza scrupoli. Proprio come è successo a Claire Stapleton, il “bardo di Google”, la manager che aveva contribuito a creare l’immagine dell’azienda.

Il motto originario è passato di moda, ora contano solo i soldi.

Tagged with: , , , ,
Pubblicato su software

Cronaca di un disastro: come sopravvivere alla pagina bianca di WordPress

Questo non è un post adatto per chi si spaventa facilmente. Se siete ansiosi o deboli di cuore fatevi un favore e non continuate a leggere.

Premessa

Quando si verifica un disastro in ambito informatico (e non solo) la cosa più importante è non perdere mai la calma. E poi non bisogna avere fretta di rimettere le cose a posto, meglio riflettere prima di agire. Naturalmente avere un backup aggiornato a disposizione aiuta sempre moltissimo.

Tutte le volte che ho dovuto affrontare un disastro di tipo informatico — e fra casi personali, amici e conoscenti succede relativamente spesso — queste linee guida sono sempre state utilissime per risolvere il problema. L’ultima volta, però, una installazione di WordPress andata completamente in tilt ha messo a durissima prova la mia pazienza, oltre che le mie conoscenze tecniche. Ecco il racconto di quello che è successo.

Una giornata particolare

Oltre a questo blog, amministro da anni Il nostro CNR, un sito finalizzato alla discussione di tematiche relative al mondo del CNR e della ricerca in generale. Come melabit, anche Il nostro CNR è basato su WordPress. Il sito è piuttosto popolare, ha un discreto numero di visualizzazioni giornaliere, purtroppo sono sempre troppo pochi quelli che hanno la voglia e la pazienza di intervenire sul forum. Ma questo è un male tipico degli italiani, bravissimi a discutere animatamente al bar (verba volant…), ma molto meno propensi a mettere per iscritto quello che pensano, magari per paura di ritorsioni (…scripta manent ).

Poco prima di Natale Corrado Zunino, un giornalista di Repubblica sempre molto attento ai problemi della ricerca, pubblica un articolo in cui rivela che la procedura di elezione del rappresentante del personale nel CdA del CNR, conclusa un mese prima, potrebbe essere stata viziata da brogli. Il rappresentante eletto alla tornata precedente era stato una vera e propria spina nel fianco per la dirigenza del CNR e, non pago di quattro anni di fatiche e sacrifici anche personali, aveva deciso di ripresentarsi per un secondo mandato, con ottime possibilità di successo. Toglierlo di mezzo e sostituirlo con qualcuno meno rigido e competente era quasi una necessità.

Subito dopo aver letto l’articolo su Repubblica decido di diffonderlo tramite Il nostro CNR. Del resto, dopo la trasmissione di Report del marzo 2017 che ha rivelato la lunga serie di ruberie avvenute in un istituto del CNR (di certo non l’unico) e ancora di più dopo l’arresto dell’ex-direttore del CNR e dei suoi sodali, nel nostro ente l’interesse per queste vicende ripugnanti è altissimo.


Fonte: Il Mattino, 20 novembre 2019.

Aggiornamenti inattesi

Entro quindi in quello che è un po’ il retrobottega del sito, la cosiddetta dashboard, l’interfaccia di gestione dei contenuti e delle funzionalità di WordPress, per scrivere un post sulla notizia di Repubblica e come al solito trovo alcuni plugin da aggiornare (i plugin sono dei pezzetti di codice che estendono le funzioni del sito). Succede praticamente ogni volta che accedo alla dashboard, e senza pensarci più di tanto clicco sul pulsante di aggiornamento. È una procedura assolutamente sicura e comunque, anche se uno dei plugin non dovesse più funzionare bloccando il resto del sistema, mi basterebbe modificare i nomi di qualche file per disattivarlo e recuperare la piena operatività del sito.

Questa volta invece, per qualche motivo incomprensibile, insieme all’aggiornamento dei plugin parte anche l’aggiornamento dell’intero codice di WordPress dalla versione 4.x all’ultima versione disponibile, la 5.qualcosa. Aggiornamento che per tanti motivi non volevo ancora fare, e soprattutto che non avrei mai fatto senza prima eseguire un backup affidabile di tutto il sito.

Non riesco ancora a capacitarmi di cosa possa essere successo, ma sono sicuro al 100% di non averlo fatto io stesso per errore. I pulsanti per aggiornare i plugin o il codice di WordPress sono ben distinti e non possono essere premuti contemporaneamente (lo vedete qui sotto), e poi ricordo benissimo di aver letto i messaggi che elencavano i plugin in corso di aggiornamento. Ma, quando alla fine del processo ho cliccato per tornare alla pagina principale, ho visto partire anche l’aggiornamento del codice di WordPress, e a quel punto non potevo più far niente per interromperlo.

È possibile che l’aggiornamento del codice sia partito da solo per qualche baco di WordPress o di un plugin, del resto i bachi del software sono inevitabili. Una cosa seccante, ma ancora niente di preoccupante.

Un backup è per sempre?

Una volta concluso l’aggiornamento non voluto di WordPress, apro una nuova scheda del browser per controllare cos’è successo al sito. Compare solo una pagina completamente bianca. Il sito in effetti funziona ancora, ma non carica correttamente le pagine, e anche la dashboard appare completamente vuota. Per fortuna i file che costituiscono il sito ci sono ancora tutti, e anche il database usato da WordPress per memorizzare i dati variabili del sito è ancora al suo posto.

Un sito web dinamico come WordPress è costituito in genere da due componenti ben distinte: la prima comprende tutti file che costituiscono il sito web vero e proprio e che vengono modificati di rado, in particolare il codice WordPress e le personalizzazioni dell’utente, i plugin, i temi grafici, le immagini e tutti i documenti collegati alle pagine del sito (questa componente sarà denominata da ora in poi “file del sito” o semplicemente “sito”). La seconda componente è costituita da un database nel quale vengono memorizzati i dati variabili del sito, fra cui i testi degli articoli e degli interventi sul forum, le informazioni relative agli utenti registrati, i dati di accesso e moltissimo altro.

Quando succedono queste cose nel 99% dei casi la colpa è di qualche plugin che funziona male o non funziona affatto. Non c’era del resto da stupirsi, uno dei motivi per decidere di non aggiornare alla versione più recente di WordPress era legato proprio al fatto che almeno due plugin piuttosto importanti non erano ancora stati aggiornati per funzionare con le nuove versioni di WordPress e di PHP, il linguaggio di programmazione per il web con il quale è sviluppato WordPress.

Per correggere il problema della pagina bianca ci sono sostanzialmente due metodi: il primo richiede di disattivare i plugin uno ad uno, fino a scoprire quello che non funziona. Richiede ore ed ore di lavoro certosino e non avrebbe comunque risolto il problema dell’aggiornamento indesiderato del sito. Nonostante tutto, ho provato a disattivare i due, tre plugin più critici ma non cambiava niente.

Il secondo metodo prevede di ripristinare il sito da un backup recente e, in questo caso specifico, ha l’enorme vantaggio di poter tornare alla versione precedente di WordPress. E dato che il provider scelto per ospitare il sito fa un backup ogni ora, mi sembrava più che naturale scegliere la seconda soluzione.

Ed è qui che sono cominciati i guai.

Apro un ticket, cioè una richiesta di supporto tecnico, presso il provider e chiedo come ripristinare il sito da un backup eseguito intorno alle 9 del mattino, ora alla quale ero sicuro di non aver fatto ancora niente. Purtroppo non posso fare da solo, l’assistenza tecnica mi avvisa che la procedura di ripristino del database di WordPress deve essere effettuata dal provider, altrimenti dà errore.

Ovviamente li lascio fare, indicando il backup da ripristinare, il #687 eseguito alle 8:53, e ribadendo che volevo un ripristino totale, pulito, sia del sito che del database su cui si appoggia (la conversazione qui sotto, così come tutte le conversazioni successive, vanno lette dal basso verso l’alto).

Non funziona, anzi è peggio, i file del sito sembrano a posto, ma il database viene ripristinato solo in parte e quindi in pratica non serve a niente.

Intanto mi sono fatto dare l’intero backup del sito e del database delle ore 8:53 in formato standard e in questo backup il database sembra completo. Però ogni volta che l’assistenza tecnica prova a ripristinarlo la procedura fallisce. Secondo loro perché il database è corrotto, secondo me perché la loro procedura di ripristino non funziona bene.

Provo allora a chiedere il ripristino da un backup di un paio di giorni prima, ma non cambia niente. È già passato un giorno, il sito è ancora giù e io faccio una pessima figura con i colleghi che lo frequentano.

Andare sul cloud

A questo punto decido di lasciar perdere l’assistenza tecnica e di fare da solo, usando il backup del sito e del database che mi sono fatto dare per ricostruire il sito da zero. Potrei usare come al solito una macchina virtuale, dove installare una versione server di Linux con tutto quello che serve per far funzionare WordPress, ma questa volta preferisco di andare sul cloud in modo da poter lavorare, se serve (e servirà molto spesso!), anche da casa.

Scelgo AWS Cloud9 di Amazon, funziona bene, costa poco e mi sembra più affidabile di altri servizi che ho usato in passato, come Codeanywhere, Koding o Pilvia, che cambiano continuamente modello di business. Accedo al mio account e creo una nuova istanza di AWS Cloud9, dove installo la versione 18.04/Bionic LTS di Ubuntu Linux.1

Potrei scegliere anche Amazon Linux, una versione di Linux specifica per Amazon AWS e basata su RedHat e CentOS, ma preferisco andare sul sicuro, in fondo Ubuntu deriva sempre da Debian, e nel mondo Linux non c’è niente di meglio di Debian.

Tralascio i dettagli dell’installazione di tutto quanto serve per far funzionare WordPress su Linux (ma se richiesto potrebbe essere argomento di un prossimo articolo). Il server web Apache, il linguaggio di programmazione PHP e il sistema di database relazionale MariaDB,2 sono già installati di default in Ubuntu LTS, si tratta solo di configurare opportunamente tutto per girare su AWS Cloud9 e di creare il database per WordPress. Già che ci sono, installo anche phpMyAdmin, un programma comodissimo che permette di gestire un database MySQL (e quindi anche MariaDB) tramite una interfaccia web.

A questo punto basta scaricare il codice di WordPress ed effettuare la famosa installazione in 5 minuti per essere a posto.

Beh, magari fosse così semplice! Tutto quello che ho in questo momento è un sito funzionante ma vuoto, invece a me serve ripristinare tutto il contenuto de Il nostro CNR.

Per farlo, sostituisco i file del sito e il database di WordPress con quelli contenuti nel backup fornito dal provider. Sembra difficile, ma avendo pieno accesso al terminale di Linux ed essendo l’amministratore onnipotente del sistema su cui gira WordPress diventa un gioco da ragazzi. Riavvio MariaDB ed Apache per fargli rileggere i nuovi dati su cui operare, ma non funziona.

Naturale, il database contiene l’indirizzo web (URL) del sito originale, https://ilnostrcnr.it, ma ora sono su Amazon AWS e l’URL del sito che ho creato è completamente diverso, è qualcosa tipo https://b0ef0914612e145f8fad9237c0dabd8a.vfs.cloud9.us-east-2.amazonaws.com. Non ho intenzione di combattere con i DNS o il file hosts, per cui entro nel database con phpMyAdmin, seleziono la tabella wp_options e sostituisco l’URL originale contenuto nei record siteurl e home con quelli forniti da Amazon AWS.

Riavvio di nuovo MariaDB ed Apache e finalmente il sito torna a vivere. Con phpMyAdmin controllo se il database ha degli errori, e in effetti ci sono, ma niente di così grave che possa impedirne il ripristino (e del resto a me funziona tutto perfettamente).

A questo punto è quasi routine, ed è anche l’occasione per dare una bella rinfrescata alle funzionalità del sito. Entro nella dashboard e rimuovo il plugin All-in-One WP Migration, che usavo per fare i backup personali del sito ma che che non è compatibile con le ultime versioni di PHP 7.x, e cancello dal terminale la directory relativa. Rimuovo anche il plugin Count per Day, ottimo per analizzare le statistiche di accesso al sito ma che non è aggiornato da un anno e non è stato testato con le versioni più recenti di WordPress. E dato che ha violato le linee guida di WordPress è stato pure rimosso dall’archivio (repository) ufficiale dei plugin di WordPress.

Controllo di nuovo il database usando sia una funzione seminascosta di WordPress3 che il solito phpMyAdmin ed ora è tutto a posto, dopo la rimozione dei due plugin problematici anche gli errori del database sono scomparsi.

Ritorno al provider

A questo punto mi rimane solo da fare un backup del sito e del database, che il provider potrà usare (o meglio “dovrà usare”, visto che finora non ha fatto niente di significativo) per ripristinare il sito originale.

Ma la cosa si rivela più difficile del previsto e l’interazione fra il supporto tecnico e me sembra un dialogo fra sordi,

che sfocia rapidamente nella incomunicabilità totale. Il sito è giù da ben 11 giorni ma al servizio tecnico importa pochissimo. Inutile provare ancora a ricevere un supporto degno di questo nome.

Prima di tagliare i ponti con il servizio tecnico ho preparato un Piano B. Ore di ricerche sul web mi hanno fatto trovare Duplicator, un plugin che sembra perfetto per le mie esigenze. In apparenza è uno dei soliti plugin di backup/ripristino di una installazione di WordPress, che alla fine richiedono sempre l’acquisto della versione Pro per essere davvero utili. Duplicator invece è diverso, la versione Pro aggiunge delle funzioni molto interessanti per chi gestisce dei siti web per professione, ma la versione base gratuita fa tutto quello che mi serve, è solo leggermente più complicata da utilizzare.

In previsione del piano B ho già provato a fondo Duplicator, usandolo per fare un backup completo del sito e per ripristinarlo in una nuova istanza di AWS Cloud9, e funziona in modo spettacolare. Mi piace soprattutto il fatto che lavori a bassissimo livello, sembra quasi di usare il terminale, che è poi quello che farei io stesso se il provider mi concedesse un accesso pieno e senza limitazioni via ssh al mio sito e soprattutto al database associato.

Entro quindi nel pannello di controllo del mio sito web e di tutti i tool collegati, il notissimo cPanel, cancello tutti i file del sito e anche il database che ha creato tanti problemi, e già che ci sono aggiorno PHP alla versione 7.2, la stessa versione disponibile in AWS Cloud9. Mi tremano un po’ i polsi, da ora in poi se sbaglio non posso più tornare indietro, ma ho delle alternative migliori?

A differenza degli altri plugin di backup/ripristino che conosco, Duplicator non ha bisogno di una installazione preesistente di WordPress per funzionare, ma insieme al backup del sito genera un programma in PHP che effettua da solo il processo di ripristino del sito e del database associato. Anche l’URL che ho modificato a mano diretatmente nel database vengono aggiornati correttamente. Bastano pochi minuti e il sito torna a vivere.

È il 2 gennaio, sono passati ben 14 giorni dal disastro.

Conclusioni

Quando dicevo all’inizio che la lettura di questo articolo non è adatta a chi si spaventa facilmente o è ansioso, stavo scherzando, ma non troppo. Questa esperienza ha davvero messo a dura prova le mie capacità tecniche, nonché la mia pazienza nell’interagire con chi dovrebbe fornire un supporto tecnico decente.

Ma dopo un paio di giorni era diventata una sfida personale, una specie di esame fuori tempo massimo, sei capace di risolvere questo problema difficile? E poi, naturalmente, c’era la necessità di non fare brutta figura con tanti colleghi…

Ovvio che alla scadenza del contratto bisognerà cambiare provider, tutto sommato questo finora non è stato male, ma finché va tutto bene sono buoni tutti, le differenze si vedono solo quando il gioco si fa duro. Avevo già pensato di farlo per altri motivi, ma il dover traslocare il sito su un’altro spazio web mi preoccupava un po’. Ora, con l’esperienza che mi sono fatta, sarà uno scherzetto.


  1. A differenza delle versioni normali di Ubuntu Linux, che vengono rilasciate ogni sei mesi, le versioni LTS, Long Term Support, vengono rilasciate solo nella primavera degli anni pari e sono particolarmente indicate per un sistema server. 
  2. MariaDB è un derivato (fork) del notissimo database MySQL, prodotto dagli sviluppatori originali di MySQL e compatibile praticamente al 100% con la versione corrispondente di MySQL. L’origine del fork sta nell’introduzione da parte di Oracle, che nel 2010 ha acquisito la ormai decaduta Sun Microsystems con tutto il suo parco software fra cui Java e proprio MySQL, di estensioni proprietarie disponibili solo per la versione a pagamento di MySQL. 
  3. Bisogna aggiungere nel file wp-config.php la riga define('WP_ALLOW_REPAIR', true);, andare all’URL di amministrazione YOURSITE.com/wp-admin/maint/repair.php (dove YOURSITE.com deve essere sostituito con l’indirizzo web del sito) e seguire le istruzioni. 
Tagged with: , , , , , , , , , , , ,
Pubblicato su software

Come creare una chiavetta USB per installare macOS


Fonte: Ferdinand Stöhr su Unsplash.

Nell’articolo precedente, Come scaricare le versioni meno recenti di macOS: un anno dopo, abbiamo visto che da qualche mese Apple ha messo a disposizione delle versioni aggiornate dei programmi di installazione di macOS, da 10.10 Yosemite a 10.15 Catalina, utilizzando due diversi formati di file. Le versioni più recenti di macOS (High Sierra, Mojave e Catalina) sono disponibili solo come normali applicazioni per il Mac (formato .app), quella più vecchia (Yosemite) si può scaricare solo in formato immagine (o .dmg), mentre le due versioni intermedie sono disponibili sia come applicazioni che come immagini.

Ma una volta finito di scaricare uno dei programmi di installazione di macOS disponibili, come si fa ad installarlo sul Mac?1

Aggiornare macOS non è difficile, ma cosa dobbiamo fare se vogliamo partire da zero? È sufficiente aprire il Terminale e seguire queste istruzioni per creare una chiavetta USB avviabile da cui eseguire una installazione pulita di macOS. Ma prima di farlo è meglio chiarire la differenza fra i due tipi di programmi di installazione di macOS messi a disposizione da Apple.

Due formati convergenti

I programmi di installazione disponibili come normali applicazioni per il Mac vengono scaricati nella cartella Applicazioni e si aprono automaticamente; con questi è possibile aggiornare in pochi minuti la versione di macOS installata sul Mac seguendo le semplici istruzioni che compaiono sullo schermo. Se invece vogliamo effettuare una nuova installazione di macOS, dobbiamo chiudere il programma (dal menu o con la combinazione di tasti ⌘-Q) ed eseguire un semplice comando di Terminale che trasferisce il programma di installazione presente in Applicazioni su una chiavetta USB, da cui avviare il Mac ed eseguire l’installazione di macOS.

Di contro, questo tipo di programmi di installazione richiedono il collegamento all’App Store e possono essere scaricati solo da chi lo ha già fatto in passato, quando erano disponibili sull’App Store, utilizzando un Mac compatibile con la versione di macOS desiderata (fa eccezione Catalina, la versione più recente di macOS, che è scaricabile liberamente dall’App Store da chiunque sia in possesso di un Mac compatibile).

I programmi di installazione in formato immagine, invece, possono essere scaricati liberamente dal sito di Apple senza passare dall’App Store, indipendentemente dal fatto che possano girare o no sul Mac usato per scaricarli. Una volta completato lo scaricamento, basta fare doppio click sul file .dmg per montare il file immagine sul Desktop del Mac e aprire una cartella contenente un tipico pacchetto (package) di installazione di macOS (l’analogo per il Mac dei ben più noti pacchetti di installazione per Windows o per Linux). Nella figura qui sotto è mostrato quello relativo a El Capitan, che utilizza ancora la vecchia denominazione “Mac OS X”,

questo invece è relativo a Sierra.

Un doppio click sul file .pkg fa partire l’installatore vero e proprio, che verifica che il programma in questione possa essere eseguito sul Mac,

e poi esegue la procedura di installazione standard di un package per macOS,


alla fine della quale troveremo in Applicazioni il programma vero e proprio di installazione di macOS, nella forma di una normale applicazione per il Mac, proprio come nel caso precedente.

Aggiornare o partire da zero?

In definitiva, qualunque sia il formato che decidiamo di scaricare, alla fine ritroveremo sempre in Applicazioni una applicazione per il Mac contenente il programma di installazione di macOS, e sarà questa che utilizzeremo per i passi successivi.

Se non si è già aperto automaticamente, possiamo fare doppio click sul programma di installazione presente in Applicazioni per aggiornare macOS alla versione desiderata, senza toccare le applicazioni e i documenti già presenti sul Mac.

Ma ci sono casi in cui si vuole ripartire da zero, ad esempio perché si è cambiato il disco di avvio del Mac, perché si è acquistato un Mac usato o perché, al contrario, si desidera vendere il Mac cancellando tutti i nostri dati e programmi dal sistema ma fornendo all’acquirente un computer con il sistema operativo preinstallato, utilizzabile sin dal primo momento. Oppure semplicemente perché abbiamo fatto dei pasticci e vogliamo ripartire da un sistema pulito.

Qualunque sia la ragione, per installare macOS da zero abbiamo davanti due alternative: la prima prevede di utilizzare macOS Recovery per installare l’ultima versione di macOS compatibile con il nostro modello di Mac, scaricandola eventualmente dalla rete.

L’altra alternativa richiede invece l’utilizzo di una chiavetta USB avviabile, sulla quale trasferire il programma di installazione di macOS scaricato. Una volta avviato il Mac dalla chiavetta USB si potrà installare macOS sul disco interno del Mac o eventualmente su un disco esterno collegato ad una porta USB3, Thunderbird o, per chi ce l’ha ancora, FireWire.

Creare una chiavetta USB avviabile

Utilizzare una chiavetta USB è molto più flessibile, perché a differenza di macOS Recovery ci permette di installare qualunque versione di macOS compatibile con il modello di Mac che stiamo utilizzando, senza nemmeno dover accedere alla rete o inserire i nostri dati personali per scaricare macOS. Avviare il Mac dalla chiavetta USB permette anche di cancellare preventivamente il disco rigido di avvio, partendo quindi da un sistema pulito. Altro aspetto a volte non trascurabile è che possiamo ripetere rapidamente l’intero processo di installazione su più Mac, senza dover attendere ogni volta lo scaricamento del programma di installazione.

Questa flessibilità ha un piccolo costo, perché richiede l’utilizzo del Terminale, ma basta seguire le istruzioni seguenti con un minimo di attenzione per non avere problemi.

Serve una chiavetta USB da almeno 8 GB (da almeno 16 GB per Catalina), vuota o contenente dei file che non servono più, perché nei passi successivi sarà cancellata completamente, senza troppe possibilità di recupero dei dati pre-esistenti. Per cui fate attenzione!, perché potreste perdere dei dati importanti.

Bisogna rinominare la chiavetta USB in modo che abbia un nome standard, che verrà usato in tutte le istruzioni successive. Il nome in sé non è importante, tanto sarà modificato nel corso del trasferimento del programma di installazione di macOS sulla chiavetta, ma usarne uno standard semplifica la scrittura dei comandi da Terminale. Per cui chiamiamola “InstallazioneUSB”, senza spazi, e non pensiamoci più.

La chiavetta USB deve essere formattata in formato Mac OS esteso con Mappa partizione GUID, se non siamo sicuri che sia già nel formato giusto lanciamo Utility Disco (si trova in Applicazioni → Utility) e selezioniamo le stesse opzioni mostrate nella figura qui sotto. Anche il nome da dare alla chiavetta può essere inserito in questo momento.

Ogni volta che si usa Utility Disco, bisogna stare molto attenti a non formattare per sbaglio un altro disco collegato al Mac, ma basta guardare la dimensione del disco da formattare, ben visibile in un riquadro in alto a destra della finestra di Utility Disco, per non sbagliare.

A questo punto si può lanciare il Terminale di macOS (anche questo si trova in Applicazioni → Utility) ed eseguire createinstallmedia, un programma nascosto da Apple in tutte le versioni gratuite dei programmi di installazione di macOS distribuite tramite l’App Store, che permette di trasferire sulla chiavetta USB i file di installazione di macOS. Le opzioni necessarie per il corretto funzionamento di createinstallmedia variano leggermente a seconda della versione di macOS e qui sotto è riportato il comando completo da utilizzare per ciascuna versione di macOS che è possibile trasferire sulla chiavetta.

Catalina

$ sudo /Applications/Install\ macOS\ Catalina.app/Contents/Resources/createinstallmedia --volume /Volumes/InstallazioneUSB && osascript -e 'display notification "Trasferimento completato." with title "Terminale"'

Mojave

$ sudo /Applications/Install\ macOS\ Mojave.app/Contents/Resources/createinstallmedia --volume /Volumes/InstallazioneUSB && osascript -e 'display notification "Trasferimento completato." with title "Terminale"'

High Sierra

$ sudo /Applications/Install\ macOS\ High\ Sierra.app/Contents/Resources/createinstallmedia --volume /Volumes/InstallazioneUSB && osascript -e 'display notification "Trasferimento completato." with title "Terminale"'

Sierra

$ sudo /Applications/Install\ macOS\ Sierra.app/Contents/Resources/createinstallmedia --volume /Volumes/InstallazioneUSB --applicationpath /Applications/Install\ macOS\ Sierra.app && osascript -e 'display notification "Trasferimento completato." with title "Terminale"'

El Capitan

$ sudo /Applications/Install\ OS\ X\ El\ Capitan.app/Contents/Resources/createinstallmedia --volume /Volumes/InstallazioneUSB --applicationpath /Applications/Install\ OS\ X\ El\ Capitan.app && osascript -e 'display notification "Trasferimento completato." with title "Terminale"'

Yosemite

$ sudo /Applications/Install\ OS\ X\ Yosemite.app/Contents/Resources/createinstallmedia --volume /Volumes/InstallazioneUSB --applicationpath /Applications/Install\ OS\ X\ Yosemite.app --nointeraction && osascript -e 'display notification "Trasferimento completato." with title "Terminale"'

Anche Mavericks può essere trasferito su una chiavetta USB con lo stesso metodo, sempre ammesso che si riesca a trovare da qualche parte il programma di installazione di questa versione del sistema operativo desktop di Apple.

$ sudo /Applications/Install\ OS\ X\ Mavericks.app/Contents/Resources/createinstallmedia --volume /Volumes/InstallazioneUSB --applicationpath /Applications/Install\ OS\ X\ Mavericks.app --nointeraction && osascript -e 'display notification "Trasferimento completato." with title "Terminale"'

Come sempre il simbolo $ indica il prompt del Terminale di macOS e non fa parte del comando.

I comandi elencati vanno eseguiti da un account di tipo Amministratore; se siete l’unico utente del Mac siete automaticamente un amministratore del sistema, altrimenti dovete fare login in un account di questo tipo e riprovare oppure dovete chiedere all’amministratore del vostro Mac di eseguirlo per voi. Subito dopo aver premuto Invio vi verrà chiesta la password di login del vostro account, seguita da una richiesta di conferma dell’operazione di trasferimento del programma di installazione di macOS sulla chiavetta USB.

Il trasferimento del programma di installazione di macOS sulla chiavetta USB dura parecchio, almeno cinque minuti e spesso molto di più, a seconda della velocità di scrittura della chiavetta USB. Nel frattempo potete tranquillamente fare altro: una volta concluso positivamente il processo di trasferimento, il Mac provvederà a notificarcelo direttamente sul Desktop e farà anche ricomparire il prompt del Terminale.

Chi preferisce un avviso sonoro può sostituire la seconda parte del comando, da osascript -e ... fino alla fine della linea, con say "Trasferimento completato". Assicuratevi di aver installato il supporto per le voci in italiano (tramite Preferenze di Sistema → Accessibilità → Voce oppure Preferenze di Sistema → Dettatura e voce → Testo da pronunciare, a seconda della versione di macOS presente sul Mac) altrimenti vi sembrerà di sentire Ollio, ma in ogni caso un avviso sonoro sembra qui più efficace di una notifica.

Per chi vuole uno strumento grafico

Il Terminale è un strumento potentissimo, ma tanti utenti del Mac vengono messi a disagio dalla sua interfaccia spartana a linea di comando, e hanno quasi paura di usarlo temendo di fare danni. In questo caso specifico è molto difficile, se si seguono attentamente le istruzioni è impossibile sbagliare. Ma visto che ci sono due buoni strumenti che permettono di trasferire un programma di installazione di macOS su una chiavetta USB tramite una interfaccia grafica, perché non segnalarli?

Tanto è facile, sono solo due, Install Disk Creator e DiskMaker X, entrambe gratuiti (la versione Pro di DiskMaker X serve solo a chi deve installare macOS su un gran numero di Mac diversi o si occupa di supporto tecnico). Ammetto di non averli mai usate perché con il Terminale faccio prima, ma sono entrambi degli strumenti noti e notoriamente affidabili, chi decidesse di usarli non avrà problemi. E nel caso, c’è sempre il Terminale…


  1. Per semplicità nel testo dell’articolo userò sempre il termine “macOS” anche per indicare le versioni che in origine si chiamavano OS X. 
Tagged with: , , , , , ,
Pubblicato su software

Buon Natale dal Terminale

C’è gente che con il Terminale sarebbe in grado di far volare un Boeing. Oppure che sa costruire un alberello di Natale pieno di lucine colorate, come questo.

Se lo volete anche voi, vi basta aprire il Terminale ed eseguire

$ curl https://raw.githubusercontent.com/sergiolepore/ChristBASHTree/master/tree-EN.sh | bash

oppure, se preferite la versione tradotta in italiano,

$ curl https://raw.githubusercontent.com/sabinomaggi/ChristBASHTree/master/tree-IT.sh | bash

(come sempre il $ rappresenta il prompt del terminale e non fa parte del comando).

Buon Natale!!!

Tagged with: , ,
Pubblicato su programmazione

Come cambiare la data in macOS


Fonte: JustHourglasses.

“Ma stai scherzando? Perché ci vuoi propinare uno dei tuoi soliti lunghissimi articoli solo per insegnarci a cambiare la data in macOS? Non lo sai che basta essere collegati ad internet e il Mac fa tutto da solo?”

Data e ora in macOS

Avete ragione, macOS (così come qualunque sistema operativo moderno) è perfettamente in grado di gestire da solo la data e l’ora. Gli basta collegarsi ai server Apple sui quali gira il servizio NTP (Network Time Protocol) per sincronizzare l’orologio interno del Mac con l’ora ufficiale di uno degli orologi atomici sparsi nel mondo.

Però ci sono almeno due casi in cui dobbiamo impostare data (e ora) a mano.

Il primo si verifica quando vogliamo aggiornare o installare ex-novo macOS utilizzando un programma di installazione scaricato prima della data fatidica del 24 ottobre di quest’anno, data nella quale Apple ha aggiornato la firma digitale di tutte le versioni di mac OS distribuite attraverso l’App Store (cioè da Lion in poi).

Il secondo caso si presenta quando la batteria montata sulla scheda madre del Mac invecchia e non riesce più a conservare le impostazioni del sistema, fra cui proprio la data e l’ora. Non potendo più contare sulla batteria interna, ad ogni riavvio la data del Mac si resetta al primo gennaio del 1970, al 2000 o a qualche altro giorno ormai lontano nel tempo.1 Se proviamo ad aggiornare o ad installare macOS senza aver prima corretto la data, il Mac si può rifiutare categoricamente di procedere, con dei messaggi di errore così criptici da essere praticamente inutili, come questo di El Capitan,

o quest’altro di Sierra.

Le schermate di sopra sono state ottenute provando a installare macOS in Parallels. Con High Sierra e Mojave la data sbagliata non impedisce di completare il processo di installazione, ma non so dire se è una correzione inserita volutamente da Apple in queste versioni più recenti di macOS oppure è un effetto dell’emulatore.

Per impostare a mano la data possiamo usare due procedure diverse: una usa l’interfaccia grafica del Mac, l’altra ha bisogno del Terminale. Possiamo utilizzare la prima se abbiamo già macOS funzionante e vogliamo solo aggiornarlo, l’altra invece è necessaria quando dobbiamo installare macOS da zero, ad esempio perché macOS non riesce ad avviarsi (rarissimo, ma può succedere) o perché abbiamo cambiato il disco rigido del Mac.

Quando macOS è già installato

Se macOS è già installato sul Mac e vogliamo aggiornarlo utilizzando un programma di installazione scaricato prima del 24 ottobre — perché siamo pigri e non vogliamo scaricare di nuovo il programma di installazione di macOS oppure perché non troviamo più sull’App Store la versione di macOS che ci interessa — possiamo continuare a farlo con un trucco semplicissimo, che risale quasi alla notte dei tempi (informatici). Basta cambiare la data del Mac facendo in modo che sia precedente al 24 ottobre. Una volta concluso il processo di installazione potremo ripristinare senza problemi la data reale.

Un altro scenario possibile si presenta quando la batteria montata sulla scheda madre non riesce a conservare le impostazioni di data ed ora. In questo caso, per motivi che mi sfuggono, i server NTP non riescono a reimpostare automaticamente la data e l’ora corretta e bisogna per forza di cose fare a mano.

Qualunque sia la ragione, cambiare a mano la data del Mac dall’interfaccia grafica è facilissimo, come si vede nelle schermate seguenti.

Bisogna aprire le Preferenze di Sistema e fare doppio click sulle impostazioni di Data e Ora,


cliccare sull’icona del lucchetto per abilitare le modifiche e inserire nome utente e password (e no, le mie password non sono solo di quattro caratteri!),

deselezionare l’opzione che imposta automaticamente la data e l’ora e inserire nei campi sottostanti la data e l’ora desiderata, premendo il tasto Salva per confermare le modifiche,


e infine selezionare di nuovo l’opzione che imposta automaticamente la data e l’ora.

Se volete fare i fini potete anche impostare, al posto dei server NTP gestiti da Apple, uno dei server NTP ufficiali del nostro paese, ntp1.inrim.it, ntp2.inrim.it, time.inrim.it, premendo poi il tasto Invio per confermare la nuova impostazione,


e cliccando poi sull’icona del lucchetto per disabilitare ulteriori modifiche.

Quando dobbiamo partire da zero

Tutti i PC permettono di modificare la data e l’ora del sistema tramite il BIOS, senza aver bisogno di avviare il sistema operativo (i PC moderni, e anche il Mac, ormai usano l’EFI, Extensible Firmware Interface, ma il termine BIOS è rimasto scolpito nella memoria).

Anche i Mac con processore PowerPC potevano modificare data ed ora tramite l’Open Firmware, una specie di BIOS potenziato sviluppato da Sun e utilizzato da Apple per tutti i suoi Mac prima del passaggio ai processori Intel.

Sui Mac moderni, invece, l’unica possibilità per impostare a mano la data e l’ora senza utilizzare il sistema operativo è tramite la funzione di macOS Recovery, che normalmente viene richiamata premendo i tasti CMD (⌘) ed R all’avvio del Mac. Se sul disco rigido è già presente una partizione dedicata a macOS Recovery (normalmente invisibile ai normali strumenti di gestione dei file), l’utility verrà caricata da questa partizione, altrimenti il Mac provvederà a scaricare macOS Recovery da Internet e ad installarla sul disco di avvio del Mac.

Un’altra possibilità per accedere a macOS Recovery è quella di utilizzare una chiavetta USB avviabile che contiene un programma di installazione di macOS.

In tutti i casi, una volta avviato macOS Recovery e selezionata la lingua dell’interfaccia,

comparirà la schermata principale dell’utility di ripristino di macOS.

A questo punto bisogna selezionare il Terminale dal menu Utility,

e aspettare qualche secondo che compaia il Terminale al posto dell’interfaccia principale di macOS Recovery (si noti che, anche se abbiamo impostato l’italiano come lingua del sistema, il Terminale parla sempre e solo in inglese).

Per impostare la data e l’ora bisogna utilizzare il comando date seguito dalla data e dall’ora in un formato piuttosto astruso, MMDDhhmmYYYY, dove MM indica il mese (scritto sempre con due cifre, premettendo eventualmente lo zero), DD il giorno (sempre con due cifre), hh e mm l’ora e il minuto da impostare (c’è bisogno di dire che anche questi vanno scritti sempre con due cifre?) e infine YYYY indica l’anno. Qui sotto, ad esempio, ho impostato il mese di dicembre (12), il giorno 11, le ore 18 e 10 minuti e l’anno corrente (2019).

Se invece vogliamo impostare la data e l’ora del nostro Mac alle nove e trentacinque del mattino del quindici luglio 2018, dovremo scrivere nel Terminale

date 071509352018

Una volta impostata la data possiamo chiudere il Terminale e ritornare alla schermata principale di macOS Recovery, per proseguire l’installazione di macOS oppure riavviare il Mac senza installare nulla.

Conclusioni

Scrivere questo articolo è stato piuttosto noioso e questo fatto, insieme a svariati impegni lavorativi e familiari, ha contribuito ad allungare a dismisura i tempi di pubblicazione.

Ma anche se l’argomento trattato non è dei più interessanti, ho voluto pubblicarlo lo stesso perché la prima volta che non sono riuscito ad installare macOS a causa della data sbagliata ho dovuto faticare parecchio per capire cosa stesse succedendo. Se risparmierò questa fatica a qualche lettore del blog ne sarà valsa la pena.


  1. Il 1 gennaio 1970 è la data in cui è iniziato il tempo, almeno secondo UNIX. 
Tagged with: , , , , , ,
Pubblicato su software
Informativa
Questo sito utilizza cookie di terze parti per inviarti pubblicità e servizi in linea con le tue preferenze. Se vuoi saperne di più o negare il consenso a tutti o ad alcuni cookie, clicca qui. Scorrendo questa pagina, cliccando su un link o su qualunque altro elemento o proseguendo la navigazione in altra maniera, acconsenti all'uso dei cookie.
Follow MelaBit on WordPress.com
Categorie
%d blogger hanno fatto clic su Mi Piace per questo: