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

У нас 300 клиентов. Кому-то это «всего», а для нас — это почти 2000 серверов на обслуживании. Чтобы хранить, обновлять и управлять базой из 2000 паролей для 60 сотрудников, управлять доступом к ней и не объяснять каждый раз клиенту, что пароли к его серверам будут одновременно знать 60 человек, мы сделали сервер аутентификации и назвали его Isolate. Под катом описание функций и ссылка на Github — мы выложили его в Open Source.

Максим Дунин (Nginx, Inc.)

Ведущий: Я представляю вашему вниманию следующего докладчика. Встречайте – Максим Дунин. И он расскажет о том, что же нового появилось в технологии под названием nginx.

Дисклеймер: речь пойдёт о нововведениях в 2016 году. Можно подумать, что это давно, но информация об изменениях в changelog от автора этих самых изменений полезна всегда!

Максим Дунин: Добрый день! Я Максим Дунин. Как вы, наверное, знаете, я разработчик nginx. Сегодня буду вам читать changelog вслух и с выражением. Для начала давайте определимся, с какого именно места мы будем читать changelog. Посмотрим на статистику.

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

При проектировании сети в новом месте хотелось новых плюшек:

• В некоторой степени изолировать серверы клиентов от чужого трафика;
• Не дать недобросовестным клиентам повесить себе на интерфейс адреса добросовестных;
• При необходимости иметь возможность без особой нагрузки порезать трафик;
• Иметь возможность дать клиенту любое количество IP-адресов.

Теоретически, все эти моменты решаются с помощью обычных VLAN. Однако, возникает проблема с перерасходом адресов — все же жалко клиенту, заказавшему сервер с одним адресом, отдавать сеть /30 и терять три адреса впустую. Также жалко адреса и в обратной ситуации — клиенту надо 6 доступных адресов, а в сеть /29 он уже не поместится, приходится выдавать сеть /28 и терять 7 штук.

Существует несколько популярных securty дистрибутивов, содержащих большинство популярных утилит и приложений для проведения тестирования на проникновение. Обычно они основаны на существующих Linux-дистрибутивах и представляют из себя их переработанные версии. В этой статье будут представлены наиболее известные из них.

Hello, Habr! Недавно мы получили от “Известий” заказ на проведение исследования общественного мнения по поводу фильма «Звёздные войны: Пробуждение Силы», премьера которого состоялась 17 декабря. Для этого мы решили провести анализ тональности российского сегмента Twitter по нескольким релевантным хэштегам. Результата от нас ждали всего через 3 дня (и это в самом конце года!), поэтому нам нужен был очень быстрый способ. В интернете мы нашли несколько подобных онлайн-сервисов (среди которых sentiment140 и tweet_viz), но оказалось, что они не работают с русским языком и по каким-то причинам анализируют только маленький процент твитов. Нам помог бы сервис AlchemyAPI, но ограничение в 1000 запросов в сутки нас также не устраивало. Тогда мы решили сделать свой анализатор тональности с блэк-джеком и всем остальным, создав простенькую рекурентную нейронную сеть с памятью. Результаты нашего исследования были использованы в статье “Известий”, опубликованной 3 января.



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

Представляю вторую статью из серии, ориентированных на «продолжающих» системных администраторов, для опытных я вряд ли открою что-то новое.
В этих статьях мы рассмотрим построение интернет шлюза на linux, позволяющего связать несколько офисов компании, и обеспечить ограниченный доступ в сеть, приоритезацию трафика (QoS) и простую балансировку нагрузки с резервированием канала между двумя провайдерами.
Конкретно в этой части:

• Более подробная настройка Shorewall
• Страшный и не понятный QoS
• Балансировка нагрузки и резервирование

А в предыдущей части были рассмотрены:

• Простейшая настройка Shorewall
• Ужасно сложная настройка dnsmasq
• Не менее сложная настройка OpenVPN
• И для многих продолжающих админов нетипичная, динамическая маршрутизация, на примере OSPF

В третьей части:

• QoS во всю ширь в Shorewall
• Более подробная настройка Shorewall
• Раскидывание трафика по каналам в соответствии с протоколами
• Костыли, без них, никуда

В четвертой части:

• Автоматические события
• Макросы

Представляю пока две статьи, ориентированных на «продолжающих» системных администраторов, для опытных я вряд ли открою что-то новое.
В этих статьях мы рассмотрим построение интернет шлюза на linux, позволяющего связать несколько офисов компании, и обеспечить ограниченный доступ в сеть, приоритезацию трафика (QoS) и простую балансировку нагрузки с резервированием канала между двумя провайдерами.
Конкретно в этой части:

• Простейшая настройка Shorewall
• Ужасно сложная настройка dnsmasq
• Не менее сложная настройка OpenVPN
• И для многих продолжающих админов нетипичная, динамическая маршрутизация, на примере OSPF

А во второй части будут рассмотрены:

• Более подробная настройка Shorewall
• Страшный и не понятный QoS
• Балансировка нагрузки и резервирование

В третьей части:

• QoS во всю ширь в Shorewall
• Более подробная настройка Shorewall
• Раскидывание трафика по каналам в соответствии с протоколами
• Костыли, без них, никуда

В четвертой части:

• Автоматические события
• Макросы

В первой статье мы познакомились с Эрлангом и фреймворком n2o. В этой части мы продолжим делать наш блог:

• добавим авторизацию через фейсбук, для этого будем из клиента вызывать функции на сервере;
• будем сохранять комментарии и посты в NoSQL базе;
• развернем наш блог на DigitalOcean и замерим производительность (спойлер — 1300 запросов в секунду).

Код из статей https://github.com/denys-potapov/n2o-blog-example, готовый проект можно посмотреть по адресу http://46.101.118.21:8001/.

Функцией партиционирования таблиц в PostgreSQL, к сожалению, активно пользуются пока не многие. На мой взгляд, очень достойно о ней рассказывает в своей работе Hubert Lubaczewski (depesz.com). Предлагаю вам еще один перевод его статьи!

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

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

Продолжение о базе данных и деплое во второй статье.

Я начинаю публиковать серию статей о веб-разработке на Эрланге. Многие хотят попробовать Эрланг, но сталкиваются с проблемой, что вводные курсы в основном касаются Эрланга как функционального языка и далеки от реальных проектов (Learn You Some Erlang for great good! — хорошая и подробная книга). С другой стороны все обучающие материалы по веб-разработке подразумевают, что читатель уже хорошо знает Эрланг.

Эта серия статей рассчитана для разработчиков, у которых есть опыт в веб-разработке (PHP, Ruby, Java), но не имеют опыта разработки на Эрланге.

Задачей будет сделать блог. Код из статей https://github.com/denys-potapov/n2o-blog-example, готовый проект можно посмотреть по адресу http://46.101.118.21:8001/. Особенности проекта:

• обновление комментариев в реальном времени;
• авторизация через фейсбук;
• данные храним в mnesia.

В основе проекта феймворк n2o. Выбор довольно субъективен, но из живых Эрланг фреймворков, n2o мне показался наиболее «эрлангоподобным», в тоже время ChicagoBoss больше похож на MVC фреймворки в других языках.

Подвернулась мне задача — запустить Proxmox и несколько виртуалок на сервере всего с 2 дисками. При этом требовалось обеспечить ну хоть какую-то надежность и простоту исправления проблем связанных с выходом из строя одного из дисков. Далее в заметке подробное описание тестирования решения на стенде.

Однажды мы ставили новые дисковые полки для массива EMC у одного из наших крупных клиентов. Когда я уходил с объекта, то обратил внимание на людей в форме транспортной компании, которые вытаскивали из стоек и готовили к погрузке большое количество серверов. С сисадминами заказчиков общение идёт плотное, поэтому довольно быстро выяснилось, что это серверы — старые машинки, в которых мало памяти и процессорной мощности, хотя дисков стоит в избытке. Обновлять их не выгодно и железки будут отправлены на склад. И их спишут где-то через год, когда они покроются пылью.

Железо, в целом, неплохое, просто прошлого поколения. Выкидывать, естественно, было жалко. Тогда я и предложил протестировать EMС ScaleIO. Если коротко, работает это так:



ScaleIO — это софт, который ставится на серверы поверх операционной системы. ScaleIO состоит из серверной части, клиентской части и нод управления. Дисковые ресурсы объединяются в одну виртуальную одноуровневую систему.

Контейнеризация сегодня — одна из самых актуальныx тем. Количество публикаций о таких популярных инструментах, как LXC или Docker, исчисляется тысячами, если не десятками тысяч.
В этой статье бы хотели мы обсудить ещё одно решение, о котором публикаций на русском языке пока что мало. Речь идёт о systemd-nspawn — инструменте для создания изолированных сред, который является одним из компонентов systemd. А закрепление systemd в качестве стандарта в мире Linux — уже свершившийся факт. В свете этого факта есть все основания полагать, что в ближайшее время сфера применения systemd-nspawn существенно расширится, и познакомиться с этим инструментом поближе стоит уже сейчас.

Данная статья является переводом оригинальной статьи с сайта Severalnines.

Nginx хорошо известен всем за свои расширенные возможности и эффективность в качестве прокси и/или балансировщика веб-приложений с низким потреблением памяти. Как правило, nginx используется на первой “линии обороны” веб приложений, чтобы распределять нагрузку на сервера бекенда, периодически проверяя их работоспособность. Данная технология довольно популярна для приложений, которым требуется повышенная отказоустойчивость.

Всё началось с того что возникла необходимость защитить передаваемые на сервер пользовательские данные. И сделать нужно было так, что бы не заморочивать при этом пользователей корпоративных iPad'ов. Я не смог придумать ничего умнее как использовать IPSexc и VPN On-Demand на iOS. И поднимать я его решил через strongSwan.

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

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

Приветствую. Меня зовут Эдуард, и я системный администратор в небольшой компании, которая аутсорсит администрирование ИТ-инфраструктуры. Кхм… Уже похоже на клуб анонимных кого-то с проблемами? Ну да ладно, одна интересная проблема у нас действительно была, а сегодня мы расскажем, как мы с ней столкнулись, и как случайно её решили.

Для начала немного предыстории. Все же помнят, как весело было админить удалённое железо раньше, лет 5-8 назад? Пишем заявку инженерам в ДЦ, ждём, когда они подключат KVM, настраиваем BIOS/CMOS, выставляем загрузку по сети, ставим систему (это хорошо, если кто-то добрый уже написал генератор preseed/kickstart-файлов, и в ДЦ есть DHCP/PXE сервер). А потом у нас на всех серверах появился ipmi (ну со временем). Ох, как мы радовались первое время!

Дорого дня, уважаемые хабражители!

Сегодня я расскажу вам о том, как можно установить неподписанное (или плохо подписанное) приложение на устройство с iOS 9. Да, без Jailbreak. Да, бесплатно. Нужен лишь компьютер с OS X и Apple ID. Как такое возможно? Читаем под катом.



Осторожно! Много картинок!

Примечания tsafin:

Перед публикацией своего цикла статей по MapReduce в Caché, мне показалось важным озвучить данную прошлогоднюю точку зрения из статьи Адама Дрейка «Command-line tools can be 235x faster than your Hadoop cluster». К сожалению оригинальная статья Тома Хайдена, на которую он ссылается стала уже недоступна на сайте Тома, но её, по-прежнему, можно найти в архивах. Для полноты картины предлагаю ознакомиться и с ней тоже.

Введение

Посещая в очередной раз свои любимые сайты, я нашел крутую статью Тома Хайдена об использовании Amazon Elastic Map Reduce (EMR) и mrjob для вычисления статистики отношения выигрыш/проигрыш в наборе данных со статистикой по шахматным матчам, которую он скачал с сайта millionbase archive, и c которой он начал играться используя EMR. Так как объем данных был всего 1.75GB, описывающий 2 миллиона шахматных партий, то я скептически отнесся к использованию Hadoop для данной задачи, хотя были и понятны его намерения просто поиграться и изучить плотнее, на реальном примере, утилиту mrjob и инфраструктуру EMR.

Появилась задача обезопасить админскую часть на сайте. Причём это надо было сделать без внесения изменений в код самого сайта. Лучшее, что смог я найти — oauth2_proxy и nginx-google-oauth, но они требовали обработку коллбэков. Эти решения мне не понравились и я их отверг.

Пришлось обратиться к одному из модулей nginx и комплектующим для велосипеда.

До недавнего времени в Одноклассниках в качестве основного Linux-дистрибутива использовался частично обновлённый OpenSuSE 10.2. Однако, поддерживать его становилось всё труднее, поэтому с прошлого года мы перешли к активной миграции на CentOS 7. На подготовительном этапе перехода для CentOS были отработаны все внутренние процедуры, подготовлены конфиги и политики настройки (мы используем CFEngine). Поэтому сейчас во многих случаях миграция с одного дистрибутива на другой заключается в установке ОС через kickstart и развёртывании приложения с помощью системы деплоя нашей разработки — всё остальное осуществляется без участия человека. Так происходит во многих случаях, хотя и не во всех.

Но с самыми большими проблемами мы столкнулись при миграции серверов раздачи видео. На их решение у нас ушло полгода.