Příspěvky

211

Software / Re:Jak zablokovat anti-adblocker ochrany

« kdy: 01. 03. 2022, 09:12:13 »

Myslíš od roku 2020 minimálně? Existuje a takto vyčištěné stránky jsou voňavé a "klidné". Je nutný doplně uBlock origin + filtry easylist cz/svk a mělo by to fungovat.

Ten filtr je něco jako

Kód: [Vybrat]

emimino.cz,euro.cz,autorevue.cz,sleviste,cz,slunecnice.cz,idnes.cz,novinky.cz,aktualne.cz,aktuality.sk,info.cz,reflex.cz,zive.cz,mobilmania.cz,e15.cz,tiscali.cz,blesk.cz,ahaonline.cz,extra.cz,super.cz,auto.cz,maminka.cz,autorevue.cz,lupa.cz,vareni.cz,osobnosti.cz,sport.cz,lidovky.cz,karaoketexty.cz,iprima.cz,hnonline.sk,kupi.cz,kinobox.cz,cnews.cz,onetv.cz,zeny.cz,expres.cz,modnipeklo.cz,nasepenize.cz##+js(abort-current-inline-script.js, kununu_mul)
idnes.cz,kupi.cz,emimino.cz,cnews.cz,autorevue.cz,slunecnice.cz,novinky.cz,aktualne.cz,aktuality.sk,info.cz,reflex.cz,zive.cz,mobilmania.cz,e15.cz,tiscali.cz,blesk.cz,ahaonline.cz,extra.cz,super.cz,auto.cz,maminka.cz,autorevue.cz,lupa.cz,vareni.cz,osobnosti.cz,sport.cz,lidovky.cz,karaoketexty.cz,iprima.cz,hnonline.sk,kinobox.cz,cnews.cz,onetv.cz,zeny.cz,expres.cz,modnipeklo.cz,nasepenize.cz##+js(abort-current-inline-script.js, ATOB)

! Hlavně dopc nepovolovat doménu dopc.cz , jhmt.cz  , mrezadosa.com a ["https://d3eyd961wi10bl.cloudfront.net/css/arrow.css", "https://d1daeonbqcq0oh.cloudfront.net/css/arrow.css", "https://toi.cdn.dopc.cz/css/arrow.css"] , adocean.pl,performax.cz, etargetnet.cz

když už na tyhle plátky musím jít, tak přepnu v mozille do "reader view".

To je ale pouze řešení alá zabalíme hovno do novinového papíru. Ale přesto bude smrdět a možná na nás něco vyteče? Nebo má snad Reader view řešení, které inhibuje skripty? Já mám indikaci že ne (například se mi na jiných webech stále načte text.

212

Server / Re: Co uloží odeslaný mail do Odeslané?

« kdy: 01. 03. 2022, 08:49:17 »

AHA, tak ono to doopravdy je takhle tupé. (A nebo to Thunderbird neumí). Odeslání 8700k  Přílohy (4/3 *file= 12MB tělo) způsobilo 24MB odchozích dat.

213

Server / Občasné ICMP pakety na loopback po zodpovězení DNS

« kdy: 25. 02. 2022, 21:08:17 »

Nevíte proč stubby mi při každém dns dotazu (i z jiného PC) posílal na loopack ICMP packet?

Nedokážu si jistotou určit, že původcem je stubby, jelikož jde o UDP a nenašel jsem nic jako ss -Eu4p nebo netstat -cu4p

Konfigurace je takováto
/etc/resolv.conf:
nameserver 127.0.0.1
resolvconf.conf:
name_servers=127.0.0.1
lokální i vzdálené dotazy chodí démonu dnsmasq, ten je filtruje a  přeposílá stubbymu na port 853.  Port 853 je  vtomto případě jen náhodné číslo.  Ten je pak posílá na DoT.  Port 853 v tomto případě je číslo portu DoT..

Po restartu stubby se už tak neděje - asi nějaká dočasný chyba

sudo  tcpdump     -evnti lo
 sudo  tcpdump     -evnti lo # pročitelněno, dole neupraveno)
tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
    1 127.0.0.1.44323 > 127.0.0.1.853: UDP, length 24
    2 127.0.0.1.44323 > 127.0.0.1.853: UDP, length 24
    3 127.0.0.1.853 > 127.0.0.1.44323: UDP, length 57
    4 127.0.0.1.853 > 127.0.0.1.44323: UDP, length 57
    5 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 udp port 44323 unreachable, length 93
        (tos 0x0, ttl 64, id 35057, offset 0, flags [DF], proto UDP (17), length 85)
    127.0.0.1.853 > 127.0.0.1.44323: UDP, length 57 #(to není paket číslo 6, to je "vnořený")


 nebo bez úprav:

tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
1 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 35048, offset 0, flags [DF], proto UDP (17), length 52)
    127.0.0.1.44323 > 127.0.0.1.853: UDP, length 24
2 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 64, id 35049, offset 0, flags [DF], proto UDP (17), length 52)
    127.0.0.1.44323 > 127.0.0.1.853: UDP, length 24
3 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 99: (tos 0x0, ttl 64, id 35056, offset 0, flags [DF], proto UDP (17), length 85)
    127.0.0.1.853 > 127.0.0.1.44323: UDP, length 57
4 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 99: (tos 0x0, ttl 64, id 35057, offset 0, flags [DF], proto UDP (17), length 85) [bad udp cksum 0xfe56 -> 0xb3c0!]
    127.0.0.1.853 > 127.0.0.1.44323: UDP, length 57
5 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 127: (tos 0xc0, ttl 64, id 17564, offset 0, flags [none], proto ICMP (1), length 113)
    127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 udp port 44323 unreachable, length 93
        (tos 0x0, ttl 64, id 35057, offset 0, flags [DF], proto UDP (17), length 85)
    127.0.0.1.853 > 127.0.0.1.44323: UDP, length 57

A tím [bad udp cksum 0xfe56 -> 0xb3c0!] se asi nemusím zaobírat ,že? je to u naprosto všech paketů na localhostu (vyznačeno v textu jen na jednom), to je jen asi vypnuté počítaní checksumů bych tipl

214

/dev/null / Re:Blokace ruských IP

« kdy: 25. 02. 2022, 19:30:04 »

U nas sa do zakonov zacina pretavovat obmedzovanie nevhodnych informacii a zdrojov z netu. Otazka je kto rozhodne co je a nie je nevhodne. Sloboda konci a nastupuje cenzura. Nastupuje urcovanie pravdy a to su nastroje rezimov, ktore nenazyvame demokraticke.

U nas aj  bez zakona.  Iba na zaklade diskuse s uradem vlady a na zaklade konzultací.

215

O serveru Root.cz / Re:Už mi zase zdejší fórum nenávratně zahodilo rozepsanou odpověď (bug report)

« kdy: 25. 02. 2022, 11:14:11 »

To je fakt nějaká lotynka. Prostě píšu příspěvek  který se povede bez problému odeslat po 10minutové neaktivitě, pak po minutě píšu další, třeba 3 minuty ale u něj to náhle napíše přístup byl odepřen...

Mám takové tušení, že je nějaký problematický timeout vypršení zalogování se počítá od přihlášení a ne od posledního http requestu.

216

/dev/null / Re:k zamyšlení - příchozí traffic z vybraných zemí

« kdy: 25. 02. 2022, 11:10:32 »

Já myslím že je to uplně jedno jakou vlaječku to má, protože mě třeba otravovala nějaká IP patřící holandskému ISP podle RIPE, ale abuse mi odpověděl zjevně americký Serverion ale vlaječku má českou

217

Software / Re:Nízký výkon exFAT na Raspberry, wget 2 MB/s

« kdy: 25. 02. 2022, 11:08:21 »

Mě se to EMMCčko moc osobně nelíbí tedy abych řekl    (i když tam je ta klíčová výhoda životnosti a možná pro někoho i zápisu 37 MB/s místo 12 u mě)  Je to takový "krápník" co z toho bude viset jak sopl u nosu . 

Používám paměťovou kartu řady "Endurance" o 2 násobné kapacitě a poloviční ceně. Mohl jsem tam zapsat kolem 300GB, beží nonstop a zatím bez problému.

Hodně podceňovaný faktor je provozní teplota karty.

218

Server / Co uloží odeslaný mail do Odeslané?

« kdy: 25. 02. 2022, 11:01:15 »

Omlouvám se za poněkud vesnickou otázku, ale co určuje, že se Odeslaný e-mail uloží zároveň do složky Odeslané? Kromě toho se to tak nemusí stát vždy. Například Při psaní z roundcube je postranní volba Uložit po odeslání do složky:Neukládat (není to doslovně, ilustruje to že se neuloží;defaultní volba je Odeslané). Anebo při posílání přes script (na M(T/S)A odesilatele. Ne na MTA příjemce  - to by nebylo co ukládat) se taky neuloží.
A taky nepřekvapivě, toto Odeslání uložení probíhá v jednom kroku. Nic takového , že by se nejdřív megový mail odeslal a pak znova by se megový mail vkládal do složky odeslané (z pohledu MUA)

nejdřív před otázka: Píšu e-mail , uložím ho do složky rozepsané. Jde o standartní příkaz IMAP protokolu "Vytvoř v Složce Drafts zprávu s obsahem ...."?


Jak tedy vypadá z pohledu MUA (a možná i MSA) cesta odesílání mailu kdy se zároveň uloží do složky odeslané? Co proběhne dřív(vajíčko nebo slepice)? Uloží se e-mail do nějaké složky a pak se zavelí odeslat a nebo se odešle klasicky smtp protokolem a MSA ho zároveň uloží.
Je mi divné se na to ptát, když umím přes skripty doručit mail na cílový server(což asi správně termínově není odesílání, MSA z řetězce uplně vypadne, ale doručování) a i odeslat mail na "svůj" MSA (který ho pochopitelně neuloží do složky Odeslané)

Má SMTP  (v komunikaci MUA->MSA) nějakou volbu "A ještě uložit do složky Odeslané"?


Zajímal by mě "ten krok navíc"´, který způsobí že se odeslaný mail uloží do Složky odeslaná (což je defaultní chování. Mám na mysli třeba desktopové kancelářskéMailové programy.

Předpokládám, že IMAP v tom vůbec nefiguruje (Tím pádem jak tedy funguje uložení konceptu zprávy?)

219

Software / Re:Nízký výkon exFAT na Raspberry, wget 2 MB/s

« kdy: 25. 02. 2022, 10:35:55 »

Já čumim : 
read  35 MB/s (>=256k) , 19 MB/s ( 16k)
write: 10 MB/s(=>64k) ,  4MB/s (16k)    (Ta karta má pomalý zápis, je to Endurance s vyšší výdrží - za cenu nižší kapacity a horší rychlosti)


celková Zátěž cpu do 4%. (kworker 2% a dd 2%)
Normálně mám raketu. Díky za připomenutí zapomenutého/odloženého.

(Neuvědomil jsem si že už  tam nemám 4.8 jádro)

220

Hardware / Re:Pomoc s výběrem telefonu

« kdy: 24. 02. 2022, 16:07:44 »

Body 2,3 řeší LineageOS - nejčistší ze systémů. Neaktualizuji.
Bod 1 řeší samsung (možná odpovídám mimo ). - i V lineageOS je režim vysoká citlivost  pro dobré ovládání v rukavicích, fakt je ovládání v rukavici přirozené.
Body 7 je pro mě otázka na kterou hledám odpověďm 6 by mi bodla, na 5 nelpím (stejně pochybuji že na rootnuném lineageOS půjde k placení použít i po všech rovnácích na "zamaskování rootu")

Je mi záhadou , proč některé vlastnosti se po přechodu na LineageOS dostanou a jiné Ne. (Live Display rozsáhlými nastaveními barevných teplot, profiů, režimů- filtrů)
A obráceně, proč některé nové vlastnosti, které přinese Lineageos, (Night mode "teplé barvy) nejsou napříč  vícero modely.


Za mě už to dávno není o hardwaru (pokud to nebude mediatek s HD TN displejem), ale o vhodné distribuci

221

Software / Nízký výkon exFAT na Raspberry, wget 2 MB/s

« kdy: 24. 02. 2022, 15:57:24 »

Tak jsem se zakoukal do logu, stahování 20Mbps:

Kód: [Vybrat]

    r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
  547,57    0,00      2,1M      0,0k     0,00     0,00   0,0%   0,0%    0,50    0,00   0,27     4,0k     0,0k   1,47  80,4% mmcblk0


     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
  580,57    0,14      2,3M      1,7k     0,00     0,14   0,0%  50,0%    0,53    6,00   0,31     4,0k    12,0k   1,56  90,6% mmcblk0

Time         ARM    Core    H264 Core Temp (Max)  IRQ/s      RX B/s      TX B/s   cpu0   cpu1   cpu2   cpu3

15:52:51  1200Mhz  400Mhz  400Mhz 52.62C (54.23C) 12,573   2,425,279      58,302  36.13  54.03  39.04  23.55
15:52:53 1200Mhz  400Mhz  300Mhz 52.62C (54.23C)  5,503   1,246,449      29,952  32.42  10.87  97.06   5.97

zátěž procentuální (busy time) je kolem 88%, je tam i read  spousty 4k bloků

sudo iotop hlásí mount.exfat write(což chápu) i read - obojí 2MBPS - kde jechyba, proč to tolik čte?

htop odhadem 25% všech jader (vč červeného-kernel)- odhadem zelené(user) je 25% z celé "plochy" grafu zátěže.
wget :30% (stahuje se z https!)
mount.exfat  9%

je exfat dobrá volba pro raspberry pi/ armv7l a microsdkartu? (je to ještě notně starý user mode). Údajně trojka je 64bit ale OS byl b 64b variantě "představen jako stabilní" teprv nedávno. I když si myslím, že 64/32bit je ten nejmenší problém.

opravdu to takhle exfat zabíjí?

Mám pocit že 8MB/s by to nezvládlo.


Jsou třeba nějaké rady jak optimalizovat exfat oddíl?
mount hlásí:
type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
ale příkaz samotný zní:
/sbin/mount.exfat /dev/mmcblk0p5 /home/pi/drr -o rw,nosuid,nodev,noatime

222

Sítě / Re:Přesměrování portu 8080 na port 80 v nftables

« kdy: 24. 02. 2022, 13:37:58 »

Myslíme tím přesměrováním portu "8080 na 80" Všichni to samé?
1. Myšlená krabička před routerem, který přepíše u příchozích paketů port 8080 na 80.  Co se pak děje s pakety na určitou dst-adresu je další krok problému.
2. Odklonění na lokální počítač (tuším že v pfsense /bsd se to to pravidlo jmenuje DIVERT)

 "V originále" man iptables-extensionjs je REDIRECT  a  volitelný parametr je číslo(rozsah) portu a toto pravidlo nasměruje porty na lokální počítač.

223

Server / Re:Spotřeba RAM mailserveru

« kdy: 24. 02. 2022, 13:27:45 »

Máte někdo odpověď z   p r a x e, kolik to tak může žrát? Například pro 1 doménu, 1 usera, když není provoz, není fronta. Bez AV / antispamu.

224

Server / Re:Naplánované odeslání e-mailu v SMTP

« kdy: 21. 02. 2022, 11:27:37 »

Exceloje

Tyjo a já jsem si byl téměř jistý, že jsem to napsal bezmezery

A já myslel že zrovna fronty jsou to pravé ořechová na tenhle problém.
No tak přijímací strana, natož MDA už tohle vůbec nemá v kompentenci
MUA přeci z definice nemůže být na serveru. To ale neznamená MUA  tu zprávu MSA nějak nepředá. Musí tam být nějaké rozhraní, by to bylo na MUA nezávislé. (Nebo tak bych to aspoň chtěl)

Mimochodem na svém MUA (Mozilla) mám složku k odeslání, jenže ta je lokální a existuje i extension, který  tuhle funkci řeší. Jenže je to řešení na klientovi. Já právě hledám funkci na serveru, že"odešlu" mail, ukončím TheBat, zaklapnu víko, a  teď as se stará server

225

/dev/null / URL dlouhé jak cesta

« kdy: 21. 02. 2022, 09:55:05 »

Co to k čertu je?
https:\\3b03526a0dbc0e6018e63348d8d47352.returdeka.@@/0/
35897.click?tt=3ea83ebbcca83
998beb69bb4a85914ac0fa97887b6ac033ec6b023cc75c8c0aab4bbe888c225b192e98211876fa4c46a8b86e23fd6ea11d62337ee
638729b477def0a0bfc21b4e641617983b74e5f9ae80a11be52d83b72d070115bd44cf4053e72ea6af17aa47fa264122c15f5c53677b
12f402801e5c597dfa318f62fd2621737821a92f8855d56adc4270ae84d12de6918ea03bc193a512b2dd8d91622b5f7f63ffceccadba7ab99c819f41ddaf19047dfbbe5655d34920cdac75
a0410d3250944e41acfd4ff8ae6a1eca625cc935e06c446150348f20abfe8893e4846b9903db4e9946b35c77d1e74d0573f0345f05a23c3deeca45bdc25423b8ff062598ea6f868ac15f2349e0f53507aabc50172ff221e1de2ea2065987d43fc1da03ffa2a176b389685eb502bcd92672bd70a1482f537ee110915a77f36e97d26a970b3b65af2c909c5f5beb7c7fac6b6fe36ede7c2b4a5e9af8f3d98b35d599e3b9506fcfef9aefcb72fa5f255923640f64d86f7a4cbaef2cfc25e002e8da4586d345fe4ddd7b19df9109d18fb4760bbb0881c74eec6e96ed2890f36522f55ae3c0fe150c6a3b5cb2786018e6b1889cbccb74069eb8b0d387bc5867bfae6
f3f765bc1293149a501941e70b3b33a2fa168445c042c6eafcaa29e016c98d0f9ded0b9d7a5e78fce4fc6423236a5e1614617c7d9b150cb990b840df04d644dbf9cc2758eef83b6179eb18
c107d51f74be5ebf45422e37171364f692b921af9e0eee48abg
To je nějaký DNS ždímač?