Однострочники — это конвейеры из команд для выполнения каких-то полезных операций. По-английски они называются one-liners. Разбираться в них тяжелее, чем в обычном многострочном скрипте, но зато их удобно применять и легко отлаживать (не надо постоянно пересохранять файл). Я поделюсь несколькими однострочниками (из тех, что приходилось использовать недавно или регулярно), по возможности расскажу из чего они составлены. И буду со временем дополнять этот пост. Помогайте мне в комментариях.

Занимаясь веб-разработкой мы часто сталкиваемся с такой типовой задачей: надо забрать с клиентского хостинга сайт, что-то там покрутить, вернуть обновлённую версию обратно. При этом клиентские виртуальные хостинги бывают разные: не на каждом есть SSH или SFTP доступ. Зато старый пыльный FTP есть везде. Если задача простая и затрагивает 1-2 файла, то их «забирает» напрямую программист к себе в IDE, редактирует и выгружает обновления на боевой хост, благо современные IDE снабжены FTP-клиентами. Но если задача требует экспериментов или тестирования, то на боевом клиентском хостинге её решать нельзя стыдно, надо делать «зеркало» у себя. А значит необходим удобный инструмент, позволяющий забрать файлы сайта к себе на сервер по FTP и потом выгрузить их обратно. Задачу блестяще решает консольный FTP-клиент lftp.

Этот пост будет посвящён тому, как на 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 10.04+ и современным (когда-то) PHP 5.3, пригодным для всех актуальных версий CMS, вдруг требуется подселить старый-старый сайт, начинающий сыпать ошибками при попытке запуска на PHP 5.3 (подавай ему чего-нибудь постарше, например, PHP 5.2). Кто виноват — понятно. Но что делать?

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

Эта статья была обновлена до актуального состояния. В частности, ссылки на PHP 5.2 тут рабочие (он переехал в музей старых версий). Мануал не годен для Ubuntu 13.10, поскольку там при сборке php не удаётся подцепить libjpeg62. В общем, коли уж вам приходится заниматься некрофилией, то выбирайте для этого и систему постарее (разумеется, в отдельной виртуалке или на отдельном ни на что более не годном VPS).

Вообще, я обо всём об этом уже писал. Но тема акутальности не потеряла. К тому же, появилось совсем уж простое техническое решение для Ubuntu 10.04+. Но начну с краткого ликбеза, потому что в целом вопрос, о котором речь пойдёт далее, из тех, что рекомендуются новичкам к скорейшему изучению. Итак, незащищённое http-соединение опасно тем, что любой, кто слушает (снифает) трафик, прекрасно видит все пароли, которые вы отсылаете на сайты вместе с логинами по протоколам POST или GET. Заниматься таким могут злоумышленники или, например, обезумевшие админы вашего провайдера.

Зато, если соединение с удалённым сервером устанавливается по протоколу https (с использованием для шифрования данных SSL сертификата), весь перехваченный трафик злоумышленникам — не пригодится, потому что ваши запросы к серверу и его ответы вам — зашифрованы (а расшифровка, в общем случае, архисложна или невозможна).

SSL сертификат это набор средств, которые позволяют шифровать передаваемую информацию открытым ключом (так, чтоб расшифровал только получатель) и однозначно идентифицировать владельца сертификата (для защиты от фишинга: злоумышленники не смогут подделать сертификат домена вашего банка, поэтому если вы попали на правильный домен и соединение защищено SSL — расслабьтесь). SSL сертификаты выдают специальные организации и обычно берут за это деньги (например, $100 в год). Но! Сертификат можно создать самостоятельно. Увы, при первом заходе на сайт с таким сертификатом браузер будет ругаться (ведь он заранее знает о центрах сертификации, но ничего не знает о вас), зато потом, когда вы подтвердите, что сертификату можно доверять — браузер создаст защищенное соединение с сервером, которое будет не хуже, чем обеспечиваемое платным сертификатом.

Конечно, это всё не нужно пользователям, если на сервере у вас крутится уютный бложик или какой-нибудь форум (и вы, наверное, догадываетесь, что на шифрование тоже тратятся ресурсы). Но ведь на том же самом сервере для тех же самых бложика с форумом, вы можете пользоваться веб-интерфейсом phpMyAdmin для управления СУБД. Перехваченные пароли нескольких пользователей форума — это так себе проблема, а вот пароль от всей базы данных ресурса с тысячими юзеров — куда страшнее. Соответственно, вам, как вебмастеру, ходить в phpMyAdmin и админку форумов/сайтов и пр. — лучше по защищенному SSL соединению. Согласны?

А теперь о том, как всё это настроить и запустить на своём сервере под управлением Ubuntu за пару минут (или даже быстрее, если вы быстро печатаете в консоли — потребуется лишь 5 команд).

Часто встречаю мучительные поиски решений упомянутой в заголовке проблемы в Debian-подобных дистрибутивах, в том числе и в Ubuntu.

А решение, тем временем, тривиальное и однозначное.

Надо в vhosts.conf добавить директиву ServerName со значением localhost.

Проще всего это сделать одной лаконичной командой:
sudo echo ServerName localhost >> /etc/apache2/conf.d/vhosts.conf

Как подсказали в комментариях, представленный выше пример — неправильный, от суперпользователя будет выполняться echo, а нам надо, чтобы от него выполнилась запись в файл, поэтому делаем вот так (если вы конечно уже не суперпользователь):
echo ServerName localhost | sudo tee -a /etc/apache2/conf.d/vhosts.conf

И после этого надо перезапустить сервер:
service apache2 restart

Внимание! Для новых версий Ubuntu (начиная с 10.04+ и вплоть до актуальной Ubuntu 12.04 LTS) существует и уже представлен у нас на сайте более простой способ создания самоподписного SSL-сертификата для Apache2. Но и эту статью мы оставляем на сайте в виду ряда полезных комментариев.

Великий веб-сервер Apache 2 умеет работать по защищенному протоколу https в рамках которого всё передаваемая информация шифруется сервером и клиентом по криптографическому протоколу SSL. Это значит, что даже перехвативший запросы клиента и страницы возвращаемые сервером — не сможет посмотреть содержание этих запросов и этих страниц. Как минимум, все эти данные постоянно оседают у провайдера и если, например, его гнусный сотрудник захочет, то легко узнает те пароли, которые вы отправляете на многие сайты в POST- или GET-запросах.

Для собственного сервера вам, как минимум, следует беречь пароли от баз данных, вбвиаемые в веб-морду phpMyAdmin.

Для того, чтобы организовать шифрованную передачу по протоколу SSL требуется специальный сертификат на сервере. Его подтверждают (обычно за деньги) всякие серьёзные центры по сертификации. Но можно сгененрировать сертификат и самостоятельно — такой сертификат называется самоподписным, потому что никакой центр аттестации его не подтверждает, а подтверждаете лично вы.

Понятно, что для сайтов из мира электронной коммерции (особенно для тех, где имеется некий личный кабинет с каким-то счётом, который может быть злоумышленником опустошён) применять требуется полноценные сертификаты, подтверждённые авторитетным центром, а для сайтов не хранящих какие-то важные пользовательские данные — шифрование вообще ни к чему (ещё и нагрузку на сервер создаёт же), но для собственных нужд (вроде упомянутого phpMyAdmin`а) — сойдём и самоподписной.

Всего-то придётся успокоить браузер, при попытке первого соединения с хостом, зашифрованным самоподписным сертификатом, разок взглянув на примерно такое окошко:

Что, конечно, критично для неосведомлённых посетителей (тем более, если ваш сайт ориентирован далеко не на гиков), но годно — для вас лично или для команды разработчиков, коллег и пр. Так вот о том, как на своём сервере за несколько минут для нужного хоста настроить SSL с самоподписным сертификатом — далее и пойдёт речь.