u1travio1et

Да практически всё (к чему не требуется исключительно гуй): работа с текстом и изображениями, работа с сетью и ее настройка, и т.д. и т.п.

имхо, проще сказать что нельзя сделать с помощью терминала.

В обязательном порядке! Файервол, можно встроенный ufw, на просто lamp-сервер этого достаточно. Прикрываем все порты кроме ssh (22) и 80/443, можно ssh перевести на какой нибудь 9922 порт, но это для параноиков.
Я еще ставлю fail2ban, да, я параноик. Хорошо бы отдельной партицией вторую копию root-раздела держать.
И сгенерите доступ по ssh только по ключам!
Дополнительно по вкусу.
И неплохо nginx фронтоэндом, а можно только им обойтись (без апаша), но тогда нужно еще php-fpm поставить и настроить.
Ну и memcached по желанию.
Так в общем все остальное можно докрутить по ходу работы.
Ах, да! Воткните collectd для сбора статистики.

И сначала все это на виртуалке попробуйте.

Серверное железо отличается функционалом! Это главное отличие.
По поводу надежности - как таковая надежность серверного железа вполне на уровне качественного десктопного.
Но на серверном железе проще построить надежное отказоустойчивое решение.
Вот блок питания - хороший качественный блок, вполне на уровне качественных десктопных аналогов.
Только вот попробуйте на десктопном железе подключить два блока питания для надежности. Без паяльника и прямых рук не получиться, а в серверном железе это штатный функционал.
То же самое с остальным.
Сам по себе сервер из серверного железа ничуть не надежней качественного десктопного аналога. Но он позволяет сделать надежное решение штатными методами.

Т.е когда у вас пять - десять пользователей, и перебой в работе не катастрофичен, десктоп стоящий под столом вполне себе конкурирует с сервером.
А вот когда у вас десяток серверов, и куча пользователей - вы замучаетесь администрировать стоящие под столами серваки, вам захочется стойку, где все под рукой компактно и удобно, захочется IPMI чтобы не лазить под стол и не подключать монитор к серверу, вы замучаетесь откручивать болтики которые крепят жесткие диски, и вам захочется нормальные корзины с горячим подключением, вам захочется нормальной техподдержки, и расширенной гарантии. И вы купите нормальное серверное железо не взирая на цену.

А если вы с такими проблемами не сталкиваетесь, то для вас десктопное железо ничуть не хуже серверного, а то и лучше по некоторым параметрам.

Никому не говорите про коммутаторы 1 уровня... Модели OSI я так понимаю?)
По Вашим вопросам:
1) Деньги обычно планируются на год или квартал вперед. Т.е. видно, что железка не справляется, что запасных частей нет и т.д. Говоришь руководству, что мол вот так и так, мне нужно это и это потому что вот так и так. Иначе будет вот так и мы тут будем сидеть без нифига. Если руководство адекватное, то часть требований одобрит и выделит под это денег. Поэтому сразу можно просить процентов на 20 больше :)
Проверки - смотря какие. На вирусы- лучше ночью, или в пятницу. Комп сам выключается после проверки или включается для нее. Нужно больше конкретики :)
2) Пользователи - наше все. Все зависит от способности нравится людям) Считай, что все они мало что смыслят и нужно подробно им все объяснять. Этим достигается цель а) тебе будут говорить спасибо б) продвинутые пользователи будут приятным подарком :) Если правильно вести - будут еще и тортики тоскать.
По поводу софта пиратского - тут каждый решает сам. Я всегда и везде говорю твердое нет, потому что если что - за жопу будут брать именно меня. Но, опять так, объясняю, почему я не буду ставить. Если заставляют ставить - задумайся.
3) Модель OSI она от масштабов не зависит. Хоть 4, хоть 400 узлов.
Я бы порекомендовал ставить систему мониторинга, на сервера и сетевое. Пользователей не трогаем. Для интереса можно все на скриптах сделать, если серверов не очень много
4) Про установку софта писал выше. Про мониторинг - по хорошему, софт надо весь вычищать. Всегда есть аналоги, которые выполнят все то, что пользователю надо. Просто нужна разъяснительная работа. Ну и поддержка руководства. Можно показать ему штрафы юр. лицам.
Совмещая ответы на 3 и 4 пункты - тебе поможет система GLPI

Бесплатное для некоммерческого использования - значит ровно то, что написано. Дома - пожалуйста, у юр. лица -нини. Убунту ставить можно, я не знаю где вы нашли такой пункт)

Много получилось, но и вопросы у вас глобальные)
Резюмируя - ищите себе поддержку в лице руководства. Без нее никак.

Просто банить ботов, с помощью fail2ban или CSF или чего угодно, хоть самописный скрипт + iptables.
Параллельно, естественно, не забывая поддерживать состояние защищенности своих сайтов.
Эти воображаемые "хакеры" в большинстве случаев - просто фоновый шум Интернета, толпы разнообразных ботов, сканирующих сети, подбирающих пароли к ssh, ищущие уязвимые сервисы, дефолтные и словарные пароли и т.п. Когда находится уязвимая жертва, чаще всего выполняется автоэксплойт, который подключает зараженный ресурс к армии ботов.
В качестве эксперимента, как уже выше предложили, можно развернуть honeypot на отдельном публичном ip (если есть в запасе), например вот готовый дистрибутив. Выставить голой задницей его в Интернет и наслаждать алертами honeypot-систем.

А "наказывать" этот фоновый шум, все равно, что высечь море.

цель: чтобы офис "lan A" и "lan B" были в одной сети.

Если имеется в виду, один IP-префикс ('подсеть') на оба сегмента, то вам нужно как-то растянуть L2-домен между маршрутизаторами, чтобы широковещательные запросы между сегментами A и B проходили (pseudowire и прочая).

Сейчас по факту префиксы на lan A и lan B завешаны разные (я подразумеваю /24 маску). Если все-таки необходима доступность машин в разных префиксах (т.е. чтобы "пинги проходили"), то на mikrotik1 нужен маршрут до 192.168.1.0/24, next-hop 10.10.10.2; на mikrotik2 - маршрут до 192.168.6.0/24 next-hop 10.10.10.1. Необходимо также внести соответствующие поправки в настройки фаервола.

И чтобы при падении канала ПД по VPN PPTP поднимался резерв.

Если речь идет о том, что связь между сегментами lan A и lan B будет осуществляться через этот VPN, то надо будет на каждом mikrotik прописать статический маршрут, аналогичный предыдущему, но с худшей метрикой (и next-hop надо будет соответственно поменять).

Действительно, уважаемый. Это слишком. Вряд ли я затрону все тонкости, но попробую наметить примерный путь:

0) Пользователь вбивает в адресную строку браузера адрес сайта (нажимая клавиши на клавиатуре, которые замыкают определённую дорожку в матрице, по которой происходит определение нажатой клавиши, что через шину USB в какой-то момент передастся OS, где это поймает HID-драйвер и вызовет определённое прерывание, что OS передаст как событие/или_ещё_как в программу, которая вызовет соотвествующую функцию из API менеджера окон, которая изменит содержимое строки и в результате когда-то будет перерисован UI-элемент, а если нажат был Enter, то начнётся следующее).
1) Браузер вытащит из input'а строку с запросом и посмотрит, похоже ли это на адрес. Если да, то добавит недостающие уточнения (например, http или file протокол, порт и подобные довольно стандартные вещи). Если нет - то скорее всего создаст запрос в поисковую систему, установленную по умолчанию (я более не буду опускаться до таких бессмысленных деталей, как вызовы API-функций, иначе я буду набирать это сообщение ОЧЕНЬ долго). В любом случае на выходе мы по сути получим URL, который надо загрузить. Протокол file:// мы рассматривать не будем, ftp далеко не везде есть, https:// на не хватит вечности, так что остановимся на http, который по сути есть tcp/ip по умолчанию на 80 порту с определённым форматом общения.
2) Окей, url есть. Теперь нам нужен адрес, к которому обращаться. Так как http это tcp/ip - нам нужен ip адрес. Здесь нам помогают dns-сервера. Обычно, нормальный провайдер устанавливает у себя кэш-сервера dns, которые не обращаются по стопицот раз за vk.com к ответственному серверу com-зоны. Давайте не будем отвлекаться на то, как происходит там общение, если что - вот (вики тем хороша, что часто содержит внизу релевантные ссылки). Скажу лишь то, что на выходе мы получаем ip адрес(а).
3) Имея адрес мы можем запросить страницу. Собственно, всё что после первого слэша - это как-бы параметры для http-сервера: какую именно страницу запрашивать, он всё же не телепат. Конечно, можно было бы немного схитрить и отправить читать про tcp/ip, но ведь существует и shared-hosting. Ограничемся лишь его упоминанием. Собственно, по полученному адресу отправляется GET запрос, который и обрабатывает сервер, находящийся по полученному IP-адресу.
4) Сервер же, получив адрес, начинает распарсивать строку, медленно вытягивая нужные данные из баз-данных и настроек, выполняются сотни скриптов, иногда делается ещё не одна сотня различных запросов на другие сервера (здесь и разного вида метрики и разного вида HADOOP и т.д.). Пройдя сквозь скрипты и темплейторы в самом конце мы получаем html-страницу, готовую к употреблению. Её-то сервер и отправит в ответе (после заголовков, конечно).
5) Вот и началось самое интересное. Получив html страницу браузер начинает жутко надругаться над CPU, HDD и GPU, попутно сжирая тонны RAM и мусоря в swap. Виной всему нереальные для полного соблюдения стандарты от небезызвестной w3c.org. Для облегчения многие делают костыли, вроде webkit, а некоторые и вовсе забивают на него и пилят свой стандарт с преферансом и картёжницами (впрочем, в последнее время становиться лучше). Здесь снова начинаются сотни вызовов API ОС, windows manager'а и прочих библиотек, вроде boost, qt или libpng. В ходе работы в RAM строится макет, по которому потом строится нечто вроде PDF (тоже сильно векторный), что, потом, обрабатываясь быстрыми шейдерами на GPU, выдаётся на экран. Опять же, многое пропущено, но вряд ли кому-либо, кроме парня в свитере с оленями, действительно интересно, как работает GDI, DirectX или OpenGL.
6) Ах да, мы же забыли про тысячи js-скриптов, миллионы картинок и анимации с котиками, а также о таких дополнительных плюшках, как flash-player или java-weblets. В кратце, что js, то и flash и java - это виртуалка, со специальной архитектурой. Они, виртуалки, конечно разные (хотя flash и js довольно похожи, ещё бы - ECMAScript один и тот же). JS - самый интегрированный внутрь браузера, он же и самый медленный чисто визуально (ибо последние два имеют доступ к быстрому GPU), хотя самый быстрый в попугаях. Второй постепенно вымирает и представляет из себя, так же как и третий специальную shared-библиотеку, о которой браузер как-нибудь узнал и которой скармливает специальное содержимое помечанное специальным тегом html. Третий уже почти умер и встречается лишь изредка или в каком-нибудь энтерпрайзед со страшным legacy-базой. Ну здесь из сылок разве только гугл. Ибо сколько всего - даже не сообразишь. Да и вообще, эта тема ещё скучнее GDI, DirectX и OpenGL и к свитеру с оленями требуются ещё очки с толстенными стёклами, дающие стопицот к терпению и задроству над матаном. Если в кратце, то в случае JS, всё что было загружено в память и не думает выгружаться и формирует этакое дерево - DOM, над которым с помощью специального API и происходят модификации. При этом, перед тем как исполниться, весь JS-код компилируется, в нативный для VM байт-код. То же самое в общем-то и со вторым и третьим, разве только они не имеют доступа к DOM и организовать его - дело тех ещё костылей. Ах да, забыл ещё про Silverlight (или как оно там пишется), который сдох, не успев родиться. Так же как и Java, жив в серьёзном энтерпрайзе, не поскупившийся не "дешёвую" поддержку MS.
7) Ну... А дальше пользователь нажимает на нужную гиперссылку и всё по новой.

За кадром остались такие костыли, как ajax, websockets и прочая асинхронная ересь. С ней всё в миллионы раз сложнее. И к очкам со свитером потребуется ещё и... а чёрт их знает, что они там ещё носят. Ну да ладно, я искренне завидую тем парням (и девушкам), которые разбираются во всей этой машине. Целиком. Ибо это лишь верхушка айсберга. Разбавленная не лучшей памятью и ужасным гуглом.

P.S. Не бейте сильно за грамматические и синтаксические ошибки. Спеллчекер приказал долго жить, да и 5 утра как никак.

UPDATE
На хабр выложили неплохой перевод дающий некоторое представление, как браузер ругается над памятью и процессором. Хотя и весьма поверхностное,

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

ClearOS, например. Из множества подобных, наиболее приятен, на мой вкус.
Установить проще, чем windows, удобный и понятный web-интерфейс.