Poslední příspěvky

1

Studium a uplatnění / Re:Byli jste někdy na podpoře?

« Poslední příspěvek od registrovany123 kdy Dnes v 15:11:39 »

Stejně už bylo všechno řečeno, úředníci jsou benevolentní když někdo pracuje a po delší době jde na pracák.

To jen zase nějaký pozér a ptm Poljak, co píše a otravuje pod svým vlastním jménem podobě jako Jirsk, aby se prezentoval když HR napíše do Google vyhledavače "Martin Poljak", tady kvůli pár stovkám navíc na MD-rate vytěžuje diskuzí svých kolegů a píše pozerské chujoviny, které by i ten blbý Chatbot identifikoval jako nesmysly.

HRko, jestli to tady čteš, protože hledáš něco na Poljaka, který se u vás uchází o práci, tak je to trefa do černého, přesně takového pozéra na tu prac. pozici web vývojáře hledáte, skvěle zapadne do vašeho zm. kolektivu a když si nějaká ovce bude stěžovat na únavu z práce, pomůže firmě a řekne ji, "Nikdo tě nenutí Franto, je to jen otázka mindsetu.". Je to váš člověk.

2

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

« Poslední příspěvek od HanzHanz kdy Dnes v 15:04:44 »

Mimochodem, zásadní chyba je už to, že v tom obrazu vůbec sshd je. (Což je samozřejmě chyba autora toho obrazu, ne vaše). Ale je to další důvod, proč na to nespoléhat – protože v další verzi obrazu to sshd být nemusí a vám pak přestane vaše zálohovací řešení fungovat.

Jo, jo, to samozřejmě beru včetně vašeho min. příspěvku a chápu.

Tak myslím, že asi nejlepší bude to přemigrovat z CT na VM a bude klid.

Díky a pěknej víkend...

3

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

« Poslední příspěvek od Filip Jirsák kdy Dnes v 14:28:17 »

Mimochodem, zásadní chyba je už to, že v tom obrazu vůbec sshd je. (Což je samozřejmě chyba autora toho obrazu, ne vaše). Ale je to další důvod, proč na to nespoléhat – protože v další verzi obrazu to sshd být nemusí a vám pak přestane vaše zálohovací řešení fungovat.

4

Studium a uplatnění / Re:Byli jste někdy na podpoře?

« Poslední příspěvek od Lord_Pitzbudka kdy Dnes v 14:14:03 »

necituju, bo jsem reagoval na posledního předřečníka.

5

Studium a uplatnění / Re:Byli jste někdy na podpoře?

« Poslední příspěvek od pruzkumbojem kdy Dnes v 14:12:56 »

Necitujes, tak by mne zajimalo na koho odpovidas.

Tohle plati minimalne na tretinu lidi tady.

Ja citim frustraci jen kdyz to ctu, nejen frustraci ohledne toho primarniho tematu (ktery je relevantni i pro mne, mam vlastni zkusenosti a pohled, ale nestoji ti za publikovani kvuli tem osobnim pseudointelektualnim utokum).

A nejen v tomhle vlaknu. Root komunita je vskutku specialni. Aby clovek dostal dve relevatni odpovedi, musi se prohrabat 90% arogantniho balastu.

Co te tak ctu, tak takovej uzlicek nestesti a frustrace aby clovek pohledal

Tobe v nejaky prsci museli strasne moc ublizit a zanechalo to nasledky.

6

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

« Poslední příspěvek od Filip Jirsák kdy Dnes v 14:01:12 »

Nebo se zeptám ještě jinak. Jaký by byl rozdíl, kdyby to nebyl CT ale VM s ssh serverem, a ta VM by chcípla stejně jako ten CT? Mě to přijde dost podobný, ne-li stejný, tedy ty následky...

CT je méně náročný na prostředky, kernel bere z hosta a je ideální na jednorázové věci, super rychle startuje atd. My CT spíše používáme na testovací věci, pokud developer daného sw přímo nedoporučí pro produkci.

Ve virtuálním stroji vám běží celý operační systém, který je stavěný na to, že v něm běží spousta nesouvisejících služeb. Proto máte v distribucích typicky systemd nebo nějakého jiného správce služeb, který se stará u jejich běh.

Kontejnery jsou dělané pro běh jedné služby. Nic vám nebrání v kontejneru provozovat skoro celý operační systém se spoustou služeb, ale není to něco, k čemu by byly kontejnery určené. A je pak na vás, abyste věděl, co děláte, a správně to nakonfiguroval a provozoval.

Když „chcípne“ VM, znamená to, že přestal běžet celý ten OS. Když „chcípne“ kontejner, znamená to, že se ukončil  proces, který tvořil ten kontejner, a OS ukončí jeho potomky. Pokud z toho kontejneru byly nastartované nezávislé procesy, které nejsou potomkem toho hlavního procesu, ty vám zůstanou v systému běžet, protože už nemají žádnou vazbu k tomu hlavnímu procesu.

Kontejnery nejsou nic jiného, než procesy izolované pomocí cgroups už na úrovni jádra operačního systému. Jádro nezná žádnou entitu „kontejner“ – kontejner je jenom naše označení pro procesy nakonfigurované určitým způsobem.

7

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

« Poslední příspěvek od HanzHanz kdy Dnes v 13:40:42 »

To: Filip J.

Nebo se zeptám ještě jinak. Jaký by byl rozdíl, kdyby to nebyl CT ale VM s ssh serverem, a ta VM by chcípla stejně jako ten CT? Mě to přijde dost podobný, ne-li stejný, tedy ty následky...

CT je méně náročný na prostředky, kernel bere z hosta a je ideální na jednorázové věci, super rychle startuje atd. My CT spíše používáme na testovací věci, pokud developer daného sw přímo nedoporučí pro produkci.

8

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

« Poslední příspěvek od HanzHanz 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í...

9

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

« Poslední příspěvek od Filip Jirsák 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.

10

Windows a jiné systémy / Re:Windows7 SP1 x32: boot zo SATA, systém na NVMe

« Poslední příspěvek od LA MA kdy Dnes v 12:36:34 »

Pani dakujem za pomoc. Nakoniec som sa rozhodol ponechat v SATA porte samostatny disk s operacnym systemom a data budu na NVMe v PCIe. Ide o dosku, kde nemozem modifikovat BIOS a rovnako z dovodu servisu nemozem nahrat dalsi zavadzac. Takto to zostane relativne nativne. Dakujem.