A riasztások be vannak állítva, mégsem érkezik semmi: a kézbesítési út, amelyet senki nem tesztel
A megfigyelésnek két fele van, és csak az egyiket szokás beállítani. A problémát észrevevő ellenőrzés a könnyebbik fél. Az üzenetet emberhez juttató út az, amelyik csendben romlik el, méghozzá azután, hogy már működött.
AtlasPVE ·
A bejegyzés ezekre válaszol
- proxmox email értesítés beállítás
- proxmox riasztás email nem működik
- proxmox gmail smtp küldés
- proxmox nem jön értesítés
- proxmox smtp relay beállítása
A megfigyelésnek két fele van. Az ellenőrzés, amely észreveszi a bajt, és az út, amely a hírt eljuttatja egy emberhez. Szinte minden figyelem az első félre jut, és szinte minden néma hiba a másodikban él.
A kényelmetlen rész az, hogy az elromlott kézbesítési út és a rendben lévő rendszer kívülről pontosan ugyanúgy néz ki. Mindkettő üres postafiókot eredményez.
Miért nem egyszerű már a szerverről küldött levél
Sokáig természetes volt, hogy a szerver közvetlenül küldi a saját leveleit, ma ez kivétel. Három dolog történt.
A fogadó szolgáltatók nem bíznak többé az ismeretlen feladókban. Az az üzenet, amely megfelelő feladói házirend bejegyzések nélkül, aláírás nélkül és hírnév nélküli címről érkezik, gyanúsnak számít, a gyanús udvarias változata pedig a spam mappa.
Az otthoni és kisvállalati kapcsolatok port szinten tiltottak. Sok szolgáltató nem engedi a kimenő kapcsolatot a közvetlen levélkézbesítés portján, éppen azért, mert visszaéltek vele. A szerver próbálkozik, és semmi nem jelzi, hogy az üzenet el sem indult.
A hírnév a címhez tartozik, nem az üzemeltetőhöz. Egy lakossági vagy kisebb felhőszolgáltatói cím magával hozza a saját előéletét, és ez öröklődik.
Ettől még nem nehéz a feladat. A naiv beállítás viszont csendben hatástalan lesz, ami rosszabb a nehéznél.
A két működő megoldás
Küldés egy már megbízható relay-en keresztül. A szerver hitelesítő adatokkal átadja az üzenetet egy olyan levelezési szolgáltatónak, amely küldhet. Ez a szokásos válasz, és működik, egy fenntartással: a szolgáltatók gyakran megkövetelik, hogy a feladói cím náluk legyen, ezért a máshonnan érkezőnek látszó üzenetet elutasítják vagy átírják.
Levélküldés helyett második csatorna. Push értesítés vagy üzenet egy amúgy is olvasott szolgáltatásba. Ez visszalépésnek hangzik, mégis gyakran a megbízhatóbb választás, éppen azért, mert nem függ az e-mail kézbesíthetőségétől.
Bármelyik választás mellett a lényeg a következő szakaszban van.
A próba, amely tényleg bizonyít
Az értesítéseket szinte mindenki ugyanúgy, rosszul teszteli: a gép mellett ülve megnyomja a "teszt küldése" gombot, nem lát hibát, és késznek tekinti.
Ez a próba azt bizonyítja, hogy a folyamat át tud adni egy üzenetet. Azt nem bizonyítja, hogy az üzenet meg is érkezik. A valódi próba négy kérdésre válaszol:
A beérkező üzenetek közé került, nem a spam mappába? A kézbesítés és a láthatóság két különböző eredmény, és csak az egyik ébreszt fel valakit.
Arról a címről jött, amelyet a valódi riasztások használnak majd? Az egyik személyazonossággal küldött teszt semmit nem mond egy másikkal küldő éjszakai feladatról.
Abban az órában érkezett meg, amikor a valódi riasztás elindul? Egyes utak hajnali háromkor másképp viselkednek, mint délután háromkor, általában azért, mert a relay sebességkorlátai vagy a szolgáltató szűrése időfüggő. Ez ritkább hiba, és éppen ez az, amelyik számít.
Túlélte a gép terhelését? A valódi incidens közben sorba állított üzenet magával az incidenssel verseng.
Hibamódok, amelyek semmilyen hibaüzenetet nem adnak
A várólista. A levél elkészül, helyben elfogadásra kerül, és egy örökké újrapróbálkozó sorban ül. Semmi nem vész el, semmi nem érkezik meg, és a sorba senki nem néz bele, mert nem volt hiba, ami erre késztetné.
Az átírt feladó. A relay elfogadja az üzenetet, a feladót egy nem olvasott címre cseréli, és hibátlanul kézbesíti egy olyan postafiókba, amelyet senki nem nyit meg.
A saját kezűleg készített szűrő. A riasztások egyformán néznek ki, ezért egy ponton egy szabály elkezdi őket mappába rakni, és a szabály jóval azután is dolgozik, hogy a létrehozása feledésbe merült.
A megszűnt cím. A munkatárs elment, az álnév az ő fiókjára továbbított, és a továbbítás most a semmibe fut.
A leghasznosabb szokás
Az üzenet hiányának is jelentenie kell valamit.
Az a rendszer, amely csak baj esetén szólal meg, nem különböztethető meg attól, amely elvesztette a megszólalás képességét. Egyetlen napi üzenet, amely azt mondja, hogy minden rendben, magát a csendet teszi jelzéssé: ha ma nem érkezik semmi, először a kézbesítési utat kell megnézni, és a hiba egy nyugodt reggelen derül ki, nem incidens közben.
Ezért ér a napi összefoglaló többet, mint amennyinek látszik. A valódi feladata nem a tartalom, hanem annak bizonyítása, hogy a csatorna még létezik.
Mit csinál az Atlas
Az Atlas Watch riasztásfolyam helyett napi egy üzenetet küld, és ez a döntés a fenti ok miatt tudatos. Az összefoglaló a nap során összegyűlt állapotot viszi magával, és már a megérkezése is bizonyítja, hogy az út ép.
Ugyanezek az értesítések a fiókportálra is megérkezhetnek, ami itt kifejezetten számít: ez egy második csatorna, amely nem függ a gazdagép saját levélkézbesítésétől. Ha éppen az e-mail romlott el, az a csatorna szól, amelyik nem e-mailt használ.
És az őszinte rész, mert az egész cikk erről szól: amikor egy ellenőrzés nem tudja beolvasni az adatait, a Watch nem hallgat, hanem közli, hogy nem tudta beolvasni. A hiányzó biztonsági mentési feladat és a rendben lévő kívülről egyformán néz ki, és csak egy olyan őrszem különbözteti meg őket, amely hajlandó jelenteni a saját vakságát.
Források
A Proxmox saját dokumentációja. Angol nyelvű, és ebben a kérdésben az övé az utolsó szó.