Beiträge von m_ueberall

Zitat von Interessent

Es geht um die Image / Snapshot Datei.

Aber Qemu scheint nicht das richtige dafür zu sein, konvertiert anscheinend nur irgendwelche Virtual Box Formate ins qcow2 Format.

Das halte ich für ein Gerücht (vgl. qemu-img-Dokumentation).

Zitat von SCD

da inzwischen ja SCSI wieder empfohlen wird, habe ich bei einem Server von VIRTIO wieder auf SCSI umgestellt.

Lese ich jetzt gerade zum ersten Mal – Wer empfiehlt denn SCSI anstelle von VIRTIO und in welchem Kontext?

Zitat von aRaphael

Das wäre doch mal ein nettes Feature für das SCP, wenn man bestimmte Verzeichnisse vom snapshot ausschließen könnte.

Mit ZFS ginge das schon …

Aber im SCP wird das eher nicht integriert, denn das wäre kaum OS-agnostisch machbar, von verschlüsselten Installationen ganz zu schweigen.

Zitat von Interessent

Und wie?

Man kann auch QEMU unter Windows installieren; damit sollte man Zugriff haben auf qemu-img, womit sich Abbilder komprimieren lassen usw. (wenn man in der VM die unbenötigten Dateien gelöscht hat). Das exportierte Dateiformat sollte mittlerweile auch von anderen/kommerziellen Programmen (VirtualBox und Co.) unterstützt werden, wobei ich mich für den letzten Schritt allerdings wirklich qemu-imgs bedienen würde.

Zitat von Lars-Daniel

Ich erinnere mich auch, dass ich Probleme mit overlay2 hatte... vielleicht geht das ja inzwischen? Aber das ist hier Offtopic. Können wir gerne woanders diskutieren, da es sicher auch andere interessiert? @m_ueberall

Temporär die Antwort einmal hier platziert: LXD 5.11 brachte etwas „syntaktischen Zucker“ (und einen ZFS-Block-Modus), welcher die einfache Einbindung von Nicht-ZFS-Dateisystemen ermöglicht (beispielsweise Btrfs*, ext4), sodass man mit Docker den „overlay2"-Treiber verwenden kann; ein Demo-Video vom Projektleiter findet sich hier. Bis zum Erscheinen einer neuen ZFS-Hauptversion, welche Container den Zugriff auf einen Teil des Host-ZFS-Pools erlaubt, sollte das gut genug sein für DroneCI und Co. (hiermit hatte ich bislang keinerlei Probleme).

*Btrfs-auf-ZFS funktionierte seinerzeit vor einigen Monaten nach einem LTS-5.10-Update nicht mehr und überlastete die KVM-Instanzen; seitdem lasse ich die Finger davon.

Zitat von Methanoid

Could I not boot the installation ISO and then use that to do the modification to my existing install with the fstransform tool and (presumably) editting the fstab after that ?? Seems theoretically possible but I'd not be confident and dont want to trash a system I use daily!

Depending on the available space, you should have the option to create a snapshot of your system and restore the latter in case of problems. (I'd test the restore functionality first, though.)

Better yet, you could export a snapshot of your entire system (the first export is free, you'd pay for subsequent exports like this) and download, import it at home or use another VPS which can be rented on an hourly basis to run your tests.

Zitat von Lars-Daniel

Allerdings ist LXC seit einiger Zeit über Tools OCI-kompatibel. LXC jetzt aber auch kein Beinbruch, wenn man damit umgehen kann. Vorallem müllt es nicht die Regeln voll, wie Docker es tut

Nach eigener Erfahrung schadet es grundsätzlich nicht, beim Einsatz von Docker die letztere Installation zusätzlich in einen LXC-/LXD-Container zu legen. Der damit verbundene Overhead ist heutzutage vernachlässigbar, aber man hat eine saubere Kapselung. Gerade dann beruhigend, wenn die Docker-Abbilder teilweise immer größer/komplexer/undurchsichtiger werden (vgl. Gitlab usw.) …

Zitat von extremmichi

Gilt das für die erste oder 2te Frage?

Ich glaube ja.

Zitat von m_ueberall

Außerdem ist sicherzustellen, dass sich der Mailserver (genauer: der Mail/Message Transfer Agent, MTA) auch für alle E-Mails mit Domain2…4 zuständig fühlt, sonst helfen die DNS-Einträge allein noch nichts.

Zitat von s.moenikes

Muss ich da aktiv etwas für tun oder erledigt sich dieser Schritt mit dem Anpassen der DNS Einträge?

Der Satz sollte eigentlich implizieren, dass noch etwas zu tun ist. Nach Lesen der Beiträge #4 und #9 in diesem Unterforum sehe ich, dass offenbar noch nicht einmal die Einstellungen für Domain1 stimmen, denn sowohl timeout 5 telnet v12023NNNNNNNNNNNNNN.yourpserver.net smtp als auch timeout 5 telnet 9N.NN.NNN.NN smtp sollten Postfix zu einer Begrüßung unter Verwendung von mail.domain1.de veranlassen (wenn der dortige Servername stimmt).

Dementsprechend sind hier mehrere Änderungen in den Postfix-Konfigurationsdateien /etc/postfix/main.cf und ggf. /etc/postfix/master.cf erforderlich, was die Verwendung der TLS-Zertifikate usw. anbelangt (mydestination etwa muss alle zu akzeptierenden Domänen auflisten).

An dieser Stelle würde ich unbedingt erst einmal alle Tests für Domain1 absolvieren, bevor die anderen Domänen umgelenkt werden. Inwieweit ein „Managed Server“ die Konfiguration von Postfix nach Kundenwünschen beinhaltet, entzieht sich meiner Kenntnis. Der Aufwand hierfür ist nicht zu unterschätzen und liegt ganz leicht zwei Größenordnungen über dem Aufwand für die vorgenannten DNS-Änderungen.

Zitat von s.moenikes

Also ich entscheide mich für eine .de Domain um hier die vermeidlich notwendige Seriosität erreichen zu wollen, dann lasse ich von Netcup den PTR des Servers auf mail.domain1.de zu setzen?

Dies macht ja keine DNS Änderungen bei domain1.de notwendig, da ja der MX Eintrag dort eh auf mail.domain1.de liegt.

Aber bei Domain2 - 4 müsste ich im Anschluss die DNS Einstellung ändern und den MX Eintrag auch auf mail.domain1.de anpassen, da dies dann das offizielle Serveridentifikationsmerkmal für den E-Mail Versand von der Server IP ist?

Ja. Die MX-Einträge für Domain2…4 sind auf "mail.domain1.de" zu ändern. Die TXT-Einträge für Domain2…4, die mit "v=spf1" beginnen, sollten ein "mx" bekommen ("v=spf1 mx ~all" oder "v=spf1 mx -all" würde ausreichen, zusätzliche Angaben wie a/aaaa/ip4/ip6 für eine delegierte Versendung schaden nicht); alternativ böte sich auch ein "v=spf1 redirect=domain1.de" an (hier nur die eigentliche Domäne nennen), aber man muss es nicht so kompliziert handhaben wie in diesem Beispiel.

Für Tests würde man (wenn noch nicht geschehen) die Gültigkeitsdauer der DNS-Einträge beteiligter Domänen verkürzen, sodass künftige Änderungen schneller weltweit übernommen werden. Außerdem ist sicherzustellen, dass sich der Mailserver (genauer: der Mail/Message Transfer Agent, MTA) auch für alle E-Mails mit Domain2…4 zuständig fühlt, sonst helfen die DNS-Einträge allein noch nichts.

Die Nutzung eines explizit gesetzten RDNS-Eintrags für die Domäne für das Senden/Empfangen von E-Mails ist eigentlich immer sinnvoller. Die „Seriosität“ einer weitverbreiteten TLD ist dabei immer mehr oder weniger subjektiv; ggf. würde ich für E-Mails im D/A/CH/EU-Bereich eher eine „lokale“ Länderdomäne verwenden (ausschlaggebend wären primär Möglichkeiten, für die verwendete Domäne dort bestimmte DNS-Einträge hinterlegen und DNSSEC aktivieren zu können).

Sofern man aus Separierungs-/Sicherheitsgründen für verschiedene Domänen nicht verschiedene IP-Adressen verwendet (die lassen sich bei Netcup hinzubuchen), sollte man aber bedenken, dass die Domäne (inkl. Unterdomäne), mit welcher sich der Mailserver identifiziert, auch als zuständig für die Übermittlung von E-Mails der anderen Domäne(n) im DNS hinterlegt sein muss (vgl. TXT(SPF)-/MX-Einträge für die anderen Domäne(n)).

Grundsätzlich würde ich meinen, dass Windows entweder „nach Hause telefoniert“ wie seinerzeit E.T. und/oder dass ein öffentlich erreichbarer Windows-Server – was an sich risikobehaftet ist, wenn man dessen Administration nicht beherrscht, denn in der Regel gehören derartige Systeme hinter eine Firewall, wie sie standardmäßig bei Netcup nicht verfügbar und/oder kein aktivierter Bestandteil von Windows Server selbst ist – mithilfe spezialisierter Suchmaschinen (Shodan & Co., vgl. etwa hier) ganz einfach gefunden werden kann.

Zwecks Lizenzierung würde ich in diesem Fall, sofern kein spezialisierter Anbieter gewählt werden soll, der sich bei der überlassenen/vermieteten VM selbst darum kümmert, jemanden fragen, der sich damit auskennt. Eine Suche nach „Windows Server 2022 Lizenzierung“ liefert sofort Anbieter, welche belastbare Aussagen und/oder gute Angebote machen können, weil sie sich hierauf spezialisiert haben – zumindest aber deutlich belastbarere Aussagen als in diesem Forum.

https://www.netcup-status.de/2023/03/stoerung-des-servercontrolpanel-scp-2/

(Translation)

Zitat von KB19

Lustigerweise gibt es bei mir seit diesem Zeitpunkt (24.02.) keine Probleme mehr

Dann sollten Nutzer, die ihre Domänen noch direkt bei Netcup verwalten (wollen), jetzt vielleicht analog auf ein erweitertes Logging bzgl. aller DNSSEC-Funktionalitäten drängen?

(Wobei mich das selbst seit dem Umzug der Domänenverwaltung zu deSEC nicht mehr betrifft; die Kombination der Dienste von Netcup für die Registrierung und deSEC für die Verwaltung hat sich bislang als optimal erwiesen.)

Zitat von s.moenikes

Vielen Dank für deine Bemühungen mir zu helfen, das ist wirklich sehr nett.

Die Ausgabe davon ist leider

Fatal error: Uncaught Error: Class 'SMTP' not found

aus dieser Zeile: $mail->SMTPDebug = SMTP::DEBUG_SERVER;

Leider kenne ich mich damit auch nicht aus, ich bin nicht in der Lage mir da selbst zu helfen und das Problem zu lösen

Die Installation sollte in einem Arbeitsverzeichnis wie folgt funktionieren:

% #### Die folgenden Zeilen stammen von https://getcomposer.org/download/
% php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
% php -r "if (hash_file('sha384', 'composer-setup.php') === '55ce33d7678c5a611085589f1f3ddf8b3c52d662cd01d4ba75c0ee0459970c2200a51f492d557530c71c15d8dba01eae') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
% php composer-setup.php
Installer verified
All settings correct for using Composer
Downloading...

Composer (version 2.5.5) successfully installed to: /tmp/php-test/composer.phar
Use it: php composer.phar

% #### So wird PHPmailer mithilfe von Composer installiert (vgl. https://github.com/PHPMailer/PHPMailer#installation--loading)
% php composer.phar require phpmailer/phpmailer
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Downloading phpmailer/phpmailer (v6.8.0)
Using version ^6.8 for phpmailer/phpmailer

% #### Das nachfolgend aufgerufene Script ist die angepasste Version des Listings von @Virinum (https://forum.netcup.de/administration-eines-server-vserver/server-konfiguration/imap-pop3/p198801-kein-e-mail-versand-an-gmail-com-m%C3%B6glich/#post198801)
% php ./listing1.php
2023-03-23 11:23:21     SERVER -> CLIENT: 220 mx.google.com ESMTP t75-20020a63784e000000b004fbd06e0996si17315563pgc.610 - gsmtp
2023-03-23 11:23:21     CLIENT -> SERVER: EHLO ip-NNN-NNN-NNN-NNN.umNN.pools.vodafone-ip.de
                                          250-SIZE 157286400
                                          250 SMTPUTF8
                                          250-SIZE 157286400
2023-03-23 11:23:24     CLIENT -> SERVER: DATA
2023-03-23 11:23:25     CLIENT -> SERVER: Date: Thu, 23 Mar 2023 12:23:20 +0100
[…]

Zitat von xwe10

Name: VPS 2000 G10 (KVM-VServer with 8 core and 12GB memory)

Just a thought: The main difference between your laptop and your VPS is that the available host CPU cores are yours w.r.t. the former, while they're shared among all users w.r.t. the latter (and are very likely overbooked as well). I would expect a somewhat better behaviour using an RS ("root server") where the host CPU cores are allocated differently.

Zitat von Strlns

Aber der google-site-verification Record aus dem screenshot ist bei meiner Domain immer noch im CCP eingetragen und wird bisher nicht öffentlich sichtbar, soweit ich das nachvollziehen kann.

Sehe trotzdem nur den Record

Code

> $ dig -t TXT +short meine-domain.de                                                                                                                                                           
"v=spf1 mx a include:_spf.webhosting.systems ~all"

oder auch hiermit:

https://toolbox.googleapps.com/apps/dig/#TXT

Ist der Host-Eintrag falsch?

Dass der "google-site-verification Record" via dig -t TXT +short meine-domain.de.meine-domain.de sichtbar wäre, wurde wohl oben geklärt.

Was mich allerdings in diesem Fall verwundert, ist, dass tatsächlich die Erläuterung bei Google selbst (dort wird "zufälligerweise" die Verwendung von "@" angesprochen) direkt das korrekte Ergebnis hätte liefern sollen: Domain mit einem TXT-Eintrag schützen. Man müsste eigentlich nur die einzelnen Schritte wortwörtlich befolgen:

support_goolge_com.png

Hallo,

Bei den Domänen sollte man die Gültigkeitsdauer der Einträge zunächst heruntersetzen.

Falls noch nicht verbraucht, kann man für die Übertragung der Daten den Inklusiv-Snapshot verwenden (Export/Import), alternativ könnte man ggf. die Platte/Partitionen via dd o.ä. übertragen.

Nachdem die Festplatte dupliziert und am Ziel-RS vergrößert wurde, kann man Vergleichstests fahren. Passt das, sind ggf. in der Zwischenzeit aufgelaufene neue Daten – wenn man den alten Rechner nicht kurzerhand ausstellen kann – applikationsspezifisch inkrementell zu übertragen (hierzu lassen sich ohne Wissen der betroffenen Anwendungen keine Aussagen treffen).

Nach abgeschlossenen Tests am Zielserver würde man alle verwendeten Ports vom alten Rechner auf den neuen umleiten (der sich für dieselben Domänen zuständig fühlt, schließlich wurde die Konfiguration übertragen). In dem Moment kann man die neuen IP-Adressen bei den Domänen hinterlegen, und sobald diese weltweit bekannt sind, kann man den alten – nunmehr nicht mehr kontaktierten – RS außer Dienst stellen.

Wenn Pageant weiterhin verwendet werden soll, bietet sich ggf. ssh-pageant an. Bei Verwendung des WSL sollte man alternativ zu Putty/Pageant auch ssh-agent und Co. (ggf. unter Verwendung von keychain) einsetzen können. Wenn das vorgenannte Debian 11 allerdings in einer VM/Dual-Boot-Installation betrieben wird, ist das sowieso naheliegend. Viel mehr kann man mangels Details zur verwendeten Umgebung nicht konstatieren.

Zitat von Interessent

[…]

SERVICE ENTITLED STATUS DESCRIPTION
[…]
fips-updates yes enabled NIST-certified core packages with priority security updates
[…]
usg yes disabled Security compliance and audit tools

AHA! Die Aktivierung von "fips-updates", welche u.a. andere Kernel mit sich bringt, kann in der Tat der Grund sein, warum Probleme auftreten. Wenn man die Konformität mit FIPS 140-2 wirklich aktivieren will, sollte man unter anderem zwingend die Ubuntu FIPS 140-2 Modules FAQ durchlesen (dort ist auch Postfix erwähnt). An der Stelle kann ich aber nicht mehr weiterhelfen, weil ich diese Konfiguration selbst nicht nutze/nutzen würde; und ich fürchte, die Nutzerbasis einer solchen Ubuntu-Konfiguration ist insbesondere außerhalb der USA auch deutlich kleiner als die der Nicht-Nutzer.

Wenn es eine Option ist und es keine zwingenden Gründe gab, FIPS 140-2-konforme Kernel usw. zu verwenden, würde ich vorschlagen, das zunächst zurück­zu­drehen/de­ak­ti­vie­ren. (Nicht, dass FIPS 140-2 per se schlecht wäre, aber man sollte genau wissen, welche Vor-/Nachteile es bringt, eine konsequente Konfiguration sicherstellen können und potenzielle Seiteneffekte/Einschränkungen berücksichtigen.)