Hi. I'm jon.404, a Unix/Linux/Database/Openstack/Kubernetes Administrator, AWS/GCP/Azure Engineer, mathematics enthusiast, and amateur philosopher. This is where I rant about that which upsets me, laugh about that which amuses me, and jabber about that which holds my interest most: *nix.
Hashicorp Vault on OpenBSD-6.9 CURRENT
At $DAYJOB, I'm in a position of doing crypto related work again, and while not quite as in depth as the HSM work I did in previous jobs, it's still fun. One of the core components I'm tasked with being an expert on is Hashicorp Vault (which I've used in previous jobs, but I've not been in a position of administration before now). I've learned over the years that if you want to become familiar with a software system quickly, you need to build it on OpenBSD. Why? Because 1) I like OpenBSD (ok, not really an answer), and 2) OpenBSD doesn't let software goof off and get away with stupid coding practices. This means you'll learn a *lot* about the software and how it behaves in a very short amount of time. But before you can do that, you have to build it.
Typical caveats apply: These steps work *as of this very moment* and *for me, on my system*. I obviously cannot guarantee it will work in a year or two, or even another month, or even in 5 minutes. I put this information here to remind me what changes I had to make to get this working, and maybe it'll help someone else work around issues they're seeing.
I'm using a 4G RockPro64 with a 120 GB nvme mounted on /home/vault. Yes, 4G is the absolute bare minimum RAM for Vault. Don't tell me how to live (see notes below)! The nvme is encrypted, of course (and none of this build shenaniginery is necessary on i386/amd64, because Vault offers pre-compiled binaries, if you're into that sort of thing). Added bonus: I'm building with the ui. Yes, you can build without (and that simplifies the process tremendously), but I want the ui if only because I want to be able to say I'm building all of it.
Also, it goes without saying that this build isn't considered "official" by Hashicorp, so don't expect to hook up an Enterprise license or any of that stuff. I'm using this as a learning opportunity and to store a few passwords for my home network. That's pretty much it.
First up, need to install go, gmake, g++, yarn, node, python2, zip, and git (go minimum at the time of this writing is 1.16.5, and 6.9-RELEASE has 1.16.2, so vault will complain and bail. Before it can realize it needs to bail, though, you'll have to fix the $VAULTSRC/scripts/goversioncheck.sh script (the regex on line 12 didn't work for determining the go version, I had to replace it with:
Once that's done, you'll realize you need to be on 6.9-CURRENT for go 1.16.5, so an OS upgrade later you'll need to update packages and start the install over again. Or maybe not, because you're reading this and you knew that before you made the same mistake I did. Note to future you: you'll also need to apply this change so gox doesn't build everything *except* openbsd/arm64. (That was a fun discovery!)
I'm following the standard process here:
https://www.vaultproject.io/docs/ins...ng-from-source
Basically, setup your environment variables TMPDIR (I used ~/tmp...more on that in a bit), CXX="/usr/local/bin/eg++", GOPATH (I used ~/go), and GOGC (I used 25 as a hackish workaround for out of memory issues during the build to force the go garbage collector to be a bit more aggressive...I also needed to add a 4G swap on the nvme ssd for the ui build...more on that in a few), make your install dir, clone the code, and "gmake bootstrap && gmake bin". Then wait a good bit, because Vault will download something like 2+ GB of code to build, and build it with *zero* errors. No joke.
Except, it's not *quite* that straightforward. As of 7/19/2021, the build doesn't seem to be fully ironed out, even though an issue on their github seems to suggest it would be done sometime in 2018 (https://github.com/hashicorp/vault/i...ment-379257350). They overshot that target, I guess.
So when that fails, make sure you "gmake static-dist bin" (preferably after the gmake bootstrap, of course). This will fail in $TMPDIR/yarn-GIBBERISH/ because node is missing, so I set TMPDIR to something on my vault ssd and copied node into the TMPDIR (yarn seems to want it there, oddly). yarn will take a while, especially considering this is supposed to be the "static" portion of the web ui (which, ironically, needs g++...perhaps it's not "static" as in webui, but static as in "not dynamically linked"? But then why Javascript?! I digress). yarn will also complain verbosely that certain packages aren't available, but the Makefile is doing --ignore-optional, so other than a bunch of warnings it doesn't have any impact.
Aaaand just keep waiting for yarn.
And waiting...
Still waiting...
In the interim, I set up an automation in HomeAssistant to dump US earthquake data to discord so I could see in near-realtime how often earthquakes are occurring today. Alaska, California, and Hawaii are quite active! Granted, the vast majority of these earthquakes are small, less than 2.0 on the Richter scale, but...it's an earthquake. Who knew?
Done in 1863.29s.
\o/ yarn is done, but there is still ember and the rest of the targets to go. Continuing on!
Oh, one more thing...it's probably not a bad idea to turn the fan on. OpenBSD-CURRENT on the rockpro64 (as of right now) doesn't have automatic fan control (that I'm aware of), so I jumpered the SoC fan to pins 2 and 4 to get some airflow going).
BEFORE TURNING FAN ON
vault# sysctl hw.sensors
hw.sensors.rktemp0.temp0=60.62 degC (CPU)
hw.sensors.rktemp0.temp1=58.89 degC (GPU)
AFTER TURNING FAN ON
vault# sysctl hw.sensors
hw.sensors.rktemp0.temp0=40.55 degC (CPU)
hw.sensors.rktemp0.temp1=39.38 degC (GPU)
There's a joke in there about building "ember" on your CPU while the fan is off, but it escapes me currently.
After running the machine into the ground (out of memory/swap...normally it wouldn't be possible for a user to run all of the memory out on OpenBSD, but I put the vault user in a custom login class heh), I decided to give it another shot. That also ended up bombing out, so I've hit a cross-roads, and after adding the previously mentioned 4G swap on the nvme ssd, relaunching the build, and getting distracted on other stuff, I came back to static-dist success!
Now, after all that, I can gmake bin, and have vault. At least, in theory.
Bracing myself for another epic disaster of idiotic proportions...but it never came. With all the shenanigans out of the way, I can finally configure vault.
I'll save that for next time. =)
Typical caveats apply: These steps work *as of this very moment* and *for me, on my system*. I obviously cannot guarantee it will work in a year or two, or even another month, or even in 5 minutes. I put this information here to remind me what changes I had to make to get this working, and maybe it'll help someone else work around issues they're seeing.
I'm using a 4G RockPro64 with a 120 GB nvme mounted on /home/vault. Yes, 4G is the absolute bare minimum RAM for Vault. Don't tell me how to live (see notes below)! The nvme is encrypted, of course (and none of this build shenaniginery is necessary on i386/amd64, because Vault offers pre-compiled binaries, if you're into that sort of thing). Added bonus: I'm building with the ui. Yes, you can build without (and that simplifies the process tremendously), but I want the ui if only because I want to be able to say I'm building all of it.
Also, it goes without saying that this build isn't considered "official" by Hashicorp, so don't expect to hook up an Enterprise license or any of that stuff. I'm using this as a learning opportunity and to store a few passwords for my home network. That's pretty much it.
First up, need to install go, gmake, g++, yarn, node, python2, zip, and git (go minimum at the time of this writing is 1.16.5, and 6.9-RELEASE has 1.16.2, so vault will complain and bail. Before it can realize it needs to bail, though, you'll have to fix the $VAULTSRC/scripts/goversioncheck.sh script (the regex on line 12 didn't work for determining the go version, I had to replace it with:
Code:
GO_VERSION=$($GO_CMD version | egrep -o 'go[0-9]+\.[0-9]+\.[0-9]+' | tr -d 'go'))
I'm following the standard process here:
https://www.vaultproject.io/docs/ins...ng-from-source
Basically, setup your environment variables TMPDIR (I used ~/tmp...more on that in a bit), CXX="/usr/local/bin/eg++", GOPATH (I used ~/go), and GOGC (I used 25 as a hackish workaround for out of memory issues during the build to force the go garbage collector to be a bit more aggressive...I also needed to add a 4G swap on the nvme ssd for the ui build...more on that in a few), make your install dir, clone the code, and "gmake bootstrap && gmake bin". Then wait a good bit, because Vault will download something like 2+ GB of code to build, and build it with *zero* errors. No joke.
Except, it's not *quite* that straightforward. As of 7/19/2021, the build doesn't seem to be fully ironed out, even though an issue on their github seems to suggest it would be done sometime in 2018 (https://github.com/hashicorp/vault/i...ment-379257350). They overshot that target, I guess.
So when that fails, make sure you "gmake static-dist bin" (preferably after the gmake bootstrap, of course). This will fail in $TMPDIR/yarn-GIBBERISH/ because node is missing, so I set TMPDIR to something on my vault ssd and copied node into the TMPDIR (yarn seems to want it there, oddly). yarn will take a while, especially considering this is supposed to be the "static" portion of the web ui (which, ironically, needs g++...perhaps it's not "static" as in webui, but static as in "not dynamically linked"? But then why Javascript?! I digress). yarn will also complain verbosely that certain packages aren't available, but the Makefile is doing --ignore-optional, so other than a bunch of warnings it doesn't have any impact.
Aaaand just keep waiting for yarn.
And waiting...
Still waiting...
In the interim, I set up an automation in HomeAssistant to dump US earthquake data to discord so I could see in near-realtime how often earthquakes are occurring today. Alaska, California, and Hawaii are quite active! Granted, the vast majority of these earthquakes are small, less than 2.0 on the Richter scale, but...it's an earthquake. Who knew?
Done in 1863.29s.
\o/ yarn is done, but there is still ember and the rest of the targets to go. Continuing on!
Oh, one more thing...it's probably not a bad idea to turn the fan on. OpenBSD-CURRENT on the rockpro64 (as of right now) doesn't have automatic fan control (that I'm aware of), so I jumpered the SoC fan to pins 2 and 4 to get some airflow going).
BEFORE TURNING FAN ON
vault# sysctl hw.sensors
hw.sensors.rktemp0.temp0=60.62 degC (CPU)
hw.sensors.rktemp0.temp1=58.89 degC (GPU)
AFTER TURNING FAN ON
vault# sysctl hw.sensors
hw.sensors.rktemp0.temp0=40.55 degC (CPU)
hw.sensors.rktemp0.temp1=39.38 degC (GPU)
There's a joke in there about building "ember" on your CPU while the fan is off, but it escapes me currently.
After running the machine into the ground (out of memory/swap...normally it wouldn't be possible for a user to run all of the memory out on OpenBSD, but I put the vault user in a custom login class heh), I decided to give it another shot. That also ended up bombing out, so I've hit a cross-roads, and after adding the previously mentioned 4G swap on the nvme ssd, relaunching the build, and getting distracted on other stuff, I came back to static-dist success!
Now, after all that, I can gmake bin, and have vault. At least, in theory.
Bracing myself for another epic disaster of idiotic proportions...but it never came. With all the shenanigans out of the way, I can finally configure vault.
I'll save that for next time. =)
Total Comments 0
