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ó.

Kapcsolódó bejegyzések

Hogyan néz ki ez az Atlason belül?

Tovább a termékoldalra