Suranyami

Sometimes, I just want to know “what's the IP address” of a machine, and I don't want to see every damn network adapter: loopback, virtual, wireless or wired…

Here's the wall of text that ip addr typically returns on a Raspberry Pi running various docker containers:

dietpi@eon:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether e4:5f:01:67:d8:10 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.238/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2403:5811:6ed:0:e65f:1ff:fe67:d810/64 scope global dynamic mngtmpaddr 
       valid_lft 86212sec preferred_lft 14212sec
    inet6 fe80::e65f:1ff:fe67:d810/64 scope link 
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:7f:98:38:dc brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
4: docker_gwbridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:69:e3:50:d0 brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.1/16 brd 172.18.255.255 scope global docker_gwbridge
       valid_lft forever preferred_lft forever
    inet6 fe80::42:69ff:fee3:50d0/64 scope link 
       valid_lft forever preferred_lft forever
1034: veth5012f18@if1033: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker_gwbridge state UP group default 
    link/ether 0a:a4:4f:99:a3:ca brd ff:ff:ff:ff:ff:ff link-netnsid 21
    inet6 fe80::8a4:4fff:fe99:a3ca/64 scope link 
       valid_lft forever preferred_lft forever
1038: veth0a22673@if1037: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker_gwbridge state UP group default 
    link/ether 5a:a6:f4:85:ad:01 brd ff:ff:ff:ff:ff:ff link-netnsid 22
    inet6 fe80::58a6:f4ff:fe85:ad01/64 scope link 
       valid_lft forever preferred_lft forever
1040: veth7324567@if1039: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker_gwbridge state UP group default 
    link/ether 06:7a:fc:bc:ba:3b brd ff:ff:ff:ff:ff:ff link-netnsid 24
    inet6 fe80::47a:fcff:febc:ba3b/64 scope link 
       valid_lft forever preferred_lft forever
1062: vethf34c1d6@if1061: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker_gwbridge state UP group default 
    link/ether be:97:31:ce:d1:20 brd ff:ff:ff:ff:ff:ff link-netnsid 27
    inet6 fe80::bc97:31ff:fece:d120/64 scope link 
       valid_lft forever preferred_lft forever
1068: vethd64996a@if1067: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker_gwbridge state UP group default 
    link/ether 2e:10:e5:36:24:cc brd ff:ff:ff:ff:ff:ff link-netnsid 6
    inet6 fe80::2c10:e5ff:fe36:24cc/64 scope link 
       valid_lft forever preferred_lft forever
976: veth5190b0e@if975: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker_gwbridge state UP group default 
    link/ether 06:bb:39:60:81:26 brd ff:ff:ff:ff:ff:ff link-netnsid 5
    inet6 fe80::4bb:39ff:fe60:8126/64 scope link 
       valid_lft forever preferred_lft forever
984: veth88f88fe@if983: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker_gwbridge state UP group default 
    link/ether 66:cb:ec:91:57:68 brd ff:ff:ff:ff:ff:ff link-netnsid 9
    inet6 fe80::64cb:ecff:fe91:5768/64 scope link 
       valid_lft forever preferred_lft forever
1007: veth49e1be0@if1006: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker_gwbridge state UP group default 
    link/ether fa:4d:cc:02:3c:6a brd ff:ff:ff:ff:ff:ff link-netnsid 14
    inet6 fe80::f84d:ccff:fe02:3c6a/64 scope link 
       valid_lft forever preferred_lft forever
1016: veth7a3a81d@if1015: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker_gwbridge state UP group default 
    link/ether 36:75:87:35:42:7f brd ff:ff:ff:ff:ff:ff link-netnsid 18
    inet6 fe80::3475:87ff:fe35:427f/64 scope link 
       valid_lft forever preferred_lft forever
1022: vetha80dc19@if1021: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker_gwbridge state UP group default 
    link/ether 72:d5:af:ce:a5:6c brd ff:ff:ff:ff:ff:ff link-netnsid 20
    inet6 fe80::70d5:afff:fece:a56c/64 scope link 
       valid_lft forever preferred_lft forever

So, what's the alternative?

These worked for me:

hostname -I | awk '{print $1}'

# ...
$ hostname -I | awk '{print $1}'
192.168.1.238

or using the results from a DNS query:

ip route get 8.8.8.8 | awk '{print $7}'

# ...
$ ip route get 8.8.8.8 | awk '{print $7}'
192.168.1.238

Discuss...

These last few years, I've been trying out a Kamado Joe smoker.

It's been challenging.

There are a number of things that make them completely different to a normal barbecue. I previously had a simple Weber barbecue. It worked fine for hot and fast cooking and after a bit of burn-down and ash-over, you could easily do a few low & slow things as long as you kept your expectations within an hour or two. There was no thermal insulation to speak of, except for a dome of steel with an adjustable outlet.

A smoker of the sort similar to a Kamado Joe (there are plenty of them…) is a different animal all together.

The first thing to know is this: refractory bricks stay hot for up to 24 hours.

The insides of these types of smokers are modelled similarly to the best pizza ovens and metal refineries. Heat dissipates, and that's bad, if you need to make something hot. It means you need to keep supplying fuel to keep things hot.

That's where refractory bricks come in: they reflect heat back from where they came from.

The outside of a Kamado Joe needs to be running for quite some time before it even gets slightly hot, because of these bricks.

This presents 2 problems:

1. If I want something to cook low and slow for a long time, I need lots of fuel.
2. If I ignite a lot of fuel, everything will get very hot and generally have a texture like leather.

So what's the solution?

I found 2 helpful procedures that, after experimenting with them, I can verify they do help make things a lot easier:

1. The “minion method”. This entails making a semi-circular chain of charcoal with smoking chunks positioned above each section, such that when lit at one end, it slowly burns through the entire chain, a bit like a very slow fuse.

2. A tray of water. This is so obvious in retrospect! Ideally, the internal temperature should be in the 120-150°C range. Water will have a beneficial feedback effect: too hot and the steam will suppress the burning, too low and it won't do much except act as thermal inertia.

A combination of the 2 above hints, allowing the first burn to properly ash over, and not moving the air inlets/outlets too chaotically has led to much more predictable outcomes.

Today's bounty was:

• Totally bodaciously tender pork shoulder with brown sugar, mustard and left-over Nong-Shim Ramyun spicy instant noodle powder rub.
• Tender-as roast chicken from the last 2 hours of the above pork cook, prepped with lemon zest, smoked paprika and oregano rub with olive oil and smoked salt.
• Purple Japanese sweet potatoes wrapped in foil with olive oil, pepper and salt.
• Smoked long, sweet peppers
• Baked and smoked aubergine.

One of the things that made all of the above much, much easier was having a decent temperature probe. I have a Meater probe, and it's worth every cent.

Discuss...

Create a network for nginx-proxy-manager to use:

docker network create nginx-proxy-manager-network

Then add this to all the compose files that want to be referenced by Nginx-Proxy-Manager:

networks:
  nginx-proxy-manager-network:
    external: true

Now you can use the service name as the host in the Nginx-Proxy-Manager GUI:

Source	Destination
awwesome.suranyami.com	http://awwesome:8088

Discuss...

My current Homelab server rack:

• Turing Pi 2 cluster, now with 4 x RK1 3588 8-core arm_64 CPUs with 32GB RAM each (not shown in pictures below), 6 TOPS NPU, in a 2U Silverstone rack-mount case, fans, 8-bay hot-swappable SSDs, 4TB SSDs x 4
• a bunch or Raspberry Pi 4s (4GB x 2, 8GB x 1, 1TB NVMe SSDs in Argon One cases)
• Radxa Rockchip 5B 16GB RAM, 4TB NVMe. 8-core arm_64, 6 TOPS NPU + case
• Argon Eon, RasPi 4, 4GB RAM 4 x 4TB SSD
• Radxa Penta NAS kit with RockChip 4 4GB + 4 x 4TB SATA SSDs
• UPS + surge protection, because we had a power surge during a storm here a few months ago that destroyed one of the RasPi CM4s I had in the Turing Pi 2, a power supply, and a 15” portable LCD monitor… expensive power surge! It’s the 21st century… you’d think these things wouldn’t happen any more, but they do.

This is all instrumented by a Portainer/Docker Swarm setup running:

• Nginx-Proxy-Manager (Simple reverse proxy manager)
• DuckDNS (Dynamic DNS)
• Minecraft Server (suranyami.duckdns.org:25565)
• Awwesome Self-Hosted Browser link (no login required)
• Excalidraw (FOSS collaborative drawing webapp, no login required)
• Homarr (Home page for all my services)
• Home Assistant (IoT control for smart devices)
• Jackett
• Joplin Server (Knowledge Base)
• Netdata monitoring on most nodes
• Ollama + Ollama WebUI (really slow ATM… installing NPU drivers this weekend, coz the RockChip 3588s have 6 TOPS of neural processing)
• Overseer
• Plex Media Server
• Radarr
• Sonarr
• Tautulli
• Tdarr
• IT-Tools (No login needed). Check it out! It’s very useful!
• Transmission (Torrents)
• Uptime-Kuma (Uptime monitoring)
• WG-Easy Wireguard VPN management
• GlusterFS distributed File System with 2 x redundancy, 1 unified storage volume of 18TB in total

Discuss...

Today I needed to different layouts for public-facing and authorised pages in a LiveView app.

After an annoying amount of digging in documentation and forums, the following was the most elegant solution I found.

Assume we have these layouts in myapp/lib/myapp_web/components/layouts/:

authenticated.html.heex
public.html.heex

And, also assuming that there is something different in each layout: stuff you can't use unless signed in.

In lib/myapp_web/router.ex modify these authentication routes to add a layout: in the live_session statements:

  scope "/", MyappWeb do
    pipe_through [:browser, :redirect_if_user_is_authenticated]

    live_session :redirect_if_user_is_authenticated,
      on_mount: [{MyappWeb.UserAuth, :redirect_if_user_is_authenticated}],
      layout: {MyappWeb.Layouts, :public} do
      live "/users/register", UserRegistrationLive, :new
      live "/users/log_in", UserLoginLive, :new
      live "/users/reset_password", UserForgotPasswordLive, :new
      live "/users/reset_password/:token", UserResetPasswordLive, :edit
    end

    post "/users/log_in", UserSessionController, :create
  end

  scope "/", ReflectalWeb do
    pipe_through [:browser, :require_authenticated_user]

    live_session :require_authenticated_user,
      on_mount: [{MyappWeb.UserAuth, :ensure_authenticated}],
      layout: {MyappWeb.Layouts, :authenticated} do
      live "/dashboard", DashboardLive.Show, :show
      live "/users/settings", UserSettingsLive, :edit
      live "/users/settings/confirm_email/:token", UserSettingsLive, :confirm_email
    end
  end

The important lines here are:

      layout: {MyappWeb.Layouts, :public} do

and

      layout: {MyappWeb.Layouts, :authenticated} do

Simple!

Discuss...

Here's a top tip to avoid:

Ironbark smoke is abso-fucking-lutely vile. Do not use a couple of ironbark logs in your smoker unless they have completely burnt down to embers and can be used to ignite something that doesn’t make everything taste like sadness and other people’s headaches.

I just managed to ruin an entire barbecue this way. Learn from my stupidity: just never do this.

Discuss...

Countries

Language

に (ni) ほん (hon) ご (go) Japanese (language)

---

えい (ei) ご (go) English (language)

Nationality

Nationality

Discuss...

I had a bit of a mystery that was bugging me for ages. After enabling automatic formatting for Elixir files in VSCode, I was getting ugly highlighting that looked like this:

It turns out this is a feature of the RainbowIndents extension to show you where you have inconsistent indenting (e.g. 3 spaces, when everything else is 2).

The problem with this is mix format has unchangeable opinions about indenting, such as in a with statement, where it cares more about alignment than even/odd indent boundaries.

The fix is to exclude indentation errors for Elixir. In your settings.json add this:

With that in place, we now get plain ol' rainbow indenting:

Discuss...

This first appeared in a forum post on community.fly.io

I've updated it a bit with some clarifications and a fix for a version-clash issue I had.

Setup the project

$ mix phx.new hello  --umbrella --no-ecto --install
$ cd hello_umbrella

Enable server in config/runtime.exs:

config :hello_web, HelloWeb.Endpoint, server: true

Add elixir_buildpack.config with the preferred Erlang and Elixir versions:

$ cat <<EOF>./elixir_buildpack.config
elixir_version=1.14
erlang_version=24.3
EOF

I had problems with too-specific versions in the above, so just use major versions, e.g. elixir_version=1.14 versus elixir_version=1.14.3-otp-24

Deploy the assets from within the web app directory:

$ cd apps/hello_web
$ MIX_ENV=prod mix assets.deploy
$ cd ../../

Setup the Fly stuff

$ fly launch

Answer “no” to deploy request and leave fly launch, then set up the secret:

$ export SECRET_KEY_BASE=$(mix phx.gen.secret)
$ fly secrets set SECRET_KEY_BASE=$SECRET_KEY_BASE

Deploy:

$ fly deploy

Enjoy your app!

$ fly open

and the umbrella application is finally happily up and running!

Summary

Besides the steps above, here are the summary of the current differences in how Fly handles deployment between plain and umbrella.

to deploy an Umbrella via Fly:

• you have to explicitly set server: true in config/runtime.exs
• you have to add the required elixir_buildpack.config file to the project
• you have to build the application assets
• you have to set the SECRET_KEY_BASE executing fly secrets after fly launch and before fly deploy (you can’t just export it to an environment variable)
• the Fly builder will not generate a Docker file as is the case with plain apps (but if you supply one, the builder will use it)

Discuss...

Install iperf

on MacOS:

brew install iperf

on Linux:

sudo apt install iperf -y

Start iperf on the server:

iperf -s

This waits for incoming connections from clients. Designate another machine as a client and run this command, substituting the IP address of your server machine for the sample one here:

iperf -c 192.168.1.2

Results

Setup was:

Results were:

> iperf -c 192.168.1.238
------------------------------------------------------------
Client connecting to 192.168.1.238, TCP port 5001
TCP window size:  128 KByte (default)
------------------------------------------------------------
[  1] local 192.168.1.91 port 58359 connected with 192.168.1.238 port 5001 (icwnd/mss/irtt=11/1448/12000)
[ ID] Interval       Transfer     Bandwidth
[  1] 0.00-10.28 sec  63.9 MBytes  52.1 Mbits/sec

Discuss...