Server ist nicht erreichbar auser mit SSH!

[Briariuss]

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!

[TerraTux]

Wenn Du mittels SSH-Client auf die Kiste kommt, prüf ob Apache läuft:

1:
ps -aux|grep apache

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

1:
netstat -an|grep LISTEN

Es sollte etwas wie:

1:
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN

beinhalten. (nicht tcp6)

Ist 'ne Firewall installiert und ggf. falsch konfiguriert?

1:
iptables -L

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

1:
ping yourdomain.tld

Dies aber von einem fremden Host, bspw. Dein HeimPC


Gruß

[Briariuss]

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 http://procps.sf.net/faq.html
root 5260 0.0 0.0 3004 756 pts/0 R+ 15:55 0:00 grep apache

[TerraTux]

Zitat von Briariuss

4.ps -aux|grep apache
Warning: bad ps syntax, perhaps a bogus '-'? See http://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:

1:
ps aux|grep httpd

Versuch den Apachen zu starten:

1:
/etc/init.d/apache start

oder

1:
/etc/init.d/apache2 start

je nach Apache-Version


wenn es danach immer noch nicht geht:

1:
apachectl configtest

oder

1:
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?

[Briariuss]

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?

[Darklord]

Bin gerade zu faul es selber zu schreiben.
Hier kannst eine Möglichkeit nachlesen.
http://wiki.goneo.de/doku.php?id=ssh-mysqldump
http://blog.ingeniumdesign.de/2009/0...-dump-via-ssh/

[Briariuss]

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]

Deine Datenbanken liegen in /var/lib/mysql/ . Pack die zusammen und ziehe sie mit sftp runter.

[Darklord]

@actrosdriver: Das ist die zweite Möglichkeit.

@Briariuss: Dann hast du ein falschen / kein Passwort angegeben.
Oder hast du das übersehen?

ACHTUNG: das Passwort muss direkt am -p stehen!

[TerraTux]

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:

1:
2:
a2enmod authz_host
apache2ctl configtest

Wenn's nun stimmt, dann

1:
/etc/init.d/apache2 start

Gruß

[Briariuss]

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.

[Arusiek]

Ich quote mal, weil ich den ersten Link bis vor kurzem noch gar nicht kannte (Danke an chrisi01), aber fast besser finde als den zweiten, den ich eigentlich gepostet hätte

Zitat von chrisi01

http://burnachurch.com/70/dein-neuer-linux-server/

http://www.vorsicht-server.de

Gruß Aru

[raven]

Zitat von actrosdriver

Deine Datenbanken liegen in /var/lib/mysql/ . Pack die zusammen und ziehe sie mit sftp runter.

Zitat von Darklord

@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?" )

[papslf58]

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.

[raven]

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 .