Příspěvky

1

Server / Re:Pomalé předání e-mailu na Gmail.com

« kdy: 22. 03. 2023, 10:06:16 »

U mna vacsinou delay pod 1s.  Ale mam tam jednu specificku adresu, kde odchadza posta dost casto a u nej mam delay vzdy daleko vacsi, medzi 10-20s.  Vyzera to, ze google selektivne spomaluje transakcie u adries, na ktore posiela nas server vela posty.
V niektorych pripadoch to konci odmietnutim na ERROR 421 s dovodom "Our system has detected an unusual rate of  unsolicited mail originating from your IP".... To protect our users from spam, mail sent from your IP has been temporarily rate limited". Co je samozrejme horsi pripad. A to nemusi ist o spam.Toto sa stava napr. u legitimnych notifikaciach z objednavkoveho systemu.

Treba si tiez uvedomit, ze mail nie je instant messaging. Oneskorenim 4s namiesto obvyklych 0.9s by som sa netrapil.

Tak zalezi na use case, ono pro nejakou aplikaci muze byt rozdil jestli odesle 900 emailu za hodinu nebo 4000 emailu za hodinu. U reseni vyzadujicich vyssi pocty dorucovanych sprav se obvykle pouziva farma emailovych serveru kde kazdy ma samostatnou IP, zaznam, atd. A ano, google ten traffic zamerne spomaluje.

Presne takhle. Mame novou i starou farmu mailserveru, na ruznych subnetech (ruzne ASN) a obe se chovaji stejne = pomalu.
Da se s tim neco delat? Uvazolval jsem nastavit postfix nastavit na sekundarni MX fqdn, ale tam je ping odezva maximalne 2x lepsi. Druhou moznosti je zvetsit nektery z parametru postfixu pro vytvoreni vice spojeni, napr. ted mam:

Kód: [Vybrat]

smtp_destination_concurrency = 4
initial_destination_concurerency = 5
A postfix to pak interne nejak upravuje podle toho, jak rychle se dari odesilat.

2

Server / Re:Pomalé předání e-mailu na Gmail.com

« kdy: 20. 03. 2023, 14:42:01 »

Hadam, ze odpoved bude asi tady:

Kód: [Vybrat]

Pinging gmail-smtp-in.l.google.com [2404:6800:4008:c06::1a] with 32 bytes of data:
Reply from 2404:6800:4008:c06::1a: time=268ms
Reply from 2404:6800:4008:c06::1a: time=268ms
Reply from 2404:6800:4008:c06::1a: time=268ms
Reply from 2404:6800:4008:c06::1a: time=269ms

Ping statistics for 2404:6800:4008:c06::1a:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 268ms, Maximum = 269ms, Average = 268ms

ping -4 gmail-smtp-in.l.google.com

Pinging gmail-smtp-in.l.google.com [64.233.188.26] with 32 bytes of data:
Reply from 64.233.188.26: bytes=32 time=268ms TTL=102
Reply from 64.233.188.26: bytes=32 time=268ms TTL=102
Reply from 64.233.188.26: bytes=32 time=268ms TTL=102
Reply from 64.233.188.26: bytes=32 time=268ms TTL=102

Ping statistics for 64.233.188.26:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 268ms, Maximum = 268ms, Average = 268ms

S tim se tedy nic delat asi neda...

3

Server / Re:Pomale predani emailu na gmail.com

« kdy: 20. 03. 2023, 13:36:20 »

delay = 0.76:

Kód: [Vybrat]

Mar 20 10:30:57 mail postfix/smtp[1114821]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[142.250.27.26]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)
Mar 20 10:30:57 mail postfix/smtp[1114821]: 134AC2A004E: to=<***@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.27.26]:25, delay=0.76, delays=0.09/0.02/0.3/0.35, dsn=2.0.0, status=sent (250 2.0.0 OK  1679304657 q6-20020a1709064cc600b00934a633a6c1si1855786ejt.228 - gsmtp)
ale

delay = 15:

Kód: [Vybrat]

Mar 20 12:39:59 mail postfix/smtp[1125593]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[142.250.27.27]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
Mar 20 12:40:14 mail postfix/smtp[1125593]: E35222A00A2: to=<***@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.27.27]:25, delay=15, delays=0.38/0/0.34/14, dsn=2.0.0, status=sent (250 2.0.0 OK  1679312414 d5-20020a50fb05000000b004ad0993e54esi9779437edq.487 - gsmtp)

Třeba je to vytížením jejich serverů, čert ví. Náš server je nevytížený... Na servery Seznamu to dělá delay okolo 1.3 až 1.6. Na Gmail nejčastěji pod 1 sekundu, ale občas je tam anomálie, viz výše. Přiznám se, že mne to moc netrápí.

V obou pripadech vidim 3. polozku cca 0.3s (navazani spojeni vcetne tls). U mne to je vetsinou 2-3s. A to to bezi na G9 serverech virtualizovane...Servery jako takove taktez bez vyrazne zateze (at uz mailserver, ci hypervizor).

4

Server / Pomalé předání e-mailu na Gmail.com

« kdy: 20. 03. 2023, 12:17:44 »

Ahoj,

zhruba pred tydnem nam zakaznik oznamil, ze posilani emailu na gmail je s velkou prodlevou.

Kód: [Vybrat]

Mar 20 11:58:24 MAILSERVER postfix/smtp[1833743]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[108.177.97.26]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X
25519 server-signature ECDSA (P-256) server-digest SHA256
Mar 20 11:58:27 MAILSERVER postfix/smtp[1833743]: 4PgBYB1wBtz76: to=<SOMEUSER@gmail.com>, relay=gmail-smtp-in.l.google.com[108.177.97.26]:25, delay=4.8, delays=0.1/0/2.4/2.3, dsn=2.0.0, status=sent (2
50 2.0.0 OK  1679309906 l4-20020a056a00140400b005a8d595767asi10382056pfu.252 - gsmtp)

Z logu mam prumerne delay zhruba mezi 4-5s na gmail.com. Kolisa to nekde mezi 3. (navazani spojeni) a 4. (predani mailu) delay hodnotou. Ve chvili, kdy posleme hromadne emaily, tak se to zpozdeni sakra nascita. Ten zpomaleny stav trva doted.

Pro srovnani:

Kód: [Vybrat]

Mar 20 12:00:04 MAILSERVER postfix/smtp[1833743]: Untrusted TLS connection established to mx1.seznam.cz[2a02:598:2::1090]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-25
6) server-signature RSA-PSS (4096 bits) server-digest SHA256
Mar 20 12:00:04 MAILSERVER postfix/smtp[1833743]: 4PgBb74v0Pz76: to=<SOMEUSER@seznam.cz>, relay=mx1.seznam.cz[2a02:598:2::1090]:25, delay=1.3, delays=0.11/0/1.1/0.08, dsn=2.0.0, status=sent (250 2.0.0 message q
ueued (szn-id:4d044e47-a9b6-4975-a1bf-f1f84450a1fb))

Mar 20 11:56:32 MAILSERVER postfix/smtp[1833743]: Untrusted TLS connection established to centrum-cz-10mx2.eco-mx.cz[46.255.227.8]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Mar 20 11:56:32 MAILSERVER postfix/smtp[1833743]: 4PgBW40r3Qz76: to=<SOMEUSER@centrum.cz>, relay=centrum-cz-10mx2.eco-mx.cz[46.255.227.8]:25, delay=0.35, delays=0.1/0.01/0.06/0.18, dsn=2.0.0, status=sent (250 ok:  Message 11722009 accepted)

Netrpi nekdo stejnym zpozdenim ci nekomunikoval nekdo ohledne toho s googlem jiz? Dela nam to na ruznych konektivitach/verzich postfixu, takze serverovou stranu muzu vyloucit. A nezda se mi, ze by za to mohlo TLSv1.3.

Diky.

5

Server / PgBouncer a scram-sha-256

« kdy: 22. 02. 2023, 12:11:59 »

Ahoj,

upgradem na postgresql 15 se nam tak trochu rozpadla vazba pgbouncer/postgresql. Pgbouncer mame primo na postgresql stroji, ale i tak jsem mel nastavene prihlasovani heslem do postgresql. To v kombinaci md5/scram-sha-256 prestalo fungovat v kombinaci s auth_query. Tak jsem trochu zagoogloval a vyznelo z toho testovanim toto:

1] aby fungoval scram, je nutne, aby heslo v postgresql bylo scram jak pro uzivatele pgbouncer, tak pro samotneho zivatele
2] udajne funguje nastaveni scram retezce v userlist.txt pro pgbouncer
- mne ale funguje jen varianta s nesifrovanym heslem
- jinak chyba "cannot do SCRAM authentication: password is SCRAM secret but client authentication did not provide SCRAM keys"
 - je jedno, zda zadam scram retezec do login query psql nebo vyvolam zadani hesla napr. -W
3] nastavenim password_encryption = md5 v postgresql.conf funguje md5/scram kombinace

a] ma nekdo v provozu bod 2] s sifrovanym heslem?
b] v debianu je pgbouncer nainstalovany pod postgres uzivatelem, nelze vyuzit "peer" overeni v ramci localhostu. Je "trust" metoda v ramci localhostu povazovana za dostatecne bezpecna/blbuvzdorna? Samozrejme za predpokladu, ze prihlasit se na samotny server (ssh) muzou pouze administratori. Zde jeste povazuji za nestastne, ze dana "trust" by se musela v pg_hba.conf vlozit pred defaultni "host all all 127.0.0.1/32 scram-sha-256" (pres ansible nechavam default pg_hba a na konec pripojuji modifikace, bohuzel nestastne resene pg_hba od postgresql jede podle poradi)

Diky za nazory.

6

Sítě / Re:Monitoring sítě

« kdy: 20. 02. 2023, 08:53:30 »

Tak napriklad ja by som si "zelal":

*Prehlad co mi tecie z WANov (IP Tranzit providery) smerom k Hostom
**Ktore IPcky v ramci LAN/DMZ vyuzivaju traffic a kedy
**Ktore IPcky z Internetu najviac s nami komunikuju, kolko, kedy

*Prehlad IP Sec tunnelov (SA UP, ICMP Echo test, ...)
** Traffic ktory tade tecie z vnutra (kolko, kedy, encryption domain)

*Prehlad vytazenosti Eth portov... Cez monitor posrty napriklad?


Zakladny prehlad mam pomocou mrtg, ale len na urovni interfaceov. Chcelo by to viac.

Zkuste nejaky netflow type nastroj - ja mam nasazeny elastiflow + librenms. Ale neco jako encryption domain docela pochybuju, ze vetsina nastroju bude umet, to by to muselo tyhle veci umet vuci konkretnimu vpn koncentratoru.

7

Sítě / Re:Software pro dokumentaci síťové infrastruktury

« kdy: 02. 02. 2023, 09:23:23 »

Muzete to doplnit treba necim jako librenms ci podobnym sw, co bezi na principu snmp/autodetekce a vyuziva lldp pro propoje. Ale zadny sw nebude umet vse, bohuzel.

8

Server / Re:Automatický restart PostgreSQL

« kdy: 30. 01. 2023, 12:35:30 »

Ale zpatky k otazce - zejmena p. Stehule prosim - mate nejake informace ohledne dopadu automatickeho restartu vzhledem k tomu, co je za komentar v dane systemd service?

9

Server / Re:Automatický restart PostgreSQL

« kdy: 30. 01. 2023, 12:30:15 »

este by sa mozno oplatilo nastavit naky rozumny statement_timeout. samozrejme po dohovore s developermy.
ono to nejaky cas trva kym sa RAM zaplni ale ked tam na tom experimentuju tak sa to moze stat.

Paměť se i na dnešních velkých serverech zaplnit během několika málo desítek sec. 4GB server tak cca za 3sec. Timeouty nejsou ochranou vůči vyčerpání paměti, ale jsou ochranou proti nechtěnému nadužívání CPU a držení zámků neoptimálně prováděných dotazů.

tak to kazdopadne. ale...
1. potom sa ale nakopne swap a tam uz to tak rychle neni.
2. timouty su ochranou pred long running queries a to okrem CPU vytazuje aj RAM.
3. tazatel riesi development server a nejake sepalenie systemu kvoli nerealistickym queries je viac ako pravdepodobnost.

preto trvam na tom ze ten timeout by predsa len bolo dobre nastavit.

Timeoutem nic nezkazíte - otázkou je kolik? A otázkou je kolik času strávit s laděním konfigurace serveru, kde není hw odpovídající produkci, a kde asi není ani moc dat. V GoodData měl každý vývojář vlastní server ve vlastní virtuální mašině a staral se o něj (rozbíjel si ho) sám. V dev prostředí, pokud nemáte k dispozici slušné železo, a běží to na chcípačích, tak má smysl řešit jedině stabilitu provozu, zvlášť ve sdíleném prostředí. V dev prostředí každý může být super user, a dlouhoběžící dotazy může jednoduše zabít.

Performance testy jsou neskutečně důležité, a dost se podceňují, ale nemá cenu si hrát na bechmarking na poddimenzovaném hw a neadekvátně velkých testovacích datech.

neviem co chce checksys... minimalne tu swap bych dal na = RAM.

On ten swap taky neni zadarmo (storage,backupy, propagace do test/prod tieru atd). Ja ho tam ma jako nouzovku pro vycerpani ram, ale rovnice swap=ram uz davno pozbyla smysl.

10

Server / Re:Automatický restart PostgreSQL

« kdy: 25. 01. 2023, 14:21:11 »

Tak se k tomuto vracim.

Vytazek z postgresql@15-main, kde je komentar k automatickemu restartu:

Kód: [Vybrat]

[Service]
Type=forking
# -: ignore startup failure (recovery might take arbitrarily long)
# the actual pg_ctl timeout is configured in pg_ctl.conf
ExecStart=-/usr/bin/pg_ctlcluster --skip-systemctl-redirect %i start
# 0 is the same as infinity, but "infinity" needs systemd 229
TimeoutStartSec=0
ExecStop=/usr/bin/pg_ctlcluster --skip-systemctl-redirect -m fast %i stop
TimeoutStopSec=1h
ExecReload=/usr/bin/pg_ctlcluster --skip-systemctl-redirect %i reload
PIDFile=/run/postgresql/%i.pid
SyslogIdentifier=postgresql@%i
# prevent OOM killer from choosing the postmaster (individual backends will
# reset the score to 0)
OOMScoreAdjust=-900
# restarting automatically will prevent "pg_ctlcluster ... stop" from working,
# so we disable it here. Also, the postmaster will restart by itself on most
# problems anyway, so it is questionable if one wants to enable external
# automatic restarts.
#Restart=on-failure
# (This should make pg_ctlcluster stop work, but doesn't:)
#RestartPreventExitStatus=SIGINT SIGTERM

Mam to chapat tak, ze pokud se nastavi automaticky restart v ramci override, tak prestane fungovat i napr. ExecStop?

11

Server / Re:Automatický restart PostgreSQL

« kdy: 20. 01. 2023, 14:49:31 »

Limit je 100, ale ten vyuzity ani nebyl. Jo, 4GB neni moc, ten server je ale v dev vetvi, takze to zatim nebyl problem. Momentalni obsah je cca 7GB v databazich.

Kdovi, co tam vyvojari najoinovali dohromady a tak Zvlast s tim, ze OOM zabil primo postgre, pricemz mel z logiky veci nejdrive zabit netdata. Nj

12

Server / Re:Automatický restart PostgreSQL

« kdy: 20. 01. 2023, 11:05:29 »

Tak byla to zrovna postgresql 13.

Konfigurace pameti je 4GB ram, 2.5GB swap.
Zmeny v postgresql.conf vs defaulut:

Kód: [Vybrat]

effective_cache_size = 2751MB
effective_io_concurrency = 200
random_page_cost = 1.1
shared_buffers = 982MB
work_mem = 12MB


Kód: [Vybrat]

Out of memory: Killed process 543258 (postgres) total-vm:8059544kB, anon-rss:2024860kB, file-rss:0kB, shmem-rss:0kB, UID:111 pgtables:13904kB oom_score_adj:0


Kód: [Vybrat]

Jan 19 14:13:40  kernel: [1139300.451096] Free swap  = 0kB
Jan 19 14:13:40  kernel: [1139300.451097] Total swap = 2670588kB
Jan 19 14:13:40  kernel: [1139300.451098] 1048441 pages RAM
Jan 19 14:13:40  kernel: [1139300.451098] 0 pages HighMem/MovableOnly
Jan 19 14:13:40  kernel: [1139300.451099] 41986 pages reserved
Jan 19 14:13:40  kernel: [1139300.451100] 0 pages hwpoisoned

Ja myslim, ze proste vyvojarum dosla pamet na jejich sql dotazy

13

Server / Re:Automatický restart PostgreSQL

« kdy: 20. 01. 2023, 09:15:35 »

Zrovna databáze je aplikace, která by neměla padat nikdy. Pokud dojde k pádu databáze, znamená to, že je někde nějaký problém – chyba paměti, disku apod. Je dost pravděpodobné, že máte poškozená data, když nad tím databázi necháte znovu nastartovat, nejspíš dojde k tomu, že se bude poškození dat šířit dál.

K tomu poškození db by mělo dojít jen výjimečně, pokud dojde k poškození filesystému. Ale je fakt, že pokud admin musí explicitně nahodit db, tak ho to spíš dokope udělat nějakou investigaci. Na druhou stranu drtivá většina adminů tu investigaci stejně neudělá.

Diky, doufal jsem v komentar od Vas.

V tomto pripade zauradoval OOM killer. Asi do te automatiky pujdeme, poskozeni dat muze vzniknout i nenapadneji, nez restartem atd, od toho mame pak zalohy.

Dotaz na tu datovou integritu - netusite, jaky to ma vykonnostni dopad?

14

Server / Automatický restart PostgreSQL

« kdy: 19. 01. 2023, 15:35:50 »

Ahoj,

mam nainstalovane postgresql z apt.postgresql.org. Koukal jsem po jednom padu postgresql, proc automaticky nerestartovala, no protoze dana unita (typ oneshot) od maintenera nema nastavene "Restart" apod. parametry.

Ma nekdo zkusenost s nastavenim napr. podle diskuze na DigitalOcean? Narazilo se pri automatickem restartu na nejake specificke stavy, kdy autorestart zpusobil vetsi problem, nez uzitek?

Diky

15

Distribuce / Re:Automatické aktualizace PHP v Debianu

« kdy: 17. 01. 2023, 12:12:02 »

Taky se mi to stalo. Jako reseni jsem zvolil nepouzivat php-neco moduly, ale ciste phpVERZE-neco moduly. Pak nevzniknou zavislosti, ktere tahaji i dalsi verze php.