vi /etc/postfix/main.cf

AÑADIMOS AL SERVIDOR RELAY EN LA VARIABLE RELAYHOST:

relayhost = example.okitup.net:2525

/etc/init.d/postfix reload

vi /etc/postfix/master.cf

DUPLICAMOS PRIMERA LINEA CON EL PUERTO ANTERIOR PUESTO PARA EL RELAY:
2525      inet  n       -       -       -       -       smtpd

vi /etc/postfix/main.cf

AÑADIMOS EN MAIN VARIABLE MYNETWORKS LA IP DEL SERVIDOR ORIGEN:
mynetworks = 127.0.0.0/8 [::1]/128 XXX.XXX.XXX.XXX

ABRIMOS PUERTO EN EL FIREWALL SI APLICA
/etc/init.d/postfix reload

Telnet – Probar si puerto 25 destino esta abierto

apt-get install telnet
telnet example.okitup.net 25

Prueba de envío mail desde consola

apt-get install heirloom-mailx

mail -s "Asunto PRUEBA" info@example.com
ESCRIBIR TEXTO + ENTER + . + ENTER

Binlog: sistema de mysql para guardar updates, deletes, creates, etc y poder reproducir las  queries desde el backup hasta el último momento…. o incluso para una única db, o para un tramo de tiempo concreto, etc

vi /etc/mysql/my.cnf

descomentar el parámetro:

log_bin = /var/log/mysql/mysql-bin

Otros valores a tener en cuenta:

max_binlog_size = 100M
#binlog_do_db = include_database_name
binlog_ignore_db = phpmyadmin

En los logs veremos que se crea el fichero bin y los demás secuencialmente:

ls -latr /var/log/mysql/mysql-bin.*
-rw-rw—- 1 mysql adm 10486 Jul 7 06:25 /var/log/mysql/mysql-bin.000001
-rw-rw—- 1 mysql adm 64 Jul 7 06:25 /var/log/mysql/mysql-bin.index
-rw-rw—- 1 mysql adm 2505782 Jul 7 08:30 /var/log/mysql/mysql-bin.000002

Mysqlbinlog: Comando para extraer los datos.

Ejemplo de salida filtrada para una sola bbdd y para un tramo de tiempo concreto, concatenando múltiples fichero mysql-bin.*

mysqlbinlog mysql-bin.000001 mysql-bin.000002 mysql-bin.000003 –database=db_name –start-datetime=”2016-07-07 00:12:00″ –stop-datetime=”2016-07-07 10:35:00″

La misma salida, si la vemos ok, la cargamos por mysql:

mysqlbinlog mysql-bin.000001 mysql-bin.000002 mysql-bin.000003 –database=db_name –start-datetime=”2016-07-07 00:12:00″ –stop-datetime=”2016-07-07 10:35:00″ | mysql -u root -p

NOTA: POSIBLEMENTE SE TENGA QUE PARAR APACHE PARA ASEGURAR QUE NADIE CAMBIA NADA, SINO PUEDE LLEGAR A HABER DUPLICATE ENTRY

Para evitar los conocidos ataques masivos a los wp-login.php de wordpress, es una buena práctica proteger el acceso a dicho fichero.

Simplemente añadiendo al .htaccess:

# Protect wp-login
<Files wp-login.php>
AuthUserFile /var/www/example.com/web/.wp-htpasswd
AuthName "Private access"
AuthType Basic
require valid-user
</Files>

Puedes generar el fichero .wp-htpasswd utilizando webs como:

http://www.htaccesstools.com/htpasswd-generator/

Es mejor no proteger la carpeta wp-admin, ya que hay procesos ajax que necesitan acceder a su interior para el uso normal de la web.

Hasta pronto!!

Ejecutando el php con fcgi nos podemos encontrar el siguiente error que puede ser causado por varios motivos. De hecho es un error similar al típico “Segmentation Fault” cuando ejecutamos php con mod_php, es decir, obtenemos un fallo pero sin saber concretamente que extensión de php da problemas, que parámetro necesita ser ajustado, etc

En el caso de “Connection reset by peer : mod_fcgid: error reading data from FastCGI server” ya nos hemos encontrado varias veces dos motivos recurrentes:

• El módulo xcache da problemas y tenemos que desinstalarlo y por ejemplo sustituirlo por apc. El ejemplo más reciente en un Laravel con el optimizer de composer Artisan (fichero afectado compiled.php).

Solución:

apt-get remove –purge –auto-remove php5-xcache

apt-get install apc

• Los valores de timeout de fast-cgi (fcgi) tenemos que aumentarlos.

Solución:

<IfModule mod_fcgid.c>
IdleTimeout 3600
ProcessLifeTime 7200
IPCConnectTimeout 8
IPCCommTimeout 1200
BusyTimeout 300
DefaultMinClassProcessCount 0
DefaultMaxClassProcessCount 100
</IfModule>

Hasta pronto!!!

El siguiente comando sólo borra/purga/limpia/vacía la cache de una url o host una vez.

Al ejecutarlo veremos en varnishstat que las peticiones no hacen hit la primera vez y que luego ya entra en cache de nuevo.

varnishadm -S /etc/varnish/secret -T 127.0.0.1:6088 “ban req.http.host ~ www.okitup.com”

Con ban.list podemos ver el registro de las últimas urls o hosts a los que se han limpiado cache:

varnishadm -S /etc/varnish/secret -T 127.0.0.1:6088 “ban.list”

Importante poner el /etc/varnish/secret y el puerto por donde escucha el varnish en cuestión.

Ojo, el nombre de “ban” para limpiar cache la verdad que no es un nombre muy acertado, habitualmente estamos más acostumbrados a purge o comandos parecidos. Esto no quiere decir que “ban” banee nada o bloquee nada, realmente vacía la cache 🙂

Hasta pronto!