Existen varios, como FailtoBan, aunque esté sea más genérico y dependa mucho de encontrar las expresiones regulares adecuadas lo que todavía no está bien encontrado.

Volviendo a DenyHosts, si lo que queremos es evitar ataques por ssh, este software es bastante útil. Lo digo porque cuando tienes el fichero btmp con este tamaño:

[root@hn19 software]# ls -lisah /var/log/btmp
3189425 785M -rw------- 1 root utmp 784M Jul 30 07:39 /var/log/btmp


Es para hacer algo, ¿no?

1. Descargar RPMforge
# wget
rpmforge-release-0.3.6-1.el5.rf.x86_64.rpm

2. Instalar RPMforge
# rpm -Uvh rpmforge-release-0.3.6-1.el5.rf.x86_64.rpm

3. Instalar DenyHosts
# yum install denyhosts

El archivo de configuración está en:

/etc/denyhosts/denyhosts.cfg

4. Iniciar denyhosts
[root@ software]# service denyhosts start
starting DenyHosts: /usr/bin/env python
/usr/bin/denyhosts.py --daemon --config=/etc/denyhosts/denyhosts.cfg

Es más que posible que ya en el primer arranque del servicio, nos añada hosts al fichero /etc/hosts.deny para su bloqueo. En el log podemos ir viendo el funcionamiento del servicio.

# tail -f /var/log/denyhosts

Hace poco me he encontrado con el caso de un proyecto, en el que uno de los actores no tiene confianza en la virtualización como filosofía básica para desplegar los servicios requeridos por el cliente, dudando del rendimiento del mismo en un entorno de producción. Asegura no creer conveniente desplegar el proyecto con una infraestructura virtualizada aunque eso sí, da su ok a un entorno de desarrollo o pruebas virtualizado.

Siempre intento ser moderado y más con gente que no conozco, el hecho es que, tal planteamiento me sorprendió de tal manera que conversando con esta persona, no encontré la forma de hacerle llegar mis razones. Aunque también es cierto que no hay más ciego que el que no quiere ver. Afortunadamente, no soy yo el que dice que virtualizar es más que recomendable, lo dicen los gurús. Aunque yo mismo tengo ejemplos suficientes, durante ya casi 5 años, de empresas que han apostado fuerte por cambiar su infraestructura y han recibido eficacia y beneficios económicos como premio. Pero el caso es que no se me da bien discutir ciertas cosas, me cuesta tenerme que explicar, no soy muy paciente ( esto es un defecto enorme).

Sea como fuere, dejo aquí “algunas” razones de peso con las que consolidar el porque recomendaría a cualquiera, desplegar su proyecto en un entorno virtualizado.

• Ejecutar varios sistemas operativos a la vez en el mismo hardware
• Reducir costes de capital, aumentando de paso la eficacia energética, reduciendo hardware y aumentando la proporción de servidores por administrador
• Mayor disponibilidad y rendimiento de las aplicaciones
• Mejor reacción ante desastres, mayor continuidad de negocio

Estas serían sólo algunas razones por las que apostar por la virtualización. Es raro que se discuta esto hoy en día, cuando la practica totalidad de la industria ha optado por la virtualización. Lo sorpendente, es que sin embargo, me aseguraron de que no tenían tantos reparos en utilizar servicios de cloud. Bueno, pues el cloud sin la virtualización no existiría. “Conditio sine qua non” que dirían los griegos. Así que si aceptamos el cloud, más a mi favor.

De todas formas, ya digo que tengo ejemplos profesionales “personales” suficientes como para consolidar estos puntos que he escrito en este post. La sóla idea de volver a un escenario “una aplicación, un servidor” me produce pesadillas.

Esto me refuerza en mi posición de que, no hay que poner al zorro a cuidar de las ovejas. Cada rol tiene su secreto, de la misma manera que yo no cuestiono cuando Eloi Poch hace una stored procedure así o asá, él no cuestiona si implementamos mejoras en la infraestructura.A veces es necesario abrir la mente a nuevas formas de trabajo, y no tener miedo a ciertos cambios. De hecho, si me propusieran administrar un proyecto “ambicioso” en la forma de “una aplicación, un servidor” me negaría en rotundo.

Para pasar la base de datos, de un estado a otro.

ALTER DATABASE [Works] SET MULTI_USER WITH NO_WAIT
ALTER DATABASE [Works] SET SINGLE_USER WITH NO_WAIT

EXEC sp_dboption 'Works', 'single user', 'false'
EXEC sp_dboption 'Works', 'single user', 'true'


Necesitaremos tres paquetes: openssl, libssh2 y ssh2

Comprobamos si tenemos openssl instalado:

[root@box1 ~]#rpm -qa |grep openssl

Si sale algo así lo tenemos ok

openssl096b-0.9.6b-22.46
openssl-0.9.7a-43.17.el4_6.1
openssl-devel-0.9.7a-43.17.el4_6.1

Las versiones difieren según la instalación. Sino lo tenemos lo instalamos:

yum install openssl (redhat OS)
apt-get install openssl (debian OS)

El segundo paquete es el libssh2.

[root@box1 ~]wget http://downloads.sourceforge.net/project/libssh2/
old-libssh2-releases
/1.1/libssh2-1.1.tar.gz?use_mirror=freefrhttp:
//downloads.sourceforge.net/project/libssh2/old-libssh2-releases
/1.1/libssh2-1.1.tar.gz?use_mirror=freefr
[root@box1 ~]tar -zxvf libssh2-1.1.tar.gz
[root@box1 ~]cd libssh2-1.1
[root@box1 libssh2-0.18]# ./configure
[root@box1 libssh2-0.18]# make
[root@box1 libssh2-0.18]# make install

Ahora necesitamos instalar el módulo ssh para PHP

[root@box1 ~]# wget http://pecl.php.net/get/ssh2-0.10.tgz
[root@box1 ~]# tar -xzf ssh2-0.10.tgz
[root@box1 ~]# cd ssh2-0.10
[root@box1 ssh2-0.10]# phpize && ./configure –with-ssh2 && make

Si finaliza sin errores ya lo tenemos instalado, faltaría añadir la extensión en el php.ini

extension=ssh2.so

Si nos encontramos un error como este:

*** [ssh2.lo] Error 1

Tendremos que hacer una pequeña modificación:

[root@box1 ssh2-0.10]# vi ssh2.c
Busca la linea
#if LIBSSH2_APINO < 200412301450
y editala así:
#if LIBSSH2_VERSION_NUM < 0x001000
Salva el archivo y vuelve a ejecutar: phpize && ./configure --with-ssh2 && make

Links

• http://hostechs.com/2008/07/installing-ssh2-for-php-shell-connections-how-to/comment-page-1/#comment-59
• http://stackoverflow.com/questions/561024/install-pecl-ssh2-extension-for-php
• http://forums.vpslink.com/centos/1682-installing-php-ssh2.html
• http://kevin.vanzonneveld.net/techblog/article/make_ssh_connections_with_php/

Your working copy remembers the unique id of the repository. The id is randomly assigned when someone (the administrator) creates a new repository.

Es decir, nuestro working copy tiene un id en base al repositorio actual, el id se genera de forma aleatoria cuando creamos un repositorio.

Este error lo tuvimos con los clientes tipo Eclipse, después de hacer un restore del repositorio en base a un backup. Lo arreglamos haciendo un checkout sobre cada proyecto que necesitemos.

De forma adicional, si hemos integrado SVN con TRAC, necesitaremos hacer un paso más.

# trac-admin /path/to/trac/ resync

De esta forma, TRAC se sincronizará con el restore del backup de SVN que hemos hecho previamente y que ha generado el error de UUID.

# mysqladmin -u root password NEWPASSWORD

# yum install quagga

La configuración ya es otro tema

/etc/quagga/ospfd.conf
/etc/quagga/zebra.conf

chkconfig --level 235 ospfd on
chkconfig --level 235 zebra on

Pasos básicos para instalar EZ templates para Virtuozo

1. Descargamos el template

# cd /vz/template ; wget http://downloads.swsoft.com/cgi-bin/getfile.pl/
centos/5/x86_64/centos-5-x86_64-ez-3.0.0-17.swsoft.noarch.rpm

2.  Instalamos template

# vzpkg install template "path_to_EZ_template"

3.  Comprobamos estado de los templates

# vzpkg list

4. Creamos la cache para poder utilizarlo en los containers

# vzpkg create cache  "centos-5-x86_64

5. Adicionalmente podemos ejecutar update cache para actualizar todos los EZ

# vzpkg update cache

Links

• Instrucciones de instalación
• Descarga de EZ template

Normalmente, cuando nos ocurre esto, es que algún proceso está bloqueando la gestión del contenedor, algo que se ha quedado a medias, etc. Se procede así:

VE is locked when some operation (backup, migration, start / stop, etc.) with this VE is in progress. You can determine which process is holding VE #101 using the following command on the hardware node:

# cat /vz/lock/101.lck

You can kill that process if needed. Make sure that the process is really killed. If there is no process with that PID on the node, just remove the lockfile.

Pero me encontré con un container que no respondía a esta solución, no había ningún proceso que respondiese al fichero, es más, borramos el fichero y intentamos reiniciar y lo mismo. Entramos dentro del container y ejecutamos reboot, pero se quedó en estado mounted. Conseguimos levantarlo así:

# vzctl --skiplock start VZID

Links
http://kb.parallels.com/fr/6834

Nota: en Plesk 9, el icono de “Limits” se ha cambiado por el siguiente “Resource Usage”. Este error hace referencia a que el tiempo de validez del dominio se agotó y hay que renovarlo. En “Resource Usage” podemos hacerlo.

Links
http://www.speedzoneroping.com/