Introducción
Razones para pasar a nuestro alojamiento en la nube
- El proyecto no es compatible con las versiones actuales de PHP o MySQL/MariaDB y todavía no puede actualizarse.
- El tamaño máximo del buzón de 10 GB en el alojamiento clásico no es suficiente (limitado por el tamaño del paquete).
- Se debengestionarvarios paquetes en una misma cuenta de cliente.
- Gestor de archivos claro para gestionar los archivos del paquete y editar fácilmente los archivos.
- No quieres gastar dinero en certificados SSL y quieres usar en su lugar certificados gratuitos Let's Encrypt.
- Una plataforma moderna y preparada para el futuro. La separación de la gestión de pedidos y del paquete facilita la autorización a las agencias.
- Los dominios con registro externo pueden utilizarse como dominios virtuales sin coste alguno.
- Muchos dominios de primer nivel pueden solicitarse directamente.
- Alta seguridad gracias a un cortafuegos de aplicaciones web (configurable) y escáneres de malware.
- El espacio de almacenamiento puede ampliarse de forma individual y económica.
- Planificación, administración y realización de copias de seguridad y restauraciones mediante el gestor de copias de seguridad.
- Disponibilidad de bases de datos MySQL 5.6 y MariaDB.
- Todas las versiones de PHP pueden personalizarse para cada dominio y subdominio.
- TYPO3 Toolkit para facilitar la instalación y administración de proyectos TYPO3.
- SEO Toolkit para optimizar sitios web para Google.
- Kit de construcción Site.pro para la creación rápida de sitios web sin conocimientos de programación.
- WordPress Toolkit para una fácil instalación y administración de proyectos WordPress.
- Acceso en tiempo real a los archivos de registro.
- Administración a través de Plesk.
- Más rendimiento a menor precio.
Versiones PHP y MySQL en Hosting Clásico
Gracias a una actualización del Servidor Clásico, ahora también están disponibles las versiones PHP 7.4, 8.0, 8.1 y 8.2, así como MySQL 5.7 y MariaDB 10.4.
Versiones PHP y MySQL en el alojamiento en nube
En nuestras tarifas de alojamiento en la nube, seguimos ofreciendo las versiones antiguas de PHP (a partir de la versión 4.4) como "PHP endurecido", además de las versiones actuales de PHP. Estas versiones PHP endurecidas seguirán recibiendo actualizaciones de seguridad. Cuando se publiquen nuevas actualizaciones de seguridad para las versiones actuales de PHP, estas actualizaciones también se aplicarán a las versiones antiguas de PHP en la medida en que sea técnicamente posible (backport, véase https://de.wikipedia.org/wiki/Backport).
Además de una base de datos MariaDB 10.3 compatible con MySQL 5.7, las bases de datos MySQL 5.6 siguen estando disponibles.
¿Qué ocurre cuando se migran las bases de datos?
Al migrar bases de datos MySQL 5.6 a MySQL 5.7, puede ocurrir que los programas no sean compatibles con MySQL 5.7, provocando un mal funcionamiento del sitio web.
Por lo general, el dominio (sitio web) afectado deja de funcionar. Dependiendo de la aplicación y de la configuración, en su lugar aparece una página en blanco (blanca) porque los mensajes de error PHP no están activados, o aparecen mensajes de error.
¿Qué ocurre cuando se desconectan las versiones antiguas de PHP?
Si hay que desconectar otras versiones antiguas de PHP debido a vulnerabilidades de seguridad, la versión 7.3 de PHP dejará de utilizarse en el dominio afectado.
Dependiendo de la aplicación, puede ocurrir que la programación no sea compatible con PHP 7.3 y aparezca una página en blanco (error PHP) o se muestren mensajes de error. En este caso, la aplicación debe ser actualizada por un desarrollador.
No hay pérdida de datos, todos los datos siguen estando disponibles en el espacio web.
Solución: pasarse al alojamiento en la nube
Para seguir ejecutando aplicaciones web con versiones de PHP o MySQL obsoletas o más recientes, le recomendamos pasar a nuestras nuevas tarifas de alojamiento en la nube.
Para ello, deberá suscribir un nuevo contrato de alojamiento. Todos los archivos, bases de datos y buzones de correo electrónico utilizados activamente, así como las entradas de redireccionamiento y DNS, deben trasladarse del centro de datos de Colonia al de Fráncfort. Técnicamente se trata de un cambio de proveedor.
I nformación importante: ¡los dominios se volverán a calcular al pasar al alojamiento en la nube!
Existen varias opciones para realizar el traslado
- Realice usted mismo el traslado.
- Usted encarga el traslado a su agencia o al creador o programador del sitio web.
- Nos encarga el traslado de los sitios web. Sin embargo, como nuestras capacidades disponibles son limitadas, puede haber tiempos de espera más largos.
A continuación encontrará los pasos necesarios. Dependiendo de la opción, las partes las realizaremos nosotros, su agencia o usted mismo.
En las tres opciones, tenga en cuenta que no podemos hacernos cargo del traslado de los buzones de correo electrónico. Encontrará los pasos necesarios en Paso 8: Traslado de los buzones de correo electrónico.
Requisito previo para la mudanza
Para realizar el traslado, es imprescindible trabajar en el "shell" del servidor de origen y de destino. El acceso al shell se realiza mediante un acceso SSH y un programa de terminal. En Windows, se utiliza un programa como PuTTY o Mobaxterm.
Instrucciones para trabajar en el shell.
Si no tienes experiencia previa en trabajar con el shell, es aconsejable que pidas a alguien que la tenga que realice el traslado.
Pedir y configurar alojamiento en la nube
Antes de iniciar el traslado, es necesario solicitar y configurar una nueva tarifa de alojamiento.
Ofrecemos tres tarifas de alojamiento en la nube entre las que elegir: Cloud BASIC, Cloud PREMIUM y Cloud POWER. Se diferencian por el espacio de almacenamiento, el rendimiento y las funciones adicionales.
Le recomendamos la tarifa Cloud PREMIUM, que ofrece 100 GB de espacio de almacenamiento, así como numerosas funciones útiles para el desarrollo y la optimización de sitios web.
Si, por el contrario, sólo necesita seguir explotando un sitio web existente, la tarifa Cloud BASIC con 30 GB de espacio de almacenamiento puede ser suficiente.
En nuestro resumen de tarifas, puede añadir la tarifa deseada directamente a la cesta de la compra y completar el pedido como nuevo cliente en nuestro sistema. También tendrá que volver a introducir sus datos bancarios si desea que sigamos cobrando las facturas por domiciliación bancaria.
Las facturas se emiten siempre a nombre del titular del contrato especificado. No existe una dirección de facturación independiente.
El paquete recibe automáticamente un dominio de desarrollo gratuito de nuestro sistema , según el patrón 90xxxx.jweiland-hosting.de (el dominio que está utilizando actualmente sólo se transferirá cuando se complete el traslado).
Al contratar un paquete de alojamiento en la nube, es obligatorio celebrar con nosotros un contrato de tramitación de pedidos de conformidad con el GDPR. El paquete de alojamiento se activará en cuanto hayamos recibido este contrato cumplimentado y firmado.
Múltiples paquetes de alojamiento en nube
Mientras que en Classic Hosting tenía que reservar varios paquetes con diferentes números de cliente, ahora Cloud Hosting le ofrece la opción de reservar varios paquetes en una cuenta de cliente con un solo número de cliente. Ahora puede reservar cualquier número de tarifas de cloud hosting (alojamiento compartido o servidor) bajo esta cuenta de cliente. Se pueden crear inicios de sesión adicionales para cada una de las tarifas reservadas, y también son posibles diferentes autorizaciones.
Una cuenta de cliente se identifica unívocamente por la dirección de correo electrónico especificada, que no puede utilizarse para varias cuentas de cliente. La dirección introducida al realizar el pedido o en la cuenta de cliente corresponde a la dirección de facturación. Las tarifas, dominios u otros servicios adicionales que vencen en un momento determinado se facturan en una sola factura.
Realización del traslado
Medidas preparatorias recomendadas
Muchos contratos con clientes han acumulado un gran número de proyectos a lo largo del tiempo: Versiones de desarrollo y de prueba, archivos de versiones antiguas de sitios web, etc.
Como primer paso, tiene sentido considerar qué aplicaciones siguen siendo realmente necesarias.
Cada proyecto suele tener varios componentes:
- Un dominio o subdominio a través del cual se puede acceder al proyecto en el navegador.
- Un directorio de destino en el que se encuentran los archivos del proyecto, también conocido como DOCROOT o directorio de inicio.
Este es el directorio (con subdirectorios) desde el que se cargan los archivos cuando se accede al dominio. Los subdirectorios también contienen el código del programa (scripts PHP), imágenes, archivos PDF, ... - Una base de datos en la que se almacenan los contenidos (textos y otros registros de datos) del sitio web.
- Cronjobs, es decir, programas que se llaman a intervalos regulares para realizar determinadas tareas. Por ejemplo, copias de seguridad, importación y exportación de datos, envío de boletines, etc.
- Programas auxiliares necesarios para determinadas tareas de la aplicación. Por ejemplo, tratamiento y conversión de imágenes, extracción de información de archivos de imagen y PDF para funciones de búsqueda, etc.
- Otros programas necesarios para un proyecto, como Matomo (para estadísticas de sitios web).
- Bandejas de entrada de correo electrónico con mensajes almacenados en ellas.
Todos estos componentes deben transferirse al nuevo servidor durante el traslado.
Tras el traslado, suele ser necesario realizar ajustes, como especificaciones de rutas absolutas en los scripts.
Dependiendo del tamaño del sitio web, este traslado puede llevar varias horas.
Antes de completar el traslado, se prueba el proyecto en el nuevo servidor utilizando un dominio temporal. Así se garantiza que todo funciona como se desea. También es un buen momento para comparar la velocidad entre el servidor de origen y el de destino, ya que se puede acceder al sitio web tanto en el servidor antiguo como en el nuevo.
Una vez finalizadas todas las pruebas, el dominio se transfiere al nuevo servidor. En el caso de los denominados dominios con registro externo, que no se registran a través de nosotros sino de otro proveedor, es necesario cambiar los registros A en el proveedor de dominios para que el dominio apunte al nuevo servidor.
Paso 1: Solicitar un paquete de alojamiento en la nube
Como se explica detalladamente en la introducción anterior, primero debe solicitar un paquete de alojamiento en la nube como cliente nuevo.
Una vez que hayamos recibido el contrato AV completo y cumplimentado, configuraremos el paquete. Una vez hayamos completado el trabajo, recibirá un correo electrónico con sus datos de acceso y contraseñas.
Paso 2: Copia de seguridad de las bases de datos en archivos
La mayoría de los sitios web utilizan bases de datos para almacenar contenidos. Una vez determinado qué proyectos se van a trasladar al alojamiento en nube, hay que identificar las bases de datos asociadas.
Determinar las bases de datos
Si un dominio apunta a un directorio de destino en el menú de cliente anterior (y no es una redirección a otro dominio), anote el directorio de destino (por ejemplo, /typo3cms/projekt1 o /wordpress). En este directorio de destino, debe averiguar en qué archivo se almacenan los datos de acceso a la base de datos.
En TYPO3, dependiendo de la versión, estos datos se encuentran en los archivos [directorio de destino]/typo3conf/LocalConfiguration.php o [directorio de destino]/typo3conf/localconf.php
Para Redaxo, los datos de acceso se encuentran en el archivo [directorio de destino]/redaxo/include/master.inc.php
Para WordPress, los datos de acceso se encuentran en el archivo [directorio de destino]/wpconfig.php
Copia de seguridad de las bases de datos
Para guardar el contenido de la base de datos en un archivo, inicie sesión en el paquete de alojamiento anterior mediante acceso SSH y cambie a la carpeta
/typo3cms/sistema/backup/bases de datos
Aquí creas la imagen de la base de datos con el siguiente comando (introdúcelo en una línea):
mysqldump --opt --no-tablespaces -h mysql -u db123456_789 -p db123456_789 > mybackup.sql
A continuación, debe introducir la contraseña de la base de datos y confirmar con [Intro].
En los paquetes de alojamiento anteriores, los nombres para el usuario de la base de datos y el nombre de la base de datos son idénticos; en los paquetes de alojamiento en la nube, pueden ser diferentes.
El nombre de archivo (en el ejemplo meinbackup.sql) bajo el que se guarda la base de datos puede elegirse como se desee.
Si se utilizan varias bases de datos, cada una de ellas debe guardarse en un archivo distinto.
Paso 3: Transfiere todos los archivos
El comando rsync se utiliza para transferir todos los archivos, incluidas las copias de seguridad de la base de datos, del paquete de alojamiento anterior al nuevo paquete de alojamiento en la nube.
Inicie sesión en el servidor del paquete de alojamiento anterior y cambie al nuevo paquete de alojamiento con el comando
cd [Intro]
al directorio de inicio (corresponde al directorio en el que aterriza tras el inicio de sesión SSH).
Para realizar la transferencia, introduce el comando personalizado con tus propios datos:
rsync --delete -ave ssh . nombre_usuario@host:httpdocs/__transfer
El punto después de ssh con un espacio antes y después es importante.
- username: Usuario SSH del paquete de alojamiento en la nube
- host: Nombre del servidor (por ejemplo 900xxx.jweiland-hosting.de) del paquete de alojamiento en la nube
Dependiendo de la cantidad de datos, la transferencia puede tardar unos minutos.
Una vez finalizada la transferencia, todos los archivos del paquete de alojamiento en la nube se encuentran ahora en el directorio: httpdocs/__transfer
Paso 4: Leer el contenido en la nueva base de datos
Debe crear una nueva base de datos para cada base de datos original del paquete de alojamiento en nube.
En la opción de menú Bases de datos, haga clic en "+ Añadir base de datos" e introduzca un nombre de usuario y un nombre de base de datos para la nueva base de datos. Las bases de datos MySQL 5.6 y MariaDB 10.3 (corresponde a MySQL 5.7) están disponibles.
Como con el alojamiento anterior sólo estaba disponible MySQL 5.6, selecciona también MySQL 5.6 para el alojamiento en la nube al transferir sitios web.
Haga que se genere y muestre la contraseña. Anótala en un lugar seguro (la contraseña ya no se puede ver más tarde, pero se puede restablecer si es necesario).
Después de crear las bases de datos, debe importar las copias de seguridad de las bases de datos del archivo a la nueva base de datos.
Para ello, debe iniciar sesión en el shell a través de SSH y cambiar al directorio: httdocs/__transfer/typo3cms/system/backup/databases
Aquí se encuentran los archivos de base de datos de las copias de seguridad creadas en el alojamiento anterior. Ahora se leerán en la base de datos recién creada.
Introduzca el comando personalizado con sus propios datos:
mysql -h db.mysql56 -u nombre de usuario -p nombre de base de datos < mybackup.sql
- username: nuevo nombre de usuario
- datenbankname: nuevo nombre de base de datos
- mybackup.sql: nombre del archivo de copia de seguridad
A continuación, debe introducir la contraseña de la base de datos y confirmar con [Intro].
Si tiene varios proyectos, repita este proceso para cada base de datos.
A continuación, introduzca los nuevos datos de acceso a la base de datos en el archivo de configuración del sitio web. Ya se ha descrito dónde encontrarlos en el Paso 2: Copia de seguridad de bases de datos en archivos.
Paso 5: Mover los archivos al destino final
Todos los archivos del proyecto están ahora todavía en el directorio: httpdocs/__transfer
Tiene sentido mover estos archivos del proyecto al destino final. Por ejemplo, si el proyecto está en el directorio httpdocs/__transfer/typo3cms/projekt1, el proyecto debería moverse a un subdirectorio de httpdocs/typo3cms. Sin embargo, ya existe un directorio project1 allí. Este fue creado por nosotros al configurar el paquete de alojamiento y contiene una instalación TYPO3 vacía.
Puede eliminar primero el directorio httpdocs/typo3cms/projekt1 (si no es necesario para un nuevo sitio web) o puede mover el proyecto transferido a un nuevo directorio, por ejemplo httpdocs/typo3cms/projekt2 o httpdocs/typo3cms/nombre-del-dominio.com.
El nombre del directorio de destino puede elegirse como se desee, ya que no es visible para el mundo exterior. En nuestro ejemplo, se mueve el proyecto a httpdocs/typo3cms/projekt2
Primero cambie al directorio de inicio, luego al directorio httpdocs y ejecute allí el comando move:
cd [Intro] cd httpdocs mv __transfer/typo3cms/projekt1 typo3cms/projekt2
En un proyecto TYPO3, el subdirectorio typo3temp/var/Cache debe ser eliminado, ya que todavía contiene alguna información de ruta del servidor anterior. Una vez eliminado, el directorio se volverá a crear automáticamente la próxima vez que se acceda a un sitio web.
Paso 6: Crear hosts virtuales
Para poder transferir sus buzones de correo electrónico en el paso 8 y realizar la configuración de los dominios en el paso 7, debe añadir sus dominios al paquete como dominios virtuales en la gestión de pedidos.
Paso 7: Configurar el alojamiento
En la raíz de documentos del dominio, guarde el directorio al que movió el sitio web en el paso 5: Mover archivos al destino final.
Para la compatibilidad con PHP, seleccione la versión de PHP adecuada para el sitio web. En nuestro sitio web encontrará un resumen de las versiones de TYPO3 y las versiones PHP correspondientes.
Paso 8: Transferir buzones de correo electrónico
Preparación de la transferencia de correo
La transferencia de los buzones de correo electrónico sólo es necesaria si se han creado los buzones de correo electrónico correspondientes en la tarifa de alojamiento anterior y éstos se utilizan a través de IMAP (los correos electrónicos permanecen en el servidor y no se almacenan localmente en el ordenador). Si los correos electrónicos se recuperan a través de POP3, los buzones de correo electrónico no deben contener ningún correo electrónico (utilización 0 MB como en la imagen "Alojamiento clásico - Buzón de correo electrónico").
Si tiene su propio servidor de correo para su dominio o utiliza sus correos electrónicos a través de otro proveedor, puede continuar con el paso 9: Configuración para el envío de correos electrónicos desde el sitio web.
Nota importante para nuestros clientes Classic:
Si utiliza el webmailer Horde o Roundcube para recibir y enviar correos electrónicos y utiliza allí una o varias libretas de direcciones, deberá exportar estas libretas de direcciones antes de la transferencia e importarlas a Cloud Hosting en Roundcube. Utilice para ello el formato vCard (3.0). Las libretas de direcciones no se transfieren automáticamente.
Las firmas o las respuestas automáticas también deben crearse de nuevo, ya que tampoco pueden transferirse.
Puede encontrar una lista de las direcciones de correo electrónico que ha creado en su menú de cliente anterior en Gestionar direcciones de correo electrónico (imagen "Gestionar direcciones de correo electrónico de Classic Hosting"). Si las direcciones de correo electrónico se han creado allí, primero debe crear estos buzones en Cloud Hosting. Sin embargo, esto sólo es posible si los dominios ya han sido registrados en el paquete de Cloud Hosting o si han sido creados como se describe en el paso 6: Crear hosts virtuales.
Configure el tráfico de correo electrónico como se describe en Configuración de correo electrónico para el dominio.
En la configuración del dominio, en Dominio: Correo electrónico, hay una función para la importación masiva de correo que se puede utilizar para crear automáticamente buzones de correo electrónico, reenviadores y alias utilizando un archivo .csv. Puede solicitárnoslo, por ejemplo, si necesita trasladar muchas direcciones de correo electrónico de Classic a Cloud Hosting.
Herramienta de transferencia de correo
Una vez creados todos los buzones que desea transferir en el paquete de alojamiento en nube, vaya a nuestra herramienta de transferencia de correo: https://mailtransfer.jweiland.net.
Tras hacer clic en "Transferir el contenido de mi buzón", aparecerá la página "Transferir buzones".
Si desea transferir buzones de correo de un paquete de alojamiento clásico a un paquete de alojamiento en la nube, seleccione "Alojamiento clásico de jweiland.net" en "Proveedor antiguo". En caso contrario, seleccione el proveedor desde el que desea transferir los buzones.
En "Nuevo proveedor", seleccione el servidor de Cloud Hosting que especificó en el correo electrónico "KN ......". - Su tarifa de Cloud Hosting Cloud ........ ha sido configurada".
Utilice el botón "+ Añadir otro buzón" para añadir más buzones del mismo proveedor para su transferencia.
Haga clic en "Siguiente" para comprobar los datos de acceso. Si son correctos, se inicia la transferencia. También se muestra un enlace en el que puede comprobar el estado de la transferencia. En el caso de buzones grandes, la transferencia puede tardar varias horas.
Si la transferencia tarda mucho o se reciben más correos electrónicos entre la transferencia y la transferencia final del dominio, se puede reiniciar la transferencia de los buzones. Entonces sólo se transferirán los nuevos correos electrónicos, con lo que el proceso será mucho más rápido que la primera ronda.
Si la visualización de la utilización del buzón no le es suficiente para comprobar la transferencia y desea comprobar si todos los correos están disponibles en el nuevo buzón antes de trasladar el dominio, debe utilizar el webmailer Roundcube en cloud hosting.
Para ello, sin embargo, primero debe crear un registro A para el subdominio "webmail.su-dominio.com" con la dirección IP del servidor cloud en la configuración DNS del dominio (en su Hosting Clásico, no es posible en la tarifa PRIVADA, ni con el proveedor anterior). Algún tiempo después de la creación del registro A, se puede acceder al webmailer Roundcube a través de la dirección webmail.sudominio.com.
Como antes, el envío de e-mails por buzón está limitado a 250 e-mails por hora.
Además, existe un límite de 500 correos electrónicos por hora para cada dominio y de 1.000 correos electrónicos por hora para el paquete de alojamiento. Si se requieren límites superiores (por ejemplo, envío de boletines o muchos propietarios de buzones), puede solicitarnos un aumento de los límites mediante el formulario.
Los correos electrónicos enviados por encima de estos límites no se almacenarán temporalmente ni se entregarán con retraso, sino que se descartarán.
Asegúrese de utilizar contraseñas seguras para sus buzones de correo electrónico y no las ceda a terceros. Si se envía spam a través del dominio, éste puede ser desactivado para el envío de correos electrónicos.
Paso 9: Configuración del envío por correo electrónico desde el sitio web
Entrada SPF
La entrada SPF determina qué servidores pueden enviar correos electrónicos para un dominio.
El servidor en el que se encuentra su paquete se incluye automáticamente en el registro SPF.
v=spf1 +a +mx +a:nombredelservidor.jweiland.cloud -all
Si envía correos electrónicos a través de otro servidor, la entrada SPF debe ampliarse con un include:servername:
v=spf1 +a +mx +a:nombredelservidor.jweiland.cloud include:nombredelservidor -all
No se pueden crear varios registros SPF para un mismo dominio. Siempre se debe ampliar o modificar una entrada existente.
Paso 10: Configurar cronjobs
Compruebe qué cronjobs están introducidos en el antiguo menú de cliente y créelos en el cloud hosting de la misma manera.
Al ejecutar scripts, se añade httpdocs/ a la ruta, por ejemplo
typo3cms/system/backup/daily (anteriormente) httpdocs/typo3cms/system/backup/daily (para cloud hosting)
Al llamar al planificador de TYPO3, el intervalo de ejecución de 5 minutos se puede especificar en "Cron Style" como */5 * * * *.
Para otros tiempos, encontrará más consejos y un"Cronitor" en una página externa.
Si el script scheduler.sh es llamado vía cronjob, la ruta a la versión correcta del intérprete PHP debe ser ajustada.
Ejemplo, si PHP 7.2 se utiliza actualmente en scheduler.sh (en una línea):
env -i /usr/local/bin/php7-72LATEST-CLI -f ~/typo3cms/projekt1/typo3cms scheduler:run
la versión PHP 7.2 se especifica ahora con
env -i /opt/alt/php72/usr/bin/php -f ~/httpdocs/typo3cms/projekt1/typo3cms scheduler:run
Paso 11: Transferir dominio
Una vez transferidos todos los datos y buzones y comprobada la funcionalidad de la página web, ya puede transferir el/los dominio(s). Aquí hay que distinguir si el dominio estaba previamente registrado con nosotros o con otro proveedor. En este último caso, también debe comprobar si el dominio debe transferirse a nosotros o permanecer con el otro proveedor.
El dominio debe trasladarse al cloud hosting
En primer lugar, debe comprobar si se han realizado configuraciones adicionales del servidor de nombres para el dominio.
En Classic Hosting, vaya a su menú de cliente. A partir de la tarifa BUSINESS, encontrará un símbolo de rueda dentada en la línea correspondiente a su dominio en "Configuración" ' "Administración de dominios". Haga clic en este símbolo de rueda dentada y luego en "Editar servidor de nombres" en el menú que aparece.
Si se introduce "auto" en todos los ajustes, no se han realizado entradas adicionales o divergentes.
Sin embargo, si hay ajustes adicionales o diferentes aquí, estos deben ser anotados cuidadosamente, ya que tendrán que ser creados de nuevo exactamente de la misma manera más tarde para el alojamiento en la nube. Lo mejor es hacer capturas de pantalla, teniendo en cuenta que la tabla con las entradas puede ser más larga y se puede desplazar.
Además del nombre del host correspondiente, también es importante el tipo y el destino o valor de la entrada.
Una vez anotados los datos, hay que liberar el dominio para un cambio de proveedor en jweiland.net o en el otro proveedor.
- Si los datos del propietario en el paquete Classic Hosting y Cloud Hosting coinciden, la liberación puede solicitarse a la dirección de correo electrónico almacenada en los datos maestros de Classic Hosting.
- Si los datos del propietario en el paquete Classic Hosting y Cloud Hosting no coinciden, el propietario del dominio deberá solicitar la liberación mediante el formulario Cancelación de dominios (no cancelación del paquete).
Los AuthCodes (código de autorización) necesarios para transferir los dominios se comunican en ambos casos en una confirmación que se envía por correo electrónico a la dirección de correo electrónico almacenada en el paquete Classic Hosting en los datos maestros.
Ahora puede solicitar el dominio en la gestión de pedidos para el cambio de proveedor.
Utilización de un dominio con registro externo
Un dominio también puede utilizarse con nosotros si está registrado a través de otro proveedor y no se va a transferir a nosotros. En la mayoría de los casos, sólo el sitio web se ejecutará a través de nosotros, mientras que, por ejemplo, el tráfico de correo electrónico se ejecutará a través de otro proveedor.
Como ya ha creado el dominio en el paso 6: Crear hosts virtuales, ahora sólo tiene que actualizar las direcciones IPv4 e IPv6 con su proveedor de dominios.
Paso 12: Configurar certificado SSL
Por último, ya puede configurar un certificado SSL para su dominio.
Código de error 500: Error interno del servidor
Si aparece un error 500 al abrir el sitio web, los siguientes consejos pueden ayudarle a solucionarlo:
- Borre la carpeta typo3temp/var/Cache en TYPO3
Compruebe si una de las siguientes entradas está presente en el archivo .htaccess en el directorio de inicio, si es así, coméntelo (preceda la línea con un #): Options +FollowSymLinks Options -Indexes Options +Indexes