martedì 28 febbraio 2017

Manjaro, aggiornamenti kernel e driver ATI catalyst

Ovvero uno dei peggiori connubi del mondo linux.
Onestamente ogni volta mi chiedo perchè non abbandono definitivamente i driver proprietari ATI a favore di quelli opensource, infatti una volta su due dopo un aggiornamento del kernel al primo riavvio si blocca sempre tutto e bisogna avviare in single user per ripristinare il tutto.
Solo che stavolta la situazione è persino peggiorata, infatti una volta avviato in single user ho provato a rimuovere i driver con il solito comando :
mhwd -r pci video-catalyst
che gentilmente mi ha mandato a fare in c... dicendomi che non andava a buon termine per il mancato soddisfacimento di alcune dipendenze.
Allora ho deciso di operare in maniera brutale forzando la rimozione di alcuni pacchetti ignorando il controllo delle dipendenze.
pacman -R -dd catalyst-video
pacman -R -dd catalyst-server
mhwd -r pci video-catalyst
poi ho riavviato ma il server Xorg non si è avviato e sono rimasto solo con la console a carattere, poco male, eseguo il login e installo nuovamente.
mhwd -i pci video-catalyst
a questo punto lo schermo è diventato nero, e forse si è anche bloccato tutto, il passaggio da una console all'altra con CONTROL+F1 ecc non ha dato nessun esito, quindi ho spento di brutto.
Fortunatamente al riavvio è andato tutto bene, ma che agonia tutte le volte .... devo eliminare questi driver proprietari e tenermi quelli opensource .... una volta per tutte.

giovedì 23 febbraio 2017

Antivirus per linux

Sono passati quasi 4 anni dall'ultima volta che ho provato dei programmi antivirus per linux, è ho deciso di darci nuovamente un'occhiata.
Resta sempre il presupposto di allora, per quanto mi riguarda, e cioè che in linux non c'è grande bisogno di un antivirus anche perchè fino ad oggi mi pare che di virus per linux ce ne siano ben pochi.
C'è da dire che negli ultimi anni i virus hanno cambiato "aspetto" e si sono diffusi molto i ransomware come il tristemente famoso CryptoLocker che vanno a criptare i file del proprio PC rendendoli inutilizzabili. In teoria credo che ciò potrebbe essere fatto anche su linux, con un virus adhoc, in quanto anche se si limita a criptare i documenti dell'utente, quindi senza rendere inutilizzabile il PC, ma una volta persi documenti importanti, di cui dovrebbe esserci sempre una copia, il danno basta e avanza.
Ma al di la di queste mie ipotesi, se il ns. PC linux è in una rete con altri computer Windows e magari fa pure da server SAMBA per la condivisione dei dati, oppure fa da downloader per file torrent, ecco che un antivirus che funzioni direttamente sul lato linux può essere anche utile.

Ho effettuato le prove con un paio di distribuzioni linux, Debian sia Jessie che Stretch, Centos 7 e Fedora 25, quest'ultima l'unica a 32 bit.
Per testare gli antivirus ho scaricato alcuni file di test da qui e alcuni keygen che ho, non che usi software piratato per l'amor del cielo ......


Il primo testato è il più famoso, e forse l'unico, antivirus opensource e disponibile con qualsiasi distribuzione linux. Testato su Fedora 25 si è comportato bene rilevando i file infetti senza però segnalare nulla in merito ai keygen. Questo programma è solo a linea di comando quindi va bene per essere usato all'interno di script, quindi anche in crontab. Su Fedora esiste anche un pacchetto clamtk per avere un'interfaccia grafica, ma è talmente spartana e poco funzionale che è meglio lasciarla perdere. Dico solo una cosa in fase di selezione della cartella da scansionare il programma non da la possibilità di eseguire una scansione ricorsiva delle eventuali sottodirectory e non lo fa nemmeno di default, quindi, a non saperlo, uno magari pensa anche di aver scansionato tutta la cartella e invece il programma si è limitato solo ai file in essa contenuti. Esiste anche un'interfaccia per KDE, che non ho testato, mi auguro sia più funzionale.
Questo antivirus non prevede la scansione realtime, che come vedremo in linux è praticamente inesistente.


Questo antivirus lo avevo testato anche la volta precedente, è ancora in circolazione ed è disponibile in formato DEB e RPM sia a 32 che a 64 bit. E' gratuito e ha una bella, questione di gusti, interfaccia grafica ma anche i tools da linea di comando, quindi utile sia per l'automazione di lavori via script che per l'utente desktop. Il programma una volta installato segnala subito di procedere con l'aggiornamento del database delle firme, e segnala anche di fare una scansione completa del sistema.
Sarebbe, a mio avviso, da 10 e lode se non fosse per un fastidioso problema, e cioè questo programma prevede la scansione realtime attraverso il modulo del kernel redirfs. Peccato che i sorgenti da compilare forniti con il pacchetto siano vecchi e funzioni solo con i kernel 2.6, da qui è possibile scaricare delle versioni aggiornate che mi hanno permesso di compilare il modulo su Jessie, che usa un kernel 3.16 .... ma con il kernel 4.9 di Fedora non vanno già più bene.
Ora la scansione realtime è quella che ti segnala che un file è infetto nel momento in cui lo scarichi sul PC o accedi ad una chiavetta USB dove è presente un file infetto .... quindi senza dover fare una scansione manuale.
Ma se anche non funziona non è proprio una tragedia, ma allora visto che il driver non è più mantenuto/aggiornato non è meglio togliere questa opzione ... o almeno disabilitarla in modo da non vedere ogni volta la segnalazione di errore che indica che il modulo redirfs non è stato caricato. 
Ripeto è proprio un'inezia secondo me, ma mi da l'impressione di poca cura verso un prodotto che, anche se gratuito, meriterebbe un pò di più attenzione.
Detto questo la scansione rileva in maniera efficace i virus di test e segnala anche i keygen come minacce, anche se in realtà si tratta di falsi positivi.


Questo antivirus mi ha deluso lasciandomi perplesso riguardo al reale interesse che l'azienda produttrice possa avere su questo prodotto, perchè dico questo, semplicemente perchè terminata l'installazione il programma non funziona.
Dopo aver aggiornato le definizioni del database dei virus un qualsiasi tentativo di scansione riporta un laconico messaggio che indica che il "motore non è stato caricato" o "engines not loaded" in versione inglese.
Sul loro forum c'è un post del 2011 che discute di questo problema, con una serie di comandi che dovrebbe risolverlo.
Sfortunatamente quelle istruzioni non risolvono il problema sui sistemi che usano RPM, io su Centos 7 a 64 bit e Fedora 25 a 32 bit con quelle istruzioni non ho risolto nulla .... su Debian Stretch a 64 bit invece hanno funzionato.
Onestamente mi domando come sia possibile che un problema già noto nel 2011 si ripresenti e non si risolva nel 2017 ..... ecco perchè dubito che ci sia un reale interesse verso questo prodotto. Ed è un peccato perchè sarebbe disponibile sia a 32 che a 64 bit, sia in formato DEB che RPM, ha sia l'interfaccia grafica che quella a linea di comando, quindi in grado di coprire le diverse esigenze degli utenti. Inoltre, su Debian Strecth, dopo aver risolto la scansione si comporta bene rilevando i file infetti e anche i keygen. 

SOPHOS

Dopo aver scaricato il file in formato tgz e averlo scompattato andrà eseguito il classico script di installazione, install.sh, che procederà a farci alcune domande per poi installare il programma con le definzioni aggiornate.
In fase di installazione possiamo abilitare la scansione realtime, on-access scanning come la chiama lui.
La scansione avviene solo da linea di comando in quanto anche questo antivirus non prevede interfaccia grafica, i risultati sono in linea con gli altri antivirus, anche questo non rileva nulla sui keygen.
La scansione on-access funziona a dovere intercettando al volo e segnalando i file infetti.
Un neo è che la cartella del programma, creata per default sotto /opt è accessibile solo all'utente root per cui bisogna usare sudo anche solo per vederne il contenuto, e quindi capire quali comandi sono disponibili.

F-PROT

L'installazione non è proprio per l'utente medio, il file è fornito in formato tar.gz e va scompattato, poi da bravi bambini bisogna leggere il file README e seguire le istruzioni, un paio di comandi da eseguire da shell per lanciare poi lo script di installazione vero e proprio.
Lo script di installazione al termine chiede se si vuole venga modificato il crontab per l'aggiornamento automatico, poi per l'uso del software ci sono solo due comandi, da shell, fpscan e fpupdate .... lascio a voi immaginare cosa facciano ;-)
Le prove di scansione hanno dato esito positivo evidenziando i file infetti usati per il test, anche in questo caso nessuna segnalazione per i keygen.
Sicuramente un buon antivirus per gli utenti che non hanno problemi a muoversi nella shell ma la mancanza di un'installazione standard, basata su pacchetti DEB o RPM o un installer grafico dedicato e di una gestione grafica dell'antivirus non lo rendono adatto ad un uso desktop, che magari non è nemmeno stato preso in considerazione.

ESET NOD32

Questo antivirus può essere scaricato e usato in modalità trial, e poi va eventualmente acquistato perchè non esiste una versione gratuita.
L'installazione è semplice ed avviene in modalità grafica, al termine va riavviato il PC, fa tutto da solo se glielo lasciate fare, al primo avvio viene chiesta la propria mail per attivare la licenza di prova.
Senza la licenza di prova non sarà possibile aggiornare il database delle firme ma il software risulta funzionante quindi lo si può testare fin da subito.
Anche questo programma prevede la possibilità di essere eseguito sia da linea di comando che dalla propria interfaccia GUI, che risulta semplice ed efficace. La scansione ha rilevato i file di test dei virus ma non ha segnalato anomalie sui keygen, il software prevede la scansione in realtime, che può essere anche disabilitata se dovesse impattare negativamente sulle performance del PC. Scaricando da internet alcuni file infetti questi sono stati subito intercettati ed eliminati.
Il programma si avvia in automatico ed è visibile e richiamabile dall'icona nella taskbar.
Una nota per quanto riguarda la licenza di prova, dopo aver impostato la mia mail in fase di installazione non ho ricevuto nulla nelle ore successive quindi ho trovato questa pagina da dove ho scaricato una username/password per avere i 30 giorni di prova e quindi procedere con l'aggiornamento delle firme.

Aggiornamento del 24 febbraio 2017.

L'interfaccia grafica del programma non si avvia più ... anche eseguendo il comando manualmente questo si blocca senza nessun messaggio di errore, il problema sembra essere nel "demone" esets_daemon che riporta sempre il messaggio :
error[24210000]: Impossibile inizializzare scanner: Module init
Nessuna notizia in rete, o meglio una sola che non mi ha aiutato, probabilmente una volta disinstallato il programma e poi reinstallato il problema si sistema ..... ma mi sono limitato solo alla rimozione del software.

A conclusione di questa mia breve, e sicuramente insufficiente, panoramica devo dire che per gli utenti che hanno una certa familiarità con la shell le possibilità non mancano e quindi la possibilità di usare i comandi di scansione o manualmente o in script, o in crontab possono servire per aumentare il controllo in ambienti dove ci siano altri PC Windows e risorse condivise. A livello di utenza desktop mi pare che le cose non vadano proprio bene, a meno di non spendere qualche decina di euro e acquistare ESET NOD32 che rispetto ai due diretti concorrenti, COMODO e BitDefender, si installa in maniera molto semplice e senza nessun problema.

Diciamo che al momento, come utenti linux, possiamo ancora vivere tranquillamente senza un antivirus .... poi se abbiamo PC Windows in casa e questi dovessero venire brutalmente distrutti da un virus .... beh forse non tutti i mali vengono per nuocere.
 

 

sabato 18 febbraio 2017

SCO OpenServer 6.0 non fa il boot da disco

In realtà il titolo è un pò fuorviante perchè potrebbe far pensare che sia un problema generale di questo OS, ma vediamo in dettaglio come stanno le cose.
Sul mio vecchio muletto, un portatile Pentium III a 550Mhz con 256 mega di RAM con ormai quasi 18 anni sul groppone ho installato su un disco il mai dimenticato Windows 98, su un altro SCO OpenServer 5.0.7 e visto che mi avanzava ancora un altro disco ho voluto installarci SCO OpenServer 6.
L'installazione si è completata, con i suoi tempi vista l'età dell'hardware, e non ha segnalato nessun problema, solo che al riavvio mi veniva segnalato di inserire un "system disk", in pratica non faceva il boot dal disco fisso.
Come ho detto il PC è vecchio, e quindi ho pensato che forse il lettore di CD con cui ho eseguito l'installazione, da un supporto CDRW, avesse incontrato qualche problema, quindi ho rifatto il CD e rifatto l'installazione. Nulla, al termine riavvio il PC ma non fa il boot.
Allora ho inserito il disco nell'altro portatile, il fratello maggiore, un Pentium III a 1Ghz con 1 giga di RAM, anche lui con un 15 anni di anzianità, ma che a livello di chassis è identico al muletto e quindi usa lo stesso caddy per l'alloggiamento del disco fisso. In soldoni, da questo PC il sistema operativo si è avviato senza problemi. 
Quindi ? Beh i due PC sono molto simili e la differenza principale è nel chipset, quello da cui non avviene il boot è un Intel 440BX, mentre l'altro un VIA Apollo 133, due BIOS diversi .... ma può essere questo il motivo ? 
Potrei essermi fermato qui e usare questo secondo PC per avviare SCO6, ma la curiosità mi ha spinto a voler investigare più in dettaglio il problema e quindi ho copiato il codice di boot, il master boot record, usato da SCO6 per confrontarlo con quello usato da SCO5. Il comando per ottenere l'MBR è semplicemente :
dd if=/dev/hd00 of=/tmp/mbr bs=512 count=1
in questo modo il file mbr contiene il primo settore del disco fisso.
Nei PC dove il boot avviene via BIOS il funzionamento è abbastanza semplice, in pratica il BIOS legge il primo settore del disco fisso e ne esegue le istruzioni. Di solito la prima cosa che fa questo codice è di copiare se stesso, cioè il contenuto del primo settore, in una nuova locazione di memoria e poi controllare la tabella delle partizioni per cercarne una attiva e caricare in memoria il codice di avvio contenuto all'inizio della partizione. Il codice di avvio è diverso per ogni sistema operativo ma quello dell'mbr è più o meno sempre simile.
Un modo semplice per analizzare il codice dell'mbr è quello di disassemblarlo con objdump, ovviamente su linux.
objdump -D -b binary -mi386 -Maddr16,data16,intel mbr
dove mbr è il file che contiene il codice di avvio.
Ora non è che io sia un grande esperto di assembly e il codice di SCO5 e SCO6 è effettivamente diverso ma non molto perchè poi fa la stessa cosa in entrambi i sistemi operativi. 
Però una cosa mi è saltata subito all'occhio, nel codice di SCO6 viene usato un opcode per abilitare l'uso dei registri a 32 bit, di norma il codice dell'mbr è talmente semplice che usa solo registri a 16 bit, anche perchè la CPU quando si avvia per eseguire il BIOS è in modalità "reale", in pratica come un vecchio 8086, prima CPU a 16 bit dell'Intel.
Boh, forse sul muletto questa cosa mette in crisi la CPU, anche se si tratta di un Pentium III, o forse  è il BIOS a non gradire.
A questo punto forse ho capito il problema, ma come lo posso risolvere ? Magari usando come codice di avvio per SCO6 lo stesso usato da SCO5. 
Su SCO5 c'è il comando /bin/dparam che se invocato con l'opzione -w legge il contenuto del file /etc/masterboot e lo copia nel primo settore del disco fisso, riscrive l'mbr insomma.
Allora posso copiare il file /etc/masterboot da SCO5 a SCO6 e fare questa operazione giusto ? sbagliato. Infatti su SCO6 non esiste un file /etc/masterboot e il comando /bin/dparam è un link a /etc/fdisk, e il codice dell'mbr è all'interno di questo eseguibile per cui devo cambiare strategia.
Da SCO5 metto un dichetto nel floppy ed eseguo questi comandi per portarmi poi su SCO6 il necessario.
cd /tmp
cp /bin/dparm .
cp /etc/masterboot .
tar cv6 dparam masterboot
adesso prendo il floppy e sull'altro PC dove SCO6 si avvia eseguo questi comandi.
cd /tmp
tar xv6
cp masterboot /etc
./dparam -w 
in pratica eseguo la versione di SCO5 del comando dparam e non l'originale di SCO6. Spengo il PC e metto il disco nel muletto, lo riaccendo e tadà!!!! SCO6 si avvia direttamente senza nessun problema.
A questo punto qualcuno si domanderà che senso a tutto questo ? Usare SCO oggi ? Su hardware reale poi, quando una VM su un PC moderno è sicuramente più veloce e non da di questi problemi...... beh a questo non ho ancora trovato una risposta sensata.