Beiträge von andreas.

Zitat von Paul

VDS mit dedicated Storage wäre wirklich mal was.

Ob da auch tatsächlich ein Platten- oder SSD-Array durchgereicht wird, kann man z.B. mit dem Befehl hdparm (hdparm -I Laufwerk) abfragen.

Auf dem Netcup vServer (RS 4000 G9.5) sieht die Ausgabe wie folgt aus:

hdparm -I /dev/vda
/dev/vda:

Auf dem VDS des Mitbewerbers sieht die Ausgabe wie folgt aus:

hdparm -I /dev/sda
/dev/sda:

ATA device, with non-removable media
Standards:
Likely used: 1
Configuration:
Logical         max     current
cylinders       0       0
heads           0       0
sectors/track   0       0
--
Logical/Physical Sector size:           512 bytes
device size with M = 1024*1024:           0 MBytes
device size with M = 1000*1000:           0 MBytes
cache/buffer size  = unknown
Capabilities:
IORDY not likely
Cannot perform double-word IO
R/W multiple sector transfer: not supported
DMA: not supported
PIO: pio0

Ich nehme mal an, dass zwischen dem SSD-Array und dem VDS ein RAID-Controller hängt und keine virtuelle SSD.

Gestern ist mir einer der vServer vom Typ RS 4000 G 9.5 wieder neu gestartet. Diesmal aber nicht mit Proxmox 7 oder 8, sondern mit Debian 12 und der Kernelversion 6.1.0-11-amd64.

Über die Logs sieht man leider nichts.

Von daher sieht es für mich als Endanwender eher so aus, als würden die vServer nach ein par Tagen einfach mal vom Host willkürlich neu gestartet werden. Denn ich habe ja mehrere vServer vom gleichen Typ bei Netcup, die sich identisch verhalten.

Gestern habe ich mal beim Mitbewerber einen der neueren Generationen mit der Bezeichnung VDS bestellt und dort das gleiche Setup wie auf einen vServer bei Netcup installiert und werde jetzt auch da mal beobachten, ob dort die Systeme auch so willkürlich wie bei Netcup neu gestartet wird.

VDS = Virtual Dedicated Server

Diese Art von vServer soll sich laut den Providern, die solche vServer als VDS anbieten, ähnlich verhalten wie Dedicated Server.

Wenn der Hoster für seine Webspace-Server Failover IP-Adressen verwendet, sollte es kein Problem sein, diese vom z.B. einem alten auf einen neuen Server umzuschwenken.

Zitat von engine

Ist bei jemandem der Fehler schon behoben? Bei mir gehts leider noch immer nicht und kann deshalb meine Firewall nicht deployen

Soeben wurde der Fehler bei mir im SCP gelöst.

Schau mal auch bei dir, ob auch bei dir im SCP das Problem nun gelöst wurde.

Zitat von engine

Ist bei jemandem der Fehler schon behoben? Bei mir gehts leider noch immer nicht und kann deshalb meine Firewall nicht deployen

Bei mir ist das Problem leider auch noch nicht behoben.

Zitat von engine

Bin ich der einzige mit dem Fehler, oder hat den noch wer? Wenn ich versuche auf "Netzwerk" im SCP zu klicken, kommt: Entschuldigung, das sollte nicht passieren. Ein Serverfehler ist aufgetreten. Sollte der Fehler wiederholt auftreten, setzen Sie sich bitte mit dem Support in Verbindung. Tritt bei all meinen Servern auf...

Bei mir für Server in Nürnberg habe ich auch das Problem.

Gestern habe ich schon ein Ticket dafür aufgegeben. Und eben wurde mir mitgeteilt, dass das Ticket an die technische Abteilung nun weitergeleitet wurde.

Einfach an die E-Mailadresse mail@netcup.de ein Ticket aufgeben.

Zitat von mainziman

wobei wo liest Du das mit den 10 Jahren?

Da habe ich mich leider vertan. Denn es sind leider nur 5 Jahre und gilt nur für die PRO-Serie.

Solche Daten findest du nur unter dessen technische Daten.

Zitat von Ente-Unser

gib mir die update länge von apple (hi EU), mit dem preis von android, der security von apple und der freiheit von android

und dann bitte nicht als monster gerät, mit wechselbarem akku (hallo EU)

mir egal ob das von microsoft kommt

Das kanst du mit Gigaset (Gigaset GX 4 PRO) bis auf dessen Gewicht und deren Gehäusestärke haben. Denn nach Einführung deren Geräte bekommt man ca. 5 Jahre für das OS Updates.

@mainziman: Die Traces sehne mir eher danach aus, als würde da eine Lastverteilung an Hand verschiedener IP-Adressen vorgenommen werden.

Die Hops kannst du meines Wissens nicht wirklich beeinflussen. Es sei denn, du baust dir ein eigenes vLAN vom Netcup-Server zu einem Server bei einem Mitbewerber oder auch nach Hause auf. Denn dann hast du es selber in der Hand, über wie viele Hops dein Netcup-Server hoppeln muß, bis er in deinem vLAN auch das Ziel erreichen kann.

Zitat von andreas.

Seit gut 17 Tagen habe ich auch auf meinem RS 4000 G 9.5 Proxmox 8 ohne ungewollte Neustarts laufen.

Mal sehen, wann dieses System wieder abschmiert. Denn den Test hat bei mir erst ein System bestanden, wenn es ohne Probleme mindestens 60 Tage am Stück durchlief.

Bei Mitbewerber habe ich solche oder auch ähnliche Probleme bezüglich Proxmox 7 und 8 auf deren vServer noch nicht gehabt.

Zitat von Valkyrie

Ich hatte jetzt eine Woche Urlaub und der Host läuft seit meiner letzten Nachricht. Ich bin am beten, dass es sich tatsächlich mit den letzten Updates erledigt haben könnte. Zumindest wäre das mein Wunschdenken Mal die nächsten Tage weiter beobachten.

Nach 20 Tagen sind während des kontrollierten Updates mir einmal ein RS 4000 mit Proxmox 8.X und einmal ein RS 4000 mit Proxmox 7.X unkontrolliert und auch ungewollt neu gestartet, so dass danach auch Beide nicht mehr neu gestartet werden konnten, da eventuell schon zu viele Systemdaten aktualisiert und das Update auf jeweiligen vServer (RS 4000 9.5) nicht komplett abgeschlossen werden konnte.

Bei Beiden, so wie es im Rettungssystem aussah, konnten dessen Daten auf jeweiliger virtueller Platte auch nicht mehr gelesen werden.

Da mir der Aufwand dann doch zu hoch wurde, die Daten auf beiden virtuellen Platten zu retten, habe ich Diese dann einfach durch die Funktion im Servercontrollpanel komplett gelöscht, da ich über das Rettungssystem die virtuellen Platten nicht mal mehr formatieren konnte.

Bei Mitbewerber laufen diese beiden Proxmox Versionen auch auf vServer ohne Probleme und sogar deutlich mehr als nur 20 Tage am Stück.

Zitat von Bud

Ja, aber genau das ergibt für mich ja keinen Sinn, da es sich um eine reine Weiterleitung handelt (siehe die letzten zwei Spoiler in meinem ersten Beitrag)

Ja. Da ansonsten jede andere Person auch über diesen SMTP-Server ohne Zugangsdaten E-Mails an beliebige Personen versenden dürfte.

Zitat von Bud

Generell?

Ja. Da dann auch neue Änderungen schneller bzw. nach einer Stunde greifen.

Zitat von Bud

<problem@example.com>: Relay access denied (in reply to RCPT TO command)

Vor dem Versenden einer E-Mail mußt du dich zuerst an dem SMTP-Server mit deinen Zugangsdaten anmelden. Dann sollte es gehen.

Die TTL der einzelnen Einträge des DNS-Servers würde ich von 86400 auf 3600 ändern.

Ich finde dieses Video sehr gelungen, da neben den Zukunftsplänen auch viele Fragen vieler Kunden vom Nutzer @[netcup] Lars S. darin beantwortet werden. Weiterhin zeigt es mir auch, daß bei Netcup Kundennähe großgeschrieben wird.

Zitat von Valkyrie

Es ist ein PVE 8.

Seit gut 17 Tagen habe ich auch auf meinem RS 4000 G 9.5 Proxmox 8 ohne ungewollte Neustarts laufen.

Mal sehen, wann dieses System wieder abschmiert. Denn den Test hat bei mir erst ein System bestanden, wenn es ohne Probleme mindestens 60 Tage am Stück durchlief.

Bei Mitbewerber habe ich solche oder auch ähnliche Probleme bezüglich Proxmox 7 und 8 auf deren vServer noch nicht gehabt.

Zitat von matt777

Ich kann auch eine Rotation einstellen. Ich denke mal, dass heißt alle X Tage/Wochen die Protokolle überschreiben/löschen? Was komisch wäre, denn ich hab das auf Default (tägliche Rotation bei 14 Protokollen) error_log von apache Einträge, welche bis zum 22.06.2023 zurückgehen (von den archivierten Logs ganz zu schweigen). Kann man da noch mehr einstellen oder war es das?

Was die Logs auf dem Webspace angeht, habe ich es mir nicht so genau angesehen, da ich bevorzugt meinen Webspace dafür verwende, um darauf im geschützten Bereich auf meine Bedürfnisse angepaßte ISO-Betriebssystemdateien ablegen zu können, die ich dann mit Hilfe der von mir erstellten Steuerdateien auf meine Server vollautomatisiert installieren lassen kann.

Von daher kann ich diesbezüglich auch nicht mehr dazu beitragen.

Zitat von matt777

Ich frage mich aktuell, welche Daten Netcup beim Besuch meiner Website genau speichert. Ich habe keinen vServer oder Root-Server, sondern einfach nur das Webhosting 1000 a1.

Ich habe mir mal meinen Bereich zum Webhosting 1000 genauer angeschaut.

So wie es zu mindestens bei meinem Tarif aussieht, speichert nicht Netcup die Daten der Besucher, sondern der Tarifinhaber. Denn der Tarifinhaber kann für jeweilige Hauptdomain und deren Subdomains selber entscheiden, ob Daten der einzelnen Besucher mitgeloggt werden sollen oder nicht.

Bei Bedarf können diese so gesammelten Daten auch vom Tarifinhaber in einem geschützten Bereich eingesehen werden.

Seit gut einem Jahr nutze ich auf zwei LXC Containern mit AlmaLinux 8.X auf einen vollvirtualisierten Server mit dem Betriebssystem Proxmox 7.X (Debian 11 und Proxmox 7.X bevorzugt als nette GUI), PLESK. Und dies einmal als eine Version zum Testen und parallel einmal als Version, die ich produktiv mit ca. 50 GB Nutzdaten nutze.

In diesen Testzeitraum habe ich jetzt für mich dann festgestellt, dass das es für mich nun die beste Entscheidung aus folgenden Gründen war, PLESK weiterhin so produktiv so zu nutzen:

• Der LXC Container kann bei Bedarf sehr schnell auch im laufenden Betrieb gesichert und kontrolliert auf einen weiteren unabhängigen Server per SFTP als Kopie gesichert werden.

• Die Wiederherstellung dieses Containers ist nach dem Einspielen der letzten oder schon vorhandenen Sicherung bei einer Datensicherungsgröße von ca. 50 GB je nach Performance des Servers als Wirt innerhalb von ca. 15 Minuten wieder hergestellt.

• Bei Bedarf, was ich auch schon mehrere Male getestet habe, kann ich diesen LXC Container im Netz von Netcup von Server 1 zu Server X entweder kopieren oder auch verschieben, während ich dann hemmungslos das Betriebssystem Debian 11 mit Proxmox 7.X als bevorzugte nette GUI kontrolliert aktualisiere und oder auch auf meine Bedürfnisse weiter anpasse.

• Updates von PLESK oder auch dem Betriebssystem im LXC Container können so auch ohne sich wirklich große Gedanken machen zu müssen, eben mal sogar per Schnellschuß durchführt werden, weil halt Sicherungen, wie schon weiter oben beschrieben, dank Proxmox damit recht schnell über dessen GUI erledigt werden können und dieser Vorgang sogar bei Bedarf auch vollautomatisiert werden kann.

• Als PLESK-Nutzer und auch als -Admin bekommt man nicht wirklich mit, dass PLESK unter einem LCX Container läuft. Denn PLESK verhält sich nach meinen Beobachtungen so, als hätte ich PLESK direkt auf einen vollvirtualisierten oder auch auf einen Dedicated Server installiert.

• Selbst die eigenen Sicherungen von PLESK mit einer bisherigen Größe von ca. 50 GB als Vollbackup, die von PLESK vollautomatisiert zum Zweck der Tests täglich auch als Vollbackup erstellt wurden, konnten nach einer Neuinstallation des Betriebssystems z.B. auf einen weiteren LXC Container oder einen weiteren vollvirtualisierten Server mit neunachinstallierten und aktuellsten PLESK-Version nach Aktivierung der PLESK-Lizenz ohne Probleme wieder eingespielt werden.

• Sofern diese indirekten schon o.g. Voraussetzungen gegeben sind, ist es eine enorme Zeiteinsparung, sein System mit PLESK in kürzester Zeit wieder herzustellen oder auf dem neusten Stand zu heben.

Zitat von Tom81

Drauf gekommen bin ich, weil mein Homelab mit Proxmox und KVM auf langsamen HDD (mit SCSI) ohne Probleme läuft.

Du darfst nicht vergessen, dass du dir im Gegensatz zu deinen Server Zuhause oder einen Dedicated Server beim Mitbewerber das SSD Array auf dem Host mit sehr vielen weiteren Kunden teilst, die eventuell auch sehr hungrige IO-Anwendungen nutzen könnten.

Zitat von aRaphael

Tja, da muss ich nun zusehen, dass ich mich an alle meine Einträge wieder erinnere. Dokumentiert habe ich die leider nicht...

Aktiv sind die Records allerdings weiterhin.

Wenn dir noch die Sup-Domains einfallen sollten und es noch einen DNS-Server gibt, der die Daten haben könnte, könntest du es mal mit folgenden Befehlen ausprobieren:

dig DeineHauptdomain.de ANY +noall +answer

dig Supdomain.DeineHauptdomain.de ANY +noall +answer