Красивое отображение статусов команд в bash-скрипте

Объявляем функцию, которой скармливаем результат последней команды ($1) и текст ($2):

function check_error() {
  if [[ "${1}" -eq 0  ]]  

then echo  -e "$2:\t\e[1;32m[OK]\e[0m"  

else echo  -e "$2:\t\e[1;31m[ERROR]\e[0m"  

fi 

}

И после нужно команды вызываем ее:

rm -f file 

check_error $? "Removing file"

=============================================

Перехват ошибок в сислог.

set -e # fail on any error
set -u # treat unset variables as errors
# ======[ Trap Errors ]======#
set -E # let shell functions inherit ERR trap
# Trap non-normal exit signals:
# 1/HUP, 2/INT, 3/QUIT, 15/TERM, ERR
trap err_handler 1 2 3 15 ERR
function err_handler {
local exit_status=${1:-$?}
logger -s -p "syslog.err" -t "ootync.deb" "supersh.deb script '$0' error code $exit_status (line $BASH_LINENO: '$BASH_COMMAND')"
exit $exit_status
}
your_command some args

===========================================

Как логировать одновременно и в консоль и в сислог

Сначала объявляем функцию:

log() { logger -t scriptname "$@"; echo "$@"; }

затем в месте, где нужно логировать вызываем ее, передавая в качестве параметра текст:

log "text to be logged";

Установка 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

Массовая миграция пользователей между серверами 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/

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

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

Опрятные логи 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" || '
                            ;

Как подцепиться к 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-ка секунд. 

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

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

Созрел я наконец для этой статьи. Навеяна она тем, что мне частенько приходится готовить своих друзей в системные администраторы. Каждый раз я придумываю им задачки и каждый раз заново придумываю, что же придумать. Пришло время дать начало полноценному мануалу.
В отличии от подобных, кстати очень интересных, статей, свою я напишу в форме тьюториала - достаточно атомарных шагов, которые усложняются от раза к разу. То есть пройдя по нему от начала и до конца, можно будет искать работы на деньги, сопоставимые со средней зарплатой в вашем городе, а может и побольше. При этом на собеседовании чувствовать себя очень уверенно. Те, у кого хватит терпения, могут использовать этот курс, как базу перед началом курсов о программировании. Очень удобно начинать программировать, когда уже хорошо ориентируешься в нижнем слое операционной системы. В конце будет также дана ссылка на мою короткую статью на тостере, о том, куда дальше двигаться, чтобы стать 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) и никогда не задерживаться на работе более года. Потому что основная масса опыта идет только в первые месяцы работы и очень важно не почевать на лаврах, а вовремя уйти в другую команду, чтобы опять попасть на волну. Но за эти деньги вы полностью распрощаетесь с личной жизнью.

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

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

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)

Как работает компилятор gcc/g++

Не могу не поделиться ссылкой на роскошнейшую статью: О GCC, компиляции и библиотеках
Досконально разобраны все четыре этапа, написано как их прерывать и как продолжать с прерванной точки. И отличное продолжение этой статье GCC and Make

Fatal: no entropy gathering module detected

Подобное сообщение появляется в том случае, если команда, запущенная из chroot'а требует генерации случайных чисел. Например svn checkout https://

Эта проблема достаточно хорошо освящена на просторах интернетов... людьми, которые не понимают, что говорят.

Итак, стандартное решение для нее - убедиться, что в системе есть эти девайсы. Если нет, то создать:

mknod -m 666 /dev/random c 1 8 
mknod -m 666 /dev/urandom c 1 9

Но в чруте эти девайсы так просто не окажутся. Потому чуть более продвинутые посоветуют создать сразу с ныжными путями:

mknod -m 666 /chroot/path/dev/random c 1 8
mknod -m 666 /chroot/path/dev/urandom c 1 9

или пробросить (команда для Jailkit):

jk_cp -v -j /chroot/path /dev/random
jk_cp -v -j /chroot/path /dev/urandom

Все три варианта - бред. Потому что в случае отсутствия этих устройств или неправильных прав на них, ошибка была бы другой.

Так о чем нам говорит именно эта ошибка?
Тут надо разобраться как работают эти две команды. Они залазят в буфер шумов от драйверов устройств и берут оттуда данные, из которых и составляются рандомные цифры. Стоп! Каких устройств? Мы же в чруте :)
Правильный вопрос - 50% ответа. Решение приходит само собой:

mount -o bind /dev /chroot/path/dev

UPD: как правильно заметил мой товарищ Павел, это резко понижает безопасность сервера, выкладывая диски в chroot. Так что нужно взвешивать такое решение.

Установка почтового сервера Exim4 и Dovecot и проксирование IMAP через Nginx

Отличная подборка информации: Exim 4.70 (lissyara)

Сначала капельку терминологии:

MTA - mail transfer agent. Это сервис, который передает почту между серверами, используя протокол SMTP. (эту задачу будет выполнять Exim4).

MSA - mail submission agent. Этот сервис используется для отправки почты пользователем с сервера наружу. Именно он получает запрос на обработку исходящего письма от нашего пользователя по протоколу SMTP на портах 25 или 587 и передает ее MTA для дальнейшей транспортировки. То есть это сервис для исходящей почты. (эту задачу будет выполнять Exim4).

MDA - mail delivery agent. Это сервис, который раскладывает почту по папкам, после того как MTA принял какую-то почту извне сервера для нашего пользователя. То есть это сервис для входящей почты. (эту задачу будет выполнять Exim4).

MRA - mail retrieval agent. Это сервис, который достает почту из папок для клиента, пришедшего по протоколам POP/IMAP. (эту задачу будет выполнять Dovecot).

MUA - mail user agent. Это программа, предоставляющая человеческий интерфейс для обращения к MRA по протоколу POP/IMAP. Она может быть исполнена как вэб-приложение на том же сервере (RoundCube, Squirrel, Horde, etc.) так и быть десктопным приложением (Outlook, Thunderbird, The Bat). В любом случае это приложение подключается к MRA на порт 110/143 и работает по протоколу POP/IMAP. (эту задачу будет выполнять десктопный клиент на стороне пользователя).


Цепочка отправки письма выглядит так:
MUA(Outlook, отсылка, ivanov@abc.com)-->MSA-->MTA(abc.com)-->
>-----интернет----->
-->MTA(xyz.com)-->MDA-->MRA-->MUA(Outlook, прием, petrov@xyz.com)

Любой из вышеперечисленных сервисов может работать не только по обычным протоколам, но и по шифрованным. Такие протоколы обозначаются буквами S в конце. Например IMAPS. Номера портов соответственно тоже меняются.

Итак приступим...

Как вытащить на свой терминал чужой процесс

Все очень просто:

apt-get install reptyr

Если процесс случайно оказался отдетаченным от PTY (например сеть отлетела), то так:
Смотрим PID своего процесса:

ps auxf 

И подключаемчя к нему:

reptyr PID-процесса

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

Ctrl+Z

Запускаем в бэкграунде:

bg

Делаем его сиротой:

disown

Отцепляемся. Прицепляемся потом с нового терминала и забираем его обратно через reptyr.

Сборка пакета PAM-SQLite и NSS-SQLite

Как многим известно, аутентификация в Linux проходит централизованно в PAM. Стандартно PAM использует файлы /etc/passwd (и еще несколько: shadow, group,  и т.д.). В крупных компаниях предпочитают держать пользователей не в файлах, а в LDAP. Но если Вы пишете свое приложение, то наверняка хотите хранить пользователей в базе. Для MySQL и PostgreSQL в репозиториях Debian есть стандартные пакеты libpam-mysql и libpam-pgsql. Но что делать, если пользователи живут в SQlite? Об этом ниже, а пока небольшая вводная, важная к прочтению:

Подразумевается, что читатель знает разницу между аутентификацией и авторизацией.

Процесс происходит примерно так (рассмотрим на примере SSH). Демон SSH принимает соединение с логином и паролем.
Теперь перед SSH-демоном две задачи:
1) Identity. Установить, что пользователь вообще существует.
(это делается на первом слое: NSS)
2) Authnetication. Проверить его пароль.
(это делается на втором слое: PAM, если конечно в /etc/ssh/sshd_config стоит настройка "UsePAM yes" ).

Далее, через систему NSS он смотрит настройки. Находятся они в файле /etc/nsswitch.conf. По дефолту там стоит так:

passwd:         compat

group:           compat

shadow:        compat

compat - значит локальные файл (/etc/passwd,/etc/shadow,/etc/group)
Можно добавить своё, например:

passwd:         compat   ldap   sqlite

group:           compat   ldap   sqlite

shadow:        compat   ldap   sqlite

В таком случае система сначала будет искать пользователя в файлах, если нет, то в LDAP и наконец в SQLite.

Поэтому кроме пакета libpam-sqlite вам понадобится еще пакет libnss-sqlite, чтобы NSS вообще понимал такую инструкцию как "sqlite".

====
Теперь разберемся откуда брать код.
Поиск кода обоих приложений (libnss-sqlite и libpam-sqlite) приводит на аккаунт github Sectoid. Но ведет его достаточно вяло. libpam-sqlite остановился на версии 0.3. Эта версия поддерживает SQLite2, а вот SQLite3 - нет.
Версию 0.3 уже, в свою очередь форкнул ip1981 и добавил в неё поддержку SQLite3, назвав ее версией 0.4.
Но я внезапно нашел вот уже версию 1.0.1 (с поддержкой SQLite3).



Нам понадобятся пакеты:

apt-get install libpam0g-dev libmhash-dev libsqlite0-dev

И инструменты сборки:

apt-get install dh-make dpatch devscripts autoconf  shtool libtool

Переходим в директорию, где будем работать:

cd /usr/src

Скачиваем исходники с сайта:

git clone https://github.com/dtjm/pam_sqlite3.git libpam-sqlite-1.0.1

Логин в RHEL/CentOS/OEL под рутом с RSA-ключом

RHEL-like операционные системы, в отличии от Debian, очень сильно защищены. Сразу после инсталляции Вы получите полный набор заборов в виде SElinux, iptables и прочих. Привыкшему человеку это нормально (оно как бы даже спокойнее), а вот новичка такое состояние приведет к эйфории эфтаназии.
Особо "грамотные" советуют выключить все это. Но я бы им по губам бил за такие советы. Умные дяденьки не для того нас оберегали от безопасности, чтобы мы ей пренебрегали. Подобные вопросы надо решать только по-спортивному.

Одна из таких засад: невозможность залогиниться под рутом с ключом.

Причин две.
1) В RHEL-вском SSH по умолчанию стоит StrictModes yes. Это значит, что мы должны создавать директории и файлы SSH с нормальными правами, а не как рубахи-парни.

mkdir /root/.ssh
chmod 700 /root/.ssh

и

touch /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys

2) Но и после этого законнектиться ключем будет невозможно. В этот раз вредит SElinux.
Чинится так:

restorecon -R -v /root/.ssh

Сборка eAccelerator под Debian

Для начала установим необходимые пакеты для сборки PHP и вообще сборки пакетов:

apt-get install php5-dev dh-make autotools-dev gcc-4.3 debhelper devscripts

Так же нужно учесть одну особенность eAccelerator - он будет работать только с той версией PHP, с которой был собран. Если у Вас на тестовом сервере одна версия PHP, например 5.3.3-7+squeeze3,  а на продакшене 5.3.3-7+squeeze8, то eAccelerator не заведется и будет выкидывать такую ошибку:

[eAccelerator] This build of "eAccelerator" was compiled for PHP version 5.3.3-7+squeeze3. Rebuild it for your PHP version (5.3.3-7+squeeze8) or download precompiled binaries.

Чтобы этого избежать, нам надо подтянуть версию на тестовой машине до сервера, где будет использоваться eAccelerator:

apt-get install php5=5.3.3-7+squeeze8 php5-dev=5.3.3-7+squeeze8

Переходим в директорию, где будем работать:

cd /usr/src

Скачиваем туда тарбол с исходниками.

Распаковываем его:

unzip eaccelerator-0.9.6.1.zip

Так как все расширения PHP принято обзывать php5-extention (например php5-tidy, php5-memcached, php5-mysql и т.д.), а имя/версия пакета будет создано на основе имени директории, то переименуем директорию:

mv eaccelerator-0.9.6.1 php5-eaccelerator-0.9.6.1

Заходим в распакованную директорию:

cd php5-eaccelerator-0.9.6.1

Открываем конфиг и настраиваем под себя. Я, например, люблю когда кэш лежит там где он должен лежать по FHS - в /var/cache, а не в /tmp. А еще нужно поправить путь к логу, потому что у нас Debian, а там CentOS-вский путь:

vi eaccelerator.ini

Далее нужно PHP-зировать пакет - подогнать под API PHP:

phpize

И теперь уже можно его конфигурировать:

./configure --with-eaccelerator-debug

Аутентификация SSH через LDAP public key

До того, как начать, нужно обязательно научить SSH работать с LDAP.  Без этого дальше можно не читать.


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

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

Например. Мы видим, что есть патчи под 5.1, 5.3, 5.4. А у нас Squeeze, с которым идет 5.5. Значит смотрим Lenny - там шла 5.1. А на эту версию у нас патч как раз есть. Добавляем репозиторий Lenny:

vi /etc/apt/sources.list

## Debian Lenny base:
deb http://archive.debian.org/debian/ lenny main non-free contrib
deb-src http://archive.debian.org/debian/ lenny main non-free contrib

Обновляем:

apt-get update

Перейдем в директорию работы с исходным кодом:

cd /usr/src/

Смотрим какие версии нам стали доступны после подключения репозитория от Lenny:

apt-cache show openssh-server | grep Version

Скачаем исходники OpenSSH нужной нам 5.1-версии:

apt-get source openssh-server=1:5.1p1-5

И затем зайдем туда:

cd openssh-5.*p1

Где достать репозитории Debian Lenny

С тех пор, как Lenny перешел в состояние устаревшего, все его репозитории переместили в archive*

## Debian Lenny base:
deb http://archive.debian.org/debian/ lenny main non-free contrib
deb-src http://archive.debian.org/debian/ lenny main non-free contrib

## Debian Lenny updates:
deb http://archive.debian.org/debian/ lenny-updates main non-free contrib
deb-src http://archive.debian.org/debian/ lenny-updates main non-free contrib

## Debian Lenny Security updates:
deb http://archive.debian.org/debian-security/ lenny/updates main contrib non-free
deb-src http://archive.debian.org/debian-security/ lenny/updates main contrib non-free

## Debian Volatile updates:
deb http://archive.debian.org/debian-volatile lenny/volatile main contrib non-free
deb-src http://archive.debian.org/debian-volatile lenny/volatile main contrib non-free

## Debian Lenny Backports
deb http://archive.debian.org/debian-backports lenny-backports main contrib non-free
deb-src http://archive.debian.org/debian-backports lenny-backports main contrib non-free

Сборка PHP в Debian в альтернативную директорию

На просторах Интернета имеется достаточно большое количествео разнообразных мануалов на тему сборки PHP. К сожалению, всех их объединяет одно: все они делаются через make install (читайте: через интимное место). О причинах распыляться не буду, порекомендую лишь статью на Хабре с многоговорящим названием: Хочется взять и расстрелять, или ликбез о том, почему не стоит использовать make install.

В данном мануале я не ограничусь только сборкой одного пакета.Мы соберем все популярные версии и {в}рапперы для него.

Все, что собирается - собирается на Debian Squeeze для FastCGI. Шаг влево/шаг вправо и мануал уже не подходит. Например на Lenny даже близко не так все будет. Я очень рекомендую установить чистенькую свежую систему, чтобы не спотыкаться об пакеты из неродных репозиториев и их разломанными зависимостями.


Начнем с того, что поставим зависимости, которые возможно нам и не понадобятся, но они указаны к стандартному PHP мейнтейнерами:

apt-get install apache2-prefork-dev autoconf automake bison chrpath flex freetds-dev hardening-wrapper libapr1-dev  libbz2-dev libc-client-dev libcurl4-openssl-dev libenchant-dev libevent-dev libexpat1-dev libfreetype6-dev libgcrypt11-dev libgd2-xpm-dev libglib2.0-dev libgmp3-dev libicu-dev libjpeg-dev libkrb5-dev libldap2-dev libmcrypt-dev libmhash-dev libmysqlclient-dev libonig-dev libpam0g-dev libpng12-dev libpq-dev libpspell-dev libqdbm-dev librecode-dev libsasl2-dev libsnmp-dev libsqlite0-dev libsqlite3-dev libt1-dev libtidy-dev libtool libwrap0-dev libxmltok1-dev libxml2-dev libxslt1-dev locales-all mysql-server quilt re2c unixodbc-dev firebird2.1-dev libgdbm-dev libcurl4-openssl-dev libssl-dev  libreadline-dev libedit-dev

Отлично. Теперь поставим утилиту, которой будем собирать пакеты:

apt-get install checkinstall

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

Создадим директории для работы над нашими пакетам:
mkdir -p /usr/src/php/php5.2 /usr/src/php/php5.3 /usr/src/php/php5.4 /usr/src/php/php-switcher

Итак перейдем с сборке первого пакета - PHP 5.2

Какой файл .php исполняется как FastCGI на моем сервере и грузит CPU?

Ответа нет, потому как вопрос задан некорректно. Чтобы докапаться до истины расскажу в кратце как работает FastCGI.
От клиента, будь это браузер или реверс-прокси перед вэб-сервером, поступает запрос на исполнение некоего .php файла (пусть в нашем примере будет index.php). Вэб-сервер создает отдельный от себя процесс, который видно в топе как php-cgi, и говорит ему: "Ты создан! Теперь вот тебе файл index.php, исполни его и верни мне результат." Далее происходит вот что. FastCGI процесс берет файл index.php и проходится по его коду (вопрос компиляции я тут опущу за ненадобностью). На пути встречает include соседних файлов и их соответственно тоже запускает. И, напомню, все это один процесс php-cgi, который пробегает по многим .php файлам.
Затем, как только php-cgi процесс отдаст результаты обратно вэб-серверу, вэб-сервер, исходя из конфига, решит что делать с этим процессом - либо убить, либо оставить для обработки следующих запросов (чтобы заново его не рожать). Но, опять же согласно конфигу, он будет еще поглядывать за этим процессом: сколько раз он выполнял задачи, как часто проставивает, не превратился ли в зомби, не завис ли, не обработал ли слишком много запросов и так далее, пока все-таки не найдет достаточного основания для убийства этого процесса и порождения нового на его место.
То есть один php-cgi процесс - это не только не один .php файл, это еще и не одна порция таких файлов.Чтобы было более понятно, процесс php-cgi, который мы видим в ps, это ничто иное как контейнер, запущенный в памяти интерпретатор, наподобии как Tomcat у Java.
Именно поэтому не нужно удивляться, что при ограничении max_execution_time = 120 секунд в php.ini, в списке процессов вдруг виден процесс, который висит вот уже неделю. Он таких по 120 секунд за свою недельную жизнь видал не перевидал, все через него прошли, как через матрешку.


Для наглядности проведем эксперимент.

Посмотрим, сколько процессов у нас на сервере запустил некто user1316 (много строк я потер, чтобы не получалась длинная простыня).

node1-2:~# ps aux | grep user1316 | grep -v grep

user1316 48214  5.1  0.1 234148 33148 ?        S    10:54   1:52 /usr/bin/php5-cgi php
user1316 48215  5.0  0.1 249040 48068 ?        S    10:54   1:50 /usr/bin/php5-cgi php
user1316 48238  5.9  0.1 244976 43980 ?        S    10:54   2:11 /usr/bin/php5-cgi php
user1316 48242  3.7  0.2 251160 49780 ?        S    10:54   1:22 /usr/bin/php5-cgi php
user1316 48367  5.4  0.1 242904 43752 ?        S    10:54   1:58 /usr/bin/php5-cgi php
user1316 48383  5.3  0.1 244968 43856 ?        S    10:54   1:57 /usr/bin/php5-cgi php
user1316 48388  5.7  0.1 243432 42452 ?        S    10:54   2:06 /usr/bin/php5-cgi php
user1316 48399  4.4  0.1 244968 43968 ?        S    10:54   1:37 /usr/bin/php5-cgi php
user1316 51261  5.6  0.1 243436 42456 ?        S    11:01   1:37 /usr/bin/php5-cgi php
user1316 51262  5.8  0.1 244712 43736 ?        S    11:01   1:41 /usr/bin/php5-cgi php
user1316 52196  8.6  0.1 234540 33568 ?        S    11:04   2:16 /usr/bin/php5-cgi php
user1316 58913  2.9  0.1 244928 43772 ?        S    11:22   0:14 /usr/bin/php5-cgi php
user1316 59862  5.3  0.1 246504 47040 ?        R    11:25   0:18 /usr/bin/php5-cgi php
user1316 59863  4.4  0.1 242908 43448 ?        S    11:25   0:15 /usr/bin/php5-cgi php
user1316 61984  1.6  0.1 248832 49344 ?        S    11:30   0:00 /usr/bin/php5-cgi php
user1316 62000  1.1  0.1 242684 43180 ?        S    11:30   0:00 /usr/bin/php5-cgi php
user1316 62001  4.3  0.1 247412 47692 ?        R    11:30   0:01 /usr/bin/php5-cgi php
user1316 62006  3.1  0.1 231848 32376 ?        S    11:30   0:01 /usr/bin/php5-cgi php
user1316 62323  9.2  0.1 248028 48408 ?        R    11:30   0:01 /usr/bin/php5-cgi php
user1316 62324  2.3  0.1 242688 43188 ?        S    11:30   0:00 /usr/bin/php5-cgi php

Обратите внимание, есть процессы S (sleeping), а есть процессы R (running).
Sleeping - это процесс, который уже обработал основной .php, выданный ему вэб-сервером и все его инклуды. Теперь он просто висит в памяти и спит, пока его не пнёт вэб-сервер с новым заданием.
Running - это процесс, который в данный момент действительно что-то делает для вэб-сервера, а как сделает, то уснёт (S), если вэб-сервер его не убьет.

Теперь попробуем подцепиться к спящему процессу (бегущие (R) процессы нам неинтересны - пока мы будем писать команду, они уже умрут). Возьмем самый последний в списке. Его PID - вторая колонка:

strace -p 62324

Process 62324 attached - interrupt to quit
accept(0,

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

Но если все же вопрос "так какие файлы то?" остался неотвеченным, то вот, что даст ответ:

strace -e open,access -p 62324

А вот так можно померять, на что сколько времени уходит у данного процесса. Эта команда ничего не покажет, ее нужно прервать на ^C через произвольный промежуток времени. Но при выходе стрейс выплюнет красивую табличку с отчетом:

strace -c -p 62324

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 66.04    0.010125           0     20990      1314 open
 11.51    0.001765           0     75052         6 read
  3.59    0.000551           0     19012           munmap
  3.36    0.000515           0     28905           fstat
  2.44    0.000374           0     19012           mmap
  2.37    0.000363           0     19848           close
  2.17    0.000332           0      4536           write
  2.16    0.000331           0     29262           lseek
  1.72    0.000264           0     14543      1385 lstat
  1.21    0.000185           0      3301           poll
...
    <вырезано еще около 20-ти системных вызовов
      но они занимают менее 1% времени каждый>
...

Что-то интересное на эту тему есть в статье Оптимизируем загрузку PHP-кода в 22 раза, или почему FastCGI не ускоряет PHP