Newsgroup: it.comp.os.linux.iniziare
Titolo: udev problemi

Salve,
ho uno Iomega Zip 250 a cui voglio assegnare un nome statico con udev.
Le info per le rules sono (parziali):
looking at device '/block/sdc':
    KERNEL=="sdc"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{capability}=="13"
    ATTR{stat}=="      58      199     1016     9160        3
0        6     7000        0    14670    16160"
    ATTR{size}=="489532"
    ATTR{removable}=="1"
    ATTR{range}=="16"
    ATTR{dev}=="8:32"
  looking at parent device '/devices/pci0000:00/0000:00:0a.0/
usb6/6-2/6-2:1.0/host3/target3:0:0/3:0:0:0':
    KERNELS=="3:0:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS=="sd"
    ATTRS{model}=="ZIP 250         "
    ATTRS{vendor}=="IOMEGA  "
    ATTRS{scsi_level}=="0"
E questa e' la mia /etc/udev/rules.d/010_local.rules
SUBSYSTEM=="block", ATTRS{model}=="ZIP 250", NAME="%k",
SYMLINK="zip_250", GROUP="users", MODE="0660"
Faccio un bel reboot, monto, ma il device non ha i permessi dati da
udev e neanche il gruppo
$ls -l /media/zip_250
drwxrwx--- 3 root root  1024 2008-05-25 20:48 zip_250
Sono quasi convinto che sia la mia regola a non funzionare...
Poi in alcune guide trovo che si usa SYSFS al posto di ATTRS, o il
SYMLINK con '+=' anziche' solo '='.
Ho aggiunto una linea in fstab che mi permette di montare /dev/zip_250
in /media/zip_250 anche da utente
Qualche idea?
grazie in anticipo

 SUBSYSTEM=="block", ATTRS{model}=="ZIP 250", NAME="%k",
]zac[
Gli spazi dopo creano problemi?
Cerca l'udev how-to, è spiegato abbastanza bene come fare le regole, come
testarle, e come attivarle senza dover riavviare il sistema.

 testarle, e come attivarle senza dover riavviare il sistema.
ahime', sto howto me lo son letto veramente tante volte. e' talmente
spiegato bene che sono arrivato ad un punto in cui penso che la mia
regola sia giusta (cosa non necessariamente vera) ma non so trovare se
e dove sbaglio.
direi che il nome del device venga correttamente impostato dalla
regola, in quanto riesco a montare con l'alias zip_250, anziche' sdc.
pero' poi il gruppo e i permessi non vengono eseguiti. puo' una regola
essere applicata a meta'?

iop wrote:

Non mescolare condizioni che si riferiscono a sezioni/blocchi diversi. 
Prova qualcosa come:
SUBSYSTEM=="scsi", ATTRS{model}=="ZIP 250         ", NAME="%k",
SYMLINK+="zip_250", GROUP="users", MODE="0660"
Ma guarda se nel resto delle informazioni hai altri blocchi più significati,
e prendi le condizioni da un solo blocco
-- 
cf

 e prendi le condizioni da un solo blocco
questa la sapevo, anche se mi ci e' voluto un po' per scoprirlo.
c'c' un'eccezione, le condizioni si devono prendere da un solo blocco,
ma si puo' prenderne una (e solo  una) da un blocco parente, che nel
mio caso era SUBSYSTEM="block"
non so piu' che pesci pigliare...

 non so piu' che pesci pigliare...
Era riferito alla riga di prima sì, ma controlla come ti hanno detto anche
gli spazi
ATTRS{model}=="ZIP 250         "
è diverso da
ATTRS{model}=="ZIP 250"
Io per un mio HD esterno usavo questa
KERNEL=="sd*", SUBSYSTEMS=="scsi", ATTRS{vendor}=="Seagate ",
ATTRS{model}=="FreeAgentDesktop", SYMLINK+="mio_hd%n"
come vedi dopo Seagate c'è uno spazio
quella dell'unica regola del parent block non la sapevo, grazie
-- 
cf

Conraid wrote:

No, gli spazi non creano problemi. Provato.
A questo punto prova  SYMLINK+= invece del solo =
Comunque ho notato una cosa.
tu parli di /media e non di /dev, il device viene creato in DEV
Quindi non ho ben capito cosa fai con il mount e del perché controlli i
permessi in /media
-- 
cf

 permessi in /media
ah, qui probabilmente emerge la mia ignoranza...
beh, in fstab ho aggiunto questa riga
/dev/zip_250 /media/zip_250 auto noauto,users,exec,rw 0 0
dove il /dev/zip_250 e' l'alias creato dalla mia regola udev.
funziona, perche' da user con
mount /media/zip_250
monto il device zip. se tolgo la regola, il mount come sopra non funge
piu'.
ora, ho che
$pwd
$/media
$ ls -l
$drwxr-xr-x 2 root root  4096 2008-07-05 14:48 zip_250
$mount /media/zip_250
$ls -l
$drwxrwxr-- 3 root root  1024 2008-07-06 16:01 zip_250
I permessi sono cambiati ma non il group! Ovviamente non sono stato io
con la mia regola a triggerare sto cambiamento.
siccome dopo il mount zip_250 non appartiene al gruppo users, non ci
posso accedere se non come root. In questo senso mi preoccupavo dei
permessi in /media.
qualche strafacione?

udev setta i permessi in dev, tu controlla quelli
ls -l /dev/zip_250
Per /media fai con HAL o imposti il mount point e dopo modifichi i permessi
a mano, in base al filesystem dello zip
-- 
:cf

 a mano, in base al filesystem dello zip
pur avendo modificato i permessi sul mount point, tipo gruppo users e
chmod 770, al momento del mount questi permessi vengono modificati
secondo uno schema default, che e' root root 770
lo so che mi sto mancando qualcosa di fondamentale e molto semplice,
ma non riesco a capire...

 ma non riesco a capire...
ma che filesystem hai nello zip?
-- 
:cf

> ma che filesystem hai nello zip?
lo zip e' formattato ext2.
a dire il vero non ho provato con altri fs

iop wrote:

se agisci sui permessi del filsystem una volta montato che ti dice?
Io solitamente per queste cose non uso /media come mount point in quanto
lascio che sia HAL ad usare /media. Per alcuni HD esterni o sia una regola
di HAL sia in fstab, e all'inserimento dell'HD scelgo cosa fare.
Lo tratto come un normale partizione di un HD interno insomma, e quindi le
directory avranno i permessi che voglio io al suo interno.
Al limite mi faccio una sottodirectory per il mio utente.
E UDEV ci incastra poco IMHO in questo
-- 
cf

> se agisci sui permessi del filsystem una volta montato che ti dice?
se lo monto e dopo cambio i permessi/gruppo allora ci accedo da utente
normale, dunque ok.
smonto, e i permessi tornano i default root root 755. rimonto e
magicamente i permessi sono quelli che ho cambiato giusto un attimo
prima.
e' come se se li ricordasse...
a questo punto sembra che abbia risolto il problema (devo acora
riavviare, se dovesse mai cambiare qulacosa) ma mi chiedo:
che c'azzecca udev in tutto questo?? con la mia regola ho ottenuto
solo un alias ma non ho ancora capito come gestire sti benedetti
permessi!
vabbuo', comunque funziona e ti ringrazio per la pazienza!

  ti ringrazio per la pazienza!
ma figurati, io sono dell'idea che condividere informazioni arricchisce
entrambi. 
Per esempio come hai visto alcune cose anche usandole non le conoscevo, come
la storia degli spazi :-)
Sono ancora molto indietro nel capire UDEV e HAL purtroppo
-- 
cf

 Con un symlink invece sai sempre che è quello scelto da te.
ho scoperto che alterando i permessi con lo zip montato non risolve i
mei problemi.
in effetti la mia intenzione era di usare script per backup
automatici. questi script devo salvare files su dir esistenti (ok coi
permessi perche' li ho cambiati io a mano) e creare dir al volo (non
ok perche' non ho i permessi giusti!). dunque risolve il mio problema
a meta'.
cio' e' sconfortante...
potrei fare un
chown -R root:users /media/zip_250
ma vale per le dir gia' esistenti
se il mio script ne crea di nuove, ho bisogno di essere root

 se il mio script ne crea di nuove, ho bisogno di essere root
Mi era sfuggito questo post.
Puoi sempre creare una directory e salvare li come se fosse la root del
disco (io faccio così e poi con rsync do la destinazione finale)
Oppure provare tra le opzioni di mount, come owner 
-- 
cf