Tudom, ilyenkor szokták mondani, aki nem tud érdemi hozzászólást, inkább ne szólaljon meg. De mégse érezd úgy, hogy a kutya sem törődik a kérdéseddel. Szerintem kezdd itt.
A problémám a következő: Van egy Windowsos hálózat, egy Wines domain szerverrel.
Ehhez szeretnék hozzácsapni egy Linuxos rendszert (Ubuntu 9.04), ami hasonlóan kéne, hogy működjön: A Linux egy passwordot kérjen, amivel a delikvens bejelentkezik a Linuxba és a hálózatba egyaránt és elérheti a jogosultságait a szerveren. Akár az is jó lenne, ha egy közös guest userként lépne be a Linuxba és eközben megtörténne a hálózati azonosítás és mappelés.
Sajnos még nem vagyok nagyon járatos a Linuxban, így ha lehet akkor szájbarágós tanácsot kérnék... :)
Van egy fedora-s masinám és egy vista-m. A fedora-n samba-val megosztott könyvtárakat csak akkor látom a vista-n, ha a tűzfalat kikapcsolom. A tűzfalban engedélyeztem a samba portjait (137-139) és a 445-öst (ds-windows talán?), mégsem sikerál. Szóval itt megakadtam. Mi lehet a porbléma?
Szerintem ha sambára állsz át, akkor annyit változna a helyzet, hogy VPN-el indítana az otthoni user (a pptp-t az újabb linux disztribek minden cafrang nélkül kezelik, windows kompatibilis módon), és szigorúan workstationból indítanák.
Amikor létrejött a kapcsolat, akkor mountolnák a hálózati meghajtót, vagyis az user távoli elérés esetében: helyi bejelentkezés -> VPN kapcsolat indítása -> hálózati meghajtók csatlakoztatása.
Távoli elérés esetén szerintem ellenjavallt a domain, mert pl. mi van olyankor, ha például az user egy DVD image-t töltött le az asztalára? Kijelentkezéskor fel akarja tölteni a domain kontrollenek, bejelentkezéskor meg letöltené. Mindezt mondjuk egy otthoni 256KB-os feltöltési sávszéllel.
Ötlet: linux PPTP VPN, ezt akár a tűzfal is kezelhetné. Innen kezdve a távoli user a helyi háló része ugye, minden cafrang nélkül eléri a sambát. A samba ugyan nem tartományvezérlő, ezért login script sem fut le a bejelentkezésnél, de ha az usereknek csinálsz egy olyan batch file-t, ami először a VPN-t indítja, majd felcsatlakoztatja a hálózati meghajtókat, akkor kezelhető a dolog. kiteszed az asztalukra nekik és azt indikják, tehát nem sima VPN kapcsolatot.
A kapcsolat bontásánál kapnának hibaüzenetet az userek, mikor is nem érik el a hálózatról csatolt meghajtót, de ez szerintem nem olyan nagy vész. Azzal együtt lehet élni.
Bocs, ha érthetetlen vagyok. Tehát jelenleg a következő a helyzet: 1. Van a munkahely. Belső háló, Linux tűzfallal és egy őskövület Novell. Bejönnek dolgozni a dolgozók. Bekapcsolják a gépet, bejön a Novell login. Beírják a felhasználót, jelszót és bejelentkeznek a Novell-be. Itt vannak login scriptek, hálózati meghajtók, hálózati nyomtatók. Nincs gond. 2. Ha valaki a nótijával otthonról szeretne dolgozni a fájl szerveren, akkor a következőt kell tennie jelenleg. Hazamegy. Gép bekapcs, Novell bejelentkezőn beállítja, hogy csak a Workstation-re jelentkezik be. Bejelentkezik a gépére, majd az asztalon elindítja a Windows-os VPN-t a cég szerverére, mert a fájl szerver a tűzfalon belül van. Ezután már be tud jelentkezni a Novell-ra, et voilá vannak hálózati mappái. (Az más kérdés, hogy egy 20/2 mbit-es nettel is csak kb. 20-25kbyte/sec-el tud a hálózati meghajtóra dolgozni.) És ami a legfontosabb, a gépet nem kell újraindítani. A user háklis;(
Tehát Samba-val szeretném azt megoldani, hogy legyen Login script központilag managelhető. Ehhez úgy tudom - tudásom csekély ez ügyben, ezért kérdezek - domain kell.
Amit nem tudok, mert még nem is próbáltam, hogy amikor beállítom a Windows-os gépen, hogy Domain-ba szeretne bejelentkezni, akkor a gépet újra kell indítani. Ezután bejön a Windows-os login, amivel már be tud jelentkezni a Domain-be. DE, ha nem a helyi hálón van a gépe, azaz pl. otthonról dolgozik, akkor mielőtt a Domain-ba bejelentkezik, be kéne a VPN-re jelentkeznie - mivel a fájl szerver a tűzfalon belül van -, az pedig csak akkor elérhető, ha már a workstation-re bejelentkezett, nem?
ps. én már ott lemaradtam, hogy miként jelentkeznek be egy helyi desktopra, és minek. Illetve miért nem rögtön VPN-el indítanak, hisz rögtön a helyi háló részét képeznék. És nem értem hogyan kerül képbe itt a domain, főleg távoli hálóról. Az úgy használhatatlanul lassú lesz a sávkorlát miatt.
Sziasztok! Mostanság szeretnék Samba-t használni fájl szerver és nyomtató szerver funkcióra. (Szeretném végre a Novell-t lecseréni, mert útálom;( Olvasgatok és kiderült, hogy a domain-t nem úszom meg, mert - a domain-ben lehet központi címtárat használni és az jó, - a domain-ben lehet központosított login script-et használni. (Bár hozzá teszem ez csak azért kell, hogy lehessen minden usernek egy saját hálózati meghajtója, amihez csak neki van jogosultsága, másnak nem. (Lényegében az egész Samba e miatt kellene)
Szóval a problémám a következő: Vannak userek, akik otthonról dolgoznak. A Novell elérése eddig úgy történt otthonról, hogy bejelentkeztek a local gépre (workstation only), ezután VPN-en kapcsolüdtak a szerverhez, majd ezután jelentkeztek be a Novell szerverre, hiszen a VPN kapcsolódás után már, belső IP címet kaptak)
Viszont a domain-be bejelentkezéshez minden esetben újra kell indítani a gépet, és a domain-be való bejelentkezés után lehet csak VPN-nel kapcsolódni a szerverhez. De ez egy ördögi kör, mert a domain-t csak a belső hálózatról lehet elérni a VPN kapcsolódás után.
Tehát van-e mód bejelentkezni a domain-be úgy, hogy ne kelljen a gépet újraindítani?
Létrehoztam egy SAMBA alapú tartományt Ubunutu 8.10 alapokon, a samba configban a login path = opcióval (vagyis semmi, nincs szerveren tárolt profiljuk). Tehát nincs vándorló profil, semmi ilyesmi. A gondom az, hogy hiába jön létre a Windows XP kliensen a profil, ha az SMB-s PDC offline állapotban van a W. számára (pl. mert laptopja van az illető felhasználónak és elciepli magával valahová máshová), akkor a felhasználó nem tud belépni, hiába van ott a gépen a profilja. Az interaktív login, felhasználói adatok cacehlése a windows felhasználói fiókoknál eleve 10 volt, de már felvettem 50-re, nem mintha ez segítene.
Mi a megoldás?
Tartományt eddig csak NT4-es szerverrel üzemeltettem és ott ugyanilyen kliens-beállítások mellett simán belépett a kliensgépen a felhasználó akkor is, ha az NT4-es PDC offline volt (és BDC se volt a rendszerben, tehát mondjuk hazacipelte a laptopják ,konfeerncián volt stb.). Viszont mindenképpen kell a domain, mert egyébként a felhasználók képtelenek felcsatlakoztatni pl. az smb-s megosztásaikat, meg van is belőle pár darab, tehát manuálisan is eléggé macerás lenne.
A probléma, amit leírok, nem biztos, hogy Samba, de nagy a gyanúm...
Adott egy Asus WL-500gx router, ezen már gyárilag linux fut, amit én szépen lecseréltem már vagy 2 éve Oleg-félére. Azóta rá van dugva egy WD MyBook vinyó, Sambával megosztva, mindenki happy.
Ámde most rátettem egy transmission csomagot, hogy ne kelljen bekapcsolva tartani egy gépet, ha valaki torrentezni akar. A letöltés céljaként a Samba megosztáson csináltam egy Downloads könyvtárat, erre konfigoltam a transmissiont.
Bejelentkezem a böngészővel, elindítom a torrentet, szépen kiírja, hogy megkezdi a letöltést... majd 2 másodperc múlva leáll a következő hibaüzenettel: No such file or directory.
Nem tudok mást gondolni, mint hogy a Downloads könyvtárat nem látja valami miatt, de el nem tudom képzelni, mi az. A transmission config fájljában az elérési út jó és abszolút, ezt megnéztem már százszor. Oda mutat, ahova kell. Ebbe a könyvtárba bármelyik gépről lehet írni, látni. A transmission processz admin joggal fut, aminthogy a könyvtár tulajdonosa is az admin. Akkor miért nem látja a transmission?
Nagyjából ennyi kell: 1 Csinálsz egy csoportot mondjuk "kozos" névvel 2 Hozzáadod a felhasználókat a "kozos" csoporthoz 3 Létrehozol egy könyvtárt "kozoskonyvtar" néven. 4 Beállítod a tulajdonost "te" vagy a "root", és csoportot "kozos" a "kozoskonyvtar"-on 5 Beállítod a jogokat 1775 a "kozoskonyvtar"-nak ( az 1-es a sticky ) 6 Előzőleg én is hülyeséget írtam force usert nem kell megadni a sambának, csak force group-ot, ami a "kozos" lesz. Még kell a vendég tiltás a megosztásba és a többi szokásos beállítás.
Ha az egyes felhasználók a saját nevükön lépnek be (nem pedig mindenki ugyanazzal az azonosítóval), akkor ki-ki csak a saját fájlját tudja törölni, a másét nem. Ilyen könyvtár például a /tmp
Köszi szépen a válaszokat. Azért kérdeztem, mert arra én is rájöttem, hogy ha van írásjog a mappán, akkor törölni is lehet. Ezt a sticky bites megoldást el tudnátok magyarázni, kipróbáltam, de igazából nem tudom, hogy kellene csinálni.
Most legszívesebben kimoderáltatnám az előző hozzászólásom. Elszégyelltem magam. Hogy a fenébe nem jutott eszembe? Bár amit a felhasználó tesz fel, azt tudja törölni is, de gondolom, ez nem probléma. Csak a másik cucca a védendő. Bár ha így nézzük, akkor lehet olyat is csinálni, hogy az illető könyvtárban létrehozunk minden felhasználónak egy-egy alkönyvtárat, akönyvtáraknak drwxrwxr-x jogokat adunk. A tulajdonosa mindegyik könyvtárnak a főnök, a csoport az individuális csoport, amely felhasználónként más. Ekkor főnök bármit csinálhat, felhasználó csak a sajátjában írhat, törölhet, és mindenki olvashat bárhonnan, de nem módosíthatja másét.
user1 pedig benne van a user1 group-ban, user2 a user2 group-ban. Persze ha a tulajdonos valamiért nem lehet a főnök, akkor a főnök az összes individuális user csoportban benne van.
De a sticky bites megoldás határozottan egyszerűbb, és erre találták ki.
Szerintem a sticky könyvtáron alkalmazva ( chmod +t könyvtárnév ) tudja ezt. A sambában be kell állítani, hogy a foce user te legyél, és a force csoport legyen a könyvtár csoportja.
Így elsőre a standard linuxos jogkezeléssel nem, mert a file létrehozása és annak törlése is a directory írását jelenti. Tehát vagy mindkettőt lehet, vagy egyiket sem. Az ACL-nek illetve a SElinuxnak kellene utánanézni, ezekkel az eszközökkel lehet, hogy megoldható. Illetve jó kérdés, hogy maga a Samba tud-e ilyet.
Nem tudom hogy lehetséges-e amit kérdezek, de így hangzik: egy megosztott mappát be lehet-e úgy állítani, hogy abba a felhasználók tudjanak feltölteni dolgokat, viszont ne tudjanak törölni belőle?
Ez nem lehet, mert a wines gépek látják egymást név szerint is, mégsincs benne a hosts-jukban a másik gép.
Valszeg valami olyan baj van, hogy nincs local master a munkacsoportban, de nem tudom valamiért rávenni a linuxot hogy az legyen.
Mondjuk a "linuxos gép" egy Asus Wl700-as router openwrt-vel, lehet annyira lebutították a sambát, hogy nem tudja ezt...? Hiába írtam be bármit a conf-ba local master, preferred master és hasonlók, semmi változás.
De már feladtam, hagyom és ip alapján fogom elérni. :)
Gondolom, a név és IP között valami névfeloldási metódus teremti meg a kapcsolatot. Linuxon a /etc/hosts file, Windows-on pedig a %SystemRoot%\system32\drivers\etc\hosts lesz az.
Mit nem csinálok jól, ha windows kliensen az ipcímre elérhető a linuxos megosztások, viszont a névre "hálózati elérési út nem található" hibaüzenet jön és a munkacsoporton belül se látszódik a gép?
