wrote most of the blog article about having the website automatically deployed

content/blog/gh_actions.md

@@ -4,5 +4,63 @@ description: "a brief post on how I setup github actions to automatically update
 date: 2022-01-20
 draft: true
 ---
-## github actions
+So recently I got a bit of a bee in my bonnet to go setup CD for this website. The main reasons that drove this were 1. deploying the site was mildly tedious which is a good enough reason on it's own and 2. I wanted to learn how to do it. I'm gonna write about some lead up to me doing this so if all you care about is the how then click [here]()
 
+## Wait but how did I find out about and how to do this?
+    I was aware of github actions and a vague sense of how it should work observing how things went when I made my small contribution to [Gerald](https://github.com/Gerald-Development/Barista-Gerald). But observing that didn't really give a sense of how it worked. What did was when my friend [Micha](https://github.com/michalusio) was working on implementing [their own blog](https://lochalhost.pl) and set things up with github actions to implement CI/CD. Then I saw [this Fireship video](https://www.youtube.com/watch?v=eB0nUzAI7M8) which gave me a nice amount of context for this. Even with that bit of knowledge on how to setup stuff with github actions I didn't really have a motivation to go do it.
+
+## The spark to actually do it
+Then for a couple of reasons wanted to write a blog article about progress on [Pogo](https://github.com/Pagwin-Fedora/Pogo). But I decided that before I wrote any more articles that I should go look into setting up CD for my site.
+
+## Implementing CD with Github actions
+So with inspiration in my heart to go and do stuff with github actions I began. First off I needed to setup the condition for my workflow running which was a pretty simple
+```yaml
+on:
+    push:
+        branches:
+            - master
+```
+as I wasn't really doing anything interesting enough to require anything else. So I went on to implement the jobs needed to make this CD workflow work.
+
+## The jobs
+I knew due to reading some pages on github's action market place and previous context that I would need to have at least 3 if not more steps
+1. checkout the code
+2. use Hugo to build the site
+3. deploy to my VPS
+So going through each of those steps in order to see how I went about doing them first we have checking the code out which was a pretty simple `uses: actions/checkout@v2` additionally telling it to fetch submodules due to the structure of my project. After checking out the code I had to use Hugo and conveniently there was a module for Hugo `peaceiris/actions-hugo@v2` although sadly it only installs Hugo so another step would have to be added to build the app. But that step was a pretty simple `run: hugo --minify`. I will say though that if the example on the marketplace page didn't use the --minify option I wouldn't have either because I didn't know it existed so that was a nice little learning experience. After building the code I needed to deploy it which due to this being a static site was theoretically as simple as copying files with rsync. But I didn't want to have an automated action have access to root or my user for security and anti-stupidity reasons. To implement that I had to leave the realm of github actions and go over to my VPS to set some stuff up.
+
+## Some work on the VPS
+That stuff in question was adding a new user and changing the perms of /var/www/pagwin.xyz so that new user could edit files there. This was pretty simple.
+```sh
+sudo useradd website # I can hear people laughing at me already for not passing the -m option but relax I'll explain later
+sudo chown -R website:www-data /var/www/pagwin.xyz # btw I didn't explain earlier but my website files are in /var/www/pagwin.xyz not /var/www/html because I'm hosting multiple sites on this VPS and the folder change makes it easier to keep track of which one I'm screwing with
+```
+However my unwillingness to have the new user have a home directory for cleanliness and to avoid unnecessarily leaving a user that could receive emails(I have an email server setup on this VPS as well) I didn't create a home directory. But in order for the deployment workflow on github to deploy to the VPS via rsync it would need ssh access... Okay the problem may not be obvious if you don't understand ssh/good security practices very well. The problem is that in order to login to ssh via an ssh key you need to put that key into `$user_home/.ssh/authorized_keys` which requires the user have a home directory that I am unwilling to create. Password authentication is also not an option because allowing password auth onto a server is insecure compared to only allowing ssh keys. This is especially true when the ssh login is being done by an automated system. Also my VPS requires the usage of a TOTP if you login via a password and setting that up for github actions sounds like a nightmare. Also also in order for the server to know the TOTP to generate it generates a file... which goes into the home directory meaning nothing has changed or improved by trying to use a password. Conveniently while `$user_home/.ssh/authorized_keys` is the default location for ssh public keys it's pretty easy to add another location for sshd to look for authorized_keys just by adding the line `AuthorizedKeysFile .ssh/authorized_keys /etc/ssh/keys/%u.authorized.pub` to `/etc/ssh/sshd_config` where the later bit of `/etc/ssh/keys/%u.authorized.pub` is added on from the default. That last bit of the config tells ssh to look for the public keys at an additional location where %u is replaced with the username of the user trying to login. After that whole hassle is done with generating the ssh key is pretty simple with `ssh-keygen` and putting the public key in the right spot. Adding the private key as a github secret was annoying however but I'll discuss that in the [#Dealing With My Stupidity]() section.
+
+## What were we talking about oh yeah github actions
+anyways yeah this is what I initially(spoiler I change it) wrote for github actions to go and deploy the app.
+```yaml
+uses: up9cloud/action-rsync@master
+env:
+  HOST: pagwin.xyz
+  KEY: ${{secrets.SSH_KEY}}
+  TARGET: /var/www/pagwin.xyz/
+```
+With that I saved the file to `.github/website-publish.yml` and felt a mild sense of accomplishment. In hindsight that sense and the initial file are hilarious and while I would love to immediately explain why first I want to take a second to show a step I added after I was done dealing with my own stupidity. That step is a cleanup step that deletes the old site before copying over the new one so people can't snoop around in redundant files. I implemented that with this tidbit.
+```yaml
+uses: appleboy/ssh-action@master
+with:
+  host: pagwin.xyz
+  username: website
+  key: ${{secrets.SSH_KEY}}
+  script: rm -rf /var/www/pagwin.xyz/*
+```
+And now we get to the comedic part of this blog post.
+
+## Dealing With My Stupidity(and a private ssh key)
+* wrong file location
+* wrong source
+* wrong target
+* website user not specified
+* accidental deletion of /var/www/pagwin.xyz
+* dumb stuff that I didn't want that I forgot I added(difficult to remove due to not knowing how hugo worked)