Данная статья касается современных линуксов. Например, RHEL6 с ядрами 2.6.3х — подойдёт, а вот RHEL5 с ядрами 2.6.18 (кстати, наиболее популярный в продакшне) — увы, нет. И ещё — здесь не будет описания ядерных отладчиков или скриптов SytemTap; только старые-добрые простые команды вида «cat /proc/PID/xyz» в отношении некоторых полезных узлов файловой системы /proc.

Диагностика «тормозящего» процесса

Вот хороший пример часто возникающей проблемы, которую я воспроизвёл на своём лаптопе: пользователь жалуется, что команда find работает «значительно медленнее», при этом не возвращая никаких результатов. Зная, в чём дело, мы решили проблему. Однако меня попросили изложить систематический подход к решению подобных задач.

К счастью, система работает под управлением OEL6, т.е. на достаточно свежем ядре (а именно — 2.6.39 UEK2)

Итак, приступим к диагностике.

1. Схема

Имеем:

• Frontend — NGINX проксирующий сервер для принятия и распределения нагрузки (IP — 1.2.3.4 — внешний, IP — 192.168.5.10 — внутренний DMZ) по хорошему он тоже должен стоять за firewall-ом, но тут схема для простоты понимания.
• Два сервера с поднятыми ownCloud
• cloud-1 IP — 192.168.1.11
• cloud-2 IP — 192.168.1.12
• Хранилище файлов NFS-storage IP — 192.168.1.20 для размещения данных пользователей с доступом по NFS.

Эта заметка является косвенным продолжением моей первой публикации Сборка Android под Mac OS X и имеет аналогичную цель — решение проблем сборки относительно старых версий Android 4.0.x.

Коротко вводная. В одном из проектов я занимаюсь доработками оригинального кода Android для создания прошивки под специфичную железку. Версия для сборки была выбрана уже относительно старая — AOSP 4.0.4, но на ней базируется стабильная ветка кода от производителя железки. Первоначально я работал на MacOS, но для этого проекта решил переключиться на Linux для удобства разработки. Итак волею судеб я перешел с MacOS на более менее свежий Ubuntu Linux 12.04.3, рекомендованную на данный момент версию Linux для сборки Android.

Привет, Хабраюзеры! Сегодня я хотел бы рассказать о инструментах, которые облегчают тестирование кукбуков. В чем собственно проблема? С ростом масштаба инфраструктуры становится сложнее следить за зависимостями и последствиями внесения изменений в кукбуки и на повестке дня становится вопрос о их тестировании. Решить данные проблемы помогают такие инструменты, как foodcritics, chefspec, minitest, test kitchen…
В данном посте я хотел бы поделиться своим опытом по освоению test kitchen в «преславутый 21 день». Я старался чтобы данный пост был максимально прост и удобен для начального ознакомления с test kitchen.

Всем привет!

В прошлой статье мы начали разговор о преимуществах контейнерной изоляции (контейнеризации), теперь мне бы хотелось углубится в технические аспекты реализации контейнеров.

На тему систем централизованного управления конфигурациями на Хабре написано немало статей и, в частности, про Chef есть несколько хороших статей. Однако, количество релизов Chef растет, и я решил немного освежить его описание для читателей Хабра. Статья предназначена как для новичков, так и для тех, кто уже знакомился с системой, но по какой-то причине отложил изучение и хочет все-таки продолжить. А продолжать стоит! Поскольку, Chef полезен и для администрирования нескольких VPS, и для управления большим парком серверов. Особенно, если вам часто приходится заниматься настройкой серверов с нуля, подключением дополнительных нод в кластер и т.д.

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

Чего обычно хочется:

• Возможность поднять проект локально на машине разработчика. Весь или хотя бы частями. Причем очень хочется, чтобы Dev конфигурация отличалась от Prod в минимуме параметров. Это позволит избежать “work on my machine” багов. Да и вообще, когда один разработчик работает на OS X, другой на Windows, а продакшен на Debian, то жди беды, это не считая того, что каждый делает работу по настройке окружения.
• Dev конфигурацию хочется разворачивать на любой машине и ОС в пару команд в консоли. Это опять же позволит уменьшить фактор “work on my machine” багов. А еще позволит привлекать других разработчиков в проект за минимальное время (vagrant up и поехали).
• Конфигурация должна быть понятна и программисту, и админу.

Всего этого мы добьемся на связке Salt + Vagrant на примере Django проекта. Но большинство техник будут полезны разработчикам не только на Python, но на других языках.

Как скоро я смогу вас заинтересовать, если скажу, что в этой статье речь пойдет о VPN-сервере, который может поднимать L2TP/IPsec, OpenVPN, MS-SSTP, L2TPv3, EtherIP-серверы, а также имеет свой собственный протокол «SSL-VPN», который неотличим от обычного HTTPS-трафика (чего не скажешь про OpenVPN handshake, например), может работать не только через TCP/UDP, но и через ICMP (подобно pingtunnel, hanstunnel) и DNS (подобно iodine), работает быстрее (по заверению разработчиков) текущих имплементаций, строит L2 и L3 туннели, имеет встроенный DHCP-сервер, поддерживает как kernel-mode, так и user-mode NAT, IPv6, шейпинг, QoS, кластеризацию, load balancing и fault tolerance, может быть запущен под Windows, Linux, Mac OS, FreeBSD и Solaris и является Open-Source проектом под GPLv2?

То-то и оно. Такое пропустить нельзя.

Приобрел пару дней назад принтер-плоттер HP T120. Это принтер с термоструйной головой, и возможностью печатать на рулонах 610мм, для его качества и скорости очень даже бюджетный.
Распаковав его и подключив к wifi, начал подключать.

На просторах Интернета можно встретить не одну статью, где нахваливают LXC и утверждают, что за этой технологией будущее. Я уже в третий раз сажусь поизучать текущий статус и каждый раз выясняется множество нюансов. Первая попытка была где-то года полтора или два назад, вторая — после релиза Debian 7, третья — на этих выходных. Причина в том, что Debian/Ubuntu мне нравятся на порядок больше, чем CentOS/RHEL. Но к сожалению, в плане контейнерной виртуализации (в частности OpenVZ) в Debain/Ubuntu стало совсем печально в последних релизах. В том числе и благодаря более активному продвижению LXC. Собственно, LXC так LXC — лишь бы решало нужные задачи. Я не являюсь хостером и такой виртуализацией пользуюсь в основном ради целей разработки, тестирования и для работы некоторых собственных проектов.

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

Вот и настал тот день, когда пришлось отложить в сторону кукбуки, рецепты, нож шеф-повара и немного позаниматься кукловодством.
Для начала постановка задачи довольно тривиальная — организовать для девелоперов возможность быстро и просто разворачивать окружение. Обязательное требование — для автоконфигурации использовать Puppet Enterprise

Ола, Хабрасообщество!

Введение

Данный доклад изначально был подготовлен для выступления на конференции компании FastVPS ROCK IT 2013, прошедшей 24-25 августа 2013 года в Городе Tallinn, Estonia.

Возможно, кто-то слышал его лично (спасибо!), но все равно рекомендую ознакомиться, так как данная публикация является более подробной и рассматривает намного больше опущенных в докладе деталей (smile)

Публикация имеет целью провести краткий обзор имеющихся на рынке open source средств для развертывания нескольких виртуальных окружений на базе физического сервера с Linux на борту, а также рассказать о преимуществах использования контейнеров для создания облаков :)

Open source решения на базе Linux для создания виртуальных окружений

Встречайте героев сегодняшнего рассказа!

Итак, вторая часть. Здесь я раскрою как получить информацию от пользователя, а так же о манипуляции этими данными. Тут можно затронуть вопрос, поднятый в комментариях к предыдущему посту — «А зачем это все нужно?». Примерами применения таких интерфейсов в 21-м веке являются различные аплаянсы на виртуальных машинах, которые реализуют отдельные сервисы. Чаще всего они представляют из себя минимальный дистрибутив Linux или набор загружаемое ядро + busybox. С помощью такого интерфейса можно реализовать некий фронтэнд для сервиса, позволяющий одним взглядом определить состояние основных узлов или выполнить некие операции в удобной для пользователя форме. Примером можно назвать подобные фронтэнды у VMware ESXi (vDirector, vCenter etc), Citrix Xen, которые сочетают как мощь web-интерфейса, так и TUI как резервного интерфейса и/или интерфейса настройки/диагностики. Переключаясь по десяткам машин можно одним взглядом увидеть, все ли в порядке или быстро узнать IP адрес, полностью заблокировав юзеру доступ к консоли, показывая ему только то, что ему достаточно знать (foolproof).

Периодически просматривая топики на хабре, постоянно ловлю себя на мысли, что ещё чуть-чуть и какой-нибудь нейроинтерфейс в ноутбуке станет реальностью. В работе постоянно натыкаюсь на то, что современные люди не очень понимают и любят простую командную строку. А читать мануалы им тем более лень.
Но в моей практике часто случается так, что нужна небольшая утилита, выполняющая одну или две функции. А где именно она будет выполняться — неизвестно. Это может быть Windows, это может быть исключительно терминальный линукс, загрузочная медия — что угодно. Я не программист, но иногда бывает нужно облегчить жизнь себе или другим. И желательно как можно более наглядно. Сначала я пробовал делать просто консольные утилиты. Собственно, с этого, наверное, начинают все. Но очень быстро оказалось, что средствами printf/sprintf/puts и прочими (а пишу я на С) не очень удобно форматировать текст, выводить какую-то информацию. Окно с постоянным «скроллингом» выглядит не очень красиво, и если информации много — абсолютно нечитаемо. Тогда я вспомнил про ncurses.

Здравствуйте, хабравчане! Сегодня я хотел бы рассказать о персональном облачном хранилище ownCloud и его установке.

Для нас уже стало обыденным использование таких сервисов как Dropbox, Google Drive, SkyDrive или даже Облако Mail.Ru, мы пользуемся их услугами каждый день не обращая внимание на явные недостатки тех или иных серверов. На одном, сервисе мало места, на другом нет локализации, на третьем ненадежное хранилище, на четвертом кривой интерфейс и так далее, но у всех этих сервисов есть общий существенный недостаток — ваши данные всегда хранятся на неконтролируемых вами серверах. В случае когда необходимо использовать сервисы для размещения данных не имеющих для вас большой ценности — этих сервисов должно полностью хватить. В случае если, необходима защита контента, полная конфиденциальность, безопасность, неограниченное количество свободного места, возможность организовать многопользовательский доступ для работы в группах, контроль версий, синхронизация, возможность просматривать документы, таблицы, изображения, видеоматериалы, аудиозаписи, заметки из любой точки мира без необходимости их загрузки — ownCloud это то что вам нужно.

Давайте подробнее рассмотрим ownCloud и попробуем его установить

Привет, Хабраюзеры! На улице противная погода, ангина не дает покоя моему воспаленному горлу, почему бы не написать статью? Это моя первая проба пера на Хабре, поэтому не судите строго. Название ее навеяно огромным количеством книг, имеющих схожее название. В этой статье я постараюсь описать путь воина-автоматизатора для юных падованов, коим в некоторой мере являюсь сам. Речь пойдет о подходе, который при определенном старании, поможет в краткие сроки познакомиться с таким инструментом кроссплатформенной автоматизации, как CHEF. А также, при сильном старании – овладеть ним в достаточной мере для первых серьезных опытов. Эта статья – некий “guiding way” для людей, мало знакомых с процессом автоматизации.

Доброго времени суток, уважаемые. Расскажу сегодня в рамках темы статьи, как я провёл новогоднюю ночь. Не только расскажу, но и покажу картинки. Очень увлекательное было действо. Ну а началось всё так. После установки и настройки домашнего мини-сервера мама захотела себе компьютер. Мол, чем я хуже. Хочу в интернете информацию читать, набирать тексты и тому подобное. Думал я думал и надумал.

Как-то давным-давно читал я одну статью о тонких клиентах. Что можно настроить старую машину — Intel i486, pentium I, II и подобную для нормальной работы: просмотр видео, интернет сёрфинг и прочее. Звучит фантастически. Но это правда. Можно сделать такое шаманство. Для этого нужен мощный сервер и клиент (в моем случае им оказался Intel Pentium MMX 200 RAM 64Mb 2MB Video и без HDD).



Вообщем дело было перед новым годом. Эта конструкция была бы неплохим новогодним подарком маме. Решил я надолго это не откладывать. Для компьютера нужно было прикупить кое какое барахлишко: новую клавиатуру и мышь. Не смейтесь, но к АТ-корпусу клавиатуры уже не выпускают. На раритетных платах это разъем DIN-5. Очень смахивает на штекер от старого магнитофона. Мышку можно туда ps/2 подключить, на материнской плате есть для этого специальные Pin'ы.

По моему мнению, большинству IT специалистов стоит использовать Vagrant. Кто не знает, что это такое – рекомендую начать с официального сайта. На Хабре так же было несколько обзоров вагранта, например Development Environment при помощи Vagrant и Chef и Создание новой виртуальной машины за одну минуту или «vagrant up!». В этой статье я более детально расскажу о «экосистеме» вагранта.

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

Доброго времени суток, читатель.

Предыстория

Я 5 лет работаю в компании, предоставляющей широкополосный доступ к всемирной паутине. Занимаюсь непосредственным управлением оборудованием, а также планированием и мониторингом сети. На момент моего прихода в сети было немногим больше 100 единиц управляемого оборудования вендоров Cisco и D-Link. Рисовали карту сети по старинке в visio, ip-адреса вели там же, но мой руководитель в то время начал писать некоторый софт для инвентаризации оборудования — началось все с учета выданных ip-адресов. Учитывая рост сети (а точнее модернизация в лице замены глупых «мыльниц» на «управляки»), мы и решили, что обычного Cacti нам не хватает. Стандартные счетчики по SNMP мы собирали сразу, но найти что-то более нужное и интересное было трудно. Неоднократные попытки овладеть другими опциями не приводили к конечному результату, но не так давно удалось «обуздать» MIB-файлы для коммутаторов D-Link и считаю, что данная статья ускорит процесс изучения коммутаторов и протокола SNMP. Это позволит быстрее и качественнее управлять сетью.

Никогда не был фанатом gitk и пользовался им редко, предпочитая консоль и настроенные алиасы. Благодаря хабраюзеру grossws, я открыл для себя tig. Это то, чего мне не хватало. После месяца использования его в работе хочу поделиться находкой с вами.

Tig это консольный GUI(TUI) для Git, основанный на Ncurses.
Основные преимущества:

• потрясающая скорость, 20,000 коммитов готовы к просмотру за четверть секунды
• консольный
• управление в vim стиле

Cкриншоты основных режимов и сравнение с gitk.