Ich zitiere mich mal selbst:
Vor dem Webhosting läuft ein nginx, der das htaccess nicht beachtet.
Der wird auch das 404 ausspucken, weil die Datei entsprechend nicht gefunden wird.
Die einfachste Lösung dürfte sein, in den Webserver Einstellungen den Haken bei "Intelligente Bearbeitung statischer Dateien" zu deaktiviern.Dann dürfte Apache vollständig übernehmen.
Siehe: https://www.netcup-wiki.de/wik…g#Einstellungen_Webserver
vielen Dank für die Ausführlich Erklärung, hilft mir nur leider nicht ganz so ... das ich mit Blech mehr Glück hätte, dachte ich mir schon fast. Problemn ist nur, dass glaube bis auf "Het zner" kaum jemand noch Blech hinstellt.. da es halt viel Strom frisst im vergleich zur Abgabe der Leistung..
Es gibt noch andere Anbieter von Blech, die ebenfalls sehr günstig sind, teilweise aber nicht die gleichen Leistungen anbieten.
Du kannst ja den Gameserver auf dem VPS betreiben, oder dir für 11 bis 16€ einen AMD RootServer mit Laufzeit von einem Monat bei Netcup bestellen.
Ist das einfach nur Glück,
Nö, das ist Computer Science.
Die Xeon CPUs, die Netcup einsetzt (Intel Xeon Gold 6140), sind darauf optimiert viele Kerne zu haben (18 Stück) - die einzelnen Kerne takten dabei nicht so hoch (2,3 GHz).
Üblicherweise sind Gameserver weniger auf Multithreading programmiert und profitieren deshalb von höherer Single Thread Leistung anstelle von Multi Thread Leistung. Wenn die Single Thread Leistung nicht stimmt, dann gibt es Probleme mit den Ticks des Gameservers.
Jetzt haben die AMD Epyc 7702 CPUs zwar auch nicht mehr GHz, aber man kann seit Jahren nicht mehr GHz gegeneinander Rechnen. Interesanter sind hier die Instructions Per Cycle und Benchmarks. Benchmarks sind allerdings vorsichtig zu betrachten, denn Benchmarks nutzen meistens den Turbo Boost, Netcup VMs haben den aber nicht garantiert. Bei Single Thread Benchmarks liegt AMD aber vor dem Intel Xeon.
Generell gilt die Empfehlung bei Spielen: Blech bzw. dedizierte Server machen da mehr Spaß.
Warum kauft Netcup solche CPUs?
In der Vergangenheit war das eben ein Kompromiss - und für Netcups Geschäftsmodell sind mehr Kerne je Maschine mehr wert, weil die Kerne als garantierte Ressourcen verkauft werden.
Anmerkung nebenbei: Intel hatte viel mehr zu kämpfen wegen der CPU Bugs Spectre und Meltdown, dafür sind entsprechende Patches im Betriebssystem und Hypervisor vorhanden, die einiges an Leistung fressen. Das kann auch dazu führen, dass AMD VPS hier besser abschneiden, als Intel RootServer.
Betreibt jemand zufällig eine Gitea Instanz auf dem Webhosting oder kennt sich sehr gut aus und kann mir paar Kickoff Tipps geben?
Das wird leider nicht funktionieren. Gitea startet seinen eigenen Webservice, den wirst du so nicht unter einem Webhosting Produkt starten können. Dazu braucht es ja auch einen sshd Service. Für Gitea wirst du um einen eigenen Server nicht herum kommen.
Nicht zwingend - Gitea kommt auch ohne eigenen SSH Server aus, funktioniert auch über das OpenSSH vom Betriebssystem oder vollständig über http ohne ssh.
Allerdings besteht Gitea aus einer Go Binary und ist kein PHP / Python - daher funktioniert es nicht auf dem Webhosting.
Wenn auf dem Webhosting Git allerdings zur Verfügung steht, kannst du über SSH das auch nutzen - ohne jegliche Klicki-Bunti Oberfläche oder Git-Server.
Ansonsten gibt es noch das gute alte Github oder Gitlab.
Wie sieht denn deine Relay Config aus?
Edit: die Netcup Mailserver nehmen nur Mails an, wenn sie auch im MX Record stehen. Somit fällt die Verwendung eines Proxies vor den Netcup Servern leider aus.
ns 1/2 [dot] [gelöschtem Individum] [dot] de habe ich nicht gesetzt.
Die sind aber gesetzet.
id 51059
opcode QUERY
rcode NOERROR
flags QR RD RA
;QUESTION
ns2.[gelöschtem Individum].de. IN A
;ANSWER
ns2.[gelöschtem Individum].de. 21599 IN A 185.216.179.172
;AUTHORITY
;ADDITIONALDie Denic mag nur PublicKeys und generiert sich daraus die DS Records selbst.
Ich benutze immer die Public KSK Keys mit Algorithm 8.
Euch und dem gesamten Netcup Team auch ein gesundes neues Jahr 2021.
DS-Lite Anschlüsse haben immer öffentliche IPv6 Adressen.
Dein Anschluss hat aber kein IPv6, nur IPv4 oder?
Ich denke dann wirst du mit 6tunnel -6 nicht weiterkommen. Du brauchst einen VPN, der vom Raspi eine Verbindung zum vServer aufbaut und regelmäßig Heartbeats durchsendet. Im VPN Tunnel hast du dann eine RFC1918 Adresse, die kannst du auf dem vServer über DNAT oder über einen Proxy dann zugänglich machen.
Huhu. 10.0.0.1 ist mein "Gateway"-Server / SSH-Jumphost. Der lässt sich von allen anderen Servern im VLAN anpingen und ist da auch überall per SSH erreichbar.
Okay, das ist gut.
Ich habe da noch ein paar Troubleshooting Ideen - aber lass den Support da erstmal 'drüber grübeln, ist ja im Rettungssystem reproduzierbar.
die Leute verschwanden irgendwann
Manche Probleme lösen sich von selbst. Scheinbar ist er auch noch stolz darauf.
Ich würde jede Station, beginnend vom vServer einmal durchpingen - ob die Tunnel überall funktionieren.
Als nächstes würde ich dann die Firewalls prüfen, inklusive der sysctl Einträge.
Kannst du uns ein bisschen mehr über dein Setup verraten, welche Tunnel, wie funktioniert dein Portmapper genau (einfach nur iptables?).
So wirklich steige ich bei deinem Setup noch nicht durch.
Danach ein weiteres Script mit dem Namen "AD_malware" sendet meine Daten durch Port53 woanders hin?
Wo wir wieder beim Punkt: Verständlichkeit von Sprache wären...
Das hat ja vorher komplett gefehlt.
Nur im Rettungssystem.
mfnalex gucke mal bitte, ob die MAC Adresse des VLAN Interfaces mit dem im SCP übereinstimmt.
Die SRC Adresse stimmt. Was ist mit 10.0.0.1? Ist der im VLAN, ist das Interface von dem Rechner oben, hat der die richtige Subnetzmaske etc.
Sind die unterschiedlichen VLANs zugeordnet?
Zumindest bei 10.0.0.3 sieht alles gut aus. Ich würde den Fehler erstmal bei 10.0.0.1 suchen / vermuten
In einem weiteren Terminal kannst du ja tcpdump -nni ens4 icmp ausführen und gucken, ob der Ping in das Netzwerk reingeht.
Wenn bei 10.0.0.1 auch alles stimmt, ist das ein Fall für den Support.
Genau, hab keine root server nur webhosting. Wie gesagt unter docker mit Apache funktioniert es. Habt ihr noch weitere Ideen?
Funktioniert es da auch explizit mit allen Varianten des Slashes am Ende?
Die NE Flag ist nämlich so eine Sache von Apache 2.2 - bei 2.4 wurde das entfernt.
Ich weiß leider nicht, welche Apache Version im Webhosting eingesetzt wird.
Evtl. könnte man es nochmal mit aktiviertem nGinx versuchen und ihm (statt htaccess) das routing überlassen - nur mal zum Testen, ob es am htaccess/Apache liegt, oder doch in der Routing-Konfiguration:
Er hat ein netcup Webhosting. Ich denke da hat er keinen Zugriff auf die Location Blöcke von nginx.
Naja jetzt ist es ein Error 500, zumindest bei /gallery- hingegen bei /gallery/, man beachte den letzten Slash funktioniert es.
Deutet für mich darauf hin, dass es in der htaccess klemmt.
Das kann an dem Regex liegen (der Punkt führt zu mehreren Matchens), oder an dem fehlenden NE Flag liegen RewriteRule . /index.html [NE,L] - dafür sind meine mod rewrite Kenntnisse aber nicht ausreichend.
Bin da ehrlich gesagt überfragt ob das nen Unterschied macht.
Google spuckt nix nennenswertes aus für LVDS + latency oder LVDS + delay
Scheinbar gibt es hier auch sowas: https://www.reichelt.de/hdmi-repeater-…03-p161867.html und mehr* aber da geht es ab 10 bis 20m erst los.
Ich gehe davon aus: 8m sollten problemlos gehen.
Hast du noch eine Idee?
Ich würde tatsächlich noch etwas warten, bis die Einstellungen vom Webhosting übernommen wurden.
Bei mir funktioniert es bereits. Ich werde auf /#/gallery weitergeleitet.
Anti Spam Erkennungen
DerRené ich würde mal sagen, das hat geklappt. Es gibt weniger Anti Spam und mehr Spam.
