Restauración copias de seguridad R1Soft (servidores dedicados)

En esta entrada vamos a explicar de forma resumida los pasos necesarios para poder restaurar archivos y bases de datos haciendo uso del sistema de copias de seguridad R1Soft para servidores dedicados.

El usuario que tenga contratado este servicio, va a disponer por defecto de copias de seguridad de todo su servidor con copias horarias (12), diarias (7), semanales (4) y mensuales (2); podrían reducirse teniendo en cuenta el límite de espacio contratado para las mismas.

Estas copias, además de salvaguardar el contenido del servidor contra potenciales fallos de hardware, lógicos o de agentes externos, servirán para poder restaurar contenido específico en cualquier momento, como por ejemplo el contenido de una web, de correo o de bases de datos.

A continuación indicamos los pasos para poder restaurar una copia (pulsa sobre las imágenes para ampliarlas):

1.- Accedemos al panel de R1Soft, y para ello existen dos vías:

  • Con url, usuario y contraseña facilitados por nosotros.
  • A través del área de cliente en el apartado Servicios > Mis servicios > Gestionar producto > Log in to control panel

2.- Una vez dentro del panel nos dirigimos a Servidores

3.- Visualizaremos los servidores que tenemos añadidos al sistema. Por lo general solamente será uno, pero si tienes máquinas virtuales te aparecerán todas ellas para poder acceder a la que necesites. En el desplegable Acciones seleccionaremos Abrir Puntos de Recuperación.

4.- En esta pantalla nos encontraremos con todas las copias que hay generadas en ese momento, con su fecha, hora y disponibilidad. En el desplegable Acciones seleccionaremos Examinar.

5.- La pantalla que vemos a continuación corresponde al sistema de archivos de la raíz del servidor. Lo normal es que queramos restaurar los archivos de una página web completa o archivos concretos, en ese caso y teniendo en cuenta que trabajamos con el panel de control Plesk la ubicación que habrá que seguir desde esta raíz para acceder a los dominios es la siguiente: /var/www/vhosts/dominio.xy/httpdocs/

NOTA: httpdocs corresponde a la raíz por defecto de un dominio creado como principal o suscripción, los dominios adicionales o subdominios pueden tener otra ubicación distinta que es visible en Plesk.

La ubicación de las cuentas de correo se encuentran en /var/qmail/mailnames/dominio.xy/cuenta/Maildir/

Como puede verse en la parte superior y a la derecha de la anterior imagen, este sistema permite además de la restauración el volcado de una copia de los archivos o directorios que seleccionemos. Nos dará la opción de comprimirla para hacerla más accesible.

6.- Si queremos restaurar una web completa, archivos sueltos o cuenta de correo, una vez hayamos llegado a la ubicación deseada, marcaríamos todos los archivos y pulsaríamos en Restaurar Seleccionados, nos abrirá una ventana con las opciones de restauración.

Habrá que dejar todo por defecto y tener en cuenta que es posible restaurar directamente el contenido sobre el directorio original (que corresponde a restaurar una copia de seguridad) o en un directorio alternativo, que puede servirnos como un volcado sin restaurar.

La opción Sobreescribir Archivos Existentes es importante si queremos que la restauración sea incremental, es decir, si queremos que se restauren todos los archivos modificados o no existentes entre el original y la copia. Si no lo marcamos, los archivos que existan no serán sobreescritos a pesar de que tengamos ahí el problema por el que necesitamos restaurar.

Por ejemplo, si tengo el archivo index.php con un error de sintáxis y quiero restaurarlo para solucionarlo, debo marcar Sobreescribir Archivos Existentes, porque si no lo hago el sistema ve que el archivo ya existe y no lo restaura, a pesar de que tengan distinta fecha, distinto tamaño y/o distinto contenido.

Para restaurar una cuenta de correo, lo más normal sería NO marcar esta opción.

7.- Al pulsar sobre Restaurar nos aparecerá la barra de progreso, el tiempo estimado y otras informaciones.

Si todo va correctamente la barra se completará y nos avisará que los archivos se han restaurado con éxito.

Con esto finalizamos con la restauración de los archivos.

Para las bases de datos hay que seguir los tres primeros pasos anteriores y en el cuarto seleccionar Examinar Bases de Datos en el desplegable.

Nos aparecerán todas las bases de datos creadas en el servidor y nos dará la posibilidad de seleccionar las que queramos para restaurarlas.

Al igual que en los archivos, nos aparecerá una ventana con las opciones de restauración. Si solamente queremos restaurar, pulsaremos directamente en Restaurar, pero también da la opción de restaurar la base de datos en otra alternativa que hayamos creado previamente en Plesk, restaurar remotamente a otro servidor, etc.

Para esta ocasión también dispondremos de una barra de progreso que informará de que todo hay ido bien o que se ha detectado cualquier problema.

Esperamos que esta guía os sirva de gran ayuda para disponer en todo momento de las copias de vuestro contenido y de la posibilidad de llevar a cabo las restauraciones al momento sin esperas.

Solución a registros de usuarios falsos en Prestashop

Desde hace unos días muchos de los usuarios de tiendas Prestashop han comprobado como decenas de nuevos usuarios se registraban en sus tiendas con emails falsos y con enlaces hacia webs maliciosas. Este tipo de hackeo en un primer momento se puede detectar si el usuario recibe muchos emails rebotados que él no ha enviado, esto es así porque al ser cuentas falsas cuando Prestashop envía el mensaje de bienvenida o alta, no puede ser entregado y el servidor de destino lo rechaza con un mensaje de vuelta.

El método usado para este registro de usuarios falsos consiste en lanzar peticiones tipo POST hacia la url de registro y en esas peticiones añaden los valores para todos los campos. Esto se efectúa desde servidores hackeados fuera de España, usando varias IPs para no ser detectados y para que sea más complejo poder bloquearlo. Por nuestra parte hemos estado bloqueando todas las IPs que hemos podido comprobar que lo hacían, pero esto es solamente una solución temporal, ya que usan cada vez una distinta.

Algunos desarrolladores y en los foros de Prestashop se indica que una posible solución pasa por instalar un captcha (a nivel de PHP) en el formulario de registro.

En una entrada del foro oficial el usuario doekia ofrece también una solución alternativa relativamente sencilla que modifica los archivos classes/Validate.php y classes/Customer.php para evitar que puedan añadirse caracteres en campos que no deben incluirlos (como por ejemplo el campo de Apellidos). La url de este post es la siguiente y es compatible con Prestashop 1.5, 1.6 y 1.7:

https://www.prestashop.com/forums/topic/981159-securite-spam-customer-account-solution-13-17/

Dentro de esta misma solución, el usuario que lo ha propuesto nos facilita un enlace con todo el código que automatiza la modificación de esos archivos para no tener que hacerlo a mano. Hay que guardar un archivo con ese código para subirlo por FTP o el gestor de archivos de Plesk al directorio de administración de Prestashop y posteriormente cargar la url en un navegador:

1.- Vamos al enlace https://area51.enter-solutions.com/snippets/122

2.- Pinchamos sobre «raw» y  se abre una nueva ventana en el navegador con todo el código.

3.- Con el botón secundario del ratón le damos a «Guardar como…» y le ponemos como nombre al archivo el mismo sugerido por ese desarrollador: patch122.php

4.- Conectamos por FTP o entramos en el panel de control Plesk, y subimos el archivo dentro del directorio de administración de Prestashop.

5.- Cargamos en el navegador la url. Tiene que tener esta estructura como ejemplo: https://mitiendapresta.es/admin123/patch122.php

6.- Aparecerá en el navegador un aviso como que se ha completado el cambio: «class Validate is now overrided class Customer is now overrided END»

Seguramente los desarrolladores de Prestashop tomarán buena nota de esta incidencia para aportar una solución definitiva en la siguiente actualización de este popular e-commerce, pero mientras tanto son los desarrolladores/programadores o usuarios de las webs quien deben parchearlo.

Nota importante: Esta solución ha sido obtenida directamente desde el foro oficial de Prestashop y Loading no se hace responsable en ningún caso del mal uso o problemas derivados tras los cambios que ahí se sugieren. Siempre se recomienda generar una copia completa de seguridad del sitio antes de hacer modificaciones, o comprobar las copias de seguridad de las que se disponen en el hosting para poder restaurar en caso de incidencias.

Nuevos planes de correo

Recientemente hemos lanzado un nuevo producto que amplía nuestro catálogo, completando así una oferta más amplia y ajustándonos a todo tipo de necesidades.

Se trata de unos nuevos planes de correo* que serán un complemento perfecto para clientes que requieran de mucho espacio para sus cuentas de email, como por ejemplo empresas con muchos empleados o para clientes con actividades donde se maneje mucha información a través del correo.

Como requisito indispensable, estos planes requieren de un hosting web (Mini – Platinum) contratado y el espacio adicional solamente podrá ser usado para el correo.

Para clientes actuales, el servicio puede adquirirse a través del área de cliente de Loading en el apartado Complementos y requiere de una migración a uno de los servidores configurados para estos productos. Para nuevos clientes, en el propio proceso del pedido desde nuestra web le ofrecerá la opción de añadirlo y el servicio se creará en el servidor correspondiente de forma automática.

Aunque este producto se contrate como un añadido al plan de hosting, no habría distintos paneles o configuraciones y todo se administraría de forma normal a través del panel de control Plesk.

La oferta de planes es la siguiente**, puedes pulsar en la imagen para ampliarla:

 

 

A diferencia de otros proveedores en los que se limita el espacio máximo de cada cuenta de email o el número de cuentas, nuestros planes de correo no tienen este límite. La distribución del espacio contratado se puede realizar como el usuario desee entre todas sus cuentas.

Siempre tendremos asegurada la entrega de mensajes en todos los proveedores porque usaremos IPs de envío españolas con buena reputación y monitorizadas en todo momento.

 

Puedes seguir todas nuestras ofertas y novedades en nuestra web loading.es, Facebook y Twitter.

 

* Ampliación solamente disponible para hostings compartidos, no disponible todavía para Resellers, VPS ni dedicados.
** Precios mensuales e IVA no incluido.

Mi tienda Prestashop carga lenta de un día para otro sin haber hecho cambios

En muchas ocasiones algunos clientes nos han reportado problemas de lentitud en sus tiendas Prestashop de un día para otro sin haber hecho cambios. Hay que tener en cuenta que la mayoría de módulos y plantillas realizan conexiones a la web oficial del desarrollador para validar licencias, comprobar actualizaciones, etc.

Esas conexiones se realizan en todo momento, incluido el front-end, por lo que esas conexiones se realizan cuando nuestros usuarios o clientes están visitando nuestro sitio web. Por lo tanto, si la web de alguno de los desarrolladores de nuestros módulos o plantillas tiene alguna incidencia, el rendimiento de nuestro sitio web se verá afectado considerablemente.

Si el tiempo de respuesta de nuestro sitio web es 0.5 segundos, pero la conexión a la web del desarrollador se demora 5 segundos, nuestro sitio tardará 5.5 segundos en responder. Hasta que nuestra tienda no haya completado todas las conexiones externas definidas en los módulos, nuestra página web no mostrará nada y se quedará cargando.

En el siguiente ejemplo, un cliente nos reporta problemas de lentitud en su sitio web, y efectivamente la página no ha sido modificada desde hace semanas. Analizando los procesos identificamos esta conexión:

php-fpm xxxxx xxxxxx 6u IPv6 2206060903 0t0 TCP linxxx.loading.es:58876->[2606:4700:30::xxxx:xxxx]:http (SYN_SENT)

El proceso php-fpm permanece bloqueado durante cerca de 60 segundos realizando esa conexión ya que el servidor de destino (2606:4700:30::xxxx:xxxx) no responde correctamente, por lo que la carga del sitio web se demora más de 60 segundos. Analizando la plantilla y módulos usados, conseguimos identificar a que módulo hace referencia esa dirección IP:

/modules/pk_themesettings/

Después de revisar el código fuente del módulo, detectamos que el problema es de la plantilla/módulo, buscando actualizaciones:

/modules/pk_themesettings/inc/confighelper.php

public function checkupdates() {
    $update_list = "http://promokit.eu/share/updates/"._THEME_NAME_."/5/update_list.dat";
    $msg = "";
    if (!$update = @file_get_contents($update_list)) {
        $msg = false;
    } else {
        $versions = explode(",", $update);
        $i = 1;
        foreach ($versions as $key => $version) {
            if (Configuration::get('ALYSUM_VER') < $version) {
                $msg .= (($i == 1) ? "" : ",").$version;
                $i++;
            }
        }
    }

    return $msg;
}

Por lo que comentamos las lineas que realizan la conexión a la web oficial del desarrollador, quedando así:

public function checkupdates() {
    /*
    $update_list = "http://promokit.eu/share/updates/"._THEME_NAME_."/5/update_list.dat";
    $msg = "";
    if (!$update = @file_get_contents($update_list)) {
        $msg = false;
    } else {
        $versions = explode(",", $update);
        $i = 1;
        foreach ($versions as $key => $version) {
            if (Configuration::get('ALYSUM_VER') < $version) {
                $msg .= (($i == 1) ? "" : ",").$version;
                $i++;
            }
        }
    }

    return $msg;
    */
}

De este modo la página web del cliente no volverá a generar problemas de lentitud buscando actualizaciones de la plantilla. No obstante, puede que tenga otros módulos o plantillas que sigan realizando conexiones de este tipo.

Normalmente cuando la web del desarrollador funcione correctamente no detectaremos ningún problema, aunque hay que tener en cuenta la importancia de usar los módulos 100% necesarios e imprescindibles. Cada conexión cuenta, si por ejemplo tenemos 10 módulos que buscan actualizaciones, y cada conexión se demora 0.10 segundos, estamos generando 1 segundo (10 x 0.10) de carga adicional a nuestro sitio web.

Al hacer un uso abusivo de módulos, tenemos mayor probabilidad de sufrir estos problemas. Aunque los módulos no estén activos, el hecho de estar instalados ya ocasiona que Prestashop tenga que leer su código fuente y realizar las conexiones correspondientes. Por lo que es recomendable eliminar los módulos que estén en desuso y hacer un uso moderado de ellos.

Visto esto, dependemos al 100% de la web de los desarrolladores de nuestros módulos y plantillas.

Versión de PHP 7.3 disponible

Estimados usuarios, os informamos que ya está disponible la nueva versión de PHP 7.3 seleccionable desde el panel de control Plesk.

Esta actualización cambia algunas de las funcionalidades internas del lenguaje que podrán ser aprovechadas por los desarrolladores o programadores que trabajen directamente con el código de la web.

Las características completas de esta nueva versión pueden consultarse en > http://php.net/releases/7_3_0.php

En este enlace aparecen todos los cambios que van de la versión de PHP 7.2 a esta nueva 7.3 > http://php.net/manual/es/migration73.php

Como se indica en el enlace anterior, la mayoría de las mejoras no variarían el funcionamiento en el código ya programado y que ya se encuentre funcionando sobre una versión troncal de PHP 7.X, pero habría que revisar los cambios en esta versión con respecto a las anteriores para evitar que se produjeran incompatibilidades.

La configuración del servidor continúa como el usuario la tuviera configurada originalmente, no se ha variado nada en ella y esta nueva característica es una opción que el programador o administrador de la web puede seleccionar y usar para optimizar/generar el código de la página.

Puedes seguir todas nuestras ofertas y novedades en nuestra web loading.es, Facebook y Twitter.

Crear una tarea programada para Prestashop desde Plesk

En esta ocasión vamos a explicar como crear una tarea programada dentro de Plesk. Como ejemplo vamos a usar el comando o URL que nos facilita Prestashop para regenerar el indice de productos del buscador.

 

1. Primero necesitamos la URL o comando para automatizar su ejecución, accedemos al back office de nuestro Prestashop, «Parámetros de la tienda», «Búsqueda«.

 

 

2. Entramos al panel de control Plesk y pinchamos en «Tareas programadas«.

 

 

3. Hacemos click en «Añadir tarea«.

 

 

4. En «Tipo de tarea» seleccionamos la opción «Obtener una URL«, y en el campo de «URL» la que copiamos en el primer paso del back office de Prestashop. Terminamos eligiendo la periodicidad deseada, en nuestro caso diaria (Diariamente) a las 04 de la madrugada.

 

 

Existen otras opciones más complejas de ejecución o periodicidad que sería «Estilo cron», añadimos algunos ejemplos.

Cada 5 minutos:

*/5 * * * *

Cada 2 horas, el minuto 1:

1 */2 * * *

Los minutos 10, 20 y 30 de cada hora:

10,20,30 * * * *

 

Algunos de nuestros planes de hosting no incluyen el servicio de tareas programadas. Se pueden contratar adicionalmente, o ampliar a un plan superior que si las incluya.

Incrementar tiempo máximo de ejecución en Plesk con Nginx y Apache

En las últimas versiones de Plesk se han implementado distintas funcionalidades que ofrecen mayor rendimiento, pero complican bastante incrementar el tiempo máximo de ejecución del dominio/servidor, en esta entrada explicamos los pasos a seguir.

 

1. En la gestión del dominio dentro de Plesk tenemos dos apartados en los que tenemos que realizar cambios, «Configuración de PHP» y «Configuración de Apache y nginx».

 

 

2. Entramos en «Configuración de PHP» y cambiamos el valor del campo «max_execution_time» y «max_input_time» como vemos en la imagen inferior por el valor deseado (en este caso 600 segundos / 10 minutos) y hacemos click en «Aceptar».

 

 

3. Ahora dentro de «Configuración de Apache y nginx», en  el campo de «Directivas adicionales para HTTP» y «Directivas adicionales para HTTPS» añadimos:

 

<IfModule mod_proxy_fcgi.c>
ProxyTimeout 600
</IfModule>

 

Y en campo de «Directivas adicionales de nginx» añadimos:

 

proxy_connect_timeout 600;
proxy_send_timeout 600;
send_timeout 600;

 

 

Por nuestra parte, no recomendamos mantener estos valores muy elevados de forma definitiva salvo que sea 100% necesario. Hacerlo supone que los procesos o visitas bloqueadas no «mueran» hasta llegado el tiempo máximo de ejecución. Si el valor es muy elevado, y se acumulan muchos procesos bloqueados, puede incrementar la carga del servidor, consumo de recursos, generar lentitud y caídas del servicio. Es mejor tener quedarse cortos e incrementarlo de forma progresiva, que poner un valor muy elevado de primeras.

 

IMPORTANTE: Dentro de Loading, esta opción solo es válida para servidores VPS y dedicados. En hosting compartido este cambio lo realizamos mediante ticket de soporte.

Plesk Mobile

Se ha incorporado en los planes de hosting compartido (Mini – Platinum y Resellers) la posibilidad de acceso al panel de control a través de la aplicación Plesk Mobile, disponible para descargar de forma gratuita en  Google Play y App Store, para dispositivos Android e iOS respectivamente.

Si se tienen contratados varios planes de hosting sobre distintos servidores, todos ellos pueden vincularse a la aplicación, pudiendo seleccionarlos individualmente para acceder a su administración. La cuenta vinculada, incluiría la posibilidad de modificación de la contraseña de acceso al propio Plesk, por si se necesita modificar en cualquier momento.

A continuación vamos a ofreceros información útil de cómo poder vincular tu cuenta/hosting en la aplicación, pulsa en las imágenes para ampliarlas:

 

HOSTINGS COMPARTIDOS

1.- El primer paso tras descargar la aplicación, instalarla en el dispositivo y abrirla, sería añadir los datos para crear el acceso. En este paso se nos va  a solicitar lo siguiente:

  • Nombre del host. Debemos especificar el nombre del servidor donde tiene que conectar la aplicación para logear. Nuestros servidores siguen la siguiente estructura en su nombre: linxxx.loading.es, donde las «xxx» serían sustituidas por un valor numérico, por ejemplo lin169.loading.es.
  • Nombre de usuario. En este campo se solicita el nombre de usuario proporcionado para Plesk.
  • Contraseña. La contraseña de usuario de Plesk.

Toda esta información la puedes obtener en el correo que enviamos inmediatamente con el alta del hosting (Información nueva cuenta hosting) o desde tu área de cliente > Servicios.

     

 

2.- Ya vinculada la cuenta, en la pantalla inicial veremos todos los dominios/subdominios  con un menú básico desde el que se puede acceder a los los archivos**, entrar al panel Plesk directamente, abrir la web en un navegador y revisar las estadísticas de consumo.

     

 

** Esta opción solamente estará disponible para los servidores lin156 y anteriores, ya que la conexión usa el protocolo FTP no seguro y a partir del servidor lin157 (incluido), la conexión se debe realizar de forma obligatoria con seguridad TLS y en la aplicación no está disponible actualmente; en esos servidores no accesibles sin TLS aparecerá el error «500 SSL/TLS required on the control channel», tal como se puede observar en la siguiente imagen . Para administrar los archivos en este caso, hay que pulsar en Administrar en Plesk  y ya dentro del panel dirigirse a Archivos.

 

 

3.- La opción más interesante será el acceso al panel (Administrar en Plesk), que es donde encontraremos todas las opciones disponibles con nuestro usuario, con todos los menús para moverse entre las distintas secciones. La interfaz es muy similar a la versión de escritorio, lo que hará que ya estemos familiarizados con su aspecto y menús. Este acceso de la aplicación facilitará la administración de todos los componentes que ofrece la versión web de Plesk: administración de dominios, archivos, bases de datos, aplicaciones, estadísticas y cuentas de correo. En la parte superior de la derecha aparecen tres líneas horizontales que pulsando sobre ellas nos mostrará las secciones antes comentadas.

     

 

    

 

Un apartado muy interesante será el de Correo, desde el cual podremos crear, editar y eliminar cuentas de email desde el móvil de una forma rápida y sencilla.

    

 

 

También encontraréis las funcionalidades adicionales proporcionadas por Loading, como la posibilidad de reiniciar el servidor PHP para liberar caché y detener procesos de la web, modificar la versión de PHP, administrar el filtro anti-spam avanzado Professional Spamfilter y tener acceso a las copias de seguridad para restaurarlas.

 

 

VPS  Y DEDICADOS

Además de los hostings compartidos, la aplicación podría ser usada en servidores privados VPS y dedicados. Para ello es necesario instalar desde el catálogo de Extensiones de Plesk, la extensión Plesk Mobile Center. Los usuarios que dispongan de un servidor privado con Plesk y así lo deseen, nos podrán solicitar a través de un ticket de soporte la instalación de este complemento.


 

La aplicación para estos servidores privados añadirá, además de todo lo anterior, funcionalidades de administración del servidor (para usuarios avanzados), tales como el control del Uptime, la carga CPU, RAM, transferencia e información sobre S.O., etc.

 

Se podrán también revisar los servicios activos que se ejecutan en el servidor y gestionar el reinicio de estos, y el reinicio completo del propio servidor cuando fuera absolutamente necesario. Obtendremos información sobre la licencia de Plesk, Registros y podríamos crear restricciones de acceso al servidor de IPs, etc.

     

 

Para más información y detalles, se puede visitar la página oficial de la aplicación en Plesk.com.

 

Puedes seguir todas nuestras ofertas y novedades en nuestra web loading.es, Facebook y Twitter.

Cómo clonar mi sitio WordPress para pruebas

En otra entrada a nuestro blog hablamos de cómo clonar un Prestashop para hacer pruebas, en esta ocasión vamos a explicar cómo hacer un clon manual de otra aplicación bastante popular: WordPress.

Muchos de los pasos son idénticos a la entrada de clonar Prestashop, porque en realidad lo que varía es la adaptación de la propia aplicación al nuevo dominio/subdominio donde se copia.

Aclarar primero que un clon sirve para realizar distintos tipos de pruebas, esas pruebas van desde configuraciones de rendimiento, actualizaciones o instalación de temas o plugins. Un clon de nuestra página sobre un subdominio tiene la gran ventaja de que la web en producción no corre el riesgo de quedar inoperativa por una mala configuración en el proceso o por una incompatibilidad de lo que se está instalando o probando.

Si se sigue esta guía paso a paso, obtendremos una copia exacta de nuestro WordPress en un entorno de desarrollo y de forma independiente a la web real.

 

Varios puntos a tener en cuenta antes de comenzar con esta clonación:

* Este tutorial es meramente informativo y Loading no se hace responsable de un mal uso o error producido en el hosting/web al seguirlo de forma errónea.

* Se recomienda que antes de comenzar a hacerlo, el usuario guarde una copia completa de la web en su equipo: descargando sus archivos por FTP y exportando un volcado de su base de datos desde Plesk > Bases de datos.

* Se debe tener en cuenta que para crear un subdominio es necesario un plan de hosting que disponga de ellos (en nuestro caso, un plan Argentum o superior) y debe tener libre al menos una base de datos para poder duplicar la original.

* Tras el clon, algunos enlaces (imágenes, secciones, etc.) o plugins pueden tener una configuración interna que siga apuntando al sitio original. Existe un plugin para WordPress que normalmente suele corregir estos enlaces y del que hacemos referencia más adelante en este mismo post; sin embargo, si se mantuvieran enlaces antiguos que no han sido corregidos de forma automática, los tendría que corregir el propio usuario de forma manual a través del propio plugin conflictivo o desde el código de la web o base de datos.

* Si la web original dispone de un certificado SSL, en el clon tendría que desactivar dicha opción ya que no funcionaría o instalar un certificado sobre ese subdominio, valdría con el gratuito Let’s Encrypt.

* Existen temas y plugins de pago de WordPress que operan bajo licencia y que solamente pueden ser usados sobre un dominio. Si fuera el caso, al clonar la web podría dejar de funcionar dicha plantilla o plugin, o el desarrollador de los mismos podría detectarlo.

 

Aclarado todo esto, vamos a proceder punto por punto a la explicación de cómo clonar nuestra web bajo un subdominio:

 

1.- Lo primero de todo es entrar al panel de control Plesk donde tengas alojado el dominio (pulsa sobre las imágenes para ampliarlas).

 

 

2.- Cuando se acceda al panel de control Plesk, pulsar sobre Añadir subdominio y añadir el nombre que se quiere que tenga el subdominio (p.e. “prueba” o “clon”). En el campo Raíz de documento recomendamos dejarlo como se cree por defecto, de esta forma podremos identificar mejor cuál es el directorio donde hay que copiar los archivos y donde va a tener el contenido ese subdominio. Si el subdominio ya lo tenías creado y tenías contenido puedes borrarlo entrando al directorio raíz del subdominio desde Plesk y usando la herramienta para eliminar archivos.

 

 

 

 

3.- Vamos a la carpeta del dominio original /httpdocs (o donde estén los archivos originales), marcamos el checkbox de selección de archivos principal y seleccionamos de esa forma todos los archivos. Pinchamos en el botón Copiar.

 

 

En la ventana emergente tenemos que poner el directorio creado para el subdominio (en el ejemplo /clon.wordpress.loading.net/). Le damos a Aceptar y ya tenemos copiados los archivos dentro de la carpeta del subdominio.

 

 

4.- Vamos ahora a la carpeta raíz del subdominio (/clon.wordpress.loading.net/) y pinchamos sobre el nombre del archivo wp-config.php, modificaremos estas tres variables borrando los valores que tienen y las dejamos así (aquí aparece como ejemplo “prueba_clon”, pero se tendría que modificar por los datos de la base de datos que creara nueva para el clon):

/** The name of the database for WordPress */
define(‘DB_NAME’, ‘prueba_clon’);

/** MySQL database username */
define(‘DB_USER’, ‘prueba_clon’);

/** MySQL database password */
define(‘DB_PASSWORD’, ‘prueba_clon’);

Es importante respetar las comillas simples, ya que si borramos más contenido del que aparece en el interior de ellas se provocaría un error de PHP y la web no cargaría. Con esto ya tenemos los archivos preparados.

 

 

5.- Los siguientes pasos ya tienen que ver con la base de datos. Vamos a Bases de datos desde la parte izquierda del panel Plesk > Pinchamos sobre Crear base de datos y ponemos los mismos datos que pusimos en el archivo wp-config.php de antes (prueba_clon, si seguimos el ejemplo).

 

 

6.- Al crear la base de datos, el propio panel nos devuelve a la página donde están creadas las bases de datos. Localizamos la base de datos de la web original y pulsamos sobre la opción Copiar.

 

 

 

7.- En la siguiente pantalla que aparece tendremos que seleccionar la suscripción (si fuera el caso) y marcar la opción “Copiar en base de datos existente“, seleccionando la base de datos creada para el clon.

 

 

8.- Cuando termine el proceso, se nos informará que la base de datos ha sido copiada. Ahora debemos pinchar sobre phpMyAdmin de la base de datos clonada.

 

 

9.- Accedemos a través de una nueva ventana que se abrirá para la herramienta phpMyAdmin. En la parte izquierda nos va a aparecer el listado de todas las tablas de la base de datos de WordPress, tenemos que buscar la tabla *_options (donde el asterisco ‘*’ es el prefijo de las tablas de la base de datos, por lo general en esta aplicación suele ser wp_, sería entonces wp_options). Pinchamos sobre dicha tabla y nos aparecerá en la pantalla principal el contenido de esa tabla con el nombre del dominio original.

 

 

10.- Editamos los dos campos donde aparece el nombre del dominio original (‘siteurl’ y ‘home’) y ponemos el nombre del subdominio que creamos en los primeros pasos. Pulsamos en Continuar y habremos aplicado los cambios.

 

 

Ya tenemos nuestra web copiada/clonada sobre un subdominio. El acceso a la administración va a tener la misma url final, si accedemos a la original a través de http://dominio.es/wp-admin el acceso al clon será a través de http://clon.dominio.es/wp-admin y el usuario y contraseña serán los mismos también.

11.- Vamos ahora a corregir urls que puedan quedar internas en el WordPress clonado y que apuntan al original. Para ello necesitamos entrar a la administración del clon http://pruebas.dominio.es/wp-admin y nos dirigimos a la sección de Plugins > Añadir nuevo. En el buscador ponemos la palabra «velvet» y damos a enter en el teclado para buscar, aparecerá como resultado el plugin «Velvet Blues Update URLs» y lo instalamos y activamos.

 

 

Ya instalado, posamos el cursor del ratón sobre Herramientas y pinchamos en la opción Update urls. En los campos a rellenar pondremos la url de la web original, respetando si carga sobre http o https y si funciona sobre www o sin ellas, y la url nueva del clon en el campo correspondiente. Marcamos todas las opciones excepto la última (Actualizar TODOS los GUIDs…) -cruzamos los dedos- y pulsamos en el botón Actualizar las URLSs YA.

Aparecerá una nueva pantalla cuando termine, informándonos del número de enlaces o urls que ha podido corregir.

En muchos casos, todo habrá quedado como esperamos o deseamos, pero hay que tener en cuenta lo indicado al principio de este post y revisar bien si queda algún enlace o url que debamos modificar manualmente, para evitar un redireccionamiento a la web original.

Si lo has hecho todo correctamente ya podrás trabajar con el clon de tu web en el subdominio sin peligro de modificar o desconfigurar nada en la web real.

Puedes seguir todas nuestras ofertas y novedades en nuestra web loading.es, Facebook y Twitter.

Adaptación servidores a normativa sobre TLS

 

El día 30 de Junio de 2018 está establecido el límite para la deshabilitación del protocolo TLS 1.0 debido a la obsolescencia de su cifrado.

TLS (Transport Layer Security) es un protocolo de seguridad en la capa de transporte del modelo de Interconexión de Sistemas Abiertos (OSI), que garantiza la encriptación entre las comunicaciones en Internet.

Este protocolo es un estándar de seguridad y es usado mayormente en los sistemas de pago en Internet, aunque también afecta a los servicios FTP, correo, etc. que se encuentran en un servidor.

Es por esto, que es muy importante que las comunicaciones se realicen con la mayor seguridad posible. Actualmente existen los protocolos TLS 1.0, TLS 1.1, TLS 1.2 y TLS 1.3 (soportado por los navegadores más recientes), y la fecha indicada al principio del post va a dejar el primero de todos obsoleto.

En Loading ya tenemos realizada la adaptación al nuevo estándar y hemos deshabilitado esa versión de TLS 1.0 en todos nuestros servidores de hosting compartido y también en VPS y dedicados con Plesk.

Además, la negociación SSL entre los servidores de Loading y los servidores de destino (pasarelas de pago, por ejemplo) soporta los últimos protocolos recomendados (TLS 1.1 y TLS 1.2). El cliente por su parte no tendría que realizar ninguna modificación a nivel de configuraciones en el servidor, pero sí debe tener en cuenta que al igual que Loading, las pasarelas de pago podrían haber adaptado sus sistemas y desactivado el protocolo TLS 1.0, por lo que deberá confirmar que sus scripts php o módulos de conexión con las pasarelas de pago soportan TLS 1.1 y TLS 1.2.

Pueden obtener más información sobre este tema pulsando aquí.

 

Sigue todas nuestras ofertas y novedades en Facebook Twitter.