From 7b715cd2717cb605467d06a103e024610b32ffce Mon Sep 17 00:00:00 2001 From: Dante Catalfamo Date: Thu, 18 Jun 2020 17:05:41 -0400 Subject: Move files back to index.org --- content/post/letsencrypt-on-openbsd.org | 122 ---------------------- content/post/letsencrypt-on-openbsd/index.org | 122 ++++++++++++++++++++++ content/post/openvpn-issues-openbsd-6.7.org | 72 ------------- content/post/openvpn-issues-openbsd-6.7/index.org | 72 +++++++++++++ content/post/pcengines-comparison.org | 96 ----------------- content/post/pcengines-comparison/index.org | 96 +++++++++++++++++ content/post/stop-mg-from-making-a-mess.org | 53 ---------- content/post/stop-mg-from-making-a-mess/index.org | 53 ++++++++++ 8 files changed, 343 insertions(+), 343 deletions(-) delete mode 100644 content/post/letsencrypt-on-openbsd.org create mode 100644 content/post/letsencrypt-on-openbsd/index.org delete mode 100644 content/post/openvpn-issues-openbsd-6.7.org create mode 100644 content/post/openvpn-issues-openbsd-6.7/index.org delete mode 100644 content/post/pcengines-comparison.org create mode 100644 content/post/pcengines-comparison/index.org delete mode 100644 content/post/stop-mg-from-making-a-mess.org create mode 100644 content/post/stop-mg-from-making-a-mess/index.org (limited to 'content') diff --git a/content/post/letsencrypt-on-openbsd.org b/content/post/letsencrypt-on-openbsd.org deleted file mode 100644 index 556404b..0000000 --- a/content/post/letsencrypt-on-openbsd.org +++ /dev/null @@ -1,122 +0,0 @@ -#+TITLE: Let's Encrypt on OpenBSD -#+DATE: 2020-06-16T22:56:27-04:00 -#+DRAFT: false -#+DESCRIPTION: Setting up acme-client on OpenBSD -#+TAGS[]: openbsd httpd letsencrypt acme-client -#+KEYWORDS[]: openbsd httpd letsencrypt acme-client -#+SLUG: -#+SUMMARY: - -#+ATTR_HTML: :alt Let's Encrypt OpenBSD -#+ATTR_HTML: :title Let's Encrypt OpenBSD -[[file:openbsd%20letsencrypt.png]] - -So I have an OpenBSD server serving a static website using -=httpd=. I've been thinking for a while I should add an SSL -certificate, but never got around to it because it was just a small -hobby website and it didn't require any real attention. - -Today while watching one of the OpenBSD tutorials at BSDCan, I thought -it was finally time. Since configuring everything else in OpenBSD is -so easy, this must be easy too, right? - -These were the only changes I had to make to my =httpd.conf= to get -=acme-client= to work. This is described in the =acme-client= man -page. -#+BEGIN_SRC diff ---- httpd.conf -+++ httpd.conf.new -@@ -1,4 +1,19 @@ - server "lambda.cx" { - listen on * port 80 - root "/htdocs/lambda.cx" -+ location "/.well-known/acme-challenge/*" { -+ root "/acme" -+ request strip 2 -+ } - } -#+END_SRC - -After that, I reloaded =httpd= with ~rcctl reload httpd~ - -I then copied the example config from =/etc/examples/acme-client.conf= -to =/etc/acme-client=. This is what the modifications to the example I -made look like. - -#+BEGIN_SRC diff ---- acme-client.conf -+++ acme-client.conf.new -@@ -1,19 +1,19 @@ - # - # $OpenBSD: acme-client.conf,v 1.2 2019/06/07 08:08:30 florian Exp $ - # - authority letsencrypt { - api url "https://acme-v02.api.letsencrypt.org/directory" - account key "/etc/acme/letsencrypt-privkey.pem" - } - - authority letsencrypt-staging { - api url "https://acme-staging-v02.api.letsencrypt.org/directory" - account key "/etc/acme/letsencrypt-staging-privkey.pem" - } - --domain example.com { -- alternative names { secure.example.com } -- domain key "/etc/ssl/private/example.com.key" -- domain full chain certificate "/etc/ssl/example.com.fullchain.pem" -+domain lambda.cx { -+ # alternative names { www.lambda.cx } -+ domain key "/etc/ssl/private/lambda.cx.key" -+ domain full chain certificate "/etc/ssl/lambda.cx.fullchain.pem" - sign with letsencrypt - } -#+END_SRC - -It's a pretty small change. I have the alternative name line commented -out because I only have =lambda.cx= pointing at my server and not -=www.lambda.cx=. Although if I did I would un-comment it. I could also -add sub-domains like =sub.lambda.cx= in that area separated by a -space. - -After that I just had to run ~acme-client -v lambda.cx~ (-v for -verbosity) and it generated the certificates. - -Then I added a =crontab= entry (using =crontab -e=) to run once a day -at a random time and reload =httpd=. - -#+BEGIN_SRC -~ ~ * * * acme-client lambda.cx && rcctl reload httpd -#+END_SRC - -Finally to use the new certificates I added the following lines to my -=httpd.conf=. - -#+BEGIN_SRC diff ---- httpd.conf -+++ httpd.conf.new -@@ -1,8 +1,21 @@ - server "lambda.cx" { - listen on * port 80 - root "/htdocs/lambda.cx" - location "/.well-known/acme-challenge/*" { - root "/acme" - request strip 2 - } - } -+ -+server "lambda.cx" { -+ listen on * tls port 443 -+ tls { -+ certificate "/etc/ssl/lambda.cx.fullchain.pem" -+ key "/etc/ssl/private/lambda.cx.key" -+ } -+ root "/htdocs/lambda.cx" -+ location "/.well-known/acme-challenge/*" { -+ root "/acme" -+ request strip 2 -+ } -+} -#+END_SRC - -I reloaded httpd with ~rcctl reload httpd~ and that was it, working -certificate! diff --git a/content/post/letsencrypt-on-openbsd/index.org b/content/post/letsencrypt-on-openbsd/index.org new file mode 100644 index 0000000..556404b --- /dev/null +++ b/content/post/letsencrypt-on-openbsd/index.org @@ -0,0 +1,122 @@ +#+TITLE: Let's Encrypt on OpenBSD +#+DATE: 2020-06-16T22:56:27-04:00 +#+DRAFT: false +#+DESCRIPTION: Setting up acme-client on OpenBSD +#+TAGS[]: openbsd httpd letsencrypt acme-client +#+KEYWORDS[]: openbsd httpd letsencrypt acme-client +#+SLUG: +#+SUMMARY: + +#+ATTR_HTML: :alt Let's Encrypt OpenBSD +#+ATTR_HTML: :title Let's Encrypt OpenBSD +[[file:openbsd%20letsencrypt.png]] + +So I have an OpenBSD server serving a static website using +=httpd=. I've been thinking for a while I should add an SSL +certificate, but never got around to it because it was just a small +hobby website and it didn't require any real attention. + +Today while watching one of the OpenBSD tutorials at BSDCan, I thought +it was finally time. Since configuring everything else in OpenBSD is +so easy, this must be easy too, right? + +These were the only changes I had to make to my =httpd.conf= to get +=acme-client= to work. This is described in the =acme-client= man +page. +#+BEGIN_SRC diff +--- httpd.conf ++++ httpd.conf.new +@@ -1,4 +1,19 @@ + server "lambda.cx" { + listen on * port 80 + root "/htdocs/lambda.cx" ++ location "/.well-known/acme-challenge/*" { ++ root "/acme" ++ request strip 2 ++ } + } +#+END_SRC + +After that, I reloaded =httpd= with ~rcctl reload httpd~ + +I then copied the example config from =/etc/examples/acme-client.conf= +to =/etc/acme-client=. This is what the modifications to the example I +made look like. + +#+BEGIN_SRC diff +--- acme-client.conf ++++ acme-client.conf.new +@@ -1,19 +1,19 @@ + # + # $OpenBSD: acme-client.conf,v 1.2 2019/06/07 08:08:30 florian Exp $ + # + authority letsencrypt { + api url "https://acme-v02.api.letsencrypt.org/directory" + account key "/etc/acme/letsencrypt-privkey.pem" + } + + authority letsencrypt-staging { + api url "https://acme-staging-v02.api.letsencrypt.org/directory" + account key "/etc/acme/letsencrypt-staging-privkey.pem" + } + +-domain example.com { +- alternative names { secure.example.com } +- domain key "/etc/ssl/private/example.com.key" +- domain full chain certificate "/etc/ssl/example.com.fullchain.pem" ++domain lambda.cx { ++ # alternative names { www.lambda.cx } ++ domain key "/etc/ssl/private/lambda.cx.key" ++ domain full chain certificate "/etc/ssl/lambda.cx.fullchain.pem" + sign with letsencrypt + } +#+END_SRC + +It's a pretty small change. I have the alternative name line commented +out because I only have =lambda.cx= pointing at my server and not +=www.lambda.cx=. Although if I did I would un-comment it. I could also +add sub-domains like =sub.lambda.cx= in that area separated by a +space. + +After that I just had to run ~acme-client -v lambda.cx~ (-v for +verbosity) and it generated the certificates. + +Then I added a =crontab= entry (using =crontab -e=) to run once a day +at a random time and reload =httpd=. + +#+BEGIN_SRC +~ ~ * * * acme-client lambda.cx && rcctl reload httpd +#+END_SRC + +Finally to use the new certificates I added the following lines to my +=httpd.conf=. + +#+BEGIN_SRC diff +--- httpd.conf ++++ httpd.conf.new +@@ -1,8 +1,21 @@ + server "lambda.cx" { + listen on * port 80 + root "/htdocs/lambda.cx" + location "/.well-known/acme-challenge/*" { + root "/acme" + request strip 2 + } + } ++ ++server "lambda.cx" { ++ listen on * tls port 443 ++ tls { ++ certificate "/etc/ssl/lambda.cx.fullchain.pem" ++ key "/etc/ssl/private/lambda.cx.key" ++ } ++ root "/htdocs/lambda.cx" ++ location "/.well-known/acme-challenge/*" { ++ root "/acme" ++ request strip 2 ++ } ++} +#+END_SRC + +I reloaded httpd with ~rcctl reload httpd~ and that was it, working +certificate! diff --git a/content/post/openvpn-issues-openbsd-6.7.org b/content/post/openvpn-issues-openbsd-6.7.org deleted file mode 100644 index a9c34bd..0000000 --- a/content/post/openvpn-issues-openbsd-6.7.org +++ /dev/null @@ -1,72 +0,0 @@ -#+TITLE: Issues with OpenVPN on OpenBSD 6.7 -#+DATE: 2020-06-14T14:08:06-04:00 -#+DRAFT: false -#+DESCRIPTION: -#+TAGS[]: openvpn openbsd libressl -#+KEYWORDS[]: -#+SLUG: -#+SUMMARY: - -#+ATTR_HTML: :alt No connection to ProtonVPN from OpenBSD -#+ATTR_HTML: :title No connection to ProtonVPN from OpenBSD -[[file:openbsd%20protonvpn%20no%20connection.png]] - -I have an OpenBSD VPN gateway I use to send all traffic it receives -over a VPN connection, and I noticed that no traffic was going through. - -I'd been using ProtonVPN as my provider for months prior to this -without any issues, so it was very confusing when it stopped working. - -No matter which VPN profile I used from ProtonVPN, it always gets -stuck after the step =TLS: Initial packet from -[AF_INET]XXX.XXX.XXX.XXX:YY=. Regardless of whether I tried the -individual server profiles, country profiles, free, or plus profiles. - -I tried starting openvpn with maximum verbosity. Everything launched -exactly as it should, until it gets to the TLS handshake, where it -failed to get a response. - -#+BEGIN_SRC -Sun Jun 14 15:37:22 2020 us=577519 UDP link local: (not bound) -Sun Jun 14 15:37:22 2020 us=577532 UDP link remote: [AF_INET]XXX.XXX.XXX.XXX:YYYY -Sun Jun 14 15:37:22 2020 us=577650 UDP WRITE [86] to [AF_INET]XXX.XXX.XXX.XXX:YYYY: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #1 ] [ ] pid=0 DATA len=0 -Sun Jun 14 15:37:22 2020 us=739355 UDP READ [98] from [AF_INET]XXX.XXX.XXX.XXX:YYYY: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #1 ] [ 0 ] pid=0 DATA len=0 -Sun Jun 14 15:37:22 2020 us=739517 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:YYYY, sid=19fe5aac 2d00f4aa -Sun Jun 14 15:37:22 2020 us=739658 UDP WRITE [94] to [AF_INET]XXX.XXX.XXX.XXX:YYYY: P_ACK_V1 kid=0 pid=[ #2 ] [ 0 ] -Sun Jun 14 15:37:22 2020 us=739798 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this -Sun Jun 14 15:37:22 2020 us=739900 UDP WRITE [331] to [AF_INET]XXX.XXX.XXX.XXX:YYYY: P_CONTROL_V1 kid=0 pid=[ #3 ] [ ] pid=1 DATA len=245 -Sun Jun 14 15:37:24 2020 us=832019 UDP WRITE [331] to [AF_INET]XXX.XXX.XXX.XXX:YYYY: P_CONTROL_V1 kid=0 pid=[ #4 ] [ ] pid=1 DATA len=245 -Sun Jun 14 15:37:29 2020 us=32189 UDP WRITE [331] to [AF_INET]XXX.XXX.XXX.XXX:YYYY: P_CONTROL_V1 kid=0 pid=[ #5 ] [ ] pid=1 DATA len=245 -#+END_SRC - -It just kept repeating the write until it timed out after 60 -seconds. It was like this for every country, on every port. Even using -the TCP profiles, but instead there the connection would get reset -almost immediately instead of timing out. - -I tried several free VPNs I found online just to compare, and all of -them worked without issue. This problem has only happened for me with -ProtonVPN servers. - -I tried connecting using both my desktop machine, and an Ubuntu VM, -both of which were able to connect without issue. The problem wasn't -with the account itself. - -I tried using another OpenBSD VM on my network, and the result was the -same as the VPN gateway, a timeout. I even spun up a fresh OpenBSD VM -in Vultr to see if the issue persisted on a new install in a different -network. The issue was still there. - -I was sure to check that the system clocks were correct on each -machine, and also tried commenting out all lines in the VPN profile -that weren't strictly required to make the connection, like mtu and -compression settings. - -As a final attempt, I tried installing OpenVPN with =mbedtls=. For all -my previous experiments, I had been using the default openvpn package, -which uses OpenBSD's LibreSSL. That time it worked perfectly. - -It occurred to me that this had been the first time I'd checked up on -the VPN gateway since updating to OpenBSD 6.7. I guess something about -a recent LibreSSL update has broken a feature OpenVPN relies on in -certain situations. diff --git a/content/post/openvpn-issues-openbsd-6.7/index.org b/content/post/openvpn-issues-openbsd-6.7/index.org new file mode 100644 index 0000000..a9c34bd --- /dev/null +++ b/content/post/openvpn-issues-openbsd-6.7/index.org @@ -0,0 +1,72 @@ +#+TITLE: Issues with OpenVPN on OpenBSD 6.7 +#+DATE: 2020-06-14T14:08:06-04:00 +#+DRAFT: false +#+DESCRIPTION: +#+TAGS[]: openvpn openbsd libressl +#+KEYWORDS[]: +#+SLUG: +#+SUMMARY: + +#+ATTR_HTML: :alt No connection to ProtonVPN from OpenBSD +#+ATTR_HTML: :title No connection to ProtonVPN from OpenBSD +[[file:openbsd%20protonvpn%20no%20connection.png]] + +I have an OpenBSD VPN gateway I use to send all traffic it receives +over a VPN connection, and I noticed that no traffic was going through. + +I'd been using ProtonVPN as my provider for months prior to this +without any issues, so it was very confusing when it stopped working. + +No matter which VPN profile I used from ProtonVPN, it always gets +stuck after the step =TLS: Initial packet from +[AF_INET]XXX.XXX.XXX.XXX:YY=. Regardless of whether I tried the +individual server profiles, country profiles, free, or plus profiles. + +I tried starting openvpn with maximum verbosity. Everything launched +exactly as it should, until it gets to the TLS handshake, where it +failed to get a response. + +#+BEGIN_SRC +Sun Jun 14 15:37:22 2020 us=577519 UDP link local: (not bound) +Sun Jun 14 15:37:22 2020 us=577532 UDP link remote: [AF_INET]XXX.XXX.XXX.XXX:YYYY +Sun Jun 14 15:37:22 2020 us=577650 UDP WRITE [86] to [AF_INET]XXX.XXX.XXX.XXX:YYYY: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #1 ] [ ] pid=0 DATA len=0 +Sun Jun 14 15:37:22 2020 us=739355 UDP READ [98] from [AF_INET]XXX.XXX.XXX.XXX:YYYY: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #1 ] [ 0 ] pid=0 DATA len=0 +Sun Jun 14 15:37:22 2020 us=739517 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:YYYY, sid=19fe5aac 2d00f4aa +Sun Jun 14 15:37:22 2020 us=739658 UDP WRITE [94] to [AF_INET]XXX.XXX.XXX.XXX:YYYY: P_ACK_V1 kid=0 pid=[ #2 ] [ 0 ] +Sun Jun 14 15:37:22 2020 us=739798 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this +Sun Jun 14 15:37:22 2020 us=739900 UDP WRITE [331] to [AF_INET]XXX.XXX.XXX.XXX:YYYY: P_CONTROL_V1 kid=0 pid=[ #3 ] [ ] pid=1 DATA len=245 +Sun Jun 14 15:37:24 2020 us=832019 UDP WRITE [331] to [AF_INET]XXX.XXX.XXX.XXX:YYYY: P_CONTROL_V1 kid=0 pid=[ #4 ] [ ] pid=1 DATA len=245 +Sun Jun 14 15:37:29 2020 us=32189 UDP WRITE [331] to [AF_INET]XXX.XXX.XXX.XXX:YYYY: P_CONTROL_V1 kid=0 pid=[ #5 ] [ ] pid=1 DATA len=245 +#+END_SRC + +It just kept repeating the write until it timed out after 60 +seconds. It was like this for every country, on every port. Even using +the TCP profiles, but instead there the connection would get reset +almost immediately instead of timing out. + +I tried several free VPNs I found online just to compare, and all of +them worked without issue. This problem has only happened for me with +ProtonVPN servers. + +I tried connecting using both my desktop machine, and an Ubuntu VM, +both of which were able to connect without issue. The problem wasn't +with the account itself. + +I tried using another OpenBSD VM on my network, and the result was the +same as the VPN gateway, a timeout. I even spun up a fresh OpenBSD VM +in Vultr to see if the issue persisted on a new install in a different +network. The issue was still there. + +I was sure to check that the system clocks were correct on each +machine, and also tried commenting out all lines in the VPN profile +that weren't strictly required to make the connection, like mtu and +compression settings. + +As a final attempt, I tried installing OpenVPN with =mbedtls=. For all +my previous experiments, I had been using the default openvpn package, +which uses OpenBSD's LibreSSL. That time it worked perfectly. + +It occurred to me that this had been the first time I'd checked up on +the VPN gateway since updating to OpenBSD 6.7. I guess something about +a recent LibreSSL update has broken a feature OpenVPN relies on in +certain situations. diff --git a/content/post/pcengines-comparison.org b/content/post/pcengines-comparison.org deleted file mode 100644 index a80f773..0000000 --- a/content/post/pcengines-comparison.org +++ /dev/null @@ -1,96 +0,0 @@ -#+TITLE: PC Engines APU Comparison -#+DATE: 2020-06-17T00:50:06-04:00 -#+DRAFT: false -#+DESCRIPTION: Comparison between PC Engines APU machines -#+TAGS[]: hardware pcengines -#+KEYWORDS[]: hardware pcengines -#+SLUG: -#+SUMMARY: - -#+ATTR_HTML: :alt PC Engines Comparison -#+ATTR_HTML: :title PC Engines Comparison -[[file:pc%20engines%20vs.png]] - -I've been looking at the [[https://www.pcengines.ch/apu2.htm][PC Engines APU]] line for a while. They're a -line of medium size single board PCs with a DB9 serial connector and -no VGA port. They also have gigabit Ethernet. Because of this they're -often used as firewall machines. - -I want to get one and use it as either the home router, or an -experimental server to mess around with. Quite a few OpenBSD folks use -them and recommend them as OpenBSD router and server hardware. They -aren't too expensive, have decent specs and a small physical -footprint. - -One thing that's always confused me was the naming scheme, which is a -little confusing at first. Initially there was the APU, then the APU2, -as described on their site, which makes sense. Then the APU model -numbers get a little confusing. They come in several variants, I'll -list them here for context. - -#+CAPTION: Taken from the PC Engines website -#+BEGIN_SRC - apu2d0 (2 GB DRAM, 2 i211AT NICs) - apu2e2 (2 GB DRAM, 3 i211AT NICs) - apu2e4 (4 GB DRAM, 3 i210AT NICs) - apu3c2 (2 GB DRAM, 3 i211AT NICs, optimized for 3G/LTE modems) - apu3c4 (4 GB DRAM, 3 i211AT NICs, optimized for 3G/LTE modems) - apu4d2 (2 GB DRAM, 4 i211AT NICs) - apu4d4 (4 GB DRAM, 4 i211AT NICs) - #+END_SRC - -What do the letters between the numbers mean? What is the significance -of the numbers in the first place? - -Let's take the =apu3c2= as an example. The =3= here means it's version -3 of the APU board. The APU 1 is no longer sold, so it's left out of -the list on the PC Engines website, along with most of their -re-sellers. The letter =c= is the revision of that board. It's pretty -much irrelevant for comparison. You'll want to get the most recent -one, as listed on the PC Engines website. The revisions are mostly -minor tweaks to the board. The final number, =2=, is the number of gigabytes -of RAM (in most cases). - -The APU2E2 boards have a single mSATA slot, and a regular SATA -connector, two mPCIe slots, and a SIM tray. It comes with 2 external -USB 3.0 type A ports, 2 internal USB 2.0 ports (header only), an SD -card slot, and a GPIO header. It also has 3 Intel i211AT gigabit -NICs. Using the SIM tray will remove the ability to use one of the two -mPCIe slots. - -So what are the major differences between version numbers? They all -use the same CPU, the quad core AMD Embedded G series GX-412TC running -at 1 GHz. Most other components on the boards are the same as -well. I'll give a description of the differences relative to the APU2 -board. - -The APU2D0 is the same as the regular APU2, but without a GPIO -headers, and it has only 2 NICs. - -The APU3 has an extra SIM tray, and the first slot, which is mSATA -only on the APU2, can be used as either an mSATA or USB 3G/LTE Modem -slot. The second slot can only be used for a modem. It also lets you -do GPIO tray swapping and failover, so you can use only a single modem -for 2 SIMs. - -The APU4D2 has 4 NICs instead of 3, and the second slot is modem -only. It has 2 GB of RAM. - -The APU4D4 is the same as the APU4D2, except it has dual SIM trays. It -has 4 GB of RAM. - -I found a lot of this information wasn't really obvious to upon first -reading the PC Engines website, as there's no direct comparison -between the board, and the site relies on you flipping between pages -to find the details. The re-seller website I looked at also didn't -elaborate on the differences. - -| Board | RAM | Slot 1 | Slot 2 | Slot 3 | Ethernet Controllers | SIM Slots | USB 2.0 | Headers | -|--------+------+-------------+-------------+--------+----------------------+-----------+---------+---------| -| [[https://www.pcengines.ch/apu2d0.htm][apu2d0]] | 2 GB | mSATA | mPCIe/Modem | mPCIe | 2 i211AT | 1 | 2 | No | -| [[https://www.pcengines.ch/apu2e2.htm][apu2e2]] | 2 GB | mSATA | mPCIe/Modem | mPCIe | 3 i211AT | 1 | 2 | Yes | -| [[https://www.pcengines.ch/apu2e4.htm][apu2e4]] | 4 GB | mSATA | mPCIe/Modem | mPCIe | 3 i210AT | 1 | 2 | Yes | -| [[https://www.pcengines.ch/apu3c2.htm][apu3c2]] | 2 GB | mSATA/Modem | Modem | mPCIe | 3 i211AT | 2 | 4 | Yes | -| [[https://www.pcengines.ch/apu3c4.htm][apu3c4]] | 4 GB | mSATA/Modem | Modem | mPCIe | 3 i211AT | 2 | 4 | Yes | -| [[https://www.pcengines.ch/apu4d2.htm][apu4d2]] | 2 GB | mSATA | Modem | mPCIe | 4 i211AT | 1 | 2 | Yes | -| [[https://www.pcengines.ch/apu4d4.htm][apu4d4]] | 4 GB | mSATA/Modem | Modem | mPCIe | 4 i211AT | 2 | 2 | Yes | diff --git a/content/post/pcengines-comparison/index.org b/content/post/pcengines-comparison/index.org new file mode 100644 index 0000000..a80f773 --- /dev/null +++ b/content/post/pcengines-comparison/index.org @@ -0,0 +1,96 @@ +#+TITLE: PC Engines APU Comparison +#+DATE: 2020-06-17T00:50:06-04:00 +#+DRAFT: false +#+DESCRIPTION: Comparison between PC Engines APU machines +#+TAGS[]: hardware pcengines +#+KEYWORDS[]: hardware pcengines +#+SLUG: +#+SUMMARY: + +#+ATTR_HTML: :alt PC Engines Comparison +#+ATTR_HTML: :title PC Engines Comparison +[[file:pc%20engines%20vs.png]] + +I've been looking at the [[https://www.pcengines.ch/apu2.htm][PC Engines APU]] line for a while. They're a +line of medium size single board PCs with a DB9 serial connector and +no VGA port. They also have gigabit Ethernet. Because of this they're +often used as firewall machines. + +I want to get one and use it as either the home router, or an +experimental server to mess around with. Quite a few OpenBSD folks use +them and recommend them as OpenBSD router and server hardware. They +aren't too expensive, have decent specs and a small physical +footprint. + +One thing that's always confused me was the naming scheme, which is a +little confusing at first. Initially there was the APU, then the APU2, +as described on their site, which makes sense. Then the APU model +numbers get a little confusing. They come in several variants, I'll +list them here for context. + +#+CAPTION: Taken from the PC Engines website +#+BEGIN_SRC + apu2d0 (2 GB DRAM, 2 i211AT NICs) + apu2e2 (2 GB DRAM, 3 i211AT NICs) + apu2e4 (4 GB DRAM, 3 i210AT NICs) + apu3c2 (2 GB DRAM, 3 i211AT NICs, optimized for 3G/LTE modems) + apu3c4 (4 GB DRAM, 3 i211AT NICs, optimized for 3G/LTE modems) + apu4d2 (2 GB DRAM, 4 i211AT NICs) + apu4d4 (4 GB DRAM, 4 i211AT NICs) + #+END_SRC + +What do the letters between the numbers mean? What is the significance +of the numbers in the first place? + +Let's take the =apu3c2= as an example. The =3= here means it's version +3 of the APU board. The APU 1 is no longer sold, so it's left out of +the list on the PC Engines website, along with most of their +re-sellers. The letter =c= is the revision of that board. It's pretty +much irrelevant for comparison. You'll want to get the most recent +one, as listed on the PC Engines website. The revisions are mostly +minor tweaks to the board. The final number, =2=, is the number of gigabytes +of RAM (in most cases). + +The APU2E2 boards have a single mSATA slot, and a regular SATA +connector, two mPCIe slots, and a SIM tray. It comes with 2 external +USB 3.0 type A ports, 2 internal USB 2.0 ports (header only), an SD +card slot, and a GPIO header. It also has 3 Intel i211AT gigabit +NICs. Using the SIM tray will remove the ability to use one of the two +mPCIe slots. + +So what are the major differences between version numbers? They all +use the same CPU, the quad core AMD Embedded G series GX-412TC running +at 1 GHz. Most other components on the boards are the same as +well. I'll give a description of the differences relative to the APU2 +board. + +The APU2D0 is the same as the regular APU2, but without a GPIO +headers, and it has only 2 NICs. + +The APU3 has an extra SIM tray, and the first slot, which is mSATA +only on the APU2, can be used as either an mSATA or USB 3G/LTE Modem +slot. The second slot can only be used for a modem. It also lets you +do GPIO tray swapping and failover, so you can use only a single modem +for 2 SIMs. + +The APU4D2 has 4 NICs instead of 3, and the second slot is modem +only. It has 2 GB of RAM. + +The APU4D4 is the same as the APU4D2, except it has dual SIM trays. It +has 4 GB of RAM. + +I found a lot of this information wasn't really obvious to upon first +reading the PC Engines website, as there's no direct comparison +between the board, and the site relies on you flipping between pages +to find the details. The re-seller website I looked at also didn't +elaborate on the differences. + +| Board | RAM | Slot 1 | Slot 2 | Slot 3 | Ethernet Controllers | SIM Slots | USB 2.0 | Headers | +|--------+------+-------------+-------------+--------+----------------------+-----------+---------+---------| +| [[https://www.pcengines.ch/apu2d0.htm][apu2d0]] | 2 GB | mSATA | mPCIe/Modem | mPCIe | 2 i211AT | 1 | 2 | No | +| [[https://www.pcengines.ch/apu2e2.htm][apu2e2]] | 2 GB | mSATA | mPCIe/Modem | mPCIe | 3 i211AT | 1 | 2 | Yes | +| [[https://www.pcengines.ch/apu2e4.htm][apu2e4]] | 4 GB | mSATA | mPCIe/Modem | mPCIe | 3 i210AT | 1 | 2 | Yes | +| [[https://www.pcengines.ch/apu3c2.htm][apu3c2]] | 2 GB | mSATA/Modem | Modem | mPCIe | 3 i211AT | 2 | 4 | Yes | +| [[https://www.pcengines.ch/apu3c4.htm][apu3c4]] | 4 GB | mSATA/Modem | Modem | mPCIe | 3 i211AT | 2 | 4 | Yes | +| [[https://www.pcengines.ch/apu4d2.htm][apu4d2]] | 2 GB | mSATA | Modem | mPCIe | 4 i211AT | 1 | 2 | Yes | +| [[https://www.pcengines.ch/apu4d4.htm][apu4d4]] | 4 GB | mSATA/Modem | Modem | mPCIe | 4 i211AT | 2 | 2 | Yes | diff --git a/content/post/stop-mg-from-making-a-mess.org b/content/post/stop-mg-from-making-a-mess.org deleted file mode 100644 index 5464a7d..0000000 --- a/content/post/stop-mg-from-making-a-mess.org +++ /dev/null @@ -1,53 +0,0 @@ -#+TITLE: Stop Mg From Making A Mess -#+DATE: 2020-06-18T16:04:33-04:00 -#+DRAFT: false -#+DESCRIPTION: -#+TAGS[]: openbsd emacs -#+KEYWORDS[]: -#+SLUG: -#+SUMMARY: - -#+ATTR_HTML: :alt mg trash file -#+ATTR_HTML: :title mg trash file -[[file:mg%20trash%20file.png]] - -If you've been an OpenBSD user for any period of time, you probably -know what =mg= is. For those who don't know, =mg= stands for -MicroGnuEmacs. It's a small clone of Emacs maintained by the OpenBSD -team that's included with the base system. - -Being an Emacs user, I love that =mg= is part of the OpenBSD base -system. It's great to have an editor that has familiar keybinds on a -system that I haven't had the time to install any packages on. It also -has (in my opinion), more useful features than =vi=, like =auto-fill-mode= -and =dired=. - -Despite all of the excellent things it emulates from Emacs, it also -emulates a couple behaviours from Emacs that I find a little -annoying. One of those behaviours is leaving backup files everywhere -when editing. Backup files have the original file name, with a tilde -appended to the end. So if you're editing =pf.conf=, =mg= will -automatically create a backup file called =pf.conf~= in the same -directory. - -Backup files can be incredibly useful if you same a mistake while -editing and you want to see what the original file looked like, but -after a while of editing files, seeing your =/etc/= littered with -files ending in =~= can be a little annoying. - -Fortunately the creators of =mg= are aware of this issue and have -provided a way to deal with it. - -Edit the =.mg= in your home directory, or create it if it doesn't -exist. Then add the following line - -#+BEGIN_SRC -backup-to-home-directory -#+END_SRC - -That's it. Now =mg= will still create backup files, but it will save -them to =~/.mg.d/= instead of the directory of the file you're -editing. It saves the file as the full path to the original file, with -the forward slashes replaced by exclamation marks. So if you were -editing =/etc/pf.conf=, the backup file will be saved as -=~/.mg.d/!etc!pf.conf~=. diff --git a/content/post/stop-mg-from-making-a-mess/index.org b/content/post/stop-mg-from-making-a-mess/index.org new file mode 100644 index 0000000..0e88fd7 --- /dev/null +++ b/content/post/stop-mg-from-making-a-mess/index.org @@ -0,0 +1,53 @@ +#+TITLE: Stop mg From Making A Mess +#+DATE: 2020-06-18T16:04:33-04:00 +#+DRAFT: false +#+DESCRIPTION: +#+TAGS[]: openbsd emacs mg +#+KEYWORDS[]: +#+SLUG: +#+SUMMARY: + +#+ATTR_HTML: :alt mg trash file +#+ATTR_HTML: :title mg trash file +[[file:mg%20trash%20file.png]] + +If you've been an OpenBSD user for any period of time, you probably +know what =mg= is. For those who don't know, =mg= stands for +MicroGnuEmacs. It's a small clone of Emacs maintained by the OpenBSD +team that's included with the base system. + +Being an Emacs user, I love that =mg= is part of the OpenBSD base +system. It's great to have an editor that has familiar keybinds on a +system that I haven't had the time to install any packages on. It also +has (in my opinion), more useful features than =vi=, like =auto-fill-mode= +and =dired=. + +Despite all of the excellent things it emulates from Emacs, it also +emulates a couple behaviours from Emacs that I find a little +annoying. One of those behaviours is leaving backup files everywhere +when editing. Backup files have the original file name, with a tilde +appended to the end. So if you're editing =pf.conf=, =mg= will +automatically create a backup file called =pf.conf~= in the same +directory. + +Backup files can be incredibly useful if you same a mistake while +editing and you want to see what the original file looked like, but +after a while of editing files, seeing your =/etc/= littered with +files ending in =~= can be a little annoying. + +Fortunately the creators of =mg= are aware of this issue and have +provided a way to deal with it. + +Edit the =.mg= in your home directory, or create it if it doesn't +exist. Then add the following line + +#+BEGIN_SRC +backup-to-home-directory +#+END_SRC + +That's it. Now =mg= will still create backup files, but it will save +them to =~/.mg.d/= instead of the directory of the file you're +editing. It saves the file as the full path to the original file, with +the forward slashes replaced by exclamation marks. So if you were +editing =/etc/pf.conf=, the backup file will be saved as +=~/.mg.d/!etc!pf.conf~=. -- cgit v1.2.3