Das ist mir bekannt. Ich nutze ja auch DynDNS, nur möchte ich wissen, wie man das komplett unabhängig macht.
Das geht dann wohl in diese Richtung:
https://forum.netcup.de/showthread.php?t=436
Halte ich jedoch nicht gerade für trivial. Wenn du aber was zum Basteln möchtest, hast du hiermit sicherlich ein ganz nettes Projekt.:)
In einigen Punkten hast du Recht, keine Frage. Dass man selber bei einem Serverausfall nicht viel richten kann, ist klar. Aber immerhin weiß man so Bescheid, was Sache ist.
Bei einem kurzzeiten Server-Reset ist eine solche Monitoring-Funktion natürlich nutzlos, da stimme ich dir zu. Da habe ich mich wohl zu sehr auf den Thread-Titel Benachrichtigung bei Serverausfällen konzentriert - und den eigentlichen Inhalt aus den Augen verloren.
Unter'm Strich würde ich allerdings folendes Fazit ziehen: Nicht mit irgendwelchen Benachrichtigungen herumspielen, sondern die Ursache beheben, so dass der Server reproduzierbar und zuverlässig nach jedem Booten korrekt konfiguriert ist.
Um hierbei ganz auf Nummer sicher zu gehen, kann man die hier vorgeschlagene Lösung verwenden: http://faq.hosteurope.de/index.php?cpid=11517
Damit wird bei jedem Start des Servers über ein minimalistisches Init-Skript der Hostname hart auf einen bestimmten Wert gesetzt.
Wenn du dir wirklich sicher bist, dass das auch wirklich das ist, was du suchst, dann findest du in RFC 2136 die genaue Definition für solche dynamischen DNS Updates. Mit der Suchmaschine deines Vertrauens solltest du ausreichend Dokumentationen hierzu finden.
Ansonsten wüsste ich aber nicht, was für Misstrauen man gegenüber DynDNS & Co. haben sollte. Du musst ja für den DynDNS-Account nicht unbedingt das selbe Passwort wie für dein Mailkonto etc. verwenden. Und allein die IP-Adresse, die dort hinterlegt wird, ist ja sicherlich kein Geheimnis.
Benutzt du zufällig einen Dienst wie DynDNS o.ä.? Dann könntest du dir nämlich einfach innerhalb deiner (richtigen) Domain einen sog. CNAME Record (Alias) anlegen. So könnte dann meinserver.blub.de auf blub.dyndns.org zeigen, wodurch der Server dann jederzeit über meinserver.blub.de erreichbar ist. Der CNAME-Alias über DynDNS läuft dabei komplett transparent und "unsichtbar" ab.
Wie du einen solchen CNAME-Record im Zonefile deiner Domain anlegst, verrät dir dein Domain-Provider.
Wenn dir auf dem vServer definitiv zu wenig RAM zur Verfügung steht um erfolgreich die ganzen Sourcen durchzukompilieren, kannst du den Sourcecode auch auf deinem Rechner zu Hause oder dort innerhalb einer VMware-VM übersetzen. Erfordert zwar etwas bessere Kenntnisse, wäre aber durchaus möglich.
Wenn der 'make' Prozess nicht immer an der selben Stelle abbricht, kannst du dich auch "Stück für Stück" herantasten, und einfach den 'make' immer wieder neu starten (ggfs. Server neustarten um RAM freizugeben). Normalerweise werden bereits kompilierte Dateien nämlich einfach übersprungen.
Hallo,
für solche Fälle bin ich auch mit diversen Server Monitoring Diensten ziemlich zufrieden. Zum Beispiel hier: http://www.hosttest.de/server_monitor.html
Wenn du das eingerichtet hast, wird alle 5 Minuten ein TCP-Verbindungsaufbau auf einen bestimmten Port (z.B. 80 für HTTP) deines Server durchgeführt. Konnte die Verbindung erfolgreich hergestellt werden, wird diese sofort wieder abgebaut. Im Falle eines Timeouts wenn der Server mal nicht erreichbar ist, bekommst du dann eine E-Mail zugeschickt, in der ganz genau drinsteht, welcher Port auf welchem Server um wie viel Uhr nicht erreichbar war.
Somit bekommt man alle Ausfälle rechtzeitig mit und kann dann entsprechend reagieren.
http://de.wikipedia.org/wiki/Nmap
10 Minuten, dann hab ich den Port wieder.
Natürlich kannst du den Port ohne Probleme heraus bekommen. Aber es geht hier ja in erster Linie darum, die etlichen automatisierten Bot-Angriffe in den Griff zu bekommen. Denn selbst wenn diese es nicht schaffen, ein gültige User/Password Kombination zu erraten, erzeugen die ganzen Login-Versuche doch auch eine gewisse Last auf dem Server, wenn diese massenhaft und simultan durchgeführt werden.
Wenn du aber den SSH-Port einfach auf irgendeinen anderen Port änderst, hast du dieses ganzen Bot-Connections schonmal komplett vom Hals. Hier wird nämlich ähnlich wie beim Versenden von Spam verfahren: Einfach so viel wie möglich (Login-Versuche/Spam-Mails) in möglichst kurzer Zeit. Da erst noch einen SSH-Port zu suchen wäre viel zu ineffizient, da die Bots in dieser Zeit schon wieder etliche andere Systeme (mit Standard-Port) ausprobieren.
Fazit: Das Ändern des SSH-Ports hat konkret auf meinen Servern mit einfachsten Mitteln die automatisierten SSH-Angriffe komplett abgeschaltet. Ganz ohne fail2ban oder ähnlichem.
Würde es etwas bringen das der SMTP Connector sich beim vServer mit User/Pass authentifiziert?
Eindeutig ja (vorausgesetzt der Mail-Server auf deinem vServer ist korrekt eingerichtet).
Wenn du einfach so Mails über den vServer versenden willst, muss dies abgelehnt werden. Denn sonst könnte jeder Spammer so viele Spam-Mails wie er möchte einfach bei deinem vServer einliefern und der vServer würde sich dann um die Zustellung kümmern.
In der Regel sind die Mail-Server so eingerichtet, dass ein Relay (Smarthost) nur mit Authentifizierung erlaubt ist.
Meine Lösung besteht momentan in einer kompletten Spiegelung mittels rsync auf meinen Server zu Hause. Da der Anschluss zu Hause genügend Downstream hat - ADSL sei Dank - und der vServer quasi unendlich Upstream - Netcup sei Dank - geht das ganze auch recht zügig; vorallem ab dem zweiten Mal, da ja nur noch die Daten übertragen werden müssen die sich auch tatsächlich verändert haben. 
PS: Wenn möglich nicht vergessen diverse temp-Verzeichnisse auszuschließen, sonst halst man sich mit dieser Lösung ganz schnell ganz viel Traffic auf. :o
Wenn schon, dann richtig. 
deb http://de.archive.ubuntu.com/ubuntu/ hardy-updates main restricted
Damit die ganzen Updates nicht noch extra über den großen Teich wandern müssen. Ich denke die Pakete von der Uni-Dresden zu holen dürfte die bessere Wahl sein. 
Okay, in wie fern das Ubuntu-Image nun als (un)stable zu betrachten ist, das kann wohl nur Netcup entscheiden.
Bei mir lief das Image jedenfalls absolut reibungslos und das tut es bis heute auch noch.
Hallo,
Ubuntu 8.04.1 ist meiner Meinung nach nicht wirklich notwending. Schließlich handelt es sich da ja nicht um eine neue Version der Ubuntu-Distribution, sondern lediglich um eine Art Service-Pack, das den OpenSSL-GAU stopft. Wenn du nach dem Aufspielen des Images einfach ein Update mittels "apt-get upgrade" machst bist du in wenigen Augenblicken auf dem selben Stand.
Und was Debian angeht, so würde ich hier ganz nach dem Debian Motto "it's done when it's done" vorgehen. Lass Lenny erstmal offiziell für stable erklärt werden, dann kann man hierfür sicherlich auch ein Image erstellen. Aber solange eine Distribution nocht nicht offiziell stable ist und mit Sicherheitsupdates versorgt wird, halte ich dies für ein Produktivsystem nicht gerade geeignet.
Zu Fedora soll jemand anderes was sagen, da kenne ich mich nicht aus.
Hallo,
eine ganz blöde Frage: Wofür brauchst du Zaptel denn überhaupt auf deinem vServer? Ich glaube nicht, dass dir Netcup eine ISDN-Karte in deinem vServer zur Verfügung stellen wird.
You have bought yourself a brand new Zaptel interface card so that you can connect telephone lines and/or telephone handsets to your computer.
Das wird wohl nicht funktionieren.
Wenn du einfach nur einen Asterisk-Server installieren willst, das klappt eigentlich einwandfrei. Nehme dazu einfach den Standard-Sourcecode von http://www.asterisk.org ohne irgendwas mit Zaptel&Co. zu installieren. Die Kernel-Sourcen brauchst dann auch nicht zum Kompilieren.
Sicherlich sind das jetzt alles nur noch irgendwelche Feinheiten.
Am wichtigsten ist es denke ich einfach, den Port zu ändern, und zumindest für Root ausschließlich Key-Auth. zu benutzen. Damit ist man schonmal auf der sicheren Seite.
Hallo,
das Tutorial sieht doch soweit schonmal ganz brauchbar aus.
Ob der Port nun allerdings zwangsläufig oberhalb von 1024 liegen sollte, spielt denke ich keine große Rolle. Da der SSH-Daemon mit Root-Rechten läuft, wäre auch jeder andere (lt. /etc/services ungenutzte) Port (<1024) in Ordnung.
Eine einzige Option in der sshd_config vermisse ich dort allerdings:
PermitRootLogin without-passwordDamit ist kein Root-Login mit Klartext-Passwort möglich sonder nur noch z.B. per Public-Private-Key, d.h. es kann auch kein Bot der Welt das Root-Passwort durch Klartext-Logins erraten.
Wenn man allerdings wie im Tutorial mit "PasswordAuthentication no" die PasswordAuthentication ganz deaktiviert, sollte meine o.g. Zeile auch wieder überflüssig sein. Ich persönlich habe mir allerdings immer die PasswordAuth. als allerletztes Hintertürchen offen gehalten, wenn ich z.B. unterwegs an irgendeinem Rechner unbedingt Zugriff auf den Server benötige, und meinen SSH-Priv-Key gerade nicht dabei habe.
Hallo,
nur noch eine kleine Ergänzung meinerseits:
die nächtlichen Login-Versuche aus aller Welt
Dieses Übel kennt wohl jeder. Vielleicht kannst du ja in Erwägung ziehen, den SSH-Daemon einfach auf einen anderen Port zu legen (sshd_config -> Port). Damit bleiben dann auch die ganzen SSH-Bots draußen, und die Serverlast steigt nicht mehr unnötig an, nur weil gerade wieder etliche SSH-Logins gleichzeitig durchprobiert werden.
n'Abend,
ich denke es macht an dieser Stelle wenig Sinn, zu diskutieren, ob man als root auf einem Server arbeiten sollte oder nicht. Sicherlich ist ein eingeschränter Benutzeraccount in Verbindung mit gezielten sudo-Aufrufen "besser", ich arbeite aber z.B. auch durchgängig als Root-User auf meinem Server wenn dort irgendetwas zu tun ist.
Das Root-Sein ist zuerst einmal ja nichts negatives. Solange man eben jede Taste zweimal überdenk bevor man sie drückt und ich genau weiß, was ich eigentlich gerade mache. Gefährlich wird es erst dann, wenn ich "irgendetwas" mache, von dem ich nicht ganz genau weiß, was es bedeutet und wie es sich auf das System auswirkt.
Gut, und der Klassiker: "rm -fr /tmp/muell". Wenn ich da nach oder vor dem zweiten Schrägstrich aus Versehen auf die Return-Taste komme habe ich eben die Arschkarte gezogen.
Ich würde aus diesem (und anderen) Thread(s) einfach das Fazit ziehen: Setzt euch zu Hause erst einmal einen simplen Linux-Server auf und lernt diesen zu administrieren. Da ist der Server in der "Einübungsphase" erst einmal nur über eine kleine ADSL-Leitung ans öffentliche Internet angeschlossen, die in der Regel auch noch durch ein NAT geschützt ist. Somit kann da erst einmal kein wirklicher Schaden (außerhalb des eigenen Netzwerks) entstehen.
n'Abend,
wie wäre es denn damit, den vServer von netcup managen zu lassen? Solange du dich nicht blind und im Schlaf auf einem Linux-Server zurecht findest, halte ich es einfach für grob fahrlässig so ein Teil im öffentlichen Internet zu betreiben.
Solche managed vServer sind nun auch wieder nicht unbezahlbar; die Tatsache dass dann aber kompetentes Personal sich um deinen Server kümmert schon.
Hallo,
für den fertigen Einsatz auf einem Produktivsystem habe ich folgenden Eintrag in der /etc/crontab, der bei 500 MB Traffic (2-Euro-vServer) anschlägt.
58 23 * * * root /usr/local/bin/traffic_netcup 500 MeineMailAdresseDa siehst du auch, was mit dem "Parameter übergeben" gemeint ist: Einfach in der Befehlszeile anhängen.
Und zum Testen starte doch einfach in der Shell von Hand z.B. folgendes Kommando:
/usr/local/bin/traffic_netcup 1 deineMailAdresseDas sollte eine Mail verschicken, wenn der Traffic des heutigen Tages 1 MB überschritten hat.
Tach,
bei den Datenmengen sollte dann die Mail-Lösung noch erträglich sein.
Am einfachsten tust du dir mit dem Tool "biabam". Das ist ein CLI-Mailer speziell für Dateianhänge. Bei einem Debian-System kannst du das Tool einfach mittels apt-get installieren.
Die Anwendung des Programms ist auch denkbar einfach. Hier ein Beispiel:
echo "Mail mit Backup im Anhang" | biabam /tmp/backup.tgz -s "Backup-Mail" anonymous@example.net
Dies schickt eine Mail an die Adresse anonymous@example.net mit dem Betreff "Backup-Mail". Der Nachrichten-Text wird per echo-Pipe-Konstruktion eingefügt. Schlussendlich wird dann noch die Datei /tmp/backup.tgz per MIME an die Mail angehängt. Du kannst so auch mehrere Dateien verschicken, indem du die einzelnen Dateien nur durch ein Komma trennst, keine Leerstelle (z.B. "/tmp/backup.tgz,/tmp/foo,/tmp/bar"). Genauso funktioniert es auch wenn die Mail an mehrere Empfänger gehen soll.
Dann viel Spass mit deinem Mail-Backup. Achja, damit das Backup auch wirklich eine Datensicherung ist, gehe ich davon aus, dass das Mail-Postfach auf einem anderen Server liegt.
Da die Mails aber komplett unverschlüsselt über die ganzen Mail-Systeme wandern würde ich auf einem Produktivsystem die anzuhängenden Dateien vor dem Versand per GPG verschlüsseln.