Sdileny disk ve Windows a Linuxu. WebDAV? (diskuse)

[Roman]

Na vzdalene pripojeni sdileneho disku pouzivame sshfs v Linuxu a http://www.expandrive.com/ ve windows, umi pouzit klic, pripojit na pismeno a pracuje spolehlive uz par let...

[Prcek]

Kdysi jsem používal SFTP plugin do Total Commandera. Ale dlouho jsem to nezkoušel, na té stránce píšou, že kód přepsali z Putty na OpenSSH.dll, takže v jakém to je stavu teď nevím.

[phr]

Na serveru mi (kromě jiného) běží OpenVPN server, takže pokud potřebuju, mám přes VPN i (například) sambu.

[Jendа]

Fascinuje mě, jak první tři příspěvky obsahují rady, u kterých jsi jasně uvedl, že je nemůžeš použít .

Ano, zkusil bych ten WebDAV přes TLS. Nic lepšího asi z Windows nevyrazíš.

[tuxmartin]

To jsem uvedl az po precteni prvnich 3 prispevku, protoze mi bylo jasne, ze kazdy mi bude radit podobne postupy (ja bych to resil stejne, ale kvuli Win nemuzu).

Asi ano, pouziju WebDAV.

btw, proc se WebDAV skoro nepouziva?

[Heron]

Používá. Velmi oblíbené je spojení SVN a webdav a to i pro zápis (s autocommitem do repositáře). Je to potom takové verzované, snadno dostupné, úložiště se zabezpečeným přístupem. Dost se to používalo před pár lety, dneska už to vytlačil DropBox a podobné projekty (což je "skoro" totéž, jen to není na tvém serveru).

[Petr Tomášek]

btw, proc se WebDAV skoro nepouziva?

Anžto jeho implementace ve windows je (nebo alespoň před pár lety, kdy jsem se o to zajímal byla) totálně zprasená...

[Petr Tomášek]

Jo, taxem o tom dokonce psal kdysi do blogu.

[Aleš Kapica]

Anžto jeho implementace ve windows je (nebo alespoň před pár lety, kdy jsem se o to zajímal byla) totálně zprasená...

Přesně tak.

[kralyk z abclinuxu]

Není mi jasný, proč nejde použít VPN. Afaik widle mají VPN klienta v základu. Je to kvůli admin právům nebo něco?

[jkb]

standardni windows vpn-client umi imho jen PPTP-VPN a L2TP-IPSec-VPN. S openvpn se myslim nelze spojit. Jestlize to nekdo umi, sem s tim, take bych to potreboval.

[Kvakor]

PPTP by měl být v Linuxu podporovaný přes démona PoPToP, ale osobně s ním zkušenosti nemám. Když jsem ho kdysi srovnával s OpenVPN pro ůčely VPN, kde by byly jak stroje s Linuxem, tak s Windows, tak mi tenkrát vyšlo jednodušší a bezpečnější použít raději OpenVPN. Ale co jsem se teď díval, u aktuální verze vypadá konfigurace mnohem snadněji, takže pokud nevadí nižší bezpečnost daná nekvalitoru protokolu samotného, tak bych ho v podobné situaci rozhodně zkusil.

[jkb]

diky za tip, toho demona jsem neznal.

[Dreit]

Nemožnost cokoli instalovat, hmm....na to mě napadá jen HW řešení, jakási "spojka", která se připojí přes SCP na tvůj server a data bude dál sdílet třeba přes FTP. Nevýhodou je, že pokud to připojíš do switche jako "T" kus, tak se tam dostane i kdokoli schopnější v síti. Lepší by bylo mít to průchozí, třeba RPi s druhou USB síťovkou

Napadá mě ještě znásilnit Android tak, aby mohlo SD kartu používat zároveň PC a zároveň SCP klient, ale to asi jednoduše nepůjde

[Jendа]

Napadá mě ještě znásilnit Android tak, aby mohlo SD kartu používat zároveň PC a zároveň SCP klient, ale to asi jednoduše nepůjde

Nevím o tom, že by někdo vyrobil pro Linux „falešný FAT“, který by toto uměl. Je to jedna z věcí, která by byla nice-to-have. Neshání někdo téma na bakalářku? :)

[Dreit]

Někde jsem viděl, jak spojit dvě GNU/Linux PC napřímo USB kabelem (jednomu se nakecalo, že je USB slave), takže asi bude stačit jen chtít.

Nebýt to windows, tak možná stačí jen USB tethering a kdejaká aplikace z Google Play, ale na Windows se mi USB tethering rozjet nepovedlo, i když to údajně jde. Navíc by se dal stejným způsobem použít Android jako "konec tunelu", kdy by přes wifi šla zašifrovaná data (VPN) a přes USB už jen FTP

 

RPi je docela velká investice (na takovou blbost, navíc firma může mít whitelist na MAC adresy), ale zase stačí přehodit kartu a může dělat úplně jinou činnost

[Jendа]

Někde jsem viděl, jak spojit dvě GNU/Linux PC napřímo USB kabelem (jednomu se nakecalo, že je USB slave), takže asi bude stačit jen chtít.

Ano, ale to je nějaké PPP/IP. Ty chceš Windowsy přesvědčit, že jsi flashdisk.

Nebýt to windows, tak možná stačí jen USB tethering a kdejaká aplikace z Google Play, ale na Windows se mi USB tethering rozjet nepovedlo, i když to údajně jde.

Tady se zase tváříš jako USB síťovka (AFAIK). Těžko říct, jestli se to podaří přesvědčit Windowsy bez admina…

[Dreit]

Ano, ale to je nějaké PPP/IP. Ty chceš Windowsy přesvědčit, že jsi flashdisk.

http://www.linux-usb.org/gadget/

http://www.one-eyed-alien.net/~mdharm/linux-usb/

Tady se zase tváříš jako USB síťovka (AFAIK). Těžko říct, jestli se to podaří přesvědčit Windowsy bez admina…

Mě se to nepovedlo ani s adminem, jen jsem psal že by to taky mohlo teoreticky jít (při splnění určitých podmínek).

[Jendа]

http://www.one-eyed-alien.net/~mdharm/linux-usb/

To je mass storage driver pro USB hosta, ne?

http://www.linux-usb.org/gadget/

No ale jak si to představuješ? g_file_storage umí zpřístupnit jenom blokové zařízení.

[Dreit]

To je mass storage driver pro USB hosta, ne?

Právě na to koukám, špatně jsem si to přeložil

No ale jak si to představuješ?

Nejsem programátor, takže asi jen jako: "SCP se připojí na server, uloží si seznam souborů ze serveru, začne se tvářit jako USB disk a všechny přesuny souborů pojedou streamovaně po síti přes SCP"

g_file_storage umí zpřístupnit jenom blokové zařízení.

To určitě půjde bez větších problémů vytvořit, ne?

[Franta]

Nejsem programátor, takže asi jen jako: "SCP se připojí na server, uloží si seznam souborů ze serveru, začne se tvářit jako USB disk a všechny přesuny souborů pojedou streamovaně po síti přes SCP"

Pokud stačí čtení, tak je emulace relativně v pohodě. Prostě si sestavíš v paměti FAT tabulku a dotazy na určitá místa na „disku“ budeš směrovat na ty soubory.

Jestli je ale potřeba i zápis, tak je to dost složité a asi to nikdy nebude fungovat spolehlivě – vždycky se najde nějaká výjimka, kterou neošetříš a jsi v háji.

[Kvakor]

Na read-only by bylo nejjednodušší NBD, to se chová jako blokové zařízení samo o sobě a dokonce umí i copy-on-write režim, kdy se veškeré změny zapisují do souboru zvlášť pro každého připojeného klienta (a po odpojení jsou zahoheny).

[Kvakor]

Mimochodem, podobná koncepce gadgetu, co zpřístupní přes síť blokové zařízení jako USB Mass storage, by bylo docela zajímavé řešení, obzvlášť kdyby se použilo i šifrování. Zařizení by šlo připojit k čemukoliv, co umí USB a Mass storage, plus přislušný souborový systém (tj. u FAT dnes skoro všechno, co má USB) a u klienta by se choval jako normální flashdisk, nebylo by třeba nic instalovat. Šifrovací klíč by byl pouze uvnitř zařízení a pokytovalé diskového prostoru by viděli jen šifrované data.

Takže i kdyby do serverovny naklusali policisté či nějací třípísmenkový hoši, viděli by jen spousty binárních blobů a maximálně by poznali, kolik který klient užívá prostoru či kdy, odkud a kolik přenášel data, ale to je tak všechno. Dostatečně dlouhý klíč u symetrického šifrování (tj. >512 bitů) není možné brutální silou prolomit (tedy alespoň bez použití stroje času ).

Pokud by ona chytrá krabička uměla jediným tlačítkem (nejlépe velkým, červeným a pod ochraným krytem schovaným) zničit uložený klíč (umístěný v nějaké NVRAM, např. baterií napájené CMOS SRAM), bylo by to výhodné pro kohokoliv, kdo přechovává data, u kterých chce mít záruku, že nikomu nepadnou do cizích rukou.

Pokud by se ještě přidalo generování klíče hardwarovým generátorem náhodných čísel a klíč by nebyl uložen nikde mimo chytrou krabičku, tak je tu i odolnost proti kryptoanalýze gumovou hadicí - klíč je náhodný a uživatel ho nikdy neviděl, tudíž ho nemůže prozradit.

Toto by byl opravdu bezpečný "cloud pro paranoiky", protože při použití náhodně generovaného unikátních klíče by měl přístup pouze vlastních chytré krabičky, do dat by nemohl zasahovat ani provozvatel, ani nikdo po cestě. A paranoiků by určitě nevadilo, že data nejdou sdílet (i když u read-only přistupu by to šlo), protože paranoici takové věci stejně nedělají

PS: Pokud se někdo tuto ideu rozhodne realizovat, tak ať to nedělá na americké půdě - něco takového by nejen nejspíš velmi naštvalo výše zmíněné třípísmekové hochy, ale výsledné zařízení by nebylo možné ani vyvážet, poněvač silná kryptografie je v USA braná na úrovni zbraní hromadného ničení.

[Jendа]

Podle mě na trhu velmi chybí i jen obyčejný token (třeba ve formě USB klíče), do kterého se dá poslat heslo a vypadne klíč. A taky se do něj dá poslat jiné heslo a klíč se uvnitř zničí. Takové jednoduché zařízení v ceně několika desítek korun (uvnitř stačí nějaký PIC/AtTiny a hodinková baterka) by při použití gumové hadice (mimochodem pěkně blbě zvolený termín, existují účinnější způsoby extrakce hesel) velmi pomohlo.

[xkucf03]

Na tohle by měl stačit starý mobil s Javou ME (tzn. prakticky každý), který jde připojit po sériovém (nebo USB) portu.

[Jendа]

U takového zařízení určitě najdeš cestu, jak vydumpovat RAMku.

Navíc o klíč přijdeš:

• když ti ta aplikace spadne (který mobil má dneska uptime 10 let?)
• když ti dojde baterka (mobil má mnohem větší spotřebu než nějaký MCU ve sleep mode)

[xkucf03]

Ale zase to má uplatnění i pro širokou veřejnost – stačí zajít do bazaru, za dvě stovky koupit mobil (nebo sáhnout do šuplíku) a nahrát do něj javovskou aplikaci.

Ale ona vlastně široká veřejnost je líná šifrovat i pomocí obyčejných klíčů na disku, takže je to vlastně jedno Takže souhlas, nějaký ten jednočip by byl ideální. Zalít do pryskyřice a udělat pouzdro tak, aby se při pokusu o otevření přerušilo napájení a smazala paměť.

Otázka je, jak řešit API – kdyby se použilo PKCS #11, tak by s tím dokázaly pracovat i stávající aplikace, jen nevím, jestli by nebylo potřeba implementovat nějaké kryptografické funkce v tokenu (obvykle je jejich smyslem to, že klíč nikdy neopouští token a asymetrické dešifrování/podepisování probíhá na něm) nebo zda to může být i jednoduché rozhraní typu: řekni heslo a já ti dám klíč (tzn. dešifrování/podepisování by probíhalo v počítači).

[Jendа]

Ale ona vlastně široká veřejnost je líná šifrovat i pomocí obyčejných klíčů na disku, takže je to vlastně jedno

Přesně tak. Navíc široká veřejnost se asi nemusí coldbootu a rubberhose (opravdu si nechcete vybrat nějakou jinou metodu?) obávat.

Princip „klíč neopouští token“ zde podle mě nemá smysl (tedy on vlastně nemá smysl skoro nikde :). Jednak při šifrování disku potřebujeme docela velký průtok a jednak to stejně ničemu nepomůže - pokud už máme počítač backdoornutý, útočník si může vytahat ta data rovnou - nepotřebuje klíč.

Nicméně správné použití takového tokenu (společně s mrkva.ko a pam_jenda) může velice ztížit coldboot útok.

[xkucf03]

Princip „klíč neopouští token“ zde podle mě nemá smysl (tedy on vlastně nemá smysl skoro nikde :)

Používá se to při asymetrickém šifrování/podepisování – v tokenu se podepíše jen hash nebo dešifruje jen symetrický klíč a následné šifrování velkých objemů dat probíhá už na počítači pomocí symetrického klíče (náhodně vygenerovaný pro danou relaci a dešifrovaný v tokenu). Při kompromitaci počítače sice útočník může získat tvůj podpis pod něco, co jsi podepsat nechtěl, ale musí to stihnout ve chvíli, kdy je token připojený a otevřený – případně tam může být dioda, aby sis všiml, že se něco děje nebo dokonce tlačítko/displej pro potvrzování jednotlivých transakcí (v ideálním případě víš, co podepisuješ a musíš to individuálně odsouhlasit). Jde hlavně o to, aby ti někdo jednou neukradl klíč a pak s ním nemohl podepisovat/dešifrovat neomezené množství dokumentů.

Podobného efektu jde dosáhnout použitím vyhrazeného počítače, který bude buď offline nebo připojen pomocí nějakého jednoduchého rozhraní (jen příjem dokumentů k podepsání a vracení podepsaných/dešifrovaných)

společně s mrkva.ko a pam_jenda

Odkaz by nebyl?

[Jendа]

Příloha:

• pam_jenda.tgz (1145 bytů)

S tou ledkou (nebo ještě lépe pípnutím) je to dobrý nápad.

mrkva.ko je tady, k release pam_jenda jsem se ještě nedokopal. V příloze…

[kralyk z abclinuxu]

mrkva.ko je tady

Možná jsem něco přehlíd, ale žádný .ko tam nevidim...

[Jendа]

le ftip

[kralyk z abclinuxu]

Aha

[Josef Kufner]

Takovéhle klíče na trhu jsou. Není jich mnoho a nemají to v Tescu, ale jsou. Stačí potrápit Google, i když najít přesně to co chceš nebude na dvě kliknutí.

[Jendа]

Přiznám se, že jsem ještě neviděl žádný, který by:

• na povel vydal symetrický klíč
• měl nuke heslo

[Josef Kufner]

Symetrický klíč dostaneš od/zašifrováním náhodných dat.

S tím nuke heslem už to bude horší.

[xkucf03]

bylo by to výhodné pro kohokoliv, kdo přechovává data, u kterých chce mít záruku, že nikomu nepadnou do cizích rukou.

Až na případy, kdy by proprietární software v koncovém zařízení umožnil vyzrazení dat – zadní vrátka a odeslání dat na žádost policie, Microsoftu, BSA atd. To bys musel používat jen offline (a bez vlastní velké paměti) koncová zařízení nebo zařízení důvěryhodná a vybavená svobodným softwarem – ale pak můžeš šifrovat rovnou v nich.

Ale jinak souhlas, i tak by taková krabička našla uplatnění – např. pro ty offline zařízení (různé přehrávače, fotorámečky) nebo pro případy, kdy člověk nepotřebuje 100% ochranu…

[Franta]

g_file_storage umí zpřístupnit jenom blokové zařízení.

Pokud bych měl původní blokové zařízení (a nebyly to vzdálené soubory někde na serveru), tak by šlo udělat LVM snapshot, ten takhle nasdílet jako USB mass storage a po odpojení USB připojit daný souborový systém snapshotu a rsyncem synchronizovat s původním blokovým zařízením. Ale je to pakárna

[Franta]

A nebylo by lepší emulovat PTP (protokol, kterým se připojují některé foťáky)? Tam odpadají problémy s emulací blokového zařízení a pracuješ o vrstvu výš.

[tuxmartin]

Zajimave uvahy, jen nevim jak je realizovat

 

To uz by bylo lepsi si spustit portable putty a tunelovat si sambu.
Stahnout plink a nejak podobne ji protunelovat:

plink.exe -N -L 1234:192.168.1.1:3389 martin@server #ukazka je na RDP

A plink a bat skript si muzu dat na web server na port 80, abych nemusel nosit flash disk s plinkem. Ale je to nepohodlne. Proto asi budu muset pouzit WebDAV.

[Dreit]

Tak teď mi dochází, že s tím RPi je to asi blbost - běžel by tam SSH klient a FTP server (se stejným mountpointem). Sice by se tím dalo číst (SSH -> FTP), ale zpátky nevim jestli by to šlo....ale kdybych to zkusil, tak třeba zjistim, že to jde

Ale "rozbalovat" s ním třeba VPN by snad jít mohlo

[Salamek]

Vysel novy slax, tak rovnou sebou tahej live USB se slaxem :D

[Franta]

+1

Asi tak. Taky bych řekl, že je zbytečné se s těmi Windows otravovat a řešit takovéhle blbosti.

[Josef Kufner]

Pokud jde o tvé počítače, postav nějakou VPN a v ní Sambu nebo NFS.

Pokud nemůžeš nic instalovat, zkusil bych telefon připojený jako flashku (Android to umí hezky). Pak můžeš telefon přes wifi připojit do VPN a nechat si přes USB sdílet síťový disk. Ale to bude trošku krkolomné na konfiguraci.

[Franta]

Který Android to umí? Myslel jsem, že při připojení po USB v telefonu odpojí (odmountuje) kartu a nedá se s ní v tu chvíli pracovat. Jinak pokud (čemuž moc nevěřím) by tam byla implementovaná nějaká emulace FAT s podporou zápisu, tak by to mělo jít z Androidu vykuchat, když je open source.

[Saljack]

Nemusí to odmountovat. MTP, PTP nebo jak se to jmenuj umí Windows snad nativně ne?

[Petr Tomášek]

WebDAV vidim jako znasilnovani HTTP protokolu

Hm, já naopak považuju WebDAV za logické a elegantní rozšíření HTTP protokolu na věci, na které se při návrhu HTTP nemyslelo. Pravda, pár věcí bych asi řečil jinak, ale v zásadě mi WebDAV (z hlediska návrhu) přijde z ostatních možností jako nejlepší.

[Petr Bravenec]

Nic z toho, co uvádíte, se nechová jako síťový disk - nautilus, sftp, putty, winscp, ftp ani webdav. Chcete-li mít jako síťový vzdáleně připojený disk ze svého počítače, na kterém běží ssh, vydejte se nejspíš cestou tunelu, asi takto (v linuxu):

ssh -L 2049:localhost:2049 muj.domaci.server

Je možné, že budete potřebovat protulenovat i porty 111 a 4045, a pak si můžete připojit svůj disk klasickým mountem:

mount -t nfs localhost:/sdileny-disk /mnt

Ve windows se to bude trochu lišit (jiné porty) a asi i to montování disku bude vypadat jinak:

net use x: \\localhost\sdileny-disk

Na počítačí samozřejmě musí běžet kromě ssh i samba nebo nfsd. Berte to jako námět, zkusit to musíte sám.

Osobně bych se na připojení síťového disku vykašlal a použil ten zmiňovaný nautilus, ve windows pak třeba program filezilla.

[tuxmartin]

Nic z toho, co uvádíte, se nechová jako síťový disk - nautilus, sftp, putty, winscp, ftp ani webdav.

Trochu mi unika souvislost mezi nautilem/winscp a ftp/webdav. Prvni je klientska aplikace a druhe prenosovy protokol.

 

OK, asi jsem se spatne vyjadril. Jde mi o jedine - kdyz napr.v MS Wordu kliknu na soubor->ulozit, abych mohl ukladat na svuj vzadleny disk. Musim ho tedy videt pod "nejakym pismenkem". Nic vic neresim.
Kdyz pouziju WinSCP, tak musim soubor nejdrive ulozit na lokalni PC a pak ho prekopirovat.

Nautilus v Gnome ma urcite nevyhody. Hodne programu (asi GTK/Gnome compatible) vidi pripojeny disk, treba gedit ano. Spousta dalsich programu ho ale nevidi. Reseni je jednuche - nautilus ve skutecnosti pripojuje vzdalene disky do "/home/uzivatel/.gvfs". Pro vetsi pohodly lze udelat mount bind treba do /media, jako to mam resene ja.

[Petr Bravenec]

OK, smíchal jsem dohromady protokoly a aplikace, které však mají jednu společnou věc: nejde o "síťové disky". Vysvětlím:

Situace "ftp":

1. Připojím se ke vzdálenému počítači
2. Najdu soubor a překopíruji na lokální počítač
3. V lokálním počítači otevřu například Office se stáhnutým souborem
4. Upravím a uložím soubor
5. Připojím se ke vzdálenému počítači
6. Překopíruji lokální monifikovaný soubor na vzdálený počítač, čím přepíšu původní soubor na vzdáleném počítači

Situace "sdílený disk":

1. Připojím disk ze vzdáleného počítači na lokální počítač
2. Na lokálním počítači na vzdáleném přimontovaném disku otevřu Office s vybraným souborem
3. Upravím a uložím soubor = změny se akcí "Uložit" přepíší do vašeho vzdáleného počítače.
4. Odpojím vzdálený disk

Vše, co jste uvedl, spadá do kategorie "ftp". To je řešení, které je jednoduché, univerzální, velmi výkonné a pokud spolupracujete v týmu, pak také zrádné a potenciálně nebezpečné.

Nicméně se tváříte, že toužíte po kategorii "sdílený disk". Tam může být nastavení složitější, obvykle je méně výkonné (při zapnuté volbě "automaticky ukládat každých pět minut" v Office budete brzy prskat), řešení však může být bezpečnější o zamykání - v týmu ostatní poznají, že děláte v souboru změny.

Vnímáte ten rozdíl? Předpokládám, pokud vám vyhovuje Nautilus, že vám vyhovuje i řešení "ftp", to ale nemá se sdíleným diskem nic společného. Nevím, jak se uživateli jeví Nautilus a jak se uživateli jeví WinSCP, ani jedno nepoužívám, ale v pricipu jde v obou případech o "ftp", ne o sdílený disk, po kterém voláte.

Pokud chcete dálkové sdílet různé dokumety (typicky zdrojové tvary programů), zvláště pak v týmu, může být pro vás vhodný i nějaký verzovací systém, který se svým fungováním nepodobá žádné z výše uvedených variant.

Podle mého názoru je pro vás "ftp" varianta vyhovující - v Linuxu se naučte používat scp, ve windows winscp, filezilla či jiný, podobný program. Naťukat pár písmenek není většinou o nic pomalejší, než se k podobnému výsledku proklikat.

[tuxmartin]

Situace "ftp":
1. Připojím se ke vzdálenému počítači
2. Najdu soubor a překopíruji na lokální počítač
3. V lokálním počítači otevřu například Office se stáhnutým souborem
4. Upravím a uložím soubor
5. Připojím se ke vzdálenému počítači
6. Překopíruji lokální monifikovaný soubor na vzdálený počítač, čím přepíšu původní soubor na vzdáleném počítači

Ja vim, lokalni kopie neni nejlepsi. Ale to me nevadi. Tady jde o uzivatele - ten s tim pracuje jako se "sitovym diskem". Uzivatel nechce nejdriv spustit WinSCP, pak pracovat ve Wordu a pak nahravat zase pres WinSCP (ktere uz davno pravdepodobne uzavrelo spojeni a musi tak znova zadavat heslo zpet na server.
Navic mi jde o male soubory (napr. ve Wordu) radove pod 1MB.

Nicméně se tváříte, že toužíte po kategorii "sdílený disk". Tam může být nastavení složitější, obvykle je méně výkonné (při zapnuté volbě "automaticky ukládat každých pět minut" v Office budete brzy prskat), řešení však může být bezpečnější o zamykání - v týmu ostatní poznají, že děláte v souboru změny.

Zamky by mel prave WebDAV umet.
Takze co navrhujete? Sambu pres VPN?

Vnímáte ten rozdíl? Předpokládám, pokud vám vyhovuje Nautilus, že vám vyhovuje i řešení "ftp", to ale nemá se sdíleným diskem nic společného. Nevím, jak se uživateli jeví Nautilus a jak se uživateli jeví WinSCP, ani jedno nepoužívám, ale v pricipu jde v obou případech o "ftp", ne o sdílený disk, po kterém voláte.

Nebo rovnou muzu mit NBD

Pokud chcete dálkové sdílet různé dokumety (typicky zdrojové tvary programů), zvláště pak v týmu, může být pro vás vhodný i nějaký verzovací systém, který se svým fungováním nepodobá žádné z výše uvedených variant.

Zajimavy je treba SparkleShare. Je to vlastne takovy "DropBox" na vlastnim serveru a vse uklada do gitu. Ma i pekne GUI.

[lertimir]

A jaký máte upload? Ten přístup přes "sdílení" disku bude pro uživatele možná nepříjemnější, právě proto, že většina aplikací pracuje se soubory dost rozmařile a očekává rychlou reakci a velký datový tok do filesystému.

[Petr Bravenec]

Aha, už chápu. Vám jde především o uživatelskou přítulnost (vždycky, když píšu o uživatelské přítulnosti v souvislosti s programem, představím si labradorského retrívra) a scénář "ftp" je přijatelný. Dám to do samostatného odstavce a zvýrazním, abyste si toho tentokrát všimnul:

Filezilla

Nikdy jsem to nepoužíval bez instalace, ale mělo by to jít.

[Václav HFechs Švirga]

Sice mám snad Filezillu rád (jinak bych ji na abclinuxu nerecenzoval :o), ale tady je mimo. On chce mít vzdálené uložiště přimountované jako "disk" (ať ho vidí všechny programy už v save dialogu) a navíc nechce instalovat ani spouštět žádné programy.

[Petr Bravenec]

Jj, taky už jsem pochopil, když jsem si představil, co asi provádí Nautilus.

[Josef Kufner]

Ty dva scénáře jsou ekvivalentní, jen v druhém případě stažení a nahrání souboru maskuje operační systém. Z pohledu serveru ani ostatních uživatelů v tom rozdíl není.

[Petr Bravenec]

Ty scénáře rozhodně nejsou ekvivalentní. Zkuste si pustit film přes ftp a přes smb a myslím, že vás ten rozdíl trkne.

[Josef Kufner]

Přes smb to pojede polovićní rychlostí

[Petr Bravenec]

OK. Tak to zkusím jinak. Připojte si přes ftp svou sbírku filmů a zkuste se jí projít, zjistit, co je který film zač. Zjistíte, že seek je v ftp scénáři nemožný, dokud není celý soubor překopírovaný lokálně.

[xkucf03]

Pomocí příkazu REST jde ve FTP nastavit počáteční pozici a stahovat soubor třeba od prostředka…

[kralyk z abclinuxu]

+1

[Petr Bravenec]

Reseni je jednuche - nautilus ve skutecnosti pripojuje vzdalene disky do "/home/uzivatel/.gvfs". Pro vetsi pohodly lze udelat mount bind treba do /media, jako to mam resene ja.

Možná mi uniká, co vše nautilus umí, a mluvím trochu s cesty.

[gtz]

Nešlo by použít NFS? Pro Windows myslím nějaký NFS client určitě je. Akorát musí být NFS share vidět z venku.

[jkb]

jak pise autor, nema moznost neco doinstalovat. NFS client u XP neni soucast OS a u win7 je to az od ultimate (urcite ne u profesional).

A jakmile by tahle podminka padla, tak pak muze samozrejme delat psi kusy. Ale jakmile prijde k cizimu pocitaci a chce pristup k nejake sve vzdalene slozce, tak mu toho krome Webdav asi skutecne moc nezbyva.

[gtz]

Na to jsem nějak zapomenul. Asi by nebyl problém sehnat nějakého klienta v portable modu, ale problém jsou ovladače.

[Václav "Darm" Novák]

Pri reseni podobneho problemu jsem nakonec sahl po projektu owncloud. Webova aplikace s prijemnym rozhranim, ktera funguje podobne jako dropbox nebo gdrive a navic umi sdilet uloziste pres webdav. Pod Windows zcela bez problemu.