Как переименовать сетевой интерфейс в CentOS 7

Во FreeBSD, когда настраиваешь сетевые параметры, есть очень удобный механизм переименовывания названий сетевых интерфейсов. Можно, к примеру, интерфейс em0 назвать lan0, а xl0 - wan0. Во-первых, это придаёт настройкам всевозможных конфигурационных файлов осмысленности: сразу понятно, какой интерфейс за что отвечает, а во-вторых, в различных конфигурационных файлах можно использовать эти псевдонимы и, в случае замены сетевой карты, нужно всего-лишь поменять одну строчку в rc.conf. Причём, делается такое переименование элементарно - одной строкой в конфиге rc.conf:

ifconfig_em0_name="lan0"
ifconfig_xl0_name="wan0"

И всё! Дальше везде используем только имена lan0 и wan0.


Когда я начал настраивать очередной Linux сервер, был сильно удивлён, что этот, вроде бы, тривиальный механизм в линуксе устроен, мягко говоря, несколько сложнее. Казалось бы, чего проще - добавь в конфигурационный файл сетевого интерфейса параметр NAME и интерфейс сам переименуется. Но нет. Там нужно задействовать какие-то сложные и не до конца понятные механизмы udev. 99% советов сводится к необходимости добавить в конфигурационный файл /etc/udev/rules.d/70-persistent-ipoib.rules строк типа:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="90:2b:34:87:d1:7d", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="lan0"

Тут с ходу понятно только, что сетевому интерфейсу с соответствующим mac-адресом присваивается имя lan0. Объяснения, зачем нужны остальные параметры, и что они означают, найти весьма непросто.
Но и это ещё не всё. После описанных действий нужно переименовать в каталоге /etc/sysconfig/network-scripts/ файл с именем ifcfg-старое_имя в файл ifcfg-новое_имя и изменить в самом файле все названия интерфейсов со старого на новый. (Написанное выше справедливо для CentOS, в Ubuntu немного по-другому).

В последних дистрибутивах (RHEL7, CentOS 7, Ubuntu 16.04) всё ещё больше запуталось. Там отказались от традиционного для линуксов именования сетевых интерфейсов, типа eth0, eth1 и т.д., и внедрили именование более сложное, основанное на аппаратном расположении интерфейса. Как это теперь работает, можно почитать, к примеру, здесь:
http://val-khmyrov.blogspot.ru/2015/11/blog-post_22.html
Всё понятно? Мне не совсем.
Я же, когда начал копать в сторону решения проблемы наткнулся на следующий мануал:
https://www.freedesktop.org/software/systemd/man/systemd.link.html
Т.е., по идее, с помощью этого механизма можно легко переименовать любой сетевой инерфейс, используя штатное средство systemd.link. Для этого всего-лишь нужно для каждого интерфейса в каталоге /etc/systemd/network/ создать файл, например с именем 10-lan0.link примерно следующего содержания:

[Match]
MACAddress=00:a0:de:63:7a:e6
[Link]
Name=lan0

после чего интерфейс с соответствующим mac-адресом, по идее, должен переименоваться. Но не тут то было! Сделал, как написано - не работает. Начал гуглить и обнаружил, что про это почти нигде ничего не сказано, кроме вышеприведённого мануала.
Хотел уже плюнуть на всё и воспользоваться методом редактирования 70-persistent-ipoib.rules (благо, он в CentOS 7 тоже работает), но случайно попал на основополагающий сайт документации RHEL. Там, вот на этой странице:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Disabling_Consistent_Network_Device_Naming.html
увидел совет, как отключить существующую схему именования. А именно нужно сделать симлинк:

ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

Таким образом отключается именование интерфейсов по слотам и включается именование по линкам.
И вот только после этого начинает работать механизм systemd.link. Победа!

В итоге имеем следующее.
Чтобы переименовать, к примеру, сетевой интерфейс ens160 в lan0 в CentOS 7, нужно сначала создать символическую ссылку:

ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

В каталоге /etc/systemd/network/ создаём файл 10-lan0.link следующего содержания:

[Match]
MACAddress=00:a0:de:63:7a:e6
[Link]
Name=lan0

указав реальный mac-адрес интерфейса, который пытаемся переименовать.

После чего, в каталоге /etc/sysconfig/network-scripts/ переименовываем файл ifcfg-ens160 в файл ifcfg-lan0 и в самом файле изменяем параметры NAME и DEVICE на новые. Перегружаемся, наслаждаемся новым именем.

И всё это вместо одной строчки:
ifconfig_ens16_name="lan0"
во FreeBSD.
Архитекторы Linux тут явно перемудрили.

Ротация логов сервера OpenVPN под FreeBSD

Задача эта, как ни странно, весьма нетривиальная.
Во-первых, если расположение log-файлов задать в конфиге OpenVPN через дерективу:

log /var/log/openvpn/openvpn.log

то никакой ротации настроить не получится. Дело тут в том, что демон OpenVPN держит этот файл до своего перезапуска и пытается писать именно в него не по имени, а по дескриптору. Т.е., когда программа newsyslog осуществляет ротацию логов, она старый файл копирует, удаляет и создаёт вместо него новый, а OpenVPN продолжает пытаться писать логи в файл со старым дескриптором, которого уже не существует. В результате, после ротации лога таким способом, запись в него прекращается.
В сети описаны способы, как настроить это через утилиту logrotate с использованием параметра copytruncate, но, во-первых, logrotate штатно во FreeBSD не входит, а во-вторых, у меня это тоже не заработало. Идея тут в том, что параметр copytruncate позволяет не удалять старый log-файл, копируя его в другой, а старый просто обнулять. После этого, по идее, OpenVPN должен продолжить писать в старый файл нулевого размера с тем же дескриптором, а предыдущий лог уже подвергается упаковке и ротации. Однако у меня ротация лога таким способом, конечно, произошла, но OpenVPN продолжил писать в старый файл с той же позиции, на которой он остановился. Т.е. размер текущего log-файла не уменьшился.

Второй способ более правильный, и описан в документации OpenVPN, хотя и не совсем явно. Состоит он в том, что дерективу "log" из файла конфигурации OpenVPN нужно убрать. После этого все логи OpenVPN начнут попадать в общий файл /var/log/messages, а уже оттуда их нужно перенаправить в другой файл через настройки syslogd и ротировать посредством newsyslog. Во многих руководствах, найденных мной в сети, написано, что для этого нужно всего-лишь добавить в конец стандартного файла /etc/syslog.conf следующие строки:

!openvpn
*.*                                             /var/log/openvpn/openvpn.log

Добавил, логи OpenVPN действительно начали писаться куда надо, НО они продолжали попадать и в /var/log/messages, т.е. дублировались.
После долгих экспериментов и консультаций с умными людьми выяснилось, что вышеуказанные строки нужно добавлять не в конец файла syslog.conf, а в его начало, добавив туда ещё одну строку, в результате чего выглядеть это должно так:

!openvpn
*.*                                             /var/log/openvpn/openvpn.log
!-openvpn

Первые две строки указывают демону syslogd перенаправлять все сообщения от программы openvpn в файл /var/log/openvpn/openvpn.log, а третья сточка отключает какое-либо другое сохранение сообщений от программы openvpn.
Далее добавляем в newsyslog.conf то, что нам нужно, например такую строку:

/var/log/openvpn/openvpn.log    644     7       *       @T04    ZC


и процесс пошёл. Всё работает.

В заключении ещё один момент. Мне нужно было сделать всё описанное для трёх демонов OpenVPN, запущенных на одном сервере. В результате экспериментов выяснилось, что выглядеть это должно так:

В начале /etc/syslog.conf:
!openvpn1
*.*                                             /var/log/openvpn/openvpn1.log
!openvpn2
*.*                                             /var/log/openvpn/openvpn2.log
!openvpn3
*.*                                             /var/log/openvpn/openvpn3.log
!-openvpn1,openvpn2,openvpn3
...

В конце /etc/newsyslog.conf:
...
/var/log/openvpn/openvpn1.log    644     7       *       @T04    ZC
/var/log/openvpn/openvpn2.log    644     7       *       @T04    ZC
/var/log/openvpn/openvpn3.log    644     7       *       @T04    ZC

Теперь всё.

Перенаправление http запросов на https в Forefront TMG

Т.к. пользователи, как правило, не обращают внимание на такие мелочи, как буква "s" в https при написании адреса сайта и потом утверждают, что у них ничего не работает, очень полезно сделать автоматический редирект с адреса http:// на https://.
Если сервер опубликован из локальной сети посредством FTMG, то сделать это не так уж и просто. Я уж не знаю, что там Microsoft намутили, но штатными средствами Forefront (через Publish Web Sites) у меня это не получилось, т.к. при попытке создать т.н. Listener по https оно просит сертификат сервера и, почему-то, наотрез отказывается принимать официально выданный Thawte, Inc. сертификат. Если у вас вообще нет сертификата, то опубликовать так web-сервер через https тем более не получится.

Но можно сделать по-другому:
1. Сначала нужно опубликовать ваш сервер, не как web-сервер, а просто пробросив через FTMG 443 порт (через Publish Non-Web Server Protocols). В результате, он станет доступен из интернет по протоколу https.
2. Далее нужно опубликовать его же, как обычный web-сервер по протоколу http (через Publish Web Sites).
3. После этого необходимо зайти в настройки этого правила и сделать там так, как показано на скриншотах:

Важно! Получившееся правило должно стоять в списке до правила, созданного в пункте 1.

Всё. Редирект работает без всяких сертификатов.

ComminiGate Pro: перенос почты с сервера MS Exchange с помощью MoveIMAPMail

В состав сервера CommuniGate Pro входит утилита для переноса почты со старого сервера на новый посредством IMAP - MoveIMAPMail. У неё есть куча параметров, которые описаны в мануале. Если сервер CGP установлен на Linux, то для удобства переноса большого количества ящиков, проще написать небольшой скрипт:

#!/bin/sh

/opt/CommuniGate/Migration/MoveIMAPMail \
--verbose \
--notimeout \
--noACL \
--fixLongLines 256 \
--renameMailboxList ./rename.txt \
192.168.1.252 $1 "$2" 127.0.0.1 $1 "$3"

и передавать ему в качестве параметров имя пользователя и два пароля - старый и новый.

интерес тут представляет параметр:

--renameMailboxList ./rename.txt

он указывает утилите автоматически переименовывать папки при переносе со старого сервера на новый и брать шаблоны переименований из файла rename.txt. Это удобно, например, чтобы сообщения из папки "Отправленные" на Exchange сразу попали в папку "Sent Items" на CGP и т.п. Проблема тут заключается в том, что MoveIMAPMail не понимает в качестве параметров русские имена папок. Вернее, она их понимает, но в весьма специфическом формате IMAP-UTF-7. Например, папка "Удалённые" в этом формате называется так: "&BCMENAQwBDsENQQ9BD0ESwQ1-".
Ввести русское имя папки в таком формате от руки не представляется возможным. Я написал об этом разработчикам CGP, но они мне ответили, что ничего делать не будут, ибо по стандарту, именно в таком виде все папки, названные не латиницей, хранятся на сервере. Что характерно, в мануале на CGP про это ни слова не сказано, и я убил полдня, пытаясь понять, почему у меня русские имена папок не переименовываются. 

В общем, пришлось заниматься извращениями. Написал ещё один скрипт:

#!/bin/sh

filename="rename.txt"

echo -e "`echo -n 'Отправленные' | /usr/bin/uconv -f utf-8 -t IMAP-mailbox-name`\tSent Items" > $filename

echo -e "`echo -n 'Удаленные' | /usr/bin/uconv -f utf-8 -t IMAP-mailbox-name`\tTrash" >> $filename

echo -e "Deleted Items\tTrash" >> $filename

echo -e "`echo -n 'Черновики' | /usr/bin/uconv -f utf-8 -t IMAP-mailbox-name`\tDrafts" >> $filename

echo -e "`echo -n 'Нежелательная почта' | /usr/bin/uconv -f utf-8 -t IMAP-mailbox-name`\tJunk" >> $filename

echo -e "Junk E-mail\tJunk" >> $filename

echo -e "Notes\tNotes_old" >> $filename

echo -e "Tasks\tTasks_old" >> $filename

Для его функционирования нужно установить из репозитория консольную утилиту uconv, которая умеет преобразовывать тексты из кучи разных форматов и наоборот. В ней этот хитрый формат называется IMAP-mailbox-name.

Результатом работы этого скрипта будет файл rename.txt в нужном формате, который можно передать в качестве параметра MoveIMAPMail.

Ещё один полезный параметр --filter after "31-Dec-2011". Дату в нём нужно писать именно в таком виде - месяц тремя буквами, иначе никаких ошибок не увидите, но работать будет неправильно. С его помощью можно скопировать со старого сервера не всю почту, а только после определённой даты. Это полезно, если квоты на размер ящика на новом сервере меньше, чем на старом.

Установка и первоначальная настройка сервера 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!". В общем и целом он работает вполне стабильно и сносно, но некоторые недочёты всё-таки имеются. (О них я, наверное, напишу позже, если к тому времени разработчики их не исправят).