Fórum Root.cz

Hlavní témata => Server => Téma založeno: czechsys 22. 03. 2022, 11:39:08

Název: Přístup k logům mailserveru
Přispěvatel: czechsys 22. 03. 2022, 11:39:08
Ahoj,

z duvodu kompletni prestavby naseho mailoveho reseni potrebuji vyresit pristup logum mailserverum, aby z nich mohla nase aplikace tahat data. Jde zejmena o maximalni spolehlivost.

Momentalni nastaveni je takove, ze na mailserveru bezi skripty, ktere parsuji logy a predavaji to zpracovatelskemu serveru. Na ten zpracovatelsky server jsou pak navazany nase dalsi aplikace. Tech mailovych serveru bude mnohem vice, takze overuji cestu, zda to parsovani logu nepresunout z mailserveru primo na zpracovatelsky. Otazkou je, ale jak zajistit spolehlivy pristup. Logy postfixu jsou navic nepristupne beznemu uzivateli

Varianty co me napadaji (styl veskery obsah logu, at si to pak prefiltruji vyvojari):
a] ssh omezeny na "cat mail.log" - pull
b] neco ve stylu filebeat apod.  - push

Mala komplikace je, ze napr. filebeat jiz pouzivam pro graylog. A graylog tu mame v rezimu - kdyz to bezi, fajn, kdyz ne, nic se nedeje. Takze napojeni zpracovatelskeho systemu na graylog neni vhodne a filebeat tedy nevyuziju.

Jeste me napadlo logovani primo do db z postfixu, ale to jsem nikdy nezkousel. Jde o to, aby i ten redeployment serveru byl jednodussi nez doted (kontejnery nevedeme).

Diky za napady.
Název: Re:Pristup k logum mailserveru
Přispěvatel: M Z 22. 03. 2022, 12:52:35
Ahoj,
mate nejaky duvod proc nepouzit standardni syslog? Napr. rsyslog umi lokalni frontu na klientu v pripade vypadku site/serveru a pres protokol REPL by melo byt zaruceno 100% doruceni logu na server.
Michal
Název: Re:Pristup k logum mailserveru
Přispěvatel: jesjim 22. 03. 2022, 13:33:18
Ahoj,
mate nejaky duvod proc nepouzit standardni syslog? Napr. rsyslog umi lokalni frontu na klientu v pripade vypadku site/serveru a pres protokol REPL by melo byt zaruceno 100% doruceni logu na server.
Michal

Přimlouvám se za rsyslog. A zlomit ho na logování přímo do DB je otázka chvilky.
Název: Re:Pristup k logum mailserveru
Přispěvatel: czechsys 22. 03. 2022, 13:58:34
Ahoj,
mate nejaky duvod proc nepouzit standardni syslog? Napr. rsyslog umi lokalni frontu na klientu v pripade vypadku site/serveru a pres protokol REPL by melo byt zaruceno 100% doruceni logu na server.
Michal

Přimlouvám se za rsyslog. A zlomit ho na logování přímo do DB je otázka chvilky.

Rsyslog me nenapadl, pro kriticke veci ho nepouzivame. Zatim bych preferoval cestu specifickych nastroju, ale zaradim to do moznosti.
Název: Re:Přístup k logům mailserveru
Přispěvatel: M Z 22. 03. 2022, 19:51:23
To je zajimavy, kdybych neco takoveho resil mel bych to presne obracene. Na kriticke veci bych nasadil rsyslog a nejake blbosti v testu bych slepil z ssh, awk atd. :D
Název: Re:Přístup k logům mailserveru
Přispěvatel: czechsys 23. 03. 2022, 09:08:19
Zatim se mi libi toto:
https://nxlog.co/documentation/nxlog-user-guide/postfix.html at uz v rezimu filtrovani ci poslat veskery text
+ pripadne
https://nxlog.co/documentation/nxlog-user-guide/om_dbi.html

Do budoucna pripadne to cist rovnou z journald
https://nxlog.co/documentation/nxlog-user-guide/linux-logs.html#reading-systemd-journal
Název: Re:Přístup k logům mailserveru
Přispěvatel: _Tomáš_ 23. 03. 2022, 10:55:51
nxlog má funkci reliable delivery při přerušení tcp spojení až v placené verzi, to je povětšinou dost zásadní funkce a nechceš ztrácet logy při restartech servové části.

Proč chceš používat tyhle obskurní nástroje (ano, nxlog je prostě takový běžný enterprise SW, u nás ho třeba máme v rajfce) místo poměrně etablovaného a stabilního řešení v podobě rsyslogu? Stejně tak se tady nabízí ještě syslog-ng.

Ty moderní nástroje mají často problém se spolehlivostí, neumí se snadno vypořádat s pády, restarty, rotováním souborů a jinými neduhami.

U postfixu se mi dlouhé roky osvědčuje používat syslog logování, dávat to do rsyslog relay s lokální cache a rovnou posílat na rsyslog server, z kterého se to poté již může distribuovat do různých grafických udělátek. Při výpadku konektivity se logy pošlou dodatečně, mohu jednoduše alertovat, když logy přestanou chodit, mám to jednotné s ostatními nástroji a infrastrukturou.

Z těch placených je poměrně solidní Splunk, umí se totiž asi nejlépe vypořádávat s rotováním souborů, jejich truncování po rotování, s přejmenováním a jinými operacemi, když už teda pustíš aplikaci, aby si mohla sama spravovat logy a sama do nich zapisovat.
Název: Re:Přístup k logům mailserveru
Přispěvatel: czechsys 23. 03. 2022, 12:42:40
nxlog má funkci reliable delivery při přerušení tcp spojení až v placené verzi, to je povětšinou dost zásadní funkce a nechceš ztrácet logy při restartech servové části.

Proč chceš používat tyhle obskurní nástroje (ano, nxlog je prostě takový běžný enterprise SW, u nás ho třeba máme v rajfce) místo poměrně etablovaného a stabilního řešení v podobě rsyslogu? Stejně tak se tady nabízí ještě syslog-ng.

Ty moderní nástroje mají často problém se spolehlivostí, neumí se snadno vypořádat s pády, restarty, rotováním souborů a jinými neduhami.

U postfixu se mi dlouhé roky osvědčuje používat syslog logování, dávat to do rsyslog relay s lokální cache a rovnou posílat na rsyslog server, z kterého se to poté již může distribuovat do různých grafických udělátek. Při výpadku konektivity se logy pošlou dodatečně, mohu jednoduše alertovat, když logy přestanou chodit, mám to jednotné s ostatními nástroji a infrastrukturou.

Z těch placených je poměrně solidní Splunk, umí se totiž asi nejlépe vypořádávat s rotováním souborů, jejich truncování po rotování, s přejmenováním a jinými operacemi, když už teda pustíš aplikaci, aby si mohla sama spravovat logy a sama do nich zapisovat.

Diky za zhodnoceni.
Ja pouzivam filebeat pro graylog, ktery s rotacemi logu a vypadky spojeni problem nema, tak jsem necekal u nxlogu, ze by to bylo v zakladni verzi problem. Ale protoze se mi automaticky konfiguruje z graylogu, tak ho jiz vyuzit nemuzu.

Duvodu, proc nepouzivam rsyslog na tyhle veci (pokud to z principu jinak nejde, napr. switche) je tento:
1] vice a vice se prechazi na journald
2] standarizace konfigurace/zabezpeceni/nahraditelnost aplikace nasaditelna defacto vsude, nez se prat s tim, jak to rsyslogem nekam poslat
3] nesnasim regexpy, je to neintuitivni, casovy zrout
Název: Re:Přístup k logům mailserveru
Přispěvatel: _Tomáš_ 23. 03. 2022, 13:13:57
rsyslogd má modul imjournal, který umí číst journald logy a ty případně poslat beztrátově někam ven, tak to i používám. Journald je spíše nástroj na čtení a pohled na logy než jejich dlouhodobé ukládání.

Filebeat se právě s rotováním nevypořádává dobře, viz https://www.elastic.co/guide/en/beats/filebeat/current/file-log-rotation.html, podporuje rotování, která třeba dělá logrorate, kdy se soubor přejmenuje a vytvoří místo něho nový, už ale nepodporuje truncatování souboru, gzipování atd. On to není špatný SW, ale od něčeho, co je pro mě kritické nečekám, že se bude aktualizovat několikrát do roka o nové funkce a rozbíjet ty staré, takže to chce pozorně testovat kažou novou verzi. Těch případů, kdy se data.json při aktualizaci promazal a poslalo to vše znovu nebo po pár dnech přestal logovat jsem už zažil až příliš.

rsyslogd používám tak 15 let, konfiguraci je přenosná, vše se chová stejně a stabilně, nejsou problémy s aktualizacemi a dostupnost je na všech platformách, nevadí tomu být případně spuštění někde v dockeru či standalone.

Na druhou stranu konfiguraci rsyslogd má plnou komentářů, protože do toho šahám tak málo, že si to nepamatuji, naopak tu u filebeat umím zapsat asi zpaměti, protože do toho šaháme pořád, pořád je potřeba něco luštit z dokumentace a debugovat.

Když už máš rád tyhle nové věci, možná ještě mrkni na fluentbit, je to tenké, konfigurace je čitelná, je možné jí různě řetězit, dobře testovat přes sample inputy, má to exporty metrik v prometheu formátu a umíš konfiguraci přímo přikompilovat do kódu, takže můžeš mít jednu distribuční binárku, kterou stačí spustit a obsahuje vše.

Název: Re:Přístup k logům mailserveru
Přispěvatel: Alibaban 23. 03. 2022, 18:54:12
Jednoznačne sa prikláňam k rsyslog / syslog-ng . Sú to veľmi spoľahlivé aplikácie, nemajú divné stavy - raz sa nakonfigurujú a už sa na ne nemusí nikdy siahať. Konfigurácia napríklad oproti filebeatu je až primitívne jednoduchá a jasná.

Syslog-ng mám produkčne vyskúšaný aj v roli central log servera a absolútna spokojnosť.
Název: Re:Přístup k logům mailserveru
Přispěvatel: czechsys 24. 03. 2022, 09:22:14
No holt to budu muset odzkouset, zda se.
Prave ze u tech non-rsyslog nastroju mi vyhovuje, ze to jde napojit primo na cteni souboru (kdyz zatim existuji), takze rekonfigurace/restarty techto sluzeb se umi "vratit na posledni bod". Reseni s rsyslogd tohle ale "zpetne" nedela...

Ono jde i o vykon, na tom starem serveru jedeme i 20 tisic mailu za hodinu, tady ocekavame zrychleni zprocesovani...
Název: Re:Přístup k logům mailserveru
Přispěvatel: _Tomáš_ 24. 03. 2022, 09:39:16
ten pattern se dělá ale jiný, logy posíláš na syslog daemona (buď socket nebo localhost udp, postfix podporuje), tím daemonem je rsyslogd a ten vytváří soubor, posílá data jinám a routuje to. Hlavní důvod je, že prostě nechceš nechat plný přístup na logy pro aplikaci, v případě průniku by totiž útočník mohl logy promazat, chyba v aplikaci smaže logy atd., to jsou vše rizika a lepší je se jim vyhnout.

Pokud chceš číst soubor, rsyslogd má modul imfile a ten umí pokračovat ve čtení po restartu, viz dokumentace https://www.rsyslog.com/doc/v8-stable/configuration/modules/imfile.html a věta "When rsyslogd is stopped while monitoring a text file, it records the last processed location and continues to work from there upon restart"

20 tis emailů za hodinu není velké číslo, rsyslogem na na produkcích teče tohle množství každou vteřinu. Asi všechny tyhle nástroje zvládnou 20 tis / hod bez komplikací.
Název: Re:Přístup k logům mailserveru
Přispěvatel: supreme.commander 24. 03. 2022, 09:50:06
Syslog-ng mám produkčne vyskúšaný aj v roli central log servera a absolútna spokojnosť.

U nas tiez pouzivame syslog-ng ako centralny log server. Syslog-ng sype logy do Kafka clusteru a cunsumery si uz z Kafiek sosaju data podla potreby. Krasne, blbu vzdorne, vypadku vzdorne riesenie, ktore nam nie raz zachranilo zadeke.

syslog-ng sme uprednostnili pred rsyslog koli lepsiemu a citatelnejsiemu konfigu, lepsej dokumentacii a tak isto koli lepsej moznosti pre-processingu a integracii s Kafka na syslog-ng serveroch.
Název: Re:Přístup k logům mailserveru
Přispěvatel: czechsys 24. 03. 2022, 12:10:27
No tak my tu nemame ani kafku, s elastikem experimentujeme teprve takze...nam zbyva jen prenos textovych logu nebo to sypat rovnou do db.

20t/hod je vykonovy limit soucasneho serveru, kdyz dojde k jeho zahlceni (cca 7k per postfix instance, je jich tam vic), realne posilame objemy i nad sto tisic. To vlastne si jeste musime rict, zda to budeme prenaset davkove ci realtime...

Nemluve o pripadne zatezi "ciloveho" log serveru.
Název: Re:Přístup k logům mailserveru
Přispěvatel: dante11235 24. 03. 2022, 20:31:18
Skus pozret Vector od datadog https://vector.dev/ je to dost lightweight, vie to transformaciu a posiela to na rozne outputy (aj na viacere naraz)
Název: Re:Přístup k logům mailserveru
Přispěvatel: _Tomáš_ 25. 03. 2022, 00:12:42
Skus pozret Vector od datadog https://vector.dev/ je to dost lightweight, vie to transformaciu a posiela to na rozne outputy (aj na viacere naraz)

vector je zajímavý projekt, hlavně mají skvělé testy všech dalších logovátek, což je velice užitečné i samostatně, ale hlavně ty testy ukazují, že ještě tak lightweight nejsou a ještě jim nějaká práce chybí.

Na produkci takový SW dnes nedoporučuji, obsahuje pořád drobné bugy a není vyladěný, viz třeba memory leak https://github.com/vectordotdev/vector/issues/11863, https://github.com/vectordotdev/vector/issues/11821 nebo leak otevřeného descriptoru https://github.com/vectordotdev/vector/issues/11742. To jsou bugy za poslední měsic ve stabilní verzi.

Věnuji se kritické infrastruktuře v enterprise sféře, v labu tyhle nástroje postupně testujeme, ale je to pořád bídá, spíše nestabilní bída. Je potřeba si ty proklamace na webu ověřovat a udělat si testy. Zatím to nepoužívá tolik firem v produkci, aby se ukázaly všechny nedostatky. S logováním je největší problém, že ho člověk kriticky potřebuje v momentě, kdy se dějí nějaké problémy a pokud ty problémy zároveň sestřelí logovací nástroj, mám na stole skoro katastrofu. Aby nástroj na sbírání logů bral více paměti než aplikace, kterou loguje je již na pováženou, stejně když tyhle nástroje obsahují nějakou formu dynamické alokace a GC (např. filebeat), lze čekat problémy s paměti, pauzováním procesu a nestabilními latencemi.
Název: Re:Přístup k logům mailserveru
Přispěvatel: M_D 29. 03. 2022, 12:09:43
Zmiňuje se tu rsyslog a jeho REPL protokol - je šance na něco spolehlivého, pokud potřebuji, aby rsyslog předával svoje data na syslog-ng server? Pokud vím, tak syslog-ng nepodporuje REPL protokol. Takže maximum je tak TCP spojení s lokálním bafrem.
Název: Re:Přístup k logům mailserveru
Přispěvatel: czechsys 30. 03. 2022, 16:05:09
Tak jsem jeste narazil na systemd-journal-remote resp. systemd-journal-upload a systemd-journal-gatewayd. Ani jsem netusil, ze to existuje...
Název: Re:Přístup k logům mailserveru
Přispěvatel: czechsys 30. 03. 2022, 16:25:12
Tak jsem jeste narazil na systemd-journal-remote resp. systemd-journal-upload a systemd-journal-gatewayd. Ani jsem netusil, ze to existuje...

Pridam si sem popis, jak to muze fungovat:
https://www.digitalocean.com/community/tutorials/how-to-centralize-logs-with-journald-on-debian-10
https://sematext.com/blog/journald-logging-tutorial/
Název: Re:Přístup k logům mailserveru
Přispěvatel: czechsys 20. 04. 2022, 14:29:47
Tak zkousim doporucenou rsyslog variantu, ctu z mail.log, zapisuju primo do vzdalene psql databaze, zatez to umi udelat peknou :D Takze me zatim zaujal restart rsyslogu  ;D:

Kód: [Vybrat]
Apr 20 14:25:31 HOSTNAME kernel: [778771.993811] rsyslogd[57142]: segfault at 1a ip 00007fa80c9ba73c sp 00007fff55af8ee0 error 4 in libc-2.31.so[7fa80c955000+14b000]
Apr 20 14:25:31 mail-11 kernel: [778771.993826] Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 83 ec 18 48 8b 05 cd 37 13 00 48 8b 00 48 85 c0 0f 85 81 00 00 00 48 85 ff 74 74 <48> 8b 47 f8 48 8d 77 f0 a8 02 75 38 48 8b 15 29 36 13 00 64 48 83

Název: Re:Přístup k logům mailserveru
Přispěvatel: _Tomáš_ 20. 04. 2022, 16:14:39
Tak zkousim doporucenou rsyslog variantu, ctu z mail.log, zapisuju primo do vzdalene psql databaze, zatez to umi udelat peknou :D Takze me zatim zaujal restart rsyslogu  ;D:

Kód: [Vybrat]
Apr 20 14:25:31 HOSTNAME kernel: [778771.993811] rsyslogd[57142]: segfault at 1a ip 00007fa80c9ba73c sp 00007fff55af8ee0 error 4 in libc-2.31.so[7fa80c955000+14b000]
Apr 20 14:25:31 mail-11 kernel: [778771.993826] Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 83 ec 18 48 8b 05 cd 37 13 00 48 8b 00 48 85 c0 0f 85 81 00 00 00 48 85 ff 74 74 <48> 8b 47 f8 48 8d 77 f0 a8 02 75 38 48 8b 15 29 36 13 00 64 48 83

jaký máš OS a jakou verzi systemd, verzi rsyslogd?

Tohle je hodně netradiční chyba, error 4 vznikl v libc-2.31.so a ta 4 znamená čtení nemapované paměti. Chytl to traps.h, to vypadá buď na nějaký divný bug nebo nekonzistentní knihovny.
Název: Re:Přístup k logům mailserveru
Přispěvatel: czechsys 21. 04. 2022, 10:08:20
Tak zkousim doporucenou rsyslog variantu, ctu z mail.log, zapisuju primo do vzdalene psql databaze, zatez to umi udelat peknou :D Takze me zatim zaujal restart rsyslogu  ;D:

Kód: [Vybrat]
Apr 20 14:25:31 HOSTNAME kernel: [778771.993811] rsyslogd[57142]: segfault at 1a ip 00007fa80c9ba73c sp 00007fff55af8ee0 error 4 in libc-2.31.so[7fa80c955000+14b000]
Apr 20 14:25:31 mail-11 kernel: [778771.993826] Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 83 ec 18 48 8b 05 cd 37 13 00 48 8b 00 48 85 c0 0f 85 81 00 00 00 48 85 ff 74 74 <48> 8b 47 f8 48 8d 77 f0 a8 02 75 38 48 8b 15 29 36 13 00 64 48 83

jaký máš OS a jakou verzi systemd, verzi rsyslogd?

Tohle je hodně netradiční chyba, error 4 vznikl v libc-2.31.so a ta 4 znamená čtení nemapované paměti. Chytl to traps.h, to vypadá buď na nějaký divný bug nebo nekonzistentní knihovny.

Debian 11:
Kód: [Vybrat]
systemd:
  Installed: 247.3-7
  Candidate: 247.3-7
  Version table:
     250.4-1~bpo11+1 450
        450 http://ftp.cz.debian.org/debian bullseye-backports/main amd64 Packages
 *** 247.3-7 990
        990 http://ftp.cz.debian.org/debian bullseye/main amd64 Packages
        100 /var/lib/dpkg/status

rsyslog:
  Installed: 8.2102.0-2
  Candidate: 8.2102.0-2
  Version table:
     8.2110.0-4~bpo11+1 450
        450 http://ftp.cz.debian.org/debian bullseye-backports/main amd64 Packages
 *** 8.2102.0-2 990
        990 http://ftp.cz.debian.org/debian bullseye/main amd64 Packages
        100 /var/lib/dpkg/status

Kód: [Vybrat]

Apr 21 10:06:59 mail-10 systemd[1]: Stopping System Logging Service...
Apr 21 10:06:59 mail-10 kernel: [849694.727937] rsyslogd[56410]: segfault at 1a ip 00007f56c2eda73c sp 00007ffe21e8dca0 error 4 in libc-2.31.so[7f56c2e75000+14b000]
Apr 21 10:06:59 mail-10 kernel: [849694.727949] Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 83 ec 18 48 8b 05 cd 37 13 00 48 8b 00 48 85 c0 0f 85 81 00 00 00 48 85 ff 74 74 <48> 8b 47 f8 48 8d 77 f0 a8 02 75 38 48 8b 15 29 36 13 00 64 48 83
Apr 21 10:06:59 mail-10 rsyslogd: [origin software="rsyslogd" swVersion="8.2102.0" x-pid="56410" x-info="https://www.rsyslog.com"] exiting on signal 15.
Apr 21 10:06:59 mail-10 systemd[1]: rsyslog.service: Main process exited, code=killed, status=11/SEGV
Apr 21 10:06:59 mail-10 systemd[1]: rsyslog.service: Failed with result 'signal'.
Apr 21 10:06:59 mail-10 systemd[1]: Stopped System Logging Service.
Apr 21 10:06:59 mail-10 systemd[1]: rsyslog.service: Consumed 1min 23.945s CPU time.
Apr 21 10:06:59 mail-10 systemd[1]: Starting System Logging Service...
Apr 21 10:06:59 mail-10 rsyslogd: imuxsock: Acquired UNIX socket '/run/systemd/journal/syslog' (fd 3) from systemd.  [v8.2102.0]
Apr 21 10:06:59 mail-10 rsyslogd: [origin software="rsyslogd" swVersion="8.2102.0" x-pid="177746" x-info="https://www.rsyslog.com"] start
Apr 21 10:06:59 mail-10 systemd[1]: Started System Logging Service.
Název: Re:Přístup k logům mailserveru
Přispěvatel: _Tomáš_ 21. 04. 2022, 10:49:27
díky to vypadá na bug rsyslogu, můžeš ukázat jeho konfiguraci? Hodil by se i core dump a výstup gdb pro stacktrace.

Jak máš nastavené timeouty v systemd, nezabiješ rsyslog příliš brzy?
Název: Re:Přístup k logům mailserveru
Přispěvatel: czechsys 21. 04. 2022, 13:22:51
Rsyslog a systemd timeouty mam v defaultni podobe z Debian 11. Jedine upravy jsou:

cat /etc/rsyslog.d/*:
Kód: [Vybrat]
##graylog
*.* @@SOMEFQDN:1514;RSYSLOG_SyslogProtocol23Format

##postfix
# Ansible managed
# Transfer postfix logs to postgresql

#Load the imfile input module
module(load="imfile")

#Load the ompgsql output module
module(load="ompgsql")

#Define a template for row insertion of data
template(name="postgresql" type="list" option.sql="on") {
 constant(value="INSERT INTO maillog.maillog (message, timereported) values('")
 property(name="msg")
 constant(value="','")
 property(name="timereported" dateformat="pgsql" date.inUTC="on")
 constant(value="')")
}

ruleset(name="postfix_to_postgresql") {
 action(
  type="ompgsql"
  server="SOMEFQDN"
  user="SOMEUSER"
  pass="SOMEPASS"
  db="maillog"
  template="postgresql"
  queue.filename="postfix-queue"
  queue.maxDiskSpace="2G"
  queue.type="LinkedList"
  queue.timeoutWorkerthreadShutdown="1000"
  queue.timeoutEnqueue="10000"
  queue.workerthreads="5"
  queue.workerthreadMinimumMessages="1000"
  queue.SaveOnShutdown="on"
  action.resumeRetryCount="-1"
  action.resumeInterval="30"
 )
}


input
(
 type="imfile"
 file="/var/log/mail.log"
 tag="postfix"
 ruleset="postfix_to_postgresql"
 PersistStateInterval="10"
)

##postfix package
# Create an additional socket in postfix's chroot in order not to break
# mail logging when rsyslog is restarted.  If the directory is missing,
# rsyslog will silently skip creating the socket.
$AddUnixListenSocket /var/spool/postfix/dev/log

core dumpy a gdb nemam.
Název: Re:Přístup k logům mailserveru
Přispěvatel: czechsys 06. 01. 2023, 16:51:07
Narazil jsem na problem s predavanim logu do postgresql z rsyslogu.

mail.log:
Kód: [Vybrat]
Jan  6 00:07:50 SOMEHOST postfix/smtp[462873]: 4Np2F15wZMz1YK: to=<SOMEMAIL>, relay=eur.olc.protection.outlook.com[104.47.18.161]:25, delay=0.92, delays=0.1/0/0.79/0.02, dsn=5.7.1, status=bounced (host eur.olc.protection.outlook.com[104.47.18.161] said: 550 5.7.1 Unfortunately, messages from [SOMEIP] 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. [AM7EUR06FT064.eop-eur06.prod.protection.outlook.com] (in reply to MAIL FROM command))
postgresql.log:
Kód: [Vybrat]
2023-01-06 00:07:50.778 CET [3445242] USER@DB ERROR:  syntax error at or near "t" at character 390
2023-01-06 00:07:50.778 CET [3445242] USER@DB STATEMENT:  INSERT INTO SOMETABLE (message, timereported) values('Jan  6 00:07:50 SOMEHOST postfix/smtp[462873]: 4Np2F15wZMz1YK: to=<SOMEUSER>, relay=eur.olc.protection.outlook.com[104.47.18.161]:25, delay=0.92, delays=0.1/0/0.79/0.02, dsn=5.7.1, status=bounced (host eur.olc.protection.outlook.com[104.47.18.161] said: 550 5.7.1 Unfortunately, messages from [SOMEIP] 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. [AM7EUR06FT064.eop-eur06.prod.protection.outlook.com] (in reply to MAIL FROM command))','2023-01-05 23:07:50')

Predpokladam, ze je to zpusobeno
Kód: [Vybrat]
weren't ktere je v sql dotazu jako
Kód: [Vybrat]
weren\t.

Jaka je nejlepsi cesta? Funkce na strane postgre? Nejaka extra uprava (jaka?) na strane rsyslogu (viz ta ##postfix konfigurace o prispevek vyse)?
Název: Re:Přístup k logům mailserveru
Přispěvatel: _Jenda 06. 01. 2023, 19:52:31
To jako opravdu lepí do SQL dotazu escapovaný uživatelský vstup? SQL injection v logách poštovního serveru v roce 2023?!
Název: Re:Přístup k logům mailserveru
Přispěvatel: tecka 06. 01. 2023, 23:57:17
Narazil jsem na problem s predavanim logu do postgresql z rsyslogu.
Od Pg 9.1 je escapování zpětným lomítkem vypnuté. V tom template použij values(E' nebo option.stdsql.
Název: Re:Přístup k logům mailserveru
Přispěvatel: czechsys 09. 01. 2023, 11:31:50
Narazil jsem na problem s predavanim logu do postgresql z rsyslogu.
Od Pg 9.1 je escapování zpětným lomítkem vypnuté. V tom template použij values(E' nebo option.stdsql.

Dik, vyzkousim option.stdsql. Se zdvojovanim ' nemam zkusenosti, tak jsem pouzil to defaultni option.sql.