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
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 missingHay 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 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
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-tokenizerMe 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
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-devel2. Instalamos PEAR.
zypper install php-pear3. 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.so5. 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.
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.
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=repackageTambié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.
Voy a empezar con un post un poco técnico pero de gran utilidad para la monitorización del servidor de bases de datos mysql.
mytop es una utilidad que sirve para monitorizar las consultas mysql, procesos, y rendimiento general del servidor de bases de datos mysql. Entre otras cosas, nos permite visualizar las consultas lentas (slow queries) que se ejecutan en la base de datos.
Vamos a realizar al instalación en un servidor CentOS. Para hacerlo, necesitamos tener instalados en nuestro servidor Perl , DBI y Term::ReadKey. Los dos primeros suelen estar instalados por lo que pasamos a instalar Term::ReadKey.
wget http://search.cpan.org/CPAN/authors/id/J/JS/JSTOWE/TermReadKey-2.30.tar.gz tar -zxvf TermReadKey-2.30.tar.gz cd TermReadKey-2.30 perl Makefile.PL make make test make install
Ahora pasamos a intalar mytop
wget http://jeremy.zawodny.com/mysql/mytop/mytop-1.4.tar.gz tar -zxvf mytop-1.4.tar.gz cd mytop-1.4 perl Makefile.PL make make test make install
Etiquetas: monitorización, mysql, mytop