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
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
|
Recently, someone retooted [this blog post](https://char.lt/blog/2026/09/sorcery-repo-viewer/) onto my Bluesky feed. I found it compelling; the scrapers haven't become a problem for me yet, but I also don't use 99% of the features my Forgejo instance provides, and I thought the program the article was about seemed cool. Besides, my Forgejo instance is running on my old domain, so I'll be needing to migrate all my repos at some point in the next two years anyway, so I might as well have some fun with it and switch hosting solutions while I'm at it.
Inconveniently for me, however, [Sorcery](https://git.t4t.associates/char/sorcery/) is certified Oomfware™ and doesn't have such luxuries as a pre-compiled binary to download or a professional install guide, so I guess if I want this sucker on my server I'm figuring that shit out myself. It's also designed for use with Nginx and not my current reverse proxy, Caddy, so I'll have to decipher the provided nginx config and port it over. I figured I may as well write all that down so you don't have to figure it out yourself.
# Git server
Sorcery is just a read-only frontend for your git repos, so we'll have to set up a git server to use it with. I'll just be setting up a basic ssh git server as described in the [official Git docs](https://git-scm.com/book/en/v2/Git-on-the-Server-Setting-Up-the-Server), but I'll copy the instructions over here for your convenience.
First, add a user on your server for the git server and switch to it:
```
adduser git
su git
cd
```
If you have ssh pubkey authentication set up (which you should) now's the time to enable it for the git user as well. I just did this by copying the contents of my `.ssh/authorized_keys` file into the git user's one at `/home/git/.ssh/authorized_keys`.
```
mkdir .ssh && chmod 700 .ssh
touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys
exit
nano ~/.ssh/authorized_keys
<copy the contents>
su git
nano ~/.ssh/authorized_keys
<paste, save and exit>
```
This is actually what I did.
Test to make sure ssh login works, and if it does, the git server is now technically set up. You can create repositories anywhere on the server that the `git` user has read/write permissions by creating a directory for the repo (convention dictates that you call it `repoName.git` but you don't have to) and initializing a bare repository in there:
```
mkdir reponame.git
cd reponame.git
git init --bare
```
Now you should be able to add it as a remote with `git remote add origin git@your.domain:/absolute/path/to/repoName.git` on your machine, or if you're lazy like me and just put your repositories in a folder in the git user's home directory, with `git remote add origin git@your.domain:relativePathTo/repoName.git`.
Sorcery expects a folder structure like this for your repositories:
```
reposFolder
├─userFolder
│ ├─repoName.git
│ └─repoName2.git
└─userFolder
```
Now on to the interesting part.
# Installing the fucker from source
Sorcery doesn't have a precompiled binary to use that I could find, so it has to be built from source. Due to the developer's choices, this will require the use of Nix. I'm installing and configuring it through the distro package manager on Ubuntu Server, so this part might be a little different for you if you're using something else.
First, naturally, Nix needs to be installed and the source code cloned:
```
apt install -y nix
git clone https://git.t4t.associates/char/sorcery
cd sorcery
```
If we try to `nix build` now, Nix is gonna give us some errors, so let's fix those. First, it'll complain about a couple of "experimental features" not being enabled. Enable the relevant ones by appending the following to `/etc/nix/nix.conf`:
```
experimental-features = nix-command flakes
```
If you're in my situation, that file should look like this after:
<p class="codetitle">/etc/nix/nix.conf</p>
```
# see https://nixos.org/manual/nix/stable/command-ref/conf-file
sandbox = true
experimental-features = nix-command flakes
```
Now it's probably gonna complain that you've been denied permission to get the status of some kind of daemon-socket. You can gain permission by adding yourself to the `nix-users` group, like so:
```
sudo usermod -a -G nix-users yourusername
```
Make sure to log out and back in after you do that.
Okay, *now* we can run `nix build` in the git repo to get our binary:
```
nix build
```
It'll show up inside the cloned repo at `result/bin/sorceryd`. Now move it somewhere that's not that — the Sorcery README suggests moving it to `/usr/local/bin/` "or whatever". Installing it there will make some pre-provided things like the systemd unit work with fewer changes, so I recommend you do that.
```
mv result/bin/sorceryd /usr/local/bin/
```
If you put it somewhere else, replace mentions of `/usr/local/bin/` accordingly.
# Reverse proxy configuration
The dev provides an nginx config for Sorcery through a script included in the repo that generates one. It's pretty elaborate, so I'm gonna have to run the script and reverse engineer its output to make a Caddy config. If you're using Nginx, I'm guessing this next part will be relevant to you. If you're using Caddy, skip ahead to where I provide the working Caddy config I used.
## Extracting the Nginx config
The script in question is a Typescript file, and the dev recommends using Deno, so we're gonna have to install that first. Annoyingly, Deno doesn't publish to most distro package managers, so that'll look about like this:
```
curl -fsSL https://deno.land/install.sh | sh
```
Yucky, but fortunately after that it just works, assuming you told it to add itself to the PATH when it asked. Now run the script:
```
deno run sorcery.ngx.ts > sorcery.conf
```
If you're using Nginx, edit the newly generated `sorcery.conf` accordingly and do whatever it is you do with it.
## Caddy config
Wow, that was tough. Thanks to my hard work, you may now simply copy this into your Caddyfile and you're golden:
```
```
# systemd configuration
Sorcery's README provides a systemd unit and the environment file it expects. We'll put the environment file in place first — copy this to `/etc/sorcery/env` and edit accordingly:
<p class="codetitle">/etc/sorcery/env</p>
```
SORCERY_REPOSITORIES=/absolute/path/to/reposFolder
SORCERY_CACHE=/var/cache/sorcery
SORCERY_SOCKET=/run/sorcery/sock
SORCERY_INSTANCE_NAME=your.domain
SORCERY_CLONE_URL_BASE=https://your.domain
SORCERY_CONTROL_SOCKET=/run/sorcery/control
```
Now paste the following systemd unit to `/etc/systemd/system/sorceryd.service`:
<p class="codetitle">/etc/systemd/system/sorceryd.service</p>
```
[Unit]
Description=Sorcery Git forge
After=network.target
[Service]
Type=simple
User=git
Group=git
RuntimeDirectory=sorcery
CacheDirectory=sorcery
ConfigurationDirectory=sorcery
EnvironmentFile=/etc/sorcery/env
ExecStart=/usr/local/bin/sorceryd
Restart=on-failure
RestartSec=2
UMask=0027
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=read-only
[Install]
WantedBy=multi-user.target
```
Mercifully, if you've followed this guide so far, you shouldn't need to change anything in there. Now you can start 'er up:
```
sudo systemctl daemon-reload
sudo systemctl enable --now sorceryd.service
```
|
