Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
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.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz