Нечёткий поиск с Elasticsearch

Что такое Elasticsearch прекрасно описано в wikipedia, поэтому здесь это описывать не вижу смысла. Совсем кратко и на свой лад — замечательная штука для поиска по большой базе (десятки тысяч документов, но не миллиарды) с возможностью нечёткого поиска, т.е. в запросе могут быть ошибки, опечатки, пропуски или даже не та раскладка. Замечательность elasticsearch'а в простоте разворачивания, простоте наполнения базы и простоте поиска.

Перед началом работы нужно установить Elasticsearch из пакетов, либо скачать архив и распаковать. После остаётся его запустить (bin/elasticsearch) и можно смотреть в браузере (http://localhost:9200/) как оно работает.

Для "потестить" можно всё делать через браузер/curl.

Добавление документа
$ curl -XPUT 'http://localhost:9200/test/doc/1' -d '{"name":"имя пользователя"}'
здесь
    test — индекс
    doc — doc_type (можно считать подиндексом индекса)

Поиск
$ curl -XGET 'http://localhost:9200/test/doc/_search?pretty=true' -d '{"query":{"fuzzy":{"name":"плзователь"}}}'
Ну или смотрим в браузере
(pretty=true в запросе просто чтобы в ответ получить json не в одну строку, а нормально отформатированный)


Для работы с Elasticsearch из python'а есть "родной" модуль elasticsearch и сторонний pyelasticsearch. Сторонний появился чуть раньше официального, но с определённой версии работает через официальный (т.е. для работы с ним нужно ставить оба модуля), развивается и дальше и старается быть более pythonic, нежели официальный.

Свой startup script for systemd

Мне для работы удобно использовать виртуалку VirtualBox в качестве виртуального разработческого сервера. Легко конфигурируема, легко переносима, максимально изолированное окружение и в основную систему нет необходимости ставить пакеты, нужные только для проектов. Опять же — никаких конфликтов версий имеющегося ПО. Так как в качестве редактора я использую Komodo Edit, который отлично ходит по SSH, то неплохо бы всегда иметь активную виртуалку, а ответственность за её запуск возложить на кого-нибудь ещё, и не контролировать это дело самостоятельно. Отсюда и возникла необходимость в своём скрипте для systemd:


/etc/systemd/system/virtualbox.centos7.service

[Unit]
Description=VBox "centos7"
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/VBoxHeadless -s centos7 --vrdp=off
ExecStop=/usr/bin/VBoxManage controlvm centos7 acpipowerbutton
RemainAfterExit=no
User=george
TimeoutStopSec=8

[Install]
WantedBy=multi-user.target


Остаётся выполнить 
$ systemctl enable virtualbox.centos7
и виртуалка сама стартует при включении и гасится при выключении компьютера.

OpenSSH 7. Возвращаем авторизацию по ключам

Return simple authorization by public keys

У меня на большинство серверов настроена авторизация по ключам. Удобно — один раз разблокировал связку ключей и ходишь по серверам не отвлекаясь на ввод паролей. Когда пароли на все сервера разные, это действительно удобно.
Но после обновление ssh до 7 версии у меня вдруг постоянно стал запрашиваться пароль при подключении к серверам, как будто никаких ключей и не было никогда прописано. Либо я один с такой проблемой, либо просто обновился рано, но готового ответа нагуглить не удалось, а решается всё просто.
В новой версии добавилась опция PubkeyAcceptedKeyTypes (ссыль), без которой имеющиеся ключи стали игнорироваться.
Идём в /etc/ssh/ssh_config и добавляем PubkeyAcceptedKeyTypes=+ssh-dss . Всё. Опять авторизация по ключам работает.


Проверить причину "неавторизации" можно включением дебага (или verbose) при попытке коннекта:
$ ssh -v hostname

В моём случае в выводе присутствовало:

debug1: Skipping ssh-dss key /home/george/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes

debug1: Next authentication method: password

Dirty tags ;) : ssh ignore keys, ssh want password, enable ssh key logon

How to disable bold font into guake terminal

Жирный шрифт в окне терминала не всегда и не везде выглядит нормально, отсюда и желание многих - отображение шрифта bold'ом запретить. В gnome-terminal (да и во многих других) для этого есть галочка в настройках, хочешь включай жирный шрифт, хочешь - отключай. А в guake почему-то этого нет. Есть патчи, есть примеры, как настройку добавить, но автор добавлять эту мега-киллер-фичу не хочет.
Вот в https://github.com/Guake/guake/issues/168 есть ответ замечательный:

So, yeah, basically, bold works, and I don't see enough motivation to ever allow to disable it.

Раньше я добавлял в guake настройку для отключения bold'а, но там несколько файлов править приходится ручками, патч-то вслепую не накатишь, версия из репозитория дистрибутива обычно отличается немного от версии в репозитории автора. Поэтому решил не заморачиваться, сперва просто захардкодил отключение bold'а, но потом всё же решил оставить возможность изменения параметра через gconf, чтоб не только мне полезно было.

Итак. Всё применительно к Arch'у, в других дистрибутивах путь может немного отличаться.

Правим /usr/bin/guake.

В GConfHandler.__init__ вставляем строку

    notify_add(KEY('/style/font/allow_bold'), self.fallowbold_changed)

у меня она встала на 144 строку, над

    notify_add(KEY('/style/font/style'), self.fstyle_changed)

(я везде новый код добавил над /style/font/style)

Дальше в сам GConfHandler добавляем метод

def fallowbold_changed(self, client, connection_id, entry, data):

    policy = entry.value.get_bool()

    for i in self.guake.term_list:

        i.set_allow_bold( policy )

(я метод вставил над существующим методом fstyle_changed, 257 строка)

Perl, OpenSSL и самоподписной сертификат

В продолжение предыдущей заметки...

Так как кроме получения данных по https со "своими" сертификатами мне эти данные нужно было ещё и обработать, то решил и обработку и получение данных запихнуть в один perl-скрипт. Так как с проблемой "трёх сертификатов в одном файле" разобрался, то не предвидел каких-либо трудностей на этом пути :)

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

Ошибка:

500 Can't connect to www.nekiysite.ru:443 (SSL connect attempt failed with unknown error error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure)

Linux, wget, SSL и самоподписной сертификат

Столкнулся недавно с необходимостью получения данных по https из консоли с использованием клиентского сертификата. При этом и клиентский и серверный сертификаты не от какого-то публичного доверенного центра сертификации.

Задача: имея на "руках" p12-сертификат получить данные с некоего сервиса.

Увы, но wget отказался получать данные, да и вообще устанавливать безопасное соединение. Немного погуглив нашёл множество вопросов по теме, но все имеющиеся ответы на них проблему не решали.

Ковырясь и подбирая варианты запросов получал такие ошибки:

OpenSSL: error:14094413:SSL routines:SSL3_READ_BYTES:sslv3 alert unsupported certificate
Unable to establish SSL connection.

OpenSSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch
Disabling SSL due to encountered errors.

OpenSSL: error:0906D06C:PEM routines:PEM_read_bio:no start line
OpenSSL: error:140AD009:SSL routines:SSL_CTX_use_certificate_file:PEM lib
Disabling SSL due to encountered errors.

Пакетное переименование файлов с транслитерацией имени

Иногда появляется необходимость переименовать кучку файлов разом, чтобы в имени перестали встречаться русские символы. Само собой хочется потом суметь понять где какой файл.
Каждый раз, когда сталкиваюсь с такой необходимостью, колхозю скрипт, который потом успешно теряется и приходится опять чего-то колхозить. На этот раз сохраню здесь получившийся велосипед.

$ perl -MLingua::Translit -le '$tr=new Lingua::Translit("GOST 7.79 RUS");opendir DIR,".";rename$_,$tr->translit($_)for grep{!/^\./}readdir DIR'

Решил в этот раз не заморачиваться с более менее правильным скриптом, переименовал/оттранслитил файлы перловым однострочником.

Принцип работы (вдруг кому пригодится): идём в папку, где лежат файлы, открываем её в терминале и выполняем команду. Однострочник читает список файлов в текущей директории и переименовывает все файлы, кроме тех, чьё имя начинается с точки.

P.S. Предварительно придётся поставить перловый модуль Lingua::Translit

$ sudo cpan -i Lingua::Translit
или
$ sudo cpanm Lingua::Translit
в зависимости от наличия cpan'а или cpanminus'а в системе.

P.P.S. Может быть потом как-нибудь не поленюсь и сделаю нормальный скрипт без лишних зависимостей.

Симлинки в shared папках под VirtualBox

С некоторых пор в гостевой системе под VirtualBox в примонтированной shared-папке нельзя создать симлинк. Связано это с безопасностью и в какой-то версии такую возможность по-дефлоту выключили, но оставили параметр, которым можно это поведение исправить. Какую-то информацию по теме можно подчерпнуть из тикета #10085.
Собственно, далеко не всегда гостевая ОС отдаётся посторонним лицам, которые могут попытаться набезобразничать, иногда VirtualBox ставится для своих нужд, и иногда симлинки действительно нужны и именно в примонтированных папках.

Итак. По-умолчанию при попытке создать симлинк из гостевой ОС в консоли получаем что-то вроде:
$ ln -s some/path/to/dir
ln: creating symbolic link `some/path/to/dir': Read-only file system

хотя файловая система совсем не read-only.

Выполняем
$ VBoxManage setextradata <vm_name> VBoxInternal2/SharedFoldersEnableSymlinksCreate/<share_name> 1

в моём случае это
$ VBoxManage setextradata centos VBoxInternal2/SharedFoldersEnableSymlinksCreate/www 1

Дальше, чтобы убедиться, что настройки сохранились, выполняем
$ VBoxManage getextradata <vm_name> enumerate

и видим появившуюся новую строку с нашей папкой.

Теперь перезапускаем VirtualBox (простого ребута гостевой ОС недостаточно) и спокойно создаём символические ссылки на примонтированной файловой системе.
Если рестарт виртуалбокса не помогает, то можно перезапустить его модули, после этого изменения точно учтутся при старте виртуальной машины.


P.S. Попутно добавлю.
Если при настройке shared-папок в VirtualBox поставить галку на автомонтирование

то система при старте сама будет пытаться примонтировать эту папку (само собой при условии, что установлены vbox guest additions).
Скорее всего дефолтное расположение примонтированной папки не устроит, тогда достаточно просто добавить запись в fstab
<share_name>   /<path/to/dir>        vboxsf     defaults,gid=502,uid=500,dmode=775,fmode=755   0 0
(uid,gid,dmode,fmode можно поправить по вкусу, либо убрать нафиг)

Теперь папка будет в правильном месте. И не нужно писать никаких скриптов для монтирования этой папки и пихать их в автозагрузку...

Resize virtual box virtual-hard-disk-drive

Появилась как-то необходимость увеличить размер virtual-hdd для vitrualbox. На деле оказалось, что ничего сложного в этом нет:

- в virtual media manager в самом virtualbox'е выбирем копирование/клонирование для требующего ресайза "диска"
- hard drive type указываем VDI
- обязательно выбираем динамически расширяемый (или как в рускоязычной vbox это называется) диск, а не фиксированного размера
- в консоли идём в папку, где лежит файл нового "диска" (необязательный пункт)
- выполняем в консоли
   $ VBoxManage modifyhd --resize <new_size_in_MB> disk-name-file
например
   $ VBoxManage modifyhd --resize 10000 disk1,vdi

Всё.
Дальше "подключаем" свежескопированноотресайзенный "диск" на место старого и можем запускать виртуальную машину.

P.S. Само собой разделы на "диске" не изменились, и если требуется не создание нового раздела, а увеличение существующего, то придётся воспользоваться сторонним софтом, благо нет проблем скачать небольшой livecd-образ и загрузившись в виртуалке с него через тот же gparted отресайзить разделы.

DeaDBeeF и пауза при активации screensaver'а

Относительно недавно наткнулся на замечательный аудиоплеер под linux - DeaDBeeF.

First steps in mongoDB

Что такое MongoDB подробно описывать не стану. Упомяну лишь, что это NoSQL документо-ориентированная СУБД.
Вдруг появилась необходимость её использования. В качестве ОС - CentOS:

После обновления до Gnome 3.4 формы в Opera стали выглядеть странно

После обновления gnome до версии 3.4 input'ы и select'ы в "нестилизованных" формах в opera стали выглядеть довольно странно:

Причиной стала обновлённая Adwaita (используемая по-умолчанию theme) со своими стилями. В новых релизах оперы обещают эту проблему пофиксить.
Сейчас же проблема решается через выставление параметра "Dialog Toolkit" в единицу или в четыре. Т.е. открываем opera:config, в поиске вводим "Dialog Toolkit", выставляем требуемое значение, жмём "Save" и рестартуем оперу.

При значении "1" будет использоваться qt (в том числе и диалоги):

При значении "4" будет использоваться gtk

P.S. Решение подсмотрено здесь.

Update:
Opera обновилась до 11.64, но проблема не пропала. Зато после изменений "Dialog Toolkit" при значении, равном четырём, диалоги похожи на Win98, но при значении, равном двум, используется gtk и нормально отображаются формы на страницах.

Couchbase из исходников в arch linux

Появилась необходимость поставить couchbase, а так как под arch покетов нет, пришлось собирать из исходников.
Опишу сам процесс чего делал и чего получалось, есть моменты, которые лучше сразу сделать немного иначе, так что использовать статью как руководство получится только после полного прочтения. Итак, начнём.
$ wget http://packages.couchbase.com/releases/1.8.0/couchbase-server_src-1.8.0.tar.gz
$ tar xzf couchbase-server_src-1.8.0.tar.gz
$ cd couchbase-server_src

В папке уже лежит готовый Makefile, но путь для установки в нём прописан явно :(
Начал собирать (собственно собранное приложение сразу будет скопировано/установлено в указанную в makefile папку)
$ sudo make    # при сборке хочет много доступа, пришлось запускать из под sudo

Почти сразу посыпались ошибки об объявленных, но неиспользуемых переменных, при этом в первом месте ошибки использование переменной было внутри if'а, так что теоретически она могла и не использоваться, но просто убрать объявление переменной уже нельзя... Хорошо, в сообщении об ошибке есть намёк '-Werror=unused-but-set-variable', не помню уже как точно пишется, но как раз про объявленное и неиспользуемое. Так как использоваться результат сборки будет не на проде, сильно не заморачиваюсь и просто заменяю ключ на -Wno-error, чтоб warning'и оставались предупреждениями (а не ошибками).
$ sudo grep -Rl 'Werror' * | grep -Ei 'configure|makefile' | while read i; do sudo perl -i.bak -pe 's/-Werror/-Wno-error/g' $i; done

Сразу оговорюсь - постоянно сидеть под root'ом не люблю, а так как привилегий при сборке надо много, то и часть файлов уже доступны только root'у, поэтому дальше будет много sudo

Запускаю собираться дальше, вроде идёт нормально.
Отвалился при сборке memcached, пришлось memcached собирать отдельно. Он в соответствующей папке, так что
$ cd memcached
$ ./configure
$ make

Возможно, надо будет так же подправить -Werror на -Wno-error

Теперь обратно в couchbase-server_src и пробую дальше собрать. Теперь отваливается на том, что не может найти бинарники memcached. Ага, значит видит, что эта часть собрана и заново не начинает компилировать, но найти результат не может. Ну само собой, я же не указал --prefix при сборке memcached и он установился в саму систему, а не в ту папку, где его ищёт "сборщик" couchbase.
Дальше можно попробовать вычистить установленный memcached и собрать его с указанием правильного пути, либо... Я просто скопировал бинарник в папку, где его не мог найти "сборщик".

Опять запускаю sudo make
Теперь вываливается с ошибкой
"erlang not loading native code for module hipe_unified_loader: it was compiled..."
Немного погуглив и попробовав просто запустить erlang понимаю, что проблема в нём. Нахожу фразу "This was introduced in a change to the Erlang VM PKGBUILD for R14B04, which added the -enable-native-libs compile flag". Ясно, удаляю erlang, который поставился из репозитория, ставлю его из AUR. На всякий случай собрал пакет и с этим ключом и без него, установил тот, который был "с ключом".

Теперь наконец-то make доводит своё дело до конца. А я обращаю внимание, что couchbase собрался в /home/george/downloads/couchbase-server_src/install. Да, не самое удачное место для софта. Надо было, на самом деле, для начала попробовать просто скопировать содержимое этой папки куда-нибудь в /usr/share/couchbase и затем поправить все пути в конфигах... Но я (собрал же уже один раз) решил пересобрать всё предварительно изменив путь в makefile'е.

Увы, с ходу всё собираться не захотело и полезли новые ошибки :(
Ладно, решил ставить в /opt/. Распаковал исходники туда, указал в makefile путь /opt/couchbase, изменил -Werror на -Wno-error, запускаю
$ sudo make
Опять не собирается memcached. Не собирается и индивидуально из своей папки, вываливает ошибки типа
mv $(DEPDIR)/example_protocol_la-example_protocol.Tpo $(DEPDIR)/example_protocol_la-example_protocol.Plo
can't stat $(DEPDIR)/example_protocol_la-example_protocol.Tpo, no such file or directory
(пишу по памяти, так что могут быть не точности, но смысл должен быть понятен).

В m4 я не силён, не знаю почему .Tpo переименовываются в .Plo ещё до выполнения этой строчки, так что решаю простым добавлением конструкции
if test ! -f <файл>.Tpo; then cp <файл>.Plo <файл>.Tpo; else :; fi
в memcached/Makefile
Хорошо, что в vim'е макросы записывать просто и добавить такую конструкцию пришлось пару раз, во все остальные места vim добавил её сам.

Пересобирал ещё раз и просто в Makefile заменил строку `am__mv = mv -f` на `am__mv = cp -f`, чтобы он не ругался на отсутствующие файлы...
После этого memcached собрался нормально.
опять sudo make в couchbase-server_src и ошибка
"configure: error: `CPPFLAGS' was not set in the previous run"
Хм. Вижу в самом конце вывода "make[1]: Leaving directory `/opt/libvbucket'"
$ cd libvbucket
$ sudo ./configure --prefix=/opt/couchbase --disable-static --enable-shared --without-docs --no-create --no-recursion       # доп. ключи - это из последнего, что было в stdout перед ошибкой
$ sudo make
$ cd ../
$ sudo make

Дальше аналогичные ошибки для memcachetest и moxi. Решаются таким же образом, ключи для configure так же вываливаются в stdout перед сообщением об ошибке.

couchbase собрался.

UPD: Собрался, но запускаться отказался :( . Буду думать дальше...

OpenSUSE 11.4 и Samba

После обновления openSUSE до 11.4 столкнулся с неприятной особенностью - samba ни в какую не хочет работать. Настраивал и правкой конфига, и тыканием мышкой в ясте - самба настроена, всё указано правильно, но не работает. Просто не запускается ни в какую и всё тут. Запустив в interactive режиме получил ругань, что permission denied при попытке открыть secrets.tdb и passdb.tdb. И это при том, что самбу запускал из под рута и при debug level 3+ (третий и выше) она честно писала, что работает от имени uid=0.
Оказалось, всё дело в apparmor. Видимо, разработчики/мейнтейнеры openSUSE где-то недоглядели и по дефолтным профилям apparmor ограничивал доступ самбы к этим файлам. По-быстрому объяснить apparmor'у, что к этим файлам обращаться можно, не получилось, поэтому просто снёс его профили, касающиеся самбы. По-дефолту лежат здесь - /etc/apparmor/profiles/extras/.