Actualicé mi humilde fork de fabric :-D Hace tiempo salió la versión 1.4 de Fabric, pero la facultad y el trabajo no me dieron tiempo de ponerme al día.
Para instalarlo usando pip, simplemente hay que ejecutar:
pip install -e git+https://github.com/hgdeoro/fabric@1.4#egg=fabric
lunes, 28 de mayo de 2012
domingo, 27 de mayo de 2012
Caché para pip
Al trabajar con varios proyectos Python usando virtualenv, es comun bajar una y otra vez las mismas librerías/dependencias (Django, South, PIL, psycopg2, etc).
Para optimizar la instalación de estos paquetes, se puede configurar pip para que utilice cierto directorio como cache. Para lograrlo, hay que crear el archivo ~/.pip/pip.conf, con el siguiente contenido:
[install]
download-cache = /var/cache/pip-cache
Obviamente necesitamos permisos de escritura en ese directorio. Una forma de crearlo seria:
$ sudo mkdir /var/cache/pip-cache
$ sudo chown USUARIO /var/cache/pip-cache
Para optimizar la instalación de estos paquetes, se puede configurar pip para que utilice cierto directorio como cache. Para lograrlo, hay que crear el archivo ~/.pip/pip.conf, con el siguiente contenido:
[install]
download-cache = /var/cache/pip-cache
Obviamente necesitamos permisos de escritura en ese directorio. Una forma de crearlo seria:
$ sudo mkdir /var/cache/pip-cache
$ sudo chown USUARIO /var/cache/pip-cache
martes, 13 de marzo de 2012
Hoy descubrí: fuser
El comando lista los procesos que poseen un archivo, socket o filesystem. Su funcionalidad es parecida a lsof, pero tiene más opciones. Por ejemplo, para ver los procesos que poseen archivos abiertos en el filesystem del dispositivo "/dev/mapper/seguro":
$ fuser -v -m /dev/mapper/seguro
USER PID ACCESS COMMAND
/dev/dm-5: root kernel swap /dev/sda6
root kernel mount /dev
horacio 2472 f.... startkde
horacio 2524 f.... unclutter
horacio 2950 F.... pulseaudio
horacio 3037 F.... gvfs-fuse-daemo
(...)
horacio 3047 F.... gvfs-gphoto2-vo
horacio 3063 F.... gvfs-afc-volume
horacio 3761 f.... chromium-browse
horacio 7684 F.... java
$ fuser -v -m /dev/mapper/seguro
USER PID ACCESS COMMAND
/dev/dm-5: root kernel swap /dev/sda6
root kernel mount /dev
horacio 2472 f.... startkde
horacio 2524 f.... unclutter
horacio 2950 F.... pulseaudio
horacio 3037 F.... gvfs-fuse-daemo
(...)
horacio 3047 F.... gvfs-gphoto2-vo
horacio 3063 F.... gvfs-afc-volume
horacio 3761 f.... chromium-browse
horacio 7684 F.... java
jueves, 16 de febrero de 2012
Hoy descubrí: cómo obtener runlevel en Solaris
Encontré que el comando "runlevel" no existe en Solaris, pero luego de investigar un poco encontré que hay que usar "who -r".
$ who -r
. run-level 3 Mar 27 23:10 3 0 S
Este comando sí funciona en Linux (al menos en Ubuntu), así que, una manera portable (al menos Linux/Solaris) de obtener el runlevel en un script sería:
$ who -r | awk '{ print $2 }'
2
$ who -r
. run-level 3 Mar 27 23:10 3 0 S
Este comando sí funciona en Linux (al menos en Ubuntu), así que, una manera portable (al menos Linux/Solaris) de obtener el runlevel en un script sería:
$ who -r | awk '{ print $2 }'
2
Un primer acercamiento a ZeroMQ (con Python)
Estoy aprendiendo a usar ZeroMQ (con Python + pyzqm)y encontré que emular el funcionamiento normal de sockets TCP/IP puede ser algo complicado para un primer acercamiento a la librería.
La implementación del servidor es bastante intuitiva:
Con esta segunda implementación, el cliente no bloquea si el servidor está caído.
La implementación del servidor es bastante intuitiva:
- hacemos bind,
- esperamos recibir peticiones,
- para cada petición devolvemos una respuesta.
-
-
La implementación del cliente es la que cambia bastante. Si intentamos enviar un mensaje usando sockets TCP/IP y no se puede establecer conexión con el servidor, del lado del cliente detectamos este problema... Por lo tanto, el envío se realiza correctamente, o se produce algún error de conexión (incluyendo la posibilidad de utilizar timeouts).
Pero con ZeroMQ, si el servidor NO está ejecutándose y el cliente envía un mensaje, el cliente se bloquea hasta que se pueda contactar el servidor y realizar el envío.
-
-
Para evitar que el cliente se bloquee, no hay posibilidad de usar un "timeout", pero podemos implementar algo parecido usando Poll().
-
-
Con esta segunda implementación, el cliente no bloquea si el servidor está caído.
jueves, 9 de febrero de 2012
Hoy descubrí: vipw y vigr
La idea es muy sencilla: permite editar /etc/passwd y /etc/group (o sus correspondientes 'shadows') luego de obtener un LOCK, y así evitar que varias personas los editen a la vez (aunque yo siempre prefiero usar comandos para alterar dichos archivos (usermod, chsh, etc) y no editarlos directamente).
miércoles, 8 de febrero de 2012
Implementé encabezados de Fabric en colores
He realizado unos cambios en Fabric para que utilice colores en los mensajes que escribe. Esto facilita mucho la visualización al ejecutar tareas que generan mucha salida por consola.
Así es la salida original de Fabric:
Al colorear los mensajes de Fabric, el resultado es mucho más fácil de leer:
Esto se encuentra en mi fork de Fabric, en https://github.com/hgdeoro/fabric/tree/1.3-hgdeoro (para versión estable) o https://github.com/hgdeoro/fabric/tree/colorized_headers.
martes, 7 de febrero de 2012
Mejora a Logging por default en Django
La configuración por default de LOGGING de Django hace que no se muestren por consola los mensajes de logging generados, sólo muestra los requests, y hacer que se vean nuestros mensajes es bastante fácil, sólo hay que agregar a LOGGING (en settings.py) las líneas en negritas:
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'handlers': {
'mail_admins': {
'level': 'ERROR',
'class': 'django.utils.log.AdminEmailHandler'
},
'console': {
'level': 'INFO',
'class': 'logging.StreamHandler'
},
},
'loggers': {
'': {
'handlers': ['console'],
'level': 'INFO',
'propagate': True,
},
'django.request': {
'handlers': ['mail_admins'],
'level': 'ERROR',
'propagate': True,
},
}
}
(esto funcionará en Django >= 1.3)
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'handlers': {
'mail_admins': {
'level': 'ERROR',
'class': 'django.utils.log.AdminEmailHandler'
},
'console': {
'level': 'INFO',
'class': 'logging.StreamHandler'
},
},
'loggers': {
'': {
'handlers': ['console'],
'level': 'INFO',
'propagate': True,
},
'django.request': {
'handlers': ['mail_admins'],
'level': 'ERROR',
'propagate': True,
},
}
}
(esto funcionará en Django >= 1.3)
domingo, 5 de febrero de 2012
Mejorando listado de task en Fabric
Cuando al usar Fabric listamos los comandos disponibles con --list, este listado está restringido a un ancho de 75 caracteres. Pero al usar una terminal de 160 caracteres de ancho, es mucho el espacio desperdiciado, y la documentación "ocultada".
Hice unos cambios en Fabric para que, al listar los comandos, utilice todo el ancho disponible. Antes, con una columna de 160 caracteres, el listado se mostraba:
Available commands:
FabricTest Nose-oriented test runner which wipes state.env and provid...
TestParallel
eq_ Shadow of the Nose builtin which presents easier to read m...
server Returns a decorator that runs an SSH server during functio...
Hice unos cambios en Fabric para que, al listar los comandos, utilice todo el ancho disponible. Antes, con una columna de 160 caracteres, el listado se mostraba:
Available commands:
FabricTest Nose-oriented test runner which wipes state.env and provid...
TestParallel
eq_ Shadow of the Nose builtin which presents easier to read m...
server Returns a decorator that runs an SSH server during functio...
Ahora:
Available commands:
FabricTest Nose-oriented test runner which wipes state.env and provides file helpers.
TestParallel
eq_ Shadow of the Nose builtin which presents easier to read multiline output.
server Returns a decorator that runs an SSH server during function execution.
Estos cambios están disponibles en mi fork de Fabric y puede ser instalado ejecutando "pip install -e git+https://github.com/hgdeoro/fabric@1.3-hgdeoro#egg=fabric"
Fabric: unsupported operand type(s) for &: 'str' and 'int'
Me ocurrió que upload_template() de Fabric fallaba con el siguiente mensaje de error:
Fatal error: put() encountered an exception while uploading '<StringIO.StringIO instance at 0x7fb4b6e0e368>'
Underlying exception message:
unsupported operand type(s) for &: 'str' and 'int'
Aborting.
Lo que estaba haciendo era bastante simple:
upload_template(
os.path.join('deploy-files', 'nginx', 'nginx-template.conf'),
nginx_config_file_to,
context=context,
use_sudo=True, backup=False, mode='0644')
Pero claro, resulta que el modo debe ser un valor en OCTAL, y no un STRING! Cambiando el modo de string a octal solucionó el problema:
Fatal error: put() encountered an exception while uploading '<StringIO.StringIO instance at 0x7fb4b6e0e368>'
Underlying exception message:
unsupported operand type(s) for &: 'str' and 'int'
Aborting.
upload_template(
os.path.join('deploy-files', 'nginx', 'nginx-template.conf'),
nginx_config_file_to,
context=context,
use_sudo=True, backup=False, mode='0644')
Pero claro, resulta que el modo debe ser un valor en OCTAL, y no un STRING! Cambiando el modo de string a octal solucionó el problema:
upload_template(
os.path.join('deploy-files', 'nginx', 'nginx-template.conf'),
nginx_config_file_to,
context=context,
use_sudo=True, backup=False, mode=0644)
os.path.join('deploy-files', 'nginx', 'nginx-template.conf'),
nginx_config_file_to,
context=context,
use_sudo=True, backup=False, mode=0644)
Es algo simple, pero lo comparto porque no encontré mucha información al buscar dicho mensaje de error en internet.
sábado, 4 de febrero de 2012
Nuevo "list format" para Fabric
He implementado un nuevo "list format" para Fabric. Este nuevo formateador hace que se muestren las distintas "tasks" declaradas, junto a la documentacion completa de las mismas.
Está disponibles en un branch de master (https://github.com/hgdeoro/fabric/tree/new_list_format_fulldoc) en un un branch de 1.3 (https://github.com/hgdeoro/fabric/tree/1.3-hgdeoro).
Por ejemplo, al ejecutar Fabric sobre "tests/test_parallel.py" con los argumentos "--list --list-format=fulldoc", se genera el siguiente listado:
Para instalarlo via pip:
$ pip install -e git+https://github.com/hgdeoro/fabric@1.3-hgdeoro#egg=fabric
Está disponibles en un branch de master (https://github.com/hgdeoro/fabric/tree/new_list_format_fulldoc) en un un branch de 1.3 (https://github.com/hgdeoro/fabric/tree/1.3-hgdeoro).
Por ejemplo, al ejecutar Fabric sobre "tests/test_parallel.py" con los argumentos "--list --list-format=fulldoc", se genera el siguiente listado:
Available commands:
FabricTest
----------
Nose-oriented test runner which wipes state.env and provides file helpers.
TestParallel
------------
eq_
---
Shadow of the Nose builtin which presents easier to read multiline output.
server
------
Returns a decorator that runs an SSH server during function execution.
Direct passthrough to ``serve_responses``.
Para instalarlo via pip:
$ pip install -e git+https://github.com/hgdeoro/fabric@1.3-hgdeoro#egg=fabric
Contribuyendo a proyectos OpenSource via GitHub
Hace tiempo uso GitHub para mis proyectos open source, pero hoy pude usarlo para compartir un pequeño FIX que hice a Fabric, y la verdad es que hace muy sencillo el trabajo.
El fix es algo insignificante (en una clase hay 2 métodos con el mismo nombre). Lo que hice fue renombrarlo el método, y después investigar qué tan fácil sería compartirlo con los autores de Fabric... y resultó muy fácil. Teniendo en cuenta que yo ya había clonado el proyecto (en modo solo-lectura), los pasos que seguí fueron:
El fix es algo insignificante (en una clase hay 2 métodos con el mismo nombre). Lo que hice fue renombrarlo el método, y después investigar qué tan fácil sería compartirlo con los autores de Fabric... y resultó muy fácil. Teniendo en cuenta que yo ya había clonado el proyecto (en modo solo-lectura), los pasos que seguí fueron:
- busqué en la doc. de GitHub cómo hacerlo, y lo encontré inmediatamente: http://help.github.com/send-pull-requests/
- creé un fork del proyecto original
- esto se hace con 1 clic en la interfaz web de GitHub
- cambié el "remote" a mi fork
- git remote set-url origin git@github.com:hgdeoro/fabric.git
- creé un branch
- git branch fix_duplicated_test_method
- realicé el commit con las modificaciones
- hice el push
- git push origin fix_duplicated_test_method:fix_duplicated_test_method
- en la interfaz web de GitHub me cambié al branch fix_duplicated_test_method
- en la interfaz web de GitHub hice clic en "Pull Request" y cargué el mensaje
Samba4 en CentOS 6.2
Siguiendo los pasos de https://wiki.samba.org/index.php/Samba4/HOWTO, con un CentOS 6.2 recién instalado, estos son los pasos que seguí para instalar Samba 4:
Preparacion del entorno
- crear usuario para NO trabajar con root, configurar keys de ssh y sudo
- instalar paquetes básicos
http://download.fedora.redhat.com/pub/epel/6/i386/epel-release-6-5.noarch.rpm
# sudo rpm -i epel-release-6-5.noarch.rpm
# sudo yum install -y man
# sudo rpm -i epel-release-6-5.noarch.rpm
# sudo yum install -y man
# sudo yum install -y gcc patch
# sudo yum install -y autoconf
Compilado de Samba 4
- instalamos git
- instalamos paquetes recomendados
$ yum install gtkhtml setroubleshoot-server setroubleshoot-plugins policycoreutils-python libsemange-python setools-libs-python setools-libs popt-devel libpcap-devel sqlite-devel libidn-devel libxml2-devel libacl-devel libsepol-devel libattr-devel keyutils-libs-devel zlib-devel cyrus-sasl-devel
Al instalarlos con el comando anterior, me apareció:
(...)
No package gtkhtml available.
No package libsemange-python available.
(...)
pero me imagino que no son paquetes esenciales...
- bajamos repositorio Git y compilamos
# cd samba-master
Ahora deberemos "parchear" unos scripts Python que tienen un bug (esto no hará falta cuando los arreglos a estos scripts estén en git). Para parchearlos hay que ejecutar (en una misma línea):
# curl -s https://raw.github.com/gist/1739239/a8a38ef99dae9c5a12bc6939d59161dcc1f2fa5a/use-named-argument-dir-instead-of-prefix.diff | patch -p1
Este comando fallará si los scripts fueron arreglados en el repositorio de Git (al menos los parches ya fueron aceptados :-D https://lists.samba.org/archive/samba-technical/2012-February/081527.html).
Ahora continuamos con el proceso:
# ./configure.developer --prefix=/opt/samba4-3bea5a147b
Nota: '3bea5a147b' es el commit (abreviado) de Git, sirve para identificar exactamente que versión estamos instalado. Se obtiene ejecutando: `git log --oneline | head -n 1 | cut -d " " -f 1`
# make -j2
# sudo mkdir /opt/samba4-3bea5a147b
# sudo chown USUARIO /opt/samba4-3bea5a147b
# make install
El próximo paso sería generar los archivos básicos que necesita Samba para funcionar. Esto se hace con el script "provision", pero al parecer al algún problema con el último comando que ejecutamos ("make install"): éste modifica algunos archivos y hace que se produzca un error al intentar ejecutar "provision". Por lo tanto, antes de ejecutar "provision", debemos volve a ejecutar "make" (https://lists.samba.org/archive/samba-technical/2012-February/081526.html)
El próximo paso sería generar los archivos básicos que necesita Samba para funcionar. Esto se hace con el script "provision", pero al parecer al algún problema con el último comando que ejecutamos ("make install"): éste modifica algunos archivos y hace que se produzca un error al intentar ejecutar "provision". Por lo tanto, antes de ejecutar "provision", debemos volve a ejecutar "make" (https://lists.samba.org/archive/samba-technical/2012-February/081526.html)
# make -j2
--realm=samdom.example.com \
--domain=SAMDOM \
--adminpass=SOMEPASSWORD \
--server-role='domain controller'
# sudo /opt/samba4-3bea5a147b/sbin/samba -i -M single
Aunque Samba ya está andando, queda pendiente su configurar, configuración de DNS, etc.
EDITADO: siguiendo el consejo del HOWTO, hace falta agregar el dominio en /etc/resolv.conf (una linea al estilo de "domain samdom.example.com")
EDITADO: el password seteado con "--adminpass" no debe ser simple, sino el proceso fallará con el error "check_password_restrictions: the password does not meet the complexity criteria!".
EDITADO: siguiendo el consejo del HOWTO, hace falta agregar el dominio en /etc/resolv.conf (una linea al estilo de "domain samdom.example.com")
EDITADO: el password seteado con "--adminpass" no debe ser simple, sino el proceso fallará con el error "check_password_restrictions: the password does not meet the complexity criteria!".
Corriendo tests con instancia de PostgreSql en ram
Otra manera de optimizar la ejecución de tests de Django, pero SIN modificar la instalación de PostgreSql del sistema operativo es crear una nueva instancia, corriendo totalmente en ram.
Para crear una nueva instancia usamos initdb:
$ /usr/lib/postgresql/9.1/bin/initdb \
--pgdata=/dev/shm/pgtesting \
-U horacio
Y para lanzar la instancia en segundo plano:
$ /usr/lib/postgresql/9.1/bin/postgres \
-F -i -p 5444 -S $((1024*64)) \
-D /dev/shm/pgtesting \
--unix_socket_directory=/dev/shm/pgtesting \
-r /dev/shm/pgtesting/postgresql.log &
Luego creamos el usuario y BD para la aplicación Django:
psql -h 127.0.0.1 \
-c "create user vindler with password 'x' superuser" postgres
psql -h 127.0.0.1 \
-c "create database vindler owner vindler" postgres
Mejora en tiempos de ejecución de test: 28%
La ejecución de los tests con PostgreSql en disco, con las optimizaciones de mi artículo anterior tardan alrededor de 7 segundos:
Ran 18 tests in 7.071s
5.44user 0.58system 0:10.40elapsed 57%CPU (0avgtext+0avgdata 122880maxresident)k
0inputs+1184outputs (0major+16964minor)pagefaults 0swaps
Ran 18 tests in 6.843s
5.28user 0.65system 0:10.27elapsed 57%CPU (0avgtext+0avgdata 122976maxresident)k
0inputs+1176outputs (0major+16956minor)pagefaults 0swaps
Ran 18 tests in 7.032s
5.42user 0.64system 0:10.42elapsed 58%CPU (0avgtext+0avgdata 124304maxresident)k
0inputs+1168outputs (0major+17122minor)pagefaults 0swaps
Los mismos tests ejecutandose en la nueva instancia de PostgreSql totalmente en ram, tardan alrededor de 5 segundos:
Ran 18 tests in 5.220s
4.41user 0.65system 0:08.38elapsed 60%CPU (0avgtext+0avgdata 117904maxresident)k
8inputs+1176outputs (0major+16524minor)pagefaults 0swaps
Ran 18 tests in 5.047s
4.32user 0.53system 0:08.04elapsed 60%CPU (0avgtext+0avgdata 117888maxresident)k
0inputs+1168outputs (0major+16504minor)pagefaults 0swaps
Ran 18 tests in 4.665s
3.95user 0.64system 0:07.79elapsed 58%CPU (0avgtext+0avgdata 117856maxresident)k
0inputs+1176outputs (0major+16502minor)pagefaults 0swaps
Al ejecutar los tests de stress: 33%
Con PostgreSql en disco:
Ran 1 test in 24.601s
15.21user 2.72system 0:27.98elapsed 64%CPU (0avgtext+0avgdata 130944maxresident)k
0inputs+9616outputs (0major+18298minor)pagefaults 0swaps
Ran 1 test in 24.458s
15.16user 2.51system 0:27.57elapsed 64%CPU (0avgtext+0avgdata 131488maxresident)k
472inputs+9608outputs (0major+18457minor)pagefaults 0swaps
Ran 1 test in 24.552s
15.23user 2.63system 0:27.95elapsed 63%CPU (0avgtext+0avgdata 131088maxresident)k
232inputs+9616outputs (0major+18310minor)pagefaults 0swaps
Para crear una nueva instancia usamos initdb:
$ /usr/lib/postgresql/9.1/bin/initdb \
--pgdata=/dev/shm/pgtesting \
-U horacio
Y para lanzar la instancia en segundo plano:
$ /usr/lib/postgresql/9.1/bin/postgres \
-F -i -p 5444 -S $((1024*64)) \
-D /dev/shm/pgtesting \
--unix_socket_directory=/dev/shm/pgtesting \
-r /dev/shm/pgtesting/postgresql.log &
Luego creamos el usuario y BD para la aplicación Django:
psql -h 127.0.0.1 \
-c "create user vindler with password 'x' superuser" postgres
psql -h 127.0.0.1 \
-c "create database vindler owner vindler" postgres
Mejora en tiempos de ejecución de test: 28%
La ejecución de los tests con PostgreSql en disco, con las optimizaciones de mi artículo anterior tardan alrededor de 7 segundos:
Ran 18 tests in 7.071s
5.44user 0.58system 0:10.40elapsed 57%CPU (0avgtext+0avgdata 122880maxresident)k
0inputs+1184outputs (0major+16964minor)pagefaults 0swaps
Ran 18 tests in 6.843s
5.28user 0.65system 0:10.27elapsed 57%CPU (0avgtext+0avgdata 122976maxresident)k
0inputs+1176outputs (0major+16956minor)pagefaults 0swaps
Ran 18 tests in 7.032s
5.42user 0.64system 0:10.42elapsed 58%CPU (0avgtext+0avgdata 124304maxresident)k
0inputs+1168outputs (0major+17122minor)pagefaults 0swaps
Los mismos tests ejecutandose en la nueva instancia de PostgreSql totalmente en ram, tardan alrededor de 5 segundos:
Ran 18 tests in 5.220s
4.41user 0.65system 0:08.38elapsed 60%CPU (0avgtext+0avgdata 117904maxresident)k
8inputs+1176outputs (0major+16524minor)pagefaults 0swaps
Ran 18 tests in 5.047s
4.32user 0.53system 0:08.04elapsed 60%CPU (0avgtext+0avgdata 117888maxresident)k
0inputs+1168outputs (0major+16504minor)pagefaults 0swaps
Ran 18 tests in 4.665s
3.95user 0.64system 0:07.79elapsed 58%CPU (0avgtext+0avgdata 117856maxresident)k
0inputs+1176outputs (0major+16502minor)pagefaults 0swaps
Al ejecutar los tests de stress: 33%
Con PostgreSql en disco:
Ran 1 test in 24.601s
15.21user 2.72system 0:27.98elapsed 64%CPU (0avgtext+0avgdata 130944maxresident)k
0inputs+9616outputs (0major+18298minor)pagefaults 0swaps
Ran 1 test in 24.458s
15.16user 2.51system 0:27.57elapsed 64%CPU (0avgtext+0avgdata 131488maxresident)k
472inputs+9608outputs (0major+18457minor)pagefaults 0swaps
Ran 1 test in 24.552s
15.23user 2.63system 0:27.95elapsed 63%CPU (0avgtext+0avgdata 131088maxresident)k
232inputs+9616outputs (0major+18310minor)pagefaults 0swaps
Con PostgreSql en ram:
Ran 1 test in 16.082s
11.30user 2.46system 0:19.22elapsed 71%CPU (0avgtext+0avgdata 126080maxresident)k
0inputs+9616outputs (0major+17675minor)pagefaults 0swaps
Ran 1 test in 15.736s
11.25user 2.20system 0:18.82elapsed 71%CPU (0avgtext+0avgdata 126192maxresident)k
0inputs+9608outputs (0major+17684minor)pagefaults 0swaps
Ran 1 test in 15.408s
10.78user 2.27system 0:18.44elapsed 70%CPU (0avgtext+0avgdata 126384maxresident)k
0inputs+9608outputs (0major+17693minor)pagefaults 0swaps
Acelerando tests de Django con PostgreSql
La ejecucion inicial de los tests toma aproximadamente 15 segundos:
4.54user 0.64system 0:15.25elapsed 34%CPU (0avgtext+0avgdata 123600maxresident)k
4.70user 0.54system 0:14.70elapsed 35%CPU (0avgtext+0avgdata 122992maxresident)k
4.46user 0.65system 0:14.85elapsed 34%CPU (0avgtext+0avgdata 122912maxresident)k
Luego de ajustar los siguientes parametros:
- fsync = off
- synchronous_commit = off
- wal_sync_method = fsync
la ejecución toma aproximadamente 8.5 segundos:
4.22user 0.56system 0:08.62elapsed 55%CPU (0avgtext+0avgdata 123024maxresident)k
4.32user 0.58system 0:08.97elapsed 54%CPU (0avgtext+0avgdata 123008maxresident)k
4.29user 0.50system 0:08.74elapsed 54%CPU (0avgtext+0avgdata 123040maxresident)k
El tiempo se redujo casi a la mitad! Aunque esta configuración no es para nada recomendable para un equipo de producción, creo que vale la pena para ejecutar tests.
4.54user 0.64system 0:15.25elapsed 34%CPU (0avgtext+0avgdata 123600maxresident)k
4.70user 0.54system 0:14.70elapsed 35%CPU (0avgtext+0avgdata 122992maxresident)k
4.46user 0.65system 0:14.85elapsed 34%CPU (0avgtext+0avgdata 122912maxresident)k
Luego de ajustar los siguientes parametros:
- fsync = off
- synchronous_commit = off
- wal_sync_method = fsync
la ejecución toma aproximadamente 8.5 segundos:
4.22user 0.56system 0:08.62elapsed 55%CPU (0avgtext+0avgdata 123024maxresident)k
4.32user 0.58system 0:08.97elapsed 54%CPU (0avgtext+0avgdata 123008maxresident)k
4.29user 0.50system 0:08.74elapsed 54%CPU (0avgtext+0avgdata 123040maxresident)k
El tiempo se redujo casi a la mitad! Aunque esta configuración no es para nada recomendable para un equipo de producción, creo que vale la pena para ejecutar tests.
jueves, 2 de febrero de 2012
Bajar paquetes y no instalarlos con yum
Suelo usar en Debian/Ubuntu el comando:
# aptitude -yd algun-paquete
que permite bajar el paquete pero NO instalarlo. Pero yum no tiene ninguna opción parecida, aunque encontré que a través de un plugin se puede conseguir la misma de aptitude.
Para instalar dicho plugin:
# yum install yum-downloadonly
# yum --help
(...)
Las instrucciones las encontré en http://www.cyberciti.biz/faq/yum-downloadonly-plugin/
# aptitude -yd algun-paquete
que permite bajar el paquete pero NO instalarlo. Pero yum no tiene ninguna opción parecida, aunque encontré que a través de un plugin se puede conseguir la misma de aptitude.
Para instalar dicho plugin:
# yum install yum-downloadonly
# yum --help
(...)
Plugin Options:
--downloadonly don't update, just download
--downloaddir=DLDIR
specifies an alternate directory to store packages
Y se puede usar, por ejemplo:
# yum install --downloadonly python-devel
miércoles, 25 de enero de 2012
Instalando django_openid_auth usando PIP
Hay algunos problemas con la version 0.4 de django_openid_auth (ej: no se puede instalar via pip). El proyecto es open source, por lo tanto es muy facil subirlo a GitHub y compartir estos arreglos :-)
Básicamente bajé el proyecto original (revisión 88) y lo subi a GitHub. Para instalarlo usando PIP hay que ejecutar:
./pip install -e git+http://github.com/hgdeoro/hgdeoro_fork_of_django_openid_auth#egg=django_openid_auth
Actualización
Mucho mejor, instalamos usando PIP, pero un commit en particular (ec68dfc046d1a75b50080ea98c56eda71956ed7a):
pip install -e git+http://github.com/hgdeoro/hgdeoro_fork_of_django_openid_auth@ec68dfc046d1a75b50080ea98c56eda71956ed7a#egg=django_openid_auth
O también un tag en particular (bzr_revno_88):
pip install -e git+http://github.com/hgdeoro/hgdeoro_fork_of_django_openid_auth@bzr_revno_88#egg=django_openid_auth
Básicamente bajé el proyecto original (revisión 88) y lo subi a GitHub. Para instalarlo usando PIP hay que ejecutar:
./pip install -e git+http://github.com/hgdeoro/hgdeoro_fork_of_django_openid_auth#egg=django_openid_auth
Actualización
Mucho mejor, instalamos usando PIP, pero un commit en particular (ec68dfc046d1a75b50080ea98c56eda71956ed7a):
pip install -e git+http://github.com/hgdeoro/hgdeoro_fork_of_django_openid_auth@ec68dfc046d1a75b50080ea98c56eda71956ed7a#egg=django_openid_auth
O también un tag en particular (bzr_revno_88):
pip install -e git+http://github.com/hgdeoro/hgdeoro_fork_of_django_openid_auth@bzr_revno_88#egg=django_openid_auth
miércoles, 21 de diciembre de 2011
Cargando modulo 'tun' al iniciar Android
Al intentar usar el cliente de OpenVpn me encontré con que mi Android no carga automáticamente el modulo "tun", y por lo tanto la VPN nunca levanta.
Para solucionarlo, agregué el siguiente archivo en "/system/etc/init.d/10modprobetun":
Luego de crear el archivo, hace falta agregarle permisos de ejecución, usando:
chmod +x /system/etc/init.d/10modprobetun
Para poder modificar los contenidos de /system, hay que remontarlo en modo escritura, usando:
mount -o remount,rw /system
Ahora, luego de reiniciar el celular, el modulo aparece cargado:
localhost ~ # lsmod
Module Size Used by Not tainted
wireless 189315 0
tun 11765 0
Para solucionarlo, agregué el siguiente archivo en "/system/etc/init.d/10modprobetun":
Luego de crear el archivo, hace falta agregarle permisos de ejecución, usando:
chmod +x /system/etc/init.d/10modprobetun
Para poder modificar los contenidos de /system, hay que remontarlo en modo escritura, usando:
mount -o remount,rw /system
Ahora, luego de reiniciar el celular, el modulo aparece cargado:
localhost ~ # lsmod
Module Size Used by Not tainted
wireless 189315 0
tun 11765 0
jueves, 8 de diciembre de 2011
Aprendiendo a usar uci en OpenWrt
Entre la extensa documentación de OpenWrt encontré que "uci show" puede ser de muchísima ayuda, ya que hace un "dump" de la configuración en un formato que después se puede usar con "uci get" y "uci set". Por ejemplo:
root@TL_MR3420:/etc/config# uci show system
system.@system[0]=system
system.@system[0].timezone=UTC
system.@system[0].hostname=TL_MR3420
system.ntp=timeserver
system.ntp.server=0.openwrt.pool.ntp.org 1.openwrt.pool.ntp.org 2.openwrt.pool.ntp.org 3.openwrt.pool.ntp.org
system.led_usb=led
system.led_usb.name=USB
system.led_usb.sysfs=tp-link:green:3g
system.led_usb.trigger=usbdev
system.led_usb.dev=1-1
system.led_usb.interval=50
root@TL_MR3420:/etc/config# uci show system
system.@system[0]=system
system.@system[0].timezone=UTC
system.@system[0].hostname=TL_MR3420
system.ntp=timeserver
system.ntp.server=0.openwrt.pool.ntp.org 1.openwrt.pool.ntp.org 2.openwrt.pool.ntp.org 3.openwrt.pool.ntp.org
system.led_usb=led
system.led_usb.name=USB
system.led_usb.sysfs=tp-link:green:3g
system.led_usb.trigger=usbdev
system.led_usb.dev=1-1
system.led_usb.interval=50
Luego, por ejemplo, para cambiar la zona horaria:
root@TL_MR3420:/etc/config# uci set system.@system[0].timezone=ART3
root@TL_MR3420:/etc/config# uci commit system
sábado, 5 de noviembre de 2011
Apache en primer plano (o sea, foreground)
Necesitaba iniciar apache y que quede funcionando en "primer plano". Inicialmente intenté arrancarlo con la opción "-X" para activar el modo debug, pero esto hacía que las páginas sean servidas muy lentamente. Buscando un poco más encontré http://httpd.apache.org/docs/2.2/programs/httpd.html y ví que se puede usar "-D" para lograrlo.
Finalmente, el comando que estoy usando es:
apache2 -DNO_DETACH -DFOREGROUND -f apache-dev.conf
Finalmente, el comando que estoy usando es:
apache2 -DNO_DETACH -DFOREGROUND -f apache-dev.conf
Suscribirse a:
Entradas (Atom)