I would agree that it's not super-simple, but there are advantages...for some people. For instance, NM logging when using NM "native" connection configuration has more information, which is handy when something goes sideways. But the logging for NM "legacy" connections (NM actually handles the /etc/network/interfaces.d/* files) isn't bad. It's just not as complete.Sorry, its still not clear.There are at least two solutions:
- nmcli in Bookworm supports the --offline switch, enabling you to do configuration prior to first boot
- Configure it up online as static and with everything else you want, then save away the .nmconnection file. Only two things to fix: 1) The static IP address, and 2) the UUID, but there appears to be no issue in using the same .nmconnection file across multiple systems. So, only one thing to fix Image may be NSFW.
Clik here to view.Learning what this means in practice seems complicated compared to simply copying "eth0" into /etc/network/interfaces.d while the SD card is mounted on the local computer - which takes seconds and works every time.Code:
--offline Work without a daemon. Makes connection add and connection modify commands accept and produce connection data via standard input/output. Ordinarily, nmcli would communicate with the NetworkManager service.
There are some ways to simplify using 'nmcli --offline', but it's beyond the scope of this thread.
The other method I suggested was simply using an existing .nmconnection file and placing it appropriately, more or less as you are doing with your 'eth0' file.
Here's my eth0.nmconnection file for DHCP-managed systems: I put this on all my "workstation" type systems, and/or servers that get their "static" address from my DHCP server.
Code:
connection]id=eth0uuid=aafb8b76-81da-3a3e-b525-f5b9194ab3cbtype=ethernetautoconnect-priority=100interface-name=eth0[ethernet][ipv4]method=auto[ipv6]addr-gen-mode=defaultmethod=disabled[proxy]
Code:
[connection]id=eth0uuid=aafb8b76-81da-3a3e-b525-f5b9194ab3cbtype=ethernetinterface-name=eth0[ethernet][ipv4]method=manualaddress1=192.168.92.3/24gateway=192.168.92.1dns=192.168.92.3dns-search=mydomain.com;dyn.mydomain.com;[ipv6]addr-gen-mode=defaultmethod=disabled[proxy]
I don't see how putting anything into /boot is going to help you configure your network without a bit of additional code. You need to get your eth0 file into /etc/network/interfaces.d, which abstractly is no different from putting .nmconnection files in /etc/NetworkManager/system-connectionsFor example, I have just written Raspberry Pi OS to an SD card (say) on another computer (enabling ssh by creating the file "ssh" in /boot).
I then want to place the SD card in a Pi, and for that Pi to boot and be immediately accessible using existing entries in the local /etc/hosts file.
I do not want to spend ages messing with nmap trying to find the address DHCP has given it.
The local machine, by the way, might be running any reasonable OS.
As far as your goal of having a Pi boot and be immediately accessible using existing entries in the local /etc/hosts file, yes, that is one way to solve the problem. But it requires that each host have an updated /etc/hosts file. Easy for Linux hosts, but not quite as easy for non-Linux OSen.
A much better approach IMHO is to have a single definition point for the network. Store that in some kind of database. For home networks, that can be a text file. In fact, a JSON file works really well. From that JSON file generate the config files for the DHCP and DNS servers. All hosts on the LAN are configured to use the local DNS server because the DHCP server tells them to configure themselves that way.
Only the DHCP/DNS server needs to have a static address actually configured on the device. The rest get their statically-assigned IP address from the DHCP server.
One flaw you might point out is that the DHCP/DNS server is a single point of failure. I don't think it's any worse than the scenario where these services are running on the router. I can easily configure a second server (or fix or replace the broken DHCP/DNS server) if needed.
But, in 25+ years running my own LAN this way, I've had DHCP/DNS outages exactly zero times.
Statistics: Posted by bls — Wed May 29, 2024 3:04 am