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 - Jakub Štech

Stran: 1 ... 19 20 [21] 22
301
Odkladiště / Re:Jak bezpečně skladujete data doma?
« kdy: 31. 12. 2019, 15:35:47 »
Já mám haldu onelinerů a jednoduchých věcí, která mi dohromady ale docela pěkně funguje :-)

Situace
NAS, několik desktopů (laptopů) s Linuxem (moje, manželky, společné atd.), několik mobilů s Androidem.

NAS je NanoPi se SATA modulem a čtveřicí 8TB disků WD Red v RAID5 (dmraid), na tom Arch Linux a různé služby (syncthing, web, gitlab, různé media servery).

Desktopy mají přímo na disku LUKS, v něm je jeden btrfs oddíl, v něm jako subvolumes všechno ostatní. Jediná nešifrovaná část je Grub (efi loader), který je podepsán secure boot klíčem. Tj. defaultní instalace Manjara :-)

Mobily mají tovární Android šifrování, klíč to nějak odvozuje z pinu, za provozu se ale odemykají otiskem prstu s výjimkou mobilu dcery, která je ještě moc malá a tak odemyká tlačítkem.

Synchronizace
Na všech strojích běží Syncthing, který synchronizuje určité adresáře tak, aby byl udržen globální stav. Jde hlavně o fotky (když udělám fotku na mobilu a konektivita je dostačující, je během několika sekund zapsána na NAS), galerii (dáváme tam ty vytříděné fotky s metadaty, které chceme mít po ruce), hudbu, různé další misc adresáře. Máme jich hodně - něco společné, něco má každá osoba jen mezi svými stroji.

Zálohování
Stroje s Linuxem (včetně NASu) jedou všechny na btrfs. Každých 15 minut se spouští cronjob (nebo teda systemd.timer), který udělá btrfs snapshot uživatelských subvolumes (ne třeba rootfs, ten je většinou bez změn). Tím se chráníme před situacemi, kdy si třeba něco omylem smažeme. Jednou za 4 hodiny se spustí služba, která vezme poslední snapshot a snapshot starý 4 hodiny, vypočte mezi nimi deltu (btrfs send), a tu komprimovanou pomocí zstd umístí do k tomu určenému Syncthing adresáře. Od tama se to příležitostně samo odleje do NASu, kde to systemd.path trigger sebere a přesune do archivu (čímž se uvolní místo na zálohovaném počítači). Patnáctiminutové snapshoty promazává další timer - u mě je to nastaveno na 3 dny, drahá polovička si to tam drží snad měsíc.

Párkrát do roka nechám (zatím ručně) udělat plný btrfs send místo delty, aby tam těch delt nebylo moc. Rekonstrukce disku ze stovky na sebe navazujících delt totiž může trvat i den :-) Staré pak ručně promažu tak, aby byl rollback tak 3 měsíce.

Na Androidu je automatické zálohování na facku (pokud vše nesvěřím Googlu, což jak asi tušíte nechci). Spíš se k tomu chováme tak, že o to můžeme snadno přijít. Data chrání Syncthing - na NASu se to taky snapshotuje, takže kdybych si omylem něco smazal, nejspíš to půjde obnovit. Aplikace s nastavením nepravidelně (ručně) zálohujeme přes Titanium Backup (opět do Syncthing adresáře, takže to nateče na NAS).

TODO
Chybí mi geograficky oddělená záloha, další NAS u rodičů nebo někde, kam bych nechával replikovat data (opět jen přidáním node do Syncthing). Před selháním jednoho disku mě chrání raid, ale uvažuju o nějaké explicitnější variantě, dedikovaný disk nebo pole na "vlažnou" zálohu.

302
Hardware / Re:V notebooku nefunguje jiný LVDS monitor
« kdy: 31. 12. 2019, 00:51:27 »
"LVDS" (low-voltage differential signalling) není specifikace konkrétního rozhraní, je to jen fyzická vrstva (jako např. RS-485 Vám řekne, co tam je kdy za napětí, ale ne, jestli po těch drátech běhá Modbus, Bacnet, Profibus, ...).

LVDS jen specifikuje chování jednoho páru diferenciálních vodičů. Ne kolik jich tam je, a už vůbec ne pinout :-) takže je možné (a podle popisovaného chování velmi pravděpodobné), že jste tam prostě šlusnul nějakou napájecí větev do země a mašina vypnula.

V praxi se po tom u displayů nejčastěji provozuje FPD-Link/FlatLink, který je v několika nekompatibilních verzích.

303
Distribuce / Re:Dvakrát mountnutý stejný disk
« kdy: 19. 12. 2019, 01:03:00 »
Na 100 procent to nemusí být bind:

Kód: [Vybrat]
# mkdir A B C D
# for a in A B C D
for> do
for> mount /dev/sda1 $a     
for> done
# mount | grep sda
/dev/sda1 on /run/media/cabrón/storage type ext4 (rw,nosuid,nodev,relatime,uhelper=udisks2)
/dev/sda1 on /root/A type ext4 (rw,relatime)
/dev/sda1 on /root/B type ext4 (rw,relatime)
/dev/sda1 on /root/C type ext4 (rw,relatime)
/dev/sda1 on /root/D type ext4 (rw,relatime)

Linux tohle umí už velmi dlouho, bind není potřeba. Všechny mount pointy si jsou rovny, žádný není "hlavní". Každý může mít jiné mount options (v rámci možností daného fs). A klidně můžou být vnořeny, tj. lze dělat cykly v grafu :-)

304
Hardware / Re:ARM se slušným výkonem
« kdy: 12. 12. 2019, 23:52:13 »
Dobrá implementace RK3399 je v laptopu PineBook Pro, třetí série se bude dodávat na přelomu roku. Taky si to kupuju na vývoj, s dovozem do ČR to stálo $260 ($320 pakliže se některá z pijavic na Poště 120 rozhodne konat).

https://www.pine64.org/pinebook-pro/

305
Hardware / Re:256GB microSD - technologie
« kdy: 07. 12. 2019, 20:39:33 »
Dnes se hojně používá VNAND, alias Vertikální NAND flash, kde se vysoké plošné hustoty dosahuje vrstvením. Letos se začal vyrábět 128vrstvý TLC NAND flash :-) a 96vrstvý QLC.

MicroSD karty jsou "jen" eMMC flash chip zalitý do hmoty s vývody. "Jen", protože vestavění chipů a diskrétních součástek do PCB (což SD karta je) byl obrovský průlom v integraci.

Průmyslové SD karty mohou ale nemusí mít SLC médium, a nad tím ještě zpravidla ve firmwaru běží ECC nebo dokonce integrovaný raid nad dvěma oddělenými flashi. My používáme ekonomičtějsí průmyslové SD karty Apacer s technologií "SLC-lite", což je fyzicky MLC médium, ale firmware do něj programuje jen dva stavy, takže se chová jako SLC. Rychlost zápisu má ale obrovskou, podobně jako právě SLC. Možná ta vaše pomalá dělá ještě něco navíc, třeba nějaké složitější součty... nebo je poškozená?


306
Sítě / Re:Něco jako patch panel: zástrčka → zásuvka
« kdy: 04. 12. 2019, 14:59:23 »
Normální patch panel, zapojit ho jako propojku (vždycky spojit třeba horní a spodní port) a je to, ne? Starý káble tak jak jsou nacvakáš do spodní řady portů a nový patch kabely zapojíš do horní.

307
Sítě / Re:Ethernet přepěťová ochrana
« kdy: 04. 12. 2019, 14:40:28 »
Jestli na to koukám dobře, je tam baterie 8 transilů (nebo podobných TSV diod) z každé linky do země, což je v tomto případě stínění, tj. plechový kryt konektoru. Když to zapojíte vhodným kabelem (STP nebo FTP a stíněný konektor), tak to proti přepětí skutečně fungovat bude, ale jen velmi krátkou dobu. Chytne to elektrostatiku, možná indukovaný ráz způsobený bleskem, ale kdyby Vám do toho někdo pustil 230 V, tak se ty transily během zlomku vteřiny odpaří a napětí pojede dál do routeru.

308
Hardware / Re:Jak opravit nevhodný firmware
« kdy: 28. 10. 2019, 21:58:12 »
Gratuluju, hlavní je se dostat zpět do vzduchu :-) co tím řídíš?

309
Hardware / Re:Jak opravit nevhodný firmware
« kdy: 28. 10. 2019, 18:22:02 »
Jestli se dostaneš k oběma SWD pinům (data+clk), tak ti stačí přivést napájení a SWD k programátoru a flashnout tam ten správný. Programátor stojí kilo, software na Windows určitě taky nějakej existuje, kdyžtak na Linuxu se program jmenuje st-link (nečekaně).

310
Hardware / Re:Stabilita ESP8266
« kdy: 14. 10. 2019, 17:20:45 »
Overflow to není, ta zpráva se posílá skutečně po resetu (v initu runtimu), ale jak říkám, je to vlastně fuk, vypadne jeden heartbeat a pak to jede dál. Za takovou chvilku mi cirguli z kůlny neukradnou!

311
Hardware / Re:Stabilita ESP8266
« kdy: 14. 10. 2019, 13:38:03 »
Mám necelých 10 holých ESP8266 v provozu jako distribuovaný bezpečností systém. Každý node snímá pohyb kliky dveří přes spínač s vačkou a jazýčkovým relé (s magnetem) jejich otevření. Na některých je na GPIO ještě siréna a nějaká pyrotechnika (palník s petardami "kobereček").

Přes wifi jde 5 druhů zpráv: "hello" (odešle po resetu), "heartbeat" jednou za minutu (absence vyvolá notifikaci), pohyb klikou odešle "prefire", "safe" systém (de)aktivuje a v případě otevření bez deaktivace "fire" (který rozhouká všechny nody naráz). Běží na tom MicroPython, je to v provozu už několik let, "hello" zpráva přijde tak jednou do měsíce, ale důvod resetu nesleduji. Dost možná něco v MicroPython runtime, je to tam přeci jen na těsno :-)

Napájení je 3V3 lineárem, do kterého jde buď 5 V ze zdroje, nebo 8-13 V z autobaterie u off-grid pastoušky.

312
V intranetu (a nejen v něm) to jde ještě lépe - mít sdílený adresář s textovými soubory (markdown) a pomocí https://www.mkdocs.org/ nebo jiného generátoru dokumentace z toho generovat statické HTML, které pak můžete servírovat triviálně libovolným webserverem. Kromě zřejmých výhod (editovat můžete oblíbeným editorem a ne nějakou JS srágorou, snadno se to verzuje gitem, atd.) dělá mkdocs skutečně pěkně vypadající stránky, s vestavěným (statickým) fulltextovým vyhledáváním a výbornou použitelností i na mobilu.

Já to mám nasazeno mezi pár lidma tak, že adresář sdílíme pomocí Syncthing a na serveru nad tím direm bdí systemd služba s PathChanged= triggerem. Ta v případě změny souboru spustí mkdocs, takže se HTML automaticky regeneruje. Ven to servíruje nginx s auth_request validací, takže se k informacím dostanou jen přihlášení.

313
Vývoj / Re:Naučení se asynchronnímu programování
« kdy: 05. 10. 2019, 14:49:31 »
Já můžu za sebe doporučit (jako takovou ilustrující technologii) message brokery, například zeromq, konkrétně komunikační schéma push-pull, které se právě hodí k rozdělení úloh mezi velké množství asynchronně pracujících jednotek. Byl tu o tom na rootu docela pěkný seriál: https://www.root.cz/clanky/dalsi-moznosti-poskytovane-knihovnou-mq/#k12

Další náměty jsou zde: https://stackoverflow.com/questions/31248615/distributed-task-processing-using-zeromq

314
Hardware / Re:Cvakání v novém notebooku
« kdy: 04. 10. 2019, 22:10:55 »
Může to být mikrofonie keramických kondenzátorů na fázích CPU. Sám jsem to měl na Aspire Nitro se Skylake i7. Když se na ně dá napětí, změní se o pár µm jejich rozměry, a protože jsou pevně spojeny s deskou plošných spojů (které jsou dnes čím dál tenčí a tím pádem pružnější), je to velmi dobře slyšet.

Nejsilněji se to projevovalo v klidu, kdy power management vypínal a zase probouzel jádra, pokaždé to tam zacvakalo. Jako malé relé :-D

Jednoduše to můžete ověřit tak, že zakážete ACPI C-state nižší než 3 (na commandline jádra processor.max_cstate=3) a po restartu se zaposloucháte :-)

315
Hardware / Re:Je zahřívání SSD důvodem k reklamaci?
« kdy: 26. 09. 2019, 23:53:55 »
Uděláme benchmark contest? :-D

Ryzen 3700U, Samsung PM981 NVMe: 7z x win32_11gR2_client.zip  2.84s user 0.79s system 98% cpu 3.727 total

pro srovnání totéž v ramdisku: 7z x win32_11gR2_client.zip  2.61s user 0.66s system 97% cpu 3.389 total

Stran: 1 ... 19 20 [21] 22