Im Webinterface kannst du folgende Betriebssysteme installieren. Die tatsächliche Auswahl kann je nach Server abweichen. Maßgeblich ist die Liste im Webinterface.
Über das Rescue-System kannst Du auch Proxmox installieren. Beachte dabei bitte, dass dein Prozessor Virtualisierung beherrschen sollte. Weitere Informationen dazu erhältst du beim Support.
In der Regel steht dein Dedicated Server in weniger als 15 Minuten zur Verfügung. Die Provisionierung haben wir automatisiert. Sollte bei der Zahlung oder automatischen Bereitstellung etwas schiefgelaufen sein, kann es etwas länger dauern.
Sobald dein Server bereitsteht, ist der Server im Webinterface mit einer IP-Adresse ausgestattet. Du kannst den Server dann mit einem Betriebssystem ausstatten.
Melde dich gerne im Support, wenn die Bereitstellung etwas länger dauert. Wir geben dir dann Auskunft über den Status deiner Bestellung.
Passiert es Dir, dass Du das Passwort für Deinen Sinusbot vergessen hast, ist das ärgerlich, aber kein Drama. Mit ein paar einfachen Schritten kannst Du es auf eine neue Wunsch-Passphrase zurücksetzen. Hier zeigen wir Dir, wie Du das Passwort erfolgreich zurücksetzt.
Solltest du das Passwort nicht vergessen haben und einfach nur das Passwort ändern wollen, kannst du direkt zum Passwort Reset.
Überschreibungs-Modus aktivieren
Per SSH verbinden
Zunächst musst du dich per SSH auf deinem Server anmelden. Hast du das erledigt, solltest du in das Sinusbot-Verzeichnis gehen. Im Normalfall handelt es sich um das Verzeichnis /opt/sinusbot.
Laufende Instanzen stoppen
Nun musst du alle laufenden Sinusbot-Instanzen stoppen. Wir nutzen dafür die etwas härtere Methode und stoppen alle Prozesse mit dem Namen „sinusbot“:
pkill -f ".sinusbot"
Als Sinusbot-User einloggen
Um den Sinusbot starten zu können, braucht es einen gesonderten User. Dieser heißt meist sinusbot. Als diesen User melden wir uns in der SSH-Konsole nun an.
Nutze dazu den folgenden Befehl, tausche aber eventuell den Nutzernamen „sinusbot“ mit dem aus, den du bei der Installation gewählt hast.
su sinusbot
Rescue Mode starten
Du bist nun als Sinusbot-User in der SSH-Sitzung angemeldet. Erst jetzt können wir den Sinusbot im Passwortüberschreibungsmodus starten. Achtung: Dieser Modus ist nur für das Zurücksetzen des Passworts gedacht. Dein Passwort ist nicht sicher, wenn du es an den Prozessnamen anhängst. Aus diesem Grund ist diese Methode nur als temporäres Passwort anzusehen. Dieser Modus überschreibt das Admin-Passwort für die aktuelle Sitzung.
Folgender Befehl ist zum Starten des PW Reset-Modus nötig:
./sinusbot -override-password=temppassword123
Sinusbot im „Rescue Modus“
Der Sinusbot ist nun im Rescue-Modus gestartet. Wichtig: Lasse die SSH-Sitzung offen und schließe sie nicht.
Öffne jetzt das Sinusbot-Webinterface unter Server-IP:8087 im Browser. Du kannst dich mit dem User „admin“ und dem temporären Passwort „temppassword123“ anmelden.
Sinusbot Passwort Reset
Nachdem du dich jetzt im Webinterface anmelden kannst, musst du ein neues Passwort für deinen Admin-User setzen. Navigiere dazu via „Settings“ > „User Accounts“ und klicke beim Admin rechts auf das „Edit“-Icon. Im öffnenden Dialog kannst du jetzt ein Passwort für den Admin-Nutzer vergeben. Erledige das und speichere die getätigten Änderungen.
Danach wirst du automatisch abgemeldet. Melde dich jetzt noch nicht mit den neuen Daten an.
Gehe in die SSH-Sitzung und drücke STRG+C – dies beendet den Rescue-Modus des Sinusbots. Jetzt kannst du dich auch aus der SSH-Sitzung des Sinusbot-Users abmelden und mit dem Root-User weitermachen.
exit
Damit bist du höchstwahrscheinlich wieder als Root-User angemeldet. Starte jetzt den Sinusbot ganz normal. In der Regel geht das mit:
service sinusbot start
Nun solltest du wieder in den Browser gehen und die Seite einmal aktualisieren. Jetzt meldest du dich mit den neuen Admin-Zugangsdaten an. Der Username ist dabei „admin“ und das Passwort das von dir gewählte neue Zugangspasswort. Solltest du das Passwort vergessen haben, … fange von vorne an.
MySQL/MariaDB Root-Passwort zurücksetzen: So geht’s
Vergisst Du Dein Root-Passwort für MySQL oder MariaDB, kann das ziemlich ärgerlich sein. Aber keine Sorge, mit ein paar kurzen Befehlen kannst Du das Problem schnell lösen. Hier zeigen wir Dir, wie Du das Root-Passwort zurücksetzen kannst, damit Du wieder vollen Zugriff hast.
Voraussetzungen
Bevor Du beginnst, stelle sicher, dass Du eine SSH-Verbindung zu Deinem Server aufbauen kannst. Dies ist notwendig, um die folgenden Schritte durchzuführen.
Schritt 1: Verbindung herstellen
SSH-Verbindung: Verbinde Dich per SSH mit Deinem Server und öffne die Root-Befehlszeile.
MySQL-Server testen: Prüfe, ob Du möglicherweise doch Zugriff auf den MySQL-Server hast, indem Du den Befehl mysql eingibst. Erhältst Du keinen Authentifizierungsfehler, bist Du bereits angemeldet. Auf Debian und Ubuntu ist das oft der Fall, weil sich der System-Root per Socket ohne Passwort anmelden darf. Setze dann direkt das neue Passwort und überspringe die Schritte 2 bis 4:
ALTER USER 'root'@'localhost' IDENTIFIED BY 'neues-passwort';
Schritt 2: MySQL ohne Rechte-Tabelle starten
Um das Passwort zurückzusetzen, muss MySQL in einem Modus gestartet werden, bei dem die Rechte-Prüfung deaktiviert ist. Dies soll nur für die Dauer des Passwort-Resets geschehen, da in diesem Modus jeder auf alle Datenbanken zugreifen kann.
MySQL-Server stoppen: Gib folgenden Befehl ein, um den MySQL-Server zu stoppen:
systemctl stop mysql
MySQL im Unsafe-Modus starten: Starte den MySQL-Server ohne Rechte-Prüfung und ohne Netzwerkzugriff. So kann sich währenddessen niemand von außen verbinden:
Einen öffentlichen Testserver für jeden bieten wir nicht mehr an. Testserver gibt es nur noch auf Anfrage. Wie das funktioniert, erklären wir im FAQ-Artikel Kann ich eure Server vor dem Kauf testen?
Hierzu erhalten wir jedoch sehr oft kurz nach Bereitstellung des Testservers irritierte Anfragen und Beschwerden, warum man denn für den kostenfreien Testserver eine Rechnung erhalten würde bzw. warum man plötzlich angeblich zum Verlängern des Servers gezwungen wird.
Hinweis im Webinterface
Wir sind ein Prepaid-Anbieter!
Wir möchten hier nochmal ganz deutlich und transparent klarstellen: Unsere Testserver sind kostenfrei und bringen keinerlei Verlängerungs- oder Zahlungsverpflichtung mit sich. So wie es übrigens auch bei jedem unserer anderen Produkte nach Kauf der Fall ist (Prepaid)!
Warum erhalte ich keine Rechnung?
Wir legen direkt nach der Testserver-Bestellung eine Kündigung für deinen Server an. Somit wird keine Rechnung zur optionalen Verlängerung erstellt. Der Server läuft dann zum Ende der Testphase einfach aus. Wenn du den Server verlängern möchtest, kannst Du die Kündigung einfach entfernen. Du bekommst dann in der Folge-Nacht eine Rechnung zur Verlängerung. Diese musst Du aber nicht bezahlen.
Was passiert, wenn ich nicht bezahle?
Bezahlst du die Rechnung nicht, passiert gar nichts. Das Produkt (hier: der Testserver) wird einfach zum Ende der Laufzeit gelöscht, ohne dass du nochmal jemals noch etwas von uns hörst.
Also, keine Bange! Wir wollen niemanden in eine Falle locken, deshalb kommunizieren wir ganz klar im Webinterface, dass du selbstverständlich keinerlei Verpflichtungen eingehst. Lehne dich zurück, powere dich und deinen Testserver aus und schau‘, ob du mit dem Server und uns zufrieden bist! 🙂
Am schnellsten geht es im Cloud Manager: Reiter „SSH“, bei „Root-Login“ die Option „Nur mit SSH Key“ wählen. Dafür muss der Guest Agent laufen. Manuell setzt du PasswordAuthentication no in der SSH-Konfiguration und startest den SSH-Dienst neu. Das klappt auf jedem Linux-Server. Wichtig in beiden Fällen: Erst prüfen, ob die Anmeldung mit deinem SSH-Key klappt, dann das Passwort abschalten.
Warum sich das lohnt: Jeder Server mit offenem Port 22 bekommt rund um die Uhr automatisierte Login-Versuche. Ohne Passwort-Login laufen diese Versuche ins Leere, egal wie viele es sind.
Über das Webinterface
Im Cloud Manager kannst du in den VPS-Einstellungen die Passwort-Authentifizierung für den Root-Login ein- und ausschalten. Voraussetzung ist der aktive Guest Agent. Gehe in den Reiter „SSH“ und wähle bei „Root-Login“ die Option „Nur mit SSH Key“ aus.
Cloud Manager, Reiter „SSH“: Root-Login auf „Nur mit SSH Key“ stellen
Nach dem Speichern lässt dein Server den Root-Login nur noch mit einem SSH-Key zu. Arbeitest du zusätzlich mit weiteren Benutzern, nutze den manuellen Weg, der gilt für alle Konten.
Smart Essential: Hier gibt es den Reiter „SSH“ nicht, im Webinterface steht nur der Reset des Root-Passworts zur Verfügung (ebenfalls mit Guest Agent). Läuft der Guest Agent, kannst du die Einstellung über die Prepaid-Hoster API setzen. Ohne Guest Agent nimmst du den manuellen Weg.
Manuell per SSH
Auf Debian und Ubuntu liest der SSH-Dienst zuerst die Dateien in /etc/ssh/sshd_config.d/ und danach /etc/ssh/sshd_config. Bei doppelten Einstellungen gewinnt der erste Wert. Deshalb legst du am besten eine eigene Datei mit niedriger Nummer an, die vor allen anderen gelesen wird:
nano /etc/ssh/sshd_config.d/00-nur-ssh-key.conf
Inhalt der Datei:
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
PasswordAuthentication no schaltet den Passwort-Login ab.
KbdInteractiveAuthentication no schließt den zweiten Weg, über den ein Passwort abgefragt werden kann. Auf Debian ist das schon Standard, schaden tut die Zeile nicht.
PermitRootLogin prohibit-password erlaubt Root nur noch mit Key.
Speichere die Datei und prüfe die Konfiguration auf Tippfehler. Kommt keine Ausgabe, ist alles in Ordnung:
sshd -t
Danach den SSH-Dienst neu starten:
systemctl restart ssh
Lass die aktuelle Sitzung offen. Teste in einem neuen Fenster, ob du dich mit deinem Key anmelden kannst. Klappt das nicht, kannst du in der offenen Sitzung die Datei wieder löschen und den Dienst erneut starten.
So prüfst du, ob es wirkt
Der SSH-Dienst zeigt dir die Werte, die er tatsächlich verwendet:
Erwartet sind passwordauthentication no, kbdinteractiveauthentication no und permitrootlogin without-password (so nennt SSH intern prohibit-password).
Von deinem eigenen Rechner aus kannst du gezielt einen Passwort-Login erzwingen. Der Server muss ihn ablehnen:
ssh -o PubkeyAuthentication=no root@62.68.75.69
Die richtige Antwort ist Permission denied (publickey). ohne Passwortabfrage.
Häufige Stolpersteine
Passwort wird trotzdem abgefragt: Eine andere Datei in /etc/ssh/sshd_config.d/ setzt PasswordAuthentication yes und wird vor deiner gelesen. Typisch ist 50-cloud-init.conf auf Ubuntu. Mit grep -ri passwordauthentication /etc/ssh/ findest du alle Stellen.
Änderung direkt in der sshd_config wirkt nicht: Gleicher Grund. Werte aus sshd_config.d haben Vorrang, weil sie zuerst gelesen werden.
Option im Cloud Manager fehlt oder greift nicht: Der Guest Agent läuft nicht. Guest Agent installieren oder den manuellen Weg nutzen.
Key wird abgelehnt: Prüfe die Rechte. ~/.ssh braucht 700, ~/.ssh/authorized_keys braucht 600 und muss dem Benutzer gehören, mit dem du dich anmeldest.
PuTTY fragt nach dem Passwort: Der private Key ist nicht geladen. In PuTTY unter „Connection“, „SSH“, „Auth“, „Credentials“ die .ppk-Datei angeben. Details im Artikel SSH Key anlegen und benutzen.
Ich habe mich ausgesperrt
Kein Grund zur Panik. Über VNC im Cloud Manager meldest du dich direkt an der Konsole an. Das ist keine SSH-Verbindung, deshalb funktioniert dort weiterhin das Root-Passwort. Dann löschst du die neue Datei oder korrigierst die Einstellung und startest den SSH-Dienst neu.
Es ist völlig nachvollziehbar, dass man vor dem Kauf wissen will, ob ein Server den eigenen Anforderungen genügt. Gerade bei virtuellen Servern hängt die tatsächliche Leistung von Hardware, Software und Belegung der Hostsysteme ab.
Einen öffentlichen Testserver bieten wir nicht mehr an. Die Infrastrukturkosten sind gestiegen, deshalb vergeben wir Testserver nur noch auf Anfrage. Schreib uns über das Kontaktformular für Testserver, was du vorhast. Vernünftige Anfragen nehmen wir an.
Ohne Testserver ausprobieren
Bei uns gibt es keine Mindestlaufzeit. Du lädst Guthaben auf, buchst einen Server und lässt ihn einfach auslaufen, wenn er nicht passt. Innerhalb der ersten 30 Minuten nach der Bestellung kannst du jeden Server ohne Gebühren zurückgeben. Was danach gilt, hängt von der Produktlinie ab, siehe Wie kann ich meinen Server sofort stornieren?
Bitte beachte, dass wir für Testserver eine „echte“ Mailadresse brauchen, damit wir Missbrauch vermeiden. Warum wir keine Trashmail-Adressen akzeptieren, erklären wir im Artikel Warum sind Wegwerf-Mails verboten?
Viele Kunden registrieren sich bei uns mit sogenannten Wegwerf-Mails. Wir verstehen den Sinn und Zweck dahinter, versprechen aber keinen Grund zur Sorge, wenn Du deine echte E-Mail Adresse bei uns hinterlegst.
Wir verbieten in unserem Web-Shop die Registrierung mit Wegwerf-Mails. Das hat nichts damit zu tun, dass wir Dein Postfach unbedingt mit Werbung bewerfen wollen – das tun wir nämlich ohnehin nicht -, sondern schützen damit Dich & Deine Daten.
Wir versenden keine E-Mail Werbung
Stell dir vor, Du meldest Dich bei uns mit einer Wegwerf-Mail an. Du bist bei der Anmeldung in deinem Postfach, weil Du die Mail-Adresse verifizieren musst. Danach wirst Du diesen Tab schließen und möglicherweise nie wieder öffnen.
Wir versenden wichtige Nachrichten zu Deinem Server immer per E-Mail. Du bekommst also nicht mit, wenn dein Server
ausläuft
wegen Wartungsarbeiten heruntergefahren wird
gesperrt wurde
mit einer Frage verbunden ist.
Es ist dann besonders ärgerlich, wenn Du deshalb die rechtzeitige Verlängerung versäumst und Deine Daten unwiderruflich gelöscht werden.
Außerdem wirst Du dein Passwort nicht richtig zurücksetzen können, wenn Du das Passwort vergessen hast und die Wegwerf-Adresse nicht auswendig kennst. Ohne ordentliche Verifizierung kann Dir auch unser Support-Team in diesem Moment nicht weiterhelfen.
Trash-Mails sind Sicherheitslücken
Bei den meisten Wegwerf-Mail Anbietern kann auch noch Monate nach Erstellung auf das Postfach zugegriffen werden. Dafür wird lediglich die E-Mail Adresse benötigt, mit der Du dich bei uns registriert hast. Es findet keine Legitimierung statt, es werden einfach alle E-Mails angezeigt. Dabei ist es egal, ob Du das Postfach aufrufst oder möglicherweise ein Dir Unbekannter.
Theoretisch hat also jeder Zugriff auf Deine E-Mails. Daraus resultiert, dass sich jeder Zugriff auf Dein Konto bei Prepaid-Hoster verschaffen kann. Denkt man ein wenig weiter, kann theoretisch sogar jeder auf die Daten deiner Server zugreifen, diesen manipulieren, kaputt machen oder deine Daten stehlen.
Wir versprechen Dir, dass es keinen Grund gibt, bei uns eine Wegwerf-Mail zu nutzen. Wir müssen als Dienstleister sicherstellen, dass Dein Konto bei Prepaid-Hoster sicher ist.
Dein Server erhält möglicherweise nicht die neuesten Features, wenn dieses sehr veraltet ist. Wir können nicht gewährleisten, dass neue Webinterface-Funktionen mit den veralteten Server-Paketen kompatibel sind und schalten deshalb neue Funktionen nur für Server frei, die auch in unserem Shop gemietet wurden. Deshalb bitten wir Dich, den Server zeitnah auf ein neues Paket zu ändern.
Wie führe ich ein Update durch?
Melde dich bitte bei unserem Support. Wir stellen das Paket dann für dich um. Vorher werden wir dir mitteilen, welche Änderungen durchgeführt werden.
Bleiben meine Daten erhalten?
Bei einem Upgrade oder bei einem Downgrade gehen keine Daten verloren, Deine IP-Adresse bleibt bestehen und Dein Server bleibt während des Upgrades online. Es ist möglich, dass Du den Server neu starten musst, um die neuen Ressourcen zu übernehmen.
Wann wird mein veraltetes Produkt von euch gekündigt?
Das ist von Paket zu Paket unterschiedlich. Wir geben Dir allerdings genug Zeit zum Handeln und schreiben Dir auf jeden Fall vorher mehrere Erinnerungs-Mails, bevor wir Dein veraltetes Paket tatsächlich kündigen. Wir halten uns dabei an die Kündigungsfristen unserer AGB.
Solltest Du Fragen zu diesem Thema haben, melde Dich bitte bei uns im Support. Wir helfen Dir dann gerne weiter.
Wir erklären Dir in diesem Artikel, warum ein DNS-Update so lange dauert und was das mit Deinem Internet-Anbieter oder DNS-Service zu tun hat.
Wenn Du im Internet surfst, dann benutzt Du eine Domain um zu einer bestimmten Webseite zu landen. Im Hintergrund sorgt der DNS-Dienst dafür, dass diese Domain zu einer IP-Adresse aufgelöst wird. Hinter dieser IP-Adresse verbirgt sich ein Server, der die gewünschte Webseite zur Verfügung stellen kann.
Wenn Du nun von Deinem vServer oder Deinem Webspace aus eine Webseite mit deiner Domain bereitstellen möchtest, muss die Domain auf die IP-Adresse Deines Dienstes auflösen. Dazu musst Du deine Domain mit deinem Webspace oder Server verbinden.
Diese DNS-Änderungen werden in unserem Kramer-DNS Nameserver hinterlegt. Dein DNS-Resolver fragt aber nicht bei jedem mal den Nameserver des Domainanbieters auf, wenn Du eine bestimmte Webseite aufrufst. Um Anfragen an diese Server so gering wie möglich zu halten und um auch die Auflösungszeit zu minimieren, speichern alle DNS-Server (z.B. von Internet-Anbietern wie Vodafone, 1&1, Telekom und co.) die DNS-Einträge der Domains zwischen. Diese bekommen deshalb nicht sofort mit, das sich die IP-Adresse auf dem Nameserver der Domain geändert hat. Meistens speichern die Anbieter diese Domains für 12 bis maximal 72 Stunden zwischen. Das variiert je nach Anbieter. Das ist auch der Grund, warum die Domain vielleicht bei einem Freund schon funktioniert, bei Dir aber noch nicht.
Auch DNS-Anbieter wie Google-DNS (8.8.8.8) und Cloudflare-DNS (1.1.1.1) gehen diesem Mechanismus nach.
Gedulde dich nach dem Einstellen einer neuen IP-Adresse also ein wenig. Schaue am nächsten Tag noch mal nach, ob die Domain dann letztendlich funktioniert. Das gilt auch für SRV-Einträge (Weiterleitungen zu Minecraft-Server und TS3-Server). Ebenso dauert die Aktualisierung aller weltweiten Caches einige Zeit, wenn Du den Nameserver deiner Domain änderst.
Wir können diesen Vorgang leider nicht beschleunigen.
Time-To-Live für DNS Änderungen
Jeder DNS-Eintrag hat auch eine TTL (Time To Live)-Angabe. Diese gibt an, wie viele Sekunden ein anderer DNS-Server diesen Eintrag zwischenspeichern darf, bevor er unseren Nameserver wieder nach dem neuesten oder aktuellen Inhalt befragen kann. Wir haben diesen Wert bei uns auf 12 Stunden gesetzt. Die meisten Cache-DNS-Server der Internetanbieter ignorieren diesen Wert allerdings. Deshalb haben wir uns entschieden, diesen Wert im Webinterface nicht einstellbar zu machen und um mögliche Fehlerquellen zu minimieren. Über die API kannst Du die TTL pro Eintrag setzen, siehe DNS-Records per API verwalten.
Für DynDNS-Updates setzen wir den TTL automatisch auf 180 Sekunden, damit ein schnelles Update für jene DNS-Server möglich ist, die diesen Wert nicht ignorieren.
