Para solicitar una cuenta de acceso, diríjase al formulario Solicitud de usuario

El acceso al sistema se realiza mediante un nodo central interactivo: dirac.df.uba.ar. Los usuarios con cuentas del DF/IFIBA/INFIP habilitados tienen acceso desde la red del DF: esto incluye el acceso tanto desde login.df.uba.ar como a través de la VPN, siempre mediante el protocolo SSH y permiten el uso de los intérpretes más comunes (por ej., bash).

Si en lugar de usuario y password utilizás ssh key, podés copiar tu llave (key) en dirac de la siguiente manera desde tu computadora:

roberto@odisea2 ~ ssh-copy-id -i .ssh/id_rsa.pub radhios@dirac

Los usuarios externos sólo tienen acceso mediante clave de acceso ssh.

Las sesiones de shell abiertas en el sistema se cancelan tras 8 horas de inactividad. Podés utilizar terminales como tmux y screen para mantener indefinidamente sesiones conectadas.

El acceso al servicio está controlado mediante mecanismos de autenticación: usuario y password del DF.

Dirac dispone de un sistema de configuración de entorno de compilación/ejecución denominado Modules. Mediante la carga de los Modules adecuados es posible personalizar de forma dinámica el entorno: eligiendo los compiladores, librerías versiones de aplicación, etc. Los Modules disponibles por defecto pueden ser consultados mediante la orden module list que proporcionará un listado organizado en categorías.

[radhios@dirac ~]$ module list
 
Currently Loaded Modules:
  1) autotools   2) prun/1.2   3) gnu7/7.3.0   4) openmpi3/3.1.0   5) ohpc

Si quiero ver todos los módulos disponiblew en el sistema, organizadow por categorías, ejecuto el comando module avail

[radhios@dirac ~]$ module avail 
 
------------------------------------------------------------------------------- /opt/ohpc/pub/moduledeps/gnu7-openmpi3 --------------------------------------------------------------------------------
   adios/1.13.1    hypre/2.14.0    mpiP/3.4.1          netcdf-fortran/4.4.4    phdf5/1.10.2      py2-mpi4py/3.0.0    py3-scipy/1.1.0    scorep/4.0       superlu_dist/5.3.0
   boost/1.67.0    imb/2018.1      mumps/5.1.2         netcdf/4.6.1            pnetcdf/1.9.0     py2-scipy/1.1.0     scalapack/2.0.2    sionlib/1.7.1    tau/2.27.1
   fftw/3.3.7      mfem/3.3.2      netcdf-cxx/4.3.0    petsc/3.9.1             ptscotch/6.0.4    py3-mpi4py/3.0.0    scalasca/2.3.1     slepc/3.9.1      trilinos/12.12.1
 
------------------------------------------------------------------------------------ /opt/ohpc/pub/moduledeps/gnu7 ------------------------------------------------------------------------------------
   R/3.5.0         atlas/3.10.1    hdf5/1.10.2     likwid/4.3.2    mpich/3.2.1     ocr/1.0.1          openmpi3/3.1.0 (L)    plasma/2.8.0        py3-numpy/1.14.3    superlu/5.2.1
   arpack/3.1.3    gsl/2.4         lapack/3.4.2    metis/5.1.0     mvapich2/2.2    openblas/0.2.20    pdtoolkit/3.25        py2-numpy/1.14.3    scotch/6.0.4
 
-------------------------------------------------------------------------------------- /opt/ohpc/pub/modulefiles --------------------------------------------------------------------------------------
   EasyBuild/3.6.1        charliecloud/0.2.4    cmake/3.11.1    gnu7/7.3.0    (L)    llvm5/5.0.1       ohpc       (L)    pmix/2.1.1        singularity/2.5.1
   autotools       (L)    clustershell/1.8      gnu/5.4.0       hwloc/1.11.10        mkl/2018.3.222    papi/5.6.0        prun/1.2   (L)    valgrind/3.13.0
 
----------------------------------------------------------------------------------- /opt/ohpc/pub/apps/modules/all ------------------------------------------------------------------------------------
   Anaconda2/5.1.0    Anaconda3/5.1.0    Java/1.8.0_172    numactl/2.0.11-GCCcore-6.4.0
 
  Where:
   L:  Module is loaded
 
Use "module spider" to find all possible modules.
Use "module keyword key1 key2 ..." to search for all possible modules matching any of the "keys".

Para cargar cualquier Module basta con ejecutar module add <app>/<version>, siendo <app>/<version> el nombre y versión de una aplicación concreta. Usando module load <app> , cargará la versión por defecto de la aplicación <app>. Este comando modificará el entorno (las variables PATH, MANPATH, LD_LIBRARY_PATH…) para permitir el uso correcto de la aplicación indicada. Ej:

[radhios@dirac ~]$ module load py3-scipy/1.1.0 

Para comprobar los Modules cargados basta con ejecutar module list.

[radhios@dirac ~]$ module list
 
Currently Loaded Modules:
  1) autotools   2) prun/1.2   3) gnu7/7.3.0   4) openmpi3/3.1.0   5) ohpc   6) fftw/3.3.7   7) openblas/0.2.20   8) py3-numpy/1.14.3   9) py3-scipy/1.1.0

Aquí vemos que se cargo el modulo py3-scipy/1.1.0 y sus dependencias en forma automática openmpi3/3.1.0 fftw/3.3.7 openblas/0.2.20 py3-numpy/1.14.3

El comando module unload <app> permite descargar el entorno de la aplicación <app>, deshaciendo las modificaciones del entorno. Si se han cargado varios Modules el resto no se verán afectados, salvo los que han sido cargados automaticamente como dependencias del modulo descargado, en ese caso si serán descargados.

[radhios@dirac ~]$ module unload py3-scipy/1.1.0 
 
[radhios@dirac ~]$ module list
 
Currently Loaded Modules:
  1) autotools   2) prun/1.2   3) gnu7/7.3.0   4) openmpi3/3.1.0   5) ohpc

Vemos que el modulo descargado y sus dependencias ya no están.

Puede encontrar más detalles para utilizar python en el cluster en en Uso de python

Los nodos de cómputo en Dirac poseen tres sistemas de archivos separados:

• /home/ es un sistema de archivos nfs4 montado sobre la red Gigabit ethernet interna del cluster, recomendable para guardar el trabajo ya completado, fuentes de código y correr programas si estos no necesitan un acceso frecuente y voluminoso de espacio. El /home es el mismo en cada nodo de cómputo y el nodo central (dirac).
• /scratch es un sistema de archivos paralelo de alta performance (Beegfs) montando sobre la red infiniband DDR. Posee una cuota superior al /home y está recomendado para realizar corridas que demanden un uso más intensivo de disco. /scratch es el mismo en cada nodo de cómputo y en el nodo central (dirac).
• /tmp es un sistema de archivos local en cada nodo de cómputo y separado para cada job. El mismo se borra automáticamente al finalizar el job. Dependiendo el programa utilizado, los archivos temporarios se suelen alojar ahí. Si necesita retener algún archivo creado en /tmp durante la ejecución de un job debe copiarlo a su /home/USER antes de finalizar.

Los sistemas de archivos tienen habilitado el control de uso mediante un sistema de cuotas. Como norma general, las cuotas se establecen a nivel de usuario. El investigador principal responsable del proyecto es el encargado de gestionar de forma apropiada los recursos asignados. Por omisión, todos los usuarios tienen asignada una cuota de 160 GB para el /home/USER del usuario y 4 TB para el scratch /scratch/USER. IMPORTANTE: Tener en cuenta que los archivos de más de 30 días en el disco scratch son borrados automáticamente. Para consultar los límites de cuota asignados se puede ejecutar quota -u <user-id> indicando el identificador de usuario que se desea utilizar.

[radhios@dirac ~]$ id 
uid=1171(radhios) gid=100(users) groups=100(users),1076(compu)
 
[radhios@dirac ~]$ quota -u 1171 -s
Disk quotas for user radhios (uid 1171): 
     Filesystem   space   quota   limit   grace   files   quota   limit   grace
/dev/mapper/centos_161--dhcp-home
                   354M  97657M    191G            2650       0       0        
 
#### O se puede hacer ####
 
[radhios@dirac ~]$ quota -u radhios -s
Disk quotas for user radhios (uid 1171): 
     Filesystem   space   quota   limit   grace   files   quota   limit   grace
/dev/mapper/centos_161--dhcp-home
                   354M  97657M    191G            2650       0       0        

Si un proyecto necesita una capacidad de almacenamiento mayor que la asignada, el jefe del proyecto deberá solicitar dicha ampliación contactando a COMPU, justificando los motivos y la capacidad que se precisa.

El sistema de archivos tanto en /home como en /scratch no cuentan actualmente con copias de seguridad (backup) por lo cual recomendamos mantener una copia propia de todos los archivos de valor en otros dispositivos.

Dirac dispone de diversos servicios de transferencia de ficheros, tanto entre el sistema y los equipos de los usuarios como entre dos o más sitios de la RED. Los métodos de transferencia seguros (SCP y SFTP) están habilitados en todos los nodos interactivos. Estos métodos cifran toda la información que se intercambia entre los dos sitios, y por lo tanto su velocidad depende no solo de la red sino de cipher utilizado, para su mejor performance recomendamos utilizar aes128-ctr.

Un ejemplo básico de uso sería:

• SCP

ComputadorPersonal> scp -c aes128-ctr <origen> <destino>

Copiar desde dirac a nuestro computador personal:

u@local> scp -c aes128-ctr [usuario]@dirac.df.uba.ar:RutaRemota RutaLocal

Copiar desde nuestro computador hacia dirac:

u@local> scp -c aes128-ctr RutaLocal [usuario]@dirac.df.uba.ar:RutaRemota

• SFTP

u@local> sftp -c aes128-ctr [usuario]@dirac.df.uba.ar
sftp> put localfile
sftp> get remotefile 

Para optimizar el uso compartido de los recursos del cluster, los trabajos deben ejecutarse utilizando un administrador y programador de ejecución de trabajos. DIRAC utiliza el administrador SLURM. Este manejador asigna y distribuye los recursos del cluster a los trabajos de los usuarios de manera de satisfacer los requerimientos de CPUs, memoria, nodos y partición (o cola) de cada trabajo.

Existen dos herramientas esenciales para la ejecución de trabajos:

sbatch Este comando envía un script a una cola manejada por SLURM para ser ejecutado en un nodo de cálculo.

srun Este comando ejecuta trabajos en un nodo de cálculo y permite el trabajo interactivo en el nodo. Si es necesario, srun solicitará recursos antes de la ejecución del trabajo.

* ¿Cómo Ejecutar Trabajos Seriales?

Para ejecutar programas seriales interactivos, es decir, que requieran de alguna entrada de parámetros de forma interactiva, ejecute un comando como el que sigue (recuerde que si cierra la sesión el proceso se cancelará):

srun ./programa &> salida &

Este comando ejecuta ./programa en alguno de los nodos del cluster. El argumento &> salida indica que tanto la salida como los errores se almacenan en un archivo de nombre salida que se creará en el mismo directorio desde donde se ejecutó el programa. Finalmente, el último carácter & es para liberar la consola desde donde se lanza la ejecución del programa.

* ¿Cómo Ejecutar Trabajos Seriales Usando un Script Shell?

Para ejecutar programas seriales pasivos utilizando un script shell, que no requieran de alguna entrada de parámetros de forma interactiva, ejecute un comando como el que sigue:

sbatch ./script.sh

Este comando ejecuta ./script.sh en alguno de los nodos del cluster.

* ¿Cómo Ejecutar Trabajos Paralelos con OpenMP? (Memoria Compartida)

Para ejecutar programas paralelos con OpenMP edite un script shell de nombre openmp.sh con el siguiente contenido:

#!/bin/bash
#SBATCH --cpus-per-task=4 # 
 
export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
 
./programa_ejecutable > salida

La línea export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK indica que se utilizarán tantos hilos de ejecución como cpus fueron asignadas por slurm, en el caso de este ejemplo, 4. El valor de esta variable debe fijarse según las necesidades y características de su programa ejecutable (programa_ejecutable). Luego, ejecute siguiente comando:

sbatch ./script.sh

Este comando ejecuta el script ./openmp.sh en alguno de los nodos del cluster.

* ¿Cómo Ejecutar Trabajos Paralelos con OpenMPI? (Memoria Distribuida)

Para ejecutar programas paralelos con OpenMPI edite un script shell, de nombre mpi.sh, con el siguiente contenido:

#!/bin/bash
#SBATCH --partition=batch  #Seleccione los nodos para el trabajo de todos el conjunto de nodos de cómputo del cluster
#SBATCH -o mpi.%j.out  #Nombre del archivo de salida
#SBATCH -J mpiJob  #Nombre del trabajo
#SBATCH --nodes=2  #Numero de nodos para correr el trabajo
#SBATCH --ntasks=20  #Numero de procesos
#SBATCH --tasks-per-node=10  #Numero de tareas por nodo
 
#Prepara el ambiente de trabajo
export I_MPI_PMI_LIBRARY=/opt/ohpc/admin/pmix/lib/libpmi.so
ulimit -l unlimited
 
#Ejecuta el programa paralelo con MPI
prun ./programaMPIejecutable

Las líneas que comienzan con la palabra reservada #SBATCH indican las opciones del trabajo paralelo. La opción –partition=batch indica que los nodos necesarios para ejecutar el trabajo se seleccionarán de la partición de nombre batch. La opción –nodes=2 solicita 2 nodos de cómputo para el trabajo, la opción –ntasks=20 indica que se ejecutarán 20 tareas que en el caso de MPI representan los procesos. La opción –ntasks-per-node=10 indica que los 20 procesos se distribuirán de a 10 procesos por nodo. La siguiente línea enlaza la biblioteca con la que se compila OpenMPI para que tenga soporte integrado con SLURM.

export I_MPI_PMI_LIBRARY=/opt/ohpc/admin/pmix/lib/libpmi.so

Finalmente, en la última línea, se especifica el programa ejecutable (programaMPIejecutable). Luego, ejecute siguiente comando:

sbatch ./mpi.sh

Este comando ejecuta el script mpi.sh en el conjunto de los nodos del cluster.

Recuerde que sea para trabajos seriales o paralelos, la memoria de cada nodo es compartida por todos los procesos y no está reservada para un proceso en particular. Sin embargo, es conveniente indicar correctamente la cantidad de memoria a utilizar para que el sistema de colas seleccione un nodo con memoria total suficiente. Para indicar la memoria deberá incluir el tag:

#SBATCH --mem=XXXX

Si Ud. indica una memoria inferior a la necesaria para su programa, aún cuando haya disponible en el nodo, el programa fallará con el mensaje de error OUT_OF_MEMORY en el momento que el programa requiera más memoria que la solicitada. Si Ud. está inseguro del valor exacto que necesita, seleccione un valor de –mem=52G (para nodos normales), o –mem=125G (para nodos de alta memoria, solo 6 disponibles).

Una de la tareas más importantes en la administración de SLURM es conocer el estado de todos los componentes y servicios. Esta sección muestra las herramientas que nos ayudan en la supervisión de SLURM.

Este comando muestra el estado de los distintos nodos. Un ejemplo de la salida es la siguiente:

[radhios@dirac ~]$ sinfo
PARTITION AVAIL  TIMELIMIT  NODES  STATE NODELIST
batch*       up 2-00:00:00      6   idle compute-[0-5]

Además de mostrar la configuración actual de SLURM, este comando es utilizado para modificarla, esto incluye elementos como trabajos (jobs), tareas (job steps), nodos, particiones, reservas, etc. Debe ser ejecutado por root. Si no se le pasan opciones se inicia una línea de comandos desde donde se puede utilizar todas las opciones de forma interactiva. Si se realiza una modificación a la configuración general, se puede escribir la nueva configuración con el comando write (solo root), lo cual generará un nuevo archivo (slurm.conf.fecha) en el directorio de la actual configuración.

[radhios@dirac ~]$ scontrol show nodes compute-0
NodeName=compute-0 Arch=x86_64 CoresPerSocket=8
   CPUAlloc=2 CPUErr=0 CPUTot=32 CPULoad=0.01
   AvailableFeatures=(null)
   ActiveFeatures=(null)
   Gres=(null)
   NodeAddr=compute-0 NodeHostName=compute-0 Version=17.11
   OS=Linux 3.10.0-862.9.1.el7.x86_64 #1 SMP Mon Jul 16 16:29:36 UTC 2018 
   RealMemory=56315 AllocMem=512 FreeMem=62642 Sockets=2 Boards=1
   State=MIXED ThreadsPerCore=2 TmpDisk=131072 Weight=1 Owner=N/A MCS_label=N/A
   Partitions=batch 
   BootTime=2018-07-30T13:04:01 SlurmdStartTime=2018-07-30T13:05:00
   CfgTRES=cpu=32,mem=56315M,billing=32
   AllocTRES=cpu=2,mem=512M
   CapWatts=n/a
   CurrentWatts=0 LowestJoules=0 ConsumedJoules=0
   ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/s

Este comando sirve para mostrar el estado de los trabajos.

[radhios@dirac ~]$ squeue 
             JOBID PARTITION     NAME     USER ST       TIME  NODES NODELIST(REASON)
              1693     batch     bash  capuzzi  R       1:04      1 compute-0

Se puede utilizar una salida con formato para visualizar información específica

[radhios@dirac ~]$ squeue -o "%u   %N      %b"
USER   NODELIST      GRES
capuzzi   compute-0      (null)

Se puede obtener información con formato sobre un trabajo específico

[radhios@dirac ~]$ squeue -n bash -o "%u %N"
USER NODELIST
capuzzi compute-0

Para poder exportar appl gráficas tipo matplotlib o gnuplot o octave tenemos varios métodos a saber:

*Exportar el display via ssh

De esta manera podemos conectarnos a dirac y decirle que cuando se ejecute una aplicación gráfica X exporte el display a la computadora del usuario para que allí sea mostrado.

Ejemplo:

roberto@odisea2 ~ ssh -XY radhios@dirac      
Last login: Tue Jul 31 13:42:19 2018 from odisea.df.uba.ar
 
[radhios@dirac ~]$ module load Anaconda2
 
[radhios@dirac ~]$ python simple_plot.py

Código del ejemplo

import matplotlib.pyplot as plt
import numpy as np
 
t = np.arange(0.0, 2.0, 0.01)
s = 1 + np.sin(2*np.pi*t)
plt.plot(t, s)
 
plt.xlabel('time (s)')
plt.ylabel('voltage (mV)')
plt.title('About as simple as it gets, folks')
plt.grid(True)
plt.savefig("test.png")
plt.show()

Salida:

La otra forma de acceso es via clientes de servidores gráficos. En nuestro caso tenemos instalados dos servicios X2GO y XPRA, a continuación detallamos como se instalan y usan.

Los paquetes para instalar los clientes son x2goclient.x86_64 / xpra-common-client.noarch para CentOS, Fedora y x2goclient / xpra para Debian, Ubuntu. Existen tambien paquetes análogos para Windows y MacOS.

En el caso de XPRA ejecutamos el siguiente comando en nuestra consola

roberto@odisea2 ~ xpra start ssh/radhios@dirac --start-child="xterm -fn 10x20 -ls" --exit-with-children

Este comando nos va a mostrar una consola grafica xterm de dirac en nuestra PC, y si ejecutamos el mismo ejemplo anterior vamos a obtener la siguiente salida:

Documentación XPRA

En el caso de usar X2Go Client ejecutamos la aplicación que instalamos en nuestra PC y procedemos a configurar la sesión:

Vamos Session → New Session se va a cargar una ventana de dialogo en la cual configuramos los datos de conexión y aplicación a ejecutar remoto:

En este caso se configuraron las credenciales del usuario y se configuró la aplicación a ejecutar en dirac, igual que en el ejemplo anterior se usa XTERM

Documentación X2Go

Otro ejemplo que pueden ejecutar es:

import numpy as np
import matplotlib
matplotlib.use("TkAgg")
import matplotlib.pyplot as plt
N = 5
menMeans = (20, 35, 30, 35, 27)
womenMeans = (25, 32, 34, 20, 25)
menStd = (2, 3, 4, 1, 2)
womenStd = (3, 5, 2, 3, 3)
ind = np.arange(N)    # the x locations for the groups
width = 0.35       # the width of the bars: can also be len(x) sequence
 
p1 = plt.bar(ind, menMeans, width, yerr=menStd)
p2 = plt.bar(ind, womenMeans, width,
             bottom=menMeans, yerr=womenStd)
 
plt.ylabel('Scores')
plt.title('Scores by group and gender')
plt.xticks(ind, ('G1', 'G2', 'G3', 'G4', 'G5'))
plt.yticks(np.arange(0, 81, 10))
plt.legend((p1[0], p2[0]), ('Men', 'Women'))
 
plt.savefig("a.png")
plt.show()

Haciendo lo siguiente:

roberto@odisea2 ~ ssh -XY radhios@dirac
Last login: Tue Jul 31 16:49:45 2018 from odisea.df.uba.ar
[radhios@dirac ~]$ module load Anaconda3
[radhios@dirac ~]$ python bar_stacked.py 

La salida será como se ve a continuación:

Este ejemplo se corrió en el nodo central, igual manera se puede hacer en uno de los nodos de calculo:

roberto@odisea2 ~ ssh -XY radhios@dirac
[radhios@dirac ~]$ srun --pty bash # Aqui el SLURM nos asigna un nodo de calculo, en este caso **compute-0**
[radhios@compute-0 ~]$ python bar_stacked.py 

La salida será como en el ejemplo anterior.

Resumen de comandos SLURM

sinfo    -> mostrar información global del cluster
sview    -> mostrar información global del cluster (Grafica, requiere exportar el X de su PC "ssh -XY usuario@dirac.df.uba.ar").
scontrol show job nnnn    -> examinar un job en especial (nnnn = jobid).
scontrol show node nodename    -> examinar un nodo en especial (nodename = compute-0 a compute-6).
sbatch    -> enviar un script ejecutable al sistema de colas.
srun    -> ejecutar un comando como un nuejo job o en uno exitente.
scancel    -> borrar un job.
sacct   -> visualizar el "accounting" del usuario de jobs terminados y en ejecución.

roberto@odisea2 ~ ssh -XY radhios@dirac
Last login: Fri Aug  3 16:18:10 2018 from odisea.df.uba.ar
[radhios@dirac ~]$ sbatch miscript.sh 
Submitted batch job 1827

[radhios@dirac ~]$ sbatch miscript.sh 
Submitted batch job 1826
[radhios@dirac ~]$ sacct
       JobID    JobName  Partition    Account  AllocCPUS      State ExitCode 
------------ ---------- ---------- ---------- ---------- ---------- -------- 
//
\\
1824.extern      extern               default          1  COMPLETED      0:0 
1824.0               ls               default          1  COMPLETED      0:0 
1825               bash      batch    default          1 CANCELLED+      0:0 
1825.extern      extern               default          1  COMPLETED      0:0 
1826         miscript.+      batch    default        128    RUNNING      0:0 
1826.extern      extern               default        128    RUNNING      0:0 

Resumen de comandos de SLURM (CheatSheet): slurm_summary.pdf

Sitio de ayuda para convertir entre sistemas de colas: Convertir de PBS a SLURM

Planilla de conversión de comandos PBS/Torque - Slurm - LSF -SGE - LoadLeveler: rosetta.pdf

(Tomado de https://dokuwiki.ccad.unc.edu.ar)

Para poder acceder al cluster debe contar con un cliente ssh. Casi la totalidad de las distribuciones LINUX ya lo tienen preinstalado. Si éste es su caso pude ejecutar el siguiente comando desde una terminal:

  ssh $USUARIO@dirac.df.uba.ar

En caso que quisiera iniciar lo conexión desde una maquina WINDOWS recomendamos el programa MoabXterm

La variable $USUARIO ha sido comunicada en el mail de confirmación de creación de la cuenta y será su nombre de usuario dentro del cluster.

Para conectarse a la cabecera del cluster no es necesario especificar una password pues la llave SSH pública enviada en la solicitud ha sido copiada en el directorio “home” de $USUARIO.

Haciendo una analogía con el mundo real, podríamos paragonar el mecanismo de conexión al cluster mediante llaves SSH con la puerta de nuestra casa. Este mecanismo se compone de un par de archivos llamados public key y private key. El archivo público (public key) representa la cerradura de la puerta mientras que el archivo privado (private key) es la llave que abre dicha cerradura. Así como es posible poner la misma cerradura a muchas puertas y usar la misma llave para entrar a todas copiando la public key en varios servidores, es también factible poner varias cerraduras en la misma puerta y abrir la misma con diferentes llaves copiando varias public keys en el mismo servidor.

Principios básicos para tener en cuenta:

• la private key debe permanecer siempre bajo custodia de la misma manera que custodiamos la llave de nuestra casa,
• en NINGUN CASO se debe comunicar el contenido de la private key,
• en caso de reinstalación del sistema operativo recordarse de hacer una copia de la private key,
• en caso de pérdida de la private key (por ejemplo luego de la reinstalación del sistema) comunicar a los administradores del cluster la nueva public key,
• un cluster es un sistema de recursos computacionales compartidos, la seguridad del mismo depende en gran medida del uso responsable de los mecanismos de autentificación. En caso de hurto o robo de la private key (o de la computadora en la cual se encuentra almacenada) comunicar intempestivamente el episodio al mail soporte at ccad dot unc dot ar.

Como creo un nuevo par de llaves SSH en Linux?

Puede generar un nuevo par de llaves SSH desde el terminal de un sistema GNU/Linux ejecutando el siguiente comando:

ssh-keygen

Como creo un nuevo par de llaves SSH en Windows?

Para usuarios de Windows se recomienda seguir el siguiente pocedimiento:

1. Descargar Mobaxterm desde la pagina de descarga eligiendo la versión portable.

2. Descomprimir el archivo zip, (si piensa conectarse al cluster desde distintas computadoras descomprima en un USB)

3. Ejecutar el programa Mobaxterm

4. Dentro de la terminal que ofrece el programa lanzar los siguientes comandos: -

  ssh-keygen
  cat .ssh/id_rsa.pub

5. Comunicar la public key a los administradores.

Que significa exactamente comunicar la public key a los administradores?

Las llaves generadas por el comando ssh-keygen se almacenan por defecto en el directorio $HOME/.ssh/ de la maquina desde la que nos queremos conectar. Los ficheros id_rsa e id_rsa.pub contienen respectivamente las llaves privada y pública. Para poder garantizar el acceso al cluster los administradores necesitan el contenido del fichero id_rsa.pub. El mismo se puede obtener gracias al comando cat:

 cat $HOME/.ssh/id_rsa.pub

O bien puede enviar directamente el fichero $HOME/.ssh/id_rsa.pub como pieza adjunta por mail.

Es posible acceder al cluster desde otras terminales diferentes a la que usé para crear la clave pública ssh?

Si, es posible. Para ello existen dos maneras de hacerlo:

1. Copiar la llave privada en todas las terminales, es decir transferir el fichero $HOME/.ssh/id_rsa original a la nueva computadora:

scp $HOME/.ssh/id_rsa usuario@mi.otra.computadora:~/.ssh 

2. Generar un par de llaves en cada computadora y copiar la llave pública en el cluster. Para ello se debe ejecutar el comando ssh-keygen en la computadora nueva, visualizar el contenido de la llave pública, conectarse al cluster a partir de la terminal que se usa habitualmente y copiar el contenido de la llave pública apenas generada en el fichero $HOME/.ssh/authorized_keys que se encuentra en el cluster. Si por alguna razón no puede conectarse al cluster, puede comunicar la la public key a los administradores.

No logro conectarme al cluster con la llave SSH, que puedo hacer antes de contactar el soporte?

1. Asegúrese que los permisos del fichero que contiene la llave privada son correctos ejecutando el siguiente comando:

  chmod 600 $HOME/.ssh/id_rsa

2. Asegúrese que los permisos de la carpeta que contiene la llave privada son correctos ejecutando el siguiente comando:

  chmod 700 $HOME/.ssh

3. Intente conectarse al cluster forzando el uso de la llave privada:

  ssh -i  $HOME/.ssh/id_rsa $USUARIO@dirac.df.uba.ar.ar

4. Si aun así no funciona, pruebe nuevamente con el siguiente comando:

<code bash>  
SSH_AUTH_SOCK=0 ssh -i  $HOME/.ssh/id_rsa $USUARIO@dirac.df.uba.ar

</code>

Si con este comando la conexión funciona, debe simplemente agregar la llave privada al repositorio del agente de autenticación:

  ssh-add

La conexión al cluster funciona forzando el uso de la llave SSH con ssh -i, que puedo hacer antes de contactar el soporte?

Si la conexión funciona forzando la utilización de la llave SSH, significa que el problema no se encuentra en el cluster sino en el cliente. En la mayoría de los casos este problema se soluciona modificando el fichero /etc/ssh/sshd_config presente en el sistema de su PC. Debe buscar en el mismo la directiva IdentityFile y modificarla de la siguiente manera:

IdentityFile ~/.ssh/id_rsa

Intenté todo pero sigue fallando

Es momento de contactar a al soporte, al hacerlo por favor adjunte la salida del comando

  ssh -vvv $USUARIO@dirac.df.uba.ar.ar

Es posible montar localmente el directorio /home/$USUARIO del cluster y de este modo realizar todas las operaciones sobre los archivos (copiar, renombrar, editar, etc.) con las herramientas de preferencia instaladas en su PC de trabajo. Para ello existen diferentes métodos. A continuación presentamos los 3 más utilizados. Todos estos métodos funcionaran únicamente si las llaves SSH están correctamente configuradas.

1. Montaje del directorio con sshfs:

En primer lugar se debe crear en el sistema cliente un repertorio que utilizaremos a continuación como punto de montaje local:

mkdir $HOME/datos_dirac

Luego se realiza el montaje reemplazando la variable $USER por el nombre de usuario asignado en el cluster:

sshfs $USER@dirac.df.uba.ar:/home/$USER $HOME/datos_dirac

Comprobar que el repertorio se ha montado correctamente y que se poseen los permisos para operar en el sistema remoto:

ls $HOME/datos_dirac
touch $HOME/datos_dirac/puedoescribir
rm $HOME/datos_dirac/puedoescribir

Para desmontar el repertorio se utiliza el siguiente comando:

fusermount -u $HOME/datos_dirac

2. Montaje del directorio al arranque:

Es posible configurar el sistema cliente para que monte automáticamente el repertorio home del cluster al arranque. Para ello debemos seguir algunos pasos muy sencillos. En primer lugar asegurarse que el usuario pertenece al grupo fuse o bien que puede acceder en lectura al fichero /etc/fuse.conf. El fichero /etc/fuse.conf debe contener la siguiente instrucción:

user_allow_other

Si no es el caso, editar el fichero con el superusuario root.

Una vez hecho esto, agregar la siguiente linea al fichero /etc/fstab :

$USER@dirac.df.uba.ar:/home/$USER  $MOUNTPOINT fuse.sshfs auto,_netdev,user,idmap=user,transform_symlinks,identityfile=$HOME/.ssh/id_rsa,allow_other,default_permissions, 0 0

El reemplazo de las variables se hará de esta manera:

$USER es el nombre de usuario en el cluster dirac

$MOUNTPOINT es el nombre del repertorio local donde se quieren montar los datos remotos. Debe contener el path absoluto, por ejemplo /home/pepe/datos_dirac

$HOME es el repertorio home del usuario local donde se encuentra la llave SSH privada.

3. Montaje del directorio desde la interfaz gráfica:

Los usuarios de GNOME o KDE pueden si así lo desean montar el repertorio home del cluster directamente a partir de la interfaz gráfica. Los pasos a seguir son realmente sencillos, a saber:

GNOME (Nautilus)

1. Abrir un gestor de archivos

2. Hacer click en Archivo→ <conectarse con el servidor>

3. En el cuadro de dialogo colocar los siguientes parámetros:

servidor: dirac.df.uba.ar
tipo: ssh
carpeta: /home/$USUARIO   (reemplace por el correspondiente)
usuario: $USUARIO
contraseña: <blanco>

si desea crear un atajo para que quede configurada la conexion tildar añadir marcador

BASH basico Toolchain GCC Manual de GIT