se1dhe

Сегодня в этой заметке хочу рассказать Вам о том, что же все-таки такое SuExec, зачем он нужен и как его установить на web-сервер в Linux системе. Не смотря на то, что интернет кишит множеством материалов по SuExec, о том как его ставить и какими способами, все же возникает множество вопросов начиная от корректности способов установки и его настройки до, почему же все в итоге не работает? Или работает но не так как надо? Прежде чем я начну говорить о SuExec, позвольте мне некоторое уточняющее отступление, которое поможет Вам в дальнейшем сориентировать именно Вас (как это ни странно) в какой же вы все-таки ОС собираетесь устанавливать и настраивать SuExec, другими словами, подходит ли вам тот или иной способ, найденный вами в интернете, для вашей операционной системы? Вот тут-то самое интересное. Найдя интересующий вас способ вы начинаете пробовать делать все как описано в нем и у вас что-то начинает идти не так практически сразу по причине простейшего отсутствия в вашей ОС тех команд которые описаны в способе... Все просто. Дело в том, что найденный Вами пример применим только для одного, максимум 3 видам ОС Linux. Какому именно? Далее, для этой статьи это будет уже не суть важно, потому что в данной статье я хочу предложить универсальный пример/способ, который подойдет к подавляющему большинству ОС Linux. Панацея? Возможно, да... В любом случае для начинающего интересоваться ОС Linux человека, мне кажется, эта статья будет крайне полезной. Итак приступим: Что же такое SuExec и для чего он НЕ нужен? Прежде чем принять решение об установке и приступить к настройке SuExec задайте себе вопрос: "А для чего я это делаю?". Есть несколько вариантов ответа: 1. Нужно повысить безопасность web-сервера Apache, потому что у меня присутствуют в системе виртуальные веб-серверы с несколькими доменами, ссылающимися на них. (ок - эта статья для вас) 2. Просто говорят, что это полезная штука и ее надо иметь в установленном/активизированном виде на web-сервере Apache, вот и хочу установить чтобы повысить безопасность одной странички на моем веб-сервере. (Думаю, в данном случае, модуль suExec Вам просто НЕ нужен и нет смысла его ставить). 3. Для самообразования, чтобы понять какие плюсы можно получить и какие минусы нужно учесть после установки этого модуля на многодоменный web-сервер. (Добро пожаловать в статью, думаю материал изложенный тут будет вам наиболее полезен). Если вы все-таки решили устанавливать этот модуль, то продолжаем. Далее. Какие версии Apache и PHP я использую в этой статье? Apache/2.2.19 (Unix) PHP Version 5.3.6 Итого имею: SERVER_SOFTWARE Apache/2.2.19 (Unix) DAV/2 PHP/5.3.6 Какую версию OC Linux я использую?: Для данной статьи это не суть важно, но если вам все-же интересно то пожалуйста: System - Linux AtomLinux 2.6.39.3 x86_64 Мне кажется это вам мало что сказало - потому что в своей работе я использую свой "респин" с данным ему мной названием "Atom" от версий linux Slackware и Mops/Agilia (http://agilialinux.ru/) - я просто привык от линукса брать только то что мне нужно под конкретные, нужные только мне, задачи и более ничего лишнего. Но продолжим. Далее я буду рассматривать два варианта развития событий: 1. Web-сервер Apache и PHP у Вас еще НЕ установлены в системе и Вы планируете настройку с нуля. 2. Web-сервер Apache и PHP у Вас уже установлен и они обслуживают 2 или более доменов. Итак, самое главное! Что же такое SuExec? SuExec - это модуль web-сервера Apache, который позволяет запускать CGI и аналогичные собственные или сторонних разработчиков скрипты/программы внутри веб-папки домена от имени вполне конкретного пользователя (которому данная папка/домен принадлежат) а не от пользователя/группы от имени которого работает непосредственно сам Apache web-сервер. Пример-пояснение (частный случай): Допустим мы имеем. 1. Web-сервер Apache, сервис которого запускается от пользователь:группа apache:apache 2. PHP - языковой пакет 3. домен www.domain1.ru - папка на сервере для него /vhost/domain1 4. домен www.domain2.ru - папка на сервере для него /vhost/domain2 5. содержимое папок domain1 и domain2 имеет следующий вид: для domain1.ru root@AtomLinux:/vhost/domain1# ls -l итого 16 dr-xr-x--- 2 domain1 domain1 4096 Июл 31 07:09 cgi-bin/ drwxr-x--- 2 domain1 domain1 4096 Июл 31 07:07 ftp/ drwxr-x--- 2 domain1 domain1 4096 Авг 4 01:43 logs/ drwxr-x--- 2 domain1 domain1 4096 Июл 31 07:12 www/ root@AtomLinux:/vhost/domain1# для domain2.ru root@AtomLinux:/vhost/domain2# ls -l итого 16 dr-xr-x--- 2 domain2 domain2 4096 Июл 31 07:09 cgi-bin/ drwxr-x--- 2 domain2 domain2 4096 Июл 31 07:07 ftp/ drwxr-x--- 2 domain2 domain2 4096 Авг 4 01:43 logs/ drwxr-x--- 2 domain2 domain2 4096 Июл 31 07:12 www/ root@AtomLinux:/vhost/domain2# Мы видим что на сравнении эти две папки практически идентичны, НО пользователь и его группа отличаются. Теперь перейдем в папку ./www каждого домена и сравним еще раз: для domain1.ru root@AtomLinux:/vhost/domain1/www# ls -l итого 4 -rwxr-x--- 1 domain1 domain1 19 Июл 27 16:41 php.php* root@AtomLinux:/vhost/domain1/www# для domain2.ru root@AtomLinux:/vhost/domain2/www# ls -l итого 4 -rwxr-x--- 1 domain2 domain2 19 Июл 27 16:41 php.php* root@AtomLinux:/vhost/domain2/www# И там и там присутствует файл php.php - он имеет внутри простой код вызова полного описания настроек php для домена к которому он относится. -rwxr-x--- 1 domain1 domain1 19 Июл 27 16:41 php.php* -rwxr-x--- 1 domain2 domain2 19 Июл 27 16:41 php.php* Внимание стоит обратить на то, что что им присвоены разные пользователь и группа. Так вот, если мы скопируем файл php.php из директории /vhost/domain1/www в директорию /vhost/domain2/www и дадим ему название php1.php (-rwxr-x--- 1 domain1 domain1 19 Июл 27 16:41 php1.php*) и попробуем его запустить через браузер, то получим ответ от сервера Apache "Access Denied" - попросту получим ошибку #403 - отказ в доступе. Одновременно с этим, файл с названием php.php (-rwxr-x--- 1 domain2 domain2 19 Июл 27 16:41 php.php*) будет также продолжать благополучно выполнять возложенную на него задачу. Файл php1.php не запустился потому что этот файл не принадлежит пользователю "domain2" группы "domain2" и файл является чужеродным для данного домена и обрабатываться не будет. Если мы проделаем все наоборот, то получим такую же картину. Также хочу обратить Ваше внимание на то, что если мы попытаемся из созданного скрипта в папке /vhost/domain1/www произвести какие либо изменения в папке /vhost/domain2/www - то мы так же получим сообщение от системы о том, что в доступе отказано. Вы уже обратили внимание на то что имена пользователей и их группы отличаются у папок разных доменов (и их содержимого) и как-бы не имеют ничего общего с сервисом Apache? Однако это не совсем так. Давайте заглянем в файлик group (/etc/group): domain1:x:2006:apache domain2:x:2007:apache и файлик (/etc/passwd): domain1:x:2006:2006::/vhost/domain1:/bin/bash domain2:x:2007:2007::/vhost/domain2:/bin/bash И тут становится понятно, что пользователь apache включен в группу этих доменов "domain1" и "domain2". Если мы уберем пользователя apache из любой из этих групп, то тот домен который входит в эту группу просто перестанет обрабатываться сервисом Apache. Таким образом можно "отключить" домен от сервиса выполнив простую команду (gpasswd -d apache domain1 или gpasswd -d apache domain2) удалив пользователя apache из соответствующих групп. Но это не всегда правильно, потому не стоит увлекаться этим приемом, я привел его для наглядности. Как мы видим из всего вышеперечисленного, SuExec это модуль который позволяет Web-серверу Apache существенно повысить безопасность как виртуальных хостов системы так и коренного домена. Это далеко не весь его функционал, но чаще всего его ставят именно из этих соображений. ВНИМАНИЕ! Неверная настройка модуля SuEXEC может не только решить ваши текущие проблемы но и СУЩЕСТВЕННО навредить безопасности наделав еще больше дыр. Так что будьте в достаточной степени внимательными при его установке. Теперь, собственно, приступим к самой установке модуля SuExec для web-сервера Apache. Что нам потребуется: 1. Сам компьютер с установленной ОС Linux 2. Пакет Apache. Взять его можно тут: http://mirror.metrocast.net/apache//httpd/. Поскольку я использую версию 2.2.19, то мне понадобится пакет httpd-2.2.19.tar.gz. Устанавливать мы будем, естественно, из исходников, потому и выбран этот вид пакета. 3. Пакет PHP. Взять его можно тут: http://www.php.net/get/php-5.3.6.tar.gz/from/a/mirror. Как вы возможно вы правильно обратили внимание, PHP мы тоже будем собирать из исходников. Ну что же, приступим: Для того чтобы во время установки включить опцию SuExec нам надо кое что добавить в строку конфигуратора. Взглянем более детально. В документации по установке Apache сказано, что для того чтобы установить web-сервер Apache проделайте следующую последовательность команд: gzip -d httpd-NN.tar.gz - достаем из архива #1 tar xvf httpd-NN.tar - достаем из архива #2 cd httpd-NN - переходим в директорию после разархивирования ./configure --prefix=PREFIX - конфигурируем make - готовим сконфигурированный вариант установки make install - устанавливаем подготовленную конфигурацию vi PREFIX/conf/httpd.conf - редактируем конфигурационные файлы Apache PREFIX/bin/apachectl -k start - запускаем сам Apachе, ничего сложного! Все просто и понятно. Теперь обратим внимание на "./configure --prefix=PREFIX" - что же такое префикс? А это ни что иное как место на диске сервера куда сам Apache будет установлен. Как видите, для того чтобы установить Apache, минимум что ему нужно, так это указать папку куда ему себя надо будет "прописать", установить и "привязать". НО.. есть одно "НО"... нам нужен SuExec!! Если мы установим Apache таким образом, то мы не получим вместе с ним установленный модуль SuExec. Почему? А потому что SuExec идет как "опция". Помните я говорил, что если у вас всего один домен или несколько доменов, которые вы используете для себя и только для себя (в своих личных целях, да мало-ли чего), когда не требуется обезопасить один домен от другого, то не стоит устанавливать модуль SuExec. Именно по этой причине разработчики Apache не включили поддержку SuExec в конфигурацию по-умолчанию. Итак, для того что бы установился модуль "suexec", нам необходимо понимать ТО, что мы будем делать дальше. У модуля первоначальной настройки Apache перед непосредственной установкой, есть вспомогательные ключи.. да-да и они нам очень помогут сейчас. Полный перечень ключей вы можете лицезреть тут: http://httpd.apache.org/docs/2.2/programs/configure.html. Смотрим внимательно... еще внимательнее... и "та-да-м!!" видим заветное "--enable-suexec". Но, увы - этого будет недостаточно.. потому рассмотрим этот этап более детально. Итак, поскольку эта статья относится к решению вопроса по установке модуля SuExec для web-сервера Apache, то я приведу все ключи конфигурации тут и объясню их подробно, нормальным человеческим языком. Итак: suEXEC configuration options --enable-suexec Как мы уже понимаем, эта опция включает поддержку suEXEC которая не включена в конфигурацию Apache по-умолчанию. Для того чтобы suexec заработал, должна быть указана по меньше мере одна опция вида "--with-suexec-xxxxx" вместе с "--enable-suexec". --with-suexec-bin=PATH Поскольку сам SuExec состоит из двух частей, то этой опцией мы указываем путь к создаваемому бинарному файлу suexec, туда где он должен быть расположен. Эту опцию использовать не обязательно, потому что в случае, если вы ее не укажете то конфигуратор Apache подставит значение по-умолчанию "--with-suexec-bin=/usr/sbin/suexec". Рекомендуется использовать это значение, но абсолютно не произойдет ничего страшного, если вы укажете свой путь, если вы захотите его изменить в целях безопасности. --with-suexec-caller=UID В этой опции надо будет указать конфигуратору, под каким пользователем запускается сам сервис Apache. Это должен быть только и именно этот пользователь (которого вы укажете), потому что, в том случае, если вы его потом смените в конфигурационном фале после установки, возможно, при последующем перезапуске сервиса Apache, сервис просто не поднимется, а функции SuExec перестанут работать совершенно точно. --with-suexec-userdir=DIR Тут надо указать где находится директория в которой suexec будет иметь право выполнять скрипты/программы пользователя домена. Значением по-умолчанию является "public_html". Но если у вас в качестве этой папки планируется какая-то другая с другим именем, ее необходимо тут указать. В том случае, если вы используете в Apache структуру виртуальных доменов/хостов с указанием различных папок пользователей для каждого пользователя, вам нужно определить/поместить эти папки в одну общую и указать имя общей папки в этой опции. Если, в этом случае, вы этого не сделаете, то опция Apache при вызове папки пользователя вида "~userdir" и cgi запросов, работать не будет! --with-suexec-docroot=DIR В этой опции надо определить корневую папку для устанавливаемого Apache. Эта папка используется для определения окружения в котором может работать SuExec. По-умолчанию эта директория принимает значение от опции --datadir и добавляет значение "/htdocs", например, если Apache сконфигурирован со значением опции "--datadir=/home/apache", то "/home/apache/htdocs" будет использоваться как корневая папка для окружения SuExec. --with-suexec-uidmin=UID Ну тут самое интересное. В SuExec есть очень хороший механизм, отсекания нежелательных пользователей для использования их в работе web-сервера Apache. В данной опции нужно указать минимальное значение UID (в цифрах) пользователей, ниже которым SuExec будет запрещать работать с папками/файлами пользователей посредством web-сервиса Apache. Очень удобно в том случае если вы хотите отделить/оградить/скомпоновать служебных пользователей отдельно от пользователей сервиса Apache. Если эта опция не указывается то данному элементу присваивается значение по-умолчанию равное 100. --with-suexec-gidmin=GID Тут все тоже самое что и с пользователями, только относится к группам пользователей. Если эта опция не указывается то данному элементу присваивается значение по-умолчанию равное 100. --with-suexec-logfile=FILE В этой опции, все, думаю, и так понятно. Тут мы указываем имя файла, куда будет записываться отчет о работе SuExec (операции, ошибки и пр.). По-умолчанию файлу назначается имя "suexec_log", а путь к нему указывается в опции конфигуратора Apache "--logfiledir". --with-suexec-safepath=PATH Тут мы указываем путь к безопасному окружению для выполнения CGI. Значение по-умолчанию "/usr/local/bin:/usr/bin:/bin". Практика показала, его лучше не трогать. Вот и все ключи по Suexec Теперь давайте сконфигурируем Apache: ./configure --prefix=/usr --with-apxs2=/usr/sbin/apxs --enable-suexec --with-suexec-bin=/usr/sbin/suexec --with-suexec-caller=apache --with-suexec-userdir=/www --with-suexec-docroot=/vhost --with-suexec-uidmin=2000 --with-suexec-gidmin=2000 Как видно из примера, мы указали "--prefix=/usr" и опции для suexec (--enable-suexec --with-suexec-bin=/usr/sbin/suexec --with-suexec-caller=apache --with-suexec-userdir=/www --with-suexec-docroot=/vhost --with-suexec-uidmin=2000 --with-suexec-gidmin=2000). Но я так же добавил "--with-apxs2=/usr/sbin/apxs", для чего, вы спросите? Как я говорил ранее, suexec состоит из 2 частей.. первую мы указали в опциях "--enable-suexec" - тут создается бинарный файл "suexec" который кладется в папку "/usr/sbin/" указанную в ключе "--with-suexec-bin=/usr/sbin/suexec", а вторая часть, это как раз и есть тот модуль который будет подключаться в сервис Apache. Для того чтобы этот модуль потом скомпилировался нам необходима система компиляции модулей Apache, она называется "APXS". Вот я ее и включил чтобы на выходе мы имели готовый скомпилированный модуль вида "mod_suexec.so". Важно! Примечание: возможно вам понадобится добавить ключ "--enable-so" для того чтобы компиляция этого модуля прошла успешно и она прописалась в конфиг Apache. Чтож, думаю этот этап у нас прошел успешно. Продолжим: Далее нам надо подготовить сконфигурированный вариант установки; Вперед! Готовим! make - и ждем пока пройдет много буковок по экрану. Если возникли проблемы во время прекомпиляции.. то скорее всего у вас недостает библиотек для самого процесса компиляции. Я думаю, скоро выложу статью и на эту тему тоже. Если же все прошло успешно, то выполняем: make install - и тоже ждем пока пройдет много текста по экрану (это может зависить от количества дополнительных опций указанных вами и от мощности компьютера). Если все прошло нормально, то поздравляю с установленным сервисом Apache с поддержкой функции SuExec! Далее надо отредактировать файл httpd.conf. Я не буду тут описывать каждое значение переменных в этом файле, поскольку подразумеваю то, что если вы решились ставить suexec, то вы понимаете синтаксис и значения содержащиеся в этом файле. Я лишь для наглядности приведу пример того что получилось у меня: вот файлик "/etc/httpd/httpd.conf" (убрал для краткости все закомментированные строки):

В этой статье я хочу рассказать вам о том, как настроить BIND9 Named сервер на Linux машинах и сделать из них связку основного и резервного ДНС сервера. Если у вас возникли вопросы по установке пакета BIND из репозиториев или из исходников. Отпишите об этом в комментариях и я постараюсь помочь вам в решении вашего вопроса. Итак, допустим, BIND установлен и что же дальше? Давайте проверим работает ли он в данный момент времени или нет? Примечание: такую проверку сделать нужно, потому что при установке пакета BIND, в некоторых дистрибутивах Linux, установщик сразу же его может запустить. Этого нам пока не нужно. Итак, если BIND запущен - остановите его. давайте заглянем в основной конфигурационный файл BIND (обычно он располагается по пути /etc/named.conf или /etc/bind/named): options { directory "/var/named"; }; zone "." IN { type hint; file "caching-example/named.root"; }; zone "localhost" IN { type master; file "caching-example/localhost.zone"; allow-update { none; }; }; zone "0.0.127.in-addr.arpa" IN { type master; file "caching-example/named.local"; allow-update { none; }; }; теперь давайте из этого конфига сделаем конфиг для MASTER зон: options { directory "/var/named"; allow-query { any; }; //указываем кто может обращаться за ДНС запросами к этому серверу - ставим "any", т.е. любой. version "No info"; // Прячем реальную версию ДНС сервера за надписью "No info". Тут можно всякое написать, в т.ч. и "заборное". listen-on { 192.168.1.100; 127.0.0.1; }; // Тут мы указываем на каких интерфейсах нам нужно ловить ДНС запросы, на 53 порту. allow-recursion { none; }; // отключаем рекурсию allow-transfer { 192.168.2.100; }; // Говорим MASTER серверу куда можно передавать зоны (обычно тут указывается адрес IP Slave сервера). }; zone "." IN { type hint; file "caching-example/named.root"; }; zone "localhost" IN { type master; file "caching-example/localhost.zone"; allow-update { none; }; }; zone "0.0.127.in-addr.arpa" IN { type master; file "caching-example/named.local"; allow-update { none; }; }; zone "domain1.ru" IN { // Вот собственно и первая наша внешняя зона, которую будет обслуживать наш сервер type master; // поскольку мы хотим чтобы для этой зоны наш сервер был первичным (MASTER), то и пишем тут "type master" file "caching-example/domain1.conf]"; // А это место расположения файла с описанием зоны. Название файла "domain1.conf" может быть произвольным. notify yes; // Говорим зоне MASTER сервера предупреждать SLAVE сервер о том что зона обновилась (если в нее вносили какие-то изменения). }; zone "domain2.ru[/b]" IN { // А это вторая зона. Таких зон может быть ооочень много. type master; // По аналогии. file "caching-example/domain2.conf"; // По аналогии. notify yes; // По аналогии. }; Вот и все. А теперь давайте посмотрим на другую машину. Также поставим там Bind как и для MASTER. Смотрим конфиг: ### КОД для SLAVE ### options { directory "/var/named"; allow-query { any; }; //указываем кто может обращаться за ДНС запросами к этому серверу - ставим "any", т.е. любой. version "No info"; // Прячем реальную версию ДНС сервера за надписью "No info". Тут можно всякое написать, в т.ч. и "заборное". listen-on { 192.168.2.100; 127.0.0.1; }; // Тут мы указываем на каких интерфейсах нам нужно ловить ДНС запросы, на 53 порту. allow-recursion { none; }; // отключаем рекурсию }; zone "." IN { type hint; file "caching-example/named.root"; }; zone "localhost" IN { type master; file "caching-example/localhost.zone"; allow-update { none; }; }; zone "0.0.127.in-addr.arpa" IN { type master; file "caching-example/named.local"; allow-update { none; }; }; zone "domain1.ru" IN { // Вот собственно и первая наша внешняя Slave зона, которую будет обслуживать наш сервер type slave; // поскольку мы хотим чтобы для этой зоны наш сервер был вторичным (SLAVE), то и пишем тут "type slave" file "caching-example/domain1-slave.conf"; // А это место расположения файла с описанием зоны. Название файла "domain1-slave.conf" может быть произвольным. Но лучше, для удобства помечать файлик маркером, так как сделал это я "-slave". masters { 192.168.1.100; }; // А вот Этой переменной мы указываем SLAVE серверу адрес MASTER сервера, откуда, собственно, мы и будем забирать описание и детали зоны "domain1.ru" }; zone "domain2.ru" IN { // А это вторая Slave зона. Таких зон может быть ооочень много. type slave; // По аналогии file "caching-example/domain2-slave.conf"; // По аналогии. masters { 192.168.1.100; }; // По аналогии. }; Обратите внимание, что в listen-on { 192.168.2.100; 127.0.0.1; }; стоит IP адрес отличный от адреса сервера MASTER, более того он находится в другой подсети. Это сделано для того чтобы, если вдруг подсеть #1 192.168.1.xxx "упадет" и перестанет отвечать на запросы... то резервный сервер в подсети #2 192.168.2.xxx - наш SLAVE останется доступным для общекорпоративной сети 192.168.xxx.xxx и он сможет продолжать обрабатывать ДНС запросы пользователей так, что они ничего не почувствуют. Как только MASTER сервер встанет в строй, работа продолжится в штатном режиме. Примечание: Если MASTER сервер выходит из строя очень важно понимать, что добавление новых записей на SLAVE сервер лучше не производить.. иначе база данных зон на MASTER сервере потеряет свою актуальность и хоть перебросить новые зоны на мастер сервер не составит труда, надо понимать, что в масштабах обновления записей к примеру 1000 и более, это будет очень тяжело. Потому, если аварийное состояние MASTER сервера затянется надолго.. то лучше объявить клиентам о технических работах и приостановить также работу и SLAVE сервера до момента полного восстановление работоспособности MASTER узла. Так же обратите внимание, что мы убрали allow-transfer { 192.168.2.100; }; - Для SLAVE сервера нет нужны передавать зону куда либо еще (за редким исключением), потому мы убрали эту опцию. Вот и все со SLAVE. Теперь можно добавлять на сервере MASTER файлы описания/содержания зоны и выкладывать их в соответствующие (указанные в файле конфигурации) директории. На сервер SLAVE эти файлы добавлять не нужно, SLAVE сервер сам их заберет с базы MASTER сервера. Пример такого файла: $ORIGIN . $TTL 1800 ; 30 minutes domain1.ru IN SOA ns1.domain1.ru. info.domain1.ru. ( 201108083 ; serial 1800 ; refresh (30 minutes) 900 ; retry (15 minutes) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) NS ns1.domain1.ru. NS ns2.domain1.ru. A 192.168.1.100 MX 10 mail.domain1.ru. $ORIGIN domain1.ru. * A 192.168.1.100 mail A 192.168.1.100 ns1 A 192.168.1.100 ns2 A 192.168.2.100 www A 192.168.1.100 О синтаксисе этого файла в интернете написано очень много, но если вопросы возникнут тут, я готов она них ответить и добавить в этот материал информацию о синтаксисе написания конфигурации зон. Теперь запустим поочередно Bind (named) демоны на MASTER и на SLAVE серверах и посмотрим как оно все работает. На сим все.. Надеюсь у вас все получится. С Уважением, Savaog [ l2x2l team ]