BreadboardOS je firmware pro Raspberry Pi Pico (RP2040) umožňující s tímto MCU komunikovat pomocí řádkového rozhraní (CLI). Využívá FreeRTOS a Microshell.
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 24.05. Přehled novinek i s náhledy a videi v oficiálním oznámení. Do balíku se dostalo 5 nových aplikací: Audex, Accessibility Inspector, Francis, Kalm a Skladnik.
Byla vydána (𝕏) nová verze 18.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
V neděli 26. května lze navštívit Maker Faire Rychnov nad Kněžnou, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byla vydána nová stabilní verze 3.20.0, tj. první z nové řady 3.20, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu 64bitové architektury RISC-V.
Společnost Jolla na akci s názvem Jolla Love Day 2 - The Jolla comeback představila telefon se Sailfish OS 5.0 Jolla Community Phone (ve spolupráci se společností Reeder) a počítač Jolla Mind2 Community Edition AI Computer.
LibreOffice 24.8 bude vydán jako finální v srpnu 2024, přičemž LibreOffice 24.8 Alpha1 je první předběžnou verzí od začátku vývoje verze 24.8 v prosinci 2023. Od té doby bylo do úložiště kódu odesláno 4448 commitů a více než 667 chyb bylo v Bugzille nastaveno jako opravené. Nové funkce obsažené v této verzi LibreOffice najdete v poznámkách k vydání.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 141 (pdf) a HackSpace 78 (pdf).
Byla vydána verze 2.0.0 programovacího jazyka Kotlin (Wikipedie, GitHub). Oficiálně bude představena ve čtvrtek na konferenci KotlinConf 2024 v Kodani. Livestream bude možné sledovat na YouTube.
Byla vydána nová major verze 27.0 programovacího jazyka Erlang (Wikipedie) a související platformy OTP (Open Telecom Platform, Wikipedie). Přehled novinek v příspěvku na blogu.
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.