Témata

106

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í

107

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?

108

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?

109

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?

110

/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?)?

111

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

112

Server / Podpora exFAT u QNAP: ARM vs. x86

« kdy: 08. 12. 2021, 15:11:07 »

Jak je to s podporou exFAT na QNAP NASech? Píše to, že mám si koupit nějakou licenci. Přitom informace jsem se dočetl, že podpora je zabudovaná, ale pro x86 procesory..


-Opravdu jen pro x86(64) procesory? Pro arm je to mimo hru (ale očivině to není technický problém, když stačí zkopírovat  binárku, ale otázkou je výkon a mód-kernel/fuse) .
-Jaké to má politické vysvětlení?
-Existují i jiná "podobně" "genitální" omezení? Například že třeba z podpory jsou vyloučeny disku podle druhu (disk v šachtě NASu vs připojený přes USB) nebo nad určitou velikost?

113

Hardware / Výkon čtení disku a komprese v NASu (A53 4jádro) - hodnoty

« kdy: 08. 12. 2021, 15:07:05 »

Jaké bych měl očekávat hodnoty výkonu v NASu s 64bit procesorem ARM  A53 čtyřjádro.  Má 2 sloty pro sata iii i disky se hlásí  jako v režimu SATA 6Gb/s ("in use").Spíš tedy bych chtěl zhodnotit zde napsané hodnoty:

1.)
rychlost  čtení disku dd if=/dev/sda of=/dev/null bs=1/2/4M .....155MB/s, 145 u konce kapacity 10TB

Disky by měl umět >220MB/s.

2.) komprese gzip  dd if=/dev/sda of=/dev/null bs=1/2/4M | gzip -1/-9 >/jinydisk/outfile.out .... 4 MB/ s!!!!!!!!!!!!!! (nebo případně ...gzip -c || dd of=soubor-jinydisk) To je nepoužitelné, já potřebuji opět stovky MB/s


Prosím o nějaké tipy čím by to mohlo být... u 2.  ještě musí vyzkoušet víc faktorů (of=/přímo-partition-sdc3) - především se zapisuje na disk USB3.0  a ještě ve filesystému exfat, který jsem tam musel dodat ručně (mount.exfat do /usr/sbin) a ručně připojit

114

Software / Výcuc 10TB disku, většinou nuly

« kdy: 29. 11. 2021, 17:10:28 »

Půjde pro přečtení disku

Kód: [Vybrat]

dd if=sda conv=sync,noerror iflag=direct,fullblock bs=1M | pv  -S -s 12345G | gzip -c image.bin

použít... Odhaduji že z 10TB disku to bude max 2TB. Bude dobře gzip fungovat na mnohagigabitové série nul ?
Ale nevím ,jak to  bude v praxi fungovat, když pak se budu chtít na obraz podívat. Existuje nějaký program, který mountne  velky gzip soubor transparentně? (pro windows Imdisk - umí načíst krásně iso soubor a pracovat s ním jako s novou jednotkou)

Rozhodně nechci procházet disk opakovaně. Nebo poradíte nějaký free tool, který by udělal chytře obraz (nějak komprimovaný) nebo aspoň mapu sektorů které jsou ne/nulové a nebo by udělal obraz jako sérii souborů po gigabajtech do složky (10000 není moc) přičemž by se buď každý file komprimoval samostatně a nebo nulové /prázdné bloky by se logicky nezapisovaly.

Spíš mi jde o nasměrovanání a nějakou generální radu, co je nejlepší přístup, ale rovnou vysypat sem mocný příkaz který přesně něco takového udělá taky ocením...

115

Sítě / Pár dotazů k síti - 169.254 a rp_filter pro odchozí a příchozí

« kdy: 29. 11. 2021, 01:05:33 »

Snažím se pochopit  nakonfigurovat firewall a jedna věc by mě zajímala, myslím, že není zrovna triviální. Na komplu je zapnuto ipv4.ip_forward, má 2 rozhraní(typicky eth - vniřní síť, wan =tam kde je gateway). Možná tu budu míchat víc věcí najednou.

1. : Jak je ošetřeno, aby pakety 169.254. neprocházely mezi sítěmi? Stačí na to (automaticky existující-proč?) záznam v route: 169.254.0.0     0.0.0.0         255.255.0.0     U     202    0        0 eth Kompl má tedy na eth mimo své i link-local adresu z nějakého důvodu (ip address - Má scope global, jestli to k něčemu). Ale chci aby tofungovalo nezávisle na tom ,jestli LL adresu má a zda je v seznam rout.  Nebo ví nějak linux "shůry" že 169.254 nemá routovat ?

2. : Pokud dám net.ipv4.conf.<XXX>.rp_filter = 1 (kromě toho, jestli to nějak vyřeší bod 1.), tak hraje roli, jestli to nastavím (XXX) jen pro wan jen pro eth nebo pro all (stejné jako pro wan a eth ). Bude to mít vliv na "směr ochrany"? (z wanu src=lokální , z wanu cíl nelokální, z Lanu src nelokální, z Lanu cíl ne-internet). Předem se omlouvám za takovéhle zjednodušení. Má smysl mít rp_filtr vůbec, jen na jednom (jen eth, jen wan) rozhraní nebo až teprv na obou?


3. a když se zeptám "hloupě" (vlastně tím generalizuju dotaz), musí na všechno být pravidla do iptables, nebo se i některé věci jako výše dají řešit "na správnějším místě" - definice route, definice adresního rozsahu na rozhraní, definice scope(pokud to má nějaký praktický význam), rp_filter ?

116

Server / Více teček v mailové adrese za @

« kdy: 24. 11. 2021, 22:45:52 »

Je možné aby emailová adresa mihla mít část za @ z víc částí oddělených tečkami? Třeba @bond.firma.cz

Má zo nějaké seciální vlastnosti , výhody a použití? Jak se k tomu přistupuje z hlediska SMTP(a dalších) serverů? Jako jestli jde o kompletně izolované domény nezávislé nebo tam.funguje nějaká delegace.

117

Server / Rozdíl mezi allocated a assigned PA

« kdy: 24. 11. 2021, 22:36:32 »

A jaký je rozdíl mezi assigned pa a allocated pa?

118

Software / (mini)DLNA provádí transcoding?

« kdy: 16. 11. 2021, 21:31:16 »

V Dlna se neorientuji, tak nevím co a jak a jak spolu vycházejí dvojice dlna server a klientv(teevizor). Probíhá tam nějaké domlouvání podporovaných formátů a případně transcoding? Anebo Je to čistě věc klienta nebo čistě věc serveru?


A taky jakým protokolem funguje vlastní přenos filmu? Je to přes http nebo smb? Nebo nějak embedováno v dlna protokolu?

Konkrétně minidlna

119

Software / Příkaz pro (občasné)neuložení historie terminálu

« kdy: 11. 11. 2021, 11:43:39 »

Dočasně jako workaround používám

Kód: [Vybrat]

kill -9 $$

Existuje ale nějaká lepší cesta jak neuložit v daném sezení terminálu  (vzdáleném přes SSH) historii ?? (A opravdu nemyslím teď že každý příkaz budu psát s mezerou)

Jde občasné použití. Je jedno jestli to bude fungovat při spuštění terminálu (nějaký parametr PUTTY), nebo uprostřed nějakým magickým příkazem/settingem proměnné a nebo nakonci  (jako zde zmíněný příklad)

Díky za rady!

(Ocenil bych i nějaké obšírnější informace o ukládání historie , jestli ta volba  funguje i retroaktivně, že se neuloží historie od začátku sezení, když ten příkaz zadám v probíhajícím sezení. A co je to za volbu, nebo co ovlivní že se příkazy ukládají ihned nebo až po skončení)