История не очень приятная, но за последнее время слишком много инсинуаций касательно СПО. Важно внимательно почитать каждую новость и понять, что вся эта движуха связана с санкциями, в т.ч. вторичными. Да и Линус имеет право на своё мнение (Whatever It May Be).
СПО на The Linux Foundation и лично Линусе не заканчивается. Да и заявление Джеймса Боттомли углы сглаживает, а исходники доступны для скачивания (и они бесплатны).
Итак, с недавнего времени заблокирован очередной сервис (который Discord). Довольно скоро в комментах под публикациями недовольных пользователей появились адепты VPN (ничего не имею против этой технологии и технологий-спутников, т.к. в рамках рабочего процесса активно это всё используется) с насмешкой в адрес обычных юзеров, далёких от ИТ.
Так вот, любая страна подключается к глобальной сети через трансграничные каналы связи (Internet backbone). Нагрузка на эти каналы всегда высчитывается и мониторится с целью избежать (через замену оборудования) чрезмерной утилизации канала/каналов связи.
VPN всегда увеличивает объем трафика в момент времени за счёт шифрования.
Нужно ли говорить, что будет, если в какой-то момент времени пропускной способности каналов (нагрузка увеличится, кстати, не только на трансграничные каналы, но и на внутренние) не хватит для обработки трафика? (гугол в помощь)
На полноценную публикацию для Хабра не тянет, но описанный ниже момент для кого-то может оказаться полезным.
Итак, краткие исходные данные таковы (полный расклад в статье по ссылке выше): 1) 2 видеокарты: "Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X]" (используется для ВМ с Win10) и "Park [Mobility Radeon HD 5430]" (используется для хост-системы);
2) "Radeon HD 5430" (старенькая видюха) воткнута в первый pcie-слот материнки, а "Lexa PRO" (железяка поновее) - во второй (кстати, в статье этот момент описан не совсем корректно);
Видеокарту "Radeon HD 5430" понадобилось перекинуть с хост-системы на ВМ, а "Lexa PRO" - на хост-систему.
Чтобы это сделать корректно, необходимо карту из первого слота явно отвязать от хост-системы. Небольшая сложность тут в том, что она идёт первой в очереди на инициализацию хост-системой.
Очерёдность инициализации выводится посредством получения содержимого procfs-файла "/proc/fb" (fb = framebuffer). Выглядеть это будет, например, так
0 efifb vga 1 amdgpudrmfb
Чтобы не использовать видеокарту в хост-системе для передачи в ВМ в статье было задействовано как изменение параметров ядра (grub) при загрузке, так и механизм подгружаемых модулей ядра (modprobe), т.е.
1) добавление параметров «intel_iommu=on iommu=on rd.driver.pre=pci-stub pci-stub.ids=1002:67ff,1002:aae0» (идентификаторы "Lexa PRO") в grub и 2) «blacklist amdgpu» и «options pci-stub ids=1002:699f,1002:aae0» -> «/etc/modprobe.d/local.conf».
Т.к. первой хост-система (ОС AlmaLinux8) захватывала "Radeon HD 5430", то проблем в рамках описанной в статье конфигурации не было.
В случае же, когда есть необходимость в ВМ прокинуть карту, находящуюся в более приоритетном слоте, в параметры загрузки мы должны прописать явный запрет на захват целевой карты. Делается это посредством добавления подстроки "video=efifb:off" (подстрока "efifb" взята из вывода "cat /proc/fb") в параметр GRUB_CMDLINE_LINUX ("/etc/default/grub") и последущим исполнением команд grub2-mkconfig + dracut + перезагрузка.
Итого, файл "/etc/default/grub" должен иметь примерно такой вид.
1002:68e1,1002:aa68 - идентификаторы "Radeon HD 5430"
В файле «/etc/modprobe.d/local.conf» также меняем идентификаторы, но не отправляем в блэк-лист драйвер "radeon", т.к. оный необходим ОС при загрузке. В общем, файл "local.conf" должен содержать только одну строку - "options pci-stub ids=1002:68e1,1002:aa68".
Занимательный (и чуточку возмутительный) факт обнаружил при скриптовании правил фаервола (который firewalld) в ОС вида "RHEL8" (AlmaLinux8, Rocky Linux 8, etc).
По какой-то неведомой причине добавление элементов ipset-а в сам ipset через файл работает "через раз" (в общем, как повезёт), если использовать "--add-entries-from-file" в рамках bash-скрипта.
Провёл не менее десятка попыток запуска скрипта. Корректно ряд подобных команд (для 4-х ipset-ов) отработал только единожды, хотя ввод вручную отрабатывает стабильно (не проверял более трёх раз).
При этом, если в рамках скрипта использовать в цикле команду на добавление единичного элемента в конкретный ipset ("--add-entry"), то проблем не возникает.
В общем, в скриптах лучше задействовать добавление элементов в ipset при помощи "--add-entry".
Максимальное время нахождения элемента ipset-а во временном наборе (элемента ipset-а в ipset-е, где при создании был указан параметр "timeout" > 0) - чуть менее 25 дней, а если точнее, то 24 дня, 20 часов, 31 минута и 23 секунды или 2147483 секунд.
Поэтому, если, например, требуется предоставить некий доступ через firewalld на довольно долгий срок, но всё-таки не на постоянной основе, то требуется решение, отличное от временных элементов ipset-ов.
Столкнулся недавно с весьма интересной неполадкой. Начало классическое - после отправки в reboot домашний сервер (от сервера тут только одно название, т.к. системный блок собран из того, что возможно купить на потребительском рынке) операционная система (AlmaLinux8) хоть кое-как загрузилась (через раз), но дальше приглашения ввести логин/пароль дело не пошло. При вводе корректных авторизационных данных - возврат к приглашению.
Симптомы весьма таки знакомые. Подозрение пало на жесткий диск, поэтому решил вытащить из запаса новенький диск и восстановить ОС из заранее подготовленного бэкапа посредством замечательной команды "dd if=/dev/SOURCE_DISK_DEVICE of=/dev/TARGET_DISK_DEVICE bs=4096" (где *_DISK_DEVICE - символьное обозначение дискового устройства), дабы не тратить время на новую установку. И финт ушами не сработал, хотя я точно помнил, что после покупки диск был мной проверен через "smartctl -t short /dev/DISK_DEVICE", о чем сообщала надпись с датой проверки на монтажной ленте, наклеенной сразу после тестирования.
Проблема разрешилась довольно быстро. Помогла замена data-кабеля SATA III (хорошо, что запас разного рода "шнурков" всегда под рукой), что спасло старенький HDD от физических повреждений и отправки в утиль. Читал, конечно, когда-то про то, что некачественный data-кабель может привести к потере данных, но на практике столкнулся впервые (видимо, до этого везло с data-кабелями). Дело в том, что наилучший вариант - это кабель с позолоченными контактами (стандарт де-факто), но в данном случае, видимо, это было не так (думал, кстати, просто протереть контакты, но у современных sata-шлейфов они хорошо так утоплены в пластик), что привело к постепенному окислению соединений (позолота или иное покрытие от этого защищает).
P.S. Наглядный пример вывода команды "dmesg", демонстрирующий в том числе описанную выше проблему.
