Bylo vydáno Eclipse IDE 2024-06 aneb Eclipse 4.32. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-2 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Po roce od vydání verze 15.5 bylo vydáno openSUSE Leap 15.6. Přehled novinek v nejnovější verzi této linuxové distribuce v oznámení o vydání a v poznámkách k vydání.
Byla vydána nová verze 256 správce systému a služeb systemd (GitHub). Nově mimo jiné s run0 jako alternativou k sudo.
Společnost Oracle oznámila spolupráci s Google Cloudem, OpenAI a Microsoftem.
Zítra začne v Brně na FIT VUT třídenní open source komunitní konference DevConf.CZ 2024. Vstup je zdarma, nutná je ale registrace. Na programu je celá řada zajímavých přednášek, lightning talků, meetupů a workshopů. Přednášky lze sledovat i online na YouTube kanálu konference. Aktuální dění lze sledovat na Matrixu, 𝕏 nebo Mastodonu.
Google Chrome 126 byl prohlášen za stabilní. Nejnovější stabilní verze 126.0.6478.55 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 21 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Byl vydán Mozilla Firefox 127.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 127 je již k dispozici také na Flathubu a Snapcraftu.
Byla vydána (𝕏) nová verze 9.5 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
Společnost Raspberry Pi dnes vstoupila na Londýnskou burzu jako Raspberry Pi Holdings plc (investor).
Také na záložní server lze nasadit greylisting, a opět je to velmi žádoucí. Možná neškodí nasadit ho i v případě, že na hlavním serveru nasazen není. Je však potřeba dát si pozor na to, aby všechny výjimky nastavené na primárním serveru byly nastaveny i zde. O to se může opět postarat nějaký synchronizační mechanismus, ať už takový, jako je uveden výše (s tím, že se po přenosu vynutí načtení souborů), nebo například realizovaný pomocí rsync
(zde je výhoda v tom, že na druhé straně není potřeba provést žádnou akci, stačí synchronizovat soubory).
Při využití programu Postgrey bohužel nelze jednoduše synchronizovat databázi, takže je třeba se buď smířit s tím, že se budou záznamy na záložním serveru vytvářet samostatně, anebo použít nějaký jiný software, který synchronizaci databáze umožňuje. Například SQLgrey, Gld nebo Policyd.
Zatím záložní server testoval (z hlediska možnosti doručení) jen to, zda doručuje do určitých domén. Neověřoval ale, zda existují schránky či aliasy, pro které jsou zprávy určeny. To samozřejmě znamená, že se na něm mohou hromadit zprávy, které nebudou nikdy doručeny (po pokusu doručit je budou vráceny zpět). Většinou půjde o spam, který se nepodařilo eliminovat nějakou antispamovou metodou a zbytečně zabírá místo ve frontě.
Klíčový problém je dostupnost databází schránek a aliasů. Pokud jsou v souborech, je třeba zajistit synchronizaci. SQL databáze může běžet v replikovaném režimu (při kterém na záložním serveru funguje jako slave, tedy jako podřízená instance). Komplikace mohou být u využití LDAP, pokud tento funguje například jen uvnitř firmy (pak se musí buď zajistit replikace – v závislosti na možnostech konkrétní implementace LDAP – nebo prostě vůbec ověřování schránek nevyužívat).
Je-li vyřešen předchozí problém, zbývá ještě správně nakonfigurovat Postfix. Oproti serveru, který přímo doručuje do uživatelských schránek, se musí změnit jedna zásadní věc: transporty. Zatím o nich v rámci celého seriálu prakticky nebyla řeč, nicméně jde o poměrně významnou součást celé architektury Postfixu.
Postfix totiž funguje tak, že není pevně dáno, jak se s každou zprávou naloží. Existují sice výchozí modely chování, ale to vůbec neznamená, že je nelze změnit. Lze nadefinovat, jak program naloží s každou jednotlivou zprávou – a to jak přímo na bázi příjemců a domén, tak i funkcí serveru. Existuje základní výchozí transport, lokální transport (doručení lokálnímu příjemci), virtuální transport (doručení virtuálnímu příjemci) a transport pro relay (vzdálené doručení).
Pro běžné role serverů není potřeba do transportů zasahovat. Ovšem pokud má být něco jinak, než je obvyklé, je třeba transporty přenastavit. To je i případ záložního serveru, který ověřuje příjemce v databázi. To lze dělat na bázi doručování místním nebo virtuálním příjemcům – ale protože se zde nemá doručovat do schránek (nýbrž předávat primárnímu serveru), musí se upravit lokální, resp. virtuální transport.
Lze si to ukázat na situaci, ve které jde o virtuální příjemce (pro lokální by to bylo velmi podobné). Místo přímého doručování (například do úložiště typu Maildir) se použije doručování vzdálené, tedy relay. Záložní server tedy ověří příjemce, ale ponechá si zprávu ve frontě pro doručení na primární server.
virtual_transport = relay: virtual_mailbox_domains = moje.domena virtual_mailbox_maps = hash:/etc/postfix/vmailbox virtual_alias_maps = hash:/etc/postfix/virtual
Uvedený příklad je určen pro uživatele a aliasy v souborech (konkrétně hešových mapách), seznam domén je uveden přímo v parametru virtual_mailbox_domains
(další možnosti jsou popsány v 6. dílu seriálu). Když bude nyní vytvořena příchozí SMTP relace s pokusem doručit neexistujícímu příjemci či aliasu, server neexistující adresu odmítne. Pro platné adresy zprávu přijme a doručí ji na primární server.
Všimněte si, že už se neuvádějí další parametry používané při doručování virtuálním příjemcům (umístění schránek, identifikátor uživatele a skupiny atd.). Nemají tady totiž žádný význam.
Někdo se ještě zcela oprávněně může zeptat, co vlastně dotaz na e-mailovou schránku vrací, když nevrací cestu ke schránce. Odpověď je opět jednoduchá – může vracet cokoli neprázdného (tedy klidně i cestu ke schránce), protože jde pouze o test, zda uživatel existuje. Proto lze beze změny používat datové zdroje z primárního serveru.
Uvedený postup není jediný možný. Lze postupovat i jinak, bez přenastavování transportů. Například lze příjemce testovat v rámci restrikcí, tedy pravidlem v smtpd_recipient_restrictions
(check_recipient_access
). Má to své výhody i nevýhody. Výhoda je možnost upravit si restrikce lépe podle potřeb, nevýhoda hlavně nutnost řešit ověřování samostatně (bez přímého využití metody z primárního serveru).
Pokud serverem proteče jen několik málo zpráv denně (myšleno do řádu tisíců nebo desítek tisíc), není většinou vůbec potřeba se zabývat výkonnostními optimalizacemi. Server bude přinejhorším trochu pomalejší, ale jinak bude bez problémů fungovat. Pokud je ale průtok větší nebo musí server zvládat mnoho současně připojených uživatelů (protokolem IMAP), už to začíná být poněkud zajímavější. V takovém případě je dobré vědět, jak lze dosáhnout svižného a stabilního chování i pod velkou zátěží, což bude téma příštího dílu.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
Diskuse byla administrátory uzamčena
standardně lze pro účely "sdílení" IP použít vrrp, carp, různé formy natu alá load-balancing atd.To lze, ale jen v případě, že jsou cílové servery v jedné síti. Pokud jsou v různých sítích (nejlépe geograficky vzdálených), pak je to mnohem problematičtější. Nevím jak obecně ve světě, ale mám pocit, že tady v Česku jsou problémy zasahující celý telehouse nebo jeho velkou část (ať už souvisí s napájením, s routery nebo něčím jiným) dost časté na to, aby high availability řešení s tímto mělo počítat.
Pripada mi to zbytecne, muze mi nekdo rici v cem je vyhoda mit MX backup ?Je samozřejmě pravda, že "nejlepší léta" záložních serverů jsou už pryč, protože spolehlivost internetových připojení je dnes už taková, že většinou záloha není potřeba. Nicméně někdo se může rozhodnout, že záložní server používat bude.
kdyz v pripade nedostupnosti mailserveru zustava nedorucena posta ve spoolu na smtp serverech po dobu peti dnu ( default ) se je postak snazi co 30 minut odeslat.Na tohle nelze až tolik spoléhat. Jednak těch 5 dnů je opravdu jen default a nikdo nebrání správci nějakého serveru tu dobu zkrátit třeba na 1 den. Dále neplatí to tvrzení o 30 minutách. Jednak velmi záleží na konkrétním serveru, jeho chování a konfiguraci (např. Postfix standardně doručovací pokusy opakuje v prodlužujících se intervalech). Současně je potřeba brát v úvahu zatížení konkrétních serverů, takže i kdyby byl interval 30 minut, v reálu to může být podstatně víc. Proto se někdo může rozhodnout, že bude raději používat záložní server, který má ve své moci. Další možností je, že záložní server poskytuje ISP v rámci připojení (v ceně služby) a s předem definovanými parametry chování.
Pokud mi (ač normálně dostupný) primární server odpoví z důvodu graylistingu, že je dočasně out, nebude se to odesílající server snažit doručit na ten záložní?Může se pokoušet (nevím, jak který poštovní software vyhodnocuje různé dočasné chyby a jak na ně konkrétně reaguje).
Když na něm bude graylisting také asi se vrátí s dalším pokusem zas na primární, takže to asi zafunguje, ale nebude to dělat nějakou neplechu?Může se tím prodloužit doba doručení. Ovšem vzhledem k tomu, že u greylistingu je obecně problém s tím, že doba doručení pro první komunikaci může být dlouhá (a podle toho, jak moc to vadí, je potřeba rozhodovat, zda greylisting nasadit), za až tak moc velký problém to nepovažuji.