Unterwelt

Кастомизация виртуальных машин в Vagrant

2014-02-23T21:38:00.000+04:00

Введение

Vagrant является удобной утилитой для быстрого развертывания виртуальных машин (для разработки, тестирования и т. п.). В 1 версии в качестве системы виртуализации поддерживался только VirtualBox. Во второй версии появилась поддержка иных систем виртуализации (например, VMware, облачных провайдеров типа Amazon, Rackspace и т. п.). Более-менее полный список можно посмотреть на github'е.

Из приятных моментов стоит отметить, что есть большое количество готовых сборок виртуальных машин. Загрузка такой сборки -- довольно тривиальное занятие, описанное на сайте vagrantbox.es.

vagrant box add precise64 https://dl.dropbox.com/u/14292474/vagrantboxes/precise64-ruby-1.9.3-p194.box
mkdir test-box && cd test-box
vagrant init precise64
vagrant up

Кастомизация

В случае vagrant'а существует два совершенно различных подхода к кастомизации:

использование SCM-систем (puppet или chef)
сборка нового образа системы

В некоторых ситуациях более удобен первый подход, в некоторых -- второй. Оставляя за кадром SCM и provisioning с использованием chef и puppet, рассмотрим второй подход. И подводные камни, встречающие нас на нём.

Пересборка box'а

В любой момент текущий образ виртуальной машины vagrant может упаковать в box-контейнер. На самом деле это обыкновенный tar.gz, в котором лежат Vagrantfile и необходимые системе виртуализации компоненты (в случае VirtualBox -- диск в формате vmdk, файл экспорта настроек виртуальной машины ovf; в случае LXC -- образ rootfs и конфиги LXC etc).

В текущий момент автоматизированная пересборка box'а возможна только для машин, использующий VirtualBox в качестве провайдера виртуализации.

После подготовки виртуальной машины (установка необходимого софта, конфигов, создание пользователей и т. п.) достаточно выполнить

vagrant package --output=<some-box-file-name.box>
vagrant box add <box-name> <some-box-file-name.box>

По окончанию операции будет импортирована полученная сборка. Теперь на её основе можно создавать новые виртуальные машины командой vagrant init <box-name>.

Подводные камни

Без них бы не появилась статья. Vagrant активно использует VirtualBox Guest Additions. Для проброса портов, монтирования общих директорий между хостом и гостевой машиной.

А guest additions требуют пересборки в случае обновления ядра. При этом, необходимо загрузить виртуальную машину с новым ядром, после чего выполнить команду

/etc/init.d/vboxadd setup

В общем случае она может сообщить о невозможности собрать часть компонентов (например, интеграция Xorg/X11, если они не установлены). После чего надо перезагрузиться и проверить, что VirtualBox Guest Additions, представленные модулями ядра и демонами запущены.

Убедившись, что всё работает можно-таки паковать новый box.

P. S. Описание этой проблемы можно найти в документации к 1 версии (в разделе troubleshooting). В актуальной версии vagrant 2 оно не находится.

P. P. S. Статья в оригинал публиковалась на хабре, но сейчас в черновиках.

2012-01-15T01:29:00.001+04:00

Зная про тулзу для двухфакторной аутентификации в гугле с использованием yubikey, решил реализовать аналогичную вещь и в linux. Удобства ради решил использовать python-yubico, предоставляющую нормальный интерфейс. И увидел прелестный пакет python-yubico-tools, в котором и была найдена утилита yubikey-totp. Неприятной неожиданностью стало то, что код, возвращаемый этой утилитой не соответствовал тому, что возвращал google-authenticator или моя прога на python'e, реализующая totp из rfc6238. Основное, что следует помнить про g-a, что он хранит ключ в base32, а большинство библиотек хотят шестнадцатеричное представление. Но это не вызывает проблем. Опасаясь, что косяк мой -- с загрузкой ключа в yubikey (нужен в обычном шестнадцатеричном виде с паддингом нулями), проверил на ключе из вышеупомянутого rfc. И увидел, что всё нормально. С другой стороны yubikey-totp с параметром --time давал тот же результат, что и написан в стандарте. Меня озадачило это поведение. Как выяснилось при дебагге, эти товарищи умудрились использовать

int(time.mktime(time.gmtime()))

что при tz отличной от +0000 давало не время от начало Эпохи, а его же с поправкой на временную зону. Т. е. на компе с tz MSK (+0400) это число было на 4 * 3600 меньше текущего unix-time. Почему эти странные "товарищи" не воспользовались куда более очевидным

int(time.time())

мне не ведомо. Написал в соответствующую гуглогруппу, посмотрим.

hg & git. Как унифицировать workflow.

2011-01-24T03:06:00.000+03:00

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

Сначала кратко об идеологии данного подхода. Фактически краткий перевод оригинальной статьи.

Ветка master (default) содержит только релизы.
Ветка develop предназначена для интеграции (содержит готовые фичи, в неё же вливаются багфиксы).
Ветки release-* являются freeze-ветка для подготовки к релизу. В момент создания этой ветки в develop должен быть только набор фич, которые войдут в релиз. В конце жизненного цикла ветка вливается в master (default), выпуская релиз. Также эта ветка вливатся в develop, внося багфиксы.
Ветки hotfix-* начинаются от релизов и возвращаются в релизную ветку для внесения исправлений. Также ветка вливается в develop.
Ветки для разработки новых фич начинаются от develop и возвращаются на неё же.

Картинка отсюда.

В случае git'a всё реализуется очень просто. Ветки легковесные, удалять их по истечению необходимости не проблема. Чего не скажешь о hg, где веток несколько типов.

В mercurial для этих целей подходят две: именованные ветки (named branches) и метки (bookmarks).

Основное отличие в том, что bookmark - легковесная ветка, наиболее близкая к git'овским. Она хранится в репозитории, как указатель на последнюю ревизию. А named branch - пишется в коммит и является его частью.

Подход с именованными ветками обладает тем недостатком, что для того, чтобы не образовывалось много голов надо очень аккуратно сливать и вовремя удалять эти ветки (перед последним слиянием). А поведении bookmark'а более похоже на поведение ветки в git (если проставить свойство track.current = True в разделе [bookmarks] в hgrc). Недостаток - что нельзя слить, если не было коммитов после ответвления. В таком случае можно сделать аналог fast-forward, что не является необходимым поведением. Это происходит из-за того, что bookmarks - всего лишь легкие метки над анонимными ветками.

Получилось несколько сумбурно, потом подредактирую.

Осторожно. Телефонное мошенничество.

2010-11-22T01:46:00.000+03:00

Вечером получил смс следующего содержания: "Вам пришло MMS, просмотр с мобильного - http://j.mp/bHZxO9".

Переходим, получаем редирект на скачивание

HTTP/1.1 301 Moved
Server: nginx/0.7.67
Date: Sun, 21 Nov 2010 21:06:27 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Set-Cookie: _bit=4ce989d3-000d4-02065-d8ac8fa8;domain=.j.mp;expires=Fri May 20 17:06:27 2011;path=/; HttpOnly
Location: http://fastmms.ru/bee/per7097.jar
MIME-Version: 1.0
Content-Length: 295

Естественно, сайт-однодневка, с него получаем jar-ник

HTTP/1.1 200 OK
Date: Mon, 22 Nov 2010 05:40:20 GMT
Server: Apache/2
Last-Modified: Mon, 22 Nov 2010 04:56:25 GMT
ETag: "eb8007-21d4-4959d14033040"
Accept-Ranges: bytes
Content-Length: 8660
Vary: Accept-Encoding,User-Agent
Keep-Alive: timeout=1, max=100
Connection: Keep-Alive
Content-Type: application/java-archive

Из манифества этого jar-ника можно почерпнуть, что он очень хочет javax.wireless.messaging.sms.send - отправлять смски =)

Скачав и запустив этот мидлет вы отправите сообщение на прелестный номер 844473 с текстом "p:60 n:9233187097", т е пополните некому абоненту мегафон-сибирь баланс на 60 рублей. И так, пока не закончатся деньги ,))
Для удобства между отправкой смс будут выдерживаться задержки, чтобы выглядело, как реальное отправление.

Это было выявлено при чтении декомпилированных class-файлов.

Пришло все с номера +79131841672.

"The Raven" by Ricardo de Montreuil

2010-04-28T03:12:00.003+04:00

git-svn. Проблема отката svn-репозитория

2010-04-13T14:45:00.002+04:00

Введение.

После ошибки при dcommit'е в svn из git-репозитория пришлось откатить svn из бэкапа. Далее git-svn отказывался выполнять dcommit, т к в git-репозитории номер коммита выше, чем в svn (который был восстановлен).

Предыстория.

Возникла необходимость совместной разработки. Так как с DVCS я толком знаком не был, решил использовать svn. Просто, удобно. Легко обучить человека, который систем контроля версий не видел ни разу.
Разработка под винды, соответственно, выбран консольный svn + tortoiseSvn (лишний раз svn status набирать не надо, все такое).

В какой-то момент пришлось дорабатывать систему на стенде, где сети уже не было. А VCS хотелось. Выбор пал на git, хотя, наверное, тогда стоило обратить внимание на mercurial.

git-svn.

git-svn прекрасно подцепился к репозиторию в сети, выкачал некоторое количество коммитов и прекрасно работал. До тех пор, пока не добавил нечаянно файл с русским именем.
git не испытывал никаких сложностей с этим. Зато на очередном git-svn dcommit svn не оценил такой шутки и остановился на коммите с кривым именем файла. Пришлось откатить svn из бэкапа.
Во избежание повторения баги этот файл был вычищен из истории (той, что не было в svn, ессно, т к в репозитории теперь номер ревизии ниже, чем считает git).

Дальнейшие попытки выполнить git-svn dcommit привели к провалу. git считал, что пора заливать 137 коммит, а svn - 118. Все это происходило в git версии 1.6.3 (текущей в ubuntu 9.10). Попытки исправления метаданных руками не помогли.

Решение.

Прочтение man'а помогло не сильно. Решив поискать решение в сети, наткнулся на man новой версии.

В новом релизе 1.7.0 появилась прелестная команда git-svn reset -rXX позволяющая откатить метаданные до соответствующей ревизии.

Итак, запускаем git-svn reset -r117, git рапортует, что refs/remotes/git-svn соответствует ревизии 117 и прочие прелести.

После этого можно спокойно делать git-svn fetch, чтобы обновить refs/remotes/git-svn. И git rebase --onto remotes/git-svn <upstream> <branch>, чтобы перенести ветку на новое дерево.

В принципе, все.

Возможно, статья поможет тем, кто попал в аналогичную ситуацию и не смог найти адекватного решения в сети.

P. S. Это то, что не прошло-таки модерацию на хабре..

ТруЪ-евый апокалипсис

2010-04-11T17:40:00.001+04:00

gitosis на домашней машине.

2010-04-10T23:28:00.001+04:00

Поднял сервак gitosis (реализует доступ к git-репозиториям через ssh с контролем доступа). Для этого спокойно воспользовался описанием http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way.

На этой же машине поднят клиент dyndns (ddclient или inadyn). Так, конечно, есть удобная опция "custom dns", позволяющая поставить ttl и обновлять некоторые поля с помощью dyndns-клиента. Получится запись вида (на своем, подконтрольном домене):

git    60    IN A    xxx.xxx.xxx.xxx

Но стоит это удовольствие $30.

Есть красивый обходной путь. На бесплатном аккаунте dyndns free привязываемся к домену 3 уровня. Например, my_git_example.dyndns.org. Далее на своей DNS'ке добавляем

git    IN CNAME    my_git_example.dyndns.org.

Тогда по адресу git.our_domain.tld мы получим доступ к нашему git-репозиторию.

Вот и все дела ,)

Город теней.

2010-04-03T06:41:00.001+04:00

Наконец-то, добрались. Прошло уже целых 10 месяцев. Время летит, к сожалению.

Пока еще не рассвело, город теней и лунного света. Как его портит реклама и уличное освещение. Может, успеем в Петропавловскую крепость до рассвета. Было б забавно.

Жалею, что не взяли роллы, народ уже катает. И в МСК, и в СПБ. Хотя, можем успеть побольше музеев посмотреть, поменьше по городу покатать. На все времени не найдешь.

За всеми безумными делами и не замечаешь, как оно утекает сквозь пальцы. Распыляешь его на то, на сё. Прочитал очередной роман Желязны/Бестера/Саймака/et cetera - хорошо. А стоило б почитать "Code complete", patterns, библию java. Оглянуться на c#/mono. Поглазеть на python. Рассмотреть GAE+GWT ~~корпорации зла~~google.
Чего-то меня совсем не в ту степь занесло. Пока "можно пить и веселиться, не работать и не бриться" ,)

С днем геолога =)

С доменом разобрались..

2010-03-22T20:40:00.000+03:00

Закончилось на сегодня все прозаично.. whois. Прислали мне ссылочку на этот whois-serv. При необходимости переноса домена другого регистратора (по словам техподдержки) они чинно-мирно выдадут мне secret code. Осталось понять, зря или нет я указал там левый телефон?

Завел твит

2010-03-22T15:42:00.000+03:00

Посмотрим, что из этого выйдет..

Доменные развлечения

2010-03-22T15:25:00.001+03:00

Зарегал себе домен в NET. Теперь развлекаюсь. Пока привязал к нему этот блог. Вся регистрация на leaseweb.com заняла чуть больше суток (нерабочие дни были) + написание одного письма, на которое они сегодня утром ответили. Единственное, что смутило - в качестве администратора домена фигурирует "KEY-SYSTEMS GMBH". Жду когда ответят. Как ни странно, домен уже поднят и работает, а зарегистрирован будет только 01/04. Может тогда там и появятся мои данные. Посмотрим.

ох, кеды-кеды

2010-02-16T23:25:00.001+03:00

Недавно решил еще разок глянуть на 4 кеды (пока еще 4.3).. посмотрел-посмотрел, решил что лучше я процессорное время и память буду тратить на что-нить другое.. при всей "навороченности" это дело тормозит на двухядерном селероне с 2Гб памяти.. гном, конечно тоже не так, чтоб лековесен, но все же даже с компизом, прозрачностью, всякими приятными эффектами по сворачиваю/разворачиванию/появлению/изменению окон, тенями и др. развлечениями работает куда быстрее, чем кеды с десятком виджетов. Так у меня и останется в качестве основного - гном/xfce, а легкого - dwm =) в dwm надо поковыряться поподробнее.. просто для работы в dwm+dmenu его реально надо чуток поковырять.. зато весь dwm - это dwm.c + config.h + Xlib(который, ессно, есть с иксами). работать-то он и без этого прекрасно будет, но для удобства - хочется улучшить. воть такие пироги с котятами..

шуточки..

2009-12-28T20:31:00.000+03:00

Овощное

2009-12-23T23:35:00.001+03:00

Состояние, к сожалению, описывается исключительно этим термином.

Сессия ползет очень неравномерно. Иногда по двое суток жесткого напряга, иногда - день почти ничегонеделанья. Вынужденного лишь отчасти.
Кажется, что какие-то разрывы в мировосприятии связаны исключительно с сессией/работой, которые очень неудачно наложились. Плюс к этому еще и моя помощь окружающим приводят к дополнительному недосыпу. Друзья-товарищи, не обижайтесь, я не жалею времени потраченного на общение с вами =)
Когда-таки оказываюсь в сети, натыкаюсь на разные интересные, странные и всякую дребедень. И начинаю засыпать. Aus.

Origin

2009-12-23T09:35:00.000+03:00

В начале было Слово. Потом появился байт.