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.


Příspěvky - _Tomáš_

Stran: 1 [2] 3 4 ... 53
16
Server / Re:Komunitní serverhousing
« kdy: 14. 03. 2024, 13:43:55 »
No tak ptal jsem se na komunitní DC, a každá komunita přece nemusí mít hned nějaký právní rámec. Ano, časem taková potřeba vzniknout může a pak se to bude řešit. Komunita určitě nemusí nabízet žádné služby. Jestli se na společném housování serverů domluví dva sousedi, nebo dvacet, to je jedno.

Pletete do toho firemní DC zbytečně. Logicky firma od toho má nějaká očekávání dostupnosti a bezpečnosti, už je proto, že firma na tom DC často stojí a padá. Pochopitelně pak firma musí spňovat nějaké právní normy.

A zcela zapomínáte na bezbariérový přístup a záchody pro 3. pohlaví...

nevím o ničem takovém. Sám jsi v úvodu to připodobnil vpsfree, ti mají ale právní rámec a dodržují (předpokládám) předpisy, tak jsem odpověď směřoval tímhle směřem.

Jak si pak představuješ internetovou přípojku? NAT? VPN? Nebo chceš veřejně routovanou? To bývají docela podstatné náklady.

Jestli hledáš někoho, kdo ti někam strčí tvé dva servery, tak to napiš rovnou, třeba se někdo přihlásí. Kolegové, kamarádi občas využili ochoty firem, kde pracovali, že si tam strčili nějaký svůj HW.

DC6 má např. housing pro 1U za 700 Kč + energie, komunitní si to moc nedokážu představit levněji, vpsfree za tu cenu nabídne dva virtuály.

17
Server / Re:Komunitní serverhousing
« kdy: 14. 03. 2024, 12:20:28 »
Příkon není 5 kWh (předpokládám překlep) a už vůbec ne 5 kW/h, ale 5 kW.

pardon, 5kW jsem myslel jako příkon a nikoliv spotřebu, špatně napsané.


Nevim jak to pocitas - ale 2 racky po 5kW = 10kW, pri 230v to dela 43A, pro 3f 14.49 A idealnich, takze jde o zrizeni samostatne 3F/25A pripojky, ktera nemusi byt mozna, pokud cely jejich dum je napojen na slabsi vedeni.

A pak mate 10kW odpadniho tepla, ktere musite z toho prostoru dat pryc - to jsou uz stavebni upravy + investice do cerpadla (klima).

Ano, odpadní teplo, přístupnost a protipožární izolace je pro hasiče největší problém. 3f 25a pro bytový dům je snad samozřejmost. A to se jedná o dva blbé racky, že jo, to je tak vzhledem ke spotřebě kolik 20 - 40 serverů? Komunitní DC bych asi asi už menší nedokázal představit.

Tak jako nechápu, proč bych měl s hasičema probírat, co si dám do sklepa za běžný elektrický spotřebič. Není to zařízení se zvýšeným rizikem požáru. Ani max. příkon není tak vysoký.

Ty si dej do sklepa co chceš ;), ptal jsi se ale na komunitní DC, tj. někdo by to musel nabízet jako službu, tj. stavební zákon, hasiči a vše okolo by si musel zařídit a to i v případě neziskovky. Nebo jak si tu komunitu představuješ? Souseda, který ti to dá do svého sklepa si můžeš domluvit sám, to není komunita.

10kW tepla se dá prostě foukat ven větrákem - oknem. Bavíme se ale o maximální hodnotě. Při běžném použití bude většina serverů téměř v idle, takže spotřeba bude o dost nižší.

Nj. ale tím větrákem budeš ven foukat i případný požár = problém a nutná stavební úprava nebo to řešit nějakou klimatizací.

Když to dáš do nějaké sklepní kóje, řekněme 6m2, 10kW tepla vůbec není málo, tím běžně vytopíš celý byt v zimě.

Napsal jsem ti konkrétní případ, který jsme řešili a co to znamenalo. Komunitní DC se za mě blbě provozuje, děláme občas malá DC pro firmy. Vůbec si nedokážu představit modus operandi, to je možná i důvod proč vlastně takových aktivit moc není.

18
Server / Re:Komunitní serverhousing
« kdy: 14. 03. 2024, 10:41:00 »
2000KČ/měsíc je většinou nejnižší cena, kam se člověk reálně dostane, kvůli tomu, že chce hostova nějaké starší žravější železo a podobně. Chápu, že komerční DC musí poskytovat nějakou kvalitu služeb, takže člověk platí za zálohované napájení, klimatizaci,..., kterou ale vlastně nepotřebuje. Nekomerční zde znamená obojí pro poskytovatele, i pro zákazníky - na provozovaných službách nezávisí vaše živobytí.

Když se sejde parta lidí, už se může vyplatit pronajmout si někde od SVJ v paneláku kolárnu/sklep/prádelnu/sušárnu, případně třeba garáž.

na umístění dvou racků příkonem 5kWh každý v suterénu bytového domu jsme potřebovali povolení stavebního úřadu, hasičů a musely se udělat stavební úpravy budovy, náklady na realizaci v roce 2020 byly 350 tis a to nepočítám cenu racků a serverů.

Tj. komunitní DC by mělo mít jakou kapacitu? 4 servery? To pak nedává smysl to tak nazývat.

moc rad si poslechnu jak se treba na takovem 1x RPI hraju treba LLM atp.

GPU si můžeš pronajmout v cloudu. Na LLM ti stačí desktop s 1 - 2 GPU, či obdobný server z druhé ruky. Pokud chceš LLM trénovat, tak pro desítky tisíc tokenů, bez epoch a pár GB vstupních dat ti to za pár dní udělá i herní grafika, pokud chceš něco produkčního, tak si připrav alespoň desítky nvidia A100, to prostě doma stejně nedáš.

Mám pro tebe tip, naši kluci od AI si hrají s LLM na macboocích, za cca 100tis poskytují naprosto nejlepší poměr cena/výkon s titěrnou spotřebou, pro domácí použití nic moc lepšího asi neseženeš.

19
prodávají se již hotové, pokud ti nevadí čína (nikoliv alík), tak tihle mají za přijatelnou cenu https://www.senter-e.net/rugged-tablet-pc/8-inch-rugged-tablet-pc/rugged-biometric-tablet.html

V provozu jsem pak viděl tablety od společnosti controltek, víc k tomu ale nevím. Tipuji, že toho bude více jen se to moc neprodává na eshopech, ale musíš poptávat firmy.

20
co znamená "vsetky prehliadace preferuju https"? Pokud nejsi v preload listu a někdo zadá tvoji doménu do url bez https, tak se nikam nedostane, pokud nemáš http a nemáš přesměrování. Nic jako, že by prohlížeče automaticky dávaly https není, ne bez pluginu bez předchozího navštívení webu a zapamatování si https z HSTS hlavičky.

21
Server / Re:Komunitní serverhousing
« kdy: 13. 03. 2024, 15:33:40 »
proč potřebuje komunitní a nestačí ti komerční serverhousing? Kvůli ceně? Ceny těch nejnižších housingů dnes klesly už na cca 1 - 2 tis/měs. za rack U.

VPS je drahý na jednotku výkonu, tak záleží co provozuješ. Mám takhle housing s servery s asi 200 TB dat, když jsem to měl doma, disky poměrně dost odpadávaly (ano, teplota, vlhkost, prach, vibrace atd.). Mám to pro své projekty, platit si nějaký cloud storage nebo vps by bylo pro mě příliš drahé.

22
Sítě / Re:Interference BT + WiFi
« kdy: 13. 03. 2024, 13:14:04 »
tipuji, že 2 je ten hlavní důvod. Setkávám se s tím v práci poměrně často, online call přes wifi s BT sluchátky kupodivu nefunguje dobře na všech noteboocích, těžko se ale separuje problém s vlastním rušení se zarušeným prostorem obecně.

Přechod na 5GHz je často nejlepší řešení, když ale nemůžeš, tak mám dobré zkušenosti s 802.11n a jeho 40MHz pásmem, to je výrazně odolnější proti rušení, které dělá BT. Jak se s tím popasuje ta interní wifi se sdíleným BT těžko říct.

23
Software / Re:Sdílení desktopu přes webový prohlížeč
« kdy: 11. 03. 2024, 18:42:28 »
používám https://novnc.com/info.html, je to i častá součást různých řešení na webovou consoli.

24
Server / Re:MariaDb - ako zalohovat/obnovovat db?
« kdy: 05. 03. 2024, 10:01:41 »
Nejak si neviem predstavit ze by Maria/Mysql mohli byt vypnute a mat poskodene data tym ze nezbehne fsync alebo nieco podobne. To mi pride ako nejaka extremna situacia.

PGSQL znie lepsie ale je to pre mna neschodne riesenie kedze cely zivot pouzivam mysql a prepisat sql a schemu pre pgsql by bolo casovo narocne(uz som pgsql skusal ale prave tie rozdiely ma vzdy odradili z jej pouzivania, tiez absencia dobreho gui). Ale aspon je dobre vediet ze pgsql ma priamo nejaky nastroj. I ked ono by sa dalo polemizovat ze maria ma prave ten BACKUP STAGE ktory funguje totozne takze pgsql nie je v nicom odlisna tym padom a ide skor len o akysia individualny bias? Plus myisam dnes uz naozaj nikto nepouziva.

A tiez je tu percona a xtradb ako dalsia alternativa pre mysql a innodb a tiez ma xtrabackup. Takze mysql/maria/percona ma stale co povedat si myslim.

docela snadno, stačí třeba v systemd službě mít TimeoutStopSec>0 (či obdobu v dockeru) a vypnutý fast shutdown, pak se nemusí vše řádně stihnout. Mít starší verzi mariadb s O_DSYNC, kde to dělalo občas problémy a fsync se při vypnutí nevolal. Stejně tak mít O_DIRECT a vypnutý innodb_use_native_aio (což kvůli bugům je automaticky na některých kernelech, ikdyž ho v configu zapneš), pak nezapsaná data zůstávají v innodb bufferech. Mariadb ještě docela nedávno neuměla oddělit fsync metadat a dat, takže volala obě najednou, což je drahé a tak se tím šetřilo. Takže pozor na to, je to občas docela alchymie. Teď to celé strč do kombinace s nějakým overlayfs, protože ti přišlo skvělé to spustit v dockeru.

Povinná metadatová databáze "mysql" je v myisam enginu, to k tomu nepoužívání, pokud jí změníš na innodb, což lze, tak občas něco nepěkně selže. Mariadb je neskutečně zákeřná tím, že má řadu archaických částí a kódů. BACKUP STAGE je dobrá funkce, řeší to právě řadu těch problémů, o kterých jsem psal. Nepřitomnost oficiálního nastroje na fyzický backup, strohá oficiální dokumentace je něco, co by ti mělo spustit v hlavě červenou kontrolku, že tady je něco špatně.

Doporučuji dělat backup přes replikaci (galera nebo klidně asynchronní nativní) a metadata, která jsou v mysql databázi si držet bokem či na ně používat mysqldump.

xtrabackup je depracated, stejně jako celé xtradb, to už se dále nevyvíjí. Stejně tak i tokudb a nově se všichni soustředí na   myrocks (ironie: jsem zvědavý co ho za pár let nahradí).

Mysql/Mariadb se dlouhé roky snažili získat jakkoukoliv výhodu, aby byly rychlejší, takže vše je postavené na tenkých základech, používají spoustu hacků, spousty triků za cenu nespolehlivosti a složité obsluze. Postgresql raději jde méně efektivní cestou (z hlediska cpu, ram), ale je zpravovatelnější, jeho chování očekávatatelné a celkově se s ním lépe pracuje. Jako UI je dobré od Jakuba Vrány Adminer. Přechod znamená nějakou práci a učení, ale dlouhodobě se ti asi vyplatí.

Tak dlouho jsem se snažil udržet mysql/mariadb stabilní až mám dnes nejvíce zakázek právě v opravě rozbitých databází.

25
Server / Re:MariaDb - ako zalohovat/obnovovat db?
« kdy: 05. 03. 2024, 09:06:09 »
Ja nehovorim ze nevies o com hovoris, ale myslim ze vychadzas z predpokladu ze DB bezi, inak hovorit o tom ze nieco ostane v ramke a nie je zapisane nedava moc zmysel.
Linux kernel může držet zapsaná data v paměti a mariadb si při ukončení nemusí vynutit jejich fyzické zapsání na disk, při záloze, pokud následuje v rychlém sledu po vypnutí, podle způsobu jak jí provedeš můžeš přečíst původní data a ne ty čerstvě zapsané.

Viz mariadb a nastavení innodb_flush_method nebo třeba man page z linuxu https://man7.org/linux/man-pages/man2/fsync.2.html.

Očividně neznáš řadu tehle funkcionalit (to není špatně, nikdy nezná vše), proto je ale pro tebe bezpečnější se vyhnout kopírování souborů než se to naučíš.

Ale len zo zvedavosti by ma este zaujimalo, ci je situacia odlisna napriklad pri Postgres?

Tam je to jednodušší, jednak má nástroj pg_basebackup, který v umí tohle dělat a zajistí ti všechny potřebné kroky a jednak má jednodušší struktury a snadnější ověření binárních souborů, že jsou v pořádku. Nemá neustále přepisované soubory jako má myisam engine.

26
Server / Re:MariaDb - ako zalohovat/obnovovat db?
« kdy: 05. 03. 2024, 01:07:49 »
Tak riesit integritu suborov tu nema moc vyznam lebo to iste sa tyka zivej db takze ked je niekde nieco posr*** tak je to posr*** vsade a ci ide skopirovanu zalohu alebo zive data je irelevantne.

A na "snapshot" su prave veci ako https://mariadb.com/kb/en/storage-snapshots-and-backup-stage-commands/ ktore prave riesia kopirovanie na urovni suborov.

živej? Z toho, co jsi psal jsem pochopil, že jí vypneš.

Integrita zálohy je obecně důležitý údaj, zajišťuje, že se mi nic neztratí a ani nepřibude. A i u živých databází se dá řešit, viz třeba tvůj příklad s BACKUP STAGE.

Pozor, BACKUP STAGE řeší pouze innodb tabulky, neřeší třeba myisam, což jsou třeba medata o strukturách tabulek, uživatelů, hesel, procedur atd. Tvůj backup skript s tím musí počítat, není to plně transparentní.

Zivej som mal na mysli ze ked vypnem db, a skopirujem subory, tak ak su poskodene skopirovane subory, najskor su poskodene aj zdrojove subory a teda cely disk je v p... a teda nema moc vyznam riesit nejaku integritu kedze mam vecsi problem. Jasne ze spravit nejaku hash kontrolu suborov ma zmysel, nehovorim ze nie, ale prislo mi ze tie argumenty zachadzali trosku do extremu ked niekto tvrdi ze kopirovat celu db do vedlajsieho priecinku ako zalohu je no-go.

o poškozených souborech na disku jsem vůbec nic nepsal. Ty důvody jsem ti tady vypisoval, zápis pro innodb mohl zůstat pouze v paměti a není uložen fyzicky na disku (soubory ib_logfile, ibdata, .frm a případně .ibd se mohou rozcházet), při kopírování tedy obraz nemusí mít konzistentní. Pokud bys ho chtěl mít je nejjistější z běžící databáze zjistit poslední transaction id a poté před kopírování čekat až v ib_logfile bude zapsané, to lze docílit třeba v kombinaci s tím backup stage.

V případě myisam to máš ještě blbější, protože ti databáze o tom moc neumí říct a ty soubory nemají žádný WAL, takže vypnout db, ručně ověřit, že vše je fyzicky zapsané, spustit na nich mysqlcheck/mariadb-check, pak zkopírovat. Myisam raději nepoužívám a interní struktury automatizuji, takže je vždy umím vytvořit znovu.

Ty problémy nejsou hypotetické, ale dost reálné. Ruční opravu databázových souborů z mysql/mariadb jsem dělal už mnokrát, záloha se udělala špatně a při nějakém DR se zjistilo, že databázi nelze spustit. Není to ojedinělý případ.

Stačí se podívat v jakém jsou stavu nástroje. U Mariadb https://mariadb.com/kb/en/how-mariabackup-works/ mají v dokumentaci řadu TODO, není moc rozsáhlá a v repu spousty issues. U mysql si zase za fyzický backup nechávají platit a ve free verzi není.

Pokud se na to musíš ptát, je lepší to nedělat, ten proces není tak přímočarý jako zkopírování souborů a může se vymstít při obnově.


27
Server / Re:MariaDb - ako zalohovat/obnovovat db?
« kdy: 04. 03. 2024, 22:44:32 »
Tak riesit integritu suborov tu nema moc vyznam lebo to iste sa tyka zivej db takze ked je niekde nieco posr*** tak je to posr*** vsade a ci ide skopirovanu zalohu alebo zive data je irelevantne.

A na "snapshot" su prave veci ako https://mariadb.com/kb/en/storage-snapshots-and-backup-stage-commands/ ktore prave riesia kopirovanie na urovni suborov.

živej? Z toho, co jsi psal jsem pochopil, že jí vypneš.

Integrita zálohy je obecně důležitý údaj, zajišťuje, že se mi nic neztratí a ani nepřibude. A i u živých databází se dá řešit, viz třeba tvůj příklad s BACKUP STAGE.

Pozor, BACKUP STAGE řeší pouze innodb tabulky, neřeší třeba myisam, což jsou třeba medata o strukturách tabulek, uživatelů, hesel, procedur atd. Tvůj backup skript s tím musí počítat, není to plně transparentní.


28
nevim co řešíte borci, autentikátor v mobilu imho nepotřebujete. Používejte buď smsky a přepisujte kod anebo si nechejte zavolat a potvrďte křížkem. mě to takhle funguje už leta a se starou tlačítkovou nokií...

To ale zalezi od toho ci autentifikacia je TOTC alebo OTC. Bez smartfonu TOTC asi tazko pojde. Banky&spol maju OTC ale pokrocilejsie webove aplikacie maju TOTC.

Co je TOTC? Naše české banky používají interně HOTP a některé dovolují použít legacy režim s OTC/OTP, ale to nemají všechny.

One-Time Code a Time-based One-Time Code. Niekedy oznacovane T/OTP namiesto T/OTC.
OTP/OTC je jednorazovy kod/heslo, nieco ako nonce, a TOTC/TOTP je to iste ale ma to casovu zlozku takze ten kod je platny len v konkretnom casovom useku, najcastejsie 30 sekundove okno. A teda kazdych 30 sekund sa generuje novy kod.

ani google mi tenhle termín nenašel :), u některých těch bank jsem ten systém 2FA navrhoval.

Odjakživa se používá (T)OTP, v poslední době jsem občas někdy zaslechl OTC, ale že někdo z toho udělá i TOTC? V angličtině má totiž code význam něčeho, co je známo obecně a dopředu, zatímco v češtině se někdy kód používá i ve významu hesla. Řekl bych, že to je nejspíš nesprávně používané v našich končinách. V angličtině to nedává smysl.


29
Server / Re:MariaDb - ako zalohovat/obnovovat db?
« kdy: 03. 03. 2024, 23:19:57 »
Kopírování databázových souborů rozhodně nedoporučuji. Dá se tím napáchat dost škody.

co je take strasne nebezpecne na cp /var/lib/mysql/foo /var/lib/mysql/foo_backup ?

V první řadě bych měl mít shodný filesystem, resp. se shodnou velikostí blocků, což se ti občas nepovede, když to dáváš někam mimo. Bez vypnutého fast shutdown u innodb v kombinaci s velkým množstvím zápisů je pak i obnovení docela sranda (trvá dlouho než se zpracují logy). Snaphosty jsou lepší. Stejně tak ne všech situacích se řádně zavolá fsync a můžeš kopírovat stale data.

A co je na tom obecně špatně? Jakýkoliv backup, kde nemůžeš ověřit integritu dat je špatný backup, no a v tomhle případě nejsi nijak schopný ověřit integritu dat. Sice můžeš si udělat nějakých checksumy těch souborů, ale nevíš, jestli po spuštění bude vypadat samotná databáze shodně, protože nevíš v jakém stavu jsi to zkopíroval a jestli nedošlo k násilnému vypnutí nebo vynechání fsyncu.

Pokud není k dispozici snapshotable filesystem, tak za mě je ještě dobré řešení použít replikaci (pouze u innodb), udělat si slave databázi (ta bude tím backupem), rozpojit replikaci, spustit aplikaci a případně se vrátit ke stavu z slave databáze.

30
nevim co řešíte borci, autentikátor v mobilu imho nepotřebujete. Používejte buď smsky a přepisujte kod anebo si nechejte zavolat a potvrďte křížkem. mě to takhle funguje už leta a se starou tlačítkovou nokií...

To ale zalezi od toho ci autentifikacia je TOTC alebo OTC. Bez smartfonu TOTC asi tazko pojde. Banky&spol maju OTC ale pokrocilejsie webove aplikacie maju TOTC.

Co je TOTC? Naše české banky používají interně HOTP a některé dovolují použít legacy režim s OTC/OTP, ale to nemají všechny.

Stran: 1 [2] 3 4 ... 53