1
Server / Re:Docker container / umožnění či autostart ssh
« Poslední příspěvek od to_je_jedno kdy Dnes v 11:37:19 »No, i tento pozadavek mi prijde ponekud zvlastni a zda se mi to byt rovnak na vohejbak, ale neznam ten seafile
Poslední příspěvky
2
Server / Re:Docker container / umožnění či autostart ssh
« Poslední příspěvek od HanzHanz kdy Dnes v 11:31:54 »Rozhodne samostatny kontejner ciste pro backup. Pokud nekde potrebujes supervisor tak je potreba hledat a rozebirat proc, protoze vetsinou (nerikam, ze vzdy) to znamena spatny navrh.
Já supervisor nepotřebuji, pouze ssh. Supervisor byla rada od SH...
3
Server / Re:Docker container / umožnění či autostart ssh
« Poslední příspěvek od to_je_jedno kdy Dnes v 11:30:09 »Rozhodne samostatny kontejner ciste pro backup. Pokud nekde potrebujes supervisor tak je potreba hledat a rozebirat proc, protoze vetsinou (nerikam, ze vzdy) to znamena spatny navrh.
4
Server / Re:Docker container / umožnění či autostart ssh
« Poslední příspěvek od HanzHanz kdy Dnes v 11:29:12 »To: Filip Jirsák
Pane Jirsáku, myslím že Seafile zálohování řešené nemá, nebo jsem to nenašel. Každopádně ani to jejich zálohování (pokud by existuje) vůbec není potřeba, celý kontejner/stack včetně VM nám zálohuje Proxmox Backup Server.
Seafile kontejner samotný nemá žádný přístup k zálohám. Pokud kontejner samotný umře, vůbec nic se neděje. Zprovozní se znova ze zálohy PBS. Pokud se někdy přeruší nedokončí rsync /zdroj seafile-fuse /cíl-někam, taky se nic nestane, proběhne znovu po obnovení funkčnosti Seafile kontejneru.
Nicméně, představte si situaci, že uživatel, kterého data se synchronizují na Seafile ztratí ntb, nepamatuje si přístup (jméno/heslo) nedej bože ztratí i tel., kde má 2FA. A v tom samém okamžiku lehne Seafile server. Obnovení dat ze zálohy bude rychlé, přístup bez hesla a 2FA není hned, ano admin samozřejmě může vyresetovat, vypnout 2FA. Nicméně pokud nutně potřebuje hned nějaký konkrétní soubor, hned to prostě nejde...
Pokud ale mám ještě další formu formu zálohy jasně čitelného filesystému pomocí kombinace rsync/fuse/proxmox backup server, je to otázka minuty.
Chápu, že best practice je jiný kontejner, který by řešil to vykopírování pomocí rsync/ssh, ale fakt v tom v tomto konkrétním případě nespatřuji vůbec žádnou výhodu, pouze kontejner navíc.
Ale každopádně děkuji za zajímavé postřehy.
Pane Jirsáku, myslím že Seafile zálohování řešené nemá, nebo jsem to nenašel. Každopádně ani to jejich zálohování (pokud by existuje) vůbec není potřeba, celý kontejner/stack včetně VM nám zálohuje Proxmox Backup Server.
Seafile kontejner samotný nemá žádný přístup k zálohám. Pokud kontejner samotný umře, vůbec nic se neděje. Zprovozní se znova ze zálohy PBS. Pokud se někdy přeruší nedokončí rsync /zdroj seafile-fuse /cíl-někam, taky se nic nestane, proběhne znovu po obnovení funkčnosti Seafile kontejneru.
Nicméně, představte si situaci, že uživatel, kterého data se synchronizují na Seafile ztratí ntb, nepamatuje si přístup (jméno/heslo) nedej bože ztratí i tel., kde má 2FA. A v tom samém okamžiku lehne Seafile server. Obnovení dat ze zálohy bude rychlé, přístup bez hesla a 2FA není hned, ano admin samozřejmě může vyresetovat, vypnout 2FA. Nicméně pokud nutně potřebuje hned nějaký konkrétní soubor, hned to prostě nejde...
Pokud ale mám ještě další formu formu zálohy jasně čitelného filesystému pomocí kombinace rsync/fuse/proxmox backup server, je to otázka minuty.
Chápu, že best practice je jiný kontejner, který by řešil to vykopírování pomocí rsync/ssh, ale fakt v tom v tomto konkrétním případě nespatřuji vůbec žádnou výhodu, pouze kontejner navíc.
Ale každopádně děkuji za zajímavé postřehy.
5
Bazar / Re:Koupím MicroServer Gen8(7)
« Poslední příspěvek od BoaR kdy Dnes v 11:24:58 »co konkretne to je ? ze bych na top kouknu.
6
Server / Re:Docker container / umožnění či autostart ssh
« Poslední příspěvek od SR kdy Dnes v 11:17:49 »V čem je prosím tě lepší/bezpečnější/sluníčkovější :-), že vytvořím další kontejner, kterej řeší úplně to stejný co potřebuju? U toho stávajícího Seafile kontejneru mi stačí přidat 2 řádky do entrypoint scriptu, přesně toto:
service ssh start
/opt/seafile/seafile-server-latest/seaf-fuse.sh start /mnt
Lepsi je to v tom ze jste takto sahl do zavadece seafile v tuhle chvili vam to treba funguje ale po zmene nemusi. Muze se v tom zavadeci neco zmenit muze se zmenit adresa /opt/seafile/seafile-server-latest/seaf-fuse.sh muze se stat cokoli vy nad tim nemate kontrolu mozna si rikate ze s kazdou novou verzi seafile budete kontrolovat obsah entrypointu ale to delat urcite nebudete.. bud na to zapomenete nebo vas nekdo vystrida.. autor vam dal otestovany funkcni kus kodu a vy jste sahl na jedno z jeho citlivich mist. v tu chvili jste ztratil veskere zaruky... ztratil jste jednu z vyhod proc se kontjenery pouzivaji.
Mozna to bude fungovat mozna ne mozna se to pokazi tak ze na to prijdete v tom lepsim pripade hned a opravite to snadno v horsim az po case a bude to bolet
7
Server / Re:Docker container / umožnění či autostart ssh
« Poslední příspěvek od Filip Jirsák kdy Dnes v 10:59:10 »To, že se to takto nedělá, má dobrý důvod. Kontejnery nejsou nic jiného, než abstrakce nad určitými vlastnostmi linuxového jádra. Z hlediska systému je kontejner proces (určitým způsobem nakonfigurovaný) a všechny jemu podřízené procesy. Když se ukončí hlavní proces (ať už sám nebo signálem zvenčí), ukončí i všechny podřízené procesy a tím se ukončí i kontejner. Když tam nastartujete bokem nějaký jiný proces, a hlavní proces se ukončí, zůstane vám běžet proces v neexistujícím kontejneru.
Používá se i to, že v kontejneru běží nějaké podpůrné procesy pro ten hlavní kontejner (řeší třeba logování, přístup apod.) – pak ale musí hlavním procesem v kontejneru být něco, co se o všechny ty podřízené procesy postará, ukončí je při ukončení hlavního procesu a předává informace mezi hostitelem a hostem. Tj. když se ukončí hlavní služby v kontejneru, ukončí se i ten správcovský proces a tím celý kontejner. Když přijde z venku signál k ukončení do toho správce, pošle to dál té hlavní službě.
Neznám ten vás konkrétní způsob použití. Ale pokud můžete nad daty (tj. ve vašem případě složkou, kde jsou data Seafile) pustit víc instancí aplikace, tak se zálohování řeší tak, že při zálohování spustíte druhý kontejner, který se připojí ke stejným datlům a zazálohuje je. Ten zálohovací kontejner běží jen po dobu zálohování. Má to i tu výhodu, že hlavní kontejner služby nemusí mít vůbec přístup k zálohám, takže kdyby vám někdo napadl tu hlavní službu, nemá možnost hned zlikvidovat i zálohy.
Vzhledem k tomu, že Seafile předpokládám udržuje i historii souborů, připadalo by mi logičtější zálohovat celý jeho adresář a v případě potřeby obnovy nad ním spustit druhou instanci Seafile, ve které najdete potřebnou verzi souboru a tu obnovíte. Akorát je potřeba dát pozor na to, zda ta záloha musí být konzistentní (k jednomu časovému okamžiku) nebo ne.
No a do třetice, Seafile chápu jako nějaké úložiště souborů – velmi by mne překvapilo, kdyby nějaké možnosti zálohování nemělo přímo vestavěné nebo zdokumentované. To je cesta, kterou bych osobně začal – použít prostředky přímo té aplikace.
Pokud by nic z předchozího nešlo, předpokládám, že fuse mount komunikuje s Seafile přes nějaký síťový protokol Seafile, takže ho klidně můžete spustit v jiném kontejneru a z toho jiného kontejneru provést zálohu. Tj. bylo by to podobné, jako první případ, ale nepřipojoval byste se přímo k datům Seafile, ale pomocí fuse mount byste se připojil k té běžící instanci Seafile „přes síť“. Byl oby nutné vyřešit, aby ten zálohovací kontejner viděl síťově na ten hlavní kontejner se Seafile, ale to je řešitelné.
Osobně bych se ale nejprve podíval na možnosti zálohování, která má předpokládám Sealfile vestavěné.
Používá se i to, že v kontejneru běží nějaké podpůrné procesy pro ten hlavní kontejner (řeší třeba logování, přístup apod.) – pak ale musí hlavním procesem v kontejneru být něco, co se o všechny ty podřízené procesy postará, ukončí je při ukončení hlavního procesu a předává informace mezi hostitelem a hostem. Tj. když se ukončí hlavní služby v kontejneru, ukončí se i ten správcovský proces a tím celý kontejner. Když přijde z venku signál k ukončení do toho správce, pošle to dál té hlavní službě.
Neznám ten vás konkrétní způsob použití. Ale pokud můžete nad daty (tj. ve vašem případě složkou, kde jsou data Seafile) pustit víc instancí aplikace, tak se zálohování řeší tak, že při zálohování spustíte druhý kontejner, který se připojí ke stejným datlům a zazálohuje je. Ten zálohovací kontejner běží jen po dobu zálohování. Má to i tu výhodu, že hlavní kontejner služby nemusí mít vůbec přístup k zálohám, takže kdyby vám někdo napadl tu hlavní službu, nemá možnost hned zlikvidovat i zálohy.
Vzhledem k tomu, že Seafile předpokládám udržuje i historii souborů, připadalo by mi logičtější zálohovat celý jeho adresář a v případě potřeby obnovy nad ním spustit druhou instanci Seafile, ve které najdete potřebnou verzi souboru a tu obnovíte. Akorát je potřeba dát pozor na to, zda ta záloha musí být konzistentní (k jednomu časovému okamžiku) nebo ne.
No a do třetice, Seafile chápu jako nějaké úložiště souborů – velmi by mne překvapilo, kdyby nějaké možnosti zálohování nemělo přímo vestavěné nebo zdokumentované. To je cesta, kterou bych osobně začal – použít prostředky přímo té aplikace.
Pokud by nic z předchozího nešlo, předpokládám, že fuse mount komunikuje s Seafile přes nějaký síťový protokol Seafile, takže ho klidně můžete spustit v jiném kontejneru a z toho jiného kontejneru provést zálohu. Tj. bylo by to podobné, jako první případ, ale nepřipojoval byste se přímo k datům Seafile, ale pomocí fuse mount byste se připojil k té běžící instanci Seafile „přes síť“. Byl oby nutné vyřešit, aby ten zálohovací kontejner viděl síťově na ten hlavní kontejner se Seafile, ale to je řešitelné.
Osobně bych se ale nejprve podíval na možnosti zálohování, která má předpokládám Sealfile vestavěné.
8
Sítě / Re:Je možné rozšířit síť bezdrátově na vzdálenost 2 km?
« Poslední příspěvek od Tonda kdy Dnes v 10:59:07 »Trochu mě to zajímá, tak jsem si něco zjistil. LoRa je nepoužitelně pomalá a pro HaLow jsou 2 km už pomalu hraniční vzdálenost, takže pokud jsou v cestě nějaké větší překážky, tak to nepojede a i v dobrých podmínkách by rychlost byla dost slabá.
Každopádně zakladatel vlákna se tu už čtyři dny neukázal, takže je to už jen taková akademická debata
Každopádně zakladatel vlákna se tu už čtyři dny neukázal, takže je to už jen taková akademická debata
9
Server / Re:Docker container / umožnění či autostart ssh
« Poslední příspěvek od HanzHanz kdy Dnes v 10:49:59 »To SR:
Hele, chápu, že jsi mi chtěl poradit, ale nějak to prostě nevyšlo, nebo nechápu ty výhody...
Moje instalace Seafile má samozřejmě persistentní Volume na data i databázi, jakýkoli upgrade celýho stacku funguje okamžitě.
A teď k tomu zálohování...
V čem je prosím tě lepší/bezpečnější/sluníčkovější :-), že vytvořím další kontejner, kterej řeší úplně to stejný co potřebuju? U toho stávajícího Seafile kontejneru mi stačí přidat 2 řádky do entrypoint scriptu, přesně toto:
service ssh start
/opt/seafile/seafile-server-latest/seaf-fuse.sh start /mnt
Hele, chápu, že jsi mi chtěl poradit, ale nějak to prostě nevyšlo, nebo nechápu ty výhody...
Moje instalace Seafile má samozřejmě persistentní Volume na data i databázi, jakýkoli upgrade celýho stacku funguje okamžitě.
A teď k tomu zálohování...
V čem je prosím tě lepší/bezpečnější/sluníčkovější :-), že vytvořím další kontejner, kterej řeší úplně to stejný co potřebuju? U toho stávajícího Seafile kontejneru mi stačí přidat 2 řádky do entrypoint scriptu, přesně toto:
service ssh start
/opt/seafile/seafile-server-latest/seaf-fuse.sh start /mnt
10
Server / Re:Docker container / umožnění či autostart ssh
« Poslední příspěvek od SR kdy Dnes v 10:37:15 »Ok takze jak bych to videl ja data mate predpokladam na Volume to proste musite jinak si koledujete o prusvih.
Seafile si na tom volume dela vlastni file system pres mount fuse tzn z venku to vidite jen jako Blob a vy by jste je chtel zalohovat po souborech ok dava smysl.
Tzn udelam novy kontejner do ktereho nainstaluju ten fuse co pouziva seafile. Do tohoto kontejneru namountuji ten samy volume (idealne Read only tim mam zaruceno ze data nepodelam).
Pustim normalne kontejneru seafilu nemusim se mu hrabat v init skriptech.
Vedlejsi kontejner ma namountovana data a bezi tam SSH pro rsync proc ne.
Komplikace bude udrzovat ten fuse modul ve stejne verzi jako ma seafile proto je tu varianta ze bych pustil znovu cely ten image seafilu (ten uz to ma nainstalovane) ale misto seafilu bych v nem pustil jen a pouze to SSHcko to uz umite...
Vyhoda: kdyz budete upgradovat seafile tak proste jen zmenite verzi image, tim ze jste mu nesahal na entrypoint tak docela urcite nabehne. V "backup" kontejneru taky vzdy jen zmenite verzi na tu samou => budete mit garanci ze FUSE je v te same verzi data uvidite bez problemu.
Sahat do entrypointu budete ale nebude to tolik vadit tim ze v tom backup kontejneru pobezite "SVOJE" sluzby tak si za ne zodpovidate sam vite co se tam deje a mate to pod kontrolou nebudete se hadat s vedlejsimi procesy / nebudete se byt se seafilem
Takto nak bych to videl ja kdybych to chtel udelat jednoduse.. za sebe bych si radeji udelal mensi image pro ten backup a ten fuse tam nainstaloval rucne bude s tim vic jebani ale je to cistejsi a image bude vyrazne stihlejsi. (na druhou stranu ten image uz tam stejne mate kuli seafile samotnemu a docker ma deduplikaci celkem dobre zmaklou). Navic je to takto i bezpecnejsi protoze na data budete sahat jen pro cteni a muzete si kontejnery oddelit i na urovni uzivatelu..
Seafile si na tom volume dela vlastni file system pres mount fuse tzn z venku to vidite jen jako Blob a vy by jste je chtel zalohovat po souborech ok dava smysl.
Tzn udelam novy kontejner do ktereho nainstaluju ten fuse co pouziva seafile. Do tohoto kontejneru namountuji ten samy volume (idealne Read only tim mam zaruceno ze data nepodelam).
Pustim normalne kontejneru seafilu nemusim se mu hrabat v init skriptech.
Vedlejsi kontejner ma namountovana data a bezi tam SSH pro rsync proc ne.
Komplikace bude udrzovat ten fuse modul ve stejne verzi jako ma seafile proto je tu varianta ze bych pustil znovu cely ten image seafilu (ten uz to ma nainstalovane) ale misto seafilu bych v nem pustil jen a pouze to SSHcko to uz umite...
Vyhoda: kdyz budete upgradovat seafile tak proste jen zmenite verzi image, tim ze jste mu nesahal na entrypoint tak docela urcite nabehne. V "backup" kontejneru taky vzdy jen zmenite verzi na tu samou => budete mit garanci ze FUSE je v te same verzi data uvidite bez problemu.
Sahat do entrypointu budete ale nebude to tolik vadit tim ze v tom backup kontejneru pobezite "SVOJE" sluzby tak si za ne zodpovidate sam vite co se tam deje a mate to pod kontrolou nebudete se hadat s vedlejsimi procesy / nebudete se byt se seafilem
Takto nak bych to videl ja kdybych to chtel udelat jednoduse.. za sebe bych si radeji udelal mensi image pro ten backup a ten fuse tam nainstaloval rucne bude s tim vic jebani ale je to cistejsi a image bude vyrazne stihlejsi. (na druhou stranu ten image uz tam stejne mate kuli seafile samotnemu a docker ma deduplikaci celkem dobre zmaklou). Navic je to takto i bezpecnejsi protoze na data budete sahat jen pro cteni a muzete si kontejnery oddelit i na urovni uzivatelu..
