Re: cgroup y lxc
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
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
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
Re: cgroup y lxc
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
