Categoría: Webmasters

Instalar Google Chrome en Linux a través de YUM

Google Chrome es ya uno de los navegadores de referencia en todas las plataformas y además cuenta con el beneplácito de los usuarios que ven en él un modo fácil y rápido de escapar a Internet Explorer, además de aportar muchas herramientas adicionales.

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)

Proteger el acceso por SSH (II)

Después de haber configurado el servicio SSH para hacerlo un poco más seguro, hoy vamos con la segunda entrega. En este caso vamos a ver como asegurar nuestro servidor SSH mediante el uso de certificados, un paso más allá que evitará que el servidor solicite autenticación si previamente no se ha enviado un certificado.

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.

Proteger el acceso por SSH

SSH (Secure SHell) es a un tiempo el nombre del protocolo y el programa que nos permite acceder a maquinas remotas de forma segura y gestionarlas por completo mediante un intérprete de comandos.

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

ESET Internet Meeting Point 2011

Los próximos 7 y 8 de octubre, se desarrollará en el Hotel Sylken de Gijón ESET Internet Meetint Point 2011, un evento que evoluciona sobre la experiencia de años anteriores para ofrecer casi todo lo que nos habéis pedido a lo largo de este último año, y que tiene como premisas principales, la cercanía y su carácter abierto a todos los públicos.

Ese es el objetivo hoy en día, abrir la red a todo el mundo, abrir un evento de internet a todo aquel que quiera participar, indistintamente de sus conocimientos sobre ella. Hablaremos de política, de homeopatía, de seguridad en el hogar, de emprendedores, de sectores industriales en dificultades, de cambios en la sociedad vinculados a las redes sociales, de la realidad sobre el asesinato de Jonh Fitzgerald Kennedy, de fotografía… haremos monólogos, tendremos humor, habrá conciertos, famosos, tweets, internet & Sidras.

El evento ha sido diseñado para que encuentres tu forma de participar, sea la que sea y tengas las aficiones que tengas. Creemos que ESET Internet Meeting Point 2011 conseguirá interesarte en su conjunto o en alguna parte en individual, estamos convencidos de ello porque allí se hablará, se mostrará y se transmitirá cultura.

Frameworks PHP: Zend vs Symfony

Cuando uno se plantea por primera vez el uso de un framework en PHP comienza a darle vueltas a las posibilidades que ofrecen unos y otros. Aunque la curva de aprendizaje en el uso de un framework es dura, todo el tiempo que le dediquemos a conocer a fondo aquel por el que nos decidamos será el tiempo mejor invertido en formarnos como desarrolladores.

En este caso quiero plantear una comparación entre dos de los frameworks más extendidos Zend y Symfony.

Documentación y aprendizaje. Com he dicho la curva de aprendizaje para poder usar correctamente y con soltura un framework necesita de un esfuerzo, mucho más si llevamos años programando sin usarlo. Symfony dispone de guias y manuales en abundancia, y además cuenta con numerosos foros en varios idiomas donde la comundad va resolviendo dudas. En el caso de Zend, a pesar de ser el framework de la empresa que está detrás de PHP, la comunidad es algo escasa, por tanto su documentación también.

Pruebas unitarias. Symfony dispone de tareas por linea de comandos para realizar testing, y además genera una clase vacia con cada nuevo controdalor desde el que poder realizar las pruebas. Zend no dispone de esta funcionalidad, algo que me parece muy importante a la hora de lanzar una aplicación a un entorno de producción.

Plantillas y plugins. Al sistema de plantillas de Zend le queda todavía un largo camino que recorer, mientras que en Symfony el sistema está ya muy avanzado, con la posibilidad de agragar módulos. Y otro tanto ocurre con los plugins, en Symfony es posible aumentar sus funcionalidades a base de plugins, mientras que Zend carece de esta característica.

Bases de datos. El trabajo con base de datos en Zend se limita a usar ActiveRecord (que no digo que esté mal), pero en Symfony tienes la posibilidad de usar el motor de base de datos que quieras, incluyendo el propio Zend_Db, algo que aporta una enorme flexibilidad al desarrollador que puede elegir en cada proyecto cual es la mejor opción.

Como conclusión a lo dicho quiero añadir, para todos aquellos que quieran dar el salto a hacer desarrollos basados en un framework, que a pesar de que al principio pueda resultar un poco engorroso con el tiempo os ayudará a mantener una limpieza de código y un mantenimiento de aplicaciones mucho más sencillo.

Utilidad y uso de EXPLAIN en MySQL

logo_mysql

A la hora de realizar una buena optimización de las consultas de MySQL habrá que prestar mucha atención a lo que dice la cláusula EXPLAIN. Su sintaxis es muy sencilla, basta anteponerlo a la consulta que queremos realizar para obtener toda la información.

EXPLAIN SELECT columna1, columna2 FROM tabla1 WHERE columna3 = ‘2’\G

El resultado que obtendremos será el plan de ejecución de la consulta a la base de datos. Una explicación de como accederá MySQL a las diferentes columnas involucradas en la consulta. EXPLAIN devolverá:

  • id: Es el identificador que EXPLAIN asignará a la consulta.
  • select_type: Tipo de consulta a analizar. Por ejemplo, si se trata de una consulta sencilla su valor será SIMPLE.
  • table: Nombre de la tabla a la que hacen referencia el resto de datos en la fila. Hay que tener en cuenta que el orden de las filas será el que utilizará MySQL para acceder a los datos.
  • type: Indica como MySQL combinará los datos de esa tabla.
  • possible_keys: Lista de los indices que se podrían utilizar, aunque podría no usarse ninguno.
  • key: Índice que finalmente se usará, si no se usa ninguno el valor del campo será NULL.
  • key_len: Tamaño del indice utilizado, si no se usó ninguno contendrá NULL.
  • ref: Muestra con que campo está relacionado el índice seleccionado.
  • rows: Número de registros que se tendrán que recuperar para ejecutar la consulta.
  • extra: Información adicional sobre la forma en que se obtendrán los datos.

Con esta información es posible encontrar donde se producen los cuellos de botella en las consultas que realizamos a la base de datos, y nos permitirá optimizarlas para evitar que una consulta lenta provoque un retraso injustificado en la devolución de resultados a los usuarios. En el manual de MySQL puedes encontrar más información.

Galite organiza unha xornada de Software Libre en Foz

cartelcursodrupalGalite, o Grupo Asociado pola Libre Información e a Tecnoloxía, organiza o vindeiro 21 de marzo unha xornada sobre software libre no Concello de Foz. O encontro terá lugar na Casa da Xuventude da vila e estará aberta á participación de calquera persoa interesada en iniciarse ou afondar no coñecemento das tecnoloxías e os estándares abertos.

A xornada iniciarase ás 12:00 horas coa presentación do Galinux, o sistema operativo libre e en galego promovido pola Dirección Xeral de Promoción Industrial e da Sociedade da Información e enmarcada no Plano Estratéxico Galego da Sociedade da Información (PEGSI 2007-2010).

A continuación impartirase un obradoiro titulado «Introdución a Drupal», no que se abordará a instalación deste sistema de xestión de contidos (CMS), así como a súa configuración para a creación dunha web particular, empresarial ou unha comunidade online.