Этот пост будет посвящён тому, как на Ubuntu Server 12.04 развернуть боевой (хотя и не приспособленный к высоким нагрузкам) свервер для Ruby On Rails приложениq. Почему, собственно, RoR? Есть ведь много других средств для веб-разработки, в том числе более популярных (Wordpress и Drupal на LAMP) и не менее прогрессивных (например, Django под Python).

Отвечу кратко и честно: до Django я пока не добрался, но, в силу обстоятельств, недавно пришлось поднимать Rails-сайт на голом сервере с нуля (ни разу прежде не встречавшись с Rгин On Rails и с Ruby в вообще). Задача эта вылилась в бессонную ночь, а потом в увлекательный день, в течение которого я от души поковырялся в азах новой для себя технологии. Пол сравнению с привычным для меня и любимым мной Drupal`ом я увидел в Ruby On Rails, прежде всего, принципиально новую идеологию.

Очевидные для меня плюсы:

1. Быстрый и лёгкий деплоймент (переход от разрабатываемой версии к «боевой»).
2. Миграции базы данных, которые можно взять под версионный контроль. Любые изменения в схемах данных можно с лёгкостью накатывать и откатывать назад.
3. Огромное количество средств в рамках фреймворка для генерации типового кода (почти не приходится создавать руками файлы и заготовки функционала).
4. Строгое следование подходу MVC при проектировании (модель-вид-контроллер) при построении приложения. Не считаю подход идеальным и единственно возможным, но подобная типизация здорово упрощает поддержку «чужих» проектов. Заранее ясна глобальная логика любого приложения.

На мой взгляд, этого вполне достаточно, чтобы уделить внимание Ruby On Rails.

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

В Ubuntu логи ошибок MySQL хранятся в файле /var/log/mysql/error.log. Но открывать его текстовым редактором на удалённой машине — опасно. Если у вас не настроена ротация логов, то файл может весить сотни мегабайт. Но даже если и настроена, то при падении MySQL мог основательно нафлудить в файл (и он, как следствие, всё равно может быть немаленьким). Поэтому изучать свежие логи будем с помощью утилиты tail, которая выводит несколько (по умолчанию, 10) последних строк указанного файла.

Зачем такое может потребоваться? Два самых ярких примера:

1. Есть у вас домашний сервер, работающий на балконе, спрятавшийся за коробками и не вскрывавшийся 2 года. Хочется добавить в него памяти, а вы уже и не помните там DDR 1, 2 или 3. Лазить в сервер дважды (до покупки памяти и после) — не хочется.
2. Заказали вы где-нибудь в Германии мощный выделенный сервер, но решили проверить немцев: действительно ли в вашу машину поставили достойное железо или обычную десктопную материнскую плату.

В обоих случаях вам потребуется программное средство в виде консольной утилиты для инвентаризации аппаратного обеспечения Linux-машины. И такое средство — существует.

Если вы настроили авторизацию по ключу, но удаленный сервер при входе продолжает с вас упорно требовать пароль, то отправляйтесь смотреть логи на удалённом сервере:

tail /var/log/auth.log

Если там встретите ошибку Authentication refused: bad ownership or modes for directory, то это означает, что беда в правах на папки и файл с разрешенными ключами. Далее обсудим, какие права необходимо установить.

И вот недавно, в начале мая 2012 года, он вышел — свободный графический редактор GIMP 2.8, охарактеризовать который можно коротко так: теперь одноконный режим появился и в стабильной мажорной версии. По умолчанию, впрочем, при запуске включается привычный для смирившихся пользователей многооконный интерфейс, но перевести его в однооконное состояние можно без всячеких мучений, парой кликов, заглянув в пункт главного меню «Окна».

Вообще, такое можно было сделать уже давно (например, в релиз-кандидате), но с выходом GIMP 2.8 ожидаемая фича наконец-то закрепилась в стабильной версии (которая, кстати, неоднократно переносилась, GIMP 2.8 собирались выпускать чуть ли не летом 2011 года). Однако, этот новый релиз настолько свеж, что в Ubuntu 12.04 Precise Pangolin — не попал, а значит придётся новый GIMP ставить руками.

Установка не самая сложная (поскольку существует готовый репозиторий с GIMP 2.8), но есть в ней один неприятный нюанс: чтобы новый GIMP встал ровно надо удалить принудительно конфликтующий кусочек старого.

1 сентября вышла первая бета-версия Ubuntu 11.10 (после трёх альфа-релизов). Вторая бета ожидается 22 сентября, а финальный релиз — 13 октября. RC намечен на 6 октября, но теперь релиз-кандидаты особо не пиарятся, хотя порой они бывают настолько стабильны, что устанавливать смело можно даже их.

Нас ждут следующие фичи:

• Ядро Linux версии 3.0.3.
• Unity с легковесным вариантом в виде Unity2D.
• Новый и последний GNOME 3+ (который можно будет поставить вместо Unity).
• Экран логина на базе LightDM вместо прежнего GDM.
• Thunderbird в роли дефолтного почтового клиента. Закончилась эра Evolution. Я вижу основную силу Thunderbird в том, что с ним ещё проще мигрировать с платформы на платформу: начинающие пользователи могут заранее «привыкнуть» к нему на Windows, а потом переехать на Ubuntu вместе с профилем и почтовой базой. Как минимум, браузер, почтовый клиент и офисный пакет теперь отвязаны от ОС и могут сопровождать пользователя при переходе с Windows на Ubuntu (или, вдруг, обратно). Для офисных работников появляется возможность бесшовной миграции (сначала начинаем использовать новый софт на Windows, потом переходим на Ubuntu, но с уже освоенным софтом, без потерь настроек, данных и пр.).
• Новый и последний LibreOffice.
• Фича Multiarch, дающая лучшую поддержку 32-битным приложением, при их запуске на 64-битной платформе.

Наверняка, о чём-то я забыл упомянуть. Но, в целом, есть чего ждать.

Ситуация проста: на новый и очаровательный сервер с Ubuntu 10.04+ и современным PHP 5.3, пригодным для всех актуальных версий CMS, вдруг требуется подселить старый-старый сайт, начинающий сыпать ошибками при попытке запуска на PHP 5.3 (подавай ему чего-нибудь постарше, например, PHP 5.2). Кто виноват — понятно. Но что делать?

Не паниковать! На одном сервере с одним Apache2 прекрасно заводятся и соседствуют PHP 5.2 (через fastcgi) и PHP 5.3 (как модуль Apache2). Мы далее решим проблему так, что указать какой именно PHP использовать можно будет на уровне настроек виртуального хоста.