Discussion:
comandos y sistema de colas
Gonzalo Aguirre
2012-02-20 11:58:17 UTC
Permalink
Hola colisteros/as,
 estoy administrando un pequeño cluster y para ellos puse un sistema
de colas (SGE) a idea es que a través de un script se larga la
ejecución al gestor del sistema y él ya ve según la carga dónde es
mejor largar la ejecución.

 Una de las ideas es que ciertos comandos que hasta ahora se accedían
de forma directa, dejen de hacerlo y sólo se pueda acceder a través
del sistema de colas, ya que ejecutarlo directamente sería básicamente
como colarse :). Los usuarios si bien no tienen experiencia en linux y
podría simplemente eliminar el directorio del PATH y en el script
tener el path absoluto pero me parece una solución bastante pobre.

 No sé si me explico bien en mi pedido. Pongo el ejemplo, hasta ahora
todo el mundo puede ejecutar el comando, supongamos `echo'
directamente. Con el sistema de colas hay que hacer un script
(script.sge):

--- script.sge ---
#!/bin/sh

#$ -argumento 1 para SGE
#$ -argumento 2 para SGE

/bin/echo "hola hola"
--- script.sge ---

y depsués largarlo con el gestor

$ qsub ./script.sge


pero si algún usuario se le ocurre hacer un:

$ echo "hola hola"

que no tenga acceso.

Gracias de antemano!

PD: es un

-- forward que antes la había mandado a lug-devel, perdón.
GA
MAbeeTT
2012-02-20 13:12:25 UTC
Permalink
Post by Gonzalo Aguirre
Hola colisteros/as,
 estoy administrando un pequeño cluster y para ellos puse un sistema
de colas (SGE) a idea es que a través de un script se larga la
ejecución al gestor del sistema y él ya ve según la carga dónde es
mejor largar la ejecución.
 Una de las ideas es que ciertos comandos que hasta ahora se accedían
de forma directa, dejen de hacerlo y sólo se pueda acceder a través
del sistema de colas, ya que ejecutarlo directamente sería básicamente
como colarse :). Los usuarios si bien no tienen experiencia en linux y
podría simplemente eliminar el directorio del PATH y en el script
tener el path absoluto pero me parece una solución bastante pobre.
 No sé si me explico bien en mi pedido. Pongo el ejemplo, hasta ahora
todo el mundo puede ejecutar el comando, supongamos `echo'
directamente. Con el sistema de colas hay que hacer un script
--- script.sge ---
#!/bin/sh
#$ -argumento 1 para SGE
#$ -argumento 2 para SGE
/bin/echo "hola hola"
--- script.sge ---
y depsués largarlo con el gestor
$ qsub ./script.sge
$ echo "hola hola"
que no tenga acceso.
Gracias de antemano!
No sé qué es SGE, pero si querés que los usuarios no usen el shell
regular (que es usualmente bash, o dash para los debians-ubuntus)
alcanza con que le asignés al usuario un programa distinto, que
inclusive podría ser un script. Eso está configurado en el archivo
/etc/passwd y se puede cambiar con el comando adduser ( y
probablemente otros).

Este programa que cargarías como shell del usuario "capturaría" los
comandos, me refiero a que sería otro shell que invocaría a SGE (o lo
que sea) en vez de hacer la llamada de sistema con un fork. Es
probable que ese programa ya lo haya inventado alguien si estás
trabajado en un escenario no extremadamente único. Así todo lo que
ejecuten quedará encolado.

Otra manera es usar un shell que limite funcionalidades para que no
puedan ejecutar tareas que consumen recursos que deberían ir al
cluster. Lo que se me viene a la mente (sin ser un entendido) es
darles de shell un busybox que excluya el conjunto de funcionalidades
en cuestión.

En todo caso otro script que invoque a qsub vuelve a problar la
variable $PATH. Aunque tené presente que si el usuario es entendido
podría cargarla por sí solo.


Bueno, contanos tus avances y por favor danos una introducción o brief
de lo que es SG
--
             .::MAbeeTT::.

 mabeett [at] gmail [ dot] com
Gonzalo Aguirre
2012-02-20 16:52:46 UTC
Permalink
Post by MAbeeTT
No sé qué es SGE, pero si querés que los usuarios no usen el shell
regular (que es usualmente bash, o dash para los debians-ubuntus)
alcanza con que le asignés al usuario un programa distinto, que
inclusive podría ser un script. Eso está configurado en el archivo
/etc/passwd y se puede cambiar con el comando adduser ( y
probablemente otros).
SGE: Sun Grid Engine (ahora Oracle Grid Engine) es una sistema para
gestionar colas de ejecución de un cluster [0].

Como comentaba en el mail anterior la idea es hacer que todos los
usuarios pasen por el sistema de colas y que no puedan hacer
ejecuciones directamente en el cluster.
Post by MAbeeTT
Este programa que cargarías como shell del usuario "capturaría" los
comandos, me refiero a que sería otro shell que invocaría a SGE (o lo
que sea) en vez de hacer la llamada de sistema con un fork. Es
probable que ese programa ya lo haya inventado alguien si estás
trabajado en un escenario no extremadamente único. Así todo lo que
ejecuten quedará encolado.
Las tareas que se mandan al cluster son siempre las mismas, sólo
varían los cálculos que se hacen, pero es siempre el mismo programa,
estaría bien tener un shell específco que los mande directamente al
sistema de colas.
Post by MAbeeTT
Otra manera es usar un shell que limite funcionalidades para que no
puedan ejecutar tareas que consumen recursos que deberían ir al
cluster. Lo que se me viene a la mente (sin ser un entendido) es
darles de shell un busybox que excluya el conjunto de funcionalidades
en cuestión.
Voy a informarme un poco sobre busybox, porque tiene pinta de ser lo
que estoy buscando.


Gracias por la respuesta!


[0] http://en.wikipedia.org/wiki/Oracle_Grid_Engine
--
GA
Alejandro Vargas
2012-02-23 09:41:23 UTC
Permalink
El 20 de febrero de 2012 17:52, Gonzalo Aguirre
Post by Gonzalo Aguirre
Las tareas que se mandan al cluster son siempre las mismas, sólo
varían los cálculos que se hacen, pero es siempre el mismo programa,
estaría bien tener un shell específco que los mande directamente al
sistema de colas.
Entonces podés hacerles un sencillo menú en shell-script. Que elijan
la opción y listo, sin salida al shell normal. Para que no lo
interrumpan con control+c le ponés un trap "" 123 al principio.


--

Qapla'
Alejandro Vargas
Gonzalo Aguirre
2012-02-27 19:14:27 UTC
Permalink
Post by Alejandro Vargas
El 20 de febrero de 2012 17:52, Gonzalo Aguirre
Post by Gonzalo Aguirre
Las tareas que se mandan al cluster son siempre las mismas, sólo
varían los cálculos que se hacen, pero es siempre el mismo programa,
estaría bien tener un shell específco que los mande directamente al
sistema de colas.
Entonces podés hacerles un seo que sólo sencillo menú en shell-script. Que elijan
la opción y listo, sin salida al shell normal. Para que no lo
interrumpan con control+c le ponés un trap "" 123 al principio.
Hola,
estoy intentando buscar la solución por el lado del bit suid, pero
me estoy perdiendo alguna parte, la idea es poder darle a un archivo
que solo sea accesible desde root.

$ ls -l datos.txt
-rw------- 1 root root 6 Feb 27 19:23 datos.txt

para poder consultarlo hice un binario `prueba' (había hecho un script
pero leí por ahí que no se puede activar el suid en los scripts) para
poder acceder a `datos.txt', activé el suid y gid `chmod 6755 prueba',

$ ls -l prueba
-rwsr-sr-x 1 root root 7588 Feb 27 19:47 prueba

ejecuto como root y tengo

$ sudo ./prueba
UID GID
Real 0 Real 0
Effective 0 Effective 0
datos

ejecuto como un usuario

$ ./prueba
UID GID
Real 1000 Real 100
Effective 0 Effective 0
cat: datos.txt: Permission denied

Me fijé en las opciones de montaje por si tenía nosuid, pero está todo
correcto. Me fijé si archlinux en particular tiene algún tipo de
restricción y no encontré nada. Alguien sabe qué más puedo mirar?

Gracias!
--
GA
Alejandro Vargas
2012-02-28 12:59:52 UTC
Permalink
Post by Gonzalo Aguirre
ejecuto como un usuario
$ ./prueba
UID GID
Real 1000 Real 100
Effective 0 Effective 0
cat: datos.txt: Permission denied
A ver... te paso un programa que a mi me funciona correctamente. Lo que
hace es ejecutar un shell script pero con su (en este caso el shell script
se llama "/usr/lib/arduino/arduino_anv" pero lo podés cambiar por otra cosa
o en lugar del execlp hacer lo que te haga falta (como leer un archivo).
Este programa estoy seguro de que funciona porque yo lo estoy usando.

OJO, este programa sólo cambia de grupo, pero podés agregar un
setreuid(geteuid(),geteuid());

#include
<stdio.h>

#include
<unistd.h>



main()
{


setregid(getegid(),getegid());

printf("Executing... getuid=%d geteuid=%d\n, getgid=%d getegid=%d\n,",
getuid(), geteuid(), getgid(), getegid());
execlp("/usr/lib/arduino/arduino_anv", "",
NULL);

printf("Exec
failed\n");

}
--
Qapla'
Alejandro Vargas
Gonzalo Aguirre
2012-02-28 14:08:33 UTC
Permalink
Post by Alejandro Vargas
Post by Gonzalo Aguirre
ejecuto como un usuario
$ ./prueba
        UID           GID
Real      1000  Real      100
Effective 0  Effective 0
cat: datos.txt: Permission denied
A ver... te paso un programa que a mi me funciona correctamente. Lo que
hace es ejecutar un shell script pero con su (en este caso el shell script
se llama "/usr/lib/arduino/arduino_anv" pero lo podés cambiar por otra cosa
o en lugar del execlp hacer lo que te haga falta (como leer un archivo).
Este programa estoy seguro de que funciona porque yo lo estoy usando.
OJO, este programa sólo cambia de grupo, pero podés agregar un
setreuid(geteuid(),geteuid());
#include
<stdio.h>
#include
<unistd.h>
main()
{
setregid(getegid(),getegid());
   printf("Executing... getuid=%d geteuid=%d\n, getgid=%d getegid=%d\n,",
getuid(), geteuid(), getgid(), getegid());
   execlp("/usr/lib/arduino/arduino_anv", "",
NULL);
   printf("Exec
failed\n");
}
Grande ANV!!.. funcionó, se ve que le gusta más la función exec() que system()

Gracias!
--
GA
Alejandro Vargas
2012-02-28 14:48:55 UTC
Permalink
El 28 de febrero de 2012 15:08, Gonzalo Aguirre
Post by Gonzalo Aguirre
Post by Alejandro Vargas
   execlp("/usr/lib/arduino/arduino_anv", "",
Grande ANV!!.. funcionó, se ve que le gusta más la función exec() que system()
El exec corre el nuevo programa en lugar del actual, o sea que incluso
mantiene el mismo process-id y seguramente los atributos. El system
abre un shell hijo y le pasa los parámetros.


--

Qapla'
Alejandro Vargas

Continúe leyendo en narkive:
Loading...