¿Cuándo reiniciar Apache?

RAID
Dos preguntas cortas con respuestas de copy&paste sobre Apache.

¿Una modificación en el archivo php.ini requiere reiniciar apache para aplicarse?
«Si tenemos PHP como módulo del servidor, el archivo php.ini se lee cada vez que se reinicia. Por lo tanto tienes que reiniciar para que actualice los cambios. »
Fuente: http://www.ignside.net/man/servidores/phpini.php

¿Y qué pasa si no puedo reiniciar apache porqué está en producción sirviendo una aplicación crítica?
«Las señales USR1 o graceful hacen que el proceso padre indique a sus hijos que terminen después de servir la petición que estén atendiendo en ese momento (o de inmediato si no están sirviendo ninguna petición). El proceso padre lee de nuevo sus ficheros de configuración y vuelve a abrir sus ficheros log. Conforme cada hijo va terminando, el proceso padre lo va sustituyendo con un hijo de una nueva generación con la nueva configuración, que empeciezan a servir peticiones inmediatamente.»
Fuente: http://httpd.apache.org/docs/2.0/stopping.html

Actualización Noviembre 2013

Aprovecho para actualizar este post con un par de apuntes:

  • Ante cualquier cambio en la configuración de Apache, podemos verificar si hay problemas con la nueva configuración, antes de aplicar los cambios, ejecutando:
/etc/init.d/httpd configtest
  • Una vez verificada la configuración, podemos reiniciar la configuración (sin necesidad de reiniciar Apache y por tanto sin afectar al servicio) símplemente haciendo un reload:
/etc/init.d/httpd reload

Flickr! Foto por US Mission Geneva

Registrar actividad en sesión ssh

spy
Imaginemos que queremos un método para registrar todo lo que un determinado usuario realiza durante su sesión ssh. Por lo tanto, lo que se busca es guardar el log de la actividad del usuario en el propio equipo al que se conecta, y por supuesto, no se quiere que el usuario pueda modificar o eliminar este archivo de log.

Opción 1

Una primera opción, es complicarse la vida, montando este entorno a mano.

Continuar leyendo «Registrar actividad en sesión ssh»

Verificar el estado del RAID con hpacucli

RAIDEn ocasiones es necesario ver el estado del RAID de un determinado servidor. El problema, es que normalmente se necesita reiniciar la máquina para poder entrar en la BIOS, la cual contiene los detalles del RAID.

Sin embargo, algunos fabricantes proporcionan herramientas que permiten consultar este tipo de información, sin necesidad de interrumpir el servicio por culpa de un reinicio.

  • En una máquina con SO Fedora, primeramente he consultado el modelo del servidor con la utilidad «lshw» que se puede instalar directamente con yum.
  • Tras comprobar que el servidor corresponde a un HP Proliant, he buscado en la web del fabricante una herramienta de este tipo, que en el caso de HP ha resultado ser HP Array Configuration Utility CLI for Linux, disponible en este enlace.
  • Para esta utilidad, HP pone a disposición todas las versiones que se han publicado de la misma, pero me he decidido a descargar la versión recomendada (se puede ver el «recommended» en el título, grande y descriptivo).
  • La herramienta se instala con «rpm -i hpacucli-8.61-1.0.noarch.rpm«.
  • Una vez instalada, se podrá ejecutar el comando «hpacucli»

Continuar leyendo «Verificar el estado del RAID con hpacucli»

MySQL usuario de lectura

Resulta que crear un usuario de mysql con acceso desde hosts remotos no es tan intuitivo como podría pensarse. Durante la creación de un usuario en mysql, ya sea con el comando apropiado o mediante utilidades como «mysql_setpermission», se debe indicar si el usuario mysql podrá conectar con el motor SQL únicamente desde el localhost, o si por el contrario, tendrá acceso desde un host remoto específico o desde cualquier host (%).

Sin embargo, para que el acceso remoto funcione, deberá crearse primero el usuario localhost y posteriormente el mismo usuario para %:

mysql> create user ‘readonly’@’localhost’ identified by ‘mipassword’;
Query OK, 0 rows affected (0.00 sec)

mysql> grant select on *.* to ‘readonly’@’localhost’;
Query OK, 0 rows affected (0.00 sec)

mysql> create user ‘readonly’@’%’ identified by ‘mipassword’;
Query OK, 0 rows affected (0.00 sec)

mysql> grant select on *.* to ‘readonly’@’%’;
Query OK, 0 rows affected (0.00 sec)

 

Esto se puede leer en la documentación oficial de MySQL:

«It is necessary to have both accounts for monty to be able to connect from anywhere as monty

Con estas instrucciones se habrá creado un usuario llamado «readonly» con únicamente permisos de lectura (selects) contra todas las bases de datos existentes, tanto desde el host local como desde cualquier otro host remoto.

Límite de conexiones en MySQL

MySQL tiene un límite de conexiones simultáneas que acepta, que por defecto en las versiones actuales está en 150. En realidad, 151, puesto que esta 1 está reservada para el administrador poder conectar en local y ver qué está pasando.

Podemos consultar el límite actual, tal y como se muestra en el siguiente ejemplo:

mysql> show variables like «max_connections»;
+—————–+——-+
| Variable_name | Value |
+—————–+——-+
| max_connections | 151 |
+—————–+——-+
1 row in set (0.00 sec)

Si quisiéramos incrementar el límite por ejemplo a 300 conexiones simultáneas, únicamente deberíamos añadir la siguiente línea al archivo de configuración de MySQL, típicamente en /etc/my.cnf:

max_connections = 300

Una vez hecho esto, y después del posterior reinicio del servicio, deberíamos poder confirmar el incremento del límite:

mysql> show variables like «max_connections»;
+—————–+——-+
| Variable_name | Value |
+—————–+——-+
| max_connections | 300 |
+—————–+——-+
1 row in set (0.00 sec)

Actualización: También podemos cambiar este parámetro «al vuelo» con el comando siguiente:

mysql> SET GLOBAL max_connections = 300;

Decir, que tenemos un par de opciones para ver el número de conexiones actuales:

mysql> SHOW STATUS WHERE `variable_name` = ‘Threads_connected’

O directamente,

mysql> SHOW PROCESSLIST;

Fuentes:
http://www.electrictoolbox.com/update-max-connections-mysql/
http://forums.mysql.com/read.php?24,15350,28036

Nagios: añadir nuevo host

Nagios
Nagios tiene todo un seguido de ficheros de configuración de objetos, donde se definen entre otros, los elementos a monitorizar (servidores, routers, impresoras, etc.) así como los servicios de cada elemento. Estos ficheros, están relacionados entre sí, y de hecho, se puede (y se recomienda) que así sea, con tal de re-aprovechar lo máximo posible las características comunes, en forma de templates.

Así pues, si se quiere añadir un nuevo elemento (por ejemplo un servidor) para ser monitorizado por Nagios, primeramente deberemos revisar el archivo templates.cfg, el cual contiene las plantillas con las definiciones comunes que podremos usar, para en este caso, dar de alta un nuevo host. Por ejemplo, se podrá incluir (si no existe ya) un template para dar de alta servidores, que contenga las definiciones comunes (o más comunes), con tal de ahorrar escribir siempre lo mismo en el momento del alta de los servidores en Nagios.

Continuar leyendo «Nagios: añadir nuevo host»

Configurar claves ssh

SSH keyImaginemos que queremos conectar desde un servidor A, usando el usuario «user», con otro servidor B, por ssh, pero sin tener que estar introduciendo el password a cada nueva conexión (por ejemplo, si queremos poder conectar automáticamente por ssh por necesidades de un script en un cron). En este caso, podremos seguir el proceso descrito a continuación:

  • En el servidor A, si «user» no tiene ya una clave ssh creada (se podrá ver si existe en $HOME/.ssh/ un archivo .pub), se podrá generar dicha clave, estando logueados con el usuario «user», ejecutando:

ssh-keygen -t dsa

  • Una vez creada la clave ssh, deberemos ir al servidor B y crear un usuario «user» (en este caso querremos conectar desde A, a user@B). Podemos usar «useradd user» y posteriormente «passwd user» para crear al usuario.
  • Ahora desde A, podremos conectar con B mediante:

ssh user@B

  • De nuevo desde A, podremos copiar la clave pública de user (de A) a la home del usuario user (de B) con el comando:

ssh-copy-id -i ~/.ssh/id_dsa.pub user@B

  • Desde este momento, ya se podrá conectar desde A a user@B sin necesidad de introducir el password del usuario «user» en el servidor B.

Fuentes:

 

Nagios: host no pingable

Hoy toca hablar de Nagios, el conocido sistema de monitorización. Nagios, nos ayuda a conocer el estado de nuestra red, monitorizando los servidores y sus servicios, así como todo un seguido de parámetros configurables, tanto a nivel de servidor, como a nivel de elemento de red (routers, switches, impresoras de red, etc.).

Por defecto, Nagios utiliza el parámetro “check-host-alive” para verificar si una máquina está o no funcionando. Este parámetro en realidad, únicamente lanza un ping a dicha máquina. El resultado del ping, determinará si la máquina está o no caída.

Sin embargo, el ping es un elemento 100% fiable para determinar la disponibilidad de una máquina. Si, como en mi caso, te has encontrado con alguna máquina que no es pingable (por ejemplo porqué se trata de un firewall en modo stealth, o símplemente porqué la máquina tiene iptables activado y está denegando los pings), ésta aparecerá en Nagios como caída, lo cual dará una falsa sensación de alarma.

Continuar leyendo «Nagios: host no pingable»

Instalar KDE

Instalar KDE
Hoy he tenido que instalarle el entorno gráfico KDE a un servidor Fedora 13 en modo texto. Para ello, he intentado usar el comando «yum groupinstall “KDE (K Desktop Environment)”» pero no ha habido suerte, básicamente, porqué he comprobado con «yum grouplist» como el grupo de paquete “KDE (K Desktop Environment)” no se encontraba ni entre los paquetes instalados, ni entre los disponibles.

Finalmente, aquí, he encontrado la solución:

  1. Descargar el repositorio oficial de KDE -> wget http://apt.kde-redhat.org/apt/kde-redhat/fedora/kde.repo
  2. Mover el repositorio descargado, al directorio de repositorios de yum -> mv kde.repo /etc/yum.repos.d/
  3. Ejecutar el comando para instalar/actualizar KDE -> yum groupupdate kde-desktop
  4. Y posteriormente, ejecutar una actualización de los paquetes del sistema -> yum update

Configurando mod_wsgi

Hello worldDespués de la entrada de instalación de mod_wsgi, llega la segunda parte: «peleándome con su configuración». En esta ocasión, al igual que con la instalación, he seguido los pasos de la guía rápida de configuración oficial, que paso a detallar a continuación:

  • En primer lugar, he creado un archivo llamado «myapp.wsgi» con el siguiente código:
def application(environ, start_response):
    status = '200 OK'
    output = 'Hello World!'

    response_headers = [('Content-type', 'text/plain'),
                        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)

    return [output]

Continuar leyendo «Configurando mod_wsgi»