Wieso hat das funktioniert obwohl mein VPS offline war?
Ich gehe mal davon aus, dasy es einach die Datei auf dem host neu erstellt (qcow2 Datei)
Server administrieren - wo fange ich an?
- Bud
- Erledigt
-
-
Wieso hat das funktioniert obwohl mein VPS offline war?
Die Festplatte des virtuellen Servers ist ja eigentlich nichts anderes als eine Datei auf dem Host.
Die wird gelöscht und das wars.
-
Zwischen RS und VPS gibt es diesbezüglich keine Unterschiede. Die sind beide virtualisiert.
Echtes dediziertes Blech hat netcup nicht.
-
Bei der Umfrage verblüfft es mich jetzt doch ein wenig, dass debian so großes Übergewicht hat. Ich hätte das knapper eingeschätzt.
-
Also wende es bei einem RS nicht gegangen da dieser wirklich heruntergefahren wäre, aber beim VPS werden nur die arbeitenden Dienste deaktiviert?
Netcup VPS und RS sind virtuelle Maschinen auf KVM Basis
Bei den RS weiß man was für Hardware auf dem Wirstsystem liegt (EPYC 7702), bei den VPS nicht. Auf dem Wirstsystem liegen mehrere, wenn nicht Hunderte Gastsysteme so wie dein Server.
Echtes Blech wird oft als dedizierter Server beworben, das gehört dann nur dir.
-
Die RS haben 2,5 Gbit/s Netzwerkanbindung, die VPS "nur" 1 Gbit/s(Reicht trotzdem dicke)
Und die RS haben dedizierte Resourcen(RAM und CPU)
-
Zusätzlich zu oben genanntem haben die RS mehr CPU-Features durchgereicht.
Es gab hier z.B. einen Thread dass neuere MongoDB Versionen auf den VPS nicht mehr laufen (wegen fehlendem AVX).
Hier noch ein paar Benchmark-Werte meiner Server. Mein RS G7 ist schneller als die VPS G8 (pro Core).
Geekbench 5 (Single / Multi Core)
vps500 G8 2 vCores 490 817 vps 200 G8 1 vCores 486 483 rs1000 G7 plus (6core xeon E5-2680 v4 6 Kerne 694 3177 rs1000 G9.5 (EPYC 7702P) 4 Kerne 1003 3692 Zu den ersten Schritten auf einem neuen Server zählen bei mir:
- eigenen Benutzer anlegen und sudo Rechte geben (Mach ich schon während der Installation)
- SSH: Passwörter verbieten, nur noch Keys erlauben.
Wenn man das nicht macht (und gute Passwörter verwendet) geht die Welt nicht unter. Trotzdem empfehlenswert.
- SSH: root verbieten, und mittels 'AllowUsers username1 username2' nur bestimmte user den SSH Zugang erlauben.
Auch hier geht die Welt nicht unter, aber wenn man root nicht verbietet hat der Angreifer schon mal einen existierenden User. Also die halbe Miete
- SSH: Port ändern.
Reduziert die Anzahl der Logeinträge enorm, bzw entlastet den Server von unnötigen Arbeiten.
- evtl fail2ban damit Angreifer eine Zeit lang blockiert werden.
- Firewall (ufw) installieren und nur die benötigten Ports öffnen.
Wie oben, auch hier geht die Welt nicht unter wenn man es (noch) nicht sofort macht.
- Mailversand einrichten, damit man mails vom System bekommen kann.
z.B. mittels postfix oder für den Anfang leichter: msmtp (https://wiki.debian.org/msmtp)
In der msmtp config trägt man die SMTP Daten von einem ganz normalen Netcup Mailkonto ein (Username:passort).
Und jetzt noch das für mich wichtigste, und ein guter Grund den Mailversand einzurichten:
- unattended-upgrades (https://wiki.debian.org/UnattendedUpgrades) (apt install unattended-upgrades apt-listchanges)
Damit werden die updates automatisch eingespielt, und wenn man es konfiguriert bekommt man Mails was getan wurde, und ob ein reboot notwendig ist.
Selbst wenn man ein paar Monate keine Zeit hat sich um den Server zu kümmern, muss man sich mit unattended-upgrades keine große Sorgen machen.
Es gibt ein minimales Risiko dass durch ein Update etwas nicht mehr richtig tut, ohne dass man es sofort merkt. Ist mir aber in vielen Jahren mit diversen Servern noch nie passiert.
- backup mittels borg-backup. https://github.com/witten/borgmatic ist hierzu ein beliebtes script (apt install borgmatic)
Gibt natürlich auch viele andere Backup Lösungen.
Ich wünsch Dir viel Erfolg und Spaß mit Deinem Server
Nochmal das Wichtigste (alle Befehle als root, oder mittels sudo):
Code
Alles anzeigen> apt install unattended-upgrades apt-listchanges > sudo nano /etc/apt/apt.conf.d/50unattended-upgrades Unattended-Upgrade::Mail "meinuser@meine-domain.de"; // oder "root", wenn man das System entsprechend konfiguriert hat, wie weiter unten beschrieben. > dpkg-reconfigure -plow unattended-upgrades > apt install msmtp msmtp-mta > nano /etc/msmtprc #------------------------------------------------------------------------------------ # A system wide configuration file is optional. # If it exists, it usually defines a default account. # This allows msmtp to be used like /usr/sbin/sendmail. account default # The SMTP smarthost host smtp-server.von.netcup.de # Use TLS on port 465 port 465 tls on tls_starttls off # Construct envelope-from addresses of the form "user@oursite.example" from "Servername <mein-from-name@meine-domain.de>" # set above from as sender. Does not work in buster or older set_from_header on auth on user der-bernutzername-deines-mailkontos password somepassword aliases /etc/aliases #‘syslog [(on|off|facility)]’ # Enable or disable syslog logging. The facility can be one of ‘LOG_USER’, ‘LOG_MAIL’, ‘LOG_LOCAL0’, …, ‘LOG_LOCAL7’. # The default is ‘LOG_USER’. Syslog logging is disabled by default. # Syslog logging with facility LOG_MAIL instead of the default LOG_USER syslog LOG_MAIL # Enable logging to the specified file. An empty argument disables logging. The file name ‘-’ directs the log information to standard output. #logfile - #logfile ~/.msmtp.log > chmod 0600 /etc/msmtprc > nano /etc/aliases # Send root to ... root: mail-empfänger@meine-domain.de # Send everything else to ... default: mail-empfänger@meine-domain.de > newaliases > systemctl enable msmtpd > systemctl start msmtpd # Test if mail is working > apt install mailutils # oder bsd-mailx (debian 11 bullseye: fail2ban can't send e-mail using mail from bsd-mailx) > echo "test mail." | mail -s Test mail-empfänger@meine-domain.de > echo "test mail." | mail -s Test root -
Zu den ersten Schritten auf einem neuen Server zählen bei mir:
…
Schöne Auflistung der ersten Schritte ohne dabei in Absolutismen zu verfallen (muss man unbedingt…). Gefällt mir echt gut. Hat imho mehr als nen Daumen hoch verdient deshalb lobende Erwähnung in extra Post
(würd mir den Beitrag jetzt gerne noch als Favorit speichern, gibts hier aber wohl ned
) -
Ich bin immer als root angemeldet, denn es geht mir auf den nerv, bei jedem Befehl das passwort eingeben zu müssen.
Als aber auch die pw Authentifizierung komplett abgeschaltet für ssh, sodass man ohne key direkt disconnected wird.
-
Ich bin immer als root angemeldet, denn es geht mir auf den nerv, bei jedem Befehl das passwort eingeben zu müssen.
Was ist das denn für ein Linux, wo man das bei jedem Befehl machen muss?
-
ch bin immer als root angemeldet, denn es geht mir auf den nerv, bei jedem Befehl das passwort eingeben zu müssen.
mal sudo su versucht?
Aber mein Betrag zum ursprünglichen Thema
ich bin ja noch aus DOS Zeiten
mein erster Schritt auf jedem Server ist
apt install mc (früher stand hier noch nano, aber das ist mittlerweile in jeder Installation dabei)
Ein Dateimanager der auch gerade Anfängern vieles erleichtern kann
Erst danach widme ich mir der sshd_config
-
ich bin ja noch aus DOS Zeiten
mein erster Schritt auf jedem Server ist
apt install mc (früher stand hier noch nano, aber das ist mittlerweile in jeder Installation dabei)
Ein Dateimanager der auch gerade Anfängern vieles erleichtern kann
Erst danach widme ich mir der sshd_config
same here!!
-
Ich bin immer als root angemeldet, denn es geht mir auf den nerv, bei jedem Befehl das passwort eingeben zu müssen.
Einfach die visudo anpassen https://linuxhandbook.com/sudo-without-password/
-
mein erster Schritt auf jedem Server ist
Mach ich auch wenns Linux ist. Erleichtert so viel!
danach mache ich erst mal apt-get upgrade und apt-get update sowie apt-get dist-upgrade
Mir wurde gesagt das wäre zu früh aber ich mag das früh erledigt haben.
-
Bei der Umfrage verblüfft es mich jetzt doch ein wenig, dass debian so großes Übergewicht hat. Ich hätte das knapper eingeschätzt.
Wir sind halt old-school. Zudem ist es nicht unbedingt immer besser, auf einem Server "das neueste" drauf zu haben, Debian ist bei den Paketen häufig älter, aber halt dadurch auch ein stabiles Workhorse. Und das ist bei einem Server nunmal wichtiger.
danach mache ich erst mal apt-get upgrade und apt-get update sowie apt-get dist-upgrade
Das apt-get update sollte aber schon vor dem upgrade kommen, denn mit dem update schaut apt ja bei den Quellen nach, ob es Upgrades gibt. Ohne das kommt bei apt-get upgrade halt einfach nix.
-
Bei der Umfrage verblüfft es mich jetzt doch ein wenig, dass debian so großes Übergewicht hat.
Hast du debian jetzt Fett genannt?
-
Der Grund, warum ich meine Server auf Ubuntu laufen lasse, ist eher "historisch" bedingt.
Der erste Server, den ich als Admin übernehmen musste, war ein Ubuntu-Server.
Da habe ich mich halt in Ubuntu eingearbeitet und danach nie wieder einen Grund gehabt zu wechseln.("The devil you know", "Never change a winning team")
Hätte genauso gut auch Debian sein können. Dann wäre ich heute Debianer.
(Bin nur froh, dass es kein Windows-Server war.
) -
