GSA: Препарируем Google Search Appliance в виртуальной машине

Последние годы, с интересом почитывая о персональных поисковых системах в веселых желтых коробках имени Google, я периодически гуглил по словам GSA, Google Search Appliance, reverse engineering и, чего греха таить, hack, DIY, disk dump и т.п. Но ничего, кроме официальных пресс-релизов и переписки счастливых (?) обладателей с группой поддержки, я не встречал.

Иногда звучали на форумах робкие вопросы вроде «а как бы рута мне получить» или «попасть в GSA по ssh», но на все подобные вопросы ответ был один — только группа поддержки Google знает пароли. И никому не скажет. Удивительно, но я не встречал в интернете никаких попыток собрать «хакинтош» на движке Гугла, или по живому коду разобраться в алгоритме ранжирования страниц.

Ситуация слегка изменилась в 2008 году, когда на волне эйфории от виртуализации, Google выкатил VGSA – бесплатную виртуальную машину для Vmware с ограниченной до 50 тысяч документов лицензией. Впрочем, особого энтузиазма это в интернете не вызвало, в 2009 году проект был свернут и большинство ссылок в Гугле на VGSA стали возвращать 404 (заметьте – самим же Гуглом). Ссылку на релиз от 2008 года можно найти довольно легко. Ссылка на версию 2009 сохранилась лишь на паре китайских сайтов.

О том, как я поставил vgsa_20090210 на ESX 5.1 и увидел много чего интересного, можно прочитать ниже.

Пара слов о Google Search Appliance

GSA – это карманная поисковая система, способная индексировать сайты, любые документы и базы данных. Позиционируется как локальный Google для крупных компаний, которые хотят иметь свой локальный специфический поиск, но никому его не показывать (или показывать). Сама коробка – это молотилка, которая индексирует не только указанные в настройках URL-ы (http://, smb://), но и любые данные (Oracle, MySQL, etc), которыми ее можно накормить через API. Набивание GSA данными, помимо собственного http/smb паука, производится через так называемые коннекторы с открытым кодом, написанные под различные базы данных и файловые системы. Они свободно доступны через Google Code и управляются посредством Connector manager.

Установка

VGSA виртуальная машина собрана на базе CentOS 5 Final. После распаковки архива мы получаем стандартный набор vmx/vmdk файлов для Vmware Player. Так как версия уже устарела, поставить ее на ESXi 5.1, через Vmware Converter, не получилось. Была создана новая VM с базовыми настройками для Redhat 5 32b, 2 Gb памяти и мелким диском, который был тут же удален и подменен vmdk из VGSA (подключен как SCSI parallel BusLogic). Update: в комментариях пишут, что прекрасно запускается в VmWare Workstation 8.

После стандартного LILO пошла загрузка и появилась первая настораживающая надпись про шифрование:



Далее VGSA получила адреса по DHCP и появился ее стандартный экран:



По предложенному URL обнаружился нормально работающий гугловский движок, готовый к настройкам (с лицензией на 50 тыс. документов):



Для проверки проиндексировал первые 100 страниц хабра, со стандартной гугловской тактикой — 4 процесса на один домен/сайт. Краулер обходит все внутренние ссылки, а механизм индексации параллельно сортирует мусор и дубликаты. Одновременно это все ранжируется, считаются ссылки на страницу и из нее, каждой странице присваивается свой PR относительно корня (корень сайта всегда PR10) и тп.



Создав коллекцию интересных для меня сайтов (влкючить индексирование картинок пока не решился), быстро понимаю, что лимит в 50 тыс. страниц — это очень мало. Пора заглянуть под капот…

Под капотом

Пойманный на shift LILO, при любой попытке задать параметр просит пароль:



Еще раз беру дистрибутивный образ диска и смотрю его структуру. Fdisk ругается на незнакомый GPT, пробую parted:

[root@server /]# parted /home/vgsa/vgsa-flat.vmdk
GNU Parted 1.8.1
Using /home/storage/azureus/vgsa-flat.vmdk
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit b
(parted) p

Model:  (file)
Disk /home/storage/azureus/vgsa-flat.vmdk: 36507222015B
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start        End           Size          File system  Name          Flags
 1      17408B       2147484159B   2147466752B   ext3         /
 2      2147484160B  4294967807B   2147483648B   linux-swap   swap
 3      4294967808B  36507205119B  32212237312B  ext3         /export/hda3

(parted)

Первый раздел стартует с 17408. Монтируем его:

# mount -t ext3 -o loop,rw,offset=17408  /home/vgsa/vgsa-flat.vmdk /mnt/vgsa

и получаем корень VGSA — пока без главного раздела /dev/hda3.
Смотрим lilo.conf на предмет пароля:

# grep pass /mnt/vgsa/etc/lilo.conf
password=cmBalx7

Теперь грузимся с init= /bin/bash, перемонтируем корень в rw (mount -o rw,remount /) и меняем пароль.
Заодно можно поправить iptables. В главном конфиге системы /export/hda3/5.2.0/local/conf/google_config есть параметр ENT_LICENSE_MAX_PAGES_OVERALL, который отвечает за максимальное количество проиндексированных страниц. Пробовал первое, что пришло в голову: telinit 1, поменять ENT_LICENSE_MAX_PAGES_OVERALL на 50 миллионов, затем sync и reboot. Удивительно, но система взлетела и показала новый лимит…

Вкратце об интересных местах, на которые пока не хватает времени:

/export/hda3/5.2.0/local/google3/quality/, а именно rankboost/indexing/rankboost_cdoc_attachment_pb.py:

Там есть очень интересный момент:

   self.link_count_ = 0
    self.offdom_link_count_ = 0
    self.paid_link_count_ = 0
    self.ppc_link_count_ = 0
    self.page_blog_score_ = 0
    self.page_wiki_score_ = 0
    self.page_forum_score_ = 0
    self.page_ppc_spam_score_ = 0
    self.has_link_count_ = 0
    self.has_offdom_link_count_ = 0
    self.has_paid_link_count_ = 0
    self.has_ppc_link_count_ = 0
    self.has_page_blog_score_ = 0
    self.has_page_wiki_score_ = 0
    self.has_page_forum_score_ = 0
    self.has_page_ppc_spam_score_ = 0

— много известных факторов ранжирования, но кое-что новенькое все же есть. Я подозревал, что рекламная PPC кампания может принести как пользу, так и вред в органической выдаче. В приведенном фрагменте видно, что Гугл учитывает поведение PPC кампаний. Пока остается только гадать, что такое PPC spam.
Много интересного в /export/hda3/5.2.0/spelling/. С форматом пока не разобрался, но навскидку – там базы Гугла по синонимам и спряжениям на разных языках. Там же коллекция стоп-слов и масса весьма забавных фильтров, иногда отдающих маразмом:

en.spelling.filter.dnc.utf8:#  Prevent correcting 'aryan' to 'jewish' or 'arabic'.

Вместо эпилога

Общее впечатление от внутренностей — не однозначное. Сделано на питоне, судя по всему часть обычный скрипт, часть скомпилированный код. Система все же больше похожа на набор костылей скриптов, чем на законченный солидный продукт. Тем не менее, это все довольно шустро работает и, наблюдая за загрузкой процессора во время активной индексации большого сайта — достаточно эффективно.

Теперь, когда система из черного ящика превратилась в по-настоящему желтый — несколько мыслей о возможном ее применении:

1. Понятен интерес с точки зрения SEO.
2. Локальный поиск для сайта, когда система индексирует только один сайт и является мощной системой внутреннего поиска (например через iframe).
3. Было бы интересно расширить функционал — например ввести в админе фильтр по ключевым словам. Чтобы спайдер собирал только страницы, в которых присутствуют определенные слова или фразы.
4. Уверен, что это можно запустить и на железе, возможно с небольшим напильником в руке.
5. … или в OpenVZ контейнере.
6. … придумайте сами.


С удовольствием выслушаю ваши мысли по этому поводу.