Se změnou práce ke mně začaly proudit i nové vizitky a elektronické podpisy ze zemí, do kterých jsem zatím nepotřeboval volat. Teď ale občas koukám na telefonní číslo a přemýšlím, jestli to, co je v závorce, se ze zahraničí vytáčí nebo ne atd.
Mou záchranou je web http://www.howtocallabroad.com/. Dají se z něj zjistit zajímavé věci, třeba adresní plán Švédska, pokud si člověk zadá, že chce volat ze Švédska do Švédska. Když jsem to samé zkusil pro Českou republiku, dostal jsem následující:

Kdeže to Zeman objímá ty stromy? Na Wysočině?
Taktéž je historicky krapet chaos třeba u prefixů Středočeského kraje. Bydlím kousek od cedule Hlavní město Praha, pevná linka od TEF CZ začínala číslem 2. Když jsem ale přešel na VOIP u alternativního operátora, dostal jsem číslo začínající 31.
Zajímavý problém – jak rozšířit kapacitu iSCSI disku, který je založen na W2008R2 iSCSI Target serveru, když na tomto serveru není nainstalován Hyper-V Server? Nakonec jsem prošel těmito kroky:
- zastavit služby na serverech iSCSI iniciátorů, aby něco nelehlo natvrdo
- na iSCSI serveru zastavit službu WinTarget, neboli Microsoft iSCSI Software Target. Tento krok je nezbytně nutný, aby byly uvolněny VHD soubory, které představují konkrétní iSCSI disky.
- na nějakém Hyper-V Serveru (nejlépe takovém, který je na stejné gigabitové síti) si otevřít CMD jako admin a přimapovat si dočasně vzdálenou lokaci s VHD soubory, které přestavují iSCSI disky. Např. net use k: \\BackupServer\d$ /user:domain\administrator.
- Následně spustit Hyper-V Manager, v pravém sloupci zvolit Edit Disk… a zadat cestu ke vzdálenému VHD souboru, např. k:\BackupDisks\Server1Backup.VHD
- v dalších krocích zvolit Extend… a následně zadat cílovou velikost VHD souboru, neboli iSCSI disku. Spustí se proces rozšiřování VHD souboru, trvá to fakt hodně dlouho. Chce to vydržet, v žádném případě nepřerušovat.
- ukončit Hyper-V Manager (nutné, jinak je problém s následujícím bodem)
- odpojit vzdálený disk příkazem net use k: /del
- zopakovat případně kroky 3 až 7 pro další iSCSI disky
- na iSCSI serveru nastartovat službu WinTarget
- připojit se na servery s iSCSI iniciátory, zkontrolovat dostupnost iSCSI disku
- spustit na každém serveru s iSCSI iniciátory Disk Management a na dosud nezvětšeném logickém disku dát pravé tlačítko a Extend Volume…
- nastartovat služby zastavené v bodě 1.
Tím je rozšiřování iSCSI disku dokončeno. Jsem docela zvědav, jestli i W2012 iSCSI Target serveru došlo k nějaké změně, aby nebylo nutné tento obludný postup procházet.
V poslední aktualizaci ESXi 5.1 se objevila oprava jednoho typu síťové karty pro W2008R2. Tak jsem si řekl, že by bylo na čase prozkoumat, jak hypervisor aktualizovat v případě, že se jedná o free verzi, tedy bez možnosti použít Update Manager. Více...
Oracle před pár hodinami uveřejnil update 11, který opravuje široce zneužívanou chybu, o které se v poslední době psalo. Chyba byla tak závažná, že se na internetu objevovaly postupy, jak do doby zveřejnění opravy podporu Javy v prohlížečích vypnout. Zajímalo mne, jestli se chyba týká i mnou dosud používané verze Java 6. Na Internetu se dá najít vyjádření expertů, kdy jeden říká, že tato chyba existovala roky, druhý zase, že se jedná o nově objevenou zranitelnost v objektu, který byl přestaven poprvé v Java 7. Tak nevím.
Dle tohoto blogu bude podpora veřejných aktualizací pro Java 6 ukončena v únoru 2013. Pak bude bezpečnější už opravdu přejít na verzi 7.
Další články:
http://www.lupa.cz/zpravicky/derava-java-je-siroce-zneuzivana-pro-utoky/
http://krebsonsecurity.com/2013/01/what-you-need-to-know-about-the-java-exploit/
Aktualizace 14.1. 13:05:
Java 6 zneužívanou chybu dle všeho vskutku neobsahuje - http://www.zdnet.com/apple-oracle-move-quickly-to-mitigate-java-security-flaw-7000009755/.
Aktualizace 14.1. 23:05:
Tohle vypadá na pěknou habaďuru – narychlo připravený hotfix prý nic neřeší. Skoro to vypadá, že programátoři měli nůž na krku – buď “něco” vydají, nebo letí. Tak vydali – placebo, ale bez efektu.
http://betanews.com/2013/01/14/java-7-update-11-security-patch-fixes-nothing/
Takže ačkoliv jsou tam určitě jiné díry, já osobně zůstávám u Java 6 update 38, ve které tato konkrétní zranitelnost není.
Mnohokrát se mi stalo, že IISRESET skončil ztrátou konfigurace, kterou jsem těsně předtím upravoval. Dnes mi to už nedalo a tak jsem se, jako poslední možnost, podíval do nápovědy. A ejhle, ono v ní opravdu něco napsaného je
V případě, že zadám pouze IISRESET /NOFORCE, dám sice příkaz k nenásilnému ukončení IIS služeb. Jenže to většinou končí těmito chybami:
Attempting stop...
Restart attempt failed.
The requested control is not valid for this service. (2147943452, 8007041c)
Attempting stop...
Stop attempt failed.
The service did not respond to the start or control request in a timely fashion.
(2147943453, 8007041d)
Zajímavým je nicméně parametr /TIMEOUT:x, kde x je počet sekund. V případě pokynu pro restart je to standardně hodnota 20 sekund, pokud má jít o zastavení služby, je standardně nastaveno 60 sekund.
Takže bezpečným příkazem by měla být tato konstrukce:
IISRESET /STOP /NOFORCE /TIMEOUT:120
Teprve po bezpečném zastavení, kdy mám jistotu, že bylo vše korektně uloženo, zadám
IISRESET /START
Tohle si sem už musím napsat. Pokaždé, když konfiguruji novou instalaci Windows Live Writeru vůči BlogEngine.NET aplikaci, která mi běží na serveru, nakonfiguruji to napoprvé blbě.
Takže pro příště – URL, které se musí zadat, je http://dolezel.net/metaweblog.axd, nikoliv pouze http://dolezel.net/. Tím dojde k vyžádání potvrzení typu blogovací služby, kde vyberu Metaweblog API. Takto nakonfigurovaný WLW korektně ukládá obrázky ze článků na server.
Řešil jsem dnes záhadnou stížnost na nedoručení pošty u Exchange 2003. Dohledal jsem, že mail měl být doručen lokálně na back-end serveru – a vzápětí bylo odesláno NDR. V tu samou dobu bylo do Eventlogu zapsáno ID 3030 od MSExchangeTransport a v Description bylo uvedeno, že se jedná o status code 5.6.3. Poté, co jsem si našel tabulku s kódy, jsem zjistil, že se cílový server bránil příjmu e-mailu s více než 250-ti přílohami. Více...
Nabil jsem si ústa s Windows Server 2008 R2 Core edicí, která byla nakonfigurována pro vzdálenou správu pomocí nástroje CoreConfig2. Při každém pokusu o připojení se objevila tato chyba: Více...
V případě, že na IIS serveru (pro zjednodušení uvažuji jednu NIC, jednu IP adresu, žádný Apache či jiný non-IIS HTTP server) změním adresu, je potřeba opravit i konfiguraci SSTP. Při prvním kliknutí na záložku Security (Zabezpečení) ve vlastnostech RRAS serveru dostanu toto chybové hlášení: Více...
Peklo na zemi. Zálohy prováděné Windows Backupem. Víc snad už nemám sílu psát. Více...