Refactored syntax highlighting shortcodes into markdown

content/blog/OpenBSD/relayd-httpd-example.md

@@ -14,7 +14,7 @@ The goal was to have a relayd configuration that would serve urls like `https://
 
 ## The httpd configuration
 
-{{< highlight txt >}}
+```nginx
 prefork 5
 
 server "example.com" {
@@ -35,11 +35,11 @@ server "example.com" {
             root "/htdocs/www/public/"
     }
 }
-{{< /highlight >}}
+```
 
 ## The relayd configuration
 
-{{< highlight txt >}}
+```cfg
 log state changes
 log connection errors
 prefork 5
@@ -93,4 +93,4 @@ relay "wwwsecure6" {
     forward to <httpd> port 8080
     forward to <synapse> port 8008
 }
-{{< /highlight >}}
+```

content/blog/OpenBSD/softraid_monitoring.md

@@ -13,32 +13,32 @@ I have reinstalled my nas recently from gentoo to OpenBSD and was amazed once ag
 ## Softraid monitoring
 
 I had a hard time figuring out how to properly monitor the state of the array without relying on parsing the output of `bioctl` but at last here it is in all its elegance :
-{{< highlight sh >}}
+```sh
 root@nas:~# sysctl hw.sensors.softraid0
 hw.sensors.softraid0.drive0=online (sd4), OK
-{{< /highlight >}}
+```
 
 I manually failed one drive (with `bioctl -O /dev/sd2a sd4`) then rebuilt it (with `bioctl -R /dev/sd2a sd4)`... then failed two drives in order to have examples of all possible outputs. Here they are if you are interested :
-{{< highlight sh >}}
+```sh
 root@nas:~# sysctl hw.sensors.softraid0
 hw.sensors.softraid0.drive0=degraded (sd4), WARNING
-{{< /highlight >}}
+```
 
-{{< highlight sh >}}
+```sh
 root@nas:~# sysctl hw.sensors.softraid0
 hw.sensors.softraid0.drive0=rebuilding (sd4), WARNING
-{{< /highlight >}}
+```
 
-{{< highlight sh >}}
+```sh
 root@nas:~# sysctl -a |grep -i softraid
 hw.sensors.softraid0.drive0=failed (sd4), CRITICAL
-{{< /highlight >}}
+```
 
 ## Nagios check
 
 I am still using nagios on my personal infrastructure, here is the check I wrote if you are interested :
 
-{{< highlight perl >}}
+```perl
 #!/usr/bin/env perl
 ###############################################################################
 #     \_o<     WARNING : This file is being managed by ansible!      >o_/     #
@@ -71,4 +71,4 @@ if (`uname` eq "OpenBSD\n") {
 
 print $output{status};
 exit $output{code};
-{{< /highlight >}}
+```

content/blog/OpenBSD/wireguard-firewall.md

@@ -13,7 +13,7 @@ tage:
 Now that we covered wireguard configurations and routing, let's consider your firewall configuration in several scenarios. This first article will focus on OpenBSD.
 
 ## Template for this article
-```
+```cfg
 table <myself>   const { self }
 table <private>  const { 10/8, 172.16/12, 192.168/16, fd00::/8 fe80::/10 }
 table <internet> const { 0.0.0.0/0, !10/8, !172.16/12, !192.168/16, ::/0, fe80::/10, !fd00::/8 }
@@ -48,7 +48,7 @@ With our template, you can already use your wireguard vpn as a client without an
 ## Reachable client
 
 To make your client reachable over wireguard, add the following:
-```
+```cfg
 pass in on wg0 from <private> to <myself>
 ```
 
@@ -59,7 +59,7 @@ In this example I use the `<private>` pf table that I find both very convenient
 ## Server
 
 A server's configuration just need to accept wireguard connections in addition of the previous rule:
-```
+```cfg
 pass in on egress proto udp from <internet> to <myself> port 342
 pass in on wg0 from <private> to <myself>
 ```
@@ -67,7 +67,7 @@ pass in on wg0 from <private> to <myself>
 ## Hub
 
 As seen in the previous routing article, a hub is a server that can route traffic to another one over wireguard:
-```
+```cfg
 pass in on egress proto udp from <internet> to <myself> port 342
 pass in on wg0 from <private> to <private>
 ```