Forum Debianizzati

Condividi contenuti
Aggiornato: 1 ora 4 min fa

Re: Gnome, utente scomparso da login

Mar, 27/03/2018 - 14:11
Ho un NAS QNAP TS-231 con due baie, sistema operativo QTS 4.3 che e' basato su Linux (distribuito con licenza GNU).
Il collegamento alle directory condivise lo faccio con SAMBA perche la mia famiglia usa anche windows.
Il problema e' che il software operativo del NAS (QTS) non mi permette di cambiare i valori numerici di uid e gid.
Ho letto che alcuni hanno fatto delle modifiche direttamente sul sistema operativo del NAS andando a modificare il file /etc/passwd e i file di configurazione di SAMBA.
Io vorrei evitare di toccare il sistema operativo del NAS ed inoltre sul computer non memorizzo niente, uso il NAS come disco rigido quindi dovrei poi andare ad applicare le modifiche del uid e gid su tutti i dati memorizzati nel NAS.
Ho pensato fosse più semplice fare la modifica sul portatile in cui ho appena installato Debian Buster e in cui non ho dati memorizzati.
Categorie: Forum Debianizzati

Re: Gnome, utente scomparso da login

Mar, 27/03/2018 - 11:43
il nas che sistema operativo usa? non sarebbe più semplice cambiare uid e gid sul nas?
Categorie: Forum Debianizzati

Re: Intel Spectre v2 broken microcode detected

Mar, 27/03/2018 - 09:50
@Aki, grazie per la tua disponibilità.

Insomma, da quanto ho capito, non ci sono *errori* nel kernel e non devo intraprendere nessuna azione di modifica (magari aspettare solo il prossimo aggiornamento).
Giusto?

**
Da questa pagina si può scaricare un PDF con una tabella degli aggiornamenti del microcodice (Microcode update guidance) che risale al 6 marzo 2018:

https://newsroom.intel.com/news/latest-intel-security-news-updated-firmware-available/

February 20, 2018
Latest Intel Security News: Updated Firmware Available for 6th, 7th and 8th Generation Intel Core Processors, Intel Xeon Scalable Processors and More

There is also a comprehensive schedule and current status for planned microcode updates available online.
Categorie: Forum Debianizzati

Re: Gnome, utente scomparso da login

Mar, 27/03/2018 - 09:43
Ciao
ho applicato i comandi tramite uno script ed ho ottenuto il seguente output
root@Portatile:/home/utente2/Documenti# ./Script_cambioIDnumerico
usermod: Failed to change ownership of the home directoryfind: ‘/proc/2935/task/2935/fd/6’: File o directory non esistente
find: ‘/proc/2935/task/2935/fdinfo/6’: File o directory non esistente
find: ‘/proc/2935/fd/5’: File o directory non esistente
find: ‘/proc/2935/fdinfo/5’: File o directory non esistente
find: ‘/run/user/1001/gvfs’: Permesso negato
find: ‘/home/utente1/NAShomes’: L'host non è attivo
find: ‘/home/utente1/NASmultimedia’: L'host non è attivo
find: ‘/home/utente1/NASdownload’: L'host non è attivo
find: ‘/proc/4427/task/4427/fd/6’: File o directory non esistente
find: ‘/proc/4427/task/4427/fdinfo/6’: File o directory non esistente
find: ‘/proc/4427/fd/5’: File o directory non esistente
find: ‘/proc/4427/fdinfo/5’: File o directory non esistente
find: ‘/run/user/1001/gvfs’: Permesso negato
find: ‘/home/utente1/NAShomes’: L'host non è attivo
find: ‘/home/utente1/NASmultimedia’: L'host non è attivo
find: ‘/home/utente1/NASdownload’: L'host non è attivo
usermod: nessuna modifica
root@Portatile:/home/utente2/Documenti#

non capisco i permessi negati in alcune directory o perche non trovi alcuni file o directory.
Le risorse remote non erano attive perche avevo scollegato la rete (mi ero dimenticato di smontare le risorse remote )
Possono esserci dei problemi legati ai messaggi riportati?
Ho provato a collegarmi come utente1 ma ancora non era visibile nella schermata iniziale di login, collegandosi come altro utente sembra funzionare tutto.
Credo di aver capito perche' non trovo utente1 nella schermata di login e nella gestione utenti.
Debian interpreta gli uid numerici da 1 a 999 come programmi o sistema per cui non li tratta come utenti "umani" e non li elenca nella schermata iniziale.
Per risolvere dovrei modificare nel file /etc/login.defs i paramentri
GID_MIN (numerico) da 1000 a 500
UID_MIN (numerico) da 1000 a 500

non ho applicato la modifica, volevo prima verificarla e capire se occorre modificare solo il file login.defs o se vi sono altre modifiche da fare.
Ci sono problemi a modificare i valori di uid e gid minimi?
Ho verificato in /etc/passwrd e mi pare che nessuno utilizzi uid o gid numerici tra 500 e 999.
Categorie: Forum Debianizzati

Re: Intel Spectre v2 broken microcode detected

Lun, 26/03/2018 - 21:27
Grazie per aver fornito ulteriori dettagli.

Dai log che hai inviato nel corso della discussione, risulterebbe che, antecedentemente al 22 marzo 2018, era installata sul tuo computer la versione del microcodice intel-microcode:amd64 3.20170707.1~deb9u1 Prelevando il microcodice di questa versione ed analizzandola, risulta:
$ wget http://snapshot.debian.org/archive/debian/20180201T100533Z/pool/non-free/i/intel-microcode/intel-microcode_3.20170707.1%7Edeb9u1.tar.xz
$ tar xf intel-microcode_3.20170707.1~deb9u1.tar.xz
$ cd intel-microcode-3.20170707.1~deb9u1/
$ /usr/sbin/iucode-tool -l *.dat | grep 806e9
  006/157: sig 0x000806e9, pf_mask 0xc0, 2017-04-27, rev 0x0062, size 97280

Dal codice sorgente della versione del kernel "Linux version 4.9.0-6-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)" risulta che il codice che descrive (in termini di costanti) la tua CPU è:
[..]
struct sku_microcode {
   u8 model;
   u8 stepping;
   u32 microcode;
};
static const struct sku_microcode spectre_bad_microcodes[] = {
[..]
   { INTEL_FAM6_KABYLAKE_MOBILE,   0x09,   0x84 },
[..]
};

Il codice sorgente che effettua il controllo del "bad microcode" è il seguente, usando tre parametri relativi alla CPU (model, stepping e versione di microcodice):
static bool bad_spectre_microcode(struct cpuinfo_x86 *c)
{
   int i;

   for (i = 0; i < ARRAY_SIZE(spectre_bad_microcodes); i++) {
      if (c->x86_model == spectre_bad_microcodes[i].model &&
          c->x86_mask == spectre_bad_microcodes[i].stepping)
         return (c->microcode <= spectre_bad_microcodes[i].microcode);
   }
   return false;
}

Con il nuovo microcodice intel-microcode 3.20180312.1~bpo9+1, (che hai installato a partire dal 23 marzo, se non erro), risulta:
/usr/sbin/iucode-tool -l kernel/x86/microcode/GenuineIntel.bin
microcode bundle 1: kernel/x86/microcode/GenuineIntel.bin
selected microcodes:
  001/001: sig 0x000806e9, pf_mask 0xc0, 2018-01-21, rev 0x0084, size 98304
  001/002: sig 0x000806ea, pf_mask 0xc0, 2018-01-21, rev 0x0084, size 97280

Dal log che hai inviato, con il microcodice più recente, la CPU si identifica come:
$ cat /proc/cpuinfo
model           : 142
stepping       : 9
microcode    : 0x84   

Stante quanto sopra indicato, se prima del 22 marzo il precedente microcodice non faceva scattare il messaggio di avviso (a parità di controllo su modello del processore, stepping e test su versione di microcodice <= 0x84 in entrambe le versioni del microcodice), devo supporre che la precedente versione del microcodice non impostava nessuno dei seguenti flag della CPU (X86_FEATURE_SPEC_CTRL, X86_FEATURE_INTEL_STIBP, X86_FEATURE_IBRS e X86_FEATURE_IBPB):
/* Now if any of them are set, check the blacklist and clear the lot */
   if ((cpu_has(c, X86_FEATURE_SPEC_CTRL) ||
        cpu_has(c, X86_FEATURE_INTEL_STIBP) ||
        cpu_has(c, X86_FEATURE_IBRS) || cpu_has(c, X86_FEATURE_IBPB) ||
        cpu_has(c, X86_FEATURE_STIBP)) && bad_spectre_microcode(c)) {
      pr_warn("Intel Spectre v2 broken microcode detected; disabling Speculation Control\n");
[..]

In effetti, questi flag della CPU (X86_FEATURE_SPEC_CTRL, X86_FEATURE_INTEL_STIBP, X86_FEATURE_IBRS e X86_FEATURE_IBPB) dovrebbero essere implementati dal nuovo microcodice nella CPU, come espressione della mitigazione della vulnerabilità meltdown/spectre, e per questo motivo - devo presumere - non comparivano con la precedente versione del microcodice (che non prevedeva correzioni per le vulnerabilità meltdown/spectre,in quanto antecedente allo loro scoperta).

A questo punto, immagino, ti starai chiedendo perché il messaggio "Intel Spectre v2 broken microcode detected; disabling Speculation Control" continua a comparire con la nuova (3.20180312.1~bpo9+1) versione del microcodice. La risposta è che, la versione 0x84 del microcodice per la cpu intel non era ancora considerata sicura ed era/è, pertanto, inserita nella "blacklist" nel codice del kernel (Linux version 4.9.0-6-amd64 Debian 4.9.82-1+deb9u3) al momento del rilascio (2018-03-02).
Categorie: Forum Debianizzati

Re: file flac di dimensioni anomale

Lun, 26/03/2018 - 15:48
Il mistero si infittisce. Ho provato a convertire il primo flac da 445MB con diversi programmi:
ffmpeg --> 536MB
sox --> 789MB
Poi ho lasciato fare a K3b, e il file (tutti) risultano enormemente più piccoli.
Il file in questione diventa 115 MB e sparisce l'immagine incorporata
(che dovendo fare un CD non mi interessa)
Tuttavia sul file originale non sortiscono nessun effetto i comandi
samiel@darkstar ~ $ metaflac --remove --block-type=PICTURE brahms.flac
samiel@darkstar ~ $ metaflac --remove-tag=COVERART brahms.flac

Come posso procedere? Non so quale programma e quali parametri usi K3b...
Categorie: Forum Debianizzati

Re: file flac di dimensioni anomale

Lun, 26/03/2018 - 15:31
Si tratta di 16 file, in pratica 8 per ciascun CD. Il passaggio da flac a wav li aumenta all'incirca del 20%.
Il primo tempo del quartetto 1 in flac misura 445MB, quando la iso con annesso cue dei primi 2 quartetti
in un'altra edizione (per dare l'idea) misura 337MB in tutto.
Mi accorgo ora però che, riprodotti con alcuni player come VLC, i vari tempi mostrano anche
sul display l'immagine del quartetto. È incorporata? Come posso eliminarla per vedere
se è la presenza di questo "tag" visivo" ad aumentare spropositamente l'ampiezza del file?
Categorie: Forum Debianizzati