Нужно перевести одну небольшую организацию с WinServer2003 на Linux-решение.
Что было:
Два Контроллера домена WinServer2003:
КД1 — Почта, 1С-файловая, ДНС, ДШСП.
КД2 — Файловый сервер.
Что нужно:
Перевести сервера на Linux-решение.
Нужно обеспечить миграцию пользователей между машинами, чтобы любой пользователь мог зайти под своей учётной записью на любом компьютере в сети.
Чтобы, если ПК откажет, работа могла продолжиться на другом ПК.
Что сделано:
Файловый сервер с КД2 переехал на сервер КД1, на освободившемся поднят Debian-6.0.6-amd64.
Что планирую сделать:
Поднять OpenLDAP + Samba для авторизации пользователей, хранения хомяков и обеспечения работы с 1С по сети (1С — файловая).
Я в правильном направлении мыслю?
Сейчас думаю над тем, как перевести почту.
Требуется, чтобы у пользователей сохранилась вся почта в их почтовом ящике. И при этом переехала на новый Linux-сервер.
Подскажите, пожалуйста, как это можно сделать?
В качестве почтового сервера планирую использовать iRedMail.
Пользователи подключаются через Outlook к Exchange по его родному протоколу.
Нужно, чтобы почта сохранялась локально на компьютер пользователя, для того, чтобы она была доступна и при отсутствии сети, и был доступ к почте извне организации, из Интернет.
Какой почтовый клиент может справиться с такой задачей?
Ай нид хелп! )
Миграция с WinServer2003 на Linux-решение
Сейчас думаю над тем, как перевести почту.
Требуется, чтобы у пользователей сохранилась вся почта в их почтовом ящике. И при этом переехала на новый Linux-сервер.
Подскажите, пожалуйста, как это можно сделать?
В качестве почтового сервера планирую использовать iRedMail.
"пальцем в небо..." - sendmail не ?!..
и да, можешь не слушать неосиляторов, утверждающих,"... дескать настраивать его сложно, проще себе голову прострелить из монтажного пистолета...", настраивается один раз, без особых затыков, главное читать внимательно в самих настроечных скриптах, ну и манами ессно не брезговать, по дефолту он сам уже рабочий, только выставлен в стадию "паранойя таки рулит"..
Нужно перевести одну небольшую организацию с WinServer2003 на Linux-решение.
.....
Ай нид хелп! )
Во первых мы имеем небольшой недостаток информации. А именно - переводится на Linux серверная часть сети или тотально, все юзеры должны уйти под Linux.
Если тотально - то организовать мигрирующих юзеров не получится. На Linux машине нет понятия "доменный" юзер. Все юзеры, которым дано право на компе работать должны быть на нем прописаны (и настроены) локально. При этом можно настроить им хомовник так, что все данные они будут держать на сети в своих персональных каталогах и эти каталоги будут монтироваться им в хомовник с нужными им полномочиями (autofs). Без этой работы блуждающий профиль не организовать.
Кроме этого, для обеспечения работы юзерей с приложениями 1С и MS-Office (увы-с, не отказаться никак) надо покупать wine@Etersoft. Оно специально под обеспечение 1С заточено. Но вот далеко не все виндовые приложения под ним идут. Выход на пути виртуализации, но тогда непонятно, зачем ставить Linux, чтобы на него взгромоздить оффтопик.
Теперь по серверной части. Вот здесь решение надо искать на пути виртуализации. Что бы я делал:
1. сервер хранения данных (СХД). С этого начинаем.
Здесь я озабочен высокой надежностью хранения данных и их высокой доступностью. То есть необходимо разворачивать СХД в кластерном варианте (то есть реплицировать в realtime данные на два сервера и автоматом переключать раздачу на выживший). Проще всего для этого применить glusterfs. Настраивается на раз-два. Но есть недостаток - если раздать самбой гластерный том, то на нем будет проблема с блокировками и 1С в файловом варианте тривиально рухнет. Так же, будут проблемы и с открытием тугаментов из MS-Office (начиная с 2007). В остальном - очень даже неплохо.
Однако обеспечить работу 1С на кластерной файловой системе тоже просто. Надо эту часть кластера назвернуть на drbd. Здесь с блокировками всё намано. К недостаткам drbd я отношу то, что иногда возникает состояние split-brian и система не знает, где более актуальные файлы. Лечение есть, но его продолжительность сильно зависит от объема drbd-тома. Я не советую делать такие тома больше 32 гигабайт. Этого размера вполне хватит на 1С и Консультанта какого с запасом.
Для управления этим кластером и миграцией служб применим heartbeat. Большего на 2 узла кластера и не надо.
2. Сервисы приложений, нативные.
Самба (файл-сервер), DNS, DHCP инсталлируются на оба хоста кластера, каталоги с их данными и конфигурациями переносятся на том glusterfs. Запуском этих служб управляем через heartbeat. Выходит из строя один сервер (отключаем его для каких либо работ) hearbeat в автомате запустит эти службы на живом сервере и настроит под них сетевые интерфейсы. То есть - каждый узел кластера имеет свой основной IP-адрес. А все сервисы видны через "виртуальный" блуждающий между узлами IP.
3. Сервисы приложений, виртуальные.
Если нам нужен AD, домен, то нужно иметь то, что его реализует. Тот же виндовый сервер. И отдельно - почтовый сервер (который может выступать и качестве шлюза в интернет). Для этого разворачиваем любую среду виртуализации (для начала можно и VirtualBox, но лучше - KVM+libvirt, но с ним возни будет больше, VB - проще) и в ней разворачиваем нужные нам сервера,Windows и почтовый.
Хавтушек как постоить на линуксе почтовый сервер полно. Ищи по словам postfix, exim, dovecot. При этом неважно, нативный он или виртуальный. С виртуальным даже проще. Его готовить можно отдельно и если что напортачил - нет проблем вернуться к сохраненному ранее образу с отлаженной системой.
Где хранить почту - на сервере или на локльных дисках? Если на сервере, то протокол IMAP. Но это потребует определенного объема на СХД. Если на локальных дисках, то POP, и, при этом, можно настроить почтового клиента так, чтобы он не удалял почту на сервере (точнее - удалял только вместе с удалением локального письма). Ну и естественно виртуальные машины тоже могут мигрировать между узлами кластера.
4. Физический доступ в Интернет. Настоятельно не рекомендую выставлять интерфейсы сервера на улицу. Плохой тон. Гораздо лучше доостнасить сервера второй сетевой платой, на этих интерфейсах организовать отдельную LAN (в которой гонять служебный кластерный трафик) и к которой подключить отдельный роутер. А на роутере организовать режим проброса нужных портов на тот или иной сервер, нативный или виртуальный. Для организации доступа к внутренним ресурсам компании из сети интернет следует развернуть openVPN (на роутере или на шлюзе). Хотя, можно и ограничиться режимом проброса портов, например, пробрасывать внешний порт 20110 роутера на порт 110 почтового сервера. Но openVPN - лучше.
5. LDAP? Если пользователей мало, то зачем он? Для хранения учеток пользователей та же самба имеет собственную "базу". Зачем плодить сущности без острой надобности? Я LDAP использую только как адресную книгу. В небольшой фирме не так много приложений, чтобы их завязывать на LDAP.
Как то так.
Теперь - что делать сейчас:
Имеем один свежий сервер с дебианом (как я понял - пустой), далее Д, и рабочий с оффтопиком, далее Р.
0. Я надеюсь, что сервер Д имеет небольшой корень и большой раздел для размещения данных (и, опционально, юзерского хомовника) . Несколько проще в будущем будет, если это дело организовано на LVM, хотя - необязательно. Отрезаем от большого раздела кусок в 32 гигабайта под организацию в дальнейшем тома drdb.
1. Настраиваем на Д DNS. Причём так, чтобы этот DNS знал про нашу локальную сеть и разрешал локальные имена. При этом - обязательно прописываем в этой схеме локальный IP нашего почтового сервера. На клиентах проверяем настройки, чтобы ни у кого не было прямого указания IP, только имя. Включаем новый DNS, на Р корректируем правила DHCP, чтобы юзерские компы брали DNS с нового адреса и отключаем DNS на Р. Проверяем работу.
2. Настраиваем DHCP на Д. Причем настраиваем его так, чтобы он обновлял локальную зону DNS на Д. Переключаем DHCP c Р на Д. Проверяем работу.
3. Поднимаем на Д файловый сервер на самбе. Делаем его самостоятельным доменом, то есть не включаем в существующий (он умрет в будущем). Настраиваем, переводим на него работу 1С и прочее... Проверяем работоспособность.
4. Ставим на Д glusterfs. И готовим с его помощью экспорт нескольких каталогов из большого раздела. Они нам понядобятся для хранения данных компактных виртуальных машин.
5. Поднимаем на Д виртуальную машину с каким угодно линуксом. Начал с дебиана, пусть так и будет дальше. На этой машине в будущем будет сделан почтовый сервер, но сейчас творим шлюз доступа в интернет. SQUID+iptables нам в руки. Настроили, проверили с административной машины, откорректировали правила маршрутизации в DHCP. Юзера поехали работать с инетом через новый шлюз. На этой машине или на внешнем роутере поднимаем и настраиваем openVPN для организации доступа определенных пользователей из внешнего мира к локальным ресурсам.
6. Клонируем эту VM (чтобы не мешать работе юзерей) и разворачиваем на клоне почтовый сервер. Почтовые каталоги выносим из виртуальной машины на внешний глустерный том. Образ машины маленький, нечего его захламлять почтой юзерсткой. Её храним вовне. Настраиваем почтаря под наши нужды (антиспам, антивирус и так далее) и назначаем этого клона дефолтным шлюзом.
Включаем новый почтовый сервер, корректируем IP почтаря в DNS и отключаем почтарь на старом сервере. Ловим и исправляем глюки.
7. Разворачиваем и настраиваем в очередной виртуальной машине новый AD-сервер под оффтопиком. Если нужен именно AD, в чем я не очень уверен. Хотя иметь в виртуале экземпляр хорошего оффтопика не вредно, на нём можно всякие регламентые работы по 1С проводить.
8. Переводим пользователей в новый домен, оффтопичный или самбовый.
************* смотрим, все ли работает у пользователей?*********
************* всё ли перенесли правильно?***************
************* НИЧЕГО НЕ ЗАБЫЛИ?******************
9. Поехали дальше, убиваем оффтопичный сервер и на нем поднимаем дебиан (Д2). С небольшим корнем, большим разделом под данные и отдельным разделом в 32 гигабайта под drdb.
10. Ставим на Д2 glusterfs и организуем глустерные тома в режиме репликации между Д и Д2. Переносим файловую помойку (кроме данных 1С) на глустерный том. Переносим конфиги и служебные каталоги самбы, dns, dhcp на глустер (создаем нужные симлинки). Перезапускаем эти службы на Д. На д2 - инсталлируем и создаем нужные симлинки конфигурационных каталогов.
11. Ставим на Д и Д2 drbd. И натравливаем его на выделенные ранее 32 гигабайта пустго места. Создаем там файловую систему, размещаем там данные 1С. Настраиваем соответствующим образом (на новое их размещение) самбу.
12. Определяем виртуальный (блуждающий) IP с которого будет раздаваться файл-сервер и ДНС. Корректируем правила DHCP и DNS.
13. Ставим и настраиваем heartbeat. То есть реализуем окончательно отказоустойчивый кластер. Образы виртуальных машин кладем на glusterfs и запускаем эти машины с того сервера, с какого хотим. Миграцию обеспечиваем через тот же heartbeat.
14. (чтобы не было 13 пунктов) пьем пиво и сдаем работу руководству.
Таким образом можно спокойно перехать с оффтопика на серверах с минимальным воздействием на юзерей.
уже проще все: Samba 4.0 Release хотя велосипеды еще будут :)
уже проще все: Samba 4.0 Release хотя велосипеды еще будут :)
Из за потенциальных велосипедов предпочту пока пожить на 3-й самбе. И подождать 2-го "сервиспака" для 4-й. Хотя, новость - интересна.
Из за потенциальных велосипедов предпочту пока пожить на 3-й самбе. И подождать 2-го "сервиспака" для 4-й. Хотя, новость - интересна.
наверно пока что подожду пока не появятся сборки в RH или SLES. А ради экспериментов поставлю поиграюсь и посмотрю что к чему. :)
На Linux машине нет понятия "доменный" юзер. Все юзеры, которым дано право на компе работать должны быть на нем прописаны (и настроены) локально
откройте для себя NIS, IPA, NSS и прочие решения.
я вижу два варианта:
1. поднять IPA и настраивать юзеров в нем. если рабстанции остаются виндовыми, то можно попробовать прикрутить openGINA
2. зимбра
откройте для себя NIS, IPA, NSS и прочие решения.
Был неправ. Но, насколько топикстартер сможет воспользоваться той же IPA? Особенно если линукс видит в первый раз в жизни. Я специально прописал RoadMap, по которому ему можно пройти и получить заявленный результат с минимальными усилиями, минимальными пертубациями пользователей и максимальными пряниками на выходе (отказоустойчивость и минимальное время простоя). Пока по этому пути идет, в линуксе освоится. А дальше посмотрит - нужно ли ему всё это централизованное управление на офис малого бизнеса, где, я полагаю, живет от силы 2 десятка юзерей вместе с уборщицами. НА - оно для бизнеса жизненно важно. А вот централизованное управление - оно уже опционально.
насколько топикстартер сможет воспользоваться той же IPA?
честно говоря, IPA совсем не сложен для базового использования. Но для абсолютной простоты, я бы просто поставил сервер с зимброй, которая сразу из коробки дает и почту и ldap, а на клиентские машины поставил бы pGINA, с настройками под openLDAP.
у зимбры есть отличный инструментарий для миграции мейлбоксов и учеток юзеров из ксченжа (недавно перетаскивал почти 1000 аккаунтов по 5Гб каждый, практически без проблем прошло), а установка проста как 5 копеек.
плюс нативный десктоп клиент заменяющий аутлук по функционалу, и куча прочих радостей в придачу, особенно если брать платную версию.
остальные сервисы, можно спокойно поставить хоть на тот же хост с зимброй, хоть на отдельные, в зависимости от ресурсов, у управлять ими православными конфигами или богомерзким, но гуевым вебмином - это уже стандартные мелочи, которые любому админу должны быть как семечки.
насчет 1С не скажу - никогда его не видел, и вряд ли увижу :)
НА - оно для бизнеса жизненно важно. А вот централизованное управление - оно уже опционально.
это я думаю от бизнеса зависит. видел достаточно контор которые прекрасно обходятся бекапами
Мне понравилось то, что Зимбра появилась в крякнутом варианте.
Поэтому ее можно протестировать в полный рост.
в крякнутом или в бесплатном?
Бесплатная версия превращается в полнофункциональную путем замены двух файлов...
Так что есть решение по переходу с Win на Lin :)
Сам хочу занятся переездом с MDAEMON на Zimbra, но есть проблема - старый cервак...