Насколько совместимы Debian и Red Hat?

[MiK13]

Сегодня вечером позвонил начальник и сказал, что получил от одного заказчика (которому мы поставили систему, работающую под управлением Debian 6) письмо примерно следующего содержания:
Debian не сертифицирован в смысле безопасности, поэтому мы хотим испольтзовать HREL 7
Что такое HREL7 он сообразить не мог и в конце концов решил, что это RHEL7, то есть Red Hat Enterprise Linux 7. И попросил меня скачать его, чтобы завтра попробовать запустить наши программы под ним.
Я пока не смог найти, где его скачать; на сайте требуется вход, для скачивания нужна регистрация. Но думаю, что если не найду, смогу договориться с админом института, взять у него. Но основной вопрос в другом.
Установка, как мы описали в документации, производится в несколько этапов.

1. Установка (с флешки, на которой записан образ первого диска) основной части системы, без рабочего окружения.
2. Вход в систему под рутом, монтирование флешки и запуск с ней скрипта, который установит дополнительные пакеты (mc, tcpdump, ngrep и т.д.), что-то иксовое, пакеты из файлов *.deb и затем командой apt-get -f install всё, что для них нужно.
   После этот этот же скрипт скопирует в /usr/lib все библиотеки, необходимые для работы основного АРМа, написанного на Qt.
3. Копирование всех файлов программ и настроек, необходимых для работы.

И основной вопрос: смогут ли наши программы (скопилированные в Debian) работать в системе Red Hat?
Какие могут быть особенности для запуска программ под Red Hat?

[ormorph]

Думаю стоит обратить внимание на appimage для создания везде запускающихся файлов тыц. Если не требуется suid бит, то проблем с запуском таких файлов нет хотя я с этим битом не экспериментировал. Просто останется что бы appimage включал все необходимые библиотеки.

[Vascom]

Скачай Centos 7.
Программы надо пересобирать из-за разных версий библиотек. Бинарной совместимости между Debian и RHEL нет.

[MiK13]

Думаю стоит обратить внимание на appimage для создания везде запускающихся файлов тыц.

Спасибо. Постараюсь разобраться с этим.

Программы надо пересобирать из-за разных версий библиотек. Бинарной совместимости между Debian и RHEL нет.

Думаю, что с этим проблем не будет. Все исходники есть.
Единственная проблема -- найти компьютер, чтобы установить RHEL.

[Bizdelnick]

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

Виртуалку/контейнер создать — тоже проблема?

[s.xbatob]

Это, пожалуй, самые далёкие друг от друга ветви Linux. Всё по-разному.
Хотя, когда разберёшься -- ядра одинаковые, утилиты тоже.
Это -- "не все йогурты одинаковые" а тут разница между дистрибутивами меньше, чем они из себя строят.

Добавлено (14:41):

MiK13
Ах, да, RHEL платный, скачать его нельзя.
На самом деле платная там только поддержка, все компоненты доступны, например в CentOS, но формально это уже не то. Для любителей чистоты можно после некоторой возни бесплатно скачать Oracle Linux (тот же RHEL), но начальники на это клюют.

[Bizdelnick]

Ах, да, RHEL платный, скачать его нельзя.

Платная там только поддержка. Предоставление isoшников, правда, входит в поддержку, и в открытом доступе их не выкладывают, но распространять их далее не возбраняется, так что можно у кого-нибудь попросить (хотя бы у того же заказчика). Но проще, действительно, скачать CentOS, — разницы никакой.

[s.xbatob]

Платная там только поддержка. Предоставление isoшников, правда, входит в поддержку, и в открытом доступе их не выкладывают, но распространять их далее не возбраняется, так что можно у кого-нибудь попросить (хотя бы у того же заказчика). Но проще, действительно, скачать CentOS, — разницы никакой.

Ещё раз -- народу нужны шашечки, а не проехать. у нас тоже начальство требует. В коммерческой фирме и заказчики тоже коммерческие, но на самом деле при госках.
Пока сошлись на Oracle OS, хотя скучно там.

[Bizdelnick]

народу нужны шашечки, а не проехать.

Шашечки нужны заказчику, вот он пусть и ставит у себя «HREL», а потом на него благополучно накатит софтину, собранную и отлаженную под CentOS (о чём ему знать совершенно необязательно).

В коммерческой фирме и заказчики тоже коммерческие, но на самом деле при госках.

Я тоже работаю в коммерческой фирме, и заказчики у нас самые разные, но они понятия не имеют, на каком дистрибутиве мы собираемся. Могут, в принципе, догадаться по минимальным требованиям к версии glibc, но им это на фиг не надо, пока всё работает. И сертифицирующим организациям это тоже фиолетово, их интересует только соответствие бинарей исходникам (за исключением самых запущенных случаев типа МО РФ).

[ormorph]

Спасибо. Постараюсь разобраться с этим.

А там совсем просто разобраться.
Просто создается директория dir(название не имеет значения) в которую копируется программа в той же структуре, какой она установлена в Debian, так же копируются системные библиотеки от которых зависит запуск программы в dir/usr/lib dir/lib, тут ldd в помощь.
Далее ссылка что я давал, выбираем готовые релизы и скачиваем appimagetool-x86_64.AppImage и AppRun-x86_64, далее переименовываем AppRun-x86_64 в AppRun и помещаем в каталог dir, даем права на выполнение и создаем либо копируем готовый desktop файл в директорию dir, который будет запускать программу находящуюся в dir/usr/bin.
Далее останется только выполнить:

Shell

$ ./appimagetool-x86_64.AppImage dir

После чего будет создан бинарник в который будет запускаться на большинстве дистрибутивов, так как он включяет в себя все необходимые библиотеки для запуска.
Для запуска такой программы как правило необходимо наличие установленного пакета libfuse, в различных дистрибутивах этот пакет называется по разному.
В качестве примера можно посмотреть как это сделано в готовых файлах appimage, на пример FrreeCad, есть на гитхабе. Данные файлы распаковываются достаточно просто:

Shell

$ file.appimage --appimage-extract

Структура каталога для создания appimage тыц

[MiK13]

Спасибо. Постараюсь разобраться с этим.

А там совсем просто разобраться.
Просто создается директория dir(название не имеет значения) в которую копируется программа в той же структуре, какой она установлена в Debian,

Тут есть одна "маленькая" проблема.
Мы не создаём пакеты для установки. У нас просто есть набор программ с дополнительными файлами настройки. Мы их просто копируем в свои каталоги. Запуск делаем из файла /etc/rc.local.
Впрочем, видимо придётся с этим разбираться немного позднее. Сейчас начальник потребовал поставить RHEL.

Я скачал через торент RHEL 7.6. Там три каталога -- Desktop, Server, Workstation. С образами DVD. Видимо надо ставить Workstation.
Скачал также CenOS -- DVD-1810 и Minimal-1810. В наличии была свободной только флешка на 4 ГБ, поэтому решил записать Mininal и поставить на ноутбук, на котором уже стояли Windows, Stretch(64) и Wheezy(32)
Уменьшил размер винды со 128 до 96 ГБ и на свободное место поставил CentOS. Правда, после этого возникла проблема с загрузкой Debian -- при попытке загрузить Stretch или Wheezy выскакивало

Код: Выделить всё

error: can't find command `linux'.
error: can't find command `initrd'.

Press any key to continue...

Выкрутился, нажав c и, в ответ на grub>, введя exit. Попал в обычное меню Debian.
Но появился начальник и сказал: "Не нужен никакой СеntOS, нужен Red Hat".
Дал флешку на 16 ГБ, сейчас буду ставить RHEL Workstation.

[Vascom]

Это не маленькая проблема.
Догоняйте уже уходящий поезд или рискуете остать навсегда.

А ещё лучше - беги из этой конторы и от такого начальника.

[MiK13]

Это не маленькая проблема.

Поэтому я и написал слово "маленькая" в кавычках
Но, с другой стороны, мы не делаем "универсальных" программ для обработки и контроля данных.
В той системе, про которую возникли вопросы у заказчика, одно измерительное устройство, которое выдаёт UDP бродкасты и два компьютера, которых их принимают. И есть дополнительная аппаратура, но она управляется по другим интерфейсам (USB/CAN)
И ещё к любому из этих компьютеров может подключаться ещё один один, чтобы получать некоторую информацию, либо по FTP, либо из UDP пакетов. Причём разрешение на это выдаётся на этих компьютерах через route add $IP $ETH (IP может быть только один)

А ещё лучше - беги из этой конторы и от такого начальника.

Проблема в том, что в моём возрасте уже некуда бежать.
Да и на начальника в целом грех жаловаться.

[Vascom]

Универсальность тут ни при чём. Если используется rpm-based дистрибутив, то лучше опакечивать всё ваше ПО. Сами себе потом спасибо скажете при обновлении и поддержке.

[Bizdelnick]

Если используется rpm-based дистрибутив, то лучше опакечивать всё ваше ПО.

Если deb-based, то тоже. А равно apk-based, nix-based, opkg-based, xbps-based и иже с ними.

Сами себе потом спасибо скажете при обновлении и поддержке.

У меня сложилось впечатление, что ТС и его начальник — не из тех, кто печётся о таких вещах.

[Vascom]

Да, я просто спешил. Любой пакетный дистрибутив.

[MiK13]

Универсальность тут ни при чём. Если используется rpm-based дистрибутив, то лучше опакечивать всё ваше ПО. Сами себе потом спасибо скажете при обновлении и поддержке.

А можно поподробнее? В чём достоинство "опакечивания" ПО?
Я понимаю, что в том, что при установке или обновлении система будет проверять на наличие дополнительных компонентов, необходимых для работы данной программы. И при необходимости будет их устанавливать (только откуда?)
Пока при необходимости что-то исправить или доработать в программе мы просто присылаем скрипт с прикреплённым архивом с файлами. Который эти файлы и обновляет.

[Vascom]

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

Вы можете опакетить даже просто обои рабочего стола, картинки. Не обязательно устанавливать зависимости, если вам их неоткуда брать, можно сделать статическую сборку и опакетить её.

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

[MiK13]

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

Всё это хорошо. Только тут есть одна проблема: нужен человек, который умеет работать с пакетным менеджером. А такого человека обычно нет. Поэтому инструкция для обновления простая:

1. Завершить работу с АРМом
2. В ответ на запрос login: набрать root, в ответ на запрос Password: ввести пароль (обычно какой-то очень простой)
3. Вставить флешку для обновления
4. Подождать сообщения от системы о том, что она её обнаружила
5. Ввести команду для монтирования флешки
6. Ввести команды для перехода в каталог флешки
7. Ввести команду запуска скрипта обновления.
8. Ввести команду reboot

Вы можете опакетить даже просто обои рабочего стола, картинки. Не обязательно устанавливать зависимости, если вам их неоткуда брать, можно сделать статическую сборку и опакетить её.

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

[Vascom]

Вам требуется лишь изменить пункт 7. Вместо команды запуска скрипта - выполнить команду пакетного менеджера.
Скрипт же кто-то делает, опакетить - не сложнее написания скрипта на bash.

Умеющего человека можно нанять, можно кого-то из молодых обучить. Хоть фрилансера или на этом форуме предложить разовую/периодичесую работу по опакечиванию. Если секреты - то можно и NDA подписать.

[Bizdelnick]

Вам требуется лишь изменить пункт 7. Вместо команды запуска скрипта - выполнить команду пакетного менеджера.

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

[MiK13]

Нашёл. Почитал. В принципе ничего особо сложного нет. Можно разобраться. Как-нибудь этим займусь.
Но на данном этапе мне это напоминает написание гуишной программы для складывания двух чисел вместо
printf("%d\n",atol(argv[1])+atol(argv[2]));
Возни на порядок больше, а результат тот же.

[Bizdelnick]

Нашёл. Почитал.

Не то Вы нашли. Читайте первоисточники: https://www.debian.org/doc/manuals/maint-guide/

Возни на порядок больше, а результат тот же.

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