Add old posts from Journal
Some of the entries in my journal are particularly detailed and/or informative, so I thought they would make good blog posts.master
parent
f801ed5bb7
commit
4ce9fb8c84
|
|
@ -0,0 +1,11 @@
|
||||||
|
---
|
||||||
|
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:
|
||||||
|
|
||||||
|
sshpass -f <(bwpass …) -P 'SUDO password:' ansible-playbook -bK …
|
||||||
|
|
@ -0,0 +1,12 @@
|
||||||
|
---
|
||||||
|
title: Updating Fedora with Read-Only Root Filesystem
|
||||||
|
date: 2019-11-12T15:52:00-0600
|
||||||
|
---
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
@ -0,0 +1,18 @@
|
||||||
|
---
|
||||||
|
title: Graphing Sensor Data with Grafana
|
||||||
|
date: 2018-08-06T21:32:00-06:00
|
||||||
|
#draft: true
|
||||||
|
---
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
@ -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.
|
||||||
|
|
@ -0,0 +1,41 @@
|
||||||
|
---
|
||||||
|
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
|
||||||
|
|
@ -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`.
|
||||||
Loading…
Reference in New Issue