Docker container / umožnění či autostart ssh

Re:Docker container / umožnění či autostart ssh
« Odpověď #15 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


Re:Docker container / umožnění či autostart ssh
« Odpověď #16 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é.

SR

Re:Docker container / umožnění či autostart ssh
« Odpověď #17 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

Re:Docker container / umožnění či autostart ssh
« Odpověď #18 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.


Re:Docker container / umožnění či autostart ssh
« Odpověď #19 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.
Děkuji za možnost editace příspěvku.


Re:Docker container / umožnění či autostart ssh
« Odpověď #20 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...

Re:Docker container / umožnění či autostart ssh
« Odpověď #21 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
Děkuji za možnost editace příspěvku.

Re:Docker container / umožnění či autostart ssh
« Odpověď #22 kdy: Dnes v 11:38:50 »
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


No nic, je vidět, že si stále nerozumíme...

Po upgradu stacku v entrypoint scriptu nic nebude, nebo tedy pouze to co obsahovala instalační image developera. Takže se nemá co podělat.

A mě stačí opět dopsat pouze znovu ty 2 řádky (ssh + fuse).

A pokud bych měl separátní kontejner pro to rsync/ssh vykopírování a změnila se image (a nějaké cesty v nové Seafile image), stajně bych to musel měnit/updatovat v tomto separátním kont. Stále tedy nevidím žádnou výhodu pro další separátní kontejner.

Re:Docker container / umožnění či autostart ssh
« Odpověď #23 kdy: Dnes v 11:41:05 »
No, i tento pozadavek mi prijde ponekud zvlastni a zda se mi to byt rovnak na vohejbak, ale neznam ten seafile

Chápu a vím že to není úplně ideální, ale je to daný tím, že Seafile má filesystem jako Git či co. Kdyby to mělo normální filesystem tak se to odzálohuje z Volume na hostovi a pohoda...

alex6bbc

  • *****
  • 1 655
    • Zobrazit profil
    • E-mail
Re:Docker container / umožnění či autostart ssh
« Odpověď #24 kdy: Dnes v 12:04:47 »
a zeptam se, proc docker?
pokud to nebotrebuju balancovat treba v kubernetes, kazdou chvili menit a updatovat, tak mi prijde docker zbytecny.

mam treba svuj mejlserver a nevidim duvod to mit v dockeru.

Re:Docker container / umožnění či autostart ssh
« Odpověď #25 kdy: Dnes v 12:06:32 »
a zeptam se, proc docker?
pokud to nebotrebuju balancovat treba v kubernetes, kazdou chvili menit a updatovat, tak mi prijde docker zbytecny.

mam treba svuj mejlserver a nevidim duvod to mit v dockeru.

Je to doporučená instalace developera Seafile...

alex6bbc

  • *****
  • 1 655
    • Zobrazit profil
    • E-mail
Re:Docker container / umožnění či autostart ssh
« Odpověď #26 kdy: Dnes v 12:10:32 »
a zeptam se, proc docker?
pokud to nebotrebuju balancovat treba v kubernetes, kazdou chvili menit a updatovat, tak mi prijde docker zbytecny.

mam treba svuj mejlserver a nevidim duvod to mit v dockeru.

Je to doporučená instalace developera Seafile...

no kdyz chces, ale ja nepotrebuju veci kontejnerovat, takze i kdyz je neco primarne v dockeru, tak ja to nemam rad a vytahnu si to ven. zatim jsem nenasel duvod pro sebe docker pouzivat. chapu, ze je to fajn pro firmu s mnoha projekty a tunou hardware.

Re:Docker container / umožnění či autostart ssh
« Odpověď #27 kdy: Dnes v 13:01:11 »
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.
Ve vlastnostech uvádějí dva způsoby pro Backup and data Recovery

Zálohovat prostředky samotné aplikace obvykle bývá lepší – většinou tak získáte zálohy, se kterými se lépe pracuje. V krajním případě můžete zálohováním mimo aplikaci získat nepoužitelnou zálohu (představte si, že třeba aplikace přesouvá data ze souboru A do souboru B, a zálohovací program zazálohuje nejprve soubor B, když v něm data ještě nejsou, a pak soubor A, když v něm data už nejsou).

Seafile kontejner samotný nemá žádný přístup k zálohám.
To sice nemá, ale pořád při zálohování pouštíte kód uvnitř kontejneru Seafile. Takže útočník vám může posílat do záloh třeba zašifrovaná data, a teprve až budete mít všechny zálohy zašifrované, zašifruje vám i primární zdroj dat.

Pokud kontejner samotný umře, vůbec nic se neděje.
Pokud umře celý kontejner, opravdu se nic neděje. Pokud umře kontejner, ale zůstanou po něm nějaké běžící procesy, které byly spuštěné bokem, není to dobrá situace.


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 lehne Seafile server, je nejrychlejší vzít kompletní zálohu jeho dat (tj. včetně databáze a těch metadat a la git), zkopírovat to na nový server a nad tím spustit novou instanci Seafile. Ve vašem případě řešíte přístup jednoho uživatele k jednomu souboru. Ale pokud lehne Seafile server, pravděpodobně budete potřebovat obnovit všechny soubory, včetně historie, uživatelské účty, přiřazení oprávnění atd.

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.
To platíte kontejnery za kus? Nebo v čem je problém mít tam další kontejner? Kontejnerová technologie byla vymyšlená právě proto, aby jednotlivé služby byly oddělené. Ta otázka nezní: „Jaká je výhoda mít to v samostatném kontejneru?“ Mít to v samostatném kontejneru je standard. Otázka je opačná: „Je nějaký dobrý důvod, proč víc věcí sloučit do jednoho kontejneru, když to je proti principům kontejnerů?“ Nebo pokud mermomocí potřebujete odpověď na vaši otázku – dělat věci standardně je obrovská výhoda, zejména když používáte technologie, o kterých toho moc nevíte. Dělat věci nestandardně znamená akorát si přidělávat problémy, o kterých ani nevíte.

Re:Docker container / umožnění či autostart ssh
« Odpověď #28 kdy: Dnes v 13:32:09 »
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.
Ve vlastnostech uvádějí dva způsoby pro Backup and data Recovery

Zálohovat prostředky samotné aplikace obvykle bývá lepší – většinou tak získáte zálohy, se kterými se lépe pracuje. V krajním případě můžete zálohováním mimo aplikaci získat nepoužitelnou zálohu (představte si, že třeba aplikace přesouvá data ze souboru A do souboru B, a zálohovací program zazálohuje nejprve soubor B, když v něm data ještě nejsou, a pak soubor A, když v něm data už nejsou).

PBS je velmi spolehlivé a osvědčené řešení pro tento případ, nehodláme měnit. Zálohuje samotný systém Seafile i data.

Seafile kontejner samotný nemá žádný přístup k zálohám.
To sice nemá, ale pořád při zálohování pouštíte kód uvnitř kontejneru Seafile. Takže útočník vám může posílat do záloh třeba zašifrovaná data, a teprve až budete mít všechny zálohy zašifrované, zašifruje vám i primární zdroj dat.

Separátní kontejner kontejner by na tom v tomto případě byl úplně stejně. Nicméně napadení ransomware bychom poznali okamžitě. Záloha PBS z předchozího by byla dostupná.

Pokud kontejner samotný umře, vůbec nic se neděje.
Pokud umře celý kontejner, opravdu se nic neděje. Pokud umře kontejner, ale zůstanou po něm nějaké běžící procesy, které byly spuštěné bokem, není to dobrá situace.


Ano, zřejmě zůstane nějaký zombie proces až do restartu/obnovení fce. Vadí to ještě něčemu jinému?


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 lehne Seafile server, je nejrychlejší vzít kompletní zálohu jeho dat (tj. včetně databáze a těch metadat a la git), zkopírovat to na nový server a nad tím spustit novou instanci Seafile. Ve vašem případě řešíte přístup jednoho uživatele k jednomu souboru. Ale pokud lehne Seafile server, pravděpodobně budete potřebovat obnovit všechny soubory, včetně historie, uživatelské účty, přiřazení oprávnění atd.


Opět, řešeno pomocí PBS, pokud server lehne komplet.


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.
To platíte kontejnery za kus? Nebo v čem je problém mít tam další kontejner? Kontejnerová technologie byla vymyšlená právě proto, aby jednotlivé služby byly oddělené. Ta otázka nezní: „Jaká je výhoda mít to v samostatném kontejneru?“ Mít to v samostatném kontejneru je standard. Otázka je opačná: „Je nějaký dobrý důvod, proč víc věcí sloučit do jednoho kontejneru, když to je proti principům kontejnerů?“ Nebo pokud mermomocí potřebujete odpověď na vaši otázku – dělat věci standardně je obrovská výhoda, zejména když používáte technologie, o kterých toho moc nevíte. Dělat věci nestandardně znamená akorát si přidělávat problémy, o kterých ani nevíte.

Chápu. Problém dalšího kontejneru není. Ale i ten další kontejner rozhodně nebude dle všeho výše uvedené best practice a je to další CT/VM ke správě oproti 2 řádkům nestandardu.

Ale nechápejte to prosím tak, že tento postup rozporuji, jen mi přijde v tomto konkrétním případě nic nezlepšující, naopak práci přidělávající...