Re: Installazione via rete senza KVM IP o IPMI - (live installabile)
Mandi! pinguino In chel di` si favelave... > A me interessa creare una live installabile. Sia per avere un backup Io ho usato 'mondorescue': http://www.mondorescue.org/ ma il simpatico vecchietto che la gestisce ormai fa ben poco... -- ...ma quel suo volo certo vuol dire che bisognava volare (F. Guccini)
Re: Debian e autenticazione esterna
Mandi! MAURIZI Lorenzo In chel di` si favelave... > mi rivolgo alla lista per trovare una soluzione al seguente quesito: > è possibile autenticare gli utenti di un server Debian utilizzando Active > Directory ma senza fare il join del server linux al dominio? Se sì, come? Se non ti interessano gruppi e relative membership: apt-get install pam-krb5 inserisci il realm, quindi dai: pam-auth-update ed abiliti pam_mkhomedir. Fatta. -- Non può sentirsi degno di essere italiano chi non vota SI al referendum (Silvio Berlusconi, 21 giugno 2006)
Re: Installazione via rete senza KVM IP o IPMI - (live installabile)
Il 15 febbraio 2022 10:05:06 UTC, pinguino ha scritto: >Il 14/02/22 17:53, Paride Desimone ha scritto: >> Il 8 febbraio 2022 10:18:45 UTC, Diego Zuccato ha >> scritto: >>> Ciao a tutti. >>> >>> Mi trovo nella situazione di dover reinstallare un vecchio server (con >>> IPMI solo parzialmente funzionante: funziona tutto tranne la parte KVM!). >>> >>> Ho cercato un po' in ciro ma ho trovato solo >>> https://wiki.debian.org/DebianInstaller/NetworkConsole >>> che però mi pare dia per scontate troppe cose e mi ci perdo. >>> >>> Qualcuno ha dei riferimenti più precisi? >>> Devo arrivare ad avere una ISO che preinstalli un sistema minimale >>> (niente desktop, solo server ssh), che poi mi arrangio senza problemi. >>> Magari potendo stabilire a priori il layout delle partizioni. >>> >>> Certo che se la ISO standard seguisse il "principio" delle immagini per >>> Raspberry (una partizione FAT con le configurazioni editabili) sarebbe >>> tutto più facile :) >>> >> >> Se non ho trovato male, live-helper, è stato sostituito da live-build. Dagli >> uno sguardo perché potrebbe fare al caso tuo. Ti fa creare una live, anche >> installabile, di debian, a secondo delle tue necessità. >> >> /paride > >Buongiorno Lista, >A me interessa creare una live installabile. Sia per avere un backup >esterno, che per avere anche un disco di recupero personalizzato. >(Non distribuisco il mio sistema a nessuno, me lo tengo solo per me.) > >Avevo fatto qualche esperienza con Remastersys e con Systemback, dove >avevo creato delle live installabili, che funzionavano bene, e >funzionano ancora. Ma sono di distribuzioni vecchie. > >Ma poi, prima Remastersys poi Systemback, non hanno più funzionato. >Per un motivo o per l'altro danno sempre degli errori e non creano più >il file ISO che si può masterizzare. > >Ci sono delle guide o delle istruzioni semplici per usare il comando >live-build ? Perché avevo provato ad usere anche quello ma era un po >complicato per me. > >Grazie >Cordiali Saluti >Claudio > live-build /paride -- Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
Re: installazione debian
Il 15/02/22 14:07, Piviul ha scritto: un aggiornamento... nel BIOS in effetti il boot non era impostato su UEFI Non so cosa intendi, ma io intendevo selezionare il device di boot con l'etichetta UEFI Altra cosa (non so se possa essere il caso e se possa riguardare questa problematica ma non sono ferrato sul SECURE BOOT), nel menu della mia scheda madre nella sezione del Secure Boot, ho selezionato tra gli OS "other os" e non windows. Ricordo tempo fa che non mi funzionava una cippa se non cambiavo questo parametro...ora lo abilito di default ma, ripeto, non so quanto possa essere utile. ora l'ho impostato ma all'avvio continua a non dirmi nulla e continua a fallire ma mi sembra l'errore sia cambiato; ora mi dice "unable to install grub in dummy"... ma ti assicuro che la ESP non è in raid ;)... comunque alla partizione ESP io non fatto altro che dirgli di usarla come EFI System Partition, nulla di più no? Ci dovrebbe pensare l'installer poi a mettere un filesystem fat32 giusto? Esatto, l'installer si occupa di creare l'fs fat32 e di montarla su /boot/efi. ho provato anche ad impostare di non usare la ESP sul secondo disco lasciando soltanto una ESP ma nulla, l'errore è sempre lo stesso... Potresti provare a vedere se quando ti chiede di installare GRUB /boot/efi è montato (dovrebbe esserlo) (NOTA: una volta che ho installato il sistema, faccio un dd da sda1 su sdb1 in modo tale che se il primo disco si frigge, il secondo parte senza problemi. Non so se è il metodo corretto, me lo suggerirono tempo fa e funziona. Magari qualcuno più esperto può aiutarci) ...interessante se ci caverò gli zampetti poi lo terrò a mente... anche se basta una copia del contenuto vero? Attenzione. Come riportato da Diego: Il 14/02/22 19:56, Diego Zuccato ha scritto: > Dovresti ricordarti di farlo ad ogni aggiornamento di grub, o può > capitare che anche senza disco fritto non ti si riavvii con un errore > criptico. Al che, da BIOS devi spostare il boot sull'altro disco e > sperare che parta. Altrimenti boot da live e fix dell'installazione di > grub (o chroot e "grub-install /dev/sdX [...] ok, /sys/firmware/efi exists ma continua a non chiedermi nulla... non so più cosa pensare. Proverò a ranzare via le partizioni e far fare tutto all'installer... come sempre del resto; però non capisco proprio dove possa essere il problema. Se tutto è come dovrebbe essere (ovvero che hai selezionato il device di boot con label che comincia con "UEFI" della chiavetta) è molto strano che non ti chieda di forzare l'installazione EFI. Sembra che non rilevi la presenza della partizione EFI (può risultare che non creandola dall'installer, lo stesso non rilevi la sua presenza?) Se hai tempo da perdere e vuoi vedere che succede fa queste prove con l'installer: 1) installa creando le partizioni dell'installer e nel momento in cui richiede l'installazione di GRUB verifica se la /boot/efi è montata. 2) installa creando le partizioni manualmente con parted, procedi con l'installazione e sempre quando richiede di installare grub verifica se è montata. In questo caso se non è montata allora non è rilevata. Se non è rilevata, prova a montarla sul filesystem / della nuova installazione su /boot/efi (attenzione: non sull'fs del device di boot) e fagli rilanciare grub (dell'installer) e vedi che ti dice. Purtroppo non ho altre macchine UEFI per testare ed aiutarti maggiormente. Spero che qualcuno con più esperienza intervenga nella discussione, perche non so che altro guardare. Grazie un monte È un piacere ;) Piviul
Re: [OT] fascicolo sanitario e CIE
Il 2022-02-15 14:57 Diego Zuccato ha scritto: Il 11/02/2022 22:00, Davide Prina ha scritto: Poiché il testo cifrato può essere decifrato, a cifrati identici corrispondono necessariamente testi in chiaro identici. questa frase è così generica che secondo me è falsa. Sicuramente falsa. Controprova: basta scegliere un algoritmo di cifratura e provare a decodificare con chiavi diverse lo stesso Davvero qualcuno può pensare che quella frase intenda dire che per decifrare non serve conoscere né l'algoritmo né la chiave? Perché è tutto lo stesso? Se c'è UN MODO per decifrare testi cifrati, a cifrati identici con QUEL MODO, corrispondono testi in chiaro identici. La frase era stata scritta in risposta al paventato rischio che cifrare documenti lunghi (implicitamente inteso che lo si fa avendo scelto UN MODO per farlo, ovverosia un determinato algoritmo, una determinata chiave, più gli eventuali annessi e connessi) aumentasse la probabilità di collisione dei testi cifrati. E sottolineo pure che si parlava di probabilità. Oserei dire che ogni affermazione, spostata in contesti diversi diventa vera e falsa :-P Prendendo ad esempio il grande classico delle affermazioni ovvie, 2+2=4, vale ricordare che: in Z/3Z, 2+2=1 :-) ho letto qualche anno fa un articolo che parlava di cifratura e si indicava che la principale attività era quella di verificare che l'algoritmo fosse stato implementato correttamente e il suo uso fosse congruo. In modo che non vi siano bug o usi inappropriati. Verificare che l'implementazione sia priva di bug di solito è il primo passo. Discorso diverso per l'uso inappropriato: questo non te lo può garantire nessun algoritmo. Anche il più sicuro, se usato male, Ci possono essere procedure che vanno seguite... almeno all'interno del singolo software. Poi sull'uso dall'esterno, certo il controllo è impossibile. Però nessuno valuta se il bug è a livello matematico, cioè se vi è un "problema", magari intenzionale, che permetta di avere un passpartout, backdoor Anche in questa affermazione penso ci siano differenze possibili di contesto. Immagino che, in una ditta che produce semplicemente software, effettivamente nessuno controlli l'algoritmo "dal punto di vista matematico" e ci si concentri sulla correttezza della implementazione. Perché ci si affida ad algoritmi, analisi, indicazioni procedurali elaborate altrove. Chi invece studia non l'implementazione, ma lo sviluppo e la selezione degli algoritmi... li guarda eccome "a livello matematico"! Ĝis, m -- http://bodrato.it/papers/
Re: [OT] fascicolo sanitario e CIE
Il 11/02/2022 22:00, Davide Prina ha scritto:
Poiché il testo cifrato può essere decifrato, a cifrati identici
corrispondono necessariamente testi in chiaro identici.
questa frase è così generica che secondo me è falsa.
Sicuramente falsa. Controprova: basta scegliere un algoritmo di
cifratura e provare a decodificare con chiavi diverse lo stesso blocco.
Ovviamente si otterranno due "plaintext" diversi.
Due, secondo me, lo stesso algoritmo con lunghezza di chiave diversa o
algoritmi diversi o... potrebbero ottenere lo stesso cifrato a partire
da testo in chiaro diverso.
*Di solito* (ma non necessariamente) l'operazione di cifratura è
deterministica: dato [algoritmo,chiave,plaintext] viene sempre generato
lo stesso cyphertext. Questo è necessario, p.e., per testare che
l'algoritmo sia implementato correttamente (i test vector forniti con le
specifiche si basano su questo), oltre che per non consumare inutilmente
entropia. Nel caso sia richiesto un "blinding" del plaintext (fissata la
tripletta [A,K,T] devo ottenere testi cifrati ogni volta diversi) ci
sono diversi modi (banalmente -e in modo poco sicuro!- si potrebbe
mettere nel primo blocco il valore di un contatore, che verrà poi
incrementato), anche se generalmente aumentano la lunghezza del
cyphertext (che potrebbe anche essere un effetto voluto).
Un esempio banale è prendere un file a piacere e applicare diversi
algoritmi o stesso algoritmo con chiavi diverse o con lunghezze di
chiavi diverse o... per "decifrarlo". Penso che, bene o male, tutti
ritornino un file di output valido.
Generalmente si, soprattutto se usano la stessa dimensione del blocco.
Il fatto che poi il testo decifrato abbia o meno "senso" all'algoritmo
di cifratura non interessa. Potrebbe p.e. essere il cyphertext da
decodificare con un algoritmo diverso. 3DES funzionava proprio in questo
modo: in modalità EDE cifrava con K1, decifrava con K2 e tornava a
cifrare con K1. Non è ancora stato dimostrato che DES non sia un gruppo,
quindi *potrebbe* essere possibile che il risultato di 3DES equivalga
alla sola operazione di cifratura sotto una sola chiave ma è improbabile:
https://link.springer.com/article/10.1007/BF00206323
" Experiments show, with overwhelming confidence, that DES is not a group."
* visto che chi deve cifrare o decifrare è di solito un utente qualsiasi
con i suoi mezzi computazionali (normalmente tramite l'uso di una CPU)
deve essere permesso di eseguire l'operazione in tempi accettabili. Se
tutti avessero hardware "appropriato" non sarebbe un problema cifrare
messaggi lunghi
No, questo no. Oramai anche un telefonino può eseguire decine (se non
centinaia) di cifrature a chiave pubblica al secondo. Il problema è che
non necessariamente aumenti la sicurezza!
Esempio classico: cifri ("firmi") con RSA2048 un messaggio, *un
carattere alla volta*. Ti aspetti che sia sicuro? Ovviamente no: anche
se l'attaccante non può generare la firma di un carattere che non ha mai
visto, dato un numero sufficiente di firme potrebbe falsificare un
messaggio creato partendo da quelle. P.e. se hai firmato "CIAO"
ottenendo !"£$ l'attaccante può generare un messaggio "firmato" !£"$ che
viene verificato come CAIO :)
* l'uso di una funzione hash permette di minimizzare le collisioni,
soprattutto per messaggi "vicini" (o simili). Questo rende (o dovrebbe
rendere) più complesso riuscire a manipolare una parte del messaggio
facendo corrispondere la firma, anche se vengono scoperte falle nel
sistema di cifratura
All'utente non interessano le collisioni :)
Il problema delle collisioni è che tutti i messaggi che entrano in
collisione possono essere spacciati come autentici!
Esempio banale: se la funzione di hash ignora il carattere '0', il
messaggio "mi impegno a pagare 1€" e ha lo stesso hash di "mi impegno a
pagare 1000€"... Entrambi validi, ma di significato molto diverso :)
* l'uso di una funzione hash permette di usare un messaggio breve su cui
applicare la cifratura. Più il messaggio è lungo e più volte viene usata
la stessa chiave di cifratura e maggiori sono le probabilità di un
attaccante di individuare la "chiave" usata
Con algoritmi recenti questo non è un problema.
(è stato grazie a questa
tecnica che sono riusciti a decifrare messaggi tedeschi nella seconda
guerra mondiale, dove l'uso, inappropriato, della stessa "chiave" su
messaggi anche lunghi ha permesso di identificare la "chiave" usata. Per
messaggi corti, se non erro la maggior parte, invece anche ora stanno
tentando di decifrarli con la tecnologia attuale, ma non ci riescono)
* ...
Beh, non proprio:
http://practicalcryptography.com/cryptanalysis/breaking-machine-ciphers/cryptanalysis-enigma/
Con poco più di 18 miliardi di chiavi, un PC anche datato può fare brute
forcing in poco tempo ("In general it will take less than 30 seconds to
break short messages (50 characters), slightly longer for longer
messages.").
ho letto qualche anno fa un articolo che parlava di
Re: installazione debian
Il 14/02/22 18:31, Alessandro Baggi ha scritto: Il 14/02/22 17:11, Piviul ha scritto: > ma te le sei preparate tu o te le ha preparate l'installer? Se te le > fossi preparate tu come fai ad utilizzare la partizione EFI come > partizione EFI? Le partizioni le ho create dall'installer con metodo manuale, quindi con tutta la lista dei device fisici e virtuali (se gia presenti) e non con fdisk o parted da console. Non devo specificare che la partizione EFI deve essere montata su /boot/efi, l'installer se ne occupa da solo (non l'ho mai specificato) un aggiornamento... nel BIOS in effetti il boot non era impostato su UEFI ora l'ho impostato ma all'avvio continua a non dirmi nulla e continua a fallire ma mi sembra l'errore sia cambiato; ora mi dice "unable to install grub in dummy"... ma ti assicuro che la ESP non è in raid ;)... comunque alla partizione ESP io non fatto altro che dirgli di usarla come EFI System Partition, nulla di più no? Ci dovrebbe pensare l'installer poi a mettere un filesystem fat32 giusto? Nel mio caso specifico, non è un partizionamento troppo complicato anzi fa pena. La partizione EFI l'ho creata su sda, su sdb ho creato solamente una partizione normale della stessa dimensione (NOTA: non ho creato un'altra EFI perchè l'installer potrebbe considerarmi quella come partizione EFI ma non è il risultato desiderato) e poi ho creato le partizioni per i raid1 e assemblati sempre nell'installer e installato debian. ho provato anche ad impostare di non usare la ESP sul secondo disco lasciando soltanto una ESP ma nulla, l'errore è sempre lo stesso... (NOTA: una volta che ho installato il sistema, faccio un dd da sda1 su sdb1 in modo tale che se il primo disco si frigge, il secondo parte senza problemi. Non so se è il metodo corretto, me lo suggerirono tempo fa e funziona. Magari qualcuno più esperto può aiutarci) ...interessante se ci caverò gli zampetti poi lo terrò a mente... anche se basta una copia del contenuto vero? [...] no, non me lo chiede, in effetti ora che mi ci fai pensare altre volte me lo ha chiesto... come faccio a sapere se secondo lui sta forzando Sinceramente non so come puoi accertarti se sta procedendo con l'installazione UEFI (magari ci sta qualche modulo o qualcos'altro). Quello che posso dirti è dopo aver inserito il media di installazione (nel mio caso USB) e aver premuto F8 per la selezione del device di boot, nella lista mi appare due volte la chiavetta: una volta con il suo nome e un'altra con la dicitura UEFI prima del nome. Per l'installazione UEFI seleziono la seconda. A volte mi è capitato per errore di selezionare la prima e 1. non mi chiedeva se forzare l'installazione EFI 2. grub si installava ma il sistema non partiva. Cercando in rete, dopo aver avviato il media di installazione, apri un'altra console e verifica se "/sys/firmware/efi exists means system uses UEFI". ok, /sys/firmware/efi exists ma continua a non chiedermi nulla... non so più cosa pensare. Proverò a ranzare via le partizioni e far fare tutto all'installer... come sempre del resto; però non capisco proprio dove possa essere il problema. Grazie un monte Piviul Ora non so se ho capito bene: ma stai provando a creare la partizione EFI su un device MD? no la partizione EFI (EFI System Partition) è una partizione fat32... solo la partizione di boot la vorrei in RAID, la partizione di root e le altre partizioni in lvm (magari anche in raid). Ok In caso affermativo con Debian non funziona e grub-dummy fallisce (per questo io creo una partizione EFI per ogni disco) [Nota OT: su AlmaLinux e OpenSUSE 15.3 è possibile creare la EFI su un device MD, non ho capito ancora come fanno ma cmq sembra è possibile] Durante l'installazione la partizione EFI non permette di specificare dove montarla come per un normale fs. Ora non so se dico una cavolata, la partizione EFI richiede una partition table GPT? Non è che i dischi essendo gia partizionati hanno una MBR? Per quello che i dischi li preparo prima con fdisk, così sono sicuro siano GPT! Come detto evito di preparare tutto prima di entrare nell'installer. Una volta lo facevo anche io (abiutato da Slackware) ma poi ho iniziato a riscontrare problemi su come l'installer rilevava i dischi (a volte facevo casino io :D). Poi un giorno ho deciso di utilizzare l'installer e funziona alla grande ed è più che adeguato. Ricordo che quando affrontai GPT per la prima volta fdisk supportava solo MBR e iniziai ad usare parted (o gdisk). Grazie mille Piviul
Re: Installazione via rete senza KVM IP o IPMI - (live installabile)
Il 14/02/22 17:53, Paride Desimone ha scritto: Il 8 febbraio 2022 10:18:45 UTC, Diego Zuccato ha scritto: Ciao a tutti. Mi trovo nella situazione di dover reinstallare un vecchio server (con IPMI solo parzialmente funzionante: funziona tutto tranne la parte KVM!). Ho cercato un po' in ciro ma ho trovato solo https://wiki.debian.org/DebianInstaller/NetworkConsole che però mi pare dia per scontate troppe cose e mi ci perdo. Qualcuno ha dei riferimenti più precisi? Devo arrivare ad avere una ISO che preinstalli un sistema minimale (niente desktop, solo server ssh), che poi mi arrangio senza problemi. Magari potendo stabilire a priori il layout delle partizioni. Certo che se la ISO standard seguisse il "principio" delle immagini per Raspberry (una partizione FAT con le configurazioni editabili) sarebbe tutto più facile :) Se non ho trovato male, live-helper, è stato sostituito da live-build. Dagli uno sguardo perché potrebbe fare al caso tuo. Ti fa creare una live, anche installabile, di debian, a secondo delle tue necessità. /paride Buongiorno Lista, A me interessa creare una live installabile. Sia per avere un backup esterno, che per avere anche un disco di recupero personalizzato. (Non distribuisco il mio sistema a nessuno, me lo tengo solo per me.) Avevo fatto qualche esperienza con Remastersys e con Systemback, dove avevo creato delle live installabili, che funzionavano bene, e funzionano ancora. Ma sono di distribuzioni vecchie. Ma poi, prima Remastersys poi Systemback, non hanno più funzionato. Per un motivo o per l'altro danno sempre degli errori e non creano più il file ISO che si può masterizzare. Ci sono delle guide o delle istruzioni semplici per usare il comando live-build ? Perché avevo provato ad usere anche quello ma era un po complicato per me. Grazie Cordiali Saluti Claudio -- https://www.linkedin.com/in/claudio-sandrone
Re: Debian e autenticazione esterna
Ciao Lorenzo. AD è grosso modo Kerberos + LDAP + DNS. Quindi se riesci a configurare l'autenticazione tramite Kerberos sei a posto per quel che riguarda la verifica della password. Ma non so come si comporti con la pre-creazione dell'utente in locale. Magari, se imposti che Kerberos venga interrogato prima dei file locali può funzionare. Il 15/02/2022 09:32, MAURIZI Lorenzo ha scritto: Ciao a tutti, mi rivolgo alla lista per trovare una soluzione al seguente quesito: è possibile autenticare gli utenti di un server Debian utilizzando Active Directory ma senza fare il join del server linux al dominio? Se sì, come? Il desiderata è che l’utente venga creato manualmente e collegato ad una autenticazione esterna, in modo da poter avere una password unica che viene gestita da AD nelle sue scadenze. Grazie in anticipo per ogni consiglio saprete darmi. Saluti da Lorenzo -- Diego Zuccato DIFA - Dip. di Fisica e Astronomia Servizi Informatici Alma Mater Studiorum - Università di Bologna V.le Berti-Pichat 6/2 - 40127 Bologna - Italy tel.: +39 051 20 95786
Debian e autenticazione esterna
Ciao a tutti, mi rivolgo alla lista per trovare una soluzione al seguente quesito: è possibile autenticare gli utenti di un server Debian utilizzando Active Directory ma senza fare il join del server linux al dominio? Se sì, come? Il desiderata è che l'utente venga creato manualmente e collegato ad una autenticazione esterna, in modo da poter avere una password unica che viene gestita da AD nelle sue scadenze. Grazie in anticipo per ogni consiglio saprete darmi. Saluti da Lorenzo
