[CLOSED] Missing interfaces on gui

Hi forum!

2 years using OMV and first post!
...here we go:

I got an old install box, upgraded from 0.5 to 2.0 up and running in production.
Being Debian experienced, and coming from 0.5, all network setup has always being done via cli /etc/network/interfaces... that included a LACP bondwith a CISCO switch.
Recently that box was put into less stressing load and put in a simple, single nic, setup... although it retains 3 its Gb NICs.

So I though: "what does the gui offers to play with with 3 NICs?" .... being the answer: nothing.
Out of the 3 NICs (1 layer1 down, 2 layer2 up, of which only one is layer3 set up and running) only 1 interface appears on the GUI: the one up without layer3 setup...
By looking around other boxes, I realice That GUI seems to apear disabled/locked to setup some interfaces, or when opening it up (for instance, opening form for a bond interface) it shows empty.
So I suspect and feel I'm doing things WRONG, relying too much on the classical cli, and creating a gap between OMV "database" setup and currently running setup.

I do not find anywhere on the forum a clue on what can be happening... (most entries are about non-working scenarios, whereas here it all works)
What am I missing? Is OMV using something similar to early Debian/Ubuntu cli conflictive network-Manager? Why seem interfaces at GUI to be uneditable/locked?

I would like to do things as OMV developers seem to have designed: using full GUI, being able to manage and control networking from it in order to have "good practices" OMV usage.

Thank you for your patiece....
and best regards!

AHA! Thank you very much....

Probably I'm too contaminated by classical cli Debianism... but some doubts spawn now:

If GUI management ensures GUI management enabled... and without network up and runing GUI can be reach.... What happens if something goes wrong?
On a classical scenario, at the very end you could physically atach an RS232 cable or even a keyboard/monitor and regain control, hypervisors allways offer a KVM on VMs for the same reason... but here, how do you recover from a network setup error? then you loss GUI and recovering at cli means you loss control from GUI forever?

...I don't think so... OMV seems to be very good planed, there should be a way to break the loop, and address things.

Best regards!

Aha... a cli script...
Thank you very much... I feel unsure about this, disaster awaits... I think I will stick to classical /etc/network/interfaces as long as I can .

Aha... got it. As I expected there is no room for errors here with the interfaces/GUI pair since they depend on each other.

I agree that the only way to setup this is with a VM mockup... but this may be complex in setting up 803.ad LACP bonds with a physical CISCO switch.
By doing it the classical way I feel more confident on complex setups.

I would like to have an option to disable the whole interfaces entry on the GUI and let OMV be directly controled by classical cli means, the same way Debian/Ubuntu ended up leting network-manager be disabled for non-desktop users.... But damn! the GUI interfaces manager looks very cool!!!!

Thank you very much and best regards!

...interesting... that way sounds as a promising alternative for complex settings.

It would be but great if a comprhensive documentation on the internal working and structure of that folders would exist.
As I expected, unless config data is stored in a kind of SQL, being Debian, there should be a way to understand the internals of OMV networking config data model and file structure.

Anyhow, it would be great if the GUI would have separated status and managment.
A status tab/dashboard with IP addresing, interface listing, MACs, UP/DOWN status, etc without any control that opens a blocked/nonfunctional form.
A Management tab/dashboard that coud be toggled to a an "advanced" setup mode with just a /etc/network/interfaces file editor.

Everything would be different if OMV had the abillity to parse human modified /etc/network/interfaces file and import/translate currently fully operational setup into propper OMV setup... but that sounds too complex.