/tech/ - technology

ClipboardImage.png
[Hide] (704.7KB, 1560x871)

Prometheus Alert Hints

https://habr.com/ru/companies/bercut/articles/761080/
https://archive.is/GK7ga#selection-462.0-462.1

ClipboardImage.png
[Hide] (56.1KB, 657x333)

ClipboardImage.png
[Hide] (295.4KB, 1280x626)

Как-то я пропустил, но тут в сентябре наконец-то выпустили Falco Talon условно стабильной версии.

Falco, если кратко, мониторит системные вызовы, анализирует что происходит и выдаёт предупреждение, если что-то нарушает его правила (делает это не только для Kubernetes, но и хоста).

Раньше, после того как Falco стриггерился на что-то, надо было придумать как на алерт реагировать. Так же Falco не позволял выстроить цепочку событий, которая бы объясняла, как к событию в алерте пришли.

Например, об этом рассказывал @gecube тут
https://youtu.be/uKX8TaLJK6E?t=293

Как это можно применять можно почитать в посте от Sysdig
Optimizing Wireshark in Kubernetes
https://sysdig.com/blog/optimizing-wireshark-in-kubernetes/

Там они рассказали, как дампили трафик с помощью Wireshark, отправляли в Falco, а потом с помощью Falco Talon реагировали на то что происходит.

Опубликован корректирующий выпуск системного менеджера systemd 256.1, в котором устранена проблема, приводившая к удалению содержимого раздела /home при выполнении команды "systemd-tmpfiles --purge", добавленной в systemd 256 для удаления всех файлов и каталогов, созданных через настройки в tmpfiles.d.

В примечании к выпуску systemd 256 и в man-руководстве systemd-tmpfiles было указано, что опция "--purge" удаляет все файлы и каталоги, созданные через настройки tmpfiles.d, но название "tmpfiles" в названии утилиты вводило в заблуждение и создавало впечатление, что удаление касается только временных файлов. При этом настройки tmpfiles.d не ограничиваются временными файлами и также используются для автоматического создания несуществующих каталогов с данными. В частности, удаление содержимого домашних каталогов объясняется тем, что при помощи файла "/usr/lib/tmpfiles.d/home.conf" создавался раздел "/home" и, соответственно, команда "systemd-tmpfiles --purge" приводила к его удалению.

Первоначально сообщение об ошибке было отвергнуто Лукой Боккасси (Luca Boccassi), разработчиком systemd из Microsoft, следующим образом: "Таким образом, функция, которая буквально задокументирована как «все файлы и каталоги, созданные записью tmpfiles.d/, будут удалены», о чём вы ничего не знали, звучала как «хорошая идея»? Вы хотя бы пошли и посмотрели, какие записи tmpfiles.d у вас были заранее? Может быть, не стоит просто запускать случайные команды, о которых вы ничего не знаете, игнорируя

Представлен выпуск P2P-платформы Radicle 1.0, нацеленной на создание децентрализованного сервиса совместной разработки и хранения кода, похожего на GitHub и GitLab, но не привязанного к конкретным серверам, не подверженного цензуре и работающего с использованием ресурсов участников P2P-сети. Релиз 1.0 ознаменовал стабилизацию протокола и готовность платформы к повсеместному использованию. Начиная с данного выпуска протокол будет изменяться с сохранением обратной совместимости, а инструментарий будут включать возможности для бесшовного обновления существующих систем до новой версии. Наработки проекта написаны на языке Rust и распространяются под лицензиями Apache 2.0 и MIT. Сборки подготовлены для Linux и macOS. Дополнительно развиваются десктоп-клиент, web-интерфейс и консольный интерфейс.

Radicle позволяет не зависеть при разработке и распространении кода от централизованных платформ и корпораций, привязка к которым вносит дополнительные риски (единая точка отказа, компания может закрыться или изменить условия работы). Для управления кодом в Radicle используется привычный Git, расширенный средствами определения репозиториев в P2P-сети. Все данные в первую очередь сохраняются локально (концепция local-first) и всегда доступны на компьютере разработчика, независимо от состояния сетевого подключения.

Участники предоставляют доступ к своему коду и связанным с кодом артефактам, таким как патчи и обсуждения исправления ошибок (issues), которые сохраняются локально и реплицируются на узлы других заинтересованных разработчиков, подключённые к общей децентрализованной P2P-сети. В итоге формируется глобальный децентрализованный Git-репозиторий, данные которого реплицированы и продублированы на разных системах участников.

Для определения соседних узлов в P2P-сети применяется протокол Gossip, а для репликации данных между узлами протокол Heartwood, основанный на Git. Так как протокол основан на Git, платформу легко интегрировать с существующими инструментами для разработки на Git. Для идентификации узлов и верификации репозиториев используется криптография на основе открытых ключей, без применения учётных записей.

Каждый репозиторий в P2P-сети имеет свой уникальный идентификатор и самосертифицирован (self-certifying), т.е. все действия в репозитории, такие как добавление коммитов и оставление комментариев к issue, заверяются владельцем цифровой подписью, позволяющей убедиться в корректности данных на других узлах без использования централизованных удостоверяющих центров. Для получения доступа к репозиторию достаточно, чтобы в online находился хотя бы один узел, на котором имеется его реплицированная копия.

Узлы в P2P-сети могут подписываться на определённые репозитории и получать обновления. Возможно создание приватных репозиториев, доступных только определённым узлам. Для управления и владения репозиторием используется концепция "делегатов" (delegates). Делегатом может быть как отдельный пользователь так и бот или группа, привязанные к специальному идентификатору. Делегаты могут принимать в репозиторий патчи, закрывать issue и задавать права доступа к репозиторию. К каждому репозиторию может быть привязано несколько делегатов.

На системах пользователей Radicle-репозитории хранятся в виде обычных git-репозиториев, в которых присутствуют дополнительные пространства имён для хранения данных пиров и форков, с которыми осуществляется текущая работа. Обсуждения, предлагаемые патчи и компоненты для организации рецензирования тоже сохраняются в git-репозитории в виде совместных объектов (COB - Collaborative Objects) и реплицируются между пирами.

Radicle 1.0 включает в себя:

Разработчики дистрибутива Arch Linux объявили о переходе к прямому сотрудничеству с компанией Valve, развивающей операционную систему SteamOS, основанную на Arch Linux. Компания Valve поможет в сопровождении сборочной инфраструктуры и поддержании анклава для заверения компонентов дистрибутива цифровыми подписями. Valve предоставит дополнительные ресурсы, которые позволят развивать отмеченные области, не ограничиваясь свободным временем добровольцев.

Ожидается, что сотрудничество с Valve ускорит решение некоторых актуальных проблем дистрибутива, ускорит разработку и позволит быстрее реализовать задуманные планы. Работа над реализуемыми при участии Valve проектами будет вестись в рамках штатных рабочих процессов, принятых в сообществе Arch Linux, и модели принятия решений на основе достижения консенсуса. Для всех инициируемых при участии Valve значительных изменений будут создаваться RFC, проводиться публичное обсуждение в списке рассылки и осуществляться планирование работ через публикацию заявок (issue) в GitLab, что позволит добиться прозрачности и даст возможность сообществу контролировать ход выполняемой работы. 

---

https://www.opennet.ru/opennews/art.shtml?num=61950

Вот, как это работало: при отправке письма на портал Zendesk техподдержки компании (например, [email protected]) Zendesk создаёт новый тикет техподдержки. Чтобы отслеживать цепочку писем, Zendesk автоматически генерирует адрес reply-to, который выглядит так: support+id{id}@company.com, где {id} — это уникальный номер тикета. Благодаря этому адресу все будущие ответы будут отправляться напрямую на тот же тикет.

Также у Zendesk есть функция совместной работы над тикетами. Если добавить кого-нибудь в CC в одном из ответов на письмо, то Zendesk автоматически добавляет его к тикету, позволяя ему видеть полную историю тикета на портале техподдержки.

Эксплойт было реализовать легко: если нападающий знает адрес почты техподдержки и ID тикета (который достаточно просто подобрать, потому что ID тикетов увеличиваются инкрементально), он может применить спуфинг почты, чтобы выдать себя за исходного отправителя. Если отправить поддельное письмо на support+id{id}@company.com с почтового адреса пользователя и добавив в CC своё собственное письмо, то Zendesk подумает, что письмо подлинное. Затем он добавит почтовый адрес нападающего к тикету, давая ему полный доступ ко всей истории тикета.

Это значит, что нападающий, по сути, мог присоединиться к любой беседе техподдержки и читать конфиденциальную информацию; и всё это благодаря тому, что Zendesk не обеспечил должной защиты от спуфинга электронной почты.
. . .
В то время я обнаружил пост TICKETTRICK, написанный в 2017 году. В нём исследователь безопасности Инти Де Сёклер подробно описал, как он воспользовался Zendesk для внедрения в приватные рабочие пространства Slack сотен компаний. Так как многие компании использовали Slack SSO на том же домене, что и Zendesk, исследователь догадался, что можно выполнить почтовые верификации через почтовый адрес [email protected] и получить доступ к приватным каналам Slack. В те годы Zendesk ещё не была такой большой и существовали другие баги, позволявшие любому, кто знает ваш адрес почты, просматривать тикеты.
. . .
1. Создаём аккаунт Apple с почтой [email protected] и запрашиваем код верификации. Apple отправляет код верификации с [email protected] на [email protected] и Zendesk автоматически создаёт тикет.

2. В то же самое время создаём тикет на портале техподдержки company.com с моего собственного адреса почты, что позволяет мне отслеживать диапазон значений ID.

3. Используем баг со спуфингом почты, чтобы попытаться добавить себя во все тикеты в рамках определённого выше диапазона.

Стажер устроил саботаж на рабочем месте и принес проблем на 10 млн. долларов.

•  Программист Кейю Тянь (https://github.com/keyu-tian) устроился стажёром в компанию ByteDance (https://ru.wikipedia.org/wiki/ByteDance) (владеет TikTok) и изнутри два месяца саботировал выполнение проекта по разработке нейросетей, добавляя ошибки в код. Как сообщает BBC, Кейю успел нанести значительный ущерб — внедрял вирусы и изменял ключевые элементы инфраструктуры. Вся команда из 30 разработчиков отчаянно пыталась выяснить, откуда появляются ошибки, пока не стало ясно, что проблема внутри самой компании.

•  Один из самых коварных методов, который использовал стажер, — загрузка специальных Pickle-файлов (https://pythonworld.ru/moduli/modul-pickle.html) со скрытым вредоносным кодом. Этот код активировался случайным образом, что усложняло его обнаружение. Система начала ломаться, проекты зависали, а команда была в растерянности: казалось, что баги возникали из ниоткуда.

•  Кроме того, стажер изменил версию библиотеки PyTorch, (https://ru.wikipedia.org/wiki/PyTorch) на которой строились все проекты команды. Он вносил крохотные изменения каждый день, которые по итогу рушили все разработки. Программы перестали работать стабильно, а эксперименты давали неверные результаты. Разработчики не сразу догадались проверить исходный код, ведь ошибки выглядели настолько рандомными, что их сложно было связать с изменениями в библиотеке.

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

•  Хитрость «шпиона» была в том, что он посещал все командные совещания и следил за тем, как коллеги планируют решать проблемы. В результате, он мог заранее продумывать новые способы саботажа. Команда долгое время не подозревала, что один из своих и был причиной всех неприятностей.

•  Тем не менее, лог-файлы помогли вывести злоумышленника на чистую воду. Как только его действия были выявлены, компания уволила стажера и проинформировала его учебное заведение и отраслевые организации о случившемся. Теперь ByteDance оценивает убытки, которые составляют 10 миллионов долларов. Проект по внедрению ИИ сильно затормозился, а сроки сгорели. 

•  После того, как Тянь исключили из ByteDance, он не подвергся наказанию или порицанию со стороны своих наставников в высшем учебном заведении. Такие вот дела...

Есть такая контора southbridge. И они недавно запустили бесплатные курсы по ansible. Пошел смотреть и сначала было интересно, потом смешно, а потом уже не смешно.

Например, они говорят:

так делать плохо:
- name: Rpmcheck exclusions file templated
  template:
    src: "{{ base_sb_srv_dir }}/etc/{{ base_fix_rpm_file }}.j2"
    dest: "/{{ base_sb_srv_dir }}/etc/{{ base_fix_rpm_file }}"
    owner: root
    group: root
    mode: "0644"

так хорошо:
- name: Rpmcheck exclusions file templated

Открыл для себя циклические зависимости в ансибле! Можно смело уходить на выходные.

В общем, если сделать так:

node:
  unit:
    name: node-01
    service: "{{ node.unit.name }}.service"
    path: /etc/systemd/system/
    full: "{{ node.unit.path }}/{{ node.unit.service }}"
  drop-in:
    name: 10-drop-in.conf
    path: "{{ node.unit.path }}/{{ node.unit.name }}.d"
    full: "{{ node.drop-in.path }}/{{ node.drop-in.name }}"

Вообще все чаще думаю о переходе с ansible на nix/guix. Пора в футуре шагнуть обеими ногами.

как оказалось такой вариант править  непросто

node:
  unit:
    name: node-01
    service: "{{ node.unit.name }}.service"
    path: /etc/systemd/system/
    full: "{{ node.unit.path }}/{{ node.unit.service }}"
  drop-in:
    name: 10-drop-in.conf
    path: "{{ node.unit.path }}/{{ node.unit.name }}.d"
    full: "{{ node.drop-in.path }}/{{ node.drop-in.name }}"

похоже реально в ямле  нужно по минимуму использовать переменные

ClipboardImage.png
[Hide] (503.9KB, 563x648)

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

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

Всё началось в момент увеличивающихся вычислительных мощностей. Тогда в голову инженерам пришла мысль: а давайте все автоматизируем! Сказано - сделано. Были написаны скрипты на баше и перле. Но время шло, количество компьютеров увеличивалось, а вместе с ним уменьшался уровень образованности и интереса людей к их работе. В итоге начали появляться системы управления конфигурациями.

И вот вылупились salt, puppet и ansible. С тех пор жизнь системных администраторов кардинально изменилась и уже никогда не вернется к прежнему.

Толковым парням и девчонкам сразу было понятно: вот теперь наделаем кучу ошибок и надо как-то этого избежать. Решением стали тесты на питоне. Одноклеточные существа имитирующие облик и поведение людей просто не заморачивались. Как известно: нет тестов - нет проблем.


Отсутствие тестирования.

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

зайду с козырей

https://archive.is/fnXVz

А вот вам несколько историй с другой стороны. Я DevOps инженер с опытом более 15 лет. Когда-то давно начинал как системный администратор. Умею настраивать Linux и сети. Есть несколько сертификатов. Например Red Hat Certified Engineer (RHCE), Red Hat Certified Systems Administrator (RHCSA), AWS Certified Solutions Architect - Associate (SAA). Это для контекста. Можете погуглить RHCE Exam objectives, что бы понять объём области знаний.

Так вот, последние полгода прохожу интервью и пока ни одного оффера.

Собеседовался в один банк - завалил кодинг интервью. Не смог за полчаса распарсить лог веб сервера Apache и найти топ самых часто встречаемых IP адресов.

Ну да, не хватает практики. Зарегистрировался на leetcode и hackerrank. Начал решать задачки регулярно. Подтянул Python.

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

Доступен системный менеджер GNU Shepherd 0.10 (бывший dmd), сочетающий возможности системы инициализации и инструментария для управления системными сервисами. Проект развивается разработчиками дистрибутива GNU Guix System в качестве альтернативы системе инициализации SysV-init, поддерживающей зависимости. Управляющий демон и утилиты Shepherd написаны на языке Guile (одна из реализаций языка Scheme), который также используется для определения настроек и параметров запуска сервисов. Shepherd уже применяется в дистрибутиве GNU Guix System и нацелен также на использование в GNU/Hurd, но может работать в любой POSIX-совместимой ОС, для которой доступен язык Guile.

Shepherd выполняет работу по запуску и остановке сервисов, учитывая взаимосвязь между сервисами, динамически определяя и запуская сервисы, от которых зависит выбранный сервис. Shepherd также поддерживает определение конфликтов между сервисами и предотвращает их одновременное выполнение. Проект может использоваться как в роли основной системы инициализации (init c PID 1), так и в обособленном виде для управления фоновыми процессами отдельных пользователей (например, для запуска tor, privoxy, mcron и т.п.) с выполнением с правами данных пользователей.

Основные новшества:

    * Добавлены новые промежуточные состояния сервисов - "starting" и "stopping", отображаемые при выполнении команды "herd status" и определяющие нахождение сервиса в процессе запуска или остановки (ранее поддерживались только состояния "running" и "stopped").
    * Обеспечена блокировка повторного выполнения операций "start" и "stop", если сервис уже запущен или остановлен (ранее выполнение "herd start SERVICE" приводило к попытке запуска второго экземпляра сервиса).
    * Обеспечено распараллеливание запуска зависимостей и сервисов, запускаемых в режиме "start-in-the-background".
    * Реализован учёт времени сбоев и изменений состояний каждого сервиса. Накопленная статистика показывается при выполнении команды "herd status".
    * Добавлена команда "herd log" для показа сводного лога событий и списка всех изменений состояния сервиса.
    * Добавлена команда "herd graph" для генерации данных, позволяющих при помощи Graphviz ("herd graph | xdot -") отобразить наглядный граф зависимостей.
    * Реализовано цветное подсвечивание вывода команды herd.
    * Добавлены новые сервисы: "monitoring" для отслеживания потребления ресурсов процессом shepherd и "repl" для запуска отладочного интерфейса REPL (read-eval-print loop).
    * Объявлен устаревшим интерфейс GOOPS (Guile’s Object-Oriented Programming System). 

Генераторы: двоичные и списка. Имеют структуру
NewList = [Выражение || Генератор1, Генератор2,..., ГенераторN. Условие1, Условие2,..., УсловиеM]

language: erlang
% общий вид двоичного генератора в литературе, которую я читаю, не приводится. Поэтому напишу здесь усреднённый вид генератора, чтобы понимать потом.
[X || <<X>> <= <<1, 2, 3, 4, 5>>, X rem 2 == 0].

ClipboardImage.png
[Hide] (41.4KB, 583x418)

Продолжаем.
Это код простого udp-сокета. Решил немного уйти дальше просто посмотреть. Очень доставил встроенная бесконечная функция loop.

>>55
Расширенный код сокета. Объединён с tcp-сокетом в один файл. Оба сокета запускаются параллельно.

-module(socket_server).
-export([start/0]).

start() ->
    TcpPort = 1337,
    UdpPort = 1488,
    TcpOptions = [{active, false}, {reuseaddr, true}],
    UdpOptions = [{active, false}, {reuseaddr, true}],
    {ok, TcpSocket} = gen_tcp:listen(TcpPort, TcpOptions),
    {ok, UdpSocket} = gen_udp:open(UdpPort, UdpOptions),
    io:format("TCP server started and listening on port ~w~n", [TcpPort]),
    io:format("UDP server started and listening on port ~w~n", [UdpPort]),

>>56
В будущем применимый для этого сокет-сервера модуль с использованием mysql

-module(db).
-export([connect/0, insert_user/2, insert_log/3]).

connect() ->
    mysql:start_link([{host, "localhost"}, {user, "root"}, {password, "password"}, {database, "chatgpt_db"}]).

insert_user(Username, Password) ->
    mysql:query(mysql:prepare(<<"INSERT INTO users (username, password) VALUES (?, ?)">>, [Username, Password])).

insert_log(FromUser, ToUser, Message) ->
    mysql:query(mysql:prepare(<<"INSERT INTO message_logs (from_user, to_user, message) VALUES (?, ?, ?)">>, [FromUser, ToUser, Message])).

Сама sql-схема прилагается.
CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(255) UNIQUE NOT NULL,
    password VARCHAR(255) NOT NULL
);

CREATE TABLE messages (
    id INT AUTO_INCREMENT PRIMARY KEY,
    sender_id INT NOT NULL,
    receiver_id INT NOT NULL,
    message TEXT NOT NULL,
    sent_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (sender_id) REFERENCES users(id),
    FOREIGN KEY (receiver_id) REFERENCES users(id)

спидран по установке arch

https://youtu.be/8utpbbdj0LQ