generate images

Amolith created

Change summary

archetypes/default.md                                          |   2 
content/_index.md                                              |   1 
content/posts/2020-03-21-email-privacy-security-concerns.md    |   1 
content/posts/a-perfect-email-setup-for-me.md                  |   1 
content/posts/abusing-mesh-networks-for-easy-remote-support.md | 114 +--
content/posts/audacity-and-the-telemetry-pull-request.md       |   1 
content/posts/dopamine-dispensers.md                           |   1 
content/posts/email-can-be-pleasant-but-it-takes-work.md       |   1 
content/posts/focus-intentionally.md                           |   1 
content/posts/freebsd-quirks-on-the-framework-laptop.md        |   1 
content/posts/making-yourself-overly-available.md              |   2 
content/posts/privacy-respecting-analytics.md                  |   1 
content/posts/pull-vs-push-intentional-feeds.md                |   1 
content/posts/pull-vs-push-intentional-notifications.md        |   1 
content/posts/stop-using-gmail.md                              |   1 
content/posts/the-new-paper.md                                 |   1 
content/projects.md                                            |   1 
content/uses.md                                                |   1 
justfile                                                       |  33 +
19 files changed, 100 insertions(+), 66 deletions(-)

Detailed changes

archetypes/default.md 🔗 

@@ -2,5 +2,5 @@
 title: "{{ replace .Name "-" " " | title }}"
 date: {{ .Date }}
 draft: true
+cover: ./cover.png
 ---
-

content/_index.md 🔗 

@@ -1,6 +1,7 @@
 ---
 title: Welcome!
 layout: home
+cover: ./cover.png
 ---
 
 ## Welcome!

content/posts/abusing-mesh-networks-for-easy-remote-support.md 🔗 

@@ -1,6 +1,7 @@
 ---
 title: "(Ab)using mesh networks for easy remote support"
 author: ["Amolith"]
+cover: ./cover.png
 date: 2021-11-01T02:51:00-04:00
 lastmod: 2023-01-18T09:33:39-05:00
 tags: ["Mesh networking", "Open source", "Remote support"]
@@ -27,7 +28,6 @@ networking tool created by Slack, [X11vnc,](https://libvnc.github.io/) a very mi
 distribution, to set up a scalable, secure, and simple setup reminiscent
 of products like RealVNC.
 
-
 ## Nebula {#nebula}
 
 The first part of our stack is Nebula, the tool that creates a network
@@ -63,7 +63,6 @@ It allows any node to connect with any other node on any network from
 anywhere in the world, as long as one lighthouse is accessible that
 knows the connection details for both peers.
 
-
 ### Getting started {#getting-started}
 
 The _best_ resource is [the official documentation,](https://github.com/slackhq/nebula) but I'll describe the
@@ -77,7 +76,6 @@ purchase. [Hetzner](https://www.hetzner.com/cloud) (referral: `ckGrk4J45WdN`) or
 `36nc15758387844`) would also be very good options; I've used them all and
 am very comfortable recommending them.
 
-
 ### Creating a Certificate Authority {#creating-a-certificate-authority}
 
 After picking a device with a static IP address, it needs to be set up
@@ -97,7 +95,6 @@ CA's name in a later section. If you have your own domain, feel free to
 use that instead; it doesn't really matter what domain is used as long
 as the format is valid.
 
-
 ### Generating lighthouse credentials {#generating-lighthouse-credentials}
 
 Now that we have the CA's `.crt` and `.key` files, we can create and sign
@@ -114,12 +111,11 @@ of the following private IP ranges, I just happened to use `192.168.100.X`
 for my network.
 
 | IP Range                      | Number of addresses |
-|-------------------------------|---------------------|
+| ----------------------------- | ------------------- |
 | 10.0.0.0 – 10.255.255.255     | 16 777 216          |
 | 172.16.0.0 – 172.31.255.255   | 10 48 576           |
 | 192.168.0.0 – 192.168.255.255 | 65 536              |
 
-
 ### Creating a config file {#creating-a-config-file}
 
 The next step is creating our lighthouse's config file. The reference
@@ -134,10 +130,10 @@ to identify nodes by their configs. Once we copy everything over to the
 server, we'll add the proper paths to the `cert` and `key` fields.
 
 ```yaml
-  pki:
-    ca: /etc/nebula/ca.crt
-    cert: /etc/nebula/
-    key: /etc/nebula/
+pki:
+  ca: /etc/nebula/ca.crt
+  cert: /etc/nebula/
+  key: /etc/nebula/
 ```
 
 The next section is for identifying and mapping your lighthouses. This
@@ -148,8 +144,8 @@ public IP address is. If you've used a different private network range,
 those changes need to be reflected here as well.
 
 ```yaml
-  static_host_map:
-    "192.168.100.1": ["XX.XX.XX.XX:4242"]
+static_host_map:
+  "192.168.100.1": ["XX.XX.XX.XX:4242"]
 ```
 
 Below, we're specifying how the node should behave. It is a lighthouse,
@@ -160,14 +156,14 @@ is set to `true` though), and this lighthouse should not send reports to
 other lighthouses. The bit about DNS will be discussed later.
 
 ```yaml
-  lighthouse:
-    am_lighthouse: true
-    serve_dns: true
-    dns:
-      host: 0.0.0.0
-      port: 53
-    interval: 60
-    hosts:
+lighthouse:
+  am_lighthouse: true
+  serve_dns: true
+  dns:
+    host: 0.0.0.0
+    port: 53
+  interval: 60
+  hosts:
 ```
 
 The next bit is about [hole punching](https://en.wikipedia.org/wiki/Hole_punching_%28networking%29), also called _NAT punching_, _NAT
@@ -180,10 +176,10 @@ connected to. We want to make sure devices are available no matter where
 they are.
 
 ```yaml
-  punchy:
-    punch: true
-    respond: true
-    delay: 1s
+punchy:
+  punch: true
+  respond: true
+  delay: 1s
 ```
 
 `cipher` is a big one. The value _must_ be identical on _all_ nodes _and_
@@ -194,7 +190,7 @@ that you won't need to work with _anything_ else, I recommend leaving it
 set to `chachapoly`.
 
 ```yaml
-  cipher: chachapoly
+cipher: chachapoly
 ```
 
 The last bit I modify is the firewall section. I leave most everything
@@ -207,14 +203,13 @@ make those changes.
 Again, I _remove_ the following bit from the config.
 
 ```yaml
-    - port: 443
-      proto: tcp
-      groups:
-        - laptop
-        - home
+- port: 443
+  proto: tcp
+  groups:
+    - laptop
+    - home
 ```
 
-
 ### Setting the lighthouse up {#setting-the-lighthouse-up}
 
 We've got the config, the certificates, and the keys. Now we're ready to
@@ -241,10 +236,10 @@ The next step is copying the config, keys, and certificates to the
 server. I use `rsync` but you can use whatever you're comfortable with.
 The following four files need to be uploaded to the server.
 
--   `config.yml`
--   `ca.crt`
--   `buyvm.lh.nebula.example.com.crt`
--   `buyvm.lh.nebula.example.com.key`
+- `config.yml`
+- `ca.crt`
+- `buyvm.lh.nebula.example.com.crt`
+- `buyvm.lh.nebula.example.com.key`
 
 With `rsync`, that would look something like this. Make sure `rsync` is also
 installed on the VPS before attempting to run the commands though;
@@ -268,10 +263,10 @@ Edit the config file and ensure the `pki:` section looks something like
 this, modified to match your hostnames of course.
 
 ```yaml
-  pki:
-    ca: /etc/nebula/ca.crt
-    cert: /etc/nebula/buyvm.lh.nebula.example.com.crt
-    key: /etc/nebula/buyvm.lh.nebula.example.com.key
+pki:
+  ca: /etc/nebula/ca.crt
+  cert: /etc/nebula/buyvm.lh.nebula.example.com.crt
+  key: /etc/nebula/buyvm.lh.nebula.example.com.key
 ```
 
 Run the following command to make sure everything works properly.
@@ -305,7 +300,6 @@ options.
 
 We're almost done!
 
-
 ### Setting individual nodes up {#setting-individual-nodes-up}
 
 This process is almost exactly the same as setting lighthouses up. All
@@ -337,15 +331,15 @@ is one of the lighthouses it should report to and query from. If you
 have more than one lighthouse, add them to the list as well.
 
 ```yaml
-  lighthouse:
-    am_lighthouse: false
-    #serve_dns: false
-    #dns:
-      #host: 0.0.0.0
-      #port: 53
-    interval: 60
-    hosts:
-      - "192.168.100.1"
+lighthouse:
+  am_lighthouse: false
+  #serve_dns: false
+  #dns:
+  #host: 0.0.0.0
+  #port: 53
+  interval: 60
+  hosts:
+    - "192.168.100.1"
 ```
 
 The other bit that should be modified is the `firewall:` section and this
@@ -364,21 +358,20 @@ on _your_ node allows any outbound connection, you'll be able to access
 other nodes.
 
 ```yaml
-    - port: 5900
-      proto: tcp
-      groups:
-      - support
-
-    - port: 22
-      proto: tcp
-      groups:
-      - support
+- port: 5900
+  proto: tcp
+  groups:
+    - support
+
+- port: 22
+  proto: tcp
+  groups:
+    - support
 ```
 
 The certs, key, config, binary, and systemd service should all be copied
 to the same places on all of these nodes as on the lighthouse.
 
-
 ## X11vnc {#x11vnc}
 
 _Alright._ The hardest part is finished. Now on to setting `x11vnc` up on
@@ -410,7 +403,6 @@ distribution's documentation, or ask someone else that might know.
 After adding it to the startup application, log out and back in to make
 sure it's running in the background.
 
-
 ## Remmina {#remmina}
 
 Now that our network is functioning properly and the VNC server is set
@@ -434,7 +426,6 @@ Save and test the connection!
 If all goes well and you see the other device's desktop, you're done
 with the VNC section! Now on to SSH.
 
-
 ## SSH {#ssh}
 
 First off, make sure `openssh-server` is installed on the remote node;
@@ -520,7 +511,6 @@ Now you can just run `ssh USER` to get in. If you duplicate the above
 block for all of the remote nodes you need to support, you'll only have
 to remember the person's username to SSH into their machine.
 
-
 ## Going further with Nebula {#going-further-with-nebula}
 
 This section explains why we used FQDNs in the certs and why the DNS

content/posts/dopamine-dispensers.md 🔗 

@@ -2,6 +2,7 @@
 title: "The case for dopamine dispensers"
 subtitles: "Likes and clicks and green badges and comments and analytics and ____ can be helpful, actually"
 author: ["Amolith"]
+cover: ./cover.png
 published: 2023-02-26T23:09:00-05:00
 categories: ["Technology"]
 tags: ["TODO"]

content/posts/the-new-paper.md 🔗 

@@ -1,6 +1,7 @@
 ---
 title: 'Catchy title about Supernote being "the new paper"'
 author: ["Amolith"]
+cover: ./cover.png
 lastmod: 2023-01-27T13:00:37-05:00
 tags: ["Supernote", "Writing", "Productivity", "Organisation"]
 categories: ["Technology"]

content/projects.md 🔗 

@@ -2,6 +2,7 @@
 title: "Projects"
 description: "Projects I'm currently working or have (mostly) finished"
 date: 2023-01-17T13:42:01-05:00
+cover: ./cover.png
 type: generic
 ---

content/uses.md 🔗 

@@ -2,6 +2,7 @@
 title: "Uses"
 description: "Just a big page describing what I use that I think is notable"
 date: 2021-08-18T22:57:48-04:00
+cover: ./cover.png
 type: generic
 ---

justfile 🔗 

@@ -66,9 +66,36 @@ images:
 
     echo -e '\033[1m# Checking whether there are cover images to generate ...\033[0m'
 
-    echo -e '\033[1m# \033[4mTODO\033[0m\033[1m: Generate covers for posts that have changed or that have no cover\033[0m'
-    # wkhtmltoimage -f png --width 1200 --height 630 /tmp/file.html /tmp/file.png
-    # optipng -o4 file.png
+    published=$(grep -ilr --include \*.md "draft: false" content/posts)
+
+    todo=""
+
+    # Iterate through all non-drafts
+    for path in $published
+    do
+        filename=$(basename "$path")
+        name=$(echo "${filename%.*}")
+        # Check whether target doc is newer than Markdown file
+        if [ "$path" -nt "public/$name/cover.png" ]
+        then
+            todo+="$path "
+        fi
+    done
+
+    if [ -z "$todo" ]
+    then
+        echo "No covers to generate"
+        exit 0
+    else
+        for path in $todo
+        do
+            filename=$(basename "$path")
+            name=$(echo "${filename%.*}")
+            echo "Generating cover for $name"
+
+            p2c -i $path -o public/$name/cover.png
+        done
+    fi
 
 # Run development server
 serve: