Samba megosztás csak írhatóan

Linux-haladó

Sziasztok!

Segítsetek, kérlek, eddig nem találtam rá megoldást.

Van egy Debian alapú fájl szerver, rajta több Samba megosztással. A gépen vannak felhasználók, valamint csoportok. Minden felhasználó tagja természetesen a Users csoportnak, ezen kívül van Peénzugy, Informatika, Vezetes, Raktar, stb csoport. Valamint van egy eSzamla nevű csoport is.

A szerveren vagy egy mappa, amit szeretnék megosztani:

    - Útvonala: \\srv\data1\e
    - Megosztás neve: eSzamla

A következőt szeretném megoldani:

    - A \\szerverem\eSzamla útvonalra minden felhasználó tudjon írni (pontosabban az ügyviteli rendszerünk mentené ide az elektronikus számlákat)
    - Ugyanez igaz bármely felhasználó által létrehozott almappára (az elektronikus számlák mappastruktúrába kerülnek Cég\Év\Hónap\számlaszám.pdf formátumban.)
    - A megosztáson levő állományokat listázni, olvasni csak az eSzamla csoport tagjai tudják
    - A tökéletes megoldás netovábbja lenne, ha a megosztásról csak az Informatika tagjai tudnának törölni

Mit kellene ehhez megadnom az smb.conf-ban? Egyáltalán megoldható ez a mód?

Gábor

  • 691 megtekintés

( x-daemon | 2021. 07. 07., sze – 20:18 )

az ugyviteli rendszer miert nem "sajat magaba" (ugy ertem sql-be mert feltetelezem oda dolgozik) menti el az elektronikus szamlakat?

ott meg mindenkinek olyan jogot adsz amire szuksege van

neked aztan fura humorod van...

Az ügyviteli rendszer természetesen tárolja a számla adatait. Viszont az elektronikus számlát (ami egy pdf állomány, ebből van képezve az a HASH, ami a NAV rendszerébe felkerül) archiválnom kell, ezt nem akarom adatbázisba tolni, mert csak felesleges ballaszt lesz. Ezeket a pdf-eket mentem erre a megosztásra. Az természetesen nem megfelelő megoldás, hogy amikor szükség van rá, legenerálom a pdf-et, mert a HASH érték garantáltan változni fog.

Nem értek egyet. A pdf tárolását és őrzését az adótörvények miatt kell megtennem. Napi működéshez nem kellenek. Ezekhez a pdf-ekhez csak akkor kell majd nyúlnom bármikor is, amikor majd kapunk egy NAV ellenőrzést és be kell mutatnunk az eredeti példányt.

Most az elmúlt 4 - igen csendes! - nap alatt jött létre 100 pdf, 2,5M-t foglal. Ha ezt felszorzom a havi, évi mennyiséggel, akkor teljesen feleslegesen terhelem a napi, heti, havi mentéseket, a mentések mentéseit is, valamint aktívan terhelem az adatbázis kezelőt is ezzel az adatmennyiséggel.

A papír alapú számlákat sem tárolom az sql adatbázisban - hehe! -, pedig együvé tartoznak....
Természetesen ez nem jelenti azt, hogy a számla adatai ne lennének meg az ügyviteli rendszerben, az egész probléma csupán a számlakép fizikai megjelenésének a tárolásáról szól.

Gábor

Mennyire terheli a rendszert, ha van egy táblád, amibe napi 50-200 írás történik, olvasás gyakorlatilag csak mentésnél? Ez mekkora többletköltség ahhoz képest, hogy egy, a rendszeren kívüli megoldásban tartod ezeket az adatokat? Vedd figyelembe azt is, hogy a fájlszerveren tárolt fájlokat legalább ugyanolyan biztonságban kell tartanod, mintha az adatbázisban lenne.

Nem értem, miért kell erőltetni egy olyan megoldást, amit már megmagyaráztam, SZÁMUNKRA miért rossz? Ezek a pdf-ek alapvetően holt balasztjai a rendszernek (mint mondtam, csak a NAV ellenőrnek fog kelleni). Minek terheljem a rendszerünket vele?

A mentése is sokkal egyszerűbb, mert a file szerverről inkrementálisan történik a mentés (tehát mindig csak az újakat fogja átmásolni a mentés helyére), addig minden adatbázimentéssel az összes benne tárolt adat ismételten mentésre kerül.

És igen, az adatbázisszervert igenis terhelni fogja az, ha éves szinten beletolok 2-3G adatot feleslegesen.

Nem erőltettem, csak feltettem egy egyszerű, ám üzemeltetői szempontból fontos kérdést. Mert azt a „ballasztot” 5–8–10–kitudja hány évig úgy kell megőrizned, hogy ha elveszted, az könnyen lehet, hogy sokkal költségesebb dolog lesz, mint 20 GB egy alvó táblában.

Ezt értem, természetesen nem csak egy mentésünk van, ami érinti az adatbázisokat, valamint egyéb dokumentumokat is. Ezzel nincs is gond.

Egyébként itt is képbe kerül a biztonság: ha az adatbázis mentés (ami egyetlen állomány adatbázisonként), akkor csak az adataink ugrottak. Míg ha ez tartalmazza az eszámla pdf-jeit is, akkor ezzel az egy hibával máris vesztettük az adatok mellett az elektronikus számlák példányait is....

Ez nem teljesen így van. A kibocsátott számlák esetében a kibocsátónak lehetősége van megőrizni a papír alapú számlákat elektronikus formában is, feltéve hogy a számla olvashatósága és sértetlensége biztosítva van.

Erről itt lehet olvasni: https://nav.gov.hu//data/cms558992/18_A_szamla_nyugta_kibocsatasanak_al…

 

A 13. oldalon:

A számlázóprogrammalelőállított és papírra nyomtatott számla kibocsátónál maradó példánya elektronikus adatállományként is megőrizhető, feltéve, hogy a megőrzés a digitális archiválásra vonatkozó előírásoknak77megfelelően történik.78

Az "előírásoknak megfelelő" lehet például az, hogy ha a papír alapú számlát is PDF-ből nyomtatod, és a PDF hash-t ugyan úgy beküldöd az online számla rendszerbe, mintha elektronikus lenne. Ez garantálja a sértetlenséget és az olvashatóságot.

Külön jó dolog, hogy ez mentesíti a kibocsátót a saját példány nyomtatásától, így papírt és festéket is megtakarít.

Pont erre van mssql-en a filestream. SQL szinten éred el, SQL szinten szabályozod a hozzáférést, de mégis egyenként lerakja a filerendszerbe a file-okat és onnan olvassa fel, ha selectet kap rá, tehát nem terheli az adatbázist, de mégis megkapsz minden okosságot, amivel egy adatbázis többet nyújt mint egy file share.

( zeller | 2021. 07. 07., sze – 21:24 )

Linuxos fájlrendszerekben van már jogosultságokra normális öröklődés...?

POSIX-szerű Linux/UNIX fájlrendszer esetén a hozzáférési jogosultságok az inode-ban vannak tárolva, az pedig nincs közvetlen, egy-az-egyhez viszonyban az elérési úttal. Egyazon inode-hoz több link tartozhat, teljesen más elérési utakkal. Innentől a klasszikus NTFS/NWFS/NSS értelemben vett öröklődés technikailag nem értelmezhető és nem implementálható.

Samba share esetén a hozzáférés kontrollt maga a Samba adja, tehát az öröklött jogok csak akkor működnek, ha a Samba API-n keresztül éred el a megosztott fájlrendszert. Ha a Samba API "mögé" nyúlsz - pl. az adattárolásra szolgáló ext4 fájlrendszer közvetlen írásával/olvasásával, akkor ott nem fogsz találni örökölt és örökölhető jogokat.

( mauzi v | 2021. 07. 07., sze – 23:43 )

Szerkesztve: 2021. 07. 07., sze – 23:44

A csak írható könyvtár technikailag a legtöbb fájlrendszeren megoldható, de készülj fel arra, hogy sok szoftver nem fog tudni vele dolgozni. A szoftverek ugyanis a fájlok kezelése során tipikusan végeznek olvasási műveleteket is, amiknek a meghíúsulására a programok nagy része egyáltalán nincs felkészítve. (Mi próbálkoztunk ilyennel, a legtöbb irodai szoftverrel használhatatlan volt.)

( x-daemon | 2021. 07. 08., cs – 00:56 )

lehet hogy valamit rosszul ertek, de ha nincs mas megoldas es mindenkeppen a fajl szerveren kell eltarolni az elektronikus szamlakat akkor valami ilyesmit allits be:

valid users = @eszamla @it ugyviteli_rendszer

write list = @it ugyviteli_rendszer

read only = yes

10 eve nem csinaltam ilyet szoval teszteld is le!

a konyvtarstrukturat ne a @eszamla csinalja kezzel hanem pl. az ugyviteli_rendszer automatikusan

neked aztan fura humorod van...

vagy a kliensben a pdf megosztasra valo feltoltesekor az ugyviteli_rendszer felhasznaloval csatlakozol

vagy

ha ilyet nem lehet akkor 2 kulon megosztas ami ugyanazt a fajlrendszer utvonalat hasznalja, egyik az eszamla_upload ahova ugyviteli_rendszer felhasznaloval csatlakozol, masik az eszamla ahova a felhasznaloval

neked aztan fura humorod van...

Én azt olvastam, bár nem próbáltam ki, hogy a bejelentkezési adatokat vagy IP címhez köti (ha a megosztás elérése pl \\192.168.10.2\valami), ekkor minden 192.168.10.2-vel hivatkozott megosztást ugyanazzal a felhasználóval akar majd elérni a win, vagy gépnévhez rendeli (pl \\szerverem\valami és a \\szerverem\masikmegosztas is ugyanazzal a felhasználóval fogja majd elérni).

Természetesen ha a szerverem név és a szerveremmasikneve név mögött is ugyanaz a gép van, akkor az már tud különböző felhasználóval működni. Erre találtam példát, amikor a hosts állományba tettek két bejegyzést, ahol a név különbözött, de ugyanazt az IP-t tették mögé. Ilyenkor a win különböző névnek látja, így hozzárendelhető különböző felhasználó.

Ebbe az irányba azért nem indultam el, mert nem szeretném, hogy minden egyes klienssel külön-külön foglalkozni kelljen emiatt.

( junior013 | 2021. 07. 08., cs – 13:29 )

Buher megoldás, de anno úgy oldottam meg hasonlót (úgy legyen írási joga, hogy közben ne olvashassa vissza a megosztás teljes tartalmát), hogy az írható megosztás Linux oldalon egy másik mappa, ahonnan inotify pakolja át a file-okat írás után a RO archív struktúrába.

Illetve rémlik egy olyan megoldás (régen volt már, de azt hiszem, később erre álltunk át), hogy maga a Samba is tudja módosítani írás befejezése után a file jogait és tulajdonosát és azonnal eltűnik az író elől.

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"