Под катом будет рассказано о настройке отказоустойчивого кластера, для запуска биллинговой системы NetUР UTM5, настройке шифрования и резервного копирования «ценных» данных.

1. Постановка задачи

Дано
Debian-сервер «из коробки» (установлен из дистрибутива)

Задача
Организовать работу нескольких проектов на сервере, чтобы люди, которые ими занимаются, не имели доступа к соседним проектам:

• Ограничить возможность обзора файловой системы определенной папкой для пользователя проекта.
• Ограничить возможность запуска бинарников пользователями
• Ограничить возможность открытия портов на сервере (нужно как-то по другому сформулировать)
• Автоматизировать добавление пользователя в систему: создание папки, конфига apache, пользователей mysql или postgres

В свете последних событий с torrents.ru и активизации государственных группировокорганов по борьбе с пиратством, думаю многие задумались как же обезопасить себя или свой сервер на случай если придут нежданные «гости». Вот и мне подвернулась задача защитить локальный медиасервер от посягательств, проведя пару дней за гугленнием и чтением мануалов/howto — мне удалось это реализовать. Скажу сразу, статей по шифрованию очень много, но в основном они рассчитаны на шифрование только определенных разделов, либо устарели/содержат много ошибок.

ЦЕЛИ:

1. Весь винт(винты) должны быть надежно зашифрованы
2. На винтах не должно быть абсолютно никакой разбивки, так как будто это новый(или стертый) винт
3. ОС должна стоять на зашифрованных разделах
4. Должна быть возможность увеличения дискового пространства, путем добавления новых винтов
5. Загрузка системы без ввода ключа от шифрованных данных

Продолжаем ставить Xen на Ubuntu.
Часть первая

В комментариях к топику Системное администрирование. Начало. прочитал, что сообществу были бы интересны статьи о виртуализации. Довольно давно у меня на жёстком диске лежит описание процесса установки Xen hypervisor и гостевой ОС на сервер под управлением Ubuntu/Debian.

Трафик проходящий по витой паре может быть прослушан абсолютно незаметно для участников соединения.
В этом посте будет показано как изготовить автономный сниффер с возможностью сохранения дампа на диск и управляемый по Wi-Fi.

По следам неудачной попытки с serverloft.eu я решил опубликовать своё руководство по установке FreeBSD на арендованный сервер c Linux.

Почему, собственно, я выбрал serverloft.com? За 100$ в месяц безо всяких VAT я получил брэндовый стоечный сервер в Германии (хоть и Fujitsu-Siemens), 100Гб места на ftp под бэкапы. Из приятных особенностей — в панели управления сервером есть запуск Linux rescue console (RIPLinux через PXE), им мы и воспользуемся. И так, пошаговое руководство по автоматической установке FreeBSD поверх Линукса.

Решил я найти для себя сервис, позволяющий хранить GPS треки путешествий и прогулок, просто рисовать на карте маршруты будущих поездок и делиться ими с друзьями. Из требований — привязка фото к маршруту, различная статистика по поездке, возможность рисовать маршруты в браузере. Обязательно — загрузка треков в формате GPX или NMEA, приятным бонусом было бы наличие приложения для iPhone.
Перебрав достаточно много подобных сервисов — решил выделить три (хорошее число, да) наиболее интересных и многофункциональных, обзор этих сервисов я и хочу представить вашему вниманию.

Повсеместное распространение NAT казалось препятствует свободному обмену трафиком между компьютерами, находящимися за одним из них, и практически делает это невозможным, если оба компьютера скрыты за разными NAT серверами, естественно если вы не администратор обоих NAT серверов. Однако Samy Kamkar легко и непринужденно не только преодолел это, но и сделал программу которая позволяет преодолевать подобные препятствия. В настоящее время данная программа доступна только пользователям *nix подобных систем.

Pwnat — этот инструмент позволяет любому количеству клиентов, находящихся за одним NAT-сервером, соединяться с сервером стоящим за другим NAT, при этом никакой проброски портов на серверах не требуется и никаких прочих инструментов не используется. Серверу не надо ничего знать о клиенте который с ним соединяется. Проще говоря это такой прокси сервер, который стоит за одним NAT и работает с клиентами, стоящими за другим NAT, между ними нет никакого дополнительного посредника, никаких DNS-фокусов и никакого пива админам. Скажу честно — я тоже в это сначала не поверил.

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

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

В настоящее время набирает популярность способ шифрования javascript на сайтах с помощью вложенных команд eval. Недавно я столкнулся с таким шифрованием на файловом хостинге mediafire.com. Шифрование было необычное, меня это заинтересовало и я решил понять, насколько хорошо данный метод работает.

Сайт mediafire.com позволяет скачивать файлы без каптчи и при этом, с недавнего времени, стал достаточно успешно защищаться от всевозможных автоматических роботов. Делает он это с помощью встроенного генератора кода javascript. Причем, код каждый раз создается новый, что затрудняет его эмуляцию автоматическими средствами.

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

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

Полностью автоматизированный инструмент проверки безопасности ваших веб приложений от Google. Основные возможности:

высочайшая скорость: написан на C, оптимизированные HTTP запросы, минимальные требования к CPU — скорость запросов легко достигает 2000 в секунду.

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

отличная логика безопасности: высокое качество работы, различные способы проверки безопасности.

Поддерживаются операционные системы — Linux, FreeBSD, MacOS X и Windows (требуется Cygwin).

Google skipfish

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 я решил немного больше рассказать о полезных рецептах:

Давайте каждый попробует ответить на вопрос: как установить apache на сервер? Этот вопрос порождает ещё десяток: какая ОС стоит на сервере, какую версию ставить, где лежат конфиги по-умолчанию и т.д. и т.п.

А теперь давайте попробуем ответить на вопрос: как установить apache на 1000 серверов? Тут, при стандартном подходе, вопросов возникнет ровно в 1000 раз больше. Часть из вас наверняка подумали, что можно написать скрипт на shell/perl/python/ruby, который будет обходить все сервера и устанавливать apache, другая часть подумала о distributed shell'ах (PDsh, dsh, etc), кто-то же подумал монтировать rootfs серверов по NFS.

В ряде случаев выше предложенные варианты решений удовлетворительны, но на практике я нигде не видел полностью гомогенных систем (зачастую, внутри компании можно встретить не только разные версии ОС, но и различные дистрибутивы. Также в России/СНГ очень распространена каша из FreeBSD/Linux в ядре проектов), так что вряд ли за адекватное время будет возможно написать скрипт, который установит и настроит apache на зоопарке в 1000 машин под CentOS, Debian, Ubuntu, FreeBSD всевозможных версий.

По моим наблюдениям, очень мало IT подразделений, даже очень крупных компаниий, используют в своей работе SCM (Software Configuration Management). В этом посте я постараюсь описать все преимущества использования Chef в IT инфраструктуре на простых примерах и больших масштабах.

Если же, после столь короткого вступления, вы не прониклись идеей Chef, да и времени читать длинный технический пост у вас нет, то рекомендую вам пролистать до конца и посмотреть как используем Chef мы, Engine Yard, 37signals и подумать, можете ли вы переложить на него часть своей работы.

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

Передо мной возникла необходимость настроить резервное копирование на новом Linux-сервере, задачка эта оочень важная, но уж больно скучная: нужно написать и отладить скрипты, которые будут архивировать нужные папки (причем желательно делать инкрементальные архивы), базы данных, хранилища subversion, а затем переносить эти архивы на удаленный сервер. По этому я попробовал нагуглить готовое решение для этой задачки и в результате наткнулся на backup-manager — замечательный опенсорсный набор bash-скриптов, позволяющих:

• архивировать любые папки, в том числе и создавать инкрементальные архивы. В конфиге просто указывается список директорий, которые должны быть скопированы, а также «черный список» файлов, которые копироваться не будут.
• делать резервное копирование баз данных MySQL. В конфиге указываются логин и пароль mysql-юзера, имеющего доступ к базам, а всю остальную работу backup-manager делает сам.
• делать резервное копирование svn-репозиториев, причем бэкап делается не копированием папки с хранилищем, а с помощью команды svnadmin dump.
• шифровать архивы.
• копировать созданные архивы на удаленные сервера по FTP, SSH или (это самая важная для меня фича) в хранилище Amazon S3, а также записывать их на DVD.

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

По просьбе уважаемого Nesmit'а публикую его HOW-TO, заместо своего, т.к. считаю что его инструкция достойна бОльшего внимания чем моя, которая была в этом посте, в моей было много недоработок и ошибок. И понапрасну его статью не пускали в ленту. Очень хорошая статья. Вот и она

ubuntu 9.10, с целью обновиться до 10.04, ничего не трогая.
pptpd 1.3.4-2
freeradius2.1.0
abills 0.5
dictionary.microsoft

Разработчик биллинга находится здесь: abills.net.ua
Хотелось бы выразить большую благодарность разработчикам данного биллинга!

Цели:
1.Обеспечить интернетом локальную сеть.
2.Учет трафика
3.Учет финансов
4.Создание тарифных планов.
5.Ограничение по скорости
6.Шифрование 128bit, причин много.
7.Без шифрования, но используя mschapv2.
8.Шифрование личного кабинета (apache SSL)
9.Возможность модернизации: интеграция почтового сервера с биллингом и т.д. Есть много модулей платных и нет.

Условия

Мы используем MySQL для хранения любых данных FriendFeed. Наша база данных растёт вместе с числом пользователей. Сейчас у нас более 250 миллионов записей, это записи пользователей (post'ы), комментарии, оценки («likes»)

По мере того как росла база данных, мы время от времени имели дело с проблемами масштабируемости. Мы решали проблемы стандартными путями: slave-сервера, используемые только для чтения, memcache для увеличения пропускной способности чтения и секционирование для увеличения пропускной способности записи. Однако, по мере роста, использованные методы масштабируемости привели к затруднению добавлению новой функциональности.

В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов. Удаление старых индексов требовало времени, а не удаление ударяло по производительности, так как база данных продолжала использовать их на каждом INSERT. Существуют сложные процедуры с помощью которых можно обойти эти проблемы (например создание нового индекса на slave-сервере, и последующий обмен местами master'a и slave), однако эти процедуры настолько тяжелые и опасные, что они окончательно лишили нас желания добавлять что-то новое, требующее изменение схемы или индекса. А так как наши базы сильно распределены, реляционные вещи MySQL как например JOIN никогда не работали для нас. Тогда мы решили поискать решение проблем, лежащее вне реляционных баз данных.

Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами. В тестах о которых мы читали и прогоняли сами, ни один из проектов не показал себя стабильным, достаточно зрелым для наших целей (см. this somewhat outdated article on CouchDB, например). А все это время MySQL работал. Он не портил данные. Репликация работала. Мы уже в достаточной мере понимали все его узкие места. Нам нравился MySQL именно как хранилище, вне реляционных шаблонов.

Все взвесив, мы решили создать систему хранения данных без схемы поверх MySQL, вместо использования полностью нового решения. В этой статье я попытаюсь описать основные детали системы. Так же нам любопытно как другие сайты решили эти проблемы. Ну и мы думаем, что наша работа будет полезна другим разработчикам.

Vuurmuur — за таким «кошачьим» именем скрывается довольно мощная GUI надстройка для iptables. Основным отличием от других iptables-надстроек является наличие консольного интерфейса написанного на Ncurses. Поэтому администрирование всё также легко возможно посредством SSH или консоли. Vuurmuur умеет работать с шейпингом, поддерживает функции мониторинга трафика, ведёт отдельные логи, прекрасно работает как на 2.4 так и на 2.6 ядрах и даже «говорит» на русском.