Перейти к публикации

CentOS

  • записей
    13
  • комментариев
    1 257
  • просмотр
    17 371

Об этом блоге

Всё, что касается администрирования CentOS.

Записи в этом блоге

Настройка чат сервера Matrix Synapse и клиента Riot

Для меня остается открытым вопрос использования бесплатного корпоративного чата, не определился с ним. В данной статье хочу рассмотреть установку и настройку бесплатного чат сервера Matrix Synapse и web клиента для него Riot. В целом, проект мне показался интересным и вполне рабочим, но со своими нюансами. Далее постараюсь подробно раскрыть эту тему.   Информация по Matrix Synapse без проблем гуглится, поэтому не буду подробно рассказывать, что это такое. Кратко пройдемся по основному: Matrix — это открытый протокол для децентрализованной коммуникации. Он может быть реализован в различных серверах и мессенджерах. Synapse — локальный сервер, который работает на протоколе matrix, обеспечивает возможность подключения и общения клиентов. Riot — клиент, который может подключаться к любому серверу, работающему по протоколу matrix, в том числе к synapse. Представлен в виде десктропной или web версии, которую можно установить на свой сервер. Далее мы займемся установкой локальной версии Matrix Synapse для подключения своих клиентов. На этом же сервере разместим веб клиента Riot. Все это дело снабдим ssl сертификатом. В общем, на выходе должны получить готовое бесплатное локальное решение для корпоративного чата. Сразу хочу предупредить, что мое описание не подходит под готовое руководство, которое позволит простым копипастом все настроить. Это руководство именно по matrix и riot, вы должны как минимум уметь настраивать web сервер с nginx, устанавливать сертификаты, проксировать запросы, если вам это понадобится. Установка Matrix Synapse home server Я буду устанавливать чат сервер на CentOS 7. Сразу обращаю внимание, что у меня на сервере будет отключен selinux. Как это сделать, смотрите в статье по настройке сервера, ссылка на которую выше. Для работы synapse server необходим Python 2.7, который в CentOS 7 установлен по-умолчанию. Убедиться в этом можно введя в консоли: # python -V Python 2.7.5 Сервер чата synapse может использовать различные базы данных. По-умолчанию, он работает с SQLite, что подходит только для теста. В продакшене использовать эту базы плохое решение. Но даже для теста у меня не получилось настроить работу с SQLite. По-умолчанию, в CentOS устанавливается очень старая версия базы. При ее использовании возникает ошибка и сервер не работает. Я обновил базу до последней версии, но как оказалось, с ней тоже возникают проблемы. Я почитал на эту тему обсуждения и понял, что проблема распространенная, а не уникальная, поэтому решил в ней не разбираться. Вместо этого сразу буду использовать postgresql, что является самым надежным и разумным выбором. С этого и начнем. Установим postgresql на Centos 7. У меня установлена следующая версия системы: # cat /etc/redhat-release CentOS Linux release 7.4.1708 (Core) Устанавливаю соответствующий моей версии репозиторий: # rpm -Uvh https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-7.4-x86_64/pgdg-centos10-10-2.noarch.rpm Ставим самую свежую на момент написания статьи версию postgresql: # yum install postgresql10-server postgresql10-contrib Инициализируем базу данных: # /usr/pgsql-10/bin/postgresql-10-setup initdb Редактируем конфигурационный файл для включения MD5 аутентификации. # mcedit /var/lib/pgsql/10/data/pg_hba.conf Меняем строки в самом конце: host all all 127.0.0.1/32 ident host all all ::1/128 ident на host all all 127.0.0.1/32 md5 host all all ::1/128 md5 Запускаем PostgreSQL и добавляем в автозагрузку: # systemctl start postgresql-10 # systemctl enable postgresql-10 Заходим в систему под пользователем postgres: # su - postgres Создаем пользователя базы данных: $ createuser synapse Запускаем консольный клиент для работы с базой данных: $ psql Задаем пароль userpass для только что созданного пользователя: # ALTER USER synapse WITH ENCRYPTED password 'userpass'; Создаем базу данных для чат сервера matrix synapse: # CREATE DATABASE synapse ENCODING 'UTF8' LC_COLLATE='C' LC_CTYPE='C' template=template0 OWNER synapse; Выходим из консоли управления и учетной записи postgres. # \q # exit Установим еще несколько пакетов, необходимых для взаимодействия synapse с postgresql. # yum install postgresql-devel libpqxx-devel.x86_64 Подготовительные действия выполнили, теперь можно устанавливать сам сервер. Для этого установим необходимые зависимости. # yum install libtiff-devel libjpeg-devel libzip-devel freetype-devel lcms2-devel libwebp-devel tcl-devel tk-devel redhat-rpm-config python-virtualenv libffi-devel openssl-devel # yum groupinstall "Development tools" Устанавливаем менеджер пакетов Python — pip. # wget https://bootstrap.pypa.io/get-pip.py # python get-pip.py Создаем виртуальную среду для приложения synapse. Она используется для изоляции отдельного python проекта. Проект будет использовать свои собственные директории и библиотеки, без взаимодействия с глобальным окружением. # virtualenv -p python2.7 ~/.synapse # source ~/.synapse/bin/activate Устанавливаем необходимые пакеты питона. # pip install --upgrade pip virtualenv six packaging appdirs psycopg2 Обновляем setuptools: # pip install --upgrade setuptools Устанавливаем сам сервер matrix synapse. # pip install https://github.com/matrix-org/synapse/tarball/master Перед запуском сервера, необходимо создать файл конфигурации. Делаем это. # cd ~/.synapse # python -m synapse.app.homeserver --server-name chat.serveradmin.ru --config-path homeserver.yaml --generate-config --report-stats=yes Я использую доменное имя для своего чат сервера chat.serveradmin.ru. Обращаю внимание на этот параметр. Он важен, если вы захотите использовать полноценный ssl сертификат и https подключения. Используйте реальное доменное имя, на которое потом будете получать сертификат. После выполнения команды вы получите примерно такой вывод: A config file has been generated in 'homeserver.yaml' for server name 'chat.serveradmin.ru' with corresponding SSL keys and self-signed certificates. Please review this file and customise it to your needs. If this server name is incorrect, you will need to regenerate the SSL certificates По умолчанию, в файле конфигурации homeserver.yaml будет указано использовать базу данных SQLite. Комментируем строки, отвечающие за эту настройку и добавляем параметры для подключения созданной ранее postgresql базы. #database: # The database engine name #name: "sqlite3" # Arguments to pass to the engine #args: # Path to the database #database: "/root/.synapse/homeserver.db" database: name: psycopg2 args: user: synapse password: userpass database: synapse host: localhost cp_min: 5 cp_max: 10 Обращаю внимание на отступы в файле конфигурации. Они принципиально важны. Должно быть именно так, как показано — database без отступа, name, args один пробел с начала строки. Все остальное — два пробела. На этом установка сервера закончена, двигаемся дальше. Использование ssl сертификата Let’s Encrypt Прежде чем начать настройку сервера, установим на него полноценный ssl сертификат. Если вам это не нужно, можно пропустить данный пункт. Просто посмотреть на чат можно и с самописным сертификатом, который мы получили ранее. Но есть один нюанс. Клиент Riot, который я буду использовать для подключения к серверу, не будет работать с самописным сертификатом. Он будет ругаться на него во время подключения. Так что если вы хотите полноценно протестировать работу мессенджера Riot в связке с matrix synapse, придется установить нормальный сертификат. Мой сервер с чатом напрямую не смотрит в интернет. Я буду проксировать все подключения к нему через web сервер, на котором установлен nginx. Поэтому получение сертификата нужно выполнять именно на нем. Если у вас matrix сервер будет смотреть напрямую в интернет, то настраивать получение ssl сертификата надо именно на нем. Прежде чем получить сертификат, нарисовал примерно такой конфиг виртуального домена для nginx. server { listen 80; server_name chat.serveradmin.ru; location /.well-known { root /web/sites/chat.serveradmin.ru/www/; } } Подробно про получение сертификатов Let’s Encrypt я рассказывал в статье по настройке веб сервера. За всеми подробностями можете заглянуть туда. Здесь же без подробных пояснений выполняем необходимые действия. Устанавливаем certbot. # yum install certbot Запускаем запрос сертификата. # certbot certonly При первом запуске на сервере, нужно будет зарегистрировать новую учетную запись на сервер и указать почтовый ящик. Я все это уже ранее делал, так что просто выбираю тип подтверждения домена: 2: Place files in webroot directory (webroot) Далее указываю имя домена: Please enter in your domain name(s) (comma and/or space separated) (Enter 'c' to cancel): chat.serveradmin.ru Указываю директорию веб сервера: Input the webroot for chat.serveradmin.ru: (Enter 'c' to cancel): /web/sites/chat.serveradmin.ru/www Сертификат получил. Дальше рисую следующий конфиг для виртуального хоста nginx уже для работы по https. upstream matrix { server 77.37.225.129:22991; } server { listen 80; server_name chat.serveradmin.ru; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name chat.serveradmin.ru; ssl on; ssl_certificate /etc/letsencrypt/live/chat.serveradmin.ru/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/chat.serveradmin.ru/privkey.pem; ssl_session_timeout 5m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_dhparam /etc/ssl/certs/dhparam.pem; ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH'; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; location /.well-known { root /web/sites/chat.serveradmin.ru/www/; } location / { client_max_body_size 50M; proxy_set_header Connection ""; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Frame-Options SAMEORIGIN; proxy_pass http://matrix; } } На сервере 77.37.225.129 сделан проброс внешнего порта 22991 на локальный 8008. На этом порту работает synapse по незащищенному соединению. Редиректить надо именно на этот порт, так как если сделать переадресацию на защищенный порт, который работает со своим сертификатом, будут проблемы при совместной работе этого локального сертификата и внешнего от Let’s Encrypt. С сертификатом и самим сервером synapse разобрались. Дальше я предлагаю сначала установить и настроить бесплатный web клиент для чата — Riot. Если он вам не нужен, можно сразу переходить к настройке самого сервера. Установка клиента Riot Вам не обязательно устанавливать собственную версию веб клиента riot. Вы можете использовать публичный web клиент https://riot.im/app/, и с его помощью подключаться к своему серверу. Для этого надо указать адрес своего сервера во время подключения. Чтобы подключиться через riot, у вас обязательно должно быть настроено подключение по https. По обычному протоколу подключиться не получится, будет ошибка. Can't connect to homeserver - please check your connectivity and ensure your homeserver's SSL certificate is trusted. или вот такая: Can't connect; check your SSL settings and trust the server Я и так и сяк пробовал, но оказалось проще и быстрее сделать ssl сертификат от Let’s Encrypt, чем разбираться с ошибками. В общем, получайте сертификат любым удобным для вас способом. Для того, чтобы установить собственный web клиент riot достаточно скачать его исходники и разместить их на веб сервере. Последнюю версию можно скачать отсюда — https://github.com/vector-im/riot-web/releases. Далее я использую свежую версию на момент написания статьи. # wget https://github.com/vector-im/riot-web/releases/download/v0.13.3/riot-v0.13.3.tar.gz # tar -xzvf riot-v0.13.3.tar.gz Дальше копируем содержимое распакованной директории в корневую папку веб сервера для домена, который вы назначили. В моем примере это /web/sites/riot.serveradmin.ru/www/. Рисуем примерно такой конфиг для публикации riot в web. # cat /etc/nginx/conf.d/riot.conf server { listen 80; server_name riot.serveradmin.ru; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name riot.serveradmin.ru; root /web/sites/riot.serveradmin.ru/www/; index index.php index.html index.htm; access_log /web/sites/riot.serveradmin.ru/log/access.log main; error_log /web/sites/riot.serveradmin.ru/log/error.log; ssl on; ssl_certificate /etc/letsencrypt/live/riot.serveradmin.ru/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/riot.serveradmin.ru/privkey.pem; ssl_session_timeout 5m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_dhparam /etc/ssl/certs/dhparam.pem; ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH'; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; location /.well-known { root /web/sites/riot.serveradmin.ru/www/; } } Перечитываем конфиг nginx и можно заходить по указанному веб адресу для использования своего клиента riot. В директории с клиентом есть конфигурационный файл config.sample.json. Переименуйте его в config.json и измените параметр сервера подключения по-умолчанию. Укажите свой. "default_hs_url": "https://chat.serveradmin.ru", Этого достаточно для использования своего собственного веб клиента riot по настроенному адресу. Настройка matrix synapse сервера Запускаем установленный сервер. # source ~/.synapse/bin/activate # synctl start Если увидели такой же вывод, значит все в порядке. Проверим, на каких портах запустилась служба чата. # netstat -tulnp | grep python tcp 0 0 0.0.0.0:8448 0.0.0.0:* LISTEN 26827/python2.7 tcp 0 0 0.0.0.0:8008 0.0.0.0:* LISTEN 26827/python2.7 Порт 8448 для шифрованных соединений, 8008 для обычных. Создание учетной записи администратора Создадим первую учетную запись администратора. # register_new_matrix_user -c homeserver.yaml http://localhost:8008 New user localpart [root]: admin Password: Confirm password: Make admin [no]: yes Sending registration request... Success. Теперь можно пройти по адресу https://chat.serveradmin.ru и залогиниться в систему под созданным пользователем администратора. Если вы не настраивали проксирование через nginx, то можно зайти напрямую на сервер с чатом по его ip адресу — http://192.168.13.31:8008 В моем случае я вижу ту же самую страницу. В веб интерфейсе нет практически никаких настроек. Вы можете только создать нужные комнаты и изменить некоторые настройки пользователя. Так же вы можете заходить и общаться в чатах, но стандартный серверный интерфейс для этого беден и неинтересен. Позже мы подключимся к серверу более удобным клиентом Riot, а пока изменим некоторые настройки сервера. Включение свободной регистрации Первым делом вам надо решить, будет ли у вас открыта свободная регистрация пользователей, или вы будете каждого создавать вручную. За это отвечает параметр в файле конфигураций homeserver.yaml enable_registration: True Я разрешил свободную регистрацию в своем примере. По-умолчанию она запрещена. Если у вас будет публичный чат-сервер, то обязательно надо настроить каптчу. В synapse уже интегрирована гугловская reCAPTCHA. Чтобы она заработала, вам надо зарегистрировать свой сайт в гугле — https://developers.google.com/recaptcha/, затем указать следующие параметры в конфиге: recaptcha_public_key: PUBLIC_KEY recaptcha_private_key: PRIVATE_KEY enable_registration_captcha: true Public и Private ключи вы получаете после регистрации каптчи для вашего доменного имени в гугле. Настройка почтовых уведомлений Сервер корпоративного чата synapse matrix умеет отправлять почтовые уведомления на различные события. Настройка этих событий выполняется в пользовательских настройках. Но чтобы сервер мог отправлять оповещения, их надо настроить в конфигурации самого сервера. Для этого в конфиге рисуем такие параметры для отправки почты через локальный сервер. email: enable_notifs: true smtp_host: "localhost" smtp_port: 25 notif_from: "Your Friendly %(app)s Home Server <chat@serveradmin.ru>" app_name: Matrix template_dir: res/templates notif_template_html: notif_mail.html notif_template_text: notif_mail.txt notif_for_new_users: True riot_base_url: "https://riot.serveradmin.ru" Перезапускаем сервер и проверяем. # source ~/.synapse/bin/activate # synctl restart Я сразу же получил ошибку на тему того, что файл notif_mail.html не найден. Долго разбирался, в чем может быть проблема. Потом все-таки понял, когда скачал вручную полные исходники сервера из github, что у меня не хватает директории res/templates. Похоже, их просто забыли положить в сборку, которая качается через pip. Так что вам нужно будет сделать то же самое, если этот баг не пофиксят к тому моменту, как вы будете пробовать настраивать свой сервер чата. Я поступил вот так: # cd /usr/src # git clone https://github.com/matrix-org/synapse # mv /usr/src/synapse/res ~/.synapse После этого еще раз перезапускайте сервер и проверяйте. Я очень много времени потратил на отладку оповещений. Так и не понял, как их внятно настроить и когда они будут срабатывать. Вроде в профиле все включаю, ухожу юзером в офлайн, шлю ему в чат письмо. Иногда оповещение приходит через 10 минут, иногда нет. Где настраивается этот интервал в 10 минут — не понял. Вроде в основном конфиге есть некоторые намеки на этот интервал, но явно не указано, что он влияет на время, через которое будет отправлено оповещение на почту. По логике, его бы надо сразу отправлять, если пользователя нет, а не ждать 10 минут. Наверно есть какой-то механизм аккумулирования оповещений, возможно у него какая то своя логика, которую я не понял, поэтому мне не до конца ясно, как работают оповещения. Шаблон самих сообщений по-умолчанию очень корявый, по нему толком не понятно, где и в каком чате произошло событие. Вот пример: Я кое-как восстановил последовательность событий по сообщениям в чатах, но в целом все не очевидно. Этот момент можно самому доработать, шаблоны можно настраивать. Но это нужно разбираться и тратить время. В этом моменте продукт явно не готов в текущем виде к продуктовому использованию. Так же у меня не получилось настроить оповещения через внешние почтовые сервисы. В частности, пробовал через ящик на Яндексе, но мне ничего не приходило. То ли проблема с почтовыми настройками, то ли с самими оповещениями, не разобрался. Дебажить эти моменты неудобно. Лог самого сервера завален спамовыми запросами от web клиентов. В общем, тема неоднозначная и неочевидная. Документации по ней нету. Разобраться, в принципе, можно, по идее то работает, но надо тратить время. Автозагрузка чат сервера со стартом системы Из коробки никакое решение для автостарта сервиса после загрузки системы не предлагается, если вы используете систему centos. Для debian есть готовый пакет, который можно просто установить в систему через apt. В комплекте будет конфиг для systemd. У нас же сервер запускается из домашней директории root в virtualenv, что не очень удобно для настройки автозагрузки. Но все решаемо. Рисуем такой конфиг для systemd по следующему пути — /etc/systemd/system/synapse.service. [Unit] Description=Synapse Matrix homeserver [Service] Type=simple User=root Group=root WorkingDirectory=/root/.synapse ExecStart=/root/.synapse/bin/python -B -u -m synapse.app.homeserver -c /root/.synapse/homeserver.yaml ExecStop=/root/.synapse/bin/synctl stop /root/.synapse/homeserver.yaml [Install] WantedBy=multi-user.target Вообще, не очень правильно, что у нас сервер работает от root. Но так как у меня это тест, я не стал заморачиваться и создавать отдельного юзера и делать все под ним. Да и вспомнил об этом только в самом конце, когда этот конфиг рисовал. Добавляем сервер в автозагрузку и запускаем: # systemctl enable synapse # systemctl start synapse Проверим, все ли в порядке. # systemctl status synapse Не очень удобно, что сервер будет дублировать свои логи в системный лог /var/log/messages, но это уже мелочи. Если реально будет мешать, можно это дело поправить. Заключение Дальше можно создавать комнаты, регистрировать юзеров, менять настройки. Не буду это описывать, каждый сам может сделать, чтобы понять продукт и познакомиться с ним получше. В целом, впечатление у меня осталось неоднозначное. Продукт неплохой, особенно в части заявленного функционала. Я нигде не видел такого же функционала бесплатно. Если у вас много времени и желания, то можно допилить до подходящего уровня, когда будет нормально работать все, что вас интересует. Но мелкие баги и ошибки, с которыми я сталкивался в процессе настройки не вселяют в меня уверенности, что все это будет стабильно работать длительное время. Я на первое место всегда ставлю стабильность и надежность работы, даже в ущерб функционалу. Я не люблю решения, которые требуют много сил на свою поддержку. В итоге они могут оказаться дороже коммерческих продуктов. Уже сейчас могу представить, сколько вылезет ошибок при очередном обновлении. Вот мое краткое резюме по плюсам и минусам synapse matrix на основе того, что я успел попробовать и проверить. Плюсы: Обширный бесплатный функционал. Свой локальный сервер Гибкие настройки email оповещений. Хоть и не очень понятные настройки, но думаю, если разобраться, будет в итоге работать. Контроль набора текста и прочтения сообщения. Вы видите, когда пользователь прочтет отправленное ему сообщение. Это важный и удобный функционал. Тот же mattermost или rocket.chat не предлагают этого в бесплатной версии. Хороший выбор клиентов. Тот же riot есть как приложение для десктопа, для смартфона и web версия через браузер. Звонки между клиентами. Никаких настроек не надо, работают сразу. Минусы: Много багов, с которыми сталкиваешься сразу же во время установки. Забыть положить файлы с шаблонами в дистрибутив и не исправить это. Мне не понятен такой подход. Нету документации, кроме небольшой справки на github. Очень много вопросов на гитхабе, в основном с ошибками. Пропадают сообщения, комнаты, юзеры, кого-то куда-то не пускает и т.д. Думаю со всем этим придется столкнутся после масштабного внедрения. Мало информации в интернете. В русскоязычном интернете вообще ничего, кроме нескольких упоминаний, все только в англоязычном сегменте, да и то в основном краткие руководства по установке. Даже по настройке ничего не нашел, разбирался во всем сам. Для себя сделал такой вывод — буду наблюдать за развитием. Сам нигде внедрять и пробовать не буду. Подожду какое-то время. Если взлетит, хорошо, буду пользоваться. Если будет в таком же состоянии, как сейчас, то увы, не считаю его готовым для внедрения в реально рабочие коллективы. Пока еще сыро.   Статья позаимствована с ресурса serveradmin.ru    

k010v

k010v

Сделать резервную копию сайта на яндекс диск

В современном мире все большую ценность получает информация, потеря которой может обернуться серьезными финансовыми расходами. Сайт является ценной информацией, резервную копию которого, или просто бэкап, мы сделаем в этой статье на примере wordpress и разместим на яндекс диске. Я рассмотрю вариант автоматизации процесса, который придумал для своих нужд и использую достаточно давно и успешно.   Двигаться будем поэтапно. Сначала просто рассмотрим вариант бэкапа непосредственно файлов сайта и базы данных. А затем полностью ответим на вопрос о том как сделать регулярную резервную копию сайта на wordpress .   Скрипт для архива файлов сайта   Тут я не изобретал велосипеда, а воспользовался стандартным способом архивирования файлов — архиватором tar. Все комментарии и пояснения напишу сразу в скрипте: #!/bin/sh # Задаем переменные # Текущая дата в формате 2015-09-29_04-10 date_time=`date +"%Y-%m-%d_%H-%M"` # Куда размещаем backup bk_dir='/mnt/backup/site1.ru' # Директория на уровень выше той, где лежат файлы inf_dir='/web/sites/site1.ru/' # Название непосредственно директории с файлами dir_to_bk='www' # Создание архива /usr/bin/tar -czvf $bk_dir/www_$date_time.tar.gz -C $inf_dir $dir_to_bk На выходе после работы скрипта имеем папку с именем www_2015-09-29_04-10.tar.gz, внутри которой будет лежать папка www со всем содержимым. Изначально, эта папка располагалась по адресу /web/sites/site1.ru/www. Здесь я применил tar с параметром -С для того, чтобы в архиве не было точного пути /web/sites/site1.ru, а была только папка www. Мне просто так удобнее. Можно пользоваться отдельно этим скриптом для создания архивов файлов, не обязательно сайта. Кладем его в cron и получаем регулярную архивацию. Скрипт для бэкапа базы данных   Теперь сделаем скрипт для резервной копии базы данных. Тут тоже ничего особенного, использую стандартное средство mysqldamp: #!/bin/sh # Задаем переменные # Текущая дата в формате 2015-09-29_04-10 date_time=`date +"%Y-%m-%d_%H-%M"` # Куда размещаем backup bk_dir='/mnt/backup/site1.ru' # Пользователь базы данных user='user1' # Пароль пользователя password='pass1' # Имя базы для бэкапа bd_name='bd1' # Выгружаем базу /usr/bin/mysqldump --opt -v --databases $bd_name -u$user -p$password | /usr/bin/gzip -c > $bk_dir/mysql_$date_time.sql.gz На выходе имеем файл с дампом базы mysql_2015-09-29_04-10.sql.gz. Дамп хранится в текстовом формате, можно открывать и редактировать любым редактором.   Подключение яндекс диска в CentOS 7 по webdav   Существует достаточно удобный и бесплатный сервис Яндекс.Диск, который может использовать любой желающий. Бесплатно дается не так много места, но для бэкапа сайта на wordpress хватит. К слову, у меня с помощью всевозможных акций бесплатно доступно 368 ГБ:       Яндекс.Диск можно подключить с помощью webdav. У меня в качестве сервера выступает CentOS 7, я расскажу как подмонтировать в ней. Первым делом подключаем репозиторий epel. Затем устанавливаем пакет davfs2: # yum -y install davfs2 Теперь пробуем подмонтировать диск: # mkdir /mnt/yadisk # mount -t davfs https://webdav.yandex.ru /mnt/yadisk/ Please enter the username to authenticate with server https://webdav.yandex.ru or hit enter for none. Username: Please enter the password to authenticate user zeroxzed@yandex.ru with server https://webdav.yandex.ru or hit enter for none. Password: /sbin/mount.davfs: Warning: can't write entry into mtab, but will mount the file system anyway Яндекс.Диск смонтирован в папку /mnt/yadisk. Чтобы автоматизировать процесс архивации и не вводить каждый раз имя пользователя и пароль, отредактируем файл /etc/davfs2/secrets, добавив в конец новую строку с именем пользователя и паролем: # mcedit  /etc/davfs2/secrets /mnt/yadisk/ user@yandex.ru password /mnt/yadisk/ точка монтирования user@yandex.ru имя пользователя яндекса password пароль пользователя Теперь при монтировании диска никаких вопросов задаваться не будет. Можно добавить подключение яндекс диска в fstab, чтобы он монтировался автоматически при загрузке, но я считаю это лишним. Я подключаю и отключаю диск в скрипте бэкапа. Если же вы хотите его монтировать автоматически, добавьте в fstab: https://webdav.yandex.ru /mnt/yadisk davfs rw,user,_netdev   0   0   Автоматизация архивации сайта   По отдельности разобрали все элементы создания резервной копии сайта, теперь пришел черед собрать все это в одном месте. Я использую следующую схему бэкапа сайта: Папка day, где хранится 7 архивов сайта за последние 7 дней. Папка week, где хранятся 4 бэкапа за последние 4 недели. Папка month, где хранятся все резервные копии сайта за все время, эту папку я автоматически не очищаю. С такой схемой мы всегда имеем под рукой 7 последних архивов, недельные архивы текущего месяца и архив за каждый месяц на всякий случай. Пару раз меня такая схема выручала, когда нужно было что-то достать из бэкапа недельной давности, к примеру. Привожу 3 полных скрипта по созданию резервной копии сайта wordpress, именно этот движок я чаще всего использую, но реально можно бэкапить любой сайт — joomla, drupal, modx и др. Принципиального значения cms или фреймворк не имеет. Скрипт ежедневного бэкапа сайта backup-day.sh: #!/bin/sh # Задаем переменные # Текущая дата в формате 2015-09-29_04-10 date_time=`date +"%Y-%m-%d_%H-%M"` # Куда размещаем backup bk_dir='/mnt/yadisk/site1.ru/day' # Директория для архива inf_dir='/web/sites/site1.ru/' # Название непосредственно директории с файлами dir_to_bk='www' # Пользователь базы данных user='user1' # Пароль пользователя password='pass1' # Имя базы для бэкапа bd_name='bd1' # Монтируем яндекс.диск mount -t davfs https://webdav.yandex.ru /mnt/yadisk/ # Создание архива исходников /usr/bin/tar -czvf $bk_dir/www_$date_time.tar.gz -C $inf_dir $dir_to_bk # Выгружаем базу данных /usr/bin/mysqldump --opt -v --databases $bd_name -u$user -p$password | /usr/bin/gzip -c > $bk_dir/mysql_$date_time.sql.gz # Удаляем архивы старше 7-ми дней /usr/bin/find $bk_dir -type f -mtime +7 -exec rm {} \; # Отключаем яндекс.диск umount /mnt/yadisk Скрипт еженедельного бэкапа сайта backup-week.sh: #!/bin/sh # Задаем переменные # Текущая дата в формате 2015-09-29_04-10 date_time=`date +"%Y-%m-%d_%H-%M"` # Куда размещаем backup bk_dir='/mnt/yadisk/site1.ru/weeek' # Директория для архива inf_dir='/web/sites/site1.ru/' # Название непосредственно директории с файлами dir_to_bk='www' # Пользователь базы данных user='user1' # Пароль пользователя password='pass1' # Имя базы для бэкапа bd_name='bd1' # Монтируем яндекс.диск mount -t davfs https://webdav.yandex.ru /mnt/yadisk/ # Создание архива исходников /usr/bin/tar -czvf $bk_dir/www_$date_time.tar.gz -C $inf_dir $dir_to_bk # Выгружаем базу данных /usr/bin/mysqldump --opt -v --databases $bd_name -u$user -p$password | /usr/bin/gzip -c > $bk_dir/mysql_$date_time.sql.gz # Удаляем архивы старше 30-ти дней /usr/bin/find $bk_dir -type f -mtime +30 -exec rm {} \; # Отключаем яндекс.диск umount /mnt/yadisk Скрипт ежемесячного бэкапа сайта backup-month.sh: #!/bin/sh # Задаем переменные # Текущая дата в формате 2015-09-29_04-10 date_time=`date +"%Y-%m-%d_%H-%M"` # Куда размещаем backup bk_dir='/mnt/yadisk/site1.ru/month' # Директория для архива inf_dir='/web/sites/site1.ru/' # Название непосредственно директории с файлами dir_to_bk='www' # Пользователь базы данных user='user1' # Пароль пользователя password='pass1' # Имя базы для бэкапа bd_name='bd1' # Монтируем яндекс.диск mount -t davfs https://webdav.yandex.ru /mnt/yadisk/ # Создание архива исходников /usr/bin/tar -czvf $bk_dir/www_$date_time.tar.gz -C $inf_dir $dir_to_bk # Выгружаем базу данных /usr/bin/mysqldump --opt -v --databases $bd_name -u$user -p$password | /usr/bin/gzip -c > $bk_dir/mysql_$date_time.sql.gz # Отключаем яндекс.диск umount /mnt/yadisk Не забудьте создать директорию /mnt/yadisk/site1.ru на яндекс диске, а в ней еще 3 папки: day, week, month: # cd /mnt/yadisk/site1.ru && mkdir day week month   Теперь для автоматизации добавляем эти 3 файла в cron: # mcedit /etc/crontab # site backup to yandex.disk # ежедневно в 4:10 10 4 * * * root /root/bin/backup-day.sh >/dev/null 2>&1 # еженедельно в 4:20 в воскресенье 20 4 * * 0 root /root/bin/backup-week.sh >/dev/null 2>&1 # ежемесячно в 4:30 1-го числа месяца 30 4 1 * * root /root/bin/backup-month.sh >/dev/null 2>&1 Все, наш wordpress надежно забэкаплен. По идее, сюда нужно прикрутить оповещение на почту, но у меня всю руки не доходят это сделать. Да и за несколько месяцев использования у меня не было ни одного сбоя.   Восстановление сайта wordpress из резервной копии   Теперь рассмотрим вариант, когда вам необходимо восстановить сайт из резервной копии. Для этого нам понадобятся оба архива: исходники и база данных. Разархивировать в принципе можно где угодно. В windows архивы открываются бесплатным архиватором 7zip. Дамп базы данных в обычном текстовом формате, его можно открыть блокнотом, скопировать и вставить в phpmyadmin.   Так что вариантов восстановления может быть много, этим мне и нравится такой подход. Все файлы в открытом виде, с ними можно работать любыми подручными средствами. Вот пример того, как извлечь файлы из архива в консоли сервера. Разархивируем каталог www из бэкапа: # tar -xzvf www_2015-10-01_04-10.tar.gz Файлы извлечены в папку www. Теперь их можно скопировать в папку с сайтом. Для восстановления базы данных поступаем следующим образом. Сначала распакуем архив: # gunzip mysql_2015-10-01_04-10.sql.gz Теперь зальем дамп в базу данных: # mysql --host=localhost --user=user1 --password=pass1 bd1; MariaDB [(none)]> source mysql_2015-10-01_04-10.sql; Все, база данных восстановлена.   Необходимо учесть, что база будет восстановлена в базу с оригинальным именем и заменит ее содержимое, если таковая на сервере есть. Чтобы восстановить базу в другую, необходимо отредактировать начало дампа и заменить там название базы на новое. Если восстановление происходит на другом сервере, то это не имеет значения. Заключение Итак, мы рассмотрели варианты создания резервных копий сайта и базы данных на примере движка wordpress. При этом использовали только стандартные средства сервера. В качестве примера мы использовали приемник для хранения копий Яндекс.Диск, но ничто не мешает адаптировать его под любой другой. Это может быть отдельный жесткий или внешний диск, другое облачное хранилище данных, которое можно подмонтировать к серверу. Схема создания бэкапа позволяет откатиться практически на неограниченное время назад. Глубину архивов вы можете сами задавать, изменяя параметр mtime в скрипте. Можно хранить, к примеру, ежедневный архив не 7 дней, как делаю я, а 30, если у вас есть такая потребность. Так что пробуйте, адаптируйте под себя. Если есть какие-то замечания по работе, ошибки или предложения по улучшению функционала, делитесь своими мыслями в комментариях, буду рад их услышать.   Статья позаимствована с ресурса serveradmin.ru

k010v

k010v

Как настроить решение резервного копирования Bareos на CentOS 7

Bareos (Backup Archiving Recovery Open Sourced) — надежное межсетевое программное обеспечение с открытым исходным кодом для резервного копирования, архивирования и восстановления данных во всех распространенных операционных системах (Linux, UN * X, MacOS, Windows). С файлом Bareos или, скорее, деревьями каталогов можно настроить централизованно, а затем автоматически и периодически сохранять в виде полной, дифференциальной или инкрементной резервной копии на жесткие диски, ленточные накопители или в облако. Он также предлагает свой собственный веб-интерфейс, используя администраторов веб-интерфейса или пользователи могут выбирать файлы для восстановления. Благодаря открытым интерфейсам Bareos можно легко расширить с помощью сценариев или плагинов, например. для запуска команд приложения до, во время или после резервного копирования. Плагины для резервного копирования MySQL / MariaDB, LDAP, MSSQL или VMWare Snapshots поэтапно уже возможны с помощью bareos. Компоненты Bareos Базовая структура Bareos состоит из блока управления, Резервного директора, одного или нескольких демонов хранилища и демонов Файла на клиентах для резервного копирования. Демон файлов отвечает за резервное копирование данных с клиента или восстановление данных на клиенте. Этот демон постоянно работает на клиентах и выполняет инструкции Директора. Директор — это контроллер: он содержит всю логику и учитывает большинство настроек. Установка Bareos Backup: На RHEL 7 и CentOS 7 bareos доступны через дополнительный канал RHEL Server. На CentOS 7 и Fedora он включен в основной репозиторий, который вы можете использовать с помощью команды ниже. ? # wget -O /etc/yum.repos.d/bareos.repo http://download.bareos.org/bareos/release/latest/CentOS_7/bareos.repo   После загрузки репозитория используйте команду ниже для установки Bareos вместе с зависимыми пакетами, используя приведенную ниже команду.   ?   # yum install bareos bareos-database-mysql   Нажмите кнопку «y», чтобы продолжить установку следующих отображаемых пакетов.     У вас есть возможность выбрать mysql-базу данных или postgresql вместе с bareos, но в этой статье мы используем базу данных MySQL. Подготовить базу данных Bareos: Прежде всего убедитесь, что ваша предпочтительная база данных должна быть установлена и запущена. Самый простой способ настроить базу данных — использовать системную учетную запись, которая имеет свободный доступ к базе данных без доступа к базе данных. Часто это root пользователя для MySQL или пользовательских postgres для PostgreSQL. Давайте запустим следующую команду для установки MySQL / MariaDB на вашем сервере CentOS 7, если она еще не установлена в вашей системе, а затем запустите ее службы. ? # yum install mariadb-server ? # systemctl start mariadb.service ? # systemctl enable mariadb.service Убедитесь, что «root» имеет прямой доступ к локальному серверу MySQL. Проверьте, не подключена ли команда mysql к базе данных без определения пароля. Это значение по умолчанию для RedHat и SUSE. На других системах (Debian, Ubuntu) создайте файл ‘~ / .my.cnf’ с информацией об аутентификации, как показано ниже. [client]
host=localhost
user=root
password=YourPasswordForAccessingMysqlAsRoot Давайте настроим таблицы базы данных Bareos следующими командами.   ? #/usr/lib/bareos/scripts/create_bareos_database #/usr/lib/bareos/scripts/make_bareos_tables #/usr/lib/bareos/scripts/grant_bareos_privileges Запуск демонов bareos ? # systemctl start bareos-dir # systemctl start bareos-sd # systemctl start bareos-fd После запуска служб вам в конечном итоге придется разрешить доступ к портам 9101-9103, которые используются Bareos. После этого вы сможете получить доступ к директору, используя команду «bconsole». ? #bconsole Connecting to Director ksh-cent7:9101
1000 OK: ksh-cent7-dir Version: 15.2.2 (16 November 2017)
Enter a period to cancel a command.
* Установка Bareos Webui: Bareos-webui является частью проекта Bareos и доступен для ряда платформ. Ниже приведены основные системные требования для Bareos-webui: Рабочая среда Bareos, Bareos> = 15.2.2, включая режим JSON API, см. Jansson. Платформа Bareos, где предоставляются пакеты bareos-webui. Веб-сервер Apache 2.x с mod-rewrite, mod-php5 и mod-setenv PHP> = 5.3.3 Zend Framework 2.2.x или новее. Примечание. К сожалению, не все дистрибутивы для пакета Zend Framework 2. В следующем списке показано, где получить пакет Zend Framework 2. Выполните приведенную ниже команду, чтобы установить Apache и PHP на ваш сервер CentOS 7. ? # yum install httpd php php-cli php-common   Добавьте репозиторий Bareos, соответствующий вашему дистрибутиву Linux, здесь мы будем использовать команду «yum» для установки последней версии epel.   ? # yum install epel-release   Теперь вы можете установить Barios-webui с помощью команды ниже, которая будет устанавливать barios-webui вместе с необходимыми пакетами.   ? # yum install bareos-webui     Barios-webui конфигурация: Пакет bareos-webui предоставляет консоль по умолчанию и профильную конфигурацию в разделе ‘/etc/bareos/bareos-dir.d/’, которые должны быть включены в нижней части вашего ‘/etc/bareos/bareos-dir.conf’ и отредактированный в соответствии с вашими потребностями. ? # echo "@/etc/bareos/bareos-dir.d/webui-consoles.conf" &gt;&gt; /etc/bareos/bareos-dir.conf [/code</pre> </div> </div> </div> <div> <div class="codecolorer-container text blackboard"> <div class="text codecolorer"> <pre> # echo "@/etc/bareos/bareos-dir.d/webui-profiles.conf" &gt;&gt; /etc/bareos/bareos-dir.conf    Вы можете просмотреть файлы по умолчанию «webui-consoles.conf» и «webui-profiles.conf», используя команду «cat» или «vim».   ? # vim /etc/bareos/bareos-dir.d/webui-consoles.conf</div> <div></div> <div># vim /etc/bareos/bareos-dir.d/webui-profiles.conf   Конфигурации веб-сервера Apache: Конфигурация по умолчанию предоставляется в файле /etc/httpd/conf.d/bareos-webui.conf для настройки конфигураций веб-сервера Apache для Bareos-webui. Необходимые модули Apache, setenv, rewrite и php активируются с помощью сценария post postinstall. Вам просто нужно перезапустить веб-сервер apache вручную. Затем сконфигурируйте своих директоров в '/etc/bareos-webui/directors.ini' в соответствии с вашими настройками, которые вы выбрали на предыдущих шагах. Конфигурация file '/etc/bareos-webui/directors.ini' должна выглядеть примерно так. ? # vim /etc/bareos-webui/directors.ini   ? ; Section localhost-dir ; [localhost-dir]   ; Enable or disable section. Possible values are “yes” or “no”, the default is “yes”. enabled = “yes” ; Fill in the IP-Address or FQDN of you director. diraddress = “localhost” ; Default value is 9101 dirport = 9101 ; Section another-host-dir ; [another-host-dir] enabled = “no” diraddress = “” dirport = 9101 Сохраните и закройте файл конфигурации, а затем перезапустите веб-службы Apache. ?   #systemctl restart httpd</div> </div> <div class="codecolorer-container text blackboard"> <div class="text codecolorer"># systemctl restart bareos-dir     Для установки bareos-webui в системе с включенным SELinux необходимо выполнить следующие дополнительные шаги, чтобы разрешить HTTP-скрипты и модули подключаться к сети.   ? # setsebool -P httpd_can_network_connect on   Доступ к Bareos-webui: Теперь откройте свой браузер, выбрав FQDN или IP-адрес вашего сервера, предоставленный вашими учетными данными, определенными в вашей конфигурации консоли Bareos Director Console.   ? http://your_servers_ip/bareos-webui/   login: user1
passwd: CHANGEME   Вы можете изменить эти учетные данные в файле '/etc/bareos/bareos-dir.d/webui-consoles.conf'.   После предоставления успешных учетных данных для входа в систему вы будете перенаправлены на свою панель управления, где вы можете увидеть старые текущие и предыдущие резервные копии.   Использование bconsole: Bconsole запускает программу Bareos Console, как только вы подключились к bconsole, введите «help», чтобы просмотреть список доступных команд.   Ниже приведены наиболее полезные команды из приведенного выше списка.   ? * show filesets ? * status dir ? * status client ? * status storage   Теперь запустите резервное задание, используя команду «run», как показано ниже:   ? *run   Вывод: Мы успешно установили и настроили решение Bareos Backup на CentOS 7. Bareos - это решение для резервного копирования с открытым исходным кодом с его замечательными функциями. Bareos - это форк  Bacula с предложениями по созданию готовых бинарных файлов для всех основных дистрибутивов Linux и Windows. Он также включает в себя множество новых функций, таких как «Пассивные клиенты», «Копирование заданий» между разными дисками хранилища, резервное копирование NDMP и т. д. Все разрабатывается как Open Source. 

k010v

k010v

Установка Bind 9 (named) в CentOS 7

Одним из важных сервисов, обеспечивающих функционирование современного интернета является сервис по преобразованию имени сайта в ip адрес. Настройкой реализации сервиса DNS мы займемся в этой статье на примере настройки Bind 9 (named) на сервере под управлением CentOS 7. Мы подготовим минимально необходимый базовый функционал и заглянем немного глубже в настройки логирования.   Что такое DNS сервер BIND   Bind — самая распространенная на текущий день реализация ДНС сервера, которая обеспечивает преобразование IP адресов в dns-имена и наоборот. Его также называют named, например в Freebsd. Судя по информации из Википедии, сейчас 10 из 13 корневых ДНС серверов интернета работают на bind. Он установлен из коробки практически во всех linux дистрибутивах. Я рассмотрю его установку на сервер CentOS 7.   Устанавливаем Bind 9 (named) в CentOS 7 Первым делом проверим, установлен ли у нас днс сервер в системе: # rpm -qa bind* bind-libs-lite-9.9.4-14.el7.x86_64 bind-license-9.9.4-14.el7.noarch У меня не установлен, так как во время инсталляции centos выбрал минимальный пакет программ. Сервер имен у нас будет работать в chroot окружении, так что устанавливаем соответствующие пакеты: # yum -y install bind bind-utils bind-chroot Еще раз обращаю внимание, что мы будем использовать bind в chroot среде для увеличения безопасности. Это накладывает определенные особенности в настройке и управлении сервером. Нужно быть внимательным в этих мелочах. Итак, запускаем bind: # systemctl start named-chroot # systemctl enable named-chroot ln -s '/usr/lib/systemd/system/named-chroot.service' '/etc/systemd/system/multi-user.target.wants/named-chroot.service' Проверяем содержимое chroot каталога: # ls -l /var/named/chroot/etc Все в порядке, сервер запустился, необходимые файлы созданы, все готово для настройки. Займемся ей.   Настраиваем DNS сервер в CentOS 7   Файл конфигурации нашего сервера располагается по адресу /var/named/chroot/etc/named.conf. Открываем его и приводим к следующему виду: # mcedit /var/named/chroot/etc/named.conf options { listen-on port 53 { any; }; listen-on-v6 port 53 { none; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; allow-query { 127.0.0.1; 192.168.7.0/24; }; recursion yes; allow-recursion { 127.0.0.1; 192.168.7.0/24; }; forwarders { 8.8.8.8; }; version "DNS Server"; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; dnssec-enable no; dnssec-validation no; }; zone "." IN { type hint; file "named.ca"; }; include "/etc/named.rfc1912.zones"; include "/etc/named.root.key"; logging { channel default_file { file "/var/log/named/default.log" versions 3 size 5m; severity dynamic; print-time yes; }; category default { default_file; }; }; Эта конфигурация обеспечит работу обычного кэширующего сервера в локальной сети. Комментарии к некоторым параметрам: listen-on-v6 port 53 { none; }; Отключили работу на интерфейсе ipv6. allow-query { 127.0.0.1; 192.168.7.0/24; }; Разрешаем обычные запросы только из локальной сети. allow-recursion { 127.0.0.1; 192.168.7.0/24; }; Разрешаем рекурсивные запросы только из локальной сети. forwarders { 8.8.8.8; }; Перенаправляем запросы, которые сами не резолвим, на днс сервер гугла. У меня указан он просто для примера. Тут лучше всего указать сначала ДНС серверы провайдера. version «DNS Server»; Скрываем версию бинда, вместо этого выводим указанную строку. Не забудьте отредактировать правила фаервола для корректной работы DNS сервера — открыть 53 порт UDP для работы кэширующего сервера, который мы сейчас настроили, и 53 порт TCP для пересылки зон, о которых речь пойдет дальше Теперь создадим папку для логов. Не забываем, что мы работаем в chroot окружении: # cd /var/named/chroot/var/log && mkdir named && chown named. named Поддержка собственной зоны Допустим, нам необходимо в нашем named разместить собственную зону site1.ru. Первым делом создаем файл зоны, которую будет обслуживать dns сервер: # mcedit /var/named/chroot/var/named/site1.ru.zone $TTL 86400 @ IN SOA site1.ru. site1.ru.local. ( 2015092502 43200 3600 3600000 2592000 ) IN NS ns1.site1.ru. IN NS ns2.site1.ru. IN A 192.168.7.254 IN MX 10 mx.site1.ru. gate IN A 192.168.7.254 mx IN A 192.168.7.250 ns1 IN A 192.168.7.235 ns2 IN A 192.168.7.231 Описание синтаксиса файлов зон достаточно хорошо освещено в интернете, не хочется подробно на этом останавливаться. При желание каждый сам сможет посмотреть, если у него возникнет необходимость настроить поддержку собственной зоны. Выставляем необходимые права: # chown root:named /var/named/chroot/var/named/site1.ru.zone # chmod 0640 /var/named/chroot/var/named/site1.ru.zone Дальше подключаем файл зоны в конфигурационном файле bind — /var/named/chroot/etc/named.conf: zone "site1.ru" { type master; file "site1.ru.zone"; }; Перечитываем конфигурацию named с помощью rndc: # rndc reconfig Добавление в bind slave zone Если вы хотите на своем сервере держать копию какой-то зоны, взятой с другого dns сервера, то добавьте следующие настройки в конфиг. zone "site.ru" IN { type slave; masters { 10.1.3.4; }; file "site.ru.zone"; }; 10.1.3.4 — ip адрес dns сервера, с которого мы берем зону. Не забудьте на нем разрешить передачу зоны на ваш dns сервер. Чтобы сервер смог корректно сохранить файл со slave зоной, необходимо добавить разрешение на запись bind для директории /var/named/chroot/var/named. По-умолчанию она имеет следующие права: drwxrx--- 6 root named 164 Jan 6 06:06 named Нужно добавить группе named разрешение на запись, чтобы стало вот так: drwxrwx--- 6 root named 164 Jan 6 06:06 named После этого можно перезапустить bind и проверить, что создался файл слейв зоны. С указанными выше настройками, он будет располагаться по адресу /var/named/chroot/var/named/site.ru.zone. Если у bind не будет прав для создания файла, в логе вы получите ошибку: dumping master file: tmp-7Swr6EZpcd: open: permission denied Настройка логов в bind (named) Гораздо интереснее и полезнее разобраться с подробным логированием работы сервера. Я долгое время поверхностно хватался за всякие рекомендации и куски примерных конфигов в интернете, пока в не решил разобраться сам с этой темой и не полез в оригинальный мануал. Bind дает широкие возможности для ведения логов. Можно фиксировать практически все, что связано с работой сервера. Я сейчас на простых примерах покажу, как это работает. Первым делом в конфигурации мы задаем канал, куда будут складываться логи по тем или иным событиям. Вот пример подобного канала: channel general { file "/var/log/named/general.log" versions 3 size 5m; severity dynamic; print-time yes; Здесь указано название канала, которые мы придумываем сами — general, указан путь до файла, сказано, что хранить будем 3 версии лога размером не более 5 мегабайт. Параметр severity может принимать следующие значения: Описание параметров severity critical Только критические ошибки. error Обычные ошибки и все что выше. warning Предупреждения и все, что выше. notice Уведомления и все, что выше. info Информационные сообщения и все что выше. debug Сообщения уровня debug и все, что выше. Уровни debug  регулируются значениями 0, 1, 2, 3. dynamic То же, что и debug, только его уровень регулируется глобальной настройкой сервера. Параметр print-time указывает на то, что в лог необходимо записывать время события. Помимо указанных мной настроек, в конфигурации канала могут быть добавлены следующие параметры: print-severity yes | no — указывает, писать или нет параметр severity в лог print-category yes | no — указывает писать или нет название категории логов Я эти параметры не указал, так как по-умолчанию устанавливается значение no, которое лично меня устраивает. Дальше необходимо указать категорию логов и в какой канал мы будем ее записывать: category general { general; }; Категорий у днс сервера bind достаточно много. Вот мой перевод полного списка с описаниями: Описание категорий логов в bind (named) default Сюда будут попадать события всех категорий из этой таблицы, если они не определены отдельно, за исключением категории queries, которую нужно включать специально. То есть если обозначить только категорию default, то в нее будут сыпаться события всех категорий. general Эта категория для всех логов, которые не включены ни в одну из перечисленных категорий. database Сообщения, относящиеся к хранению зон и кэшированию. security Подтверждение и отказ в выполнении запросов. config Все, что относится к чтению и выполнению файла конфигурация. resolver Разрешение имен, включая информацию о рекурсивных запросах, выполняемых от имени клиента кэширующим сервером. xfer-in Информация о получении зон. xfer-out Информация о передаче зон. notify Логирование операций протокола NOTIFY. client Выполнение клиентских запросов. unmatched Сообщения, которые named не смог отнести ни к одному классу или для которых не определено отображение. network Логирование сетевых операций. update Динамические апдейты. update-security Подтверждение или отклонение запросов на апдейт. queries Логирование запросов к ДНС серверу. Для включения этой категории необходимо отдельно задать параметр в конфигурации сервера. Это связано с тем, что эта категория генерирует очень много записей в лог файл, что может сказаться на производительности сервера. query-errors Ошибки запросов к серверу. dispatch Перенаправление входящих пакетов модулям сервера на обработку. dnssec Работа протоколов DNSSEC и TSIG. lame-servers Фиксируются ошибки, которые получает bind при обращении к удаленным серверам в попытке выполнить запрос на разрешение имени. delegation-only Логирование запросов, вернувших NXDOMAIN. edns-disabled Запросы, которые вынуждены использовать plain DNS из-за превышения timeouts. RPZ  Все операции, связанные с выполнение Response Policy Zone (RPZ). rate-limit  Операции связанные с одним или несколькими rate-limit statements в options или view. Таким образом, чтобы вывести все категории логов в отдельные файлы, необходимо в конфиг named добавить следующую конструкцию: logging { channel default { file "/var/log/named/default.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel general { file "/var/log/named/general.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel database { file "/var/log/named/database.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel security { file "/var/log/named/security.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel config { file "/var/log/named/config.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel resolver { file "/var/log/named/resolver.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel xfer-in { file "/var/log/named/xfer-in.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel xfer-out { file "/var/log/named/xfer-out.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel notify { file "/var/log/named/notify.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel client { file "/var/log/named/client.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel unmatched { file "/var/log/named/unmatched.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel network { file "/var/log/named/network.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel update { file "/var/log/named/update.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel update-security { file "/var/log/named/update-security.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel queries { file "/var/log/named/queries.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel query-errors { file "/var/log/named/query-errors.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel dispatch { file "/var/log/named/dispatch.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel dnssec { file "/var/log/named/dnssec.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel lame-servers { file "/var/log/named/lame-servers.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel delegation-only { file "/var/log/named/delegation-only.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel edns-disabled { file "/var/log/named/edns-disabled.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel rpz { file "/var/log/named/rpz.log" versions 3 size 5m; severity dynamic; print-time yes; }; channel rate-limit { file "/var/log/named/rate-limit.log" versions 3 size 5m; severity dynamic; print-time yes; }; category default { default; }; category general { general; }; category database { database; }; category security { security; }; category config { config; }; category resolver { resolver; }; category xfer-in { xfer-in; }; category xfer-out { xfer-out; }; category notify { notify; }; category client { client; }; category unmatched { unmatched; }; category network { network; }; category update { update; }; category update-security { update-security; }; category queries { queries; }; category query-errors { query-errors; }; category dispatch { dispatch; }; category dnssec { dnssec; }; category lame-servers { lame-servers; }; category delegation-only { delegation-only; }; category edns-disabled { edns-disabled; }; category rpz { rpz; }; category rate-limit { rate-limit; }; }; Если мы хотим собирать все логи запросов из категории queries, то в раздел options файла конфигурации необходимо добавить параметр, который это разрешает: querylog yes; Перезапускаем bind: # systemctl restart named-chroot.service   Проверка работы DNS Server Первым делом пойдем в каталог с логами и проверим, что там у нас: # cd /var/named/chroot/var/log/named # ls -l Все файлы журнала созданы и начали наполняться. Можно проверить один из них. Например, посмотрим, как наш сервер centos (192.168.7.246) логирует запросы пользователей. Попробуем с компьютера 192.168.7.254 (windows) выполнить nslookup yandex.ru и посмотрим как это отразится в лог файле: 26-Sep-2015 19:25:30.923 client 192.168.7.254#56374 (yandex.ru): query: yandex.ru IN A + (192.168.7.246) 26-Sep-2015 19:25:31.013 client 192.168.7.254#56375 (yandex.ru): query: yandex.ru IN AAAA + (192.168.7.246) Теперь выполним ping site1.ru, чтобы проверить, как сервер поддерживает нашу зону: Смотрим, что в логах: 26-Sep-2015 19:28:01.660 client 192.168.7.254#49816 (site1.ru): query: site1.ru IN A + (192.168.7.246) Таким образом очень удобно отследить, куда лезет компьютер. Например, можно поднять временно dns сервер, включить лог запросов. В клиенте указать единственный днс сервер, который мы настроили. Дальше можно отслеживать, к примеру, куда лезет винда после загрузки без нашего ведома. Или откуда грузится реклама в скайпе. Все запросы будут аккуратно складываться в файл, который потом можно спокойно анализировать. Это все, что я хотел в данном материале рассказать. Тема настройки bind (named) достаточно обширная. Возможно я еще вернусь к ней.   Статья позаимствована с ресурса serveradmin.ru    

k010v

k010v

Подключение сетевой папки Windows в CentOS 7

Данное руководство предназначено для тех, у кого есть желание самостоятельно подключить сетевую папку Windows в CentOS. В этом руководстве мы будем рассматривать тот случай, когда у вас уже есть сервер с установленной на нем операционной системой CentOS 7. Подробно о том, как установить CentOS 7, вы можете прочитать в моем руководстве «Установка CentOS 7 на сервер». Обратите внимание, все команды необходимо выполнять без кавычек. В данном руководстве будет подключаться сетевая папка Windows Share, которая расположена на компьютере с присвоенным ему IP-адресом 10.77.2.30. Для начала вам потребуются полноценные права. Выполняем команду «su». Проверим наличие доступных обновлений для пакетов. Выполняем команду «yum check-update». Далее установим доступные обновления для пакетов. Выполняем команду «yum update». Система уведомляет о том, что для установки потребуется свободное место на диске. Нажимаем на кнопку “y”, затем “Enter”. Система снова уведомляет о том, что для установки потребуется свободное место на диске. Нажимаем на кнопку “y”, затем “Enter”. Теперь установим пакеты необходимые для покдлючения сетевой папки Windows. Выполняем команду «yum install samba-client». Система уведомляет о том, что для установки потребуется свободное место на диске. Нажимаем на кнопку “y”, затем “Enter”. Выполняем команду «yum install cifs-utils». Система уведомляет о том, что для установки потребуется свободное место на диске. Нажимаем на кнопку “y”, затем “Enter”. Создадим папку, в которую будет подключена сетевая папка Windows. Выполняем команду «mkdir /mnt/share01». Выполняем команду «mount.cifs //10.77.2.30/Windows\ Share /mnt/share01 -o user=vmikhalev». Обратите внимание, в параметре “user” необходимо указать логин учетной записи, которая имеет права доступа к сетевой папке Windows. Указываем пароль от учетной записи, которая имеет права доступа к сетевой папке Windows. Сетевая папка Windows подключена. Просмотрим содержимое папки “/mnt/share01”. Выполняем команду «ls -l /mnt/share01». Содержимое сетевой папки Windows теперь доступно в папке “/mnt/share01”. Все содержимое сетевой папки корректно отображаются в CentOS. Подключение сетевой папки Windows в CentOS успешно завершено.

k010v

k010v

БЭКАП И ВОССТАНОВЛЕНИЕ LINUX (CENTOS, DEBIAN, UBUNTU) СЕРВЕРА С ПОМОЩЬЮ VEEAM AGENT FOR LINUX

Пример приводится для ОС Centos 7 Установка Veeam Agent for Linux КОД: ВЫДЕЛИТЬ ВСЁ# cd /root
# wget https://download2.veeam.com/veeam-release-el7-1.0-1.x86_64.rpm
# rpm -Uhv veeam-release-el7-1.0-1.x86_64.rpm
Далее нужно скачать и установить ключ: КОД: ВЫДЕЛИТЬ ВСЁrpm --import http://repository.veeam.com/keys/RPM-EFDCEA77
Обновляем репозитории и устанавливаем veeam. КОД: ВЫДЕЛИТЬ ВСЁ# yum update
# yum install veeam Запускаем Veeam Agent for Linux КОД: ВЫДЕЛИТЬ ВСЁ# veeam
После запуска будет предложение ввести номер лицензии, но мы не вводим ввиду отсутствия. Настройка бекапа
- Нажимаем C (configure) для настройки задания на backup. Задаем любое имя задания, затем указываем, что будем делать полный бэкап сервера.
- В пункте Restore Points указывается глубина архива. Это число копий, которые будут храниться на сервере. Если делать бэкап каждый день и указать число 14, то будут храниться резервные копии системы за последние 14 дней. Если делать будете через день, то за 28 дней и т.д.
Если будет ошибка: КОД: ВЫДЕЛИТЬ ВСЁCurrent system does not support cifs. Please install cifs client package.
то необходимо выполнить: КОД: ВЫДЕЛИТЬ ВСЁyum install cifs-utils

Отличия FREE от платной: https://habr.com/company/veeam/blog/317952/

Подробное описание: https://serveradmin.ru/backup-i-perenos-linux-servera/

k010v

k010v

Почтовый сервер Postfix на CentOS 7 с виртуальными доменами, системой управления, веб-доступом и многим другим

В данной инструкции выполнена настройка полноценного почтового сервера. Список всех особенностей и возможностей: Почтовая система на базе Postfix; Поддержка виртуальных доменов; Хранение почты на сервере; Подключение к почтовым ящикам по POP3 и IMAP (Dovecot); Поддержка шифрования; Хранение части настроек в MariaDB; Защита от СПАМа и вирусов; Доступ к почте с помощью веб-интерфейса (Roundcube); Возможность управление почтовыми ящиками с помощью PostfixAdmin. 1. Преднастройка системы Напоминаю, данная инструкция написана под систему Linux CentOS версии 7. Общие настройки Задаем правильное имя серверу — это важный шаг, так как большинство антиспам систем выполняют проверки, обращаясь к серверу по имени в ожидании ответа. vi /etc/hostname relay.dmosk.ru * необходимо указать FQDN-имя, которое будет доступно из глобальной сети. В данном примере указано relay.dmosk.ru. После вводим такую команду: hostname relay.dmosk.ru Устанавливаем служебные пакеты (они понадобятся в процессе настройки сервера): yum install ntpdate wget * ntpdate для возможности синхронизировать время на сервере; wget — клиент для загрузки файлов. Задаем временную зону (в данном примере московское время): \cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime Синхронизируем время: ntpdate ru.pool.ntp.org Обновляем систему: yum update Настройка безопасности Заранее открываем порты на брандмауэре с помощью firewalld: firewall-cmd --permanent --add-port=25/tcp firewall-cmd --permanent --add-port=80/tcp firewall-cmd --permanent --add-port=110/tcp firewall-cmd --permanent --add-port=143/tcp firewall-cmd --permanent --add-port=443/tcp firewall-cmd --permanent --add-port=465/tcp firewall-cmd --permanent --add-port=587/tcp firewall-cmd --permanent --add-port=993/tcp firewall-cmd --permanent --add-port=995/tcp firewall-cmd --reload * где мы откроем следующие порты: 25 — стандартный SMTP через STARTTLS; 80 — HTTP для порталов Postfixadmin и Roundcube; 110 — стандартный POP3 через STARTTLS; 143 — стандартный IMAP через STARTTLS; 443 — защищенный HTTPS для порталов Postfixadmin и Roundcube; 465 — защищенный SMTP через SSL/TLS; 587 — защищенный SMTP через STARTTLS; 993 — защищенный IMAP через SSL/TLS; 995 — защищенный POP3 через SSL/TLS. В CentOS также может использоваться утилита iptables — в таком случае команды будут следующие: iptables -A INPUT -p tcp --dport 25 -j ACCEPT iptables -A INPUT -p tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp --dport 110 -j ACCEPT iptables -A INPUT -p tcp --dport 143 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j ACCEPT iptables -A INPUT -p tcp --dport 465 -j ACCEPT iptables -A INPUT -p tcp --dport 587 -j ACCEPT iptables -A INPUT -p tcp --dport 993 -j ACCEPT iptables -A INPUT -p tcp --dport 995 -j ACCEPT После сохраняем правила любым из описанных способов. 2. Настройка веб-сервера: NGINX + PHP + MariaDB Система управления PostfixAdmin работает как веб-приложение, разработанное на PHP, а информацию хранит в базе данных. В нашем примере будет использоваться веб-сервер на NGINX, а база данных — MariaDB. Установка NGINX Добавляем репозиторий с нужным пакетом: vi /etc/yum.repos.d/nginx.repo [nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=0
enabled=1 Устанавливаем nginx: yum install nginx Разрешаем автозапуск сервиса и запускаем его: systemctl enable nginx systemctl start nginx Проверяем работоспособность веб-сервера, обратившись к нему в браузере по IP-адресу. Если видим заголовок «Welcome to nginx!», NGINX настроен верно. PHP + PHP-FPM + NGINX Устанавливаем php и php-fpm: yum install php yum install php-fpm Настраиваем NGINX: vi /etc/nginx/conf.d/default.conf server {
    listen       80 default_server;
    set $root_path /usr/share/nginx/html;

    location / {
        root   $root_path;
        index index.php index.hml;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php-fpm/php5-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
        include fastcgi_params;
        fastcgi_param DOCUMENT_ROOT $root_path;
    }
} * где /usr/share/nginx/html — каталог для размещения портала управления Postfix. Настраиваем PHP-FPM: vi /etc/php-fpm.d/www.conf listen = /var/run/php-fpm/php5-fpm.sock * здесь мы поменяли строку 127.0.0.1:9000. Запускаем сервисы: systemctl enable php-fpm systemctl start php-fpm systemctl restart nginx * если в процессе перезапуска nginx выскочит ошибка nginx: [emerg] a duplicate default server, необходимо найти настройку виртуального домена, в которой также указана опция default_server — опцию нужно убрать. Или можно самостоятельно настроить другой виртуальный домен. Для проверки, создаем индексный файл в директории сайта со следующим содержимым: vi /usr/share/nginx/html/index.php <?php phpinfo(); ?> Открываем сайт в браузере по его IP-адресу. На открывшейся странице мы должны увидеть подробную информацию по php: MariaDB Устанавливаем сервер баз данных следующей командой: yum install mariadb mariadb-server Включаем автозапуск сервиса и запускаем его: systemctl enable mariadb systemctl start mariadb Задаем пароль для пользователя sql root: mysqladmin -u root password 3. Установка и настройка PostfixAdmin Устанавливаем дополнительные компоненты для PHP: yum install php-mysql php-mbstring php-imap Для применения установленных пакетов, перезапускаем обработчик скриптов: systemctl restart php-fpm Скачиваем PostfixAdmin: wget https://sourceforge.net/projects/postfixadmin/files/latest/download -O postfixadmin.tar.gz В директории сайтов nginx создаем каталог для postfixadmin и распаковываем в него архив: mkdir /usr/share/nginx/html/postfixadmin tar -C /usr/share/nginx/html/postfixadmin -xvf postfixadmin.tar.gz --strip-components 1 Задаем права на каталог: chown -R apache:apache /usr/share/nginx/html/postfixadmin * несмотря на то, что мы используем веб-сервер nginx, php-fpm по умолчанию, запускается от пользователя apache. Создаем базу данных postfix и учетную запись в mariadb: mysql -u root -p CREATE DATABASE postfix DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; * где postfix — имя базы. GRANT ALL ON postfix.* TO 'postfix'@'localhost' IDENTIFIED BY 'postfix123'; * где postfix — имя учетной записи; postfix123 — пароль; localhost разрешает подключение только с локального сервера. Выходим из командной оболочки MariaDB: \q Открываем конфигурационный файл postfixadmin: vi /usr/share/nginx/html/postfixadmin/config.inc.php И редактируем следующее: $CONF['configured'] = true;
$CONF['default_language'] = 'ru';
$CONF['database_password'] = 'postfix123';
$CONF['emailcheck_resolve_domain']='NO'; Запускаем браузер и вводим адрес http://<IP-адрес сервера>/postfixadmin/setup.php Начнется процесс проверки конфигурации и установки портала PostfixAdmin. После ее окончания вводим дважды пароль и генерируем хэш: После перезагрузки страницы копируем хэш: Открываем конфигурационный файл: vi /usr/share/nginx/html/postfixadmin/config.inc.php Находим строчку: $CONF['setup_password'] = 'changeme'; И меняем ее на: $CONF['setup_password'] = '7a8e14...c26'; * где '7a8e14...c26' — скопированный хэш. После, на той же странице, где показан хэш, добавляем суперпользователя PostfixAdmin: * где Setup password — пароль, который мы ввели на предыдущей странице; Пароль — новый пароль для создаваемой учетной записи. В итоге мы увидим следующее: И переходим в браузере на страницу http://<IP-адрес сервера>/postfixadmin/ Вводим логин и пароль для созданного пользователя. Готово. 4. Настройка Postfix По умолчанию, Postfix уже установлен в CentOS 7. Но если встретится сервер без него, выполним установку простой командой: yum install postfix Создаем учетную запись, от которой мы будем работать с каталогом виртуальных почтовых ящиков: groupadd -g 1024 vmail
useradd -d /home/mail -g 1024 -u 1024 vmail -m * сначала мы создаем группу vmail и guid 1024, после — пользователя vmail с uid 1024 и домашней директорией /home/mail. Обратите внимание, что в некоторых системах идентификатор группы и пользователя 1024 может быть занят. В таком случае необходимо создать другой, а в данной инструкции ниже заменить все 1024 на альтернативный. Теперь открываем на редактирование конфигурационный файл почтового сервера: vi /etc/postfix/main.cf И редактируем следующие строки: myorigin = $mydomain * данная настройка указывает, какой домен подставлять отправителю, если он не указан в заголовке FROM. mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain * указываем, для каких доменов принимаем входящую почту. local_recipient_maps = unix:passwd.byname $alias_maps * указываем, откуда брать список локальных пользователей. mynetworks = 127.0.0.0/8 * разрешаем отправлять сообщения локальному серверу. alias_maps = hash:/etc/aliases * указываем, откуда брать список алиасов. inet_interfaces = all * необходимо убедиться, что postfix будет слушать на всех необходимых интерфейсах, в данном случае, на всех. Теперь в конец конфигурационного файла допишем следующее: virtual_mailbox_base = /home/mail
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
virtual_minimum_uid = 1024
virtual_uid_maps = static:1024
virtual_gid_maps = static:1024
virtual_transport = dovecot
dovecot_destination_recipient_limit = 1 smtpd_sasl_auth_enable = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth smtpd_tls_cert_file = /etc/ssl/mail/public.pem
smtpd_tls_key_file = /etc/ssl/mail/private.key
smtpd_use_tls = yes
smtpd_tls_auth_only = yes
smtpd_helo_required = yes * где: virtual_mailbox_base — базовый путь хранения почтовых ящиков в системе UNIX. virtual_alias_maps — формат и путь хранения алиасов для виртуальных пользователей. virtual_mailbox_domains — формат и путь хранения доменов виртуальных пользователей. virtual_mailbox_maps — формат и путь хранения почтовых ящиков для виртуальных пользователей. virtual_minimum_uid — с какого номера присваивать идентификаторы пользователям. virtual_uid_maps — идентификатор пользователя, от которого записываются сообщения. virtual_gid_maps — идентификатор группы, от которой записываются сообщения. virtual_transport — задает доставщика сообщений. dovecot_destination_recipient_limit — передача сообщений от Postfix в Dovecot выполняется по заданному количеству (в нашем примере, по 1 шт.). smtpd_sasl_auth_enable — разрешает sasl аутентификацию. smtpd_sasl_exceptions_networks — исключение сетей от использования шифрования. smtpd_sasl_security_options — дополнительные опции настройки sasl. broken_sasl_auth_clients — эту опцию прописываем для клиентов MS Outlook. smtpd_sasl_type — указывает тип аутентификации. smtpd_sasl_path — путь до временных файлов обмена информацией с Dovecot. Указывается либо абсолютный путь, либо относительный queue_directory. smtpd_tls_cert_file — полный путь до публичного сертификата. smtpd_tls_key_file — полный путь до приватного сертификата. smtpd_use_tls — указывает клиентам на наличие поддержки TLS. smtpd_tls_auth_only — использовать только TLS. smtpd_helo_required — требовать начинать сессию с приветствия. Создаем файл с настройками обращения к базе с алиасами: vi /etc/postfix/mysql_virtual_alias_maps.cf user = postfix
password = postfix123
hosts = localhost
dbname = postfix
query = SELECT goto FROM alias WHERE address='%s' AND active = '1' * где user и password — логин и пароль для подключения к MySQL; hosts — имя сервера баз данных (в нашем случае, локальный сервер); dbname — имя базы данных; query — шаблон запроса к данным. Создаем файл с инструкцией получения данных по виртуальным доменам: vi /etc/postfix/mysql_virtual_domains_maps.cf user = postfix
password = postfix123
hosts = localhost
dbname = postfix
query = SELECT domain FROM domain WHERE domain='%u' И файл с почтовыми ящиками: vi /etc/postfix/mysql_virtual_mailbox_maps.cf user = postfix
password = postfix123
hosts = localhost
dbname = postfix
query = SELECT CONCAT(domain,'/',maildir) FROM mailbox WHERE username='%s' AND active = '1' Открываем файл master.cf и дописываем в самый конец: vi /etc/postfix/master.cf submission     inet  n       -       n       -       -       smtpd
    -o smtpd_tls_security_level=may
    -o smtpd_sasl_auth_enable=yes
    -o smtpd_sasl_type=dovecot
    -o smtpd_sasl_path=/var/spool/postfix/private/auth
    -o smtpd_sasl_security_options=noanonymous
    -o smtpd_sasl_local_domain=$myhostname smtps      inet n - n - - smtpd
    -o syslog_name=postfix/smtps
    -o smtpd_tls_wrappermode=yes
    -o smtpd_sasl_auth_enable=yes
    -o smtpd_client_restrictions=permit_sasl_authenticated,reject dovecot    unix  -       n       n       -        -       pipe
    flags=DRhu user=vmail:vmail argv=/usr/libexec/dovecot/deliver -d ${recipient} * необходимо убедиться, что в содержимом файла нет других раскомментированных опций для submission, smtps и dovecot (по умолчанию, их нет). В данном случае, мы настроили работу postfix на портах 25, 465 и 587. Перезапустим postfix: systemctl restart postfix 5. Настройка Dovecot Устанавливаем Dovecot с компонентом для работы с СУБД: yum install dovecot dovecot-mysql Настраиваем способ хранения сообщений: vi /etc/dovecot/conf.d/10-mail.conf mail_location = maildir:/home/mail/%d/%u/
first_valid_gid = 1024 * в данном примере сообщения будут храниться в продвинутом формате maildir. Настраиваем слушателя для аутентификации: vi /etc/dovecot/conf.d/10-master.conf service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0666
    user = postfix
    group = postfix
  }
  unix_listener auth-userdb {
    mode = 0600
    user = vmail
    group = vmail
  }
} * обращаем внимание, что /var/spool/postfix/private/auth — это тот же private/auth, который был прописан нами в postfix. Настраиваем аутентификацию в Dovecot: vi /etc/dovecot/conf.d/10-auth.conf #!include auth-system.conf.ext
!include auth-sql.conf.ext * в данном случае мы просто комментируем обычную аутентификацию и снимаем комментарий для использования sql-аутнтификации. Настраиваем использование шифрования: vi /etc/dovecot/conf.d/10-ssl.conf ssl = required
ssl_cert = </etc/ssl/mail/public.pem
ssl_key = </etc/ssl/mail/private.key * данная настройка укажет dovecot требовать от клиентов использования шифрования. Настроим автоматическое создание каталогов при первом подключении пользователя к ящику: vi /etc/dovecot/conf.d/15-lda.conf lda_mailbox_autocreate = yes Настраиваем подключение к нашей базе данных: vi /etc/dovecot/conf.d/auth-sql.conf.ext passdb {
  …
  args = /etc/dovecot/sql.conf
} userdb {
  …
  args = /etc/dovecot/sql.conf
} * в данном примере мы указали на файл, в котором будут находиться настройки для получения пользователей и паролей из базы данных. Создаем файл с настройками работы с mysql: vi /etc/dovecot/sql.conf driver = mysql
connect = host=localhost dbname=postfix user=postfix password=postfix123
default_pass_scheme = MD5-CRYPT
password_query = SELECT password FROM mailbox WHERE username = '%u'
user_query = SELECT maildir, 1024 AS uid, 1024 AS gid FROM mailbox WHERE username = '%u'
user_query = SELECT CONCAT('/home/mail/',LCASE(`domain`),'/',LCASE(`maildir`)), 1024 AS uid, 1024 AS gid FROM mailbox WHERE username = '%u' И, напоследок, настраиваем протоколы и интерфейс, на котором будет слушать dovecot: vi /etc/dovecot/dovecot.conf protocols = imap imaps pop3 pop3s
listen = * * по умолчанию, dovecot слушает также на ipv6 (listen = *, ::). Если на сервере не используется 6-я версия протокола TCP/IP, в логах dovecot появятся ошибки:
master: Error: service(imap-login): listen(::, 143) failed: Address family not supported by protocol
master: Error: service(imap-login): listen(::, 993) failed: Address family not supported by protocol Генерируем сертификаты безопасности Создаем каталог, в котором разместим сертификаты: mkdir -p /etc/ssl/mail И сгенерируем их следующей командой: openssl req -new -x509 -days 1461 -nodes -out /etc/ssl/mail/public.pem -keyout /etc/ssl/mail/private.key -subj "/C=RU/ST=SPb/L=SPb/O=Global Security/OU=IT Department/CN=relay.dmosk.ru" * сертификат сгенерирован на 1461 день, ключи subj могут быть произвольными, CN необходимо указать в соответствии с именем сервера, по которому мы будем подключаться к почте. Запускаем dovecot: systemctl start dovecot 6. Создаем первый почтовый ящик и проверяем работу сервера В браузере вводим в адресной строке путь до Postfixadmin — http://<IP-адрес сервера>/postfixadmin/. Вводим логин и пароль от административной учетной записи, которую мы создали на шаге 3. Перед нами появится страница управления учетными записями. Переходим в Список доменов - Новый домен: Заполняем формы и нажимаем по Добавить домен: Теперь переходим в Обзор - Создать ящик: Вводим данные нового пользователя и нажимаем по Создать ящик: Теперь можно подключиться к серверу с помощью любой почтовой программы, например, Mozilla Thunderbird. Параметры для подключения: Сервер: имя сервера или его IP-адрес (не желательно, так как сертификат выдается по доменному имени). IMAP: 143 STARTTLS или 993 SSL/TLS POP3: 110 STARTTLS или 995 SSL/TLS SMTP: 25 STARTTLS или 465 SSL/TLS или 587 STARTTLS 7. Устанавливаем и настраиваем Roundcube Webmail На официальном сайте заходим на страницу загрузки Roundcube. Смотрим ссылку на последнюю стабильную версию продукта: Используем ссылку, чтобы загрузить архив программы: wget https://github.com/roundcube/roundcubemail/releases/download/1.1.9/roundcubemail-1.1.9.tar.gz Создаем каталог, где будут размещаться файлы портала: mkdir /usr/share/nginx/html/webmail И распаковываем скачанный архив: tar -C /usr/share/nginx/html/webmail -xvf roundcubemail-1.1.9.tar.gz --strip-components 1 Копируем шаблон конфига: cp /usr/share/nginx/html/webmail/config/config.inc.php.sample /usr/share/nginx/html/webmail/config/config.inc.php И открываем его на редактирование: vi /usr/share/nginx/html/webmail/config/config.inc.php $config['db_dsnw'] = 'mysql://roundcube:roundcube123@localhost/roundcubemail';
$config['enable_installer'] = true; * первую строку мы редактируем, а вторую добавляем. В первой строке roundcube:roundcube123 — логин и пароль для доступа к базе данных; localhost — сервер базы данных; roundcubemail — имя базы данных. Задаем владельца apache на папку портала: chown -R apache:apache /usr/share/nginx/html/webmail Создаем в MariaDB базу для roundcubemail: mysql -uroot -p > CREATE DATABASE roundcubemail DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci; > GRANT ALL PRIVILEGES ON roundcubemail.* TO roundcube@localhost IDENTIFIED BY 'roundcube123'; > quit И загружаем в созданную базу данные: mysql -uroot -p roundcubemail < /usr/share/nginx/html/webmail/SQL/mysql.initial.sql Устанавливаем компоненты, необходимые для работы Roundcube: yum install php-pear php-mcrypt php-intl php-ldap php-pear-Net-SMTP php-pear-Net-IDNA2 php-pear-Mail-Mime Настроим php: vi /etc/php.ini date.timezone = "Europe/Moscow" Перезагружаем php-fpm: systemctl restart php-fpm Теперь открываем браузер и переходим по адресу http://<IP-адрес сервера>/webmail/installer/. В самом низу нажимаем по кнопке Next. Если кнопка будет неактивна, проверяем, что нет ошибок (NOT OK). Проверяем, что все пункты находятся в состоянии OK. После удаляем папку с установочными скриптами: \rm -R /usr/share/nginx/html/webmail/installer И заходим в браузере по адресу http://<IP-адрес сервера>/webmail/. 8. Защищаемся от вирусов Установка и настройка ClamAV Устанавливаем антивирус: yum install clamav clamsmtp clamav-scanner-systemd clamav-update Настраиваем postfix: vi /etc/postfix/main.cf content_filter = scan:[127.0.0.1]:10025
receive_override_options = no_address_mappings * где content_filter указывает на приложение, которое будет сканировать сообщения; receive_override_options позволяет увидеть оригинальные email адреса писем с вирусами. Теперь редактируем master.cf: vi /etc/postfix/master.cf Дописываем следующее: scan unix - - n - 16 smtp
  -o smtp_send_xforward_command=yes
  -o smtp_enforce_tls=no

127.0.0.1:10026 inet n - n - 16 smtpd
  -o content_filter=
  -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
  -o smtpd_helo_restrictions=
  -o smtpd_client_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_recipient_restrictions=permit_mynetworks,reject
  -o mynetworks_style=host
  -o smtpd_authorized_xforward_hosts=127.0.0.0/8 Перезапускаем postfix: systemctl restart postfix Конфигурируем clamsmtpd: vi /etc/clamsmtpd.conf ClamAddress: /var/run/clamd.scan/clamd.sock
TempDirectory: /var/run/clamd.scan * где ClamAddress указываем на путь к сокетному файлу — он должен совпадать с путем в конфигурационном файле для clam scan; TempDirectory — путь для хранения временных файлов. Редактируем конфигурационный файл для clam scan: vi /etc/clamd.d/scan.conf PidFile /var/run/clamd.scan/clamd.pid
LocalSocket /var/run/clamd.scan/clamd.sock
User clamsmtp * где PidFile — путь для pid-файла сервиса; LocalSocket — путь до сокетного файла для взаимодействия с clamsmtp; User — пользователь, от которого будет запускаться clamd. Редактируем владельца на каталог для сокетного файла: chown clamsmtp:clamscan /var/run/clamd.scan Теперь разрешаем запуск антивируса и запускаем его: systemctl enable clamsmtpd systemctl start clamsmtpd systemctl enable clamd@scan systemctl start clamd@scan Обновление Открываем конфиг freshclam и ставим комментарий напротив Example: vi /etc/freshclam.conf #Example Разрешаем и запускаем сервис: systemctl enable clamd@freshclam systemctl start clamd@freshclam Запускаем обновление: freshclam Для настройки автоматического обновления, редактируем cron: crontab -e 15 3 * * * /bin/freshclam * в данном примере, каждый день в 03:15 будет запускаться процесс обновления clamav. Проверка Для проверки отправляем сообщение со следующим содержимым: X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* Письмо не должно дойти. 9. Боремся со СПАМом Проверка контента с помощью Spamassassin Устанавливаем spamassassin yum install spamassassin Редактируем master.cf: vi /etc/postfix/master.cf Для smtp добавляем следующую опцию:  smtp      inet  n       -       n       -       -       smtpd
    -o content_filter=spamassassin И добавить следующее: spamassassin      unix  -       n       n       -       -       pipe
  flags=R user=spamd argv=/usr/bin/spamc -u spamd -e /usr/sbin/sendmail -f $sender $recipient Обновляем spamassassin: sa-update --nogpg Разрешаем его запуск и стартуем сервис: systemctl enable spamassassin systemctl start spamassassin Перезапускаем postfix: systemctl restart postfix Для автоматического обновления добавим в cron следующее: crontab -e 30 3 * * * /bin/sa-update * обновление будет происходить каждый день в 03:30. Для проверки работы контентного антиспама, отправляем письмо со следующим содержимым: XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X Антиспам средствами Postfix В MTA Postfix встроен свой механизм проверки заголовков входящих сообщений. Правила размещаются в 6 секций, обработка которых выполняется в следующем порядке: client -> helo -> sender -> relay -> recipient -> data И так, для настройки антиспама в конфигурационный файл main.cf добавляем: vi /etc/postfix/main.cf smtpd_client_restrictions =
        permit_mynetworks
        permit_sasl_authenticated
        reject_unauth_pipelining
        permit

smtpd_helo_restrictions =
        permit

smtpd_sender_restrictions =
        permit_mynetworks
        permit_sasl_authenticated
        reject_non_fqdn_sender
        reject_unknown_sender_domain
        permit

smtpd_relay_restrictions =
        permit

smtpd_recipient_restrictions =
        permit_mynetworks
        permit_sasl_authenticated
        reject_non_fqdn_recipient
        reject_unauth_destination
        reject_unknown_recipient_domain
        reject_unverified_recipient
        permit

smtpd_data_restrictions =
        permit

smtpd_end_of_data_restrictions =
        permit * это более или менее мягкие правила. Их можно использовать первое время, пока тестируем сервер. Для усиления защиты добавляем: smtpd_recipient_restrictions =
        ...
        reject_unknown_client_hostname
        reject_invalid_helo_hostname
        reject_non_fqdn_helo_hostname
        reject_unknown_helo_hostname
        reject_rbl_client bl.spamcop.net
        reject_rbl_client cbl.abuseat.org
        reject_rbl_client dul.ru
        reject_rbl_client dnsbl.abuse.ch
        permit * где: reject_unknown_client_hostname — проверяет наличие PRT-записи отправителя и наличие рабочей А-записи в соответствие PTR. reject_invalid_helo_hostname — проверяет синтаксис HELO-приветствия. reject_non_fqdn_helo_hostname — требует правильного FQDN-имени во время HELO-приветствия. reject_unknown_helo_hostname — запрещает представляться именами, для которых нет А-записи или MX. reject_rbl_client — проверяет наличие отправителя в черных списках. После внесения всех правок, необходима перезагрузка Postfix: systemctl restart postfix Сервер настроен — можно пользоваться.

k010v

k010v

Установка и обновление SSL-сертификатов Let's encrypt в Centos 7

Настройка Let's Encrypt на CentOS 7

 
0. Установка git и bc если не установлены раннее sudo yum -y install git bc
1. Клонированию проекта letsencrypt из GitHub.
 
sudo git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt
 
 
2. Получение сертификата
Переходим к проекту Letsencrypt, куда мы клонировали файлы. И запускаем генерацию сертификатов командой letsencrypt-auto certonly, используя плагин webroot.
 
cd /opt/letsencrypt
 
./letsencrypt-auto certonly -a webroot --webroot-path=/web/path -d domen.com -d www.domen.com
 
Если все прошло успешно, тогда в консоли вы должны увидеть примерно это:
 
/etc/letsencrypt/live/domen.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/domen.com/privkey.pem
 
IMPORTANT NOTES:
- If you lose your account credentials, you can recover through
e-mails sent to sammy@digitalocean.com
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/example.com/fullchain.pem. Your
cert will expire on 2016-03-15. To obtain a new version of the
certificate in the future, simply run Let's Encrypt again.
- Your account credentials have been saved in your Let's Encrypt
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Let's
Encrypt so making regular backups of this folder is ideal.
- If like Let's Encrypt, please consider supporting our work by:
 
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
 
Если вы получили ошибки, типа: Failed to connect to host for DVSNI challenge, настройте firewall вашего сервера, что бы TCP трафик проходил по портам 80 и 443.
 
3. Настройка TLS/SSl на веб-сервере Nginx
 
NGINX:
ssl_certificate "/etc/letsencrypt/live/domen.com/fullchain.pem";
ssl_certificate_key "/etc/letsencrypt/live/domen.com/privkey.pem";
ssl_trusted_certificate "/etc/letsencrypt/live/domen.com/fullchain.pem";
 
APACHE:
SSLCertificateFile /etc/letsencrypt/live/domen.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/domen.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/domen.com/chain.pem
 
 
4. Перезапуск Nginx или Apache
 
service nginx restart && service php-fpm restart
 
service httpd restart
 
5. Настройка автопродления
 
Сертификаты действительный 90 дней, но рекомендуется продлевать сертификаты каждые 60 дней. Мы это автоматизируем с помощью cron.
 
Чтобы запустить процесс обновления для всех установленных доменов, выполните следующую команду:
 
/opt/letsencrypt/letsencrypt-auto renew
 
Так как мы недавно установили сертификат, то команда будет проверять только дату истечения срока действия и распечатает сообщение, информирующее о том, что сертификат не нуждается в продлении. Вы увидите примерно следующие в консоли:
 
Checking for new version...
Requesting root privileges to run letsencrypt...
/root/.local/share/letsencrypt/bin/letsencrypt renew
Processing /etc/letsencrypt/renewal/example.com.conf
 
The following certs are not due for renewal yet:
/etc/letsencrypt/live/example.com/fullchain.pem (skipped)
No renewals were attempted.
 
Обратите внимание, что если вы создали сертификат в комплекте с несколькими доменами, тогда только базовое имя домена будет отображено в консоли, но вы не пугайтесь, продлены будут все домены, включенные в этот сертификат.
 
6. Редактируем crontab, что бы наши сертификаты обновлялись автоматически. Проверку на обновления мы будем делать каждую неделю.
Для редактирования crontab от root пользователя выполните команду:
 
sudo crontab -e
 
Добавим следующие строки:
 
30 2 * * 1 /opt/letsencrypt/letsencrypt-auto renew >> /var/log/le-renew.log
35 2 * * 1 /usr/bin/systemctl reload nginx
 
Этак команда создаст cron, который каждый понедельник будет выполнять автоматическое продление letsencrypt сертификатов в 2:30 и перезагружать Nginx в 2:35. Вся информация об обновлении будет логироваться в /var/log/le-renew.log.
 

k010v

k010v

Установка Owncloud X на CentOS 7

Появилась необходимость в своем облачном сервере. Решил развернуть Owncloud X на Centos 7. Есть так же и мобильное приложение, которое можно подключить к вашей облачной среде owncloud. Так же в новой версии появился webdav.
И так приступим. Обновляем систему
yum update -y
Устанавливаем php (необходимо выше версии 5.4)
Для этого необходимо подключить репозиторий epel-release
yum install epel-release
Далее подключаем репозиторий remi
yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm
Проверяем список доступных репозиториев
ls /etc/yum.repos.d/remi* Как видим в списке отображается несколько версий php: Далее есть несколько вариантов, чтобы активировать необходимую версию php:
a) Устанавливаем пакет yum-utils
yum install yum-utils С помощью команды yum-config-manager активируем необходимую версию php
yum-config-manager --enable remi-php72 b) Второй вариант
Открываем файл с необходимой версией php и меняем значение enabled=0 на 1
vi /etc/yum.repos.d/remi-php72.repo После устанавливаем сам php и необходимые компоненты для работы 0wncloud
yum install php php-mcrypt php-cli php-gd php-curl php-mysql php-ldap php-zip php-fileinfo php-intl php-xmlwriter php-mbstring Проверяем версию php
php -v Устанавливаем сервер базы данных
yum install mariadb mariadb-server
Запускаем и добавляем в автозагрузку
systemctl enable mariadb
systemctl start mariadb При первом подключении к БД у меня не было пароля, чтобы установить пароль на root необходимо выполнить следующую команду
mysqladmin -u root password "newpass" Подключаемся к mysql
mysql -u root -p Создаем новую базу
CREATE DATABASE owncloud;
Теперь создайте пользователя и назначьте его для базы данных owncloud:
GRANT ALL ON owncloud.* to 'owncloud'@'localhost' IDENTIFIED BY 'newpass'; exit Перезапускаем службы
systemctl restart httpd php-fpm mariadb Так же не забываем настроить firewall.
Добавляем следующие правила: firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https Перезапускаем
firewall-cmd --reload Смотрим список правил
firewall-cmd --permanent --list-all Выключаем selinux, для этого открываем файл config, расположенного по пути:
vi /etc/selinux/config и меняем значение SELINUX=enforcing на SELINUX=disabled После проделанных шагов можно пробовать подключиться к owncloud, вводим в браузере
http://ipaddress/owncloud Заполняем поля имя пользователя и пароль и нажимаем на “Хранилище и база данных” После подключения БД и ввода логина с паролем, вы попадаете на сайт owncloud. Если вы будете открывать доступ из интернета, необходимо добавить в config.php
vi /var/www/html/owncloud/config/config.php найти массив array  добавить ваши данные: ‘trusted_domains’ =>
array (
0 => ‘local_ip’,
1 => ‘site.com’,
), Если этого не сделать, то owncloud будет выдавать ошибку и не пустит на сайт!
На этом первоначальная установка с настройкой завершена.  

k010v

k010v

Настройка postfix + dovecot + mysql база + postfixadmin + roundcube + dkim на CentOS 7

Публикация по материалам serveradmin.ru     Я буду настраивать почтовый сервер на ОС linux, а точнее на CentOS 7. За основу будет взят postfix, который присутствует в этой системе из коробки. Инструкция получится универсальной, можно использовать и для других дистрибутивов. Все основные конфиги легко переносятся на разные системы, требуя минимальной правки, в основном путей. Я напишу статью на самом что ни на есть реальном примере, без какой-либо правки доменов, ip и прочего, чтобы не ошибиться и показать максимально возможный реальный пример. У меня есть технический домен zeroxzed.ru. Я буду использовать его в своей работе. Почтовый сервер будет иметь имя mail.zeroxzed.ru. Всю теорию по подготовке dns к установке и настройке почтового сервера я рассказывал в предыдущей статье о почтовом сервере. Не хочу здесь повторяться. Уточню только список действий, которые вам нужно проделать c ДНС: Создаем A запись в DNS — mail.zeroxzed.ru. Добавляем или редактируем MX запись, указывая в качестве почтового сервера mail.zeroxzed.ru. Просим провайдера прописать PTR для внешнего ip адреса, который будет использовать почтовый сервер. В качестве ptr записи просим установить имя нашего сервера — mail.zeroxzed.ru. Я предпочитаю в качестве dns хостинга использовать сервера яндекса, даже если не прикрепляю его почту к домену. На картинке показан минимально необходимый набор записей, кроме PTR. Этими записями управляете не вы, а провайдер, который вам выдает ip. Пока с днс все. Позже мы вернемся к этому вопросу, когда будем добавлять dkim и spf записи. Но обо всем по порядку. Подготовим систему centos к установке и настройке почтового сервера postfix. Если у вас еще нет готовой системы, то рекомендую воспользоваться моими статьями по установке и настройке centos. Отдельно потратьте время на настройку iptables. Я не буду касаться этого вопроса в данной статье, чтобы не раздувать ее второстепенными вещами. Удобнее, когда все по отдельности рассказано и описано с должной глубиной. Сваливать все в одну кучу не хочется. По вступлению вроде все, основное рассказал. Приступим к настройке нашего почтового сервера. Сразу хочу сделать предупреждение. Настройка почтового сервера достаточно трудоемкий процесс, требует определенных навыков, знаний и понимания принципов работы используемых средств. Я не ставлю для себя цель расписать максимально подробно так, чтобы было понятно даже неподготовленному администратору linux. Вы должны быть так или иначе подготовлены, либо запаситесь терпением и разбирайтесь внимательно сами в нюансах. Эта статья на полный копипаст не подходит, что-то остается за кадром для самостоятельного выполнения. Иначе нельзя, получится очень большой и громоздкий материал. Установка postfixadmin Начнем с установки и настройки панели управления почтовым сервером postfix — postfixadmin. Без него начинать что-то делать неудобно, так как управлять пользователями, ящиками, алиасами будет нечем. По своей сути postfixadmin — набор php скриптов для управления записями в mysql базе данных, которую использует сервер postfix во время своей работы. Соответственно, для работы postfixadmin нам нужен web сервер. Подробно о настройке web сервера на centos читайте отдельно. Сейчас же мы быстро установим все необходимое. Привожу только команды, без комментариев. Все подробности по приведенной выше ссылке. # yum install httpd php phpmyadmin mariadb mariadb-server php-imap Этих пакетов со всеми зависимостями будет достаточно для установки всех необходимых компонентов веб сервера. Я специально ставлю phpmyadmin, с ним удобно работать с базой. В нашем случае все пользователи будут храниться в mysql, иногда может понадобиться туда заглянуть. Подробнее с установкой и настройкой phpmyadmin можете ознакомиться отдельно. Запускаем httpd и mariadb и добавляем их в автозагрузку. # systemctl start httpd # systemctl enable httpd # systemctl start mariadb # systemctl enable mariadb Задаем пароль root для mysql. # /usr/bin/mysql_secure_installation Проверяем работу web сервера. Заходим по ip адресу сервера — http://188.35.19.125/, а также проверяем работу phpmyadmin — http://188.35.19.125/phpmyadmin/. Его нужно настроить, об этом рассказано в статье, которую я привел чуть выше. По-умолчанию в phpmyadmin доступ закрыт. Если все сделали правильно, то увидите примерно следующее. Сразу создадим тут пользователя postfix и одноименную базу данных. Запомните учетные данные, они нам далее понадобятся. Веб сервер готов, продолжаем настройку почтового сервера. Скачиваем последнюю версию postfixadmin. # cd /usr/src # wget https://downloads.sourceforge.net/project/postfixadmin/postfixadmin/postfixadmin-3.0.2/postfixadmin-3.0.2.tar.gz Скорее всего во время вашей установки версия postfixadmin изменится и ссылка может быть неактуальной. Но даже если она будет актуальна, возможно выйдет более новая версия. Проверьте ее по ссылке https://sourceforge.net/projects/postfixadmin/ и скачайте самую свежую версию. Распаковываем архив и копируем в директорию веб сервера. # tar -xvzf postfixadmin-* # mv /usr/src/postfixadmin-3.0.2 /var/www/html/postfixadmin Назначаем владельцем пользователя веб сервера: # chown -R apache. /var/www/html/postfixadmin/ Дальше редактируем конфигурационный файл postfixadmin. # mcedit /var/www/html/postfixadmin/config.inc.php Приводим параметры к следующему виду: $CONF['configured'] = true; $CONF['default_language'] = 'ru'; $CONF['database_type'] = 'mysqli'; $CONF['database_host'] = 'localhost'; $CONF['database_user'] = 'postfix'; $CONF['database_password'] = '12345678'; $CONF['database_name'] = 'postfix'; $CONF['admin_email'] = 'root@zeroxzed.ru'; $CONF['encrypt'] = 'md5crypt'; $CONF['default_aliases'] = array ( 'abuse' => 'root', 'hostmaster' => 'root', 'postmaster' => 'root', 'webmaster' => 'root' ); $CONF['domain_path'] = 'YES'; $CONF['domain_in_mailbox'] = 'YES'; Обращаю внимание на выделенный параметр. Он указывает на то, в каком виде хранить пароли пользователей в базе данных. Конечно, хранить обычным текстом без шифрования это дурной тон и может быть опасно. Я указал хранение в шифрованном виде. Но если мы говорим о небольшой компании без публичного доступа к серверу, можно использовать нешифрованные пароли. Для этого указываем значение параметра cleartext. Я сам так часто делаю просто из соображений удобства. Объясню, в чем удобство. К примеру, у пользователя несколько устройств подключены к почте и он забыл свой пароль. Админ при создании почему-то тоже его никуда не записал, или забыл, или потерял. Вам придется сбросить пароль и перенастроить все устройства. Если же у вас пароль хранится в открытом виде, вы просто смотрите в базу и говорите пользователю пароль. Пароли в открытом виде удобно просто выгрузить дампом из базы, если понадобится кому-то все учетки передать. Но тут как посмотреть  С одной стороны плюс, с другой минус — кто-то очень просто может спереть все ваши пароли. В общем, тут от ситуации зависит, решайте сами, как вам удобнее хранить пароли. У меня распространены ситуации, когда я удаленно администрирую сервера, а на месте эникеи работают с пользователями. Чаще всего это не очень аккуратные и ответственные люди, иначе они бы работали с серверами.  Они часто забывают записать пароль, путают что-то и т.д. В итоге, когда один человек увольняется и приходит другой, оказывается, что найти пароли на некоторые ящики просто невозможно. Тут очень выручает возможность посмотреть пароль в базе. Я новому админу либо пароль говорю, либо весь дамп сразу отдаю, пусть работает. Если вы сами работаете с сервером и все аккуратно ведете, записываете, например, в keepass все пароли от почтовых ящиков, то смело шифруйте все пароли, так будет спокойнее. Последние 2 параметра domain_path и domain_in_mailbox указывайте по своему усмотрению. В файле конфигурации в комментариях расписано, за что они отвечают и в чем отличие. Мне кажется, удобно хранить директории именно в таком виде, как я указал. Получится следующий путь до ящика, если у вас архив почты будет жить, к примеру, в директории /mnt/mail — /mnt/mail/zeroxzed.ru/root@zeroxzed.ru. С параметрами разобрались. Сохраняем конфиг. Идем по адресу http://188.35.19.125/postfixadmin/setup.php и начинаем установку postfixadmin. Первым делом идет проверка всех необходимых для установки и работы компонентов. Для продолжения установки у вас должна быть такая картинка. Если чего-то не хватает, разбирайтесь по месту. Если делаете по моей инструкции, то все должно быть в порядке. Указывайте пароль установки и продолжайте. Вы должны получить строку с хэшем этого пароля. Добавляем полученную строку в файл конфигурации postfixadmin. # mcedit /var/www/html/postfixadmin/config.inc.php $CONF['setup_password'] = '67e46bdcc7aeb431f7af9a6d02f43352:30672e5a9deacaf505d32807b967caf9fd0c32ef'; Используя этот пароль, можно создать учетную запись администратора панели управления. Делаем это, учитывая, что пароль должен содержать не менее двух цифр. Если все сделали правильно, то увидите сообщение. Переходим по ссылке и авторизуемся с помощью учетной записи администратора, которую только что сделали. Вы должны увидеть основную страницу интерфейса postfixadmin. Теперь нам нужно добавить домен в панель управления. Идем в раздел Список доменов -> Новый домен и добавляем свой домен. При создании домена были добавлены стандартные алиасы, получателя для которых мы указали еще в конфиге — ящик root@zeroxzed.ru. Создание таких алиасов требование стандартов, но по факту, кроме спама, вы скорее всего ничего не будете получать по этим адресам. Так что их создание оставляйте на свое усмотрения. Я обычно их не делаю, так как ящик для этих алиасов все равно не читаю. Далее создадим почтовый ящик администратора — root@zeroxzed.ru. Для этого идем в раздел Обзор -> Создать ящик и заполняем поля. Непосредственно ящик на диске создан не будет, так как у нас еще не настроена почтовая система, но запись в базе данных появится. Это можно проверить через phpmyadmin. Как мы видим, пароль указан в зашифрованном виде. На этом установку и настройку postfixadmin завершаем. Интерфейс для управления почтовым сервером мы подготовили. Теперь можно заняться непосредственно настройкой postfix.   Настройка postfix   Сердце нашего почтового сервера на linux — postfix. В дистрибутиве centos он уже установлен, можно сразу переходить к настройке. Рисуем следующий конфиг. # mcedit /etc/postfix/main.cf soft_bounce = no queue_directory = /var/spool/postfix command_directory = /usr/sbin daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix mail_owner = postfix myhostname = mail.zeroxzed.ru mydomain = zeroxzed.ru myorigin = $myhostname inet_interfaces = all inet_protocols = ipv4 mydestination = localhost.$mydomain, localhost unknown_local_recipient_reject_code = 550 mynetworks = 127.0.0.0/8 alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases smtpd_banner = $myhostname ESMTP $mail_name debug_peer_level = 2 # Строки с PATH и ddd должны быть с отступом в виде табуляции от начала строки debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 sendmail_path = /usr/sbin/sendmail.postfix newaliases_path = /usr/bin/newaliases.postfix mailq_path = /usr/bin/mailq.postfix setgid_group = postdrop html_directory = no manpage_directory = /usr/share/man sample_directory = /usr/share/doc/postfix-2.10.1/samples readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES relay_domains = mysql:/etc/postfix/mysql/relay_domains.cf virtual_alias_maps = mysql:/etc/postfix/mysql/virtual_alias_maps.cf, mysql:/etc/postfix/mysql/virtual_alias_domain_maps.cf virtual_mailbox_domains = mysql:/etc/postfix/mysql/virtual_mailbox_domains.cf virtual_mailbox_maps = mysql:/etc/postfix/mysql/virtual_mailbox_maps.cf smtpd_discard_ehlo_keywords = etrn, silent-discard smtpd_forbidden_commands = CONNECT GET POST broken_sasl_auth_clients = yes smtpd_delay_reject = yes smtpd_helo_required = yes smtp_always_send_ehlo = yes disable_vrfy_command = yes smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname smtpd_data_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_pipelining, reject_multi_recipient_bounce, smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unknown_sender_domain smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_multi_recipient_bounce, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, smtp_tls_security_level = may smtpd_tls_security_level = may smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtp_tls_session_cache_database = btree:$data_directory/smtp_tls_session_cache smtpd_tls_key_file = /etc/postfix/certs/key.pem smtpd_tls_cert_file = /etc/postfix/certs/cert.pem tls_random_source = dev:/dev/urandom # Ограничение максимального размера письма в байтах message_size_limit = 20000000 smtpd_soft_error_limit = 10 smtpd_hard_error_limit = 15 smtpd_error_sleep_time = 20 anvil_rate_time_unit = 60s smtpd_client_connection_count_limit = 20 smtpd_client_connection_rate_limit = 30 smtpd_client_message_rate_limit = 30 smtpd_client_event_limit_exceptions = 127.0.0.0/8 smtpd_client_connection_limit_exceptions = 127.0.0.0/8 maximal_queue_lifetime = 1d bounce_queue_lifetime = 1d smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_sasl_path = private/dovecot-auth # Директория для хранения почты virtual_mailbox_base = /mnt/mail virtual_minimum_uid = 1000 virtual_uid_maps = static:1000 virtual_gid_maps = static:1000 virtual_transport = dovecot dovecot_destination_recipient_limit = 1 sender_bcc_maps = hash:/etc/postfix/sender_bcc_maps recipient_bcc_maps = hash:/etc/postfix/recipient_bcc_maps Я выделил жирным имя домена и путь для директории с почтовыми ящиками. Не забудьте поменять эти параметры на свои. Сохраняем конфиг и продолжаем настройку. В таком виде сервер еще не готов. Нужно теперь создать все то, что описано в файле конфигурации. Создаем папку для файлов с конфигурацией подключения к mysql и сами файлы подключения. # mkdir /etc/postfix/mysql && cd /etc/postfix/mysql # mcedit relay_domains.cf hosts = localhost user = postfix password = 12345678 dbname = postfix query = SELECT domain FROM domain WHERE domain='%s' and backupmx = '1' # mcedit  virtual_alias_domain_maps.cf hosts = localhost user = postfix password = 12345678 dbname = postfix query = SELECT goto FROM alias,alias_domain WHERE alias_domain.alias_domain = '%d' and alias.address = CONCAT('%u', '@', alias_domain.target_domain) AND alias.active = 1 # mcedit virtual_alias_maps.cf hosts = localhost user = postfix password = 12345678 dbname = postfix query = SELECT goto FROM alias WHERE address='%s' AND active = '1' # mcedit virtual_mailbox_domains.cf hosts = localhost user = postfix password = 12345678 dbname = postfix query = SELECT domain FROM domain WHERE domain='%s' AND backupmx = '0' AND active = '1' # mcedit virtual_mailbox_maps.cf hosts = localhost user = postfix password = 12345678 dbname = postfix query = SELECT maildir FROM mailbox WHERE username='%s' AND active = '1' Редактируем файл /etc/postfix/master.cf. Нам надо добавить строки, касающиеся настройки Submission для того, чтобы почтовый сервер работал на 587 порту. Смартфоны очень часто при настройке используют этот порт по-умолчанию, где-то даже без возможности изменить эту настройку. Приводим секцию, отвечающую за эту работу к следующему виду. submission inet n - n - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_wrappermode=no -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject -o smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,defer_unauth_destination -o milter_macro_daemon_name=ORIGINATING Обращаю внимание на пробел в начале строки, начиная со второй. Его надо обязательно оставить. Добавляем еще настройки для того, чтобы наш сервер поддерживал протокол SSL/TLS и слушал порт 465 smtps inet n - n - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject -o smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,defer_unauth_destination -o milter_macro_daemon_name=ORIGINATING В этот же файл добавляем еще одну настройку, которая будет указывать postfix, что доставкой почты у нас будет заниматься dovecot, который мы настроим следом. Добавляем в master.cf в самый конец. dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/libexec/dovecot/deliver -f ${sender} -d ${recipient} Сгенерируем самоподписанные ssl сертификаты для нашего почтового сервера. Позже отдельным пунктом я расскажу как использовать полноценные сертификаты. Они не всем нужны, поэтому показываю быструю настройку postfix на использование своих сертификатов, которые уже указаны в конфиге postfix. Создаем директорию и сами сертификаты: # mkdir /etc/postfix/certs # openssl req -new -x509 -days 3650 -nodes -out /etc/postfix/certs/cert.pem -keyout /etc/postfix/certs/key.pem Для генерации вам зададут несколько вопросов по поводу данных о сертификате. В принципе, можете там писать все, что угодно. Вот мои данные. Создадим файлы для информации о ящиках, куда будет собираться вся входящая и исходящая почта. # mcedit /etc/postfix/recipient_bcc_maps @zeroxzed.ru all_in@zeroxzed.ru # mcedit /etc/postfix/sender_bcc_maps @zeroxzed.ru all_out@zeroxzed.ru Создаем индексированные базы данных из этих файлов. Это нужно делать каждый раз, после изменения. # postmap /etc/postfix/recipient_bcc_maps /etc/postfix/sender_bcc_maps Теперь создайте два почтовых ящика all_in@zeroxzed.ru и all_out@zeroxzed.ru через postfixadmin. Немного поясню по этим ящикам — для чего они нужны. Изначально я их делал, когда пользователи использовали протокол pop3 без сохранения писем на сервере. Это позволяло организовать бэкап всей переписки. Эти ящики очень быстро заполняются и занимают огромный объем, поэтому их обязательно надо чистить. Я просто скриптами регулярно собирал всю почту в архивы с именами в виде дат. Если нужно было какое-то письмо найти, то просто распаковывал нужный архив. В случае с imap роль бэкапа отпадает, так как вся почта хранится на сервере. Но эти ящики все равно бывают полезны, когда пользователь, к примеру, удалил какое-то важное письмо и потом делает вид, что его и не было. Если это письмо пришло только сегодня и еще не успело улететь в бэкап, то кроме записи в логах об этом письме, вы не увидите само содержимое. А с такими ящиками все сразу будет понятно, и вопросы отпадут. Последнее применение — служба безопасности. Если у вас есть кто-то, кому положено читать всю переписку, то реализовать этот функционал можно таким простым способом. Все основные настройки для postfix мы сделали. Некоторые из них завязаны на работу с dovecot, который мы еще не настроили. Поэтому больше postfix не трогаем, не перезапускаем. Идем настраивать dovecot — imap сервер нашей почтовой системы. Настройка dovecot Займемся настройкой dovecot — сервер доставки почты пользователю по протоколам pop3 и imap. Я не вижу причин использовать pop3. Он неудобен по сравнению с imap. Чаще всего pop3 отключаю вовсе. Но это уже на ваше усмотрение. Приведу пример с настройкой обоих протоколов. Помимо основного функционала по доставке почты, я настрою несколько полезных плагинов. Расскажу о них поподробнее: Sieve — выполняет фильтрацию почты по заданным правилам в момент локальной доставки на почтовом сервере. Удобство такого подхода в том, что вы один раз можете настроить правило сортировки, и оно будет работать во всех клиентах, которыми вы будете получать почту по imap. Правила создаются, хранятся и исполняются на самом сервере. Acl — позволяет пользователям расшаривать папки в своем почтовом ящике и предоставлять доступ к этим папкам другим пользователям. Не часто видел, чтобы этот функционал настраивали и использовали. Думаю, просто по незнанию. По мне так очень удобный и полезный функционал. Часто вижу, что люди настраивают плагин quota, который позволяет ограничивать максимальный размер почтового ящика. Я лично в своей работе его не использую. Возможно, когда у тебя клиентов сотни и тысячи это имеет значение и надо обязательно настроить ограничение. Когда же ящиков меньше, нет смысла напрягать людей постоянной чисткой. Сейчас диски стоят не так дорого. Мне кажется, проще и дешевле увеличить место на сервере, нежели постоянно беспокоить пользователей необходимостью чистки ящика. Лучше ограничить максимальный размер письма, скажем 20-ю мегабайтами. Тогда сильно забить ящик даже при большом желании быстро не получится. А почта все-таки важный инструмент в работе. Мне кажется, ее лучше хранить как можно дольше. Есть еще один полезный плагин expire, который позволяет удалять устаревшие письма в определенных папках. Например, удалять все письма старше 30-ти дней в корзине и папке со спамом. Но реально пользоваться им не получается по простой причине. Разные почтовые клиенты создают различные папки для корзины и спама. Thunderbird создает папки с латинскими именами trash и spam, outlook с русскими, которые на почтовом сервере преобразуются в кодировку UTF7, мобильные клиенты тоже используют разные имена папок. В итоге нет единообразия, плагин полноценно не работает. Я рассказал об этих плагинах для наводки. Сам их не настраиваю, но если вам захочется реализовать описанный функционал, можете сами разобраться и настроить. Небольшую теорию я дал, теперь переходим к практике. Устанавливаем необходимые для dovecot пакеты. # yum install dovecot dovecot-mysql dovecot-pigeonhole Изначально конфиг dovecot разбит на отдельные сегменты и лежат в директории /etc/dovecot/conf.d. Каждый файл — отдельный функционал. Мне не нравится прыгать по файлам, поэтому я храню все в едином общем файле конфигурации /etc/dovecot/dovecot.conf. С ним мы и будем работать. Приводим его к следующему виду. # mcedit /etc/dovecot/dovecot.conf listen = * [::] mail_plugins = mailbox_alias acl protocols = imap pop3 sieve lmtp mail_uid = 1000 mail_gid = 1000 first_valid_uid = 1000 last_valid_uid = 1000 log_path = /var/log/dovecot/main.log info_log_path = /var/log/dovecot/info.log debug_log_path = /var/log/dovecot/debug.log ssl_protocols = !SSLv2 !SSLv3 ssl = required verbose_ssl = no ssl_cert = </etc/postfix/certs/cert.pem ssl_key = </etc/postfix/certs/key.pem ssl_cipher_list = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA ssl_dh_parameters_length = 2048 ssl_prefer_server_ciphers = yes disable_plaintext_auth = yes mail_location = maildir:/mnt/mail/%d/%u/ auth_default_realm = zeroxzed.ru auth_mechanisms = PLAIN LOGIN service auth { unix_listener /var/spool/postfix/private/dovecot-auth { user = postfix group = postfix mode = 0666 } unix_listener auth-master { user = vmail group = vmail mode = 0666 } unix_listener auth-userdb { user = vmail group = vmail mode = 0660 } } service lmtp { unix_listener /var/spool/postfix/private/dovecot-lmtp { user = postfix group = postfix mode = 0600 } inet_listener lmtp { address = 127.0.0.1 port = 24 } } userdb { args = /etc/dovecot/dovecot-mysql.conf driver = sql } passdb { args = /etc/dovecot/dovecot-mysql.conf driver = sql } auth_master_user_separator = * plugin { auth_socket_path = /var/run/dovecot/auth-master acl = vfile acl_shared_dict = file:/mnt/mail/shared-folders/shared-mailboxes.db sieve = /mnt/mail/sieve/%u.sieve mailbox_alias_old = Sent mailbox_alias_new = Sent Messages mailbox_alias_old2 = Sent mailbox_alias_new2 = Sent Items } protocol lda { mail_plugins = $mail_plugins sieve auth_socket_path = /var/run/dovecot/auth-master deliver_log_format = mail from %f: msgid=%m %$ log_path = /var/log/dovecot/lda-errors.log info_log_path = /var/log/dovecot/lda-deliver.log lda_mailbox_autocreate = yes lda_mailbox_autosubscribe = yes postmaster_address = root } protocol lmtp { info_log_path = /var/log/dovecot/lmtp.log mail_plugins = quota sieve postmaster_address = postmaster lmtp_save_to_detail_mailbox = yes recipient_delimiter = + } protocol imap { mail_plugins = $mail_plugins imap_acl imap_client_workarounds = tb-extra-mailbox-sep mail_max_userip_connections = 30 } protocol pop3 { mail_plugins = $mail_plugins pop3_client_workarounds = outlook-no-nuls oe-ns-eoh pop3_uidl_format = %08Xu%08Xv mail_max_userip_connections = 30 } service imap-login { service_count = 1 process_limit = 500 } service pop3-login { service_count = 1 } service managesieve-login { inet_listener sieve { port = 4190 } } namespace { type = private separator = / prefix = inbox = yes mailbox Sent { auto = subscribe special_use = \Sent } mailbox "Sent Messages" { auto = no special_use = \Sent } mailbox "Sent Items" { auto = no special_use = \Sent } mailbox Drafts { auto = subscribe special_use = \Drafts } mailbox Trash { auto = subscribe special_use = \Trash } mailbox "Deleted Messages" { auto = no special_use = \Trash } mailbox Junk { auto = subscribe special_use = \Junk } mailbox Spam { auto = no special_use = \Junk } mailbox "Junk E-mail" { auto = no special_use = \Junk } mailbox Archive { auto = no special_use = \Archive } mailbox Archives { auto = no special_use = \Archive } } namespace { type = shared separator = / prefix = Shared/%%u/ location = maildir:%%h:INDEX=%h/shared/%%u subscriptions = yes list = children } Создаем группу и пользователя с указанными в конфиге uid 1000. # groupadd  -g 1000 vmail # useradd -d /mnt/mail/ -g 1000 -u 1000 vmail # chown vmail. /mnt/mail Создаем конфигурационные файлы для доступа к mysql базе. # mcedit /etc/dovecot/dovecot-mysql.conf driver = mysql default_pass_scheme = CRYPT connect = host=127.0.0.1 dbname=postfix user=postfix password=12345678 user_query = SELECT '/mnt/mail/%d/%u' as home, 'maildir:/mnt/mail/%d/%u' as mail, 1000 AS uid, 1000 AS gid, concat('*:bytes=', quota) AS quota_rule FROM mailbox WHERE username = '%u' AND active = '1' password_query = SELECT username as user, password, '/mnt/mail/%d/%u' as userdb_home, 'maildir:/mnt/mail/%d/%u' as userdb_mail, 1000 as userdb_uid, 1000 as userdb_gid, concat('*:bytes=', quota) AS userdb_quota_rule FROM mailbox WHERE username = '%u' AND active = '1' Создадим директорию и файлы для логов. # mkdir /var/log/dovecot # cd /var/log/dovecot && touch main.log info.log debug.log lda-errors.log lda-deliver.log lmtp.log # chown -R vmail:dovecot /var/log/dovecot Создаем пару служебных папок для плагинов sieve и acl. # mkdir /mnt/mail/sieve && mkdir /mnt/mail/shared-folders # chown -R vmail. /mnt/mail И небольшой штрих в завершении настройки. # chown vmail. /var/run/dovecot/auth-master Уже не помню, зачем это было нужно, запись осталась в черновиках. Знаю только, что какая-то ошибка всплывала без этого. На этом основная настройка почтового сервера на базе postfix и dovecot завершена. Можно перезапускать службы и проверять работу системы. # systemctl restart postfix # systemctl start dovecot # systemctl enable dovecot     Проверка работы почтового сервера Самый простой и быстрый способ проверить работу почтового сервера — отправить на него письмо. Я буду отправлять со своего почтового адреса zeroxzed@gmail.com на адрес root@zeroxzed.ru. Вот что должно быть в логе, если у вас все правильно настроено и почтовый сервер нормально работает. # cat /var/log/maillog Mar 10 21:56:27 mail postfix/smtpd[28075]: connect from mail-yw0-f172.google.com[209.85.161.172] Mar 10 21:56:28 mail postfix/smtpd[28075]: Anonymous TLS connection established from mail-yw0-f172.google.com[209.85.161.172]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) Mar 10 21:56:28 mail postfix/smtpd[28075]: D4263420BB7B: client=mail-yw0-f172.google.com[209.85.161.172] Mar 10 21:56:29 mail postfix/cleanup[28086]: D4263420BB7B: message-id=<CAHWPLcOeqf6uNHRg34+wuppDUGPDLY=fp8s-E=o9fmxYMS48cQ@mail.gmail.com> Mar 10 21:56:29 mail postfix/qmgr[28042]: D4263420BB7B: from=<zeroxzed@gmail.com>, size=2533, nrcpt=2 (queue active) Mar 10 21:56:29 mail postfix/pipe[28089]: D4263420BB7B: to=<all_in@zeroxzed.ru>, relay=dovecot, delay=0.39, delays=0.33/0.02/0/0.05, dsn=2.0.0, status=sent (delivered via dovecot service) Mar 10 21:56:29 mail postfix/pipe[28090]: D4263420BB7B: to=<root@zeroxzed.ru>, relay=dovecot, delay=0.4, delays=0.33/0.03/0/0.04, dsn=2.0.0, status=sent (delivered via dovecot service) Mar 10 21:56:29 mail postfix/qmgr[28042]: D4263420BB7B: removed Mar 10 21:56:29 mail postfix/smtpd[28075]: disconnect from mail-yw0-f172.google.com[209.85.161.172] Пояснять тут нечего, по логу все понятно. Письмо было доставлено в указанный ящик и в общий ящик для сбора всей входящей почты. В директории /mnt/mail была создана директория с именем домена zeroxzed.ru, а в ней созданы 3 папки с именами ящиков: all_in@zeroxzed.ru all_out@zeroxzed.ru root@zeroxzed.ru Директории с почтовыми ящиками создаются в момент получения первого письма в ящик. Непрочитанное письмо помещается в директорию /new в почтовом ящике. После прочтения переносится в /cur. Попробуем теперь подключиться к почтовому ящику по imap, прочитать письмо и отправить ответ. Настроим любой почтовый клиент для проверки работы настроенного почтового сервера. Я для этих целей буду использовать Thunderbird. Из всех почтовых клиентов мне он нравится больше всего. В основном из-за его портированной версии. Указываем следующие настройки. Так как мы используем самоподписанный сертификат ssl, почтовый клиент предупредит нас о том, что серверу нельзя доверять. Нас это не пугает, добавляем сертификат в список доверенных и продолжаем работать. Позже получим и настроим нормальный сертификат. Я подключился к почтовому ящику и увидел тестовые письма. Отвечу на одно из них и посмотрю в логе, как прошла отправка. У меня еще раз выскочило окно с предупреждением о небезопасном сертификате. Еще раз добавляю его в исключения. Это нормально, сертификат проверяется во время получения почты в dovecot, а во время отправки в postfix. Так что нужны 2 подтверждения. Отправляю письмо еще раз и смотрю лог. # cat /var/log/maillog Mar 10 22:10:12 mail postfix/smtpd[28764]: connect from broadband-75-37-235-139.moscow.gw.ru[75.37.235.139] Mar 10 22:10:12 mail postfix/smtpd[28764]: Anonymous TLS connection established from broadband-75-37-235-139.moscow.gw.ru[75.37.235.139]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) Mar 10 22:10:12 mail postfix/smtpd[28764]: B24C2420BB70: client=broadband-75-37-235-139.moscow.gw.ru[75.37.235.139], sasl_method=PLAIN, sasl_username=root@zeroxzed.ru Mar 10 22:10:12 mail postfix/cleanup[28779]: B24C2420BB70: message-id=<aaac96c3-197e-c6bd-4dfe-85d09bce216a@zeroxzed.ru> Mar 10 22:10:12 mail postfix/qmgr[28042]: B24C2420BB70: from=<root@zeroxzed.ru>, size=955, nrcpt=2 (queue active) Mar 10 22:10:12 mail postfix/smtpd[28764]: disconnect from broadband-75-37-235-139.moscow.gw.ru[75.37.235.139] Mar 10 22:10:12 mail postfix/pipe[28784]: B24C2420BB70: to=<all_out@zeroxzed.ru>, relay=dovecot, delay=0.14, delays=0.07/0.01/0/0.06, dsn=2.0.0, status=sent (delivered via dovecot service) Mar 10 22:10:13 mail postfix/smtp[28783]: B24C2420BB70: to=<zeroxzed@gmail.com>, relay=gmail-smtp-in.l.google.com[64.233.163.26]:25, delay=0.62, delays=0.07/0.01/0.28/0.26, dsn=2.0.0, status=sent (250 2.0.0 OK 1489173013 13si2106703ljv.3 - gsmtp) Mar 10 22:10:13 mail postfix/qmgr[28042]: B24C2420BB70: removed Все в порядке. Видно подключение с моего ip, успешную sasl авторизацию, формирование письма на сервере, присваивание ему message-id, отправка копии письма в ящик для сбора исходящей почты и отправка оригинала в ящик получателя. Все этапы прошли без ошибок. Расскажу, куда еще надо смотреть для отладки почтовой системы. Да и не только отладки, во время работы периодически придется разбираться, куда ушло то или иное письмо, кто и когда подключался к ящику. Разные ситуации бывают. В файле /var/log/dovecot/lda-deliver.log содержится информация обо всех пришедших письмах — когда, от кого и в какой ящик было положено. Mar 10 22:25:29 lda(all_in@zeroxzed.ru): Info: mail from zeroxzed@gmail.com: msgid=<CAHWPLcNG=WMOoWW2Y_Lw4qn9+V4TOrbxZpwtA=O+CSEBaiwuBg@mail.gmail.com> saved mail to INBOX Mar 10 22:25:29 lda(root@zeroxzed.ru): Info: mail from zeroxzed@gmail.com: msgid=<CAHWPLcNG=WMOoWW2Y_Lw4qn9+V4TOrbxZpwtA=O+CSEBaiwuBg@mail.gmail.com> saved mail to INBOX Mar 10 22:25:49 lda(all_out@zeroxzed.ru): Info: mail from root@zeroxzed.ru: msgid=<75358e4d-7c8e-24c2-a21f-7ee0df2a4704@zeroxzed.ru> saved mail to INBOX В /var/log/dovecot/info.log информация о подключениях к почтовым ящикам — кто, когда, откуда и каким способом авторизовывался на сервере. Mar 10 22:10:20 imap-login: Info: Login: user=<root@zeroxzed.ru>, method=PLAIN, rip=75.37.235.139, lip=188.35.19.125, mpid=28790, TLS, session=<3tDeHGVKpQBNJeCL> Mar 10 22:19:39 imap-login: Info: Login: user=<root@zeroxzed.ru>, method=PLAIN, rip=75.37.235.139, lip=188.35.19.125, mpid=29248, TLS, session=<7VY8PmVKbwBNJeCL> Остальное уже не так полезно. Сами посмотрите, что собирается в остальных лог файлах. На текущий момент сервер полностью работоспособен. В таком виде им без проблем можно пользоваться. Но функционал полностью не раскрыт. Использовать плагины sieve и acl через удаленные почтовые клиенты неудобно. Проще всего их настроить через web почту roundcube. Установим эту web панель на наш почтовый сервер.   Установка web интерфейса roundcube Установим и настроим самый популярный web интерфейс для postfix — roundcube. Скачиваем исходники. # cd /usr/src # wget https://github.com/roundcube/roundcubemail/releases/download/1.2.9/roundcubemail-1.2.3-complete.tar.gz Не забудьте проверить в момент установки, какая версия является самой свежей на текущий момент. Нет необходимости устанавливать устаревшую версию. Рекомендую ставить самую последнюю на момент настройки. # yum install php-pear php-mcrypt php-intl php-ldap php-pear-Net-SMTP php-pear-Net-IDNA2 php-pear-Mail-Mime php-pear-Net-Sieve # tar -xzvf roundcubemail-* # mv roundcubemail-1.2.9 /var/www/html/webmail # chown -R apache. /var/www/html/webmail Переходим в браузер по следующей ссылке для установки roundcube — http://188.35.19.125/webmail/installer/. Вы увидите несколько незначительных замечаний. На них можно не обращать внимание, если установщик позволяет нажать кнопку NEXT. Единственное, рекомендую установить правильный часовой пояс в /etc/php.ini и перезапустить после этого httpd. На следующем этапе нам надо указать настройки подключения к mysql базе. Предварительно ее следует создать через phpmyadmin. Я создал пользователя roundcube и такую же базу с полными правами пользователя на нее. Эти параметры указал в настройках. Так же на этой странице нужно будет указать несколько параметров: smtp_server — пусто (ничего не пишем) language — ru_RU Выбираем плагины — managesieve, userinfo, acl. Остальные на свое усмотрение. Жмем CREATE CONFIG. Должны увидеть сообщение: The config file was saved successfully into RCMAIL_CONFIG_DIR directory of your Roundcube installation. Жмем CONTINUE. Открывается страница с проверкой настроек. Тут проверять неудобно, можно этого не делать. Зайдем в почтовый ящик и там все проверим. Если что, конфиг потом все равно можно вручную отредактировать. Папку /var/www/html/webmail/installer удаляем. Заходим в почтовый ящик через roundcube — http://188.35.19.125/webmail/ Набирать нужно полное имя ящика и пароль. Если все сделали правильно, должны попасть в свой почтовый ящик. Ну вот и все. Можно пользоваться web интерфейсом для почтового сервера. У меня есть статья по настройке мобильной версии roundcube. Рекомендую ее настроить, если есть необходимость. Тема качественная и добротная. Пользоваться удобно. Дальше рассмотрим настройку и использование плагинов acl и sieve с помощью roundcube.   Настройка фильтра почты sieve Sieve очень удобная штука, но вот хорошего интерфейса для управления через почтовый клиент я не знаю. Существует плагин для thunderbird, который так и называется sieve. Но лично мне он не понравился вообще, так как предлагает писать правила определенным кодом. Для этого надо знать синтаксис, тратить время. Можете сами на него посмотреть — https://github.com/thsmi/sieve. К счастью, есть удобный способ писать правила фильтрации для sieve через roundcube. Там это реализовано отдельным плагином managesieve, который мы активировали во время установки. Для создания правила фильтрации, зайдите в свой почтовый ящик через roundcube. Переходите в раздел Настройки -> Фильтры и создавайте новое правило. После этого письма будут обрабатываться правилом сразу после поступления в почтовый сервер, в независимости от вашего подключения к ящику. В папке /mnt/mail/sieve появилась запись с настроенным правилом. Можете познакомиться с синтаксисом написания правил. Он не сложный. Настройка автоответчика В roundcube есть замечательная возможность настроить автоответчик в почтовом ящике. Это актуально, к примеру, если вы уходите в отпуск. Вы можете сами настроить автоответчик, который будет отправлять письмо с указанной вами информацией всем, от кого будут приходить письма в ваш ящик. Возможность эта реализована на базе того же плагина managesieve. По-умолчанию она отключена. Активировать ее нужно вручную. Для того, чтобы модуль автоответчика заработал, отредактируйте конфигурационный файл плагина. Для этого открываем его в моем случае по следующему адресу: # mcedit /var/www/html/webmail/plugins/managesieve/config.inc.php Изменяем там параметр: $config['managesieve_vacation'] = 1; После этого достаточно просто обновить веб интерфейс roundcube, и появятся новые настройки по адресу Настройки -> Отпуск На вкладке Дополнительные настройки есть возможность настроить различные полезные действия, в том числе пересылку входящей почты вашему заместителю.   Общие папки по imap Рассмотрим настройку необычного и полезного функционала в виде общих папок. С их помощью один пользователь почтового ящика может предоставить другому пользователю доступ к папке внутри своего почтового ящика. Где и как использовать этот функционал, каждый может придумать сам, в зависимости от своих потребностей. Мне кажется это удобным в том случае, когда создан какой-то общий ящик, на который только поступает информация и нет необходимости писать ответ от его имени. То есть по сути работает как обычный почтовый алиас. Но в случае с алиасом и несколькими почтовыми ящиками, письмо падает в каждый ящик. Если таких писем и получателей много, то идет большое дублирование одного и того же письма в рамках почтового сервера. Если сделать ящик и расшарить на нем папку, подключить ее всем пользователям, то дублирования почты не будет. Каждый сможет прочитать письмо, без необходимости его доставки в каждый конкретный ящик. Настроим общую папку imap. Хотя настраивать нам, по сути, нечего. Мы уже все настроили ранее. Добавили соответствующие настройки в dovecot и активировали плагин acl в roundcube. Теперь нужно просто сделать папку и открыть ее для другого пользователя. Для этого идем в раздел Настройки -> Папки. Создаем там любую папку. В моем случае это папка с названием Общая. Добавляем необходимый доступ либо всем ящикам в домене, либо какому-то конкретному. Так же можно указать, какого рода это будет доступ: чтение запись удаление Заходим в ящик, которому добавили общий доступ и проверяем. Все в порядке, общая папка imap настроена и подключена. В папке /mnt/mail/shared-folders появился файл с настроенным выше правилом. На этом настройка пользовательского функционала закончена. В принципе, почтовый сервер полностью готов к работе. Но мы сделаем еще несколько полезных настроек на стороне сервера. Настройка dkim и spf Напишу своими словами как я понимаю работу dkim. С помощью dkim вся исходящая почта сервера подписывается электронной цифровой подписью, связанной с именем домена. Открытый ключ шифрования с помощью DNS публикуется в txt записи. Таким образом, удаленный сервер, при получении письма от вас, сравнивает цифровую подпись с опубликованным в dns открытым ключом вашего домена. Если все в порядке, то считает, что ваше письмо в самом деле пришло от вас, а не от мошенников. То есть с помощью этой технологии можно однозначно идентифицировать отправителя. Некоторые считают, что эта технология помогает бороться со спамом. Не знаю, насколько это верно. Спамеру не составит большого труда настроить на своем сервере dkim и отправлять спам, но подписанный электронной цифровой подписью. Теоретически, dkim помогает защититься от подделки адреса отправителя, когда письмо якобы от вас шлет совсем другой сервер. Но с этим можно бороться и другими способами. В общем, я до конца не понимаю, зачем это надо. Прошу поделиться в комментариях тем, к кого есть бОльший опыт. Я только недавно стал шагать в ногу со временем и настраивать dkim. Раньше всегда без него обходился. Плюс настройки dkim я вижу только в том, что автоматические фильтры определения спама будут добавлять больше траста письмам с корректной dkim подписью. У вас будет больше шанса не попасть в спам при прочих равных условиях. В принципе, ради этого можно немного заморочиться. Для настройки dkim устанавливаем соответствующий пакет: # yum install opendkim Создаем директорию для хранения ключей: # mkdir -p /etc/postfix/dkim && cd /etc/postfix/dkim Генерируем ключи для домена: # opendkim-genkey -D /etc/postfix/dkim/ -d zeroxzed.ru -s mail zeroxzed.ru имя почтового домена mail непосредственно имя сервера На выходе получаете пару файлов — закрытый (приватный) и открытый ключ. Закрытый останется на сервере, открытый будет опубликован в dns. Переименуем их сразу, чтобы не путаться, если у вас будет несколько доменов. Ключи нужно будет делать для каждого домена. # mv mail.private mail.zeroxzed.ru.private # mv mail.txt mail.zeroxzed.ru.txt Создаем файл с таблицей ключей, в которой будут описаны все домены. В данном случае только один. # mcedit keytable mail._domainkey.zeroxzed.ru zeroxzed.ru:mail:/etc/postfix/dkim/mail.zeroxzed.ru.private Тут же создаем еще один файл, в котором будет описано, каким ключом подписывать письма каждого домена. У нас один домен, поэтому только одна запись. # mcedit signingtable *@zeroxzed.ru mail._domainkey.zeroxzed.ru Выставляем права доступа на все файлы: # chown root:opendkim * # chmod u=rw,g=r,o= * Рисуем конфиг службы. # mcedit /etc/opendkim.conf AutoRestart Yes AutoRestartRate 10/1h PidFile /var/run/opendkim/opendkim.pid Mode sv Syslog yes SyslogSuccess yes LogWhy yes UserID opendkim:opendkim Socket inet:8891@localhost Umask 022 Canonicalization relaxed/relaxed Selector default MinimumKeyBits 1024 KeyFile /etc/postfix/dkim/mail.zeroxzed.ru.private KeyTable /etc/postfix/dkim/keytable SigningTable refile:/etc/postfix/dkim/signingtable Добавляем в конфигурационный файл postfix в самый конец следующие параметры: # mcedit /etc/postfix/main.cf smtpd_milters = inet:127.0.0.1:8891 non_smtpd_milters = $smtpd_milters milter_default_action = accept milter_protocol = 2 Перезапускаем postfix и dkim, последний добавляем в автозагрузку. # systemctl restart postfix # systemctl restart opendkim.service # systemctl enable opendkim.service Теперь нам надо добавить открытый ключ в dns. Идем в консоль управления dns и добавляем новую txt запись. Ее содержание берем из файла /etc/postfix/dkim/mail.zeroxzed.ru.txt cat /etc/postfix/dkim/mail.zeroxzed.ru.txt mail._domainkey IN TXT ( "v=DKIM1; k=rsa; " "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQClZX2xWRDISlVLF4b4pUiinY5N9WN7VXEHeyPw8smHTamXh35wJoh+j0+MIQDWG/KtdCcETeawTuypXbvtbneXniYR0iiv6kt754T2WXBjz7O/uHL+vK58LhJsm4TGyhUN6ZBit+w22jG92zdeybSZeU/g7hQdkaAAi0I+0nIkUwIDAQAB" ) ; ----- DKIM key mail for zeroxzed.ru Убираем кавычки, лишние проблемы и вставляем. Должно получиться вот так: Проверяю работу. Отправляю письмо на gmail и смотрю лог почтового сервера: # cat /var/log/maillog Mar 17 17:40:26 mail postfix/smtpd[22352]: connect from localhost[127.0.0.1] Mar 17 17:40:26 mail postfix/smtpd[22352]: BB1794195584: client=localhost[127.0.0.1] Mar 17 17:40:26 mail postfix/cleanup[22364]: BB1794195584: message-id=<baf63dcec016594d49f2d80f815e5d26@zeroxzed.ru> Mar 17 17:40:26 mail opendkim[21744]: BB1794195584: DKIM-Signature field added (s=mail, d=zeroxzed.ru) Mar 17 17:40:26 mail postfix/qmgr[21990]: BB1794195584: from=<root@zeroxzed.ru>, size=593, nrcpt=2 (queue active) Mar 17 17:40:26 mail postfix/pipe[22369]: BB1794195584: to=<all_out@zeroxzed.ru>, relay=dovecot, delay=0.14, delays=0.11/0.02/0/0.02, dsn=2.0.0, status=sent (delivered via dovecot service) Mar 17 17:40:26 mail postfix/smtpd[22352]: disconnect from localhost[127.0.0.1] Mar 17 17:40:27 mail postfix/smtp[22370]: BB1794195584: to=<zeroxzed@gmail.com>, relay=gmail-smtp-in.l.google.com[64.233.163.26]:25, delay=0.84, delays=0.11/0.02/0.31/0.4, dsn=2.0.0, status=sent (250 2.0.0 OK 1489761627 185si4568435lfa.398 - gsmtp) Все в порядке, электронная цифровая подпись установлена. Проверим, как гугл отреагировал на нашу подпись: Тоже все в порядке. Подпись выполнена корректно, проверку прошла. Дополнительно, проверить корректность dkim записи в dns можно онлайн сервисом — http://dkimcore.org/c/keycheck. Настроим еще одно средство для повышения доверия к нашей почте со стороны других серверов — spf. Расскажу опять своими словами для чего это нужно. Spf запись добавляется в виде txt записи в dns вашего домена. С помощью этой записи вы указываете, какие ip адреса имеют право отправлять почту от вашего имени. Если кто-то из спамеров будет использовать ваше имя домена при рассылке спама, он не пройдет проверку по spf и скорее всего будет идентифицирован как спам. Можно указать конкретные ip адреса в записи, а можно сказать, чтобы ip адреса проверялись по спискам A и MX записей. У нас простой случай и только 1 сервер с одним ip, поэтому укажем конкретно этот ip адрес. Идем в панель управления dns и добавляем новую txt запись. zeroxzed.ru. TXT v=spf1 ip4:188.35.19.125 ~all Больше ничего делать не надо. Снова отправляем письмо на gmail и смотрим логи. Обращаю внимание на прошлый скрин, когда мы проверяли dkim и еще не настроили spf, и этот. Видно, что запись работает, гугл определил наш ip, как доверенный для отправки писем с этого домена.   Дополнительный функционал почтового сервера postfix Я рассмотрел и настроил наиболее актуальный с моей точки зрения функционал почтового сервера. В статье я основывался исключительно на своем опыте работы с почтой в малых и средних организациях, поэтому не претендую на истину в последней инстанции. Рекомендую осмысленно подходить к настройке своего сервера и решать, что нужно именно вам. Будет хорошо, если кто-то укажет на мои ошибки или подскажет какие-то более удобные и эффективные приемы для решения затронутых задач. В данном виде почтовый сервер представляет собой готовое и законченное решение, но есть еще несколько вещей, которые ему бы не помешали. Я их сейчас перечислю, а затем постараюсь постепенно писать статьи на указанные темы и ставить на них ссылки в этой теме. Вот список того, что по моему мнению нужно еще настроить на почтовом сервере: Защиту от подбора паролей с помощью fail2ban. Мониторинг почтового сервера postfix с помощью zabbix. Сбор статистики с помощью pflogsumm или чего-то подобного. Просмотр и анализ логов с помощью webmin. Использование бесплатных сертификатов let’s encrypt. Регулярную очистку служебных почтовых ящиков. Бэкап всей почтовой базы. Расскажу еще почему я не настраиваю некоторые популярные программы, которые использую на почтовых серверах: Clamav — известный антивирус. Считаю, что сейчас он не актуален, так как вирусов, от которых он способен защитить, я уже давно не видел. Сейчас вирусная эпидемия шифровальщиков. От них он не защищает. Spamassasin — популярный бесплатный антиспам фильтр. Скажу честно, работал с ним очень мало и могу быть не объективен. Насколько я видел его настройку и работу — он требует к себе некоторого внимания, калибровки, особенно на начальном этапе. Мне обычно не хочется этим заниматься. Graylist — эффективное средство борьбы со спамом. Я уже подробно его рассматривал, когда писал про iredmail, так что не буду повторяться. Скажу лишь, что режет спам очень эффективно и бесплатно, но есть существенные неудобства, которые по моему мнению не перекрывают плюсы. Поэтому я не использую. В качестве антиспама я предпочитаю коммерческое решение — Kaspersky Anti-Spam. Я знаю этот продукт уже лет 8. Он действительно отлично фильтрует спам. Ложных срабатываний вообще не припоминаю, 95% спама фильтрует, может больше. С ним вопрос спама отпадает вообще. Стоит он недорого, можно купить лицензию на меньшее количество ящиков, чем реально используется в системе. Этот вопрос никак не отслеживается и на качество работы не влияет. Но нужно понимать, что это уже нарушение лицензионного соглашения. Но можно всякие хитрости придумать, чтобы и фильтровать и не нарушать.   Борьба со спамом средствами postfix Сначала хотел сразу все настройки postfix разместить в соответствующем разделе в едином конфиге, но потом передумал и решил все же вынести этот вопрос на отдельное рассмотрение. Возможно, не каждому захочется сразу в эту тему углубляться. Все, что рассказано выше, позволит настроить полноценный почтовый сервер, который будет успешно принимать почту и доставлять ее пользователям. Но в таком виде он будет принимать слишком много спама, но зато не будет проблем с тем, что от кого-то что-то не придет. Как ни крути, но все средства борьбы со спамом так или иначе несут накладные расходы в виде ложных срабатываний с той или иной вероятностью. Если вы решите не заморачиваться и купить Kaspersky Anti-Spam, можете этот раздел не читать. Он сам реализует все те проверки, что мы будем делать. Если же хотите своими силами бороться со спамом средствами postfix, то давайте дальше разбираться. Я буду использовать штатные возможности postfix, позволяющие отсеять спам по тем или иным параметрам еще до получения письма. Это очень эффективный способ с точки зрения производительности. Благодаря этому, правильно настроенный на отсев спама postfix часто ставят перед exchange, чтобы снизить на него нагрузку. Сразу дам ссылки на официальную документацию с описанием параметров, которые я буду использовать: smtpd_helo_restrictions smtpd_sender_restrictions smtpd_recipient_restrictions smtpd_data_restrictions smtpd_client_restrictions Есть еще парочка — smtpd_etrn_restrictions и smtpd_end_of_data_restrictions, но я ими не пользуюсь.   Обращаю внимание на то, что нужно очень аккуратно работать с настройками, о которых пойдет речь. Нужно четко понимать как, зачем и что вы делаете. Неверные настройки могут нарушить нормальное хождение почты. Нужно уметь анализировать лог файл почтового сервера и понимать, что там происходит. Долго думал, как лучше всего представить информацию по этому разделу. В итоге решил просто написать часть конфига, которая отвечает за restrictions с комментариями. Более подробную информацию по каждой настройке вы можете найти в официальной документации postfix, ссылки я привел выше, либо в гугле. Данные настройки это моя многолетняя калькуляция различных параметров, собранных из черновиков и рабочих серверов. Не везде все было настроено именно в таком виде, так как ситуации бывают разные. Сейчас я постарался все собрать в одном месте и аккуратно описать. Те проверки в борьбе со спамом, что вам не нужны, просто закомментируйте. В конце я еще пройдусь по некоторым из них и поделюсь своим опытом. #Описание списков исключений smtpd_restriction_classes = white_client_ip, black_client_ip, block_dsl, white_client, white_helo, black_client, mx_access # IP адреса, которые нужно пропускать всегда white_client_ip = check_client_access hash:/etc/postfix/lists/white_client_ip # IP адреса, которые нужно блокировать всегда black_client_ip = check_client_access hash:/etc/postfix/lists/black_client_ip # E-mail, которые нужно пропускать всегда white_client = check_sender_access hash:/etc/postfix/lists/white_client # E-mail, которые нужно блокировать всегда black_client = check_sender_access hash:/etc/postfix/lists/black_client # Неправильные значения HELO, которые мы тем не менее принимаем white_helo = check_sender_access hash:/etc/postfix/lists/white_helo # Правила для блокировки различных динамических ip. block_dsl = check_client_access regexp:/etc/postfix/lists/block_dsl # Список приватных сетей, которые не могут быть использованы в качестве IP для MX записей mx_access = check_sender_mx_access cidr:/etc/postfix/lists/mx_access # Проверки на основе данных, переданных в HELO/EHLO hostname smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, white_client_ip, white_helo, black_client_ip, block_dsl, # Отказываем серверам, у которых в HELO несуществующий или не FQDN адрес reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, # Запрещаем приём писем от серверов, представляющихся адресом, для которого не существует A или MX записи. reject_unknown_helo_hostname # Проверки клиентского компьютера или другого почтового сервера, который соединяется с сервером postfix для отправки письма smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, # Отвергает запрос, когда клиент отправляет команды SMTP раньше времени, еще не зная, поддерживает ли Postfix конвейерную обработку команд ESMTP reject_unauth_pipelining, # Блокируем клиентов с адресами from, домены которых не имеют A/MX записей reject_unknown_address, reject_unknown_client_hostname # Проверки исходящей или пересылаемой через нас почты на основе данных MAIL FROM smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, white_client, black_client, # Запрет отправки писем, когда адрес MAIL FROM не совпадает с логином пользователя reject_authenticated_sender_login_mismatch, # Отклоняем письма от несуществующих доменов reject_unknown_sender_domain, # Отклоняем письма от доменов в не FQDN формате reject_non_fqdn_sender, # Отклонение писем с несуществующим адресом отправителя reject_unlisted_sender, reject_unauth_destination, # Отклонять сообщения от отправителей, ящики которых не существуют, использовать аккуратно #reject_unverified_sender, mx_access # Правила приема почты нашим сервером на основе данных RCPT TO smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, # Отклоняет всю почту, что адресована не для наших доменов reject_unauth_destination, # Отклонение писем с несуществующим адресом получателя reject_unlisted_recipient, # Отклоняет сообщения на несуществующие домены reject_unknown_recipient_domain, # Отклоняет сообщения если получатель не в формате FQDN reject_non_fqdn_recipient, # Отклоняем прием от отправителя с пустым адресом письма, предназначенным нескольким получателям. reject_multi_recipient_bounce У меня во всех ограничениях первыми правилами стоят разрешения для mynetworks и авторизовавшихся пользователей. Важно понимать, что это значит и для чего сделано. Ограничения читаются последовательно в порядке их перечисления. Таким образом, мы своих пользователей пускаем мимо ограничений, а для всех остальных выполняются проверки. Теперь важные комментарии по указанным параметрам. Если бы все почтовые сервера всех системных администраторов были настроены по правилам, то эти комментарии не были бы нужны. Пройдемся по некоторым ограничениям, которые нужно включать осторожно: reject_invalid_helo_hostname и reject_unknown_helo_hostname — под эти правила иногда попадают почтовые серверы клиентов, которые не очень хорошо настроены. У них бывают неправильные адреса, кривые записи dns, отсутствие обратных зон и т.д. Их не много, но попадаются. Это не страшно, если вы регулярно следите за сервером. Отправитель получит сразу сообщение о том, что его письмо не дошло до вас. Если он как-то сообщит вам о проблеме, вы легко добавите его в белый список и все будет нормально. Если вам не хочется следить за сервером, лучше не указывайте эти ограничения. Но спам они отсекают не плохо. Сюда попадают все завирусованные компьютеры и сервера без нормальных настроек dns (а их чаще всего и нет). reject_unverified_sender — специально его закомментировал. Я тестировал этот параметр. В принципе, работает нормально, но есть, как обычно, нюансы. Поясню, что делает этот параметр. Когда вам кто-то шлет письмо, ваш сервер обращается к серверу отправителю и спрашивает его стандатрной командой, есть ли на сервере такой отправитель. Если удаленный сервер отвечает, что есть, то никаких проблем — письмо принимается. Если удаленный сервер не отвечает или говорит, что такого адресата нет — письмо отклоняем. Очевидно, что такие проверки создают дополнительную постоянную нагрузку. Это нужно учитывать. К тому же, у вас почтовый лог постоянно будет забит этими проверками, особенно, если вам приходит много спама. На каждое спамовое письмо будет идти проверка, а сервера отправителя скорее всего либо нет, либо он неправильный, либо не отвечает и т.д. Все это будет постоянно проверяться и фиксироваться. В общем, я не использую. На время отладки ограничений, рекомендую пользоваться параметром: soft_bounce = yes Когда он включен, все ответы сервера с кодами ошибок 5XX, заменяются на 4ХХ. То есть постоянная ошибка, которая сразу отклоняет письмо, заменяется на временную, которая предлагает повторить отправку позже. Таким образом, вы увидите работу всех ограничений, но письма не будут отклонены навсегда. Сервер отправителя через некоторое время снова придет к вам с новой попыткой доставки почты. Письмо безвозвратно не отклоняется. Вы можете проанализировать работу фильтра и решить, ставить его на постоянную работу или с ним что-то не так. Создадим теперь файлы с белыми и черными списками. cd /etc/postfix/lists && touch white_client_ip black_client_ip white_client black_client white_helo block_dsl mx_access Ниже пример содержания этих файлов. Вы можете менять по своему усмотрению. # cat white_client_ip 195.28.34.162 OK 141.197.4.160 OK # cat black_client_ip 205.201.130.163 REJECT You IP are blacklisted! 198.2.129.162 REJECT You IP are blacklisted! # cat white_client # Принимать всю почту с домена яндекс yandex.ru OK # Разрешить конкретный ящик spammer@mail.ru OK # cat black_client # Блокировать всю почту с домена mail.ru mail.ru REJECT You domain are blacklisted! # Блокировать конкретный ящик spam@rambler.ru REJECT You e-mail are blacklisted! # cat white_helo # Могут попадаться вот такие адреса, которые не пройдут наши проверки ka-s-ex01.itk.local     OK exchange.elcom.local    OK # cat block_dsl /^dsl.*\..*\..*/i 553 AUTO_DSL spam /dsl.*\..*\..*/i 553 AUTO_DSL1 spam /[ax]dsl.*\..*\..*/i 553 AUTO_XDSL spam /client.*\..*\..*/i 553 AUTO_CLIENT spam /cable.*\..*\..*/i 553 AUTO_CABLE spam /pool.*\..*\..*/i 553 AUTO_POOL spam /dial.*\..*\..*/i 553 AUTO_DIAL spam /ppp.*\..*\..*/i 553 AUTO_PPP spam /dslam.*\..*\..*/i 553 AUTO_DSLAM spam /node.*\..*\..*/i 553 AUTO_NODE spam /([0-9]*-){3}[0-9]*(\..*){2,}/i 553 SPAM_ip-add-rr-ess_networks /([0-9]*\.){4}(.*\.){3,}.*/i 553 SPAM_ip-add-rr-ess_networks /.*\.pppool\..*/i 553 SPAM_POOL /[0-9]*-[0-9]*-[0-9]*-[0-9]*-tami\.tami\.pl/i 553 SPAM_POOL /pool-[0-9]*-[0-9]*-[0-9]*-[0-9]*\..*/i 553 SPAM_POOL /.*-[0-9]*-[0-9]*-[0-9]*-[0-9]*\.gtel.net.mx/i 553 SPAM_POOL /dhcp.*\..*\..*/i 553 SPAM_DHCP # cat mx_access 127.0.0.1 DUNNO 127.0.0.2 550 Domains not registered properly 0.0.0.0/8 REJECT Domain MX in broadcast network 10.0.0.0/8 REJECT Domain MX in RFC 1918 private network 127.0.0.0/8 REJECT Domain MX in loopback network 169.254.0.0/16 REJECT Domain MX in link local network 172.16.0.0/12 REJECT Domain MX in RFC 1918 private network 192.0.2.0/24 REJECT Domain MX in TEST-NET network 192.168.0.0/16 REJECT Domain MX in RFC 1918 private network 224.0.0.0/4 REJECT Domain MX in class D multicast network 240.0.0.0/5 REJECT Domain MX in class E reserved network 248.0.0.0/5 REJECT Domain MX in reserved network По сути файлы белых и черных списков не отличаются друг от друга. Можно использовать только один файл и в нем в каждой отдельной строке указывать либо запрет, либо разрешение. Я разделил просто для удобства восприятия и редактирования. Возможно вам будет удобнее с одним файлом. После редактирования файлов обязательно выполняем команду на перестроение базы данных. Я перестрою сразу все файлы: cd /etc/postfix/lists && postmap white_client_ip black_client_ip white_client black_client white_helo block_dsl mx_access Еще упомяну о таком популярном явлении в спамерских письмах, как подделка адреса отправителя. Причем не просто подделка на абы кого, а именно на ваше имя домена. Пользователь получает спам письмо и в почтовом клиенте видит, что оно отправлено с вашего домена. Только по заголовкам можно определить реального отправителя. Такой подход позволяет обходить некоторые антиспам системы, которые не фильтруют письма внутреннего домена. Бороться с подменой адреса отправителя в нашем случае очень просто. Для этого в black_client добавим следующую запись: zeroxzed.ru 554 Stop spam from my name Отправка с нашего домена осуществляется только с SASL авторизацией, а она во всех ограничениях стоит первой, поэтому письма реальных пользователей без проблем будут уходить. А всех тех, кто только притворяется нашим доменом, мы будет отфильтровывать этим правилом. Приведу в завершении описания методов борьбы со спамом простой пример. Добавим в black_client почтовый адрес и отправим с него письмо. # cat black_client zeroxzed@gmail.com REJECT Your e-mail was banned! # postmap black_client Отправляем сообщение и проверяем почтовый лог. # cat /var/log/maillog Mar 20 02:21:34 mail postfix/smtpd[10816]: connect from mail-yw0-f177.google.com[209.85.161.177] Mar 20 02:21:35 mail postfix/smtpd[10816]: Anonymous TLS connection established from mail-yw0-f177.google.com[209.85.161.177]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) Mar 20 02:21:35 mail postfix/smtpd[10816]: NOQUEUE: reject: RCPT from mail-yw0-f177.google.com[209.85.161.177]: 554 5.7.1 <zeroxzed@gmail.com>: Sender address rejected: Your e-mail was banned!; from=<zeroxzed@gmail.com> to=<root@zeroxzed.ru> proto=ESMTP helo= Mar 20 02:21:35 mail postfix/smtpd[10816]: disconnect from mail-yw0-f177.google.com[209.85.161.177] Вот и результат. На этом по борьбе со спамом все.   Заключение Проверить настроенный почтовый сервер можно с помощью онлайн сервиса https://www.mail-tester.com. Не факт, что получите максимальный бал, но все недочеты будут указаны. Критичное нужно исправить (например, если обратная зона неправильная), некритичное можно пропустить (если dkim, к примеру, не настраивали). Кажется все написал, что знал по поводу почтового сервера на linux в небольших и средних организациях. У некоторых может возникнуть вопрос, а зачем свой почтовый сервер? Почему бы не воспользоваться средствами корпоративной почты, которую представляют популярные почтовые сервисы бесплатно? Я планирую написать по этому поводу отдельную заметку (в итоге написал — выбор почтового сервера). У меня тоже есть определенный опыт на этот счет. И если некоторое время назад я считал, что свои почтовые серверы в небольших организациях уже не актуальны, то сейчас я так не думаю, поэтому и появилась эта статья. Буду рад замечаниям по делу и советам в комментариях.   Статья позаимствована с ресурса serveradmin.ru    

k010v

k010v

Удалённое подключение к ПК Windows с помощью xrdp на CentOS 7

Установка xrdp на CentOS 7 В этой статье мы рассмотрим установку xrdp на CentOS 7.
Для пущего интереса, давайте мы это рассмотрим с такой точки зрения: вы поставили CentOS в его минимальном варианте установки (minimal install), без компонентов рабочего стола и прочих утилит и вам понадобилось этот самый рабочий стол завести, и предоставить к нему доступ по rdp. Поэтому мы рассмотрим весь процесс самого начала. GNOME А сначала нам нужно установить компоненты рабочего стола — а именно GNOME. Сделать это можно следующим образом. Получим список групп доступного для установки программного обеспечения yum grouplist или так yum groups list Среди текста вывода команд мы увидим строку «GNOME Desktop»
Она то нам и нужна.
Запустить установку мы можем одной из следующих команд yum groupinstall "GNOME Desktop" или yum groups install "GNOME Desktop" Это что касается рабочей станции. Если же вы устанавливаете GNOME на систему, выполняющую серверные функции, то лучше воспользоваться одной из следующих команд yum groupinstall "Server with GUI" или yum groups install "Server with GUI" После этого нам нужно указать, чтобы по умолчанию система загружалась в графический режим. systemctl set-default graphical.target Для того, чтобы активировать его без перезагрузки systemctl start graphical.target xrdp Теперь перейдем к xrdp.
Сначала добавим нужный нам репозиторий. А понадобится нам EPEL — Extra Packages for Enterprise Linux. Найти ссылку на его текущую версию мы можем, заглянув по адресу http://download.fedoraproject.org/pub/epel. В моем случае команды будут выглядеть следующим образом wget http://download.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-6.noarch.rpm rpm -ivh epel-release-7-6.noarch.rpm Еще одним вариантом, и соответственно, с тем же результатом, будет следующая команда, которая представляет из себя объединение двух предыдущих строк rpm -ivh http://download.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-6.noarch.rpm Теперь, если мы введем команду yum repolist в списке вывода мы должны увидеть нечто подобное epel/x86_64   Extra Packages for Enterprise Linux 7 - x86_64   10,042 Далее нам нужно установить xrdp. yum install xrdp Если после этого мы попытаемся запустить xrdp, то это у нас скорее всего не получится, а в логах (команда journalctl -xe) мы увидим сообщения «Failed at step EXEC spawning /usr/sbin/xrdp-sesman: Permission denied» и «Failed at step EXEC spawning /usr/sbin/xrdp: Permission denied».
Чтобы все-таки их запустить, нам нужно изменить контекст безопасности SELinux для этих двух файлов. chcon -t bin_t /usr/sbin/xrdp chcon -t bin_t /usr/sbin/xrdp-sesman Запустить xrdp можно командой systemctl start xrdp а проверить, запустился ли он systemctl status xrdp Чтобы xrdp запускался каждый раз при старте системы systemctl enable xrdp Для подтверждения того, что он ожидает подключений на полагающемся ему порту 3389 можно ввести следующую команду netstat -antup | grep xrdp Firewall Если на вашей системе активен межсетевой экран, потребуется разрешить прохождение трафика на порт 3389. Сделать это можно следующими командами firewall-cmd --permanent --zone=public --add-port=3389/tcp firewall-cmd --reload Теперь можно попробовать подключиться к системе при помощи rdp-клиента, например, Microsoft Remote Desktop Connection.

k010v

k010v

Установка и настройка KVM на CentOS 7

Подготовка сервера Проверяем наличие поддержки со стороны процессора: cat /proc/cpuinfo | egrep "(vmx|svm)"   Если команда ничего не вернет, на сервере отсутствует поддержка виртуализации или она отключена в настройках БИОС. Сам KVM поставить на такой сервер можно, но при попытке ввести команду управления гипервизором мы получим ошибку «WARNING  KVM acceleration not available, using 'qemu'». В таком случае необходимо перезагрузить сервер, войти в БИОС, найти поддержку технологии виртуализации (Intel VT или AMD-V) и включить ее. Создадим каталоги, в которых будем хранить все, что касается виртуализации (предлагаемые по умолчанию не удобные): mkdir -p /kvm/{images,iso}   * каталог /kvm/images для виртуальных дисков; /kvm/iso — для iso-образов. Установка и запуск Установка выполняется из репозитория следующей командой: yum install qemu-kvm libvirt virt-install   * где qemu-kvm — сам гипервизор; libvirt — библиотека управления виртуализацией; virt-install — утилита для управления виртуальными машинами. Разрешаем автозапуск: systemctl enable libvirtd   Запускаем KVM: systemctl start libvirtd   Настройка сети В данной инструкции рассмотрим использование сетевого моста. Настраивая сетевой мост через удаленное подключение, внимательно проверяйте вводимые данные. В случае ошибки соединение будет прервано. Устанавливаем пакет для работы с bridge: yum install bridge-utils   Смотрим список сетевых интерфейсов и их настроек: ip a   В моем примере были следующие данные: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp4s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:16:76:04:26:c6 brd ff:ff:ff:ff:ff:ff inet 192.168.1.24/24 brd 192.168.1.255 scope global enp4s0f0 valid_lft forever preferred_lft forever inet6 fe80::216:76ff:fe04:26c6/64 scope link valid_lft forever preferred_lft forever 3: enp5s5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000 link/ether 00:16:76:04:26:c7 brd ff:ff:ff:ff:ff:ff 4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000 link/ether 52:54:00:cd:86:98 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 1000 link/ether 52:54:00:cd:86:98 brd ff:ff:ff:ff:ff:ff   * из этого для нас важны enp4s0f0 — реальный сетевой интерфейс с настроенным IP-адресом 192.168.1.24, через который идет подключение сервера к локальной сети (из него мы будем делать мост); 00:16:76:04:26:c6 — mac-адрес реального ethernet адаптера; virbr0 — виртуальный сетевой адаптер. Редактируем настройки реального адаптера: vi /etc/sysconfig/network-scripts/ifcfg-enp4s0f0   Приводим его к виду: ONBOOT=yes BRIDGE=br0 TYPE=Ethernet DEVICE=enp4s0f0 BOOTPROTO=none   Создаем интерфейс для сетевого моста: vi /etc/sysconfig/network-scripts/ifcfg-br0   DEVICE=br0 TYPE=Bridge ONBOOT=yes BOOTPROTO=static IPADDR=192.168.1.24 NETMASK=255.255.255.0 GATEWAY=192.168.1.1 DNS1=8.8.8.8 DNS2=77.88.8.8   Перезапускаем сетевую службу: systemctl restart network   Сетевые настройки должны измениться — в моем случае: 2: enp4s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 1000 link/ether 00:16:76:04:26:c6 brd ff:ff:ff:ff:ff:ff 3: enp5s5: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000 link/ether 00:16:76:04:26:c7 brd ff:ff:ff:ff:ff:ff 4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000 link/ether 52:54:00:cd:86:98 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever 5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 1000 link/ether 52:54:00:cd:86:98 brd ff:ff:ff:ff:ff:ff 6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000 link/ether 00:16:76:04:26:c6 brd ff:ff:ff:ff:ff:ff inet 192.168.1.24/24 brd 192.168.1.255 scope global br0 valid_lft forever preferred_lft forever inet6 fe80::216:76ff:fe04:26c6/64 scope link valid_lft forever preferred_lft forever   Настаиваем перенаправления сетевого трафика:   vi /etc/sysctl.conf net.ipv4.ip_forward=1   Применяем настройки: sysctl -p /etc/sysctl.conf   Перезапускаем libvirtd: systemctl restart libvirtd   Создание виртуальной машины Смотрим доступные варианты гостевых операционных систем: virt-install --os-variant list   Для создания первой виртуальной машины вводим следующую команду: virt-install -n FirstTest \ --noautoconsole \ --network=bridge:br0 \ --ram 1024 --arch=x86_64 \ --vcpus=1 --cpu host --check-cpu \ --disk path=/kvm/images/FirstTest-disk1.img,size=16 \ --cdrom /kvm/iso/CentOS-7-x86_64-Minimal-1611.iso \ --graphics vnc,listen=0.0.0.0,password=my_password \ --os-type linux --os-variant=rhel7 --boot cdrom,hd,menu=on   * где: FirstTest — имя создаваемой машины; noautoconsole — после создания не подключается автоматически к консоли виртуальной машины; network — тип сети (в нашем примере сетевой мост); ram — объем оперативной памяти, который будет выделен; vcpus — количество виртуальных процессоров; disk — виртуальный диск: path — путь до диска; size — его объем; cdrom — виртуальный привод с образом системы; graphics — параметры подключения к виртуальной машины с помощью графической консоли (в данном примере используем vnc); listen — на какой адресе принимает запросы vnc (в нашем примере на всех); password — пароль для подключения при помощи vnc; os-variant — гостевая операционная система (весь список мы получали командой virt-install --os-variant list, в данном примере устанавливаем Reв Hat 7 / CentOS 7). Разрешаем автостарт для созданной ВМ: virsh autostart FirstTest   Подключение к виртуальной машине Для дальнейшей установки операционной системы скачиваем VNC-клиент на компьютер администратора, например, TightVNC и устанавливаем его. На сервере смотрим, на каком порту слушает VNC созданной машины: virsh vncdisplay FirstTest в моем случае было: :0 Это значит, что нужно к 5900 прибавить 0. Если результат команды будет :1 — 5900 + 1 = 5901 и так далее. Открываем порт на брандмауэре: firewall-cmd --permanent --add-port=5900-5905/tcp   * в данном примере добавлено сразу 6 tcp-портов от 5900 до 5905. Запускаем установленный TightVNC Viewer, в открывшемся окне вводим IP-адрес сервера KVM и порт, на котором слушает наша ВМ (в данном примере, 5900): Нажимаем Connect. Программа запросит пароль — вводим тот, что указали при создании ВМ, (в данном примере, my_password). Мы подключимся к виртуальной машине, как будто, к ней подключен монитор или удаленная консоль KVM. Базовые команды управления ВМ Получить список созданных машин: virsh list --all   Включить виртуальную машину: virsh start FirstTest   * где FirstTest — имя созданной машины. Выключить: virsh shutdown FirstTest   Управление через веб-интерфейс Существуют различные веб-интерфейсы для управления гипервизором KVM. В данной инструкции мы рассмотрим oVirt. Для его установки вводим команды: yum install http://resources.ovirt.org/pub/yum-repo/ovirt-release41.rpm   yum install ovirt-engine   После разворачиваем и настраиваем портал: engine-setup   * после запуска команды система задаст ряд вопросов, на все, кроме ввода пароля, можно ответить по умолчанию (просто нажать Enter). После окончания установки в браузере вводим https://kvm/ovirt-engine/sso/, где kvm — имя сервера. В открывшемся окне вводим логин admin и пароль, который создали при выполнении команды engine-setup. После успешного входа можно управлять виртуальными машинами через веб-интерфейс.

k010v

k010v

Настройка web сервера nginx, php-fpm, php7 на CentOS 7

Установка nginx на CentOS 7 Для установки самой свежей стабильной версии nginx на centos подключим родной репозиторий. # rpm -Uvh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm Если по какой-то причине ссылка изменится или устареет, то можно создать файл с конфигурацией репозитория nginx вручную. Для этого рисуем такой конфиг /etc/yum.repos.d/nginx.repo. [nginx] name=nginx repo baseurl=http://nginx.org/packages/centos/7/$basearch/ gpgcheck=0 enabled=1 Устанавливаем nginx на сервер. # yum install nginx Запускаем nginx и добавляем в автозагрузку. # systemctl start nginx # systemctl enable nginx Проверяем, запустился ли web сервер. Для этого идем по ссылке http://95.169.190.64/. Вы должны увидеть стандартную страницу заглушку. Если страница не открывается, то скорее всего вы не настроили firewall. Свою статью по его настройке я приводил в самом начале.   Настройка nginx Расскажу, как настроить nginx для работы разных виртуальных хостов. Создадим виртуальный хост и подготовим директории для размещения исходников сайта и панели управления phpmyadmin. # mkdir -p /web/sites/hl.zeroxzed.ru/www && mkdir /web/sites/hl.zeroxzed.ru/log # mkdir -p /web/sites/p1m2a.zeroxzed.ru/www && mkdir /web/sites/p1m2a.zeroxzed.ru/log Создадим конфиги nginx для этих виртуальных хостов. Я сразу буду делать их с учетом https, который мы настроим позже. Так что после создания не надо перезапускать веб сервер и проверять работу — будут ошибки. Виртуальный хост сайта показан на примере wordpress. Конфигурация собрана на основе рекомендаций из официальной документации конкретно для веб сервера nginx. # mcedit /etc/nginx/conf.d/hl.zeroxzed.ru.conf server { listen 80; server_name hl.zeroxzed.ru; root /web/sites/hl.zeroxzed.ru/www/; index index.php index.html index.htm; access_log /web/sites/hl.zeroxzed.ru/log/access.log main; error_log /web/sites/hl.zeroxzed.ru/log/error.log; location / { return 301 https://hl.zeroxzed.ru$request_uri; } location ~* ^.+.(js|css|png|jpg|jpeg|gif|ico|woff)$ { return 301 https://hl.zeroxzed.ru$request_uri; } location ~ \.php$ { return 301 https://hl.zeroxzed.ru$request_uri; } location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { rewrite ^ /robots.txt break; allow all; log_not_found off; access_log off; } location ~ /\.ht { deny all; } } server { listen 80; server_name www.hl.zeroxzed.ru; rewrite ^ https://hl.zeroxzed.ru$request_uri? permanent; } server { listen 443 ssl http2; server_name hl.zeroxzed.ru; root /web/sites/hl.zeroxzed.ru/www/; index index.php index.html index.htm; access_log /web/sites/hl.zeroxzed.ru/log/ssl-access.log main; error_log /web/sites/hl.zeroxzed.ru/log/ssl-error.log; keepalive_timeout 60; ssl_certificate /etc/letsencrypt/live/hl.zeroxzed.ru/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/hl.zeroxzed.ru/privkey.pem; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_dhparam /etc/ssl/certs/dhparam.pem; add_header Strict-Transport-Security 'max-age=604800'; location / { try_files $uri $uri/ /index.php?$args; } location ~* ^.+.(js|css|png|jpg|jpeg|gif|ico|woff)$ { access_log off; expires max; } location ~ \.php$ { try_files $uri =404; fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; #fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param DOCUMENT_ROOT /web/sites/hl.zeroxzed.ru/www/; fastcgi_param SCRIPT_FILENAME /web/sites/hl.zeroxzed.ru/www$fastcgi_script_name; fastcgi_param PATH_TRANSLATED /web/sites/hl.zeroxzed.ru/www$fastcgi_script_name; include fastcgi_params; fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param HTTPS on; fastcgi_intercept_errors on; fastcgi_ignore_client_abort off; fastcgi_connect_timeout 60; fastcgi_send_timeout 180; fastcgi_read_timeout 180; fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; } location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off; } location ~ /\.ht { deny all; } } server { listen 443 ssl http2; server_name www.hl.zeroxzed.ru; rewrite ^ https://hl.zeroxzed.ru$request_uri? permanent; } В данной конфигурации настроены все необходимые редиректы, при этом отключен редирект файла robots.txt. Он отдельно отдается по http и https. Это требуется для яндекса во время перехода с http на https и склейки зеркал. Для phpmyadmin рисуем конфиг попроще. # mcedit /etc/nginx/conf.d/p1m2a.zeroxzed.ru.conf server { listen 443 ssl http2; server_name p1m2a.zeroxzed.ru; root /web/sites/p1m2a.zeroxzed.ru/www/; index index.php index.html index.htm; access_log /web/sites/p1m2a.zeroxzed.ru/log/ssl-access.log main; error_log /web/sites/p1m2a.zeroxzed.ru/log/ssl-error.log; keepalive_timeout 60; ssl_certificate /etc/letsencrypt/live/p1m2a.zeroxzed.ru/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/p1m2a.zeroxzed.ru/privkey.pem; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_dhparam /etc/ssl/certs/dhparam.pem; add_header Strict-Transport-Security 'max-age=604800'; location ~ \.php$ { fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; #fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param DOCUMENT_ROOT /web/sites/p1m2a.zeroxzed.ru/www/; fastcgi_param SCRIPT_FILENAME /web/sites/p1m2a.zeroxzed.ru/www$fastcgi_script_name; fastcgi_param PATH_TRANSLATED /web/sites/p1m2a.zeroxzed.ru/www$fastcgi_script_name; include fastcgi_params; fastcgi_param QUERY_STRING $query_string; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_intercept_errors on; fastcgi_ignore_client_abort off; fastcgi_connect_timeout 60; fastcgi_send_timeout 180; fastcgi_read_timeout 180; fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; fastcgi_busy_buffers_size 256k; fastcgi_temp_file_write_size 256k; } } server { listen 443 ssl http2; server_name www.p1m2a.zeroxzed.ru; rewrite ^ https://p1m2a.zeroxzed.ru$request_uri? permanent; } server { listen 80; server_name p1m2a.zeroxzed.ru; root /web/sites/p1m2a.zeroxzed.ru/www/; index index.php index.html index.htm; access_log /web/sites/p1m2a.zeroxzed.ru/log/access.log main; error_log /web/sites/p1m2a.zeroxzed.ru/log/error.log; location / { return 301 https://p1m2a.zeroxzed.ru$request_uri; try_files $uri $uri/ /index.php?$args; } } Сохраняем конфиги виртуальных хостов nginx и продолжаем настройку производительного веб сервера.   Установка php-fpm 7.1Установка и настройка 7-й версии php на centos не очень простая задача. Ранее я уже рассказывал как обновить php до 7-й версии, но в итоге откатился назад. Прошло прилично времени и откатываться уже не будем, так как большинство проблем исправлены. Основные трудности возникают с тем, что в официальных репозиториях очень старые версии php, но при этом они часто есть в зависимостях к другим пакетам. В итоге, обновившись неаккуратно до 7.1 можно получить проблемы с установкой и обновлением, к примеру, phpmyadmin или zabbix. В комментариях к моим статьям я иногда вижу эти ошибки и по тексту ошибок сразу понимаю, что проблема с зависимостями. Вторая проблема в том, что надо определить, какой репозиторий использовать для установки php7. Их существует очень много. К примеру, мой хороший знакомый в своей статье по настройке web сервера использует репозиторий Webtatic. В принципе, чтобы просто поставить php 7-й версии это нормальный вариант. Но если вы после этого захотите установить phpmyadmin через yum уже ничего не получится. Будет ошибка зависимостей, которые нужно будет как-то руками разбирать. То же самое будет и с другими пакетами. К примеру, zabbix без плясок с бубнами скорее всего не встанет. В сторонних репозиториях есть еще одна проблема. Иногда они закрываются. И это станет для вас большой проблемой на боевом сервере. Так что к выбору репозитория нужно подходить очень аккуратно и внимательно. Я до сих пор иногда встречаю настроенные сервера centos 5 с очень популярным в прошлом репозиторием centos.alt.ru, который закрылся. Сейчас это уже не так актуально, так как таких серверов осталось мало, но некоторое время назад мне это доставляло серьезные неудобства. Для установки свежей версии php я буду использовать репозиторий Remi. Это известный и популярный репозиторий, который ведет сотрудник RedHat. И хотя надежность репозитория, который ведет один человек не так высока, но ничего лучше и надежнее remi лично я не нашел для своих целей. Если вы можете что-то посоветовать на этот счет — комментарии в вашем распоряжении. Буду благодарен за дельный совет. Подключаем remi репозиторий для centos 7. # rpm -Uhv http://rpms.remirepo.net/enterprise/remi-release-7.rpm Я получил ошибку: Retrieving http://rpms.remirepo.net/enterprise/remi-release-7.rpm warning: /var/tmp/rpm-tmp.nwcDV1: Header V4 DSA/SHA1 Signature, key ID 00f97f56: NOKEY error: Failed dependencies: epel-release = 7 is needed by remi-release-7.3-2.el7.remi.noarch Тут все понятно, нужен репозиторий epel. Те, кто готовили сервер по моей статье по базовой настройке сервера его уже подключили, а те кто не делали этого, подключают сейчас: # yum install epel-release После этого повторяем установку remi, все должно пройти нормально. Проверим список подключенных репозиториев. # yum repolist У меня такая картинка получилась. Активируем репу remi-php71, для этого выполняем команду: # yum-config-manager --enable remi-php71 Если получаете ошибку: bash: yum-config-manager: command not found то установите пакет yum-utils. # yum install yum-utils Теперь устанавливаем php7.1. # yum install php71 Установим php-fpm и наиболее популярные модули, которые могут пригодится в процессе эксплуатации веб сервера. # yum install php-fpm php-cli php-mysql php-gd php-ldap php-odbc php-pdo php-pecl-memcache php-pear php-xml php-xmlrpc php-mbstring php-snmp php-soap Запускаем php-fpm и добавляем в автозагрузку. # systemctl start php-fpm # systemctl enable php-fpm Проверяем, запустился ли он. # netstat -tulpn | grep php-fpm tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 9084/php-fpm: maste Все в порядке, повис на порту 9000. Запустим его через unix сокет. Для этого открываем конфиг /etc/php-fpm.d/www.conf и комментируем строку: ;listen = 127.0.0.1:9000 Вместо нее добавляем несколько других: listen = /var/run/php-fpm/php-fpm.sock listen.mode = 0660 listen.owner = nginx listen.group = nginx Заодно измените пользователя, от которого будет работать php-fpm. Вместо apache укажите nginx. user = nginx group = nginx Перезапускаем php-fpm. # systemctl restart php-fpm Проверяем, стартовал ли указанный сокет. # ll /var/run/php-fpm/php-fpm.sock srw-rw----. 1 nginx nginx 0 Oct 26 18:08 /var/run/php-fpm/php-fpm.sock На текущий момент с настройкой php-fpm закончили, двигаемся дальше. Для того, чтобы проверить работу нашего веб сервера, нужно установить ssl сертификаты. Без них nginx с текущим конфигом не запустится. Исправляем это.   Настройка бесплатного ssl сертификата Lets Encrypt Устанавливаем пакет certbot для получения бесплатного ssl сертификата от let’s encrypt. # yum install certbot Запускаем программу для генерации сертификата. # certbot certonly Вам в консоли будут заданы несколько вопросов. Вот мои ответы, необходимые для успешного получения сертификата. Первый раз мы получим сертификаты, используя временный веб сервер самого certbot, так как наш еще не работает. Далее обновлять сертификаты будем в автоматическом режиме с помощью временной директории в корне виртуального хоста. # certbot certonly Saving debug log to /var/log/letsencrypt/letsencrypt.log How would you like to authenticate with the ACME CA? ------------------------------------------------------------------------------- 1: Spin up a temporary webserver (standalone) 2: Place files in webroot directory (webroot) ------------------------------------------------------------------------------- Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1 Plugins selected: Authenticator standalone, Installer None Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): zeroxzed@gmail.com Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org ------------------------------------------------------------------------------- Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf. You must agree in order to register with the ACME server at https://acme-v01.api.letsencrypt.org/directory ------------------------------------------------------------------------------- (A)gree/(C)ancel: A ------------------------------------------------------------------------------- Would you be willing to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about EFF and our work to encrypt the web, protect its users and defend digital rights. ------------------------------------------------------------------------------- (Y)es/(N)o: N Please enter in your domain name(s) (comma and/or space separated) (Enter 'c' to cancel): hl.zeroxzed.ru Obtaining a new certificate Performing the following challenges: tls-sni-01 challenge for hl.zeroxzed.ru Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/hl.zeroxzed.ru/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/hl.zeroxzed.ru/privkey.pem Your cert will expire on 2018-01-24. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le Для успешного создания бесплатных ssl сертификатов от lets encrypt у вас должны быть корректно настроены DNS записи для доменов, на которые выпускаются сертификаты. Итак, сертификаты получили. Теперь можно проверить конфигурацию nginx и запустить его. Проверяем конфиг: # nginx -t Если получаете ошибку: nginx: [emerg] BIO_new_file("/etc/ssl/certs/dhparam.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/etc/ssl/certs/dhparam.pem','r') error:2006D080:BIO routines:BIO_new_file:no such file) nginx: configuration file /etc/nginx/nginx.conf test failed То генерируете необходимый ключ: # openssl dhparam -out /etc/ssl/certs/dhparam.pem 4096 Генерация будет длиться долго (у меня 20 минут длилось на двух ядрах). Снова проверяйте конфигурацию. Если ошибок нет, то перезапустим nginx. # systemctl restart nginx Настройка nginx на этом завершена. Он должен корректно запуститься и работать в рабочем режиме. Теперь сделаем так, чтобы сертификаты автоматически обновлялись перед истечением срока действия. Для этого необходимо изменить конфигурации доменов. Они располагаются в директории /etc/letsencrypt/renewal. Так как мы генерировали сертификаты с помощью временного веб сервера, наш текущий конфиг hl.zeroxzed.ru.conf выглядит вот так: # renew_before_expiry = 30 days version = 0.18.1 archive_dir = /etc/letsencrypt/archive/hl.zeroxzed.ru cert = /etc/letsencrypt/live/hl.zeroxzed.ru/cert.pem privkey = /etc/letsencrypt/live/hl.zeroxzed.ru/privkey.pem chain = /etc/letsencrypt/live/hl.zeroxzed.ru/chain.pem fullchain = /etc/letsencrypt/live/hl.zeroxzed.ru/fullchain.pem # Options used in the renewal process [renewalparams] authenticator = standalone installer = None account = e9c86e6aa57b45f9614bc7c0015927a5 Приводим его к следующему виду: # renew_before_expiry = 30 days version = 0.18.1 archive_dir = /etc/letsencrypt/archive/hl.zeroxzed.ru cert = /etc/letsencrypt/live/hl.zeroxzed.ru/cert.pem privkey = /etc/letsencrypt/live/hl.zeroxzed.ru/privkey.pem chain = /etc/letsencrypt/live/hl.zeroxzed.ru/chain.pem fullchain = /etc/letsencrypt/live/hl.zeroxzed.ru/fullchain.pem # Options used in the renewal process [renewalparams] authenticator = webroot installer = None account = e9c86e6aa57b45f9614bc7c0015927a5 post_hook = nginx -s reload [[webroot_map]] www.hl.zeroxzed.ru = /web/sites/hl.zeroxzed.ru/www hl.zeroxzed.ru = /web/sites/hl.zeroxzed.ru/www По аналогии делаете с остальными виртуальными хостами, для которых используете бесплатные сертификаты let’s encrypt. Осталось дело за малым — настроить автоматический выпуск новых ssl сертификатов, взамен просроченным. Для этого добавляем в /etc/crontab следующую строку: # Cert Renewal 30 2 * * * root /usr/bin/certbot renew --post-hook "nginx -s reload" >> /var/log/le-renew.log Все, с сертификатами закончили. Двигаемся дальше в настройке web сервера.   Установка mariadb 10 на CentOS 7 Дошла очередь до установки сервера баз данных для web сервера на CentOS 7 — MariaDB. По аналогии с другим софтом, в официальном репозитории очень старая версия mariadb — 5.5. Я же буду устанавливать последнюю стабильную версию на момент написания статьи — 10.2. Для того, чтобы подключить репозиторий MariaDB, можно воспользоваться специальной страницей на официальном сайте, где можно задать параметры системы и получить конфиг репозитория. В моем случае конфиг получился следующий. # cat /etc/yum.repos.d/mariadb.repo [mariadb] name = MariaDB baseurl = http://yum.mariadb.org/10.2/centos7-amd64 gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck=1 Устанавливаем последнюю версию mariadb на centos. # yum install MariaDB-server MariaDB-client Убедитесь, что база данных ставится из нужного репозитория. Запускаем mariadb и добавляем в автозагрузку. # systemctl start mariadb # systemctl enable mariadb Запускаем скрипт начальной конфигурации mysql и задаем пароль для root. Все остальное можно оставить по-умолчанию. # /usr/bin/mysql_secure_installation Сервер баз данных mysql для нашего web сервера готов. Продолжаем настройку. Установим панель управления mysql — phpmyadmin.   Установка phpmyadmin Кратко расскажу про установку phpmyadmin в контексте данной статьи. Подробно не буду останавливаться на этом, так как статья и так получается очень объемная, а я еще не все рассказал. Вопрос настройки phpmyadmin я очень подробно рассмотрел отдельно. За подробностями можно сходить туда. Устанавливаем phpmyadmin через yum. Если ранее все сделали правильно, то конфликтов с зависимостями быть не должно. # yum install phpmyadmin Phpmyadmin по-умолчанию сконфигурирована для работы с httpd. Для того, чтобы в будущем автоматически обновлять ее, просто сделаем символьную ссылку из директории с исходниками панели в наш виртуальный хост. # rm -df /web/sites/p1m2a.zeroxzed.ru/www # ln -s /usr/share/phpMyAdmin /web/sites/p1m2a.zeroxzed.ru/www Выставляем правильные права на директорию с php сессиями. Без этого работать phpmyadmin не будет. # chown nginx:nginx /var/lib/php/session/ Можно заходить и проверять работу phpmyadmin. Ее установка закончена.   Доступ к сайту по sftp Настройка сервера почти завершена. Если вы администратор и единственный пользователь, то больше можно ничего не делать. Вы и так сможете загрузить на сервер все что нужно тем или иным способом. Если же вы будете передавать управление сайтами другим людям, им нужен доступ к директории с исходниками сайта. Раньше для этих целей повсеместно использовали ftp. Если вы хотите так сделать, у меня есть статья по настройке ftp сервера vsftpd. Я же предлагаю использовать sftp по нескольким причинам: Он безопаснее. Его быстрее настроить. Не надо отдельно настраивать firewall. Статью по настройке sftp доступа я уже тоже писал, все подробности там. Здесь без комментариев выполним необходимые действия. Создаем пользователя для подключения к сайту. Я обычно использую имя пользователя пересекающееся с названием сайта. Так удобнее управлять. # useradd -s /sbin/nologin hl.zeroxzed.ru # passwd hl.zeroxzed.ru Открываем конфиг ssh по пути /etc/ssh/sshd_config и комментируем там одну строку, добавляя далее несколько новых. #Subsystem sftp /usr/libexec/openssh/sftp-server Subsystem sftp internal-sftp Match User hl.zeroxzed.ru ChrootDirectory /web/sites/hl.zeroxzed.ru ForceCommand internal-sftp Перезапускаем службу sshd. # systemctl restart sshd Этого уже достаточно, чтобы вы могли подключиться к сайту, к примеру, с помощью программы winscp. Если что-то пойдет не так и будут какие-то ошибки, то смотреть подробности нужно в логе /var/log/secure. Но тут возникает много нюансов с правами к файлам и директориям. Дальше я расскажу, как их аккуратно и грамотно разрулить, чтобы у нас не было проблем с дальнейшей работой сайтов от разных пользователей.     Работа с сайтами разных пользователей на одном веб сервере Самый простой способ решить проблему с правами доступа, это сделать владельцем папки с сайтом пользователя, который подключается по sftp. Тогда он сможет нормально работать с файлами, загружать и удалять их. Если доступ в качестве группы установить для nginx, то в целом все будет работать. Для каких-то сайтов такой вариант может оказаться подходящим. То есть сделать надо вот так: # chown -R hl.zeroxzed.ru:nginx /web/sites/hl.zeroxzed.ru/ # chmod -R 0775 /web/sites/hl.zeroxzed.ru/ Но при такой схеме будут проблемы с движками сайтов, которые автоматом что-то к себе загружают. Какие-то галереи не будут работать. К примеру, wordpress не сможет автоматически загружать плагины, будет просить доступ к ftp. В общем, могут возникнуть некоторые неудобства. Сейчас мы их исправим. Еще обращаю внимание на один нюанс. Chroot доступ для sftp не будет работать, если владельцем директории, куда чрутимся, будет не root. Только что мы сделали владельцем каталога с сайтом и всего, что внутри него пользователя hl.zeroxzed.ru. Теперь надо вернуть обратно владельцем исходного каталога рута, а все, что внутри него остается как мы и хотим — будет принадлежать hl.zeroxzed.ru. # chown root:root /web/sites/hl.zeroxzed.ru/ # chmod 0755 /web/sites/hl.zeroxzed.ru/ А теперь сделаем все красиво. Назначаем владельцем содержимого нашего сайта только отдельного пользователя. # chown -R hl.zeroxzed.ru:hl.zeroxzed.ru /web/sites/hl.zeroxzed.ru/ Возвращаем обратно рута владельцем корня chroot. # chown root:root /web/sites/hl.zeroxzed.ru/ # chmod 0755 /web/sites/hl.zeroxzed.ru/ Обращаю внимание, что сначала мы рекурсивно назначаем права на все содержимое директорий, а потом возвращаем владельца root только на корень. Добавляем пользователя nginx в группу hl.zeroxzed.ru. # usermod -aG hl.zeroxzed.ru nginx Создаем отдельный pool для php-fpm, который будет обслуживать сайт hl.zeroxzed.ru и будет запускаться от этого пользователя. Для этого копируем существующий конфиг /etc/php-fpm.d/www.conf и изменяем в нем несколько строк. # cd /etc/php-fpm.d && cp www.conf hl.zeroxzed.ru.conf [hl.zeroxzed.ru] user = hl.zeroxzed.ru group = hl.zeroxzed.ru listen = /var/run/php-fpm/hl.zeroxzed.ru.sock listen.owner = hl.zeroxzed.ru listen.group = hl.zeroxzed.ru Мы поменяли название пула, запустили его от отдельного пользователя и назначили ему отдельный сокет. Теперь идем в настройки этого виртуального хоста в nginx — /etc/nginx/conf.d/hl.zeroxzed.ru.conf и везде меняем старое значение сокета fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; на новое fastcgi_pass unix:/var/run/php-fpm/hl.zeroxzed.ru.sock; Перезапускаем nginx и php-fpm и проверяем работу сайта от отдельного пользователя. # systemctl restart nginx # systemctl restart php-fpm Я рекомендую подключиться по sftp, закинуть исходники wordpress, установить его и добавить новую тему, чтобы проверить, что все корректно работает.  По аналогии проделанные выше действия повторяются для всех остальных сайтов.   Ротация логов виртуальных хостов Последний штрих в настройке web сервера — ротация логов виртуальных хостов. Если этого не сделать, то через какое-то, обычно продолжительное, время возникает проблема в связи с огромным размером лог файла. У нас уже будет файл конфигурации logrotate для nginx, который был создан во время установки — /etc/logrotate.d/nginx. Приведем его к следующему виду: /var/log/nginx/*log /web/sites/p1m2a.zeroxzed.ru/log/*log { create 0644 nginx nginx size=1M rotate 10 missingok notifempty compress sharedscripts postrotate /bin/kill -USR1 `cat /run/nginx.pid 2>/dev/null` 2>/dev/null || true endscript } /web/sites/hl.zeroxzed.ru/log/*log { create 0644 hl.zeroxzed.ru hl.zeroxzed.ru size=1M rotate 10 missingok notifempty compress sharedscripts postrotate /bin/kill -USR1 `cat /run/nginx.pid 2>/dev/null` 2>/dev/null || true endscript } Я предлагаю ротировать файлы логов по достижению ими размера в 1Мб, сжимать после ротации и хранить 10 архивов с логом. Для виртуальных хостов, работающих от отдельного пользователя, новые логи создаются сразу с соответствующими правами, чтобы у пользователя был доступ к ним. Для всех остальных хостов можно использовать самое первое правило, просто добавляя туда новые пути для логов. Это просто пример конфигурации. Все параметры вы можете поменять по своему усмотрению. Примеров конфигурации logrotate в интернете много. На этом все. Я рассмотрел все основные моменты, которые необходимы для установки и настройки производительного web сервера на основе nginx и php-fpm последних версий. При этом рассказал о некоторых вещах, которые повышают удобство и гибкость эксплуатации сервера.   Статья позаимствована с ресурса serveradmin.ru    

k010v

k010v



  • Блоги

    • CentOS

      • 13
        записей
      • 1257
        комментариев
      • 17369
        просмотров
    • web-администрирование

      • 3
        записи
      • 0
        комментариев
      • 257
        просмотров
    • Mikrotik

      • 11
        записей
      • 225
        комментариев
      • 21973
        просмотра
    • LAN

      • 5
        записей
      • 0
        комментариев
      • 1171
        просмотр
    • Windows

      • 17
        записей
      • 12
        комментариев
      • 962
        просмотра
    • Asterisk

      • 2
        записи
      • 0
        комментариев
      • 91
        просмотр
    • Разное

      • 1
        запись
      • 0
        комментариев
      • 332
        просмотра
    • 1C

      • 1
        запись
      • 0
        комментариев
      • 240
        просмотров
    • Linux

      • 2
        записи
      • 0
        комментариев
      • 264
        просмотра
    • iOS

      • 1
        запись
      • 0
        комментариев
      • 274
        просмотра
×