Nota: (final de 2024) Esta página de documentos é muito datada, mas ainda deve ter algum valor - particularmente se migrar um backup TKLBAM para uma versão TurnKey significativamente mais recente.

Por favor, veja o Documentos TKLBAM para informações mais gerais e atualizadas sobre TKLBAM. Veja obter suporte página para opções e informações se você precisar de suporte mais personalizado e atual.

Houve algumas mudanças significativas no Debian Jessie (que TurnKey Linux v14.x é baseado em) de versões anteriores. Esta página tem como objetivo fornecer uma visão geral e algumas informações sobre alguns problemas comuns. Não é exaustiva e você pode muito bem encontrar outros problemas.

Se você tem coisas estranhas acontecer depois de migrar de uma versão anterior do TKL para v14.x, então por favor, post no fóruns de suporte e alguém estará junto para tentar ajudar ASAP. Também se você for um Hub utilizador (ou Mercado AWS assinante) então, por favor, também sinta-se livre para experimentar o nosso portal de suporte (acessível quando conectado no Hub).

Sugere-se que você leia esta página inteira antes de começar. Fluxo de Trabalho Sugerido ou Migração semi-manual/estágio TKLBAMDe qualquer forma, você provavelmente ainda precisa fazer alguns Ajustes manuais para Software Específico.

Fluxo de trabalho de migração sugerido

Sugere-se que você migrar de versões mais antigas (pré v14.x) de TurnKey em um processo encenado, algo como isto:

Observe os pontos específicos detalhados para o fundo desta página.
Auditoria restaurada dados em novo servidor - verifique o que está funcionando e o que não está.
Resolver problemas observados na sua auditoria, documentando à medida que vai.
Faça a migração final.

1. Restauração inicial e auditoria

Recomenda-se que você não toque no seu servidor de produção (de onde vem o seu backup) até que a migração esteja completa e você esteja 100% satisfeito.

Primeiro verifique se o seu backup mais recente é bastante recente. Assumindo que você não tenha feito nenhuma alteração significativa no seu appliance no último mês ou assim; um backup dentro desse prazo deve ser adequado para nossos propósitos iniciais. Então restaure seus dados em um servidor de teste despotável (por exemplo, uma VM local ou um servidor AWS novo, etc) e faça uma auditoria completa. Tome cuidado com o que está funcionando e o que não está. Uma vez que você tenha a auditoria completa, tomar algum tempo para fazer alguma pesquisa sobre qualquer coisa que você não está familiarizado com.

Ao procurar por documentação/enviar para questões específicas, geralmente o Google é seu amigo. Tenha em mente que sob o capô TurnKey é construído em Debian, então geralmente coisas que se aplicam ao Debian, também se aplica ao TurnKey. v14.x é baseado em Debian Jessie aka Debian 8.

Por favor, note que quando appliances incluir software que é instalado a partir de upstream (por exemplo. TurnKey instala WordPress diretamente do próprio WordPress) que geralmente, todo o aplicativo está incluído em seu backup. Então, se você migrar seu site v13.0 WordPress (vamos fingir que ele está rodando WordPress v3.2) para um v14.2 WordPress appliance, você ainda estará rodando a versão antiga do software. Em outras palavras, mesmo que TurnKey v14.2 vem com WordPress v4.4, seu site antigo 3.2 irá sobrescrevê-lo.

Como a maioria de nossos appliances são baseados em LAMP, estou usando PHP como um exemplo, mas isso geralmente se aplica a outros softwares também. Se você está vindo de v13.x, e não atualizou ativamente o software, a maioria das aplicações PHP em execução em v13.x ainda deve funcionar ok como a diferença entre PHP em v13.x o nbx(phPv5.4) e o nbx14.x (phPv5.6) não são muito significativos. No entanto, há uma chance de que o software mais velho que correu bem em v13.x pode ser um pouco de falha em v14.x, ou talvez não funcionar em tudo.

Se o software que você está usando, não é suportado corretamente na versão mais recente do PHP (ou qualquer idioma/plataforma) então você também pode precisar atualizar o próprio software (por exemplo. WordPress). Mesmo que você não precise, você pode desejar atualizar para uma versão mais recente. As versões mais recentes frequentemente incluem novos recursos e correções de segurança em andamento.

Se você está atualizando software de terceiros a partir de upstream, a primeira coisa a fazer é ler os documentos. Projetos (quase) sempre fornecem instruções de migração ou scripts de uma versão para outra. Antes de fazer qualquer coisa vale a pena ler qualquer documentação relevante que possa encontrar. A menos que você esteja experimentando problemas durante sua auditoria, geralmente eu recomendo que você faça atualizar software de terceiros um passo adicional mais tarde, em vez de lidar com isso agora...

2. Trabalhar através de questões encontradas durante a auditoria

Considere esta execução inicial puramente um teste. Dessa forma, você pode ser destemido em seu ajuste. Se você fizer algo pior, ou as coisas ficarem bagunçadas (por exemplo. tentativa e erro sem resolução limpa) então você pode simplesmente destruir o seu servidor de teste e começar novamente com uma nova restauração (para um novo servidor se você quebrou coisas demais).

Certifique-se de documentar tudo o que faz; especialmente as coisas que funcionam. Tente focar-se em um problema de cada vez e continue trabalhando até que cada solução esteja completa. Se você acabar começando uma nova, quaisquer problemas independentes que você já tenha resolvido completamente (que não têm consequências para outras questões), não precisa ser reaplicado neste Qualquer problema que você tenha parcialmente resolvido, ou que precise ser refeito (para revelar outros problemas que você ainda precisa abordar) pode ser refeito usando seus documentos como referência.

3. Migração final

Você trabalhou em todos os problemas descobertos na sua auditoria e documentou a resolução deles. Voltar ao servidor de produção, quando for relevante e possível; coloque-o em "modo de manutenção" ou de outra forma bloqueá-lo (assim nenhum novo conteúdo é adicionado). Em seguida, execute um backup final.

Restaure seu novo backup para um novo servidor. Siga seus documentos para completar a migração, de modo que tudo esteja funcionando bem. Retire-o do "modo manutenção" (etc).

Uma vez que você está 100% feliz, em seguida, faça qualquer ajuste final (por exemplo, configurar DNS para mapear para a nova máquina etc) para colocá-lo em produção e fazer um backup TKLBAM completo do seu novo servidor:

tklbam-backup --full-backup now

Quando estiver pronto, poderá destruir o servidor antigo. Lembre- se que alguns gostam de deixar o servidor antigo a correr por algum tempo, por precaução. Também é recomendado que antes de destruir o servidor; dentro do Hub definir " backups máximos" para 1 e forçar um backup final completo. Isso irá limpar todos os backups anteriores e deixá-lo com um backup legado final para fins de arquivo/histórico.

Migração semi- manual/estágio TKLBAM

Se você tem uma idéia de onde os arquivos importantes que você precisa restaurar estão localizados, uma boa alternativa é uma restauração manual (ou semi-manual). Isso pode curto-circuito coisas e significa menos trabalho a longo prazo. É ideal para migrar de servidores muito antigos, ou altamente personalizado ou particularmente complexas configurações. No entanto, TKLBAM ainda pode ser uma maneira muito útil de transferir seus dados para o novo servidor e tornar o processo semi-manual, em vez de totalmente manual. Ainda é aconselhável seguir um fluxo de trabalho um pouco semelhante ao que é observado acima.

Em vez de fazer uma restauração completa, no entanto, apenas fazer um download e descarte:

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

Utilização tklbam-restore, você pode continuar a restaurar partes específicas do seu backup usando o --limits= mudar. Por exemplo, para restaurar toda a /var/www/ e é conteúdo, mais um banco de dados MySQL chamado 'DATABASE_1', mas sem pacotes, você poderia usar esta linha:

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

Alternativamente, para pular pacotes e restaurar tudo, exceto /etc (e é conteúdo) e /boot (e é conteúdo), use esta linha:

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

Por favor, veja o Página do man do tklbam- restabelecimento para mais informações.

Se partires alguma coisa, podes voltar com tklbam- restabelecimento- rollback. Por favor, note que TKLBAM só armazena um rollback. Então, pode ser melhor tentar restaurar tudo que você precisa / quer de uma só vez. Uma boa opção pode ser iniciar manualmente fazendo backups TKLBAM deste novo servidor em cada etapa do processo.

Você também pode restaurar manualmente os arquivos da pasta /tklbam-dump, se desejar. Os arquivos baixados devem estar em locais que são relativos à pasta de download. Por exemplo. arquivos que vêm de /var/www deve ser encontrado em /tklbam-dump/var/www. Por favor, note que, por padrão, as permissões não serão preservadas quando mover manualmente os arquivos, assim que os ajustes de permissão podem ser necessários.

De qualquer forma, você ainda vai precisar decidir o que mover e o que não fazer, mas isso pode tornar uma migração manual um pouco mais fácil. Seria certamente mais fácil do que ter de fazer uma migração manual completa!

Software específico

Webmin (todos appliances)

A partir do v14.0 Webmin está agora escondido atrás do atordoamento. Isto significa que se você restaurar de uma versão anterior, você precisará fazer algumas alterações antes que o Webmin funcione novamente. No arquivo de configuração do servidor Webmin (/etc/webmin/miniserv.conf) certifique-se de que você tem estes itens (adicione-os ou altere-os conforme apropriado):

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

Verifique também se a configuração do atordoamento (/etc/stunnel/stunnel.conf) tem isto (provavelmente bem no final):

[webmin]
accept  = 12321
connect = 127.0.0.1:10000

Se você configurou certificados SSL para Webmin (e/ou Webshell), então provavelmente você também precisará configurar o atordoamento para usá-los em seu lugar. Por exemplo. ajustar as linhas em /etc/stunnel/stunnel.conf que diz isto:

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

Apache (inc LAMP e cerca de 70% da biblioteca)

A configuração Apache teve algumas mudanças significativas, embora a que irá quebrar as coisas esteja realmente relacionada com TurnKey. Nós endurecemos o SSL em v14.0 e movemos o local do certificado padrão. Nós também incluímos todos os SSL/TLS adicionais juntos (em /etc/apache2/mods-available/ssl.conf).

A maneira mais fácil de evitar o problema mais significativo, é excluir o arquivo ssl.conf do Apache da sua restauração. Você pode fazer isso assim:

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

Se você tem um certificado CA de terceiros, então isso não deve afetá-lo (embora você possa mover o seu certificado se desejar). Se você estiver usando certificados auto assinados, então simplesmente remover referência ao certificado antigo de seus arquivos de site de vhost Apache (em /etc/apache2/sites-available) deve fazer o truque. Por exemplo. aqui está a atualização em ação sobre o Trac appliance.

Há outras alterações que também devem ser feitas (embora Apache ainda deve funcionar sem elas). Veja os links abaixo para mais informações.

Mais informações:

Documentos Apache: https://httpd.apache.org/docs/2.4/upgrading.html
Grande post sobre o Oceano Digital: https://www.digitalocean.com/community/tutorials/migrating-your-apache-c...

MySQL

Nada de significativo deveria ter mudado em relação ao MySQL, de modo que esperava que a maioria dos usuários estaria bem. erro no PHPMyAdmin, mudamos para o peso mais leve MySQL web UI; Administrador.

Você pode continuar com o PHPMyAdmin se preferir, mas você precisará desativar o Administrador e ajustar o PHPMyAdmin para usar um diretório sub. E se acostumar a usar o PHPMyAdmin de https://YOUR_DOMAIN.COM/phpmyadmin (ou seja, como subdiretório do seu site, em vez de através de uma porta específica).

Além disso (eu não acho que está relacionado, mas não tenho certeza) alguns usuários relataram que sua senha MySQL root não funciona após a restauração. Isso pode ser facilmente reposto ao executar novamente o inithook MySQL:

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

Servidor de arquivos

Samba passou de v3.x em todas as versões anteriores do TKL para v4.1/v4.2 no v14.x então novamente algumas mudanças significativas. Um membro da comunidade que ajuda a resolver os principais problemas e postou um esboço claro nos fóruns Aqui.

O acesso ao arquivo WebUI também mudou. Infelizmente, contas de usuário que você pode ter configurado na versão antiga do servidor de arquivos WebUI, pode precisar ser recriado. OTOH o novo WebUI usa usuários Samba, para que os usuários existentes possam usá-lo automaticamente com sua conta e senha existentes.

MediaWiki

A partir do v14.2 MediaWiki é instalado diretamente dos desenvolvedores (em vez de um pacote Debian). Instruções para migrar de v14.1 a v14.2Não há instruções confirmadas para versões anteriores, no entanto, deve ser muito semelhante.