Minecraft Server Erstellt , aber kann nicht connecten ???

  • Thread starter Thread starter Deleted member 15595
  • Start date Start date
D

Deleted member 15595

Guest
moin moin meine lieben !

zuerst möchte ich erstmal zu den Technische daten kommen .

System : Linux Debian 7 LAMP

CPU : AMD Opteron 3365 Octacore (8x 2,3 GHz)

Ram : 24 GB (DIMM (DDR3)

Kapazität : 2x 120 GB (SSD, 80.000 IOPS) (RAID 1)

Java Version : "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode

-------------------------------------------------------------

So also jetzt geht es geht um mein Minecraft Server .

Ich habe den Minecraft Server Erstellt , und laut Putty Online .

Aber über den Minecraft Client ist er Offline .

habe also die Port eingetragen mit

Code:
iptables -A INPUT -p tcp --dport 25565 -j ACCEPT

und

Code:
iptables -A OUTPUT -p tcp --dport 25565 -j ACCEPT


Aber auch da ist der Server Offline .

Habe also den Befehl

Code:
iptables-save

kommt das Raus

Code:
# Generated by iptables-save v1.4.14 on Fri Mar  7 18:41:16 2014
*filter
:INPUT ACCEPT [192:16904]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [181:20499]
-A INPUT -p tcp -m tcp --dport 25565 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 25565 -j ACCEPT
COMMIT
# Completed on Fri Mar  7 18:41:16 2014


und über

Code:
netstat -ntplue

Kommt das .....

Code:
Aktive Internetverbindungen (Nur Server)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode       PID/Program name
tcp        0      0 0.0.0.0:110             0.0.0.0:*               LISTEN      0          10426       2963/dovecot
tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN      0          10442       2963/dovecot
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      0          3840        2281/apache2
tcp        0      0 0.0.0.0:465             0.0.0.0:*               LISTEN      0          12470       3149/master
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      108        10337       2517/proftpd: (acce
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      0          12454       3149/master
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      0          3842        2281/apache2
tcp        0      0 85.25.195.22:25565      0.0.0.0:*               LISTEN      0          11565       3632/java
tcp        0      0 0.0.0.0:993             0.0.0.0:*               LISTEN      0          10444       2963/dovecot
tcp        0      0 0.0.0.0:xxxx            0.0.0.0:*               LISTEN      0          7538        2448/sshd
tcp        0      0 0.0.0.0:995             0.0.0.0:*               LISTEN      0          10428       2963/dovecot
tcp        0      0 85.25.195.22:3306       0.0.0.0:*               LISTEN      110        12322       2855/mysqld
tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN      0          12462       3149/master
tcp6       0      0 :::110                  :::*                    LISTEN      0          10427       2963/dovecot
tcp6       0      0 :::143                  :::*                    LISTEN      0          10443       2963/dovecot
tcp6       0      0 :::465                  :::*                    LISTEN      0          12472       3149/master
tcp6       0      0 :::25                   :::*                    LISTEN      0          12456       3149/master
tcp6       0      0 :::993                  :::*                    LISTEN      0          10445       2963/dovecot
tcp6       0      0 :::xxxx                 :::*                    LISTEN      0          7540        2448/sshd
tcp6       0      0 :::995                  :::*                    LISTEN      0          10429       2963/dovecot
tcp6       0      0 :::587                  :::*                    LISTEN      0          12464       3149/master


die xxxx habe ich gemacht aus Sicherheits Gründen .


Ich hoffe ihr habt Genug infos , um mir zu helfen .

Ich hoffe ihr könnt mir Helfen , da ich mir kein rat mehr weis , was es noch sein Könnte .

LG euer ice
 
Punkt 1.: Hör auf an einer nicht eingerichteten Firewall rumzufummeln, wenn du offensichtlich nicht weißt, was du tust.

Punkt 2.: Dein Minecraft läuft und ist erreichbar.

Punkt 3.: Es wirkt leider überhaupt nicht cool, mit einem BMW zu protzen, wenn man nicht fahren kann ;-)
 
Last edited by a moderator:
Punkt 1.: Hör auf an einer nicht eingerichteten Firewall rumzufummeln, wenn du offensichtlich nicht weißt, was du tust.

Punkt 2.: Dein Minecraft läuft und ist erreichbar.

Punkt 3.: Es wirkt leider überhaupt nicht cool, mit einem BMW zu protzen, wenn man nicht fahren kann ;-)


Danke für deine Hilfreiche info Top .

1.) habe ich nicht rumgefummelt .

2.) in wie Fern habe ich gefummelt .

3.) Ich habe nur den Port eingetragen . mehr nicht .

Aber danke für deine Info .

Bitte Closed
 
3.) Ich habe nur den Port eingetragen . mehr nicht .
Da du fragst, möchte ich dir gern ausführlich mitteilen, warum ich das geschrieben habe und wie du so eine Sache besser angehen kannst.

Aus deinen Postings ging deutlich hervor, dass auf deinem Server überhaupt keine Firewall-Regeln gesetzt sind. Überhaupt macht ein Port-Filter auf einem einzelnen Server keinen Sinn: Warum willst du Ports schließen, auf denen gar kein Dienst läuft?

An deinen zwei eingefütterten Regeln konnte man sehen, dass du obendrein nicht weißt, wie eine TCP-Verbindung überhaupt funktioniert und was die Ports auf welcher Seite (Source oder Destination) machen. So baut dein Dienst z.B. überhaupt keine ausgehenden Verbindungen auf.

All das lässt mich vermuten, dass du dir irgendwo im Netz Bruchstücken von Informationen gesammelt hast und per Try&Error versuchst, ob es vielleicht etwas nützt, die Zeilen abzuwerfen, die du nicht verstanden hast.

Das mag auf einem Windows-Desktop zu Hause funktionieren. Auf einem Server geht das mit Sicherheit schief. Du musst bei deinem Server einfach wirklich verstehen was du tust, damit du nicht ein Loch in die Konfiguration reißt, die deinen Server verwurschteln oder gar angreifbar machen.

Ich rate dir daher dringend: Mache nichts!, gar nichts!, überhaupt nie nichts! an deinem Server, was du nicht wirklich verstanden hast. Wenn du es nicht verstanden hast, nimm dir die Zeit und die Doku und lies das! Wenn das nicht hilft, besorg dir ein Buch und lies das! Wenn du dabei trotzdem etwas nicht verstehst, kannst du hier gern fragen, dafür ist das Forum da.

Aber niemals!!! Try&Error auf einem Server. Deine Errors müssen nämlich alle anderen im Netz in Form von Spam oder Angriffen ausbaden.

P.S.: Da geht's weiter: http://openbook.galileocomputing.de/unix_guru/
 
Last edited by a moderator:
Also vielleicht hilft es ja eher, erstmal zu sagen, dass bei Server4you (so sieht die Hardware Zusammenstellung auf jedenfall aus..) im Grunde vieles vorkonfiguriert ist.

Server für MineCraft zu eröffnen (erstellen ist wohl übertrieben), ist also super einfach.
Benutzer anlegen, Datei auf den Server legen und dann starten. Bitte natürlich im Screen, sonst ist Putty dicht und der Server beendet.

Sollte dein Server für dich per Clienten trotzdem nicht erreichbar sein, dann solltest du die Versionen überprüfen.

Was mich allerdings etwas stört gerade ist:
Egal wie wenig Ahnung jemand scheinbar hat. Warum wird immer gleich mit Flame los gelegt? Steht doch mal drüber und gut :cool: ;)
Ich hoffe, ich trete nun niemanden auf den Schlips.
 
@TE: Poste doch mal bitte deine ganze Firewallconfig d.h. die Ausgabe von iptables -nvL. Vermutlich ist das meiste davon überflüssig.



Egal wie wenig Ahnung jemand scheinbar hat. Warum wird immer gleich mit Flame los gelegt? Steht doch mal drüber und gut :cool: ;)
Da ist dieses Forum noch eher harmlos.
Das Problem ist, dass jeder ohne Ahnung meist nen Rootserver mit fester IP und 100MBit Anbindung, dafür aber ohne Sicherheitskonzept und Updates hat.
=> potentiell mehr Spam/DDOS/usw für alle anderen.

Außerdem nervt es, wenn Leute ohne Ahnung kommen und für ne hingeklatschte 2Zeilen-Antwort (in diesem Thread nicht der Fall) ne ausführliche Antwort wollen.
Vor allem, wenn man mit der Suchfunktion 5 Threads dazu gefunden hätte.
Die Grundlage für eine funktionierende Lösung ist nunmal, zu verstehen, was man selbst macht und grundlegend zu verstehen, wie das System arbeitet.
Bei ausführlichen Hardwareangaben zu nem Softwareproblem oder Unkenntnis für sport/dport ist fraglich, ob das Wissen da ist.
 
Hmm. Kein Windows? :D

Im Ernst: Es gibt für Windows leider keine gute Alternative.
Können wir nur Hoffen, dass die Backdoors niemals gefunden werden...
 
Im Ernst: Es gibt für Windows leider keine gute Alternative.
Können wir nur Hoffen, dass die Backdoors niemals gefunden werden...

Boar...immer diese hirnlose Panikmache...:mad:
Dann lade dir hier den Sourcecode von putty runter und schau ihn dir durch, du wirst sicher keine Backdoor finden.
Erst nachdenken, bevor du irgendwas ungeprüft weiterverbreitest, was du irgendwo mal im Netz gesehen hast.
 
Also vielleicht hilft es ja eher, erstmal zu sagen, dass bei Server4you (so sieht die Hardware Zusammenstellung auf jedenfall aus..) im Grunde vieles vorkonfiguriert ist.
Du wirst überrascht sein, aber bis auf wenige Ausnahmen wie etwa Gentoo oder Arch ist bei nahezu allen Linux-Distributionen im Grunde vieles sauber vorkonfiguriert. Das befreit einen jedoch nicht von der Pflicht, sich Wissen anzueignen und sich adäquat um seinen Server zu kümmern.

Datei auf den Server legen und dann starten. Bitte natürlich im Screen, sonst ist Putty dicht und der Server beendet.
Bitte natürlich NICHT im Screen!!! Wer Dienste via Screen startet zeigt deutlich, dass er sich nicht ausreichend mit Linux beschäftigt hat und nicht einmal versteht, wie der Bootprozess funktioniert. Dienste werden via SysV-Init-Scripts oder via Systemd gestartet.

Sollte dein Server für dich per Clienten trotzdem nicht erreichbar sein, dann solltest du die Versionen überprüfen.
Hast du meine Antwort gelesen? Der Server IST erreichbar.

Egal wie wenig Ahnung jemand scheinbar hat. Warum wird immer gleich mit Flame los gelegt? Steht doch mal drüber und gut :cool: ;)
Wie ich und andere bereits geschrieben haben: Gelernt wird in einer VM zu Hause, dann kommt hier auch jede Menge Hilfe. Auf einem eigenen Server im Rechenzentrum zu üben ist grob fahrlässig und verantwortungslos allen Anderen gegenüber. Daher die Reaktionen.
 
Bitte natürlich NICHT im Screen!!! Wer Dienste via Screen startet zeigt deutlich, dass er sich nicht ausreichend mit Linux beschäftigt hat und nicht einmal versteht, wie der Bootprozess funktioniert. Dienste werden via SysV-Init-Scripts oder via Systemd gestartet.

Geh mit deinen Tipps am besten zu den großen bekannten Anbietern und erkläre denen wie sie ihr Tagesgeschäft zu machen haben.

Bei manchen Diensten wie z.B. Gameservern macht es Sinn, da die Konsole meist interaktiv ist. Wenn der Server aus welchen Gründen auch immer nicht erreichbar ist (davon gibt es sehr viele), kannst du im Screen nachsehen und interaktiv eingreifen. Auf zur Fehlersuche ist es oftmals besser geeignet als irgend ein Client, der via RCON connected. Natürlich könntest du auch die Logs mit tail -f ansehen, wenn der Prozess als Damon läuft, wobei dir dann aber wiederrum die Interaktivität fehlt. Ich möchte dich mal sehen, wie du ca. 1000 Gameserver über mehrere Maschinen hinweg mit LSBInitScripts verwaltest. Das alles bitte noch dynmisch und für den Nutzer interaktiv (Kosole über das WI & SSH).

Wieso sollte es jetzt jemand der nur einen Server starten will, komplett anders machen?
 
Last edited by a moderator:
Du möchtest dir gern supervisord (http://supervisord.org/) ansehen, der wiederum von Init gestartet wird. Screen ist aus den verschiedensten Gründen kein geeignetes Tool. Das reicht von handhabbarer Prozessverwaltung über Monitoring bis hin zu sinnvollem Logging. Von solch unsinnigen Dingen wie aktiver Login-Shells ganz zu schweigen.

Ach ja: Nur weil es viele machen, muss es noch lange nicht richtig sein. Gerade aus der Gameserver-Ecke ließt man nahezu täglich den gröbsten Quatsch. Seriöse Anbieter scheinen in der Branche wohl leider die Ausnahme zu sein...
 
Last edited by a moderator:
Ich möchte mir supervisord nicht ansehen, weil das schon einsetze (nicht für GS).

Wie gesagt, es fehlt die Interaktivität. Die Konfiguration ist zwar mehr als einfach und das Tool ließe sich auch gut erweitern, ist aber für den GS einsatz ungeeignet.

Ich hab das 8 Jahre lang gemacht und kenne die Vorzüge bei der Fehlersuche im Screen.

Zu deinen genannten Pukten:

> handhabbarer Prozessverwaltung
Mehr als start/stop braucht man nicht

> Monitoring
Munin > RCON-Protokoll

> Logging
Alle GS loggen selbst. Wieso sollte ich dann zwei mal loggen?

>solch unsinnigen Dingen wie aktiver Login-Shells
Entfällt bei der automatisierung "ssh -c"

Das einzige was ich gelten lasse, wäre der Support von XMLRPC. Es ist aber nun so, dass alle WI den Screen nutzen. Wenn du meinst du weißt es besser, kannst du bei den OpenSource Pannels ja nen Issue aufmachen.

Am besten punktest du mit einem realen Beispiel anstatt hir nur von der Theorie zu sprechen.

- Installieren und updaten der Masterserver
- sychronisieren des FastDL
- dynamisches anlegen neuer GS (z.B. mit supervisord)
- Monitoring
- interaktivität der Konsole im Webinterface und der Login-Shell ggf. noch übers Netzwerk
- automatisiert Befehle an die Konsole des Servers schicken (rcon & direkt)
- restartplanung

Noche viele andere Sachen, die ich jetzt vergessen habe. Diese WIs sind fertig und kein Mensch wird sie umstricken, damit nur ein paar Nerds meinen sie wären wichtig für die Welt, glücklich sind. Du bist dir gar nicht über die Auswirkungen dieser kleinen Änderungen bewusst. Ideal ist sie nicht, aber das interessiert auch kein Mensch. Es funktioniert und man wird es nicht ändern.

PS: Die beiliegenden Startscripts der Server (nicht Minecraft) sind mehr als schlecht. Diese dürftest du dann auch noch umschreiben um die gewünschte funktionalität zu erreichen. (LD_LIBRARY_PATH, gdb, ggf. Updateprocess nach dem Restart, sofern Singleserverinstallation)
 
Last edited by a moderator:
Bei mir ist Minecraft der einzige Dienst, welcher nicht vom Upstart geladen wird.
Das hat mehrere Gründe, der wichtigste aber ist, dass die Codequalität von Minecraft etwa Windows ME entspricht.. So kam es bei uns mal vor, dass ein User durch eine Konstruktion im Spiel ein Memory Leak ausgelöst hat und über das Java-Memory-Limit hinweg den ganzen Rechner in den Swap getrieben hat.

Ich habe zwar mittlerweile den Prozess ordentlich begrenzt, möchte aber ehrlich gesagt nicht, dass das Teil automatisch mit meinem System mitstartet, damit ich im Notfall immernochmal nen Hard-Reboot auslösen kann. ;)

Außerdem natürlich der bereits genannte Grund, dass man Minecraft gerne mal in der Konsole ansprechen können möchte, wobei das natürlich auch über RCON möglich wäre (aber mir ehrlich gesagt lieber ist, über meine SSH Verbindung mit Key-based-Auth zu arbeiten, als über Plaintext-TCP irgendwelche Passwörter über den Äther zu jagen.. :D)

Viele Grüße,
Tobias
 
Am besten punktest du mit einem realen Beispiel anstatt hir nur von der Theorie zu sprechen.
Das ist einfach, weil die angesprochenen Probleme ja auch auf viele andere Dienste zutreffen und als gelöst betrachtet werden können. Anbieter wie heroku z.B. zeigen, wie sowas funktionieren kann.

- Installieren und updaten der Masterserver
- sychronisieren des FastDL
- dynamisches anlegen neuer GS (z.B. mit supervisord)
- Monitoring
Nennt sich deployment und geht auch automatisiert z.B. mit capistrano, fabric, ansible oder batou

- interaktivität der Konsole im Webinterface und der Login-Shell ggf. noch übers Netzwerk
- automatisiert Befehle an die Konsole des Servers schicken (rcon & direkt)
- restartplanung
Nennt sich API und bekommen alle anderen auch irgendwie gebacken.

Mehr als start/stop braucht man nicht
Das gilt doch für alle anderen Dienste auch???

Entfällt bei der automatisierung "ssh -c"
Geile Variante, einen Dienst automatisch mit zu booten ;-)

Es ist aber nun so, dass alle WI den Screen nutzen. [...] Diese WIs sind fertig und kein Mensch wird sie umstricken
Das ist wohl der entscheidende Punkt und ich gebe dir vollkommen Recht. Das würde mit Sicherheit einigen Aufwand nach sich ziehen.

Die beiliegenden Startscripts der Server (nicht Minecraft) sind mehr als schlecht.

der wichtigste aber ist, dass die Codequalität von <GAMESERVER> etwa Windows ME entspricht..

Mein Fazit: die Gameserver-Fraktion beweist einmal mehr, eher dürftige Qualtität zu liefern und nicht wirklich kapiert zu haben, wie Linux/Unix + Dienste und Prozessmanagement funktioniert. Die angesprochenen Problemfelder sind sicher nicht ganz trivial, aber wir haben da draußen eine Menge Clouds mit ähnlich gelagerten Anforderungen am Start und bewährte Tools und Workflows die zeigen, wie so etwas funktionieren sollte. Dass eine ganze Branche daran scheitert, einen Dienst vernünftig zu startet ist, naja, nennen wir es: eher schwach...
 
Last edited by a moderator:
Lange Liste... fangen wir mal an:

Nennt sich deployment und geht auch automatisiert z.B. mit capistrano, fabric, ansible oder batou

Die GS bestehen aus manuellen Updates, Updates über ein proprietäres Programm und Updates, die durch das Spiel selbst bezogen werden (ich glaub es war aa2.5)
Die Tools mögen zwar gut sein, aber im Endeffekt gibt es zu viele unterschiedliche Methoden zu Beschaffung der Updates. Problematisch wird es z.B. wenn wie bei AA2.5 die Updates über Binary des Servers selbst bezogen werden und man keinerlei Versionkontrolle hat. Ich hab zumindest nichts verwertbares gefunden. D.h. man könnte nur anhand Datum/Größe und/oder Checksum der Dateien festellen was/wann sich geändert hat. Man kann nicht einfach alles unter einem Hut bekommen. Die Komplexität steigt z.B. noch, wenn nur Updaten will wenn eins zur Verfügung steht und z.B. die von Steam angebotene API zur Versionskontrolle nutzt (und der Updater manchmal einfach hängen bleibt). Unter anderem wird die Version zwischen Server und Client nicht unterschieden. Die AppID (ne Zahl) zur Versionskontrolle muss aber die des Clients sein. Upgedatet wird aber mit der AppID des Servers.

Geile Variante, einen Dienst automatisch mit zu booten ;-)
Du hast nicht verstanden, wie ein WI funktioniert. Wenn du die Kiste neu startest, wir kein einziger GS gestartet. Erst du eingreifen des Kunden werden die Server gestartet. Naja, manche haben die Restartplanung...


Das ist wohl der entscheidende Punkt und ich gebe dir vollkommen Recht. Das würde mit Sicherheit einigen Aufwand nach sich ziehen.

Im Nachinein ist man immer schlauer. Natürlich kann man eine ganz tolle API für alles machen. Es ist aber einfach so, dass es gerade im GS-Bereich viele Sonderfälle gibt. Vieles weiß man vorher gar nicht, sondern merkt es erst wenn es benötigt wird. Wie oft hab ich schon für einen Anbieter mal eben über ein Shell-Script, dass beim GS-Start immer ausgeführt ist und auf allen Servern synchronisiert wird, Worarounds für irgendwelche dämlichen Fehler rausgebracht, welcher dann diesen Fehler auf allen Maschinen behoben hat.

Mein Fazit: die Gameserver-Fraktion beweist einmal mehr, eher dürftige Qualtität zu liefern und nicht wirklich kapiert zu haben, wie Linux/Unix + Dienste und Prozessmanagement funktioniert. Die angesprochenen Problemfelder sind sicher nicht ganz trivial, aber wir haben da draußen eine Menge Clouds mit ähnlich gelagerten Anforderungen am Start und bewährte Tools und Workflows die zeigen, wie so etwas funktionieren sollte. Dass eine ganze Branche daran scheitert, einen Dienst vernünftig zu startet ist, naja, nennen wir es: eher schwach...

Äh, ja :-D
Ich hab den Einstieg durch Gameserver erst in die *nix-Welt geschafft. Ich hatte eine Aufgabe gefunden und da ich von Natur aus faul war einfach alles automatisiert. Da kamen die komischten Scripts bei raus. Mittlerweile mach es mir keinen Spaß mehr, weil alles immer noch beim alten ist. An dem Verhalten der Entwickler ändert sich nichts, fehlerhafte Updates werden rausgerbacht und die Informationen dazu kommen auch nur Scheibchenweise. Wie oft hab ich irgend einen verdammten Gameserver mit einer eigenen glibc starten müssen, wo sich jeder Sysadmin nur noch an den Kopf fassen würde und das zu Recht! Sieh es so: Rein technisch gesehen kann man nichts von der GS-Providern erwarten. Sie nutzen fertige Sachen und das war es auch schon.

Der Knaller zuletzt: Es ist jetzt wahrscheinlich in dem WI, was man mieten kann (bestimmt auch in anderen) immer noch möglich die Startscripte der GS zu verändern. OK, im Protected-Mode nicht. Aber es gibt ja auch Kunden, die z.B. keine WarServer betreiben.

Ach sorry, falls manches jetzt hier überhaupt keinen Zusammenhang ergibt. Bin durch den Messeabbau etwas fertig...
 
manuellen Updates, Updates über ein proprietäres Programm
[...]
keinerlei Versionkontrolle
[...]
der Updater manchmal einfach hängen bleibt
[...]
Wenn du die Kiste neu startest, wir kein einziger GS gestartet. Erst du eingreifen des Kunden werden die Server gestartet.
[...]
An dem Verhalten der Entwickler ändert sich nichts
[...]
fehlerhafte Updates werden rausgerbacht
[...]
die Informationen dazu kommen auch nur Scheibchenweise.
[...]
Gameserver mit einer eigenen glibc starten müssen
[...]
Rein technisch gesehen kann man nichts von der GS-Providern erwarten

Ich denke, im Grunde sind wir der selben Meinung :D
 
Back
Top