Установка и первоначальная настройка сервера CentOS 6 и 7

CentOS 6

CentOS 6, если её ставить в минимальной конфигурации, ставится уж очень аскетично. В базовую систему даже не входит пакет man, не говоря уже о многих других полезных утилитах. Поэтому решил написать небольшую шпаргалку, что нужно поставить, чтобы получить работоспособный и минимально-настроенный сервер.

Итак, начинаем установку (всё написанное делалось на CentOS 6.5 x64):

выбираем английский язык

когда просят ввести имя хоста, вводим и нажимаем кнопку "Configure Network"


в настройках адаптера включаем "Connect automatically" и настраиваем параметры IPv4

(если этого здесь и сейчас не сделать, то после перезагрузки система будет с отключенной и не настроенной сетью, и придётся править конфигурационные файлы вручную)

выбираем Minimal install

после окончания установки и первой перезагрузки:
yum update
reboot

ставим минимально-необходимый на сервере набор пакетов:
yum -y install man mc telnet bind-utils bzip2 unzip zip wget psmisc

настраиваем синхронизацию времени:
yum -y install ntp
chkconfig --level 345 ntpd on
service ntpd start

выключаем для начала брендмауэр, чтобы он не мешал настройке всего прочего; потом его можно при  необходимости настроить и включить
chkconfig ip6tables off
chkconfig iptables off
service iptables stop
service ip6tables stop
можно ещё выключить selinux, написав в файле /etc/selinux/config
SELINUX=disabled
он тоже может помешать настройке сервера

Добавляем дополнительные репозитории EPEL и rpmforge:
yum -y install epel-release
rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt
yum -y install http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm

yum updateставим оттуда ещё несколько полезных пакетов
yum install bash-completion htop atop iftop

В принципе, это всё,  но можно ещё для большей секурности добавить пользователя с правами администратора и отключить возможность root-логина через ssh:
useradd administrator
usermod -a -G wheel administrator
или сразу одной командой:
useradd -G wheel administrator

passwd administrator

в файле /etc/sudoers убираем комментарий в строке:
# %wheel        ALL=(ALL)       ALL

в файле /etc/ssh/sshd_config убираем комментарий в строке:
#PermitRootLogin yes
и меняем yes на no

Всё. Теперь по ssh можно зайти только пользователем administrator и админить сервер уже через sudo.
Дальше ставятся все остальные необходимые на сервере сервисы и пакеты, в зависимости от назначения этого сервера.

CentOS 7

В CentOS 7 много чего поменялось, но в плане первоначальной настройки сервера изменения не большие.
Инсталлятор вполне интуитивно-понятный. Главное, как и с 6 не забыть сразу настроить сеть. Хотя, в 7 штатно появилась утилита nmtui, которая позволяет наглядно из консоли настроить все необходимые сетевые параметры, не прибегая к ручной правке конфигурационных файлов.

После инсталляции почти всё, как и с шестёркой:

yum -y update
yum -y install mc telnet bind-utils bzip2 unzip zip wget psmisc

В 7 исчезла команда ifconfig. Вместо неё появилась команда ip. Для элементарного просмотра сетевых настроек нужно ввести ip a. Но если хочется старых команд, то нужно поставить ещё один пакет:
yum -y install net-tools.x86_64

Далее настраиваем синхронизацию времени. Тут есть два варианта:

1. Воспользоваться уже имеющимся в системе новым сервисом. (В Centos 7 вместо старого  ntpd предустановлен и активирован новый сервис chrony).
Проверяем, работает ли chrony:
systemctl status chronyd
если работает, то разрешаем синхронизацию времени:
timedatectl set-ntp yes
проверяем состояние:
chronyc sources

2. Если chrony не работает или хочется установить вместо него ntpd:

yum -y install ntp
systemctl start ntpd
systemctl enable ntpd
отключаем chrony:
systemctl stop chronyd
systemctl disable chronyd

Добавление репозиториев:
yum -y install epel-release
rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt
yum -y install http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm

ставим оттуда полезные утилиты:
yum -y update
yum -y install bash-completion htop atop iftop


Далее можно сделать то же, что и в версии 6 касательно создания пользователя администратор и отключения логина root через ssh.

Также для начала отключаем selinux, написав в файле /etc/selinux/config
SELINUX=disabled

и выключаем firewall.
В CentOS 7 вместо привычных iptables появилась надстройка над ними под названием firewalld. Отключается он так:
systemctl stop firewalld
systemctl disable firewalld
Как его настраивать - отдельная тема. Почитать об этом можно, например, тут:
http://bozza.ru/art-259.html

Если нужно вернуть iptables, то делается это так:
yum -y install iptables-services
systemctl enable iptables

Ну и последнее. Можно ещё отключить в системе ipv6, ибо оно пока непонятно зачем нужно в большинстве случаев.
Во-первых, частично это можно было сделать при инсталляции, когда настраивались сетевые параметры, отключив автоматическую настройку ipv6.
Если этого сделано не было, то уже после установки системы делается это так:
Сначала смотрим, какие службы используют ipv6:
netstat -tulnp
Все строки с названием протокола и 6 в конце или ::: это как раз оно. Как правило, на только что установленном сервере этот протокол используют sshd, ntpd и, возможно, postfix.

Для sshd в /etc/ssh/sshd_config находим строки:
#AddressFamily any
#ListenAddress 0.0.0.0
и меняем их на:
AddressFamily inet
ListenAddress 0.0.0.0

Для ntpd в /etc/ntp.conf добавляем в конце строку:
interface ignore ipv6

И отключаем ipv6 в самой CentOS. Открываем файл /etc/sysctl.conf и добавляем туда строки:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

и в файле /etc/sysconfig/network, добавляем:
NETWORKING_IPV6=no
IPV6INIT=no

редактируем файл /etc/default/grub
находим строку GRUB_CMDLINE_LINUX и добавляем в начало ipv6.disable=1, чтобы это выглядело примерно так:
GRUB_CMDLINE_LINUX="ipv6.disable=1 rd.lvm.lv=rootvg/usrlv...
создаём новую конфигурацию grub командой:
grub2-mkconfig -o /boot/grub2/grub.cfg

Для postfix правим файл /etc/postfix/main.cf
Делаем замену
#inet_interfaces = localhost
#inet_protocol = all
на
inet_interfaces = 127.0.0.1
inet_protocol = ipv4


Можно перегружаться и проверить, что ipv6 успешно выключен:
netstat -tulnp
никаких упоминаний об ipv6 там быть не должно.

ComminiGate Pro: установка, настройка, миграция

Первое, что бросается в глаза, когда начинаешь читать документацию по CommuniGate Pro (CGP), это то, что разработчики, кажется, предусмотрели почти всё. Настолько много там всяких разных гибких настроек и вариантов работы во всех компонентах сервера. Ложкой дёгтя в этой цистерне мёда можно считать разве что не очень современный и немного запутанный интерфейс администратора. Некоторые вещи там находятся совсем не там, где предполагаешь сначала. Возможно, это только с непривычки, пока не до конца понял логику системы. И, справедливости ради, нужно заметить, что у некоторых систем и такого интерфейса нет.
Но это так, лирическое отступление. Речь в этой статье пойдёт об установке, первоначальной настройке CGP и миграции со старого почтового сервера.

Для начала о выборе серверной ОС.
CGP, как я уже писал ранее, выпускается под кучу разных ОС, начиная от Windows и Linux, и кончая AIX, HP/UX и IBM OS/2. Можно было поставить его на Windows Server, только непонятно зачем, тем более, что от ОС для функционирования CGP мало что требуется, кроме надёжной и быстрой работы, поэтому выбор пал на Linux, как наиболее простую в эксплуатации и доступную систему. Разработчики посоветовали мне 64 битную версию любого RedHat-совместимого дистрибутива. Я взял последнюю на тот момент версию CentOS - 6.4.

Собственно, процесс установки и первоначальной настройки CGP подробно описан в руководстве и является настолько тривиальным, что рассказывать про него нет никакого смысла. Просто скачал дистрибутив под нужную платформу, запустил инсталляцию и через пару минут сервер уже работает. Нюансы первоначальной настройки зависят от того, будет у вас сервер находиться напрямую в интернете или в локальной сети за брандмауэром, но там тоже всё предельно просто, нужно только предварительно прочитать соответствующие разделы документации.
Кстати, чтобы попробовать в работе CGP перед покупкой тоже ничего особого не нужно. Берёте на сайте бесплатную версию на 5 пользователей, ставите её прямо на свою рабочую станцию и сразу начинаете работать с почтой, IM и телефонией. Единственное, что обязательно нужно серверу CGP для работы - это доменное имя, но для теста вполне сойдёт что-нибудь типа cgp.company.ru в локальной сети. Также в этом случае, чтобы почта ходила из интернета и в интернет понадобится MX запись в DNS и соответствующие настройки брандмауэра на корпоративном шлюзе.

Теперь о миграции с MS Exchange.
В руководстве по CGP описано несколько способов миграции со старой почтовой системы, в том числе и с Exchange с помощью специальной утилиты, которая умеет экспортировать пользователей из одной системы в другую. У меня эта утилита почему-то не заработала. Но не очень то и хотелось.
По ряду причин, мы решили не переносить сразу всех пользователей со старого сервера на новый, а делать это постепенно, сначала оставив работать в сети оба сервера: CGP для уже смигрированных пользователей, а Exchange для тех, кто ждёт своего часа.
Собственно, такой способ тоже описан в руководстве по CGP. Суть его заключается в следующем:
- в настройках DNS и брандмауэра делаем так, чтобы почта приходила на CGP;
- на самом CGP включаем опцию перенаправления почты для неизвестных пользователей домена на старый почтовый сервер (в нашем случае это MS Exchange);
После этих действий все сообщения, приходящие снаружи уже смигрированным пользователям попадают в их ящики на новом сервере, а тем, кто ещё остался на старом, письма уходят на Exchange и тоже попадают куда нужно.
Вроде, всё просто, но у нас это осложнялось одним нюансом. Нам нужно было оставить Exchange со всеми ящиками в неприкосновенности ещё на какое-то время, и чтобы он был доступен пользователям в качестве архива. Это необходимо было потому, что у некоторых сотрудников размер почтовых ящиков на Exchange превышал все мыслимые пределы и не вписывался в квоты на новом сервере. Поэтому было принято решение, таким сотрудникам автоматически переносить на новый сервер почту только за последние два года, а всё остальное они должны забрать со старого сервера сами в пределах установленных квот.
Иными словами ситуация получилась такая:
- очередной пользователь переносится на новый сервер и начинает работать уже на нём;
- его старый почтовый ящик на Exchange продолжает существовать и быть ему доступным;
- при этом вся почта, как снаружи, из сети интернет, так и из локальной сети от всех пользователей должна поступать в его ящик на новом сервере.
Проблема тут заключается в том, что если на Exchange ящик пользователя не удалять, то когда ему будут писать сотрудники в локальной сети, ещё не переведённые на новый сервер, письмо попадёт в ящик на сервере Exchange и до CGP не дойдёт. (Т.к. Exchange будет справедливо считать, что это его пользователь).
Задача была решена следующим образом:
1. На CGP сделали у основного домена company.ru псевдоним cgp.company.ru.
2. В DNS создали запись cgp.company.ru, указывающую на сервер CGP.
3. После перевода пользователя user@company.ru на новый сервер, на сервере Exchange настраивается переадресация всей входящей почты для этого пользователя на адрес user@cgp.company.ru.
После этих действий, сотруднику, переведённому на новый сервер, вся почта начинает поступать куда нужно - на сервер CGP.

Ну и о переносе почты со старого сервера на новый.
Разработчики CGP предоставляют для этого специальную консольную утилиту MoveIMAPMail, которая умеет копировать письма указанного аккаунта с одного сервера IMAP на другой. Описание этой утилиты и параметров её запуска есть в руководстве по CGP. К сожалению, работает это не так гладко, как хотелось бы. Во-первых, утилита иногда "спотыкается" о некоторые папки IMAP и прекращает дальнейшую работу. Например, это происходит, если со старым сервером пользователь поработал посредством программы Mail из Mac OS X. Что уж она там такого неправильного создаёт, я не знаю, но эффект налицо. А во-вторых, утилита по умолчанию пытается скопировать все имеющиеся у пользователя папки IMAP (даже общие папки, не принадлежащие пользователю), что не всегда нужно, а параметры, задающие исключения у меня не заработали с русскими именами папок.
Но и тут выход был найден. У утилиты есть параметр, позволяющий копировать только "подписанные" папки IMAP. Поэтому берём любой почтовый клиент, умеющий работать с IMAP, подключаемся с его помощью к ящику пользователя на старом сервере и подписываемся там только на те папки, которые нужно перенести. После этого запускаем утилиту, и вся нужная почта копируется на новый сервер.

В заключении хотелось бы ещё раз обратить внимание на то, что документация, идущая с Communigate Pro, достаточно подробная, чтобы не прибегать ни к каким другим руководствам по установке и настройке, но всё же я дам одну ссылку на текст, из которого можно кое-что почерпнуть тем, кто впервые  устанавливает и настраивает сервер CGP:
http://wiki.rsu.edu.ru/wiki/Communigate_Pro
Кроме того, там есть описание, как "прикрутить" к серверу CGP бесплатные SpamAssassin и антивирус ClamAV.
Также кое-какие сведения можно получить из официального русскоязычного списка рассылки:
http://mx.ru/Lists/CGatePro/List.html
Ну и, если вы приобрели продукт легально, то не стоит пренебрегать поддержкой от производителя. Адрес электронной почты службы поддержки и ссылка на риал-тайм чат есть на русском сайте Communigate Pro в разделе поддержка. Отвечают там на вопросы быстро и достаточно подробно.

CommuniGate Pro: выбор

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

Для начала о проблеме выбора.

Когда назрела необходимость обновлять существующий почтовый сервер (MS Exchange 2003), так получилось, что рассматривались всего три варианта:
1. Тот же Exchange, но последней версии.
2. Kerio Connect.
3. CommuniGate Pro.
Собственно, какие-либо другие серьёзные и относительно доступные по цене, решения, на российском рынке представлены мало, а некоммерческие имеют недостатки, присущие любому бесплатному ПО:
- отсутствие нормальной поддержки;
- как следствие - необходимость во всём разбираться самому;
- огромное количество недокументированных и плохо документированных нюансов, на которые наталкиваешься только тогда, когда начинаешь вовсю эксплуатировать такое ПО;
- необходимость иметь администратора, который хорошо знает именно это ПО; причём, если он уволится, разобраться, что он там нанастраивал бывает очень непросто.
Возможно, эти тезисы покажутся кому-то, кто в совершенстве знает какой-нибудь Exim или Postfix, спорными, но целью этой статьи не является доказать преимущества коммерческого ПО перед бесплатным. Каждый выбирает для себя сам, исходя из возможностей и условий.

В общем, если деньги есть и нет времени и желания самому ковыряться с установкой и настройкой, а потом всё это хозяйство поддерживать, то проще софт купить. Особенно это актуально для почтового сервера, требующего бесперебойной работы в режиме 24/365 и надёжной сохранности данных.

Был сделан анализ стоимости покупки и владения всех трёх вариантов за 5 и за 10 лет. Он представлен в следующей таблице (цены в рублях):

https://docs.google.com/spreadsheet/ccc?key=0Ar6Huh64nZhndGhuUDlwLVRoNWZPbWhlMWZkZUFMb1E&usp=sharing

Тут требуется небольшие пояснения:
1. В качестве антивирусов рассматривался:
- для MS Exchange - Kaspersky AV для почтовых серверов
- для двух других - Sophos antivirus, предлагаемый производителями этих систем в виде штатного, платного дополнения.
2. Т.к. у нас в компании до сих пор используется MS Office 2003, то в стоимость Exchange включалась покупка последней версии Outlook. У кого нет лишней лицензии на Windows Server, нужно добавить ещё и её. (Кстати, если у вас есть ещё компьютеры с Windows XP, то имейте ввиду, что последний Outlook требует как минимум Windows Vista).
3. Количество сотрудников у нас около 200, но почтовых ящиков примерно 300. MS считает лицензии по количеству клиентов, т.е. рабочих мест, подключающихся к серверу, а Kerio, CGP и KAV по количеству почтовых ящиков. Поэтому Exchange считался на 200 лицензий, а всё остальное на 300.
4. Лицензия на MS бессрочная, а на два других продукта для наличия поддержки и возможности получать обновления и новые версии, требуется ежегодная подписка. (Впрочем у MS это тоже есть и называется, по-моему, software assurance и тоже стоит немалых денег).
5. "Важные функции" - это то, что именно мы наиболее часто используем при администрировании почтового сервера.
6. Также рассматривался вариант без покупки антивирусного ПО, т.к. антивирус установлен у нас на всех рабочих станциях.

Как видно из таблицы, CGP выигрывает по стоимости у всех конкурентов, пусть и не во всех случаях много. (Причём, даже если взять с запасом лицензию на 400 ящиков).


После анализа стоимости владения, системе CGP было уделено повышенное внимание и выяснились следующие его дополнительные преимущества:
1. ПО разработано в полном соответствии с открытыми стандартами, что означает корректную работу с любым другим ПО, поддерживающим эти стандарты.
2. В состав сервера входит не только почта, но и средства документооборота, совместной работы, мгновенных сообщений и IP-телефонии, и всё это работает прямо "из коробки".
3. Не сказать, чтобы это было приемуществом, но то, что CGP установлен и используется в большом количестве компаний, в том числе и очень крупных, стало дополнительным аргументом в его пользу. (Списком этих компаний можно впечатлиться на сайте CGP).
4. CGP имеет достаточно подробную документацию, в том числе и на русском языке.
5. CGP имеет русскоязычную поддержку в режиме онлайн (по электронной почте и посредством чата).
6. По отзывам, продукт является очень надёжным и за последние 8 лет не имеет ни одной критической уязвимости.
7. Продукт динамично развивается - постоянно выходят новые версии, в которых добавляется функционал и исправляются недочёты.
8. CGP работает на куче разных платформ, в том числе и на бесплатных, и даже на таких экзотических, как Solaris и OS/2. Т.е. серверную ОС для него покупать не обязательно.

Ну и о недостатках по результатам предварительного тестирования (как же без них):
1. Аскетичный, довольно запутанный и не всегда очевидный интерфейс администратора. Я довольно плотно работаю с ним уже больше месяца, но до сих пор путаюсь, где, что находится.
2. Небезглючный клиент "Pronto!". В общем и целом он работает вполне стабильно и сносно, но некоторые недочёты всё-таки имеются. (О них я, наверное, напишу позже, если к тому времени разработчики их не исправят).