Diese Website existiert nur weil wir Werbung mit AdSense ausliefern.
Bitte den AdBlocker daher auf dieser Website ausschalten! Danke.

[gelöst] openSUSE 11.2 + amanda

Alles rund um die Systemverwaltung, die Administration und Konfiguration Eures Linuxsystems

Moderator: Moderatoren

Antworten
wshbg
Newbie
Newbie
Beiträge: 9
Registriert: 12. Feb 2010, 15:28
Wohnort: Hamburg

[gelöst] openSUSE 11.2 + amanda

Beitrag von wshbg »

Moin,
zuerst das outing: dies ist ein crossposting. Die gleiche Frage bei http://forums.opensuse.org/applications ... ost2115482 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: Alles auswählen

 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: Alles auswählen

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
Zuletzt geändert von wshbg am 3. Mär 2010, 19:23, insgesamt 1-mal geändert.
wshbg
Newbie
Newbie
Beiträge: 9
Registriert: 12. Feb 2010, 15:28
Wohnort: Hamburg

Re: openSUSE 11.2 + amanda

Beitrag von wshbg »

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
Benutzeravatar
framp
Moderator
Moderator
Beiträge: 4317
Registriert: 6. Jun 2004, 20:57
Wohnort: bei Stuttgart
Kontaktdaten:

Re: openSUSE 11.2 + amanda

Beitrag von framp »

wshbg hat geschrieben:...und ich suche immer mal wieder, bisher ohne Erfolg.
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.
Benutzeravatar
robi
Moderator
Moderator
Beiträge: 3178
Registriert: 25. Aug 2004, 02:13

Re: openSUSE 11.2 + amanda

Beitrag von robi »

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
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: Alles auswählen

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
wshbg
Newbie
Newbie
Beiträge: 9
Registriert: 12. Feb 2010, 15:28
Wohnort: Hamburg

Re: openSUSE 11.2 + amanda

Beitrag von wshbg »

robi hat geschrieben:Ich würde mal vermuten das ist ein Rechteproblem das auf unterschiedliche GruppenIDs auf unterschiedlichen Rechnern beruht.
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: Alles auswählen

-rwsr-x--- 1 root amanda 9884 21. Jan 00:46 /usr/lib/amand/runtar
mit den Rechten

Code: Alles auswählen

-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
Benutzeravatar
robi
Moderator
Moderator
Beiträge: 3178
Registriert: 25. Aug 2004, 02:13

Re: openSUSE 11.2 + amanda

Beitrag von robi »

Code: Alles auswählen

-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
wshbg
Newbie
Newbie
Beiträge: 9
Registriert: 12. Feb 2010, 15:28
Wohnort: Hamburg

Re: openSUSE 11.2 + amanda

Beitrag von wshbg »

robi hat geschrieben:Kann nicht der Lösung letzter Schluss sein.
Nein, ganz sicher nicht.
amanda UID 37, amanda GID 115 ..und jeweils nur ein einziger Eintrag (wie es sich gehört)
Wilfried
Benutzeravatar
robi
Moderator
Moderator
Beiträge: 3178
Registriert: 25. Aug 2004, 02:13

Re: openSUSE 11.2 + amanda

Beitrag von robi »

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
wshbg
Newbie
Newbie
Beiträge: 9
Registriert: 12. Feb 2010, 15:28
Wohnort: Hamburg

Re: openSUSE 11.2 + amanda

Beitrag von wshbg »

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: Alles auswählen

# 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
Benutzeravatar
robi
Moderator
Moderator
Beiträge: 3178
Registriert: 25. Aug 2004, 02:13

Re: openSUSE 11.2 + amanda

Beitrag von robi »

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
wshbg
Newbie
Newbie
Beiträge: 9
Registriert: 12. Feb 2010, 15:28
Wohnort: Hamburg

Re: openSUSE 11.2 + amanda

Beitrag von wshbg »

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
Antworten