Drucken

Bitte loggen sie sich ein oder registrieren sie sich.
1 Stunde 1 Tag 1 Woche 1 Monat Immer
Einloggen mit Benutzername, Passwort und Sitzungslänge

[viper666]

Hallo liebes Forum und vieleicht auch der Support.

Ich teste für mich gerade die Einsetzbarkeit eines V-Server für mich hier bei EU-Serv.
Ich habe beruflich damit zu tun und brauche für verschiedene Services immer mal wieder gute und günstige V-Server. Ich bin gerne bereit dafür Geld zu bezahlen, wenn das Leistungsverhältnis passt. Was ich auch schon bei diversen Providern mache.

Zum testen habe ich nun den VS2-free erstmal bestellt.

Hierauf ein Debian 10 buster installiert und überwache den Server mit einem externen eigens betriebenen Nagios Server.
Nach kurzer Zeit habe ich bemerkt, dass der Server unkontrolliert einfach neu gestartet wird oder für eine gewisse Zeit gar nicht erreichbar ist.

Um das Nachzuverfolgen wollte ich mir intensiv die Logs ansehen.
Stoße aber auf das Problem, dass ich auf die Kernelprotokolle erst gar kein Zugriff habe.
Hä? Eigentlich bin ich doch root!

Also zum Verständnis. Ich bekomme hier auf der console solch schöne Meldungen.

Code: [Auswählen]

root@srv10864:~# dmesg
dmesg: read kernel buffer failed: Die Operation ist nicht erlaubt
Also auch mal hier geschaut

Code: [Auswählen]

root@srv10864:~# cat /proc/sys/kernel/dmesg_restrict
1
Eigentlich ist hier die derault Einstellung 0 und nicht 1
Gut, generell ja kein Problem. Bin ja root und ich darf ja dann alles.
Aber....

Code: [Auswählen]

root@srv10864:~# sysctl kernel.dmesg_restrict=0
sysctl: permission denied on key 'kernel.dmesg_restrict'
und auch...

Code: [Auswählen]

root@srv10864:~# echo 0 > /proc/sys/kernel/dmesg_restrict
-bash: /proc/sys/kernel/dmesg_restrict: Keine Berechtigung
Ebenso der Versuch in der /etc/sysctl.conf mit:

Code: [Auswählen]

root@srv10864:~# cat /etc/sysctl.conf
...
###################################################################
# Magic system request Key
# 0=disable, 1=enable all, >1 bitmask of sysrq functions
# See https://www.kernel.org/doc/html/latest/admin-guide/sysrq.html
# for what other values do
#kernel.sysrq=438
kernel.dmesg_restrict=0ist nach einem reboot ohne Ergebnis geblieben.

Was ist hier los?

Warum wird man hier so eingeschränkt?

Jedenfalls ist mir das bei den V-Servern der Konkurenz nicht so.

Liegt es ggf. am kleinen Wörtchen "free"?
Wäre ja kein Problem. Aber dann muss man ggf. kommunizieren, dass man die ein oder andere Funktion einschränkt.

Oder habe ich hier etwas falsch gemacht?

Gruß
viper

[thiloz]

Hallo Forum, hallo Support,

das interessiert mich natürlich auch.

Das sind noch weitere Fragen von mir offen.

Beispiel: https://forum.euserv.de/index.php/topic,9106.0.html

Wäre ja kein Problem. Aber dann muss man ggf. kommunizieren, dass man die ein oder andere Funktion einschränkt.

Damit habe ich auch immer ein Problem, was zwar nicht unbedingt was zu sagen hat, weil ich in neu bin.
Wenn aber auch viper666, der Profi ist damit Probleme hat, ....................................................

@viper666
Evtl. hilft das weiter:
https://forum.euserv.de/index.php/topic,9109.0.html

Liebe Grüße
thiloz

[Forum-Support2]

Hallo,

die vServer sind in der Conatiner Umgebung in Bezug auf sicherheitskritische Funktionen oder Funktionen, die Zugriff auf Parameter des Hostsystems geben, beschränkt.

Sofern das andere Provider mit derselben Technik anders lösen, bitte ich um Lösungsvorschläge. Wir prüfen dann gern, ob das in unser Sicherheitskonzept passt und wir das umsetzen können bzw. wollen.

[viper666]

Danke für die Antwort!
Ich bin nicht so tief in den virtualisierungstechniken drin. Will ich auch gar nicht.
Aber ich habe mal nachgesehen. Bei den anderen Providern habe ich KVM.
Da steckt warscheinlich der Teufel im detail.
Wenn ich das richtig verstanden habe kann man damit auch eigene Kernel einsetzen.

Und das mit dem Kernel ist dann bei Containern eine sehr kritische Sache.

Mich irritiert dann nur der Werbespruch auf der Startseite bei dem VS2-Produkte beworben werden.

Das Rootserver Modell "VS2-free" basiert auf der neuen Container basierten vServer Plattform von EUserv und bietet Hosting in einer virtualisierten Linux-Umgebung mit vollen Root-Rechten und allen damit verbundenen Vorteilen eines eigenen Servers.

Passt für mich dann nicht so ganz.

Aber nun weiß ich Bescheid.

Da ich aber somit nicht nachvollziehen kann warum der Server zw. dem 23.4 - 28.4 sehr häufig neu gestartet wurde und auch in dieser Zeit mehrmals überhaupt nicht erreichbar war ist das vieleicht noch eine spannende Aufgabe für den Support.
Gibt es dafür ggf. eine plausible Erklärung?

Aktuell sieht es ja ganz gut aus. Läuft schon über 11 Tage ohne Neustart. Nur eine Unterbrechung gab es da wieder mal am 13.05. um 19.00 Uhr bis 20.00 Uhr. Aber hier war der Server nur nicht erreichbar. Lief aber durch.

Gruß
viper

[thiloz]

Hallo,

die vServer sind in der Conatiner Umgebung in Bezug auf sicherheitskritische Funktionen oder Funktionen, die Zugriff auf Parameter des Hostsystems geben, beschränkt.

Guten Morgen Forum,

welche Beschränkungen sind das konkret?

Liebe Grüße

thiloz