OpenSLX

Replying to mj0:

Für größere Gruppen ist es recht mühsam einzelne clients anzulegen. Hier wäre eine IP-Range wie
sie auch von PXE unterstützt wird wünschenswert. ip_range=0A0812 würde für alle IPs welche mit
10.8.18 anfangen Attribute definieren. Im Grunde ist die gleiche Funktionalität wie bei
add-client gewollt nur statt die MAC wird eben die IP-Range definiert. Wäre interessant für
Szenarien mit anderen VMware-Images, wie wir es in der AC verwenden. So könnte man auch
spezielle Pool-Konfigs realisieren. Siehe auch #264

Ja, das Problem dabei ist aber, dass unsere Clients sich nicht per IP sondern über ihre MAC an den Server wenden, um Ihre Konfiguration zu holen.
Mir ist klar, dass es wünschenswert wäre, IP-Ranges zu unterstützen, aber dazu müsste man unsere DB irgendwie mit dem/n DHCP-Server(n) verheiraten.
Spontan fällt mir erstmal keine Lösung ein.

Ich würde das deshalb von den Clients abkoppeln. Es gibt eine neue Option add-iprange und die ist so aufgebaut wie add-client. Das sieht dann folgendermaßen aus:

linux:~# slxconfig add-iprange anorg-chemie range=0A0812
List of bla:
range anorg-chemie:
    comment       = Ip-Adressen der Anorg. Chemie
    id            = 1
    kernel_params = 
    range         = 0A0812
    systems       = 
    unbootable    = 
  ATTRIBUTES:
    vmchooser::env=ac

MAC->Range->Vendor->Default

PXE macht das ähnlich:

MAC->Range->Default

Replying to [comment:3 mj0]:

Ich würde das deshalb von den Clients abkoppeln. Es gibt eine neue Option add-iprange und die
ist so aufgebaut wie add-client. Das sieht dann folgendermaßen aus:

> linux:~# slxconfig add-iprange anorg-chemie range=0A0812
> List of bla:
> range anorg-chemie:
>     comment       = Ip-Adressen der Anorg. Chemie
>     id            = 1
>     kernel_params = 
>     range         = 0A0812
>     systems       = 
>     unbootable    = 
>   ATTRIBUTES:
>     vmchooser::env=ac

Ah, Du meinst ein neues DB-Objekt. Eigentlich gibt es sowas ja schon, nämlich Gruppen, nur dass diese bislang keine eigene Config bekommen, sondern nur ihre Werte zur Config der entsprechenden Clients beisteuern.

Wie wäre es, wenn wir die Tabelle 'groups' um das DB-Feld 'ip_ranges' erweitern, welches ein oder mehrere Netzwerke enthält, in denen die bei dieser Gruppe gesetzten Attribute gelten sollen? Das hätte den gleichen Effekt und wäre weniger Aufwand und - glaube ich - leichter zu verstehen.

Die Konfig landet dann wie bei Clients unterhalb von $config/ubuntu-8.04-bla/anorg-chemie.

Hm, woher soll denn der Client beim Booten den Namen anorg-chemie kennen?
Die Config müsste doch eher in einer Datei namens 10.8.18 bzw. 0A0812 abgelegt werden, oder? Da ihr die ganzen Clients eben nicht anlegen möchtet, muss jeder bootende Client doch im Prinzip aus seiner IP-Adresse und der Netzmaske den Namen dieser Datei bilden können, um diese herunterzuladen, oder übersehe ich da was?

Ich persönlich fände es übrigens schöner, statt der Hex-Notierung die dezimale Bezifferung zu verwenden (also z.B. '10.8.18' statt '0A0812'), weil dieses Format gebräuchlicher ist (zumindest ich selbst kenne die Hex-Codes meiner eigenen Netzwerke nicht auswendig, die dezimalen Varianten natürlich schon).

Hier könnte man noch sehen, ob man Unterordner $config/{clients|ipranges} verwendet.

Ja, das fände ich ganz gut.

Konfiguration wird dann folgendermaßen gezogen:

MAC->Range->Vendor->Default

PXE macht das ähnlich:

MAC->Range->Default

Ja, das wäre dann ja nur ein versuchter TFTP-Zugriff mehr, das klingt doch nach einem guten Kosten-Nutzen-Verhältnis ;-)

Replying to [comment:4 zooey]:

Die Config müsste doch eher in einer Datei namens 10.8.18 bzw. 0A0812 abgelegt werden, oder?
Da ihr die ganzen Clients eben nicht anlegen möchtet, muss jeder bootende Client doch im
Prinzip aus seiner IP-Adresse und der Netzmaske den Namen dieser Datei bilden können, um diese
herunterzuladen, oder übersehe ich da was?

Diese Berechnung könnte man recht einfach so realisieren, dass erst mittel 'ip address' die IP-Adresse + Netzmaske ermittelt wird und anschließend per 'ipcalc -n <addresse>/<bits>' die Netzwerkadresse ermittelt wird.

Allerdings klappt das alles natürlich nur dann, wenn die IP-Range auch tatsächlich mit einem Netzwerk korrespondiert. Falls dem nicht so ist, könnte man versuchen, die Netzwerk per TFTP bitweise abzuklappern (also zuerst 10.8.18.0, dann 10.8.16.0, dann 10.8.0.0, ...
Letzteres kostet natürlich ein wenig Zeit und ist auch darauf angewiesen, dass die IP-Ranges entsprechend der 2-er Potenzen gruppiert sind.

Replying to [comment:5 zooey]:

Allerdings klappt das alles natürlich nur dann, wenn die IP-Range auch tatsächlich mit einem
Netzwerk korrespondiert. Falls dem nicht so ist, könnte man versuchen, die Netzwerk per TFTP
bitweise abzuklappern (also zuerst 10.8.18.0, dann 10.8.16.0, dann 10.8.0.0, ...

Äh, naja oder so ähnlich: Man müsste wohl von der IP-Adresse des Clients ausgehend von rechts her Bits löschen, um so nach und nach zu versuchen, die "passendste" IP-Range Config zu holen.

Replying to [comment:4 zooey]:

Replying to [comment:3 mj0]:

Ich würde das deshalb von den Clients abkoppeln. Es gibt eine neue Option add-iprange und die
ist so aufgebaut wie add-client. Das sieht dann folgendermaßen aus:

> > linux:~# slxconfig add-iprange anorg-chemie range=0A0812
> > List of bla:
> > range anorg-chemie:
> >     comment       = Ip-Adressen der Anorg. Chemie
> >     id            = 1
> >     kernel_params = 
> >     range         = 0A0812
> >     systems       = 
> >     unbootable    = 
> >   ATTRIBUTES:
> >     vmchooser::env=ac

Ah, Du meinst ein neues DB-Objekt. Eigentlich gibt es sowas ja schon, nämlich Gruppen, nur dass diese bislang keine eigene Config bekommen, sondern nur ihre Werte zur Config der entsprechenden Clients beisteuern.

Wie wäre es, wenn wir die Tabelle 'groups' um das DB-Feld 'ip_ranges' erweitern, welches ein oder mehrere Netzwerke enthält, in denen die bei dieser Gruppe gesetzten Attribute gelten sollen? Das hätte den gleichen Effekt und wäre weniger Aufwand und - glaube ich - leichter zu verstehen.

Ja das war der erste Gedanke. Aber dann habe ich gesehen, dass group anders funktioniert und auch keine Konfiguration schreibt. Group ist ja zur Client-Gruppierung gedacht. Deshalb dachte ich, um im Schema zu bleiben, ein add-iprange einzuführen. Dachte wäre auch einfacher zu realisieren, da man nur die Namen durchtauschen müsste (Range ersetzt MAC).

Die Konfig landet dann wie bei Clients unterhalb von $config/ubuntu-8.04-bla/anorg-chemie.

Hm, woher soll denn der Client beim Booten den Namen anorg-chemie kennen?
Die Config müsste doch eher in einer Datei namens 10.8.18 bzw. 0A0812 abgelegt werden, oder? Da ihr die ganzen Clients eben nicht anlegen möchtet, muss jeder bootende Client doch im Prinzip aus seiner IP-Adresse und der Netzmaske den Namen dieser Datei bilden können, um diese herunterzuladen, oder übersehe ich da was?

Ja das stimmt. Wie du auch weiter unten erklärst ist das gar nicht so einfach. Man könnte es vielleicht irgendwie über die PXE-Parameter übergeben. Ich weiß nur nicht wie und ob das so schön ist.

Ich persönlich fände es übrigens schöner, statt der Hex-Notierung die dezimale Bezifferung zu verwenden (also z.B. '10.8.18' statt '0A0812'), weil dieses Format gebräuchlicher ist (zumindest ich selbst kenne die Hex-Codes meiner eigenen Netzwerke nicht auswendig, die dezimalen Varianten natürlich schon).

Ja war nur der Einfachheit halber. Da PXELinux ja nach der IP-Adresse als HEX sucht, und bei jedem Schritt eine Position nach links geht. Mit "echten" IP-Adressen hat man entweder nicht die Vielfalt, wenn man nur die jeweiligen Netze nimmt (ABC). Oder man hat das Problem, die IP-Adressen in das Hex-Format umzuwandeln. Ich dachte wenn man das Client-Zeug kopiert die Namen durchtauscht, würde schon alles laufen. Wollte jetzt nicht noch komplizierte Umwandlungen machen.

Hier könnte man noch sehen, ob man Unterordner $config/{clients|ipranges} verwendet.

Ja, das fände ich ganz gut.

Konfiguration wird dann folgendermaßen gezogen:

MAC->Range->Vendor->Default

PXE macht das ähnlich:

MAC->Range->Default

Ja, das wäre dann ja nur ein versuchter TFTP-Zugriff mehr, das klingt doch nach einem guten Kosten-Nutzen-Verhältnis ;-)

Replying to [comment:6 zooey]:

Replying to [comment:5 zooey]:

Allerdings klappt das alles natürlich nur dann, wenn die IP-Range auch tatsächlich mit einem
Netzwerk korrespondiert. Falls dem nicht so ist, könnte man versuchen, die Netzwerk per TFTP
bitweise abzuklappern (also zuerst 10.8.18.0, dann 10.8.16.0, dann 10.8.0.0, ...

Äh, naja oder so ähnlich: Man müsste wohl von der IP-Adresse des Clients ausgehend von rechts her Bits löschen, um so nach und nach zu versuchen, die "passendste" IP-Range Config zu holen.

Hmm. Das ist nicht so schön, nehmen wir an wir haben eine IP-Adresse 10.12.34.56, die Range ist 10.x.x.x. D.h, die Konfiguration, die PXELinux haben will ist 0a.tgz. PXELinux geht dann folgendermaßen durch:

01-$MAC_ADDR

0a0c2238

0a0c223

0a0c22

0a0c2

0a0c

0a0

0a

Diese Reihenfolge (also 8 extra Abfragen) müsste dann auch der TFTP in Stage 3 durchgehen. Bei Default sind es noch 3 Abfragen mehr. Wäre die Frage, ob man das über PXELinux herausfinden kann, oder wir übergeben die Info über PXE-Append, oder sonstwie.

Vielleicht fällt noch jmd. was gutes ein.

Replying to [comment:7 mj0]:

Hmm. Das ist nicht so schön, nehmen wir an wir haben eine IP-Adresse 10.12.34.56, die Range
ist 10.x.x.x. D.h, die Konfiguration, die PXELinux haben will ist 0a.tgz. PXELinux geht dann
folgendermaßen durch:

01-$MAC_ADDR

0a0c2238

0a0c223

0a0c22

0a0c2

0a0c

0a0

0a

Ist doch im Prinzip das gleiche wie bei den dezimalen IP-Adressen, nur dass hier eben immer gleich 4 Bits entfernt werden. Hier kann man natürlich beliebig zwischen Effizienz und Flexibilität abwägen (und mal mehr mal weniger Bits pro Versuch entfernen).

Diese Reihenfolge (also 8 extra Abfragen) müsste dann auch der TFTP in Stage 3 durchgehen.
Bei Default sind es noch 3 Abfragen mehr. Wäre die Frage, ob man das über PXELinux
herausfinden kann, oder wir übergeben die Info über PXE-Append, oder sonstwie.
Vielleicht fällt noch jmd. was gutes ein.

Man könnte die Notwendigkeit nutzen, dass diese Clients ja ohnehin im DHCP-Server explizit konfiguriert werden müssen (um ihnen IP-Adressen aus dem jeweiligen Range zu geben). Es gäbe nämlich auch die Möglichkeit, sich eine bestimme DHCP-Option auszusuchen und die für die Group-ID zu missbrauchen. Das heisst, wir würden einfach die Netzadresse direkt in dieser Option an den Client liefern (udhcpc -O ... klappt ja jetzt). Dann wäre die Zuordnung von Clients zu Gruppen/Ranges nur an einer einzigen Stelle vorhanden, nämlich im DHCP-Server.

Replying to [comment:8 zooey]:

Replying to [comment:7 mj0]:

Hmm. Das ist nicht so schön, nehmen wir an wir haben eine IP-Adresse 10.12.34.56, die Range
ist 10.x.x.x. D.h, die Konfiguration, die PXELinux haben will ist 0a.tgz. PXELinux geht dann
folgendermaßen durch:

01-$MAC_ADDR

0a0c2238

0a0c223

0a0c22

0a0c2

0a0c

0a0

0a

Ist doch im Prinzip das gleiche wie bei den dezimalen IP-Adressen, nur dass hier eben immer gleich 4 Bits entfernt werden. Hier kann man natürlich beliebig zwischen Effizienz und Flexibilität abwägen (und mal mehr mal weniger Bits pro Versuch entfernen).

Das habe ich eigentlich nur so gewählt, da PXELinux das genauso macht. Habe mit Dirk gestern darüber diskutiert. Vielleicht wäre es doch ganz gut so etwas zu haben (finde ich zumindest). Ob es nun add-iprange oder in die Gruppe integriert wird muss man noch sehen. Was gebracht wird ist etwas was aus einer IP-Range eine PXELinux-Konfiguration anlegt in Hex-Schreibweise a0c22 und dazu gehörig eine a0c22.tgz. PXELinux übernimmt für uns die Arbeit mit der PXE-Konfiguration, da es selbst nach MAC->IP-Ranges->Default sucht. In stage 3 müssten wir das machen. Dirk meinte das sei kein Problem und würde auch nicht wirklich Zeit in Anspruch nehmen. Wir bräuchten da die gleiche Kaskade:

tftp get:

01-$MAC_ADDR.tgz

0a0c2238.tgz

0a0c223.tgz

0a0c22.tgz

0a0c2.tgz

0a0c.tgz

0a0.tgz

0a.tgz

0.tgz

default.tgz

Ich würde da gerne die gleiche Benennung nehmen, damit dies zu den PXELinux-Konfigurationen passt. Können natürlich auch was einfacheres nehmen wie 192.168.x.x, und nur die jeweiligen Netze absuchen A,B,C: 192.168.1.1->192.168.1.x->192.168.x.x ... oder sonstwas, man muss es ja nur irgendwie auf die PXELinux-konforme Hex-Version bringen. Dann wäre natürlich noch die Benennung der Konf-Ordner: 0a0c22, pool-keller, 192.168+netmask ...

Diese Reihenfolge (also 8 extra Abfragen) müsste dann auch der TFTP in Stage 3 durchgehen.
Bei Default sind es noch 3 Abfragen mehr. Wäre die Frage, ob man das über PXELinux
herausfinden kann, oder wir übergeben die Info über PXE-Append, oder sonstwie.
Vielleicht fällt noch jmd. was gutes ein.

Man könnte die Notwendigkeit nutzen, dass diese Clients ja ohnehin im DHCP-Server explizit konfiguriert werden müssen (um ihnen IP-Adressen aus dem jeweiligen Range zu geben). Es gäbe nämlich auch die Möglichkeit, sich eine bestimme DHCP-Option auszusuchen und die für die Group-ID zu missbrauchen. Das heisst, wir würden einfach die Netzadresse direkt in dieser Option an den Client liefern (udhcpc -O ... klappt ja jetzt). Dann wäre die Zuordnung von Clients zu Gruppen/Ranges nur an einer einzigen Stelle vorhanden, nämlich im DHCP-Server.

Dachte wir wollten eigentlich gar keine Konfiguration mehr über Dhcp übergeben.

Replying to [comment:9 mj0]:

Das habe ich eigentlich nur so gewählt, da PXELinux das genauso macht. Habe mit Dirk gestern darüber diskutiert. Vielleicht wäre es doch ganz gut so etwas zu haben (finde ich zumindest). Ob es nun add-iprange oder in die Gruppe integriert wird muss man noch sehen. Was gebracht wird ist etwas was aus einer IP-Range eine PXELinux-Konfiguration anlegt in Hex-Schreibweise a0c22 und dazu gehörig eine a0c22.tgz. PXELinux übernimmt für uns die Arbeit mit der PXE-Konfiguration, da es selbst nach MAC->IP-Ranges->Default sucht. In stage 3 müssten wir das machen. Dirk meinte das sei kein Problem und würde auch nicht wirklich Zeit in Anspruch nehmen. Wir bräuchten da die gleiche Kaskade:

tftp get:

01-$MAC_ADDR.tgz

0a0c2238.tgz

0a0c223.tgz

0a0c22.tgz

0a0c2.tgz

0a0c.tgz

0a0.tgz

0a.tgz

0.tgz

default.tgz

Ich würde da gerne die gleiche Benennung nehmen, damit dies zu den PXELinux-Konfigurationen passt.

Ja, da der Benutzer mit diesen Namen eh nichts direkt zu tun hat, bietet es sich an, die gleiche Notation wie PXE selbst zu verwenden.

Können natürlich auch was einfacheres nehmen wie 192.168.x.x, und nur die jeweiligen Netze absuchen A,B,C: 192.168.1.1->192.168.1.x->192.168.x.x ... oder sonstwas, man muss es ja nur irgendwie auf die PXELinux-konforme Hex-Version bringen.

Wie gesagt, die Benutzer haben damit ja nichts zu tun, dann lieber gleich das PXE-Namensformat.

Dann wäre natürlich noch die Benennung der Konf-Ordner: 0a0c22, pool-keller, 192.168+netmask ...

Wenn man die IP-Range-Zuordnung über Gruppen löst, könnte man einfach den Namen der entsprechenden Gruppe angeben ('pool-keller'), das fände ich am besten.

Man könnte die Notwendigkeit nutzen, dass diese Clients ja ohnehin im DHCP-Server explizit konfiguriert werden müssen (um ihnen IP-Adressen aus dem jeweiligen Range zu geben). Es gäbe nämlich auch die Möglichkeit, sich eine bestimme DHCP-Option auszusuchen und die für die Group-ID zu missbrauchen. Das heisst, wir würden einfach die Netzadresse direkt in dieser Option an den Client liefern (udhcpc -O ... klappt ja jetzt). Dann wäre die Zuordnung von Clients zu Gruppen/Ranges nur an einer einzigen Stelle vorhanden, nämlich im DHCP-Server.

Dachte wir wollten eigentlich gar keine Konfiguration mehr über Dhcp übergeben.

Naja, es steht und fällt ja alles mit dem Konzept der IP-Ranges. Wie sicher seid ihr denn, dass alle Clients eines Pools sich per IP-Range von den Clients eines anderen Pools abgrenzen lassen (und dies vor allem entlang der 4-Bit-Grenzen, die von PXE gesetzt werden)? Solange die Netze sauber voneinander getrennt sind, ist das kein Problem, aber falls nicht, könnte man die Gruppenzuordnung einzelner Clients eben über den DHCP-Server abwickeln. Letzten Endes ist die Verwaltung von IP-Adressen dessen Job, und nicht der von OpenSLX.

Replying to [comment:10 zooey]:

Replying to [comment:9 mj0]:

[...]

Man könnte die Notwendigkeit nutzen, dass diese Clients ja ohnehin im DHCP-Server explizit konfiguriert werden müssen (um ihnen IP-Adressen aus dem jeweiligen Range zu geben). Es gäbe nämlich auch die Möglichkeit, sich eine bestimme DHCP-Option auszusuchen und die für die Group-ID zu missbrauchen. Das heisst, wir würden einfach die Netzadresse direkt in dieser Option an den Client liefern (udhcpc -O ... klappt ja jetzt). Dann wäre die Zuordnung von Clients zu Gruppen/Ranges nur an einer einzigen Stelle vorhanden, nämlich im DHCP-Server.

Dachte wir wollten eigentlich gar keine Konfiguration mehr über Dhcp übergeben.

Naja, es steht und fällt ja alles mit dem Konzept der IP-Ranges. Wie sicher seid ihr denn, dass alle Clients eines Pools sich per IP-Range von den Clients eines anderen Pools abgrenzen lassen (und dies vor allem entlang der 4-Bit-Grenzen, die von PXE gesetzt werden)? Solange die Netze sauber voneinander getrennt sind, ist das kein Problem, aber falls nicht, könnte man die Gruppenzuordnung einzelner Clients eben über den DHCP-Server abwickeln. Letzten Endes ist die Verwaltung von IP-Adressen dessen Job, und nicht der von OpenSLX.

Ja das war auch Dirks Einwand, doppelte Konfiguration und eigentlich Dhcp-Aufgabe.

Wir haben hier eben ein spezielles Szenario, ich weiß jetzt auch nicht, ob das irgendwo noch so Auftreten wird. Wenn man das schöner Lösen kann, sind IP-Ranges gestorben. Ich beschreibe es mal:

Also im RZ gibt es einen externen Abnehmer, der unser Default-System nimmt. Also unser generiertes InitramFS + Kernel + NFS-Export. Was sich jedoch unterscheidet ist die PXE-Konfiguration (Andere-Menüeinträge + Optionen) und das Konf-Paket (.tgz). Externe Möglichkeiten gibt es, bzw. soll es evtl. bald geben (externe Rechner-DB mit IP, MAC, PXE-Menü, ...), aber SLX-intern ist das schwerer. Man kann natürlich für diese vielleicht 20 Rechner eigene Client-Einträge erstellen (wie sieht es bei 100 aus), wenn jedoch ein Rechner ausgetauscht wird, muss wieder der Demuxer laufen, etc... was ich gerne im Produktiv-System vermeiden würde. Die Trennung ist zugegebenermaßen nicht ganz so einfach. Hoffen wir, dass die Netze gut trennbar, sind, oder man muss bis zu 15 Einzelkonfigurationen an beiden Enden in Kauf nehmen.

Dirk hatte grad eine Gute Idee. Man könnte die Client-Konfiguration als erweiterten Client auffassen. Statt Mac könnte man die Range angeben 0123, das einzige was dann noch geändert werden müsste ist die Abfrage nach Ranges im Stage 3.

Replying to [comment:12 mj0]:

Dirk hatte grad eine Gute Idee. Man könnte die Client-Konfiguration als erweiterten Client auffassen. Statt Mac könnte man die Range angeben 0123, das einzige was dann noch geändert werden müsste ist die Abfrage nach Ranges im Stage 3.

Hm, bin nicht so begeistert, denn das würde das OpenSLX mit System, Gruppen und Clients ein wenig vergewaltigen. Gruppen sind exakt für den gewünschten Zweck gedacht, nur dass die Implementierung noch nicht komplett ist. Wenn man einen speziellen Client dafür hernimmt, dann besteht z. B. das Problem, dass andere Clients, die in diesem IP-Pool sind, zwar noch eigene Attribute setzen können, aber dann nicht mehr von der Gruppe erben (weil OpenSLX ja von der Zuordnung der Clients untereinander nichts weiß).

Oder spricht irgendein Argument gegen die Lösung mittels Gruppen, abgesehen davon, dass sie noch nicht fertig ist?

Replying to [comment:13 zooey]:

Replying to [comment:12 mj0]:

Dirk hatte grad eine Gute Idee. Man könnte die Client-Konfiguration als erweiterten Client auffassen. Statt Mac könnte man die Range angeben 0123, das einzige was dann noch geändert werden müsste ist die Abfrage nach Ranges im Stage 3.

Hm, bin nicht so begeistert, denn das würde das OpenSLX mit System, Gruppen und Clients ein wenig vergewaltigen. Gruppen sind exakt für den gewünschten Zweck gedacht, nur dass die Implementierung noch nicht komplett ist. Wenn man einen speziellen Client dafür hernimmt, dann besteht z. B. das Problem, dass andere Clients, die in diesem IP-Pool sind, zwar noch eigene Attribute setzen können, aber dann nicht mehr von der Gruppe erben (weil OpenSLX ja von der Zuordnung der Clients untereinander nichts weiß).

Ja da hatte ich nicht daran gedacht. Für mich war das eher eine komplementäre Lösung: Vererbung: Range->System, MAC->System nicht MAC->Range->System. Hatte aber auch nicht Bedacht, dass man in einer Range trotzdem eine MAC-basierte Konfiguration haben kann / will.

Oder spricht irgendein Argument gegen die Lösung mittels Gruppen, abgesehen davon, dass sie noch nicht fertig ist?

Ich wart mal was Dirk so dazu sagt ;). Wenn man aber auf die Verkettung MAC->Range->System aus ist, wird wohl kein Weg daran vorbei führen.

Was man jedoch noch hinzufügen kann ist, dass Client-Konfigurationen ohnehin nicht von einer anderen Client-Konfiguration erben, was es ja dann wieder klarer macht. Ich erwarte ja nicht, dass wenn ich 2x Client-Konfigurationen habe: rechner-keller pool-keller, dass rechner-keller die Eigenschaften von pool-keller hat, auch wenn er in der Range 10.1.1.x ist.

Jungs, das schreit nach einer Mini-Telco. Mal Skype installieren und los gehts nach Absprache :)
Nur noch eine Anmerkung: Die IP-Range-Nummer würde ich versuchen aus dem OpenSLX rauszulassen, da es eben das nicht verwaltet. Und die Idee war einfach "Gruppen" als Spezialclients anhand dieser 16er PXE-Nummer zu definieren, damit man mit dem jetzigen etwas schnell lauffähiges hat, was eben nicht den Anspruch hat eine weitgehende Gruppenimplementierung zu sein.