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 - Pavel Dufek

Stran: [1]
1
Zdravím, vím, že na stahování tiles based obrázků z českých archivů (směrem ke genealogii, historii) používají nástroj Dezoomify, což je jednak asi webappka - https://dezoomify.ophir.dev/ a za druhé a hlavně - opensource appka v Rustu - https://github.com/lovasoa/dezoomify-rs. A tu pak krmí YAML soubory, zřejmě odkoukanými z těch webů ... to už nevím, já jsem jen občasný rekompilovač toho Rustu na méně typickou platformu, na kterou to nereleasuje originální autor ... ale třeba Vás to nasměruje.

2
Zdravím, myslím si, že nejjednodušší bude opravdu správcovská editace v Active Directory DNS, obzvlášť pro Linuxový staticky adresovaný a předpokládám staticky pojmenovaný stroj. Protože ty "při instalaci vzniklé záznamy" nejspíš vznikly pomocí mechanismu zabezpečené aktualizace dns, což si jednak může vyžádat MS dhcp server při zapůjčení adresy a při její aktualizaci a dále o to žádá členská stanice v doméně (a nevím, jestli pro tohle žádání vůbec existuje nějaký linuxový klient, AD stanice provozuju pouze windowsové). Takže ve staticky adresovaném linuxu bez nějakého MS AD členství nejspíš nebude žádný standardní způsob pro bezpečné ohlášení takové změny ...

3
Distribuce / Re:Po instalaci Kali na SSD ho nepozná BIOS
« kdy: 01. 11. 2022, 13:17:39 »
Každý jsme nějak začínali ... myslím si, že tím ilustračním/zkratkovým mv příkazem chtěl pisatel říct, že je potřeba na tom externím disku s Kali přesunout (možná by bylo pro začátek lepší a já tedy radím zkopírovat, tím se prostě potřebná cesta vyrobí taky) ten soubor grubx64.efi (a třeba vše, co je v adresáři s ním) do adresáře /EFI/boot (nebo x:\EFI\boot, pokud se to bude dělat ve Windows) a případně ho po překopírování přejmenovat na bootx64.efi ... a vyzkoušet, jestli takto upravený disk už UEFI bios k bootu nabídne ... (jde opravdu jen o kopírování běžným souborovým managerem, protože UEFI nepotřebuje v tomto případě žádné speciálně nahrané boot sektory apod.). Pokud ne, tak bude muset poradit někdo ve věci UEFI nebo spíš specificky distribuce Kali znalejší, pokročilé formátování disků a boot více OS v PC opravdu není úplně začátečnická věc ... ale pokud uefi bios rozpozná nějak vyrobenou Kali boot flash, měl by rozpoznat i Kali boot SSD, pokud bylo vyrobeno jako Kali bootovací - aby to nebylo jen jako datový disk pro ukládání persistentních dat pro tu live distribuci Kali, ale bootující stále z té flash ??? Je totiž otázka, z čeho vlastně bylo to Kali bootováno, jestli ne stále z té flash s tím, že na SSD byla jen provozem generovaná data ...

4
Bazar / Re:Koupím externí sériový modem (dialup)
« kdy: 15. 09. 2022, 09:57:16 »
Protože čtu a cítím, že Trident v době modemové aktivně působil a protože jsem se k té pevné lince vyjadřoval - pro ty analogové modemy proti sobě jsem myslel zřejmě tu "suchou linku" (ten pojem teda slyším poprvé, doufám, že ho chápu správně), prostě telco operátorem nenapájený čistě na svorkovnicích a kabelově propojovacích místech postavený pár drátů mezi místem A a B. To jsem jako zákazník (byl jsem sítař pro firmy, ne telekomák/spojař) použil několikrát, jelo to samozřejmě maximálně těch 33.6 (to je tuším to V34), protože jak už bylo uvedeno, vyšší rychlosti na analogu byly jen download a analogová byla jen jedna strana (klient s tím V90 modemem), druhá strana musela být digitální dsp modem/karta ve volaném dialup serveru připojeném pomocí isdn (většinou isdn pri = 2 mbps, 30 hovorů + signalizace) a i ten analogový volající musel mít linku do digitální karty v digitální telco ústředně, prostě jediné analogové byla poslední míle k zákazníkovi. Na těch pronajatých analogových okruzích bylo podle mne oficiálně garantované to hlasové pásmo o šířce zhruba 3 kHz, ale pásmové filtry nejspíš nebyly osazovány všude, protože minimálně na jedné takové lince jsem zkoušel i různé jiné modemy pro obecný 2-drát (Planet p-t-p shdsl, vdsl od stejného výrobce, případně ruský SBNI Granch modem) a jely i o dost rychleji než V34, určitě i mimo hlasové pásmo, i když teda spíš ve stovkách kbps nebo okolo megabitu, víc to vdsl sice umělo, ale nejelo, ono už je to dost dlouho :)
Jinak jako kuriozita pamětníka - docela vepřovina byla v době dialupu digitální rozčtverka - digitální Telecom adaptér v baráku, proti tomu nějaká speciální karta v ústředně, z té rozčtverky 4 nové domovní analogové přípojky, na hlas a trochu fax ok, vlastní číslo, ale díky té digitální konverzi to z modemového signálu přeneslo tak 9600 bps místo těch 33.6 ... používali to z počátku, když měli málo linek ...
Digitální modemy pro vyšší rychlosti bylo něco jiného - tam stranu operátora neznám (asi i možností bylo víc), napájené to určitě bylo, zřejmě to bylo nějaké PCM i s možností nějakých opakovačů/zesilovačů, na straně zákazníka byl maximem linky zřejmě 2 mbps (v ČR, co jsem viděl), jejich modemu říkali Orkit (mělo to nějaké takové označení, tuším izraelský výrobek), jelo to na 2-4 drátech operátora a lezl z toho synchronní seriák V21 nebo V35 do routeru nebo to isdn pri/30 do ústředny - nebo třeba do toho dialup serveru ...
Starší digitální modemy jsem slyšel nazývat baseband, to jsem viděl jako brigádník/študent někde okolo roku 1996, to byl Nokia baseband modem tuším 64 nebo pak 128 kbps obousměrně, připojený na 2 drát do vyhrazené telefonní zásuvky na zdi a z toho opět V35 nebo X21 sync seriák do malého Cisco nebo do BSDI Unixu a Riscom N2 karty ... no nějak jsem se rozvzpomínal, jdu raději něco dělat ...

5
Bazar / Re:Koupím externí sériový modem (dialup)
« kdy: 12. 09. 2022, 14:03:35 »
Zdravím,
ne všechny analogové telefonní modemy ten režim pronajaté linky uměly. Ty, které ho uměly, opravdu dokázaly fungovat na (asi nízké) jednotky km telefonního drátu po páru vodičů, O2/tehdy možná ještě SPT Telecom/ mělo dokonce službu pronájmu analogového okruhu mezi 2-ma místy v jejich kabeláži, používali jsme to v 90-letech před nástupem wifi na propojení centrály na okraji a prodejny v centru okresního města. Používali to i provideři pro pevné připojení rychlostma do těch 33.6 kbps, což zvládly běžné modemy a Novell či Linux servery s běžným sériovým portem. Vyšší rychlosti už byly digitální synchronní okruhy až do 2 mbps, ale to byly jiné modemy a hlavně jiné (drahé) sériové karty či routery ...
Jinak každý analogový modem dokázal fungovat na té telefonní lince (nějaké klidové napětí, impedance; samozřejmě volitelně vyzvánění a detekce oznamovacího a obsazovacího tónu) - viděl jsem před lety i nějaká schémata jednoduché emulace ústředny v tomto impedančně-fyzickém minimalistickém smyslu právě pro možnost propojení faxmodemu a modemu nebo dvou modemů bez skutečné pobočkové ústředny nebo 2 pevných "státních" linek. Kupodivu nějaká ta schemata dávno uložená do mht souborů jsou ještě online - např. http://www.ebastlirna.cz/modules.php?name=News&file=article&sid=20 nebo https://www.epanorama.net/documents/telecom/fax_to_modem.html ...

6
Distribuce / Re:Nefunkční HTTPS mirror od CZ.NIC
« kdy: 29. 06. 2022, 13:43:21 »
Zdravím, jen takový nápad - pokud by v použitých certifikátech bylo LetsEncrypt, mohl by u staršího systému (v roli klienta) být problém s "dvojakostí" podpisu kořene LetsEncrypt a správném rozpoznání důvěry. Stručně - mohlo by pomoci na tvém Ubuntu poeditovat soubor /etc/ca-certificates.conf - najít řádek s /DST_Root_CA_X3.crt a zaremovat ho na tvar !mozilla/DST_Root_CA_X3.crt a pak dát update-ca-certificates, to vše samozřejmě jako root či přes sudo. A pak zkusit znovu apt-get update atd.

7
Server / Re:WoL- jak ne/funguje
« kdy: 20. 06. 2022, 08:19:43 »
Neznám Váš router, ale co jsem viděl Wake On Lan ve webgui/cli routeru, byl to prostě ten magic packet sender s parametrem cílovou mac adresou k probuzení, případně doplněný o nějaký sken sítě/možnost výběru zařízení ze seznamu zařízení routeru známých (co já vím, z dhcp, z arp z aktivní resp. nedávné komunikace). Takže to podle mne nemůže dělat nic jiného než posílat to samé, co posílá wakeonlan cli linux utilita ...

8
Zdravím, jestliže už víte, že ta krabička, kterou chcete spravovat, má ip 192.168.1.x, tak si prostě na svém (k ní ethermetem připojeném) notebooku/pc dejte adresu prostě ručne 192.168.1.x+1 s maskou 255.255.255.0 bez výchozí brány a dns a prostě zkuste web 192.168.1.x otevřít. Ničemu obecně nevadí, pokud v jedné L2 síti (1 sít switchů, wifi ap, žádne "složitosti" typu vlan rozdělení) budete provozovat 2 a více různých ip adresací. Je to sice méně obvyklé (spíše dočasně-laboratorní), v IP adresách se vidí vždy jen stroje z jedné ip podsítě A MUŽETE MÍT JEN JEDNO DHCP, ale fungovat to při statickém nastavení té podružné sítě bude a UPC router vám vadit nebude. Ty dns TP-Link apod. triky (co jsem kdysi viděl) nejsou většinou plný hijacking provozu, jen podstrčení privátního ip jako odpovědi ... tj. když odpověď víte, můžete jít rovnou na teb web. Spíš bych si dal pozor na to, abych jasně viděl, ve kterém TP-Link zařízení jsem resp. aby tu adresu 192.168.1.x (na obou stejné x) neměla obě TP Powerline zařízení, pak byste prostě musel zařídit spojení svého ntb jen s jedním z nich (tedy odpojit to cyky propojení nebo druhou stranu fakt vypnout) a tu ip statickou dočasnou konfiguraci.

9
Sítě / Re:DHCP server na OpenWRT
« kdy: 24. 03. 2022, 11:11:02 »
Zdravím, opravdu to vypadá na výskyt ještě nějakého jiného dhcp nebo nějaký reset konfigurace toho Openwrt na výchozí - ale jak se to dostane zpět ... no v každém případě já bych zkusil ověřit, jakou mac adresu má dhcp server resp. výchozí brána v obou variantách. Tj. v okamžiku správné adresy zapinkat pingem 192.168.0.1 a zjistit na pc/ntb prostě z arp -a mac adresu a totéž pro 192.168.1.1 v okamžiku poruchy. Pokud to bude jiná mac, tak prostě hledat; pokud stejná, tak TPLink zkusit vyměnit nebo prostě zkusit na té "vadné" bráně otevřít web a vidět ... třeba i z login page bude jasnější, jaké zařízení to tam posílá ... na provedení postupu někoho na místě zacvičit, pokud není možno být přímo u toho.

10
Server / Re:SMTP 550-5.7.1
« kdy: 12. 01. 2022, 09:25:32 »
Podle mých zkušeností tato Google chyba znamená, že se mu "nelíbí" ip, ze kterého bylo na jejich smtp port (zřejmě klasický server smtp port 25) přistupováno. Dle nějakého detail info/helpu před časem tam psali, že jejich smtp servery nepřijímají poštu od ip, jejichž reverzní dns vede na consumer style ip rozsahy nebo spíš názvy ala 78.56.34.12.provi.der. Doporučovali řešení buď si pořídit klasickou forward confirmed reverzi, tj. jsem server.vietnamka.doma, tak si u ISP zařídím odpovídající reverzi, ev. včetně povolení toho ip v SPF domény vietnamka.doma. Řešil jsem to před časem, pomohlo to, ale ne hned po nastavení, nějakou dobu jsem to řešil posíláním té pošty (relayováním) přes mnou spravovaný server jinde, který měl od začátku název a reverze a byl v ip bloku telehouse. Pokud by Googlu vadilo, že ip je v nějakém často problematickém consumer grade subnetu, tak jedině projet běžné blacklisty (multirbl.valli.org třeba) a ev. delistovat ... imho to nemá zkrátka okamžité řešení kromě relay jinudy ...

11
Server / Re:FreeRadius + Let's Encrypt
« kdy: 18. 11. 2021, 16:56:48 »
No neznám ten Freeradius tak dokonale, mohlo by záležet na verzi openssl toho operačního systému (openssl version, pokud je menší než 1.0.2, tak je to algoritmický problém s nutností mít celý odkazovaný chain verifikovatelný, pokud nějak přes api/custom verzi toho openssl nevynutíte v novějších preferovaný režim vyhodnocování trusted_first, tedy že stačí jakákoliv dohledaná důvěra ke kořeni, ne každá). Alternativa by mohla být zkusit si požádat o ten LE cert v režimu preferred root ISRG viz. můj předchozí post a nebo možná zkusit to cvičně "oprasit" tak, že prolezete ten fullchain.pem, zkouknete jednotlivé sekce skrz "openssl x509 -text" a pokud naleznete sekci s Common name ...ISRG... issued by ... DST X3..., tak ji prostě textově vyhodíte a restartujete ty služby. A prostě ve fullchainu budete mít jen vaše signed by R3 a R3 signed by ISRG ... nebo byste si ten cert R3 signed by ISRG musel najít na netu (to bude možné) a prostě si cvičně vyrobit fullchain ve tvaru vaše ostré signed by R3 a k tomu nahradit zbytek tím R3 by ISRG ... tím defakto ručně uděláte asi totéž jako ta nová žádost s preferred root, pokud teda problém opravdu je ta existence zmínky o DST X3 v tom fullchainu ...

12
Server / Re:FreeRadius + Let's Encrypt
« kdy: 18. 11. 2021, 14:39:31 »
Nevím, jestli je to ještě aktuální, ale pokud je pro komponenty toho Freeradius "řetězce" problém s tím cross signed R3, tak to je vlastně "jen" problém LE-čkem dodaného chainu při registraci. Samotný certifikát je podepsaný tím R3 a většina nových klientů by mohla rozumět už jen tomu ... takže buď zkuste v tom Radiusu používat z LE /etc/letsencrypt/live/neco jen privkey a cert (ne chain, fullchain) nebo zkuste konfigurací svého LE renew clienta požádat LE-čko o cert s chainem bez toho cross signu (pokud ten cross sign nepotřebujete pro ty věci jako old Android) - o ten ISRG only chain by mělo jít požádat při registraci/renew parametrem --preferred-chain "ISRG Root X1" nebo snad i vložením preferred_chain = ISRG do odpovídajícího /etc/letsencrypt/renewal/neco.conf ...

13
Server / Re:FreeRadius + Let's Encrypt
« kdy: 16. 11. 2021, 09:08:10 »
Dobrý den, jen takový nápad - na čem Vám běží ten Freeradius - podle té chybovky není tam problém buď s obnovou toho LE certu (že by byl opravdu "prošlý") nebo není tam problém s tím, že v ca-certificates daného OS je kromě nového ISRG rootu i ten starý expirovaný DST X3 a Freeradius nějak nedává tu R3 - ISRG - expired DST X3 kombinaci ? Na fórech se to v době té expirace na konci září 2021 řešilo, většinou by na vyřazení toho starého root certu ze systému měl stačit full update, případně (na Debian based Linuxu) v souboru /etc/ca-certificates.conf zakomentovat pomocí ! řádek s textem DST_Root_CA_X3.crt a provést příkaz update-ca-certificates (nebo prostě pro daný OS vyhodit ten DST Root CA X3 z úložiště důvěryhodných kořenových CA), ev. pak restartovat ten radius daemon ...

Stran: [1]