🔥 Сломали голову над медленными запросами?
Учитесь оптимизировать Greenplum у тех, кто его создаёт.

Давайте разберём одну из самых частых и болезненных проблем в распределённых базах данных: запросы внезапно начинают выполняться часами при росте данных. Частая причина — неправильная дистрибуция (распределение) таблиц в Greenplum, из-за которой система тратит львиную долю времени не на вычисления, а на пересылку данных между узлами.

Суть проблемы:
Допустим, у вас две таблицы — sales и products. Они распределены по разным ключам или случайно.

Сегмент 1: sales {A, C, E}, products {A, D}
Сегмент 2: sales {B, D, F}, products {B, C}

➡️ При join по product_id системе придётся "гонять" почти все строки между серверами (reshuffle). Это и есть главный тормоз.

Как это выглядит в коде (проблемный вариант):

-- Таблицы созданы без общей стратегии дистрибуции
CREATE TABLE sales (sale_id bigint, product_id int, amount decimal)
DISTRIBUTED RANDOMLY; -- или DISTRIBUTED BY (sale_id)

CREATE TABLE products (product_id int, name text)
DISTRIBUTED BY (product_id);

💡Решение — контроль дистрибуции от создателей технологии:
Эксперты Yandex Cloud покажут, как проектировать схему с самого начала, чтобы соединения работали локально.

-- Правильная дистрибуция по общему ключу соединения
CREATE TABLE sales_opt (sale_id bigint, product_id int, amount decimal)
DISTRIBUTED BY (product_id); -- Теперь product_id совпадает с products!

CREATE TABLE products (product_id int, name text)
DISTRIBUTED BY (product_id);

Результат: Данные с одинаковым product_id лежат на одном сегменте. Join выполняется локально, ускоряясь в десятки раз.

🎯 Где вы научитесь такому подходу? Только на курсе, разработанном и проводимом командой Yandex Cloud.

Это не просто теория. Это официальная программа от Yandex Cloud, где:
🔹 Все практические работы выполняются на реальных инструментах Yandex Cloud — в сервисе Yandex MPP Analytics for PostgreSQL.
🔹Вы учитесь на кейсах и best practices, которые используют разработчики этой облачной платформы.
🔹Формат этой когорты — гибридный для максимального результата:
🔹Гибкий график: Теорию и задачи проходите в удобное время.
🔹Синхронные вебинары с экспертом Yandex Cloud: Онлайн-встречи привязаны к программе, чтобы разбирать сложные моменты и давать обратную связь. Держите ритм, чтобы не отстать!

Вебинары проведёт Никита Целищев — эксперт по Big Data из команды Yandex Cloud, который ежедневно работает с сервисом Yandex MPP Analytics и знает все тонкости оптимизации изнутри.

🚀 Хотите не просто использовать Greenplum, а понимать его архитектуру и выжимать максимум производительности?

Записывайтесь на курс "Greenplum в Yandex MPP Analytics for PostgreSQL" от создателей и главных экспертов по облачной платформе.

👉 Подробнее о курсе и программе: https://rebrainme.com/courses/greenplum
💳 Оплатить по специальной цене: 55000 38 500 руб. (до 22 января включительно)

Привет!🤘

Кратко о граблях, на которые наступают даже профи. Нужно дать скрипту права root. Кажется, что это просто:

# ⛔️ ОШИБКА, НЕ ДЕЛАЙ ТАК!
sudo chown root my_tool.sh
sudo chmod u+s my_tool.sh

Эта команда ставит SUID`-бит, который должен запускать файл с правами владельца (`root`). Но с скриптами (.sh`, .py`) это не работает — ядро Linux игнорирует `SUID для них из соображений безопасности.

Хуже того, это создает ложное чувство защиты и открывает двери для атаки Path Injection.

Как `root`-скрипт отдает тебе систему
Представь, у тебя есть скрипт, который запускается через sudo и содержит вызов системной команды без полного пути:

victim_noscript.sh

#!/bin/bash
# ...какой-то код...
# Вот уязвимость:
ps aux
# ...

Атакующий делает три простых шага:

1️⃣ Создает свой `ps`:

    # Этот "ps" на самом деле запускает шелл
    echo '/bin/bash' > /home/attacker/ps
    chmod +x /home/attacker/ps
    

2️⃣ Добавляет свою папку в `PATH`:

    export PATH=/home/attacker:$PATH
    

Теперь его папка в приоритете для поиска команд.

3️⃣ Запускает твой скрипт:

    sudo /path/to/victim_noscript.sh
    

Скрипт попытается выполнить ps, найдет вредоносный файл атакующего и запустит его с правами root. Игра окончена, система захвачена.

Как делать правильно и безопасно

Всего два железных правила, которые спасут твою инфраструктуру:

1️⃣ Всегда указывай полные пути к исполняемым файлам в своих скриптах: /bin/ps, /usr/bin/systemctl и т.д.

2️⃣ Используй `sudoers` для выдачи прав. Это единственный контролируемый способ.

Создай файл /etc/sudoers.d/developers:

# Дать право запускать ТОЛЬКО один конкретный скрипт без пароля
developer ALL=(root) NOPASSWD: /usr/local/bin/my_awesome_tool.sh

Это безопасно, логируется и полностью под твоим контролем.

---
Знание таких основ — это фундамент. Чтобы видеть все векторы атак, от sudo и SUID до эксплойтов ядра, и уметь им противостоять, нужно мыслить как атакующий.

Именно этому мы учим на нашем практикуме "Повышение привилегий в Linux". Только хардкор, только практика на стендах.

🚀 Старт курса уже 26 января! Успей запрыгнуть, чтобы стать на голову выше в понимании Linux.

🤘Записаться на курс

---

P.S. Мы хотим постить прямые ссылки на самые сочные материалы в сторис, но для этого Телеграм просит "бусты". Если наши посты тебе полезны, поддержи канал своим голосом! Это быстро и бесплатно.

🚀 Бустануть канал Rebrain

Спасибо! 💪

🟡 Анонс открытых практикумов на следующую неделю

1️⃣ Keycloak: часть 3
↘ Регистрация

Время проведения:
27 января 2026, вторник, 19:00 по МСК

Программа практикума:
🟢Интегрируем apiserver к Keycloak
🟢Настраиваем роли и группы в Kubernetes
🟢Связываем kubectl с Keycloak"

Кто ведёт?
Василий Озеров — co-Founder REBRAIN, IT-инженер с 2012 года, провёл 100+ вебинаров по DevOps и инфраструктуре.
---------------------------------------------------------------------------------------

2️⃣ Linux From Scratch: 01
↘ Регистрация

Время проведения:
28 января 2026, среда, 20:00 по МСК

Программа практикума:
🟢Получаем нужные пакеты для создания окружения
🟢Получаем нужные патчи для создания окружения
🟢Настраиваем пользователя для создание окружения

Кто ведёт?
Андрей Буранов — системный администратор в департаменте VK Play, 10+ лет опыта работы с ОС Linux, 8+ лет опыта преподавания. Входит в топ 3 лучших преподавателей образовательных порталов
---------------------------------------------------------------------------------------

3️⃣ HTTPS в Angie и Nginx
↘ Регистрация

Время проведения:
29 января 2026, четверг, 19:00 по МСК

Программа практикума:
🟢Теория TLS: шифры, версии;
🟢Оптимальная настройка TLS;
🟢Особенности реализации Kernel TLS;
🟢Получение бесплатных сертификаты с помощью различных инструментов;
🟢Создаём самоподписные сертификаты;
🟢Используем модуль ACME от Angie;
🟢Настраиваем аутентификацию по TLS-сертификату (mTLS).

Кто ведёт?
Николай Лавлинский — Технический директор в ООО “Метод Лаб”. Веб-разработчик более 15 лет. Спикер конференций HighLoad++, РИТ++

Привет! 🤙

Мы с вами уже говорили про sudo и скрытые угрозы типа Capabilities. Но сегодня я хочу затронуть слона в посудной лавке — Docker 🐳

Все мы любим Докер. Но часто ради удобства (или лени) мы прокидываем доступ к Docker сокету внутрь контейнеров или даем пользователям группу docker.

⚠️ В чем проблема?
Если у пользователя есть доступ к /var/run/docker.sock или он входит в группу docker, это эквивалентно правам root на хост-системе. Без паролей, без регистрации и смс.

🔫 Сценарий атаки:
Злоумышленник (или кривой скрипт) получает доступ к сокету и запускает привилегированный контейнер, монтируя корень хостовой системы (`/`) внутрь контейнера. Всё, он владеет сервером.

🛡️ Решение: Docker Socket Proxy (Harden Configuration)

Не прокидывайте сырой сокет! Используйте проксирующий контейнер, который фильтрует запросы к Docker API. Это "флоппинет" (firewall) для вашего докера.

Ниже готовый docker-compose.yml для Tecnativa Docker Socket Proxy. Он разрешает только чтение (GET запросы) и запрещает запуск новых контейнеров. Идеально для мониторинга (Portainer, Traefik, Prometheus и др.).

📂 Конфигурация (docker-compose.yml)

version: '3.8'

services:
  docker-proxy:
    image: tecnativa/docker-socket-proxy
    container_name: docker-proxy
    privileged: true # Нужно для доступа к реальному сокету
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro # Монтируем оригинал в RO
    environment:
      # --- Политика безопасности ---
      # Разрешаем только безопасные операции
      CONTAINERS: 1  # List containers
      IMAGES: 1      # List images
      NETWORKS: 1    # List networks
      VOLUMES: 1     # List volumes
      INFO: 1        # System info
      
      # Запрещаем всё, что может менять состояние
      POST: 0        # Запрет на создание (POST)
      DELETE: 0      # Запрет на удаление
      AUTH: 0        # Запрет auth
      SECRETS: 0     # Не палить секреты
      # Остальное по умолчанию запрещено образом
    ports:
      - "127.0.0.1:2375:2375" # Слушаем только на localhost!
    restart: unless-stopped
    networks:
      - proxy-net

# Пример сервиса, которому нужен доступ к докеру (например, мониторинг)
  monitoring-agent:
    image: alpine:latest
    command: ["curl", "http://docker-proxy:2375/containers/json"]
    depends_on:
      - docker-proxy
    networks:
      - proxy-net

networks:
  proxy-net:
    internal: true # Изолированная сеть

🛠️ Как это работает в продакшене:

1️⃣ Изоляция: Сервисы (мониторинг, Traefik и т.д.) больше не получают /var/run/docker.sock.
2️⃣ Доступ: Они общаются с docker-proxy:2375 внутри внутренней сети proxy-net.
3️⃣ Фильтр: Если взломанный сервис попробует сделать POST /containers/create (создать новый контейнер для побега), прокси ответит 403 Forbidden.

Совет: Если у вас Jenkins или GitLab Runner требует сокет для сборки — используйте Docker-in-Docker (dind) или выделенные ноды. Не давайте CI/CD системам прямой доступ к сокету продакшн-хоста. Это самоубийство.

---

Хочешь реально понимать, где в Linux живут уязвимости и как их закрывать, а не просто копировать конфиги с StackOverflow?

Жду тебя на курсе "Повышение привилегий в Linux".
Разберем всё: от SUID и ядра до NFS и токенов.

🗓 Старт: 26 января
👉 Записывайся тут, Стоимость всего 22 000 рублей ⛔️сегодня последний день скидки на модуль⛔️

🚀 Турбо-поиск в Dovecot или как ускорить сервер 🚀

Знакомая боль: пользователь ищет письмо за 2018 год, Thunderbird висит, а сервер выжирает диск в полку. Почему? Dovecot по умолчанию ищет "в лоб", перебирая файлы.

Решение — Full Text Search (FTS) на движке Lucene. Он быстрый, легкий, не требует Java (как Solr) и хранит индексы прямо рядом с письмами.

🛠 Настройка за 5 минут

1️⃣ Ставим плагин:`apt install dovecot-lucene` (или yum)
2️⃣ Правим глобальный конфиг (`/etc/dovecot/conf.d/90-plugin.conf`):

plugin {
  fts = lucene
  # Лайфхак: @. в whitespace_chars позволяет искать по email целиком
  fts_lucene = whitespace_chars=@. no_index=mime
  
  # Индексируем входящие сразу. Для HighLoad лучше 'no' + cron
  fts_autoindex = yes
  
  # Стемминг для русского и английского
  fts_languages = en ru
}

3️⃣ Включаем плагин в протоколах (`10-mail.conf` или `20-imap.conf`):

protocol imap {
  mail_plugins = $mail_plugins fts fts_lucene
}
# То же самое добавляем в protocol lda и lmtp!

После рестарта (`systemctl restart dovecot`) новые письма индексируются сами.

⚡ Как ускорить старые письма?
Их нужно прогнать через индексатор вручную. Осторожно, нагрузка на CPU!

# Для одного страдающего пользователя
doveadm fts rescan -u user@domain.com && doveadm index -u user@domain.com INBOX

# Для всех сразу (запускать в screen/tmux)
doveadm fts rescan -A

✅ Итог:
* Скорость: Поиск занимает миллисекунды.
* Ресурс: Диски перестают "хрустеть" I/O операциями при поиске.
* Цена: Индексы съедят ~10-20% доп. места на диске.

---

🔥 Почта — это сложная экосистема. Хочешь понимать, как тюнить производительность, интегрировать SQL/LDAP, настраивать Sieve и безопасность?

Приходи на новый курс Dovecot, материалы уже на платформе. Разбираем архитектуру, а не просто копипастим конфиги.

Как приручить хаос: Импорт ресурсов и рефакторинг без даунтайма

Знакомая ситуация? Ты приходишь на новый проект, а там — классический ClickOps. Половина инфраструктуры натыкана руками в консоли облака, другая половина — в потерянных bash-скриптах. Или другой сценарий: ты решил навести порядок в коде, переименовать ресурсы, разложить всё по модулям, запускаешь plan, а Terraform радостно сообщает:

Plan: 10 to add, 10 to destroy.

У тебя холодный пот. Удалять прод нельзя. Оставлять как есть — значит плодить технический долг.

Многие в этот момент сдаются и оставляют "как есть". Но сильный инженер знает: Terraform state — это не скрижаль, которую нельзя трогать. Это база данных, которой можно и нужно управлять.

Проблема 1️⃣: "Это было создано руками"

Допустим, у тебя уже есть виртуалка в Yandex Cloud (`ID: fhm...`), созданная через UI. Тебе нужно загнать её под IaC.

Неправильно: Писать код и надеяться, что Terraform "подхватит" существующий айдишник. Он попытается создать новую ВМ и упадет с ошибкой конфликта.

Как делает профи: Использует terraform import.

1️⃣ Описываем ресурс в коде (пока можно даже пустой):

resource "yandex_compute_instance" "legacy_vm" {
  # Пока пусто, заполним после импорта, глядя в state
}

2️⃣ Импортируем реальное состояние в наш стейт:

terraform import yandex_compute_instance.legacy_vm fhm1234567890abcdef

3️⃣ Теперь самое интересное. Выполняем `terraform plan`. Terraform скажет, что хочет *изменить* ресурс, чтобы привести его к пустому конфигу. Твоя задача — дописать HCL код так, чтобы plan показал: No changes.

Проблема 2️⃣: "Хочу переименовать, но боюсь пересоздания"

Ты назвал ресурс resource "yandex_vpc_network" "net" {}, но по стайл-гайду нужно vpc-main. Если просто поменяешь имя в коде — Terraform удалит старую сеть (и всё, что в ней!) и создаст новую.

💡Решение: Манипуляции со стейтом (`terraform state mv`).

Мы объясняем Terraform, что объект в базе данных переехал по новому адресу:

terraform state mv yandex_vpc_network.net yandex_vpc_network.vpc-main

После этой команды меняешь имя в .tf файле, запускаешь plan — и видишь заветный зеленый свет без разрушений.

🚀 Terraform 2.0: Глобальная перезагрузка

Умение работать со стейтом, писать чистые модули, внедрять CI/CD и понимать, *как* это работает под капотом — это база. И именно эту базу мы полностью пересобрали.

Рады сообщить, что мы обновили курс по Terraform на 90%. Это не просто косметика, это полный рефакторинг программы.

🔗 Смотреть подробную программу (PDF)

🔗 Купить обновленный курс. Мы сделали знания доступнее. Теперь модуль стоит 30 000 ₽ (вместо 50 000 ₽).

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

Перестань бояться terraform apply. Становись архитектором своей инфраструктуры.

🟡 Анонс открытых практикумов на следующую неделю

1️⃣ EIGRP. Протокол динамической маршрутизации
↘ Регистрация

Время проведения:
3 февраля 2026, вторник, 19:00 по МСК

Программа практикума:
🟢Дистанционно-векторная маршрутизация (Distance Vector Routing, DVR);
🟢EIGRP: основные теоретические сведения;
🟢Базовая настройка протокола EIGRP."

Кто ведёт?
Андрей Шабалин — Тренер Cisco / Huawei, инструктор академии Eltex и Астра-Университета
---------------------------------------------------------------------------------------

2️⃣ Linux From Scratch - 02
↘ Регистрация

Время проведения:
4 февраля 2026, среда, 20:00 по МСК

Программа практикума:
🟢Binutils
🟢GCC
🟢Linux API Headers
🟢Glibc
🟢Libstdc

Кто ведёт?
Андрей Буранов — системный администратор в департаменте VK Play, 10+ лет опыта работы с ОС Linux, 8+ лет опыта преподавания. Входит в топ 3 лучших преподавателей образовательных порталов
---------------------------------------------------------------------------------------

3️⃣ Kubernetes: Service Mesh на базе Linkerd
↘ Регистрация

Время проведения:
5 февраоя 2026, четверг, 19:00 по МСК

Программа практикума:
🟢Что такое service mesh и как он работает?
🟢Почему Linkerd, а не Istio?
🟢Разворачиваем Linkerd
🟢Настраиваем авторизацию между подами

Кто ведёт?
Василий Озеров — co-Founder REBRAIN, IT-инженер с 2012 года, провёл 100+ вебинаров по DevOps и инфраструктуре.

Прокачали контент: дайджест исправлений и доработок за январь 2026

Привет, на связи команда Rebrain! 👋

Мы постоянно говорим, что мир технологий не стоит на месте. Как и наши курсы. Хотим делиться с вами какие изменения мы вносим в модули, чтобы держать вас в курсе. И вы знали, что модули проходят постоянный рефаткоринг с учетом обновлений технологий и вашей💚 обратной связи. Для нас «качество» — это не просто красивый интерфейс, а когда ты открываешь задачу и понимаешь: «Ага, вот как это работает на самом деле». Без магии и сломанных костылей.

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

🛠 Nginx
Исправили мелкие, но досадные неточности, чтобы ничего не отвлекало от настройки конфигов:
* Уточнили формулировки про кэширование (да, "backend" и "application" серверы — вещи разные, теперь в тексте порядок).
* Обновили ссылки на репозитории Nginx и скорректировали версии пакетов в примерах установки через dpkg.
* Поправили опечатки в описании флагов ./configure и блоков server.

🐳 Docker & DevOps 2.0
Фокус на актуальности образов и логике проверки:
* В примерах убрали путаницу между Ubuntu 22.04 и 24.04. Теперь версия базового образа и тега совпадают, чтобы при сборке не было сюрпризов.
* Gitlab CI: Добавили ясности в навигацию — теперь четко понятно, где искать раздел Merge Requests.
* Terraform / старая версия: Поправили форматирование .tf файлов и логику проверки состояния (state file), чтобы автопроверка работала стабильно. 🛑Новая версия уже на платформе, вы можете бесплатно обновить модуль, но без сохранения прогресса. Для это нужно написать в поддержку.
* Observability: Чиним автопроверки Grafana dashboard, чтобы ваши красивые графики засчитывались с первого раза.

☸️ Kubernetes & Helm
Больше практики и рабочих конфигов:
* Kubectl Config: Исправили ошибку с расширением файла .yaml vs .yml) при генерации конфига — теперь консоль не ругается на "no such file".
* Новые блоки: Внедряем автопроверки для блоков Helm, Canary Deploy и Argo Rollouts. Практика без обратной связи — деньги на ветер, исправляем это.

🛡 Безопасность (White Hat & Vault)
Безопасность требует точности:
* OWASP Top 10: На основе фидбека первых студентов допиливаем доступы к тачкам (SSH, VNC) и уточняем формулировки в заданиях по Injection и Broken Access Control.
* Hashicorp Vault: Исправили команды отключения аудита (пути list/ вместо команды list) и уточнили пути к ролям в БД. Раньше приходилось гадать, теперь все по документации.

🐧 Linux (Basics & Advanced)
Чтобы консоль была другом, а не врагом:
* Инфраструктура: Актуализируем инструкции по доступу к стендам (SSH vs Browser) для разных потоков.
* Systemd: В задании по траблшутингу сервисов добавили проверку статуса Nginx после перезагрузки.
* Убрали опечатки в путях конфигов (типа лишней "d" в rsyslog.conf).

🧠 Другие улучшения (Ansible, SQL, ClickHouse, Kafka)
* Ansible: Убрали категоричное заявление, что with_ — это устаревшее и запрещенное. Да, loop моднее, но старый синтаксис жив и валиден (спасибо за внимательность!).
* ClickHouse: Вернули звук в видео про масштабирование кластера (да, бывает и такое 😅) и актуализировали даты в заданиях.
* Golang Advanced: Работали над добавлением недостающих видеоматериалов по GraphQL.

Мы читаем всю вашу обратную связь, которую вы отправляете нам при прохождении курсов. Если видишь, что что-то работает не так или объяснение хромает — пиши.

Мы здесь, чтобы ты стал крутым инженером, а не чтобы ты боролся с багами в тексте задания.

Развивайся, практикуйся и не бойся ломать проды (но лучше тестовые)! 🚀

Как за 1 команду получить доступ к БД, которая слушает только localhost?

Знакома ситуация? На сервере крутится PostgreSQL, Redis или веб-интерфейс, но они закрыты и слушают только 127.0.0.1. В целях безопасности — правильно. Но как подключиться?

💡Решение — SSH-туннель. 1 команда:

ssh -L 6543:localhost:5432 user@backend-prod-01

Что произошло:

🔹На твоём ноуте открылся порт 6543
🔹Весь трафик с него шифрованно идёт на backend-prod-01:5432
🔹Подключайся в DBeaver к localhost:6543 — работает!

Делаем навсегда удобным в ~/.ssh/config:

Host backend-tunnel
    HostName backend-prod-01
    User deploy
    LocalForward 6543 localhost:5432  # PostgreSQL
    LocalForward 9100 localhost:3000  # Grafana

Теперь просто: ssh backend-tunnel -Nf и оба порта доступны локально.

Обратная задача — дать коллеге доступ к твоему localhost:

ssh -R 9090:localhost:8080 bastion-server

Почему это безопасно?

1️⃣Весь трафик шифруется через SSH
2️⃣Доступ есть только у тех, у кого есть SSH-ключ
3️⃣Не нужно открывать порты в firewall

На курсе OpenSSH разбираем туннели глубоко:
👉Local/Remote Port Forwarding (Урок 6)
👉Dynamic (SOCKS5) прокси (Урок 7)
👉Интеграция с конфигом (Урок 4)
👉Hardening для безопасности (Урок 9)

Программа: PDF
Цена 22 000₽ вместо 25 000₽ до 23 февраля: купить модуль.

Перестань бороться с доступом — начни его контролировать.