Skip to content
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

correctly setup network interfaces #13

Closed
wants to merge 1 commit into from

Conversation

chiva
Copy link

@chiva chiva commented May 2, 2020

Add available network interfaces to OMV settings, so all interfaces are up after first reboot

Ethernet is added with "predictable naming" to keep connectivity after first reboot
If wpa_supplicant.conf is found:

  • Setup wifi country in crda file (without this, wifi can't be enabled)
  • SSID and password are taken and added to OMV

Solves openmediavault/openmediavault#688

Tested with Raspberry 3B and 3B+

Add available network interfaces to OMV settings, so all interfaces are up after first reboot

Ethernet is added with "predictable naming" to keep connectivity after first reboot
If wpa_supplicant.conf is found:
-  Setup wifi country in crda file (without this, wifi can't be enabled)
- SSID and password are taken and added to OMV
@ryecoaaron
Copy link
Member

I’m not sure I want this level of network setup in the install script because it will need to be maintained, isn’t the same across versions of OMV, and duplicates what omv-firstaid does.

@chiva
Copy link
Author

chiva commented May 2, 2020

Current one doesn't correctly configure any interface after first reboot, so it's that or recommend to use omv-firstaid in the install guide.

But also, the ethernet interface will change its name after reboot, so you can never configure it correctly from a headless perspective.

Just trying to lower the entry bar for the not so tech-savvy typical Raspberry's userbase

@ryecoaaron
Copy link
Member

Up until a week ago it seems like it was working. The switch to netplan seems to have broken it. It was only meant to configure eth0 on armbian and raspbian. I definitely don’t want to support wireless. I will try to find something simple but we may have to resort back to running omv-firstaid.

@ryecoaaron
Copy link
Member

I’m sorry you are mad that I don’t want to use this pull request. I thought my reasons were justified.

@ryecoaaron ryecoaaron closed this May 3, 2020
@emarashliev
Copy link

I really don't understand why this Pull Request was rejected but with it the OMV5 on Raspberry PI is practically unusable! Thank you @chiva you saved the day!

@ryecoaaron
Copy link
Member

ryecoaaron commented May 3, 2020

@emarashliev , did you read my reasons? I just installed a fresh raspbian 2020-02-13-raspbian-buster-lite on an RPi4 and other than the ip address changing, the network interfaces are not using predictable naming and it is working fine after multiple reboots. I am going to try on an RPi3 as well.

@ryecoaaron
Copy link
Member

The RPi3 does use predictive naming where the RPi4 does not. That is annoying. Testing armbian now. It really sucks to have a workaround just for the RPi2/3.

@ryecoaaron
Copy link
Member

I just pushed a fix that disables predictive network device naming. Since this is the behavior of armbian and raspbian images by default, I don't think this is bad. I have tested on RPi3/4, rock64, and odroid-n2 without issues.

@emarashliev
Copy link

Thanks, but I already used the @chiva version which worked fine for me. Also I don't understand why you don't want wireless support. Do you image how the people plug in the LAN cables on their MacBooks just to use OpenMediaVault 🤔. My point is that the most of the cases people gonna use wireless connectivity, so you have the bottleneck anyway.

@ryecoaaron
Copy link
Member

Why would the macbook or any other client need to be plugged into ethernet?

A headless NAS should be able to be put anywhere and plugged into a network by cable. A wireless NAS is terrible ideal and most commercial NASes have no wireless card. Plus, the script could never automatically pick the wireless network and password. So, why not run omv-firstaid instead if you choose to use wireless?

nicMac=$(cat /sys/class/net/$nic/address | tr -d ':')
UUID=$(cat /proc/sys/kernel/random/uuid)

xmlstarlet ed -L \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@votdev
Copy link
Member

votdev commented May 4, 2020

I think it will be a better way to get omv-firstaid working than adding such a monster script which must maintainer and is duplicate code of an already existing function.

@emarashliev
Copy link

emarashliev commented May 4, 2020

@ryecoaaron In my case I'm using the OMV as a Time Capsule replacement to make Time Machine backups for my MacBook, so I'm using wireless connectivity to reach the OMV. It doesn't matter if my RPI is connected over LAN or Wi-Fi. I understand you arguments, but one of main reasons why the people prefer open source product like OMV over the commercial ones is the ability to customize and modify it for its own needs. But anyway, it didn't work even with the LAN. I can't run omv-firstaid I don't have an external display neither keyboard, my RPI is completely headless.

@votdev
Copy link
Member

votdev commented May 4, 2020

If an existing wireless setup should be imported into the OMV configuration during setup, then a script like https://github.com/openmediavault/openmediavault/blob/master/deb/openmediavault/usr/share/openmediavault/confdb/populate.d/40interfaces.sh is the correct way. See https://github.com/openmediavault/openmediavault/blob/master/deb/openmediavault/usr/share/openmediavault/confdb/populate.d/README.md, too. Contributions to the OMV core are welcome.

P.S.: Contributions to OMV core MUST be platform independent. That code MUST be work on every supported platform. If it's only related to RPi, then OMV core is the wrong place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants