TURNKEYGNU / LINUX
中文

文档

TKLBAM: 从早期版本的TurnKey Linux迁移到v14.x

说明: (state 2024) 这个 doc 页面已经很晚的过时,但应该仍然有一定的价值：特别是如果将一个TKLBAM备份迁移到一个较新的TurnKey版本.

请看 TKLBAM 文档 用于更概括和最新的 TKLBAM 信息。请参见 获得支持 选项和信息页面,如果需要更定制和当前支持。

Debian Jessie(TurnKey Linux v14.x的根据)与之前的版本相比,已经发生了一些显著的变化. 本页旨在提供一般性概览和一些关于若干共同问题的信息,并非详尽无遗,你们很可能遇到其他问题。

如果您有奇怪的事情发生, 之后从早期版本的 TKL 迁移到 v14.x 请在 支持论坛 并且有人会一起帮助ASAP 如果你是... 枢纽 用户(或 AWS 采购站 用户请随意尝试我们的支援门户(登录到枢纽时可访问)。

建议您在开始前读完整页。 建议的工作流程 或 时间 半手工/分期TKLBAM型移徙。无论哪种方式,你可能仍然需要做一些 特定软件的手工调整.

建议的迁移工作流程

提议您在阶段性过程中从TurnKey的旧版本(pre v14.x)中迁移,类似的东西:

  1. 注意本页底部详细列出的具体点。
  2. 审计在新服务器中恢复的数据 - 检查哪些是有效的,哪些是无效的.
  3. 解决审计中注意到的问题,随你处理。
  4. 做最后的迁移。

1. 初步恢复和审计

建议您不要触摸您的制作服务器( 备份来自何处) , 直到迁移完成, 您100%满意 。

首先检查一下你最新的备份是最近才找到的 假设你上个月左右没有对应用设备做任何重大修改;从该时间范围内得到的备份应该足以满足我们的初步目的. 然后将您的数据恢复到一个可处理的测试服务器(例如本地的VM或新鲜的AWS服务器等),并进行全面审计。仔细注意哪些是有效的,哪些是无效的 。 一旦你完成了审计, 需要一些时间来做一些研究 你熟悉的任何东西。

在搜索特定问题的文件/素材时,一般Google是你的朋友. 记住在头罩TurnKey下是建在Debian上,所以一般适用于Debian的东西,也适用于TurnKey. v14.x是基于Debian Jessie aka Debian 8.

请注意,当应用设备包含从上游安装的软件时(例如. TurnKey直接从WordPress本身安装WordPress),通常,整个应用程序包含在您的备份中. 所以,如果将你的v13.0 WordPress网站(让我们假装它运行着WordPress v3.2)迁移到一个v14.2 WordPress 应用设备,那么你仍然会运行旧版的软件. 换句话说,尽管TurnKey v14.2与WordPress v4.4同时出现,但您原来的3.2站点会覆盖它.

由于我们大多数的应用设备都是基于LAMP的,我以PHP为例,但一般这也适用于其他软件. 如果您来自v13.x, 且未对软件进行激活更新, 运行于 v13.x 的 PHP 应用程序大多仍应作为 v13.x 中的 PHP 的区别而运行 。 (PHPv5.4)和v14.x(PHPv5.6)的成绩并不太大. 可能因为V13x运行的软件有些故障,

如果你使用的软件,没有在PHP(或任何语言/平台)的更新版本上得到适当的支持,那么你可能需要升级软件本身(例如. WordPress),即使不需要,你也可能希望更新到更新版本,更新版本往往包括新的功能,以及持续的安全修正.

如果你从上游更新第三方软件,首先要读取文件。 Projects(几乎)总是提供从一个版本到另一个版本的迁移指令或脚本. 在你做任何事情之前,它非常值得读 通过任何相关的文件,你可以找到。 除非你们在审计期间遇到问题,我一般建议你们以后再把更新第三方软件作为新的步骤,而不是现在处理.

2. 通过审计期间发现的问题开展工作

将这个初始运行视为纯粹的测试。 这样你就可以在调整时无所畏惧。 如果你让事情变得更糟,或者事情变得混乱(例如, 试和错误没有干净解析度),那么您就可以将测试服务器丢弃,然后重新开始一个新鲜的恢复(如果损坏太多,则重新恢复到新服务器).

确定您所做的一切,特别是工作。尝试一次集中处理一个问题,并一直工作到每个解决方案完成。 如果你最终开始一个新的,任何你已经完全解决的依赖性问题(这不会对其他问题产生影响),就不必再被重新应用了 点。任何你已经部分解决的问题,或者需要重整(以揭示你仍然需要解决的其他问题),都可以重整文件作为参考。

3. 最后移徙

你研究了审计中发现的所有问题 并记录了这些问题的解决情况 返回您的制作服务器, 视具体情况和可能; 将其放入“ 维护模式” , 或者将其锁定( 因此没有添加新内容) 。 然后运行最后备份 。

将您的新备份恢复到新的服务器。 随您的文件完成迁移, 一切都正常运行。 把它从“ 维护模式” (etc) 中取出 。

一旦你100%的快乐,那么就做任何最终的调试(例如配置 DNS 映射到新机器等),将其投入生产,并完成您新服务器的全TKLBAM备份:

tklbam-backup --full-backup now

准备好后可以摧毁旧服务器。 请注意, 一些人喜欢让旧服务器运行一段时间, 以防万一 。 还建议在摧毁服务器之前;在Hub内部将"最大备份"设置为1,并强制最终完全备份. 这将清除所有先前的备份,并留给你一个存档/历史目的最后的遗留备份。

TKLBAM 半人工/分阶段迁移

如果您有一点想法, 需要恢复的重要文件会位于何处, 一个很好的替代方案就是手动( 或半手动) 恢复 。 这可能会缩短线路,意味着长期工作减少。 这对于从非常老旧的服务器,或高度定制或特别复杂的设置迁移来说,是理想的。 然而TKLBAM仍然可以是一个非常有用的方法,可以将您的数据转移到新的服务器,使过程半手工化,而不是完全手工化. 仍宜采用与目前工作流程类似的做法。 上文指出的.

而不是完全恢复,

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

使用 tklbam-restore,您可以继续使用 --limits= 切换。例如,恢复全部 /var/www/ 并且是内容,加上一个名为"DATABASE_1"的MySQL数据库,但没有软件包,您可以使用此行:

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

或者,跳过包并恢复除 /etc (和它的内容)和 /boot (和内容),用此行:

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

请看 tklbam 重现的 man 页面 需要更多的信息 来点新的信息

如果你打破的东西,你可以滚回 tklbam 重覆滚动。请注意, TKLBAM 仅存储一个回滚。所以,最好一次尝试恢复您需要/想要的一切。 一个好的选项可能是在进程的每一步骤开始手动制作此新服务器的TKLBAM备份.

如果您愿意,也可以手动恢复 /tklbam-dump 目录中的文件。下载的文件应该位于相对于下载目录的位置。例如。 来源文件 /var/www 中查找 /tklbam-dump/var/www。请注意,默认情况下,在手动移动文件时权限将不会被保留,因此可能需要权限调整.

不管怎样,你还是需要决定什么是移动,什么是不移动,但这可能让人工迁移变得容易一些. 做一个完整的人工迁移当然容易了!

特定软件

Webmin (all 应用设备)

截止到 v14. 0 Webmin 现在隐藏在stunnel 后面。 这意味着如果您从早先的版本恢复的话, 您需要先做一些修改, 然后再Webmin 重新工作 。 在 Webmin 服务器配置文件中( /etc/webmin/miniserv.conf) 确保您有这些条目( 添加或酌情修改 ) ) :

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

还要双倍检查该突尼黑配置( /etc/stunnel/stunnel.conf) 拥有此配置( 最有可能在结尾右侧) ) :

[webmin]
accept  = 12321
connect = 127.0.0.1:10000

如果您已经配置了 Webmin (和/或 Webshell) 的 SSL 证书, 那么您也很可能还需要配置 stunnel 来代替它们使用 。 例如 。 调整 /etc/stunnel/stunnel.conf 中的线条, 表示:

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

Apache(inc LAMP和约70%的图书馆)

Apache配置有一些显著的改变,虽然将打破事物的改变实际上是TurnKey相关. 我们在 v14. 0 中加硬化 SSL 并移动默认证书位置。 我们还包含所有额外的 SSL/ TLS 配置在一起( 在 /etc/apache2/mods-available/ssl.conf). 中)

最容易避免最重大问题的方法是将 Apache 的 ssl.conf 文件排除在恢复之外。 您可以这样做 :

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

如果您有第三方 CA 证书, 则不应影响您( 尽管您需要的话, 可以移动您的证书 ) 。 如果您正在使用自签名的证书,那么只需从您的 Apache vhost 站点文件中删除旧的证书引用(在 /etc/apache2/sites-available) 中应该做这个技巧). E. 以下是当前行动的最新情况。 电车 应用设备.

还有其他一些可能应该做的修改( 尽管 Apache 仍然可以没有这些修改 ) 。 更多信息请参见下面的链接 。

更多信息 :

MySQL 密码

MySQL方面没有什么意义,因此它期望大多数用户会没事。 PHPMYAdmin 中的错误,我们已切换到轻重 MySQL网络UI; 管理员. 

如果您愿意, 欢迎继续使用 PHPMyAdmin, 但是您需要禁用管理员和微调 PHPMyAdmin 来使用子目录。 并习惯使用 PHPMYAdmin 。 https://YOUR_DOMAIN.COM/phpmyadmin 密码 (即作为您网站的子目录,而不是通过特定端口).

此外(我并不认为是相关,但不确定)一些用户报告说,他们的MySQL根密码在后恢复后没有工作. 可以通过重运行 MySQL inithook 来方便地重置:

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

文件服务器

Samba从以前所有版本的TKL中的v3.x发展到v14.x中的v4.1/v4.2,所以再次有一些显著的改变. 社区成员解决了主要问题,并在论坛上张贴了明确的纲要。 这儿.

文件访问 WebUI 也发生了变化。 不幸的是, 您可能在旧版本的文件服务器 WebUI 中设置的用户账户可能需要重新创建 。 OTOH 新的WebUI使用Samba用户,因此现有的用户可以自动使用它,同时使用他们现有的账户和密码.

媒体维基

截至v14.2 MediaWiki直接从开发者处安装(而不是Debian包). 将从v14.1迁移到v14.2的指示记录在案。。对于以前的版本,没有确认的指示,但应该非常相似。