Итак, если вы счастливый владелец nginx, знатный параноик и за каким-то чертом решили поставить wordpress, то… Первое, что пришло в голову — это «надо ограничить сему творению свободу!».

Настройки учетной записи, как и настройки php5-fpm, я опущу, так как у каждого свои тараканы, а кто-то вообще на apache запускает. Но вот общие для Wordpress я опишу в этой части. Напишу о том, что сделал, что получилось и почему.

Сумеречными зимними вечерами под песнь вьюги, укутавшись в овечий плед с бокальчиком «яблочной самогонки», я люблю почитывать логи на сервере. Авторизация по ключам упрощает сие, так что если в публичное помещение меня и не пустят, то сервер всегда рад приютить, старый чертяга.

В мире много чего происходит, у кого счастливое 200, кто-то недоуменно смотрит на 301, кто-то царапает похабщину на 403.

Но самый ценных мех — это исследователи. Это те, кто открывает новый для себя мир на основе своих знаний путем проб и 404.

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

Освоил expect и сразу в бой. Написал, опробовал, получилось. Теперь делюсь с Вами, может кому и пригодится.

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

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

Привет, Хабр! Какое-то время назад люди осознали, что увеличивать мощность сервера в соответствии с ростом нагрузки просто невозможно. Тогда-то мы и узнали слово «кластер». Но как бы красиво это слово не звучало, всё равно приходится технически объединять разрозненные серверы в единое целое – тот самый кластер. По городам и весям мы добрались до наших узлов в моём предыдущем опусе. А сегодня мой рассказ пойдёт о том, как делят нагрузку между членами кластера системные интеграторы, и как это сделали мы.



Внутри публикации вас также ждёт бонус в виде трёх сертификатов на месячную подписку ivi+.

Лирическое вступление

Когда администраторы сталкиваются с неожиданной проблемой (раньше работало, и, вдруг, после обновления, перестало), у них существует два возможных алгоритма поведения: fight or flight. То есть либо разбиратся в проблеме до победного конца, либо убежать от проблемы не вникая в её суть. В контексте обновления ПО — откатиться назад.

Откатиться после неудачного апгрейда — это, можно сказать, печальная best practice. Существуют целые руководства как готовиться к откату, как их проводить, и что делать, если откатиться не удалось. Целая индустрия трусливого поведения.

Альтернативный путь — разбираться до последнего. Это очень тяжёлый путь, в котором никто не обещает успеха, объём затраченных усилий будет несравним с результатом, а на выходе будет лишь чуть большее понимание произошедшего.

Завязка драмы

Облако «Instant Servers» Webzillа. Рутинное обновление хоста nova-compute. Новый live image (у нас используется PXE-загрузка), отработавший шеф. Всё хорошо. Внезапно, жалоба от клиента: «одна из виртуалок странно работает, вроде работает, но как начинается реальная нагрузка, так всё замирает». Инстансы клиента переносим на другую ноду, проблема клиента решена. Начинается наша проблема. Запускаем инстанс на этой ноде. Картинка: логин по ssh на Cirros успешен, на Ubuntu — зависает. ssh -v показывает, что всё останавливается на этапе «debug1: SSH2_MSG_KEXINIT sent».

Все возможные внешние методы отладки работают — метаданные получаются, DHCP-аренда инстансом обновляется. Возникает подозрение, что инстанс не получает опцию DHCP с MTU. Tcpdump показывает, что опция отправляется, но не известно, принимает ли её инстанс.

Нам очень хочется попасть на инстанс, но на Cirros, куда мы можем попасть, MTU правильный, а на Ubuntu, в отношении которой есть подозрение о проблеме MTU, мы как раз попасть не можем. Но очень хотим.

Если это проблема с MTU, то у нас есть внезапный помощник. Это IPv6. При том, что «белые» IPv6 мы не выделяем (извините, оно пока что не production-ready в openstack), link-local IPv6 работают.

Думали ли вы когда-нибудь о том, что однажды слишком быстро втянулись в веб-программирование на PHP? И вот уже прошло много лет, у вас хороший опыт, и вы не думаете ни о каких других способах „делать“ веб, кроме как на PHP. Может быть, у вас возникают сомнения в правильности выбора, однако непонятно, как найти способ быстро его проверить. А хочется примеров, хочется знать, как изменятся конкретные аспекты деятельности.

Сегодня я попробую ответить на вопрос: «А что если вместо PHP писать на Python?».

Сам я долгое время задавался этим вопросом. Я писал на PHP 11 лет и даже являюсь сертифицированным специалистом. Я научился его «готовить» так, чтобы он работал в точности, как мне надо. И когда я в очередной раз читал на Хабре перевод статьи о том, как всё в PHP плохо, я просто недоумевал. Однако подвернулся случай пересесть на Ruby, а потом и на Python. На последнем я и остановился, и теперь попробую рассказать вам PHP-шникам, как нам питонистам живётся.

И снова в эфире наша постоянная рубрика «Лекции Технопарка». На этот раз предлагаем вам ознакомиться с материалами курса «Проектирование высоконагруженных систем». Цель курса — получение студентами навыков проектирования высокоэффективных программных систем.

Сегодня ночью завершилась первая игра отборочного тура Yandex.Root — олимпиады для Unix-инженеров и системных администраторов. В ней приняло участие 456 человек из 229 команд, 194 из которых выполнили хотя бы одно задание. Со всеми девятью справилось 38 команд.

Мы проводим Root в четвёртый раз, но впервые решили опубликовать на Хабре разбор тасков. Задачи, которые мы даём на олимпиаде, сопоставимы с теми, что регулярно решают наши системные администраторы. В Яндексе почти каждый день что-то выкатывается и, когда что-то идёт не так, нужно оперативно распознать это и эффективно отреагировать.



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

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

Игра Shannon

Мы решили назвать все игры в память о людях, которые внесли вклад в современные технологии, которые используются в нашей работе. Эта посвящена Клоду Шеннону, инженеру и математику, который среди прочего подарил нам слово «бит». Кстати, сам сервис root.yandex.ru запущен на compute узлах private cloud Яндекса.

На волне популярности Docker на Хабре, после участия в некоторых дискуссиях в комментариях относительно Docker, и в связи с недавней необходимостью настроить централизованную авторизацию для кластера Linux машин, я решил написать небольшую заметку. Здесь будет показан яркий, на мой взгляд, пример применения Docker'a для небольшой частной задачи.

Вот так, кстати, выглядит FreeIPA WebUI (официальное демо) (кликабельно):



Какие задачи я хотел решить при помощи FreeIPA:

1. Иметь возможность создавать/изменять/удалять акаунты пользователей централизовано, а не на каждом отдельном сервере
2. Централизованные плавила для sudo
3. В последствии мы подключим к этой системе ещё и VPN авторизацию, а потом может и другие внутриофисные сервисы

Да, скорее всего FreeIPA в нашем случае это выстрел пушкой по воробьям, но с другой стороны — альтернатив что-то не видно. Я рассматривал такие варианты: NIS (по-моему он уже давно должен отправиться на отдых), OpenLDAP +… +… (не очень дружелюбно, да и FreeIPA в итоге под собой имеет LDAP, только нам не приходится с ним иметь дело напрямую), тут перечень заканчивается, я не нашёл ничего больше.

Относительно недавно я опубликовал небольшую статью «Курс молодого бойца. Практический курс по Cisco Packet Tracer». Там я рассказал об опыте создания обучающего курса для внутренних нужд организации. Основная цель курса — быстрая подготовка специалиста к «полевым работам». Уроки параллельно публиковались на YouTube в свободном доступе. Сам проект получил название NetSkills. После публикации на канал YouTube добавилось больше 2-х тысяч подписчиков. Я получил отличный фидбэк (такой, что еле справился) и стимул довести дело до конца.



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

Некоторое время назад, в силу определенных причин, мне пришла в голову мысль о том, чтобы начать изучать какой-нибудь новый язык программирования. В качестве альтернатив для этого начинания я определил два языка: Java и Python. После продолжительного метания между ними и сопутствующих нытья и долбежки головой о стену (у меня с новыми языками всегда так — сомнения, раздумья, проблема выбора и т.д.), я все-таки остановился на Python. Окей, выбор сделан. Что дальше? А дальше я стал искать материал для изучения…

Как известно, для обработки соединений NGINX использует асинхронный событийный подход. Вместо того, чтобы выделять на каждый запрос отдельный поток или процесс (как это делают серверы с традиционной архитектурой), NGINX мультиплексирует обработку множества соединений и запросов в одном рабочем процессе. Для этого применяются сокеты в неблокирующем режиме и такие эффективные методы работы с событиями, как epoll и kqueue.

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

Каждый процесс расходует память и каждое переключение между ними требует дополнительных циклов процессора, а также приводит к вымыванию L-кэшей

У медали есть и обратная сторона. Главной проблемой асинхронного подхода, а лучше даже сказать «врагом» — являются блокирующие операции. И, к сожалению, многие авторы сторонних модулей, не понимая принципов функционирования NGINX, пытаются выполнять блокирующие операции в своих модулях. Такие операции способны полностью убить производительность NGINX и их следует избегать любой ценой.

Но даже в текущей реализации NGINX не всегда возможно избежать блокировок. И для решения данной проблемы в NGINX версии 1.7.11 был представлен новый механизм «пулов потоков». Что это такое и как его применять разберем далее, а для начала познакомимся с нашим врагом в лицо.

Вот уже как неделю английская версия the art of command line висит в секции trending на Github. Для себя я нашел этот материал невероятно полезным и решил помочь сообществу его переводом на русский язык. В переводе наверняка есть несколько недоработок, поэтому милости прошу слать пулл-реквесты мне сюда или автору оригинальной работы Joshua Levy вот сюда. (Если PR отправите мне, то я после того, как пересмотрю изменения отправлю их в мастер-бранч Джоша). Отдельное спасибо jtraub за помощь и исправление опечаток.

Если посмотреть на интерактивную карту текущих кибер-атак, происходящих в мире, в режиме реального времени, то становится очевидно, что единственное место, где нет криминальной кибер-активности на Земле – это Антарктида. 2014 год был богат на громкие взломы и утечки данных. Взлом Apple iCloud с последующим выкладыванием в сеть интимных фотографий разных известных людей, утечка данных 80 миллионов клиентов из JP Morgan, троян в Regin на компьютерах администрации ЕС, взлом eBay, взлом Home Depot, DDoS-атака на сайт Кремля, взломы сети Московского метро и т.д. Однако взлом Sony Entertainment замечателен тем, что за последние три года инфраструктура компании взломана уже как минимум третий раз. Поэтому, прежде чем говорить о современных средствах сетевой защиты, я кратко опишу стратегию реализации сетевой атаки на примере одной из самых известных атак последнего времени – атаки на Sony Pictures Entertainment 2014.

Несколько слов о том, что, собственно, произошло. В пятницу, 21 ноября 2014 года, руководители Sony получили письмо с предложением заплатить определённую сумму за то, чтобы ИТ-инфраструктура Sony избежала «массированной бомбардировки». Письму не придали значения, у многих руководителей оно попало в спам, но уже 24 ноября 2014 года сотрудники Sony, придя в понедельник утром на работу, увидели у себя на мониторах следующую картинку:

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

Как это произошло и, главное, почему?

Мы уже рассказывали на Хабре про выпуск Veeam Endpoint Backup Free (бесплатного инструмента резервного копирования для физических рабочих станций, ноутбуков и домашних компьютеров). Сегодня я хочу рассказать об этом продукте более подробно: об архитектуре, основных настройках заданий резервного копирования, параметрах расписания, о схеме резервного копирования, и об интеграции с Veeam Backup & Replication v8 (если он установлен).

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

Первое, что я заметил — множество советов как все настроить под большую нагрузку. Читайте их внимательно, обычно в тексте найдете, что речь про «высокую нагрузку» в 15-20 тысяч клиентов в сутки. У нас клиентов примерно миллион, активных, ежедневных.

У нас нет денег и мы все делаем за свой счет, поэтому экономим. Итог — весь миллион клиентов обслуживается на одном сервере, вот на таком — EX-60 на hetzner.

После выхода mysql 5.6 с его GTID (global transaction identifier) репликация в mysql перестала быть кошмарным сном сисадмина и стала вполне рабочим инструментом. В инете есть некоторое количество информации по этому поводу, но вся она довольно разрозненная и не всегда доступна для понимания. По этому я решил сделать небольшую инструкцию-выжимку, больше для себя, но может и еще кому пригодится.

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

Материал разбит следующим образом:

1. Введение
2. Примеры сессий
3. Проверка авторизации на сервере (LOGIN, PLAIN, CRAM-MD5), Base64
4. Проверка шифрования SSL/TLS
5. Анализ почтового трафика при помощи tshark. Расшифровка SSL/TLS
6. Ссылки на материалы

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

Предыстория

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