1
Software / Re:Neobvyklý haš u Apache Directory Studio
« Poslední příspěvek od Ħαℓ₸℮ℵ ␏⫢ ⦚ kdy Dnes v 15:12:16 »Sice to asi neodpovídá na zdroj formátu ale lze to : sha512sum -b(inary) a utilita od,xxd
Poslední příspěvky
2
Hardware / Re:Kde koupit 10m HDMI kabel?
« Poslední příspěvek od dj-bobr kdy Dnes v 15:08:01 »Tak se vsaďte, co je v tom aliexpressím RJ45-HDMI "extenderu"...
Ano, je to full pasiv, a stejně to funguje
Ano, je to full pasiv, a stejně to funguje
3
Odkladiště / Re:Zálohování stále se měnících velkých dat
« Poslední příspěvek od RDa kdy Dnes v 15:06:29 »Kdyby někoho zajímal rozsah, v jednom z Corů vidím třeba 2 000 tabulek a celkově obsahují 300 000 sloupců.
A pouziva se to prakticky vse, nebo je to spis dusledek nasazeni nakoupene technologie, ktera byla vytvorena nebo dokonvergovala do univerzalniho reseni, aby zadna zmena schematu v teto casti uz nikdy nebyla potreba (coz rozhodne usnadnuje aktualizace a snizuje moznosti problemu, kdyz jsou vse pouze data a samotna struktura se nemeni).
Nebo je tam i nejaka segmentace dat (sam jsem pouzival ve vykonnem vyhledavaci), to pak pocet klidne narust muze libovolne, a usnadnuje to pak paralelizaci, ono jeden stroj s naivnim schematem databaze bude mit chte nechte sve limity.
4
Hardware / Re:Levný nevýkonný hardware na virtualizaci
« Poslední příspěvek od dj-bobr kdy Dnes v 14:59:55 »Dostal jsem se konečně k tomu se tomuto kousku (HP T640) opět mírně pověnovat, a zde jsou nějaké další detaily okolo spotřeby atd.
Měřil jsem čistý odběr na DC straně - origo zdroj bude mít nějakou non100% účinnost, takže na AC straně (230V) bude odběr o něco vyšší. Nicméně pro hrubou orientaci jsou tyto hodnoty snad dostatečně inspirativní.
HP T640, 48GB RAM (32+16 DDR4), 1TB NVMe SSD (WD Blue), vyjmutá WiFi a RS232 karta
Během memtestu: 8.9W
Během cp /dev/random /dev/null: 14W
Během bootu Proxmoxu: 18W
V idle stavu: 5.2-5.9W
Zkoušel jsem i rozsah napájecího napětí. Zařízení funguje zhruba do 12.9V, pak se bez dalšího varování vypne. Opět zapíná při 13.7V. Horní hranici jsem raději nezkoušel (21V z Parkside akumulátoru je také OK).
Pokud chcete T640 napájet z DC zdroje, pořiďte konektor 4.5x3.0mm s kablíkem se třemi vývody - dvouvývodové nebrat. Černý vodič je mínus, bílý vodič plus, modrý vodič je vnitřní "signálový" pin = identifikace zdroje. Bez identifikace se stroj vůbec nezapne a ani nemá žádné známky života.
Zvyklý na kejkle s identifikací wattáže zdrojů u Thinkpadů (=rezistor proti mínusu) a u Dellů (=opruz s 1-wire EEPROM) jsem trochu zapátral po webu a našel https://www.parkytowers.me.uk/thin/hp/hp_psu.shtml, zkusmo mezi modrý a bílý vodič vřadil rezistor 300k a vše funguje.
Dovedu si případně představit i SMD rezistor velikosti 0805 či 1206 připájet přímo na board nebo na vývody konektoru na straně boardu.
Pro fullsize NVMe SSD do kejsu vleze i 10mm žebrovaný chladič. NVMe SSD se vesměs hodně hřejí (i 80°C není výjimkou, zejména při zápisu) a tak jsem aplikoval AXAGON CLR-M2L10 chladič - dodává se včetně teplovodné žvýkačky a upevňujících gumiček (jednu jsem zničil při přetahování přes hranu žebrování, bacha na to). Kejs jde zaklapnout úplně v pohodě, ale vyšší chladič by už asi nevešel.
Měřil jsem čistý odběr na DC straně - origo zdroj bude mít nějakou non100% účinnost, takže na AC straně (230V) bude odběr o něco vyšší. Nicméně pro hrubou orientaci jsou tyto hodnoty snad dostatečně inspirativní.
HP T640, 48GB RAM (32+16 DDR4), 1TB NVMe SSD (WD Blue), vyjmutá WiFi a RS232 karta
Během memtestu: 8.9W
Během cp /dev/random /dev/null: 14W
Během bootu Proxmoxu: 18W
V idle stavu: 5.2-5.9W
Zkoušel jsem i rozsah napájecího napětí. Zařízení funguje zhruba do 12.9V, pak se bez dalšího varování vypne. Opět zapíná při 13.7V. Horní hranici jsem raději nezkoušel (21V z Parkside akumulátoru je také OK).
Pokud chcete T640 napájet z DC zdroje, pořiďte konektor 4.5x3.0mm s kablíkem se třemi vývody - dvouvývodové nebrat. Černý vodič je mínus, bílý vodič plus, modrý vodič je vnitřní "signálový" pin = identifikace zdroje. Bez identifikace se stroj vůbec nezapne a ani nemá žádné známky života.
Zvyklý na kejkle s identifikací wattáže zdrojů u Thinkpadů (=rezistor proti mínusu) a u Dellů (=opruz s 1-wire EEPROM) jsem trochu zapátral po webu a našel https://www.parkytowers.me.uk/thin/hp/hp_psu.shtml, zkusmo mezi modrý a bílý vodič vřadil rezistor 300k a vše funguje.
Dovedu si případně představit i SMD rezistor velikosti 0805 či 1206 připájet přímo na board nebo na vývody konektoru na straně boardu.
Pro fullsize NVMe SSD do kejsu vleze i 10mm žebrovaný chladič. NVMe SSD se vesměs hodně hřejí (i 80°C není výjimkou, zejména při zápisu) a tak jsem aplikoval AXAGON CLR-M2L10 chladič - dodává se včetně teplovodné žvýkačky a upevňujících gumiček (jednu jsem zničil při přetahování přes hranu žebrování, bacha na to). Kejs jde zaklapnout úplně v pohodě, ale vyšší chladič by už asi nevešel.
5
Software / Re:sha512sum ApacheDirectoryStudio
« Poslední příspěvek od Jan Antos kdy Dnes v 14:22:46 »jeste dodam, pokud by nekdo potreboval to generovat v teto forme tak to lze snadno poslat do sedu
cat file | sha256sum | sed -r 's/(.{8})/\1 /g'
cat file | sha256sum | sed -r 's/(.{8})/\1 /g'
6
Hardware / Re:Kde koupit 10m HDMI kabel?
« Poslední příspěvek od Ivo2003 kdy Dnes v 14:20:52 »A že by jenom striktnější standard pomohl stejný signál táhnout 6x dál (10m vs. 60m)? Chápu, že tam asi budou nějaké linkové zesilovače, ale to by v HDMI mělo být taky, ne?
HDMI bylo navrženo pro propojení spotřební elektroniky na krátkou vzdálenost, tomu odpovídá stínění kabelů a výstupní signály a jeho intenzita.
U DVI bylo problém při spojení 5 a 3 metrového DVI kabelu. (pravděpodobně za to mohla i DVI spojka mezi kabely a kabel v celku o délce 10 metrů by fungoval)
Ethernet byl navržen pro vzdálenosti až 100 metrů a tomu odpovídá konstrukce kabelů a parametry vysílaného signálu.
Existuje i HDMI optický kabel, který metalický kabel nahradí optickým, ten může mít i více než 10 metrů a pravděpodobně může být i méně tlustý.
7
Odkladiště / Re:Zálohování stále se měnících velkých dat
« Poslední příspěvek od Exceptions kdy Dnes v 14:19:16 »Jde-li konkrétně o banky.
Ono to řešení není tak složité, složité je jen v detailech. Ukázkový příklad, Oracle DB nad replikovaným diskovým polem, replikovaný transakční log, na vstupu se každý požadavek ukládá do auditního logu. Transakce se nejprve uloží do interní fronty a poté se provedou změny v modelu. Vše se striktně spouští v db transakci.
To co tzv. Core (či Core banking system, CBS). Je to databáze a k tomu rozhraní, které se stará o transakce, klienty, účty, účetnictví, číselníky atd. Na Core databázi se zpravidla nikdo z venku (ani aplikace) nepřipojuje, vše se replikuje přes transakční log, který se čte. Core bývá fyzicky, síťově a administračně oddělen od zbytku infrastruktury.
České banky mají Core velký zpravidla několik TB velký, RTO se pohybuje v hodinách. Při obnově se zahodí datová složka, vezme se poslední snapshot/checkpoint a od něho se aplikují jednotlivé transakce z logu (jedna po druhé). To už psali předřečníci.
Naše banky mají zpravidla dvě aktivní lokality, kam se data rovnou replikují. Transakční a auditní logy z core putují na pásky se zpožděním pár desítek minut.
Vedle toho pak nezávislé stojí jiné databáze a datové sklady, které data dále zpracovávají, posílají, zobrazují klientům v bankovnictví, dělají reporty a výstupy do ČNB atd. Aplikací a systémů nad Corem pak může být i několik stovek a to jsou pak systémy, s kterými se potkávají běžní lidé a zaměstnanci. Často ale neobsahují primární data a mohu je obnovit z Core systému. Tam se data zálohují už daleko jednodušejí, snaphosty virtuálů, dumpy dat a vesměs to je věcí týmu, kterému to patří, aby udělal backup and restore implementaci. Obnova se čvičí několikrát ročně a některé banky to mají již plně zautomatizované.
Technicky se ale nedá zabránit všem druhům útoků, důležitou roli hraje dohledový tým a automatizace, která izoluje v případě problémů celé systémy, dohledové centrum funguje nonstop. Díky vysokému tlaku ČNB, jsou naše banky v tomhle hodně progresivní. To už se ale nedá říct o těch systémech nad tím, s kterými se větčina vývojářů a uživatelů setkává.
Kdyby někoho zajímal rozsah, v jednom z Corů vidím třeba 2 000 tabulek a celkově obsahují 300 000 sloupců. K transakcím se ukládají i atributy a metadata, tj. z jakých terminálů transakce vznikla, různé identifikace a seriová čísla, IP adresy, časové známky, podpisy atd. atd.
Ono to řešení není tak složité, složité je jen v detailech. Ukázkový příklad, Oracle DB nad replikovaným diskovým polem, replikovaný transakční log, na vstupu se každý požadavek ukládá do auditního logu. Transakce se nejprve uloží do interní fronty a poté se provedou změny v modelu. Vše se striktně spouští v db transakci.
To co tzv. Core (či Core banking system, CBS). Je to databáze a k tomu rozhraní, které se stará o transakce, klienty, účty, účetnictví, číselníky atd. Na Core databázi se zpravidla nikdo z venku (ani aplikace) nepřipojuje, vše se replikuje přes transakční log, který se čte. Core bývá fyzicky, síťově a administračně oddělen od zbytku infrastruktury.
České banky mají Core velký zpravidla několik TB velký, RTO se pohybuje v hodinách. Při obnově se zahodí datová složka, vezme se poslední snapshot/checkpoint a od něho se aplikují jednotlivé transakce z logu (jedna po druhé). To už psali předřečníci.
Naše banky mají zpravidla dvě aktivní lokality, kam se data rovnou replikují. Transakční a auditní logy z core putují na pásky se zpožděním pár desítek minut.
Vedle toho pak nezávislé stojí jiné databáze a datové sklady, které data dále zpracovávají, posílají, zobrazují klientům v bankovnictví, dělají reporty a výstupy do ČNB atd. Aplikací a systémů nad Corem pak může být i několik stovek a to jsou pak systémy, s kterými se potkávají běžní lidé a zaměstnanci. Často ale neobsahují primární data a mohu je obnovit z Core systému. Tam se data zálohují už daleko jednodušejí, snaphosty virtuálů, dumpy dat a vesměs to je věcí týmu, kterému to patří, aby udělal backup and restore implementaci. Obnova se čvičí několikrát ročně a některé banky to mají již plně zautomatizované.
Technicky se ale nedá zabránit všem druhům útoků, důležitou roli hraje dohledový tým a automatizace, která izoluje v případě problémů celé systémy, dohledové centrum funguje nonstop. Díky vysokému tlaku ČNB, jsou naše banky v tomhle hodně progresivní. To už se ale nedá říct o těch systémech nad tím, s kterými se větčina vývojářů a uživatelů setkává.
Kdyby někoho zajímal rozsah, v jednom z Corů vidím třeba 2 000 tabulek a celkově obsahují 300 000 sloupců. K transakcím se ukládají i atributy a metadata, tj. z jakých terminálů transakce vznikla, různé identifikace a seriová čísla, IP adresy, časové známky, podpisy atd. atd.
8
Software / Re:sha512sum ApacheDirectoryStudio
« Poslední příspěvek od Jan Antos kdy Dnes v 14:05:30 »Tak s timto jsem se take nedavno potkal pri PAM certifikaci, tenhle format generuje a pouziva napriklad Verify+ od Kobetron, ale ten zvaliduje i standardni format bez mezer.
9
Studium a uplatnění / Re:Kde ako ajťák žiť?
« Poslední příspěvek od Jimmyx kdy Dnes v 13:55:22 »Máme 36 let po revoluci. Většina původních stavitelů už je mrtvá (a ti to stavěli většinou svépomocí), ale současní majitelé, důchodci jsou většinou potomci původních stavitelů.No akorátže ty chaty a zahrádky současní důchodci víceméně většinou zdědili po svejch rodičích co to pořídili za tuhého socializmu.
misto poridili bych napsal svepomoci postavili
10
Software / Neobvyklý haš u Apache Directory Studio
« Poslední příspěvek od drnest kdy Dnes v 13:46:03 »Ahoj, stáhl jsem si ApacheDirectoryStudio-2.0.0.v20210717-M17-linux.gtk.x86_64.tar.gz a k němu ApacheDirectoryStudio-2.0.0.v20210717-M17-linux.gtk.x86_64.tar.gz.sha512.
Jenže ten sum soubor má nějaký divný formát:
Na svých stránkách mají i "návod", že se to v linuxu má zkontrolovat příkazem sha512sum. Ono to naštestí spočítá stejnou sumu, ale linuxový a standardní formát je takovýto:
A samozřejmě, že sha512sum --check o tom prohlásí, že je to špatně.
Mě by jen zajímalo, čístě ze zvědavosti, čím tohle u Apache vyrobili !?!
Jenže ten sum soubor má nějaký divný formát:
Kód: [Vybrat]
./ApacheDirectoryStudio-2.0.0.v20210717-M17-linux.gtk.x86_64.tar.gz:
771A5C2D 6B9F6F04 87CEB435 EE765863 EB51A66F 9FF4506F D5BBA574 5CFF4C41 B7557A79
16DABE85 BAE8204E 79746A1B B95D75C1 AEACC474 193CAFC6 401A8EDBNa svých stránkách mají i "návod", že se to v linuxu má zkontrolovat příkazem sha512sum. Ono to naštestí spočítá stejnou sumu, ale linuxový a standardní formát je takovýto:
Kód: [Vybrat]
771a5c2d6b9f6f0487ceb435ee765863eb51a66f9ff4506fd5bba5745cff4c41b7557a7916dabe85bae8204e79746a1bb95d75c1aeacc474193cafc6401a8edb ApacheDirectoryStudio-2.0.0.v20210717-M17-linux.gtk.x86_64.tar.gzA samozřejmě, že sha512sum --check o tom prohlásí, že je to špatně.
Mě by jen zajímalo, čístě ze zvědavosti, čím tohle u Apache vyrobili !?!
