From 716b4c5af5b211d124d7f0bad9fcfbf024ffa458 Mon Sep 17 00:00:00 2001 From: "Dustin C. Hatch" Date: Mon, 8 Mar 2021 22:29:18 -0600 Subject: [PATCH] blog: Import posts from Hugo blog --- content/blog/ansible-sudo-bw.md | 13 +++++++ content/blog/fedora-update-roroot.md | 12 +++++++ content/blog/grafana-sensor-data.md | 17 +++++++++ content/blog/improving-influxdb-queries.md | 15 ++++++++ content/blog/new-tool-mizule.md | 40 ++++++++++++++++++++++ content/blog/xrdp-experiment.md | 25 ++++++++++++++ 6 files changed, 122 insertions(+) create mode 100644 content/blog/ansible-sudo-bw.md create mode 100644 content/blog/fedora-update-roroot.md create mode 100644 content/blog/grafana-sensor-data.md create mode 100644 content/blog/improving-influxdb-queries.md create mode 100644 content/blog/new-tool-mizule.md create mode 100644 content/blog/xrdp-experiment.md diff --git a/content/blog/ansible-sudo-bw.md b/content/blog/ansible-sudo-bw.md new file mode 100644 index 0000000..02f5c67 --- /dev/null +++ b/content/blog/ansible-sudo-bw.md @@ -0,0 +1,13 @@ ++++ +title = 'Ansible, sudo, Bitwarden' +date = 2019-08-20T06:54:00-06:00 ++++ + +The latest version of `sshpass` supports a `--prompt`/`-P` argument, which +controls the string the tool expects, after which it will send the specified +password. Using this, it is possible to send a password from Bitwarden to +Ansible, like so: + +```sh +sshpass -f <(bwpass …) -P 'SUDO password:' ansible-playbook -bK … +``` \ No newline at end of file diff --git a/content/blog/fedora-update-roroot.md b/content/blog/fedora-update-roroot.md new file mode 100644 index 0000000..c22c46a --- /dev/null +++ b/content/blog/fedora-update-roroot.md @@ -0,0 +1,12 @@ ++++ +title = 'Updating Fedora with Read-Only Root Filesystem' +date = 2019-11-12T15:52:00-06:00 ++++ + +When using `dnf system-update` on a Fedora machine that has a read-only root +filesystem, it is important to make sure that the filesystem will be mounted +read-write automatically first. Edit `/etc/fstab` and change it to `rw` +before rebooting, lest the update will fail. + +I imagine the offline update process really should remount the root filesystem +on its own, but that does not appear the case, at least for now. diff --git a/content/blog/grafana-sensor-data.md b/content/blog/grafana-sensor-data.md new file mode 100644 index 0000000..d6d00fe --- /dev/null +++ b/content/blog/grafana-sensor-data.md @@ -0,0 +1,17 @@ ++++ +title = 'Graphing Sensor Data with Grafana' +date = 2018-08-06T21:32:00-06:00 ++++ + +To view trending sensor data, I installed collectd (with the "sensors" plugin +enabled), InfluxDB, and Grafana. For some series, Grafana displayed wierd +graphs with what looked like two values for one interval. I worked around this +by changing the Influx query from + + SELECT "value" FROM "sensors_value" WHERE ("type" = 'temperature') AND $timeFilter GROUP BY "type_instance" + +to + + SELECT median("value") FROM "sensors_value" WHERE ("type" = 'temperature') AND $timeFilter GROUP BY time(10s), "type_instance" + +This seemed to smooth out the line quite a bit. diff --git a/content/blog/improving-influxdb-queries.md b/content/blog/improving-influxdb-queries.md new file mode 100644 index 0000000..221059f --- /dev/null +++ b/content/blog/improving-influxdb-queries.md @@ -0,0 +1,15 @@ ++++ +title = 'Improving InfluxDB Sensor Data Queries' +date = 2018-08-07T18:28:00-06:00 ++++ + +I now understand why Grafana built the initial query with `GROUP BY +time($__interval)`. With a hard-coded value in `time()`, every single point is +displayed on the graph, regardless of the zoom level. The `$__interval` +variable scales this value based on the time period displayed. + +Initially, this did not work for me, and Grafana just drew seemingly random +points when using any view besides "last 6 hours." This turned out to be +because the default value for "min time interval" was not set (or was +incorrect). Seting it to "10s" (which is the collectd poll interval) corrected +this issue as well. diff --git a/content/blog/new-tool-mizule.md b/content/blog/new-tool-mizule.md new file mode 100644 index 0000000..c307dbb --- /dev/null +++ b/content/blog/new-tool-mizule.md @@ -0,0 +1,40 @@ ++++ +title = 'New Tool: Mizule' +date = 2020-01-17T23:01:00-05:00 ++++ + +I want to do better about switching out the BURP backup disks, so I need +something to remind me. A calendar event might work, but if I forget to do it +on the day it's scheduled, I won't get another reminder until the next +scheduled date. + +I decided to write a simple program that checks the UUID of the filesystem +mounted at /var/spool/burp and generates a notification if it has not changed +for some time. This way, if I forget to do it on the scheduled date, it will +keep reminding me until I do. + +I wrote the tool in Rust, because it is very simple and I have been looking +for a project to help me get motivated to learn Rust more. It took about 12 +hours start-to-finish. + +Aside from my lack of familiarity with Rust, probably the most difficult part +of the project was getting it to reliably send email notifications! At some +point, I realized that `nullmailer` wasn't running on my desktop, and hadn't +been for *quite* some time! When I started it up, it had so many messages +queued up (from cron, etc.), that Protonmail put a rate limit on my email +account! This made it difficult to test Mizule's email capability, since I +couldn't actually see the messages it was sending, only that it had sent +something according to the Postfix logs. + +I am going to look into some other options for sending push notifications. So +far, I have found [Firebase Cloud Messaging][0], Google's "offical" push +notification solution, which naturally requires a Google account, Google +Services Framework, et. al. I also found [Gotify][1], which just uses a +WebSocket. There is also [notify.run][2], which uses the Web Push API (browser +based), and [signald][3], which sends messages to Signal. XMPP may be an option +as well. + +[0]: https://firebase.google.com/docs/cloud-messaging/ +[1]: https://gotify.net/ +[2]: https://notify.run/ +[3]: https://gitlab.com/thefinn93/signald diff --git a/content/blog/xrdp-experiment.md b/content/blog/xrdp-experiment.md new file mode 100644 index 0000000..d7f6aad --- /dev/null +++ b/content/blog/xrdp-experiment.md @@ -0,0 +1,25 @@ ++++ +title = 'Experimenting with xrdp' +date = 2019-08-08T10:38:00-06:00 ++++ + +I needed to use the iDRAC on the prototype appliances to install FMOS. I tried +several ways of using the Remote File Share feature to map the virtual media +(HTTP, NFS, CIFS), but could not get any of them to work: most options +appeared to do nothing, giving an error message about invalid path or +credentials, without even attempting to connect to the specified server. I +knew that the client-side virtual media would not work over the VPN, so I +decided to try setting up a GUI on a machine in the office to run Firefox and +the iDRAC virtual console applet, and then connect to it remotely. + +On Fedora, setting up xrdp was pretty simple. I just installed the *xrdp* +package, which pulled in the *xorgxrdp* and *xorg-x11-server-Xorg*. Besides +adding the port to the firewall, the change I had to make was to create +`/etc/X11/Xwraper.config` and set `allowed_users=anybody`, to allow non-local +users to create X sessions. Then, just starting the *xrdp* service was all +that was necessary. I did have to work around a bug by passing `+glyph-cache` +(or ticking the corresponding checkbox to `xfreerdp` to get the client to +connect, but otherwise, the process was pretty smooth. I then instaled +*firefox*, *i3*, and *icedtea-web*. The only part that was somewhat confusing +is that `~/.xinitrc` did not work; the launch script had to be named +`~/startwm.sh`.