Have you tried turning it off and on again?
Hace un tiempo, escribí como acceder de un servidor a otro mediante certificados por SSH, para automatizar tareas que requieran de una conexión SSH entre servidores, evitando así tener que introducir el password. Aquí el post original.
Sin embargo, en ocasiones, el SSH no está configurado para aceptar conexiones con password, y no podemos por lo tanto, usar el comando «ssh-copy-id». Para estas ocasiones, podemos seguir el procedimiento descrito a continuación:
Migrar un proyecto web (php/mysql) de un servidor a otro(s) puede parecer un proceso sencillo, pero rara es la vez en la que no salen imprevistos. Por esta razón, prefiero tener bien documentado todo el proceso de migración, antes de empezar, para evitar sobresaltos e ir sobre seguro.
La idea del siguiente proceso, es clonar la base de datos del servidor a migrar al nuevo servidor, y una vez clonada, modificar el código del servidor a migrar para empezar a usar la base de datos del nuevo server en lugar de la que usaba hasta ahora. De esta manera, no se perderán datos cuando se inicie la modificación de las DNS para apuntar al nuevo servidor.
REQUISITOS
En muchas ocasiones, hemos de actualizar o instalar nuevos paquetes en servidores críticos, que difícilmente podemos asegurar que no afectarán a nuestros servicios. Es posible que la nueva versión de PHP tenga alguna incompatibilidad con el código que usa la versión añeja que tiene el servidor, o que una nueva versión de openssh venga con un 0day.
¿Cómo podemos deshacer lo que acabamos de estropear con yum?
Afortunadamente, las últimas versiones de yum, vienen con una nueva funcionalidad que permite ver el histórico de ejecuciones, y lo más importante, volver atrás. Aquí lo explican en la documentación oficial.
Este post es una breve introducción a mod_rewrite, que puede servir como punto de partida, pero que no servirá ni mucho menos, como manual ni como guía. Por favor, mira las fuentes al final del mismo, para acceder a las fuentes originales y ampliar la información sobre mod_rewrite.
Mod_rewrite es uno de los módulos de Apache más importantes. Nos permitirá manipular urls (reescribiendo urls al vuelo), redirigir una url a otra o invocar un proxy interno, mediante una serie de reglas y condiciones.
En primer lugar, activaremos el motor de reescritura (en el .htaccess o en el virtualhost correspondiente), en el caso de que esté instalado mod_rewrite. Una vez activado, pondremos las reglas a continuación:
<IfModule mod_rewrite.c>
RewriteEngine On
## Aquí las reglas
</IfModule>
Si se ha ejecutado un proceso en una terminal Linux, y necesitamos retomar el control de la terminal sin interrumpir el proceso, podemos ejecutar «Ctrl+z» para parar el proceso, sin matarlo. De esta manera, volveremos a tener la terminal en primer plano.
Posteriormente podremos ejecutar «jobs» para ver el proceso recién detenido:
$ jobs
[1]+ Stopped ./test.sh
«Jobs» nos devolverá el número de la tarea correspondiente al proceso.
Si ejecutamos «bg», podremos reactivar el proceso y mandarlo a background, que es lo que deberíamos haber hecho originalmente, si hubiéramos sabido que el proceso se nos quedaría corriendo tanto tiempo en primer plano:
$ bg 1
[1]+ Running ./test.sh &
Foto por Maggie-Me
Logrotate es el proceso encargado de rotar, comprimir y enviar por mail los logs de sistema en Linux.
Cuando un paquete individual (como httpd, bacula, vsftpd, yum, etc.) se instala, éste añade en el directorio /etc/logrotate.d/ su fichero de configuración logrotate encargado de la gestión de los logs. Así por ejemplo, Apache añade un fichero similar al siguiente:
[root@server logrotate.d]# cat /etc/logrotate.d/httpd
/var/log/httpd/*log {
missingok
notifempty
sharedscripts
postrotate
/sbin/service httpd reload > /dev/null 2>/dev/null || true
endscript
}
Si se quieren añadir políticas de rotación de logs para logs que no estén definidos o que no estén en las rutas por defecto, se podrá tocar el fichero de configuración /etc/logrotate.conf
En este fichero (/etc/logrotate.conf), además, se configuran las políticas de rotación de logs comunes a todos los logs. En cada fichero de configuración dentro de /etc/logrotate.d, se pueden sobreescribir las políticas comunes, de forma local, redefiniendo el valor para la variable de configuración deseada. Así por ejemplo, se podría crear un fichero para rotar los logs del tipo /var/log/miapp.log que deja una aplicación concreta, tal y como sigue:
[root@server logrotate.d]# cat /etc/logrotate.d/miapp
/var/log/miapp.log {
weekly
copytruncate
rotate 4
compress
missingok
}
Con la definición anterior, estaríamos inficando:
Logrotate no es un demonio que corre en la máquina. Así pues, tras realizar cualquier cambio en el fichero de configuración, no será necesario realizar ningún restart de ningún servicio. Símplemente, Logrotate usará la nueva configuración en la siguiente ejecución. Si se desea testear Logrotate tras algún cambio en su configuración, se puede ejecutar el comando siguiente:
logrotate -vf /etc/logrotate.conf
PD: Es posible que tras la ejecución del comando anterior, tarde unos segundos en empezar a escribir en el nuevo fichero de logs.
Útil y muy necesario para mantener controlado el espacio usado por los logs.
Fuentes:
http://www.thegeekstuff.com/2010/07/logrotate-examples/
http://www.linuxcommand.org/man_pages/logrotate8.html
http://www.linuxquestions.org/questions/linux-newbie-8/
Bacula es probablemente, la solución OpenSource más conocida para la realización de copias de seguridad a nivel empresarial. Bacula se compone de varios elementos:
En entornos tanto físicos como virtuales, es común encontrarse con la necesidad de añadir un disco duro extra a un servidor tipo Red Hat. Éste proceso se puede hacer de diversas maneras, pero con cualquiera de ellas, se convierte en una tarea crítica, puesto que cualquier fallo nos puede provocar muchos problemas.
A continuación describo el proceso que a mi me funciona:
Identificar los discos, con
fdisk -l
Crear una partición primaria para el nuevo disco, en el ejemplo /dev/sda:
[root@USAFront2 dev]# fdisk /dev/sda
Orden (m para obtener ayuda): n
Acción de la orden
e Partición extendida
p Partición primaria (1-4)
p
Número de partición (1-4): 1
Primer cilindro (1-4865, valor predeterminado 1):
Se está utilizando el valor predeterminado 1
Last cilindro, +cilindros or +size{K,M,G} (1-4865, valor predeterminado 4865):
Se está utilizando el valor predeterminado 4865Orden (m para obtener ayuda): w
¡Se ha modificado la tabla de particiones!NOTA:
n Añade una nueva partición
w Escribe la tabla en el disco y sale
En las distribuciones tipo Red Hat, cada usuario de sistema puede modificar su fichero $HOME/.bash_profile, para por ejemplo, definir nuevos comandos, programas a ejecutar en el momento de acceder al sistema, o cambiar los valores de las variables de entorno como $PATH.
Cuando un usuario (excepto «root») se loguea, primero se ejecuta el fichero /etc/profile, que contiene las definiciones comunes para todos los usuarios, y posterioremente, se ejecutará el fichero .bash_profile correspondiente al usuario.
«When bash is invoked as an interactive login shell, or as a non-interactive shell with the –login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.»
Fuente: «man bash»
Si se quisiera realizar un cambio en una variable de entorno para todos los usuarios, se recomienda crear un fichero .sh en /etc/profile.d/ con el código correspondiente, en lugar de modificar directamente el fichero /etc/profile.
«It’s NOT a good idea to change this file unless you know what you are doing. It’s much better to create a custom.sh shell script in /etc/profile.d/ to make custom changes to your environment, as this will prevent the need for merging in future updates.»
Fuente: «head /etc/profile»
Fuente: http://www.troubleshooters.com/linux/prepostpath.htm
Amazon AWS ofrece un sistema de almacenamiento de archivos llamado S3. Este sistema se puede aprovechar para gestionar archivos de forma automática desde un servidor Linux, para, por ejemplo, realizar copias de seguridad o almacenar otros datos.
Para ayudarnos a gestionar S3 desde una terminal de un servidor Linux, disponemos de herramientas como s3cmd, lista para instalar con yum:
[root@server]# yum info s3cmd
Paquetes instalados
Nombre : s3cmd
Arquitectura : noarch
Versión : 1.0.1
Lanzamiento : 1.fc15
Tamaño : 319 k
Repositorio : installed
Desde el repositorio : updates
Resumen : Tool for accessing Amazon Simple Storage Service
URL : http://s3tools.logix.cz/s3cmd
Licencia : GPLv2
Descripción :S3cmd lets you copy files from/to Amazon S3
: (Simple Storage Service) using a simple to use
: command line client.