jueves, 10 de enero de 2013

Installing Chef Server with Omnibus installer

I have a broad experience on configuration management. I've used Cfengine, Puppet, and several others, but currently, i'm in love with Opscode's Chef

Not only a good tool, but a complete toolkit to build your devops dreams: CM, CMDB, inventory, ...

Recently, Opscode guys change the way on they distribute their product, using Omnibus. I'll try to install and configure Chef Server, using chef-solo method.


curl -L http://www.opscode.com/chef/install.sh | sudo bash

Checkout install dir:

ls -l /opt/chef

Type chef-client. You must see something similar to this

[Thu, 30 Aug 2012 07:57:53 +0000] WARN: *****************************************
[Thu, 30 Aug 2012 07:57:53 +0000] WARN: Did not find config file: /etc/chef/client.rb, using command line options.
[Thu, 30 Aug 2012 07:57:53 +0000] WARN: *****************************************
[Thu, 30 Aug 2012 07:57:53 +0000] INFO: *** Chef 10.12.0 ***
[Thu, 30 Aug 2012 07:57:55 +0000] INFO: Client key /etc/chef/client.pem is not present - registering
[Thu, 30 Aug 2012 07:57:55 +0000] WARN: Failed to read the private key /etc/chef/validation.pem: #
[Thu, 30 Aug 2012 07:57:55 +0000] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[Thu, 30 Aug 2012 07:57:55 +0000] FATAL: Chef::Exceptions::PrivateKeyMissing: I cannot read /etc/chef/validation.pem, which you told me to use to sign requests!


Don't worry. It's OK. Simply we don't have a working chef API server to register our chef server (recursive error ahead! :P )

Every Chef installation needs a Chef Repository. This is the place where cookbooks, roles, config files and other artifacts for managing systems with Chef will live.

I'd prefer use GIT to manage Chef's repo, but my projects mates are currently using subversion, so we'll go to the "unsupported" way of life :D

wget https://github.com/opscode/chef-repo/tarball/master
tar zxf master
mv opscode-chef-repo-a3bec38/ chef-repo
svn add chef-repo


Create /etc/chef/chef-solo.rb file:

file_cache_path "/tmp/chef-solo"
cookbook_path "/tmp/chef-solo/cookbooks"
recipe_url "http://s3.amazonaws.com/chef-solo/bootstrap-latest.tar.gz"




Create /etc/chef/chef-solo.json:


{
"bootstrap": {
"chef-server": {
"init_style": "init",
"server_fqdn": "vm-chef-server.example.es",
"webui_enabled": true
}
},
"run_list": [ "recipe[chef-server::rubygems-install]" ]
}



If you are using Vagrant, note that Vagrant includes a fully functional ruby environment, located at /opt/vagrant_ruby, who makes chef-solo's install fails, because Omnibus installer use this Ruby path instead the Omnibus provided. As a simple solution, launch chef-solo with explicit ruby PATH


mv /opt/vagrant_ruby /opt/vagrant_ruby_old
export PATH=/opt/bin:$PATH
sudo chef-solo -c /etc/chef/solo.rb -j /etc/chef/chef.json


Previously, we must install build-essential package, that installs g++, make and other tools of the trade. If not, Chef Ruby fails with a not very descriptive message:

--without-/opt/chef/embedded/lib/ruby/1.9.1/mkmf.rb:368:in `try_do': The complier failed to generate an executable file. (RuntimeError)
You have to install development tools first.


If everything goes fine, you must have a fully functional Chef server, with the webUI listening on port defined. Just fire sudo ss -lnp or sudo lsof -i -nto see port number

Next step: managing Chef.
The system where you are doing development and maintaining a cookbook repository we can call a workstation or your management workstation. It is where you run knife commands. Let's create a knife.rb file that works with our new shiny server

sudo knife configure -i
WARNING: No knife configuration file found
Where should I put the config file? [/home/sadiel/.chef/knife.rb]
Please enter the chef server URL: [http://vm-chef-server:4000]
Please enter a clientname for the new client: [sadiel] root
Please enter the existing admin clientname: [chef-webui]
Please enter the location of the existing admin client's private key: [/etc/chef/webui.pem]
Please enter the validation clientname: [chef-validator]
Please enter the location of the validation key: [/etc/chef/validation.pem]
Please enter the path to a chef repository (or leave blank):
Creating initial API user...
Created client[root]
Configuration file written to /home/sadiel/.chef/knife.rb


We use sudo command, because we need read-write access to /etc/chef directory.

In /home/sadiel/.chef we can found two files:

  • knife.rb: tells knife how to interact with the server API
  • root.pem: RSA certificate that identifies node_name "root" user defined on knife.rb

You must copy to your management workstation. Adapt file paths and URL to reflect your settings. Don't forget to chmod 600 files. These are chef-repo/.chef/knife.rb contents:

current_dir = File.dirname(__FILE__)
log_level :info
log_location STDOUT
node_name 'root'
client_key "#{current_dir}/root.pem"
validation_client_name 'chef-validator'G
validation_key '/etc/chef/validation.pem'
chef_server_url 'http://vm-chef-server:4000'
cache_type 'BasicFile'
cache_options( :path => '#{current_dir}/checksums' )

Test your settings with knife client list.


OK, you are the proud father of a chef server.






miércoles, 16 de mayo de 2012

Installing RPMs on a good old Red Hat


I don't have a subscription for RHEL anymore and I want to update my server. What can I do?

CentOs claims to be "binary-compatible" with every RH release. Well, this is not really true, but can be a nice solution for little packages upgrades.

So, I created a file /etc/yum.repos.d/CentOs.repo with the following contents

[CentOS-Base]
name=CentOS-Base
mirrorlist=http://mirrorlist.centos.org/?release=5&arch=$basearch&repo=os
gpgcheck=1
enabled=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5

[CentOS-Updates]
name=CentOS-Updates
mirrorlist=http://mirrorlist.centos.org/?release=5&arch=$basearch&repo=updates
gpgcheck=1
enabled=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5

[CentOS-Plus]
name=CentOS-Plus
mirrorlist=http://mirrorlist.centos.org/?release=5&arch=$basearch&repo=centosplus
gpgcheck=1
enabled=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5



Watch out!!! If you install so many packages, it becomes on a CentOs! :D

lunes, 25 de abril de 2011

ext3 commit overload

At CGA, we used to face up problems usually tagged as "weird".
Sometimes, these are implementation problems. 

Well, some Incident Management folks needs help with a server located at several
km. away from office. The server has a looong history of faulty services, mainly 
relationed with server performance.
Incident Management folks have been done a good work trying to debug the server
behaviour: switches, tagged ports, cable link, disk I/O ...  But the problem
still persist, and is affecting user's daily work. This turns this problem into a 
SLA problem!
We've two servers for each educational center -real or virtual-
- one for security services: firewall, DHCP, cache and content filtering
(via Dansguardian), etc
- another one for user data and user centric services:  Helvia, Moodle, and users 
home directory exported through
NFS exports and LDAP user profiles. 

Educational Centrers differs on users volume: from almost testimonial usage
to *real* intensive. This Educational centre have a high ratio of NFS usage,
and Incident Management folks ask me if I can help on find the servers poor
performance root.

Server c0 is a vanilla Debian 4.0, with nfs-kernel-server and ext3 disks. 
The problem is about disk contention: top command shows loadvg from 18 to 53.
That's scary: this values NEEDS be close to zero. 

 
Let's go:  
 
First round: Discarding network and hardware (RAID 5) problems, I've to see
 if filesystems need some tunning, mainly related to noatime fstab mount options.
 After study the situation, and have implemented the disaster recovery scenario,
 the most simple solution would be remount /home partition with noatime activated
. 
No results :-(
  
Second round: This is a typical high performance write error on journaled 
filesystems, but some of others filesystems (including commercial ones) don't have
a  good set of debugging tools. Fortunately, Linux do it.
I need to know what process is hitting on disk performance, so I  simply have
to activate the sysctl's vm.block_dump switch (accessible too via 
/proc/sys/vm/block_dump). BUT it's are a performance killer! Think on these: 
if the problem is that some process it's squashing disk performance, 
activating vm.block_dump means that EVERY disk use is logged to /var/log/syslog 
and /var/log/debug. OOOUch!
Keep in mind that this is a production server, with user data, and SLA time 
under fire!.
The best approach is create a RAM disk, and redirect syslogd.conf entries to
it, so logging don't affect to server performance.
These are an example of file contents:

kjournald(2008): WRITE block 8672240 on sda7
kjournald(2008): WRITE block 8671568 on sda7
kjournald(2008): WRITE block 4267496 on sda7
kjournald(2008): WRITE block 14760 on sda7
kjournald(2008): WRITE block 14768 on sda7
kjournald(2008): WRITE block 14776 on sda7
kjournald(2008): WRITE block 14784 on sda7
kjournald(2008): WRITE block 14792 on sda7
kjournald(2008): WRITE block 14800 on sda7
kjournald(2008): WRITE block 14808 on sda7
kjournald(2008): WRITE block 14816 on sda7
kjournald(2008): WRITE block 14824 on sda7
kjournald(2008): WRITE block 14832 on sda7
kjournald(2008): WRITE block 14840 on sda7
kjournald(2008): WRITE block 14848 on sda7
kjournald(2008): WRITE block 14856 on sda7
kjournald(2008): WRITE block 14864 on sda7
kjournald(2008): WRITE block 14872 on sda7
kjournald(1129): WRITE block 31440 on sda1
pdflush(166): WRITE block 64 on sda6
pdflush(166): WRITE block 136 on sda6
pdflush(166): WRITE block 184 on sda6
pdflush(166): WRITE block 224 on sda6
pdflush(166): WRITE block 280 on sda6
pdflush(166): WRITE block 336 on sda6
pdflush(166): WRITE block 352 on sda6
pdflush(166): WRITE block 472 on sda6
pdflush(166): WRITE block 504 on sda6
pdflush(166): WRITE block 600 on sda6
pdflush(166): WRITE block 664 on sda6
pdflush(166): WRITE block 728 on sda6
pdflush(166): WRITE block 880 on sda6
pdflush(166): WRITE block 4560 on sda6
pdflush(166): WRITE block 6144 on sda6
pdflush(166): WRITE block 6272 on sda6
pdflush(166): WRITE block 6328 on sda6
pdflush(166): WRITE block 262232 on sda1
pdflush(166): WRITE block 262264 on sda1
pdflush(166): WRITE block 262296 on sda1

As you can see, the problem is write contention. pdflush and kjournald,
 by default, commit data to disk every 5 seconds. If the server is under heavy 
load, these 5 sec. may not to be sufficient to write all data to disk, so more 
contention happens!
 
Well, the real problems was NFS's sync mount option on exported filesystem. Every cliente who
needs write data to server disk was causing several fsync() calls, causing I/O penalty while 
writing info to disk. The solution was simple: exports NFS's filesystem with async option enabled
 
Voilá! Problem solved.  
 
 

 
 

martes, 12 de abril de 2011

DevOps: irse por las nubes

¿Qué es DevOps?

Conjunto de procesos, métodos y sistemas para agilizar la comunicación, colaboración e integración entre departamentos de desarrollo (Dev), operaciones (Ops), Seguridad (Sec) y calidad (QA)

Es un concepto que busca la integración entre las áreas de desarrollo, operaciones, seguridad y calidad para satisfacer los cambiantes requerimientos de negocio, mientras se minimizan los riesgos que implica ese cambio.


¿Por qué debería de interesarme?

DevOps no es la respuesta a un problema tecnológico, lo es a un problema de negocio.


¿Y cuál es el problema?

1. Muchos proyectos están fallando debido a problemas en la transferencia (sea a producción, sea del conocimiento), que afectan en tiempo, dinero y alcance. Básicamente: un problema de velocidad de adaptación.

2. La operación del software desarrollado es YA un requisito no funcional, que evita la pérdida de tiempo, dinero y modifica el alcance. Un software que no contempla las necesidades de quienes realmente van a gestionarlo, es por definición, un software abocado a ser "odiado" y que no provocará interés en ser mantenido o ampliado.

3. Existe un "muro de confusión" entre Desarrollo y Operaciones, causado por una combinación de motivaciones, procesos y herramientas no siempre con objetivos alineados. Aún peor es el escenario donde Desarrollo es un ente externo a Operaciones.

4. El equipo que realizó en desarrollo raramente tiene que lidiar con los resultados a largo plazo de sus decisiones respecto a la arquitectura y decisiones, por lo que no cuentan con incentivos para mantener una cultura de explotación y mantenimiento de las aplicaciones que desarrollan

5. Los equipos de soporte, mantenimiento y operaciones, generalmente, cuentan con escasos recursos, tienen pocas oportunidades de cambiar de proyecto -fruto de la falta de transferencia de conocimientos-, y deben alternar sus tareas entre diferentes proyectos. Esto usualmente lleva a unas prácticas de operación que hacen que la calidad total del producto se deteriore a medida que pasa el tiempo, que a su vez implica que sean necesarias más horas de soporte.

6. El equipo del proyecto generalmente no se ve involucrado en el análisis de los problemas en el entorno de producción, y no sienten la necesidad de implementar los mecanismos necesarios para encontrar la causa raíz de un problema.

7. El equipo de desarrollo tan sólo realiza un limitado número de liberaciones de software para su puesta en producción, por lo que no encuentran incentivos a la hora de automatizar tareas y procesos, ni realizar pruebas en entornos de pre-preducción


¿Qué ventajas aporta?

La solución combina las visiones del área de Desarrollo (eminentemente innovadora) con la de gestión de la infraestructura (eminentemente conservadora) , integrando ambas bajo unos procesos que posibiliten la sencillez de operación de la plataforma, faciliten la creación de interrelaciones entre las tareas de estos grupos y habiliten nuevos procesos colaborativos, todo ello siempre enfocado hacia la mejora continua, la estabilidad y la obtención del máximo beneficio de la inversión en infraestructuras y equipos de operaciones y desarrollo, para lo cual es necesario que se realicen pruebas de calidad de los productos.

Todo nace con una idea
El proceso de negocio fundamental de cualquier organización es llevar una idea desde su concepción hasta el punto en el que genera beneficios, sean tangibles o intangibles. Para ello es necesario afinar los procesos que lo llevarán a cabo: algunos de ellos se centran en aspectos tecnológicos y otros en aspectos humanos. Aquí es donde entran en juego desarrolladores, operadores, calidad , arquitectos, gestión del cambio, seguridad... cada uno tiene que hacer su parte, del mismo modo que se trabaja en una cadena de montaje.

Si quitamos el contexto de los procesos de negocio ¿Qué nos queda?
Pues queda un montón de gente haciendo ”sus labores”, con lo que se pierde totalmente el incentivo de luchar contra la ineficiencia, la duplicación de esfuerzos, y el desacoplamiento de objetivos entre estos grupos.

!Salvese quien pueda!
Empiezan las acusaciones cruzadas: "falta documentación, ¿esto quién lo ha hecho? ¿por qué?"
Por lo tanto, y por el bien de ”nuestro negocio”, nuestra misión es reaccionar ante las demandas de más servicios, más estables, más productivos y en menos tiempo, de la forma más rápida, eficiente y disponible posible.

La palabra de moda es Ágil

¿Esto no suena mucho a las metodologías ágiles utilizadas en el desarrollo de software?

En efecto, sus aproximaciones a la solución de los problemas del negocio son similares, y por lo tanto, no deben de crearse ”islas de procesos, herramientas y personas”

Mientras que Agile Dev se centra en la creación y entrega de software, DevOps se centran en mejorar la integración y facilitar flujo entre las distintas fases de operaciones, acortando el ciclo de tiempo desde la concepción a la operación de un proyecto. Cuando nuevas metodologías de desarrollo (como aquellas conocidas como ágiles) son adoptadas en una organización TI basada en la tradicional separación por roles se crea una tensión interdepartamental fruto de la necesidad de ajustar las interrelaciones entre estos departamentos.

Por ello, DevOps es algo más: es un conjunto de procesos y métodos para aumentar la comunicación y colaboración entre departamentos. Las organizaciones que no ajustan estas deficiencias comunicativas, ven como paulatinamente la efectividad aumenta en el área de desarrollo, pero empiezan a ocurrir problemas en el resto de las áreas de las TI.

La adopción de DevOps está siendo impulsada por factores como:
1. El uso de procesos y metodologías de desarrollo ágiles

2. La demanda de mayor agilidad en la puesta en producción de versiones

3. Amplia disponibilidad de infraestructura virtualizada y en la nube, tanto interna como externa, y los cambios de mentalidad y métodos de trabajo que ello implica.

4. Incremento de uso de herramientas de la gestión de la configuración y automatización del CPD.

5. El uso de prácticas producción Just In Time: «producir los elementos que se necesitan, en las cantidades que se necesitan, en el momento en que se necesitan».

La mejora de la relación y colaboración aumenta la eficiencia y reduce el riesgo en la entrega, asociado a los cambios frecuentes en las prioridades, requisitos y objetivos de los procesos productivos.


¿Por qué se crea esa fricción?


Muchas organizaciones dividen las áreas de desarrollo y operación TI en diferentes departamentos. Mientras que los primeros son presionados por la necesidad de proveer frecuentes entregas de software con nueva funcionalidades, los segundos tienen como objetivo principal la estabilidad, disponibilidad y eficiencia de la infraestructura TI, lo que ralentiza la entrega del Servicio y su valor para el negocio.

  • Los grupos de desarrollo no son conscientes acerca del impacto de su código en el área de operación de sistemas. Simplemente lo liberan sin involucrar a Operaciones TI en las decisiones que corresponden a la arquitectura de la aplicación.
  • Los grupos de desarrollo fallan a la hora de comunicar la configuración o los cambios necesarios sobre el sistema base
  • plican configuraciones manualmente en sus puestos de desarrollo y no documentan el proceso paso a paso. Muchas veces es necesario realizar ciclos de "prueba-error" hasta que se logra el resultado deseado, dando el resultado de que no se tiene claros qué pasos son los mínimos para que se apliquen efectivamente los cambios necesarios.
  • Suelen tender a utilizar herramientas optimizadas para el desarrollo rápido, que son muy diferentes de los entornos donde realmente se van a ejecutar las aplicaciones, donde lo que prima es la estabilidad y el rendimiento.
  • Dado que programan en sus propias estaciones de trabajo, generalmente no se utiliza el sistema operativo que será el utilizado en la fase de producción dando lugar a problemas e incompatibilidades.
  • Durante el desarrollo, suelen utilizar entornos centralizados, mientras que en la producción cada vez es más frecuente encontrar sistemas distribuidos entre varias máquinas, sobre todo en entornos en la nube.
  • Los desarrollos están basados en los requisitos funcionales extraídos de las necesidades del negocio.Sin embargo, el área de operaciones TI se centra en requisitos como disponibilidad, estabilidad, rendimiento...
  • Operaciones intenta minimizar los riesgos en la infraestructura de la peor manera posible: evitando los cambios
  • Si se evitan los cambios frecuentes en operaciones, pero estos siguen sucediendo en desarrollo, se crea una cola de cambios cada vez más grande que termina por colapsar ambos procesos, necesitando cambios más grandes.
  • Cambios más grandes implican mayores riesgos
  • Operaciones puede no estar completamente al tanto de las particularidades internas de la aplicación, haciendo difícil el diagnostico de problemas y procedimientos de puesta en producción.
  • Desarrollo puede no estar completamente al tanto de las particularidades internas de la plataforma, haciendo difícil la adaptación del código a ésta .

¿Cómo se lleva a la práctica?

Fruto de lo anterior, ha aparecido un nuevo rol en TI cuya principal misión es la coordinación de las tareas de despliegue en los entornos de pre-producción. La necesidad de estos nuevos perfiles vienen de:

  • La necesidad de "acercar" desarrollo y operaciones
  • Transmitir el conocimiento la cada vez más compleja infraestructura TI: múltiples componentes desacoplados que establecen relaciones de interdependencia, que muchas veces no son visibles.
  • Potenciar el número de entregas a producción, utilizando técnicas de desarrollo ágil e iterativo
  • Equipos distribuidos: outsorcing, factorías de software, near-shore, off-shore, ...

El rol de Coordinador de Releases es similar al de un controlador aéreo, realizando tareas de coordinación entre diferentes equipos a fin de lograr una orquestación de las entregas, usando recursos compartidos por los equipos. Su área de competencia encaja dentro de la Gestión del Cambio, que es una disciplina relativa a la gestión de todo tipo de cambios en la infraestructura TI, y que es un rol principal en ITILv3.

El mantra de el coordinador de versiones es:

  • Si cuando se escribe una aplicación se usan tests unitarios y pruebas de integración para asegurarnos de que la aplicación cumple las expectativas ¿Por qué no hacer lo mismo con la infraestructura?
  • Cambios pequeños implican menores riesgos.
  • Hay que proveer a los desarrolladores de más conocimiento de la plataforma sobre la que se ejecuta.
  • Hay que proveer a los operadores de un conocimiento más profundo de la aplicaciones.
  • Instauración de procesos simples y conocidos por todos, frente a procesos complejos y conocidos sólo por expertos
  • Automatización de todo lo que no sea extremadamente necesario realizar a mano.
  • Establecimiento de una metodología de colaboración activa entre las áreas implicadas, utilizando prácticas de SCRUM y/o Kanban

Conclusión

Podríamos concluir con que DevOps es en realidad una disciplina que combina las de áreas de ingeniería del software y operaciones, que se focaliza en el desarrollo del software para dar soporte a la infraestructura sobre la cual se ejecuta el software con el que los usuarios interactúan. A veces es conocido como desarrollo de sistemas , desarrollo de infraestructuras o infraestructure as code

¿Qué hace diferente un devops frente al clásico perfil de administrador de sistemas o desarrollador?

1. Habilidad de escribir código más allá de simples scripts. Dado que la infraestructura ya no depende del hardware, el comportamiento y componentes de la infraestructura pasa a codificarse y debe de ser considerada como parte del programa

2. Focalización en la estabilidad y disponibilidad de la plataforma. Un claro legado del área de operaciones, y el principal motivo de ésta.

3. Seguimiento exhaustivo de los estados en transición. Dado que ahora el software cambia rápidamente , las transiciones entre los estados de desarrollo, pruebas, pre-producción y producción deben de recibir toda la atención que se merecen.

4. Un ángulo de visión diferente del Negocio. Mientras que la misión de los desarrolladores es crear software que aporte ganancias al negocio, los devops tienen la misión de la prevención y reducción de eventos que impactan en el negocio. La clave está por lo tanto en el equilibrio entre estas facetas.


5. Los devops son los usuarios del software que ellos mismos desarrollan. Por lo tanto, nadie más que ellos van a sufrir las consecuencias de malgastar tiempo extra en encontrar la información necesaria para cumplir con sus objetivos.

6. Arquitectos, desarrolladores, tester, ... todos juntos. Si DevOps orbita alrededor de la colaboración entre "islas de roles", es natural que se establezcan las prácticas culturales necesaria como para que la diseminación del conocimiento se lleve a cabo y sea efectivo.

7. Consciencia de la existencia errores. No importa cuánto esfuerzo se ponga en el diseño de un sistema: un sistema complejo, tarde o temprano, experimentará un error imposible de predecir, fruto de la interacción (no programada) de los componentes. En Google, Amazon, y otros entornos distribuidos por ejemplo, han modelado sus sistemas teniendo esto en cuenta.

8. Calidad en producción. Algunas tareas no pueden ser adecuadamente probadas en entornos de prueba más pequeños o menos complejos que el entorno de producción. El desarrollo en fases y otras técnicas intentan reducir el riesgo, pero debemos ser conscientes de que obtener métricas de disponibilidad, capacidad, etcétera, sólo son válidas en el entorno de producción

9. Primero manual, después automatización. Cuando se valida un proceso productivo ES el momento de automatizarlo. Desarrollo no contará con tiempo para implementar el método automatizado, acuciado por los plazos. En producción, por lo tanto no será aceptable código que no cuente con código que automatice el despliegue y la operación

10. Los sistemas distribuidos son la norma. Los Sistemas de Información, con la explosión de la virtualización y el despliegue en Cloud, tienden a ser completamente distribuidos y sin estados. Esto es pasar de un modelo donde el Sistema de Información se modela "dentro de un CPD" a un modelo donde no sólo no existe el concepto de propiedad, sino que además los servicios pueden ejecutarse en distintas máquinas en distintos CPDs, tanto internos como externos.

jueves, 13 de enero de 2011

The Spanish government acknowledges the work done by the Linux community

The Spanish government has issued a note on the name used in an operation against the terrorist group ETA: Operation Linux.

In order to avoid FUD storm expected to associate "Linux = terrorism", Hispalinux and other groups have asked Ministerio del Interior to establish an acclaration note explaining the reasons of the name. The ministry's response was this:

http://www.mir.es/DGRIS/Notas_Prensa/Ministerio_Interior/2011/np011204.html

Not bad. But the best comes last:

"4 .- Similarly, the Home Office is grateful for the free development of technology based on the Linux operating system, driven by users, organizations and businesses, and is an extremely useful tool for research by Force and State Security Forces to ensure the safety of citizens. "


This note it's not an OSS victory, it's only a finding on several goverments has adopted OSS not for political reasons, just for it's works. That's the good news.

lunes, 20 de diciembre de 2010

Open Goverment

Just a quick  note:

O'Reilly Media just published a sample of their book about Open Goverment: 140 pages!

If you're interested in Digital Democracy and citizen participation, it's a must read!

Open Goverment Sampler

miércoles, 24 de noviembre de 2010

Neutralidad de la red ¿Perderemos otra revolución industrial?

Todos recordaréis el festival del humor protagonizado por César Alierta, así como su amplísimo conocimiento del medio.





En este blog analizan el impacto real que podría llegar a tener una decisión de este tipo en manos de un tipo como este.