Sziasztok!
A következő problémával fordulnék Hozzátok, hátha tudtok segíteni:
3.0.24-es Sambát használok, Mandriva 2007 Spring alatt. Ez a Samba szerver egyúttal egy PDC is, amely egy egész középiskolát lát el, kb. 1000 diákkal és 60 tanárral.
Mindenkinek saját felhasználóneve van, windows authentikáció van ezen a sambán keresztül.
A diákok és a tanárok két külön groupba, 'diakok' illetve 'tanarak' csoportba tartoznak.
Van egy nagy KÖZÖS nevű megosztás, amelyre a guest hozzáférés tiltva van, és mindenki egyedi felhasználónevével és jelszavával fér hozzá, tulajdonképpen windowsba való bejelentkezés után automatikusan felmappeli neki a samba, a saját bejelentkezőnevével.
A lenti probléma elhárításában milliónyi google oldalt, több-tíz tippet, FAQ-t átolvastam, egyenként kipróbálgattam, a leghülyébb ötleteket is, de már nincs több tippem.
Tehát:
Van egy speciális megosztás, amit malacperselynek neveztem el, a lényege ugyanis, hogy amit oda belemásol a diák, azt utána se nem tudja újra visszaolvasni, se nem tudja törölni. Ez informatikai dolgozatok iratására ideális. Gyakorlatilag arról van szó, hogy create mask = 007 van beállítva a file-ra, és azért hetes a vége, mert azt szeretném, hogy a tanárok viszont teljes joggal hozzáférjenek.
(Tehát ha felmásol a diák egy file-t, semmilyen joga nem lesz rá neki, valamint a csoportjának (a többi diáknak) sem, ugyanakkor a csoportján kívülieknek (akik tulképp a tanárok) teljes joguk lesz a file-hoz.)
Gyakorlatilag viszont a következő történik: a tanár az olvasási jogot rendesen megkapja a file-ra, tudja olvasni a file-t, azonban törölni nem! Chmoddal megnézve a jogokat szépen látszik, hogy elvileg megvan a tanárnak minden joga a file-ra, mégis kizárólag csak olvasni tudja, törölni nem.
Most jön az érdekesebb rész: ha az adott file-ra adok a tulajdonosának(!) írási jogot (és csak azt), úgy hirtelen a tanár is tudja törölni a file-t, aki ugyebár minden, csak nem tulajdonos. Sőt, tovább megyek: ha a tulajdonos számára megadom az írási jogot, hirtelen a saját csoport (diakok) tagjai is kapnak írási jogot, azoknak aztán meg abszolút semmiféle jog nincs bepipálva.
Tehát itt a file, aminek a jogai '207'. Ennek ellenére, MINDENKI tudja törölni a file-t. Ha 007-re teszem a jogot, akkor pedig SENKI nem tudja törölni.
Szerintem ennek nem így kéne működni, főleg hogy ez így a jogok használatát értelmetlenné teszi.
A sticky bit nincs bekapcsolva a könyvtárra, egyébként pedig ha megnézem a file tulajdonosát és csoportját, az tökéletesen működik: valóban a file létrehozója a tulajdonos, a hozzá tartozó csoport a csoport.
Próbálkoztam már security mask, create mode, nt acl support, write list, inherit permissions, meg a tökömtudja még hányféle beállítással - egyik sem oldotta meg a problémát.
Talán még érdekes lehet, hogy a tanári gépek nincsenek tartományba rakva (nem is fogjuk tudni), úgyhogy nekik kézzel kell felcsatlakozni a net use használatával.
Na szóval ez a helyzet. Bármilyen segítséget örömmel veszek és kipróbálok, az egyetlen feltétel sajnos az, hogy mivel év közepe van, nem mehetünk át sem új disztróra, sem új szerverre, és tartósabb ideig nem is szünetelhet a szolgáltatás, mivel az egész iskola használja.
Aki tud segíteni vagy megoldást találni, vendégem egy virtuális sörre, vagy ha egyszer a környékemen jár, biz' isten egy valódira is szívesen meghívom!
Előre is köszönöm!
- 2926 megtekintés
Hozzászólások
Ezek szerint eléggé "lebetonozódott" a helyzet.
Egyébként szerintem, ha csak a malacpersely telítődése probléma, akkor első körben nyilván a jogosultságok körül kutatnék, de ezt már megtetted, sőt többet is.
Másképp kérdezek:
Mi alapján dől el, hogy valami megmarad a malacperselyben, vagy törlődik?
Ha minden törlődik, akkor ezt egy cron.daily script is megtehetné a dátum alapján (pl. ami 2 hónapnál régebbi).
Más: nekem debian alatt a síma fat32-es adatpartíció csatolása volt hasonló:
mountpoint = /windows
/windows jogosultságai 777
júzerként néztem, jogosultság 755
végül nekem a /etc/fstab-ban ez segített:
/dev/hda5 /windows vfat rw,sync,umask=0000,gid=mazursky
Lehet, hogy valami hasonlót kellene a samba-ba beletolni. De ez csak gyenge ötlet részemről.
Egyébként gratula, szépen összeraktad a hálót. Én még "kezdő" vagyok, de azért jó lenne egy kis megmérettetés a "linux, mint server" témakörben.
/mazursky
- A hozzászóláshoz be kell jelentkezni
A törléshez szükséges, hogy az adott felhasználó (aki törölni akar) írási jogosultsággal rendelkezzen a malacpersely megosztás könyvtárára.
Ha ez jó, akkor szükségem lenne az smb.conf-ra, és a könyvtárra beállított jogosultságokra. Azután meglátjuk...
------
Λ4Иł)4
- A hozzászóláshoz be kell jelentkezni
Helló!
Köszi szépen a segítséget. Nem feledkeztem el Rólatok, csak félévzárás van/volt ugye a munkahelyen, és ezért az utóbbi 1-2 napban nagyon nem volt időm ezzel a témával foglalkozni. Felküldöm hétfőn az smb.conf-omat.
Köszi mégegyszer előre is!
- A hozzászóláshoz be kell jelentkezni
Sziasztok!
Bocs, hogy nem válaszoltam időben, sajnos kis időhiánnyal küszködtem. Szóval!
Tesztem a következő:
Belépek egy diák nevében, és létrehozok egy file-t.
Create mask = 207.:
Ilyenkor az elkészült file 206-os jogot kap alapból (ami kicsit vicces, mert 207 van beállítva maszkként.)
A tulajdonos kizárólag írhatja, a saját csoportja (a többi diák) nem kezdhet vele semmit, a csoporton kívüliek pedig teljes joggal hozzáférhetnek. Papíron így működik.
Gyakorlatban viszont a következőképp:
Egy másik diák belépés után valóban nem tudja olvasni a file-t, de törölni simán. Ez hiba.
A tanár tudja olvasni a file-t, és törölni is. Tőle ez lenne a normális.
Tehát Create Mask = 207 esetén a tanár jól működik, a diák rész már kevésbé.
Teszt #2, átállítom a maszkot 007-re, amolyan James Bondosra :).
Create mask = 007.:
Ilyenkor létrehozás után 006 lesz belőle (007 helyett, de ott egye meg a fene, futtatási jog nem kell senkinek wines környezetben).
Papíron senkinek nincs semmilyen joga, csak a csoporton kívülieknek írási és olvasási.
Ekkor gyakorlatban:
Egy másik diák nem tudja olvasni a file-t, és törölni sem tudja. Ez jól működik.
Egy tanár pedig tudja rendesen olvasni a file-t, azonban törölni ő sem tudja. Ez hiba.
Na ez a helyzet. Vagy az egyik rész működik jól, vagy a másik.
A fizikai alkönyvtárra, amely 'malacpersely' néven meg van osztva, 0777 van, vagyis mindenkinek minden joga van rá. Játszottam a jogokkal itt is, sajnos eredménytelenül. Sticky bit nincs bekapcsolva.
És akkor beidézem az smb.conf-ot, a lényeges részeit persze:
[global]
netbios name = sulinet
server string = Keri nagy szerver
workgroup = sulinet
printcap name = /etc/printcap
load printers = yes
printing = cups
cups options = raw
guest account = smbguest
log file = /var/log/samba/samba.log
log level = 1
max log size = 1000
security = user
username level = 8
password level = 8
username map = /etc/samba/smbusers
add user script = /usr/sbin/useradd -d /home/profiles/'%u' -g smbusers
add machine script = /usr/sbin/useradd -c 'Machine' -d /dev/null -s /bin/false %m$
smb passwd file = /etc/samba/smbpasswd
encrypt passwords = yes
unix password sync = Yes
passwd program = /usr/bin/passwd '%u'
passwd chat = *Az*+j*UNIX*jelsz+-* %n\n *+rja*be*+jra*az*+j*UNIX*jelsz+-t* %n\n *passwd:*all*authentication*tokens*updated*successfully*
null passwords = no
socket options = TCP_NODELAY
interfaces = 127.0.0.1/8 192.168.2.0/24 192.168.64.0/24 10.0.1.0/24 192.168.3.0/24
local master = yes
os level = 33
domain master = yes
preferred master = yes
time server = no
dos charset = UTF-8
display charset = UTF-8
domain logons = yes
logon drive = z:
logon home = \\%L\malacpersely
logon path =
# logon path = \\%L\profiles\%u
# logon script = logon.bat
# logon script = %G.bat
name resolve order = wins lmhosts bcast
wins support = yes
wins proxy = yes
dns proxy = yes
preserve case = yes
; short preserve case = no
; default case = lower
; case sensitive = no
winbind use default domain = no
idmap uid = 16777216-33554431
idmap gid = 16777216-33554431
template shell = /dev/null
nt acl support = yes
public = yes
inherit permissions = yes
[malacpersely]
comment = Kozos Diak Megosztas2
guest ok = No
inherit permissions = no
path = /kozos/kozos/Diakdolgozatok
browseable = No
read only = No
public = no
valid users = @diakok
#write list = @diakok // ha kiveszem a kommentet, akkor se müxik :S
writable = yes
directory mask = 0777
create mask = 007
//És most jön két tanári megosztás, kb. 60 ilyen bejegyzésünk van, minden tanárnak saját, nem //sorolnám fel mindet, ugyanez csak más-más változókkal.
[ila]
path = /kozos/kozos
writable = yes
browseable = no
valid users = ila
[beata]
path = /kozos/kozos
writeable = yes
browseable = no
valid users = beata
// hát nagyjából ennyi az smb.conf, legalábbis azon része amelyről úgy gondolom, hogy fontos ezzel az egésszel kapcsolatban. Beidéztem a teljes [global] részt, a [malacpersely] megosztást, és példaként két tanári megosztást.
A diákok windows tartományon keresztül jelentkeznek be, nekik a megosztás automatikusan felmappelődik, a tanárok gépei nincsenek tartományban, ők kézzel csatolják fel a saját megosztásukat (pontosabban, írtam egy pici kis delphi programot, ami semmi mást nem csinál, csak bekéri a nevüket és a jelszót, és azok alapján egy megfelelően formázott 'net use' parancsot lefuttat.). Mindenki jelszava egy smbpasswd file-ban tárolódik.
Kb. ennyit tudok elmondani. Mindenféle segítséget szívesen veszek.
u.i.: amit mondtatok, hogy egy cron script esténként törölje a mappa tartalmát, ezt mondta kollégám is, és nem is rossz ötlet, sőt végső esetben ez lesz belőle... csak szeretném ennél kicsit elegánsabban megoldani a dolgot.
Köszönöm előre is mindenkinek, a virtuális és/vagy valós sör továbbra is áll:)
-- Tamás
- A hozzászóláshoz be kell jelentkezni
Szerintem a cron.script lesz a megoldás (és dehogynem elegáns... na jó, legalább működik!), átmenetileg megteszi. Évvégén (nyári szünetben), vagy akár addig is érdemes kipróbálni (ha van tesztgép, valami hulladék, vagy olyan amire egyébként is újra kell telepíteni a winfos-t) egy másik disztrót is, pl Ubuntu (már ha nem tartod bugbányának), vagy Debian-t, esetleg PCLinuxOS-st (ami beállító felületre tiszta Mandriva, bár szerintem jobbak a csomagok, és APT-os disztró RPM alapokon.)
/mazursky
- A hozzászóláshoz be kell jelentkezni
Ahogy időm engedte, próbálkoztam a dologgal. Leginkább sikertelenül. Pillanatnyilag már azt sem bírom átlátni, hogy milyen logika alapján közvetíti a linux alatti fájlrendszer jogokat a samba a windows kliensek felé. Próbálkoztam a hagyományos user/group/others jogosultságokkal és ACL beállításokkal. Ami linux alatt logikusnak tűnik, és működik (mint pl. az általad beállított módon), az sambával nem jön össze.
Korábbi samba verzióval (3.0.10) a malacpersely könyvtárra 733 jogosultságot beállítva a leírthoz hasonlóan működik, a felhasználók írhatnak a könyvtárba, de nem olvashatják azt vissza. Az általam használt jelenlegi samba verzióval (3.0.25b) az így beállított könyvtárakhoz a felhasználók már nem férnek hozzá.
Az egyetlen, nem túl elegáns megoldás amit találtam, hogy arra a megosztásra, amivel a tanárok elérik a malacperselyt, az adott felhasználónak admin jogot adok (admin users =), így az illető tényleg bármit csinálhat.
Ha esetleg találnál majd megoldást, megírhatnád. Van egy szerverem egy középiskolában és azt hiszem a tanárok imádnának egy ilyen megosztást.
Egyébként nem hiszem, hogy disztró specifikus lenne. Én Centossal és Ubuntuval próbáltam.
------
Λ4Иł)4
- A hozzászóláshoz be kell jelentkezni