added gitea and nextcloud syncing

1 files changed, 26 insertions, 24 deletions

diff --git a/set up gitea on ubuntu 18.04.txt b/set up gitea on ubuntu 18.04.txt
index 33ded6c..6d1870b 100644
--- a/set up gitea on ubuntu 18.04.txt
+++ b/set up gitea on ubuntu 18.04.txt
@@ -1,6 +1,6 @@
-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 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.
+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 Gitlab, which I like, but the system requirements are ridiculous.
+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. 
 
@@ -10,15 +10,15 @@ Here's a quick guide to getting Gitea up and running on your Ubuntu 18.04 -- or
 
 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 do that:
+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 like 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. That's a bit more secure and while we will use this user to authenticate over SSH, we'll do so with a key, not a password.
+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 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].
+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
@@ -27,7 +27,7 @@ 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. That should make you nervous, but at least we know it wasn't tampered with in transit[^1].
+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:
 
@@ -42,7 +42,7 @@ You can stop Gitea with `Ctrl+C`. Let's move the binary to a more traditional lo
 sudo cp gitea /usr/local/bin/gitea
 ~~~~
 
-The next thing we're going to be is create all the directories we need. 
+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}
@@ -55,7 +55,7 @@ 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 an 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:
+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 
@@ -98,7 +98,7 @@ Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea
 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 up.
+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/
@@ -106,11 +106,11 @@ sudo systemctl enable gitea
 sudo systemctl start gitea
 ~~~~
 
-There you have it, Gitea is installed, running and will automatically boot 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.
+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:
+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
@@ -124,16 +124,18 @@ 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. 
+Exit the postgres user shell by hitting `Ctrl+D`. 
 
-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.
+Now let's set up Nginx to serve our Gitea site. 
 
 ~~~~console
 sudo apt update
 sudo apt install nginx
 ~~~~
 
-Now we need to create a config file for this domain. By default Nginx will look for config files in `/etc/nginx/sites-enabled/`, so the config file we'll create is:
+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
@@ -156,7 +158,7 @@ server {
 }
 ~~~~
 
-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 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:
 
@@ -164,23 +166,23 @@ The last step is to add an SSL cert to our site so we can clone over https (and
 sudo certbot --nginx
 ~~~~
 
-Select your gitea domain, follow the prompts and when you're done you'll be read to set up Gitea. 
+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, I strongly recommend check the "disable self registration" box, which means you'll need to create an administrator account at the bottom of the page, but will stop anyone else from being able to sign up.
+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 their directories that we set up earlier.
+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
 ~~~~
-Okay, now you can create your first repo. 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:
+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
@@ -202,23 +204,23 @@ git push origin master
 
 ### Setting up SSH
 
-Working with git over https is pretty good, but I prefer the more secure method of SSH. 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:
+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).
+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 we interface, click on the user menu link 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.
+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.
 
-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:
+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 so you'll be able to authenticate with the git user over ssh. Now test SSH cloning with this line, subsituting your SSH clone url:
+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