Én szeretem a Linuxot asztalnak is, de...

 ( zz7 | 2018. december 8., szombat - 11:15 )

...de néha annyira mégse. Mint például az ilyen eseteknél.

Készítek Debian 9 alatt egy semmi extra, alap Samba megosztást, ő a főtallózó is.
- Ubuntu Desktop 18.04 tallózással nem lát semmi megosztást, a Samba szervert se, üres, cifs-utils, smbclient, samba telepítések után se
- Ubuntu Mate 18.10 ugyanígy szintén
- Fedora 29 szintén vak grafikusan a Samba szerver felé
- Windows 10 frissen telepítve, böngészve azonnal látja
- feltettem kíváncsiságból egy ilyet és csodálkozásomra azonnal látja a Debian Samba szervert és megosztásait: https://distrowatch.com/table.php?distribution=openindiana

Miért kell ennek (is) így működnie???

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Bizonyara a gonosz Microsoft eltitkolt valamit ami miatt nem mukodik rendesen Linux alatt.

Debian 9 Mate rögtön telepítés után látja, kezeli.

Csak tipp, de nem lehet, hogy SMB protocol szinten a különböző disztrók különböző kliensei más protocol verziót beszélnek, és ezért csak azon kliensek mennek amik a szerver által használt / támogatott verzióval próbálkoznak?
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Persze, valószínű hogy valami ilyen van mögötte. Ezt én is értem. Csak azt nem miért nem lehet ezeket egyformán megcsinálni. Egy ma támogatott Debian 9 egy testing változattal már nem beszélget ezen a téren. Egy Windows 10, Solaris x86 utód Unix meg mindkettővel.

"Csak azt nem miért nem lehet ezeket egyformán megcsinálni."
Mert a disztrókat nem ugyan arra hegyezik ki.. Debian tipikusan az a disztro ami stabil szervernek hirdeti magát, míg más disztrók inkább arra mennek rá, hogy publikus teszt platformok legyenek, ahol az újnál újabb dolgokat lehet "élesben" tesztelni.
Ha most az a helyzet állt elő, hogy az általad használt SMB protokol a többi disztróban nincs engedélyezve (mondjuk valami biztonsági okra hivatkozva), de Debian úgy dönt, hogy ő ezt a támogatást meghagyja (backward compatibility, régi kliensek támogatása, mittom én), akkor ez innentől részben Debian specifikus viselkedés.

Ezért is van, hogy amikor az ember disztrót választ, akkor azt is figyelembe kell venni, hogy azt mire szánják, illetve a kiadási ciklusokat mennyi ideig tartják karban.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Most úgy elképzeltem a kereskedelmi NAS fejlesztőket, azok hogy állhatnak ehhez a kérdés csomaghoz. Gondolom az lenne ott a cél hogy minél több fajta klienssel működjön rendesen az SMB megosztás és tallózás. Vagyis ennek érdekében a legkompatibilisabb, de legkevésbé biztonságos megoldást fogják választani protokoll szempontból?

Persze ez a részemről csak egy fajta panaszkodás kör. Ha akarom természetesen gépnévvel, IP címmel felcsatolom a megosztásokat és annyi. Nekem személy szerint ez nem probléma. De hogyan hagyjak ott valahol normál mezei felhasználóknak egy vegyes felállású rendszert ha lehet már másnap telefonálnak hogy ez nem működik? Meséljek nekik a biztonsági problémákról meg a kiadási változatokról?

Idézet:
De hogyan hagyjak ott valahol normál mezei felhasználóknak egy vegyes felállású rendszert ha lehet már másnap telefonálnak hogy ez nem működik?

TLDR: Úgy, hogy megfelelően bekonfigurálod

Bővebben: Ugye az egész "panaszkodás kör" onnan indult, hogy a gyárilag felrakott csomag így vagy úgy de nem kompatibilis más disztrók gyári telepítésével. De a gyári telepítés nem azt jelenti, hogy csak úgy lehet használni az adott programot adott disztró alatt: Simán azt jelenti, hogy a disztróban lévő csomag karbantartója esetleg más gyári konfiggal szállítja az adott csomagot. De ez nem jelenti azt, hogy azt a konfigot ne lehetne átszerkeszteni, és a program / bináris által támogatott egyéb módon belőni.

Szóval kérdésedre válaszolva, hogy a kereskedelmi NAS fejlesztők mit és hogy csinálnak a válasz simán az, hogy ők nem gyári distro csomagot szállítanak, hanem vagy vesznek egy alap disztrót és annak a csomagját testre szabják, vagy a csomagot is már maguk fordítják (esetleg saját patcheikkel), és maguknak is konfigolják be azt, hogy az aztán minél több eszközzel kompatibilis tudjon maradni.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Konkrétan milyen csomagokra gondolsz? Samba és smb.conf? És a grafikus asztali Linux klienseken amin ezek nincsenek is telepítve mert nem kell, de a grafikus fájlkezelővel kellene elérni az SMB megosztásokat amik jó lenne ha egységesen működnének?

Azt én sem tudom, mitől megy olykor, máskor meg nem, de ha a címsávba beírom, hogy smb://server, persze a server IP-címe a hosts file-ban fel van oldva, akkor működik.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kicsit szerintem itt összekeveredik 1-2 dolog (főleg, hogy az előbb még NAS-ról beszéltünk, ami egyértelműen szerver funkciót takar, nem pedig desktopot)

Egyik oldalról van ugye a szerver, ami adja a szolgáltatást (ilyen vagy olyan konfiggal)
Másik oldalról meg vannak a különböző féle és fajta kliensek, amik majd ezt megpróbálják használni, aztán vagy sikerül nekik, vagy sem.

Abba már előzőleg belementünk, hogy mivel több fajta kliens több féle módon próbálkozik, így szerver oldalon kell úgy konfolni a szolgáltatást, hogy az minél több klienssel legyen kompatibilis. Ebbe innentől beletartozik a protokol verzió(k), authentikáció, illetve security beállítások.

Ez mellé keveredett most még ide az, hogy adott kliens gépek hogy is találják meg a szolgáltatást, illetve hogyan detektálja, hogy az adott szolgáltatás milyen protokol verzió(ka)t támogat. Itt viszont már meglehetősen sok új dolog bejön a képbe, kezdve a desktop kliens által használt file managerétől (Nautilus Vs Dolphin Vs Windows File Manager / File Explorer), annak integrációjával az adott szolgáltatás által használt protokol felé (ezt most belsős lib adja, vagy külsősre dependál - azok közül is melyikre, és az mit is támogat), illetve, hogy adott rendszer képes e adott hálózaton belül az ilyen szolgáltatásokat automatikusan detektálni valamilyen más eszközre hagyatkozva (nmblookup Vs smbtree Vs avahi-browse Vs cifs-utils).

És akkor még a hálózati oldalról (tűzfal szabályok, névfeloldási nehézségek), és WORKGROUP beállításokról nem is beszéltünk amivel ezen kliensek jönnek

____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Van valami baszakodás, hogy régebbi samba verzió tiltva van mert nem biztonságos, emlékszem szívtam emiatt kodival.

+1

Fedorából is kigyomlálták ezért. Lehet, hogy a kódban megvan, de a default konfigból kiszedték.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Off: speciel ez a 'látom a hálozatot' dolog sosem volt jó ötlet, és sosem is működött megbízhatóan. Egy 2003-as példa: http://forum.index.hu/Article/viewArticle?a=30981341&t=9028250

Kb ebben az időben a kollégiumunkban a helyi hálózat adminisztrátorainak a hozzá-nem-értése eredményezte, hogy a tallózás rettenetesen lassú volt: nem volt WINS szerver és az összes nyomorult windóz állandóan harcolt a master-browser-ségért.

Fogtunk egy Slackware telepítést, és beállítottuk a samba-ban OS levelnek a maximumot. Fél órán belül lecsendesült a hálózat, a Slackware begyűjtötte a browse listát, és innentől ő szolgálta ki mindenkinek. 2 gép maradt a hálózaton, akik rendszeresen küldtek challenge-et, de persze nem kapták meg: két, magát NT4 Server-nek mondó valami, de már nem mentünk utánuk.

Innentől viszont ment a dolog rendesen, linuxokon is, nem kellett baromkodni azzal, amit a linken leírtak, illetve Win95/98-ak esetén a NetBEUI protokollt érdemes volt ettől függetlenül is leszedni (ez pl. hazavágta a StartCraft LAN tallózását)

Ha jól értem akkor linux alatt akarod használni, akkor miért a samba a választás?

Teljesen vegyes kliensekről van szó desktop oldalról, Win, Linux, néha Apple is. A szerver pedig Linux.
De mondom megint, ez nálam itthon nem gond mert persze megoldom, tudom hogy kell ha nem látják egymást. Hosts vagy IP cím és megy minden. Csak akkor van a gond amikor ott hagysz valahol egy Linux/Samba szervert és már nincs rálátásod a dologra, de néha jönnek ilyen, olyan desktop gépek és rád panaszkodnak a hátad mögött hogy nem tudsz rendesen beállítani egy fájlszervert mert a csak felhasználó szint nem tudja hogy mit kell csinálni ha nem látszik a szerver a hálózaton. Vagyis csinálhatunk Linux/Samba szervert, de mindegyik alkalmi, változó, új, vendég kliens gépnek nem foghatjuk a kezét állandóan és igazíthatjuk a klienst a szerverhez ha nem vagyunk ott, nem is tudunk róla hogy gond van.
És úgy látszik erre a dologra már a nagy Linux terjesztők se nagyon figyelnek oda, mert már egy előző és aktuális Debian, Ubuntu stb. között is nem egyezés van ezen a téren.