Getting X11 client work with x2go from docker container

Details

Category: Blog

Published: Thursday, 09 September 2021 16:44

Written by Lars Berntzon

Hits: 2176

Having a X11 client running in a docker container to run properly in a x2go session is not quite straight forward from normal X11 clients in docker. To make it work its important to have the option --network=host set.

Like this:

docker run -e HOME=$HOME -e DISPLAY=$DISPLAY --network=host -it -v /tmp/.X11-unix:/tmp/.X11-unix -v $HOME/.Xauthority:$HOME/.Xauthority --user $(id -u):$(id -g) "image-name"

kubeadm upgrade node failing with "failed to get config map: Unauthorized"

Details

Category: Blog

Published: Thursday, 02 September 2021 15:46

Written by Lars Berntzon

Hits: 1999

Are you getting below errors when running: kubeadm upgrade node

[upgrade] Reading configuration from the cluster...
[upgrade] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
unable to fetch the kubeadm-config ConfigMap: failed to get config map: Unauthorized
To see the stack trace of this error execute with --v=5 or higher

Chances are that the kubelet certificate is expired and can not be used to upgrade the node. A strace of that command reveals it does not really use the current users config but the file /etc/kubernetes/kubelet.conf. That file does in turn point to the key and cert to be used. In my installation both cert and key refered to /var/lib/kubelet/pki/kubelet-client-current.pem as follows:

client-certificate: /var/lib/kubelet/pki/kubelet-client-current.pem
client-key: /var/lib/kubelet/pki/kubelet-client-current.pem

That file is in turn a symlink to the real file, in my case was /var/lib/kubelet/pki/kubelet-client-2020-06-04-18-38-46.pem - which for some reason was not updated recently.

You need to create an updated cert/key file there and change /var/lib/kubelet/pki/kubelet-client-current.pem to this new file instead. 

Problem solved.

Problems after changing IP-addresses of kubernets masters

Details

Category: Blog

Published: Friday, 03 September 2021 15:15

Written by Lars Berntzon

Hits: 1981

Just a small tips. Check the config map cluster-info in namespace kube-public. There is an IP address published there.

Gluster cluster split in two?

Details

Category: Blog

Published: Monday, 07 June 2021 17:26

Written by Lars Berntzon

Hits: 1955

It can happen that a Gluster cluster gets divided in two parts. I'm not talking a about a volume split brain here but a whole cluster. Something might have gone wrong when probing a node. Or as in our case when adding aliases for nodes, the peer info file was corrupted (seems to be a maximum name length for nodes) which caused some nodes to believe they where in another cluster.

The solution to this is to first decide which nodes you consider as the proper cluster. Running gluster peer status will show you what other nodes are considered to be in the same group as the node you run the status command on. Nodes that are in state "Peer Rejected State" might thing they are part of another cluster. If most of the nodes are in "Peer Rejected State", then probably you should run the command on one of those nodes in rejected state and you will see that most nodes there will be in ok state.

On all those nodes in rejected state, run following procedure:

1. Stop glusterd
2. Remove all files from /var/lib/glusterd except the glusterd.info-file
3. Start glusterd again
4. Run a gluster peer probe to a member node.
5. Restart glusterd again

Other lessons learned:

Do make sure that you save the glusterd.info file, if not a new one will be created and effectively you will be creating a new node, with the same name. To solve this, stop the glusterd daemon on all nodes, remove the faulty uuid from /var/lib/glusterfs/peers and restart glusterd on all nodes again.
I did not find this error immediately and I was strugling with a lot of locking errors in glusterd.log file and any "gluster volume status" command would just hang for ever.