diff options
author | luxagraf <sng@luxagraf.net> | 2020-08-13 16:26:13 -0400 |
---|---|---|
committer | luxagraf <sng@luxagraf.net> | 2020-08-13 16:26:13 -0400 |
commit | c657feb58769c1f975af2f2ab4968da1b1e42158 (patch) | |
tree | a1bf11fbaedb094c480ebbdc9e4e0d83508b1090 /tech/set up gitea on ubuntu 18.04.txt | |
parent | 0d1cba91e435b1d613735d4537a64673e5c2731d (diff) |
added reading moved tech to folder cleaned up old notes
Diffstat (limited to 'tech/set up gitea on ubuntu 18.04.txt')
-rw-r--r-- | tech/set up gitea on ubuntu 18.04.txt | 233 |
1 files changed, 233 insertions, 0 deletions
diff --git a/tech/set up gitea on ubuntu 18.04.txt b/tech/set up gitea on ubuntu 18.04.txt new file mode 100644 index 0000000..6d1870b --- /dev/null +++ b/tech/set up gitea on ubuntu 18.04.txt @@ -0,0 +1,233 @@ +I've never liked hosting my git repos on someone else's servers. GitHub especially is not a company I'd do business with, ever. I do have a repo or two hosted over at [GitLab](https://gitlab.com/luxagraf) because those are projects I want to be easily available to anyone. But I store almost everything in git -- notes, my whole documents folder, all my code projects, all my writing, pretty much everything is in git -- but I like to keep all that private and on my own server. + +For years I used [Gitlist](http://gitlist.org/) because it was clean, simple, and did 95 percent of what I needed in a web-based interface for my repos. But Gitlist is abandonware at this point and broken if you're using PHP 7.2. There are few forks that [patch it](https://github.com/patrikx3/gitlist), but it's copyrighted to the original dev and I don't want to depend on illegitimate forks for something so critical to my workflow. Then there's self-hosted Gitlab, which I like, but the system requirements are ridiculous. + +Some searching eventually led me to Gitea, which is lightweight, written in Go and has everything I need. + +Here's a quick guide to getting Gitea up and running on your Ubuntu 18.04 -- or similar -- VPS. + +### Set up Gitea + +The first thing we're going to do is isolate Gitea from the rest of our server, running it under a different user seems to be the standard practice. Installing Gitea via the Arch User Repository will create a `git` user, so that's what I used on Ubuntu 18.04 as well. + +Here's a shell command to create a user named `git`: + +~~~~console +sudo adduser --system --shell /bin/bash --group --disabled-password --home /home/git git +~~~~ + +This is pretty much a standard adduser command such as you'd use when setting up a new VPS, the only difference is that we've added the `--disable-password` flag so you can't actually log in with it. While we will use this user to authenticate over SSH, we'll do so with a key, not a password. + +Now we need to grab the latest Gitea binary. At the time of writing that's version 1.5.2, but be sure to check the [Gitea downloads page](https://dl.gitea.io/gitea/) for the latest version and adjust the commands below to work with that version number. Let's download the Gitea binary and then we'll verify the signing key. Verifying keys is very important when working with binaries since you can't see the code behind them[^1]. + +~~~~console +wget -O gitea https://dl.gitea.io/gitea/1.5.2/gitea-1.5.2-linux-amd64 +gpg --keyserver pgp.mit.edu --recv 0x2D9AE806EC1592E2 +wget https://dl.gitea.io/gitea/1.5.2/gitea-1.5.2-linux-amd64.asc +gpg --verify gitea-1.5.2-linux-amd64.asc gitea +~~~~ + +A couple of notes here, GPG should say the keys match, but then it should also warn that "this key is not certified with a trusted signature!" That means, essentially, that this binary could have been signed by anybody. All we know for sure is that wasn't tampered with in transit[^1]. + +Now let's make the binary executable and test it to make sure it's working: + +~~~~console +chmod +x gitea +./gitea web +~~~~ + +You can stop Gitea with `Ctrl+C`. Let's move the binary to a more traditional location: + +~~~~console +sudo cp gitea /usr/local/bin/gitea +~~~~ + +The next thing we're going to do is create all the directories we need. + +~~~~console +sudo mkdir -p /var/lib/gitea/{custom,data,indexers,public,log} +sudo chown git:git /var/lib/gitea/{data,indexers,log} +sudo chmod 750 /var/lib/gitea/{data,indexers,log} +sudo mkdir /etc/gitea +sudo chown root:git /etc/gitea +sudo chmod 770 /etc/gitea +~~~~ + +That last line should make you nervous, that's too permissive for a public directory, but don't worry, as soon as we're done setting up Gitea we'll change the permissions on that directory and the config file inside it. + +Before we do that though let's create a systemd service file to start and stop Gitea. The Gitea project has a service file that will work well for our purposes, so let's grab it, make a couple changes and then we'll add it to our system: + +~~~~console +wget https://raw.githubusercontent.com/go-gitea/gitea/master/contrib/systemd/gitea.service +~~~~ + +Now open that file and uncomment the line `After=postgresql.service` so that Gitea starts after postgresql is running. The resulting config file should look like this: + +~~~~ini +[Unit] +Description=Gitea (Git with a cup of tea) +After=syslog.target +After=network.target +#After=mysqld.service +After=postgresql.service +#After=memcached.service +#After=redis.service + +[Service] +# Modify these two values and uncomment them if you have +# repos with lots of files and get an HTTP error 500 because +# of that +### +#LimitMEMLOCK=infinity +#LimitNOFILE=65535 +RestartSec=2s +Type=simple +User=git +Group=git +WorkingDirectory=/var/lib/gitea/ +ExecStart=/usr/local/bin/gitea web -c /etc/gitea/app.ini +Restart=always +Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea +# If you want to bind Gitea to a port below 1024 uncomment +# the two values below +### +#CapabilityBoundingSet=CAP_NET_BIND_SERVICE +#AmbientCapabilities=CAP_NET_BIND_SERVICE + +[Install] +WantedBy=multi-user.target +~~~~ + +Now we need to move the service file to somewhere systemd expects it and then start and enable the service so Gitea will launch automatically when the server boots. + +~~~~console +sudo cp gitea.service /etc/systemd/system/ +sudo systemctl enable gitea +sudo systemctl start gitea +~~~~ + +There you have it, Gitea is installed, running and will automatically start whenever we restart the server. Now we need to set up Postgresql and then Nginx to serve up our Gitea site to the world. Or at least to us. + +### Setup a Postgresql and Nginx + +Gitea needs a database to store all our data in; I use PostgreSQL. You can also use MySQL, but you're on your own there. Install PostgreSQL if you haven't already: + +~~~~console +sudo apt install postgresql +~~~~ + +Now let's create a new user and database for Gitea: + +~~~~console +sudo su postgres +createuser gitea +createdb gitea -O gitea +~~~~ + +Exit the postgres user shell by hitting `Ctrl+D`. + +Now let's set up Nginx to serve our Gitea site. + +~~~~console +sudo apt update +sudo apt install nginx +~~~~ + +For the next part you'll need a domain name. I use a subdomain, git.mydomain.com, but for simplicity sake I'll refer to `mydomain.com` for the rest of this tutorial. Replace `mydomain.com` in all the instructions below with your actual domain name. + +We need to create a config file for our domain. By default Nginx will look for config files in `/etc/nginx/sites-enabled/`, so the config file we'll create is: + +~~~~console +nano /etc/nginx/sites-enabled/mydomain.com.conf +~~~~ + +Here's what that file looks like: + +~~~~nginx +server { + listen 80; + listen [::]:80; + server_name <mydomain.com>; + + + location / { + proxy_pass http://localhost:3000; + } + + proxy_set_header X-Real-IP $remote_addr; +} +~~~~ + +The main line here is the `proxy_pass` bit, which takes all requests and sends it to gitea, which is listening on `localhost:3000` by default. You can change that if you have something else that conflicts with it, but you'll need to change it here and in the service file that we used to start Gitea. + +The last step is to add an SSL cert to our site so we can clone over https (and SSH if you keep reading). I have another tutorial on setting up [Certbot for Nginx on Ubuntu](/src/certbot-nginx-ubuntu-1804). You can use that to get Certbot installed and auto-renewing certs. Then all you need to do is run: + +~~~~console +sudo certbot --nginx +~~~~ + +Select your Gitea domain, follow the prompts and when you're done you'll be ready to set up Gitea. + +### Setting up Gitea + +Point your browser to `https://mydomain.com/install` and go through the Gitea setup process. That screen looks like this, and you can use these values, except for the domain name (and be sure to enter the password you used when we created the `gitea` user for postgresql). + +One note, if you intend your Gitea instance to be for you alone, I strongly recommend you check the "disable self registration" box, which will stop anyone else from being able to sign up. But, turning off registration means you'll need to create an administrator account at the bottom of the page. + +<img src="images/2018/gitea-install_FAW0kIJ.jpg" id="image-1706" class="picwide" /> + +Okay, now that we've got Gitea initialized it's time to go back and change the permissions on those directories that we set up earlier. + +~~~~console +sudo chmod 750 /etc/gitea +sudo chmod 644 /etc/gitea/app.ini +~~~~ +Now you're ready to create your first repo in Gitea. Click the little button next to the repositories menu on the right side of your Gitea dashboard and that'll walk you through creating your first repo. Once that's done you can clone that repo with: + +~~~~console +git clone https://mydomain.com/giteausername/reponame.git +~~~~ + +Now if you have an existing repo that you want to push to your new Gitea repo, just edit the `.git/config` files to make your Gitea repo the new url, e.g.: + +~~~~ini +[remote "origin"] + url = https://mydomain.com/giteausername/reponame.git + fetch = +refs/heads/*:refs/remotes/origin/* +~~~~ + +Now do this: + +~~~~console +git push origin master +~~~~ + +### Setting up SSH + +Working with git over https is pretty good, but I prefer the more secure method of SSH with a key. To get that working we'll need to add our SSH key to Gitea. That means you'll need a GPG key. If you don't have one already, open the terminal on your local machine and issue this command: + +~~~~console +ssh-keygen -o -a 100 -t ed25519 +~~~~ + +That will create a key named `id_ed25519` in the directory `.ssh/`. If you want to know where that command comes from, read [this article](https://blog.g3rt.nl/upgrade-your-ssh-keys.html). + +Now we need to add that key to Gitea. First open the file `.ssh/id_ed25519.pub` and copy the contents to your clipboard. Now in the Gitea web interface, click on the user menu at the upper right and select "settings". Then across the top you'll see a bunch of tabs. Click the one that reads "SSH / GPG Keys". Click the add key button, give your key a name and paste in the contents of the key. + +Note: depending on how your VPS was set up, you may need to add the `git` user to your sshd config. Open `/etc/ssh/sshd_config` and look for a line that reads something like this: + +~~~~console +AllowUsers myuser myotheruser git +~~~~ + +Add `git` to the list of allowed users so you'll be able to authenticate with the git user over ssh. Now test SSH cloning with this line, substituting your SSH clone url: + +~~~~console +git clone ssh://git@mydomain/giteausername/reponame.git +~~~~ + +Assuming that works then you're all set, Gitea is working and you can create all the repos you need. If you have any problems you can drop a comment in the form below and I'll do my best to help you out. + +If you want to add some other niceties, the Gitea docs have a good guide to [setting up Fail2Ban for Gitea](https://docs.gitea.io/en-us/fail2ban-setup/) and then there's a whole section on [backing up Gitea](https://docs.gitea.io/en-us/backup-and-restore/) that's well worth a read. + +[^1]: You can compile Gitea yourself if you like, there are [instructions on the Gitea site](https://docs.gitea.io/en-us/install-from-source/), but be forewarned its uses quite a bit of RAM to build. |