/etc/php.ini

En primer lugar, podríamos mirar el archivo de configuración del php en busca de las líneas correspondientes a la gestión de la visualización de los mensajes de error. Se recomienda que ambos parámetros estén a Off si se quiere evitar que tras un error en el servidor, se le muestre al usuario el código relativo al error, o incluso el fragmento de código php que lo ha provocado:

display_errors = Off
display_startup_errors = Off

/etc/httpd/conf/httpd.conf – Configuración básica

En cuanto al fichero de configuración de Apache, se podrían comprobar las siguientes directivas:

KeepAlive Off

No permite sesiones de larga duración. En según qué entornos interesará permitirlas, pero en otros entornos con muchas peticiones, ésto incrementará el número de conexiones simultáneas impactándo en el rendimiento, ya que las conexiones permanecerán abiertas más tiempo.

Timeout 60

Esta directiva se encarga de definir el tiempo máximo que el servidor esperará, para que ocurran determinados eventos. Tras una instalación por defecto, esta directiva se habrá configurado para esperar 60 segundos, pero según el caso, podría interesar aumentar o reducir este valor.

Include conf.d/*.conf

Con esta línea, se está indicando que el fichero de configuración de Apache buscará cualquier otro archivo con extensión .conf dentro del directorio conf.d, ubicado en lo definido en la directiva ServerRoot.

ServerName 80.90.100.101:80

La directiva ServerName especifica el nombre del servidor y el puerto a usar. Si se están usando virtual hosts, cada virtual host especifica su propio nombre para el servidor, con lo que se puede dejar esta directiva con la ip pública de la máquina.

NameVirtualHost *:80

Si se quiere usar virtual hosts (lo habitual), se deberá habilitar esta directiva para permitir hosting virtual basado en nombres.

DirectoryIndex index.php index.html index.html.var

También suele ser habitual, querer servir páginas php con Apache. Con la directiva “DirectoryIndex” se pueden definir el nombre de los archivos que el servidor buscará para servir como índice cuando se le realice una petición (tipo index.html).

/etc/httpd/conf/httpd.conf – Consejos de seguridad

ServerRoot

La directiva ServerRoot define el directorio de instalación de Apache. Este directorio, al igual que sus ficheros y subdirectorios, deben pertenecer tanto como usuario como grupo a root. Además, el único usuario que debería tener permisos de escritura sobre cualquier fichero o directorio dentro de ServerRoot, debería ser el propio “root”.

<Directory />
AllowOverride None
</Directory>

Con la directiva AllowOverride None, dentro del Directory raíz, se previene que un usuario pueda usar el fichero .htaccess (a parte de los casos explícitamente definidos), el cual podría configurar directivas de seguridad diferentes a las especificadas en el fichero de configuración de Apache.

<Directory />
Order Deny,Allow
Deny from all
</Directory>

Las anteriores instrucciones, denegarán el acceso a cualquier parte del sistema de ficheros. Al definir el comportamiento para el Directory raíz, se podría incluir dentro de este Directory, la anterior directiva AllowOverride None explicada anteriormente. Una vez definido, se podrán añadir Directorys para permitir el acceso a determinadas áreas:

<Directory /usr/local/httpd>
Order Deny,Allow
Allow from all
</Directory>

Otra acción recomendable podría ser revisar el DocumentRoot que viene por defecto en Apache, normalmente en forma de <Directory “/var/www/html”>, que por defecto, puede venir definida tal y como sigue:

<Directory “/var/www/html”>
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>

En este caso podríamos querer desactivar el listado de archivos (lo cual muestra los archivos y subdirectorios en caso de no encontrar ningún archivo del tipo DirectoryIndex como index.html):

Options -Indexes

Otra opción interesante, es asegurarse de desactivar la ejecución de CGIs, en caso de no querer utilizarlos con la opción:

Options -ExecCGI

Fuentes: http://httpd.apache.org/docs/2.0/mod/core.html
http://httpd.apache.org/docs/current/misc/security_tips.html
http://www.desarrolloweb.com/articulos/20-trucos-de-seguridad-para-apache.html
http://httpd.apache.org/docs/2.0/mod/core.html#options

Foto por US Mission Geneva

[root@server ]# virsh -c qemu:///system
Bienvenido a virsh, la terminal de virtualización interactiva.
Ingrese: ‘help’ para obtener ayuda con los comandos
‘quit’ para salir
virsh #

Hay que tener en cuenta, que el comando anterior debe ejecutarse estándo logueado con un usuario con permisos suficientes (“root” en el ejemplo). Una vez dentro, podremos teclear “help” para obtener el listado de comandos, donde veremos que con “list” se nos listarán las máquinas virtuales alojadas en la máquina, y su estado:

virsh # list
Id Nombre               Estado
———————————-
1 vm_srvQA            ejecutando
2 vm_server23             ejecutando

Podremos obtener más información de cada máquina, con “dominfo”.

virsh # dominfo vm_srvQA
Id:             1
Nombre:         vm_srvQA
UUID:           b5a3712d-116a-433c-a204-80cdee30e2da
Tipo de sistema operatuvo: hvm
Estado:         ejecutando
CPU(s):         1
hora del CPU:   1218452,2s
Memoria máxima: 1048576 kB
Memoria utilizada: 1048576 kB
Persistent:     yes
Autoinicio:     activar

Entre los múltiples comandos de gestión, podremos hacer uso de “shutdown”, “reboot” o “start” seguido del nombre de la máquina obtenido mediante el comando “list”, según lo necesitemos.

Fuentes:

• http://doc.opensuse.org/documentation/html/openSUSE/opensuse-kvm/cha.libvirt.managing.html
• http://www.centos.org/docs/5/html/5.2/Virtualization/chap-Virtualization-Managing_guests_with_virsh.html

Foto por ivanwalsh

¿A cuántos de vosotros más de una vez se os ha quedado colgado un Linux y habéis tenido que hacerle un “botonazo”?
Pues debéis saber que Linux cuenta con la posibilidad de apagar el sistema de forma “segura” delante de un cuelgue inesperado o un kernel panic con las llamadas “Las Magic Keys o Claves Mágicas”.

Como todos sabemos, los kernel panic, son los sucesos más preocupantes en un Linux puesto que dependiendo del sistema de ficheros o volumen de información que se maneje, puede provocar una pérdida de información de muy difícil solución, aquí es donde entra esa tecla que acostumbra a pasar desapercibida en nuestros teclados, la tecla “Pet Sys” (en algunos teclados no existe como tal pero es la misma que la de “Impr Pant”). En muchas distribuciones vienen activadas por defecto, pero podéis activarlas en todas.

En el caso en que nos encontremos que estuvieran deshabilitadas, podéis activarlas en:

Versiones del Kernel 2.6 y posteriores: Tendremos que habilitar la opción “Magic SysRq Key” que hay en el menú “Kernel Hacking”.

Versiones del Kernel 2.4 hasta 2.1: Tendremos que habilitar la opción “Magic SysRq Key” que hay en el menú “Kernel Debugging”.

Aquí tenéis la lista de comandos que podemos usar Ctrl + Alt + Pet Sis + X:

• ‘r’ – Cambia el teclado del modo raw al modo XLATE.
• ‘k’ – Mata todos los programas en la consola virtual actual.
• ‘b’ – Reiniciará inmediatamente el sistema sin sincronizar o desmontar sus discos.
• ‘o’ – Apagará su sistema (si está configurado y lo soporta).
• ‘s’ – Intentará sincronizar todos los sistemas de ficheros montados.
• ‘u’ – Intentará montar de nuevo todos los sistemas de archivos montados como solo lectura.
• ‘p’ – Volcará los registros y banderas actuales a su consola.
• ‘t’ – Volcar una lista de las tareas en ejecución y su información a su consola.
• ‘m’ – Volcar la información actual de la memoria a su consola.
• ’0′-’9′ – Establece el nivel de información en consola, controlando los mensajes del núcleo que se mandarán a la consola. (’0′, por ejemplo hará que sólo los mensajes de emergencia como PANIC u OOPS salieran en su consola.)
• ‘e’ – Manda un SIGTERM a todos los procesos, excepto para init.
• ‘i’ – Manda un SIGKILL a todos los procesos, excepto para init.
• ‘l’ – Manda un SIGKILL a todos los procesos, INCLUYENDO init. (Su sistema ya no será operativo tras esto).

Bien, ahora ya sé que son las Magic Keys, pero, ¿con eso como recupero mi sistema?
Es muy sencillo, con una única secuencia, conocida de

(Ctrl) + Alt + Impr Pant + <’ R | E | I | S | U | B ‘>

Recordando la frase “¡¡REInicia SUBnormal!!” (Que es lo que realmente quieres que haga tu PC, como si hablases con él) Vamos usando una a una la primera letra de cada palabra. Así pues, mientras mantenemos pulsadas las teclas (Ctrl) + Alt e Impr Pant , sin soltarlas vamos pulsando las teclas R, E, I, S, U, y B, en secuencia dejando un tiempo entre una y otra (sobre todo después de la ‘S’, ya que el vaciado le los buffers al hdd puede tardar un rato dependiendo del volumen que maneje el PC).

Foto por waferboard

rpm -qa –qf “%-20{NAME} %-10{VERSION} %12{SIZE} %{SUMMARY}\n”

Checkear un paquete concreto:

rpm -q nombrepaquete

Más info:

• http://www.rpm.org/max-rpm/ch-rpm-verify.html
• http://www.linuxask.com/questions/how-to-check-if-a-rpm-package-is-already-installed

Foto por puuikibeach

getconf LONG_BIT

Ésto nos devolverá un escueto “32″ o “64″, que es justo lo que queríamos saber.

Fuente: http://twitter.com/#!/linuxtotal

Primer paso, instalar todos los componentes con yum:

yum install -y httpd php mysql-server mysql php-mysql

Segundo paso, configurarlos para que se ejecuten al inicio:

chkconfig httpd on
chkconfig mysqld on

Y la comprobación de la correcta configuración con:

chkconfig –list

Lo cual nos devolverá, un listado de servicios, entre los cuales, los dos que acabamos de configurar, y que deberían estar en “on” tal y como sigue:

httpd           0:desactivado   1:desactivado   2:activo        3:activo        4:activo        5:activo        6:desactivado
mysqld        0:desactivado   1:desactivado   2:activo        3:activo        4:activo        5:activo        6:desactivado

Tercer paso, iniciar mysql y realizar la configuración inicial.

/etc/init.d/mysqld start
/usr/bin/mysql_secure_installation
Enter current password for root (enter for none):
Set root password? [Y/n] Y
New password:
Re-enter new password:
Remove anonymous users? [Y/n] Y
Disallow root login remotely? [Y/n] Y
Remove test database and access to it? [Y/n] Y
Reload privilege tables now? [Y/n] Y

A partir de aquí, ya será necesario entrar en la configuración del Apache, usuarios de MySQL, iptables si fuera el caso, etc.

Fuente: http://mamiol.blogspot.com.es/2011/09/how-to-install-lamp.html

301 según Google

P: ¿Qué es una redirección 301?
R: “Si necesita cambiar la forma en que aparece la URL de una página en los resultados del motor de búsqueda, le recomendamos que use un redireccionamiento 301 por parte del servidor. Es la mejor forma de asegurarse de que se redirija a la página correcta a todos los usuarios y motores de búsqueda. El código de estado 301 significa que una página se ha trasladado de forma permanente a una nueva ubicación.”

Fuente: http://support.google.com/webmasters/bin/answer.py?hl=es&answer=93633

Ejemplo: Cambio de hosting y de dominio

Si se está migrando una web de un antiguo dominio a un nuevo dominio (es decir, únicamente se está moviendo la web de dominio y de hosting, sin realizar ningún cambio en el código de la web), bastará con crear un fichero .htacess en la raíz del antiguo hosting/dominio con el siguiente código:

Options +FollowSymLinks
RewriteEngine on
RewriteRule (.*) http://nuevodominio.com/$1 [R=301,L]

Ejemplo: Mismo hosting, mismo dominio, diferente web

Si en cambio, no se cambia ni de dominio ni de hosting, y lo único que varia es la estructura interna de la web (si por ejemplo, se crea una nueva web desde cero, totalmente diferente a la original en cuanto a estructura), se deberá hacer una redirección de las antiguas webs (ya no existentes) a sus correspondencias en la nueva web. Por ejemplo, últimamente he trabajado en montar una nueva web para Fucal, una carpintería de aluminio. Su web es www.fucal.net y no hemos cambiado de hosting ni de dominio, símplemente en el servidor, hemos creado dos directorios en la raíz, totalmente independientes uno de otro:

• /fucal: con el código de la antigua web
• /fucal_new: con el nuevo código

El nuevo código, además, no tiene nada que ver con el antiguo, y por lo tanto, los enlaces que anteriormente existían, tienen su correspondencia en la nueva web, pero no mantienen el formato.

Para hacerlo de forma correcta, en el la raíz del antiguo código, se deberá incluir en el .htaccess las redirecciones 301 para indicar qué nuevas páginas corresponden a las antiguas. Así por ejemplo, si se disponía de una página http://www.fucal.net/serveis.html la cual ahora ha pasado a llamarse http://www.fucal.net/productos/, se deberá crear la correspondiente redirección tal y como sigue, en el .htaccess de la raíz del site antiguo (en /fucal):

RewriteRule ^serveis.html$ http://www.fucal.net/productos/ [R=301,L]

Así, nos quedaría un .htacess en la raíz de la antigua web, que indicará las correspondencias entre la antigua y la nueva web:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^renovat.html$ http://www.fucal.net/pla-renovat-2012/ [R=301,L]
RewriteRule ^serveis.html$ http://www.fucal.net/productos/ [R=301,L]
RewriteRule ^presupost.php$ http://www.fucal.net/presupuestos/ [R=301,L]
RewriteRule ^empresa.html$ http://www.fucal.net/quienes-somos/ [R=301,L]
RewriteRule ^cat/$ http://www.fucal.net/ [R=301,L]
RewriteRule ^contactar.html$ http://www.fucal.net/quienes-somos/ [R=301,L]
</IfModule>

NOTA: Esta parte no la he probado (mal por mi parte) pero debería funcionar.

Ejemplo: ¿Y con WordPress?

Si la antigua web fuera un WordPress, éste ya habría generado su propio .htaccess con el siguiente código:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Para añadir las redirecciones, se deberían incluir dentro del código existente, tal y como sigue:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^renovat.html$ http://www.fucal.net/pla-renovat-2012/ [R=301,L]
RewriteRule ^serveis.html$ http://www.fucal.net/productos/ [R=301,L]
RewriteRule ^presupost.php$ http://www.fucal.net/presupuestos/ [R=301,L]
RewriteRule ^empresa.html$ http://www.fucal.net/quienes-somos/ [R=301,L]
RewriteRule ^cat/$ http://www.fucal.net/ [R=301,L]
RewriteRule ^contactar.html$ http://www.fucal.net/quienes-somos/ [R=301,L]
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Ejemplo: Cambio de hosting pero conservando el dominio

Si éste es tu caso, no necesitas una redirección 301, porqué el dominio continua siendo el mismo. Únicamente necesitarás realizar el cambio en las DNS para apuntar al nuevo hosting y listo. A no ser que tengas una base de datos, en cuyo caso, no te podrás permitir estar 24-48h (de propagación del cambio en las DNS) en los cuales tendrás algunas peticiones almacenadas en la base de datos del servidor antiguo y otras en el nuevo, debido a la propagación de DNS.

Para evitar esto, tienes varias alternativas, de entre las cuales propongo 2:

1- Modificar el código del servidor original para usar la base de datos del nuevo servidor, antes empezar con la migración. De esta forma, cuando se haga el cambio DNS no importará el tiempo de propagación porqué todos los datos irán a parar al nuevo servidor.

2- En un servidor Linux, modificar iptables para redirigir todo el tráfico HTTP al nuevo servidor. Aquí las instrucciones.

Finalmente faltaría testear que las redirecciones efectivamente funcionen y ya podremos ir a dormir tranquilos.

Fuente: http://www.webconfs.com/how-to-redirect-a-webpage.php
Foto por Will Weaver

Pull: rsync [OPTION...] [USER@]HOST:SRC… [DEST]
Push: rsync [OPTION...] SRC… [USER@]HOST:DEST

Así pues, si se quiere sincronizar dos directorios, con un servidor remoto, y además de forma automatizada, mediante SSH, podríamos primero copiar la clave pública de una máquina a la otra, para conectar por certificado y evitar así tener que introducir un password para la conexión SSH. Aquí (con autentificación con password) o aquí (sin autentificación con password) el cómo hacerlo.

Una vez contemos con la autentificación por certificados configurada, podremos conectar desde el servidor desde el cual iniciamos el rsync para copiar sincronizar el contenido de una carpeta local, con una carpeta de un servidor remoto (en el ejemplo, se usará como base la carpeta local, con lo que la carpeta remota quedará igual que la local).

rsync -e ssh -avz /folder/src_folder user@80.80.80.100:/another_folder/dest_folder

Con el parámetro anterior, estaremos conectando por ssh contra el servidor 80.80.80.100, logueándonos con “user”, que será el usuario contra el cual habremos copiado el certificado público de la máquina local, para poder conectar por ssh mediante certificados.

Además, con “-avz” se estarán manteniendo los permisos y propietarios de los ficheros copiados, y además con “z” se estarán comprimiendo los archivos durante las transferencias.

ACTUALIZACIÓN:

La opción “-a” en realidad, ejecuta “-rlptgoD”, lo cual significa:

• -r: recursivo
• -l: copia los links simbólicos, como eso, links simbólicos
• -p: conserva los permisos
• -t: conserva los tiempos de modificación
• -g: conserva el grupo
• -o: conserva el propietario
• -D: conserva los ficheros de dispositivo (–devices) así como los ficheros especiales (–specials)

El comando anterior, puede estar mejor si se le añade la opción:

-u / –update: no sincroniza los ficheros que son más recientes en directorio de destino

Finalmente, un parámetro muy interesante es el “-n”:

-n: combinado con el resto de parámetros, únicamente realiza el rsync en modo test, pero no efectúa ningún cambio, con lo que si se combina con la opción “-v” devolverá el resultado que obtendríamos al ejecutar el comando, pero sin realizar ninguna modificación. Si el resultado es el esperado, podremos quitar la opción “-n” y volver a ejecutar, para esta vez sí, obtener los cambios esperados.

qshape -c /etc/postfixA/

Qshape es una utilidad que muestra por pantalla el número de mails distribuidos por edad en las colas, es decir, nos mostrará el tiempo que llevan los mails en las colas, esperando para salir, agrupados por tiempo. Con la opción “-c” se le indicará la ruta al fichero main.cf del postfix del cual queremos ver las colas.

postqueue -p -c /etc/postfixA/

Postqueue, es la utilidad para gestionar las colas de postfix, la cual, requiere indicar igual que qshape, la ruta al main.cf del postfix en cuestión. La opción “-p” lista el contenido de las colas.
Foto por alecperkins

Se partirá de un backup comprimido con “zip” para Linux.

En primer lugar, crearemos un fichero temporal donde descomprimir el backup.

[backup]# mkdir /tmp/restore

Una vez creado, copiaremos el backup al directorio temporal.

[backup]# cp 2012-02-02-backup.gz /tmp/restore/

Nos situaremos en el directorio temporal y descomprimiremos el backup.

[backup]# cd /tmp/restore/
[restore]# unzip 2012-02-02-backup.gz

Tras la descompresión, entraremos en la ruta donde están los ficheros MYI, frm y MYD correspondientes a los ficheros de las tablas de la base de datos, y nos aseguraremos de que tienen el propietario y los permisos correctos.

[database]# chown mysql:mysql *
[database]# chmod 660 *

Finalmente, únicamente quedará parar MySQL, machacar los ficheros de la base de datos con los ficheros correspondientes a la copia de seguridad, e iniciar de nuevo el MySQL.

[database]# /etc/init.d/mysqld stop
[database]# mv -f * /var/lib/mysql/database/
[database]# /etc/init.d/mysqld start

¡Listo!

Foto por magerleagues