Why I Stopped Guessing at Linux Distros and Started Asking AI to Reason Through It

Установи Linux с помощью промптов: серия из 4 частей

Часть 1: Выбор дистрибутива → Часть 2: Хранилище и шифрование → Часть 3: Ручная установка → Часть 4: Сервисы и GPU

Я устанавливал Linux столько раз, что уже сбился со счёта. И каждый раз выбор дистрибутива сводился к интуиции или к тому, чем я пользовался в прошлый раз. Но вот в чём дело: если вы строите что-то конкретное, интуиция не поможет. Узел безопасности, которому нужны Docker, PostgreSQL, локальные модели ИИ и перехват пакетов на трёх зашифрованных дисках? Это задача архитектуры, а не настроения.

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

Первый промпт важнее всего

Вот что большинство людей вводит в ChatGPT, когда думает о Linux:

«Какой дистрибутив Linux мне установить?»

И получает ровно то, чего следовало ожидать: список дистрибутивов с поверхностными описаниями. Ubuntu подходит новичкам. У Fedora пакеты посвежее. Arch для тех, кто любит страдать. Спасибо, невероятно бесполезно.

Проблема не в ИИ. Проблема в промпте. Вы задаёте общий вопрос и получаете общий ответ. Стоит перейти от «что мне установить» к «вот что должна делать эта машина», и разговор меняется кардинально.

Вот шаблон промпта, который действительно работает:

1I'm setting up a Linux machine for [specific role].
2My requirements are: [list workloads].
3The machine needs to support: [list services].
4What distribution should I consider and why?

Простая структура. Огромная разница в качестве ответа. Вы даёте ИИ достаточно контекста для рассуждений, а не просто для пересказа.

Что на самом деле нужно вашей сборке

Прежде чем отправить промпт, чётко определите роль машины. Не говорите «сервер на Linux». Скажите, что он делает. Для узла безопасности (именно такую сборку разбирает эта серия) список нагрузок выглядит так:

• Docker-контейнеры с несколькими инструментами и сервисами безопасности
• PostgreSQL и Redis для структурированных данных и кэширования
• Ollama для запуска локальных моделей ИИ (без зависимости от облака)
• Будущий проброс NVIDIA GPU для ускоренного инференса
• Хранилище артефактов атак с надлежащим разделением цепочки хранения
• Зашифрованное многодисковое хранилище на NVMe, SSD и HDD
• Долгосрочная стабильность без постоянных поломок из-за обновлений с переднего края

Это уже не вопрос «какой дистрибутив». Это вопрос архитектуры. И когда вы формулируете его именно так, ИИ начинает думать об экосистемах пакетов, сроках поддержки ядра, доступности драйверов и инструментарии сообщества. Ваша задача — задать ограничения. Задача ИИ — рассуждать в их рамках.

Как выглядят рассуждения

Дайте ИИ такой список нагрузок, и вы получите не просто ответ, а обоснование каждого варианта. Вот чего ожидать:

Kali Linux получает наиболее сильную рекомендацию. Он основан на Debian, что означает надёжное управление пакетами и широкую совместимость. Инструменты безопасности поставляются предустановленными или устанавливаются одной командой apt install. Rolling-релизы поддерживают актуальность инструментов без нестабильности, характерной для Arch. А сообщество сосредоточено именно на той работе, для которой предназначена эта машина.

Ubuntu Server занимает второе место. Отличная поддержка Docker, огромное сообщество, LTS-релизы. Но для сборки с упором на безопасность первые два дня уйдут на установку инструментов, которые в Kali идут из коробки. Это универсальная основа там, где нужна специализированная.

Debian Stable слишком консервативен. Версии пакетов отстают от того, что требуют Ollama и новые драйверы NVIDIA. Вы будете постоянно бороться с бэкпортами.

Arch Linux предлагает самые свежие пакеты, но нестабильность rolling-релиза на машине с производственными базами данных и Docker-сервисами — это риск. Один неудачный pacman -Syu, и ваш экземпляр PostgreSQL лежит.

Fedora Server интересен, но вносит инструментарий на основе RPM, который не вписывается в экосистему Kali/Debian, на которую ориентировано большинство инструментов безопасности.

Для этой сборки выбор пал на Kali. Не потому что это модно или какой-то YouTube-ролик так сказал, а потому что профиль нагрузки напрямую соответствует тому, для чего Kali создан, а основа на Debian обеспечивает стабильность, которой требуют Docker и PostgreSQL. Ваша сборка может указать в другую сторону. В этом и весь смысл: пусть ИИ рассуждает, а не угадывает.

Разговор об обнаружении оборудования

Когда дистрибутив выбран, не спешите за ISO. Сначала выясните, с каким именно железом вы работаете. Именно здесь разговор с ИИ становится по-настоящему мощным.

Попробуйте такой промпт:

1You are a security expert and are setting up a clean Kali Linux
2install. I'm sitting in front of the terminal. What commands do
3you want me to run to get you all the specs and hard drives
4available to plan this?

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

Что запрашивает ИИ (и почему каждая категория важна)

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

Режим прошивки (ls /sys/firmware/efi или проверка настроек BIOS): определяет всю стратегию загрузки. UEFI означает таблицы разделов GPT и ESP-разделы. Legacy BIOS означает MBR и другие конфигурации загрузчика. Ошибитесь здесь, и придётся переустанавливать.

Процессор и ОЗУ (lscpu, free -h): количество ядер и объём памяти определяют, сколько Docker-контейнеров можно запускать одновременно, поместятся ли локальные модели ИИ в память и насколько агрессивной может быть конфигурация PostgreSQL.

Инвентаризация дисков (lsblk -o NAME,SIZE,TYPE,ROTA,TRAN,MODEL, fdisk -l): размер каждого диска, тип интерфейса (NVMe, SATA) и тип накопителя (вращающийся или нет). Это основа архитектуры хранилища.

Режимы контроллера (настройки BIOS, dmesg | grep -i ahci): режим AHCI, RAID или IDE влияет на производительность дисков и совместимость с Linux. Некоторые контроллеры в режиме RAID скрывают отдельные диски от установщика.

Видеокарта (lspci | grep -i vga, lspci -nn | grep -i nvidia): важно по двум причинам. Во-первых, видеокарты NVIDIA могут вызывать сбои установщика, если с ними не обращаться должным образом. Во-вторых, точная модель GPU определяет, какая версия драйвера понадобится позже.

Сетевые устройства (ip link, lspci | grep -i net): во время установки нужен доступ к сети для загрузки пакетов. Знание того, Intel, Realtek или Broadcom стоит в системе, определяет, потребуются ли пакеты с прошивками.

Существующие таблицы разделов (fdisk -l, blkid): любые существующие данные или схемы разделов нужно изучить, прежде чем что-то стирать.

Состояние SMART (smartctl -a /dev/sdX): данные о здоровье диска показывают, каким накопителям можно доверять для долгосрочного хранения, а какие могут отказать под высокой нагрузкой.

Схема рабочего процесса

На практике это выглядит так:

1. ИИ даёт вам набор команд
2. Вы запускаете их в терминале
3. Вы вставляете вывод обратно в чат
4. ИИ интерпретирует результаты и задаёт уточняющие вопросы
5. Повторяете, пока не сложится полная картина

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

ИИ Интерпретирует Ваше Железо

После выполнения команд обнаружения вот с каким инвентарём вам предстоит работать (это точное железо для сборки этой серии):

• NVMe SSD, 1 ТБ: Samsung 970 EVO Plus, последовательное чтение ~3 500 МБ/с
• SATA HDD, 1 ТБ: Western Digital Blue, 5400 RPM, механический
• SATA SSD, 128 ГБ: Старый Kingston, неплохой, но маленький, SMART фиксирует повышенную температуру
• GPU: Встроенная графика Intel + NVIDIA GeForce (гибридная конфигурация Optimus)
• RAM: 32 ГБ DDR4
• CPU: Intel i7, 8 ядер / 16 потоков

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

Трёхуровневая Архитектура Хранилища

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

Уровень 1: NVMe (рабочая лошадка) — для всего, что требует скорости. Операционная система, хранилище контейнеров Docker, базы данных PostgreSQL, данные Redis и модели ИИ Ollama. Эти нагрузки генерируют интенсивный случайный ввод-вывод, с которым NVMe справляется без труда. Этот диск получает шифрование LUKS с LVM для гибкого управления разделами.

Уровень 2: SATA SSD (горячее рабочее пространство) — для активного анализа. Когда вы работаете над делом, вам нужен быстрый доступ к извлечённым образцам, временным результатам инструментов и данным в процессе обработки. SSD на 128 ГБ обеспечивает доступ на скорости SSD, не засоряя основной NVMe временными файлами. Также зашифрован LUKS, смонтирован как выделенное рабочее пространство.

Уровень 3: SATA HDD (холодный архив) — для долгосрочного хранения. Захваты пакетов, форензик-экспорты, архивы доказательств и всё, что должно существовать, но не требует быстрого доступа. Механический диск идеально подходит для этого: большой, дешёвый и надёжный для последовательной записи. Зашифрован LUKS с отдельным ключом.

«Не кладите базы данных на вращающиеся диски и не тратьте пропускную способность NVMe на файлы, которые открываете дважды в год. Подбирайте уровень хранилища под паттерн доступа.»

Почему Маленький SSD Не Подходит в Качестве Корневого Диска

Вот ловушка, в которую легко попасть: использовать меньший SSD в качестве корневого диска, чтобы оставить NVMe «свободным» для данных. Звучит логично. ИИ будет активно возражать против этого, и вот почему.

Только образы Docker и тома контейнеров могут занять 40-60 ГБ на рабочей станции безопасности. Добавьте каталоги данных PostgreSQL, файлы моделей Ollama (каждая может весить 4-8 ГБ) и системные пакеты — и вы смотрите на минимум 80-100 ГБ для комфортного корневого раздела. На диске в 128 ГБ это почти не оставляет места для роста. Одна большая загрузка Docker — и вы на 95% заполненности.

Данные SMART добавляют ещё одну причину для беспокойства. Если SSD зафиксировал события теплового троттлинга, он не выходит из строя, но это не тот диск, который вы хотите видеть в качестве системного корня.

NVMe — очевидный приоритет. Быстрее, больше, надёжнее и создан именно для смешанной случайно-последовательной нагрузки, которую генерирует корневой раздел с Docker и базами данных. Не усложняйте.

Проверка Прошивки, Которая Экономит Часы

Именно здесь процесс обнаружения окупается ещё до того, как на диск запишется хоть один байт.

Одна из ранних команд обнаружения может показать, что ваша машина работает в режиме Legacy BIOS. Машина прекрасно работает в этом режиме. Но для зашифрованной сборки с несколькими дисками это неправильно. Именно такие вещи ИИ замечает там, где вы могли бы не подумать проверить. Вот почему это важно:

Legacy BIOS + MBR ограничивает вас четырьмя основными разделами на диск. Для трёхдисковой зашифрованной сборки с LVM это реальное ограничение. Вы в итоге используете расширенные разделы и логические тома способами, которые добавляют ненужную сложность.

UEFI + GPT снимает ограничение на количество разделов, нативно поддерживает большие размеры дисков и обеспечивает более чистый процесс загрузки. Для зашифрованной сборки с несколькими томами GPT — просто правильная основа.

Ваши следующие шаги, если ИИ это обнаружит: три изменения прошивки перед установкой.

1. Переключиться в режим UEFI в настройках BIOS
2. Отключить Secure Boot (установщик Kali умеет работать с Secure Boot, но это добавляет трудностей при начальной настройке и установке драйверов, особенно с NVIDIA)
3. Проверить режим AHCI для контроллеров SATA (возможно, уже установлен, но убедитесь)

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

Ваш Воспроизводимый Метод

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

Шаг 1: Опишите свои цели конкретно. Не «хочу Linux», а «мне нужна система, которая запускает эти сервисы, обрабатывает эти нагрузки и хранит данные такого типа». Чем конкретнее вы, тем лучше ИИ может рассуждать о ваших вариантах.

Шаг 2: Позвольте ИИ спроектировать обнаружение. Не гуглите отдельные команды. Скажите ИИ, какую роль он играет, и попросите его спроектировать исследование. Он попросит проверить то, о чём вы бы не подумали.

Шаг 3: Выполняйте и докладывайте. Запускайте команды, вставляйте вывод. Вы — руки; ИИ — аналитик. Такое разделение труда работает, потому что ИИ может обрабатывать плотный технический вывод быстрее, чем большинство людей его читают.

Шаг 4: Позвольте ИИ интерпретировать с учётом ваших целей. Голые характеристики бессмысленны без контекста. SSD на 128 ГБ вполне подходит для корневого раздела медиасервера. Для рабочей станции безопасности с Docker он опасно мал. ИИ сопоставляет железо с требованиями рабочей нагрузки и указывает на несоответствия, которые вы бы пропустили.

Шаг 5: Итерируйте, пока картина не станет полной. Обнаружение редко бывает одним раундом. ИИ будет задавать уточняющие вопросы. «Что показывает smartctl для того старого SSD?» или «Является ли GPU NVIDIA основным видеоадаптером?» Каждый раунд уточняет план.

«Вам не нужно запоминать команды Linux. Вам нужно знать, что вы строите. ИИ берёт на себя перевод между целями и реализацией.»

Эта методология работает независимо от того, настраиваете ли вы домашний медиасервер, рабочую станцию разработчика, сетевой аплайанс или стенд для тестирования на проникновение. Команды меняются. Паттерн остаётся тем же.

Теперь у вас есть выбранный дистрибутив, полный инвентарь железа, план многоуровневого хранилища и чистые настройки прошивки. Всё дальнейшее — это исполнение. Часть 2 берёт всё это и превращает в реальную схему разделов: зашифрованные тома, разметку LVM, точки монтирования и скрипт подготовки, который проверяет всё перед тем, как установщик коснётся диска. Вот где сборка становится настоящей.

Далее: Часть 2: Хранилище и Шифрование — проектирование зашифрованных томов, разметка LVM и скрипт проверки безопасности, который валидирует ваше железо перед началом установки. Берите терминал.