Почему для Windows платно, а для Linux бесплатно.
Где кончается ядро и начинаются проблемы совместимости в Linux
Настройка USB Redirector для Linux
Пингвин расправил крылья?
Почему для Windows платно, а для Linux бесплатно
В настоящее время USB ключи защиты для 1С становятся антиквариатом, который постоянно растет в цене, поскольку санкции перекрыли их поставки, но за 15 лет их еще огромное количество. USB ключ гораздо удобней программной лицензии, особенно в виртуальной среде, где любые перемещения виртуальной машины приводят к необходимости переактивации лицензии. В конце концов программную лицензию удобно привязать к USB ключу (любого номинала). Минус их нужно пробрасывать.
Проброс USB в Linux можно делать разными способами.
Например, можно через usbip (usbip win) , который позиционируется как стандартный. Попробуйте поставить его на Oracle Linux (Red hat) версии 9. Поиск по всем рекомендованным репозиториям результатов не дает. Изучение вопроса приводит к необходимости компилировать это из исходников под конкретное ядро Linux. Ладно, смотрим дальше.
У меня был положительный опыт эксплуатации USB Redirector для Windows, однако он платный. Посмотрел версию для Linux, здорово — она бесплатная! И клиентская и серверная. Изучение инструкции по установки привело в уныние — нужно тоже компилировать из исходников и еще мирится с этим
If your kernel is updated after USB Redirector installation, you may need to re-install the program to re-compile its kernel module!
This is because kernel modules in Linux are tied to a particular kernel version, thus they need to be re-compiled for each new kernel to work correctly
Ну вы поняли, если в Windows я ставлю USB Redirector, то я могу спокойно ставить обновления и на 99% быть уверенным, что все будет работать. А вот в Linux при обновлении ядра можно быть на 99% уверенным, что это работать не будет. Потому что USB Redirector нужно пересобирать! А как же тогда обновления? А вот Вам
Таким образом мы имеем две проблемы
Отсутствие rpm с нужной программой для текущего ядра.
Необходимость постоянной перекомпиляции при обновлении.
Причина такой ситуации лежит исключительно в идеологии построения системы Linux. Есть замечательная статья от сообщества Linux, которая отвечает на вопрос: Почему в Linux так? И конечно дорога в этот ад системного администратора, была выстроена исключительно благими намерениями обеспечить рай для разработчиков.
The Linux Driver Model: A Better Way to Support Devices - The Linux Foundation
Рассмотрим детально на примере развертывания USB Redirector
Где кончается ядро и начинаются проблемы совместимости в Linux
Итак имеем свежеустановленный Oracle linux с версией ядра
uname -r
5.15.0-302.167.6.el9uek.x86_64
Usb redirector по странному совпадению запрещает доступ на сайт из России, но из-за границы все работает. Поэтому исходные инструкции положил тут
Инструкции по установки USB Redirector
Распакованный дистрибутив нужно скопировать на сервер Linux и запустить из каталога дистрибутива команду
sudo ./installer.sh installВ теории клиентская и серверная часть USB Redirector должна быть скомпилирована, собрана и установлена , но меня конечно поджидал сюрприз
«Kernel sources or kernel headers directory not found»
В инструкции разработчик предлагает установить пакеты. Вот такой командой
yum install make gcc chkconfig kernel-devel-`uname -r`Но пакета kernel-devel для моей версии ядра найдено не было. И это на свежей инсталляции Oracle Linux!
Это кстати «нормальная» практика распространения софта в Linux через нескомпилированные модули, и как Вы увидите дальше причина не в лени разработчиков софта, а в идеологии ядра.
Чтобы разобраться в этом нужно достичь определенного уровня понимания. Это как в физике, чтобы достичь понимания процессов во вселенной надо сначала изучить процессы в ядрах, элементарных частицах и т.д.
Далее я буду ссылаться на The Linux Driver Model: A Better Way to Support Devices - The Linux Foundation в которой Linux разработчики сравнивают модели драйверов Linux и Windows. Рекомендую прочитать на английском, если хочется понять глубже мотивацию разработчиков Linux.
На данной картинке видно, что в операционной системе (Windows и Linux ) есть понятия
API – application programming interface
ABI – application binary interface
При чем они могут существовать в двух областях Linux kernel to user space, Linux kernel to internal.
Так вот в Windows ABI – application binary interface подразумевает стабильность даже в рамках разных версий Windows.
В Linux стабильности ABI нет даже в разных версий ядра и это сознательная стратегия.
В Linux НЕТ стабильности ни в ABI ни в API при разработке драйверов, но есть стабильность в user space interface. Это позволяет скомпилированным приложениям работать на разных версиях Linux без особых проблем, а вот скомпилированным драйверам уже нет.
По сути в Linux драйвера это часть ядра. Есть даже понятие драйвер принят в mainline kernel. В Windows драйвера и ядро четко изолированы – разработчики драйверов не видят код ядра, а разработчики кода ядра не видят кода драйверов. В Linux нормально предоставить код драйвера для компиляции пользователем под конкретное ядро.
Итак давайте сравним модели по критериям.
Совместимость скомпилированных драйверов.
В Windows совместимость выше.
В Linux она никакая, совместимость можно достичь, только скомпилирова�� драйвер заново.
Кроссплатформенность
В Windows она низкая, поскольку ABI может быть стабилен только в рамках платформы.
В Linux высокая кроссплатформенность, поскольку сборка дистрибутива подразумевает компиляцию исходников кода под платформу.
Совместимость со старым оборудованием.
В Windows драйвер работает пока не наблюдается фатальной несовместимости с новыми версиями ОС.
В Linux это решается перекомпиляцией, старые драйвера исключаются, если пользователей становится критически мало.
Толерантность к обновлениям.
У Windows высокая, поскольку подразумевается совместимость интерфейса для драйверов
У Linux зависит где обновление: в user space или kernal – internal. Если драйвер является частью репозитория проблем нет, если нет то нужно компилировать драйвер заново. А поскольку делать rpm для каждой версии ядра это неоплачиваемый труд, то Вам дадут исходник для компиляции
Устойчивость модели к ошибкам.
В Windows после компиляции, разработчик может покрыть свой драйвер тестами и передать администратору. Исходники распространять нет нужды – ABI разных ядер совместим.
В Linux после компиляции, администратор просто не имеет возможности покрыть драйвер тестами. Кто же ему их даст?
Разработчики Linux считают свою модель ABI прогрессивной по следующим причинам:
Полностью открытый код ядра и драйвера, позволяет писать его оптимально.
Не нужно реализовывать устаревшие спецификации (например для USB), можно сразу реализовывать новые.
Включение драйверов в ядро позволяет достичь стабильности ОС, ведь там будет отличный code review с обоих сторон.
Высокая кроссплатформенность в том числе для будущих поколений оборудования.
В качестве сравнения с Windows приводится ситуация с драйверами под Windows Vista — переход на 64бит и дальнейшая поддержка. Да — разработчики драйверов под Windows поддерживают драйвера ровно до окончания цикла продаж устройства. Это особенно видно по китайским ноутбукам.
Вот только разработчики Linux почему-то не акцентируют внимание на двух проблемах.
Компиляция драйвера подразумевает тестирование как часть DevOps, а на практике что и как скомпилируется у пользователя никак не тестируется. Т.е. изначально мы внедряем в операционную систему непротестированную сборку драйвера.
Если драйвер часть ядра ОС, мы получим несовместимость при обновлении ОС Linux
Если бы компиляция всегда производилась гладко, как установка rpm пакетов с контролем зависимости, эту ситуацию можно было бы принять. Но как увидите далее все гораздо хуже.
На самом деле ABI модель определяет и будущее Linux. Будет ли она удобным инструментом ИТ инфраструктуры, или ее нишей будут устройства типа настроил, забыл. Обновления - работает не трогай. Для того чтобы сделать для себя вывод - посмотрим как происходит дальше установка USB Redirector. Напомню, что не был найден kernel-devel подходящий для текущего ядра.
Подключаем выключенные по умолчанию репозитории
dnf repolist
далее можно включить дополнительные репозитории указав в файлах каталога
/etc/yum.repos.d
Enable=1
подключаем репозиторий epel (extra packages for enterprise linux) – вдруг что то нужное найдется там.
dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
как подключать репозиторий тут How to add a Yum repository
Если попытаетесь запросить пакет так – вы не найдете kernel-devel, найдете что то другое. Странно да?
dnf list kernel-* | grep 5.15.0-302.167.6
kernel-uek.x86_64 5.15.0-302.167.6.el9uek @anaconda
kernel-uek-core.x86_64 5.15.0-302.167.6.el9uek @anaconda
kernel-uek-modules.x86_64 5.15.0-302.167.6.el9uek @anaconda
#Попробуйте использовать ключ –showduplicates — иначе не найдет
dnf list --showduplicates kernel*devel*
#И вот сюрприз, package kernel-devel в Oracle linux имеет другой формат
dnf install <package_name>-<version>-<release>.<architecture>
#Теперь можно выполнить команду, для подтверждения наличия нужно версии пакета
dnf list kernel-uek-devel-5.15.0-302.167.6.el9uek.x86_64
Last metadata expiration check: 0:23:18 ago on Wed 12 Nov 2025 12:13:52 AM +06.
Available Packages
kernel-uek-devel.x86_64 5.15.0-302.167.6.el9uek ol9_UEKR7
Устанавливаем Package
dnf install kernel-uek-devel-5.15.0-302.167.6.el9uek.x86_64
Last metadata expiration check: 0:23:48 ago on Wed 12 Nov 2025 12:13:52 AM +06.
Dependencies resolved.
==============================
Package Architecture Version Repository Size
==============================
Installing:
kernel-uek-devel x86_64 5.15.0-302.167.6.el9uek ol9_UEKR7 41 M
--- тут я подсократил вывод
Running transaction
Preparing : 1/1
Installing : kernel-uek-devel-5.15.0-302.167.6.el9uek.x86_64 1/1
Running scriptlet: kernel-uek-devel-5.15.0-302.167.6.el9uek.x86_64 1/1
Verifying : kernel-uek-devel-5.15.0-302.167.6.el9uek.x86_64 1/1
Installed:
kernel-uek-devel-5.15.0-302.167.6.el9uek.x86_64
Complete!
Попытка запустить скрипт ./installer.sh заново install предлагает установить dkms
Dkms позволяет автоматически перекомпилировать нужные модули, а не весь проект ядра.Лучше установить, иначе придется переходить на следующий уровень сложности.
Установка dkms
dnf install dkms
Вывод я приводить не буду, но он ставит зависимости с предыдущей версией ядра – выглядит страшно, какие будут side effect время покажет
Повторяем инсталляцию USB Redirector, и ура установилось
./installer.sh install
*** Installing USB Redirector for Linux v3.12
*** Destination dir: /usr/local/usb-redirector
*** Checking installation...
*** Detecting system...
*** distribution: redhat
*** init: systemd
*** kernel: 5.15.0-302.167.6.el9uek.x86_64
*** dkms: dkms-3.2.2
*** Configuring kernel module...
*** Compiling kernel module with dkms...
*** Kernel module successfully compiled
*** Creating directories...
*** Preparing scripts...
*** Copying files...
*** Installing daemon...
*** Starting daemon...
*** Please allow incoming connections on 32032 port for the USB server to be able to accept connections from remote clients.
*** INSTALLATION SUCCESSFUL! To uninstall, run /usr/local/usb-redirector/uninstall.sh
Как видите, происходит процесс «Compiling kernel module with dkms...» , поздравляю Вы выполнили часть функций разработчика, но без покрытия тестами. Надеюсь дальше будет все хорошо.
Настройка USB Redirector для Linux
При настройке подразумеваем, что есть один сервер с ключами, а другой (виртуальная машина) их использует. Usb redirector устанавливается на обе машины — просто на сервере с ключами делает share (сервер ключей), а на сервере с приложением просто подключение (клиент)
Не забудьте проверить наличие порта «32032» на сервере с ключами
firewall-cmd --query-port=32032/tcp
firewall-cmd --zone=public --permanent --add-port=32032/tcp
firewall-cmd --zone=public --permanent --add-port=32032/tcp
firewall-cmd –reload
Сначала проверяем статус установленного софта (на обоих серверах), сервис должен быть в Enable.
systemctl status usbsrvd
● usbsrvd.service - IncentivesPro USB Redirector for Linux
Loaded: loaded (/usr/lib/systemd/system/usbsrvd.service; enabled; preset: disabled)
Active: active (running) since Wed 2025-11-12 00:57:35 +06; 16min ago
Process: 119397 ExecStartPre=/sbin/modprobe usbcore (code=exited, status=0/SUCCESS)
Process: 119398 ExecStartPre=/bin/sh -c [ -f /usr/local/usb-redirector/bin/tusbd.ko ] && /sbin/insmod /usr/local/usb-redirector/bin/tusbd.ko >/dev/null 2>&1 && exit 0;>
Process: 119400 ExecStart=/usr/local/usb-redirector/bin/usbsrvd (code=exited, status=0/SUCCESS)
Main PID: 119401 (usbsrvd)
Tasks: 8 (limit: 21297)
Memory: 3.5M
CPU: 47ms
CGroup: /system.slice/usbsrvd.service
└─119401 /usr/local/usb-redirector/bin/usbsrvd
Nov 12 00:57:35 ERP1CUX systemd[1]: Starting IncentivesPro USB Redirector for Linux...
Nov 12 00:57:35 ERP1CUX systemd[1]: Started IncentivesPro USB Redirector for Linux.
Далее из каталога приложения /usr/local/usb-redirector запускаем добавление адреса сервера, где расположены ключи . Там аналогичным образом должен быть установлен сервер Usb-redirector. Подробное описание настройки сервера Usb-redirector указано в инструкции производителя Инструкции по установки USB Redirector . Мы же сейчас на клиенте Usb-redirector добавим адрес сервера Usb-redirector (где физически стоят USB ключи).
./usbclnt -add-server 192.168.0.157:32032
====================== OPERATION SUCCESSFUL =====================
USB server has been added
===================== ======================= ===================
Проверяем, какие ключи доступны. Предварительно на сервере с ключами нужно сделать share. Мы в данном случае пробрасываем готовые ключи
./usbclnt -list-devices
================== LIST OF REMOTE USB DEVICES ===================
1: USB server at 192.168.0.157:32032
Mode: manual-connect Status: connected
|
|- 2: Sentinel HL
| Vid: 0529 Pid: 0001 Port: 3-11
| Mode: manual-connect Status: available for connection
|
`- 3: Sentinel HL
Vid: 0529 Pid: 0001 Port: 3-12
Mode: manual-connect Status: available for connection
===================== ======================= ===================
Теперь нужно эти ключи пробросить (присоединиться к ним) и они станут доступными на сервере 1С
./usbclnt -connect 1-2
====================== OPERATION SUCCESSFUL =====================
USB device connected
===================== ======================= ===================
./usbclnt -connect 1-3
====================== OPERATION SUCCESSFUL =====================
USB device connected
===================== ======================= ===================
#Посмотрите как изменился статус
./usbclnt -list-devices
================== LIST OF REMOTE USB DEVICES ===================
1: USB server at 192.168.0.157:32032
Mode: manual-connect Status: connected
|
|- 2: Sentinel HL
| Vid: 0529 Pid: 0001 Port: 3-11
| Mode: manual-connect Status: connected
|
`- 3: Sentinel HL
Vid: 0529 Pid: 0001 Port: 3-12
Mode: manual-connect Status: connected
===================== ======================= ===================
Ну вот видите работает, но до следующего обновления релиза ядра.
Пингвин расправил крылья?
Я думаю пройдя этот путь, возникает понимание, что Linux имеет достаточно высокий порог входа. Так что не удивляйтесь стабильно низким процентам Linux на декстопах, поскольку при таком раскладе установка драйвера приводит пользователя прямо в ядро. Ваша бабушка, которая работает на Linux, сможет сама установить отправленный ей драйвер, по Вашим подсказкам?
Linux Statistics 2025: Desktop, Server, Cloud & Community Trends • SQ Magazine
Очевидно, что при такой архитектуре даже автообновление драйвера возможно только при наличии репозитория с rpm, где все возможные драйверы скомпилированы под текущую версию ядра. Это фантастика, поэтому исходник как дистрибутив будет еще очень долго.
А в результате, как на примере с USB, возникает слишком много неудобных вопросов:
Если в Linux распространяется свободный код драйвера как исходник и он же дистрибутив , как тогда обеспечивается его валидация после компиляции?
Как, необходимость администратору компилить код из исходников, вообще вписывается в требования DevOps в части автоматизированного тестирования?Откуда у него автотесты?
Если компилить драйвера из исходников в Linux это нормально, почему тогда kernel-devel не имеет единой маски, и не присутствует сразу после установки в нужном формате, и в нужной версии?
Почему dkms не установлен по умолчанию?
Для меня вообще загадка – есть ли вообще какая то стратегия развития в свободном ПО, или возможность свободно использовать открытый код уже является стратегией?
Понятно, что для разработчиков достаточно удобно видеть открытый код, и иметь возможность скомпилировать все, что нужно.
Напротив - для спецов, желающих построить серверную инфраструктуру на Linux (Администраторы) это серьезный вызов в надежности. С одной стороны нужно периодически ставить обновления, с другой нужно помнить – что же развалится при обновлении.
И вот тут мы приходим к главному:
В операционных системах «для человека»: Количество пользователей >>> количества администраторов > количества разработчиков. Потому что такая ОС как минимум, должна быть пластичной для потребителей, удобно обновляемой, простой для кастомизации и т.д.
Но на Linux процент пользователей на Desktop или VDI прямо скажем не радует - 2%. С другой стороны, когда мы смотрим статистику по Web Servers, Embedded systems, специализированным серверам приложений - там сразу большие цифры около 70%
А вот если посмотреть, кому доверяют дирижировать ИТ инфраструктурой ( конкуренты Microsoft Active Directory) статистика сразу меняется не в пользу Linux (<20%).
О чем это говорит? Linux в идеологии так и осталась операционной системой для устройств и докеров: Собрал, настроил, работает и не трогай, иначе развалится. В век ИИ и виртуализации это выглядит архаично.
Проблема как всегда, в сообществе. Ну не видят они потребности в выходе Linux на более глобальные задачи. В предыдущей статье про Linux GUI было наглядно продемонстрировано, что неспособность сообщества стандартизировать GUI оставили Linux без нормальной подсистемы GUI Linux дневник импортозамещения. Linux GUI – ложное искушение . При том X Window System для UNIX (не путать с Linux) был еще в 80х, и на развитие было 30 лет.
Даже в вопросах безопасности – selinux не включили в ядро, реализовали так, что безопасность нужно устанавливать дважды (в OS и SElinux) и все равно она многих не устраивает, появляются альтернативы Security-Enhanced Linux против 1С + Apache. Выключить нельзя мучаться / Хабр . Есть еще хорошая статья почему нельзя просто взять selinux за стандарт, несмотря на открытый код Преимущества использования СЗИ в ОС Astra Linux Special Edition / Хабр - многое проясняет
В такой ситуации, видится только один разумный выход импортозамещения на Linux - каждому сервису своя ОС Linux. Каждому конечному - пользователю GUI терминал с ограниченным функционалом. Безопасность Firewall, SElinux или что нравится. Обновление только переходом на новый образ ОС раз в 5 лет. Вот такое импортозамещение.
До новых встреч на нашем канале t.me/Chat1CUnlimited
P. S. Если думаете, что прокидывание USB по IP редкое явление и остальное есть в репозитории, вот вам пример с Amnezia VPN для Red hat
dnf copr enable amneziavpn/amneziawg
Enabling a Copr repository. Please note that this repository is not part
of the main distribution, and quality may vary.
The Fedora Project does not exercise any power over the contents of
this repository beyond the rules outlined in the Copr FAQ at
<https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr>,
and packages are not held to any quality or security level.
Please do not file bug reports about these packages in Fedora
Bugzilla. In case of problems, contact the owner of this repository.
Do you really want to enable copr.fedorainfracloud.org/amneziavpn/amneziawg? [y/N]: y
Repository successfully enabled.
[root@ bin]# dnf list amneziawg-dkms
Copr repo for amneziawg owned by amneziavpn 2.3 kB/s | 5.0 kB 00:02
Available Packages
amneziawg-dkms.noarch 1:1.0.20241112-1.el9 copr:copr.fedorainfracloud.org:amneziavpn:amneziawg
amneziawg-dkms.src 1:1.0.20241112-1.el9 copr:copr.fedorainfracloud.org:amneziavpn:amneziawg
[root@ bin]# dkms status
tusbd/3.12, 5.15.0-302.167.6.el9uek.x86_64, x86_64: installed
[root@ bin]# dnf list amneziawg-tools
Last metadata expiration check: 0:01:13 ago on Sat 15 Nov 2025 01:17:01 AM +06.
Available Packages
amneziawg-tools.src 1.0.20240201-1.el9 copr:copr.fedorainfracloud.org:amneziavpn:amneziawg
amneziawg-tools.x86_64 1.0.20240201-1.el9 copr:copr.fedorainfracloud.org:amneziavpn:amneziawg
