Wicardd в Docker: настройка контейнера CCcam-сервера

Если вы раньше гоняли Wicardd прямо на железе или в OpenWrt, то переход на Docker поначалу кажется излишним усложнением. На деле всё наоборот — контейнер решает кучу проблем с зависимостями и воспроизводимостью. Эта статья про Wicardd Docker контейнер: настройка с нуля — Dockerfile, монтирование конфигов, проброс портов и разбор типичных ошибок.

Официального Docker-образа для Wicardd нет. Придётся собирать самостоятельно, но это проще, чем кажется — особенно если вы уже знаете, как работает демон на голом металле.

Зачем запускать Wicardd именно в Docker

Главный аргумент — переносимость. Один раз собрал образ, и его можно запустить на любом VPS или домашнем сервере без танцев с зависимостями. Переехать с одного хоста на другой — это просто docker save и docker load, плюс копирование папки с конфигами.

Изоляция демона и зависимостей от хост-системы

Wicardd тянет за собой libpcsclite и иногда pcscd — и это может конфликтовать с другими сервисами на хосте. В контейнере всё это живёт изолированно. Хост-система остаётся чистой, а сам Wicardd получает ровно те версии библиотек, под которые он собран.

Откат тоже тривиален. Сломал конфиг? docker restart вернёт тебя к последнему рабочему состоянию за секунды. На bare-metal такого удобства нет.

Воспроизводимость: один Dockerfile вместо ручной сборки

Вместо инструкции на пять страниц «сначала apt install, потом скачай бинарник, потом пропиши в systemd» — один Dockerfile. Любой человек в команде (или вы сами через полгода) поднимает идентичное окружение одной командой. Это реально удобно.

Portainer сверху делает управление ещё проще — можно перезапустить контейнер через браузер, не заходя по SSH.

Ограничения: проброс USB-ридеров и доступ к /dev

Честно: с физической смарт-картой через USB контейнер усложняет жизнь, а не упрощает. Docker не видит устройства автоматически — нужны флаги --device или --privileged, и udev-правила на хосте должны быть настроены.

Если вы работаете как сетевой шаринг-сервер (newcamd или cs378x клиент к внешнему источнику), эта проблема вас вообще не касается. Для сетевых ридеров Docker — чистое решение без оговорок.

Минимальные требования: Docker 20.10 и выше, архитектура amd64 или arm64 (armv7 тоже работает, но бинарник должен совпадать).

Сборка Docker-образа Wicardd: Dockerfile

Официального образа нет — собираем сами. Базой берём debian:stable-slim: минимальный размер, знакомая экосистема, нет неожиданностей с glibc. Alpine соблазнителен по размеру, но musl-libc часто ломает бинарники, собранные под glibc — не стоит экономить эти 30 МБ.

Базовый образ debian:stable-slim и нужные пакеты

Из пакетов нужны libpcsclite1, libusb-1.0-0 и pcscd если планируете локальный ридер. Для сетевого режима достаточно libpcsclite1. Добавьте ca-certificates — пригодится если Wicardd обращается куда-то по HTTPS для обновлений.

Загрузка и размещение бинарника wicardd

Бинарник кладём в /usr/bin/wicardd и выставляем chmod 755. Обязательно проверьте архитектуру: file wicardd должен показать ELF 64-bit LSB или ARM, совпадающий с архитектурой вашего хоста. Несовпадение даёт exec format error при старте — и контейнер падает без внятного объяснения.

Структура каталогов /etc/wicardd и /var/log

Создаём /etc/wicardd/ для конфигов и /var/log/wicardd/ на случай если всё же захотите логи в файл. Но в Docker лучше stdout — об этом подробнее ниже.

Пример рабочего Dockerfile с ENTRYPOINT

Главный момент, который все упускают: Wicardd по умолчанию демонизируется, уходит в фон, и Docker убивает контейнер, потому что PID 1 завершился. Нужен запуск на переднем плане.

FROM debian:stable-slim

RUN apt-get update && apt-get install -y \
    libpcsclite1 \
    libusb-1.0-0 \
    pcscd \
    ca-certificates \
    && rm -rf /var/lib/apt/lists/*

RUN mkdir -p /etc/wicardd /var/log/wicardd

COPY wicardd /usr/bin/wicardd
RUN chmod 755 /usr/bin/wicardd

EXPOSE 10000 12000 8888

ENTRYPOINT ["/usr/bin/wicardd", "-c", "/etc/wicardd/wicardd.conf", "-nodaemon"]

Флаг -nodaemon — это и есть ключевой момент. Без него контейнер стартует, Wicardd форкается в фон, PID 1 завершается, статус Exited(0). Выглядит как нормальное завершение, но на деле демон никогда не запустился нормально.

Если у вашей версии Wicardd другой флаг для foreground-режима — проверьте wicardd --help. Иногда это -f или -foreground.

Монтирование конфигов и запуск контейнера

Конфиг не должен лежать внутри образа. Если зашить wicardd.conf в образ, каждое изменение настроек потребует пересборки — это неудобно и медленно. Монтируем папку с хоста.

Том для wicardd.conf и файлов карт

На хосте создаём папку, например /opt/wicardd/, кладём туда wicardd.conf и монтируем внутрь контейнера как /etc/wicardd. Файлы карт и дополнительные конфиги — туда же.

Проброс портов: newcamd, CCcam, cs378x, HTTP-статус

Типичные порты для Wicardd:

• newcamd: диапазон 10000–15000/tcp, конкретный порт задаётся в wicardd.conf
• CCcam: 12000/tcp
• cs378x: обычно 10002/tcp
• HTTP веб-статус: 8888/tcp по умолчанию

Пробрасывайте только то, что реально используете. Открытые неиспользуемые порты — лишняя поверхность атаки.

Команда docker run и эквивалент в docker-compose

Базовый запуск командой:

docker run -d \
  --name wicardd \
  -v /opt/wicardd:/etc/wicardd \
  -p 10000:10000 \
  -p 12000:12000 \
  -p 8888:8888 \
  --restart unless-stopped \
  wicardd:latest

Эквивалент в docker-compose.yml, который я рекомендую для постоянного использования:

version: "3.8"

services:
  wicardd:
    image: wicardd:latest
    container_name: wicardd
    restart: unless-stopped
    volumes:
      - /opt/wicardd:/etc/wicardd
      - /var/log/wicardd:/var/log/wicardd
    ports:
      - "10000:10000"
      - "12000:12000"
      - "8888:8888"
    environment:
      - TZ=Europe/Moscow

Переменная TZ критична для диагностики. Если часовой пояс контейнера не совпадает с хостом, метки времени в логах будут сбивать с толку — ECM-тайминги и временные штампы разъедутся, и вы потратите час на поиск несуществующей проблемы.

Если у вас несколько newcamd-инстансов на разных портах (скажем, 10000–10005), пробрасывать каждый порт отдельной строкой неудобно. В этом случае используйте network_mode: host — контейнер разделит сетевой стек с хостом и все порты будут доступны автоматически.

services:
  wicardd:
    image: wicardd:latest
    container_name: wicardd
    restart: unless-stopped
    network_mode: host
    volumes:
      - /opt/wicardd:/etc/wicardd

Но network_mode: host убирает сетевую изоляцию контейнера. Для домашнего сервера это приемлемо, для VPS с несколькими сервисами — подумайте дважды.

Доступ к веб-интерфейсу мониторинга

После запуска веб-статус доступен на http://<хост>:8888. Если порт 8888 уже занят другим контейнером (Portainer, например, иногда его берёт), меняйте маппинг: -p 8889:8888. Внутренний порт в конфиге не трогаете, меняете только внешний.

Структура wicardd.conf для работы в контейнере

Конфиг для Docker отличается от bare-metal в нескольких ключевых точках. Разберём по секциям.

Секции [ACCOUNT] и [SERVER] для входящих клиентов

Минимальный пример секции аккаунта для newcamd-клиента:

[ACCOUNT]
user = myuser
password = mypassword
caid = 0x0500,0x1810

DES-ключ для newcamd — 14 байт, задаётся в hex. Убедитесь, что ключ на сервере и у клиента совпадает точно — это самая частая причина отказа соединения после правильного проброса портов.

Настройка newcamd-сервера и портов прослушивания

Критичный момент для контейнера: bind-адрес должен быть 0.0.0.0, а не 127.0.0.1.

[SERVER]
port = 10000
bind = 0.0.0.0
key = 0102030405060708091011121314
protocol = newcamd

Если указать bind = 127.0.0.1, демон будет слушать только внутри контейнера. Docker пробросит порт, соединение дойдёт до контейнера, но Wicardd его отклонит — и вы будете час смотреть на открытый порт, который ничего не принимает.

Подключение к внешним источникам (клиентские секции)

Когда Wicardd выступает как клиент к внешнему источнику карт, добавляете соответствующую секцию с адресом, портом, логином и паролем внешнего сервера. При выборе источника смотрите на стабильность аптайма (провалы больше 30 секунд рвут клиентские сессии), корректные ECM-тайминги для ваших CAID, и поддержку нужных протоколов — не все источники одинаково хорошо работают с newcamd против cs378x.

Логирование в stdout вместо файла

В конфиге Wicardd есть параметры для логирования. В Docker правильно направлять вывод в stdout/stderr — тогда docker logs работает как положено:

[LOG]
level = info
target = stdout

Конкретные имена директив зависят от версии Wicardd — в некоторых сборках это logfile = /dev/stdout. Проверьте документацию вашей версии. Логирование в файл внутри контейнера — плохая идея: при пересоздании контейнера логи исчезнут вместе с ним (если не смонтирован отдельный том для логов).

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

Большинство проблем при Wicardd Docker контейнер: настройка сводятся к трём вещам: неправильный режим запуска, неверный bind-адрес, или несовпадение DES-ключа. Разберём по симптомам.

Контейнер стартует и сразу падает (Exited 0)

Статус Exited(0) — это демонизация. Wicardd форкнулся в фон, PID 1 завершился, Docker решил что работа сделана. Решение: добавить -nodaemon в ENTRYPOINT или CMD.

Если контейнер падает с Exited(1) — проблема в конфиге или бинарнике. Смотрите docker logs имя_контейнера сразу после падения. Самая частая причина Exited(1) после добавления -nodaemon — отсутствующий или битый wicardd.conf по указанному пути.

И не забывайте про архитектуру. exec format error означает, что бинарник собран под другую платформу. Проверяйте: docker exec имя_контейнера uname -m и file /usr/bin/wicardd.

Порт слушается, но клиенты не подключаются

Последовательность проверок:

1. Проверьте что порт вообще слушается внутри контейнера: docker exec wicardd ss -tlnp
2. Проверьте доступность снаружи: nmap -p 10000 <адрес_хоста>
3. Проверьте bind-адрес в конфиге — должен быть 0.0.0.0
4. Проверьте firewall на хосте: iptables -L -n или ufw status

Отдельная история — работа за NAT. Если хост находится за двойным NAT (провайдерский NAT плюс домашний роутер), клиенты из интернета не доберутся до порта без явного port forwarding на роутере. В некоторых случаях единственное решение — реверс-туннель через публичный VPS. Также некоторые VPS-провайдеры блокируют нестандартные входящие порты — попробуйте перевесить newcamd на порт 443 или 80 как обходной вариант.

Проброс USB-ридера: --device и udev-правила

Для PC/SC ридера (типа ACS ACR38):

docker run -d \
  --name wicardd \
  --device=/dev/bus/usb \
  -v /opt/wicardd:/etc/wicardd \
  -p 10000:10000 \
  wicardd:latest

Для серийного ридера на /dev/ttyUSB0:

--device=/dev/ttyUSB0:/dev/ttyUSB0

--privileged как последний вариант — работает, но контейнер получает доступ ко всем устройствам хоста. Лучше явно указывать конкретный девайс. Если устройство не определяется внутри контейнера — проверьте udev-правила на хосте и убедитесь что пользователь, под которым запущен Docker, имеет доступ к /dev/bus/usb.

Для PC/SC может потребоваться запущенный pcscd внутри контейнера. В таком случае ENTRYPOINT заменяется на shell-скрипт, который сначала стартует pcscd, потом запускает Wicardd.

Чтение логов через docker logs и уровни отладки

Базовый просмотр: docker logs -f wicardd. Флаг -f даёт поток в реальном времени — удобно при диагностике подключений клиентов.

Для детальной диагностики ECM поднимите уровень логирования в конфиге до debug и перезапустите контейнер (docker restart wicardd). В debug-режиме Wicardd пишет каждый ECM-запрос с временными метками — видно где зависает декрипт. После диагностики верните info, иначе логи растут со скоростью нескольких МБ в минуту.

Полный процесс Wicardd Docker контейнер: настройка и отладки занимает час-полтора при первом запуске, и пять минут при переносе на новый хост — в этом весь смысл контейнеризации.