Установка

Загрузка

Ничего не нужно компилировать и никакого рантайма ставить. Выберите сборку под вашу машину и скачайте через curl.

amd64 — это большинство облачных VPS и десктопов; arm64 — современные ARM-серверы и Raspberry Pi 4/5; armv7 — 32-битные ARM-платы.

Проверка загрузки

С каждым релизом идёт checksums.txt с SHA-256 каждого бинарника. Положите его рядом со скачанным файлом и сверьте — это та же проверка SHA-256, что gtcnsl self-update делает перед заменой бинарника.

curl -fsSLO https://dl.gtcnsl.ru/v1.3.0/checksums.txt
sha256sum --check --ignore-missing checksums.txt

Положить в PATH

Сниппет установки уже пишет в /usr/local/bin/gtcnsl и ставит бит исполнения. Если скачивали вручную — сделайте это явно:

sudo install -m 0755 gtcnsl-v1.3.0-linux-amd64 /usr/local/bin/gtcnsl

Проверить запуск

gtcnsl version

Вы увидите версию, коммит сборки и целевую архитектуру. Если команда не найдена — оболочка ещё не подхватила /usr/local/bin: откройте новую сессию.

Поддерживаемые платформы

gtcnsl тестируется на дистрибутивах и архитектурах ниже. Другие современные systemd-дистрибутивы, скорее всего, тоже работают, но не проверены.

Профили сервинга: HTTP или сразу HTTPS

По умолчанию gtcnsl gitea install поднимает обычный HTTP на :3000 — правильный выбор за реверс-прокси или во внутренней сети. Если TLS должна терминировать сама Gitea, выберите профиль при установке:

# Встроенный Let's Encrypt на :443 (:80 отвечает на ACME-челлендж и редиректит).
# --acme-tos — ваше явное согласие с условиями CA; оно никогда не подразумевается.
gtcnsl gitea install --yes --serving https-acme \
    --domain git.example.com --acme-email you@example.com --acme-tos

# Свой сертификат (корпоративный CA, wildcard) — порт по умолчанию 443.
gtcnsl gitea install --yes --serving https-manual \
    --domain git.example.com \
    --cert-file /etc/gitea-tls/fullchain.pem --key-file /etc/gitea-tls/privkey.pem

Оба HTTPS-профиля проходят префлайты до того, как что-либо скачано: целевые порты должны быть свободны, файлы сертификата — существовать и читаться пользователем git, а для ACME домен проверяется (best effort) на то, что указывает на этот хост. Юнит gtcnsl выдаёт CAP_NET_BIND_SERVICE, поэтому непривилегированный git биндит :443/:80 без ухищрений.

Уже установлено по HTTP? Живой инстанс переключается без переустановки:

gtcnsl gitea enable-https --yes --serving https-acme \
    --domain git.example.com --acme-email you@example.com --acme-tos

Переключение едет на декларативной машинерии конфига — атомарная запись с бэкапом, рестарт, health-check — и при любой ошибке (сертификат не выдан, DNS ещё не указывает сюда) автоматически откатывается к рабочему HTTP-конфигу. Если рукописный юнит не даёт capability для портов ниже 1024, --grant-caps кладёт маленький drop-in от gtcnsl; сам файл юнита никогда не редактируется. У gtcnsl doctor появилась проба когерентности, которая ловит конфиг «https на :443», чей юнит на самом деле не может забиндить порт.

Уже есть Gitea? Адоптируйте её

Если на хосте уже стоит Gitea — руками или другим инструментом — переустанавливать не нужно. gtcnsl gitea install обнаружит её и обновит на месте (см. «Обновления»), а gtcnsl gitea adopt возьмёт установку под управление не перенося никакие данные:

gtcnsl gitea adopt                      # dry-run: печатает план, ничего не меняет
gtcnsl gitea adopt --yes --emit-template app.ini.tmpl
gtcnsl gitea adopt --yes --unit         # опционально: нормализовать рукописный юнит

Adopt выносит секреты из app.ini в secrets.ini с теми же значениями (без рестарта), затягивает права world-readable app.ini и генерирует шаблон без секретов для коммита в git — открывая config apply и secrets rotate. --unit разделяет рукописный unit-файл на управляемую базу gtcnsl и operator-owned drop-in, причём сам systemd доказывает, что поведение не изменилось (иначе — автооткат).

Что дальше

Бинарник в PATH — и вы в трёх командах от работающего Gitea с CI.