Server ist nicht erreichbar auser mit SSH!

Briariuss

Well-known member
ID: 361993
L
13 August 2009
83
3
Wie da Oben steht ist mein server nicht erreichbar ob damein oder kunden login oder admin ist egal seite nicht gefunden! wenn ich aber anpinge oder über SSH mich einloge gehts. Möchte gerne meine Datenbank retten aber wie?
über phpmyadmin gehts ja nicht!
 
Wenn Du mittels SSH-Client auf die Kiste kommt, prüf ob Apache läuft:

Code:
ps -aux|grep apache

Läuft der Indianer evtl. an einer IPv6-Adresse?

Code:
netstat -an|grep LISTEN
Es sollte etwas wie:
Code:
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
beinhalten. (nicht tcp6)

Ist 'ne Firewall installiert und ggf. falsch konfiguriert?

Code:
iptables -L

Ist eine Domain geschaltet und wird diese in die richtige IP-Adresse aufgelöst?

Code:
ping yourdomain.tld
Dies aber von einem fremden Host, bspw. Dein HeimPC


Gruß
 
ist ein Root von server4you ja ich weiß nicht die aller besten.
glaube schon das eine Firewall installiert ist.

1. ping bekomme ich eine Antwort

2.netstat -an|grep LISTEN
tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:783 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:465 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN
tcp 0 0 85.25.143.171:53 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN

3. iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

4.ps -aux|grep apache
Warning: bad ps syntax, perhaps a bogus '-'? See https://procps.sf.net/faq.html
root 5260 0.0 0.0 3004 756 pts/0 R+ 15:55 0:00 grep apache
 
4.ps -aux|grep apache
Warning: bad ps syntax, perhaps a bogus '-'? See https://procps.sf.net/faq.html
root 5260 0.0 0.0 3004 756 pts/0 R+ 15:55 0:00 grep apache
Sorry, das '-' war zu viel, tut aber nichts zur Sache...es läuft kein Prozess mit dem Namen. Dabei fällt mir ein, dass der Apache auf manchen Systemen auch unter einem anderen Prozessnamen läuft. Try again:

Code:
ps aux|grep httpd


Versuch den Apachen zu starten:

Code:
/etc/init.d/apache start
oder
Code:
/etc/init.d/apache2 start
je nach Apache-Version


wenn es danach immer noch nicht geht:

Code:
apachectl configtest
oder
Code:
apache2ctl configtest
je nach Apache-Version. Muss "Syntax OK" melden.


Wenn er dennoch nicht will, unter /var/log/apache(2)/ findest du den Error-Log, in dem auch steht warum der Indianer nicht will.

Was für ein Betriebssystem ist installiert?
 
Betriebssystem: Ubuntu 8.04 LTS
bei versuch zum starten un testen kommt immer:
Syntax error on line 143 of /etc/apache2/apache2.conf:
Invalid command 'Order', perhaps misspelled or defined by a module not included in the server configuration

Und da steht das line 143 of /etc/apache2/apache2.conf:
#
# The following lines prevent .htaccess and .htpasswd files from being
# viewed by Web clients.
#
<Files ~ "^\.ht">
Order allow,deny
Deny from all
</Files>

Danke das du mir hilft!

Das hilft alles nicht danach kommt wieder ein anderer fehler und dann wieder einer kann man die datenbanken ürgenwie retten?
 
Zuletzt bearbeitet:
wenn ich es versuche bekomme ich kein zugang.
mysqldump: Got error: 1045: Access denied for user 'root'@'localhost' (using password: YES) when trying to connect

25 Mio wenn jemand das hinbekommt!!!!
 
@actrosdriver: Das ist die zweite Möglichkeit. :)

@Briariuss: Dann hast du ein falschen / kein Passwort angegeben.
Oder hast du das übersehen?
Code:
mysqldump -h HOSTNAME -u USERNAME -pPASSWORT ALTERDATENBANKNAME > backup.sql
ACHTUNG: das Passwort muss direkt am -p stehen!
 
Wieso wegen einer Fehlerhaften Apacheconfig die DB sichern? *confused*

Ist es denn geplant den Server ohnehin neu aufzusetzen, oder stellt das für Dich gerade den "letzten Ausweg" dar?

Vermutlich fehlt Dir das passende Apachemodul. Try:

Code:
a2enmod authz_host
apache2ctl configtest

Wenn's nun stimmt, dann

Code:
/etc/init.d/apache2 start

Gruß
 
Habe etwas viel dran gemacht wuste nur nicht mehr was und dann ging nach ein reboot nach 2 tagen nichts mehr. Das wegen wollte ich den Server neu aufzusetzen. Habe aber vergessen das ich da noch wichtige daten zu backupen habe, es aber dank euch wieder hinbekommen das wegen bekommt ihr 5 Mio bonus von mir fürs Helfen.
 
Zuletzt bearbeitet:
Deine Datenbanken liegen in /var/lib/mysql/ . Pack die zusammen und ziehe sie mit sftp runter.
@actrosdriver: Das ist die zweite Möglichkeit. :)
Mal abgesehen von den "Vorsicht Server"-Initiativen, die ich hier ganz ausdrücklich unterstützen möchte: Die mysql-Daten packen und runterziehen ist bei allen Datenbank-Engines außer MyISAM eine eher schlechte Idee, weil nicht plattformunabhängig. Besonders InnoDB macht da gerne Probleme, wenn die Daten ohne SQL-Dump auf eine andere Architektur gezogen werden ;).

Außerdem sollte der mysql-Server vorher vielleicht besser ausgemacht werden ... ("wie geht das?" :roll:)
 
kopieren

Hallo

Die mysql-Daten packen und runterziehen ist bei allen Datenbank-Engines außer MyISAM eine eher schlechte Idee, weil nicht plattformunabhängig. Besonders InnoDB macht da gerne Probleme, wenn die Daten ohne SQL-Dump auf eine andere Architektur gezogen werden

Wieso, wenn voin einem Linuxsystem z.B. /var komplett per cp kopiert wird und die Dateien dan auch noch komprimiert auf ntfs abgelegt werden und später zurückgespielt werden, wo liegt das Problem.
Der Server wird ja nach dem neuaufsetzen auch wieder unter Linux laufen.
Da sollte Mysql eigentlich nicht meckern.
 
Das Problem tritt zum Beispiel auf, wenn du InnoDB-Daten von einem 64bit-System auf ein 32bit-System einfach rüberziehst - oder umgekehrt.
Standard-Datentypen sind auf beiden Systemen unterschiedlich groß; das führt ganz schnell zu Problemen.

Bleibt es bei einem vergleichbaren Serversystem (x-Bit-Architektur wird beibehalten, gleicher Befehlssatz, ...) treten im Normalfall keine Probleme auf - trotzdem ist und bleibt ein SQL-Dump die sicherere Variante ;).
 
Natürlich ist ein Dump besser, keine Frage. Nur, wenn Du auch an den MySQL-Server nimmer rankommst, ist das kopieren die beste Möglichkeit.
Im Zweifelsfall schaltest Du InnoDB ab, kopierst rein und dumpst dann auf dem neu installierten einmal raus und mit angeschaltetem InnoDB wieder rein.
Wichtig ist ja im Moment nur, daß die Daten nicht verloren gehen..