msgbartop
Desarrollador Web, Android y iOS
msgbarbottom

Borrar carpetas .svn y archivos .DS_Store recursivamente de nuestro proyecto

Este comando nos permitirá borrar las carpetas .svn recursivamente de todas las subcarpetas a partir del directorio donde nos encontremos. Puede ser útil en diferentes ocasiones como que hayamos subido esta información al servidor de producción, se ha corrompido el sistema svn, etc.

find . -name .svn -print0 | xargs -0 rm -rf

MUCHO CUIDADO: ejecutarlo dentro de la carpeta del proyecto para que solo afecte a sus subdirectorios.

Este otro comando, reutilizado del anterior, nos servirá para borrar los archivos .DS_Store recursivamente que nuestro diseñador ha tenido la “amabilidad” (con la complicidad de su Mac) de subirlos al proyecto.

find . -name .DS_Store -print0 | xargs -0 rm -rf

Etiquetas: , , , , ,

Error Trac svn: The Trac Environment needs to be upgraded

Si utilizas o has utilizado subversion como sistema de control de versiones en algún proyecto, seguramente hayas manejado el Trac (http://trac.edgewall.org/). Trac es una interfaz web que permite gestionar proyectos almacenados en servidores SVN: control de bugs, wiki, historial de commits, etc.

En ocasiones me he encontrado un error cuando navegas por el listado de proyectos disponibles en el Trac o directamente al acceder a un proyecto.

El error es el siguiente:

miproyecto: Error 
(The Trac Environment needs to be upgraded. Run "trac-admin /var/local/trac/miproyecto upgrade")

Hacemos lo que nos indica el error y ejecutamos en consola:

sudo trac-admin /var/local/trac/miproyecto upgrade

Algunas veces con esto es suficiente y el problema se ha resuelto. Pero otras veces no y sigue apareciendo el error en el Trac. De hecho, la consola nos devuelve un mensaje indicando que la base de datos ya estaba actualizada:

Database is up to date, no upgrade necessary.

El error es más simple de lo que parece pero podemos pasarnos un buen rato buscando la solución. El secreto: no es más que un error de permisos en el archivo trac.ini

Ejecutamos lo siguiente:

sudo chmod 777 /var/local/trac/miproyecto/conf/trac.ini

Ya lo tendremos solucionado y podremos acceder al Trac de nuestro proyecto en subversion

Etiquetas: , , , ,

Login en ssh sin password

Es habitual tener que acceder a nuestros servidores mediante ssh en nuestro día a día. Cada uno cuenta con su usuario y contraseña, lo que puede ser algo bastante molesto (y repetitivo) si no recordamos cada una de ellas y tenemos que buscarlas cada vez que queremos acceder.

Por este motivo existe un archivo en la configuración de ssh que nos permite añadir claves autorizadas sin ser necesario pedir autorización a la máquina cliente que posea esa clave.

Para generar esta clave en nuestra máquina local, haremos lo siguiente:

usuario@cliente:~$ ssh-keygen -t rsa
Generating public/private rsa key pair. 
Enter file in which to save the key (/home/usuario/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/usuario/.ssh/id_rsa. 
Your public key has been saved in /home/usuario/.ssh/id_rsa.pub. 
The key fingerprint is: 91:95:c0:a0:22:04:16:e0:7d:d4:71:60:d4:d0:60:a8 usuario@cliente

Con el comando “ssh-keygen -t rsa” generaremos la clave que identifica a nuestro ordenador. Es la clave que deberemos indicarle al ssh del servidor para que no nos pida identificación cuando hagamos login desde esa máquina.

Ahora copiaremos esta clave en el servidor. Lo haremos mediante el comando “scp”:

usuario@cliente:~$ scp .ssh/id_rsa.pub usuario@servidor:/ruta-a-nuestra-home
usuario@servidor's password:
id_rsa.pub           100% |**************************************|   397       00:00

Accedemos al servidor mediante ssh (aún nos pedirá la contraseña) para poder añadir la clave en el archivo correcto.

servidor:~$ cat id_rsa.pub >> .ssh/authorized_keys
servidor:~$ exit

Hemos añadido el contenido de “id_rsa.pub” (que generamos anteriormente en nuestra máquina local y copiamos al servidor mediante el comando scp) al archivo authorized_keys del directorio .ssh de nuestro servidor.

Ahora ya podremos hacer login con ssh desde nuestra máquina local y el servidor no nos pedirá la contraseña.

En otro post ya expliqué como aumentar la seguridad cambiando el puerto por defecto de ssh.

Etiquetas: , , , , ,

Redireccionar a página de mantenimiento con htaccess, manteniendo los estilos css y las imágenes

Si vamos a realizar cambios en nuestra web y se tratan de cambios que pueden afectar al funcionamiento de la página (cambios en la base de datos, cambio de funcionalidades, etc), lo ideal es redirigir a una página de mantenimiento para informar a los usuarios mientras se realizan los cambios. En este caso lo vamos a hacer editando el archivo .htaccess y dando permiso a nuestra ip para acceder a la web normalmente y poder ver los cambios. El resto de usuarios verán la página de mantenimiento a la que les redirigiremos.

1
2
3
4
5
6
<IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteCond %{REMOTE_ADDR} !^999\.999\.999\.999
 RewriteCond %{REQUEST_URI} !/mantenimiento.html$ [NC]
 RewriteRule .* /mantenimiento.html [R=302,L]
</IfModule>

En la línea 3, cambiaremos la ip por la nuestra propia para poder acceder normalmente.
La línea 4 indica que no redirija si ya estamos en la página de mantenimiento (para evitar un bucle infinito).
Y en la línea 5 indicamos la ruta de la propia página de mantenimiento con una redirección 302 (redirección temporal).

Hasta aquí todo bien. El problema es que desde la página de mantenimiento no podemos acceder a las imágenes o estilos css porque también se ejecuta la redirección. Para evitar esto, añadiremos una línea más al código anterior:

1
2
3
4
5
6
7
<IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteCond %{REMOTE_ADDR} !^999\.999\.999\.999
 RewriteCond %{REQUEST_URI} !/mantenimiento.html$ [NC]
 RewriteCond %{REQUEST_URI} !\.(jpe?g?|png|gif|css) [NC]
 RewriteRule .* /mantenimiento.html [R=302,L]
</IfModule>

Ahora todo debería funcionar correctamente. Cuando hayamos terminado de hacer los cambios, solo tendremos que comentar las líneas anteriores.

Etiquetas: , , , , , ,

Error svn: Directory .svn containing working copy admin area is missing

El motivo por el que nos puede aparecer este error (utilizando el sistema de control de versiones svn) al intentar hacer un commit, es porque hemos borrado (o ha desaparecido misteriosamente ;) ) la carpeta .svn de alguno de los directorios del proyecto.

svn: Directory .svn containing working copy admin area is missing

Hay dos soluciones:

1) Descargarnos de nuevo el proyecto completo (checkout).

svn co http://servidorsvn/proyecto/trunk proyecto

2) Si la carpeta .svn ha desaparecido solamente de uno de los directorios del proyecto, podemos bajarnos solo esa carpeta y mover el archivo .svn a nuestro proyecto (a la carpeta a la que falta el .svn).

En este ejemplo, se ha borrado la carpeta .svn del directorio css.

svn co http://servidorsvn/proyecto/trunk/css css_copia
mv css_copia/.svn /ruta_al_proyecto/proyecto/css/
rm -rf css_copia

Etiquetas: , ,

Error svn: The log message is a pathname

Error tonto donde los haya relacionado con el sistema de control de versiones svn, pero que nos puede llevar un buen rato y algún que otro quebradero de cabeza dar con la solución.

Si intentamos hacer un commit de los cambios con la orden:

svn commit -m "plugins" ./proyecto/plugins

Nos mostrará el siguiente error:

svn: The log message is a pathname (was -F intended?); use '--force-log' to override

El “error” es que el mensaje que adjuntamos con el commit es igual al nombre de la carpeta que estamos subiendo. Lo arreglaremos cambiando el nombre del mensaje:

svn commit -m "cambios en plugins" ./proyecto/plugins

Etiquetas:

Error con la función token_get_all() al crear proyecto con Symfony 1.4

Cuando tenemos un servidor recién instalado, nos podemos encontrar con que algunos paquetes necesarios no están instalados en el sistema. Esto me ha ocurrido al intentar generar un nuevo proyecto con Symfony 1.4 en un servidor con OpenSuse 11.1.

Al intentar crear un nuevo proyecto con el comando:

php symfony generate:project miproyecto

La orden no se ejecutaba en su totalidad y me dejaba unos “bonitos” mensajes de error, relacionados con la función token_get_all():

PHP Notice:  Use of undefined constant T_FINAL - assumed 'T_FINAL' in /var/symfony14/lib/util/sfClassManipulator.class.php on line 52
PHP Notice:  Use of undefined constant T_ABSTRACT - assumed 'T_ABSTRACT' in /var/symfony14/lib/util/sfClassManipulator.class.php on line 52
PHP Notice:  Use of undefined constant T_STATIC - assumed 'T_STATIC' in /var/symfony14/lib/util/sfClassManipulator.class.php on line 52
PHP Notice:  Use of undefined constant T_PUBLIC - assumed 'T_PUBLIC' in /var/symfony14/lib/util/sfClassManipulator.class.php on line 52
PHP Notice:  Use of undefined constant T_PROTECTED - assumed 'T_PROTECTED' in /var/symfony14/lib/util/sfClassManipulator.class.php on line 52
PHP Notice:  Use of undefined constant T_PRIVATE - assumed 'T_PRIVATE' in /var/symfony14/lib/util/sfClassManipulator.class.php on line 52
PHP Notice:  Use of undefined constant T_FUNCTION - assumed 'T_FUNCTION' in /var/symfony14/lib/util/sfClassManipulator.class.php on line 52
PHP Fatal error:  Call to undefined function token_get_all() in /var/symfony14/lib/util/sfClassManipulator.class.php on line 117

Este problema con la función token_get_all() lo solucionaremos instalando la extensión para php “php5-tokenizer”:

zypper install php5-tokenizer

Me he encontrado este error al generar un nuevo proyecto con Symfony pero nada tiene que ver con el framework. Quizás para cualquier otro proyecto donde no utilicemos Symfony no nos haga falta instalarlo y no lo echemos de menos. Visto lo visto, con Symfony es totalmente necesario tener esta extensión instalada.

Etiquetas: , , , ,

Instalar funcionalidad hash_hmac() en OpenSuse 11.1

En algunos proyectos vamos a necesitar algunas funciones que por algún motivo no tenemos instaladas en nuestro servidor. Un ejemplo puede ser la función hash_hmac(), que sirve para genera un valor cifrado mediante una clave dada usando el método HMAC. Esta función es utilizada, por ejemplo, en la librería de autentificación OAuth para generar la firma.

Cuando la vamos a utilizar, nos mostraría el error:
Call to undefined function hash_hmac()

Voy a explicarlo para OpenSuse 11.1, pero no debería haber problema para instalarlo en cualquier otra distribución (cambiando zypper por apt-get, por ejemplo).

1. Comprobamos si tenemos instalado el paquete php-devel o php5-devel. Si no, lo instalamos:

zypper install php5-devel

2. Instalamos PEAR.

zypper install php-pear

3. Ejecutamos

pecl install hash

4. Añadimos la extensión al archivo php.ini (en mi caso /etc/php5/apache2/php.ini):

; Enable pecl_hash extension module
extension=hash.so

5. Reiniciamos Apache

/etc/init.d/apache2 restart

Con estos pasos ya deberíamos poder utilizar la función hash_hmac (entre otras) en nuestros proyectos.

Etiquetas: , , , , ,

Cambiar puerto 22 del servidor ssh

Si queremos tener más seguridad en nuestro servidor, un truco fácil es el de cambiar el puerto del servidor ssh. Por defecto, la conexión se hace en el puerto 22, que es uno de los puertos más utilizados por scripts maliciosos para realizar ataques por fuerza bruta o denegación de servicio.

Cambiar el puerto del ssh es tan sencillo como hacer lo siguiente:

1
nano /etc/ssh/sshd_config

Editamos la linea dice

1
#Port 22

La descomentamos (quitamos la almoadilla) y cambiamos el 22 por el puerto que queramos. Nos tenemos que asegurar de que el puerto que elijamos no esté ya en uso (Aquí tenemos una lista de puertos). Por ejemplo, si elegimos el puerto 27, la línea quedará:

1
Port 27

Ahora editamos el archivo /etc/services

1
nano /etc/services

buscamos las líneas:

1
2
ssh         22/tcp
ssh         22/udp

y las cambiamos por el nuevo puerto que hemos seleccionado antes:

1
2
ssh         27/tcp
ssh         27/udp

Ahora paramos e iniciamos el servidor ssh:

1
/etc/init.d/ssh stop
1
/etc/init.d/ssh start

Y ya lo tenemos. A partir de ahora, cuando queramos acceder a nuestro servidor mediante ssh, deberemos especificar el puerto por el que nos queremos conectar. Por ejemplo:

1
ssh usuario@192.168.1.100 -p27

Puede que te salte algún error relacionado con las public keys. Es normal, ya que anteriormente ha detectado movimiento en el puerto 22. Simplemente hay que borrar esos public keys:

1
 rm ~/.ssh/known_hosts

A partir de ahora tendremos nuestro servidor ssh un poco más seguro.

Etiquetas: , ,

CentOS / Red Hat: Deshacer yum update (roll back)

Es bastante importante tener actualizado nuestro servidor con los parches de seguridad más recientes. Puede que el sistema se actualice sin problemas… pero puede que no. En esos momentos es cuando desearíamos poder volver a la versión anterior de los paquetes que hemos actualizado.

Con el gestor de paquetes yum lo podemos hacer. Para ello, primero tenemos que modificar un par de archivos:

Añadimos esta linea al fichero /etc/yum.conf

tsflags=repackage

También deberemos añadir esta linea al archivo /etc/rpm/macros (si no existe, lo creamos)

%_repackage_all_erasures 1

La documentación de rpm no tiene ninguna referencia a la opción deshacer (rollback). Para volver a la versión de los paquetes anteriores a la actualización usaremos el comando rpm con el parametro –rollback

rpm -Uhv --rollback '15:00'
rpm -Uhv --rollback '2 hours ago'
rpm -Uhv --rollback 'december 31'
rpm -Uhv --rollback 'yesterday'

Es una buena idea activar el rollback por lo que pueda pasar. Ahora podremos ejecutar

yum update

sin miedo a posibles incompatibilidades.

Etiquetas: , , ,