Эта страница была обновлена 2020-09 и содержит сведения для версии маршрутизатора 0.9.47.

Настройка Gitlab через I2P

Это процесс настройки, который я использую для конфигурирования Gitlab и I2P, с Docker для управления самой службой. Gitlab очень легко разместить на I2P таким образом, его может администрировать один человек без особых трудностей. В моей конфигурации я использую виртуальную машину Debian для размещения контейнеров docker и маршрутизатора I2P на системе Debian Host, однако, для некоторых людей это может быть более чем необходимо. Эти инструкции должны работать на любой системе на базе Debian, независимо от того, находится ли она в ВМ или нет, и должны легко переводиться на любую систему, где доступны Docker и I2P-маршрутизатор. Это руководство начинается с Docker и не предполагает наличия под ним ВМ.

Зависимости и Docker

Поскольку Gitlab работает в контейнере, нам нужно установить только необходимые для контейнера зависимости на нашей основной системе. Удобно, что все необходимое можно установить:

sudo apt install docker.io

на немодифицированной системе Debian, или если вы добавили собственный репозиторий Docker "Community" Debian, вы можете использовать:

sudo apt install docker-ce

вместо.

Получение контейнеров Docker

После установки docker вы можете получить контейнеры docker, необходимые для gitlab. Не запускайте их пока.

docker pull gitlab/gitlab-ce

Образ докера gitlab-ce собирается с использованием только образов докера Ubuntu в качестве родительского, которые собираются с нуля. Поскольку здесь не задействованы сторонние образы, обновления должны появляться сразу же, как только они станут доступны в образах хоста. Чтобы самостоятельно ознакомиться с Dockerfile, посетите исходный код Gitlab.

Настройка I2P HTTP-прокси для использования Gitlab (Важная информация, необязательные шаги)

Серверы Gitlab внутри I2P можно запускать с возможностью или без возможности взаимодействия с серверами в интернете за пределами I2P. В случае, когда серверу Gitlab не разрешено взаимодействовать с серверами вне I2P, его нельзя деанонимизировать путем клонирования git-репозитория с git-сервера в интернете вне I2P. Однако они могут экспортировать и зеркалировать репозитории из других git-сервисов внутри I2P.

В случае, когда серверу Gitlab разрешено взаимодействовать с серверами вне I2P, он может выступать в качестве "моста" для пользователей, которые могут использовать его для зеркалирования контента вне I2P на источник, доступный I2P, однако в этом случае он не является анонимным. Гит-сервисы в неанонимном интернете будут подключаться напрямую.

Если вы хотите иметь сопряженный, неанонимный экземпляр Gitlab с доступом к веб-репозиториям, никаких дополнительных изменений не требуется.

Если вы хотите иметь экземпляр Gitlab только для I2P без доступа к Web-Only Repositories , вам нужно настроить Gitlab на использование I2P HTTP Proxy. Поскольку HTTP-прокси I2P по умолчанию прослушивает только 127.0.0.1, вам нужно настроить новый для Docker, который будет прослушивать адрес хоста/шлюза сети Docker, обычно это 172.17.0.1. Я настраиваю свой на порт 4446.

Запуск контейнера на месте

После того как вы все настроите, вы можете запустить контейнер и опубликовать свой экземпляр Gitlab локально.

docker run --detach \
  --env HTTP_PROXY=http://172.17.0.1:4446 \
  --publish 127.0.0.1:8443:443 --publish 127.0.0.1:8080:80 --publish 127.0.0.1:8022:22 \
  --name gitlab \
  --restart always \
  --volume /srv/gitlab/config:/etc/gitlab:Z \
  --volume /srv/gitlab/logs:/var/log/gitlab:Z \
  --volume /srv/gitlab/data:/var/opt/gitlab:Z \
  gitlab/gitlab-ce:latest

Зайдите в свой локальный экземпляр Gitlab и настройте учетную запись администратора. Выберите надежный пароль и настройте ограничения учетной записи пользователя в соответствии с вашими ресурсами.

Измените gitlab.rb (Необязательно, но хорошая идея для хостов "Bridged non-anonymous")

Также можно применять настройки HTTP Proxy более детально, чтобы разрешить пользователям зеркалировать хранилища только с выбранных вами доменов. Поскольку домен, предположительно, управляется организацией, вы можете использовать это для обеспечения того, чтобы зеркалируемые хранилища следовали разумному набору политик. В конце концов, в неанонимном интернете гораздо больше оскорбительного контента, чем на I2P, и мы не хотели бы слишком упрощать внедрение оскорбительного контента из такого гнусного места.

Добавьте следующие строки в ваш файл gitlab.rb внутри контейнера /src/gitlab/config. Эти настройки вступят в силу при перезапуске через некоторое время.

gitlab_rails['env'] = {
    "http_proxy" => "http://172.17.0.1:4446",
    "https_proxy" => "http://172.17.0.1:4446",
    "no_proxy" => ".github.com,.gitlab.com"
}
gitaly['env'] = {
    "http_proxy" => "http://172.17.0.1:4446",
    "https_proxy" => "http://172.17.0.1:4446",
    "no_proxy" => "unix,.github.com,.gitlab.com"
}
gitlab_workhorse['env'] = {
    "http_proxy" => "http
    "https_proxy" => "http://172.17.0.1:4446",
    "no_proxy" => "unix,.github.com,.gitlab.com"
}

Настройте туннели Сервиса и зарегистрируйте имя хоста

После того как вы установили Gitlab локально, перейдите на консоль I2P Router. Вам нужно будет настроить два серверных туннеля: один ведет к веб-интерфейсу Gitlab (HTTP) на TCP-порт 8080, а другой - к SSH-интерфейсу Gitlab на TCP-порт 8022.

Веб-интерфейс Gitlab (HTTP)

Для веб-интерфейса используйте туннель сервера "HTTP". С http://127.0.0.1:7657/i2ptunnelmgr запустите "Мастер создания нового туннеля" и введите следующие значения на каждом шаге:

  1. Выберите "Серверный туннель"
  2. Выберите "HTTP-сервер"
  3. Заполните "Веб-сервис Gitlab" или опишите туннель другим способом
  4. Введите 127.0.0.11для хоста и 8080 для порта.
  5. Выберите "Автоматически запускать туннель при запуске маршрутизатора".
  6. Подтвердите свой выбор.
Зарегистрируйте имя хоста (необязательно)

Веб-службы на I2P могут зарегистрировать для себя имена хостов, предоставив строку аутентификации провайдеру услуг перехода, например stats.i2p. Для этого снова откройте http://127.0.0.1:7657/i2ptunnelmgr и нажмите на элемент "Веб-служба Gitlab", который вы только что настроили. Прокрутите до нижней части раздела "Редактирование настроек сервера" и нажмите Аутентификация при регистрации. Скопируйте поле с надписью "Аутентификация для добавления имени хоста" и зайдите на сайт stats.i2p, чтобы добавить свое имя хоста. Обратите внимание, что если вы хотите использовать поддомен (например, git.idk.i2p), то вам придется использовать правильную строку аутентификации для вашего поддомена, что немного сложнее и заслуживает отдельной инструкции.

Интерфейс SSH Gitlab

Для интерфейса SSH используйте "Стандартный" серверный туннель. С сайта http://127.0.0.1:7657/i2ptunnelmgr запустите "Мастер создания туннеля" и введите следующие значения на каждом шаге:

  1. Выберите "Серверный туннель"
  2. Выберите "Стандартный сервер"
  3. Заполните "Gitlab SSH Service" или опишите туннель другим способом
  4. Введите 127.0.0.1 для хоста и 8022 для порта.
  5. Выберите "Автоматически запускать туннель при запуске маршрутизатора".
  6. Подтвердите свой выбор.

Повторно запустите службу Gitlab с новым именем хоста

Наконец, если вы либо изменили файл gitlab.rb, либо зарегистрировали имя хоста, вам необходимо перезапустить службу gitlab, чтобы настройки вступили в силу.

docker stop gitlab
docker rm gitlab
docker run --detach \
  --hostname your.hostname.i2p \
  --hostname thisisreallylongbase32hostnamewithfiftytwocharacters.b32.i2p \
  --env HTTP_PROXY=http://172.17.0.1:4446 \
  --publish 127.0.0.1:8443:443 --publish 127.0.0.1:8080:80 --publish 127.0.0.1:8022:22 \
  --name gitlab \
  --restart always \
  --volume /srv/gitlab/config:/etc/gitlab:Z \
  --volume /srv/gitlab/logs:/var/log/gitlab:Z \
  --volume /srv/gitlab/data:/var/opt/gitlab:Z \
  gitlab/gitlab-ce:latest