Příspěvky

1

Server / Re:Profi SMTP server

« kdy: 18. 05. 2023, 12:17:24 »

technicka: jakym zpusobem jste detekoval blokaci? monitoring - jak ?

Denní výpisy z logu Postfixu - pflogsumm. Když tam vidím nějakou "zajímavost", koumám to pak podrobněji v samotném logu. V tomto případě pflogsumm prozradil:

Kód: [Vybrat]

message bounce detail (by relay)
--------------------------------
eur.olc.protection.outlook.com[104.47.12.33]:25 (total: 1)
         1   27:51.756Z 08DB54CD99EBE39D] (in reply to MAIL FROM command)

A pak v logu:

Kód: [Vybrat]

May 15 14:27:51 mail postfix/smtp[198917]: 351B32A004F: to=<*****@outlook.cz>, relay=eur.olc.protection.outlook.com[104.47.12.33]:25, delay=0.57, delays=0.09/0.02/0.43/0.04, dsn=5.7.1, status=bounced (host eur.olc.protection.outlook.com[104.47.12.33] said: 550 5.7.1 Unfortunately, messages from [IP] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. [DB3EUR04FT064.eop-eur04.prod.protection.outlook.com 2023-05-15T12:27:51.756Z 08DB54CD99EBE39D] (in reply to MAIL FROM command))
A pak jsou tu uživatelé, co reportují, že jim někam nejde poslat e-mail. :-) Schválně jsem si testoval několik poštovních serverů, které máme, a všechny blokovány, takže M$ zablokoval zřejmě celý /24 subnet. Ani jednou ale nesdělili, kdo je původcem problému, jejich blacklist není bohužel veřejný.

Diky. Doufal jsem v neco automatizovaneho, mam desitky serveru a bounce ruzneho typu mam denne v desitkach ci vyssich radech. Zkoumanim vypisu pflogsummu bych travil hodiny denne :-)

2

Server / Re:Profi SMTP server

« kdy: 18. 05. 2023, 11:35:26 »

A také můžete mít svůj server sebelépe nastavený a stačí, aby měl váš ISP v části subnetu (ve kterém má vaše společnost  servery) nějakého spammera nebo zavirovaný stroj dalšího zákazníka a takový Microsoft rovnou zablokuje celý subnet včetně těch dobrých, a je úplně jedno, jestli jste na nějakých whitelistech a máte dokonalou reputaci...

To se před pár dny stalo nám. Vyřešil jsem to ihned, jak jsem blokaci detekoval, a to přesměrováním smtp komunikace jinam... Ale pak kolotoč žádostí o odblokaci s Microsoftem, fakt za trest. Zabere to nejeden den a zaručeně vás laxní přístup M$ rozpálí doběla. 

technicka: jakym zpusobem jste detekoval blokaci? monitoring - jak ?

3

Sítě / Re:Internet na lokalnim pc a firemni VPN

« kdy: 27. 04. 2023, 09:55:27 »

Zakladni vec je, komu patri lokalni pc.

4

Server / Re:Kdy a proč využít Docker nebo více serverů?

« kdy: 26. 04. 2023, 11:56:47 »

Díky,
ještě upřesním, z hlediska funkce celého systému nevadí, když při nějakém přetížení systému chvíli nepojede web a mobilní aplikace (uživatelé to překousnou) a případně sftp (data se přenesou později).
Ale je důležité, aby jely některé komunikační java aplikace, které neustále z databáze něco čtou a ukládají do ní. Tady i výpadek 10 sekund je nežádoucí.

Tak hodne stesti, to bude vyzadovat robustni HA reseni a tim i cena takoveho reseni bude jinde.

5

Server / Re:Nastavení reverse proxy pro směrování nedefinovaných domén na konkrétní VM

« kdy: 26. 04. 2023, 11:13:30 »

Ne, nelze. Reverzni proxy musi znat, kterou domenu ma poslat na jakou ip, takze pokud je konkretni domena na jine ip nez "nedefinovane domeny ip" (obvykle nejaky default), tak je nutno tu domenu v proxy definovat.

takze:
 dns prvni.cz -> fyzicka IP apache, virtualhost prvni.cz
 proxy, virtualhost default
 dns druha.cz -> fyzicka IP apache, proxy -> ip virtual
 dns nedefeinovana -> fyzicka IP apache, proxy -> "default" ip

Teoreticky ta varianta s wildcardem by sla, ale je to svazane s presne danym regex domeny a neexistujici virtualhosty splnujici wildcard pak skonci na nedefaultnim serveru.

6

Vývoj / Re:PHP 8.2 nevrací ve funkci date čas s timezone

« kdy: 17. 04. 2023, 12:15:57 »

Je to sice debian 11, ale php je z packages.sury.org/php

V release notes pro packages.debian.org je v release notes akorat info o prechod na 8.2 No uz je to tak nejak fuk, holt se to nastavi nekterym z uvedenych zpusobu a nebude se uz spolehat na automaticke vyuziti systemovych nastaveni.

7

Vývoj / Re:PHP 8.2 nevrací ve funkci date čas s timezone

« kdy: 17. 04. 2023, 11:32:02 »

Kód: [Vybrat]

root@testphp:/etc/php/8.1/cli# cat /etc/timezone
Europe/Prague

Dalsi zajimavost, proc vraci php timezone Europe/Berlin, kdyz mam nastaveno Europe/Prague :-)

php.ini nie je jediny konfigurak ktory php pouzije. Kludne to mozes mat prepisane niekde inde.
Ked tak si vypis ktore konfiguraky natahuje:

Kód: [Vybrat]

/usr/bin/php8.1 --ini

/usr/bin/php8.2 --ini


Kód: [Vybrat]

root@testphp:~# /usr/bin/php8.1 --ini
Configuration File (php.ini) Path: /etc/php/8.1/cli
Loaded Configuration File:         /etc/php/8.1/cli/php.ini
Scan for additional .ini files in: /etc/php/8.1/cli/conf.d
Additional .ini files parsed:      /etc/php/8.1/cli/conf.d/10-opcache.ini,
/etc/php/8.1/cli/conf.d/10-pdo.ini,
/etc/php/8.1/cli/conf.d/20-calendar.ini,
/etc/php/8.1/cli/conf.d/20-ctype.ini,
/etc/php/8.1/cli/conf.d/20-exif.ini,
/etc/php/8.1/cli/conf.d/20-ffi.ini,
/etc/php/8.1/cli/conf.d/20-fileinfo.ini,
/etc/php/8.1/cli/conf.d/20-ftp.ini,
/etc/php/8.1/cli/conf.d/20-gettext.ini,
/etc/php/8.1/cli/conf.d/20-iconv.ini,
/etc/php/8.1/cli/conf.d/20-phar.ini,
/etc/php/8.1/cli/conf.d/20-posix.ini,
/etc/php/8.1/cli/conf.d/20-readline.ini,
/etc/php/8.1/cli/conf.d/20-shmop.ini,
/etc/php/8.1/cli/conf.d/20-sockets.ini,
/etc/php/8.1/cli/conf.d/20-sysvmsg.ini,
/etc/php/8.1/cli/conf.d/20-sysvsem.ini,
/etc/php/8.1/cli/conf.d/20-sysvshm.ini,
/etc/php/8.1/cli/conf.d/20-tokenizer.ini

root@testphp:~# /usr/bin/php8.2 --ini
Configuration File (php.ini) Path: /etc/php/8.2/cli
Loaded Configuration File:         /etc/php/8.2/cli/php.ini
Scan for additional .ini files in: /etc/php/8.2/cli/conf.d
Additional .ini files parsed:      /etc/php/8.2/cli/conf.d/10-opcache.ini,
/etc/php/8.2/cli/conf.d/10-pdo.ini,
/etc/php/8.2/cli/conf.d/20-calendar.ini,
/etc/php/8.2/cli/conf.d/20-ctype.ini,
/etc/php/8.2/cli/conf.d/20-exif.ini,
/etc/php/8.2/cli/conf.d/20-ffi.ini,
/etc/php/8.2/cli/conf.d/20-fileinfo.ini,
/etc/php/8.2/cli/conf.d/20-ftp.ini,
/etc/php/8.2/cli/conf.d/20-gettext.ini,
/etc/php/8.2/cli/conf.d/20-iconv.ini,
/etc/php/8.2/cli/conf.d/20-phar.ini,
/etc/php/8.2/cli/conf.d/20-posix.ini,
/etc/php/8.2/cli/conf.d/20-readline.ini,
/etc/php/8.2/cli/conf.d/20-shmop.ini,
/etc/php/8.2/cli/conf.d/20-sockets.ini,
/etc/php/8.2/cli/conf.d/20-sysvmsg.ini,
/etc/php/8.2/cli/conf.d/20-sysvsem.ini,
/etc/php/8.2/cli/conf.d/20-sysvshm.ini,
/etc/php/8.2/cli/conf.d/20-tokenizer.ini

Zadny rozdil...

8

Server / Re:iSCSI Multipathing v Proxmox

« kdy: 14. 04. 2023, 09:06:32 »

Diky, kouknu.

Ja jsem ted zkusil dve veci:

1] pridani 2x10Gbps sitovky a pro kazdy  iscsi port odlisny subnet, bez openvswitch/lacp
2] zmenit na openvswitchi pro ty 2x iscsi porty z jednohu subnetu na dva odlisne subnety

V obou pripadech multipath zafungoval jak ma - pouzil oba iscsi porty a v pripade 2] to pri testu i teklo po obou lacp linkach. Takze to vypada, ze jeden subnet pro vice src ip na pve nebude fungovat bez dalsi magie, takze to holt predelame na aspon 2 subnety.

9

Vývoj / Re:PHP 8.2 nevrací ve funkci date čas s timezone

« kdy: 13. 04. 2023, 10:16:53 »

Ve verzi 8.1 se pri nenastaveni date.timezone vzalo nastaveni systemu a PHP vyhazovalo varovani:

Kód: [Vybrat]

It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier.
Je tedy otazka, jestli nemate skryta varovani.

Od verze 8.2 je toto varovani pryc a pouziva se UTC jako default.

Tohle by bylo zrejme to, co hledam, ale kde je takovahle zmena zapsana? nejaky release notes/commit?

10

Vývoj / Re:PHP 8.2 nevrací ve funkci date čas s timezone

« kdy: 13. 04. 2023, 10:14:12 »

Zapnul jsem zobrazovani chyb:

Kód: [Vybrat]

root@testphp:/etc/php/8.1/cli# grep display_errors /etc/php/8.?/cli/php.ini
/etc/php/8.1/cli/php.ini:; display_errors
/etc/php/8.1/cli/php.ini:;display_errors = Off
/etc/php/8.1/cli/php.ini:display_errors = On
/etc/php/8.1/cli/php.ini:; separately from display_errors. We strongly recommend you set this to 'off'
/etc/php/8.2/cli/php.ini:; display_errors
/etc/php/8.2/cli/php.ini:;display_errors = Off
/etc/php/8.2/cli/php.ini:display_errors = On
/etc/php/8.2/cli/php.ini:; separately from display_errors. We strongly recommend you set this to 'off'

root@testphp:/etc/php/8.1/cli# grep error_reporting /etc/php/8.?/cli/php.ini
/etc/php/8.1/cli/php.ini:; error_reporting
/etc/php/8.1/cli/php.ini:;error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
/etc/php/8.1/cli/php.ini:error_reporting = E_ALL
/etc/php/8.2/cli/php.ini:; error_reporting
/etc/php/8.2/cli/php.ini:;error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
/etc/php/8.2/cli/php.ini:error_reporting = E_ALL


Kód: [Vybrat]

root@testphp:/etc/php/8.1/cli# /usr/bin/php8.1 /opt/date.php
2023-04-13 10:08:44
string(13) "Europe/Berlin"

root@testphp:/etc/php/8.1/cli# /usr/bin/php8.2 /opt/date.php
2023-04-13 08:08:48
string(3) "UTC"

Doplnil jsem do date parametr "T":

Kód: [Vybrat]

root@testphp:/opt# cat date.php
<?php

$date = date('Y-m-d H:i:s T');
echo $date;
echo "\n";
var_dump(date_default_timezone_get());
echo "\n";
?>


Kód: [Vybrat]

root@testphp:/opt# /usr/bin/php8.1 /opt/date.php
2023-04-13 10:11:26 CEST
string(13) "Europe/Berlin"

root@testphp:/opt# /usr/bin/php8.2 /opt/date.php
2023-04-13 08:11:28 UTC
string(3) "UTC"


Kód: [Vybrat]

root@testphp:/etc/php/8.1/cli# cat /etc/timezone
Europe/Prague

Dalsi zajimavost, proc vraci php timezone Europe/Berlin, kdyz mam nastaveno Europe/Prague :-)

11

Vývoj / Re:php8.2 nevraci ve funkci date cas s timezone

« kdy: 13. 04. 2023, 08:48:20 »

Ja mam v gentoo config per verzi, takze mozna ti vypadl konfiguracni radek? -- vidim ze asi ne.

Udelej si tedy dump runtime nastaveni - treba z ini_get_all a udelej diff
https://www.php.net/manual/en/function.ini-get-all.php

Pripadne ten timezone zkontroluj pres date_default_timezone_get
https://www.php.net/manual/en/function.date-default-timezone-get.php

8.1 ini_get_all();

Kód: [Vybrat]

    [date.timezone] => Array
        (
            [global_value] =>
            [local_value] =>
            [access] => 7
        )

8.1 date_default_timezone_get():

Kód: [Vybrat]

2023-04-13 08:47:47
string(13) "Europe/Berlin"


8.2 ini_get_all():

Kód: [Vybrat]

    [date.timezone] => Array
        (
            [global_value] => UTC
            [local_value] => UTC
            [access] => 7
        )

8.2 date_default_timezone_get:

Kód: [Vybrat]

2023-04-13 06:47:44
string(3) "UTC"


12

Vývoj / Re:php8.2 nevraci ve funkci date cas s timezone

« kdy: 13. 04. 2023, 08:38:47 »

Ak timezone nieje nastavena cez date_default_timezone_set() a ani v php.ini (tvoj pripad) tak defaultna timezona je UTC, takze 8.2 to ma spravne.

Tim jste nevysvetlil, proc to ma 8.1 jinak.

13

Vývoj / Re:PHP 8.2 nevrací ve funkci date čas s timezone

« kdy: 13. 04. 2023, 08:38:12 »

Koukám správně, že v php.ini jsou oba řádky s proměnnou "date.timezone =" zakomentované?
Tzn. se použije nějaký compile-time default?

Vidím dva balíčky, které mají v názvu "debian", různé číslo verze, ale stejné datum... to vznikne jak? Je to přirozená vlastnost nějakého upstream build systému, nebo jste si je kompiloval a balil sám? (vrtá mi hlavou možná další souvislost třeba s locale v okamžiku kompilace)

vzdyt je v tom vypisu videt ze je to z packages.sury.org...Takze zadna kompilace.

14

Server / Re:iSCSI Multipathing v Proxmox

« kdy: 12. 04. 2023, 17:05:59 »

Aby byl funkcni multipath, co je potreba?
[a dál dotaz na kombinace IP subnety vs. porty na storage boxu]

To je dobrá otázka. Podle mého záleží, co umí ten storage box.

Pokud to má uvnitř jedinou instanci firmwaru, která vidí ty své čtyři porty jako eth0...eth3, tak bez dalšího bych řekl, že nemá smysl dávat těm čtyřem rozhraním IP adresy z jediného společného subnetu. V tom případě totiž traffic směrem ven pojede nejspíš jediným rozhraním. Aspoň takto by se choval standardní Linux.

Jak se tu nedávno probíralo, i v tom Linuxu se dá zařídit, aby "odpovědi odcházely stejným rozhraním, odkud přišel dotaz" (per TCP spojení) - ale znamená to nějaké hraní s iptables, ten storage box by musel řešit connection tracking a nějaké navazující věci... odhadem by to mohlo být procesorově náročné a tedy nežádoucí. Nebo by na to výrobce musel mít nějaký svůj vlastní modul v kernelu - nemohu vyloučit, viděl jsem už různá zvěrstva.

Tezko rict, dovnitr nevidim. Ale sitovky se daji konfigurovat L2,L3, bonding, port groupy, etc, takze...

Uměl by ten storage box proti switchi trunking / bonding? Toto buď pomocí LACP nebo i bez. Pokud ano uměl, můžou se dvě a více rozhraní chovat jako "failover group", možná dokonce s jakýmsi load balancingem, a tím pádem ten storage box může mít klidně jedinou společnou IP adresu.

Umi. Ale v pripade bondingu bude prece vykon degradovany minimalne na urovni linky ne? Jedine spojeni pve(ip:port)->box(ip:port)?

Obecně by mělo fungovat, postavit to jako dvojhvězdu. Každý PVE box po jednom fousu do každé hvězdy, každý storage box taktéž (dva porty storage boxu by zůstaly "na ocet"). A na každou L2 hvězdu jiný L3 subnet.

Grammar nazi poznámka: mít dva samostatné storage boxy připojené k jedinému hostiteli, a provozovat nad nimi nějaký (geograficky) rozprostřený mirror, to je terminologicky něco jiného, než multipath.

Multipath znamená, že máte jeden storage box (dokonce jeden LUN) vidět z jednoho hostitele dvěma nezávislými cestami. Za starých časů bych ke "sloučení do jednoho blokového zařízení" použil v Linuxu modul dm-multipath.

Nad temi boxy bude HA sluzba, takze ten mirror by nemel byt problem.

Ono v Linuxu jde ledacos poskládat "holýma rukama" na kterékoli distribuci, ale některé distribuce mají své vlastní specifické uživatelsky příjemné nástroje...

Mimochodem než geograficky rozprostřený mirror z blokových zařízení, zvážil bych možná spíš CEPH, pokud tomu jde naproti geografické rozmístění počítačů. A tahat storage traffic skrz L3 router by mi kdysi taky připadalo jako svatokrádež. Já vím - lepším switchům je už asi dvacet let dost jedno, jestli forwardují L2 nebo L3.

ceph jsme zvazovali, nakonec dostal prednost SAN. Co se tyce L3, vzdy peclive premyslime, zda roztahnute L2 ma smysl (konfiguracni schopnosti switche). Tohle je asi prvni pripad roztahnute L2 (replikace), ale iscsi zatim mame L3.

Tldr: zatim resim, jak vlastne nastavit site na PVE, aby spravna kombinace adresace/portu fungovala - je tam lacp, bridge atd...proste sdilena sitova konfigurace. A nez budu predelavat na subnet per sitovy port, tak zjistuji, zda nemam botu jinde. Prvotni predpoklad je, ze ten box ten multipath umi podle ocekavani - tzn. vice IP na pve a vice IP na boxu.

15

Vývoj / PHP 8.2 nevrací ve funkci date čas s timezone

« kdy: 12. 04. 2023, 16:19:26 »

php.ini:

Kód: [Vybrat]

root@testphp:/opt# grep timezone /etc/php/8.?/cli/php.ini
/etc/php/8.1/cli/php.ini:; Defines the default timezone used by the date functions
/etc/php/8.1/cli/php.ini:; https://php.net/date.timezone
/etc/php/8.1/cli/php.ini:;date.timezone =
/etc/php/8.2/cli/php.ini:; Defines the default timezone used by the date functions
/etc/php/8.2/cli/php.ini:; https://php.net/date.timezone
/etc/php/8.2/cli/php.ini:;date.timezone =

Skript:

Kód: [Vybrat]

cat /opt/date.php
<?php

$date = date('Y-m-d H:i:s');
echo $date;
echo "\n";
?>
Testy:

Kód: [Vybrat]

root@testphp:/opt# /usr/bin/php8.2 /opt/date.php
2023-04-12 14:00:22

root@testphp:/opt# /usr/bin/php8.1 /opt/date.php
2023-04-12 16:00:26

root@testphp:/opt# timedatectl
               Local time: Wed 2023-04-12 16:00:34 CEST
           Universal time: Wed 2023-04-12 14:00:34 UTC
                 RTC time: Wed 2023-04-12 14:00:35
                Time zone: Europe/Prague (CEST, +0200)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no


Kód: [Vybrat]

root@testphp:~# apt-cache policy php8.2-cli
php8.2-cli:
  Installed: 8.2.4-1+0~20230409.18+debian11~1.gbp556b04
  Candidate: 8.2.4-1+0~20230409.18+debian11~1.gbp556b04
  Version table:
 *** 8.2.4-1+0~20230409.18+debian11~1.gbp556b04 990
        990 https://packages.sury.org/php bullseye/main amd64 Packages
        100 /var/lib/dpkg/status
root@testphp:~# apt-cache policy php8.1-cli
php8.1-cli:
  Installed: 8.1.17-1+0~20230409.38+debian11~1.gbp0c3ecb
  Candidate: 8.1.17-1+0~20230409.38+debian11~1.gbp0c3ecb
  Version table:
 *** 8.1.17-1+0~20230409.38+debian11~1.gbp0c3ecb 990
        990 https://packages.sury.org/php bullseye/main amd64 Packages
        100 /var/lib/dpkg/status

Je to bug ci ne? Nemuzu najit v release notes php8.2, co by se k tomu dalo priradit.