Equin0x Feb 26 2013 at 19:05

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

5 min

15K

Последние годы, с интересом почитывая о персональных поисковых системах в веселых желтых коробках имени 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'.

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

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

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

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

Tags:

Hubs:

Search engines