diff options
| -rw-r--r-- | drafts/posts/adding-cgit-subdomain-to-personal-site.md | 136 |
1 files changed, 98 insertions, 38 deletions
diff --git a/drafts/posts/adding-cgit-subdomain-to-personal-site.md b/drafts/posts/adding-cgit-subdomain-to-personal-site.md index a302b0e..70af4a5 100644 --- a/drafts/posts/adding-cgit-subdomain-to-personal-site.md +++ b/drafts/posts/adding-cgit-subdomain-to-personal-site.md @@ -1,26 +1,25 @@ +++ -title = "Adding a CGit web interface" +title = "Adding a CGit Subdomain To My Site" tags = ["linux", "nginx", "certbot"] -summary = """ - -Here I document my experience setting up CGit on my VPS. - -""" +summary = "Setting up CGit on my VPS." +date = 2026-03-06 +++ # 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: +To update the content of my blog, I have to do something of a +dance. My blog's content started out life as a subdirectory of my SSG +project, but now lives in its own separate Git repo. This is super +convenient since I now can host my blog wherever I want on my VPS's +filesystem, for example in a folder called `brandons_blog`. 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`. +4. Perform a `cd` into the `brandons_blog` directory, 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 @@ -37,9 +36,9 @@ 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. +populated with files. However, the buildablog server expects to see a +working directory with blog files (not just blobs, for example), so +this doesn't solve my problem. # Cgit @@ -51,26 +50,30 @@ I ended up adding the Cgit web interface to my site, available via 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. +After a ton of false starts, I ended up doing slightly different. 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. + +Here's what I did. I'm phrasing these in the imperative mood since it +reads better than beginning everything with "I" + past-tense, and the +steps themselves are also suitable as a potential HOWTO for my future +self: 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`: +2. Start out by adding the Nginx configuration of the `http` version + of the site. 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 your published Nginx configuration, and then reload Nginx + (e.g. `sudo systemctl restart nginx.service`): ``` server { @@ -107,11 +110,11 @@ server { ``` 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. + somewhat 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 need a + certificate only for your new subdomain. From there you shouldn't even have to restart Nginx: you should see that your subdomain is available over `https`. @@ -121,10 +124,67 @@ that your subdomain is available over `https`. 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. +certificate issues per identifier (five per hour), which doesn't +forgive botched attempts at certificate registration. The solution +here is to run Certbot with the `--test-cert` flag, which uses Let's +Encrypt's staging area, which has a much more forgiving rate limit. + +In digging a bit through the Let's Encrypt [forums](https://community.letsencrypt.org/), I learned +about two super helpful sites for debugging DNS and certificate +issues: + +1. <https://letsdebug.net> + + Super helpful for figuring out issues with bad certificates. + +2. <https://dnsviz.net> + + For debugging a site's DNS config, which I was messing up since I + wasn't sure in the beginning how to properly add a subdomain to my + DNS records (somewhat confusingly, Epik places the word + "subdomain" alongside the CNAME section, making me think CNAME had + something to do with it, which it doesn't.) + +# A Ghost in the Machine? + +I finally managed to [host](https://git.brandonirizarry.xyz) my Cgit dashboard on my site, which +currently contains only my blog repo. I even managed to share the link +with a friend of mine, who was successfully able to view it from their +end. + +However, when going through some exercises in *The Go Programming +Language* (a story for another time), I happened to cavalierly make a +GET request to that subdomain, which then reported a TLS error. In my +mind this seemed somewhat bonkers, since, after all, everything was +already up and running, no? So late that evening I had to jump back +onto the VPS and do some bespoke troubleshooting. + +It looked like there were some redundant server blocks in my Nginx +config file that were added while I was throwing everything and the +kitchen sink at getting a valid TLS certificate. So what I did in the +end was remove everything Certbot had added concerning my `git` +subdomain, essentially reverting back to just the server block shown +just above, and repeating those exact steps — including first +verifying service over `http`. This part of the process for me was the +most satisfying, since it proves that the mere act of publishing a +website on the Web is, at its core, not all that difficult. One thing +different this time though was that, per the options Cerbot presents +you, it sufficed to reinstall the existing certificate, as opposed to +applying for a new one.) + +After that, everything was in order! I even checked the site the next +morning just to make sure it had stayed that way. To date, everything +looks good. + +# In the End... + +In the end, I didn't actually solve my initial problem, but still went +down an interesting rabbit hole, and now have a convenient tool at my +disposal — my own poor-man's GitHub — for personal use. For now, I may +well only use it for throwaway Go packages, in case I don't feel like +using workspaces. + + |