Plugins de yum

Una de las primeras cosas que debemos hacer es mejorar el rendimiento de YUM, puesto que lo necesitamos para el resto de tareas. Dos plugins fundamentales fastetstmirror (sirve para localizar el servidor más rápido para la descarga de paquetes) y presto que descarga sólo los paquetes nuevos de un determinado programa.

yum install yum-plugin-fastestmirror
yum install yum-presto

Instalar repositorios extras

Algunos paquetes interesantes, por uno u otro motivo, no se encuentran en los repositorios oficiales de Fedora, así que mejor tener preparados los repositorios extra para cuanto se necesiten.

yum localinstall --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

Instalar flash plugin en Fedora 16

El plugin de flash, una de esas cosa que una vez instalado no te volverás a preocupar, pero que cuando no lo tienes y accedes a una web que lo usa provoca bastante frustración.

yum install flash-plugin

Instalar java y su famoso plugin

Otra de esas cosas, que a menos que uses programas en java no echas de menos hasta que llegas a una web que requiere su famoso plugin para poder acceder a alguna utilidad. Si eres fan de la Fórmula 1 y quieres seguir la tabla de tiempos a través de la web oficial necesitas el plugin (OJO: algunos navegadores necesitan configuración adicional).

yum install java-1.6.0-openjdk
yum install java-1.6.0-openjdk-plugin

Instalar codecs de audio y video

Cuando intentes usar Rhythmbox para escuchar música te darás cuenta de su necesidad.

yum install gstreamer-plugins-bad gstreamer-plugins-bad-nonfree gstreamer-plugins-ugly gstreamer-ffmpeg

Visualización y herramientas

Completado el apartado de entrañas, toca una revisión a la parte visual. Fedora 16 viene con la Shell de Gnome 3 y tenemos una herramienta estupenda para configurar sus opciones gnome-tweak-tool

yum install gnome-tweak-tool

Algunas utilidades que en algún momento vais a necesitar si usáis Fedora como sistema de escritorio: paquete ofimático, editor de gráficos, gestor de documentos (si usas Google Docs, debes activar las cuentas en línea) y el VLC.

yum install libreoffice
yum install gimp gimp-data-extras gimp-fourier-plugin gimp-lqr-plugin gimp-resynthesizer gimpfx-foundry
yum install gnome-documents
yum install vlc-extras

Y eso es todo, excuso decir que para todas estas operaciones tenéis que tener permisos de administración sobre el sistema.

No es mi propósito hablar de las ventajas del navegador del buscador más popular de la red, para eso hay muchos artículos por la red, el interés de este post es hablar de cómo instalarlo en sistemas Red Hat y derivados a través del popular YUM.

Podemos optar por dos modos, el primero descargando directamente el RPM desde la página de Google y la segundo agregando el repositorio de YUM. El segundo método tiene evidentes ventajas sobre el primero, sobre todo a la hora de mantener actualizado el sistema.

Para instalarlo con el RPM en local, procedemos a descargarlo desde la web de Google, nos situamos en el directorio e instalamos con:

yum localinstall --nogpgcheck google-chrome-stable_current_x86_64.rpm

Para usar el segundo método, tendremos que crear el repositorio, para ello generamos el fichero /etc/yum.repo.d/google.repo y ponemos lo siguiente:

[google-chrome-32]
name=Google Chrome - 32-bit
baseurl=http://dl.google.com/linux/chrome/rpm/stable/i386
enabled=1
gpgcheck=1
gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub

[google-chrome-64]
name=Google Chrome - 64-bit
baseurl=http://dl.google.com/linux/chrome/rpm/stable/x86_64
enabled=1
gpgcheck=1
gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub

Podemos optar por montar uno sólo de los repositorios eligiendo el que corresponda a la arquitectura de nuestro procesador.

Después de esto sólo queda un paso para tener instalado Google Chrome:

#### Version Estable ###########
yum install google-chrome-stable

#### Version Beta ###########
yum install google-chrome-beta

Y … listo a disfrutar del navegador de Google en Linux.

Nota para desarrolladores web: Google Chrome tiene la misma base que Safari, por lo que si vuestra web está dando problemas en Mac y no tenéis uno a mano, podéis comprobar los errores con este navegador (muy útil con problemas en javascript)

3.2.4. Scripts de SysVinit portados a systemd

Fedora 15 vió la introducción de systemd, un administrador de sistema y de servicios nuevo para Linux. La integración de systemd continúa en Verne, con muchos más scripts de inicio de SysV convertidos a archivos de servicios nativo de systemd. El resultado es un proceso de arranque más rápido, eficiente y una administración de servicios más simple.

Ahora bien, si entrar a valorar si el cambio ofrece mejoras, que seguro que si y pronto lo veremos también en Red Hat Enterprise, CentOS y el resto de la familia, pero el abandono de sysvinit trae consigo la necesidad de adaptarse al nuevo sistema.

Por el momento se puede hacer uso de service y chkconfig, aunque creo que poco durarán en futuras versiones, así que toca ponerse al día para poder administrar los servicios con systemd, ahí van algunos comandos y sus correspondencias con sysvinit:

Más info en: https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet/es

Estos prefijos se combinan con el identificador del dispositivo. Así en los discos duros IDE tendríamos para el primer disco la letra “a” seguida de un número para identificar la partición. Con hda1 se identificaría la primera partición del primer disco duro IDE. Con hdb2 tendríamos la segunda partición del segundo disco IDE.

Todos los dispositivos se almacenan en el directorio /dev, listado este directorio se mostrarán todos los dispositivos conectados.

• Soporte básico para Microsoft SQL Server
• Botón para detener consultas largas
• Gestión de usuarios: propuesta de password aleatorio y soporte SSL
• Soporte para autenticación en MariaDB 5.2, con indicación con iconos de MariaDB y Percona Server
• Correcciones varias en el uso con Wine
• Recuperación el SQL original en VIEW editor

Puedes consultar el resto de cambios de la versión 7.0 aquí. Descargar HeiddiSQL 7.0

Los repositorios se configuran bajo el directorio /etc/yum.repos.d/ y deben tener la terminación .repo. En cada uno de los ficheros pueden estar configurado más de 1 repositorio, para agregar un repositorio debemos poner los siguientes campos:

[nombre_repositorio]
name=Nombre del repositorio
baseurl=http://servidor/repositorio
enabled=1
gpgkey=http://servidor/repositorio/gpgkey
pgpcheck=1

En name indicamos el nombre, con baseurl la ruta hasta el repositorio, con enabled si se habilita (1) o no (0), con gpgkey la ruta de la llave de seguridad y con pgpcheck si se comprueba la integridad con la llave.

Una vez completado guardamos el fichero repositorio.repo por ejemplo y lanzamos el listado de repositorios que debería mostrarnos algo como lo siguiente:

# yum repolist

repo id repo name status
base CentOS-5 – Base 3558+8
extras CentOS-5 – Extras 290
updates CentOS-5 – Updates 676+40
repolist: 4524

Y ya tenemos configurado nuestro repositorio. Si estáis buscando información para configurar repositorios en este enlace tenéis EPEL (Paquetes adicionales para Linux Empresarial, incluyendo CentOS, Oracle Linux, etc).

El primer paso será generar un certificado en el equipo cliente, para ello podemos optar por dos alternativas, la primera usar la ssh-keygen y la segunda utilizar la PuTTYgen. Si utilizáis indistintamente la shell y el PuTTY para acceder a servidores remotos entonces deberíais usar los dos formatos. Accedemos al equipo cliente y lanzamos el comando:

# ssh-keygen

Nos pedirá la ruta donde queremos guardar el fichero (pulsando enter se guardará en la ruta por defecto), y luego nos pedirá el passphrase. Se podría dejar en blanco y que simplemente se accediese al servidor sin ninguna contraseña, pero como hablamos de la seguridad lo primero usaremos un passphrase. También podemos omitir estos pasos indicandolos como parametros:

# ssh-keygen [-b bits] -t type [-N passphrase] [-f fichero]

Con la opción -b indicamos el número de bits, por defecto son 2048 y el valor mínimo es 768. Con -t indicamos el tipo (rsa o dsa, por defecto rsa que es el que usaremos). Con -N indicamos el passphrase y con -f el fichero de salida del certificado.

Una vez completado tendremos dos ficheros en la ruta especificada id_rsa e id_rsa.pub, que como parece obvio es el que contiene la clave pública, mientras que id_rsa contiene la clave privada.

Ahora toca trasladar al servidor la clave pública, para ello podemos echar mano del comando ssh-copy-id del siguiente modo:

# ssh-copy-id [-i fichero_clave] usuario@servidor

Con la opción -i indicaremos el fichero que contiene la clave pública generada en el paso anterior. Solicitará el passphrase y se instalará en .ssh/autorized_keys

Una vez completado este paso ya podemos acceder al servidor mediante el uso de los certificados y en lugar de pedir el password nos pedirá el passphrase. Ahora nos queda hacer que el servidor no responda ninguna petición si no viene acompañada de certificado, para ello editamos el fichero /etc/ssh/sshd_config, cambiamos la directiva PasswordAuthentication a no y reiniciamos el servicio sshd.

Ya sólo nos queda una cosa más. Si accedéis por SSH usando PuTTY entonces necesitareis convertir vuestro certificado. Para ello echaremos mano de PuTTYgen, en el menú Conversiones >> Importar clave y buscaremos el fichero de clave privada (id_rsa). Pulsamos en Generar y luego en Guardar clave privada.

Ahora ya tenemos nuestra clave privada en formato ppk. Para usarla con PuTTY tendremos que acceder a Connection >> SSH >> Auth e insertar ahí la clave, luego loguearnos como de costumbre.

Las redes sociales (Facebook, Twitter, Linkedin…), música, mapas… están a un toque de tu pantalla, este Nuevo modelo cuenta con Internet Explorer 9 y una cámara de 8 Mpx con un objetivo de gran angular.

El lanzamiento del teléfono Nokia Lumia 800 es el más importante de la marca, con esta campaña tiene el objetivo de comunicar y posicionarse como el nuevo Smartphone de Nokia que contará con el sistema operativo de Windows Phone.

Hasta el momento ya se han presentado ocho monoplazas de esta temporada, a saber (por orden cronológico): Caterham CT01, McLaren MP4-27, Ferrari F2012, Force India VJM05, Lotus E20, Sauber C31, Red Bull RB8 y el Toro Rosso STR7.

Quizás el signo más característicos de todos ellos, a excepción del MP4-27, sea lo que se ha dado en llamar morro de delfín, una diferencia de altura a modo de desnivel escalonado en la mitad del morro del monoplaza, una solución de diseño para hacer frente a la normativa de seguridad de 2012.

Por otra parte, algunos equipos ya han confirmado que algunas piezas de los coches que presentaron eran simples maquetas de plástico. En especial lo que se trata de ocultar esta temporada son los escapes y la parte del difusor, con la prohibición de los difusores soplados cada equipo ha tenido que buscar la solución más ingeniosa para esa área.

El punto más extraño lo está poniendo Mercedes, que llega a Jerez con el coche del año pasado y reducen un día los entrenamientos (el viernes no van a rodar), para quedar perplejo viendo que el resto de equipos no están demasiado contentos con la reducción de 15 a 12 de los días de entrenamientos de pretemporada.

Algunos dicen que Mercedes ha encontrado una solución fantástica y no quieren que nadie la copie. Desde el equipo insisten en que no hay nada de eso y simplemente no les ha dado tiempo a completar el programa de de desarrollo. Veremos con que llegan a mediados de febrero a Montmeló, si es verdad que puede luchar con los de arriba y si Rosberg por fin logra subirse a lo más alto del podio.

Otro punto destacable de esta temporada, que comienza el 18 de marzo con el Gran Premio de Australia 2012, es que coincidirán en pista 6 campeones del mundo, a saber: Michael Schumacher (7), Fernando Alonso (2), Sebastian Vettel (2), Lewis Hamilton (1), Jenson Button (1) y Kimi Raikkonen (1), en total 14 campeonatos y entre ellos los comprendidos entre el 2000 y 2011, todo un lujo.

En España, la fusión de Antena 3 y La Sexta ha dejada claro que en este país nos gusta usar la picaresca. Y si Telecinco traspasó los derechos del fútbol cuando se fusionó con Cuatro, ahora toca hacer lo mismo con la F1. Mediapro, gestor de los derechos, los ha sacado a subasta porque dice que La Sexta no tenia dinero para hacer frente al contrato, un contrato que probablemente sea por el concepto que más ingresa esta cadena teniendo en cuenta la cantidad de espectadores que siguen las carreras en este país, a pesar de que Fernando Alonso no gane..

Nota: Para los más despistados, este año Lotus pasa a llamarse Caterham y Renault será Lotus.

Hechas las presentaciones, vaya por delante lo de siempre: un servidor completamente seguro es el que está encerrado entre muros de hormigón sin ningún tipo de conexión. Obviamente, así no sirve para nada, entonces tendremos que buscar el correcto equilibrio entre conectividad y seguridad. Como me toca acabar el año configurando nuevos servidores, os dejo una pequeña guía para asegurar el acceso por SSH.

Lo primero, modificar el fichero de configuración de SSH que encontrareis en /etc/ssh/sshd_config y agregamos las siguientes líneas (en muchos casos las encontrareis comentadas).

Protocol 2
LoginGraceTime 20
PermitRootLogin no
MaxAuthTries 2
MaxStartups 3
AllowUsers pepito

La primera línea le indica que unicamente se puede hacer uso de la versión 2 del protocolo de comunicación. La primera versión tiene algunas vulnerabilidades conocidas y está obsoleta por lo que lo recomendable es no usarla si no se necesita.

El LoginGraceTime hace referencia al tiempo en segundos que la pantalla de login permanecerá abierta, en el ejemplo hemos dejado 20 segundos, un tiempo más que suficiente para indicar usuario y contraseña.

Con PermitRootLogin establecido a no evitaremos que el usuario root pueda autenticarse a través de SSH para acceder al servidor. El problema es que los sistemas Linux y Unix crean al usuario root, lo que garantiza a un atacante que ya conoce el usuario, sólo queda la contraseña. De esta forma será mucho más complicado, obviamente no uses nombres conocidos o estarás en el mismo caso.

Otro de los límites que podemos imponer es definir la cantidad de veces que podemos fallar al autenticarnos. Con MaxAuthTries definimos el número de intentos, con 1 sería más que suficiente, pero a los que nos toca andar con varios servidores a la larga terminas equivocándote la primera vez de ahí que lo defina con 2 intentos. Lo que ocurrirá después del segundo fallo es que se cerrará la conexión.

Con MaxStartups se indican la cantidad de conexiones simultaneas que se permiten, en este caso hemos optado por 3, un número razonable para aquellos servidores a los que se accede por SSH únicamente para su administración. Con esto evitaremos que un ataque por fuerza bruta pueda realizar miles de conexiones simultaneas para atacar.

Y por último, pero no menos importante, AllowUsers. Con esta directiva le indicamos al SSH que usuarios exclusivamente se pueden identificar en el sistema. También podemos aumentar la seguridad definiendo desde que redes puede acceder un determinado usuario. Basta con poner los nombres de los usuarios separados por espacios, si se quiere indicar un host podemos hacerlo poniendo el usuario seguido del símbolo @ y el host (Ej: pepito@127.0.0.1).

Con esto ya tenemos nuestro SSH un poco más seguro. Guardamos el fichero y reiniciamos el servicio.

Lo segundo que haremos para evitar que nos ataquen será instalar Fail2ban, un programa controla los logs y que nos permite vetar todas aquellas IP’s que fallan un determinado número de veces. El baneo se realizará usando el firewall, así que lo que hace realmente Fail2ban es crear y borrar reglas en función de la información que se registra en los logs.

El requisito para instalar Fail2ban es tener Python, tenéis disponibles paquetes compilados para instalar o podeis tirar de repositorios. Una vez instalado tan solo es necesario configurar las reglas que queremos tener activas, tenéis bastante información en su web y un archivo de configuración de prueba en /etc/fail2ban/jail.conf

Proteger acceso por SSH con certificados