Перейти к содержанию

Mos.Hub как вторичное зеркало для Entware/IPK: что подтверждено, а что нет

Статус: Confirmed (платформенные факты Mos.Hub — анонимные публичные проверки 2026-09-24; модель дистрибуции entware-go — по коду репозитория) + Research (сценарии, требующие реального пилота: автоматизация, квоты, поведение под нагрузкой)
Область применения: решение «нужен ли второй канал раздачи .ipk помимо GitHub latest release» для saymer-alt/entware-go и его потребителей (keenetic-auto-setup и др.)
Проверено на: hub.mos.ru — анонимные GET-запросы (web + GitLab API v4), 2026-09-24; saymer-alt/entware-go @ gh-action-build (read-only)
Последняя проверка: 2026-09-24
Source of truth: живое поведение hub.mos.ru на дату проверки; код/workflow-ы entware-go; upstream-документация GitLab — только как «возможность GitLab» без переноса на Mos.Hub
Provenance: raw-исследования moshub.md (несколько последовательных AI-разведок с противоречивыми выводами) и moshubrd.md (сохранённый README реального проекта владельца на Mos.Hub)

Что решаем

Старое исследование moshub.md — компиляция нескольких AI-разведок с взаимно противоречивыми выводами (от «отличный fallback» до «не подходит»). Эта статья фиксирует, что из него подтверждается живыми публичными проверками, что осталось предположением «GitLab так умеет», и даёт решение по пилоту.

Вопрос поставлен узко: Mos.Hub рассматривается как вторичное зеркало/fallback артефактов, а не как замена GitHub.

Текущая архитектура владельца (Confirmed по коду entware-go)

saymer-alt/entware-go (рабочая ветка — gh-action-build, read-only проверка 2026-09-24):

  • пакетный фид — общий GitHub-релиз с тегом latest;
  • каждый workflow публикует только свои ассеты: mihomo_*.ipk (+mihomo_nohf_*), beszel-agent_*.ipk, warpscout_*.ipk — через gh release upload latest --clobber с последующим удалением старых версий своих файлов;
  • потребители скачивают .ipk прямым curl/wget по URL релизного ассета (установщики keenetic-auto-setup / warpscout); opkg install идёт уже с локального файла;
  • сам репозиторий не публикует Packages/Packages.gz — «классический opkg-фид» сегодня не используется.

Отсюда практические требования к зеркалу: анонимный HTTPS-GET .ipk по предсказуемому URL и предсказуемое хранение. OPKG-индекс — опциональная надстройка, не текущая потребность.

Confirmed on Mos.Hub (проверено анонимно, 2026-09-24)

Всё ниже — собственные публичные проверки (GET без авторизации, без логина):

  • Платформа жива и доступна: https://hub.mos.ru/ отвечает 200 (~1,5 с), фронт — nginx. Это инстанс GitLab с API v4: анонимно читаются /api/v4/projects, /api/v4/groups, поиск, теги; /api/v4/version требует авторизации (401) — как у стандартного GitLab.
  • Публичные проекты существуют в большом числе; анонимный листинг и поиск по проектам/группам работают (группы mos/pkgs, pkgstore, project-templates, auroraos, ditmos/… и др.).
  • Анонимная загрузка файла из репозитория работает: /-/raw/main/README.md публичного проекта → 200, text/plain, полное содержимое. Заголовки: Cache-Control: max-age=60, public; ответ выставляет session-cookie (на анонимный GET это не мешает curl/wget, но это сигнал о возможной защите от автоматизации — предмет пилота). Rate-limit-заголовков в ответе не наблюдалось.
  • Анонимная загрузка архива тега работает: /-/archive/<tag>/<repo>-<tag>.tar.gz → 200, бинарное содержимое. Т. е. анонимный бинарный GET по HTTPS — рабочий механизм платформы.
  • GitLab Pages на платформе есть и официально шаблонизирована: в экземплярной группе project-templates (id 204) лежат официальные шаблоны сайтов hugo, jekyll, plain-html, hexo, pelican, gatsby, bridgetown, middleman (+ локализованные варианты nfhugo, nfjekyll, nfplain-html, nfhexo, nfgitbook); .gitlab-ci.yml шаблона jekyll содержит канонический deploy-джобу pages: с artifacts: [public]. Этим опровергается часть старых выводов «Pages не подтверждены/нет». Фактический serving-хост/URL Pages без своего проекта не установлен.
  • Реальный проект владельца уже существует: публичный проект sayone/saymer (создан 2026-05-09) — нетронутый шаблонный README; его копия и есть moshubrd.md. Т. е. учётная запись/namespace для пилота уже есть.
  • Releases на практике не используются: среди ~40 просмотренных публичных проектов не найдено ни одного с релизами; эндпоинт /releases на публичных проектах отвечает 200 с пустым списком; у одного фактически приватного проекта —
  • Плюс: API проекта лишён полей visibility/releases_access_level/ packages_enabled/pages_access_level — инстанс кастомизирован и скрывает feature-флаги из анонимных ответов.

GitLab capability — Mos.Hub exposure not confirmed

Из этого класса в старом исследовании делались уверенные выводы «раз GitLab — значит работает». Публичных Mos.Hub-доказательств нет, переносить в практику нельзя:

  • Generic Package Registry: API PUT/GET /api/v4/projects/:id/packages/generic/:name/:version/:file — документировано для GitLab; на Mos.Hub ни одного публичного проекта с пакетами не найдено (листинг /packages публичных проектов пуст), анонимность скачивания package-файлов не доказана. Upstream-нюансы GitLab (project setting «Allow anyone to pull», deploy-токены, opkg не умеет передавать auth-заголовки, issue #36894 «Opkg Repository» закрыт как not planned) относятся к GitLab и должны перепроверяться на месте.
  • Releases с ассетами и «вечными» ссылками /-/releases/<tag>/downloads/<file>: механизм GitLab; на Mos.Hub живых примеров не найдено (см. выше).
  • CI artifacts: срок жизни/retention на Mos.Hub неизвестны.
  • Git LFS, кастомные домены для Pages, зеркалирование внешних репозиториев (косвенное новостное свидетельство в старом исследовании), лимиты/квоты/трафик — публичной документации не найдено; числовых данных нет вообще.

Unknown / needs real pilot

  • Загрузка и обновление артефактов извне (GitHub Actions → Mos.Hub API с токеном): модель авторизации для внешних клиентов не проверялась (требует логина).
  • Поведение raw-раздачи под периодической автоматической нагрузкой (тот самый session-cookie; возможная защита от ботов; кэш 60 с).
  • Практические лимиты: размер файла в git-репозитории, объём, трафик, retention — нигде не опубликованы.
  • URL и доступность Pages-сайта, публикуемого из проекта (шаблоны есть — работающий экземпляр не смотрели).
  • Долгосрочная стабильность URL и политики платформы для сторонних public-проектов.

Сравнение с текущей моделью (без ранжирования)

GitHub latest (текущее) Mos.Hub как зеркало Статический HTTP на VPS (базлайн)
Анонимное скачивание .ipk работает в production работает (raw/archive; подтверждено 2026-09-24) работает
Предсказуемый URL URL ассета релиза; перезапись ассетов под тегом latest уже отлажена workflow-ами raw-путь привязан к ветке (URL стабилен, содержимое изменяемо; кэш 60 с); релизы/пакеты не доказаны полный контроль
Хранение IPK доказано (лимиты GitHub документированы) в git — лимиты неизвестны; Registry — не доказан любой размер по хостингу
Packages.gz (если понадобится) через Pages — многократные прецеденты Pages-шаблоны официально есть; serving не проверен тривиально
Автоматизация выкладки Actions + gh release upload — работает GitLab API есть; внешняя автоматизация не проверена rsync/scp — своя обвязка
Retention/замена старых версий работает (workflow сам чистит) неизвестно полный контроль
Прозрачность квот документированы не опубликованы известны (хостер)
Операционная сложность нулевая (уже работает) новый канал, новая авторизация, мониторинг новая инфраструктура
Независимость от GitHub нет полная полная
Пригодность для opkg src/gz текущая модель ею не пользуется Pages-путь возможен, не доказан нативная

Мотивация пересмотра (Historical, из старого исследования): деградация доступности GitHub из РФ в 2026 г. — рост неудачных соединений по OONI, ограничения на подсети Fastly (через него раздаются релизные файлы), полный сбой 14.07.2026. Это наблюдения того периода, не текущий замер; но именно они делают RF-независимое зеркало осмысленной идеей для потребителей из РФ.

Решение по пилоту: B — пилот оправдан, но не доказан

Обоснование по критериям задачи:

  • анонимная стабильная загрузка файла — продемонстрирована (raw + archive);
  • но «relevant storage behavior» (квоты, лимиты размера, retention, внешняя автоматизация выкладки) — не продемонстрированы публично.

Поэтому не A (публичные факты не блокируют идею и дают мотивацию) и не C (доказательств хранилища/автоматизации нет).

Пилот максимального объёма (НЕ выполняется в этой задаче — оператор)

1. один тестовый проект (можно существующий sayone/saymer или новый disposable);
2. один безвредный артефакт (dummy .ipk или произвольный небольшой файл);
3. один Packages.gz (если проверяется opkg-сценарий);
4. анонимный GET-тест URL с другой машины (curl -fsSI);
5. на Keenetic: wget/curl загрузка + (опционально) opkg download/update против
   временного custom-feed;
6. отдельно: PUT через API с project-token из настроек проекта (внешняя автоматизация);
7. повторный GET через сутки (retention/самопроизвольные удаления);
8. удалить проект/файлы после проверки — по желанию оператора.

До независимого доказательства зеркала — никаких изменений production-workflow в entware-go (см. PROMOTION_BACKLOG): ни Mos.Hub-выкладки, ни правки latest, ни существующих workflow-ов.

Типичные проблемы (если пилот состоится)

  • raw-URL отвечает session-cookie и кэшем 60 с — проверять, что curl/wget/opkg на Keenetic работают без браузерного flow;
  • «работает» ≠ «работает под расписанием»: проверять повторные автоматические GET (интервал как у реального потребителя);
  • Releases/Package Registry на Mos.Hub публично никем не используются — не строить пилот на них, пока не проверено на месте;
  • moshub.md-цифры «лимит 10 МБ у GitLab Releases» и сервис moshub.ru — из ошибочной ветки старого исследования, не использовать.

Что подтверждено, а что нет

Confirmed:

  • модель дистрибуции entware-go (тег latest, свои glob-ы на workflow, curl-потребители) — по коду и README репозитория;
  • все факты раздела «Confirmed on Mos.Hub» (анонимные проверки 2026-09-24);
  • существование публичного проекта владельца sayone/saymer (2026-05-09).

Observed (Historical):

  • деградация GitHub из РФ в 2026 г. (OONI/Fastly/сбой 14.07.2026) — наблюдения старого исследования на свою дату;
  • масштаб платформы Mos.Hub «30+ тыс. пользователей / 34+ тыс. проектов» — старые анонсы, не перепроверялись.

Research / needs pilot:

  • всё из раздела «Unknown»: внешняя автоматизация, квоты, retention, Pages-serving, поведение под нагрузкой, долгосрочная стабильность URL.

Опровергнуто / не использовать:

  • «Mos.Hub не предоставляет статический хостинг / Pages не подтверждены» — опровергнуто официальными Pages-шаблонами платформы;
  • сведения о «moshub.ru» как о платформе с Maven/npm/PyPI-реестрами — другой сервис, к hub.mos.ru отношения не подтверждено;
  • «лимит 10 МБ на файл в GitLab Releases» — не подтверждаемое утверждение;
  • уверенные «Да» по Package Registry/Releases для Mos.Hub из первой таблицы старого исследования — вывод по аналогии, публично не подтверждён.

Источники и provenance

  • Живые анонимные проверки hub.mos.ru 2026-09-24 (root, /api/v4/*, raw, archive, группы project-templates/mos/pkgs/pkgstore, проект sayone/saymer).
  • saymer-alt/entware-go @ gh-action-build: README, .github/workflows/build-mihomo.yml, build-beszel.yml, build-warpscout.yml (read-only).
  • Raw: moshub.md (компиляция AI-разведок, выводы противоречивы — см. заголовок файла), moshubrd.md (README реального проекта владельца на Mos.Hub).
  • Документация GitLab — только как upstream-справка «возможностей GitLab», не как доказательство для Mos.Hub.

Связанные материалы