1BLU VServer Probleme

buzz

New Member
vor 2 Tagen habe ich meinen Server Rebootet,
danach war er nicht mehr erreichbar. Aber über Plesk konnte ich
schon darauf kommen. Ich habe 2 Tickets aufgemacht und danach
habe ich den VServer in Repair Mode versetzt und versucht die Ursache
zu lokalisieren.
1BLU hat nach einer Weile meinen Repair Mode beended und und mir diese
per eMail mitgeteilt.
Jetzt kann ich den Server weder über Plesk noch über irgendwas anderes.

Das ist ein wohl ein schlechter Service .:mad::mad:
 
Das ist ein wohl ein schlechter Service
Ein Statement deiner Inkompetenz oder irealistischer Erwartungen?
Du wirst ja nicht erwarten dass ein Massenhoster bei vergeigter Konfiguration
auf den Server zugreift und in muehevoller Handarbeit die Einstellungen wiederherstellt damit du weiter spielen kannst?
Somit sehe ich kein Problem bei 1BLU.
Hands-On Service wird von vielen Anbietern mit entsprechendem Auftrag oder durch Vertrag geregelt angeboten, meist zum Stundensatz von 60Euronen.
(15 Eur / 15 min)


danach war er nicht mehr erreichbar. Aber über Plesk konnte ich
schon darauf kommen.
Dein Server ist erreichbar, somit kann man Probleme auf dem hardware-Node ausschliessen. Schliesslich muss ja Plesk auch laufen, somit muss zumindest ein Teil der Software in Betrieb sein.


Kannst ja versuchen den Webserver (ich nehme an dass der bei dir nicht funktioniert) manuell zu starten und die Fehlerausgabe hier posten.

Jetzt kann ich den Server weder über Plesk noch über irgendwas anderes.
Unter Windows benutzt man RDP unter Linux SSH. Wenn du jetzt sagst "davon habe ich keine Ahnung" dann gib den Server vor Ablauf der naechsten Woche zurueck. Danke! Wenn man einen Root mietet _MUSS_ man Ahnung haben.
1blu bietet auch ganz schoene Webspace-Pakete an!
 
@d4f

Ich denke mal so persönlich brauchst du nicht werden, zumal Inkompetenz
kannst nur du sein.

Es ist nicht ein Konfig Fehler und der WebServer funktioniert wohl, wenn die
VM funktionieren würde.

Wenn du es richtig lgelesen hast , alles ist nach einem Reboot passiert.
Und mein Server funktioniert NICHT , also weder per Plesk noch perl SSH.

In Sachen Linux System Administration kann ich DIR "scherz keks" und möchte gern Admin ;) eine ganze Menge erzählen.
Wenn du auch ein Mitarbeiter von 1BLU bist musst du dem Hoster nicht so
in den Popo kriechen.

Wenn du keine Antwort auf mein Problem hast sitz dich auf deinem Gesäß und sei ruhig
 
Mal abgesehen davon das dein Deutsch grausam ist, kann ich noch immer keine Frage erkennen.

In deinem ersten Post schreibst du aber sehr wohl das Plesk für dich scheinbar erreichbar war, nun im zweiten Post schreibst du, das der Webserver erreichbar wäre, wenn die VM laufen würde. Was denn nun? Hast du Logfiles oder irgendwas womit man etwas anfangen könnte?
 
Uj, da habe ich aber jemanden an empfindlicher Stelle getroffen =)
Und nein ich arbeite nicht bei 1blu.
Randnotiz: irgendwie habe ich das Gefuehl dass ich aktuell mehr SSH-Sessions aufhabe als du je Server hattest.

chroot in der Rescue-Umgebung und starte den Webserver.
(Aber das sollte ein Linux-Profi doch bereits wissen)

Ich gehe mal von der Annahme aus dass die chroot-Binary auf dem Rescue-System verfuegbar ist, ansonsten muesstest du es in die RAM nachladen oder aus dem Betriebssystem deines vServers rausziehen (inkl evtl. Librarys)



[PS]
Wenn du keine Antwort auf mein Problem hast sitz dich auf deinem Gesäß und sei ruhig
- Ich sitze auf meinem Gesaess. (staendiges Stehen waere herzlich unbequem)
- Wenn ich Nightwish mitsingen wuerde koennte nur zu Regen und Gewitter fuehren...
 
Nun OK
Jetzt reden wir die gleiche Sprache ohne einander zu beleidigen.

Es ist folgendes passiert:

Ich habe auf meinem VServer u.a. Asterisk 1.4 & A2Billing 1.7
Auf dem Web FE merke ich, daß A2Billing nicht ordentlich funzt.
Da ich mit Asterisk am Testen war und keine Zeit für Fehlersuche hatte habe
ich untypischerweise das System rebootet.
Danach war das System nicht mehr erreichbar.
Traceroute lieferte folgendes:
Code:
1  DD-WRT (xxx.xxx.xxx.xxx)  0.423 ms  0.299 ms  0.255 ms
2  fritz.fon.box (xxx.xxx.xxx.xxx)  0.996 ms  0.880 ms  0.726 ms
3  lo1.br03.muc.de.hansenet.net (213.191.89.10)  26.502 ms  25.890 ms  
4  gi2-0-0.pr02.muc.de.hansenet.net (213.191.88.88)  25.710 ms  25.215 ms 25.613 ms 
5  ge-1-3-21-bg2.ip.eu.equinix.com (80.81.202.4)  34.605 ms  34.427 ms  34.276 ms
6  ge-5-1-23-bg4.ixsolutions.net (217.68.155.40)  34.110 ms  33.139 ms 33.724 ms
7  ge-2-1-23-ed2.ixsolutions.net (217.68.155.82)  34.648 ms  34.608 ms  34.929 ms
8  89.202.113.22 (89.202.113.22)  34.683 ms  34.187 ms  34.788 ms
9  vh64-2014.1blu.de (89.202.2.3)  33.880 ms  35.153 ms  37.166 ms
10  * * *
11  * * *
12  * * *
[COLOR="Red"]...MOD: gekürzt & Code Tags...[/COLOR]
------------------------
nmap lieferte auch keine offene Ports.
--------------------------------
Trortdem in Plesk war die VM oben
- meine Vermutung war, daß etwas mit der Policy von IPTables nicht stimmte.
- In Plesk waren aber alle Policies auf ACCEPT gesetzt
ABER
- ich könnte nicht per SSH im Plesk auf die VM zugreifen.

-------------------------------------------------
Per "telnet" habe ich sämtliche ports auf verbindung kontrolliert (OHNE ERFOLG)

Mir blieb nur die Repair Mode , wo ich per SSH/SCP reinkommen konnte und die Daten auf meinem lokalen Rechner sichern und den Test fortsetzen konnte.
------------------------------

Warum sagte ich schlechter Service ?
weil viele andere Hoster mit dem gleichen Preis eine 24/7 Support bieten aber diesen nicht. Und diese Incident passierte am Freitag :(


Trotzdem Danke für euere Hilfe

@d4f :
Nichts für Ungut - Wir machen alle Fehler, aber nicht gleich
einen persönlich angreifen und behaupten er weiß nicht was SSH o. RDP heißt.
 
Last edited by a moderator:
Mir blieb nur die Repair Mode , wo ich per SSH/SCP reinkommen konnte und die Daten auf meinem lokalen Rechner sichern und den Test fortsetzen konnte.
Meinst du damit, das bereits angesprochene Rescue-System? Wenn ja, warum hast du dort nicht mal nach dem Fehler gesucht?

PS:
Wenn du sowas wie einen traceroute postest, benutze doch bitte die CODE-tags, danke. Etwas Rechtschreibung, wie ebenfalls schon erwähnt wurde könnte ebenfalls nicht schaden. ;)
 
Hmm, der Traceroute sieht so aus wie man ihn von einer nicht geclaimten IP erwartet; die VM scheint also nicht zu starten oder zumindest kein Interface hoch zu kriegen.
(NB: DD-WRT rulez =) )

Trortdem in Plesk war die VM oben
Meinst du jetzt Plesk oder Virtuozzo (oder ein anderes Hostingpanel)?

Mir blieb nur die Repair Mode , wo ich per SSH/SCP reinkommen konnte und die Daten auf meinem lokalen Rechner sichern und den Test fortsetzen konnte.
chroot'e mal wie bereits angesprochen in den vServer und versuch die Dienste zu starten, funktioniert es?
Kontrollier die /etc/network/interfaces - Datei.


weil viele andere Hoster mit dem gleichen Preis eine 24/7 Support bieten aber diesen nicht.
Was soll der Anbieter machen ausser kontrollieren ob der Hardware-Node sowie die Uplinks iO sind?
 
Lieber Buzz,
ich kenne ca. 100 VServer Anbieter, ich kenne ale Preise und ich kenne die Support und Serviceleistungen.

Deine Argumente und Vergleiche mit anderen Firmen, die für den gleichen Preis die Adminarbeiten eines nichtmanaged VServers kostenlos anbieten, die Du von 1blu erwartest hast, sind definitiv falsch.

Solltest Du mal eine kleine Frma gehabt haben, die Dir in so einem Fall Deine Arbeit abgenommen hat und Dir kostenlos geholfen hat, sei einfach froh und dankbar.

Wenn wir mal Streit und Emotionen beiseite lassen, hat d4f sachlich Recht, dass die Firma nur dafür zu sorgen hat, dass der Node einwandfrei läuft. Da Du über das Rescuesystem an Deinen VServer herangekommen bist, hättest Du alles selbst reparieren können und müssen.

Darum bitte ich Dich, um den Ruf von Firmen nicht ungerecht zu schädigen, aus solchen Schlagzeilen den Firmennamen rauszulassen, bis 100%ig geklärt ist, dass es nicht Deiner falschen Erwartungshaltung zu verdanken ist, dass Deine Kiste nicht für Dich repariert wurde. Wenn Du solche Meldungen in die Welt setzt, kannst Du einer kleinen Firma großen Schaden zufügen. 1blu verkraftet solche Kunden wie Dich schon eher, hat aber solche Rufschädigungen selbstverständlich auch nicht verdient.

Gruß Fritz
 
Ja Gut,
es mag sein (und es war auch so) ich habe zu emotional reagiert.

Das lag wohl daran, dass es das zweite Mal war wo ich nach einem Reboot das System nicht mehr hochbekommen habe, obwohl ich "keine" Änderungen am System Startup Sequences durchgeführt habe.
Die Reboots wurden initiert, weil das System nicht mehr ansprechbar war.

##
Beim 1. Mal hat der Hoster gemeint : Es gab Einschränkungen beim Hochfahren des VM's die jetzt beseitigt wurden (die wurden mir aber nicht genannt)

##
Beim 2. Mal(heute) meinte der Hoster :die Policies von meine IPTable waren alle "falsch", und deswegen hatte ich keinen Zugang zumn System, obwohl ich die IPTable-Policies bereits kontrolliert hatte(über Plesk) und alle Policies standen auf ACCEPT.


@d4f & @Fritz
Ihr habt ja Recht, der Hoster überprüft nur die Nodes aber Ihre Reaktionszeit
war extrem lang.

mag sein, dass die Art und Weise wie ich es angegangen bin nicht so
"Politisch Korrekt" war, ich sehe es ja wie ich darüber kritisiert werde.

Ich hoffe aber durch so ein hartes Kritik, werden die Ihr Service verbessern. Sicherlich sind die nicht von mir abhängig.


Gruß
Buzz
 
Back
Top