Bug 50101 - First ucs@school computer will always create a network
First ucs@school computer will always create a network
Status: NEW
Product: UCS@school
Classification: Unclassified
Component: UMC
UCS@school 4.4
Other Linux
: P5 normal (vote)
: UCS@school 4.4 v6
Assigned To: UCS@school maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-09-03 11:08 CEST by Christian Völker
Modified: 2020-06-23 15:17 CEST (History)
3 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 2: Improvement: Would be a product improvement
Who will be affected by this bug?: 1: Will affect a very few installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.023
Enterprise Customer affected?: Yes
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2020032021000399, 2020050621000242
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Völker univentionstaff 2019-09-03 11:08:50 CEST
Having created a network including a reverse-DNS zone and all stuff.

Creating the first computer in a @school environment:
Selecting "Rechner (Schulen)" it pops up with "Es wurden keine Rechner gefunden. Möchten Sie jetzt den ersten Rechner anlegen?".

Confirming with "Erstellen". 

Creating a new computer now with an IP from the above created network results in an error:
"Subnetzmaske: Das neu zu erstellende Netzwerk würde mit dem bereits existierenden Netzwerk VLAN10 überlappen."

Well, the idea was to put this client into this network...

Expected behaviour:
Accept the new client's IP and assign it (somehow) to the existing networks.
Comment 1 Sönke Schwardt-Krummrich univentionstaff 2019-09-03 11:16:20 CEST
(In reply to Christian Völker from comment #0)
> Having created a network including a reverse-DNS zone and all stuff.

What did you created where?
 
> Creating the first computer in a @school environment:
> Selecting "Rechner (Schulen)" it pops up with "Es wurden keine Rechner
> gefunden. Möchten Sie jetzt den ersten Rechner anlegen?".
> 
> Confirming with "Erstellen". 
> 
> Creating a new computer now with an IP from the above created network
> results in an error:
> "Subnetzmaske: Das neu zu erstellende Netzwerk würde mit dem bereits
> existierenden Netzwerk VLAN10 überlappen."

It looks like you created the subnet at the wrong position, so the code tried to create a new subnet for this school and (that's new!) detected a conflict.
 
> Well, the idea was to put this client into this network...

This only works if the subnet is created at the correct position with correct settings. I have to admit, that this is not explicitly documented, because at that time the intension was that subnets are always created implicitly via the wizards.

> Expected behaviour:
> Accept the new client's IP and assign it (somehow) to the existing networks.

Should work, if the subnet is correctly set up. Please give more details so we can reproduce the issue.
Comment 2 Christian Völker univentionstaff 2019-09-03 12:46:30 CEST
Ok, went on the Master UMC, selected "Domain" (blue) --> "Networks"

"Add" and then selected the place within the target school (ie ucs.schulen:/SchuleLena/networks)

Then given a name, entered IP network (192.168.10.0) and netmask (24)
Is does not seem to matter if I give a first and last IP address.
DNS-Settings: Selected Forward Zone (schulen.ucs)
Left the reverse zone empty (again, does not matter)
Selected in DHCP the service from school. 

Saved.

Nothing more to configure...
Comment 3 Sönke Schwardt-Krummrich univentionstaff 2019-09-04 10:37:42 CEST
First of all: I remembered it wrong and assumed that the subnet conflict was NOT detected by checking the network objects.
I don't think this is the best solution because network objects are basically just templates for the interactive creation of new computer objects in the UDM modules computers/* of the UMC.
This means that the network objects are not used functionally by UCS@school/the connected services (except for the subnet conflict detection mentioned here).

Back to Christian's problem:
the network object he created was created at the correct position in LDAP, but with the name "VLAN10" and not according to the scheme "$OU-$SUBNET" expected by UCS@school (e.g. "gymmitte-10.200.18.0").
The code for conflict detection of subnets assumes that the network objects below the OUs all correspond to the UCS@school naming scheme. Since there was only one "VLAN10" network object in his environment and no "SchuleLena-192.168.10.0" network object, the UCS@school library tried to create the supposedly missing network object and then performed a conflict check against the network objects of *ALL* OUs.
Of course, the new network object "SchuleLena-192.168.10.0" collides with the "VLAN10" and the described error message is displayed.

The contents of the LDAP objects "SchuleLena-192.168.10.0" and "VLAN10" were identical. I.e. the wish would be that the library recognizes this and reuses an existing network object IN THE SAME OU/SCHOOL before trying to create its own network object.

For classification:
Network objects are created automatically when the UCS@school computer wizard is used. Network settings can also be made via the CLI import ./import_networks, which also uses the "correct" network object names. This means that the problem only occurs if network objects with "wrong" names are manually created for a school and the UCS@school computer wizard is then to be used in the UMC.
Comment 4 Dirk Schnick univentionstaff 2020-03-23 16:42:06 CET
Now a customer has reported the problem.
Customer manually create a network whose name is "speaking". When they join a Windows client, an identically configured network is created. They have 2 identical networks with different names, which makes it difficult to keep track.