Příspěvky

301

Odkladiště / Shodnost IP adres po zřetězeném resolvování ?-PTR-A-?

« kdy: 31. 12. 2021, 11:03:27 »

Pokud provedu následující řetězec resolvování:
?A  : stranky.cz --> 1.2.3.4  ## stranky.cz už nás dál nezajímaj
?PTR: 1.2.3.4 --> shrek.hostmonstr.net (nebo gamma.noshorozec.com třeba taky 32-43.mástr.cz , to je celkem jedno)
?A  shrek.monstr.net: OTÁZKA
Logicky se nabízí, že by se to mělo rovnat. Ale jsou stavy, kde vyjde odlišná adresa (nemyslím teď chybu, ale schválně). A konečně, může se stát, kdy vyjde odlišná adresa (vlivem chyby). Pořád nějak nevím, kdo přesně je zodpovědný (u koho leží, za kým jít) PTR záznamy (může to být i klidně zóna 3.2.1.in-addr.arpa, tam se vloží "4" IN simpson.magnum.cz).

302

Sítě / Re:Zkušenosti s nefunkčním powerline

« kdy: 30. 12. 2021, 21:02:26 »

Také jsem s tím laboroval. Protože to fakt vypadalo že nenajdu způsob propojení dvou míst.

Podmínka: chtěl jsem něco s konektorem pro 1GBASE. Tudíž jsem vyřadil z  nabídek modely s avizovanou rychlostí 100Mbps (100BASE). Už jen kvůli tomu, že 100Mbps by promě bylo no-go. 

1 Vyzkoušený byl nějaký TPLINK PA4020 nebo něco takového. Označení AV600 Bohužel šlo o kombinaci klamavé reklamy a špatného popisku. Ten šmejd měl 100BASE konektory Osobní odběr, ale zjistil jsem to ihned doma po rozbalení že tohle ne.  Ale aspoň jsem to vyzkoušel, 100Mbps to dávalo  spolehlivě i když jsem to navrstvil za prodlužku a spotřebiče na větvi... Cena cca 1200


2. Nějaký Mercury (francouzský) taky 1500 Kč. Mělo to umět AV1200 a mělo to aspoň gigabitové konektory. Zklamání: max. rychlost asi 200-300 Mbps.

Nakonec jsem po půl  roce bádání našel způsob jak protáhnout CAT8 kabel (30 metrů za 300 od Karla). A 10Gbit je k nezaplacení.

Resume: tady dvojnásob nevěřit reklamním kecům a číslům.


Je třeba mít respekt, že někdy prostě kabel neprotáhnete a nedosáhnete vysněného ideálu, optiku až do spižírny. Sám jinde třeba mám páteřní přípojení wifi adaptérem 802.11n s jednou anténou.

303

Hardware / Re:Kapacita baterky neodpovídá

« kdy: 21. 12. 2021, 17:59:04 »

Mě se nezdá ty samotné údaje v tabulce. Už jen to, že to tam je na "disjunktní navazující intervaly"  0-15, 16-25, 26-45 mi přijde divné.

Chápal bych, kdyby tam bylo třeba aspoň 0-45 pro 0.1C. Vždyť přece teplot platící pro nízký proud musí být obsažené v rozsahu pro vyšší teplotu.

Podle mé představy : Čekal jsem, že tam bude nějaký třeba nějaký interval kolem 25°C (klidně i se mírně posunující), který bude mít s rostoucím proudem nižší šířku :
1C: 22-28
C/2: 17-36
C/4: 13- 45

Ale zase je to možná ošemetné, rozebírat takhle "jednu tabulku odněkud"

A trochu hodně  se mi to zdá v rozporu s "špatný vlivem" vysokých teplot na baterie.

304

Hardware / Re:Kapacita baterky neodpovídá

« kdy: 21. 12. 2021, 13:29:25 »

cat battery/uevent hlásí Li-poly

Btw: Nabíjení lithiových baterií by se mělo odehrávat za vyšších teplot, třeba 30 °C. Těch 13 °C to máš v ledničce ne?

Na chodbě


Ty teploty mě překvapily. Já myslel že nad 30 neni dobra teplota pro baterky. Nebo je rozdil u -ion a -poly v tomto?Nemaji zde chybu?

Kód: [Vybrat]

Charge current

    Max 0.1C(0~+15℃)
    Max 0.5C(+16~+25℃)
    Max 1C (+26~+45℃)

čekal jsem obrácenou závislost (a taky divné je rozdělení na intervaly)napadá mě pro vyšší proudy ohřát aby povolil separátor (=snížil vnitřní odpor jakomáslo, med), ale asi tam bude nějaká nevýhoda co třeba paralel.odpor=samovyvijeni? (Teply ned začne sám ukapávat)

305

Hardware / Re:Čím čistit matnou obrazovku?

« kdy: 21. 12. 2021, 11:57:26 »

Když se zeptám laicky, měla vy okena vadit? Předpokládám že jde o stejný materiál ale jen s "hrubou strukturou" a žádná antiROFLexní vrstva tam není (na matné - jaký význam)

306

Hardware / Kapacita baterky neodpovídá

« kdy: 21. 12. 2021, 11:48:31 »

Na smartfounu bych měl mít 4Ah baterku,přesto ale systematicky delší dobu pozoruji že podle výpisu nabíjení má spíš poloviční kapacitu (srovnáním proudu a procent nebo za nějakou dobu)

Telefon mám 2 roky (model starý 2.5 roku) , používal se ale poslední rok jenom. Baterku netůruji, nabijim v chladu, proudem do 1.5A (max umí 2.3) a ne na 100% (většinou)

Je to nějaká chyba měření nebo to skutečně má menší kapacitu? A je to reálné že takto by se snížila?

Paradoxně nepozoruju že by výdrž telefonu byla nějak nízká.

Kód: [Vybrat]

# 1%  ... 40mAh , řádek refresh 120s
#údaje z /sys/class/power/battery/ : voltagenow currentnow temp capacity

3700 mV   13°   -256 mA   50%
 4183 mV   14°   1104 mA   54%
 4194 mV   15°   1097 mA   56%
 4214 mV   15°   1145 mA   59%
 4226 mV   15°   1147 mA   61%
 4166 mV   16°   585 mA   64%
 4250 mV   16°   1158 mA   67%
 4260 mV   16°   1157 mA   70%
 4268 mV   16°   1141 mA   72%
 4279 mV   16°   1141 mA   74%
 4289 mV   16°   1149 mA   76%
 4299 mV   16°   1146 mA   78%
 4307 mV   16°   1138 mA   80%
 4317 mV   16°   1138 mA   82%
 4326 mV   16°   1132 mA   83%
 4335 mV   16°   1130 mA   85%
 4346 mV   16°   1134 mA   86%
 4356 mV   16°   1122 mA   87%
 4362 mV   17°   1131 mA   89%
 4374 mV   17°   1119 mA   90%
 4388 mV   17°   1111 mA   91%
 4388 mV   17°   1043 mA   92%
 4389 mV   16°   977 mA   93%
 4389 mV   16°   921 mA   94%
 4389 mV   16°   874 mA   95%
 4389 mV   15°   825 mA   96%
 4322 mV   15°   279 mA   96%
 4388 mV   16°   785 mA   97%
 4388 mV   17°   788 mA   97%
 4388 mV   17°   772 mA   97%
 4389 mV   17°   743 mA   97%
 4389 mV   17°   691 mA   97%
 4389 mV   16°   645 mA   97%
 4389 mV   16°   604 mA   97%
 4389 mV   15°   566 mA   98%

Jednoduchým výpočtem se zjistí: 4000/100/120*3600=proud 1200mA na jedno procento (formulace technicky trochu tahá za uši) ... Můžete srovnat jestli sedí proud a přírustek procent


S hysterzí ukazatele % počítám, údaje beru z prostředka (tedy ne hned po zasunutí céčka) a taky ne hned sousední řádky. Opakuji, že to je opakované pozorování

307

Sítě / Re:Udělá tento řádek z full cone NATu symetrický? --snat persistent, fully-rando

« kdy: 13. 12. 2021, 20:24:23 »

Sice jsem si četl iptables-extensions mana, ale nejsem moc moudrý z voleb persistent (u SNAT jen) a fully-random(ized)

persistent nemá smysl řešit, když --to je jedna IP ?

fully-randomized se liší oproti random, že používá (pseudo)generátor namísto hashe? Nebo liší se sekvence nějak? (často je vidět, že čísla portů rostou/klesají o jedničku nebo dvojku)

308

Sítě / Udělá tento řádek z full cone NATu symetrický?

« kdy: 13. 12. 2021, 11:47:49 »

Je pravda, že v linuxu pomocí přidání jednoho řádku do iptables se stane z full cone natu symetrický?

Kód: [Vybrat]

# iptables -S -t nat
-A POSTROUTING -o eth0 -j MASQUERADE --random # existující NAT maškaráda, (šlo by nahradit -J SNAT 77.256.123.123)
-A PREROUTING -i eth0 -j DNAT --to-destination 192.168.10.250 # přílepek. 

Ze zajímavosti, u toho přílepku se musí určit vnitřní IP, ač je logické, že to musí být adresa toho stroje na tom vnitřním rozhraní. Nebo by to šlo bez toho?
A hraje roli nevinná volba --random?

309

Vývoj / xargs - použití n-tic položek do jednoho příkazu

« kdy: 13. 12. 2021, 11:22:28 »

Dá se použít xargs k nějakému takovému výsledku?

Kód: [Vybrat]

# echo 1 2 3 4 5 6 | xargs -d " " comm -a % -b %
#případně
# echo -e "1 \n2 \n3 \n4 \n5 \n6\n" | xargs comm -a % -b %
#nebo ještě lépe
# echo -e "1 \n2 \n3 \n4 \n5 \n6\n" | xargs comm -a %2 -b %1
#vypis prvnich dvou 
comm -a 1 -b 2 , comm -a 3 -b 4, comm -a 5 -b 6
#vypis "nebo ještě lépe"
comm -a 2 -b 1 , comm -a 4 -b 3 , comm -a 6 -b 5

#prozatím vím jen o:
# echo -e "1 \n2 \n3 \n4 \n5 \n6\n" | xargs -n 2 comm -a -b  # ===> Parametry se přidají na konec příkazu
# echo -e "1 \n2 \n3 \n4 \n5 \n6\n" | xargs -I _ comm -a _  -b  _  # ===> výsledkem ale je comm -a 1 -b 1 atd.

Četl jsem man, klíčové jsou volby -n, -L -x ,- d -I. Ale volba I podle nápovědy implikuje -L 1 a -x. Ale i tak jde určit -I, a -L/-n.
Mimochodem, jaký je rozdíl mezi volbou -n a L? Nenarazil jsem na to. Hraje u xargs taky rozdíl když jsou záznamy oddělené mezerou nebo novým řádkem? (Jaké vím, že -vlastní oddělovač jde určit -d, ale právě v man se něco píše od space separated arguments myslím.)


Použilo by se na takovéhle zadání třeba sprintf nebo zřetězení xargs | xargs?

310

Odkladiště / Re:Je legální používat služby jako je Sidify / Tidabie / DeeKeep?

« kdy: 10. 12. 2021, 22:44:28 »

Proč by nebylo?  Hudbu máte, Soubory máte, služby pouští hudbu a můžete s nima naložit dle libosti. Stejně jako youtube-dl

Stejně jako jisté doplňky do prohlížeče, který zpracovají obsah co vám jako tak pošle server a naloží s ním příslušně

311

Software / Re:journalctl při -r + -n vynechá nejnovější záznamy

« kdy: 10. 12. 2021, 22:40:13 »

Aha, 241.
Mimochodem na té stránce je napsáno

Kód: [Vybrat]

    main (#14552) 
    v250-rc2 ... v245-rc1

Proč je tam verze uvedená dvakrát? Po rozbalení trojtečky se tam ukáže "interval verzí". Předpoklám správně, že tento opravný commit byl pro verzi* 245 a jen pro pořádek to píše ve kterých dalších verzích* až po současnou(250) to je?

* Nebo přesněji že to je první verze, která obsahuje tento comit
* možná je to tag nebo release

312

Software / HTTPSEverywhere se občas nechová jak má

« kdy: 10. 12. 2021, 22:32:45 »

Zkusil jsem si přidat doplněk HTTPS Everywhere , verze 2021.7.13. Pro Firefox android.

Asi jsem měl jiná očekávání, co bude principem fungování a že vůbec nebude spoléhat na nějaké seznamy a za druhé že Defaultně vypnutá volba Encrypt All Sites Eligible is ON je to co nechci.


Ale i tak mám nějaké problémy. (budu popisovat jak zadávám do adresního řádku)
- na idos.cz i https://idos.cz browser ukazuje na Redirect loop
- u některého procenta stránek, třeba kapral.cz , psycho.cz,pikao.cz se mi po odpálení "entru" ukáže Warning stránka rozšíření "HTTPS.E... zabránil načtení stránky. Možnosti. Proceed anyway, Disable, copy url"


jaká je příčina proč to nejde? Chápu, dnes je spousta možností, Location na www., Location na https://, Hlavičky,, weby co jedou na obou protokolech, jen na HTTP, jen na HTTPS, chybové kódy na url

A anketa: používáte nějaký takovýhle doplněk a neblbne ani u okrajových webů (divný konfig, jen http)? Co tam bylo potřeba nastavit?

313

/dev/null / Existuje tento nový druh způsob šifrování+přenosu?

« kdy: 10. 12. 2021, 22:13:15 »

Nevím jak to nazvat : předhřáté / homomorfní / mezilehlé šifrování.  A mám na mysli teď use case  stahování klasického souboru přes https z nějakého serveru.

Klasické šifrování : na souboru je uložený nějaký soubor. Když si ho někdo chce stáhnout (dnes je https běžné jak arm jako hlavní počítač). Soubor se přečte a https engine ho zašifruje.
Důležité vlastnosti: každé spojení je šifrované jiným náhodným klíčem pro zajištení forward secrecy (jen kdysi dávno pokud vím se používal přímo klíč serveru a když došlo k získání klíče, forward secrecy bylo pryč. Asi jakoPGP.)  O forward secrecy to ale nebude. Taky nehraje roli, jestli samotný server používá šifrované úložiště, ty soubory tak jako tak musí přečíst


Nové šifrování? : Vlastnost že by soubor by na serveru nebyl uložen nešifrovaný v případě disků bez šifrování. V případě šifrovaného úložiště by se právě ani soubor nedešifroval do plaintextu ( to je důležité do plaintextu, musel by se transformovat nějak jinak)...

Existuje něco takovéhleho? Jak se tomu říká? Používá se to v NSA, bílém domě, u hamáčka?

Prostě by to mělo fungovat, že pro  protokol TLS  uživatele a uživatele samotného to bude transparentní  na úložišti budou zvláštně zašifrované. Že nebude docházet k jejich dešifrování, ale nějaké zvláštní transformaci, která způsobí, že TLS vrstva u klienta (nezměněná) je dešifruje jako u normálního HTTPS (spíš TLS).
A nebo jinak, kdyby server nepoužíval šifrované disky, tak by tohle zamezilo možnosti přečíst obsah souborů pře čtení (a teď pozor, bojím se  to napsat a tady může být zádrhel) disku / paměti / trafficu serveru.


Postřehy:
- Možná někdo navrhne prostě na disk uložit zašifrovaný 7z soubor a ty co ho stáhnou odkázat na klíč. Tohle ne.
- Jak jsem psal, použít pro soubory šifrované úložiště . Řeší to to problém ? Tohle není jednoduchá otázka. Já myslím že ne.
- Jako jakýsi první nástřel by mohlo být, [zkratkovitě], že na server by se nahrál soubor zašifrovaný privátním klíčem serveru a TLS vrstva na serveru by "ten soubor posílal bez šifrování".Bohužel, tento příklad by platil jen v tom starém režimu TLS bez forwaed secrecy, kde se jelo na statický klíč.
- Filozoficko-logicky, má něco takovéhleho smysl a nebo jde dokázat, že něco takovéhleho neexistuje a že i kdzby se to nějak "naimplementovalo", vždy by musel existovat způsob, jak data vyčíst (z disku logicku ne, ale s pomocí RAM?)?

314

Hardware / Re:Aky disk do NASu?

« kdy: 09. 12. 2021, 20:41:42 »

že disky nejsou sešroubovány, ale.hermeticky zavařený.

Někde jsem četl, že v nové generaci disků jsou ještě lépe utěsněny než ta předchozí (první)

315

Software / journalctl při -r + -n vynechá nejnovější záznamy

« kdy: 09. 12. 2021, 20:30:29 »

Dělám něco špatně, nebo příkaz journalctl při současném použití -r a -n 7004 blbne? Jako vím, že mohu použít journalctl -r | head -n7004, ale proč to blbne v tamtom?

čas nyní 20:21-, nejnovější záznam 20:20. záznam na pořadí 7004 cca v 17:0x.


Očekáváno : vypíše posledních 7004 záznamů od nejnovějších dolů (parametr r). Vypadá to jako když kombinace -r a -n blbne.

Místo toho: chybí prvních 7003(přibližně) záznamů, začíná od 7004tého (přibližně) a vypisuje k 14008mému řádku (přibližně)


Zkoušel jsem i argumenty --no-pager, --no-tail --pager-end

Kód: [Vybrat]

pixla@id:~ $ journalctl   -n 7004 -r  | cat | head -n9 | grep -Pio "^.+:\d\d "
-- Logs begin at Wed 2021-12-08 22:15:43 CET, end at Thu 2021-12-09 20:22:10
pro 09 17:07:12
pro 09 17:07:12
pro 09 17:07:02
pro 09 17:07:02
pro 09 17:07:02
pro 09 17:07:02
pro 09 17:07:02
pro 09 17:07:02
pixla@id:~ $ journalctl   -n 7004 -r  | cat | tail -n9 | grep -Pio "^.+:\d\d "
pro 09 13:24:07
pro 09 13:24:07
pro 09 13:24:07
pro 09 13:24:07
pro 09 13:23:55
pro 09 13:23:55
pro 09 13:23:55
pro 09 13:23:55
pro 09 13:23:43

# wtf where 19:12


workaround: (mírný časový posun ,nehraje roli , čas 20:33)

 $ journalctl -r |head -n 2 |grep -Pio "^.+:\d\d"
-- Logs begin at Wed 2021-12-08 22:15:43 CET, end at Thu 2021-12-09 20:31:40
pro 09 20:31:40
...atd

Komentář k řetězení:

nadbytečný cat - vím, byl jsem líný ho umazat při testování
tail a head - aby tu nebyly tisíce řádků
grep - ovoce, které skryje nepotřebné detaily