Re: CIE ( di nuovo) su bullseye

[ilario . quinson]

Non avevo capito, quindi con l'ACR hai risolto? Potresti fare una guida?
Grazie

Ilario

Il 20 aprile 2021 08:46:34 CEST, Filippo Dal Bosco -  ha 
scritto:
>Il giorno Tue, 20 Apr 2021 07:20:17 +0200
>ilario.quinson@e.email ha scritto:
>
>> Quindi su Kali con lettore bit4id hai risolto?
>
>sto parlando solo ed esclusivamente di prove fatte con l' ACR122U-A9
>
>Per il bit4id ho solo fatto un ipotesi 
>
>-- 
>Filippo

-- Inviato da /e/ Mail.

Re: CIE ( di nuovo) su bullseye

[Filippo Dal Bosco -]

Il giorno Tue, 20 Apr 2021 07:20:17 +0200
ilario.quinson@e.email ha scritto:

> Quindi su Kali con lettore bit4id hai risolto?

sto parlando solo ed esclusivamente di prove fatte con l' ACR122U-A9

Per il bit4id ho solo fatto un ipotesi 

-- 
Filippo

Re: CIE ( di nuovo) su bullseye

[ilario . quinson]

Quindi su Kali con lettore bit4id hai risolto?

Grazie

Ilario

Il 20 aprile 2021 05:56:42 CEST, Filippo Dal Bosco -  ha 
scritto:
>Il giorno Mon, 19 Apr 2021 22:45:08 +0200
>Davide Prina  ha scritto:
>
>> 
>> Se hai installato, allora rimuovi tutti i pacchetti (con --purge) 
>> libccid, libacsccid1 e reinstalla quelli che ti ho indicato sopra,
>> senza più installare quello del sito che mi hai indicato.
>
>
>dopo aver eseguito --purge ed installando esclusivamente
>file.deb della distribuzione stessa la procedura
>
>1) installare libacsccid1 ( specifica di ACR122U )
>2) installare pcsc-tool
>3) installare pcscd
>4) systemctl start pscsd.service
>--->>  5) pcsc_scan riconosce il lettore e la CIE <<<---  
>
>funziona esclusivamente in kali2021, non funziona in bullseye, ubuntu
>20.04 ed ubuntu 20.10
>
>In kali2021 installare cie-middleware che dipende ed installa un
>suo libccid NON funziona e saprattutto blocca pcsc_scan
>
>Segue che il sistema potrebbe funzionare fino a pcsc_scan ( vedi
>kali2021) ma cie-middleware comunque lo blocca. 
>Probabilmente per libccid e le sue configurazioni in
>
>/lib/udev/rules.d/92-libccid.rules 
>
>/usr/lib/pcsc/ifd-ccid.bundle/contents/info.plist
>
>inoltre: probabilmente quando si sceglie un NFC reader bisogna
>controllare che la specifica libccid per il reader si chiami libccid (
>come in  bit4id) e non abbia un nome diverso tipo libacsccid1 come in
>ACS perchè la CIE italiana prevede ed installa un suo libccid 
>
>-- 
>Filippo

-- Inviato da /e/ Mail.

Re: CIE ( di nuovo) su bullseye

[Filippo Dal Bosco -]

Il giorno Mon, 19 Apr 2021 22:45:08 +0200
Davide Prina  ha scritto:

> 
> Se hai installato, allora rimuovi tutti i pacchetti (con --purge) 
> libccid, libacsccid1 e reinstalla quelli che ti ho indicato sopra,
> senza più installare quello del sito che mi hai indicato.


dopo aver eseguito --purge ed installando esclusivamente
file.deb della distribuzione stessa la procedura

1) installare libacsccid1 ( specifica di ACR122U )
2) installare pcsc-tool
3) installare pcscd
4) systemctl start pscsd.service
--->>  5) pcsc_scan riconosce il lettore e la CIE <<<---  

funziona esclusivamente in kali2021, non funziona in bullseye, ubuntu
20.04 ed ubuntu 20.10

In kali2021 installare cie-middleware che dipende ed installa un
suo libccid NON funziona e saprattutto blocca pcsc_scan

Segue che il sistema potrebbe funzionare fino a pcsc_scan ( vedi
kali2021) ma cie-middleware comunque lo blocca. 
Probabilmente per libccid e le sue configurazioni in

/lib/udev/rules.d/92-libccid.rules 

/usr/lib/pcsc/ifd-ccid.bundle/contents/info.plist

inoltre: probabilmente quando si sceglie un NFC reader bisogna
controllare che la specifica libccid per il reader si chiami libccid (
come in  bit4id) e non abbia un nome diverso tipo libacsccid1 come in
ACS perchè la CIE italiana prevede ed installa un suo libccid 

-- 
Filippo

Re: Debian e il supporto hardware

[Davide Prina]

On 19/04/21 09:30, Paolo Redælli wrote:
Vorrei iniziare una piccola riflessione sulla scia di "Debian Bullseye 
poweroff".


Personalmente io sono arrivato alla conclusione che quando devo 
acquistare hardware la mia condizione irrinunciabile è "se non c'è con 
Linux(*) preinstallato non lo prendo neanche in considerazione".


però hai preso l'esempio sbagliato.
Il problema poweroff sembra sia dovuto a qualche patch/personalizzazione 
fatta dai DD di Debian rispetto a Linux upstream.


Se usi Linux upstream il supporto alla spegnimento c'è, se usi quello 
Debian sembra non spegnersi.


Come dicevo nell'altro thread potrebbe essere che hanno 
attivato/disattivato una o più opzioni di Linux rispetto a quello 
upstream o che abbiano applicato una patch con un bug... bisognerebbe 
indagare, ma per farlo serve un PC con quel determinato processore.


Inoltre, come dice Gerlos, puoi restare fregato in un altro senso: 
quando ti arriva il PC funziona, ma se poi fai aggiornamenti può essere 

che non ti funzioni più qualcosa perché hanno fatto loro delle 
personalizzazioni che poi non riesci a "riprodurre" sugli aggiornamenti.


Ciao
Davide
--
Client di posta: https://www.thunderbird.net
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook

Re: CIE ( di nuovo) su bullseye

[Davide Prina]

On 18/04/21 16:07, valerio wrote:


-rw-r--r-- 1 root root 137104 10 gen  2020 libacsccid.so


questo è diverso, è anche più vecchio di una giorno (quello scaricato 
dal sito di ACS)


come dicevo nell'altra mail i file sono stati compilati per Buster e 
quindi è normale che sia diverso.




-rw-r--r-- 1 root root  1289 10 gen  2020 changelog.Debian.gz

anche questo è diverso


se lo apri (è un file di testo compresso, puoi usare zless o most) vedi 
che è un backport di Buster


Ciao
Davide
--
I lati oscuri del secure boot:
https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web
Petizione contro il secure boot:
https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook

Re: CIE ( di nuovo) su bullseye

[Davide Prina]

On 18/04/21 15:38, Filippo Dal Bosco - wrote:


Davide Prina ha scritto:



ma questi sono i file che ti trovi già installando i pacchetti dai
repository Debian e quindi li sovrascrive... meglio usare quelli
Debian.

Sono nel pacchetto libacsccid1



Osservazione cie.middelware dipende da libccid   ( lo installa) e non da
libacsccid1.


entrambi quei pacchetti sono in Debian.


è normale ? Non è che cie.middelware usa libccid che ovviamente non
riesce ad accedere al device?


da quello che ho capito uno è la versione lite e l'altro quella 
completa. Possono essere installati contemporaneamente, almeno io li ho 
installati entrambi.



https://www.acs.com.hk/en/driver/3/acr122u-usb-nfc-reader/


da quello che vedo hanno preso il pacchetto da buster-backport

Se stai usando Bullseye io ti consiglio di non installare quel 
pacchetto, ma di installare quello presente in Bullseye. In questo caso 
potrebbe essere che installando quel pacchetto qualcosa non sia corretto 
al 100% perché hai messo un pacchetto creato appositamente per Buster su 
Bullseye.


Se stai usando Buster installa direttamente dal backport.

Se hai installato, allora rimuovi tutti i pacchetti (con --purge) 
libccid, libacsccid1 e reinstalla quelli che ti ho indicato sopra, senza 
più installare quello del sito che mi hai indicato.


Ciao
Davide
--
What happened in 2013 couldn't have happened without free software
(He credited free software for his ability to help disclose the U.S. 
government's far-reaching surveillance projects).

Edward Snowden

CIE parzialmente risolto con ACR122U

[Filippo Dal Bosco -]

Per provare ho installato un parente stretto di bullseye : kali2021

Seguendo la procedura

1) installare libacsccid1 ( specifica di ACR122U )
2) installare pcsc-tool
3) installare pcscd
4) systemctl start pscsd.service

--->>  5) pcsc_scan riconosce il lettore e la CIE <<<---

6) installare cie-middleware che dipende ed installa libccid 
7) cie-middleware NON funziona ( penso causa libccid)

su bullseye ed ubuntu 20.04 dopo aver cancellato tutto comprese le
configurazione la stessa procedura non funziona e pcsc_scan non rileva
il lettore NFC. 



-- 
Filippo

Re: Debian e il supporto hardware

[gerlos]

Il 19/04/21 09:30, Paolo Redælli ha scritto:


Vorrei iniziare una piccola riflessione sulla scia di "Debian Bullseye 
poweroff".


Personalmente io sono arrivato alla conclusione che quando devo 
acquistare hardware la mia condizione irrinunciabile è "se non c'è con 
Linux(*) preinstallato non lo prendo neanche in considerazione".


È vero, ci sono sempre stati assemblatori locali che permettevano di 
Comprare un computer con Debian già installata 
. Ma il supporto dei 
"grossi produttori" è un'altra cosa, specialmente in ambito aziendale.


Oggi fortunatamente si può fare. Dell offre Ubuntu. Lenovo mi pare 
Fedora. E ci sono molti altri esempi.


In questi tempi di pandemia ho acquistato portatili per me, mia figlia 
e mio suocero. In tutti i casi sono riuscito ad acquistarli con Linux 
preinstallato e ne sono stato molto soddisfatto. Vero, erano Ubuntu ed 
EndlessOS, ma pur sempre sistemi derivati da Debian.


Ok, al posto dell'asterisco dovrebbe esserci "GNU/Linux" o meglio 
ancora "Software libero" ma per la stragrande maggioranza 
dell'universo mondo là fuori son concetti "astrusi". È già tanto che 
sanno cosa sia Linux ed è già molto che qualche grosso produttore si 
sia "deciso" a supportarlo. Ma se non lo chiediamo noi, non lo 
sapranno mai.


Dopo un periodo in cui compravo (e facevo comprare al lavoro) PC senza 
sistema operativo, ultimamente anche io ho seguito questo approccio: 
guardo solo sistemi con GNU/Linux preinstallato, e quando amici e 
conoscenti mi chiedono, consiglio *anche* sistemi con GNU+Linux.


Purtroppo, pragmaticamente, non me la sento di consigliare di "passare a 
Linux" ad alcune persone, perché non ho tempo di (o non voglio) seguirli 
nella migrazione (spesso si tratterebbe di formazione e assistenza 
tecnica gratuita "a vita" 😅).


È vero che è più facile trovare roba con Ubuntu o Fedora, ma spesso ci 
si può mettere su Debian Testing senza problemi (magari dopo qualche 
mese, per escludere potenziali difetti di fabbricazione).


La cosa che trovo fastidiosa è che in alcuni casi vengono installati dei 
kernel personalizzati o frutto di backport per aggiungere supporto 
hardware, senza fornire documentazione in proposito, e non vengono 
forniti repository che permettano di aggiornare questi kernel, con i 
potenziali problemi di sicurezza che questo comporta.


Mi è capitato comprando a Marzo 2020 un notebook Microtech, con Ubuntu 
20.04 che arrivava con un kernel 5.8 personalizzato per il supporto a 
webcam e wifi. Ora il kernel 5.8 è arrivato su Ubuntu 20.04 tramite HWE, 
ma se avessi reinstallato il sistema operativo per qualche ragione, mi 
sarei trovato con un sistema "zoppo".


Credo che il passo successivo che va chiesto agli OEM sia documentare 
cosa fanno, e se possibile fornire repository delle loro 
personalizzazioni o immagini del sistema per il ripristino, o quanto 
meno provare a interagire più strettamente con la distro upstream in 
modo che non siano necessari repo addizionali né immagini speciali.


Senza questo, non mi sento di consigliare PC con GNU+Linux senza remore 
alla proverbiale zia inesperta che si limita a fare email, navigazione e 
poco altro, per quanto sarebbero sistemi perfetti per il suo caso d'uso.


saluti,
gerlos

Re: Debian e il supporto hardware

[Paolo Redælli]

Il 19/04/21 09:44, Marco Ciampa ha scritto:

Io è un bel po' che prendo e consiglio laptop con Linux preinstallato
(principalmente Clevo). Non credo che Clevo, vedendo gli ordini che
arrivano da Tuxedocomputers o simili, non sappia che i suoi clienti
principali usano Linux...

BTW interessante Endless* dicci di più...


Io ho regalato questo 
https://www.nexths.it/Products/details/sku/P1511CJA-BR767 dopo averlo 
farcito di RAM.


https://distrowatch.com/table.php?distribution=endless spiega bene: 
endlessos è una Debian stable dove tutto quello che si può viene montato 
in sola lettura. In questo modo il sistema dovrebbe essere stabilissimo 
ed a prova di utonto.


Le eventuali "applicazioni terze" si possono installare con un sistema 
di overlay. Che funziona talmente bene che non ho sentito il bisogno di 
capire se sia basato su flatpak, su appimage o altri sistemi, più che 
altro perché dovevo consegnare la macchina.


Come potrai notare dalle recensioni la sua caratteristica peculiare, 
ossia il sistema base in sola lettura starà strettissimo alla maggior 
parte degli utenti smaliziati e qualcuno l'ha paragonato alla 
"invasività" di Android. Tutto sommato però l'azienda che sta dietro ad 
EndlessOS è abbastanza chiara nello spiegare la faccenda e per l'uso che 
ne può fare un utente assolutamente non smaliziato come mio suocero è 
perfetto.

Re: Debian e il supporto hardware

[Nicola Ferrari (#554252)]

On 19/04/2021 09:30, Paolo Redælli wrote:
> In questi tempi di pandemia ho acquistato portatili per me, mia figlia e
> mio suocero. In tutti i casi sono riuscito ad acquistarli con Linux
> preinstallato e ne sono stato molto soddisfatto. Vero, erano Ubuntu ed
> EndlessOS, ma pur sempre sistemi derivati da Debian. 

Cos'hai preso, per curiosità?


-- 
+-+
| Linux User  #554252 |
+-+

Re: Debian e il supporto hardware

[Marco Ciampa]

On Mon, Apr 19, 2021 at 09:30:58AM +0200, Paolo Redælli wrote:
> Vorrei iniziare una piccola riflessione sulla scia di "Debian Bullseye
> poweroff".
> 
> Personalmente io sono arrivato alla conclusione che quando devo acquistare
> hardware la mia condizione irrinunciabile è "se non c'è con Linux(*)
> preinstallato non lo prendo neanche in considerazione".
> 
> È vero, ci sono sempre stati assemblatori locali che permettevano di
> Comprare un computer con Debian già installata
> . Ma il supporto dei "grossi
> produttori" è un'altra cosa, specialmente in ambito aziendale.
> 
> Oggi fortunatamente si può fare. Dell offre Ubuntu. Lenovo mi pare Fedora. E
> ci sono molti altri esempi.
> 
> In questi tempi di pandemia ho acquistato portatili per me, mia figlia e mio
> suocero. In tutti i casi sono riuscito ad acquistarli con Linux
> preinstallato e ne sono stato molto soddisfatto. Vero, erano Ubuntu ed
> EndlessOS, ma pur sempre sistemi derivati da Debian.
> 
> Ok, al posto dell'asterisco dovrebbe esserci "GNU/Linux" o meglio ancora
> "Software libero" ma per la stragrande maggioranza dell'universo mondo là
> fuori son concetti "astrusi". È già tanto che sanno cosa sia Linux ed è già
> molto che qualche grosso produttore si sia "deciso" a supportarlo. Ma se non
> lo chiediamo noi, non lo sapranno mai.
> 

Io è un bel po' che prendo e consiglio laptop con Linux preinstallato
(principalmente Clevo). Non credo che Clevo, vedendo gli ordini che
arrivano da Tuxedocomputers o simili, non sappia che i suoi clienti
principali usano Linux...

BTW interessante Endless* dicci di più...

-- 

Saluton,
Marco Ciampa

Debian e il supporto hardware

[Paolo Redælli]

Vorrei iniziare una piccola riflessione sulla scia di "Debian Bullseye 
poweroff".


Personalmente io sono arrivato alla conclusione che quando devo 
acquistare hardware la mia condizione irrinunciabile è "se non c'è con 
Linux(*) preinstallato non lo prendo neanche in considerazione".


È vero, ci sono sempre stati assemblatori locali che permettevano di 
Comprare un computer con Debian già installata 
. Ma il supporto dei 
"grossi produttori" è un'altra cosa, specialmente in ambito aziendale.


Oggi fortunatamente si può fare. Dell offre Ubuntu. Lenovo mi pare 
Fedora. E ci sono molti altri esempi.


In questi tempi di pandemia ho acquistato portatili per me, mia figlia e 
mio suocero. In tutti i casi sono riuscito ad acquistarli con Linux 
preinstallato e ne sono stato molto soddisfatto. Vero, erano Ubuntu ed 
EndlessOS, ma pur sempre sistemi derivati da Debian.


Ok, al posto dell'asterisco dovrebbe esserci "GNU/Linux" o meglio ancora 
"Software libero" ma per la stragrande maggioranza dell'universo mondo 
là fuori son concetti "astrusi". È già tanto che sanno cosa sia Linux ed 
è già molto che qualche grosso produttore si sia "deciso" a supportarlo. 
Ma se non lo chiediamo noi, non lo sapranno mai.