Всем привет!
Давеча возникла необходимость упрятать некоторый сервис в DMZ. Сервис этот крутится в W2K3, и мне не хотелось чтобы машина с OS Windows смотрела в интернет и в локальную сеть ни чем незащищенная(«виндовые» фаерволы просто идут лесом).
Помянуя успешный опыт работы с Asus WL 520GU и DD-WRT, решил пойти по проторенной дороге, но в качестве прошивки для роутера выбрал OpenWRT.
Схему работы связки можно увидеть на рисунке.

Итак, от слов перейдем к делу.

Конечно же речь пойдет не о приготовлении всем известного японского деликатеса. А пойдет она о настройке нескольких сервисов, которые я определил для
себя как необходимые, на домашнем сервере. В качестве операционной системы которого будет выступать OpenBSD.
Многие воскликнут, а зачем тебе эта малоизвестная ОС, ведь есть же Linux, FreeBSD. Да, действительно, я мог бы настроить все необходимое и на других
unix like, но это бы не принесло мне столько удовольствия, сколько я испытал изучая и настраивая OpenBSD. Да и потом, меня всегда привлекают сложные
и нестандартные решения.
Закончим с вступлением и вернемся к теме заголовка.
Спешу представить тебе меню, уважаемый читатель.

Приветствую всех хаброжителей!

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

Думаю вполне резонным будет предположение, что данная тема уже набила оскомину, но все же я рискну поделиться своим опытом. На суд читателя будет представлена клиент-серверная реализация схемы резервного копирования. В качестве инструмента я выбрал open source проект Bacula. По более чем полугодовому опыту его использования остаюсь доволен своим выбором.

Bacula состоит из нескольких демонов, каждый из которых несет свою функциональную нагрузку. На рисунке ниже схематично представлена взаимосвязь этих демонов.

Под хабракатом я опишу все демоны подробно


В моем случае резервному копированию подлежат:

1. Конфигурационные файлы различных демонов со всех серверов.
2. MySQL базы данных.
3. Документооборот с файлового сервера Windows.
4. Различные важные данные с nix серверов(движки сайтов/форумов, etc..)

Книги.
Я считаю, что важнейшим инструментом получения скилов системного администрирования являются именно они — книги.
Нет специальных факультетов, обучающих «админству» — каждый постигает это самостоятельно. Путем проб, ошибок и боли, потере важных данных различных злоключений.
В начале пути сложно определиться, что же нужно прочесть — ведь массив информации столь огромен!
В данном посте я хочу собрать наиболее важные и значимые труды для системных администраторов.
Уклон будет на *nix админство, но, надеюсь тема окажется небезынтересной и для Windows коллег и в комметариях они заполнят мои пробелы.
Пост субьективен и отражает лишь мой собственный опыт — я раскажу о книгах, которые помогли моему становлению.

Введение.
Мне повезло работать в организации которая развивается, и время от времени возникают новые задачи, позволяющие и мне расти. На этот раз мне было необходимо объединить головной офис и второй филиал. Задача для меня не новая, но к её решению я решил подойти иначе нежели раньше.
На текущий момент в головном офисе установлена FreeBSD + mpd5 в качестве PPTP сервера. В первом филиале аналогично(за исключением того что используется как vpn клиент). Так же есть 8 точек где установлено по одному компьютеру с ОС Windows XP «цепляющихся» к головному стандартным клиентом этой ОС.
Мне необходимо создать еще один туннель между двумя сетями, но любимую ОС FreeBSD я использовать не могу, в силу ограниченного места для установки роутера во втором филиале(это магазин розничной торговли, все оборудование приютилось на узеньком стелаже). К тому же хотелось попробовать прошивку dd-wrt, о которой так много слышал, в деле.

Всем доброго времени суток!

Как видно из заголовка, речь пойдет о двух программах:
1. Open Computers and Software Inventory
OCS-Inventory основан на распределяемых модулях, устанавливаемых на инвентаризируемые машины, которые отсылают подробную информацию о системе, подключенных устройствах и установленном ПО в выделенную базу данных.
Поддерживаются следующие OS: Microsoft Windows, Linux, *BSD, Sun Solaris, IBM AIX, HP-UX, MacOS X

2. GPLI — Guestion Libre de Parc Informatique
Проект предназначен для работы с базой данных IT и телекоммуникационного оборудования, установленного на предприятии. Также имеется возможность ведения учета расходных материалов и организации службы технической поддержки по расписанию и по заявкам пользователей.

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

Казалось бы вещи, вынесенные в заголовок, достаточно тривиальны и описаны во множестве мест глобальной сети, но это только на первый взгляд. Опробовав наиболее часто встречающиеся советы я обнаружил несколько «подводных камней», глыб и даже скальных образований.

Но это все слова, ближе к делу.
Достаточно распространенная ситуация — Asterisk внутри ЛКС, за маршрутизатором MikroTik.
Дабы выделить трафик сервера, где установлена PBX, администратор отрезает часть канала провайдера выделяя его исключительно для конкретного IP.
Или другая реализация, когда нужный трафик определяется не только по IP-адресу PBX, но и по размеру пакетов и протоколу.
Попробовали — работает. Можно забыть? А вот и нет.

Что если администратору захочется слить что-то из Интернет находясь в консольке сервера, или наоборот отправить куда-либо в Интернет большое количество траффика? Правильно — он приоритезируется на MikroTik так же как и полезный трафик от PBX, что в итоге приведет к проблемам с IP-телефонией.

Решение здесь старо как сам IPv4 — метить трафик на сервере с Asterisk генерируемый только ею, и так, чтобы MikroTik это мог «увидеть», отматчить(простите за столь грубый англицизм) и приоритезировать только его.

Следующим пунктом у нас идет резервирование каналов от двух интернет-провайдеров.
Думаю что каждому системному администратору, использующему в своем хозяйстве маршрутизаторы MikroTik, знаком скрипт из wiki — wiki.mikrotik.com/wiki/Failover_Scripting
Он всем хорош, но как и в предыдущей ситуации есть ряд «но».
Наиболее весомому из них имя «Connection tracking» и заключается оно вот в чем:
когда наш основной ISP изволит отдохнуть от трудов праведных, траффик переключается на резервного.

Все вроде бы довольны, ютуб работает, яп тоже, но сколько бы мы не кричали экспекто потронум

sip reload

и в отчаянии не пытались применить магию высших порядков

core restart now

SIP-регистрации не поднимаются.

А дело в том, что в механизме «Connection tracking» остались висеть записи от «старого»(основного) интернет-канала и их нужно удалить, после чего регистрации успешно поднимутся и звонки начнут проходить.

Если вам интересно как доказать MikroTik'у кто все-таки верблюд, а так же как автоматизировать в скрипте сброс «старых» соединений, то вам прямо под кат.

Я работаю инженером технической поддержки в ISP. В статье поделюсь опытом построения корпоративной сети со статической маршрутизацией и резервированием каналов связи, а также автоматическим информированием об аварии на email, при ограниченном бюджете для торговой сети магазинов. Для опытных сетевых инженеров статья вряд ли будет интересной. Для админов, которым поставлена подобная задача, данная статья может пригодиться.

Считаю, что динамическая маршрутизация именно в данной задаче работала бы не так быстро и вероятно надежно, как того требует проект. Ничего не имею против динамической маршрутизации, но негативные отзывы о работе ее на оборудовании MikroTik и некоторая специфика сети (об этом ниже), повлияли на выбор в сторону статики и скриптов.