From e2d0f38dd293025aa60903125718c7bc722ba727 Mon Sep 17 00:00:00 2001 From: hankhill19580 Date: Mon, 16 Mar 2020 13:48:44 +0000 Subject: [PATCH] gitlab over I2P hosting tutorial blog post, minor correction to git-over-i2p blog post. --- i2p2www/blog/2020/03/06/git-over-i2p.rst | 2 +- i2p2www/blog/2020/03/16/gitlab-over-i2p.rst | 251 ++++++++++++++++++++ 2 files changed, 252 insertions(+), 1 deletion(-) create mode 100644 i2p2www/blog/2020/03/16/gitlab-over-i2p.rst diff --git a/i2p2www/blog/2020/03/06/git-over-i2p.rst b/i2p2www/blog/2020/03/06/git-over-i2p.rst index 3ab0c7ac..69d96bd9 100644 --- a/i2p2www/blog/2020/03/06/git-over-i2p.rst +++ b/i2p2www/blog/2020/03/06/git-over-i2p.rst @@ -5,7 +5,7 @@ .. meta:: :author: idk :date: 2020-03-06 - :excerpt: {% trans %}Help Bootstrap I2P-Bote!{% endtrans %} + :excerpt: {% trans %}Git over I2P{% endtrans %} {% trans -%} Tutorial for setting up git access through an I2P Tunnel. This tunnel diff --git a/i2p2www/blog/2020/03/16/gitlab-over-i2p.rst b/i2p2www/blog/2020/03/16/gitlab-over-i2p.rst new file mode 100644 index 00000000..a335e550 --- /dev/null +++ b/i2p2www/blog/2020/03/16/gitlab-over-i2p.rst @@ -0,0 +1,251 @@ +{% trans -%}Gitlab over I2P Setup{%- endtrans %} +================================================ + +.. meta:: + :author: idk + :date: 2020-03-16 + :excerpt: {% trans -%}Mirror I2P Git repositories and Bridge Clearnet repositories for others.{%- endtrans %} + +{% trans -%} +This is the setup process I use for configuring Gitlab and I2P, with +Docker in place to manage the service itself. Gitlab is very easy to +host on I2P in this fashion, it can be administered by one person +without much difficulty. In my configuration, I use a Debian VM to host +docker containers and an I2P router, on a Debian Host system, however, +this may be more than necessary for some people. These instructions +should work on any Debian-based system, regardless of whether it is in a +VM or not, and should easily translate to any system where Docker and an +I2P router are available. This guide starts at Docker and does not +assume any VM underneath. +{%- endtrans %} + +{% trans -%}Dependencies and Docker{%- endtrans %} +--------------------------------------------------- + +{% trans -%} +Because Gitlab runs in a container, we only need to install the +dependencies required for the container on our main system. +Conveniently, you can install everything you need with: +{%- endtrans %} + +:: + + sudo apt install docker.io + +{% trans -%} +on an otherwise unmodified Debian system, or if you have added Docker’s +own “Community” Debian repository, you may use: +{%- endtrans %} + +:: + + sudo apt install docker-ce + +{% trans -%} +instead. +{%- endtrans %} + +------------------------------------------------------ +{% trans -%}Fetch the Docker Containers{%- endtrans %} +------------------------------------------------------ + +{% trans -%} +Once you have docker installed, you can fetch the docker containers +required for gitlab. *Don’t run them yet.* +{%- endtrans %} + +:: + + docker pull gitlab/gitlab-ce + +{% trans -%} +For those who are concerned, the gitlab-ce Docker image is built using +only Ubuntu Docker images as a parent, which are built from scratch +images. Since there are no third-party images involved here, updates +should come as soon as they are available in the host images. To review +the Dockerfile for yourself, visit the `Gitlab source +code `__. +{%- endtrans %} + +{% trans -%}Set up an I2P HTTP Proxy for Gitlab to use(Important information, optional steps){%- endtrans %} +------------------------------------------------------------------------------------------------------------ + +{% trans -%} +Gitlab servers inside of I2P can be run with or without the ability to +interact with servers on the internet outside of I2P. In the case where +the Gitlab server is *not allowed* to interact with servers outside of +I2P, they cannot be de-anonymized by cloning a git repository from a git +server on the internet outside of I2P. They can, however, export and +mirror repositories from other git services inside of I2P. +{%- endtrans %} + +{% trans -%} +In the case where the Gitlab server is *allowed* to interact with +servers outside of I2P, it can act as a “Bridge” for the users, who can +use it to mirror content outside I2P to an I2P-accessible source, +however it *is not anonymous* in this case. Git services on the +non-anonymous internet will be connected to directly. +{%- endtrans %} + +{% trans -%} +**If you want to have a bridged, non-anonymous Gitlab instance with +access to** **web repositories,** no further modification is necessary. +{%- endtrans %} + +{% trans -%} +**If you want to have an I2P-Only Gitlab instance with no access to +Web-Only** **Repositories**, you will need to configure Gitlab to use an +I2P HTTP Proxy. Since the default I2P HTTP proxy only listens on +``127.0.0.1``, you will need to set up a new one for Docker that listens +on the Host/Gateway address of the Docker network, which is usually +``172.17.0.1``. I configure mine on port ``4446``. +{%- endtrans %} + +{% trans -%}Start the Container Locally{%- endtrans %} +------------------------------------------------------ + +{% trans -%} +Once you have that set up, you can start the container and publish your +Gitlab instance locally. +{%- endtrans %} + +:: + + 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 + +{% trans -%} +Visit your Local Gitlab instance and set up your admin account. Choose a +strong password, and configure user account limits to match your +resources. +{%- endtrans %} + +{% trans -%}Modify gitlab.rb(Optional, but a good idea for “Bridged non-anonymous” hosts){%- endtrans %} +-------------------------------------------------------------------------------------------------------- + +{% trans -%} +It’s also possible to apply your HTTP Proxy settings in a more granular +way, so that you can only allow users to mirror repositories from the +domains that you choose. Since the domain is presumably operated by an +organization, you can use this to ensure that repositories that are +mirrorable follow a reasonable set of policies. After all, there is far +more abusive content on the non-anonymous internet than there is on I2P, +we wouldn’t want to make it too easy to introduce abusive content from +such a nefarious place. +{%- endtrans %} + +{% trans -%} +Add the following lines to your gitlab.rb file inside the +/src/gitlab/config container. These settings will take effect when you +restart in a moment. +{%- endtrans %} + +:: + + 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" + } + +--------------------------------------------------------------------------------- +{% trans -%}Set up your Service tunnels and sign up for a Hostname{%- endtrans %} +--------------------------------------------------------------------------------- + +{% trans -%} +Once you have Gitlab set up locally, go to the I2P Router console. You +will need to set up two server tunnels, one leading to the Gitlab +web(HTTP) interface on TCP port 8080, and one to the Gitlab SSH +interface on TCP Port 8022. +{%- endtrans %} + +{% trans -%}Gitlab Web(HTTP) Interface{%- endtrans %} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +{% trans -%} +For the Web interface, use an “HTTP” server tunnel. From +http://127.0.0.1:7657/i2ptunnelmgr launch the “New Tunnel Wizard” and +enter the following values at each step: +{%- endtrans %} + +1. {% trans -%}Select “Server Tunnel”{%- endtrans %} +2. {% trans -%}Select “HTTP Server”{%- endtrans %} +3. {% trans -%}Fill in “Gitlab Web Service” or otherwise describe the tunnel{%- endtrans %} +4. {% trans -%}Fill in ``127.0.0.1`` for the host and ``8080`` for the port.{%- endtrans %} +5. {% trans -%}Select “Automatically start tunnel when Router Starts”{%- endtrans %} +6. {% trans -%}Confirm your selections.{%- endtrans %} + +{% trans -%}Register a Hostname(Optional){%- endtrans %} +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +{% trans -%} +Web services on I2P can register hostnames for themselves by providing +an authentication string to a jump service provider like +`stats.i2p `__. To do this, open the +http://127.0.0.1:7657/i2ptunnelmgr again and click on the “Gitlab Web +Service” item you just set up. Scroll to the bottom of the “Edit Server +Settings” section and click Registration Authentication. Copy the field +that says “Authentication for adding Hostname” and visit +`stats.i2p `__ to add your hostname. +Note that if you want to use a subdomain(Like git.idk.i2p) then you will +have to use the correct authentication string for your subdomain, which +is a little bit more complicated and merits it’s own instructions. +{%- endtrans %} + +{% trans -%}Gitlab SSH Interface{%- endtrans %} +~~~~~~~~~~~~~~`~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +{% trans -%} +For the SSH interface, use a “Standard” server tunnel. From +http://127.0.0.1:7657/i2ptunnelmgr launch the “New Tunnel Wizard” and +enter the following values at each step: +{%- endtrans %} + +1. {% trans -%}Select “Server Tunnel”{%- endtrans %} +2. {% trans -%}Select “Standard Server”{%- endtrans %} +3. {% trans -%}Fill in “Gitlab SSH Service” or otherwise describe the tunnel{%- endtrans %} +4. {% trans -%}Fill in ``127.0.0.1`` for the host and ``8022`` for the port.{%- endtrans %} +5. {% trans -%}Select “Automatically start tunnel when Router Starts”{%- endtrans %} +6. {% trans -%}Confirm your selections.{%- endtrans %} + +{% trans -%}Re-start the Gitlab Service with the new Hostname{%- endtrans %} +---------------------------------------------------------------------------- + +{% trans -%} +Finally, if you either modified ``gitlab.rb`` or you registered a +hostname, you will need to re-start the gitlab service for the settings +to take effect. +{%- endtrans %} + +:: + + 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