以下は、指定されたテキストの日本語訳です。

---

このファイルは .github/workflows/gh-pages.yml によって生成されています - すべてのローカル変更は最終的に失われます! = ansible-role-bootstrap Jonas Pammer opensource@jonaspammer.at; :toc: left :toclevels: 2 :toc-placement!: :source-highlighter: rouge

https://galaxy.ansible.com/jonaspammer/bootstrap[image:https://img.shields.io/badge/available%20on%20ansible%20galaxy-jonaspammer.bootstrap-brightgreen[Galaxyのバージョン]] // とても関連性のあるステータスバッジ https://github.com/JonasPammer/ansible-role-bootstrap/actions/workflows/ci.yml[image:https://github.com/JonasPammer/ansible-role-bootstrap/actions/workflows/ci.yml/badge.svg[CIテスト]]

Ansibleで管理されるLinuxシステムを準備するためのAnsibleロールです。

このロールは、https://docs.ansible.com/ansible-core/2.16/collections/ansible/builtin/raw_module.html[`ansible.builtin.raw`モジュール]を使用し、独自に実装した「オペレーティングシステム判別システム」と組み合わせて、Ansibleがシステムを管理できるように、最小限必要なパッケージ（`python` と sudo）をインストールします。

このロールは、ほとんどのシステムに対して最新のパッケージキャッシュを確保します。

ほとんどの場合、このロールは私の https://github.com/JonasPammer/ansible-role-core_dependencies[`core_dependencies`ロール]と組み合わせて使用することをお勧めします。

[注] .DISCLAIMER ===== このロールは https://github.com/robertdebock/ansible-role-bootstrap/releases/tag/5.2.12[robertdebock/ansible-role-bootstrap v5.2.12 (2022年1月27日)]のフォークであり、さまざまな変更や修正が加えられています。+ 以下に https://github.com/JonasPammer/ansible-role-bootstrap/releases[/releases]からの変更の抜粋を示します（robertdebockのリポジトリの関連するIssuesも含む）：

• ロール自体がパッケージマネージャキャッシュを予熱する必要があります： https://github.com/robertdebock/ansible-role-bootstrap/pull/57[robertdebock/ansible-role-bootstrap#57] （修正されました： https://github.com/JonasPammer/ansible-role-bootstrap/pull/43[JonasPammer#43]； https://github.com/JonasPammer/ansible-role-bootstrap/pull/50[JonasPammer#50]）
• becomeのデフォルトをfalseに変更し、ansible_userとは別にbecome_userを定義する能力を追加： https://github.com/robertdebock/ansible-role-bootstrap/issues/63[robertdebock/ansible-role-bootstrap#63] （修正されました： https://github.com/JonasPammer/ansible-role-bootstrap/pull/61[JonasPammer#61]）
• bootstrap_become_userのデフォルトをrootに変更
• Ansibleモジュールのステップでもbootstrap_become_userを使用
• podmanとの互換性を持たせるために/bin/shを指定 https://github.com/robertdebock/ansible-role-bootstrap/pull/66[robertdebock/ansible-role-bootstrap#66] （修正されました：

  https://github.com/JonasPammer/ansible-role-bootstrap/pull/62[JonasPammer#62]）

toc::[]

[[meta]] == 🔎 メタデータ ここでは、次の情報を見つけることができます…

• ロールに必要なAnsibleのバージョン
• ロールがサポートするプラットフォーム
• ロールの https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#role-dependencies[ロールの依存関係]

.link:meta/main.yml[] [source,yaml]

---

---

galaxy_info: role_name: bootstrap description: Ansibleで管理されるLinuxシステムを準備するためのAnsibleロール。robertdebockのロールに基づいています。

author: jonaspammer license: "MIT"

min_ansible_version: "2.9" platforms: - name: EL # (エンタープライズLinux) versions: - "9" # アクティブテスト: rockylinux9 - name: Fedora versions: - "38" # アクティブテスト: fedora38 - "39" # アクティブテスト: fedora39 - name: Debian versions: - bullseye # アクティブテスト: debian11 - bookworm # アクティブテスト: debian12 - name: Ubuntu versions: - focal # アクティブテスト: ubuntu2004 - jammy # アクティブテスト: ubuntu2204

galaxy_tags: - bootstrap - python - sudo

dependencies: []

[[requirements]] == 📌 要件 // このロールまたはAnsible自体ではカバーされていない要件があれば、ここに記載してください。 Ansibleユーザーはbecomeできる必要があります。

[[variables]] == 📜 ロール変数 // このロールの設定可能な変数の説明をここに記載してください。 // 役割にパラメーターで設定できる変数。 // 他のロールやグローバルスコープ（例：hostvars、group varsなど）から読み取られる変数もここに記載する必要があります。

[source,yaml]

bootstrap_user: root

https://docs.ansible.com/ansible/latest/reference_appendices/special_variables.html#term-ansible_user[ユーザー名] 主なrawタスクのためにマシンに接続するために使用します。_簡単な事実を収集するため/_インストールするため。

[source,yaml]

bootstrap_become: false bootstrap_become_user: root

---

becomeおよびbecome_user変数は、ほとんどの実際のタスクに渡されます。

bootstrap_becomeのデフォルト値はfalseに設定されました。 これは、ブートストラップ前はsudoが利用できないという仮定から来ています。

[source,yaml]

bootstrap_wait_for_host: false

ansible_port（22）でホストが利用可能になるまで待機するかどうか。

[source,yaml]

bootstrap_timeout: 3

リモートシステムが到達可能または使用可能になるまで最大何秒待つかを設定します。

[[public_vars]] == 📜 このロールによって定義された事実/変数

このセクションにリストされた各変数は、このロールを実行する際に動的に定義され（ansible.builtin.set_factsを使用してのみ上書き可能）、 内部的にだけでなく、他で使用されることを意図しています。

[[tags]] == 🏷️ タグ

// タスクをタグでグループ化する素晴らしい例については、https://github.com/tribe29/ansible-collection-tribe29.checkmk/blob/main/roles/server/README.md#tagsをチェックしてください

タスクには以下の https://docs.ansible.com/ansible/latest/user_guide/playbooks_tags.html#adding-tags-to-roles[タグ]が付けられます：

[cols="1,1"] |=== |タグ | 目的

2+| このロールには公式に文書化されたタグはまだありません。 |===

Ansibleを使ってタスクをスキップしたり、特定のタスクだけを実行したりするためにこれらのタグを使用できます。デフォルトでは、タグが指定されていない場合、すべてのタスクが実行されます。

[[dependencies]] == 👫 依存関係 // ここには他のロールのリストと、他のロールに設定する必要があるパラメータに関する詳細、 // または他のロールから使用される変数を記載する必要があります。

[[example_playbooks]] == 📚 サンプルプレイブックの使用法 // このロールをプレイブックで使用する一般的なシナリオの例を含めることは、ユーザーにとって常に良いです：

[重要]

このロールが使用されるプレイブックのgather_factsプロパティを無効にする必要があります。 このロールが成功裏に完了すると、https://docs.ansible.com/ansible/latest/collections/ansible/builtin/setup_module.html[ Ansibleのセットアップモジュール]が自動的に呼び出されます（gather_facts: trueと同じ効果があります）。

このロールの前にタスクを配置してはいけません。

.最小限の再起動

[source,yaml]

---

• hosts: servers:&provisioned name: Ansibleによって管理されるLinuxマシンをブートストラップします。 become: false gather_facts: false

  roles:

  • role: jonaspammer.bootstrap

---

====

.ブートストラップユーザーの変更（例：rootがオプションでない場合）

[source,yaml]

---

• hosts: servers:&provisioned name: Ansibleによって管理されるLinuxマシンをブートストラップします。 become: false gather_facts: false

  vars: bootstrap_user: "{{ ansible_user }}"

  roles:

  • role: jonaspammer.bootstrap

---

====

.使用可能なsudoを持つ場合のbecome trueの使用（例：すでに少なくとも使えるsudoがあることがわかっている場合）

[source,yaml]

---

• hosts: servers:&provisioned name: Ansibleによって管理されるLinuxマシンをブートストラップします。 become: true gather_facts: false

  vars: bootstrap_user: "{{ ansible_user }}" bootstrap_become: true

  roles:

  • role: jonaspammer.bootstrap

---

====

[[tested-distributions]] == 🧪 テストされたディストリビューション

このロールはRed Hat Enterprise Linux（RHEL）のようなさまざまなディストリビューションで動作する可能性がありますが、 この正確なディストリビューションについてはテストされていません。

|=== | OSファミリー | ディストリビューション | ディストリビューションのリリース日 | ディストリビューションのサポート終了日 | 伴うDockerイメージ

| Rocky | Rocky Linux 8 (https://www.howtogeek.com/devops/is-rocky-linux-the-new-centos/[RHEL/CentOS 8の変装]) | 2021-06 | 2029-05 | https://github.com/geerlingguy/docker-rockylinux8-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-rockylinux8-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Rocky | Rocky Linux 9 | 2022-07 | 2032-05 | https://github.com/geerlingguy/docker-rockylinux9-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-rockylinux9-ansible/workflows/Build/badge.svg?branch=master[CI]]

| RedHat | Fedora 39 | 2023-11 | 2024-12 | https://github.com/geerlingguy/docker-fedora39-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-fedora39-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian | Ubuntu 20.04 LTS | 2021-04 | 2025-04 | https://github.com/geerlingguy/docker-ubuntu2004-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-ubuntu2004-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian | Ubuntu 22.04 LTS | 2022-04 | 2027-04 | https://github.com/geerlingguy/docker-ubuntu2204-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-ubuntu2204-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian | Debian 11 | 2021-08 | 2024-06 (2026-06 LTS) | https://github.com/geerlingguy/docker-debian11-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-debian11-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian | Debian 12 | 2023-06 | 2026-06 (2028-06 LTS) | https://github.com/geerlingguy/docker-debian12-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-debian12-ansible/workflows/Build/badge.svg?branch=master[CI]] |===

[[tested-ansible-versions]] == 🧪 テストされたAnsibleのバージョン

テストされたansibleバージョンは、https://github.com/ansible-collections/community.general#tested-with-ansible[ Ansibleのcommunity.generalコレクションのサポートパターン]と同等であるように保たれます。執筆時点では以下の通りです：

• 2.13（Ansible 6）
• 2.14（Ansible 7）
• 2.15（Ansible 8）
• 2.16（Ansible 9）

[[development]] == 📝 開発 // このプロジェクトの慣習に関するバッジ https://conventionalcommits.org[image:https://img.shields.io/badge/Conventional%20Commits-1.0.0-yellow.svg[Conventional Commits]] https://results.pre-commit.ci/latest/github/JonasPammer/ansible-role-bootstrap/master[image:https://results.pre-commit.ci/badge/github/JonasPammer/ansible-role-bootstrap/master.svg[pre-commit.ciステータス]]

[[development-system-dependencies]] === 📌 開発マシンの依存関係

• Python 3.10以上
• Docker

[[development-dependencies]] === 📌 開発依存関係 開発依存関係は、https://pip.pypa.io/en/stable/user_guide/#requirements-files[pip要求ファイル]に定義されています。名前は`requirements-dev.txt`です。 Linux用のインストール手順の例は以下の通りです：

---

"optional": 現在のシェルセッションのためにpython仮想環境を作成し、アクティブにします

$ python3 -m venv venv $ source venv/bin/activate

$ python3 -m pip install -r requirements-dev.txt

[[development-guidelines]] === ℹ️ Ansibleロール開発ガイドライン

私の https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_GUIDELINES.adoc[Ansibleロール開発ガイドライン]を参照してください。

興味があれば、私もいくつかの https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_TIPS.adoc[一般的なAnsibleロール開発（ベスト）プラクティス]を書いています。

[[versioning]] === 🔢 バージョニング

バージョンは https://git-scm.com/book/en/v2/Git-Basics-Tagging[タグ]を使って定義され、これが https://galaxy.ansible.com/docs/contributing/version.html[Ansible Galaxyで認識され使用されます]。

バージョンはvから始めてはいけません。

新しいタグがプッシュされると、 https://github.com/JonasPammer/ansible-role-bootstrap/actions/workflows/release-to-galaxy.yml[ GitHub CIワークフロー]（image:https://github.com/JonasPammer/ansible-role-bootstrap/actions/workflows/release-to-galaxy.yml/badge.svg[リリースCI]）がロールを私のAnsible Galaxyアカウントにインポートすることを管理します。

[[testing]] === 🧪 テスト 自動テストは、GitHubワークフローを使用して各貢献に対して実行されます。

テストは、主に https://molecule.readthedocs.io/en/latest/[Molecule]を実行し、<<tested-distributions,varying set of linux distributions>>を使用し、<<tested-ansible-versions,various ansible versions>>を使用します。

Moleculeテストには、すべてのAnsibleプレイブックをリントするステップも含まれており、https://github.com/ansible/ansible-lint#readme[`ansible-lint`]を使用して、ベストプラクティスや改善の可能性がある動作を確認します。

テストを実行するには、コマンドラインで単にtoxを実行してください。 MoleculeによってスピンアップされるDockerコンテナのディストリビューションを定義するためにオプションの環境変数を渡すこともできます：

---

$ MOLECULE_DISTRO=ubuntu2204 tox

MOLECULE_DISTROに渡される可能な値のリストは、link:.github/workflows/ci.yml[]に定義されているマトリックスを参照してください。

==== 🐛 Moleculeコンテナのデバッグ

1. MOLECULE_DESTROY=neverオプションでモレキュールテストを実行します。例：

• [subs="quotes,macros"]

---

$ MOLECULE_DESTROY=never MOLECULE_DISTRO=#ubuntu1604# tox -e py3-ansible-#5# ... TASK [ansible-role-pip : (redacted).] pass:[************************] failed: [instance-py3-ansible-9] => changed=false ... pass:[___________________________________ summary ____________________________________] pre-commit: commands succeeded ERROR: py3-ansible-9: commands failed

---

2. Moleculeによって提供されたDockerコンテナの名前を調べます：

• [subs="quotes"]

---

$ docker ps #30e9b8d59cdf# geerlingguy/docker-debian12-ansible:latest "/lib/systemd/systemd" 8 minutes ago Up 8 minutes instance-py3-ansible-9

---

3. コンテナのbashシェルに入り、デバッグを行います：

• [subs="quotes"]

---

$ docker exec -it #30e9b8d59cdf# /bin/bash

root@instance-py3-ansible-2:/#

• [TIP]

  失敗をデバッグしようとしている場合、それはverify.ymlステップの一部であり、実際のconverge.ymlではないことを理解しておく必要があります。 Ansibleのモジュール（vars）、ホスト（hostvars）、および環境変数の出力が、プロビジョナーとDockerマシンの両方にファイルとして保存されています：

• /var/tmp/vars.yml（hostvarsキーの下にホスト変数が含まれています）
• /var/tmp/environment.yml

grepやcat、またはこれらを転送してください！

• [TIP]

  上記の備考に述べたファイルは、特定のワークフロー実行のGitHub CIアーティファクトに添付されています。+ これにより、実行間の違いを確認でき、何がビットロットや失敗を引き起こしたのかをデバッグするのに役立ちます。

image::https://user-images.githubusercontent.com/32995541/178442403-e15264ca-433a-4bc7-95db-cfadb573db3c.png[]

4. デバッグが完了したら、終了してコンテナを破棄します：

• [subs="quotes"]

---

root@instance-py3-ansible-2:/# exit

$ docker stop #30e9b8d59cdf#

$ docker container rm #30e9b8d59cdf# or $ docker container prune

---

==== 🐛 ローカルでインストールされたパッケージバージョンのデバッグ

tox 3では標準機能ですが、これは https://github.com/tox-dev/tox/pull/2794[now] CI変数の存在を認識するときのみ起こります。 例えば：

---

$ CI=true tox

[[development-container-extra]] === 🧃 TIP: コンテナ化された理想的な開発環境

このプロジェクトは「1クリックのコンテナ化された開発環境」の定義を提供します。

このコンテナは、内部でDockerコンテナを実行することも可能にし（Docker-In-Docker, dind）、Moleculeの実行を可能にします。

使用するには：

1. Visual Studio Code開発コンテナの システム要件を満たしてください。 必要に応じて、リンクされたページの__インストール__セクションに従ってください。+ この手順には、Dockerのインストール、Visual Studio Code自体のインストール、および必要な拡張機能のインストールが含まれます。
2. プロジェクトをマシンにクローンします
3. Visual Studio Codeでリポジトリのフォルダーを開きます（_ファイル - フォルダを開く..._）。
4. 開発コンテナの定義があることを通知するプロンプトが右下に表示された場合は、案内されるボタンを押して入ります。 そうでない場合、自分でVisual StudioコマンドRemote-Containers: Open Folder in Containerを実行することもできます（表示 - コマンドパレット -> _メンションされたコマンドをタイプ_）。

[TIP]

開発コンテナ機能が正しく定義の変更を認識しない場合があるので、ここにたまに Remote-Containers: Rebuild Without Cache and Reopen in Container を使用することをお勧めします。

[注]

ホストシステムを設定して、コンテナがSSH/GPGキーを使用できるようにする必要がある場合があります。

手順は、公式の開発コンテナドキュメントの「コンテナと共有 Git 資格情報」を参照してください。https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials

[[cookiecutter]] === 🍪 CookieCutter

このプロジェクトは、https://github.com/JonasPammer/cookiecutter-ansible-role[元々テンプレートとして使用したCookieCutter]と同期を保ちます。 可能であれば https://github.com/cruft/cruft[cruft] を使用し、必要に応じて手動で変更を加えます。

.公式の cruft update 使用例

---

image::https://raw.githubusercontent.com/cruft/cruft/master/art/example_update.gif[公式の cruft update 使用例]

---

==== 🕗 変更ログ 新しいタグがプッシュされると、リポジトリの管理者によって適切なGitHubリリースが作成され、タイトルと説明のある人間による変更ログが提供されます。

[[pre-commit]] === ℹ️ 一般的なリントおよびスタイル規約 一般的なリントおよびスタイル規約は、https://stackoverflow.blog/2020/07/20/linters-arent-in-your-way-theyre-on-your-side/[*自動的に*基準に適合します] さまざまな https://pre-commit.com/[`pre-commit`] フックによって、少なくとも一部は保持されます。

プルリクエストが自動的にファイルを変更したり、コミットごとにリントチェックを実行します。 注： ==== 一部のpre-commitフックは、構文やコードのテストを行い、エラーを警告することがありますが、これらはテストスイートの一部です。 テストに関する情報は、<>を参照してください。 ====

[TIP]

[[note_pre-commit-ci]] それでも、ローカルの開発ワークフローにpre-commitを統合することをお勧めします。

このためには、克隆したプロジェクトのディレクトリに移動し、pre-commit installを実行します。 これにより、gitは作成したすべてのコミットに対してpre-commitチェックを実行し、フックが警告を発した場合はコミットを中止します。

また、たとえば、pre-commit run --all-filesを実行することで、いつでもpre-commitのフックを実行することもできます。

== 💪 貢献 https://open.vscode.dev/jonaspammer/ansible-role-bootstrap[image:https://img.shields.io/static/v1?logo=visualstudiocode&label=&message=Open%20in%20Visual%20Studio%20Code&labelColor=2c2c32&color=007acc&logoColor=007acc[Visual Studio Codeで開く]] image:https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square[PRを歓迎します]

// README.adoc に含まれています :toc: :toclevels: 3

以下のセクションは一般的な内容であり、新しい貢献者を支援するために使用されます。 このプロジェクトの実際の「開発ドキュメント」は <>にあります。

=== 前文 まず、このプロジェクトへの貢献を考えていただき、ありがとうございます。

これらのガイドラインに従うことで、開発者の時間を尊重していることをコミュニケーションできます。 その対価として、開発者はあなたの問題に対処し、変更を評価し、プルリクエストの完了を助けることでその尊重を返してくれるべきです。

[[cookiecutter--contributing]] === 🍪 CookieCutter このプロジェクトの多くのファイルは、https://github.com/JonasPammer/cookiecutter-ansible-role[元々テンプレートとして使用したCookieCutter]に由来しています。

あなたが考えている編集案が実際にそのテンプレートに適用可能か確認し、 そうであれば、そこに適切な変更を加えてください。 あなたの変更が部分的にテンプレートに、部分的にこのプロジェクトに特有である場合、複数のPRを作成することになります。

=== 💬 一般的な貢献の定義

一般的な貢献者は、https://github.com/JonasPammer/JonasPammer/blob/master/demystifying/conventional_commits.adoc[__定義__]に従うことを心配する必要はありません。 プルリクエストはこのプロジェクトに一つのコミットとして統合されるためです。 ただし、コアメンバーはそれに従う必要があります（例：自動バージョン決定や変更履歴生成を機能させるため）。

=== 🚀 始めるために

貢献はIssuesやプルリクエスト（PR）を通じてこのリポジトリに行います。 以下は両方に適用されるいくつかの一般的なガイドラインです：

• 自分自身のIssuesやPRを作成する前に、既存のものを検索してください。
• 初めて貢献する場合は、https://auth0.com/blog/a-first-timers-guide-to-an-open-source-project/[Auth0のブログにある初めてのガイド]を参照して、リソースとヒントを得てください。

==== Issues

Issuesは問題を報告したり、新しい機能をリクエストしたり、PRを作成する前に潜在的な変更について話し合うために使用するべきです。 https://github.com/JonasPammer/ansible-role-bootstrap/issues/new[ 新しいIssueを作成する]ときには、捜査に必要な情報を収集するためのテンプレートがロードされます。

あなたが抱えている問題に対処しているIssueを見つけた場合は、 新しいものを作成するのではなく既存のIssueに自分の再現情報を追加してください。 反応を追加することも、特定の問題がレポーター以外にも影響を与えていることを管理者に示すのに役立ちます。

==== プルリクエスト

このプロジェクトに対するPRは常に歓迎されており、次のリリースのための修正や改善を早くスラートに載せる手段となります。 https://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/[一般的に、PRは以下を満たす必要があります]：

• 該当する機能のみを修正/追加する または広範囲にわたっての空白/スタイルの問題に対処する、両方を行わない。
• 修正または変更された機能のためにユニットまたは統合テストを追加する（テストスイートが既に存在する場合）。
• 単一の懸念に対処する
• リポジトリ内に文書を含める
• プルリクエストを作成した際に自動的にロードされる完全なプルリクエストテンプレートを含むこと。

コア機能に影響を与える変更や、破壊的変更を必要とする変更（たとえば、大規模なリリース）については、最初にIssueを開いて提案について議論する方が良いでしょう。

一般的に、私たちは「フォークしてプル」Gitワークフローに従います：

1. リポジトリを自身のGithubアカウントにフォークします
2. プロジェクトを自身のマシンにクローンします
3. 簡潔かつ説明的な名前でローカルブランチを作成します
4. ブランチに変更をコミットします
5. このリポジトリに固有の書式設定とテストガイドラインに従います
6. フォークに変更をプッシュします
7. 私たちのリポジトリにPRを開き、変更を効率的にレビューするためにPRテンプレートに従います。

[[changelog]] == 🗒 変更ログ このリポジトリの https://github.com/JonasPammer/ansible-role-bootstrap/releases[リリースページ]を参照して、対応する人間による変更ログを確認してください。

このプロジェクトはセマンティックバージョニングを遵守しています。 マイナーバージョンの更新での意図しない破壊的変更は報告してください。

== ⚖️ ライセンス

.link:LICENSE[]

MITライセンス

Copyright (c) 2022, Jonas Pammer

このソフトウェアおよび関連する文書ファイル（以下「ソフトウェア」といいます）を取得したすべての者に無償で配布されることを許可します。 制限なく、ソフトウェアを利用、コピー、修正、結合、出版、配布、サブライセンス、販売する権利を持ち、他の者にもこれを許可することとします。これには以下の条件が付属します：

上記の著作権表示及び、この許可表示は、すべてのソフトウェアのコピーまたは重要な部分に含まれます。

ソフトウェアは「現状有姿」で提供され、いかなる種類の保証もありません。 明示的または暗黙的な保証を含みますが、いかなる商品性、特定の目的の適合性、または非侵害に関する保証は含まれません。 著作者または著作権所有者は、契約、トート、またはその他の行為によって生じた請求、損害またはその他の責任について、一切責任を負わないものとします。

---

---

この翻訳が役立つことを願っています。