Posts by Paul

Ich habe es bisher (keine Mailcow, klassisches Postfix + Dovecot Setup) immer so gemacht:
1. Zweiten Mailserver aufgesetzt (mx2.example.com)
2. Dovecot Synchronisation aktiviert

3. Paralleler Betrieb für eine kurze Zeit, bis alles anstandslos funktioniert.

5. Dovecot DNS umschalten auf den neuen Server

6. (alter) mx1 aus dem DNS nehmen und nach kurzer Zeit abschalten.

7. Währenddessen Webmail während einer kurzen Downtime migrieren.

Das sollte mit Mailcow doch auch so in etwa möglich sein, sind ja schließlich die gleichen Komponenten.

Das DNS ist eigentlich die größte Herausforderung. Da lieber direkt möglich früh die TTL sehr niedrig stellen.

#TeamFeinschmecker

Ente.jpg

Die DNS Einträge musst du dort ändern, wo du sie registriert hat (in der Regel nutzt du nämlich auch deren Nameserver). Solange die Domain bei einem anderen Anbieter liegt, kannst du sie nicht bei Netcup administrieren. Du musst bei deinem jetzigen Anbieter einfach die entsprechenden DNS Records auf deinen Server hier setzen. Mehr nicht.

Mila, kann verkaufen, irgendwann ist sie ein Superstar!

christianr wrote:

Und Netcup selbst schreibt nicht ohne Grund auf der Produktseite der RS:

AMD EPYC™ 7702
(max. 3,35 GHz je Kern)

Was die Marketing Abteilung auf der Webseite schreibt und was technisch letztendlich umgesetzt wurde, können sehr oft 2 Paar Schuhe sein Solche Infos muss man immer mit etwas Vorsicht ansehen, gerade bei solchen Detailfragen.

Ich sage es einfach mal so direkt: Xen ist tot. Das fängt man lieber gar nicht mehr an. LXC ist ja eine Container Engine. Das ist so nicht direkt mit Xen vergleichbar. Das was dem am nächsten käme, wäre eher KVM/qemu.

Security lässt sich so pauschal nicht sagen. Kommt immer auf deine Umsetzung an und was du darauf eigentlich betreibst. Ähnlich sieht es mit der Usability aus. Es findest sich fast für alles ein entsprechendes Szenario, worauf es passen könnte.

Valkyrie wrote:

Auweiah, kam mir schon so ruhig vor

Mich würde der Grund mal interessieren. Kontrovers waren seine Posts zwar manchmal, aber einen triftigen Grund für eine Sperre habe ich da nie erkennen können.

geekmonkey wrote:

Das geht mit dem normalen Editor nicht, oder?

Ich habe ihn selbst nie genutzt, daher musste ich das gerade selbst mal ausprobieren. Aber da hast du recht, da finde ich die Option jetzt auch nicht. Scheint wohl momentan nur mit dem Markdown Editor zu funktionieren (welchen ich sowieso empfehlen würde).

geekmonkey wrote:

interessante Möglichkeit, hatte ich gar nicht auf dem Schirm. Funktionieren Callouts (also die rot hinterlegten Ausrufezeichen oder blau hinterlegten Hinweise) bei Markdown? Oder bin ich nur zu doof?

Ja, Wiki.js bietet neben der normalen Markdown Synatx auch zusätzliche Funktionen wie Hinweis/Warn Blöcke, Tabs oder auch mathematische Formeln (Latex).

Der erwähnte Info Block lässt sich z.B. so definieren

Ich habe mich für Wiki.js entschieden. Hatte vorher Mediawiki im Einsatz. Der größte Vorteil von Wiki.js ist für mich, dass es die Artikel als klassiche Markdown Files abspeichert und optional in ein Git Repo sichert. So kann man jederzeit auf die Dateien zugreifen, selbst wenn das Wikisystem an sich mal nicht mehr funktionieren sollte. Auch lässt sich das Wiki aus dem Git Repo wiederherstellen. Diese Kompatibilität würde ich mittlerweile allen sonstigen Funktionen vorziehen.

Eine Möglichkeit wäre, dass du aktuelle Daten, die momentan noch auf der normalen Festplatte liegen auf den zusätzlich gebuchten (NFS) Speicher verschiebst und zwar so lange bis du wieder unter 50% Belegung kommst. Dann solltest du wieder einen Snapshot erstellen können (fstrim nicht vergessen). Hängt natürlich damit zusammen, ob das überhaupt machbar ist. Dokumente, Bilder, andere Medien sollte hier kein Problem sein. Wenn du eine große Datenbank hast, dann wird das natürlich nichts.

Welche Funktion genau möchtest du denn im SCP haben? Du hast ja einen Managed Server gebucht, sprich eine Art Webhosting auf einem eigenen Server. Zugriff auf Plesk hast du ja. Funktionen am Server stehen hier natürlich nicht zur Verfügung. Ich habe etwas den Eindruck, dass das SCP nicht das ist, wofür du es hältst. Über das SCP administriert man ja einen Server (Installation, Neustarts, ...). Das sind ja alles Dinge, die du bei einem Managed Server gar nicht selbst machen musst bzw. darfst. Der eigentliche Inhalt wird ja über Plesk verwaltet.

Die Netstat Ausgaben sind immer mit Vorsicht zu genießen (im Grunde eh deprecated, man sollte mittlerweile lieber ss aus dem iproute Paket nutzen). Schau einfach, ob an deinem Interface eine IPv6 Adresse anliegt (mit `ip a`). Wenn nicht, ist alles ok und du musst dir keine weiteren Gedanken machen.

stroet wrote:

wenn ich das richtig verstehe beinhaltet das klassischen Setup kein Weninterface für die Administration.

Alles über die Konsole zu machen finde ich jetzt nicht so prickelnd.

Doch, das genannte Postfixadmin ist ja die gewünschte Webadministration: https://github.com/postfixadmin/postfixadmin

Die fertigen Pakete wie Mailcow haben absolut ihre Vorteile, wenn es darum geht, möglichst schnell was auf die Beine zu stellen. Die Frage ist immer nur, was machst du, wenn es mal Probleme gibt. Wenn man nicht wirklich weiß, was da eigentlich so genau läuft und wie es konfiguriert wurde, dann verliert man in der Problemanalyse schnell mal wertvolle Zeit, die man eigentlich zu diesem Zeitpunkt nicht hat. Wenn man sich aber mit den Komponenten sowieso gut auskennt, spricht da absolut nichts dagegen. Aber gerade zu Beginn kann ich aber nur wärmstens empfehlen, sich auch mit den Grundlagen zu beschäftigen. Früher oder später muss man das sowieso.

Ich würde in diesem Fall zu einem klassischen Setup raten:

* dovecot
* postfix
* postfixadmin

Damit lässt sich das alles relativ problemlos einrichten. Letztendlich bauen die fertigen Lösungen auch nur auf diesen bzw. ähnlichen Komponenten auf, sind aber nicht direkt auf das oben genannte Setup ausgelegt, weswegen ein manuelles Setup sicher nicht so viel aufwändiger wäre.

Ein VPS 200 hat jetzt nicht unbedingt so viel Speicherplatz zur Verfügung. Da wäre die Frage, ob dir das auf Dauer reicht. Oder planst du sowieso noch externen Storage einzubinden? Evtl. über NFS, S3 oder ähnliches?

Evtl. hilft es ja sogar, wenn man im WCP eine neuere PHP Version auswählt. Vielleicht ist dort php-tidy ja auch schon verfügbar. Mangels Webhosting Paket kann ich es jetzt nicht testen, aber ein Versuch ist es sicherlich wert.

michaeleifel wrote:

Betreibt jemand zufällig eine Gitea Instanz auf dem Webhosting oder kennt sich sehr gut aus und kann mir paar Kickoff Tipps geben?

Normalerweise nutze ich ja Ansible / Docker / Kubernetes für Setups, aber brauche aktuell was Server unabhängiges wo ich paar private Ansible Playbooks hosten kann und wollte dafür das Webhosting Paket "missbrauchen".

Danke

Das wird leider nicht funktionieren. Gitea startet seinen eigenen Webservice, den wirst du so nicht unter einem Webhosting Produkt starten können. Dazu braucht es ja auch einen sshd Service. Für Gitea wirst du um einen eigenen Server nicht herum kommen.

Immerhin hat dein Interface nun schon mal die richtige IP bekommen (10.0.0.3). Das hat ja vorher komplett gefehlt.

Kannst du mit `ifdown ens4` bzw. anschließend mit `ifup ens4` etwas bewirken (falls das so geht)?

Siehst du denn im Log irgendwas? Was sagt denn z.B. `systemctl status networking`? oder auch `journalctl -r`? Er scheint ja das NIC nicht richtig zu konfigurieren.