Archivo de la etiqueta: config

Distutils2 el posible futuro del empaquetado de aplicaciones en Python

Distutils (Python Distribution Utilities) es un módulo estándar de la biblioteca de python con el propósito de distribuir aplicaciones Python de forma sencilla. Es el módulo estándar para empaquetado de aplicaciones en Python.

Si has utilizado distutils en pequeños proyectos puede que haya sido suficiente para tus necesidades. Sin embargo, a medida que es necesario personalizar con más detalles la instalación o realizar funciones avanzadas, distutils resulta ser un módulo carente de algunas funcionalidades y con muchos pequeños detalles por mejorar. Es simple, pero limitado y no extensible de forma trivial.

En mi opinión, hay dos principales problemas en la forma en la que se distribuye aplicaciones y módulos python:

  • 1) Existen muchas formas de realizar la instalación de una distribución de paquetes Python y crea un estado de interoperabilidad difícil.
  • 2) No existe una API para conseguir información de las distribuciones de paquetes instaladas.

Alternativas

Están disponibles otras alternativas como Setuptools. Este proyecto nació para rellenar pequeñas funcionalidades olvidadas en distutils y explorar nuevas direcciones. Para algunas subcomunidades Setuptools es un estándar de facto. Pero actualmente su desarrollo no esta siendo mantenido (por inactividad en 2 años) y su uso esta en decadencia desde que no tiene soporte para python 3.x.

Posteriormente surgió Distribute. Es un fork como reemplazo de Setuptools iniciado por los mismos desarrolladores que sentían que el proyecto no avanzaba lo suficiente y pensaban que no era posible una evolución.

De este último grupo ha surgido una nueva biblioteca, llamada Distutils2. Iniciada desde la base de distutils y tomando las buenas ideas de Setuptools (discutidas fuertemente en PEPs como PEP 376, PEP 386), además de inspirarse en un instalador básico similar a pip.

Integración Distutils2

Distutils2 tenia como principal objetivo la integración como módulo nativo en la rama de Python 3.3 bajo el módulo packaging. Debido a problemas en su desarrollo esta semi-paralizado hasta Python 3.4 a la espera de acuerdos entre desarrolladores y fijación de objetivos aunque este cuenta con una buena cobertura de test y estabilidad.

Novedades

Compatibilidad con otros sistemas

Distutils2 Estado actual del empaquetado de aplicaciones Python
Estado actual del empaquetado de aplicaciones Python

Los módulos de Distutils2 están capacitados para funcionar con PyPI y los metadatos asociados en proyectos instalados. El objetivo a largo plazo es la coexistencia de proyectos escritos para Pip o Distribute puesto que usan los mismos estándares. Por ejemplo, esta iniciándose una remodelización de pip, llamada pip2 que debería comtemplar la coexistencia con distutils2.

Nuevos comandos de instalación

Distutils2 habilita nuevos comandos de instalación como:

  • test : un comando para ejecutar las pruebas del proyecto (idea inspirada en Setuptools).
  • upload_docs: un comando para subir la documentación a packages.python.org
  • check: previamente añadido, pero ha sido mejorado para que se realicen comprobaciones antes de liberar o subir un paquete. Comprueba los metadatos, cumplimiento de reglas reST en la descripción.
  • uninstall: es una función muy básica añadida en el módulo distutils2.util que permite desinstalar de forma sencilla la aplicación. Esta ha sido una petición muy demandada para python 3.3. Además se incluye una API para eliminar todos los archivos que no cambiaron o directorios vacíos. Por ejemplo, para listar una lista de todos los archivos posibles para desinstalar:
from distutils2.util import uninstall
uninstall('setuptools')

Grafico de dependencias

El módulo constructor de grafos de dependencias de paquetes analiza las dependencias entre varias distribuciones de paquetes y permite a través de una API de código crear un grafo representando las relaciones entre ellos. Se sirve de graphviz para realizar los gráficos desde lenguage DOT. Por ejemplo, este sería el aspecto más básico y sin personalizar de un paquete de dependencias con el nombre “bacon”.

Gráfico de dependencias generado
Gráfico de dependencias generado

Archivo de configuración

Distutils2 toma como primera opción el archivo distutils2.cfg además del setup.cfg para permitir la compatibilidad con antiguos archivos de configuración. Es posible por tanto configurar la instalación sin necesidad de setup.py y sólo usar setup.cfg. Por defecto, los archivos como README o README.txt además del setup.py no serán más incluidos en la opción de distribución de fuentes.

Generación del archivo de configuración

Editar los archivos de configuración desde cero puede resultar muy tedioso, por ello se ha ideado un script interactivo (mkcfg) que permite generar el archivo setup.cfg preguntando los datos esenciales.

Para ejecutarlo:

$ python -m distutils2.mkcfg

Hooks

Distutils2 permite ser extensible a través de comandos que se ejecutan antes y después de una opción (hooks). Los hooks son simples funciones python (u objetos invocables) que están especificados en el archivo de configuración usando los nombres completos.

Los hooks se ejecutan después de que las opciones sean leídas y antes y después del comando a ejecutar.  Un ejemplo de hook necesitaría inicialmente que el hook estuviera presente en la ruta de ejecución, es decir, en el directorio del setup.py. Se crea un archivo en python para el hook, por ejemplo myhoook.py para el comando de instalación:

def my_install_support_hook(install_cmd):
    print "Genial, acabas de instalar mi proyecto! Ahora visita mi web blablable.com para soporte."

Posteriormente se edita el archivo setup.cfg bajo la sección de comandos apropiadas para la instalación:

[install]
pre-hook.myproject = myhooks.my_install_support_hook

Nuevas keywords

En la función setup donde recibe todas las palabras claves como autor, email, version, etc se han añadido nuevas que faciliten un mayor control.

Sistema de logging mejorado

La primera versión de disutils incluye un modulo de depuración para mensajes de error e información que no utilizaba el módulo logging estándar de Python, es decir siguiendo el estilo del PEP 282. La nueva versión de distutils2 usa de forma nativa el módulo logging.

Instalación

Si te ha parecido interesante el módulo de Distutils2, probablemente estés muy interesado en probarlo e instalarlo.

Para instalarlo puedes seguir la guía de instalación o el tutorial que se ofrece desde la documentación

Para python 2.7 puedes probar a instalarlo desde pip:

$ sudo pip install distutils2

Para Python 3, necesitas instalar (en Ubuntu) pip con compatibilidad para python3 con el paquete python3-pip:

$ sudo apt-get install python3-pip

Y después instalarlo vía:

$ sudo pip install http://hg.python.org/distutils2/archive/python3.tar.bz2

Si estas interesado en ver el código, puedes clonar el repositorio Mercurial con:

$ hg clone http://hg.python.org/distutils2

Como contribuir

Los autores de Distutils2 animan a contribuir y realizar sprints para finalizar características pendientes y corregir fallos.

Fuentes

Como crear un servidor proxy con Squid en Ubuntu

Como crear un servidor proxy con Squid en Ubuntu - Squid Cache Logo
Squid Cache

Un servidor proxy tiene la misión de actuar de intermediario en el acceso de un recurso en internet. Suelen utilizarse como pasarelas que permitan acceder a páginas webs restringidas por país o dentro de una empresa, es decir, pueden trabajar como muro cortafuegos operando en la capa de red (actuando como filtro de paquetes, como es el caso de iptables) o bien desde la capa de aplicación controlando diferentes servicios.

Funciones servidor proxy

Otra de sus funciones es actuar como caché de contenido de red (principalmente para el protocolo HTTP), proporcionando mayor proximidad de los clientes a un caché de páginas y archivos de forma que estos accedan con tiempos similares a los de una red local.

En este sentido el servidor de proxy cache Squid tiene un alto rendimiento además de soportar FTP o incluso HTTP sobre IPv4 e Ipv6. Todos los objetos cacheados por Squid permanecen en RAM, incluso consultas de búsquedas DNS. Es importante recalcar que Squid administra todas las peticiones bajo un único proceso asíncrono y no bloqueante. Por otro lado se ofrece soporte SSL y listas de control de acceso.

Proceso de interacción de un servidor proxy

Durante el proceso de interacción ocurre lo siguiente:

  1. Un cliente se conecta hacia un Servidor Proxy.
  2. El cliente solicita una conexión, archivo u otro recurso disponible en un servidor distinto.
  3. El Servidor Proxy proporciona el recurso ya sea conectándose hacia el servidor especificado o sirviendo éste desde un caché.
  4. En algunos casos el Servidor Proxy puede alterar la solicitud del cliente o bien la respuesta del servidor para diversos propósitos.

Este último punto 4, es que permite realizar muchas configuraciones personalizadas a los administradores de sistemas.

Instalación de Squid

En este artículo se instalará Squid 3.1. Para instalarlo en Ubuntu o Debian based:

sudo apt-get install squid3

Después se debe editar el fichero de configuración por defecto /etc/squid3/squid.conf

Por defecto el acceso http esta negado para todas las peticiones. Por ello debes buscar y borrar en el archivo la configuración:

http_access deny all

En su lugar se puede configurar una lista de acceso basada en rangos de IP al que se quiera permitir el acceso, por ejemplo:

acl our_networks src 123.123.123.0/24 213.213.213.0/24
http_access allow our_networks

De igual forma puedes comprobar que la directiva http_port este apuntando al puerto 3128 por defecto o cambiarlo al que necesites. Debes tener en cuenta que de acuerdo a las asignaciones hechas por IANA y continuadas por la ICANN desde el 21 de marzo de 2001, son los Puertos Registrados (rango desde 1024 hasta 49151)  y los recomendados para Servidores Proxies son el 3128 y 8080 a través de TCP.

También se pueden configurar varios:

http_port 3128
http_port 8080

O incluso especificando varias IPs:

http_port 192.168.1.254:3128
http_port 192.168.1.253:8080

Una vez configurado, es necesario reiniciar squid con:

sudo service squid3 restart

También existen otras opciones como recargar la configuración:

service squid reload

Parar el servicio:

service squid stop

O iniciarlo:

service squid start

Si tienes chkconfig (Sistemas basados en RedHat como Centos) puedes activarlo automáticamente en cada inicio del sistema con:

chkconfig squid on

Para comprobar si se está ejecutando correctamente:

sudo service squid3 status

Y si esta efectivamente escuchando en el puerto configurado:

netstat -tulpn | grep 3128

Si existe algun error grave, que no permita iniciar el servicio se debe examinar el contenido del fichero /var/log/squid/squid.out

Se puede acceder a los ficheros de log mediante:

sudo cat /var/log/squid3/access.log

O bien el fichero de cache:

sudo cat /var/log/squid3/cache.log

Para conocer la ip pública del proxy puede utilizarse:

curl ifconfig.me

Modificaciones de configuración básicas

Para mostrar las cadenas de las consultas http en el log, es necesario desactivar la directiva strip_query_terms (por defecto activa) en /etc/squid3/squid.conf:

strip_query_terms off

Por otro lado el parámetro cache_mem establece la cantidad de memoria RAM dedicada para almacenar los datos mas solicitados y datos en tránsito (con mayor prioridad de almacenamiento). Los datos son normalmente almacenados en bloques de 4 Kb. El valor por defecto es de 256 MB, pero puede especificarse una cantidad mayor si es necesario. Por ejemplo puede establecerse 2 GB de memoria:

cache_mem 2048 MB

Por defecto, si algo ocurre con la caché, como por ejemplo que el proceso se termine, se enviará un mensaje de aviso a la cuenta de email del webmaster en el servidor. Para configurarla pues cambiarse la directiva cache_mgr:

cache_mgr [email protected]

Se puede especificar un lugar diferente para el registro de accesos con la directiva access_log:

access_log /var/log/squid/access.log squid

Para ver toda tu configuración squid, sin mostrar los comentarios, puedes usar:

cat /etc/squid/squid.conf | sed '/ *#/d; /^ *$/d'

O bien:

grep -v "^#" /etc/squid/squid.conf | sed -e '/^$/d'

Solución de errores

Si intentas conectar a tu servidor proxy y este no atiende tus peticiones, es posible que no hayas abierto los puertos en tu router. Se recomienda abrir el puerto TCP/UDP en el que este configurado Squid.

Fuentes y enlaces relacionados

– Sitio web Squid Cache

– Proyecto Squid en Launchpad

– Desarrollo del proyecto Squid con Bazaar

RoadMap de Squid

Manual Squid LinuxParaTodos

UnixCraft: Setup a transparent proxy with Squid in three easy steps

– Install Squid Proxy Server on CentOS / Redhat enterprise Linux 5

Acelerar la carga del terminal borrando logs en Ubuntu

Terminal

Por lo general, al iniciar alguna consola o terminal bash, se leen muchos archivos de configuración por defecto y se abren archivos para guardar los eventos de actividad que van ocurriendo. Aunque es útil, puede ralentizar un poco la carga del terminal.

Normalmente, cuando un sistema lleva mucho tiempo en ejecución o ha pasado bastante tiempo desde que fue instalado por primera vez, se acumulan bastantes logs de actividad de diferentes procesos.

Logrotate es una buena utilidad, activada por defecto en la mayoría de distribuciones para los archivos más importantes y que generan mayor volumen de información. Es muy útil porque ademas comprime los logs y los borra pasado un tiempo.

El problema, es que no todas las configuraciones por defecto de logrotate suministradas por la distribución, pueden resultar útiles para todos los usuarios.

Aunque se puede optar por personalizar logrotate para los archivos necesarios, muchas veces se desconocen cuales son todos los archivos de logs o resulta demasiado tedioso ir configurando todos, incluso aunque utilices sistemas automatizados como Puppet.

De ahí la necesidad de crear un pequeño script de bash, más radical (bajo responsabilidad del usuario) que previo respaldo de todos los logs en el home, borre todos los archivos de log más antiguos que una determinada fecha dada en días y tambien borre archivos rotados con logrotate.

Lo he llamado zerolog y este es código que realiza esas tareas:

#!/usr/bin/env bash

#    zerolog is a bash script for delete common logs on /var/log and
#    avoid fill the disk with rotated files. It backups previously
#    the logs on home folder and it can preserve logs older than
#    a date given on days. This is useful for avoid slow sessions
#    starts on bash terminals.

#    Copyright (C) 2012 by Ángel Guzmán Maeso, shakaran at gmail dot com

#    This program is free software; you can redistribute it and/or modify
#    it under the terms of the GNU General Public License as published by
#    the Free Software Foundation; either version 3 of the License, or
#    (at your option) any later version.

#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#    GNU General Public License for more details.

#    You should have received a copy of the GNU General Public License
#    along with this program; if not, write to the Free Software
#    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

usage(){
    echo 'Usage: $0 [DAYS]'
    echo 'DAYS: Remove logs older than DAYS. Default: 0 days'
    exit 1
}

if [ `/usr/bin/id -u` -ne 0 ]; then
    echo 'Please, run this script as root'
    usage
fi

if [ -z "$1" ]; then
    MTIME_DAYS=''
else
    MTIME_DAYS='-mtime +$1'
fi

echo Currently logs size: `du -hs /var/log/ | awk {'print $1'}`
echo 'Backup the log folder on home'
tar zcPf ~/logs-`date '+%m-%d-%y-%H:%M:%S'`.tar.gz /var/log

echo 'Removing rotated log files'
find /var/log/ -type f $MTIME_DAYS -name *.gz -exec rm -rf '{}' \;

echo 'Emptying the logs'
for logs in `find /var/log $MTIME_DAYS -type f`; do > $logs; done

echo Currently logs size: `du -hs /var/log/ | awk {'print $1'}`

El script esta subido a github en:

https://github.com/shakaran/scripts/blob/master/zerolog.sh

Por si alguien quiere hacer fork, modificarlo o en un futuro hago nuevas modificaciones. Esta licenciado bajo GPLv3.

Ejemplos de uso

Para usarlo, requiere ser administrador, ya que no todos los logs pueden borrarse como usuario regular.

Puede usarse como:

$ sudo ./zerolog.sh

Que borrará todos los logs rotados y vaciara existentes, ademas de crear un backup previo en el home del tipo logs-<FECHA>.tar.gz con la fecha actual de la ejecución. Por si quieres conservar los logs o decides restaurarlos por algún motivo.

Si quieres borrar sólo los más antiguos de X días, por ejemplo los más antiguos de hace una semana:

$ sudo ./zerolog.sh 7

Incluso puedes crearte un alias zlog:

$ alias zlog="sudo sh /ruta/zerolog.sh"

También puedes añadir el script como una tarea cron y que se ejecute a diario, por ejemplo:

$ sudo crontab -e

Y añadir:

0 0 * * * sh /ruta/zerolog.sh > /dev/null 2>&1

Por otro lado, si te importan poco tus logs o quieren guardar solo los más recientes, puedes optar por una opción más drástica como:

0 0 * * * find /var/log/ -type f -mtime +7 -exec rm -rf '{}' \; > /dev/null 2>&1