Z důvodu omezené propustnosti USB externích disků jsem se rozhodl pořídit k notebooku eSATA Express Card Adapter (PC Card Adapter jsem zavrhl). Na webu VirtuaVia jsem objevil adaptér prodávaný jako ExpressCard to Dual eSATA II (eSATA port x 2) za € 39.00 plus € 18.00 za dopravu. Zjistil jsem, že se jedná o kartu APIOTEK. U nás se mi ji nepodařilo sehnat, tak jsem ji objednal přímo z Francie. Platba on-line kartou, dodávka přišla za 2 dny, ovšem poslali omylem jiné zboží (v ceně € 69.00). Trochu komplikace, ale nakonec se vyřešilo. Chtěl jsem právě tuto kartu, protože umí RAID 0, RAID 1 a sw RAID 5. Žádné jiné adaptéry s podporou RAIDu jsem nenašel. Navíc je podporována i v linuxu.

Stáhl jsem si potřebný software a dokumentaci: APIOTEK, Silicon Image, recenze. Ze všeho nejdřív jsem aktualizoval BIOS verzí RAID. Ve Windows XP jsem pak použil odpovídající ovladač pro RAID a abych mohl s RAIDem pracovat, musel jsem ještě instalovat software z balíčku 3132-W-R_15180b.msi. V PDF je k dispozici kvalitní dokumentace SATARAID5-UserGuide_v1.60.pdf.

Práce s kartou je velice jednoduchá, jen jsem musel přijít na to, jak ji používat. Pokud je karta zasunutá ve slotu před zapnutím notebooku (HP Compaq nc6320), nabízí se možnost vstoupit do BIOSu karty a spravovat připojené disky (RAIDové pole). Naběhnutí trvá ale příliš dlouho a disky stejně nejsou vidět - zkrátka takto to nefunguje. Pokud chceme pracovat s disky v RAID poli, je třeba zasunout kartu do slotu v okamžiku po naběhnutí BIOSu notebooku, ale před startem Windows, a to se zapojenými disky. Pokud kartu zasuneme do slotu, když už Windows běží, sw pro správu RAID nefunguje a taky máme zaděláno na problém s rozhozením RAIDu. Naopak pokud chceme připojit jen samostatné disky nezapojené v RAID poli, můžeme kartu zasunout do slotu kdykoliv během práce ve Windows a disky taky připojovat a odpojovat dle libosti. Odpojování disků i karty se provádí přes ikonu Bezpečně odebrat hw.

Mám k dispozici několik disků, krabiček na disky (tzv. enclosure) a různých udělátek (konvertor IDE-SATA, redukci kabelu SATA na eSATA a naopak, USB 2.0 IDE konvertor aj.). Nedalo mi tedy, abych neotestoval výkonnost různých disků (2,5", 3,5", IDE, SATA) přes různá zapojení (USB konvertor, USB krabičky, SATA krabičky, zapojení v RAIDu). A když už jsem byl v tom, přidal jsem pro zajímavost i test USB flash disků. Testoval jsem i interní disky, a to na zmíněném nc6320 (Intel Core 2 CPU T7200 2.00GHz) a dále na PC (Intel Pentium 4 CPU 3.20GHz) - oba 2 GB RAM. K testu jsem použil zkušení verzi HD Tune Pro 3.0. Podrobné výsledky jsem shrnul do tabulky. Screenshoty naleznete zde:

Chtěl jsem zkusit používat externí 3,5" disk místo interního, což se ukázalo jako problematické. Nejdřív jsem nabootoval SystemRescueCD a před startem jsem zasunul Apiotek i se zapnutým diskem. Linux si poradil výborně, bez problémů jsem měl disk dostupný jako sdb. Spustil jsem gparted a postupně zkopíroval všechny oddíly z interního disku sda na externí sdb (čímž jsem si taky udělal komplet zálohu).

Boot z karty Apiotek a externího disku byl oříškem. Postupně jsem vyzkoušel různé změny v BIOSu notebooku, upgrade BIOSu notebooku, ale při zasunuté kartě a zapnutém disku stroj při bootu buď zatuhne, nebo po delší době naběhne, ale externí disk nenajde. Na webu jsem našel jen to, že výrobce čipu SiI se snaží, aby boot byl možný, ale ne vždy se to daří, záleží na hw stroje, takže smůla. Řešení ale existuje: stačí při startu notebooku mít kartu nezapojenou a mít disk připojen přes USB (moje krabička Delock má připojení USB i eSATA), po naběhnutí zavaděče Windows zastrčit kartu se zapojeným eSATA konektorem v disku a spustit boot Windows. Start Windows se mi subjektivně zdál o něco rychlejší, ale po zalogování spadne nějaký systémový proces a Windows jsou nepoužitelná. Nemám už chuť ani čas si s tím víc hrát, tak to dávám k ledu.

Narazil jsem ještě na jednu recenzi s diskusí v češtině. Je tam sice z počátku dost nepřesností, ale dá se z toho něco zajímavého dostat: Test mbp int.HDD vs. eSATA vs. FW800

Nedalo mi to, abych nevyzkoušel použití externího disku místo interního s linuxem (mám disk rozdělen na více oddílů s různými verzemi CentOS a Debian). Výsledek funguje téměř tak, jak má, ale dobrat se k němu chtělo taky trochu úsilí.

Nejdřív jsem musel nainstalovat grub i na externí disk. To jsem udělal jednoduše: nabootoval linux z interního disku (Debian i CentOS externí disk vidí), spustil grub a zadal příkazy root (hd0,1) a setup (hd1). Při dalším startu systému způsobem jako 10.4.08, tj. ext. disk připojen přes USB se spustí grub z ext. disku. Pak je třeba zasunout kartu Apiotek do slotu Express Card a zvolit, co chci bootovat. Začnu Debianem, kde to bylo jednodušší.

Debian startoval bez jakýchkoliv úprav. Problém byl pouze v tom, že náhodně byl někdy detekován jako první disk interní a jako druhý disk externí, v tom případě bootoval z interního disku z sda5, někdy to bylo naopak, tj. bootoval z externího disku opět z sda5. Řešení bylo celkem snadné, použil jsem v /etc/fstab a v /boot/grub/menu.lst místo odkazu natvrdo na oddíl sda5 LABEL oddílu. Oddíl jsem si pojmenoval příkazem tune2fs -L deb-ext /dev/sdb5. Tím jsem docílil toho, že při bootu z grubu na externím disku Debian vždy nastartuje z oddílu s názvem "deb-ext", tedy z externího disku. V systému je ovšem stále náhodně jako první disk (sda) externí disk a druhý disk (sdb) je interní disk nebo naopak. Systém je tedy přimountován někdy na /dev/sda5 a někdy na /dev/sdb5.

CentOS jsem řešil pomocí LABEL stejně jako Debian. Navíc jsem ale musel vytvořit nový initial ramdisk, protože jinak jsem se dostal jen na kernel panic. Postupoval jsem takto: Nabootoval jsem CentOS z interního disku, připojil si oddíl sdb2 s CentOS z externího disku (mount /dev/sdb2 /media/sdb2), ze kterého budu chtít startovat. Doplnil jsem do /media/sdb2/etc/modprobe.conf řádek
alias scsi_hostadapter2 sata_sil24, pak spustil příkaz
mkinitrd -f --fstab /media/sdb2/etc/fstab /media/sdb2/boot/initrd-2.6.9-67.0.7.img 2.6.9-67.0.7.EL. Nyní již nabootuji také CentOS z externího disku. Zajímavé je, že (na rozdíl od Debianu s jádrem 2.6.18-6, který si dělá, co chce) CentOS s jádrem 2.6.9-67.0.7 nastartuje vždy s prvním diskem interním, naopak s jádrem 2.6.18-53.1.14 vždy s prvním diskem externím. Nakonec ještě pár čísel.

Hledal jsem nějaké bezpečnostní rozšíření do Squida a mimo jiné narazil na krásnou jednoduchou věcičku. Jmenuje se SqStat a jedná se o php skript, pomocí kterého lze zobrazovat aktivní síťová spojení jednotlivých uživatelů procházející přes Squid. Stačí rozbalit do adresáře webového serveru a drobně upravit squid.conf a vše je hotové během 5-10 minut (popis instalace je na webu). Pro mě užitečné především pro rychlé zjištění, zda někdo nepřetěžuje internetové spojení.

Semináře o bezpečnosti mě zase trochu postrašily a prezentující firmy nabudily trochu vylepšit zabezpečení naší firmy. Ukázalo se, že řešení za stovky tisíc (v lepším případě za desítky tisíc) korun nenabízí vlastně skoro nic, co bychom již neměli nasazené. Zalíbila se mi ale možnost rozšířit statický squid o další blacklisty. První volba vedla na squidGuard. Pak jsem ale narazil na URLfilterDB, který se mi líbil víc, a to především ze dvou důvodů:

1. je mnohonásobně rychlejší než squidGuard
2. umí obecně blokovat i https provoz.

Líbí se mi především ta blokace https provozu, neboť může blokovat stránky, které

• nemají certifikát vydaný známou důvěryhodnou certifikační autoritou (neboli certifikát je obvykle self-signed)
• používají IP adresy místo doménových jmen.

URLfilterDB se skládá ze dvou komponent: programu, který je zdarma, a z databáze, která je placená. Místo placené databáze se však dá použít jakákoliv databáze v textovém formátu. Toho jsem využil a začal používat zdarma dostupné blacklisty, na které odkazuje squidGuard.

Samozřejmě se ukázalo, že filtry blokují i některé "regulérní" weby. Komplikacím se dá předejít tak, že program nejdřív několik dní necháme běžet v testovacím režimu, kdy nedochází ke skutečnému blokování stránek, ale v logu se vše zaznamenává. Pokud blokovanou stránku chceme povolit, stačí ji přidat na seznam alwaysallow. Toto řešení je mnohem snazží, než reportování chybných stránek v blacklistech jejich autorům, což se mi zatím nedaří. Blacklist, který používám, je kombinací 2 listů. Jeden odkazuje na německy psaný web a k blacklistu není povolen přístup. Druhý blacklist má i kontaktní mail, ale i po několika dnech se mnou reportované změny zatím neprojevily.

A ještě jedna věcička je na URLfilterDB šikovná: program s blacklisty může běžet na úplně jiném serveru, než kde běží squid.

SPAM je věčný problém a občas se objevuje těžko řešitelná situace:
Mnohé spamy jsou v mnoha případech pouze vrácené zprávy od spammera na zfalšovanou adresu, která je v tomto případě někoho z naší firmy. Přesněji: spammer rozešle milióny zpráv na různé pravé i náhodné adresy a jako odesílatele uvede mail někoho z naší firmy. Maily, které jsou poslané na neexistující adresu, se vrací odesílateli s informací, že adresát neexistuje. Odesílatel je ale v tomto případě někdo z naší firmy, takže to jde na nás. Bohužel spamassassin tyto vrácené spamy nemůže rozpoznat jako spamy, protože se často jedná jen o záhlaví původního spamového mailu.

Poštovní server využívá k doručení zpráv procmail, tak jsem do .procmailrc napsal speciální pravidlo, které tyto zprávy bude rovnou mazat. Chtělo to jen trochu analyzovat hlavičky i těla zpráv. Není to 100%, ale funguje. Falešně zachytí občas potvrzenou doručenku, což ale není žádná tragédie. Zde je tedy část souboru .procmailrc z home adresáře uživatele:
:0 HB
* ^Return-Path:\ \<MAILER-DAEMON@nasedomena\.cz\>$
* !^(Original-)?Message-ID:\ \<.*@(((ruzna|jmena\.nasedomena|jinejmeno\.jinanasedomena|\ dalsinasedomena)\.cz)|(nazevpc)|(jinepc)|(dalsipc)|(poslednipc))\>$
/dev/null

Tentokrát z jiného soudku - přináším autentickou komunikaci, jak se banka umí chovat ke klientovi. Jedná se o ukončenou smlouvu o stavebním spoření, na kterou banka nezaslala státní podporu. Celé anabázi předcházel můj telefonický dotaz na privátní poradkyni, proč mi nepřišla státní podpora. Ta zjistila, že mám ve jméně o jedno písmeno navíc. Údajně mi banka poslala dopis, ve kterém mě o chybě informovala a instruovala mě, jak postupovat. Poradkyně mě požádala o návštěvu pobočky kvůli opravě. S tím jsem nejdřív souhlasil, ale pak si to rozmyslel...

Datum: Mon, 09 Jun 2008 15:08:40 +0200, adresováno na privátní poradkyni
Vážená paní,
ještě jsem se díval, jak je to s tou chybou ve jméně u mé smlouvy. Pokud jsem se nepřehlédl, tak se chyba objevila až letos od výpovědi smlouvy. Žádný dopis, který by mě vyzýval k opravě, mi doručen nebyl a jsem přesvědčen o tom, že nebyl ani odeslán. Jelikož mi byla vyplacena uspořená částka korektně a v průvodním dopise je uvedeno, že mi tak bude vyplacena i státní podpora, jedná se zcela evidentně o VAŠI chybu se snahou ji svést na zákazníka a navíc ho ještě obtěžovat zbytečnou návštěvou.
Jelikož mi nebyla vyplacena vaší vinou státní podpora ve stanoveném termínu, žádám o zaplacení úroku z prodlení a vzhledem z výše uvedenému chování žádám minimálně ještě omluvu.
Dnes se tedy osobně nedostavím a očekávám další kroky z vaší strany.
Váš nespokojený klient

Datum: Tue, 10 Jun 2008 14:30:00 +0200, od privátní poradkyně
Dobrý den pane Geisselreitere,
Nikdy bych si nedovolila někoho obviňovat z nějaké chyby a už vůbec ne noprávněně. Já jsem na Váš telefonický dotaz zjišťovala údaje ve Stavební spořitelně ČS, a.s, protože některé údaje v našem (Česká spořitelna,a.s.) systému nevidíme. Tudíž jsem Vám tlumočila odpověď. Včera jsem zaslala e-milem na Stavební spořitelnu dotaz ohledně nevyplacené státní podpory k Vaší smlouvě.
Zde je odpověď:
Dobrý den paní,
klientovi byla přiznána SP za r. 2007 ve výši 0,- Kč, a to z následujícího důvodu:
V souvislosti s nárokováním SP pro klientův účet stavebního spoření bylo zjištěno, že jeho identifikační údaje evidované SSČS, a.s. se neshodují s údaji v evidenci obyvatel ministerstva vnitra, v případě cizích státních příslušníků s údaji v evidenci cizinecké policie.
Žádáme proto klienta o kontrolu osobních údajů evidovaných u SSČS s údaji uvedenými v platném průkazu totožnosti. Pokud klient zjistí jakékoli nesrovnalosti, prosíme o písemné sdělení s uvedením správných údajů, případně o návštěvu kterékoliv pobočky ČS, kde budou změny údajů provedeny.
V případě, že jsou všechny údaje shodné, žádáme klienta, aby prověřil správnost údajů v centrální evidenci obyvatel, tj. obrátil se na Ministerstvo vnitra - odbor správních činností, nám. Hrdinů 3, pošt. přihrádka 155/SC, 140 21 Praha 4, tel. 974 817 239. Správnost Vašich identifikačních údajů v evidenci obyvatel SSČS nemá možnost jakkoliv ovlivnit.
S přáním příjemného dne
...
Stavební spořitelna ČS, a. s.
Úsek podpora prodeje
Vážený pane Geisselreitere,
Za chybu ve Vašem příjmení se velice omlouvám, z vlastní zkušenosti vím jak je to nepříjemné. Budu ráda pokud se domluvíme na schůzce - navrhněte termín, pokusím se Vám přizpůsobit. Na státní podporu nárok máte, ale bude vyplacena po vyřešení vzniklé nesrovnalosti.
Děkuji za odpověď a přeji hezký den

Datum: Tue, 10 Jun 2008 15:13:36 +0200, adresováno na privátní poradkyni
Vážená paní,
jen pro upřesnění chci říct, že si nestěžuji na vás, ale na ČS, resp. SSČS.
Vaše odpověď je zcela typická pro jednání velké banky s "malým" klientem: jen jste jinými slovy zopakovala to, co jste mi již řekla: v mém příjmení je chyba, dostavte se. A já zase opakuji: PROČ bych se měl dostavovat! Chybu opravte, jak má být, a peníze pošlete (opakuji: ne nutně vy osobně, ale ČS/SSČS).
Zkuste se nad tím zamyslet: že se jednou u vás někdo překlepl znamená, že to nemůže opravit, jak to bylo? Že kvůli tomu musí klient na pobočku? Že mu nepošlete státní podporu a ani ho o tom neinformujete? Myslíte to vážně?! Že reakce na emailovou stížnost musí trvat bez půl hodiny 24 hodin?
Chyba v mém příjmení mi nijak nevadí, za to jsem ani omluvu nepožadoval.
Z vyjádření SSČS je řečeno, že mám písemně sdělit správné údaje, PŘÍPADNĚ navštívit pobočku. Písemně tedy sděluji, že je chyba v mém příjmení, které má správně být Geisselreiter. Mé správné údaje tedy jsou:
...

Datum: Thu, 12 Jun 2008 15:46:47 +0200, od privátní poradkyně
Dobrý den pane Geisselreitere,
Vaše vyjádření bylo 10.6.2008 e-mailem předáno na Stavební spořitelnu ČS, a.s. 11.6.2008 Váš požadavek prošetřil odborný úsek SSČS. Dnes 12.6.2008 přišlo vyjádření SSČS - omlouváme se za chybu v příjmení, bylo opraveno. Státní podpora bude nárokována v dalším kole na podzim. Klient by měl mít připsánu případnou SP na účet během měsíce října.
K Vaší připomínce k rychlosti odpovědi Vám sděluji, že distribuční cesta (helpdesk) má na vyřízení e-mailu 24 hodin, tudíž limit byl splněn. Tento e-mail je jeden ze stovek e-mailů, které denně vyřizujeme.
Já osobně mám každý den několik různě dlouhých jednání s klienty a poštu tudíž vyřizuji průběžně během dne.
Děkuji za pochopení a přeji hezký den

Datum: Fri, 13 Jun 2008 12:02:16 +0200, adresováno na zástupce ředitele pobočky
Vážená paní,
okolnosti mě přinutili znovu vás kontaktovat, bohužel v nemilé věci. Hned na úvod musím konstatovat, že jednání Vaší banky s klienty je ještě hodně vzdálené od toho, kdy by klient měl pocit, že si ho banka váží a že mu je rovnocenným partnerem. První větší rozčarování mě čekalo, když jsem na břeclavské pobočce jednal po pěti letech fixace hypotečního úvěru o nových podmínkách při skončení fixace. Nemožnost a neochota cokoliv dohodnout mě donutila převést hypotéku k jiné bance. Obdobný příběh jiného zákazníka jsem četl zrovna nedávno, viz Malá hypotéční anabáze.
Ale k jádru věci. Jak jsem již v lednu požadoval na vás (viz původní mail níže), vypověděl jsem staré smlouvy a založil nové. Když mi nedávno došel závěrečný výpis, zjistil jsem, že nemám připsanou žádnou státní podporu, na kterou jsem měl nárok. Nejdřív jsem tedy kontaktoval telefonicky paní ... a ta zjistila, že se jedná o chybu v mém jméně a z toho důvodu mi nemohla být státní podpora vyplacena. Prý mi banka posílala o tomto vyrozumění, ovšem já nic nedostal. Dohodli jsme se, že kvůli tomu zajdu na pobočku, aby se to dalo do pořádku. To jsem si nakonec rozmyslel, protože
a) se mi to jeví zcela zbytečné plýtvání mého celkem vzácného a drahého času a
b) jsem si prošel všechny doklady a zjistil, že chyba vznikla překlepem až při psaní výpovědi smlouvy.
Následovala výměna dvou e-mailů s paní ..., které přikládám. K tomu jen dodávám, že v prvním mailu byla ještě jakási snaha o omluvu, ve druhém už jen suché konstatování faktů bez jakékoliv omluvy či kompenzace.
Dosáhl jsem tedy toho, že nemusím na pobočku, že jsem ztratil nesmyslnou komunikací skoro tolik času, jako kdybych na pobočku zašel a poslouchal jak stádo, co si úředník usmyslí, že jsem znechucen, že peníze, které jsem měl dostat koncem dubna, dostanu o půl roku později.
Očekával bych spíš to, že se mi dostane omluvy za chybu, kterou jste způsobili, že peníze dostanu neprodleně od vás a na peníze od státu si počkáte do října vy a ne já, že mi nabídnete nějakou kompenzaci nebo výhodu.
Ano, ono se nejedná o nic závratného, ale zde jde o princip.
Ano, chybu může udělat každý, to vám nezazlívám, problém je v jejím řešení a v chování ke klientovi.
Ať už tato fraška skončí jakkoliv, rozhodl jsem se ji zveřejnit.
Možná jsem pro vás nyní jeden bezvýznamný klient z pěti milionů, ale co když budu zítra např. chtít úvěr na 10 milionů? Nevím, zda bych šel do ČS.
Doufám, že tento mail vás přiměje alespoň k zamyšlení.
S přáním pěkného dne
Miroslav Geisselreiter
P.S. Potvrďte mi prosím alespoň to, že jste tuto zprávu dostala. Děkuji.

Datum: Fri, 13 Jun 2008 16:46:27 +0200, od zástupce ředitele pobočky
Dobrý den, pane Geisselreitere,
děkuji za Vaši zprávu - potvrzuji přijetí. Vzhledem k dnešní časové vytíženosti se nemohu seznámit se všemi podrobnostmi. Vyjádření k celkové situaci Vám jistě zašlu v průběhu příštího týdne.
Hezký víkend.

Dodatek září 2008:
Žádná odpověď již nepřišla. Peníze došly na účet v polovině září 2008.

S přípravou nového serveru jsem se potrápil se SELinuxem. Nechtěl jsem ho ale vypnout, tak jsem bojoval a zde uvádím, co jsem musel provést, aby mi chodilo to, co jsem chtěl.

U clamAV byl problém v tom, že výchozí nastavení politiky bylo na /var/lib/clamav, ale clam pracuje s /var/clamav, dále výchozí bylo /var/log/clamav/clamav.*, ale clam má /var/log/clamav/clamd.*. Tak zadáno:
semanage fcontext -a -t clamd_var_lib_t "/var/clamav(/.*)?"
semanage fcontext -a -t clamd_var_log_t "/var/log/clamav/clamd.*"
Příkaz restorecon skončil na nedostatečných oprávněních, takže jsem řešil takto:
touch /.autorelabel
shutdown -r now

Další problém se vyskytl s procmailem a spamd. Šlo o to, že jsem domovské adresáře neměl v adresáři /home, ale v jiném adresáři a ještě na jiném diskovém oddílu. Po delším boji, než jsem přišel na to, že je problém právě s domovskými adresáři, stačilo nakonec jen toto:
semanage fcontext -a -t -f -d -t root_t "/samba/"
restorecon /samba/ (restorecon nyní zabral bezchybně a restart nebyl třeba).

Další úprava se týkala samby, bylo třeba již jen dle man samba_selinux provést:
semanage fcontext -a -t samba_share_t "/samba/data(/.*)?"
restorecon -R -r /samba/

Ještě bylo třeba provést nastavení pro named. Nejdřív to chtělo změnit vlastníka adresáře /var/named/chroot/var/named z uživatele root na uživatele named, dále dle man named_selinux provést:
setsebool -P named_write_master_zones 1

Jelikož používám samba server i jako doménový server a uživatelé mají na serveru své cestovní profily, bylo nutno zadat ještě příkaz:
setsebool -P samba_enable_home_dirs 1

Již nějakou dobu hledám pro firmu cenově i výkonově vhodné diskové úložiště. Od firmy AGORA plus, a.s. jsem měl na víc než 2 týdny zapůjčené zařízení Hitachi SMS 100. Firma Hitachi se snaží v segmentu pro malé a střední firmy prorazit právě s tímto zařízením, jinak dodává řešení spíš pro velké firmy. Já ovšem silně pochybuji, že s takovýmto zařízením a obchodními podmínkami uspěje.

Začnu tím pozitivním: SMS 100 bude pravděpodobně robustní a spolehlivé, jak se na výrobce sluší. Výhodou může být uváděná snadná automigrace na jiné zařízení Hitachi stejné řady. Součástí je i sw k vytváření snapshotů, naopak sw k plnému zálohování je nutno dokoupit. To je ale asi tak vše, co lze přičíst k dobru. Více méně standardní vlastnosti nemá smysl rozebírat (možnost 2 řadičů s nastavením load-balancingu, 2 gigabitové iSCSI porty na každý řadič, 2 zdroje napájení).

A nyní to horší: zařízení je s prominutím velké jak kráva a hučí jak Boeing 747. Tedy výška 2U a šířka 482,6 mm se zdá ideální do racku, ale to by ten rack musel být navíc pěkně hluboký. Do našich standardních racků se s hloubkou 731,4 mm nevejde ani omylem (může ale ležet volně na racku). Hluk se dá též přirovnat k vysavači a rozléhal se přes zavřené dveře serverovny přes celou chodbu. Technicky se připravte na další omezení: pole se dodává s předem stanoveným počtem a kapacitou disků a tu není později možné změnit za žádných okolností. Disků SATA nebo SAS může být 6, 8 nebo 12 a vždy jsou v poli RAID-6. Pokud si tedy objednáte pole např. s šesti SATA disky o kapacitě 500 GB, v budoucnu je nemůžete vyměnit za větší ani doplnit další disky do zbývajících šesti pozic. Záruka je 3 roky, je možno dokoupit na 4–5 let, víc ale ne.

Distributor prezentuje pole jako "Zapoj a pracuj". Tedy dle manuálu na 2 strany formátu A4 se prý pole během půl hodinky zprovozní. Krásná pohádka, které jsem zprvu věřil (proč ne?). Nakonec ale došlo k tomu, že jsem musel procházet několik manuálů, než jsem byl schopen vůbec něco dělat. Tedy zprovoznění pro neznalého je třeba počítat spíš na dny (když to trochu přeženu).

Nejlepší lahůdka je ovládací software, bez kterého nezmůžete vůbec nic. Instalace se spustí v japonštině a jen sem tam se objeví nějaké slovíčko v angličtině. Z instalace není vůbec jasné, jaké parametry (IP adresu) mám zadat, když jsem vyzván. Pokud zadáte chybnou IP adresu (správně se musí dát IP adr. PC, na který se sw instaluje), sw vůbec nefunguje a ani instalace nedoběhne do konce. Když se tedy instalace správně podaří, počítejte, že vám ubyde na disku nějakých 1,5 GB (ano, skutečně Gigabajtů!). SW pracuje pod javou verze 1.4, tak už raději vůbec nepřemýšlím, jaké bezpečnostní díry mi sw do PC udělá.

Rychlost a odezvy ovládacího sw jsou šokující: na notebooku s Windows XP s dvoujádrovým pentiem a 2 GB RAM jsou odezvy v těch nejlepších případech jednotky sekund, to je ale spíše výjimka. Pro běžné operace spíš desítky sekund a pro mnohé několik minut! Jinými slovy: normálně se s tím nedá pracovat (nutno objektivně dodat, že se sw jsem musel pracovat hodně díky tomu, že jsem zkoušel všechny možné vlastnosti zařízení; v běžném nasazení se dá předpokládat, že se vše jednou nastaví a pak už se sw nemusíme prakticky vůbec dělat).

Měl bych se zmínit o výkonnosti, tu ale nemůžu příliš objetivně posoudit, neboť při praktickém testování jsem objevil více slabin v naší síti a rychlost, kterou jsem ze SMS 100 dostal, byla mnohem horší, než je zařízení jistě schopné dosahovat. Syntetické testy ukazovaly slušné hodnoty. Další info o výkonnosti viz Infortrend níže.

Podtrženo a shrnuto: Hitachi SMS 100 je zařízení, které mě již při koupi omezí tím, že je nemohu v budoucnu rozšířit. Pokud je pořídím, nemohu je umístit ani v uzavřené serverovně díky hluku, který vydává. Na to by byla nutná serverovna někde ve sklepě, kde by hluk nikoho neobtěžoval. Ovládací sw mi neskutečně zaseká PC (běží spoustu služeb, možné bezpečnostní díry) a je neskutečně pomalý – nejspíš by to chtělo vyčlenit pro to nějaký samostatný hodně výkonný počítač. Pro hovoří snad jen jméno výrobce a rozumná cena, která je ovšem srovnatelná s konkurencí. Co s takovým zařízením? Děkuji, nechci.

Díky ochotě (a snaze prodat) mi firma Agora sama nabídla k testování další SAN zařízení z jejich nabídky od tajwanské firmy Infortrend. Při srovnání s HITACHI výše se jedná rozměrově o skromnější zařízení výšky 2U, šířky 446 mm a hlouby 490 mm (bez držadel). Co se týká hlučnosti, je Infortrend srovnatelný s kdejakým PC, tedy víceméně tichý.

Ke správě pole slouží grafická ulitita RAIDWatch manager dostupná jak pro Windows, tak pro linux. Její instalace byla na rozdíl od Hitachi velmi snadná a rychlá, a to i při samotném konfigurování. V krabici mimo CDčka se sw je také brožurka o 2 listech A4, kde je dobře popsáno, jak se připojit přiloženým seriovým kabelem přes terminál a nastavit IP adresy.

Infortrend je dostupný přes iSCSI protokol tak jako Hitachi přes 2 gigabitové ethernet porty (bez možnosti load-balancingu), taktéž má 2 zdroje napájení. Zapůjčená sestava obsahovala pouze 2 SATA II disky Seagate 750 GB, což mi k testování stačilo. V této konfiguraci bylo možno disky sestavit jako NonRAID, RAID-0 a RAID-1. Při osazení více disků pole podporuje RAID 0, 1 (0+1), 3, 5, 10, 30, 50 a NonRAID, možnost RAID-6 tedy chybí.

Hodně času jsem strávil testováním výkonnosti obdobně jako s polem Hitachi. Zde se vyjasnilo, že problémy, jak jsem uváděl u Hitachi výše, nebyly jen v naší síti, ale též v samotném Hitachi poli. Abych byl konkrétnější, tak jsem z desítek měření sestavil alespoň trochu přehlednou souhrnnou tabulku. Z ní lze vyvodit několik závěrů:

•	Hitachi je skoro vždy o dost slabší než Infortrend, mělo by být vyrovnané (Hitachi zapojení RAID-6, Infortrend RAID-1, rychlost pole a disků ale není limitující!)
•	mírné rychlostní rozdíly jsou i v typu připojení, nejpomalejší je Edimax, pak Intel a nakonec Qlogic HBA – neplatí to ale vždy
•	o něco horší výsledky dosahuje sw initiator na linuxu při síťových přenosech protokolem SMB/CIFS
•	proč rychlost mezi dvěma Win-PC dosahuje jen zhruba poloviční rychlosti než je dosahovaná rychlost mezi lokálními disky jednoho Win-PC? (pro vyloučení vlivů měřeno také mezi dvěma PC propojenými kříženým kabelem s minimem běžících služeb; teoretická režie protokolu SMB/CIFS by měla být kolem 10%)
•	zápis na interní RAID-5 pole linuxového stroje vysdíleného sambou je zoufale pomalý, opět to ale není způsobeno pomalostí diskového subsystému – proč?
•	přenosy protokolem SMB/CIFS jsou mnohem pomalejší než lokální přenosy přes iSCSI protokol (a obdobně pomalé jako SMB/CIFS byly i přenosy NFS, ftp, rsync, scp)
•	pro úplnost uvádím testy rychlosti zápisu na pásku LTO2 příkazem dump: Hitachi 1,7 MB/s až 2,5 MB/s, Infortrend 21,7 MB/s, lokální RAID-5 pole 22,2 MB/s. Rychlost obnovy z pásky příkazem restore na Hitachi 11,1 MB/s, na Infortrend 22,04 MB/s a na lokální RAID-5 pole 21,0 MB/s. Výsledek Hitachi je katastrofální, Infortrend i lokální pole dosahuje limitní rychlosti pásky a nebrzdí ji.

Infortrend je jednoduché (v tom dobrém slova smyslu) zařízení, jehož správa je snadná a bezproblémová. Výkonnost je na rozdíl od Hitachi limitována pouze rychlostí disků, rychlostní problémy jsou ale se síťovými protokoly SMB/CIFS (a také NFS, ftp aj.). Tyto problémy nejsou jen u Hitachi či Infortrendu, ale projevují se jak na sambou sdílených discích, tak i na sdílených discích u strojů s Windows.

Jelikož mám velmi špatné zkušenosti s řešením čehokoliv se společností Telefónica O2 (stejně tak jako s jejími předchůdci Českým Telecomem a spol. s ručením mizerným), přijal jsem s hrůzou informaci od manželky ohledně „výhodné“ nabídky O2.

Nastala jedna z mála pravděpodobných situací, kdy manželka byla doma a já v práci a jak na potvoru doma zvoní telefon. Manželka zvedla telefon, vyslechla si něco v tom smyslu, že je pro nás výhodné přejít na balíček O2 Trio (výhodné to samozřejmě nebylo ani náhodou, nehledě na to, že takovou službu nechci, nepotřebuji a nikdy nepoužiji) a že nám posílají poštou nějaký modem. V podstatě nebyla ani dotázána, zda něco takového chceme. Byla zkrátka postavena před hotovou věc a basta. Než se stačila vzpamatovat, byl hovor u konce.

Nutno podotknout, že máme službu home mini s internetem a telefonování přes tuto službu zásadně nerealizujeme. Telefonát přišel v době letní pohody na přelomu července a srpna. Telefonní linka je psaná na mě, ne na manželku.

Moje drahá choť mi vzápětí volala a vše mi vylíčila. Hned mi bylo jasné, do jakého vleklého popotahování jsme se dostali. Vyčkal jsem asi půl hodiny, jednak abych se psychicky připravil a také abych dal soudruhům z O2 čas k synchronizaci jejich bezesporu skvělého informačního systému. U O2 je skvělé, že nemáte jinou možnost, než volat na univerzální číslo 800 123 456 a nemáte žádnou možnost řešit jeden problém s jedním konkrétním opočlověkem. Také se musíte proťukat a proposlouchat přes několik voleb, než se vám podaří (často ovšem ne hned na poprvé) dostat se na oporátora. K našemu potěšení se provolby často mění, abychom se náhodou nenaučili jednu správnou sekvenci, kterou bychom mohli příště již pohotově použít.

Pokud se vám tedy podaří se dostat provolbami tam, kam potřebujete, dostanete se obvykle na čekačku - posledně minulý týden jsem takto rozjímal s bublajícím kyslíkem 45 minut. Ale zpět k problému: dovolal jsem se tedy na oporátora, kterému jsem se snažil vylíčit situaci. Ten juknul do systému a oznámil mi, že tam nemáme žádnou žádost na změnu služby. Na můj dotaz, zda je možné, že v systému ještě nemá zaneseno to, co bylo řešeno s manželkou, mi odvětil, že to možné je, že se to tam může objevit třeba až druhý den. Důrazně jsem tedy požádal, že žádnou změnu nechci a ať dá do systému poznámku v tomto smyslu.

Ovšem už dopředu mi bylo jasné, že to je marné. Po pár dnech jsme měli na poště k vyzvednutí zásilku od O2. Vyzvednutí jsme úspěšně ignorovali a já již očekával, jaké překvapení mě bude čekat při obdržení měsíčního vyúčtování. Zklamán jsem nebyl. Naúčtovali nám nejen službu, kterou jsme nechtěli a nepoužívali, ale i jejich režijní náklady za poslání modemu, který jsem ani neviděl.

Následovalo další cvičení nervů při vytáčení 800 123 456 a hledání správné provolby na řešení reklamace s oporátorem. Kuriózní je, že pokaždé po mě chtějí, abych zadal telefonní číslo, kterého se reklamace týká a když toto poctivě naťukám a spojím se s oporátorem, jsem dotázán na telefonní číslo, kterého se reklamace týká. Nakonec se mi podařilo vše vysvětlit a reklamace byla uznána s upozorněním, že její vyřízení bude ze zákona trvat přibližně měsíc. Jako obvykle se mě zeptají na číslo mobilního telefonu, aby mi mohli podat zprávu o vyřízení reklamace pomocí SMS (to číslo mobilu taky chtějí pokaždé).

29. 9. 2008 mi došla SMS, že reklamace je opravena a přeplatek 100 Kč mi odečtou v nejbližším možném účtu. Byl jsem zvědav, co mě čeká a o překvapení jsem nepřišel. Vyúčtování přišlo celkem opožděně a nějakých 100 Kč mi sice odečetli, ale navíc naúčtovali asi 2000 Kč. Nechtějte po mně, abych vám popsal, za co. Měli tam několik dní něco za ADSL internet 2 Mb/s, něco za 4 Mb/s apod., zkrátka zmatek nad zmatek. Podotýkám, že jsem měl do té doby službu 4 Mb/s.

Následoval další pokus o spojení s oporátorem na 800 123 456. Byl jsem upozorněn, že doba čekání na něho je více než 5 minut. Jejich informace by mohla být trošku přesněji specifikována, jelikož jsem čekal 45 minut. Již trochu podrážděně jsem opět vysvětloval celou situaci. Opočlověka na druhém konci drátu to příliš nevzrušovalo a tak mě asi chtěl trochu podráždit, když na mě vyrukoval s tím, že k té službě jsme nějak přijít museli (rozuměj: jste si to objednali) a jestli nám ta reklamace vůbec byla uznána. To už jsem se neudržel a pana chytrého pěkně seřval. Najednou byl samá ochota, zjistil, že reklamace uznána byla a že ji tedy znova reklamuje. Bohužel si myslím, že mé snahy, aby situaci pochopil a uvedl službu do stavu před osudným letním telefonátem, přijdou zase v niveč. Opočlověk se ani nesnažil pochopit, v čem je problém, co na fakturách je či není či co má být, prostě mi sdělil, že to předá na fakturaci nebo reklamaci nebo kam a ti to vyřídí. Neopomněl dodat, že na vyřízení reklamace mají ze zákona 30 kalendářních dnů a abych mu sdělil číslo mobilního telefonu, kam mi pošlou vyrozumění.

Tak teď bezmocně čekám, co najdu za cca 2–3 týdny na vyúčtování. A to už je nyní čtvrt roku od osudné telefonní informace, že posílají modem zdarma k výhodné službě O2 Trio. Včera jsem si měřil rychlost připojení, jedu teď na 2 Mb/s.

Aby toho nebylo málo, vsunula se nám na začátek září ještě jedna porucha. U nás ve městě kopali kanalizaci a nejspíš překopli kabel (práce probíhali zrovna před budovou místního domku Telefóniky). Ohlásil jsem tedy telefonicky reklamaci, že nejde telefon ani internet. Zeptal jsem se také, zda mohu očekávat nějakou kompenzaci za dobu nefunkčnosti (nestudoval jsem smluvní podmínky, není to pro mě ani kritické). V odpověď se mi dostalo, že na opravu mají 48 hodin. Za asi 40 hodin přišla SMSka (na můj mobil, jehož číslo jsem jim musel opět nahlásit), že porucha byla odstraněna.

Ano, internet již fungoval, ale telefonní linka (kterou nepoužívám, ale to je vedlejší) byla stále hluchá. Opět volám 800 123 456 a hlásím jim situaci. Jelikož v systému mají reklamaci již vyřízenou, zadávají tedy novou reklamaci. Zprovoznění linky trvalo celkem 3 dny, ale O2 plán splnil do 48 hodin, protože vlastně vyřešil 2 reklamace během 3 dnů.

Možná se ptáte, proč se musím nervovat a proč stále služby Telefóniky využívám. Odpověď je v celku jednoduchá. Na malém městě, kde bydlím, není kromě drahého pomalého nespolehlivého bezdrátu jiná možnost. Jo, a taky jedna pozitivní věc na O2: pokud něco funguje a nešťourá se do toho, tak to obvykle funguje dobře.

Mám jedno zbožné přání: rád bych sem napsal, jak mi v příštím vyúčtování dala Telefónica vše do pořádku. Nic víc a nic míň.

Dnes je 26. 11. 08 a doplňuji pár informací. 3. listopadu jsem dostal doporučeně dopis s dobropisem a omluvným dopisem. Po úhradě vyúčtování přes SIPO mi mají přeplatek vrátit poštovní poukázkou, tak už se nemůžu dočkat, kdy přijde. Mezitím jsem netrpělivě čekal na vyúčtování za další období 11. 10. – 10. 11. 08. Doklad, vystavený 19. 11. 08, jsem dostal do schránky 24. 11. 08. Bohužel vyúčtování je opět zamotané – účtování je rozděleno na část za ADSL 2048 a část za ADSL 8M. Pravda je, že poslední měření rychlosti ukazovalo nějakých 5400 kb/s. Jelikož se zdá, že od dalšího účtovacího období už by se mohlo všechno srovnat a vrátit do normálu, raději vyčkám a nebudu do toho zbytečně šťourat.

V práci jsem byl nucen také zasáhnout do zaběhnutého stavu a na pobočce změnit službu připojení ADSL a také službu telefonní na IP telefonii. Bohužel ani v tomto případě nešlo vše, jak by mělo. Hned po žádosti v půli října změnili službu ADSL na podstatně levnější, ale ve vyúčtování na to nějak zapomněli a nejenže účtovali celý měsíc původní sazbu, ale navíc od změny služby začali účtovat i Zvýšenou servisní podporu ADSL 2. Že něco takového existuje jsem zjistil až z faktury. Přechod na IP telefonii se zhruba předpokládal od 1. 11. 08 (bez záruky, mají toho prý moc). Ovšem 30. 10. 08 jsem byl upozorněn, že žádosti, které jsem vyplnil, jsou na jinou firmu, než na kterou je vedená telefonní linka. Celý problém byl v tom, že jsme před lety změnili název firmy (IČO, sídlo a ostatní náležitosti zůstaly nezměněny). Takže po trochu nesmyslném dohadování (chtěli uzavřít smlouvu na původní firmu, která neexistuje) jsme museli vyplnit další formulář Převod účastnictví. Ten byl předán pracovnicí O2 k realizaci 31. 10. 08. Služba stále není zprovozněná.

Musím dodat, že na rozdíl od nedávné minulosti, kdy ani jako firemní zákazník jsme nemohli řešit různé požadavky s konkrétní osobou Telefóniky, se toto alespoň částečně změnilo k lepšímu. Mám telefon a mail na konkrétní pracovnici, se kterou jsem řešil výše uvedené záležitosti. Ovšem v případě, že jsem chtěl u ní reklamovat chybné rozúčtování a fakturaci neobjednané služby, dostal jsem jasný pokyn: ohledně vyúčtování kontaktujte linku 800 203 203 a podejte reklamaci.

19. 12. 08 doplňuji: Složenka na vrácení peněz za přeplatek na domácí lince pořád nikde, tak jsem volal na O2 koncem listopadu. Tam mi s klidem sdělili, že mi složenku pošlou s příštím vyúčtováním (tj. někdy kolem vánoc, přitom jsem přeplatek přes SIPO uhradil 15. 11. 08). Samozřejmě jsem dal najevo svou nelibost a nakonec jsem složenku na peníze dostal poštou 10. 12. 08.

Na firemní lince se událo toto: Telefonicky jsem podal reklamaci. Přišel mi dobropis a později mi pracovnice O2 volala, že bohužel i příští faktura bude ještě špatně, jejich systém zkrátka neumí reagovat rychleji, ale zase následně pošlou dobropis. Na pevné lince, kde jsme si v půli října zažádali o převod na službu IP telefonie, se zatím neudálo nic ani přes jednu telefonickou urgenci.

7. 1. 09 mi volal pracovník O2 a nabídl mi termín instalace služby IP telefonie na 14. 1. 09 mezi 12 a 14 hodinou. Jelikož se jedná o lokalitu v Praze a já tam kvůli tomu raději pojedu (z Brna), požádal jsem o dopolední termín a ten mi pak po konzultaci s technikem byl potvrzen kolem 10 hodiny (tedy v rozmezí 10 až 12). 14. 1. 09 v 10:20 mi volal technik O2, že mají přijít. Potvrdil jsem, že jsou již očekáváni. Prý konfigurují nově došlé brány, tak přijdou kolem 11 hodiny. Další telefonát přišel po půl dvanácté, že se omlouvají, ale mají s konfigurací problémy a ještě se zdrží. Nakonec dorazil technik s druhým člověkem kolem 13:30. Druhý člověk skoro nepromluvil a vůbec nic nedělal. Během zprovozňování služby vyšlo najevo, že nová služba bude mít nové telefonní číslo a původní telefonní číslo zůstane. Jelikož jsme měli zažádáno o přenesení čísla na novou službu a protože máme jen jeden telefonní přístroj, mohli jsme buď přístroj nechat zapojený na původní lince s původním číslem, technik by zprovoznil novou službu a na ní by nebyl žádný telefon. Technik by vykázal, že své má splněno a já ať si pak s obchodníkem dořeším převod čísla. Obdobně jsme mohli telef. přístroj zapojit k nové službě s novým číslem a původní číslo by bylo nedostupné.

Následoval telefonát na obchodníka, jehož způsob jednání nebyl zrovna vstřícný. Tedy paní se snažila dělat, že papíry k tomu už u sebe nemá, že to je z října, a že je to určitě tak, jak jsme chtěli. Jelikož jsem měl papíry před sebou a přečetl jsem, kde přesně je výslovně uveden text o převodu čísla, najednou paní měla papíry před sebou a dala mi za pravdu. Bohužel mi už nebyla schopna říct nic víc, tedy co mám dál dělat. S technikem se bavit nechtěla (a technik s ní také ne), přesto jsem telefon předal technikovi. Technik řekl, že plní požadavek, jak byl zadán, a že tedy asi byl požadavek zadán špatně. Technik mi pak ještě nabídl variantu, že vše zase odnese, úkol tak bude trvat a já si to dohodnu následně s obchodníkem. S tím jsem souhlasil a tak jsme se po asi půl hodině rozloučili.

Vzhledem k neustálým nedorozuměním, z důvodu dlouhého čekání a také proto, že nová služba nám výrazně nic nepřinese (chtěli jsme to hlavně vyzkoušet s tím, že náklady na zřízení jsou nulové a na provoz budou vycházet přibližně stejně jako doposud), následující den jsem se s obchodníkem dohodl, že již službu nechceme. Poučení pro příště: když nemusíš, tak do toho nešťourej.

Doufám, že se Petr Krčmář nebude zlobit, že jsem si vypůjčil jeho název článku Greylisting aneb kladivo na spam z 3.8.2006, který nic neztrácí na aktuálnosti a který mi také pomohl s nasazením této technologie u nás ve firmě. V době vzniku, kdy jsem článek četl, mi přišel greylisting jako celkem zajímavá možnost, ale neměl jsem odvahu to rozjet. Důvod byl hlavně ten, že jsem měl strach, jak budou všechny maily chodit s velkým zpožděním a jak mě uživatelé budou kamenovat. Tomu nasvědčovaly i názory a zkušenosti systémáků v diskusích.

Minulý týden jsem narazil na další zajímavý článek SPAM - greylisting ve firmě od Ondřeje Valouška. Článek byl pěkně napsaný a diskuse pod ním na věcné a odborné úrovni, což nebývá vždy zvykem. V ní mě zaujala myšlenka dát celou doménu .cz na whitelist, což jsem také při rozjíždění udělal (a přidal i doménu .sk). Důvodem je to, že z těchto domén chodí minimum (ne-li žádný) spamu. Naopak z těchto domén pro naše uživatele chodí odhadem přibližně 99% pošty.

Jelikož již dlouhá léta používám Sendmail, byl pro mě vodítkem i odkaz na démona milter-greylist, který je opravdu skvělý, jak uvádí autor. Po přečtení článku a diskuse jsem dlouho neváhal a dal se do nasazování. Večer ten samý den již byl greylisting spuštěn v ostrém provozu pro celou firmu.

Na domovské stránce démona milter-greylist jsem si přečetl možnosti konfigurování a byl nadšen. Jen heslovitě uvádím některé funkce, které mě zaujaly:

• možno nastavit individuálně každému uživateli
• možno nastavit whitelisty dle odesílatele, IP adresy, domény...
• stejně tak možno nastavit blacklisty i greylisty
• auto-whitelisting - pokud je již zpráva akceptována, dá se odesílatel do whitelistu na stanovenou dobu

Jinými slovy – program má široké možnosti konfigurace. Dokumentace, jak bývá u linuxových programů zvykem, je dobrá, a tak jsem začal dle README. Vytvořil jsem ze zdrojáků rpm balíčky příkazem:
rpmbuild --define "build_user smmsp" -tb milter-greylist-4.0.1.tgz
Balíčky se uložily do /usr/src/redhat/RPMS/i386 a odtud instalováno:
rpm -Uvh milter-greylist-*
Při instalaci napsalo, že pro povolení máme dopsat do /etc/mail/sendmail.mc řádek:
FEATURE(`milter-greylist')dnl
Zde vznikl menší zádrhel. Nejdřív greylisting nechodil, protože jsem výše uvedný řádek umístil příliš vysoko. Bylo třeba ho dát až téměř na konec před řádek
MAILER(smtp)dnl
Pak je samozřejmě nutné makro soubor převést na soubor /etc/mail/sendmail.cf spuštěním
make -C /etc/mail
Pracuji s distribucí CentOS 4.7. Následovala úprava konfiguračního souboru /etc/mail/greylist.conf. V něm byla na ř. 10 chyba:
dumpfile "/var/milter-greylist/grelist.db" 755, musel jsem odmazat 755, jinak se nerozjelo. K ladění konfiguráku je dobré spustit příkaz
milter-greylist -c

Uplynul více než týden a tak přináším statistiku greylistingu za posledních 7 dnů:

Jak jsem již uváděl výše, maily přicházející přes smtp servery v doménách .cz a .sk zde nejsou zahrnuty, ty prošly přímo. Na bráně mám ještě před greylistem předřazenou kontrolu na DSBL blacklist. Všechny maily, co projdou, jdou dále na vnitřní server, kde jsou kontrolovány ještě na viry – milter ClamAV, a nakonec na spam – Spamassassinem. Z dlouhodobé zkušenosti mám nastaveno, že zprávy hodnocené známkou 5 (příp. 6) jsou označené jako spamy a doručené uživateli pro kontrolu, zprávy s hodnocením 10 a více jsou rovnou mazány.

Přestože před nasazením greylistingu nebyl objem doručovaných spamů příliš velký - dle uživatele 0 až cca 10 denně, byla zátěž linky i serverů mnohonásobně vyšší než po nasazení greylistingu. Navíc po jeho nasazení je objem doručených spamů prakticky nulový (80 spamů za týden dělá průměrně denně 1 spam na 5 uživatelů). Denně tak greylisting v průměru vyřeší problém s 5000 spamy, a to prakticky zadarmo – zprávy nejsou vůbec na server doručeny.

Po více než měsíci od nasazení (26. 11. 08) je účinnost greylistingu stále stejně velmi dobrá. Došlo pouze k tomu, že do firmy chodí podstatně méně spamu. Za poslední týden klesl celkový počet zpráv na 10599, z čehož doručených zpožděných bylo 197 (z toho asi 133 spamů) a zbytek, tj. 10402, byl zachycený spam.

Jen krátká poznámka ohledně pokrytí signálem mobilního operátora T-Mobile. Nedávno jsem po dlouhé době opět usedl do vlaku a vyzkoušel si cestování s ČD. Jízda mezi Brnem a Prahou je totiž po dálnici v poslední době katastrofická. Autem jsem nucen jet, pokud přepravuji větší náklad (obvykle při cestě na pobočku – vezu PC apod.). Jízda je o nervy. Pokud jedu na nějaký seminář, volil jsem jízdu autobusem se Student Agency. Cestování s nimi mi možná trochu zevšednělo, nebo spíš úroveň cestování klesá (někdy nefungují u určitého sedadla sluchátka apod., je zkrátka vidět, že vybavení stárne). Každopádně cesta trvá vždy alespoň 3 hodiny.

Pro cestu vlakem jsem volil to nejrychlejší možné spojení. Bohužel Pendolino jezdí jen 2x denně a v ne zcela vyhovující dobu. Doba jízdy Pendolina je velmi přijatelných přibližně 2,5 hodiny, expresu to trvá jen asi o 10 minut déle. Zpoždění je do 5 minut. Úroveň cestování (pomineme-li Pendolino) je mírně lepší než před deseti a více lety. Cena, na této trase zvýhodněná, činila při zakoupení jízdenky předem 175 Kč (u Pendolina navíc povinně +200 Kč za místenku), což je velmi příjemné. Cestu vlakem tedy mohu doporučit. Pozor si dejte při koupi jízdenek. Orientovat se, za kolik a kdy a jak jízdenky koupit je na vysokou školu. V době říjen – listopad např. paradoxně koupě přes internet nebo telefonicky vyšla dráž než u pokladny. Taky jsem nevěděl, že cena 175 Kč je platná jen při koupi nejméně den dopředu, v den jízdy mi nabídli snad jakousi síťovou jízdenku za 440 Kč do Prahy a zpět (tedy jedna jízda za 220 Kč).

Zajímavé ovšem je, že pokrytí signálem mobilního operátora T-Mobile (nevím, jak je to u ostatních) bylo velmi špatné. Na trase Praha – Pardubice – Česká Třebová – Brno jsem se prakticky až do Pardubic nemohl dovolat – buď nebyl signál, nebo vypadával. V Pardubicích při zastávce na nádraží jsem se konečně dovolal a rychle domluvil, dále už jsem to nezkoušel, jen jsem na svém mobilu občas sledoval, jak signál klesá a vypadává. Řekl bych, že na této trase by mělo být zcela samozřejmé vyřizovat nejen mobilní telefonáty, ale také možnost pracovat s mobilním internetem. S pokrytím na D1 se to bohužel nedá srovnávat a je to dle mého obrovský handicap.

For a long time I use Samba Recycle bin which is equivalent to windows recycle bin but for network shares. Configuration is pretty simple except excluding directories. Google did not give me single correct answer so I had to investigate it myself. Right solution for linux CentOS 5.3 is here:
recycle:exclude_dir = tmp temp cache
It is important to use underscore in exclude_dir and separate list of directories by spaces (do not use any leading or trailing slash, comma or semi-colon).
This is my share:

[VOL1]	
   comment = Prvni disk
   hide files = /odpadky/
   browseable = no
   writable = yes
   printable = no
   path = /samba1/664
   guest ok = no
   create mode = 0664
   directory mode = 6775
   security mask = 0000
   directory security mask = 0000
   inherit permissions = yes
   nt acl support = no
   vfs object = recycle
                 recycle:repository = odpadky/%U
                 recycle:keeptree = Yes
                 recycle:touch = No
                 recycle:versions = Yes
                 recycle:maxsize = 0
                 recycle:exclude = *.tmp *.temp *.bak *.dwl ~$*.* *.~*
                 recycle:exclude_dir = tmp temp cache BW
   # end of share

Due to samba permission before you start create directory odpadky in root share (here /samba1/664) with permissions
root root drwxr-xrwt (sticky bit).

Examples of INCORRECT definitions follow below:

#                 recycle:exclude = *.tmp *.temp *.TMP *.TEMP ~$*.* *.~?? *.dwl *.bak
#                 recycle:exclude = *.tmp|*.temp|*.TMP|*.TEMP|~$*.*|*.~??|*.dwl|*.bak
#                 recycle:noversions = *.doc|*.xls|*.ppt
This is also wrong:  *.~??
but this is correct: *.~*

I clean daily (set in cron) all files and non-empty dirs which have been moved to recycle bin more than seven days ago with this bash script:

#! /bin/bash
CESTA='/samba1/664/odpadky /samba2/660/odpadky /samba3/660/odpadky /var/www/odpadky'
for i in $CESTA; do
    touch $CESTA; # preserve recycle bins from deleting
    cd $i;
    find . -type f -ctime +7 -print0 | xargs -0 --no-run-if-empty rm;
    find . -type d -ctime +7 -print0 | xargs -0 --no-run-if-empty \
     rmdir --ignore-fail-on-non-empty;
done

Ve firmě jsem se rozhodl implementovat DKIM. Důvody byly nasnadě: samotná implementace i provoz jsou nenáročné a firmě to může zvýšit důvěryhodnost odeslaných mailů, resp. snížit pravděpodobnost, že někde spadnou mezi spamy. Nasazení DKIM také umožní ověření podpisu došlých podepsaných mailů, což zase zvýší šanci odesílatelům, že jejich maily neskončí ve spamovém koši. O to se u nás stará spamassassin, který korektně ověřené zprávy s DKIM podpisem zvýhodňuje (spamassassin nebylo nutné nijak upravovat, má to implementováno defaultně).

Nasazení ovšem ukázalo především 3 problémy.

•	Došlých zpráv, používajících DKIM podpis, chodí minimum. Statistika za poslední pracovní týden: pouze 2,2% došlých zpráv má DKIM podpis.
•	U velkého množství zpráv s DKIM podpisem je podpis vyhodnocen špatně, tedy s největší pravděpodobností byla zpráva cestou modifikována. Statistika za poslední pracovní týden: ověření došlých zpráv s DKIM podpisem selhalo u 28,3% zpráv.
•	MS Outlook 2000 a MS Outlook XP v mnoha případech zapříčiňuje, že zpráva se již při odeslání podepíše chybně. O tom více dále.

Při implementaci jsem postupoval dle velmi dobrého článku DKIM – podepisujeme e-maily na serveru a také dle diskuse pod ním. Nebudu tedy opakovat celý postup, zmíním jen některé rozdíly. Jelikož místo Postfixu používáme Sendmail, skoro na konec souboru sendmail.mc bylo nutno doplnit:
INPUT_MAIL_FILTER(`dkim', `S=local:/var/run/dkim-milter/dkim-milter.sock')dnl
define(`confINPUT_MAIL_FILTERS', `dkim')
Následuje přegenerování sendmail.cf a restart sendmailu. Dále jsem musel vytvořit soubor InternalHosts, který obsahuje domény či IP adresy. Tím rozlišíme maily odcházející z firmy, aby je DKIM podepisoval (jinak by je kontroloval jako ostatní příchozí maily). Nakonec jsem ještě provedl některé další úpravy v souboru dkim-filter.conf, zmíním např.
Canonicalization Relaxed/Relaxed
To by mělo zvýšit šanci, že integrita zprávy bude při doručení v pořádku a podpis bude platný.

Za zmínku možná ještě stojí to, jak řeším podepisování více domén a ještě přes dva servery. Používám pouze jeden klíč, který je nahraný na obou serverech a jeho veřejná část je v záznamu u každé domény, kterou podepisuji. Soubor dkim-filter.conf pak obsahuje řádky
Domain mojeprvnidomena.cz,mojedruhadomena.cz
KeyFile cesta/k/souboru/s/privatnim/klicem

Celkově není možno odeslat z naší domény mail, který by neměl DKIM podpis, neboť odesílat lze jen z centrály přes první server, z pobočky přes druhý server anebo přes VPN opět ovšem přes první server. Z toho plyne, že pokud nějaký mail není podepsaný, nešel přes naše servery a je to podvrh, resp. mail není důvěryhodný. To ovšem příjemce nerozpozná. Příjemce, pokud používá také DKIM, pouze ověří, pokud má příchozí mail DKIM podpis, zda je podpis v pořádku, tedy zda cestou zpráva nebyla pozměněna. A zde je kámen úrazu celého systému DKIM.

Jak uvádím výše, víc než 1/4 mailů s DKIM podpisem je při přepravě modifikována. Změna je způsobena ani ne tak zákeřným útočníkem, jako spíš přepravními servery, které nekorektně modifikují hlavičku zprávy a tomu se nedá zabránit.

Další zajímavou příčinou poškození integrity je odesílající klient. Dost jsem se natrápil, než jsem přišel na zajímavou příčinu poškození podpisu DKIM hned při odeslání z MS outlooku 2000/XP. Problém vzniká s neASCII znaky ve jménu adresáta. Uvedu příklad: v kontaktech je uživatel Marek Jedlička s emailem mjedlicka@seznam.cz. Po odeslání mailu tomuto uživateli je v hlavičce zprávy

To: "=?iso-8859-2?Q?Marek_Jedli=E8ka_\=28el._adresa\=29?=" <mjedlicka@seznam.cz>

(pokud uživatele v kontaktech nemám, napíšu adresu ručně a v hlavičce zprávy bude

To: <mjedlicka@seznam.cz>

a k problému s integritou nedochází). Celý problém spočívá v uvozovkách, které jsou doplněny až po DKIM podpisu (nebo se DKIM podpis spočítá bez uvozovek?). Pokud tedy uvozovky ručně odmažu a provedu kontrolu integrity, je zpráva ověřena. Ruční odmazání ovšem mohu provést jen při zachycení zprávy. Běžně tedy naprostá většina zpráv odcházejících od nás s DKIM podpisem již odchází jako modifikovaná (neboť používáme MS outlook 2000), takže příjemce obdrží zprávu s poškozenou integritou DKIM podpisu (prakticky tedy jakoby bez DKIM podpisu). Nenarazil jsem nikde na tento problém (a tedy ani na jeho možné řešení). Rušit diakritiku u všech jmen v adresáři se mi nejeví jako to pravé ořechové a kromě změny poštovního klienta mě jiné řešení nenapadá (MS outlook 2003 se již chová korektně, stejně tak Mozilla SeaMonkey).

Závěrem ještě jednu poznámku. Jsem si vědom toho, že ne zcela přesně zacházím s pojmy neplatný podpis, integrita zprávy, hash zprávy atd. Doufám, že tím nezmátnu čtenáře, odborník snad chápe, jak to ve skutečnosti je a jak to tedy i já správně myslím.

After long investigating the procedure of implementing SRS (The Sender Rewriting Scheme) is quite simple:

•	yum install perl-Mail-SRS
•	download srs-socketmapd.0.31.tar.gz, extract two files to /usr/local/bin/socketmapd.0.31.pl and /usr/share/sendmail-cf/hack/socketmap.m4
•	create simple init script /etc/rc.d/init.d/SRS pointing to start /usr/local/bin/socketmapd.0.31.pl before sendmail
•	modify /etc/mail/sendmail.mc - insert just one line at last: HACK(socketmap)dnl and run make -C /etc/mail

Rozhodl jsem se, že se nabídnu přeložit zajímavý a užitečný program AxCrypt do češtiny. Cílem bylo přiblížit AxCrypt více uživatelům, kteří preferují český jazyk před anglickým. Mé rozhodnutí bylo svobodné (ostatně i program je nabízen pod svobodnou licencí) s tím, že z překladu budu mít dobrý pocit a žádný osobní prospěch.

Mailem jsem kontaktoval autora a 7. 9. 2012 jsem strávil první hodinu nad překladem. Obdržel jsem textový soubor, který obsahoval spousty textů v mnoha jazycích. Mnohdy nebylo vůbec snadné zjistit, v jakém kontextu se text nachází. Postup byl tedy takový, že jsem přeložil všechny anglické texty do češtiny a soubor poslal zpět autorovi. Ten s mými texty zkompiloval program a zaslal mi jeho beta verzi. Nyní jsem měl možnost si program nainstalovat i s volbou češtiny a zkoušet nasimulovat všechny hlášky (to se mi zdaleka nepovedlo; nasimulovat např. nějakou chybovou situaci mnohdy snad ani nejde). V mnoha případech se ukázalo, že překlad nebyl zcela adekvátní, takže jsem v textovém souboru provedl úpravy a poslal ho autorovi zase zpět. Toto se opakovalo ještě asi dvakrát. Musím říct, že překlad byl náročnější, než jsem čekal.

30. 9. 2012 jsem poslal autorovi finální verzi se žádostí o uvolnění. Na překladu jsem strávil celkem přibližně něco přes 10 hodin. Nová verze programu s podporou češtiny by měla být vydána každým dnem. Pokud k českému překladu budou jakékoliv připomínky, výhrady, náměty apod., můžou být zaslány na e-mail axcrypt.cz@gmail.com.

GoogleReader používám denně a proto se bez něj neobejdu. Čtu jen na PC a na notebooku, chci tedy webovou čtečku. Během 3 dní jsem souběžně pracoval s několika čtečkami a zde je můj komentář:

https://www.netvibes.com/ - zdá se přeplácané, nezkoušeno

https://www.commafeed.com - nezkoušeno

http://www.newsblur.com - při prvním pokusu zrovna údržba webu, free je trochu omezené, placené víc možností, nezkoušeno

http://www.feedspot.com - špatně se ovládá, nepřehledné

http://multiplx.com - importuje od rána 24. 6. 2013, 25. 6. 2013 jsem zkusil znova, chová se divně a pořád nic neobsahuje, 26. 6. 2013 v poledne pořád synchronizuje, už dále netestováno

Takže nakonec jsem srovnával a testoval tyto 4 čtečky:

http://theoldreader.com

• importuje od rána 24. 6. 2013, načetlo se odpoledne
• práce svižná, přehledné, pohodlné, možnost reloadu (Živě neměl poslední články a po reloadu se hned načetly)
• při zobrazení od nejstarších občas nejde rolovat dolů až k nejnovějším!
• při volbě zobrazit všechny články - zobrazí jen 6 dní zpět! (nedrží historii)
• Refresh načte nejnovější články
• design mi úplně nevyhovuje (úzké a schované posouvací svislé lišty)

Největší nedostatek: při kompaktním zobrazení když kliknu na titulek, rozbalí se náhled, ale všechny titulky nad ním se schovají a musím pak nesmyslně odrolovávat (v tomto případě je lepší zobrazovat od nejstarších a číst odshora); přesně stejně se chová inoreader (dále)

https://www.inoreader.com

• jeden ze tří nejpřehlednějších designem
• All Articles ukazuje (2), i když mám nepřečteno mnohem víc
• během testování 3x probíhala aktualizace a chvíli (řádově minuty) nepoužitelné
• zásadní nedostatek je odskok zpráv v kompaktním zobrazení při náhledu jedné zprávy (jako oldreader viz výše)
• při volbě zobrazit všechny články - zobrazí víc než měsíc zpět
• můžu mít v předplatných zdroje vypnuté, aniž bych je mazal (to asi neznal ani google reader)
• Refresh načte nejnovější články

http://www.g2reader.com

• jeden ze tří nejpřehlednějších designem
• bohužel dost zpráv se načítá i s několikahodinovým zpožděním, z tohoto pohledu je nespolehlivé
• ani Refresh NEnačte nejnovější články
• neukazuje správně počty nepřečtených zpráv
• při volbě zobrazit všechny články - zobrazí víc než měsíc zpět

http://cloud.feedly.com

• jeden ze tří nejpřehlednějších designem
• i když zpočátku jsem byl k němu skeptický, ukázal se jako jeden z nejlepších
• aktualizace zpráv asi nejspolehlivější (vždy aktuální načtené)
• má možnost měnit skiny, hodí se doladit si vhodné barvy

Takže závěr: pro mě nejlépe vyšly feedly, inoreader a g2reader. Nejvíc se mi asi líbí g2reader, ale kvůli neaktuálním aktualizacím bych volil inoreader, ale ten má zase nevhodné schovávání titulků, takže až třetí v řadě feedly asi budu používat. GoogleReader mi vyhovoval asi nejlíp (ale taky možná proto, že jsem už byl na něj zvyklý).
Napadá mě otázka: proč Google neprodal svůj Reader, když se ho zbavuje?

Although there is a lot of information about VLAN on internet I couldn't find simple explanation how VLANs work with Linux. So I write this procedure for CentOS 6 (be aware that VLANs configuration for CentOS 5 and other linux systems are different).

Suppose we have LAN with subnet 192.168.1.0/24, SERVER-A linux gateway 192.168.1.1 with iptables (two physical interfaces eth0, eth1) and SERVER-B linux dhcp server 192.168.1.2. We want to use VLAN-100 for some LAN clients. These clients are not allowed to browse LAN subnet, they are allowed to browse only internet. We have L2 switch supporting VLANs with default VLAN-1 (PVID-1). We have to set VLAN ports on this switch. Please modify ports for VLANs clients: type ACCESS, PVID-100; for SERVER-A and SERVER-B: type TRUNK, PVID-1, tagged member VLAN-100. For VLAN-100 we have to use different subnet (because of routing etc.), say 192.168.100.0/24. If we use the same subnet, VLAN will not work!

For configuring ethernet interfaces we use config files. It is also possible to use command ip (do not use deprecated command ifconfig!). Config files are in directory /etc/sysconfig/network-scripts/. Present config SERVER-A (gateway):

/etc/sysconfig/network-scripts/ifcfg-eth0:
DEVICE="eth0"
ONBOOT="yes"
HWADDR=00:0C:3F:64:37:D1
TYPE=Ethernet
BOOTPROTO=none
IPADDR=192.168.1.1
PREFIX=24
DEFROUTE=no
NAME="System eth0"

/etc/sysconfig/network-scripts/ifcfg-eth1:
DEVICE="eth1"
ONBOOT="yes"
HWADDR=00:0B:C9:9E:01:B7
TYPE=Ethernet
BOOTPROTO=none
IPADDR=XX.XX.XX.XX
PREFIX=27
GATEWAY=YY.YY.YY.YY
DNS1=8.8.8.8
DNS2=4.4.4.4
DEFROUTE=yes
NAME="System eth1"

Now we create new virtual interface with specific name for VLAN-100:

/etc/sysconfig/network-scripts/ifcfg-eth0.100:
DEVICE="eth0.100"
ONBOOT="yes"
BOOTPROTO=none
IPADDR=192.168.100.1
PREFIX=24
NAME="VLAN-100 eth0"
VLAN=yes

The same can be done by these commands:
ip link add link eth0 name eth0.100 type vlan id 100
ip addr add 192.168.100.1/24 brd + dev eth0.100
ip link set dev eth0.100 up

Start interface using command: ifup eth0.100

Allow forwarding to internet, deny to local network:
iptables -A FORWARD -i eth0.100 -o eth1 -j ACCEPT
iptables -A FORWARD -i eth0.100 -o eth0 -j DROP

Present config SERVER-B (dhcp server):

/etc/sysconfig/network-scripts/ifcfg-eth0:
DEVICE="eth0"
ONBOOT=yes
HWADDR=00:0B:38:85:B9:57
TYPE=Ethernet
BOOTPROTO=none
IPADDR=192.168.1.2
PREFIX=24
GATEWAY=192.168.1.1
DNS1=192.168.1.2
DNS2=192.168.1.1
DEFROUTE=yes
NAME="System eth0"

Now similarly as SERVER-A we have to create for SERVER-B new virtual interface for VLAN-100. I show two methods.
Method 1:

/etc/sysconfig/network-scripts/ifcfg-eth0.100:
DEVICE="eth0.100"
ONBOOT="yes"
BOOTPROTO=none
IPADDR=192.168.100.2
PREFIX=24
NAME="VLAN-100 eth0"
VLAN=yes

DHCP server will allocate IP addresses for both 192.168.1.0 and 192.168.100.0 subnets depending on VLAN (if frames are marked with VLAN-100 or not). With this method there will be log messages "wrong network" but otherwise works OK.

More clear is method 2 with no error messages but you need second ethernet interface:

/etc/sysconfig/network-scripts/ifcfg-eth1:
DEVICE="eth1"
ONBOOT="yes"
HWADDR=00:0D:2A:84:C9:4B
TYPE=Ethernet
BOOTPROTO=none
#IPADDR=no IP addr.!
NAME="System eth1"

/etc/sysconfig/network-scripts/ifcfg-eth1.100:
DEVICE="eth1.100"
ONBOOT="yes"
BOOTPROTO=none
IPADDR=192.168.100.2
PREFIX=24
GATEWAY=192.168.1.1
DNS1=192.168.1.2
DNS2=192.168.1.1
DEFROUTE=no
NAME="VLAN-100 eth1"
VLAN=yes

You must not set IP address for eth1. If you set IP address for eth1 from the same subnet as eth1.100, VLAN will not work correctly - dhcp server will not allocate addresses for VLAN subnet.

Addendum: You can create more VLAN interfaces on one physical interface. Simply create new file /etc/sysconfig/network-scripts/ifcfg-eth1.200 for VLAN-200 etc.
And there is also posibility to have more IP addresses on one physical interface. In our situation let's see this example: We want some PCs in our network separated from LAN subnet 192.168.1.0 and we do not want to use VLAN. We will use new subnet 192.168.2.0/24. Let's set static address for PC1 192.168.2.10, gw 192.168.2.1. Now create for SERVER-B this file:

/etc/sysconfig/network-scripts/ifcfg-eth0.01:
DEVICE="eth0"
IPADDR=192.168.2.1
PREFIX=24
NAME="System eth0 IP2"

Restart network: /etc/rc.d/init.d/network restart and create iptables rules as you need (allow or deny routing between 192.168.1.0 and 192.168.2.0 etc.). Remember that iptables work with interfaces eth0 and eth0.100 but not with eth0.01. Interface eth0.01 is just eth0. Use command ip addr show to see all your interfaces and IP addresses.

It is very simple on CentOS 7 to set more IP addresses on one physical interface. Everything you need is to edit configuration file for that interface. With CentOS 7 there is name convention change so in our example file name is /etc/sysconfig/network-scripts/ifcfg-ens32:

TYPE="Ethernet"
BOOTPROTO="none"
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
NAME="eth0"
UUID="abeafd35-75fe-3e47-bdd1-c19743c3ec8d"
ONBOOT="yes"
HWADDR="00:0C:29:18:79:BD"
IPADDR0="192.168.1.101"
PREFIX0="24"
GATEWAY0="192.168.1.1"
IPADDR1="192.168.1.201"
PREFIX1="24"
GATEWAY1="192.168.1.1"
DNS1="192.168.1.11"
DNS2="192.168.1.21"
DOMAIN="mydomain.cz"
IPV6_PEERDNS="yes"
IPV6_PEERROUTES="yes"

After changing config I recommend to restart server because restarting only network (systemctl restart network) does not work properly. Use command ip addr show to see all your interfaces and IP addresses.