Linux にはさまざまな顔があります: ディストリビューションでの作業方法

どのディストリビューションでも動作するバックアップ アプリケーションを作成するのは簡単な作業ではありません。 Veeam Agent for Linux が Red Hat 6 や Debian 6 から OpenSUSE 15.1 や Ubuntu 19.04 までのディストリビューションで動作することを確認するには、特にソフトウェア製品にカーネル モジュールが含まれていることを考慮して、さまざまな問題を解決する必要があります。

この記事は、カンファレンスでの講演資料を基に作成されました。 Linux ピーター 2019.

Linux は、単に最も人気のあるオペレーティング システムの XNUMX つではありません。 本質的に、これは、何かユニークなもの、独自のものを作成できるプラットフォームです。 このおかげで、Linux にはソフトウェア コンポーネントのセットが異なる多くのディストリビューションがあります。 ここで問題が発生します。ソフトウェア製品がどのディストリビューションでも機能するには、それぞれのディストリビューションの機能を考慮する必要があります。

パッケージマネージャー。 .deb と .rpm

製品をさまざまなディストリビューションに配布するという明らかな問題から始めましょう。
ソフトウェア製品を配布する最も一般的な方法は、システムに組み込まれているパッケージ マネージャーがそこからインストールできるように、パッケージをリポジトリに配置することです。
ただし、一般的なパッケージ形式が XNUMX つあります。 rpm и deb。 つまり、全員がサポートする必要があるということです。

deb パッケージの世界では、互換性のレベルは驚くべきものです。 同じパッケージは、Debian 6 と Ubuntu 19.04 の両方にインストールされ、同様に機能します。 古い Debian ディストリビューションで定められた、パッケージを構築して操作するプロセスの標準は、新しい Linux Mint および基本 OS にも引き続き関連しています。 したがって、Veeam Agent for Linux の場合、ハードウェア プラットフォームごとに XNUMX つの deb パッケージで十分です。

しかし、rpm パッケージの世界では、その違いは大きくあります。 まず、Red Hat と SUSE という 6 つの完全に独立したディストリビュータがあり、互換性はまったく必要ありません。 第二に、これらのディストリビュータは、それらのディストリビュータからの配布キットを持っています。 サポートと実験的。 それらの間の互換性も必要ありません。 el7、el8、el11 には独自のパッケージがあることが判明しました。 Fedora 用の別個のパッケージ。 SLES12 および XNUMX 用のパッケージと、openSUSE 用の別個のパッケージ。 主な問題は依存関係とパッケージ名です。

依存関係の問題

残念ながら、同じパッケージが異なるディストリビューションでは異なる名前になることがよくあります。 以下は、Veeam パッケージの依存関係の部分的なリストです。

EL7 の場合:
SLES 12の場合:

• リブキッド
• libgcc
• libstdc ++
• ncurses-libs
• ヒューズライブラリ
• ファイルライブラリ
• veeamsnap=3.0.2.1185

• libblkid1
• libgcc_s1
• のlibstdc + + 6
• libmagic1
• リブヒューズ2
• veeamsnap-kmp=3.0.2.1185

その結果、依存関係のリストはディストリビューションごとに一意になります。

さらに悪いことに、更新されたバージョンが古いパッケージ名の下に隠れ始めた場合です。

例：

パッケージは Fedora 24 で更新されました 呪う バージョン 5 からバージョン 6 へ。当社の製品は、古いディストリビューションとの互換性を確保するためにバージョン 5 で構築されました。 Fedora 5 でライブラリの古い 24 バージョンを使用するには、パッケージを使用する必要がありました。 ncurses-compat-libs.

その結果、Fedora には異なる依存関係を持つ XNUMX つのパッケージが存在します。

さらに面白い。 次回のディストリビューションの更新後、パッケージは ncurses-compat-libs ライブラリのバージョン 5 では、利用できないことが判明しました。 ディストリビュータにとって、古いライブラリを新しいバージョンのディストリビューションにドラッグするのはコストがかかります。 しばらくして、SUSE ディストリビューションでも問題が再発しました。

その結果、一部のディストリビューションは、への明示的な依存関係を削除する必要がありました。 ncurses-libsを作成し、どのバージョンのライブラリでも動作できるように製品を修正します。

ちなみに、Red Hat のバージョン 8 ではメタ パッケージがなくなりました。 パイソン、古き良きものを指しました python 2.7。 あります python2 и パイソン3.

パッケージマネージャーの代替

依存関係の問題は古くから存在しており、長い間明らかでした。 依存地獄を思い出してください。
さまざまなライブラリとアプリケーションを組み合わせて、それらがすべて安定して動作し、競合しないようにすること - 実際、これはどの Linux ディストリビュータも解決しようとしている課題です。

パッケージ マネージャーは、まったく異なる方法でこの問題を解決しようとします。 粋な カノニカルから。 主なアイデアは、アプリケーションがメイン システムから隔離され保護されたサンドボックス内で実行されることです。 アプリケーションにライブラリが必要な場合、それらはアプリケーション自体とともに提供されます。

フラットパック Linux コンテナを使用してサンドボックスでアプリケーションを実行することもできます。 サンドボックスのアイデアも活用 AppImage.

これらのソリューションを使用すると、あらゆるディストリビューションに対して XNUMX つのパッケージを作成できます。 の場合には フラットパック 管理者の知識がなくても、アプリケーションのインストールと起動が可能です。

主な問題は、すべてのアプリケーションがサンドボックスで実行できるわけではないことです。 プラットフォームに直接アクセスする必要がある人もいます。 私はカーネル モジュールについて話しているわけでもありません。カーネル モジュールはカーネルに厳密に依存しており、サンドボックスの概念には適合しません。

XNUMX 番目の問題は、エンタープライズ環境で一般的な Red Hat および SUSE のディストリビューションには、まだ Snappy および Flatpak のサポートが含まれていないことです。

この点に関して、Veeam Agent for Linux は利用できません。 snapcraft.io 全くない www.flathub.org.

パッケージ マネージャーに関する質問の締めくくりとして、バイナリ ファイルとバイナリ ファイルを XNUMX つのパッケージにインストールするスクリプトを組み合わせて、パッケージ マネージャーを完全に放棄するオプションがあることに注意してください。

このようなバンドルを使用すると、さまざまなディストリビューションやプラットフォームに対応する XNUMX つの共通パッケージを作成し、対話型のインストール プロセスを実行して、必要なカスタマイズを行うことができます。 私は VMware の Linux 用のそのようなパッケージに出会っただけです。

アップデートの問題

すべての依存関係の問題が解決されたとしても、プログラムは同じディストリビューション上で異なる動作をする可能性があります。 それはアップデートの問題です。

3 つの更新戦略があります。

• 最も簡単な方法は、更新しないことです。 サーバーを立ち上げたのに忘れてしまいました。 すべてが機能するのになぜ更新する必要があるのでしょうか? 初めてサポートに連絡したときから問題が始まります。 ディストリビューションの作成者は、更新されたリリースのみをサポートします。
• ディストリビュータを信頼して、自動アップデートを設定できます。 この場合、サポートへの電話は、アップデートが失敗した直後に行われる可能性があります。
• テスト インフラストラクチャで実行した後にのみ手動で更新するオプションが最も信頼性が高くなりますが、コストと時間がかかります。 誰もがそれを買う余裕があるわけではありません。

ユーザーごとに異なる更新戦略を使用するため、最新のリリースと以前にリリースされたすべてのリリースの両方をサポートする必要があります。 これにより、開発とテストの両方のプロセスが複雑になり、サポート チームの負担が増大します。

さまざまなハードウェア プラットフォーム

ハードウェア プラットフォームの違いは、主にネイティブ コードに特有の問題です。 少なくとも、サポートされているプラ​​ットフォームごとにバイナリを収集する必要があります。

Veeam Agent for Linux プロジェクトでは、この RISC のようなものはまだサポートできません。

この問題については詳しくは説明しません。 主な問題点のみを概説します。プラットフォームに依存するタイプ。 size_t、構造体のアライメントとバイト順序。

静的および/または動的リンク

しかし問題は、「ライブラリとどのようにリンクするか - 動的か静的か?」ということです。 議論する価値がある。

原則として、Linux 上の C/C++ アプリケーションは動的リンクを使用します。 これは、アプリケーションが特定のディストリビューション専用に構築されている場合にうまく機能します。

6 つのバイナリ ファイルでさまざまなディストリビューションをカバーすることがタスクの場合は、サポートされている最も古いディストリビューションに焦点を当てる必要があります。 私たちにとって、これは Red Hat 4.4 です。これには、C++11 標準でもサポートされていない gcc XNUMX が含まれています。 十分.

C++6.3 を完全にサポートする gcc 14 を使用してプロジェクトをビルドします。 当然のことながら、この場合、Red Hat 6 では libstdc++ および boost ライブラリを持ち運ぶ必要があります。 最も簡単な方法は、静的にリンクすることです。

しかし残念ながら、すべてのライブラリを静的にリンクできるわけではありません。

まず、次のようなシステムライブラリ リブヒューズ, リブキッド カーネルお​​よびそのモジュールとの互換性を確保するには、動的にリンクする必要があります。

第二に、ライセンスには微妙な点があります。

GPL ライセンスでは、基本的にオープンソース コードにのみライブラリをリンクできます。 MIT と BSD では静的リンクが許可され、プロジェクトにライブラリを含めることができます。 しかし、LGPL は静的リンクと矛盾していないようですが、リンクに必要なファイルを共有することを要求しています。

一般に、動的リンクを使用すると、何も指定する必要がなくなります。

C/C++ アプリケーションの構築

さまざまなプラットフォームやディストリビューション向けに C/C++ アプリケーションを構築するには、適切なバージョンの gcc を選択または構築し、特定のアーキテクチャ向けのクロスコンパイラーを使用して、ライブラリのセット全体をアセンブルするだけで十分です。 この作業はかなり実行可能ですが、かなり面倒です。 また、選択したコンパイラとライブラリが動作可能なバージョンを提供するという保証はありません。

明白な利点: ビルド プロセス全体を XNUMX 台のマシンで完了できるため、インフラストラクチャが大幅に簡素化されます。 さらに、XNUMX つのアーキテクチャに対して XNUMX セットのバイナリを収集するだけで十分であり、それらを異なるディストリビューションのパッケージにパッケージ化できます。 これは、Veeam パッケージが Veeam Agent for Linux 用に構築される方法です。

このオプションとは対照的に、ビルド ファーム、つまりアセンブリ用の複数のマシンを単純に準備することができます。 このような各マシンは、特定のディストリビューションおよび特定のアーキテクチャ向けにアプリケーションのコンパイルとパッケージのアセンブリを提供します。 この場合、配布元が用意した手段を用いてコンパイルが行われる。 つまり、コンパイラを準備してライブラリを選択する段階が不要になります。 さらに、ビルドプロセスは簡単に並列化できます。

ただし、このアプローチには欠点もあります。同じアーキテクチャ内のディストリビューションごとに、独自のバイナリ ファイルのセットを収集する必要があります。 もう XNUMX つの欠点は、非常に多数のマシンを維持する必要があり、大量のディスク領域と RAM を割り当てる必要があることです。

これは、veeamsnap カーネル モジュールの KMOD パッケージが Red Hat ディストリビューション用にコンパイルされる方法です。

オープンビルドサービス

SUSE の同僚は、アプリケーションのコンパイルとパッケージのアセンブルのための特別なサービスの形で、いくつかの中間点を実装しようとしました。 オープンビルドサービス.

基本的に、これは仮想マシンを作成し、その中に必要なすべてのパッケージをインストールし、アプリケーションをコンパイルして、この隔離された環境でパッケージを構築するハイパーバイザーであり、その後仮想マシンがリリースされます。

OpenBuildService に実装されたスケジューラは、最適なパッケージ構築速度を実現するために起動できる仮想マシンの数を決定します。 組み込みの署名メカニズムはパッケージに署名し、組み込みリポジトリにアップロードします。 組み込みのバージョン管理システムは、変更とビルドの履歴を保存します。 残っているのは、このシステムにソースを追加するだけです。 自分でサーバーをセットアップする必要さえなく、オープンなものを使用できます。

しかし、問題があります。このような収穫機は既存のインフラに適合させるのが難しいということです。 たとえば、バージョン管理は必要ありません。ソース コードにはすでに独自のものがあります。 私たちの署名メカニズムは異なります。特別なサーバーを使用します。 リポジトリも必要ありません。

さらに、他のディストリビューション (Red Hat など) のサポートがかなり不十分に実装されていますが、これは当然のことです。

このようなサービスの利点は、SUSE ディストリビューションの次のバージョンを迅速にサポートできることです。 正式なリリース発表前に、アセンブリに必要なパッケージがパブリックリポジトリに掲載されます。 新しいディストリビューションが OpenBuildService の利用可能なディストリビューションのリストに表示されます。 ボックスにチェックを入れると、ビルド計画に追加されます。 したがって、ディストリビューションの新しいバージョンの追加は、ほぼ XNUMX 回のクリックで完了します。

私たちのインフラストラクチャでは、OpenBuildService を使用して、SUSE ディストリビューション用の veeamsnap カーネル モジュールのさまざまな KMP パッケージ全体がアセンブルされています。

次に、カーネル モジュールに特有の問題について詳しく説明したいと思います。

カーネル ABI

Linux カーネル モジュールはこれまで、ソース形式で配布されてきました。 実際のところ、カーネルの作成者は、カーネル モジュールの安定した API、特に kABI と呼ばれるバイナリ レベルのサポートについて心配する必要はありません。

バニラ カーネル用のモジュールをビルドするには、この特定のカーネルのヘッ​​ダーが必ず必要であり、このヘッダーはこのカーネルでのみ機能します。

DKMS を使用すると、カーネルの更新時にモジュールを構築するプロセスを自動化できます。 その結果、Debian リポジトリ (およびそれに関連する多くのリポジトリ) のユーザーは、ディストリビュータのリポジトリから、または DKMS を使用してソースからコンパイルされたカーネル モジュールを使用します。

ただし、この状況はエンタープライズセグメントには特に適していません。 独自コードの配布者は、製品をコンパイルされたバイナリとして配布したいと考えています。

管理者は、セキュリティ上の理由から、開発ツールを運用サーバー上に保持したくないと考えています。 Red Hat や SUSE などの Enterprise Linux ディストリビュータは、ユーザーのために安定した kABI をサポートできると判断しました。 その結果、Red Hat 用の KMOD パッケージと SUSE 用の KMP パッケージが作成されました。

このソリューションの本質は非常にシンプルです。 ディストリビューションの特定のバージョンでは、カーネル API が凍結されています。 配布者は、カーネル (たとえば、3.10) を使用し、カーネル インターフェイスに影響を与えない修正と改善のみを行っており、最初のカーネル用に収集されたモジュールは、再コンパイルすることなく後続のすべてのカーネルで使用できると述べています。

Red Hat は、ディストリビューションのライフサイクル全体を通じて kABI 互換性があると主張しています。 つまり、rhel 6.0 (2010 年 6.10 月リリース) 用にアセンブルされたモジュールは、バージョン 2018 (8 年 XNUMX 月リリース) でも動作するはずです。 そして、これは約XNUMX年になります。 当然のことながら、この作業は非常に困難です。
kABI の互換性の問題が原因で veeamsnap モジュールが動作を停止したケースがいくつか記録されています。

RHEL 7.0 用にコンパイルされた veeamsnap モジュールが RHEL 7.5 のカーネルと互換性がないことが判明し、ロードされてサーバーがクラッシュすることが保証されたため、RHEL 7 での kABI 互換性の使用を完全に放棄しました。

現在、RHEL 7 の KMOD パッケージには、各リリース バージョンのアセンブリとモジュールをロードするスクリプトが含まれています。

SUSE は、kABI 互換性というタスクにさらに慎重に取り組みました。 これらは、XNUMX つのサービス パック内でのみ kABI 互換性を提供します。

たとえば、SLES 12 のリリースは 2014 年 12 月に行われました。SLES 1 SP2015 はすでに 3.12 年 XNUMX 月にリリースされており、XNUMX 年強が経過しています。 どちらのリリースも XNUMX カーネルを使用していますが、kABI には互換性がありません。 明らかに、kABI 互換性を XNUMX 年間だけ維持する方がはるかに簡単です。 カーネル モジュールの年次更新サイクルにより、モジュール作成者に問題が生じることはありません。

この SUSE ポリシーの結果、veeamsnap モジュールの kABI 互換性に関する問題は XNUMX 件も記録されていません。 確かに、SUSE のパッケージの数はほぼ XNUMX 桁多くなります。

パッチとバックポート

ディストリビュータは、kABI の互換性とカーネルの安定性を確保しようとしますが、パフォーマンスを向上させ、この安定したカーネルの欠陥を排除することにも努めます。

同時に、エンタープライズ Linux カーネルの開発者は、独自の「エラーへの対処」に加えて、バニラ カーネルの変更を監視し、それを「安定した」カーネルに転送します。

時にはそれが新たな発見につながることもある 間違い.

Red Hat 6 の最新リリースでは、マイナー アップデートの 4.19 つで間違いが発生しました。 これにより、スナップショットがリリースされたときに veeamsnap モジュールがシステムをクラッシュさせることが保証されるという事実が生じました。 アップデートの前後でカーネル ソースを比較したところ、バックポートが原因であることがわかりました。 同様の修正がバニラ カーネル バージョン 2.6.32 で行われました。 この修正はバニラ カーネルでは正常に機能しましたが、それを「安定した」XNUMX に移行すると、スピンロックで問題が発生しました。

もちろん、誰でも常にエラーは発生しますが、安定性を危険にさらしてコードを 4.19 から 2.6.32 にドラッグする価値はあったでしょうか?...よくわかりません...

最悪なのは、マーケティングが「安定」と「近代化」の綱引きに巻き込まれることだ。 マーケティング部門は、更新されたディストリビューションのコアが安定している一方で、パフォーマンスが向上し、新しい機能が備わっている必要があります。 これは奇妙な妥協につながります。

SLES 4.4 SP12 のカーネル 3 でモジュールをビルドしようとしたとき、バニラ 4.8 の機能が含まれていることに驚きました。 私の意見では、SLES 4.4 SP12 の 3 カーネルのブロック I/O 実装は、SLES4.8 SP4.4 の安定版 12 カーネルの以前のリリースよりも 2 カーネルに似ています。 コードの何パーセントが SP4.8 のカーネル 4.4 から SLES 3 に転送されたのか判断できませんが、そのカーネルを同じ安定版 4.4 と呼ぶことさえできません。

これの最も不快な点は、異なるカーネルでも同様に機能するモジュールを作成するときに、カーネルのバージョンに依存できなくなることです。 分布も考慮する必要があります。 新しい機能とともに登場する定義に参加できる場合があるのは良いことですが、その機会が常に現れるとは限りません。

その結果、コードは奇妙な条件付きコンパイル ディレクティブで肥大化してしまいます。

文書化されたカーネル API を変更するパッチもあります。
配信に行き当たりました KDEネオン 5.16 では、このカーネル バージョンの lookup_bdev 呼び出しによって入力パラメータのリストが変更されたことに非常に驚きました。

これをまとめるには、lookup_bdev 関数にマスク パラメーターがあるかどうかをチェックするスクリプトを makefile に追加する必要がありました。

カーネルモジュールへの署名

パッケージ配布の問題に戻りましょう。

安定した kABI の利点の XNUMX つは、カーネル モジュールをバイナリ ファイルとして署名できることです。 この場合、開発者は、モジュールが誤って損傷したり、意図的に変更されたりしていないことを確認できます。 これはmodinfoコマンドで確認できます。

Red Hat および SUSE ディストリビューションでは、対応する証明書がシステムに登録されている場合にのみ、モジュールの署名を確認してロードできます。 証明書は、モジュールの署名に使用される公開キーです。 別パッケージとして配布しております。

ここでの問題は、証明書がカーネルに組み込まれる (ディストリビュータが使用する) か、ユーティリティを使用して EFI 不揮発性メモリに書き込まれる必要があることです。 モクティル。 ユーティリティ モクティル 証明書をインストールするときは、システムを再起動する必要があり、オペレーティング システム カーネルをロードする前であっても、管理者に新しい証明書のロードを許可するように求めるメッセージが表示されます。

したがって、証明書を追加するには、システムへの物理的な管理者アクセスが必要です。 マシンがクラウド内のどこかに配置されているか、単にリモート サーバー ルームに配置されており、アクセスがネットワーク経由 (たとえば、SSH 経由) のみである場合、証明書を追加することはできません。

仮想マシン上の EFI

EFI はほぼすべてのマザーボード メーカーによって長い間サポートされてきたにもかかわらず、システムをインストールするときに、管理者は EFI の必要性を考慮せず、EFI を無効にすることがあります。

すべてのハイパーバイザーが EFI をサポートしているわけではありません。 VMWare vSphere はバージョン 5 以降で EFI をサポートします。
Microsoft Hyper-V も、Windows Server 2012R2 の Hyper-V から EFI サポートを取得しました。

ただし、デフォルト構成では、この機能は Linux マシンに対して無効になっており、証明書をインストールできません。

vSphere 6.5 では、オプションを設定します 安全な立ち上げ Flash 経由で実行される古いバージョンの Web インターフェイスでのみ可能です。 HTML-5 上の Web UI はまだ大幅に遅れています。

実験的な配布

最後に、実験的なディストリビューションと公式サポートのないディストリビューションの問題について考えてみましょう。 一方で、そのようなディストリビューションが本格的な組織のサーバーで見つかる可能性はほとんどありません。 このようなディストリビューションに対する公式サポートはありません。 したがって、それらを提供してください。 この製品はそのようなディストリビューションではサポートされません。

ただし、このようなディストリビューションは、新しい実験的ソリューションを試すための便利なプラットフォームになります。 たとえば、Fedora、OpenSUSE Tumbleweed、または Debian の不安定なバージョンなどです。 非常に安定しています。 彼らは常に新しいバージョンのプログラムと常に新しいカーネルを持っています。 XNUMX 年後には、この実験的な機能が更新された RHEL、SLES、または Ubuntu に組み込まれる可能性があります。

したがって、実験的なディストリビューションで何かが機能しない場合は、問題を特定して解決する必要があります。 この機能が間もなくユーザーの実稼働サーバーに追加されるという事実に備える必要があります。

バージョン 3.0 で正式にサポートされているディストリビューションの現在のリストを確認できます。 ここで。 しかし、私たちの製品が動作できるディストリビューションの実際のリストはさらに広範囲に及びます。

個人的にはElbrus OSを使った実験に興味がありました。 Veeam パッケージを完成させた後、製品がインストールされ、動作しました。 この実験についてはハブレで書きました。 статье.

新しいディストリビューションのサポートは継続します。 バージョン4.0のリリースを待っています。 ベータ版が間もなく登場するので、注目してください 新着情報!

出所： habr.com