-
Notifications
You must be signed in to change notification settings - Fork 8
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
RFE: better management of dynamic network interfaces #8
Comments
I'm not sure this is a practical problem for most people using network labeling today, but that doesn't mean we can't try to solve it anyway ;) It sounds like the udev based approach would be the easiest, would you care to work on that @topimiettinen? |
Sure. I have this problem even with fixed devices: I think the udev rule should look like something like this:
In case of In case of Instead of new command If the udev rules are called for all interfaces including If 100% compatibility with previous setups is needed, new dynamic actions could be opted in with a new global rule in |
Added PR #9. |
It's possible that at the time when
netlabel-config
is started at boot, some network interfaces aren't yet available. The reason for that could be that the corresponding kernel module isn't (fully) loaded yet, or the hardware is simply inserted later (like USB network adapters or putting a laptop in a docking station). Withnetlabelctl
however it's not possible to manage interfaces which are not (yet) present.I suppose this could be fixed by changing
netlabelctl
and kernel so that rules could be stored also for nonexistent interfaces. But a more dynamic way could be to utilizeudevd
so that when new network hardware is found,netlabelctl
would be launched (for example via something likenetlabelctl@.service
) to configure the new interface. This would not require changes to kernel.The text was updated successfully, but these errors were encountered: