Scott's Weblog The weblog of an IT pro focusing on cloud computing, Kubernetes, Linux, containers, and networking

Technology Short Take 156

Welcome to Technology Short Take #156! It’s been about a month since the last Technology Short Take, and in that time I’ve been gathering links that I wanted to share with my readers. (I still have quite the backlog of links to read!) Hopefully something I share here will prove useful to someone. Enjoy the links below, and enjoy your weekend!

Networking

  • I’d never heard of Pipy before seeing it in this article, but it look like it could be quite useful for a number of use cases.
  • William Morgan, one of the creators of Linkerd, has a lengthy treatise on eBPF, sidecars, and the future of the service mesh. As a (relative) layperson—meaning I’m not an eBPF expert—I don’t know if I should believe the eBPF cheerleaders (some of whom I know personally and are familiar with their technical expertise) or folks like William who have clearly “been there, done that” with service mesh. I certainly think there’s a place for eBPF in service meshes, but I’m not yet on board with sidecar-less service meshes (or per-node proxy models).

Security

Cloud Computing/Cloud Management

Operating Systems/Applications

Programming

Storage

Virtualization

  • Here’s Chris Evans’ take on the Broadcom acquisition of VMware.
  • Colin shares a critical learning item on using Terraform with VMware ESXi.
  • Apple’s Worldwide Developer Conference (WWDC) recently happened, and some virtualization-related information emerged on how Apple is allowing ARM-based Linux VMs (virtualized using the hypervisor present in macOS) to leverage Rosetta 2 to run Intel binaries. Ars Technica has more information here. (Personally, I think this is pretty cool, even if the setup process to make it work is like jumping through hoops.)

Career/Soft Skills

  • I liked this brief article on the true nature of remote work (hint: it’s about working asynchronously.)
  • Julien Simon’s treatise on technical evangelism from the trenches was also a good read, with a number of tips that I’ll be attempting to assimilate into my thinking and work.

That’s all for now! I love hearing from readers, so if you feel like getting in touch with me there are a variety of ways to do that. I’m on Twitter, in a variety of Slack channels, and you can even e-mail me (my e-mail address isn’t too hard to find, just poke around on this site for a bit). Thanks for reading!

Making Flatpak Firefox use Private Browsing by Default

In April 2021 I wrote a post on making Firefox use Private Browsing by default, in which I showed how to modify the GNOME desktop file so that Firefox would open private windows by default without restricting access to normal browsing windows and functionality. I’ve used that technique on all my Fedora-based systems since that time, until just recently. What happened recently, you ask? I switched to the Flatpak version of Firefox. Fortunately, with some minor tweaks, this technique works with the Flatpak version of Firefox as well. In this post, I’ll share with you the changes needed to make the Flatpak version of Firefox also use private browsing by default.

When working with the non-Flatpak version of Firefox, the GNOME desktop file installed with the Firefox package is found at /usr/share/applications. In my earlier article, I suggested editing that file to add the --private-window parameter to the Exec line. Unfortunately, that change gets overwritten every time the Firefox package is updated. It’s better, actually, to use a locally customized desktop file placed in ~/.local/share/applications instead, which will take precedence over the shared desktop file.

With the Flatpak version of Firefox, there is still a shared GNOME desktop file, and support for a locally-customized version as well. The shared desktop file, installed with the Flatpak, is found here on my Fedora system:

/var/lib/flatpak/app/org.mozilla.firefox/current/active/export/share/applications

(It’s worth noting that the current and active portions of the directory path are symlinks.)

You can edit the org.mozilla.firefox.desktop file at this location to add the --private-window parameter to the first Exec line, like this (it’s all on a single line; I’ve wrapped it here for you):

Exec = /usr/bin/flatpak run --branch=stable --arch=x86_64 \
--command=firefox --file-forwarding org.mozilla.firefox \
--private-window @@u %u @@

However, when the Flatpak gets updated, then this change will get overwritten. Instead, it would be better to copy org.mozilla.firefox.desktop from the path above to the corresponding local path:

~/.local/share/flatpak/exports/share/applications

Then edit this local desktop file to include the --private-window parameter on the first Exec line. Making the change to the local copy ensures that the change will not get overwritten or replaced when the Flatpak gets updated.

After you save this change, you’ll find that launching the Firefox Flatpak version will open a private browsing window by default. You can still open a regular window as needed, but any links that you click in other applications will automatically open in a private window (or a tab in an existing private window).

There does appear to be one drawback to this approach, and I haven’t found a workaround/solution yet. When you edit the local desktop file, you can still launch Firefox as normal, but Firefox disappears as a valid option for the default web browser in the Default Applications screen of the GNOME Settings app. I don’t know why this happens.

I hope this information is useful. Feel free to contact me—on Twitter, in any one of a variety of Slack communities, or elsewhere online—if you have any questions, comments, or suggestions for improvement.

Git Difftool and Meld as a Flatpak

I’ve recently started migrating many of the applications on my Fedora 36 laptop to their Flatpak versions. For the most part, this has been pretty straightforward, although there isn’t really any method for migrating configuration and data. Today I ran into a problem with Meld, a graphical diff utility, and using it with the git difftool command. Below I’ll share how I worked around this problem.

Normally, the integration between Git and Meld—which is what enables you to run git difftool and have the results show up in Meld—would look something like this (this is from ~/.gitconfig):

[merge]
    tool = meld
[diff]
    tool = meld
[difftool]
    prompt = no
[difftool "meld"]
    cmd = /usr/bin/meld "$LOCAL" "$REMOTE"
[mergetool "meld"]
    cmd = /usr/bin/meld "$LOCAL" "$REMOTE"

However, when Meld is installed as a Flatpak, /usr/bin/meld doesn’t exist. In order to continue using Meld with the git difftool command, you must change the Git configuration to look like this instead:

[merge]
    tool = meld
[diff]
    tool = meld
[difftool]
    prompt = no
[difftool "meld"]
    cmd = flatpak run org.gnome.Meld "$LOCAL" "$REMOTE"
[mergetool "meld"]
    cmd = flatpak run org.gnome.Meld "$LOCAL" "$REMOTE"

In addition to the change above, I found it necessary to use Flatseal to modify the permissions of the Meld Flatpak to include the /tmp directory. (You can optionally make that read-only as well.)

After you make these changes, using Meld with git difftool should work as expected again.

This is a pretty straightforward change, but hopefully documenting it here will prove helpful to someone. If you have any questions, feel free to contact me on Twitter. Thanks!

Technology Short Take 155

Welcome to Technology Short Take #155, just in time for the 2022 Memorial Day holiday weekend! (Here in the US, at least.) I mean, don’t you want to spend this weekend catching up on some technology-related articles instead of cooking on the grill and gathering with friends and family? I certainly hope not! Still, for those who need a little technology fix over the weekend, hopefully I’ve included something useful in the list of articles below. Enjoy!

Networking

  • Isovalent—the company behind the Cilium project—has been talking a lot about how the use of eBPF will transform things, including the architecture of a service mesh. Along those lines, one of their latest articles discusses how to achieve identity-based mutual authentication leveraging eBPF. If I’m understanding the article correctly (and feel free to correct me if I am mistaken) it looks as if Cilium Service Mesh will leverage/does leverage a combination of certificate-based mTLS for identity at the workload level and node-based transport encryption (via WireGuard) for data confidentiality. Even though I know that the underlying mechanisms are different, subjectively this feels a lot like using tunnels to connect workloads on different compute nodes (i.e., network virtualization). Is the relationship between network virtualization and service mesh closer than some folks might wish to admit?

Servers/Hardware

  • Researchers have uncovered a potential security flaw in Apple Silicon CPUs; more details in this 9to5Mac article. I’m not sure how I feel about security researchers calling this flaw “not that bad.”
  • Colin Percival shares some benchmarks using FreeBSD on the Graviton 3.

Security

Cloud Computing/Cloud Management

Operating Systems/Applications

Programming

Storage

Virtualization

  • The state of virtualization on Apple Silicon hardware has seen a few developments in recent days and weeks. One project that caught my attention was Tart, a CLI-driven tool that leverages the virtualization support present in macOS to run virtual macOS instances. This will become even more useful, in my opinion, when Linux support is added. (The possibility of a Vagrant provider just seals the deal, in my opinion.)
  • The world of virtualization—nay, more than just virtualization—will be forever changed with the announcement of Broadcom’s acquisition of VMware.

Career/Soft Skills

  • Mike McQuaid shares some details on how he gets things done.
  • Ashley Janssen discusses how time-blocking may help improve productivity. This is not a technique I’ve generally used, so I’d be curious to hear from readers who may have used or are currently using techniques like this.
  • Here’s some advice on “starting your diagramming career” (let’s be real, many IT folk need to create diagrams on a regular basis, so tips on creating diagrams might prove really useful).

Other

  • I’ve seen a lot of work-from-home desk setups, but this one stood out as actually having some budget-conscious selections (which is often not the case). The use of 3M Command strips to affix stuff under the desk is also so blindingly obvious that I’m surprised I hadn’t thought of it already.

It’s time to wrap up. I hope you all have a wonderful weekend! Feel free to reach out to me if you have questions, comments, suggestions for improvement, or if you just want to say hi. The easiest way to contact me is via Twitter. Thanks for reading!

Fine-Tuning Control Plane Access with Cluster API

When Cluster API creates a workload cluster, it also creates a load balancing solution to handle traffic to the workload cluster’s control plane. This is necessary so that the control plane endpoint is decoupled from the underlying control plane nodes (which facilitates scaling the control plane, among other things). On AWS, this mean creating an ELB and a set of security groups. For flexibility, Cluster API provides a limited ability to customize this control plane load balancer. In this post, I’ll show you how to use this functionality to fine-tune access to a workload cluster’s control plane when using Cluster API with AWS.

If you’re not familiar with Cluster API (hereafter just referred to as “CAPI”), then my introduction to CAPI article may be useful. Keep in mind that article was written in 2019, while the project was still in its early stages. The high-level concepts are correct, but some of the details may have shifted slightly over the last three years as the project progressed from v1alpha1 APIs to the now-current v1beta1 APIs.

The key here is the controlPlaneLoadBalancer object, which is part of the AWSCluster object (see details here in the code or here via pkg.go.dev). With regard to access to a workload cluster’s control plane via its control plane load balancer, two fields are of particular interest:

  1. The additionalSecurityGroups field allows you to list any additional security groups—referenced by security group ID—that the control plane load balancer should use (this is in addition to the standard set of security groups created by CAPI). This is an optional field.
  2. The scheme field allows you to specify whether the load balancer should be externally-accessible from the Internet (specified with the value “internet-facing”, which is the default value) or not (specified with the value “internal”). If you specify “internal” as the scheme, then the load balancer won’t get a public IP address and won’t be reachable via the Internet. This would be a great way to restrict access to only those connections coming via a VPN (or similar) into the VPC.

Personally, I would at least switch the scheme on the control plane load balancer; otherwise, the API server of your newly-created workload cluster is publicly accessible via the Internet. You can then leverage any additional security groups as needed.

One note to keep in mind: the default security group created by the AWS provider for CAPI (referred to as CAPA) allows access from 0.0.0.0/0 to the control plane load balancer. If you need to restrict access to something more fine-grained than that, using the additionalSecurityGroups field is not the way. As outlined here, you’ll instead want to use the securityGroupOverrides field (which is found at spec.network.securityGroupOverrides).

I hope this information is useful. Feel free to reach out to me if you have any questions (or corrections, in the event I explained/presented something incorrectly). You can find me on the Kubernetes Slack (as well as a number of other Slack communities) as well as on Twitter.

Recent Posts

Technology Short Take 154

Welcome to Technology Short Take #154! My link of links and articles from around the Internet is a bit light on networking and virtualization this time around, but heftier in the security, cloud, and OS/application sections. I hope that I’ve managed to include something that you’ll find useful. Enjoy the content!

Read more...

Technology Short Take 153

Welcome to Technology Short Take #153! My personal and professional life has kept me busy over the last couple of months, so things have been quiet here on the blog. I’ve still been collecting links to share with you, though, and here’s the latest collection. I hope you’re able to find something useful here!

Read more...

Technology Short Take 152

Welcome to Technology Short Take #152! Normally I’d publish a Technology Short Take in the morning on a Friday, but I really wanted to get this one out so I’m making it live late in the day on a Monday. Here’s hoping I’ve included some content below that you find useful!

Read more...

Using cert-manager with Kuma for mTLS

When configuring mutual TLS (mTLS) on the open source Kuma service mesh, users have a couple of different options. They can use a “builtin” certificate authority (CA), in which Kuma itself will generate a CA certificate and key for use in creating service-specific mTLS certificates. Users also have the option of using a “provided” CA, in which they must supply a CA certificate and key for Kuma to use when creating service-specific mTLS certificates. Both of these options are described on this page in the Kuma documentation. In this post, I’d like to explore the use of cert-manager as a “provided” CA for mTLS on Kuma.

Read more...

Follow Up: Bootstrapping Servers into Ansible

Seven years ago, I wrote a quick post on bootstrapping servers into Ansible. The basic gist of the post was that you can use variables on the Ansible command-line to specify hosts that aren’t part of your inventory or log in via a different user (useful if the host doesn’t yet have a dedicated Ansible user account because you want to use Ansible to create that account). Recently, though, I encountered a situation where this approach doesn’t work, and in this post I’ll describe the workaround.

Read more...

Technology Short Take 151

Welcome to Technology Short Take #151, the first Technology Short Take of 2022. I hope everyone had a great holiday season and that 2022 is off to a wonderful start! I have a few more links than normal this time around, although I didn’t find articles in a couple categories. Don’t worry—I’ll keep my eyes peeled and my RSS reader ready to pull in new articles in those categories for next time. And now for the content!

Read more...

Getting Certificate Details from HashiCorp Vault

It seems there are lots of tutorials on setting up a PKI (public key infrastructure) using HashiCorp Vault. What I’ve found missing from most of these tutorials, however, is how to get details on certificates issued by a Vault-driven PKI after the initial creation. For example, someone other than you issued a certificate, but now you need to get the details for said certificate. How is that done? In this post, I’ll show you a couple ways to get details on certificates issued and stored in HashiCorp Vault.

Read more...

Using Test-Driven Development for Kustomize Overlays

I am by no means a developer (not by a long shot!), but I have been learning lots of development-related things over the last several years and trying to incorporate those into my workflows. One of these is the idea of test-driven development (see Wikipedia for a definition and some additional information), in which one writes tests to validate functionality before writing the code to implement said functionality (pardon the paraphrasing). In this post, I’ll discuss how to use conftest to (loosely) implement test-driven development for Kustomize overlays.

Read more...

Technology Short Take 150

Welcome to Technology Short Take #150! This is the last Technology Short Take of 2021, so hopefully I’ll close the year out “with a bang” with this collection of links and articles on various technology areas. Bring on the content!

Read more...

Review: OWC Thunderbolt 3 Dock

About six months ago I purchased an OWC Thunderbolt 3 Dock to replace my Anker PowerElite Thunderbolt 3 Dock (see my review here). While there was nothing necessarily wrong with the Anker PowerElite, it lacked a digital audio port that I could use to send audio to a soundbar positioned under my monitor. (I’d grown accustomed to using a soundbar when my 2012 Mac Pro was my primary workstation.) In this post, I’ll provide a brief review of the OWC Thunderbolt 3 Dock.

Read more...

Technology Short Take 149

Welcome to Technology Short Take #149! I’ll have one more Technology Short Take in 2021, scheduled for three weeks from now (on the last day of the year!). For now, though, I have a small collection of articles and links for your reading pleasure—not as many as I usually include in a Technology Short Take, but better than nothing at all (I hope!). Enjoy!

Read more...

Technology Short Take 148

Welcome to Technology Short Take #148, aka the Thanksgiving Edition (at least, for US readers). I’ve been scouring RSS feeds and various social media sites, collecting as many useful links and articles as I can find: from networking hardware and networking CI/CD pipelines to Kernel TLS and tricks for improving your working memory. That’s quite the range! I hope that you find something useful here.

Read more...

Using Kustomize Components with Cluster API

I’ve been using Kustomize with Cluster API (CAPI) to manage my AWS-based Kubernetes clusters for quite a while (along with Pulumi for managing the underlying AWS infrastructure). For all the time I’ve been using this approach, I’ve also been unhappy with the overlay-based approach that had evolved as a way of managing multiple workload clusters. With the recent release of CAPI 1.0 and the v1beta1 API, I took this opportunity to see if there was a better way. I found a different way—time will tell if it is a better way. In this post, I’ll share how I’m using Kustomize components to help streamline managing multiple CAPI workload clusters.

Read more...

Technology Short Take 147

Welcome to Technology Short Take #147! The list of articles is a bit shorter than usual this time around, but I’ve still got a good collection of articles and posts covering topics in networking, hardware (mostly focused on Apple’s processors), cloud computing, and virtualization. There’s bound to be something in here for most everyone! (At least, I hope so.) Enjoy your weekend reading!

Read more...

Influencing Cluster API AMI Selection

The Kubernetes Cluster API (CAPI) project—which recently released v1.0—can, if you wish, help manage the underlying infrastructure associated with a cluster. (You’re also fully able to have CAPI use existing infrastructure as well.) Speaking specifically of AWS, this means that the Cluster API Provider for AWS is able to manage VPCs, subnets, routes and route tables, gateways, and—of course—EC2 instances. These EC2 instances are booted from a set of AMIs (Amazon Machine Images, definitely pronounced “ay-em-eye” with three syllables) that are prepared and maintained by the CAPI project. In this short and simple post, I’ll show you how to influence the AMI selection process that CAPI’s AWS provider uses.

Read more...

Older Posts

Find more posts by browsing the post categories, content tags, or site archives pages. Thanks for visiting!