Filipe Pina's questions

Rancher documentation on k3s is quite nice and its HA support (both with external DB or embedded etcd) look nice, but I don't want/need an HA setup.

In case my master node fails, I don't mind having downtime while I re-create it or make a master out of another one, but I cannot find documentation how to switch master node.

Which files should I backup regularly (or host in NFS mount which is what I want to do) so I can easily re-setup the cluster with another server node but with the exact same state?

For the initial setup, we do:

• master: curl -sfL https://get.k3s.io | sh
• worker: curl -sfL https://get.k3s.io | K3S_URL=\"https://${MASTER_IP}:6443\" K3S_TOKEN=\"${TOKEN}\" sh -s

If I just re-run the scripts choosing another master, I'll have all the state lost. Is there a single directory I can copy/preserve (and an argument to pass to script to re-use it)?

I was running a container based on the image linuxserver/radarr:3.0.0.3095-ls12.
Once I updated the tag/version to linuxserver/radarr:3.0.0.3807-ls24 the application stopped working.

After debugging a little I noticed that date behaves weirdly in this image:

$ docker run --rm --entrypoint "" linuxserver/radarr:3.0.0.3807-ls24 date
Fri 20 Feb 1970 03:17:15 AM UTC
$ docker run --rm --entrypoint "" linuxserver/radarr:3.0.0.3807-ls24 date
Sun 01 Mar 1970 09:09:15 AM UTC
$ docker run --rm --entrypoint "" linuxserver/radarr:3.0.0.3807-ls24 date
Thu 19 Feb 1970 09:04:59 AM UTC

But the old doesn't

$ docker run --rm --entrypoint "" linuxserver/radarr:3.0.0.3095-ls12 date
Sat 10 Oct 2020 12:15:09 AM UTC

After meditating for a while, assuming some kind of weird dark magic in the clock, decided to run it with --privileged for full/raw access

$ docker run --rm --entrypoint "" --privileged linuxserver/radarr:3.0.0.3807-ls24 date
Sat 10 Oct 2020 12:16:22 AM UTC

And it worked well (and so did the app, but not important to the question).

I have gone through docker history of both images but a lot of COPY and RUN curl that might have different results between builds. Still, I don't think anyone (image maintainers) would want to mangle with the date, so it must be something out of their control (no libfaketime found)...

This is a multi-arch image and these results are from a raspberry Pi (so the arm build of the image). In my amd64 linux laptop, the latest image reports proper date even without privileged...

What could it be? How can I even start to debug this as I cannot use the --privileged flag?

I've had this issue ever since I got this new router and flashed it with dd-wrt.
It's not really impactful (I'll describe the scenario) but I'm curious about it...

This is the diagram of the network setup:

• Manjaro Linux running on VMware Fusion (in a Mac/OSX host) connected through WiFi
• 3 raspberry Pis (running Raspbian) connected to switch 1 (and then router)
• 1 NAS (WDCloud) connected to switch 1
• 1 raspberry Pi connected to switch 2 (which is connected to switch 1)

Given the setup, the issue:

• Mac over WiFi, Manjaro VM in bridged mode
  • Pinging any of the 4 Pis shows packet loss in under 5min - sometimes 20%, sometimes more
  • Pinging the NAS shows no packet loss at all
• Mac over WiFi, Manjaro VM in NAT
  • no packet loss on any scenario
• Mac over LAN, Manjaro VM in NAT or Bridged mode
  • no packet loss on any scenario

So, my initial guess was that it was something related to Fusion bridged mode because pinging directly from Mac (host) never had any loss (nor using the VM with NAT).

• Tried Virtualbox, same happens (bridged shows packet loss, NAT does not).
• Played a lot with DDWRT WiFi settings but nothing seemed to make any difference.

Realized that pinging NAS had no packet loss so it looked like something only in the Bridged+WiFi+Raspberry combination, so I ran tcpdump icmp on one of the raspberries and started pinging from the VM

Ping output in the VM:

64 bytes from  (192.168.1.22): icmp_seq=13 ttl=64 time=2.40 ms
64 bytes from  (192.168.1.22): icmp_seq=14 ttl=64 time=2.50 ms
===> lost sequences 15 to 42 <===
64 bytes from  (192.168.1.22): icmp_seq=43 ttl=64 time=34.1 ms
64 bytes from  (192.168.1.22): icmp_seq=44 ttl=64 time=2.31 ms

tcpdump output in the Pi:

01:24:42.397835 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 13, length 64                                    
01:24:42.397919 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 13, length 64                                      
01:24:43.399899 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 14, length 64                                    
01:24:43.399948 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 14, length 64                                      
01:24:44.404887 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 15, length 64                                    
01:24:45.422542 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 16, length 64                                    
===> requests hit but no replay is sent... <===
01:25:12.044102 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 42, length 64                                    
01:25:13.068516 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 43, length 64                                    
01:25:13.099164 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 43, length 64                                      
01:25:14.071065 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 44, length 64                                    
01:25:14.071129 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 44, length 64                                      

Conclusion (I think): ping requests hit the raspberry Pi but no replies are sent (for that period, about 30s).
I'm using ping as it is the easiest to show/test packet loss, but this also happens with TCP as SSH sessions hang now and then.

Any hints on what to check on the raspberry pi configuration to understand why it's not sending the ICMP replies? It makes it look related to the Pi, but why would this not happen in the other scenarios (Mac WiFi + VM bridged), as the Pi remains constant?