TKL アプライアンスでアプリXYZをアップグレードする方法[Linux newbsの場合]

...進捗中の作業...私はもともとこのシンプルで簡単に新しいために読みやすくするために設定しましたが、それは意図よりもはるかにフルになりました...フィードバック歓迎。

パッケージ管理(apt)でアプリをインストールする際の情報は、こちらを参照してください。 詳しくはこちら.

これは、インストールまたはアップグレード/更新したい個々のアプリの特定の回答を必要とするであろうトリッキーな質問です。 残念ながら、この「ハウツー」のスコープを超えて、その部分に追加の作業が必要になります。 幸運なことに、手動でインストールまたはアップグレード/更新パスが、以前のTKLコミュニティメンバーによって文書化されていること(フォーラム - 右上の隅を検索する)、そうでなければ、 是非、ご視聴ください。 このページには、TKLコアのdevs、彼らがそれをそのようにした理由の合理性、およびあなたが取る必要がある一般的な手順の解説が含まれています TKL アプライアンス に、indivdual アプリをインストールまたはアップグレード/更新します。

はじめる前に

現在のTKL アプライアンスバージョン(v11.3を書いている時に)から始めることを強くお勧めします。また、各ステップを詳しく説明することをお勧めします。 すぐに希望する結果を得なければトラブルシューティングが容易になります。 また、完了したら、コミュニティでステップバイステップのドキュメントを共有できます。オープンソースの市民がすべて使えるようにしてください。

既存のデータでアプライアンスを使わないユーザは、次のヘッディングに直進してください。 アプライアンス に現在のデータがある場合、少なくとも v11.x を使用しない場合、最初に気をつけることをお勧めします。 それから完全なバックアップをします(名称: TKLBAM うまく機能し、テスト復元をクリーンインストール(VMはこのようなタスクに便利です)にします。

一部のアプリでは、バージョンの更新/アップグレード時にデータを手動で移行する必要があります。 メジャーバージョンの更新を行う際のケースは、多くの場合、より頻繁にあります。関連するアプリのドキュメントを確認してください(できれば、ウェブサイト上になります)。 VM でアップグレードしたテスト実行をメインインスタンスの前に行うことをお勧めします。

ケースのシナリオを心配すると、TKLBAMバックアップを使用して、現在実行中のインスタンスを傷つけることなく、ゼロから再び起動できます。

主要なアプリのインストール方法

アプライアンスを作るときにコアTKLのdevsはアプリをインストールの主な方法は次のとおりです。

• パッケージ管理、または
• アップストリーム アーカイブ(多くの場合、'tarballs' と呼ばれます)。 厳密に言えば、tarballs は tar.gz (または tar.bz2) のアーカイブのみですが、 時々 開発者は zip ファイルとしてパッケージを上流 (技術的には tarball ではない) 。 このドキュメントのtarballsの目的は、提供されるすべてのアップストリームのアプリ アーカイブを参照します。
• 他の上流ソースコード。 AFAIK TKL devs は、上流バージョン管理リポジトリ(例えば SVN/Git/Mercurial/etc)から何かを一般的にインストールし、これらが頻繁に安定していないため、手動でソースコードをコンパイルすることができません。 そこで、開発者がこの手段で安定したブランチを提供しているのが、ますますます注目していますが(それも含むことを選んだ)。

パッケージ管理(公式リポジトリ)

これらのアプリは、インストールされている apt-get インストール <packagename> コマンドと(通常)は、公式のUbuntuリポジトリから来ます。 一般的に、これらのパッケージは、リリース時に同じメジャーバージョンで保持されます(つまり、Ubuntu 10.04の場合の2010年4月 - TKL v11.xの基礎)。 apt の使用に関する詳細は、 詳しくはこちら.

混乱に追加するには、公式がありますが、公式に「universe」と呼ばれるUbuntuリポジトリをサポートしていません。 このリポジトリのパッケージは、セキュリティの更新を保証するものではありません(ただし、コミュニティがパッチを提供してパッチを受け取った場合があり、MediaWikiなどの例外があります)。 また、別の公式Ubuntuリポジトリには「backports」(再び正式にサポートされていない)と呼ばれるものがあります。これは、新しいバージョンのソフトウェアが出荷されるものよりも含まれています もともと。このことは、幸せな媒体のように思えるかもしれないが、私の経験では、そこに多くの興味がほとんどありませんが、YMMV.

プロモーション

これらのアプリの主要なバージョンが更新されていないにもかかわらず、それらは全く更新されていないという意味ではありません。 一般的に、すべてのセキュリティ関連のバグは、バックポート(および時々他の深刻なバグ修正も)です。 - 'main' リポジトリのアプリにとにかく (更新は「セキュリティ」に表示されます)。 これらは、TKLの自動セキュリティ更新メカニズムを介して自動適用されます。

インストールとアップデート/アップグレードのこのプロセスは、セキュリティと安定性を最大にし、予期しない問題が発生するリスクを最小限に抑えます。 また、メンテナンスのオーバーヘッドを最小限に抑え、生産性を向上します。 アプライアンス のデータの破損やダウンタイムが非常に制限されています(明らかに、定期的なバックアップを維持するのが最善です - 念のため)。

そのため、最新バージョン(例:'show-stopper'バグや必要な機能)の本物の必要性がなければ、一般的に、これらのアプリをそのまま残すことが望ましい。 Windowsのユーザーは、Linuxに新しいことは、これは、ソフトウェアの「最新かつ最高のバージョン」に常にアップグレードする彼らの通常のプロセスに反するかもしれませんが、多くのシナリオでは、それは本当にあります おすすめ!

コンサルティング

欠点は、新しい機能はほとんど追加されず、マイナーなバグ(そして時々、大きなバグ)が対処されていないことです(TKLの次のメジャーバージョンを隠す - アプリがどこにいるか) バージョン番号は頻繁にジャンプします。 また、シンプルでセキュリティ監査ソフトウェア(ソフトウェアバージョン番号でのみチェック)は、多くの場合、偽りなく「無担保」としてアプリをリストし、事実上脆弱性を抱く それらはパッチを当てられた - すなわち偽陽性。

また、このようにインストールされたアプリは、同じ場所にあるすべての代わりに、Windows Linux newbs を余儀なくされることができます(例えば、Webルートのサブフォルダ) それらはLinuxファイルシステム(例えば、通常、設定ファイルはで見つけることができます)を通していくつかの異なる場所で普及することができます /etc/<アプリケーション名>)。TKLは、データがどこにあるかを交わすことによってこれを緩和しようとします。

パッケージ管理(第三者リポジトリ)

AFAIK TKL devs は、現在、サードパーティリポジトリからアプリを含む アプライアンス を提供していません。 利用可能な場合、サードパーティが互換性のあるアプリを含むリポジトリを提供するかどうかに行く良い方法であることができます。

時には、目的のアプリの上流のdevsが自分のリポジトリを提供するほど、あなたは幸運になります。 このリポジトリは、自社のウェブサイトでホストされているか、または、 LaunchPad で PPA (個人パッケージアーカイブ) のような場所にあるか、またはその場合もある。 場合によっては、第三者(上流のdevsに関与しない人)が自分のリポジトリ(PPAになる可能性が高いが、そうではないかもしれません)を生成する可能性がある場合があります。 個人的には、一般的に LaunchPad で良い結果を持っていましたが、ヒットして見逃すことができます。

プロモーション

第三者のリポーズは通常、公式リポーズよりもはるかに頻繁に更新されます(ただし、第三者に依存します)。 正式なリポジトリ(PPAsまたはその他)は、一般的に安全で信頼性が高く、(一般的に)アプリを更新するための最低限のfusを提供します。 これらは、公式のUbuntuのリポジトリよりもよくなる可能性があります。

コンサルティング

彼らが非公式であるならば、第三者のリポジトリは未知の品質と信頼のものになることができます。いつか、または彼らが再び更新されるかもしれないかどうかをリアルタイムに知ることはできません。

アップストリームのタルボール(および他のソース)

上記のように、上流のタルボールは、アプリをインストールするために必要なすべてのファイルを含むアーカイブです。 これらは、上流開発者によって直接提供されます。 これらは、自然の中でかなり一般的なが、通常、いくつかの種類の最低要件があります。 Webapps(Webserver eg MediaWiki で実行するアプリ)は、このように非常に一般的に提供されています。 アップストリームのタルボールにアップグレードを検討する前に、必要なすべてのものがUbuntu 10.04に簡単に満足できることを確認する必要があります。(私の経験では、この 一般的には、YMMV がメインストリームアプリの場合です。 パッケージ管理からアプリを使用する既存のTKL アプライアンスをアップグレードする場合は、削除する必要があります。 場合によっては、バニラLAMPインストール(既存のアプライアンスを更新するよりも)から始めるのが好ましいかもしれません。

プロモーション

アップストリームのタルボールは、常に最新のソフトウェアバージョンを持っており、すべての最新の機能(ならびにすべての最新のバグ :p)が含まれています。 多くの場合、上流の開発者は2つの枝を持っています:安定(これはあなたが生産のために望むものになります)と開発(これはいくつかのクールな新しい最先端機能を含むかもしれませんが、 また、未完成、またはバグを含む場合があります。バージョンコントロールリポジトリ(SVNやGitなど)を介してソースを提供する場合は、特に関連性があります。

コンサルティング

アップストリームバージョンに行くと、リリースされると、すべての将来のアップデートを手動で適用する必要があります。 そのため、「latest」と「best」を持つという考えが、メンテナンスコストやセキュリティリスクの増加を考慮する必要があるとアピールするかもしれません(セキュリティバグがない場合) 手動で、彼らはあくように迅速に対処しました。 小さなサイトでは、重要なデータとバックアップ体制が少しずつあり、セキュリティリスクの増加と、上流ソースを使用した追加のメンテナンスが一層ブレンダーになりません。 特に、前段バージョン(または1つがない場合)で発生しない新規機能が show-stopper バグや/または必要になった場合。

上記のように、正当な理由がない限り、公式のUbuntuリポジトリからバージョンに固執することをお勧めします。

TKL devs がインストールされている場所と理由は?

TKLコアのdevsがアプライアンスをリリースすると、上記の要因を考慮に入れ、あらかじめパッケージされたバージョン(利用可能な場所)または アップストリームバージョン。例えば、MediaWiki などの アプライアンス では、 devs は、あらかじめパッケージされたバージョンが有利であることに決め、その時にそれを残した。 Moodleでは、 devs は、 初期パッケージバージョン (v1.9) がかなり深刻なバグがあったため、上流からインストールすることを決めた。 新しく上流バージョン (v2.0) には、いくつかの強力な新しい 機能(Moodle以外は「universe」リポジトリでのみ利用可能 - 説明については、以下の他の考慮事項を参照してください)。 他の場合(Redmine IIRCなど)では、あらかじめパッケージされたバージョンは、それほど古いものではなく、上流を使用する多くの機能が欠けています。 何か、JoomlaのようなものはUbuntu経由でしか利用できないので、それらを提供する唯一の方法は上流を使用するだけです。