Серия «ИТ»

О блокировках (в т.ч. сервиса Discord)

Итак, с недавнего времени заблокирован очередной сервис (который Discord). Довольно скоро в комментах под публикациями недовольных пользователей появились адепты VPN (ничего не имею против этой технологии и технологий-спутников, т.к. в рамках рабочего процесса активно это всё используется) с насмешкой в адрес обычных юзеров, далёких от ИТ.

Так вот, любая страна подключается к глобальной сети через трансграничные каналы связи (Internet backbone). Нагрузка на эти каналы всегда высчитывается и мониторится с целью избежать (через замену оборудования) чрезмерной утилизации канала/каналов связи.

VPN всегда увеличивает объем трафика в момент времени за счёт шифрования.

Нужно ли говорить, что будет, если в какой-то момент времени пропускной способности каналов (нагрузка увеличится, кстати, не только на трансграничные каналы, но и на внутренние) не хватит для обработки трафика? (гугол в помощь)

K.O.

9

Проброс видеокарты в виртуальную машину. Небольшой UPD

Приветствую!

Сей UPD является продолжением статьи "Проброс видеокарты в виртуальную машину".

На полноценную публикацию для Хабра не тянет, но описанный ниже момент для кого-то может оказаться полезным.

Итак, краткие исходные данные таковы (полный расклад в статье по ссылке выше):
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" должен иметь примерно такой вид.

Проброс видеокарты в виртуальную машину. Небольшой UPD IT, Linux, Windows, Виртуализация

1002:68e1,1002:aa68 - идентификаторы "Radeon HD 5430"

В файле «/etc/modprobe.d/local.conf» также меняем идентификаторы, но не отправляем в блэк-лист драйвер "radeon", т.к. оный необходим ОС при загрузке. В общем, файл "local.conf" должен содержать только одну строку - "options pci-stub ids=1002:68e1,1002:aa68".

Показать полностью 1
2

Firewalld. Занимательный факт

Салом! (привет на таджикском)

Занимательный (и чуточку возмутительный) факт обнаружил при скриптовании правил фаервола (который firewalld) в ОС вида "RHEL8" (AlmaLinux8, Rocky Linux 8, etc).

По какой-то неведомой причине добавление элементов ipset-а в сам ipset через файл работает "через раз" (в общем, как повезёт), если использовать "--add-entries-from-file" в рамках bash-скрипта.

Провёл не менее десятка попыток запуска скрипта. Корректно ряд подобных команд (для 4-х ipset-ов) отработал только единожды, хотя ввод вручную отрабатывает стабильно (не проверял более трёх раз).

При этом, если в рамках скрипта использовать в цикле команду на добавление единичного элемента в конкретный ipset ("--add-entry"), то проблем не возникает.

В общем, в скриптах лучше задействовать добавление элементов в ipset при помощи "--add-entry".

Firewalld. Занимательный факт Linux, Информационная безопасность, IT, Red Hat, Firewall, Командная оболочка bash

Firewalld (RHEL8). Интересный факт

Максимальное время нахождения элемента ipset-а во временном наборе (элемента ipset-а в ipset-е, где при создании был указан параметр "timeout" > 0) - чуть менее 25 дней, а если точнее, то 24 дня, 20 часов, 31 минута и 23 секунды или 2147483 секунд.

Поэтому, если, например, требуется предоставить некий доступ через firewalld на довольно долгий срок, но всё-таки не на постоянной основе, то требуется решение, отличное от временных элементов ipset-ов.

9

Проблема с data-кабелем SATA III

Oel ngati kame!

Столкнулся недавно с весьма интересной неполадкой. Начало классическое - после отправки в 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", демонстрирующий в том числе описанную выше проблему.

Проблема с data-кабелем SATA III IT, Linux, Жесткий диск, Sata 3, Системное администрирование, Компьютер

Такой вот интересный случай.

В общем, доброй ночи и удачи!

Показать полностью 1

Про firewalld и ipset-ы с ограниченным временем жизни элементов (RHEL8)

Slan!

Довольно забавный момент связан с "механикой" добавления/удаления ipset-элементов в ipset-списки с ограниченным временем жизни (параметр "timeout") элементов. Для краткости будем называть такие списки "temporary_ipset".

1. Создадим temporary_ipset через firewall-cmd
"firewall-cmd --permanent --new-ipset=temporary_ipset --option=timeout=6000"
"firewall-cmd --reload".

2. Добавим в ipset пару элементов
"firewall-cmd --ipset=temporary_ipset --add-entry="11.12.13.14""
"firewall-cmd --ipset=temporary_ipset --add-entry="14.13.12.11"".

3. Попытаемся посмотреть список элементов через firewall-cmd
"firewall-cmd --permanent --info-ipset=temporary_ipset".

Список элементов мы не увидим, т.к. для просмотра элементов с ограниченным временем жизни необходимо использовать команду
"ipset list temporary_ipset". Так вот не очень удобно реализовано (RHEL8).

4. Удаление элемента из temporary_ipset тоже с подвохом.
Команда "firewall-cmd --permanent --ipset=temporary_ipset --remove-entry="11.12.13.14"" не даст нужного результата и выдаст ответ вида "Error: IPSET_WITH_TIMEOUT".

Для удаления из temporary_ipset необходимо воспользоваться утилитой ipset -
"ipset del temporary_ipset 11.12.13.14".

5. Добавление элемента в temporary_ipset с таймаутом, отличным от заданного, невозможно через firewall-cmd. В этом случае нам также поможет утилита ipset -
"ipset add temporary_ipset 11.12.13.144 timeout 500".

6. Чтобы переопределить таймаут уже добавленного элемента, необходимо через утилиту ipset сначала удалить элемента, а после добавить с иным таймаутом.

(Небольшой бонус)
7. Удаление temporary_ipset осуществляется уже стандартно -
"firewall-cmd --permanent --delete-ipset=temporary_ipset".
После необходимо выполнить "firewall-cmd --reload". Если этого не сделать, то ipset всё ещё будет доступен через одноимённую утилиту.

Если по каким-то причинам нежелательно проводить reload, то исполняем команду удаления ipset-а (выше), а после удаляем temporary_ipset посредством команды
"ipset destroy temporary_ipset".

Показать полностью

Cеть на RHEL8-based хостах. Error fixed

Доброго утра/дня/вечера/ночи (нужное подчеркнуть)!
===
Дополнение к публикации: Разворачиваем сеть на RHEL8-based хостах (копия с Хабра)
===
Неприятный баг, созданный собственноручно (увы, недосмотрел), обнаружил сегодня.

Как оказалось, в код ansible-хелпера "conf_int_ipv4_via_network_scripts" закралась ошибочка, не позволявшая корректно настраивать сетевые интерфейсы (или их сочетание), связанные с VLAN-ами.

Ошибка устранена.
===
Если вы пользуетесь репозиторием и нашли баг, то send email to vladimir.chursin000@yandex.ru

Отличная работа, все прочитано!