イメージの構築と管理
1. イメージの構築の概要
SUSE Managerでは、システム管理者はコンテナおよびOSイメージを構築し、結果をイメージストアにプッシュできます。
-
イメージストアを定義します。
-
イメージプロファイルを定義し、それをソース(gitリポジトリまたはディレクトリのいずれか)に関連付けます。
-
イメージを構築します。
-
イメージをイメージストアにプッシュします。
SUSE Managerでは、2つの異なるビルドタイプ(Dockerfile、およびKiwiイメージシステム)をサポートしています。
Kiwiビルドタイプは、システムイメージ、仮想イメージ、およびその他のイメージの構築に使用されます。 Kiwiビルドタイプのイメージストアは、サーバ上の/srv/www/os-images
にあるファイルシステムディレクトリとして事前定義されています。 SUSE Managerは、//<SERVER-FQDN>/os-images/
からHTTPS経由でイメージストアを提供します。 イメージストアの場所は固有であり、カスタマイズできません。
イメージは/srv/www/os-image/ORGANIZATION-ID
に保存されます。
2. コンテナイメージ
2.1. 要件
コンテナ機能は、SUSE Linux Enterprise Server 12以降を実行しているSaltクライアントで使用できます。 開始する前に、ご使用の環境が次の要件を満たしていることを確認してください。
-
Dockerfileと設定スクリプトを含む発行済みのgitリポジトリ。 リポジトリはパブリックにもプライベートにもでき、GitHub、GitLab、またはBitBucketでホストする必要があります。
-
Dockerレジストリなどの適切に設定されたイメージストア。
コンテナの詳細については、https://documentation.suse.com/container/all/html/Container-guide/を参照してください。
2.2. 構築ホストの作成
SUSE Managerでイメージを構築するには、構築ホストを作成して設定する必要があります。 コンテナビルドホストは、SUSE Linux Enterprise 12以降を実行しているSaltクライアントです。 このセクションでは、構築ホストの初期設定について説明します。
構築ホスト上のオペレーティングシステムは、ターゲットイメージ上のオペレーティングシステムと一致する必要があります。 たとえば、SUSE Linux Enterprise Server 15 (SP2以降)のOSバージョンを実行している構築ホスト上にSUSE Linux Enterprise Server 15ベースのイメージを構築します。 SUSE Linux Enterprise Server 12 SP5またはSUSE Linux Enterprise Server 12 SP4 OSバージョンを実行している構築ホスト上にSUSE Linux Enterprise Server 12ベースのイメージを構築します。 クロスアーキテクチャビルドはサポートされていません。 |
SUSE Manager Web UIから、次のステップを実行して、構築ホストを設定します。
-
ページから、構築ホストとして指定されるSaltクライアントを選択します。
-
選択したクライアントの[
システムの詳細
]ページから、コンテナモジュールを割り当てます。 に移動して、コンテナモジュール(たとえば、[SLE-Module-Containers15-Pool
]と[SLE-Module-Containers15-Updates
])を有効にします。 サブスクリプションの変更をクリックして確定します。 -
ページから、[付属エンタイトルメント
]リストからコンテナビルドホスト
を有効にします。プロパティの更新をクリックして確定します。 -
highstate
を適用して必要なすべてのパッケージをインストールします 。 システムの詳細ページで、 を選択し、[highstate の適用
]をクリックします 。 または、SUSE Managerサーバのコマンドラインからhighstateを適用します。salt '$your_client' state.highstate
2.3. コンテナ用アクティベーションキーの作成
SUSE Managerを使用して構築されたコンテナは、イメージを構築するときに、アクティベーションキーに関連付けられたチャンネルをリポジトリとして使用します。 このセクションでは、この目的のためにアドホックアクティベーションキーを作成する方法について説明します。
コンテナを構築するには、 |
-
を選択します。
-
キーの作成をクリックします。
-
[
説明
]と[キー
]名を入力します。 ドロップダウンメニューを使用してこのキーと関連付ける[ベースチャンネル
]を選択します。 -
アクティベーションキーの作成で確定します。
詳細については、アクティベーションキーを参照してください。
2.4. イメージストアの作成
すべての構築されたイメージは、イメージストアにプッシュされます。 このセクションでは、イメージストアの作成について説明します。
-
を選択します。
-
[
作成
]をクリックして、新しいストアを作成します。 -
[
ラベル
]フィールドにイメージストアの名前を定義します。 -
コンテナレジストリホスト(内部か外部)の完全修飾ドメイン名(FQDN)として、[
URI
]フィールドに入力して、イメージレジストリへのパスを指定します。registry.example.com
レジストリURI を使用して、すでに使用されているレジストリのイメージストアを指定することもできます。
registry.example.com:5000/myregistry/myproject
-
作成をクリックして、新しいイメージストアを追加します。
2.5. イメージプロファイルの作成
すべてのコンテナイメージは、構築手順を含む、イメージプロファイルを使用して構築されます。 このセクションでは、SUSE Manager Web UIでイメージプロファイルを作成する方法について説明します。
-
イメージプロファイルを作成するには、
を選択し、作成をクリックします。 -
[
ラベル
]フィールドに入力して、イメージプロファイルの名前を指定します。コンテナイメージタグが
myproject/myimage
などの形式である場合は、イメージストアのレジストリURIに/myproject
サフィックスが含まれていることを確認します。 -
[
イメージタイプ
]としてDockerfileを使用します。 -
ドロップダウンメニューを使用して、[
ターゲットのイメージストア
]フィールドからレジストリを選択します。 -
[
パス
]フィールドに、GitHub、GitLab、またはBitBucketリポジトリのURLを入力します。URLはhttp
、https
、またはトークン認証URLである必要があります。以下の形式のいずれかを使用します。GitHubパスオプション-
GitHubシングルユーザプロジェクトリポジトリ
https://github.com/USER/project.git#branchname:folder
-
GitHub組織プロジェクトリポジトリ
https://github.com/ORG/project.git#branchname:folder
-
GitHubトークン認証
gitリポジトリがプライベートな場合、認証を含むようにプロファイルのURLを変更します。 GitHubトークンで認証するには次のURL形式を使用します。
https://USER:<AUTHENTICATION_TOKEN>@github.com/USER/project.git#master:/container/
-
GitLabシングルユーザプロジェクトリポジトリ
https://gitlab.example.com/USER/project.git#master:/container/
-
GitLabグループプロジェクトリポジトリ
https://gitlab.example.com/GROUP/project.git#master:/container/
-
GitLabトークン認証
gitリポジトリがプライベートで、パブリックにアクセスできない場合は、認証を含むようにプロファイルのgit URLを変更する必要があります。 GitLabトークンで認証するには、次のURL形式を使用します。
https://gitlab-ci-token:<AUTHENTICATION_TOKEN>@gitlab.example.com/USER/project.git#master:/container/
gitブランチを指定しない場合は、デフォルトで
master
ブランチが使用されます。folder
が指定されていない場合、イメージソース(Dockerfileソース)はGitHubまたはGitLabチェックアウトのルートディレクトリにあると想定されます。
-
-
[
アクティベーションキー
]を選択します。 アクティベーションキーは、プロファイルを使用するイメージが正しいチャンネルとパッケージに確実に割り当てられるようにします。アクティベーションキーをイメージプロファイルに関連付けると、プロファイルを使用するすべてのイメージで正しいソフトウェアチャンネルとチャンネル内のすべてのパッケージが確実に使用されるようになります。
-
作成ボタンをクリックします。
2.5.1. Dockerfileソースの例
再利用できるイメージプロファイルはhttps://github.com/SUSE/manager-build-profilesで公開されています。
例: リポジトリファイルを示す リポジトリは、イメージプロファイルに割り当てたアクティベーションキーによって決定されます。 |
FROM registry.example.com/sles12sp2 MAINTAINER Tux Administrator "tux@example.com" ### Begin: These lines Required for use with {productname} ARG repo ARG cert # Add the correct certificate RUN echo "$cert" > /etc/pki/trust/anchors/RHN-ORG-TRUSTED-SSL-CERT.pem # Update certificate trust store RUN update-ca-certificates # Add the repository path to the image RUN echo "$repo" > /etc/zypp/repos.d/susemanager:dockerbuild.repo ### End: These lines required for use with {productname} # Add the package script ADD add_packages.sh /root/add_packages.sh # Run the package script RUN /root/add_packages.sh # After building remove the repository path from image RUN rm -f /etc/zypp/repos.d/susemanager:dockerbuild.repo
2.5.2. カスタム情報のキーと値のペアをDocker buildargs
として使用する
カスタム情報のキーと値のペアを割り当てて、イメージプロファイルに情報を添付できます。 さらに、これらのキーと値のペアは、Dockerビルドコマンドにbuildargs
として渡されます。
使用可能なカスタム情報キーと追加のキーの作成に関する詳細については、カスタムシステム情報を参照してください。
2.6. イメージの構築
イメージを構築するには、2つの方法があります。 左側のナビゲーションバーから
を選択するか、 リストのビルドアイコンをクリックします。-
を選択します。
-
デフォルトの
latest
(コンテナにのみ関連する)以外のバージョンを使用する場合は、別のタグ名を追加します。 -
[
Build Profile
](ビルドプロファイル)と[構築ホスト
]を選択します。ビルドフィールドの右側にある[
プロファイル概要
]に注目します。 ビルドプロファイルを選択すると、選択したプロファイルに関する詳細情報がこの領域に表示されます。 -
ビルドをスケジュールするには、ビルドボタンをクリックします。
2.7. イメージの取り込み
任意のイメージの取り込みおよび検査が可能です。 左側のナビゲーションバーから取り込み
]ダイアログのテキストボックスに入力します。 処理が完了すると、取り込まれたイメージが[イメージリスト
]ページに一覧表示されます。
-
から、取り込みをクリックして、[イメージの取り込み
]ダイアログを開きます。 -
[
イメージの取り込み
]ダイアログで、次のフィールドに入力します。- イメージストア
-
検査のためにイメージがプルされるレジストリ。
- イメージ名
-
レジストリのイメージの名前。
- イメージバージョン
-
レジストリのイメージのバージョン。
- 構築ホスト
-
イメージをプルして検査する構築ホスト。
- アクティベーションキー
-
イメージが検査されるソフトウェアチャンネルへのパスを提供するアクティベーションキー。
-
確定するには、取り込みをクリックします。
イメージのエントリがデータベースに作成され、SUSE ManagerのInspect Image
(イメージの検査)アクションがスケジュールされます。
処理が完了すると、取り込まれたイメージがイメージリスト
に表示されます。 イメージが取り込まれたことを示す異なるアイコンが[ビルド
]列に表示されます。 取り込まれたイメージのステータスアイコンはイメージの[概要
]タブにも表示されます。
2.8. トラブルシューティング
イメージを操作する場合の既知の問題がいくつかあります。
-
レジストリまたはgitリポジトリにアクセスするためのHTTPS証明書はカスタム状態ファイルによってクライアントに配備する必要があります。
-
Dockerを使用したSSH gitアクセスは現在サポートされていません。
3. OSイメージ
OSイメージは、Kiwiイメージシステムによって構築されます。 出力イメージはカスタマイズ可能で、PXE、QCOW2、LiveCD、またはその他のタイプのイメージにすることができます。
Kiwiビルドシステムの詳細については、Kiwiのドキュメントを参照してください。
3.1. 要件
Kiwiイメージ構築機能は、SUSE Linux Enterprise Server 12およびSUSE Linux Enterprise Server 11を実行しているSaltクライアントで利用できます。
Kiwiイメージ設定ファイルおよび設定スクリプトは、以下の場所のいずれかからアクセスできる必要があります。
-
Gitリポジトリ
-
HTTPでホストされたtarball
-
ローカル構築ホストディレクトリ
gitで提供される完全なKiwiリポジトリの例については、https://github.com/SUSE/manager-build-profiles/tree/master/OSImageを参照してください。
Kiwiで構築されたOSイメージを実行しているホストには、少なくとも1GBのRAMが必要です。 ディスク容量は、イメージの実際のサイズによって異なります。 詳細については、基になるシステムのドキュメントを参照してください。 |
3.2. 構築ホストの作成
SUSE Managerであらゆる種類のイメージを構築するには、構築ホストを作成して設定します。 OSイメージ構築ホストは、SUSE Linux Enterprise Server 15 (SP2以降)またはSUSE Linux Enterprise Server 12 (SP4以降)で実行されているSaltクライアントです。
このプロシージャでは、構築ホストの初期設定について説明します。
構築ホスト上のオペレーティングシステムは、ターゲットイメージ上のオペレーティングシステムと一致する必要があります。 たとえば、SUSE Linux Enterprise Server 15 (SP2以降)のOSバージョンを実行している構築ホスト上にSUSE Linux Enterprise Server 15ベースのイメージを構築します。 SUSE Linux Enterprise Server 12 SP5またはSUSE Linux Enterprise Server 12 SP4 OSバージョンを実行している構築ホスト上にSUSE Linux Enterprise Server 12ベースのイメージを構築します。 クロスアーキテクチャビルドはできません。 たとえば、SUSE Linux Enterprise Server 15 SP3を実行しているRaspberry PI (aarch64アーキテクチャ)構築ホストにRaspberry PI SUSE Linux Enterprise Server 15 SP3を構築する必要があります。 |
-
ページから構築ホストとして指定するクライアントを選択します。
-
タブに移動して、[付属エンタイトルメント
][OS イメージビルドホスト
]を有効にします。プロパティの更新で確定します。 -
に移動し、構築ホストのバージョンに応じて必要なソフトウェアのチャンネルを有効にします。
-
SUSE Linux Enterprise Server 12構築ホストでは、SUSE Managerクライアントツール(
SLE-Manager-Tools12-Pool
とSLE-Manager-Tools12-Updates
)が必要です。 -
SUSE Linux Enterprise Server 15構築ホストでは、SUSE Linux Enterprise Serverモジュール
SLE-Module-DevTools15-SP4-Pool
とSLE-Module-DevTools15-SP4-Updates
が必要です。 -
スケジュールを設定して確認をクリックします。
-
-
highstate
を適用してKiwiと必要なすべてのパッケージをインストールします。 システムの詳細ページで、 を選択し、highstateの適用をクリックします。 または、SUSE Managerサーバのコマンドラインからhighstateを適用します。salt '$your_client' state.highstate
3.2.1. SUSE Manager Webサーバのパブリック証明書RPM
構築ホストのプロビジョニングでは、SUSE Manager証明書RPMを構築ホストにコピーします。 この証明書はSUSE Managerによって提供されるリポジトリにアクセスするために使用されます。
証明書は、mgr-package-rpm-certificate-osimage
パッケージスクリプトでRPMにパッケージ化されます。 パッケージスクリプトは新しいSUSE Managerのインストール中に自動的に呼び出されます。
spacewalk-certs-tools
パッケージをアップグレードすると、アップグレードシナリオではデフォルト値を使用してパッケージスクリプトが呼び出されます。 ただし、証明書パスが変更された場合や使用できない場合は、アップグレードプロシージャの完了後に、--ca-cert-full-path <path_to_certificate>
を使用してパッケージスクリプトを手動で呼び出します。
3.2.2. パッケージスクリプトの呼び出し例
/usr/sbin/mgr-package-rpm-certificate-osimage --ca-cert-full-path /root/ssl-build/RHN-ORG-TRUSTED-SSL-CERT
証明書を含むRPMパッケージは、次のようなsalt-accessibleディレクトリに保存されます。
/usr/share/susemanager/salt/images/rhn-org-trusted-ssl-cert-osimage-1.0-1.noarch.rpm
証明書を含むRPMパッケージは、ローカル構築ホストリポジトリで提供されます。
/var/lib/Kiwi/repo
ビルドソースに SUSE Manager SSL証明書を含むRPMパッケージを指定し、Kiwiの設定に Listing 1. config.xml
|
3.3. OSイメージ用アクティベーションキーの作成
イメージの構築時にOSイメージがリポジトリとして使用できるチャンネルに関連付けられたアクティベーションキーを作成します。
アクティベーションキーはOSイメージの構築に必須です。
OSイメージを構築するには、 |
-
Web UIで、
を選択します。 -
[
キーの作成
]をクリックします。 -
[
説明
]、[キー
]の名前を入力し、ドロップダウンボックスを使用してキーに関連付ける[ベースチャンネル
]を選択します。 -
アクティベーションキーの作成で確定します。
詳細については、アクティベーションキーを参照してください。
3.4. イメージストアの作成
OSイメージには、大量のストレージ容量が必要になる場合があります。 したがって、OSイメージストアは、ルートパーティションとは別の、独自のパーティションまたはBtrfsサブボリュームに配置することをお勧めします。 デフォルトでは、イメージストアは/srv/www/os-images
にあります。
システム、仮想、およびその他のイメージの構築に使用されるKiwiビルドタイプのイメージストアは、まだサポートされていません。 イメージは常に |
3.5. イメージプロファイルの作成
Web UIを使用してイメージプロファイルを管理します。
-
イメージプロファイルを作成するには、
から選択し、作成をクリックします。 -
[
ラベル
]フィールドに、イメージプロファイル
の名前を入力します。 -
[
イメージタイプ
]として[Kiwi
]を使用します。 -
イメージストアは自動的に選択されます。
-
Kiwi設定ファイルを含むディレクトリに[
設定URL
]を入力します。-
git URI
-
HTTPS tarball
-
構築ホストローカルディレクトリへのパス
-
-
必要に応じて[
Kiwiオプション
]を入力します。 Kiwi設定ファイルで複数のプロファイルが指定されている場合、--profile <name>
を使用してアクティブなプロファイルを選択します。 他のオプションについては、Kiwiのドキュメントを参照してください。 -
[
アクティベーションキー
]を選択します。 アクティベーションキーにより、プロファイルを使用したイメージが正しいチャンネルとパッケージに確実に割り当てられます。アクティベーションキーをイメージプロファイルに関連付け、イメージプロファイルで正しいソフトウェアチャンネルとパッケージが使用されるようにします。
-
作成ボタンで確定します。
ソースフォーマットオプション-
リポジトリへのgit/HTTP(S) URL
構築するイメージのソースを含むgitリポジトリへのURL。 リポジトリのレイアウトによって、URLは次のようになります。
https://github.com/SUSE/manager-build-profiles
URLの
#
文字の後にブランチを指定できます。 この例では、master
ブランチを使用します。https://github.com/SUSE/manager-build-profiles#master
:
文字の後のイメージソースを含むディレクトリを指定できます。 この例では、OSImage/POS_Image-JeOS6
を使用します。https://github.com/SUSE/manager-build-profiles#master:OSImage/POS_Image-JeOS6
-
tarballへのHTTP(S) URL
WebサーバでホストされているtarアーカイブへのURL (圧縮または非圧縮)。
https://myimagesourceserver.example.org/MyKiwiImage.tar.gz
-
構築ホスト上のディレクトリへのパス
Kiwiビルドシステムソースを含むディレクトリへのパスを入力します。 このディレクトリは選択した構築ホスト上に存在する必要があります。
/var/lib/Kiwi/MyKiwiImage
-
3.5.1. Kiwiソースの例
Kiwiソースは少なくとも config.xml
で構成されています 。 通常、config.sh
とimages.sh
も存在します。 ソースにはroot
サブディレクトリの下の最終イメージにインストールするファイルも含めることができます。
Kiwiビルドシステムについては、Kiwiのドキュメントを参照してください。
SUSEでは、SUSE/manager-build-profilesパブリックGitHubリポジトリで、完全に機能するイメージソースの例を提供しています。
<?xml version="1.0" encoding="utf-8"?>
<image schemaversion="6.1" name="POS_Image_JeOS6">
<description type="system">
<author>Admin User</author>
<contact>noemail@example.com</contact>
<specification>SUSE Linux Enterprise 12 SP3 JeOS</specification>
</description>
<preferences>
<version>6.0.0</version>
<packagemanager>zypper</packagemanager>
<bootsplash-theme>SLE</bootsplash-theme>
<bootloader-theme>SLE</bootloader-theme>
<locale>en_US</locale>
<keytable>us.map.gz</keytable>
<timezone>Europe/Berlin</timezone>
<hwclock>utc</hwclock>
<rpm-excludedocs>true</rpm-excludedocs>
<type boot="saltboot/suse-SLES12" bootloader="grub2" checkprebuilt="true" compressed="false" filesystem="ext3" fsmountoptions="acl" fsnocheck="true" image="pxe" kernelcmdline="quiet"></type>
</preferences>
<!-- CUSTOM REPOSITORY
<repository type="rpm-dir">
<source path="this://repo"/>
</repository>
-->
<packages type="image">
<package name="patterns-sles-Minimal"/>
<package name="aaa_base-extras"/> <!-- wouldn't be SUSE without that ;-) -->
<package name="kernel-default"/>
<package name="salt-minion"/>
...
</packages>
<packages type="bootstrap">
...
<package name="sles-release"/>
<!-- this certificate package is required to access {productname} repositories
and is provided by {productname} automatically -->
<package name="rhn-org-trusted-ssl-cert-osimage" bootinclude="true"/>
</packages>
<packages type="delete">
<package name="mtools"/>
<package name="initviocons"/>
...
</packages>
</image>
3.6. イメージの構築
Web UIを使用してイメージを構築する2つの方法があります。
を選択するか、 リストのビルドアイコンをクリックします。-
を選択します。
-
デフォルトの
latest
(コンテナのみに適用)以外のバージョンが必要な場合は別のタグ名を追加します。 -
[
イメージプロファイル
]および[構築ホスト
]を選択します。[
プロファイル概要
]がビルドフィールドの右側に表示されます。 ビルドプロファイルを選択したら、選択したプロファイルに関する詳細情報がここに表示されます。 -
ビルドをスケジュールするには、ビルドボタンをクリックします。
ビルドサーバは、イメージ構築プロセス中にどのような形式のオートマウンタも実行できません。 必要に応じて、Gnomeセッションがrootとして実行されていないことを確認します。 オートマウンタが実行されている場合、イメージのビルドは正常に終了しますが、イメージのチェックサムが異なるためエラーが発生します。 |
イメージが正常に構築されると、検査フェーズが開始されます。 検査フェーズ中に、SUSE Managerではイメージに関する情報を収集します。
-
イメージにインストールされているパッケージのリスト
-
イメージのチェックサム
-
イメージタイプと他のイメージの詳細
構築されたイメージタイプが 生成されたピラーはすべての接続されているクライアントで使用できます。 |
3.7. トラブルシューティング
イメージを構築するには、いくつかの依存ステップが必要です。 ビルドが失敗した場合は、Salt状態の結果とビルドログを調査することで、失敗の原因を特定できます。 ビルドが失敗した場合は、次のチェックを実行できます。
-
構築ホストがビルドソースにアクセスできる
-
構築ホストとSUSE Managerサーバの両方にイメージ用の十分なディスク容量がある
-
アクティベーションキーには正しいチャンネルが関連付けられている
-
使用されるビルドソースが有効である
-
SUSE Managerのパブリック証明書を含むRPMパッケージは最新で
/usr/share/susemanager/salt/images/rhn-org-trusted-ssl-cert-osimage-1.0-1.noarch.rpm
から入手できます。 パブリック証明書RPMを更新する方法の詳細については、構築ホストの作成を参照してください。
3.8. 制限事項
このセクションには、イメージを操作するときのいくつかの既知の問題が含まれています。
-
HTTPソースまたはgitリポジトリへのアクセスに使用されるHTTPS証明書は、カスタム状態ファイルによってクライアントに配備するか、手動で設定する必要があります。
-
Kiwiベースのイメージの取り込みはサポートされていません。
4. ビルドイメージのリスト
使用できるビルドイメージを一覧にするには、
を選択します。 すべてのイメージのリストが表示されます。イメージに関する表示されたデータには、イメージの[名前
]、その[バージョン
]、[リビジョン
]、およびビルドの[ステータス
]が含まれます。 また、イメージに使用できる可能性のあるパッチやパッケージの更新のリストを使用してイメージの更新ステータスを確認することもできます。
OSイメージの場合、[名前
]および[バージョン
]フィールドはkiwiソースから作成され、ビルドが成功したときに更新されます。 ビルド中またはビルドが失敗した後は、これらのフィールドにはプロファイル名に基づく一時的な名前が表示されます。
[リビジョン
]はビルドが成功するたびに自動的に増えます。OSイメージの場合、複数のリビジョンがストア内に共存できます。
コンテナイメージの場合、ストアには最新リビジョンのみが保持されます。 以前のリビジョン(パッケージ、パッチなど)に関する情報は保存され、[非推奨の表示
]チェックボックスを使用して一覧にすることができます。
イメージの詳細ボタンをクリックすると、詳細ビューが表示されます。 詳細ビューには、関連するパッチの正確なリスト、イメージ内にインストールされたすべてのパッケージのリスト、およびビルドログが含まれます。
削除ボタンをクリックすると、リストからイメージが削除されます。 また、関連するピラー、OSイメージストアからのファイル、および非推奨のリビジョンも削除されます。
パッチおよびパッケージリストは、ビルド後の検査状態が正常だった場合にのみ使用できます。 |