mi presento, sono Andrea Venturi e utilizzo Debian da tanti anni, perché è per me sempre stata una distribuzione "filosoficamente" evoluta ed "operativamente" affidabile. estremamente affidabile ed innovativa.
Utilizzo Debian come PC e come distribuzione per server che installo e gestisco poi da remoto via openvpn / ssh.
Ho anche "roba" vecchia, che per vari motivi, essendo in reti isolate e che funzionano, rimangono con distribuzioni piuttosto vecchie (e che non ritengo utile aggiornare perché fanno il loro mestiere e a cambiare le cose, a volte si "rompono"!). Capisco però che altri possono avere diverse opinioni.
A questo giro però, per colpa di una mia ingenuità, son rimasto "chiuso fuori" e sto cercando un modo per evitare una trasferta assurda (che di questi tempi è anche impossibile tecnicamente!)
Questa storia spero che possa anche essere interessante..
Stiamo parlando di una Debian 7 Wheezy (il cui ultimo uptime era di 320 giorni, quando stavo facendo la manutenzione)
Tutto è scatenato quando mi hanno connesso, per fare backup, un disco USB da 500GB ma partizionato GPT. A me francamente bastava MBR e quindi ho cercato di "tornare" indietro (anche perché il kernel è ancora un 3.2.0..) come partizione, e da internet ho visto che esiste una utilità "gdisk" che ha una opzione avanzata per "togliere" le signature GPT dal disco.
purtroppo gdisk non era installata su quella Wheezy che peraltro è finita in archive.debian.org ed adesso i pacchetti si trovano solo qua:
http://archive.debian.org/debian/dists/
A voler fare un aggiornamento "completo" chissà quanti pacchetti e quanti rischi di "instabilità" temporanea; non avendo la macchina in locale, ho cercato un approccio più conservativo possibile.
Ho scaricato il gdisk e poi ho cercato di capire quali dipendenze aveva per ridurre al minimo i pacchetti da aggiornare. Parliamo di una utility a linea di comando quindi speravo poco o niente.
La dipendenza che mi procurato i guai è stata quella delle librerie ncurses per gestire quei menu che si vedono anche nel "menuconfig" del kernel linux..
trovate qua le versioni gestire da Debian, nelle varie distro.
http://archive.debian.org/debian/pool/main/n/ncurses/
ncurses dipende da lib32tinfo
ed io sul sistema avevo questa: lib32tinfo5_5.9-10 del 27.6.2012
http://archive.debian.org/debian/pool/m ... _amd64.deb
ma gdisk richiede la: lib32tinfo5_5.9+20140913 del 13.6.2018 (chissà quale buco di sicurezza!)
http://archive.debian.org/debian/pool/m ... _amd64.deb
vabbè, scarico ed installo con dpkg questa lib in formato Deb e vado avanti col mio lavoro, tranquillo..
Un giorno dopo, vado per accedere al server in ssh e salta fuori IL PROBLEMA!
$ ssh username@serverRemoto
username@server's password:
Linux serverDebianWheezy 3.2.0-4-686-pae #1 SMP Debian 3.2.46-1+deb7u1 i686
The programs included with the Debian GNU/Linux system are free software;
...
Last login: Sat Apr 18 10:50:52 2020 from 172.30.0.1
-bash: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by /lib/i386-linux-gnu/libtinfo.so.5)
Connection to localhost closed.
la autenticazione via ssh funziona ma quando c'è il fork della shell, la libc.so.6 riconosce la presenza della libtinfo con una incompatibilità! e chiude la connessione!
e non è un problema di bash, ma anche un scp termina di brutto con lo stesso errore. son rimasto fuori dal server.
Ho anche paura che se venisse fatto un reboot, l'OS con la libc.so.6 cosi compromessa, non sarebbe in grado di ripartire.. per cui gli ho detto di non fare niente su quel server..
Ora una strada per recuperare sarebbe andare sul server con un livecd e fare in qualche maniera un downgrading della libtinfo alla vecchia versione (come poi? con chroot? con debootstrap? o direttamente a mano spacchettando la vecchia versione e cambiando file per file..)
Però mi domandavo se qualcun altro avevo visto/affrontato questo tipo di problema durante la manutenzione di un sistema Debian.. e se c'erano suggerimenti.. ovviamente sul sistema non c'è neanche il telnetd, potrei chiedere (e chiederò) di verificare se almeno da console locale si riesce ad entrare (ma son poco fiducioso..)
Con google non ho trovato tante descrizioni di problemi "simili" da cui prendere ispirazione.. e francamente non capisco perché la libc.so.6 debba pretendere/verificare una libreria "opzionale" come libtinfo (che francamente non so neanche a cosa serva..) se quest'ultima è una dipendenza di libncurses! mah..
Mi sa che dovrò spendere un po' di tempo a documentarmi..
Grazie per l'attenzione, per chi è arrivato fin qua in fondo!
)