1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
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.
|
