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 - Mirek Prýmek

Stran: 1 ... 242 243 [244] 245 246 ... 618
3646
Server / Re:Na čem stavět log server?
« kdy: 16. 12. 2015, 06:16:14 »
Jedna věc je přenos logů, druhá věc je nějaká jejich analýza a třetí je zobrazování výsledků analýzy. Na tu první věc bych doporučil rsyslog+TCP transport+framing: http://www.freebsd.cz/listserv/archive/users-l/2015q4/029164.html

Řešení druhé a třetí věci záleží na požadavcích a na tom, jak moc jsi hipster a jak moc chceš spravovat logování místo správy serverů. Možný je všechno, co tady zaznělo - Logstash, Elasticsearch, Kibana, Splunk... ...a ještě asi miliarda jiných možností.

3647
Sítě / Re:PXE boot + dd
« kdy: 13. 12. 2015, 07:20:51 »
Jinak to, co psal Mirek Prýmek ohledně *BSD, tak platí víceméně s mírnýma obměnama i pro Linux. V podstatě na to můžeš použít i to OpenWRT. Nestavený DHCP server, TFTPD (obojí umí zastat Dnsmasq) plus NFS export root-u toto OpenWRT. A můžeš zkoušet. Až odladíš OpenWRT přes NFS export, tak vyzkoušíš image na disku a je to...
Velký rozdíl je v tom, že:
1. FreeBSD ani pro pxe boot nepoužívá initrd, který způsobuje problémy, zvlášť pokud chci nějak zasahovat do bootovacích skriptů
2. má přímo v initscriptech zabudovanou podporu pro bezdiskové fungování - pokud root mountnu rw, můžu normálně věci měnit na NFS serveru, pokud mountnu ro, automaticky se mi vytvoří ramdiskové /tmp, /var apod.
3. (tohle se v tomhle případě nevyužije) má bezvadně vyřešenou možnost customizace konfgurace při diskless fungování - stačí adresář /conf, v něm adresář default a pak adresáře podle mac adres pro různé speciální stroje. Cokoli je v nich, se automaticky sloučí s default konfigurací, vytvoří stejnojmenný ramdisk a namountuje na stejné místo v rootu. Takže tímhle způsobem můžeš třeba u některých strojů překrýt klidně /bin, kdybys to potřeboval :)

Nevýhodou je pomalejší boot (zvlášť oproti systemd) a menší podpora hw.

3648
Sítě / Re:PXE boot + dd
« kdy: 12. 12. 2015, 21:28:32 »
To neni tak uplne pravda, on se ten image da namountit a pak si s tim delat cokoli treba na urovni FS ;)
Jo, můžeš třeba pak na úrovni FS použít ten ntfsclone, co's mohl použít rovnou :)

3649
Vývoj / Re:[RPi] GUI pro zobrazení hodnot ze souboru na LCD
« kdy: 12. 12. 2015, 19:08:21 »
Za pár týdnů pouštím do malosériové výroby radiátorové hlavice které mají HTTP API + MQTT/websocket klienta
Tybrďo, to přesně potřebuju! Můžeš dát víc info?

3650
Odkladiště / Re:Priatelka a IT
« kdy: 12. 12. 2015, 17:45:03 »
Ale v tom Scratchi by mohla časem dělat i výukové hry pro předškolní děti, to je zatraceně těžká věc, jenže s jejím oborem by pro to mohla mít předpoklady!
Tohle je výborná myšlenka! Pokud je na té pedagogice proto, že ji to zajímá a baví, a podařilo by se jí to s IT propojit, byla by to bomba. Programovacích her pro děcka, který ještě neumí číst a psát, je zoufale málo, myslím, že to je docela díra na trhu a pěkná hra pro tablety by určitě nějaký drobný peníz hodila.

Jinak na okraji IT existují joby, kde jsou vyloženě holky, třeba v IBM různé ty podpory, administrativa a tak. Některé z nich jsou docela slušný, zbytek je ale nevděčná otročina (helpdesk apod.).

3651
Sítě / Re:PXE boot + dd
« kdy: 12. 12. 2015, 17:25:07 »
Image bude mit cca 40MB (je to OpenWRT) a po prvnim startu si sam zvetsi root partition podle velikosti disku :) takze dd by melo stacit,
Aha, tak to je jiná, v tom případě je určitě dd správná volba. Pak to teda asi chceš hrnout na nějaký kdovíjaký zařízení s kdovíjakou platformou, tak to by BSD nemusela být dobrá volba.

Pokud bys z nějakýho důvodu cestou FreeBSD nakonec chtěl jít, tak se mi určitě ozvi - už jsem to používal, takže vím, jak na to, a potřebuju to tak jako tak kvůli čemusi oživit, takže přesnej návod můžu sepsat, případně i dát ke stažení všechny potřebný soubory. Akorát to teď pro mě není úplně priorita číslo jedna, takže nemůžu slíbit, že by to bylo zítra ;)

3652
Vývoj / Re:[RPi] GUI pro zobrazení hodnot ze souboru na LCD
« kdy: 12. 12. 2015, 17:16:13 »
Jo a ještě k tomu browseru v kiosk režimu: mělo by stačit použít Firefox, spouštět ho z nějakýho skriptu, kterej ho při pádu případně restartne, nastavit výchozí stránku na to, co potřebuješ, nainstalovat doplněk https://addons.mozilla.org/cs/firefox/addon/r-kiosk/ a v profilu dát do souboru user.js potřebný volby. Mně zatím stačilo:
Kód: [Vybrat]
user_pref("rkiosk.navbar",false);
user_pref("browser.fullscreen.autohide",true);
user_pref("app.update.enabled",false);

3653
Vývoj / Re:[RPi] GUI pro zobrazení hodnot ze souboru na LCD
« kdy: 12. 12. 2015, 17:02:53 »
433MHz moduly za 40Kč mam, není to hitparáda (spolehlivost a dosah), ale vzhledem k NRF24L01, který mam taky, je to luxus (dosah). Tyhle kravinky mě zklamaly. Pravda, dal jsem za těch asi 10 kusů všeho cca 250Kč, technicky jsou funkční, ale těžko využitelný. Obzvlášť ne na takovou aplikaci, tady potřebuju jistou spolehlivost...
U těch NRF mě dosah taky zklamal a jedinej způsob, jak se mi ho podařilo dostat na použitelnou úroveň, je právě ten mesh. U heterodynů je rozumnej dosah hodně otázka softwaru - je potřeba nízká rychlost, krátká zpráva, nějaký checksum, dost opakování a v případě potřeby i potvrzování. S tímhle vším je to pak v pohodě použitelný. Spínám tím zásuvku za pár šupů ze supermarketu (něco takovýhodle http://www.nej-ceny.cz/produkty/original/631429.jpg) přes celej barák. Výhodou je, že na všechny ty potřebný serepetičky, se kterýma to má použitelnej dosah, jsou pro Arduino knihovny.

Ještě se mně hrozně líbila tahle vychytávka: vzít levnou meteostanici taky ze supermarketu a přes 433 si na ni posílal jakýkoli čísla emulací dalšího sensoru :) Zatím jsem neměl čas to vyzkoušet, ale jako nápad mi to přijde parádně vychytralý :)

3654
Sítě / Re:PXE boot + dd
« kdy: 12. 12. 2015, 12:41:39 »
Tak me napada, ze kdyz v tech strojich je lokalni disk, jestlipak umi umet bootovat ze site? Ze by tam jako vyrobce prihodil bootrom, protoze mel dobrou naladu?
Bootování ze sítě přes PXE umí úplně každý současný počítač a úplně každá současná síťovka má PXE rom.

3655
Vývoj / Re:[RPi] GUI pro zobrazení hodnot ze souboru na LCD
« kdy: 12. 12. 2015, 12:03:51 »
doporučit Elixirový webový framework
...a když už jsme u toho, měl bych si přihřát polívčičku :)

https://github.com/mprymek/fulight

3656
Vývoj / Re:[RPi] GUI pro zobrazení hodnot ze souboru na LCD
« kdy: 12. 12. 2015, 11:59:54 »
Koukám, že Saky došel k prakticky stejným závěrům a technologiím jako já, to potěší :) Drobný poznámky:

primárně pak MQTT client [...] Ten má oproti API výhodu v trvalém spojení
Kdyby náhodou trvalé spojení u MQTT bylo problém (např. pokud chci MCU vypínat kvůli šetření energií a spojení se mi nechce pokaždé rušit a znovu navazovat, takže by mi spadlo samo), dá se použít právě ta verze MQTT-SN, která s "mizením" klientů počítá.

Navíc díky trvalému spojení  na serveru vidím, zda je periferie online a dokáži na rozpadnutí spojení reagovat ihned na obou stranách.
Poznámka pro kolegy s MQTT méně zkušené: Na tohle se výborně hodí použít MQTT last will: při startu pošlu na topic /hebla/heblo1/live třeba "1" s nastaveným flagem retained, last will topic nastavím na /hebla/heblo1/live a last will message na "" (prázdná zpráva). Tím mám automaticky zabezpečeno, že na /hebla/+/live dostanu v každém okamžiku seznam hebel, který jsou skutečně živý. Last will mechanismus mi zaručí, že i při nějakém nekorektním odpojení klienta se tam dostane ta správná hodnota (prázdná zpráva).

Prázdná zpráva způsobí, že se retained message na tom daném topicu na brokeru smaže, takže zprávy z /hebla/+/live nemusím vůbec parsovat, stačí mi si z topicu vyparsovat id hebla. A navíc můžu mít i "efemerní hebla" - tj. klienty, kteří použijí náhodně generované ID a jenom na chvilku. Protože se topic /hebla/RANDOM_ID/live po odpojení automaticky smaže, nemusím se bát, že by mi počet topiců na brokeru rostl.

Další výhodou je pak přímé spojení pomocí WebSocket
Velice vřele můžu (nejen) pro programování s WebSockety doporučit Elixirový webový framework www.phoenixframework.org - je naprosto skvělý, brutálně rychlý a s websockety se tam pracuje nádherně (a díky Elixiru/Erlangu je to úplně přirozený, včetně nějakých asynchronních událostí apod.).

Momentálně kromě topení pracuji na OTA aktualizacích
Dobrá připomínka! Na to je taky vhodný myslet, zvlášť pokud počet sensorů roste. Pro Arduino/Atmel existuje několik způsobů - Atmel na to má docela dobře připravený návrh, kód bootloaderu je od vlastního programu úplně oddělený, existují různé bootloadery, já jsem třeba používal TFTP.

3657
Sítě / Re:PXE boot + dd
« kdy: 12. 12. 2015, 09:27:39 »
Klonovat pomocí dd je při současných velikostech disků dost hloupost. Navíc takový image nemůžeš nahrát na libovolný disk, musel bys dodržet velikost disku. Určitě chceš použít ntfsclone (Windows) nebo tar/dump (unixoidní systémy).

Nejpohodovější PXE bootování, který jsem zatím viděl, má FreeBSD. Potřebuješ:

1. přidat 3 řádky do konfigurace DHCP serveru
2. na TFTP server umístit jeden soubor (pxeboot)
3. přes NFS vyexportovat root (nemusíš FreeBSD instalovat, stačí rozbalit distribuční soubory base a kernel z ftp://ftp.cz.freebsd.org/pub/FreeBSD/releases/amd64/amd64/10.2-RELEASE/)
4. při prvním bootu mít ten NFS share rw a doinstalovat potřebné balíky (viz freshports.org - ve tvém případě to asi bude jeden příkaz "pkg install fusefs-ntfs")
5. nastavit spuštění ntfsclone po startu (nejspíš budeš chtít upravit /etc/ttys nebo /etc/rc.local)
6. pokud chceš i vytvářet partitiony, FreeBSĎácký gpart je příjemný, dobře skriptovatelný a nejspíš umí všechno, co bys mohl potřbovat (GPT i MBR, zapisování bootsektorů)

Pokud bys FreeBSD chtěl použít, rád poradím s detaily. Pokud bys chtěl Linux, celkem bych se přimlouval za TinyCore, ten je rozumně velký, celkem čistý a pochopitelný a dá se docela slušně upravit.

3658
Vývoj / Re:[RPi] GUI pro zobrazení hodnot ze souboru na LCD
« kdy: 12. 12. 2015, 08:43:30 »
6. Linková vrstva
Pro hnidopichy: tady mělo být spíš "linková a fyzická vrstva" :)

3659
Vývoj / Re:[RPi] GUI pro zobrazení hodnot ze souboru na LCD
« kdy: 12. 12. 2015, 08:35:26 »
Musíš míň hrát a víc se učit programovat!!! :)))

Hele, termostat se dá udělat i úplně na koleni amatérsky, ale pokud do toho jdeš úplně bez znalostí, připrav se, že narazíš na spoustu slepých uliček a celkově ti to bude docela dlouho trvat, než to celý rozchodíš tak, abys byl spokojenej. Dost bych doporučil sledovat přednášky, články a blog Petra Stehlíka, protože to je člověk, kterej je v elektrotechnice amatér, hraje si s tím pro radost a píše postřehy, které se perfektně hodí pro amatéry. Spoustu slepých uliček ti ušetří.

Než s tím začneš, doporučoval bych nepodcenit návrh. Celkově ti s tím neporadím, ale měl bych pár tipů ke zvážení:

1. RPi je dobrý na to, že tam můžeš použít plnotučné technologie, které znáš (jako třeba ten X-server, klasický www server, balíčkovač, python atd.) - tj. můžeš tam rychle rozjet poměrně složité věci. Ale máš tam podstatně složitější software stack a hardware samotný je dělaný primárně pro nízkou cenu. Takže se stabilitou to nemusí být kdovíjaký a jenom těžko na RPi můžeš dosahovat nízké latence (kdybys třeba něco chtěl řídit rychlostí jánevím nad sto kilohertz, už budeš mít asi docela problém). Čili RPi bych rozhodně nepoužil na řízení něčeho, co může způsbit škodu - pokud např. ten kotel nemá nějakou vnitřní logiku, která by ho chránila v situaci, kdy se RPi nějakým způsobem zblázní. Třeba můj kotel má spínání, ale i když bys kontakt trvale sepnul, nebude topit pořád - občas se vypne sám nezávisle na tom, co mu radí ovladač. To si určitě předem ověř.

2. Druhá nevýhoda RPi je (na embedded zařízení) poměrně vysoká spotřeba. Prostě budeš k tomu potřebovat síťový napaječ a tímpádem zásuvku, což může být otravný. Mít doma jedno, dvě RPi je v pohodě, ale deset jich doma mít nechceš.

3. Proto se vyplatí si předem promyslet, jestli ti aspoň na některé části systému nebude stačit menší deska. Nezatracuj Arduino, je to perfektní věc a spoustu věcí zvládne naprosto dostatečně! S trochou snahy ho můžeš provozovat i několik měsíců (až dva roky) na baterku a je parádně levný (nejmenší desky z Číny už někde od šedesáti korun). Jediná nevýhoda ATmega328 (čip majoritního typu Arduina) je, že moc nezvládne šifrování.

4. Hodně zajímavá možnost je taky ESP8266. Brutálně levná a s wifi "zadarmo". Taky ale pozor na stabilitu!

5. Komunikační protokol: silně bych doporučil nevymýšlet nic svýho a použít MQTT. Je to fantastická věc, výborně navržená, jednoduchá, ideální pro mebedded zařízení, ale zároveň nekonečně rozšiřitelná. Pokud by i MQTT bylo z nějakého důvodu moc, použít MQTT-SN, které je speciálně navržené pro sensorové sítě.

6. Linková vrstva: wifi je dobrý, pokud to chceš rozjet rychle a moc se s tím nepárat. Vede ale k větší spotřebě, vyšší ceně (pokud nepoužiješ ESP8266) a můžeš mít problémy s šifrováním. Lepší varianta pro jednodušší nekritický věci (měření teploty apod.) jsou nelicencovaný pásma 433 a 868MHz. Na ně se dá použít buď jednoduchý levný vysílač: http://www.aliexpress.com/item/1Lot-1-pair-2pcs-Best-prices-433Mhz-RF-transmitter-and-receiver-link-kit-for-Arduino/32318951712.html který neumí fakt nic jinýho než vysílat nebo přijímat (a to ještě s velkou chybovostí) nebo inteligentnější nRF24L01 nebo nRF905 které mají zabudovanou docela pokročilou logiku - např. umí (aspoň to nRF24L01, u druhýho si nejsem jistej) samy o sobě rozběhnout MESH síť - t.j. automaticky posílat pakety "jeden přes druhýho, na kterýho vidí" správným směrem. Je to hodně dobrá volba v případě, že chceš mít sensorů víc (např. měřit teplotu v každém pokoji). Hlavně proto, že dosah je trochu horší než u té první, stupidní varianty. Zvlášť u desek bez externí antény, s těma mám zkušenost, že mají dosah spíš jenom přes jednu stěnu, víc jsem uspokojivě nedosáhl. Ten jednoduchý vysílač zase v pohodě propálí celej barák.

7. Řešení UI webem bych vůbec nezatracoval! Web rozhodně nemusí být škaredší než nějaký jednodochý UI toolkit. Spíš bych řekl, že naopak. A máš tam zadarmo dálkový přístup. Pokud použiješ nějaký lokální prográmek s UI toolkitem, stejně časem zjistíš, že bys to chtěl ovládat vzdáleně třeba z práce, a stejně skončíš u webu :) Takže myslím, že než hledat vhodný UI toolkit, možná by se vyplatilo trochu zainvestovat do studia moderních webových technologií (různé ty jQuery, D3 apod.) Jako "terminál" bys pak mohl použít nějaký levný tablet z Ebaye, na kterém by jel jenom prohlížeč.

8. Pokud tohle fakt určitě nechceš, na jednodušší terminál by se mohlo hodit STM32F429, které má zabudovaný dotykový displej. Ale počítej s o hodně větší pracností - budeš si tam muset rozjet nějaký RTOS a grafickou knihovnu. Práce s toolchainem a knihovnami není tak pohodlná jako u Arduina, je to občas trochu porod. Mně osobně, když jsem si s tím trochu hrál, se docela líbila kombinace ChibiOS+uGFX.

...uff, to je román tyvole, už budu radši končit :)

3660
Server / Re:Yubikey – přidání kódu za heslo
« kdy: 06. 12. 2015, 13:28:15 »
Nekde jsem cetl, ze Youbikey ma jiny zpusob. Uzivatel prida overovaci kod na konec hesla a PAM modul si ho odrizne.
Yubikeys je několik druhů a různé druhy podporují různé protokoly. Ten nejlevnější (jediný cenově zajímavý) podporuje jenom U2F, což dost zajímavě navržený protokol, ale jeho použitelnost je zatím docela omezená, i když se dá doufat, že se časem rozšíří hlavně díky ohlášené nativní podpoře ve Windows 10. Není to ekvivalent OTP i když to tak z nějakých krátkých popisů může vypadat, a k použité jinému než v podporovaném browseru vyžaduje netriviální podporu v software [1]. Vyšší (a podstatně dražší) verze Yubikey pak mají klasické OTP.

Takže pokud bys uvažoval nad Yubikey, tak si předem dobře nastuduj, jestli to opravdu chceš a jestli to opravdu umí to, co si myslíš.

[1] viz https://plus.google.com/+MiroslavPrymek/posts/LnckaHqGLBC

Stran: 1 ... 242 243 [244] 245 246 ... 618