Системное администрирование *

Вторая часть статьи об управлении трафиком в Linux. В статье приведены примеры приоретизации трафика (QoS) и рассказано об использовании hash таблиц при фильтрации трафика (fast hash tables), использование которых позволяет существенно увеличить производительность.

Наверняка многие использовали для записи сессий командной строки программу script.
А кто-нибудь задавался вопросом, а можно ли использовать её в рамках повышения безопасности/мониторинга/проверки адекватности пользователей системы?
Любопытства ради решил прикрутить script ко всем пользователям системы и посмотреть, что из этого выйдет…

Под катом описано как шейпировать трафик в Linux и что для этого нужно знать.

Вот такой вот шарфик нашел утром в интернетах:

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

Телевизор я не смотрю, возможно, там этот вопрос подробно обсуждается уже давно, но лично для меня эта информация в начале этой недели стала новостью.
До недавнего времени я был уверен, что идея с сокращением числа часовых поясов в России до 5 штук — это просто чьё-то неудачное предложение или очередной бредовый законопроект, который обязательно будет отвергнут и далее обсуждений не пройдёт. Однако, оказывается, все решения на этот счёт «у них там наверху» уже приняты и соответствующие постановления Правительства уже подписаны (В.Путиным) и опубликованы.
Постановление по Кемеровской области было подписано ещё осенью 2009 года, а постановления по Самарской области, Удмуртии, Камчатке и Чукотке были подписаны буквально на днях.



Далее рассмотрим когда и как именно будет происходить этот переход, кого это коснётся, чего от этого ждать и как к этому готовиться с точки зрения администрирования IT-инфраструктуры.

Сегодня меня заинтересовал опрос надо ли перевешивать SSH на нестандартный порт. Сам опрос не так интересен как способ автора zivot_je_cudo защищать SSH от подбора пароля: после неверной попытки подключения блокировать новые попытки в течение 20 секунд. Задержка, видимо, выбрана эмпирически, исходя их двух противположных пожеланий: чтобы не заблокировать в случае опечатки себя надолго, и в тоже время усложнить жизнь подбиральщика. Я хочу поделиться своим способом противодействия брут-форсу, который применяю уже несколько лет. Он имеет два преимущества:
— дает мне больше попыток для набора правильного пароля
— но при этом блокирует брутфорсеров «навечно».

Как можно достичь этих двух противоположных целей?

 

Иногда проснувшись утром отчетливо понимаешь — что то не так. Хотя ты побрился и даже ни разу не порезался, кофе не выкипел, на улице солнечное утро, добрался до работы быстро и без приключений, вроде бы все хорошо, а все равно что то не так. Но войдя в офис ты видишь общую панику, истеричные вопли, о том, что все пропало и «весь офисный планктон» умрет, а ты находишься во главе тех кто погибнет.
Оказывается ночью отказали файловый и почтовый серверы. И тут понимаешь, что не с проста утро началось так хорошо. Работы предстоит достаточно, но данные надежно сохранены, ибо ты позаботился об их резервном копировании.

Наступило время Chef 0.8.8, и большая новость, связанная с этим выпуском: мы исправили ошибку с ресурсом remote_directory, который был сломан для пользователей утилиты Chef Solo. Извините, ребята — мы добавили тесты, чтобы быть уверенными, что эта ошибка не проявится в будущем. Особое спасибо Джейсону Дюсеку, Михаилу Клишину и Дмитрию Дзёме за отчёт об ошибке и помощь в её исправлении.

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

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

Dklab vzfirewall — это утилита для OpenVZ, позволяющая конфигурировать firewall без утомительного ввода iptables-правил и без «завязки» на множество IP-адресов виртуальных машин. Главный принцип утилиты — быть настолько простой в использовании, насколько это возможно. Цель, которую я преследовал при создании утилиты, — избавить системного администратора от головной боли, связанной с конфигурированием iptables; надеюсь, у меня это хоть немного получилось.

^{Конечно, я понимаю, что вам может быть страшновато пробовать vzfirewall сразу на продакшен-сервере. Наверняка забудете какие-то порты открыть из нужных. Поэтому хороший момент, когда удобно «пощупать» vzfirewall, — это в момент установки нового сервера с OpenVZ (ну или на дев-сервере). Вот тогда-то уж можно развернуться.}

Примеры

Листинг 0: Установка

cd /usr/sbin
wget http://github.com/DmitryKoterov/vzfirewall/raw/master/vzfirewall
chmod +x vzfirewall

Листинг 1: Файл /etc/sysconfig/vz-scripts/101.conf

После недавней вводной публикации о Chef я решил немного больше рассказать о полезных рецептах:

Недавно возникла задача установки дистрибутива Linux на парк из 15 машин. Наиболее автоматизируемым методом такой установки является установка по сети. Как таковой этой задаче посвящено множество руководств, для нее имеются средства как специфичные для каждого дистрибутива (debian-installer, kickstart), так и универсальные (CloneZilla, System Installer). В данной статье я хочу написать о том, как при решении этой задачи добиться того, чтобы каждой машине было присвоено имя компьютера в формате pcNN, где NN — это числа по порядку от 01 до 99, в моем решении это будет последние два десятичных разряда из IP-адреса. Погуглив на эту тему я не нашел готового ответа, поэтому покопавшись в руководстве к DHCP серверу нашел решение и решил поделиться им с хабрасообществом.

В этой статье я расскажу вам о сервере службы каталогов 389 Directory Server (он же Fedora Directory Server, он же Redhat Directory Server). Так уж повелось, что для доступа к серверу каталогов используется протокол LDAP. Если вы не работали с LDAP, я очень рекомендую ознакомиться со статьями в Wikipedia (тут про cлужбу каталогов, а тут про протокол LDAP).

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

Казалось бы, вполне логичен вопрос: а почему именно LDAP? Что мешает хранить учетные записи в MySQL или PostgreSQL? Ответ очевиден — ничего =)

Но над любой RDBMS служба каталогов обладает целым рядом преимуществ:

• Это стандарт. Многие приложения поддерживают аутентификацию/авторизацию через LDAP;
• Данные хранятся как иерархическое дерево, что позволяет делать эффективные операции поиска, выделив нужную часть дерева;
• Число операций чтения в тысячи раз превышают число операций записи, в связи с этим появляется огромное число плюсов: нет необходимости применения транзакций и rollback'ов, репликация работает без проблем, которые присущи RDBMS;
• Приложение должно видеть одну и ту же информацию на всех серверах службы каталогов, если сервер не хранит информацию, нужную клиентскому приложению, он может сам запросить ее у другого сервера или перенаправить само приложение к другому серверу;
• Из-за описанных выше свойств службы каталогов, этот сервис отлично масштабируется горизонтально.

Выбор сервера службы каталогов пал на 389 Directory Server. История этого LDAP сервера тесно связана с компанией Netscape (если интересно, почитать историю можно тут).

UPDATE: Так как все это писалось давно, то смысл использовать скрипты сильно теряется, осталось ради истории.
Все можно и наверно лучше настроить через inadyn.
Синтаксис файла конфигурации примерно такой:

dyndns_system ipv6tb@he.net
username es1125cc87b23bfe1f3ba8923ca7f2ee
password PASS-WORD
alias 10220

На Habrahabr уже существуют статьи по настройке IPv6, например тут и тут. и тут
Сам я рекомендую почитать version6, там примеры зачем это надо.

Я же решил сделать процесс поднятие туннеля более универсальным и автоматизированным…
Для этого я написал два простых скрипта, но ..., давайте по порядку.

Ваша компания медленно, но верно выходит из кризиса, открываются новые офисы или магазины, появляются рабочие места — растет количество сотрудников. Вы, как системный администратор, уже позаботились об этом заранее и внедрили Active Directory или LDAP. Фух, проблем с учетками больше нет.
Но в нашем деле проблемы не заставляют себя долго ждать: вчера взяли пять бухгалтеров, троих продавцов и кладовщика. Всем нужна корпоративная электропочта. Отлично, если вы продумали достаточное количество ходов наперед и вместе с установкой AD перевели авторизацию почтосервера на домен. Тратим пять минут на добавление учеток, вписываем правильные данные, отдаем вашим помошникам — они настроят почтоклиенты этим сотрудникам. Но как теперь сообщить новые адреса всем остальным сотрудникам? Написать каждому письмо? Скинуть в чат? Слишком много работы для среднестатистического и вечно ленящегося сисадмина.

Я вижу два удобных пути решения: можно уговорить почтоклиенты бегать в AD за адресами, а можно показывать их на корпоративном сайте. Сегодня мы попробуем обеспечить корпоративный веб-сайт нужной информацией — будем выводить список сотрудников и их почтовые адреса, а за данными ходить к участковому прямо в Active Directory.

Нередко перед системными администраторами встает задача оповещения себя и коллег о каких-либо событиях на сервере, будь то отчет об успешных входах по ssh, резко возросшая нагрузка, падение сервиса, сообщение о переключении на резервное питание или вскипевшем чайнике.
Чаще всего такая задача решается, например, отправкой почтового сообщения. Но нельзя гарантировать, что сообщение, во-первых, прийдет вовремя, а во-вторых, что его сразу прочтут. Тогда, подумает администратор, будем использовать IM. Но как? Держать, например, centerim постоянно открытым в screen? Согласитесь, не самый радужный вариант.
На выручку к нам спешит чип и дейл открытый протокол XMPP. Написано множество расширений к популярным языкам и примеров кода, позволяющих отослать сообщение кому требуется, и отослать его быстро.
Пример такого кода я и приведу.

Началось строительство FTTB и появилось новое оборудование производителя Edge-core. Естественно захотелось прикрутить новое железо к Zabbix. Ранее я поступал просто — натравливал snmpwalk на железку и анализировал полученные данные. Этот путь достаточно долгий, так как полученный результат бывает под несколько мегабайт текста и достаточно тяжело найти нужные значения. Но есть другой способ — использовать MIB устройства. Но ведь Zabbix не умеет работать напрямую с MIB файлами. Что же делать?
На форуме забикса нашел замечательную утилиту SNMP Builder for Zabbix. С её помощью можно сделать базовый шаблон устройства имея его MIB и потом ручками его допилить до нормального состояния.
Я вам расскажу как это сделать на примере оборудования Edge-core.

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

Вы уже используете runit на своих серверах? Теперь у Вас есть возможность наблюдать за состоянием сервисов и управлять ими через минималистичный Web-интерфейс.


Для работы этой утилиты Вам нужно поставить ruby и rubygems, и затем выполнить
gem install runit-man thin