• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst] openSUSE 11.2 + amanda

W

wshbg

Newbie
Moin,
zuerst das outing: dies ist ein crossposting. Die gleiche Frage bei http://forums.opensuse.org/applications/432377-oss-11-2-amanda.html#post2115482 seit 5.2.10 und bei zmanda http://forums.zmanda.com/showthread.php?t=2573 seit 9.2.10. Und weil dort bisher keine Lösungen ermittelt wurden bzw. kein reply erfolgte jetzt die Frage hier. ;-)
Ich verwende amanda schon mehrere Jahre, ich denke die Konfiguration ist ok. Nach einem SuSE online-update wurde u.a. auch amanda auf version 2.6.1.1-3.5.1 x86_64 aktualisiert.
Seitdem habe ich folgendes Problem.
amcheck für den fehlerhaften client:
Code: 
 amanda@muemmel:/var/log> amcheck -c mue_hd muemmel1 sdb2
Amanda Backup Client Hosts Check
--------------------------------
ERROR: muemmel1: [can not execute /usr/lib/amanda/runtar: Permission denied]
Client check: 1 host checked in 0.239 seconds.  1 problem found.

(brought to you by Amanda 2.6.1p1)
und ein Auszug aus dem Logfile auf dem client
Code: 
OPTIONS features=ffffffff9ffeffffffff7f;
OK sdb2
OK sdb2
OK /
ERROR [can not execute /usr/lib/amanda/runtar: Permission denied]
OK /bin/tar executable
OK /var/lib/amanda/gnutar-lists/. read/writable
OK /usr/bin/gzip executable
OK /dev/null read/writable
OK /tmp/amanda has more than 64KB available.
OK /tmp/amanda has more than 64KB available.
OK /etc has more than 64KB available.
Das sieht so simpel aus, aber ... wichtig: diese Version von amanda funktioniert auf einem PC mit INTEL Processor, der Fehler ist auf einem PC mit AMD Processor. Beide PC's sind gleich konfiguriert und vor dem update war alles ok.
Nach dem einspielen der Vorversion amanda-2.6.1.1.-3.4.x86_64.rpm ist der Fehler immer noch vorhanden.
Ich vermute inzwischen, dass es kein amanda Fehler ist, sondern ein Fehler in einer Systemdatei, die amanda benutzt. Und genau das kann ich nicht finden. Wie kann ich das weiter eingrenzen?
Wilfried
 
OP
W

wshbg

Newbie
Nur mal so die Ergebnisse (zum crossposting):
die Frage bei forums.zmanda.com ergab bisher 97 views / 0 replies
forums.opensuse.org 234 views / 12 replies
...und ich suche immer mal wieder, bisher ohne Erfolg.
Wilfried
 
framp

framp

Moderator
Teammitglied
wshbg schrieb:
...und ich suche immer mal wieder, bisher ohne Erfolg.
Zum Vergrößern anklicken....
Vermutlich liegt es daran, dass keiner amanda kennt bzw benutzt. Ich musste auch erst einmal googeln was das für ein Tool ist. Aber mir scheint das wohl weniger ein amanda Problem zu sein als die Frage, wie man rausbekommen kann, wer für das Problem verantwortlich ist.
 
A

Anonymous

Gast
Ich würde mal vermuten das ist ein Rechteproblem das auf unterschiedliche GruppenIDs auf unterschiedlichen Rechnern beruht.
At the server /etc/passwd says
amanda:x:37:112:Amanda admin:/var/lib/amanda:/bin/bash where 112 is group amanda.
At the faulty client
amanda:x:37:115:Amanda admin:/var/lib/amanda:/bin/bash where 115 is group amanda there.
Wilfried
Reply With Quote
Zum Vergrößern anklicken....

zwar werden dir die Rechner local immer sagen das du zur Gruppe amanda gehörst, doch wenn du remote von einem anderem Rechner kommst dann kommst du mit einer anderen GruppenID und die wird dann nicht als amanda erkannt.

auf allen Rechner sollte
Code: 
grep amanda /etc/group
die selbe GruppenID bringen, ist das nicht der Fall muss das sichergestellt werden, entweder auf dem betreffenden Rechner die Gruppe umstellen und bei allen Dateien die zu dieser Gruppe gehören müssen dann auch die GruppenIDs entsprechend geändert werden.

Oder nochmal das gesammte Paket komplett deinstallieren, und sollte dann die Gruppe amanda nicht gelöscht sein, diese dann löschen und noch mal neu installien. Eventuell war vor der Installation schon eine Gruppe amanda mit "falscher" ID bekannt, so das bei der Installation dieses ID genommen wurde und nicht das was im Paket als GruppenID vorgesehen war.

robi
 
OP
W

wshbg

Newbie
robi schrieb:
Ich würde mal vermuten das ist ein Rechteproblem das auf unterschiedliche GruppenIDs auf unterschiedlichen Rechnern beruht.
Zum Vergrößern anklicken....
Danke für die Antwort, aber nein, die Vermutung ist schlicht falsch. Die numerische ID von Benutzer oder Gruppe zwischen Server und Client spielt keine Rolle. Auf dem Client wird über port 10080 (/etc/services) durch den xinetd das zugehörige Programm amandad angeworfen. Unter welchen ID's amandad läuft bestimmt die Konfiguration in /etc/xinetd.d/amanda. Dort ist konfiguriert, dass der Daemon unter user = amanda und group = amanda läuft. Offensichtlich tut er das aber nicht .-(
Ich habe jetzt als workaround (das ist gegen alle Sicherheit) das Programm /usr/lib/amanda/runtar statt mit
Code: 
-rwsr-x--- 1 root amanda 9884 21. Jan 00:46 /usr/lib/amand/runtar
mit den Rechten
Code: 
-rwsr-xr-x 1 root amanda 9884 21. Jan 00:46 /usr/lib/amanda/runtar
gestartet. Damit läuft amcheck fehlerfrei und die Sicherung funktioniert.
...nur verstehen tue ich das nicht. Ein Programm (hier amandad) ausgestattet mit den Rechten des Users amanda und der Group amanda darf doch runtar starten und erhält mit dem SUID dann die Rechte von root. Das ist doch auch der Sinn der Sache.
Wilfried
 
A

Anonymous

Gast
Code: 
-rwsr-xr-x 1 root amanda 9884 21. Jan 00:46 /usr/lib/amanda/runtar
Kann nicht der Lösung letzter Schluss sein. Wenn das Pogramm in etwa das macht was es im Namen verspricht, (tar-ähnlich arbeiten) könnte jeder "böse" lokale User wahrscheinlich mit wenigen Konsolbefehlen die volle Kontrolle des Servers übernehmen und mit dem Rechner machen was er wollte.

Müsste man sich genauer anschauen was dort für Netzwerkprotokolle genau benutzt werden , wer sich wie anmeldet, wie welche Konfigurationsdateien genutzt werden und wer mit welchen Benutzerkennungen welche Prozesse startet. Habe jedoch selbst kein amanda auf den Rechnern.

Unter welcher UID und GID läuft denn auf dem entsprechenden Client der Dienst ? Und gibt es dort in der Datei /etc/group nur eine Gruppe die amanda heißt oder nicht aus unerklärlichem Grund 2 solcher Einträge?


robi
 
A

Anonymous

Gast
als nächstes würde ich folgendes versuchen
runtar die Zugriffsrechte rwxr-rx-r geben.
damit eine Sicherung eines Filesystems starten das jeder lesen darf (eventuell /usr/share)
und gleichzeitig nachschauen mit welcher UID und GID der Prozess auf dem Client läuft.

robi
 
OP
W

wshbg

Newbie
Moin,
ich habe noch einen Tipp ausserhalb des Forums bekommen und habe das Programm amandad durch ein shellscript ersetzt. Das sagt mir, dass amandad mit user=amanda und group=disk läuft. Das erklärt den Fehler. Schliesst sich die nächste Frage an: wieso macht der xinetd nicht das, was ich konfiguriert habe, erwarte.... nämlich

Code: 
# description: Amanda backup client
service amanda
{
        socket_type     = dgram
        protocol        = udp
        wait            = yes
        user            = amanda
        group           = amanda
        groups          = yes
        disable         = no     
        server          = /usr/lib/amanda/amandad
}
Nb: Der xinetd ist immer noch der "alte", wurde derweil nicht aktualisiert.
Ich will mein CP/M plus wiederhaben. Oh, jetzt habe ich mich geoutet ;-)
Wilfried
 
A

Anonymous

Gast
um das nachvollziehen zu können, müsste man entweder das Ganze tracen oder zumindestens das mal auf dem Rechner selbst vor sich haben . Eventuell hilft die Auswertung der Prozessliste weiter, um zu sehen wer da wen startet. disk als Gruppe scheint mir aber sehr seltsam, haben bei mir nur Geräteknoten. Dann könnte das ganze funktionieren wenn du deinem User amanda noch zusätlich in die Gruppe disk aufnimmst, ist zwar auch nicht schön aber zumindestens währe es sicherer als jedermann das Ausführen von runtar zu erlauben.

Ist alles von hier aus schlecht einzuschätzen. Für die Aktivitäten von xinetd wird normalerweise eine Logfile geführt, eventuell stehen diesbezügliche Hinweise drin. Schau mal unter /var/log/xinetd.log ob du dort was findest. Befürchte aber, mit dem default log-Optionen werden solche "Kleinigkeiten" nicht mitgeschrieben sondern nur allgemeine Start - Stop und Netzwerkaktivitäten.

robi
 
OP
W

wshbg

Newbie
Moin,
es hat überhaupt nichts mit amanda zu tun, es war der xinetd.
Im Verzeichnis /etc/xinetd.d habe ich zwecks Fehlersuche die alte Datei amanda nach amanda_save umbenannt. Ausserdem gab es noch eine Datei amanda.rpmnew, habe aber mit einer neuen Datei amanda experimentiert.
xinetd liest aber offensichtlich alle Dateien und kumuliert die Inhalte (?). Dadurch wurde der service amanda 2x oder auch 3x definiert, der letzte Eintrag gilt und definierte group=disk, denn der Dateiname spielt keine Rolle, nur die Definitionen in der Datei .-(
Ausserdem muss man dran denken, mit kill -HUP <xinetd.pid> die Konfiguration neu zu lesen, aber das ist eher selbstverständlich.
SuSE hinterlässt nach einem update oft Dateien, die dann als xyz.rpmnew oder ähnlich rumliegen, m.E. eine potentielle Fehlerquelle in diesem Verzeichnis.
Danke für Eure Bemühungen, Wilfried
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben