Příspěvky

1

Software / Re:Znak skoromezery rozbije curl

« kdy: 23. 12. 2024, 16:11:42 »

curl verze 7.88.1

Kód: [Vybrat]

$ curl ​http://adre.sk/
curl: (3) URL using bad/illegal format or missing URL

2

Software / Re:DYI náhrada DVB-T2 set-top boxu

« kdy: 03. 12. 2023, 22:51:57 »

Používám PC s https://www.neven.cz/kategorie/pocitace-a-kancelar/tv-tunery/dvbsky-t982-dvb-t-t2-c-pcie-interni-dualni-tuner/, KODI a balík kodi-pvr-hts na ovládání tvheadend přes KODI.

Bohužel musím říct, že kodi-pvr-hts občas neumí přesně říct tvheadend, co chce, a něco se nahraje víckrát a podobné chyby. Takže jsem nakonec taky skončil u programování přes tvheadend web interface. Mám ale dojem, že pokud se KODI použije na "Timers" - programování začátku nahrávání podle času, ne podle EPG - fungovalo to dobře.

3

Vývoj / Re:Ako programovo odoslat email priamo bez SMTP hostingu?

« kdy: 08. 09. 2022, 20:00:54 »

Asi oba dva mluvíte každý o něčem jiném.

Na mém serveru se objevují např. takovéto výměny:
(C - klient, S = server = já, ~ - "\r\n")

Kód: [Vybrat]

C: MGLNDD_x.x.x.x_25~
·S: 500 Error: command not recognized~
<RST>


Kód: [Vybrat]

C: ehlo DESKTOP-8N00BJ1~
·S: 250-DESKTOP-8N00BJ1, mss version 2 here~250-8BITMIME~250-SIZE 33554432~250 PIPELINING~
 C: Rset~
·S: 250 OK to reset~
 C: Mail from:<spameri@tiscali.it>~


Kód: [Vybrat]

C: EHLO nexen.net~
·S: 250-nexen.net, mss version 2 here~250-8BITMIME~250-SIZE 33554432~250 PIPELINING~
 C: RSET~MAIL FROM:<qonsm@mojedomena.cz>~RCPT TO:<3123827806@qq.com>~DATA~
·S: 250 OK to reset~250 OK mail from <qonsm@mojedomena.cz>~550 error: receipt to address not accepted~503 error: Bad sequence of commands~
 C: RSET~MAIL FROM:<xgmnls@mojedomena.cz>~RCPT TO:<3123827806@qq.com>~DATA~
·S: 250 OK to reset~250 OK mail from <xgmnls@mojedomena.cz>~550 error: receipt to address not accepted~503 error: Bad sequence of commands~
 C: RSET~MAIL FROM:<cokghh@mojedomena.cz>~RCPT TO:<3123827806@qq.com>~DATA~
<a dál do nekonečna>

U takovýchto serverů nemá cenu čekat na to, co se mi chystají poslat (aka DATA). Dříve nebo později to musím ukončit, jinak bych nedělal nic jiného.

Jiné věc je, když se na mě připojí např. google, pak mail samozřejmě přijmu a pak teprve řeším, jestli to je spam nebo ne. To pak vypadá nějak takto:

Kód: [Vybrat]

C: EHLO mail-ed1-x52e.google.com~
·S: 250-mail-ed1-x52e.google.com, mss version 2 here~250-8BITMIME~250-SIZE 33554432~250 PIPELINING~
 C: MAIL FROM:<xxxx@gmail.com> SIZE=11151~RCPT TO:<y@mojedomena.cz>~DATA~
·S: 250 OK mail from <xxxx@gmail.com>~250 OK: receipt to 'y@mojedomena.cz'~354 OK for DATA, end with classic <CR><LF>.<CR><LF>~
<atd>


4

Vývoj / Re:Ako programovo odoslat email priamo bez SMTP hostingu?

« kdy: 07. 09. 2022, 15:19:00 »

Mohl bych se zeptat, jaký byl důvod opouštět Postfix? Ještě tam chybí třeba podepisování e-mailů technologií DKIM. A tu frontu e-mailů vlastně není vůbec těžké naprogramovat, když nad tím tak přemýšlím...

Asi mi přišlo lehčí si to napsat sám než donutit Postfix dělat to, co jsem chtěl. Ale to si každý musí vybrat podle sebe.

DKIM je příliš těžký na kódování  Zkusil jsem to bez toho a funguje. Ale chápu, že se to asi hodí jen pro malého soukromníka.
U té fronty ten email prostě uložím a v exponenciálně se zvyšujících intervalech to zkouším znova. Zatím ve 100% případů se jednalo o greylisting, takže se ten mail odešle hned při první opakované iteraci.

5

Vývoj / Re:Ako programovo odoslat email priamo bez SMTP hostingu?

« kdy: 06. 09. 2022, 22:40:06 »

• Zařídil jsem si VPS a pevnou IP4 a IP6 adresu + doménu.
• Naprogramoval jsem si SMTP klienta, který umí jen posílat (nefunguje jako proxy). Předtím jsem používal postfix myslím.
• Do domény dodal SPF záznam v=spf1 ip4:x.x.x.x ip6:y::y/64 -all a DMARC záznam v=DMARC1; p=quarantine
• Poslal jsem si zkušební emaily do mých emailových stránek na gmail, seznam a tak a zkontrolovat v hlavičkách, jestli je vše v pořádku.
• Zkušebně jsem poslal emaily svým známým a nenápadně se poptal, jak to dopadlo. Pokud spadly do spamu, poprosil jsem je, aby emaily označili jako ne-spam.

Argument, že nemůžu vědět, jestli všechny mé maily došly, je samozřejmě validní, ale platí i pro jiné providery.
Funguju takto od roku 2015, zatím jsem nenarazil na problém, posílám cca 30 mailů denně, ale většinou těm stejným lidem.

6

Desktop / Re:Co dělám blbě? Firefox 91.5.0 vysoké CPU

« kdy: 21. 01. 2022, 14:49:37 »

Hmm, koukam, ze to uz je asi zastarale. Zkus media.ffmpeg.vaapi.enabled,
viz https://bugzilla.mozilla.org/show_bug.cgi?id=1748862 pripadne zastresujici bug https://bugzilla.mozilla.org/show_bug.cgi?id=1610199. Seznam prefs i s popisky najdes treba zde: https://searchfox.org/mozilla-central/source/modules/libpref/init/StaticPrefList.yaml

Zkusil jsem změnit media.navigator.mediadatadecoder_vpx_enabled a media.ffmpeg.vaapi.enabled na true, ale pořád to jede stejně přes CPU.

Divné je, že FF safe-mode by měl jet se stejnými hodnotami about:config jako normální profil, a přesto umí jet přes GPU a normální profil ne. Musí to být v něčem jiném, ale nedaří se mi přijít na to v čem. 

7

Desktop / Re:Co dělám blbě? Firefox 91.5.0 vysoké CPU

« kdy: 20. 01. 2022, 22:50:51 »

Koukni do about config na hodnotu media.hardware-video-decoding

media.hardware-video-decoding.enabled true.
media.hardware-video-decoding.force-enabled false. Zkusil jsem dát true, ale nepomohlo.

8

Desktop / Re:Co dělám blbě? Firefox 91.5.0 vysoké CPU

« kdy: 20. 01. 2022, 22:28:08 »

Na jakém OS? Mac/Windows/Android/Linux? Můžeš nějakým process explorerem zjistit CPU a gpu load?
a v youtube dát advanced stats:typ kodeku (kdysi dávno youtube ještě ukazoval praktickou informaci o HW decodingu &HW renderingu)

Debian 10.11
CPU (intel 4 jádra) normální FF

Kód: [Vybrat]

top - 22:11:07 up 11:19,  1 user,  load average: 3.55, 2.75, 1.59
Tasks: 187 total,   4 running, 183 sleeping,   0 stopped,   0 zombie
%Cpu(s): 68.4 us,  2.5 sy,  0.0 ni, 29.1 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

CPU safe-mode

Kód: [Vybrat]

top - 22:15:11 up 11:23,  1 user,  load average: 2.42, 2.42, 1.72
Tasks: 187 total,   2 running, 185 sleeping,   0 stopped,   0 zombie
%Cpu(s): 26.1 us,  2.5 sy,  0.0 ni, 68.9 id,  0.1 wa,  0.0 hi,  2.4 si,  0.0 st

GPU normální FF (přes intel_gpu_top)

Kód: [Vybrat]

                   render busy:  24%: ████▉                                  render space: 17/131072
                bitstream busy:   0%:                                     bitstream space: 0/131072
                  blitter busy:   0%:                                       blitter space: 0/131072

                          task  percent busy
                           GAM:  23%: ████▋                   vert fetch: 28881941 (4791/sec)
                            VS:  21%: ████▎                   prim fetch: 10319483 (1669/sec)
                          URBM:  21%: ████▎                VS invocations: 19650540 (3240/sec)
                            VF:   4%: ▉                    GS invocations: 0 (0/sec)

GPU safe-mode

Kód: [Vybrat]

                   render busy:  41%: ████████▎                              render space: 29/131072
                bitstream busy:   0%:                                     bitstream space: 0/131072
                  blitter busy:   0%:                                       blitter space: 0/131072

                          task  percent busy
                           GAM:  39%: ███████▉                vert fetch: 35158898 (9680/sec)
                            VS:  37%: ███████▌                prim fetch: 12477516 (3356/sec)
                          URBM:  37%: ███████▌             VS invocations: 23856112 (6568/sec)
                          GAFM:   0%:                      GS invocations: 0 (0/sec)
                            VF:   0%:                           GS prims: 0 (0/sec)

Kodek (přes pravoklik na video a "Stats for nerds") - stejný pro normální i safe-mode

Kód: [Vybrat]

vp09.00.51...(303)/opus(251)

Jestli to dobře chápu, tak v safe-mode to jede správně přes GPU, a ne přes CPU jako v normálním FF. Jak mám nastavit běžný FF tak, aby jel přes GPU jako v safe-mode?

9

Desktop / Co dělám blbě? Firefox 91.5.0 vysoké CPU

« kdy: 20. 01. 2022, 18:27:33 »

Zdravím,

po upgradu na nový FF ESR se zvýšila zátěž pří přehrávání videa (Youtube). Mám jedno video, na kterém to zkouším, a zátěž je dvojnásobná než před tím upgradem. K jiným změnám než aktualizaci FF nedošlo.

Jiné prohlížeče - zátěž v normálu.

Firefox safe-mode (troubleshoot mode) dává taky normální CPU (nadějné!). Když ale postupuju podle návodu https://support.mozilla.org/en-US/kb/troubleshoot-extensions-themes-to-fix-problems#w_the-problem-does-not-occur-in-troubleshoot-mode, nic z toho nepomohlo (vypnout doplňky, themes, akceleraci a tak).

Máte ještě nějaké nápady, čím by to mohlo být? V čem je safe-mode jiný?

Díky!

10

Server / Re:Gmail zahazuje maily?

« kdy: 01. 01. 2022, 17:11:50 »

Dobrý souhrn tipů jsem našel tady: https://www.rackaid.com/blog/gmail-blacklist-removal/

Ukázka:

Generally, Gmail blocks your email for one of several reasons.

    You are sending large volumes of email.
    There are sudden changes in email volume.
    You are sending emails to “spam trap” addresses.
    You are sending email to unknown users.
     One of the important email blacklist includes your server’s IP address.
    Gmail users mark your emails as spam.
    You are using a new IP address to send emails.
    You have incomplete or incorrect DNS records.
    Failing Email Authentications

V reálu to znamená, že musíš na kolena a odprosit/kát se. Pak z různých náznaků odtušit, co jsi vlastně udělal "špatně", a zkusit to napravit. Přímá audience u biskupa není možná

11

Sítě / Re:ping neukazuje time pro -s menší než 8

« kdy: 25. 12. 2021, 12:49:19 »

Do packetu se musí vejít "timestamp", z kterého se po návratu odečte ten čas.
Pokud je packet příliš malý (viz kód), čas se nepočítá (timing = 0).

Kód: [Vybrat]

// iputils-20180629, ping.c
if (datalen >= sizeof(struct timeval))  /* can we time transfer */
                timing = 1;

U mě je tedy sizeof(struct timeval) rovno 16, takže ping -s 16 čas ukazuje, ale ping -s 15 už ne.

12

Server / Re:Mail u sebe doma

« kdy: 30. 10. 2021, 20:37:13 »

Správa SMTP serveru a klienta je otrava a ztráta času pro toho, koho to nebaví. Za tu dobu, co to tady rozebíráme, by průměrný programátor naprogramoval kostru SMTP serveru.

Takže z mých zkušeností bych doporučoval udělat ještě jeden krok dál a naprogramovat si to sám. Udržovat konfigurační soubory a aktualizace je hrozná nuda, ale hrábnout do kódu a udělat si to přesně tak, jak chci, to teprve přináší pocity uspokojení  Možná ještě více pro toho, kdo není profesionální programátor.

Výhoda SMTP je, že kód nemusí být nějak zvlášť optimalizovaný a rychlý. U emailů si vždycky můžeš dát voraz.
Dále: základ SMTP je děsivě primitivní: HELO - OK - MAIL FROM - OK - RCPT TO - OK - DATA - OK - QUIT. 
Je dobré oddělit démona pro příjem a odesílání pošty, a každého si pohlídat zvlášť. Např. SMTP klient samozřejmě přijímá požadavky jen přímo ode mne, ošetřené např. přes firewall a pak přímo v kódu. Je dobré všechny kontroly duplikovat a pak ještě sledovat logy.

Když uslyšíš o nějaké zranitelnosti v jiných klientech, hned přemýšlíš - mohlo by se to stát i mně? Někdy zjistíš, že jo, a musíš to celé přepsat. Opruz! Anebo zábava To už má každý jinak.

Tento přístup má ale jednu velkou nevýhodu: jakmile se ti to povede, máš chuť si pak programovat sám všechno: web server, šifrování, imap,... Protože žádná aplikace nikdy nebude přesně taková, jakou chceš a potřebuješ, a musíš si ji pak napsat sám. 

13

Server / Re:VPS hosting pro mailserver (čisté IP adresy)

« kdy: 16. 02. 2021, 21:58:55 »

Wedos dává IPv4 a k tomu /64 IPv6. [...]

U stávajících klientů to s tou IPv6 není bohužel pravda (dostali /112): Na opravě se prý pracuje.
https://help.wedos.cz/otazka/ipv6-na-blacklistu-spamhaus/26835/

U nových nevím.

14

Software / Re:Rsync: jaká volba pro bezchybný přesun souboru po síti

« kdy: 03. 09. 2020, 21:42:57 »

... A jestli kontrolouje i spravnost zapisu na disk v cili pri kazdem behu, to tu resime.

Nekontroluje.

Pri beznem provozu, praci a zalohovani me nenapadlo, jak by se to mohlo stat.

Mně se to stalo na Raspberry Pi - systém (Raspbian) se choval divně, a díky tomu, že jsem ho zálohoval přes rsync BEZ varianty -c, tak jsem měl k dispozici nepoškozenou kopii, díky které jsem zjistil, že se mi náhodně mění celé bloky dat na RPi. V syslogu žádné chyby disku, rsync taky nehlásil žádné chyby. Memtest v pořádku, dal jsem tam jinou SD kartu, přeinstaloval systém, nic nepomohlo.

Vyřešeno až reklamací celé Maliny. Díky záloze (bez -c!) jsem o nic nepřišel.

15

Software / Re:Rsync: jaká volba pro bezchybný přesun souboru po síti

« kdy: 03. 09. 2020, 10:18:40 »

...
2x rsync spoustet nejdriv bez -c a pak s -c by snad melo odhalit jen soubory zdanlive stejne (jmeno, cas, umisteni) ale s jinym checksumem. Stejne tak, pustim li rsync jen jednou s -c. Spousteni 2x (podruhe s -c) by odhalilo i chybny zapis s cili, ktery by nemel kvuli kontrole konzistence VZDY nastat.
...

Nepochopil jsem, co znamená "by nemel kvuli kontrole konzistence VZDY nastat", ale co vím, tak rsync NEkontroluje, jestli byl soubor správně ZAPSÁN na disk, ale jestli byl správně přenesen, bez ohledu na volbu -c. Tedy se může stát, že při chybném sektoru na disku v cíli bude cílový soubor jiný, než originál, i když rsync hlásí vše v pořádku.

Pokud ti tedy jde s kontrolu souboru na disku, pak by dávalo smysl spustit rsync s volbou -c dvakrát. Anebo spíš podruhé spustit s variantou "--verbose --dry-run --checksum" a podívat se, jestli má rsync snahu soubor přenášet znova (= checksum výchozího a cílového souboru nesouhlasí).