WEB-MAIL-DNS+DHCP-PROXY-FIREWALL сервер на ubuntu в локальной сети

Доброго времени суток. Столкнулся с такой задачой, нужно в институте поднять локальную сеть из 180 компов. Имеются два сервера intel. Так вот, мне не обходимо настроить локальную сеть таким образом;

1. WEB сервер которая видна по сети под именим institut.lan
2. MAIL сервер с доступом по mail.institut.lan (только для локальной сети)
3. DNS + DHCP для автоматической раздачи IP а так же что бы был виден WEB сервер (по записи А, не прписывать же каждому компу в сети настройки в файл HOST)
4. Поднять файловый сервер на SAMBA
5. PROXY что бы каждый клиент выходил в инет через свой логин и пароль, а так же контролировать его трафик и при не обходимости ставить ограничение на скачиваемые файлы.
6. FIREWALL для защиты сети



Полазил по инету. инфы много, ос выбрал ubuntu 9.10, web+dns+dhcp сделал но как организовать остальное, всё время какие то косяки то с mail, то с proxy серверами. Вчера вообще всё рухнуло. Вот решил попросить помощи у Вас, быть может кто решал такую задачу. Пожалуйста помогите... :(

ЗЫ: google уже был, еслиб нашёл ответ - сюда не писал бы.. wink

Надо все делать последовательно и задавать вопросы по мере поступления.. А сейчас Вам сказать нечего.
В качестве прокси используем Squid. Можно к нему прикрутить SAMS и squidguard. Samba тоже настраивается по разному.

Установил ubuntu.
Установил Apache2
Установил Bind 9 (DNS)
Установил DHCP3
Установил MySQL
Установил PHP5

В dns настроил зону А institut.lan на ip 192.168.100.1
В apache тоже настроил хост на institut.lan

в сетевых настройках:
eth0
192.168.1.2
255.255.255.0
192.168.1.1

в eth1

182.168.100.1
255.255.255.0

Из компьютеров в сети через браузер по адресу http://institut.lan всё работает. Динамические ip подставляются.

Теперь на этом же сервере мне нужно настроить email, proxy а на втором сервере нужно настроить samba, С которого из них начать. Прокси должна пускать в инет через авторизацию а так же иметь возможность ограничений и фильтров. Примерно как в user gate.

Azizbek написал:

... Вчера вообще всё рухнуло.

Итак, чтобы если и рушилось, но не всё, то настоятельно рекомендую посмотреть в сторону:
1. Кластеризации твоих компьютеров. У тебя же два сервера. Читай про heartbeat и кластерные файловые системы (drbd и glusterfs).
2. Виртуализации отдельных твоих подсистем. Можно посмотреть в сторону Oracle VirtualBox.

Итак, поднимаем кластер и на нем делаем кластерную FS.
Соответственно на кластерную FS переносим конфигурационные файлы отказоустойчивых сервисов (в стандартных местах делаем на них симлинки). Образы виртуальных машин - так же на кластерную FS сразу будем класть.
Далее думаем - какие сервисы стоит иметь на хостовой оси, какие - поднимать в гостевой.
На хосту я бы оставил только DNS+DHCP. Кэширующий DNS на каждом узле кластера, а DHCP - мигрирующий, под управлением heartbeat.
Шлюзовую машину, межсетевой экран со сквидом - в виртуалку. И чтобы мигрировала между узлами кластера. Хотя, можно и непосредственно на узлах разместить с общей конфигурацией и под heartbeat'ом. Но сие хуже. На узлы кластера надо отдельные правила экранирования писать, а на выход в Inet - иные. Поэтому proxy со всей его требухой - лучше в виртуалку.
Почтовый сервер - в отдельную виртуалку.
Файловый сервер - в отдельную виртуалку. Нефиг пускать студней к кластерной оси. Там только ты быть можешь, админить. А у студней в кластерной оси не должно быть никаких аккаунтов. И, может быть даже, поднимать его под Вынью, чтобы были и AD и более чем rwx продвинутые права на файло. Под юниксом не всё возможно сделать в части деления доступа.
WWW будет везде, это сейчас инструмент управления, но "публичный" - только в виртуалку.
Учебные машины - только виртуальные.
Ну и соответсвенно раскидать эти виртуальные машины между узлами кластера.

Если сделаешь так, по получишь устойчивую систему. И в ней крах одного компонента не повлечет за собой неработоспособности остальных. И, к тому же, если какая виртуальная машина рухнет, то не придется бегать к консоли сервера, нажимать там на кнопки и смотреть на экран загрузки. Всё (именно всё) будет доступно дистанционно.
И еще плюс - пока ты возишься с освоением одного пакета в виртуалке - ты совершенно не затрагиваешь работу уже отлаженных машин. Делай в виртуалке что хочешь, включай её, выключай - никому этим не помешаешь.
И еще плюс - на паре узлов при наличии достаточных на них железных ресурсов ты сможешь поднять гораздо больше чем 2 машины. И сможешь выбирать для решения той или иной задачи нужную (оптимальную) ось.

По схеме DNS - наверняка есть желание иметь в DNS имена локальных компьютеров. Можно заводить отдельные подзоны на твоем DNS-сервере в рамках имеющегося домена. В твоем случае - это оптимально. А если есть нужда видеть эти компьютеры в рамках одного домена, то тогда можно немного "обмануть" DNS (мы же не будем отдавать информацию своего DNS на улицу, не станем его светить по интернету? Верно?) - заводишь на своем кэширующем сервере "мастер-режим", то есть определяешь нужную тебе зону, руками записываешь в неё информацию, видимую по твоему домену из интернета (чтобы оно было одинаково и из инета, и локально) а далее - наполняешь через динамику DHCP свою зону нужными локальными хостами.