https://lmgtfy.app/?q=shopware+mysql+8
https://forum.shopware.com/t/mysql-8-0-support/52723
Die letzten Beiträge sagen, es geht ohne Probleme.
Posts by H6G
-
-
deswegen bitte ich um eine Erklärung, wie genau das funktioniert.
Links Mitte Rechts @ TXT google-site-verification=gaaaaaanzLangerText Dann auf speichern klicken.
Die Meldung, dass die Domain unbrauchbar wird, kannst du dabei ignorieren.
-
Nein, ernsthaft: Unabhängig von diesem Problem will ich endlich mal testen, wie gut sich eine hochgelobte FRITZ!Box 4040 unter OpenWrt macht.
Letzte Version von 2019... https://forum.openwrt.org/t/fritz-box-4040-experiences/64487
-
Aktuell läuft das System in einer Testumgebung (VM)
Und diese Testumgebung hat 2001:db8:1::/64 als funktionierendes IPv6 Subnetz?
-
ahh check jetzt hab ich es glaub ich danke
Supi. Kleiner Hinweis: die Routingtabelle wird nach einem Neustart wieder zurückgesetzt.
Du könntest dir damit ein Script anlegen, was beim Start dir die notwendigen Daten in die Tabelle schreibt.
natürlich statt der ext.IP die wo ich hin will
In deiner Zeichnung stehen leider nicht die internen Tunneladressen und die RFC1918 Adressen auf der rechten Seite sind auch nicht vollständig beschrieben. Das macht die Kommunikation etwas schwieriger.
-
doch jetzt bekomme ich bei tracert ein time out
Auf dem Gegenstück zum IPSec Tunnel, brauchst du natürlich die entsprechenden Rückrouten für das 10.0.0.0er Netz.
Edit: außerdem ist via 185....ext.linux kompletter Murx. Du willst doch durch den VPN und durch den Tunnel routen. Da hat die Public IP von keiner Maschine etwas zu suchen.
-
Erste Stoßrichtung ist definitiv Signal (wohl via Verknüpfung mit signal-cli), danach ggf. E-Mail und IRC. Die Sammlung existierender mqttwarn-Plugins gefällt mir als Grundlage eigentlich recht gut, die Nutzerbasis scheint nicht allzu klein zu sein.
Reicht es dir, wenn ein entsprechender Daemon ein Executable aufruft mit dir bekannten Aufrufparametern?
Da kann man dann ein Go-Executable ranhängen, ein Bashscript, oder ein Python Script
-
Der Traceroute zeigt, dass die Pakete ins Internet gehen, und nicht durch den Tunnel.
Du musst auf dem Linux entsprechende Routen anlegen:
ip route add Netz/CIDR via IP
Auf dem Gegenstück zum IPSec Tunnel, brauchst du natürlich die entsprechenden Rückrouten für das 10.0.0.0er Netz.
Wenn du komplexere Tunnel hast, solltest du über ein Routing Protokoll nachdenken (OSPF, RIP, IS-IS und was es da nicht noch so alles gibt)
-
Drei Fragen:
a) wo läuft das ganze?
b) Warum DynDNS?
c) entsprechen die Configs der Realität?
-
die Python-Fehlermeldung ModuleNotFoundError: No module named '_ctypes'
Also bei MS-qttwarn wundert mich das nicht.
In welche Richtung soll er denn ein Notify geben?
-
allerdings ohne, dass dafür ein Eintrag im Protokoll vermerkt wurde.
Wenn SCP Protokoll offline, dann nix Eintrag im Protokoll.
-
Nur kurz der Vollständigkeit halber: In dem Blogpost geht der Kollege hin und weißt seinem Netzwerkinterface die Adresse als /128 zu, nicht als /64. Damit liegt sie natürlich außerhalb des /80 Netzes für die Bridge. Das wäre IP-mäßig sauber. Aber wie gesagt: Offenbar ein rein kosmetisches Problem.
Die Netzmasken sind nur für die Routing Tabelle wichtig.
Je spezifischer eine Netzmaske ist - sprich desto kleiner das Netz ist, was sie abdeckt, desto höher die Priorität in der Routingtabelle.
Probleme gibt es nur, wenn die Netzmasken identisch sind. Überlappende Masken sind kein Problem.
Das sind zumindestens die Standardregeln die im Linux Kernel, im BSD Kernel, unter Cisco iOS funktionieren.
Andere Implementationen können sich dort anders verhalten, allerdings sind mir solche nicht bekannt.
-
Ich verwende Archlinux. Leider weiß ich nicht auf was Arch basiert.
Arch basiert auf Arch
- ist eine eigenständige Distribution die ohne eine bestehende Basis gebaut wird.Vielleicht wurde in Apache das Modul nicht einkompiliert.
Eigentlich sollte das aber vorhanden sein: https://archlinux.org/packages/extra/x86_64/apache/files/
Guck mal bitte, ob die Datei /usr/lib/httpd/modules/mod_proxy_wstunnel.so existiert.
Mir würde eine Aussage von netcup reichen ob es sein kann das meine idle websocket Verbindung nach 60 Sekunden von netcup getrennt wird.
Das kann ich auf jeden Fall ausschließen.
-
Der Game-Client ist in c++ entwickelt und wird mit emscripten zu wasm compiliert.
Das ist ja mal mega.
Nutzt du diese API? https://emscripten.org/docs/po…p-sockets-over-websockets
dann kommt eine Fehlermeldung das proxy_wstunnel nicht geladen ist
Das ist echt ungewöhnlich.
Eigentlich sollte es damit gehen:
Gibt es einen Grund, warum du Apache nutzt?
Es gibt viel bessere Proxies, z.B. nginx - der kann auch den Client ausliefern.
Wenn Apache hier wirklich das Problem ist, würde ich es mit nginx probieren.
Das könnte auch von der Performance interessanter werden.
Ich habe aber noch nie mit Websockets unter nginx gearbeitet.
-
Wie frank_m schon angedeutet hat ist das möglicherweise auch gar nicht mal die beste Lösung (?).
Ich sehe das Problem nicht. Ggf. hat sich Frank da verguckt.
Ich benutze hier immer ein Script, welches mir die Adressen zuweist, nachdem das Netzwerk durchlief.
Die IPv6 kannst du doch auch in der LXC Config für die Bridge zuweisen - evtl. sogar direkt unter /etc/network/interfaces
Die Bridge selbst steht nämlich solange auf "down", bis der erste Container gestartet ist. Und dieser Zeitpunkt kann halt nach "post up" von ens3 liegen.
Ich würde sagen, da stimmt etwas in der Logik bzgl. der Startreihenfolge nicht.
-
Hallo werto87 und herzlich Willkommen im Forum,
der Editor unter dem Forum hat bestimmte Funktionen für Quelltexte etc.
Bitte nutze diese Funktionen für Config Dateien und Logs - das macht deinen Beitrag übersichtlicher.
Mir fehlt auch ein bisschen die Beschreibung, was du da eigentlich vor hast.
Das Serverprogramm, ist das selbstentwickelt?
Und du möchtest mit dem Apache einen Websocket als Proxy anbinden, verstehe ich das richtig?
Zur eigentlichen Problemlösung:
- Hast du im Apache das Modul proxy_wstunnel geladen?
- Was macht denn der Client (Webbrowser)? Gibt es dort nicht auch Keepalive Optionen?
- In einigen Quellen steht auch was davon, dass einige Browser damit Probleme machen und ein Wechsel des Browsers die Probleme löst. Damit könntest du ausschließen, dass der Server das Problem ist.
-
Als Gateway nutze ich die Public-Adresse die ich der lxcbr0 Bridge zugewiesen habe. fe80::1 funktioniert hier leider (noch) nicht.
Auf dem Host: ip -6 addr add fe80::1 dev lxcbr0 - dann kannst du im Container auch fe80::1 als Gateway eintragen.
Für die initiale Verzögerung hatte ich bisher auch keine Lösung gefunden. Der Ping ist aber ein guter Workaround.
-
Da die Priorität jedoch größer/niederer ist, dürfte der MX von Netcup nie angesprochen werden, solange spambarrier mit höherer Priorität in der Liste online erreichbar ist.
Spammer halten sich nicht an die Priorität.
-
Was nutzt ihr denn so als täglichen Browser?
Firefox - sowohl auf dem Linux Desktop, als auch auf Android. Das letzte UI Update konnte man ja gottseidank per about:config deaktivieren.
Chrome & Chromium wollen immer noch beim Start den Gnome Keyring entsperren. Mitlerweile halten sie sich sogar an das Fensterlayout vom Window Manager.
-
IP-Adressen, Zugriffszeitpunkte und sonstige Metadaten bei der DNS-Auflösung sind also keine "Daten"?
Diese Daten kann jeder authoritative DNS Server sammeln, sprich jeder Domainbetreiber.
Da das ganze sogar unverschlüsselt auf Port 53 abläuft, haben diese Daten dann nicht nur Cloudflare, Google, IBM, sondern auch:
- dein Internetanbieter (Telekom, Vodafone, O2...)
- alle die dazwischen schnorcheln: Cisco, Huawei, HE, Juniper, Palo Alto
Diese Daten fällen für jede Domain egal bei welchem Anbieter an.
Das ist eigentlich kein Argument gegen einen authoritativen DNS Anycast Anbieter.
Und selbst wenn das für einen soweit alles passt, gibt es ausreichend Gründe auf CloudFlare zu verzichten.
Das betrifft jedoch nur den Proxy und die Public Resolver, nicht aber den authoritativen Dienst.
Klar kann man das in Betracht ziehen, wenn man Cloudflare boykottieren möchte.
Für die sachliche Diskussion über den authoritativen Dienst spielt das aber keine Rolle - die Gründe sind in dem Fall ad hominem Argumente.
Was hier noch iO ist, sind die US Geheimdienste - diese sind aber genauso bei Huricane Electric präsent, wo viele aus der Netcup Community sekundäre DNS Server betreiben. Komischerweise steht da nix vonwegen Datensicherheit in den entsprechenden Threads.
Ich möchte einfach nur, dass die Diskussion (um Cloudflare) sachlich bleibt.
