Moin,
seit 22.7.6 gibts folgende Änderung laut Changelog:
interfaces: allow user-configurable VLAN device names with certain restrictions
Hier das Issue in github: https://github.com/opnsense/core/issues/6038
Im Hilfetext steht:
Leave empty to generate a device name. Custom names are possible, but only if the start of the name matches the required prefix and contains numeric characters or dots, e.g. "vlan0.1.2" or "qinq0.3.4".
Ich entnehme daraus, dass ein VLAN-Device dann immer mit vlan beginnen muss, dahinter können Zahlen folgen. Gleiches analog für QinQ. Dahinter dürfen dann nur Zahlen und Punkte folgen.
Nun hab ich da ein bisschen rumprobiert. Einfach nur vlan mit beliebiger Systematik an Zahlen und Punkten hinten dran scheint nicht zu gehen und führt zu folgender Fehlermeldung:
Only a maximum of 15 characters is allowed starting with "vlan0" combined with numeric characters and dots, e.g. "vlan0.1.104".
Welcher Regel nach bzw. Syntax entsprechend sind die Zahlen und Punkte anzuordnen? Das ist irgendwie nicht so ganz einleuchtend.
Bezogen auf die Beispiele im Hilfetext und der Fehlermeldung:
Was bedeutet die führende 0? Ist das der Adaptertyp? (z.B. vmx)
Ist die Zweite Zahl die Interface-Nummer des entsprechenden Adaptertyps?
Die letzte Zahl ist das VLAN-Interface?
Welchen Spielraum lässt die Syntax?
Das exakte Pattern ist: "/^{$prefix}0([0-9\.]){1,10}$/". Soweit ich im Code sehe, trägt der Name keinerlei inhärente Bedeutung, anders als früher z.B. "igb0_vlan7".
Der Name für ein VLAN muss lediglich mit vlan0 beginnen und dann können 1-10 Zeichen aus der Menge 0123456789. folgen, es wäre also auch "vlan0...1" möglich oder "vlan0815", aber nicht "vlan666".
Die Idee war, mit Einführung von QinQ Kollisionen zu verhindern, indem einfach durchnumeriert wurde (vlan01, vlan02 usw.). Damit sieht man der Bezeichnung aber den Sinn nicht mehr an. Baut man z.B. für T-Online PPPoE ein VLAN 7, heißt es trotzdem vlan01, wenn es das erste ist.
Deswegen wurde die Möglichkeit, strukturierte Namen zu verwenden, wiederhergestellt.
Am Rande bemerkt kann man auch den Namen in einer gespeicherten Konfigurationsdatei später ersetzen und wieder einlesen - dann ist auch "igb0_vlan7" wieder möglich. Vorhandene Namen aus geladenen Konfigurationsdateien werden nämlich 1:1 übernommen.
QuoteDeswegen wurde die Möglichkeit, strukturierte Namen zu verwenden, wiederhergestellt.
Sehr gut, vielen Dank. Ja, das stumpfe durchnummerieren war wirklich keine gute Idee.
Wenn es sowieso keine Rolle spielt, wie das Interface heißt, wieso gibt man dann nicht gleich die Benennung ganz frei? Soll doch derjenige, der sich keine Gedanken drüber machen will ein vordefiniertes, automatisiertes Namensschema nutzen und der, der strukturiert bezeichnen will, soll seine Bezeichnung gleich selbst definieren. Dieses vlan0 prefix macht doch keinen Sinn...
Und ob das jetzt ein phy, vlan, qiniq, vxlan interface ist, kann man doch an anderer stelle definieren. Muss ja mit der Benennung nichts zu tun haben.
QinQ bietet ja die Möglichkeit, VLANs zu schachteln, das alte Schema hätte dann zu Namen wie igb0_vlan1_vlan2_vlan3_vlan4 führen können. Es gibt aber eine Längenbeschränkung, die das verbietet.
Ich fände es auch besser, die eigene Benennung im Rahmen der syntaktischen Freiheitsgrade zu erlauben, zudem das über Umwege ja sowieso möglich ist. Die Automatik kann ja tun, was sie will (oder man lässt sie weg).
> Ja, das stumpfe durchnummerieren war wirklich keine gute Idee.
Danke für die nicht hinreichende technische Analyse des vordergründigen Problems. ;)
Der Name ist letztlich egal, der Inhalt aber nicht: wir haben nur 15 Zeichen und wir müssen verhindern, dass dort auf einmal der Name eines anderen Interfaces auftaucht weil das einige Annahmen des Codes sprengt.
Und seien wir ehrlich, man würde doch gleich wieder "em0" in den VLAN Namen einfügen wollen wenn man könnte aus "Gründen".
Grüsse
Franco
Quote
> Ja, das stumpfe durchnummerieren war wirklich keine gute Idee.
Danke für die nicht hinreichende technische Analyse des vordergründigen Problems. ;)
Muss diese Art der Kommunikation sein? Warum nicht sachlich bleiben?
Quote
Der Name ist letztlich egal, der Inhalt aber nicht: wir haben nur 15 Zeichen und wir müssen verhindern, dass dort auf einmal der Name eines anderen Interfaces auftaucht weil das einige Annahmen des Codes sprengt.
Ich versteh nicht, wieso kritische Zeichenfolgen nicht einfach abgefangen werden.
Wenn die Strings nicht länger als 15 Zeichen lang sein sollen, dann lässt sich das abfangen.
Wenn gewisse Zeichenfolgen nicht genutzt werden dürfen, dann lässt sich das doch sicher ganauso abfangen.
Alles was mit diesen Bedingungen nicht kollidiert, sollte erlaubt sein.
Wenn dann noch die Bedingungen und kritischen Zeichenfolgen im Wiki, hier im Forum oder in der Weboberfläche kommuniziert werden, dann ist doch alles getan um die Nutzer abzuholen.
Quote
Und seien wir ehrlich, man würde doch gleich wieder "em0" in den VLAN Namen einfügen wollen wenn man könnte aus "Gründen".
Grüsse
Franco
Und wenn es genau das ist, was deine Nutzer wollen? Nicht weil es früher immer so gemacht wurde und man daran aus Gewohnheit festhalten will, sondern weil es einfach Sinn egeben hat und sich etabliert hat?
Ich kann an der Stelle nur nochmal drauf aufmerksam machen, welchen Impact solche Änderungen auf die vielen Tutorials, Dokus, Howtos im Internet hat, denn die stimmen nun alle nicht mehr.
Diskutiert haben wir das auch hier schon. Es kam nur keine Reaktion mehr....
https://forum.opnsense.org/index.php?topic=28114
> Ja, das stumpfe durchnummerieren war wirklich keine gute Idee.
Ganz sachlich also: technisch unmöglich sauber auszuführen auf 15 Zeichen pro Device, aber es reicht für eine pauschale Aussage, dass diese Alternative keine gute Idee ist? Eine Idee, die schon bei Bridges und LAGG und OpenVPN uvm. seit Jahrzehnten verwendet wird ist also keine gute Idee?
Auch ganz sachlich ohne Smiley, da die angespannte Situation hier wohl nicht aufgelockert werden kann.
Weshalb darf eigentlich der Name des Parent-Interface da nicht drin vorkommen?
Das Standard FreeBSD-RC-System baut Namen wie lagg0.12 für VLAN 12 auf lagg0 - das passt prima in 15 Zeichen und reicht für beliebig viele laggs und beliebig viele vlans darauf - im Rahmen vernünftiger Zahlen für "beliebig". Mehrere Tausend wären kein Problem. Und bei QinQ hängt man halt noch ein .X hinten dran. Passt auch noch.
Ich kann mit durchnumerierten vlanX problemlos leben - es ist doch alle Info im UI. Und auf der Shell sowieso. Daher versteh ich die Aufregung nur teilweise. Aber aus Neugier: was spricht gegen das Standard FreeBSD-Schema, das man bekommt, wenn man z.B.
vlans_lagg0="12 13 14"
in rc.conf setzt?
Gruß
Patrick
@franco:
Deinen ersten Satz könnte man schon als leicht unsachlich interpretieren. Deinen letzten Satz, indem du Gründen in Anführungszeichen packst ebenso. Aber es ist vielleicht nur ein Fall von "Text schluckt Seitenkanäle der Kommunikation" und ich habs völlig falsch aufgenommen. Darum ist für mich auch alles gut und es geht ganz sachlich weiter:
Kann es sein dass ich mich unklar ausgedrückt habe oder du was falsch verstanden hast? Ich hab mit dem Zitat was du nun schon 2x gebracht hast die Durchnummerierung nach dem Schema vlan01, vlan02, vlan03 usw. gemeint (seit 22.1.4) und nicht das aktuelle Schema, was mit 22.7.6 eingeführt wurde.
Ja, was dieses Schema ab 22.1.4 angeht, da bleib ich bei meiner Meinung, dass das keine gute Idee war.
Das Schema vor 22.1.4 war um Welten besser. Das jetzige was seit 22.7.6 eingeführt wurde geht in die richtige Richtung, aber ist trotzdem irgendwie nicht das gelbe vom Ei.
Würdest du bitte noch auf den Vorschlag eingehen, dass der Device-Name im Rahmen der syntaktischen Freiheitsgrade (schön formuliert, das trifft den Nagel auf den Kopf) einfach selbst vergeben werden darf?
Quote from: pmhausen on November 15, 2022, 08:48:14 PM
Ich kann mit durchnumerierten vlanX problemlos leben - es ist doch alle Info im UI. Und auf der Shell sowieso. Daher versteh ich die Aufregung nur teilweise.
Aktuell ist vlanX nicht möglich (zumindest wenn X eine beliebige, frei definierbare Zahl sein soll). Aktuell ist nur vlan0X möglich, wobei X entweder leer sein kann oder eine Kombination aus Punkten und Zahlen. Zumindest hab ich meyergru im zweiten Beitrag so verstanden.
Ich verstehe den Zweck der 0 hinter VLAN nicht.
Ich benutze den automatisch erzeugte Standard vlan0-N und verstehe nicht, welche Info dann fehlt. Man sieht im UI doch überall die Beschreibung bzw. den symbolischen Namen wie LAN, OPT1, etc.
Und im CLI spuckt "ifconfig" auch die Beschreibung mit aus. Ist doch schnurz, wie die Dinger heißen. Das erste lagg ist lagg0, das zweite lagg1, ... das erste VLAN ist vlan0, das zweite vlan1, ...
Die Info zur Semantik, also Parent und VLAN-Tag findet sich doch woanders, die muss nicht in den Namen.
Aber wenn man das unbedingt braucht, weshalb macht die OPNsense dann nicht automatisch das, was auch FreeBSD macht: lagg0.12, em1.17, ... etc.
Cisco IOS auf Routern übrigens genau so. Einfach ".n" für 802.1q Subinterfaces.
Gruß
Patrick
Also ich bin da nicht dogmatisch, aber @pmhausen: Es ist eben nicht vlan0, vlan1 usw., sondern vlan01, vlan02 usw., wenn ich dem Code trauen darf.
Es ist richtig, dass man über den symbolischen Namen (Description) den Interfaces selbst sprechende Namen geben kann, nur, wenn man z.B. ein VLAN für PPPoE braucht, sieht man z.B. beim zugeordneten Link-Interface ja nur den technischen Namen.
Suche ich nach dem Link-Status, sehe ich in der Overview-Sicht zwar den Status, aber nicht das "wirkliche" VLAN. Auch in den Assigments wurde die VLAN-ID erst vor kurzem hinzugefügt.
Das ist aber alles nur "Convenience" und limitiert funktional nicht die Bohne, zudem es einen Workaround gibt... :D
Quote from: meyergru on November 15, 2022, 09:40:51 PM
Das ist aber alles nur "Convenience" und limitiert funktional nicht die Bohne, zudem es einen Workaround gibt... :D
Ja, da stimme ich zu. Die Sense läuft ja auch trotzdem noch. ;-)
Quote from: meyergru on November 15, 2022, 09:40:51 PM
Also ich bin da nicht dogmatisch, aber @pmhausen: Es ist eben nicht vlan0, vlan1 usw., sondern vlan01, vlan02 usw., wenn ich dem Code trauen darf.
So ist es. Habs grad ausprobiert, die VLAN-Interfaces beginnen immer mit vlan0.
Wenn man das Feld Device beim Anlegen eines VLAN nicht ausfüllt, wird nach wie vor stumpf hochgezählt. Also VLAN01, das näcshte VLAN02, VLAN03, usw...
Wenn man das Feld Device ausfüllt, muss zwingend "vlan0" vorne dran stehen. Danach dürfen dann Punkte und zahlen folgen.
Der angesprochene Convenience-Nachhteil ist doch schon ziemlich groß. Zumal ja auch an allen Ecken und Enden in der GUI immer wieder Darstellungsprobleme auftauchen, Tabellen sich nicht gut sortieren lassen, usw...
Der Nachteil vom Workaround bedeutet auch immer, dass man einen Neustart durchführen muss. Wir setzen schon recht stark auf Segmentierung. Das hat zur Folge, dass wir oft neue VLAN-Interfaces anlegen und wir dann recht häufig neu starten müssten für den Workaround. Mal von den Ausfallzeiten abgesehen (wer will das schon bei nem Core-Router/FW?), ist das doch ein ziemlich nerviger und kostentreibender Aufwand. XML runterladen, editieren, hochladen, neu starten, manchmal auch hoffen, dass der Faktor Mensch keinen Fehler ins XML gehackt hat.
Ich hatte früher bereits auch folgende Frage gestellt auf die bisher noch keine Antwort kam:
Was passiert mit Altinstallationen?
Entweder man supported solche Installationen mit z.B. igb0_VLAN0010 auf ewig weiter (und muss dementsprechend dann auch den Code pflegen). In dem Fall kann man die künstliche Einschränkung raus nehmen, denn dann wird der Workaround von meyergru auch auf ewig funktionieren.
Oder es ist absehbar, dass igb0_vlan0010 irgendwann nicht mehr unterstützt und nur noch vlan0.10 gehen wird und Altinstallationen dann ein Migrationsproblem haben werden.
Noch ein Aspekt:
Was ist, wenn ich mehrere Parent-NICs hab, also bspw. igb0, igb1, igb2, igb3, usw...
Und was ist, wenn ich auf igb2 und 3 jeweils VLAN 10 liegen habe, aber das eine VLAN 10 zu Kunde/Mandant A gehört, das zweite VLAN10 zu Kunde/MandantB und diese VLAN10 nix miteinander zu tun haben?
OK, ich könnte dann vlan0.2.10 für igb2 mit vlan10 schreiben und vlan0.3.10 für igb3 mit anderem vlan10.
Aber was wenn ich igb0 und re0 verbaut hab? Dann geht vlan0.0.10 wieder nicht, weil es zwei unterschiedliche Karten mit 0 gibt.
igb2.10 und igb3.10 wären m.E. am sinnvollsten. Macht klar, dass es Subinterfaces sind - und das sind sie in OPNsense, FreeBSD ist kein Switch.
Ok, also noch mal um die Absurdität des ständigen "aber" auszudrücken zu lesbaren Gerätenamen:
2-5 Zeichen Treibername
1-2 Zeichen Treiberindex
1 Trennzeichen VLAN
1-4 VLAN ID
1 Trennzeichen QINQ
1-4 VLAN ID
ergibt
Minimum 7 Zeichen Gerätename
Maximum 17 Zeichen Gerätename
Die Grenze ist 15. Das habe ich bereits gesagt.
Wie soll das technisch für alle Fälle funktionieren?
Wie heißen die Treibernamen mit 4 und 5 Zeichen?
VLAN, LAGG, VXLAN, QinQ ?
Sehe da zwei Möglichkeiten. Entweder man schneidet den Treibernamen einfach nach dem dritten Buchstaben ab. VLAN = VLA, LAGG = LAG, QinQ = Qin, VXLAN = VXL. Sieht manchmal doof aus und ist nicht gerade einleuchtend.
Oder, so machen wir es oft, man wird kreativ: VLAN = vID, VXLAN = xID oder VXL, LAGG = LAG, QinQ = qiq.
Mein Favorit im Aufbau wenns um VLAN und QinQ geht:
phy11.2222.3333
phy = Treibername wie igb, vmx, re, lag, etc.
11 = 0 - 99
2222 = Wenn kein QinQ genutzt wird ist das die VLAN ID, wenn QinQ genutzt wird ist es die QinQ ID. Bereich 1-4094
3333 = Wenn nur VLAN genutzt wird, entfält diese Zahl. Wenn QinQ genutzt wird, wird damit die innere VLAN-ID dargestellt. Bereich 1-4094
Und noch besser wärs, wenn man den Devicename einfach selbst wählen darf. ;-)
Bei VXLAN ist sowieso alles zu spät, weil da allein 8 Stellen für die ID drauf gehen können. Da bleibt dann oft nur vxlan12345678 oder sowas.
Quote from: franco on November 16, 2022, 04:05:00 PM
Ok, also noch mal um die Absurdität des ständigen "aber" auszudrücken zu lesbaren Gerätenamen:
...
Die Grenze ist 15. Das habe ich bereits gesagt.
Wie soll das technisch für alle Fälle funktionieren?
Das geht -
automatisch - natürlich nicht aufgrund der Grenze von 15 Zeichen.
Ich habe nur noch nicht verstanden, wieso man
manuell nicht innerhalb der normalen Freiheitsgrade Interface-Namen vergeben kann - zudem legacy-Namen ja ohnehin nicht dem Pattern für manuelle Vergabe entsprechen.
Theoretisch denke ich mir, man könnte doch den Nutzer selbst den Namen vergeben lassen, die Automatik so belassen wie sie ist und vor / beim Speichern auf Kollisionen prüfen? Die Prüfung benötigt man doch sowieso, falls vorher jemand zufällig den automatisch vergebenen Namen belegt hat.
Damit wären die künstlichen Limits überflüssig. Und bei der automatischen Vergabe kann man bei etwaigen Kollisionen einfach solange weiter hochzählen, bis keine Kollision mehr auftritt - wahrscheinlich ist das sowieso schon so implementiert.
Vielleicht entgehen mir auch nur die offensichtlichen "Annahmen des Codes", die feste Regeln für die manuelle Vergabe erzwingen.
> Wie heißen die Treibernamen mit [...] 5 Zeichen?
"vtnet" sind fünf. Ich würde meine Hand nicht ins Feuer legen, dass dann auch bei 5 schon die Grenze heute oder in der Zukunft erreicht ist.
> Ich habe nur noch nicht verstanden, wieso man manuell nicht innerhalb der normalen Freiheitsgrade Interface-Namen vergeben kann - zudem legacy-Namen ja ohnehin nicht dem Pattern für manuelle Vergabe entsprechen.
Ganz einfach: weil viel vorhandener Code darauf angewiesen ist definierte Namen und Pattern zu erkennen und dann entsprechend zu handeln: vom Erkennen von Hardware Interfaces in get_interface_list() oder wenn eine Entscheidung über die Zugehörigkeit oder Verhalten eines Treibers erkannt werden muss, z.B. https://github.com/opnsense/core/blob/da9c21c550d915ef5edff8e013700e8d68371652/src/etc/inc/plugins.inc.d/core.inc#L289 usw.
Lassen wir alles zu, dann wird langfristig ein Bug gemeldet, der auf die manuelle Benennung abzielte oder wo sich darüber beschwert wird, dass das Zeichenlimit überschritten wurde. Z.B. auch in https://github.com/opnsense/core/issues/3222 ging es um überlange automatische Interfaces, amüsanterweise auch in Verbindung mit dem (fast zu langen) VLAN Legacy Namen.
Man könnte jetzt annehmen das passiert hier alles böswillig, oder weil viel umgestellt und verbessert wurde, weil aus Fehlern gelernt werden muss und wir uns keine absehbaren Patzer leisten können. Und hier sind viele vorhersehbare Patzer in Ideen vorhanden auf die ich nicht weiter eingehen muss.
Grüsse
Franco
Nachvollziehbar, danke für die Erklärung, Franco.
Wie ich schrieb: die Probleme durch implizite Annahmen über den Inhalt von Interface-Namen an anderen Stellen sind von außen natürlich nicht offensichtlich. Böswilligkeit hätte ich niemals unterstellt.
Ich kenne das Problem aus Legacy-Code nur zu gut und auch viel neuere Software wird so designed. Ich versuche eigentlich immer zu vermeiden, Inhalt und Form zu vermischen. Der Merksatz, den einer meiner Mitarbeiter dazu mal geprägt hat, war: "Namen sind nicht das, was sie bedeuten." Anders gesagt, Namen sollten dem Benutzer erlauben, etwas zu benennen, nicht implizit Attribute des benannten Objekts beinhalten.
Tatsächlich kann man über die Bezeichnung ja beliebige symbolische Namen für Interfaces vergeben, bei VLANs fällt es nur eher auf, z.B. weil bei der Konfiguration von PPPoE-Interfaces eben nicht die Bezeichnung, sondern der technische Name verwendet wird, der weniger sprechend ausfällt.
Dann aber eine Frage, Franco - denn das nervt dann tatsächlich meine "OCD" (habe ich natürlich nicht klinisch, aber so als Nerd, der es gerne ordentlich hat ...)
Weshalb vlan01, vlan02, vlan03, ...
Ich kann mit automatischer Benennung im Gegensatz zu anderen prima leben und brauch auch gar keine manuellen Namen. Aber dann doch bitte genau wie für alle anderen Interfaces: vlan0, vlan1, vlan2, ... vlan10, vlan11 ...
Ja, das geht bei alphabetischer Sortierung in die Hose, aber das war schon immer so, ist bei allen anderen Interfaces so - bitte einheitlich.
Ginge das? Issue aufmachen?
Gruß
Patrick
Ja, pppoe, lagg, gif, gre, bridge usw. -- da ist das irgendwie weniger relevant.
Es gibt leider 2 Sachen die schon jahrelang die Modernisierung aufhalten: die Device Namen aus dem System sind hard verdrahtet in der Konfiguration, Hardware-Interfaces alle implizit und leider der Gerätename auch noch direkt im Interface eingetragen anstatt eine Referenz-ID zu verwenden.
D.h. ändert man einen Device-Namen muss auch zwangsläufig die Interface-Referenz geändert werden und dann auch die Konfiguration neu eingespielt werden mit erneuern der Firewall Regeln sogar. In dem Sinne sind die VLANs aus alter Konfiguration eine Augenweide an Seiteneffekten und Sonderbehandlung.
Schöner wäre das Loslösen über einen Gruppennamen, aber auch der ist auf 15 Zeichen beschränkt und auch anderweitig reglementiert:
# ifconfig vlan06 group igb03434445476de
ifconfig: setifgroup: group name too long
# ifconfig vlan06 group igb0.343
ifconfig: setifgroup: group names may not end in a digit
Das schränkt den Spielraum eigentlich genau so ein und nicht immer kann eine Gruppe referenziert werden (ifconfig selber zum Beispiel behandelt keine Gruppen).
Man könnte natürlich einen Wrapper bauen, oder die internen Tools anpassen:
# pluginctl -d
bridge
gif
gre
lagg
ppp
vlan
wlan
ipsec
loopback
openvpn
vxlan
# pluginctl -d vlan
igb2_vlan42
vlan01.
vlan0.3
vlan0.5.6.7
vlan05
vlan06
qinq0.123
vlan0.1.23
Aktuell nur eine Auflistung aus einer Überarbeitung aus der Entwicklungsversion, aber wer sich im ifconfig verloren sieht angesichts der "Unklarheiten" könnte hiermit Licht ins dunkel bringen wenn man mehr Informationen hinzufügt bei der Auflistung. Das würde dann auch dem Kern nicht schaden da es alles im Tool erledigt werden kann.
Die frühere Frage bleibt: ist das arbeiten in der GUI beeinträchtigt? Dann können wir noch was verbessern. Ist das arbeiten in der Konsole beeinträchtigt Dann können wir ja... auch noch was verbessern?
Grüsse
Franco
Patrick: Die Motivation der 0 war die eindeutige Abgrenzung zu Systeminterfaces die manuell angelegt wurden und dabei gleichzeitig die Regex [a-z]+[0-9]+ zu erfüllen, genau wie "qinq" verwendet wurde anstatt "vlan". Kann kein Erfolg versprechen, aber werde mich am Ticket beteiligen.
Grüsse
Franco
Es gibt ja nun ein z.B.
ifconfig em0 name i0
ifconfig igb0 i1
...
Das hat z.B. die Sidewinder-Firewall gemacht und damit abstrahiert man die Hardware-Typen weg.
Wir haben in unserer Hosting-Plattform alle "uplink" Interfaces "inet0" genannt. Alle bridges für Jails "jail0, jail1, ...". Haben wir erst geändert als wir durchgängig lagg bekommen haben und alles auf VLANs gelegt. Seitdem heißen die alle lagg0.<vlan-id> - wie FreeBSD das eben automatisch macht.
Aber die Treiber-Eigenheiten wegbenennen wie die Sidewinder - wäre das was?
Wäre es nicht sinnvoller die Zeichenbeschränkung zu erhöhen?
Grüsse
Franco
Let's see :)
Ich frag morgen mal nett auf freebsd-net ...
Absicht hätte ich auch nicht unterstellt. Alles hat irgendwie Gründe. Danke franco, dass die Diskussion jetzt in Gang gekommen ist und für die Erklärungen.
QuoteWäre es nicht sinnvoller die Zeichenbeschränkung zu erhöhen?
+1 für den Königsweg.
Quote
Die frühere Frage bleibt: ist das arbeiten in der GUI beeinträchtigt? Dann können wir noch was verbessern. Ist das arbeiten in der Konsole beeinträchtigt Dann können wir ja... auch noch was verbessern?
Ja, wenns darum geht, würd ich mir auch die Finger wund tippen. Ist nur immer die Frage ob das auch jemand liest oder jemanden interessiert. Hab ich schon mal gemacht, aber es kam keine Reaktion mehr :) Das ganze zu scrennshotten, beschreiben, etc., kost ja auch seine Zeit.
Ganz allgemein gefragt (vielleicht trifft das auch den Kern des angesprochenen Wrappers?):
Kann man für die GUI und CLI nicht einfach ne Übersetzungstabelle bauen? So dass im Unterbau einfach das Device so heißen kann, wie es für die Codepflege am besten ist, und dass in der GUI oder in der CLI Bezeichnungen benutzt werden können, die einfach sprechender sind und keinen nennenswerten Restriktionen unterliegen?
Aber im UI heißen die Objekte doch schon WAN, LAN, OPT1, ... und du kannst statt OPT1 Dinge wie Customer_ACME, Uplink_Telekom, ... verwenden.
Wo braucht man im UI jemals den Device-Namen? Den Teil begreife ich wirklich nicht. OPßnsense legt da doch auch ganz ohne VLANs schon eine Abstraktionsebene drüber?
Ich seh das halt so:
vlan01 ist genauso vielsagen wie eine kryptische UUID. Es ist eine Information, die zwar mit zusätzlichen Infos verortbar ist, aber ohne zusätzliche Wissen nicht weiter hilft. Man muss im Kopf haben wofür es steht oder wo anders nachschauen um zu wissen was es bedeutet. Einenen schnelle Überblick, der nur das Auge bemüht, kann man sich so nicht verschaffen. Und das ist einfach anstrengend.
Wenn ich mir Interfaces - Assignements angucke, sehe ich in der spalte Network Port ein Durcheinander aus den alten Bezeichnungen vmx1_.... und vlan01, vlan02, etc.. Da dort auch nicht alles in die Felder rein passt, sind die Informationen auch teilweise noch abgeschnitten. Diese Tabelle ist zum Beispiel ein wichtiger Anlaufpunkt um schnell sehen zu können, ob das richtige Interface zum richtigen Device passt.
Wenn ich mir Interface - Other Types - VLAN angucke, hab ich wieder so ein Durcheinander. Die alten Interfaces mischen sich mit den neuen vlan07 und vlan0.1234. Ich kann da nicht auf die Schnelle gucken, ob alle vmx1 parent interfaces nur mit vmx1_*-Devices verknüpft sind, weil sich halt zwischendrin die vlan0*-Interfaces tummeln.
Wenn ich Logfiles durchsuchen will, muss ich mal nach vlan0* , mal nach vmx1_vlan10, mal nach vlan0.1234 suchen. Ich brauch drei Anläufe, muss 3x ein Logfile durchgucken und dann vielleicht Informationen aus den drei Suchdurchläufen kombinieren. Das dauer länger, als wenn man ein Logfile einmal durchsuchen muss und einem dann Infos ins Auge springen.
Wenn in der Konsole Events auftauchen, dann steht dort auch öfter mal vlan0* und ich weiß erstmal nicht, um welches Netz es sich genau handelt. Auch da muss ich erstmal nachschauen.
Ich arbeite viel mit Descriptions, was einiges abfängt. Solang die aber nicht konsequent als führende Information angezeigt, geloggt, in Grafiken verabeitet, in Spalten nach vorne gerückt werden etc., bleibts ein Durcheinanders.
@franco:
> "vtnet" sind fünf. Ich würde meine Hand nicht ins Feuer legen, dass dann auch bei 5 schon die Grenze heute oder in der Zukunft erreicht ist.
Nur als kurze Info dazu: Da darf ich gern auf pfSense bzw. deren ARM Build für die espressobin Boxen (1100/2100) verweisen. Das verwendete Switch/Interface hat als Benennung
"mvnetaX"
6-stellige Bezeichner sind also durchaus ein Ding. :)