initial commit
This commit is contained in:
41
www/blog/_drafts/automations_20230628.html
Normal file
41
www/blog/_drafts/automations_20230628.html
Normal file
@@ -0,0 +1,41 @@
|
||||
<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>
|
||||
51
www/blog/_drafts/jails_20230630-0846.md
Normal file
51
www/blog/_drafts/jails_20230630-0846.md
Normal file
@@ -0,0 +1,51 @@
|
||||
# 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.
|
||||
0
www/blog/_drafts/rantings_20230706-114800.md
Normal file
0
www/blog/_drafts/rantings_20230706-114800.md
Normal file
Reference in New Issue
Block a user