#devops #troubleshooting #база #одинденьизжизни

Иногда появляются проблемы, которые нельзя быстро решить.
Они неожиданные и вступаешь в ступор "а как какать?".


У нас много подключенных SaaS и интеграций.
Время от времени приходят разные коллеги и просят добавить/обновить DNS записи.
Например интеграция с каким-нибудь chargebee  или hubspot чем бы это не было. Да тысячи их, я даже не знаю чо они делают.

В основном задача состоит из двух типов записи:
- добавить новый CNAME
_E2E2BURMALDADZHIGURDA SOMEDOMAIN.COM
- обновить существующий TXT добавив туда новый хост
"v=spf1 include:outlook.com include:hubspotemail.net include:chargebee.com ~all\""

В общем-то ничего сложного,
Стек на тераформе и легко пилю MR, где добавляю, получаю аппрув, качу в мейн и ..а всё отлично, какие ещё и.

Спустя время прибегают сейлзы/саппорт с большими глазами, говорят не доходят часть почты, а это критикал.
🔥🔥🔥
Бежишь смотришь пайплайн - всё ок, тераформ всё раскатал, валидация прошла, все чеки тоже прошли - всё чисто.
nslookup, dig - базовые привычные команды проверки показывают, что всё ок.

Ну магии не существует, пошли на https://mxtoolbox.com/
Пацаны не даром свою зарплату получают (в отличии от меня, лол), и сайт показывает ошибки нарушения контракта.😞

Ошибка, что адресов уже много и пррривет, RFC, и его лимиты.
Дальнейший поиск меня приводит к неизвестному мне ранее
https://datatracker.ietf.org/doc/html/rfc7208

Оказывается есть лимиты и тут. Сука.

RFC 7208 (спека на SPF) прямо говорит: суммарно можно использовать не больше 10 механизмов, которые дёргают DNS - include, a, mx, ptr, exists, redirect.
И считается это не построчно, а рекурсивно - если внутри одного include спрятан ещё include, он тоже идёт в зачёт. Круто, да? Я сам в охере.

То есть в самой записи можно хоть 100 include понаписать - терраформ смолчит, все валидации пройдут, все провайдеры (клаудфлер в данном случае) скажут ок, MR смержится, ревьюер поставит approve, всё ок. Даже на клаудфлер появится. А хлебнёшь ложку говна уже на проверке письма: получатель досчитывает до 10го lookup и такой "аригато, дальше не считаю" - permerror. Причём не сразу и не у всех - где-то письма улетают в спам, где-то тихо дропаются. Полный рандом, сука. Предполагаю из-за разных политик корректных МТА.

Ок, причину мы нашли, быстро ревертаем коммит, проверяем через https://mxtoolbox.com/ и нам показывают, что всё хорошо.

Ок, мы вернули как было, успокаиваем продажников и саппорт и думаем - "а как быть дальше?" Задачу надо решить.

Вот так сходу есть две мысли
- узнать каким-то образом - все те SPF записи в TXT нужны ли нам - не можем ли мы что-то удалить, чтобы добавить нужное? 😏
- как-то эээ по сабдоменам уровнем ниже разнести записи, ну типа того

Слава вселенной - всё в гите и можно узнать по каждому добавлению SPF кто и когда добавлял. Есть название таски, автор. Идём в личку в слак всем людям, спрашиваем "а эта запись ещё нужна? Модем ли мы дропнуть или ещё используем?".

К счастью в этом случае нашли 1 запись, которая 100% не нужна и больше не используется, дропнули её и добавили новую по задаче.

Как быть при следующем добавлении следующей SPF записи и все они нужны?
А хз, я там уже не работаю 😬

Я и правда честно - не знаю, варианты те же в голове:
- развести интеграции по поддоменам со своим SPF (типа mail.PARTNER.SOMEDOMAIN.СOM), а не тащить всё в основной домен
Тогда, предполагаю, каждый поддомен считает свои 10, а не делит один лимит на всех, но это надо проверять.
- завести привычку прогонять запись через mxtoolbox перед каждым новым includ
- тупорылые танцы со статикой IP, но это статика, шанс инцидента при смене адреса возрастает в 10 раз

Итоги:
- иногда подстава откуда не ждёшь, никакие штатные валидаторы тебе не покажут потенциальную ошибку. В этом случае нам даже впаяли инцидент 😔
- RFC это боль, сколько раз я уже в своей практике упирался в какие-либо лимиты
- если бы не гит-блейм по таскам - чистили бы SPF вслепую.
Инвестируй в IAC - трейсинг "кто и зачем добавил" окупается на все 100% ровно в такие моменты. Git+IaC=❤️

и да, иногда никакого куберентиса 😀

Дуров тоже молодец.
Захотел я поправить ссылки некрасиво отправленные выше..

Если править через "новый редактор макрдаун в телеграме" - текст заметки просто уничтожается без права восстановления.
😬

#ai #devops

Раз в 2-3 недели гоняю команду
/insights
в claude code.

Она парсит все мои сессии за последние дни и выкатывает наглядный html-отчёт без лишней воды: сильные стороны, где я реально эффективен, где просаживаюсь, что можно заавтоматизировать, какие бэд-практисы проскакивают.

Отдельно подскажет, чем обогатить CLAUDE.md, как лучше структурировать контекст, где утекают токены и время, и какие паттерны повторяются из сессии в сессию, какие скиллы новые запилить на повторяющиеся задачи.
Научит новым промптам.
Подсветит боли и фрустрации как на скрине 😀.

Смотрю, где стал лучше, где наоборот деградировал, и по итогу подкручиваю промпты, сетап и подход к работе.
Реально держит систему в тонусе, а не работу по инерции.
Если с английским не очень - гугл-переводчик отчёт нормально осилит.

Рекомендация - 10 из 10.

Для кодекса и курсора есть НЕ нативные аналоги, но я сам их не тестировал, лишь видел в чатах обсуждение:
- https://github.com/tim-hilde/opencode-insights
- https://github.com/rapidrabbit76/OpenCodeInsights


- - -
Всегда стрёмно такое постить - сейчас вокруг все дохера умные, что ни напиши - "я и так знаю".😬
А простейшая нативная фича - никто не в курсе среди моих знакомых (на работе, я уверен, все в курсе).
Тонкая грань между "база-базная" и "о, а я не знал" 🦍

#бытовое

Когда-то давно я подсел на браузер Chrome и долго на нём сидел.
У меня была целая коллекция закладок.

Как безумный, собирал все интересные ссылки, что попадались мне в интернетах:
- 15 постмортемов от крупных инцидентов и детальным разбором каждого
- как сделать лазер своими руками из DVD-привода
- список всех linux capabilities
- сайт для поиска авиабилетов
- виза в Канаду и что для этого нужно
- все адмишн контроллеры кубера и что они делают
- вебкамеры у подъезда
- чейнджлог кубера 1.19-1.29
- как выучить корейский за 40 уроков
- генерация блоков для комментов
- топ книг для систем дизайна и архитекторов
- грокаем алгоримы %авторнейм%

И тысячи прочей информации.

Всё это было разложено по директориям, внутри которых тоже были директории. Максимально эффективно и понятно - разобрался бы даже посторонний человек, получивший доступ к закладкам. Была даже директория TODO на потом почитать. Всё интересное, на что не хватало времени сразу, закидывал туда. Ага, может, у кого-то тоже такая была или есть.

За многие годы директорий стало больше 60, а закладок больше 2000.

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

Начал разбираться и с грустью понял, что половиной не пользовался уже несколько лет, а 30-35% вообще недоступны - 404 или домена больше нет 🤡.

Сперва немного посидел, сам потыкал руками, потом сделал бэкап закладок, экспортировал их и скормил нейронке - она прошлась по ссылкам курлом в цикле и убрала кучу неактивных. Я снова импортировал, закладок стало около 1100.

Оглядев всё это, почистил TODO-лист, освободил ещё сотен пять, наверное. Потом прошёлся по разделам, посмотрел, какие мне вообще нужны, и снёс целые директории.

Когда закладок осталось около 400, убрал ещё часть директорий - тех, что были уже не нужны для деления на категории. Потом задумался: а заходил ли я по этим ссылкам хоть раз за последний год? В общем, руками удалил то, чем давно не пользовался.

В итоге у меня осталась всего одна директория Alex (так удобнее на панели закладок), внутри - 5 поддиректорий и суммарно около 70 закладок, которыми пользуюсь регулярно. Временные TODO-закладки кидаю прямо на панель, и если не пользуюсь ими - по пятницам чищу, оставляя только директорию Alex.

Поработал так несколько недель и понял, что ничего и не поменялось. Что 70 закладок, что миллион. Бекап закладок улетел в дальний архив.

Я удалил примерно 95% своих закладок. Оставил исключительно то, что использую.
Грустно, но, вероятно, иногда стоит сбросить уже ненужный груз истории.😢
С появлением хороших машин для поиска информации (я всё ещё гуглю) и, особенно, доступными бесплатными нейронками, хранить закладки "на всякий случай" уже немного бессмысленно.

А на Сафари я так и не переехал 😬

#longread #devops #troubleshooting #одинденьизжизни

Пересечения.

У нас на работе много проектов.
На части из них я как выделенный инженер (был), частично могу кого-то заменять на соседних проектах.

Однажды коллега с соседнего проекта ушёл в длительный отпуск.
На время отпуска меня попросили быть заменой:
- мне выделили все доступы к куберам
- перминш сеты к аккаунтам амазона
- добавили в доменные группы гугла
- дали все ключевые url адреса
- ну и гитлаб, куда без него, дали права девелопера ко всему

Провели небольшой онбординг за полчаса, в целом не так сложно быть заменой, проект пока вроде не в проде, так что критикал нет ничего.
Я проверил все адреса, к волту, к UI фронта и так далее - всё ок.

Жизнь несправедлива и человек из отпуска так и не вернулся, прошла волна увольнений, смыв с борта часть команды.
Так бывает 😢

Спустя время на этот проект пришёл новый человек (ну его с 2 проектов подвинули сразу на 4 что-ли, лол).
Меня попросили его заонбордить, так как предыдущего инженера уже нет.
Немного странно (я знаю буквально ничего), но ок.

Я просто повторил ровно то, что делали мне - сделал заявки на доменные группы гугла, репозитории гитлаба, куберы - в общем всё то же, тупо скопировав из системы саппорт заявок и джиры.

Приходит этот новый инженер ко мне и говорит:
- сюда есть доступ, сюда есть, туда тоже ок, а вот UI интерфейсы продукта - доступа нет.

Ну странно.
Самое странное, что у меня то есть доступ - мы визуально равны по правам.

Проверяем все группы на https://groups.google.com - у нас одинаковые, связанные с этим проектом.
Рестарт ПК, рестарт тейлскейла - никакого эффекта.

Пишем заявку девопсам:
- так и так, вот ссылки на заявки, вот такие группы у меня и у него, вот такие адреса

Вспоминаю, что была какая-то табличка в гугл докс - прикладываю и её, типа вдруг поможет. Табличка просто содержит подсети по всем проектам - бронь, кому что надо.
Сам почти никогда не пользовался - все подсети по аккаунтам нарезаны были на всех проектах до меня и без меня.
Спустя полчаса девопс пишет - всё исправил - не хватало подсетей в tailscale.
Ещё через пара минут новый инженер пишет, что всё ок (ну и там ещё пара человек заодно, кто пришёл на проект).
В фоне смотрю в гитлаб репозитория - там МР на добавление в конфиг тейлскейла:

{ // projectname 111
  "src": [
    "group:project1-prod@domain.com",
    "group:project1-qa@domain.com"
  ],
  "dst": [
    "10.******/16",
    "10.******/16",
    "10.******/16"
  ],

Проблема решена.
У всех доступы есть, все довольны.

- - -
Решил все дела на работе и пошёл пить чай. Пью и думаю:
ну ведь магии не бывает, я то имел доступ к этим сайтам по продукту.
Как так-то? Что за бред? У меня был доступ и до и после исправлений. Херня какая-то.

Эта мысль буквально не давала мне покоя до вечера и рано утром я радостным щеночком побежал разбираться.
Я посмотрел конфиг тейлскейла и буквально сразу, поиском, понял, где тут ошибка.
Первые два октета совпадали с одним моим текущим проектом 😬
То есть в конфиге тейлскейла было ещё и

{ // projectname 222
  "src": [
    "group:project222-stage@domain.com",
    "group:project222-prod@domain.com"
  ],
  "dst": [
    "10.******/16",
    "10.******/16",
    "10.******/16"
  ],

Абсолютно те же подсети!

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

Пишу новому инженеру на проект:
- ты только пришёл сюда, а у тебя уже есть техдолг: целым аккаунтом Х в AWS переехать на другие подсети, с полным пересозданием всех ресурсов ))))😂🤣

- - -
До сих пор не знаю, что реально меня триггенуло разбираться дальше после "проблема решена":
- то, что уволенный инженер месяц-полтора назад намекал/говорил про пересечение подсетей, а я это забыл и где-то в глубине подсознания я всё же знал ответ
- то, у меня большое любопытство и мне неспокойно, когда решение есть, а объяснения нет

#security #docker #devops и немного #всратость

Заметка носит скорее исследовательский и развлекательный характер.
Никакого поиска правды, настаивании на этом мнении или призыва к действию.


Однажды приходит алерт от инфобеза: критическая уязвимость, CVE-666lupa666pupa в zlib, надо фиксить.

Смотрю: zlib - это какая-то неизвестная мне хрень.
Возможно и инфобезе, может и никому.
Дебиан букворм держит zlib1g 1.2.13, в которой этот CVE есть.
Триви его видит, алерт красный, белки-истерички кричат и бегают по кругу.

Говорю инфобезу: это нас не касается, камон.
Во-первых, статус в самом триви - will not fix.
Во-вторых, есть флаг --ignore-unfixed, который именно для этого и придуман.
Мы в тот момент работали без этого флага - по какой-то причине, уже не помню.
Поэтому жалобка и прилетела. Поставили флаг + игнор файл для другой неэксплуатируемой штуки и вроде отстали от нас.
В-третьих, сканер это опционально у нас, ну чо ты, какие блокеры, иди чай попей.

Пока я пытался всё это объяснить, у меня в голове крутился вопрос:
а насколько вообще можно доверять тому, что триви находит или не находит?
Решил потом проверить.

- - -
Тест первый.
Пересобрал образ, вручную скомпилировал из сорсов прямо в имадж:

RUN apt-get update && apt-get install -y build-essential wget \
  && wget https://github.com/madler/zlib/releases/download/v1.3.1/zlib-1.3.1.tar.gz \
  && tar -xf zlib-1.3.1.tar.gz \
  && cd zlib-1.3.1 \
  && ./configure \
  && make \
  && make install \
  && ldconfig \
  && cd .. \
  && rm -rf zlib-1.3.1 zlib-1.3.1.tar.gz \
  && apt-get purge -y build-essential wget \
  && apt-get autoremove -y

Проверяю внутри контейнера - 1.3.1 там:

$ ls -la /usr/local/lib/libz*
lrwxrwxrwx  /usr/local/lib/libz.so -> libz.so.1.3.1
lrwxrwxrwx  /usr/local/lib/libz.so.1 -> libz.so.1.3.1
-rwxr-xr-x  /usr/local/lib/libz.so.1.3.1

$ ldconfig -p | grep libz
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1  <- dpkg-пакет, 1.2.13
libz.so.1 => /usr/local/lib/libz.so.1  <- скомпилированная 1.3.1

Запускаю триви - снова цве критикал 😬

Вероятно триви читает /var/lib/dpkg/status - базу пакетного менеджера.
Что реально лежит в /usr/local/lib его не интересует.
Скомпилированная версия для него невидима. Безопасность)

Наверняка это не баг - это архитектурное решение, бинарный анализ каждой библиотеки был бы на порядки дороже. Но это означает, что сканер сообщает о CVE на основе базы пакетного менеджера, а не того, что реально резолвит линкер в рантайме - а это, вообще-то, отдельный вопрос, который одним ldconfig -p не закрыть. Ну не глупость ли, а?
Сканер говорит "уязвимость есть" - а есть ли она реально в работающем процессе, это уже совсем другая история, и я её тут не проверял.

Тест второй.
Раз уж проверяем, проверим до конца.
Берём образ с реальной уязвимостью - log4shell

FROM alpine:3.18
WORKDIR /app
RUN apk add --no-cache openjdk8-jre-base wget
RUN wget https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.14.1/log4j-core-2.14.1.jar && \
  wget https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-api/2.14.1/log4j-api-2.14.1.jar
CMD ["/usr/bin/java", "-version"]

Триви весело находит три CVE:
log4shell, CVE-biba, CVE-boba. Всё верно.

Теперь берём тот же JAR с уязвимым байткодом и просто меняем строку версии в метаданных внутри архива:

RUN mkdir temp && \
  unzip log4j-core-2.14.1.jar -d temp && \
  sed -i 's/version=2.14.1/version=2.17.1/g' \
  temp/META-INF/maven/org.apache.logging.log4j/log4j-core/pom.properties && \
  cd temp && \
  zip -r ../mylog4j-core.jar . && \
  cd .. && \
  rm -rf temp log4j-core-2.14.1.jar
RUN mv log4j-api-2.14.1.jar mylog4j-api.jar

Байткод не тронут, язвимый код на месте.
Только pom.properties теперь говорит версию 2.17.1.

trivy image test:latest --severity HIGH,CRITICAL
Total: 0 (HIGH: 0, CRITICAL: 0)

Триви для джавы читает мета pom.properties внутри JAR.
Не байткод, не хэши классов - метаданные, так что поменял строку и тут же сканер доволен 😀.
Сканер говорит "всё чисто" - а уязвимость есть 🤣.

Тест третий.
Проверим ещё - го бинари.
Триви умеет читать зависимости прямо из скомпилированного го бинаря. В каком-то файле есть секция .go.buildinfo, куда компилятор записывает все модули с версиями.
Это реально удобная фича - никаких go.sum в образе не нужно, сканер находит всё сам.
Берём минимальное приложение с намеренно старой версией:

golang.org/x/net v0.0.0-20210405180319-a5a99cb37ef4

Триви после сборки находит 20 CVE только в го депенденси.

Теперь удаляем секцию билдинфо из бинаря с помощью objcopy:

RUN go build -o myapp . \
  && apt-get update && apt-get install -y --no-install-recommends binutils \
  && objcopy --remove-section=.go.buildinfo myapp myapp-stripped \
  && apt-get purge -y binutils && apt-get autoremove -y

Бинарь работает и функционально идентичен, проверяю:

$ objdump -s -j .go.buildinfo /myapp-stripped
objdump: section '.go.buildinfo' mentioned in a -j option, but not found in any input file

скан:

trivy image test-go-stripped:latest --severity HIGH,CRITICAL
Total: 9 (HIGH: 6, CRITICAL: 3)   только пакеты операционки

Все 20 гошные CVE исчезли, остались только 9 от Дебиан, которые will not fix. Безопасность 😎

На мультистейдже с финальным FROM scratch это тоже легко обходится - например, через upx, который пакует бинарь в свой формат и триви перестаёт читать билдинфо.
Суть та же: все варианты работают, сканер молчит. Безопасность 😁


Так что с итогом:
Да ничо, это просто было увлекательно. Изначальная проблема была решена чисто флагом вообще то.
А вопросы остались.
Я не говорю, что CVE сканеры имаджей бесполезны, наоборот - они полезны в штатных сиуациях.
Они находят реальные проблемы, они дают точку отсчёта, они вполне работают как первый фильтр.
Но некоторые сканеры, такие как триви, дают лишь аппроксимацию на основе сигнатур и метаданных.
И в целом они не гарантируют ничего - ни того, что уязвимость есть, ни того, что её нет.

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

- - -
Эта заметка - аккуратно переработанный текст моих старых сообщений в чате куберентис ру, но без обсценной лексики 😬.

#kubernetes #devops #sre

TLDR: это не пост с решением.
Скорее пост-размышление с очередным внутренним вопросом, на который я сам себе так и не ответил.


Прилетает алерт.
Смотрю чо там.
У него метрика простая:
kube_node_status_condition{condition="DiskPressure",status="true"} == 1
Полез смотреть - да, реально диска не хватает.

Дальше вопрос на минуту:
а чем именно забито? Логами? Эфемерными томами подов? Или это имаджи?
Смотрим ещё одну метрику:
kubelet_image_garbage_collected_total{reason="space"}

Счётчик прыгнул вверх ровно в момент алерта.
Всё, картина ясна: раздел на 200 гигов забился старыми образами (очень частые релизы, по гигалион раз в день), кублет сам это увидел, сам почистил, алерт потух.

Красота же?
Сработало как задумано: от NodeHasDiskPressure до NodeHasNoDiskPressure прошло 8 минут, ни одной ручной команды.

Но вот дальше я сижу и не понимаю, что с этим делать дальше.
В голову приходит несколько вариантов:
- увеличить диск
Поможет? Да, отодвинет проблему во времени. Но это буквально плата за то, чтобы не думать. И мы вроде не резинового бюджета контора, чтобы просто лупать гигабайты, потому что "так спокойнее".

- подвинуть трешхолды гарбаджколлектора *
стояло:

image-gc-high-threshold-percent = 85
image-gc-low-threshold-percent = 80

Много это или мало - а хуй знает.
Может, надо 60/65, чтобы чистка начиналась заранее и мы вообще не долетали до disk pressure. Может вообще поставить 40%, лол.
А может это сделает только хуже - кублет начнёт чиститься чаще, будет чаще передёргивать пул подов, которые сейчас пуллят образ.
Кстати да, у меня был страх - а не удалит ли гарбаджколлектор образ, который прямо сейчас используется живым контейнером?
По идее нет, не удалит, вроде кублетовский image GC чистит только то, что не занято ни одним запущенным контейнером. Но осадочек "а что если" всё равно остался, потому что документация - это одно, а современный вайбкод, даже в кубере, это другое.

- моё любимое - забить болт 😎
Формально всё ок: алерт мигнул и потух сам, никакого даунтайма. Disk pressure - это не баг, это фича, механизм ровно для этого и придуман.

- вырубить нахер этот алерт?
Да вроде тупость. Тогда зачем я его добавлял.

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

- менять северити на инфо?
А если это реальная трабла?

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

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

Так и не знаю, какой из путей правильный.
Подозреваю, что правильного ответа тут вообще нет, есть только свой уровень принятия риска и адаптация к счёту за EBS

- - -
* Кстати я не помню, надо гуглить, а точно ли эти метрики, это случаем не эвикшн менеджер дергает триггер на imagefs.available<15%?
Или один трешхолд запускает чистку, а другой двигает метрику диск прешр?
Надо читать.