Today It learned

Ядро Линукс Управление пользователями Что это такое: - В ядре Linux информация о пользователе и его правах хранится в структуре struct cred. - Эта структура «прикрепляется» к процессам и определяет, от имени какого пользователя и группы работает процесс, и какие у него права доступа. Зачем это нужно: - Ядро проверяет cred при любом обращении процесса к ресурсам: файлам, сокетам, устройствам и т.д. - Если у процесса нет нужных прав (например, он запущен от обычного пользователя, а не root), ядро отказывает в доступе. - Значения именно из этой структуры возвращаются системными вызовами `getuid()`, `geteuid()`, `getgid()` и `getegid()` Пример структуры struct cred: struct cred { kuid_t uid; /* реальный UID процесса */ kgid_t gid; /* реальный GID процесса */ kuid_t suid; /* сохранённый UID (для setuid-программ) */ kgid_t sgid; /* сохранённый GID */ kuid_t euid; /* эффективный UID (именно он используется при проверках доступа) */ kgid_t egid; /* эффективный GID */ struct user_struct *user; /* ссылка на структуру user_struct с информацией о пользователе */ }; Объяснение ключевых полей: - uid/gid – реальные UID/GID, под которыми процесс изначально создан. - suid/sgid – сохранённые UID/GID, нужны для временной смены прав (например, в `setuid` бинарных файлов). - euid/egid – эффективные UID/GID, именно они определяют фактические права процесса при доступе к ресурсам. - user_struct *user – хранит дополнительную информацию о пользователе (например, сколько процессов он может создать, какие лимиты установлены). Итог: struct cred = «паспорт процесса». Она говорит ядру: «Я процесс X, запущен пользователем Y из группы Z, у меня такие-то права».

Ядро Линукс IPC Inter-process communication - Межпроцессное взаимодействие. Это способы взаимодействия внутри одной системы Что это такое: - IPC — это набор механизмов, с помощью которых процессы могут обмениваться данными и синхронизировать свою работу внутри одной системы/на одном физическом компьютере. - Нужно, потому что процессы изолированы друг от друга: у каждого — своё адресное пространство и ресурсы. Основные способы межпроцессного взаимодействия: 1. Файлы и файловая система - Самый простой способ: процессы читают и пишут один и тот же файл. - Минусы: медленно, требует доступа к диску. 2. Каналы (Pipes, FIFO) - Неименованные каналы (pipes): Создаются вызовом pipe(). Работают только между родственными процессами (например, между родителем и потомком, созданным через fork()). - Именованные каналы (FIFO): Это специальный файл в файловой системе (создается mkfifo()). Через него могут взаимодействовать любые процессы, знающие его имя. 3. Сокеты (sockets) - Универсальный механизм обмена сообщениями. - Unix domain sockets работают внутри одной системы и очень эффективны. - Сетевые сокеты (TCP/UDP) работают между машинами по сети. 4. Сигналы - Лёгкий способ уведомить процесс о событии (например, SIGTERM, SIGKILL, SIGHUP). - Это не обмен данными, а скорее управление поведением процесса. 5. Общие области памяти (Shared Memory) - Быстрый способ обмена большими объёмами данных. - Процессы получают доступ к одной и той же области физической памяти. - Требует обязательного использования семафоров или мьютексов для синхронизации доступа и избегания состояний гонки (race condition). 6. Очереди сообщений (Message Queues) - Структурированный обмен: процессы ставят сообщения в очередь, другие читают их в порядке поступления или по приоритету. - Удобно для сложных взаимодействий. 7. Семафоры и мьютексы - Не для передачи данных, а для синхронизации. - Нужны чтобы процессы не мешали друг другу. Например, чтобы два процесса не писали в файл одновременно. Итог - IPC нужен, потому что процессы изолированы. - В Linux есть несколько способов: от простого (файл) до очень быстрого (shared memory + семафоры). - Выбор механизма зависит от задачи: - файлы — просто, но медленно, - сокеты — универсально, - shared memory — быстро, но сложно в синхронизации, - каналы и очереди сообщений — для потокового и структурированного обмена. - Сигналы, семафоры и мьютексы используются для координации и управления, а не для передачи данных.

Ядро Линукс Работа с файловыми системами Виртуальная файловая система (VFS) Зачем нужна: - В Linux существует множество файловых систем (ext4, XFS, Btrfs, NTFS, FAT и т.д.). - Чтобы ядро не писало отдельный код под каждую, придумали виртуальную файловую систему (VFS) — единый «слой-абстракцию», через который всё работает одинаково. Как устроена: - VFS — это фундаментальный слой ядра, который представляет собой набор интерфейсов в виде структур данных, содержащих указатели на функции. Основными являются: - struct super_operations (операции с суперблоком) - struct inode_operations (операции с inode) - struct dentry_operations (операции с dentry) - struct file_operations (операции с файлом) - Эти интерфейсы описывают базовые операции: открыть файл, прочитать, записать, создать каталог, удалить и т.д. Конкретная файловая система (например, ext4) предоставляет экземпляры структур, где указатели ведут на её функции (ext4_read(), ext4_write(), ext4_open()) Как это работает: - Если новая файловая система хочет поддерживаться в Linux, она должна реализовать все эти функции у себя. - То есть драйвер файловой системы — это реализация интерфейса, который определён в VFS. Оптимизация работы: - В ядре есть кэш (page cache, dentry cache и inode cache). - Благодаря кэшу не всегда нужно лезть в «железо» (диск) при повторных операциях: - часто используемые данные читаются из памяти, - это сильно ускоряет работу с файлами. dentry cache и inode cache — кэшируют структуру файловой системы (пути, метаданные). page cache — кэширует содержимое самих файлов (те самые данные, которые вы читаете и записываете). Итого: - VFS = «единый интерфейс» для всех файловых систем. Он обеспечивает единообразие системных вызовов. Неважно, работает ли программа с файлом на ext4, XFS или FAT — она всегда использует одни и те же open(), read(), write(), close(). VFS перенаправляет эти вызовы нужной реализации. - Конкретная файловая система = реализация этого интерфейса. - Кэш = ускоритель, чтобы не дёргать диск по мелочам.

Ядро Линукс Система времени Системные тики (timer ticks): - На материнской плате есть устройство-генератор импульсов (осциллятор), которое с фиксированной частотой посылает аппаратные прерывания в ядро. - Каждое такое прерывание называется тик (tick). - Зная частоту этих тиков, ядро «шагает» по времени, продвигая счётчик времени. Основным таким счётчиком является jiffies (или jiffies_64) — глобальная переменная ядра, которая увеличивается на 1 с каждым тиком. Именно отсчёт jiffies позволяет ядру измерять временные интервалы. - Время в ядре дискретное (разбитое на интервалы), а не абсолютно непрерывное. 2. Частота тиков (tick rate): - Частота, с которой приходят тики, задаётся параметром CONFIG_HZ при сборке ядра. - Проверить её можно так: grep 'CONFIG_HZ=' /boot/config-$(uname -r) - Типичные значения: 100, 250, 1000 Гц. Это означает, что ядро получает 100, 250 или 1000 тиков в секунду. - Чтобы изменить это значение, придётся пересобирать ядро. - Более точный способ узнать текущую частоту — посмотреть в /proc/timer_list: grep -E "jiffies|resolution" /proc/timer_list | head -10 /proc/timer_list — это спецфайл, который показывает подробную информацию о таймерах ядра и их состояние. 3. Реальное время (RTC — Real Time Clock): - Когда компьютер полностью выключен, ядро не может «считать» время, поэтому используется отдельное устройство на материнской плате — Real Time Clock. - В нём есть своя батарейка и микросхема с кварцевым резонатором. - RTC хранит текущее время и дату между перезагрузками. - При старте ядро считывает время из RTC и синхронизирует системные часы. 4. Дополнительно: - После загрузки Linux обычно запускается демон NTP (Network Time Protocol) или systemd-timesyncd, чтобы синхронизировать время по сети (так как кварц RTC со временем всё равно немного уходит вперёд/назад). - Современные ядра поддерживают режим tickless (CONFIG_NO_HZ) — в этом случае прерывания таймера приходят не с фиксированной частотой, а только тогда, когда реально нужно (например, для планировщика). В этом режиме ядро "просыпается" по таймеру только когда есть какая-то работа (например, нужно проверить, не истек ли квант времени у выполняемого процесса, или когда ожидается какое-то событие с дедлайном). Это снижает нагрузку на CPU и экономит энергию.

Ядро Линукс Драйверы Что это такое: - Устройства не умеют напрямую «разговаривать» с ядром — для этого нужны драйверы. - Драйвер — это программа/код, который выполняется в режиме ядра (kernel space) с максимальными привилегиям и он знает, как управлять конкретным устройством. Одна ошибка в драйвере может привести к падению всей системы (kernel panic). Как драйверы попадают в ядро: - Часть драйверов уже встроена в ядро по умолчанию. - Другие можно установить отдельно: они подгружаются как модули ядра (`.ko` files — Kernel Object), которые загружаются в память при необходимости. Интерфейсы ядра: - Ядро предоставляет стандартизированные интерфейсы для разных классов устройств: блочные (диски), символьные (терминалы), сетевые и т.д. - Благодаря этим интерфейсам драйверу не нужно «изобретать велосипед», он реализует определённый набор функций по стандарту. Пример: - Подключаешь жёсткий диск → ядро через драйвер и стандартный интерфейс сразу умеет: - читать сектора, - записывать данные в нужные сектора, - создавать и удалять файлы (через файловую систему, которая работает поверх этого драйвера (ext4, NTFS, Btrfs и т.д.)). Итого: Драйвер = «переводчик» между устройством и ядром. Ядро предоставляет «единый стандарт» (Linux kernel API), чтобы работать с любым устройством одного класса одинаково.

Ядро Линукс Загрузчик (Bootloader) - это программа, которая находит на диске операционную систему и запускает её ядро. Последовательность запуска: 1. Нажатие кнопки питания. В работу вступает процессор, и первым делом он ищет программу начальной инициализации в постоянной памяти. 2. BIOS/UEFI. - Код BIOS (или его современный аналог UEFI) хранится в энергонезависимой памяти ROM (read-only memory, постоянное запоминающее устройство) на материнской плате. - Процессор начинает выполнение именно с этого кода: адрес начала программы BIOS «зашит» в фиксированный адрес в памяти (`0xFFFFFFF0` или последние 16 байт) устройства ROM. - BIOS выполняет POST (Power-On Self Test): проверяет и инициализирует оборудование — память, видеокарту, контроллеры, накопители. 3. Поиск загрузочного сектора. - После инициализации устройств BIOS обращается к диску и ищет заголовок Master Boot Record (MBR) который находится в самом первом секторе диска и имеет раздел 512 байт или раздел EFI System Partition (ESP) — в зависимости от режима. - MBR содержит первый этап загрузчика (первые 446 байт из 512) и таблицу разделов. Этого кода очень мало, поэтому он обычно только загружает второй этап загрузчика, который уже находится в другом месте на диске. Так работает, например, GRUB. - ESP — это полноценный файловый раздел, в котором хранится исполняемый файл загрузчика с расширением `.efi` 4. Загрузчик (Bootloader). - Получив управление, загрузчик выполняет сканирование файловой системы, чтобы найти исполняемый файл ядра ОС. - После нахождения ядра он загружает его в память. Попутно загружает вспомогательные файлы (например, "initramfs") и передает ядру управление, а также необходимые параметры. 5. Ядро операционной системы. - Ядро инициализирует драйверы, подсистемы и запускает системные процессы (первым, как правило, ”init” или “systemd”). - После этого управление полностью переходит к операционной системе.

Аппаратные прерывания (Interrupts) — это электрический сигнал от оборудования, который устройство посылает процессору для уведомления о каком-то событии. Примеры событий: - нажатие клавиши на клавиатуре; - приход сетевого пакета; - завершение операции чтения/записи на диске; Механизм работы: 1. Устройство посылает сигнал на контроллер прерываний. 2. Контроллер уведомляет CPU, указывая номер (вектор) прерывания 3. CPU откладывает выполнение текущего кода. 4. Сохраняется текущее состояние процессора. 5. Управление передаётся в специальную функцию — обработчик прерывания (Interrupt Handler). 6. Обработчик выполняется в привилегированном режиме ядра (Kernel mode) в особом контексте прерывания (Interrupt context). 7. После выполнения обработчика процессор восстанавливает сохранённое состояние и продолжает выполнение основной программы. Особенности: - Каждому устройству назначается номер прерывания (IRQ number или вектор прерывания). По этому номеру процессор находит в специальной таблице (IDT - Interrupt Descriptor Table) адрес соответствующего обработчика. Источников прерываний может быть больше, чем физических линий, поэтому используется контроллер, который их собирает в один канал и управляет приоритетами. - Прерывания не выполняются параллельно — они обрабатываются по очереди, в потоке, на одном ядре процессора (том, которое приняло прерывание). Новые прерывания на этом же ядре обычно на время обработки текущего маскируются (отключаются), чтобы обработчик не мог быть прерван сам собой. - При необходимости контроллер прерываний ставит прерывания в очередь и создаёт задачи для их обработки.

Проблема запуска Wazuh Dashboard: ошибка circuit_breaking_exception Если при попытке открыть дашборд Wazuh мы сталкиваемся с грустной надписью: Wazuh dashboard server is not ready yet А команда systemctl status wazuh-dashboard сообщает что-то вроде: FATAL {"error":{"root_cause":[{"type":"circuit_breaking_exception","reason":"[parent] Data too large, data for [<http_request>] would be [1063084208/1013.8mb], which is larger than the limit of [1020054732/972.7mb] Это значит что wazuh-indexer (он же opensearch) превысил лимит оперативной памяти, отведённой JVM для работы индексера. В результате он прекращает обработку запросов, чтобы избежать перегрузки. А это значит, что память нам нужно несколько увеличить. Для этого: 1. Открываем файл jvm.options, который лежит у нас по пути /etc/wazuh-indexer 2. Ищем там строчки: -Xms1024m -Xmx1024m Эти параметры определяют минимальный и максимальный объём памяти, выделенный для Java-машины. 3. Увеличиваем значения в зависимости от доступной оперативной памяти сервера. Например: -Xms2048m -Xmx2048m 4. Сохраняем, перезапускаем службы systemctl restart wazuh-indexer.service systemctl restart wazuh-dashboard.service