Samba és a Clipper

 ( Polesz | 2018. február 28., szerda - 22:08 )

Az egyik cégnél sikerült egy SAMBA szervert beszervezni a mindennapi munkába (Zentyal 5.0 egyébként).

Ami problémaként előjött, hogy sajnos régebbi Clipperben írt programokat használnak és belassul, valamint az index kezelés is szétesik. Eddig Novell hálózat alatt voltak az alkalmazások és adatbázisok, de ott nem jelentkezett ez a probléma.

Olvastam az oplock témakört ebben, de igazán nem tudom mit nézzek, vagy vezessek be. A Samba doksit az oplock körében átnyálaztam, de egyelőre sötétség van.

Előre is köszönöm a segítséget.

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ő.

A triviális paraméterek összehasonlítása (RAM, háttértár sebessége) megvolt már?

Csak mert a szoftver ódonsága miatt el merem képzelni a hardveren garasoskodást is.

jó az irány, az oplock-ot tiltsd le az egész share-re, vagy csak az adott fileokra.

veto oplock files = /*.DBF/*.dbf/*.MDX/*.mdx/*.ITB/*.itb/*.MDB/*.mdb/

Sorold fel az összes kiterjesztést, amit használ a Clipper.
(Úristen, ilyen még létezik? Olyan idős koromban programoztam Clipperben, mint a nagyfiam most).

Esetleg a komplett share-re tiltsd az oplockokat.
A Zentyalal mindenesetre jol tokonlotted magad, mert minden ilyet bonyolultabb rajta megcsinalni mint egy sima Debian + samba4 szerveren, irogathatsz hookokat, mert minden konfig update-el at fogja irni a kezzel bereszelt modositasokat.
Nem beszelve arrol h a devel ag egy instabil bughalmaz.

Oplock tiltás menni fog. A Zentyal amikor adva lett nem volt szó hogy az őskort kell támogatni :)

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

Nekem a stabilitásával nagyon sok problémám volt, mindettől függetlenül is.
Pure Debian óta nincs az h. hol ezért, hol azért valami szolgáltatást újra kell indítani mert nem v. csak részlegesen működik.

Ezexerint a szamba azóta is sz@r ilyen környezetben...? https://hup.hu/node/67045

Ez nem samba hiba, ez SMB protkoll ilyen, Windows szerverrel is ugyanez a probléma. Oplock esetén a kliens önmagában cache-el így a kliens nem tud róla ha más kliens is módosította a fájlokat így a szerverre visszaküldve felülírják a kliensek egymás módosításait. SMBv1 protkoll esetén (<=Samba3.5) szerver oldalon ki lehet kapcsolni az oplock-ot. SMBv2(>=Samba3.6)/SMBv3 esetén(Samba4) szerver oldalon már nem lehet kikapcsolni (így v2/v3 esetén samba oldalon sem és Windows szerveren sem, főleg, hogy itt már nem oplock van hanem leases aminek a lényege ugyanaz mint az oplocknak de a samba-nak is külön opcioi vannak v2/v3 leases tuninghoz), de SMBv2 esetén kliens oldali registry túrás még segíthet (FileInfoCacheLifetime, FileNotFoundCacheLifetime, DirectoryCacheLifetime, stb.). SMBv3 esetén elvileg semmi nem segít (bár ezt nem próbáltam mert az SMBv1 a Clipper barátja...). Ha Windows 10 a kliens és Samba4 a szerver akkor SMBv3 lesz az alap közöttük. Samba4-nél a "server max protocol = NT1" segíthet vagy Windows 10 oldalon az SMBv2/SMBv3 letiltása, és SMBv1 engedélyezése mert a Windows 10-ből a legutolsó nagy frissítés óta gyilkolja a Microsoft az SMBv1-et. A másik, hogy valahol azt olvastam, hogy ha a Windows 10 tartományba van léptetve akkor kizárólag SMBv3-at akar használni. (szintén nem próbáltam). Ez esetben mondjuk VM-ben futtani kell egy XP-t a régi Clipper szoftvernek mert Windows 10-en Samba4-el már szorul a Clipper nyakán hurok...

Ez windóz szerverrel is ugyanígy gond :)

Hogy a sötétséget segítsek eloszlatni az alábbi linken részletesen leírják, hogy mi ez az oplock és miért kell kikapcsolni osztott adatbázisok esetén: http://oregontechsupport.com/samba/

#nemide