Someone reached out to me over e-mail to discuss my previous post on caching your nix-shell.
“What I wish to do is to copy a particular development environment (nix-shell) from A to B, so that I could run nix-shell on server B. Server B is only accessible through SSH and does not have Internet access.”
This is part 2 of a post regarding VPNs. Please see here for part 1.
In the previous post, we discussed the basics of setting up a virtual private network; the goal of which was bridging two distinct private subnets.
This gave us the alluring property of treating separate networks as they were colocated and can be accessed easily. However most people are first introduced into VPNs for other features such as: anonymity, secrecy & privacy.
A common example may be to tunnel traffic through a host in another country to disguise the origin. For instance, maybe you are in Canada but want to browse the American Netflix catalog.
How can we extend lametun to do this?
I’ll present a few alternatives. The main goal however will to forward all traffic, including ones destined for the Internet, through the tunnel.
If you enjoy the from first principles theme, consider reading the one on containers.
Networking can seem like voodoo; many of us take for granted how data transmits from one computer to the next. Recently, wireguard, has attracted a lot of publicity for it’s inclusion into the Linux kernel & for it’s stated goal of making setting up VPNs simpler.
Behind all the magic, is a very simple premise. Let’s shed some of the complexity and break it down to first principles.
Our adventure into NixOS continues; this time let’s look into how we can harden our NixOS machines by putting them within a VPN. We will be using tailscale to setup our VPN.
Restricting your machines; especially SSH for servers; behind a VPN is a great way to add a layer of security without having to mess with various checklists like making sure password based logins are disabled.
This is part 2 of a series on nixos-rebuild. You can read part 1 here.
We previously broke down that one of the first tasks done by nixos-rebuild is to build the system attribute.
What happens next for switch ? Let’s go back to the source.
I have been using Nix but mainly through home-manager on my Debian system; finally I made the plunge into running NixOS on an AWS server for my side-projects.
There’s a lot of information on how to configure & setup an already created NixOS machine but not much advice for workflows, best practices & multiple machines.
Here I’ll document what I found useful and pulling back the veil on some of the NixOS tooling.
Feel free to check my Nix repository for home-manager & NixOS https://github.com/fzakaria/nix-home
I wrote previously about the current state of affairs for Java packaging in the Nix ecosystem; including a little blurb at the end about a little project I have been working on.
I would like to announce a beta release for mvn2nix.
You find find the similar announcement on https://discourse.nixos.org/t/mvn2nix-packaging-maven-application-made-easy/8751
Easily package your Maven Java application with the Nix package manager.
mvn2nix is my attempt & re-imagining of what a lock file type Nix Java ecosystem should look like.
I have been wanting to take part of the NixOS community more; specifically the IRC channels. I have been heavily using the Discord server but I found many other contributors are only on the IRC network. ✊
tl;dr; If the attrset contains outPath, it can automatically be converted to a String.
tl;dr; you can use the following invocation to cache your nix-shell
$ nix-store --query --references $(nix-instantiate shell.nix) | \ xargs nix-store --realise | \ xargs nix-store --query --requisites | \ cachix push your_cache
I have been hooked on Nix as a way to introduce reproducible development environments. However I had to introduce a shell.nix file for a project that relied on a very old version of nodejs.