Hopefully, you're already familiar with zrok, our open-source solution for easy and secure sharing. If you're not, check out the initial post introducing zrok. There's also a more recent post describing some of the new features in the latest v0.4.0 version.

I have a website I built using Django; it's just a personal site meant to be used by friends and family. This makes it a perfect fit for zero trust as, I can hide it from the world and hand out specific access to friends and family I want to allow to use it. The site has all sorts of tools to keep track of things as a family. We have the "Tool Pool" so each friend or family member can see who has what special tools so they can borrow them instead of buying their own, and it keeps track of who borrowed what. There's another called "Packer Tracker" which keeps track of what you bring on a camping trip (personal or shared trip) so you can review what was missing or isn't needed for future trips and see what other people are bringing on a shared trip. There are many others, but, in any case, this site is just a personal site to be used on an invite-only basis, so I don't need the world to have access to it, but I do want it publicly available for those using it. So, I spun up an Oracle cloud instance (totally free "forever") and hosted it there. Currently, I create an account and send a link to anyone who wants to use it. The problem is it's still publicly accessible and prone to security issues from unwanted guests and/or web crawlers. I already have an OpenZiti zero trust network running in another Oracle cloud instance where I've secured my NAS, CCTV, and HomeAssistant access with zero trust, so why not just add this?

zrok is officially in public beta. Feel free to download the latest release of zrok and invite yourself to the public instance using the zrok invite command (there is no longer an invite token requirement):

$ zrok invite 

enter and confirm your email address...

> michael.quigley@netfoundry.io 
> michael.quigley@netfoundry.io 


[_Submit_]

invitation sent to 'michael.quigley@netfoundry.io'!

Today we celebrate the initial release of zrok v0.4.0. This new release of zrok introduces important new features and provides a stronger more extensible foundation for future growth.

I’m a big fan of commercially supported open source. I’m biased, of course, in that it’s how I get my paycheck. However, having worked on OSS without getting paid to do so, I think there are better outcomes for everyone when a project has financial backing.

A few jobs ago, when I was still working on my degree, I wrote a workflow engine for my capstone project. I was able to open-source it and used it at my work. I felt comfortable making improvements that were relevant to work on my paid time, but any community support or maintenance fell on my free time. When I moved to a new company, the project slowly bit-rotted into uselessness. I tried to find a new maintainer and I moved it to GitHub from code.google.com, to keep it on life support, but it’s functionally dead. If someone tried to adopt it today, I wouldn’t have the time to support them.

Compare that to my current project. If I got hit by a bus tomorrow, the project would carry on. Not only do I get to work on OSS, but I have time to spend with my family. In addition to writing code, I’m not just allowed, but expected to write docs, ensure we have a solid build process, respond to user questions and, in general, engage with the community to make sure users are successful and improve the project based on user needs. It feels like a sustainable approach to developing open-source software, at least for large projects.

Commercial backing does complicate community engagement somewhat. As soon as there’s a profit motive involved, people look at what you’re offering them with some suspicion. I would argue that when you’re engaging with the community, it’s not only ethical but more effective, to follow a few simple rules.

1. Be honest

2. Respect people’s time

3. Be nice

A few days ago, we had a user bring to our attention, a failure of OpenZiti on a Raspberry Pi 4 running a 32-bit operating system. As I got started investigating the bug, I smirked a little as it just so happened to be Pi day (March 14th).

OpenZiti's tunnelers have a killer feature, a superpower, if you will: "Private" DNS. "Private DNS," I hear you ask with a subtle tone of disbelief, "what does that mean?" When you have an OpenZiti tunneler running on your system with one or more enrolled identities, it's likely those services have "intercepts" configured. Those intercepts are often in the form of some DNS entry and those DNS entries are only available to your system when OpenZiti is running. That, is what it means to have "Private DNS". These private DNS entries are valuable because they are only available to people who are authenticated and authorized to have them. If you're not authorized, you won't see the entry at all. That's very cool!

Where we started​

If you were using zrok <=v0.3.3 you might have noticed that websockets weren't exactly behaving quite like we were expecting. We decided to quickly fix that to get users the features they want.

At the OpenZiti project, we heavily rely on OpenAPI specifications to streamline our development process. The OpenAPI project provides code generators that support a variety of programming languages. In this blog, we'll focus on a practical guide for using a generated OpenAPI Python client library. Using a generated client as a user of an API is not entirely a straightforward process. Investing some time upfront to understand the translation between the spec and the code will help you establish the right mental model and kickstart your development.

Postman can build a collection of API requests and has a friendly interface for walking the API specification. This article aims to accelerate your timeline for productively exploring the API and developing an integration.