Oltre ad essere un’autorità in materia di certificazione, il loro sito è una miniera di risorse gratuite.

Per chi conosce i loro percorsi di certificazione, sa che che sono strutturati nel modo seguente:

• Essentials
  • Linux
  • Security
  • Web Developer
  • Open Source
• Linux Professional
  • LPIC-1
  • LPIC-2
  • LPIC-3
    • Mixed Environemnts
    • Security
    • Virtualization and Containerization
    • High Availability and Storage Clusters
• Open Technology
  • DevOps Tools Engineer
  • BSD Specialist

La prima certificazione è il percorso pensato per chi vuole conseguire una conoscenza di base su un sistema Gnu/Linux.

LPIC-1-2-3 possiamo pensarli come percorsi di certificazione per acquisire competenze rispettivamente per l’amministratore Gnu/Linux di base, esperto su reti di piccole e medie dimensioni e esperto verticale.

Open Technology è rivolta invece a chi vuole essere specialista di strumenti DevOps o di BSD.

LPI mette a disposizione una quantità enorme di materiale gratuito che copre Linux Essentials e LPIC-1 e che è possibile reperire qui: https://learning.lpi.org/it/learning-materials/all-materials/ (il materiale italiano è qui: https://learning.lpi.org/it/)

In particolare, LPIC-1-101 e LPIC-1-102, che sono quelli relativi al percorso di amministrazione di base, sono compresi ed estesi da un altro volume, una vera bibbia, edita da TrueLite e giunta ormai alla sesta edizione: Amministrare Gnu/Linux di Simone Piccardi (https://www.truelite.it/libri/amministrare-gnu-linux/) che copre e amplia sia LPIC-1 nella sua interezza (101 e 102) che LPIC-2 (anche se non completamente).

Se LPIC-1-101 e LPIC-1-102 sono verticali per il superamento dell’esame LPIC-1, Amministrare Gnu/Linux è un testo dal respiro molto più ampio, che copre come detto anche buona parte di LPIC-2 e che va considerato, non tanto come un testo alternativo per la preparazione dell’esame di certificazione, quanto piuttosto come un riferimento imprescindibile per un amministratore di sistemi Gnu/Linux.

TrueLite, per non essere da meno, in ossequio alla filosofia di sviluppo Gnu/Linux, offre il libro pubblicato con licenza libera, sia in vendita (che vale ogni centesimo speso e vale la pena averlo in libreria) che disponibile sui loro repository come sorgente LaTeX. E con quelli è possibile ricavare il pdf.

Per farlo ho seguito le loro istruzioni che prevedono Debian come S.O. di riferimento ma si adattano facilmente anche su Fedora 43 (il mio).

Per prima cosa installiamo le dipendenze che differiscono un po’ da quelle indicate:

dnf install dia inkscape make netpbm texlive-base texlive-pstricks texlive-luatex latexml luahbtex texlive-unicode-math texlive-babel-italian latexml texlive-comment texlive-luapstricks texlive-multirow texlive-mlmodern

Dovrebbero coprire tutto il necessario.

Un’altra cosa che servirà, per avere la resa tipografica conforme a quanto stabilito dall’autore, è il font UbuntuMono che preleverò dal repository di Canonical:

# creazione dalla cartella dei font in locale
mkdir -p ~/.local/share/fonts/UbuntuMono
 
# scaricamento del font
wget -O /tmp/UbuntuMono-v1.002.zip
https://github.com/canonical/Ubuntu-Sans-Mono-fonts/releases/download/v1.002/UbuntuMono-fonts-1.002.zip
 
# decompressione dell'archivio
unzip UbuntuMono-v1.002.zip
 
# copia dei file ttf nella cartella dei font della nostra home
cp /tmp/UbuntuMono-fonts-1.002/ttf/* ~/.local/share/fonts/UbuntuMono
 
# caricamento del font
fc-cache -f
 
# verifica
fc-list | grep -i 'Ubuntu Mono'

Sistemati i prerequisiti, possiamo prelevare il sorgente LaTeX del testo dal repository TrueLite e procedere con la compilazione:

# clone del repository
git clone https://labs.truelite.it/git/truedoc

Creazione delle immagini usate nella compilazione del libro:

# creazione delle immagini
cd truedoc/
make
for i in mailservices sicurezza webservices ldap agl; do
    cd $i
    make images
    cd ..
done

Infine, per creare il libro completo di bibliografia e indici:

cd agl
lualatex agl.tex
makeindex agl
bibtex agl
lualatex agl.tex
lualatex agl.tex

Non dovrebbe esserci alcun errore (solo un po’ di warning) e nella stessa cartella troverete il libro “Amministrare Gnu/Linux”, sotto forma di un grazioso acronimo (agl.pdf), in tutte le sue maestose e densissime 806 pagine!

Buona lettura!

#amministrareGnuLinux #fedora #fedora43 #GnuLinux #LaTeX #sistemistaGnuLinux

Ieri ho dimenticato di descrivere cosa ho fatto, venendo meno al senso stesso di questo blog che è, prima di tutto, un blocco note in cui riversare tutto quello mi passa per la testa quando “amministro”.

Upgrade F36 → F37

Ho scelto la via della cli ^[1] che mi permette di seguire passo-passo quello che succede. L'approccio è comunque conservativo. Si scaricano i pacchetti e l'upgrade avviene al reboot in un ambiente controllato, non a caldo.

# export app installed
flatpak list --runtime > flatpak_runtime_fw6.txt
flatpak list --app > flatpak_app_fw36.txt
snap list > snap_install_fw36.txt
dnf list installed > dnf_install_fw36.txt

# upgrade
dnf upgrade --refresh && reboot

# Installazione plugin di upgrade
dnf install dnf-plugin-system-upgrade

# Download dei pacchetti di Fedora 37
dnf system-upgrade download --releasever=37

# Reboot e upgrade
dnf system-upgrade reboot

# Pulizia
dnf clean
flatpak uninstall --unused
# da https://superuser.com/questions/1310825/how-to-remove-old-version-of-installed-snaps/1330590#1330590
set -eu
snap list --all | awk '/disabled/{print $1, $3}' |
    while read snapname revision; do
        snap remove "$snapname" --revision="$revision"
    done

Installazione Dropbox

Se non si vuole sporcare il sistema installando nemo-dropbox ^[2], si può installare il solo dropbox rinunciando agli indicator sul file manager. nemo-desktop, del resto, produceva lo stesso risultato nei confronti di nautilus.

Il pacchetto è sempre lo stesso da Fedora 35 solo che, fino a Fedora 36, l'integrazione con nautilus c'era. Al momento, ancora no. Direttamente da RPMFusion-Nonfree, per l'installazione è sufficiente:

rpm -vuH https://download1.rpmfusion.org/nonfree/fedora/releases/35/Everything/x86_64/os/Packages/d/dropbox-2020.03.04-3.fc35.noarch.rpm

#fedora37 #gnulinux #upgrade #nautilus #dropbox

Non ce l'ho fatta ad aspettare.

Il mio iniziale approccio prudenziale è stato fagocitato in un sol boccone da un'insana curiosità e così, ieri pomeriggio, mi è sembrato del tutto normale infrangere le più elementari norme di buon senso. Niente backup e via all'aggiornamento sulla macchina più critica.

L'aggiornamento in fondo è andato bene. Mmm... benino, per essere precisi.

Cosa è andato bene

L'aggiornamento.

Alla fine, sto scrivendo su un pc con Fedora 37 che fa il suo onesto lavoro.

Cosa non è andato bene

L'aggiornamento.

In alcuni suoi punti.

Partizionamento disco

Comincio da quello che è una mia incuria. Ho sovrastimato la bontà del partizionamento fatto a suo tempo e 50GB di root, che mi sembravano più che sufficienti, hanno mostrato la corda in un maniera piuttosto evidente.

Arrivati quasi alla fine del processo di acquisizione dei file (fatto da cli e non dal software center), si blocca perché il disco è quasi pieno e l'aggiornamento aveva bisogno di poco più di 2GB per essere completato. Recupero spazio cancellando un po' di log e riesco a finire per il rotto della cuffia.

Riconosco di non aver misurato a sufficienza il fattore di crescita di /usr e /var anche in presenza di installazioni flatpak (a livello di sistema e non di utente, ancora mea culpa) e snap.

Una volta finito, faccio piazza pulita anche dei flatpak inutilizzati e degli snap disabilitati per raschiare un altro po' di spazio.

Dipendenze rotte

Da che uso Gnu/Linux, ogni aggiornamento ad una major release mi lascia sempre un po' di cadaveri soprattutto quando il sistema non è immacolato e qua e là spuntano repository di terze parti.

Sono abituato. E così, prima dell'aggiornamento metto sempre da parte il listone delle app installate, prendo nota di ciò che viene segato man mano (la mia unica nota di merito in questa storia) e poi inizio la paziente opera di ricostruzione che non è mai immediata, soprattuto se dipende dai repository terzi che potrebbero impiegare qualche giorno prima di rilasciare le build per la nuova release.

La prima vittima è VirtualBox. Il suo repository non ha ancora rilasciato l'ultima versione per F37 Continuo a usare quella per F36. Poco male, repository disabilitato per ora. .

Poi un falso positivo, mlocate, sostituito in realtà da plocate.

Infine Dropbox.

nautilus-dropbox non è più presente, così ripiego su nemo-dropbox, che si porta dietro il metapacchetto cinammon-desktop e un altro po' di dipendenze, ma poca roba.

Nonostante il rimorso sulla dimensione della root faccia subito sentire la sua voce, lo considero un sacrificio accettabile, soprattutto perché ha il carattere della temporaneità.

L'alternativa sarebbe usare l'rpm secco dal sito Dropbox ma quando provo ad installarlo ecco il primo vero allarme della giornata:

Problema: conflicting requests
  - nothing provides libnautilus-extension.so.1()(64bit) needed by nautilus-dropbox-2020.03.04-1.fc21.x86_64
(try to add '--skip-broken' to skip uninstallable packages)

Come riportato su ask.fedoraproject.org:

Nautilus changed extension API in GNOME 43, but Dropbox haven’t updated their extension yet. There is a fix 68 provided by the community, but Dropbox maintainers haven’t responded yet.

RPMFusion, a popular alternative place to get Dropbox, removed 22 nautilus-dropbox package for similar reasons – not able to build it and also lacking maintainers.

In altre parole, Nautlus ha cambiato le sue API, Dropbox non ha modificato l'estensione e non si parlano più.

Brutta cosa.

E poi c'è il runtime di qt5.

Da quello che ho potuto capire, F37 installa di base la versione 5.15.16-1 ma negli updates di Fedora è subito comparsa la versione 5.15.17-1 che però non può essere installata perché alcuni pacchetti richiedono la 5.15.16-1, altri richiedono (o richiederebbero, se sono aggiornamenti come keepassxc che quindi vengono congelati) la 5.15.17-1 e insieme non possono coesistere.

Potrei forzare l'aggiornamento ma sono certo che andrei a rompere alcune applicazioni nel migliore dei casi o ne provocherei addirittura la rimozione. Devo solo sperare che, mano mano, tutte le applicazioni vengano ricompilate col nuovo runtime così da poter aggiornare in maniera indolore.

Brutta cosa (e sono due).

Conclusioni

L'aggiornamento alla fine è andato bene, niente che non possa essere superato.

All'inizio avevo attribuito la cosa alle varie gradazioni di aggiornamento che hanno attraversato questa macchina da Fedora 33, ma sono ormai certo che non c'entri nulla. Anche se partissi con un'installazione pulita, quello che otterrei, al più, è che alcune applicazioni non potrei installarle per niente perché:

• mi mancherebbe un'estensione aggiornata
• non avrei il runtime corretto.

Gnu/Linux è così. Non è fatto per i deboli di cuore o per chi non abbia un buono spirito di adattamento.

Ma piace anche per questo e ne vale la pena.

Edit 18/11/2022

È appena uscito l'aggiornamento al runtime qt5 versione 5.15.17-1. Una buona parte dei miei problemi sono dunque rientrati a riprova che se avessi aspettato almeno una settimana, mi sarei evitato questo sbattimento.

#fedora37 #gnulinux #upgrade #qt5 # brokenpackages #nautilus #dropbox

#fedora37 #gnulinux #upgrade