Fórumok
Sziasztok!
Adott egy (nem saját) szerverteremben két szerver, az egyiken lévő felhasználói könyvtárat kellene mountolnom a másik szerveren, írási és olvasási jogokkal. Egyszerű, de jól működő megoldást keresek, az adatforgalom nem lesz jelentős.
NFS vagy SSHFS?
Hozzászólások
Hat az attol fugg pl sajat networkon van-e a ket gep vedve a kulvilagtol. "that NFS is not an encrypted protocol and anyone on the same physical network could sniff the traffic and reassemble the information being passed back and forth."
-
Kiterjesztések írása Go nyelvi környezetben
vagy openvpn fölött nfs?
--
Gábriel Ákos
+1
Vagy vmi külön erre dedikált hálózat, akár 1-1 külön hálókártya, és egy deróttal összekötni a két gépet.
Kerd hogy tegyek egymas melle a gepeket es kosd ossze. Utana no file securiti. Nfs :d
------------------------
Jézus reset téged
Vagy ha nem megoldható, kaphat az eth-pár egy dedikált VLAN-t.
+1 a külön kábelre vagy dedikált VLAN-ra.
de inkább a külön kábel :-)
no file security :D:D:D
ipsec+nfs
Persze, jóhogy nem már e-mail.
???
A témában felsorolt alternatívákkal (openvpn, sshfs, stb) szemben én az IPSEC-et tartanám stabilnak és gyorsnak. Hogy jön ide az email?
Ha az adatforgalom nem jelentős akkor sima scp bőven megteszi. Szerintem nem kell túl bonyolítani.
SSHFS. Az NFS egy belső, saját hálón elmegy és talán még nyitottabban is, de nem az igazi.
Mind a kettő jó lehet, de tűzfalazni kell alaposan.
NFS mitől lesz biztonságos "tűzfalazástól" egy nyilt közegben ?
Ezt kérdezed?:D
Az átvitel nem lesz titkositva, de a kihasználásához közbe kell ekelodni, ami azért nem egy egyszerű feladat és a tuzfalazas kizárája az egyéb helyekről történő támadások lehetőséget. Ezért lesz használható.
Ez kicsit olyan, mint amit egyik ügyfélnél láttam. A helyi RG nemes egyszerűséggel kinyitotta a samba portokat a netre, forrás IP címeket a tűzfalon beállította. Értem én, h működik, de azért nem csinálnám.
Azert a sambatol nem kell felni 3.0-tol felfele.
Hint: Microsoft Azure Files
Nem tudom, hogy ez változott-e, de amikor utoljára láttam - Debian - Samba, akkor az összes interface-én binding-olt default. Ezt már talán az SP2 előtti XP sem csinálta.
Oké, kiveszek 1 szót a mondatból ami idézőjelben is volt:
NFS mitől lesz biztonságos egy nyilt közegben ?
Ezen nincsen mit magyarázni, rendben van hogy "tűzfalazól", de nézzünk csak:
- az én gépem a géped mellett van a polcon, u.a. switch-en.
- én dumpolom a forgalmat, látom NFS
- felveszem az IP-det (mert jó sok hostingban ezt megtehetem, és nem csak pistike bérelt salgó hostingjában)
- szépen csatlakozom szabályosan a te gépedre NFS-el (a te géped addig "elnémítom")
Maradjunk annyiban hogy éppeszű ember ilyet nem csinál! :)
Ha hosztingban felveheted más rezervált IP-jét, akkor megette a fene az egészet.
Hol van ilyen?
Attol fugg, hogy milyen adatokrol van szo es milyen halozaton.
Megbizhato halozaton nem kulonosen erzekeny adat eseten szerintem NFS. Megbizhato halozaton erzekeny adatnal NFS+krb5p vagy esetleg SSHFS.
Ha ezt nem megbizhato halozaton kell megvalositani akkor lehet, hogy eloszor egy megbizhato halozat kellene (akar VPN).
Az SSHFS-sel az a baj, hogyha megszakad a kapcsolat akkor az ugy is marad, kezzel (vagy scripttel) kell megjavitani, NFS helyre tud allni legtobbszor.
--
http://blog.htmm.hu/
Köszönöm a segítséget mindenkinek, SSHFS lesz.
--
Kum Gábor
Linux póló | Ciprus | Matek korrepetálás
Nekem még egyszer sem jött vele össze az értelmezhető sebesség. (Sok kis fájl esetén.)
valahogy ugy viselkedik mint az scp, marmint sok kis file eseten?
Nem tudom. Backupnak akartam. Felmountoltam majd masoltam. Masoltam volna, de remenytelenul lassu volt.
Jó az ssh, szeressük, meg azt is, ami azzal jön, és nincs is okunk nem szeretni, amíg a lassú ujjunk átviteli igényeihez igazodik, vagy pár közepes méretű fájlt kell átvinni.
De amikor X-et kell átvinni, akkor már látszik, hogy sok elvész a vámon, ha pedig rendszeresen kell nagyobb mennyiséget átvinni, akkor látszik, hogy mennyi az a sok: az NFS idejét optimális esetben is duplázni kell.
mwhahahahahaha.
ezek szerint meg nem szoptal vele.
sshfs arra jo, mikor ad-hoc kell valami gyorsan, ideiglenesen.
access time-t borzalmas, throughput szinten. cpu-t lezabalja, minden tetu lassu, par alkalmazas nem is mukodik egyaltalan, foleg bonyibbak (pl. egy intellij-t nem feltetlen engednek ra, JVM alol indexelni).
Ja es persze megbizhatosag is gond (auto-reconnect es a tarsai nemigen vannak).
confirmed, fasza amikor a 40GB backup offsite masolas kozben egyszercsak eltunik az sshfs-fuse mountpointtal egyutt, a kernel meg nem ad vissza IO hibat...
zárójelbe:
nem segit, a mountpoint szunik meg random.... azt meg nem hiszem hogy 2 datacenter kozt elnyisszantja a mano a kapcsolatot..... en ahol tudtam leepitettem
Ha egyszeri fajlmasolasra kell, akkor barmelyik jo lehet.
Ha hosszabb idore, folyamatos uzemben hasznalnad, akkor inkabb NFS. Tapasztalatom szerint ha valamiert szakad a kapcsolat, akkor az SSHFS arra sokkal nyugosebb, mint az NFS.
Apropó: milyen server/kliens opciók javasoltak ahhoz, hogy a leghibatűrőbb legyen? Ha a szerver eltűnik egy kis időre majd visszajön, ne kelljen már rebootolni a klienst.
Alapesetben ha a szerver eltűnik, a kliensen a mountpoint beragad és csak a teljes reboot segít. Van, hogy a szerver hiába jön vissza, valami ID megváltozik és ugyanúgy nem tud észhez térni a kapcsolat. Umount -l, umount -f sem segít.
Ezt már többször beszívtam.
SMB 3.x tamogatasaval hogy all a Samba?
A felmerult igenyeket elvileg lefedne (enkriptalt, gyors, hibaturo)
A Synology cuccai mostanában szedték össze magukat SMB3 alatt, úgyhogy valszeg a Samba is jól halad.
nfs nálam bevált, igaz, nehézkes a beállítása, de utána nincs vele gond. A nagy adatforgalmat és a sok apró fájl is jól bírja. Linux-Linux rendszerek közti fájlátvitelre szerintem ez a legjobb opció.
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba
Végülis mégiscsak NFS lett, privát hálózaton.
--
Kum Gábor
Linux póló | Ciprus | Matek korrepetálás