1051
Vývoj / Re:Arduino programované v Pythonu
« kdy: 14. 05. 2018, 10:52:51 »
OT, ale jste mi hoši připomněli, že jsem zahlédl Python pro uživatelské skriptování v nějakých GSM modemech s vnitřnostmi zn. Telit...
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.
1052
Hardware / Re:OT: pařezy (Re:Postavení super výkonného a super malého PC)
« kdy: 09. 05. 2018, 20:31:32 »... najdi si holku.
Ale no jooo, už končim s tím tapetováním :-)
O rodině neklábosím s lidma co neznám.
Koukni na ZOTAC MAGNUS 1080Hezky. Ale pod zátěží bude hřát, přestože má ventilátor. Napájení 19V dvěma dutými jacky ze dvou externích adaptérů :-)))
1053
Hardware / Re:Postavení super výkonného a super malého PC
« kdy: 09. 05. 2018, 16:39:10 »https://www.youtube.com/watch?v=eCjapqw1pYA
To ti u šeříku a bezu nepomůže, protože to během pár dní pošle výmlazky a bojuješ s tím pak jako s Hydrou. až na to, že místo jedný hlavy ti nevyrostou dvě, alébrž rovnou tak dvacet. nejlíp funguje listy máznout gelovým roundupem a po týdnu oštípat kleštěma a vykopat pařez.
vidis to, to jsem nevedel.
a ted vtipne zpet k tematu:
a chlazeni se kam dava na ten brousic parezu? jake to ma TDP ?
Tenhle je ještě slabej. Mechanickej výkon budou nižší jednotky kW a pokud to má účinnost využití paliva třeba 30% tak si vem, kolik bude topnej výkon. Chlazení tradičně žebry na válci s ofukem radiálním ventilátorem, který je schovaný v té kapotě navrchu (někde těsně u ventilátoru je naviják "trhacího" startéru).
Jsou i výkonnější verze.
https://www.youtube.com/watch?v=QVAJT2ThP-4
https://www.youtube.com/watch?v=p7TrSMcolnI
Ale účinnost bude podobně bídná. Jako samotnej motor u toho velkého traktoru může mít účinnost ke 40%, ale zase spotřebuje spoustu energie na svůj vlastní pohyb/přesun. Chlazení vodou + ventilátor na výměníku voda/vzduch.
1054
Hardware / Re:OT: pařezy (Re:Postavení super výkonného a super malého PC)
« kdy: 09. 05. 2018, 13:20:55 »hele, než si tady špinit triko s tímhle tr(v)olem, jdu radši zase trhat na zahradu pařezy.
Hele čím trháte pařezy? To je možná mnohem zajímavější téma :-) Co zbylo na zahradě po předchozím majiteli jsem sice dávno vykopal, a nově vzniklé soušky páčím za delší pahýl ručním navijákem, ale slyšel jsem o různých dalších postupech, některé jsou zřejmě docela zábavné :-) Hergot... asi si říkám o smahnutí.
To ti reknu naprosto presne. ten nejslabsi clanek jsi ty, takze si vem lopatu a krumpac a nevymyslej blbosti s navijakem.
To vim naprosto přesně, že nejslabší článek jsou moje záda :-) Řekly mi to dost jasně, poté co jsem vykopal před pár lety asi 10 m drážky do hloubky 80cm v šutrovitém jílu. Od té doby na ně musím opatrně. Takže následně když jsem doloval asi 6-7 pařízků, tak už jsem musel dávat bacha. Pařízky to byly nevelké, po ovocných stromech asi 20-30 cm tloušťka kmene. Žádné půltunové buky, žádné borovice s kořenem přímo dolů. Vedle krumpáče a lopaty používám dvoukilovou sekeru a nějaká další "párátka".
S pařezem uříznutým u země se toho moc jiného dělat nedá, ani navijákem. Ale když si necháte třeba 2m pahýl, a nejlíp ho necháte rok-dva prohnít, tak už páka tažená navijákem dost pomůže. Není třeba kopat tolik do hloubky, víceméně najdu mělce rostoucí kořeny kolem a postupně je osekávám, až si pahýl lehne. Tahal jsem s tím taky nějaké mladé jasánky, ještě zelené, tak do 10 cm průměru - a tyhle mrchy jsou ochotné se pružně ohnout k zemi, aniž by rupnul kmen nebo kořeny.
Pokud jde o naviják... koukal jsem na nějaké hupcuky, ale pokud se nepodaří sehnat v bazaru něco slušného, je funglový hupcuk na blbnutí na zahradě trochu drahá sranda. Nakonec jsem postavil takovou železnou kozu pod klikou hnaný lanový navijáček co utáhne asi tunu. Přikládám hrubé náčrtky (fotku kupodivu nemám). Tyhle ruční navijáky se tuším používají na přívěsech pod člun apod. Je na tom asi 6tka ocelové lanko, pár metrů jsem si koupil navíc, k tomu nějaké spojky/třmeny/oka/háky, a jako kotvu dvoutunový polyesterový úvaz (tlusté lano v rukávu) který hodím dvojmo kolem zdravého silného stromu těsně nad zemí. Pro jistotu na navíjené lanko vážu ještě 1-2 závaží pro případ, že by chtělo rupnout. Je to celé bastl, ale je s tím sranda. Asi nejslabší článek jsou nekvalitně provedené železné převody na levném navijáku, a spojky na lankách.
Když jsem si pak pozval bagristu na jednu další drážku, tak mi řekl, že jsem trubka, že se s pařízkama dřu ručně. Když ono je to zas něco jiného, než pořád jenom rukama na klávesnici, a ten naviják tomu dodá jistý moment dobrodružství :-)
Ptal jsem se spíš jestli někdo nemá nějaké humorné postupy typu "na krtka propanbutanem" atp.
Taky jsem na pár věcí použil páku ze 4m smrkového trámku 80x80 mm, jehož konec jsem zasadil asi do metrového ocelového účka (zřejmě UPE100). Tahal jsem s tím staré sloupky od plotu. Na konci účka jsem flexou vyrobil "zobáček" (asi jako má otvírák na pivo) který jsem buď mohl přímo nasadit "obkročmo" na tažený sloupek (skrz který jsem prohnal šroub), a uměl jsem na konec i zaháknout řetěz, který jsem přivázal na vzdorovitý pařízek apod. Asi největší kumšt byl nějak tu páku podložit blízko u konce = poskytnout jí "pevný bod". A pak dávat bacha, aby tažený pahýl "náhle nepovolil" :-) Pár takových příhod bylo, ale neměl jsem nikdy ani bouli.
1055
Hardware / OT: pařezy (Re:Postavení super výkonného a super malého PC)
« kdy: 08. 05. 2018, 22:51:02 »hele, než si tady špinit triko s tímhle tr(v)olem, jdu radši zase trhat na zahradu pařezy.
Hele čím trháte pařezy? To je možná mnohem zajímavější téma :-) Co zbylo na zahradě po předchozím majiteli jsem sice dávno vykopal, a nově vzniklé soušky páčím za delší pahýl ručním navijákem, ale slyšel jsem o různých dalších postupech, některé jsou zřejmě docela zábavné :-) Hergot... asi si říkám o smahnutí.
1056
Hardware / Re:Postavení super výkonného a super malého PC
« kdy: 08. 05. 2018, 07:32:15 »
Neslo by to chladit jak je to napr tady: https://youtu.be/cPx4qyKPsw0
Nevim kolik je ty tekutiny potreba (aby stihala kondenzovat zpet z pary na tekutinu) a jestli by se to veslo do rozpoctu.
To je boží :-) Mít fajfku, označil bych to jako řešení.
Stejný princip údajně používá "heat pipe", a v tom případě údajně stačí nějaká těkavá kapalina jako aceton. Stačila by i destilka, nejlépe ve vakuu (nižší bod varu). Akorát že board ponořený do acetonu by to dlouho nepřežil, stejně jako board v destilce. Ta kapalina od 3M je zřejmě nepolární, s nízkým bodem varu, nicméně nefunguje jako organické rozpouštědlo. Žeby nějaký těžší freon?
Praktické problémy: jak to utěsnit kolem kabelů, a cena náplně. Těch pár litrů na videu údajně stálo 1600 USD.
"kolik je té kapaliny potřeba": podle mého především tolik, aby se do ní ponořily všechny chlazené součástky. Tzn. je vhodné postavit tomu trochu úspornou nádobu = rozměrově "na míru". Při té konstrukci na videu je pak hmotnost toho štoffu v plynné fázi zřejmě zanedbatelná, pokud tam není 1km trubek ke chladiči/kondenzátoru.
A ta kapalina řeší "jenom" transport tepla. Pokud to má být dál už pasivně chlazené vzduchem, opět bude třeba řešit rozměry teplosměnné plochy a prostor kolem.
1057
Hardware / Re:Postavení super výkonného a super malého PC
« kdy: 07. 05. 2018, 22:51:10 »František Ryšánek:
ta vaše krabička http://www.aaeon.com/en/p/fanless-embedded-computers-aec-6920/
Má procesor s TDP 34W. Takže já se v pohodě vlezu s procesorem s TDP 95W do nějaké pořádnější skřině.
No však jsem ji jako příklad použil záměrně a škodolibě :-) Zrovna tahle historická krabička (čest její památce) se navzdory své cihelné dimenzi hřála docela dost. Proto říkám: tak do 20W v těchto rozměrech, a ne že tu žebrovanou cihličku zavřete do stísněné skříňky.
Pořádnější skříň na 100W TDP by musel být zhruba tower s oběma sajtnami žebrovanými a kvalitním přenosem tepla z procesoru na ty sajtny. Teda pokud nechcete vnitřnosti provozovat při teplotách, které neprojdou mým testem (udržím na tom ruku a nesmrdí to). Takový tower jsem mimochodem nedávno zahlédl... taková fanless pornografie, a spíš jenom na oko. Vnitřnosti nebyly moc dobře tepelně přivázané, pokud si správně pamatuju. V podstatě namachrovaný case na normální ATX motherboard :-(
1058
Hardware / Re:Postavení super výkonného a super malého PC
« kdy: 07. 05. 2018, 13:49:33 »
@nobody(ten pravej) :
> https://fit-iot.com/web/products/airtop2/airtop2-specifications/
Ano! Palec nahoru za procesor z rubu motherboardu.
V patici? To jsem asi ještě neviděl, ale proč ne...
By mě zajímalo, jestli mají kromě CPU na chladič přivázáno i něco dalšího. Totiž nejen procesor topí.
@anonym:
> https://www.asrock.com/mb/Intel/X299E-ITXac/
Huf, to ke kus! No jestli tam mají ve VRM jenom těch 5 polymer-tantalů od Panasonicu, tak to nevidím na dlouhou životnost. To by ten VRM musel bejt *hodně* vychytanej aby skládal fáze hezky za sebou / minimalizoval střídavou složku...
Obecně:
Procesor nekonvertuje elektrický příkon na "výpočetní energii". Procesor konvertuje elektrický příkon na teplo. Chová se jako topné těleso. Něco přidají méně žravé součástky okolo, nějaké teplo vzniká ztrátami ve VRM (na motherboardu) a v napájecím zdroji. Všechno tohle teplo je třeba odvést, jinak se bude hromadit pouze v nevelké vlastní tepelné kapacitě součástek uvnitř = poroste *teplota*. Pasivní počítače se vyznačují tím, že všechny součástky uvnitř chladící skříně běží na vyšší teplotě, než je teplota skříně. Na rozdíl od větraného počítače, kde se chladící vzduch dostane i na teplosměnné plochy uvnitř.
Vemte si, že pasivní skříňka o téhle velikosti:
http://www.aaeon.com/en/p/fanless-embedded-computers-aec-6920/
uchladí důstojně cca 20W topného výkonu.
A teď si představte, jakou plochu by ta krabice musela mít, aby se pasivně uchladilo 100W+.
Hlubší a hustší žebra při pasivním chlazení moc nepomohou. A hliník o tloušťce 5 mm účinně roznese teplo na vzdálenost třeba jenom na 10-15 cm. Takže vodník / heatpajpy nebo ještě tlustší řízek hliníku.
Čili jedna věc je venkovní plocha. Pominu prostorové uspořádání okolí = kolik je kolem místa a jaká je šance na volnou cirkulaci vzduchu. (Další věc je navázání zdrojů tepla uvnitř počítače na vnější žebrovanou skříň.) Dokud se nepodíváte dovnitř, je pravděpodobnější hypotéza, že to taiwanec navrhl blbě, nebo že mu to ve výrobě zoptimalizovali.
Osobně považuji za optimální uspořádání s procesorem na rubu desky. Obvykle v BGA pouzdru = přímo letovaný. Tímto je CPU na rubu desky nejvyšší součástkou, a není problém ho přisadit naplocho přímo na chladič. Žádný dlouhý / štíhlý / odfláknutý tepelný most.
Přímá tepelná vazba je kvalitnější a méně krkolomná i oproti scénáři, že byste standardní ITX motherboard umístili na dlouhé distance lícovou stranou k plochému chladiči, a teplo přenášeli hliníkovým (spíš měděným) "tepelně-distančním kvádrem". (I taková konstrukce je občas k vidění. Přibližně viz dvě přiložené fotky.)
Umístění CPU z rubové strany znamená, že se otočí pořadí signálů v paralelních sběrnicích, např. k DIMM paticím! oproti stavu "jak to pánbůh Intel zamýšlel". Tzn. navrhnout plošák bude o něco větší oříšek, než vzít referenční motherboard od Intelu a trochu dochutit.
Kromě CPU jsou v počítači další topné součástky. VRM bude trochu topit, i pokud se jeho účinnost přiblíží ideálním cca 95% (synchronní usměrnění). Takže nejlíp ho taky přivázat, nebo aspoň některé velké součástky (FETy, indukčnosti). Obecně pokud vezmu ATX motherboard, a třeba vodníkem mu ochladím jenom procesor, a ten procesor hodně žere, tak riskuju odpálení VRM (MOSFETy, kondenzátory) = je potřeba chladit i další věci kromě CPU. Občas třeba vidím, že se výrobce snaží chladit i SODIMM.
Problém je, že mechanická tolerance "výšky" SMD součástek nad rovinou plošáku je nenulová. Takže pokud potřebujeme o chladič opřít víc než jednu součástku, nepůjde to "kov na kov" s pouze minimální vrstvičkou pasty. Tolerance výrobci s oblibou řeší šedou ŽVEJKAČKOU. Problém je o to horší, že různé součástky jsou i jmenovitě různě vysoké. Jsou k vidění dosedací plochy stupňovitě frézované pro lepší přizpůsobení součástkám na motherboardu, nebo různě tlusté "distanční plíšky" - ale poslední slovo má vždycky žvejkačka. A pokud skutečně kromě CPU jsou přivázané i další součástky, tak jsem ještě neviděl, aby CPU měl pastu a jenom ostatní smetí okolo mělo žvejkačku = žvejkačku pak dostane i procesor! A vrstva žvejky mezi chladičem a čipem CPU je klidně půl milimetru. V lepším případě to jde napravit vyhozením žvejkačky na CPU (náhrada pastou) a upravením tloušťky /dávkování žvejkačky na ostatních součástkách, aby si to celé sedlo dohromady...
"Pokud na tom udržím ruku a nesmrdí to, tak to má šanci nějakou dobu fungovat" - dávná bastlířská hypotéza, o které se mnou dodnes v práci kolegové polemizují.
http://support.fccps.cz/download/adv/frr/teplo.pdf
Jako že jsem moc outlocitnej.
> https://fit-iot.com/web/products/airtop2/airtop2-specifications/
Ano! Palec nahoru za procesor z rubu motherboardu.
V patici? To jsem asi ještě neviděl, ale proč ne...
By mě zajímalo, jestli mají kromě CPU na chladič přivázáno i něco dalšího. Totiž nejen procesor topí.
@anonym:
> https://www.asrock.com/mb/Intel/X299E-ITXac/
Huf, to ke kus! No jestli tam mají ve VRM jenom těch 5 polymer-tantalů od Panasonicu, tak to nevidím na dlouhou životnost. To by ten VRM musel bejt *hodně* vychytanej aby skládal fáze hezky za sebou / minimalizoval střídavou složku...
Obecně:
Procesor nekonvertuje elektrický příkon na "výpočetní energii". Procesor konvertuje elektrický příkon na teplo. Chová se jako topné těleso. Něco přidají méně žravé součástky okolo, nějaké teplo vzniká ztrátami ve VRM (na motherboardu) a v napájecím zdroji. Všechno tohle teplo je třeba odvést, jinak se bude hromadit pouze v nevelké vlastní tepelné kapacitě součástek uvnitř = poroste *teplota*. Pasivní počítače se vyznačují tím, že všechny součástky uvnitř chladící skříně běží na vyšší teplotě, než je teplota skříně. Na rozdíl od větraného počítače, kde se chladící vzduch dostane i na teplosměnné plochy uvnitř.
Vemte si, že pasivní skříňka o téhle velikosti:
http://www.aaeon.com/en/p/fanless-embedded-computers-aec-6920/
uchladí důstojně cca 20W topného výkonu.
A teď si představte, jakou plochu by ta krabice musela mít, aby se pasivně uchladilo 100W+.
Hlubší a hustší žebra při pasivním chlazení moc nepomohou. A hliník o tloušťce 5 mm účinně roznese teplo na vzdálenost třeba jenom na 10-15 cm. Takže vodník / heatpajpy nebo ještě tlustší řízek hliníku.
Čili jedna věc je venkovní plocha. Pominu prostorové uspořádání okolí = kolik je kolem místa a jaká je šance na volnou cirkulaci vzduchu. (Další věc je navázání zdrojů tepla uvnitř počítače na vnější žebrovanou skříň.) Dokud se nepodíváte dovnitř, je pravděpodobnější hypotéza, že to taiwanec navrhl blbě, nebo že mu to ve výrobě zoptimalizovali.
Osobně považuji za optimální uspořádání s procesorem na rubu desky. Obvykle v BGA pouzdru = přímo letovaný. Tímto je CPU na rubu desky nejvyšší součástkou, a není problém ho přisadit naplocho přímo na chladič. Žádný dlouhý / štíhlý / odfláknutý tepelný most.
Přímá tepelná vazba je kvalitnější a méně krkolomná i oproti scénáři, že byste standardní ITX motherboard umístili na dlouhé distance lícovou stranou k plochému chladiči, a teplo přenášeli hliníkovým (spíš měděným) "tepelně-distančním kvádrem". (I taková konstrukce je občas k vidění. Přibližně viz dvě přiložené fotky.)
Umístění CPU z rubové strany znamená, že se otočí pořadí signálů v paralelních sběrnicích, např. k DIMM paticím! oproti stavu "jak to pánbůh Intel zamýšlel". Tzn. navrhnout plošák bude o něco větší oříšek, než vzít referenční motherboard od Intelu a trochu dochutit.
Kromě CPU jsou v počítači další topné součástky. VRM bude trochu topit, i pokud se jeho účinnost přiblíží ideálním cca 95% (synchronní usměrnění). Takže nejlíp ho taky přivázat, nebo aspoň některé velké součástky (FETy, indukčnosti). Obecně pokud vezmu ATX motherboard, a třeba vodníkem mu ochladím jenom procesor, a ten procesor hodně žere, tak riskuju odpálení VRM (MOSFETy, kondenzátory) = je potřeba chladit i další věci kromě CPU. Občas třeba vidím, že se výrobce snaží chladit i SODIMM.
Problém je, že mechanická tolerance "výšky" SMD součástek nad rovinou plošáku je nenulová. Takže pokud potřebujeme o chladič opřít víc než jednu součástku, nepůjde to "kov na kov" s pouze minimální vrstvičkou pasty. Tolerance výrobci s oblibou řeší šedou ŽVEJKAČKOU. Problém je o to horší, že různé součástky jsou i jmenovitě různě vysoké. Jsou k vidění dosedací plochy stupňovitě frézované pro lepší přizpůsobení součástkám na motherboardu, nebo různě tlusté "distanční plíšky" - ale poslední slovo má vždycky žvejkačka. A pokud skutečně kromě CPU jsou přivázané i další součástky, tak jsem ještě neviděl, aby CPU měl pastu a jenom ostatní smetí okolo mělo žvejkačku = žvejkačku pak dostane i procesor! A vrstva žvejky mezi chladičem a čipem CPU je klidně půl milimetru. V lepším případě to jde napravit vyhozením žvejkačky na CPU (náhrada pastou) a upravením tloušťky /dávkování žvejkačky na ostatních součástkách, aby si to celé sedlo dohromady...
"Pokud na tom udržím ruku a nesmrdí to, tak to má šanci nějakou dobu fungovat" - dávná bastlířská hypotéza, o které se mnou dodnes v práci kolegové polemizují.
http://support.fccps.cz/download/adv/frr/teplo.pdf
Jako že jsem moc outlocitnej.
1059
Sítě / Re:Asi neobvyklá konfigurace VPN
« kdy: 01. 05. 2018, 22:46:17 »
> 12[IKE] received DELETE for ESP CHILD_SA with SPI 0df79ea0
Takže můžete zkusit zvednout na serveru debug level pro tuto oblast (neporadím jak) a stejně třeba nakonec nezjistíte, proč IPhone proti [vašemu IPsec serveru] tu security association típne vzápětí po navázání. Netvrdím že je to tenhle případ, ale moje dosavadní zkušenosti s IPsecem jsou přesně takové: různé implementace proti sobě navzájem se povedou málokdy. Jsou tu lidi, kteří IPsecem dýchají, a pro ně to třeba není takový problém. Taky tu zatím nikdo nezmínil, že IKE v2 je v tomhle lepší než "v1" apod.
Osobně mám lepší (použitelné) zkušenosti s OpenVPN. Je to jediný projekt (code base) a je sám se sebou slušně kompatibilní napříč mnoha releasy.
Pro tenhle scénář (cestující klienti na centrálu) doporučuji transport TCP (nikoli UDP), a pokud by nefungoval standardní port 1194, dá se to narafičit i na port 443 (který má o něco lepší šanci skrz firewally).
Autentikace klientů se dá navléknout pomocí PKI certifikátů, nebo pomocí loginu+hesla, nebo kombinací obojího. Z hlediska správy konfigurací klientů je nejjednodušší varianta, kdy jednotlivý klient potřebuje jenom svůj (jednotný) konfigurák, certifikát CA (pokud na server použijete self-signed certifikát) a samozřejmě login+heslo. Tzn. klient teoreticky nepotřebuje svůj vlastní certifikát. Je to méně bezpečné, ale jde to.
S OpenVPN (nebo s libtls?) se distribuuje pár skriptů zvaných "easy RSA", pomocí kterých lze generovat potřebné certifikáty. Na serveru je potřeba cerfikát a tuším soubor s "Diffie-Hellman" klíčem (nebo co to je).
Pro mě osobně asi nejnáročnější bylo zorientovat se v klíčích a certifikátech = naučit se základní chvaty s easy-RSA. Nějaké vzorové konfiguráky OpenVPN serveru a klienta mohu kdyžtak nabídnout.
Pokud by se mělo jednat o rozsáhlejší síť (větší počet mobilních zařízení) tak zvažte privátní APN. Odpadly by starosti s konfigurací a některými nectnostmi OpenVPN.
Takže můžete zkusit zvednout na serveru debug level pro tuto oblast (neporadím jak) a stejně třeba nakonec nezjistíte, proč IPhone proti [vašemu IPsec serveru] tu security association típne vzápětí po navázání. Netvrdím že je to tenhle případ, ale moje dosavadní zkušenosti s IPsecem jsou přesně takové: různé implementace proti sobě navzájem se povedou málokdy. Jsou tu lidi, kteří IPsecem dýchají, a pro ně to třeba není takový problém. Taky tu zatím nikdo nezmínil, že IKE v2 je v tomhle lepší než "v1" apod.
Osobně mám lepší (použitelné) zkušenosti s OpenVPN. Je to jediný projekt (code base) a je sám se sebou slušně kompatibilní napříč mnoha releasy.
Pro tenhle scénář (cestující klienti na centrálu) doporučuji transport TCP (nikoli UDP), a pokud by nefungoval standardní port 1194, dá se to narafičit i na port 443 (který má o něco lepší šanci skrz firewally).
Autentikace klientů se dá navléknout pomocí PKI certifikátů, nebo pomocí loginu+hesla, nebo kombinací obojího. Z hlediska správy konfigurací klientů je nejjednodušší varianta, kdy jednotlivý klient potřebuje jenom svůj (jednotný) konfigurák, certifikát CA (pokud na server použijete self-signed certifikát) a samozřejmě login+heslo. Tzn. klient teoreticky nepotřebuje svůj vlastní certifikát. Je to méně bezpečné, ale jde to.
S OpenVPN (nebo s libtls?) se distribuuje pár skriptů zvaných "easy RSA", pomocí kterých lze generovat potřebné certifikáty. Na serveru je potřeba cerfikát a tuším soubor s "Diffie-Hellman" klíčem (nebo co to je).
Pro mě osobně asi nejnáročnější bylo zorientovat se v klíčích a certifikátech = naučit se základní chvaty s easy-RSA. Nějaké vzorové konfiguráky OpenVPN serveru a klienta mohu kdyžtak nabídnout.
Pokud by se mělo jednat o rozsáhlejší síť (větší počet mobilních zařízení) tak zvažte privátní APN. Odpadly by starosti s konfigurací a některými nectnostmi OpenVPN.
1060
Hardware / Re:Redukce mini-PCIe - USB
« kdy: 29. 04. 2018, 21:15:30 »
Wifiny do MiniPCI-e jsou takřka bez výjimky PCI-e zařízení. (Některé mají připečené taky BlueTooth rádio - to se ukáže na USB.) Takže pro Wifinu je ta redukce k ničemu.
GSM apod. modemy do MiniPCI-e jsou takřka bez výjimky USB zařízení.
V názvu produktu je jasně napsáno "with SIM 8 Pin Card Slot for WWAN/LTE Module" = má to do MiniPCI-e slotu připojený SIM slot a je to pro Wireless WAN moduly = GSM/GPRS/EDGE/WCDMA/HSPA/LTE. Totiž tyhle hračky měly původně sériový port, časem jim vypučelo USB rozhraní, nad kterým byl původně virtuální sériák, později virtuální síťovka. Postupně se objevilo několik "průmyslových de facto standardů" pro WWAN virtuální síťovky, počínaje Windows 7 už mají widle dokonce systémový "WWAN dialer" který chápe APN name a k němu login+heslo. Troufnu si odhadnout, že momentálně nejrozšířenějším standardem WWAN virtuálních síťovek je QMI od Qualcommu - protože prakticky všichni výrobci MiniPCI-e karet berou od Qualcommu čipset a základ firmwaru (hodně zapečený Linux, pokud se nepletu).
Matně si vybavuju, že jsem někde viděl webík nebo snad PPT z nějaké konference, srovnávající různá "standardizovaná" rozhraní pro práci s WWAN modemy... nedokážu to dohledat.
MiniPCI-e sloty na motherboardech taky nejsou všechny obojetné (PCI-e + USB), záleží kolik má čipset volných PCI-e a USB portů a kolik je na boardu místa (= jak velký je celý počítač). Některé sloty jsou taky mSATA-only. A některé jdou přepínat... USB 2.0 jde levně rozbočit přídavným hubem, PCI-e bridge jsou zřejmě dražší legrace.
GSM apod. modemy do MiniPCI-e jsou takřka bez výjimky USB zařízení.
V názvu produktu je jasně napsáno "with SIM 8 Pin Card Slot for WWAN/LTE Module" = má to do MiniPCI-e slotu připojený SIM slot a je to pro Wireless WAN moduly = GSM/GPRS/EDGE/WCDMA/HSPA/LTE. Totiž tyhle hračky měly původně sériový port, časem jim vypučelo USB rozhraní, nad kterým byl původně virtuální sériák, později virtuální síťovka. Postupně se objevilo několik "průmyslových de facto standardů" pro WWAN virtuální síťovky, počínaje Windows 7 už mají widle dokonce systémový "WWAN dialer" který chápe APN name a k němu login+heslo. Troufnu si odhadnout, že momentálně nejrozšířenějším standardem WWAN virtuálních síťovek je QMI od Qualcommu - protože prakticky všichni výrobci MiniPCI-e karet berou od Qualcommu čipset a základ firmwaru (hodně zapečený Linux, pokud se nepletu).
Matně si vybavuju, že jsem někde viděl webík nebo snad PPT z nějaké konference, srovnávající různá "standardizovaná" rozhraní pro práci s WWAN modemy... nedokážu to dohledat.
MiniPCI-e sloty na motherboardech taky nejsou všechny obojetné (PCI-e + USB), záleží kolik má čipset volných PCI-e a USB portů a kolik je na boardu místa (= jak velký je celý počítač). Některé sloty jsou taky mSATA-only. A některé jdou přepínat... USB 2.0 jde levně rozbočit přídavným hubem, PCI-e bridge jsou zřejmě dražší legrace.
1061
Software / Re:Linux jede podivně (brutálně) rychle oproti Win 10
« kdy: 29. 04. 2018, 20:56:40 »
Já kdybych nebyl na Windows závislej pro některé oblasti své práce, tak mě z Linuxu nikdo nedostane. Přesně protože v Linuxu není antivirák, není v něm Windows Update, nefunguje v něm 99% malwaru.
Pod windows bych se bez antiviráku neodvážil fungovat natrvalo. Takže pak výkonný procesor, SSD a 8 GB RAM slouží vlastně základním životním funkcím :-(
Pod windows bych se bez antiviráku neodvážil fungovat natrvalo. Takže pak výkonný procesor, SSD a 8 GB RAM slouží vlastně základním životním funkcím :-(
1062
Server / Re:Jaký software na VPN „router“?
« kdy: 06. 04. 2018, 15:57:15 »
Pokud nejsou vysoké nároky na průchodnost, tak OpenVPN. Minimum nervů "proč to nejede, proč tahle konfigurace nefunguje". Flame war OpenVPN vs. IPSec jsem už párkrát absolvoval, argumenty pro IPSec znám.
Zdejší debata mě poňoukla, abych otestoval průchodnost mezi dvěma lokalitami. Bohužel je na jedné z nich ohavný rate-limit na 10 Mbps (symetrický) takže jsem nezměřil, kolik by to dalo samospádem. Takhle jsem pomocí FTP změřil 8 Mbps a oba routery se flákaly (quad-core BayTrail Celeron J1900 měl jedno jádro vytížené asi na 10%). Pravda je, že slýchám stesky, že OpenVPN ani to jedno jádro nevystropuje, že má bottleneck někde jinde...
OpenVPN je zřejmě jednovláknová. Pokud by byl zájem na centrále rozložit zátěž na víc jader, dá se ručně spustit dvě a více instancí a satelitní "klienty" mezi ně ručně rozhodit. Konfigurace a spouštění démona pak dá trochu práce navíc. Ale pokud byste začal kopírovat data proti centrálnímu storagi ve více streamech, možná by to zase zůstalo viset na random IOPS točivých disků.
Já třeba míval dvě instance OpenVPN kvůli redundantním uplinkům. A nad tím Quagga jela dynamický routing... Hezké to bylo, ale teď na optice u slušného ISP už redundanci nepotřebuju.
Zdejší debata mě poňoukla, abych otestoval průchodnost mezi dvěma lokalitami. Bohužel je na jedné z nich ohavný rate-limit na 10 Mbps (symetrický) takže jsem nezměřil, kolik by to dalo samospádem. Takhle jsem pomocí FTP změřil 8 Mbps a oba routery se flákaly (quad-core BayTrail Celeron J1900 měl jedno jádro vytížené asi na 10%). Pravda je, že slýchám stesky, že OpenVPN ani to jedno jádro nevystropuje, že má bottleneck někde jinde...
OpenVPN je zřejmě jednovláknová. Pokud by byl zájem na centrále rozložit zátěž na víc jader, dá se ručně spustit dvě a více instancí a satelitní "klienty" mezi ně ručně rozhodit. Konfigurace a spouštění démona pak dá trochu práce navíc. Ale pokud byste začal kopírovat data proti centrálnímu storagi ve více streamech, možná by to zase zůstalo viset na random IOPS točivých disků.
Já třeba míval dvě instance OpenVPN kvůli redundantním uplinkům. A nad tím Quagga jela dynamický routing... Hezké to bylo, ale teď na optice u slušného ISP už redundanci nepotřebuju.
1063
Bazar / Re:HW RAID řadič PCIe 4xSATA a více
« kdy: 25. 03. 2018, 21:35:59 »
Osobně mám rád Arecu. Přijde mi že má nejkomfortnější ovládání. Čtyřportový model bude mít onboard Ethernet s lehkotonážním webovým GUI. Pokud klekne řadič, data z disků přečte libovolná mladší Areca. Podpora disků >2TB není problém snad ani u staršího EOL hardwaru (ARC11x0 series) pokud flashnete poslední firmware.
Anebo se vykašlat na HW RAID a postavit to v Linuxu třeba na MD RAIDu.
Anebo se vykašlat na HW RAID a postavit to v Linuxu třeba na MD RAIDu.
1064
Sítě / Re:Hardware pro linuxový router
« kdy: 23. 03. 2018, 09:26:45 »Kup si neco PC like = s CPU id intelu nebo amd, a nemusis resit ani vykon ani problemy s tim jak tam to ci ono nainstalujes/prekompilujes/...Nebo pokud to chcete rozumně chlazené, tak nějakou ITX desku s Atomem BayTrail a výš.
Trebas neco na bazi Intel NUC pokud to chces maly.
Já jsem před pár lety řešil několik takových strojů deskou GA-J1900N-D3V (BayTrail), která už je EOL. A dával jsem je buď do velkých ATX šasi (jako servery) nebo jednu do tohoto šasi Eurocase:
http://partis.cz/index.php?gid=3161
(v mém případě včetně měniče, protože deska měla ATX 24pin napájení. Tuším jsem na tom měniči preventivně nahradil elyty solid-poly provedením a přidal jsem velký zpomalený větrák.)
Momentálně vidím v tuzemských shopech GA-N3160TN - trochu dražší, ale patřičně vybavená, Braswell už není bleeding edge takže s Linuxem nebude problém. ATOM SoC má TDP=6W/SDP=4W tj. tak akorát. Všimněte si, že má vstup 12 V dutým konektorem. Tohle prakticky stačí přitlouct na zeď dvěma hřebíky :-)
Vidím v krámě taky GA-J3455N-D3H - tohle má bohužel ATX vstup napájení a nemá to MiniPCI-e ani M.2. TDP=10W (samotný ATOM) je taky trochu vyšší. Zato má přídavný SATA řadič, takže dohromady 4 porty SATA. Tohle bych volil spíš do malého serveru nebo HTPC. Kromě toho je to relativně čerstvý Apollo Lake, nevím jak by se na to tvářil Linux (asi jak které distro).
Přímo u GB vidím dále GA-IMBLAP3350. Apollo Lake, TDP=6W/SDP=4W, MiniPCI-e + M.2, napájení 12V dutým konektorem. U nás v krámech zatím není, ale jinak je to zjevně přímý nástupce GA-N3160TN. Mimochodem tyhle dvě desky mají větší počet sériových portů, z toho dva umí 232/422/485. Touhle deskou zjevně GB konkuruje zavedeným "průmyslovým" výrobcům. (Je to psina - žeby sériový port zažíval po letech útlaku renesanci? :-)
Pokud chcete, aby to sloužilo jako WiFi AP, tak bych zvážil použití OpenWRT. Je šance dostat kernel, ve kterém nesmrdí CRDA.
A je fakt, že pokud místo toho použijete nějaký TP-Link, máte šanci dostat se asi na poloviční až třetinovou spotřebu. Akorát to nebude PCčko, budete čekat na nový release OpenWRT aby podporoval čerstvou revizi HW apod. Na PCčku tyhle problémy nejspíš mít nebudete - ačkoli onboard síťovky v novém PC HW bývají taky často pěkný výdobytek :-)
1065
Windows a jiné systémy / Re:Sekání videa ve VLC a Windows 10
« kdy: 16. 03. 2018, 07:11:04 »
i7, 16 GB RAM a přídavná grafika od Nvidie? Ten noťas je docela dělo :-)
Zažil jsem pod windowsama sekání celého systému z různých důvodů. Historicky si vybavuju "Realtek fmapp.exe" (řešení: smazat), nověji "Intel WiDi UoIP service" (řešení: stopnout a zakázat), to bylo bez ohledu na velikost RAMky. Se 4 GB RAM se to stává dneska už dost běžně - systém prostě začne krutě swapovat. Již zmiňovaný resmon většinou ukáže viníka (proč došla RAMka a disk seekuje jak vzteklej): Windows Update, Microsoft Malware Protection Engine, indexing engine, 3rd-party antivirák... Se 16 GB asi RAMka hned tak nedojde, ale tyhle věci prostě potřebujou šahat i na disk.
Jsou to jenom nápady. V tomhle případě je problém dost možná právě ve VLC. Mimochodem nějak jsem si tady nevšiml informace, co je to za kodek / datový tok / cbr vs vbr / rozlišení...
BTW myslím si správně, že u podobných hybridních konfigurací NVidia/Intel musí NVidia ještě kopírovat obsah výstupního framebufferu (ve své dedicated videoRAM) skrz PCI-e do okna v hostitelově sdílené paměti (pronajaté IGP) pro vlastní "řádkování" do vnějšího výstupního portu?
Zažil jsem pod windowsama sekání celého systému z různých důvodů. Historicky si vybavuju "Realtek fmapp.exe" (řešení: smazat), nověji "Intel WiDi UoIP service" (řešení: stopnout a zakázat), to bylo bez ohledu na velikost RAMky. Se 4 GB RAM se to stává dneska už dost běžně - systém prostě začne krutě swapovat. Již zmiňovaný resmon většinou ukáže viníka (proč došla RAMka a disk seekuje jak vzteklej): Windows Update, Microsoft Malware Protection Engine, indexing engine, 3rd-party antivirák... Se 16 GB asi RAMka hned tak nedojde, ale tyhle věci prostě potřebujou šahat i na disk.
Jsou to jenom nápady. V tomhle případě je problém dost možná právě ve VLC. Mimochodem nějak jsem si tady nevšiml informace, co je to za kodek / datový tok / cbr vs vbr / rozlišení...
BTW myslím si správně, že u podobných hybridních konfigurací NVidia/Intel musí NVidia ještě kopírovat obsah výstupního framebufferu (ve své dedicated videoRAM) skrz PCI-e do okna v hostitelově sdílené paměti (pronajaté IGP) pro vlastní "řádkování" do vnějšího výstupního portu?
