Re: [OT] Scelta della distro in ambiente lavorativo
Il 13/05/24 07:37, Mario vittorio Guenzi ha scritto: Scusami se rispondo solo ora, sono giornate "interessanti" Presto detto, systemd e' la causa della nostra scelta. Il 10/05/24 08:45, Alessandro Baggi ha scritto: Ciao Mario, non preoccuparti e grazie per il tuo feedback. Alessandro.
Re: [OT] Scelta della distro in ambiente lavorativo
Il 12/05/24 21:34, Davide Prina ha scritto: Alessandro Baggi ha scritto: Il 12/05/24 11:09, Davide Prina ha scritto: ma non è detto che i container siano sempre la soluzione ottimale. Soprattutto se sei su un sistema di conteinerizzazione sul cloud a pagamento. In questo caso l'uso di macchine virutuali può essere la scelta ottimale sia per costi che per tempistiche. Inoltre con i container puoi incontrare difficoltà/problematiche che con le macchine virtuali non hai. Non ho molta esperienza sui container, a quali problematiche fai riferimento? dipende dal sistema di conteinerizzazione che stai usando e da come lo stai usando (SaaS, IaaS, ...), in alcuni casi potresti avere delle forte limitazioni (soprattutto casi SaaS)... tutto dipende da cosa devi fare. La logica tra container e vm è totalmente diversa e, secondo me, bisogna valutare bene caso per caso, sia lato costi che lato risultati che vuoi ottenere e trovare un bilanciamento tra i due. In generale se devi portare fuori qualcosa dai container, ad esempio log, e questi sono sopra certe dimensioni per unità di tempo potresti non avere uno strumento di base che ti garantisca che tutti siano portati fuori e devi crearti tu la soluzione. Normalmente i container hanno vantaggi su uso risorse e velocità, ma hanno meno sicurezza (RAM e SO condiviso... infatti alcune aziende richiedono macchine reali dedicate) e meno versatilità (es: hai quel solo SO). La scalabilità in orizzontale può essere importante per alcune applicazioni, ma, da quel che vedo io, nella maggior parte dei casi non ha nessuna importanza (nel parco applicativi che gestisce l'azienda dove lavoro). Alcune hanno un andamento più o meno lineare, altri hanno picchi, ma sai quando ci sono e quindi puoi scalare verticalmente prima. Inoltre il 99% degli applicativi deve essere sempre attivo e quindi non puoi neanche dire posso spegnere tutto in certi giorni/orari (anche se questo vale per entrambi i casi). Inoltre se vuoi tirarti su tu il sistema di conteinerizzazione non è così semplice ottenere qualcosa che sia funzionante e sicuro per essere usato da più applicazioni. Secondo me, da quel che leggo, hanno ragione le medie/grosse aziende che, dopo il covid, hanno iniziato a scappare dal cloud on-line e farsi un clund on-premis in propri data center. Ciao Davide Grazie Davide per le delucidazioni. Un saluto, Alessandro.
Re: [OT] Scelta della distro in ambiente lavorativo
Ciao Davide e grazie per la tua risposta. Il 12/05/24 11:09, Davide Prina ha scritto: Alessandro Baggi ha scritto: ci sono molti che sono ancora su virtualizzazione e non usano per tutto i container. ma non è detto che i container siano sempre la soluzione ottimale. Soprattutto se sei su un sistema di conteinerizzazione sul cloud a pagamento. In questo caso l'uso di macchine virutuali può essere la scelta ottimale sia per costi che per tempistiche. Inoltre con i container puoi incontrare difficoltà/problematiche che con le macchine virtuali non hai. Non ho molta esperienza sui container, a quali problematiche fai riferimento? Come viene visto l'utilizzo di una distribuzione senza supporto tecnico nel vostro ambiente lavorativo? solo Red Hat, tranne casi particolari (es: riuso di software), per motivi di assistenza e certificazioni. Però ho visto che nell'Unione Europea, intesa come istituzione e non come insieme di stati, viene usato Debian. Ho partecipato a delle riunioni per riuso di software e usavano solo Debian. Informazione molto interessante. Saluti, Alessandro
Re: [OT] Scelta della distro in ambiente lavorativo
Il 12/05/24 01:25, Paride Desimone ha scritto: Il 11 maggio 2024 07:16:12 UTC, Alessandro Baggi ha scritto: E la nostra cara vecchia Debian dove la mettiamo? Riuscite ad usarla in produzione senza troppi problemi? Il problema è che l'azienda vuole soluzioni e se non hai supporto poi iniziano i problemi. Io non appena posso vado sempre di stable, ma non sempre è consentito. Devi avere sempre dietro qualcuno che ti pari il fondo schiena in caso di problemi. /paride E quando non puoi andare di Debian generalmente cosa sei obbligato ad usare? Alessandro.
Re: [OT] Scelta della distro in ambiente lavorativo
Il 12/05/24 01:20, Paride Desimone ha scritto: Per systemd, beh, non smetterò mai di imprecare. Han voluto unificare ciò che prima era kiss. Ora se becchi un bug su systemd, inevitabilmente ha notevoli ripercussioni. /paride Si è vero. Ora Poettering ha lanciato 'run0' per sostituire sudo, chissa dove si andrà a finire. Alessandro.
Re: [OT] Scelta della distro in ambiente lavorativo
Ciao e grazie per la tua risposta. Il 11/05/24 00:42, Paride Desimone ha scritto: Il 8 maggio 2024 11:52:17 UTC, Alessandro Baggi ha scritto: Sembra più un modo per lavarsene le mani. Da una parte giustamente non è che possono dare supporto su tutto ma solo sul testato ma dall'altro se è una bazzecola perche non risolvere il problema del consumatore? Non sembra: lo è. D'altronde 8n qualche modo devono pur pararsi... Tra RHEL, Ubuntu PRO e SLES chi ha la matrice più malleabile? Innanzi tutto nel mondo redhat non rischierei di andare fuori in conflitto con rocky, alma, oracle, dopo la mossa di redhat sui sorgenti. nel mondo EL concordo su RockyLinux e Oracle ma Almalinux non proprio perche non è più 1:1 con RHEL ma bensi basata su CentOS Stream e mantiene la compatibilità binaria con RHEL. Anzi hanno gia cominciato a divergere da RHEL applicando patch che non sono state rilasciate su RHEL (e hanno contribuito in upstream), con la 9.4 (da quello che ho letto) hanno reintegrato dei driver per hardware che RHEL ha ritenuto obsoleti (principalmente controller e HBA). In più sono liberi di patchare quello che vogliono senza dover aspettare RHEL. Per esempio potrebbero reintegrare BTRFS (che sembra richiesto da molti) per non usare soluzioni basate su repository terzi e quindi qualcosa di più stabile. Per il supporto enterprise si appoggia a TuxCare. Ora non so il supporto TuxCare come lavora ma da un recente conferenza molti si stanno spostando su AlmaLinux (per la EOL di CentOS7) proprio perche non è incatenata a RHEL ed è molto stabile. Devo dire che quando si è svincolata da RHEL sta diventando un bel progetto. Di redhat posso dirti che con il client insight, è una figata pazzesca star dietro alle patch. Praticamente la stessa redhat ti manda gli advisory e tu tramite script ansible, creati automaticamente metti le patch al sistema. RHEL l'ho usata poco ma ho letto che insight è una bella cosa. Ubuntu, da quel poco che ho parlato con i commerciali, dovrebbero darti assistenza a ticket solo e soltanto sui loro pacchetti. Ubuntu la stavo per adottare ma poi snap mi ha fatto desistere. Suse invece, da quello che mi ha riferito in cliente, fornisce supporto su tutte le distribuzioni per essere portate in suse. Io mi son trovato male con yast. Molte cose se non le fai con yast non funzionano. Ad esempio se cambi il gestore di rete con network manager, da yast non configuri più la rete. Ed inoltre non ti disinstalla il vecchio demone. Quindi ti lascio immaginare. /paride E la nostra cara vecchia Debian dove la mettiamo? Riuscite ad usarla in produzione senza troppi problemi? Alessandro.
Re: [OT] Scelta della distro in ambiente lavorativo
Il 11/05/24 00:20, Paride Desimone ha scritto: Volevo chiederti, se non è un problema, come mai la scelta è caduta su Devuan e non direttamente su Debian? Un saluto, Alessandro. La butto li: Al 99% il supporto ed il restante 1% lo stramaledetto systemd /paride Buongiorno Paride, in che senso "al 99% il supporto"? Devuan offre un supporto migliore rispetto a Debian? Oramai systemd non lo considero un problema, è da tutte le parti (o almeno quasi) e siamo costretti in un modo o nell'altro a conoscerlo e ad usarlo. Alessandro.
Re: zfs
Il 10/05/24 14:24, Paride Desimone ha scritto: Il 26-04-2024 11:09 Paride Desimone ha scritto: La butto li, fare un destroy del pool e recuperarlo? https://docs.oracle.com/cd/E19253-01/819-5461/6n7ht6r0o/index.html zpool import -D no pools available to import Risolto. Era un problema di sequenza errata di montaggio dei dischi. erano cambiati gli uuid dei dischi. Una volta ricreati tutti gli uuid e rimontati nella giusta sequenza, tutto è tornato "magicamente" a posto /paride Ottimo, grazie per il feedback. Potresti riportare la procedura di risoluzione in modo che altri utenti possano usufruirne? Grazie.
Re: [OT] Scelta della distro in ambiente lavorativo
Buongiorno a tutti, credo dipenda da diversi fattori, il principale e' la dimensione dell'azienda, noi siamo piccoli e io decido che distro usare. L'assistenza (quando serve) ce la fornisce una piccola azienda di Milano con la quale collaboriamo da 25 anni o giu' di li. Tutto cio' molto difficilmente puo' succedere in azienda di dimensioni maggiori o che comunque ha una politica di tipo tutto deve essere certificato. Abbiamo scelto Devuan diversi anni fa per n+1 motivi che sono importanti per noi, chi ci supporta non ci ha mai lasciato a piedi, quindi son sempre stati soldi investiti intelligentemente. La mia esperienza se puo' esserti utile Un cordiale saluto a tutti. Ciao Mario, grazie per il tuo feedback. Volevo chiederti, se non è un problema, come mai la scelta è caduta su Devuan e non direttamente su Debian? Un saluto, Alessandro.
Re: [OT] Scelta della distro in ambiente lavorativo
Il 08/05/24 13:02, Diego Zuccato ha scritto: Ognuno ha la sua, e talvolta non è disponibile prima dell'acquisto [*]. Può essercene una per la distro, una per il sistema di storage, una per la connessione InfiniBand... Sta poi a te sapere prima *tutto* quel che ti serve e incastrarle. Poi ovviamente dopo aver fatto l'acquisto arriva qualcuno che deve fare una cosa diversa che al 90% ha dei requisiti in conflitto col resto. [*] caso "in corso": devo dotare di scheda IB dei server ordinati in convenzione. In convenzione la scheda IB non era più disponibile. Ho chiesto ad altri fornitori per avviare l'acquisto ma tutti vogliono il service tag delle macchine (che non ho ancora). Eccheccavolo! E' una scheda PCIE "standard", dovrebbe bastarti al limite il *modello* del server dove va montata... E invece no. Invece di andare avanti si torna indietro. :( Diego Sembra più un modo per lavarsene le mani. Da una parte giustamente non è che possono dare supporto su tutto ma solo sul testato ma dall'altro se è una bazzecola perche non risolvere il problema del consumatore? Nel caso in cui un utente abbia un contratto di supporto per una determinata distro e avesse problemi con apache, supponendo che sulla macchina ci sia del software da repository terzi ma che comunque non vanno in conflitto in nessun modo con apache, la matrice si ritiene rispettata oppure anche il solo installare un pacchetto terzo invalida il requisito? Tra RHEL, Ubuntu PRO e SLES chi ha la matrice più malleabile? Nel senso, chi tra questi da supporto anche al di fuori della matrice di compatibilità (tipo pacchetto che interagisce con apache ma che non fa parte della distro)? Un saluto. Alessandro
Re: [OT] Scelta della distro in ambiente lavorativo
Il 08/05/24 12:14, Diego Zuccato ha scritto: Il 08/05/2024 11:53, Alessandro Baggi ha scritto: Come viene visto l'utilizzo di una distribuzione senza supporto tecnico nel vostro ambiente lavorativo? Ogni volta che ho provato a suggerire di acquistare il supporto (p.e. per Proxmox) a momenti gli veniva un coccolone. Quanti di voi possono scegliere di utilizzare il sistema che preferiscono (quindi debian) e quanti invece sono costretti ad utilizzare distro RHEL (o based) o Ubuntu LTS per via di certificazioni (software/hardware) o per necessità di supporto tecnico (per pararsi il e richiesto a gran voce dal proprio superiore)? Talvolta la scelta diventa quasi obbligata: sto impazzendo per cercare di far funzionare BeeGFS con RDMA OFED in Debian. Con la 12 pare non ci sia possibilità (compila il client ma poi non lo carica), con la 11 vedrò appena reinstallo una macchina. Sicuramente poter starsene al riparo delle matrici di compatibilità ti evita molte grane: è oggettivamente più difficile che ci siano problemi. Ma ne crea poi altre. P.e. parecchi anni fa avevamo acquistato un sistema completamente ridondato per storage su FC, con director ridondante, 2 schede FC per ogni server, storage con doppia controller... tutto il pacchetto, insomma... proprio per non dover mai fermare tutto, e la prima volta che abbiamo avuto bisogno dell'assistenza qual'è stata la risposta? "Se non aggiornate il firmware all'ultima versione non siete in matrice di compatibilità e non possiamo aiutarvi". Morale: abbiamo dovuto fermare tutto solo perché prendessero in esame il problema, anche se evidentemente non era relativo alla versione di FW in uso (infatti dopo l'aggiornamento continuava a presentarsi). E non si parla di una ditta piccolina, ma al tempo era uno dei più grossi fornitori mondiali di sistemi di storage. Altra grana: per rimanere in matrice (e quindi in assistenza) potresti trovarti a violare la legge (p.e. perchè non puoi fare un aggiornamento del SO che andrebbe fuori matrice). Che scegli? IMVHO il problema è la mancanza di preparazione di chi offre assistenza e la burocretinite di dover per forza seguire una checklist prima di scalare la segnalazione a chi sa fare. Tipo l'assistenza di un grosso gestore, dopo che gli ho detto che avevo già riavviato il modem prima di chiamarli "eh, ma se non lo riavvia mentre è al telefono con me non posso procedere"... (ovviamente, riavviandolo cadeva la comunicazione). Ciao Diego e grazie per la tua risposta. Non ho esperienza con il supporto tecnico delle disco che lo forniscono, ma il concetto di "matrice di compatibilità" è interessante. In sostanza se non rispetti questa matrice non ti danno assistenza fino a che non rientri nei canoni...C'è un modo per sapere quale è la matrice di compatibilità in modo tale da poterla rispettare?
[OT] Scelta della distro in ambiente lavorativo
Un saluto a tutta la lista, mi scuso per OT e scusate la domanda strana. In ambiente lavorativo non si scherza e la scelta della distruzione Linux generalmente è dettata dalle esigenze (che siano software, certificazioni, supporto, sicurezza (fips140 e simili), team abituato a lavorare con determinate distro..ecc). Ultimamente noto che quando si parla di distribuzioni linux in ambito lavorativo, se non ha il supporto da chi la rilascia(come per RHEL [Almalinux con TuxCare e RockyLinux con CIQ], SLES o Ubuntu con Canonical) la distro viene lasciata in fondo alla lista (letteralmente la gente fa una smorfia). Ok con l'avvento dei container questo discorso lascia un pò a desiderare ma cmq ci sono molti che sono ancora su virtualizzazione e non usano per tutto i container. Come viene visto l'utilizzo di una distribuzione senza supporto tecnico nel vostro ambiente lavorativo? Quanti di voi possono scegliere di utilizzare il sistema che preferiscono (quindi debian) e quanti invece sono costretti ad utilizzare distro RHEL (o based) o Ubuntu LTS per via di certificazioni (software/hardware) o per necessità di supporto tecnico (per pararsi il e richiesto a gran voce dal proprio superiore)? Nel mio caso in passato mi è stato permesso di scegliere la distribuzione in un ambiente medio/grande e la scelta cadde su Debian e per la workstation avevo una Slackware mentre in un'altra esperienza lavorativa (piccola realtà) mi è stato richiesto di utilizzare CentOS per via di un software (quindi mi sono fatto dalla 6.5 alla 7.x). Attualmente invece non avendo necessità di certificazioni hardware e software la scelta è ricaduta di nuovo su Debian (alcune VM versione 11 e alcune sulla 12) e va una meraviglia. In che situazione vi trovate? Potete scegliere la distro su cui basare i vostri servizi oppure siete soggetti ad utilizzo di distro con supporto? Soprattutto, in casi in cui il supporto vi è stato richiesto, è stato utile oppure è solo una perdita di soldi e tempo? Cioè: vi hanno risolto veramente qualche grana oltre che provare a vendervi altri prodotti? Un saluto.
Re: zfs
Il 24/04/24 16:29, Paride Desimone ha scritto: Buongiorno. Ciao, non so se hai già risolto ma premetto che non sono ferrato su ZFS (lo uso da poco) ne tantomeno su VSphere/ESXi e company (non li uso da un bel po) quindi se dico qualche capp---ata, perdonatemi e correggetemi. Ho una vm con due dischi che erano parte di un pool zfs. Ora dopo che la macchina ha avuto varie problematiche (a seguito aggiornamento vmware non partiva più), ho la necessità di rimontare questi due dischi sulla stessa vm, che inutile dirlo non riesco a montare. Prima di tutto, scusa se te lo chiedo: ma hai/avete fatto qualche test prima di aggiornare tutto? Dalla mia esperienza con ESXi ad ogni aggiornamento era una menata, non oso immaginare migrare tra major release. Spero tu abbia un backup dei dati sul pool. dando: zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT ncdata - - - - - FAULTED - ho la situazione precedente. provo allora a fare uno "zpool status -x" ed ottengo pool: ncdata state: UNAVAIL status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-3C scrub: none requested Aborted (core dumped) Da quello che mi sembra di capire non vede i device. Infatti lui ti consiglia di metterli online con: "action: Attach the missing device and online it using 'zpool online'." Se non dovesse funzionare...da quello che ho capito sono dischi virtuali giusto? Questi dischi sono accessibili al sistema nel senso che il sistema li vede? Puoi maneggiarli? Le partition table di dei dischi per zfs è rimasta uguale? Può essere che durante l'aggiornamento c'è stata anche una modifica al formato delle immagini dei dischi e le stesse sono state modificate (aggiornate al nuovo formato) e zfs non riconosce più i suoi devices? > Se gli do zpool import ncdata > ottengo > cannot import 'ncdata': a pool with that name is already created/imported, > and no additional pools with that name were found > Potresti provare ad esportare il pool e poi re-importarlo ma non so che succede se è in uno stato UNAVAIL Prova ad importare specificando almeno un device (non sono responsabile di quello che succederà), tipo: # zpool import -d /dev/sdb1 ncdata se gli do zpool add ncdata /dev/sdb1 /dev/sdc1 ottengo cannot open 'ncdata': pool is unavailable Ora, non sono proprio ferrato in zfs. Qualcuno saprebbe darmi una mano a capire come montare questi dischi per poter accedere i dati? La butto li, fare un destroy del pool e recuperarlo? https://docs.oracle.com/cd/E19253-01/819-5461/6n7ht6r0o/index.html Magari fa qualche prova su un'altra VM con immagini di piccole dimensione e con qualche dato dentro e vedi se un export, un destroy non ti distrugge i dati e ti permette veramente di recuperare il pool. Al momento non mi viene altro in mente se non ricrea il pool e fai il restore del backup. Qualche nota su ZFS: 1. per esperienza personale devi sempre usare i nomi persistenti dei dischi con ZFS (tipo /dev/disk/by-id/.). Qualche tempo fa ho usato i nomi canonici e la scheda madre li invertiva ad ogni reboot cosi ZED mi rompeva ad ogni avvio dicendo che c'èrano problemi e mi lanciava un resilvering. 2. Mi hanno sempre sconsigliato di utilizzare ZFS su dischi virtuali in quanto ZFS deve accedere direttamente ai device. Inoltre se le immagini virtuali sono COW mettere un filesystem COW su immagini COW rallenta le performance, ma di usare i device fisici, montarli e dire all'hypervisor di usare quel mountpoint come risorsa. Se proprio non ne puoi fare a meno e sei costretto ad usare come dischi delle immagini che siano almeno in formato RAW. Non ho esperienza di questo ma sembra sensato. Fammi sapere come va, che sono interessato. Un saluto.
Re: Debian 12.5 e ZFS [BUG]
Il 14/04/24 10:23, Davide Prina ha scritto: Alessandro Baggi ha scritto: In Debian Bookworm (12.5) è presente zfs-dkms versione 2.1.11-1. Tempo fa, come molti ricorderanno (nel 2023) è stato trovato un bug Non riesco a trovare nulla che indichi che in stable il problema sia stato risolto se usi Firefox installa webext-debianbuttons... è un'estensione utilissima * ti copi il nome del pacchetto zfs-dkms * apri debian buttons e fai click su package tracker questo ti apre la pagina del riepilogo del pacchetto sorgente usato per generare quel pacchetto * qui fai clic su "security tracker" e ti apre: https://security-tracker.debian.org/tracker/source-package/zfs-linux questo per vedere se il bug di sicurezza è stato risolto e dove se il bug non è di sicurezza, allora devi guardare tra i bug normali e anche per questo c'è il link sulla stessa pagina. https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=yes=zfs-linux Notare che in questo caso essendo coinvolto anche coreutils dovresti vedere anche questo pacchetto. In alternativa puoi eseguire: $ apt changelog zfs-dkms e vedere se è citato nei changelog Se il bug è questo: https://github.com/openzfs/zfs/issues/15526 allora è indicato che The bug was fixed in #15571 and was backported to 2.2.2 and 2.1.14. Altrimenti con quanto indicato sopra dovresti riuscire a trovare qualche riferimento e capire se è risolto sulla tua installazione. Ciao Davide Ciao Davide, e grazie mille per i link, mi si è aperto un mondo La prossima volta userò il bugtracker di debian prima di cercare altrove. Nel primo link che hai postato, non so perche io cercavo zfs-dkms invece di zfs-linux, è riportato il bug e in debian bookworm non è fixato (è marcata come vulnerable). Inoltre ho letto in fondo alla pagine questa riga: "[bookworm] - zfs-linux (contrib not supported)" (no-dsa dovrebbe significare che non è urgente nel senso che non è un bug critico per la sicurezza [no-dsa è stato cambiato in e dal 03/2024)] ma leggendo qui: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056752 il manutentore riporta che: "The fix will land in bookworm-backports and bullseye-backports-sloppy shortly after 2.1.14-1 migrates to testing, which will take about 2 days hopefully. Fixes to 2.0.3-9+deb11u1 (bullseye) and 2.1.11-1 (bookworm) are planned but will likely take more time. Such an issue is marked low-priority because the bug itself isn't urgent from a security update point of view, which means an attacker can only cause damage in rare cases. It's still recommended to update or at least apply mitigations to the problem (by setting zfs_dmu_offset_next_sync to 0 on bookworm) to avoid potential data loss." quindi impostando zfs_dmu_offset_next_sync a 0 non dovrebbe esserci il problema e nessuna perdita di dati? e anche il comando apt changelog fenomenale, non lo conoscevo, per non parlare dell'estensione per FF. Grazie ancora! Un saluto, Alessandro.
Re: Debian 12.5 e ZFS [BUG]
Il 12/04/24 14:56, Piviul ha scritto: On 4/10/24 20:09, Alessandro Baggi wrote: Salve ragazzi, ho un dubbio che non riesco a districare. In Debian Bookworm (12.5) è presente zfs-dkms versione 2.1.11-1. Tempo fa, come molti ricorderanno (nel 2023) è stato trovato un bug che era presente da molti anni ma che sui sistemi con coreutils 9 in certe condizioni corrompeva i dati. Non riesco a trovare nulla che indichi che in stable il problema sia stato risolto tipo un nuovo aggiornamento, delle istruzioni per mitigare il problema, molte volte (anche il progetto openzfs) dice di usare backports ma i backports non fanno parte del progetto LTS, cosi il supporto è minore in termini di tempo. non uso zfs ma mi accodo alla domanda ed aggiungo non esiste un changelog per ogni aggiornamento di un pacchetto? ...può anche darsi che su bookwork tutti usino i pacchetti zfs su backports ma parrebbe strano che nessuno si lamenti di data corruption in debian bookworm. Comunque a questo punto la curiosità è tanta... Piviul Ciao Piviul, ho fatto un pò di ricerche. Sembrerebbe che la versione su Debian 12 non sia interessata da quel bug specifico. Invece è presente un bug di corruzione nel caso si utilizzi la cifratura di ZFS e si esegua un send (se non ho capito male) ma non uso la cifratura di ZFS. Non capisco pero perche non viene riportato niente per il pacchetto di stable. Non ho letto di nessuno che abbia problemi o si lamenti del bug su Debian Stable quindi o nessuno usa ZFS, o non è presente o tutti usano zfs dai backports oppure tutti se ne fregano. Ho comunque fatto dei test e ho lanciato uno script che riproduce l'errore (ovvero i file copiati dovrebbero essere pieni di 0..). Il test l'ho fatto girare per qualche ora e in nessuna iterazione del test mi ha dato errore. Questo non significa che il bug non sia presente ma dopo diverse ore di scritture se non è uscito qualcosa. Inoltre ho letto che c'è una mitigazione che consiste nell'aggiungere un parametro di boot per zfs: zfs.zfs_dmu_offset_next_sync=0 che ho comunque attivato prima di avviare lo script riproduttore. Inoltre ho letto che il bug affligge solo chi ha il block cloning attivo, e nel caso di Debian 12 non sembra esserci. In un post su Reddit viene riportato: "If it says disabled, you are not hit by this bug: zpool get all|grep block_cloning" So che non è una fonte autorevole ma i test sembrano confermarlo. Un saluto. Alessandro.
Debian 12.5 e ZFS [BUG]
Salve ragazzi, ho un dubbio che non riesco a districare. In Debian Bookworm (12.5) è presente zfs-dkms versione 2.1.11-1. Tempo fa, come molti ricorderanno (nel 2023) è stato trovato un bug che era presente da molti anni ma che sui sistemi con coreutils 9 in certe condizioni corrompeva i dati. Non riesco a trovare nulla che indichi che in stable il problema sia stato risolto tipo un nuovo aggiornamento, delle istruzioni per mitigare il problema, molte volte (anche il progetto openzfs) dice di usare backports ma i backports non fanno parte del progetto LTS, cosi il supporto è minore in termini di tempo. Ho provato a inviare un'email al manutentore del pacchetto ma non ho ricevuto risposta. Qualcuno sa con certezza se il BUG in stable è stato fixato o no? Sono costretto ad usare zfs-dkms da bookworm-backports? Un saluto e una buona serata. Alessandro.
Re: Bullseye e squidguard...
Il 03/03/24 18:11, Marco Gaiarin ha scritto: Mandi! Alessandro Baggi In chel di` si favelave... 1. Apparmor con profilo per squid? Ah, ecco, vedi... root@vcoreacpn1:~# apparmor_status apparmor module is loaded. 9 profiles are loaded. 9 profiles are in enforce mode. /usr/bin/man /usr/sbin/ntpd /usr/sbin/squid lsb_release man_filter man_groff named nvidia_modprobe nvidia_modprobe//kmod 0 profiles are in complain mode. 12 processes have profiles defined. 12 processes are in enforce mode. /usr/sbin/ntpd (444) /usr/sbin/squid (1707739) /usr/sbin/squid (1707741) /usr/sbin/squid (1707742) /usr/sbin/squid (1707743) /usr/lib/squid/pinger (1744240) /usr/sbin/squid /usr/lib/squid/log_file_daemon (1752035) /usr/sbin/squid /usr/lib/squid/log_file_daemon (1752036) /usr/sbin/squid /usr/lib/squid/pinger (1752037) /usr/sbin/squid /usr/lib/squid/log_file_daemon (1752038) /usr/sbin/squid /usr/lib/squid/pinger (1752039) /usr/sbin/squid /usr/sbin/named (2431) named 0 processes are in complain mode. 0 processes are unconfined but have a profile defined. Ho trovato anche: https://bugs.launchpad.net/ubuntu/+source/squid3/+bug/1787409 quindi c'è una patch, almeno per ubuntu... 2. Il permission denied è relativo a squid che richiama squidguard o il permission denied è dato da squidGuard? 3. Cercando in rete sembra che ipcCreate sia una funzione di squidGuard (non ho visto cosa fa) quindi potrebbe essere questa funzione. Boh... ma squidguard non emette alcun log, quindi non si capisce. 4. Problemi con i db di squidGuard? Lo escludo. ora resta da capire cosa è meglio fare... Ciao, io per prima cosa disabiliterei il profilo apparmor di squid e poi avviare il tutto. Se è quello modifichi il profile di squid aggiungendo squidGuard.
Re: Bullseye e squidguard...
Il 01/03/24 14:41, Marco Gaiarin ha scritto: Stavo tentando di configurare squid e squidguard come faccio di solito, su bullseye, ma qualcosa non torna. La configurazione è corretta, e se la lancio a mano parte: root@vcoreacpn1:/etc/squid# su - proxy -s /bin/sh -c '/usr/bin/squidGuard -d -c /etc/squidguard/squidGuard.conf' 2024-03-01 14:36:46 [1708037] INFO: New setting: dbhome: /var/lib/squidguard/db 2024-03-01 14:36:46 [1708037] INFO: New setting: logdir: /var/log/squidguard 2024-03-01 14:36:46 [1708037] init iplist /var/lib/squidguard/db/local/staff [...] 2024-03-01 14:36:46 [1708037] init urllist /var/lib/squidguard/db/ut1/dating/urls 2024-03-01 14:36:46 [1708037] INFO: loading dbfile /var/lib/squidguard/db/ut1/dating/urls.db 2024-03-01 14:36:46 [1708037] INFO: squidGuard 1.6.0 started (1709300206.114) 2024-03-01 14:36:46 [1708037] INFO: squidGuard ready for requests (1709300206.153) ma se provo a eseguirlo da squid con: url_rewrite_program /usr/bin/squidGuard -c /etc/squidguard/squidGuard.conf url_rewrite_children 10 ottengo un flood in syslog e in cache.log di squid di: 2024/03/01 14:22:59 kid1| Starting new helpers 2024/03/01 14:22:59 kid1| helperOpenServers: Starting 1/10 'squidGuard' processes 2024/03/01 14:22:59 kid2| ipcCreate: /usr/bin/squidGuard: (13) Permission denied 2024/03/01 14:22:59 kid2| WARNING: redirector #Hlpr175 exited cosa sbaglio?! Ho cercato in rete ma a parte qualcuno che ha effettivamente fatto errori di permessi, non ho trovato nulla. Il log di squidguard resta immacolato e vuoto. Grazie. Ciao Marco, è un po che non uso squidGuard, ma a prima vista mi viene in mente: 1. Apparmor con profilo per squid? 2. Il permission denied è relativo a squid che richiama squidguard o il permission denied è dato da squidGuard? 3. Cercando in rete sembra che ipcCreate sia una funzione di squidGuard (non ho visto cosa fa) quindi potrebbe essere questa funzione. 4. Problemi con i db di squidGuard? Prova a lanciare squidguard senza squid con un comando del genere: echo “http://www.example.com 10.0.0.1/ – – GET” | squidGuard -c /tmp/test.cfg -d e vedi se ti riporta errori. Saluti, Alessandro.
Re: Debian 12.4 Kernel Panic durante spegnimeto
Il 14/01/24 12:00, Davide Prina ha scritto: ma hai lo stesso problema anche con i driver liberi? Io userei quelli. Ho provato con nouveau e con quelli il problema si presenta di più. Tieni conto che versioni nuove di Linux possono far cambiare le API esposte rendendo il tutto incompatibile con quelle delle versioni precedenti. Se tu hai una vecchia scheda può essere che i driver proprietari non vengano più aggiornati per quella tua scheda e questo potrebbe essere la causa del problema. Per essere sincero, il problema mi si presenta con Debian 12. Ho provato anche altre distro tra cui Ubuntu (sempre driver sito Nvidia) e anche AlmaLinux e il problema non si presenta. A questo punto sembra riconducibile ad una problematica del kernel di Debian. Altro caso potrebbe essere che c'è un bug nella nuova versione di Linux... puoi cercare nei bug report se trovi qualcosa. Cercherò. Grazie per la risposta. Un saluto Alessandro.
Re: Debian 12.4 e ZFS
Ciao Gerlos e grazie per la risposta. Mah, io per non saper né leggere né scrivere userei ZFS per i volumi che contengono i dati, e metterei il sistema operativo su un file system supportato nativamente dal kernel, come i ben noti ext4 e xfs. In questo modo nella remota ipotesi in cui qualcosa vada storto con dkms puoi comunque avviare il sistema, risolvere la questione e montare il volume o i volumi dei dati in un secondo momento (con l'opzione "nofail" in /etc/fstab il sistema prosegue il boot anche se non può montare un certo volume). La mia intenzione era lasciare solo i dati su ZFS e il sistema su ext4. A ogni modo anche io userei btrfs, soprattutto per un server di backup casalingo, dove il fatto che è più lento di zfs non conta più di tanto (immagino che il collo di bottiglia sia la rete, non lo storage). Il server non è un server casalingo ma un piccolo server di backup. Ho usato poco BTRFS ma pensandoci comunque il raid1 non ha problemi (tipo write hole), ha la compressione, l'integritità e la deduplicazione ed è supportato nativamente dal kernel di Debian. Devo studiare un po btrfs perche ho solo letto qualcosa online ma non ho fatto nulla di concreto. Intanto perché mi fanno antipatia i problemi di licenza di zfs, ;-) poi per evitare problemi con dkms, Stesso sentimento. e infine perché rispetto a zfs con btrfs mi sembra più facile "rimescolare le carte" a posteriori (sostituire dischi, passare da una configurazione all'altra, etc... ma probabilmente sono io che non ho capito zfs). In realtà, si, btrfs sembra più flessibile (da quello che ho letto). Con ZFS non puoi fare alcune cose (non ricordo bene quale operazione) ma devi per forza ricreare il pool. Domanda: Usare btrfs su SSD comporta qualche problema? Saluti, Alessandro.
Re: Debian 12.4 e ZFS
Il 12/01/24 10:46, gianluca.signoro...@eritrium.org ha scritto: Il 12/01/24 09:29, Alessandro Baggi ha scritto: Io sapevo che era necessario 1GB di RAM per ogni TB in caso di deduplicazione. per quanto ne so, al contrario, assieme alla deduplicazione, molte altre caratteristiche di ZFS richiedono RAM. https://web.archive.org/web/20140818042550/http://hardforum.com/showpost.php?s=8d31305e57c1dd2853eb817124ff18d9=1036865233=3 Grazie per la risorsa. Quindi da un certo punto di vista mi sconsigli di utilizzare ZFS su una distro che utilizza dkms per zfs a livello di stabilità? Non a livello di stabilità ma, come scrivevo, semplicemente perché non mi piace avere di mezzo DKMS per avere ZFS su Debian, ma ciò e personale. Se a te va bene nullaosta. Anche a me non piace avere di mezzo DKMS anzi è proprio questo che mi ha reso indeciso.
Re: Debian 12.4 e ZFS
Ciao Gianluca e grazie per la riposta. Ciao, con i suoi oltre 20 anni di sviluppo DKMS immagino, da quel punto di vista, sia ben maturo ed affidabile e non faccia scherzi di quel tipo... tutto può essere eh. È da tenere presente che ZFS richiede molta RAM per funzionare a dovere; se intendi adottarlo, assicurati di averne abbastanza disponibile. Utilizzo Proxmox ed avendo letto la loro documentazione, consigliano 4 GB RAM di base più 1GB di RAM per ciascun TB di spazio disco. Io sapevo che era necessario 1GB di RAM per ogni TB in caso di deduplicazione. Ora, Proxmox usa un kernel modificato ma proveniente da Ubuntu (per ragioni di licenza è dovuta la scelta) e lì non c'è quindi bisogno di DKMS. Su una Debian a seconda dei casi preferisco, invece, affidarmi a BTRFS. A presto, Quindi da un certo punto di vista mi sconsigli di utilizzare ZFS su una distro che utilizza dkms per zfs a livello di stabilità? Un saluto.
Debian 12.4 e ZFS
Un saluto a tutti i partecipanti. Spero di non essere OT. Ho un piccolo server di backup sui cui è presente un RAID1 mdadm e xfs come storage. Volevo aggiungere un controllo di integrità per i dati e ho trovato tre soluzioni: 1. dm-integrity + mdadm 2. ZFS 3. Btrfs Dopo qualche test casalingo, qualche ricerca e qualche lettura tipo [1](anche se è del 2020) alla fine ho optato per ZFS. Ho provato dm-integrity e mdadm ma su dischi da 3TB ci mette un po perche quando formatta per dm-integrity deve fare il wipe di ogni device quindi due device da 3TB, poi deve creare il raid quindi bisogna aspettare il sync dei 3TB. Inoltre per verificare errori di integrità devo lanciare un check sul raid mdadm e ci mette un po, per non parlare in caso di guasto in cui devo ricreare il device dm-integrity e rifare il sync. Non immagino il tempo necessario con dischi più capienti. Con ZFS invece il resilvering è più veloce e inoltre offre altre funzionalità che non si hanno con dm-integrity + mdadm + xfs. Debian supporta ZFS dai repo stable contrib e backports contrib. Ho letto in rete che era presente un bug problematico che riportava ad una corruzione dei dati (deve verificarsi un determinata condizione) e per Debian si consiglia di utilizzare la versione di ZFS presente sui backports perche aveva la versione fixata. Qualcuno lo usa al momento (non per uso casalingo) e ha qualche suggerimento prima di convertire lo storage? Ho gia effettuato il backup del backup. L'unica cosa che mi rende insicuro della scelta è che ZFS è compilato con DKMS e ad ogni aggiornamento del kernel viene ricompilato e qui sta il problema. Vi è mai capitato che DKMS fallisse una ricompilazione di ZFS? In caso di errori di compilazione cosa fare (oltre ad usare il kernel precedente dove ZFS funzionava correttamente)? Al momento uso DKMS per i driver NVIDIA (dal sito NVIDIA) e non ho mai avuto problemi da due anni a questa parte, ma mai dire mai. Che esperienza avete con questo FS? Avete avuto brutte sorprese? Grazie a tutti in anticipo. Saluti. [1] - https://www.unixsheikh.com/articles/battle-testing-zfs-btrfs-and-mdadm-dm.html
Re: Debian 12.4 Kernel Panic durante spegnimeto
Ciao Davide, grazie per la risposta e mi scuso per non aver risposto subito ma ho avuto dei problemi. non so se possa centrare, ma prova ad usare systemctl per spegnere # systemctl halt # systemctl poweroff Il secondo fa le stesse cose del primo comando, ma in più toglie "corrente" se non si spegne si può usare l'opzione --force se vuoi schedularlo usa l'opzione --when per riavviare # systemctl reboot Inoltre proverei anche: $ systemctl is-system-running per verificare se il sistema è in funzione normalmente o è degradato per vedere se c'è qualcosa di annomalo $ systemctl status Grazie per i suggerimenti. Come detto nelle email precedenti, pensado che il problema fosse derivato dalla scheda video avevo rimosso la scheda video (una vecchia GTX 1050ti) e usato quella della CPU e come riportato i kernel panic non si sono più verificati. Non contento ho voluto fare qualche test e avevo reinstallato la scheda video usando i driver proprietari dal sito di NVIDIA (configurazione che sto usando al momento). Il problema sembrava risolto ma poi inaspettatamente ad uno shutdown un kernel panic (solo 1 dalla data della tua risposta). Sempre per supportare la mia tesi sui problemi della scheda video ho notato che con XFCE dopo che lo schermo va in standby per inattività, quando lo riattivo vedo simboli strani al posto delle lettere sullo schermo fino al movimento del mouse. Non vorrei che la scheda video creasse artefatti a causa di un danno e mi generi il problema allo spegnimento. Secondo te è possibile? Un grazie ancora e scusate il ritardo. Saluti.
Re: Debian 12.4 Kernel Panic durante spegnimeto
Ciao Giuseppe, per quel poco che capisco, si tratta del codice di spegnimento del kernel, nella parte dell'array multidisk che va a interrompere le scritture su tutti i dischi dell'array. Si, ho notato che nel trace ci sono riferimenti ad md. Potresti provare a segnalare il problema direttamente sul kernel. Ci sono problematiche simili alla tua, come questa: https://bugzilla.kernel.org/show_bug.cgi?id=217733 Interessante ma mi chiedo, se fosse un bug del kernel non dovrebbero esserci molte più segnalazioni al riguardo? Non credo siamo gli unici ad avere una debian installata su MD device o che usano MD device. Cmq prima di aprire un nuovo bug farò qualche altro test. Tra qualche giorno aggiorno il mio server di backup dalla 11 alla 12 con device MD e vediamo se ho lo stesso problema (proverò a collegare anche la scheda video in questione per replicare la problematica che ho sulla "workstation"). Io sto continuando con i test hardware. Ieri ho tolto la scheda di rete ma il problema si è ripresentato. Ho proceduto con la rimozione della scheda video. In questo processo ho prima disinstallato i driver nvidia dei repo di debian e riavviato un paio di volte. Ad ogni riavvio ho avuto kernel panic. Quindi il problema si è verificato con i driver nvidia di debian e i driver nouveau. Scollego la scheda video e i kernel panic sono finiti (almeno per il momento). Ora mi chiedo e se dico una cappellata correggimi: è possibile che la scheda video (essendo collegata sullo slot PCI-E) o i driver causino problemi ai device MD da generare un kernel panic? Te lo chiedo perche i due dischi primari sono due nvme in raid1 in modalità PCI-E (che se attivati in PCI-E mode disabilatano alcune porte SATA). Grazie ancora. Alessandro.
Re: Debian 12.4 Kernel Panic durante spegnimeto
Il 21/12/23 12:25, Alessandro Baggi ha scritto: Mi sa che l'unica cosa che puoi fare è una foto allo schermo, oppure usare un cavo seriale collegato ad un altro computer e impostare la console su seriale. Ho caricato l'immagine su postimg e sarà disponibile per 7 giorni. Di seguito il link: https://i.postimg.cc/HnpDpmj1/20231220-204617.jpg Un saluto, Alessandro. Sono riuscito a catturare tutta la schermata del panic con un video. Ho preso le immagini significative in quest'ordine: debug1, debug2, debug3. In queste tre immagini dovrebbe esserci il trace del kernel panic. Di seguito il link alla galleria: https://postimg.cc/gallery/y68sgvD Saranno attive per 7 giorni. Un saluto, Alessandro.
Re: Debian 12.4 Kernel Panic durante spegnimeto
Mi sa che l'unica cosa che puoi fare è una foto allo schermo, oppure usare un cavo seriale collegato ad un altro computer e impostare la console su seriale. Ho caricato l'immagine su postimg e sarà disponibile per 7 giorni. Di seguito il link: https://i.postimg.cc/HnpDpmj1/20231220-204617.jpg Un saluto, Alessandro.
Re: Debian 12.4 Kernel Panic durante spegnimeto
Ciao Giuseppe e grazie per la risposta. Mi sa che l'unica cosa che puoi fare è una foto allo schermo, oppure usare un cavo seriale collegato ad un altro computer e impostare la console su seriale. Sono riuscito a fare una foto dello schermo del kernel panic ma il messaggio è molto più lungo di quello che appare nell'immagine. Domanda: posso allegare la foto in ML oppure devo usare qualche altro servizio? Difatti i casi di oops durante lo shutdown, se avvengono con il journald già spento, non sono nel log. Come ad esempio questo: https://github.com/systemd/systemd/issues/14829 Sto facendo qualche prova rimuovendo hardware dal PC. Ti dico questo perche ricevo: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) devive [10ec-8168] Il device [10ec-8168] corrisponde ad una scheda di rete TPLink. Ho rimosso la scheda e vedo se ottengo un kernel panic. inoltre il dmesg mi da anche: pcieport :00:1b.0: DPC: error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 4, DL_ActiveErr+ pcieport :00:1c.4: DPC: error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 4, DL_ActiveErr+ pcieport :00:1d.0: DPC: error containment capabilities: Int Msg #0, RPExt+ PoisonedTLP+ SwTrigger+ RP PIO Log 4, DL_ActiveErr+ Devo dire che durante queste prove, ho ottenuto 3 kernel panic in 3 spegnimenti consecutivi. Cmq se il problema continua, provo a disintallare i driver nvidia con successiva rimozione della vecchia Nvidia GTX 1050ti e invierò aggiornamenti in lista. Non vorrei arrivare a conclusioni affrettate ma ho paura che sia la scheda madre. In passato mi ha dato problemi con le porte sata. Ora ha cominciato con le PCI-E. Vedremo dove portano questi test.
Debian 12.4 Kernel Panic durante spegnimeto
Un saluto cordiale a tutta la lista. Ho un problema durante lo spegnimento del mio PC. Ho una Debian 12.4. In poche parole ogni tanto quando lancio uno shutdown -h now o un reboot ottengo un bel kernel panic. É casuale e capita circa due/tre volte al mese. È da quando ho installato la 12 che questo accade mentre quando ero sulla 11 non accadeva. Credevo fosse un problema dei primi kernel di debian (l'ho installata appena uscita) ma il problema persiste quindi mi viene da pensare che sia un problema hardware? Su questa PC ho un i9-10850k (leggermente in OC ma con Vcore auto), scheda madre ASUS Prime Z490-A, 16 GB ddr4, per scheda video una vecchia Nvidia 1050ti, 2 nvme e due ssd sata (tutti i dischi li uso da meno di un anno) e alimentatore ASUS ROG Gold da 850W (anche l'alimentatore è recente e l'ho installato prima del passaggio alla 12.4). Cosa ci gira: Debian 12.4. Ho configurato 4 mdadm device tipo raid 1, ho qualche macchina virtuale e qualche servizio come apache2, smb. Tutto il software è installato tramite repository di debian eccetto per chrome. Nessun flatpak o snap. Filesystem ext4 e xfs. Cmq niente di esotico. Nota: ho provato ad installare sempre sugli stessi dischi e con la stessa configurazione ubuntu e AlmaLinux ma non ho riscontrato errori di nessun tipo. L'ultima volte è stato ieri sera verso le 21. Ho provato a leggere i log con journalctl --system --since="2023-12-18 20:00:00" e le ultime righe prima del boot odierno sono: systemd[1]: Shutting down. systemd-shutdown[1]: Syncing filesystems and block devices. systemd-shutdown[1]: Sending SIGTERM to remaining processes... systemd-journald[461]: Received SIGTERM from PID 1 (systemd-shutdow). systemd-journald[461]: Journal stopped -- Boot c86eb14c26cd47f1b95d903d39dc419c -- non ho riscontrato errori e dalle riga Boot riporta il boot di oggi. Non so dove posso trovare altri log relativi al kernel panic ( a dirla tutta non so se salva i messaggi del panic che si verifica durante uno shutdown) Durante l'utilizzo della macchina non ho nessun problema. Ho provato a lanciare qualche sessione di Prime95 per stressare ram e cpu ma va tutto bene. Ho stressato un po i dischi ma nessun problema. I driver della scheda video sono da contrib. Essendo un po vecchia la scheda video non vorrei cominciasse a dare i primi problemi. Ma anche in questo caso durante l'utilizzo nessun problema. Purtroppo non ho l'immagine con i messaggi del paniclo so Qualcuno ha qualche suggerimento su cos'altro indagare? Grazie a tutti. Un saluto e buone festività.
[OT] Diamoci una regolata, era NOW epic fail, era codice di condotta,era Sensori di..
Salve lista, ma ti pareva che un'altra volta usciva fuori una menata del genere? Spero che questa sia l'ultima email di questa penosa conversazione. Non voglio dare una lezione a nessuno, ma diamoci una regolata (me compreso con il quoting). Tutti possono scrivere quello che vogliono, come vogliono, possono polemizzare, ecc.. è una lista libera... ma a tutto c'è un limite e nessuno ha cercato di non andare oltre. Ripartiamo dall'inizio. Ieri ho postato un messaggio nel quale ho quotato male i contenuti precedenti. Cosmo mi risponde, diciamo "chiedendomi" di quotare meglio e di lasciare fuori le informazioni non necessarie. Fin qui non fa una piega anche se le ultime righe della sua risposta erano un pò polemiche. Notando il suo tono polemico mi sono preso la briga di non rispondere e cercare una soluzione per conto mio non facendo riferimento alla lista proprio per evitare quello che è successo. Ricordiamocelo, tutte le cose che abbiamo scritto rimangono online e questo non va bene per la comunità di Debian Italia (che poi i singoli utenti facciano una figura della ceppa affari loro). Torno un momento sul quoting. Non c'è nessun problema se un utente chiede ad un altro di quotare meglio per rendere più leggibile una "conversazione", c'è chi preferisce l'ordine, chi il disordine, è semplicemente una preferenza e quella di Cosmo è una richiesta "legittima" Il modo in cui viene chiesto è diverso (e anche qui dipende da chi legge la risposta, da come la interpreta, il che la dice lunga). Cosmo, non voglio dare lezioni, sono solo opinioni...ma non era meglio scrivere (anche se per l'ennesima volta): "Ciao, ti prego di quotare meglio le tue prossime email e di omettere le parti non necessarie in modo tale da aiutare a capire meglio il problema. Nonostante questo prova a" invece che: "E non sperare che lo faccia gmail al posto tuo. Devi farlo tu, cancellando le parti della mail che non servono *prima* di inviarla. Se non lo fai, dovrò presumere che dei tuoi interlocutori te ne sbatti e quindi, per quanto mi riguarda, agirò di conseguenza, sbattendomene dei tuoi problemi." o: "se vuole avere una mano da *me*, di rendermi le sue mail più leggibili. Delle regole m'importa poco: m'importa che non mi venga mal di testa per leggere le sue mail - se poi non vuole il *mio* aiuto" Cosmo, mi viene da pensare che anche tu non hai interesse nel mantenere la lista un "luogo" di incontro e di aiuto, nel tuo messaggio ci sono parole poco conformi allo spirito di una comunità: "Devi", "se vuole una mano da me", "sbattendomene dei tuoi problemi"...ripeto, posso capire il fastidio del quoting, la tua frustrazione nel leggere email "incasinate"...ma datti una regolata, ogni tanto lascia correre...anche perche la prima cosa che mi viene da dire dopo aver letto le tue risposte è: "ma chi co sei?" e questo sembra sia un pensiero comune. La prossima volta,se non ti garba il quoting cestina direttamente il messaggio o almeno non rispondere come hai fatto perche poi arriva qualche altra testa calda che accende la discussione. Ripeto alla lista Debian Italia questo non serve. Se poi volete avere il diritto di controbattere per arrivare a questa penosa discussione va bene, dico solo poverà community. Ma comunque, nonostante le polemiche, Cosmo HA CERCATO DI AIUTARMI ed è stato l'unico. Poi è intervenuto Cantanna, riportando la sua opinione. Cosmo a risposto nuovamente "devi cambiare " ancora polemizzando. Scusa Cosmo ma non serviva un'altra polemica, hai contribuito di nuovo al flame, bastava che tu le ignorassi ma mi viene da pensare che eri pronto allo scontro gia dalla mia prima email. Cantanna: anche te non è che ci sei andato leggero, messaggi in privato ecctu hai superato il limite...che poi Cosmo ha riportato i msg in lista (peggio ancora). Anche questo non fa bene alla community. Un casino. Poi è arrivato Fabrizio con: "Ciccio datti una bella calmata perchè non sei utile, figuriamoci indispensabile..." e via con un altro carico, male per la community. Poi Valerio con: "il messaggio di cantanna era anche in html" e "ha scritto a cosmo anche in privato (cc), anzi ha scritto a cosmo e per cc in lista" altro benzina sul fuoco, male per la community. Non c'è stato nessuno che ha cercato di placare i toni e di non far degenerare la discussione o di riportare la discussione sull'aiuto alla risoluzione del problema (quello per cui la lista è stata creata oltre che per altre cose). I moderatori ci sono? Chi sono? La lista è abbandonata? Se ci siete battete un colpo per favore, avere delle regole ma nessuno che le fa "rispettare" o che almeno mette un punto su questa penosa discussione non serve a nulla. Sempre ai moderatori, non vi aspettate che solo perche ci sono delle regole gli utenti si prendono la briga di rispettarle, anche perche questo non accade (forse andava bene 15 anni fa). Questo mi fa pensare che questa lista
Re: [OT] Sensori di temperatura e Debian 12
Il 13/10/23 12:27, Alessandro Baggi ha scritto: Il 24/09/23 11:35, Alessandro Baggi ha scritto: Il 24/09/23 11:29, Davide Prina ha scritto: Alessandro Baggi ha scritto: Viene riportata una lista con diversi chip ma non è presente il mio (NCT6798D) e non riesco a trovare info al riguardo. Non vorrei che l'unico modo per verificare che è supportato è collegare un sensore. secondo me, il sensore deve essere inserito per poter essere rilevato il chip. Lo credo anche io. Proverò e riporterò il risultato il lista. Però cercando in rete il tuo: https://github.com/lm-sensors/lm-sensors/issues/197 nota che il problema era su una vecchia versione di lm_sensors e quindi magari con l'attuale non serve neanche quel passaggio di parametro per farlo funzionare Di più non saprei cosa dirti... Ciao Davide Grazie mille per il tuo aiuto. Alessandro. Un saluto a tutti, sono tornato con la questione del sensore. Alla fine ne ho comprato uno e l'ho collegato, ho lanciato nuovamente sensors-detect ma non viene rilevato nulla. Cos'altro posso provare? Un saluto, Alessandro. Nota: il sensore è funzionante perche nel BIOS viene visto nella senzione monitor e riporta la temperatura correttamente.
Re: Comportamento anomalo Debian 12
Il 13/10/23 12:15, Cosmo ha scritto: In data venerdì 13 ottobre 2023 12:09:23 CEST, Alessandro Baggi ha scritto: È cambiato qualcosa in Debian che mi sono perso oppure è una situazione anomala? Esistono i log per rispondere a queste domande Ciao Cosmo, lanciando journalctl --since "3 hours ago" ho trovato queste informazioni: at-spi-bus-launcher[1787]: X connection to :0 broken (explicit kill or server shutdown). e: systemd[1]: lightdm.service: Scheduled restart job, restart counter is at 1. systemd[1]: Stopped lightdm.service - Light Display Manager. systemd[1]: lightdm.service: Consumed 1min 3.003s CPU time. systemd[1]: Starting lightdm.service - Light Display Manager... In mezzo a questi messaggi ci sono molti altri stop and start di altri servizi. Possibile abbia riavviato molti servizi dopo l'update e tra questi X e lightdm.
Re: [OT] Sensori di temperatura e Debian 12
Il 24/09/23 11:35, Alessandro Baggi ha scritto: Il 24/09/23 11:29, Davide Prina ha scritto: Alessandro Baggi ha scritto: Viene riportata una lista con diversi chip ma non è presente il mio (NCT6798D) e non riesco a trovare info al riguardo. Non vorrei che l'unico modo per verificare che è supportato è collegare un sensore. secondo me, il sensore deve essere inserito per poter essere rilevato il chip. Lo credo anche io. Proverò e riporterò il risultato il lista. Però cercando in rete il tuo: https://github.com/lm-sensors/lm-sensors/issues/197 nota che il problema era su una vecchia versione di lm_sensors e quindi magari con l'attuale non serve neanche quel passaggio di parametro per farlo funzionare Di più non saprei cosa dirti... Ciao Davide Grazie mille per il tuo aiuto. Alessandro. Un saluto a tutti, sono tornato con la questione del sensore. Alla fine ne ho comprato uno e l'ho collegato, ho lanciato nuovamente sensors-detect ma non viene rilevato nulla. Cos'altro posso provare? Un saluto, Alessandro.
Comportamento anomalo Debian 12
Un saluto a tutta la lista. Ho una Debian 12 con XFCE (dalla quale sto scrivendo) che aveva un pò di aggiornamenti da installare (146 pacchetti). Ho effettuato l'aggiornamento e nel mentre mi è arrivata una telefonata, finita la telefonata torno davanti allo schermo e mi ritrovo di nuovo la schermata di lightdm mi accorgo però che non è il login del salvaschermo ma la schermata di login come se il sistema fosse appena stato avviato. In sostanza tutta la sessione è stata chiusa. Il sistema non è stato riavviato in quanto l'uptime è di oltre 3 ore. Non mi era mai capitato che durante un aggiornamento tutta la sessione venisse distrutta. È cambiato qualcosa in Debian che mi sono perso oppure è una situazione anomala? Un saluto, Alessandro.
Re: [OT] Sensori di temperatura e Debian 12
Il 24/09/23 11:29, Davide Prina ha scritto: Alessandro Baggi ha scritto: Viene riportata una lista con diversi chip ma non è presente il mio (NCT6798D) e non riesco a trovare info al riguardo. Non vorrei che l'unico modo per verificare che è supportato è collegare un sensore. secondo me, il sensore deve essere inserito per poter essere rilevato il chip. Lo credo anche io. Proverò e riporterò il risultato il lista. Però cercando in rete il tuo: https://github.com/lm-sensors/lm-sensors/issues/197 nota che il problema era su una vecchia versione di lm_sensors e quindi magari con l'attuale non serve neanche quel passaggio di parametro per farlo funzionare Di più non saprei cosa dirti... Ciao Davide Grazie mille per il tuo aiuto. Alessandro.
Re: [OT] Sensori di temperatura e Debian 12
Il 24/09/23 10:44, Davide Prina ha scritto: puoi guardare sul sito del pacchetto lm-sensors https://hwmon.wiki.kernel.org e probabilmente su queste pagine: https://hwmon.wiki.kernel.org/projectinformation https://hwmon.wiki.kernel.org/device_support_status https://hwmon.wiki.kernel.org/faq poi non so se ci sono altri pacchetti per rilevare i dati dei sensori che non sono basati su questo Ciao Davide Ciao Davide, grazie per le risorse. Il problema è che non riesco a individuare il chip che il sensore usa. Lanciando sensors-detect mi viene trovato questo chip: "Nuvoton NCT6798D Super IO Sensors" Cercando in rete ho trovato questo: https://www.nuvoton.com/products/cloud-computing/i-o/super-i-o-series/ d dove viene riportato un diagramma nel quale viene riportato (Other SMBus temp sensors) SMBus/i2c. Viene riportata una lista con diversi chip ma non è presente il mio (NCT6798D) e non riesco a trovare info al riguardo. Non vorrei che l'unico modo per verificare che è supportato è collegare un sensore. Alessandro.
[OT] Sensori di temperatura e Debian 12
Un saluto a tutta la lista, chiedo scusa per l'OT. Ho una scheda madre Asus Prime Z490-A sulla quale è presente un sensore di temperatura con connettore a 2 pin per collegarci il sensore. Prima di procedere con l'acquisto del sensore volevo accertarmi che tale sensore venga riconosciuto su Linux (nel mio caso Debian 12). Come posso verificare se il sensore della scheda madre è riconosciuto dal kernel? Grazie in anticipo. Un saluto, Alessandro.
Re: [OT] Batteria portatile
Il 12/09/23 13:35, Alessandro Rubini ha scritto: Come voltaggio viene riportato 10.8 V mentre sulla batteria da 4400mAh 11.1 V. Puo` andar bene? Penso di si`, ma se te lo dessi per certo azzarderei conoscenza che non ho (sentiamo cosa dice anche Alessandro R.); Oops! Promosso a super esperto di batterie... Sul mio portatile non avrei alcuna paura a metterla. La tensione nominale e`, appunto, nominale. Un'etichetta con poco significato reale. La batteria ha una certa oscillazione di voltaggio, sia da carica a scarica sia in base alla corrente che sta entrando o uscendo. Le pile stilo o mini-stilo sono da 1.5V, ma le ricaricabili da 1.2V vanno bene quasi sempre. E se le misuriamo, le stilo normali nuove sono a 1.8 e da scariche (ma funzionanti) arrivano senza problemi a 1.0 o anche meno -- dipende dall'utilizzatore: la mia fotografica e` esigente e con le ricaricabili fa poche foto prima di lamentarsi. Il litio ha un'oscillazione minore, ma si parla sempre del 20% almeno (a memoria). Quindi 0.3V non e` una differenza significativa. Ovviamente il circuito di ricarica del portatile deve essere pronto a gestirla, ma se la vendono per compatibile sicuramente lo e`. Per male che vada, non verra` ricaricata proprio completamente (ma quasi). Se si tratta di recuperare un portatile va benissimo. Se si vuole una cosa al massimo delle prestazioni sicuramente non ci si arriva, ma come dicevo raramente si trova come ricambio lo stesso prodotto che era montato sull'originale, e ci si deve accontentare. Sicuramente non si rompe la macchina. Certo se fosse da 9V invece che 10.8, sarebbe sempre segnata come scarica (e potrebbe essere sovraccaricata, con riscaldamento e danni) e se fosse da 15V invece che 10.8 potremmo temere il portatile (e non verrebbe ricaricata). 0.3V non sono significativi. Il mio portatile, dopo 10 anni, ha bisogno della terza batteria, che sto aspettando. La seconda ha durato meno della prima. Ora sto usandone uno di recupero (piu` potente del mio ma con le sue stranezze), in attesa di sceglierne uno da comprare, che mi hanno dato per "batteria da cambiare" ma per i miei usi non ha problemi. Tiene molte ore in suspend-to-ram e quello basta, in particolare ora che tutti i treni hanno la presa su ogni posto. Grazie mille per le delucidazioni. Come al solito, questa lista è una risorsa grandiosa. Grazie Alessandro e a tutti gli altri. Un saluto.
Re: [OT] Batteria portatile
Il 12/09/23 12:38, Alessandro Rubini ha scritto: Sto cercando in rete ma trovo solo batterie a 4400mAh (dove viene riportato che è compatibile con il modello del portatile) mentre su quella originale viene riportato 5200mAh. Nessun problema. Se consumi 1A quella orignale finisce in 5.2 ore e questa in 4.4. Se la danno per compatibile siamo a posto. E` frequente chs le batterie orignali siano migliori dei ricambi. Mi sfugge il motivo, ma posso immaginarne 5 o 6 diversi, quindi si accetta la cosa senza troppa preoccupazione, Ciao Alessandro. Grazie per la risposta.
Re: [OT] Batteria portatile
Il 12/09/23 12:37, Giuliano Curti ha scritto: Il mar 12 set 2023, 12:13 Alessandro Baggi <mailto:alessandro.ba...@gmail.com>> ha scritto: Un saluto a tutta la lista, mi scuso per l'offtopic. Ho un portatile Asus N53SV e la battera è fritta da tempo. Per alcune necessità sorte in questi giorni mi ritrovo a dover rimpiazzare la batteria del portatile. Sto cercando in rete ma trovo solo batterie a 4400mAh (dove viene riportato che è compatibile con il modello del portatile) mentre su quella originale viene riportato 5200mAh. Nel caso dovessi acquistare quella da 4400 mAh, vado incontro a problemi? Credo di no, il dato fornito indica solo una capacità inferiore di fornire energia nel tempo, cioè una durata inferiore, ma se gli altri parametri (voltaggio e amperaggio) collimano non dovresti avere problemi Grazie in anticipo Aspetta qualche conferma più esperta, ciao, Giuliano Ciao Giuliano, grazie per la risposta. Purtroppo le scritte sulla batteria originale sono quasi cancellate. Come voltaggio viene riportato 10.8 V mentre sulla batteria da 4400mAh 11.1 V. Può andar bene?
[OT] Batteria portatile
Un saluto a tutta la lista, mi scuso per l'offtopic. Ho un portatile Asus N53SV e la battera è fritta da tempo. Per alcune necessità sorte in questi giorni mi ritrovo a dover rimpiazzare la batteria del portatile. Sto cercando in rete ma trovo solo batterie a 4400mAh (dove viene riportato che è compatibile con il modello del portatile) mentre su quella originale viene riportato 5200mAh. Nel caso dovessi acquistare quella da 4400 mAh, vado incontro a problemi? Grazie in anticipo
Re: Le querce fanno limoni ( o almeno di provano)
Il 13/08/23 18:00, Paride Desimone ha scritto: Il 13 agosto 2023 09:01:46 UTC, "fran...@modula.net" ha scritto: Apprendo oggi che Oracle sarebbe diventata paladina dell'open source con la Open Enterprise Linux Association. Luciano Oracle cerca soltanto manodopera gratuita! Finché non vedrò rilasciato lo zfs sotto gpl3, per me può anche schiattare. Questa mi sembra tanto una manovra per cercare di tirarsi fuori dai guai ora che redhat ha chiuso i rubinetti. /paride + 1
Re: Debian 12 e problemi con device md
Ciao Guido, Grazie per la risorsa. Alessandro. Il 27/06/23 11:03, Guido Bozzetto ha scritto: Il 27/06/23 09:59, Alessandro Baggi ha scritto: Un saluto a tutta la lista. Sto riscontrando problemi sul mio pc con Debian 12 relativo ai device MD (raid mdadm). In sostanza ad ogni riavvio il nome dei devices cambia. In realtà non è un problema bloccante perche il sistema usa gli UUID. Per esempio al primo avvio la root è su md125, i dati su md126 e la swap su md127. Al successivo boot (non dopo un reboot ma dopo uno shutdown) i nomi dei dispositivi cambiano e la root diventa md126, dati su md127 e swap su md125. Il tutto avviene arbitrariamente e solo dopo uno shutdown del sistema. ... Ho provato ad aggiornare l'initrd ma non cambia nulla. ... Provato con: |/etc/mdadm/mdadm.conf| Cfr.: https://debian-handbook.info/browse/it-IT/stable/advanced-administration.html#sect.raid-soft 12.1.1.3. Fare il backup della configurazione Guido. ||
[RISOLTO] Re: Debian 12 e problemi con device md
Ciao Paolo, all'interno di mdadm.conf ogni md device ha un relativo UUID assegnato, ma il problema si presenta lo stesso. Nel frattempo ho provato la soluzione N.1 ovvero quella di rinominare i device md con il seguente comando: # umount /dev/md125 # mdadm --stop /dev/md125 # mdadm --assemble /dev/md0 --update=name /dev/sdXN /dev/sdXN Mentre per il device di / ho usato la chiavetta di installazione di debian, lanciato lo stesso comando di assemble, montato in /mnt con i relativi /dev, /proc, /sys e ho aggiornato mdadm.conf e initrd. Ho fatto diverse prove e il problema sembra non manifestarsi. Lo terrò monitorato per qualche giorno nel caso in cui si rifarà vivo mi rifarò vivo anche io :D . (Grazie anche a Diego per la risposta precedente). Grazie ancora a tutti. Come al solito, la ml di debian-italian è una grandissima risorsa. Saluti, Alessandro. Il 27/06/23 10:24, Paolo Miotto ha scritto: Il 27/06/23 09:59, Alessandro Baggi ha scritto: Potrei: 1. salvare i dati e ricreare gli MD device ripartendo da 0 2. provare a cambiare nome dei device con un riasseble e poi aggiornare l'initrd. 3. Si accettano suggerimenti. Secondo voi quale è la migliore soluzione? 4. fissare i nomi in /etc/mdadm.conf ARRAY /dev/md2 UUID=...
Debian 12 e problemi con device md
Un saluto a tutta la lista. Sto riscontrando problemi sul mio pc con Debian 12 relativo ai device MD (raid mdadm). In sostanza ad ogni riavvio il nome dei devices cambia. In realtà non è un problema bloccante perche il sistema usa gli UUID. Per esempio al primo avvio la root è su md125, i dati su md126 e la swap su md127. Al successivo boot (non dopo un reboot ma dopo uno shutdown) i nomi dei dispositivi cambiano e la root diventa md126, dati su md127 e swap su md125. Il tutto avviene arbitrariamente e solo dopo uno shutdown del sistema. Ho uno script che monitora la capienza dei filesystem e dai log ho notato questa inversione dei nomi. Questo script mi invia un alert nel caso in cui l'fs abbia spazio occupato oltre l'80% e quando la capienza rientra nel limiti mi avvisa che il problema è stato "recuperato". Il problema è che l'alert viene emesso per md125 che in un determinato momento corrisponde a /mnt/dati ma il recovery (al successivo boot) fa riferimento ad md125 che è la / di sistema. Ho provato ad aggiornare l'initrd ma non cambia nulla. Il sistema è fresco di installazione e non è stato fatto un upgrade dalla 11. Sulla 11 questo problema non si presentava. Nota: i device raid sono stati creati tempo fa su una AlmaLinux 8. Potrei: 1. salvare i dati e ricreare gli MD device ripartendo da 0 2. provare a cambiare nome dei device con un riasseble e poi aggiornare l'initrd. 3. Si accettano suggerimenti. Secondo voi quale è la migliore soluzione? Grazie in anticipo. Alessandro.
Debian runs the world
Salve lista, spero di non essere off-topic. Mi sono imbattuto in un video di qualche giorno fa in cui Greg Kroah-Hartman dice esplicitamente che "take all Android stuff out of it everything else around me error, majority runs Debian and the world Cloud systems run Debian over 70 percent. It's insane what they mean, the world runs in Debian.." Qui il link al video: https://www.youtube.com/watch?v=gdLKCc6ABZk Quanto di veritiero c'è nelle sue parole? Nel "conteggio" (chissa come ha ottenuto questo 70%) saranno incluse anche le Ubuntu? Che ne pensate? Un saluto. Alessandro.
Re: Siamo fottuti (dal 1998) [Era: Re: secure boot e TPM 2.0]
Il 10/05/23 16:07, Filippo Dal Bosco - ha scritto: Il giorno Wed, 10 May 2023 11:28:34 +0200 Leandro Noferini ha scritto: Ora non è per fare polemica ma forse quando circolano previsioni più o meno catastrofiche potrebbe essere buona norma attaccare con un bel chiodo un cartello per ricordarselo :) di fronte a previsioni ( di qualsiasi tipo, esempio quelle del Club Roma) bisognerebbe leggere "Antifragile" di Nassim Nicholas Taleb per capire che sono impossibili. Un sistema ( qualsiasi) deve essere costruito in modo Antifragile ( flessibile), capace di agire in modo meno dannoso possibile di fronte a qualsiasi cambiamento anche il più catastrofico (= cigno Nero) E aggiungo, bellissimo libro. Ne consiglio la lettura.
Re: Annullare iscrizione
Salve, per disiscriverti dalla mailing list vai su: https://lists.debian.org/debian-italian/ inserisci il tuo indirizzo e clicca su "Unsubscribe" Il 19/04/23 17:48, Ro.Ma ha scritto: Nonostante ripetuti solleciti continuo a ricevere le vs. notifiche. Non voglio più riceverle, cortesemente annullate la mia iscrizione. Grazie Inviato da Proton Mail mobile
Re: Problemi di installazione Debian Testing (BookWork)
Il 21/02/23 14:42, Cosmo ha scritto: In data martedì 21 febbraio 2023 14:39:26 CET, Alessandro Baggi ha scritto: Qualcun'altro ha avuto simili problemi? https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1894160.html Grazie per la risorsa.
Problemi di installazione Debian Testing (BookWork)
Un saluto a tutta la lista, ho letto del soft freeze della testing e ho deciso di provarla. L'ho installata da PC dal quale ora sto scrivendo. L'installazione prevede la configurazione in RAID (mdadm) della swap, della root e della partizione EFI. L'installazione viene completata con successo ma al reboot ottengo un bel: /dev/md4 has unsupported feature(s): FEATURE_C12 e2fsck: get a newer version of e2fsck /dev/md4 * Warning: filesystem still has errors * fsck exited with status code 12 The root filesystem on /dev/md4 requires a manual fsck Lanciando un fsck di md4 riporta il messaggio riportato sopra. Allora ho lanciato un rescue dal media di installazione e prima di montare la root ho lanciato un fsck sul device md4 e mi dice che tutto è apposto. Riavvio convinto che l'FS è corretto ma il problema persiste. Allora riavvio dal media di installazione modificando fstab per non fargli fare il check ma riavviando il problema si ripresenta. Ho provato anche ad aggiornare l'initrd ma senza risultati positivi. Ora ho reinstallato la 11. Ho provato a replicare il problema su KVM creando una macchina virtuale con EUFI e i RAID e ottengo sempre lo stesso problema. Il messaggio che mi lascia perplesso è "e2fsck: get a newer version of e2fsck", significa che serve una versione nuova di e2fsck e che quindi quello del media di installazione (che funziona correttamente) è più recente di quello installato? Qualcun'altro ha avuto simili problemi? È ancora troppo presto per installare la 12? Non ho provato a fare l'upgrade da 11 a 12. Un saluto.
Re: Selinux
Il 01/02/23 15:56, Paride Desimone ha scritto: Il 01-02-2023 12:33 Paride Desimone ha scritto: Buongiorno. Sto provando a studiare Selinux, perché mi serve per un esame di certificazione rhcsa ex200. Qualcuno può dipanarmi un dubbio? Se io confino l'utente root, in modo che nemmeno lui abbia poteri illimitati, in modo che un'eventuale escalation, non consenta di prendere il controllo della macchina, come si fa in caso si voglia agire sulla configurazione di selinux e nemmeno lui può farlo? /paride Come non detto. Non ero arrivato alla gestione degli utenti con selinux. /paride Ciao Paride, è possibile confinare l'utente root? Io so che prima viene valutata la DAC. Se la DAC permette all'utente di eseguire una certa operazione SELinux non entra in gioco. Se la DAC non lo consente, Selinux controlla tutte le sue cose (contesti, booleans, [attento alle don't audit rules], ecc) (ed è qui che salva le chiappe) e in base alle policy crea un deny o un allow. Detto questo, essendo root utente con privilegi elevati, è possibile confinarlo? Inoltre non sarebbe il caso di evitare di far entrare root nel confinamento? Cioè ha senso confinare root? Almeno un utente privilegiato deve poter fare qualcosa se le cose non funzionano, anche perche se tu non permetti a root di effettuare qualcosa tipo operazioni di rete, accesso a determinati file ecc, si può sempre impostare selinux in permissive mode, e poi da quello che ho letto (non l'ho provato) sistemi come SELinux e AppArmor possono essere aggirati a livello del kernel, non chiedermi come che non lo so. SELinux non dovrebbe evitare proprio problemi di questo tipo come le escalation? (Lo chiedo perche ho il dubbio) Cmq se puo esserti di aiuto, che nessuno me ne voglia, l'ambiente migliore per studiare SELinux è una RHEL Based tipo AlmaLinux/RockyLinux. Purtroppo su debian ho sempre avuto problemi con SELinux. D'altro canto su debian uso apparmor che nella creazione delle policy è moltooo più semplice e diretto. Se posso darti un consiglio su SELinux, quando passi al processo della creazione delle policy custom, revisiona sempre quello che audit2allow aggiunge al file della policy (prima di compilarla e caricarla) perche potrebbe includere software/contesti/azioni che non vorresti permettere e questo è male perche crei una policy bacata non sapendolo. Altro consiglio è, nel caso in cui non riesci a trovare il deny ad una certa azione e quindi non puoi creare la regola nella policy, ti può tornare utile disabilitare le regole dont'audit che sono regole per cui è indicato di non riportate negli audit perche ce ne sarebbero troppe nel log. A me è capitato con un'applicazione che provava ad accedere a PostgreSQL ma l'applicazione nel contesto non aveva il permesso di lettura e scrittura nel comunicare in rete con postgresql. Ci ho messo qualche giorno per scoprire queste tipi di regole. Un saluto e scusate l'OT.
Re: migliore/peggiore ambiente desktop di sempre
Il 11/07/22 14:55, Giuseppe Naponiello ha scritto: Salve a tutti, mi riallaccio ad uno degli ultimi thread passati in lista in cui un utente dice di "odiare il paradigma di Gnome", poiché uso gnome da circa 10 anni mi farebbe piacere conoscere il vostro parere sugli altri ambienti e magari, alla fine, capire i pro e i contro di ognuno e, chissà, superare la mia pigrizia e testare l'ignoto! Mi sono reso conto di non aver mai provato altro per pigrizia, come scommetto la maggior parte di voi. In verità all'inizio avevo installato kde su consiglio dei miei colleghi ma l'ho trovato troppo "macchinoso" e pieno di abbellimenti fighi ma pesanti in termini di prestazioni, e l'ho subito abbandonato in favore di Gnome, che ho trovato più "leggero" anche graficamente. E' anche vero che molti software che mi farebbero comodo non sono fatti per gnome (i miei colleghi usano ancora kde e devo dire che, a naso, ci sono molti più pacchetti, soprattutto per l'editing audio/video) La mia ditta si occupa di archeologia e informatica (o archeologia informatica!!!) quindi, a parte scrivere tanto codice per applicazioni sia native che web, ci occupiamo di analisi spaziale (tanto GIS) modellazione 3d, e produzione di contenuti multimediali, quindi abbiamo bisogno di un'interfaccia. Facendo calcoli lunghi e pesanti (gis e rendering 3d) abbiamo anche bisogno di alleggerire il più possibile il carico del sistema, motivo per cui io ho scelto Gnome. Qual è la vostra esperienza e quali scelte avete fatto? Buona serata -beppe- Ciao Beppe, ho usato molti DE e WM nel corso degli anni. Ho usato fluxbox, blackbox , KDE3/4/5, GNOME 2/3/3.40, Cinnammon, XFCE, I3wm, CDE, MATE, Budgie e Deepin. Mate per pochissimo tempo e Budgie e Deepin erano relegati solo alla relativa distribuzione e li ho lasciati perdere. Il problema secondo me è che non esiste uno migliore o peggiore, dipende tutto dai gusti, dal tuo "workflow", dalle tue esigenze e ahime da quello che il tuo hardware di permette di usare (anche se devo dire che anche con le GPU integrate di intel si riesce a far girare GNOME e KDE (magari senza effetti). Praticamente è come chiedere quale distribuzione è migliore...non se ne viene mai a capo, quindi ti dico la mia. Allora... fluxbox e blackbox: realmente ridotti all'osso e molto minimali. Li usavo su un portatile con Pentium 4 Prescott con scheda video integrata. Leggerissimi. Ho usato CDE e JDE su Solaris 10 (che brutta esperienza :D). Sono passato per KDE3 ma preferivo ancora la minimalità di fluxbox. Poi è arrivato KDE4 che non mi è piaciuto affatto. Plasma 5 invece è una bella release, altamente personalizzabile ma a volte pieno di bug (a seconda della distro che usavo) ad un certo punto pero mi sono accorto che perdevo molto tempo nel personalizzare il DE con interruzioni a causa di crash di alcune applicazioni. Per di più ho notato che mi distraeva molto. Oggi con le ultime versioni lo si può alleggerire disabilitando gli effetti. Successivamente ho voluto provare GNOME (la versione 2 non mi ha mai attirato molto e l'ho usata solo perche la trovavo installata), non male come esperienza DE. Odio in particolar modo il pulsante delle attività con quel menu di tutte le applicazioni...non lo sopporto quindi lo disabilito subito. Non so se è solo una mia percezione ma quando uso GNOME ho la sensazione che il modo di come un DE debba essere usato sia imposto dagli sviluppatori (forse questo è a conferma della poca possibilità di personalizzazione). L'unico problema è che con gnome per avere qualcosa di utilizzabile sei costretto ad installare qualche estensione (che ogni tanto smettono di funzionare perche aggiornano qualcosa che non la fa più funzionare). Anche qui ogni tanto ho avuto rallentamenti su GNOME tipo applicazioni (di GNOME) che non si aprivano subito con GNOME che pensava a cosa fare (ricordi la clessidra di windows? tipo quello). Ho provato anche GNOME40 ma non mi ha entusiasmato molto. In tutto questo arco di tempo usavo XFCE saltuariamente fino ad un bel giorno in cui ho voluto usarlo definitivamente. Quello che preferisco e uso ad oggi è XFCE + lightdm per diversi motivi: 1. Leggerezza a livello di risorse. 2. Velocità nel fare tutto (mai un rallentamento). 3. STABILITA e SOLIDITA (fino ad ora non mi ha mai dato nessun problema di ogni sorta, mai un crash) 4. Personalizzabile al punto giusto (ne troppo poco come GNOME ma non esagerato come Plasma) Sono mesi ora che utilizzo XFCE4 insieme al plugin docklike (non disponibile su debian) e sto una meraviglia. L'unico pecca per il momento è la mancanza di un applicazione per configurare le stampanti anche se con il vecchio menu di CUPS il problema si risolve. Magari in futuro le mie esigenze cambieranno e userò altro. Un saluto. Alessandro.
Re: [OT] - Volume messaggi su debian-italian
Il 30/05/22 09:21, Luca Costantino ha scritto: Gli utenti sono calati un pochino, ma il traffico in effetti è proprio precipitato! :/ È un vero peccato, questa lista è una preziosissima risorsa con molti utenti competetenti. Agli albori della mia iscrizione era molto stimolante. Il giorno lun 30 mag 2022 alle ore 08:56 Alessandro Baggi mailto:alessandro.ba...@gmail.com>> ha scritto: Rieccomi, ho trovato questo https://lists.debian.org/stats/ <https://lists.debian.org/stats/> e questo https://lists.debian.org/stats/debian-italian.png <https://lists.debian.org/stats/debian-italian.png> Il 30/05/22 08:47, Alessandro Baggi ha scritto: > Ciao Luca, > Debian, come molte altre distribuzioni, e' diventata un po' > piu' facile >> da usare? >> L'utente medio riesce a trovare piu' info su Internet, senza scomodare >> la lista? >> I nuovi utenti non sono a conoscenza della lista? >> > > È possibile ma ho notato nel cerchio delle domande e risposte sono > sempre gli stessi utenti a postare. A me sembra più una perdita di utenti. > > É possibile vedere quanti utenti sono iscritti alla lista debian-italian > e magari qualche statistica della ML? > > > Alessandro.
Re: [OT] - Volume messaggi su debian-italian
Rieccomi, ho trovato questo https://lists.debian.org/stats/ e questo https://lists.debian.org/stats/debian-italian.png Il 30/05/22 08:47, Alessandro Baggi ha scritto: Ciao Luca, > Debian, come molte altre distribuzioni, e' diventata un po' piu' facile da usare? L'utente medio riesce a trovare piu' info su Internet, senza scomodare la lista? I nuovi utenti non sono a conoscenza della lista? È possibile ma ho notato nel cerchio delle domande e risposte sono sempre gli stessi utenti a postare. A me sembra più una perdita di utenti. É possibile vedere quanti utenti sono iscritti alla lista debian-italian e magari qualche statistica della ML? Alessandro.
Re: [OT] - Volume messaggi su debian-italian
Ciao Luca, > Debian, come molte altre distribuzioni, e' diventata un po' piu' facile da usare? L'utente medio riesce a trovare piu' info su Internet, senza scomodare la lista? I nuovi utenti non sono a conoscenza della lista? È possibile ma ho notato nel cerchio delle domande e risposte sono sempre gli stessi utenti a postare. A me sembra più una perdita di utenti. É possibile vedere quanti utenti sono iscritti alla lista debian-italian e magari qualche statistica della ML? Alessandro.
[OT] - Volume messaggi su debian-italian
Un saluto a tutta la lista, scusate per l'OT. Sono iscritto a questa lista dal 2009 e ho notato che il traffico è diminuito molto negli ultimi anni, mentre negli anni precedenti era abbastanza consistente. Nella mailing list debian-user invece il traffico è molto consistente. Quale è secondo voi la motivazione? 1. Gli utenti non usano più debian? 2. Esiste un altro network e la mailing list sta andando in disuso? 3. Gli utenti usano direttamente la lista debian-users? 4. Altro? Un saluto a tutti e grazie in anticipo per tutte le risposte. Alessandro.
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: installazione debian
Il 14/02/22 19:56, Diego Zuccato ha scritto: Il 14/02/22 18:31, Alessandro Baggi ha scritto: (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) 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"). Si vero!! ... indovina come lo so... :) Me lo hai consigliato tu? :D
Re: installazione debian
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) 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. (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) Per prima cosa, il sistema su cui installi supporta EUFI? beh, certo! Il pc è un Dell Poweredge T110 II. Bene 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". 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 debian
Il 14/02/22 11:29, Piviul ha scritto: Ciao a tutti, ho sempre qualche difficoltà durante l'installazione di debian con sistemi EFI. Se faccio fare il partizionamento al setup va tutto bene, non ho difficoltà ma se voglio farlo io mi blocco nella fase di installazione di grub... Nel caso specifico vorrei fare il setup su 2 dischi che precedentemente ho già partizionato: la prima partizione per EFI System, la seconda per /boot in raid1 e la terza per LVM. Nell'installer non ho difficoltà a creare il raid per la partizione di boot e creare i mie volumi logici per root, swap etc.. quello che non capisco è come fare a dire all'installer che la partizione EFI di uno dei dischi venga montata in /boot/efi e che venga usata come partizione ESP... Mi sfugge qualcosa? Grazie Piviul Ciao Piviul, da qualche giorno ho installato debian 11 sulla mia workstation con installazione su due dischi in raid1 software (mdadm) con il seguente partizionamento: sda1 = partizione EFI sdb1 = partizione EFI sda2 & sdb2 = raid da 4G sda3 & sdb3 = raid fino al 100% Per prima cosa, il sistema su cui installi supporta EUFI? Seconda cosa: durante l'installazione ti chiede di forzare l'installazione EFI? Su macchine eufi me lo chiede sempre. Puo essere che selezioni come boot device la USB "non UEFI" (ovvero quella per BIOS)? A me in passato è capitato per errore e grub non si installava. Ora non so se ho capito bene: ma stai provando a creare la partizione EFI su un device MD? 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? Un saluto.
Re: Come limitare temporalmente i log nel journal di systemd e avere journalctl più reattivo
On 30/10/21 10:48, Davide Prina wrote: mi sono accorto che non ho tantissimo spazio libero su / e indagando ho scoperto che il journal di systemd stava occupando diversi giga. Ho scoperto che al massimo, come impostazioni di default, dovrebbe occupare 4 GByte. Per vedere quanto spazio sta occupando attualmente: $ journalctl --disk-usage ho visto che i log partivano da diversi mesi fa e avevo già notato che la consultazione del journal era sempre più lenta. Visto che a me non interessa avere un journal che può andare indietro così tanto ho modificato il file /etc/systemd/journald.conf e ho tolto il commento alla variabile MaxRetentionSec impostandola a max 2 mesi: MaxRetentionSec=2month poi ho riavviato il journal per eliminare tutti i log oltre i due mesi: # systemctl restart systemd-journald.service ora se voglio vedere il log attuale $ journalctl -b 0 ho la risposta completa immediatamente :-) e ho liberato un po' di spazio (circa 2 GByte), non molto, ma è già qualcosa. Se qualcuno vuole indagare ulteriormente è possibile leggere il man $ man 5 journald.conf Ciao Davide Ciao Davide, grazie per la condivisione.
Re: Debian 11 e SELinux
Il 11/08/21 14:53, Alessandro Baggi ha scritto: Il 11/08/21 13:48, Alessandro Baggi ha scritto: Un saluto a tutta la lista. Ho installato su una macchina virtuale KVM Debian 11 (non ancora rilasciata) e ho attivato SELinux. Come riportato su https://wiki.debian.org/SELinux/Setup ho rimosso AppArmor e installato selinux-basics selinux-policy-default e auditd, ho lanciato selinux-activate e ho riavviato. Il sistema, giustamente, ha effettuato un relabel di tutto. Successivamente ho modificato la configurazione di SELinux da permissive a enforcing. Il problema è che non mi permette di loggarmi via ssh con utente normale dandomi come errore: /bin/bash: permission denied Ho usato SELinux su distro della famiglia RPM ma non sono esperto in quanto ho solo configurato dei contesti, qualche boolean e confinato qualche user e non riesco a capire come risolvere questo problema. Ho provato ad assegnare ad un utente il ruolo user_u con "usermod -Z user_u username" e riesco ad effettuare il login via ssh ma ho notato che lanciando "su -" non mi permette di leggere/scrivere file che sono soggetti ad altri contesti, come se l'utente root fosse confinato. Questa cosa non accade però se il login viene effettuato da console. Purtroppo la documentazione di Debian non mi è di alcun aiuto. In rete non sono riuscito a trovare granchè ma solo problemi relativi ad anni dimenticati Qualcuno ha qualche suggerimento? Grazie in anticipo. Dopo aver spulciato qualche boolean di SELinux ho abilitato ssh_sysadm_login (impostato a on) e permette agli utenti non confinati di effettuare il login su ssh. Non capisco perche se effettuo il login da utente confinato se lancio id -Z ho: user_u:user_r:user_t:s0 e dopo "su - root" mantiene lo stesso contesto dell'utente semplice e non unconfined. Può essere che la transazione da un contesto user_t non puo essere effettuata verso unconfined? Continuando la ricerca ho capito che: se si necessità di avere solo i servizi pubblicati su internet come confinati non ha senso usare il mapping degli user con gli user SELinux. Inoltre se viene abilitato il boolean ssh_sysadm_login, agli utenti non confinati è permesso il login, mentre ad un utente lo confiniamo con "user_u", è permesso il login ssh ma è confinato quindi nel caso in cui lanciasse un "su -" e ottenesse la root ha comunque il contesto dell'utente confinato e quindi non può fare nulla. Quello che non mi è chiaro è che se un utente lo mappo all'user SELinux staff_u (dalla doc di gentoo: SELinux user with direct system administrative role assigned), permette di fare il login ma non permette di lanciare comandi amministrativi ne da utente normale (credo sia normale) ne da utente root (con su -) perche il contesto rimane lo stesso di staff_u. A questo punto a che serve se non puo lanciare comandi amministrativi tipo apt?
Re: Debian 11 e SELinux
Il 11/08/21 13:48, Alessandro Baggi ha scritto: Un saluto a tutta la lista. Ho installato su una macchina virtuale KVM Debian 11 (non ancora rilasciata) e ho attivato SELinux. Come riportato su https://wiki.debian.org/SELinux/Setup ho rimosso AppArmor e installato selinux-basics selinux-policy-default e auditd, ho lanciato selinux-activate e ho riavviato. Il sistema, giustamente, ha effettuato un relabel di tutto. Successivamente ho modificato la configurazione di SELinux da permissive a enforcing. Il problema è che non mi permette di loggarmi via ssh con utente normale dandomi come errore: /bin/bash: permission denied Ho usato SELinux su distro della famiglia RPM ma non sono esperto in quanto ho solo configurato dei contesti, qualche boolean e confinato qualche user e non riesco a capire come risolvere questo problema. Ho provato ad assegnare ad un utente il ruolo user_u con "usermod -Z user_u username" e riesco ad effettuare il login via ssh ma ho notato che lanciando "su -" non mi permette di leggere/scrivere file che sono soggetti ad altri contesti, come se l'utente root fosse confinato. Questa cosa non accade però se il login viene effettuato da console. Purtroppo la documentazione di Debian non mi è di alcun aiuto. In rete non sono riuscito a trovare granchè ma solo problemi relativi ad anni dimenticati Qualcuno ha qualche suggerimento? Grazie in anticipo. Dopo aver spulciato qualche boolean di SELinux ho abilitato ssh_sysadm_login (impostato a on) e permette agli utenti non confinati di effettuare il login su ssh. Non capisco perche se effettuo il login da utente confinato se lancio id -Z ho: user_u:user_r:user_t:s0 e dopo "su - root" mantiene lo stesso contesto dell'utente semplice e non unconfined. Può essere che la transazione da un contesto user_t non puo essere effettuata verso unconfined?
Debian 11 e SELinux
Un saluto a tutta la lista. Ho installato su una macchina virtuale KVM Debian 11 (non ancora rilasciata) e ho attivato SELinux. Come riportato su https://wiki.debian.org/SELinux/Setup ho rimosso AppArmor e installato selinux-basics selinux-policy-default e auditd, ho lanciato selinux-activate e ho riavviato. Il sistema, giustamente, ha effettuato un relabel di tutto. Successivamente ho modificato la configurazione di SELinux da permissive a enforcing. Il problema è che non mi permette di loggarmi via ssh con utente normale dandomi come errore: /bin/bash: permission denied Ho usato SELinux su distro della famiglia RPM ma non sono esperto in quanto ho solo configurato dei contesti, qualche boolean e confinato qualche user e non riesco a capire come risolvere questo problema. Ho provato ad assegnare ad un utente il ruolo user_u con "usermod -Z user_u username" e riesco ad effettuare il login via ssh ma ho notato che lanciando "su -" non mi permette di leggere/scrivere file che sono soggetti ad altri contesti, come se l'utente root fosse confinato. Questa cosa non accade però se il login viene effettuato da console. Purtroppo la documentazione di Debian non mi è di alcun aiuto. In rete non sono riuscito a trovare granchè ma solo problemi relativi ad anni dimenticati Qualcuno ha qualche suggerimento? Grazie in anticipo.
Re: migrazione dati da mysql a postgress
Il 14/07/21 11:45, marco ha scritto: Buon giorno lista; qualcuno di voi ha mai fatto la migrazione dati da mysql a postgress? Se si come si deve fare? CIao Marco, la domanda non è strettamente relativa a Debian e spero non si generi un flame per questo OT. Comunque, non l'ho mai fatto ma procederei cosi (prendilo come spunto): 1. Creare il db, tabelle, relazioni con tutto quello che serve (tipi campi, chiavi, indici, procedure, ecc) 2. Con uno script in python (va bene anche php o linguaggio che conosci) leggerei il contenuto di tutte le tabelle rispettando l'ordine delle relazioni (magari tabella 1 dipende da tabella 2 quindi devi prima popolare tabella 2) e ripopolare le tabelle sul db postgres. In questo passaggio è importante mantenere la consistenza del db altrimenti potresti avere dei problemi con l'applicazione che deve leggere i dati. Per evitare problemi, se non conosci il db ti consiglio di analizzarlo attentamente. 3. Sicuramente ci sarà un'applicazione che usuifrerà di questi dati, quindi devi cambiare tutte le chiamate per recuperare/inserire le informazioni sul db. In base alla versione che usi, sul sito di PostgreSQL c'è un'esauriente documentazione. Sicuro utenti più esperti ti risponderanno a breve e in maniera più adeguata. Un saluto.
Re: presentazione
Il 17/12/20 10:41, Marco Ciampa ha scritto: Buongiorno lista, sono nuovo nuovo per cui perdonate se faccio errori clamorosi. Sono un traduttore (GIMP, Midnight Commander, KiCad ecc.). Benvenuto e granzie per il grandioso lavoro.
Re: considerazioni sulla virtualizzazione
Il 14/08/20 14:45, Marco Gaiarin ha scritto: NON è un ''filesystem condiviso'', NON è possibile montare lo stesso device iSCSI su due macchine diverse, ma in un cluster PVE ti permette di migrare le macchine da un nodo all'altro senza problemi, perchè il device iSCSI è visto da tutte. Ciao, corretto, non è possibile montare lo stesso iSCSI su più macchine se si usano filesystem canonici (ext4,xfs). È possibile farlo se si usa GFS2 o OCFS come fs. Un saluto.
Re: considerazioni sulla virtualizzazione
Il 08/08/20 15:49, Marco Gaiarin ha scritto: Se la tua idea è esportare due dischi in iSCSI e farci sul 'client iSCSI' il RAID-1, mi sa che stai a fare una ca%%ata...;-) +1
Re: Debian e downgrade di un pacchetto
Il 06/08/20 09:42, Alessandro Baggi ha scritto: Il 06/08/20 07:33, Paolo Redælli ha scritto: Il 05/08/20 21:45, Davide Prina ha scritto: On 04/08/20 11:18, Paolo Redælli wrote: Il 04/08/20 11:05, Alessandro Baggi ha scritto: Volevo sapere se su debian è possibile fare un downgrade di un determinato pacchetto con apt. apt-get --allow-downgrades install nomepacchetto/versione ma questo non dovrebbe funzionare perché i pacchetti di versioni precedenti dovrebbero essere tolti dal repository ufficiali e messi su snapshot.debian.net... a meno che mi sono perso qualcosa accaduto di recente. In effetti è come dici tu, perché la stragrande maggioranza delle persone ha elencato nelle fonti di apt una sola release tra stabile, testing, unstable eccetera Non avevo tenuto presente che non sono tanti a fare come me che ho stable, testing, unstable ed **experimantal** tra le fonti... Vedi https://monodes.com/predaelli/2020/02/23/debian-programmi-da-stable-testing-unstable-ed-anche-experimental-senza-traumi/ Scusate ma non ho capito se --allow-downgrades install nomepacchetto/versione funziona e come faccio a determinare quale versione posso installare. Rieccomi, per vedere quali versioni di un pacchetto sono disponibili, si può usare 'apt policy thunderbird".
Re: Debian e downgrade di un pacchetto
Il 06/08/20 07:33, Paolo Redælli ha scritto: Il 05/08/20 21:45, Davide Prina ha scritto: On 04/08/20 11:18, Paolo Redælli wrote: Il 04/08/20 11:05, Alessandro Baggi ha scritto: Volevo sapere se su debian è possibile fare un downgrade di un determinato pacchetto con apt. apt-get --allow-downgrades install nomepacchetto/versione ma questo non dovrebbe funzionare perché i pacchetti di versioni precedenti dovrebbero essere tolti dal repository ufficiali e messi su snapshot.debian.net... a meno che mi sono perso qualcosa accaduto di recente. In effetti è come dici tu, perché la stragrande maggioranza delle persone ha elencato nelle fonti di apt una sola release tra stabile, testing, unstable eccetera Non avevo tenuto presente che non sono tanti a fare come me che ho stable, testing, unstable ed **experimantal** tra le fonti... Vedi https://monodes.com/predaelli/2020/02/23/debian-programmi-da-stable-testing-unstable-ed-anche-experimental-senza-traumi/ Scusate ma non ho capito se --allow-downgrades install nomepacchetto/versione funziona e come faccio a determinare quale versione posso installare.
Re: Debian e downgrade di un pacchetto
Il 04/08/20 11:18, Paolo Redælli ha scritto: Il 04/08/20 11:05, Alessandro Baggi ha scritto: Salve ragazzi, leggendo le problematiche legate ai fix del BootHole su sistemi della famiglia RHEL, tra le soluzioni viene proposto il downgrade dei pacchetti interessati. Volevo sapere se su debian è possibile fare un downgrade di un determinato pacchetto con apt. Certo che si può. E non solo di un determinato pacchetto, per inciso. Anni fa son passato da experimental a testing (ma ci ha messo tipo 8-10 ore!). apt-get --allow-downgrades install nomepacchetto/versione oppure apt-get --allow-downgrades install nomepacchetto/release Ciao Paolo e grazie per la risposta. è possibile vedere quante e quali versioni sono disponibili per un determinato pacchetto in modo tale da poter fornire la version corretta?
Debian e downgrade di un pacchetto
Salve ragazzi, leggendo le problematiche legate ai fix del BootHole su sistemi della famiglia RHEL, tra le soluzioni viene proposto il downgrade dei pacchetti interessati. Volevo sapere se su debian è possibile fare un downgrade di un determinato pacchetto con apt. Grazie in anticipo. Un saluto.
Re: comparazione fra files
Il 03/08/20 17:43, Piviul ha scritto: Ciao a tutti, dati 2 o più files con migliaia di righe ordinate dovrei riuscire ad estrapolare le righe uguali. Non c'è altro modo dii farlo se non controllando riga per riga se è presente negli altri files? Non esiste un diff al contrario? Grazie Piviul Ciao Piviul, ti do uno spunto. Prova con: sort file1 file2 file3 | uniq -d Questo dovrebbe darti le rige uguali in tutti i file specificati. Un saluto.
Aggiornamento: Debian Buster (10.4) e GIMP
Il 12/06/20 23:18, Davide Prina ha scritto: On 12/06/20 09:01, Alessandro Baggi wrote: non uso Wayland ma Xorg. Wayland is intended as a simpler replacement for X, easier to develop and maintain. GNOME and KDE are expected to be ported to it. È vero che ci sono cose che non funzionano (es: bisogna imposare delle variabili di sistema alla chiamata dell'applicativo) o danno problemi con wayland, ma con il passare del tempo stanno sistemando. Ciao Davide Salve ragazzi, ricordate il problema di GIMP su debian 10.4 dove non funzionava il color picker? Il problema sembra risolversi quando utilizzo come motore di rendering XRender. Con OpelGL 3.1 e 2.0 mi da quel problema. Non ho molta conoscenza sui motori di rendering ma Xrender è valido?
Re: [OT] Backup dati
Il 10/07/20 15:54, Bertorello, Marco ha scritto: Il 09/07/2020 15:58, Alessandro Baggi ha scritto: Un saluto esteso a tutta la lista. Come da oggetto ho necessità di mettere su un server di backup [...] Avete dei consigli al riguardo? Non sto seguendo il thread, scusate, ma questo è stato rilasciato oggi in Beta, magari vi interessa: https://pbs.proxmox.com/wiki/index.php/Main_Page Ciao e grazie per la risposta. Grazie per aver condiviso, è molto interessante. +1
Re: [OT] Backup dati
Il 10/07/20 14:54, Giulio Turetta ha scritto: backuppc E' pacchettizzato per Debian, è solido e versatile. Unica pecca? Non cripta i backup ma se la criptazione della partizione che li contiene può essere sufficiente te lo consiglio. Se invece la criptazione è un must vai un occhio a duplicity Happy hack! G. Ciao Giulio, grazie per la risposta e per il suggerimento. Un saluto, Alessandro.
Re: [OT] Backup dati
Il 10/07/20 12:21, Mauro Morichi ha scritto: Il 10/07/2020 10:27, Alessandro Baggi ha scritto: mile al tuo, con checksum, quota, notifiche e comunicazioni. Come hai implementato il checksum nel tuo script? Io sto provando a trovare una soluzione utilizzando l'md5 di rsync che si può ottenere usando l'opzione --output-format="%C e altri format per altre info". Questo è ottimo perche cmq l'hash lo calcola direttamente rsync e si risparmia un po di tempo, quindi per ogni file scaricato inserisco il rispettivo md5 in un manifest unico per il client contenente tutti i checksum dei file scaricati precedentemente. Il problema è che usando gli hardlink e utilizzando il prune, mi ritrovo a dover aggiornare una lista molto lunga ogni volta che effettuo un prune e questo richiede molto tempo. Al momento mi sono affidato a ZFS ma se non ho capito male il controllo di zfs consiste nel controllare se la copia live è cambiata rispetto a quella della parità senza che il file sia stato modificato nella copia live (anche perche se il file viene modificato nella copia live viene comunque aggiornato anche nel parity) (se sbaglio correggetemi). anche se piu' lentamente utilizzo il tool esterno. Ogni volta genero un file con l'elenco di tutti gli md5 piu' altre info utili come spazio occupato, spazio disponibile, numero di backup presenti un po' di info leggibili, insomma. Anche io ho provato con un tool esterno (sha512/256sum) ma quando sono molti file (tipo il primo backup o un aggiornamento di qualche giga) ci mette un po. Per esempio il primo backup scarica circa 60 file e il processo per calcolare il checksum di ogni file richiede un bel po di tempo mentre invece utilizzando il checksum (md5 al momento) di rsync si perde solo il tempo di sincronizzazione dei file.
Re: [OT] Backup dati
Il 09/07/20 21:48, Mauro ha scritto: Il 09/07/2020 15:58, Alessandro Baggi ha scritto: Un saluto esteso a tutta la lista. ricambio con piacere. Per un ambiente lavorativo stavo pensado a qualcosa di più professionale che supporti la compressione, deduplicazione (non che sia necessaria al momento), cifratura dei backup e controllo di integrità dei backup. Facendo un ricerca in rete ho trovato: 1) rsnapshot: non più mantenuto in quanto lo sviluppatore principale è passato a borgbackup. 2) dirvish: non più mantenuto dal 2014. 3) bacula: letteralmente un mostro (che ho usato in passato) 4) bareos: è il fork di bacula quindi come sopra 5) amanda: non so 6) borgbackup: tool veramente interessante ma supporta solo il push nativamente quindi dovrei usarlo con rsync + borg in locale. Anche in questo caso uno script bash è necessario per mantenere più client. 7) restic: simile a borgbackup e altri. Avete dei consigli al riguardo? Ciao Mauro e grazie per la risposta La mia situazione che e' un mix di robe di lavoro e personali alla fine mi hanno portato a usare due tools (tralascio quelli per gli ambienti misti winz): il primo, uno script che ogni giorno cresce un po' che si basa su rsync, simile al tuo, con checksum, quota, notifiche e comunicazioni. Come hai implementato il checksum nel tuo script? Io sto provando a trovare una soluzione utilizzando l'md5 di rsync che si può ottenere usando l'opzione --output-format="%C e altri format per altre info". Questo è ottimo perche cmq l'hash lo calcola direttamente rsync e si risparmia un po di tempo, quindi per ogni file scaricato inserisco il rispettivo md5 in un manifest unico per il client contenente tutti i checksum dei file scaricati precedentemente. Il problema è che usando gli hardlink e utilizzando il prune, mi ritrovo a dover aggiornare una lista molto lunga ogni volta che effettuo un prune e questo richiede molto tempo. Al momento mi sono affidato a ZFS ma se non ho capito male il controllo di zfs consiste nel controllare se la copia live è cambiata rispetto a quella della parità senza che il file sia stato modificato nella copia live (anche perche se il file viene modificato nella copia live viene comunque aggiornato anche nel parity) (se sbaglio correggetemi). il secondo un bacula che sta diventando in questi giorni un bareos. Quest'ultima soluzioni l'avevo scelta qualche anno fa perche' dovevo lavorare in ambienti misti (linux,bsd e windows) e mi sembrava una valida alternativa da mettere in mano con apposita interfaccia a utenti meno smaliziati a cui, al massimo, dovevo far premere un tasto soltanto. Effettivamente Bareos/Bacula sono di una complessita' che rasenta la follia. Per carita' stabili, ma laddove ho thera e thera di file piccoli (documenti office) andare a cercare qualcosa sta diventando una tortura. Concordo. Bacula è una cosa allucinante, l'ho usato in passato con successo ma è troppo complesso e macchinoso (magari in altre realtà è la salvezza ed è necessario che sia cosi). Prima cosa è un pò confusionario il modo in cui i client vengono configurati, cioè si parte da un file di configurazione che contiene le direttive ma poi una parte delle info viene memorizzata sul database (la parte riguardante ai pool, volumi, job, file e host). Non c'è niente di male in questo ma se provi cambiare le config dei pool, volumi ecc devi cmq aggiornarle sul DB con la bconsole, se elimini un client dalla configurazione poi devi andare ad eliminare il client dal DB, idem se fai modifiche ai pool/volumi, idem se cancelli un volume o un job (esiste un tool per fare questo, o meglio un tool che si occupa di eliminare i record orfani ma non ha mai funzionato per me..sarò io). Poi ci sta il mantenimento del DB che potrebbe diventare gigante e quindi le query per vedere quale file è memorizzato in quale volume richiedo un tempo maggiore e poi ti ritrovi a fare un backup del db (di bacula) molto grande (ci sono diverse direttive per questo ma si può sempre omettere qualcosa o sbagliare il retention period). Oltre a questo non mi piace come gestisce i volumi sui backup con storage su disco e non su TAPE (su TAPE penso che sia formidabile questo approccio) ma su disco è più un problema che una soluzione. Per esempio, mi capitava che un job fallisse per un motivo ma il volume era già stato allocato e marcato come usato. Avendo il maximum volume jobs = 1, Maximum Volumes = N e le retention policy praticamente distruggeva il ciclo di backup del client perche ti trovavi con un volume in meno (praticamente non usato) ma che cmq ti sballava il ciclo. E vai a manina a cambiare il numero di pool per fargli fare il backup e poi eliminare quello vecchio. Forse lo usavo male io, ma per backup su disco non è il massimo. Poi per carità ha delle funzioni spettacolari come il migration su un secondo storage come replica, backup virtuali ecc...forniscono supporto a chi ne ha bisogno ma il gioco non vale la ca
[OT] Backup dati
Un saluto esteso a tutta la lista. Come da oggetto ho necessità di mettere su un server di backup per effettuare il backup di un NAS (debian) con ~1TiB, qualche VPS (potrebbero aumentare di numero) e una workstation. Sono tutti dati, quindi niente immagini di VM o container. Al momento ho in mano uno script (bash) da me scritto anni fa che utilizza rsync per il backup di molteplici host tramite SSH. Utilizza gli hardlink con l'opzione --link-dest e per ogni backup crea uno snapshot a se stante. Inoltre ho la possibilità di poter lanciare degli script di pre/post job (sempre script in bash) sui target remoti per operazioni (ES: lvm snapshot, backup di db, start/stop di servizi...), ha il mailing, ha il pruning dei vecchi job, ha un'impostazione per il QUOTA e il relativo controllo, crea un catalogo dei file con alcune informazioni (su file) per ogni snapshot, permette il restore dei backup sempre con rsync in un determinato path sul target. Niente di complesso ma funziona. A casa lo uso con ZFS dove è abilitata la compressione e dove ogni tanto lancio uno scrub per verificare se ci sono degli errori. La cosa che mi piace è che i file sono memorizzati nella stessa modalità in cui sono scaricati, quindi accessibili con qualsiasi tool disponibile sulla distro a non dipendono da uno specifico software di backup ma solo dal filesystem. Ha alcuni svantaggi come il limite degli hardlink, il gran numero di file salvati singolarmente e non in un archivio per backup il che potrebbe creare problemi con fsck. Oltre a queste non supporta la compressione, la cifratura e il controllo di integrità nativamente ma al momento posso ovviare al problema grazie a ZFS e comunque essendo uno script in bash preferirei gestire queste funzionalità in maniera più appropriata. Per un ambiente lavorativo stavo pensado a qualcosa di più professionale che supporti la compressione, deduplicazione (non che sia necessaria al momento), cifratura dei backup e controllo di integrità dei backup. Facendo un ricerca in rete ho trovato: 1) rsnapshot: non più mantenuto in quanto lo sviluppatore principale è passato a borgbackup. 2) dirvish: non più mantenuto dal 2014. 3) bacula: letteralmente un mostro (che ho usato in passato) 4) bareos: è il fork di bacula quindi come sopra 5) amanda: non so 6) borgbackup: tool veramente interessante ma supporta solo il push nativamente quindi dovrei usarlo con rsync + borg in locale. Anche in questo caso uno script bash è necessario per mantenere più client. 7) restic: simile a borgbackup e altri. Avete dei consigli al riguardo? Scusate la lunghezza e grazie. Alessandro.
[RISOLTO] Re: Ho fatto un casino con i DE (fork(Debian Buster (10.4) e GIMP)
Il 15/06/20 18:56, Alessandro Baggi ha scritto: Il 15/06/20 17:57, Davide Prina ha scritto: On 15/06/20 08:55, Alessandro Baggi wrote: Esiste un modo sicuro per eliminare GNOME ed XFCE senza distruggere l'installazione? guardi cosa ha effettivamente installato e rimuovi qui pacchetti: /var/log/apt/history.log Io ho rimosso gnome su un eeepc dove avevo messo xfce e non ho avuto problemi. Ciao Davide Grazie mille proverò. Un saluto. Ciao Davide, ho effettuato l'eliminazione dei pacchetti riportati nel log di apt. Tutto è andato per il meglio. Grazie ancora. Un saluto.
[RISOLTO] Re: Debian Buster (10.4) e GIMP
Il 12/06/20 23:18, Davide Prina ha scritto: On 12/06/20 09:01, Alessandro Baggi wrote: non uso Wayland ma Xorg. Wayland is intended as a simpler replacement for X, easier to develop and maintain. GNOME and KDE are expected to be ported to it. È vero che ci sono cose che non funzionano (es: bisogna imposare delle variabili di sistema alla chiamata dell'applicativo) o danno problemi con wayland, ma con il passare del tempo stanno sistemando. Ciao Davide Salve Ragazzi, inaspettatamente il problema non si presenta più. Qualche giorno fa ho lanciato un upgrade senza notare cosa venisse aggiornato. Il log di apt riporta questo: Start-Date: 2020-06-12 09:03:30 Commandline: apt-get upgrade Upgrade: linux-image-4.19.0-9-amd64:amd64 (4.19.118-2, 4.19.118-2+deb10u1), linux-libc-dev:amd64 (4.19.118-2, 4.19.118-2+deb10u1), libgnutls-openssl27:amd64 (3.6.7-4+deb10u3, 3.6.7-4+deb10u4), nodejs:amd64 (10.19.0~dfsg1-1, 10.21.0~dfsg-1~deb10u1), linux-compiler-gcc-8-x86:amd64 (4.19.118-2, 4.19.118-2+deb10u1), linux-headers-4.19.0-9-common:amd64 (4.19.118-2, 4.19.118-2+deb10u1), thunderbird-l10n-it:amd64 (1:68.8.0-1~deb10u1, 1:68.9.0-1~deb10u1), linux-headers-4.19.0-9-amd64:amd64 (4.19.118-2, 4.19.118-2+deb10u1), lightning:amd64 (1:68.8.0-1~deb10u1, 1:68.9.0-1~deb10u1), thunderbird:amd64 (1:68.8.0-1~deb10u1, 1:68.9.0-1~deb10u1), nodejs-doc:amd64 (10.19.0~dfsg1-1, 10.21.0~dfsg-1~deb10u1), libgnutls30:amd64 (3.6.7-4+deb10u3, 3.6.7-4+deb10u4), libnode64:amd64 (10.19.0~dfsg1-1, 10.21.0~dfsg-1~deb10u1), ca-certificates:amd64 (20190110, 20200601~deb10u1), linux-kbuild-4.19:amd64 (4.19.118-2, 4.19.118-2+deb10u1), libgnutls-dane0:amd64 (3.6.7-4+deb10u3, 3.6.7-4+deb10u4) End-Date: 2020-06-12 09:03:54 ma non so da cosa possa essere dipeso. Grazie a tutti per il supporto.
Re: Ho fatto un casino con i DE (fork(Debian Buster (10.4) e GIMP)
Il 15/06/20 17:57, Davide Prina ha scritto: On 15/06/20 08:55, Alessandro Baggi wrote: Esiste un modo sicuro per eliminare GNOME ed XFCE senza distruggere l'installazione? guardi cosa ha effettivamente installato e rimuovi qui pacchetti: /var/log/apt/history.log Io ho rimosso gnome su un eeepc dove avevo messo xfce e non ho avuto problemi. Ciao Davide Grazie mille proverò. Un saluto.
Re: leggere dati smart in dischi SAS
Il 15/06/20 08:32, Piviul ha scritto: Il 13/06/20 21:46, Marco Taschin ha scritto: Ciao, prova con questi tools: https://downloads.linux.hpe.com/SDR/project/mcp/ sai che non sono riuscito a trovare un tool in grado di leggere i dati smart dell'hd? E smartctl quindi non è supportato? Piviul Ciao Piviul, Leggi qui: https://www.smartmontools.org/wiki/FAQ#MySCSISASdriveisnotinthesmartctlsmartddataba
Ho fatto un casino con i DE (fork(Debian Buster (10.4) e GIMP)
Buongiorno lista, non so se avete letto la mia problematica con GIMP, ma per verificare se dipendesse dai driver nvidia o dal DE, ho installato (oltre a Plasma) anche GNOME e XFCE. Alla fine il problema si presenta su Plasma ma al momento non so ancora da cosa dipenda. Ora il problema è che mi ritrovo con 3 DE. Da mie vecchie esperienze, la disinstallazione di xfce non dovrebbe creare problemi ma la rimozione completa di GNOME mi ha sempre rovinato l'installazione. Esiste un modo sicuro per eliminare GNOME ed XFCE senza distruggere l'installazione? Un saluto e grazie in anticipo.
Re: zfs pool degraded
Ciao Piviul, sembra il caso di cambiarlo, magari qualcuno con più esperienza potrebbe confermare la diagnosi. Il 12/06/20 14:44, Piviul ha scritto: Ciao Alessandro... Alessandro Baggi ha scritto il 12/06/20 alle 11:09: [...] I valori THRESH dello smart del disco riportano qualcosa di strano? Non riesco a leggerli né da iLO4 né da smartctl, non so infatti dove trovare le informazioni da inserire nell'opzione --device di smartctl :( I log di sistema hanno riportato qualcosa al riguardo del disco come errore I/O ecc (anche dmesg al momento dell'errore)? No, non ci ho guardato ma l'ho fatto ora; ecco cosa riportano: Jun 11 08:23:34 pve02 kernel: [63208.585107] sd 2:0:2:0: [sdc] tag#128 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Jun 11 08:23:34 pve02 kernel: [63208.585126] sd 2:0:2:0: [sdc] tag#128 Sense Key : Illegal Request [current] Jun 11 08:23:34 pve02 kernel: [63208.585132] sd 2:0:2:0: [sdc] tag#128 Add. Sense: Logical block address out of range Jun 11 08:23:34 pve02 kernel: [63208.585139] sd 2:0:2:0: [sdc] tag#128 CDB: Write(10) 2a 00 b7 e8 13 10 00 05 28 00 Jun 11 08:23:34 pve02 kernel: [63208.585146] blk_update_request: critical target error, dev sdc, sector 3085439760 op 0x1:(WRITE) flags 0x700 phys_seg 12 prio class 0 Jun 11 08:23:34 pve02 kernel: [63208.585252] zio pool=zfspool vdev=/dev/sdc1 error=121 type=2 offset=1579744108544 size=675840 flags=40080c80 Jun 11 08:23:48 pve02 kernel: [63223.328731] sd 2:0:2:0: [sdc] tag#162 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Jun 11 08:23:48 pve02 kernel: [63223.328751] sd 2:0:2:0: [sdc] tag#162 Sense Key : Illegal Request [current] Jun 11 08:23:48 pve02 kernel: [63223.328757] sd 2:0:2:0: [sdc] tag#162 Add. Sense: Logical block address out of range Jun 11 08:23:48 pve02 kernel: [63223.328764] sd 2:0:2:0: [sdc] tag#162 CDB: Write(10) 2a 00 c3 39 fa 18 00 02 60 00 Jun 11 08:23:48 pve02 kernel: [63223.328771] blk_update_request: critical target error, dev sdc, sector 3275356696 op 0x1:(WRITE) flags 0x700 phys_seg 6 prio class 0 Jun 11 08:23:48 pve02 kernel: [63223.328878] zio pool=zfspool vdev=/dev/sdc1 error=121 type=2 offset=1676981579776 size=311296 flags=40080c80 Jun 11 08:24:28 pve02 kernel: [63263.323315] sd 2:0:2:0: [sdc] tag#141 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Jun 11 08:24:28 pve02 kernel: [63263.323334] sd 2:0:2:0: [sdc] tag#141 Sense Key : Medium Error [current] Jun 11 08:24:28 pve02 kernel: [63263.323340] sd 2:0:2:0: [sdc] tag#141 Add. Sense: Unrecovered read error Jun 11 08:24:28 pve02 kernel: [63263.323347] sd 2:0:2:0: [sdc] tag#141 CDB: Read(10) 28 00 00 00 00 00 00 01 00 00 Jun 11 08:24:28 pve02 kernel: [63263.323353] blk_update_request: critical medium error, dev sdc, sector 0 op 0x0:(READ) flags 0x0 phys_seg 32 prio class 0 Jun 11 08:25:37 pve02 kernel: [63331.416500] sd 2:0:2:0: [sdc] tag#143 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Jun 11 08:25:37 pve02 kernel: [63331.416507] sd 2:0:2:0: [sdc] tag#143 Sense Key : Medium Error [current] Jun 11 08:25:37 pve02 kernel: [63331.416510] sd 2:0:2:0: [sdc] tag#143 Add. Sense: Unrecovered read error Jun 11 08:25:37 pve02 kernel: [63331.416516] sd 2:0:2:0: [sdc] tag#143 CDB: Read(10) 28 00 00 00 00 00 00 01 00 00 Jun 11 08:25:37 pve02 kernel: [63331.416522] blk_update_request: critical medium error, dev sdc, sector 0 op 0x0:(READ) flags 0x0 phys_seg 32 prio class 0 Jun 11 11:44:58 pve02 kernel: [75292.560537] sd 2:0:2:0: [sdc] Unaligned partial completion (resid=4056, sector_sz=512) Jun 11 11:44:58 pve02 kernel: [75292.560549] sd 2:0:2:0: [sdc] tag#769 CDB: Read(10) 28 00 00 00 00 00 00 01 00 00 Jun 11 11:44:58 pve02 kernel: [75292.560558] sd 2:0:2:0: [sdc] tag#769 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK Jun 11 11:44:58 pve02 kernel: [75292.560562] sd 2:0:2:0: [sdc] tag#769 CDB: Read(10) 28 00 00 00 00 00 00 01 00 00 Jun 11 11:44:58 pve02 kernel: [75292.560567] blk_update_request: I/O error, dev sdc, sector 0 op 0x0:(READ) flags 0x0 phys_seg 32 prio class 0 Jun 11 11:44:58 pve02 kernel: [75292.560694] sd 2:0:2:0: [sdc] tag#770 FAILED Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK Jun 11 11:44:58 pve02 kernel: [75292.560697] sd 2:0:2:0: [sdc] tag#770 CDB: Read(10) 28 00 00 00 08 00 00 01 00 00 Jun 11 11:44:58 pve02 kernel: [75292.560700] blk_update_request: I/O error, dev sdc, sector 2048 op 0x0:(READ) flags 0x0 phys_seg 32 prio class 0 Jun 11 11:44:58 pve02 kernel: [75292.688448] sd 2:0:2:0: [sdc] tag#799 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_SENSE Jun 11 11:44:58 pve02 kernel: [75292.688456] sd 2:0:2:0: [sdc] tag#799 Sense Key : Illegal Request [current] Jun 11 11:44:58 pve02 kernel: [75292.688460] sd 2:0:2:0: [sdc] tag#799 Add. Sense: Logical unit not supported Jun 11 11:44:58 pve02 kernel: [75292.688466] sd 2:0:2:0: [sdc] tag#799 CDB: Read(10) 28 00 00 00 00 00 00 01 00 00 Jun 11 11:44:58 pve02 kernel: [75292.688471] blk_update_request: I/O
Re: zfs pool degraded
Ciao Piviul, non so se iLO riporta questo tipo di errori. Cercando in rete ho trovato (http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c03580889-1.pdf) che iLO4 riporta tra le tante cose un Disk Failure. I valori THRESH dello smart del disco riportano qualcosa di strano? I log di sistema hanno riportato qualcosa al riguardo del disco come errore I/O ecc (anche dmesg al momento dell'errore)? Se non trovi nessun problema (ed è strano) proverei a riaggiungere il disco al pool di zfs e vedere se riaccade. Se riaccade sta a te valutare in base al ruolo del server e all'importanza dei dati che ha memorizzati se è il caso di acquistare un nuovo disco. Potresti fare un'altra prova ma è rischiosa, non l'ho mai fatto e non so se è possibile. Se dico qualche ca___ta perdonatemi. Se il tuo pool supporta un duplice guasto (raizd2) o se hai dischi spare (anche non collegati) perche non invertire due dischi? Potrebbe essere il bay ad avere il problema (so che è remota come possibilità). Se fallisce sempre lo stesso disco sai che è quel disco altrimenti se fallisce il disco nel bay "incriminato" sai che il problema dipende dal bay. Se hai il raidz2 puoi scollegare due device insieme altrimenti sei obbligato a scollegare il disco corrotto, fare un replace con un disco nuovo e aspettare il resilvering. Se tutto va bene scolleghi un disco del pool e inserisci quello che ti da problemi e aspetti il manifestarsi del problema. Anche in questo caso, dipende dal ruolo di questo specifico server. Può essere spento e avere un downtime per il resilvering? Non smetterò mai di consigliarlo: backup, backup e backup. Nota: mi è capitato in passato, quando ero un novizio ed ero affiancato da "un esperto", che su alcuni server HP in raid5 (hardware non ricordo il controller) ogni tanto un disco veniva marcato come faulted e il tutto si risistemava scollegando il disco e ricollegandolo (a fronte però della ricostruzione). Un saluto. Aggiungo che il server è un proliant hp e iLO4 dice che lo stato di salute del server è ottimo, non vengono rilevati problemi. Se un HD dovesse avere problemi il server proliant non dovrebbe accorgesene? Grazie Piviul Il 11/06/20 13:04, Piviul ha scritto: Ciao a tutti, zfs si è arrabbiato e mi ha fatto uscire un HD dal raid. Ora io essendoci ancora cose non essenziali sul server ho dato un zpool clear sul server ma mi piacerebbe testare l'hd; con uno smartctl -a /dev/sd? mi dice : smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.41-1-pve] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org /dev/sd?: requires option '-d cciss,N' Please specify device type with the -d option. Use smartctl -h to get a usage summary se gli aggiungo un -d scsi mi restituisce: smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.41-1-pve] (local build) Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org User Capacity: 2,000,398,934,016 bytes [2.00 TB] Logical block size: 512 bytes Rotation Rate: 7202 rpm Form Factor: 3.5 inches Logical Unit id: 0x5000c5004e1c339a Serial number: Z1P3KYTT Device type: disk Local Time is: Thu Jun 11 13:03:46 2020 CEST SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Disabled or Not Supported === START OF READ SMART DATA SECTION === SMART Health Status: OK Current Drive Temperature: 32 C Drive Trip Temperature: 0 C Error Counter logging not supported Device does not support Self Test logging Voi cosa fareste? Piviul
Re: Debian Buster (10.4) e GIMP
Il 11/06/20 21:29, Davide Prina ha scritto: On 11/06/20 10:29, Alessandro Baggi wrote: Ho installato xfce4 e rilanciato la sessione utente con XFCE e GIMP funziona come di dovere. Sembra che il problema derivi da KDE. Come potrei identificare cosa causa la problematica su KDE Plasma? secondo me il problema è in una libreria specifica di KDE $ dpkg -l | grep wayland penso che siano qt quelle che potrebbero darti problemi Io guarderei se per qualcuna di quelle di KDE c'è aperto qualche bug su wayland. Una strada che potrebbe essere più complessa è quella di fare il debug di gimp con gdb e cercare di capire cosa stampa i messaggi di errore https://wiki.debian.org/HowToGetABacktrace Ciao Davide Ciao Davide, non uso Wayland ma Xorg. root 1128 0.1 0.3 193472 50680 tty1 Sl+ 08:51 0:00 /usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/122/gdm/Xauthority -background none -noreset -keeptty -verbose 3 Proverò con il debug di gimp. Grazie
Re: Debian Buster (10.4) e GIMP
Il 10/06/20 21:49, Davide Prina ha scritto: On 03/06/20 16:28, Alessandro Baggi wrote: ho riscontrato un problema con GIMP su Debian 10 con il color picker del selezionatore di colore di primo piano nel pannello degli strumenti o da Menu->Finestre->Pannelli Agganciabili->Colori. In sostanza qualsiasi colore io selezioni mi da sempre nero su testing funziona correttamente. Di solito problemi di questo tipo sono causati da un supporto per wayland non corretto. infatti qui è segnalato il problema che hai indicato tu (però marcato come risolto): https://bugs.launchpad.net/ubuntu/+source/gimp/+bug/1705188 però penso che dovrebbe essere risolto sulla versione che hai... Qui è riportato l'errore https://www.kubuntuforums.net/showthread.php/76021-Gimp-2-10-8-color-picker-issue e indicato che se lo fai partire da un terminale Gnome funziona, mentre se parte da Konsole non funziona... Ciao Davide Ciao Davide. grazie per la tua risposta. La tue indicazione sull'uso di un altro DE è stata utile. Ho installato xfce4 e rilanciato la sessione utente con XFCE e GIMP funziona come di dovere. Sembra che il problema derivi da KDE. Come potrei identificare cosa causa la problematica su KDE Plasma? Grazie in anticipo.
Re: Debian Buster (10.4) e GIMP
Il 07/06/20 15:03, liste DOT girarsi AT posteo DOT eu ha scritto: Il 05/06/20 09:48, Alessandro Baggi ha scritto: Ciao, io sapevo che KDE, GNOME ecc sono DE mentre Xorg o Wayland sono i server grafici. Comunque i driver sono installati dal repo di debian (non-free). Backports disabilitati. Il fatto è che il problema è riscontrato solo con GIMP mentre con kcolorchooser funziona a dovere. Un saluto. Scusa, hai ragione, faccio spesso confusione, comunque, io sono su una testing/sid, e la mia versione è più recente, ho la 2.10.18-1, però il tuo problema non lo riscontro ho desktop KDE e pure i driver proprietari (presenti nei repository non-free). Quindi probabile sia un bug di gimp. Hai già provato, per esempio a fare un riempimento di un cerchio, per vedere se mantiene l'assenza di colore? Dubito un problema ai driver nvidia, perchè succede solo lì. Guardando il changelog [0], ci sono diversi fix sui colori nelle varie versioni precedenti, forse questo ha influito, però è solo un'idea senza supporto tecnico a disposizione, per mio limite. Poi ho trovato questi [1] [2], vedi se ti son di aiuto, anche se non ne ho idea e le risposte sono simili. [0] https://metadata.ftp-master.debian.org/changelogs//main/g/gimp/gimp_2.10.8-2_changelog [1] https://graphicdesign.stackexchange.com/questions/85548/cant-use-any-colors-other-than-black-in-gimp-image [2] https://graphicdesign.stackexchange.com/questions/100160/gimp-will-only-fill-with-black Ciao, grazie per i suggerimenti. Proverò appena ho un po di tempo. Grazie mille. Se risolvo lo riporto in lista (magari può servire a qualcuno) Un saluto
Re: Debian Buster (10.4) e GIMP
Il 07/06/20 15:39, WinterMute ha scritto: il Fri, 5 Jun 2020 09:48:23 +0200 Alessandro Baggi ha scritto: | [...] buon pomeriggio, provando a cercare con le keyword "gimp color picker not working" escono diversi risultati (per altro ci sono segnalazioni del medesimo comportamento anche su win), non ho modo di approfondire ma ti conviene provare a seguire qualcuna delle segnalazioni presenti per vedere se trovi qualche spunto utile. non ho al momento modo di controllare in prima persona ma parrebbe che ci sia un qualche collegamento tra questo anomalo comportamento e l'utilizzo di wayland. comunque, come dicevo prima, prova ad eseguire una ricerca con quelle keywords magari riesci a trovare il bandolo della matassa (o qualche info utile per risolvere il problema). saluti. *** [-> WinterMute <-] -> https://www.debian.org/ «-branch-» [bullseye/sid] |GNU Project| -> https://www.gnu.org/ |Kernel Archives| -> https://www.kernel.org/ |GPG FingerPrint| -> 38A4 5354 30C5 E86F 9AA8 B234 7227 D71D A547 39E0 *** Ciao,e grazie per la risposta. Ho provato a cercare con le stesse keyword prima di postare ma non vedevo nulla di relativo a debian con la mia versione. Continuerò la mia ricerca. Grazie.
Re: Debian Buster (10.4) e GIMP
Il 04/06/20 19:20, liste DOT girarsi AT posteo DOT eu ha scritto: Il 04/06/20 08:24, Alessandro Baggi ha scritto: Ciao Simone, # apt info gimp Package: gimp Version: 2.10.8-2 Priority: optional Section: graphics Maintainer: Debian GNOME Maintainers Installed-Size: 19,5 MB . ... Server grafico Xorg (con Plasma e Nvidia driver) Alessandro. Io intendevo come server grafco, KDE, GNOME, XLDE, ecc.. Se hai plasma presumo KDE, però per i driver grafici NVidia, è tutto un programma, hai quelli proprietari scaricati dal sito NVidia o quelli dei repository? quelli recenti o i legacy? Hai pure i repository backports attivati immagino visto i driver proprietari. Temo un problema legato ai driver NVidia, però dipende dalla scheda grafica e se i driver sono i suoi; poi bisogna vedere se il problema c'è solo con gimp, in tal caso è possibile un bug di gimp. Ciao, io sapevo che KDE, GNOME ecc sono DE mentre Xorg o Wayland sono i server grafici. Comunque i driver sono installati dal repo di debian (non-free). Backports disabilitati. Il fatto è che il problema è riscontrato solo con GIMP mentre con kcolorchooser funziona a dovere. Un saluto.
Re: Debian Buster (10.4) e GIMP
Il 03/06/20 16:32, liste_girarsi ha scritto: Il 3 Giugno 2020 16:28:39 CEST, Alessandro Baggi ha scritto: Salve ragazzi, ho riscontrato un problema con GIMP su Debian 10 con il color picker del selezionatore di colore di primo piano nel pannello degli strumenti o da Menu->Finestre->Pannelli Agganciabili->Colori. In sostanza qualsiasi colore io selezioni mi da sempre nero (anche la notazione HTML). Ho provato anche su macchine diverse ma il problema persiste. Qualcuno presenta lo stesso problema? Al momento uso kcolorchooser per ovviare al problema. Un saluto. che versione di gimp? che serve grafico hai di sistema? --simone girardelli-- ## Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. Ciao Simone, # apt info gimp Package: gimp Version: 2.10.8-2 Priority: optional Section: graphics Maintainer: Debian GNOME Maintainers Installed-Size: 19,5 MB . ... Server grafico Xorg (con Plasma e Nvidia driver) Alessandro.
Debian Buster (10.4) e GIMP
Salve ragazzi, ho riscontrato un problema con GIMP su Debian 10 con il color picker del selezionatore di colore di primo piano nel pannello degli strumenti o da Menu->Finestre->Pannelli Agganciabili->Colori. In sostanza qualsiasi colore io selezioni mi da sempre nero (anche la notazione HTML). Ho provato anche su macchine diverse ma il problema persiste. Qualcuno presenta lo stesso problema? Al momento uso kcolorchooser per ovviare al problema. Un saluto.
Re: ZFS e consumo di RAM
Il 28/05/20 15:27, Piviul ha scritto: Piviul ha scritto il 28/05/20 alle 09:21: Ciao a tutti, in rete molti dicono che ZFS consuma tutta la RAM - 1GB. Forse all'inizio era così... io ricordo invece di aver letto, ma non ricordo dove, che il consumo di RAM (ARC) era proporzionale alla quantità di dati presenti nel pool zfs ma non ricordo nel dettaglio questa proporzionalità. Qualcuno mi sa indirizzare dove potermi documentare? come al solito continuo il mio monologo sperando che a qualcuno sia utile e che a qualcun altro non dia fastidio :) Documentazione[¹] credo[²] attendibile darebbe manforte a chi sostiene che ZFS consumi tutta la RAM meno 1GB; infatti si legge che il valore di default sia impostato al "75% of memory on systems with less than 4 GB of memory physmem minus 1 GB on systems with greater than 4 GB of memory". Però a me non torna: # arc_summary | grep -A9 ^ARC\ size ARC size (current): 94.4 % 59.4 GiB Target size (adaptive): 100.0 % 62.9 GiB Min size (hard limit): 6.2 % 3.9 GiB Max size (high water): 16:1 62.9 GiB Most Frequently Used (MFU) cache size: 0.7 % 386.3 MiB Most Recently Used (MRU) cache size: 99.3 % 56.2 GiB Metadata cache size (hard limit): 75.0 % 47.2 GiB Metadata cache size (current): 6.1 % 2.9 GiB Dnode cache size (hard limit): 10.0 % 4.7 GiB Dnode cache size (current): 0.2 % 10.5 MiB che è circa la metà della ram presente sul sistema: # free -h total used free shared buff/cache available Mem: 125Gi 64Gi 60Gi 104Mi 903Mi 59Gi Swap: 8.0Gi 0B 8.0Gi E a questo punto non mi resta altro che pensare che zfs in solaris si comporta diversamente che su linux... O no? Piviul [¹] https://docs.oracle.com/cd/E26502_01/html/E29022/chapterzfs-3.html [²] credo perché si riferisce a zfs in solaris ma non dovrebbero esserci differenza Ciao Piviul, sono nuovo con ZFS ma da quello che so hai ragione, è tutta la ram - 1GiB. Se necessiti di RAM (magari un VM o altro), puoi tranquillamente impostare zfs_arc_max ad un valore ragionevole. La ARC permette di accedere ai file in maniera più veloce. Ovviamente avere una ARC più grande ti permette di avere più file in cache. Abbassarla non comporta nessun problema per ZFS, ma ho letto consigli di non abbassarla sotto i 4GiB (non ho capito perche ma credo sia un fatto di prestazioni). Per la deduplicazione, anche se non l'ho ancora usata, ho letto che ZFS richiede 1 GiB di RAM per 1 TiB di dati, e questo credo si vada a sommare alla memoria usata dalla ARC, quindi attivare la deduplicazione solo se zdb riporta un rate di deduplicazione ragionevole. Dato il grande utilizzo di RAM da parte di ZFS (ARC e Deduplicazione) l'utilizzo di ram ECC sarebbe indicato, ma al momento lo sto provando su una macchina con RAM non ECC, chissa che succederà in caso di qualche bit corrotto. Hai qualche problema in particolare con l'utilizzo della RAM? PS. Le tue avventure con PROXMOX e ZFS e Debian le trovo stimolanti dal punto di vista tecnico. Un saluto.
Re: postgres upgrade interrotto
consiglio spassionato... quando fai queste cose, soprattutto da remoto... usa screen o tmux (il primo super rodato, il secondo notevole, secondo me). così, a meno che non si spenga proprio la macchina, recuperi sempre la tua sessione di lavoro. +100
Re: [OT] La scorsa notte ho avuto un incubo
Bellissima la GIF. Che dire... Il 11/05/20 20:11, Felipe Salvador ha scritto: https://giphy.com/gifs/hungry-systemd-5xtDarAgrjoOrBxSVYk
Re: Aggiunta HDD in un raid.
Ciao Alessandro...
in relatà non ho mai fatto il backup della nas, quindi non ho nulla da
verificare come integrità dei precedenti backup.
il backup che farò, in prima battuta, è della sola parte utente
"/home" e "/root", della parte di sistema, mi interessano solo un paio
di configurazioni, che mi copierò esplicitamente (non copio tutta
/etc, per intenderci.
in ogni caso, ho intenzione di attivare uno snapshot del sistema,
prima di procedere al backup, per non trovarmi con file/direcotry
bloccate, ma qui, devo chiarirmi un po' le idee prima...
Ho sempre fatto un po' di confusione su quello che devo andare a
copiare... se lo snapshot o la directory nativa...
In quale modo mi suggerisci di verificare poi l'integrità del backup?
E' mia intenzione di usare un banale rsync, in quanto i due HDD su cui
faccio il backup, non mi coprono l'intera struttura, devo quindi
spezzarli sui due dischi separatamente e in tempi diversi
(probabilmente addiritura in tempi diversi, visto che per ora ho solo
una sola interfaccia usb da collegare).
Ciao e buona domenica.
Se usi rsync, il primo consiglio che mi sento di darti è quello di
generare uno storico dei backup. Se continui ad eseguire il sync/backup
solo tra due dir hai solo l'ultima versione e non i pregressi tipo (con
hardlink per salvare spazio):
(in maniera molto semplificata)
mkdir -p /mnt/backup/{archive,dataset}
rsync -av --delete src/ /mnt/backup/dataset/
mkdir /mnt/backup/archive/backup-$(date "+%d_%m_%Y")
cp -al /mnt/backup/dataset/* /mnt/backup/archive/backup-date
per quanto riguarda l'ultimo comando rsync ha un'opzione per usare gli
hardlink ma io preferisco dividere il processo di sync dal processo di
"snapshot".
Per il discorso dell'integrità generalmente un controllo con checksum
dovrebbe essere sufficiente. Ricalcolare un checksum di un intero
dataset (molto grande) potrebbe essere una lunga operazione. Per fortuna
rsync ci viene in aiuto con l'opzione --out-format attraverso la quale
possiamo stampare l'output in maniera personalizzata tra cui l'md5sum
del file sincronizzato tipo rsync -av --out-format="%n;%C" che fa
stampare (se non erro) il nome del file e il relativo md5sum, che potrai
salvare nel modo che preferisci (NOTA: l'md5 viene riportato solo per i
file quindi nell'output di rsync dovresti eliminare tutto tranne i file.
Per semplificare l'operazione potresti inserire nell'out-format anche il
%i che simula l'itemize-change e attraverso il quale potresti estrarre
il tipo di file.) Una volta salvato il "manifest" con gli md5 potresti
eseguire un controllo sui file riportati iterando il tutto.
Nota: md5 ahime è quello che rsync al momento supporta, e per un
controllo di integrità dei file puo andare bene.
So che puo sembrare macchinoso ma è un'idea.
Potresti usare anche altri sistemi come borgbackup (che sto testando per
un mio uso). È semplice, crei un repo (cifrato se preferisci e remoto se
preferisci), lanci borg create . e fa il backup con deduplicazione
(molto più efficiente degli hardlink perche è la deduplicazione è sui
blocchi). Per il controllo lanci semplicemente un borg check sul
repository o sull'archivio e ti riporta lo stato del tutto. Anche qui
hai bisogno di creare il tuo script bash per fare il tutto ma è molto
piccolo. L'unica cosa che non mi fa impazzire di borg è che non supporta
nativamente il pull backup...per il resto è molto efficiente e puoi
usare ssh (come con rsync) per repository remoti. Ora la mia paura di
borg è che aggiungere deduplicazione, compressione e cifratura (3
livelli) rende il tutto (in particolare i file dove tutto viene salvato)
molto complesso e se qualcosa si rompe...sarebbe dura recuperarlo.
Non vorrei andare off-topic ma qualcuno con più esperienza con rsync,
borg o altri sistemi di backup potrebbe aiutarci in maniera più precisa
magari con altre soluzioni migliori.
Un saluto.
Re: Futuro di debian
Il 30/04/20 13:37, Federico Di Gregorio ha scritto: On 4/30/20 1:33 PM, marco wrote: Buon giorno: prima atto reso inutilizzabile qemu-utils, poi hanno tolto dai repository kvm e inoltre post installazione non e' piu' possibile utilizzare apt-get in quanto nella directory etc non e' piu' presente (alcuni hanno trovato lo stratagemma di ricrearselo); secondo voi e' l'inizio della morte di questa distro? Posso chiederti gentilmente di cosa ^!?£%$"! stai parlando? Post installazione di cosa? federico Mi accodo...cosa ha che non va debian? Kvm tolto dai repository? (prova con apt-cache -n search qemu-kvm) Parlare di morte di debian mi sembra assurdo (anche per il modo in cui la community e il suo sviluppo è gestito) soprattutto considerato che è la mamma di mille mila distro. Troll?
Re: Aggiunta HDD in un raid.
Il 25/04/20 19:27, Gollum1 ha scritto: Sono riuscito a trovare degli HDD su cui fare il backup, appena ordino il secondo disco da sostituire nel raid, spengo, tiro fuori uno dei dischi, mandando quindi in degraded il raid, e vediamo se lo spare viene usato correttamente, o se perdo tutto... Se dovessi perdere tutto, compro gli altri dischi mancanti e rifaccio tutto il raid e ripristino tutto sulla nuova serie di dischi... (sperando che il backup non sia fallato) Ciao, per quanto riguarda il backup, prima di fare il tutto avvia un'operazione di verifica di integrità dell'ultimo backup/snapshot o ciclo di backup in modo tale da avere almeno la certezza che quello che hai salvato sia integro come nel momento in cui l'hai salvato (ovvio potresti aver salvato dati già corrotti nel target quindi l'integrità verifica solo che il backup sia consistente). Se posso, che soluzione di backup stai utilizzando? Un saluto.
Re: qemu e permessi
Il 08/04/20 18:22, Sabrewolf ha scritto: Ciao, sul mio sistema non ho nè sudo nè tunctl perchè cerco sempre di evitare di installare cose superflue o obsolete. Con systemd-networkd avevo specificato "group=kvm" nella sezione [Tap] del file *.netdev ma a quanto pare non è bastato. Alla fine direi che la soluzione che ho indicato prima è la migliore e cioè: - con systemd-networkd configurare un bridge br0 (10.0.0.1/24) - con nft impostare il mascheramento di 10.0.0.1/24 in postrouting - settare "chmod u+s" su /usr/lib/qemu/qemu-bridge-helper e "allow br0" in /etc/qemu/bridge.conf - avviare qemu usando "-netdev tap,id=net0,br=br0,helper=/usr/lib/qemu/qemu-bridge-helper" - settare 10.0.0.1 come gateway nel sistema guest Rimango col dubbio se il bridge br0 è necessario oppure no. Ciao, se usi il bridge br0 non ha necessità di mascherare nulla. Assegni l'indizzo ip (della tua rete) alla VM con il metodo che preferisci ed è fatta. Ovviamente il bridge deve avere un'interfaccia slave altrimenti è tutto vano. Io utilizzo virt-install per installare le macchine virtuali su kvm+libvirt (ci sarebbe anche virt-manager ma lo uso poco), per la rete basta --network=bridge:br0 (ovvio sempre un bridge valido deve essere configurato) Un saluto.
