開始
最新のUTMソリューションの人気は、主にその多機能性に関連しています。企業のすべてのITタスクを迅速に解決する機能は、1つのWebインターフェイスからでも、多くのシステム管理者を魅了します。
当社のソリューションである インターネット制御サーバーもUTM製品のクラスに属しており、ネットワーク保護、インターネット接続管理、コンテンツフィルタリングなどの機能を組み合わせています。
明らかな利点にもかかわらず、そのようなソリューションを使用することには欠点があります-それらはしばしばモノリシックであり、より柔軟な方法で市場の変化に対応することを可能にしません。
この観点から、より興味深い製品はUTMゲートウェイです。これは、会社の実際のタスクに基づいて、ユーザー自身が構築できます。
この場合、システム管理者はコンポーネントの「ビルディングブロック」からゲートウェイを構築し、必要なモジュールのみをインストールします。すべてのツールは開発者のクラウドにあり、ユーザーは必要なパッケージをダウンロードしてインストールします。この原則は、私たちの将来の発展の基本となっています。
歴史的なFreeBSDエコシステムは素晴らしく、よく理解されていました。パッケージを配布するための最も適切な方法として、従来のFreeBSDパッケージインストーラーpkgを選択しました。リポジトリはクラウドに収集され、リポジトリへのアクセスはクライアントの従来のpkgconfigで規定されています。
何をするつもりでしたか
システムは、コンポーネントが張られているコアの形のコンストラクターである必要があります。ユーザーは、最低限必要なプラグイン（ルーター、フィアウォールなど）のみを含む配布キットを受け取ります。残りは必要に応じてインストールされます。
システムを機能させるには、次のコンポーネントを実装する必要がありました。
- システム-変更されたFreeBSDカーネル
- コア-製品の設定で特殊なパッケージ、すべてのプラグインの親依存性があります
- プラグイン-それぞれは、pkgユーティリティを使用して通常の方法でインストールされるコンパイル済みパッケージです
プラグインの構造
前述のように、プラグインは通常のパッケージです。pkgユーティリティを使用してインストールできます。
下位互換性を維持するために、プラグインの新しいメジャーバージョンは、以前のメジャーバージョンとは関係のない別のパッケージになることが決定されました。たとえば、 plugin-v1と plugin-v2です。その理由は、それらが完全に異なる依存関係を持っている可能性があり、おそらく互いに矛盾している可能性があるためです。
マイナーバージョンは、パッケージのバージョン番号を変更するだけです。ここではすべてが通常どおりです。
プラグインの操作
システムが必要に応じて機能するために、pkgの上にアドオンユーティリティが作成されました。
仕事のための主要なツールになります PKGクエリおよび PKG rqueryコマンド。
1つ目はシステムにインストールされているプラグインに関する情報を収集し、2つ目はリポジトリにアクセスします。
ユーティリティがシステム内のコマンドの正しい実行を制御するために、各コマンドの実行で戻りコードがチェックされます。戻りコード0を受け取った場合はコマンドが実行され、それ以外の場合はエラーが発生しました。したがって、たとえば、ネットワーク接続の問題を追跡できます。
ここで興味深いニュアンスが生まれました。たとえば、すべてのパッケージをパターンで検索すると
、パターン条件に一致するインストール済みパッケージがない場合、エラーメッセージなしでエラー69が返されます。ユーティリティの開発者は、検索で何も返されない場合、これは異常な動作であると考えました。まぁ、いいよ。私はそのような場合を特別な方法で処理しなければなりませんでした。
更新の問題
次に、プラグインを更新するときにバージョン管理の問題が始まります。
まず、pkgユーティリティはpkg upgrade <pkg_name>コマンドを実行すると、 すべての直接パッケージ依存関係も更新します。この動作は開発者によって設計されています。ただし、この場合、マイナーバージョンがリリースされている場合、これには更新とコアが含まれます。これは、コアがシステムパラメータを変更し、更新後にシステムを再起動する必要があるため、望ましくありません。
つまり、すでにSP2（pkg-1および pkg-2）をインストールしていて 、pkg-1に依存している 場合は、コマンドを実行するとpkg-2が設定され ます。 pkg upgrade pkg-1、次にpkg-2もアップグレードされ ます。
逆に行きましょう。
パッケージの依存関係ツリーを上下に構築してみましょう。
パッケージが依存するすべてのパッケージの名前を検索します
。pkgrquery％rn <pkg_name>
ここで、パッケージに依存するすべてのパッケージ：
pkg rquery％dn <pkg_name>
パッケージに依存するすべてのエンティティを削除しましょう。次に、コアに自分自身が見つかるまで、パッケージがツリーに依存しているエンティティの削除を開始します（もちろん削除しません）。すべてのパッケージの最新のマイナーバージョンをインストールすることで、ツリーを復元できるようになりました。
たとえば、上の図では、ics-plugin-a-v1パッケージがics-plugin-b-v1プラグインに依存している ことがわかり ます。パッケージをics-plugin-v2バージョンに更新する必要がある場合は 、ics-plugin-b-v1パッケージの更新も必要になります 。これには2つのメジャーバージョン（ ics-plugin-b-v2と ics-plugin）があります。 -b-v3。ただし、それらのいずれもics-plugin-c-v1プラグインをサポートしていません 。つまり、更新プログラムは最初にics-plugin-b-v2または -v3パッケージをインストールし 、次にics-plugin-a-v1をインストールします。 そして、 ICS-プラグイン-cはアンインストールしてインストールされていないされます。
さらに、コアにはメジャーバージョンがある場合があります。その場合、プラグインのセット全体を更新して一致させる必要があります。 ics-core-v2に依存
するics-plugin-aパッケージをインストールするには、 ics- coreを更新する必要があります。その後、ics-core-v2に依存する主要なパッケージのみがインストールされ ます。
データベースのバックアップ
リポジトリを操作しているときに、更新中に接続が失われる（システムエラーコード70または3が発生する）状況が発生する可能性があります。さらに、プラグインを正しくアンインストールするために、システムはシステム上に有効なpkgベースを必要とします。pkg updateコマンドを実行するときに、 接続がない場合、ベースはエラーを報告し、更新が正しく完了するまでローカルでもその機能を実行しません。
このような状況を回避するために、pkgバックアップユーティリティを使用します 。目的の結果が得られない可能性がある操作の前に、データベースを保存します
。pkgbackup -d <backup_dir>
操作が正しく完了しなかった 場合は、データベースを元の場所に戻します
。pkgbackup -r <backup_dir>
芯
これまでのところ、すべてが非常に単純です。カーネルの更新がある場合は、次のようにします。
- アーカイブ内の新しいカーネルイメージをダウンロードします
- zfsで新しいデータセットを作成する
- データセットをシステムにマウントします
- 画像を解凍します
- 通常の操作に必要なカーネルオプションを含む特別なパッケージをインストールします
- 新しいイメージを起動可能として登録します
- ???
利益？
未だに。
ユーザーが以前にインストールしたシステムプラグインを復元する必要があります（もちろん、新しいカーネルでサポートされている場合）。したがって、カーネルバージョンごとに個別のプラグインリポジトリを作成する必要があります。
しかし（いつものように）ニュアンスがあります。
将来のバージョンのカーネルはまだインストールされておらず、別のバージョンのプラグインをインストールすることはできません。新しいイメージからシステムを起動すると、リポジトリにアクセスできなくなります（歴史的および技術的な理由から、ルーティングもプラグインです）。
何をすべきか？
apiを使用してサーバーを起動します。これにより、指定されたカーネルバージョンのプラグインリポジトリを使用してアーカイブが提供されます。
次に、ユーティリティは、解凍されたアーカイブのあるフォルダーへのパスを含むリポジトリ構成ファイルを生成します。
FreeBSDの場合、これは/ usr / local / etc / reposまたは / etc / reposにある <repo_name> .confファイルになります 。ここで、パスが次のように記述されていることに注意してください 。url：“ file：/// path_to_repo”（ 3つのスラッシュ！） インストールされたプラグインに関するデータを保存し、カーネルの将来のバージョンとの互換性を確認します（互換性のないプラグインがある場合） 、ユーザーに通知します）。 これで再起動できます。
最後のもの
Pkgは、システムのアップグレード後に初期化（ブートストラップ）する必要があります。したがって、コマンドを実行すると、そのコマンドの入力を求められます。私たちの場合、バインディングユーティリティはそれが必要であることを理解せず、操作が正しく実行されなかったと見なします。
これを行うために、初期化エラーハンドラーを作成しました。幸い、別のシステム操作コード1があります。したがって、ユーティリティがこのようなコードを検出すると、
pkg -y
Pkgを実行するだけで ブートストラップが作成され、通常どおりに作業できます。
合計
これが私たちがリポジトリを構築した方法です。これはプロトタイプであり、将来的には変更されてより複雑になる可能性がありますが、設計ベースは確立されており、変更されません。
記載されている技術は、インターネット制御サーバーの新しい開発に適用され、企業の企業ネットワークでの使用にさらに便利になります。リンクからICSの最新バージョンをダウンロードしてテストできます 。
試用期間、9ユーザー向けの無料バージョン、オンラインデモ、対応するテクニカルサポート。
ニュースに従って、私たちと一緒にいてください！