Planeta código

Desde hace poco tiempo me he picado con los podcasts sobre software libre. Son un buen método para estar informado y conocer qué se cuece en la comunidad. Y, desde hace algo más de mes y medio, algo se mueve en las comunidades y los podcasts. Algo llamado Maratón Linuxero.

El objetivo es hacer un evento de emisión en directo de ¡9 horas de duración! desde las 15:00 hasta las 24:00 (hora española, UTC+2), aunque puede que dure algo más. Vamos, para llegar con las pestañas pegadas al trabajo al día siguiente. Y todo utilizando software libre en la medida de lo posible.

El evento no está limitado sólo a que los oyentes escuchemos lo que los podcasters nos tengan que decir, es mucho más. Los oyentes podremos interactuar por Telegram, Twitter o Youtube, podremos conocer a bloguers, podcasters, youtubers dentro del mundo y la cultura y el software libre.

Pioneros en España

Este evento ya forma parte de la historia del software libre en España. Ya que es la primera vez que se hace una emisión en directo de tal duración utilizando exclusivamente software libre. Al menos, hasta el último punto, justo antes de la retransmisión. La retransmisión se hará por Youtube que, aunque no sea libre, cuenta con un buen servicio de directo y les dará una gran difusión. Al fin y al cabo, es lo que interesa.

Y ya que son 9h (mínimo) de audio, que es un montón, y puede que todos no podamos escuchar en directo todo el evento. Todos los audios quedarán grabados en Youtube y se subirán a varias plataformas de audio para poder volverlo a escuchar y descargarlo.

Podemos ver de qué va el tema escuchando los audios disponibles tanto en Youtube como en Archive.org. En estos audios, que son mayormente pruebas de audio, emisión, software y configuraciones se van presentando muchos de los podcasters y colaboradores así como dando ciertos adelantos sobre el evento.

Empresas colaboradoras

Aunque todo empieza con las ganas e ilusión de un grupo de podcasters, que ya tienen tablas en estos círculos. Varias empresas se han hecho eco del evento y han querido respaldar el proyecto. En concreto, Slimbook, PCUbuntu y Vant, por supuesto, algunos de sus productos se sortearán durante la emisión del 3 de septiembre. Aunque adelantan que habrá un sorteo en la última prueba. El 27 de agosto a las 15:00 (hora Española).

¿Qué podcasters participal?

15:00 – 16:00: Podcast Linux

Juan Febles, que está detrás de Podcast Linux, un podcast que lleva algo más de un año con nosotros y ya es como de la familia.

16:00-170:00: Eduardo Collado

Lleva el podcast eduardocollado.com donde habla sobre todo, de servidores y WordPress.

17:00-18:00: Yoyo Fernández

Con tilde, el Fernández. Que podía ser primo mío, pero no nos tocamos nada. Es uno de los veteranos del podcasting de habla hispana sobre GNU/Linux con Salmorejo Geek. Donde tenemos muchas días de audio sobre nuestro sistema operativo favorito y mucho más.

18:00-19:00: José GDF y DJ Mao Mix

Producción musical utilizando software libre.

19:00-20:00: KDE España Podcast

Porque KDE es mucho más que un entorno de escritorio. Un gran podcast para conocer el ecosistema KDE y mucho más.

20:00-21:00: Ubuntu y otras hierbas

Un podcast de reciente creación centrado en el mundo del software libre en general y de Ubuntu en particular.

21:00-22:00: Ugeek y Mosquetero web

Ugeek podcast, que nos brinda pequeños ficheros de audio que podemos devorar casi sin pensar sobre software libre, servicios web, Raspberry PI y muchísimo más.
Mosqueteroweb también tiene un gran podcast sobre tecnoogía y software libre.

22:00-23:00: Neoranger y Enderhe

Esperamos haber cenado en la hora anterior para escuchar a Neoranger de Neositelinux, autor de varios vídeos en Youtube sobre software libre y con un podcast recién estrenado hace poco tiempo.

Enderhe no lleva mucho tiempo en la comunidad podcast, pero seguro que nos dará su visión y punto de vista sobre el asunto

23:00-00:00: Paco Estrada

Terminamos con la voz del podcasting libre. Autor de compilando podcast, otro de los obligados.

¿Estás preparado?

Reserva ya ese día en tu agenda y déjate el día libre para participar en un evento histórico de la comunidad de software libre de habla hispana.

Más información

Tienes todos estos medios para interactura:

• Blog
• Telegram
• Twitter
• Correo
• Youtube
• Radio Maratón
• Feed Podcast Maratón Linuxero
• Audios en Archive.org

The post El domingo 3 de Septiembre tienes una cita. #MaratónLinuxero appeared first on Poesía Binaria.

Con el buscador Google y usando las palabras clave adecuadas es raro no encontrar información sobre aquello que estemos buscando. Pero en internet la información suele estar muy dispersa y en cada sitio la información no es completa y con profundidad, internet esta muy bien como apoyo o para precisar una determinada cuestión. Sin embargo, los libros siguen siendo un buen material de aprendizaje, entre sus ventajas está que la información está mejor organizada con una estructura más didáctica y dependiendo del libro el tema tratado es explicado con profundidad. Desde el 2014 son unos cuantos libros más los que he leído.

En internet hay cantidad de información que nos permiten aprender sobre cualquier cosa a nuestro libre albedrío y que queramos teniendo el tiempo para dedicárselo ya sea en forma de escuetas presentaciones en SpeakerDeck o SlideShare, páginas sobre temas de programación, artículos en bitácoras como esta que estás leyendo u otras, vídeos en YouTube, convenciones presenciales o hangouts.

Algunas páginas dedicadas a la programación relativa a Java y GNU/Linux a las que estoy suscrito son:

• JAXenter
• JavaWorld
• JavaMagazine
• VirtualJUG
• BSD Magazine
• LWN.net
• linux.com

En la biblioteca digital OpenLibra encontramos una gran cantidad de libros de diversos temas cuyas licencias permiten su libre acceso.

Podemos leer libros cuya información no está relacionada con un determinado herramienta técnica sino que su conocimiento es más generalista e independiente de la tecnología, en el artículo 8+ libros para mejorar como programadores recogía varios de los más mencionados y recomendados por mucha gente todavía válidos a pesar del tiempo transcurrido desde que fueron escritos, son atemporales. En la época que estaba en la universidad hace unos 15-20 años para mi internet aún estaba llegando, lo más parecido que tenía era la biblioteca en la que pedía prestados libros pero lógicamente con mayor limitación de material disponible. Hoy en día los alumnos, de universidad o bachillerato y gente con interés que quiera formarse mediante internet tiene acceso a material del que aprender mucho mejor en cantidad, facilidad y seguramente en calidad. A la gente que ahora está en la universidad le recomendaría que no se limiten a aprender lo que les enseñan en clases magistrales sus profesores sino que tomen parte activa en su formación aprovechándose de los recursos que pueden encontrar en internet.

Estos son los que me ha parecido que están bastante bien, algunos he leído de forma completa otros solo ciertos capítulos, algunos después de leídos olvidados en parte por falta de uso y porque mi inglés no es muy bueno. Son libros relacionados con la programación, la web o el lenguaje Java en su mayoría. Hay algún libro más que he leído pero estos son los que quería destacar. Además de aprender leer esta buena cantidad de libros me da ideas para escribir algunos artículos, algunos de los cuanles he incluído en este artículo como relacionados.

Libros sobre Java

Java 9 Modularity

La modularidad no es la única característica que se incorporará en Java 9 hay muchas otras pero quizá la que más llama la atención en parte porque estaba prevista ya para versiones anteriores y finalmente se ha postergado desde la versión 7. En cualquier caso la modularidad mejora la encapsulación, seguridad, rendimiento y compatibilidad con versiones futuras aspecto de la compatibilidad hacia atrás que siempre se la ha dado y es destacado en la plataforma Java.

Java 9 Modularity explica los cambios que afectan principalmente a algún nuevo archivo de código fuente para definir de forma explícita las dependencias que posee un módulo y los paquetes que exporta que definen su interfaz pública. También explica los cambios que afectan a comandos básicos como javac para compilar y java para ejecutar una aplicación. Hasta que los módulos se empiecen a adoptar por las librerías, y será lento, se explican los mecanismos para usar en Java 9 con módulos librerías de código que no hayan sido adaptadas aún.

Java 9 será publicado en septiembre y ya tengo ideados unos cuantos artículos para publicar.

Java Generics and Collections

Los tipos genéricos se añadieron en Java 5, en el año 2004, que el copilador utiliza para validar la corrección del código evitando problemas que serían producidos en tiempo de ejecución. En la API de colecciones se usa de forma extensiva.

El concepto no es difícil pero dominar las declaraciones de los generics no lo es, se puede complicar bastante. El libro Java Generics and Collections es antiguo pero no está anticuado y sigue tiendo plena validez hoy, explica porque los generics fueron implementados en Java como fueron implementados, las limitaciones que causa y las ponderaciones que realizaron sus desarrolladores.

• Tutorial sobre los tipos genéricos de Java

Cloud Native Java

La flexibilidad que aporta la computación en la nube (o en los ordenadores de otros como dice la FSF) es en gran medida su éxito. Los programas que adopten esta nueva arquitectura obtienen varias ventajas como escalabilidad, tolerancia a fallos o administración de automatizada. Sin embargo, las aplicaciones tiene que diseñarse o adaptarse a este nuevo entorno.

Algunas librerías como Spring Boot proporciona a las aplicaciones Java facilidades para desarrollar aplicaciones que se consideran nativas para la computación en la nube. Cloud Native Java hace un repaso a los factores a tener en cuenta en las aplicaciones.

Java The Good Parts

El lenguaje de programación Java es uno de los lenguajes más populares y que más desarrolladores posee desde ya muchos años. Su éxito se debe a varios principios que los arquitectos de la plataforma incorporaron desde sus inicios. Un lenguaje orientado a objetos, con excepciones para el tratamiento de errores, organización de clases en paquetes, recolector de basura que libera al programador de la tarea y evitar fugas de memoria o errores no controlados, la máquina virtual que posibilita escribir el código una vez y ejecutarlo en cualquier plataforma para la que haya una JVM, la gran documentación en javadoc que sirve como consulta y como formato para documentar en el propio código fuente, las colecciones que proporcionan estructuras de datos básicas y útiles para cualquier programa, concurrencia con hilos y primitivas para la sincronización y con el paso del tiempo un ecosistema muy grande de librerías, herramientas y entornos integrados de desarrollo.

Todas estas características se comentan detalladamente en Java The Good Parts.

Building Maintainable Software Java Edition

Hay conocimiento que es independiente del lenguaje que se utilice como tratar de escribir funciones o métodos con pocas líneas de código, mantener las interfaces pequeñas, separar en módulos, mantener el acoplamiento bajo y balanceados, que la base de código sea pequeña, automatizar las pruebas o escribir código limpio. Aunque Building Maintainable Software Java Edition es una edición para Java con los ejemplos en este lenguaje las motivaciones que describe de cada uno de los puntos anteriores es universal.

The Well-Grounded Java Developer

The Well-Grounded Java Developer diserta sobre varios conceptos a tener en cuenta para tener una base sólida sobre la plataforma Java. Nuevas características de Java 7, cosas vitales como inyección de dependencias, concurrencia, ficheros class y bytecode o lenguajes alternativos para la máquina virtual.

Spring Boot in Action

Spring Boot permite que una aplicación sea completamente autocontenida incluyendo un servidor web como Tomcat entre otros disponibles. En vez de distribuir la aplicación en formato war para ser desplegada en un contenedor de servlets o aplicaciones la aplicación se distribuye en formato jar y se inicia como una aplicación Java tradicional. Es la aplicación la que inicia el servidor web embebido y hace que proporcione su servicio. Esta es nueva tendencia que se sigue en las aplicaciones y en las aplicaciones basadas en la nube.

Spring Boot proporciona una integración con la parte del ecosistema de Spring que requiera la aplicación. Para nuevos proyectos Spring Boot in Action es muy interesante.

• Aplicación Java autocontenida con Spring Boot
• Información y métricas de la aplicación con Spring Boot Actuator
• Ejemplo de API REST en Java con JAX-RS y Spring Boot

Gradle in Action

Gradle es una herramienta de construcción de proyectos y gestión de dependencias que adopta las mejores características de Ant y Maven con pocas o ninguna de sus deficiencias. Gradle in Action explica en profundidad esta herramienta de construcción para llegar a dominarla.

• Herramienta de construcción Gradle
• Usar Gradle mediante Gradle wrapper
• Ejemplo de multiproyecto con Gradle
• Incluir información de la versión en el artefacto distribuible con Gradle
• Iniciar rápido un proyecto de Java con Gradle o de Spring con Spring Initializr

Java Testing with Spock

Las pruebas automatizadas son indispensables para escribir código con menos errores y con mayor calidad. En Java hay varias herramientas de testing para hacer pruebas unitarias, de integración o funcionales. Spock con el que se escriben especificaciones con un DSL y utilizando el lenguaje Groovy permite automatizar las indispensables pruebas de todo código. Java Testing with Spock explica esta herramienta.

Portlets in Action

Los portales son utilizados por algunas organizaciones para gestionar el contenido que publican en su web. Portlets in Action explica como crear las unidades básicas de los portales en Java, los portlets.

• Introducción a los portales y ejemplo de portlet con Liferay
• Portlets con el framework Apache Tapestry y Apache Pluto

Varios libros

Learning JavaScript

Learning JavaScript explica este lenguaje de programación utilizado en los navegadores web. Denostado a veces por falta de conocimiento el libro explica muchas cosas interesantes del lenguaje e incorporadas la versión de ECMAScript 6. Es un libro que no requiere gran conocimiento previo y empieza desde un nivel básico.

• Introducción al JavaScript de ECMAScript 6

The Book of CSS3

Al igual que JavaScript el denostado CSS también a veces lo es por el mismo motivo. The Book of CSS3 explica las nuevas posibilidades para aplicar estilos a documentos HTML en los navegadores. Media queries, selectores, psedo-clases y pseudo-elementos, web fonts, efectos y estilos de tipografías, disposiciones en múltiples columnas, imágenes de fondo, bordes y efectos de caja, color y opacidad, gradientes transoformaciones 3D, animaciones y transiciones, layouts, modos blend, filtros y máscaras es el contenido del libro.

Learning RabbitMQ y Mastering RabbitMQ

Los libros Learning RabbitMQ y Mastering RabbitMQ tratan sobre la herramienta RabbitMQ para desarrollar aplicaciones que se comuniquen mediante mensajes. Los mensajes son una forma efectiva de desacoplar dos aplicaciones tanto temporalmente como en el lenguaje utilizado en cada una de ellas.

• Ejemplo de RabbitMQ con Java para enviar y recibir mensajes

MongoDB in Action

La misión de las bases de datos es almacenar información para una posterior consulta o búsqueda. MongoDB in Action trata sobre la base de datos orientada a documentos MongoDB catalogada como NoSQL.

• Ejemplo de RabbitMQ con Java para enviar y recibir mensajes
• Usar la base de datos NoSQL MongoDB con Java

SQL Antipatterns

Aún con la popularización de las bases de datos NoSQL las bases de datos relacionales siguen siendo perfectamente válidas. El libro SQL Antipatterns es una colección de consejos a tener en cuenta al diseñar y utilizar las bases de datos relacionales. Algunas formas de uso que generan problemas están desaconsejados y se consideran antipatrones.

Beginning SQL Queries y Learning PostgreSQL

El lenguaje declarativo SQL es muy potente y yo al menos desconocía o he usado poco muchas cosas que se han añadido al lenguaje en versiones más modernas y que algunas bases de datos como PostgreSQL implementan. Algunas de estas cosas son las windows functions, tipos definidos por el usuario, triggers, common table expression o CTE, consultas recursivas, búsqueda de texto más avanzado y eficiente que la expresión like, lateral subqueries, …

Los libros Beginning SQL Queries y Learning PostgreSQL son una buena documentación sobre el lenguaje SQL que van más allá de lo enseñado en algunos cursos académicos.

CORS in Action

Cross-Origin Resource Sharing permite a sitios distintos del origen de la página proporcionar su contenido. Por defecto, los navegadores solo permiten hacer peticiones al mismo sitio del origen de la página, con una combinación del navegador y cabeceras en las peticiones que proporcionan los sitios web permiten hacer llamadas entre diferentes sitios manteniendo la seguridad. El libro CORS in Action trata en detalle este tema.

Microservice Architecture

El ámbito cloud y una nueva forma de arquitectura para las aplicaciones han originado los denominados microservicios. En vez de desarrollar una aplicación monolítica y grande se tiende hacia múltiples aplicaciones más pequeñas con un contexto específico que colaboran para proporcionar la misma funcionalidad. El libro Microservice Architecture trata las motivaciones, que valor aportan los microservicios así como sus principios y cultura.

Learning HTTP/2

La siguiente versión del protocolo HTTP mejora varios aspectos del anterior. Es más eficiente, con menos latencia, con mejor rendimiento mas seguro al requerirse una conexión cifrada y haciendo innecesarios varias técnicas que se usaban anteriormente. Learning HTTP/2 es un buen material para conocer las diferencias y los problemas que presentaba HTTP/1.

• Introducción al protocolo HTTP/2

Mastering OAuth 2.0

OAuth es un protocolo para proporcionar autenticación y autorización a un sitio o aplicación sin que el usuario le proporcione las credenciales. Una aplicación que requiera acceso aun tercero necesita obtener un bearer token que mediante un proceso de autorización se puede obtener de cuatro formas diferentes dependiendo de la aplicación y de si el dispositivo autorizado es de confianza o no. Matering OAuth 2.0 es una buena introducción.

• Autenticación con OAuth y Keycloak en un servicio REST con JAX-RS y Spring Boot
• Integrar autenticación OAuth con Keycloak, Shiro, Apache Tapestry y Spring Boot

Libros sobre Linux y DevOps

Git: Mastering Version Control

He leído varios libros sobre Git, muchos empiezan explicando como es la estructura de información que guarda Git, no es necesario empezar por ahí. El libro Git: Mastering Version Control es mucho más pragmático y explica muy bien los casos de uso que uno requiere de este sistema de control de versiones. Con este libro finalmente he aprendido mejor como usar un rebase interactivo para reescribir los commits o hacer un squash, también como crear alias y hooks, los diferentes modos de reset además de como crear commits, hacer búsquedas en el repositorio y otras muchas cosas que no he usado aún.

GitLab Cookbook

Como servidor de Git me gustan de GitLab dos cosas: que tiene una versión para la comunidad usable por ejemplo en un servidor propio de una empresa u organización y que tiene varias herramientas integradas como son una wiki, un sistema de tracking para las tareas de un proyecto junto con tableros y soporte para hacer integración y entrega continua sin necesidad de más herramientas lo que simplifica la infraestructura para el desarrollo en gran medida. También soporta otras características presentes en GitHub como merge request, revisiones entre pares o calidad de código entre otras muchas otras, la lista completa de features es grande. GitLab Cookbook es un libro introductorio para empezar a manejarlo.

Docker in Action y The DevOps 2.1 Toolkit

Docker y los contenedores junto con la computación en la nube han cambiado la forma de distribuir y desplegar las aplicaciones en los servidores. Docker es una gran herramienta muy interesante de conocer. Son varias las herramientas del ecosistema, Docker in Action explica docker y docker compose y The DevOps 2.1 Toolkit explica docker swarm para crear clusters de servidores.

• Serie de artículos sobre Docker

Ansible Up and Running y Implementing DevOps with Ansible 2

Ansible es una herramienta para automatizar tareas en una o múltiples máquinas locales o remotas. Otra de sus propiedades en la mayoría de los casos es que es idempotente, es decir, se pueden ejecutar las acciones múltiples veces aplicando los cambios pertinentes o no haciendo nada según el estado de la máquina y el estado deseado.

La herramienta es muy útil para tratar a los servidores siendo numerosos como ganado en vez de como mascotas y los libros Ansible Up and Running y Implementing DevOps with Ansible 2 lo explican.

• Introducción a Ansible

UNIX and Linux System Administration Handbook, Linux Administration A Beginner’s Guide y How Linux Works

UNIX and Linux System Administration Handbook es un libro que presenta al usuario los sistemas GNU/Linux, Linux Administration A Beginner’s Guide detalla las tareas administrativas para un servidor Linux y How Linux Works es un libro que explica detalles más profundos de aspectos internos de Linux.

Amazon Web Services in Action y Amazon Web Services For Dummies

Aún habiendo leído Amazon Web Services in Action y Amazon Web Services For Dummies como no he tenido la oportunidad de practicar con la nube de Amazon casi todo de lo que leí lo tengo olvidado. Amazon ofrece una capa gratuita para probarlo.

Publicaciones más breves

Esto ya no son libros sino documentos más pequeños sobre diferentes temas.

Guide to the Java Ecosystem 2015

Aun es la edición del 2015 y no he visto que hayan publicado una más reciente. Explica las tendencias y el ecosistema de Java. Microservicios, docker, Java 8, programación reactiva, mejores prácticas, …

Java The Legend

¿A que es debido el éxito de Java? El libro Java The Legend expone varios motivos como importancia de la compatibilidad hacia atrás, fácil de aprender y de leer, un sistema de tipos simple o la máquina virtual de Java o JVM. Aunque también según el documento con algunos fracasos como los Java Bean por promover la mutabilidad que es molesta para la concurrencia, la finalización de los objetos, sobre configuración de Java EE o la abstracción muy básica de hilos. Comenta el ecosistema alrededor de la plataforma Java con Eclipse, Apache y Spring junto con el futuro con Java 9, HTTP/2, JShell y quizá en un futuro el proyecto Panama para una nueva interfaz alternativa a JNI para código nativo y el proyecto Valhalla que trata sobre los tipos para usar cosas como definir colecciones genéricas con tipos primitivos.

The daemon, the GNU and the penguin

The daemon, the GNU and the penguin es un documento que repasa el origen, inicios y evolución del software libre y de código abierto desde el año 1968 con referencias a Unix, BSD, Minix, Sun, GPL, Hurd, la web, Tanenbaum, Torvalds, Linux, … Este documento y el siguiente son unos clásicos en internet.

La catedral y el bazar

La catedral y el bazar hace referencia a dos modelos distintos de desarrollo uno centralizado y controlado por una organización y otro distribuido de más libre albedrío pero también se ha demostrado muy efectivo posibilitado por la democratización de internet. La catedral y el bazar está traducido a varios idiomas entre ellos el español.

Para acabar este artículo, viendo la cantidad de libros que he leído en unos 3 o 4 años con el tiempo que supone dedicado a adquirir estos conocimientos en gran parte en el tiempo libre y que en general empleamos los que trabajamos en el sector tecnológico hay que hacerse valer a la hora de recibir o postular a una oferta de trabajo y me refiero al ámbito económico que en muchas ofertas de InfoJobs o Tecnoempleo no se corresponde con lo que supone los conocimientos que se solicitan.

Let’s Encrypt es una entidad que emite certificados TLS/SSL que son reconocidos como de confianza por los navegadores web. Usando esta entidad de certificación es posible obtener y renovar un certificado TLS/SSL de forma automatizada, rápida y sin coste alguno.

Google ha anunciado que su buscador va a considerar el uso del protocolo seguro HTTPS como un criterio de SEO y posicionamiento en la lista de resultados, posicionando mejor aquellas páginas web que usen el protocolo seguro. Además, el navegador Chrome va a advertir al usuario para algunas páginas que usen solo HTTP que esas páginas son inseguras. Por estos motivos y para mayor seguridad y privacidad del usuario es conveniente usar el protocolo seguro HTTPS.

El mayor inconveniente de usar el protocolo seguro HTTPS es que es necesario un certificado firmado por una autoridad de confianza instalada en el navegador del usuario. Hasta ahora había que comprar el certificado que puede llegar a tener un coste de más de 100€, instalarlo en el servidor y renovarlo antes de su fecha de expiración. Tareas quizá manuales por tanto tediosas y propensas a que surjan errores o se nos olvide hacer la renovación del certificado sobre todo si son múltiples los certificados a gestionar.

Para mejorar la seguridad en la web y facilitar la administración de certificados hace un tiempo se creó una entidad Let’s Encrypt asociado a la Linux Foundation con la que es posible automatizar la obtención y renovación de un certificado TLS/SSL firmado por una autoridad de confianza para los navegadores. Además Let’s Encrypt permite obtener un certificado sin ningún coste, de forma gratuita.

Los pasos para usar en un servidor web un certificado de Let’s Encrypt son los siguientes. Primero hay que instalar el paquete certbot según la distribución de GNU/Linux, en Arch Linux:

En el proceso de obtención del certificado demostraremos que somos los propietarios del sitio web a certificar. Usando nginx como servidor web, iniciado y el dominio a certificar con la opción -d se usa el siguiente comando:

El certificado obtenido tiene una fecha de expiración de únicamente tres meses periodo antes del cual hay que renovarlo. Para hacer la renovación hay que usar el comando:

La renovación del certificado se realiza cuando queda poco tiempo para que expire, unos 30 días, el siguiente comando permite comprobar antes si la configuración es correcta para realizar la renovación.

La clave privada y certificado que Let’s Encrypt genera una vez el dominio se ha validado se ubican en el directorio /etc/letsencrypt/live/ con una carpeta por cada dominio. También se puede ver desde la linea de comandos los certificados existentes y sus fechas de expiración.

Dado el relativo poco tiempo de validez de los certificados es recomendable automatizar la renovación empleando una expresión cron. La utilidad certbot solo hace la renovación del certificado cuando queda menos de un més para su expiración aunque se programe su ejecución en este caso cada 6 horas y en un minuto aleatorio que Let’s Encrypt recomienda para que todos los usuarios no programen sus renovaciones al mismo tiempo:

Una vez que se ha renovado el certificado hay que reiniciar el servidor web para que lo utilice y para ello está el parámetro –renew-hook que ejecuta un comando cuando se produce una renovación. En el ejemplo anterior está el comando para reiniciar el servicio de nginx con el sistema gestión de procesos de systemd.

Let’s Encrypt con certbot comprueba si somos el propietario de un sitio web instalando en el servidor web un archivo que posteriormente antes de generar el certificado lo valida. Este archivo para nginx se ubica en el directorio /usr/share/nginx/html/.well-known/acme-challenge/ y ha de estar accesible desde internet con el protocolo HTTP en la dirección /.well-known/acme-challenge/ del servidor web.

La siguiente configuración del servidor web nginx redirige todo el tráfico usando el procotolo HTTPS excepto el contenido del directorio /.well-known/acme-challenge/ que queda accesible por HTTP.

Y este es el resultado al acceder con el navegador al sitio web que tengo instalado en una Raspberry Pi accesible desde internet con un dominio de FreeDNS:

En la documentación del proyecto de Let’s Encrypt hay explicaciones más detalladas sobre como funciona, límites de uso, como usarlo y varias guías según el servidor web y distribución GNU/Linux.

Esta pequeña placa de apenas 24x14mm contiene un microcontrolador y chip WiFi a/b/g (esas de 2.4GHz) y una memoria. Además de algunos leds, una antena y un oscilador. Cuesta muy poco dinero (apenas unos 3€ comprándolo en algunas tiendas de España y mucho menos si se compra directamente a China). Y encima consume muy poco, alrededor de 0.5W a pleno rendimiento y muchísimo menos en alguno de sus modos de sueño y bajo consumo. Lo que hace que este circuito sea idóneo para trabajar con pilas o baterías, miniaturizar nuestros proyectos y automatismos así como conectarlos a Internet o a una red local.

Así de primeras, se me ocurren algunos proyectos, unos de ellos perversos y otros más normales. Entre ellos sistemas de automatización doméstica, lo típico encender y apagar enchufes desde el móvil, o programar para que se enciendan y apaguen y verificar el estado de los aparatos; estaciones meteorológicas a las que podemos acoplar decenas de sensores diferentes, avisadores de correo en el buzón, pequeños detectores de humo para zonas de no fumadores o para detectar que alguien se acerca a la puerta de la habitación; así como un pequeño keylogger que podemos camuflar dentro de un teclado, dispositivo USB que podrá hacer estragos y camuflar dentro de un ratón o para suplantar una WiFi y que los usuarios se conecten a ti (aunque no creo que soporte mucho ancho de banda con sacar la información que queremos y desconectar vamos sobrados).

Es cierto que hay versiones y chips más autónomos como es el caso del NodeMCU, que puedes programarlo en LUA o Python; o por ejemplo versiones más nuevas como el ESP8866-12 (para mis experimentos estoy utilizando el ESP8266-01), cuando yo lo compré me salía un poco más barato el ESP8266-01, además, lo quiero para un proyecto en el que cuanto más pequeño, mejor.

Estrenando el juguete

Pero por ahora estoy como un chaval con un juguete nuevo y quiero experimentar con él. Empezar a cacharrear y a descubrir sus posibilidades. Así que vamos a empezar conectándolo al ordenador a ver qué pasa. En principio, yo he utilizado un adaptador USB a puerto serie para poder enviar y recibir de la placa. Este adaptador (otros no lo hacen) tiene dos salidas VCC. Una a 5V proporcionada por el USB y otra a 3.3V después de pasar por un regulador de tensión. Y, como el ESP8266 trabaja a 3.3V, pongo una resistencia de 1KΩ entra la patilla de transmisión del adaptador y la patilla de recepción del ESP8266. En algunos adaptadores no hace falta, pero yo, sin esa resistencia no puedo comunicarme bien con el chip. No se me ha quemado, como dicen en muchos sitios, pero pasa de mi olímpicamente.

Aprovechar el adaptador USB de Arduino

Es otra opción si, como yo, eres de los que te pones a hacer este tipo de cosas a las 3 de la mañana y no tienes un adaptador a mano. Si tienes un Arduino cerca puedes probar hacer lo siguiente:

Así estarás utilizando la propia placa Arduino como conversor USB-TTL para nuestro ESP8266 ya que hemos puesto RESET a VCC, el chip Atmega no va a entrar en funcionamiento y todo lo que hablemos por el puerto serie lo estaremos aprovechando para nuestro ESP8266. Eso sí, dependiendo de la placa, la resistencia de 1KΩ ya no es necesaria. Además, yo en enlazado el RX de Arduino con el RX de la ESP8266 y el TX de uno con el TX del otro, mientras que con al conversor USB hacía lo contrario. Eso es por cómo está la placa etiquetada, si hacemos caso a las flechitas que hay dibujadas todo se entiende mejor.

Hablando con nuestro nuevo amigo

Lo tenemos todo listo para empezar a hacer algo con el chip. Así que vamos a hablar con él a través del puerto serie. Como está pensado para comunicarnos con otro microcontrolador (éste que se encargue de la comunicación y otro que haga el trabajo sucio), podemos enviarle comandos al chip y éste nos devolverá un resultado de la ejecución de dichos comandos. Así que lo podemos conectar sin problema a un Arduino (o un circuito basado en ATmega/ATtiny), un Raspberry PI, microcontroladores PIC o incluso una placa controladora de un móvil viejo si tenemos ganas de cacharrear. Aunque, por supuesto, el ESP8266 puede funcionar de manera autónoma.

El idioma que habla es el de los módems de toda la vida, tanto los de cable telefónico como los GSM. Bueno, no lo hablan todos los dispositivos, pero sí muchos de ellos, el lenguaje de comandos Hayes. Para mi gusto es un lenguaje muy imperativo (AT, viene de ATención) y serán comandos muy simples, y siempre con una respuesta cubriendo así todas las opciones que tiene nuestro chip. Así que vamos a conectar a un puerto USB nuestro ESP8266 y abrir un emulador de terminal. Podemos utilizar el mismo que viene con Arduino, aunque a mí me gusta más CuteCom. Aunque puedes utilizar GNU Screen si lo prefieres.
La conexión por defecto suele ser a 115200 baudios sin paridad y con CRLF como fin de línea (aunque a mí me funciona sólo con LF).

Hay algunos comandos que soportan las terminaciones _CUR y _DEF. Estas definiciones suelen afectar a la memoria interna del chip, ya que guardan valores de configuración. Estos pueden ser tratados sólo para la sesión actual (_CUR), por lo tanto cuando reiniciemos se perderá esa información; o pueden ser grabados de forma definitiva en el chip y recordados en futuras sesiones (_DEF). Esto nos permitirá por ejemplo conectar automáticamente con un punto de acceso o recordar la velocidad de conexión del puerto serie entre otras cosas.

Voy a hacer un resumen aquí de algunos comandos que podemos utilizar:

Comprobar el estado del chip

Sólo para saber que la comunicación se establece y que el chip está bien inicializado.

Si obtenemos un error aquí, puede deberse a:

• La inicialización no ha sido correcta. Se ha encontrado un problema al ejecutar el programa y todas las demás acciones se cancelan.
• La corriente de entrada no es estable. Tal vez haya habido alguna variación en la entrada y ha provocado un mal funcionamiento.
• El voltaje no es estable o tiene valores muy grandes o muy pequeños. Igual que antes, eso puede provocar un mal funcionamiento. Si le metemos 9V al chip sí que nos lo podemos cargar, pero si le introducimos 5V no se garantiza que el funcionamiento sea correcto. Lo mismo si le aplicamos menos de 3V.
• Error en el programa. Normalmente el firmware original está muy probado pero puede tener errores. Asimismo si probamos con otro firmware pueden pasar muchas cosas. ¡Pero estamos aquí para jugar y experimentar!
• La velocidad de nuestro terminal no es correcta. Es decir, que o nuestro ESP8266 o nuestro ordenador estén hablando a diferentes velocidades, lo que puede trabar la comunicación.
• ¡Cualquier cosa! En el mundo del HW y el SW todo puede fallar. Y te agradecería que pusieras un comentario para completar esta respuesta.
• Tu ESP8266 está muerto, Jim. Porque todo puede pasar.
• Tu conversor USB está muerto o, al menos, moribundo. Porque no siempre va a tener la culpa el mismo.
• Revisa tus cables. Me ha pasado muchas veces, cuando tienes muchos cables juntos, algunos valen, otros no valen, estás con la protoboard y no hacen buen contacto o realmente tus ojos te han traicionado. Si estás con una placa soldada revisa también tus soldaduras, puede que haya un problema. Si es problema de contactos tal vez sí hagan contacto pero no sea muy firme y fluctúe la corriente.

Reset del dispositivo

Cuando queremos reinicializar el chip cancelando conexiones y empezar de nuevo (también podríamos quitarle corriente y volver a aplicársela).

Restaurar valores de fábrica

Si queremos restaurar la configuración del chip como venía cuando lo compramos podemos ejecutar:

El chip se reiniciará cuando termine de reponer todos los valores.

Versión del firmware

Nos dará información básica de la versión, y su fecha. Nos ayudará para saber si podemos ejecutar ciertos comandos o saber si tenemos ciertas características. Podremos actualizar nuestro chip en el futuro si queremos.

Echo de comandos

Si queremos que al enviar un comando nos diga qué comando hemos enviado o no. Por ejemplo, si lo utilizamos con un Arduino, puede ser incómodo enviar un comando y recibir la respuesta de nuevo. Nos puede dificultar un poco el parseo de la misma.

La salida, debería ser un OK, aunque dado que hay un cambio de velocidad no vamos a ser capaces de captar ese OK. A partir de este momento podremos conectar a 9600 baudios.
Si lo vamos a conectar con un Arduino la velocidad de 9600 puede ser más que suficiente si sólo vamos a enviar/recibir datos de control. Por ejemplo, estados de dispositivo, temperaturas, etc y luego que el ESP8266 se encargue de generar una respuesta web por ejemplo y la envíe por la red.

Antiguamente había un comando AT+CIOBAUD con el que podíamos consultar la velocidad actual. Aunque no tiene mucho sentido ya que hemos tenido que establecer dicha velocidad para hacer la conexión. Así que con AT+IPR sólo podemos definir una velocidad nueva.
Atención. AT+IPR define la velocidad que le digamos. Eso es, que si no es una velocidad estándar, lo va a aceptar y el chip empezará a funcionar o malfuncionar a esa velocidad y puede que no podamos acceder a él hasta que flasheemos de nuevo el firmware. No es un brickeo completo, pero un pequeño error nos puede amargar un buen rato de trabajo.

Dato que este comando es peligroso, en versiones más nuevas del firmware se incluye AT+UART_CUR y AT+UART_DEF en donde podemos modificar los bits de parada, comprobación de paridad y algunas cosas más.

Cambiar modo WiFi

El WiFi del ESP8266 puede funcionar de varias maneras:

1. STA – Modo estación. Es decir, el chip se conecta a un punto de acceso.
2. AP – Punto de acceso. Para que los dispositivos se conecten a nosotros.
3. STA+AP – Lo mejor de los dos mundos.

Ahora bien, podemos consultar cómo está funcionando el dispositivo y también definir el modo de funcionamiento. Este modo se mantendrá después del reset. Incluso tras la perdida de energía.

Listar redes WiFi disponibles

Sólo podremos listar las redes visibles si estamos en modo STA o STA+AP. Si sólo estamos como AP nos devolverá ERROR.

Veremos una lista de las redes (así conocéis a mis vecinos un poco. Además vemos más información como:

• Seguridad de la red:
  • 0 – Open. Red abierta.
  • 1 – WEP
  • 2 – WPA_PSK
  • 3 – WPA2_PSK
  • 4 – WPA_WPA2_PSK
• SSID. O nombre de la red.
• RSSI. Fuerza de la señal.
• MAC. Dirección MAC del punto de acceso.
• CH. Canal.
• freq. offset. Offset del punto de acceso en KHz
• freq. calibration. Calibración para el offset anterior.

Si queremos personalizar esta salida podremos utilizar algo como:

En este caso ordenará las redes de la salida por su intensidad de señal (el primer valor, 0 si no queremos ordenarlas). Y mostrará todos los datos (el segundo valor es una máscara de bits que activa o desactiva cada uno de los valores de la salida).
Por ejemplo AT+CWLAPOPT=1,7 ordenará las redes por SSID y mostrará los valores de seguridad, ssid e intensidad de señal solamente.

Conectarse a una red WiFi

¡Vamos a hacer algo de provecho! Conectémonos a una red. Primero, elegiremos si vamos a tener activo DHCP o no, para que nuestro dispositivo coja una dirección IP automáticamente (Si el router no lo soporta, olvidémonos):

Con esto decimos que en el modo 1 (Station) ponemos DHCP a 0. Si quisiéramos hacerlo con el modo AP sería el modo 0. Y si queremos activar o desactivar ambos modos a la vez, pondremos modo2.

Si utilizamos DHCP, ya tenemos que tener dirección IP. Pero si queremos configurar una IP estática haremos:

Donde la primera dirección es la dirección IP del dispositivo, el segundo es la puerta de enlace y el tercero la máscara de subred. Los dos últimos valores no es obligatorio especificarlos para el ESP8266, pero tal vez sí lo sea para tu red. Y luego cuando consultemos nuestra dirección IP:

Las DNS a utilizar se obtienen o bien del router (por DHCP) o se establece OpenDNS (208.67.222.222). En versiones antiguas como la mía no se permite cambiar esta información, aunque en versiones nuevas se puede hacer AT+CIPDNS=1,dns_server

Y cuando queramos desconectar…

Otra forma de mirar la IP es utilizar:

Resolver un dominio

Un dominio debe ser resuelto a una dirección IP antes de conectarnos hacia él. Aunque podemos conectarnos a través del nombre de dominio, para probar que todo está bien podemos pedir la información de la resolución del nombre. Internamente se contactará con el servidor de nombres para obtener el valor:

Ping a un servidor

Con esto sabemos cuánto tarda en responder un host. Lo podemos hacer tanto por IP como por dominio:

Google ha tardado en contestar 14ms.

Conectar con un servidor web

Vamos a poner vamos comandos con el fin de descargar contenido de un servidor web.

• Primero con CIPMUX diremos que vamos a soportar múltiples conexiones, Porque nosotros lo valemos.
• Luego iniciamos una conexión (le damos 2 como identificador, por ejemplo)
• Tras ello iniciamos un envío de datos por la conexión 2 de 61 bytes
• Una vez aceptada, enviamos la información.
• Ahora recibimos la información del servidor.

La conexión la vamos a hacer al servicio ifconfig.me, para saber cuál es nuestra IP remota en Internet. Veamos los comandos

Como la conexión se cierra sola no hacemos nada más, pero si queremos cerrarla manualmente podemos hacer:

Si queremos hacerlo rápido, ya que muchos servidores HTTP requieren velocidad a la hora de pedirles información porque tienen timeouts muy ajustados, podemos hacer un script como este:

Como vemos, en la línea de CIPSTART especificamos el ID de conexión, el tipo de conexión que puede ser TCP, UDP o SSL (bien por la seguridad, aunque la pondremos algo a prueba), el host o IP con el que contactar y el puerto. Y luego para CIPSEND especificaremos el ID de conexión y el tamaño de los datos a enviar, cuando recibamos el OK con el prompt (petición de información) procedemos a enviar los datos en bruto. Se leerán tantos bytes como hayamos puesto en el tamaño.

Actualización del Firmware por WiFi

Este chip soporta auto-actualización del propio software del chip si lo conectamos a una red inalámbrica de la siguiente manera:

Tarda un rato en actualizar y tal vez tengamos un problema en nuestros dispositivos por temas de memoria. Sobre todo porque el chip viene con poco espacio de almacenamiento y los nuevos firmwares son mucho más grandes.:

1. Encontrar el servidor
2. Conectar
3. Descargar el software
4. Actualizar!!

¿Hay más?

Por supuesto tenemos más comandos soportados en viejas y nuevas versiones del firmware. He sacado sobre todo comandos de conexión a un punto de acceso y conexión como cliente aunque también podemos ser un punto de acceso y crear un servidor. Además de los modos de sueño y bajo consumo de los que quiero investigar un poco más. Aunque lo dejo para futuros posts. De todas formas, podemos ver la referencia de comandos AT del ESP8266.

El primero de muchos

Este cacharro me ha encantado, así que le dedicaré algunos posts más a los nuevos descubrimientos que haga con él. Lo próximo será programarlo y tengo muchas ideas para poner en práctica.

The post Trasteando con juguetes nuevos. Primeros pasos con el ESP8266 appeared first on Poesía Binaria.

El esperado Iron Marines ya tiene fecha de lanzamiento: va a estar disponible en las respectivas tiendas de Android e iOS a partir del 14 de setiembre.

De los creadores de Kingdom Rush, Kingdom Rush: Frontiers y Kingdom Rush: Origins – Ironhide Game Studio – llega una nueva saga. Un juego de estrategia en tiempo real en planetas desconocidos. Los marines van a ser los soldados protagonistas de la aventura junto a mechas y alienígenas de todo tipo. Al estilo de los queridos RTS de siempre, tendremos que armar y proteger una base con defensas fijas y estar a la ofensiva con nuestras unidades.

De la saga Kingdom Rush se mantiene el concepto de los héroes, esta vez a un nivel galáctico, pero que tanto por su carisma como sus distintos poderes ofensivos y defensivos aportan mucho a la batalla. Las tropas pueden cambiar de rol de explorador a francotirados, de lanzallamas a lanzacohetes. También hay ataques especiales como bombas, minas, tropas de soporte, torres y armas especiales. El universo Iron Marines está habitado por ejércitos de robots, naves espaciales estrelladas, monstruos gigantes, razas desconocidas, rescates, sabotajes, y más.

Cuenta con 14 misiones en campaña a través de dos mundos. Distintos escenarios que requieren distintas tácticas y acciones. Incluye además 10 “Operaciones especiales” con sus reglas de combate propias, prometen ser desafíos importantes. Para los más valientes se puede desbloquear el Modo Imposible, imagino que o con limitaciones de armas o mareas infinitas de enemigos a destruir.

No pueden faltar los jefes que prometen ser enormes y únicos, pero particularmente enormes. Hay más de 40 actualizaciones para mejorar la estrategia en nuestras unidades, desde drones de defensa, cohetes de napalm, explosiones que rebotan y más. Qué lindo sacarse las ganas de usar cohetes de napalm.

En un principio hay una selección de 9 héroes que debemos ir entrenando, aunque mencionan también que podemos “molestarlos a nuestro propio riesgo”, capaz que sugiriendo un nuevo tipo de relación con ellos. Hay al menos 8 armas especiales, y más de 50 “Achievements”. Cuenta con 3 niveles de dificultad: Casual, Normal o Veterano. Si bien no han comentado nada, conociendo al estudio no sería muy loco esperar expansiones en el futuro, veremos qué guarda Ironhide bajo la manga…

Anteriormente ya habían mencionado la intención de llevar el título a Steam en Linux, Mac OS y Windows, así como lo hizo con los primeros dos títulos de Kingdom Rush (y que tantas horas les dediqué). Habrá que esperar a ver si podremos disfrutarlo también en PC, aunque ya que soñar es gratis, qué genial sería una versión para Nintendo Switch

Los Kingdom Rush han tenido un éxito gigante, y merecido. Se nota la atención al detalle y el amor por las series a las que hacen homenaje en varias ocasiones. Tengo mucha expectativa con Iron Marines y espero poder jugarlo pronto. Probablemente sea el segundo juego que compre en la tienda de aplicaciones de Android (el primero fue KR: Frontiers), no suelo jugar mucho en Android.

Estén atentos al Twitter de Ironhide y el sitio web de Iron Marines, porque se vienen cosas interesantes. Les dejo con el trailer oficial de Iron Marines:

 

De TASM, Turbo Assembler, recuerdo una directiva que me encantaba, era SMART, y la agregaba a todos mis programas, porque increíblemente, no se podía activar desde la linea de comandos. El modo SMART, realizaba ciertas optimizaciones sobre el código ensamblador, por ejemplo era capaz de convertir algo como: shr ax, 2 En: shr ax, 1 […]

Artículo publicado originalmente en Bitácora de Javier Gutiérrez Chamorro (Guti)

La entrada smart.inc aparece primero en Bitácora de Javier Gutiérrez Chamorro (Guti).

Java es un lenguaje más verboso y con menos azúcar sintáctico (o veneno para ratas, según se mire) que otros lenguajes. Esto hace que por ejemplo para declarar e inicializar objetos tan comunes en un programa de tipo Map, List o Set que contengan un número fijo de elementos haya que escribir varias líneas de código. Estas clases de estructuras de datos del grupo de colecciones son de las más usadas en una aplicación Java. A la fecha de escribir este artículo Java no soporta literales para las colecciones que reduzca las lineas de código para inicializarlas y mejore la legibilidad del código aunque en versiones recientes si se han incorporado métodos de utilidad que cubren el requerimiento.

Con el objetivo de reducir la verbosidad quizá en algún sitio se pueda ver que usando la técnica de doble llave se puede inicializar un Map o List de una forma más reducida, tal que:

Sin embargo, no es recomendable usar este hack del lenguaje porque presenta sus inconvenientes, por ello está desaconsejado y se considera un antipatrón. En el pozo de sabiduría para el programador de StackOverflow se indican varios inconvenientes:

• Cada bloque de inicialización con doble llave crea una clase anónima que incrementa el número de clases de la aplicación y que puede penalizar el rendimiento si se usa de forma extensiva en una aplicación.
• Si se retorna un mapa inicializado de esta forma desde un método el mapa tendrá una referencia al objeto que lo creo, lo que evita que el objeto sea destruido por el recolector de basura hasta que no se recolecte el mapa creando una potencial fuga de memoria.

En otros hilos de StackOverflow algunas respuestas muy votadas se propone usar dobles llaves para la inicialización, pero por los puntos comentados anteriormente mejor no usarla por mucho que esté en StackOverflow y haya sido esta una respuesta muy votada.

Las alternativas en Java 8 en el caso del Map si queremos reducir la verbosidad al inicializar estos tipos de datos usados profusamente podemos usar lo siguiente, en el caso de List o Set disponemos desde hace más tiempo del método Arrays.asList:

En Java 9 aunque aún no se incorporen la definición de literales al lenguaje con los métodos de utilidad of en su respectivas interfaces gracias a los defaults methods el código se simplifica en gran medida.

Java es un lenguaje más verboso y con menos azúcar sintáctico (o veneno para ratas, según se mire) que otros lenguajes. Esto hace que por ejemplo para declarar e inicializar objetos tan comunes en un programa de tipo Map, List o Set que contengan un número fijo de elementos haya que escribir varias líneas de código. Estas clases de estructuras de datos del grupo de colecciones son de las más usadas en una aplicación Java. A la fecha de escribir este artículo Java no soporta literales para las colecciones que reduzca las lineas de código para inicializarlas y mejore la legibilidad del código aunque en versiones recientes si se han incorporado métodos de utilidad que cubren el requerimiento.

Con el objetivo de reducir la verbosidad quizá en algún sitio se pueda ver que usando la técnica de doble llave se puede inicializar un Map o List de una forma más reducida, tal que:

Sin embargo, no es recomendable usar este hack del lenguaje porque presenta sus inconvenientes, por ello está desaconsejado y se considera un antipatrón. En el pozo de sabiduría para el programador de StackOverflow se indican varios inconvenientes:

• Cada bloque de inicialización con doble llave crea una clase anónima que incrementa el número de clases de la aplicación y que puede penalizar el rendimiento si se usa de forma extensiva en una aplicación.
• Si se retorna un mapa inicializado de esta forma desde un método el mapa tendrá una referencia al objeto que lo creo, lo que evita que el objeto sea destruido por el recolector de basura hasta que no se recolecte el mapa creando una potencial fuga de memoria.

En otros hilos de StackOverflow algunas respuestas muy votadas se propone usar dobles llaves para la inicialización, pero por los puntos comentados anteriormente mejor no usarla por mucho que esté en StackOverflow y haya sido esta una respuesta muy votada.

Las alternativas en Java 8 en el caso del Map si queremos reducir la verbosidad al inicializar estos tipos de datos usados profusamente podemos usar lo siguiente, en el caso de List o Set disponemos desde hace más tiempo del método Arrays.asList:

En Java 9 aunque aún no se incorporen la definición de literales al lenguaje con los métodos de utilidad of en su respectivas interfaces gracias a los defaults methods el código se simplifica en gran medida.

Un Arduino, ¡es muy grande! Es una placa que luego no sabes dónde meter, un circuito integrado que ocupa mucho y en algunas ocasiones no usamos la miad de las entradas y salidas. Así que, para pequeños montajes que requieran algo de lógica de programación o comunicación que debamos meter en una pequeña placa sin complicarnos mucho la vida, y hemos trabajado antes con la plataforma Arduino. Un buen siguiente paso es comprar un pequeño ATtiny, un circuito integrado que cuesta alrededor de 2€. Ya que tiramos de ATtiny, vamos a dedicarnos al ATtiny84 y ATtiny85 que son los más grandes de la gama.

ATtiny85

Este circuito cuenta con:

• 8 patillas
• Funciona desde 1.8V a 5V
• 300uA a 1MHz y 1.8V
• Frecuencia de operación de 20MHz como máximo si utilizamos un oscilador externo. Aunque puede funcionar entre 1MHz y 8MHz con el propio oscilador interno. Ideal para operaciones de bajo consumo.
• 8KB de memoria Flash para nuestros programas.
• 512bytes de EEPROM para almacenar constantes o valores de forma permanente. EEPROM es una memoria de escritura limitada, así que no es conveniente para almacenar datos que vayan cambiando mucho.
• 0.5Kb de SRAM. Como memoria temporal para nuestros programas.
• 6 canales GPIO, para interactuar con el exterior.
• 4 de ellos soportan entrada analógica a través de un conversor analógico-digital de 10bit.
• 5 de ellos soportan PWM

Y muchas más cosas que iremos descubriendo y experimentando.

ATtiny84

Este circuito cuenta con:

• 14 patillas
• Funciona desde 1.8V a 5V
• 300uA a 1MHz y 1.8V
• Frecuencia de operación de 20MHz como máximo si utilizamos un oscilador externo. Aunque puede funcionar entre 1MHz y 8MHz con el propio oscilador interno. Ideal para operaciones de bajo consumo.
• 8KB de memoria Flash para nuestros programas.
• 512bytes de EEPROM para almacenar constantes o valores de forma permanente. EEPROM es una memoria de escritura limitada, así que no es conveniente para almacenar datos que vayan cambiando mucho.
• 0.5Kb de SRAM. Como memoria temporal para nuestros programas.
• 12 canales GPIO, para interactuar con el exterior.
• 8 de ellos soportan entrada analógica a través de un conversor analógico-digital de 10bit.
• 4 de ellos soportan PWM

Configurando el entorno Arduino

El método más sencillo para hacer la programación es con el entorno Arduino, que a estas alturas de 2017 va por la versión 1.8.3 y tiene muchas cosas más que cuando empecé. Así que vamos a configurar nuestro entorno para que soporte los chips ATtiny. Para ello vamos a Archivo / Preferencias y en la línea Gestor de URLs adicionales de tarjetas pegamos la siguiente dirección: https://raw.githubusercontent.com/damellis/attiny/ide-1.6.x-boards-manager/package_damellis_attiny_index.json:

Ahora bien. Para relizar la programación del circuito integrado, voy a utilizar mi propia placa Arduino. Por lo tanto voy a instalar un programador en mi Arduino que se encargará de escribir la memoria del ATtiny. Para ello, seleccionamos nuestro Arduino, el puerto donde está conectado y seleccionamos Archivo / Ejemplos / ArduinoISP. Una vez abierto el programa lo subimos a nuestra placa Arduino.

Seguidamente vamos a Herramientas / Placa / Gestor de tarjetas, nos aparecerá una ventana como la siguiente, donde podemos escribir attiny en la barra de búsqueda. Nos aparecerá la configuración para incluir estos circuitos integrados a nuestro entorno Arduino. Así que seleccionamos la última versión y pulsamos Instalar:

Ahora podremos seleccionar nuestro ATtiny en Herramientas / Placa / ATtiny. Para este ejemplo vamos a programar un ATtiny85, aunque colocando los cables correctamente podremos programar también los ATtiny84 o incluso los Atmega.

Ahora seleccionamos el resto de opciones dentro de herramientas:

• Procesador. Donde especificamos el chip que vamos a programar.
• Clock. Donde decimos la velocidad de reloj. Estos ATtiny tienen un reloj interno que puede ir hasta los 8MHz, aunque parece que con algunos modelos puede llegar hasta 16MHz, aunque a mayor frecuencia, mayor consumo eléctrico. Además, estos chips soportan una fuente de reloj externa hasta 20MHz.
• Puerto. Mi USB está en /dev/ttyUSBx (con la placa Duemilanove) o en /dev/ttyACMx (con Arduino Uno), usando GNU/Linux. O tal vez en otros sistemas COM3/COM4… ya depende de cómo esté enchufado el dispositivo.
• Programador: Arduiono as ISP. Le estamos diciendo que el propio Arduino va a actuar como programador del chip.

Montando el circuito para programar nuestro ATtiny

Debemos montar algo así:

En este circuito conectamos los pins:

Arduino PIN 10 –> ATTiny Reset PIN
Arduino PIN 11 –> ATTiny PIN 0
Arduino PIN 12 –> ATTiny PIN 1
Arduino PIN 13 –> ATTiny PIN 2
Arduino GND PIN –> ATTiny PIN GND PIN
Arduino +5V PIN –> ATTiny PIN VCC PIN

Los diodos led, los he conectado como indicación (no es necesario tenerlos, y me podéis matar por no colocar resistencias, pero están muy chulos):

• PIN 9 – Es el heartbeat. Indica que nuestra placa Arduino como programador funciona y está lista
• PIN 8 – Error.
• PIN 7 – El programador se está comunicando con el ATtiny

NOTA: En las placas Leonardo, Yun y seguro que algunas otras utilizan el puerto ICSP para realizar la programación del chip. Como se indica a continuación (aunque no lo he probado. Si alguien se atreve que me deje un comentario):

Arduino PIN 10 –> ATTiny Reset PIN
Arduino ICSP MOSI PIN –> ATTiny PIN 0
Arduino ICSP MISO PIN –> ATTiny PIN 1
Arduino ICSP SCK PIN –> ATTiny PIN 2
Arduino GND PIN –> ATTiny PIN GND PIN
Arduino +5V PIN –> ATTiny PIN VCC PIN

El condensador entre RESET y GND evita que Arduino se reinicie actuando como ISP. De todas formas muchas veces no es necesario poner el condensador. Depende de la placa que estemos usando. Si no tenéis ninguno a mano, intentadlo sin él.

Programando el chip

Lo primero será cargar un programa, como por ejemplo el Blinking Led, ese ejemplo típico, aunque por defecto el led suele estar conectado al Pin13, y en Attiny no tenemos tantos, así que podemos conectarlo al 0 o al 1 para hacer la prueba. O si no, podemos utilizar mi versión modificada que utiliza la salida analógica, ya que el Pin 0 del Attiny85 soporta PWM, vamos a hacer algo con él:

Programando ATtiny84

Para programar este circuito, tendremos que conectar nuestra placa Arduino al chip. Para ello, debemos conectar VCC, GND y reset a los sitios correspondientes, y luego los pins MOSI, MISO y SCK. De la siguiente forma:

Arduino PIN 10 –> ATTiny Reset PIN
Arduino PIN 11 –> ATTiny PIN 7
Arduino PIN 12 –> ATTiny PIN 8
Arduino PIN 13 –> ATTiny PIN 9
Arduino GND PIN –> ATTiny PIN GND PIN
Arduino +5V PIN –> ATTiny PIN VCC PIN

Ahora, con nuestro ATtiny conectado, le damos a Subir y listo! Se compilará y se subirá a nuestra placa.

Foto principal: Uwe Herman (Flickr CC)

The post Programando ATtinys para miniaturizar nuestros proyectos electrónicos appeared first on Poesía Binaria.

Normalmente el control de los ventiladores que hace automáticamente el sistema está bien. Cuando la CPU se calienta mucho los ventiladores aumentan su velocidad y ésta disminuye cuando se enfrían. El objetivo es mantener el procesador a una temperatura estable y que no se rompan los componentes. Porque seguro que más de uno nos hemos cargado algún aparato cuando se ha sobrecalentado.

El caso es que no siempre está bien el control automático. Bien porque alguna vez se le puede ir la olla, por tema de drivers en ocasiones un ventilador se vuelve loco; puede haberse roto el sensor de temperatura, porque todo se puede romper, y nosotros nos resistimos a cambiar el equipo; estamos experimentando rompiendo cosas, queremos ponerlo a tope un rato para aumentar el rendimiento general a pesar de que haya mayor consumo energético, o puede que lo principal sea dejarnos dormir y no nos importa que se caliente la CPU un poco.

He de decir, que los ventiladores que podemos controlar son los que están conectados a un dispositivo capaz de gestionar una señal PWM. Sí, como la de Arduino, es la misma tecnología, enviamos pulsos a un ventilador para que varíe su velocidad. Y podemos encontrar varios puertos PWM para ventiladores en nuestras placas base, aunque en los portátiles normalmente tenemos sólo uno; en los ordenadores de sobremesa podemos encontrar más ventiladores y ahí está mucho más chulo hacerlo.

Ya lo tenemos hecho!!

Existe un software llamado fancontrol que lo hace por nosotros. Le decimos temperaturas y velocidades de ventilador y automáticamente cada cierto tiempo hará un sondeo en los sensores de temperatura y actuará en consecuencia.

Pero, ¿cómo se hace a mano?

Pero, ¿y si queremos cambiar la velocidad del ventilador a mano? Por ejemplo, para hacer algo rápido, porque no siempre podemos o queremos instalar un paquete en un equipo. Y, como la magia de GNU/Linux está en que casi casi todo son ficheros nos aprovecharemos de eso.

Antes de nada, debemos saber que todo esto depende mucho del driver que utilice nuestro sistema para gestionar esta capacidad. Es decir, el circuito que controla la velocidad de los ventiladores necesita un módulo específico en el kernel y puede que éste cambie un poco la forma de acceso, suele ser parecida, pero a lo mejor cambian un poco los nombres. También puede que no tengamos dicho soporte en nuestro kernel, o que nuestra placa base sea incapaz de hacerlo… todo puede pasar, pero para eso estamos, para investigar

Buscar ficheros importantes

Me voy a basar en la forma de encontrar la temperatura actual (los sensores) y modificar la velocidad de los ventiladores. Así que vamos a ello. En los kernels más antiguos podíamos encontrar todo esto dentro de /proc/acpi/ aunque en los núcleos más modernos lo encontramos en /sys/devices/. Así que, hagamos las búsquedas, pondré los resultados que salen en mi equipo principal, no tiene por qué coincidir con el tuyo, pero sí puede ser parecido.

El primer fichero será temp1_input que nos dice la temperatura del sensor, seguramente sea el sensor de la CPU, aunque podemos tener más sensores repartidos por la placa base. (Generalmente podremos acceder desde /sys/class/hwmon/, en mi sistema tengo enlaces desde /sys/class/hwmon/hwmonX que apuntan a las rutas a continuación; pero otras veces no)

Podemos encontrar varios ficheros parecidos, correspondientes a cada uno de los drivers y a veces puede coincidir que el mismo sensor sea leído por dos drivers distintos. Estos ficheros, al final, podemos leerlos con cat. Por ejemplo:

Pues eso, 52ºC

Generalmente estos ficheros suelen tener en el mismo directorio los ficheros temp1_label, temp1_max, temp1_crit especificando, qué sensor es, su temperatura máxima y crítica respectivamente. Y todos los valores podemos verlos con cat, aunque puede que en algunos sistemas necesitemos privilegios de root.

Si queremos, también podemos mirar en el mismo directorio qué más hay, puede que encontremos más sensores, temp2_input, temp3_input, etc.

Ventiladores

Dentro de /sys/class/hwmon/hwmonX/ también puede que encontremos ficheros llamados fan1_input, fan1_label (que nos dirá qué ventilador es), pwm1 o de forma general, dependiendo de la cantidad que haya fanX_input y pwmX. De todoas formas, si queremos buscarlos, aquí os dejo el comando:

Qué podemos hacer

Hemos visto que podemos ver la temperatura del sensor haciendo cat al fichero. También podemos ver información de los ventiladores:

En este caso vemos la velocidad en revoluciones por minuto (rpm) del ventilador, y también a qué corresponde el ventilador, que es el ventilador de la CPU.

Ahora vemos qué hacen los ficheros PWM

El primero es el modo de funcionamiento, puede ser 1 (manual) o 2 (automático). Se puede utilizar el 0 pero suele ser lo mismo que el 2. Además, no hace falta establecer este valor antes de cambiar a modo maunal. Lo veremos en un ejemplo más adelante.
El segundo es la velocidad del ventilador expresado con el valor del byte que controla el PWM. Es decir, un valor entre 0 y 255 donde 0 es el mínimo (ventilador parado, y por tanto, muy peligroso) y 255 es el máximo, por lo que nuestro ordenador puede parecer un cohete espacial. Ahora, si queremos dar una velocidad a mano al motor haremos:

Si somos root, pero si lo hacemos desde un usuario, podremos hacer:

De esta forma se establecerán los valores de pwm1_enable a 1 (no tenemos que hacer nada para ir a modo manual) y el valor de pwm1 será de 120. Además, escucharemos el ventilador de nuestro ordenador más rápido. Eso sí, tenemos que tener cuidado cuando demos una velocidad manual, ya que el modo automático lo hemos desactivado y puede que el sistema requiera más frío del que le estamos dando y se caliente demasiado. ¡Un gran poder conlleva una gran responsabilidad!

Si queremos volver al modo de ventilador automático, basta con hacer:

The post Píldora: Modificar a mano la velocidad de los ventiladores de nuestro ordenador appeared first on Poesía Binaria.

Con Uptime en ensamblador, volví a adentrarme en el maravilloso mundo de los ensambladores, que tantos buenos recuerdos me había traído. Os comenté, que actualmente existen gran variedad de herramientas de este tipo, muchas de ellas, derivadas de Openwatcom Assembler (WASM), como UASM, ASMC o el difunto JWASM. Lo cierto es que si no fuera […]

Artículo publicado originalmente en Bitácora de Javier Gutiérrez Chamorro (Guti)

La entrada EasyCode Visual Assembler aparece primero en Bitácora de Javier Gutiérrez Chamorro (Guti).

No hace mucho que os hablaba de Uptime para DOS, y que publiqué la versión 1.00 y la 1.10, un sencillo programa escrito en FAST, y que replicaba el comando uptime de UNIX. El desarrollo empezó muy bien, con una eficiencia casi de ensamblador, pero contando con la ventaja de las estructuras de alto nivel. […]

Artículo publicado originalmente en Bitácora de Javier Gutiérrez Chamorro (Guti)

La entrada Uptime 2 para DOS aparece primero en Bitácora de Javier Gutiérrez Chamorro (Guti).

En la empresa conviven dos dimensiones: la operativa, que realiza los productos o servicios de la compañía; y la organizativa, que define y gestiona la cultura, estructura y modelo de gobernanza con el que se dirige .

A menudo se aborda la agilidad conjuntamente en las dos dimensiones, introduciendo modificaciones tanto en la gestión de proyectos y procesos de desarrollo, como en la cultura y modelo de gobernanza  (Agilidad en la empresa: ¿en el producto, en la cultura o en todo?).

Al considerar que la agilidad implica cambios operativos y organizativos de forma simultánea, no se valora por separado:

a) Si el producto, servicio o proyecto de la empresa se puede construir de forma evolutiva, y si el hacerlo proporciona ventajas a los clientes o la comercialización.
b) Si la propiedad de la empresa desea cambios en la estructura o en el modelo de gobernanza, y si es consciente de las implicaciones de esos cambios.

Cuando lo que se quiere es crear entornos potenciadores de creación de valor, basados en las personas y su motivación, pero no se necesita o no se puede entregar de forma incremental, hacer ágil la empresa no consiste en institucionalizar prácticas de desarrollo evolutivo, sino estructuras organizativas fractales y modelos de gobernanza dinámica. Es el caso, por ejemplo, de AES (sector energético, 40.000 empleados), Heiligenfeld (Hospitales de salud mental, 600 empleados) o Zappos.com (venta de zapatos on line, 1.500 empleados)  Laloux, F. (2016).

Estructuras fractales

Margaret Wheatley introduce en 1992, el concepto de organización fractal (Wheatley, 1992).

“Las mejores organizaciones tienen una naturaleza fractal... El patrón de su comportamiento es coherente y predecible... Las organizaciones fractales, aunque jamás hayan oído hablar del término fractal, han aprendido a confiar en fenómenos naturales de organización"

¡Tenía muchas ganas de escribir este post! De hecho, hay muchas personas a las que les he hablado de la técnica port knocking y me he tenido que poner a buscar un ejemplo que me convenciera por Internet. ¡Ya no tengo excusa! Y, como siempre, intentaré incluir varios ejemplos para copiar y pegar sin miedo explicados para no perder detalle.

¿Qué es el port knocking?

Imaginad que en mi servidor tengo activo un servicio privado, al que no quiero que nadie acceda, sólo yo. Por ejemplo, puede ser un sistema de administración remota, monitorización, logs, rescate, o simplemente cosas que no quiero que sean públicas. Y, claro, cuanto más tiempo esté un servicio expuesto a Internet, más probabilidades de ser vulnerado.
Por ejemplo, si tenemos un servidor SSH corriendo, normalmente veremos el puerto 22 abierto, y cualquiera que nos haga un scan de puertos podrá verlo (¿quién va a querer hacerme un scan de puertos?):

Está bien, una de las formas de ocultar un servidor SSH es cambiar el puerto, y entonces un análisis rápido no lo verá. De todas formas es un puerto abierto y, tarde o temprano, esas cosas salen a la luz. Así que si abres tu puerto 753 como servidor SSH, cualquiera se podrá conectar a él y basta hacer un netcat al puerto y ver cómo se presenta:

¡Listo! Sabemos que es un SSH, vamos a atacar, intentando identificarnos como los usuarios típicos: root, admin y demás, ¡Y conocemos la versión! Con lo malo que es eso para mantener un sistema medianamente seguro. Aunque bueno, aquí tienes una guía para endurecer un servidor SSH y hacerlo más seguro. No obstante, también podríamos tener un servicio corriendo que fuera algo más inseguro con una autentificación algo más floja.

Así que vamos a hacer un sistema de cerradura, como los de las cajas fuertes de las películas, en los que tenemos que girar la rueda varias veces siguiendo una combinación hasta que la podemos abrir o como cuando llamamos a la puerta con una combinación de golpes y esperas perfecta para que sepan que somos nosotros. De hecho port knocking lo podemos traducir como golpeo de puertos, es decir, intentaremos conectar con varios puertos y, el firewall de nuestro servidor mágicamente nos reconocerá y nos abrirá el puerto sólo para nosotros y así poder conectarnos.

Entonces, imaginemos que mi combinación es 1111, 3333, 2222 (lo pongo así para que veamos que no es necesario que los números de puerto estén ordenados), para abrir el puerto 22 de SSH necesitaré hacer intentos de conexión a los puertos 1111, 3333 y 2222. Estos puertos están cerrados, por lo que no conectarán, y el servidor parece que pasa de nosotros porque no hace nada, pero, tras los intentos de acceso a dichos puertos, podremos establecer una conexión con el puerto 22.

¿Podemos considerarnos paranoicos con este sistema de seguridad? Puede, y a muchos sysadmins les encanta. Al menos nos proporciona ocultación de los servicios críticos, así como de sus protocolos. Aunque, como todo, tiene sus riesgos.

No estoy inventando nada

Antes de continuar, tengo que decir que esta técnica es muy antigua. En junio de 2003, Martin Krzywinski publicó en Sys Admin Magazine un artículo bautizando de paso a esta técnica con un nombre chulo. Pero claro, eso no quiere decir que no se hubiera hecho antes.

Beneficios de esta técnica

Incluyo algunos puntos (no todos) que vienen en el artículo original de Krzywinski:

• Lo principal es que es un método de autentificación silencioso. Como dije antes, el sistema parece que pasa de ti. Además, los puertos a los que accederemos están previamente cerrados, por lo que con un escaneo de puertos no sabremos los puertos que hay que golpear, y mucho menos el orden.
• Si encima disponemos de un sistema que detecte y bloquee los escaneos de puertos, podríamos evitar que si nuestra clave de golpeo es de tres puertos, pudieran acceder al sistema tras hacer 3 escaneos. Además de que podríamos configurar el tiempo entre golpeos por lo que si tardas mucho en golpear tienes que empezar de nuevo. Aunque algunas implementaciones modernas de esta técnica pueden también evitar que un escaneo cuente como knock (hará knock cuando llegue al puerto deseado pero invalidará el knock cuando pruebe el siguiente puerto).
• No tenemos que cambiar nada en el software servidor que escucha en el puerto que vamos a abrir. Es más, esta configuración es totalmente independiente.
• Elimina entradas en los logs de sistema. ¡Cuántas líneas logea el demonio SSH con intentos de acceso! Con este sistema, la mayoría de intentos de acceso a un servidor SSH no llegarán a afectarnos lo más mínimo. El puerto del servicio está cerrado así que el propio firewall se deshará de todos.

Desventajas e inconvenientes

• No es conveniente proteger puertos como el 80 (http) o el 25 (smtp), porque los clientes no se van a poner a hacer el proceso de knocking cada vez que quieran algo de esos servidores. Esto está pensado para servicios que deben ser privados.
• Si tenemos servicios abiertos al público en el mismo servidor. Alguien podría utilizar un problema, bug, puerta trasera, etc. para entrar en el servidor y podría echar por tierra la seguridad que queremos tener con los servicios privados. Esto no es específicamente de la técnica, es un problema general de todos los sysadmins.
• Tenemos que tener cuidado con los servicios de automatización del firewall. Yo utilizaré iptables, así que si utilizamos UFW o APF, puede que éstos no se lleven bien y tendremos que trabajar un poco más para que todo funcione en sintonía.
• Es algo más que debemos mantener. Tanto si lo hacemos con scripts de iptables como si lo hacemos con un demonio. Como administradores del sistema tendremos que asegurarnos de que el sistema está vivo y no falla. Sólo imagina que si el sistema que controla el port knocking falla, nos quedaremos sin acceso al servicio que hemos ocultado.
• Tenemos una contraseña para abrir el puerto. Podríamos hacer un script que haga el knocking automáticamente, y ese script nos lo querremos llevar con nosotros a cualquier lado. Y ya estamos liberando información privada si lo subimos a un servidor o lo anotamos, etc.
• Si muchos usuarios tienen la clave del knocking e intentan acceder al servidor, la información temporal que tiene que almacenar el firewall puede crecer mucho. No es preocupante si es un gran servidor, pero la memoria se evapora.
• Este método permite la entrada a la IP que haga el juego completo de knocks. Es decir, si estamos haciéndolo a una máquina en Internet y varias personas compartimos conexión cualquiera en nuestra red local podría entrar. Eso también podría ser una ventaja… según se mire.

Ejemplo con iptables

Entonces, lo que queremos es que nuestro servidor tenga el puerto 22 (ssh) cerrado (cojo el 22, pero podría ser cualquier otro). Y cuando intente conectar con los puertos 1111, 3333 y 2222, puertos que están cerrados y los intentos de conexión no harán nada, veremos el puerto 22 abierto para poder conectar por ssh. Así que vamos a definir los diferentes estados por los que pasará mi sistema:

Estado	Descripción
Inicial	Configuración básica del firewall
WAITING	Esperando golpeos. Desde este estado repartimos los paquetes entrantes a los demás estados
KNOCK1	Entra el primer toque
KNOCK2	Entra el segundo toque
KNOCK3	Entra el tercer toque
ACCESSGRANTED	Esperando conexión con el puerto abierto

También vamos a suponer que tenemos un servidor web instalado, por lo que el puerto 80 deberá estar abierto (en la práctica deberíamos también abrir el 443). Si tienes otro firewall o un script de firewall, tal vez esto tengas que solucionarlo ahí.

Crearemos los estados en iptables:

Esto es lo que vamos a hacer lo siguiente en el servidor.

¿Qué haremos con el tráfico normal del servidor?

Asumo que el servidor SSH ya está instalado y funcionando.
Es decir, vamos a definir las directivas del tráfico que aceptará nuestro servidor (lo que empieza por # se ejecutará como root directamente. Si no somos root, tal vez podríamos usar sudo).

Lo primero que hacemos es aceptar todo el tráfico entrante y saliente (INPUT y OUTPUT, algunos también necesitaréis activar FORWARD), seguidamente con -F limpiamos las reglas de iptables hasta el momento (cuidado si tienes firewalls ya).

La siguiente línea hace que las conexiones ya establecidas sigan su curso. Es decir, tanto las conexiones al servidor web como las conexiones que ya tenemos establecidas en el puerto 22, que no tengan ningún problema para continuar.

Lo siguiente es aceptar todo lo que venga de localhost. Normalmente podemos tener varios servicios en la misma máquina que conectan con ellos mismos, y son todos privados, por lo que éstos no tienen que tener impedimentos.

Con estas líneas, rechazamos los paquetes ICMP, por ejemplo el PING. Esto no es esencial, pero muchos lo hacen, y desde aquí quiero demostrar que podemos hacer que ciertas conexiones continúen o al contrario, que se detengan.
Como hacemos en la siguiente línea, que es aceptar todo lo que provenga del puerto 80 tcp. Es decir, nuestro servidor web.
# iptables -A INPUT -p icmp -j DROP
# iptables -A INPUT -p tcp –dport 80 -j ACCEPT
[/simterm]

Todas las conexiones que hayan llegado hasta aquí, las vamos a pasar al estado WAITING

Configuramos los estados knockX y AccessGranted

Estos estados “knock” también pueden ser considerados puertas, como si un usuario tuviera que pasarlas todas para ver la libertad. Éstos serán KNOCK1, KNOCK2, KNOCK3. Empezamos por el primer intento. Estamos esperando un knock al puerto tcp 1111, conexión que tenemos que tirar porque ahí no hay servicio y no queremos que el puerto figure como cerrado. Eso sí, vamos a ponerle un flag “PASSED1” para que cuando entre el siguiente paquete sepa que tiene que este paso ya está hecho y entre directamente en KNOCK2.
La primera línea sólo nos sirve para enviar un log (que podemos ver con dmesg. El ejemplo de dmesg está al final del post).
En la tercera línea me encargo de tirar todos los demás paquetes que vengan. Sin flag ni nada, esos no han pasado la prueba.

En este post hablo de poner un flag a la IP, para indicar que se ha pasado la prueba. En realidad, iptables lo que hace es meter una IP en una lista. Al final estamos hablando de lo mismo, pero de forma más eficiente. En lugar de crear un texto que diga PASSED1 asociado a una IP, lo que hacemos es crear una lista llamada PASSED1 y meter ahí la IP, el momento en el que entró el último paquete y alguna información más. Si queremos, podemos ver el contenido de las listas haciendo:

Vamos, al KNOCK2, al que entraremos cuando recibamos el segundo knock. Éste será parecido al primero, sólo que antes de nada tendremos que borrar el flag PASSED1. Esto lo hacemos para que cuando un usuario haga mal el golpeo, es decir, después del 1111, golpee el 5555 y luego el 3333 ya no cuente, así si hacen varios escaneos que no bloqueamos el usuario no entrará. Por lo demás, hacemos que cuando se acceda al puerto 3333 pongamos la etiqueta “PASSED2” para que, como antes, cuando llegue un paquete nuevo al estado WAITING, éste sepa que tendrá que ir directamente al estado KNOCK3 porque KNOCK2 ya lo ha pasado y además, el paquete lo tiramos, porque en el puerto 3333 no hay nada. Por lo demás, saltaremos al estado KNOCK1 para ver si la conexión pasa el primer toque.

Este estado sí que es mucho más parecido al anterior y, con esto, ya nos da una pista para que nuestro sistema pueda tener tres, cuatro o cinco knocks. Cuantos más knocks, más difícil será entrar, será un modo más paranoico, y nuestro firewall será más complicado (recordad que esto requerirá un mantenimiento y, si hay muchos usuarios que quieren entrar, todo será más complicado). Lo único que cambian son los números. Es decir, en el estado KNOCK3 entramos porque el flag PASSED2 está activo (es decir, hemos superado el paso2 y por eso estamos en knock3), luego logeamos diciendo que estamos en knock3 y si alguien intenta conectar por el puerto 2222, colocaremos el flag PASSED3. Sencillo, ¿no?

Y… una vez superados los tres knocks, es decir, la conexión tiene el flag PASSED3, el acceso ya está permitido y ahora aceptaremos las conexiones al puerto 22.

Colocando cada paquete en su estado

Una vez que tenemos los estados KNOCKX y ACCESSGRANTED configurados, necesitamos que el estado WAITING, que será al estado que saltemos cuando llega un nuevo paquete (y éste ha sido previamente filtrado), reparta los paquetes que lleguen entre los diferentes estados en función de los flags que hemos ido definiendo. Es decir:

• Si no tenemos flags, saltamos a KNOCK1, porque tal vez sea una conexión con el puerto 1111, si no lo es, no haremos nada.
• Si la IP tiene el flag PASSED1, saltaremos a KNOCK2 y esperaremos el segundo toque.
• Si la IP tiene el flag PASSED2, saltaremos a KNOCK3 y esperaremos el tercer toque.
• Si la IP tiene el flag PASSED3, saltaremos a ACCESSGRANTED y esperaremos una conexión por el puerto 22.

Además, desde aquí podemos asignar tiempos. Es decir, si la IP tiene el flag PASSED1 y además han pasado menos de 10 segundos desde que entró en la lista, entramos a KNOCK2. Con esto limitamos el tiempo que tiene el usuario para poder completar cada paso y entrar en el sistema.

Todo el tráfico restante, lo mandamos a KNOCK1

El script completo

A mí me encanta poder copiar y pegar de las webs, al menos para probar las cosas de un tirón. Así que, os pongo el script completo aquí.

Cómo hacer el golpeo de puertos

En el lado del cliente, en nuestro ordenador, sólo tendríamos que intentar acceder a los puertos, con el programa que queramos, incluso con un navegador web si queremos (puede ser muy lento). Eso sí, como los puertos no tienen ningún servicio y cuando intentamos establecer una conexión parece que el servidor nos ignora tendremos que tener muy en cuenta los timeouts. Es decir, tenemos que poner un timeout pequeño, por ejemplo de un segundo o menos. Eso sí, la conexión con el servidor debe ser más o menos buena para que los paquetes lleguen en un tiempo razonable. Así que podríamos intentarlo incluso con curl:

Aunque, ya puestos, intentémoslo con netcat, que será más sencillo:

Y también con el mismo nmap, desactivando el ping al host:

Por si fuera poco, lo podemos automatizar con un pequeño bucle en una sola línea de nuestro shell favorito:

Utilizando un demonio (knockd)

Aunque existen varios sistemas, uno de los demonios que más me ha convencido, y más utilizado para estas cosas es knockd. El problema de tener un demonio corriendo es que si el demonio se cae estamos perdidos… ¡pero perdidos de verdad! Porque no vamos a poder entrar en nuestro servidor. Hay proveedores, como por ejemplo DigitalOcean que te permiten acceder a través de web a tu servidor sin necesidad de SSH aunque en ocasiones esto debe estar prohibido por exigencia de nuestros clientes o de normativas de seguridad.

De todas formas, el hecho de utilizar un demonio muy conocido y muy antiguo para eso (la primera versión es de 2004) es que está muy probado y podemos considerarlo estable. Además está hecho en C, por lo que la huella en memoria y la CPU utilizada serán ínfimas (que esté hecho en C no tiene nada que ver, podemos hacer programas muy poco eficientes, pero programarlo en python, por ejemplo ralentizaría mucho el sistema en caso de que entren muchas conexiones a la vez); y utiliza la biblioteca pcap, que también es muy robusta y está muy probada.

Cabe comentar que el uso del demonio facilita muchísimo la tarea de implementar el port knocking, ya que es mucho más intuitivo y no hay que andar pensando en los estados de los diferentes paquetes ni preocuparse en exceso por los firewalls. Además, como el resultado final es la ejecución de un comando, es decir, el programa detecta los knocks y en consecuencia ejecuta una orden, podemos personalizar dicha orden para que sea lo más amigable posible con nuestro firewall o script controlador o si, por ejemplo, queremos o necesitamos logear este tipo de actividad, no sólo haciendo caso al propio log de knockd.

Para esta guía he utilizado una Debian, de todas formas en otra distribución no debería ser muy complicado instalarlo y configurarlo (los ficheros de configuración serán iguales).

Lo primero es editar el archivo /etc/default/knockd, en el que debemos poner a 1 START_KNOCKD y en KNOCKD_OPTS definir el interfaz de red sobre el que nos vamos a centrar. En mi caso, eth0. Por lo que el archivo quedaría así:

################################################
#
# knockd’s default file, for generic sys config
#
################################################

# control if we start knockd at init or not
# 1 = start
# anything else = don’t start
#
# PLEASE EDIT /etc/knockd.conf BEFORE ENABLING
START_KNOCKD=1

# command line options
KNOCKD_OPTS=”-i eth0″

Seguidamente, editamos /etc/knockd.conf, vamos a hacer algunos cambios en el fichero para hacer las cosas más fáciles:

[options]
UseSyslog

[openSSH]
sequence = 1111,3333,2222
seq_timeout = 5
command = /sbin/iptables -I INPUT -s %IP% -p tcp –dport 22 -j ACCEPT
tcpflags = syn

[closeSSH]
sequence = 3333,2222,1111
seq_timeout = 5
command = /sbin/iptables -D INPUT -s %IP% -p tcp –dport 22 -j ACCEPT
tcpflags = syn

Ahora, configuramos iptables, en mi caso, aunque podríamos hacerlo perfectamente desde nuestro firewall o script de firewall siempre y cuando adaptemos bien las reglas. Sería una configuración parecida a la configuración inicial anterior en la que aceptamos los paquetes de las conexiones ya establecidas, aceptamos los paquetes que vienen de localhost y lo que venga del puerto 80, si queremos. Eso sí, en lugar de enviar los paquetes enviados a WAITING, directamente los tiramos (drop).

En este caso, knockd será el que controle si se están haciendo los knocks y la forma de entrar en el servidor será muy parecida. Eso sí, con esta configuración necesitamos hacer los knocks a los puertos 1111, 3333, 2222 para abrir el puerto 22 y luego 3333, 2222, 1111 para cerrarlo. El puerto se mantendrá abierto hasta que lo cerremos. Por un lado está bien, porque no tendremos que repetir los knocks para abrir otra sesión (por ejemplo si queremos abrir dos sesiones), pero por otro… personalmente soy muy despistado y se me puede olvidar cerrar el puerto.

Knockd por tiempo, como hacíamos con iptables

Como soy muy despistado, con knockd también podemos replicar el comportamiento anterior de iptables, es decir, el puerto se abrirá durante un tiempo y se cerrará automáticamente. Para eso, entraremos en el archivio /etc/knockd.conf y pondremos lo siguiente:

[options]
UseSyslog

[opencloseSSH]
sequence = 1111, 3333, 2222
seq_timeout = 15
tcpflags = syn
start_command = /usr/sbin/iptables -I INPUT -s %IP% -p tcp –syn –dport 22 -j ACCEPT
cmd_timeout = 10
stop_command = /usr/sbin/iptables -D INPUT -s %IP% -p tcp –syn –dport 22 -j ACCEPT

De esta manera con nuestra secuencia de puertos de antes se abrirá el puerto 22 por unos segundos y luego se cerrará pasados unos segundos. Y también tenemos un log de todo esto, tanto en el ejemplo anterior como en este podremos ver en el syslog (/var/log/syslog) lo siguiente:

Aug 3 12:43:06 ubuntu-512mb-fra1-01 knockd: xxx.xxx.xxx.xxx: openSSH: Stage 1
Jul 30 12:43:07 ubuntu-512mb-fra1-01 knockd: xxx.xxx.xxx.xxx: openSSH: Stage 2
Jul 30 12:43:08 ubuntu-512mb-fra1-01 knockd: xxx.xxx.xxx.xxx: openSSH: Stage 3
Jul 30 12:43:08 ubuntu-512mb-fra1-01 knockd: xxx.xxx.xxx.xxx: openSSH: OPEN SESAME
Jul 30 12:43:08 ubuntu-512mb-fra1-01 knockd: openSSH: running command: /sbin/iptables -I INPUT -s xxx.xxx.xxx.xxx -p tcp –dport 22 -j ACCEPT

Y listo. Ya tenemos la puerta abierta. Lo bueno de este demonio es que podemos configurar varios locks y los servicios que queramos en cada uno de ellos o incluso… enviar mensajes a los servidores utilizando los knocks, los start_command y stop_command pueden, perfectamente, ser scripts que hagan cualquier cosa y no sólo abrir o cerrar puertos.

Secuencias de knock preconfiguradas

¡El comportamiento más peliculero de knockd! Vamos, contraseñas de knock que van cambiando cada vez que se abren o se cierran las puertas. Imaginad que vamos a utilizar varias secuencias para abrir un puerto, así que vamos a crear un fichero /etc/ssh_knock_seq que contenga lo siguiente:

1111,3333,2222
1111,2222,3333,
1234,5678,9101,
1213,1415,1617

Es muy importante el espacio al principio de la línea, ya que knockd escribirá un # en el primer carácter de cada secuencia que vaya utilizando (por eficiencia, es mucho más rápido cambiar un carácter que insertarlo, ya que implica un desplazamiento de todos los contenidos), por lo que perderíamos el primer número si no ponemos un espacio.

Ahora, en /etc/knockd.conf hacemos lo siguiente:

[options]
UseSyslog

[openSSH]
one_time_sequences = /etc/ssh_knock_seq
seq_timeout = 5
command = /sbin/iptables -I INPUT -s %IP% -p tcp –dport 22 -j ACCEPT
tcpflags = syn

La primera vez que hagamos la secuencia de knocks debemos hacerla a los puertos 1111, 3333 y 2222; la segunda vez a los puertos 1111, 2222 y 3333 y así sucesivamente. Lo bueno es que las secuencias cambian, así que si alguien está sniffando el tráfico de red y vea que estás hacieno knocks a puertos e intente hacer lo mismo después, no le va a servir porque la secuencia ha cambiado. Lo malo es que si hay más de un administrador del sistema que tiene que entrar, es un poco rollo saber por qué combinación vamos.

Complicando un poco los knocks

Este cliente, al funcionar capturando el tráfico de la red, puede ver directamente los paquetes TCP que se envían, y podemos reaccionar ante diferentes flags del paquete: syn, ack, fin, rst… Para no entrar en mucha profundidad, normalmente cuando se inicia una conexión TCP. Un cliente envía SYN al servidor, y el servidor responde SYN-ACK, luego el cliente le responde ACK, cuando alguien corta la comunicación le dice al otro FIN, para reiniciar la conexión se envía RST y, bueno, hay algunos más. El caso es que normalmente cuando hacemos knocks enviamos un SYN, pero, ¿y si hacemos que el servidor requiera knocks con ACK? Es raro, más paranoico y enrevesado, además puede requerir privilegios de administración en los clientes y no sé yo si a muchos firewalls les gustará que les mandes un ACK sin conocer de nada al host con el que hables (el SYN solo es como un saludo). Pero bueno, podemos decirle a knockd en tcpflags que escuche solo a ACK o a FIN y sólo reaccionará ante esos estímulos. Está muy chulo para probar.

Para hacer los knocks, recomiendo la herramienta hping3 que podemos utilizarla así:

Y, por supuesto, podemos utilizarla en un script como el de antes.

Envío de knocks con cliente

knockd proporciona un cliente llamado knock (sin la d) con el que podemos enviar los knocks todos seguidos y sin scripts como hacíamos antes:

Anexos

Quiero incluir algunas cosillas más, para tener toda la información en este post. Con algunas cosas que no tienen mucho que ver, pero ayudan a comprenderlo todo.

Ejemplo de dmesg

El kernel está todo el rato escribiendo mensajes con lo que sucede. Y el caso de iptables, ya que actúa en el kernel no es menos. Cuando desde iptables enviamos al log un mensaje podremos consultarlo haciendo:

Con tail sacamos las últimas líneas del buffer de mensajes del kernel, porque suele ser muy largo y seguramente algo que sucedió hace mucho tiempo no nos interesa.
De todas formas, las fechas y horas están expresadas en el tiempo transcurrido tras el arranque de la máquina y no es un formato muy agradable porque usa números muy largos. Podemos expresarlo en formato humano con este post o con el argumento -T. Aunque a mí me gusta mucho la salida producida por:

Que escribe los mensajes de manera legible y nos deja hacer búsquedas (como less), el tiempo en formato humano, nos da información sobre el tipo de mensaje y encima lo muestra en colores.

Ejemplo de iptables centrado en interfaz

No voy a extenderme mucho, pero si queremos que una regla de iptables se aplique a los paquetes que viajan por una interfaz de red determinada debemos incluir “-i [interfaz]”. Al final se quedaría algo así:

ACCEPT, REJECT y DROP

Está claro que ACCEPT directamente acepta el paquete y si va para alguna aplicación, ésta lo recibe y lo procesa. Vamos, el uso normal. Pero cuando especificamos REJECT, estamos rechazando el paquete, y para rechazarlo tenemos que responder algo. DROP, en cambio ignora el paquete, lo tira en saco roto y que se pierda en la inmensidad de la red.
Es como cuando mantienes una conversación con alguien, si aceptas su mensaje haces algo al respecto. Te dicen “Hola” y respondes: “Buenos días, ¿cómo estás?”. Si rechazas los mensajes (reject), te dicen “Hola” y contestas: “¡No hablo contigo!” y pones carita de enfado. Eso implica un esfuerzo, intención de contestar y en general gasto de recursos. Pero si ignoras a alguien, te dirán “Hola” y no contestas, pero tú estás a lo tuyo, lo mismo has movido un poco la oreja o has girado ligeramente la cabeza cuando lo has escuchado, pero tu “amigo” ya puede esperar tu respuesta, que lo hará hasta que se cumpla su timeout.

Foto principal: Mahkeo

The post Knock, knock, knockin’ on server’s ports – Port knocking con ejemplos appeared first on Poesía Binaria.

Retomo mis posts sobre Arduino (después de muchísimo tiempo) con un pequeño ejemplo que monté hace unos años, pero el post nunca llegó a salir. Se trata de la utilización de un display de 7 segmentos desde la propia placa Arduino. Estos displays, al final son 7 barras led con las que podemos representar números y letras dependiendo de las que encendemos y las que no. En mi ejemplo, haremos un contador de 0 a 9 controlado por un pulsador.

El display

Para ver más a fondo cómo funciona el display, lo más fácil es ver este dibujo:

Este ejemplo muestra un display de cátodo común, ya que las patillas centrales van a gnd (sólo hay que conectar una) y las demás (a, b, c, d, e, f, g, dp) podrán ir conectadas a VCC. Todo depende de las que queramos encender. En mi caso, alimento cada uno de los leds con unos 3.6V.

También existen displays de ánodo común, como el que utilizo en este proyecto. En este caso conecto el display a VCC (5V) y cada uno de los segmentos van conectados a GND a través de una resistencia.

Conectar el display directamente a Arduino

Es una opción. Nuestro display tiene 7 segmentos, y normalmente los Arduinos (Duemilanove, Uno, Mega…) suelen tener muchos pines de entrada-salida (más de 7) configurables y capaces de soportarlo. Así que perfectamente podemos conectar cada segmento a un pin del Arduino y hacer un programa que escriba valores en dichos pines.

En principio no es mala idea, nosotros controlaremos al 100% la iluminación de los segmentos. Aunque podemos tener varios problemas:

• Nuestro Arduino se calentará. El display al final pide potencia, y puede que nuestro Arduino trabaje en exceso para entregar la potencia necesaria para iluminar el display. Podemos poner resistencias más grandes, pero el display lucirá menos.
• Son muchos pines, para controlarlos podemos usar digitalWrite() y es un poco tostón controlar los digitalWrite() de cada número que vamos a representar. Por otro lado podemos hacerlo usando los PORT del Atmega (lo veremos en el ejemplo), pero claro, el PORTD (pines 0-7) no podemos acapararlo entero porque por ejemplo las interrupciones de algunos Arduino (como el mío, un Duemilanove, aunque sea algo viejo) están en los pines 2 y 3 por lo que no podremos utilizarlos. Y el PORTB (pines 8-13) sólo son 6 por lo que no son suficientes. Así que tendremos que pasar parte por un puerto y parte por otro puerto. Pero a fin de cuentas, si queremos hacer algo más con nuestra placa hemos gastado muchos pines para este propósito.
• Impensable ya pasar el montaje a un circuito a base de ATtiny, por ejemplo.

Por poner un ejemplo más, si queremos utilizar puertos en lugar de digitalWrite(), lo primero es mirar el datasheet del chip que estemos utilizando, en mi caso Atmega168. Tendremos que mirar a qué pines corresponden los puertos. Yo utilizaré el puerto D y el puerto B para conectar el display.

Lo primero será crear un array con los valores de los segmentos que corresponderán a cada dígito. Daremos valores en hexadecimal porque serán más fáciles de manejar cuando tienes algo de vicio, sobre todo cuando debemos mirar el valor en binario de cada uno de los valores. En mi array, como mi display es de ánodo común tengo que mandar ceros a los dígitos que quiero encender. En este caso, sólo será un ejemplo, haremos algo así:

Con este array, hacemos que la posición 0 contenga 1000 0001 (al 0 sólo le falta un segmento, el último bit no lo usaremos), en la posición 1 tendremos 1101 1101 (el 1 sólo tiene dos segmentos activos), en la posición 2 tendremos 0100 0011 (el dos sólo tiene 2 segmentos desactivados), etc.

Y, para enviar los valores a los puertos podríamos utilizar el desplazamiento binario (shift):

Los puertos

Veamos primero un diagrama de los pines del Atmega368, por ejemplo (muy parecido al del Atmega168:

Vemos que hay pines etiquetados como PB0..PB7, PC0..PC6, PD0..PD7. Corresponderán a los puertos B, C y D respectivamente. Si hemos manejado Arduino anteriormente habremos visto cómo digitalRead/digitalWrite nos puede solucionar la vida cuando se trata de leer o escribir el valor de un pin concreto. Aunque lo que yo quiero es definir el valor completo de un puerto. Es decir, enviar, por ejemplo un valor 11011011 de una sola vez a todos los pines del puerto D, por ejemplo.

Para ello, lo primero que tenemos que hacer será definir una máscara de entrada/salida de los pines del puerto, lo que anteriormente hacíamos con pinMode([pin], OUTPUT); pero esta vez lo haremos definiendo en la función setup() o en cualquier otro sitio la variable DDRD dando 1 al bit correspondiente con el pin que queremos que sea de salida (OUTPUT) o 0 si queremos que sea de entrada (INPUT):

Con la última forma de hacerlo, podemos pensar que se realizan operaciones en el chip e irá más lento, pero al ser PD5, PD3 y PD1 constantes, en tiempo de compilación se procesará el número y el programa real se ejecutará con una sola instrucción, por lo que es tan rápido como el caso que hay justo encima en el que nosotros hemos calculado el número.

Ahora para escribir valores en el puerto puerto, escribiremos la variable PORTD y para leer valores, leeremos la variable PIND.

Decodificador de 7segmentos 7447, 7448

Para arreglar los problemas mencionados anteriormente (potencia y número de pins), vamos a utilizar el circuito integrado 7447, ya que nuestro display es de ánodo común. Si fuera de cátodo común utilizaríamos el 7448. Este es un circuito TTL decodificador de BCD (binary-coded decimal, o decimal codificado en binario) a display de 7 segmentos. Ya que el sistema utilizado es digital no se garantiza que la salida para valores mayores a 9 sea la misma en todos los chips. Dada su tecnología requiere una corriente baja de entrada, de algunos microamperios, y proporciona una corriente de salida del orden de los miliamperios, por lo que puede hacer las veces de amplificador de la señal haciendo que nuestro Atmega no sufra.Haremos las conexiones como en el siguiente diagrama (como en la foto de portada):

Éstos son los materiales utilizados:

• Arduino Duemilanove
• Display de 7 segmentos de ánodo común
• DM74LS74N (decodificador BCD-7 segmentos)
• 1 diodo led (es para jugar, sólo parpadeará indefinidamente
• 8 resistencias de 1K
• 1 resistencia de 10K (para el pulsador)
• 1 switch

El esquema del proyecto será el siguiente:

Vamos al código:

Empecemos por setup(). En donde con DDRB preparamos el puerto B como salida y el puerto D como entrada. Como es el puerto entero, le damos un 0 y listo. Preparamos la salida del led, aunque no haría falta especificar el pinMode porque el LED_BUILTIN apunta al pin 13 que es del puerto B que ya está marcado como salida, pero dejo esa línea ahí por si cambiamos el led de sitio. Simplemente es un led que parpadea para demostrar el funcionamiento de la interrupción.

Seguidamente presentamos el número en el display, aunque ya que el display y el led comparten puerto (el puerto B para todos), quise poner la parte alta del puerto B tal cual está (0xf0 & PORTB) y en la parte baja del puerto B pongo el número a representar (0x0f & num).

EICRA y EIMSK son dos valores que tengo que establecer para que mi Atmega escuche a las interrupciones hardware. Esto depende mucho del chip y no en todos los Arduinos funcionará igual y, aunque la plataforma Arduino tiene su propia manera de hacer las interrupciones, he querido poner esta forma aquí.

Por último llamo a sei() para activar el flag de interrupciones de Atmega.

Luego en el loop() sólo me encargaré de actualizar el estado del led, apagarlo y encenderlo sin preocuparme por el pulsador. Por último, tenemos ISR(INT0_vect), una función donde estableceremos las acciones que se llevan a cabo cuando se activa la interrupción. En este caso incrementar el número y enviarlo a PORTB.

The post Controlando un display de 7 segmentos con Arduino y un botón por interrupción. appeared first on Poesía Binaria.

Este artículo es bastante extenso. Si te interesan los detalles más técnicos puedes ir al final.

Nacieron en la primera mitad del siglo XX. Originalmente, estas primeras tarjetas no eran más que una línea de crédito de un determinado establecimiento. En 1924 por ejemplo, General Petroleum Corporation emite una tarjeta para poder adquirir gasolina. En realidad, lo que sucedía al usar esa tarjeta era que contraíamos una deuda con la compañía, que posteriormente había que pagar en efectivo. De este modo, funcionaban de forma similar a como cuando dejamos que nos apunten algo en la cuenta del bar.

Esto cambió en 1949, cuando Franck McNamara estaba cenando con unos amigos y discutiendo precisamente sobre este tipo de tarjetas. Finalmente al llegar a la hora de pagar, McNamara pudo comprobar que se había dejado la cartera en casa. Tuvo que llamar a su mujer para que le llevase el dinero. Pasó tal vergüenza que se propuso acabar para siempre con este tipo de situaciones. Así es como nació Diners Club, la primera compañía de tarjetas de crédito del mundo.

Frank X. McNamara

Una de las primeras tarjetas Diners Club

Otros dicen que no llamó a su mujer sino que salió del aprieto dando su tarjeta de visita y anotando la cantidad debida. Sea cual sea la historia verdadera, lo cierto es que el sistema de funcionamiento de una tarjeta de crédito es ese. Nosotros cuando pagamos con una tarjeta de este tipo estamos emitiendo deuda, que a final de mes o cuando más nos convenga, pagamos íntegramente o a plazos. Diners cobraba comisiones de mantenimiento a los poseedores de las tarjetas y comisiones por transacción a los establecimientos que las admitían. Esta es la principal diferencia respecto a las tarjetas de débito y las tarjetas prepago.

Logotipos en un establecimiento de Master Charge (actual MasterCard) y BankAmericard (actual VISA)

A partir de ese momento empiezan a surgir más compañías, Bank AmeriCard o Master Charge (VISA y MasterCard actualmente). En España se aceptaron tarjetas de crédito por primera vez en el año 1954 y por aquel entonces eran simples tarjetas de cartón con un número y su titular, que los hoteles y restaurantes de la época anotaban para posteriormente reclamar el pago a Diners. La primera tarjeta emitida por un banco español no llegaría hasta 1978, por el Banco de Bilbao y se trataba de una AmeriCard. Las tarjetas de crédito son el tipo de tarjetas más admitidas en el mundo y suelen llevar asociadas ventajas tales como seguros, programas de puntos, … Al pasarnos una factura a final de mes es más fácil saber cuanto hemos gastado en un mes. Sin embargo estas tarjetas tienen un gran peligro. Nos dejan a nuestra disposición una gran cantidad de dinero, y si no somos capaces de pagar las cuotas a tiempo podemos enfrentarnos a unos intereses de devolución en la mayoría de los casos de dos cifras.

Las primeras tarjetas de crédito emitidas en España fueron las BankAmericard del Banco de Bilbao

Como vemos, las tarjetas de crédito no necesitaban ninguna tecnología en especial para funcionar, las de débito y las prepago, sí que lo necesitan. No obstante, todas las tarjetas de crédito hoy en día usan tecnología, de hecho existen tarjetas que operan en varios modos, crédito y débito. ¿Cómo funcionan las tarjetas de débito?

Las tarjetas de débito son lo más parecido a pagar en efectivo. Cuando pagamos, estamos pagando con nuestro dinero. En algunas se nos permite caer en números rojos (VISA Debit) mientras que en otros se comprueba la existencia de fondos (VISA Electron). Inmediatamente a la compra, el dinero se descuenta de la cuenta bancaria asociada. Estas tarjetas suelen tener gastos de mantenimiento menores (en España los bancos las suelen dar gratis) y son prácticamente igual de admitidas que las de créditos en cajeros automáticos, establecimientos y compras por Internet. No obstante, las tarjeta de débito no son aceptadas en todos los sitios, por dos motivos:

• Las tarjetas de débito (como VISA Electron) requieren conexión a la cuenta bancaria de tu banco. Este proceso es más complicado que simplemente anotar que debes 50€ a fulanito. Otras tarjetas como VISA Debit pueden funcionar en puntos de pago offline ya que pueden dejarte en números rojos (por tanto, el comerciante se asegura que siempre va a recibir el dinero, aún sin saber cuanto dinero tienes).
• Las tarjetas de débito no dejan gastar más dinero del que hay en cuenta (o pueden dejar, pero no demasiado).

Por estos dos motivos, puede ser que una tarjeta de débito no llegue a funcionar en algún país extranjero (aunque es cada vez más raro) o simplemente no se admitan para poder así cobrarte gastos imprevistos (alquileres de coches, hoteles, …). Si bien en esto las tarjetas de débito han ido mejorando y en muchas existe la posibilidad de reservar una cantidad de dinero de la tarjeta. Eso quiere decir que al hacerel primer pago o la entrada, se nos cobra una parte y se nos reserva otra. Esa cantidad reservada a efectos prácticos no podemos usarla para nada pero técnicamente sigue siendo nuestro. Cuando se acaba el plazo y no ha hecho falta recurrir a ese dinero de reserva, el comerciante libera ese dinero y ya lo podemos usar en nuestra tarjeta.

Las tarjetas prepago funcionan con tecnología similar a las de débito, salvo por el detalle de que no tienen asociada una cuenta bancaria como tal. En vez de eso, las tarjetas prepago tienen una cuenta propia, que debemos recargar antes de efectuar pagos o retirar dinero. Las tarjetas prepago se han vuelto muy populares para menores de edad y compras por Internet, donde solo se recarga la tarjeta con la cantidad máxima que consideremos necesario.

La tarjeta Antes de BBVA es una tarjeta prepago

Por último, existe otro tipo de tarjeta, aunque apenas usadas en compras, se trata de las tarjetas monedero. Su diferencia principal respecto a las tarjetas prepago reside en como se realiza el pago. En una tarjeta prepago, se realiza una conexión al emisor de la tarjeta, como con las de débito, mientras que en una monedero no. En una tarjeta monedero el dinero se almacena en la propia tarjeta, de forma cifrada. Este sistema no es tan popular y en España que yo sepa ningún banco emite tarjetas de este tipo. Son usadas sin embargo en algunos sistemas de transporte público o de empresas, donde se puede descontar el dinero instantáneamente, aunque no haya conexión con un servidor central. La forma de recargar estas tarjetas es acudir con la propia tarjeta a un punto de recarga, no pudiendo realizarse por Internet o sin la tarjeta.

Tarjeta monedero emitida por Caja Duero para el transporte urbano de Valladolid

Mencionar también las tarjetas ATM. Estas tarjetas únicamente pueden usarse en los cajeros para sacar dinero, no pudiéndose usar en las compras. De este modo funcionan similar a algunas libretas de ahorro. Sin embargo, he de reconocer que personalmente no he visto ninguna tarjeta ATM.

Redes bancarias

Si nos centramos en tarjetas de crédito, débito y prepago tenemos que tener en cuenta las redes interbancarias. Estas permiten las conexiones entre las redes de los distintos bancos y permiten por ejemplo que podamos sacar dinero en un cajero de EspañaDuero cuando nuestra tarjeta la ha emitido N26 Bank o que podamos pagar en el extranjero. En el sistema bancario, no existe nada parecido a Internet (la red de redes) y cada red tiene sus propios puntos de acceso. Así pues, no todos los cajeros tienen por qué poder conectarse a todas las redes existentes, con los consiguientes problemas (no poder sacar dinero, no poder pagar,…). En tarjetas de débito esto es más problemático. En España existen tres redes locales aunque funcionan también redes internacionales.

• Servired, la mayor red intranacional de España, con el BBVA, Bankinter, Deutsche Bank, Sabadell, Bankia, CaixaBank, Cajamar, las cajas rurales que están unidas por el Banco Cooperativo Español, Triodos Bank, Self Bank, Banco Mediolanum, Caixa Geral, Laboral Kutxa, Abanca y otros bancos más pequeños.
• 4B, originalmente para Banco Santander, Banco Popular, Banco Pastor y Banesto, ahora también ING, Targobank, Openbank, Banca March, Cetelem, Inversis, Andbank y alguno más.
• Euro6000, usada antiguamente por las cajas de ahorros, hoy en día de sostiene gracias a Unicaja, EspañaDuero, Ibercaja, Kutxabank, Liberbank y EVO Banco.

Cajero perteneciente a la red intranacional Servired. También aparecen logos de PLUS, Cirrus, Tarjeta 6000, Eurocheque, Eurocard,…

Indicativo del Banco Pastor y Telebanco 4B

IberCaja, con sede en Zaragoza, es una de las entidades que sigue dentro de Euro 6000

Estas redes se comunican con otras redes similares de otros países o bien pueden recurrir a una red internacional, como Cirrus. Aunque después de la crisis de 2008 muchos bancos y cajas se han fusionado entre sí, parece que las tres redes siguen operando de forma independiente.

Logo actual de la red interbancaria Cirrus

Tarjetas

Vamos ahora a ver las principales empresas que se dedican a las tarjetas:

VISA (anteriormente Bank AmeriCard) es quizá la tarjeta más conocida del mundo. Es la tarjeta líder en España. A nivel global es la segunda red más importante (solo superada por UnionPay). Las tarjetas VISA operan a través de la red interbancaria PLUS. VISA dispone de varios tipos de tarjeta: VISA, VISA Debit, VISA Electron y V Pay. VISA es de crédito, VISA Debit es la versión más libre de las de débito. Permite dejarte en números rojos ya que al hacer un pago no se comprueba la disponibilidad de fondos. Es por ello que la VISA Debit puede usarse en algunos sitios donde solo se admiten tarjetas de crédito por ese mismo motivo, el comerciante se puede asegurar que va a recibir su dinero aunque no sepa si tu cuenta tiene fondos. VISA Electron por contra, verifica que haya fondos suficientes en la cuenta, así que necesita que exista una conexión con el banco. Desde hace no mucho existe V Pay, una tarjeta de débito mucho más moderna, emitidas solo con chip y que solo funcionan en SEPA (Single Euro Payments Area). Han sido diseñadas para ser usadas en transacciones pequeñas y por lo general funcionan de forma similar a VISA Electron.

Logo antiguo de VISA Electron

PLUS es la red interbancaria de VISA

V Pay es la gama más moderna de VISA, sólo válida en territorios SEPA

MasterCard, la gran competidora de VISA en España. MasterCard entro en el mercado europeo con las adquisiciones de Eurocard y Europay. Su red interbancaria es Cirrus. Posee varias tarjetas: MasterCard, Debit MasterCard y Maestro. MasterCard es la línea de tarjetas de crédito, Debit MasterCard es una línea de tarjetas de débito compatibles con puntos offline y números rojos (como VISA Debit) y Maestro es comparable a VISA Electron, ya que requiere comprobación de fondos. No obstante, Maestro también puede funcionar como tarjeta prepago y las tarjetas Maestro son distintas al resto de tarjetas MasterCard y VISA. En ciertos países, Maestro funciona como Debit MasterCard, por lo que no requiere autorización electrónica. Las tarjetas Maestro también son compartidas en algunos países con algún proveedor local de tarjetas, como Girocard en Alemania. Maestro fue de las primeras tarjetas donde no había que firmar, sino que se introducía un PIN al comprar, tanto si se compra usando chip como con banda magnética. Muchas Maestro que no pueden usarse en el extranjero e Internet. En España, las tarjetas Maestro nunca han llegado a ser populares.

Logos antiguos de MasterCard, Cirrus y Maestro

American Express es la tercera entidad de tarjetas en España. Sin embargo, debido a sus altas comisiones, es fácil encontrar tiendas que no la admitan.

Discover y Diners Club son bastante usadas en Estados Unidos y otros países como Croacia. En España son bastante difíciles de encontrar y se suelen aceptar únicamente en establecimientos turísticos. Hasta hace años eran empresas con tarjetas independientes, no obstante, Discover adquirió Diners Club hace años. Discover se centrará en el mercado doméstico estadounidense y Diners Club, que era más usada internacionalmente, seguirá con la expansión internacional.

JCB, se trata de una entidad japonesa de tarjetas. Es usada sobretodo por japoneses y coreanos.

UnionPay, es la compañía de tarjetas más grande del mundo, aunque la mayor parte de sus transacciones se concentran en China. Solo las emiten bancos chinos.

UnionPay es la tarjeta más usada del mundo desde 2015

RuPay, son unas tarjetas de amplio uso creadas con intervención del gobierno de la India con el deseo de que todos los habitantes de la India pudieran disponer de esta forma de pago.

Otras tarjetas pueden ser Bancomat (Italia), Elo (Brasil) o Dankort (Dinamarca). Este tipo de tarjetas, debido a su poca popularidad suelen ser compatibles con VISA y MasterCard en el extranjero, mientras que en sus países de origen usan su red interna.

Elo es muy usada dentro de Brasil

¿Cómo funcionan las tarjetas?

Ahora vamos a ver como se puede pagar con las tarjetas de crédito, débito y prepago. En primer lugar comentemos algo sobre el número de las tarjetas. Estas tienen normalmente 16 dígitos, aunque pueden llegar a 19 dígitos. Se numeran por lotes, siendo los primeros dígitos los correspondientes a la empresa. Es posible reconocer la empresa detrás de la tarjeta según su número o PAN.

Los PAN siguen una estructura, que aunque presenta longitud variable, está bien definida.

El primer dígito corresponde al Major Industry Identifier (MII). Indica a que sector pertenece la empresa de la que es la tarjeta. Los sectores son:

Dígito	Sector
0	Uso interno
1	Aerolíneas
2	Aerolíneas y otros
3	Viajes, entretenimiento, finanzas
4	Finanzas
5	Finanzas
6	Finanzas
7	Petroleras
8	Salud y telecomunicaciones
9	Sin asignar

Aunque actualmente, la mayoría de tarjetas son de finanzas. El MII y los siguientes 5 dígitos forman el BIN o Bank Identification Number y sirven para idenficar al banco emisor de la tarjeta y enrutarlo. Los siguientes dígitos excepto el último forman parte del identificador de tarjeta personal, asignado por el banco a sus clientes. El último dígito es de comprobación y se calcula con el algoritmo de Luhn.

Número(s) de inicio	Longitud número de tarjeta	Empresa
22 a 27	16	MasterCard
30	14	Diners Club
34	15	American Express
35	16	JCB
36	14	Diners Club
37	15	American Express
38, 39	14	Diners Club
4	16	VISA
5018, 502, 503, 506	12 a 16	Maestro
5019	16	Dankort
51 a 55	16	MasterCard
56 a 58	12 a 19	Maestro
60	16	Discover
62	16 a 19	UnionPay
622, 64, 65	16	Discover
639, 6220	12 a 19	Maestro
88	16 a 19	UnionPay

Esta tabla no es exhaustiva pero puede servir de referencia rápida. Por ejemplo, aunque VISA empieza siempre por 4, no todas las que empiezan por 4 son VISA siempre, ya que existen tarjetas Elo que también empiezan por 4. No obstante, se trata de rangos tan pequeños que la lista sería muy larga si fuese exhaustiva.

Banda magnética y firma

Estas tarjetas, mejorando las de cartón, agilizan el proceso de pago pero ni introducen ninguna medida de seguridad extra. Se definen según el estándar ISO/IEC 7813 e ISO/IEC 7811. Incluyen una banda magnética desde la que se puede leer el número de la tarjeta, la fecha de caducidad, los nombres del titular y algunos datos técnicos. Las tarjetas tienen 3 bandas o tracks.

Los 3 tracks de las bandas magnéticas y su posición

El primer y segundo track llevan información redudante, de forma que si una banda está dañada puede leerse la otra, sin embargo no siguen el mismo formato.

Nombre del campo	Longitud	Uso
Start Sentinel (SS)	1 caracter	Indica que comienza el track 1, siempre es %
Format Code (FC)	1 caracter	Indica el tipo de tarjeta, B para crédito/débito
Primary Account Number (PAN)	Hasta 19 digitos	Normalmente, el número de la tarjeta que está impreso
Field Separator (FS)	1 caracter	Separa el campo de longitud variable PAN del siguiente campo. Siempre es ^
Nombre	Hasta 26 caracteres	El nombre del titular de la tarjeta, con espacios si hace falta
Field Separator (FS)	1 caracter	Separa el campo de longitud variable nombre del resto de campos. Siempre es ^
Expiration Date (ED)	4 dígitos	Fecha de caducidad. Siempre en formato YYMM
Service Code (SC)	3 dígitos	Indica que tipo de pagos son aceptados
Discretionary Data (DD)	Indefinido, pero el track 1 solo puede almacenar 79 caracteres en total	Este campo viene determinado por el fabricante de la tarjeta. Puede incluir datos como el CVV1 y PIN.
End Sentinel (ES)	1 caracter	Se usa para indicar el fin del campo DD. Siempre es ?
Longitude Redundancy Check (LRC)	1 caracter	Se usa para comprobar que se ha podido leer el track 1 entero sin problema

El track 2 fue desarrollado por la American Banking Association y es más corto.

Nombre del campo	Longitud	Uso
Start Sentinel (SS)	1 caracter	Se usa para indicar el comienzo del track 2. Siempre es ;
PAN	Hasta 19 caracteres	Normalmente, el número de la tarjeta que aparece impreso
Field Separator (FS)	1 caracter	Separa el campo de longitud variable PAN, siempre es =
Expiration Date (ED)	4 dígitos	Fecha de caducidad en formato YYMM
Service Charge (SC)	3 dígitos	Indica los pagos que pueden realizarse
Discretionary Data (DD)	Indefinido, pero el track 2 no puede superar los 40 caracteres	Campo determinado por el fabricante de la tarjeta. Puede incluir el CVV1 y PIN.
End Sentinel (ES)	1 caracter	Indica que el track 2 acaba, siempre es ?
Longitude Redundancy Check (LRC)	1 caracter	Usado para comprobar que el track 2 fue leído correctamente

El track 3 no se usa y habitualmente no contiene información. La única excepción se puede encontrar en Alemania donde el track 3 de las tarjetas de débito incluye la información necesaria para obtener la cuenta corriente sobre la que opera la tarjeta de débito.

Al pagar con estas tarjetas es habitual firmar, para dar nuestro consentimiento y en algunos países como España, era necesario mostrar el DNI o algún tipo de identificación.

El problema principal de estas tarjetas es su rápida y sencilla clonación. No deja de ser información que igual que es leída puede ser copiada y ningún lector sería capaz de distinguir entre una tarjeta original y una clonada. No obstante vamos a entrar más a fondo en la seguridad de estas tarjetas.

En primer lugar, toca hablar el CVV1. Se trata de un código que aunque el estándar ISO no exige, suelen llevar las tarjetas VISA y MasterCard. Se trata de un número generado en la emisión de la tarjeta de forma poco previsible fruto de la encriptación del número de la tarjeta y la fecha de caducidad. Las claves usadas en la encriptación, evidentemente, no son públicas. De este modo se consigue que una persona no pueda crear aleatoriamente tarjetas, ya que si bien puede acertar con el número y la fecha de caducidad, difícilmente lo hará con el CVV1. Este sistema de seguridad no protege en ningún momento contra los clonados totales.

También existe el CVV2. Se trata del código de 3 dígitos detrás de la tarjetas VISA / MasterCard (4 dígitos en American Express). Fue creado con la finalidad de mejorar la seguridad en las compras sin tarjeta o por Internet. El mecanismo de generación es similar al del CVV1, aunque está diseñado para que sea imposible que CVV1 y CVV2 coincidan. El CVV2 solo es usado en compras por Internet, y no está almacenado en la banda magnética. Tiene un propósito similar al CVV1 y es verificar que la tarjeta es realmente la emitida por el banco y no una generada aleatoriamente. Sin embargo, hay que advertir que el CVV2 no es un requisito para aceptar pagos por Internet (el CVV2 llegó a VISA en 2001, para aquel entonces Amazon ya era importante) y existen webs que admiten pagos con CVV2 incorrecto (como Stripe).

El PIN y el CVV2 tienen propósitos similares, si bien el PIN puede cambiarse y se deja para opeativas físicas, mientras que el CVV2 es inmutable.

Antiguamente los lectores de banda magnética no estaban conectadas a la red y al terminar el día los empleados realizaban todas las operaciones en lote. Con el paso del tiempo y la llegada de Electron y Maestro, los lectores de banda magnética empezaron a estar conectados a las redes EFTPOS.

Chip EMV

EMV hace referencia a Europay, MasterCard y VISA, y es que estas 3 compañías desarrollaron el sistema de chips más usado actualmente para los pagos. Este protocolo, definido en ISO/IEC 7816, incluye muchas ventajas respecto a la banda magnética. La principal diferencia es que si bien la banda magnética los datos estaban tal cual, en los chips EMV podemos incluir un procesamiento, gracias a un chip que se alimenta gracias al lector. Este estándar es todavía más complejo que el de banda magnética, debido a las mejoras que ha ido sufriendo con el paso de los años.

VCC es la entrada de corriente y GND es tierra. RST para resetear la comunicación, VPP para programar la memoria interna. CLK es la señal de reloj, I/O es para las comunicaciones (half-duplex). C4 y C8 son auxiliares y se pueden usar con dispositivos USB.

Uno de los objetivos de EMV fue ofrecer autenticación offline mucho más segura. Además EMV está diseñado para permitir múltiples apps que se ejecuten en el chip, aunque habitualmente las tarjetas solo llevan una app instalada. Aunque en Europa, los chips EMV se usan con PIN, no es estrictamente necesario y también pueden funcionar con firma.

En primer lugar, tenemos que hablar del sistema de autenticación. Todos los sistemas se basan en criptografía de clave pública-privada mediante RSA. El primer sistema es Static Data Authentication (SDA). Este sistema, el más rápido, no necesita que el chip sea capaz de realizar criptografía, sino que tiene los datos ya guardados de forma encriptada (con un criptograma o clave pública) y simplemente se leen. Cuando se realiza un pago, el lector realiza la verificación de la clave pública y si es correcta efectúa el pago. Como vemos, tampoco necesita conectarse a la red para realizar esta verificación, por lo que se ha añadido seguridad sin necesitar de estar conectado con el servidor. Ese sistema impide la modificación de los datos, no obstante es posible clonar enteramente una tarjeta sin ningún problema (copiaremos datos encriptados, pero eso da igual a fin de cuentas).

El segundo sistema, mucho más seguro, es Dynamic Data Authentication (DDA). Este sistema requiere que el chip sea capaz de realizar operaciones criptográficas. Por este motivo las tarjetas con este chip son más caras de emitir, aunque bajo los mandatos de VISA, MasterCard y SEPA, son las más emitidas en Europa desde 2011. La tarjeta en su interior contiene los datos y una clave privada. Cada vez que se realiza la verificación, la tarjeta responde con datos cifrados. Para ello, necesita que el terminal le pase los datos que necesita así como cierto número impredecible o aleatorio. De ese modo, las tarjetas clonadas no podrán responder lo mismo, ya que en realidad no poseen la clave privada del interior del chip. Este sistema permite verificar los PIN de forma segura sin conexión a la red interbancaria.

Flujo de trabajo de DDA

Existe un tercer sistema, denominado CDA o Combined Dynamic Data Authentication. Se trata de una mejora sobre DDA y es que DDA solo realiza la encriptación en el momento de la autorización, dejando el resto de la comunicación abierta. CDA aplica la encriptación a más partes de la comunicación.

RFID-NFC

Hoy en día las tarjetas que se emiten en España cuentan con esta tecnología. Estas tarjetas funcionan siguiendo el protocolo ISO/IEC 14443, en el cuál se definen las etiquetas RFID y los lectores RFID. Las etiquetas, al igual que los chips EMV, no necesitan energía eléctrica por si mismos.

Existen dos tipos de tarjetas contactless, las MSD y las EMV. Las MSD, solo usadas algún tiempo en Estados Unidos no son más que otra manera de leer la información de la banda magnética, con los problemas de seguridad que ya hemos comentado. Las tarjetas EMV sin embargo, siguen los protocolos del chip EMV. En realidad estas tarjetas suelen usar el mismo chip, solo que con dos vías de comunicación: el chip físico, y el RFID. El mayor problema del protocolo RFID original es que no es full-duplex, es decir, solo puede haber comunicación en un sentido. Para solventar este problema nació NFC, que permite comunicaciones bidireccionales. Sobre NFC se puede implementar EMV sin ningún problema.

La tarjeta de N26 es transparente y nos permite ver la antena necesaria para la comunicación

3DSecure

Los pagos online siguieron creciendo después de la introducción del CVV2 y aunque técnicamente está prohibido almacenar el CVV2 en una base de datos sumado al hecho de que no sea obligatorio para una transacción online, el fraude seguía aumentando. Por ello, VISA creó 3D-Secure, un protocolo basado en XML por el que es necesario introducir un código extra en una web propiedad del banco emisor para finalizar el pago. Este código puede ser de un solo uso, enviado por SMS o puede ser un PIN configurado de antemano.

Flujo de trabajo de 3D Secure

En 2016, ante la popularidad de este sistema, el consorcio EMVco lanzó 3DS 2.0, una versión mejorada del sistema, que entre otras cosas puede utilizarse para verificar la identidad de una persona sin necesidad de hacer un pago.

¿Tienes dudas? ¿Quiéres añadir o corregir algo? Usa los comentarios

La entrada Todo lo que debes sobre las tarjetas de crédito, débito y prepago aparece primero en Blog - Adrianistan.eu.

Estimados usuarios de Xailer,

Hoy hemos publicado una nueva versión de Xailer que incorpora toda la documentación y resuelve algunos problemas de la primera versión 5.0.0.

Muchas gracias a todos los que habéis colaborado en la localización de problemas.

Podéis descargar la nueva versión desde el siguiente enlace:

http://www2.xailer.com/download/?es&file=1

Un cordial saludo
[El equipo de Xailer]

Al hablar de FAST, me entraron ganas de recordar viejos tiempos, así que un poco como con Bell/beep en ensamblador, decidí implementar algo sencillito que accediera al hardware de bajo nivel. Lo más tedioso de ensamblador, es que no tienes ninguna biblioteca que tenga implementadas conversiones de números para mostrarlos en pantalla (binario a ASCII), […]

Artículo publicado originalmente en Bitácora de Javier Gutiérrez Chamorro (Guti)

La entrada Uptime para DOS aparece primero en Bitácora de Javier Gutiérrez Chamorro (Guti).

Odiado por muchos, alabado por otros, systemd se ha impuesto como el init por excelencia del mundo Linux. Las distros más populares como Debian, Ubuntu, Fedora, openSUSE y Arch Linux usan systemd por defecto. Hoy vengo a hablaros de una característica interesante de systemd que son son los timers. Se trata de poder definir que arranquen programas/servicios cada cierto tiempo o a una hora, su versatilidad es tal que pueden sustituir a cron en la mayoría de casos. Veamos como usar los timers.

Creando un servicio

Para crear un timer primero necesitamos crear un servicio simple que ejecute el comando que queramos al ser iniciado.

Crea el archivo miapp.service y ponlo en /etc/systemd/system/.

[Unit]
Description=Cat Mania GIF

[Service]
ExecStart=/home/pi/charlatan/catmania.py

 

Creando el timer

Para el timer es necesario un archivo con extensión timer en /etc/systemd/system/. Se suele usar el mismo nombre que el que tiene el servicio para escenarios simples. El archivo miapp.timer quedaría así:

[Unit]
Description=Run Cat Mania daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=5min
Unit=catmania.service

[Install]
WantedBy=timers.target

 

Aquí es donde podemos realizar toda la magia de los timers. Los timers de systemd tienen dos modos de funcionamiento. En el primer modo, systemd ejecutará el timer cada cierto tiempo desde el arranque del sistema ( o algo más tarde si no queremos saturar el sistema). El otro modo es el modo calendario donde podemos especificar fechas y horas con wildcards y patrones. Además, es posible modificar la hora exacta de ejecución del timer con las propiedades de Randomize y que evitan que si hay varios timers configurados a la vez, no lo hagan exactamente a la vez (pero siempre dentro de un margen). Otras opciones para OnCalendar pueden ser:

OnCalendar=Wed,Sun *-*-10..15 12:00:00

En ese caso, el timer se activaría los miércoles y domingos que cayesen entre el 10 y el 15 de todos los meses a las 12 horas.

Activando el timer

Una vez estén copiados los archivos service y timer ejecutamos:

systemctl start miapp.timer
systemctl enable miapp.timer

Ya solo queda esperar a que systemd lance el servicio en la fecha y hora especificados.

Monitorización

Los timers están integrados con systemd, por lo que los logs se registran con journalctl. Podemos inspeccionarlos de forma sencilla:

journalctl -f -u miapp.service
journalctl -f -u miapp.timer

Para revisar los timers instalados y activos en el sistema puedes usar el comando:

systemtctl list-timers

Y ya estaría. De este modo podemos usar systemd como reemplazo de cron. Yo personalmente lo prefiero, ya que me parece una sintaxis más clara.

La entrada Timers en systemd, reemplazo a cron aparece primero en Blog - Adrianistan.eu.

En este post voy a contar de qué se trata el patrón circuit breaker para utilizar cuando dependemos de recursos externos y vamos a ver un ejemplo de implementación en C#.

Objetivo

El objetivo de este patrón es poder manejar un error al cosultar un servicio remoto que puede tomar un tiempo indeterminado en recupearse. La idea es mejorar la capacidad de nuestra aplicación a ser resilente a fallos.

Cuando nuestra aplicación consume un servicio externo puede ocurrir que este servicio sufra problemas momentaneos o que tengamos problemas de latencia o conectividad, en general estos problemas se pueden manejar utilizando el patrón retry, sin embargo si el problema no se resuelve rápidamente ésta no es siempre la mejor estrategia.

Entonces el circuit breaker evita que nuestra aplicación consulte un recurso externo (otra aplicación, un servicio, una base de datos, etc.) que muy probablemente nos de error por un tiempo hasta que se estabilice.

En resumen el circuit breaker se utilizará donde no tenga sentido seguir reintentando que el recurso externo responda y el patrón retry no tendía utilidad y por supuesto trasladar los errores causados por la falla del recurso externo (o la espera a que responda) a nuestra aplicación nos traería otro tipo de problemas como por ejemplo operaciones de que se quedan esperando y consumiendo hilos de ejecución, memoria y potencialmente causando más problemas a nuestra aplicación e incluso podamos empeorar la situación del servicio externo no dándole oportunidad de recuperarse si lo continuamos consultando.

Por último el circuit breaker actuará como un proxy sobre las operaciones que queramos manejar con él, esto por supuesto puede penalizar levemente la performance.

Implementando un circuit breaker con C#

Básicamente el circuit breaker es una máquina de estados que puede exponer los siguientes estados:

• Open: El recurso no está disponible porque se alcanzó un número de fallas en cierto tiempo.
• Half-Open: Estando en Open ha transcurrido un tiempo dado y pasa a este estado, si se puede acceder al recurso se pasa a Closed, si falla se vuelve a Open y se pone el contador en cero
• Closed: el circuito funciona, en caso de detectarse una falla se incrementa un contador, si se alcanza un número determinado en un periodo de tiempo dado se cambiar a Open

Por otro lado tendremos al menos dos parámetros

• Threshold: La cantidad de veces que aceptamos que el recurso externo de error antes de considerarlo en problemas.
• Reset timeout: El tiempo que se esperará antes que volver a intentar consultar el servicio (el tiempo que le daremos a que se recupere)

 

Implemetación simple en C#

Acá dejo una implementación simple den C# utilizando una máquia de estados clásica, esto se puede evolucionar mucho por supuesto.

public interface ICircuitBreaker
{
    /// <summary>
    /// Obtiene la cantidad de fallas aceptadas hasta pasar a estado Open
    /// </summary>
    int Threshold { get; }

    /// <summary>
    /// Obtine el tiempo de espera para pasar a estado Half-Open
    /// </summary>

    TimeSpan Timeout { get; }
    /// <summary>
    /// Obtiene el estado actual
    /// </summary>

    CircuitBreakerState CurrentState { get; }
    /// <summary>
    /// Permite invocar una acción utilizado el circuit breaker
    /// </summary>
    /// <param name="protectedCode">La acción que será invocada</param>
    /// <returns>El estado resultante</returns>
    CircuitBreakerState AttemptCall(Action protectedCode);
}

Esta sería la interfaz de nuestro circuit breaker, es sencilla y se puede mejorar mucho pero sirve para el ejemplo, vamos a la implementación

public enum CircuitBreakerState
{
    Close,
    Open,
    HalfOpen
}

public class SimpleCircuitBreaker : ICircuitBreaker
{
    private int threshold;
    private TimeSpan timeout;
    private int attemptCounter;
    private DateTime failureTime;
    private CircuitBreakerState currentState = CircuitBreakerState.Close;

    public int Threshold => this.threshold;
    public TimeSpan Timeout => this.timeout;
    public CircuitBreakerState CurrentState => this.currentState;

    public SimpleCircuitBreaker(int threshold, TimeSpan timeout)
    {
        this.threshold = threshold;
        this.timeout = timeout;
    }

    public CircuitBreakerState AttemptCall(Action protectedCode)
    {
        switch (this.currentState)
        {
            case CircuitBreakerState.Close:

                try
                {
                    protectedCode();
                }
                catch (Exception)
                {
                    this.attemptCounter++;
                    if (this.attemptCounter > this.threshold)
                    {
                        this.failureTime = DateTime.Now;
                        this.attemptCounter = 0;
                        this.currentState = CircuitBreakerState.Open;
                    }
                }

                break;
            case CircuitBreakerState.Open:
                if (this.failureTime.Add(this.timeout) > DateTime.Now)
                {
                    this.currentState = CircuitBreakerState.HalfOpen;
                }
                break;
            case CircuitBreakerState.HalfOpen:
                try
                {
                    protectedCode();
                }
                catch (Exception)
                {
                    this.failureTime = DateTime.Now;
                    this.attemptCounter = 0;
                    this.currentState = CircuitBreakerState.Open;
                }
                break;
        }
        return this.currentState;
    }
}

La forma de utilizar el código es crear una instancia del SimpleCircuitBreaker y llamar al recurso externo a través del método AttenptCall.

Como vemos una máquina de estados que inicia en Closed y en caso de error incrementa un contador, si se llega el número de fallos permitos (threshold) pasa a Open, si se ha pasa un tiempo dado (el que consideramos que es adecuado para que el recurso externo se recupere) se pasa al Half-Open, si se intenta acceder nuevamente y falla se vuelve a Open, si funciona a Close.

De esta manera todo el código que dependa de recursos externos puede conocer el estado del recurso y esperar para llamarlo en caso que se encuentre en fallo.

Como dije se puede mejorar mucho este código no tiene sentido para explicar el concepto hacerlo ahora.

Les dejo un link con el código en github.

Nos leemos.

En el artículo de iniciación a la programación concurrente en Java explicaba las facilidades que proporciona este lenguaje para la programación de tareas con varios hilos que implica la sincronización y bloqueo mediante varias primitivas como semáforos o locks, ponía el ejemplo y su código de dos de los típicos ejemplos que suelen usarse en las asignaturas de sistemas operativos, el problema de los filósofos y el del barbero.

En el caso de tener varias tareas que tardan unos segundos si las ejecutamos de forma secuencial el tiempo que tardarán será la suma de todas las tareas. Si las tareas no son dependientes, no hace falta esperar a que termine una anterior para comenzar otra, o el problema se puede descomponer en varias partes ejecutándolas de forma concurrente y simultáneamente el tiempo total que tardarán aproximadamente será el tiempo de la tarea más lenta.

En la API de Java además de las primitivas de sincronización se ofrece además algunas clases para manejar hilos y tareas a ejecutar de forma concurrente sin tener que manejar los hilos a bajo nivel. La clase ExecutorService permite crear un pool de threads con un número fijo de ellos, el pool reutilizará cada thread para ir ejecutando las tareas. Crear threads es una operación más o menos costosa con lo que reutilizándolos se aprovecha mejor los recursos del sistema y en un número grande de tareas a ejecutar la mejora en el rendimiento quizá se note. Crear un pool con un número fijo y limitado de threads evita que el sistema se sature o por el contrario esté infrautilizado, configurando el tamaño del pool de threads según las características del sistema que las ejecutará y del tipo de recursos que más utiliza las tareas se obtiene el mejor rendimiento posible.

Con el método Runtime.availableProcessors se obtiene el número de núcleos lógicos del ordenador de los modernos procesadores que utilizan Hyper Threading tanto los de Intel como AMD, si las tareas hacen un uso muy intensivo de CPU y poco de entrada/salida el tamaño del pool de threads óptimo será cercano al número de núcleos del procesador. Por el contrario, si las tareas hacen un uso intensivo de de entrada/salida el tamaño del pool de threads óptimo será mayor ya que estarán la mayor parte del tiempo esperando a que finalicen las lentas operaciones de entrada y salida comparadas con la CPU.

Suponiendo que una aplicación ha de realizar varias consultas a una base de datos para presentar su información al usuario, esas consultas y por la cantidad de información que tiene la base de datos o porque los índices no ayudan tardan en ejecutarse 3 segundos, teniendo que realizar 8 de estas consultas el tiempo total que tardará la aplicación en presentar la información será de 24 segundos (8 tareas x 3 segundos/tarea) ejecutando las consultas de forma secuencial. 24 segundos es un tiempo considerable y el usuario pensará que la aplicación no responde. Ejecutando las tareas con un pool de 8 threads el tiempo total empleado para presentar la información será de 3 segundos y con un pool de 4 threads el tiempo será de 6 segundos, mucho menos que los 24 de forma secuencial.

Este es el código para ejecutar tareas de forma secuencial y de forma concurrente con un pool de threads de tamaño el doble del número de procesadores del sistema midiendo además el tiempo total para comprobar la diferencia de tiempos de ambas opciones.

El código fuente completo del ejemplo puedes descargarlo del repositorio de ejemplos de Blog Bitix alojado en GitHub y probarlo en tu equipo ejecutando el comando ./gradlew run.

Sin hacer muchos alardes y un poco por los pelos, parece que he conseguido llegar al sexto año con el blog.

En total son ya 326 entradas (algunas tan inútiles como ésta) en las que he repasado temas de lo más variado, desde muy técnicos y específicos hasta ideas raras que me rondan por la cabeza, pasando por aspectos genéricos del desarrollo de software e historias de abuelo cebolleta.

Siempre he mantenido que escribo el blog principalmente para mi, pero debo reconocer que después de tanto tiempo hay momentos en los que me siendo en deuda con la gente que se ha molestado en dejar comentarios, enseñarme cosas y hacerme pasar muchos buenos ratos. Por eso, y aunque siempre he odiado este tipo de posts cuando me los encuentro en otros blogs, creo que los que compartís conmigo un rato de vez en cuando leyendo alguno de mis posts os mereceis saber qué va a ser de este blog.

No hace falta ser ningún lince para darse cuenta de que últimamente la frecuencia de posteo ha ido disminuyendo. Si hace unos años había un post todas las semanas, mi objetivo en los dos últimos años ha sido menos ambicioso, y en los últimos meses a duras penas consigo publicar un post cada dos semanas. Me temo que eso no va a cambiar en un futuro próximo.

Ahora mismo estoy embarcado en un proyecto personal de casi cinco meses y siete kilos de peso que tiene prioridad máxima para mi. La buena noticia es que, con mayor o menor actividad, mi intención es mantener el blog vivo y seguir escribiendo siempre que tenga un hueco. Además, mi referente me ha dicho que es normal pasar por rachas así y yo confío plenamente en él ;-)

Y a descansar unas semanas

Cada año llego a estas fechas con las energías más justas (será cosa de ser un viejo), y los últimos 10 meses han sido especialmente agotadores, así que toda disfrutar de las vacaciones, del nuevo proyecto, y descansar unas semanas.

Como siempre, descansar no significa olvidarme (por completo) del mundo del desarrollo, y seguiré quejándome de cosas y discutiendo por nimiedades en twitter.

¡Disfrutad del verano!

No hay posts relacionados.

Desde que Mozilla publicó Firefox Focus para Android (¡hace menos de un mes!), la aplicación fue descargada 1 millón de veces. Ya cuentan con más de 8.000 comentarios, y la aplicación tiene un rating de 4.5 estrellas. Muy buena respuesta por parte de la comunidad al hermoso navegador simple, rápido y orientado a la privacidad que nos brinda Mozilla.

En mi caso vengo usándolo prácticamente a diario, es al que voy por defecto. Si necesito algo extra, puedo abrir el sitio que estoy viendo en Firefox estándar. También he conseguido que más de una persona empiece a usarlo por puras recomendaciones (Mozilla, give me free stuff!).

Junto a este festejo se agregaron 3 nuevas características. Prestando atención a los comentarios de los usuarios, se juntaron las características que se pudieran agregar rápidamente y en menos de un mes del lanzamiento, ahora contamos con:

• Videos a pantalla completa: Algo que estaba esperando, aunque justo no funciona (todavía) para YouTube… Parece que se volvió una prioridad debido a los comentarios de usuarios. “Entendemos que si vas a mirar un video en tu teléfono, sólo vale la pena si se puede expandir al tamaño completo de la pantalla de tu teléfono celular.” Se agregó soporte para la mayoría de los sitios siendo YouTube la excepción más notable. El soporte para YouTube depende de la corrección de un bug por parte de Google y será incluido apenas esté arreglado.
• Soporte de descargas: Se actualizó la aplicación para permitir descarga de archivos de todo tipo
• Actualización de las acciones de las notificaciones: Ahora no sólo sirven para recordarnos borrar el historial. También incluyen la opción de abrir Firefox Focus a través de las notificaciones.

Mozilla tiene la misión de asegurarse que sus productos satisfagan las necesidades de los usuarios.Responder al feedback con mejoras rápidas y notables es su forma de decir gracias y dejarnos saber que nos están escuchando. Puedes descargar la última versión de Firefox Focus en Google Play y  App Store.

Durante mis comienzos, me topé gracias al Shareware, con una grata sorpresa. Se trataba del lenguaje de programación FAST. Un lenguaje que jamás llegué a conocer a nadie que lo conociera, pero que en aquellos días de Turbo BASIC, me parecía increíble. FAST Compiler, generaba archivos .COM para DOS extremadamente pequeños, y ofrecía una velocidad […]

Artículo publicado originalmente en Bitácora de Javier Gutiérrez Chamorro (Guti)

La entrada FAST Compiler aparece primero en Bitácora de Javier Gutiérrez Chamorro (Guti).

Hasta Java 5 para hacer un bucle desde 0 a N elementos había que usar una variable para mantener un contador, hacer una comparación para comprobar si se había llegado al límite e incrementar la variable en la siguiente ejecución. El código era bastante verboso y dado que los bucles son una construcción básica de cualquier lenguaje de programación es empleada numerosas veces en cualquier algoritmo. Antes de Java 5 un bucle for de 0 a 5 y de una colección se realizaba de la siguiente manera:

En Java 5 el bucle for se enriqueció notablemente, con el foreach se puede recorrer una colección y cualquier objeto que implemente la interfaz Iterable. Con el bucle foreach una Collection se recorre de la siguiente manera.

Pero esto es para las colecciones si se quiere hacer un bucle un número fijo de veces como en el primer caso de 0 a 5 conociendo que para usar el foreach basta que le indiquemos un objeto que implemente la interfaz Iterable podemos usar la siguiente expresión y su implementación que tiene la ventaja de no tener que incluir la expresión de comparación y el incremento de la variable, la clase Counter implementa la interfaz Iterable y devuelve un Iterator sobre los valores del rango indicado:

En Java 8 con la introducción de los Stream y de IntStream podemos usar el método range y rangeClosed para obtener un Stream de enteros y hacer un bucle con un comportamiento similar a los anteriores.

Los Stream de Java 8 están muy bien para simplificar algunas operaciones complejas pero para un bucle for sencillo tiene sus inconvenientes como ofuscar significativamente el stacktrace en caso de producirse alguna excepción. Se puede usar cualquier opción pero la primera con el tradicional bucle for sea la menos recomendable teniendo a nuestra disposición la clase Counter con Java 5 o los Stream y lambdas con Java 8.

El siguiente programa muestra las cuatro opciones, su salida en la consola sería el siguiente:

El código fuente completo del ejemplo puedes descargarlo del repositorio de ejemplos de Blog Bitix alojado en GitHub y probarlo en tu equipo ejecutando el comando ./gradlew run.