Настройка сервера
Большая и нетематическая статься на тему, как я игрался с VPS. Так как сайтик постоянно падал и тормозил, я собирался перетащить все свои проекты к другому хостеру.
К счастью (а может, и к сожалению), когда я уже почти настроил сервер, текущий хостер поправил проблему у себя, и сейчас все довольно стабильно работает. Так как у меня хостинг проплачен еще на год, с переездом я решил немного подождать. Конечно, если сайтик будет глючить/тормозит, то перееду.
В любом случае, я хочу заиметь VPSку и у меня для нее есть применения помимо сайта. К примеру, у меня есть устройства, которые пишут логи в базу данных. Cейчас они запускают php-скриптик на этом сервере, который пишет в базу. Это не очень то красиво и оптимально, на работает. С VPSкой можно было бы писать непосредственно в базу.
Если кто не в курсе, то сейчас есть два принципиально разных подхода к виртуализации серверов — аппаратная и на уровне ядра. Преимущество аппаратной в том, что можно установить любое ядро, кроме того, хостер не может оверселлить. KVM как раз и является такой аппаратной визуализацией, и с ним можно быть более-менее уверенным, что сколько ресурсов ты купил, столько тебе и дадут.
В качестве операционки я выбрал CentOS. Ее — потому, что среднее мнение по интернету — «самая стабильная ОС». Кроме того, все хостеры, которых я видел предлагали ее, а ведь тысяча леммингов не могут ошибаться. У меня не было особых предпочтений, и с ней я до этого не работал. CentOS мне очень даже понравилась, хотя проработал с ней очень мало и этого явно не достаточно, чтобы узнать все подводные камни.
По почте пришло письмо с рутовым паролем, IP и кучей другого (пока не нужного) добра. Сервер к этому моменту уже запущен и на нем работает чистая операционка.
Вбиваю IP своего сервера и подключюсь, логинюсь как root, пароль пришел по почте. Уря, все работает. Работает довольно быстро.
Да, пароль удобно скопировать вставить. Кто не знает, вставить в putty из буфера обмена можно правой кнопкой мышки.
Системой занято около 700Мб.
Первое, что я сделал — установил MC (ну не могу я без удобств).
Все поставилось без проблем, отлично.
Теперь самое время понять зачем нужны разные каталоги. Да, я предупреждал что не мега-линупсоид.
Я прочитал кучу туториалов, но вот этот, показался мне самым логичным и последовательным. Думаю, не имеет смысла переписывать его, напишу только заметки.
Остальное прошло без сучка и задоринки.
Естественно, это не оптимальная конфигурация, просто наброски как это предполагалось будет работать, но логика, думаю, ясна. Я остановился на вот такой конфигурации: в /etc/nginx/nginx.conf
Из этого конфига включаются все конфиги в /etc/nginx/conf.d пример такого конфига (да, я для тестов привязал домен imbed.ru):
Как видно, тут фактически объявляется переменная $host_name и включается конфиг общий для всех хостов (/etc/nginx/include.d/common.conf):
Собственно и все. Для добавления нового хоста достаточно скопировать конфиг в каталоге /etc/nginx/conf.d.
но, на #ru_embedded меня отговорили от этого. Проблема в том, что если злоумышленникам таки удастся выполнить свой php-код на сервере, то он может получить доступ к примеру, к почте. В результате, я выбрал вот такой вариант
Для того, чтобы в результате успешной атаки пострадало как можно меньше добра, испольуем chroot. Кто не знает — эта штука подменяет корень файловой системы. Получается, кул хацкер не сможет вылезти выше отведенной папки. У меня этой папкой будет /var/www.
опять редактируем /etc/php-fpm.d/www.conf
Ок. Конечно, это не помешает хацкеру получить доступ ко всем сайтам при взломе какого-то одного. Для изоляции сайтов друг от друга, я буду использовать настройку php open_basedir (в принципе, есть другой подход — запустить несколько пулов php-fpm, каждый со своим chroot'ом это надежнее, но скушает больше памяти, жалко).
Для этого, редактируем /etc/php.ini и меняем open_basedir = /dummy_path (вы ведь помните, что после chroot у нас корень — /var/www). /dummy_path не существует. Соответственно, по умолчанию скрипты никаких файловых операций производить не могут.
Теперь разрешим скриптам работать в пределах своего каталога. Да, при добавлении нового хоста придется редактирвоать и php.ini, не красиво, но ладно уж.
добавляем в конец php.ini:
Посмотреть, какой open_basedir испольуется сейчас, можно в выводе phpinfo:
Итак, теперь и сайты изолированы друг от друга.
Так как у каждого домена может быть больше одного пользователя, я решил для каждого домена делать группу пользователей:
ну, и добавлю себя в эту группу:
меняем владельцев того, что уже есть
теперь нужно сделать так, чтобы эта группа могла писать файлы
2 — сделает так, что група будет присваиваться всем создаваемым файлам
Если в каталоге уже есть какие-то файлы, то нужно сделать тоже самое со всеми файлами и папками. Можно пройтись chmod-ом с флагом -R, но он не отличает файлы и директории, и расставит лишние права на исполнение. Поэтому, лучше сделать вот так:
Дальше можно входить пользователем из группы imbed.ru (там, правда, только я) и уже что-то делать.
Редактируем /etc/my.cnf
Для того, чтобы локальный клиент смог подключиться, добавляем следующие строки в конец my.cnf
Я решил еще добавить root пользователя mysql. Как это можно сделать как написано тут.
Для того, чтобы подключить php к новым сокетам, редактирует php.ini:
Естественно, перезапускаем все сервисы.
Файлы, которые мне понадобилось скопировать в chroot:
Все эти файлы нужно скопировать в chroot с сохранением пути. К примеру, /etc/resolv.conf нужно скопировать в /var/www/etc/resolv.conf
Еще нужно создать каталог в chroot't /tmp и дать права php на запись туда — там будут находится файлы с сессиями.
Распаковываем:
Дальше, нужно создать каталог /config в каталоге phpMyAdmin и дать php права на запись.
Заходим в браузере
действуем в соответствии с инструкциями :)
Устанавливаем memecache и модуль для php:
Запускаем
Параметры редактируются в файле /etc/sysconfig/memcached. Вот его содержимое у меня:
В принципе, можно переключить на unix-сокеты, но пока и так работает.
Результат можно заценить сегодня-завтра вот тут
К счастью (а может, и к сожалению), когда я уже почти настроил сервер, текущий хостер поправил проблему у себя, и сейчас все довольно стабильно работает. Так как у меня хостинг проплачен еще на год, с переездом я решил немного подождать. Конечно, если сайтик будет глючить/тормозит, то перееду.
В любом случае, я хочу заиметь VPSку и у меня для нее есть применения помимо сайта. К примеру, у меня есть устройства, которые пишут логи в базу данных. Cейчас они запускают php-скриптик на этом сервере, который пишет в базу. Это не очень то красиво и оптимально, на работает. С VPSкой можно было бы писать непосредственно в базу.
Выбор хостера
В качестве нового хостера, я выбрал ihc.ru (реф. ссылка, буду рад, если вы зарегистрируетесь по ней). О нем довольно много хороших отзывов, у него есть KVM VPS'ки и есть скидка на 10% по коду SE12 :). Они подключены к msk-ix, что тоже хорошо — основная часть моих посетителей из России. Кроме того, они дают 7-дневный тестовый период. Цены с учетом скидки не сильно отличаются от hetzner'овских. При этом, у них нормальные сервера, а не десктопные компьютеры. Вообщем, отличные ребята, обязательно к ним приду.Если кто не в курсе, то сейчас есть два принципиально разных подхода к виртуализации серверов — аппаратная и на уровне ядра. Преимущество аппаратной в том, что можно установить любое ядро, кроме того, хостер не может оверселлить. KVM как раз и является такой аппаратной визуализацией, и с ним можно быть более-менее уверенным, что сколько ресурсов ты купил, столько тебе и дадут.
Запуск
Тут все очень просто — зарегистрировался на сайте, подтвердил мобильник (наверняка, это защита от того, чтобы не давать много тестовых периодов). И заказал тестовый период.В качестве операционки я выбрал CentOS. Ее — потому, что среднее мнение по интернету — «самая стабильная ОС». Кроме того, все хостеры, которых я видел предлагали ее, а ведь тысяча леммингов не могут ошибаться. У меня не было особых предпочтений, и с ней я до этого не работал. CentOS мне очень даже понравилась, хотя проработал с ней очень мало и этого явно не достаточно, чтобы узнать все подводные камни.
По почте пришло письмо с рутовым паролем, IP и кучей другого (пока не нужного) добра. Сервер к этому моменту уже запущен и на нем работает чистая операционка.
SSH
Для подключения к серверу я использовал Putty. Единственное, что нужно поправить — кодировка:Вбиваю IP своего сервера и подключюсь, логинюсь как root, пароль пришел по почте. Уря, все работает. Работает довольно быстро.
Да, пароль удобно скопировать вставить. Кто не знает, вставить в putty из буфера обмена можно правой кнопкой мышки.
Поиграемся
Первое, что делаем — смотрим свободное место на диске:df -h
Системой занято около 700Мб.
Первое, что я сделал — установил MC (ну не могу я без удобств).
yum install mc
Все поставилось без проблем, отлично.
Теперь самое время понять зачем нужны разные каталоги. Да, я предупреждал что не мега-линупсоид.
Устанавливаем сервер
Я решил устанавливать nginx+php-fpm, как самое современное решение :)Я прочитал кучу туториалов, но вот этот, показался мне самым логичным и последовательным. Думаю, не имеет смысла переписывать его, напишу только заметки.
- При добалении репозитория EPEL, его версия может отличаться у автора было:
rpm -ihv https://mirror.yandex.ru/epel/6/i386/epel-release-6-6.noarch.rpm
у меня уже стало:
rpm -ihv https://mirror.yandex.ru/epel/6/i386/epel-release-6-7.noarch.rpm
Ествественно, у вас цифры могут быть еще больше :)
- Для того, чтобы быть последовательным, поменял в /etc/php-fpm.d/www.conf пользователя и групу с apache на nginx :) Параметры пула php-fpm выставил как тут, потом посмотрим, как оно будет работать и сколько памяти кушать. Заранее не предскажешь.
- php.ini я сразу взял предназначенный для продакшина (/usr/share/doc/php-common/) и запретил самые опасные функции:
disable_functions = "escapeshellcmd, exec, passthru, popen, proc_close, proc_open, proc_nice, proc_get_status, proc_terminate, putenv, shell_exec, system, openlog, syslog, dl, mail, chown, chmod, chgrp" expose_php = Off
Остальное прошло без сучка и задоринки.
Nginx
Теперь конфигурируем nginx. Я хотел, чтобы для добавления новых хостов нужно было переписывать как можно меньше кода. Раз у меня уже есть сервер, то, скорее всего, на нем захостятся все мои проекты.Естественно, это не оптимальная конфигурация, просто наброски как это предполагалось будет работать, но логика, думаю, ясна. Я остановился на вот такой конфигурации: в /etc/nginx/nginx.conf
user nginx;
worker_processes 1; # у нас - одно ядро
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
include /etc/nginx/conf.d/*.conf;
}
Из этого конфига включаются все конфиги в /etc/nginx/conf.d пример такого конфига (да, я для тестов привязал домен imbed.ru):
server {
listen 80;
server_name imbed.ru;
set $host_name "imbed.ru";
include "/etc/nginx/include.d/common.conf";
}
Как видно, тут фактически объявляется переменная $host_name и включается конфиг общий для всех хостов (/etc/nginx/include.d/common.conf):
root /var/www/$host_name;
charset utf-8;
location / {
index index.php index.html index.htm;
}
error_page 404 /404.html;
location = /404.html {
root /usr/share/nginx/html;
}
# redirect server error pages to the static page /50x.html
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
location ~ \.php$ {
fastcgi_pass unix:/tmp/php-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /$host_name/$fastcgi_script_name; # эта строка с учетом chroot, смотри дальше :)
include fastcgi_params;
}
Собственно и все. Для добавления нового хоста достаточно скопировать конфиг в каталоге /etc/nginx/conf.d.
Файловая структура
Теперь самое сложное — как и где располагать файлы сайтов. Сначала, я выбрал такую вот структуру (ее использует мой текущий хостер):
/domains/имя_домена/тип_данных/
к примеру, /domains/bsvi.me/public_html/
или /domains/tqfp.org/mail/
но, на #ru_embedded меня отговорили от этого. Проблема в том, что если злоумышленникам таки удастся выполнить свой php-код на сервере, то он может получить доступ к примеру, к почте. В результате, я выбрал вот такой вариант
/var/www/имя_домена/
Для того, чтобы в результате успешной атаки пострадало как можно меньше добра, испольуем chroot. Кто не знает — эта штука подменяет корень файловой системы. Получается, кул хацкер не сможет вылезти выше отведенной папки. У меня этой папкой будет /var/www.
опять редактируем /etc/php-fpm.d/www.conf
...
chroot = /var/www
chdir = /
...
Ок. Конечно, это не помешает хацкеру получить доступ ко всем сайтам при взломе какого-то одного. Для изоляции сайтов друг от друга, я буду использовать настройку php open_basedir (в принципе, есть другой подход — запустить несколько пулов php-fpm, каждый со своим chroot'ом это надежнее, но скушает больше памяти, жалко).
Для этого, редактируем /etc/php.ini и меняем open_basedir = /dummy_path (вы ведь помните, что после chroot у нас корень — /var/www). /dummy_path не существует. Соответственно, по умолчанию скрипты никаких файловых операций производить не могут.
Теперь разрешим скриптам работать в пределах своего каталога. Да, при добавлении нового хоста придется редактирвоать и php.ini, не красиво, но ладно уж.
добавляем в конец php.ini:
[HOST=imbed.ru]
open_basedir = /imbed.ru
Посмотреть, какой open_basedir испольуется сейчас, можно в выводе phpinfo:
Итак, теперь и сайты изолированы друг от друга.
Права
Теперь нужно назначить этому всему права. Тут вся идея в том, что по умолчанию сервер может только читать файлы. А во всех каталогах, куда пользователь может загрузить контент, сервер должен уметь и писать. Неплохо бы запретить php запретить исполнять файлы из таких каталогов.Так как у каждого домена может быть больше одного пользователя, я решил для каждого домена делать группу пользователей:
groupadd imbed.ru
ну, и добавлю себя в эту группу:
usermod -a -G imbed.ru bsvi
меняем владельцев того, что уже есть
chown -R root:imbed.ru /var/www/imbed.ru
теперь нужно сделать так, чтобы эта группа могла писать файлы
chmod 2775 /var/www/imbed.ru
2 — сделает так, что група будет присваиваться всем создаваемым файлам
Если в каталоге уже есть какие-то файлы, то нужно сделать тоже самое со всеми файлами и папками. Можно пройтись chmod-ом с флагом -R, но он не отличает файлы и директории, и расставит лишние права на исполнение. Поэтому, лучше сделать вот так:
find /var/www/imbed.ru -type d -exec chmod 2775 {} +
find /var/www/imbed.ru -type f -exec chmod 0664 {} +
Дальше можно входить пользователем из группы imbed.ru (там, правда, только я) и уже что-то делать.
Работа с файлами
Для работы с файлами я обычно использую far manager. В принципе, на сервере уже стоит OpenSSH, который поддерживает SFTP. Осталось только прикрутить этот sftp к far'у. Оказывается, для этого есть плагин, который называется NetBox. Последняя версия, правда, у меня падала. Пришлось откатиться на предпоследнюю и она отлично работает. Большое преимущетво собственного SFTP в отличии от FTP хостера в том, что нет таймаута в 10минут.Mysql
Для общения с mysql буем использовать unix-сокеты. Они быстрее. Как как php должен иметь доступ к сокету, сокет нужно расположить в chroot'овской директории (я выбрал /var/www/mysql). Этой директории нужно дать права на запись php и mysql.Редактируем /etc/my.cnf
socket=/var/www/mysql/mysql.sock
Для того, чтобы локальный клиент смог подключиться, добавляем следующие строки в конец my.cnf
[client]
socket=/var/www/mysql/mysql.sock
Я решил еще добавить root пользователя mysql. Как это можно сделать как написано тут.
Для того, чтобы подключить php к новым сокетам, редактирует php.ini:
pdo_mysql.default_socket=/mysql/mysql.sock
mysql.default_socket =/mysql/mysql.sock
mysqli.default_socket =/mysql/mysql.sock
Естественно, перезапускаем все сервисы.
service php-fpm restart
service mysqld restart
service nginx restart
PHP в chroot'e
PHP в пытается обратиться к некоторым файлам за пределами www каталога. Естественно, он их там не находит, так как сам находится с chroot'е. Сервер отдает 500 ошибку.Файлы, которые мне понадобилось скопировать в chroot:
/etc/localtime
/etc/nsswitch.conf
/etc/resolv.conf
/lib64/libnss_dns-2.12.so
/lib64/libnss_dns.so.2
/usr/share/zoneinfo
Все эти файлы нужно скопировать в chroot с сохранением пути. К примеру, /etc/resolv.conf нужно скопировать в /var/www/etc/resolv.conf
Еще нужно создать каталог в chroot't /tmp и дать права php на запись туда — там будут находится файлы с сессиями.
Установка phpMyAdmin
Качаем его вот тут. Заливаем на сервер (за одно и плагин к фару протестируем).Распаковываем:
tar zxf phpMyAdmin-3.5.4-all-languages.tar.gz
Дальше, нужно создать каталог /config в каталоге phpMyAdmin и дать php права на запись.
Заходим в браузере
https://imbed.ru/каталог_php_my_admin/setup
действуем в соответствии с инструкциями :)
Memcache
Так как доступ к памяти намного быстрее, чем к диску, кэш лучше хранить в памяти. Для этого, я решил настроить memcache.Устанавливаем memecache и модуль для php:
yum install memcached
yum --enablerepo=remi install php-pecl-memcache
Запускаем
chkconfig --levels 235 memcached on
service memcached start
Параметры редактируются в файле /etc/sysconfig/memcached. Вот его содержимое у меня:
PORT="11211"
USER="memcached"
MAXCONN="1024"
CACHESIZE="64"
OPTIONS="-l 127.0.0.1"
В принципе, можно переключить на unix-сокеты, но пока и так работает.
Результат можно заценить сегодня-завтра вот тут
21 комментарий
А все потому что он не deb-based, а rpm-based, а рпм это говнище. Как начнешь ставить и настраивать что-то — поймешь… А когда переглючит RPM базу материться будеш и не оптому что линукс гавно, а потому что рпм криво задуман изначально. )
Я это все проходил, много лет просидел на рпм-базед дитсрибах, и когда дебиан поставил первый раз, то рвал на себе волосы что с первого дня это не сделал, потому что по сравнению с редхадовскими дистрибами Дебиан был идеалом для подражания, все делалось автоматически, продумано и правильно, правда были свои особенности из-за старых привычек, но то уже не относится к делу… И что касается серверов, то после того как я их ставить начал на базе Дебиана на все настройки на порядок меньше времени пришлось тратить и поддерживать легче. Так вот для сервера лучше всего именно DEB-based дистриб, таже убунта или минт будут лучше редхата, и думаю по стабильности пакета тоже. Я конечно допускаю что за последние лет 8 как я отказался от RPM-базед что-то изменилось в лучшую сторону, но я сильно сомневаюсь, так как ни кто RPM не переписывал, а только костыли цепляли и марафеты… Так что прими правильное решение, поставь DEB-based дистриб, а лучше сразу Дебиан(так как убунта и минт строятся на нестабильных пакетах дебиана).
Кстати пару дней назад, вышла новая версия Минта. :)
Судя по гугл трендам, скоро лучше будет ставить убунтус, так как сообщество больше, а CentOS и debian одинаково популярны
В принципе, я не против попробовать и debian, другое дело, что уже все поставил и сейчас менять операционку — не комильфо. Когда буду ставить в следующий раз — попробую дебиан.
Но это вовсе не показатель.
Что же касается сервера нужно гнаться за стабильностью а не как не за трендами. убунта и минт по стабильности чуть хуже чем дебиан. Стабильность — это комплекс наличия глюков и багов и потенциальной возможности выстрелить себе в ногу смотря при этом в небо левой пяткой.
То что ты ссылку с ЛОРа привел, то болтовня тролей. Изучи вопрос по нескольким форумам на тролесбродникам. Центос и стабильность это непересекающиеся прямые. Так как ты неловким движением при установке любого пакета пложишь на лопатки в вывихом позвоночника своему серверу, вот и думай теперь какая тебе нужна стабильность, полная или на кастылях…
Странно, что ты считаешь центос нестабильной. Это несмотря на rpm — это таки потомок red hat'а, который используется большими компаниями, и там падение многого стоит. Кроме того, сервер на то и сервер, чтобы поставить там все один раз, а потом только секюрити апдейты делать.
Хотя, по тому, что я прочитал — дебиан и центос — примерно на равне, никто не лучше, никто не хуже.
Сомневаюсь что ты это сделаешь. Так что учитывай это тоже. Дело конечно твое, только потом не кричи что линукс-гавно, бывают только идиотские по идеологии дистрибутивы и админы с недостаточным опытом, когда это вместе это «гремучая смесь»… И кстати поверь, все линуксоиды такими когда то были, выбирали-ставили-пробовали-учились-ошибались-исправлялись-ставили-пробовали-исправлялись..., но этот путь можно сократить сразу если посмотреть в сторону дебиана. ;)
Посмотри комменты вот тут, к примеру:
livestreet.ru/blog/dev_documentation/10626.html
Таких отзывов о репозиториях центоса я не встречал.
А ты как хотел пару раз мышкой клацнуть? Нет друг, ты в линукс вляпался. ;)
Мог бы и поверить человеку который в линуксе с 1998го и видавшего всякого за это время, я уж молчу о об наслышаного об опыте друзей с линуксовки за 10 лет её существования… В общем как хочешь. ;) Ставь центос и не смотри на дибианы ;)
Кстати, рад тя тут видеть.
Итак,
виртуализация KVM, CentOS: 1045 баллов
виртуализация KVM, Debian: 1341 баллов
виртуализация OpenVZ, Debian: 365 баллов
Итак, debian практически на 30% быстрее(!). KVM виртуализация однозначно рулит.
Полный вывод тестов тут.
updateupgrade, а потом устанавливать пакеты из официальных.зачеркиваниятожеработают. Круто. ))