Seafile 4

Szerszám

Korábban írtam róla itt és itt. Seafile egy saját „felhő” fájlmegosztó szolgáltatás, amit magunk telepíthetünk és felügyelhetünk anélkül, hogy egyéb szervezetek keresnének az anyagainkban vagy csak tárolják...

Az adatok tárolása a fájlrendszeren fájlok helyett objektumokban történik a Git-hez hasonlóan.

A kiszolgáló fut Debian 6-, Ubuntu 11.10-, CentOS 5.8, 6.0-, RasPi, Windows-on.

Kliensek: Android, iPad/iPhone, Windows, Linux, Mac

Fontosabb újdonságok:

  • Szinkronizálás http(s) protokollon
    • még nem ez az alapértelmezett
  • Vastag kliensben fájlböngésző
  • Bélyegképek

Sajnos a köteteket nem lehet átmigrálni az új formátumra, de érdemes őket törölni és újból létrehozni; főleg azoknál a köteteknél amik még 2-es verzióval lettek elkészítve vagy még régebbivel. Esetleg web felületen létre lehet hozni egy új kötetet majd a fájlokat átmozgatni a régiből és a klienseken az új kötetet beállítani.

( vinnui | 2015. 01. 07., sze – 08:36 )

Köszönjük, ez jónak tűnik. Van vele valakinek üzemeltetési tapasztalata?

2.1.5 ota hasznaljuk, jelenleg a 4.0.1-es verzio fut. Igaz nem nagy telepites, korulbelul 10 kliens log rajta egyszerre es alig 30 GB a netto adatmennyiseg, de elso pillanattol fogva kifogastalanul mukodik. Stabil, a kliensek nem orulnek meg, a frissitesek gond nelkul telepulnek es kifejezetten szimpatikus, hogy vastagkliens eseteben kotetenkent eldontheto a felhasznalo, hogy mit akar a gepen szinkronban tartani, igy egy jol felepitett kotet struktura lehetove teszi, hogy a felhasznalok csak azt toltsek le amire tenyleg szukseguk van az adott gepen. Elotte es mellette parhuzamosan Owncloud telepites is volt/van, azzal tobb problemank akadt sajnos.

Az igazság az, hogy a 2-es széria óta sokminden alapvető dolgot változtattak meg, mint webdav lehetőség beépítése, fájlok keletkezésének ideje - ehhez új storage formátum kellett, al-könyvtárak megosztásának lehetősége, kötetek közötti deduplikáció megszűntetése (al-könyvtár kötetek között van dedub) és most a 4-es szériában a http-n való szinkronizálás lehetősége a stabilitásban hagyott nyomokat.
Adatvesztésem ebből még nem volt, de hibás működése és fsck futtatás a javításhoz igen. Épp tegnap javították a 4.0.4-es szerverben az al-könyvtárak http-n való szinkronizálás hibáját. Üzemi méretben nem használom sehol, otthon a családnak és ritkán várom meg egy-egy verzió kiadását követően a stabilizációs szakaszt, amikor 3-5 kiadás jelenik meg a verzióból (x.y.3 -) így belefutok hibákba.
Érdemes végignézni a changelog-okat, mind kliens, mind szerver oldalon...
A frissítése nagyon egyszerű, 1 tgz kicsomagolás, szerver leáll, 2 symlink kicserél, szerver elindít, örül.

( khiraly | 2015. 01. 07., sze – 10:41 )

Harom kerdesem lenne:

1) Be lehet olyat allitani, hogy van egy megosztas mappam amit mondjuk naponta egyszer ellenoriz, hoyg frissult-e. Es van egy megosztas/instant mappam, amire mondjuk percenkent ranez?

2) szamitogep inditasanal (vagy reboot), ez is azzal kezdi, hogy atmolyolja az osszes fajlt 100% cpu mellett?

3) 1-2kB-os fajlokat osszecsomagolja egy zip-be es ugy kuldi el, mondjuk 1MB-os meretre, amit a tuloldal kicsomagol? Mert az apro .git/* fajlok miatt az atviteli sebesseg ilyen nevetseges 20-60kB/s mellett ingadozik. Magyaran a kezdeti sync nalam laptop->laptop -ra 2 nap. Laptop -> raspberrypi -ra 3 het.

Amit en megosztok az most per pillanat 121GB, es 1.2millio fajl (.git-ek mindent elrontanak:()

Mire ezt az 1.2millio fajlt atfutja a jelenlegi kliensem(btsync) az a laptopon olyan 1.5 ora. Es fullra eszi a processzort.
Az ujabb laptopomon 1 ora alatt van mar, de meg mindig idegesito.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Jelenleg en is btsync-et hasznalok a szemelyes dolgok (2.2GB) es nehany git repo (kb 30 MB) megosztasara, de a btsync baromi instabilla valt az 1.4-es verzio ota. Van egy allandoan futo szerver es egy relative allandoan futo nas amire egy laptop es egy asztali gep szinkronizal. Sajnos napi szinten futok bele out-of-sync allapotba, a kliens jelzo, hogy lenne mit feltolteni, de egyszeruen nem teszi, csak var. Gondolkodom rajta, hogy Seafile-ra valtok, de kicsit overhead-nek erzem, raadasul a Mac-es kliensben nem tetszik, hogy a dock-ban marad az ikonja. :/

En meg futottam egy kort a git-annex-assistant-tal is.

Az is szerintem elbonyolitja a dolgokat. Bar mar egy jo fel eve neztem ra legutoljara. Az egyik regi laptopomon mar nem megy a kliens, foleg ezert hanyagoltam.

Van par sajat alkalmazasom, es nem frissitettem a laptopot (10.04 van rajta, a unity miatt ragadtam ott meg),
es kellene frissiteni a guis programjaimat is. Gondoltam, hogy az uj laptopra migralok, addig a regit eletbentartom, de ebben a migralasi idoszakban jo lenne fajlmegosztas a ketto kozott.

Gondolkodok egy sajat megoldas osszeutesen node.js alapon. Ugyis par guis dolgomat atteszem web alapura, igy a fajlmegosztas mar nem oszt nem szoroz.

Szerintem nem kell a fajlmegosztasba verziokezelo. Arra ott a git kliens oldalon.
Eleg egy kuka implementalasa mondjuk 30 napos hataridovel, igy van reagalni.

Fajlmegosztasra meg http, discovery-re meg egy-ket kozponti szerver meg egy cache.

Az apro fajlok problemara meg csomagolas zip-pel (az minden platformon van), es ugy kuldeni.

De meg mielott belevagok, azelott szerintem futok meg egy kort az osszessel.
(git-annex-assistant, btsync, owncloud, cozy, seafile)
Meg szerintem egy egyszeru android alkalmazassal kezdem,
ami tolja fel a fajljait a szerverre.

Tudom, a sajat backup megoldas ellen mindenki agital, de az osszes erv csak ceges kornyezetben allja meg a helyet (magyaran ha kirugnak a soron kovetkezonek beletorik a foga a custom megoldasba), mig ha a sajat eletembol rugnak ki, akkor mar mind1:-\

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( tothgab | 2015. 01. 07., sze – 12:36 )

Ez az alkalmazás jó alternatívája lehet mondjuk a SharePoint-nak?

Nem.

Bővebben: kicsit sem, mert a kettő teljesen másra jó, és nem is hasonlítanak. A SharePointnak kb. annyira alternatívája a Seafile, mint a fogkefe a bakancsnak, az alma a traktornak, vagy a műanyag pohár egy térképnek. Semennyire. A Seafile inkább a Dropboxnak, Google Drive-nak, stb. lehet alternatívája, a SharePoint teljesen másra való.

Nincs mit. :)

De tényleg, itt le van írva elfogultságtól mentesen, hogy mit tud a SharePoint: http://en.wikipedia.org/wiki/SharePoint

Az, hogy mellékesen képes valami hasonlóra, mint a Seafile, mindegy, mert alapvetően a SP nem egy cloud file storage. Jó lehet annak is, de szerintem az az ágyúval verébre című jelenség.

( uid_395 v | 2015. 01. 07., sze – 17:45 )

Anno kerestem owncloud alternatívát (sok gondunk volt ownclouddal, most nem részletezném), akkor a 3.x szériás seafile-ra találtam rá.

Azóta egy instance megy, de tervben van a következő is.

egy 149G -s kötet van rajta, több userrel, több eszközről (mobil pl), vegyes fájlkörnyezet. Vannak nagy fájlok is, van olyan könyvtár amiben sok sok kicsi, stb.

Eddig teljesen stabilan megy, egyszer volt 1 darab gond vele, egy kisebb szinkronizálási hiba, de az is csak kliens oldali hiba volt.

Megelégedéssel használják :) (6-10 user)

Csak javasolni tudom. Egyetlen "hátrány", hogy mivel gitben tárol mindent, így nincsennek meg a szerveren a "pure" fájlok. Azaz, backup backup backup!

Röviden címszavakban:

- random jogosultsági gondok, egyik user látta eddig, utána hopp, nem látta (semmi config / egyéb változás)
- problémák merültek fel akkor amikor egy user több helyről szinkronizált volna (iroda, otthon, másik hely, stb)
- ékezetes, ponttal ellátott, szóközt tartalmazó fájloknál sikertelen szinkronizálások, stb. lehet egyedi eset.

Kb. ennyi, de összefoglalva, azonos idő alatt az owncloudnál mondjuk kellett beavatkoznom 5ször, míg a seafilenál 1szer.

ps.: ez főleg az owncloud6-nál fordult elő, volt egy owncloud5-ös instance anno, ami kiszolgált 40+ usert, ott nem tapasztaltam ilyen gondokat, mondjuk ott általában 1 user 1 helyről használta.

> Egyetlen "hátrány", hogy mivel gitben tárol mindent, így nincsennek meg a szerveren a "pure" fájlok. Azaz, backup backup backup!

Én ezt inkább előnynek tartom mint hátránynak. Objectstore van és nem filestore, van deduplikáció... Backup meg így is úgy is kell. Nemde? ;-)

Androidon szeriintem így kell működnie. Egy néhány (5-20) GB-os megosztás már nem biztos, hogy elférne a készüléken, ha minig szinkronban tartaná az egészet. Míg egy PC-n ez nem gond.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

En szeretnem neha kontrollalni a felhasznalok tarolt allomanyait. Na most ezt igy igazan nem tudtam megoldanj, admin accal a webrol sem. Pedig a vezetoseg reszerol orulnenek.

Masik nyug amim volt a seafile-lal, hogy ldap- bol kapja a nepeket, de a megosztasnal nem volt lehetoseg az ldapot bongeszni, csak az ismerosnek felvetteket, vagy kezzel megadni a felhasznalot.

( szilard_ v | 2015. 01. 14., sze – 10:55 )

Win 7 x64-re feltettem a klients, de az a bajom vele, ha egyik wifi hálózatról megyek a másikra, akkor a kliens 10-ből 7 alkalommal nem tud mit kezdeni az új hálózaton, nem jelentkezik be a szerverre. Ha kézzel meglököm, akkor csak teker, de nem történik semmi. Ha a klienst jobb klikk/kilépéssel bezárom, akkor a tast managerből is ki kell lőnöm, mert beragad és nem lehet újra indítani a klienst. Ha ezt megtettem, akkor utána már pöccre megy megint minden.

( Proci85 v | 2015. 02. 28., szo – 18:25 )

"Sajnos a köteteket nem lehet átmigrálni az új formátumra, de érdemes őket törölni és újból létrehozni;"

Ez mit takar? Az imént frissítettem 2.1.5-ről 4.0.6-ra.
Az upgrade könyvtárban van:
[...]
upgrade_3.0_3.1.sh
upgrade_3.1_4.0.sh

Ezeken végigmentem a leírása szerint. Egyikkel több, másikkal kevesebb időt töltött és weben az új verzióval fémjelzett felület fut. Kötetek működnek. Akkor sikerült az átmigrálás vagy attól még a régi formátumot használja, így nem tudja kiaknázni az új ficsőröket?

Van azonban egy problémám:
Word, excel fájlok közös használatánál gond, hogy nem szinkronizálja át a lock fájlt, így a másik nem veszi észre, hogy valaki használja a fájlt. Az office sem szól, megnyitja rw módban. Ez nem fajin:)

Más: csoport kvótát hogy lehetne beállítani vagy legalább mérni a csoportban lévő kötetek méretét? User kvóta van oké, de az sajnos nem megfelelő nekem.