Development of the Apache Nutch 1.10 plugin in IntelliJ IDEA using the Maven project

Apache Nutch is quite old project using Apache Ant to build itself. I wanted to develop a plugin for filtering content of parsed pages and because I am IntelliJ IDEA user I wanted to do it in this IDE. This how-to helps you to setup IDEA project so you can develop and debug the Nutch (parse) plugin. I must mention great article by Emir Dizdarevic the Precise data extraction with Apache Nutch which helped me a lot.

Part of the article is a template project: https://github.com/vkuzel/Nutch-Plugin-Development-Template

Overview

When started from IDEA the project is first built by Maven and then deployed to Nutch binary installation. Nutch task (in this case parse) is then started and Nutch itself runs the plugin. IDEA attaches a debugger to Nutch process and you can debug the code.

Maven project

Apache Nutch is present in the Maven repository but unfortunately contains some weird dependencies. To compile plugin you need to add dependency to Nutch org.apache.nutch.nutch version 1.10 and to Hadoop org.apache.hadoop.hadoop-core version 1.2.0 (Hadoop is a core library of Nutch). To compile the project you need to exclude org.apache.cxf dependency from Nutch library because Maven cannot resolve it. Btw. I figured out that different versions of Nutch need to exclude different libraries.

To allow Nutch to run the plugin it has to be built and deployed to Nutch installation directory during every debug session. This is managed by external shell script deploy_plugin_to_nutch_for_debug.sh which is executed by Maven on a install phase of a build process. For this task I incorporated the exec-maven-plugin plugin into the pom.xml file.

Nutch installation

Since this article covers development of Nutch plugin there's no need to have complete Nutch source codes. To run plugin you need properly configured Nutch binary installation that can be downloaded from it's official site. In the template project there's empty directory nutch-1.10 where Nutch should be copied. Only necessary change to Nutch cofiguration (apart from default installation process) is to add the plugin to the plugin.includes directive so Nutch can recognize it.

There's also archive test_data.zip with the pre-downloaded page that can be used to test the parser plugin. This archive is extracted to the nutch-1.10/test_data directory so the plugin is always working with same data.

Project (debug) configuration

Because project uses an external application (Nutch) an custom application run/debug configuration is needed in IDEA. Add new debug configuration with following parameters:

• Main class: org.apache.nutch.parse.ParseSegment. Nutch is started directly by calling its class not by usual shell script located in the bin directory of its installation.
• Program arguments: test_data/crawl/segments/20151010172800. This is path to test data extracted from the test_data.zip archive. Test data contains one html page just to test one pass through the plugin.
• Working directory: nutch-1.10. Besides of this working directory it is also necessary to add Nutch's conf and lib directories to a classpath. Do it by adding them in the Project Settings -> Modules -> Dependencies menu.
• Before launch run Maven Goal: clean install. Before every execution module has to be built and deployed to Nutch installation. Because of it it's necessary to execute an install goal of Maven's build process.

Now by running the debug configuration you should be able to debug the plugin.

Creating offline fallback page for the AngularJs web application using ApplicationCache

I needed to create a page that is going to be displayed to user who opened my application in the past but currently is without internet connection or he is working with the application but his connection is suddenly lost.

Client is opening the application but does not have connection available

For this purpose I decided to use ApplicationCache. I wanted that user will be redirected to offline.html page if index.html page is not loaded because connection is lost. This means I couldn’t put manifest directive to index.html page because page with manifest is automatically cached but I needed only offline.html page to be cached. So I placed manifest to offline.html instead and invoked it by placing object element to index.html.

Then defined failover page in ApplicationCache manifest file.

From now if user tries to open the application without internet connection or without server working a offline.html page will be displayed to him instead.

Client is working with the application and connection is suddenly lost

At this state only requests to server are done via XHR so we just need to intercept responses and if error occurs because connection is lost to redirect client to offline page. Interceptor can be added by $httpProvider.

How to connect Apache Solr 5.2.1 with Apache Nutch 1.10 and build concordancer on top of this stack

Apache Solr is search server based on Apache Lucene search library that allows you to index and search text content. This is great base for concordancer service. Solr itself cannot gather data from the internet. Apache Nutch was created to handle this job. This article describes basic steps of connecting Nutch to Solr and configuring concordancer service.

This text covers configuration for Solr 5.2.1 and Nutch 1.10 on Linux/Unix/OSX operating system. It's possible that configuration is going to change in future releases.

At first download binary versions of Solr and Nutch from project's websites. Then unpack both projects into one directory, let's say concordancer.

Go to Solr direcotry (solr-5.2.1) and start it by calling

bin/solr start

Then create search core named "concordancer".

bin/solr create -c concordancer

Core is the database of indexed data and configuration of how to perform search on this data. For example you can have several cores one for searching intranet sites another for searching internet websites.

Newly created core concordancer uses default configuration that needs to be changed. Without these changes Nuch can't interoperate with Solr. Open the configuration file server/solr/concordancer/conf/solrconfig.xml.

Almost at the end of file you can see directive <updateRequestProcessorChain name="add-unknown-fields-to-the-schema”>. This tells to Solr that when indexing data Solr should define index structure (de facto database structure for indexed data) dynamically. This means if new data structure is indexed (like website with all its metadata) new fields will be added to index structure described in generated managed-schema file. We don't need this feature so remove <updateRequestProcessorChain name="add-unknown-fields-to-the-schema"> and it's content. Also remove <schemaFactory class="ManagedIndexSchemaFactory"> and it's content. Try to find <initParams path="/update/**”> it should contain add-unknown-fields-to-the-schema parameter so remove this directive too.

Search for all occurences of string _text_ in config file and change them to text. Newly created schema file below does not contain field named _text_ so that’s why we have to change it's name.

Now remove generated file managed-schema from configuration directory and replace is by schema.xml file prepared by Nutch developers. This means copying apache-nutch-1.10/conf/schema.xml to solr-5.2.1/server/solr/concordancer/conf directory.

Open the copied configuration schema.xml and find directive <field name="content" type="text" stored="true" indexed="true”/>. Change parameter stored from value false to true. This means that you don’t want to just index page's content but also store it's text for concordancer purposes.

Find directive <filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt”/> and delete it. Then close the file and restart Solr by calling:

bin/solr restart

Let’s turn our attention to crawling websites by Nutch so go to directory apache-nutch-1.10 and try to run program without parameters:

bin/nutch

You should see output like this:

If there's some problem please go to Nutch tutorial for more details.

Open Nutch configuration file conf/nutch-site.xml and add configuration of Nutch User-agent http header:

Then create directory that is going to contain files with URLs to be crawled. In this directory create file seed.txt with one URL per line. You should end up with structure like this:

apache-nutch-1.10/urls/seed.txt

Then execute crawling and indexing of pages by calling crawl command.

bin/crawl -i -D solr.server.url=http://localhost:8983/solr/concordancer urls/ crawl/ 1

Troubleshooting: If some error appear while crawling check out the log files solr-5.2.1/server/logs/solr.log and apache-nutch-1.10/logs/hadoop.log Actually Solr's schema.xml file contains some problems like missing field types, etc. Solving of these problems is up to you.

Open the Solr's query page and try to search newly indexed data.

Let's configure Solr's concordancer ability. Open the configuration file server/solr/concordancer/conf/solrconfig.xml and locate configuration directives of highlighter (tag <searchComponent class="solr.HighlightComponent" name="highlight”>). Change the default boundary scanner from simple boundary scanner to break iterator and configure break iterator’s bs.type to SENTENCE. Boundary scanner finds boundaries of sentence so from now concordancer can display whole sentences.

Finally we need to modify request handler to display found sentences. Go to required request handler and add highlighter configuration. I choose to modify /query handler so its configuration looks like following:

Open the Solr admin http://localhost:8983/solr/#/concordancer/query and fire some queries on /query request handler. You should see result similar to this:

Apache 2.4.7 v Xubuntu 14.04 nenačítá některé konfigurační soubory

Po přechodu z Xubuntu 12.04 na verzi 14.04 s instalací nového web-serveru Apache2 mi přestaly fungovat VirtualHosty. Konfiguraci VirtualHostů mám uloženou v adresářích jednotlivých projektů a nalinkovanou do složky s konfigurací webů sites-enabled.

/etc/apache2/sites-enabled/projekt1 -> /home/vkuzel/projects/projekt_dir/projekt1

Problém je ale v tom, že poslední verze Apache2 odmítají načítat konfigurační soubory, které nemají příponu conf. Prý je to z důvodu, že u těchto souborů nelze použít nástroje jako a2enconf, a2ensite atd. Řešením je tedy přidat příponu souboru .conf ke konfiguracím.

/etc/apache2/sites-enabled/projekt1.conf -> /home/vkuzel/projects/projekt_dir/projekt1.conf

Pád Firefoxu při vypnutí systému Xubuntu 12.04

V Xubuntu 12.04 se objevila nepříjemná chyba, která způsobila nekorektní ukončení Firefoxu, při vypnutí systému nebo odhlášení uživatele. Ta měla za následek, že při následujícím spuštění Firefoxu se místo původních záložek nebo prázdné stránky (dle nastavení) objevila hláška "Ale toto je nepříjmené." nebo "Well, this is embarrassing.", záleží na jazykové mutaci prohlížeče.

Problém je v chybějících knihovnách, sloužících pro upozornění Firefoxu systémem, že dochází k ukončení relace vizte též https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/867424. Jde o knihovny libgnome, které se vývojáři chystají odstranit z Linuxové verze Firefoxu. Zatím je však odstranili pouze ze závislostí balíčku prohlížeče, nikoli však ze zdrojového kódu.

Řešení problému spočívá v dodatečné instalaci knihoven pomocí následujícího příkazu.

sudo apt-get install libgnomeui-0

Spuštění existující instalace Windows XP OEM - GMC-Dell ve VirtualBoxu 4.2.4 na Xubuntu 12.04 bez nutnosti Aktivace

Na počítači Dell Optiplex 740 mám předinstalovaný systém Microsoft Windows XP (dále jen Windows na fyzickém stroji). Přidal jsem druhý pevný disk se systémem GNU/Linux, konkrétně s distribucí Xubuntu 12.04 (dále jen Linux nebo Xubuntu), který jsem se rozhodl používat jako hlavní operační systém. Protože ale některé programy pod Xubuntu (ani Wine) neběží a restartováni PC do Windows pokaždé když chci spustit některý z Windows-only programů je nepohodlné, vyvstal požadavek na spouštění Windows přímo z Linuxu.

Předpoklady

Instalace Microsoft Windows

Jako koncový uživatel můžete získat Windows prakticky se třemi různými druhy licence. Na mém počítači je předinstalovaný systém Microsoft Windows a to v licenci OEM Gold Master Copy. Co tento typ licence znamená?

1. Retail. Jde o krabicovou verzi Windows, zakoupenou v obchodě. Nevím jak je to u ní s aktivací a smlouvou EULA, co se týče počtu instalací z "jedné krabice". Prý je možné jeden systém legálně nainstalovat vícekrát.
2. OEM - Běžná OEM licence. Systém Windows zakoupený koncovým uživatelem v obchodě. Tato licence opravňuje uživatele provést pouze jednu instalaci systému. Během aktivace systému je tato instalace svázána s konkrétním hardware počítače na kterém je systém nainstalován.
   
   Svázání je řešeno tak, že při aktivaci Windows přečte vlastnosti deseti zařízení počítače, tyto vlastnosti zašifruje a uloží do souboru c:\Windows\system32\wpa.dbl. Po každém přihlášení uživatele do systému porovná nainstalovaná zařízení počítače s daty ve wpa.dbl a pokud se alespoň sedm z těchto zařízení shoduje, pokračuje v přihlášení, jinak vyžaduje opětovnou aktivaci. Od každého druhu zařízení ukládá Windows do wpa.dbl poze první nalezené zařízení, tedy pokud máte například tři síťové karty, pro kontrolu aktivace je použita pouze první, atd.
3. OEM Gold Master Copy. Pokud zakoupíte počítač od některého z velkých výrobců (Dell, HP, Asus) s již předinstalovaným systémem obdržíte Windows v takzvané Gold Master Copy OEM licenci, což je speciální druh licence určené pro hromadnou instalaci. Tento typ Windows disponuje takzvanou System Locked Pre-Installation (dále jen SLP) kontrolou aktivace systému. Na rozdíl od běžné OEM licence, Windows po přihlášení neporovnává hardware počítače se souborem na disku, ale v paměťovém prostoru BIOSu, hledá speciální řetězec identifikující počítač daného výrobce, pro kterého je instalace Windows určena. Konkrétně tedy instalace pro Dell, hledá na různých místech paměti BIOSu řetězce, jako "Dell System", "Dell Computer" a pod. Pokud některý (alespoň jeden) z nich najde není uživatel vyzván k aktivaci a systém se normálně spustí. Toto je můj případ a více se o něm rozepíšu v kapitole Aktivace Windows a prakticky v celém tomto článku.

Pokud si nejste jistí, který typ licence máte, spusťte ve Windows nástroj Microsoft Genuie Advantage Diagnostic Tool.

Klikněte na tlačítko Continue a potom Copy, címž uložíte výsledek kontroly do clipboardu. Otevřete nějaký textový editor (například notepad) a pomocí ctrl+v vložte výsledek do editoru. Ke konci souboru by měla být vidět informace o SLP řetězcích.

OEM Activation 1.0 Data-->
BIOS string matches: yes
Marker string from BIOS: 1E840:Dell Inc|563B:Dell Inc|563B:Microsoft Corporation
Marker string from OEMBIOS.DAT: Dell System,Dell Computer,Dell System,Dell System

Pokud tam tuto informaci nemáte, nevlastníte Windows ve verzi OEM Gold Master Copy.

Zajímavá je také informace "Marker string from OEMBIOS.DAT", což je seznam SLP řetězců, které Windows hledají v BIOSu, bohužel zde není zobrazeno na kterých pozicích v paměti tyto řetězce hledá, to zjistíme později.

Předpokládejme tedy, že máte na svém PC, na jednom pevném disku (nebo oddílu disku) existující fungující legální instalaci Windows XP, service pack 3 a na druhém disku instalaci Xubuntu nebo obdobného Debian-based Linuxu.

Instalace VirtualBox

Pokud chcete v Linux spustit/virtualizovat existující instalaci Windows, máte prakticky dvě možnosti. Použít uzavřený software VMware Player nebo téměř open source VirtualBox (využívá některé uzavřené komponenty). VM Player nabízí víc konfiguračních možností, ale díky plně uzavřenému kódu není snadné jej modifikovat v případě, že potřebujete upravit něco, co konfigurace nenabízí.

Já jsem tedy volil VirtualBox a to konkrétně v aktuálně poslední verzi 4.2.4, instalované přímo z repositářů projektu VirtualBox, kde se nachází také návod k instalaci.

Ve vašem Linuxu byste tedy měli mít funkční instalaci programu VirtualBox verze 4.2.4.

Spuštění Windows ve VirtualBoxu

Protože smlouva EULA, OEM verze Windows nedovoluje instalovat systém více než jednou a to i na jednom PC, neimportoval jsem existující instalaci do virtuálního disku VirutalBoxu, ale vytvořil jsem virtuální disk jako odkaz na fyzický disk s Windows, a tato Windows následně spouštím přímo z něj.

Vytvořit odkaz na virtuální disk a nastavit VirtualBox je možné dle návodu na stránkách VirtualBoxu.

https://forums.virtualbox.org/viewtopic.php?t=9697

Návod je poměrně obsáhlý, nejdůležitější body jsou ale kapitola I. bod 1., kde i přes to, že návod výslovně zakazuje povolení volby IO APIC na kartě systém, zkuste si s touto volbou pohrát, pokud Windows ve VirtualBoxu nenastartují. DMI BIOS setting vás budou zajímat, pouze pokud máte Windows v běžné OEM licenci. Dále se pak zaměřte na kapitolu III. Partitioning, ve které je popsán proces vytvoření odkazu na fyzický disk s instalací Windows. Ve třetí kapitole je v podstatě nutné spustit jediný příkaz.

sudo VBoxManage internalcommands createrawvmdk -filename rawDiskXP.vmdk -rawdisk /dev/sda

Který vytvoří vdmk soubor s cestou k fyzickému disku. A nakonec bod IV. ve kterém je popsána konfigurace virtuálního stroje. Já jsem vytvořil virtuální stroj ve výchozím nastavení, pouze jako pevný disk jsem vybral vdmk soubor vytvořený v předchozím bodě a stroj bez problémů spustil. Bez nutnosti spuštění MergeIDE nebo vytváření alternativních hardwarových profilů Windows naběhly.

V tomto okamžiku byste tedy měli mít nakonfigurovaný virtuální stroj, se spuštěnými Windows, které po přihlášení (pokud je nutné) vyžadují aktivaci.

Spuštění Windows bez výzvy k aktivaci

Jak již bylo napsáno v předchozích kapitolách, OEM GMC verze Windows hledá při kontrole aktivace speciální řetězec v BIOSu. Samotný algoritmus vyhledávání SLP řetězců je uložen v souborech c:\Windows\system32\OEMBIOS.*. Pokud tyto soubory nahradíte soubory z instalace Windows od jiného GMC výrobce, budou Windows hledat jiné řetězce (to ovšem není cílem tohoto článku).

My tedy:

1. Zjistíme, jakou verzi souborů OEMBIOS máme v instalaci Windows.
2. Dle ní potom najdeme pozice SLP řetězců v BIOSu a ověříme existence SLP řetězce v BIOSu fyzického stroje.
3. Prozkoumáme strukturu BIOSu virtuálního stroje.
4. Vložíme SLP řetězec do BIOSu virtuálního stroje, tak abychom předešli nutnosti znovu-aktivovat Windows ve VirtualBoxu.

1. Ověření OEM licence Windows

Ke zjištění verze souborů OEMBIOS spusťte nástroj OEMBIOS.EXE v příkazové řádce Windows. Na výstupu dostanete kontrolní součty nalezených informací. Například na mém systému vidím dva součty (crc).

C:>OEMBIOS.EXE

F:Dell System OEMBIOS.CAT CRC=63875D1F
F:Dell System OEMBIOS.CAT CRC=B6F0EEFD

Tyto hodnoty si poznamenejte pro další použití.

2. Nalezení pozice SLP řetězce v BIOSu fyzického stroje

Abychom se trochu zorientovali, ověříme si umístění SLP řetězce v našem BIOSu. A aby se nám s pamětí BIOSu lépe pracovalo, začneme tím, že si ji zkopírujeme do souboru. Nabootujte do Linuxu a jako uživatel root nebo pomocí příkazu `sudo` spusťte následující příkaz.

sudo dmidecode -t0

Příkaz dmidecode čte informace o BIOSu přímo ze zařízení /dev/mem (proto nutnost mít práva uživatel root) a vypisuje je uživatelsky čitelná na standardní výstup. Přepínačem -t0 zobrazíme pouze obecné informace o BIOSu. Ve výstupu bychom měli mimo jiné vidět data obdobná jako jsou následující.

BIOS Information
   Vendor: Dell Inc.
   Version: 2.1.9
   Release Date: 12/04/2008
   Address: 0xE0000
   Runtime Size: 128 kB
   ROM Size: 512 kB

Zajímavé jsou pro nás informace Vendor identifikující výrobce BIOSu a Address společně s Runtime Size popisující umístění dat BIOSu v paměti. Následujícím příkazem z paměti od adresy 0xE0000 (hexadecimálně) přečteme 128 kB dat a uložíme je do souboru.

sudo head -c 1048576 /dev/mem | tail -c 131072 > original_bios.bin

Příkaz před pajpou přečte počáteční 1 MB dat z paměti, tedy 0xE0000 + 128 kB. Druhý příkaz potom z těchto dat vybere posledních 128 kB.

Podle kontrolních součtů zjištěných v kapitole Ověření OEM licence Windows nalezněte na tech. fóru MSFN seznam SLP řetězců, které vaše instalace Windows hledá v paměťovém prostoru BIOSu.

http://www.msfn.org/board/topic/71016-multi-manufacturer-pre-activation/page__view__findpost__p__534097

Pokud máte víc kontrolních součtů, ne všechny se musí v seznamu nacházet. Používejte jeden součet po druhém a hledejte seznam, dokud na něj nenarazíte. Tedy například mé Windows dle OEMBIOS.CAT CRC32=B6F0EEFD hledají následující řetězce.

f000,e076,0010,Dell System
f000,e840,0010,Dell Computer
f000,49a9,0010,Dell System
f000,e05e,0010,Dell System
f000,e838,0018,Dell Inc

Přičemž například hodnoty v prvním řádku znamenají f000: hledej v oblasti kódu BIOSu (nikoli SMBIOSu), e076: začni zde hledat od adresy 0xE076, 0010: hledej v následujících šestnácti bytech a hledej tam řetězec "Dell System". Tedy v mém případě Windows hledají řetězec "Dell System" v paměťovém prostoru počítače od adresy 0xFE076 až po adresu 0xFE086.

Pokud by první hodnota byla e000, znamenalo by to hledání řetězce od adresy 0xEE076. Pokud třetí hodnota 0010 chybí, znamená to že pozice řetězce musí přesně odpovídat dané adrese.

Pokuste se některý z SLP řetězců nalézt v BIOSu, který jste si v předešlém kroku zkopírovali do souboru. Protože v souboru jsou pouze samotná data BIOSu, musíme hledat první řetězec nikoli od adresy 0xFE076, ale od adresy 0x1E076 (náš soubor začíná od hodnoty 0x0, nikoli 0xE0000 jako je tomu v paměti počítače).

Pomocí následujícího příkazu zobrazte data BIOSu a prozkoumejte uvedené adresy.

hexdump -C current_bios.bin | less

V mém případě jsem SLP řetězec "Dell Computer" naše na pozici 0x1E840, kde se nacházela tato data.

0001e840   44 65 6c 6c 20 43 6f 6d   70 75 74 65 72 20 43 6f   |Dell Computer Co|

Tedy, Windows v tomto paměťovém prostoru nalezly řetězec "Dell Computer".

3. Prozkoumání BIOSu virtuálního stroje

Obdobným způsobem, kterým jsme prozkoumali BIOS fyzického stroje v kapitole 2, prozkoumáme BIOS virtuálního stroje.

Abychom se mohli do BIOSu ve virtuálním stroji podívat, spustíme si v něm nějaký operační systém, kterým budeme moci číst paměť obdobně jako jsme to udělali v kapitole 2. Já jsem pro své experimentování zvolil live distribuci Slax.

Ze stránek Slaxu si stáhněte iso obraz distribuce a uložte někam na svůj disk. Ve VirtualBoxu vytvořte nový virtuální stroj bez virtuálního disku. Po jeho vytvoření, přejděte do nastavení jednotek, u optické mechaniky zvolte stažený ISO obraz Slaxu, virtuální stroj spusťte (stačí textový režim) a přihlašte se jako uživatel root (přihlašovací údaje uvidíte po nabootování systému, přímo nad vstupem pro zadání jména a hesla).

Obdobným způsobem, jako v kapitole 2. zobrazíme základní informace o BIOSu virtuálního stroje, příkazem dmidecode.

dmidecode -t0

Ze zobrazených informací zjistíme umístění dat BIOSu v paměti.

BIOS Information
   Vendor: innotek GmbH
   Version: VirtualBox
   Release Date: 12/01/2006
   Address: 0xE0000
   Runtime Size: 128 kB
   ROM Size: 128 kB

Tedy v případě virtuálního stroje se BIOS nachází ve 128 kB paměti, počínaje adresou 0xE0000, obdobně jako v případě BIOSu fyzického stroje. Stejným způsobem tedy paměť přečteme a BIOS uložíme do souboru.

head -c 1048576 /dev/mem | tail --bytes=131072 > virtual_bios.bin

Všimněte si, že v případě příkazu tail jsem místo přepínače -c použil přepínač --bytes. Tyto dva přepínače mají stejnou funkci, pouze přepínač -c v tailu, verze 6.12, která je přítomná v distribuci Slax 6 nefunguje korektně. Vyexportovaný soubor si hexadecimálně zobrazte.

hexdump -C virtual_bios.bin | less

Jak jsme si objasnili v předchozích kapitolách OEM verze Windows hledá definované řetězce v BIOSu, najděte si proto SLP řetězce platné pro Vaši instalaci Windows viz kapitola 2. Když prohledáte data zobrazená předchozím příkazem (`hexdump virtual_bios.bin`) a prozkoumáte pozice SLP řetězců, odpovídající řetězce na nich nenajdete. Nezapomeňte na to, že SLP řetězec může být umístěn v určitém rozsahu, tedy nemusí být nutné aby byl umístěn přesně na jedné konkrétní adrese.

V následujícím kroku se tedy pokusíme SLP řetězce do BIOSu dostat. To můžeme prakticky udělat dvěma způsoby. Jednodušším, což je změnou dat SMBIOSu, popsaném v kapitole 4, anebo složitějším, což je zápis SLP řetězců přímo do programu BIOSu, popsaném v kapitole 5.

4. Vložení SLP řetězce do oblasti SMBIOSu konfigurací virtuálního stroje

System Management BIOS (SMBIOS) je datová struktura/oblast BIOSu, ve které jsou uloženy informace o počítači, jako je například typ, model, výrobce základní desky, procesoru a pod. Některé hodnoty v této oblasti je možné změnit jednoduchou úpravou konfiguračního souboru virtuálního stroje. Pokud tedy máte štěstí a Vaše OEM instalace Windows hledá SLP řetězec právě v této oblasti, můžeme této možnosti využít.

Nejdříve zjistíme, kde se v BIOSu virtuálního stroje oblast SMBIOS nachází. Zobrazte si BIOS virtuálního stroje příkazem hexdump.

hexdump -C virtual_bios.bin | less

A najděte řetězec "_DMI_", který značí začátek druhé části "vstupního bodu" struktury SMBIOS. Jinými slovy kousek za tímto řetězcem naleznete adresu na které se struktura SMBIOS nachází a její délku. Po nalezení DMI Vás bude zajímat následujících 12 bytů.

0001ff70  5f 44 4d 49 5f 65 b6 01   00 10 0e 00 09 00 25 00  |_DMI_e........%.|

Dle specifikace vstupního bodu SMBIOSu (entry point viz tabulka 1) snadno již dohledáme, že struktura SMBIOS má dle bytů 6 až 7 celkovou délku 0xB601, tedy 46 593 bytů a dle bytů 8 až 11 (na řádku, byty se dle kapitoly "Access Method Address — DWORD Layout" čtou pozpátku) nachází v paměti na adrese 0xE1000.

Jelikož můj systém hledá SLP řetězce mimo oblast SMBIOS, budeme po zbytek této kapitoly uvažovat, že máme počítač i systém od společnosti Epson, hledající SLP řetězce na následujících pozicích.

F000,0000,FFFF,EPSON
E000,0000,FFFF,EPSON

Dle druhého řádku (a dle kapitoly 2) vidíme, že systém hledá SLP řetězec "EPSON" v paměti od adresy 0xE0000, až po adresu 0xEFFFF, tedy tato oblast pokrývá oblast SMBIOSu virtuálního stroje.

V manuálu VirtualBoxu si ze seznamu nastavitelných parametrů SMBIOSu (tzv. DMI parametry) vyberte vhodný parametr, do kterého vložte požadovaný SLP řetězec. Určitě je vhodné volit parametr, typu textová hodnota, vhodný bude například "DmiBIOSVendor". Potom pomocí příkazu `VBoxManage setextradata` tomuto parametru nastavte hodnotu jako pro virtuální stroj Windows a pro ověření správnosti nastavení i pro stroj se systémem Slax (nezapomeňte virtuální stroj vypnout a za "VM name" dosadit jeho název).

VBoxManage setextradata "VM name" "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSVendor" "EPSON"

Po nastavení parametru spusťte nejdříve systém Slax a z paměti si zobrazte oblast BIOSu.

head -c 1048576 /dev/mem | tail --bytes=131072 | hexdump -C | less

V zobrazených datech by jste měli být schopni dohledat řetězec "EPSON" a to zhruba na adrese 0xE1010. Tedy pokud jste si paměť zobrazili předchozím příkazem, měl by řetězec být umístěn zhruba na pozici 0x1010. Pokud se tam nachází a jste vlastníky počítače s WIndows od Epsonu, máte vyhráno. Spusťte virtuální stroj s Windows, která by se měla spustit bez nutnosti aktivace.

Pokud Windows stále vyžadují aktivaci, zkuste prověřit následující možné příčiny problémů.

1. Ověřte, zda-li jste změnili parametr DmiBIOSVendor i pro virtuální stroj s Windows.
2. Ověřte, zda-li je nastavený SLP řetězec, v oblasti, kde jej systém hledá/očekává. Pokud není, zkuste změnit některý z dalších parametrů SMBIOSu, který by se v dané oblasti mohl nacházet (metodou pokus-omyl).
3. Pokud se Vám nedaří dostat SLP řetězec na správnou pozici v paměti konfigurací parametrů SMBIOS, pokračujte čtením kapitoly 5.
   

5. Vložení SLP řetězce do existujícího BIOSu VirtualBoxu

Pokud postup popsaný v předcházející kapitole selhal a Váš SLP řetězec se nachází mimo oblast SMBIOSu, v části od adresy 0xF0000, musíme řetězec vložit přímo do upraveného binárního kódu BIOSu VirtualBoxu a tento BIOS pomocí nezdokumentované konfigurační direktivy "BiosRom" použít ve vašem virtuálním stroji.

Použití vlastního obrazu BIOSu ve VirtualBoxu má nějaká omezení, na která je dobré myslet.

1. Nepodařilo se mi zprovoznit jiný BIOS než ten, který je dodáván s VirtualBoxem. Zkoušel jsem zkopírovat BIOS fyzického stroje (tedy Dellu), upravit entry point SMBIOSu, ale s tímto BIOSem virtuální stroj nenastartoval.
   
2. Obraz BIOSu musí mít přesně 65536 bytů. Údajně by měly fungovat i obrazy velikosti násobku této hodnoty, ale opět žádný takový obraz se mi nepodařilo zprovoznit. Z toho také vyplývá, že použitý obraz je částí kódu BIOSu od adresy 0xF0000 až po 0xFFFFF. Tedy nejedná se o tabulku SMBIOS, která je VirtualBoxem generovaná dyanmicky při spuštění virtuálního stroje, dle konfiguračních parametrů.

Pro jednoduchost příkladu budeme opět uvažovat Windows dodávaný společností Epson, tedy vložíme do BIOSu řetězec "EPSON" tentokrát někam mezi adresy 0xF0000 a 0xFFFFF. Tento rozsah nám poskytuje absolutní svobodu v editaci obrazu BIOSu.

Pod Slaxem si uložte obraz BIOSu do souboru a to od adresy paměti 0xF0000 až po adresu 0xFFFF. Soubor si zkopírujte z virtuálního stroje (Slaxu) na fyzický stroj například pomocí příkazu `scp` a otevřete si jej v hexadecimálním editoru (například ghex).

head -c 1048576 /dev/mem | tail --bytes=65536 > virtual_bios_image.bin

ghex virtual_bios_image.bin

V editoru teď najdeme místa, kde je dostatek binárních nul za sebou, do kterých bude možné vložit požadovaný řetězec aniž bychom něco rozbili. Všimněte si, že ve zkopírovaném BIOSu je řada takových míst a tato místa často končí ASCII řetězcem "XM". Tento řetězec je speciální značka použitá vývojáři VirtualBoxu k odsunutí části kódu BIOSu za určitou adresu. Například vývojáři nechtěli mít obsluhu disků nalepenou hned na obsluhu grafického výstupu a tak při kompilaci assembleru BIOSu vložili mezi tyto dva bloky prázdné místo ukončené značkou "XM". Tohoto místa můžeme beze strachu, že bychom něco rozbili, pohodlně využít.

Projděte Vaše SLP řetěze, zda-li některý z nich nebude možné vložit do jednoho z těchto prázdných míst. V našem ukázkovém případě můžeme řetězec "EPSON" vložit hned do prvního nalezeného prázdného místa v mém případě od 0xDDAA až po 0xE02D, za kterým se nachází řetězec "XM". Oblast bude po úpravě vypadat následovně (Zobrazena je pouze část oblasti).

0000e010   00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00   |................|
0000e020   45 50 53 4f 4e 00 00 00   00 00 00 00 00 00 58 4d   |EPSON.........XM|

Obdobně, jako v kapitole 4 nastavíme virtuální stroj, tak že požije upravený obraz BIOSu místo výchozího. Spusťte příkaz `VboxManage` a nastavte parametr BiosRom, jak pro virtuální stroj se Slaxem, tak i pro stroj s Windows.

VBoxManage setextradata "VM name" "VBoxInternal/Devices/pcbios/0/Config/BiosRom"   "/cesta-k-upravenemu-biosu/virtual_bios_image.bin"

Nyní spusťte virtuální stroj se systémem Slax a zkontrolujte přítomnost požadovaného SLP řetězce v BIOSu obdobně, jako v kapitole 4. Poté spusťte virtuální stroj s Windows.

Pokud se Vám nepodařilo vložit SLP řetězec na požadovanou pozici z důvodu, že se na této pozici nenacházelo prázdné místo, ale leží na ní kód BIOSu, pak pokračujte kapitolou 6.

6. Kompilace a použití vlastního BIOSu ve VirtualBoxu

Tak jak jsem zmiňoval dříve některé verze Windows hledají SLP řetězce na pozicích, na kterých se již nachází kód BIOSu virtuálního stroje a nikoli prázdná místa, do kterých by bylo možné řetězce vložit. To je i můj případ s Windows od Dellu, které hledají SLP na následujících adresách.

f000,e076,0010,Dell System
f000,e840,0010,Dell Computer
f000,49a9,0010,Dell System
f000,e05e,0010,Dell System
f000,e838,0018,Dell Inc

Nyní bude naším cílem na některé z výše uvedených pozic prázdné místo vytvořit odsunutím částí kódu BIOSu jinam a poté do tohoto místa SLP řetězec vložit. Abychom to mohli udělat, budeme muset zkompilovat VirtualBox i s jeho BIOSem, který je naprogramován v assembleru.

Dle návodu na stránkách VirtualBoxu stáhněte zdrojové kódy projektu a připravte potřebné knihovny. Ještě před samotnou kompilací (kapitola Building VirtualBox) si stáhněte, nainstalujte a nastavte nástroje a knihovny OpenWatcom, bez kterých nepůjde kód BIOSu zkompilovat.

Jděte do adresáře zdrojových kódů VirtualBoxu a v textovém editoru otevřete zdrojový kód BIOSu.

vi src/VBox/Devices/PC/BIOS/orgs.asm

Ve zdrojových kódech si všimněte funkce BIOSORG a jejího volání. Tato funkce vkládá prázdná místa a řetězec "XM" na požadované pozice ve výsledném binárním souboru BIOSu. Kód, který se nachází za voláním této funkce je potom odsunut až za tuto adresu.

My tedy upravíme parametr volání funkce BIOSORG, tak abychom kód odsunuli až za prostor, do kterého budeme chtít vložit SLP řetězec. Jelikož se může stát (a v mém případě také stalo), že odsunutý kód bude po kompilaci kolidovat s kódem následujícím, budeme muset odsunout i tento následující kód a tak dále, dokud se kolizí nezbavíme.

Prozkoumejte seznam vašich SLP řetězců a stávající binární verzi BIOSu virtuálního stroje. Ta by měla odpovídat zobrazenému zdrojovému kódu, pokud odpovídat nebude po kompilaci můžete zkoumat BIOS Vámi kompilovaný. Zvažte různé varianty posunutí kódu a případné kolize. Já jsem zvolil umístění SLP řetězce na pozici 0xE076. Pokračujme tedy v úpravách pro Windows od Dellu.

Abychom mohli řetězec na danou pozici umístit, musíme odsunout jeden z bloků kódu BIOSu. Po letmém prozkoumání zdrojového kódu vidíme, že na pozici 0xE076 se již nachází kód začínající oddělovačem na pozici 0xE05B. Najděte tedy příslušné volání funkce BIOSORG a posuňte pozici o 240 (0xF0) bytů, tedy změňte její parametr na hodnotu 0xE14B. Tím vytvoříme dostatek prostoru pro vložení SLP.

Prozkoumáním binární verze BIOSu (soubor virtual_bios_image.bin) zjistíte, že odsunutím původní sekce o 240 bytů, dojde k ke kolizi s následujícím blokem kódu, začínajícím na 0xE2C3. Totiž mezi posledním nenulovým bytem předcházejícícho a začátkem tohoto bloku jsou volné pouhé 4 byty. Tento blok tedy posuňte také o 240 bytů na pozici 0xE3B3. Tím dojde ke kolizi s následujícím blokem na pozici 0xE3FE, ten už stačí posunout o 48 (0x30) bytů na pozici 0xE42E. Změny uložte a spusťte příkaz `diff` na původní a upravený zdrojový kód BIOSu, dostanete následující výsledek.

220c220
<      BIOSORG    0E05Bh
---
>      BIOSORG    0E14Bh
506c506
<      BIOSORG    0E2C3h
---
>      BIOSORG    0E3B3h
552c552
<      BIOSORG    0E3FEh
---
>      BIOSORG    0E42Eh

Přejdeme k přípravě BIOSu ke kompilaci. Abychom mohli zkompilovat BIOS z námi upraveného souboru je nejdříve nutné zkompilovat celý projekt, potom přegenerovat nižší úroveň assembleru BIOSu a poté projekt zkompilovat znovu a vytvořit tak binární podobu obrazu BIOSu. Z upraveného souboru orgs.asm je totiž vygenerován soubor VBoxBiosAlternative.asm ("jednodušší" assembler) a až ten je potom kompilován, při kompilaci celého projektu. Toto generování "jednoduššího" assembleru obstará program, který je v podobě zdrojových kódů součástí VirtualBoxu, proto je nutná ta první kompilace.

Přejděte tedy do složky se zdrojovými kódy VirtualBoxu ověřte, že máte správně nainstalovanou a nastavenou knihovnu OpenWatcom a projekt nakonfigurujte s parametrem "--disable-hardening".

configure --disable-hardening
source env.sh

Během konfigurace, konfigurační skript vypisuje dostupnost knihoven a nástrojů potřebných ke kompilaci projektu. V tomto výpisu ověřte, že nástroj OpenWatcom je dostupný. Zůstaňte v adresáři projektu a spusťte kompilaci.

kmk all

Kompilace může trvat i přes hodinu, záleží na výkonnosti vašeho stroje a nemusí se vždy povést úplně celá. Obvykle skončí s problémy při sestavení dokumentace. To nás nemusí příliš trápit, důležité je, zda-li se zkompiloval program pro generování BIOSu a binární podoba původního neupraveného BIOSu. Proto v adresáři s výstupem kompilace ověřte přítomnost následujících dvou souborů.

out/linux.x86/release/obj/MakeAlternativeSource/MakeAlternativeSource.o
out/linux.x86/release/obj/VBoxPcBios/VBoxPcBios.rom

Nyní přejděte zpět do adresáře se zdrojovým kódem BIOSu, vygenerujte jednodušší verzi assembleru BIOSu (soubor VBoxBiosAlternative.asm bude aktualizován) a projekt znovu zkompilujte.

ghex out/linux.x86/release/obj/VBoxPcBios/VBoxPcBios.rom

Já jsem vložil řetězec "Dell System" na pozici 0xE076, výsledná oblast bude tedy vypadat následovně.

0000e070  00 00 00 00 00 00 44 65  6c 6c 20 53 79 73 74 65  |......Dell Syste|
0000e080  6d 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |m...............|

Zkopírujte si soubor BIOSu někam ke konfiguraci virtuálního stroje a nastavte virtuální stroj tak aby tento upravený BIOS používal místo výchozího, obdobně jako v předcházející kapitole.

VBoxManage setextradata "VM name" "VBoxInternal/Devices/pcbios/0/Config/BiosRom"  "/cesta-k-upravenemu-biosu/virtual_bios_image.bin"

Spusťte Slax a zknotrolujte, zda-li vše běží tak jak má, pak spusťte Windows.

Řešení možných problémů.

1. Virtuální stroj po konfiguraci upraveného BIOSu nenastartuje. To je pravděpodobně způsobeno chybnou úpravou volání funkce BIOSORG, tedy zřejmě jste posunuli nějaký kód o příliš velký počet bytů a ten teď koliduje s kódem následujícím. Překontrolujte ještě jednou možné kolize ve výsledné binární verzi upraveného BIOSu.
2. Windows stále vyžadují aktivaci. Ověřte správnost pozice vloženého SLP řetězce.
3. Kompilace VirtualBoxu selhává z různých příčin. Pokud se Vám nedaří BIOS zkompilovat a snažíte se zprovoznit Windows od Dellu, můžete si stáhnou mnou kompilovaný BIOS z Google docs nebo alternativně také binární podobu původního BIOSu. Pozor tyto BIOSy v sobě nemají vložené SLP řetězce, tato úprava zůstává na Vás.

Legálnost/licence

Setkal jsem se s názorem, že spuštění Windows XP ve VirtualBoxu je proti licenčním podmínkám systému. Tento názor se podle mne nezakládá na pravdě a v následujících odstavcích se jej pokusím rozporovat.

Výchozí podmínky: Společně s počítačem (koupil jsem jej jako použitý), jsem získal i systém Windows XP Service Pack 3 OEM (GMC). Licence k systému je uložena v souboru c:\windows\system32\eula.txt. Licence (End User Agreement Licence, dále jen EULA) má na konci souboru uvedeno "EULAID:XPSP2_RM.0_PRO_OEM_CS" což navozuje dojem, že se jedná o licenci k service packu 2. Při prohledání systému jsem ovšem nikde soubor se speciální licencí pro service pack 3 nenašel. Ani na stránce seznamu licencí produktů Microsoftu není novější (než tu kterou mám ve svém systému já) licence dostupná. K počítači nebyla přiložena jiná tištěná podoba licence a licence instalovaných aktualizací systému nemění podmínky používání systému. Předpokládám tedy, že platná licence je tato.

Systém jsem získal předinstalován společně s počítačem Dell Optiplex 740 a s tímto počítačem byl systém i původně dodáván. Proto se také jedná o OEM (GMC) verzi systému.

V úvodní kapitole smlouvy nalezneme větu: "Tato licenční smlouva s koncovým uživatelem ("EULA") je smlouvou mezi vámi (fyzickou nebo právnickou osobou) a výrobcem ("Výrobce") počítačového systému nebo součásti počítačového systému ("HARDWARE"), s nímž jste získali softwarové produkty společnosti Microsoft uvedené v Certifikátu pravosti („COA“) připojeném k HARDWARU nebo v dokumentaci k příslušnému produktu ("SOFTWARE").". Ze které vyplývá, že

1. Windows jsem získal s počítačem bez periferií, tedy bez monitoru atd. Takto se i tento model původně prodával, licenční štítek je tedy nalepen na skříni počítače. Chápu tedy, že tento počítač je HARDWAREm jako součástí počítačového systému.
2. Smlouva je uzavřena mezi mnou, tedy koncovým uživatelem a společností Dell Inc., jakožto výrobce počítačového systému. Tedy při porušení smlouvy se zodpovídám společnosti Dell, nikoli Microsoft, jak se spousta lidí mylně domnívá.

Ke konci úvodní kapitoly je vysvětlen pojem POČÍTAČ, takto: "Pojem "POČÍTAČ", tak jak je v tomto dokumentu používán, znamená HARDWARE, pokud je HARDWARE samostatným počítačovým systémem, nebo znamená počítačový systém, s nímž HARDWARE pracuje, je-li HARDWARE součástí počítačového systému.", což si dle předcházející kapitoly vykládám tak, že POČÍTAČ = HARDWARE z předcházející kapitoly + přidané periferie.

V kapitole 1.1 se mimo jiné píše: "Na POČÍTAČI můžete instalovat, užívat, zobrazovat a spouštět pouze jednu kopii SOFTWARU a přistupovat k této jedné kopii.", z čehož vyvozuji, že

1. Existující instalaci je možné ve VirtualBoxu spustit a to pouze tak, že Windows nabootuje do VritualBoxu přímo z disku, jelikož nedojde k vytvoření více kopií Windows. Pochopitelně VirtualBox nesmí běžet na jiném počítači (a spouštět Windows například přes síť), jelikož pak by se už nejednalo o POČÍTAČ definovaný v úvodní kapitole.
2. Naopak není možné vytvořit kopii disku a tu naimportovat jako virtuální disk do VirtualBoxu společně s Windows, protože tím už dojde k vytvoření více kopií, což je v rozporu s tímto odstavcem.

Kapitola 1.2 potvrzuje předcházející tvrzení větami: "Tato licence nesmí být sdílena, přenášena na různé počítače nebo na nich být současně používána. K SOFTWARU se spolu s POČÍTAČEM uděluje licence jako k jednomu nedělitelnému produktu a SOFTWARE může být používán pouze s POČÍTAČEM.", tedy Windows smí být použity pouze na daném POČÍTAČi.

Další kapitoly smlouvy EULA se k problému kopírování a spouštění Windows nevyjadřují.

Voodoo3 akcelerace na ubuntu 9.10

Dnes jsem na počítač s grafickým akcelerátorem Voodoo3 nainstaloval Xubuntu 9.10. Přesto, že Xorg používá ovladač tdfx nefungovala mi akcelerace a spuštění glxgears nebo glxinfo skončilo s chybovou hláškou viz níže.

X Error of failed request:  BadAlloc (insufficient resources for operation)
Major opcode of failed request:  154 (GLX)
Minor opcode of failed request:  3 (X_GLXCreateContext)
Serial number of failed request:  35
Current serial number in output stream:  37

Chvíli jsem pátral po internetu a přes zaručené informace o bugu v xkách nebo v ovladači tdfx jsem se dostal na stránky týpka, který řešil podobný problém. A ten zjistil, že na vině je chybějící knihovna pro glide, uff.

Řešení je tedy prosté, stačí nainstalovat libglide3.

sudo apt-get install libglide3