Van értelme Samba használatának fájlszerverként ha a desktopok is linuxok?
Az sshfs számomra jobbnak, gyorsabbnak és egyszerűbb megoldásnak tűnik. Vagy van valamilyen rejtett előnye a Sambanak?
Hozzászólások
Ebben az esetben nem biztos, h vacakolnék a tákolt sambával.
Szvsz a NFS jobb valasztas lenne ( amennyiben nincs szukseged titkositasra ). Az sshfs sokkal jobban terheli a CPU -t.
( Tudom, NFS != samba && NFS != sshfs. :) )
A samban lehet könnyebben mindenféle virtuális userekkel csatlakozni, force user meg hasonlók, a symlinkeken keresztül mappák elérése is sima ügy (unix extensions = off), szóval én pl. sambat hasznalok Linuxok között is, mert egyszerű adminisztrálni, és a net szakadást is relatíve jól tolerálja (mondjuk az nfs hez képest). Sebességben, stabilitásban nem érzem, hogy helyi hálózaton bármi gond lenne vele. Neten mondjuk az sshfs tényleg reszponzívabb lehet.
Srry ha pontatlanul fogalmaztam volna. A következőre gondoltam:
ln -s /home/felhasznalo/docs /home/user/notebook-docs
helyett
ln -s ../felhasznalo/docs notebook-docs
szimlinkekre.
Így sshfs-sel fájlrendszerben bárhova becsatolható másik gépen, ott is jók lesznek a szimlinkek.
Valójában pl. olyan mappát akarok oda symlinkelni, aminek az egész szerkezete egyébként nem elérhető. Tehát a symlink nem dolgok összegyűjtése miatt, hanem kifejezetten elérés biztosítására.
Nagyon régen találkoztam NFS-el... megoldották már, hogyha elszáll valamiért a szerver, majd visszajön, a kliensen ne legyen teljes halál a következő rebootig? :)
Ez önmagában tuti nem elég, hogy ne akadjon be a df, a könyvtár listázás stb, és umountolni sem lehet. Csak umount -l el, ami aztán az újramountolásnál kavarhat be stb. Ha neked ilyen nincs, akkor írd meg pls. milyen kapcsolókat használsz még. mount -o soft,async,timeo=60 stb. ilyenekkel szoktam kíséletezni, de valós leállásnál teljes a kudarc a kliensen is.
Ez jogos, de ha épp csatolás közben van gond, akkor ez nem segít, sőt, még az autofs is bekakál. Viszont legalább nincs mindig mountolva (pl. ftp szervernél)
Hozzászólások
Ebben az esetben nem biztos, h vacakolnék a tákolt sambával.
Szvsz a NFS jobb valasztas lenne ( amennyiben nincs szukseged titkositasra ). Az sshfs sokkal jobban terheli a CPU -t.
( Tudom, NFS != samba && NFS != sshfs. :) )
Igen sshfs nagyon terhel. max
-o cipher="blowfish"kapcslóval. De az NFS a jó választás.ezzel alig terheli a titkosítás a cput.
Még ezeket szoktam bekapcsolni:
Lokális hálón természetesen.
Továbbá a /etc/ssh/ssh_config fájlba az alábbiak
a gyorsabb timeouthoz ha leszakadna a szerverről (pl sleep és elviszik a notebookot)
Ha meg titkosítás kell, az IPSec -et könnyű felétenni.
nfs +1
A samban lehet könnyebben mindenféle virtuális userekkel csatlakozni, force user meg hasonlók, a symlinkeken keresztül mappák elérése is sima ügy (unix extensions = off), szóval én pl. sambat hasznalok Linuxok között is, mert egyszerű adminisztrálni, és a net szakadást is relatíve jól tolerálja (mondjuk az nfs hez képest). Sebességben, stabilitásban nem érzem, hogy helyi hálózaton bármi gond lenne vele. Neten mondjuk az sshfs tényleg reszponzívabb lehet.
Ha a symlinkek relatívan vannak megadva akkor jól működnek sshfs-sel is.
OT
Én gyakorlatilag alig találkoztam relatív szimlinkkel.
Srry ha pontatlanul fogalmaztam volna. A következőre gondoltam:
ln -s /home/felhasznalo/docs /home/user/notebook-docs
helyett
ln -s ../felhasznalo/docs notebook-docs
szimlinkekre.
Így sshfs-sel fájlrendszerben bárhova becsatolható másik gépen, ott is jók lesznek a szimlinkek.
Teljesen pontosan fogalmaztál. Én csak azt mondom, hogy nagyon kevés embernél láttam hogy így használná.
Csak sshfs miatt kezdtem használni. Ebben az esetben viszont erősen javallott, különben az sshfs-sel felcsatolt linkek rosszak lesznek.
Valójában pl. olyan mappát akarok oda symlinkelni, aminek az egész szerkezete egyébként nem elérhető. Tehát a symlink nem dolgok összegyűjtése miatt, hanem kifejezetten elérés biztosítására.
Nagyon régen találkoztam NFS-el... megoldották már, hogyha elszáll valamiért a szerver, majd visszajön, a kliensen ne legyen teljes halál a következő rebootig? :)
mount -o soft
A default a hard az adatvesztés ellen.
Ez önmagában tuti nem elég, hogy ne akadjon be a df, a könyvtár listázás stb, és umountolni sem lehet. Csak umount -l el, ami aztán az újramountolásnál kavarhat be stb. Ha neked ilyen nincs, akkor írd meg pls. milyen kapcsolókat használsz még. mount -o soft,async,timeo=60 stb. ilyenekkel szoktam kíséletezni, de valós leállásnál teljes a kudarc a kliensen is.
soft mounton kill -9 -cel ki tudod elvileg lőni a beakadt appokat és utána rendes umount.
autofs-t kell hasznalni
-
Groovy funkcionális eszközök
Ez jogos, de ha épp csatolás közben van gond, akkor ez nem segít, sőt, még az autofs is bekakál. Viszont legalább nincs mindig mountolva (pl. ftp szervernél)
Lehet/érdemes timeoutot állítani a kapcsolatokhoz
-
Groovy funkcionális eszközök
subs