Ein paar Einstellungen ändern und die Sense reagiert kaum noch.

[bitboy0]

ich habe das Problem in vielen Dialogen, wo ich nacheinander einige ähnliche Datensätze ändern muss.

• Rules bei NAT oder Firewall
• Benutzer
• OpenVPN-Overrides

Sagen wir mal ich habe für 10 User auch 10 Client-Overrides bei OpenVPN.
Ich möchte bei allen einen zusätzlichen DNS eintragen.
Dann öffne ich den ersten zur Bearbeitung und trage das ein und speichere den. Das geht sofort
Das mache ich auch für die nächsten 2-3 Einträge, ebenfalls kein Problem
Dann der nächste, aber es dauert durchaus 20-30 Sekunden bis ich die Maske sehe. Speichern dauert 1 Minute.
Der nächste, es dauert 1-2 Minuten bis ich die Maske sehe, auch 1-2 Minuten es zu speichern.

Gebe ich der Sense danach etwas Zeit (1-2 Minuten ohne weitere Eingaben), dann reagiert sie beim nächsten Edit wieder schnell.

Wie gesagt, das betrifft Einträge in der Firewall genauso wie User oder NAT-Regeln.
Ich kann aber weder eine besonders hohe CPU-Last erkennen (in der Regel unter 0.2) noch sehe ich einen Mangel beim Speicher.
Es werden auch keine Fehler erzeugt und die User können das Netz ohne Störung benutzen.

[jahonix]

Welcher Browser?
Mit einem aktuellen Safari habe ich dieses Verhalten auch öfter auf verschiedenen Seiten, nicht nur in der pfSense.
Andere Browser laufen da momentan deutlich flüssiger…

[bitboy0]

Chrome, Edge, Firefox, IE

Das ist egal … wenn ich EINE Einstellung ändere, oder zwei, dann klappt das sofort. Will ich direkt nacheinander 10 NAT-Regeln, oder User oder so was ändern, dann läd er sich einen Wolf ab der 3.ten oder 4.ten Änderung ...

[JeGr]

Ist das nanoBSD oder Full Install?

[bitboy0]

Ist wohl nano.

2.2.4-RELEASE (amd64)
built on Sat Jul 25 19:57:37 CDT 2015
FreeBSD 10.1-RELEASE-p15

und war eben vom varia-store schon vorinstalliert auf 2.2
http://varia-store.com/Systeme-mit-Software/pfSense/pfSense-19-Komplettsystem-mit-2x-APU1D4-1GHZ-Dual-Core-4GB-R::3261.html

[viragomann]

Kann es sein, dass die Firewall auf die Synchronisation warten muss? Sollte zwar auf einer APU auch nicht soviel Zeit in Anspruch nehmen, aber schließlich ist es ein NanoBSD und muss die gesamte Konfiguration auf die SD schreiben.
Vielleicht das mal überprüfen.

Habe selbst nicht die Erfahrung mit CARP auf NanoBSD. Von einem CARP Set mit normalen HDD kenne ich das nicht.

[jahonix]

@bitboy0:

Ist wohl nano.

Wie kommst'n jetzt da drauf?
Meine APUs melden sich auch so, dort läuft jedoch die Full-Install in 64-bit. Ist für die Platform ja auch so empfohlen.

Unter der Version steht Platform, gefolgt von "pfSense" oder "nanobsd". Siehe Screenshots.


[bitboy0]

Die Leute vom Vario-Store scheinen gerne veraltete Infos mitzuschicken .. in den Beilagen stand was von NANO, aber das ist wohl nicht so.

Also es ändert aber nichts daran: Wenn ich ein paar Sachen ändere, dann wird die Oberfläche eextrem zäh, bzw. in Firefox steht "verbindung wird hergestellt" und nichts passiert… bis nach einer Weile dann die Seite doch kommt.

Das könnte an CARP liegen? Wie kann ich das rausfinden? Und warum sollte es länger als eine Minute dauern die paar Byte auf SD zu schreiben? Die ganze Konfig sind ja nur ein paar MB.

[JeGr]

Die Leute vom Vario-Store scheinen gerne veraltete Infos mitzuschicken .. in den Beilagen stand was von NANO, aber das ist wohl nicht so.

Das ist eben problematisch wenn da keine Leute bei sind, die sich aktuell halten. Allerdings ist Varia eigentlich m.W. ein authorized Reseller, sollte also nicht so sein.

Ändert aber auch nichts daran, dass du immer noch nicht gesagt hast, ob es nun NanoBSD oder pfSense (full) ist ;) Das stand bei deiner Ausführung jetzt leider nirgends :) Bei deinem Link zum Komplettsystem steht leider auch nicht ob SD Karte oder mSATA verbaut ist.

Wenn es NanoBSD ist, versuche mal bitte auf der Konsole folgendes:

time /etc/rc.conf_mount_rw

und danach

time /etc/rc.conf_mount_ro

Die Ausgaben sagen dir dann, wie lange die Sense zum locken/unlocken des Dateisystems braucht. Beispiel:

time /etc/rc.conf_mount_rw
0.161u 0.053s 0:00.27 77.7%    4676+324k 0+30io 0pf+0w
time /etc/rc.conf_mount_ro
0.179u 0.080s 0:04.87 5.1%      3934+278k 0+852io 0pf+0w

Sprich: Meine Testkiste braucht ca. 5s (unten) um wieder auf R/O zu schalten, nachdem sie was geschrieben hat. Das verzögert jegliche Ausgabe natürlich ungemein. Wir hatten kürzlich eine von zwei APUs die mit NanoBSD läuft, die nach dem Update auf 2.2.4 komplett eingeschlafen ist. Die brauchte fast 30s bei jedem R/O Mount. Wir haben da jetzt auch aus anderen Gründen beide Kisten auf mSATA SSDs aufgerüstet und jetzt flitzen die Dinger wie nix (Vollinstallation).

[bitboy0]

[2.2.4-RELEASE][admin@pfsense.wedia.de]/root: time /etc/rc.conf_mount_rw
0.137u 0.084s 0:00.22 95.4%     5214+348k 0+18io 0pf+0w
[2.2.4-RELEASE][admin@pfsense.wedia.de]/root: time /etc/rc.conf_mount_ro
0.192u 0.025s 0:00.22 95.4%     4675+312k 0+18io 0pf+0w
[2.2.4-RELEASE][admin@pfsense.wedia.de]/root: time /etc/rc.conf_mount_rw
0.176u 0.038s 0:00.21 95.2%     5286+352k 0+18io 0pf+0w
[2.2.4-RELEASE][admin@pfsense.wedia.de]/root: time /etc/rc.conf_mount_ro
0.160u 0.053s 0:00.21 100.0%    5034+336k 0+18io 0pf+0w
[2.2.4-RELEASE][admin@pfsense.wedia.de]/root: time /etc/rc.conf_mount_rw
0.174u 0.047s 0:00.22 95.4%     5034+336k 0+18io 0pf+0w
[2.2.4-RELEASE][admin@pfsense.wedia.de]/root: time /etc/rc.conf_mount_ro
0.170u 0.046s 0:00.21 100.0%    5034+336k 0+18io 0pf+0w
[2.2.4-RELEASE][admin@pfsense.wedia.de]/root: time /etc/rc.conf_mount_rw
0.167u 0.047s 0:00.21 95.2%     5097+340k 0+18io 0pf+0w
[2.2.4-RELEASE][admin@pfsense.wedia.de]/root: time /etc/rc.conf_mount_ro
0.191u 0.030s 0:00.22 100.0%    4977+332k 0+18io 0pf+0w

[JeGr]

OK danke dir, das ist definitiv fix. Da kommen auf jeden Fall die Proleme nicht her, das würde man sonst direkt schon sehen. Wenn das dann nach der 3./4. Änderung schon der Fall ist - wie schauen die Einstellungen unter System / AdvancedSettings aus? Da werden per default 2 Max Processes für die GUI gestartet. Da kannst du auf der APU aber auch gut und gern 5-10 machen gesetzt du hast noch RAM über, aber ich denke mit 4GB sollte da schon einiges übrig sein. Hast du da schon was erhöht? Wenn nein, dreh das mal rauf und schau dir an wie sie sich verhält :)

Grüße

[jahonix]

@JeGr:

Allerdings ist Varia eigentlich m.W. ein authorized Reseller, sollte also nicht so sein.

Wäre ja schön, aber von allen meinen Lieferanten/Distries bekomme ich Ware mit einem Software/Firmware-Stand zu Zeiten der Herstellung. Niemand macht sich da die Arbeit, eine Gerät vor Auslieferung mit Updates zu versehen. Niemand.
Täten das die Jungs und Mädels vom Varia-Store trotzdem, dann wären sie wegen der gestiegenen Kosten nicht mehr konkurrenzfähig. So leicht ist das leider.

[JeGr]

Niemand macht sich da die Arbeit, eine Gerät vor Auslieferung mit Updates zu versehen.

Naja das ist ja eine Seite, aber die andere - sofern das korrekt ist - wäre es, alte/falsche Informationen weiterzugeben wie bei den APUs und Auto-Updates aus der GUI etc. Da weiß ich wirklich nicht, wo die herkommen sollen. Es gab zwar wie gesagt mit 2.2.2->.3->.4 ein Problem mit dem Schreiben auf SD Karten bzgl. ro/rw/ro mount Zeiten sowie mal ein Schreib-Problem, aber ob ich mein Gerät jetzt via GUI oder Console update ist ja im Prinzip egal, da durch die 2 Bootslices der alte Stand wieder gebootet werden kann. Ein Neu-Flashen soll ja nun genau damit verhindert werden, damit man nicht jedes Mal die Kiste außer Betrieb nehmen muss.

Ob es dann Aufgabe eines autorisierten Partners ist, immer auch das letzte FW Release auf den Geräten zu shippen ist jetzt ne andere Frage. Ich halte das nicht für nen Riesen-Act, zumal es sich extrem automatisieren lässt (von wegen konkurrenzfähig). Wenn Bestellungen kommen für fertige Builds, muss ich ggf. auch jemand hinsetzen, der die Dinger zusammenklöppelt, da Varia m.W. die APUs auch nicht von pfSense ordert, sondern von pcEngines und sie dann fertig baut. Dann ists auch kein Akt an der Flash-Station das aktuelle Image draufzuflashen, einmal anfahren zum Testen, geht, nächstes. So haben wir das für unsere Kunden letztes Jahr auch gemacht (da die bereits ihre Config in der Box eingespielt haben wollten). Aber gut, Firmenkunden sind vllt. auch nochmal was anderes als Privatkunden. Trotzdem ist das IMHO kein größerer Aufwand (neues ISO laden, in den Build Prozess der SD Karte hängen, done). :)

Grüße
Jens

[jahonix]

@JeGr:

die bereits ihre Config in der Box eingespielt haben wollten

Das impliziert doch, dass Du Deine Zeit bereits mit verkaufst und in einem Service-Preis einrechnest.
Bei den Store-Preisen handelt es sich immer um reine Warenlieferungen.

…und ganz ehrlich, ein Firmware-Update auf den tagesaktuellen Stand mache ich bei allen Geräten sowieso immer, wenn ich sie ausliefere.
Meistens ist das in meinem Fall jedoch keine IT-Hardware sondern Medientechnik und die Steuerungen dazu, Switch und APs oder gar Router sind nur manchmal Arbeitsumgebungen dazu.

[bitboy0]

Meine Sense kam mit 2.2 … und einer Info, dass ein Update nicht über die GUI möglich sei.

Aber nochmal zurück zum Thema:
Was kann in meinem Fall hier dieses Problem sein? Ich kann ein paar Einstellungen ganz normal und zügig ändern, dann dauert es plötzlich sehr lange um eine Seite auf der Sense zu erreichen. Es wird bis zu 2 Minuten nur "Verbindung wird hergestellt" angezeigt und dann geht es wieder.... wenn ich der Sense dann ein bisschen Ruhe gönne (1-2 Minuten) regaiert sie wieder normal, bis ich den Zustand wieder erreiche.

Das es mit CARP zu tun haben könnte finde ich seltsam.... die Verbindung ist einfach ein Patchkabel direkt zwischen den Anschlüssen und die ganze Config ist ja nur ein paar MB groß... und die schreibt man in wenigen Sekunden über das Netz und auf die SD ... also eher unter einer Sekunde.

[JeGr]

Das impliziert doch, dass Du Deine Zeit bereits mit verkaufst und in einem Service-Preis einrechnest.

Das wiederum ist richtig - Punkt für dich :)

Meistens ist das in meinem Fall jedoch keine IT-Hardware sondern Medientechnik und die Steuerungen dazu, Switch und APs oder gar Router sind nur manchmal Arbeitsumgebungen dazu.

Finde ich aber auch einen spannenden Bereich :)

Meine Sense kam mit 2.2 … und einer Info, dass ein Update nicht über die GUI möglich sei.

Das wiederum finde ich eher weniger schön, denn seit 2.x (2.1) war das in den meisten Fällen kein Problem mehr. Ausnahmen gibts leider immer.

Aber nochmal zurück zum Thema:

Das ist mir auch ein kleines Rätsel. Hattest du mal wie angemerkt die Anzahl gleichzeitiger Threads für die WebUI erhöht? Siehe ein paar Posts oberhalb: https://forum.pfsense.org/index.php?topic=101660.msg567493#msg567493
Würde mich interessieren ob du das Phänomen dann noch genauso hast oder es später oder gar nicht mehr auftritt.

Dass es was mit CARP zu tun hat glaube ich eher weniger. Wäre mir bislang noch nie über die Füße gefallen zudem die Änderungen asynchron gespeichert werden. Sprich der Master schreibt und schickt dann per XMLRPC den Kram an den Slave. Da kanns zu einem Error kommen oder nicht, aber im Normalfall ist trotzdem das Ganze auf dem Master dann beendet und läuft im Hintergrund.

Grüße

[bitboy0]

Ich hab das auf 10 geändert und eben getestet … nach 4 Änderungen (ein "a" an die description einer NAT-Regel angefügt, sonst nix) ist es wieder so ...

Also wirklich sehr strange.

[bakunin]

… bei mir das gleiche Problem.

Die Übernahme der Einstellungen dauert zum Teil mehr als 40 Sekunden. (PFSense-Installation nicht auf Speicherkarte, sondern auf HDD - "Max Processes" steht bei mir auf 30).

Erstaunlich ist, dass immer wieder mal eine Einstellungsänderung praktisch sofort durchgeht ...

Grüsse

bakunin

[EmL]

Hi, habs nur kurz durchgelesen, glaube hatte das gleiche Problem auf Alix mit NanoBSD auf CF … hatte damals die Lösung im englischen Forum gefunden:

Mach unter "Diagnostics: NanoBSD" das Häkchen bei "Keep media mounted read/write at all times" rein. Is zwar nicht schön, aber momentan der einzige Weg. Wenns bei Dir doch was anderes ist, kannst Du es ja wieder rausmachen. Auf jeden Fall gehen die Änderungen bei mir wieder so schnell, wie sie vorher waren.

[JeGr]

Mach unter "Diagnostics: NanoBSD" das Häkchen bei "Keep media mounted read/write at all times" rein. Is zwar nicht schön, aber momentan der einzige Weg. Wenns bei Dir doch was anderes ist, kannst Du es ja wieder rausmachen. Auf jeden Fall gehen die Änderungen bei mir wieder so schnell, wie sie vorher waren.

Hi EmL,

wir hatten schon geprüft, ob es am mount_ro/rw lag. Tat es nicht, insofern wird die Änderung sehr wahrscheinlich nichts bewirken. Testen kann aber nicht schaden.

[bitboy0]

Ja, habs getestet und es ändert nichts :(
Aber Danke trotzdem, für jeden Tip

Es fühlt sich so an, als würde ein FIFO vollaufen und im Hintergrund eben nur langsam und STück für Stück abgearbeitet.
Vier Eingaben gehen… die fünfte klemmt... wenn ich dann 20-30 Sekunden warte, dann geht wieder eine oder zwei schnell.
Wenn ich 2 Minuten warte sind wieder 4 schnelle Eingaben drin.

[JeGr]

Hallo Bitboy,

mir lief vor einigen Wochen ein ähnliches Phänomen über die Leber. Kannst du mal testweise den Sync zwischen den Geräten (also auf dem Master auf den Slave) abschalten? Also bei System/HA Sync das Config (XMLRPC) Syncing rausnehmen? Einfach keine IP/User/Pass eintragen. Wie sieht es dann mit Arbeit in der UI aus?