Warum kann ein mit nohup gestarteter Befehl nach der Benutzerabmeldung keine Datei schreiben?

Warum kann ein mit nohup gestarteter Befehl nach der Benutzerabmeldung keine Datei schreiben?

Ich verwende nohup, um Matlab zu starten und ein Skript auszuführen, das bestimmte Dateien lesen und schreiben muss.

nohup matlab -nojvm -nodisplay -r 'MyScript'&

Dies läuft reibungslos, während ich angemeldet bin, aber sobald ich mich ab- und wieder anmelde, sehe ich, dass mein Matlab-Prozess nicht mehr läuft. Nach der Überprüfung der Datei nohup.out finde ich die folgende Fehlermeldung:

Unable to write file $HOME/matlab/my_mat_file.mat: permission denied

Es scheint, dass sich der Besitzer des Matlab-Prozesses ändert, sobald ich mich abmelde, und er keinen Zugriff mehr auf meine Dateien hat. Wie kann ich verhindern, dass dieser Fehler auftritt, ohne die Dateiberechtigungen zu ändern, z. B. indem ich jedem Schreibberechtigungen gewähre?

Diese Fehlermeldung erscheint auch bei der Verwendung von GNU-Screen. Wenn ich ls -al $HOMEvor dem Abmelden in meiner GNU-Screen-Sitzung laufe, habe ich

Befehl vor dem Abmelden

Ich trenne mich von der GNU-Screen-Sitzung, melde mich ab, melde mich wieder an und stelle die Verbindung zur Screen-Sitzung wieder her, nur um festzustellen, dass ich den Zugriff auf Dateien verloren habe, auf die ich in Screen Zugriff hatte. Die Ausgabe von ls -al $HOMElautet jetzt

Befehl nach dem Abmelden

Faszinierend, nicht wahr?

Antwort1

Es hat mit Authentifizierung zu tun.

Ich beginne mit einigen Konzepten zu Tickets und Token und wie diese vom Kerberos-Authentifizierungssystem und AFS verwendet werden. Am Ende wird die Antwort auf meine Frage klar sein: Ich darf nicht in die Datei schreiben, einfach weil mein AFS-Token beim Abmelden entfernt wurde. Die Lösung für mein Problem bestand jedoch darin, in das Matlab-Skript einige Zeilen aufzunehmen, die feststellen, ob das Token existiert, oder es nicht erstellen, falls dies nicht der Fall ist. Wie dies genau gemacht wurde, ist der Schluss der Antwort.

Authentifizierung

Die Bereitstellung eines verteilten Dateisystems, auf das von überall aus zugegriffen werden kann, erfordert ein robustes Sicherheitssystem. Aus diesem Grund verfügt AFS über ein starkes Authentifizierungssystem, das in das Kerberos-Authentifizierungssystem integriert ist.

Die Authentifizierung in AFS erfolgt über ein Token. Token gewähren Benutzern während ihrer Lebensdauer Zugriff auf die Daten. In vielen Fällen erfolgt die Token-Verarbeitung nahtlos und erfordert kein Eingreifen des Benutzers. Der Benutzer kann jedoch jederzeit die in seinem Namen ausgestellten Token auflisten, indem ertokens

username@machine00 ~ $ tokens

Tokens held by the Cache Manager:

User's (AFS ID xxxxx) tokens for [email protected] [Expires Mar 20 05:10]
   --End of list--

AFS-Token werden aus einem Kerberos-Identifikationsticket bezogen. Ähnlich wie Token identifizieren auch Kerberos-Tickets den Benutzer. Bei Verwendung des Kerberos-Authentifizierungssystems erhält der Benutzer vom KDC (Key Distribution Center) ein erstes Ticket, das als Ticket-Granting-Ticket bezeichnet wird. Dieses erste Ticket identifiziert den Benutzer eindeutig und ermöglicht ihm, bestimmte Tickets zu erhalten, die für weitere Dienste wie die AFS-Token erforderlich sind. Tatsächlich können Sie das Kerberos-Ticket direkt für den AFS-Dienst verwenden, der über das AFS-Identifikationstoken verfügt.

In den meisten Fällen wird das Ticket-Granting-Ticket von Kerberos automatisch bei der Benutzeranmeldung abgerufen. Dasselbe passiert mit dem AFS-Anfangstoken. Wie bei Token ist die Handhabung von Kerberos-Tickets in den meisten Fällen für den Benutzer unsichtbar, aber Sie können die ausgestellten Tickets auflisten mitklist

username@machine00 ~ $ klist
Credentials cache: FILE:/tmp/krb5cc_V16088
        Principal: [email protected]

  Issued           Expires          Principal                 
Mar 19 19:10:11  Mar 20 05:10:11  krbtgt/[email protected]
Mar 19 19:10:11  Mar 20 05:10:11  afs/[email protected]   
username@machine00 ~ $

Der Credentials-Cache ist der Speicherort der Datei, in der Tickets gefunden werden. Der Principal ist die Benutzer-ID und ergibt sich im Wesentlichen aus der Kombination von Benutzername und Kerberos-Realm-Domäne. Beachten Sie, dass der Kerberos-Realm im Allgemeinen in Großbuchstaben angegeben wird und zwischen Groß- und Kleinschreibung unterscheidet. Nachfolgend finden Sie die Liste der ausgestellten Tickets mit den entsprechenden Ausstellungs- und Ablaufdaten. In diesem Fall krtbgentspricht das erste Ticket ( ) dem Ticket-Granting-Ticket im Realm, KERBEROS.REALM.DOMAINwährend das zweite dem AFS-Token in der AFS-Zelle entspricht your.system.domain(das normalerweise denselben Namen hat wie die Domäne, in der es gefunden werden kann). Andere Kerberos-Tickets können in der Liste angezeigt werden, falls sie angefordert wurden.

Token-Erneuerung

Wenn ein AFS-Token abläuft, ist der Zugriff auf das AFS-Konto nicht mehr möglich. Die Symptome eines solchen Ereignisses variieren von Betriebssystem zu Betriebssystem. Unter Unix/Linux erhalten Sie jedoch normalerweise die Meldung „Zugriff verweigert“, wenn Sie versuchen, auf Ihre Dateien zuzugreifen:

username@machine00 ~ $ ls
ls: .: Permission denied

Wenn ein Token abläuft, müssen Sie es erneuern. Eine einfache Möglichkeit hierfür besteht darin, sich abzumelden und erneut anzumelden, da die Token-Erneuerung in den meisten Fällen automatisch bei der Anmeldung erfolgt. Manchmal stellt sich jedoch heraus, dass die Abmeldung keine Option ist, insbesondere wenn Sie etwas ausführen, das Sie nicht beenden möchten, was der Fall ist.

Eine alternative Lösung für die Ticketerneuerung ist die Verwendung von kinitund aklogin der Reihenfolge. Der erste dieser Befehle ( kinit), der Ihr Passwort erfordert, ermöglicht die erneute Authentifizierung des Benutzers und die Ticketerneuerung. Als nächstes aklogkönnen Sie mit dem Befehl ein AFS-Token vom Kerberos-Ticket abrufen. Beachten Sie, dass kinitversucht wird, ein Ticket für den Standardprinzipal und -bereich abzurufen. Falls diese nicht definiert sind oder der Benutzer zum Zeitpunkt der Ticketanforderung einen anderen Benutzernamen verwendet, kinitsollte als verwendet werden kinit <principal>@<realm>, zum Beispiel:

username@machine00 ~ $ kinit [email protected]
[email protected]'s Password: 
username@machine00 ~ $

Das Gegenteil von aklogist unlog, wodurch das AFS-Token gelöscht wird. Entsprechend kdestroywird die Ticketdatei entfernt, wodurch alle Kerberos-Tickets gelöscht werden.

Wie es den Tag gerettet und mir geholfen hat, meine Freunde und Familie zu lieben

Wie eingangs erwähnt, half mir das Wissen um diese Konzepte, besser zu verstehen, was mit meiner Matlab-Sitzung passierte. Nach dem Abmelden war mein AFS-Token nicht mehr da und meine laufenden Prozesse hatten keine Berechtigung mehr, in mein AFS-Volume zu schreiben. Da ich im Moment nur sicherstellen möchte, dass mein Matlab-Skript auch nach dem Abmelden weiterhin Dateien liest und schreibt, habe ich vor jedem Zugriff auf das AFS-Volume sorgfältig einen Test des AFS-Tokens durchgeführt.

ticket_status = unix('klist -s');
if ticket_status ~= 0,
   unix 'kinit [email protected] <<< "password"';
   unix  aklog
end

Wie gesagt, dies geht in das Matlab-Skript und ich habe es direkt vor alle Matlab-Befehle gesetzt save. loadDer Code verwendet Matlab-Befehle, unixum seine Argumente auf einer Unix-Shell auszuführen und die Ergebnisse zurückzugeben. Der Unix-Befehl wird im Hintergrund klist -sausgeführt klist, gibt aber seinen Beendigungsstatus zurück. Wir testen den Beendigungsstatus für Anmeldeinformationen und fordern neue an, falls diese nicht vorhanden oder abgelaufen sind.

verwandte Informationen