Estoy usando nohup para iniciar matlab y ejecutar un script que requiere leer y escribir algunos archivos determinados.
nohup matlab -nojvm -nodisplay -r 'MyScript'&
Esto funciona sin problemas mientras estoy conectado, pero tan pronto como cierro la sesión y vuelvo a iniciarla veo que mi proceso de Matlab ya no se está ejecutando. Después de verificar el archivo nohup.out encuentro el siguiente mensaje de error:
Unable to write file $HOME/matlab/my_mat_file.mat: permission denied
Parece que tan pronto como cierro la sesión, el propietario del proceso de matlab cambia y ya no tiene acceso a mis archivos. ¿Cómo puedo evitar que ocurra este error sin cambiar los permisos del archivo, por ejemplo, otorgando permisos de escritura a todos?
Este mensaje de error aparece también mientras se usa la pantalla GNU. Si ejecuto ls -al $HOMEdentro de mi sesión de pantalla GNU antes de cerrar sesión, tendré
Me separo de la sesión de pantalla GNU, salgo, inicio sesión y me vuelvo a conectar a la sesión de pantalla solo para descubrir que perdí el acceso a los archivos a los que solía tener acceso dentro de la pantalla. La salida de ls -al $HOMEes ahora
Interesante, ¿no?
Respuesta1
Tiene que ver con la autenticación.
Comenzaré con algunos conceptos sobre tickets y tokens y cómo los usa el sistema de autenticación Kerberos y AFS. Al final, la respuesta a mi pregunta será clara: no puedo escribir en el archivo simplemente porque mi token AFS se eliminó al cerrar sesión. Dicho esto, la solución a mi problema fue incluir en el script de Matlab algunas líneas que determinan si el token existe o no, creándolo en caso de que no exista. Cómo se ha hecho esto concluye exactamente la respuesta.
Autenticación
Proporcionar un sistema de archivos distribuido, accesible desde cualquier lugar, implica un sistema de seguridad sólido. Es por eso que AFS tiene un sólido sistema de autenticación, integrado con el sistema de autenticación Kerberos.
La autenticación en AFS se resuelve mediante un token. Los tokens otorgan a los usuarios acceso a los datos durante su vida. En muchos casos, el manejo de tokens es fluido y no requiere intervención del usuario. Sin embargo, el usuario puede, en cualquier momento, enumerar los tokens emitidos a su nombre utilizandotokens
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--
Los tokens AFS se obtienen a partir de un ticket identificador de Kerberos. De manera similar a los tokens, los tickets Kerberos también identifican al usuario. Mientras utiliza el sistema de autenticación Kerberos, el KDC (Centro de distribución de claves) emite al usuario un ticket inicial llamado ticket de concesión de tickets. Este primer ticket identifica de forma única al usuario y le permite obtener tickets específicos necesarios para servicios adicionales como los tokens AFS. De hecho, puede utilizar directamente el ticket Kerberos para que el servicio AFS tenga el token de identificación AFS.
En la mayoría de los casos, el ticket de concesión de tickets de Kerberos se obtiene automáticamente durante el inicio de sesión del usuario. Lo mismo sucede con el token inicial de AFS. Al igual que los tokens, el manejo de tickets de Kerberos es en la mayoría de los casos invisible para el usuario, pero puede enumerar los tickets emitidos usandoklist
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 ~ $
la caché de credenciales es la ubicación del archivo donde se encuentran los tickets. El Principal es la identificación del usuario y básicamente resulta de la combinación del nombre de usuario y el dominio de Kerberos. Tenga en cuenta que el dominio Kerberos generalmente se escribe en mayúsculas y distingue entre mayúsculas y minúsculas. A continuación tenemos el listado de billetes emitidos, con sus correspondientes fechas de emisión y caducidad. En este caso, el primer ticket ( krtbg) corresponde al ticket que otorga el ticket en el dominio KERBEROS.REALM.DOMAINmientras que el segundo corresponde al token AFS en la celda afs your.system.domain(que normalmente tiene el mismo nombre que el dominio en el que se puede encontrar). Es posible que aparezcan otros tickets de Kerberos en la lista en caso de que se hayan solicitado.
Renovación de tokens
Cuando un token AFS caduca, el acceso a la cuenta AFS ya no es posible. Los síntomas de que ocurrió un evento de este tipo varían de un sistema operativo a otro; sin embargo, en Unix/Linux generalmente recibe un mensaje de permiso denegado al intentar acceder a sus archivos:
username@machine00 ~ $ ls
ls: .: Permission denied
Cuando un token caduca, debes renovarlo. Una forma sencilla de hacerlo es cerrar sesión y volver a iniciar sesión, ya que, en la mayoría de los casos, la renovación del token se produce automáticamente al iniciar sesión. Pero resulta que a veces cerrar sesión no es una opción, especialmente si estás ejecutando algo y no quieres salir, como es el caso.
Una solución alternativa para la renovación de billetes es utilizar kinity aklog, en secuencia. El primero de estos comandos ( kinit), que requiere su contraseña, permite la reautenticación del usuario y la renovación del ticket. A continuación, aklogel comando le permite obtener un token AFS del ticket de Kerberos. Observe que kinitintenta obtener un ticket para el principal y el dominio predeterminados. En caso de que estos no estén definidos, o si el usuario está usando un nombre de usuario diferente en el momento de la solicitud del ticket, kinitse debe utilizar como kinit <principal>@<realm>, por ejemplo:
username@machine00 ~ $ kinit [email protected]
[email protected]'s Password:
username@machine00 ~ $
Lo contrario de akloges unlog, que elimina el token AFS. En consecuencia, kdestroyelimina el archivo de tickets, eliminando todos los tickets de Kerberos.
Cómo esto salvó el día y me ayudó a amar a mis amigos y familiares.
Como dije al principio, conocer estos conceptos me ayudó a comprender mejor lo que estaba sucediendo con mi sesión de matlab. Después de cerrar sesión, mi token AFS ya no estaba allí y mis procesos en ejecución ya no tenían permiso para escribir en mi volumen afs. Dado que, por el momento, solo estoy interesado en garantizar que mi script matlab siga ejecutándose leyendo y escribiendo archivos incluso después de cerrar sesión, tuve cuidado de incluir una prueba en el token AFS antes de cualquier acceso al volumen AFS.
ticket_status = unix('klist -s');
if ticket_status ~= 0,
unix 'kinit [email protected] <<< "password"';
unix aklog
end
Como dije, esto va en el script de matlab y lo he colocado justo antes de savelos loadcomandos de matlab. El código utiliza el comando matlab unixpara ejecutar sus argumentos en un shell Unix y devolver los resultados. El comando Unix klist -sse ejecuta klistsilenciosamente pero devuelve su estado de salida. Probamos el estado de salida de las credenciales y solicitamos nuevas en caso de que no existan o hayan caducado.