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

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

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

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

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


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

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

Фантастика. В общем, в далеком прошлом существовала некая сверхцивилизация, уровень развития которой на основе интернета, техники и биологии позволил объединить людей в единую информационную сеть не требуя никаких дополнительных интерфейсов. Определенная перенастройка биологической структуры мозга, причем в конечном итоге включенная в ДНК и передаваемая по наследству, Вроде нынешнего Wi-Fi, но приемник и передатчик построены на синапсах и аксонах. Каждый обладатель такого усовершенствования имеет возможность непрерывной связи с ретрансляторами сети, пользуется их информационными и другими возможностями.

Вот и мне посчастливилось познакомиться с git. Каюсь, пользуясь Subversion, я знал, как в IDEA или TortoiseSVN сделать то, что мне надо, но даже не представлял, что происходит за сценой. В данном случае я решил подойти к git более ответственно и хорошенько изучить его перед использованием. Сейчас я знаю какие команды надо использовать для выполнения задуманного, но не знаю, как это сделать в IDEA или TortoiseSVN.
Но я решил пойти еще дальше и узнать, что происходит в самой директории .git. Там оказалось все настолько интересно и просто, что я решил поделиться этим с вами.

Введение

Эта статья – скорее из разряда «для самых маленьких», чем «для умудренных опытом», но она призвана повышать профессиональную культуру системных администраторов.
В силу специфики работы мне «по наследству» достается самый разнообразный облачный ад, который приходится разгребать, оптимизировать, приводить в чувство и делать прозрачным и красивым. Эти заметки, пожалуй, иллюстрация к тем моментам, которые вообще недопустимы в системном администрировании.
В причинах, которыми порождаются эти анти-паттерны, можно разбираться очень долго: дедлайны, законы и темпы бизнеса, да и просто идиотизм, наконец. Но цель статьи другая. Мне бы хотелось породить конструктивную дискуссию. А вот уже её результаты и являются основной целью статьи.

Скорость работы вашего сайта, его стабильность и отказоустойчивость всегда зависят от трех составляющих:

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

Зачастую веб-разработчик может написать хороший качественный код, но при этом мало что смыслит в системном администрировании и настройке серверов. А хороший сисадмин редко бывает по совместительству еще и классным программистом.

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

В итоге сайт может «хромать» из-за проблем и «узких» мест в любой из составляющих: CMS, хостинг, разработка. Клиент в нюансы не вникает и остается не удовлетворен проектом в целом. Его негатив переносится на всех: «Тормозной хостинг! Ужасная система! Разработчики ничего не умеют!»

Такая картина нас, конечно, никогда не устраивала. И мы решили, что надо что-то делать…

С данной темой доклада я выступал на CodeFest. А здесь я перескажу словами, что, как и зачем.


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

Видеоприглашение на конференцию:

В данной статье на примере однопортовой E1 карты Digium TE121P рассмотрим пример подключения её во FreeSWITCH на операционной системе CentOS.

Для тех, кто интересуется вопросами безопасности и уязвимостями Linux, создан обучающий проект exploit-exercises.com с подборкой виртуальных Linux-машин, описаниями уязвимостей, документацией и практическими заданиями.

1. Виртуальная машина Nebula
торрент-файл
прямая ссылка

Самые общие уязвимости, связанные с эскалацией привилегий в Linux: это SUID-файлы, разрешения, состояние гонки (race conditions), метапеременные оболочки, уязвимости $PATH, уязвимости скриптовых языков, ошибки компиляции бинарных файлов.

Агентство по национальной безопасности США опубликовало новую версию 200-страничного руководства (PDF) по безопасной конфигурации Red Hat Enterprise Linux 5. Это весьма подробный мануал, который объясняет принципы защищённой системы и на практике указывает все необходимые настройки и перечень сервисов, которые обязательно нужно отключить (это один из базовых принципов: минимизировать количество софта).

Есть и что-то вроде шпаргалки на листе A4, тоже очень удобно.

Я очень далёк от желания устраивать «cвященные войны» на тему языков программирования. Всё равно мы будем использовать те языки программирования, которые сочтём подходящими для своих задач. Когда я писал эту заметку, я предполагал, что она вызовет негативную реакцию. Меня она совсем не удивит.
Когда я впервые познакомился с ruby, я был приятно удивлён-элегантный и внятный синтаксис языка, мультиплатформенность и много всяких вкусностей.Но пользуюсь я до сих пор python, совсем не потому что python лучше чем ruby. Совсем по другим причинам.

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

Если вы не понимаете, что побудило сделать git именно таким, то вас ждут страдания. Используя множество флагов (--flag), вы сможете заставить git работать так, как по вашему мнению он должен работать, вместо того, чтобы работать так, как git того хочет. Это как забивать гвозди отверткой. Работа делается, но хуже, медленнее, да и отвертка портится.

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

Наряду со статьей "iPhone: MiTM атака из кармана", родилась почти аналогичная статья про Android.

Мы уже знаем, на что способен iPhone. Уступает ли ему Android?

Было рассмотрено около 25 боевых приложений. Хочу предоставить вам результат маленького исследования. Многие приложения даже не запустились, некоторые подвесили телефон намертво, но некоторые даже работали!

Весь софт тестировался на телефоне LG Optimus, с версией Android 2.3.

Итак, краткий обзор боевого софта на Android:

Лет 6 назад, в мою бытность сисадмином в одной конторе, мне приходилось обслуживать несколько серверов на FreeBSD — прокси, почтовик, web-сервер, ftp, ipfw, в общем, все как у всех. Работало все на двух физических серверах, и было у меня желание заиметь какую-нибудь универсальную графическую оболочку для удобства управления всем этим хозяйством. Ну и, конечно же, таковой нигде не было. Были попытки разных умельцев создать свои GUI для управления подсистемами по отдельности: один для squid, другой для sendmail и т. д. Конечно, можно было какую-то часть управления выполнять и в webmin, но это не доставляло никакого удовольствия. Как говорили мне — неправильно работать с *nix-системами через GUI. Нет, естественно работа в командной строке не доставляла неудобства, но хотелось чего-то более универсального. В итоге, я написал несколько скриптов, которые вызывали псевдографику на черном экране, где можно было добавлять/удалять правила, рулить пользователями и т. д., на чем как-то все остановилось, хотя интерес к удобству управления через GUI и не пропал.

Добрый день, сообщество,
На Хабре уже говорилось о всевозможных TOP- овых утилитах, на этот раз, я хочу попробовать рассмотреть поближе утилиту atop. Постараюсь немного сравнить ее с существующими утилитами наблюдения за производительностью и научиться читать выводы данной команды.
У системных администраторов задача наблюдения за производительностью встает чуть ли не каждый день, и конечно же хотелось бы все это сделать в рамках одной утилиты и без особых танцев с бубном, как мне кажется удобнее всего в таком случае использовать команду atop.

Чтобы было понятно о чем речь, прикладываю 3 скринкаста, второй и третий под катом.

1. Знакомство с макетом #1
   

GNU make — широко известная утилита для автоматической сборки проектов. В мире UNIX она является стандартом де-факто для этой задачи. Являясь не такой популярной среди Windows-разработчиков, тем не менее, привела к появлению таких аналогов, как nmake от Microsoft.

Однако, несмотря на свою популярность, make — во многом ущербный инструмент.

Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.

Основные понятия Domain Name System

Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:

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

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

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

Но статья, на самом деле, не об этом. Я хочу рассказать про две замечательные команды git, которые я недавно для себя открыл. Это git blame и git bisect

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

Универсального решения в данном вопросе нету, просто есть некоторые аспекты, которыми следует руководствоваться при выборе схемы разбивки.

— Феденька, ты очень интеллигентный мальчик, ты мне очень нравишься, но Я БУДУ СТАВИТЬ ДВА В ГОДУ!!! — визжала моя школьная учительница по французскому и делала примерно такое лицо.

Моя школьная учительница по английскому языку делала другое лицо: