blog-sync-up-1705848860188

diff --git a/archive/1705848860112/metadata.json b/archive/1705848860112/metadata.json
new file mode 100644 (file)
index 0000000..7d90e7b
--- /dev/null
+++ b/archive/1705848860112/metadata.json
@@ -0,0 +1,4 @@
+{
+  "id": "1705848860112",
+  "createdOn": 1705848860112
+}
\ No newline at end of file

diff --git a/archive/1705848860112/scripts-for-git-admin.gmi b/archive/1705848860112/scripts-for-git-admin.gmi
new file mode 100644 (file)
index 0000000..09d276e
--- /dev/null
+++ b/archive/1705848860112/scripts-for-git-admin.gmi
@@ -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!

diff --git a/posts/0/metadata.json b/posts/0/metadata.json
index b1cdb33f4f4dc16e640dc44f771424f9eb3dda5f..7d90e7bbfba6410afd2d9fc37f22a7ded8e51184 100644 (file)
--- a/posts/0/metadata.json
+++ b/posts/0/metadata.json
@@ -1,4 +1,4 @@
 {
 {

-  "id": "1705616805329",
-  "createdOn": 1705616805329
+  "id": "1705848860112",
+  "createdOn": 1705848860112

 }
\ No newline at end of file
 }
\ No newline at end of file

diff --git a/posts/0/scripts-for-git-admin.gmi b/posts/0/scripts-for-git-admin.gmi
new file mode 100644 (file)
index 0000000..09d276e
--- /dev/null
+++ b/posts/0/scripts-for-git-admin.gmi
@@ -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!

diff --git a/posts/1/metadata.json b/posts/1/metadata.json
index e4fee33be9308e447bd70ac2bd52609dc784ffd0..b1cdb33f4f4dc16e640dc44f771424f9eb3dda5f 100644 (file)
--- a/posts/1/metadata.json
+++ b/posts/1/metadata.json
@@ -1,4 +1,4 @@
 {
 {

-  "id": "1705007731083",
-  "createdOn": 1705007731083
+  "id": "1705616805329",
+  "createdOn": 1705616805329

 }
\ No newline at end of file
 }
\ No newline at end of file

diff --git a/posts/0/window-management-and-huge-windows.gmi b/posts/1/window-management-and-huge-windows.gmi
similarity index 100%
rename from posts/0/window-management-and-huge-windows.gmi
rename to posts/1/window-management-and-huge-windows.gmi

diff --git a/posts/1/decentralization-depends-on-access.gmi b/posts/2/decentralization-depends-on-access.gmi
similarity index 100%
rename from posts/1/decentralization-depends-on-access.gmi
rename to posts/2/decentralization-depends-on-access.gmi

diff --git a/posts/2/metadata.json b/posts/2/metadata.json
index 492517f1a399b7e932ec30753f5b2b9ae365db91..e4fee33be9308e447bd70ac2bd52609dc784ffd0 100644 (file)
--- a/posts/2/metadata.json
+++ b/posts/2/metadata.json
@@ -1,4 +1,4 @@
 {
 {

-  "id": "1704232830490",
-  "createdOn": 1704232830490
+  "id": "1705007731083",
+  "createdOn": 1705007731083

 }
\ No newline at end of file
 }
\ No newline at end of file

diff --git a/posts/2/notes-on-setting-up-a-mastodon-server.gmi b/posts/2/notes-on-setting-up-a-mastodon-server.gmi
deleted file mode 100644 (file)
index 7e69014..0000000
--- a/posts/2/notes-on-setting-up-a-mastodon-server.gmi
+++ /dev/null
@@ -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.