Channels

Top 100 Trending New

Categories

Crypto Gaming News Entertainment Music Sports Tech Gambling Bots and mini apps Finance Business Education Lifestyle Health Travel Auto Fashion Jobs Dating Deals and shopping

Stickers

Stickers Emoji Themes Wallpapers

Bots Gifts Tools

Currency

$ USD ₽ RUB € EUR ₴ UAH ₸ KZT ₺ TRY zł PLN ₪ ILS AED AED R$ BRL Rp IDR RM MYR ¥ JPY ₩ KRW CN¥ CNY

Theme

Português (Brasil)

Bahasa Indonesia

Беларуская

Українська

Channels Categories Stickers Bots Gifts Tools

Premium Wiki Glossary Legal

Notifications Settings Log in

Admin Guides | Сисадмин: пост #3095 — TG.ME

Admin Guides | Сисадмин@admguides · 11.9K subscribers Open in TelegramOpen

t.me/admguides/3095

12

10

3

September 4, 2026 845 8

More from this channel

udevadm monitor: что происходит с устройством между kernel и /dev Когда подключается диск, сетевой адаптер или USB-устройство, файл в /dev не появляется сам по себе. Сначала kernel обнаруживает устройство и генерирует событие, затем udev обрабатывает его и создаёт нужные device nodes и symlink. Посмотреть эти события в реальном времени: udevadm monitor Подключаем USB-накопитель и можем увидеть события от kernel и udev KERNEL[...] add /devices/.../usb1/1-2 UDEV [...] add /devices/.../usb1/1-2 Это позволяет увидеть разницу между двумя этапами. KERNEL - устройство обнаружено ядром UDEV - событие обработал userspace udev Отфильтровать только устройства udevadm monitor --kernel --udev --subsystem-match=block Теперь интересуют только block devices При подключении диска можно увидеть цепочку событий для самого устройства и его разделов add → nvme0n1 add → nvme0n1p1 add → nvme0n1p2 Узнать, почему устройство получило именно такое имя После обнаружения: udevadm info --query=all --name=/dev/sda Можно посмотреть свойства, по которым udev идентифицирует устройство Например: ID_SERIAL=... ID_WWN=... ID_FS_UUID=... ID_PATH=... Именно на основе таких атрибутов создаются стабильные ссылки вроде: /dev/disk/by-id/ /dev/disk/by-path/ /dev/disk/by-uuid/ Полезный кейс Допустим, после перезагрузки диск иногда становится /dev/sdb, а иногда /dev/sdc Ориентироваться на имя sdX в такой ситуации ненадёжно Можно посмотреть стабильный идентификатор: udevadm info --query=property --name=/dev/sdb А затем использовать /dev/disk/by-id/... Так можно понять не только что система обнаружила, но и почему конкретное устройство получило конкретные свойства и имена 520·Sep 4

nsenter: заглянуть внутрь namespace работающего контейнера Контейнер не обязан иметь shell внутри себя. Если приложение работает, но docker exec недоступен или сам контейнерный userspace сломан, namespace можно открыть непосредственно с хоста Сначала находим PID основного процесса контейнера docker inspect -f '{{.State.Pid}}' <container> Допустим, получили 4217 Проверяем его namespaces: ls -l /proc/4217/ns/ Например: net -> net:[4026532456] mnt -> mnt:[4026532457] pid -> pid:[4026532458] Заходим сразу во все основные namespace nsenter -t 4217 -m -u -i -n -p -C Теперь shell работает в namespace процесса контейнера Проверка: hostname ip addr mount ps aux При этом команды выполняются с host kernel, но видят изолированное окружение контейнера Можно войти только в нужный namespace Например, посмотреть сетевую конфигурацию контейнера с хоста: nsenter -t 4217 -n ip addr Или его mount namespace: nsenter -t 4217 -m mount Это удобно, когда проблема именно в одном namespace и нет смысла запускать полноценный shell Почему nsenter особенно полезен при авариях docker exec фактически зависит от container runtime и возможности запустить новый процесс внутри контейнера nsenter работает иначе: он использует namespace уже существующего процесса через /proc/<PID>/ns Поэтому если внутри контейнера сломан shell, отсутствуют утилиты или runtime не может выполнить exec, диагностику всё ещё можно проводить с хоста ⚡️Важный нюанс: namespace изолирует пространство имён, но не создаёт отдельное ядро. Процессы контейнера и хоста используют одно Linux kernel, просто смотрят на разные namespace 794·Sep 3 [media post] 985·Sep 3

lsblk -o +UUID,PARTUUID: когда UUID и PARTUUID ведут к разным объектам У диска и его раздела могут быть сразу несколько идентификаторов, и они не взаимозаменяемы Посмотрим их вместе: lsblk -o NAME,SIZE,FSTYPE,UUID,PARTUUID,MOUNTPOINTS Например: nvme0n1 ├─nvme0n1p1 vfat 7A3C-91F2 4f8a... /boot/efi └─nvme0n1p2 ext4 91c2... 8e21... / UUID относится к файловой системе PARTUUID относится к самому разделу в partition table Это принципиальная разница. Если выполнить: blkid /dev/nvme0n1p2 можно получить: UUID="91c2..." PARTUUID="8e21..." UUID меняется вместе с filesystem Например, для ext4 можно создать новую файловую систему: mkfs.ext4 /dev/nvme0n1p2 Раздел останется тем же, но filesystem UUID будет новым. Поэтому /etc/fstab, где используется: UUID=91c2... / ext4 defaults 0 1 после пересоздания filesystem перестанет находить старую файловую систему PARTUUID принадлежит разделу Если файловую систему внутри раздела пересоздать, PARTUUID обычно останется прежним. Но если удалить раздел и создать его заново, partition entry уже может получить другой идентификатор Посмотреть таблицу непосредственно можно: lsblk -o NAME,PARTUUID или: blkid -p /dev/nvme0n1p2 Где это становится особенно важным В Linux можно встретить: root=UUID=... в параметрах kernel command line А в некоторых конфигурациях используется: root=PARTUUID=... В первом случае kernel/initramfs ищет filesystem с определённым UUID Во втором - конкретный partition entry Поэтому после клонирования диска можно получить очень неприятную ситуацию: структура разделов и их PARTUUID скопированы, а UUID файловых систем тоже совпали В результате система или initramfs может обнаружить не тот экземпляр filesystem ⚡️Практическое правило: UUID отвечает на вопрос «какую файловую систему найти», а PARTUUID - «какой раздел найти» При диагностике загрузки, клонирования дисков и проблем с /etc/fstab важно сначала определить, какой именно идентификатор используется и к какому уровню устройства он относится 889·Sep 2

💬 Вопрос на собеседовании для сисадмина Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать. ❓Вопрос: Что такое split-brain в кластере и почему он опасен? ✅Ответ: Split-brain - это состояние кластера, при котором его узлы теряют связь между собой, но несколько частей кластера продолжают считать себя активными и пытаются одновременно управлять одними и теми же ресурсами. Как это происходит: • Кластер из нескольких узлов теряет сетевую связь между ними. • Каждый узел видит, что остальные недоступны, и может решить, что именно он должен продолжать обслуживать ресурс. • Два узла начинают одновременно работать с общим хранилищем, виртуальной машиной или IP-адресом. • В результате возникают конфликты, повреждение данных или двойная запись. 1K·Sep 2

An open web layer over public Telegram — search, stats and channel reading right in your browser, no account, no install.

Not affiliated with Telegram FZ-LLC; all data comes from public sources.

Catalog

Top channels Categories Countries Search

Content

Stickers Emoji Gifts Themes Wallpapers

Help

Tools Wiki Glossary Blockchain Safety Premium Advertisers Advertising

© 2026 TG.ME · G.Media network· Updated 09/05/2026 · v0.2.0 · 26a81aa

Privacy Terms DMCA & complaints Report a violation

Similar channels

Network Admin12.4K subscribers

BashMaster8.9K subscribers

ServerAdmin.ru32.5K subscribers

Linux / Линукс13.5K subscribers

Серверная Админа | Компьютерные сети26.6K subscribers

Типичный Сисадмин38K subscribers

Bash Days | Linux | DevOps23.7K subscribers

Лига сисадминов13.1K subscribers