Megérteni a folyamatot

Amikor a nyilvánvaló hiba nem is annyira nyilvánvaló.

Van egy szerverem, mely alapvetően egy webszerver és egy levelezőszerver, ez utóbbi az előbbiben regisztrált domainek számára biztosít levelezést.

A rendszer maga rém egyszerűen működik, a Postfix a MySQL-t zaklatja, hogy akkor én most mely domainekért is vagyok felelős? Ki az a Kovács János? Hova kell kézbesíteni a [email protected] leveleit? Meg ilyen nagyon hasonló kérdésekkel.
Amibe belefutottam, az az volt, hogy a szerver időnként különféle riportokat generál saját működéséről, és ezt elküldi a rendszergazdának, pontosabban a root-nak. Mivel ez a része mindig is önműködő volt, sosem bántottam.
Viszont nem szeretem, ha a webes felületen bármilyen [email protected] felhasználó belépked, így lett kreálva egy user a szerver fő domainjén belül, és a root leveleit neki címeztettem. A dolog ment is, mígnem egy szép napon elkezdtek nagyon furcsa dolgok történni.

Jött egy non-delivery report azzal, hogy a root nevű usert ő bizony nem találja, legyek szíves ezt tudomásul vennni, mint postmaster. És csak a root-ot nem.
Vagyis az alias elkezdett úgy működni, hogy a levél el akart menni a root-nak, az nem volt feloldható, visszapattant a postmaster-nek, aki viszont már feloldható volt az [email protected] -ra, és a levél (ugyan mint NDR), de végülis megérkezett az admin postaládájába.
Tesztlevél: NDA. Oké. Postfix ismer olyant, hogy root? Ismerni ismer, sőt, fel is oldja a nevet [email protected] -ra. Az [email protected] -nak lehívhatók az infói? Le. WTF?
Mivel jobb ötletem nem volt, a levélküldő alkalmazásokat kezdtem el átállítgatni, hogy a fontos levelek azért megjöjjenek rendesen, ne csak NDR-en keresztül. A szervert úgy mellesleg fel is jelentettem, de a probléma nem öltött akkora méreteket, hogy tudtam volna időt szánni a nyomozásra.

Aztán egy szép napon valaki előszedte a fórumtémát, hogy akkor most végülis mi volt. Ennek kapcsán valaki más megkeresett IRC-n, hogy akkor ő most segítene, nézzük meg, mi lehet a baj.
Először is, bekért egy csomó infót a szerverről, amit lehetett készségesen el is küldtem. Végül egy ilyen sor keltette fel a kíváncsiságát:

myorigin = /etc/mailname

Mi is az a myorigin? Nos, mint kiderült, a myorigin az a beleértett végződés, amit a Postfix a végződés nélküli címekhez rendel hozzá. Vagyis ha valaki azt mondja, hogy akkor ezt most küldd el a root-nak, akkor ő veszi a myorigin értékét (azaz kiolvassa a /etc/mailname tartalmát), hozzácsapja a root felhasznlónévhez, és elkezdi a rendes levélküldési folyamatot: megnézi, felelős-e ezért a domain-ért, ha igen, akkor pedig mit kell kezdeni a levéllel.

Nos, a bukta már az első keresésnél kiderült: a Postfix nem volt felelős azért a domain-ért, ami értéket a myorigin végülis felvett. Ennek az volt az oka, hogy a homályos múltban még homályosabb okokból a szerver hostneve át lett írva mail.mittudomain.com -ról mittudomain.com-ra (én sosem csinálok ilyent, de nem kizárólag az enyém a szerver), majd a Postfix-től el lett véve a cím, mondván, hogy innentől ilyen címzett nem lesz.
A gond csak az volt, hogy a másik rendszergazda a /etc/mailname értékét nem írta át, hanem maradt mail.mittudomain.com -nak, és a Postfix továbbra is ezt értette bele a végződés nélküli címekhez. Mivel azonban ilyen domainért ő nem volt felelős, megpróbálta kifelé feloldani. A DNS saját magára mutatott, ám mivel ő továbbra sem érzett semmilyen elkötelezettséget a mail.mittudomain.com domain irányába, a kézbesítést feladta, és kihisztizte magát a postmaster vállain egy NDR formájában.

A végső megoldás természetesen az /etc/mailname értékének az átfaragása, a probléma azonban az elvvel van.
Általánosságban igaz, hogy ha az ember gépet nevez át (mondjuk már ahhoz is nagyon nyomós indok kell, hogy a gép nevét megváltoztassam), akkor igyekszik a legnagyobb alapossággal eljárni, és sed-del végigjárja az összes szóbajöhető érintett konfigot, lecserélve a gép régi nevét az újra. Ezt a kollega meg is tette, azzal az apró pici különbséggel, hogy a végén nem grep-pelt egyet, hogy biztos nem maradt-e a sarokban valahol egy apró pici fájl, benne a régi névvel. A main.cf pedig nem egyértelműen hivatkozott erre a névre, hanem közvetve, az /etc/mailname értékén át. Mivel pedig a main.cf meg lett nézve, onnét a régi név gyökeresen ki lett írtva, így a Postfix teljes joggal érezhette, hogy márpedig ehhez a dologhoz neki köze nincsen.

És hogy mi a tanulság? Az, hogy ilyen neveket nem rakunk le apró pici fájlokba, hanem bevéssük rendesen a konfigba. Egyfelől a dolog jobban parsolhatóvá válik (nem kell külön ellenőrizni, hogy akkor ez most fájl vagy sem), másfelől pedig egy esetleges probléma felmerülésekor eggyel kevesebb nyomon kell elindulni. No és persze a névváltásokat meg kell alaposan tervezni, és a végén vissza kell ellenőrizni, hogy valami hülye spion nem ragaszkodik-e foggal-körömmel a régi névhez.

Comments