Brauch mal Hilfe oder Tipps nach Server-crash

[Theodor R"uthers]

Hallo Leute,

sowas habe ich noch nicht erlebt, jedenfalls nicht unter Linux.

Unser Server ist ein aktuelles debian-queeze und er bedient seit
Jahren 5 bis 6 windows und linux Clients, routed ins Internet, macht
den DB-Server, den File-Server usw.

Am Sonntag gegen 14.00 Uhr war niemand an den Rechnern. Wie ich
nachträglich recherchieren konnte, ist zu der Zeit das Telefon
ausgefallen (seitens der Telekom) - möglicherweise dann auch DSL.

Jedenfalls begannen zu dem Zeitpunkt die Programme nacheinander
auszusteigen und lassen sich seither nicht wieder starten.

Die letzten vernünftigen Meldungen z.B. von fetchmail lauten
beispielsweise:

Feb 5 14:20:50 ottoserver fetchmail[8015]: Server certificate
verification error: unable to get local issuer c
Feb 5 14:20:50 ottoserver fetchmail[8015]: This means that the root
signing certificate (issued for /C=DE/ST=B

oder der INN:
SERVER cant exec in /usr/lib/news/bin/nnrpd Permission denied

oder wwwofled
Fatal: Cannot create spool directory /var/cache/wwwoffle
[Permission denied]....failed.

Apache:
[error] [client 192.168.0.2] (13)Permission denied: access to
/apache2-default/ denied


Usw usw. Der ganze init-prozess kommt nur unvollständig zustande.
Manche Programme starten, andere steigen ohne Fehlermeldung aus.
Samba z. B. startet, läuft auch, meckert aber auch über
Verzeichnisse die angeblich nicht da sind z. B:

'/tmp' does not exist or permission denied when connecting to [IPC$]
Error was Permission denied

Ich habe den Eindruck, das das Rechte - System völlig durcheinander
ist, und überhaupt keine Ahnung, was jetzt noch zu machen wäre.

Letztes Backup ist vom 1. Februar. Sind aber tar.gz und machen wegen
den hardlinks ne Menge Arbeit beim restore. Deshalb - vielleicht
hat jemand von Euch einen Tip für mich.

Danke und Grüße

[Lars Behrens]

Am 07.02.2012 09:26, schrieb Theodor R"uthers:

> Letztes Backup ist vom 1. Februar. Sind aber tar.gz und machen wegen den
> hardlinks ne Menge Arbeit beim restore. Deshalb - vielleicht hat jemand
> von Euch einen Tip für mich.

Kuck dir das Ganze doch erstmal in Ruhe mit ner Live-DVD/Stick an, dann
siehst du, was noch/nicht mehr da ist, wie die Rechte aussehen usw.

Good Luck!

--
Cheerz,
Lars

[Peter Blancke]

Am 2012-02-07, Theodor R"uthers <as...@gmx.de> schrieb:

> ist zu der Zeit das Telefon ausgefallen (seitens der Telekom) -
> möglicherweise dann auch DSL.

Und warum fielen diese Komponenten aus?

Richtig. Wegen eines Ueberspannungsschadens. Und dabei hat es Dir
auch die Technik Deines Servers zerlegt.

Ich wuerde mit Speicher- und Plattentests des Server beginnen. Dazu
ein Lebendig-Betriebssystem Linux von einer Kompaktscheibe starten,
nicht mehr versuchen, den Server anzufahren, weil Du nur mehr und
mehr (womoegliche) Spuren, die Dir helfen koennten, ruinierst.

> Letztes Backup ist vom 1. Februar. Sind aber tar.gz und machen
> wegen den hardlinks ne Menge Arbeit beim restore.

Bei dieser Gelegenheit ueberdenkst Du gleichzeitig Dein
DatensIcherungskonzept und schaffst etwas Vernuenftiges an. Und ja,
"rsync" existiert und hat maechtige Parameter mitgebracht.

Alle anderen Ueberlegungen erscheinen mir augenblicklich
Spekulationen zu sein.

Grusz,

Peter Blancke

--
Hoc est enim verbum meum!

[Uwe Borchert]

Hallo,

Am 07.02.2012 11:56, schrieb Peter Blancke:
> Am 2012-02-07, Theodor R"uthers<as...@gmx.de> schrieb:
>
>> ist zu der Zeit das Telefon ausgefallen (seitens der Telekom) -
>> möglicherweise dann auch DSL.
>
> Und warum fielen diese Komponenten aus?

Das wissen wir nicht!

> Richtig. Wegen eines Ueberspannungsschadens. Und dabei hat es Dir
> auch die Technik Deines Servers zerlegt.

Das ist erst mal nur eine Spekulation. ;-)

> Ich wuerde mit Speicher- und Plattentests des Server beginnen. Dazu
> ein Lebendig-Betriebssystem Linux von einer Kompaktscheibe starten,
> nicht mehr versuchen, den Server anzufahren, weil Du nur mehr und
> mehr (womoegliche) Spuren, die Dir helfen koennten, ruinierst.

Für mich sehen die Fehler wie massive Probleme mit den Partitionen
und/oder Festplatten aus. Da könnte einige Partition und/oder HDD
drunter defekt sein. Ein read-only-Test der Partitionen von einer
Live-CD wäre da erst mal angesagt. Da wirst der OP wahrscheinlich
fündig werden. Das läuft allerdings sehr schön konform mit Deiner
Spekulation.

MfG

Uwe Borchert

[Theodor R"uthers]

Am 7.2.2012 12:39, schrieb Uwe Borchert:

> Für mich sehen die Fehler wie massive Probleme mit den Partitionen
> und/oder Festplatten aus. Da könnte einige Partition und/oder HDD
> drunter defekt sein.

Jo, hab ich auch erst mal vermutet.

> Ein read-only-Test der Partitionen von einer
> Live-CD wäre da erst mal angesagt.

Dann sprich bitte mal, wie genau. Ein fsck.ext3 über alle
Partitionen mit Knoppix wirft keine Fehler aus.

> Da wirst der OP wahrscheinlich fündig werden.

Darauf hoffe ich.

MfG

[Werner Flamme]

Theodor R"uthers [07.02.2012 09:26]:

> Hallo Leute,
>
> sowas habe ich noch nicht erlebt, jedenfalls nicht unter Linux.
>

>[...]

>
> Usw usw. Der ganze init-prozess kommt nur unvollständig zustande.
> Manche Programme starten, andere steigen ohne Fehlermeldung aus.
> Samba z. B. startet, läuft auch, meckert aber auch über
> Verzeichnisse die angeblich nicht da sind z. B:
>
> '/tmp' does not exist or permission denied when connecting to [IPC$]
> Error was Permission denied

Ja, gut - und? Ist die Platte voll (z. B. durch vollgelaufene Logs)?
Existiert /tmp? Welche Rechte sind da?

# ls -ld /tmp
drwxrwxrwt 34 root root 4096 Feb 7 13:02 /tmp

> Ich habe den Eindruck, das das Rechte - System völlig durcheinander
> ist, und überhaupt keine Ahnung, was jetzt noch zu machen wäre.

Nachgucken, ob vielleicht die ein oder andere Meldung doch ihre
Berechtigung hat ('/tmp' does not exist).

> Letztes Backup ist vom 1. Februar. Sind aber tar.gz und machen wegen
> den hardlinks ne Menge Arbeit beim restore. Deshalb - vielleicht
> hat jemand von Euch einen Tip für mich.

Wieso machen tarfiles wegen Hardlinks Probleme? Und wieso werden sie
dann trotzdem verwendet?

Gruß
Werner

[Uwe Borchert]

Hallo,

Am 07.02.2012 13:03, schrieb Theodor R"uthers:
> Am 7.2.2012 12:39, schrieb Uwe Borchert:
>
>> Für mich sehen die Fehler wie massive Probleme mit den Partitionen
>> und/oder Festplatten aus. Da könnte einige Partition und/oder HDD
>> drunter defekt sein.
> Jo, hab ich auch erst mal vermutet.
>
>> Ein read-only-Test der Partitionen von einer
>> Live-CD wäre da erst mal angesagt.
>
> Dann sprich bitte mal, wie genau. Ein fsck.ext3 über alle Partitionen
> mit Knoppix wirft keine Fehler aus.

Äh *stammel* *glaskugelpolier* Optionen read only (-n) und force (-f)?

MfG

Uwe Borchert

[Peter Blancke]

Am 2012-02-07, Theodor R"uthers <as...@gmx.de> schrieb:

> Am 7.2.2012 12:39, schrieb Uwe Borchert:

>> Ein read-only-Test der Partitionen von einer Live-CD wäre da erst
>> mal angesagt.

> Dann sprich bitte mal, wie genau. Ein fsck.ext3 über alle
> Partitionen mit Knoppix wirft keine Fehler aus.

Wie hast Du denn fsck.ext3 aufgerufen? Ich hoffe fuer Dich, dasz Du
das Dateisystem zunaechst NUR LESEND anfaszt. Mit einem Filecheck
drauf zugreifen, wenn die darunter physische Platte Defekte hat,
kann das Ende jeglichen Datenzugriffes sein.

Platten prueft man zunaechst mit

badblocks -v /dev/sdX

Bitte das X entsprechend richtig setzen. Kann es sein, dasz Du bei
der von mir vermuteten Sensibilitaet der Daten einen Fachmann an die
Sache lassen solltest?

[Peter Blancke]

Am 2012-02-07, Uwe Borchert <wetter...@yahoo.com> schrieb:
> Am 07.02.2012 11:56, schrieb Peter Blancke:

> Das ist erst mal nur eine Spekulation. ;-)

Nun, nichts sonst. Was auch sonst? Hier existiert keine Glaskugel.

> Für mich sehen die Fehler wie massive Probleme mit den Partitionen
> und/oder Festplatten aus.

Fuer mich auch. Bis hin zu locker sitzenden Kabeln und was nicht
mehr.

Darum wird dem Problembehafteten ja nun auch vermehrt empfohlen,
zunaechst die Hardware zu untersuchen und nicht auch noch mit
Filesystemchecks auf die Daten zuzugreifen und diese womoeglich noch
zu veraendern.

[Theodor R"uthers]

Am 7.2.2012 13:09, schrieb Werner Flamme:
> Ja, gut - und? Ist die Platte voll (z. B. durch vollgelaufene Logs)?

/dev/sda1 19228276 4373224 13878304 24% /
/dev/sda5 230741364 4308504 214711840 2% /mnt/sda_a
/dev/sda6 230749396 127703788 91324184 59% /mnt/sda_b
/dev/sdb5 240308484 137721796 90379700 61% /mnt/sdb_a
/dev/sdb6 230797592 30533168 188540592 14% /mnt/sdb_b
/dev/sdc5 240308484 2289340 225812156 2% /mnt/sdc_a
/dev/sdc6 230797592 286964 218786796 1% /mnt/sdc_b

> Existiert /tmp? Welche Rechte sind da?
> # ls -ld /tmp
> drwxrwxrwt 34 root root 4096 Feb 7 13:02 /tmp

Na klar:
# ls -ld /tmp
drwxrwxrwt 6 root root 4096 7. Feb 13:31 /tmp

> Nachgucken, ob vielleicht die ein oder andere Meldung doch ihre
> Berechtigung hat ('/tmp' does not exist).

Da sollte nur ein Beispiel dafür sein, das manche Programme ihre
angestammten Verzeichnisse nicht erreichen können.

Noch schärfer wird es wenn ich zum Testen ein neues Programm
installiere. Also apt-get install irgendwas.
Dann hat das irgendwas nicht einmal Rechte auf
/etc/irgendwas/irgendwas.conf
Da kommt sofort: permission denied

Mit ratlosen Grüßen

[Peter Blancke]

Am 2012-02-07, Theodor R"uthers <as...@gmx.de> schrieb:

> /dev/sda1 19228276 4373224 13878304 24% /
> /dev/sda5 230741364 4308504 214711840 2% /mnt/sda_a
> /dev/sda6 230749396 127703788 91324184 59% /mnt/sda_b

etc.

Bitte hier zukuenftig ruhig mit "df -hT" arbeiten, das macht die
Sache leichter lesbar und liefert weitere Informationen mit.

In welcher der o. a. Partitionen liegt denn der "tmp"-Ordner? In der
/dev/sda1?

Ich frage nur, weil

> # ls -ld /tmp
> drwxrwxrwt 6 root root 4096 7. Feb 13:31 /tmp

dieser Ordner sonst nicht derjenige ist, von dem hier die rede ist.

Falls er es doch ist: Warum greifst Du schreibend auf Deine Platte
zu, wenn es Probleme gibt? Oder woher ruehrt sonst der Zeitstempel
"7. Feb 13:31"?

> Noch schärfer wird es wenn ich zum Testen ein neues Programm
> installiere.

Warum tust Du das in einem Zustand, wo Deine Platte offensichtlich
bisher unbekannte Probleme hat?

> Mit ratlosen Grüßen

[Werner Flamme]

Theodor R"uthers [07.02.2012 13:43]:

> Am 7.2.2012 13:09, schrieb Werner Flamme:
>> Ja, gut - und? Ist die Platte voll (z. B. durch vollgelaufene Logs)?
>
> /dev/sda1 19228276 4373224 13878304 24% /
> /dev/sda5 230741364 4308504 214711840 2% /mnt/sda_a
> /dev/sda6 230749396 127703788 91324184 59% /mnt/sda_b
> /dev/sdb5 240308484 137721796 90379700 61% /mnt/sdb_a
> /dev/sdb6 230797592 30533168 188540592 14% /mnt/sdb_b
> /dev/sdc5 240308484 2289340 225812156 2% /mnt/sdc_a
> /dev/sdc6 230797592 286964 218786796 1% /mnt/sdc_b

OK, also nicht vollgelaufen.

for DAT in a b c; do hdparm -Ir /dev/sd$DAT; done

irgendwas Auffälliges, wie z. B. "readonly = 1"? Auch ein

for DAT in a1 a5 a6 b5 b6 c5 c6; do mount /dev/sd$DAT -o rw,remount; done

funktioniert, so dass keine Filesysteme mehr readonly gemountet sind?

>> Existiert /tmp? Welche Rechte sind da?
>> # ls -ld /tmp
>> drwxrwxrwt 34 root root 4096 Feb 7 13:02 /tmp
>
> Na klar:
> # ls -ld /tmp
> drwxrwxrwt 6 root root 4096 7. Feb 13:31 /tmp

Beruhigend :-)

>> Nachgucken, ob vielleicht die ein oder andere Meldung doch ihre
>> Berechtigung hat ('/tmp' does not exist).
> Da sollte nur ein Beispiel dafür sein, das manche Programme ihre
> angestammten Verzeichnisse nicht erreichen können.

Dachte ich mir fast. Du kannst also allen Fehlermeldungen nachgehen, um
zu sehen, welche Berechtigungen die Dateien/Verzeichnisse haben :-P

> Noch schärfer wird es wenn ich zum Testen ein neues Programm
> installiere. Also apt-get install irgendwas.
> Dann hat das irgendwas nicht einmal Rechte auf
> /etc/irgendwas/irgendwas.conf
> Da kommt sofort: permission denied

Von wem? Beim Installationsversuch? Du willst jetzt sagen, dass Du auf
ein kaputtes System noch etwas draufinstallierst? Mutig!

Bei uns ist Sonntag ein Nagios-Server ausgestiegen - hat nach
Herzenslust Fehler generiert, SMS geschickt, 15 Minuten später alles OK,
wieder SMS usw. Konnte nur durch Serverneustart behoben werden (init 6).
Der Service konnte nicht neu gestartet werden, weil der User nagios
angeblich nicht existierte... Zum Glück hat die Kiste ein eingebautes
KVM, denn das Netz war auch tot (kein Mailversand, kein ssh-Login). Nach
dem Reboot war alles in bester Ordnung.

Gruß
Werner

[Theodor R"uthers]

Am 7.2.2012 14:12, schrieb Werner Flamme:

> for DAT in a1 a5 a6 b5 b6 c5 c6; do mount /dev/sd$DAT -o rw,remount; done
> funktioniert, so dass keine Filesysteme mehr readonly gemountet sind?

In einigen Stunden. Gerade läuft zum zweiten mal ein Badblock-Test
Sieht aber nicht nach Fehlern aus.

>> Noch schärfer wird es wenn ich zum Testen ein neues Programm
>> installiere. Also apt-get install irgendwas.
>> Dann hat das irgendwas nicht einmal Rechte auf
>> /etc/irgendwas/irgendwas.conf
>> Da kommt sofort: permission denied
>
> Von wem? Beim Installationsversuch?

Das ist kein Versuch, das Programm wird fehlerfrei installiert.
Das ist alles völlig Problemlos. Nur starten, das tuts nicht.

> Du willst jetzt sagen, dass Du auf
> ein kaputtes System noch etwas draufinstallierst? Mutig!

Wieso nicht, spätestens morgen früh wird neu installiert. Wenn ich
den Fehler nicht bis dahin gefunden habe. Alle wichtigen Daten, die
Datenbank und die Homverzeichnisse der User sind gesichert.

Ein Server ohne X ist ratzfatz installiert. Mich wurmt nur, das ich
den Fehler nicht finde. Wie ich schon schrieb, seit 1995 mit Linux
unterwegs, aber das habe ich noch nicht erlebt.
Und hier liegt bestimmt kein Hardware-Fehler vor. Den hätte ich
längst gefunden.

Gruß Theo

[Peter Blancke]

Am 2012-02-07, Theodor R"uthers <as...@gmx.de> schrieb:

> spätestens morgen früh wird neu installiert. Wenn ich den Fehler
> nicht bis dahin gefunden habe.

Hmmm... Ist doch ein Linuxsystem.

> Ein Server ohne X ist ratzfatz installiert.

Das ist voellig richtig. Und trotzdem wuerde ich, sofern Du
Plattenplatz hast, vorweg ein Abbild des verkorksten Systems machen
und beizeiten dort forensisch nachsteigen, respektive dann, wenn die
derzeitige Platte problemlos auslesbar ist.

Angriffsszenarien koennen vielschichtig sein und sie nicht erkannt
zu haben, koennte beizeiten gleiche/aehnliche Probleme auf den Plan
rufen.

> Und hier liegt bestimmt kein Hardware-Fehler vor. Den hätte ich
> längst gefunden.

Sicher? Badblocks ist zwischenzeitlich durch? Memtest lief 24
Stunden lang? Kabel ueberprueft?

Thermische Probleme koennten ebenfalls die Probleme der Platten
verursachen. Ich rate dazu, fuer das kommende System zusaetzlich
lm-sensors und evt. Munin oder Konsorten zu installieren, auch
liefert smartctl hier passende Informationen.

"Neuinstallieren und die Probleme sind weg" waere fuer mich
persoenlich voellig unbefriedigend.

[Helmut Hullen]

Hallo, Theodor,

Du meintest am 07.02.12:

>> Ja, gut - und? Ist die Platte voll (z. B. durch vollgelaufene Logs)?

> /dev/sda1 19228276 4373224 13878304 24% /
> /dev/sda5 230741364 4308504 214711840 2% /mnt/sda_a
> /dev/sda6 230749396 127703788 91324184 59% /mnt/sda_b
> /dev/sdb5 240308484 137721796 90379700 61% /mnt/sdb_a
> /dev/sdb6 230797592 30533168 188540592 14% /mnt/sdb_b
> /dev/sdc5 240308484 2289340 225812156 2% /mnt/sdc_a
> /dev/sdc6 230797592 286964 218786796 1% /mnt/sdc_b

Inodes verbraucht?

df -i

sollte da weiterhelfen.

Dann:

ls -ld /
ls -ld /etc

Wenn auch das nicht hilft (die Verzeichnisse müssen/sollten "root:root"
gehören und 755 als Rechte haben): dann könnte die Platte einen
gewaltigen Hau haben;

Knoppix-CD,

badblocks -nsv -b65536 -c16384 /dev/sdx

(o.ä.). Die Kiste ist dann eine Weile beschäftigt ...

Viele Gruesse
Helmut

"Ubuntu" - an African word, meaning "Slackware is too hard for me".

[Theodor R"uthers]

Am 7.2.2012 15:08, schrieb Peter Blancke:

> Sicher? Badblocks ist zwischenzeitlich durch?

0 defekte Blöcke gefunden

> Memtest lief 24
> Stunden lang? Kabel ueberprueft?

Da reicht die Zeit nicht. Dies ist ein produktives System

> for DAT in a b c; do hdparm -Ir /dev/sd$DAT; done

nichts auffälliges. Readonly überall = 0

> for DAT in a1 a5 a6 b5 b6 c5 c6; do mount /dev/sd$DAT -o
> rw,remount; done

echo $?
0

> Thermische Probleme koennten ebenfalls die Probleme der Platten
> verursachen.

Im Moment bestimmt nicht. Unbeheizter Serverraum.

> "Neuinstallieren und die Probleme sind weg" waere fuer mich
> persoenlich voellig unbefriedigend.

Was glaubst du, wie mich das wurmt.
Aber da kommt grad was von Helmut. Da könnte was dran sein

Grüße

[Theodor R"uthers]

Am 7.2.2012 15:45, schrieb Helmut Hullen:

> Inodes verbraucht?
> df -i
Zwischen 1 und 9 Prozent

> ls -ld /etc
Das ist in Ordnung:
drwxr-xr-x 131 root root 12288 7. Feb 15:49 /etc

> ls -ld /

Ja Hallo aber auch - das ist es vielleicht:
drwxrwx--- 22 theo users 4096 6. Feb 18:55

Thats me als user und nicht root, wie kriege ich das denn repariert?

Und frei nach Janosch:
Wenn das - dann Danke

[Uwe Borchert]

Hallo,

Am 07.02.2012 13:36, schrieb Peter Blancke:
> Am 2012-02-07, Theodor R"uthers<as...@gmx.de> schrieb:
>> Am 7.2.2012 12:39, schrieb Uwe Borchert:
>
>>> Ein read-only-Test der Partitionen von einer Live-CD wäre da erst
>>> mal angesagt.
>
>> Dann sprich bitte mal, wie genau. Ein fsck.ext3 über alle
>> Partitionen mit Knoppix wirft keine Fehler aus.
>
> Wie hast Du denn fsck.ext3 aufgerufen? Ich hoffe fuer Dich, dasz Du
> das Dateisystem zunaechst NUR LESEND anfaszt. Mit einem Filecheck
> drauf zugreifen, wenn die darunter physische Platte Defekte hat,
> kann das Ende jeglichen Datenzugriffes sein.

Ich habe ja extra darauf hingewiesen. Die Option sollte -n sein.
Ich bin mir aber nicht sicher ob das eine oder andere System diese
Option als Default aufweisen könnte. Daher immer explizit anknipsen.

> Platten prueft man zunaechst mit
>
> badblocks -v /dev/sdX
>
> Bitte das X entsprechend richtig setzen.

Das würde ich aber erst als zweiten Schritt anwenden. Nach meinen
bisherigen Erfahrungen waren es fast immer Probleme mit kaputten
Dateisystemen. Man sollte aber beide Tests fahren? Die Reihenfolge
ist aber IMHO Geschmackssache und bei fsck vor badblocks hatte ich
(in meinen Fällen!) immer schneller den Fehler raus. badblocks
lief da bei mir fast immer ohne Maulen und Mosern dann am Ende
(teilweise über Nacht) durch, so ich es nicht unterlassen habe.

PS: Vollgelaufenes /tmp könnte übrigens auch sein. Oder aber
verdrehte Rechte auf /tmp

drwxrwxrwt 8 root root 20480 7. Feb 17:03 tmp

Falls das nicht so da steht: chmod 1777 /tmp sollte helfen? IIRC
kann tar beim Entpacken von / (z.B. von einem alten Systemabbild zur
Wiederherstellung) in einem Verzeichnis da die Rechte verbiegen.

MfG

Uwe Borchert

[Theodor R"uthers]

Am 7.2.2012 16:14, schrieb Theodor R"uthers:

> Thats me als user und nicht root, wie kriege ich das denn repariert?

Pardon, das war natürlich ne dumme Frage, schon erledigt.

Und es sieht gut aus. Die kritischen Programme starten ohne murren.


Und noch einmal Helmut, frei nach Janosch:

[Helmut Hullen]

Hallo, Theodor,

Du meintest am 07.02.12:

>> ls -ld /

> Ja Hallo aber auch - das ist es vielleicht:
> drwxrwx--- 22 theo users 4096 6. Feb 18:55

So etwas habe auch ich (versehentlich) erreicht, indem ich einen Tarball
mit diesen Verzeichnis-Rechten drüber-entpackte.

[Uwe Borchert]

Hallo,

Am 07.02.2012 21:01, schrieb Helmut Hullen:
> Hallo, Theodor,
>
> Du meintest am 07.02.12:
>
>
>>> ls -ld /
>
>> Ja Hallo aber auch - das ist es vielleicht:
>> drwxrwx--- 22 theo users 4096 6. Feb 18:55
>
> So etwas habe auch ich (versehentlich) erreicht, indem ich einen Tarball
> mit diesen Verzeichnis-Rechten drüber-entpackte.

Genau danach wollte ich Theodor fragen: Hast Du einen Tarball mit
diesen Rechten direkt in / entpackt? Mir ist dies in /tmp passiert.
Das war ein Systemabbild als Tarball mit den handelsüblichen Rechten
von / und root. Danach waren die User weg vom X und ihren Anwendungen.

MfG

Uwe Borchert

[Sieghard Schicktanz]

Hallo Theodor,

Du schriebst am Tue, 07 Feb 2012 13:43:46 +0100:

> Noch schärfer wird es wenn ich zum Testen ein neues Programm
> installiere. Also apt-get install irgendwas.

Auf eine kaputte Platte / ein kaputtes Dateisystem installieren ist schon
recht wagemutig...

> Dann hat das irgendwas nicht einmal Rechte auf
> /etc/irgendwas/irgendwas.conf
> Da kommt sofort: permission denied

Hast Du mal nachgesehen, was "/" für Rechte hat? (ls -ld /)

Ein Bekannter hat da schon zweimal das Problem gehabt, daß dem das "d"
entfallen war, womit natürlich alles, was nicht root war, keinen Zugriff
mehr fand. Natürlich waren keine Logins möglich, niemand außer root konnte
irgendwelche Dateien finden u.s.w.
Wie das zustande kommen konnte, war nie zu eruieren...

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[Sieghard Schicktanz]

Hallo Theodor,

Du schriebst am Tue, 07 Feb 2012 16:07:18 +0100:

> > Thermische Probleme koennten ebenfalls die Probleme der Platten
> > verursachen.
> Im Moment bestimmt nicht. Unbeheizter Serverraum.

Kommt auf die aktuelle Temperatur an - Platten gehen nicht nur durch
Überhitzung kaputt, sie verkraften auch keine Unterkühlung. Schließlich
sind das schnelllaufende Motoren, die geschmiert werden wollen, und wenn's
zu kalt wird, schmiert sich nix mehr -> Lagerschaden. Vorher wird aber wohl
schon das Motörchen überlastet - viel an Reserven haben die ja nicht - und
damit passen die Bits nicht mehr in die Abtastelektronik (Fehlanpassung der
Zeitkonstanten). Die 0 "bad blocks" sprechen da zwar etwas dagegen, aber
badblocks ist eher wenig zimperlich und probiert schon recht extensiv,
wenn ein Fehler auftritt, bevor es aufgibt und den auch meldet.

[Hauke Laging]

Theodor R"uthers wrote on Dienstag, 7. Februar 2012 09:26:

> SERVER cant exec in /usr/lib/news/bin/nnrpd Permission denied
>
> oder wwwofled
> Fatal: Cannot create spool directory /var/cache/wwwoffle
> [Permission denied]....failed.
>
> Apache:
> [error] [client 192.168.0.2] (13)Permission denied: access to
> /apache2-default/ denied

> '/tmp' does not exist or permission denied when connecting to [IPC$]
> Error was Permission denied

Was ist denn mit den fraglichen Verzeichnissen und ihren Rechten? Ist das
alles auf einem einzigen Volume? Hat da möglicherweise das Dateisystem in
Teilen die Grätsche gemacht und/oder sind (wenn auch schlecht erklärlich)
Mountoptionen durcheinander geraten (siehe /proc/mounts)? Grundsätzlich ist
strace Dein Freund, um das Problem einzugrenzen.


CU

Hauke
--
http://www.hauke-laging.de/ideen/
D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814

[Theodor R"uthers]

Am 7.2.2012 21:20, schrieb Uwe Borchert:

>>
>> So etwas habe auch ich (versehentlich) erreicht, indem ich einen Tarball
>> mit diesen Verzeichnis-Rechten drüber-entpackte.
>
> Genau danach wollte ich Theodor fragen: Hast Du einen Tarball mit
> diesen Rechten direkt in / entpackt? Mir ist dies in /tmp passiert.

Leute, ich war nicht am Rechner, als die Probleme auftraten. Das
schrieb ich schon im OP. Ich habe alles erst Stunden später aus den
log-files herausgelesen. Ich habe auch nichts entpackt, oder
sonstwie am Rechner gemacht.

Wenn ich die Zeit finde werde ich aber versuchen den Fehler zu
reproduzieren.

Nochmal Dank an Alle
Grüße

[Ansgar Strickerschmidt]

Also schrieb Theodor R"uthers:

> Am 7.2.2012 21:20, schrieb Uwe Borchert:
>
>>>
>>> So etwas habe auch ich (versehentlich) erreicht, indem ich einen
>>> Tarball
>>> mit diesen Verzeichnis-Rechten drüber-entpackte.
>>
>> Genau danach wollte ich Theodor fragen: Hast Du einen Tarball mit
>> diesen Rechten direkt in / entpackt? Mir ist dies in /tmp passiert.
>
> Leute, ich war nicht am Rechner, als die Probleme auftraten. Das schrieb
> ich schon im OP.

Aber vielleicht jemand anderer - ungebetene Gäste??
Veränderte Rechte lassen so eine Vermutung zu. Wobei ein sorgfältiger
Eindringling es doch tunlichst vermeidet, solche Spuren zu hinterlassen...

Ansgar

--
*** Musik! ***

[Theodor R"uthers]

Am 7.2.2012 21:19, schrieb Sieghard Schicktanz:

> Ein Bekannter hat da schon zweimal das Problem gehabt, daß dem das "d"
> entfallen war, womit natürlich alles, was nicht root war, keinen Zugriff
> mehr fand. Natürlich waren keine Logins möglich, niemand außer root konnte
> irgendwelche Dateien finden u.s.w.
> Wie das zustande kommen konnte, war nie zu eruieren...

Sieht hier genauso aus. Ich glaube nicht das es mit gelingt,
herauszufinden wie das passiert ist. Ich habe in meinem ganze
Linux-Leben noch niemals eine Manipulation am Wurzelsystem
vorgenommen oder vornehmen müssen.

Grüße

[Sieghard Schicktanz]

Hallo Theodor,

Du schriebst am Thu, 09 Feb 2012 07:47:24 +0100:

> > Ein Bekannter hat da schon zweimal das Problem gehabt, daß dem das "d"
> > entfallen war, womit natürlich alles, was nicht root war, keinen Zugriff

...
> Sieht hier genauso aus. Ich glaube nicht das es mit gelingt,
> herauszufinden wie das passiert ist. Ich habe in meinem ganze
> Linux-Leben noch niemals eine Manipulation am Wurzelsystem
> vorgenommen oder vornehmen müssen.

Ich auch nicht, aber auf diesem Debian-System ist das vorgekommen.
Vielleicht hatte er auch, wie im Verlauf der Diskussion ja mal angeführt,
ein Paket in / entpackt - aber wer erinnert sich schon nach mehrstündiger
bis -tägiger Suche nach einem "ganz anderen" Fehler noch daran?

Aber wenigstens läuft's ja inzwischen auch bei Dir wieder.