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

Статья рассказывает об организации отказоустойчивого файлового сервера на базе пакета Samba. Для понимая материала нужно иметь общее представление об администрировании ОС Linux, а также иметь опыт работы с обычной версией Samba.



Samba – это сервис CIFS, разработанный для того чтобы обеспечить семантику протокола CIFS (и соответственно доступ с машин под управлением Windows) к среде, использующей POSIX файловую систему. Основная функция Samba – преобразовать богатую семантику, которую используют клиенты на базе Windows к значительно более бедной семантике файловой системы POSIX.

Доброго времени суток, уважаемые пользователи Хабра!

Случилось так, что появилась необходимость добавить оперативки в старый добрый HP Proliant 150 G2. К слову, в нем уже были установлены 2 модуля по 1ГБ памяти. Я был наслышан о проблемах с совместимостью «родных» и «неродных» модулей, однако проблему нужно было решать и ждать поставки было невозможно.

Уже давным давно по интернетам ходят ссылки на мифические тонкие клиенты по 50-60-70 баксов. Мол, если есть такие, зачем по $200-$500? Более того, несколько компаний у нас в стране их пытаются продавать, и даже двигают на рынок с привлечением тяжёлой артиллерии в форме презентаций, бесплатных фуршетов и роадшоу.

Итак, сначала рыночно-историческая часть, а потом подробно техническая.

История

Была фирма, ncomputing. И изобрела она свой путь изготовления терминальных решений. Подчёркиваю, решений, а не тонких клиентов. Про него подробнее во второй части. Это изобретение было не такое уж дешёвое — под $150. Состояло оно из железа и софта. Софт шёл «как бы бесплатно» (точнее, с железками шла лицензия для них в софт). Но ушлые китайцы… произвели творческое осмысление и сделали своё. Главное, что своего сервера они не написали, а вместо этого банальным образом хакнули старую версию софта. То, что продаётся по $50-70 — это оно. Без техсаппорта, без обновлений (а они ой как там нужны), с ломанной версией критически важной для работы программы. Другими словами, типичные музыкальные центры panafonic и sonny, спортивная одежда от pyma и riibook. Та самая «китайская подделка», от имиджа которой стремятся уйти китайцы.

Впрочем, куда интереснее посмотреть на сам ncomputing, потому что это действительно НЕ RDP, это НЕ цитрикс, и у них ВСЁ своё.

Техническая часть

Понадобилось реализовать управление выдачей IP в сети одного провайдера, увязав его с системой учёта и прочими «фишками». В качестве DHCP сервера стоял ISC DHCP 4.x на 9-м Ubuntu Server'е.

Для DHCPd нужно было реализовать:

1. добавление новой статичной резервации (по маку либо порту свитча — опция 82),
2. «привязка» юзера с IP выданным динамически (то есть из пула свободных IP) в статичную резервацию
3. удаление статичной резервации
4. удаление динамической лизы до истечения срока резервации
5. Различные отчёты по подсетям, мак-адресам, свободным и занятым аресам

Хочу поделиться информацией, собранной в процессе реализации, на какие подводные камни наткнулся, как обходил, что так и не обошёл. Возможно кому-то сэкономит несколько часов времени.

 

Чуть раньше я писал про тонкие клиенты. Мол, зачем они нужны, кому они нужны и какой с них прок.

А теперь немного грустной правды о том, что есть тонкий клиент на самом деле.

Сколько бы не завывали маркетологи про особые свойства ТК, это просто компьютер. Зачастую с обычным биосом, в котором вы можете взять и загрузить свою ОС. В особо запущенных случаях вам придётся к этой ОС собрать особое ядро или играться с параметрами ядра, но обычно — это просто компьютер. В формате mini-itx или меньше. Без вентиляторов. Такие компьютеры до выхода Атома были экзотикой, с момента появления Атома — практически «компьютер как компьютер», только меньше.

Я не видел ни одного мейнстрим производителя, который бы делал тонкие клиенты примерно так, как делают принт-сервера (очень специальная плата, минимум лишнего...). Основная причина состоит в том, что тонкий клиент, хоть и является dumb terminal с логической точки зрения, на самом деле должен обладать очень и очень приличной производительностью.

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

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

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

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



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

В этом топике расскажу как можно в пару скриптов наладить простой сбор статистики по аномальной активности в сети.

Аномальным для нас будет на момент снятия статистики:

1. Более 20 исходящих коннектов по 25 порту с 1 IP.
2. Более 100 исходящих коннектов по 80 порту с 1 IP.
3. Более 100 исходящих коннектов по 53 порту с 1 IP.
4. Придумывайте сами, всё гибко.

Статистику будем вынимать из кэша netflow маршрутизаторов. Будет ли это Cisco или FreeBSD — не важно. О настройке netflow на FreeBSD я рассказывал в предыдущих своих статьях.

Я устал испытывать определённые опасения за сохранность данных на выделенном сервере, наблюдая за происходящим у хостеров последнее время… 3FN, Agava, Hosting.UA, МакХост — тенденция получается очень нехорошая.

В итоге, МакХост стал последней каплей, и, чтобы не оказаться в числе тех, кто «уже делает бекапы», я перевёл систему бекапов своего сервера на Amazon S3. Получилось вполне себе быстро и прозрачно.

Хочу поделиться с общественностью простейшей реализацией.

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

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