Делаю 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 не загрузить, или я пока не знаю как.

После работы чтобы отвлечься от забот, катаю пару каток в StarCraft II, по выходным в GTA Online с ребёнышем, каждый на своём аккаунте. В Windows бесспорно проще, запустил и играешь. И тут меня осянило, что можно же всё это дело в виртуалку запихнуть, и будет по заверениям что-то вроде от 95% производительности, не велика потеря, зато удобно: один мощный ПК, ресурсы которого не простаивают, а используются под виртуалки и самые разные задачи. А заодно вернусь обратно на десктопный линукс в качестве основной ОС.

Однако линукс быстро вернул меня с небес на землю, при первой же загрузке с RX 578 на борту, зависнул намертво сообщив fb: switching to radeondrmfb from EFI VGA. Ага, уже размечтался, как в линуксе «всё просто работает», думал, в сказку попал? И это только начало! Я ведь ещё даже не пытался пробросить GPU в виртуалку. Даже ПРОСТО загрузиться на ПК линукс уже не шмогла(с). CRUX 3.5, Linux 5.3.6. Меня как холодной водой окатило. Зачем я это делаю? Почему бы не продолжать использовать standlone-PC для игр под Windows? Тут тебе и никакой потери в производительности при нативном использовании железа, и решать постоянные проблемы в линукс никто не заставляет. Мдааа...

Ясное дело, мы так просто не сдаёмся, это всё ерунда, гугл в помощь, и все проблемы так или иначе решаются, вопрос в другом — стоит ли оно того, чтобы тратить время на их решение?

Кто использует Linux > QEMU > Windows для игр, оно ведь правда работает? И оно того стоит? 95% производительности от нативного железа достаточно чтобы не проседал FPS на хорошей железке? При этом, продолжая использовать Linux как основную ОСь. Или ну его нафиг?

Если всё заработает (в себе я не сомневаюсь, все проблемы решаемы), то было бы круто, воткнуть 3950X, тот что 16/32, который скоро выйдет, поставить на него пару-тройку виртуалок с оффтопиком и сделать одну игровую станцию на нескольких пользователей, ага... Ещё лучше, если существует какая-нибудь работающая технология, позволяющая играть удалённо (remote). А то всякие там VNC, RDP для этого явно не создавались.

Итого.

1. QEMU или standalone-PC для видеоигр?

2. Какими средствами можно играть удалённо?

Как сделать чтобы /boot/efi/grub/grubx64.efi по-умолчанию ставил себя в /boot/efi/bootx64.efi?

Собираю ядро с EFI_STUB, сохраняю файл ядра arch/x86/boot/bzImage как /boot/efi/bootx64.efi (жыр32), и отныне система портируется простым dd с винта на винт, без перенастройки всяких там загрузчиков, потому что /boot/efi/bootx64.efi — это то, что как стандарт де-факто должен подхватывать любой UEFI-биос.

А вот grub2 копирует себя в /boot/efi/grub/grubx64.efi, затем ещё добавляет запись имени себя через efibootmgr в список для загрузки. Таким образом перенося систему на другую железку, которая ничего не знает про загрузчик grubx64.efi — она отказывается загружаться с диска. Нельзя так просто взять и перенести систему на другую железу, — там ещё надо будет с какого-нибудь накопителя загружаться и прописывать efibootmgr или переустанавливать grub2, grub-install делать. Не комильфо. Должно быть тупа dd.

Так вот, как грамотно установить grubx64.efi на место bootx64.efi? Хочу перейти на лишнюю прослойку в виде загрузчика, ну чтоб просто по-феншую было.

Обновился CRUX 3.4 -> 3.5, теперь бесконечно долго загружается система, завтык происходит при запуске /etc/rc.d/sshd

Я уже и систему всю целиком переустановил, простым for i in /mnt/crux-iso/ports/core/*; do pkgadd -u $i; done, и ключи /etc/ssh/ssh_host_*_key{,.pub} удалил чтобы при запуске sshd сгенерировал их заново.

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

Для чистоты эксперимента я ещё не пробовал ставить CRUX 3.5 с нуля, без обновления поверх старого, но думаю что sshd можно вылечить и так.

# dig -t A google.com
google.com.		299	IN	A	173.194.222.113
google.com.		299	IN	A	173.194.222.101
google.com.		299	IN	A	173.194.222.100
google.com.		299	IN	A	173.194.222.138
google.com.		299	IN	A	173.194.222.139
google.com.		299	IN	A	173.194.222.102

когда клиент создаёт TCP/IP-соединение, он же ведь занимает порт, так?

# ss -an
State		Recv-Q	Send-Q	Local Address:Port	Peer Address:Port
ESTAB		0	0	78.24.219.239:80	spoofing:59144

диапазон портов, надо полагать

# sysctl -a
net.ipv4.ip_local_port_range = 32768	60999

но ведь 6 * (60999 - 32768) = 169386 это мало? не? для всего мира?

или существует какое-то иное решение проблемы? я просто хочу расширить домашний Wi-Fi... что сделать? больше шлюзов добавить? ну ладно, порты закончатся на 192.168.1.1, будут порты браться для 192.168.1.2... а провайдер? он же выдаёт мне только один IP-адрес? приехали?

Сабж. Того, что обжатый кабель^Wпатч-корд заводится на 1гбите вроде бы достаточно, но хотелось бы чуть более детальной информации, а вдруг что-то с ним не так. Или всё так, если он просто работает? Дешёвые китайские тестеры в пределах 2к выдадут не больше информации, чем собственно «просто работающая сеть», а какой-нибудь флюк за 10к очень дорохо.

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

это интернет, здесь вам даже никто не запретит написать «дебил, б11@7ь», и расписать по пунктикам с чем вы в итоге не согласны. в чём же заблуждение юзера.

нет, просто удалим и всё. и это форум? и это нетехнические РАЗГОВОРЫ о Linux/Unix? говно, не форум.

@

Доля чистого web-трафика в современном мире огромна относительно всего internet-трафика. Порог вхождения в разработку низкий. Никто не хочет писать desktop-standalone-приложения, все хотят разрабатывать сервисы онлайн без регистрации смс. Новые форумы, чаты, мессенджеры, всё это имеет под собой web-основу. Никто больше не хочет рисовать формочки в Delphi, все создают один единственный объект типа браузера для отображением своего сайта а-ля Steam. Ситуация ясна.

В то же время консорциум веб-разработчиков всеми способами бодается с TCP/IP-стеком, разрабатывая новейший HTTP2.

Почему бы тогда не взяться за разработку отдельного сетевого стека на уровне L4 (TCP, UDP) или даже L3 (IP)? Опуститься тремя уровнями ниже. Если TCP/IP им такой неидеальный. Знаю, это создаёт кучу проблем, ломанием всего того что уже работает, но не обязательно же ломать!

Сперва разработать приложение, имитирующее работу сетевого стека типа TCP... Но! Чтобы переход был плавный и незаметный, пускать его поверх TCP/IP. Вот как Onion-сети, i2p. Они ведь работают поверх TCP/IP? Такой же массовый HTTP3 запилить. А потом с очередным релизом браузеры просто массово перейдут на новый протокол, вместо транспортного приложения.

DNS? Сейчас это контролируется одной организацией, которая управляет всеми доменами первого/второго уровня, от этого суть не поменяется. Всё так же будет контролировать web-домены. Можно кстати начать с чистого листа, сделать отдельно web-домены и отдельно legacy-internet-домены. )))

Каждому клиенту можно будет выдавать уникальный идентификатор (вместо IP-адреса) на время веб-сессии! И привязывать его к сессионной куке на сайте, намного упрощает работу с пользователем. Будет проще отслеживать конечного пользователя и конечно же бороться с DDoS-атаками!

Ну что, даёшь HTTP3 пацаны? HTTP 3 != HTTP 3.0 (c)

Раньше Google (и другие компании) активно развивали веб, подарили нам Gmail, Google Plus, прелесть веб-технологий в их простоте реализации. Любой школьник мог себя противопоставить Google, я не говорю о выходе на тот-же уровень, но собрать на коленке всё тоже самое, что есть у Google, завести свою почту, вести блоги и тыды. Шло активное развитие веб. Где-то до середины 10-х годов веб оставался диковинкой и все в нём ковырялись.

А сейчас веб всё? Наигрались? Вплоть до того, что Google Plus закрывают, — фиг бы с ним, не в плюсаче дело. Передовая интернет-компания в мире не запускает новые продукты, не тратит ресурсы на развитие веб, а взяло новый курс на изучение нейросетей, развитие ИИ? Вместе с ними про ИИ и нейросети говорит всё АйТи сообщество, такие гиганты как nVidia, Intel занимаются производством и внедрением чипов в автомобильной промышленности, это всё круто, но условный Васян из Российской глубинки уже не в теме. Слишком высок порог вхожедния, как мне кажется, и в лучшем случае Васян научит свою нейросеть дорисовывать фрагменты картинок. Ну офигеть теперь! Васяну остаётся только наблюдать за всем этим со стороны и заносить по 100.000р за видеокарту в качестве доната на развитие технологий.

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

Васян оставшись на обочине жизни пойдёт снова гнать спирт из браги по желобкам в -50° мороз где-то в Сибирской глубинке.

Йэх...

Смотрю ютуб, со всех каналов трубят про первые 5G смартфоны, проходят выставки, где техноблоггеры тестируют 5G внутри помещений (т.е. пока ещё не внедрили опсосы). Но как же ПеКа-бояре? Про нас совсем забыли? Почему в 2019 году провайдеры ещё используют PPPoE и долбятся в соточку (100мбит/сек)? Где мой fiber-to-the-home? Чего уж там, если совсем недавно попросил второй интернет и мастер посчитал важным урезать весь потанцевал, таким образом пытаясь сказать, что о гигабите можешь даже не мечтать.

С другой стороны если посмотреть на опсосов, которые как я утверждаю, якобы обогнали десктопный сегмент устройств, — опсосы у нас точно так же слабо развиты примерно на уровне тех же провайдеров с PPPoE. Вот конкретно у нас даже 4G+ (300мбит) нет, 4G+ только в Красноярске. А про 5G в рамках целой страны можно пока не заикаться, полагаю. Но создаётся ощущение что все дружно забили на развитие ЛВС, никто ничего не собирается модернизировать и улучшать.

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