1)Si es un sistema en el que teneis root:
yum install python-pip
pip install pyotp

2) Creamos un token con freeotp tomando nota del secret

3) El script en python:
#!/usr/bin/env python
# -*- coding: utf-8 -*-

import pygtk
pygtk.require(‘2.0’)
import gtk
import time
import sys
import datetime
import pyotp
totp = pyotp.TOTP(“$SERIAL”)

class Token:

def __init__(self):
window = gtk.Window(gtk.WINDOW_TOPLEVEL)
window.connect(“destroy”, lambda w: gtk.main_quit())
window.set_title(“My Token”)
self.label = gtk.Label()
window.add(self.label)
window.set_border_width(25)
window.show_all ()

def update(self):
currentotp = str(totp.now()).zfill(6)
seconds=30 – (int(datetime.datetime.now().strftime(‘%S’)) % 30)
self.label.set_text(“Token : ” + currentotp + ” Remaining seconds ” + str(seconds))
return True #needed to keep the update method in the schedule

def main():
gtk.main()

if __name__ == “__main__”:
token = Token()
gtk.timeout_add(200, token.update) #add to the main loop scheduled tasks
main()

4) Gnome launcher:
.local/share/applications/mytoken.desktop
[Desktop Entry]
Encoding=UTF-8
Name=MyRsa
Exec=/home/jramirez/bin/mytoken.py
Icon=/home/jramirez/Desktop/mytoken_icon.png
Type=Application
Categories=Development;

#TODO:
clipboard with a button

Red Hat provee imágenes en formato qcow2, listas para ser desplegadas en entornos que permitan el uso de cloud-init, como por ejemplo OpenStack o RHEV.

Basandome en una idea de Eduardo Minguez he creado un pequeño script en bash, guestimageinstall.sh, que hace lo siguiente:

  • Si no le pasamos la imagen qcow revisa el directorio definido (/opt/qcow2 por defecto) y nos permite elegir entre las imagenes qcow2 que haya disponibles.
  • Luego automaticamente selecciona un fichero de template en función de la versión.
  • En esta plantilla hacemos lo siguiente:
    • Creamos un usuario y le añadimos su clave ssh pública
    • Añadimos password para el usuario root
    • Cambiamos la timezone y la configuración del teclado
    • Activamos/desactivamos algunos servicios y reiniciamos
  • Cambiamos el hostname en la plantilla de meta data
  • Copiamos los ficheros de las plantillas y generamos el fichero clouditnit.iso usando genisoimage
  • Instalamos la nueva maquina virtual usando este fichero de cloudinit.iso

Más detalles en la página de github del proyecto.

  • Remover una entrada errónea en .ssh/known_hosts:
    • ssh-keygen -R hostname/ip
  • Poner la dirección mac correcta en la interfaz de red de una vm de RHEL/CentOS 7 recién clonada:
    • nmcli c mod eth0 802-3-ethernet.mac-address `nmcli d show eth0 | grep HW | awk '{print $2}'`
  • Listar las ips, macs y nombre de VMs ejecutandose en un host kvm:
    • for i in `sudo virsh list –name` ; do echo $i ; arp -na | grep `sudo virsh dumpxml $i | grep “mac add” | cut -d\’ -f2` ; done
  • Añadir un tema nuevo de wordpress de openshift:
    • git clone ssh......
    • cd $app
    • cp $path/$theme.zip .openshift/themes/
    • cd .openshift/themes/
    • unzip $theme.zip
    • rm themes/$theme.zip
    • git add .openshift/themes/Zoren/
    • git commit -m "Adding $theme"
    • git push

Aunque hay miles de posts sobre como y porque usar un servidor ssh como Proxy Socks, este me parece bastante instructivo, yo simplemente voy a hacer este post para aclarar los pasos necesarios en RHEL 7 o Fedora 19/20, con SELinux activado y con firewalld funcionando.

SELinux

En nuestro ejemplo, nuestro proxy Socks va a usar el puerto 443 para que sea factible usarlo desde la mayoría de los firewalls desde donde nos conectemos.
El problema es que este puerto es el vinculado al servicio HTTPS y uno de los mecanismos de seguridad que nos ofrecen las políticas de SELinux es el vincular los números de puerto al servicio esperado, así que lo primero que tenemos hacer es modificar la política de SELinux, para ello usamos el siguiente comando:

semanage port -m -t ssh_port_t -p tcp 443 

Firewalld

Con SELinux configurado lo siguiente es abrir el puerto en nuestro firewall, en este caso firewalld, para ello con los siguientes comandos lo que hacemos es aceptar de forma permanente el trafico hacia nuestro servidor por el puerto 443 desde la zona pública y recargar las reglas:

firewall-cmd –permanent –zone=public –add-port=443/tcp
firewall-cmd –reload 

SSH

Por último nos queda la configuración de ssh, para ello simplemente editamos el fichero /etc/ssh/sshd_config para definir los puertos donde escuchar:

Port 22 
Port 443 

A continuación reiniciamos el servicio:

systemctl restart sshd.service 

Lo siguiente es ejecutar el siguiente comando en nuestra máquina local:

ssh -N -D localhost:1080 mi_servidor_remoto -p 443 

Las opciones que usamos son:

  • -N” Para no ejecutar comandos remotos
  • -D localhost:1080” Para definir el puerto local desde el que vamos a hacer la redirección
  • -p 443” Para definir el puerto al que nos vamos a conectar

Si quisieramos ejecutar el comando en segundo plano, podríamos usar la opción -f

ssh -f -N -D localhost:1080 mi_servidor_remoto -p 443

Por último nos quedaría configurar nuestras aplicaciones, por ejemplo el navegador, para que use localhost:1080 como Proxy.

Openshift es la “Plataforma como servicio” (PAAS en inglés) de Red Hat. El concepto de PaaS lo que intenta es abstraer a los desarrolladores de todo lo relacionado con la infraestructura, la forma en que lo hace OpenShift a groso modo es la siguiente:

Soy un desarrollador y quiero desplegar una aplicación, supongamos para el ejemplo un blog con WordPress, primero elijo el tamaño que quiero que tenga mi aplicación, en términos de RAM y de espacio en disco, le pongo un nombre, a continuación añado mediante “cartuchos” las tecnologías a usar, en este caso PHP y MySQL, al añadir los cartuchos obtengo los datos de conexión necesarios para poder desplegar mi código o mi base de datos, si en algún momento mi aplicación necesita más recursos, puedo activar el autoescalado y ni siquiera preocuparme de morir de éxito.

Antes de pasar a la parte más técnica, quiero enumerar algunas ventajas/características que tiene OpenShift:

  • Tiene versión Online y versión para desplegar internamente en nuestra infraestructura, llamada OpenShift Enterprise.
  • La versión online se puede usar gratuitamente, aunque con limitaciones: Sólo 3 aplicaciones, el tamaño de estas es del tipo pequeño, no tiene soporte, etcétera.
  • La versión interna se puede desplegar en cualquier infraestructura virtual, ya sea RHEV, VMWare, OpenNebula, OpenStack… Evidentemente si se mantiene un ecosistema Red Hat, usando RHEV u OpenStack, tienes documentos de referencia y más articulos en la Knowledge Base 
  • La versión interna dispone a su vez de una versión comunidad, Origin 
  • Hay una gran comunidad de usuarios detrás, por lo que es fácil encontrar bastantes ejemplos de como desplegar aplicaciones, y no sólo ejemplos, sino guias rápidas con las que poder desplegar aplicaciones con sólo 2 clicks.
  • Es agnóstico al lenguaje de programación, hay cartuchos de python, php, perl, ruby, java e incluso .net
  • Hay bastante documentación:

¿Cómo funciona técnicamente OpenShift Online?

  1. Te creas una cuenta, que como ya he dicho hay una versión gratuita que permite hasta 3 aplicaciones.
  2. Creas la aplicación mediante la consola web , usando Eclipse , o la línea de comandos 
  3. A la hora de crear la aplicación eliges el tamaño de “Gear” hay 3 tamaños ya predefinidos, todos con 1 GB de espacio en disco inicial, y con 512MBs de RAM (Pequeño), 1GB de RAM (Mediano) y 2GB de RAM (Grande)
  4. En la aplicación recién creada, agregamos los cartuchos necesarios 
  5. Al agregar los cartuchos creamos a su vez repositorios privados de git dónde poder aplicar cambios con comandos git estandares.
  6. Una vez subido el codigo, OpenShift usa herramientas como Maven, Jenkins o Apache para completar el despliegue.
  7. En caso de activar el auto escalado, OpenShift inserta un HA-Proxy delante de la aplicación para monitorizarla y escalar en caso de que sea necesario.

¿Cómo funciona técnicamente OpenShift Enterprise/Origin?

Básicamente se compone de 2 elementos principales:

  1. Los “Broker” que son el punto de contacto para todas las actividades de gestión de una aplicación. Logins, DNS, monitorización de la aplicación, etcétera. Los usuarios no acceden directamente al broker sino que interactúan con él gracias a la API basada en REST, ya sea mediante la consola web, el cliente de línea de comandos o un IDE. El broker usa MCollective para los sistemas donde realmente residen las aplicaciones, los “Nodos”.
  2. Los Nodos albergan los cartuchos preconstruidos asi como las aplicaciones de los usuarios contenidas en “Gears”. En cada Nodo hay un cliente MCollective encargado de recibir y ejecutar las peticiones del Broker.

La comunicación entre los clientes MCollective de los Nodos y el Broker se hace usando un servicio de cola de mensajes. Tanto Enterprise como Origin usar ActiveMQ inicialmente, pero cualquier otro sistema compatible con AMQP como RabbitMQ debe funcionar.

Las topologías a poder usar son multiples, por ejemplo:

  • Todos los componentes en un solo sistema.
  • Un sistema con un broker y ActiveMQ y multiples sistemas Nodo.
  • Varios brokers balanceados, un sistema dedicado en exclusiva para ActiveMQ, con varios servidores MongoDB replicados y múltiples sistemas Nodo.

Como hemos dicho antes, los Gears, representan las porciones de CPU, memoria RAM y espacio en disco que están disponibles para una determinada aplicación. Una aplicación nunca puede sobrepasar el uso de estos recursos, a excepción del espacio en disco cuya cuota es ampliable por el administrador. Las tecnologías en las que se basa OpenShift para aislar los Gears y para controlar sus cuotas son SELinux y cgroups

Esto último cambiará próximamente puesto que OpenShift va a empezar a adoptar Docker , el problema de Docker, es que tiene algunos aspectos no muy pulidos:

  • ¿ Cual es la mejor manera de desplegar una aplicación en un contenedor recién creado?
  • ¿ Cómo conectar un montón de contenedores para formar una sola aplicación?
  • ¿ Cómo hacer desde el punto de vista de red que estos contenedores aparezcan como una simple aplicación al mundo exterior?
  • ¿ Cuando despliego un contenedor, he instalado todo lo necesario?

Aquí es donde GearD llega al rescate, e inicialmente se centrará en:

  • Convertir fuentes de aplicaciones en imagenes de Docker
  • Proveer conexiones elásticas entre varios contenedores
  • Facilitar los despliegues

De hecho, como ya he comentado en mi anterior post hay un nuevo proyecto llamado Project Atomic, que combina Docker, GearD y cockpit, así que no me extrañaría que pudiera usarse para desplegar “Nodos”

Últimamente hay mucho ruido alrededor de un nuevo proyecto open source llamado Docker  asi que voy a intentar tratar de aportar mi granito de arena.

Empecemos por la descripción de Docker: “Un proyecto open source para empaquetar, distribuir y ejecutar cualquier aplicación como un contenedor ligero”. Muy bonito, pero ¿Que es un contenedor?

Un contenedor es una forma ligera de virtualizar de forma que los recursos que ya se están ejecutando en la maquina host son compartidos con los contenedores, por ejemplo los contenedores no necesitan ejecutar su propia instancia del kernel, lo que permite una carga mucho menor, así como un arranque muy rápido y una gestión simplificada de los mismos. Es decir sería algo parecido a chroot con esteroides, en el sentido de que no sólo se usa para aislar una sola aplicación.

La tecnología de contenedores es conocida desde hace mucho tiempo y existen varias, cómo lxc , openvz , FreeBSD Jails o Solaris Containers .

Entonces ¿Que aporta Docker?. Pues como su descripción indica, Docker aporta las herramientas para tratar a los contenedores como si fueran repositorios de código, es decir, combinar paquetería y código todo en uno, de forma que se puedan desplegar, clonar, hacer vuelta atrás de versiones, etcétera con un simple comando.

Otra forma de desplegar contenedores que permite docker es mediante los Dockerfile, que son recetas en las que especificas el contenedor base y todos los cambios que quieres aplicar en un solo fichero.

La tecnología Docker es reciente y por eso, y tal como dicen en su web, “Aún no está preparado para produción”, no obstante tiene mucha tracción, por ejemplo Amazón ha anunciado recientemente su soporte  

Red Hat ha anunciado el “Project Atomic” que además de Docker, usa systemd , GearD y cockpit para crear una versión de RHEL especialmente destinada a usarse como “hypervisor” de contenedores.

Red Hat también ha anunciado que ha incluido Docker en su programa de High Touch Beta de forma que los clientes que participen en este programa puedan probarlo y reportar feedback, y se espera que este incluido en RHEL 7, aunque no en las primeras versiones.

Si quereis probar Docker, recomiendo hacer el tutorial interactivo de Docker.

Leyendo el post de Ramón Ramón  sobre “La falsa creencia de la propiedad y las licencias privativas” se me ha ocurrido escribir sobre otro aspecto diferencial entre el software libre y el software propietario: El soporte.

Primero un gran disclaimer: Trabajo para Red Hat  y además he trabajado para el departamento de Soporte  , y aunque intento siempre ser objetivo a veces mi pasión por el software libre me puede :) También tengo amigos que trabajan o han trabajado en departamentos de soporte de otras grandes empresas como Canonical, Oracle, RSA o Rackspace. Además quiero dejar claro que este post es una opinión puramente personal y no tiene vinculación ningún con mi empresa.

Ahora al lío: El tipo de licencia de un software no tiene nada que ver con el soporte que vas a recibir por él, como dice el post de Ramón Ramón , la licencia de un software privativo sólo te da derecho a usarlo, de hecho normalmente no es que te dé derecho a usarlo, sino que te restringe en que puedes usarlo y en que no, además durante un tiempo determinado. Además la empresa propietaria del software se guarda el derecho a no renovarte la suscripción, aumentar el precio en el futuro o simplemente descontinuar el producto.

Sobre el soporte del software libre hay 2 tipos bien diferenciados, el soporte de “la comunidad” y el soporte empresarial que ofrecen muchas empresas como Suse, Canonical o Red Hat.

El soporte “comunitario” no es más que aquel que puedes encontrar por parte de usuarios o desarrolladores de ese software, ya sea en blogs, foros, wikis, es decir contenido “estático” o mediante interacciones: Listas de correo, herramientas para reportar problemas (tipo http://bugzilla.redhat.com) o canales de irc

Este tipo de soporte tiene sus ventajas: es muy abundante, es gratis y en muchas ocasiones te puedes encontrar interactuando con el creador(es) del propio software. Pero también tiene sus problemas: falta de organización, no tiene tiempos de respuesta definidos y evidentemente no tienes forma de “quejarte” si crees que no estas recibiendo el soporte adecuado.

Pero es mentira que el software libre no disponga de soporte empresarial, como ya he nombrado hay muchas empresas que si dan soporte:
Red Hat
Canonical
Suse
Puppetlabs 

Desconozco en detalle como trabajan otras empresas de software libre, pero estoy seguro de que ofrecen un soporte excelente, pero puedo aprovechar para hacer una breve introducción al soporte de Red Hat, que espero que ayude a desmitificar la idea de con el software libre todo tienes que hacerlo tu mismo.

  • Red Hat Enterprise Linux ofrece un ciclo de vida de soporte de 10 años, extensibles otros 3 años, con diferentes etapas. Aunque personalmente me parece una mala idea tener en produción un software con tanto tiempo.
  • Como ya he dicho, Red Hat ofrece tiempos de respuesta definidos, además para ciertos tipos de incidencias , aquellas en las que se está impactando la produción, el soporte es 24×7
  • La forma de acceder al soporte de Red Hat puede ser via web (mediante casos de soporte o via chat una vez abierto el caso), por email (una vez abierto el ticket via web) o por telefono. Además en algunas ocasiones se pueden tener sesiones remotas 
  • La base de datos de conocimiento de Red Hat  es el mejor sitio para buscar información, los artículos que aparecen son artículos aprobados por Red Hat, basados en casos reales, se van actualizando y puedes comentarlo en un caso abierto con soporte. Personalmente hay 2 cosas que no me gustan: Que requiera login para ver los artículos (aunque cualquiera puede crearse una cuenta) y el motor de búsqueda no funciona del todo fino.
  • Que está incluido en el soporte de Red Hat? Pues la regla básica es “Lo que distribuimos es lo que soportamos”  Pero ante la duda siempre abrid un caso y preguntar.
  • El soporte de Red Hat no está solo para incidencias, sino que está también para otras muchas cosas: petición de nuevas funcionalidades  , reportar problemas, mejoras de la documentación, revisiones de arquitectura de ciertos productos (Cluster o RHEV por ejemplo), grupos de discusion , laboratorios de soporte  , certificación de hardware, etcétera
  • Si la atención que se recibe no te parece satisfactoria siempre puedes requerir una escalación  o incluso llamar directamente al móvil a uno de los directores de soporte de tu respectiva zona horaria .
  • A la hora de abrir casos de soporte, Red Hat tiene varias herramientas que se utilizan para recopilar información sobre los sistemas, de forma que sea más fácil resolver los problemas: sosreport  , kdump-crash , spacewalk-debug , etcétera
  • Además dependiendo del nivel de soporte necesario, Red Hat ofrece otros servicios asociados como Technical Account Manager  o Support Relationship Manager 

Bueno como todos probablemente hayáis leído, ha aparecido un bug de OpenSSL que podría permitir el robo de información, que en otras condiciones estaría protegida por el cifrado SSL/TLS.

Voy a dividir el post en 2 partes, la primera la técnica:

Se puede encontrar más información en http://heartbleed.com/ y puedes ver si un sitio está afectado usando https://code.google.com/p/go/downloads/list También hay una herramienta online, pero no es muy buena idea usarla: https://gist.github.com/janl/10107626

El bug se resolvió de forma muy rápida, por ejemplo en Red Hat no pasaron ni 24 horas:
https://rhn.redhat.com/errata/RHSA-2014-0376.html

Y por ejemplo en Red Hat, no afectaba a ninguna de las versiones de RHEL 5, y en RHEL 6 solo afectaba a la ultima versión la 6.5.
https://access.redhat.com/site/solutions/781793

El problema se soluciona actualizando simplemente el paquete openssl, y después de hacerlo hay que tener en cuenta que hay que reiniciar todos aquellos servicios que estén usando la versión antigua, se puede comprobar usando el comando:
“lsof -n | grep ssl | grep DEL”

Ahora la parte menos técnica:

En Linux (Red Hat, Debian, Ubuntu…) había un fix en apenas 24 horas, que hubiera pasado si fuera un sofware privativo, como Microsoft o Apple? Pues nunca sabremos la respuesta, pero tenemos ejemplos pasados de retrasos en problemas parecidos:
http://www.forbes.com/sites/andygreenberg/2014/02/25/apple-patches-its-gotofail-security-bug-for-osx-after-four-days-of-heckling/
http://microsoft-news.com/microsoft-finally-fixes-the-svchost-bug-in-windows-xp-after-years/

Ojo, estoy totalmente desconectado del mundo privativo, así que no sé si los ejemplos que pongo son algo aislado, pero por los titulares que suelo leer, creo que no.

Otro tema a tener en cuenta que comentaba https://twitter.com/pantulis/ aquí https://twitter.com/pantulis/status/453508912327974912 era la problemática de que los clientes valoren el mantenimiento y de la plataforma/sistema operativo, que está alrededor de una solución.

Desde mi experiencia como administrador de sistemas y como consultor: Nadie lo valora hasta que tienen un problema, por eso hace años que cuando algún familiar o conocido me pregunta por temas de hosting o similar, siempre les oriento hacia soluciones de hosting compartido, en las que pagas a una empresa para que (al menos supuestamente) se encargue de todo este mantenimiento.

Además, por desgracia, esto también pasa no solo de cara a clientes que solo ven en la tecnología un medio para su negocio, hay empresas de tecnología que ni siquiera tienen definido ciclos de vida de sus soluciones, ni definidas políticas de parcheado.

Por último como comentario “corporativo”, para entender como Red Hat entiende los ciclos de vida del Sistema Operativo:

Red Hat no diferencia entre versiones “menores”, es decir, para Red Hat, solo existe RHEL 6, lo de RHEL 6.1, 6.2, etcétera son sólo imágenes iso que se sacan cada cierto tiempo, cuando se saca alguna actualización, que pueden ser de seguridad, arreglo de fallo o nueva funcionalidad, pues se incorpora directamente en el canal (repositorio) de RHEL 6, pero no a las isos que siguen siendo las mismas.

Para la gestión del software del sistema operativo Red Hat ofrece, Red Hat Network Satellite, con este producto, entre otras muchísimas cosas, lo que dispones es de un “Canal” (algo parecido a un repositorio) que se sincroniza con Red Hat Network para tener las ultimas versiones de todos los paquetes RPM. Hasta aquí nada nuevo, la ventaja es que además permite “clonar” estos canales para adaptarlos al ciclo de vida de la empresa, que puede ser por versiones menores, o cualquier otro criterio. Además desde la interfaz web o mediante la API, podríamos actualizar sistemas o grupos de sistemas en base a muchos criterios:
– Cambios de versión (la que haya definido el cliente)
– Aplicar sólo actualizaciones de seguridad
– Aplicar sólo actualizaciones relativas a una(s) errata(s)

Permite también obtener informes para ver las erratas pendientes de aplicar a estos sistemas y un largo etcétera de utilidades para la gestión del ciclo de vida de los sistemas.

Pero incluso si solo dispusieramos de repositorios RPM, y aunque tuvieramos que hacerlo uno a uno en cada sistema, mediante yum también podríamos:
– Comprobar si un sistema está afectado o no por una determinada errata o alerta de seguridad
– Aplicar sólo actualizaciones de seguridad
– Aplicar sólo actualizaciones relativas a una(s) errata(s)

Y por supuesto en el resto de distribuciones Linux seguro que hay alternativas parecidas para hacer lo mismo, en definitiva, que es un problema más de estrategia corporativa y de mentalidad que técnico, y por desgracia no se valora el trabajo “en la sombra” de los administradores de sistemas.

  • Han mejorado el sistema de suscripciones e informes, donde hay mas niveles de reportes de consumo de suscripciones
  • Analisis de clientes: Red Hat Satellite 5.6 integra ABRT para proveer informacion centralizada de “crash” en aplicaciones de los clientes
  • Mejor el Inter-Satellite Sync (ISS) de forma que permite refinar el nivel de acceso a la hora de sincronizar Satellites
  • PostgreSQL (Por fin!!!!) El uso de PostgreSQL como base de datos, de forma interna o externa, ya esta totalmente soportado
  • Mejoras de Escalabilidad: Debido al uso de PostgreSQL, ahora es posible desplegar la base de datos en una maquina externa sin la intervencion de un DBA.
  • La base de datos interna por defecto ahora es PostgreSQL lo que provee la posibilidad de ejecutar backups en caliente.
  • Provisionamiento automatico en entornos sin PXE al agregar el soporte para Cobbler Build ISO en Satelite, lo que permite creacion de ISOs personalizadas.
  • Junto con la salida de Red Hat Network Satellite 5.6 se ha publicado una nueva herramienta para la “autogeneracion” de certificados de Satellite, lo que permite crear certificados con el detalle de las suscripciones a usar

Más detalles en:

http://gb.redhat.com/about/news/press-archive/2013/10/red-hat-releases-red-hat-satellite-5-6
https://access.redhat.com/site/articles/477863

Voy a intentar ir creando entradas en el blog comentado productos de Red Hat , que dejo hace mucho tiempo de ser una empresa de “sólo” un sistema operativo.

Hoy quiero comentar 2 productos orientados a tener acceso a software de desarrollo mas reciente, aunque con ciclos de soporte mas cortos que los hasta 13 años de ciclo de vida de RHEL:

Red Hat Software Collections tiene un ciclo de vida de 3 años e incluye:
  • Ruby 1.9.3
  • Python 2.7
  • Python 3.3
  • PHP 5.4
  • Perl 5.16.3
  • node.js 0.10 (Technology Preview)
  • MariaDB 5.5
  • MySQL 5.5
  • PostgreSQL 9.2

Más información:

http://developerblog.redhat.com/2013/09/12/rhscl1-ga/
https://www.redhat.com/about/news/press-archive/2013/9/red-hat-extends-red-hat-enterprise-linux-platform-with-latest-versions-of-popular-programming-languages-and-databases
https://access.redhat.com/site/discussions/482093
https://access.redhat.com/support/policy/updates/rhscl/

Red Hat Developer Toolset tiene un ciclo de vida de 2 años e incluye:

  • Eclipse 4.3 (Kepler)
  • gcc 4.8
  • Dyninst 8.0
  • Strace 4.7

Más información:

http://developerblog.redhat.com/2013/09/12/rh-dts2-ga/
https://access.redhat.com/site/products/Red_Hat_Enterprise_Linux/Developer/#dts
https://access.redhat.com/site/documentation/en-US/Red_Hat_Developer_Toolset/2/html/User_Guide/index.html
https://access.redhat.com/support/policy/updates/dts/

En ambos casos el acceso a software se hace mediante canales (repositorios) de Red Hat Network o Red Hat Network Satellite, es decir no hay una iso descargable.


Ademas aprovecho para comentar algunas novedades que se han publicado hoy:

Satellite 5.6: