abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 01:44 | Zajímavý projekt

Kampaň na podporu chytrého telefonu Librem 5, jenž by měl respektovat bezpečnost, svobodu a soukromí uživatelů, úspěšně skončila. Bylo vybráno více než 2,1 milionu dolarů, tj. cíl kampaně byl splněn na více než 141 %. Objednáno bylo cca 3 000 telefonů. Telefon Librem 5 by měl být k dispozici v lednu 2019.

Ladislav Hagara | Komentářů: 3
včera 21:11 | Komunita

Ke zhlédnutí jsou videozáznamy přednášek z konferencí All Systems Go! (media.ccc.de) a GStreamer Conference 2017 (ubicast.tv) konaných o víkendu 21. a 22. října. All Systems Go! v Berlíně a GStreamer Conference 2017 v Praze.

Ladislav Hagara | Komentářů: 0
včera 20:33 | Komunita

MojeFedora.cz informuje (en), že Fedora 27 přináší snadný přístup k Red Hat Enteprise Linuxu. Virtualizační nástroj Boxy nyní umožňuje jednoduše stáhnout a nainstalovat Red Hat Enterprise Linux, který je pro vývojáře zdarma. Vytvořit lze neomezené množství virtuálních mašin s RHEL.

Ladislav Hagara | Komentářů: 2
včera 19:00 | Komunita

Konsorcium Linux Foundation oficiálně představilo licence pro komunitní otevřená data Community Data License Agreement (CDLA). První licence je copyleftová CDLA-Sharing a druhá permisivní CDLA-Permissive. Odpovědi na často kladené otázky ve FAQ.

Ladislav Hagara | Komentářů: 0
včera 13:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. pražský sraz, který proběhne ve čtvrtek 26. října od 18:00 hodin v karlínském Pivovarském klubu. Najdete jej kousek od metra Florenc na adrese Křižíkova 17, Praha 8. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

Ladislav Hagara | Komentářů: 0
včera 06:00 | Zajímavý software

Byla vydána verze 0.56 open source platformy Home Assistant (GitHub) pro monitorování a řízení inteligentní domácnosti naprogramované v programovacím jazyce Python verze 3 a bežící také například na Raspberry Pi. Pro vyzkoušení je k dispozici demo [reddit].

Ladislav Hagara | Komentářů: 0
22.10. 16:55 | Nová verze

Byla vydána verze 1.0 klienta F-Droid určeného pro instalaci aplikací do Androidu ze softwarového repozitáře F-Droid (Wikipedie), alternativy k Google Play, nabízející pouze svobodný a otevřený software. Podrobnosti v přehledu změn [Hacker News].

Ladislav Hagara | Komentářů: 8
22.10. 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 10
21.10. 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

Ladislav Hagara | Komentářů: 0
21.10. 06:00 | Komunita

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (10%)
 (1%)
 (0%)
 (1%)
 (75%)
 (12%)
Celkem 246 hlasů
 Komentářů: 8, poslední 22.10. 23:02
    Rozcestník

    Stavíme poštovní server – 16 (záložní server): Příkaz ETRN

    23. 3. 2010 | Lukáš Jelínek | Sítě | 10522×

    Příkaz ETRN

    link

    Za normálních okolností to (v případě programu Postfix) funguje tak, že záložní server zkouší s prodlužující se periodou doručit přijaté zprávy primárnímu serveru. Zejména při delším zadržování to však znamená, že od okamžiku, kdy je primární server dostupný, do doručení zpráv může uběhnout dlouhá doba. Aby šlo zprávy doručit dříve, existuje v rozšíření protokolu SMTP (konkrétně v RFC 1985) příkaz ETRN.

    Obdrží-li záložní server příkaz ETRN (pro určitou doménu, uvádí se v argumentu příkazu), zahájí doručení zpráv, a to obdobně, jako kdyby šlo o spontánní doručení (tedy vytvoří novou SMTP relaci, ve které zprávy předá, pokud nějaké zadržoval). Hodí se to pro - dnes již naštěstí velmi řídké – případy, kdy je primární server připojen přes dial-up nebo nějaké velmi nespolehlivé připojení.

    Pokud není žádoucí, aby se záložní server pokoušel zprávy automaticky doručovat, lze to zajistit příslušným nastavením v souboru master.cf. Běžně není důvod to dělat, ale kdyby to někoho zajímalo, návod najde v dokumentaci k Postfixu.

    Ohledně příkazu ETRN je důležité, aby byl záložní server správně nastaven, jinak příkaz nefunguje (server ho odmítne). Je to řízeno dvěma parametry – jednak fast_flush_domains (specifikace domén, pro které je příkaz povolen) a dále pak smtpd_etrn_restrictions (restrikce na příkaz ETRN).

    Parametr fast_flush_domains má výchozí hodnotu odpovídající parametru relay_domains. To je výhoda v případě, že se pro testování domén využívá tento parametr (viz výše), ale nevýhoda v případě, že se domény testují jen podle MX záznamů. Pak je lepší povolit ETRN pro všechny domény, například takto:

    fast_flush_domains = static:any
    

    Výsledkem dotazu na libovolnou doménu bude natvrdo hodnota „any“ (resp. lze použít cokoli neprázdného; hodnota „any“ má význam pro srozumitelnost konfigurace), proto bude příkaz povolen. Pro úplné vypnutí ETRN pro všechny domény by stačilo použít toto:

    fast_flush_domains =
    

    Dále lze nastavit oprávnění vůbec používat ETRN. Ve výchozím stavu je povolen neomezeně, což není úplně to pravé ořechové, protože by mohl být zneužit k DoS útoku (hlavně při větším počtu zadržovaných zpráv může být režie ETRN významná). Proto ho lze omezit například takto:

    smtpd_etrn_restrictions =
      permit_mynetworks,
      reject
    

    Tím se umožní přístup jen z vlastních sítí. Lze používat klasické metody omezování přístupu známé z jiných restrikcí. Příkladem může být třeba toto:

    smtpd_etrn_restrictions =
      sleep 5,
      check_etrn_access hash:/etc/postfix/etrn,
      permit_mynetworks,
      reject
    

    Takovéto nastavení bude po příkazu ETRN vždy čekat 5 sekund (dobré jako ochrana proti DoS), pak prověří doménu v hešové mapě v uvedeném souboru (lze zakázat některé domény i pro přístup z vlastních sítí a naopak některé povolit odkudkoliv). Možností je mnoho, například lze vyžadovat klientský certifikát, testovat existenci reverzního DNS záznamu či třeba dotazovat vzdálené blacklisty.

    Vyvolání příkazu ETRN

    link

    Zajímavá a důležitá otázka je, jak odeslat příkaz ETRN záložnímu serveru. Odpověď je jednoduchá – musí se o to postarat správce. Primární server (ve smyslu jeho SMTP služby) nesleduje, kdy je dostupný zvenčí, kdy na něj lze doručovat poštu.

    V první řadě je třeba identifikovat stavy, kdy server začne být (po nedostupnosti) opět dostupný. Takovými stavy je samotné spuštění Postfixu a také aktivace příslušných síťových rozhraní. Nejjednodušeji to lze tedy realizovat tak, že se do skriptů spouštěných v uvedených případech přidá zavolání příslušné akce, které bude předcházet dostatečná čekací doba, aby byl server plně připraven (např. 10 sekund).

    K odeslání příkazu lze použít například program fetchmail, který je standardně dostupný v podobě balíčků pro všechny běžné distribuce. Příkaz pro odeslání příkazu by vypadal například takto:

    fetchmail -p ETRN --fetchdomains moje.domena postak-zalozni.moje.domena
    

    Tento příkaz způsobí, že se záložnímu serveru odešle příkaz ETRN pro doručení pro doménu moje.domena. Pokud by bylo potřeba vyžádat doručení pro více domén, uvedly by se jako seznam.

    Lze samozřejmě poměrně snadno zajistit, aby se příkaz ETRN posílal i na základě skutečné dostupnosti zvenčí. K tomu poslouží monitorovací program (např. monit), který bude periodicky testovat dostupnost záložního serveru a pokud dojde k obnovení dostupnosti po období nedostupnosti, zavolá program k odeslání příkazu ETRN.

    Silnější zabezpečení

    link

    Pokud si nakonfigurujete záložní server takto jednoduše, bude sice hladce fungovat, současně se ale brzy stane cestou, kterou se bude na hlavní server tlačit zbytečný spam. Proto je žádoucí server silněji zabezpečit (základní restrikce jsou již uvedeny v prvním příkladu, ale to je opravdu jen úplné minimum).

    Podrobné informace o ochraně proti spamu najdete v 9.11. dílu seriálu. Většina popsaného platí prakticky ekvivalentně i pro záložní server, samozřejmě s nutností přizpůsobení některých věcí. Co se týká samotného Postfixu, do main.cf se vyplatí přidat následující řádky:

    smtpd_client_connection_rate_limit = 10
    smtpd_client_message_rate_limit = 20
    smtpd_client_recipient_rate_limit = 200
    smtpd_recipient_limit = 100
    smtpd_recipient_overshoot_limit = 10
    

    Limity jsou oproti hlavnímu serveru nastaveny tvrději, což má v tomto případě svůj smysl. Je to proto, že záložní server se k příchozím legitimním zprávám v praxi dostane dost zřídka (jen při nedostupnosti primárního serveru), naopak bude velmi často konfrontován se spamem. Konkrétní hodnoty nejsou samozřejmě žádné dogma, nechť si je každý upraví podle potřeb a zkušeností.

    amavisd-new, Spamassassin a ClamAV

    link

    Na použití programů pro ochranu proti spamu a virům se oproti primárnímu serveru nic nemění. Sice by se dalo spekulovat o možnosti nekontrolovat na hlavním serveru zprávy, které už byly zkontrolovány na serveru záložním, ale zejména u virů to není dobrý nápad (mezi doručením na záložní server a předáním na server primární může být do databáze doplněn virus, který by jinak nebyl zachycen).

    Prahy pro hodnocení zpráv lze na záložním serveru nastavit o něco přísněji, protože legitimní zprávy se na něm budou vyskytovat jen výjimečně a není tedy příliš pravděpodobné, že by byla nějaká neoprávněně zahozena.

    Co si však zaslouží úvahu, je učení bayesovského filtru. Na záložním serveru to může být docela problém, protože materiálu pro učení (zejména legitimních zpráv) moc není a hlavně nelze vycházet z toho, jak zprávy hodnotí uživatelé.

    Možností, jak to řešit, je více. Asi nejjednodušší je periodicky (např. jedenkrát denně) přenášet obsah databáze primárního serveru na server záložní. Čistá metoda je export databáze do souboru, přenos tohoto souboru na záložní server a import do databáze z přeneseného souboru. Není potřeba nijak řešit vlastnosti databází ani vlastnosti architektur obou serverů.

    Jak bude konkrétně celá operace realizována, to už záleží na správci serverů (celé řešení samozřejmě předpokládá, že záložní server slouží právě jednomu primárnímu serveru). Lze ji celou provést z primárního serveru, ze záložního serveru, případně kombinovaně. Následující popis bude vycházet z první varianty, tedy z řešení na primárním serveru. Tam se vytvoří následující skript (umístěný například v /etc/cron.daily na primárním serveru):

    #!/bin/bash
    
    BACKUPPATH=/var/lib/spamassassin/sa.backup
    sa-learn --backup > $BACKUPPATH
    sftp -b /etc/sftp/sa-sync postak
    ssh postak sa-learn --restore $BACKUPPATH && rm $BACKUPPATH
    

    Uvedený skript předpokládá, že se lze ze záložního serveru na ten hlavní přihlašovat certifikátem pod vhodným uživatelem (postup při nastavení najdete například v manuálu k ssh – přesahuje rámec tohoto článku). Pro samotný přenos přes SFTP se použije skript /etc/sftp/sa-sync s příkazy pro SFTP. Ten může vypadat například takto:

    put /var/lib/spamassassin/sa.backup /var/lib/spamassassin/sa.backup
    quit
    

    Funkce obou skriptů je z jejich obsahu zřejmá. Bylo by samozřejmě žádoucí je přepsat do čistší podoby, aby byly schopny správně vyhodnotit všechny chyby, které při přenosu mohou nastat, a vypsat o tom zprávu do logu.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    23.3.2010 12:11 kolcon | skóre: 15 | blog: kolcon
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 16 (záložní server)
    a nestacilo by na tom zaloznim serveru proste nastavit relay_host ?
    Luk avatar 23.3.2010 17:28 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 16 (záložní server)
    Jde o to, co znamená to "prostě nastavit". Bez kombinace s restrikcemi to nejde, jinak z toho bude open relay se všemi důsledky. Kromě toho je zbytečné to nastavovat, když záložní server ví, kam má zprávy předávat (dozví se to z MX záznamů). Pokud navíc záložní server slouží více primárním serverům, ani to nastavit nejde, protože jsou ty servery různé.
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    23.3.2010 14:00 Petr Horacek
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 16 (záložní server)
    Je mozne nejakym podobnym zpusobem postavit ne jen zalozni, ale duplicitni mail server takovy, ze v pripade vypadku primarniho prevezme v plne siri jeho ulohu (vcetne uzivatelskych uctu, stavajicich dat a podobne), a to idealne transparentne, bez nutnosti prekonfigurovat MUA? Tahove high-availibility reseni.

    Dekuji za odpoved.
    Luk avatar 23.3.2010 17:42 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 16 (záložní server)
    Bez nutnosti překonfigurovávat MUA to bude docela problém. Buď by musely být DNS záznamy s TTL=0 (nebo hodně nízkou hodnotou) a spoléhat se na to, že si to cachující servery nebudou vykládat po svém. Pak by se musely odněkud ty DNS záznamy měnit podle dostupnosti serverů. Druhá možnost je z to z IP adresy uvedené v DNS to tunelovat jinam, ale to už se zavádí single point of failure (když selže, selže všechno).

    Samozřejmě duplicitní server postavit lze, s uživatelskými účty není problém (ať už jsou v databázi, přes LDAP, případně souborově). Zbývá vyřešit jediný problém, a to je úložiště. Pokud bude vzdálené (v technologickém smyslu) a transparentně synchronizované mezi různými geografickými místy, opět to není až tak velký problém.
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    26.3.2010 08:06 tomfi | skóre: 19
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 16 (záložní server)
    Sakra, to jsem nějak zaspal dobu... myslel jsem, že standardně lze pro účely "sdílení" IP použít vrrp, carp, různé formy natu alá load-balancing atd...

    ale co, možná i to DNS někdo považuje za failover technologii, i když je to trochu podle hesla "když to nezvládnu nastavit na serveru tak ten problém přenesu jinam (na klienta) :D"
    Vždyť jsou to jen jedničky a nuly ...
    26.3.2010 08:49 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 16 (záložní server)
    Problém je ve sdílení IP. K čemu mi je cluster, když se k němu klient nedostane.
    Luk avatar 26.3.2010 12:40 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 16 (záložní server)
    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.
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    24.3.2010 12:41 Duskol
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 16 (záložní server)
    Pripada mi to zbytecne, muze mi nekdo rici v cem je vyhoda mit MX backup ? 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.
    Luk avatar 24.3.2010 12:53 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 16 (záložní server)
    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í.
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    26.3.2010 15:44 fanda
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 16 (záložní server)
    Trochu mi není jasné fungování v případě graylistingu. 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í? 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?
    Luk avatar 26.3.2010 17:02 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 16 (záložní server)
    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.
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.