Раз уж вчера читали про systemd, давайте сегодня про системный вызов fork()

Описание: http://bit.ly/2SCJt6i

Изучаем процессы: http://bit.ly/39qhP3w

Про rpython - python с JIT https://dantealighierin.github.io/rpython.html

Перевод статьи про etcd от jepsen, которую я посетил ранее https://habr.com/ru/post/487534/#etcd

Поддержка мета запросов в Grafana (типа Moving Average) - может быть интересным https://github.com/GoshPosh/grafana-meta-queries

CVE-2019-11043: вы, скорее всего, подвержены

Никогда такого не делал, и вот опять. Советую обратить внимание на уязвимость, которая скорее всего где-то у вас будет воспроизводиться. Это очень жесткий и простой эксплойт.

Итого, что нужно:
1) nginx
2) php-fmp
3) php файлик, который будет отдавать 200 OK
4) php -v <7.2.24 & <7.3.11

Итого, если у вас есть стандартная связка nginx + php-fpm и что-то на PHP7 с версиями, которые я указал, и еще есть /ping.php (или любой другой эндпоинт, который возвращает 200 OK) - нужно чинить ASAP. Таким образом можно экзекнуть любую команду в этом окружении.

Этой тулзой можно проверить:
https://github.com/neex/phuip-fpizdam

Более детально:
https://www.trendmicro.com/vinfo/hk-en/security/news/vulnerabilities-and-exploits/php-fpm-vulnerability-cve-2019-11043-can-lead-to-remote-code-execution-in-nginx-web-servers

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

Всем безопасности!

Крутотень!

Diagram as Code for prototyping cloud system architectures
https://github.com/mingrammer/diagrams

Люблю такое

pgagroal is a high-performance protocol-native connection pool for PostgreSQL

https://github.com/agroal/pgagroal

Если вы помните, пару недель назад я публиковал пост, где написал, что мне предоставили возможность сходить на курсе Slurm по SRE. Так вот, я сходил и хотел бы поблагодарить организаторов за гостеприимство и рассказать о своих впечатлениях. В первый раз, когда я услышал про этот курс, мое отношение было очень скептическим - как можно за три дня, сделать из человека SRE? Позже, я подумал что в целом, опытному опсу или разработчику вполне можно за это время рассказать основные принципы - в конечном итоге, SRE book вполне читается за день-два и тогда я решил что ребята просто перескажут книжку за определенную сумму денег, что вполне себе тоже вариант для занятых людей, в дальнейшем, когда я пообщался с организаторами, я понял что они основной упор собираются давать на практику и мне стало интересно. Собственно, на курс я ехал с небольшим скепсисом (сам то я SRE book прочел достаточно давно), но забегая вперед скажу что получилось достаточно неплохо, особенно учитывая что я был на первом потоке, а про первый блин мы с вами прекрасно знаем. Теперь о курсе: во-первых, slurm взяли работающих инженеров из Booking и даже Google, что я считаю, действительно круто и избавило их от претензий касательно компетентности преподавателей, во-вторых: организация курса вполне удачная - всех участников разбили по командам из пяти человек, стараясь чтобы в одну команду не попали коллеги из одной компании, у каждой команды был ментор и отдельный чат с поддержкой для решения тех проблем, которые не то чтобы были критичны, но возникали. Теперь, что касательно, содержательной части - всех участников, делят на команды, читают теоретическую часть, которой обычно немного, и дают задание - некий "инцидент", команды должны разобраться и починить, получая баллы за решения. Сами задания выбраны вполне удачно и на мой взгляд приближенный к тому что делают SRE - не буду раскрывать подробности, но некоторые из них вполне заставили попотеть. Работать приходится с вполне "модным" сейчас стеком - Kubernetes\Prometheus\Gitlab\Grafana с проектом, который выглядит "как живой" и даже имеют документацию. Заданий очень много, времени впритык да и организаторы вводят дополнительные игровые элементы стресса, так что скучать не придется. Темп курса вполне себе интенсивный - к третьему дню я понял, что даже успел подустать. Что понравилось - вполне релевантные задачи и достаточно реалистичные условия, теория без "отсебятины" и повторяет то что есть в книге, да и вообще в общем доступе. Не было ощущения "снежного кома", когда у тебя не выходило справиться с заданиями - давались подсказки, затем, по истечению времени, давались решения и дополнительное время на то чтобы их выкатить. Очень весело работать именно командой - мне с ребятами вполне повезло, мы легко нашли общий язык и работали вполне слаженно,  хоть и не сразу. Что не понравилось: все таки темп великоват, как мне кажется, но это конечно субъективно. Так же были шероховатости касательно заданий и времени на них отведенных, подсчета баллов, но это явно проблемы первого потока и в дальнейшем это решат, я уверен. Подведу итог: если вы, как я писал выше, опытный системный администратор, который не боится кодить, бекендер, который хочет расширить свой scope или devops (AKA человек-методология) - приходите, вам точно понравится. Если вы не знаете технологий, которые используются в стеке курса или никогда не программировали, вам будет сложно. Точно не стоит на курс идти тем, кто в индустрии совсем недавно, курс совсем не для новичков - скорее всего вы будете балластом в команде и кроме сумбурной мешанины в голове у вас ничего не останется. Не подойдет он уже и тем кто сейчас уже работает SRE - курс рассчитан на ознакомление с практиками и есть риск что все происходящее вам очень напомнит работу ;) В целом впечатления остались положительные, пообщался с тиммейтами, среди них есть ребята из регионов - они тоже довольны и считают курс более чем полезным, собираются теперь нести SRE на местах #sre #slurm

📚 BPF Performance Tools. Linux System and Application Observability. Brendan Gregg. #книга

[Из песочницы] Понимание итераторов в Python
https://habr.com/ru/post/488112/
Tags: Python, python, iteration, generators, sequences
Author Xezed #habr

Давно про Kubernetes не было.

WKSctl - инструмент для управления Kubernetes кластерами с использованием GitOps.

Под ногами у неё Cluster API, то есть сначала создается "управляющий кластер", который уже будет разворачивать остальные.

В добавок интервью с разработчиками на InfoQ

#kuberentes

GitHub CLI

GitHub запускают официальный CLI. Выглядит адекватно, написан на Go.

https://github.blog/2020-02-12-supercharge-your-command-line-experience-github-cli-is-now-in-beta

Код: https://github.com/cli/cli

​​Немного про диетическое мясо и легкий, теплый мех - про RabbitMQ

Я разделю эту тему на 3 потока сознания, ищите по тегу #rabbitmq

На днях занимался обновлением кластеров кролика с версии 3.7.6 до 3.7.23

При обновлении есть что учесть, к примеру версию Erlang/OTP. Полный changelog по версиям можно посмотреть тут: http://bit.ly/39xrR2T

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

В чем же проблема спросите вы? Пишем в конфижек:

queue-master-locator: min-masters

или

queue-master-locator: random

Именно так в конфиге и стоит писать, и при первичном создании очередей мастер очередь действительно попадет куда её просят. Однако внимательный читатель вспомнит, что мастер очередь после падения, уедет жить туда, где её реплика живет дольше всех. Итак «собери их всех»: после последовательного обновления хостов кластера (или просто рестарта хостов) мы получим все мастер очереди на одном хосте с самым высоким uptime. Сами они не разъедутся, даже если очень попросить. И даже если «денек подождать». Ну не рассосется оно.

Официально предложенное лекарство это создание policy с указанием:

ha-mode: nodes
ha-param: список хостов

Про все выше написанное в доке кролика: http://bit.ly/2vuKhCI

Кто сталкивался и решал эту проблему - напишите пожалуйста свои варианты в чат @chiki_briki_chat или личку @the_asten С удовольствием почитаю, а потом напишу как решил эту проблему у себя.

p.s. Пожалуйста не предлагайте мне манную кафку, я ею с детства закормлен 😄

Записи докладов с CNCF Minsk #5

First part: Cloud Security Posture Management - Aleksandr Slobodanyuk, Senior Security Systems Engineer.
• CSPM - general overview
• Overview of commercial and opensource tools
• How does it work?

Second part: Infrastructure as Code Security - Michael Yudin, Senior Security Systems Engineer & German Babenko, Senior Security Systems Engineer.
• Infrastructure as Code intro
• Security in IaC
• IaC security tools: AWS demo, GCP demo
• Verifying of Terraform code for AWS Cloud with integration of security code scanning tools in IaC pipeline.

https://www.youtube.com/playlist?list=PLwjWMHa5_FX88yf3fapksH9M1OIGM1aNi

PS. на русском
https://habr.com/ru/post/487116/

Цикл из 3 статей о go-micro. 😆

👉 https://itnext.io/micro-in-action-getting-started-a79916ae3cac
👉 https://itnext.io/micro-in-action-part-2-71230f01d6fb
👉 https://itnext.io/micro-in-action-part-3-calling-a-service-55d865928f11

Очень крутой и интересный долад про chaos engineering в  командах. Автор предлагает ломать не только системы, но и команды
https://www.youtube.com/watch?v=sn6wokyCZSA
#chaosengineering