Наблюдательское

Появились в блоге какие то комментарии. Не спам, вроде, то есть для чего нужны и кем пользуются непонятно. Чегой-то сомневаюсь я, что статьей 3-летней давности неожиданно куча народу заинтересовалась...

ProFTPD за NAT

Ситуация: рутер с установленной RouterOS версии 3.17, FTP сервер в DMZ зоне. Требуется доступ к FTP из интернета.
Обязательно использовать стандартный порт FTP сервера т.е. 21. В файрволе рутера делать проброс порта на сервер FTP. В этом случае рутерборд сам следит за тем чтобы соединения пробрасывались как в active, так и в passive режиме.
Если хочется можно использовать нестандартный порт. Тогда в конфигурации Proftpd необходимо использовать такие директивы как MasqueradeAddress (адрес, который отдается клиенту)и PassivePorts(диапазон портов, из которого выделяется адрес для подключения). На рутерборде надо прокинуть порты вручную. Видимо, в этом случае не срабатывают модули(точнее их аналоги) ip_nat_ftp и ip_conntrack_ftp. Однако, в этом варианте бывают плавающие глюки и работать так не рекомендуется.

Bacula, заметки на память

Данная заметка - черновик для себя, набросок. Если кому будет полезно - welcome!
Итак, задача - резервное копирование серверов.
Повыбирав из всех систем резервного копирования остановился на bacula - система гибкая, море возможностей, довольно удобна. Документации в сети довольно много, отличная документация есть на сайте программы, правда на английском языке.
Учитывая, что бэкапить надо сервера с Windows Server 2008 x64, а в репозитарии lenny версия 2.4, пришлось собирать собственную из исходников. Зато добился работы bat файлов перед бэкапом, что позволило делать копию system state средствами Windows, и забирать файлы используя VSS.
1. Общая информация о системе резервного копирования bacula.
Система резервного копирования Bacula состоит из 3 основных компонентов:
• Bacula Director – управляющий модуль. Ставится на сервер, отвечает практически за все возможные настройки. Занимается управлением системой т.е. расписанием, назначением уровня работ (полный, дифференциальный либо инкрементальный бэкап), распределением пулов и т.д. Конфигурационный файл bacula-dir.conf
• Bacula Storage Daemon – модуль описывающий устройство для хранения бэкапов. Сюда будут складываться бэкапы. Конфигурационный файл – bacula-sd.conf.
• Bacula File Daemon - модуль ставится на все машины, с которых надо делать бэкап. Конфигурационный файл на каждой машине свой – bacula-fd.conf.


2. Полезные и часто используемые команды
bconsole - Запуск консоли управления.
help – выводит все доступные команды консоли.
estimate – позволяет оценить размер передаваемых данных по работе, с дополнительной опцией listing – выводит список файлов, которые будут восстановлены.
status – выводит информацию о происходящем в системе (проще всего – status all).
run – позволяет запустить задание на выполнение.
restore – позволяет восстановить данные из бэкапа. Для восстановления задания целиком необходимо запускать restore all. Далее выбираем номер задания для восстановления и даем добро. По умолчанию путь для восстановления файлов - /home/archive/restore.


3. Файл bacula-dir.conf.
В этом файле описываются шаблоны заданий(jobdefs), задания, наборы файлов для бекапа, расписания заданий, клиенты контролируемые данным сервером, сервера хранения, пулы томов.

3.1 Основная кофигурация сервера управления

Director {
Name = test-server-dir # Имя сервера
DIRport = 9101 # порт который слушаем
QueryFile = "/etc/bacula/scripts/query.sql" # файлы запросов
WorkingDirectory = "/var/lib/bacula" # Рабочая директория
PidDirectory = "/var/run/bacula"
Maximum Concurrent Jobs = 1 # Максимальное количество одновременных заданий
Password = "testpwd" # Console password
}



3.2 Конфигурация шаблона для задания
Можно использовать те же параметры, что и в описании заданий.

JobDefs {
Name = "DefaultJob" # Имя шаблона
Type = Backup # Тип задания
Level = Full # Уровень бэкапа, данный означает бэкапить все файлы.
Client = test-fd # Клиент с которым работаем
}

3.3 Описание задания

Job {
Name = "test-backup" #Имя задания
JobDefs = "DefaultJob" #Имя шаблона
Client = Test #Клиент которого будем бэкапить
FileSet = "Test Set" #Набор файлов для сохранения
Pool = Test-pool #Имя пула для бэкапа
Schedule = "DailyBackup" #Имя расписания
Priority = 11 #Приоритет задания. Чем меньше, тем выше.
ClientRunBeforeJob = "c:/bacula.cmd" #Файл, запускаемый на клиенте, перед началом копирования
Write Bootstrap = "/var/lib/bacula/TEST.bsr" #Имя bootstrap файла. Если ляжет база mysql, с помощью этого файла можно будет поднять бэкап.
}

3.4 Наборы файлов, которые необходимо сохранять.
Разделяющий слэш всегда / даже для систем с Windows.

FileSet {
Name = "TEST Set"
Enable VSS = yes # Включает Volume Shadow Service, службу, которая делает снэпшот системы перед копированием. Позволяет, например, забэкапить базу данных при включенном сервере MSSQL.
Include {
Options {
Compression = gzip # Включает компрессию файлов
}
File = "e:/WindowsImageBackup"
}
}

3.5 Расписания заданий
Schedule {
Name = "DailyBackup" # Имя расписания
Run = Full mon-sat at 5:00 # Запускать каждый день недели, кроме воскресенья, в 5 утра
}

3.6 Описания клиентов, т.е. компьютеров с которых будет делаться бэкап

Client{
Name = TEST # Имя клиента
Address = 10.0.0.200 # IP-адрес или домнное имя клиента
FDPort = 9102 # Порт к которому подключаться
Catalog = MyCatalog # База данных с которой работаем
Password = "testpwd" # Пароль для подключения
File Retention = 30 days # Время хранения данных о файла в БД каталога
JobRetention = 6 months # Время хранения данных о заданиях в БД.
AutoPrune = yes # Автоматическое удаление старых записей.
}

3.7 Описание серверов хранения

Storage {
Name = File
# Do not use "localhost" here
Address = test-server # N.B. Use a fully qualified name here
SDPort = 9103
Password = "test"
Device = FileStorage # Имя устройства, на которое будем писать. Должно быть описано в bacula-sd.conf
Media Type = File
}

3.8 Описание пулов томов

Pool {
Name = Default
Pool Type = Backup # Тип пула
Recycle = yes # Использовать тома заново?
AutoPrune = yes # Удалять старые тома?
Volume Retention = 365 days # Время хранения тома перед его повторным использованием
Maximum Volume Bytes = 4500m # Максимальный размер тома
Label Format = "archive" # Метка тома
Purge Oldest Volume = yes #
Maximum Volumes = 30 #Максимальное количество томов
}

3.9 Описание формата отправки сообщений

Messages {
Name = Daemon
mailcommand = "/sbin/bsmtp -h 10.0.0.1 -f \"test@test.md\" -s \"Bacula daemon message\" %r"
mail = test@test.md = all, !skipped
console = all, !skipped, !saved
append = "/var/lib/bacula/log" = all, !skipped
}

4. Файл bacula-sd.conf
Файл конфигурации сервера хранения.
Storage {
Name = test-server-sd # Имя
SDPort = 9103 # порт, который слушает sd демон.
}
Далее кофигурация устройства хранения, т.е. бекапы сохраняются на диск, в файлы, которые находятся в директории /home/archive.
Device {
Name = FileStorage
Media Type = File
Archive Device = /home/archive
LabelMedia = yes; # lets Bacula label unlabeled media
Random Access = Yes;
AutomaticMount = yes; # when device opened, read it
RemovableMedia = no;
AlwaysOpen = no;
}

Бороться и искать, найти и перепрятать!

Возникла необходимость сделать собственную Wireless сеть. Причем не абы какую, а длинный линк, на 25 км. Договорились с поставщиками оборудования, взяли для теста антенн и всего прочего, затестили с хопа в две стороны - замечательно, 20 мБит и это не предел! Обрадовались, как оказывается рано...
Сеть наша не радио-релейная, а простой 802.11a, т.е. 5 ГГц. Частота нелицензируемая, общего гражданского пользования, но надо брать разрешение в ГосИнспекции по РадиоЧастотам (или хз как они там щас зовутся). Эти феерические долбое.., хм, парни отказали по очень простой причине. Оборудование с рабочей частотой в 5 ГГц относится к классу оборудования малого радиуса действия, по рекомендациям CEPT. А у нас радиус им видите ли большой... Причем определения малого радиуса нет, как и запретов на использование оборудования на больших дистанциях...
В общем совет радиолюбителям :) Молдовы - делайте втихаря!

Прокси-сервер со всеми удобствами

Новое время – новые цели и задачи. Возникла необходимость установить и настроить прокси сервер. Задача, казалось бы, тривиальная, однако в процессе её реализации обросла дополнительными функциями и возможностями, поэтому и решил описать её здесь. В сети есть гора материалов на данную тему, однако все они решают определенную проблему, а целостного комплексного решения найти так и не удалось.
Сначала было слово )) т.е. задание от технического директора, в котором от меня требовалось установить и настроить прокси. Однако в процессе обдумывания задачи захотелось всяческих удобств, типа редиректора, ведения красивых логов и т.д. В итоге пришли к такому решению: кэширующий прокси-сервер с авторизацией доменных пользователей, редиректором режущим рекламу и ограничением прав пользователей, антивирусный прокси, ведение логов в MySQL…
Начнем пожалуй, с выбора операционной системы. Не долго думая был поставлен мой любимый дистрибутив линукса – Debian, в его стабильном варианте, т.е. etch. Естественно можно было поставить что-то типа ClarkConnect, однако мы ведь не ищем легких путей? Тем более я больше люблю самосбор и полный контроль над системой ).
Пойдем дальше – прокси сервер. В мире Linux уже давно стандартом де-факто является Squid. Это мощнейший сервер, позволяющий решать практически все мыслимые и немыслимые задачи. Установка его описана в сотнях источников, и ничем сложным не является, набрать в консоли aptitude install squid, небольшая проблема для сурового системного администратора :-).
В качестве сервера баз данных был выбран MySQL, просто потому что я с ним работал раньше, и для текущих задач его хватает вполне.
Редиректором выступил отличная программа rejik (www.rejik.ru). В репозитариях Debian его, к сожалению, нет, однако он отлично ставится по инструкции, которую можно найти на сайте программы.
И наконец антивирусный прокси – HAVP (http://www.server-side.de/). Так же нет в репозитариях, так же отлично ставится по инструкции с сайта.
Ну и конечно антивирус – ClamAV.
Получившаяся в итоге схема работает отлично, пользователи ходят под своими доменными аккаунтами, на каждого ведется статистика и учёт трафика, проверяются проходящие файлы на вирусы, у каждого пользователя свои права на доступ к определенным сайтам.

ЗЫ
Если проявится интерес к данной заметке, распишу всё более подробно и размещу в блоге, пока это всего лишь примерное направление движения.

Объединение каналов или транкинг для самых маленьких.

Cегодняшней публикацией начну новую тему в своём блоге - сетестроительство.

В провайдинге довольно часто возникает ситуация, когда максимальной ширины канала начинает не хватать. Первая возникающая мысль - естественно о смене оборудования и расширении канала. Однако упереться можно и в гигабит... В такой ситуации на помощь приходят так называемые транки. Сначала разберемся, что же это такое.
Транк, по сути своей, это объединение нескольких физических портов коммутатора в 1 логический, который можно обозвать транком или транковым портом. Объединяются также скорости пропускания портов. То есть, мы можем объединить в транк 2 стомегабитных порта коммутатора, и получить 1 логический порт с пропускной способностью 200 мегабит!
Для создания транков используются специальные коммутаторы, поддерживающие данный режим работы и настройки. Естественно у каждого конкретного коммутатора они свои, и здесь мы не будем их рассматривать. Обычно необходимо просто создать транк, добавить в него нужные порты, и сделать то же самое на другом коммутаторе.
Также транки можно использовать для резервирования каналов. Делается это при помощи специального протокола, называемого LACP (Link Aggregation Control Protocol). Данный протокол следит за указанными портами, и автоматически добавляет, либо удаляет необходимые порты из транка. То есть, к примеру у вас есть 2 линии от 1 дома до другого. Порты этих линий при помощи LACP объединены в транк. При падении одной из линий, через определенный, настраиваемый интервал времени весь трафик пойдёт по другой линии. Связь не оборвется полностью, а лишь уменьшится скорость. Когда линк восстановится, порт автоматически включится в транк, и трафик вновь распрделится равномерно по 2 линиям.

Важные замечания:
1) При использовании статических транков, если оборвется один из линков, трафик не будет ходить через целый транк. По сути - оборвали 1 кабель = оборвали всё! Используйте LACP.
2) Советую использовать одинаковые скорости для линков входящих в транк. Не используйте Ethernet(100 Mb) и SHDSL(2 Mb) в одном транке, у вас не будет 102 мегабита! Трафик пускается в зависимости от мака в тот или иной физический порт. В данном примере у вас получится у 1 абонента 100 Mb, а у другого 2 ...
3) При прокладке кабелей на длинные дистанции старайтесь использовать разные кабельные трассы. Это увеличит вероятность того, что при физическом повреждении хоть один линк, да останется.
4) Часто транком также называется порт в который уходит тегированный траффик. Это произошло из-за синтаксиса коммутаторов Cisco. Об этом у нас ещё будет отдельный разговор. Не путайте их, эти транки совсем разные ;)

Данный пост написан основываясь на собственном опыте и не претедует на истину в последней инстанции. В общем если есть, что добавить или исправить - пишите! ;)

С чего бы это?

Итак. С работой разгрёбся, засел снова за любимую Ubuntu. Обновился до версии 7.10, и честно говоря остался недоволен...
Это, конечно, мелочи и придирки, но:
Перестал нормально работать framebuffer. В Grub передаю в ядро 0x31B, а оно не кажет ничего кроме картины Малевича. Когда уже X-ы стартуют нормально.
Ухудшилось отображение шрифтов. Да видно, что патчи уже наложены и сглаживание работает, но хуже стало, намного хуже...
С локализацией у Кубунту так и остались проблемы. Да, это не критично, но впечатление портит.

А вообще может у меня руки кривые, не разобрался ещё )))