1 files changed, 135 insertions, 0 deletions
diff --git a/drafts/posts/adding-cgit-subdomain-to-personal-site.md b/drafts/posts/adding-cgit-subdomain-to-personal-site.md
new file mode 100644
index 0000000..a302b0e
--- /dev/null
+++ b/drafts/posts/adding-cgit-subdomain-to-personal-site.md
@@ -0,0 +1,135 @@
++++
+title = "Adding a CGit web interface"
+tags = ["linux", "nginx", "certbot"]
+summary = """
+
+Here I document my experience setting up CGit on my VPS.
+
+"""
++++
+
+# Motivation
+
+To update the content of my blog, I have to do something of a dance. I
+like versioning my blog's *content* as a separate Git repo,
+independent of the SSG that manages its final layout, rendering,
+styling, etc. So right now what I'm doing is this:
+
+1. Commit all changes.
+2. Push the changes to GitHub, where it's currently hosted in a
+   somewhat centralized manner.
+3. Log in via SSH into my VPS.
+4. Navigate to the cloned version of the blog repo that lives there,
+   and run `git pull`.
+
+However, I thought, "wouldn't it be nice if I could push **directly**
+to the VPS repo?" And so I started working on that idea in the obvious
+manner: add the VPS repo as a remote, such that I would be pushing to
+`vps/main` alongside of `origin/main` (where `origin` points to
+GitHub).
+
+It turns out that this alone is a shade more complicated that it would
+seem: I had to first add a new `git` user (see [this tutorial](https://landchad.net/git/)),
+and then adjust my SSH configuration appropriately to allow for this
+pseudo-user to log in via SSH (since I would be pushing into a
+directory now owned by it.)
+
+I quickly learned, to my dismay, that I couldn't push to the VPS
+remote if it's not a bare repo. A bare repo is one initialized with
+`git init --bare`, so that it doesn't have a working directory
+populated with files. However, the buildablog server does expect to
+see a working directory with blog files (not just blobs, for example),
+so this doesn't solve my problem.
+
+# Cgit
+
+What I ended up doing in the end didn't solve this problem, but it
+ended up becoming an interesting rabbit hole in its own right.
+
+I ended up adding the Cgit web interface to my site, available via
+<https://git.brandonirizarry.xyz>. I checked out a [tutorial](https://landchad.net/cgit/) on
+how to do it, but their suggested Nginx setup was off in some
+parts. 
+
+After a ton of false starts, I ended up doing the following. Note that
+this assumes that you've already followed the aforementioned tutorial
+on setting up your `git` user and its home directory. As a quick addon
+to that, I suggest adjusting the permissions for the `/var/git`
+directory to 775 (I had initially found they were set to 770.) This
+allows the Cgit web interface to actually read and display your hosted
+repos, which is after all the point.
+
+1. Add two new *external records* for `git.brandonirizarry.xyz` to my
+   site's DNS configuration over on Epik: the A (IPv4) and AAAA (IPv6)
+   records, per usual if you're already somewhat familiar with this
+   thing.
+
+2. Start out with the `http` version of the site you're serving. Not
+   only does this make adding the TLS certificate later on painless,
+   you can immediately verify that your new subdomain is, in fact,
+   being hosted. Add the following server block to whatever nginx
+   configuration you have published as your website, and then reload
+   the nginx configuration with something like `sudo systemctl restart
+   nginx.service`:
+
+```
+server {
+    listen 80;
+    listen [::]:80;
+
+    # Replace this with your actual site.
+    server_name git.example.org;
+
+    root /usr/share/cgit ;
+    try_files $uri @cgit ;
+
+    location ~ /.+/(info/refs|git-upload-pack) {
+        include             fastcgi_params;
+        fastcgi_param       SCRIPT_FILENAME /usr/lib/git-core/git-http-backend;
+        fastcgi_param       PATH_INFO           $uri;
+        fastcgi_param       GIT_HTTP_EXPORT_ALL 1;
+
+        # This part assumes your git user's home directory is /var/git.
+        fastcgi_param       GIT_PROJECT_ROOT    /var/git;
+        fastcgi_param       HOME                /var/git;
+        fastcgi_pass        unix:/run/fcgiwrap.socket;
+    }
+
+    location @cgit {
+        include fastcgi_params;
+        fastcgi_param SCRIPT_FILENAME /usr/lib/cgit/cgit.cgi;
+        fastcgi_param PATH_INFO $uri;
+        fastcgi_param QUERY_STRING $args;
+        fastcgi_param HTTP_HOST $server_name;
+        fastcgi_pass unix:/run/fcgiwrap.socket;
+    }
+}
+```
+
+3. Add a TLS certificate for your subdomain. I admit that I took a
+   someone nonlinear path in achieving my setup, but this should be as
+   simple as running `sudo certbot --nginx`, and then selecting your
+   subdomain from the menu options. Here I'm assuming you've already
+   gotten a certificate for your main site, hence you only need one
+   for your new subdomain.
+   
+From there you shouldn't even have to restart Nginx: you should see
+that your subdomain is available over `https`.
+
+# Five Strikes and You're Out
+
+I learned, through banging my head against various misconfigurations
+(both from the DNS and Nginx sides), that Let's Encrypt (what Certbot
+uses to issue the certificate) [imposes a rate limit](https://letsencrypt.org/docs/rate-limits/#authorization-failures-per-identifier-per-account) on
+certificate issues per identifier, which doesn't forgive botched
+certificates. The solution here is to run Certbot with the
+`--test-cert` flag, which uses Let's Encrypt's staging area, which has
+no such draconian rate limit.
+
+   
+   
+    
+    
+    
+
+