~rbdr/gemlog

2ea36e8e9756fbf4c55a119a926d6b86f1bf8490 — Ruben Beltran del Rio 2 months ago f594f89
blog-sync-up-1705848860188
9 files changed, 150 insertions(+), 68 deletions(-)

A archive/1705848860112/metadata.json
A archive/1705848860112/scripts-for-git-admin.gmi
M posts/0/metadata.json
A posts/0/scripts-for-git-admin.gmi
M posts/1/metadata.json
R posts/{0/window-management-and-huge-windows.gmi => 1/window-management-and-huge-windows.gmi}
R posts/{1/decentralization-depends-on-access.gmi => 2/decentralization-depends-on-access.gmi}
M posts/2/metadata.json
D posts/2/notes-on-setting-up-a-mastodon-server.gmi
A archive/1705848860112/metadata.json => archive/1705848860112/metadata.json +4 -0
@@ 0,0 1,4 @@
{
  "id": "1705848860112",
  "createdOn": 1705848860112
}
\ No newline at end of file

A archive/1705848860112/scripts-for-git-admin.gmi => archive/1705848860112/scripts-for-git-admin.gmi +70 -0
@@ 0,0 1,70 @@
# Scripts for self-hosted git admin

Recently I've been using my own git server [1,2] to host my repositories, and for simplicity I decided to go with GitWeb [3]. This also means that I don't get a web management UI, which turns out is a great thing with a few helper scripts.

=> https://git.unlimited.pizza [1] git @ unlimited.pizza (https)
=> gemini://gemini.unlimited.pizza/git [2] git @ unlimited.pizza (gemini)
=> https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb [3] GitWeb

## repo_name to fetch repository name

I want to use the same <username>/<repo> structure across services, and this utility helps me extract it. It fetches the push origin remote, grabs the last two fragments of the URL and then removes any leading tilde (for compatibility with sourcehut). I don't really use this one directly, but all other scripts depend on it.

```
function repo_name {
  git remote -v | grep origin | grep push | grep -o '[^:/]\+\/[^/]\+\s\+' | grep -o '[^~:]\+\/[^ ]\+'
}
```

## sync_to_conchos creates the repository

My upstream is called conchos [4], and this function checks if the origin exists and then pushes everything. The server is setup to create a private repository if it's not found.

```
function sync_to_conchos {
  if git config remote.conchos.url > /dev/null; then; else
    git remote add conchos "git@git.unlimited.pizza:$(repo_name)" 
  fi
  git push conchos --all
  git push conchos --tags
}

// eg.
% cd ~/projects/web/blog && sync_to_conchos
```

=> https://en.wikipedia.org/wiki/Rio_Conchos [4] Rio Conchos

## make_public /make_private control a repo's visibility

The git daemon controls public access with a file called `git-daemon-export-ok`, so controlling visibilitiy is as easy as touching or removing a file. If I run these from the root of the project, it controls its visibility.

```
function make_public {
  ssh git@git.unlimited.pizza -T "touch /srv/git/$(repo_name)/git-daemon-export-ok"
}

function make_private {
  ssh git@git.unlimited.pizza -T "rm /srv/git/$(repo_name)/git-daemon-export-ok"
}

// eg.
% cd ~/projects/web/blog && make_public
```

## describe adds a description for the repo

The git daemon uses a file called `description` to show a description on the web.

```
function describe {
  ssh git@git.unlimited.pizza -T "echo '$1' > /srv/git/$(repo_name)/description"
}

// eg.
% cd ~/projects/web/blog && describe 'An (almost) ephemeral blog #cli'
```

## That's it!

This has made managing my repositories a lot easier as I don't have to fiddle with a web UI at all. If you're also self-hosting git, maybe you'll also find them helpful!

M posts/0/metadata.json => posts/0/metadata.json +2 -2
@@ 1,4 1,4 @@
{
  "id": "1705616805329",
  "createdOn": 1705616805329
  "id": "1705848860112",
  "createdOn": 1705848860112
}
\ No newline at end of file

A posts/0/scripts-for-git-admin.gmi => posts/0/scripts-for-git-admin.gmi +70 -0
@@ 0,0 1,70 @@
# Scripts for self-hosted git admin

Recently I've been using my own git server [1,2] to host my repositories, and for simplicity I decided to go with GitWeb [3]. This also means that I don't get a web management UI, which turns out is a great thing with a few helper scripts.

=> https://git.unlimited.pizza [1] git @ unlimited.pizza (https)
=> gemini://gemini.unlimited.pizza/git [2] git @ unlimited.pizza (gemini)
=> https://git-scm.com/book/en/v2/Git-on-the-Server-GitWeb [3] GitWeb

## repo_name to fetch repository name

I want to use the same <username>/<repo> structure across services, and this utility helps me extract it. It fetches the push origin remote, grabs the last two fragments of the URL and then removes any leading tilde (for compatibility with sourcehut). I don't really use this one directly, but all other scripts depend on it.

```
function repo_name {
  git remote -v | grep origin | grep push | grep -o '[^:/]\+\/[^/]\+\s\+' | grep -o '[^~:]\+\/[^ ]\+'
}
```

## sync_to_conchos creates the repository

My upstream is called conchos [4], and this function checks if the origin exists and then pushes everything. The server is setup to create a private repository if it's not found.

```
function sync_to_conchos {
  if git config remote.conchos.url > /dev/null; then; else
    git remote add conchos "git@git.unlimited.pizza:$(repo_name)" 
  fi
  git push conchos --all
  git push conchos --tags
}

// eg.
% cd ~/projects/web/blog && sync_to_conchos
```

=> https://en.wikipedia.org/wiki/Rio_Conchos [4] Rio Conchos

## make_public /make_private control a repo's visibility

The git daemon controls public access with a file called `git-daemon-export-ok`, so controlling visibilitiy is as easy as touching or removing a file. If I run these from the root of the project, it controls its visibility.

```
function make_public {
  ssh git@git.unlimited.pizza -T "touch /srv/git/$(repo_name)/git-daemon-export-ok"
}

function make_private {
  ssh git@git.unlimited.pizza -T "rm /srv/git/$(repo_name)/git-daemon-export-ok"
}

// eg.
% cd ~/projects/web/blog && make_public
```

## describe adds a description for the repo

The git daemon uses a file called `description` to show a description on the web.

```
function describe {
  ssh git@git.unlimited.pizza -T "echo '$1' > /srv/git/$(repo_name)/description"
}

// eg.
% cd ~/projects/web/blog && describe 'An (almost) ephemeral blog #cli'
```

## That's it!

This has made managing my repositories a lot easier as I don't have to fiddle with a web UI at all. If you're also self-hosting git, maybe you'll also find them helpful!

M posts/1/metadata.json => posts/1/metadata.json +2 -2
@@ 1,4 1,4 @@
{
  "id": "1705007731083",
  "createdOn": 1705007731083
  "id": "1705616805329",
  "createdOn": 1705616805329
}
\ No newline at end of file

R posts/0/window-management-and-huge-windows.gmi => posts/1/window-management-and-huge-windows.gmi +0 -0
R posts/1/decentralization-depends-on-access.gmi => posts/2/decentralization-depends-on-access.gmi +0 -0
M posts/2/metadata.json => posts/2/metadata.json +2 -2
@@ 1,4 1,4 @@
{
  "id": "1704232830490",
  "createdOn": 1704232830490
  "id": "1705007731083",
  "createdOn": 1705007731083
}
\ No newline at end of file

D posts/2/notes-on-setting-up-a-mastodon-server.gmi => posts/2/notes-on-setting-up-a-mastodon-server.gmi +0 -62
@@ 1,62 0,0 @@
# Notes on Setting Up a Mastodon Server

Last week I decided to migrate my account to my own mastodon server [1], and I was surprised at how easy it was, but it wasn't without hiccups so I'm writing down some notes on my experience on here. It's not meant to be an in-depth tutorial, but a rough overview on what I had to do to get the server to work.

=> https://friendship.quest/@ruben [1] my profile @ friendship.quest

First, some information on my setup: I have a VPS on digitalocean running arch linux, so I went directly to the Arch Wiki [2] which provides great documentation. I had my mind set on using the glitch fork of mastodon [3], so I went with the mastodon-git [4] package. I only had 1G of RAM, which absolutely won't work: some dependencies won't even compile without running out of memory. I decided to upgrade to an instance with 4GB, and this was enough though I did have to tweak some values.

=> https://wiki.archlinux.org/title/Mastodon [2] Arch Wiki entry on Mastodon.
=> https://glitch-soc.github.io/docs/ [3] Mastodon Glitch Edition
=> https://aur.archlinux.org/packages/mastodon-git [4] mastodon-git AUR package.

Then onto the setup itself. Starting with the clone:

```
% git clone https://aur.archlinux.org/packages/mastodon-git
```

Then changed PKGBUILD to use the glitch-soc version.

```
# -source=("git+https://github.com/tootsuite/${pkgname%-git}.git#branch=$_branch"
# +source=("git+https://github.com/glitch-soc/${pkgname%-git}.git#branch=$_branch"
```

Installed some dependencies.

```
% pacman -Sy imagemagick libpqxx postgresql redis protobuf nodejs icu cmake base-devel
```

At this point I ran into issues with yarn when running makepkg as I use asdf [5] to control my environment. The dependencies above install nodejs, but I wanted to use the one from asdf, so I had to make sure the paths were correct, otherwise I ran into issues with the right version of yarn. Eventually corepack enable did work. I'm skipping this here because I don't really remember and I don't think most people will haver these issues.

=> https://asdf-vm.com/ [5] asdf-vm

But then we were able to makepkg

```
% makepkg -si
```

The post-install instructions didn't run for me, so I read them from the file [6].

=> https://aur.archlinux.org/cgit/aur.git/tree/mastodon.install?h=mastodon [6] mastodon.git post-install file

Before running the mastodon rake file, I made sure to have the s3 bucket and smtp configuration ready (Will post the pulumi recipe for this in another post), and then the mastodon:setup rake task ran *almost* entirely, but failed during the assets:precompile phase so I had to continue from where it stopped by reading the source [7]. Since only setting up the admin user was left, I removed the rest of the code temporarily to run just that part of the task.

=> https://github.com/glitch-soc/mastodon/blob/main/lib/tasks/mastodon.rake [7] mastodon:setup rake task source

With that, all that was left was to set up nginx, so I used the file included in the repo [8] to set it up.

=> https://github.com/mastodon/mastodon/blob/main/dist/nginx.conf [8] nginx.conf from mastodon repo.

And that was pretty much it. I did have to make some changes to reduce memory usage and have sidekiq run correctly. On /lib/systemd/system/mastodon-sidekiq.service, I replaced -c 5 with -c 3 and made sure to include -q ingress and -q scheduler as they weren't included.

I won't go into detail here on the full text search setup, but I did have to reduce the max heap size on opensearch + reduce the sidekiq workers to 3 to avoid running out of memory. In /etc/opensearch/jvm.options you can set -Xms1g and -Xmx1g or whatever value works for you.

Finally, before migrating I imported a couple of ready-made blocklists and went over information on moderation.

=> https://fedi.tips/importing-ready-made-server-blocklists-on-mastodon/ [9] fedi.tips info on blocklists

The server worked well, though it did take about a day for federation to work reliably with some instances. I believe it had to do mostly with DNS propagation. Eventually I was able to migrate and so far it seems to be going well! I am now the proud owner of my personal mastodon instance.