-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Move Network Manager bits into extensions #6756
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
aae3bf4
to
0a66b50
Compare
Overall I think this is a great idea 👍 Having stuff in a modular fashion definitely has its advantages. |
00a6c0c
to
ea11602
Compare
I just tested with networkd, it won't even detect the ethernet, like no connection is up without manual config. Any manual config won't work since the ethernet interfaces have different names (sometimes lan, wan, eth0, enps***, ...). We need auto detection. |
It works now.
Yes, it only works when its eth0 ... |
d60374f
to
cd60f67
Compare
Okay I got it! In
This will match all network interfaces and stuff will work automatically with DHCP enabled, like expected. |
5787057
to
12b18f5
Compare
Oh no, I was just working on a common Netplan config 😂 |
https://github.com/armbian/build/blob/main/packages/bsp/common/usr/lib/armbian/armbian-firstlogin#L50-L118 will get messy when not using Netplan or another common way of config unfortunately. But good news, I have tested a minimal system with networkd and alos with networkd+Netplan. There is not difference in RAM or CPU usage since Netplan only generates a config for the managing service (networkd or network-manager). So it should be fine to include in the minmal image 👍 Sorry by the way for spamming this PR, it's probably not the best idea to have more than one person work on the same topic 😅. I just enjoy networking stuff 😄 |
OK, lets go back then ;) I have no problem with that. I haven't done anything in the messy areas yet.
I appreciate your input. Doing this together is better!
Networking is my passion too. Sorry for taking away something enjoyable 😄 |
Thanks! I did some substantial changes which are currently working pretty well I think. I can push them later. But maybe it's better if I open a new PR for this instead of pushing to this PR? |
In which area? I am not done yet with 1st config - setting up netplan config from external input and I haven't test network manager much yet. |
- use Chrony with Network Manager - use timesync with systemd-networkd - use NetPlan with Network manager only - move command-not-found to CLI image only - improve firstlogin ip detection
Maybe I'll put the config documents for the extensions in their own folder instead of doing I can't build at the moment because |
Also remove `$BRANCH == dev` line since dev branch does not exist anymore
Done with the |
- Use resolved no matter what manages the network (networkd or NetworkManager) - Use resolved.conf.d/ directory to set DNS as recommended by resolved itself - In armbian-firstrun, remove config specific to mvebu64|mt7623 since this is now done by default
This should also include the case if zero retries are left, but the IP address has been found on this last retry.
The IP address function should now work pretty stable. And it doesn't need to ping anything :) |
…ve defined AP for wifi. Which we don't have yet.
If we have more ethernet devices, we want to list them one after another Before: IP address: 1.1.1.1 2.2.2.2 After IP address: 1.1.1.1,2.2.2.2
I am pleased with our common achievement and I think we are ready to go. Functionality is added, documentation is ready and there are in general less bugs then before. |
I agree, nice one! It was a lot of work, but network stuff should be pretty good now and likely easier to maintain in the future 👍 Although I don't quite understand this commit yet: 8d94b9e
|
Yep. Wish for refactoring networking was year(s) old :) Now finally ✔️
My test wireless device represented itself as Ethernet ... otherwise this would be unnoticed. |
Ah yes! It feels great when some long wish is finally fulfilled 😄
I see, that's a problem. On the other hand, only checking if it's not What's your output for the wifi device when you do For ethernet it is Maybe
can find your wireless device and filter it out? Or maybe |
Yes, I think this is just fine as for 1st run we don't expect to have that. For automated scenarios this also doesn't apply as configuration is pushed to the system.
Classification is clearly wrong,
I am pretty sure this is not the only one ... (cheap) wireless networking is IMO quite a mess. |
Sure but I think it may be forgotten if we don't fix it soon 😅 Maybe I have too high expectations regarding quality though, lol
What do you mean?
Oh no :( |
This is perfectly fine. I am just trying not to go overkill ;)
I mean if we preset network configuration, wizards does not run. For wireless. I would propose not getting further as we are opening Pandora box LOL |
else | ||
# Search for the extension file in any subdirectory | ||
extension_file=$(find "${extension_base_path}" -type f -name "${extension_name}.sh" | head -n 1) # Example format: extensions/network/net-network-manager.sh | ||
if [[ -n "${extension_file}" ]]; then | ||
# Extract extension dir from file, e.g. from "extensions/network/net-network-manager.sh" the dir "extensions/network/" gets extracted | ||
extension_dir="${extension_file%/*}" | ||
break | ||
fi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty late to this party, but I think this opens up too many possibilities for confusion. eg if someone has a/a/b.sh
and a/a/a/b.sh
which is loaded? I appreciate being able to group extensions in sub-directories, but really we should be explicit about them. @ColorfulRhino
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I agree this is not solved pretty, I wish I had found a prettier solution.
The reason for this was to be able to group multiple extensions (in this case networking stuff) in one folder as to not let the extensions folder become a massive clutter-dump.
The ultimate goal is to move more stuff into extensions as to make things more modular and replacable in general. If stuff is baked hard into the system, it's difficult and time-consuming to change stuff.
cat <<- EOF > "${SDCARD}"/etc/systemd/resolved.conf.d/00-armbian-default-dns.conf | ||
# Added by Armbian | ||
# | ||
# See resolved.conf(5) for details | ||
|
||
[Resolve] | ||
DNS=${NAMESERVER} | ||
EOF |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the necro @ColorfulRhino but I've been badly bit by this. This seems to force resolved to use $NAMESERVER (which is always in practice set to 1.0.0.1
) despite anything obtained through DHCP. I don't think we should have this in at all -- $NAMESERVER is required during image building but should be left to DHCP or manual user configuration at runtime. Why did you introduce this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rpardini Also sorry for the delay. After looking back at the commit, it seems that the intention was to follow best practices to save systemd config snippets in the *.conf.d
folder (as described in resolved.conf(5)). These snippets also make it easier to spot which configs have been added specifically by Armbian or by other means.
My intention was not to introduce anything new, the impression was that the new:
cat <<- EOF > "${SDCARD}"/etc/systemd/resolved.conf.d/00-armbian-default-dns.conf
# Added by Armbian
#
# See resolved.conf(5) for details
[Resolve]
DNS=${NAMESERVER}
EOF
does the same thing as the old:
sed -i "s/#DNS=.*/DNS=$NAMESERVER/g" "${SDCARD}"/etc/systemd/resolved.conf
just in a config snippet instead of the main resolved.conf file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed. So the behavior is the same -- what changed is that MINIMAL images actually started using systemd-networkd and systemd-resolved (and so did my cloud-images, which is how I found it). Thanks for the investigation.
Description
This will allow dynamic selection and we could make even leaner NetworkManager-free minimal images. Which will be defaulted to systemd networking.
Jira reference number AR-2373
How Has This Been Tested?
Documentation changes
https://github.com/igorpecovnik/documentation/blob/master/docs/User-Guide_Networking.md
Checklist: