Re: cgroup y lxc

2014-12-19 Por tema sio2 
El Tue, 16 de Dec de 2014, a las 03:58:23PM +, Camaleón dijo:

> Bueno, en Debian (y el resto de distribuciones) tienen especial interés 
> en el uso de LXC, así que no me extrañaría que lo corrigieran antes de 
> que salga Jessie, siempre y cuando se trate de un bug y el parche no sea 
> excesivamente intrusivo para que no trastoque nada más.
> 
> Ya nos contarás lo que te vayan diciendo.

Bueno, pues no contestaron nada. Pero no me extraña. Estuve curioseando
y ahora mismo hay al menos tres modos de gestionar los cgroup:

1. La librería libcg (los paquetes de debian libcgroup1 y cgroup-tools)
   pertenecen a ella.
2. cgmanager que desarrolla la gente de lxc.
3. systemd.

La tercera opción creo que aún no está madura para manegar los cgroups
que necesita lxc. Al menos eso es lo que he leído en esta entrada:

https://github.com/lxc/lxc/issues/323

No sé si systemd-218 ha solucionado esto o no, según se puede leer al
final de los comentarios. En cualquier caso en jessie viene systemd-215.

La segunda opción es la que he visto usada para lo que quiero en todas
las guías.

La primera fue la que se me antojó utilizar, porque me permitía más
elegantemente automatizar todo, pero al meterme en su página de
sourceforge he visto que no se ha desarrollado nada desde enero de 2014.
Además he visto que cgrulesengd tiene un problema: se tarda un minúsculo
tiempo entre que se crea el proceso y cgrulengd lo pasa al cgroup que
indican las reglas. Si durante este pequeño tiempo la aplicación en
cuestión lanza un proceso hijo, resulta que este proceso hijo no
pertenecerá al cgroup en donde aún estará el padre y no se mudará con
él.

En fedora 21, por ejemplo, que me bajé para comprobar si me encontraba
con los mismos problemas que en debian, ha desaparecido parcialmente
(aún se puede instalar cgconfigparser, pero no cgrulesengd). Y el futuro
es que desaparezca totalmente en favor de la gestión con systemd.

Total, que me sospecho que el futuro es utilizar bien systemd o, como
alternativa para el systémdfobo, cgmanager.

Como mi intención es montar todo esto en una jessie, voy a tirar por la
calle de enmedio y usaré cgconfigparser para crear un cgroup inicial
(lxc), el script para pam para crear con cgcreate el cgroup de cada
usuario, y "cgexec" para lanzar lxc-start en este cgroup particular de
usuario. Lo último es un tanto engorroso, pero como todo estará incluido
en un script, no se tendrá que hacer manualmente.

Saludos.


-- 
   Dejemos metafísicas quimeras;
vuesas mercedes garlen en chacota:
que no está el mundo para hablar de veras.
  --- Tomé de Burguillos ---


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141219174812.ga6...@cubo.casa

Re: cgroup y lxc

2014-12-16 Por tema Camaleón 
El Mon, 15 Dec 2014 19:13:24 +0100, José Miguel (sio2) escribió:

> El Mon, 15 de Dec de 2014, a las 04:06:45PM +, Camaleón dijo:
> 
>> Pues la verdad es que no :-P pero si no he entendido mal la
>> problemática,
>> te digo lo que probaría...
>> 
>> 1/ Usuarios en lugar de grupos:
>> 
>> perico:lxc-start * lxc/%u pantuflo:lxc-start * lxc/%u
>> 
>> 2/ UID en lugar de nombres:
>> 
>> @lxc:lxc-start * lxc/%U
> 
> En realidad no parece que en ello esté el problema: de hecho, mientras
> uso sleep todo va bien. Es al usar lxc-start cuando se descuajeringa
> todo.
> No parece fallar cuando el criterio es simplemente
> 
> @lxc   *  lxc/%u
> 
> O sea, cualquier proceso que arranque un usuario que pertenezca a lxc,
> sea el que sea.
> 
> Pero no he sido exhaustivo en las pruebas.

(...)

Entonces es posible que se deba al comando en sí mismo ¿que es lo que 
hace "lxc-start" exactamente? ¿necesita algún parámetro o se ejecuta 
directamente? ¿se puede ejecutar dentro de un contenedor lxc...?

>> 3/ No sé si será posible pero sería interesante aumentar la verbosidad
>> del registro para ver por qué no puede crear el contenedor
>> (¿permisos?).
> 
> No, no tiene nada que ver con permisos. Tiene que ver con que
> cgrulesengd deja de hacer su trabajo. Después de enviar el mensaje,
> arranqué el demonio cgrulesengd en primer plano y con el máximo de
> verborrea:
> 
> # cgrulesengd -d
> 
> Se puede ir viendo cómo el demonio analiza los procesos que ejecuto y
> comprueba si concuerdan o no con alguna regla de las escritas en
> /etc/cgrules.conf. Todo marcha bien, hasta que ejecuto "lxc-start": ese
> proceso también sufre "supervisión" y aparentemente sin problemas, pero
> a partir de ese momento, el demonio se queda tonto: arranque lo que
> arranque después, no analiza nada. La consecuencia es que los procesos
> acaban en el cgroup que está el bash en que se ejecutan, o sea, el
> cgroup raíz.
> 
> Tiene pinta de ser un bug. Acabo de hacer una consulta en la lista de
> usuarios de lxc. Como participan los desarrolladores, quizás me puedan
> arrojar luz sobre el asunto. A ver qué saco en claro. Como sea bug, mi
> gozo en un pozo, porque jessie ya está congelada.

(...)

Bueno, en Debian (y el resto de distribuciones) tienen especial interés 
en el uso de LXC, así que no me extrañaría que lo corrigieran antes de 
que salga Jessie, siempre y cuando se trate de un bug y el parche no sea 
excesivamente intrusivo para que no trastoque nada más.

Ya nos contarás lo que te vayan diciendo.

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.12.16.15.58...@gmail.com

Re: cgroup y lxc

2014-12-15 Por tema sio2 
El Mon, 15 de Dec de 2014, a las 04:06:45PM +, Camaleón dijo:

> Pues la verdad es que no :-P pero si no he entendido mal la problemática, 
> te digo lo que probaría...
> 
> 1/ Usuarios en lugar de grupos:
> 
> perico:lxc-start * lxc/%u
> pantuflo:lxc-start * lxc/%u
> 
> 2/ UID en lugar de nombres:
> 
> @lxc:lxc-start * lxc/%U

En realidad no parece que en ello esté el problema: de hecho, mientras uso
sleep todo va bien. Es al usar lxc-start cuando se descuajeringa todo.
No parece fallar cuando el criterio es simplemente

@lxc   *  lxc/%u

O sea, cualquier proceso que arranque un usuario que pertenezca a lxc,
sea el que sea.

Pero no he sido exhaustivo en las pruebas.

> 3/ No sé si será posible pero sería interesante aumentar la verbosidad 
> del registro para ver por qué no puede crear el contenedor (¿permisos?).

No, no tiene nada que ver con permisos. Tiene que ver con que
cgrulesengd deja de hacer su trabajo. Después de enviar el mensaje,
arranqué el demonio cgrulesengd en primer plano y con el máximo de
verborrea:

# cgrulesengd -d

Se puede ir viendo cómo el demonio analiza los procesos que ejecuto y
comprueba si concuerdan o no con alguna regla de las escritas en
/etc/cgrules.conf. Todo marcha bien, hasta que ejecuto "lxc-start": ese
proceso también sufre "supervisión" y aparentemente sin problemas, pero
a partir de ese momento, el demonio se queda tonto: arranque lo que
arranque después, no analiza nada. La consecuencia es que los procesos
acaban en el cgroup que está el bash en que se ejecutan, o sea, el
cgroup raíz.

Tiene pinta de ser un bug. Acabo de hacer una consulta en la lista de
usuarios de lxc. Como participan los desarrolladores, quizás me puedan
arrojar luz sobre el asunto. A ver qué saco en claro. Como sea bug, mi
gozo en un pozo, porque jessie ya está congelada.

Es una pena, porque lo tengo todo preparado: cambié la creación del
cgroup de usuario, y en vez de hacerla en /etc/profile la hago a través
de un script que se ejecuta con pam_exec: al identificarse el usuario,
se crea si no existe, y al abandonar la sesión se destruye, si no tiene
ninguna otra sesión abierta.

Mi idea es montar todo esto en un servidor que a través de ssh (con
ForceCommand y un script adecuado) permita a los alumnos entrar
exclusivamente en contenedores linux: como cada uno tiene un cgroup
independiente puedo limitar la memoria que me consuman con sus linuces
virtuales; y, como todos los contenedores están contenidos dentro de
"lxc", la memoria total que consumen entre todos. Con los ciclos de cpu
puedo hacer otro tanto. Y para limitar el disco, ya me apaño con los
subvolumenes de btrfs.  Lo que no he investigado es si se puede limitar
el ancho de banda. Quizás haya alguna forma con tc.

> Saludos,

Saludos y gracias.

-- 
   Patrimonio es un conjunto de bienes, matrimonio es un
conjunto de males.
  --- Enrique Jardiel Poncela --


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141215181324.gb2...@cubo.casa

Re: cgroup y lxc

2014-12-15 Por tema Camaleón 
El Sun, 14 Dec 2014 20:34:38 +0100, José Miguel (sio2) escribió:

> He estado este fin de semana curioseando lxc sobre jessie; y he llegado
> al problema de los contenedores de usuario (los unprivileged containers,
> vamos).

(...)

> Si la regla en cgrules.conf hago que sea:
> 
> @lxc* lxc/%u
> 
> La cosa funciona, pero yo lo único que quiero en cgroup aparte son las
> máquinas lxc, no el resto de procesos que pueda crear el usuario.
> 
> ¿A alguien alcanza a saber qué pasa?

Pues la verdad es que no :-P pero si no he entendido mal la problemática, 
te digo lo que probaría...

1/ Usuarios en lugar de grupos:

perico:lxc-start * lxc/%u
pantuflo:lxc-start * lxc/%u

2/ UID en lugar de nombres:

@lxc:lxc-start * lxc/%U

3/ No sé si será posible pero sería interesante aumentar la verbosidad 
del registro para ver por qué no puede crear el contenedor (¿permisos?).

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2014.12.15.16.06...@gmail.com

cgroup y lxc

2014-12-14 Por tema sio2 
Un saludo a la lista.

He estado este fin de semana curioseando lxc sobre jessie; y he llegado
al problema de los contenedores de usuario (los unprivileged
containers, vamos).

Después de dar vueltas y vueltas por internet acabé por pergeñar una
solución, pero no me acaba de funcionar, no sé muy bien por qué. La idea
es usar /etc/cgconfig.conf y /etc/cgrules.conf, de manera que al
arrancar se cree un cgroup de usuario llamado "lxc" en el que pueden
escribir los usuarios que pertenecen al grupo "lxc".

Para ello he creado este /etc/cgconfig.conf:

#v+
group lxc {
perm {
admin {
uid = root;
gid = lxc;
dperm = 775;
fperm = 664;
}
task {
uid = root;
gid = lxc;
fperm = 664;
}
}
memory {
memory.limit_in_bytes = 512m;
}
cpu {}
blkio {}
freezer {}
cpuacct {}
cpuset {
cgroup.clone_children = 1;
cpuset.cpus = 0;
cpuset.mems = 0;
}
devices {}
net_cls {}
net_prio {}
perf_event {}
}
#v-

Y en /etc/cgrules.conf he puesto esto:

#v+
@lxc:lxc-start* lxc/%u
@lxc:sleep* lxc/%u
#v-

La segunda línea sólo está a efectos de prueba y, en realidad, sobraría.

O sea, cuando un usuario del grupo "lxc" arranca lxc-start el proceso va
al cgroup lxc/nombre_de_usuario. Este cgroup lo creo cuando el usuario
arranca una sesión de bash (he creado un
/etc/profile.d/create_user_lxc.sh para ello).

En teoría debería funcionar y dejarme crear sin problema los
contenedores ya que estos se crearían dentro de lxc/nombre_de_usuario en
donde no hay problemas de permisos. Pero sucede una cosa muy curiosa con
lxc-start.

Si uso "sleep", la cosa va bien:

#v+
$ sleep 30 &
[1] 1124
$ cat /sys/fs/cgroup/memory/lxc/perico/tasks 
1124
$ sleep 20 &
[2] 1126
$ cat /sys/fs/cgroup/memory/lxc/perico/tasks 
1124
1126
$ sleep 10 &
[3] 1128
$ cat /sys/fs/cgroup/memory/lxc/poerico/tasks 
1124
1126
1128
#v-

O sea todos los procesos "sleep" van a "lxc/perico". Sin embargo, con
lxc-start ocurre que la primera vez funciona como espero:

#v+
$ lxc-start -n wheezy -d
$ cat /sys/fs/cgroup/memory/lxc/perico/tasks 
1139
$ ps -C lxc-start
  PID TTY  TIME CMD
 1139 ?00:00:00 lxc-start
#v-

Pero a partir de ese momento, deja de funcionarme eso de que todos los
procesos "sleep" y "lxc-start" vayan al cgroup "lxc/perico":

#v+
$ sleep 20 &
[3] 2400
pantuflo@zipi:~$ cat /sys/fs/cgroup/memory/lxc/pantuflo/tasks 
1139
$ grep 2400 /sys/fs/cgroup/memory/tasks 
2400
#v-

O sea, el sleep va al cgroup raiz. Este y todos los que lance a partir
de ahora. Un lxc-start falla y si miro por qué, me dice que porque no
puede crear el cgroup para el contenedor. Imagino que le pasará lo mismo
que a sleep: que el proceso va al cgroup raiz y ahí el usuario no puedo
crear ningún cgroup hijo.

Si la regla en cgrules.conf hago que sea:

@lxc* lxc/%u

La cosa funciona, pero yo lo único que quiero en cgroup aparte son las
máquinas lxc, no el resto de procesos que pueda crear el usuario.

¿A alguien alcanza a saber qué pasa?

Muchas gracias.

-- 
   La virtud, como el arte, hallarse suele
cerca de lo difícil [...]
  --- Lope de Vega ---


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141214193438.ga24...@cubo.casa