Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - u.n.known

#1
When enabling auth in the postfix service, it complains about:

warning: /usr/local/etc/postfix/smtp_auth: logical line must not start with whitespace: " username:password"

when looking into the file, there is a leading whitespace.

When I'm looking in the config.xml there is no leading whitespace (as well as in the gui of opnsense)

I think it looks like a but

cheers

marc
#2
German - Deutsch / Re: Unboumd Interfaces
November 13, 2021, 01:27:44 PM
Ja, die Empfehlung ist nicht nur die von franco... Grundsätzlich sollte/muss alles nicht benötigte abgeschaltet werden. So ist das bei mir auch... NUR: Wenn ich halt das Binding von unbount an das WLAN-Interface deaktiviere, dann resolvd er nicht mehr... Zumindest auf dem LAN. Auf localhost resolved er noch. Und ja, UDP/TCP für DNS ist vom gesamten LAN-Netz erreichbar, also freigegeben. Nur halt: WLAN in unbound zusätzlich an, apply gedrückt dann geht alles. WLAN als interface aus der unbound-Konfig rausgenommen (haken weg), apply => Keine Resolution mehr... :(

#3
German - Deutsch / Unboumd Interfaces
November 13, 2021, 09:46:38 AM
Eine opnsense mit einem WAN und einem LAN Interface. Wenn ich unbound auf dem WAN interface deaktiviere antwortet unbound nicht mehr... ok, wenn das einen netzwerkplan braucht male ich einen. [emoji2] Screenshots kommen


Gesendet von iPhone mit Tapatalk
#4
German - Deutsch / Unboumd Interfaces
November 13, 2021, 07:28:24 AM
Eigentlich brauche ich auf dem WAN Interface keinen DNS Server laufen, muss ich aber...
Die opnsense hängt in zwei Netzen. WAN und LAN. Wenn ich nun den unbound nur auf dem LAN Interface aktiviere, nicht auf dem wan dann resolvt er nicht mehr. Er lauscht noch auf dem lan Port aber antwortet nicht mehr. Aktiviere ich den WAN im unbound dann geht wieder alles...

Ist das so gewollt?!? [emoji38]


Gesendet von iPhone mit Tapatalk
#5
Oh doch... Das Logging ist nicht aktiv... Das hat mich ja so irritiert.
Das betrifft die Regelnummern 64 und 65... Aber beide haben kein Logging aktiviert... :(
#6
Hallo Franco,

danke für den Hinweis. Nur kann ich bei den Regel ja lediglich das Logging Aktivieren (Log packets that are handled by this rule) ABER: Wenn ich mir die Regel anschaue, die einschlägig ist, ist da kein Haken.. Sie dürfte eigentlich nicht loggen... Oder steht das wo anders? Wo kann ich das dann noch ausschalten?
#7
Hallo,

kann man das was in der Firewall-Live-View angezegt bekommen eigentlich auch mit Ausschlüssen versehen?

Hab den Traffic vom Admin-Frontend per NGINX anderweitig verfügbar gemacht. Jetzt: Hab ich den Traffic vom nginx zum admin-frontend ständig drin. Und gerade wenn ich die Live-View anschaue, dann pumpt das ja ordentlich durch, weil es sich selbst ja auch darstellen möchte... Und das vervielfacht ja alles.

Ich würd gern das was von dem nginx zu dem port auf einem nicht-WAN Interface geht ausschließen. Kann man das irgendwie bewerkstelligen?
#8
German - Deutsch / Nginx ssl_verify_depth
November 23, 2020, 08:48:45 AM
Moin, bin die ganze Zeit am suchen, ob man dies setting über die ui setzen kann. Vielleicht bin ich nur blind.

Hab halt eine self signed root ca und zwei intermediates bis hin zum Client cert, mit dem ich mich authentifizieren muss. Bislang komm ich nur zu einem 400er beim request. Denke mal, dass es an der verify depth liegt...

Cheers
M.
#9
Hi Franco,

meine wiederholte Frage, war die: "wie testet ihr, wie ist eure Strategie/QA"?
Ach ja, um es zu quantifizeren: Die Frage war etliche male von mir in diesem Thread von mir gestellt worden.
UND NEIN, ich hab nicht um Hilfe nachgesucht!! (um auch dies zu quantifizieren)

"Prompt" ist übrigens auch etwas was man unter qualitativen und quantitativen Aspekten beleuchten sollte! ;)

Für mich ist damit klar geworden, wie die Test-Strategie aussieht...


#10
In den Docs selbst ist kaum was zu tests zu finden. In den Makefiles gibt's was zu Regressionstests. Damit endet das Thema Tests in der Doku.
Ja acme.sh gehört zu einem Plugin, war aber auch nur ein Beispiel von zweien, das andere gehörte in den Core.

Tests gehören zum Alltag von Softwareentwicklern und, ja, auch zu Community-Projekten. Es sei denn, man steht auf dem Standpunkt, dass Community-Projekte so cool sind, dass sie ohne Tests auskommen.
Sorry, das kann man durchaus anders sehen.

Naja, mittlerweile hab ich meine Portweiterleitungen wieder gefixt, die offenbar nichts mit meiner Config zu tun gehabt haben. Es war ein Core-Modul, was die alten Configs ignoriert hat, nach Neuanlage der Rules lief es durch. Aber gut, brauchen ja keine Tests, sind ja community...  ;D 8)
#11
Ja, natürlich weil es ein community Projekt ist, stelle ich die Frage nach z. B. Tests. Heißt ja nicht, weil etwas community ist kommt es ohne aus. Eher im gegenteil. Viele Projekte aus der community sind deutlich stabiler und besser abgesichert als kommerzielle Produkte. Das liegt gerade daran, dass die maintainer ein hohes Interesse an der Stabilität haben. Insofern habe ich gehofft, dass ich auf die Frage auch ein einfaches "schau mal, hier sind die Tests und so arbeiten wir hier mit ihnen" als Antwort bekomme.
Wenn die Leute von Cisco oder sophos einen nicht so guten Job machen, sollte uns das nicht wirklich interessieren, auch sollten wir uns dann daran auch nicht messen.
#12
Wir investieren einen hohen Anteil unserer Arbeit unter anderem in Tests, das ist nicht wenig, um die testpyramide weitestgehend abzudecken. Eine Firewall ist sicher nicht das einfachste System, um es komplett unter test zu stellen. Aber für ein dermaßen wichtiges System ist es unerlässlich. Vor allem, wenn man auch noch einen gewissen kommerziellen Erfolg haben möchte.

#13
Was ich bemerkenswert finde ist, dass anscheinend keiner die Frage beantworten mag.

Gibt es vor releases automatisierte Tests? Gibt es Testpläne? Gibt's überhaupt eine QA oder ist die so streng geheim, daß keiner was drüber weiß?

Aufgrund der anderen Fehler, hier zum Beispiel das Thema mit der Acme.sh würde ich schon fast dahin tendieren, das maximal unit tests aber kein test auf das Gesamtsystem, geschweige denn funktionale Tests oder e2e gemacht werden. Etwas was mich langsam unruhig macht
#14
Ich hab genug Redundanz, dass ich erstmal auf die eine verzichten kann.

Allerdings stellt sich für mich immer noch die Frage nach QA. Nachdem immer wieder ähnlich gelagerte Themen auftreten, fragt sich ob das dann letztlich eine gute Wahl war. Features hin oder her, wenn ein Update, sei es plug in oder firmware, ein Spiel mit dem Feuer ist, dann kommen einen solche Gedanken. :(
#15
Bei mir waren es die Versionen ebenfalls 2020.1.7 auf 8. Nur nicht auf Blech.

Aber letztlich ist die Frage auch nicht die, warum es jetzt nicht geht. Das bekomme ich schon wieder hin.
Meine Frage bezog sich eher auf die Qualitätssicherung mittels Tests.