Dotaz: Cloud disk s FTP?

[tazatel]

Znáte nějaké free úložiště s možností nahrávat soubory přes FTP? Stačí mi já nevím, 10GB? Jde hlavně o to, že na straně klienta bude počítač, ale někdy i hloupé krabičky ála Rpi, nebo nějaký senzor IoT. Chtěl bych, aby to nebylo závislé na mém serveru, tedy nějaké free řešení nějakého velkého hráče a nějaký jednoduchý protokol, aby když to ten cloud zabalí, jen změním přístupové údaje k jinému.

Proto jsem přemýšlel nad FTP - klidně jeho nezabezpečenou verzi, nebude tam nic tajného.

Problém je, že většina úložišť co jsem se díval, tak FTP nepodporuje. Nebo nějaké znáte?

Díky za snahu!

Odpovědi

[klingger]

http://www.capsa.cz

[tazatel]

Díky, čekal jsem spíše něco v zahraničí, ale vypadá to docela dobře, použitelně.

[jiwopene]

Rád bych upozornil, že ten, kdo „vidí“ do komunikace (ISP, někdo připojený do stejné sítě, …) může to úložistě pak používat i pro sebe. Takovéto zneužití by mohl být problém.

Je RPi „hloupá“ krabička? Myslím si, že tam šifrované připojení určitě není problém. (Používám např. sftp.)

[tazatel]

To je velké scifi, k čemu by tomu dotyčnému takové "spolehlivé" úložiště bylo? Ne, Rpi hloupé není, ale ta čidla ano a je poměrně zbytečné na nich řešit šifrování, když jsou to data, která nikomu k ničemu nejsou. Aby se v tom rýpal provider, musel by být úplný idiot, riskovat pověst a žalobu kvůli údajům z nějakého čidla.

[NN]

Ja to takto resil ale pres protokol HTTP s upravenou hlavickou. Vyhoda je, ze to proleze vsude. Data zaslana na specifickou URL se zpracovavaji v PHP. Na rozdil od FTP neni potreba zadna autentizace.

[tazatel]

Jak jsi to řešil? V rámci toho php? Výhodou je, že kdyby se něco podělalo, tak změníš PHP script a to zařízení stále posílá požadavky na jednu adresu, ale FTP server může být každý den jiný

[NN]

Na strane klienta se zabali CSV data do GZIP a pres HTTP poslou na adresu http://muj-server/sensors/rawpost.php. Skript jen rozbali data do adresare /sensors/data/. Zpracovavani uz probiha jinde. Funguje to spolehlive a z nekolika lokalit najednou. Nekam muzu klidne poslat detaily..

No jo, ale to vyžaduje, abys měl nějaký ten "muj-server", který logicky musí mít veřejnou IP adresu. Kdyby "tazatel" něco takového měl, tak se tady neptá na ftp zdarma, protože by si na tom svém serveru mohl dělat, co by chtěl.

[NN]

To je sice pravda, ale na rozdil od FTP protokolu to nemusi byt ani uloziste. Staci libovolny free hosting.

to je fakt.

[Kit]

uloziste.com

[tazatel]

To jsou všechno služby jako by je dělal nějaký 15 letý student. Nějaká nadnárodní služba, která tady bude ještě za dva roky by nebyla?

A nebylo by lepší, kdyby sis zaplatil nějaký svůj server?

[Filip Jirsák]

To jsou všechno služby jako by je dělal nějaký 15 letý student.

Což odpovídá, protože stejně vypadá i zadání…

Nějaká nadnárodní služba, která tady bude ještě za dva roky by nebyla?

Taková nadnárodní služba taky musí z něčeho žít a musí zajistit, aby se nestala skladištěm porna a warezu. Takže 10 GB zdarma nezabezpečeným FTP asi těžko.

[Filip Jirsák]

Pokud chcete jednoduchý protokol, poohlédněte se raději po HTTP. Navážete spojení, pošlete data, ukončíte spojení. S FTP musíte navázat řídící spojení, domluvit se se serverem, že použijete pasivní připojení, navázat druhé spojení pro data, odeslat soubor…

Jinak úložiště s podporou FTP má třeba Wedos Disk nebo Axfone Disk (ten má i variantu zdarma).

[Peter Golis]

Ja som bol v tom, že FTP má dva módy prenosu. Aktívny, kde sa klient a server dohodnú na druhom porte cez ktorý pôjdu dáta. A pasívny kde sa oznámi veľkosť dát a dáta idú na riadiacom porte 21. Niečo sa zmenilo od minulého tisícročia že zrazu pasívny prenos potrebuje alokovať nový port?

[Filip Jirsák]

To jste v tom žil špatně. Ani při pasivním přenosu nejdou data po řídícím spojení. Rozdíl oproti aktivnímu módu je v tom, že datové spojení v pasivním režimu navazuje také klient – v aktivním režimu je datové spojení navázané „opačně“, ze serveru. Takže od minulého tisíciletí se nic nezměnilo, v obou módech se pořád používá jedno kontrolní spojení a jedno nebo několik datových spojení pro přenos dat, a rozdíl je jenom v tom, zda je klient aktivní (sám naslouchá příchozímu datovému spojení a řekne serveru, kam se má datovým spojením připojit), nebo je pasivní (jenom řekne serveru, že potřebuje vytvořit datové spojení, počká, až server začne naslouchat a pošle klientovi zprávu, kde naslouchá, a pak se klient jenom připojí). Ono by ani nedávalo logiku kvůli potřebě obráceného navazování spojení totálně rozvrtat logiku FTP protokolu, že se příkazy přenášejí jedním spojením a data jiným, když jenom stačí změnit to, odkud kam se navazuje datové spojení a zbytek může zůstat beze změny.

[Peter Golis]

Takže keď so si robil vlastného FTP klienta a prišli mi dáta po riadiacej linke, tak som asi nemal používať ten jeden port na ktorom mi to bežalo. Divné že mi to fungovalo.

[Filip Jirsák]

Za prvé je potřeba rozlišovat TCP/IP spojení a port – TCP/IP spojení je definované čtveřicí údajů (dvě IP adresy a dva porty). Klidně můžete mít dvě různá TCP/IP spojení, která se liší jenom jedním portem. Za druhé, do pasivního režimu FTP přenosu se přechází tak, že klient pošle příkaz PASV, na který server odpoví IP adresou a portem, na kterém čeká navázání datového spojení od klienta. Server vám tedy po řídícím spojení určitě data neposílal.

[Peter Golis]

Používal som len jeden handle, ďakujem za pochopenie.

[Filip Jirsák]

Když mám na výběr buď věřit na zázrak nebo se smířit s tím, že lidská paměť není dokonalá a lidé také ne vždy správně rozumí tomu, co dělají, na zázraky nevěřím. Ale připadá mi zbytečné se handrkovat o tom, co jste kdysi dělal – ten kód už asi nemáte, a ve specifikaci a jiných dokumentech je to chování popsané jasně, takže důležité je, že teď už víte, jak je to správně.

[Peter Golis]

Ten kód bol vypálený na CDčku ktoré neprežilo dve dekády.

Ale som rád, že som sa dozvedel že mi ro fungovalo omylom. Pamätám si to presne, potreboval som si pred prenosom overiť veľkosť súboru aby som vedel kedy mám prestať presýpať dáta v tom riadiacom kanáli. Pri dátovom kanáli sa koniec prenosu riešil elegantnejšie.

[Filip Jirsák]

Pamätám si to presne

Ale klidně si věřte na zázraky, já vám to neberu. Howgh.

[pepe_]

Fungovalo to pouze proto že přenos zabral port 21 a jiný stroj ve stejném čase už fungovat nemohl.

To handle portů je protože se port 21 musí stále používat pro požadavky na spojení.

 

Pokud to jelo pouze mezi 2 zařízeními tak to fungovalo ale jistě to nebylo ftp ale prasárna.

Pokud to fungovalo s více stroji najednou tak jistě mluvíte jinak než to fungovalo.

[Peter Golis]

S viacej strojmi ako dvoma naraz to nefungovalo, site proxy command nebol v serveroch moc implementovaný.

[k3dAR]

hloupé krabičky ála Rpi

RPi je regulerni ARM pocitac s regulernim GNU/Linuxem a v nem dostupnou hromadou lepsich protokolu/klientu nez je FTP, chapu ze "senzor IoT" je na tom jinak(pokud tedy sensor nekomunikuje primo jen s RPi), ale nevidim duvod se tvarit ze je RPi "hloupa krabicka"

[tazatel]

Výše už jsem vysvětlil, že jsem tím myslel ty senzory a blbě jsem to napsal, ty Rpi samozřejmě hloupé nejsou, myslel jsem tím, že tam nebudou servery a počítače, ale různé desky s více, či méně omezenými zdroji a možnostmi.

[Josef Kufner]

Vybodni se na FTP. Je to nezabezpečené, problematické a zbytečně komplikované. Navíc už dávno mrtvé (i když na mnoha místech ještě dožívá).

Pokud chceš něco jednoduchého, sáhni po WebDAV. Jako server si najdi poskytovatele NextCloud nebo OwnCloud, založ si tam složku a na klienty/čidla nakopíruj ten WebDAV odkaz. Případně můžeš jen nakonfiigurovat Apache či Nginx, aby poskytnul ten WebDAV přístup.

Pro upload pak stačí udělat jednoduchý HTTPS dotaz, kterým uploadneš soubor. Takový HTTP dotaz snadno vytvoříš pomocí curl nebo wgetu, případně libovolné HTTP knihovny. Jde jen o nastavení pár hlaviček a volbu vhodné HTTP metody. Když budeš generovat názvy podle data a budeš mít připravenou známou URL, je to párřádková záležitost.