Author: Howie

I was already using kubectl with some plugins, and the nice completion already set up, to access remote Kubernetes clusters from my Ubuntu desktop. So when I decided to try microk8s, I wanted to keep the same convenience, without maintaining two configs, or having two different commands. It took a little bit of research to figure out how to make it work, so here it is.

First, find the admin password for your microk8s:

microk8s.kubectl config view | grep password

Now you can create a new context in kubectl, adding in your password on line 2:

kubectl config set-cluster microk8s --server=https://127.0.0.1:16443/ --certificate-authority=/var/snap/microk8s/current/certs/ca.crt

kubectl config set-credentials microk8s-admin --username=admin --password={password from before}

kubectl config set-context microk8s --cluster=microk8s --namespace=default --user=microk8s-admin

Now you can switch to the new context with kubectl config use-context microk8s and work as before. kubectl config get-contexts will list the other available contexts so you can switch back.

I’ve had this strange problem for about a year or more, where on my main Windows system, I can’t log in to local Linux servers using SSH Public Key authentication. I get this “Server refused our key” message. The same key files on a different computer work fine though.

Tonight I finally got annoyed enough to investigate deeper. Googling did not help me, so here’s a blog post so that it might help you. The final straw was installing the RancherOS ISO, which exclusively uses SSH keys, and not being able to get into it from my normal desktop. I suspect this is not the most common cause of “Server refused our key” errors, especially if you are getting them from multiple client to the same server. Look at the server’s SSH config in that case.

I use Pageant, and it has my usual keys loaded at boot time.

So I enabled debug logging in Putty and SSHed to my Linux desktop.

With that enabled, I was able to see this in the logs:

Event Log: Reading key file "C:/xampp/htdocs/cacti-1.0.6/plugins/weathermap/dev/Vagrant/.vagrant/machines/develop/virtualbox/private_key.ppk"
Event Log: Pageant is running. Requesting keys.
Event Log: Pageant has 4 SSH-2 keys
Event Log: Configured key file not in Pageant

So it turns out that at some point I had a Vagrant box running, and saved its private key into my DEFAULT putty profile. From there, it got saved into other profiles. Further, if putty had a specific key in this box, and it no longer exists, it never gets as far as the Pageant-supplied keys, and just gives up!

Removing that entry (at the bottom of the SSH auth section) has cured all my problems, and RancherOS is back on the menu!

This is quite a niche thing, but since it took me ages to piece it together, here it is.

I run a PXE build environment for bare-metal install of new systems. I use PuppetLabs’ Razor to do the installation bit, and that works well. I do this for multiple environments, and I wanted to have a single server serve all of these related subnets (they come and go as projects complete). The single server acts as TFTP, DHCP, & Razor server for each subnet, as well as a NAT for external access, so it’s possible to use any IP addressing inside the build environment (except the network the razor box is on, of course).

In each subnet, the DHCP config is somewhat complicated. Aside from the normal DHCP stuff (IPs, gateway etc), the boot file to be used varies depending on the client-id of the host. EFI devices get a difference iPXE boot file from BIOS devices. Also, iPXE then makes its own DHCP request, which needs to be given a script instead. The script filename is different per subnet. The naive way to do all that results in an enormous tangle to update as projects change.

So my goals:

1. Single copy of the boot file switchy config
2. Simple to update/edit config for new subnets

For the switching stuff, I started with this Gist from robinsmidsrod, and chopped out the cases I don’t care about. That leaves me with this include file:

option ipxe.no-pxedhcp 1;

if exists user-class and option user-class = "iPXE" {
    # THIS IS DIFFERENT PER SUBNET
    filename "bootstrap-172.19.19.0.ipxe";
}
elsif option arch = 00:06 {
    # EFI 32-bit
    filename "ipxe-x86.efi";
}
elsif option arch = 00:07 {
    # EFI 64-bit    
    filename "ipxe-x64.efi";
}
elsif option arch = 00:00 {
    # Legacy BIOS x86 mode
    filename "ipxe.pxe";
}

and scopes like:

# Network 1
subnet 172.19.19.0 netmask 255.255.255.0 {
   range 172.19.19.10 172.19.19.49;
   option routers 172.19.19.1;
   next-server 172.19.19.1;

   include "/etc/dhcp/ipxe-common-172.19.19.0.conf";
}

So that works, but has a lot of duplication! Being able to define parameters would be useful.

So that looks like this:

option bootstrap_file code 254 = string;

# Network 1
subnet 172.19.19.0 netmask 255.255.255.0 {
   range 172.19.19.10 172.19.19.49;
   option routers 172.19.19.1;
   next-server 172.19.19.1;

   option bootstrap_file "bootstrap-172.19.19.0.ipxe";

   include "/etc/dhcp/ipxe-common.conf";
}

and then:

if exists user-class and option user-class = "iPXE" {
    # THIS IS *NO LONGER* DIFFERENT PER SUBNET
    option bootfile-name = concat("",config-option bootstrap_file);
}

in the included file means that nothing needs to change in there anymore. I can just add a new scope in a few lines, drop in the appropriate TFTP file and be up and running.