Доброго времени суток, уважаемое сообщество!

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

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

Wireshark — это достаточно известный инструмент для захвата и анализа сетевого трафика, фактически стандарт как для образования, так и для траблшутинга.
Wireshark работает с подавляющим большинством известных протоколов, имеет понятный и логичный графический интерфейс на основе GTK+ и мощнейшую систему фильтров.
Кроссплатформенный, работает в таких ОС как Linux, Solaris, FreeBSD, NetBSD, OpenBSD, Mac OS X, и, естественно, Windows. Распространяется под лицензией GNU GPL v2. Доступен бесплатно на сайте wireshark.org.
Установка в системе Windows тривиальна — next, next, next.
Самая свежая на момент написания статьи версия – 1.10.3, она и будет участвовать в обзоре.

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

Начинаем плаванье

Для начала захвата достаточно выбрать свой сетевой интерфейс и нажать Start.

В качестве предисловия

Основной задачей моей работы является поддержка парка железных и vm хостов — уже под 200 (а приходил было менше 100, эх, время бежит...) Поддерживаю все железо, а также сеть. Также на мне весь мониторинг (используем Opsview — сделан на ядре nagios), аггрегация логов (я внедрил Logstash, обалденное opensource решение за место ну ооочень дорогого Splunk), configuration management (puppet), бекапы, поддержка баз данных и прочих систем тоже на мне (MongoDB, MySQL, Redis, ElasticSearch, etc). В общем — все самое интересное). Стоит отметить что у нас достаточно тонкая грань между поддержкой и разработкой, и разработчики часто говорят что они хотят, а я уже занимаюсь внедрением. Хочется рассказать обо всем что происходит интересного и какие технологии удается использовать. Какие прижились, а какие по каким-то причинам нет.

Образовательный проект General Assembly представил интерактивный курс Dash, призванный помочь тем, кто хочет изучить CSS, JavaScript и HTML, пишет TechCrunch. Для этого пользователям предлагаются различные задачи, похожие на те, с которыми сталкиваются веб-разработчики в реальной жизни. Так, по мере прохождения курса, вы сначала узнаете, как создать личный сайт, затем макет для блога и сайт небольшой компании и в конечном итоге робота в CSS.

Период таймера Windows по умолчанию составляет 15.6 мс – он тикает 64 раза в секунду. Когда программа увеличивает частоту таймера, растет потребление энергии, что сказывается на расходе батареи. При этом также расходуется вычислительная мощность компьютера, и даже больше, чем я думал – то есть компьютер начинает работать медленнее! Вот почему в течение многих лет Microsoft настоятельно не рекомендует разработчикам поднимать частоту таймера.
Почему же тогда почти каждый раз, когда я вижу разгон таймера, он вызван программой от Microsoft?

Задача:

Собирать информацию о действиях пользователя (аудита) в консоли Linux, а именно вводимых им командах и выводимой на экран информации.

Предлагаемое решение:

screen по умолчанию для всех пользователей в Linux с логированием

Необходимые условия:

1. Полное логирование всех пользователей в консоли, включая вывод информации процессами, чтобы можно было оценить почему пользователь принял то или иное решение
2. Без возможности отключения логирования
3. Раз уж выбрали screen — максимально используем его возможности (открытие новых окон, отключение по ^a + d, оставляя рабочие процессы запущенными и другие удобства)
4. Максимальное удобство — не должно быть каких-либо несовместимостей с приложениями
5. В случае использования пользователями, не знакомыми с screen — сделать работу максимально знакомой и близкой к обычной командной оболочке (shell)

На последней конференции РИТ++ мне посчастливилось стать впервые докладчиком конференции такого масштаба и такой значимости. В этой статье я не просто хочу пересказать всё, о чём я докладывал. Выступать впервые перед такой большой аудиторией для меня было непривычно и я половину забыл рассказать, нервничал немного. Речь пойдет о создании с нуля собственной отказоустойчивой структуры для веб-проектов. Мало кому из системных администраторов дается возможность с нуля запустить в production крупный проект. Мне повезло.

Как я уже написал, я не смог рассказать всё, что планировал со сцены, в этой статье я восполню эти пробелы, да и для того, кто не смог там присутствовать — это будет приятно, видео с конференции так и не дали бесплатно всем. Да и стать пользователем Хабра я хотел давно, вот только не было времени. Майские праздники дали время и силы. Статья будет не столько технической с кучей конфигов и графиков — статья будет принципиальная, все пробелы мелких технических вопросов можно будет восполнить в комментариях.

Disclaimer

Этот урок поможет вам познакомиться с Yii2. В данный момент Yii2 абсолютно не готов для продакшена. Я не рекомендую использовать его в рабочих проектах.

Начнём

Сегодня авторы Yii Framework анонсировали публичное превью Yii2. Между Yii1 и Yii2 довольно много изменений.

Этот урок описывает создание простого блога на Yii2. В процессе мы будем скачивать и устанавливать Yii2, создавать базовое приложение, подключаться к базе данных и описывать логику создания, обновления, чтения и удаления постов.

Для продолжения вам потребуется:

• Вебсервер, например Apache или Nginx. Я буду использовать Nginx. Использование Apache будет отличаться незначительно, поэтому не волнуйтесь если у вас нет поблизости сервера с Nginx.
• Север базы данных для нашего приложения. Я выбрал MySQL 5.5
• Базовые знания PHP. Я постараюсь объяснять всё так просто, как это возможно, но чем лучше вы знаете PHP, тем проще вам будет двигаться дальше.
• Базовые знания Yii или MVC. Если у вас нет никакого опыта работы с MVC, то я рекомендую вам прочесть основы MVC. Вы можете прочитать этот урок и без знания MVC, но вам будет гораздо легче понимать происходящее, разбираюсь в теме MVC.

Вперёд!

Автор: Олег Гельбух

Прошлой осенью в блоге команды SwiftStack появился интересный обзор их подхода к созданию мультирегиональных кластеров Объектного хранилища OpenStack (кодовое название проекта — Swift). Этот подход хорошо сочетается со схемой географически распределенного кластера Swift с сокращенным числом реплик (3+1 вместо 3+3, например), над которой мы совместно работали с компанией Webex примерно в это же время. Я хотел бы кратко описать наш подход и остановиться на плане внедрения и предлагаемых изменениях кода Swift.

Текущее состояние OpenStack Swift

Я хотел бы начать с краткого обзора текущих алгоритмов Swift, чтобы затем пояснить, что именно требуется сделать, чтобы создать кластер из нескольких географически разделенных регионов.

А так же советы «Бывалого» в записи вебинара.


На этот раз на глубоком техническом уровне дан обзор по следующим темам:

• Что такое Hyper-V
• Версии Windows Server 2012 Hyper-V
• Аппаратные требования к Windows Server 2012 Hyper-V
• Динамическое выделение памяти
• Новый формат VHDX файлов, поддержка Native 4K Drives и дисков до 64Tb
• Возможности SMBv3
• Установка Hyper-V
• Миграция на Hyper-V и её сценарии
• Сервисы интеграции
• Модель безопасности Hyper-V
• Сетевые возможности Windows Server 2012 Hyper-V
• Виртуальные Fibre Channel
• Что такое Live Migration
• Высокодоступные кластеры Windows Server 2012 Hyper-V
• Live merge of snapshots
• Аварийное восстановление и Hyper-V Replica
• Азы управления при помощи System Center
• Hyper-V на клиентских ОС и их ограничения
• И многое другое...

Автор: Piotr Siwczak

Когда я разрабатывал свою первую инфраструктуру OpenStack, я с трудом находил информацию о том, как следует распределять многочисленные ее компоненты по оборудованию. Я изучил множество документов, в том числе справочник по архитектуре Rackspace (который ранее был размещен по ссылке referencearchitecture.org, но сейчас, похоже, эта ссылка устарела). Я также просмотрел проектные схемы в документации OpenStack. Должен признать, что тогда у меня были только базовые знания о том, как взаимодействуют компоненты, поэтому я остановился на достаточно простой схеме: один “управляющий узел”, который включал все компоненты, в том числе API-сервисы, nova-scheduler, Glance, Keystone, базу данных и RabbitMQ. Под управление узла я поместил ферму “рабочих лошадок” — вычислительных узлов. Я также организовал три сети: частную (для трафика с фиксированным IP-адресом и управления серверами), общедоступную (для трафика с динамическим IP-адресом) и для хранения (для трафика по протоколу iSCSI сервиса nova-volume).

Когда я начал работать в Mirantis, я значительно изменил свой подход. Я понял, что все мои идеи по созданию фермы выделенных вычислительных узлов с одним или двумя управляющими узлами, были неверными. С одной стороны, мой подход был хорош в плане разделения компонентов, но на практике мы можем с легкостью смешивать и компоновать рабочие компоненты без перегрузки OpenStack (например, сервис nova-compute с сервисом nova-scheduler на одном узле). Оказывается в OpenStack “управляющий узел” и “вычислительный узел” могут иметь разные значения в зависимости от того, как гибко распределены компоненты OpenStack.

В общем, можно предположить, что в каждой установке OpenStack должны быть как минимум три типа узлов (и, возможно, четвертый), которые описал мой коллега Олег Гельбух:

Автор: Олег Гельбух

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

— Бесперебойность (HA) сервиса и резервирование
— Масштабируемость кластера
— Автоматизация технологических операций

Компания Mirantis разработала подход, который позволяет удовлетворять всем этим трем требованиям. Эта статья – первая в ряде статей, которые описывают наш подход. В статье содержится обзор используемых методов и инструментов.

Бесперебойность (HA) и резервирование

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

API-сервисы
Первая группа включает API-серверы, а именно:

Когда у вас возникнет вопрос, как выбрать диагональ экрана, или в каком разрешении скачать фильм, предлагаю воспользоваться таблицей Головина для выбора диагонали экрана (pdf, 85 Кб). Название я придумал сам, надеюсь, Головин был бы не против.



С появлением первых телевизоров с разрешением 4к (3840 × 2160), я хотел обновить график для определения оптимального расстояния до экрана. Но, поскольку там указаны рекомендуемые расстояния, это бы снова вылилось в субъективные обсуждение возможностей зрения каждого. Новая таблица, теоретически, должна помочь каждому сделать выбор, в не зависимости от остроты зрения.

Думаю у каждого грамотного системного администратора есть коллекция ссылок на полезные в работе ресурсы. Я имею в виду различные сайты и блоги, на которых выкладываются полезные с точки зрения системного администратора посты.
Предлагаю ими поделиться в формате ссылка — описание.
Пример: habrahabr.ru — разнообразные статьи и новости на IT и около-IT тематику.

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

P.S. Хабр, опеннет и лор можно не упоминать. Можно выкладывать ссылки на конкретные статьи, если считаете их очень полезными.

Начну с себя (т.к я администрирую linux, то и ссылки у меня в основном соответствующие):

Уже 2 месяца использую на своих компьютерах модуль zRam и хочу поделиться результатами. На практике он позволил мне не используя раздел подкачки, и не получая видимого замедления работы компьютера увеличить размер оперативной памяти в 2.5-3 раза. На сервере виртуалок тот же подход позволил очень ощутимо увеличить отзывчивость при нехватке памяти.
Заинтересовавшихся прошу под кат.

В общем-то на Хабре достаточно постов о фрилансе вообще, и о Elance.com в частности — пост ниже является попыткой поделиться опытом.
Информации много не бывает — посему позвольте начать.

Если вы впервые слышите про Elance — настоятельно рекомендую прочитать два поста ниже, serjio очень хорошие советы даёт по поводу регистрации, наполнения портфолио, бидов и прочего, что необходимо знать:

• Как начать работать на Elance.com. Краткое руководство для веб-дизайнера.
• Работа на elance для новичков. Часть2

Ситуация

В сети на сегодняшний день достаточно много описаний по развертыванию IP телефонии и в основном это два варианта:

• Берём готовый дистрибутив в виде установочного образа (Elastix,Trixbox etc...) и в результате получаем рабочий комплекс не имея никаких знаний в Linux
• Устанавливаем комплекс самостоятельно занимаясь при этом компиляцией из исходных кодов и ручной правкой множества конфигурационных файлов.

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

Предпосылки

В процессе внедрения IP телефонии в одной из компаний с разветвленной структурой филиалов рассматривались оба варианта но оба не устраивало по ряду причин:

• Бюджет на проект не подразумевал затрат на привлечение сторонних компаний для развертывания проекта, весь комплекс телефонии было решено развертывать своими силами.
• Большинство системных администраторов в филиалах были не знакомы с Linux системами и являлись чистыми Winows админами.
• Требовалось заложить высокую гибкость системы под будущие, еще не придуманные задачи.

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

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

• вики, учет задач, тикетов, дефектов;
• система управления версиями/репозиторий;
• файловый сервер.

И если в случае первого и второго предлагается множество прекрасных средств, в частности для багтрекинга существуют известные каждому Redmine, Trac, а для управления версиями Subversion, Git, Mercurial, то для грамотной организации файлового хранилища приходится в очередной раз изобретать велосипед.

В статье описываются недостатки существующей структуры DNS, полный процесс внедрения DNSSEC на примере доменов .com и .org, процедура создания валидного самоподписанного SSL-сертификата подписанного с помощью DNSSEC.

Приветствую. Хочу поделиться одним самописным костылём, авось кому-нибудь будет полезен.

Коротко о главном

Моделируем ситуацию: есть кластер PostgreSQL-серверов — мастер и n-реплик. Наступает черный день и одна(или несколько) реплик падает. Причины неважны — сдохла железка, уборщица перебила шваброй провод или НЛО временно зохавало серверную. Итог один — если реплика долго лежала, то сама она уже никогда не нагонится.