hi!
warum ist netcup bei domain-handles so restriktiv und läßt fremd-handles nur bei domain-resellern zu?
bei einem registrar aus der Prinzessinnengasse zb ist das total frei. da kann man zb auch als privatperson eine domain für "seinen" verein registrieren.
gre3tings, Klaus
Die Vienna rootserver Angebote bleiben mal so, oder gibt es hier Handlungsbedarf? Ich glaube ich werde zum Osterhasen zuschlagen.
aus den FAQ:
"Handelt es sich bei den Root Server Vienna um eine zeitlich begrenzte und limitierte Aktion oder werden diese dauerhaft angeboten?
Die Verfügbarkeit der Root Server Vienna ist nicht begrenzt oder limitiert, sondern werden auch nach dem 15.12.2021 dauerhaft zum Aktionspreis angeboten."
Fehlen nur noch Storage Server in Österreich, dann wäre es perfekt, Da Backups im gleichen RZ wenig Sinn macht.
das hängt jetzt natürlich sehr stark vom standpunkt ab. 
aber ich bin schon neugierig, ob das CloudVLAN RZ-übergreifend sein wird.
und ist Wien dann ein eigenes AS?
Root-Server Vienna
https://www.netcup.de/vserver/root-server-vienna/
Kam etwas überraschend aus dem Adventskalender…
ich finde das großartig!
Ich glaube, vor dem letzten Schritt sollte man noch einmal einen Blick in /etc/fstab (und ggf. /etc/crypttab) werfen, ob da irgendwelche Zeilen mit UUID auftauchen
vollkommen korrekt. hier in meinem speziellen fall macht der mdadm ja schöne devices.
Evtl. ist da rsync doch die schnellere Lösung. Ich hatte halt nur das Bedenken, dass, wenn man das so macht:
...dass es dann Probleme gibt, wenn man so Verzeichnisse wie /boot, /etc/fstab, /ect/mtab usw mit rüberkopiert, da man ja eben nicht die gesamte Disk, inkl. bootpartition überträgt.
ich mach das pro partition immer mit
ionice -c idle rsync -axHAXvP --numeric-ids --delete / root@<targethost>:/new-root/
ionice -c idle rsync -axHAXvP --numeric-ids --delete /boot root@<targethost>:/new-root/bootdas -x bzw --one-file-system bewirkt, daß er innerhalb des einen filesystems bleibt. /boot zb dann nicht vergessen wenn es auf einer eigenen partition liegt.
das quell-system kann dazu beim ersten sync noch im normalbetrieb sein, das ziel-system ist auf jedenfall im recovery. erst beim letzten durchlauf (und dann hoffentlich nur mehr die deltas syncend) ist auch das quell-system im recovery. somit ist auch die downtime recht kurz.
im anschluß am ziel-system im recovery im chroot den grub installieren
grub-mkdevicemap -n
grub-install /dev/sda
grub-install /dev/sdbauf persistierte net-interfaces nicht vergessen in /etc/udev/rules.d/70-persistent-net.rules
md-array informationen aktualisieren bei bedarf
mdadm --detail --scan >> mdadm.conf
vim /etc/mdadm/mdadm.confund zu guter letzt initramfs und grub aktualisiern
update-initramfs -u -k all
update-grub2