Beiträge von tab

  • EURid / "WHOIS-Email" für .EU Domäne?

    Zitat von gunnarh

    Danke MichaelOF für das Status-Update / Insights.

    Ehrlich gesagt weiß ich nicht, was an meinem Vorschlag aus 2018 so aufwändig in der Umsetzung wäre. Im CCP statt nur 2 E-Mail-Adressen (Vertragspartner, Rechnungen) einfach noch 2 weitere (Notfallkontakt, Whois) hinzuzufügen und initial aus Vertragspartner zu übernehmen aber ab nun änderbar zu machen würde die laufenden Probleme in dieser Causa zu 99% lösen und wäre doch hoffentlich auch vom Junior-Developer mit einem Personentag Aufwand umgesetzt.

    Manche Dinge muss man einfach nicht verstehen. Wahrscheinlich ist es weniger aufwändig für netcup, wenn sich die Kunden einen weiteren Account für .eu und sonstige Domains zulegen und die entsprechenden Domains dahin transferieren.

  • NetCup Domain für GitHub Page

    Wie getestet? Die üblichen Verdächtigen wie den lokalen DNS-Cache mal geleert? Ansonsten merkt sich der Cache die IP-Adresse bis zu einemTag, wegen der Default TTL für DNS-Records bei netcup. Offensichtlich löst deine Domain bei dir lokal ja noch auf die alte IP auf (Domainparker).

  • Das längste Thema

    Also ich werde mir jetzt sicher kein Webhosting 2000 extra für deine Tests bestellen. Nextcloud dürfte auf beiden eher humpeln als laufen. Klar, wenn man nur Datei und Kalendersync benutzt mag es "laufen", aber dafür gibt es auch etwas ^^ schlankere Software. Bei einer Nextcloud Talk Videokonferenz mit 4-6 Personen mag es schon ganz anders aussehen. Was soll denn letztlich drauf laufen? Das sollte dann auch die Testsoftware sein.

  • Das längste Thema

    Ich glaube es eher schon, dass gemischt wird. Das haut ja sonst bei größeren Webhostings mit dem RAM nicht mal ansatzweise hin. Haut zwar sowieso nicht hin, weil so viele 1000er wirds nicht geben, dass die RAM-Garantie nicht zig-fach überbucht wird. Aber ich hatte jedenfalls schon mal zwei unterschiedliche Tarife auf dem selben Server.

  • Ich bekomme seit gestern keine Token mehr per E-Mail zugeschickt

    Bei der Größenordnung von 15 Minuten Verzögerung könnte es tatsächlich an Greylisting liegen. Bei mehreren Stunden eher nicht ;). Das sollte allerdings bei den Tokens nicht passieren. Der Mailserver, über den diese verschickt werden (smtp.netcup.net) hat derzeit einen Senderscore von 99. Für den Versand wird zum Glück nicht eine der zahlreichen IPs des "relay.yourmailgateway.de" verwendet - sofern sich das nicht in den letzten Monaten geändert hat oder jedenfalls seit ich 2FA per TOTP aktiviert habe. Am Senderscore sollte es hier also eigentlich nicht liegen. Meine Testmail gestern lief über eine dieser IPs und wurde dann dank miesem Senderscore "greylisted", also zunächst auf später vertröstet und erst beim zweiten Zustellungsversuch dann akzeptiert.

    Die heutige Testmail von der selben Adresse per netcup Webmail kam heute ohne Verzögerung an. Die lief allerdings über eine andere der zahlreichen IPs von relay.yourmailgateway.de, nämlich 194.59.206.189, mit einem Senderscore von derzeit 48. Also ein deutlich weniger schlechter Senderscore als die IP von gestern, wenn auch nicht wirklich gut.

  • Das längste Thema

    Wäre denkbar, dass man mit PHP exec() per ls-Befehl die Home-Verzeichnisse sehen kann (nicht deren Inhalte). Über den Webserver ist man ja nicht chrooted. Probiert habe ich es aber noch nicht, muss also nicht klappen. Bei anderen Hostern (z.B. 2+2) konnte man die Home-Verzeichnisse früher sogar direkt in der SSH-Konsole sehen, da gab es keine chroot. Ob es heute bei I0N0s immer noch so ist weiss ich aber nicht.

  • Das längste Thema

    Zitat von ASS

    Ohne die Info wieviele Webhostings dann darauf laufen, ist die Info leider nur begrenzt Aussagekräftig...

    Wieviele es sind, kann man eventuell noch rausfinden. Das verbessert dann zwar die Informationslage etwas, aber ohne Info, was für welche es im Einzelnen sind, bleibt es schwierig.

  • Das längste Thema

    Zitat von notfound404

    Ich habe es jetzt Mal mit einem Extremfall ausprobiert, nämlich nextcloud. Auf dem Webhosting 1000 natürlich suboptimal, weil PHP Memory Limit 128MB max. statt der empfohlenen 512 MB.

    Auf die Schnelle konnte ich es nur mit ein paar hundert kleinen Bilddateien testen, aber gefühlt läuft es auf dem Webhosting 1000 tatsächlich flüssiger als auf einem VPS Piko mit Apache. Vielleicht hab ich den aber auch nicht optimal konfiguriert.

    Überrascht mich fast ein wenig, aber gut, der Piko hat eben nur 1 Core und 1 GB RAM - was hinter dem Webhosting 1000 steckt weiß ihc nicht.

    Die vCores sind halt eine Wundertüte. Für den Piko kann ich sagen, das ist grob ein nur halb so starker vCore wie ein vCore eines VPS 1000 oder größer. Von RS-vCores ganz zu schweigen. Wie das bei den unterschiedlichen Webhostings genau aussieht weiss ich nicht. Weder wieviel Power die Cores haben noch wieviele jeweils minimal bzw maximal gleichzeitig benutzt werden können. Allerdings sind die Webhostings natürlich schon so konfiguriert, dass sie aus den Ressourcen gute Performance rausholen. OPCache, nginx als Reverse Proxy usw.

    Die Pikos verwende ich normalerweise nicht für Webhosting, eher für Monitoring, Resolver oder ähnliches. Höchstens z.B. für die Ausgabe der von Munin erzeugten Webseiten, auf die dann auch nur ich Zugriff habe. Ansonsten hätte ich da schon gern mindestens 2GB oder besser 4GB RAM.

    Ich werde mal spasseshalber ausprobieren, ob ich ein komplettes Hostingpanel wie z.B. Keyhelp darauf installieren kann und halbwegs akzeptabel zum Laufen bekomme. Ohne eingerichteten Swap wird da schon die Installation scheitern wegen zu wenig RAM. Natürlich hat man dann auch Sachen mit installiert, die es eigentlich nur für die eine Website nicht bräuchte.

    Mit einem von den Specs her ähnlichen VC1-1 ( 1 vCore, 1 GB RAM) von Strota hat das mit Swap immerhin so lala geklappt. Im Normalbetrieb lief es gut, gelegentlich hat er dann mal alle paar Wochen die IPv6 verloren, aber eine kleinere Demo-Website (mit MariaDB Datenbank) lief immerhin durchaus akzeptabel darauf. Die würde aber auch auf einem Webhosting 1000 laufen.

  • Das längste Thema

    Zitat von notfound404

    Das ist natürlich richtig. Aber wie würdest Du bzw. jemand generell es einschätzen, wenn man es jetzt nur unter dem Gesichtspunkt der Performance für normale PHP-Skripte betrachtet? Ist da das Webhosting, insbesondere das 1000er ohne garantierten RAM, einem preislich vergleichbaren VPS, sagen wir mal dem Piko oder Nano, eher über- oder eher unterlegen?

    Kann ich dir so ohne weiteres auch nicht sagen. Was genau soll das Webhosting oder der Piko/Nano ausführen. Was sind für dich normale PHP-Skripte? Ein CMS, also relativ komplex, bestehend aus vielen einzelnen PHP-Skripten oder eher was einfaches? Wenn beide als Webserver agieren sollen, kommt beim VPS halt dazu, welches OS und welcher Webserver installiert wird und wie man das System konfiguriert. Beim Webhosting ist es einfach, da hat man nicht so viele Möglichkeiten zur Optimierung.

    Wenn du einen einen konkreten Testfall hast, ich hätte einen Piko und ein Webhosting 1000 notfalls für Tests zur Verfügung, die haben gerade nichts produktives.zu tun. Auf dem Piko ist derzeit nur das Debian 12 Minimal Image von netcup installiert, also noch nicht mal PHP und ein Webserver.

  • AOL Mail noch zeitgemäß – sollte ich meine Adresse überall ändern?

    Ich habe zwar ein halbes Dutzend Server, von denen jeder so installiert ist, dass er technisch in der Lage wäre Mail zu empfangen und zu senden von meinen Domains, aber für meine derzeitige Noch-Hauptdomain empfange und versende ich Mail über die grüne Mailbox aus Berlin. Die 2,50€ / Monat ist es mir wert.

    Völlig unabhängig von netcup, wichtig für die Kontakt-Adresse ;). Bisher ohne jegliche Probleme, Mails an wen auch immer zuzustellen. Zumal ich da noch Mails für 50+ weitere Adressen drüber versenden könnte, zuverlässiger als ich es mit meinem Haupt-Mailserver oder einem der anderen jemals könnte. Zudem gibt es noch ein paar andere Goodies im Paket oben drauf, die ich aber derzeit kaum verwende, z.B. Videokonferenzen, Kalender, Adressbuch.

  • Cron Geplante Aufgabe Ausführung Python script

    Wenn das ein RS oder VPS ist, dann ist das zunächst ihr ganz persönliches Problem. Dazu müsste man dann konsequenterweise sagen, dass so ein Server generell keine gute Idee ist ;) . Eine wesentlich schlechtere Idee, als shell_exec() in einem Cronjob zu benutzen um ein Python-Script ausuführen, das man ansonsten halt einfach direkt ausgeführt hätte. Oder Plugins im Wordpress oder auch in anderen CMS zu benutzen, ohne den Source-Code genau anzuschauen.

    Eigentlich schon ein CMS an sich zu benutzen, das man nicht selbst geschrieben oder und bis ins letzte Detail auf Sicherheitslücken geprüft hat. Naja, wer hat das schon? Ich nicht. Die CMS-Entwickler eher auch nicht. In der Regel wird das dann auch der Weg sein, auf dem eine Malware überhaupt in ein selbst geschriebenes Python-Script reinkommt, von trivialeren Ursachen wie schwachen FTP-Passwörtern mal abgesehen. Aber wenn jemand per FTP in den Account kommt, dann braucht man sich über Sicherheit oder Unsicherheit irgendwelcher PHP-Funktionen sowieso keine Gedanken mehr zu machen.

  • Cron Geplante Aufgabe Ausführung Python script

    Zitat von Hille

    Man kann damit zum Beispiel ne Web Shell ausführen. Ist der Server dann nicht sauber konfiguriert, kann man schlimme Sachen damit machen.

    https://github.com/artyuum/simple-php-web-shell

    Man kann mit vielen Dingen schlimme Sachen machen, wenn der Server nicht sicher konfiguriert ist. Bei einem Shared Webhosting würde ich als Kunde davon ausgehen, dass der shared Server inklusive der aktivierten PHP-Funktionen sicher konfiguriert ist, sonst würde ich ihn nicht benutzen wollen.

    tiekoetter: Ich verstehe die Frage auch durchaus so, das es sich hier um ein netcup Shared Webhostingpaket handelt und nicht um einen VPS oder RS. Immerhin sind wir hier im Bereich CCP, was mit auf einem VPS oder RS laufenden Cronjobs nichts zu tun hat.

  • Das längste Thema

    "KI" Ist halt bei aller Liebe ein sehr zweischneidiges Schwert, da KI momentan fast überall als Lösung für alle Probleme angesehen wird. Wer die KI trainiert, bestimmt sozusagen die Wahrheit, weil sehr viele Menschen einer KI, die vermeintlich alles weiss, einfach alles glauben. Wenn die KI sehr sorgfältig und umfassend trainiert ist, mag das noch angehen, aber zumindest hier beim netcup Chatbot ist das ja noch nicht (aber hoffentlich bald) der Fall. Momentan kommen noch falsche Antworten und sehr viele Hinweise auf den Support und das (oder den? ^^ ) Kontaktformular. Für diese Hinweise bedarf es keiner KI bzw sie sollten nur selten gegeben werden müssen, sonst ist ja nichts gewonnen bei der Supportsituation.

    Und wenn jetzt Dutzende neue Webhosting-Benutzer versuchen, ihr memory_limit oder sonstige PHP-Einstellungen per .htaccess zu setzen, dann wird ihnen der Apache was husten. Das wird die Zahl der Tickets eher nicht reduzieren.

  • Abuse - Vorgang

    Zitat von marklo

    Es würde ja reichen, wenn ich rasch per FTP die - vermutlich nur teilangelegte - Zip-Datei löschen könnte...

    Auf jeden Fall DANKE für die Anteilnahme...

    Darauf wird es auch letztendlich nach Kontakt zum Support hinauslaufen. Bliebe natürlich der Notfall-Support. Ich weiss aber nicht, ob das in so einem Fall kostenpflichtig wäre

  • Abuse - Vorgang

    Dass die Behandlung von Over-Quota mehr als suboptimal ist, habe ich ja schon öfter hier geschrieben. Die derzeitige Behandlung funktionier sehr schlecht, wenn sehr schnell sehr deutliche Überschreitungen des Speicherlimits passieren. Gesperrt wird erst ab 150% soweit ich mich erinnere. Bei 100% sollte eine Warnung per Mail rausgehen. Der genaue Ablauf wurde mal seitens netcup hier im Forum erläutert. Das große Problem dabei ist, dass die Speicherbelegung nur einmal(?) pro Tag geprüft wird. Damit ist natürlich bei einem solchen Kopiervorgang oder auch bei einem schnell vollaufenden Log reichlich Zeit, die 150% zu reissen, bevor die Überschreitung überhaupt bemerkt wird. Das Kind liegt im Brunnen, ohne dass der Kunde eine Chance hat, das noch zu verhindern. Möglichkeiten das zu verbessern gäbe es sicher reichlich.