Suchergebnisse

Wenn ich das richtig verstehe müsstest du doch acl blocked_https_dst dstdomain "/etc/squid/blackhttps.txt" deny_info EXTRA_INFO_HTTPS_SITES blocked_https_dst http_access deny blocked_https_dst machen können, oder? Warum hast du einen Teil der Dateien unter /usr/local liegen und einen Teil in...

Moin, wie blockst du denn die https-Seiten? Ich kann mir gut vorstellen, dass du mit squidGuard das gewünschte Ergebnis bekommst. Ich habe zB eine php-Datei, die den Grund angibt, warum geblockt wird (zB "Destination https"). HTH

Ich kann nicht ausschließen, dass ich mir damals auch dieses Ergebnis ergoogelt habe. Bei mir steht allerdings ein höherer Wert in der Config: Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Ich hatt den gleichen Fehler. Soweit ich mich erinnere war es aber eine frühere Version von 16 und nicht 16.0.4. Und bei mir war es ein Bug in nextcloud. Kurze Zeit später kam ein Update raus, welches das Problem behoben hat. Derzeit läuft hier Version 17, vielleicht ist das eine Alternative für...

Wie es laufen muss (und ob das funktioniert), wenn du die Jail auch auf em0 bindest, weiß ich nicht. In dem Fall hätte ich gefühlsmäßig nicht auf em0 gebunden (so habe ich es hier zwar auch, aber der Host selbst hat mit em0 eine IP im selben Netzwerk wie die Jail) sondern auf lo0. Deswegen hab...

Hast du dir mal mit tcpdump angesehen, was mit dem Ping auf 8.8.8.8 passiert? Ich gehe davon aus, dass das Antwortpaket nicht zurückkommt. -> NAT aktivieren über pf.

Ich gehe davon aus, dass du noch aktivieren musst, dass dein Host als Gateway fungieren darf. Ebenfalls wirst du "pf" (oder dergleichen) konfigurieren und aktivieren musst. Genaueres kann ich dir erst später raussuchen, vielleicht hilft dir das aber schon einmal weiter.

Hast du eine /etc/resolv.conf in der Jail?

Mein Beitrag trägt nichts zu Sache bei. Da mir das aber auch ständig passiert und ich danach jedes mal schmunzeln muss, wie "doof" ich bin: grep netif /etc/defaults/rc.conf reicht aus. Hier "cat" einzusetzen macht einfach keinen Sinn. :) Nichts für ungut. :)

Ich habe jetzt mal bapt@ angeschrieben. Das "muss" in meinen Augen pkg können. :) "Es kann doch nicht sein", dass da jeder Admin aussenrum basteln muss. Und für so ungewöhnlich halte ich mein Vorgehen nicht. :)

Danke, aber das erfordert einen aktuellen Portstree, den ich ja nicht habe. Zumal das nicht nur auf dem Host selbst benötigt wird, sondern auch verschiedene Jails laufen. Das bedeutet wohl: Portstree aktuell halten und per nullfs_mount auch in der Jail verfügbar machen.. :(

Moin, danke für deine Antwort. Gelesen hatte ich den Teil von UPDATING schon (auf anderen Maschinen nutze ich ausschließlich Ports). Ich frage mich, wie ein reiner pkg-Anwender hiervon Kenntnis nehmen soll?! Das ist doch ein wenig "kurz gedacht", oder?

Moin, ich benutze auf einem System ausschließlich pkg und ebenfalls ausschließlich die "latest"-Pakete unter FreeBSD 12.0. Bislang dachte ich, dass pkg relativ automatisch das System auf dem aktuellen Stand hält und ich außer "pkg upgrade" nichts ausführen muss um auf dem aktuellen Stand zu...

@veloc möchtest du evtl. noch einmal die Quote-Tags richtig setzen? ;)

Ich kenne das Verhalten nicht und habe schon einige Male aktualisiert. Das erinnert mich ein wenig an Patches, die über die Ports "installiert" werden. Hattest du mal Ports genutzt? Ich gehe jedenfalls davon aus, dass das ein Überbleibsel einer alten Installation ist.

Danke für die Richtigstellung!

Der korrekte Ort ist aber laut pkg-Info /usr/local/etc und nicht mehr /usr/local/etc/mysql ;) Die Meldung heißt (der Tippfehler ist ebenfalls Original): Damit er die Config weiterhin in /usr/local/etc/mysql haben kann, müsste er mysql_optfile="/usr/local/etc/mysql/my.cnf" in /etc/rc.conf...

Ich gehe davon aus, dass das Problem gefunden ist. Die Logdatei sagt ja, dass libglx.so von X.Org geladen wird, du willst jedoch libglx.so von NVIDIA...

Die Ausgabe von ls -l wäre besser gewesen, denn dann hätten wir die Größen der Dateien vergleichen können. Sichere das Verzeichnis "extensions" inkl. Unterverzeichnissen weg. Danach kopierst du den Inhalt von .nvidia direkt ins Verzeichnis extensions. Danach versuchst du es noch einmal.

libva-glx ist bei mir ebenfalls installiert. In /usr/local/lib/xorg/modules/extensions müsste ein Verzeichnis mit dem Namen .nvidia exisiteren. Dort liegt libglx.so drin (in dem Verzeichnis .xorg ebenfalls). Die Größe meiner libglx.so entspricht der im Verzeichnis .nvidia. ich tippe mal...

mysql_upgrade -uroot -p

Ich habe jetzt mal dein Logfile mit meinen verglichen. Aufgefallen ist mir dabei: Bei mir läd er glx vencor= NVIDIA. Bei dir ist es X.Org. Das dürfte das Problem sein. hast du zusätzliche glx-Pakete installiert?

Ich sehe gerade: Kann es sein, dass du die my.cnf von /usr/local/etc/mysql/my.cnf nach /usr/local/etc verschieben musst? Ich hatte das vorhin andersrum geschrieben.

Was mich ein wenig wundert ist die Tatsache, dass du UPDATING befolgst, obwohl du Packages benutzt. Nach meiner Erinnerung war es so, dass pkg automatisch alles befolgt, was in UPDATING steht. Sobald also der Maintainer auf die neue Defaultversion umstellt, sollte das über pkg automatisch...

Ok, ich würde dir trotzdem dazu raten, es in /etc/rc.conf zu belassen. Zurück zum Thema: Ich meine mich zu erinnern, dass es ein Problem gab, wenn ein bestimmtes Paket installiert wurde, bevor/nachdem der nvidia-Treiber installiert ist. Evtl. war es mesa-dri. Hast du das installiert? Ansonsten...