Nota: (late 2024) Esta página de doc es muy fechada, pero todavía debe tener algún valor - en particular si migramos una copia de seguridad TKLBAM a una versión TurnKey significativamente más nueva.

Por favor, veamos TKLBAM docs para más general y hasta la fecha TKLBAM info. Ver el conseguir apoyo página para opciones e información si necesita más soporte personalizado y actual.

Ha habido algunos cambios significativos en Debian Jessie (en lo que TurnKey Linux v14.x está basado) de versiones anteriores. Esta página está dirigida a proporcionar una visión general y cierta información sobre un par de temas comunes. No es exhaustivo y puede que encuentre otros problemas.

Si tienes cosas extrañas suceden después de migrar desde una versión anterior de TKL a v14.x, entonces por favor, publicar en foros de apoyo y alguien estará a su lado para tratar de ayudar a ASAP. También si eres un Hub usuario (o Mercado AWS suscriptor) entonces por favor también se sienta libre de probar nuestro portal de soporte (accesible cuando se ha conectado al Hub).

Se sugiere que usted lea a través de toda esta página antes de comenzar. Propuesto flujo de trabajo o el Migración semi-manual/establecida TKLBAMDe cualquier manera probablemente todavía necesite hacer algo Ajustes manuales para software específico.

Afluencia de trabajo sobre migración propuesta

Se sugiere que migras de versiones anteriores (pre v14.x) de TurnKey en un proceso escenificado, algo así:

Observe los puntos específicos como detallados hacia la parte inferior de esta página.
Auditoría de datos restaurados en el nuevo servidor - comprobar lo que está funcionando y lo que no.
Resuelva los problemas señalados en su auditoría, documentando como usted va.
Haz la migración final.

1. Restitución y auditoría iniciales

Se recomienda que no toque su servidor de producción (de donde viene su copia de seguridad) hasta que la migración esté completa y que esté 100% satisfecho.

Primero comprueba que tu última copia de seguridad es bastante reciente. Suponiendo que no hayas hecho cambios significativos en tu appliance en el último mes o así; una copia de seguridad desde dentro de ese plazo debe ser adecuada para nuestros propósitos iniciales. Luego, restituya sus datos a un servidor de prueba desechable (por ejemplo, un VM local o un servidor AWS fresco, etc.) y haga una auditoría completa. Tome nota cuidadosa de lo que está funcionando y lo que no lo es. Una vez que hayas completado la auditoría, tómate un tiempo para hacer alguna investigación sobre cualquier cosa que no estés familiarizado con.

Al buscar documentación/ints sobre temas específicos, generalmente Google es su amigo. Tenga en cuenta que bajo la capucha TurnKey se construye en Debian, por lo que las cosas generalmente aplicables a Debian, también se aplica a TurnKey. v14.x se basa en Debian Jessie aka Debian 8.

Tenga en cuenta que cuando appliances incluye software que se instala desde el río arriba (por ejemplo, TurnKey instala WordPress directamente desde WordPress ellos mismos) que generalmente, toda la aplicación está incluida en su copia de seguridad. Así que si migramos su sitio v13.0 WordPress (a fin de cuentas que está ejecutando WordPress v3.2) a un v14.2 WordPress appliance, todavía estará ejecutando la versión antigua del software. En otras palabras, aunque TurnKey v14.2 viene con WordPress v4.4, su viejo sitio 3.2 lo sobreescribirá.

Como la mayoría de nuestro appliances son basados en LAMP, estoy usando PHP como ejemplo, pero esto generalmente se aplica a otros software también. Si vienes de v13.x, y no has actualizado activiosamente el software, la mayoría de las aplicaciones PHP que se ejecutan en v13.x todavía debe funcionar bien como la diferencia entre PHP en v13.x (PHPv5.4) y v14.x (PHPv5.6) no son demasiado significativos. Sin embargo, existe la posibilidad de que el software más viejo que funciona bien en v13.x puede ser un poco de desconcertante en v14.x, o quizás no trabajar en absoluto.

Si el software que está utilizando, no está correctamente soportado en la versión más reciente de PHP (o cualquier idioma/platform) entonces usted también puede necesitar actualizar el software mismo (por ejemplo. WordPress). Incluso si no lo necesita, puede que desee actualizar a una versión más nueva. Las versiones más recientes a menudo incluyen nuevas características, y las correcciones de seguridad en curso.

Si está actualizando el software de terceros desde arriba, lo primero que hay que hacer es leer los documentos. Los proyectos (casi) siempre proporcionan instrucciones de migración o scripts de una versión a otra. Antes de hacer cualquier cosa, vale la pena leer a través de cualquier documentación relevante que pueda encontrar. A menos que usted está experimentando problemas durante su auditoría, generalmente recomiendo que usted haga actualizar software de terceros un paso más tarde, en lugar de abordarlo ahora ...

2. Labor realizada mediante cuestiones encontradas durante la auditoría

Considere esta primera carrera puramente una prueba. De esa manera usted puede ser sin miedo en su retoque. Si usted hace algo peor, o las cosas se ponen desordenadas (por ejemplo. prueba y error sin resolución limpia) entonces usted puede simplemente traspasar su servidor de prueba y comenzar de nuevo con una restauración fresca (a un servidor fresco si usted ha roto demasiado las cosas).

Asegúrese de documentar todo lo que hace; especialmente las cosas que funcionan. Trate de enfocarse en un problema a la vez y seguir trabajando hasta que cada solución esté completa. Si terminas empezando una nueva, cualquier problema independiente que ya hayas resuelto completamente (que no tiene consecuencias para otros temas), no es necesario que te repitan en esto Cualquier problema que hayas resuelto parcialmente o necesites ser redone (para revelar otros asuntos que aún necesitas abordar) puede ser redoneado usando tus docs como referencia.

3. Migración final

Has trabajado a través de todos los problemas descubridos en tu auditoría y documentado su resolución. De vuelta en su servidor de producción, donde sea relevante y posible; ponlo en "modo de mantenimiento" o bloquearlo de otra manera (por lo que no se añade ningún contenido nuevo).

Restaurar su nuevo respaldo a un nuevo servidor nuevo. Siga sus docs para completar la migración de modo que todo esté funcionando bien. Saquelo de "modo de mantenimiento" (etc).

Una vez que esté 100% feliz, haga cualquier pinza final (por ejemplo, configure DNS para mapear a la nueva máquina, etc) para ponerla en producción y hacer una copia completa de seguridad TKLBAM de su nuevo servidor:

tklbam-backup --full-backup now

Cuando estés listo puedes destruir el servidor antiguo. Tenga en cuenta que algunos como dejar el servidor antiguo funcionando por un tiempo, por si acaso. También se recomienda que antes de destruir el servidor; dentro del Hub se establece "reposiciones máximas" a 1 y forzar un respaldo completo final. Eso aclarará todos los respaldos anteriores y le dejará con una copia de seguridad de legado final para fines históricos y de archivo.

Migración semimanual/establecida TKLBAM

Si tienes una idea de dónde se ubican los archivos importantes que necesitas restaurar, una buena alternativa es una restauración manual (o semi-manual). Esto puede cortocircuitar cosas y significar menos trabajo a largo plazo. Es ideal para migrar desde servidores muy antiguos, o configuraciones muy personalizadas o particularmente complejas. Sin embargo TKLBAM puede ser una forma muy útil de transferir sus datos al nuevo servidor y hacer el proceso semi-manual, en lugar de manualmente. Es recomendable seguir un flujo de trabajo algo similar a lo que es arriba.

En lugar de hacer una restauración completa, sin embargo, sólo hacer una descarga y el vertedero:

mkdir /tklbam-dump
tklbam-restore BACKUP_ID --raw-download=/tklbam-dump

Uso tklbam-restore, puede continuar restaurando partes específicas de su copia de seguridad utilizando el --limits= cambiar, por ejemplo, para restaurar todo /var/www/ y es contenido, además de una base de datos MySQL llamada 'DATABASE_1', pero sin paquetes, podría utilizar esta línea:

tklbam-restore /tklbam-dump --skip-packages --limits="/var/www mysql:DATABASE_1"

Alternativamente, saltar paquetes y restaurar todo excepto /etc (y es contenido) y /boot (y su contenido), utilice esta línea:

tklbam-restore /tklbam-dump --skip-packages --limits="-/etc -/boot"

Por favor, veamos Página del hombre de restauración tklbam para más información.

Si rompes algo, puedes volver a rodar con tklbam-restore-rollbackPor favor, tenga en cuenta que TKLBAM sólo almacena un revolver. Así que puede ser mejor tratar de restaurar todo lo que necesita/quiere en una sola marcha. Una buena opción puede ser comenzar manualmente haciendo copias de seguridad TKLBAM de este nuevo servidor en cada paso del proceso.

También puede restaurar manualmente archivos del directorio /tklbam-dump si lo desea. Los archivos descargados deben estar en lugares que son relativos al directorio de descarga. archivos que vienen de /var/www debe ser encontrado en /tklbam-dump/var/www. Tenga en cuenta que por defecto, los permisos no se conservarán cuando se muevan los archivos manualmente, por lo que se pueden requerir ajustes de permiso.

De cualquier manera, todavía necesitará decidir qué moverse y qué no hacerlo, pero puede hacer una migración manual un poco más fácil. ¡Sería más fácil que tener que hacer una migración manual completa!

Software específico

Webmin (todo appliances)

A partir de v14.0 Webmin está ahora escondido detrás de la atonta. Esto significa que si restauras de una versión anterior necesitarás hacer algunos cambios antes de que Webmin funcione de nuevo. En el archivo de configuración del servidor Webmin (/etc/webmin/miniserv.conf) asegúrese de que tiene estas entradas (addárselas o cambiarlas según corresponda):

port=10000
ssl=
listen=10000
inetd_ssl=1
bind=127.0.0.1
sockets=
no_resolv_myname=0
ipv6=0

También comprobar doblemente que el config de la atonel (/etc/stunnel/stunnel.conf) tiene esto (probablemente al final):

[webmin]
accept  = 12321
connect = 127.0.0.1:10000

Si ha configurado certificados SSL para Webmin (y/o Webshell), entonces es muy probable que también necesite configurar el stunnel para utilizarlos en su lugar. ajustar las líneas en /etc/stunnel/stunnel.conf que dice esto:

cert = /etc/ssl/private/cert.pem

Apache (inc LAMP y alrededor del 70% de la biblioteca)

El config Apache ha tenido algunos cambios significativos, aunque el que romperá las cosas es en realidad TurnKey relacionado. Hemos endurecido el SSL en v14.0 y movimos la ubicación de certificado predeterminado. También incluimos todos los config adicional SSL/TLS juntos (en /etc/apache2/mods-available/ssl.conf).

La forma más fácil de evitar el problema más significativo, es excluir el archivo ssl.conf de Apache de su restauración. Usted puede hacer eso de esta manera:

tklbam-restore --limits="-/etc/apache2/mods-available/ssl.conf"

Si usted tiene un certificado de CA de terceros entonces esto no debe afectarle (aunque usted puede mover su cert si desea). Si está usando certificaciones auto firmados, simplemente eliminar referencia al antiguo certificado de los archivos del sitio Apache vhost (en /etc/apache2/sites-available) debe hacer el truco. E.g. aquí está la actualización en acción sobre Trac appliance.

Hay otros cambios que probablemente deberían hacerse (aunque Apache todavía debe funcionar sin ellos). Vea los enlaces a continuación para más información.

Más información:

Apache docs: https://httpd.apache.org/docs/2.4/upgrading.html
Gran post en el Océano Digital: https://www.digitalocean.com/community/tutorials/migrating-your-apache-c...

MySQL

Nada de significado debería haber cambiado con respecto a MySQL, por lo que esperaba que la mayoría de los usuarios estén bien. bug en PHPMyAdmin, hemos cambiado al peso más ligero MySQL web UI; Adminer.

Usted es bienvenido a continuar con PHPMyAdmin si lo prefiere, pero usted tendrá que deshabilitar Adminer y tweak PHPMyAdmin para utilizar un sub directorio. Y acostúmbrese a utilizar PHPMyAdmin desde https://YOUR_DOMAIN.COM/phpmyadmin (es decir, como subdirectorio de su sitio web, en lugar de a través de un puerto específico).

Además (no creo que esté relacionado, pero no seguro) algunos usuarios han informado que su contraseña raíz MySQL no funciona después de la restauración. Eso puede ser fácilmente reajuste re-correr el inithook MySQL:

/usr/lib/inithooks/bin/mysqlconf.py

Fileserver

Samba ha pasado de v3.x en todas las versiones anteriores de TKL a v4.1/v4.2 en v14.x así que de nuevo algunos cambios significativos. Un miembro de la comunidad de ayuda ha resuelto los principales problemas y ha publicado un esquema claro en los foros Aquí..

El acceso a archivos WebUI también ha cambiado. Desafortunadamente, las cuentas de usuario que puede haber establecido en la versión antigua de ficheros WebUI, puede ser necesario ser recreado. OTOH el nuevo WebUI utiliza usuarios de Samba, por lo que los usuarios existentes pueden utilizarlo automáticamente con su cuenta y contraseña existente.

MediaWiki

A partir de v14.2 MediaWiki se instala directamente de los desarrolladores (en lugar de un paquete Debian). Se documentan las instrucciones para la migración de v14.1 a v14.2. No hay instrucciones confirmadas para versiones anteriores, sin embargo debe ser muy similar.