Настройка newcamd в Docker: гайд 2026

Если вы читаете это, значит уже знаете, чего хотите: поднять newcamd-сервер или клиент внутри контейнера, и что-то пошло не так. Может, порт не пробрасывается. Может, ридер висит в CONNECTED, а каналы не открываются. Именно под это и заточен материал — newcamd Docker контейнер: настройка с нуля до рабочего состояния, без воды и маркетинга.

Всё примеры ниже — на OScam, потому что именно он сейчас остаётся де-факто стандартом для newcamd как в серверном, так и в клиентском варианте.

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

Newcamd — TCP-протокол card sharing. Работает поверх обычного TCP-соединения, шифрует сессию 14-байтным DES-ключом (он же записывается как 28 hex-символов). По умолчанию никакого жёстко зашитого порта нет — конфигурируется вручную, но по традиции большинство серверов слушают что-то из диапазона 28000–28010.

В OScam newcamd реализован с обеих сторон: секция [newcamd] в oscam.conf делает из него сервер, а блок [reader] с protocol = newcamd в oscam.server — клиент, который цепляется к удалённому серверу.

Протокол newcamd: порт по умолчанию и DES-ключ

DES-ключ — это не пароль в обычном смысле. Он используется для шифрования всей сессии на транспортном уровне. Длина строго фиксированная: 14 байт, 28 hex-символов. Укоротить или удлинить нельзя. Если ключи на сервере и клиенте не совпадают, соединение технически устанавливается, но данные расшифровываются в мусор — ECM-запросы проходят, ответы не разбираются.

Порт задаётся в формате ПОРТ@CAID:IDENT. Например, 28000@0500:000000 означает: слушать на порту 28000, обслуживать CAID 0x0500 (Viaccess), идентификатор провайдера 0x000000. Можно указать несколько строк для разных CAID.

Почему OScam в контейнере — удобный способ держать newcamd-сервер

Главное удобство — воспроизводимость. Зафиксировал тег образа, и через полгода поднимаешь ровно ту же версию OScam на новом железе за три команды. Никаких проблем с зависимостями libc, конфликтующими пакетами или системными библиотеками.

Плюс изоляция: процесс OScam не видит остальную систему. Если что-то сломается — удаляешь контейнер, пересоздаёшь. Конфиги при этом живут на хосте в смонтированном томе и никуда не деваются.

Когда контейнеризация оправдана, а когда лишняя

Docker здесь избыточен в одном сценарии: если у вас локальная DVB-карта и вы хотите использовать её как internal-ридер. В bridge-режиме устройство /dev/dvb/adapter0 недоступно без явного проброса через --device, а с host-режимом теряется изоляция. Если вся работа — проксировать newcamd-линии от удалённых серверов клиентам, Docker отлично подходит.

Подготовка образа и структуры конфигов

Первое, что нужно решить до запуска контейнера — куда ляжет конфигурация и под каким UID будет работать процесс OScam внутри.

Выбор образа OScam с поддержкой newcamd

На Docker Hub есть несколько неофициальных образов OScam. Смотрите на то, собран ли бинарник с флагом --enable-protocol-newcamd — без него секция [newcamd] в конфиге просто игнорируется без каких-либо ошибок, что очень удобно для трёхчасовой отладки несуществующей проблемы.

Проверить можно так:

docker run --rm your-oscam-image oscam --build-info | grep -i newcamd

Если строка есть — всё нормально. Если нет — нужен другой образ или самосборка.

Том для конфигов: /var/keys или /config

Путь зависит от образа. Большинство популярных сборок монтируют конфиги в /var/keys или /config. Проверьте ENTRYPOINT в Dockerfile или документацию образа. Пример монтирования:

-v /opt/oscam/config:/var/keys

Главное правило: конфиги всегда на хосте. Никогда не храните их только внутри слоя образа — при docker pull новой версии всё потеряете.

Проверьте UID. Если OScam внутри запускается от пользователя с UID 1000, а файлы на хосте принадлежат root, он не сможет писать oscam.log — будете отлаживать вслепую. Исправляется через chown 1000:1000 /opt/oscam/config на хосте или через параметр --user при запуске контейнера.

Минимальный набор файлов: oscam.conf, oscam.server, oscam.user

Для работы newcamd-сервера нужны три файла:

• oscam.conf — глобальные настройки и секции [global], [newcamd], [webif]
• oscam.server — ридеры (если OScam выступает клиентом к другому серверу)
• oscam.user — учётные записи клиентов, которые подключаются к вашему серверу

Файл oscam.dvbapi нужен только если используется локальная карта. oscam.services — опционально, для фильтрации каналов по сервисам.

Конфигурация newcamd-сервера в OScam

Вот где большинство руководств дают конфиг, но не объясняют синтаксис. Разберём по частям.

Секция [newcamd]: key, port, allowed

В файле /var/keys/oscam.conf (путь внутри контейнера) добавляете:

[newcamd]
key        = 0102030405060708091011121314
port       = 28000@0500:000000
allowed    = 192.168.1.0/24,10.0.0.0/8
keepalive  = 1

Параметр key — это и есть тот самый 14-байтный DES-ключ, записанный как 28 hex-символов. Пример выше — учебный, в продакшне ставьте что-то менее очевидное. allowed ограничивает, каким подсетям разрешено подключение на уровне протокола — хорошая практика.

Привязка CAID к порту в параметре port

Синтаксис ПОРТ@CAID:IDENT позволяет жёстко привязать порт к конкретной системе условного доступа. Если хотите несколько CAID на разных портах:

port = 28000@0500:000000|28001@0604:000000|28002@1800:000000

Это одна строка. Три порта: 28000 для Viaccess (0500), 28001 для Irdeto (0604), 28002 для Nagravision (1800). Все три порта потом надо пробросить в Docker — ниже разберём как.

Если написать просто port = 28000 без CAID, сервер будет отвечать на запросы по всем доступным системам. Это удобнее в начале, но менее контролируемо.

Создание учётной записи клиента в oscam.user

Файл /var/keys/oscam.user:

[account]
user       = testclient
pwd        = secretpass
group      = 1
au         = 1
monlevel   = 0

Клиент подключается с этим логином и паролем. Параметр group должен совпадать с группой ридера, который отдаёт карту — иначе декодирования не будет, хотя соединение будет выглядеть нормально. Это одна из самых частых причин «CONNECTED без декода».

Проброс портов и сетевые режимы Docker

Именно здесь кроется большинство проблем при newcamd Docker контейнер: настройка в реальных условиях. Docker networking — не очевидная тема.

Режим bridge с -p 28000:28000

По умолчанию контейнер работает в bridge-режиме. Порты снаружи не видны, пока их явно не опубликовать:

docker run -d \
  --name oscam \
  -p 28000:28000 \
  -v /opt/oscam/config:/var/keys \
  your-oscam-image

Если newcamd слушает на нескольких портах — пробрасывать каждый отдельно:

-p 28000:28000 -p 28001:28001 -p 28002:28002

Или диапазоном, если порты последовательные:

-p 28000-28002:28000-28002

Важно: убедитесь, что на хосте эти порты не заняты другим процессом. Проверить: ss -tlnp | grep 280. Если порт занят, Docker молча не сообщит об ошибке при docker run — только при попытке подключения клиент получит отказ.

Когда нужен network_mode: host

С network_mode: host контейнер использует сетевой стек хоста напрямую. Никаких NAT, никакого проброса — OScam слушает на 28000, и снаружи это видно напрямую.

Удобно в двух случаях: много портов (10+ newcamd-линий под разные CAID) или нужна работа с локальными DVB-устройствами и multicast. Минус — теряете изоляцию сети и риск конфликтов портов становится выше.

Несколько newcamd-портов под разные CAID

Эквивалент в docker-compose.yml:

version: "3.8"
services:
  oscam:
    image: your-oscam-image
    container_name: oscam
    volumes:
      - /opt/oscam/config:/var/keys
    ports:
      - "28000:28000"
      - "28001:28001"
      - "28002:28002"
    restart: unless-stopped

Или с host-сетью:

version: "3.8"
services:
  oscam:
    image: your-oscam-image
    container_name: oscam
    network_mode: host
    volumes:
      - /opt/oscam/config:/var/keys
    restart: unless-stopped

С network_mode: host секцию ports убираете полностью — она игнорируется в этом режиме.

Подключение newcamd-клиента (ридера)

Если ваш контейнер выступает клиентом — подключается к удалённому newcamd-серверу — конфиг ридера идёт в /var/keys/oscam.server.

Блок [reader] с protocol = newcamd

[reader]
label      = my_newcamd_server
protocol   = newcamd
device     = 192.168.1.100,28000
key        = 0102030405060708091011121314
user       = testclient
password   = secretpass
caid       = 0500
group      = 1
reconnecttimeout = 15

Параметр device — это адрес сервера и порт через запятую. Можно использовать hostname, но DNS-резолвинг внутри контейнера должен работать — проверьте, что /etc/resolv.conf в контейнере указывает на рабочий резолвер.

Параметры device, key, user, password

key должен быть ровно тем же 28-символьным hex, что прописан в секции [newcamd] на сервере. Ни больше, ни меньше. user и password совпадают с блоком [account] в oscam.user сервера.

Параметр caid в ридере — подсказка OScam, для каких систем пробовать этот ридер. Если сервер отдаёт несколько CAID, можно перечислить через запятую: caid = 0500,0604.

Проверка статуса ридера в веб-интерфейсе OScam

Включите webif в oscam.conf:

[webif]
httpport   = 8888
httpuser   = admin
httppwd    = adminpass

Пробросьте порт 8888 при запуске контейнера и откройте http://хост:8888. В разделе Readers смотрите статус: CONNECTED — TCP-соединение есть, CARD — карта определена и отдаёт ECM-ответы, UNAVAILABLE — нет соединения вообще.

Статус CONNECTED без CARD — это логическая проблема, не сетевая. Соединение есть, но что-то мешает получить ответ на ECM-запросы. Смотреть надо в oscam.log.

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

Большинство проблем при newcamd Docker контейнер: настройка делятся на два класса: сетевые (клиент вообще не может достучаться до порта) и логические (соединение есть, но декодирования нет). Их диагностика принципиально разная.

Ридер CONNECTED, но нет декодирования

Это логическая проблема. Чек-лист:

• Проверить group в oscam.user и oscam.server — они должны совпадать
• Убедиться, что CAID/ident в запросе совпадает с тем, что прописано на сервере
• Проверить, что у аккаунта в oscam.user нет ограничений по сервисам (services / ident)
• Повысить уровень отладки и читать лог: loghistorysize = 4000 и debug = 64 в секции [global]

В логах ищите строки с ECM — там будет видно, получает ли сервер запрос и что отвечает.

Ошибка несовпадения DES-ключа

При несовпадении ключа OScam обычно показывает ошибку вроде invalid DES key length или соединение устанавливается, но сразу разрывается. В лог-файле будет строка с decrypt error или handshake failed.

Частая причина: где-то скопировали ключ с пробелом в начале или конце, или вставили 26 символов вместо 28. Всегда считайте длину перед сохранением.

Контейнер не слушает порт: проверка через ss/netstat

Сначала убедитесь, что OScam внутри контейнера вообще слушает нужный порт:

docker exec oscam ss -tlnp

Или через netstat, если ss недоступен:

docker exec oscam netstat -tlnp 2>/dev/null | grep 28000

Если порт не слушается изнутри — проблема в конфиге OScam, а не в Docker. Если слушается, но снаружи недоступен — проблема в проброске или firewall хоста.

Проверка firewall:

iptables -L DOCKER -n -v | grep 28000

Docker обычно сам добавляет правила в цепочку DOCKER, но некоторые дистрибутивы с агрессивными политиками по умолчанию могут блокировать трафик до того, как он туда доходит. Проверьте также цепочку INPUT.

Логи OScam: debug-уровни и фильтры

В секции [global] файла oscam.conf:

[global]
logfile        = /var/keys/oscam.log
loghistorysize = 4000
debug          = 64

Значение debug = 64 включает подробный лог newcamd-протокола. Значение 255 — максимум, но это очень много текста. Для диагностики конкретного ридера удобнее использовать веб-интерфейс: раздел Logs с фильтром по имени ридера.

И ещё один момент, который часто упускают: часовой пояс внутри контейнера. Если контейнер живёт в UTC, а хост в Europe/Moscow, метки времени в oscam.log будут на 3 часа позади системного времени. Это не критично, но сбивает с толку при сопоставлении событий с другими логами. Исправляется переменной окружения: -e TZ=Europe/Moscow при запуске.

Итого: полная схема newcamd Docker контейнер: настройка сводится к правильно подобранному образу, конфигам на хосте через том, явному проброску всех newcamd-портов и пониманию разницы между сетевой и логической ошибкой.