Sziasztok,
Próbálnék egy levél küldő szervert készíteni, ami képes SPF, DKIM kezelésre és mellette real time logol adatbázisba. De szerintem bátran mondhatom, hogy már az elején elakadtam.
Tehát a cél:
- Nem túl nagy terhelésű levél küldő készítése, napi maximum 1000 mail kiküldése. Vannak erősebb és gyenégg napok, de átlagnak vehető az 1000 / nap. Ebből 0db hírlevél, vagy SPAM levél, csak fontos céges, web alkalmazás levelek (regisztráció megerősítés..stb.), automatizált értesítők éjszakánként (pl, meg nem erősített regisztrációk, újboli kiértesítése).
- A lehető legmagasabb fokú SPAM elleni küzdelem beállítható legyen rajta, úgy mint SPF, DKIM
- Csak leveleket kell tudjon küldeni, fogadni nem kell neki semmit. Fogadni egy másik szerver fogadja a leveleket, ez csak kiküld.
- Egy nagyon fontos, ha nem a legfontosabb tulajdonság, pedig, hogy real time tudja naplózni mysql-be a rendszer, hogy ki, kinek mikor mit küldött ki és arra mi volt a címzett szerver válasza. Tehát kb: timestamp, from, to, subject, remote answer... A REAL TIME itt nagyon fontos.
Az elképzelés a következő volt:
- Postfix, mert levél küldésre kiválóan konfigurálható. Bár nagyon sok mást is tud, amire itt nincs szükség, de hát enni nem kér.
- Postfix a SPAM elleni harc esetén is jó választásnak tűnt, mivel SPF, DKIM, mind megoldható nála.
- Majd jött a loggolás... Nah itt megakadtam.
-- Volt a rsyslog, ami tud adatbázisba logolni, de az csak fájl helyett DB-be ír mindent ömlesztve. Ugyan az, mint a syslog-ng, csak nem fájlba ment.
-- Tudnék írni egy scriptet, ami a mail.log fájlt felparsolja, de real time nem tudom, hogyan oldjam meg. Ha a logrotate átfordítja a log fájlt két script futás között, akkor kiesig a köztes esemény a logokból. Illetve, ha nagy, akkor amíg lockolom a fájlt (értsd parsolom), nem tudom, hogy a syslog-ng mit csinál, mert hogy nem vár rám, az biztos.
-- Aztán persze megoldható úgy is, hogy folyamatosan nyitva a fájl, de csak olvasásra, vagyis nincs lock, és figyeli a scipt az új sorokat és logol. De mi van, ha lehal a script, akkor újraindulásig, független, hogy kézi, vagy automatizált, a köztes idő elvész.
-- Köztes megoldás, hogy rsyslog ment adatbázisba és ami a levelezéssel kapcsolatos, azt parsolgatja egy script és kigyűjti belőle, ami nekem kell és a felparsolt sorokat megjelöli egy flaggel, hogy azzal már végzett. De mivel scriptről beszélünk, az sem real time, mert percenként fut a script.
A legjobb az lenne, hogyha lehetne olyat csinálni, hogy a postfix minden levél küldés esetén meghívna egy scriptet, ami a paraméterekből, vagy a postfix által átadott adatok alapján insertálgatná az adatbázis sorokat. A script nem figyel folyamatosan, így nem tud lehalni... A postfix régi motoros, nem hibázik, tehát minden script hívás megtörténne, idővel a script bug mentes lenne, tehát adat vesztés gyakorlatilag 0-ra redukálódna.
Vagy... és most jön az, amiről én nem tudok. Lehet, hogy létezik erre egy tök egyszerű megoldás, csak én még nem hallottam róla.
Bármilyen építő jellegű választ és ötletet szívesen fogadnék.
Köszönettel...
Hozzászólások
Nekünk is hasonló okból (alkalmazás reg és azok megérkezése) merült fel az igény. Első körben néztem Sendgrid, Mailgun és társait. Ezek mind tudjuk a fenti naplózást saját webes felülettel + WebHooks. Viszont a free verziók napi szinten fent vannak valami spam listán, így nekünk nem fért bele a lepattant levelek aránya miatt.
Második körben találtam ezt: https://haraka.github.io/
Tudja mindazt, amit a Postfix (SPF, DKIM). Szerintem kicsit könnyebb is beállítani. Ráadásul könnyedén tudsz hozzá saját plugint csinálni, ami minden eseményre ráállítható, így minden adatrétegre - amit a nodejs támogat - tudsz küldeni részletes logot. Nálunk pl. azt logolja MongodDB-be hogy a fogadó mail szerver átvette-e a levelet.
Ha gondolod át tudom küldeni a plugint, pár sor a lényeg benne valójában.
Minden ingyenes és nem ingyenes megoldást megnéztem, DE:
- Sendgrid szerintem egy átláthatatlan katyvasz lett és egy account alatt nem tud kezelni több webhookot, már pedig nem csak 1 irányba kéne értesítést küldenem, bizonyos eseményeknél.
- Mandrill fizetős lesz április végétől és ráadásul nagyon komoly összeget kérnek el, ha azt is bele veszem, hogy nem minden levelet kézbesít az Ő szervrük sem. Kb 2 évig használtam. (Többlet között ezért lett érdekes a saját megoldás, mert többlet költséget nem szeretnék, vagy legalábbis nem magasat, így a mandrill ugrott, váltanom kell).
- Mandrill után a mailgunra tértem át. Minden jónak tűnt, mindent tud, ami kell és jól is kezelhető. DE 3 domaint vettem fel hozzájuk, amihez 2 külöböző IPt rendelt, melyek közül 1 egyik 2 db spam listán volt fent a másik meg 10 darabon. Ezt pedig úgy vettem észre, hogy a citromail, a freemail mind visszaszórták a leveleket. A gmail.com a statisztikai spam szűrőjével beengedett mindent, amivel teszteltem a szolgáltatót. Hiba volt...
Ezen kívül más SMTP relay nem jöhet szóba, mert kis cégre nem bíznám a leveleim. Létezik még a mailjet és társai, de olyan ingyenes kvótákkal, ami egy vicc, fizertős verzióba meg nagyon komolytalan összegeket egy magyar pénztárcának.
Haraka... Ha nem kapom más olyan választ, amit alap repoból meg lehet oldani, akkor megpróbálkozom vele és akkor érdekelne a sciprt is, mert legalább azzal nem kell küzdeni.
Mi mind mandrillal mind mailgunnal eleg sok levelet kuldunk millios nagysagrend. Viszont kerj fix ip-t akkor tudod felugyelni de shared ip-d van es az spam listara kerul akkor kerj a supportol ujat es tuti fognak adni.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer
Kértem... Cserébe zárolták (mailgun) néhány domainhez tartozó hozzáférésem, mondván meghaladta a bounced rate az 5%-ot. Amíg nem szóltam nem tűnt fel nekik...
Egy weboldalon regisztráció megerősítéshez használt fiók volt. Kérdem én, hol tehet arról, hogy hülye, aki reggel és rossz címet ad meg. MX rekord ellenőrzésen kívül nem sok minden tudok csinálni. Ami a @ előtt van nem validálható, mert a VERFY minden szerveren tiltott. Vagyis tehetetlen vagyok.
Szóval ennyit a segítőkészséges supportról :(
Minden feliratkozót vissza kell igazoltatni és ha egyszer visszapattan akkor leszedni a listáról.
Ezt így csinálom... Azonnal kap egy mail_status=false értéket és a rendszer annak a usernek több levelet soha nem próbál meg küldeni. Ennek ellenére sok a teszt regisztráció, ahol nyilván nem ad meg valós címet, mert minek és máris hard bounced.
Már azt sem szabad hagyni, csak visszaigazolt emailcímre érdemes küldeni. Gondold el, hogy egy gmail, egy O365 vagy hasonló méretű szolgáltató könnyedén tudja figyelni az egy feladótól vagy IP-ről jövő maileknél a bounce-rate-et és akár az alapján is szűrni. Ha meg már semmiképp se lehet visszaigazoló linkkel operálni, akkor írni egy validáló scriptet, ami a rcpt to után köszöni és kilép. Így lehet az üres időben nagyon kis intenzítással is ellenőrizni.
jogos... erre eddig én nem is gondoltam, sőt nem is számoltam azzal, hogy még küldés előtt megfogható... sj felnyitotta a szemem, néhány hszel korábban
dehogynem validalhato. Az MX kotelezove tetele nem teljesen korrekt, mert az is eleg, ha csak A rekordja van. De ezeken tul megnezeheted, hogy 250-et kapsz-e az ehlo, mail from es rcpt to vegen. Ha igen, akkor a cim koser. Ha 45x-et, akkor valoszinuleg szurkelistaba (ugyetlenbe) botlottal. Ha 55x, akkor nem letezik a cimzett. Szoval ha mindezeken tuljutsz, akkor egy megerosito emailt kuldeni, amire ha kattint, reply-ol, whatever, akkor van felveve a cim.
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
Az eljárásom a zona MX rekordját keresi, mert hogy A rekordja van a domainnek az még nem feltételezi rögtön azt, hogy levelezés is zajlik rajta
A Te eljárásod odáig jó, amíg a gmail.com helyett gmall.com-ot ír a felhasználó. De ha letezik@gmail.com helyett nemletezik@gmail.com-ot ír, akkor már semmivel nem tudod szűrni, csal az első levél küldéssel, aminek megnézed, hogy mi lesz az eredménye: 250, 4xx, 5xx
az en eljarasom vegig jo, mert a 'nemletezik' cim tesztelesenel (tehat nem kell levelet kuldened) 55x hibat illik visszakuldeni...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
hát elnézést kell kérnem... utána olvastam a dolognak és ez tényleg működhet... találtam rá a neten millió kész scriptet is, függetlenül attól, hogy nem egy ördöngös feladat
Illik, de nem muszáj. Bőven belefér, hogy az MX csak relayként működik és valójában fogalma sincs a létező az élő e-mail címekről, max. a bounce levelet tudja visszaküldeni, amikor továbbadná...
(rejtett subscribe)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
ez a fucked by design minositett esete. Lattam mar ilyet, de attol meg ez nagyon szar, tobb okbol is...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
Az, de van, hogy muszáj.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
miert lenne muszaj? El kell magyarazni a hatranyokat, es korreket modon osszerakni az mx-eket...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
Nálunk volt olyan setup korábban, hogy a 20-as MX nem intézmény területén volt, hanem az egyetemnél ahonnan a net jött és arra állították be, hogy ha nem megy karbantartás miatt a net nálunk, akkor fogadjon el mindent amit aztán az újra online levélszerver átvett és "megválaszolt".
Az sem volt egy jól átgondolt setup. :) A bounce-ra vagy bármire ami beidéze az eredeti emailt harapnak a spammerek, mert remekül lehet "pattintva" spammelni.
gondolom, nehez lett volna megoldani, hogy az email db a 20-ason is jelen legyen...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
Igen, de nem technikai ok miatt.
En ilyet nem tapasztaltam soha. Pedig nekunk neha szokott lenni 10-15% is de ez valszeg a kikuldott mennyiseghez kepest nezik.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer
miert fontos a realtime loggolas? De, felteve, hogy ez tenyleg elengedhetetlen (majd eldol, ha elmagyarazod), akkor csinalhatsz egy primitiv content filtert, ami egy shell script, amit a postfix minden levelnel meghiv, es az elvegzi a loggolast. Ha bovebben kifejted, valoszinu, hogy tudunk erre egy alternativ megoldast ajanlani...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
Nem tudom bővebben kifejteni... Sajnos ebbe nem én vagyok a döntés hozó. Ezt az igényt támasztották a rendszerrel szemben.
Gondolom a rendszert használó, aki a logokat nézni fogja kb 2 napig nézi real time, aztán utána évente max 1x nyitja meg az adatokat listázó webet.
De ha ez az igény, akkor sajnos ezt kell megoldani. És ha vitatkozni szeretnék ilyen elképzelésekkel kapcsolatban, akkor a válasz: a holdra is eljutottunk, nehogy már ilyen alap dolgot nem lehet megoldani :((
mondjuk az 1 perc késés még elfogadható, ami a cron ütemező legkisebb intervalluma. De a kiesés nem, ha mondjuk logrotate logot fordít és kiesik 20 levél.
te mar tapasztaltal ilyet, hogy amikor futott a logrotate, akkor elvesztek elkuldott log bejegyzesek? (En nem). De ha ezen parazol, es napi 1k levelrol van szo, akkor miert nem allitod be a maillog file rotalasat mondjuk fel evre?
Akarhogyis, a fentebb javasolt content filter erre is megoldast ad, raadasul gyerekjatek ott megoldani, hogy minden nap yyyymmdd alaku file-ba irja a logot, amit btw. a syslog-ng is tud, igy nem is kell rotalni a mail logot....
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
Nem a rotate miatt veszik el, sot nem is veszik el. Csak fut egy script valamikor, majd rotate van es utana ismet fut a script. A log egy feldologzatlan resze a tomoritett fajlba lesz, a masik resze a rendes log fajlba.
A content filter hogy tud itt mukodni? Az nem csak bejovo levelre fut?
Nekem logolva van realtime a levelezes, de ez egy mellektermek.
Siman beteszel egy SMTP proxy szervert, es logol az is.
Itt irtam rola bovebben:
http://hup.hu/node/144754
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
haraka vs más egyéb --> 2 - 1
ennyire jó lenne az az SMTP szerver???
Nézd meg az eximet, azzal megy közvetlenül SQL-be, nem kell külön problémázni. Már az acl szakaszban nagyon könnyű egy szabályt (warn és continue-nak nézz utána) betenni, hogy mi történt a fogadáskor és utána a transport szinten is tudod naplózni. Az biztos, hogy próbálgatós lesz, hogy pontosan milyen állapotokat és hol érdemes naplóznod, amik az eredeti igényhez a legjobban igazodnak.
Az SPF-fel és DKIM-mel is simán megbírkózik az exim, sőt DKIM-mel natívan. :P Bár az SPF nem tudom hogy jön képbe, hiszen csak küldeni akarsz és a küldő MTA-n nem jön képbe az SPF, csak fogadáskor lesz fontos a validálás.
Ennek az exim-nek neki futok holnap, mert az előbb ránéztem a config fájlra és hát cseppet sem éreztem úgy, hogy könnyen konfigurálható. Így elsőre elég semmit mondó paraméter neveket találtak ki. De majd a doksi segít.
Amúgy van ehhez valami jól bevált konfig részlet, ami segíthet a logolásban elindulni? Vagy valami hasonlót feladatot ellátó szabály? Vagy valami, amin el lehet indulni konfigurálásban?
Szerintem ha a postfix-et ismered, akkor inkább maradj annál.
Egyébként elsőként a syslog-ng jutott eszembe.
Második az volt, hogy minden normális *syslog* rávehető arra, hogy logserver-re mentsen, ami triviálisan dolgozhat sql backend-re
Harmadszor elővettem a guglit (postfix log to database), 5. találat ez volt: mysqmail-postfix-logger.
Első olvasásra nem éppen rocket science, de szerintem pont azt tudja amit keresel...
Hát ennek mindjárt utána fogok nézni... Köszönöm.
Ha jutsz valamire írd meg, mert kis intenzitással engem is érdekel a dolog :)
ok...
Az első fő tippem, hogy ha debianozol vagy ubuntuzol akkor kukázd a /etc/exim4 alattiakat és írj egy szép exim4.conf -ot. Itt végigvezetnek: http://tldp.org/HOWTO/Spam-Filtering-for-MX/exim-configfile.html
Én anno postfixről váltottam, mert ez a script jellegű konfigolhatóság jobban bejött és nem kellett mindenféle ügyek miatt "jajj tudja-e" irányba menni, hanem eleve komoly eszköztárat ad és lehet írni feltételeket szépszámmal igény szerint.
Logoláshoz példa:
Ahogy lentebb írták, gondold meg a postfixről váltást. Ha neked a postfix áll kézre, abban vagy benne, akkor nem biztos, hogy megéri eximre váltással vesződni.
Gentoo-zom... de szerintem ez itt részletkérdés, mert a programok minden disztron ugyan olyanok és ugyan úgy működnek, csak max máshol kell beállítani valamit.
Köszönöm a példákat. Ha eximre esik a választás, akkor mindenképpen hasznát fogom venni.
Mindenképpen meggondolom, mert a postfix configot már értem és tudom mi mit csinál, így nehezemre esik a váltás, de ha nincs más megoldás, akkor megyek. :)
Akkor nézd meg a sendmail-t. Utána bármi más könnyen, egyszerűen, átlátható módon konfigurálható kategóriába kerül.
:) :) Talán nem ok nélkül jelent meg pár konkurens alkalmazás.
Hint: eyecandy :-P A sendmail.cf, és az annak generálásához megalkotott m4 makrónyelv annyira nem vészes - csak a modern, elsődlegesen emberi "fogyasztásra" alkalmas konfigurációs állományok okán kevesen vettek magukon erőt, hogy megtanulják :-P
ha csak annyi forintom lenne, ahany sec. bug volt mar (es lesz is meg) a sendmail fucked by design cuccaban, akkor gazdag ember lennek. Bar aligha van elo ember, aki sendmail-t hasznal, amikor van helyette boven alternativa...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
Szerintem írj egy jó kis ál-policy server-t hozzá...
http://www.postfix.org/SMTPD_POLICY_README.html
A "protocol description" résznél lévőket tudod kiloggolni belőle.
Pl. Így:
#!/bin/bash
# Policy logger
LOGFILE='/tmp/policy.log'
while read input
do
if [ -z "${input}" ]
then
/bin/echo >>${LOGFILE}
/bin/echo -e 'action=dunno\n'
exit 0
fi
/bin/echo ${input} >>${LOGFILE}
done
exit 0
--
Debian Linux rulez... :D
RIP Ian Murdock
Így a _küldéskor_ visszakapott túloldali hibakódot tudja naplózni?
ez hibátlanul működik, de a doksi szerint a queue_id benne lesz a kimenetben, de Nekem az nem került bele (vagyis bele kerül a paraméter, csak üres), pedig az már egy nagy segítség lenne, mert akkor a mail.log-ot maradéktalanul fel lehetne parsolni egy scripttel... de sajnos a küldő és a fogadó paraméteren kívül nem sok olyan adat van benne, ami Nekem kéne :(
smtp_sender_restrictions részhez tedd be... check_policy_service felhasználásával... :)
Nálam szépen loggol:
request=smtpd_access_policy
protocol_state=RCPT
protocol_name=ESMTP
client_address=xxx.xxx.64.3
client_name=mail2.xxxxxxxx.hu
reverse_client_name=mail2.xxxxxxx.hu
helo_name=mail2.xxxxxx.hu
sender=info@xxxxxxxxx.hu
recipient=barkas@zzzzzz.hu
recipient_count=0
queue_id=AE64468101847
instance=2480.5705271b.ae5c0.0
size=18168712
etrn_domain=
stress=
sasl_method=
sasl_username=
sasl_sender=
ccert_subject=
ccert_issuer=
ccert_fingerprint=
ccert_pubkey_fingerprint=
encryption_protocol=
encryption_cipher=
encryption_keysize=0
--
Debian Linux rulez... :D
RIP Ian Murdock
jogos... nem a senderhez tettem, így most már nekem is hozta az adatokat
de ettől még csak a queue_id és néhány egyéb adat van meg, de sajnos nem minden...
elkezdtem egy scriptet fejleszteni a logok parsolására, mert úgy látom, eddig ettől jobb megoldás nincs az én legnagyobb sajnálatomra, mert ezt szerettem volna a leginkább elkerülni :(
függetlenül attól, hogy a log fájl szintaxisa adott, ebben van a legnagyobb hiba ráta, már most tudok 3 olyan esetet, amikor hibásan fogja parsolni és egyelőre egyikre sincs megoldásom
A scriptes gondolatodhoz: mi van, hogy ha nem file-ba, hanem named pipe-ba, tehát FIFO-ba történik a logolás, a scripted a másik végén szedi fel az infót? Ez a script egy systemd szolgáltatás, amelyet a systemd újraindít, ha netán megdöglene.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
ez nem rossz, de hogy tudom pl a syslog-ng-t rávenni a pipe loggolásra? illetve sajnos még nem írtam olyan scriptet, ami pipe-on figyelni tudott volna...
van esetleg valami példa kód arra, hogy egy progi pipe-on figyeljen?
LMGFY, az egyik találat a lista elejéről:
http://www.linuxjournal.com/content/using-named-pipes-fifos-bash
Jaja, meg a nagy kedvencem:
Advanced Bash-Scripting Guide
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Köszönöm a kódot és a linket... Könnyen lehet, hogy át fogom alakítani.
Ez is hasznos link, talán jobban a lényegre térő... Köszönöm
Most nézem a scriptemet, amiben használtam named pipe-ot...
Nem ismerem a syslog-ng-t, de gondolom, konfigolható, hogy melyik file-ba írjon. Aztán, ha az a file véletlenül épp egy named pipe, akkor szerintem meg is vagy.
Releváns részleteket írok. Nem azért, mert titok, hanem azért, mert szerintem neked nem lenne türelmed kivadászni a számodra érdekes részeket. Ettől függetlenül, ha gondolod, elküldhetem.
A makefifo() függvényem kap egy nevet, s így hozom létre a fifo-t:
local FIFO="/tmp/runnerd-fifo.$1/runnerd-fifo"
rm -Rf "/tmp/runnerd-fifo.$1"
mkdir "/tmp/runnerd-fifo.$1"
mkfifo -m 0600 "$FIFO"
chown "$1:root" "$FIFO"
Aztán van egy ciklusom, amelyben van egy ilyen részlet:
makefifo "$u" || continue
FIFO="/tmp/runnerd-fifo.$u/runnerd-fifo"
exec {fd}<> "$FIFO"
log "USERS[$i]='$u'\t\tFD[$i]=$fd"
USERS[i]="$u"
FD[i++]="$fd"
A log() nyilván logol, ne törődj vele. Az FD[@] tömbömben tárolódnak a file descriptorok, ezt az exec hozta létre.
Aztán van két egymásba ágyazott ciklusom, amelyek így kezdődnek, itt a writer nevű változó nem lesz túl érdekes neked:
ptr=0
while [ $ptr -lt ${#USERS[@]} ]; do
FIFO="/tmp/runnerd-fifo.${USERS[ptr]}/runnerd-fifo"
LOCK="/tmp/runnerd-fifo.${USERS[ptr]}/lock"
writer="`stat -c '%U' \"$FIFO\"`"
while [ ! -e "$LOCK" ] && read -t 0.1 -u ${FD[ptr]}; do
[ -z "$REPLY" ] && break
Ja, és az írás lemaradt:
FIFO="/tmp/runnerd-fifo.$USER/runnerd-fifo"
exec {FD}<> "$FIFO"
echo -e "$s" >&$FD
Közte vannak kódrészek, de most az nem érdekes. Systemd unit file-ban az újraindíthatóság:
[Service]
Type=simple
Nice=19
ExecStart=/usr/local/bin/tescripted
Restart=always
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Nagyon szépen köszönöm a sok hozzászólást és javaslatot.
Leírom, hogy mi lett a megoldás, ami mostanra működni látszik:
- A dolog lényege a napló fájl elemzése, de hogy ez működjön, egy-két dolgot be kellett állítanom.
- Először is a syslog-ng egy a szokásos mail.err, mail.log, mail.warn, mail.info fájlokon kívül egy másik fájlba is logol, ami csak parsolási célokra használok. Így a tényleges postfix logolást nem akadályozza semmiféle script.
- Ezen felül a syslog-ng-nek még megadtam egy formátumot, hogy hogyan formázza ezt a külön fájlt - természetesen, ahogy a legkönnyebb volt feldolgozni.
- Illetve a postfix-nél beállítottam egy fejléc ellenőrzést, ahol a Subject sort lelogolja fájlba.
- Végül egy-két finom hangolás a postfix-en és már csak a script volt hátra.
- A script percenként fut, ami még elfogadható késleltetés volt. Átnevezi a log fájlt, majd újra loadolja a syslog-ng-t, hogy az átnevezett fájl újra generálódjon. Ezt követően a script a postfix logolási logikája alapján soronként feldolgozza a bejegyzéseket. Azoknál az üzeneteknél, ahol megtalálja a queueId: removed sort, vagyis a mailq-ból kikerült levél, azt lelogolja, ahol pedig nem, ott az addig gyűjtött adatokat ideiglenesen letárolja. Mivel addig nincs kiküldve a levél, amíg a queue-ból ki nem került, így nem lehet róla minden infót tudni. Pl: postgray miatti visszafordítás. Így aztán a postfi teszi a dolgát és amikor lejár a lifetime, vagy amikor sikerül kiküldeni a levelet, akkor removed sor megjelenik és már megy is a log táblába az üzenet összes addig begyűjtött adata.
A dolog működik és ahogy eddig figyeltem, még nem hibázott...
Nagyon szépen köszönök mindenkinek mindent, nagyon sokat okultam ebből a topikból és a probléma és megoldódni látszik.
Ez az átnevezősdi biztos, hogy jó? Mi van, ha épp az átnevezéskor íródik a file? Valahogy nem látom, hogyan van megoldva a kölcsönös kizárás, ilyesmi.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Jogos... Ezen még majd picit masszírozni fogok. Hogy mire jutottam mindenképpen leírom ide.
A syslog-ng rugdosása helyett év-hónap-nap-óra-perc adatot tartalmazó nevű fájlba logolás?
Nem rossz elképzelés, még az sem kizárt, hogy ez fogja felváltani az átnevezéses módszerem.
Szia,
Erről nem akarsz egy részletesebb leírást írni? Nem szájbarágósat, csak a lényeget, minden ponthoz a releváns 1-2 sor.
Ugyanakkor a log átnevezést én se tartom jó ötletnek, a percenkénti futtatás helyett szerintem egy "tail -f"-fel simán olvashatnád folyamatosan a logfile-t, a kapott eredményt pedig folyamatosan is feldolgozhatnád.
Meg szerintem erre való a FIFO, lehet például named pipe és tee együtt.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Azért a FIFOs példakódod elég nehéz olvasmány...
Nem is ez volt a szándékom, én sem 10 perc alatt jutottam a működő megoldásra, amikor szükségem volt rá. A legtöbb dologra kell időt szánni, nem lehet fél szívvel nekilátni, ha valami működőt szeretnénk.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Mit értesz a részletes leírás? Konfigok és egyebek?
Ebbe az átnevezős dologba sokan belekötöttek és tényleg nem jó. Ne bántsd az eredeti logfájlt, csak jegyezd meg (pl. sor szám fájlba írása) melyik sornál hagytad abba és legközelebb (1 perc) múlva csak onnan dolgozd fel. (normál logrotate esemény ellen nem véd, azt is külön figyelembe kell venni.)
nem erre való a logtail? ;-)
Az warningol logrotate után. Persze lehet, hogy ki lehet valahogy kapcsolni, nem tudom. Egyszerűbb saját scriptet írni, mint utánanézni. ;)