331
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.
332
Sítě / Re:Pomoc s Mikrotikem - RouterBOARD 751G
« kdy: 30. 03. 2020, 10:09:52 »
Pokud vynechám, že by byla wifi část kaput (to by asi nešlo ani skenování), tak nejčastější zrada je, že máte povoleno použití šířky 20/40 Mhz kanálu, napevno krajní kanál (1. nebo 13.) a k tomu chybnou kombinaci doplňkového kanálu (pod/nad řídícím kanálem).
Pokud je zvolen 1. kanál a k tomu channel-width=20/40mhz-eC, tak rádio mlčí, protože by muselo vysílat pod povoleným rozsahem. Obdobně platí pro poslední kanál s channel-width=20/40mhz-Ce.
Takže prvotně zvolit frekvenci někam doprostřed nebo auto a uvidí se. :-)
Jiná věc je, že některé verze toho ROSu nezvládají korektně volbu kanálu na auto, takže zkusit ručně kanál zadat (nebo přes channels list založit seznam kanálů, z kterých má volba auto probíhat, pak funkce ožila - pokud není v okolí takový bordel, že se neustále jen přepíná kanál a vysílání fakticky nekoná).
Pokud je zvolen 1. kanál a k tomu channel-width=20/40mhz-eC, tak rádio mlčí, protože by muselo vysílat pod povoleným rozsahem. Obdobně platí pro poslední kanál s channel-width=20/40mhz-Ce.
Takže prvotně zvolit frekvenci někam doprostřed nebo auto a uvidí se. :-)
Jiná věc je, že některé verze toho ROSu nezvládají korektně volbu kanálu na auto, takže zkusit ručně kanál zadat (nebo přes channels list založit seznam kanálů, z kterých má volba auto probíhat, pak funkce ožila - pokud není v okolí takový bordel, že se neustále jen přepíná kanál a vysílání fakticky nekoná).
333
Sítě / Re:Bezpečnostní úskalí RDP
« kdy: 27. 03. 2020, 11:52:08 »Ne. RDP to vůbec neřeší.Dík, jasně, NAP je asi ta zkratka. :-)
Funkce NAP je deprecated od 2012R2, od 2016 removed.
Předpokládám, že na novějším se očekává použití Always On VPN (či jak se to jmenuje) a klientské PC je tak "trvale" součástí firmení LAN a trvalého dohledu. Ale tady něco takového bude na dlouho, když vidím ten zástup serverů, kde jsou stále i Windows NT4.0 servery v provozním portfoliu. :-)
334
Sítě / Re:Bezpečnostní úskalí RDP
« kdy: 25. 03. 2020, 14:34:25 »
Těch možností řešení je mnoho, my používáme NoMachine ( https://www.nomachine.com/terminal-server ), protože jsme primárně řešili vzdálený přístup k linuxům na X-Win plochy (a to tám máme šílence, co vzdáleně motají OpenGL modely celé elektrárny v nějakém CAD/CAM/CFD a jsou spokojeni). Že sekundárně to umí být i brána k RDP, VNC je příjemné plus. :-)
Jinde se používá Cytrix virtuální desktopy, často s integrovaným CiscoVPN a napojením na další infrastrukturu (zrovna se ale jedno takové řešní jednomu velkému korporátu v Česku složilo, inu pár tisíc uživatelů online udělá své).
Souhlasím, že na cizí počítač max nějaký remote desktop s rozumnou konfigurovatleností, co člověk ne/může. VPNko na to, co nemám pod kontrolou není ideál. Samozřejmě pak mix VPN do DMZ a tam nějaká bráno k desktopu je plus navíc, ale v nouzové situaci nemusí být čas to oživovat (třeba včetně jednorázových/SMS hesel a podobných blbostí).
Ale sešli se tu evidentně znalci RDP: Otázka - umí v rámci připojení udělat už RDP klient ve woknech nějaký backgroud check a report serveru stavu klienta a na základě stavu server dovolí ne/připojit? Jak to umí nativní VPN klient ve Win10 (a asi i stsrších), když si to VPN server vyžádá? Zkrátka krom ověření klienta to pošle background check, co je nainstalováno, patche, běžící procesy, antivir, ..., takže když něco není dle představ serveru, tak odmítne spojení. Sice z toho zpět nedojde obvkyle inteligentní hláška, ale člověk už ví, že má pustit update OS/apliací, pustit plný scan systému a v dalším pokusu se už připojí. Nekonfiguroval jsem, jen jsem obětí takového řešení a má to něco do sebe (pokud ten update zrovna nerozjebe něco potřebného k životu :-) ).
Jinde se používá Cytrix virtuální desktopy, často s integrovaným CiscoVPN a napojením na další infrastrukturu (zrovna se ale jedno takové řešní jednomu velkému korporátu v Česku složilo, inu pár tisíc uživatelů online udělá své).
Souhlasím, že na cizí počítač max nějaký remote desktop s rozumnou konfigurovatleností, co člověk ne/může. VPNko na to, co nemám pod kontrolou není ideál. Samozřejmě pak mix VPN do DMZ a tam nějaká bráno k desktopu je plus navíc, ale v nouzové situaci nemusí být čas to oživovat (třeba včetně jednorázových/SMS hesel a podobných blbostí).
Ale sešli se tu evidentně znalci RDP: Otázka - umí v rámci připojení udělat už RDP klient ve woknech nějaký backgroud check a report serveru stavu klienta a na základě stavu server dovolí ne/připojit? Jak to umí nativní VPN klient ve Win10 (a asi i stsrších), když si to VPN server vyžádá? Zkrátka krom ověření klienta to pošle background check, co je nainstalováno, patche, běžící procesy, antivir, ..., takže když něco není dle představ serveru, tak odmítne spojení. Sice z toho zpět nedojde obvkyle inteligentní hláška, ale člověk už ví, že má pustit update OS/apliací, pustit plný scan systému a v dalším pokusu se už připojí. Nekonfiguroval jsem, jen jsem obětí takového řešení a má to něco do sebe (pokud ten update zrovna nerozjebe něco potřebného k životu :-) ).
335
Vývoj / Re:PostgreSQL a primární klíč s funkcí?
« kdy: 30. 01. 2020, 22:06:50 »
Uff, to je nakládačka. :-)
MŠ: rozdíl mezi "primary key" a "index unique" je v tom, že pokud máš nenulový počet uživatelů, co mají nutkavou potřebu do tabulek lézt nějakým tim table view čumítkem a tyto klikátka chtějí zkrátka primární klíč na tabulce. Bez něj buď odmítnou zobrazit nebo se podivně pošahají, když v tabulce je 500M+ řádků. To je jediný důvod, proč byla snaha přidat primární klíč. Aplikačně to celé rychle žije z indexu, který si vyrábí na pozadí ta omezující podmínka na nevkládání překrývajících se dat.
Nu, stejná skupina má občas snahu psát dotazy, kde do where nacpou něco jako "lower(casr) between T1 and T2", tak jsem chtěl zabít dvě mouchy jedním klíčem, že by jim to trochu zrychlilo, když nejsou schopni pochopit range operaci typu casr && (T1, T2]. :-)
Ono při větším počtu řádků už ty indexy začínají i něco žrát času i místa na disku, tak jsem nechtěl kvůli tomu čumítku přidat tupě jen bigserial nebo něco takového.
Samozřejmě to jde řešit, že místo casr:tstzrange použít na to 3 samostatné sloupce (casl:timestamp, casu:timestamp, casb:char(2)) a vyrobit si nad tím primary index pomocí (smid, casl, casb) a kontrola nepřekrývání pomocí "exclude using gist (smid with =, tstzrange(casl, casu, casb) with &&)" funguje, akorát pak některé operace to nechtělo brát dle toho indexu na pozadí. Dotaz typu "select * from tab where tstzrange(casl, casu, casb) && '[ T1, T2]'" nechtěl použít index toho exclude, což při použití normálního range sloupce fungovalo. A historicky je to děláno vše na range, tak jsem nechtěl do toho tak hluboce rejpat.
MŠ: rozdíl mezi "primary key" a "index unique" je v tom, že pokud máš nenulový počet uživatelů, co mají nutkavou potřebu do tabulek lézt nějakým tim table view čumítkem a tyto klikátka chtějí zkrátka primární klíč na tabulce. Bez něj buď odmítnou zobrazit nebo se podivně pošahají, když v tabulce je 500M+ řádků. To je jediný důvod, proč byla snaha přidat primární klíč. Aplikačně to celé rychle žije z indexu, který si vyrábí na pozadí ta omezující podmínka na nevkládání překrývajících se dat.
Nu, stejná skupina má občas snahu psát dotazy, kde do where nacpou něco jako "lower(casr) between T1 and T2", tak jsem chtěl zabít dvě mouchy jedním klíčem, že by jim to trochu zrychlilo, když nejsou schopni pochopit range operaci typu casr && (T1, T2]. :-)
Ono při větším počtu řádků už ty indexy začínají i něco žrát času i místa na disku, tak jsem nechtěl kvůli tomu čumítku přidat tupě jen bigserial nebo něco takového.
Samozřejmě to jde řešit, že místo casr:tstzrange použít na to 3 samostatné sloupce (casl:timestamp, casu:timestamp, casb:char(2)) a vyrobit si nad tím primary index pomocí (smid, casl, casb) a kontrola nepřekrývání pomocí "exclude using gist (smid with =, tstzrange(casl, casu, casb) with &&)" funguje, akorát pak některé operace to nechtělo brát dle toho indexu na pozadí. Dotaz typu "select * from tab where tstzrange(casl, casu, casb) && '[ T1, T2]'" nechtěl použít index toho exclude, což při použití normálního range sloupce fungovalo. A historicky je to děláno vše na range, tak jsem nechtěl do toho tak hluboce rejpat.
336
Sítě / Re:MikroTik načítá IP přes DHCP, i když je veškerá komunikace zahazovaná
« kdy: 30. 01. 2020, 18:32:33 »
/interface bridge filter
add action=drop chain=input dst-port=67-68 in-interface=ether1 ip-protocol=udp mac-protocol=ip
add action=drop chain=input dst-port=67-68 in-interface=ether1 ip-protocol=udp mac-protocol=ip
337
Sítě / Re:MikroTik načítá IP přes DHCP, i když je veškerá komunikace zahazovaná
« kdy: 30. 01. 2020, 15:06:16 »
DHCP klient (stejně i server, VRRP a pár dalších) pracuje přímo s raw L2 socketem, takže ho neovlivní L3 firewall.
Jde blokovat pomocí L2 firewallu v /interface bridge filter nebo (pokud to není historický ROS) asi i v /ip firewall raw.
Jde blokovat pomocí L2 firewallu v /interface bridge filter nebo (pokud to není historický ROS) asi i v /ip firewall raw.
338
Vývoj / PostgreSQL a primární klíč s funkcí?
« kdy: 30. 01. 2020, 08:10:25 »
Bádám, zda primární klíč můž být u PgSQL založen na výsledku funkce, ale nedaří se (mám tady PgSQL9.5)?
Mějme tabulku ttt, kde jsou podstatné dva sloupce:
smid | integer not null | ID zdroje
casr | tstzrange not null | Interval platnosti dat
jde udělat dvojsloupcový primární klíč nad obojím:
ALTER TABLE ttt ADD CONSTRAINT "pk-ttt" PRIMARY KEY(smid, casr);
ale pro štastnější život by se mi hodil primární klíč, kde je zahrnut z toho casr jen počáteční čas, což asi nejde, končí jako syntax error?
ALTER TABLE ttt ADD CONSTRAINT "pk-ttt" PRIMARY KEY(smid, lower(casr));
Normální index tak udělat jde:
CREATE UNIQUE INDEX "inx-ttt-scc" ON ttt(smid,lower(casr),lower_inc(casr));
Primární index se hodí mít a index dle (smid, casr) už tam je přítomen kvůli omezující podmínce na nepřekrývání se dat <CONSTRAINT "const-ttt-smid-casr" EXCLUDE USING gist (smid WITH =, casr WITH &&)>, takže se takto indexovaná data zbytečně duplikují a index založený jen na start (nebo end času) intervalu by se hodil u některých typů dotazů, kdy neumí využít index data z toho constraint.
Mějme tabulku ttt, kde jsou podstatné dva sloupce:
smid | integer not null | ID zdroje
casr | tstzrange not null | Interval platnosti dat
jde udělat dvojsloupcový primární klíč nad obojím:
ALTER TABLE ttt ADD CONSTRAINT "pk-ttt" PRIMARY KEY(smid, casr);
ale pro štastnější život by se mi hodil primární klíč, kde je zahrnut z toho casr jen počáteční čas, což asi nejde, končí jako syntax error?
ALTER TABLE ttt ADD CONSTRAINT "pk-ttt" PRIMARY KEY(smid, lower(casr));
Normální index tak udělat jde:
CREATE UNIQUE INDEX "inx-ttt-scc" ON ttt(smid,lower(casr),lower_inc(casr));
Primární index se hodí mít a index dle (smid, casr) už tam je přítomen kvůli omezující podmínce na nepřekrývání se dat <CONSTRAINT "const-ttt-smid-casr" EXCLUDE USING gist (smid WITH =, casr WITH &&)>, takže se takto indexovaná data zbytečně duplikují a index založený jen na start (nebo end času) intervalu by se hodil u některých typů dotazů, kdy neumí využít index data z toho constraint.
339
Odkladiště / Re:Jak bezpečně skladujete data doma?
« kdy: 25. 01. 2020, 09:07:21 »
Uff, jsem prvně ted nadpis četl jako "Jak bezpečně sledujete porna doma?" - to je asi to přepracování ze studování všech těch zpráv od ISO27K/NUKIB/zákaznických auditů...
Ale k otázce původní: Služební noťas neřeším, to si řeší firma na dálku. Soukromé cca 4 domácí notebooky (vše W10P) mám tak 1x ročně bitová kopie na NAS v racku doma a pak průběžně se už jen odlívá datová složka, tak 1x měsíčně. Obsah NAS ručně čas od času replikuji na svůj druhý NAS v druhé domovině na sousední tektonické desce, který je normálně trvale vypnutý a zapíná se jen na zálohy (přes ovládané PDU). Notebooky nešifrovány, složky na NASech už ano.
V případě totálního selhání pak nezbývá, než slušně formulovaný dopis k BIS/NSA/FSB/MSS s žádostí, zda někde něco nenajdou ve svém archívu, stejně u některých z nich mám červený puntík, tak by si mohli vzpomenout. :-)
Ale k otázce původní: Služební noťas neřeším, to si řeší firma na dálku. Soukromé cca 4 domácí notebooky (vše W10P) mám tak 1x ročně bitová kopie na NAS v racku doma a pak průběžně se už jen odlívá datová složka, tak 1x měsíčně. Obsah NAS ručně čas od času replikuji na svůj druhý NAS v druhé domovině na sousední tektonické desce, který je normálně trvale vypnutý a zapíná se jen na zálohy (přes ovládané PDU). Notebooky nešifrovány, složky na NASech už ano.
V případě totálního selhání pak nezbývá, než slušně formulovaný dopis k BIS/NSA/FSB/MSS s žádostí, zda někde něco nenajdou ve svém archívu, stejně u některých z nich mám červený puntík, tak by si mohli vzpomenout. :-)
340
Sítě / Re:Rozdělení switche
« kdy: 17. 01. 2020, 07:59:26 »
Tak u slušnějších swichtů je to i konfigurovatelné, zda chci/nechci, aby brala FDB v potaz VLANu (tím pádem zda MAC přeskakuje mezi VLANama nebo může stejná MAC existovat současně ve víc VLANách) a případně i kolik záznamů per VLAN nebo port dovolím max využít. Obvykle nadávky SVL/IVL (shared / independend VLAN learning).
341
Sítě / Re:Datová síť v novostavbě
« kdy: 09. 01. 2020, 22:47:37 »
Ano, mám doma zařízení propojená na 1000BaseT1 na stole. :-)
Jen si dovoluji upozornit, že 1000BaseT1 je komunikace po jednom krouceném páru pro technologické nasazení - sumárně jen 2 dráty (dříve se přes to posílala třeba sériová linka RS485 na hóóódně daleko, ale hodně pomalu). Normálnější kabeláž obsahuje 4 páry a příslušná verze pro to se jmenuje 1000BaseTX, která funguje 1 Gbps na 100 metrů na Cat6 a lepším. Nicméně je pak otázka použitého HW, zda podporuje 1000BaseT nebo i 1000BaseTX.
Jen si dovoluji upozornit, že 1000BaseT1 je komunikace po jednom krouceném páru pro technologické nasazení - sumárně jen 2 dráty (dříve se přes to posílala třeba sériová linka RS485 na hóóódně daleko, ale hodně pomalu). Normálnější kabeláž obsahuje 4 páry a příslušná verze pro to se jmenuje 1000BaseTX, která funguje 1 Gbps na 100 metrů na Cat6 a lepším. Nicméně je pak otázka použitého HW, zda podporuje 1000BaseT nebo i 1000BaseTX.
342
Sítě / Re:Wifi adhoc - topologie , možná komunikace "nepřímo viditelných"
« kdy: 06. 01. 2020, 20:07:20 »
Pokud jde o ad-hoc wifi síť dle 802.11, tak se komunikující uzly musí vidět přímo. A navíc bude komunikace často sražena jen na 11 Mbps rychlost, protože ten standard dovoluje jen WEP šifrování a pro něj je normové omezení max na 11 Mbps. Pokud jde o ad-hoc síť podle standardu WiFi Direct, tak bod rychlosti a šifrování padá, ale občas zařízení různých výrobců má problém se domluvit vzájemně.
Jestli-že je nutno, aby se dalo komunikovat "i za roh", tak musí být použito nějaké rozšíření o dynamickou mesh technologii, kterou musí všechny uzly v síti podporovat (jak je ten o kousek výše zmíněný příklad u OLPC notebooků), aby dokázaly fungovat jako repeatery. Takž eje třeba si prostudova tdokumentaci danývh zařízení, zda něco takového podporují, klasické 802.11 ad-hoc a i novější wifi direct nikoliv.
Jestli-že je nutno, aby se dalo komunikovat "i za roh", tak musí být použito nějaké rozšíření o dynamickou mesh technologii, kterou musí všechny uzly v síti podporovat (jak je ten o kousek výše zmíněný příklad u OLPC notebooků), aby dokázaly fungovat jako repeatery. Takž eje třeba si prostudova tdokumentaci danývh zařízení, zda něco takového podporují, klasické 802.11 ad-hoc a i novější wifi direct nikoliv.
343
Studium a uplatnění / Re:Kam po ZŠ?
« kdy: 02. 01. 2020, 14:27:34 »
Ano, mohlo být přesněji, samozřejmě je myšleno aspoň na §5.
344
Studium a uplatnění / Re:Kam po ZŠ?
« kdy: 02. 01. 2020, 11:03:46 »
Ještě promysli faktor, zda se jako programátor pak budeš chtít pohybovat jen v kanclu "v saku" nebo třeba zamířit i do něčeho praktického, průmyslu, robotika atd. Protože v tom druhém případě bych pak se snažil i získat vzdělání, v rámci kterého získáš uznané elektro vzdělání, abych dosáhl na vyhlášku 50, protože tu bez patřičně uznaného elektro vzdělání získat nejde. Dost to usnadní život v těchto oborech. Takže pokud nějakou střední odbornou, tak se ptát, zda součástí toho oboru je získání i vyhlášky nebo nabízí dobrovolný kurz, v rámci kterého toto vzdělání ti uznají (takže pokud půjdeš na čistě IT obor, tak to bude obvykle bez splnění elektorvzdělání, pokud na slaboproud, tak ho získáš, ale někde můžeš jít na IT obor a nabrat si dobrovolně předmět, kde pak ti dají papír, že máš ofociální potřebné elektrovzdělání).
Dodatečně, až budeš Mgr. Ing. ..., se to pak už hodně blbě honí (někdy to jde dohnat i na té vejšce dobrovolným kurzem). Každy nechce na staré kolena dálkově na učňák - píše zkrachovalý strojař, co se ze zoufalství musí živit IT v energetice, takže mu za zadkem musí sedět medvědář oficiálně kryjící to chybějící elektro vzdělání (a smějící se ti, že sice máš splněnou praxi i na vedoucího elektrosměny elektrárny, ale smůla), když musí hrabat na počítač někde v elektro rozvaděči....
Dodatečně, až budeš Mgr. Ing. ..., se to pak už hodně blbě honí (někdy to jde dohnat i na té vejšce dobrovolným kurzem). Každy nechce na staré kolena dálkově na učňák - píše zkrachovalý strojař, co se ze zoufalství musí živit IT v energetice, takže mu za zadkem musí sedět medvědář oficiálně kryjící to chybějící elektro vzdělání (a smějící se ti, že sice máš splněnou praxi i na vedoucího elektrosměny elektrárny, ale smůla), když musí hrabat na počítač někde v elektro rozvaděči....
345
Sítě / Re:IPv6 a dynamické DNS
« kdy: 24. 12. 2019, 10:20:25 »
Řešení pro obecně příchozí bude problém. Pokud se klient konfiguruje pomocí SLAAC, tak se ti ten router/DNS server nemá jak dozvědět jeho jméno, dokud ho klient sám nějak neohlásí. Ani v případě DHCPv6 nemáš jistotu, že bude v žádosti něco, co můžeš použít jako jméno do DNS (a navíc DHCPv6 je nepovinné a řada věcí jej nepodporuje).
Sice si jde vést seznam živých IPv6 adres v síti, ale nějak smysluplně a univerzálně k nim hledat jméno bude problém. Pokud chci povolit takto přímo lokální komunikaci, tak asi nechat ten dual stack plus mDNS/LLMNR a v lokálním DNS mít jen to, co je tak staticky trvale.
Sice si jde vést seznam živých IPv6 adres v síti, ale nějak smysluplně a univerzálně k nim hledat jméno bude problém. Pokud chci povolit takto přímo lokální komunikaci, tak asi nechat ten dual stack plus mDNS/LLMNR a v lokálním DNS mít jen to, co je tak staticky trvale.
