Beiträge von Paul

Wie KB19 schon angedeutet hat. Man darf nicht vergessen: Nach dem Wechsel ist vor dem Wechsel. Hat man den Sprung von Windows auf Linux einmal geschafft, hört es ja nicht auf. Dann fängt das Distro-Hopping an. Von Ubuntu auf Fedora, dann mal Suse. Irgendwann landet man dann sowieso bei Archlinux . Nicht zu vergessen die ganzen Desktop Umgebungen. Von KDE auf GNOME hin zu XFCE oder i3 und wieder zurück.

Die Diskussionen in Windows mit den Änderungen an der Oberfläche gibt es ja bei Linux genauso. Der Wechsel von Gnome 2 auf 3 oder auch von KDE 4 auf 5 war nicht minder leiser.

Das größte Problem an Windows ist vor allem der Online Account Zwang. Microsoft kann dir den jederzeit sperren, wenn sie der Meinung sind, du hast eine falsche Meinung oder etwas falsches geschrieben. Meinen lokalen Linux Account nimmt mir keiner so einfach weg.

Kraus Geht es dir nur um den SSLLabs Test? Wenn ja, dann teste das bitte nochmal mit einem anderen Tool oder einer anderen Seite. SSLLabs hatte in letzter Zeit ein paar Probleme. Die Seite war die Tage zum Teil sogar mal komplett down. Ich würde aktuell auch nicht ausschließen, dass das Problem auf Seiten SSLLabs liegt, wenn es denn mit anderen Tools problemlos funktioniert. Teste das also mal mit einer alternativen Methode. Und versuche auch mal die Dev Version: https://dev.ssllabs.com/ssltest/ (evtl. funktioniert es ja dort).

Zitat von eripek

Also nur so aus Interesse: Warum benützt Ihr noch Microsoft-Produkte?

Mein Gaming Desktop läuft mit Windows (zwangsläufig). Auch benötige ich diesen um gewisse Firmware Updates (z.B. für meine Logitech Produkte) installieren zu können. Dafür sind dort aber auch sonst keine (persönlichen) Daten drauf. Daher kann ich damit gut leben.

Aber nicht alle Produkte sind direkt schlecht, nur weil sie von Microsoft kommen. Mein im Grunde wichtigstes Tool (VS Code Editor) kommt auch von Microsoft. Und das läuft auf allen meinen Linux Systemen. Funktioniert wunderbar. Oder auch eine SwiftKey Tastatur auf meinen Mobilgeräten.

Zitat von philw95

Bei dem Netcup Images (Debian 12 zumindest) ist das so Standard. Finde es aber auch sehr komisch.

Bei mir heißen die Standard ens3 bei Allen Servern. Installiere Debian aber immer über die Iso von Netcup. Nicht die Images.

Soll wohl schon seit Debian 9 Standard so sein. Man kann aber die Alten Namen wieder Aktivieren. In dem Fall eth0

Ah ok, danke. Gut zu wissen. Die /etc/network/interfaces überschreibe ich direkt mittels Ansible. Daher kannte ich die mitgelieferte Config so gar nicht.

Zitat von Bud

Der Fehler bleibt nach dem reboot der gleiche.

Auf meinen anderen Debian-Installationen sieht die interfaces ebenso aus.

Kontrolliere dann wirklich nochmal, ob die Daten mit denen im SCP übereinstimmen. Auch wenn das eigentlich erst einmal keinen Fehler werfen sollte. Wenn man ein falsches Gateway angibt, sollte eigentlich nur das Routing nicht funktionieren. Was sagt denn ip a bzw. ip r? Siehst du dort deine neue IP? Könnte auch sein, dass das Interface zwar hochkommt und nur der Service an sich wegen irgendwas meckert, aber das Netzwerk prinzipiell funktioniert.

Zitat von Bud

Wie jetzt, du trinkst deinen heißen Kaffee nicht auf Ex?

Die Zeiten sind schon lange vorbei . Und damals stand auch noch kein Kaffee auf der Getränkeliste als man so was noch gemacht hatte.

Ja, nimm den Teil mit den ens3 mal komplett aus der /etc/network/interfaces raus. Auch das loopback Interface sollte nicht 2 mal definiert werden. Auch das solltest du raus nehmen. In der /etc/network/interfaces sollte nichts mehr stehen außer dem include source.

Zitat von martin\

Hab auch zwei von früher, die sind mega, weil sie schön groß sind. 😁

Interessant. Genau das hat mich eigentlich immer davon abgehalten eine zu bestellen . Da ich meine primär auch für Kaffee nutze, sind mir selbst die Standard 325ml Tassen zum Teil fast schon zu groß. Irgendwie kühlt darin dann der Kaffee zu schnell ab.

Was mir hier auch auffällt: Heißt dein NIC überhaupt ens3? Meine Debian 12 Server hier bei Netcup haben alle ein eth0 NIC. Kontrolliere das mal mit der Ausgabe von ip a.

Zitat von Bud

Nicht das ich erkennen würde:

Spoiler anzeigen

pasted-from-clipboard.png

Du hast einmal DHCP für dein ens3 NIC aktiviert und in interfaces.d/ vermutlich eine statische Konfiguration. Eins von beiden müsste wohl weg. Du könntest deine 50-cloud-init.cfg mal zensiert hier posten. Vielleicht sehen wir ja dann was

Wenn du die Konfiguration in /etc/network/interfaces.d direkt änderst, starte den Server anschließend mal lieber neu. Ein reiner Neustart von networking.service reicht hier oft nicht. Stelle auch sicher, dass hier kein netplan im Einsatz ist. Ich vermute, du nutzt Debian als OS. Da beobachte ich das oft, dass man hier networking.service nicht neustarten sollte, sondern lieber einen Neustart macht, man man grundlegende Änderungen (IPs) vornimmt.

Zitat von Bud

Anfangen bzw. testen möchte ich das Ganze mit der munin.conf. Diese unterscheiden sich nur darin, dass der jeweilige Server auf dem munin läuft, sich selbst mit 127.0.0.1 überwacht – gibt es irgendeinen Grund, warum ich hier nicht die normale IP des Servers verwenden sollte? Weil wenn nicht, kann ich diese drei Dateien 1:1 aufbauen.

Du kannst auch deinen Munin Server über die normale IP überwachen. Das ist gar kein Problem. Du musst nur sicherstellen, dass der Agent (auf dem Munin Server) auch auf dieser IP lauscht und nicht nur auf 127.0.0.1. Darüber hinaus in der Firewall sicher stellen, dass der Munin Port nicht nach außen hin freigegeben ist. 127.0.0.1 ist lediglich der Standardwert, damit die mitgelieferte Konfiguration universell einsetzbar ist. Aber es ist auch völlig ok, dies auf die normale IP zu ändern, wenn das für dich einfacher ist.

Vermutlich ist es genau umgekehrt. Bud verteilt gerade seine Agenten, äh Server hier unter uns, nur damit wir eines Tages aufwachen und merken müssen, dass da ein teuflicher Plan dahintersteckt und er uns alle infiltriert hat.

Also ich mag die österreichische Sprache bzw. Dialekt trifft es vermutlich etwas besser

Zitat von KB19

Ach

Das habe ich mir auch gerade gedacht. Von wegen zu viel Interpretation. Blöd sind wir schließlich nicht - auch wenn wir viel zu viel Geld bei Netcup lassen *hust*.

Zitat von Bud

Ich werde demnächst eine Handvoll Server in Biete werfen, weil ich vor den Prüfungen keine Verwendung dafür habe, und sie einfach nur kosten produzieren. Als Testserver würde ich gerne einen der folgenden zwei behalten, kann mich aber nicht entscheiden:

Spoiler anzeigen

pasted-from-clipboard.png

Welchen würdet ihr als Testserver behalten, und welchen abgeben? Eigentlich sollte der VPS 500 G9 zum testen für die meiste Software reichen, aber 8 GB RAM für 4,95 € im Monat ist halt auch etwas, was ich ungern abgebe... Was würdet ihr tun?

Behalte den VPS 1000 G9 mit 8 GB RAM. Den VPS 500 G9 nehme ich dir gerne ab

Ich nutze jetzt seit vielen Jahren Zabbix. Kenne aber auch Nagios/Icinga recht gut. Dadurch dass Zabbix aber alles in der DB speichert und die API einfach mächtiger ist, gefällt mir das etwas besser. So kann ich neue Server automatisiert über Ansible direkt registrieren und auch bei Wartungsarbeiten entsprechende Downtimes setzen. Es braucht ein wenig Eingewöhnung, aber wenn man das mal durchblickt hat, ist es ein sehr mächtiges Monitoring Tool. Nur für HTTP/SSL Checks kommt hier noch eine zusätzliche uptime-kuma Instanz zum Einsatz.

Oder noch besser: Einen SSH Jumphost nutzen. Die neuen 1€ VPS sind dafür ideal!

Zitat von Bud

Gerade herausgefunden, dass einer meiner Server über drei verschiedene „netcup-Domains“ erreichbar ist.

Code

v2201410**********.yourvserver.net
v2201603**********.luckysrv.de
v2201811**********.megasrv.de 

Aus reiner Neugierde: Hat das einen Grund? Oder sind das einfach „Altlasten“?

Rein aus Interesse. Wie bist du darauf denn gekommen?

In Hinblick auf SEO definitiv ungünstig und gut zu wissen. Hier sollte man definitiv darauf achten, dass man in seinem Webserver oder Reverse Proxy einen 404 Default vHost konfiguriert, damit hier nicht unnötigerweise unter einer nicht bekannten Domain Inhalte ausgeliefert werden.

Auch sollte die hinterlegte E-Mail Adresse nicht nur eine Weiterleitung sein, da man ggfs. über genau diese Adresse mit dem Netcup Support kommunizieren muss.