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: .DS_Store, borrar, comando, proyecto, recursivamente, svn
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: error, subversion, svn, trac, trac-admin
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: 302, css, htaccess, imágenes, ip, mantenimiento, redirect
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: control de versiones, error, svn
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: svn
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: opensuse, php, php5-tokenizer, Symfony, zypper
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.
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.
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.
