Initial commit

.gitignore

@@ -0,0 +1,6 @@
+/public/
+/resources/_gen/
+/assets/jsconfig.json
+hugo_stats.json
+
+.hugo_build.lock

.gitmodules

@@ -0,0 +1,3 @@
+[submodule "themes/qubt"]
+	path = themes/qubt
+	url = https://github.com/chrede88/qubt

archetypes/default.md

@@ -0,0 +1,5 @@
++++
+title = '{{ replace .File.ContentBaseName "-" " " | title }}'
+date = {{ .Date }}
+draft = true
++++

config/_default/menus.yaml

@@ -0,0 +1,7 @@
+main:
+  - name: Home
+    url: /
+    weight: 10
+  - name: About
+    url: /about/
+    weight: 20

config/_default/params.yaml

@@ -0,0 +1,4 @@
+author:
+  name: "Emin Arslan"
+  image: Emin-Arslan.jpg
+  greeting: "Welcome to my personal blog :)"

content/about.md

@@ -0,0 +1,21 @@
++++
+title = 'About'
+date = 2024-10-24T23:17:52+03:00
+draft = false
++++
+# About me
+
+Hi, I'm Emin!
+
+I am a second year Computer Engineering student at Izmir University of Economics.
+I like all things programming and computers.
+
+I mostly do systems programming - I feel most at home when I use C++ or C, though
+I've used Rust, Java and many other languages to varying degrees. I *did* have a phase
+when I was really into Common Lisp.
+
+This website exists to be my blog/toy. It's hosted on a VPS, so that I can practice
+my hosting/web skills. I use [Hugo](https://gohugo.io/) with the [Qubt](https://themes.gohugo.io/themes/qubt/) 
+theme to generate pages from my content. I think it looks pretty good, check them out.
+
+Hopefully I'll post a bit more on here soon.

content/posts/podman-setup.md

@@ -0,0 +1,121 @@
++++
+title = 'Podman Setup - p1'
+date = 2024-10-25T23:11:17+03:00
+draft = false
++++
+
+# Podman
+
+In this 'article' I will be walking you through my process of how I
+host everything on this server.
+
+When first creating this website, I had a small issue with how I wrote
+my code and deployed it: whenever I made a small change to the page, I had
+to manually rebuild it, then upload the updated version to server and put it
+in the web directory.
+
+This is a cumbersome process. For comparison, in my new setup, all I have to
+do is to run `git commit` and `git push` after any change and my website will be
+automatically built and deployed. 
+
+The previous "manual" approach also depends on me having already installed all
+necessary software. If you have a dedicated server that you're running yourself,
+that's probably okay, you just have to setup once, but I'm running this on a VPS
+that I'm not sure I'll keep forever. The ability to reproduce this exact setup 
+within minutes actually matters.
+
+After reading a bit on this topic, I decided I would use podman for this. Docker would
+work just as nicely (any containerisation software would work, really), but I decided 
+on podman because it can run without a daemon and without root privilages. Also,
+it has pretty neat support for kubernetes pods (which are honestly a lot more useful
+than I would've given them credit for before I started this whole project).
+
+That's really why I'm writing this. So that you, the reader (or possibly my future self) can
+understand the methodology of podman, how to create pods, run containers and configure all
+of this automatically, and so that I may demonstrate and share what I've learnt during
+this process.
+
+## Motivation
+
+Basically, I'm already running a web server. Why shouldn't I also host several other services
+for friends and family while I'm at it? Why shouldn't I make the entire setup reproducable?
+
+Here are some of the services I wanted to self-host:
+    - Web server: obviously, who doesn't want a website?
+    - Some git server: having my own place to show off all the things I've done is certainly really cool.
+    - Wireguard: Free VPN along with the website? sign me up.
+    - CI/CD: automatic testing and releases of my software is cool, and also incredibly useful because that's
+how I plan to handle the website as well.
+
+Of course, there are always more things I could be self-hosting. So it makes sense to automate
+the setup, and that's where podman comes in.
+
+## Basics of podman
+
+Before we can get to the exciting stuff, we need to go over what podman is, and how to
+use it. Essentially, podman is a container engine: it lets you build and run applications in
+a containerized environment. Containers are useful because they provide security,
+easy setup and most importantly, reproducability.
+
+I'm not going to spend any more time explaining what containers are and why they're
+good, that's been done to death already. Right now, what matters is the actual setup,
+so let's get on with it.
+
+If you've used docker before, you'll feel right at home. Many commands are unchanged
+from docker, making podman a suitable drop-in replacement. Some things like network
+setups tend to be a little different, but that won't matter too much right now.
+
+In case you're unfamiliar with docker, here are some basic commands:
+
+```sh
+# Search for container images (on docker.io unless you configure otherwise)
+$ podman search <image name>
+
+# Download (pull) an image from remote repo
+$ podman pull <image name>
+
+# list the images you have pulled.
+$ podman images
+
+# run a container.
+$ podman run <image name>
+
+# run a container, but with a LOT of flags. I just listed the most useful ones.
+$ podman run
+    -i # interactive, so you can e.g. run a shell in the container
+    -t # allocates a tty. useful with -i so that shell completion etc. can work
+    -d # opposite of -i, detach and run in the background
+    --port <HOST PORT>:<CONTAINER PORT> # port forwarding, for when you need a server.
+    -v <HOST DIR>:<CONT DIR>:<FLAGS> # give the container access to some directory
+    <image name>
+    <command> # ... want a shell?
+
+# list running containers. add -a to list ALL containers, running or stopped.
+# podman ps <-a>
+
+# stop a running container.
+$ podman stop <id>
+
+# stopped containers don't automatically get removed. This command removes it.
+$ podman rm <id>
+```
+
+## Pods are nice.
+
+Pods are basically just a collection of containers - multiple programs working with each other.
+
+Usually, on a server, each application *isn't* totally separate from each other - for my own usecase,
+I want my git server (e.g. gogs) to automatically build and update my website whenever I push to its git
+repository. That means my git server and web server can't be *totally* separate, there's some amount of
+relation. Pods can help with this.
+
+Pods allow you to create a "pod" containing several containers, sharing resources with each other, etc.
+For example, I could run a pod with nginx and gogs running in seperate containers - then, the nginx
+server could act as a reverse proxy based on host name, showing the web page on emin.software,
+and the git server on git.emin.software. Nginx redirects to gogs which only binds to *the pod's localhost
+address*, so only nginx can reach it. Likewise, a database server can be added to the pod only for the
+git server to use, so that it can't be reached from the outside the pod - and it is logically grouped
+along with the rest of the pod.
+
+On top of this, pods can be built purely from a kubernetes-compatible configuration file, so setting them
+up is relatively easy.

hugo.toml

@@ -0,0 +1,4 @@
+baseURL = 'http://emin.software/'
+languageCode = 'en-us'
+title = 'haxala1r'
+theme = 'qubt'

themes/qubt

@@ -0,0 +1 @@
+Subproject commit 5f1c2f3e72a2f7b6ec74442ebcedc144479da035