04.08.2013

Установка Node.js + Fugue

Вообще nodejs появился в стандартном репо Debian Jessie. Но если нет желания подцеплять его репо, то будет ставить вручную.

Перейдем в директорию, где он будет у нас жить:
cd /opt/

и скачаем Node.js:
wget http://nodejs.org/dist/v0.10.15/node-v0.10.15-linux-x64.tar.gz
Распакуем:
tar xzf node-v0.10.15-linux-x64.tar.gz
Следующий шаг объясню чуть подробнее. Дело в том, что номер версии node.js отображается в названии директории. При обновлении у нас появится рядом еще одна директория с новой версией. Для быстрого переключения, пусть они так и останутся, а мы будем переключаться между ними симлинками. Но пока у нас только одна директория, то симлинк будет вести на нее:
ln -s node-v0.10.15-linux-x64 node.js
Можем перейти в нее и попасть в Node.js:
cd node.js
Обязательно надо добавить в $PATH, чтобы вызывать интерпретатор из любой директории (синюю строчку надо добавить непосредственно перед export PATH):
vi /etc/profile
PATH="$PATH:/opt/node.js/bin" 
И перечитаем новые настройки на лету:
source /etc/profile
Теперь мы можем создать тестовый файл и запустить его в Node.js:
mkdir /var/www/cat > /var/www/hello.js
var http = require('http');
http.createServer(function (request, response) {    response.writeHead(200, {'Content-Type': 'text/plain'});    response.end('Hello World\n');}).listen(8080);
console.log('Server started');

Как видно выше, мы сделали порт 8080. Теперь запускаем:
node /var/www/hello.js
Так как это однотредовая модель, то рано или поздно мы получим проблему с производительностью. Во избежание этого прогноза нам надо установить Fugue:

(coming soon...)
http://nodejs.org/docs/latest/api/cluster.html

26.07.2013

Массовая миграция пользователей между серверами ISPmanager

Прижала меня жизнь, как видно из названия. И прижала сильно. Перенос 2300 пользователей - это чистейшей воды ад. Я дам только основные этапы. 99% работы придется допиливать по месту.

Первый этап:

Если оставить дефолтные настройки MySQL на принимающем сервере, более половины баз не вгрузятся - и вот тогда на помощь придет веревка и мыло. Дабы избежать главной и самой досадной ошибки, увеличим размер единовременно вгружаемого пакета команд в MySQL:
set global max_allowed_packet = 104857600;
Да, пусть это будет на лету, а не с конфига. Мы все равно перезагружать MySQL не будем. А после того, как все импортируется, нас больше не будет интересовать эта настройка.

Второй этап:

Если Вы переносите пользователей с нескольких разных серверов, то у Вас будет затык с одинаковыми названиями баз и/или имен пользователей MySQL. Не бывает серверов, на котором какой-нибудь умник не заведет базу под названием joomla, wp или admin.

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

Как решать: берете список на каждом из серверов, чистите его от мусора, сортируете, diif.
Списки тут:
select db from mysql.db;select user from mysql.user;
В случае обнаружения одинаковых пользователей нужно создать пользователю базу с более уникальным именем или более уникального пользователя. Затем вписать это в конфиг сайта.

Третий этап:

Дисковое пространство. Места, куда мы бэкапимся, должно хватить на сумму файлов /var/www и /var/lib/mysql. Например мы нашли место на /var/backups/

Четвертый этап:

Возможно когда-то пользователи перемещались между серверами. При этом на исходном он не был удален, а был просто выключен. Но! Мы не можем просто взять и сдампить только включенных - ведь есть те, кого выключили за неуплату. Быть может завтра он оплатит - а ему нечего включать - его данные остались на исходном сервере.

29.05.2013

Опрятные логи Nginx

Хочу поделиться своим вариантом формата access-лога. Очень уж мне нравится. Не могу держать в себе :)

        log_format verbose  '[$time_iso8601] || '
                            ' STATUS: $status || '
                            ' HOST: $host || '
                            ' CONN#: $connection || '
                            ' $remote_addr --> $server_addr || '
                            ' REQ_TIME: $request_time || '
                            ' UPSTR_RESP_TIME: $upstream_response_time || '
                            ' USER_AGENT: "$http_user_agent" || '
                            ;


18.05.2013

Как подцепиться к FastCGI-процессу напрямую

Как известно, telnet'ом тут не пообщаться. На помощь приходит утилита cgi-fcgi

Устанавливаем пакет, в котором она есть. Вариант для Debian:
apt-get install libfcgi0ldbl

У CentOS пакет называется, вроде как, fcgi.


Далее мы можем делать запросы скармливая его утилите cgi-fcgi либо прямо из командной строки либо помещая их в простой советский CGI-скрипт. Формат общения примерно следующий:

cgi-fcgi -bind -connect адрес:порт
Если не передавать никакой запрос или не передать минимально необходимые данные, то вернутся просто стандартные теги:

# cgi-fcgi -bind -connect 127.0.0.1:9000
X-Powered-By: PHP/5.4.4-14Content-type: text/html
Но нам нужно сделать какой-нибудь реальный запрос. Минимальный набор передававаемых переменных составляет:
REQUEST_METHOD - метод HTTP, например GET или POST
SCRIPT_FILENAME - полный путь с скрипту. Например: /var/www/index.php
более полный список стандартных переменных можно посмотреть например в файле /etc/nginx/fastcgi_params или в массиве $_SERVER в PHP.

Самый простой вариант - прямо в командной строке задать все переменные и обратиться к FastCGI-процессу:
# SCRIPT_FILENAME=/var/www/index.php
# REQUEST_METHOD=GET
# cgi-fcgi -bind -connect 127.0.0.1:9000

, где # - это приглашение командной строки и его писать не надо.


Ну и в помощь простейшая команда, которая выступит в качестве мониторинга количества процессов (не забудьте настрить парметр pm.status_path в pool.d/www.conf):
watch SCRIPT_NAME=/fpm-status SCRIPT_FILENAME=/fpm-status QUERY_STRING= REQUEST_METHOD=GET cgi-fcgi -bind -connect 127.0.0.1:9000



read data timeout in 40 seconds

Многие встречаются достаточно часто с этой ошибкой. Очень популярно мнение, что нужно увеличить параметр FcgidIOTimeout в конфиге FastCGI. Отчасти так оно и есть. 40 секунд - это дефолтное значение FcgidIOTimeout, если оно не задано в конфиге в явном виде.

Первое, на чем хотелось бы сделать акцент: FcgidIOTimeout - это время, которое отведено под то, что Апач пытается подсоединиться к приложению FastCGI. То есть это до того, как началось исполнение кода PHP и к PHP-интерпретатору и его ограничениям по времени никакого отношения не имеет. Поэтому не надо думать, что скрипту не хватает время для исполнения. На момент вылета этой ошибки, скрипт даже еще не начал исполняться - его никто не принимает в работу.

Причина сводится к простой фразе: Апачу не отвечает ни один из инстансов FastCGI. А это уже может иметь сколько угодно разных причин. Например FastCGI-процессы зависли или уперлись в лимит FcgidMaxProcessesPerClass (максимальное количество процессов на одного пользователя). В таком случае ждать можно вечно и накручивать время ожидания - бесполезно.

Вывод: искать в чем пробема нужно не глупым повышением цифры в FcgidIOTimeout, а выяснением, почему Апач не может обратиться к FastCGI аж в течении 40-ка секунд. 

30.04.2013

SSL Explorer

SSL Explorer был приобретен Барракудой, но похоже остается единственным опенсорсным решением для организации VPN, который не использует клиента. Хочу также отметить, что все clientless решения на самом деле не являются таковыми, потому что на браузере пользователя должна быть установлена Java, которая сама установит клиента. Есть действительно clienless (например CheckPoint Mobile Access), но на слово VPN они не тянут - заключаются они в том, что просто пропускают вэб-сайты через свой URL (при этом отрезая JavaScript/Flash/etc.).


Итак, переходим в директорию, где будет установлено приложение:
cd /opt

Установка prerequisites: Java и Ant.

Устанвливаем Java SDK по этому мануалу.
ВНИМАНИЕ: новые версии Java не подойдут. Качайте пятую версию (у меня 1.5.22 подошла).

Ставим также Ant на сервер. Скачиваем его в директорию /opt.
Распаковываем:
tar xf apache-ant-1.9.0-bin.tar.gz
И прописываем путь к его бинарнику
vi /etc/profile
PATH="$PATH:/opt/apache-ant-1.9.0/bin"
export PATH

Подхватываем новый /etc/profile для обновления изменений:
source /etc/profile
Проверяем:
ant -version

15.04.2013

Как стать системным администратором

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

Немного вводной информации для новичков. Какие администраторы бывают, сколько они зарабатывают, каковы их карьерные перспективы.

Итак, какие администраторы бывают:
1) Универсальный администратор - администратор, который управляет операционными системами и сервисами на них (кроме совсем уже сложных сервисов, на которые есть собственные администраторы - см.п.2). Основные системы, с которыми работает системный администратор: Linux, Windows Server, Sun Solaris, BSD. Есть и менее популярные системы, на которые также требуются специалисты (они дороже, но предложений мало).

2) Узкопрофильный администратор сервиса (баз данных, кластеров, сетей, VoIP, MS Exchange и т.д.) - узкоспецилизированный администратор, заточенный на конкретные глубокие задачи. Как правило, все они бывышие универсальные администраторы, которые решили сосредоточиться на чем-то одном.

3) Build/Release-инженеры [иногда называют Configuration manager'ы] - бывшие системные администраторы, которые ударились в программирование и занимаются настройкой движения программного кода от IDE разработчика до сервера, на котором он будет работать. В это движение входят статический анализ кода, модульное тестирование, компиляция кода, упаковка программы, интеграционное/системное/регрессионное тестирование, выкладывание в репозитории и установка на серверы. Одним словом Continuous Delivery.
Как правило, это уже вершина карьеры системного администратора. В такие инженеры попадают только самые сильные и матёрые. И таких не более 5%.
Отдельно хотелось бы упомянуть, что стиль работы регулируется не только объемом технических знаний, но и "культурным" подходом, который называется DevOps. Заключается он в полной прозрачности процесса как для Developers (разработчиков) так и для Operations (системные администраторов). Причем не просто прозрачности, а качественной связи в обратную сторону тоже.
Основные инструменты, которые используют B/R-инженеры:
  • VCS (например Git, Mercurial, SVN, ...)
  • SCA (SonarQube, Veracode, Moose, ... )
  • Maven, Ant, Gradle, Rake, make, SCons, WAF, NuGet, ...
  • CI (например Bamboo, Jenkins, TeamCity, TFS, ...)
  • CD (например uDeploy, RunDeck, ...)
  • EM (например Vagrant, Docker, ...)
  • CM (например Ansible, Puppet, Chef, CFEngine, SaltStack, PowerShell DSC, ...)
  • Репозитории (например APT, YUM, Nexus, Artifactory, Archiva, Chocolatey, ...)

____

Теперь углубимся только в первый пункт, потому что статья ради него написана.
Как я уже оговорился, операционных систем много и, как правило, каждый системный администратор выбирает себе систему по душе. Мы же будем говорить только о Linux. Не холивара ради объясню почему.
Windows - бесспорно прекрасная система. Во многих отраслях она лидирует так, что за ней в принципе невозможно угнаться (тот же Exchange ушел лет на 10 вперед от Zimbra и ее альтернатив). Но:
1) Windows на пушечный выстрел не подпускают туда, где нужна надежность, скорость и прозрачность процессов - то есть к деньгам. Все до единого промышленные системы построены на Linux. Даже мосты в Петербурге разводят на нем же.
Например у крупного сотового оператора это выглядит так: на компанию 10k компьютеров с Windows (в качестве десктопов сотрудников и AD/почты) и порядка 400-500k промышленных серверов на Linux (обслуживают звонки абонентов - от OSS/BSS до биллинга). Понятно где вакансий больше?
2) Windows вообще не держит нагрузку :( Почти не кластеризуется нормально и не тюнится. И я это говорю не как дилетант, а как бывший ведущий специалист по Windows в Мегафоне.
3) Этой системе не повезло в том, что заточена она под офисную инфраструктуру. Занявшись Windows, Вы получите не только интересные сервисы от талантливых парней из Редмонда, но и полный набор коллег в виде нервозных бухгалтеров и недемократичных менеджеров, неспособных сформулировать не то что задачу, но даже собственные мысли. Работа в таком коллективе скорее сделает из Вас профессионала по подковерным интригам, чем системного администратора.
 В мире Linux/Unix все совсем по другому. Вход намного "дороже". Так просто не стартанешь, как в мире Windows, но зато, если стартанешь, выигрыш больше. Коллектив - все такие, как Вы. С уровнем интеллекта компьютерщиков, а не вопиюще тупых гуманитариев. Кроме того, Linux - открытая система, ее принципы понятны почти сразу и работает она прозрачно. Даже если захотите потом вернуться на Windows, Вы будете понимать его лучше, чем те, кто не прошел Linux-школу.

И все же главная выгода Linux от Windows, то что среди их команды попадаются вот такие девчонки!
Вот доказательство:




Базовых видов Linux всего 3: Debian, RHEL и Slackware. Все остальные названия, которые Вам приходилось слышать - это их дочерние варианты (например Ubuntu произошел из Debian).
Каждая из этих систем имеет свой набор плюсов и минусов, которые сводятся к тому, что под каждую задачу надо выбирать свой вариант. Все они имеют право на жизнь и все они по разному хороши. Но для начала лучше выбрать что-то одно. Переключиться потом будет очень просто. Мы будем работать на Debian.

Вкратце о деньгах: хороший специалист стоит дорого. Зарабатывать на этой специальности в 4 раза выше средней зарплаты при трехлетнем опыте в среднестатистическом российском городе-миллионнике вполне несложно. Есть кто работает и за 10 средних зарплат - но этого достигнут только самые трудолюбивые. Те, кто будет жадно пожирать новые технологии, соблюдать культуру (в том числе ITIL и DevOps) и никогда не задерживаться на работе более года. Потому что основная масса опыта идет только в первые месяцы работы и очень важно не почевать на лаврах, а вовремя уйти в другую команду, чтобы опять попасть на волну. Но за эти деньги вы полностью распрощаетесь с личной жизнью.

Последний важный момент: английский язык. Если его нет хотябы в зачаточном виде - до свидания. В мире ИТ делать без английского в принципе нечего. Английский на столько является само собой разумеющимся, что о нем даже не спросят на собеседовании и его не указывают в резюме. Так что либо марш учить, либо конец Вашей непостроенной карьере. В конце концов, давайте будем откровенны: на что вообще способен человек, который даже не может выучить иностранный язык? Мало на что.

Итак, в бой. Под катом уже пойдет последовательность действий.


09.01.2013

Repcache - кластеризация Memcache'а

Не понравился мне CouchBase. Причина - он написан на Java. А чтобы починить продукт на Java нужно быть Java-программистом и уметь читать эксепшены (а это подразумевает, что продукт писал ты сам, потому что эксепшен незнакомой программы понять физически невозможно). Еще сильнее убила нерабочая функция flush_all.
Ну пусть они сами своим барахлом и пользуются. А нам кто-то неизвестный великодушно дал еще один продукт, но на приличном языке Си: repcached.

Ну как водится, показываю как это сделать для Debian.

Сначала соберем пакет.
Нам понадобится одна зависимость и одна утилита:
apt-get install libevent-dev checkinstall

Создадим рабочую директорию:
mkdir /usr/src/repcached
cd /usr/src/repcached
Скачаем дистрибутив в эту директорию.

Распакуем его и перейдем внутрь:
tar xzf memcached-1.2.8-repcached-2.2.tar.gz
cd memcached-1.2.8-repcached-2.2
Далее есть баг, который заключается в том, что переменная IOV_MAX объявляется только для FreeBSD, а у нас Debian. Если этого не сделать, то ошибка при компиляции выскочит такая:
error: ‘IOV_MAX’ undeclared (first use in this function)