Информация об активации Windows 10 привязывается к (motherboard + cpu) и хранится на серверах M$, свежеустановленная Windows 10 проверяет, активировали ли её на таком-то железе.

В QEMU используется одинаковое железо у всех людей по всему миру, — поправьте если я ошибаюсь. Ну пусть кто-то использует -cpu host, ну а кто-то ведь не использует, да? Ну а motherboard в QEMU, должна быть наверняка у всех одинаковая.

В мире семь миллиардов человек, наверняка кто-то же должен был активировать лицензию Windows 10 на одной из дефолтных конфигураций QEMU, и если уникальные ID железа QEMU не генерирует каждый раз заново, то теперь каждый кто использует такую же конфигурацию железа в QEMU, может невозбранно пользоваться лицензионной версией Windows 10, ведь согласно данным своего же сайта, Windows будет думать что запущена на железе, где её и активировали... Не?

Короче, если я сейчас установлю Windows 10 на дефолтную QEMU, она должна быть в теории лицензионной, если кто-то её активировал на такой же дефолтной QEMU. Не?

Если есть желающие скоротать вечер-другой за покатушками в GTA Online и кооперативном прохождении миссий, прошу, добавляйтесь в друзьяшки. Хэндл: Sp00f1ng

У нас есть ЛОР с тяночкой на ресепшоне и можно невозбранно бухать.

Материнская плата gigabyte ab350m-ds3h v2, в настройках включена Wake On Lan (по-умолчанию), но вот что странно: когда включаешь компьютер в розетку первый раз и затем отправляешь WOL-пакет wol -v -h 172.31.255.255 B4:2E:99:XX:XX:XX в сеть (broadcast address), то компьютер никак на него не реагирует. Не включается.

После чего сам нажимаю кнопку Power и не заходя даже в BIOS/UEFI сразу выключаю (не из сети, а просто Power'ом), и только после этого компьютер начинает реагировать на WOL-пакеты и включаться.

Такая закономерность. Если выключить комп из розетки, то WOL не работает до первого включения ПК. После включения и выключения начинает работать.

Сначала подумал, на это может как-нибудь влиять ARP-протокол, типа компьютер при включении говорит: привет! я - XX:XX:XX:XX:XX:XX. Вычищение ARP таблиц со всех устройств никак не повлияло на фактор включения.

В итоге заборол проблему немного иначе: выставил в бивисе AC Power State == Always On, чтобы компьютер всегда включался при появлении нямки в розетке. После включения и загрузки по PXE, он сам себя выключает средствами ОС (poweroff), и теперь, когда ПК действительно нужен в работе, тогда начинаю слать WOL в сеть и работать с ПК.

Но всё же интересно было бы узнать, нормально такое поведение или баг?

Думаю, передавать в параметрах ядра /proc/cmdline чтобы наверняка. Или есть способ узнать реальный аптайм?

Там это, Техно-Кухня на святое покусились: https://www.youtube.com/watch?v=eAuBE3oVlaw

Для Ъ: про ПеКа-роутеры и линуксы/бздю ни слова. Увы.

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

Все хосты у нас загружаются по сети (PXE), и считается, что система остаётся без человеко-вмешательства, но сюда могут вмешаться китайские ботнеты. Поскольку система загружается целиком в RAM, то простой Reset как всегда спасёт отца демократии. Система загружается с хоста DMZ (demilitarized zone) и возвращается к «заводским настройкам». Да, с нашей стороны мы обеспечиваем полную работоспособность системы и служб, что отключение питания (читай, Reset) это не форс-мажор, а обычное рабочее состояние. И было решено сделать, чтобы система сама перезагружала себя каждые N времени, но доверить скрипту эту работу нельзя, в случае вмешательства «хакера», скрипту будет kill -9, а вот с модулем ядра посложнее. А когда уже «свой» человек вмешается в работу системы, он при необходимости будет собственноручно модуль выгружать и система будет работать без перезагрузок.

Знатоки ядра, какими двумя функциями можно запустить sleep 31337 && reboot? Корректное завершение системы ctrl_alt_del(); не требуется (она в памяти, что ей там завершать?), поэтому kernel_restart(); отлично подходит.

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Spoofing");
MODULE_DESCRIPTION("/xyzzy");
MODULE_VERSION("1.0");

static int __init xyzzy_init(void) {
  mdelay(31337000);
  kernel_restart(NULL);
  printk(KERN_INFO "Nothing happens.\n");
  return 0;
}

static void __exit xyzzy_exit(void) {
  printk(KERN_INFO "Human happened.\n");
}

module_init(xyzzy_init);
module_exit(xyzzy_exit);

Сперва я конечно хотел сделать это на Bash на уровне initramfs, но как уже было оговорено, это дохлый номер.

daemon_xyzzy() {
  (
    sleep 31337
    echo "Nothing happens."
    reboot
  ) &

  echo $! > /xyzzy.pid
}

switch_initramfs() {
  local FS=/fs
  if [ -d $FS ]; then
    mount -t tmpfs -o size=100% inittmpfs $FS
    cp -a /???* $FS
    cd $FS
    # FIX: Yes I know about /proc /sys /dev fails.
    exec switch_root . /init 2>/dev/null
  fi
}

P.S. модуль называется xyzzy потому что есть такая недокументированная команда в проприетарном клиенте mIRC, которая делает echo Nothing happens. и больше ничего. Как-бы, ничего хорошего, и систему оставленную без присмотра надо перезагружать, наверняка её уже похакали. Вот.

Заранее благодарю за помощь и советы.

На счету FirstVDS лежат 2500р. Чтобы их вывести, надо заключать договор в устаревшем аналоговом формате (почта россии, бумага а4, спасём леса, вот это вот всё). Долго, муторно, неудобно.

Есть вариант вывести деньги через посредника, путём продления услуг. То есть, я со своего аккаунта продляю услугу FirstVDS на вашем аккаунте на сумму 2500 рублей, а вы переводите мне деньги любым удобным способом (хоть на мобилу скинуть) в размере 2000 рублей.

Тех поддержка не возражает:

Здравствуйте, Иван. Да, в целом это возможно, но найти такого человека придётся самостоятельно. Получается, с нашей стороны это будет выглядеть так:

1. Получаем встречные запросы с обоих аккаунтов о продлении услуг на одном за счёт средств на другом
2. Списываем указанную в запросах сумму с одного аккаунта
3. Продлеваем на соотв. период сервер на другом аккаунте.

Остальная часть — договорённость со вторым партнёром, его перевод средств вам — уже происходят без нашего участия.

Anybody?

@ https://i.imgur.com/iZyyn8j.jpg
@ https://i.imgur.com/IYYIuSw.jpg

no comments

Включаю ПК или виртуалку подключенные к локальной сети, DHCP раздаёт PXE, загружается дистрибутив линукса (в теории, он может быть любой), — там просто загружается ядро и initramfs сразу содержащий squashfs-образ с системой, куда потом chroot'ится /init-скрипт. В общем, получается работающая система в RAM через PXE.

Простой /init-скрипт в initramfs, который чрутится в squashfs-образ с системой.

# cat init
#!/bin/sh

error() {
  setsid sh -c 'exec sh </dev/tty1 >/dev/tty1 2>&1'
}

mount -t proc none /proc || error
mount -t sysfs none /sys || error
mount -t devtmpfs devtmpfs /dev || error
mount -t tmpfs tmpfs /overlay || error

mkdir -p /ro /overlay/rw /overlay/work
mount -t squashfs -o loop,noatime /filesystem.squashfs /ro || error
mount -t overlay -o lowerdir=/ro,upperdir=/overlay/rw,workdir=/overlay/work rootfs /newroot || error

mount --move /dev /newroot/dev
umount /sys
umount /proc

exec chroot /newroot /sbin/init
exec sh
reboot

Чрутнулся. Система успешно загрузислась. Теперь не знаю как лучше настраивать систему сразу после загрузки. Например, в дистрибутивах есть /etc/rc.local файл, выполняющийся сразу после загрузки. Можно модифицировать его, чтобы он например, делал bash -s <(curl http://10.0.0.1/rc_local.php), и уже скриптом отдавать глядя на IP машины дальнейшие команды (в виде bash скрипта) для конфигурации системы и введения её в работу. Настроить SSH, доустановить нужные пакеты, сделать git clone и прочая-прочая-прочая. Всё, что угодно.

А как бы вы реализовали такую настройку системы?

Только не надо про syslinux с его pxeconfig, это не то пальто: там в зависимости от MAC ты только выбираешь, какой файл с конфигурацией syslinux'а отдать. Я не хочу иметь 100500 образов систем, — пусть система будет одна, и уже в процессе загрузки она настраивается под каждый хост.

Делаю switch_root, и так, и сяк, а оно сыпется ошибками. Не критичными, всё работает, но хотелось бы от них избавиться. Не знаю, как правильно делать switch_root.

[    1.338833] Run /init as init process
switch_root: failed to mount moving /dev to /newroot/dev: Invalid argument
switch_root: forcing unmount of /dev
switch_root: failed to mount moving /proc to /newroot/proc: Invalid argument
switch_root: forcing unmount of /proc
switch_root: failed to mount moving /sys to /newroot/sys: Invalid argument
switch_root: forcing unmount of /sys
switch_root: failed to mount moving /run to /newroot/run: No such file or directory
switch_root: forcing unmount of /run
INIT: version 2.96 booting
The system is coming up.  Please wait.

/init скрипт имеет следующий вид:

# cat init
#!/bin/sh

error() {
  setsid sh -c 'exec sh </dev/tty1 >/dev/tty1 2>&1'
}

mount -t proc none /proc || error
mount -t sysfs none /sys || error
mount -t devtmpfs devtmpfs /dev || error
mount -t tmpfs tmpfs /overlay || error

mkdir -p /ro /overlay/rw /overlay/work
mount -t squashfs -o loop,noatime /filesystem.squashfs /ro || error
mount -t overlay -o lowerdir=/ro,upperdir=/overlay/rw,workdir=/overlay/work rootfs /newroot || error

umount /proc
umount /sys
umount /dev

exec switch_root /newroot /sbin/init
error

Ни umount, ни mount --move, ни mount --rbind, ничего не помогает, оно либо говорит что /proc /sys already mounted, либо ещё что похуже. Как правильно приготовить новую ФС перед switch_root?

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

Заглянул в местечковый /etc/rc.shutdown файлик, оно отправляет всем процессам сигнал killall5 -15, ждёт, отправляет -9, я думал, что авторы QEMU учли такой момент, отправил через kill -n 15 $(pgrep qemu), а виртуалка просто убилась апстену, — я ожидал, что QEMU отправит гостевой ОС сигнал «нажали кнопку power». Нет, не отправил, виртуалка просто убилась сразу.

Сходу есть вариант слушать -qmp сокет, отправлять json-команду { "execute": "system_powerdown" }. Это говорят, аналогично действию «нажали кнопку power на системнике» и значит не только Linux, а всякая ОС должна сообразить, что от неё просят выключиться.

Дело в том, что это действие хотелось бы автоматизировать. Что, писать очередного /etc/rc.d демона, который будет корректно пробегаться по всем виртуалкам и завершать их? И только после этого, собственно, выключать сервер?

Ещё есть вариант, очень хороший, это полностью перекатиться на PXE, чтобы все ОС (линуксы) в виртуалках загружались по PXE, и тогда вообще без разницы как виртуалки будут выключены, тогда как они каждый раз будут загружаться и настраиваться «на лету».

А как это сделано у Proxmox?

Здравствуйте мои маленькие любители авиационного спирта =) !

Последние пару дней занимался настройкой Wi-Fi, да не простого, а стильного-модного-молодёжного, со своим Captive Portal. Для тех, кто в танке: это когда ты подключаешься к Wi-Fi сети, но прежде чем допускать тебя к интернетам и ЛОРу в частности, нужно пройти какую-никакую дополнительную авторизацию на веб-страничке, third-party так сказать.

Такой подход я считаю более секурным, потому как, доступ каждого клиента по Wi-Fi регулируется лично через iptables, а не тупо форвардится всё подряд. Какой простор для творчества! Во-вторых, авторизация происходит через веб-страничку, а не WPA и прочие нативные механизмы wireless-сетей, которые как и всё в нашем мире, не вечны и надёжность их хромает.

После вступления, приступим.

hostapd? checked!

iptables? checked!

nginx? checked!

Рассказывать о настройке NAT лишний раз не буду, думаю, у вас уже должна быть настроена раздача Wi-Fi, и всё, что вам ненужно, это только Captive Portal.

wlan0 — имя интерфейса Wi-Fi
eth0 — имя интерфейса с интернетами
192.168.0.0/24 — локалка

# создаём кольцо
iptables -t mangle -N captive

# все пакеты из ви-фи отправляем в это кольцо
iptables -t mangle -A PREROUTING -i wlan0 -j captive

# доверенные клиенты из кольца выходят сразу же (адреса инсертим в начало списка)
# фильтр хоть по MAC, хоть по IP
# этот список должен редактироваться через сайт (Captive Portal)
# iptables -t mangle -I captive -m mac --mac-source 00:00:00:00:00:00 -j RETURN
# iptables -t mangle -I captive -s 192.168.0.137 -j RETURN

# если ты всё ещё в кольце, тогда ставим метку
iptables -t mangle -A captive -j MARK --set-mark 1

# всех с меткой перенаправляем к себе, когда они открывают сайты 80
# про 443 забудьте
iptables -t nat -A PREROUTING -i wlan0 -m mark --mark 1 -p tcp --dport 80 -j DNAT --to-destination 192.168.0.1

# всех с меткой при прочем трафике просто дропаем
iptables -t filter -A FORWARD -i wlan0 -m mark --mark 1 -j DROP

# успешно натим оставшихся доверенных
iptables -t filter -A FORWARD -i wlan0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE

Вот и всё. Здесь включена проверка через -i wlan0, таким образом это не вызовет никаких конфликтов с другими сетями, т.к. у меня в продакшене под кроватью очень много правил iptables и я знаю, о чём говорю.

Подводные камни, на которые я наткнулся и спешу поделиться с вами. В соседнем треде мне научно-популярно объяснили, что тщетно пытаться настроить редирект по HTTPS на свой Captive Portal, это просто не сработает, это уже MitM атака. Не очень-то и хотелось! ;p

Если у вас используются личные DNS, то наверняка у вас есть правило, разрешающее локальные запросы к серверу (tcp/53 udp/53). Не забудьте разрешить запросы и к локальному веб-серверу (tcp/80). Но а если вы сообщаете Wi-Fi клиентам какие-то публичные NS, то не забудьте разрешить доступ клиентам к ним: iptables -t filter -I FORWARD -i wlan0 -s 192.168.0.0/24 -d 8.8.8.8/32 -j ACCEPT. А суть такова. Когда клиент подключается к Wi-Fi, он проверяет доступность интернета в целом, для этого смартфоны качают со своих серверов файлы и проверяют корректность полученных данных. Если оно не сможет резолвить хост запрашиваемого сайта, то на этом и споткнётся и проверка на наличие Captive Portal в сети не пройдёт.

Собственно, теперь к механизму Captive Portal.

Как уже замечено, это личная прерогатива каждого клиента, проверять доступность интернета, и если в результате проверки что-то пошло не так, — значит либо интернета нет, либо Captive Portal.

Мы перенаправили все запросы на 80 порт к себе, на свой локальный сервер. Теперь nginx должен в ответ на все HTTP запросы отвечать кодом 302. Не 200, не 301, не 511, а именно 302, а затем перенаправлять вас на страничку с third-party авторизацией, и только таким макаром например мой Андрюша-9 смог обнаружить, что у меня таки Captive Portal, а не какой-то сломанный интернет. В результате сразу после подключения к Wi-Fi сети должно появиться Push-уведомление: Скриншот #1, при нажатии которого откроется страничка, куда редиректит nginx Скриншот #2.

Сам скрипт странички я оставляю вам на откуп: думаю, вам не составит никакого труда наслюнявить однострочник на php добавляющий $_SERVER['REMOTE_ADDR'] в iptables через shell_exec(); или типа того. Да? Да. Ваш Captive Portal полностью в ваших руках.

Вот и весь механизм работы Captive Portal. Спрашивайте ответы.

приветики-пистолетики.

делаю так называемый captive portal, когда клиенты свободно подключаются по wi-fi, но для использования интернетов им необходимо пройти некую проверку (регистрацию) на локальном сайте, тобишь при попытке зайти на любой сайт, их перенаправляет ко мне, а весь прочий трафик попросту дропается.

оно работает. реализация достаточно простая. весь трафик из mangle сперва заворачивается в новое кольцо, затем, если ты «свой» клиент, то сразу выходим из кольца (-j RETURN), а если мы тебя не знаем, тогда делаем пометку (-j MARK). именно этот список в этом кольце подлежит изменению (добавлению/удалению) IP/MAC-адресов через сайт. затем всех помеченных при попытке зайти на 80/443, перенаправляем к себе на локальный сайт, а весь прочий трафик попросту дропаем. ну и в конце концов успешно форвардим если всё ок.

# создаём кольцо
iptables -t mangle -N wlp0s19f2u2_mark

# все пакеты из ви-фи отправляем в это кольцо
iptables -t mangle -A PREROUTING -i wlp0s19f2u2 -j wlp0s19f2u2_mark

# доверенные клиенты из кольца выходят сразу же (адреса инсертим в начало списка)
# iptables -t mangle -I wlp0s19f2u2_mark 1 -m mac --mac-source a8:87:b3:22:60:4d -j RETURN
# iptables -t mangle -I wlp0s19f2u2_mark 1 -s 192.168.0.1 -j RETURN
# этот список редактируется через сайт shell_exec();

# если ты всё ещё в кольце, тогда ставим метку
iptables -t mangle -A wlp0s19f2u2_mark -j MARK --set-mark 1

# всех с меткой перенаправляем к себе, когда они открывают сайты 80/443
iptables -t nat -A PREROUTING -i wlp0s19f2u2 -m mark --mark 1 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.1:80
iptables -t nat -A PREROUTING -i wlp0s19f2u2 -m mark --mark 1 -p tcp --dport 443 -j DNAT --to-destination 10.0.0.1:80

# всех с меткой при прочем трафике просто дропаем
iptables -t filter -A fw-interfaces -i wlp0s19f2u2 -m mark --mark 1 -j DROP

iptables -t filter -A fw-interfaces -i wlp0s19f2u2 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.254.0/16 -o enp3s5 -j MASQUERADE

проблема заключается в том, что при заходе на https-сайты у меня не работает редирект на мой локальный :80 сайт. то есть, если я удалив себя из «вайт-листа», захожу на какой-нибудь быдланет без https, то да, открывается мой локальный :80 сайт спокойно. если же я пытаюсь открыть пrавославный ЛОР по https, то фиг там.

тестирую wi-fi сеть на андроид смартфоне. я считаю, проблема заключается в том, что браузер изначально пытается создать https соединение, а когда iptables пытается ему подсунуть фейковый 80 порт, оно обсирается, простите, и дальше не идёт. и происходит завтык на этом.

можно ли это как-то починить? спасибо.

Сабж. Настроил 10.0.0.0/8 для виртуалок и 172.16.0.0/12 для физических устройств, подсети на разных сетевых картах, обе включил в один физический свич. Вроде никакого пакет-шторма пока не наблюдаю. А вообще, какие подводные камни?

Пригласил девушку на свидание, девушка меня продинамила и не пришла, а хотя могла бы просто погулять со мной, да на халяву пожрать в кафешке, ну чего ей стоит? Что я её, вступить в секту ЛОР заставлю? Мда. Девушки приходят и уходят, а компьютер как стоял, так и будет стоять. Грустный и подавленный, прохладным вечером, пошёл в ближайший DNS, да купил 2700X, дабы он меня согревал холодными зимними вечерами.

В наличии уже есть дешёвенькая MSI A320M PRO-M2 V2, но это не то, она не раскроет потанцевал, не раскочегарит 2700X на полную. Нужна добротная материнская плата, в которую производитель не забыл заложить побольше фаз питания на процессор, например.

Из второстепенных хотелок к системной плате, чтобы устройства адекватно определялись в Linux по-умолчанию, в последовательности именовались сетевые интерфейсы, если я воткну несколько сетевушек, чтобы небыло этих вот enp3s45h63hg812g35th9iq50j8gh.

Желательно наличие всё в том же DNS.

CRUX NG — бездисковый дистрибутив ориентированный на сетевую прозрачность и загрузку по сети, в основе которого, конечно же, CRUX.

 — NG?
 — NextGen!

Текущее состояние пре-альфа-версия, поскольку это только initrd-образ для загрузки с локального сервера. Дистрибутив загружается напрямую в оперативную память. Если у вас дома чисто случайно так крутится DHCP, TFTP, iPXE, да ещё QEMU какой-нибудь, вам это может показаться интересным. А если нет, то вперёд, настраивать. ;)

В составе образа обновлённый core-репозиторий CRUX, сжатый при помощи xz и размером всего 132мб, — именно столько оперативной памяти будет расходовать корневая ФС дистрибутива после загрузки. В текущей стадии развития дистрибутива вы просто получаете чистый CRUX работающий из памяти.

CRUX NG использует squashfs и overlay для работы. squashfs это ФС доступная только для чтения, в которой находится сама ОС, а overlay создаёт дополнительный слой «поверх» squashfs, tmpfs-диск в памяти, куда записываются все изменения. Таким образом система полностью работоспособна. Всё очень просто, «по-CRUX'овски». Соответственно, когда вы будете собирать ядро (рекомендую), хотя бы ванильное, то обратите внимание чтобы эти опции были включены, можете посмотреть config.

 — Очередной школолодистр с нескучными обоями, надолго тебя хватит...
 — У вас, как и у меня, наверняка есть старые железки, ресурс которых ещё можно утилизировать. Да просто виртуалки с сервисами запускать. Целью проекта сделать полноценный, но лёгкий дистрибутив, такой как CRUX, загружаемым и работоспособным («прозрачным») по сети. Мне очень нравится сама идея, что одним нажатием кнопки Reset система возвращается в исходное состояние и никакие кулхацкеры вам не страшны. Пока у меня есть хотя бы один лишний ПК в доме, — я буду развивать проект.

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

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

1) Образ корневой ФС будет урезан до минимума. Чистый core это хорошо, но на «тонких серверах» (это как «тонкие клиенты», только «тонкие сервера», выполняющие одну задачу, но делающие её хорошо (ц) :-) все эти инструменты разработчика и прочие утилиты ни к чему. CRUX NG даст только минимум, необходимый для подключения, загрузки дополнительных пакетов и получения конфигурации по сети. По итогу система станет ещё меньше, прям, сущие копейки. В пределах 50мб (это с глибцом).

2) Будет улучшена поддержка железа. Сейчас это ядро, какое вы сами соберёте, такое у вас и будет. Никакой /lib/firmware нет, а надо бы, ради поддержки сетевых карт и Wi-Fi, хотя бы. Загружать ОС по Wi-Fi — топ.

3) Основой системы всегда будет ванильный CRUX, хотя ничего не мешает загружать любую другую ОС в оперативную память по сети, но все прочие дистрибутивы для меня слишком сложные. «Сложна, сложна!» (ц)

Скачать initrd / config (vmlinuz) / grub.cfg

День пятый, наверное, изобретаю велосипед, пилю очередной initrd чтоб загружать CRUX в RAM по сети, поднимать сеть, запускать ssh с предустановленным ключом и делать условный ПК условной нодой в условной сети, предоставляющей свои ресурсы для всяких нужд.

Может такое уже сделали до меня?

Proxmox вещь, позволяет объединять ноды в кластер, но на атлонах и пентиумах ему делать нечего.

Было бы совсем хорошо, если бы дистрибутив мог загрузиться без NFS, за счёт только initrd, который при необходимости будет загружать дополнительные пакеты с более нишевых http/ftp.

передаю привет соседям, вот.

в hostapd.conf нужно включить utf8_ssid=1 и указать ssid2=P"\x00\x00\x00\x00" название сети в hex-формате.

в bash можно воспользоваться printf 'жырдечко ❤️' | hexdump -e '"\\\x" 1/1 "%x"'

// а то гляжу тухло в Talks, вот вам развлечение на вечер.

Представьте, в ОС или каком-либо компоненте нашли уязвимость, взломали, и одно дело, утекшие данные, а ведь до кучи могут сделать хост частью своего ботнета, например. Вы хватаетесь за голову, что ж теперь, аудит проводить, куда лазили, что делали, или просто переустановить всё, опять же заново настраивать, — сплошной головняк. Восстановление из последнего бэкапа? Как давно он был сделан? Ведь наверняка с тех пор в конфигурацию хоста внесены изменения. Я веду к тому, что всё ещё популярно хранить актуальное состояние ОС в единственном экземпляре в «горячем» виде, так сказать.

А что если, экземпляр вашей ОС хранился бы в «холодном» виде в образе, на сервере, откуда бы загружался на ваш хост при каждом его включении, и подтягивал за собой всю конфигурацию, необходимую для работы. Хост взломали, а вы просто исправили баг в образе который хранится «на холодную» и жмякнули кнопочку reset для перезагрузки, и снова в строю. Это же просто офигенно.

Как раз сейчас я этим и занимаюсь и решил поделиться мыслями. Хочу перевести все свои сервисы на удалённую «бездисковую» загрузку по сети. Чтоб даже домашний ПК-роутер, раздающий интернеты, загружался по сети и подтягивал образ с соответствующей конфигурацией. Для этого нужен только DHCP, tftp-hpa и... grub2, либо syslinux.

Когда компьютер включается, UEFI / BIOS при необнаружении накопителей пытается загрузиться через сеть, это так по-умолчанию, можно тупо принести новый комп из магазина домой, закрытыми глазами его собрать, включить и он загрузится, и станет нодой, частью вашей сети, да... кра-со-та.

UEFI спросит DHCP-сервер, DHCP выдаст IP и скажет, что по такому-то адресу находится загрузчик. UEFI попытается загрузить его по TFTP-протоколу, и в случае успеха, уже сам grub2 покажет красивую менюшку с выбором ОС, — добро пожаловать бездисковую загрузку по сети!

С установкой и запуском tftp-hpa проблем не будет, /usr/sbin/in.tftpd --listen --secure --verbose /var/ftp/tftpboot

Предлагаю всё хранить в /var/ftp/tftpboot, туда же установим загрузчик GRUB2:

# grub-mknetdir --net-directory /var/ftp/tftpboot
Netboot directory for i386-pc created. Configure your DHCP server to point to /var/ftp/tftpboot/boot/grub/i386-pc/core.0
Netboot directory for i386-efi created. Configure your DHCP server to point to /var/ftp/tftpboot/boot/grub/i386-efi/core.efi
Netboot directory for x86_64-efi created. Configure your DHCP server to point to /var/ftp/tftpboot/boot/grub/x86_64-efi/core.efi

Далее DHCP, достаточно настроить чтобы он раздавал IP и говорил по какому адресу находится файл загрузчика, который UEFI будет загружать через TFTP.

# cat /etc/dhcpd.conf
shared-network arpanet {
  interface br0;

  allow booting;
  allow bootp;
  next-server 10.0.0.1;
  filename "boot/grub/i386-pc/core.0";

  subnet 10.0.0.0 netmask 255.0.0.0 {
    option domain-name-servers 8.8.8.8, 8.8.4.4;
    option subnet-mask 255.0.0.0;
    option routers 10.0.0.1;
    range 10.0.0.2 10.0.0.254;
  }
}

Загрузка будет происходить с tftp://${next-server}/${filename}. У меня интерфейс br0 — бридж, в который вхожи все виртуальные машины. Именно br0 присвоен 10.0.0.1. У вас это может быть просто сетевая карта enp1s4po3te5ri7ng9.

Алсо, если у вас реально UEFI, можно добавить проверку, какой загрузчик отдавать системе:

option client-system-architecture-type code 93 = unsigned integer 16;

if option client-system-architecture-type = 00:09 {
  filename "boot/grub/x86_64-efi/core.efi";
}
else {
  filename "boot/grub/i386-pc/core.0";
}

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

Ну и вишенкой на торте надо создать обычный grub.cfg vi /var/ftp/tftpboot/boot/grub/grub.cfg:

set default=0
set timeout=60
menuentry "Boot SLAX" {
  linux /boot/os/slax/vmlinuz load_ramdisk=1 prompt_ramdisk=0 rw printk.time=0 from=http://10.0.0.1/slax/slax-64bit-9.9.1.iso
  initrd /boot/os/slax/initrfs.img
}
menuentry "Reboot" {
  reboot
}
menuentry "Shutdown" {
  halt
}
menuentry "Continue" {
  exit
}

На этом вся настройка. Для теста я использовал qemu-system-x86_64 -nic tap, который скриптами /etc/qemu-{ifup,ifdown} входил в бридж br0. BIOS спрашивал DHCP, DHCP выдавал IP и сообщал адрес загрузчика, далее BIOS загружал его с TFTP сервера и удачно грузился grub2, а дальше — дело тривиальное. Напихать кучу образов ОС.

Для примера можно использовать SLAX, для этого скачаем ISO-образ дистрибутива, стырим оттуда файлики /slax/boot/{vmlinuz,initrfs.img} и положим к себе в /var/ftp/tftpboot/boos/os/slax/.

Расскажу, как это работает, почему загружается SLAX и почему не загружается Debian / Ubuntu / Anything Else по сети.

Мы включили ПК, по TFTP загрузился grub2 и всё управление сейчас находится у него. Далее, выбирая пунктик меню загрузки SLAX, сам grub2 загружает с TFTP-сервера файлы /vmlinuz и /initrfs.img и передаёт управление уже ядру /vmlinuz. А ядро-то про TFTP сервер ничего не знает! И initrd SLAX'а, и любого другого дистрибутива ничего про TFTP не знает. До того момента, как мы грузимся по сети, мы работаем с TFTP-сервером, grub2 может оттуда загружать все свои модули, шрифты, аниме-картинку-с-понями для фона, но после того, как он передаёт управление ядру — забудьте про TFTP, всё.

В данном примере параметром к ядру указан from=http:// iso-образ SLAX, — да, iso-образ будет скачан с этого ресурса и SLAX будет успешно загружен по сети, нооо, важная деталь — это не параметр ядра, from= сохранится в /proc/cmdline, но ядро не знает что с этим делать, с from= будет работать сам /init скрипт находящийся в initrfs.img. Это чисто фича SLAX, и такой фичи нет у других дистрибутивов.

Как же тогда загрузить Ubuntu Live по сети? Да, grub2 может загрузить ISO образ размером 2гб, но оно вам надо? Ядро не знает про http и ftp (поправьте, если ошибаюсь), но ядро знает про NFS (Network File System) и умеет работать с ней. Таким образом, чтобы загрузить Ubuntu Live, вам надо точно так же извлечь vmlinuz и initrd из iso-образа Ubuntu, а параметром к ядру дописать root=/dev/nfs, таким образом ядро Ubuntu (и любого другого дистрибутива, т.к. это уже фича самого ядра Linux), будет знать, что после того как какой-нибудь скрипт в initrd запросит внешний файл, например, Live-образ системы, — ядро знает, что брать его надо с nfs://10.0.0.1/ubuntu-live — так-то!

Если будут вопросы, постараюсь ответить (хотя скоро спать).

За основу дистрибутива для загрузки по сети я беру любимый CRUX. Вся идея в том, чтобы загружался простенький busybox, подключался к сети (udhcpc), а затем через wget ftp://10.0.0.1/boot/pxelinux.cfg/54:52:00:12:34:56/init.sh && sh init.sh выполнял дальнейшие инструкции для загрузки, которые могут быть вообще любые. Подтягивал любой образ ФС по сети и switch_root в него! Так-то.

По дороге к виртуализации, до кучи захотелось сделать бездисковые станции. Ну, чтобы включаешь новенький ПК, а тебе сразу по DHCP предлагают установить на выбор новую ОС, а по-таймату продолжат загрузку ОС, CRUX например, сделав железку частью моей сети. Как мультизагрузочная флешка, только по сети, по кабелю.

https://files.catbox.moe/dffqpe.png

Установка и настройка DHCP, TFTP прошла успешно. Всего одной командой grub-mknetdir была создана структура /tftpboot директории. Теперь при запуске виртуальной машины без всяких там параметров, или же подключения нового физического компьютера в свич, — они все заходят в бридж br0, где участникам сети раздаются айпишники предлагается загрузка по сети. Включаем ПК / КВМ и получаем приветствие grub2. Пустого, пока что.

Дело тривиальное, наполнить его Debian, Ubuntu, CentOS, ... Windows? Мультизагрузочная «флешка» по сети это одно. Возвращаемся к бездисковым станциям, — допустим, я отправил пакет Wake-On-Lan, физический компьютер без диска включился, далее grub2 предлагает ему как и всем на выбор установку ОС, а по-таймауту в 3 секунды продолжает загрузку уже сконфигурированной ОС _конкретно для данного хоста_.

Суть в том, что таких компьютеров много, задачи у каждого свои: кто-то днс-сервер, кто-то веб-сервер. Тут должна быть какая-то идентификация, по mac-адресу например. На каком уровне тогда её организовать? На уровне grub2? То есть, сделать множественные menuentry "(00-00-00-00-00-FF)" доступными для всех, чтобы grub2 сам выбирал кого загружать в зависимости от mac-адреса устройства. Что в принципе не безопасно, т.к. конфигурации будут доступны всем. Уровне DHCP? Я не знаю как, в зависимости от mac каждому хосту предлагать отдельный загрузчик?

Ещё вопрос, хотел было попробовать freedos для начала, но для его запуска требуется memdisk, который идёт в пакете syslinux. insmod memdisk у граба это не то. Тащить все загрузчики я не хочу, не комильфо. grub2 самый фичастый, и я решил использовать чисто его. Как вы видите, у меня нет никакого «pxelinux.0», только grub2. Но вот походу, memdisk в нём нет, и какой-нибудь установленный образ freedos не загрузить, или я пока не знаю как.