Hallo,
ich habe schon seit Jahren HAproxy auf pfSense in Verwendung.
Die Konfiguration auf pfSense scheint recht nah an der tatsächlichen HAproxy Konfiguration angelehnt zu sein. Die originalen HAproxy Anleitungen sind so leicht nachzuvollziehen.
Nun evaluiere ich OPNsense für unseren Zweck und habe auch hier HAproxy eingerichtet. Aber die GUI verfolgt ein völlig anderes Konzept, das nicht nur von jener auf pfSense, auch von der tatsächlichen HAproxy Konfiguration weit abweicht. Ich kann nicht nachzuvollziehen, warum hier die Konfiguration dermaßen zerklüfftet ist: Real Servers, Public Services, Backend Pools, Conditions, Rules, Haelth Monitor.
In pfSense wie auch in HAproxy selbst ist all das in zwei Bereichen zu konfigurieren, Frontends und Backends. Das erscheint mir weitaus übersichtlicher und hängt auch sinngemäß zusammen.
Vielleicht kann mir jemand aber den Sinn dahinter erklären.
Aber okay, da mag sich jemand was anderes überlegt haben, und ich versuche halt damit umzugehen. Doch nun zu meinen eigentlichen Fragen / Problemen:
An einem Punkt erscheint mir die Konfiguration doch regelrecht grotesk:
Conditions
Ich versuche, alles über eine öffentliche IP zu lösen und habe 5 Backend Server. Zu Sinn oder Unsinn dieser Lösung kann man sich hier auch gerne äußern, bislang hatte ich ein Frontend je Backup.
Auf einem dieser habe ich etwa 30 ziemlich verschiedene Hostnamen. So brauche ich eine Menge Host-Conditions, um diesen Server zu bedienen. 14 für einen einzigen virtuellen Server darauf. Der hat so viele Aliase.
So habe ich 14 Conditions mit demselben Namen angelegt, und dachte, so wie es die HAproxy Konfiguration vorsieht, brauche ich diesen nur einmal in der Regel zu erwähnen. Aber nicht auf OPNsense. In der Regel-Konfig scheinen auch alle 14 auf und möchten auch alle angehakt werden, damit sie darauf reagiert.
Im Konfig-File habe ich gesehen, dass jede Condition eine eigene ID erhält und diese verwendet wird. Ich frag mich, warum, wenn es das Original doch einfacher vorgibt.
Ist das wirklich so nötig oder habe ich was übersehen?
Das erscheint mir doch ziemlich abwegig von der eigentlichen HAproxy Konfiguration und ist zudem unnötig kompliziert und unhandlich.
Zusätzlich habe ich noch ein Frage zur 'Maintenance' Funktion:
In einem Backend Pool habe ich einen Server mit Status 'active' und einen weiteren mit Status 'backup'.
Mein Test: Ich aktiviere 'maintenance' auf dem aktiven. Die Anfragen werden auf den Backup weitergeleitet, wie erwartet. Nachdem ich den aktiven wieder auf 'ready' setze, bleibt das allerdings so. Auch ein 'drain' des Backups bringt HAproxy nicht wieder dazu, die Anfragen auf den aktiven Server zu leiten, auch nicht jene einer neuen Session / anderen Browser.
Erst, wenn ich den Backup auf 'maintenance' stelle UND die Webseite im Browser aufrufe, verwendet HAproxy wieder den aktiven Server.
Das kann doch auch nicht Sinn der Sache sein. Auch das funktioniert auf pfSense pipifein.
Hat da jemand bessere Erfahrung? Lassen sich die Server noch irgendwie anders umschalten?
Und dann noch die Frage, lassen sich Aliases aus OPNsense in den Conditions verwenden?
Ich vermute mal, nein, nachdem man eigene User und -Gruppen einrichten kann. Auch das geht in pfSense super toll und ist sehr praktisch.
Wenn das alles negativ bleibt, frage ich mich, ob HAproxy überhaupt die richtige Wahl für einen Reverse-Proxy auf OPNsense ist.
Habe mitbekommen, dass hier sehr viel von Caddy geschrieben wird. Aber kann der auch all das und ist der vernünftiger einzurichten und zu bedienen?
Meine Anforderungen sind sehr überschaubar: Eben wie o.g. ein Backup-Backend, das verwendet wird, wenn der primäre Host down ist, HTTP auf HTTPS Redirect und ein paar Regeln basieren auf Hostnamen, Pfade und später vielleicht noch Files und IPs.
Grüße
Die Konfiguration von HAproxy ist etwas komplex, aber sehr flexibel. Hast Du Dir die Anleitung von TheHellsite (https://forum.opnsense.org/index.php?topic=23339.0) angesehen? Das deckt die meisten Anwendungen gut ab.
Caddy ist im Vergleich weniger komplex, aber "geschwätziger" und es kann ein bisschen weniger, ich habe dazu hier (https://forum.opnsense.org/index.php?topic=38714.msg217354#msg217354) etwas geschrieben.
Auch zu Caddy gibt es ein Tutorial (https://forum.opnsense.org/index.php?topic=38714.0).
Bei Deiner Anzahl an Hostnamen würde ich eher zu HAproxy mit einer Alias Map raten, dann kannst Du die Zertifikate mittels ACME-Wildcards erledigen.
Dazu braucht man nur eine Condition, wirst schon sehen. Je nachdem, wie viele Backends Du hast, brauchst Du natürlich Backends und "Real Server", aber es kann ja gut sein, dass ein Backend mehrere Hostnamen abdeckt.
Mit Maintenance habe ich noch nicht gespielt, ich nutze auch keine Redundanz nach hinten. Durch das "Health Checking" könnte man aber m.W. sowieso ein automatisches Failover hinbekommen, so dass man das nicht aktiv managen muss.
Caddy hat einen anderen Fokus im Plugin. Eher Heimanwender und kleine Firmen. Features wie Lets Encrypt, DNS Provider, Dynamic DNS etc... sind da direkt mit eingebaut. Die GUI ist auf so gut es geht Einfachheit und wenig User Error durch zuviel Abstraktion ausgelegt, im gesamten Design.
Ich würde die Tools (in Form der Plugins) so nicht vergleichen da sie einen grundlegend anderen Scope haben.
Featureparität gibt es da nicht, beide haben Features die das andere Tool in der Form nicht bieten.
Die Frage war, weshalb die Konfiguration des HAproxy-Plugins so vollkommen anders aufgebaut ist als in pfSense ;)
Lässt sich hiermit beantworten:
https://github.com/opnsense/plugins/issues/208
Der Weg zur Hölle ist gepflastert mit guten Absichten ::)
Ich hatte die Diskussion mit Franco schon beim WireGuard. Ich würde Konzepte und Bezeichnungen für jeden in OPNsense integrierten Dienst immer zu 100% vom Upstream übernehmen.
Der Commit liest ich zwar anwenderfreundlich, ist es aber nicht.
Anwenderfreundlich ist, wenn man "HAproxy how to do foo" in Google kippen und die Ergebnisse von Stackoverflow 1:1 ins UI kopieren kann mit so wenig Übersetzungsleistung wie möglich.
Meine Meinung, muss nicht jeder teilen. :)
@Patrick
Genau, das ist der Punkt.
Es gibt im Web jede Menge Hilfe zu HAproxy, Doch wenn ich das im OPNsense Plugin konfigurieren will, brauch ich einen Pons dazu.
pfSense hatte ich erwähnt, weil da in der GUI weitgehend die HAproxy Konfig-Datei abgebildet ist. Da wird ein frontend als "Frontend", backend "Backend" und acl als "ACL" bezeichnet, wie im Konfig-File auch. Auch die Reihenfolge ist identisch, wenngleich ich Backends voranstellen würde, weil ich diese zuerst konfigurieren muss.
In OPNsense GUI finde ich nicht mal eine dieser Bezeichnungen demselben Zweck entsprechend verwendet.
Aber gut, das ist nicht mein größtes Problem. Nachdem ich mit HAproxy schon etwas Erfahrung gesammelt habe, weiß ich zumindest, wonach ich suchen muss.
Doch die Sache mit den zig Conditions für denselben Zweck, die ich dann auch nochmals in der Regel angeben muss, würde ich schon als Problem bezeichnen. Das führt schnell zu Unübersichtlichkeit, selbst bei meiner kleinen Konfiguration mit nur einer handvoll Backends.
@Alle
Danke für die Links. Muss ich mir morgen noch ansehen.
Grüße
Zwei Dinge:
1. Ja, die OpnSense GUI unterscheidet sich stark von "HAproxy native". Die Karawane zieht weiter, man muss das Plugin nicht nutzen.
2. Man braucht eben keine tausend Conditions. TheHellsite umgeht das elegant mit einer einzigen Regel, wo in einer Map die Namen auf Backends abgebildet werden. Das ist, was ich meinte, wieso ich bei komplexen Konfigurationen HAproxy bevorzuge. In Caddy müssen die verschiedenen Bestandteile jeweils pro Name angelegt werden, das wird mir immer zu unübersichtlich.
Ist wohl mehr die Frage, ob / wie man etwas fertig bekommen möchte (ich bin da ziemlich lösungsorientiert) oder sich an der konkreten Umsetzung in einer bestimmten Umgebung abarbeitet oder mit einem bestimmten Hintergrundwissen daherkommt. Letztlich war das wohl auch der Grund, weshalb Fraenki HAproxy so "verpackt" hat, dass es seiner gewohnten Load-Balancer-Nomenklatur entspricht.
Wenn man sich mal von seinem vermeintlichen Vorwissen löst (oder vorgibt, keins zu haben, wie ich), muss man ja nur dem einen oder anderen Tutorial folgen, um sein Ziel zu erreichen - wenn man's denn will.
P.S.: Wie bei vielen Open-Source Tools habe ich bei HAproxy auch feststellen müssen, dass ein 2-3 Jahre altes Tutorial, das ich bei Google finde. überhaupt nicht mehr anwendbar ist, weil die Hälfte der Optionen inzwischen deprecated sind.
Quote from: meyergru on November 26, 2024, 07:30:12 PM
Die Konfiguration von HAproxy ist etwas komplex, aber sehr flexibel. Hast Du Dir die Anleitung von TheHellsite (https://forum.opnsense.org/index.php?topic=23339.0) angesehen? Das deckt die meisten Anwendungen gut ab.
Danke dafür.
Die Map Files könnten also wahrscheinlich mein Problem mit den vielen Conditions für denselben Zweck lösen.
Allerdings, so wie ich es verstanden habe, lassen sich damit Hostnamen nur direkt auf ein Backend mappen, nicht aber auf einen Backend Pool, wodurch kein Failover möglich wäre.
Muss mir aber noch die genannten Links dazu ansehen. Für meinen speziellen Zweck brauch ich aber eh kein Failover.
Damit wäre mir also schon mal geholfen.
Quote from: meyergru on November 26, 2024, 10:47:41 PM
P.S.: Wie bei vielen Open-Source Tools habe ich bei HAproxy auch feststellen müssen, dass ein 2-3 Jahre altes Tutorial, das ich bei Google finde. überhaupt nicht mehr anwendbar ist, weil die Hälfte der Optionen inzwischen deprecated sind.
Das trifft auch auf TheHellsites Tutorial zu.
Und leider behandelt es keine HTTPS Frontends, nur TCP. Ich werde aufgrund der Filtermöglichkeiten eher HTTPS verwenden.
Quote from: viragomann on November 27, 2024, 02:17:52 PM
Die Map Files könnten also wahrscheinlich mein Problem mit den vielen Conditions für denselben Zweck lösen.
Allerdings, so wie ich es verstanden habe, lassen sich damit Hostnamen nur direkt auf ein Backend mappen, nicht aber auf einen Backend Pool, wodurch kein Failover möglich wäre.
Nein, das Mapping läuft auf einen Backend Pool, der dann mit N "Real Servers" bestückt wird.
Quote from: viragomann on November 27, 2024, 02:17:52 PM
Und leider behandelt es keine HTTPS Frontends, nur TCP. Ich werde aufgrund der Filtermöglichkeiten eher HTTPS verwenden.
Doch, genau das tut es. Die Konfiguration ist tricky, aber sehr effektiv. Er definiert drei Frontends, das erste ist tatsächlich TCP, dient aber nur dazu, auf ein Backend zu verweisen, das SNI macht und dann auf die beiden anderen HTTP(S) Frontends verzweigt. Dabei macht er auch gleich noch HSTS-Redirection, verwaltet Zertifikate, macht SSL-Offloading u.v.a.m.
Ich wage zu behaupten, dass man ohne diese Anleitung mit HAproxy "native" kaum selbst eine so elegante Lösung hinbekäme. Ich habe das sowohl bei mir zu Hause wie auf zwei Proxmox-Servern bei Hetzner im Einsatz.
Quote from: meyergru on November 27, 2024, 03:13:39 PM
Nein, das Mapping läuft auf einen Backend Pool, der dann mit N "Real Servers" bestückt wird.
Okay, das mach ja Sinn.
QuoteEr definiert drei Frontends, das erste ist tatsächlich TCP, dient aber nur dazu, auf ein Backend zu verweisen, das SNI macht und dann auf die beiden anderen HTTP(S) Frontends verzweigt. Dabei macht er auch gleich noch HSTS-Redirection, verwaltet Zertifikate, macht SSL-Offloading u.v.a.m.
Dann hab ich den Sinn dahinter wohl nicht verstanden.
Er schreibt beim TCP Frontend, dass dieses dazu da ist, um den Traffic zwischen SSL Offloading oder nicht aufzuteilen. Ich möchte aber für alles SSL Offloading haben, also habe ich es für meinen Zweck als nicht nötig gehalten.
Die Umleitung von HTTP auf HTTPS hatte ich auch schon gebaut. Dazu hatte ich ein Frontend erstellt, dass nur auf Port 80 lauscht und mit er entsprechenden Regel versehen. Das von ACME erstellte "redirect_acme_challenges" wollte dann auch noch da rein.
Und für alles andere habe ich ein HTTP Frontend auf Port 443.
In dem vorgeschalteten zusätzlich TCP Frontend kann ich aktuell keinen Vorteil für mich erkennen. Ich möchte mit dem Reverse Proxy ausschließlich Webserver Backends bedienen.
Kann schon sein, dass man das auch anders lösen kann.
Aber: TheHellSite's Ansatz hat den Vorteil, dass es die HTTP->HTTPS Redirection am Rande mit erledigt, außer, wo es nicht gebraucht wird oder sogar schädlich wäre, z.B. für die ACME-Verifikation unter /.well-known..., denn die funktioniert eben nur per HTTP.
Also bringt ein Frontend, dass immer auf HTTPS umleitet, gewisse Probleme mit sich.
Ich will jetzt hier nicht die ganzen Vor- oder potentiellen Nachteile des Tutorials durchkauen. Daher mein Rat: Vergiss, was Du zu wissen glaubst und probier die Anleitung einfach aus. Du wirst überrascht sein.
Die Alternative ist, dass Du alles selbst erfindest. Ich würde das nicht tun, weil die Anleitung 100% für genau Dein Vorhaben funktioniert, Deinen Bedenken zum Trotz. Das setzt natürlich voraus, dass man nichts vergisst.
Übrigens: Das Tutorial behandelt auch - entgegen Deiner Annahme - keine reinen TCP-Verbindungen bzw. "Nicht-Webserver". Es geht nur um HTTP und HTTPS, man kann aber durch Hinzunahme weiterer Frontends natürlich auch beispielsweise SMTP(S) oder IMAP(S) bedienen. Das ist aber nicht Gegenstand des Tutorials.
Quote from: meyergru on November 27, 2024, 04:13:50 PM
Aber: TheHellSite's Ansatz hat den Vorteil, dass es die HTTP->HTTPS Redirection am Rande mit erledigt, außer, wo es nicht gebraucht wird oder sogar schädlich wäre, z.B. für die ACME-Verifikation unter /.well-known..., denn die funktioniert eben nur per HTTP.
Ich hatte das schon eingerichtet gehabt, bevor ich dieses Tutorial kannte.
Er benötigt mit seiner Methode auch zwei Frontends, nur dass das HTTP dann auf die interne IP lauscht.
Auf pfSense ging meine Methode übrigens mit einem einzigen für beide Ports 80 u. 443. Die Regel für das Redirect war dann im Frontend angelegt.
OPNsense hatte bei mir aber beim HTTPS Frontend nicht unterschiedliche Ports akzeptiert. Bei TCP scheint das zu gehen, dann ist aber auch ein zweites erforderlich. Kommt für mich aufs selbe raus.
QuoteIch will jetzt hier nicht die ganzen Vor- oder potentiellen Nachteile des Tutorials durchkauen. Daher mein Rat: Vergiss, was Du zu wissen glaubst und probier die Anleitung einfach aus. Du wirst überrascht sein.
Ja, die Anleitung habe ich mir notiert und ich werde sicher noch mehrmals rein schauen, ob ich was brauchen kann.
Danke dafür.
Ich habe jetzt aber eine neue Herausforderung: Anstatt die ganzen Hostnamen im Map File auf ein Backend zu leiten, möchte ich sie direkt in HAproxy auf einen andren Server weiterleiten. Ich komme da aber mit dem Map File nicht weiter.
In der Regel, wo http-redirect zu setzen wäre, kann ich dann aber nur Conditions für diese Funktion angeben. Demnach brauche ich dann doch wieder meine 14 Conditions. ::)
Eine Idee noch, vielleicht kann man den Redirect-URL im Map File angeben. Muss ich mir noch genauer ansehen, was das so alles kann.
Man kommt mit einem Map-File alleine nicht weiter (und man kann dort auch keine URLs angeben), kann aber einfach mehrere Backends (eine pro Weiterleitung) definieren. In denen verzichtet man auf Angabe eines "Real Server", fügt aber eine Regel hinzu.
Die Regel enthält dann die Weiterleitung mittels "http-request redirect code 301 location https://xxxxxx". Das gesperrte ist der Parameter zur "http-request redirect"-Regel.
Wenn die Weiterleitungen einem Muster folgen, kann man natürlich auch mit einem Backend und einer Regel arbeiten, die entsprechend parametriert ist.
Damit sehen Redirects im Map-File genauso aus wie die Verteilung auf "normale" Backends. Man kann sie zur Unterscheidung ja z.B. xxxxxx_redirect statt xxxxx_backend nennen.
Ergo: Keine einzige Condition.
Verstehe nicht, wie ich da dem Proxy klar mache, wann er diese Backends verwenden soll.
Ich habe aktuell 14 Hosts Muster, die alle auf einen URL weitergeleitet werden sollen. Diese enthalten schon Wildcards, wie ich sie in "Host" Conditions verwenden kann, ansonsten wären es über 20.
Wo ich diese da einbauen soll, kann ich deiner Anleitung leider nicht entnehmen, und ob das Komplexität einspart oder diese nur verlagert.
Namensbasiert. Das map-File sieht doch genau so aus:
www.xyz.de www-xyz_BACKEND
forum.xyz.de forum-xyz_BACKEND
wiki.xyz.de wiki-xyz_BACKEND
...
Wobei die _BACKENDs gemäß dem Tutorial eben Backends sind, die auf Real Server verweisen.
Da fügt man einfach weitere Backends an, die keinen Real Server haben, sondern nur je eine Weiterleitungs-Rule, wie oben beschrieben:
weiterleitung1.xyz.de xyz1_REDIRECT
weiterleitung2.xyz.de xyz2_REDIRECT
...
Wenn man Teile des Namens wiederverwenden will, muss natürlich die Regel entsprechend aufgebohrt werden, um HAproxy-Variablen zu verwenden. Dann reicht dafür eventuell eine Regel und ein paar Zeilen im Map-File, die alle das selbe Backend verwenden:
weiterleitunga.xyz.de xyz_REDIRECT
weiterleitungb.xyz.de xyz_REDIRECT
...
P.S.: Wildcards gehen im Map-File nicht.
Quote from: meyergru on November 27, 2024, 06:13:20 PM
Namensbasiert. Das map-File sieht doch genau so aus:
www.xyz.de www-xyz_BACKEND
forum.xyz.de forum-xyz_BACKEND
wiki.xyz.de wiki-xyz_BACKEND
...
Wobei die _BACKENDs gemäß dem Tutorial eben Backends sind, die auf Real Server verweisen.
Ach ja, logisch. Im Map File ist ja das Backend einzutragen. Dass es nun kein tatsächliches ist, hat mich verwirrt.
Sollte klappen.
Okay, versuche ich morgen.
Danke.
Grüße
@meyergru
Geschafft!
Es braucht 2 Regeln. Das ging für mich aus deiner Erklärung nicht hervor und führte zur Unklarheit.
Eine für das http-request-redirect und eine weitere, die auf das Map File verweist und ich im Frontend eingebunden werden kann.
Ich kann auch noch bestätigen, dass Wildcards wie www.* (hab ich tatsächlich eingebaut :) ) im Map File funktionieren.
Ich muss, nachdem ich dieses eingerichtet habe, nochmal bekräftigen, die GUI ist alles andere als übersichtlich. Um einen Überblick zu bekommen, musste ich mir alle für den Zweck benötigen Konfigurationsteile heraus schreiben, das Backend, die beiden Regeln, das Frontend.
Eine GUI sollte eigentlich die Konfiguration erleichtern. Aber in dieser sind die Kategorien dermaßen zerpflückt, dass die Zusammenhänge vollkommen verloren gehen. Die verwendeten, vom HAproxy Konfig File abweichenden Bezeichnungen für die einzelnen Funktionen tun dann ein Übriges.
Das mit dem Map File ist klar, dass dies einen gesonderten Platz in der Konfig hat, weil es verschiedene Zwecke erfüllen kann. Aber ein Backend Pool da, zwei Regeln dort, im Frontend einbinden...
Gewiss, wenn man es ein paar mal gemacht hat, geht es einem wahrscheinlich problemlos von der Hand, aber für einen Neuling ist das nicht zu durchschauen.
Ja, man muss es ja nicht nutzen... Aber die Software nicht zu nutzen kann ja nicht die Intuition der Entwickler sein.
Wie auch immer, ich habe einiges gelernt.
Vielen Dank für die Unterstützung.
Grüße
Hallo,
ich muss diesen Thread nochmals aufgreifen, nachdem die Sache nicht, wie erwartet, funktioniert.
Aus Freude an der Ordnung, die mir das Map File für die ganzen Redirects in die Konfiguration gebracht hat, habe ich für ein weiteres Backend mit 7 Hostnamen ein weiteres Map File erstellt und die Regel entsprechend geändert.
Hat auch funktioniert.
Jedoch habe ich gestern bemerkt, dass dir Redirects aus dem ersten Map File nicht mehr funktionieren. Bei Aufruf eines Hosts bekomme ich von HAproxy 503 zurück.
Wenn ich die Regel fürs 2. Map File aus dem Frontend entferne, geht es. Natürlich.
Beim Herumspielen mit den Regeln ist mir aufgefallen, dass immer die letzte Regel, die ich hinzufüge nichts bewirkt.
Schreibe ich alle Mappings in ein File und verwende eben nur die entsprechende Regel, funktionieren auch alle.
Alle Hostnamen und die beiden Backends in den Map Files sind eindeutig. Wildcards hatte ich entfernt, um dies sicher überprüfen zu können.
Eine Recherche, ob vielleicht nur 1 Map File desselben Typs (Hosts) erlaubt wären, brachte nichts. Aber bezüglich mehrere Map Files bin ich auf den Hinweis gestoßen, dass diese im Frontend per IF zu verknüpfen wären, was aber OPNsense nicht macht.
Die beiden Map File Regeln werden in der HAproxy Konfig einfach nacheinander beim Frontend eingetragen:
use_backend %[req.hdr(host),lower,map_dom(/tmp/haproxy/mapfiles/674879807b26b5.22516524.txt)]
use_backend %[req.hdr(host),lower,map_dom(/tmp/haproxy/mapfiles/67472b11b0a4a9.24401988.txt)]
Nachdem ich im Frontend keine Möglichkeit habe, Regeln zu verknüpfen, nehme ich an, dass OPNsense das automatisch machen müsste.
Könnte man das bitte einpflegen?
Die Logik, die die Konfig generiert, erkennt ja schon, dass es sich bei der Regel um eine Map File Regel handelt. Diese im Fall mehrere noch zu verknüpfen, sollte nicht mehr viel Aufwand geben.
Nach Verwendungszweck getrennte Map Files sind doch übersichtlicher, als alles in eines zu schreiben.
Grüße
Edit:
Bei solch einem Problem sollte man die OS Version nennen: 24.7.9
Im Change Log zur aktuellen 24.7.10 konnte ich aber nichts Diesbezügliches finden. Wurde also noch nichts daran geändert.
Wenn du möchtest, dass sich hier etwas tut, ist das Beste, einen Issue auf Github zu öffnen.
Die beiden Maps ohne logische Verknüpfung hintereinander zu schreiben, darf man ja sicher "Bug" nennen.
Durch Forenposts löst du in der Regel (!) keine Aktionen in der Entwicklung aus.
Das böse Wort wollte ich nicht verwenden, und so sicher war ich mir dessen auch nicht.
Ich dachte, ihr habt einen direkten Draht zu den zuständigen Leuten und könntet das formlos weitergeben.
Entwickler wie Franco oder Cedrik lesen hier mit, aber garantiert is da nix und ich habe keinen direkteren Draht als du auch.
Ich kann das auch nicht nachstellen, ich habe deine Anwendung nicht und bis auf eine einzige meiner vielen Firewalls auch nirgends HAproxy.
Daher bist der einzig qualifizierte Mensch für den Bugreport im Moment du. Kein Issue, keine Aktion ;)
Nur wenn man auf github bei den plugins eine issue öffnet bekommt der Maintainer auch was davon mit. Viele plugins haben verschiedene Maintainer und nicht alle lesen hier.
Abgesehen davon sehe ich auch nicht, wo der Fehler liegen soll. Man braucht ja keine zwei Mapfiles für verschiedene Backends. Eins reicht völlig, es ist lediglich so, dass verschiedene Zeilen darin auf verschiedene Backends verweisen, die dann wiederum unterschiedliche Server bedienen.
Wenn man das besser lesbar gestalten will, kann man ja Kommentarzeilen einfügen.
Okay, ist erledigt.
.. für die "Nachwelt". Für meine Bedürfnisse hätte ich mich auch mit einem gemeinsamen Map File abfinden können. ;)
Vielleicht aber noch eine Frage für meine künftigen Ambitionen an dieser Stelle:
Gibt es Ansätze, Map Files von außen zu generieren? Durch API od. per Script via SSH.
Das könnte bei vielen Domains doch hilfreich sein, und vor allem könnten Änderungen automatisiert werden.
Quote from: meyergru on December 10, 2024, 05:16:33 PM
Abgesehen davon sehe ich auch nicht, wo der Fehler liegen soll. Man braucht ja keine zwei Mapfiles für verschiedene Backends.
Es würde der Übersichtlichkeit und dem Komfort dienen.
Die in einem Map File zusammengefassten Domains erfüllen denselben Zweck. Wenn sich an deren Routing was ändern soll, gilt das für alle. Dann brächte ich nicht ein unübersichtliches Map File editieren, dessen Darstellung in der GUI zudem immer ziemlich mickrig geöffnet wird.
Man braucht auch nicht zwingend eine hübsche GUI, um die Funktionen von OPNsense umzusetzen, dennoch wurde eine gemacht.
Mehrere Map Files zu mergen, wäre auch ein gangbarer Weg und habe ich auf Github auch vorgeschlagen.
Wenn man das besser lesbar gestalten will, kann man ja Kommentarzeilen einfügen.
Danke für den Tipp.
Das hätte ich auch versucht. Wusste aber nicht, ob das auch akzeptiert wird. Und dein Link zur Syntax von Map Files funktioniert leider nicht mehr.