Re: qemu e permessi

2020-04-09 Per discussione Sabrewolf



Il 09/04/20 11:23, Alessandro Baggi ha scritto:


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.


Avevo letto da qualche parte che i bridge a volte danno problemi con il
wifi e per questo non avevo neanche provato la configurazione
"classica". Inoltre il bridge mi sta antipatico a prescindere :D



Ovviamente il bridge deve avere un'interfaccia slave altrimenti è
tutto vano.



Ce l'ho fatta a eliminarlo ! Vittoria !!

Ho trovato per caso la causa del problema e cioè avevo messo nella
sezione [Tap] del file *.netdev di systemd l'opzione "User=root" (e
ovviamente anche "Group=kvm").

Era proprio quel "user=root" il problema, e non ho idea del perchè.

Adesso la macchina virtuale va come volevo, senza bridge, solo con
tap...Pero' non funziona l'opzione vhost=on.

...E neanche l'audio.

Forse per il 2022 ce la farò a configurare tutto come voglio.



Re: qemu e permessi

2020-04-09 Per discussione Alessandro Baggi



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.



Re: qemu e permessi

2020-04-08 Per discussione Sabrewolf

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.


Il 07/04/20 12:35, Walter Valenti ha scritto:

Ciao,
credo che una semplice soluzione possa essere:

sudo tunctl -t tap0 -u __UTENZA__





Re: qemu e permessi

2020-04-07 Per discussione Walter Valenti
Ciao,
credo che una semplice soluzione possa essere:

sudo tunctl -t tap0 -u __UTENZA__







Salve a tutti, non riesco ad avviare qemu da utente:

qemu-system-x86_64: could not configure /dev/net/tun (tap0): Operation
not permitted

Le opzioni che uso sono semplicemente:

-netdev tap,id=net0,ifname=tap0,script=no,downscript=no
-device virtio-net,netdev=net0

Se eseguo qemu da root l'interfaccia tap0 viene attivata e
systemd-networkd assegna l'ip corretto. La rete internet sul guest
funziona tramite il mascheramento fatto con nft. Non uso bridge
insomma...Ma da utente non privilegiato qemu non parte.

Come risolvo ?



Re: qemu e permessi

2020-04-06 Per discussione Sabrewolf

Ho fatto un passo avanti, dopo aver letto qui:

https://wiki.qemu.org/Features/HelperNetworking

usando le opzioni:

-netdev tap,id=net0,br=br0,helper=/usr/lib/qemu/qemu-bridge-helper

Così facendo, dopo aver configurato br0 con systemd-networkd, qemu
parte. Mi crea tap1 e lo collega al bridge. Non mi piace questa cosa
perchè ho già tap0 e volevo usare questa. Non so nemmeno se è
logico/corretto assegnare un ip al bridge br0 e fare nat su questo.
Soprattutto continuo a non capire perchè qemu richieda un helper se
systemd-networkd è configurato per creare sia un bridge br0 che una rete
tap0.

Mi da fastidio questa cosa. :-S

Boh


Il 06/04/20 01:42, Sabrewolf ha scritto:


-netdev tap,id=net0,ifname=tap0,script=no,downscript=no
-device virtio-net,netdev=net0






qemu e permessi

2020-04-05 Per discussione Sabrewolf

Salve a tutti, non riesco ad avviare qemu da utente:

qemu-system-x86_64: could not configure /dev/net/tun (tap0): Operation
not permitted

Le opzioni che uso sono semplicemente:

-netdev tap,id=net0,ifname=tap0,script=no,downscript=no
-device virtio-net,netdev=net0

Se eseguo qemu da root l'interfaccia tap0 viene attivata e
systemd-networkd assegna l'ip corretto. La rete internet sul guest
funziona tramite il mascheramento fatto con nft. Non uso bridge
insomma...Ma da utente non privilegiato qemu non parte.

Come risolvo ?



Re: aiutino permessi file system

2019-05-13 Per discussione Piviul

Il 13/05/19 22:49, Marco Gaiarin ha scritto:

[...]
Dall'altro almeno con le ACL posix non credo che sia possibile; non so se
usando vfs_acl_xattr (ovvero cercando di sintetizzare nel modo più fedele
possibile le ACL windows) si possano fare cose del genere.
Quindi, la domanda è: in windows si possono fare cose del genere? Magari
usando le ACL negative? Allora forse... ma NON aspettarti la compatibilità
POSIX.
Si in windows si possono fare cose del genere avendo una granularità sui 
permessi molto maggiore; in effetti però anch'io ho optato per un altra 
soluzione più flessibile: interfaccia web dove si fanno le richieste di 
archiviazione di directories samba che nottetempo vengono poi spostate 
in una cartella di sola lettura e sostituite con un link MSDFS.


Grazie mille Marco!

Buona giornata a tutti quanti

Piviul



Re: aiutino permessi file system

2019-05-13 Per discussione Marco Gaiarin
Mandi! Piviul
  In chel di` si favelave...

> Quello di cui avrei bisogno è una directory condivisa samba (share) in 
> cui tutto ciò che viene copiato in quella share mantiene le stesse acl 
> di accesso dell'origine eccetto che diventa in sola lettura...
> È un po' troppo pretenzioso?

Credo di si.

Da un lato è 'logicamente' poco ragionevole: se puoi creare un file, lo puoi
anche modificare.


Dall'altro almeno con le ACL posix non credo che sia possibile; non so se
usando vfs_acl_xattr (ovvero cercando di sintetizzare nel modo più fedele
possibile le ACL windows) si possano fare cose del genere.
Quindi, la domanda è: in windows si possono fare cose del genere? Magari
usando le ACL negative? Allora forse... ma NON aspettarti la compatibilità
POSIX.


Ovviamente puoi pensare a uno script... insomma, costruiti qualcosa...

-- 
  ...buffoni che campate di versi senza forza
  avrete soldi e gloria, ma non avete scorza;   (F. Guccini)




Re: aiutino permessi file system

2019-05-08 Per discussione Piviul

Il 07/05/19 16:20, ThEgAmEr ha scritto:

[...]
Non sono sicuro che in questo modo tu riesca ad ottenere esattamente
quello che vuoi ma forse combinato con altro puo' essere utile:
su fs che lo supportano(ext4 si) da root puo' impostare l'attributo
"a"  (append only) alla cartella:
#chattr +a /cartellaworm/

da quel momento (coerentemente con gli altri permessi settati) si
potranno aggiungere file alla cartella ma non rimuoverli o
rinominarli, questo vale anche per i proprietari dei file al contrario
dello sticky bit suggerito da Federico.
non si possono cancellare, non si possono rinominare ma si possono 
modificare...


Quello di cui avrei bisogno è una directory condivisa samba (share) in 
cui tutto ciò che viene copiato in quella share mantiene le stesse acl 
di accesso dell'origine eccetto che diventa in sola lettura...


È un po' troppo pretenzioso?

Piviul



Re: aiutino permessi file system

2019-05-07 Per discussione Piviul
nel caso in cui non fosse possibile con posix standard anche utilizzando 
acl...


Grazie

Piviul

Il 07/05/19 15:02, Piviul ha scritto:
Ciao a tutti, non ricordo come ma ricordo che in un file system ext4 era 
possibile creare un cartella in cui tutti potessero scrivere ma una 
volta inserito un file nella cartella questo diventava in read only 
anche per l'utente che lo aveva inserito. Ricordo male? Altrimenti mi 
rammentate come si possa ottenere?


Grazie

Piviul






Re: aiutino permessi file system

2019-05-07 Per discussione Piviul

Il 07/05/19 15:02, Piviul ha scritto:
Ciao a tutti, non ricordo come ma ricordo che in un file system ext4 era 
possibile creare un cartella in cui tutti potessero scrivere ma una 
volta inserito un file nella cartella questo diventava in read only 
anche per l'utente che lo aveva inserito. Ricordo male? Altrimenti mi 
rammentate come si possa ottenere?
scusate era molto banale, basta cambiare la umask... ma a livello di 
file system è possibile?


Piviul



Re: aiutino permessi file system

2019-05-07 Per discussione ThEgAmEr
On Tue, May 7, 2019 at 3:02 PM Piviul  wrote:
>
> Ciao a tutti, non ricordo come ma ricordo che in un file system ext4 era
> possibile creare un cartella in cui tutti potessero scrivere ma una
> volta inserito un file nella cartella questo diventava in read only
> anche per l'utente che lo aveva inserito. Ricordo male? Altrimenti mi
> rammentate come si possa ottenere?


Non sono sicuro che in questo modo tu riesca ad ottenere esattamente
quello che vuoi ma forse combinato con altro puo' essere utile:
su fs che lo supportano(ext4 si) da root puo' impostare l'attributo
"a"  (append only) alla cartella:
#chattr +a /cartellaworm/

da quel momento (coerentemente con gli altri permessi settati) si
potranno aggiungere file alla cartella ma non rimuoverli o
rinominarli, questo vale anche per i proprietari dei file al contrario
dello sticky bit suggerito da Federico.



Re: aiutino permessi file system

2019-05-07 Per discussione Federico Di Gregorio

On 5/7/19 3:02 PM, Piviul wrote:
Ciao a tutti, non ricordo come ma ricordo che in un file system ext4 era 
possibile creare un cartella in cui tutti potessero scrivere ma una 
volta inserito un file nella cartella questo diventava in read only 
anche per l'utente che lo aveva inserito. Ricordo male? Altrimenti mi 
rammentate come si possa ottenere?


E` il bit sticky, ma ricordi leggermente sbagliato. Tutti possono 
scrivere ma non si può cancellare o rinominare il file di un altro utente.


Per impostarlo puoi usare "chmod +t".

federico

--
Federico Di Gregorio federico.digrego...@dndg.it
DNDG srl  http://dndg.it
 I porcellini di terra sono davvero Crostacei! Non lo sapevo!
  Certo che sono crostacei, hanno la crosta!
  Allora la pizza è un crostaceo?!   -- discorso all'ESC2k07



aiutino permessi file system

2019-05-07 Per discussione Piviul
Ciao a tutti, non ricordo come ma ricordo che in un file system ext4 era 
possibile creare un cartella in cui tutti potessero scrivere ma una 
volta inserito un file nella cartella questo diventava in read only 
anche per l'utente che lo aveva inserito. Ricordo male? Altrimenti mi 
rammentate come si possa ottenere?


Grazie

Piviul



Re: [OT] Tar e permessi

2017-12-29 Per discussione Igor Trevisan
2017-12-29 11:51 GMT+01:00 Federico Di Gregorio :

> On 29/12/17 11:11, Felipe Salvador wrote:
>
>> On Fri, Dec 29, 2017 at 07:53:48AM +0100, Igor Trevisan wrote:
>>
>>> Con un framework per la gestione/creazione di Root File System per
>>> sistemi
>>> Linux genero un pacchetto tar.bz2 che contiene un RFS completo per un
>>> sistema Linux (arm). Tale pacchetto contiene file il cui owner è root
>>> (riferito al sistema embedded per cui è stato prodotto).
>>> Dovrei scompattare tale archivio, modificare un file e ricompattarlo
>>> senza
>>> modificare owner e permessi dei file del RFS.
>>> E' possibile? Se sì, come?
>>>
>>
> Se decompatti il file come root e usi --preserve tar mantiene i permessi
> ed i proprietari anche se NON ESISTONO sulla macchina. Con un "ls -a"
> vedrai owner e gruppo numerici invece che i nomi definiti in /etc/passwd.
> Quando ricompatti, se dici a tar di mantenere permessi e proprietari tutto
> dovrebbe funzionare.
>
>
Avevo visto quest'opzione di tar ma purtroppo non posso eseguire nulla
come"root" sulla macchina su cui sto lavorando! :-(
Come detto però, per il mio caso specifico fakeroot ha risolto il problema.

Grazie,
I.


Re: [OT] Tar e permessi

2017-12-29 Per discussione Federico Di Gregorio

On 29/12/17 11:11, Felipe Salvador wrote:

On Fri, Dec 29, 2017 at 07:53:48AM +0100, Igor Trevisan wrote:

Con un framework per la gestione/creazione di Root File System per sistemi
Linux genero un pacchetto tar.bz2 che contiene un RFS completo per un
sistema Linux (arm). Tale pacchetto contiene file il cui owner è root
(riferito al sistema embedded per cui è stato prodotto).
Dovrei scompattare tale archivio, modificare un file e ricompattarlo senza
modificare owner e permessi dei file del RFS.
E' possibile? Se sì, come?


Se decompatti il file come root e usi --preserve tar mantiene i permessi 
ed i proprietari anche se NON ESISTONO sulla macchina. Con un "ls -a" 
vedrai owner e gruppo numerici invece che i nomi definiti in 
/etc/passwd. Quando ricompatti, se dici a tar di mantenere permessi e 
proprietari tutto dovrebbe funzionare.



federico


--
Federico Di Gregorio federico.digrego...@dndg.it
DNDG srl  http://dndg.it
  monja: che c'entra, l'importante è sapersi usare -- 



Re: [OT] Tar e permessi

2017-12-29 Per discussione Igor Trevisan
Ciao Felipe,

grazie per aver preso in considerazione il mio quesito!

2017-12-29 11:11 GMT+01:00 Felipe Salvador :

> On Fri, Dec 29, 2017 at 07:53:48AM +0100, Igor Trevisan wrote:
>
> > Dovrei scompattare tale archivio, modificare un file e ricompattarlo
> senza
> > modificare owner e permessi dei file del RFS.
> > E' possibile? Se sě, come?
>
> Potresti agire utilizzando i permessi del gruppo, lasciando intatto
> l'owner.
>
>
alla fine ho trovato la soluzione: fakeroot!

Mi sono guardato un po' come funziona questo comando e sono riuscito a fare
quello che mi serviva.

Lo riporto qui, nel caso in futuro possa essere utile/interessante per
altri:

(dentro uno script eseguo)

fakeroot sh -c '
  tar xvjf pkg.tar.bz2
  echo "blabla" >> my_path/file_to_change

  [other stuff...]

  exit'

e il gioco è fatto.

Ciao e grazie,
I.


Re: [OT] Tar e permessi

2017-12-29 Per discussione Felipe Salvador
On Fri, Dec 29, 2017 at 07:53:48AM +0100, Igor Trevisan wrote:
> Con un framework per la gestione/creazione di Root File System per sistemi
> Linux genero un pacchetto tar.bz2 che contiene un RFS completo per un
> sistema Linux (arm). Tale pacchetto contiene file il cui owner è root
> (riferito al sistema embedded per cui è stato prodotto).
> Dovrei scompattare tale archivio, modificare un file e ricompattarlo senza
> modificare owner e permessi dei file del RFS.
> E' possibile? Se sì, come?

Potresti agire utilizzando i permessi del gruppo, lasciando intatto l'owner.


> Comunque vada a finire questo mio OT (cestino, /dev/null ecc...) colgo
> l'occasione per augurare a tutta la Lista un Buonissimo 2018! :-)
> Ciao e grazie,
> Igor.
> 
> 
> -- 
> "Don't find fault, find a remedy" (H.Ford)
> ---

Ciao

-- 
Felipe Salvador



[OT] Tar e permessi

2017-12-28 Per discussione Igor Trevisan
Ciao a tutti,

mi scuso subito per l'OT: la questione che pongo è assolutamente generale
(e non strettamente collegata a Debian quindi) ma confido che in lista ci
sia qualche anima pia che mi perdoni e possa dare una risposta definitiva
ai miei dubbi.

Vengo al sodo.
Sto lavorando da utente normale (senza alcun privilegio di root e senza
sudo) su una macchina di sviluppo su cui girano alcuni compilatori
arm-linux.
Con un framework per la gestione/creazione di Root File System per sistemi
Linux genero un pacchetto tar.bz2 che contiene un RFS completo per un
sistema Linux (arm). Tale pacchetto contiene file il cui owner è root
(riferito al sistema embedded per cui è stato prodotto).
Dovrei scompattare tale archivio, modificare un file e ricompattarlo senza
modificare owner e permessi dei file del RFS.
E' possibile? Se sì, come?

Comunque vada a finire questo mio OT (cestino, /dev/null ecc...) colgo
l'occasione per augurare a tutta la Lista un Buonissimo 2018! :-)
Ciao e grazie,
Igor.


-- 
"Don't find fault, find a remedy" (H.Ford)
---


Re: Ripristinare i permessi del pc di casa

2017-03-05 Per discussione Davide Prina

On 04/03/2017 23:41, Giuliano Grandin wrote:


Non so come o cosa, ma qui a casa i permessi del pc domestico
sono saltati[...]



Mi chiedo, dato che nel portatile c'è sempre jessie[...]


forse con aide puoi risolvere velocemente... se su entrambi i PC sono 
installati più o meno gli stessi pacchetti


esegui aide sul portatile, copi il file generato sul fisso e lo riesegui 
qui per trovare i file con attributi diversi.


Se funziona, per controllare i file rimanenti puoi estrarti tutti i 
pacchetti installati su entrambi i PC e usare un programma di diff per 
vedere quali sono installati solo sul portatile.


Ciao
Davide

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



Ripristinare i permessi del pc di casa

2017-03-04 Per discussione Giuliano Grandin
Ciao a tutti.
Non so come o cosa, ma qui a casa i permessi del pc domestico
sono saltati, ad es. /usr/bin/google-chrome-stable non appartiene a
root e i permessi non sono 4755. Ripristinati ha ripreso a funzionare.

Ora non so cos'altro c'è di sbagliato e allora ho letto il thread del
2015 sullo stesso argomento.

Mi chiedo, dato che nel portatile c'è sempre jessie, posso montare in
rete il suo hd e copiare con cp --attributes-only i permessi dal
portatile al pc fisso?

Qualche suggerimento, che non comporti lo smontaggio dei pc?

Grazie a tutti

Giuliano

--
« I don't know what's the matter with people: they don't learn by
understanding; they learn by some other way — by rote or something.
Their knowledge is so fragile »

Richard Phillips Feynman, 
Surely You're Joking, Mr. Feynman!: Adventures of a Curious Character.



Re: ripristinare i permessi di default

2015-08-26 Per discussione Davide Prina

On 26/08/2015 10:16, Piviul wrote:


sys invece non viene creata runtime dal kernel?


sì, hai ragione, ho sbagliato :-(

Ciao
Davide

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



Re: ripristinare i permessi di default

2015-08-26 Per discussione Dott. Giovanni Bonenti
Il giorno 26 agosto 2015 10:16, Piviul  ha scritto:

> Dott. Giovanni Bonenti ha scrito il 25/08/2015 alle 21:21:
> > Aggiungo di amputare 2 o 3 dita al tuo collega o sottrargli il tempo
> > perso a rimettere a posto i casini che ha combinato dalla sua
> > retribuzione del mese prossimo
> ...è il mio capo.
>
> Piviul
>
>
Mannaggia la malora, subodoravo la fregatura.

;) ;) ;)

Giovanni

-- 
Dott. Giovanni Bonenti
Medico Radiologo
C.so Traiano 24/2
10135 - TORINO
ITALIA


Re: ripristinare i permessi di default

2015-08-26 Per discussione Piviul
Dott. Giovanni Bonenti ha scrito il 25/08/2015 alle 21:21:
> Aggiungo di amputare 2 o 3 dita al tuo collega o sottrargli il tempo
> perso a rimettere a posto i casini che ha combinato dalla sua
> retribuzione del mese prossimo
...è il mio capo.

Piviul



Re: ripristinare i permessi di default

2015-08-26 Per discussione Piviul
Davide Prina ha scrito il 25/08/2015 alle 18:58:
> ma scusa, se ha fatto quel casino non potrebbe averne fatti altri?
non dovrebbe a sentire lui. Voleva cambiare i permessi ad una alberatura
con uno script e si è dimenticato di impostare la variabile nello script
che definisce la posizione della alberatura sicché ha cambiato i
permessi dell'alberatura di /.

> Non fai prima a:
> 
> 1) usare dpkg --get-selections per salvarti i pacchetti salvati
> 2) rifai una macchina ripristinando con --set-selections
> 3) fai un controllo delle configurazioni e cambi solo dove necessario
non è proprio così... sulla macchina è installato anche oracle client,
senza contare che ci sono una mare di piccoli cambiamenti nei files di
configurazione... ora sembra essere tutto a posto.

>> Non ho capito perché non basta farlo soltanto delle directory /etc /usr
>> /bin /sbin /boot /var in ogni caso...
> 
> e /lib*, /sys, ...
o porca paletta, mi ero dimenticato di lib!

sys invece non viene creata runtime dal kernel?

Mille grazie

Piviul



Re: ripristinare i permessi di default

2015-08-25 Per discussione Dott. Giovanni Bonenti
Il giorno 25 agosto 2015 18:58, Davide Prina  ha
scritto:

> ma scusa, se ha fatto quel casino non potrebbe averne fatti altri?
> Non fai prima a:
>
> 1) usare dpkg --get-selections per salvarti i pacchetti salvati
> 2) rifai una macchina ripristinando con --set-selections
> 3) fai un controllo delle configurazioni e cambi solo dove necessario
>

Aggiungo di amputare 2 o 3 dita al tuo collega o sottrargli il tempo perso
a rimettere a posto i casini che ha combinato dalla sua retribuzione del
mese prossimo

Giovanni


-- 
Dott. Giovanni Bonenti
Medico Radiologo
C.so Traiano 24/2
10135 - TORINO
ITALIA


Re: ripristinare i permessi di default

2015-08-25 Per discussione Davide Prina

On 25/08/2015 11:20, Piviul wrote:


Piviul ha scrito il 24/08/2015 alle 08:12:

Ciao a tutti, un mio collega mentre ero in ferie ha incasinato i
permessi di un fs di un server



sono riuscito a farlo ripartire facendo una installazione minimale su un
altro hd facendo il boot da quella e poi creando uno script per il
ripristino dei permessi con i comandi:

# find / -type d -exec stat --format "chmod %a \"/mnt%n\"" {} \; >
ripristinaPermessi.sh
# find / -type f -exec stat --format "chmod %a \"/mnt%n\"" {} \; >>
ripristinaPermessi.sh


ma scusa, se ha fatto quel casino non potrebbe averne fatti altri?
Non fai prima a:

1) usare dpkg --get-selections per salvarti i pacchetti salvati
2) rifai una macchina ripristinando con --set-selections
3) fai un controllo delle configurazioni e cambi solo dove necessario


Non ho capito perché non basta farlo soltanto delle directory /etc /usr
/bin /sbin /boot /var in ogni caso...


e /lib*, /sys, ...

Ciao
Davide

--
Dizionari: http://linguistico.sourceforge.net/wiki
Strumenti per l'ufficio: https://www.libreoffice.org
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook



Re: ripristinare i permessi di default

2015-08-25 Per discussione Piviul
Piviul ha scrito il 24/08/2015 alle 12:25:
> Piviul ha scrito il 24/08/2015 alle 08:12:
>> Ciao a tutti, un mio collega mentre ero in ferie ha incasinato i
>> permessi di un fs di un server di sviluppo in tal modo che il server non
>> parte più. C'è un modo per ripristinare i permessi default (ammesso che
>> riesca a farlo ripartire)?
sono riuscito a farlo ripartire facendo una installazione minimale su un
altro hd facendo il boot da quella e poi creando uno script per il
ripristino dei permessi con i comandi:

# find / -type d -exec stat --format "chmod %a \"/mnt%n\"" {} \; >
ripristinaPermessi.sh
# find / -type f -exec stat --format "chmod %a \"/mnt%n\"" {} \; >>
ripristinaPermessi.sh

Non ho capito perché non basta farlo soltanto delle directory /etc /usr
/bin /sbin /boot /var in ogni caso...

Probabilmente era sufficiente un cp con --attributes-only.

Beh, grazie a tutti quanti

Piviul



Re: ripristinare i permessi di default

2015-08-24 Per discussione Piviul
onetmt ha scrito il 24/08/2015 alle 15:41:
> Questo messaggio non significa necessariamente che /bin/bash (ovviamente
> nella tua chroot) sia inaccessibile; 
in effetti /mnt/bin/bash viene eseguito tranquillamente

> e' probabile che l'access denied se
> lo stia beccando lo stesso /bin/bash quando prova ad aprire file o
> directory nella chroot. Per esempio, trova un /etc/passwd con permessi
> --- (giusto per citarne uno, ma i file aperti dalla shell sono
> centinaia, se non migliaia).
ma ora i permessi dei files in /etc /usr /boot /bin /sbin e /var
dovrebbero essere a posto per lo script che mi sono costruito da un
server similare no? ...evidentemente no.

Mille grazie comunque per aver tolto un po' di magia al mio problema

Ciao e grazie

Piviul



Re: ripristinare i permessi di default

2015-08-24 Per discussione onetmt
On 24/08/2015 15:24, Piviul wrote:
> gerlos ha scrito il 24/08/2015 alle 14:59:
>> Può essere che il file system sia montato con l’opzione noexec?
> no, ho controllato con il comando mount ma per non saper né leggere né
> scrivere ho provato anche a montarlo con on le opzioni rw,exec ma non è
> cambiato nulla
> 
>> [...] 
>> PS Io non lo monterei direttamente su /mnt, ma in una subdirectory… 
> mi sembra stiamo entrando nel soprannaturale... comunque ho provato
> anche questo ma non è cambia nulla. Visto che a questo punto stiamo
> esplorando anche cose improbabili ho provato anche da una debian live ma
> non è cambaito (per fortuna) nulla: anche la live di debian provando a
> chroottare il filesystem originale risponde con un /bin/bash permission
> denied

Questo messaggio non significa necessariamente che /bin/bash (ovviamente
nella tua chroot) sia inaccessibile; e' probabile che l'access denied se
lo stia beccando lo stesso /bin/bash quando prova ad aprire file o
directory nella chroot. Per esempio, trova un /etc/passwd con permessi
--- (giusto per citarne uno, ma i file aperti dalla shell sono
centinaia, se non migliaia).

> 
> A questo punto reinstallerò wheeze su un altro hd ripartendo daccapo...
> non mi viene in mente altro.
> 
> Piviul
> 
> 


-- 
Hofstadter's Law:
"It always takes longer than you expect, even when you take into account
Hofstadter's Law."



Re: ripristinare i permessi di default

2015-08-24 Per discussione Piviul
gerlos ha scrito il 24/08/2015 alle 14:59:
> Può essere che il file system sia montato con l’opzione noexec?
no, ho controllato con il comando mount ma per non saper né leggere né
scrivere ho provato anche a montarlo con on le opzioni rw,exec ma non è
cambiato nulla

>[...] 
> PS Io non lo monterei direttamente su /mnt, ma in una subdirectory… 
mi sembra stiamo entrando nel soprannaturale... comunque ho provato
anche questo ma non è cambia nulla. Visto che a questo punto stiamo
esplorando anche cose improbabili ho provato anche da una debian live ma
non è cambaito (per fortuna) nulla: anche la live di debian provando a
chroottare il filesystem originale risponde con un /bin/bash permission
denied

A questo punto reinstallerò wheeze su un altro hd ripartendo daccapo...
non mi viene in mente altro.

Piviul



Re: ripristinare i permessi di default

2015-08-24 Per discussione gerlos

Il giorno 24/ago/2015, alle ore 14:05, Piviul  ha scritto:

> gerlos ha scrito il 24/08/2015 alle 13:19:
>> Hm. Ci faresti vedere i permessi di /bin/bash per esempio? Usa ls -l e 
>> getfacl. 
> 
> ubuntu@ubuntu:~$ ls -l /mnt/bin/bash
> -rwxr-xr-x 1 root root 941252 2014-09-25 20:46 /mnt/bin/bash
> ubuntu@ubuntu:~$ getfacl /mnt/bin/bash
> getfacl: Removing leading '/' from absolute path names
> # file: mnt/bin/bash
> # owner: root
> # group: root
> user::rwx
> group::r-x
> other::r-x
> 
>> Che utente stai usando? Root o un utente normale tramite sudo?
> sto usando il cd live di xubuntu 11.10 (avevo quello sotto mano) e ho
> provato sia con sudo chroot /mnt che da utente root direttamente
> (loggandomi come root tramite sudo su -)
> 
> ubuntu@ubuntu:~$ sudo chroot /mnt
> chroot: impossibile eseguire il comando "/bin/bash": Permesso negato
> ubuntu@ubuntu:~$ sudo su -
> root@ubuntu:~# chroot /mnt
> chroot: impossibile eseguire il comando "/bin/bash": Permesso negato

Può essere che il file system sia montato con l’opzione noexec?

Qual è l’output di 
$ mount 
Relativo al file system in questione?

saluti,
gerlos

PS Io non lo monterei direttamente su /mnt, ma in una subdirectory… 

--
"Life is pretty simple: You do some stuff. Most fails. Some works. You do more
of what works. If it works big, others quickly copy it. Then you do something
else. The trick is the doing something else."
   < http://gerlos.altervista.org >
 gerlos  +- - - >  gnu/linux registred user #311588



Re: ripristinare i permessi di default

2015-08-24 Per discussione Piviul
gerlos ha scrito il 24/08/2015 alle 13:19:
> Hm. Ci faresti vedere i permessi di /bin/bash per esempio? Usa ls -l e 
> getfacl. 

ubuntu@ubuntu:~$ ls -l /mnt/bin/bash
-rwxr-xr-x 1 root root 941252 2014-09-25 20:46 /mnt/bin/bash
ubuntu@ubuntu:~$ getfacl /mnt/bin/bash
getfacl: Removing leading '/' from absolute path names
# file: mnt/bin/bash
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

> Che utente stai usando? Root o un utente normale tramite sudo?
sto usando il cd live di xubuntu 11.10 (avevo quello sotto mano) e ho
provato sia con sudo chroot /mnt che da utente root direttamente
(loggandomi come root tramite sudo su -)

ubuntu@ubuntu:~$ sudo chroot /mnt
chroot: impossibile eseguire il comando "/bin/bash": Permesso negato
ubuntu@ubuntu:~$ sudo su -
root@ubuntu:~# chroot /mnt
chroot: impossibile eseguire il comando "/bin/bash": Permesso negato

Piviul



Re: ripristinare i permessi di default

2015-08-24 Per discussione gerlos

Il giorno 24/ago/2015, alle ore 12:48, Piviul  ha scritto:

> Scrap ha scrito il 24/08/2015 alle 12:38:
>> la butto lì...
>> se provi ad usare una distro live sul server
> questo l'ho fatto, e ho provato a ripristinare i permessi con lo script
> che vi dicevo senza alcun risultato...
> 
>> ed usi chroot per accedere
>> al sistema danneggiato? magari da li poi riesci a sistemare i permessi e
>> farlo ripartire.
> Ci avevo pensato sperando che dpkg-reconfigure -a fosse in grado di
> ripristinare i permessi ma anche qui ho trovato un inghippo. Dopo aver
> montato il filesystem in /mnt eseguendo chroot /mnt ottengo l'errore:
> 
> chroot: impossibile eseguire il comando "/bin/bash": permesso negato

Hm. Ci faresti vedere i permessi di /bin/bash per esempio? Usa ls -l e getfacl. 

Che utente stai usando? Root o un utente normale tramite sudo?

saluti,
gerlos

--
"Fairy tales are more than true, not because they tell us that dragons exist, 
but because they tell us that dragons can be beaten."
G. K. Chesterton
   <http://gerlos.altervista.org>
gerlos +- - - > gnu/linux registred user #311588



Re: ripristinare i permessi di default

2015-08-24 Per discussione Piviul
Scrap ha scrito il 24/08/2015 alle 12:38:
> la butto lì...
> se provi ad usare una distro live sul server
questo l'ho fatto, e ho provato a ripristinare i permessi con lo script
che vi dicevo senza alcun risultato...

> ed usi chroot per accedere
> al sistema danneggiato? magari da li poi riesci a sistemare i permessi e
> farlo ripartire.
Ci avevo pensato sperando che dpkg-reconfigure -a fosse in grado di
ripristinare i permessi ma anche qui ho trovato un inghippo. Dopo aver
montato il filesystem in /mnt eseguendo chroot /mnt ottengo l'errore:

chroot: impossibile eseguire il comando "/bin/bash": permesso negato

:(

Piviul



Re: ripristinare i permessi di default

2015-08-24 Per discussione Scrap

la butto lì...
se provi ad usare una distro live sul server ed usi chroot per accedere 
al sistema danneggiato? magari da li poi riesci a sistemare i permessi e 
farlo ripartire.


On 08/24/2015 12:25 PM, Piviul wrote:

Piviul ha scrito il 24/08/2015 alle 08:12:

Ciao a tutti, un mio collega mentre ero in ferie ha incasinato i
permessi di un fs di un server di sviluppo in tal modo che il server non
parte più. C'è un modo per ripristinare i permessi default (ammesso che
riesca a farlo ripartire)?

Dunque, per cercare di ripristinare almeno l'avvio ho creato il seguente
script da un server simile:

# find /etc /usr /bin /sbin /boot /var -type d -exec stat --format
"chmod %a \"/mnt${MPOINT}%n\"" {} \; > ripristinaPermessi.sh
# find /etc /usr /bin /sbin /boot /var -type f -exec stat --format
"chmod %a \"/mnt${MPOINT}%n\"" {} \; >> ripristinaPermessi.sh

Poi con una live ho montato il filesystem del server di sviluppo su /mnt
ed eseguito lo script ripristinaPermessi.sh creato precedentemente ma
non è cambiato nulla :(

Al boot continuo a ricevere l'errore:
switch_root: can't execute '/sbin/init': Permission denied

Qualcuno ha qualche idea di cosa abbia bisogno per poter partire?

Piviul






Re: ripristinare i permessi di default

2015-08-24 Per discussione Piviul
Piviul ha scrito il 24/08/2015 alle 08:12:
> Ciao a tutti, un mio collega mentre ero in ferie ha incasinato i
> permessi di un fs di un server di sviluppo in tal modo che il server non
> parte più. C'è un modo per ripristinare i permessi default (ammesso che
> riesca a farlo ripartire)?

Dunque, per cercare di ripristinare almeno l'avvio ho creato il seguente
script da un server simile:

# find /etc /usr /bin /sbin /boot /var -type d -exec stat --format
"chmod %a \"/mnt${MPOINT}%n\"" {} \; > ripristinaPermessi.sh
# find /etc /usr /bin /sbin /boot /var -type f -exec stat --format
"chmod %a \"/mnt${MPOINT}%n\"" {} \; >> ripristinaPermessi.sh

Poi con una live ho montato il filesystem del server di sviluppo su /mnt
ed eseguito lo script ripristinaPermessi.sh creato precedentemente ma
non è cambiato nulla :(

Al boot continuo a ricevere l'errore:
switch_root: can't execute '/sbin/init': Permission denied

Qualcuno ha qualche idea di cosa abbia bisogno per poter partire?

Piviul



ripristinare i permessi di default

2015-08-23 Per discussione Piviul
Ciao a tutti, un mio collega mentre ero in ferie ha incasinato i
permessi di un fs di un server di sviluppo in tal modo che il server non
parte più. C'è un modo per ripristinare i permessi default (ammesso che
riesca a farlo ripartire)?

Piviul



Re: Modificare in massa i permessi : problema con file e dir con spazi e underscore

2014-11-28 Per discussione Gian Uberto Lauri
Gerlos writes:

 > Che esagerazione!
 > La gran parte delle volte basta usare le virgolette "" o gli apici '' 
 > per "proteggere" gli spazi.

Si, sulla command line. Evita tu che for separi le varie parti in una
for i in * senza mettere mano a IFS. Ma sai chee due palline. Si fa
prima a non usare i blank nei nomi dei file.

Poi devi fare in modo che ogni volta che passi un filename da uno
script all'altro questo sia blindato... Ma gli metto un tassametro
sulla barra spaziatrice (e intasco io, che cavoli!)

-- 
Gian
   Friends will be friends
  right to the end!


-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21624.31483.116780.608...@mail.eng.it



Re: Modificare in massa i permessi : problema con file e dir con spazi e underscore

2014-11-28 Per discussione Gerlos

Il 24/11/2014 12:16, Gian Uberto Lauri ha scritto:

pac writes:
  > Vorrei modificare i permessi nella mia directory Documenti come segue
  > Tutte le dir 775
  > Tutti i file 664
  > Per far questo ho tentato di utilizzare i seguenti comandi :
  > find percorsoincuicambiareipermessi -type f | xargs chmod 664 per

find path -type f -exec chmod 664 {} \;

  > find percorsoincuicambiareipermessi -type d | xargs chmod 775 per
  > modificare solo le directory

find path -type d -exec chmod 775 {} \;


  > Solo che in questo modo mi salta directory e file in cui ci sono degli
  > spazi

MAI usare gli spazi. Sono il separatore di token di default nella shell.


Che esagerazione!
La gran parte delle volte basta usare le virgolette "" o gli apici '' 
per "proteggere" gli spazi.


In alcuni casi speciali si può anche cambiare momentaneamente la 
variabile IFS:

http://goo.gl/dEkQU

saluti
gerlando

--
"Life is pretty simple: You do some stuff. Most fails. Some works. You do more
of what works. If it works big, others quickly copy it. Then you do something
else. The trick is the doing something else."
   < http://gerlos.altervista.org >
 gerlos  +- - - >  gnu/linux registred user #311588


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5478782d.8060...@gmail.com



[OT] name typo - [WAS]: Re: Modificare in massa i permessi : problema con file e dir con spazi e underscore

2014-11-25 Per discussione Gian Uberto Lauri
Lorenzo Sutton writes:
 > 
 > On 25/11/2014 12:55, Gian Uberto Lauri wrote:
 > > Lorenzo Sutton writes:
 > >
 > >   > La soluzione e il consiglio di Gian Umberto è il migliore. Può essere
 > >
 > > Perdonami, Uberto senza m :)
 > Pardon me. :)

Figurati, lo ha sbagliato pure chi non aveva necessità di scriverlo!
(è andato a correggerlo inserendo la m - si dice il peccato ma non il
peccatore)

-- 
Gian
   Friends will be friends
  right to the end!


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21620.28647.614071.532...@mail.eng.it



[OT] name typo - [WAS]: Re: Modificare in massa i permessi : problema con file e dir con spazi e underscore

2014-11-25 Per discussione Lorenzo Sutton


On 25/11/2014 12:55, Gian Uberto Lauri wrote:

Lorenzo Sutton writes:

  > La soluzione e il consiglio di Gian Umberto è il migliore. Può essere

Perdonami, Uberto senza m :)

Pardon me. :)


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54746e94.2040...@gmail.com



Re: Modificare in massa i permessi : problema con file e dir con spazi e underscore

2014-11-25 Per discussione Gian Uberto Lauri
Lorenzo Sutton writes:

 > La soluzione e il consiglio di Gian Umberto è il migliore. Può essere 

Perdonami, Uberto senza m :)

-- 
Gian
   Friends will be friends
  right to the end!


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21620.28192.554898.974...@mail.eng.it



Re: Modificare in massa i permessi : problema con file e dir con spazi e underscore

2014-11-25 Per discussione Lorenzo Sutton

On 24/11/2014 12:16, Gian Uberto Lauri wrote:

pac writes:

[...]

  > Per far questo ho tentato di utilizzare i seguenti comandi :
  > find percorsoincuicambiareipermessi -type f | xargs chmod 664 per

find path -type f -exec chmod 664 {} \;

  > find percorsoincuicambiareipermessi -type d | xargs chmod 775 per
  > modificare solo le directory

find path -type d -exec chmod 775 {} \;
  > Solo che in questo modo mi salta directory e file in cui ci sono degli
  > spazi

MAI usare gli spazi. Sono il separatore di token di default nella shell.

  >  underscore perchè legge solo il primo vocabolo e non a seguire

Gli underscore dovrebbero funzionare regolarissimamente.

La soluzione e il consiglio di Gian Umberto è il migliore. Può essere 
utile (visto anche il soggetto del messaggio) segnalare che con find e 
xargs se usi -print0 e -0 gli spazi vengono maneggiati correttamente.. 
Esempio:


find . -type f -print0 | xargs -0 chmod 664

Ciao
Lorenzo.


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/547469f0.4010...@gmail.com



Re: Modificare in massa i permessi : problema con file e dir con spazi e underscore

2014-11-24 Per discussione Cico


- Messaggio originale -

> Da: pac 
> A: debian 
> Cc: 
> Inviato: Lunedì 24 Novembre 2014 12:09
> Oggetto: Modificare in massa i permessi : problema con file e dir con spazi e 
> underscore
> 
> Vorrei modificare i permessi nella mia directory Documenti come segue
> Tutte le dir 775
> Tutti i file 664
> Per far questo ho tentato di utilizzare i seguenti comandi :
> find percorsoincuicambiareipermessi -type f | xargs chmod 664 per
> modificare solo i file
> find percorsoincuicambiareipermessi -type d | xargs chmod 775 per
> modificare solo le directory
> Solo che in questo modo mi salta directory e file in cui ci sono degli
> spazi o underscore perchè legge solo il primo vocabolo e non a seguire
> dopo lo spazio
> Come posso modificare questo script in modo tale che comprenda anche
> file e dir con spazi e underscore ?
> 

> 


Ciao,
Tempo fa avevo trovato in rete lo script qui sotto, che rinomina file 
ricorsivamente, inserendo underscore al posto dello spazio e mettendo tutte le 
lettere in minuscolo; magari ti torna utile.
Ovviamente puoi togliere la parte delle lettere; fai comunque delle prove 
prima, per vedere se fa al caso tuo.

Ciaociao :)


 - - -


#!/bin/bash
# Convert filenames to lowercase
# and replace characters recursively
#

if [ -z $1 ];then echo Give target directory; exit 0;fi

find "$1" -depth -name '*' | while read file ; do
directory=$(dirname "$file")
oldfilename=$(basename "$file")
#   newfilename=$(echo "$oldfilename" | tr 'A-Z' 'a-z' | tr ' ' '_' | sed 
's/_-_/-/g')
newfilename=$(echo "$oldfilename" | tr 'A-Z' 'a-z' | tr ' ' '_')
if [ "$oldfilename" != "$newfilename" ]; then
mv "$directory/$oldfilename" "$directory/$newfilename"
echo ""$directory/$oldfilename" ---> "$directory/$newfilename""
#echo "$directory"
#echo "$oldfilename"
#echo "$newfilename"
#echo
fi
done
exit 0


 - - -


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/947209617.165941.1416828717717.javamail.ya...@jws11160.mail.ir2.yahoo.com



Re: Modificare in massa i permessi : problema con file e dir con spazi e underscore

2014-11-24 Per discussione Gian Uberto Lauri
pac writes:
 > Vorrei modificare i permessi nella mia directory Documenti come segue
 > Tutte le dir 775
 > Tutti i file 664
 > Per far questo ho tentato di utilizzare i seguenti comandi :
 > find percorsoincuicambiareipermessi -type f | xargs chmod 664 per

find path -type f -exec chmod 664 {} \;

 > find percorsoincuicambiareipermessi -type d | xargs chmod 775 per
 > modificare solo le directory

find path -type d -exec chmod 775 {} \;


 > Solo che in questo modo mi salta directory e file in cui ci sono degli
 > spazi

MAI usare gli spazi. Sono il separatore di token di default nella shell.

 >  underscore perchè legge solo il primo vocabolo e non a seguire

Gli underscore dovrebbero funzionare regolarissimamente.

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21619.4993.290706.527...@mail.eng.it



Modificare in massa i permessi : problema con file e dir con spazi e underscore

2014-11-24 Per discussione pac
Vorrei modificare i permessi nella mia directory Documenti come segue
Tutte le dir 775
Tutti i file 664
Per far questo ho tentato di utilizzare i seguenti comandi :
find percorsoincuicambiareipermessi -type f | xargs chmod 664 per
modificare solo i file
find percorsoincuicambiareipermessi -type d | xargs chmod 775 per
modificare solo le directory
Solo che in questo modo mi salta directory e file in cui ci sono degli
spazi o underscore perchè legge solo il primo vocabolo e non a seguire
dopo lo spazio
Come posso modificare questo script in modo tale che comprenda anche
file e dir con spazi e underscore ?


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAHmhrxCPxwUdhz9UG=fwpebesfy4j1opvp4w2ho3vskow1h...@mail.gmail.com



[RISOLTO] Permessi esclusivi su partizioni

2014-03-27 Per discussione mauro pecchioli

Il 27/03/2014 09:18, Gian Uberto Lauri ha scritto:

Ci sarebbe anche l'opzione gid= per cambiare il gruppo.

Per settare i permessi sulla directory dovrebbe andarti bene l'opzione
dmask, una bitmask dove un bit a 01 indica un permesso _negato_,
ovvero 0 vale per tutto permesso a tutti, il default dovrebbe essere
0011 (completo per l'owner, niente scrittura per gli altri), 0017
dovrebbe fare al caso tuo.

Io darei un'occhiata a man mount.ntfs, l'opzione usermapping sembra
tanto carina...

Grazie per le dritte, alla fine, cerca cerca, ho trovato che 
uid=nomeutente,umask=077 messo nelle opzioni della riga della partizione 
risolve il problema di dare a me (proprietario) soltanto la possibilita' 
di aprire quella partizione, e blocca l'ospite dal farlo.


mauro

--
Mauro Pecchioli
Medico, Firenze
Sostieni la nuova legge antifumo a tutela dei minori:
http://tinyurl.com/qgobdzg


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5334935a.5050...@iol.it



Re: Permessi esclusivi su partizioni

2014-03-27 Per discussione Gian Uberto Lauri
mauro pecchioli writes:
 > Salve,
 > 
 > volendo condividere il pc con un utente "ospite", concedendogli solo 
 > permessi utente desktop e senza permessi di amministratore, ho 
 > necessita' di mettere permessi esclusivi su un disco Dati, /dev/sdb1, 
 > per l'appunto con fs ntfs.
 > 
 > Edito fstab, metto questa riga:
 > 
 > /dev/sdb1/media/Datintfs-3guid=mauro0 0

Ci sarebbe anche l'opzione gid= per cambiare il gruppo.

Per settare i permessi sulla directory dovrebbe andarti bene l'opzione
dmask, una bitmask dove un bit a 01 indica un permesso _negato_,
ovvero 0 vale per tutto permesso a tutti, il default dovrebbe essere
0011 (completo per l'owner, niente scrittura per gli altri), 0017
dovrebbe fare al caso tuo.

Io darei un'occhiata a man mount.ntfs, l'opzione usermapping sembra
tanto carina...

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21299.57051.990417.345...@mail.eng.it



Permessi esclusivi su partizioni

2014-03-26 Per discussione mauro pecchioli

Salve,

volendo condividere il pc con un utente "ospite", concedendogli solo 
permessi utente desktop e senza permessi di amministratore, ho 
necessita' di mettere permessi esclusivi su un disco Dati, /dev/sdb1, 
per l'appunto con fs ntfs.


Edito fstab, metto questa riga:

/dev/sdb1/media/Datintfs-3guid=mauro0 0

quindi riavvio come mauro, in terminale lancio "sudo caja" (mate) e apro 
la cartella /media, sulla quale apro "proprieta'" di sdb1.

Nella linguetta "permessi", trovo

proprietario: mauro (leggere e scrivere)
gruppo: root (leggere e scrivere, e non mi viene permesso di cambiare da 
root a mauro, resta root)
altri: (leggere e scrivere e non mi e' possibile inserire "nessuno", per 
impedire l'accesso al disco ad altri al di fuori di me e root)


Naturalmente, quando entro come "ospite", riesco a vedere la partizione 
Dati, quindi non ho raggiunto lo scopo che mi ero prefisso.


Un suggerimento per risolvere il problema? Forse una opzione nella riga 
di fstab?


Grazie per l'aiuto!

mauro pecchioli

--
Mauro Pecchioli
Medico, Firenze
Sostieni la nuova legge antifumo a tutela dei minori:
http://tinyurl.com/qgobdzg


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53335b95.4020...@iol.it



Re: Un bel problema con i permessi di udev...

2014-02-27 Per discussione Paolo

Il 27/02/2014 08:56, onetmt ha scritto:

Il 26/02/2014 22:05, Luana Spinetti ha scritto:


P.S. Se poi il problema non fosse creato da udev... non saprei davvero.


Inizia con l'escludere questa possibilita': dai una occhiata a fstab e
commenta eventuali direttive di mount che possano avere qualcosa a che
fare con questi.



Io ho risolto controllando fstab, installando il sistema da USB avevo 
delle righe relative all'USB, una volta commentato quelle tutto è andato 
a posto.


Ciao,

P.


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/530effe0.6080...@gmail.com



Re: Un bel problema con i permessi di udev...

2014-02-27 Per discussione Gian Uberto Lauri
Luana Spinetti writes:
 > Gentili utenti Debian,
 > 
 > già da parecchi mesi a questa parte mi trovo in difficoltà nella 
 > gestione dei miei hard disk esterni (che montano uno filesystem msdos, 
 > l'altro ntfs o fat32) e delle pennette USB a causa di udev che mi 
 > consente di creare ed eliminare file soltanto con l'accesso da root. 
 > Come utente normale riesco solo a leggere.

Non credo che sia udev poverino, lui  si limita a creare i device. Qui
mi  sa  che a  imballarsi  sono  i 'fantastici',  'moderni',  'comodi'
sistemi  di  mount automatico  tanto  cari  agli ut[]nti  ([]users  in
inglese).

Una soluzione è usare i vecchi cari tool, ad esempio il comando mount.

Peccato  che ci  si trovi  con file  system che  non sono  tutti posix
compliant (ntfs lo è, gli altri  no), in particolare le varie versioni
di fat non  hanno il concetto di utente proprietario  del file, quindi
Linux associa come proprietario l'utente che ha montato il device.

Quindi devi permettere ad un qualsiasi utente di montare il device, e
questo lo fai creando una riga in /etc/fstab per quel file system che
contenga user nella quarta colonna (le opzioni - vedi man fstab).

Problema, devi identificare univocamente i device e non è detto che ad
ogni reboot i nomi dei device  cambino (può contare anche l'ordine con
cui li colleghi al computer).

Per i file system fat, io per prima cosa userei mlabel o blkid per
etichettare i device in modo da essere sicuro che ad ogni bootstrap il
device abbia lo stesso nome. Non mi pare di aver visto tra le regole
di udev qualcosa che garantisca la persistenza dei nomi dei block
device usati per i file system.

Se invece assegni una label ai file system FAT, puoi crearti delle
righe in /etc/fstab di questo tipo dove identifichi il device per
label:

LABEL=TUX   /tuxvfatuser,noauto 0   0

Questo è un metodo sicuro per identificare i device. La stringa user
nella riga di fstab assegna i diritti di scrittura al solo utente che
ha montato il device.

Per ntfs il problema cambia. ntfs è un file system posix, quindi ha il
concetto  di  utente  proprietario  dei file.  E  se  l'identificativo
numerico coincide sotto Windows e sotto Linux...

Vedi la pagina (in inglese)

http://askubuntu.com/questions/11840/how-do-i-use-chmod-on-an-ntfs-or-fat32-partition
 

Siccome però il disco è esterno, ti conviene anche qui crearti una
riga del tipo

UUID=blablabla  /mount/point   ntfs-3g  opzioni

dove blablabla è l'output del comando blkid /dev/nomedeldevice

Lo so, non è il metodo più comodo e da ut[]nti, ma è quello che so indicarti
io :)

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21262.64771.718335.659...@mail.eng.it



Re: Un bel problema con i permessi di udev...

2014-02-27 Per discussione onetmt
Il 26/02/2014 22:05, Luana Spinetti ha scritto:
> Gentili utenti Debian,
> 
> già da parecchi mesi a questa parte mi trovo in difficoltà nella
> gestione dei miei hard disk esterni (che montano uno filesystem msdos,
> l'altro ntfs o fat32) e delle pennette USB a causa di udev che mi
> consente di creare ed eliminare file soltanto con l'accesso da root.
> Come utente normale riesco solo a leggere.
> 
> Non ho idea di cosa sia successo mesi fa, quando udev ha smesso di
> funzionare a dovere... e non ho le conoscenze necessarie ad individuare
> e risolvere il problema da sola.
> 
> Sapreste aiutarmi? O anche soltanto aiutarmi ad indagare sul problema?
> 
> Grazie!
> 
> Luana S.
> 
> P.S. Se poi il problema non fosse creato da udev... non saprei davvero.

Inizia con l'escludere questa possibilita': dai una occhiata a fstab e
commenta eventuali direttive di mount che possano avere qualcosa a che
fare con questi.

> 
> 


-- 
Hofstadter's Law:
"It always takes longer than you expect, even when you take into account
Hofstadter's Law."


-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/530eef94.9010...@gmail.com



Re: Un bel problema con i permessi di udev...

2014-02-26 Per discussione andrea biancalana
il giorno Wed, 26 Feb 2014 22:05:32 +0100  Luana Spinetti  ha 
scritto:

> Gentili utenti Debian,
> 
> già da parecchi mesi a questa parte mi trovo in difficoltà nella 
> gestione dei miei hard disk esterni (che montano uno filesystem msdos, 
> l'altro ntfs o fat32) e delle pennette USB a causa di udev che mi 
> consente di creare ed eliminare file soltanto con l'accesso da root. 
> Come utente normale riesco solo a leggere.
> 
> Non ho idea di cosa sia successo mesi fa, quando udev ha smesso di 
> funzionare a dovere... e non ho le conoscenze necessarie ad individuare 
> e risolvere il problema da sola.
> 
> Sapreste aiutarmi? O anche soltanto aiutarmi ad indagare sul problema?
> 
> Grazie!
> 
> Luana S.
> 
> P.S. Se poi il problema non fosse creato da udev... non saprei davvero.
> 

forse gli utenti devono appartenere al gruppo "plugdev". O sbaglio?


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140226232227.17656...@anbi.homelinux.org



Un bel problema con i permessi di udev...

2014-02-26 Per discussione Luana Spinetti

Gentili utenti Debian,

già da parecchi mesi a questa parte mi trovo in difficoltà nella 
gestione dei miei hard disk esterni (che montano uno filesystem msdos, 
l'altro ntfs o fat32) e delle pennette USB a causa di udev che mi 
consente di creare ed eliminare file soltanto con l'accesso da root. 
Come utente normale riesco solo a leggere.


Non ho idea di cosa sia successo mesi fa, quando udev ha smesso di 
funzionare a dovere... e non ho le conoscenze necessarie ad individuare 
e risolvere il problema da sola.


Sapreste aiutarmi? O anche soltanto aiutarmi ad indagare sul problema?

Grazie!

Luana S.

P.S. Se poi il problema non fosse creato da udev... non saprei davvero.


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/530e571c.1040...@n0tseo.com



Re: dischi usb e permessi [OT]

2014-01-13 Per discussione Gian Uberto Lauri
Federico Di Gregorio writes:
 > Non so se sia applicabile agli XTerm (credo si tratti più di PC con
 > tastiere/mouse/schede grafiche/monitor multipli) ma usando systemd per
 > fare multi-seat è possibile assegnare l'USB in maniera esclusiva ad una
 > postazione. Non è proprio la prenotazione che si auspica
 > Gian Uberto Lauri ma ci andiamo abbastanza vicino.

Grazie, me lo guardo subito!
 
Ed effettivamente ci si può lavorare sopra!

Il sistema di prenotazione dovrebbe solo vedere se la porta è libera
(ovvero non in uso e assegnata a seat 0, che supponiamo dedicata al
supervisore di laboratorio) e quindi cambiare la configurazione. Alla
scadenza della prenotazione/liberazione, si ripristina l'assegnazione
a seat0.

Probabilmente ci se la può cavare coi link simbolici (io gestisco in
questo modo le configurazioni multiple della scheda di rete del
portatile).

Chapeau, Federico! Gran bella segnalazione!

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21204.5916.74826.578...@mail.eng.it



Re: dischi usb e permessi

2014-01-13 Per discussione Dario

Il 13/01/2014 16:47, Gian Uberto Lauri ha scritto:

Dario writes:

  > quindi quale soluzione proponi in alternativa?:-)

Oltre  ad una  che  non gradiresti,  trovandola  dolorisissima:),  ti
invito a leggere il  trhead, la ho postata altrove e  non ho voglia di
riscriverla.


non è importante quello che io gradisca o no. A proposito posso
aggiungere che amo il terminale.

Rileggendo i tuoi vari commenti, ho trovato quanto di seguito:


O più correttamente, che sia indicato "user" tra le opzioni.
Io ho messo questo in /etc/fstab

#USB sticks
LABEL=TUX   /tuxvfatuser,noauto 0   0
LABEL=PANDA /panda  vfatuser,noauto 0   0

ed in  questo modo  con mount  /tux o  mount /panda  monto le  mie due


altro messaggio:


La soluzione  è mettere una  label al device, e  per i device  vfat il
tool da  usare è mlabel  di mtools. Io ho  fatto così per  le pennette
PANDA e TUX.
Direi che dando una label alla penna USB, e indicando in /etc/fstab

LABEL=TUX   /tuxvfatuid=gid=1000,noauto 0   0

automount monterà la penna con i permessi giusti.


altro messaggio:


Prevedere una serie di /dev/sd?1 per le varie possibili penne non
partizionate e mettere 'user' in /etc/fstab.
Oppure usare sudo come Il Grande Bit comanda? Script montapenna e
smontapenna (magari con iconcina sul desktop) che permettono a tua
moglie di fare mount.  Questo potrebbe introdurre quel pizzico di
intelligenza che manca alla soluzione precedente.


altro:

potrei già aver inserito le regole in fstab per
limitare il lavoro a udev (che si limita a creare il device) e quindi
una mount basterebbe.


però hai detto anche:

 > Gian Uberto Lauri suggerisce di mettere 'user' tra le opzioni
 > di fstab per tutte le possibili penne presenti contemporaneamente
 > come /dev/sd?1, con possibilità di fare anche link simbolici
 > per renderli più facili da ricordare.

Alla peggio. Non è praticissima come soluzione.



 > Dice anche che "non dovrebbe
 > essere una gran noce scrivere un programma che generi le entry
 > per lo fstab noto il numero di porte USB che si pensa di utilizzare
 > per le penne usb."

Ocio:  funziona  solo  con  penne  che  hanno  una  certa  determinata
configurazione delle partizioni e file system. Come ho detto è una ultima
spiaggia e nemmeno troppo comoda.


Aiutami Gian Uberto a capire ti prego :-( abbi pazienza.

Dario> Stiamo perdendo il punto "domanda-problema" "risposta-soluzione".
Dario> Stiamo parlando che "utente X che usa sistema con DE necessita 
che il

Dario> mount delle chiavette non avvenga tramite root".

Gian Uberto Lauri> Questa è una limitazione locale a te. Mi spiace per i 
tuoi limiti.


No, non c'entra nulla con la mia situazione/limitazione.
Stai suggerendo a chi ha fatto la richiesta iniziale di fare a meno
dell'utilizzo di DE?


Dario


--- OT 


2) La UE  ha stanziato un tot  di migliaia di euro su  un progetto per
vedere  se  c'erano tecniche  software  (oltre  che hardware)  per  la
riduzione dei  consumi di corrente.  Dopo aver visto tutto  quello che
hanno fatto la  mia opinione è ancora quella che  col software l'unico
modo  di risparmiare  corrente "non  usare più  risorse di  quelle che
servono".


Link alla ricerca ? Io ho trovato questo, ma è molto generico [1]


-- Link --
[1]
http://europa.eu/pol/ener/index_it.htm



--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d4142d.9030...@gmail.com



Re: dischi usb e permessi [OT]

2014-01-13 Per discussione Dario

Il 13/01/2014 17:01, Federico Di Gregorio ha scritto:

Non so se sia applicabile agli XTerm (credo si tratti più di PC con
tastiere/mouse/schede grafiche/monitor multipli) ma usando systemd per
fare multi-seat è possibile assegnare l'USB in maniera esclusiva ad una
postazione. Non è proprio la prenotazione che si auspica
Gian Uberto Lauri ma ci andiamo abbastanza vicino.

http://www.freedesktop.org/wiki/Software/systemd/multiseat/

federico



systemd integra udev ... :-D

Dario


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d413e7.3070...@gmail.com



Re: dischi usb e permessi [OT]

2014-01-13 Per discussione Federico Di Gregorio
Non so se sia applicabile agli XTerm (credo si tratti più di PC con
tastiere/mouse/schede grafiche/monitor multipli) ma usando systemd per
fare multi-seat è possibile assegnare l'USB in maniera esclusiva ad una
postazione. Non è proprio la prenotazione che si auspica
Gian Uberto Lauri ma ci andiamo abbastanza vicino.

http://www.freedesktop.org/wiki/Software/systemd/multiseat/

federico

-- 
Federico Di Gregorio federico.digrego...@dndg.it
Di Nunzio & Di Gregorio srl   http://dndg.it
  We should forget about small efficiencies, say about 97% of the
   time: premature optimization is the root of all evil.-- D.E.Knuth


-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d40de2.3060...@dndg.it



Re: dischi usb e permessi

2014-01-13 Per discussione Federico Di Gregorio
On 13/01/2014 16:42, Gian Uberto Lauri wrote:
> Federico Di Gregorio writes:
> 
>  > Scusa, mi spieghi come fa un utente che NON è "davanti alle console di
>  > sistema" ad infilare una chiavetta in una porta USB? E` collegato da
>  > remoto con telecinesi-ssh?
> 
> Xterminal o analoghi con server nella stessa stanza.
> 
>  > E` inutile. Se l'utente è davanti al computer e può prenotare una porta,
>  > tanto vale usare qualsiasi porta libera.
> 
> Non proprio. Scenario: aula didattica economica con un terminal server
> e vari xterminal (la cosa che ho descritto a Piviul nella e-mail
> precedente).
> 
> Sono sul banco X del laboratorio  didattico. Ho bisogno di montare una
> penna su cui ci sono dei dati che non voglio che gli altri vedano.

E` vero ma in questo caso la sessione non è corrente. La sessione
corrente per GNOME è quella attaccata allo stesso hardware su cui c'è la
porta USB.

In questo secondo caso sono d'accordo che un meccanismo diverso permette
sicuramente una gestione migliore ed in sicurezza del mount/umount di
dispositivi rimuovibili.

federico

-- 
Federico Di Gregorio federico.digrego...@dndg.it
Di Nunzio & Di Gregorio srl   http://dndg.it
Bhoe, bhe, bhe. Sono brutto e cattivo. Brutto lama! -- Cuzco


-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d40c3c.7080...@dndg.it



Re: dischi usb e permessi [OT]

2014-01-13 Per discussione Dario

Il 13/01/2014 16:52, Gian Uberto Lauri ha scritto:

Dario writes:
  > Gian Uberto, posso darti un consiglio di . aggiornarti un pò
  > sui prezzi/disponibilità dell'hardware recente?

Sto pensando  a paesi meno  benestanti di  noi (forse ancora  per poco
visto la picchiata in cui ci siamo tuffati con l'economia :))


Emmm  i paesi meno benestanti fra pochissimi mesi potrebbero
anche superarci  (se non lo hanno già fatto IMHO).

Dario


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d40da1.7070...@gmail.com



Re: dischi usb e permessi [OT]

2014-01-13 Per discussione Dario

Il 13/01/2014 16:37, Gian Uberto Lauri ha scritto:

Bene o male il mio portatile aziendale - se non dovessi farci partire
tomcat, eclipse e chromium (sopratutto quest'ultimo) potrebbe gestire
3/4 sessioni su cui degli studenti si possono esercitare a
programmare.


chiedo venia per l'OT, ma a questo punto prova a giocherellare
con JBOSS :-9.

Agli studenti può bastare utilizzare il proprio smartphone per 
programmare, come potenza intendo... (a comodità display ridotto

e tastiera non sono i migliori). Fare un giro per le scuole
oggi potrebbe dare un'idea migliore delle risorse disponibili
che hanno già.

Dario


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d40d05.4030...@gmail.com



Re: dischi usb e permessi

2014-01-13 Per discussione Gian Uberto Lauri
Dario writes:
 > Gian Uberto, posso darti un consiglio di . aggiornarti un pò
 > sui prezzi/disponibilità dell'hardware recente?

Sto pensando  a paesi meno  benestanti di  noi (forse ancora  per poco
visto la picchiata in cui ci siamo tuffati con l'economia :))

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21204.3002.32119.844...@mail.eng.it



Re: dischi usb e permessi

2014-01-13 Per discussione Gian Uberto Lauri
Marco Bertorello writes:

 > Beh, potrebbe star usando il sistema remotamente, tipo LTSP.
 > Ora non ricordo di preciso, è molto che non metto mano a LTSP, ma se
 > non sbaglio era possibile infilare la chiavetta nel thin (o fat)
 > client e vedersela montata sul server, come se fosse in locale. Questo
 > già 4 o 5 anni fa, sempre che la mia famosa memoria non faccia cilecca
 > ;)

Anche questa  è una  soluzione, parli in  pratica di  virtualizzare il
device via rete?

Dove trovo un link? Lo si può usare anche con sistemi eterogenei?

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21204.2914.223700.855...@mail.eng.it



Re: dischi usb e permessi

2014-01-13 Per discussione Dario

Il 13/01/2014 16:42, Gian Uberto Lauri ha scritto:

Federico Di Gregorio writes:

  > Scusa, mi spieghi come fa un utente che NON è "davanti alle console di
  > sistema" ad infilare una chiavetta in una porta USB? E` collegato da
  > remoto con telecinesi-ssh?

Xterminal o analoghi con server nella stessa stanza.

  > E` inutile. Se l'utente è davanti al computer e può prenotare una porta,
  > tanto vale usare qualsiasi porta libera.

Non proprio. Scenario: aula didattica economica con un terminal server
e vari xterminal (la cosa che ho descritto a Piviul nella e-mail
precedente).

Sono sul banco X del laboratorio  didattico. Ho bisogno di montare una
penna su cui ci sono dei dati che non voglio che gli altri vedano.

Se non ho modo di "prenotare" la porta, nel tempo in cui vado dal banco
al server e torno, qualcun'altro può montare la penna.

Credo che, visti i fondi disponibili, la cosa potrebbe tornare utile
anche alla scuola pubblica italiana e non solo a quelle a sud del
Mediterraneo...


Gian Uberto, posso darti un consiglio di . aggiornarti un pò
sui prezzi/disponibilità dell'hardware recente?

Nel campo informatico sono cambiate diverse cose, gli scenari di cui
parli me li ricordo una 20ina di anni fa, dove era anche raro che
si facesse uso di penne USB, visto che costavano.

Dario


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d40ad5.70...@gmail.com



Re: dischi usb e permessi

2014-01-13 Per discussione Gian Uberto Lauri
Dario writes:

 > quindi quale soluzione proponi in alternativa? :-)

Oltre  ad una  che  non gradiresti,  trovandola  dolorisissima :),  ti
invito a leggere il  trhead, la ho postata altrove e  non ho voglia di
riscriverla.

 > Dario> centellinare la memoria "RAM" occupata ?.. :-|, stiamo parlando
 > Gian Uberto Lauri> Certi scenari portano una macchina con 8GB ad usare 
 > il 90% o più del core:

1) peccato che più di 8 non ne possa mettere

2) La UE  ha stanziato un tot  di migliaia di euro su  un progetto per
vedere  se  c'erano tecniche  software  (oltre  che hardware)  per  la
riduzione dei  consumi di corrente.  Dopo aver visto tutto  quello che
hanno fatto la  mia opinione è ancora quella che  col software l'unico
modo  di risparmiare  corrente "non  usare più  risorse di  quelle che
servono".

 > Stiamo perdendo il punto "domanda-problema" "risposta-soluzione".
 > Stiamo parlando che "utente X che usa sistema con DE necessita che il 
 > mount delle chiavette non avvenga tramite root".

Questa è una limitazione locale a te. Mi spiace per i tuoi limiti.



-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21204.2734.46498.494...@mail.eng.it



Re: dischi usb e permessi

2014-01-13 Per discussione Gian Uberto Lauri
Federico Di Gregorio writes:

 > Scusa, mi spieghi come fa un utente che NON è "davanti alle console di
 > sistema" ad infilare una chiavetta in una porta USB? E` collegato da
 > remoto con telecinesi-ssh?

Xterminal o analoghi con server nella stessa stanza.

 > E` inutile. Se l'utente è davanti al computer e può prenotare una porta,
 > tanto vale usare qualsiasi porta libera.

Non proprio. Scenario: aula didattica economica con un terminal server
e vari xterminal (la cosa che ho descritto a Piviul nella e-mail
precedente).

Sono sul banco X del laboratorio  didattico. Ho bisogno di montare una
penna su cui ci sono dei dati che non voglio che gli altri vedano.

Se non ho modo di "prenotare" la porta, nel tempo in cui vado dal banco
al server e torno, qualcun'altro può montare la penna.

Credo che, visti i fondi disponibili, la cosa potrebbe tornare utile
anche alla scuola pubblica italiana e non solo a quelle a sud del
Mediterraneo...

[Nota storica:  temporibus illis, siccome  non c'era modo  di bloccare
l'accesso  di altri  ad  un floppy  -  cui si  accedeva  con mtools  -
qualcuno si fregò  la scansione della lettera della  mia ragazza, cosa
che non gradii per nulla]

-- 
Gian
   Friends will be friends
  right to the end!


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21204.2432.836971.979...@mail.eng.it



Re: dischi usb e permessi

2014-01-13 Per discussione Gian Uberto Lauri
Piviul writes:
 > Gian Uberto Lauri scrisse in data 13/01/2014 15:56:
 > > [...]
 > > Ci  possono essere  scenari legittimi  in cui  su una  stessa macchina
 > > possono lavorare in più  di uno e tutti e due  devono avere il diritto
 > > di montare il device, non solo quello davanti alle console di sistema,
 > > se non 'rovini' la multiutenza.
 > ad esempio? Probabilmente sono uno gnomo anch'io ma non mi viene in 
 > mente un pc con appiccicati 2 monitor e 2 tastiere.

Quella che cito è una configurazione "da poareti", e credo che una cosa
del genere non si usi più nei paesi benestanti.

Faccio riferimento  all'uso degli xterminal  (che sono cose  fisiche e
non il programma xterm).

Per quanto siano enie piaghen, sopratutto se sono troppi, possono
essere una soluzione economica laddove puoi avere a disposizione (a
poco prezzo o gratis) macchine vecchiotte ma con una risoluzione video
sufficiente e quindi usi tutte le risorse finanziarie per un server
carrozzato il meglio possibile.

Anni fa li vidi citati ad esempio da associazioni che raccoglievano HW
sufficientemente valido per l'invio in Africa.

Bene o male il mio portatile aziendale - se non dovessi farci partire
tomcat, eclipse e chromium (sopratutto quest'ultimo) potrebbe gestire
3/4 sessioni su cui degli studenti si possono esercitare a
programmare.

E se vi pare lento vi mando a lavorare su un 3B2 200 con 8 terminali
:)

Link:

http://unikant.gianoziaorientale.org/moin.fcg/DscPinguinoIJPiccolini

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21204.2110.650883.760...@mail.eng.it



Re: dischi usb e permessi

2014-01-13 Per discussione Dario

Il 13/01/2014 16:02, Federico Di Gregorio ha scritto:

Scusa, mi spieghi come fa un utente che NON è "davanti alle console di
sistema" ad infilare una chiavetta in una porta USB? E` collegato da
remoto con telecinesi-ssh?


emm .. [1]


>Il meccanismo andrebbe ripensato per venire incontro a queste situazioni.
>
>Ne butto una:  il sistema mostra tutte le porte  usb libere, un utente
>ne prenota una, infila la chiavetta e la monta. Ci sono sufficienti
>algoritmi sulle prenotazioni per creare qualcosa di decente:).



E` inutile. Se l'utente è davanti al computer e può prenotare una porta,
tanto vale usare qualsiasi porta libera.


"inutile" potrebbe essere soggettivo.
Volendo potrei stabilire che le porte pari/dispari
possano essere utilizzate come le targhe alterne,
in base ai livello di polveri sottili nel reparto IT.

Una battuta, mi raccomando senza nessuna intenzione di offendere 
nessuno, e se fosse mi scusi da subito.


Dario

-- Link --
[1] https://en.wikipedia.org/wiki/The_Tomorrow_People


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d4074f.9060...@gmail.com



Re: dischi usb e permessi

2014-01-13 Per discussione Dario

Il 13/01/2014 14:35, Gian Uberto Lauri ha scritto:

Dario writes:

  > Gian Uberto Lauri suggerisce di mettere 'user' tra le opzioni
  > di fstab per tutte le possibili penne presenti contemporaneamente
  > come /dev/sd?1, con possibilità di fare anche link simbolici
  > per renderli più facili da ricordare.

Alla peggio. Non è praticissima come soluzione.


quindi quale soluzione proponi in alternativa? :-)


"non dovrebbe
essere una gran noce scrivere un programma che generi le entry
per lo fstab noto il numero di porte USB che si pensa di utilizzare
per le penne usb."


Ocio:  funziona  solo  con  penne  che  hanno  una  certa  determinata
configurazione delle partizioni e file system. Come ho detto è una ultima
spiaggia e nemmeno troppo comoda.


quindi quale soluzione alternativa proponi? :-)


  > > Riguardo udev [pmount etc..] Gian Uberto Lauri dice che:
  > > ..Se hanno la flessibilità della ghisa sono tool scadenti.  ..
  > > Credo che udev si limiti solo a segnalare al sistema che esiste il
  > > device.
  > > Peraltro, proprio la dinamicità di udev rende non banale la creazione
  > > di script per risolvere questo scenario: inserisco la penna, lancio
  > > uno script (che monta la penna, fa ad esempio un backup, smonta la
  > > penna).
  > > Se affronti quotidianamente quello scenario, lo script ti fa tanto comodo.

Gli script proposti non sono leggerissimi e richiedono 3 fork() + exec().
La cosa può diventare pesante con una macchina carica se i dischi sono, come
spesso capita nel mondo consumer, delle lumache.


mmm.. puoi fare un esempio di script proposto?

Dario> centellinare la memoria "RAM" occupata ?.. :-|, stiamo parlando
Gian Uberto Lauri> Certi scenari portano una macchina con 8GB ad usare 
il 90% o più del core:


certo, come in altri scenari avere solo 8GB ci faccio le patatine,
visto che come minimo me ne servono 16GB  come anche avere un solo
processore, come anche la dimensione del filesystem e tante altre cose..

Stiamo perdendo il punto "domanda-problema" "risposta-soluzione".
Stiamo parlando che "utente X che usa sistema con DE necessita che il 
mount delle chiavette non avvenga tramite root".


In questo caso, si presume che la macchina dell'utente funzioni 
egregiamente con il DE scelto, udev è presente ed installato ed in 
funzione. Ma c'è il problema segnalato dall'utente (rifarsi al messaggio 
iniziale di questo thread).


Dario> Se capita arrivare spesso a page fault, forse è il caso di fare una
Dario> bella chiacchierata con l'IT e valutare la sostituzione della 
macchina

Dario> con qualcosa di più adeguato alle esigenze.

Gian Uberto Lauri> Ma davvero? Non ti riporto la risposta che ebbi 
quando la macchina di cui
Gian Uberto Lauri> sopra ne aveva solo 4 e come si è arrivati ad 8 te lo 
lascio indovinare.


budget limitato o prassi aziendale?
Più correttamente dovrei chiederti a quanto tempo fa risale la richiesta
di aumentare la RAM :-). Se mi parli di una 10ina o 20ina di anni fa
posso capire i nasi storti.
Oggi un modulo ram ha costi veramente irrisori, o meglio non è puntando 
lì che si risparmia sul budget.

Con questo però non dico di sperperare memoria, visto che c'è.


(ma un tempo per mandare un uomo sulla luna bastava la potenza di
un VIC20)

Era un qualcosa di più... Diciamo che erano meno potenti di un 486.


c'è da dire anche [1]

Dario> In aggiunta, nemmeno OSX lo fa ed in Debian non mi è mai capitato.
Dario> (Naturalmente ognuno è libero di configurare il sistema anche per
Dario> farsi del male).

Gian Uberto Lauri> Ne parla chi usa kde. Io  li ho evitati 
accuratamente. Mi sono accorto
Gian Uberto Lauri> di quanto rompono dopo averne messo uno di debug in 
uno script.


quì parlavamo di "Un popup, sopratutto se modale, è una finestra 
potenzialmente rompiscatole. ... prende il focus".


Certo che se stai configurando un sw e attivi script con popup di debug,
tutto dipende da come "te" realizzi la cosa.

Questo esula dal discorso dei popup che appaiono nell'inserimento di una
chiavetta usb. Se ho capito male, puoi farmi un esempio di script che
crea lo scempio (IMHO)?


  > Domande:
  > 1) L'attuale udev è flessibile come la ghisa ?

Mai detto che udev non è flessibile. E sono sufficientemente sicuro di
non aver espresso male la cosa. Non assolutamente, ma sufficientemente.


mm rileggiti la mail che hai spedito in lista.
Forse ti sei espresso male allora.


In ogni caso c'è stato un tempo in cui udev non era così sveglio come
oggi e fortunatamente le tecniche di allora vanno ancora bene (label
sui device, sono vagamente più mnemonici di un blockID).


appunto, un tempo udev era.
Oggi per la problematica oggetto di questo thread, cosa proporresti?



  > 2) Dove è che hanno smarrito la retta via gli sviluppatori di udev?
  > 2b) per non parlare di tutti quei *pazzi* che l'hanno adottato?
  > 2c) visto che basterebbe farsi un semplice script per utilizzare al
  > meglio fstab?
  > 3) Alla fine è più agevole *non usare udev*, ma usare *bene* fstab ?

Re: dischi usb e permessi

2014-01-13 Per discussione Federico Di Gregorio
On 13/01/2014 15:56, Gian Uberto Lauri wrote:
> Federico Di Gregorio writes:
>  > 1) udev rileva l'inserimento della chiavetta e spara un messaggio
>  >su dbus.
> 
> Lo immaginavo, grazie di averlo confermato.
>  
>  > Se sulla macchina ci sono 2 o più sessioni solo quella di frontend
>  > esegue il mount (quindi è possibile avere + utenti collegati e sempre e
>  > solo 1 alla volta monta la chiavetta USB).
> 
> Questo è un comportamento che a me  non piace per nulla, è valido solo
> nel caso di  un utente per macchina.  Quelli di Gnome se  le cercano a
> volte le battutacce sui loro nomi :).
> 
> Ci  possono essere  scenari legittimi  in cui  su una  stessa macchina
> possono lavorare in più  di uno e tutti e due  devono avere il diritto
> di montare il device, non solo quello davanti alle console di sistema,
> se non 'rovini' la multiutenza.

Scusa, mi spieghi come fa un utente che NON è "davanti alle console di
sistema" ad infilare una chiavetta in una porta USB? E` collegato da
remoto con telecinesi-ssh?

> Il meccanismo andrebbe ripensato per venire incontro a queste situazioni.
> 
> Ne butto una:  il sistema mostra tutte le porte  usb libere, un utente
> ne prenota una, infila la chiavetta e la monta. Ci sono sufficienti
> algoritmi sulle prenotazioni per creare qualcosa di decente :).

E` inutile. Se l'utente è davanti al computer e può prenotare una porta,
tanto vale usare qualsiasi porta libera.

-- 
Federico Di Gregorio federico.digrego...@dndg.it
Di Nunzio & Di Gregorio srl   http://dndg.it
Bhoe, bhe, bhe. Sono brutto e cattivo. Brutto lama! -- Cuzco


-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d40008.7060...@dndg.it



Re: dischi usb e permessi

2014-01-13 Per discussione Piviul

Gian Uberto Lauri scrisse in data 13/01/2014 15:56:

[...]
Ci  possono essere  scenari legittimi  in cui  su una  stessa macchina
possono lavorare in più  di uno e tutti e due  devono avere il diritto
di montare il device, non solo quello davanti alle console di sistema,
se non 'rovini' la multiutenza.
ad esempio? Probabilmente sono uno gnomo anch'io ma non mi viene in 
mente un pc con appiccicati 2 monitor e 2 tastiere. Mi ricordo tempo fa 
che qualcuno vendeva schede PCI con per poter condividere lo stesso PC 
con 2 postazioni diverse ma se non mi ricordo male è sempre stato meno 
conveniente acquistare un secondo PC che acquistare una di quelle 
schede... Se quindi non ti riferisci ad una eventualità del genere uno 
dei 2 utenti si collega in remoto e direi che è difficile per un utente 
inserire un pendrive remotamente...


Ma probabilmente ti riferisci a qualcosa che non conosco.

Piviul



--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d401d0.7060...@riminilug.it



Re: dischi usb e permessi

2014-01-13 Per discussione Gian Uberto Lauri
Federico Di Gregorio writes:
 > 1) udev rileva l'inserimento della chiavetta e spara un messaggio
 >su dbus.

Lo immaginavo, grazie di averlo confermato.
 
 > Se sulla macchina ci sono 2 o più sessioni solo quella di frontend
 > esegue il mount (quindi è possibile avere + utenti collegati e sempre e
 > solo 1 alla volta monta la chiavetta USB).

Questo è un comportamento che a me  non piace per nulla, è valido solo
nel caso di  un utente per macchina.  Quelli di Gnome se  le cercano a
volte le battutacce sui loro nomi :).

Ci  possono essere  scenari legittimi  in cui  su una  stessa macchina
possono lavorare in più  di uno e tutti e due  devono avere il diritto
di montare il device, non solo quello davanti alle console di sistema,
se non 'rovini' la multiutenza.

Il meccanismo andrebbe ripensato per venire incontro a queste situazioni.

Ne butto una:  il sistema mostra tutte le porte  usb libere, un utente
ne prenota una, infila la chiavetta e la monta. Ci sono sufficienti
algoritmi sulle prenotazioni per creare qualcosa di decente :).

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21203.65210.411828.23...@mail.eng.it



Re: dischi usb e permessi

2014-01-13 Per discussione Federico Di Gregorio
On 13/01/2014 14:08, Dario wrote:
> 
> Domande:
> 1) L'attuale udev è flessibile come la ghisa ?
> 2) Dove è che hanno smarrito la retta via gli sviluppatori di udev?
> 2b) per non parlare di tutti quei *pazzi* che l'hanno adottato?
> 2c) visto che basterebbe farsi un semplice script per utilizzare al
> meglio fstab?
> 3) Alla fine è più agevole *non usare udev*, ma usare *bene* fstab ?
> 
> Ricordo che stiamo parlando di: computer utente con DE[3], quindi
> non stiamo parlando di ambiente server senza DE[3], sistema embed, etc.
> E stiamo sempre parlando di: non voglio venga montata la chiavetta usb
> con permessi root, ma con i permessi dell'utente. Voglio una soluzione
> semplice.
> 
> 
> Buon pranzo ed inizio settimana.

Ammetto che non ho seguito questo thread dall'inizio quindi
probabilmente mi sono perso qualcosa ma su di una macchina desktop con
Gnome 3 in configurazione standard tutto funziona benissimo:

1) udev rileva l'inserimento della chiavetta e spara un messaggio
   su dbus.

2) gnome (meglio, un demone che viene fatto partire nella sessione
   utente di gnome) riceve il messaggio su dbus e *se la sessione è
   quella di frontend e l'utente ne ha i permessi* manda un messaggio
   su dbus a udisks2.

3) udisks2 monta il volume su /media// (ovviamente la
   directory che viene creata dentro a /media/ è di proprietà
   dell'utente corretto.

Se sulla macchina ci sono 2 o più sessioni solo quella di frontend
esegue il mount (quindi è possibile avere + utenti collegati e sempre e
solo 1 alla volta monta la chiavetta USB).


federico

-- 
Federico Di Gregorio federico.digrego...@dndg.it
Di Nunzio & Di Gregorio srl   http://dndg.it
 But not all bugs are an interesting challenge. Some are just a total
  waste of my time, which usually is much more valuable than the time of
  the submitter.   -- Md


-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d3f84a.5070...@dndg.it



Re: dischi usb e permessi

2014-01-13 Per discussione Gian Uberto Lauri
Dario writes:

 > Gian Uberto Lauri suggerisce di mettere 'user' tra le opzioni
 > di fstab per tutte le possibili penne presenti contemporaneamente
 > come /dev/sd?1, con possibilità di fare anche link simbolici
 > per renderli più facili da ricordare.

Alla peggio. Non è praticissima come soluzione.

 > Dice anche che "non dovrebbe
 > essere una gran noce scrivere un programma che generi le entry
 > per lo fstab noto il numero di porte USB che si pensa di utilizzare
 > per le penne usb."

Ocio:  funziona  solo  con  penne  che  hanno  una  certa  determinata
configurazione delle partizioni e file system. Come ho detto è una ultima
spiaggia e nemmeno troppo comoda.

 > > Riguardo udev [pmount etc..] Gian Uberto Lauri dice che:
 > > ..Se hanno la flessibilità della ghisa sono tool scadenti.  ..
 > > Credo che udev si limiti solo a segnalare al sistema che esiste il
 > > device.
 > > Peraltro, proprio la dinamicità di udev rende non banale la creazione
 > > di script per risolvere questo scenario: inserisco la penna, lancio
 > > uno script (che monta la penna, fa ad esempio un backup, smonta la
 > > penna).
 > > Se affronti quotidianamente quello scenario, lo script ti fa tanto comodo.

Gli script proposti non sono leggerissimi e richiedono 3 fork() + exec().
La cosa può diventare pesante con una macchina carica se i dischi sono, come
spesso capita nel mondo consumer, delle lumache.

 > Poi ancora Gian Uberto Lauri dice che:
 > > comodità/scomodità: se non erro udev lancia un segnale su dbus ...
 > > [cut]...udev è magrolino e ti serve se vuoi avere i device rimovibili,
 > > comunque 780k residenti e qualcosa più di tremila virtuali li usa.
 > >
 > > Ci sta tutto che in quei 780 k ci sia tutto l'insieme di pagine che
 > > gli bastano per reagire all'inserimento della penna.
 > >
 > > Ma se aggiungiamo dbus abbiamo circa un'altro mega di resident memory
 > > in uso (sette mega virtuali)
 > >
 > > Aggiungiamo poi lo spazio per il file manager, magari grafico, e
 > > macchine come la mia in ufficio, cariche di tool di sviluppo, servlet
 > > container e chromium, rischiano di andare incontro a 'fastidiosi' page
 > > fault (il fastidio dipende dal numero e da quanto è lento il disco).
 > 
 > centellinare la memoria "RAM" occupata ?.. :-|, stiamo parlando

Certi scenari portano una macchina con 8GB ad usare il 90% o più del core:

KiB Mem:   7992416 total,  7211092 used,   781324 free,   323468 buffers

 > Se capita arrivare spesso a page fault, forse è il caso di fare una
 > bella chiacchierata con l'IT e valutare la sostituzione della macchina
 > con qualcosa di più adeguato alle esigenze.

Ma davvero? Non ti riporto la risposta che ebbi quando la macchina di cui
sopra ne aveva solo 4 e come si è arrivati ad 8 te lo lascio indovinare.

 > (ma un tempo per mandare un uomo sulla luna bastava la potenza di
 > un VIC20)

Era un qualcosa di più... Diciamo che erano meno potenti di un 486.
 
 > In aggiunta, nemmeno OSX lo fa ed in Debian non mi è mai capitato.
 > (Naturalmente ognuno è libero di configurare il sistema anche per
 > farsi del male).

Ne parla chi usa kde. Io  li ho evitati accuratamente. Mi sono accorto
di quanto rompono dopo averne messo uno di debug in uno script.

 > Domande:
 > 1) L'attuale udev è flessibile come la ghisa ?

Mai detto che udev non è flessibile. E sono sufficientemente sicuro di
non aver espresso male la cosa. Non assolutamente, ma sufficientemente.

In ogni caso c'è stato un tempo in cui udev non era così sveglio come
oggi e fortunatamente le tecniche di allora vanno ancora bene (label
sui device, sono vagamente più mnemonici di un blockID).

 > 2) Dove è che hanno smarrito la retta via gli sviluppatori di udev?
 > 2b) per non parlare di tutti quei *pazzi* che l'hanno adottato?
 > 2c) visto che basterebbe farsi un semplice script per utilizzare al
 > meglio fstab?
 > 3) Alla fine è più agevole *non usare udev*, ma usare *bene* fstab ?

Scusa, ma hai digerito tutti i post insieme con un risotto con funghi un
pelo esotici?

 > Ricordo che stiamo parlando di: computer utente con DE[3]

Ma perché servirebbe a tutti un DE sul desktop? 

E il discorso era principalmente "certe soluzioni non sono fatte bene"
(o sono fatte da cani, come citato in un'altra mail del thread) e
possono arrivare a facilitare il danneggiamento dell'utente o l'abuso
delle risorse dell'utente per arrecare danno a terzi.

(Che oltretutto si basa su un modello di qualche decina di anni fa, la
prima macchina consumer con un DE la ho vista nel 1984/1985).

fre-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
Per REVOCARE l'iscrizione alla lista, inviare u

Re: dischi usb e permessi

2014-01-13 Per discussione Dario

Il 13/01/2014 08:44, Gian Uberto Lauri ha scritto:

Gollum1 writes:
  > Se anche c'è stato forse qualche fraintendimento, ho apprezzato molto la
  > discussione.

I fraintendimenti che ho causato io sono dovuti alla fretta e alla
poca attenzione nello scrivere, spero di essere comunque riuscito a
chiarirli.

E confrontarsi è sempre utile.


Sottoscrivo e approfitto per ringraziare tutti quelli che hanno 
partecipato a questo thread.


Tralasciando le opinioni/preferenze di ognuno, sono rimasto
incuriosito dal discorso udev e fstab. Visto i commenti che
sono stati fatti, mi farebbe piacere avere qualche chiarimento,
approfittando dell'ora di pranzo (ricreazione).

Messaggio prolisso, leggasi se si ha voglia/tempo.

Premessa, stavamo parlando di:

Il 09/01/2014 05:19, piv...@riminilug.it ha scritto:

Ciao a tutti, debian jessie. Se inserisco un disco
usb non viene montato correttamente: il filesystem
viene montato con owner root invece che con l'utente.
Ad esempio se inserisco un pen drive in fat viene
montato in /dev/usb0 e questi sono i permessi:

$ ls -ld /media/usb0
drwxr-xr-x 3 root root 4096 gen 1 1970 /media/usb0

[cut] Oppure su un disco usb in ntfs ..
$ ls -ld /media/usb0
drwxrwxrwx 1 root root 4096 dic 26 16:57 /media/usb0

Se però inserisco prima un disco usb, il secondo viene
montato con i permessi giusti. Questo è lo stralcio
dell'output di mount inserendo prima un pendrive in
vfat (e montato in /dev/usb0), poi un disco usb in
ntfs (e montato correttamente nello spazio utente):

/dev/sdb1 on /media/usb0 type vfat
(rw,nosuid,nodev,noexec,relatime,fmask=0022,dmask=0022,
codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro)

/dev/sdc1 on /media/antonella/Argentino type fuseblk
(rw,nosuid,nodev,relatime,user_id=0,group_id=0,
default_permissions,allow_other,blksize=4096)


dalla richiesta di Piviul evinco che:
non voglio venga montata la chiavetta usb con permessi root,
ma con i permessi dell'utente. Voglio una soluzione semplice.

Vediamo 

Wikipedia: fstab [1]

I sistemi Linux moderni usano udev come automounter
per montare i device a caldo invece di riscrivere al
volo il fstab. I programmi come pmount permettono
agli utenti non root di montare e smontare i filesystem
senza una corrispondente voce nel fstab; le versioni
tradizionali di Unix hanno sempre permesso agli utenti
con sufficienti privilegi di montare o smontare i device
senza una voce fstab.


Wikipedia: udev [2]

A differenza dei tradizionali sistemi Unix, dove i
dispositivi a blocchi o a caratteri sono rappresentati
da un insieme statico di file in /dev, udev permette
di gestire dinamicamente la creazione (o rimozione) di
questi file speciali, mantenendo solo i nodi relativi
ai dispositivi presenti nel sistema.

Udev, rispetto al predecessore devfs, presenta alcuni
vantaggi [udev sostituisce l'obsoleto devfs]:

* supporta l'assegnazione persistente dei nomi dei device,
anche quando essi sono collegati in ordine o posizione
differente;
* viene eseguito interamente in spazio utente, di
conseguenza i criteri per l'assegnazione dei nomi vengono
definiti al di fuori del kernel;
* devfs, a differenza di udev, mantiene la struttura dati
relativa ai dispositivi nello spazio di memoria persistente
del kernel; questo spazio di memoria non è swappabile.


[Nella citazione le parentesi quadre sono una mia aggiunta]

Riporto in forma sintetica alcune osservazioni fatte:

Gian Uberto Lauri suggerisce di mettere 'user' tra le opzioni
di fstab per tutte le possibili penne presenti contemporaneamente
come /dev/sd?1, con possibilità di fare anche link simbolici
per renderli più facili da ricordare. Dice anche che "non dovrebbe
essere una gran noce scrivere un programma che generi le entry
per lo fstab noto il numero di porte USB che si pensa di utilizzare
per le penne usb."

Gerlos si chiede: Ma perché pasticciare fstab, che è per le cose
permanenti e non cose provvisorie come le pendrive, quando udev
è stato inventato anche e soprattutto per questi scopi?

Gollum1 si chiede "ma perché mi devo dannare l'anima "
[visto che c'è udev]. Poi aggiunge: " fstab io lo lascio per le
cose che rimangono sempre inserite o per le condivisioni di rete
che voglio permettere sia fatto da parte di tutti gli utenti senza
continuare a montare e smontare."

Riguardo udev [pmount etc..] Gian Uberto Lauri dice che:

..Se hanno la flessibilità della ghisa sono tool scadenti.  ..
Credo che udev si limiti solo a segnalare al sistema che esiste il
device.
Peraltro, proprio la dinamicità di udev rende non banale la creazione
di script per risolvere questo scenario: inserisco la penna, lancio
uno script (che monta la penna, fa ad esempio un backup, smonta la
penna).
Se affronti quotidianamente quello scenario, lo script ti fa tanto comodo.


Poi ancora Gian Uberto Lauri dice che:

comodità/scomodità: se non erro udev lancia un segnale su dbus ...
[cut]...udev è m

Re: dischi usb e permessi

2014-01-13 Per discussione Gian Uberto Lauri
Davide G. writes:

 > alla fine non è possibile senza ricompilare il pacchetto perché sono scritte
 > nel codice (vergognoso!)

Mai stato più felice di avere /bin/bash come file manager :)
O al più dired di Emacs :)

-- 
Gian
   Friends will be friends
  right to the end!


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21203.58211.643114.394...@mail.eng.it



Re: dischi usb e permessi

2014-01-13 Per discussione Davide G.
Il 12/01/2014 21:20, Gian Uberto Lauri ha scritto:
> Credo che udev si limiti solo a segnalare al sistema che esiste il
> device.

Mi intrometto per dire che se non sbaglio (su mate e probabilmente gnome) il
montaggio viene lanciato dal file manager (nautilus, caja) tramite il comando
"gvfs-mount -d". L'avevo scoperto perché volevo cambiare le opzioni di mount ma
alla fine non è possibile senza ricompilare il pacchetto perché sono scritte
nel codice (vergognoso!)

Ciao

-- 
Davide


-- 
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d3dc0e.60...@gmail.com



Re: dischi usb e permessi

2014-01-12 Per discussione Gian Uberto Lauri
Gollum1 writes:
 > Se anche c'è stato forse qualche fraintendimento, ho apprezzato molto la
 > discussione.

I fraintendimenti che ho causato io sono dovuti alla fretta e alla
poca attenzione nello scrivere, spero di essere comunque riuscito a
chiarirli.

E confrontarsi è sempre utile.

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21203.39249.74406.561...@mail.eng.it



Re: dischi usb e permessi

2014-01-12 Per discussione Gollum1
Il 12/gen/2014 21:57 "Gian Uberto Lauri"  ha
scritto:
>
> Quoting Gollum1
>
>>> Bene o male tutte le macchine hanno un numero finito di porte USB, e
>>> già per le classiche penne USB non partizionate e formattate con vfat
>>> mettere 'user' tra le opzioni di fstab per tutte le possibili penne
>>> presenti contemporaneamente come /dev/sd?1. Si possono peraltro fare
>>> dei link simbolici ai device per renderli più facili da ricordare.
>>
>>
>> è già ben oltre alle possibilità della maggior parte degli utenti.
>
>
> Volontà inficiata dalla pigrizia direi, non possibilità. Sapere cosa
> fare è diverso da sapere cosa accade.

Sicuramente una certa dose di pigrizia... Ma c'è anche quella persona che
per certi versi è "costretta" a fare certe operazioni con il computer, ma
del computer in se non ne vuole sapere nulla... Nel tempo ne ho conosciute
diverse di queste persone...
>
>
> Prova a prendere due penne, A e B. Monta le penne nel medesimo posto
> qualsiasi sia l'ordine in cui le metti?
>
>

Sì, provato personalmente... Se la Pennetta ha una label viene sempre
montata in /media/utente/label/ altrimenti in /media/utente/ID/ dove ID è
un identificatore univoco e sempre associato alla stessa chiavetta (deve
essere legata a qualcosa nell'HW della chiavetta stessa, perché ho lo
stesso identificatore di macchine diverse)

Non sono sicuro che sia assegnato sempre lo stesso device, ma se ti basi
sul mount point, allora è fisso.

>
> Forse di Unity. Windows ha rilegato il desktop in un angolo.
>

Infatti non sopporto W8, ne tantomeno GNOME. Forse mi sarò troppo
fossilizzato sul mio KDE, ma mi trovo comodo così, come trovo comodo
lavorare direttamente sul terminale per tante operazioni.

>>> Per la facilità di uso hanno già messo a repentaglio la sicurezza e
>>> non una volta sola.
>>
>>
>> in linux non dovrebbe succedere, fino a che le interfacce saranno solo
>> interfacce, ma il sistema viene amministrato esclusivamente nel
>> kernel,
>
>
> No, non solo quello. Vedi i problemi coi file .desktop .
>
> Tutto in user space.
>
>

Mi informerò più nel dettaglio...

>>
>
> No, mi riferivo al tuo atteggiamento sulla multiutenza. Ho compreso
> che, a causa di una mia cattiva formulazione del testo, eri
> probabilmente ancora fumino.
>

Hahaha :) no... Non lo ero...

> Ma dalle tue parole, se non sono scritte male, si evince che dato che
> a te non serve molto la multiutenza, allora quella serve poco a tutti.
>

Assolutamente... Ritengo invece che la possibilità di una reale
multiutenza, come quella che è in grado di fornire linux, sia una risorsa
molto importante e spesso sottovalutata.

Il mio computer è spesso con entrambi gli utenti (mio e di mia moglie)
loggati, e nell'arco della giornata, chi si siede attiva il proprio (F7 o
F8), chi mette la password e continua quello che sta facendo... Si che
questo non è forse quello che intendi tu per multi utenza, ma se il
computer è uno solo, non ne vedo altri di possibili.

>
>> e poi... pure nelle tua firma di indichi come "integralista"... :P
>
>
> Il termine Integralista GNUslamico se non ricordo male venne in mente
> al mio capo a metà anni '90, ma non riferito a me. A quell'epoca
> compresi bene quale era il messaggio di Stallman leggendo - e
> traducendo - il manifesto.
>
>

In certe occasioni hanno dato  dell'integralista anche a me...

>> mi piace il "coltivatore diretto di software", auguri di buon raccolto
>
>
> Su questa meglio non parli su come l'ho pensata...

Se anche c'è stato forse qualche fraintendimento, ho apprezzato molto la
discussione.

;)

byez
-- 
Gollum1
tesssoro… dov'è il mio tesssoro?


Re: dischi usb e permessi

2014-01-12 Per discussione Gian Uberto Lauri

Quoting gerlos :

Ma perché pasticciare fstab, che è per le cose permanenti e non cose  
provvisorie come le pendrive, quando udev è stato inventato anche e  
soprattutto per questi scopi?


Ma chi lo ha detto

fstab è ovviamente nato quando di rimovibile c'erano solo i media, le
penne USB sono sia medium che drive.

Perché usare nomi anonimi per i punti di mount (tipo /mnt/usb oppure  
/mnt/sd1), quando esistono da sempre i label delle partizioni?  
(parlo di montare la mia pendrive in /media/gerlos/miapendrive)


Infatti non lo faccio.

Dai, se proprio volete farvi uno script per automontare un disco,  
almeno usate udev: guardate gli esempi in questa pagina, pienamente  
applicabili a Debian Wheezy:

https://wiki.archlinux.org/index.php/Udev_%28Italiano%29#Mount_automatico_delle_periferiche_USB



Agganci a udev una mount. Non è una cosa leggerissima quella che gli
fai fare. Anzi, sono due fork() + exec per lanciare delle shell...
Anzi 3 perché c'è la pipe su blkid.

Lasciate che udev faccia quello per cui è pensato principalmente.

O per aggiungere una riga ad fstab per permettere il montaggio  
manuale da un utente normale. ;-)


Questa ha un pericolo. Vediamo se ci arrivi da solo :)

Oltre al fatto che potrei già aver inserito le regole in fstab per
limitare il lavoro a udev (che si limita a creare il device) e quindi
una mount basterebbe.

Io dopo essermi stancato di fare sempre le cose a mano, mi sono  
fatto uno script chiamato tramite alcune regole di udev in modo che  
quando collego uno specifico HD esterno al mio “muletto”, accada che:



Preferisco lanciare lo script a mano per essere informato di cosa può
essere andato storto. Peraltro, vedo che raramente la gestione delle
situazioni anomale è fatta sensatamente...

Che poi fare queste cose usando udev credo che sia proprio  
l’approccio dei DE moderni…


Credo che operino in modo leggermente diverso. Si fanno segnalare via
dbus l'avvenuta creazione del device.

--
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/   e coltivatore diretto   not install
   di software   Debian"


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140112215858.1656503ybad6y...@webmail.eng.it



Re: dischi usb e permessi

2014-01-12 Per discussione Gian Uberto Lauri

Quoting Gollum1 :


ed è un sistema che mi pare corretto sia nella singola utenza, che
nella multi utenza, e senza far dannare l'utente che conosce poco o
nulla di informatica.


È accettabile come modo di fare.


Bene o male tutte le macchine hanno un numero finito di porte USB, e
già per le classiche penne USB non partizionate e formattate con vfat
mettere 'user' tra le opzioni di fstab per tutte le possibili penne
presenti contemporaneamente come /dev/sd?1. Si possono peraltro fare
dei link simbolici ai device per renderli più facili da ricordare.


è già ben oltre alle possibilità della maggior parte degli utenti.


Volontà inficiata dalla pigrizia direi, non possibilità. Sapere cosa
fare è diverso da sapere cosa accade.


Non dovrebbe essere una gran noce scrivere un programma che
generli le entry per lo fstab noto il numero di porte USB che si
pensa di utilizzare per le penne usb.


ma perché mi devo dannare l'anima, che già qualsiasi periferica mi
viene riconosciuta con un nome univoco, montato sempre nello stesso
posto (un posto creato dinamicamente con il nome univoco dell'utente
che lo monta e con il nome univoco della periferica)?


Prova a prendere due penne, A e B. Monta le penne nel medesimo posto
qualsiasi sia l'ordine in cui le connetti?


Questo non permette ancora di sapere che il file system contenuto
nella tal penna comparirà in un ben determinato posto, che dipende
dall'ordine di inserimento, cosa che o rende non banale fare degli
script per automatizzare operazioni che coinvolgano il contenuto di
una certa penna usb oppure ti impone di seguire sempre quell'ordine di
inserimento dei device (motivo per cui ho scelto di mettere le
label agli sticks con vfat e uso lvm per gli hd rimovibili).


ripeto... le periferiche sono riconosciute e identificate con un ID
univoco, quindi hanno sempre lo stesso nome, e sono montate sempre
nello stesso posto (dallo stesso utente).



Se il nome è quello della periferica, sei sicuro che udev assegni
sempre quella periferica indipendentemente da quante e dall'ordine in
cui le hai inserite?


concordo anche sul fatto che analizzando il primo, in quello che "lo
copia" i problemi di sicurezza dovrebbero essere risolti, e credo che
tutto sommato in linux la cosa sia abbastanza vicina alla realtà... si
è presa l'impronta di quello che è il modo visuale, ma il modo
operativo è totalmente differente, anzi... ora pare che sia winzoz
alla rincorsa...


Forse di Unity. Windows ha rilegato il desktop in un angolo.


Per la facilità di uso hanno già messo a repentaglio la sicurezza e
non una volta sola.


in linux non dovrebbe succedere, fino a che le interfacce saranno solo
interfacce, ma il sistema viene amministrato esclusivamente nel
kernel,


No, non solo quello. Vedi i problemi coi file .desktop .

Tutto in user space.


Le GTK mi piacciono come modello di programmazione, non sei costretto
ad usare il C++ - che non mi piace -


neppure con le QT sei obbligato ad usare per forza il C++, io uso le
QT con python.


Le GTK sono in C e le API base sono in C.


Unix è multiutenza... embhe... che me ne frega? io sto usando il mio
computer a casa, non me ne frega nulla che virtualmente ci si possano
connettere ed usarne le risorse chissà quanti utenti


Non lo so, a me me ne frega che dove non ci sono molti soldi una sola
macchina permetta comunque a più persone di lavorare e/o imparare.




No, mi riferivo al tuo atteggiamento sulla multiutenza. Ho compreso
che, a causa di una mia cattiva formulazione del testo, eri
probabilmente ancora fumino.

Ma dalle tue parole, se non sono scritte male, si evince che dato che
a te non serve molto la multiutenza, allora quella serve poco a tutti.


e poi... pure nelle tua firma di indichi come "integralista"... :P


Il termine Integralista GNUslamico se non ricordo male venne in mente
al mio capo a metà anni '90, ma non riferito a me. A quell'epoca
compresi bene quale era il messaggio di Stallman leggendo - e
traducendo - il manifesto.


mi piace il "coltivatore diretto di software", auguri di buon raccolto


Su questa meglio non parli su come l'ho pensata...

--
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/   e coltivatore diretto   not install
   di software   Debian"


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140112214111.19262pvij2d5q...@webmail.eng.it



Re: dischi usb e permessi

2014-01-12 Per discussione Gian Uberto Lauri

Quoting gerlos :


Scusate, mi sono perso anche io.

Anni fa queste cose le facevo anche io a mano, o con script più o  
meno esoterici, e condivido l’entusiasmo di alcuni nell’inventare da  
capo soluzioni ad uno dei problemi più vecchi dell'informatica. :-)


Usare mount correttamente non è reinventare nulla, solo usare
correttamente un tool.

Solo che oggi esistono già sistemi eccellenti per montare dischi  
esterni in modo più o meno automatico (pmount, udev, ...),  
soprattutto se uno sta usando un ambiente desktop.


Eccellenti solo se ti va bene come si comportano. Se hanno la
flessibilità della ghisa sono tool scadenti.


sistema… (io darei anche un’occhiata alle regole di udev).


Credo che udev si limiti solo a segnalare al sistema che esiste il
device.

Peraltro, proprio la dinamicità di udev rende non banale la creazione
di script per risolvere questo scenario: inserisco la penna, lancio
uno script (che monta la penna, fa ad esempio un backup, smonta la
penna).

Se affronti quotidianamente quello scenario, lo script ti fa tanto comodo.

Se ho appena collegato una pendrive ad un sistema desktop mi  
aspetto, anzi, pretendo, che il mio sistema faccia qualcosa:  
automonti la pendrive, mi mostri una finestra del file manager,  
insomma, mi mostri una notifica. Insomma, l’ho collegata ed  
evidentemente voglio farci qualcosa!


Questi sono i tuoi desiderata. Altra gente può avere desiderata ben
diversi dai tuoi. E non si tratta di seghe mentali, ma di
comodità/scomodità: se non erro udev lancia un segnale su dbus che
viene ricevuto da eventuali applicazioni in ascolto, tipicamente il
file manager.

udev è magrolino e ti serve se vuoi avere i device rimovibili,
comunque 780k residenti e qualcosa più di tremila virtuali li usa.

Ci sta tutto che in quei 780 k ci sia tutto l'insieme di pagine che
gli bastano per reagire all'inserimento della penna.

Ma se aggiungiamo dbus abbiamo circa un'altro mega di resident memory
in uso (sette mega virtuali)

Aggiungiamo poi lo spazio per il file manager, magari grafico, e
macchine come la mia in ufficio, cariche di tool di sviluppo, servlet
container e chromium, rischiano di andare incontro a 'fastidiosi' page
fault (il fastidio dipende dal numero e da quanto è lento il disco).

Il fatto che vi preoccupate di un popup "che potrebbe disturbare” mi  
fa venire il dubbio che il sistema in oggetto non sia un desktop  
“normale”...


Un popup, sopratutto se modale, è una finestra potenzialmente
rompiscatole. Vero che se hai appena inserito una penna USB non stai
con molta probabilità lavorando su una certa finestra e quindi ti
importa poco che perda il focus, ma non è garantito che sia così per
tutti gli scenari. Lasciare all'utente la scelta è sempre l'opzione
migliore.


--
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/   e coltivatore diretto   not install
   di software   Debian"




--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140112212024.499871f67j291...@webmail.eng.it



Re: dischi usb e permessi

2014-01-12 Per discussione gerlos

Il giorno 12/gen/2014, alle ore 14:50, Gollum1  ha 
scritto:

> Il 12 gennaio 2014 12:34, Gian Uberto Lauri 
> ha scritto:
>> 
>> L'errore è nell'accettare una soluzione 'facile' ma intrinsecamente
>> non coretta sia per questioni di sicurezza sia di creazione
>> dell'interfaccia.
>> 
> 

[CUT]

> Quindi che cosa c'é che non va? quali sarebbero i problemi di
> sicurezza? perché è sbagliato questa semi automatizzazione?

Credo che si riferisse all’auto mount dei dischi. L’approccio di default di KDE 
(che notifica la possibilità di montare un disco, ma non lo monta) non credo 
possa creare problemi di sicurezza. 
Almeno, non a livello di macchine desktop (e a chi evocava stuxnet ricordo che 
era pur sempre un worm per Windows, e che io sappia -smentitemi- non c’è nulla 
del genere che colpisca il nostro pinguino e che si propaghi tramite pendrive 
usb).

> 
>> Non dovrebbe essere una gran noce scrivere un programma che
>> generli le entry per lo fstab noto il numero di porte USB che si
>> pensa di utilizzare per le penne usb.
> 
> ma perché mi devo dannare l'anima, che già qualsiasi periferica mi
> viene riconosciuta con un nome univoco, montato sempre nello stesso
> posto (un posto creato dinamicamente con il nome univoco dell'utente
> che lo monta e con il nome univoco della periferica)?
> 
> fstab io lo lascio per le cose che rimangono sempre inserite o per le
> condivisioni di rete che voglio permettere sia fatto da parte di tutti
> gli utenti senza continuare a montare e smontare.

Ma perché pasticciare fstab, che è per le cose permanenti e non cose 
provvisorie come le pendrive, quando udev è stato inventato anche e soprattutto 
per questi scopi?

Perché usare nomi anonimi per i punti di mount (tipo /mnt/usb oppure /mnt/sd1), 
quando esistono da sempre i label delle partizioni? (parlo di montare la mia 
pendrive in /media/gerlos/miapendrive)

Dai, se proprio volete farvi uno script per automontare un disco, almeno usate 
udev: guardate gli esempi in questa pagina, pienamente applicabili a Debian 
Wheezy:
https://wiki.archlinux.org/index.php/Udev_%28Italiano%29#Mount_automatico_delle_periferiche_USB

Ovviamente gli esempi trattano di mount automatico, ma possono essere 
modificati facilmente per “preparare tutto” e montare il disco in un secondo 
tempo, manualmente. 
O per aggiungere una riga ad fstab per permettere il montaggio manuale da un 
utente normale. ;-)

Io dopo essermi stancato di fare sempre le cose a mano, mi sono fatto uno 
script chiamato tramite alcune regole di udev in modo che quando collego uno 
specifico HD esterno al mio “muletto”, accada che:
- il disco viene montato in uno specifico percorso
- rsync si avvia, e fa un mirror sull’HD esterno dei dati in una dir del 
muletto 
- al termine di rsync, il disco viene smontato

Che poi fare queste cose usando udev credo che sia proprio l’approccio dei DE 
moderni… 

saluti
gerlos


--
"Life is pretty simple: You do some stuff. Most fails. Some works. You do more
of what works. If it works big, others quickly copy it. Then you do something
else. The trick is the doing something else."
   < http://gerlos.altervista.org >
 gerlos  +- - - >  gnu/linux registred user #311588


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5807279d-7f11-49d8-834f-e3e1e0217...@gmail.com



Re: dischi usb e permessi

2014-01-12 Per discussione Gollum1
Il 12 gennaio 2014 12:34, Gian Uberto Lauri 
ha scritto:
>
> L'errore è nell'accettare una soluzione 'facile' ma intrinsecamente
> non coretta sia per questioni di sicurezza sia di creazione
> dell'interfaccia.
>

sinceramente io non vedo cosa ci sia di scorretto, sia dal punto di
vista della facilità d'uso e della sicurezza sul modo di operare per
l'uso delle periferiche usb di debian.

come già detto uso KDE e la mia macchina è una unstable, quando
inserisco una periferica di massa nell'usb appare un popup dalla tray
icon che mi avverte che è stato inserito un dispositivo, non monta
nulla, non avviene null'altro e dopo qualche secondo il popup si
chiude da solo.

a questo punto basta un click nella tray icon per riaprire il
"notificatore di dispositivi", selezionando il dispositivo mi da una
serie di operazioni che posso eseguire (se è un cd posso anche
riprodurlo senza montarlo, un DVD gli posso dire di visualizzarmelo
con vlc, una macchina fotografica posso vedere direttamente le foto o
attivare un programma che mi scarichi le foto in una posizione
prestabilita), ma nulla è eseguito se non lo scelgo esplicitamente. Se
è una pendrive, e e gli dico di montarla, questa viene montata (e
identificata univocamente) in una posizione ben precisa, in
/media/nome utente/identificativo periferica/ e viene montata con i
permessi solo per quell'utente, qualsiasi altro utente non ha
l'accesso a questa risorsa e non può neppure smontarla (ho verificato,
quindi so di cosa sto parlando).

Quindi che cosa c'é che non va? quali sarebbero i problemi di
sicurezza? perché è sbagliato questa semi automatizzazione?

ed è un sistema che mi pare corretto sia nella singola utenza, che
nella multi utenza, e senza far dannare l'utente che conosce poco o
nulla di informatica.

> Bene o male tutte le macchine hanno un numero finito di porte USB, e
> già per le classiche penne USB non partizionate e formattate con vfat
> mettere 'user' tra le opzioni di fstab per tutte le possibili penne
> presenti contemporaneamente come /dev/sd?1. Si possono peraltro fare
> dei link simbolici ai device per renderli più facili da ricordare.

è già ben oltre alle possibilità della maggior parte degli utenti.

> Non dovrebbe essere una gran noce scrivere un programma che
> generli le entry per lo fstab noto il numero di porte USB che si
> pensa di utilizzare per le penne usb.

ma perché mi devo dannare l'anima, che già qualsiasi periferica mi
viene riconosciuta con un nome univoco, montato sempre nello stesso
posto (un posto creato dinamicamente con il nome univoco dell'utente
che lo monta e con il nome univoco della periferica)?

fstab io lo lascio per le cose che rimangono sempre inserite o per le
condivisioni di rete che voglio permettere sia fatto da parte di tutti
gli utenti senza continuare a montare e smontare.

> Questo non permette ancora di sapere che il file system contenuto
> nella tal penna comparirà in un ben determinato posto, che dipende
> dall'ordine di inserimento, cosa che o rende non banale fare degli
> script per automatizzare operazioni che coinvolgano il contenuto di
> una certa penna usb oppure ti impone di seguire sempre quell'ordine di
> inserimento dei device (motivo per cui ho scelto di mettere le
> label agli sticks con vfat e uso lvm per gli hd rimovibili).

ripeto... le periferiche sono riconosciute e identificate con un ID
univoco, quindi hanno sempre lo stesso nome, e sono montate sempre
nello stesso posto (dallo stesso utente).

> Sarebbe una solutione (sempre subottima) un tool inattivo per default
> - ma facilmente attivabile se installato - che permetta nei casi in
> cui c'è sempre e solo un utente collegato di attuare gli automatismi
> che l'utente desidera siano attuati, ad esempio ti mostro solo il
> device inattivo (poi tu lo attivi-monti), ti mostro un poput e monto,
> oppure monto in automatico (pericoloso).

è così infatti, con la differenza che hanno scelto di non fare il
mount automatico, ma sempre e solo il popup e lasciare il device
inattivo fino alla scelta dell'utente.

Ricordiamoci poi che solitamente le periferiche montate sono sempre
montate con i permessi che non permettono l'esecuzione di programmi
e/o script sulla periferica stessa, quindi non vedo che problemi ci
siano per la sicurezza...


>> Qui mi trovi invece parzialmente concorde... ma questo non vuol dire
>> che almeno in alcune cose winzoz e questi DE siano delle immonde
>> schifezze...
>
>
> Nel momento in cui un programma espone ad un pericolo (di recare
> danni a se o altri - ricordare che c'è anche questa di possibilità)
> questo programma è fatto male.

concordo

> Nel momento in cui un programma lo
> imita anche nei comportamenti scorretti è forse fatto ancora peggio
> oppure denota un

Re: dischi usb e permessi

2014-01-12 Per discussione Gian Uberto Lauri

Quoting Gollum1 :


Il 10 gennaio 2014 16:01, Gian Uberto Lauri  ha scritto:

Gollum1 writes:
 > Il 10 gennaio 2014 14:27, Gian Uberto Lauri  ha scritto:
 > > Gollum1 writes:
 > >  > perché se si usa linux bisogna sempre fare le cose più difficili del
 > >  > necessario?
 > >
 > > Perché  è  il modo  migliore  di  lavorare.
 >
 > su questo ho i miei dubbi.

Lo immaginavo, ma sei in una posizione non corretta.


ecco... in questa frase c'é molta arroganza...

Non puoi arrogarti il diritto di venire a dire che io sbaglio perché
ho un'idea diversa e metto in dubbio una tua idea...


Errore mio nell'esprimermi.

L'errore è nell'accettare una soluzione 'facile' ma intrinsecamente
non coretta sia per questioni di sicurezza sia di creazione
dell'interfaccia.

Bene o male tutte le macchine hanno un numero finito di porte USB, e
già per le classiche penne USB non partizionate e formattate con vfat
mettere 'user' tra le opzioni di fstab per tutte le possibili penne
presenti contemporaneamente come /dev/sd?1. Si possono peraltro fare
dei link simbolici ai device per renderli più facili da ricordare.

Non dovrebbe essere una gran noce scrivere un programma che
generli le entry per lo fstab noto il numero di porte USB che si
pensa di utilizzare per le penne usb.

Questo non permette ancora di sapere che il file system contenuto
nella tal penna comparirà in un ben determinato posto, che dipende
dall'ordine di inserimento, cosa che o rende non banale fare degli
script per automatizzare operazioni che coinvolgano il contenuto di
una certa penna usb oppure ti impone di seguire sempre quell'ordine di
inserimento dei device (motivo per cui ho scelto di mettere le
label agli sticks con vfat e uso lvm per gli hd rimovibili).

Sarebbe una solutione (sempre subottima) un tool inattivo per default
- ma facilmente attivabile se installato - che permetta nei casi in
cui c'è sempre e solo un utente collegato di attuare gli automatismi
che l'utente desidera siano attuati, ad esempio ti mostro solo il
device inattivo (poi tu lo attivi-monti), ti mostro un poput e monto,
oppure monto in automatico (pericoloso).



Qui mi trovi invece parzialmente concorde... ma questo non vuol dire
che almeno in alcune cose winzoz e questi DE siano delle immonde
schifezze...


Nel momento in cui un programma espone ad un pericolo (di recare
danni a se o altri - ricordare che c'è anche questa di possibilità)
questo programma è fatto male. Nel momento in cui un programma lo
imita anche nei comportamenti scorretti è forse fatto ancora peggio
oppure denota un male ancora più subdolo del primo programma, una
specie di 'multilazione mentale' indotta negli utenti che non riescono
più a vederne i difetti.


tutto sta nel capire che cosa si deve dare ad un utente
desktop, dobbiamo parlare di sistemi alla portata di tutti, che entri
in un ambiente casalingo e/o lavorativo con certi standard di
sicurezza, di affidabilità e di facilità d'uso...


Per la facilità di uso hanno già messo a repentaglio la sicurezza e
non una volta sola.


(BTW, le  QT sono  simili come impostazioni  alle MFC,  gli preferisco
 ancora le GTK nonostante tenga Gnome a distanza).


su questo non mi pronuncio, con KDE e le QT mi trovo tutto sommato
bene, ma non l'ho sposato, se dovessi trovare qualcosa che mi desse
maggior soddisfazione sarei felice di cambiare. Per esempio, non
sopporto per nulla Gnome, ho sempre odiato l'arroganza degli
sviluppatori di Gnome, che si prendono il diritto di dirmi come devo
per forza gestire e/o vedere le cose, almeno KDE mi propone quello che
per lui dovrebbe essere il suo standard, ma posso in qualsiasi
momento, e senza cose troppo astruse, decidere cosa voglio in realtà.
Mi lascia molto più spazio di azione rispetto a Gnome.


Su questo siamo in pieno accordo.

Le GTK mi piacciono come modello di programmazione, non sei costretto
ad usare il C++ - che non mi piace -


 > > Una è stata  definita "follia da camicia di forza"  in un libro edito
 > > da Microsoft Press.
 >
 > curiosità: quale era questa follia?

Dispatchment degli eventi ai thread.  In pratica tu potevi impedire ad
applicazione di sapere che volevano chiuderla.


[--- tagliato ---]



Ci hanno messo una decina di anni a sistemare la cosa.


bhe... ci hanno messo molto di più a sistemare altri bug,


La cosa 'terribile' è che quel bug lo vedevi subito sulla carta, non
era un problema subdolo che richiede di analizzare il codice e
verificare se effettivamente c'è una idiozia.


 > > Avevo trovato la descrizione di "implementazione di prova" di un virus
 > > per  GNU/Linux  che   usava  che  usava  la   debolezza  descritta  in
 > > http://lists.freedesktop.org/pipermail/xdg/2006-April/006379.html .
 > >
 > > Era una  implementazione macchinosa, ma  si può fare di  meglio, molto
 > > meglio.
 > >
 > > A parer mio invece di montare in automatico la penna sarebbe molto più
 > > sensato rendere  facile il montaggio  della penna agli utenti:
 >
 > io non ho mai parlato di montaggio automatico... co

Re: dischi usb e permessi

2014-01-11 Per discussione Gollum1
Il 10 gennaio 2014 16:01, Gian Uberto Lauri  ha scritto:
> Gollum1 writes:
>  > Il 10 gennaio 2014 14:27, Gian Uberto Lauri  ha scritto:
>  > > Gollum1 writes:
>  > >  > perché se si usa linux bisogna sempre fare le cose più difficili del
>  > >  > necessario?
>  > >
>  > > Perché  è  il modo  migliore  di  lavorare.
>  >
>  > su questo ho i miei dubbi.
>
> Lo immaginavo, ma sei in una posizione non corretta.

ecco... in questa frase c'é molta arroganza...

Non puoi arrogarti il diritto di venire a dire che io sbaglio perché
ho un'idea diversa e metto in dubbio una tua idea... Io rispetto la
tua idea, tu devi rispettare la mia... se poi si fa una discussione
pacata, sono anche pronto a cambiare la mia idea, se le argomentazioni
sono convincenti, ma se l'argomentazione inizia con "tu sbagli" mi
salgono i fumi alle orecchie (ne sa qualcosa un mio collega, con cui
mi sono scontrato in ambito religioso, perché ho deciso di non
battezzare mia figlia, in quanto non credo più nella chiesa, la sua
prima frase è stato "tu sbagli"... sti cazzi... ops... scusate)... ;P

>
>  > bhe... che winzoz mi stia sugli zebedei non è un mistero (sopratutto 8.x).
>
> Ma intanto sia KDE che Gnome sono progetti di inseguimento, e inseguno
> ANCORA Windows nonostante gli annunci.

Qui mi trovi invece parzialmente concorde... ma questo non vuol dire
che almeno in alcune cose winzoz e questi DE siano delle immonde
schifezze... tutto sta nel capire che cosa si deve dare ad un utente
desktop, dobbiamo parlare di sistemi alla portata di tutti, che entri
in un ambiente casalingo e/o lavorativo con certi standard di
sicurezza, di affidabilità e di facilità d'uso...

> (BTW, le  QT sono  simili come impostazioni  alle MFC,  gli preferisco
>  ancora le GTK nonostante tenga Gnome a distanza).

su questo non mi pronuncio, con KDE e le QT mi trovo tutto sommato
bene, ma non l'ho sposato, se dovessi trovare qualcosa che mi desse
maggior soddisfazione sarei felice di cambiare. Per esempio, non
sopporto per nulla Gnome, ho sempre odiato l'arroganza degli
sviluppatori di Gnome, che si prendono il diritto di dirmi come devo
per forza gestire e/o vedere le cose, almeno KDE mi propone quello che
per lui dovrebbe essere il suo standard, ma posso in qualsiasi
momento, e senza cose troppo astruse, decidere cosa voglio in realtà.
Mi lascia molto più spazio di azione rispetto a Gnome.

>  > > Una è stata  definita "follia da camicia di forza"  in un libro edito
>  > > da Microsoft Press.
>  >
>  > curiosità: quale era questa follia?
>
> Dispatchment degli eventi ai thread.  In pratica tu potevi impedire ad
> applicazione di sapere che volevano chiuderla. Con un flood di VM_USER
> in broadcast la macchina in  breve ascoltava solo l'interruttore della
> corrente.
>
> Quasi vent'anni  fa stavo andando  al lavoro con il  Richter (Advanced
> Windows Programming)  sulle ginocchia, lessi  la cosa e mi  dissi "Non
> possono  aver  fatto  una  cosa  simile, stasera  provo  a  vedere  se
> veramente faccio casino".  Solo dopo mi accorsi  che l'autore definiva
> la cosa come "follia" (madness in inglese, ovvero follia da camicia di
> forza) e fatta solo perché "il management aveva deciso che in quel modo
> le applicazioni avrebbero risposto meglio all'utente" (più o meno).
>
> Come  ho  detto,  l'effetto  della  prova è  che  ho  dovuto  spegnere
> fisicamente la macchina.
>
> Ci hanno messo una decina di anni a sistemare la cosa.

bhe... ci hanno messo molto di più a sistemare altri bug, questo è uno
dei motivi per cui non mi piace winzoz e mi piace linux, uno è
immobile in se stesso, l'altro è dinamico, i problemi si affrontano,
non si nascondono (o almeno si cerca di farlo, non conosco tutti i
meandri del mio sistema, purtroppo).

>  > > Avevo trovato la descrizione di "implementazione di prova" di un virus
>  > > per  GNU/Linux  che   usava  che  usava  la   debolezza  descritta  in
>  > > http://lists.freedesktop.org/pipermail/xdg/2006-April/006379.html .
>  > >
>  > > Era una  implementazione macchinosa, ma  si può fare di  meglio, molto
>  > > meglio.
>  > >
>  > > A parer mio invece di montare in automatico la penna sarebbe molto più
>  > > sensato rendere  facile il montaggio  della penna agli utenti:
>  >
>  > io non ho mai parlato di montaggio automatico... con KDE, quando
>  > inserisco una periferica di massa, mi avverte che è stata inserita una
>  > periferica di massa... non la monta direttamente, ci mette un bel
>  > pulsantino, e se vuoi la monti, altrimenti la lasci stare li com'é.
>
> Meglio, già meglio.
>
> Ammetto che quelle cose nemmeno le guardo che non mi servono (ci metto
> niente a scrivere mount /tux o /panda).

certo... tu sulla tua macchina, nel momento in cui usi solo quelle due
chiavette... se dicessi a mio padre, quando metti la chiavetta devi
andare ad aprire /etc/fstab per metterci i dati della chiavetta (e
come può? visto che non è amministratore) per poi poterla montare
tranquillamente le volte successive... (lo devi fare tu che se

Re: dischi usb e permessi

2014-01-11 Per discussione gerlos

Il giorno 10/gen/2014, alle ore 17:08, Gian Uberto Lauri  ha 
scritto:

> Piviul writes:
>>> Prevedere una serie di /dev/sd?1 per le varie possibili penne non
>>> partizionate e mettere 'user' in /etc/fstab.
>> Sai che non capisco il nocciolo della questione? se io permetto ad un 
>> utente di inserire e montare una qualuque penna usb precreando in 
>> /etc/fstab trovo che sia esattamente quello che fa gnome con 
>> l'automount. È molto più probabile che un eventuale malware arrivi da 
>> internet che da un pendrive nel pc di casa mia: non concordi?
> 
> La differenza è che nel primo caso l'utente controlla il montaggio, nel
> secondo caso la penna viene montata anche se l'utente vuole solo il device
> presente.
> 
> Quanto alla diffusione dei malaware, temo che i device riscrivibili usati
> in modo promiscuo possano essere tanto dannosi quanto la rete.
> 
>> A me sembra che bisogna cercare di costruire un sistema operativo che 
>> sia in grado di automatizzare tutto ciò che sia automatizzabile. 
> 
> In linea  di principio  sono pienamente  d'accordo con  te, altrimenti
> userei vi e non  Emacs :).
> 
> In pratica, non automatizzerei troppo comportamenti pericolosi.

Scusate, mi sono perso anche io. 

Anni fa queste cose le facevo anche io a mano, o con script più o meno 
esoterici, e condivido l’entusiasmo di alcuni nell’inventare da capo soluzioni 
ad uno dei problemi più vecchi dell'informatica. :-)

Solo che oggi esistono già sistemi eccellenti per montare dischi esterni in 
modo più o meno automatico (pmount, udev, ...), soprattutto se uno sta usando 
un ambiente desktop.

Quindi chiedo (solo per capire, eh!): stiamo cercando una soluzione come 
esercizio tecnico, o stiamo cercando una soluzione ad un problema pratico per 
agevolare l’utente finale del sistema, cui non funzionano le feature di 
automount del DE scelto?

Perché nella seconda ipotesi, io indagherei sul perché il DE non permette di 
montare i dischi esterni in modo “facile”, e cercherei di risolvere il problema 
da lì. 
Perché se Gnome/KDE/XFCE/quelcheèDE (qual è il DE incriminato?) non monta i 
dischi esterni forse c’è qualcosa da sistemare su quel sistema… (io darei anche 
un’occhiata alle regole di udev).

>> L'automount dei pendrive o dei cd/dv... va proprio in questa direzione e 
>> non mi sembra che nasconda alcuna falla di sicurezza.
> 
> Piuttosto che automount  o un popup - che potrebbe  disturbare - sarei
> per un meccanismo di mount estremamente facile.


Quando ho letto quest’ultima frase mi è venuto il dubbio se il sistema di cui 
stiamo parlando è un desktop o qualcosa di esotico… 
Se ho appena collegato una pendrive ad un sistema desktop mi aspetto, anzi, 
pretendo, che il mio sistema faccia qualcosa: automonti la pendrive, mi mostri 
una finestra del file manager, insomma, mi mostri una notifica. Insomma, l’ho 
collegata ed evidentemente voglio farci qualcosa! 

Il fatto che vi preoccupate di un popup "che potrebbe disturbare” mi fa venire 
il dubbio che il sistema in oggetto non sia un desktop “normale”...

saluti
gerlos

--
"Fairy tales are more than true, not because they tell us that dragons exist, 
but because they tell us that dragons can be beaten."
G. K. Chesterton
   
gerlos +- - - > gnu/linux registred user #311588


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/948c8fa2-cd1e-4577-ba75-ac03ad161...@gmail.com



Re: dischi usb e permessi

2014-01-10 Per discussione Piviul

Gian Uberto Lauri scrisse in data 10/01/2014 17:08:

Piviul writes:
  > > Prevedere una serie di /dev/sd?1 per le varie possibili penne non
  > > partizionate e mettere 'user' in /etc/fstab.
  > Sai che non capisco il nocciolo della questione? se io permetto ad un
  > utente di inserire e montare una qualuque penna usb precreando in
  > /etc/fstab trovo che sia esattamente quello che fa gnome con
  > l'automount. È molto più probabile che un eventuale malware arrivi da
  > internet che da un pendrive nel pc di casa mia: non concordi?

La differenza è che nel primo caso l'utente controlla il montaggio, nel
secondo caso la penna viene montata anche se l'utente vuole solo il device
presente.
secondo il mio punto di vista nel primo caso l'utente è costretto a 
montarlo manualmente, nel secondo caso invece può scegliere se montarlo 
in automatico o meno...



Quanto alla diffusione dei malaware, temo che i device riscrivibili usati
in modo promiscuo possano essere tanto dannosi quanto la rete.

  > A me sembra che bisogna cercare di costruire un sistema operativo che
  > sia in grado di automatizzare tutto ciò che sia automatizzabile.

In linea  di principio  sono pienamente  d'accordo con  te, altrimenti
userei vi e non  Emacs :).

:-[ io uso vim...


In pratica, non automatizzerei troppo comportamenti pericolosi.

  > L'automount dei pendrive o dei cd/dv... va proprio in questa direzione e
  > non mi sembra che nasconda alcuna falla di sicurezza.

Piuttosto che automount  o un popup - che potrebbe  disturbare - sarei
per un meccanismo di mount estremamente facile.

Ci  possono  essere   validi  motivi  per  cui   l'automatismo  è  una
scocciatura. A meno che non sia una scelta dell'utente.
l'importante, secondo me, è che l'automatismo se lo vuoi lo possa usare 
e se non lo vuoi lo possa disattivare.
Gnome in effetti mi piaceva di più quando aveva la doppia azione smonta 
e espelli, ora invece ha soltanto espelli... comunque il fatto che te lo 
monti in automatico io lo trovo molto comodo: nel 99% dei caso quando 
inserisco un pendrive nel mio pc mentre lavoro è perché ho bisogno di 
leggere/scrivere qualcosa nel pendrive. Sui server invece non metto né 
gnome né l'automount.


Ciao

Piviul


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d0214f.7010...@riminilug.it



Re: dischi usb e permessi

2014-01-10 Per discussione Gian Uberto Lauri
Piviul writes:
 > > Prevedere una serie di /dev/sd?1 per le varie possibili penne non
 > > partizionate e mettere 'user' in /etc/fstab.
 > Sai che non capisco il nocciolo della questione? se io permetto ad un 
 > utente di inserire e montare una qualuque penna usb precreando in 
 > /etc/fstab trovo che sia esattamente quello che fa gnome con 
 > l'automount. È molto più probabile che un eventuale malware arrivi da 
 > internet che da un pendrive nel pc di casa mia: non concordi?

La differenza è che nel primo caso l'utente controlla il montaggio, nel
secondo caso la penna viene montata anche se l'utente vuole solo il device
presente.

Quanto alla diffusione dei malaware, temo che i device riscrivibili usati
in modo promiscuo possano essere tanto dannosi quanto la rete.

 > A me sembra che bisogna cercare di costruire un sistema operativo che 
 > sia in grado di automatizzare tutto ciò che sia automatizzabile. 

In linea  di principio  sono pienamente  d'accordo con  te, altrimenti
userei vi e non  Emacs :).

In pratica, non automatizzerei troppo comportamenti pericolosi.

 > L'automount dei pendrive o dei cd/dv... va proprio in questa direzione e 
 > non mi sembra che nasconda alcuna falla di sicurezza.

Piuttosto che automount  o un popup - che potrebbe  disturbare - sarei
per un meccanismo di mount estremamente facile.

Ci  possono  essere   validi  motivi  per  cui   l'automatismo  è  una
scocciatura. A meno che non sia una scelta dell'utente.

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21200.6929.824670.428...@mail.eng.it



Re: dischi usb e permessi

2014-01-10 Per discussione Piviul

Gian Uberto Lauri scrisse in data 10/01/2014 09:27:

Piviul writes:
  > Gian Uberto Lauri scrisse in data 09/01/2014 15:07:
  > > E QUESTO è il modo di rendere la cosa veramente multiutente:
  > > supponiamo che linuxbox sia IL computer di un LUG, [...]
  > e supponiamo che invece il pc si di casa mia dove mia moglie che non è
  > nel gruppo sudo e non conosce la password di root perché non è in grado
  > di fare qualunque cosa di tipo amministrativo,

Prevedere una serie di /dev/sd?1 per le varie possibili penne non
partizionate e mettere 'user' in /etc/fstab.
Sai che non capisco il nocciolo della questione? se io permetto ad un 
utente di inserire e montare una qualuque penna usb precreando in 
/etc/fstab trovo che sia esattamente quello che fa gnome con 
l'automount. È molto più probabile che un eventuale malware arrivi da 
internet che da un pendrive nel pc di casa mia: non concordi?


A me sembra che bisogna cercare di costruire un sistema operativo che 
sia in grado di automatizzare tutto ciò che sia automatizzabile. 
L'automount dei pendrive o dei cd/dv... va proprio in questa direzione e 
non mi sembra che nasconda alcuna falla di sicurezza.


Ciao

Piviul


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d01937.7060...@riminilug.it



Re: dischi usb e permessi

2014-01-10 Per discussione Gian Uberto Lauri
Gollum1 writes:
 > Il 10 gennaio 2014 14:27, Gian Uberto Lauri  ha scritto:
 > > Gollum1 writes:
 > >  > perché se si usa linux bisogna sempre fare le cose più difficili del
 > >  > necessario?
 > >
 > > Perché  è  il modo  migliore  di  lavorare.
 > 
 > su questo ho i miei dubbi.

Lo immaginavo, ma sei in una posizione non corretta.

 > bhe... che winzoz mi stia sugli zebedei non è un mistero (sopratutto 8.x).

Ma intanto sia KDE che Gnome sono progetti di inseguimento, e inseguno
ANCORA Windows nonostante gli annunci.

(BTW, le  QT sono  simili come impostazioni  alle MFC,  gli preferisco
 ancora le GTK nonostante tenga Gnome a distanza).

 > > Una è stata  definita "follia da camicia di forza"  in un libro edito
 > > da Microsoft Press.
 > 
 > curiosità: quale era questa follia?

Dispatchment degli eventi ai thread.  In pratica tu potevi impedire ad
applicazione di sapere che volevano chiuderla. Con un flood di VM_USER
in broadcast la macchina in  breve ascoltava solo l'interruttore della
corrente.

Quasi vent'anni  fa stavo andando  al lavoro con il  Richter (Advanced
Windows Programming)  sulle ginocchia, lessi  la cosa e mi  dissi "Non
possono  aver  fatto  una  cosa  simile, stasera  provo  a  vedere  se
veramente faccio casino".  Solo dopo mi accorsi  che l'autore definiva
la cosa come "follia" (madness in inglese, ovvero follia da camicia di
forza) e fatta solo perché "il management aveva deciso che in quel modo
le applicazioni avrebbero risposto meglio all'utente" (più o meno).

Come  ho  detto,  l'effetto  della  prova è  che  ho  dovuto  spegnere
fisicamente la macchina.

Ci hanno messo una decina di anni a sistemare la cosa.

 > > Avevo trovato la descrizione di "implementazione di prova" di un virus
 > > per  GNU/Linux  che   usava  che  usava  la   debolezza  descritta  in
 > > http://lists.freedesktop.org/pipermail/xdg/2006-April/006379.html .
 > >
 > > Era una  implementazione macchinosa, ma  si può fare di  meglio, molto
 > > meglio.
 > >
 > > A parer mio invece di montare in automatico la penna sarebbe molto più
 > > sensato rendere  facile il montaggio  della penna agli utenti:
 > 
 > io non ho mai parlato di montaggio automatico... con KDE, quando
 > inserisco una periferica di massa, mi avverte che è stata inserita una
 > periferica di massa... non la monta direttamente, ci mette un bel
 > pulsantino, e se vuoi la monti, altrimenti la lasci stare li com'é.

Meglio, già meglio.

Ammetto che quelle cose nemmeno le guardo che non mi servono (ci metto
niente a scrivere mount /tux o /panda).

 > >  non si
 > > renderebbe difficile la multiutenza, quella  vera dico e non quella di
 > > uno alla volta con utenti diversi,
 > 
 > siamo sempre li... su un pc di casa, con un solo pc in casa, quanti
 > credi che facciano la multiutentza contemporanea?

Ecco, sei cieco, perdona. Se TU non lo usi non vuole dire che NON sia
usato. Linux venne scritto da Thorvalds perché voleva divertirsi ad
avere Unix a casa. E Unix è multiutenza :).

Ci sono varie situazioni in cui la multiutenza fa tanto comodo,
evidentemente non ti sono mai capitate e quindi le ignori e non
comprendi che in quelle situazioni non avere una vera multiutenza può
essere una rogna.

Perdonami, non voglio offenderti. Ma ci sono cose che non si capiscono
se non le hai mai sperimentate. La multiutenza, il display remoto...

 > già è difficile avere più utenti diversi sullo stesso pc, ogniuno con
 > le proprie cose e le proprie impostazioni (io e mia moglie facciamo
 > così), la normalità che ho visto è l'uso dello stesso account tra più
 > persone (parliamo sempre e solo di ambito famigliare).

Non hai mai lavorato con macchine con 100 e passa utenti?

Non ci sono solo gli scenari "un pc a testa".

 > >  e si ridurrebbero i rischi per gli
 > > utenti, anche se non li si elimierebbero del tutto.
 > 
 > qui ci vorrebbe una divulgazione della cultura informatica, che la
 > maggior parte della gente (sopratutto quella proveniente dai mondo
 > winzoz) non ha e purtroppo spesso non vuole avere.

No. Sono gli  esperti che devono "proteggerli". Per  curarti il medico
ti  chiede di  studiare  medicina? No,  è lui  a  scegliere farmaci  e
dosaggi.

 > > Per rispetto agli  utenti "che non sanno" ci si  dovrebbe astenere dal
 > > pubblicare certe  soluzioni solo perché non  si è in grado  di fare di
 > > meglio e  avere l'umiltà di  chiedere aiuto.  Non fare come  chi punta
 > > solo a mungere soldi dagli utenti sfruttando la loro ignoranza.
 > 

Mi sono  spiegato male,  scusami. Non  intendevo dire  che tu  o altri
hanno munto.

In vari  progetti ho visto  "un comportamento sulla  valutazione della
qualità" del rilasciato che è uguale  a quello delle aziende che hanno
munto.

 > 
 > > È una questione di rispetto degli utenti, non essere duri e puri.
 > 
 > Una forma di rispetto è forse anche quella di non castrarli sul
 > nascere con soluzione improponibili ad un analfabeta informatico.

No.  La soluzione è scrivere qualcosa di semplice e di sicuro

Re: dischi usb e permessi

2014-01-10 Per discussione Gollum1
Il 10 gennaio 2014 14:27, Gian Uberto Lauri  ha scritto:
> Gollum1 writes:
>  > perché se si usa linux bisogna sempre fare le cose più difficili del
>  > necessario?
>
> Perché  è  il modo  migliore  di  lavorare.

su questo ho i miei dubbi.

>  > è finita l'epoca dei duri e puri ad ogni costo, c'é la tecnologia
>  > adeguata, usiamola...
>
> Non è essere duri e puri. Non ritengo ancora adeguata la tecnologia.
>
> Sono d'accordo  che i  computer debbano essere  utili, che  i computer
> debbano essere al servizio di chi li usa e non una servitù.
>
> Ma c'è modo e modo di fare le cose. Inseguire Windows NON è la scelta.
> Windows ha fatto troppe scelte  scriteriate solo perché comunque erano
> comode.

bhe... che winzoz mi stia sugli zebedei non è un mistero (sopratutto 8.x).

> Una è stata  definita "follia da camicia di forza"  in un libro edito
> da Microsoft Press.

curiosità: quale era questa follia?

> Avevo trovato la descrizione di "implementazione di prova" di un virus
> per  GNU/Linux  che   usava  che  usava  la   debolezza  descritta  in
> http://lists.freedesktop.org/pipermail/xdg/2006-April/006379.html .
>
> Era una  implementazione macchinosa, ma  si può fare di  meglio, molto
> meglio.
>
> A parer mio invece di montare in automatico la penna sarebbe molto più
> sensato rendere  facile il montaggio  della penna agli utenti:

io non ho mai parlato di montaggio automatico... con KDE, quando
inserisco una periferica di massa, mi avverte che è stata inserita una
periferica di massa... non la monta direttamente, ci mette un bel
pulsantino, e se vuoi la monti, altrimenti la lasci stare li com'é.

>  non si
> renderebbe difficile la multiutenza, quella  vera dico e non quella di
> uno alla volta con utenti diversi,

siamo sempre li... su un pc di casa, con un solo pc in casa, quanti
credi che facciano la multiutentza contemporanea?
già è difficile avere più utenti diversi sullo stesso pc, ogniuno con
le proprie cose e le proprie impostazioni (io e mia moglie facciamo
così), la normalità che ho visto è l'uso dello stesso account tra più
persone (parliamo sempre e solo di ambito famigliare).

>  e si ridurrebbero i rischi per gli
> utenti, anche se non li si elimierebbero del tutto.

qui ci vorrebbe una divulgazione della cultura informatica, che la
maggior parte della gente (sopratutto quella proveniente dai mondo
winzoz) non ha e purtroppo spesso non vuole avere.


> Per rispetto agli  utenti "che non sanno" ci si  dovrebbe astenere dal
> pubblicare certe  soluzioni solo perché non  si è in grado  di fare di
> meglio e  avere l'umiltà di  chiedere aiuto.  Non fare come  chi punta
> solo a mungere soldi dagli utenti sfruttando la loro ignoranza.

fino ad ora non ho munto nessuno, e non ho intenzione di cominiciare ora... :P

> È una questione di rispetto degli utenti, non essere duri e puri.

Una forma di rispetto è forse anche quella di non castrarli sul
nascere con soluzione improponibili ad un analfabeta informatico.

Byez
-- 
Gollum1
Tesoro, dov'é il mio teoro...


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cantvqs9fe0nwkzy4qmhawppipevj2nzjcddfxs5fz_uhnod...@mail.gmail.com



Re: dischi usb e permessi

2014-01-10 Per discussione Gian Uberto Lauri
Gollum1 writes:
 > perché se si usa linux bisogna sempre fare le cose più difficili del
 > necessario?

Perché  è  il modo  migliore  di  lavorare.  Prima che  qualche  nuova
testolina (peraltro  mica stupida) si  mettesse a dire "Wow,  ho fatto
una cosa comoda" tanta altra gente si è fatta la bua al naso...

Un giorno  uno studente si  presentò a Moon  e disse: "Ho  capito come
migliorare  garbage collector.   Dobbiamo  mettere in  ogni 'cons'  un
contatore dei riferimenti"

Moon  pazientemente raccontò  allo  studente  questa storiellina:  "Un
giorno uno studente arrivò da Moon e disse: 'Ho capito come migliorare
garbage collector...

[Nota tennica: il  solo conteggio delle referenze  fallisce ad esempio
miseramente nelle situazioni un cui un  oggetto A ha un riferimento ad
un  oggetto  B e  contemporameamente  l'oggetto  B ha  un  riferimento
all'oggetto A.]

 > è finita l'epoca dei duri e puri ad ogni costo, c'é la tecnologia
 > adeguata, usiamola...

Non è essere duri e puri. Non ritengo ancora adeguata la tecnologia.

Sono d'accordo  che i  computer debbano essere  utili, che  i computer
debbano essere al servizio di chi li usa e non una servitù.

Ma c'è modo e modo di fare le cose. Inseguire Windows NON è la scelta.
Windows ha fatto troppe scelte  scriteriate solo perché comunque erano
comode.

Una è stata  definita "follia da camicia di forza"  in un libro edito
da Microsoft Press.

Avevo trovato la descrizione di "implementazione di prova" di un virus
per  GNU/Linux  che   usava  che  usava  la   debolezza  descritta  in
http://lists.freedesktop.org/pipermail/xdg/2006-April/006379.html .

Era una  implementazione macchinosa, ma  si può fare di  meglio, molto
meglio.

A parer mio invece di montare in automatico la penna sarebbe molto più
sensato rendere  facile il montaggio  della penna agli utenti:  non si
renderebbe difficile la multiutenza, quella  vera dico e non quella di
uno alla volta con utenti diversi,  e si ridurrebbero i rischi per gli
utenti, anche se non li si elimierebbero del tutto.

Per rispetto agli  utenti "che non sanno" ci si  dovrebbe astenere dal
pubblicare certe  soluzioni solo perché non  si è in grado  di fare di
meglio e  avere l'umiltà di  chiedere aiuto.  Non fare come  chi punta
solo a mungere soldi dagli utenti sfruttando la loro ignoranza.

È una questione di rispetto degli utenti, non essere duri e puri.

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21199.62800.144883.31...@mail.eng.it



Re: dischi usb e permessi

2014-01-10 Per discussione Gollum1
Il 10 gennaio 2014 09:27, Gian Uberto Lauri  ha scritto:
> Piviul writes:
>  > Gian Uberto Lauri scrisse in data 09/01/2014 15:07:
>  > > E QUESTO è il modo di rendere la cosa veramente multiutente:
>  > > supponiamo che linuxbox sia IL computer di un LUG, [...]
>  > e supponiamo che invece il pc si di casa mia dove mia moglie che non è
>  > nel gruppo sudo e non conosce la password di root perché non è in grado
>  > di fare qualunque cosa di tipo amministrativo,
>
> Prevedere una serie di /dev/sd?1 per le varie possibili penne non
> partizionate e mettere 'user' in /etc/fstab.
>
> Oppure usare sudo come Il Grande Bit comanda? Script montapenna e
> smontapenna (magari con iconcina sul desktop) che permettono a tua
> moglie di fare mount.  Questo potrebbe introdurre quel pizzico di
> intelligenza che manca alla soluzione precedente.
>
>  > Ovviamente se amministrassi un pc di un LUG direi che la tua proposta
>  > sia sensata ma già in ufficio da me chiunque vuole essere in grado di
>  > leggere un pen drive gli passi per le mani...
>
> Stuxnet ringrazia di cuore per questo modo di pensare :).

perché se si usa linux bisogna sempre fare le cose più difficili del
necessario? i nuovi framework che sono stati inseriti nel tempo
aiutano di parecchio (e mi riferisco a udev e compagnia bella). Se a
mio padre (a cui amministro io il computer per gli aggiornamenti, ma
non posso essere sempre li presente) decide di inserire un HDD o una
pendrive, perché gli devo creare problemi? se il mio amico windozziano
che ho "convertito" a linux, la prima volta che va a mettere un HDD
esterno al suo pc e non è in grado di fare nulla, prima mi manda a
quel paese, e poi mi chiede di cancellare linux e rimettergli
winzoz...

è finita l'epoca dei duri e puri ad ogni costo, c'é la tecnologia
adeguata, usiamola...

piuttosto la cosa importante è capire poi come questa viene usata,
rendiamoci conto che in realtà il 99% dei computer casalinghi vengono
usati da un utente solo alla volta (e spesso vengono usati con lo
stesso utente da più persone della famiglia), quindi non facciamoci
troppe seghe mentali. Dobbiamo portare i vari utonti/utenti ad usare
correttamente la tecnologia, con la giusta sicurezza e le giuste
procedure, non tagliargli le gambe ad ogni momento.

Tutto IMHO naturalmente... :)

Byez
-- 
Gollum1
Tesoro, dov'é il mio teoro...


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cantvqs-j9vodvurczjaubpgyqkfv+wcrdva9fnnuox1bhek...@mail.gmail.com



Re: dischi usb e permessi

2014-01-10 Per discussione Gian Uberto Lauri
Piviul writes:
 > Gian Uberto Lauri scrisse in data 09/01/2014 15:07:
 > > E QUESTO è il modo di rendere la cosa veramente multiutente:
 > > supponiamo che linuxbox sia IL computer di un LUG, [...]
 > e supponiamo che invece il pc si di casa mia dove mia moglie che non è 
 > nel gruppo sudo e non conosce la password di root perché non è in grado 
 > di fare qualunque cosa di tipo amministrativo,

Prevedere una serie di /dev/sd?1 per le varie possibili penne non
partizionate e mettere 'user' in /etc/fstab.

Oppure usare sudo come Il Grande Bit comanda? Script montapenna e
smontapenna (magari con iconcina sul desktop) che permettono a tua
moglie di fare mount.  Questo potrebbe introdurre quel pizzico di
intelligenza che manca alla soluzione precedente.

 > Ovviamente se amministrassi un pc di un LUG direi che la tua proposta 
 > sia sensata ma già in ufficio da me chiunque vuole essere in grado di 
 > leggere un pen drive gli passi per le mani...

Stuxnet ringrazia di cuore per questo modo di pensare :).

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21199.44781.984940.699...@mail.eng.it



Re: dischi usb e permessi

2014-01-09 Per discussione Piviul

Gian Uberto Lauri scrisse in data 09/01/2014 15:07:

E QUESTO è il modo di rendere la cosa veramente multiutente:
supponiamo che linuxbox sia IL computer di un LUG, [...]
e supponiamo che invece il pc si di casa mia dove mia moglie che non è 
nel gruppo sudo e non conosce la password di root perché non è in grado 
di fare qualunque cosa di tipo amministrativo, arrivi con il pen derive 
di una amica che gli ha portato la scansione dei compiti per la figlia 
che era assente da scuola. Inserisce la chiavetta nel pc e non accade 
nulla. A questo punto incavolata come una iena mi chiede perché a lei 
non sia concessa questa oppurtunità...


Ovviamente se amministrassi un pc di un LUG direi che la tua proposta 
sia sensata ma già in ufficio da me chiunque vuole essere in grado di 
leggere un pen drive gli passi per le mani...


Un saluto

Piviul


--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52cfa052.7050...@riminilug.it



Re: dischi usb e permessi

2014-01-09 Per discussione Gian Uberto Lauri
Dario writes:
 > approfittando della tua disponibilità nella spiegazione:
 > che succede se Tizio e Caio, ciascuno per la loro chiavetta,
 > utilizzano la stessa label OCNAPOCNIP?

Premessa:

Negli esempi assumerò che la penna 1 contenga i file a b c d nella
radice del file system, la penna 2 contenga i file w x y z nella
radice del file system ed il mountpoint sia /prova


Ci sono due casi:

1 - si inseriscono successivamente le varie chiavi

Nel caso 1 la seconda mount riesce e nasconde la precendente che
rimane comunque montata:

user1$ mount /prova
user1$ ls -l /prova
-rwx-- 1 user1 user1 (blablabla) a
-rwx-- 1 user1 user1 (blablabla) b
-rwx-- 1 user1 user1 (blablabla) c
-rwx-- 1 user1 user1 (blablabla) d
(user2 inserisce la seconda chiavetta)
user2$ mount /prova
user2$ ls /prova
-rwx-- 1 user2 user2 (blablabla) w
-rwx-- 1 user2 user2 (blablabla) x
-rwx-- 1 user2 user2 (blablabla) y
-rwx-- 1 user2 user2 (blablabla) z

a questo punto solo root può fare l'umount delle due chiavi.

2 - si montano chiavi ambedue inserite nella presa. In questo caso
viene montata la seconda chiave inserita.

Questo accade perché nel caso 1 la label individua ad esempio /dev/sdb
(che credo udev associ a penna1) e la mount va. Alla seconda insert
label viene associata a /dev/sdc (associato a penna2) e la mount riesce.

Nel secondo la label viene "risolta" subito con /dev/sdc.

Nota: a quanto pare udev si tiene in cache le assegnazioni dei device
(ma non sono un esperto di udev) e quindi la penna inserita per
seconda viene sempre riconosciuta come /dev/sdc anche se /dev/sdb
fosse un device non esistente. Non ho ancora verificato cosa succede
con un reboot.

-- 
 /\   ___Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_   African word
  //--\| | \|  |   Integralista GNUslamicomeaning "I can
\/ coltivatore diretto di software   not install
 già sistemista a tempo (altrui) perso...Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21198.50200.493708.711...@mail.eng.it



Re: dischi usb e permessi

2014-01-09 Per discussione Dario

Il 09/01/2014 15:07, Gian Uberto Lauri ha scritto:

Altro modo: La chiavetta di Tizio ha label PINCO, quella di Caio label
PANCO.  Anche lasciando fare le cose ad automount o fuse, Tizio
troverà sempre nello stesso path e sempre di sua proprietà il file
system della sua chiavetta. Idem per Caio.

Senza contare il caso non raro di avere un certo numero di chiavette che
vuoi usare in parallelo, magari in congiunzione con qualche script. Senza
le label e fstab penso che la cosa sia un pelino rognosa.


approfittando della tua disponibilità nella spiegazione:
che succede se Tizio e Caio, ciascuno per la loro chiavetta,
utilizzano la stessa label OCNAPOCNIP?

Dario




--
Per REVOCARE l'iscrizione alla lista, inviare un email a 
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per

problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52ceb411.2090...@gmail.com



Re: dischi usb e permessi

2014-01-09 Per discussione Gian Uberto Lauri
Piviul writes:
 > Non avertene a male ma non sono d'accordo con te... se il pc è usato da 
 > più persone e vuoi che ognuno possa gestirsi il suo (o i suoi) pendrive 
 > è di gran lunga più comodo far fare tutto a gnome.

Comodo non vuole dire sensato.

E poi il discorso era un altro:  se hai due penne usb collegate, quale
sarà  la sdb1,  quale la  sdc1?

(sdX è il device, sdXN è  l'ennesima partizione, e se non ricordo male
ci deve essere almeno una partizione)

La cosa sensata  è che chi ha la  PWD di root distingua tra  chi può e
chi non può montare la penna e  usi users in fstab, dopo aver messo le
etichette alle chiavette.

E QUESTO è il modo di rendere la cosa veramente multiutente:
supponiamo che linuxbox sia IL computer di un LUG, ci sia Tizio in
console e Caio che può accedere al computer, mettiamo via rete.  

Ora Caio ha una penna USB ma non una porta USB disponibile sulla sua
macchina. Può connettersi a linuxbox, inserire la chiavetta in una
porta USB di linuxbox e via rete avere i dati sul suo computer
personale (o far viaggiare i dati dal computer alla chiavetta).

E complichiamo  la cosa,  anche Tizio vuole  usare una  chiavetta USB,
cavoli la macchina è multiuser e ci sono porte libere.

Usando gnome: la prima chiavetta inserita viene montata come un device
di Tizio anche se è di Caio, la seconda non viene montata su /dev/sdb.

Oppure  ammazzi il  PC  con  due sessioni  di  Gnome  una delle  quali
carica pure la rete :).

Altro modo: La chiavetta di Tizio ha label PINCO, quella di Caio label
PANCO.  Anche lasciando fare le cose ad automount o fuse, Tizio
troverà sempre nello stesso path e sempre di sua proprietà il file
system della sua chiavetta. Idem per Caio.

Senza contare il caso non raro di avere un certo numero di chiavette che
vuoi usare in parallelo, magari in congiunzione con qualche script. Senza
le label e fstab penso che la cosa sia un pelino rognosa.

-- 
Gian
   Friends will be friends
  right to the end!


--
Per REVOCARE l'iscrizione alla lista, inviare un email a
debian-italian-requ...@lists.debian.org con oggetto "unsubscribe". Per
problemi inviare un email in INGLESE a listmas...@lists.debian.org

To UNSUBSCRIBE, email to debian-italian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21198.44348.218693.782...@mail.eng.it



  1   2   3   4   5   6   >