Dotaz: FOSS Dropbox alternativa? Jen ownCloud?

[petrfm]

Ahoj, co pouzivate pro zalohovani /home slozky? Chtel bych mit projekty, dokumenty a poznamky dostupne kdekoliv. Provozoval jsem owncloud, ale nikdy jsem nepresel na system ,kdy by se mi syncovala data z /home primo na server. Nejak jsem k tomu nemel duveru, vzhledem k tomu, jak zive probiha vyvoj a jak je to udajne derave jsem tam proste nahraval jen data na kterych mi nezalezelo.

Chtel bych zalohovat a verzovat treba i zdrojaky a nechci se zatim ucit GIT. Takze bych si jednoduse syncoval slozku s projekty a idea je, ze bych mel takto dostupne zdrojaky i podklady jak doma, tak v kanclu, ale i na mobilu, kdybych se potreboval podivat.

Take bych rad zacal syncovat svuj android mobil s CyanogenMod. Proto by se hodil nejaky klient pro android bez nutnosti mit google apps - idealne dostupny pres svobodnme repozitare ala fdroid, abych mel jakysi pocit sucha a jistoty, ze mi to neposila vsechny fotky nekam do ciny, nebo do ruska

Diky za tipy, Petr

Odpovědi

[katr]

Provozuji OwnCloud s PC i mobilem už přes 5 let a zatím vše OK. Server běží na Debian, pro synchronizaci souborů používám oficiálního klienta. Na mobil (kontakty a kalendář) pak DAVdroid (dostupný i přes F-Droid). Po zavedení Lets encrypt to mám konečně i s pořádným certifikátem :)

[petrfm]

A co s tím syncuješ? Jen nějaké dokumenty, nebo třeba i zdrojáky, nebo weby, kde máš tisíce souborů? Nerozbilo se nikdy nic? Já právě taky na mobilu používám davdroid na kontakty a kalendář, ale vadí, mi, že na serveru mám ubuntu 12.04 a tím pádem staré php a nepodařilo se mi aktualizovat owncloud. Nasírá mně, jak každý měsíc vydávají novou verzi, přitom tam doplňují samé hovadiny a neustále to bobtná. Za chvílí to bude i sociální síť a sdílení souborů a bezpečnost se odsune někam do pozadí Proto bych klidně zkusil něco co se soustředí jen na to sdílené, páč třeba kalendář a kontakty, na to stačí jednoduchý serveřík obsluhovaný přes CLI, nebo něco v PHP, co by mi běželo někde na hostingu... nemusím to mít doma svém na železe.

[katr]

Malé i velké věci, zatím přibližně 4000 souborů. Ale není to záloha, ta se přece dělá jinak. Až budu upgradovat, zkusím ten fork NextCloud.

[Filip Jirsák]

Záleží na tom, jaké funkce od toho požadujete. Pro obyčejnou synchronizaci souborů stačí rsync. Odkazováním na Dropbox a ownCloud jste požadavky moc neupřesnil, protože to jsou dvě dost velmi odlišné věci (už jen proto, že jedno je služba a druhé aplikace), které mají společné snad jenom to, že se tam dají ukládat soubory a má to webové rozhraní.

[kuba77]

Nemám s ním zatím zkušenosti, ale možná požadavky splní Syncthing? Pro Android je dostupný i přes f-droid.

[k3dAR]

take nemam zkusenost, ale mozna komunitni free verze Seafile?, aplikace pro Android take dostupna pres f-droid...

[petrfm]

na seafile jsem koukal, vypada to docela jednoduse a umi to jenom sdilet a syncovat soubory, coz je fajn. Zvazim jeste reinstall serveru na novejsi verzi a zkusit znova owncloud vc. klientu, ale dokud mi nekdo nepotvrdi, ze mu to spolehlive funguje i u tisicu soubory, kdy syncuje treba zdrojaky nejakych slozitejsich webu, apod., tak jeste budu vyckavat.

Nechci, aby se mi to pak rozbilo a abych nejakou chybou prisel o data - treba i o ta lokalni, kdyz to klient premazne.

[tibor]

syncthing pouzivam dlho rokov na sync suborov, celych adresarov. je to bitorrent. discovery service (ten co spoji oboch klientov) mozno prevadzkovat aj privatne. multiplatformny soft beziaci na linux, macos, windows, android. moznost jednoducheho verzovania contentu. na kalendare a kontakty potom baikal)

[petrfm]

Jo na ten baikal se chystam. Je idealni, ze mu staci klasicky LAMP. Hodim to na hosting a hotovo. Protoze email a kontakty se hodi, mit dostupne 365dnu v roce a to se na domacim serveriku spatne zajistuje.

Nevite nekdo, jestli ta komunikace probiha sifrovane? Vidim, ze to beha na HTTP a na webu jsem zbezne zahledl, ze resi overovani uzivatele. Ale ten samotny prenos kontaktu a kalendaru probiha v plain textu? To by na OPEN wifi nemuselo byt uplne nejlepsi.

Prece jen owncloud mi behal cely pod HTTPSkem.

[tibor]

Jo, HTTPS, apache / nginx ako reverse proxy a letsencrypt je samozrejmostou. U mna baikal zije svojim zivotom, z casu na cas spravim nejaky update

[Josef Kufner]

na kontakty a kalendáře doporučuju na Androidu Davdroid.

[VK]

Jenom pro úplnost - NextCloud slibuje (alespoň do budoucna) zaměření na stabilitu a snadnější update atd., takže by do budoucna mohl být (jak se mi zdá) lepší volbou než owncloud. Možná už je na čase ho vyzkoušet...

[k3dAR]

podle toho co sem cetl, tak smer jak ownCloud vedli "manageri" se nelibil puvodnim zakladatelum, kteri tak odesli spolecne s dalsima programatorama a udelali fork nextCloud... to mi prijde samoosobe dobrej duvod prejit ;)

[pavlix]

Chtel bych zalohovat a verzovat treba i zdrojaky a nechci se zatim ucit GIT.

Chyba. Zálohování není důvod nepoužívat VCS.

[PanZvedavy]

Pouzivam Seafile schovanej za reverzni proxy s ssl a zatim spokojenost. Je to projekt(na pythonu), kterej je tu uz spoustu let a soustredi se vyhradne na praci se soubory a nedela ze sebe multifunkcni nesmysl. Klienty ma pro vsechny hlavni platformy. Maji free verzi, ktera ma vsechny pro me pozadovane funkcionality. Owncloud jsem pred par roky zkousel a neoslovil me.

[Josef Kufner]

Zálohování, synchronizace a verzování jsou tři zcela odlišné a nezávislé věci.

Pro zálohování je dobré používat rsync a hardlinky/snapshoty na serveru pro inkrementální zálohy.

Pro synchronizaci je potřeba něco obousměrného, jako je právě OwnCloud, Dropbox nebo Syncthing. V případě kontaktů a kalendáře pak je potřeba CalDAV a CardDAV, což umí Davdroid (server je typicky klasická webová aplikace, např. Davical, Baical, …).

Ani jedno z předchozího ale neřeší verzování (inkrementální záloha se tomu podobá, ale je to něco docela jiného). Na to potřebuješ Git. Verze totiž chceš tehdy, kdy je chceš. Nestačí je mít jednou denně v nějaký téměř náhodný okamžik. Navíc ty změny je potřeba nějak pojmenovat, slučovat, vynášet do světa a tak podobně. Až si přečteš úvod ke Gitu, tak pochopíš.

[petrfm]

Já si právě s GITem hrál a přišlo mi to šíleně složité. Je to asi jenom věc zvyku a udělat si workflow, ale já byl zvyklý, ukládat si zdrojáky do adresářů s číslem verze a to mi stačilo. Pracuju na projektech sám, takže jsem si vždy vystačil s poznámkami v úvodu a jednoduchým TODO listem + vhodnými komentáři.

GIT pro mne IMHO nemá žádný přínos, je to jenom "práce" navíc. Chápu to v týmu, nebo když někdo vyvíjí veřejně aplikaci a potřebuje vystavit zdrojáky, apod. Ale pro samostatného vývojáře, co si občas něco uplácá a jediné, co potřebuje, aby měl zdrojáky synchronizované na více zařízeních si myslím, že dropbox/owncloud bohatě stačí ?

[Josef Kufner]

I pro jednotlivce to má smysl. Umí to pomoct s hledáním chyb, je jednodušší udržet pořádek při experimentování, a i ten navázaný issue tracker (Gitlab/Github) se hodí. A té "práce navíc" je méně než při vytváření očíslovaných adresářů.

[Vantomas]

Rozhodně bych šel do varianty znát git, je to dnes takový běžný nástroj, jehož znalost se rozhodně neztratí. Takové to základní používání je otázka pěti příkazů.

Sám git používám třeba u serverů, kde na pěti serverech běží jedno a to samé, mám to s Redmine propojené tak, že při commitu do dané branch se automaticky spustí deploy na všech serverech a automaticky se mi po nějaké úpravě aktualizuje konfigurace i na těchto serverech a nemusím to ručně obcházet a kopírovat a hlídat zda jsem tam neprovedl nějaké nepodchycené lokální změny.

A když už k tomu mám ten Redmine, tak rovnou jsem automaticky přešel na task tracker v něm a je v tom mnohem větší přehled co a proč se tak stalo. A prakticky všechny projekty, jak ty pracovní, tak i ty soukromé udržuji v tom. Ta možnost zpětně si dohledat proč došlo k nějaké změně nebo v souvislosti s čím vznikla je k nezaplacení.

[Vantomas]

Jinak git používám jen na zdrojové kódy a konfigurace na serveru, tam bych neměnil.

Na synchronizaci dokumentů jsem asi před půl rokem začal používat Nextcloud, rovnou jsem do Cloud adresáře nahrál i fotky, protože webový klient umí z fotek udělat galerii, soubory je možné sdílet pomocí URL a tak. Klient na telefon umí automaticky nahrávat vyfocené fotky do cloudu, takže už nemusím fotku posílat sám sobě mailem nebo spouštět ssh server, abych jí dostal do počítače a tak.

V Nextcloudu včetně těch fotek mám asi 200GB, na stolní počítač si to synchronizuji celé, na notebook jen ty adresáře bez fotek. Z home adresáře mám udělané symlinky do cloud adresáře pro různé konfigurace programů nebo adresář ~/bin, ve kterém mám různé skripty - zde je jediný problém, owncloud klient nesynchronizuje execute bit, takže při vytvoření nového souboru musím udělat +x na všech počítačích, ale execute bit se už poté neztratí.

Nextcloud na serveru mi běží na btrfs, byl jsem docela odvážný co se týče nastavení btrfs snapshotů, kdy se mi vytváří snapshot každých 5 minut a udržuji historii za 1 měsíc, což dělá 9000 snapshotů a za půl roku provozu jsem nezpozoroval žádné problémy a ke smazaným souborům se dá dostat dobře, když vím z jaké doby je hledat. Absence nějakého rozhraní pro přístup ke starším verzím mi nevadí.

[pavlix]

Já si právě s GITem hrál a přišlo mi to šíleně složité.

Ani náhodou to není složité. Oproti běžným programátorským problémům je uživatelská stránka Gitu triviální záležitost. Osobně ho preferuju, ale třeba Franta Kučera zde propaguje Mercurial jakožto alternativu s jednodušším a pochopitelnějším rozhraním.

Číslování adresářů je relativně nepohodlné a jak člověk jednou vyzkouší spravovat lokální kód pomocí commitů, tagů a větví, už se nikdy nechce vrátit. Narozdíl od šíleností jako CVS nebo Subversion je právě Git (nebo Mercurial a další) ideální pro one man show.

git init

Mám repozitář.

git add .

Mám všechny soubory zazálohované pro případ, že udělám nějakou nesmyslnou změnu.

git rm -f xyz

Vyhodil jsem trvale soubor, který do projektu nepatří.

git commit -m "initial commit"

Mám uložený počáteční stav projektu.

git tag -a v0.0.1 -m "Version 0.0.1"

Mám zafixovanou verzi 0.0.1.

Až na pár detailů uživatelského rozhraní, vážně nevím, co by mohlo být jednodušší. Od té doby, co jsem začal jsem používat Git na všechny projekty namísto Subversion nebo verzovaných kopií, mám život daleko jednodušší. Navíc se s Gitem dá víceméně pracovat i jako s těmi verzovanými adresáři, přepínání větví, commitů a souborů je bleskové a v přípaďě potřeby lze používat víc pracovních adresářů s různými verzemi. Už i ta nejzákladnější funkcionalita mi šetří obrovské množství času při jakékoli chybě nebo neopatrnosti.

Ovšem každý svého štěstí strůjcem a pokud se chceš patlat s adresáři, enjoy...

[petrfm]

Hele ja si rad necham poradit od profiku, co maji workflow zmaknute. Netvrdim vubec, ze to delam dobre, proto se prave ptam a nasloucham. Ten GIT syncujes nekam na server, nebo to provozujes takhle normalne lokalne?

Mne desi to, ze se to nijak neintegruje treba do IDE. Kdybych vyvijel v konzoli, chapu to. Ale takhle, kdyz treba zalozim projekt v NETBEANS, vytvori se mi adresar, tak si ho v konzoli otevru, provedu init a je to? Jak pak dokumentuju zmeny? Zase v konzoli?

Proste mi pripada, ze pokud nepouzivam serverove funkce a sync treba do githubu, je pro mne mnohem snazsi, kdyz zakladam projekt, vyrobit adresar PROJEKT-POKUS a v nem v1.0 a do nej vytvorit projekt z netbeans. Kdyz jdu neco predelat, vytvorim adresar v.1.1 a ulozim projekt do nej. Tam provadim zmeny.

Jasne, pokud zmenim neco, aniz bych si vytvoril novou verzi a neco se posere, tak se nemam jak vratit zpet. Ale pokud si to ohlidam, dava mi GIT neco navic? Krome toho, ze nemusim jak osel vytvaret adresare, ale zase musim porad lezt do konzole?

Proste kdyz to takhle srovanavam, nevidim ten prinos. Ale dost pravdepodobne je to tim, ze to proste delam blbe a mel jsem v tom dost velky bordel

[Vantomas]

Netbeans má podporu gitu v sobě, normálně včetně GUI

[petrfm]

zrovna koukam, ze treba NETBEANS ma podporu pro GIT primo v sobe... HMMM, to uz by asi bylo lepsi, nez porad lezt do konzole

[pavlix]

Ten GIT syncujes nekam na server, nebo to provozujes takhle normalne lokalne?

Naprosto libovolně. Jakmile začínám něco dělat, co má povahu projektu, tak minimálně nahodím git init a git add jako obranu proti chybám. Pak už se to větví podle povahy projektu. Většina věcí, co dělám je open source a jde do veřejného repozitáře. Pár jsou věci, které selektivně sdílím pomocí URL, ty jdou do repozitáře na serveru s deployment hoky. Výjimečně jde něco do private repozitáře.

Každopádně pokud máš daný projekt zálohovaný a nepotřebuješ ho sdílet ani deployovat, není problém ho nechat čistě lokálně.

Mne desi to, ze se to nijak neintegruje treba do IDE. Kdybych vyvijel v konzoli, chapu to.

Pracuju v konzoli, s integrací neporadím, ale určitě najdeš dost lidí, kteří nějakou používají.

Proste mi pripada, ze pokud nepouzivam serverove funkce a sync treba do githubu, je pro mne mnohem snazsi, kdyz zakladam projekt, vyrobit adresar PROJEKT-POKUS a v nem v1.0 a do nej vytvorit projekt z netbeans. Kdyz jdu neco predelat, vytvorim adresar v.1.1 a ulozim projekt do nej. Tam provadim zmeny.

Moje zkušenost je přesně opačná. Nejdřív jsem začal používat Git výhradně lokálně. GitHub tou dobou ani neexistoval. Adresáře mi nevyhovují granularitou. S VCS si ji určuju sám podle aktuálních potřeb.

Jasne, pokud zmenim neco, aniz bych si vytvoril novou verzi a neco se posere, tak se nemam jak vratit zpet.

To by mi právě vadilo, VCS mi umožňuje nepřemýšlet dopředu a soustředit se jenom na to, co chci udělat. Dává mi to svobodu dělat naprosté vylomeniny aniž bych se v jejich výsledcích ztratil.

Ale pokud si to ohlidam, dava mi GIT neco navic?

Je to jenom nástroj, navíc takový, který je od základu postavený tak, aby pomáhal a nepřekážel. Já osobně vycházím z toho, že si to neohlídám a hlídat si to ani nechci. Architektura Gitu funguje v zásadě na principu těch adresářů a jejich kopií, jenom je to schované do repozitáře a člověk k tomu přistupuje přes ten toolset. A já velkou část toho toolsetu na ty gitovské verzované adresářové stromy skutečně používám.

[Josef Kufner]

Já používám vim a příkazový řádek. Prostě mám vedle editoru otevřený i terminál. Ale Vim mi například ukazuje, které řádky jsou změněné/přidané a kde jsem nějaké smazal. Většina editorů a IDE aspoň nějakou podporu má. A existují i různá samostatná GUI.

Pro začátek doporučuju si projít Pro Git a používat příkazový řádek, neboť nešikovně udělané GUI dokáže být hodně matoucí. Jakmile ale pochopíš jednotlivé příkazy, není důvod nepoužívat jejich GUI varianty. Ale na složitější merge, rebase, bisect a podobné věci to ten terminál chce.

Co se serveru týče, lokální použití je často plně dostačující. Když uděláš jen git init a git commit, ale nikdy git push, tak budeš mít kompletní historii v místním adresáři ./.git a nikde jinde. Pokud nepotřebuješ program vystavit světu, tak to tak klidně může zůstat. Server není potřeba ani nemá po technické stránce žádnou zvláštní roli. S Gitem se centrální server používá jen z organizačních důvodů, nikoliv z technických (když nepočítám obtížné připojování se na vypnutý notebook kolegy).

Workflow s Gitem při běžném programování vypadá tak, že uděláš nějakou funkci (feature) nebo něco opravíš a commitneš. Pak něco dalšího a zas commitneš. Tedy hodně relativně malých commitů. Když později zjistíš, že jsi něco rozbil, tak ti git bisect poví, který commit to byl. Na běžné commity můžeš mít čudlík v GUI. Já mám trvale otevřený terminál a nijak mne to nebrzdí.

[lertimir]

souhlas že zálohování synchronizace a verzování je zcela jiná věc. Já používám na zálohování několika strojů BackupPC. interně používá rsync pro linux a pro win stroje, win share (nepoužívám) nebo rsnycd z cygwinu (používám) a mnohaletá spokojenost.

[copepr]

https://pydio.com/

[DD]

Zdravím, v podstatě jsou k dispozici Owncloud Nextcloud, Pydio a Seafile. Owncloud a Nextcloud - pomalé, synchronizace moc nefunguje, psáno v PHP. Mnoho funkcí, velké nároky, pomalé. Zbývá Pydio a Seafile. Pydio - opět PHP jen sync. klient je v Pythonu. Lepší než Own~NextCloud, ale vítězem by mohlo být Seafile - rychlý a funkční synchronizace, psáno v Pythonu, ovšem data na serveru ukládána v binární podobě - přes ssh přístup nečitelné.