Příspěvky

151

Software / Re:Chrome 98: nelze potvrdit průchod na TLS 1.0 a 1.1

« kdy: 07. 02. 2022, 13:51:14 »

Firefox už podporu TLS 1.0 a 1.1 dokonce vypnul 10. března 2020 ve verzi 74. Kvůli pandemii ji ale zase dočasně zapnul, aby se uživatelé neměli problém dostat na weby s důležitými informacemi, které ještě nepodporují novější šifrovací protokoly. Je tedy jisté, že podpora starších TLS bude zase vypnuta.

To ja vim. Ten termin byl i docela jasne oznamen. Ale tady v pripade Chrome clovek ani nenajde info, ze doslo k tomu vypnuti, v release notes o tom neni ani slovo.

152

Software / Re:Chrome 98 a tls1/1.1 - jiz nelze potvrdit pruchod skrz stare verze

« kdy: 07. 02. 2022, 12:36:43 »

Je toho celkem dost, co už v Chrome nejde bypassnout. Takže na takové věci používám Firefox.
Zdar Max

To sic, ale jak dlouho to aktualizovany FF bude umet?

153

Software / Chrome 98: nelze potvrdit průchod na TLS 1.0 a 1.1

« kdy: 07. 02. 2022, 11:57:40 »

Ahoj,

po upgrade na chrome a chromium 98 nelze preskocit varovani o starem tls. Mam to chapat, ze dle https://chromestatus.com/feature/5759116003770368 (M-98) to skutecne deaktivovali? Jde to pripadne nejak obejit v ramci chrome (napr. reinstalaci na enterprise verzi, atd.)?

154

Server / Re:Přístupová práva k souborům pro podřízeného uživatele

« kdy: 26. 01. 2022, 15:29:17 »

Ptate se na komplexitu, ktera vyplyva z navrhu a pozadavku aplikace na funkcionality.

Napr, co znamena administrace? Pouze zevnitr aplikace, nebo i ze serveru (typicky, ssh pristup)? Atd.

Nekdo to resi oddelenim dat od aplikace. At uz v ramci serveru, nebo sitove pristupnych sluzeb - rozsirene acl, db, fileshare, overlay, etc etc.

Na tahle obecny dotaz nelze moc konkretne odpovedet...

155

Server / Re:Přístupová práva k souborům pro podřízeného uživatele

« kdy: 26. 01. 2022, 13:41:58 »

Bez kontejnerizace je to jednoduche.

Nginx root slozka pro daneho uzivatele prava 2750, user:www-data.
Nastavit php(etc), aby bezelo pod danym uzivatelem.

Vysledek: do daneho rootu se dostane jen uzivatel a www-data. Uzivatel smi zapisovat, www-data jen cist. Jakkakoliv data vlozena skrz web budou zase user:www-data. Web server tedy nebude mit vubec prava zapsat kdekoli (pokud to nejaky tatar nezmeni), o zmeny na disku se bude starat ten php(etc) modul.

156

Sítě / Re:Jak protáhnout optiku trubkou do obýváku?

« kdy: 25. 01. 2022, 14:28:33 »

Tohle https://www.fs.com/products/40191.html ma cca 10x10mm ten modry zacvakavac. Ale vypada to demontovatelne, takze trubka d=16mm by mohla stacit. Pripadne jsou takove kabely, ktere maji zacvakavac per vlakno.

Jiny zpusob je zvetsit trubku.

ad 1] Zakonceni neci takovym: https://www.fs.com/products/35488.html
ad 2] asi https://www.fs.com/de-en/c/bidi-sfp-89 (ale BX neznam).

157

Hardware / Re:Poškodená partition table

« kdy: 20. 01. 2022, 14:29:47 »

Udelat dd obraz, pak experimentovat na obrazu.

Mozne napady:
Pokud se jen zapsala tabulka, ale neformatoval se disk, tak bych zkusil zapsat tu tabulku znova s puvodnim rozlozenim oddilu (musi to sedet presne na start/end cisla bloku), nasledne zkusit obnovu ze zaloznich superbloku ci recovery nastroje.

158

Server / Re:SFTP, ChrootDirectory, a přístup uživatelů do VirtualHost (každý odděleně)

« kdy: 14. 01. 2022, 08:58:07 »

Každá doména bude mít vlastní chroot (dále příklady pro první doménu) /var/www/domena1_cz/, který vlastní root:root 775 (včetně všech rodičů).
Virtuální adresáře Apache pak odkazují na složky /var/www/domena1_cz/www/. Tuto složku vlastní www-data:www-data 775.

Jak dlouho chcete cekat, nez ten server nekdo hackne? Tohle neni multiuzivatelsky bezpecne ani na prvni pohled.

159

Server / Re:Nagios nejde spustit na openSUSE Tumbleweed

« kdy: 07. 01. 2022, 08:20:01 »

Vypiste si jednotlive kroky funkce get_var() a porovnejte je s pozadavkem na shift. Ten shift podle mne dela akorat to, ze skoci na dalsi pozici v "poli".

160

Server / Re:Nagios nejde spustit na openSUSE Tumbleweed

« kdy: 06. 01. 2022, 14:10:09 »

A co je na tom radku 16 resp. kolem okolo ohledne tech shift?

161

Software / Re:algoritmy round robin dns na klientovi (DNS vrací víc A záznamů)

« kdy: 04. 01. 2022, 17:30:02 »

Chcete odpoved? Tak si nastudujte zdrojaky (pokud jsou dispozici) jednotlivych systemovych knihoven, zajistujicich resolving, dale zdrojaky aplikaci, jak si to resi (pokud nepouziji systemovou knihovnu).

Co se tyce dns, tak to nema zadny flag ohledne rizeni zpracovani seznamu adres.

162

Server / Re:Reverzní proxy - jaké používáte checky?

« kdy: 15. 12. 2021, 22:26:11 »

Vidím to také tak, že problém je v kontrole, která selže i pokud backend funguje. Musíte odlišit a specifikovat funkčnost jednotlivých komponent a výpadky jednotlivých komponent řešit adekvátním způsobem (pro jednotlivé vrstvy se bude lišit) - a to tak, aby infrastruktura jako celek fungovala.

Co přesně je ta kontrola pingem? Myslíte ICMP ping nebo aplikační ping ve smysli heartbeat nebo - ?

Haproxy umi definovat jeden check pro pool. Takze pokud ten check selze (at uz je na cilove strane pouze nejaka status stranka, ci komplexni skript na vyhodnoceni stavu), tak pak staci dany soubor zmenit/odstranit a veskere backendy toho poolu leti dolu.

Z toho duvodu zvazujeme, zda nezkusit cestu pres monitorovani primo HTTP statusu z dotazu, ale trochu se obavam, ze odpojovani backendu tam bude castejsi (a z toho vznikl dotaz, zda lze zajistit, aby aspon jeden backend byl vzdy pripojen).

163

Server / Re:Reverzni proxy - jake pouzivate checky?

« kdy: 15. 12. 2021, 22:23:33 »

Problem je snad jasny ne? Jednoducha demonstrace pomoci pingu:
1] kazdy backend v danem poolu je kontrolovan pingem
2] z nejakeho duvodu prestane ping fungovat (napr. nedomyslena uprava na FW)
3] kontroly na proxy selzou pro vsechny backendy -> odpojeni vsech backendu

Ale pritom aplikace je funkcni.

Backup parametr mi nepripada jako rozumne reseni takoveho problemu.

Problém
Teď už je problém jasný. Rozumné řešení je oprava kontroly nebo backendu tak, aby kontrola neselhávala, když je backend funkční. Pokud z nějakého důvodu nechcete/nemůžete použít rozumné řešení, je podle mne backup přesně to, co hledáte – jeden nebo více backendů zduplikujete v konfiguraci jako backup, a když všechny primární servery budou označené jako nefunkční, začne nginx posílat požadavky na backup (což budou shodou okolností ty samé backend servery). Řešení je to sice zvláštní, ale nevidím důvod, proč by nemělo fungovat (v rámci limitů toho, že nechcete rozumné řešení).

Jinak v případě (falešného) výpadku všech primárních backendů směrovat veškerý provoz na jediný backend mi nepřipadá jako dobrý nápad. Pokud tam ten load balancer nemáte jen tak pro legraci, ten jediný backend zátěž neustojí a odpadne nebo bude odpovídat velmi pomalu (čímž se teda konečně srovná stav hlášený kontrolou se skutečným stavem).

Problem parametru backup je ten, ze (napr. v pripade haproxy) ten backend "backup" je monitorovany (a tim se propaguje to monitoringu, fw apod). Ale jako jo, provozni naklady jsou proti nakladum na vypadek defacto nulove.

164

Server / Re:Reverzní proxy - jaké používáte checky?

« kdy: 15. 12. 2021, 22:21:45 »

Tu si dovolím tvrdiť, že máte veľmi zlý prístup. Ak je niečo FAIL, tak je to FAIL. Neexistuje "napoly fail alebo akože fail". Ošetrite si checky tak aby reprezentovali realitu. Na čo budem posielať zákazníka na Internal Server Error?

Jenze FAIL je na strane checku, ne na strane backendu. Takze by zakaznik videl aplikaci, ne Internal Server Error.

165

Server / Re:Reverzni proxy - jake pouzivate checky?

« kdy: 15. 12. 2021, 16:57:50 »

Na čo chceš posielať traffic z vonku na FAIL backend?
Fuknčne som to riešil s vývojármi tak, že mi vytvorili na app endpoint. Napr. web.app.cz/check ktorý vracal HTTP 200 ak všetky interné checky prebehli OK. Ak nastal nejaký problém na backende, tak sa vrátil nejaký špecfický non200 kód (spravidla http 500 family).
V haproxi si vieš nastaviť aby špecifické IP (napr. RFC1918) smerovalo na backend bez balancovania a tým obchádzalo checky.

Eliminace problemu s chybovym checkem. Lepsi posilat traffic na FAIL backend v pripade, ze vsechny jsou ve stavu FAIL, nez neposilat nic.