• Search for:
    5 Apr, 2020
    Making File URLs Work Again in Firefox
    Cloud

    At some point in the last year or so—I don’t know exactly when it happened—Firefox, along with most of the other major browsers, stopped working with file:// URLs. This is a shame, because I like using Markdown for presentations (at least, when it’s a presentation where I don’t need to collaborate with others). However, using this sort of approach generally requires support for file:// URLs (or requires running a local web server). In this post, I’ll show you how to make file:// URLs work again in Firefox.

    I tested this procedure using Firefox 74 on Ubuntu, but it should work on any platform on which Firefox is supported. Note that the locations of the user.js file will vary from OS to OS; see this MozillaZine Knowledge Base entry for more details.

    Here’s the process I followed:

    1. Create the user.js file (it doesn’t exist by default) in the correct location for your Firefox profile. (Refer to the MozillaZine KB article linked above for exactly where that is on your OS.)

    2. In the user.js, add these entries:

      // Allow file:// links
user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "file://");
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");

    3. In your Firefox configuration (accessible using about:config in a Firefox tab), change the value of privacy.file_unique_origin from true to false.

    4. Restart Firefox.

    After you restart Firefox, you should be able to use file:// URLs, but only from local HTML files on your system (as specified by the second line you added in step 2). It’s possible this may expose an unknown security flaw or weakness that I haven’t foreseen, so keep that in mind.

    If you’re a fan of Markdown-based presentations displayed using your browser, they should work again.

    Hit me on Twitter if you have questions. Thanks!

    …

    Read MoreMaking File URLs Work Again in Firefox

    4 Apr, 2020
    Installing MultiMarkdown 6 on Ubuntu 19.10
    Cloud

    Markdown is a core part of many of my workflows. For quite a while, I’ve used Fletcher Penny’s MultiMarkdown processor (available on GitHub) on my various systems. Fletcher offers binary builds for Windows and macOS, but not a Linux binary. Three years ago, I wrote a post on how to compile MultiMarkdown 6 for a Fedora-based system. In this post, I’ll share how to compile it on an Ubuntu-based system.

    Just as in the Fedora post, I used Vagrant with the Libvirt provider to spin up a temporary build VM.

    In this clean build VM, I perform the following steps to build a multimarkdown binary:

    1. Install the necessary packages with this command:

      sudo apt install gcc make cmake git build-essential

    2. Clone the source code repository:

      git clone https://github.com/fletcher/MultiMarkdown-6

    3. Switch into the directory where the repository was cloned and run these commands to build the binary:

      make
cd build
make

    4. Once the second make command is done, you’re left with a multimarkdown binary. Copy that to the host system (scp works fine). Use vagrant destroy to clean up the temporary build VM once you’ve copied the binary to your host system.

    And with that, you’re good to go!

    …

    Read MoreInstalling MultiMarkdown 6 on Ubuntu 19.10

    2 Apr, 2020
    Setting up etcd with Kubeadm, containerd Edition
    Cloud

    In late 2018, I wrote a couple of blog posts on using kubeadm to set up an etcd cluster. The first one was this post, which used kubeadm only to generate the TLS certs but ran etcd as a systemd service. I followed up that up a couple months later with this post, which used kubeadm to run etcd as a static Pod on each system. It’s that latter post—running etcd as a static Pod on each system in the cluster—that I’ll be revisiting in this post, only this time using containerd as the container runtime instead of Docker.

    This post assumes you’ve already created the VMs/instances on which etcd will run, that an appropriate version of Linux is installed (I’ll be using Ubuntu LTS 18.04.4), and that the appropriate packages have been installed. This post also assumes that you’ve already made sure that the correct etcd ports have been opened between the VMs/instances, so that etcd can communicate properly.

    Finally, this post builds upon the official Kubernetes documentation on setting up an etcd cluster using kubeadm. The official guide assumes the use of Docker, whereas this post will focus on using containerd as the container runtime instead of Docker. The sections below outline the changes required to the official documentation in order to make it work with containerd.

    Configuring Kubelet

    The official documentation provides a systemd drop-in to configure the Kubelet to operate in a “stand-alone” mode. Unfortunately, this drop-in won’t work with containerd. Here is a replacement drop-in for containerd:

    [Service]
ExecStart=
ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd --container-runtime=remote --runtime-request-timeout=15m --container-runtime-endpoint=unix:///run/containerd/containerd.sock
Restart=always

    The changes here are the addition of the --container-runtime, --runtime-remote, and --container-runtime-endpoint parameters. These parameters configure the Kubelet to talk to containerd instead of Docker.

    As instructed in the official documentation, put this into a systemd drop-in (like the suggested 20-etcd-service-manager.conf) and copy it into the /etc/systemd/system/kubelet.service.d directory. Once the file is in place, run systemctl daemon-reload so that systemd will pick up the changes.

    Create the Manifests Directory

    Although this is not included in the official documentation, I saw problems with the Kubelet starting up if the manifests directory doesn’t exist. I suggest manually creating the /etc/kubernetes/manifests directory to avoid any such issues.

    Bootstrap the etcd Cluster

    Aside from the changes/differences described above, the rest of the process is as outlined in the official documentation. At a high-level, that means:

    1. Use kubeadm init phase certs etcd-ca to generate the etcd CA certificate and key.
    2. Use kubeadm init phase certs to generate the etcd server, peer, health check, and API server client certificates.
    3. Distribute the certificates to the etcd nodes.
    4. Use kubeadm init phase etcd local to generate the Pod manifests for the etcd static Pods.

    One final note: the docker command at the end of the official documentation won’t work in this case, since containerd is the container runtime instead of Docker. I’m still working on the correct containerd equivalent command to test the health of the cluster.

    How I Tested

    I used Pulumi to create a test environment in AWS for testing the instructions in this article. The TypeScript code that I wrote for use with Pulumi creates an environment suitable for use with Kubernetes Cluster API, including a VPC, both public and private subnets, an Internet gateway, NAT gateways for the private subnets, all associated route tables and route table associations, and the necessary security groups. I hope to publish this code for others to use soon; look for an update here.

    If you have any questions, concerns, or corrections, please contact me. You can reach me on Twitter, or contact me on the Kubernetes Slack instance. I’d love to hear from you, and all constructive feedback is welcome.

    …

    Read MoreSetting up etcd with Kubeadm, containerd Edition