Support hat sich grad bei mir gemeldet, dass der Fehler im CCP behoben wurde. Das Setzen eigener DNS-Server funktioniert bei mir jetzt auch.
Damit sollte sich das Thema erledigt haben.
Support hat sich grad bei mir gemeldet, dass der Fehler im CCP behoben wurde. Das Setzen eigener DNS-Server funktioniert bei mir jetzt auch.
Damit sollte sich das Thema erledigt haben.
Der Unterschied is soweit ich das sehe nur, dass du einen Teil des VM Host fest zugesichert bekommst.
Genau das ist der Punkt. Bei den Root-Servern hast du effektiv N "reale" Kerne des eigentlichen Servers, die 1:1 dem virtuellen Server zustehen. Wenn du also 2 Kerne mit je 2GHz hast, bekommst du auch die Leistung, die ein System mit einem 2x2GHz CPU leisten könnte. Beim RAM vermute ich, dass dort kein Memory Ballooning (https://blog.jgriffiths.org/how-does-memory-ballooning-work/) durchgeführt wird. Bei den VPS hingegen bekommst du nur N "virtuelle Kerne". Da ist es egal, wie viele Kerne das Hostsystem, der Hypervisor teilt einfach die Arbeit der insgesamt N virtuellen Kerne (aller virtualisierten Maschienen) auf M reale Kerne, die das Hostsystem wirklich hat, auf. Ebenso wird meines Wissens nach Memory-Ballooning genutzt, wodurch deine VM nur den umbedingt notwendigen Speicher nutzt. Dies führt dazu, dass man in Summe mehr virtuelle Kerne und RAM auf einer Maschiene anbieten kann, als physisch vorhanden sind. Wenn bsp. ich auf einer 32Gb RAM Maschiene mit 8 Kernen 16 virtuelle Maschienen mit je 4Gb RAM und einem CPU-Kern hoste, so kostet mich die einzelne VM nur halb so viel, als wenn ich "nur" die real vorhandenen Ressourcen nutzen würde. Da in der Praxis nicht jeder Server seinen RAM und CPU-Kerne die komplette Zeit vollständig nutzt, kann ich dadurch die VMs so aufteilen, dass die unterliegende Hardware immer zu mind. 70/80% ausgelastet ist.
Kannst natürlich auch einfach jedes Jahr nen neuen Webhosting-Vertrag nehmen, den alten kündigen und die Domains, die du haben willst transferieren. Wenn ich das richtig sehe, haben die Webhosting-Verträge ja keine Einrichtungsgebühr. Ggf. überlappst du die Verträge ein paar Tage für den Datentransfer. Ist natürlich etwas schwierig, wenn du irgendein Super-Sonderangebot hast.
Mfg 7c00
Ähm... ist das nicht bereits beim DNS so oder versteh ich was falsch?
Hab im Zuge der BF-Aktion auch nen Domaintransfer nach Netcup durchgeführt und im Transferprozess wurde ich direkt gefragt, ob ich die Domain parken möchte oder ob ich meine eigenen Records angeben möchte. Der Transfer hat zwar mehrere Stunden gedauert (währenddessen noch die DNS-Server von meinem alten Anbieter galten) bis die Netcup-Nameserver auch an meiner Domain hinterlegt waren, aber gefühlt hab ich keine Unterbrechung (wobei das auch daher kommen kann, dass ich nachts schlafe und erst am nächsten Tag draufgeschaut hab).
Kann natürlich sein, dass das bei den Inklusivdomains von Webhosting-Paketen anders funktioniert, da Netcup da annimmt, dass du auch deren Webspace und Mailserver nutzen willst. Ggf. gibts da ja Unterschiede, wenn du die Domain beim Bestellen noch nicht angibst und erst später hinzufügst.
Mfg 7c00
I have no experience with dd over the network. For the copying of the files, you maybe can use rsync to synchronize all the files.
Erster interessanter Test: Gilt das nur für die eine xml-Datei oder sind davon alle Dateien im autodiscover-Ordner betroffen (einfach aus Interesse, wie viel da eingeschränkt ist)?
Ein Versuch zur Problemlösung: Mit ner .htaccess-Datei den autodiscover/autodiscover.xml URL zu irgendeiner anderen Datei umbiegen: https://httpd.apache.org/docs/2.4/rewrite/intro.html
Falls das nicht funktioniert vermute ich, dass Netcup da nen Proxy davor hat, der den URL schon vorher auf irgendeinen Dienst von Netcup umleitet, der die autodiscovery.xml-Dateien generiert, sodass dein Webserver den gar nicht sieht. Beim Abschalten der Autodiscovery-Funktion gibt der Dienst zwar keine autodiscovery-Datei mehr zurück, aber die Umleitung nicht abgeschaltet wird. Bist da vermutlich einer der wenigen Personen, die ihre eigene autodiscovery-Datei anlegen wollen und daher ist das noch nicht aufgefallen. Daher würd ich mich an den Support wenden, da das ja nur nen technisches Problem seitens Netcup ist, weshalb du das Problem auch nicht bei Webhosting-Angebote anderer Hoster sehen wirst.
Mfg 7c00
P.S.: Kannst auch mal Dateien im Ordner .well-known/acme-challenge ausprobieren. Ich würd vermuten, dass du da auch Probleme haben könntest, da der Ordner für die Generierung der LetsEncrypt SSL-Zertifikate relevant ist.
I'm glad to hear, that you've got your data back.
First of all, I would suggest to backup/download the most important files. If something else goes wrong and the rescue attempt fails (shit happens...), you at least can setup a new server manually.
Then check your partition setup. We want the unused space at the end of the disk. If we shrink a partition that is not the last, we also need to move other partitions to the front, so that the empty space is at the end (so the dd copy only leaves out unused disk space instead of some partitions).
Now you can shrink the partition with gparted. I would suggest to shrink it, so that only 1Gb of free space remains on the partitions (so the system can boot and run without a problem). This reduces the amount of data that needs to be transferred via dd.
now continue with your list of steps. The most important thing is to check, that the shrinking worked fine. Everything else doesn't risk your data, as you only read from the old servers harddisk.
And probably you won't reach your new server after booting, as it probably has a static IP, which is the one from the old server. So don't worry, if you don't reach it via SSH, you can still fix it via VNC. Just look up where your OS stores the IP address configuration.
Sincerely
7c00
I am dumb.. I didnt realise I could use GUI apps like Gparted using the VNC option... Can I fix this mess with Gparted?
Tricky question... Just a quick visualisation of what has gone wrong:
I assume some partition setup like this:
Partition 1 | Partition 2 | Partition 3
XXXXXXXXXXXXXXYYYYYYYYYYYYZZZZZZZZZZZZZZZZZZZ
The above partitions are the ones, which the partition table defines. X Y and Z are the drive spaces that are occupied with data from the filesystem (fat, ext4, btrfs, ZFS, etc.).
By using parted to just shrink the partition, we got the following scenario:
Partition 1 | Partition 2 | Partition 3 | Unused disk space
XXXXXXXXXXXXXXYYYYYYYYYYYYZZZZZZZZZZZZZZZZZZZ
Now the Partition 3 won't work, as part of the data for the filesystem is outside of the partition boundary.
Currently there is no data lost, just the partition table is messed up. This can be fixed by manually adjusting the partition table or using "parted rescue" or testdisk.
But there might be the case, that fsck or something else has corrupted the data (like creating a new partition and formatting it in the unused disk space). This is the bad case, where you probably need some data recovery tool (like photorec).
The correct way of shrinking is the following (which GParted does automatically):
Partition 1 | Partition 2 | Partition 3
XXXXXXXXXXXXXXYYYYYYYYYYYYZZZZZZZZZZZZZZZZZZZ
Shrink the filesystem down first (resize2fs does this):
Partition 1 | Partition 2 | Partition 3
XXXXXXXXXXXXXXYYYYYYYYYYYYZZZZZZZZZ
Then change the partition table to actually shrink the partition:
Partition 1 | Partition 2 | Partition 3 | Unused disk space
XXXXXXXXXXXXXXYYYYYYYYYYYYZZZZZZZZZ
Enlarging a partition works the other way around. First the partition table is modified:
Partition 1 | Partition 2 | Partition 3
XXXXXXXXXXXXXXYYYYYYYYYYYYZZZZZZZZZ
And now the filesystem is resized (again with resize2fs) according to the partition boundaries:
Partition 1 | Partition 2 | Partition 3
XXXXXXXXXXXXXXYYYYYYYYYYYYZZZZZZZZZZZZZZZZZZZ
Why is this necessary to know?
Because the resize2fs part changes actual data on the disk. As GParted does this automatically, it might overwrite something (i don't know, maybe it's smart), as usually the partition you expand is in a working state.
Therefore I would suggest the following steps:
Edit: Just for your information: You can use X11 tunneling to use GUIs via SSH: https://wiki.archlinux.org/index.php/OpenSSH#X11_forwarding
First I would suggest to try to rescue the partition table: https://www.gnu.org/software/p…ual/html_node/rescue.html
If this doesn't make anything better, we can use the file recovery utilities: https://wiki.archlinux.org/ind…ery#Testdisk_and_PhotoRec
As you don't want to touch the filesystem on the old server, you need to get some external storage (I would suggest from the new server), where the tools can put the recovered data. I would suggest SSHFS: https://wiki.archlinux.org/index.php/SSHFS
Quoteresizepart partition end
Change the end position of partition. Note that this does not modify any filesystem present in the partitio
Damned, why is GParted called a GUI of parted, when it does those things by itself. I'm so sorry.
But lets focus on getting the partition back... Parted knows percentages, so you should be able to just give all unallocated space back to the partition using "parted /dev/sda resizepart [partition number] 100%" (based on https://unix.stackexchange.com…e-using-parted-in-batch-m).
P.S.: Don't use resize2fs (yet), as this will modify the actual data on the harddisk. We only want to change the partition table to fully encapsulate the old filesystem (if the partition is greater, it shouldn't matter, but currently it is smaller, which looks like to the filesystem, as if it was cut in half).
My old server (resized partition to bring the contents under 480GB) is broken. It boots from Grub but reports file system errors and says to run fsck on /dev/sda3
Did you use parted to resize the partition? If yes, then parted seemed to just change the partition table and not resized the fs (i always use gparted, which does this, so I thought that parted should do the same). I would suggest to resize the partition on the old server back to it's original size (so the partition table is like before) and see, if you can access your data.
This seems weird, as the UUID shouldn't change if you've copied the partitions exactly.
Of course you can use the rescue system to check for the error. Just look up your partitions and mount them to /mnt or somewhere else. Then you can inspect the files and change them if necessary.
I would also advise you to look into the grub.cfg (somewhere in /boot, but probably it is located on another smaller partition and mounted to the final linux to the /boot directory). This file should also contain an UUID for the root partition.
Ok, ich habs geändert. Nochmals vielen Dank!
Die IPv6 Adresse hatte ich (wie auch die IPv4) vom Server Control Panel. Wie kommt es, dass dort die kürzere angegeben ist, anders als in der Netplan-Konfiguration?
Dazu sollte man wissen, warum wir IPv6 haben: Weil in IPv4 die Adressen knapp werden!
IPv4 hat 32-Bit pro Adresse, was etwas über 4 Milliarden Adressen ergibt. IPv6 hat 128-Bit, was ca. 3,4 * 10^38 ist (also ne 39-Stellige Zahl).
Nun haben wir soo viele IP-Adressen, das die quasi nix kosten (weil das Angebot ja riesig ist). Also bekommst du nicht nur eine IP-Adresse, sondern gleich ein Subnetz, was quasi sagt: "Die ersten X-Bits der IP sind festgelegt, alle weiteren Bits kannst du frei bestimmen".
Das wird dann bsp. so geschrieben: 2a03:4000:42:430::/64. Das bedeutet, dass die ersten 64-Bits fest bestimmt sind (also die ersten 4-Blöcke 2a03:4000:42:430 von den 8 IPv6-Blöcken) und du dir die restlichen Bits aussuchen kannst. In der IP vor der /64 sind dann nur alle vorgegebenen Bits gesetzt, der Rest (den du bestimmen kannst) ist auf 0 gesetzt. Die zwei Doppelpunkte sind die Kurzform in IPv6 für "füll mal mit 0en auf". 2a03:4000:42:430:: ist in Wahrheit also 2a03:4000:0042:0430:0000:0000:0000:0000. Du hast jetzt also für deinen Server von Netcup ca. 1,8 * 10^19 IPv6-Adressen bekommen, die du nur halt vergeben musst.
Für IPv4 gibt es auch diese Schreibweise, aber wegen der Adressknappheit bekommst du auch nur eine IP-Adresse und für weitere IPv4-Adressen musst du extra zahlen. Im Heimnetz ist bsp. üblich das Subnetz 192.168.0.0/24 zu nutzen. D.h. die ersten drei Blöcke (192.168.0, 24 Bits) sind immer gleich und die letzten 8 Bits (bzw. den letzten Block) darfst du selbst bestimmen. Somit hast du im üblichen Heimnetzwerk 256 mögliche (in Wahrheit ein paar weniger) IP-Adressen, die der Router üblicherweise per DHCP vergibt. Und wenn dein Provider schon IPv6 anbietet, dann bekommst du zu Hause je nach Provider auch ein /64 oder ein /60 IPv6-Subnetzwerk.
Mfg 7c00
Edit: In der Subnetzschreibweise kann man auch einzelne IPs angeben, wo es dann halt alle Bits vorgegeben sind. Wär dann in IPv4 /32 und in IPv6 /128. Das wird aber üblicherweise weggelassen, da es auch nicht wirklich ein "Subnetz" ist (da es nicht mehr als eine IP beschreibt).
Zum E-Mailempfang ist der MX-Record entscheidend. Wenn der korrekt gesetzt ist, sollte das Empfangen von E-Mails funktionieren. Oder liegt die Domain oder das DNS nicht bei Netcup?
Zum Versandt sind die TXT-Records wichtig. Die sind notwendig für SPF (welche IPs dürfen E-Mails im Namen der Domain versenden), DKIM (Signaturverfahren um sicherzustellen, dass E-Mails authentisch sind im Falle von bsp. einer Mailingliste, die E-Mails weiterleitet) und DMARC (Wer soll informiert werden, falls SPF oder DKIM einer ankommenden Mail ungültig sind), welches zusätzliche Schutzmaßnahmen sind, damit der Empfänger sich von der Echtheit der E-Mail überzeugen kann. Theoretisch sind die optional, aber ohne die werden wohl viele Mailserver deine Mails als Spam einstufen oder abweisen.
Mfg 7c00
der eingeenglischte Name eines Kuhdorfes des nach einer Verschwörungstheorie nicht existiert;
ich find des einfach witzig: https://de.wikipedia.org/wiki/Bielefeld-Verschw%C3%B6rung
Also immer diese suspekte Quelle Wikipedia. "Entworfen und konzipiert wurde die Wikipedia Ende 2070 von den Wikingern als eine gut gemeinte Parodie auf die Stupidedia, die nach dem gleichen Prinzip funktioniert und als Raubkopie dazu auch noch auf der gleichen Software basiert." (Quelle: https://www.stupidedia.org/stupi/Wikipedia)
Folgen wir also dem "Original": https://www.stupidedia.org/stupi/Bielefeld
Damit sollten sich alle Fragen klären. Aluhut nicht vergessen
Da wurden scheinbar ein paar (Spam-)Regeln zu scharf angezogen und Netcup erfüllt die nicht.
Das DNS für E-Mails sieht dagegen einer anderen von Netcup gehosteten Webseite sehr ähnlich (auch wenn ich die zwei MX-Records doch sehr suspekt sehe, da beide effektiv sich auf dieselbe IP verweisen).
Um zu verstehen was schiefläuft schauen wir mal auf den Weg, den eine vom Netcup-Webhosting versandte E-Mail nimmt (zu sehen wenn man sich die E-Mail-Header einer angekommenen Mail ansieht):
Received: from relay.yourmailgateway.de (relay.yourmailgateway.de [188.68.63.162])
by [Zielmailserver]
for <[Empfänger-E-Mail]>; Fri, 27 Nov 2020 21:08:29 +0100 (CET)
Received: from mors-relay-8201.netcup.net (localhost [127.0.0.1])
by mors-relay-8201.netcup.net (Postfix) with ESMTPS id 4CjQfx4HmTz4Kg5
for <[Empfänger-E-Mail]>; Fri, 27 Nov 2020 21:08:25 +0100 (CET)
Received: from policy02-mors.netcup.net (unknown [46.38.225.53])
by mors-relay-8201.netcup.net (Postfix) with ESMTPS id 4CjQfx3v6hz4Kfn
for <[Empfänger-E-Mail]>; Fri, 27 Nov 2020 21:08:25 +0100 (CET)
Received: from mxf993.netcup.net (unknown [10.243.12.53])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by policy02-mors.netcup.net (Postfix) with ESMTPS id 4CjQfx0rMYz8sjw
for <[Empfänger-E-Mail]>; Fri, 27 Nov 2020 21:08:25 +0100 (CET)
Received: from [192.168.2.192] (unknown [46.21.15.209])
by mxf993.netcup.net (Postfix) with ESMTPSA id ACD3F1223C6
for <[Empfänger-E-Mail]>; Fri, 27 Nov 2020 21:08:24 +0100 (CET)
Display More
Also Sender -> mxf993 -> policy02-mors.netcup.net -> mors-relay-8201.netcup.net -> relay.yourmailgateway.de -> Mailserver vom Empfänger
Zum Vergleich, wenn man nen eigenen Mailserver (d.h. VPS oderso) betreibt: Sender -> Eigener Mailserver -> Mailserver vom Empfänger
Soo und jetzt kommen wir zum großen Problem von E-Mails: Spam
Da kommt jetzt so ein Server bei uns an und möchte uns sagen, dass er eine E-Mail von Domain XYZ hat. Aber woher wissen wir, dass der überhaupt für die Domaine zuständig ist?
Jetzt kann da jeder das konfigurieren, was er möchte:
Mfg 7c00
P.S.: Wer denkt, dass er einfach nur relay.yourgateway.de (188.68.63.102) als MX-Eintrag hinzufügen muss, dem würde ich davon stark abraten. Das sollte zwar das Problem lösen, da nun auch ohne SPF die Verifikation möglich ist. Jedoch definiert der MX-Eintrag auch die Mailserver für ankommende E-Mails, wodurch es sein könnte, dass Mails bei euch nicht ankommen (bzw. Fehler beim Sender auftreten), da relay.yourgateway.de die Mails sehr wahrscheinlich nicht annehmen wird.
QuoteLäuft das denn ohne einen Webserver?
Ja klar: php helloworld.php
Siehe auch: https://stackoverflow.com/ques…-php-without-a-web-server
Wird halt mal gerne vergessen, da viele es nur als Sprache für Webseiten sehen.
Bei den API-Clients/Libraries kann ich dir leider nicht weiterhelfen, da ich davon nichts nutze (sondern meinen eigenen DNS-Server betreibe).
Mfg 7c00
Wie wär es mit dem Bash-Skript aus dem ersten Eintrag? https://github.com/linux-insideDE/ncdapi
Dafür brauchst du nur Bash und Curl, was du auf jedem Linux eig. vorfinden solltest.
Mfg 7c00
P.S.: Fehlt es an Platz um PHP auf dem Server zu installieren? Wär ja die einfachste Möglichkeit. Kannst natürlich auch den PHP-Code in Python nachprogrammieren.
Quote
Evtl. ist dir ein Fehler unterlaufen, als du die Netzwerkkonfiguration des eingespielten Images an den neuen Server angepasst hast?
So wie ich das lese, wurde da gar nichts angepasst, sondern alle Daten per Snapshot auf den neuen Server gebracht.
Das führt natürlich zum Problem, da die IP-Adressen bei Servern statisch gesetzt werden. Und da dein neuer Server auch eine andere IP-Adresse hat, empfängt der nichts mehr, da Linux noch auf die alte IP hört. Also: Serverip einmal anpassen und (um sicher zu gehen) den Server neu starten.
QuoteAber wenn sich da gerade etwas ändert, ist ja vielleicht ein(e) Support-Mitarbeiter(in) dran.
Das bezog sich auf deine DNS-Server. Als ich den Check im NAST testweise durchgeführt habe, so hab ich noch nen REFUSED-Fehler bekommen (d.h. deine DNS-Server haben die DNS-Anfragen für hilko.eu refused). Das war nach dem Schreiben des Posts nicht mehr der Fall (oder ich hab mich davor vertippt), daher der Zusatz. Von Netcup hab ich leider noch nix gehört und meine Domain zeigt auch noch auf die Netcup DNS-Server.