Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
nastavenia certbot som urcite nemenil, musi to byt v ubuntu takto nastavene ako default.To je správně, že je to tak nastavené. Je díky tomu zajištěné, že je ta služba hned po instalaci funkční.
Za predpokladu ze je sluzba v stave enabled, tak sa pusti pri starte systemu.Ale služby, které se mají spouštět z timeru, se do stavu enabled nepřepínají. Byl by to nesmysl. I pokud bych chtěl spouštět takovou službu v souvislosti se startem systému, použiju k tomu prostředky timeru.
Za predpokladu ze je sluzba nastavena ako daemonSlužby spouštěné z timeru se neanastavují jako daemon (ostatně takový typ služby ani systemd nezná), ale jako oneshot. Ta služba se prostě spustí a když udělá, co má, tak se ukončí. A je to tak v pořádku, systemd se nemá starat o to, aby běžela pořád. Až přijde správný čas, timer službu spustí znovu.
Ak sa ma sluzba vykonavat periodicky, tak nie je daemon a je disabled. Timer sa spusta peridicky podla nastvenia a vola prislusnu sluzbu.Já jsem ovšem psal jenom o timeru.
Ano, je to systemd timer. Timery mají podobný účel, jako cron, ale je to integrované do systemd a umí to s ním lépe spolupracovat.Kód: [Vybrat]Tue 2022-03-08 22:26:28 CET 12h left Tue 2022-03-08 01:35:13 CET 8h ago certbot.timer certbot.service
toto si zije vlastnycm zivotom, nezavisle do cron-u?
preco je ten certbot.service medzi timermi?Je to certbot.timer, který spouští certbot.service. Takhle se to dělá v systemd – máte službu (service), která se spouští jednorázově, tj. spustí se, něco zpracuje a pak se ukončí. A ta služba se sama od sebe nespustí nikdy – ale vytvoří se k ní timer, který říká, kdy se ta služba má spustit.
predpokladam, ze sa tam pridal pri instalacii. ale koli comu?Proto, aby se certbot pravidelně spustil a obnovil certifikáty, pokud je to potřeba. Když máte certbot nainstalovaný z distribuce, je integrován do systému. A v systému, kde je systemd, je správné pravidelné spouštění plánovta pomocí timer jednotek, nebo pomocí cronu.
Niewklko tutorialov o nastaveni certbotu pre obnovu certifikatov som presiel, ale ani jeden nespomynal tento service. Vzdy to len koncilo nastavenim "certbot renew" v crone a hotovo.Protože ty tutorialy to popisují tak, že si vše uděláte ručně. Vy jste ale použil distribuční instalaci, která to ruční nastavení nepotřebuje, protože je to přednastavené už od správce distribučního balíčku.
To je pravda, v pripade od tazatele to je 'par bajtu' ale bylo by dobry, aby programator vedel, jak to funguje a snazil se to psat 'spravne' sam. Ale to se dostavame uz do tematu, kdy dnes programatory nic nezajima a jelikoz mame vsichni 16GB RAM, tak proc bychom na vsechno nekaslali.Ano, programátor se má snažit psát to správně. Ale správně je v tomto případě jednoznačně určené tím, jak se to používá, k čemu je to určené a co tedy bude čitelnější. Ušetřených pár bajtů reference rozhodně není ten důvod, proč to psát jinak – a naopak by to bylo špatně psát kód jinak kvůli pár bajtům, když vůbec nevíme, jestli to má nějaký vliv na výkon. Stejně důležité, jako vyhýbat se nesmyslně neefektivním konstrukcím, je vyhýbat se nesmyslným předčasným optimalizacím.
A ano, ve finale to bude fungovat oboji a jestli programatora zajima/nezajima, ze se tam zbytecne generuji zbytecnosti, je uz vec druha
A hodí se dodat, že v moderním JS jsou i “normální” třídy (class), takže pokud člověk nechce, o prototypy se nemusí zajímat.Jenže ty „normální“ třídy v JavaScriptu jsou pořád založené na prototypové dědičnosti.
takze se zbytecne plytva pameti na necem, co by melo byt pro vsechny objekty stejne a na jednom misteTohle bych vůbec neřešil. Dnešní JavaScriptové frameworky jsou založené na tom, že se stále dokola vytvářejí ty samé funkce, takže JavaScriptové enginy se s tím musí umět vypořádat a řešit to efektivně.
pravidlo bude mít --source-port 8080 (to je číslo cílového portu co než to dorazí do routeru)Ne, source je zdrojový port. Při DNATu se pro klasické TCP/IP protokoly, jako např. HTTP, chcete rozhodovat podle čísla cílového portu, ne zdrojového – ten je obvykle volen náhodně.
DNAT v tomtopřípadě bych nepoužil, protože vyžaduje rovnák na ohejbák (že pakety obvykle požere rpfilter nebo že FORWARDOVÁNÍ MEZI loopbackem se nedělá) - REDIRECT je lepší volba (ostatně --to je jen číslo portu)Ty vaše komentáře jsou taková snůška pravdivých tvrzení, nesmyslů a vět, jejichž význam mi uniká. Rozdíl mezi REDIRECTEM a DNATem v iptables je ten, že REDIRECT mění IP adresu cíle na IP adresu aktuálního počítače. Je to tedy opak maškarády – nespecifikujete, na jakou IP adresu se má adresa v paketu přepisovat. Výhodné je to třeba když máte dynamicky přidělované IP adresy. DNAT je naproti tomu obecný, jste to vy, kdo určuje cílovou IP adresu i port. Ovšem musíte je uvést (alespoň jedno z toho) – no, a když bude mít zařízení dynamickou IP adresu, budete ji muset vždy nejprve zjistit a pak do pravidel nastavit správnou IP adresu.
Tak to napíšu potřetí. Na WAN interfejsu mám nahozenou maškarádu a potřebuji port 8080 přesměrovat na port 80 za tímto překladem adres. Port 8080 musí být dostupný/otevřený a port 80 ne.Nemusíte to psát potřetí. Stačí, když to napíšete jednou, ale pořádně. Co znamená „za tímto překladem adres“? Ta aplikace na portu 80 běží na stejném zařízení, kde je NAT (tedy vaše maškaráda, a teď k tomu potřebujete přidat ještě DNAT), nebo na jiném zařízení? Já si zkusím zavěštit, že je to ta druhá varianta, a celou dobu to před námi tajíte – tedy že máte třeba nějaký domácí router, tam děláte NAT – a někde v domácí síti máte server, kde běží nějaký web, který má být z venku dostupný na portu 8080.
Rád bych se dozvěděl vaše čtyři způsoby, jak to vyřešit.
Mám zálohu co 2 hodiny.Tak zálohujte častěji.
Jde mi o snížení ztráty dat, tj. abych nepřišel o data za dvě hodiny, ale třeba o data za 5-10-15 minut.
Nemá/nemusí to být spolehlivá záloha dat, pokud bude načutnutá, tak se to nepoužijeJste si jistý tím, že dokážete poznat, že je ta záloha špatná?
Spíš mě děsí ty zmíněné náznaky "ne"spolehlivosti DRBD.Distribuované úložiště není záloha.
Poradil mi přesměrování na localhost a to nefungovaloFirewall a NAT fungoval. Jenže vy jste nenastavil správně další věci, které jsou potřeba, aby to fungovalo. Navíc já jsem vám poradil celkem minimálně 4 způsoby, jak to vyřešit.
což v zadání nemám a takhle to nechci.Problém je právě v tom, že jsou to tři různé věci – co potřebujete vyřešit za problém, co chcete, a na co se ptáte. Co potřebujete vyřešit za problém nevíme vůbec, co chcete mlhavě tušíme.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.