https://rancher.com/ logo
Join Slack
Powered by
This message was deleted.
# harvester
a
This message was deleted.
r
I'm setting up a three node lab with hopes of building confidence in Harvester. I'm using the patched 1.2 ISO with Intel NUCs. If I get the management interface working on the wireless adapter then I'll dedicate the wired adapter to storage. After booting the installer image, I'm able to switch to tty2 and run terminal commands. I found that nmcli is not installed, and the installer appears to be using Wicked. I was unable to find any blog posts or docs to this effect, and I can only search 90 days of history in Slack because the workspace is on the free plan. Feels like I might be blazing a trail here, so I'm wondering if there are any fellow travelers out there that would share some wisdom, or caution me to turn back. Thanks!
I was able to configure wpa_supplicant and Harvester network configuration succeeded.
I followed this doc to supply the wireless network info during the install, but the wireless configuration is not persisted. https://harvesterhci.io/installation/harvester-configuration/#oswifi So far, the only way I can see to use the wireless adapter is to manually configure wpa supplicant after each boot.
I was able to persist the wpa supplicant configuration by adding a file definition in /oem/90_custom.yaml. However, I noticed there was already some correct configuration for an incorrectly named wireless adapter. The file ifcfg-wlan0 should be named ifcfg-wlo1. Finally, there was incorrect configuration for the correct adapter name, ifcfg-wlo1. After deleting that element from the list of files the network is correct and persisted after a reboot.
I'm still struggling with the necessity of manipulating the generated 90_custom.yaml to align the wireless adapter name and WPA config params. I see now that the simplistic Harvester configuration file scheme does not express the WPA configuration I need for this particular network, which uses WPA3 SAE CCMP, not WPA2 PSK. I think I need to figure out how to express the configuration as valid Wicked ifcfg parameters, but 
man ifcfg-wireless
doesn't work in Harvester because 
man
is not installed. Maybe I need to install OpenSUSE or SLE Micro on the device first to fiddle wireless configurations. I've experimented with setting 90_custom.yaml overrides for both wpa_supplicant.conf and ifcfg-wlo1, but there may be a parsing error in the YAML because none of the configuration in that file is applied at all during startup after adding my changes.
😠
✅ SOLVED The problems were: 1. 
/oem/90_custom.yaml
was invalid and failed to load my changes, and all config, because I used tabs instead of spaces in vim and they look the same, so I didn't notice. 2. I needed to modify the Wicked ifcfg that's generated by the installer (from document linked above) because I'm using WPA3, not WPA2. In `/oem/90_custom.yaml`: a. I needed to add 
WIRELESS_KEY_MGMT='SAE'
b. I had to change the path from 
ifcfg-wlan0
to match the actual interface name 
ifcfg-wlo1
.
👏 1
(it wasn't necessary to constitute a wpa_supplicant.conf in 90_custom.yaml because the Wicked params in the ifcfg file are sufficient to associate with the access point)
I gave up trying to contribute a documentation enhancement because the "edit this page" button on the doc is a broken link to https://github.com/harvester/harvesterhci.io/edit/main/static/docs/installation/harvester-configuration.md
w
For dev/test wireless could work (via the custom YAML file) but definitely not for production. Personally for my home lab I'd use a USB Ethernet NIC if I need a second network connection.
💯 1
t
Also, you can create other .yaml files in /oem like /oem/91_my_wireless_config.yaml and those will get processed during boot. You can overwrite the same files in your yaml as are written in the original /oem/90_custom.yaml. This is a bit easier than modifying the original and I believe that as long as you are using a filename that sorts after 90_custom.yaml, then your changes will override those in 90_custom.yaml.
👍 1
r
Thank you. I agree that's easier. With that I can compact the first boot console steps to cURL the custom yaml snippet and reboot. The custom yaml only needs to override ifcfg-wlo1 with supplicant params to bring up the metal node on the lab LAN. Additional interfaces can be configured later for VM networks and Longhorn.
Open in Slack
PreviousNext
Powered by