freyjagp/blog.raer.me
1
0
Fork 0
Code Actions Packages Releases Activity

Migrate to blag

Browse Source 
- Convert old html blogposts to markdown
- Organize things into blag's folder structure
- Adjust html and css templates
This commit is contained in:
Freyja Odinthrir
2024-01-17 12:04:35 -08:00
parent ed482a34e9
commit 7922bab8e3
29 changed files with 704 additions and 121 deletions
Download Patch File Download Diff File Expand all files Collapse all files

73
content/2023/06/28/_draft_automating-some-things.md Normal file
View File

@@ -0,0 +1,73 @@
title: (DRAFT) Automating some things...
description: Automating some stuff
tags: automation, gitops, freebsd
date: 2023-06-28 12:00
# Automating some things...
So, you've got yourself a webserver. Congratulations! You've taken the first step toward taking ownership of any public webservices you'd like to use. Now... What do you *do* with it?
Well, if you're me, you overenginner it (sort of). I'm at least, *trying* not to overengineer things as much. But there are definitely avenues for improvement on my current deployment. This site runs on a raspberry pi. Specifically, a raspberry pi 4b+ with 8 gigs of ram running FreeBSD 13.2. I've done the basics to harden the system (restricted SSH to keys only, on a port and ip that's on a management vlan - inaccessible from the 'net... and some other things I won't mention here ;P). The nginx webserver runs inside a FreeBSD [jail](https://docs.freebsd.org/en/books/handbook/jails/) on this bare-metal system. It is also networked to a public-facing vlan, separate from the management vlan (and my private stuff). This is accomplished with some networking trickery which I'll go into in depth in the future. For now, essentially: we create a vlan device, a bridge, and several 'epair' devices (one for each jail) then config the jail + host to give the jail its own 'network' thru this epair.
Okay, so we've described the system. How do I get files on/off the server? How do I manage it? That, [my dear data,](https://memory-alpha.fandom.com/wiki/Elementary,_Dear_Data_(episode)) is achieved via ssh. An unprivileged account on the pi has some public keys in the `~/.ssh/authorized_keys` file. That lets me in, and with `sshftp` I can easily drop files onto the server, then with a quick `cp -a /path/to/files /path/to/jail/webroot` I can update the server. Dope. That's awfully manual though... How can we automate this process?
## Gitops! (sort of?)
Well, we can do a couple things here...
- We can just keep doing it this way forever (lame)
- We can do some sort of 'gitops' to speed things up.
Naturally, we choose 2. (There are of course more options, but I won't list them here. Because I haven't thought of them. Not cus they don't exist.) The idea goes like this: since we only need to push static files to update the webserver, I'll just keep the static files in a git repo. Then I can devise a method whereupon updates pushed to the repo are propagated to the webserver automatically via scripts, instead of doing all that manual nonsense each time.
---
__EDIT: 2024-01-17 11:34:__
This was converted from original html:
```html
<s>
<h1>Automating some things...</h1>
<p>So, you've got yourself a webserver. Congratulations! You've taken the first step toward taking ownership of any
public webservices you'd like to use. Now... What do you *do* with it?</p>
<p>Well, if you're me, you overenginner it (sort of). I'm at least, *trying* not to overengineer things as much. But
there are definitely avenues for improvement on my current deployment. This site runs on a raspberry pi.
Specifically, a raspberry pi 4b+ with 8 gigs of ram running FreeBSD 13.2. I've done the basics to harden the
system (restricted SSH to keys only, on a port and ip that's on a management vlan - inaccessible from the
'net... and some other things I won't mention here ;P). The nginx webserver runs inside a FreeBSD <a
href="https://docs.freebsd.org/en/books/handbook/jails/">jail</a> on this bare-metal system. It is also
networked to a public-facing vlan, separate from the management vlan (and my private stuff). This is
accomplished with some networking trickery which I'll go into in depth in the future. For now, essentially: we
create a vlan device, a bridge, and several 'epair' devices (one for each jail) then config the jail + host to
give the jail its own 'network' thru this epair.</p>
<p>Okay, so we've described the system. How do I get files on/off the server? How do I manage it? That, <a
href="https://memory-alpha.fandom.com/wiki/Elementary,_Dear_Data_(episode)">my dear data,</a> is achieved
via ssh. An unprivileged account on the pi has some public keys in the `~/.ssh/authorized_keys` file. That lets
me in, and with `sshftp` I can easily drop files onto the server, then with a quick `cp -a /path/to/files
/path/to/jail/webroot` I can update the server. Dope. That's awfully manual though... How can we automate this
process?</p>
<h2>Gitops! (sort of?)</h2>
<p>Well, we can do a couple things here...
<ol>
<li>We can just keep doing it this way forever (lame)</li>
<li>We can do some sort of 'gitops' to speed things up.</li>
</ol>
</p>
<p>Naturally, we choose 2. (There are of course more options, but I won't list them here. Because I haven't thought
of them. Not cus they don't exist.) The idea goes like this: since we only need to push static files to update
the webserver, I'll just keep the static files in a git repo. Then I can devise a method whereupon updates
pushed to the repo are propagated to the webserver automatically via scripts, instead of doing all that manual
nonsense each time.</p>
</s>
```

48
content/2023/06/28/hello-world.md Normal file
View File

@@ -0,0 +1,48 @@
title: Hello, world!
description: Hello, world!
tags: hello world
date: 2023-06-28 11:03
# Hello? Is anyone listening? Is this thing on?
Hello, world. I'm Freyja (Rae? idk dude, names are as difficult as gender for me.) This is my website. Well... *one* of my websites. I have a few domains. This one is low-effort. Going forward, I'm just gonna use this thing as a sort of blog.Since... I can? I mean, its not like HTML is complicated... It was designed mainly as a way to do books, but better - and with HYPERTEXT. Modern web design has more or less bastardized existing technologies to do fancy things with web browsers. But at the end of the day, raw HTML still works just fine - it just isn't as purdy.
---
__EDIT 2024-01-17 11:22:__ This was originally written in html for an html-only version of this blog. I got tired of that rather quickly. Its difficult to maintain HTML by hand. I wanted something a *little* more automatic, so the blog has been updated to that end.
Here's the original HTML of this blog entry:
```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Hello, world!</title>
</head>
<body>
<nav>
<a href="/index.html">Index</a>
<a href="/about.html">About</a>
<a href="/contact.html">Contact</a>
</nav>
<hr>
<!-- CONTENT GOES HERE -->
<h1>Hello? Is anyone listening? Is this thing on?</h1>
<h2>11:03am(PDT)</h2>
<p>Hello, world. I'm Freyja (Rae? idk dude, names are as difficult as gender for me.) This is my website. Well... *one*
of my websites. I have a few domains. This one is low-effort. Going forward, I'm just gonna use this thing as a sort
of blog.Since... I can? I mean, its not like HTML is complicated... It was designed mainly as a way to do books, but
better - and with HYPERTEXT. Modern web design has more or less bastardized existing technologies to do fancy things
with web browsers. But at the end of the day, raw HTML still works just fine - it just isn't as purdy.</p>
<!-- END CONTENT -->
<hr>
<footer>
<p>Published: 28th June, 2023</p>
</footer>
</body>
</html>
```

57
content/2023/06/30/jails_20230630-0846.md Normal file
View File

@@ -0,0 +1,57 @@
title: FreeBSD Jail Networking
description: Networking FreeBSD Jails
tags: UNIX, freebsd, networking
date: 2023-06-30 08:46
# FreeBSD Jails: Networking
_containerization as a workshop, instead of a toolbox_
## Some assumptions
This article assumes an understanding of:
- [FreeBSD Jails](https://docs.freebsd.org/en/books/handbook/jails/)
- [`ifconfig(8)`](https://man.freebsd.org/cgi/man.cgi?ifconfig)
___
## Basic networking
~~FreeBSD has a refined form of containerization called `jails` which, while simple to install, are not quite as simple to network. We'll distill the core concepts of jail networking here to make them easier to understand for implementation.~~ By default, you must assign a jail an ip address, which attaches to and shares the host's physical network adapter. This is `good 'nough for government work` but for more advanced deployments, you're going to need more advanced configurations (go figure). This is achieved by assigning a jail a `vnet`. This gives the jail control over a virtual networking device created on the host.
~~One of the more confusing concepts to wrap my head around was ifconfig and how it manages network devices. I'm not used to dealing with networking on a unix system in such an elegant way. Imagine using one utility to list and manage devices?? Wowie!! `ifconfig` is a great tool. `network-manager` and all the other dogshit that you can find on linux pales in comparisson to the simplicity of configuring your network with a _FUCKING API_. Not through bullshit config files, hidden in bullshit places which have changed endless times over the years leading to fragmented, confusing, and enraging experiences while trying to use the web to do networking things on linux. But with an actual cli/api. WOW. This is great.~~
A few things are implied here, which tripped me up. I'll note them:
1. `ifconfig vlan1000 create vlan 1000 vlandev em0` is the same thing as `ifconfig em0.1000 create` so save yourself the trouble and use the latter syntax.
2. `vnets` are attached to running jails, and do not appear when using `ifconfig -a`
Lets first list the tools at our disposal before we start playing around with them.
- the `bridge`. Think of this as a sort of virtual switch. Devices on a bridge can talk to one another.
- the `virtual device`. `ifconfig em0.1000 create` creates a virtual device connected to the physical interface `em0` that tags packets with vlan 1000. This virtual device can be created/destroyed without impactinv the parent (physical) device.
- the `epair`. This is, essentially, a virtual crossover cable. This plugs two devices into each other directly (virtually) allowing them to speak.
So with the tools listed above, we can begin to think about what's going on here. When configuring a jail to use a `vnet`, we're giving it access to the whole virtual device. We can't give it `em0`, but every device described above is in fact a virtual network device passable to a jail. Giving one access to a vlan directly is fine, but blocks that vlan from being shared by other jails. So we must architect the virtual network stack on a freebsd host to allow for such things.
This is how I've achieved it.
Note: Something about the order in which you do these things matters. I'm not _quite_ sure about this as I haven't done digging. Anyway...
For this example, our vlan will be `vlan 10` and our physical network device will be `em0`. We assume the network is laid out as such: Each vlan is assigned to a subnet of /16 on the ips in 10.0.0.0/8, with each vlan denoted by the second octet.
We assume a fresh configuration that has a single physical network device present. This device may have an ip assigned directly to it.
`ifconfig em0.10 create up` will create and attach a virtual device on em0, using vlan 10, and designated as "up" for communication.
`ifconfig bridge0 create addm em0.10 inet 10.10.0.1/16 up` creates a bridge device, assigns it an ip on vlan 10, and connects it to em0.10.
`ifconfig epair10 create up` creates an epair device which will be passed to the jail.
`ifconfig bridge0 addm epair10a up` will attach the epair device to the bridge. We do not assign A an ip address.
Finally, we may pass `epair10b` to the jail in `/etc/jail.conf`. Using ifconfig on the jail, we may assign the jail an ip address (say, 10.10.0.10/16).
This method allows us to create any arbitrary amount of jails attached to vlan10, so long as we create an epair for it and attach it appropriately.

47
content/2023/07/03/doing-more-stuff.md Normal file
View File

@@ -0,0 +1,47 @@
title: Doing more stuff...
description: doing more stuff with the blog
tags: ruminations
date: 2023-07-03 16:20
# Doing more
Now that I have gitea (and a mysql server) in 'prod', its time to do more automagical things. The first line of business will be to look into CI/CD tools with gitea. Its rather silly that I have a whole-ass gitea server running, but don't utilize any of the ci/cd features that it offers. At a minimum, I could set up something to update this webserver automatically based off of a git repo push, instead of the current method: sftp directly into the freebsd host, navigate to the jail's html folder, and editing things directly. I'm literally editing this thing LIVE in vscode right now, lol. The moment I hit save, is the moment it gets published. I could maybe stand to do things a *little* different...? Possibly? Or maybe I won't. Maybe I'll just say "Fuck it, that's too much work, this site is full on low-effort". IDK. It depends on how much I think going 'low effort' will end up causing me to have an annoying, repetative workflow when editing this site.
---
__EDIT: 2024-01-17 11:27__
This was imported from the old version of this blog. Here is the original html version:
```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>TEMPLATE</title>
</head>
<body>
<nav>
<a href="/index.html">Index</a>
<a href="/about.html">About</a>
<a href="/contact.html">Contact</a>
</nav>
<hr>
<!-- CONTENT GOES HERE -->
<h1>Doing more.</h1>
<p>Now that I have gitea (and a mysql server) in 'prod', its time to do more automagical things. The first line of business will be to look into CI/CD tools with gitea. Its rather silly that I have a whole-ass gitea server running, but don't utilize any of the ci/cd features that it offers. At a minimum, I could set up something to update this webserver automatically based off of a git repo push, instead of the current method: sftp directly into the freebsd host, navigate to the jail's html folder, and editing things directly. I'm literally editing this thing LIVE in vscode right now, lol. The moment I hit save, is the moment it gets published. I could maybe stand to do things a *little* different...? Possibly? Or maybe I won't. Maybe I'll just say "Fuck it, that's too much work, this site is full on low-effort". IDK. It depends on how much I think going 'low effort' will end up causing me to have an annoying, repetative workflow when editing this site.</p>
<!-- END CONTENT -->
<hr>
<footer>
<p>Published: 3rd July, 2023 @ 4:20pm PDT</p>
</footer>
</body>
</html>
```

76
content/2023/07/03/ha.md Normal file
View File

@@ -0,0 +1,76 @@
title: Ha!
description: a discovery of sorts
tags: ruminations
date: 2023-07-03 15:36
# Ha!
I've tracked down an issue that plagued my gitea config and made me go nuts for a week. Turns out that for some reason, full end-to-end https on gitea breaks ssh pushing? I've abandoned this prospect for now, instead opting to just use TLS termination at <https://gitea.raer.me/> and forwarding to http on the private network. That's fine for my purposes. Its not ideal. But its fine.
What truly matters here, is that I've got my gitea deployment off of the virtual machine it was running on. And, the database connection is now encrypted (and enforced) with tls. So there's that. See, before, I was running a virtual machine on my truenas scale server that had a bunch of rootless docker instances running things. this was far. Too. Complex. It didn't even solve anything practically, either. It forced me to do networking where I didn't need to.
Instead, gitea and its mysql server run directly on the k3s implementation on my truenas scale server. This is ideal, as it allows me easier control over the files. It allows me to do zfs snapshots of the db and the gitea server. It removes the need for the scheduled daily downtime while a script archived and stored the whole thing on another server. At least, that's the idea. It also removes the overhead of the whole server, and streamlines things somewhat.
Anyway, this has been an entry in the ol blog. Over and out
- Freyja
ps: did I mention I didn't have to nuke the whole thing and start from scratch like I thought I might? That's a big bonus!
---
__EDIT 2024-01-17 11:29__
This was copied from its original HTML version. See below:
```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Ha!</title>
</head>
<body>
<nav>
<a href="/index.html">Index</a>
<a href="/about.html">About</a>
<a href="/contact.html">Contact</a>
</nav>
<hr>
<!-- CONTENT GOES HERE -->
<h1>Ha!</h1>
<p>I've tracked down an issue that plagued my gitea config and made me go nuts for a week. Turns out that for some
reason, full end-to-end https on gitea breaks ssh pushing? I've abandoned this prospect for now, instead opting to
just use TLS termination at https://gitea.raer.me/ and forwarding to http on the private network. That's fine for my
purposes. Its not ideal. But its fine.</p>
<p>What truly matters here, is that I've got my gitea deployment off of the virtual machine it was running on. And, the
database connection is now encrypted (and enforced) with tls. So there's that. See, before, I was running a virtual
machine on my truenas scale server that had a bunch of rootless docker instances running things. this was far. Too.
Complex. It didn't even solve anything practically, either. It forced me to do networking where I didn't need to.
</p>
<p>Instead, gitea and its mysql server run directly on the k3s implementation on my truenas scale server. This is ideal,
as it allows me easier control over the files. It allows me to do zfs snapshots of the db and the gitea server. It
removes the need for the scheduled daily downtime while a script archived and stored the whole thing on another
server. At least, that's the idea. It also removes the overhead of the whole server, and streamlines things
somewhat.</p>
<p>Anyway, this has been an entry in the ol blog. Over and out.</p>
<p>ps: did I mention I didn't have to nuke the whole thing and start from scratch like I thought I might? That's a big
bonus!</p>
<p>- Freyja</p>
<!-- END CONTENT -->
<hr>
<footer>
<p>Published: 3rd July, 2023 @ 3:36pm PDT</p>
</footer>
</body>
</html>
```