Posts

KIND == Kubernetes in Docker I will install the KIND binary into my ~/bin/ directory since that’s where I keep all my binaries. >_ cd ~/.bin >_ curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.9.0/kind-linux-amd64 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 97 100 97 0 0 163 0 --:--:-- --:--:-- --:--:-- 162 100 642 100 642 0 0 831 0 --:--:-- --:--:-- --:--:-- 831 100 7247k 100 7247k 0 0 4742k 0 0:00:01 0:00:01 --:--:-- 18.6M >_ chmod +x kind >_ which kind /home/danesh/.bin/kind >_ kind version kind v0.9.0 go1.15.2 linux/amd64 >_ source <(kind completion zsh)

Go to the release page to get the download link for the latest version of helm. https://github.com/helm/helm/releases I prefer the binaries to be in my ~/.bin/ directory as it is already in my PATH >_ cd ~/.bin >_ wget https://get.helm.sh/helm-v3.4.0-linux-amd64.tar.gz --2020-11-06 19:41:28-- https://get.helm.sh/helm-v3.4.0-linux-amd64.tar.gz Resolving get.helm.sh (get.helm.sh)… 152.195.19.97, 2606:2800:11f:1cb7:261b:1f9c:2074:3c Connecting to get.helm.sh (get.helm.sh)|152.195.19.97|:443… connected. HTTP request sent, awaiting response… 200 OK Length: 13315267 (13M) [application/x-tar] Saving to: ‘helm-v3.4.0-linux-amd64.tar.gz’ helm-v3.4.0-linux-amd64.tar.gz 100%[======================================================>] 12.70M 77.2MB/s in 0.2s 2020-11-06 19:41:29 (77.2 MB/s) - ‘helm-v3.4.0-linux-amd64.tar.gz’ saved [13315267/13315267] >_ tar -zxvf helm-v3.4.0-linux-amd64.tar.gz linux-amd64/ linux-amd64/README.md linux-amd64/helm linux-amd64/LICENSE >_ ll total 303M drwxrwxr-x 11 danesh danesh 4.0K Oct 11 11:27 fzf drwxrwxr-x 9 danesh danesh 4.0K Nov 6 19:01 google-cloud-sdk -rw-rw-r-- 1 danesh danesh 13M Oct 26 10:37 helm-v3.4.0-linux-amd64.tar.gz drwxr-xr-x 2 danesh danesh 4.0K Oct 26 10:36 linux-amd64 -rwxrwxr-x 1 danesh danesh 54M Nov 6 18:10 minikube -rwxr-xr-x 1 danesh danesh 119M Sep 30 12:55 packer -rwxr-xr-x 1 danesh danesh 82M Sep 30 13:10 terraform -rwxr-xr-x 1 danesh danesh 37M Aug 24 18:02 vagrant >_ cp linux-amd64/helm . >_ rm -rfv linux-amd64 >_ rm helm-v3.4.0-linux-amd64.tar.gz >_ ll total 330M drwxrwxr-x 11 danesh danesh 4.0K Oct 11 11:27 fzf drwxrwxr-x 9 danesh danesh 4.0K Nov 6 19:01 google-cloud-sdk -rwxr-xr-x 1 danesh danesh 40M Nov 6 19:42 helm -rwxrwxr-x 1 danesh danesh 54M Nov 6 18:10 minikube -rwxr-xr-x 1 danesh danesh 119M Sep 30 12:55 packer -rwxr-xr-x 1 danesh danesh 82M Sep 30 13:10 terraform -rwxr-xr-x 1 danesh danesh 37M Aug 24 18:02 vagrant >_ helm version version.BuildInfo{Version:"v3.4.0", GitCommit:"7090a89efc8a18f3d8178bf47d2462450349a004", GitTreeState:"clean", GoVersion:"go1.14.10"}

I’m installing minikube on my shiny new Pop!OS 20.10 install which is based on Ubuntu 20.10. >_lsb_release -a No LSB modules are available. Distributor ID: Pop Description: Pop!_OS 20.10 Release: 20.10 Codename: groovy I prefer to have my standalone application binaries placed in ~/.bin/ which is already included in my PATH. >_ cd ~/.bin >_ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 53.3M 100 53.3M 0 0 63.9M 0 --:--:-- --:--:-- --:--:-- 63.8M >_ install -m 775 minikube-linux-amd64 ./minikube >_ ll total 343M drwxrwxr-x 11 danesh danesh 4.0K Oct 11 11:27 fzf drwxrwxr-x 9 danesh danesh 4.0K Oct 30 14:29 google-cloud-sdk -rwxrwxr-x 1 danesh danesh 54M Nov 6 18:10 minikube -rw-rw-r-- 1 danesh danesh 54M Nov 6 18:10 minikube-linux-amd64 -rwxr-xr-x 1 danesh danesh 119M Sep 30 12:55 packer -rwxr-xr-x 1 danesh danesh 82M Sep 30 13:10 terraform -rwxr-xr-x 1 danesh danesh 37M Aug 24 18:02 vagrant >_ rm minikube-linux-amd64 Verify if it’s working ...

Problem Some of my docker containers access resources from a NAS over NFS. On reboot, the Docker service comes up before the NFS paths are mounted, this causes the services within my containers to fail. Restating the docker service, systemctl restart docker fixes this but I’d rather the containers come up properly the first time. Solution Add a systemd drop-in unit for the docker service instructing it to wait for the NFS mount to come online before starting. ...

My Arch update broke today with the following error which was due to a missing soname entry in the older nss packages. The error was identified and a post describing the error with a fix was posted to the ArchLinux news feed. Read Here ? sudo pacman -Syu ..... ..... (201/201) checking for file conflicts [------------------------------------------------------------] 100% error: failed to commit transaction (conflicting files) nss: /usr/lib/p11-kit-trust.so exists in filesystem lib32-nss: /usr/lib32/p11-kit-trust.so exists in filesystem Errors occurred, no packages were upgraded. ? pacman -Syu --overwrite /usr/lib\*/p11-kit-trust.so ..... ..... ? sudo pacman -Syu :: Synchronizing package databases... core is up to date extra is up to date community is up to date multilib is up to date endeavouros is up to date 0.0 B 0.00 B/s 00:00 [c o o o o o o o o o o o o o o o o o o o ] 0% :: Starting full system upgrade... there is nothing to do