Beiträge von Kinch

Alles klar; ich danke euch allen drei Das mit der Zufriedenheitsgarantie war mir gar nicht bekannt (ich sollte echt genauer lesen) Schön auch, dass Netcup sowas anbietet.

Grüße

Hallo,

ich möchte einen neuen Root-Server haben und wollte einen RS 1000 G8 bestellen. Leider habe ich einfach nicht genau gelesen. Da stand als Speicher 40 GB SS / 320 GB SAS. Ich dachte, das wären 40 GB SD für das System und 320 GB SAS für Daten.

Ich habe auf bestellen gedrückt und mir war nicht klar, dass ich mich hätte zwischen beidem entscheiden sollen. Das war natürlich mein Fehler und ich hätte besser aufpassen sollen, keine Frage.

Nichtsdestotrotz, wären 320GB für meine Zwecke viel sinnvoller. Ich habe am nächsten Tag angefragt, ob man den Server nicht löschen könnte und mir einen 320GB Server hinstellen könnte. Der Support meinte ich müsse erst den alten Server ordentlich kündigen und dann den neuen bestellen. Nun, gibt es ja leider die Laufzeit von 12 Monaten.

Lange Rede kurzer Sinn: Weiß einer, ob diese 14 Tage Widerrufsrecht noch gelten? Es gibt da noch diese Seite: https://www.netcup.de/bestellen/widerrufsbelehrung.html, aber ich weiß nicht, ob die für meinen Bestellvorgang gilt.

Weiß da jemand was?

Vielen Dank schonmal

Ah ok, das beruhigt mich. Ich hatte sowas ähnliches gehofft. Ja, der Load ist normal.

Viele Dank Christian

Gruß
Kinch

Hallo Allerseits,

htop und top zeigen mir zur Zeit eine CPU-Last zwischen 50 und 60% an. Das merkwürdige ist, dass aber ebenfalls laut (h)top keiner der laufenden Prozesse diese Last erzeugt.

Das Ganze bleibt auch nach einem Neustart bestehen.

Kennt jemand das Phänomen und hat eine Erklärung dafür?

Gruß
Kinch

Aber wenn du die IPs ständig sammelst, wird die Blacklist dann nicht irgendwann zu groß? Ich denke mal, der Apache muss die bei jedem Zugriff erneut auswerten.

Und dann gibt es noch das Problem, dass viele IPs dynamisch zugewiesen sind. Das heißt auch ein legitimer Besucher könnte eine IP auf der Blacklist bekommen.

Zitat von Servior;5553

Eine Möglichkeit ist davon auch bereits genutzt worden, nämlich die über phpmyadmin. Daher solltest du dieses auch gut absichern, z.b. indem nicht /phpmyadmin benutzt wird.

Security by Obscurity ist aber auch nicht wirklich das wahre. Wenn man schon solche Sachen benutzt, ist es imho selbstverständlich eine HTTP-Authentifizierung vorzuschalten.

Daneben finde ich, ist ein manuelles Eintragen in eine Firewall auch nicht wirklich sinnvoll. Die Wahrscheinlichkeit öfters von der gleichen IP abgerast zu werden ist doch eher gering. Und Schutzmechanismen die erst greifen nachdem der Scan durchgeführt wurden, bringen wohl nichts.

Ich weiß ja nicht, was confixx macht/kann, aber denk bitte daran SSH dicht zu machen.

Nein, das ist so: Wenn du den Namen einer Datei aufrufst, interpretiert die Shell das, als ein Versuch die Datei /auszuführen/. "/root/zugangsdaten.txt" heißt also in Sprache übersetzt: "Führ das Programm "zugangsdaten.txt" im Ordner /root aus".

Die Datei ist aber nicht ausführbar, dass heißt in dem Fall auch, dass sie keine entsprechende Rechte hat um ausgeführt zu werden, und deshalb kommt "Permission denied".

"cat" ist ein Programm, dass Dateien einließt und ausgibt. Du gibst nun dem Programm "cat" die Datei als Parameter an und das Programm gibt die Datei auf der Konsole aus.

> cat /root/zugangsdaten.txt

Wichtig ist das Leerzeichen zwischen "cat" und dem Dateipfad. Sonst sucht er nach einem Ordner "cat" in dem der Ordner "root" liegt, in dem die Datei "zugangsdaten.txt" liegt.

Zitat von fLoo;5512

EPIC Fail. Er schadet hierdurch den anderen Kunden auf dem Node, wie Du siehst bringt er KEIN Grundwissen mit um einen VServer zu admiminstrieren. 1 Monat und seine Kiste ist kompromittiert - er ist 25 Euro ärmer und heult dann wieder hier rum ...

Ich kann deine Position verstehen, aber Fakt ist, dass er einen Root-Server hat. Und im Moment läuft der SSH-Server dort mit einem kurzen Passwort, dass per Mail versendet wurde, ohne jede Aufsicht. Ihm nicht zu sagen, was er tun kann, verbessert die Situation auch nicht wirklich.

Bogdan

Um mal die Wogen zu glätten: floo glaubt halt nicht, dass du im Moment einen Root-Server administrieren kannst. Und wenn du nicht mit SSH umgehen kannst, stimmt das leider auch. Das ist wie Autofahren ohne zu wissen, wo man den Schlüssel reinstecken muss.
Und wenn dein Server gehakt wird, hat das für alle anderen, eventuell auch für mich und floo oder für Netcup Konsequenzen. Zum Beispiel könnte die Polizei den Rechner von Netcup beschlagnahmen und dann wären wir alle unsere Root-Server los.

Deshalb mal ein Rat an dich: Per vcp kannst du einen Server runterfahren. Nimm dir ne Woche Zeit und befasse dich mit der Konsole, mit SSH, mit dem Linux-Verzeichnisbaum und der Konfiguration von Daemons.

Zitat

wenn ich root/zugangsdaten.txt aufrufe sagt der "Permission denied"
Und was jetzt? Der erlaubt mir nicht die zu sehen

Wie hast du denn das aufgerufen?

Es sollte mit: "cat /root/zugangsdaten.txt" gehen. Wichtig ist das / am Anfang von "root".

Noch was: Ich misch mich ja auch ungern in anderer Leute Sachen ein und man kann ja nicht immer alles wissen. Auch Grundwissen muss gelernt werden und so. Aber Hilfe zur Selbsthilfe sollte auch gelernt sein:

> http://de.wikipedia.org/wiki/Ssh
> http://wiki.ubuntuusers.de/SSH
> http://the.earth.li/~sgtatham/putty/0.60/htmldoc/

Das ist normal und ein Sicherheitsmerkmal. Das Passwort wird nicht angezeigt, damit ein Dritter es nicht sehen kann, wenn er zufällig auf den Bildschirm schauen kann. Auch nicht als Sternchen um die Anzahl der Zeichen nicht preiszugeben.
Das ist generell im Linux-Konsolen-Bereich so.

Da ich Putty nicht kenne, kann ich dazu nicht soviel sagen. Aber Einloggen musst du dich beim erstenmal als "root". Du verwendest also nicht "dein" Benutzername. Das Passwort sollte in der Mail mit den Zugangsdaten stehen, oder im Kontrollpanel bei der Neuinstallation erscheinen.

Nach dem ersten Login rate ich dir übrigens dringend, SSH abzusichern: Key-Authentifizerung und das Verbot von Passwörtern helfen gegen Bruteforce. Sobald du einen SSH-Dienst öffentlich anbietest kommen nämlich Horden von Bots die alle Möglichen Passwörter durchtesten.

Hast du mal in den Apache-Logs nachgeschaut, ob er einen Fehler meldet?

Danke für den Post. Scheint, als würden sich die Vserver hier nur einen Kernel teilen? Das könnte dazu führen, dass solche Dinge wie Upstart nicht wie gewohnt funktionieren denke ich.

Na ja, ich gebe mich mit einem Workaround für mein Git-Repo zufrieden, bis ich was besseres gefunden habe.

Gruß

Hallo,

danke erstmal für die Antwort. Die Sache ist nur die: Ich weiß nicht wirklich, ob das jetzt an der Firewall oder an Ubuntu liegt. Und selbst wenn es an der Firewall liegt, wüsste ich auf anhieb nicht, welche Regel ich erstellen müsste.

Hat hier niemand einen git-daemon installiert?

Hallo,

ich bin noch ziemlich neu bei der Server-Administration und habe folgendes Problem:

Beim Aufruf eines intictl-Befehls erscheint immer die Meldung:

initctl: Unable to send message: Connection refused

Kann das mit den Firewall-Einstellungen des vserves zusammenhängen? Wenn ja, weiß jemand wie ich diese Entsprechend ändern kann? Geht das "normal" über die Iptables?

Die Konfiguration der Firewall über das vcp ist jedenfalls /nicht/ möglich, es gibt nur die Meldung "can_manage_firewall". Ich nehme mal an, dass das an meiner Ubuntu-Installation liegt.

(Edit: Ich habe gerade gelesen, dass man sich die Möglichkeit der Firewall-Konfiguration manuell freischalten lassen muss.)

Gruß
Kinch