I2P Address: [http://git.idk.i2p]

Skip to content
Snippets Groups Projects
Commit 55ca6792 authored by idk's avatar idk
Browse files

move gitlab, git, and git bundle guides to application section, update the screenshots

parent 70693b73
No related branches found
No related tags found
1 merge request!3move gitlab, git, and git bundle guides to application section, update the screenshots
Hide whitespace changes
Inline Side-by-side
Showing
with 235 additions and 0 deletions
i2p2www/pages/downloads/windows.html
+ 1
− 0
View file @ 55ca6792
{% extends "global/layout.html" %} {% extends "global/layout.html" %}
{% block title %}Microsoft Windows{% endblock %} {% block title %}Microsoft Windows{% endblock %}
{% block accuratefor %}0.9.47{% endblock %}
{% block content %} {% block content %}
<h1>{{ _('Installing I2P, its dependencies, and recommended external software on Windows 10') }}</h1> <h1>{{ _('Installing I2P, its dependencies, and recommended external software on Windows 10') }}</h1>
......
i2p2www/pages/global/nav.html
+ 4
− 0
View file @ 55ca6792
...@@ -104,6 +104,9 @@ ...@@ -104,6 +104,9 @@
<ul> <ul>
<li><a href="{{ site_url('docs/applications/supported') }}"><div class="menuitem"><span>{{ _('Supported applications') }}</span></div></a></li> <li><a href="{{ site_url('docs/applications/supported') }}"><div class="menuitem"><span>{{ _('Supported applications') }}</span></div></a></li>
<li><a href="{{ site_url('docs/applications/bittorrent') }}"><div class="menuitem"><span>{{ _('Bittorrent') }}</span></div></a></li> <li><a href="{{ site_url('docs/applications/bittorrent') }}"><div class="menuitem"><span>{{ _('Bittorrent') }}</span></div></a></li>
<li><a href="{{ site_url('docs/applications/gitlab') }}"><div class="menuitem"><span>{{ _('GitLab') }}</span></div></a></li>
<li><a href="{{ site_url('docs/applications/git') }}"><div class="menuitem"><span>{{ _('Git') }}</span></div></a></li>
<li><a href="{{ site_url('docs/applications/git-bundle') }}"><div class="menuitem"><span>{{ _('git+Bittorrent') }}</span></div></a></li>
</ul> </ul>
</li> </li>
<li class="has-sub"><div class="menuitem"><span>{{ _('Protocols') }}</span></div> <li class="has-sub"><div class="menuitem"><span>{{ _('Protocols') }}</span></div>
...@@ -137,6 +140,7 @@ ...@@ -137,6 +140,7 @@
<li><a href="{{ site_url('get-involved/guides/new-developers') }}"><div class="menuitem"><span>{{ _('New developers') }}</span></div></a></li> <li><a href="{{ site_url('get-involved/guides/new-developers') }}"><div class="menuitem"><span>{{ _('New developers') }}</span></div></a></li>
<li><a href="{{ site_url('get-involved/guides/ides') }}"><div class="menuitem"><span>{{ _('Using an IDE with I2P') }}</span></div></a></li> <li><a href="{{ site_url('get-involved/guides/ides') }}"><div class="menuitem"><span>{{ _('Using an IDE with I2P') }}</span></div></a></li>
<li><a href="{{ site_url('get-involved/guides/dev-guidelines') }}"><div class="menuitem"><span>{{ _('Developer guidelines and coding style') }}</span></div></a></li> <li><a href="{{ site_url('get-involved/guides/dev-guidelines') }}"><div class="menuitem"><span>{{ _('Developer guidelines and coding style') }}</span></div></a></li>
<li><a href="{{ site_url('docs/applications/git') }}"><div class="menuitem"><span>{{ _('Git') }}</span></div></a></li>
<li><a href="{{ site_url('get-involved/guides/monotone') }}"><div class="menuitem"><span>{{ _('Monotone') }}</span></div></a></li> <li><a href="{{ site_url('get-involved/guides/monotone') }}"><div class="menuitem"><span>{{ _('Monotone') }}</span></div></a></li>
<li><a href="{{ site_url('get-involved/guides/new-translators') }}"><div class="menuitem"><span>{{ _('New translators') }}</span></div></a></li> <li><a href="{{ site_url('get-involved/guides/new-translators') }}"><div class="menuitem"><span>{{ _('New translators') }}</span></div></a></li>
</ul> </ul>
......
i2p2www/pages/site/docs/applications/git-bundle.html 0 → 100644
+ 35
− 0
View file @ 55ca6792
{% extends "global/layout.html" %}
{% block title %}{% trans %}Setting up Gitlab with I2P{% endtrans %}{% endblock %}
{% block lastupdated %}2020-09{% endblock %}
{% block accuratefor %}0.9.47{% endblock %}
{% block content %}
<h1 id="using-a-git-bundle-to-fetch-the-i2p-source-code">{% trans -%}Using a git bundle to fetch the I2P source code{%- endtrans %}</h1>
<p>{% trans -%} Cloning large software repositories over I2P can be difficult, and using git can sometimes make this harder. Fortunately, it can also sometimes make it easier. Git has a <code>git bundle</code> command which can be used to turn a git repository into a file which git can then clone, fetch, or import from a location on your local disk. By combining this capability with bittorrent downloads, we can solve our remaining problems with <code>git clone</code>. {%- endtrans %}</p>
<h2 id="before-you-start">{% trans -%}Before you Start{%- endtrans %}</h2>
<p>{% trans -%} If you intend to generate a git bundle, you <strong>must</strong> already possess a full copy of the <strong>git</strong> repository, not the mtn repository. You can get it from github or from git.idk.i2p, but a shallow clone(a clone done to –depth=1) <em>will not</em> <em>work</em>. It will fail silently, creating what looks like a bundle, but when you try to clone it it will fail. If you are just retrieving a pre-generated git bundle, then this section does not apply to you. {%- endtrans %}</p>
<h2 id="fetching-i2p-source-via-bittorrent">{% trans -%}Fetching I2P Source via Bittorrent{%- endtrans %}</h2>
<p>{% trans -%} Someone will need to supply you with a torrent file or a magnet link corresponding to an existing <code>git bundle</code> that they have already generated for you. A recent, correctly-generated bundle of the mainline i2p.i2p source code as-of Wednesday, March 18, 2020, can be found inside of I2P at my pastebin <a href="http://paste.idk.i2p/f/4h137i">paste.idk.i2p/f/4hq37i</a>. {%- endtrans %}</p>
<p>{% trans -%} Once you have a bundle, you will need to use git to create a working repository from it. If you’re using GNU/Linux and i2psnark, the git bundle should be located in $HOME/.i2p/i2psnark or, as a service on Debian, /var/lib/i2p/i2p-config/i2psnark. If you are using BiglyBT on GNU/Linux, it is probably at “$HOME/BiglyBT Downloads/” instead. The examples here assume I2PSnark on GNU/Linux, if you use something else, replace the path to the bundle with the download directory preferred by your client and platform. {%- endtrans %}</p>
<h3 id="using-git-clone">{% trans -%}Using <code>git clone</code>{%- endtrans %}</h3>
<p>{% trans -%}Cloning from a git bundle is easy, just:{%- endtrans %}</p>
<pre><code>git clone $HOME/.i2p/i2psnark/i2p.i2p.bundle</code></pre>
<p>{% trans -%}If you get the following error, try using git init and git fetch manually instead.{%- endtrans %}</p>
<pre><code>fatal: multiple updates for ref &#39;refs/remotes/origin/master&#39; not allowed</code></pre>
<h3 id="using-git-init-and-git-fetch">{% trans -%}Using <code>git init</code> and <code>git fetch</code>{%- endtrans %}</h3>
<p>{% trans -%}First, create an i2p.i2p directory to turn into a git repository.{%- endtrans %}</p>
<pre><code>mkdir i2p.i2p &amp;&amp; cd i2p.i2p</code></pre>
<p>{% trans -%}Next, initialize an empty git repository to fetch changes back into.{%- endtrans %}</p>
<pre><code>git init</code></pre>
<p>{% trans -%}Finally, fetch the repository from the bundle.{%- endtrans %}</p>
<pre><code>git fetch $HOME/.i2p/i2psnark/i2p.i2p.bundle</code></pre>
<h3 id="replace-the-bundle-remote-with-the-upstream-remote">{% trans -%}Replace the bundle remote with the upstream remote{%- endtrans %}</h3>
<p>{% trans -%} Now that you have a bundle, you can keep up with changes by setting the remote to the upstream repository source. {%- endtrans %}</p>
<pre><code>git remote set-url origin git@127.0.0.1:i2p-hackers/i2p.i2p</code></pre>
<h2 id="generating-a-bundle">{% trans -%}Generating a Bundle{%- endtrans %}</h2>
<p>{% trans -%} First, follow the <a href="GIT.md">Git guide for Users</a> until you have a successfully <code>--unshallow</code>ed clone of clone of the i2p.i2p repository. If you already have a clone, make sure you run <code>git fetch --unshallow</code> before you generate a torrent bundle. {%- endtrans %}</p>
<p>{% trans -%}Once you have that, simply run the corresponding ant target:{%- endtrans %}</p>
<pre><code>ant bundle</code></pre>
<p>{% trans -%} and copy the resulting bundle into your I2PSnark downloads directory. For instance: {%- endtrans %}</p>
<pre><code>cp i2p.i2p.bundle* $HOME/.i2p/i2psnark/</code></pre>
<p>{% trans -%} In a minute or two, I2PSnark will pick up on the torrent. Click on the “Start” button to begin seeding the torrent. {%- endtrans %}</p>
{% endblock %}
i2p2www/pages/site/docs/applications/git.html 0 → 100644
+ 100
− 0
View file @ 55ca6792
{% extends "global/layout.html" %}
{% block title %}{% trans %}Setting up Gitlab with I2P{% endtrans %}{% endblock %}
{% block lastupdated %}2020-09{% endblock %}
{% block accuratefor %}0.9.47{% endblock %}
{% block content %}
<h1 id="git-over-i2p-for-users">Git over I2P for Users</h1>
<h2>Attention: Not all repositories are migrated to git yet. At this time, i2p.www and i2p.firefox are accepting merge requests via gitlab.</h2>
<p>{% trans -%} Tutorial for setting up git access through an I2P Tunnel. This tunnel will act as your access point to a single git service on I2P. {%- endtrans %}</p>
<h2 id="before-anything-else-know-the-capabilities-the-service-offers-to-the-public">Before anything else: Know the capabilities the service offers to the public</h2>
<p>{% trans -%} Depending on how the git service is configured, it may or may not offer all services on the same address. In the case of gittest.i2p, there is a public HTTP URL, but this URL is read-only and cannot be used to make changes. To do that, you must also know the SSH base32, which isn’t public at this time. Unless I’ve told you the SSH base32 to gittest.i2p, head over to the <a href="GITLAB.md">Server</a> tutorial to set up your own. {%- endtrans %}</p>
<h2 id="first-set-up-an-account-at-a-git-service">First: Set up an account at a Git service</h2>
<p>{% trans -%} To create your repositories on a remote git service, sign up for a user account at that service. Of course it’s also possible to create repositories locally and push them to a remote git service, but most will require an account and for you to create a space for the repository on the server. Gitlab has a very simple sign-up form: {%- endtrans %}</p>
<figure>
<img src="/_static/images/git/register.png" alt="" /><figcaption>Registration is easy!</figcaption>
</figure>
<h2 id="second-create-a-project-to-test-with">Second: Create a project to test with</h2>
<p>{% trans -%} To make sure the setup process works, it helps to make a repository to test with from the server, and for the sake of this tutorial, we’re going to use a fork of the I2P router. First, browse to the i2p-hackers/i2p.i2p repository: {%- endtrans %}</p>
<figure>
<img src="/_static/images/git/explore.png" alt="" /><figcaption>Browse to i2p.i2p</figcaption>
</figure>
<figure>
<img src="/_static/images/git/i2p.png" alt="" /><figcaption>I2P Hackers i2p.i2p</figcaption>
</figure>
<p>{% trans -%} Then, fork it to your account. {%- endtrans %}</p>
<figure>
<img src="/_static/images/git/fork.png" alt="" /><figcaption>Roger is forking</figcaption>
</figure>
<figure>
<img src="/_static/images/git/forked.png" alt="" /><figcaption>Roger is finished</figcaption>
</figure>
<h2 id="third-set-up-your-git-client-tunnel">Third: Set up your git client tunnel</h2>
<p>{% trans -%} To have read-write access to my server, you’ll need to set up a tunnel for your SSH client. As an example, we’re going to use the HTTP tunnel instead, but if all you need is read-only, HTTP/S cloning, then you can skip all this and just use the http_proxy environment variable to configure git to use the pre-configured I2P HTTP Proxy. For example: {%- endtrans %}</p>
<pre><code>http_proxy=http://localhost:4444 git clone http://gittest.i2p/i2p-developer/i2p.i2p</code></pre>
<figure>
<img src="/_static/images/git/wizard1.png" alt="" /><figcaption>Client tunnel</figcaption>
</figure>
<figure>
<img src="/_static/images/git/wizard2.png" alt="" /><figcaption>Git over I2P</figcaption>
</figure>
<p>{% trans -%} Then, add the address you will be pushing and pulling from. Note that this example address is for Read-Only HTTP-over-I2P clones, if your admin does not allow the git HTTP(Smart HTTP) protocol, then you will need to get the SSH clone base32 from them. If you have an SSH clone base32, substitute it for the base32 in this step, which will fail. {%- endtrans %}</p>
<figure>
<img src="/_static/images/git/wizard3.png" alt="" /><figcaption>gittest.i2p</figcaption>
</figure>
<p>{% trans -%} Pick a port to forward the I2P service to locally. {%- endtrans %}</p>
<figure>
<img src="/_static/images/git/wizard4.png" alt="" /><figcaption>localhost:localport</figcaption>
</figure>
<p>{% trans -%} I use it alot, so I start my client tunnel automatically, but it’s up to you. {%- endtrans %}</p>
<figure>
<img src="/_static/images/git/wizard5.png" alt="" /><figcaption>Auto Start</figcaption>
</figure>
<p>{% trans -%} When you’re all done, it should look alot like this. {%- endtrans %}</p>
<figure>
<img src="/_static/images/git/wizard6.png" alt="" /><figcaption>Review settings</figcaption>
</figure>
<h2 id="trans--fourth-attempt-a-clone--endtrans">{% trans -%}Fourth: Attempt a clone{%- endtrans %}</h2>
<p>{% trans -%}Now your tunnel is all set up, you can attempt a clone over SSH.{%- endtrans %}</p>
<pre><code>GIT_SSH_COMMAND=&quot;ssh -p 7442&quot; \
git clone git@127.0.0.1:i2p-developer/i2p.i2p</code></pre>
<p>{% trans -%} You might get an error where the remote end hangs up unexpectedly. Unfortunately git still doesn’t support resumable cloning. Until it does, there are a couple fairly easy ways to handle this. The first and easiest is to try and clone to a shallow depth: {%- endtrans %}</p>
<pre><code>GIT_SSH_COMMAND=&quot;ssh -p 7442&quot; \
git clone --depth 1 git@127.0.0.1:i2p-developer/i2p.i2p</code></pre>
<p>{% trans -%} Once you’ve performed a shallow clone, you can fetch the rest resumably by changing to the repo directory and running: {%- endtrans %}</p>
<pre><code>git fetch --unshallow</code></pre>
<p>{% trans -%} At this point, you still don’t have all your branches yet. You can get them by running the following commands: {%- endtrans %}</p>
<pre><code>git config remote.origin.fetch &quot;+refs/heads/*:refs/remotes/origin/*&quot;
git fetch origin</code></pre>
<p>{% trans -%} Which tells git to alter the repository configuration so that fetching from origin fetches all branches. {%- endtrans %}</p>
<p>{% trans -%} If that doesn’t work, you can try opening the tunnel configuration menu and adding some backup tunnels. {%- endtrans %}</p>
<figure>
<img src="/_static/images/git/tweak2.png" alt="" /><figcaption>Backup Tunnels</figcaption>
</figure>
<p>{% trans -%} If that doesn’t work, then the next easy thing to try is to decrease the tunnel length. Don’t do this if you believe you are at risk of your code-contribution activity being de-anonymized by a well-resourced attacker seeking to run many malicious nodes and control your whole path. If that sounds unlikely to you then you can probably do it safely. {%- endtrans %}</p>
<figure>
<img src="/_static/images/git/tweak1.png" alt="" /><figcaption>One-Hop Tunnels</figcaption>
</figure>
<h2 id="trans--suggested-workflow-for-developers--endtrans">{% trans -%}<em>Suggested Workflow for Developers!</em>{%- endtrans %}</h2>
<p>{% trans -%} Revision control can make your life easier, but it works best if you use it well! In light of this, we strongly suggest a fork-first, feature-branch workflow as many are familiar with from Github. In such a workflow, the master branch is used as a sort of “Trunk” for updates and is never touched by the programmmer, instead, all changes to the master are merged from branches. In order to do set up your workspace for this, take the following steps:{%- endtrans %}</p>
<ul>
<li>{% trans -%}<strong>Never make changes to the Master Branch</strong>. You will be using the master branch to periodially obtain updates to the official source code. All changes should be made in feature branches.{%- endtrans %}</li>
</ul>
<ol type="1">
<li><p>{% trans -%}Set up a second remote in your local repository using the upstream source code.{%- endtrans %}</p>
<pre><code>git remote add upstream git@127.0.0.1:i2p-hackers/i2p.i2p</code></pre></li>
<li><p>{% trans -%}Pull in any upstream changes on your current master:{%- endtrans %}</p>
<pre><code>git pull upstream master</code></pre></li>
<li><p>{% trans -%}Before making any changes to the source code, check out a new feature branch to develop on:{%- endtrans %}</p>
<pre><code>git checkout -b feature-branch-name</code></pre></li>
<li><p>{% trans -%}When you’re done with your changes, commit them and push them to your branch{%- endtrans %}</p>
<pre><code>git commit -am &quot;I added an awesome feature!&quot;
git push origin feature-branch-name</code></pre></li>
<li><p>{% trans -%}Submit a merge request. When the merge request is approved and brought into the upstream master, check out the master locally and pull in the changes:{%- endtrans %}</p>
<pre><code>git checkout master
git pull upstream master</code></pre></li>
<li><p>{% trans -%}Whenever a change to the upstream master(i2p-hackers/i2p.i2p) is made, you can update your master code using this procedure as well.{%- endtrans %}</p>
<pre><code>git checkout master
git pull upstream master</code></pre></li>
</ol>
{% endblock %}
i2p2www/pages/site/docs/applications/gitlab.html 0 → 100644
+ 95
− 0
View file @ 55ca6792
{% extends "global/layout.html" %}
{% block title %}{% trans %}Setting up Gitlab with I2P{% endtrans %}{% endblock %}
{% block lastupdated %}2020-09{% endblock %}
{% block accuratefor %}0.9.47{% endblock %}
{% block content %}
<h1 id="gitlab-over-i2p-setup">{% trans -%}Gitlab over I2P Setup{%- endtrans %}</h1>
<div class="meta" data-author="idk" data-date="2020-03-16" data-excerpt="{% trans -%}Mirror I2P Git repositories and Bridge Clearnet repositories for others.{%- endtrans %}">
</div>
<p>{% 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 %}</p>
<h2 id="dependencies-and-docker">{% trans -%}Dependencies and Docker{%- endtrans %}</h2>
<p>{% 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 %}</p>
<pre><code>sudo apt install docker.io</code></pre>
<p>{% trans -%} on an otherwise unmodified Debian system, or if you have added Docker’s own “Community” Debian repository, you may use: {%- endtrans %}</p>
<pre><code>sudo apt install docker-ce</code></pre>
<p>{% trans -%} instead. {%- endtrans %}</p>
<h3 id="fetch-the-docker-containers">{% trans -%}Fetch the Docker Containers{%- endtrans %}</h3>
<p>{% trans -%} Once you have docker installed, you can fetch the docker containers required for gitlab. <em>Don’t run them yet.</em> {%- endtrans %}</p>
<pre><code>docker pull gitlab/gitlab-ce</code></pre>
<p>{% 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 <a href="https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/master/docker/Dockerfile">Gitlab source code</a>. {%- endtrans %}</p>
<h2 id="set-up-an-i2p-http-proxy-for-gitlab-to-useimportant-information-optional-steps">{% trans -%}Set up an I2P HTTP Proxy for Gitlab to use(Important information, optional steps){%- endtrans %}</h2>
<p>{% 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 <em>not allowed</em> 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 %}</p>
<p>{% trans -%} In the case where the Gitlab server is <em>allowed</em> 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 <em>is not anonymous</em> in this case. Git services on the non-anonymous internet will be connected to directly. {%- endtrans %}</p>
<p>{% trans -%} <strong>If you want to have a bridged, non-anonymous Gitlab instance with access to</strong> <strong>web repositories,</strong> no further modification is necessary. {%- endtrans %}</p>
<p>{% trans -%} <strong>If you want to have an I2P-Only Gitlab instance with no access to Web-Only</strong> <strong>Repositories</strong>, you will need to configure Gitlab to use an I2P HTTP Proxy. Since the default I2P HTTP proxy only listens on <code>127.0.0.1</code>, 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 <code>172.17.0.1</code>. I configure mine on port <code>4446</code>. {%- endtrans %}</p>
<h2 id="start-the-container-locally">{% trans -%}Start the Container Locally{%- endtrans %}</h2>
<p>{% trans -%} Once you have that set up, you can start the container and publish your Gitlab instance locally. {%- endtrans %}</p>
<pre><code>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</code></pre>
<p>{% 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 %}</p>
<h2 id="modify-gitlab.rboptional-but-a-good-idea-for-bridged-non-anonymous-hosts">{% trans -%}Modify gitlab.rb(Optional, but a good idea for “Bridged non-anonymous” hosts){%- endtrans %}</h2>
<p>{% 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 %}</p>
<p>{% 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 %}</p>
<pre><code>gitlab_rails[&#39;env&#39;] = {
&quot;http_proxy&quot; =&gt; &quot;http://172.17.0.1:4446&quot;,
&quot;https_proxy&quot; =&gt; &quot;http://172.17.0.1:4446&quot;,
&quot;no_proxy&quot; =&gt; &quot;.github.com,.gitlab.com&quot;
}
gitaly[&#39;env&#39;] = {
&quot;http_proxy&quot; =&gt; &quot;http://172.17.0.1:4446&quot;,
&quot;https_proxy&quot; =&gt; &quot;http://172.17.0.1:4446&quot;,
&quot;no_proxy&quot; =&gt; &quot;unix,.github.com,.gitlab.com&quot;
}
gitlab_workhorse[&#39;env&#39;] = {
&quot;http_proxy&quot; =&gt; &quot;http
&quot;https_proxy&quot; =&gt; &quot;http://172.17.0.1:4446&quot;,
&quot;no_proxy&quot; =&gt; &quot;unix,.github.com,.gitlab.com&quot;
}</code></pre>
<h3 id="set-up-your-service-tunnels-and-sign-up-for-a-hostname">{% trans -%}Set up your Service tunnels and sign up for a Hostname{%- endtrans %}</h3>
<p>{% 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 %}</p>
<h4 id="gitlab-webhttp-interface">{% trans -%}Gitlab Web(HTTP) Interface{%- endtrans %}</h4>
<p>{% trans -%} For the Web interface, use an “HTTP” server tunnel. From <a href="http://127.0.0.1:7657/i2ptunnelmgr">http://127.0.0.1:7657/i2ptunnelmgr</a> launch the “New Tunnel Wizard” and enter the following values at each step: {%- endtrans %}</p>
<ol type="1">
<li>{% trans -%}Select “Server Tunnel”{%- endtrans %}</li>
<li>{% trans -%}Select “HTTP Server”{%- endtrans %}</li>
<li>{% trans -%}Fill in “Gitlab Web Service” or otherwise describe the tunnel{%- endtrans %}</li>
<li>{% trans -%}Fill in <code>127.0.0.1</code> for the host and <code>8080</code> for the port.{%- endtrans %}</li>
<li>{% trans -%}Select “Automatically start tunnel when Router Starts”{%- endtrans %}</li>
<li>{% trans -%}Confirm your selections.{%- endtrans %}</li>
</ol>
<h5 id="register-a-hostnameoptional">{% trans -%}Register a Hostname(Optional){%- endtrans %}</h5>
<p>{% trans -%} Web services on I2P can register hostnames for themselves by providing an authentication string to a jump service provider like <a href="http://stats.i2p">stats.i2p</a>. To do this, open the <a href="http://127.0.0.1:7657/i2ptunnelmgr">http://127.0.0.1:7657/i2ptunnelmgr</a> 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 <a href="http://stats.i2p/i2p/addkey.html">stats.i2p</a> 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 %}</p>
<h4 id="gitlab-ssh-interface">{% trans -%}Gitlab SSH Interface{%- endtrans %}</h4>
<p>{% trans -%} For the SSH interface, use a “Standard” server tunnel. From <a href="http://127.0.0.1:7657/i2ptunnelmgr">http://127.0.0.1:7657/i2ptunnelmgr</a> launch the “New Tunnel Wizard” and enter the following values at each step: {%- endtrans %}</p>
<ol type="1">
<li>{% trans -%}Select “Server Tunnel”{%- endtrans %}</li>
<li>{% trans -%}Select “Standard Server”{%- endtrans %}</li>
<li>{% trans -%}Fill in “Gitlab SSH Service” or otherwise describe the tunnel{%- endtrans %}</li>
<li>{% trans -%}Fill in <code>127.0.0.1</code> for the host and <code>8022</code> for the port.{%- endtrans %}</li>
<li>{% trans -%}Select “Automatically start tunnel when Router Starts”{%- endtrans %}</li>
<li>{% trans -%}Confirm your selections.{%- endtrans %}</li>
</ol>
<h2 id="re-start-the-gitlab-service-with-the-new-hostname">{% trans -%}Re-start the Gitlab Service with the new Hostname{%- endtrans %}</h2>
<p>{% trans -%} Finally, if you either modified <code>gitlab.rb</code> or you registered a hostname, you will need to re-start the gitlab service for the settings to take effect. {%- endtrans %}</p>
<pre><code>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</code></pre>
{% endblock %}
i2p2www/static/images/git/register.png
+ 0
− 0
View replaced file @ 70693b73 View file @ 55ca6792
i2p2www/static/images/git/register.png

62.4 KiB | W: | H:

i2p2www/static/images/git/register.png

121 KiB | W: | H:

i2p2www/static/images/git/register.png
i2p2www/static/images/git/register.png
i2p2www/static/images/git/register.png
i2p2www/static/images/git/register.png
  • 2-up
  • Swipe
  • Onion skin
i2p2www/static/images/git/wizard4.png
+ 0
− 0
View replaced file @ 70693b73 View file @ 55ca6792
i2p2www/static/images/git/wizard4.png

35.9 KiB | W: | H:

i2p2www/static/images/git/wizard4.png

43 KiB | W: | H:

i2p2www/static/images/git/wizard4.png
i2p2www/static/images/git/wizard4.png
i2p2www/static/images/git/wizard4.png
i2p2www/static/images/git/wizard4.png
  • 2-up
  • Swipe
  • Onion skin
i2p2www/static/images/git/wizard6.png
+ 0
− 0
View replaced file @ 70693b73 View file @ 55ca6792
i2p2www/static/images/git/wizard6.png

69.2 KiB | W: | H:

i2p2www/static/images/git/wizard6.png

80.6 KiB | W: | H:

i2p2www/static/images/git/wizard6.png
i2p2www/static/images/git/wizard6.png
i2p2www/static/images/git/wizard6.png
i2p2www/static/images/git/wizard6.png
  • 2-up
  • Swipe
  • Onion skin
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment

Base32 Address: [http://7qeve4v2chmjdqlwpa3vl7aojf3nodbku7vepnjwrsxljzqipz6a.b32.i2p] Onion Address: [http://47ggr2fa3vnwfyhvgskzdmr3i32eijwymxohtxsls45dulmriwxszjad.onion]