Штука позитивная. Стоит в тестовом режиме в моей компании. Хорошего и полезного в ней много. Но как всегда расскажу о «подводных камнях».
eGroupware, точнее ее модуль работы с почтой, опирается на любой сторонний почтовый сервер, с доступом к ящикам по IMAP. И, как заявляют разработчики, умеет нормально работать с LDAP серверами. Я там видел даже взаимодействие с AD. Т.е. как минимум аккаутны пользователей и адресные книги можно вынести в LDAP. Письма в egroupware можно прикреплять к заданиям, календарю и прочим полезным модулям, поэтому почтовый модкль по хорошему нужен.
Исходя из вышеперечисленного, решил скрестить почтовый сервер (доступ к ящикам при помощи Cyrus IMAP), OpenLDAP и eGroupware. Идея простая. В eGroupware заводится пользователь, информация о нем сохраянется в LDAP. Почтовый сервер берет инфу о пользователе из LDAP + включена функция автоматического создания почтовых ящиков в Cyrus IMAP. Заодно сторонние клиенты (предполагался Thunderbird) смогут брать из LDAP корпоративную адресную книгу.
И тут пошли подводные камни.
Учетные записи пользователей великолепно сохраняются в LDAP сервере. Но, к сожалению, модуль адресной книги их не видит. Приходится делать запись пользователя в адресбуке руками.
Почтовый сервер сам создает почтовые ящики и все служебные папки в ящике. Но я так и не смог найти, как автоматически давать доступ служебным пользователям к некоторым папкам юзверя. Например, это необходимо для работы спам фильтра. Он должен уметь помещать почту в специальные папки и забирать почту из папок для обучения.
Модуль адресной книги может экспортировать индивидуальные и групповые адресные книги в LDAP, но не видит их. Т.е. я эти записи увидел при помощи интсрументов, для работы с LDAP сервером.
Модуль работы с почтой, не отображает русские названия папок в IMAP сервере, если они сделаны сторонней программой в кодировке UTF-8.
После просмотра логов, оказалось, что в модуле адресной книги вызывается функция, отсутсвующая в дистрибутиве egroupware. Я пока не понял (не знаю я PHP) это внешняя функция или разрабы забыли что то положить в дистрибутив. Сейчас разбираюсь с этим вопросом.
В результате, принял решение. Буду все данные хранить в MySQL (хранилище по умолчанию). Разрешил пользователям настраивать почтовый сервер, услугами которого они пользуются самостоятельно. Если пользователю потребуется почтовый аккаунт, создам его вручную на почтовом сервере.
В остальном все пока тип-топ. Шикарный функционал.
В перспективе — прикрутить модуль, позволяющий подключаться к основным службам типа адресной книги и календаря, сторонним программам. (Таблица совместимости) Хотя всего функционала eGroupware при помощи внешнего клиента не получить 🙂 (Список модулей)
Мне потрясающе не везет с Федорой. Она либо не ставится, либо ставится но не так, либо ставится, но не работает. Последний опыт был с Русской федорой 10. Она поставилась, но то что я увидел, меня сильно удивило. Сильно — это слабо сказано (каламбурчик).
По идее это дружественный к пользователю дистрибутив. Т.е. по идее он не должен напрягать пользователя. Но о какой дружественности может идти речь, если рабочая станция на Федоре, с использованием КДЕ 4 тормозит больше чем Vista? КДЕ 4 — это вообще отдельная песня! Как можно это ставить в дистрибуив в маин ветку?
Дальше, чудо визарды конфигурации системы. Мне так и не удалось при помощи визарда в Русской федоре включить переключатель языка клавиатуры! (Переключатель из КДЕ не считается, это нонсенс). Кроме того, я даже не смог найти xorg.conf 🙂 Ну да ладно, настройка через HAL, но блин, лезть руками в конфигурационные файлы в юзер френдли дистрибутиве… слов нет.
Отдельная песня — это наблюдение за скачущими виджетами в графической утилите (визарде) установки программ. Мало того, что тормозит, дык еще таааак прыгает 🙂 жестокая весЧь!
Всеже очень сильно чуствуется, что Федора — это полигон. Так что, поставлю я на ноут обратно Open SuSE, он как десктопный дистрибутив на порядок лучше Федориного Коре.
Настройка шифрования при подключении к почтовому серверу. 40 Настройка sendmail. 46 Настройка IMAP сервера. 47 Настройка почтового клиента. 48
Подключение антивируса. 50
MySQL. 53
Защита от спама. 65 DNSBL. 65 Антиспам фильтр. 66 Настройка spf. 75 Серые списки. 78
WEB интерфейс. 82
Поддержка нескольких почтовых доменов. 92 ——
Пришлось в курсе добавить немного материала по базовому администрированию MySQL и немного о сервере Apache (используется при создании WEB интерфейса)
eGroupware в этот курс не попал, потому как отдельный мощный продукт. Хотя для работы ему требуется нормально настроенный почтовый сервер.
Вообще egroupware — это клевая вещь. Я просто прусь от нее. Шикарное решение для небольших компаний. А вот как развернуть его на нескольких серверах, я пока еще не представляю. Наверное синхронизацию базы можно делать средствами MySQL, а вот хранение документов, обработка сайтов тут пока не придумал. Может использовать rsync?
Оказывается LPI поменяли срок жизни своих сертификатов. Раньше раньше был равен 10 годам. Но видать поток на сертификацию мало мало затих и они сократили срок жизни до 5 лет 🙂 Ну вот, в следующем году надо будет все сдавать по новой. На досуге задумался — нужна ли мне сертификация от RedHat?
Интересно, что в первую очередь ищут противные редиске на WEB сервере? Достаточно посмотреть логи Apache, что бы понять, что нельзя выставлять в Интернет и как не следует называть директории.
phpadmin — чемпион! По моему, проще один раз выучить управление MySQL из командной строки и забыть про всякие WEB морды. Вот списочек, как усердно они перебирали возможные варианты 🙂
Сейчас работаю с одним клиентом, переводим компанию с продуктов Микросотф, на бесплатные аналоги, в том числе и рабочие места. Традиционно возник вопрос об офисном пакете. Не для кого не секрет, что ОО и МсОфис отличаются друг от друга, добавляются особенности интерфейса, работы, баги и прочая. Причем, клиент это прекрасно понимает 🙂 и первое что они потребовали — сделать небольшой курс по переходу с МСОфис на ОО.
Честно говоря, я терпеть не могу читать пользовательские курсы, поэтому не взялся за работу над курсом. Поспрошал коллег. Оказывается такой курс уже есть. Более того, есть готовые курсы по обучению ОО с нуля.
Так что, если возникнет вопрос обучения Опен Офису с самого начала или вопрос перехода на ОО с Микрософт, обращайтесь, помогу 🙂
Наконец то появилось время и я ударными темпами начал писать третий дистанционный курс «Настройка Linux сервера, часть 2». Уже написал больше половины.
О чем будет рассказано на курсе.
Большая часть курса посвящена настройке почтового сервера. А это значит, что мы прикурутим антиспам, антивирус и прочие полезные плюшки. Будет рассказано о виртуальном хостинге нескольких почтовых серверов и много другого.
В результате, на выходе вы получите полностью готовый к употреблению почтовый сервер небольшой компании. Если у вас большая компания, то этот сервер можно будет развивать, расширять. Надо посмотреть на запросы слушателей, и возможно я расширю этот курс вопросами о создании группы почтовых серверов, выполняющих разные функции.
Кроме, собственно, почтового сервера, нам придется рассмотреть администрирование MySQL. Эта база данных будет использоваться для работы антиспам фильтра. Я решил не делать отдельного курса по MySQL и поэтому включил его во вторую часть.
Так же мы посмотрим на программу tinyca2, предназначенную для генерации SSL сертификатов. Все таки Николай Коршенин убедил меня, что эта графическая надстройка над openssl не есть зло 🙂
Если все пойдет по плану, то через неделю курс будет полностью готов.
И еще одна новость. Я почти договорился со своим коллегой о создании им дистанционного курса по Apache. Огромный плюс заключается в том, что человек, который будет делать этот курс — практик. У него есть свой развитый WEB хостинг и он много знает о реальных проблемах, возникающих при эксплуатации Apache. Кроме работы в народном хозяйстве, он заодно является хорошим преподавателем. Вообщем, продолжу переговоры, надеюсь, что все получится.
Это глава из учебника, предоставляемого к моим дистанционным курсам. (с) 2008, Артур Крюков www.kryukov.biz
После выпуска первой редакции этого учебника, у слушателей возникло много вопросов по применению VPN в реальных задачах. Эта глава была добавлена специально для того, что бы показать, как еще можно использовать Open VPN.
Рассмотрим задачу, возникшую у одного из слушателей.
Исходные данные.
Существует внутренняя сеть 192.168.1.0/24. Она выходит в Интернет через роутер с внутренним интерфейсом 192.168.1.1 и внешним интерфейсом 120.3.5.8. Этот и все другие IPадреса взяты совершенно случайно и никакого отношения к реальным серверам не имеют.
Где то «в замке у шефа» в буржуинском сегменте Интернет стоит сервер с IP 110.45.45.8, который тоже принадлежит нашей компании.
Задача 1.
Необходимо весь трафик, предназначенный на WEB сервера (80 порт) отправлять только через сервер 110.45.45.8. Трафик между нашей сетью и этим сервером должен быть зашифрован. Весь остальной трафик из нашей сети должен идти обычным образом.
Задача 2.
Необходимо весь исходящий трафик нашей сети, предназначенный для Интернет, оправлять через роутер 110.45.45.8. Трафик между нашей сетью и этим роутером должен быть зашифрован.
Что тут сказать, параноидальные задачи, но выполнимые. Итак, будем играть в Штирлица и шифроваться.
Настройка VPN.
Материал, описанный в этом разделе необходим для решения обеих задач.
Для шифрования трафика меду двумя серверами мы будем использовать OpenVPN. Сервер, выводящий нашу компанию в Интернет, будет работать как VPN клиент. Сервер в Интернет всегда включен, поэтому он будет работать в качестве VPN сервера.
OpenVPN настраивается так же как и в предыдущей главе, поэтому не буду повторять материалы этой главы. Просто покажу готовые конфигурационные файлы клиента и сервера.
Конфигурационный файл VPN сервера.
dev tap0 proto udp mode server comp-lzo log-append /var/log/openvpn.log daemon ifconfig-pool 192.168.240.2 192.168.240.12 ifconfig 192.168.240.1 255.255.255.0 tls-server dh /etc/openvpn/dh1024.pem ca /etc/pki/CA/CA.crt cert /etc/pki/tls/certs/server.pem key /etc/pki/tls/private/server.key port 5000 user nobody group nobody persist-tun persist—key verb 0
Необходимо подставить реальные файлы ключей и сертификатов.
Что изменилось в файле конфигурации сервера, по сравнению с предыдущей главой? Во-первых, используется 5000 порт, а не 1194. За время, прошедшее с момента написания первой главы, создатели программы стали рекомендовать использовать порт 5000. На самом деле номер порта может быть любой, но мы будем следовать рекомендациям отцов-основателей.
Конфигурационный файл Linux клиента.
remote 110.45.45.8 5000 dev tap proto udp ca /etc/openvpn/certs/CA.crt cert /etc/openvpn/certs/client.pem key /etc/openvpn/keys/client.key client tls-client comp-lzo user nobody group nobody ping 30 ping-restart 120 ping-timer-rem persist-key persist-tun verb 0
В этом файле мы тоже заменили порт, куда будет подключаться клиент на 5000.
Посмотрим, что получится после настройки такого решения.
Таким образом, мы обеспечили шифрование при передаче данных между первым и вторым серверами. Но этого мало! Надо сделать так, что бы VPN сервер мог доставлять пакеты в сеть 192.168.1.0/24. Поэтому в конфигурации VPN клиента добавим команду push, которая внесет изменения в таблицу маршрутизации VPN сервера.
В результате конфигурационный файл клиента будет выглядеть так:
remote 110.45.45.8 5000 dev tap proto udp ca /etc/openvpn/certs/CA.crt cert /etc/openvpn/certs/client.pem key /etc/openvpn/keys/client.key client tls-client comp-lzo user nobody group nobody push «route 192.168.1.0 255.255.255.0 192.168.240.2» ping 30 ping-restart 120 ping-timer-rem persist-key persist—tun verb 0
Теперь внимательно приглядимся к нашей схеме. У нас получилось два сегмента внутренних сетей:
192.168.1.0/24
192.168.240.0/24
И два! Целых два выхода в Интернет! Через роутер 192.168.1.1 и роутер 192.168.240.1.
Господа, как только у вас появляется больше чем один выход в Интернет, необходимо использовать дополнительные возможности, предоставляемые ядром Linux в области маршрутизации. Эти возможности очень хорошо описаны в документе Linux Advanced Routing & Traffic Control HOWTO:
Настоятельно рекомендую в дальнейшее подробно изучить данный HOWTO!
А теперь займёмся решением задач.
Решение задачи 1.
Напомню, что требуется сделать.
Нам необходимо весь трафик на WEB сервера (порт 80) отправлять в Интернет через удаленный сервер, через интерфейс с IP адресом 110.45.45.8.
Весь остальной трафик из нашей сети должен выходит в Интернет через локальный сервер, через интерфейс с IP адресом 120.3.5.88.
На удаленном сервере нам надо сделать только NAT преобразование. Все пакеты, пришедшие из сети 192.168.1.0/24 или 192.168.240.0/24 (а вдруг у вас на клиентском сервере работает прокси сервер Squid?) пропускать через SNAT.
Поэтому в firewall удаленного сервера надо добавить следующие правила:
Не забудьте разрешить перенос пакетов с одного сетевого интерфейса на другой.
echo 1 > /proc/sys/net/ipv4/ip_forward
В файле /etc/sysctl.conf отредактируйте строку.
net.ipv4.ip_forward = 1
C удаленным сервером все. Займемся локальным сервером. Наша задача отправлять пакеты предназначенные на 80 порт в Интернет через машину 192.168.240.1.
Добавить маршрут в таблицу маршрутизации? Не поможет, в таблице маршрутизации нельзя указывать порты.
Сделать DNAT? Тоже не поможет, нам нельзя менять IP назначения.
SNAT? Тоже ничего не даст.
Во всех случаях, перечисленных выше, пакет с локального сервера будет уходить по маршруту по умолчанию через интерфейс eth0.
Пришло время включить дополнительные возможности ядра Linux. А вы знаете, что в Linux можно сделать 256 таблиц маршрутизации? И 512 можно! и даже больше 🙂
Для решения нашей проблемы мы добавим еще одну таблицу маршрутизации.
В этой таблице сделаем маршрут по умолчанию на машину 192.168.240.1 через интерфейс tap0.
Все пакеты, приходящие на наш сервер на 80 порт из внутренней сети, а также все пакеты, которые генерируют программы, работающие на нашем сервере на 80 порт, будем передавать в новую таблицу маршрутизации. А там уровень IP все сделает сам.
Создадим новую таблицу маршрутизации с именем www.
echo 430 www >> /etc/iproute2/rt_tables
Таким образом, мы создали таблицу номер 430 с именем www. Номер и имя можно использовать любые. Главное, что бы они уже не использовались в вашей системе. Вы можете сначала посмотреть содержимое файла rt_tables при помощи программы cat.
cat /etc/iproute2/rt_tables
Добавим в таблицу www маршрут по умолчанию.
ip route add default via 192.168.240.1 dev tap0 table www
Таблица создана. Как заставить необходимые нам пакеты попадать именно в неё? Тут следует сделать два действия:
При помощи iptables и действия MARK пометить пакет. Присвоить ему номер от 1 до 64.
При помощи программы ip, все помеченные нужным нам номером пакеты перенаправить в таблицу www.
Обратите внимание на то, что метки мы ставим в таблице mangle в цепочках PREROUTING (для пакетов, пришедших из внутренней сети) и OUTPUT (для пакетов, которые генерирует программное обеспечение, работающее на нашей машине), до того, как пакеты попадут в таблицу маршрутизации.
ip rule add fwmark 1 table www
Можете посмотреть какие пакеты, каким таблицам будут передаваться.
ip rule show
После перезагрузки компьютера, привязка к таблице и маршруты пропадут. Поэтому мы должны сделать так, что бы при старте они появились снова. Тут все зависит от дистрибутива. Самый простой способ воспользоваться файлом /etc/rc.d/rc.local (или /etc/rc.d/rc.local.local, зависит от системы, которую вы используете). В этом файле надо дописать правила:
Остальными правилами разрешаете то, что должно выходить через интерфейс eth0. Я не буду писать эти правила. Посмотрите, как это делалось в разделе, посвященном firewall. Единственное добавление — теперь надо явно указывать output интерфейс при помощи параметра –o.
Последнее замечание — NAT преобразования. Нам необходимо делать NAT только на интерфейсе eth0. На интерфейсе tap0 ничего делать не надо. Там пакеты идут без преобразования.
Решение задачи 2.
А тут я поступлю немного хитрее. Я хочу, что бы вы сами решили эту задачу. Если все заработает, значит, вы все поняли правильно. Если не заработает, присылайте мне ваше решение. У нас будет тема для обсуждения.
Единственная подсказка — трафик на 22 порт удаленного сервера не пускайте через VPN. Если вдруг не получится, вы хоть сможете подключиться к удаленному серверу. И вторая причина — в этом соединении уже итак все зашифровано J.
