SSH clients will automatically be disconnected from the server and prompt the below message after being idle or inactive for a while.

This is due to the SSH servers' configuration (often by default) to avoid hanging sessions and free up resources. These are the related options in the SSH server configuration;

TCPKeepAlive

Whether or not to send TCP “alive” message to the connecting clients to test for connection issues. Defaults to yes.

ClientAliveInterval

A timeout interval to send encrypted alive message to clients if no data has been received from connection. Defaults to 0 (not sending any message).

ClientAliveCountMax

Number of times to send the encrypted alive message before disconnecting clients if no response are received. Defaults to 3.

If you have administrative access to the SSH servers, you can change the options so that you will not easily be disconnected. Edit the SSH server configuration file (normally in /etc/ssh/sshd_config for Unix based operating systems) and set the related options as the followings (uncomment or add if necessary);

TCPKeepAlive no 

ClientAliveInterval 30

ClientAliveCountMax 100

What it basically means is that the server will not send the TCP alive packet to check if the client's connection is working, yet will still send the encrypted alive message every 30 seconds but will only disconnect after 24 hours of inactivity. Be sure to restart the SSH service after the reconfiguration. The following command would work for most Unix based servers;

sudo service sshd restart

If you don't have administrative access to the server, you can configure the SSH client to send the alive message to the server instead. The key here is the ServerAliveInterval option for the SSH client.

You can do this by updating /etc/ssh/ssh_config (applying the setting to every user in the system) or in ~/.ssh/config (single user). Set the following option to have the client send the alive packet every 30 seconds to the server;

ServerAliveInterval 30

Matar el proceso a pelo, no ayuda mucho. Lo recomendable sería tracear el problema para ver el origen del incidente

kill -TERM 17757

kill -STOP 17757

Paso siguiente sería inspeccionar el proceso

ls -al /proc/17757/

cat /proc/17757/cmdline

Para ver cómo ha arrancado el proceso, se puedo probar con la siguiente orden

ls -la /proc/17757/fd

Que te informará si hay ficheros abiertos por el proceso

También puedes examinar lo que está haciendo el proceso, mediante

strace -p 17757

Lo más correcto sería usar la orden usermod. 

usermod --lock --expiredate 1970-01-01 <username>

Bloqueando al mismo tiempo, puedes redirigir la shell 

sudo usermod --lock --shell /bin/nologin username

Otra posibilidad sería bloquear la cuenta con la siguiente orden: 

# chage -E 0 username

Para desbloquear, habría que teclear lo siguiente.

# chage -E 1 username

Es muy frecuente para un desarrollador de páginas web, que cuando se está trabajando con el wordpress, las tareas de configuración se realicen en una subcarpeta. tipo

http://proyecto-web-concreto.com/prueba

Luego cuando finaliza el trabajo, el autor de la web, mueve el contenido del wordpress al directorio raíz. Aquí es cuando vienen los problemas. Generalmente, se dan las siguientes situaciones

1) Que no se abra la página web, que la web está en blanco

2) Que devuelva un error 404

3) El navegador devuelve el famoso: INTERNAL SERVER ERROR

Bueno, vamos a ver si, siguiendo estos pasos, conseguimos arreglar nuestro problema

1) Acceder al panel de administración del Word Press, e ir al menú AJUSTES, aquí hay que quitar las dos primeras URLs 

/prueba

2) Cambiar los enlaces permanentes, para que Wordpress genere un nuevo .htaccess

3) Si no has podido entrar vía panel de administración, la única vía posible sería a través de PHPMYADMIN, a través del panel de gestión de tu hosting. Tienes que ir a WP_options, y allí podrás editar la tabla para borrar la URL de prueba.

4) Si has llegado hasta aquí, y tu página sigue sin abrirse, mira a ver si en tu directorio raíz hay un fichero llamado PHP.INI. Bórralo, o muévelo a otro sitio, o renómbralo a php.ini.bak. Refresca el navegador 

Lo más importante es revisar las siguientes líneas de configuración

# SASL SUPPORT FOR CLIENTS

# The following options set parameters needed by Postfix to enable 

# Cyrus-SASL support for authentication of mail clients. 

# 

smtpd_sasl_auth_enable = yes

smtpd_sasl_security_options = noanonymous

smtpd_sasl_local_domain = $myhostname

broken_sasl_auth_clients = yes

... 

smtpd_recipient_restrictions = 

   permit_sasl_authenticated, 

   permit_mynetworks, 

   check_relay_domains

About Spamassassin

Spamassassin is a free and open-source mail filter written in Perl that is used to identify spam using a wide range of heuristic tests on mail headers and body text. It will save your mailbox from much unwanted spam emails.

1. Prerequisites

Before installing Spamassassin, you need to install and setup a mail transfer agent such as Postfix on your virtual private server.

You can find instructions on that here

2. Install Spamassassin

Use apt-get to install Spamassassin and spamc.

apt-get install spamassassin spamc

Once Spamassassin is installed, there are a few steps that has to be taken to make it fully functional.

3. Adding Spamassassin User

To run Spamassassin you need to create a new user on your VPS.

4. First add the group spams:

groupadd spamd

then add the user spamd with the home directory /var/log/spamassassin:

useradd -g spamd -s /bin/false -d /var/log/spamassassin spamd

then create the directory /var/log/spamassassin:

mkdir /var/log/spamassassin

and change the ownership of the directory to spams:

chown spamd:spamd /var/log/spamassassin

Let's set up Spamassassin now.

5. Setting Up Spamassassin

Open the spamassassin config file using:

nano /etc/default/spamassassin

To enable Spamassassin find the line

ENABLED=0

and change it to

ENABLED=1

6. To enable automatic rule updates in order to get the latest spam filtering rules find the line

CRON=0

and change it to

CRON=1

Now create a variable named SAHOME with the Spamassassin home directory:

SAHOME="/var/log/spamassassin/"

Find and change the OPTIONS variable to

OPTIONS="--create-prefs --max-children 2 --username spamd -H ${SAHOME} -s ${SAHOME}spamd.log"

This specifies the username Spamassassin will run under as spamd, as well as add the home directory, create the log file, and limit the child processes that Spamassassin can run.

7. If you have a busy server, feel free to increase the max-children value.

Start the Spamassassin daemon by using the following code:

service spamassassin start

Now, let's config Postfix.

Configuring Postfix

The emails still do not go through Spamassasin. To do that, open Postfix config file using:

nano /etc/postfix/master.cf

Find the the line

smtp      inet  n       -       -       -       -       smtpd

and add the following

-o content_filter=spamassassin

Now, Postfix will pipe the mail through Spamassassin.

To setup after-queue content filter add the following line to the end of the file

spamassassin unix -     n       n       -       -       pipe

        user=spamd argv=/usr/bin/spamc -f -e  

        /usr/sbin/sendmail -oi -f ${sender} ${recipient}

For the changes to take effect restart postfix:

service postfix restart

Now postfix will use spamassassin as a spam filter.

Configuring Spamassassin on your VPS

To get the maximum use of Spamassassin you have to create rules.

Open the Spamassassin default rules file using:

nano /etc/spamassassin/local.cf

To activate a rules uncomment line remove the # symbol.

To add a spam header to spam mail uncomment or add the line:

rewrite_header Subject [***** SPAM _SCORE_ *****]

Spamassassin gives a score to each mail after running different tests on it. The following line will mark the mail as spam if the score is more than the value specified in the rule.

required_score           3.0

To use bayes theorem to check mails, uncomment or add the line:

use_bayes               1

To enable bayes auto learning, uncomment or add the line:

bayes_auto_learn        1

After adding the above details, save the file and restart spam assassin.

service spamassassin restart

Testing

To see if Spamassassin is working, you can check the spamassassin log file using:

nano /var/log/spamassassin/spamd.log

or send the email from an external server and check the mail headers.

En Centos, hay que seguir los siguientes pasos para instalar SPAMASSASSIN

## screen -U -S spamc-screen

## yum update

## yum install spamassassin

## groupadd spamfilter

## useradd -g spamfilter -s /bin/false -d /usr/local/spamassassin spamfilter

## chown spamfilter: /usr/local/spamassassin

Ahora toca configurar SPAMASSASSIN

## vim /etc/mail/spamassassin/local.cf

## Required_hits: This determines the filter balance; the lower the score the more aggressive the filter.
# A setting of 5.0 is generally effective for a small organisation or a single user.
# Adjust the strictness score to your organization's needs - a large medical organisation might want  to let email items
# through that are trying to sell pharmaceuticals, so we might increase the level to a more modest 8.0.
required_hits 5
## Report_safe:  This line determines whether to delete the item or to move the item to the inbox whilst appending
# a spam notice to the subject line. The levels for this line are set to either a 1 or 0. A score of 1 will delete the spam item,
# whereas a score of 0 will send the item to the inbox and rewrite the subject line.
report_safe 0
rewrite_header Subject [**SPAM**]
## Required_score: This line sets the spam score for all email allowed through to your domain, with levels of certainty set from 0 to 5.
# Zero would be classified as a legitimate email item, whereas 5 would be an definite 'SPAM' item.  If we set the score to 3 we would catch a
# lot of unsolicited emails but quite a few false positives would still get through. For our example email server we will use the score of 5,
# but you can of course set this value according to your preference.
required_score 5.0

## vim /etc/sysconfig/spamassassin

Agregar lo siguiente

SAHOME="/usr/local/spamassassin"
SPID_DIR="/var/run/spamassassin"
SUSER="spamfilter"
SPAMDOPTIONS="-d -c -m5 --username ${SUSER} -H ${SAHOME} -s ${SAHOME}/spamfilter.log"

## service spamassassin start

## chkconfig spamassassin on

AHORA HAY QUE CONFIGURAR POSTFIX

## vim /etc/postfix/master.cf

Agregar las siguientes líneas en el fichero.

smtp      inet  n       -       n       -       -       smtpd -o content_filter=spamassassin
spamassassin unix -     n       n       -       -       pipe user=spamfilter argv=/usr/bin/spamc -f -e  /usr/sbin/sendmail -oi -f ${sender} ${recipient}

Y luego reiniciar postfix

## service postfix restart

Por defecto, el puerto de escucha de Postfiex es el 25. Si quieres, lo puedes cambiar a cualquier otro puerto que quieras, siempre que no esté en uso. 

Para cambiar el puerto, hay que seguir los siguientes pasos:

1) Editar el fichero master.cf

vi /etc/postfix/master.cf

smtp inet n – n – – smtpd

2) Cambiar la palabra smtp por el puerto deseado

9267 inet n – n – – smtpd

3) Reiniciar postfix

/etc/init.d/postfix restart

En algunas ocasiones, generalmente al cambiar una tienda online para mejorar el SEO de Prestashop a otro hosting, podemos encontrarnos con un error que nos impedirá visualizar nuestra tienda online, al intentar cargarla veremos un mensaje similar a este:

Fatal error: Call to undefined function mcrypt_encrypt() in /var/www/vhosts/dominio.com/public_html/classes/Rijndael.php on line 50

El fallo se debe básicamente a que la extensión mcrypt de PHP no está instalada en ese servidor, así que la opción más rápida de solucionar este problema es deshabilitando esta funcionalidad en la configuración de tu Prestashop, para conseguirlo tienes que ejecutar una sentencia en tu base de datos MySQL:

UPDATE ps_configuration SET VALUE=0 WHERE name="PS_CIPHER_ALGORITHM"

Lo primero de todo, hay que detectar de donde viene ese error, la mayoría de veces cuando ves esta pantalla te bloqueas y no entiendes porque ocurre esto.

En Prestashop 1.5.4 puede pasarte a menudo, o darte otros errores, pero la mayoría de veces nos pasara, sobre todo cuando migramos la página web de un hosting a otro

Pasos para Reconocer el Error 500 en Prestashop
Hay diferentes formas de que te encuentre con este error son estas:

“500 Internal Server Error”

“HTTP 500 – Error interno del servidor”

“Error interno del servidor”

“HTTP 500 Error interno”

“Error 500”

“HTTP Error 500”

Una frase que acompaña este este error es esta: “El servidor encontró una condición inesperada que le impidió cumplir con la solicitud del cliente”.

La mayoría de veces el error 500 es un mensaje del servidor que nos dice que “Algo salió mal y yo no sé qué es” esto se suele llamar “Server-side” Eso quiere decir que algo salió mal con el servidor que aloja el sitio web. La mayoría de errores suele ser por problemas de configuración del hosting o incluso de tu Prestashop.

Primer paso para Solucionar Error 500 en Prestashop
Activar el informe de errores en Prestashop para esto haz lo siguiente:

Para PrestaShop v1.4 hasta v1.5.2

1. Abre config / config.inc.php

2. En línea 28 se encuentra esta línea @ ini_set (‘display_errors’, ‘off’);

3. Cambie la línea para que @ ini_set (‘display_errors’, ‘on’);

Para PrestaShop v1.5.3 +

1. Abre config / defines.inc.php

2. En la línea 28 se encuentra esta línea define (‘_PS_MODE_DEV_’, false);

3. Cambie esta línea para leer define (‘_PS_MODE_DEV_’, true);

Bien ahora quizás ya no veamos la pantalla de error 500 pero si podremos ver algún mensaje que nos de la consola de errores.