Příspěvky

871

Sítě / Re:Datový rozvod v malom RD

« kdy: 01. 02. 2020, 22:47:22 »

Multiswitch i NAS docela topí, dávat je do uzavřeného (byť perforovaného) racku není dobrý nápad. Pokud se rovnou neupečou, zkrátí se jim životnost.

Na tvrdé kabely (drát) patří zásuvka (patch panel) a do ní měkký patch kabel (licna). Dávat konektor přímo na kabel je tak trochu čuňárna, ale dělá se to kvůli úspoře peněz a prostoru. Důvodem, proč to nedělat je, že kabel z drátu nesnese mnoho ohnutí a po pár manipulacích se zlomí a začne zlobit (a to se pak blbě hledá). Proto by měl vést drát do pevných rozvodů (patch panel <=> zásuvka) a dál by se mělo pokračovat licnou.

872

Vývoj / Re:PostgreSQL a primární klíč s funkcí?

« kdy: 30. 01. 2020, 22:13:28 »

... 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íč.

Ok, ale přesně na to by Váš PK nad funkcí nefungoval. Protože by "ty klikátka" měly jiný PK než sloupec, který chtějí zobrazovat. V tomto bodě jste si možná odpověděl sám.

... zbytek rozumím, proto necituji... Řešil bych to tím generated sloupcem, nebo v případě PG9.5 triggerem. (K triggeru by měl být ještě CHECK, aby nějaký chytrák nezaktualizoval ten vytvářený sloupec nezávisle od casl, casu.)

873

Vývoj / Re:PostgreSQL a primární klíč s funkcí?

« kdy: 30. 01. 2020, 19:00:55 »

Celý ten dotaz je nesmysl, omlouvám se.
Primární klíč identifikuje řádek. Pokud je pro identifikaci důležitá jen levá část intervalu, pak by měla být uložena zvlášť levá a zvlášť pravá část. Naopak tzrange z toho dopočítávat (index nad dopočtenou tzrange).

Postgresu funguje PRIMARY KEY a UNIQUE KEY nad NOT NULL sloupci technicky naprosto totožně.
Jediným rozdílem je, že PK může být maximálně jeden, a že pohlídá, aby byl nastavený NOT NULL.
Když si to pohlídáte, ničemu nevadí se na PK v tomto případě vykašlat (nemusíte si na to definovat ani jiný identifikátor, ale slušelo by se to).

Osobně bych ten tzrange rozpálil do dvou timestampů a udělal PK tak, jak jste ho popsal. Tzrange můžete použít jen v indexu, případně (kdyby to mělo nějaký smysl pro výkon - ale pochybuji), triggerovat ho do dalšího sloupce. V PG12 můžete využít generated column: https://www.postgresql.org/docs/12/ddl-generated-columns.html a vyhnout se triggeru.

874

Sítě / Re:Datová síť v novostavbě

« kdy: 28. 01. 2020, 14:18:40 »

Nejlepších výsledků dosáhnete s F/FTP.
S/UTP je "nižší" standard.

Belden považuji za lepší značku než Datacom, ale podle specifikace Datacom vypadá o chlup kvalitnější.

Ještě se podívejte na zásuvky, pokud nedokážete zakončit stínění v zásuvce, je zbytečné i v kabelu.

875

Vývoj / Re:Ukládání vícejazyčných verzí v MariaDB

« kdy: 28. 01. 2020, 11:29:15 »

bude full-text indexovat i anglictinu a vyhledavani  to muze zpomalovat. I kdyz uz 18 000 radku to asi nebude zase takova katastrofa. Pridani sloupcu je pro danou situaci asi lepsi. Indexy pridanych sloupcu budou obsahovat jen slova, ktera se vztahuji k dane jazykove mutaci. Souhlas?

Máte pravdu, jedná se o jedno z mnoha omezení v mysql (mariadb). V "dospělých" databázích byste udělal parciální index (CREATE INDEX ft_cz ... WHERE lang='cz').

Takže Vám opravdu nezbude, než přidat sloupec. Chjo, mysql jen kazí návyky .

876

Vývoj / Re:Ukládání vícejazyčných verzí v MariaDB

« kdy: 27. 01. 2020, 18:50:48 »

Z hlediska DB je správné udělat dvě (možná tři) řešení. Buďto přidávat sloupce, (do sloupce pole), nebo to vše navázat. Pokud se jedná jen o EN a CZ a další jazyk je nepravděpodbný, udělal bych to jako slopec navíc. Kdyby to mělo být obecnější pak, vazbou:

CREATE TABLE product_translation(jazyk varchar, description text) a do něj vložit "CZ", "toto je český popis" a "EN", "this is an English description".

Dokonce to můžete zobecnit nad celou DB pomocí UUID třídy, tabulky a záznamu. Databáze si s tím pak dokáže poradit stoprocentně lépe, než Vaše vymýšlení "optimalizací". Dá se říct, že cokoliv Vás napadne jako struktura, dokáže DB zobecnit - tak se nesnažte jít proti tomu .

877

Sítě / Re:VPN bez verejnej IP adresy

« kdy: 26. 01. 2020, 19:15:03 »

...

DHCPOPTIONS jdou skrz VPN.
Naváže se VPN. Do VPN se pošle dotaz na DHCPOPTIONS a podle nich se nastaví zbytek.

Možná jen nerozumím otázce.

878

Sítě / Re:Datová síť v novostavbě

« kdy: 23. 01. 2020, 14:09:14 »

No televize má přednost :O) kopírování spusím až na noc a je mi jedno jak dlouho běží ... Do rána se to stihne.

To mi nepřijde moc šťastné, myslím, že spousta lidí právě nechce řešit, co kdy má kopírovat. Obyčejně v domě žije celá rodina a nechtějí řešit kdo co kdy smí. Zkuste dětem vysvětlit, že WiFi mají jen v obýváku... Atd.

To co tu plánujete do RD nemá leckterá malá firma někde kolem dvaceti zaměstnanců, protože to prostě nepotřebuje, ale je to jedno každý chce jiné hračky

Co znám firmy, tak když dělají rekonstrukci, tak pořizují kabeláž aby vydržela. Pokud se tahá v lištách po stěně a jde vyměnit, dává se to, co je zrovna dostačující.

Meritem sdělení bylo hlavně to, že Cat 5e je dnes už historický relikt a na celém domě ušetříte mezi 6A a 5e asi 2000 Kč - směšně.

879

Server / Re:Server pro malou firmu

« kdy: 23. 01. 2020, 10:10:28 »

Server má několik výhod - nevím, jestli je oceníte, napadají mě:
1. možnost napájení z více zdrojů (výměna za chodu),
2. IPMI a vzdálená konzole (instalace, správa na dálku i při krachu OS).

Supermicro prodává poměrně levné a malé servery, je to podle mě lepší než desktop.

Poměrně šikovné je ho zvirtualizovat (já mám nejradši ESXi, jedinou nevýhodou je potřeba víc RAM 6 GB navíc?, ale to nestojí moc). Pak můžete záznam z kamer oddělit od databáze, prací a správou na jednom nebudou výpadky na druhém.

880

Sítě / Re:Datová síť v novostavbě

« kdy: 22. 01. 2020, 23:59:03 »

Dnešní wifi jsou opravdu parádně rychlé, ale dosah klesá a rychlost klesá se vzdáleností. Je to znát už i přes místnost. Když dva provádějí něco datově náročného, nefunguje to dobře. S kabelem se to srovnat nedá.

881

Sítě / Re:Rozdělení switche - dodatek ohledně private VLAN...

« kdy: 22. 01. 2020, 23:10:45 »

A pokud se ptáte "ale k čemu to všechno", jako že konkrétní use-case / scénář... to je taky dobrá otázka. Třeba chceme šetřit adresním prostorem, proto všichni účastníci v jednom subnetu, ale zároveň nechceme, aby se navzájem ohrožovali, a jenom dost vyjímečně mají potřebu a nárok, bavit se navzájem zcela konkrétním a dobře filtrovatelným protokolem - a v tom případě je chceme nějak filtrovat routerem/firewallem (nad rámec toho, co zvládnou dnešní switche v hardwaru i "napřímo", a že toho zvládnou poměrně dost). Aneb dosaďte si své vlastní paranoidní zadání :-)

Jo takhle to myslíte. No asi jediné rozumné řešení je L3 switch a filtrovat to na IP. Druhé řešení, pokud nemáte L3 switch, je onen jeden port dát do extra VLAN a na routeru udělat bridge s filtrováním (což je de facto rozkouskovaný L3 switch . Mrcasit se s proxy arp mi přijde šílené (zatím se mi vždy podařilo téhle šílenosti vyhnout, ale vlan+bridge+vlan už jsem řešil).

BTW nepleťte si prosím ARP tabulku (L3) s FDB=CAM tabulkou (L2)

Díky .

882

Sítě / Re:Rozdělení switche - dodatek ohledně private VLAN...

« kdy: 22. 01. 2020, 21:54:53 »

Já pořád nějak nechápu, proč bych měl v PVLAN dělat proxy ARP, k čemu by mi to bylo?

No... tohle mi nejde moc do hlavy. Na ingressu přiletí paket. Poslat ho do obou VLAN by znamenalo, ten paket zdvojit/naklonovat a dát každé kopii jinou značku. Protože v paketu je VLAN tag jenom jeden. Pro "point to point" spojení (TCP relace) toto nedává smysl. Pro komunikaci jednotlivými pakety by to pro některé aplikace smysl mít mohlo... ale je to divoké.

Podle mě by neposílal dva packety. Představte si switch, který má jednu ARP pro všechny VLAN společnou. Potřebujete odeslat packet a zeptáte se Who Has IP a povolíte to proswištět do všech portů v obou VLAN. Odpoví však jen jeden konkrétní. Získáte MAC a pak už switch ví, kam další (L3) provoz posílat. VLAN fungují na mnoha switchích "jen" jako filtr, které porty vynechat při přepínání.

883

Windows a jiné systémy / Re:Licence pro Windows 10

« kdy: 22. 01. 2020, 21:39:38 »

"Nezapomeňte na to, že jste to Vy, kdo se dovolává platnosti smlouvy - proto taky prokazujete TOTO tvrzení."

Není pravda nejprve musí ten kdo podává žalobu podat "důkazy" jinak vůbec žádný soud nebude, sám jste to napsal...

"najdou u Vás kupu SW, ale zjistí se, že není legální, protože jste ho koupil od někoho, kdo Vás podvedl"

Nesmysl to od koho jsem co koupil nijak neurčuje nakolik je co legální a mimochodem v mém počítači nemá co kdo pohledávat.

Důkazem pro soud bude zadokumentování, že software užíváte (třeba fotka z kavárny) a Vaše odmítnutí prokázat to autorovi.

To, že jste byl podveden nemění nic na tom, že není legální a musíte ho odinstalovat nebo dokoupit a nahradit poškozenému (autorovi) škodu z titulu bezdůvodného obohacení (měl jste z toho neoprávněný prospěch).

884

Sítě / Re:Rozdělení switche - dodatek ohledně private VLAN...

« kdy: 22. 01. 2020, 21:16:16 »

Takže si představte "primární" ... aplikační odpověď proletí stejným způsobem na dva hopy opačným směrem.

Rozumím. A co je v tom za problém?

Něco v tom smyslu jsem v nějakých čínských návodech taky zaznamenal, ale vždycky jsem to hodil za hlavu s tím, že mám asi vlčí mlhu, nebo že documentation writer rozumí spíš angličtině než základním principům. Na egressu bych tomu rozuměl: přijde paket s jednou nebo druhou značkou, vypadne vždycky tímhle portem. Ale opačným směrem lze ten paket poslat pochopitelně jenom do jedné z obou VLAN. Do které? No tak se jedna určí jako default. Nojo, ale pokud je to odpověď na dotaz "z ne-defaultní VLAN", tak se tazatel odpovědi nedočká. Tzn. možné to asi je, ale praktický smysl v tom moc nevidím.

Já si myslím, že port nastavený do dvou VLAN to pošle do obou. ARP mu odpoví (snad) jen z jedné. Ale účel toho fakt nechápu.

885

Sítě / Re:Datová síť v novostavbě

« kdy: 22. 01. 2020, 19:19:19 »

Všechno je to o ceně a snadnosti manipulace.
Pokud je to dům, kde chci bydlet dalších XX let, pak zvážím Cat7.
Pokud musím škrtit rozpočty, budu přemýšlet nejvíc o Cat6a.
Cat5e bych dával jen tam, kde potřebuju fakt jen pár konkrétních propojů, nic dalšího od toho neočekávám a/nebo bych měl problém zatáhnout tlustší kabely.