Mercurial, como ya vimos en la receta «Mercurial, por favor» es un sistema de control de versiones distribuido y demás info que podéis encontrar en los enlaces. En esta receta quiero explicar algo sobre el uso un poco más avanzado: los llamados hooks
Buenas... pues para aquellos que necesiten hacer un programita que mande notificaciones a alguien, puede usar alguno de los cientos de programas que existen por ahí... o puede hacer su propio notificador vía e-mail. En python es ultra sencillo y hay varios métodos, que yo conozca: conectar a un servidor SMTP, autenticarse y mandar el mensaje; o ser uno mismo el servidor y conectarse con un relay que te autorice (también soportado en python). En esta receta explicamos la primera, que es más simple (aunque también requiere tener la contraseña por algún lado, en el ejemplo la pediremos al usuario y listo...).
A cerca de Gmail
Bueno, este servidor, al igual que otros muchos por ahí, utiliza conexiones cifradas, por lo que mandar un correo nos obligará a establecer una conexión segura antes de autenticarnos (lo cual está muy requetebién y es muy sencillo).
Supongo que esta receta funcionará igual para todos aquellos servidores que requieran TLS puesto que cumple con la RFC 821 y la RFC 1869 (que alguien ponga los enlaces si quiere, yo voy con prisas :P).
Componer el mensaje
En python un mail es básicamente un diccionario cuyas keys son los nombres de los campos: Subject, Reply-To, etc... pero que además nos ofrece un par de métodos interesantes que nos permiten attach-ear imágenes y codificar todo el mensaje como mensaje MIME:
Mensaje de texto corriente y moliente
fromemail.MIMETextimportMIMETextmsg=MIMEText("Hello World,\no algo parecido...")msg['Subject']='Esto es una prueba'msg['From']="Juancar I"msg['Reply-to']="La casa ficticia"msg['To']="La Sofi"
Como dijimos antes, los campos se tratan igual que en un diccionario. Hay que tener en cuenta que no son obligatorios y que podemos falsear el origen y el destino del mismo, aunque para enviar el correo SI es necesario origen y destino reales, pero los datos que aparecerán en el correo al destinatario serán los que pongamos aquí. Tened cuidado con poner cosas demasiado "raras" o no rellenar suficientes campos porque entonces vuestro mail será considerado Spam casi con toda seguridad...
Mensaje con texto y fotos
Esto está sacado de la documentación de python y no lo he probado, pero en teoría funciona, si alguien me lo confirma pues mejor que mejor. Como dije antes, voy con prisa! :P
Aquí tenéis cómo enviar un mensaje con imágenes, podéis attachear cuantas imágenes queráis de la misma manera. Si queréis envíar sonidos o algún otro tipo de fichero, consultad la documentación de python porque se pueden componer cosas bastante chulas de forma similar (básicamente cambiar la clase MIMEImage por una más adecuada).
Conectar con el servidor SMTP
Asumimos aquí que tienes un objeto msg construído como anteriormente explicamos, pues bien, la cosa queda más o menos tal que así:
Y así de fácil es!
En este punto sabed que el origen y el destino deben ser auténticos, en caso contrario, el servidor de gmail nos dirá que hasta luego (y en el error nos da un bonito enlace con ayuda sobre su SMTP). Otra cosa más, si nuestro servidor utiliza algún tipo de certificado especial, se puede especificar en la función starttls().
Hace mucho tiempo los usuarios de madwifi contábamos con un driver maravilloso que nos permitía hacer casi cualquier cosa con nuestra tarjeta WiFi. El driver pasó al mainstream de Linux y de repente, en una aciaga versión 2.6.18 (o por ahí) el driver dejó de inyectar. Muchos pensábamos que sería cuestión de tiempo que reparasen este bug... versión tras versión no hemos podido volver a inyectar y en los foros sobre el driver nadie parece haberse dado cuenta... y eso es porque el driver internamentenunca dejó de inyectar. Esta receta explica cómo hacer que el driver funcione como antaño, cuando todos éramos felices inyectando.
El problema
Bueno, como decíamos en la introducción, el driver nunca dejó de inyectar, sin embargo, las aplicaciones que hacen uso de esta feature no funcionan o dicen que el chipset no es capaz de inyectar. ¿Cómo es esto posible?. Para responder a esta pregunta quizás primero debamos saber qué características tiene el driver y el tráfico wifi.
Estructura del driver
El driver tiene dos partes bien diferenciadas: capa MAC80211 o interfaz con el sistema operativo y capa ATH_HAL o interfaz con el hardware. Ambas capas tienen colas de envío y recepción. Los frames o paquetes recibidos por ATH_HAL son procesados y pasados a las colas de la capa MAC80211 si es necesario. Los paquetes envíados a la capa MAC80211 son tratados y depositados en las colas de la capa ATH_HAL para ser envíados por el hardware.
La inyección es tratada por la capa MAC80211, sin embargo, ATH_HAL no marca ese tráfico como lo hacía antiguamente. Éste es el motivo por el que ahora parece que no inyectamos tráfico.
Tráfico normal vs. Tráfico inyectado
Bueno, cuando nuestro driver trabaja con tráfico normal, la cola de envío en la capa MAC80211 no realiza un marcaje especial de los frames, lo que implica que todos los paquetes envíados esperarán su correspondiente ACK. La capa MAC puede configurar su cola de envío de forma que marque los frames para que no esperen respuesta. Éste método es el que se debe usar cuando la cola de envío esté en modo inyección. Y ésto es lo que actualmente se ha eliminado del driver: cuando la cola de envío está en modo inyección, los paquetes en ATH_HAL son tratados como tráfico corriente, cuando en realidad deberían marcarse como NO_ACK.
Actualmente lo que sucede es que los paquetes inyectados esperan ACK, pero jamás lo recibirán puesto que son inyectados. Por este motivo son descartados por el propio ATH_HAL. Para que sean procesados y enviados por ATH_HAL sin importar si llegan o no los ACK hay que marcar el tráfico como NO_ACK.
Dónde se marca el tráfico
Bueno, aquí depende del módulo que use nuestro chipset:
ath5k: echamos un vistazo a base.c del código fuente:
La función ath5k_txbuf_setup() configura la cola de envío (como su propio nombre indica) y, efectivamente, vemos que si la cola se configura como IEEE80211_TX_CTL_NO_ACK, añade AR5K_TXDESC_NOACK a los flags de envío. Sin embargo, no hace ningún cambio si la cola está en modo INJECTED.
ath9k: veamos el fichero xmit.c (nueva versión del ath5k con un código bastante más limpio):
staticintsetup_tx_flags(structath_softc*sc,structsk_buff*skb,structath_txq*txq){structieee80211_tx_info*tx_info=IEEE80211_SKB_CB(skb);intflags=0;flags|=ATH9K_TXDESC_CLRDMASK;/* needed for crypto errors */flags|=ATH9K_TXDESC_INTREQ;if(tx_info->flags&IEEE80211_TX_CTL_NO_ACK)flags|=ATH9K_TXDESC_NOACK;returnflags;}
Efectivamente, la función aquí es setup_tx_flags(), que retorna los flags que usará la capa ATH_HAL en su cola de envío. Al igual que antes, no hace nada especial si la cola de la capa MAC80211 se configuró como INJECTED.
Aplicar el parche (sin recompilar el Linux entero)
Ahora explicaremos como parchear el módulo en cuatro fáciles pasos, es un poco artesanal pero también más genérico (no voy a hacer parches para cada posible versión del driver :P).
Descarga del código fuente y preparación
Como ya dijeramos, los drivers madwifi pertenecen al mainstream de linux por lo que obtener los fuentes de forma separa puede no ser tan fácil como parece. En nuestro caso tenemos suerte y podemos descargar el paquete compat-wireless de Linux Wireless. Nos bajamos aquel cuya versión sea la más cercana a la de nuestro núcleo, en mi caso la 2.6.32:
Con esto habremos instalado los programas y paquetes necesarios para compilar módulos para nuestro núcleo.
Parcheado
ATENCIÓN: estas modificaciones parecen ser motivos de cuelgues en núcleos con versiones 2.6.27 y similares.
Antes disponíamos de parches oficiales de madwifi pero ahora no hay (o no los encuentro) así que a manita... según el módulo que use nuestro chipset (con lsmod podemos ver cuál es):
ath5k Modificamos la siguiente línea del fichero drivers/net/wireless/ath/ath5k/base.c:
Como véis, lo único que hacemos es añadir una condición más al if para marcar el tráfico como NO_ACK, y es que la cola esté configurada como INJECTED.
Compilación
Si todo lo anterio lo hicimos correctamente, la compilación es lo más sencillo:
ath5k:
$./scripts/driver-select ath5k
$make
ath9k:
$./scripts/driver-select ath9k
$make
Instalación
Bueno, el Makefile tiene el target install con lo que:
$sudo make install
debería funcionar a la perfección, sin embargo, yo he hecho la instalación manual que consiste básicamente (esto es para ath9k, para el módulo ath5k se hará igual... solo cambia un fichero...):
Descargar los modulos ath9k, ath, mac80211 y cfg80211 de memoria:
Terminados algunos de los juicios anti-monopolio de la innombrable (la antigua, no la nueva esa de la manzana) se han revelado algunos e-mails internos (de directivos y tal) donde Bilipuertas pide explicitamente cosas como:
Permitir que los documentos de Office se visualicen bien por los navegadores de otros es una de las cosas más destructivas que podemos hacer a la compañía. Debemos dejar de poner cualquier esfuerzo en esto y asegurarnos de que los documentos de Office dependan profundamente en las capacidades propietarias de Internet Explorer.
A. K. A. Cómo suplantar un servidor :P
Aunque suene un poco delictivo (o como les gusta llamarlo ahora, pirata), esto puede ser una buena solución para muchas situaciones; como crear "islas" dentro de una misma red, u ofrecer servicios adicionales.
REST es el acrónimo de REpresentational State Transfer. Dicen que es un «estilo arquitectural». Seguramente te has quedado como yo, pero es que no es fácil encontrar material para entender realmente de qué va esto. Aquí os dejo algunos enlaces:
