注意: (late 2024) このドキュメントページは、非常に日付が付けられますが、まだいくつかの値を持っている必要があります - 特にTKLBAMバックアップをかなり新しいTurnKeyバージョンに移行する場合。

是非ご覧ください。 TKLBAM ドキュメント一般的なTKLBAM情報と最新のTKLBAM情報については、こちらをご覧ください。サポートを受けるより調整された、現在のサポートが必要な場合は、オプションと情報のページ。

以前のバージョンからDebian Jessie(TurnKey Linux v14.xがベースになっているもの)には、いくつかの重要な変更がありました。このページでは、一般的な概要と一般的な問題のカップルに関するいくつかの情報を提供することを目指しています。それは疲れではなく、あなたは他の問題に遭遇するかもしれません。

以前のバージョンのTKLからv14.xに移行した後に奇妙なことが起こる場合は、投稿してくださいフォーラムのサポート誰かがASAPを助けるために努力するために一緒にいるでしょう。また、あなたがハブユーザ(または) AWSマーケットプレイス加入者) それからまた私達のサポートポータルを(ハブに記録されるときアクセス可能)試すこと自由に感じて下さい。

このページ全体で読み始める前に、このページを読んでいることをお勧めします。それからどちらかがフォローする提案ワークフローまたは半マニュアル/タグ付きTKLBAMマイグレーション. どちらの方法でも、まだいくつか作る必要があります特定のソフトウェアのための手動調節.

移行ワークフローを提案

段階的なプロセスでTurnKeyの古い(pre v14.x)バージョンから移行するのが推奨されます。

このページの下部に、特定のポイントを詳しく記載してください。
新規サーバーで復元されたデータを監査 - 動作しているものと、何が動作していないかを確認します。
監査に指摘した問題の解決、あなたが行くように文書化します。
最終移行を行います。

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) はあまり重要ではありません。しかし、v13.x 上でうまく実行される古いソフトウェアは v14.x 上で少しグリッチになる可能性があり、またはまったく動作しない可能性があります。

ご使用のソフトウェアが PHP の新バージョン(または言語/プラットフォーム)で正しくサポートされていない場合、ソフトウェア自体をアップグレードする必要があります(例: WordPress)。必要がなくても、新しいバージョンに更新したい場合があります。新しいバージョンには、新しい機能、継続的なセキュリティ修正が頻繁に含まれています。

サードパーティソフトウェアを上流から更新している場合は、まず最初に行うことは、ドキュメントを読み込みます。プロジェクト(ほぼ)は、マイグレーションの指示やスクリプトを1つのバージョンから別のバージョンに常に提供します。関連する文書を読んで価値のあるものをする前に、見つけることができます。監査中に問題が発生している場合を除き、一般的に、サードパーティソフトウェアを後で追加ステップアップさせることをお勧めします。

2. 監査中に見つかった問題による作業

この初期の実行は純粋にテストを考えてください。あなたの微調整で恐れることができる方法。何か悪いこと、または物事が混乱する(例えば) 試験とエラーをクリーンな解像度なしで)、テストサーバーをゴミ箱にし、新しい復元(壊れたものもあれば、新しいサーバーへ)で再び起動できます。

必要なことを文書化してください。特に作業する作業です。一度に1つの問題に集中して、各ソリューションが完成するまで作業を続けます。新しく始めたばかりのとき、独立の問題が完全に解決済み(他の問題に結果がない場合)、この問題に再適用する必要はありません。点。部分的に解決した問題、または再発行する必要があります(まだアドレスを要求する他の問題が明らかになる)。参照としてあなたの文書を使用して再発行することができます。

3. 最終移行

監査に未発見されたすべての問題を通して、その解決を文書化しました。関連する、可能なプロダクションサーバーに戻り、 "メンテナンスモード" に置いたり、ロックしたり(新しいコンテンツが追加されていない)。最後のバックアップを実行します。

新しく新しいサーバーに新しいバックアップを復元します。ドキュメントに従って、すべてのものがうまく機能しているので、移行を完了してください。「メンテナンスモード」(など)から取り出します。

100% 満足したら、最終的な調整を行います(例えば、DNS を新しいマシンにマップするように設定します)、生産にそれを置くと、新しいサーバーの完全な TKLBAM バックアップを行います。

tklbam-backup --full-backup now

古いサーバーを破壊できる準備ができたら、しばらくの間、古いサーバーを少し残したいのは、念のためです。また、サーバーを破壊する前に、ハブ内で「最大バックアップ」を1に設定し、最終バックアップを強制的に行うことを推奨します。これにより、以前のすべてのバックアップが消去され、アーカイブ/歴史的目的のために最終的なレガシーバックアップであなたを残します。

TKLBAM 半マニュアル/ステージングマイグレーション

あなたが復元する必要がある重要なファイルが配置されているのは少しのアイデアを持っている場合、良い代替はマニュアル(または半マニュアル)復元です。これは、短絡の事態を短くし、長期的に作業することを意味します。非常に古いサーバーから移行したり、多重にカスタマイズしたり、特に複雑なセットアップをしたりするのに理想的です。しかし、TKLBAMは、データを新しいサーバーに転送し、プロセスの半マニュアルを完全にマニュアルではなく、プロセスを半マニュアルにすることができます。どんなワークフローにも似たようなワークフローを追随するのは、まだお勧めです。上記に記した.

しかし、完全な復元を行う代わりに、ダウンロードとダンプを行います。

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

利用方法 tklbam-restoreバックアップの特定の部分を引き続き復元できます。 --limits= スイッチ。例えば、すべてのものを元通りにするために /var/www/ と、MySQL データベースの「DATABASE_1」と、パッケージは使用できません。

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

あるいは、パッケージをスキップし、すべてのものを復元する /etc (内容です) /boot (内容です)、この行を使用します。

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

是非ご覧ください。 tklbam-restoreマンページ詳しくは、

何かを壊すと、ロールバックできます。 tklbam-restore-rollback(tklbam-restore-rollback)のリリース. TKLBAMは1つのロールバックしか保存されていないので注意してください。そのため、必要な全てのものを1つに復元しようと最善の方法です。プロセスの各ステップで、この新しいサーバーの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

また、stunnel config (/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 (LAMP とライブラリの約 70% を組み込む)

Apache config は、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の証明書を持っている場合は、これはあなたに影響を与えるべきではありません(あなたが望むならば、あなたの証明書を移動することができますが)。自己署名されたcertsを使用している場合は、Apacheホストサイトファイルから古い証明書を参照するだけです(/etc/apache2/sites-available)では、トリックを行う必要があります。例) ここでは、アクションのアップデートですトレイクアプライアンス.

おそらく作るべきこと(Apacheはまだそれらなしで動作するべきが)他の変更もあります。詳細については、以下のリンクを参照してください。

詳細情報:

Apache ドキュメント: 寸法: https://httpd.apache.org/docs/2.4/upgrading.html
デジタルオーシャンの素晴らしい投稿: 寸法: https://www.digitalocean.com/community/tutorials/migrating-your-apache-c...

名称: MySQL

重要性はMySQLに関して変更されるべきではありませんので、ユーザーの過半数がうまくなると予想されます。ただし、 PHPMyAdmin のバグ、私達はより軽い重量MySQLの網UIに転換しました; 管理者.

好みの場合には、PHPMyAdmin を続行しておくことができますが、Adminer と tweak PHPMyAdmin を無効化してサブディレクトリを使用する必要があります。そして、PHPMyAdmin をから使用するために使用しました。寸法: https://YOUR_DOMAIN.COM/phpmyadmin (特定のポートではなく、サイトのサブディレクトリとして)

また(関連ではないと思いますが、確かにそうではない)一部のユーザーは、MySQLのrootパスワードが投稿復元を動作させないと報告しています。つまり、MySQLのinithookを再実行することで簡単にリセットできます。

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

ファイルサーバ

Samba は、以前のバージョンの TKL から v4.1/v4.2 まで v14.x からなくなってしまったので、かなりの変更がいくつかありました。コミュニティメンバーは、メインの問題を解決し、フォーラムで明確なアウトラインを掲示しました詳しくはこちら.

WebUIにアクセスするファイルも変更しました。残念ながら、古いバージョンのファイルサーバーWebUIで設定したユーザーアカウントは再作成する必要があるかもしれません。新規のWebUIはSambaユーザーを使用するので、既存のユーザーは既存のアカウントとパスワードで自動的に使用できます。

メディアウィキ

開発者(Debianパッケージよりもむしろ)から直接MediaWikiをインストールします。 v14.1からv14.2への移行に関する手順は文書化されています. 以前のバージョンの記載が確認されていないが、とても似ているはずです。