GBox в Docker: настройка контейнера для CCcam/OScam

Если вы дошли до этапа контейнеризации шаринга — значит, уже пережили ручную установку, конфликты библиотек и ситуацию «обновил бинарник, всё сломалось». Gbox Docker контейнер: настройка — это именно та тема, где большинство мануалов бросают вас на полпути: команды есть, объяснений — ноль. Разберём всё по порядку: от Dockerfile до диагностики UDP через tcpdump.

Что такое GBox и зачем запускать его в Docker

Краткое описание протокола GBox и его место рядом с CCcam/OScam

GBox — это протокол карточного шаринга, работающий поверх UDP. Исторически он появился раньше CCcam и до сих пор используется в связке с OScam как дополнительный транспорт. Порт по умолчанию — UDP 8004, хотя в конфиге можно задать любой другой. GBox не занимается декодированием напрямую — он доставляет ECM/EMM между нодами, а уже OScam или CCcam их обрабатывает.

В типичной схеме GBox работает как мост: принимает контрольные слова от удалённых пиров и передаёт их локальному OScam через loopback. Отдельно GBox почти никто не запускает — он идёт в паре с OScam через протокол-мост или с CCcam через его встроенную поддержку GBox.

Главная проблема: официального репозитория с пакетами нет. GBox распространяется как бинарник под конкретную архитектуру, и это сразу порождает зависимость от окружения хоста.

Преимущества контейнеризации: изоляция, откат версий, переносимость

Docker решает несколько реальных проблем. Первая — изоляция: GBox и его зависимости не конфликтуют с системными библиотеками хоста. Вторая — откат: если новая версия бинарника ломает связь с пирами, откатиться к предыдущему образу занимает секунду (docker-compose down && docker-compose up -d с тегом старого образа). Третья — переносимость: перенести шаринг на другой сервер значит скопировать каталог с конфигами и docker-compose.yml.

И да, логи в одном месте — docker logs gbox — вместо того чтобы искать их по полдюжине файлов в /var/log.

Когда Docker НЕ нужен: один ресивер, embedded-образы

Если у вас Enigma2-ресивер на базе OpenATV или Dreambox — Docker там просто не запустится на стандартном ядре. Embedded-образы вроде Oscam-emu уже собраны под конкретное железо. Docker имеет смысл на отдельном Linux-сервере: Raspberry Pi 4, мини-ПК с Debian или виртуалке в облаке.

Подготовка хоста и структура каталогов

Установка Docker и docker-compose на Debian/Ubuntu

На свежем Debian 12 или Ubuntu 22.04 это две команды:

apt update && apt install -y docker.io docker-compose
systemctl enable --now docker

Добавьте своего пользователя в группу docker, чтобы не работать под root: usermod -aG docker $USER. После этого нужно перелогиниться. Проверить установку: docker run --rm hello-world.

На Raspberry Pi 4 с Raspberry Pi OS (64-bit) та же процедура работает без изменений. На 32-bit образе (armv7) придётся учитывать архитектуру при выборе бинарника GBox — к этому вернёмся в разделе про Dockerfile.

Структура каталогов для конфигов: /opt/gbox/config

Конфиги живут на хосте, контейнер их только читает. Это принципиально: пересобрать образ не значит потерять настройки.

mkdir -p /opt/gbox/config
mkdir -p /opt/gbox/tmp
touch /opt/gbox/config/gbox.cfg
touch /opt/gbox/config/share.cfg

Права на файлы конфигурации:

chmod 644 /opt/gbox/config/gbox.cfg
chmod 644 /opt/gbox/config/share.cfg

Если в конфигах хранятся строки подключения с паролями (а они там будут) — ставьте 600 и меняйте владельца на uid контейнера. По умолчанию GBox внутри контейнера часто работает под root, тогда 644 достаточно, но это не лучшая практика для продакшена.

Проверка наличия DVB-устройств /dev/dvb

Если хост подключён к DVB-карте или USB-тюнеру:

ls -la /dev/dvb/adapter0

Типичный вывод показывает файлы demux0, dvr0, frontend0. Если адаптеров несколько — будут adapter0, adapter1 и т.д. Запомните эти пути: их придётся явно пробрасывать в контейнер. Если DVB-устройств нет (GBox работает чисто как сетевой ретранслятор без локальной карты) — этот раздел можно пропустить.

Сборка Docker-образа и Dockerfile для GBox

Базовый образ и установка зависимостей (libc, libssl)

Берём debian:stable-slim как базу — минимальный размер, стабильная libc, без лишнего мусора. GBox обычно требует libssl и стандартные libc6. На некоторых версиях бинарника нужен ещё libpthread, но он входит в libc6 начиная с glibc 2.34.

apt-get install -y --no-install-recommends \
  libssl3 \
  ca-certificates \
  libgcc-s1

Alpine Linux как базу я бы не рекомендовал: там musl libc, а большинство бинарников GBox слинкованы под glibc. Получите то же самое «exec format error», только по другой причине.

Пример Dockerfile с копированием бинарника GBox

FROM debian:stable-slim

RUN apt-get update && apt-get install -y --no-install-recommends \
    libssl3 \
    ca-certificates \
    libgcc-s1 \
  && rm -rf /var/lib/apt/lists/*

COPY gbox /usr/bin/gbox
RUN chmod +x /usr/bin/gbox

VOLUME ["/config"]
WORKDIR /config

ENTRYPOINT ["/usr/bin/gbox"]

Бинарник gbox кладётся рядом с Dockerfile перед сборкой. Альтернатива — монтировать бинарник снаружи через volume, но тогда теряется смысл образа: непонятно, что именно запущено. Лучше зафиксировать конкретную версию бинарника внутри образа и тегировать образ соответственно (gbox:2.3.4-x86_64).

Сборка образа: docker build -t gbox:local .

docker build -t gbox:local .

Перед сборкой убедитесь, что бинарник соответствует архитектуре хоста:

uname -m          # хост
file ./gbox       # бинарник

Если хост выдаёт x86_64, а file говорит ELF 32-bit ARM — это гарантированный exec format error при запуске. На Raspberry Pi 4 с 64-bit OS нужен aarch64-бинарник, с 32-bit — armv7l. Перепутать легко, особенно когда бинарники лежат без подписей в архиве.

Запуск контейнера: docker-compose, порты и устройства

Проброс UDP-порта GBox и режим сети host vs bridge

GBox использует UDP — и это меняет всё. В bridge-режиме Docker создаёт внутреннюю сеть с NAT, и UDP-пакеты от внешних пиров просто не доходят до контейнера без явного проброса. Плюс GBox иногда использует широковещательные пакеты внутри локальной сети, которые bridge вообще не пропускает.

Поэтому для GBox рекомендуется network_mode: host. Контейнер использует сетевой стек хоста напрямую, UDP-порт 8004 слушается на всех интерфейсах хоста без дополнительных настроек.

Bridge возможен, но требует:

ports:
  - "8004:8004/udp"

И всё равно могут быть проблемы с обнаружением пиров в локальной сети. Если GBox работает только с внешними пирами по IP — bridge с пробросом порта вполне рабочий вариант.

Монтирование конфигов через volumes

Конфиги монтируются из /opt/gbox/config на хосте в /config внутри контейнера. GBox запускается из рабочей директории /config и ищет файлы там. Логи и временные файлы лучше вынести в отдельный volume:

volumes:
  - /opt/gbox/config:/config
  - /opt/gbox/tmp:/tmp/gbox

Доступ к /dev/dvb через --device или privileged

Privileged-режим (privileged: true) даёт контейнеру доступ ко всем устройствам хоста. Это работает, но это плохая практика — контейнер получает слишком много прав. Лучше пробрасывать устройства явно:

devices:
  - /dev/dvb/adapter0:/dev/dvb/adapter0

Если адаптеров два:

devices:
  - /dev/dvb/adapter0:/dev/dvb/adapter0
  - /dev/dvb/adapter1:/dev/dvb/adapter1

Важный момент: устройства /dev/dvb обычно принадлежат группе video (gid 44). Если GBox внутри контейнера работает не под root — добавьте group_add: ["video"] в docker-compose или явно укажите gid.

Пример docker-compose.yml

version: "3.8"

services:
  gbox:
    image: gbox:local
    container_name: gbox
    network_mode: host
    restart: unless-stopped
    volumes:
      - /opt/gbox/config:/config
      - /opt/gbox/tmp:/tmp/gbox
    devices:
      - /dev/dvb/adapter0:/dev/dvb/adapter0
    environment:
      - TZ=Europe/Moscow

Переменная TZ здесь не декоративная: если часовой пояс контейнера не совпадает с хостом, временны́е метки в логах GBox расходятся с системными логами, и диагностика превращается в квест. Укажите свой timezone явно.

Запуск и проверка:

docker-compose up -d
docker logs -f gbox

Конфигурация GBox: gbox.cfg и строки обмена

Основные параметры gbox.cfg: пароль, порт, hostname

Файл gbox.cfg — это основной конфиг. Структура простая, но несколько параметров критичны:

# Локальный UDP-порт GBox
M: { 08004 }

# Пароль локальной ноды (hex, 4 байта)
C: { 01 23 45 67 }

# Публичный hostname или IP (или DDNS)
H: { myhost.dyndns.org }

# Директория для временных файлов
T: { /tmp/gbox }

Пароль задаётся в hex-формате и должен совпадать с тем, что указан у пира с вашей стороны. Hostname используется для самоидентификации при обмене — если у вас динамический IP без DDNS, пиры потеряют связь после каждой смены адреса. Это не проблема Docker, это проблема архитектуры GBox: он идентифицирует узлы по hostname/IP + пароль.

Описание формата строки пира (peer) без привязки к провайдеру

Строки пиров хранятся либо в gbox.cfg, либо в отдельном share.cfg (зависит от версии). Общий формат записи пира:

D: { peer.hostname.example 08004 01 23 45 67 }

Где: hostname или IP пира, UDP-порт пира, пароль пира в hex (4 байта). Некоторые версии GBox используют расширенный формат с ID-карты или дополнительными флагами — сверяйтесь с документацией к конкретному бинарнику.

При выборе источника обмена ориентируйтесь на несколько критериев: стабильность соединения (ping до пира не должен зашкаливать за 100–150 мс для нормальной работы), надёжность DDNS (если пир за динамическим IP — DDNS обновляется ли вовремя), и взаимность обмена — GBox строится на принципе взаимного шаринга.

Связка GBox с OScam через протокол-мост

Самый распространённый вариант — GBox как reader в OScam. В /etc/oscam/oscam.server добавляете:

[reader]
label     = gbox_reader
protocol  = gbox
device    = /var/run/gbox.socket
# или через TCP-мост на loopback:
# protocol = camd35
# device   = 127.0.0.1:8005

Конкретный способ сопряжения зависит от версии GBox и OScam. Если оба работают в Docker — проще всего вывести их в одну docker network и использовать имена сервисов как hostname. Но если используете network_mode: host для GBox, то OScam обращается к нему через 127.0.0.1 хоста напрямую.

Диагностика и типичные ошибки запуска

Контейнер стартует и сразу падает: чтение логов

Первое, что нужно сделать:

docker logs gbox

Если контейнер умирает мгновенно и логов нет — проблема в ENTRYPOINT или бинарнике. Запустите контейнер с переопределённым точкой входа:

docker run -it --entrypoint /bin/sh gbox:local

Внутри проверьте:

ls -la /usr/bin/gbox    # файл существует?
/usr/bin/gbox           # что происходит при запуске?
ldd /usr/bin/gbox       # все библиотеки нашлись?

Если ldd показывает not found рядом с библиотекой — нужно доустановить её в Dockerfile. Часто это libssl или libcrypto старой версии.

exec format error и несовпадение архитектуры

Это самая распространённая ошибка при gbox Docker контейнер: настройка на ARM-железе. Сообщение выглядит так:

exec /usr/bin/gbox: exec format error

Решение: проверить архитектуру хоста и бинарника:

uname -m          # например: aarch64
file /usr/bin/gbox  # должно совпадать с хостом

На Raspberry Pi 4 с 64-bit OS нужен бинарник aarch64. На TV-box с 32-bit Android-ядром под Debian — armv7l. На x86_64 сервере — x86_64. Бинарники разных архитектур выглядят одинаково в файловом менеджере и отличаются только через file или readelf -h.

GBox не видит пиров: firewall и NAT для UDP

Контейнер запущен, GBox работает, но пиры не подключаются. Первым делом — firewall на хосте:

# UFW
ufw allow 8004/udp

# iptables напрямую
iptables -A INPUT -p udp --dport 8004 -j ACCEPT

Если хост за роутером — нужен проброс UDP-порта 8004 на роутере. GBox за двойным NAT (например, провайдерский роутер + домашний) — это боль: нужен проброс на обоих уровнях, иначе входящие UDP-пакеты не доберутся до хоста. В такой ситуации единственное нормальное решение — VPN-туннель до сервера с белым IP.

Проверить, приходят ли пакеты вообще:

tcpdump -i any udp port 8004 -n

Если пакеты видны в tcpdump, но GBox их не обрабатывает — проблема в конфиге или в том, что порт уже занят другим процессом (ss -ulnp | grep 8004).

Конфликт портов — отдельная история. Если на хосте уже запущен GBox или OScam, слушающий тот же UDP-порт, и вы запускаете контейнер с network_mode: host — получите ошибку bind. Проверьте перед запуском: ss -ulnp | grep 8004.

Нет доступа к DVB: права на устройство

GBox внутри контейнера пишет в лог что-то вроде cannot open /dev/dvb/adapter0/demux0: Permission denied. Первое — убедиться, что устройство пробрасывается через devices в docker-compose, а не только через --privileged. Второе — проверить группу устройства на хосте:

ls -la /dev/dvb/adapter0/
# crw-rw---- 1 root video 212, 4 Jun 23 10:15 demux0

Группа video, gid обычно 44. Добавьте в docker-compose:

group_add:
  - "44"

Или запустите GBox внутри контейнера под root (по умолчанию так и есть в большинстве образов). Privileged-режим как костыль тоже работает, но лучше понять реальную причину и использовать точечный проброс устройств.

Чеклист при диагностике:

• Бинарник соответствует архитектуре хоста (file gbox)
• Все библиотеки найдены (ldd /usr/bin/gbox)
• UDP-порт открыт в firewall и на роутере
• Порт не занят другим процессом на хосте
• DVB-устройства пробрасываются через devices
• Часовой пояс контейнера совпадает с хостом (TZ=)
• DDNS обновляется и резолвится корректно

Gbox Docker контейнер: настройка — это не разовая операция, а итеративный процесс. Первый запуск почти никогда не бывает без ошибок, и это нормально. Главное — читать логи внимательно и не лезть в privileged-режим как первое решение.