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

La configuración de ssh en la máquina a la que queremos conectar, en entornos tipo Red Hat, se encuenta en /etc/ssh/sshd_conf. En este fichero de configuración, podremos realizar varias modificaciones para intentar tener un entorno SSH más seguro, como por ejemplo las que se describen a continuación:

Cambiar el puerto de acceso por defecto

Por defecto SSH usa el puerto 22, cambiando el puerto por otro conseguimos añadir una traba extra para alguien que quiere acceder a nuestro server a través de SSH, puesto que el puerto por defecto no responderá. Se recomienda usar uno mayor al 1024, por estar del 1 al 1024 reservados.

Port 12503

Deshabilitar el acceso a root

El usuario root tiene todos los permisos del sistema, y además es un usuario que existe en todos los sistemas. Una buena práctica sería deshabilitar el acceso al usuario root, y conectárse por ssh únicamente con usuarios propios, que posteriormente (si así lo deseamos) puedan coger privilegios de administrador mediante “sudo”, habiéndose configurado préviamente en /etc/sudoers. De esta manera, prevenimos ataques SSH que intenten conectar con el usuario root, que serían los más usuales.

PermitRootLogin no

Deshabilitar el protocolo 1

Por estar obsoleto y por contar con varias vulnerabilidades conocidas, se recomienda sólo habilitar el protocolo 2, con el que se podrá trabajar sin ningún problema hoy en día.

Protocol 2

Crear una lista de usuarios permitidos

Lista de usuarios del sistema (en /etc/passwd) que tienen permiso para conectar por ssh. Así controlamos mucho mejor el acceso al ssh y evitamos ataques ssh con usuarios conocidos como el usuario apache, nagios, etc. También podemos incluir desde qué equipos se aceptarán las conexiones, incluyendo un @ip tras el username.

AllowUsers paco pepe@80.12.32.132

Deshabilitar la autentificación con contraseña

Este punto es algo más complicado que el resto, puesto que requiere de un trabajo adicional; la creación de claves públicas/privadas para la autentificación. Aquí habría dos posibles maneras de actuar:

1- Crear un par de claves en la máquina desde la que queremos conectar y copiarla al servidor siguiendo los pasos descritos aquí. Esto requiere poder autentificarse mediante contraseña para poder copiar la clave al servidor.

2- Otra opción para realizar lo mismo, se describe aquí, en el punto 7, sin necesidad de usar ssh-copy-id (lo cual requiere autentificación por contraseña).

Una vez comprobado que funciona la autentificación por ssh mediante certificado, se podrá deshabilitar la autentificación por password.

PasswordAuthentication no

Limitar el número de reintentos

Incluir un número máximo de errores al introducir el usuario/password (si está habilitado).

MaxAuthTries 2

Limitar el número de pantallas de login

Limitar el número de conexiones simultáneas a la pantalla de login desde la misma IP, para evitar ataques divididos. Esto no limita el número de sesiones ssh simultáneas, sólo limita el número de pantallas de login abiertas al mismo tiempo.

MaxStartups 3

NOTA IMPORTANTE: Se recomienda iniciar una sesión ssh contra la máquina antes de realizar ningún cambio, y no cerrar dicha sesión ssh. Tras los cambios, se podrá reiniciar el sshd del servidor sin que se cierre la sesión ssh original, por lo que si nos hemos equivocado con algún parámetro, aun podremos deshacer los cambios a través de la sesión ssh original. Para los tests, se recomienda usar nuevas sesiones ssh y nunca cerrar la original.

Configurar iptables correctamente

Finalmente, una buena idea sería configurar correctamente el firewall de Linux, iptables, que nada tiene que ver con el fichero de configuración sshd_config. Con iptables, podríamos por ejemplo únicamente aceptar peticiones al puerto definido para el SSH desde las IPs públicas de confianza que nosotros queramos. Más info sobre cómo hacer esto, aquí.

Fuentes: http://fedorasolved.org/post-install-solutions/securing-ssh

http://www.linuxtotal.com.mx/index.php?cont=info_seyre_004

http://wiki.centos.org/HowTos/Network/SecuringSSH

http://resin.csoft.net/cgi-bin/man.cgi?section=5&topic=sshd_config

 
Foto por @boetter

Después de unos años beneficiándome de hosting y sub-dominio gratuitos de 000webhost.com he pasado a un hosting con 1and1 (después de haberlo abandonado unos años atrás) con un dominio.es. El antiguo blog continúa existiendo, pero con una redirección 301 (movido permanentemente).

El .com y el .net ya estaban ocupados, así que me he tenido que conformar con el “.es”, que tampoco está tan mal.

En cuanto al servidor a monitorizar, he seguido estos pasos:

1. Descargar NSClient++ en el servidor Windows. Aquí la página oficial de NSClient++
2. Ejecutar el instalador y seguir el asistente
   • Durante el instalador, se podrá indicar la IP del servidor Nagios, para únicamente permitir el acceso a NSClient++ desde esa IP.
   • Igualmente, se podrá indicar una contraseña que se deberá configurar en el servidor Nagios, para poder conectar.
   • Si se va a usar check_nt, como es habitual, se deberá marcar durante la instalación, los módulos “common check plugins” y “nsclient server (check_nt)”.
3. Una vez finalizada la instalación, se recomienda marcar el check “start service” para iniciar en ese momento el servicio NSClient++ (se podrá ver desde services.msc). El servicio se guarda con inicio “automático”, así que en teoría no hemos de preocuparnos de él.

Con esto estaría todo listo, en cuanto a la parte de la máquina a monitorizar. En cuanto a la propia configuración del Nagios, por defecto ya viene un fichero windows.cfg que encontraremos en la carpeta de objetos del servidor Nagios, que nos servirá de base para conectar mediante check_nt con nuestro nuevo servidor Windows.

Fuente: http://nagioses.blogspot.com/2009/03/monitoreando-maquinas-con-windows.html

[root@miserver nagios-plugins-1.4.15]# ./configure
checking for a BSD-compatible install… /usr/bin/install -c
checking whether build environment is sane… yes
checking for a thread-safe mkdir -p… /bin/mkdir -p
checking for gawk… gawk
checking whether make sets $(MAKE)… yes
checking build system type… x86_64-unknown-linux-gnu
checking host system type… x86_64-unknown-linux-gnu
checking for gcc… no
checking for cc… no
checking for cl.exe… no
configure: error: no acceptable C compiler found in $PATH
See `config.log’ for more details.
[root@miserver nagios-plugins-1.4.15]#

Este error es de por sí, bastante descriptivo; falta el compilador de C, concretamente, “gcc”. En entornos Red Hat, bastará con usar yum para instalar gcc y solucionar así el problema:

[root@miserver nagios-plugins-1.4.15]# yum install gcc

En mi caso, gcc ha tenido las siguientes dependencias, también instaladas junto con gcc de forma automática:

• cpp
• glibc-devel
• glibc-headers
• kernel-headers

El propósito del post, es ver los paquetes imprescindibles a instalar para solucionar este problema.

Para generar la petición para el certificado, se deberán seguir una serie de pasos:

• Crear el certificado y la petición CSR (Solicitud para Firma del Certificado), ejecutando en el servidor web, el siguiente comando (NOTA: yourdomain puede ser cualquier texto, por ejemplo, para dominio.com podríamos usar dominio.key y dominio.csr respectivamente):

openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr

• Al ejecutarlo, preguntará una serie de detalles para generar el certificado, los cuales deberemos rellenar convenientemente

- Country Name: ES
- State: Barcelona
- Locality Name: Barcelona
- Organization Name: Mi Ornanizacion SL
- Organizational Unit Name:  Dept. Sistemas
- Common Name: dominio.com
- Email Address: mi_mail@mi_otro_dominio.com

Es especialmente importante introducir en el Common Name, el nombre del dominio (o subdominio) al cual asociaremos el certificado (es decir, el dominio que resolverá una petición https).

No hará falta introducir una contraseña para el certificado.

• Al acabar el proceso, se habrán generado tanto el fichero .key como el .csr, ambos necesarios para crear el certificado, directamente en la página del proveedor (como GoDaddy).
• Desde el proveedor, al intentar crear el certificado mediante el CSR, se enviará un mail al contacto administrativo del dominio asociado al certificado (parámetro “Common Name” durante la creación del CSR), que deberá autorizar la creación del certificado.
• Finalmente, el proveedor nos proporcionará dos archivos:

1. bundle.crt (el certificado intermedio)
2. dominio.com.crt (e

• Deberemos incluir estos dos archivos, junto con el archivo con la clave privada (.key) generado al crear la petición CSR, en la carpeta donde guardemos los certificados en el servidor web y configurar el virtual host convenientemente para empezar a usar nuestro nuevo certificado.

Actualización: Así por ejemplo, y tras modificar los permisos para los ficheros del certificado a 600 y root:root, creariamos un vhost donde especificaríamos la ubicación de los ficheros tal y como sigue:

<VirtualHost *:443>
[...]
SSLEngine on
SSLCertificateFile /etc/httpd/crt/dominio.com.crt
SSLCertificateKeyFile /etc/httpd/crt/dominio.com.key
SSLCertificateChainFile /etc/httpd/crt/gd_bundle.crt
[...]
</VirtualHost>

Foto por US Mission Geneva

En primer lugar miraremos qué versión de php tenemos, sin necesidad de usar phpinfo():

[root@miserver ~]# php -v
PHP 5.1.6 (cli) (built: Nov 13 2010 16:05:12)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies

A continuación instalaremos los repositorios de remi siguiendo los pasos descritos aquí:

[root@miserver ~]# wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
[root@miserver ~]# wget http://rpms.famillecollet.com/enterprise/remi-release-5.rpm
[root@miserver ~]# rpm -Uvh remi-release-5*.rpm epel-release-5*.rpm

Una vez instalados, faltará habilitar el repo de remi (que no el “remi_test”) símplemente poniendo a “1″ la línea “enabled”:

[root@miserver ~]# vi /etc/yum.repos.d/remi.repo
…
[remi]
enabled=1

Como curiosidad, podremos ver qué paquetes de php tenemos instalados con el siguiente comando:

[root@miserver ~]# rpm -qa | grep php
php-pdo-5.1.6-27.el5_5.3
php-mysql-5.1.6-27.el5_5.3
php-cli-5.1.6-27.el5_5.3
php-common-5.1.6-27.el5_5.3
php-5.1.6-27.el5_5.3
php-gd-5.1.6-27.el5_5.3

Podremos actualizar todos los paquetes, o bien indicando uno a uno cada uno de los paquetes, o mejor aun, introduciendo únicamente el paquete “padre” (lo cual ya nos actualizará el resto de paquetes):

[root@miserver ~]# yum update php

Es posible que nos encontremos con algún tipo de error como el siguiente:

Transaction Check Error:
file /etc/my.cnf from install of mysql-libs-5.5.19-1.el5.remi.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.x86_64
file /usr/share/mysql/charsets/Index.xml from install of mysql-libs-5.5.19-1.el5.remi.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.x86_64
file /usr/share/mysql/charsets/cp1250.xml from install of mysql-libs-5.5.19-1.el5.remi.x86_64 conflicts with file from package mysql-5.0.77-4.el5_6.6.x86_64
…

En mi caso, esto se ha solucionado eliminando el paquete que crea el conflicto, y posteriormente, actualizando php para a continuación instalar de nuevo el paquete conflictivo (que se instalará ya en la nueva versión):

[root@miserver ~]# yum remove mysql-5.0.77-4.el5_6.6.x86_64
[root@miserver ~]# yum update php
[root@miserver ~]# yum install php-mysql

¡Feliz año!

Fuente: http://www.sohailriaz.com/how-to-update-php-on-servers-centosfedorarhel/

use mydatabase;
show table status;

También me he encontrado con la necesidad de cambiar varias (o todas) las tablas de un motor a otro. Existe la posibilidad de ejecutar la siguiente sentencia para cambiar el motor de una tabla:

ALTER TABLE mytable ENGINE=InnoDB

Sin embargo, si lo que queremos es cambiar todas las tablas de una base de datos, podemos crear un pequeño fichero en php como el siguiente, que se conecte a la base de datos y nos haga el cambio de todas las tablas de forma automática:

<?php
// your connection
mysql_connect(“localhost”,”root”,”123456″);
mysql_select_db(“postaff”);

// convert code
$res = mysql_query(“SHOW TABLES”);
while ($row = mysql_fetch_array($res))
{
foreach ($row as $key => $table)
{
mysql_query(“ALTER TABLE ” . $table . ” ENGINE=InnoDB”);
echo $key . ” =&gt; ” . $table . ” CONVERTED<br />”;
}
}
?>

Foto por 123 Chroma Pixels

En primer lugar, se deberá copiar la configuración actual del replica set a una variable auxiliar:

PRIMARY> cfg = rs.conf()
{
“_id” : “replica1″,
“version” : 6,
“members” : [
{
"_id" : 0,
"host" : "192.0.1.2:27001"
},
{
"_id" : 1,
"host" : "192.0.1.3:27001"
},
{
"_id" : 4,
"host" : "192.0.1.4:38001",
"arbiterOnly" : true
}
]
}

Tal y como se observa en el ejemplo, este comando mostrará por pantalla los parámetros actuales de cada uno de los nodos del réplica set (en el ejemplo, 2 nodos y un árbitro). A partir de la versión 2.0 de mongoDB, se permite cambiar la prioridad de un nodo, pudiendo otorgar un valor entre 0 y 1000 (incluído) en lugar de entre 0 y 1 como hasta ahora.

PRIMARY> cfg.members[0].priority = 10
10

Una vez realizados los cambios en la configuración, se podrán comprobar ejecutando la variable auxiliar.

PRIMARY> cfg
{
“_id” : “replica1″,
“version” : 6,
“members” : [
{
"_id" : 0,
"host" : "192.0.1.2:27001",
"priority" : 10
},
{
"_id" : 1,
"host" : "192.0.1.3:27001"
},
{
"_id" : 4,
"host" : "192.0.1.4:38001",
"arbiterOnly" : true
}
]
}

Una vez comprobados los cambios, se podrán aplicar, ejecutando el siguiente comando (en caso de no estar en un nodo primario, el comando no se ejecutará):

PRIMARY> rs.reconfig(cfg)
{ “ok” : 1 }

Ahora sí, una vez aplicados los cambios, se podrán ver los cambios realizados con

PRIMARY> rs.conf()