CentOS 7 и 8 настройка сервера после установки

Сегодня я познакомлю вас со своим видением начальной конфигурации универсального сервера на популярной ОС. Я расскажу о том, как сделать базовую настройку сервера centos сразу после установки для использования его в любом качестве на ваше усмотрение. Приведенные практические советы повышают безопасность и удобство работы с сервером. Статья будет актуальна для двух последних релизов Centos — 7 и 8.

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти вступительный тест.

Цели статьи

• Перечислить начальные настройки centos, которые я выполняю на свежеустановленном сервере.
• Показать примеры конфигураций, которые я использую в типовой настройке.
• Дать советы по настройке centos на основе своего опыта работы с системой.
• Привести список типовых программ и утилит, которые помогают администрировать сервер.

Данная статья является частью единого цикла статьей про сервер Centos.

Введение

Для настройки практически любого сервера требуется выполнить ряд стандартных шагов, которые мало чем отличаются в различных ситуациях. Какой бы функционал вы не готовили, вам придется настроить правильное время и включить его автообновление. Без установки сетевых настроек я вообще не представляю работу современного сервера. В голову не приходит ни один пример. Один и тот же набор настроек практически на автомате выполняется после установки. Своими наработками по этой теме я хочу поделиться с вами — то, что я в первую очередь настраиваю на новоиспеченном сервере centos после установки.

После выхода нового релиза Centos 8, стало тяжело в единой статье описывать начальную настройку обоих серверов, но мне не захотелось разделять статью, так как на нее идет много входящих ссылок из разных мест. Удобнее поддерживать общий материал по обоим релизам, чем я и займусь. Заодно наглядно будут видны отличия двух версий, которые пару лет после выхода centos 8 будут актуальны обе и использовать придется и ту, и другую версию, в зависимости от ситуации.

В Centos 7 используется пакетный менеджер yum, а в Centos 8 — dnf. При этом оставили символьную ссылку с yum на dnf, так что можно писать как первое название, так и второе. Для единообразия я везде буду использовать yum, а вас предупреждаю, просто чтобы вы понимали, почему я делаю именно так. Реально в CentOS 8 используется dnf, это другой, более современный пакетный менеджер, которые позволяет работать с разными версиями одного и того же софта. Для этого используются отдельные репозитории, которые появились для centos 8.

Начальная настройка CentOS

Лично я любую настройку системы, будь то centos или другая, после установки начинаю с того, что полностью обновляю систему. Если установочный образ был свежий, либо установка велась по сети, то скорее всего обновлений никаких не будет. Чаще всего они есть, так как установочные образы не всегда регулярно обновляются.

# yum update

Для удобства администрирования, я всегда устанавливаю Midnight Commander, или просто mc:

# yum install mc

Дальше нам пригодятся сетевые утилиты. В зависимости от набора начальных пакетов, которые вы выбираете при установке системы, у вас будет тот или иной набор сетевых утилит. Вот список тех, к которым привык лично я — ifconfig, netstat, nslookup и некоторые другие. Если она вам нужны, так же как и мне, то предлагаю их установить отдельно, если они еще не стоят. Если вам они особо не нужны и вы ими не пользуетесь, то можете пропустить их установку. Проверим, что у нас имеется в системе на текущий момент

Если увидите ответ:

-bash: ifconfig: command not found

Значит утилита не установлена. Вместо ifconfig в CentOS теперь утилита ip. Это относится не только к центос. Такая картина почти во всех популярных современных дистрибутивах Linux. Я с давних времен привык к ifconfig, хотя последнее время практически не пользуюсь. Мне всегда нравилось, что в различных дистрибутивах линукс все примерно одинаковое. С помощью ifconfig можно настроить сеть не только в linux, но и в freebsd. Это удобно. А когда в каждом дистрибутиве свой инструмент это не удобно. Хотя сейчас это уже не очень актуально, так как с Freebsd больше не работаю, а утилита ip есть во всех дистрибутивах linux. Тем не менее, если вам нужен ifconfig, то можете установить пакет net-tools, в который она входит:

# yum install net-tools

Чтобы у нас работали команды nslookup или, к примеру, host необходимо установить пакет bind-utils. Если этого не сделать, то на команду:

-bash: nslookup: command not found

# yum install bind-utils

Отключить SELinux

Отключаем SELinux. Его использование и настройка отдельный разговор. Сейчас я не буду этим заниматься. Так что отключаем:

# mcedit /etc/sysconfig/selinux

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

А если хотите без перезагрузки применить отключение SELinux, то выполните команду:

Постоянно получаю очень много критики на тему отключения SELinux. Я знаю, как он работает, умею его настраивать. Это реально не очень сложно и освоить не трудно. Это мой осознанный выбор, хотя иногда я его настраиваю. Мой формат работы с системой таков, что SELinux мне чаще всего не нужен, поэтому я не трачу на него время и в базовой настройке centos отключаю. Безопасность системы — комплексная работа, особенно в современном мире web разработки, где правят бал микросервисы и контейнеры. SELinux нишевый инструмент, которые нужен не всегда и не везде. Поэтому в данном статье ему не место. Кому нужно, будет отдельно включать SELinux и настраивать.

Указываем сетевые параметры

Продолжаем базовую настройку centos после установки. Теперь произведем настройку сети, если по какой-то причине не сделали это во время установки, либо если вам надо их изменить. В общем случае, сеть в Centos настраивается с помощью NetworkManager и его консольной утилиты nmtui. Она идет в базовой устновке системы. Там простой и понятный графический интерфейс, так что рассказывать нечего. Я больше привык настраивать сеть через конфигурационные файлы network-scripts. В centos 7-й версии они есть из коробки, в 8-й версии их убрали. Чтобы воспользоваться ими для настройки сети, надо отдельно установить пакет network-scripts.

# yum install network-scripts

Теперь можно выполнить настройку сети. Для этого открываем файл /etc/sysconfig/network-scripts/ifcfg-eth0

# mcedit /etc/sysconfig/network-scripts/ifcfg-eth0

Если вы получаете сетевые настройки по dhcp, то минимальный набор настроек в конфигурационном файле будет такой.

Для настройки статического ip адреса настройки будут следующие.

В поле IPADDR вводим свой адрес, в PREFIX маску сети, в GATEWAY шлюз, DNS адрес днс сервера. Сохраняем файл и перезапускаем сеть для применения настроек:

# systemctl restart network

Настраиваем firewall

Очень подробно вопрос настройки iptables в CentOS я рассмотрел отдельно. Сейчас мы быстро и просто настроим firewall. В CentOS 7 в качестве базового фаервола выступает iptables. По-умолчанию он запущен. Чтобы посмотреть текущие правила, нужно ввести команду:

# iptables -L -v -n

В Centos 8 вместо iptables используется nftables. Сразу скажу, что я с ним еще не разбирался и не знаю, буду ли. Реально, меня полностью устраивают iptables. Я ни разу не сталкивался с тем, что что-то не получалось или было невозможно настроить с их помощью. У меня написана куча конфигов к ним, настроены роли ansible с шаблонами правил. Я не понимаю, зачем мне все это переводить в nftables и какую выгоду я с этого получу. Поэтому пока я продолжаю использовать iptables.

Начиная с 7-й версии CentOS для настройки firewall разработан новый инструмент под названием firewalld и все управление производится через него. Он же используется и в Centos 8, только управляет при этом nftables, но сами правила для firewalld одинаковые в обоих версиях. Я не понял зачем в принципе придумали firewalld и не могу сказать, удобнее с ним стало или нет. По мне, так удобнее использовать одни и те же наработки по iptables. Мигрируя от сервера к серверу и от дистрибутива к дистрибутиву, я просто редактирую скрипт настроек фаервола либо шаблон ansible с правилами.

На тему отключения firewalld я тоже время от времени получаю критику, типа надо изучать новое и не цепляться за старое. Так вот, firewalld я изучил и пользуюсь относительно регулярно. Он долгое время использовался в Bitrixenv, с которым я работаю давно и плотно. Кстати, в последних версиях этого окружения bitrix отказался от firewalld. Удивился, когда это заметил. В связи с этим, firewalld мне приходится знать и использовать. И мне он нравится меньше, чем нативные правила в iptables и мои скрипты для управления ими.

Свое мнение не навязываю и убеждать никого не хочу. Делюсь в статье про настройку centos тем, что использую сам. А вы выбирайте тот инструмент, что вам больше подходит. Я привык управлять iptables через самописный скрипт, который переношу от сервера к серверу и редактирую под конкретные потребности. Этим скриптом я и поделюсь. Так что для начала остановим и отключим firewalld.

Сразу хочу предупредить, что не имея доступа к консоли сервера, настраивать firewall плохая идея. Даже если вы очень хорошо понимаете что делаете и проделывали подобное много раз, все равно есть шанс остаться без доступа к серверу. Так что первым делом перед настройкой iptables проверяем доступ к консоли сервера.

# systemctl stop firewalld
# systemctl disable firewalld
rm ‘/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service’
rm ‘/etc/systemd/system/basic.target.wants/firewalld.service’

Установим утилиты для iptables:

# yum install iptables-services

Включим автозапуск iptables:

# systemctl enable iptables

Теперь создадим файл /etc/iptables.sh следующего содержания:

Делаем файл c правилами исполняемым и запускаем:

# chmod 0740 /etc/iptables.sh
# /etc/iptables.sh

Проверяем, применились ли правила:

При каждом запуске файла с правилами iptables, все изменения записываются в файл /etc/sysconfig/iptables и применяются при загрузке системы.

Настройка SSH в CentOS

Продолжаем настраивать centos. Внесем некоторые изменения в работу ssh для небольшого увеличения безопасности. Хотя речь стоит вести больше не о безопасности, а об удобстве и эффективности. По-умолчанию, сервис ssh работает на 22 порту и если все оставить как есть, то мы получим огромное количество попыток авторизоваться. Боты сканят непрерывно интернет и подбирают пароли к ssh. Это не доставляет в реальности каких-то серьезных хлопот и тем не менее, подобные запросы забивают лог secure и трятят некоторые ресурсы сервера как миниум на установку соединения и рукопожатия (handshake).

Чтобы немного закрыть себя от сканов простых ботов, изменим порт, на котором работает ssh. Можно выбрать любой пятизначный номер, это не принципиально. От автоматического сканирования это защитит. Повесим демон ssh на 25333 порт. Для этого редактируем файл /etc/ssh/sshd_config.

# mcedit /etc/ssh/sshd_config

Раскомментируем строку Port 22 и заменим значение 22 на 25333.

Так же я обычно разрешаю подключаться по ssh пользователю root. Мне так удобнее. Проблем с этим у меня никогда не возникало. Если вы считаете, что это не безопасно, не трогайте эту настройку. Чтобы разрешить пользователю root подключаться по ssh, раскомментируйте строку

Сохраняем файл. Теперь обязательно изменяем настройки iptables, добавляем в разрешенные подключения вместо 22 порта 25333. Если этого не сделать, то после перезапуска sshd мы потеряем удаленный доступ к серверу. Итак, открываем и меняем в строке

$IPT -A INPUT -i $WAN -p tcp —dport 22 -j ACCEPT

22 на 25333 и исполняем файл. Наше текущее соединение не оборвется, так как оно уже установлено, но заново подключиться по ssh к 22 порту уже не получится.

# systemctl restart sshd

Кстати, если вы не отключили SELinux, то просто так не сможете сменить порт ssh. Получите ошибку при перезапуске.

Наглядный пример того, как работает защита SELinux. Если у вас кто-то заберется на сервер через какую-то уязвимость и захочет открыть отдельный ssh серввер на каком-то нестандартном порту, у него ничего не получится.

Проверяем какой порт слушает sshd:

Если вывод такой же как у меня, то все в порядке, теперь к ssh можно подключаться по 25333 порту.

Для применения изменений нужно перезапустить ssh службу, как мы уже делали ранее. Настройку службы sshd в centos закончили, двигаемся дальше.

Настраиваем время

Узнать, какое время настроено на сервере centos можно с помощью команды date:

Чтобы сменить часовой пояс, можете воспользоваться специальной утилитой, которая входит в состав systemd.

# timedatectl set-timezone Europe/Moscow

По факту, эта утилита меняет символьную ссылку. Рассказываю, чтобы вы понимали, как реально меняется часовой пояс.

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

Теперь проверим статус службы по обновлению времени через интернет. Для этого можно использовать указанную выше команду timedatectl без параметров.

В CentOS есть утилита для синхронизации времени chrony. В стандартной установке она должна быть установлена в системе, в минимальной ее нет. Если у вас она не стоит, как и у меня, что видно по скриншоту, то установим и настроим вручную:

# yum install chrony

Запускаем chrony и добавляем в автозагрузку:

# systemctl start chronyd
# systemctl enable chronyd

Проверяем, нормально ли запустился:

# systemctl status chronyd

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

Более подробно об этой теме написано отдельно в моем материале — установка, настройка и синхронизация времени в CentOS.

Добавление репозиториев

При настройке centos частенько нужен софт, которого нет в стандартной репе. Для инсталляции дополнительных пакетов необходимо подключить репозитории в CentOS. Наиболее популярный это EPEL. Раньше был rpmforge, но уже как несколько лет закрыт. Про него все позабыли. Подключаем репозиторий EPEL. С ним все просто, он добавляется из стандартной репы:

# yum install epel-release

Так же для CentOS 7 крайне полезен репозиторий REMI, который позволяет установить больее свежие версии php, в отличие от тех, что есть в стандартном репозитории. Напомню, что это версия php 5.4, которая уже никуда не годится и снята с поддержки.

# rpm -Uhv http://rpms.remirepo.net/enterprise/remi-release-7.rpm

Для Centos 8 remi пока не актуален, но думаю, что это временно. В принципе, мне этих двух репозиториев в centos обычно хватает в общем случае. Другие подключаются уже под конкретные нужды для установки различного софта.

Настройка хранения истории в bash_history

Двигаемся дальше по настройке системы centos на сервере. Полезным будет внести некоторые изменения в стандартный механизм сохранения истории команд. Он часто выручает, когда надо вспомнить одну из ранее введенных команд. Стандартные настройки имеют некоторые ограничения, которые неудобны. Вот их список:

• По-умолчанию, сохраняются только последние 1000 команд. Если их будет больше, то более старые будут удаляться и заменяться новыми.
• Не указаны даты выполнения команд, только их список в порядке выполнения.
• Файл со списком команд обновляется после завершения сессии. При параллельных сессиях часть команд может быть утеряна.
• Сохраняются абсолютно все команды, хотя в хранении некоторых нет никакого смысла.

Список последних выполненных команд хранится в домашней директории пользователя в файле .bash_history (в начале точка). Его можно открыть любым редактором и посмотреть. Для более удобного вывода списка, можно в консоли ввести команду:

и увидеть пронумерованный список. Быстро найти конкретную команду, можно с помощью фильтрации только нужных строк, например вот так:

Так мы увидим все варианты запуска команды yum, которые хранятся в истории. Исправим перечисленные недостатки стандартных настроек хранения истории команд в CentOS. Для этого нужно отредактировать файл .bashrc, который находится в том же каталоге, что и файл с историей. Добавляем в него следующие строки:

export HISTSIZE=10000
export HISTTIMEFORMAT=»%h %d %H:%M:%S »
PROMPT_COMMAND=’history -a’
export HISTIGNORE=»ls:ll:history:w:htop»

Первый параметр увеличивает размер файла до 10000 строк. Можно сделать и больше, хотя обычно хватает такого размера. Второй параметр указывает, что необходимо сохранять дату и время выполнения команды. Третья строка вынуждает сразу же после выполнения команды сохранять ее в историю. В последней строке мы создаем список исключений для тех команд, запись которых в историю не требуется. Я привел пример самого простого списка. Можете дополнить его на свое усмотрение.

# source ~/.bashrc

По настройке хранения истории команд все. В файле можно много чего настроить интересного. Я одно время увлекался и экспериментировал, но потом все забросил, так как не имеет смысла. Работая с серверами заказчиков я чаще всего вижу дефолтный bash, поэтому лучше привыкать и работать именно в нем. А отдельные настройки и украшательства это удел личных компьютеров и серверов. Не рабочих. Так что больше я ничего не настраивать по стандарту в centos сервере в этом плане.

Автоматическое обновление системы

Для поддержания безопасности сервера на должном уровне необходимо как минимум своевременно его обновлять — как само ядро с системными утилитами, так и остальные пакеты. Можно делать это вручную, но для более эффективной работы лучше настроить автоматическое выполнение. Не обязательно именно устанавливать обновления автоматически, но как минимум проверять их появление. Я обычно придерживаюсь такой стратегии.

Для автоматической проверки обновлений в Centos 7 нам поможет утилита yum-cron. Ставится она традиционно через yum из стандартного репозитория.

# yum install yum-cron

После установки yum-cron создается автоматическое задание на выполнение утилиты в /etc/cron.daily и /etc/cron.hourly. По-умолчанию, утилита скачивает найденные обновления, но не применяет их. Вместо этого, администратору на локальный почтовый ящик root отправляется уведомление об обновлениях. Дальше вы уже в ручном режиме заходите и решаете, устанавливать обновления или нет в удобное для вас время. Мне такой режим работы видится наиболее удобным, поэтому я не меняю эти настройки.

Как я уже говорил ранее, в Centos 8 используется другой пакетный менеджер — dnf. Настройка обновления пакетов там выполняется через утилиту dnf-automatic. Поставим ее и настроим.

# yum install dnf-automatic

Управлением запуском по расписанию занимается уже не cron, а systemd своим встроенным планировщиком. Посмотреть таймеры автоматического запуска можно командой:

# systemctl list-timers *dnf-*

Если там нет ни одного задания, то добавить таймер можно вручную:

# systemctl enable —now dnf-automatic.timer

Конфиг для dnf-automatic живет в /etc/dnf/automatic.conf. По-умолчанию он только скачивает обновления, но не применят их. Конфиг хорошо прокомментирован, так что можете его настроить так, как пожелаете. Отдельных пояснений не требуется. Настраивайте обновление пакетов системы на свое усмотрение. Как я уже сказал, автоматически только качаю их. Установку всегда держу под контролем с ручным управлением.

Отключаем флуд сообщений в /var/log/messages

Продолжая настройку centos, исправим одно небольшое неудобство. В дефолтной установке системы 7-й версии, весь ваш системный лог /var/log/messages через некоторое время работы сервера будет забит следующими записями.

В Centos 8 я их не заметил, поэтому там ничего делать не надо. Никакой практической пользы сообщения не несут, поэтому отключим их. Для этого создадим отдельное правило для rsyslog, где перечислим все шаблоны сообщений, которые будем вырезать. Разместим это правило в отдельном файле /etc/rsyslog.d/ignore-systemd-session-slice.conf.

# cd /etc/rsyslog.d && mcedit ignore-systemd-session-slice.conf

Сохраняем файл и перезапускаем rsyslog для применения настроек.

# systemctl restart rsyslog

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

Установка iftop, atop, htop, lsof на CentOS

И напоследок в завершении настройки добавим несколько полезных утилит, которые могут пригодиться в процессе эксплуатации сервера.

iftop показывает в режиме реального времени загрузку сетевого интерфейса, может запускаться с различными ключами, не буду останавливаться на этом подробно, в интернете есть информация на эту тему. Ставим:

# yum install iftop

И два интересных диспетчера задач, я чаще всего пользуюсь htop, но иногда пригодится и atop. Ставим оба, сами посмотрите, разберетесь, что вам больше нравится, подходит:

# yum install htop
# yum install atop

Вот как выглядит htop:

Для вывода информации о том, какие файлы используются теми или иными процессами, советую поставить утилиту lsof. Она скорее всего рано или поздно пригодится, когда будете диагностировать работу сервера.

# yum install lsof

Рекомендую еще установить несколько нужных и полезных программ, которые часто необходимы, но отсутствуют в минимальной установке — wget, bzip2, traceroute, gdisk.

# yum install wget bzip2 traceroute gdisk

На этом у меня все. Базовая настройка CentOS закончена, можно приступать к установке и настройке основного функционала.

Настройка системной почты

В завершение настройки сервера CentOS сделаем так, что бы почта, адресованная локальному root, отправлялась через внешний почтовый сервер на выбранный почтовый ящик. Если этого не сделать, то она будет локально складываться в файл /var/spool/mail/root. А там может быть важная и полезная информация. Настроим ее отправку в ящик системного администратора.

Подробно об этом я рассказал в отдельной статье — Отправка почты через консоль с авторизацией в linux. Здесь кратко только команды и быстрая настройка. Ставим необходимые пакеты:

# yum install mailx cyrus-sasl cyrus-sasl-lib cyrus-sasl-plain postfix

Рисуем примерно такой конфиг для postfix.

Создаем файл с информацией об имени пользователя и пароле для авторизации.

Создаем db файл.

Теперь можно перезапустить postfix и проверить работу.

# systemctl restart postfix

К стандартному алиасу для root в /etc/aliases, добавьте внешний адрес, куда будет дублироваться почта, адресованная root. Для этого редактируем указанный файл, изменяя последнюю строку.

Обновляем базу сертификатов:

Отправим письмо через консоль локальному руту:

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

Ошибка эта означает то, что у вас в качестве отправителя почты указан не тот же ящик, что вы используете для авторизации. Как это исправить, я рассказываю в отдельной статье — как изменить адрес отправителя в postfix. С другими почтовыми системами, где нет подобной проверки, все должно быть нормально и так.

На этом настройка локальной почты закончена. Теперь все письма, адресованные локальному root, например, отчеты от cron, будут дублироваться на внешний почтовый ящик, причем с отправкой через полноценный почтовый сервер. Так что письма будут нормально доставляться, не попадая в спам (хотя не обязательно, есть еще эвристические фильтры).

Часто задаваемые вопросы по теме статьи (FAQ)

Почему вы используете скрипт для настройки iptables, вместо стандартного FirewallD?

Я работаю не только с серверами, где установлен firewalld. Правила для iptables более универсальные и применимы в любом linux дистрибутиве. Мне так просто удобно. Если вам удобнее работать с firewalld, то используйте его.

Используете ли вы GIU в настройке и эксплуатации серверов?

Чаще всего нет. У меня давно налажен процесс настройки практически любого сервера. Я быстрее все делаю через консоль. Иногда использую Webmin из-за удобного просмотра логов сервисов, если они хранятся только на сервере. Если вам нужна консоль управления сервером, то я рекомендую попробовать Cockpit.

Зачем вы отключаете SELinux? Неужели так трудно его настроить?

Я умею настраивать selinux и в некоторых статьях это показываю. Данный материал по общей, базовой настройке centos. В основном это для новичков, которых если сразу нагрузить еще и selinux, то будет тяжело. Если есть желание использовать selinux, его можно будет включить и настроить вместе с сервисом, который будет работать на сервере после предварительной настройки.

Почему вы не используете sudo, а работаете в консоли под root?

Подробно этот вопрос я разбирал в отдельной статье про sudo. Если объяснить кратко, то смысл в том, что я подключаюсь к консоли сервера для административных дейсвий. Мне всегда нужен sudo, поэтому не вижу смысла его каждый раз набирать. Проще сразу зайти под root.

Заключение

Мы выполнили некоторые начальные шаги по настройке сервера CentOS, которые я обычно делаю при подготовке сервера сразу после установки. Я не претендую на абсолютную истину, возможно что-то упускаю или делаю не совсем верно. Буду рад разумным и осмысленным комментариям и замечаниям с предложениями.

Напоминаю, что данная статья является частью единого цикла статьей про сервер Centos.

Полезно после базовой настройки сразу же подключить сервер к системе мониторинга. Либо настроить ее, если у вас еще нет. У меня есть подробный цикл статей по настройке мониторинга:

Из наиболее популярных и масштабных статей по настройке различного функционала на базе сервера centos хочу отметить следующие:

• Почтовый сервер postfix.Файловый сервер samba с интеграцией в AD.Настройка шлюза centos и прокси сервера squid.Пошаговая инструкция по настройке asterisk для среднего офиса.
• Почтовый сервер postfix.
• Файловый сервер samba с интеграцией в AD.
• Настройка шлюза centos и прокси сервера squid.
• Пошаговая инструкция по настройке asterisk для среднего офиса.

• Пример соединения двух офисов с помощью openvpn.
• Настройка веб сервера на базе apache+php или nginx+php-fpm.

И никогда не забывайте про бэкап и его проверку — бэкап или перенос linux сервера.

Видео по настройке CentOS

https://youtube.com/watch?v=qsDH0u1gCGw%3Ffeature%3Doembed

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.

Проверьте себя на вступительном тесте и смотрите подробнее программу по ссылке.

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Когда у меня появилась необходимость настроить полноценный прокси сервер на базе CentOS 7, оказалось, что в интернете почти нет актуальной информации на эту тему. Статьи в целом есть, но большинство из них про 6-ю версию, плюс нету полноценной связки с active directory. В своей статье я восполню тематический пробел.

Теоретический курс «Сетевые технологии для системных администраторов» позволит системным администраторам упорядочить и восполнить пробелы в знаниях. Цена очень доступная, есть ознакомительные уроки. Все подробности по ссылке. Можно пройти тест на знание сетей, бесплатно и без регистрации.

Существует проверенная временем связка для прокси сервера — squid + sams. Я настраивал ее еще лет 8 назад на Freebsd. Недавно у меня появилась необходимость настроить что-то подобное на CentOS 7, и я с удивлением обнаружил, что ничего принципиально нового с тех пор не появилось. Никакой более удобной и информативной web панели к squid не придумали.

Так что будем настраивать проверенный временем набор программ. Ко всему прочему, удобнее его сразу интегрировать с виндовым доменом, для простой авторизации на прокси с помощью учетных записей домена. Так проще будет смотреть статистику и давать доступ. Особенно это актуально, если у вас есть терминальные пользователи, работающие с одного ip. Здесь у вас вообще нет других вариантов, если вам нужна статистика и ограничение доступа по пользователям.

Приступим к настройке. В своей работе я буду подразумевать, что вы установили и настроили centos по моим рекомендациям. Советую ознакомиться с материалом. Это позволит здесь не тратить время на второстепенные настройки, которые не имеют прямого отношения к теме статьи.

Добавление CentOS 7 в домен Windows

Здесь нужно быть очень внимательным. Это сложный и не любимый мной момент, так как все очень сильно привязано к версиям системы и софта. Порой какой-нибудь точки или регистра достаточно, чтобы ничего не работало. Так вышло и у меня, когда я готовил этот материал.

Я без проблем ввел компьютер в домен, прошел все проверки, но потом в squid напрочь отказывалась работать ntlm авторизация. Все на вид выглядело нормально, но не работало. Я несколько раз восстанавливал виртуалку и начинал все сначала, перечитав практически все, что смог найти по теме в рунете и буржунете. В какой-то момент все заработало. Я зафиксировал результат и несколько раз проверил последовательность действий и отточил ее до каждого шага. Проверил несколько раз на чистой системе. По крайней мере на момент написания статьи конфигурация на 100% рабочая, если аккуратно повторить все мои действия. Приступаем.

Сначала остановим и отключим firewalld:

# systemctl stop firewalld && systemctl disable firewalld

Это не значит, что его не надо настраивать. Сейчас другая тема статьи, для локализации проблем необходимо убрать все, что теоретически может мешать при неправильной настройке. Firewall нужно настраивать и у меня есть подробная инструкция по настройке iptables. Рекомендую с ней ознакомиться и аккуратно настроить iptables, когда все получится со squid.

Установим софт для добавления сервера в домен windows:

# yum -y install samba-winbind samba-winbind-clients pam_krb5 krb5-workstation ntp ntpdate

Для продолжения настройки вам необходимо знать следующие вещи — FQDN имя контроллера домена, его ip адрес и учетную запись с правами на ввод компьютера в домен.

Первым делом вручную синхронизируем часы компьютера с контроллером домена:

Добавляем наш контроллер в список серверов для обновления в файле /etc/ntp.conf, запускаем ntp и добавляем в автозагрузку:

# systemctl enable ntpd
# systemctl start ntpd

Синхронизация времени с контроллером домена не является обязательным действием. Но в случае расхождения времени более чем на 5 минут, будут возникать проблемы, которые на первый взгляд будут неочевидными и решать их трудно. Поэтому на всякий случай процедуру лучше провести. Очень подробно о настройке времени в CentOS 7 рассказано отдельно.

Выполняем команду для передачи настроек керберосу:

Команда вся идет в одну строчку. Скопируйте ее сначала в текстовый файл и подредактируйте под свои параметры. Проверьте, что нигде не пропали и не добавились лишние пробелы, либо какие-то еще символы, тире должно быть двойным перед параметром. В данном случае:

• xs — название домена
• winsrv — имя контроллера домена
• winsrv.xs.local — полное имя домена

Вывод после работы команды будет такой:

Job for winbind.service failed. See ‘systemctl status winbind.service’ and ‘journalctl -xn’ for details.
getsebool: SELinux is disabled

Это нормально. Обращаю внимание, что SELinux у меня отключен.

Теперь заводим машину в домен:

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

Теперь нужно запустить и добавить в автозагрузку winbind:

# systemctl start winbind
# systemctl enable winbind

Проверяем, все ли у нас корректно работает. Для начала проверим наличие доверительной учетной записи сервера на КД:

# wbinfo -t
checking the trust secret for domain XS via RPC calls succeeded

Все в порядке. Теперь проверяем, может ли наш сервер получать списки пользователей и групп. Первая команда выводит список всех групп домена, вторая — всех пользователей:

# wbinfo -g
# wbinfo -u

Проверим авторизацию пользователя через winbind:

# wbinfo -a XS\control%’pass’
plaintext password authentication succeeded
challenge/response password authentication succeeded

В данном случае control — имя пользователя домена, pass — его пароль. Успешная проверка выглядит так, как у меня.

Теперь запросим билетик кербероса:

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

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

Настройка SQUID с ntlm авторизацией через домен

Дальше будет попроще. Если на предыдущем этапе вы все сделали правильно, то squid заработает без проблем. Устанавливаем его:

# yum -y install squid

Открываем файл конфигурации /etc/squid/squid.conf и добавляем в самое начала следующие параметры:

auth_param ntlm program /usr/bin/ntlm_auth —diagnostics —helper-protocol=squid-2.5-ntlmssp —domain=XS
auth_param ntlm children 10
auth_param ntlm keep_alive off
acl auth proxy_auth REQUIRED

Не забудьте указать свой домен. Обращаю внимание на первую строку. В большинстве инструкций в интернете она выглядит немного не так, в ней нет дополнительных параметров. Без них у меня ntlm авторизация не хотела работать, я очень долго ее мучал.

Дальше находим в конфиге строку:

http_access allow localnet

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

http_access allow auth

Разрешаем доступ только тем, кто прошел авторизацию. Запускаем squid и добавляем в автозагрузку:

# systemctl start squid
# systemctl enable squid

Все, можно идти проверять. Открываем браузер у какого-нибудь компьютера и указываем в качестве прокси ip адрес сервера, порт 3128. Пробуйте выйти в интернет.

Как понять, что все работает правильно:

• Пользователя должно пустить в интернет.
• В лог файле сквида должна быть информация об имени пользователя, который получает доступ. У меня это выглядит примерно вот так при открытии страницы яндекса:

В данном случае control — доменная учетная запись.

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

В таком виде конфигурация сервера уже вполне рабочая, можно пользоваться, подключать пользователей. Но это неудобно. Нужно средство для удобного управления списками доступа и просмотра статистики пользователей.