概要 Rocky Linux を構築する RHEL ソースコードが公開されていた git.cento…
The post Rocky Linux は RHEL ソース公開方法編後も更新を継続 first appeared on Pocketstudio.Net.
]]>概要
Rocky Linux を構築する RHEL ソースコードが公開されていた git.centos.org の更新停止1と、6/22 は Red Hat から git.centos.org 更新停止の発表がありました。Rocky Linux は、従来の手法で構築できないことが判明したものの、6/23 に Rocky 8 および 9 のサポート継続を宣言し、6/24 にはパッケージの更新が再開できるようになったと発表。
詳細
Red Hat の 6/21 発表「Furthering the evolution of CentOS Stream」（CentOS Streamの更なる進化）では、CentOS Streamが RHEL 関連のソースコード公開の唯一のリポジトリになる（CentOS Stream will now be the sole repository for public RHEL-related source code releases）という記載がありました。従来は git.centos.org にソースコードを送信していましたが、以後は行わないというものです。そのかわりに、RHEL のポータルサイトからのみソースコードが入手できるようになるという発表でした。
実際には、この発表に先がけ Rocky Linux は「Last week we had identified we were about ten updates behind」（先週から10ほど更新が遅れている）と認識しており、同様のプロジェクトである AlmaLinux もパッケージの更新が遅延している状況を把握していました。AlmaLinux は 6/15 に bugzilla でバグ報告をしていますが、6/21 にコメント欄で「With the end of life of CentOS Linux 7 coming, we will no longer publish source code on git.centos.org.」（CentOS Linux 7 の提供終了(EOL)に伴い、git.centos.org でのソースコードの公開を終了する）という返信がありました。
これをうけ、Rocky Linux プロジェクトは、git.centos.org からソースコードを自動的に取り込む方法をやめ、「After tireless efforts by team members」（チームメンバの絶え間ない努力により）6/24 には何らかの方法でパッケージを更新できる体制を整えた模様です。さらに、手動での作業が増えたとはいえ、ライセンスは遵守している旨の記載もありました。
This is more manual work than our previous processes, but it does abide by licensing agreements
また、今後はすべての SRPM 、パッチ、対象のチェックサムといった透明性を確保する方法も準備するとの記載がブログにあります。
これ以上の詳しいことは Rocky Linux のプロジェクトに書かれていませんので分かりませんが、6/22 の発表にあったように、Rocky Linux 8 および 9 の完全サポートを維持する体制が整った模様です。
参考情報
- Furthering the evolution of CentOS Stream
- Rocky Linux Expresses Confidence Despite Red Hat’s Announcement | Rocky Linux
- Brave New World: The Path Forward for Rocky Linux | Rocky Linux
- AlmaLinux OS – Forever-Free Enterprise-Grade Operating System
- 2215299 – Missing sources on git.centos.org
The post Rocky Linux は RHEL ソース公開方法編後も更新を継続 first appeared on Pocketstudio.Net.
いつかの自分のための覚え書き。 /etc/selinux/config で設定できなくなる SELi…
The post SELinux実行時の無効化機能が削除へ first appeared on Pocketstudio.Net.
]]>いつかの自分のための覚え書き。
/etc/selinux/config で設定できなくなる
こちらのページの情報によると、Linux 6.4 からは「SELinux の実行時無効化機能が削除」されるとあります。現在、現行の一部ディストリビューションでは /etc/selinux/config の設定で SELINUX=disabled としておくと、SELinux のポリシーが kernel に読み込まれる前に無効化できています（the runtime disable functionality）。これが「remove」と書いてある通り、この無効化機能そのものが削除されます。
そのため、Linux 6.4 以降で SELinux を無効化するには従来の方法ではなく、ブート時のパラメータに selinux=0 を付ける必要が出てきます、と書かれています。
利用者の視点では、Linux カーネルのバージョンによっては /etc/selinux/config で disabled だとしても、SELinux が有効になっている可能性があるという点を覚えておく必要がありそうです。
なお先の記事では、この昨日廃止に向けて数年間取り組んできたものの、目に見えた障害は個人のカーネルテストシステム1件だけであり、 selinux=0 によって問題に対応できたようです。
参考
The post SELinux実行時の無効化機能が削除へ first appeared on Pocketstudio.Net.
]]>概要 Sphinx で「Edit on GitHub」を出すには、conf.py に設定の追記が必要…
The post Sphinxで「Edit on GitHub」リンクを出す方法 first appeared on Pocketstudio.Net.
]]>概要
Sphinx で「Edit on GitHub」を出すには、conf.py に設定の追記が必要。
背景
Docker ドキュメントの日本語翻訳サイトには Sphinx を採用しています。このページでは、次のように「Edit on GitHub」のボタンがあり、
ここをクリックすると Pull Request を出すための編集画面が開く仕組みです。
従来はローカルリポジトリ上にあるテーマ用HTMLファイルを直接編集していました。改めて調べてみると、今日では Sphinx と Read the Docs テーマ側で対応しているのが分かりました。メンテナンスがない古いテーマを使い続ける理由はないため、テーマが推奨する記法で対応する方向に切り替えました。以下は設定手順です。
手順
テーマのドキュメントに Sphinx テーマにソース編集のリンクを追加するという、ズバリそのものの記述があります。今回は GitHub のリポジトリを追加したいので、ドキュメントを参考に Sphinx の conf.py に以下の記述を追加しました。
html_context = {
"display_github": True,
"github_user": "zembutsu",
"github_repo": "docs.docker.jp",
"github_version": "v23.0",
"conf_py_path": "/",
}項目を見ていくと、以下のような意味があります。
display_github… GitHub のリンクを表示github_user… GitHub ユーザ名github_repo… GitHub リポジトリ名github_version… リポジトリ内で対象とする main 等のバージョン（ブランチ名）conf_py_path…conf.pyから見て、どこにソースコードが置かれているか（/source/等）
さらにこれだけでなく、 conf.py にはテーマ用オプションの説明ページにある記述を追加します。
重要な設定項目は vcs_pageview_mode です。デフォルトでは blob であり、GitHub 上の URL で「単にページを表示する」に相当します。今回は、リンクをクリックすると編集画面に飛ばしたいので edit を指定します。なお、ここで raw を指定するとテキスト形式でそのまま出力させるのも可能です。
最終的にオプションを追記した conf.py は次のような指定になりました。
html_theme_options = {
'logo_only': False,
'display_version': True,
'prev_next_buttons_location': 'bottom',
'style_external_links': True,
'collapse_navigation': True,
'sticky_navigation': True,
'navigation_depth': 5,
'includehidden': True,
'titles_only': False,
'vcs_pageview_mode': 'edit',
}ファイルを変更後、 make html でページを生成し直すと、Read the Docs の標準テーマを使ったままページ上に「Edit on GitHub」のリンクを表示できました。
参考
- Adding “Edit Source” links on your Sphinx theme — Read the Docs user documentation 9.12.0 documentation
- Configuration — Read the Docs Sphinx Theme 1.2.0 documentation
The post Sphinxで「Edit on GitHub」リンクを出す方法 first appeared on Pocketstudio.Net.
]]>Stable DiffusionをWindowsのDocker Desktopで比較的簡単にはじめる…
The post Stable DiffusionをDocker Desktopで簡単に使い始める方法 first appeared on Pocketstudio.Net.
]]>
Stable DiffusionをWindowsのDocker Desktopで比較的簡単にはじめる手順をまとめました。ほぼ、自分の覚書です。
確認した環境は、Windows 10 Pro、21H2、build 19044.2846＋16GB RAM+NVIDIA GeForce RTX 2060 SUPER＋WSL2(Ubuntu)+Docker Desktop 4.18.0(104112) です。
どうして Stable Diffusion のために Docker Desktop を使うのか？
楽してセットアップしたいからです。AUTOMATIC1111/stable-diffusion-webui というウェブ用 UI は既にありますが、動かすためには環境構築等いくつかの手順が必要です。ですが、この面倒な作業を省略してできる Stable Diffusion WebUI Docker (AbdBarho/stable-diffusion-webui-docker) があります。
Windows かつ Docker Desktop が入っていれば、 docker compose コマンドで環境構築と実行が簡単にできます。ライブラリや各種依存関係の事前準備は一切不要です。
なお、コンテナだから何か困ったコトはないの？という疑問があるかもしれません。私も使い始めるまでは不安がありましたが、今のところは特に困っていません。生成される画像やモデルや VAE 等のデータは Windows マシン上と共有（bind マウント）していますので、エクスプローラまたは Docker Desktop 上の対象コンテナ「Files」でドラッグするだけでファイルをやりとりできます。せいぜい困ったのは、extension を無効化するときにバックアップを取っておらず、半日かけて学習させたデータ50GBくらいを一瞬で吹っ飛ばしたくらいです。
事前準備
WSL2 の有効化と Docker Desktop のインストールです。
はじめる前の注意点
初回実行時、Stable Diffusion 1.5 のモデル等 12GB をダウンロードします。このダウンロードが終わらないと、Web UI が利用できません。回線状況によっては、初回起動まで、とても時間がかかる可能性があります。
コード類のダウンロード
まずはじめに、Stable Diffusion WebUI Docker のコード類を https://github.com/AbdBarho/stable-diffusion-webui-docker からダウンロードします。
ZIPでダウンロードする場合、「Code」→「Download ZIP」をクリックするとファイル「stable-diffusion-webui-docker-master.zip」がダウンロードされますので、適当に使いやすい場所に中身を展開します。展開すると、 stable-diffusion-webui-docker-master というフォルダがありますので、コマンドライン等を開き、この中で docker compose コマンドを動かします。
あるいは、Git for Windows 等の Git が使える環境であれば、次のようにしてダウンロードするのが手っ取り早いです。
git clone https://github.com/AbdBarho/stable-diffusion-webui-docker.gitこの場合、フォルダ名は stable-diffusion-webui-docker です。 cd stable-diffusion-webui-docker などで移動しておきます。
Docker に慣れている方向けの補足情報
※とりあえず始める場合は、読み飛ばして大丈夫です。
デフォルトではタイムゾーンが UTC です。ログに出てくる時刻や output/txt2img 以下に生成されるディレクトリの日付を日本時刻に合わせるためには、 auto サービスの環境変数に TZ=Asia/Tokyo を追加します。具体的には、次のような記述を environment: に追記します。
auto: &automatic
<<: *base_service
profiles: ["auto"]
build: ./services/AUTOMATIC1111
image: sd-auto:51
environment:
- CLI_ARGS=--allow-code --medvram --xformers --enable-insecure-extension-access --api
- TZ=Asia/Tokyo初回起動時の作業
あとは Wiki のドキュメント通りの作業です。コードが展開されたフォルダ内で、以下のコマンドを実行します。
docker compose --profile download up --buildコマンド実行後、 webui-docker-download-1 というコンテナのログが画面に出ます。暫くは、次の様にダウンロードが走りますので、完了するまで待ちます。
webui-docker-download-1 | [DL:256KiB][#4561e1 1.4GiB/3.9GiB(36%)][#42c377 1.4GiB/3.9GiB(37%)]正常に終了すると、次の様に exited with code 0 と表示されて、元のプロンプトに戻ります。
...（省略）
webui-docker-download-1 | https://github.com/xinntao/Real-ESRGAN/blob/master/LICENSE
webui-docker-download-1 | https://github.com/xinntao/ESRGAN/blob/master/LICENSE
webui-docker-download-1 | https://github.com/cszn/SCUNet/blob/main/LICENSE
webui-docker-download-1 exited with code 0 一方、もし次の様に 0 以外のコードが出てきた場合は、ダウンロード処理に失敗しています。
webui-docker-download-1 | 42c377|OK | 426KiB/s|/data/StableDiffusion/sd-v1-5-inpainting.ckpt
webui-docker-download-1 |
webui-docker-download-1 | Status Legend:
webui-docker-download-1 | (OK):download completed.(ERR):error occurred.
webui-docker-download-1 |
webui-docker-download-1 | aria2 will resume download if the transfer is restarted.
webui-docker-download-1 | If there are any errors, then see the log file. See '-l' option in help/m
an page for details.
webui-docker-download-1 exited with code 24こうなった場合は、先ほどのコマンドをもう一度実行して、正常終了になるかどうかを確認します。
正常に終わったら、次は Web UI を起動するコマンドを実行します。※以下 AUTOMATIC1111 の UI かつ GPU 仕様の場合
docker compose --profile auto up --buildコマンドを実行して、初回実行時はモデル等を読み込むため数分ほど時間がかかりる場合があります。以下のような表示になって、固まっているかのように見えるかもしれませんが、大丈夫です。
webui-docker-auto-1 | LatentDiffusion: Running in eps-prediction mode
webui-docker-auto-1 | DiffusionWrapper has 859.52 M params.しばらく待つとログが流れ、次のような URL が出ます。
webui-docker-auto-1 | Running on local URL: http://0.0.0.0:7860これで Web UI の起動準備が調いました。ブラウザから http://127.0.0.1:7860 を開くと WebUI が見えます。
開いたら、画面左上で適当なモデルを選び、テキスト欄に何か文字を書き、「Generate」ボタンをクリックすると、画像生成が始まります。
クリックすると、ボタンが反転します。処理が終わるまで待ちます。
この時、操作しているターミナル上でも画像生成のログが出ますし、Docker Desktop でコンテナのログを見ても、同様の表示を確認できます。
100％になると、画像の生成が終わり、画面上でも確認できます。
作成した画像は、自動的に docker compose コマンドを実行したディレクトリ直下の「output/txt2img/日付」のフォルダ内に保存されています。
なお、起動した Web UI を停止するには docker compose コマンドを実行したままになっているターミナル上で Ctrl+C を入力すると止められます。
Gracefully stopping... (press Ctrl+C again to force)
Aborting on container exit...
[+] Running 1/1
? Container webui-docker-auto-1 Stopped 11.4s
canceled正常終了すると、再びコマンドが実行できるようになります。
再起動後など、再度 WebUI を使うには docker compose コマンドを実行し直します。
docker compose --profile auto up --buildちなみに、動作中のハードウェア状況をみるには、タスクマネージャを使って GPU の状況を見ると分かりやすいです。
GPU がコンテナ内から見えているかどうか確認したい場合は、 docker exec や Docker Desktop の 「Terminal」からコマンド nvidia-smi を実行して、情報が出てくるかどうかでも確認できます。
root@e37fcc5a5810:/stable-diffusion-webui# nvidia-smi
Mon Apr 17 07:42:27 2023
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 530.41.03 Driver Version: 531.41 CUDA Version: 12.1 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 NVIDIA GeForce RTX 2060 S... On | 00000000:01:00.0 On | N/A |
| 42% 40C P8 6W / 175W| 2558MiB / 8192MiB | 2% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| 0 N/A N/A 149 C /python3.10 N/A |
+---------------------------------------------------------------------------------------+モデルやVAEの追加
はじめから入っていないモデルをダウンロードしたら、「stable-diffusion-webui-docker\data\StableDiffusion」に「.safetensors」など拡張子を持つファイルを置いておきます。
VAEの場合は「stable-diffusion-webui-docker\data\VAE」に「.skpt」ファイルを置きます。
Docker Desktop であれば、webui-docker-auto-1 コンテナの「Files」上で中を見たり操作できますので、Docker Desktop にドラッグすることもできます。
以下は Docker Desktop の画面です。Note に「MOUNT」（マウント）とあり、Windows ホスト側とフォルダ内の情報をコンテナと共有しているのが分かります。
さて、ファイルを置いたあとは、Web UI のフッタに「Reload UI」のリンクがありますので、ここをクリックします。
クリックすると読み込み中の表示になり、ブラウザの接続が切れます。ブラウザを再読み込みすると、自動的にモデルやVAEファイルが読み込まれています。
なお、モデルを削除するには、「data\StableDiffusion\」から対象モデルのファイルを削除するだけです。
Enjoy!
参考情報
- Usage · AbdBarho/stable-diffusion-webui-docker Wiki · GitHub
The post Stable DiffusionをDocker Desktopで簡単に使い始める方法 first appeared on Pocketstudio.Net.
]]>Docker 公式ブログで Docker Desktop 4.18 リリースのお知らせ「Docker…
The post Docker Desktop 4.18 リリース関連情報 first appeared on Pocketstudio.Net.
]]>Docker 公式ブログで Docker Desktop 4.18 リリースのお知らせ「Docker Desktop 4.18: Docker Scout Updates, Container File Explorer GA」が公開されました。docker init というβ機能のコマンドの追加や、Docker Scout CLI、 Docker Desktop での Container File Explorer（ファイルエクスプラーラ）の一般提供開始(GA)等、macOS の adminless（管理者権限不要）インストール対応、Docker Compose File Watchといった、いくつかの新機能が紹介されていました。以下では、その発表ポイントを整理します。
Docker Scout CLI
- Docker Dekstop 4.17で導入された Docker Scout（ドッカー・スカウト：スカウトとは、「偵察」や「探し出す」意味）は、イメージの脆弱性を見えるようにして、迅速な対応を推奨するツール。
- Docker Desktop 4.17 からは
docker scountコマンドラインでは、コミュニティからのフィードバックを受けた新機能が追加。 docker scout quickviewコマンドは、イメージのセキュリティに関する情報と、対象方法を表示できる。docker scout cvesコマンドは、CVE （脆弱性データベース）の情報を表示するが、docker scout recommendationsコマンドを実行すると、イメージを分析し、脆弱性を減らしたりイメージ容量を小さくする方法、ベースイメージで利用可能なアップデートの情報を表示する。- 2023年1月、BuildKit の拡張 により、attestation（認証）を含むイメージの構築をサポート。これで構築したイメージは、
docker scoutコマンドを使えば、ベースイメージからどのように構築したかを正確に把握できる。 - SBOM attestation（Software Bill of Materials, ソフトウェア構成情報の認証）を含めて push されたイメージがあれば、
docker scoutでローカルの SBOM を新しく作成せず、SBOM attestation からパッケージ情報を読み込む。 - 実験的機能（Experimental）として、
docker scout compareコマンドによりイメージを比較できる。比較するのは脆弱性やパッケージの情報、環境変数など。Markdown 形式の出力に対応。
Container File Explorer の一般提供開始(GA)
- Docker Desktop のユーザインターフェース上から、直接コンテナ内のファイルを表示・操作できる機能。これがあれば、長いコマンドを覚える必要も無く、 docker cp などで都度操作したりシェル上で作業する必要がなくなる。
- Container File Explorer ができること
- コンテナのファイルシステムを確認
- ホストとコンテナ間でのファイルとフォルダのコピー
- コンテナにファイルを簡単にドラッグ＆ドロップできる
- syntax hilighting でファイルを簡単に編集
- ファイル削除
macOS の adminless（アドミンレス、管理者権限不要）インストール対応
- セキュリティ権限が厳しく管理者権限が制限されている環境では、Docker Desktop から管理者権限を必要とする機能を外せるようにしたもの。
- インストール時は、デフォルトでは管理者権限の付与が求められるが、
Settings->Advancedタブで変更可能に。
docker init (Beta)
- Docker Desktop 4.18.0 からは、新しいコマンド
docker initを使えば、 新しいプロジェクトを始めるときに必要なファイル、たとえば Dockerfile、Compose ファイル（docker-compose.yaml）、 .dockerignore をプロジェクトに適した状態で自動的に作成。 - 現時点では Go 言語のみ。Docker チームが取組中なのは Node.js、Python、Java、Rust、 .NET 。数ヶ月で他の機能も追加。その他の言語やフレームワークについては 意見を募っている 。
Docker Compose File Watch（Experimental）
- docker-compose.yaml ファイル中に、新しい
x-developセクションをオプションで追加可能。 - 設定後、
docker compose alpha watchコマンドを実行すると、プロジェクト内にあるファイル変更の監視を開始できる。 - 例えば指定したパスにあるファイルを変更すると、Compose はイメージを再構築し、実行中のサービスを更新版に入れ替えられる。
参考情報
- Docker Desktop 4.18: Docker Scout Updates, Container File Explorer GA | Docker
- docker scout
- docker init
The post Docker Desktop 4.18 リリース関連情報 first appeared on Pocketstudio.Net.
]]>最終更新日 2023年4月4日 概要 2023年3月14日（米国時間）、サブスクリプションプランの１…
The post Docker Free Team の organization プラン廃止・撤回に関する情報 first appeared on Pocketstudio.Net.
]]>最終更新日 2023年4月4日
概要
2023年3月14日（米国時間）、サブスクリプションプランの１つ「Docker Team」1 の「Free」（無料で利用可能）プランの廃止（sunsetting）を発表しましたが、その後3月17日に撤回を発表し、混乱に対する謝罪を表明しました。
無料の Team を使っている組織やユーザは直接影響を受け、有償プラン切り替えなど、何らかの対策が必要です。それ以外の一般ユーザも、organization として公開されている Docker イメージ（リポジトリ名が「組織名/リポジトリ」の場合。例：「dokku/dokku」）を利用している、間接的に影響を受けます。そのため、自分が使っている Dockerfile の確認が必要になり、リポジトリが公開されなくなる場合、あるいはリポジトリが移動する場合には、FROMなど書き換えが必要です。
3月17日、Free Team プランの廃止撤回に伴い、以上の懸念は無くなりました。
本ページでは、公開されている情報を基に、事実ベースで影響範囲、対策、関連情報を整理しています。
発表内容
Docker 社からの発表 (2023/03/14)
現時点で Docker Inc. の公式ページやブログからは、本件に関する情報は辿れません。3月14日、Organizations の Docker Free Plan 利用者を対象者に、第1報のメールが送信されました。その後、3月17日には、Docker 公式ブログ上で「We apologize. We did a terrible job announcing the end of Docker Free Team」（「謝罪します。Docker Free Team の終了について酷い行いをしました」）という Frem Team プラン廃止を撤回する発表が行われました（3月17日JST更新）。また3月24日の Docker 公式ブログ記事「We’re No Longer Sunsetting the Free Team Plan」で改めて正式に廃止撤回を表明します。また、3月25日(JST)には対象者に「We’re no longer sunsetting Free Team organizations」（Free Team organizationを一切廃止しません）という撤回の旨のメールが送られました。
2023年3月14日発表（メール第1報）
当時、該当する利用者に対してはメールでの通知（3月15日JST）と、詳細情報の PDF へのリンクが提示されました。メールの件名は「Important: Docker is sunsetting Free Team organizations」（重要：Docker は Free Team organization を廃止します）であり、メールの文面は以下の通りです。
この通知のポイントは「無料の Docker Team は 2023年4月14日でプライベートリポジトリが利用できなくなり、公開リポジトリも rate リミットが適用される。さらに、その1ヵ月後にリポジトリ（もちろん Docker イメージも）削除される」でした。※現在は撤回済み
詳細：
- Docker Team サブスクリプションのうち無料で使えた「Free Team organization」は既に過去の存在（レガシー）。
- Free Team は有料の Docker Team と同じ特徴や機能を持っている。
- このメールが届いた利用者は、Free Team organization のメンバーの可能性がある。
- Free Team のプライベートリポジトリは 2023 年 4 月 14 日（UTC午後11時59分、日本時間15日9時00分）に停止予定。
- 回避するには 2023 年 4 月 14 日までに Docker Team の有料サブスクリプションに切り替える必要。
- 有料サブスクリプションに切り替えなければ、データを 30 日間保管した後、削除対象となる。
- 削除対象となると、それまで公開リポジトリのイメージは公開されるものの、rate リミットが適用される。
- 30日の期間中に有料プランに更新すると、いつでも回復できる。
- 詳細は FAQ を読むように。
2023年3月25日発表（メール第2報）
その後、3月25日に対象者に対して Free Team プラン廃止撤回のメール「We’re no longer sunsetting Free Team organizations」が送られました。
詳細：
- 2023年3月14日、Free Team プラン廃止に関するメールを送信。コミュニティからの懸念に耳を傾け、方針を転換し、Free Team プランの廃止を撤回。
- Free Team プランを利用中の場合、4月14日まで他のプランに変更する必要がない。
- 有料プランにアップグレートした場合、30日以内に自動的に全額返金し、かつ、サブスクリプション契約期間は新しい有料プランを無料で利用できる。
- 私たちの判断で不安を引き起こしたのを謝罪。
- 詳細は FAQ を参照
Docker が発表した FAQ (2023年3月24日最新版)
Docker から通知されたメールには、 FAQ (PDF) へのリンク https://web.docker.com/rs/790-SSB-375/images/privatereposfaq.pdf が示されていました。現在、この PDF は書き換えられ、ウェブ上の FAQ https://www.docker.com/developers/free-team-faq/ が表示されます。
以下は FAQ の概要です：
Docker は Free Team プランを廃止するのですか？
いいえ。Docker は 2023年3月14日に Docker Free Team プランを廃止する意向を伝えました。しかし、この決定は2023年3月24日に撤回されました。
他の Docker に何か影響がありましたか？
いいえ。以下いずれにも影響はありませんでした。Docker Personal、Docker Pro、Docker Team、Docker Business、Docker-Sponsored Open Source、Docker Verified Publishers、Docker Official Images。
オープンソースプログラムは Docker にまだありますか？
はい。長年にわたる Docker スポンサード・オープンソース（DSOS）プログラムは（既に撤回された）Free Team organization 廃止の影響を一切受けず、利用し続けられます。私たちは Free Team プランを越える利便性を提供しますので、適切なプロジェクトは、このプログラムの適用を推奨します。
Docker Free Team プランを使っているかどうかを確認するには？
Free Team の organization に自分が属しているかどうかを確認するには、 Docker Hub にログイン後、「Organization」をクリックします。
それから、Organizations の画面で一覧が表示されます。対象となる Organization の名前（Namespace）列を確認し、「Subscription」列が「Docker Free Team」と表示されている場合に影響を受けます。
Free Team organization を持っている Docker の利用者は 2% 未満です。
どうして今は料金ページに Docker Free Team が無いのですか？
2021年にサインアップのオプションを廃止したからです。
（有料）Docker Team プランと Docker Free Team プランの違いは何ですか？
主な利点の違いは：
- team の数が無制限（vs Free Team では 1 team）
- 100 人まで対応（vs Free Team では 3 人）
- プライベートリポジトリが無制限（vs Free Team ではプライベートリポジトリが無し）
- 5,000 pull/日/ユーザ（vs Free Team では 200 pull/6時間/ユーザ）
- Free Team プランには、250 人以上の従業員または年間利益10百万ドル以上の企業に対する Docker Desktop の商用ライセンスに含まない
Docker Free Team プランの上限に到達したらどうなりますか？
Docker Free Team が更に必要な場合は、Docker Team や Docker Business へのアップグレードをすべきでしょう。
Docker Free Team が Docker Personal や Docker Pro に移行されたらどうしたらよいですか？
私たちはアカウントを移行しませんので、Free Team organization のまま使い続けられます。私たちのサポートチームは、この確認をする全てのオープンなお問い合わせに対応します。
3月14日から3月24まで、Docker Free Team を有料プランにアップグレードしていた場合、返金されますか？
私たちが発表した3月14日から3月24日にかけて発生した、この種の全ての支払を確認・返金するために取り組んでいます。返金は最大30日です。
Docker Free Team を有料プランにアップグレードしましたが、Free Team に戻せない問題が発生しています。
サポートにお問い合わせください。
私のアカウントからデータを出力（エクスポート）できますか？
はい、Docker レジストリ上のプライベートリポジトリからイメージを取得し、それらのイメージを任意の他のレジストリに送信してください。
Docker は公開イメージやレイヤを削除するのですか？
いいえ。Docker は削除するつもりは一切無く、公開リポジトリに対する一切のアクセス制限も行いません。オープンソースプロジェクトのメンテナは一切の対応が不要です。もしもメンテナが Docker Hub からリポジトリを削除した場合のみ、Docker Hub 上で公開イメージやレイヤが非表示になります。
（廃止された場合）他人に namespace を不法占有(squat)されますか？
いいえ。Docker は namespace を解放しません。そのため、namespace が不法占有される危険性は一切ありません。
これは Docker Hub 上のコンテンツのセキュリティに影響がありますか？
いいえ。Docker は公開リポジトリへの制限を行いません。メンテナは障害なく更新し続けられますので、CVE 等の修正対応など、あらゆる理由でリポジトリ上にフルアクセスを続けられます。
まだ質問がある場合は？
サポートにお問い合わせください。
Docker が発表した FAQ (2023年3月15日更新)※当時の古い情報
当時の FAQ の内容は以下の通りです。今となっては古く撤回された情報ですが、当時の発表を記録・比較する意図で残しておきます。
※以下の情報は3月15日公開時点の情報です。最新の FAQ を常にご確認ください。
自分が影響を受けるかどうかを確認するには？
Free Team の organization に自分が属しているかどうかを確認するには、 Docker Hub にログイン後、「Organization」をクリックします。
それから、Organizations の画面で一覧が表示されます。対象となる Organization の名前（Namespace）列を確認し、「Subscription」列が「Docker Free Team」と表示されている場合に影響を受けます。
なお、 organizations の一部に影響があったとしても、個々の Docker アカウントや他の organization には影響がありません。
また、今回の変更は Docker Personal、Docker Pro、有料の Docker Pro、 Docker Business 等のサブスクリプションには影響ありません。
オープンソースプロジェクトで使っている場合はどうしたらいいですか？
オープンソースプロジェクト向けの Docker スポンサード・オープンソース（DSOS）プログラムを提供し続けています。Free Team organization 廃止の影響を受けません。
Free Team organization から DSOS への参加を希望する新しい利用者は、DSOS の申請中がレビュー中の場合は organization の停止や削除を延期します。最終的に申請が却下されても、少なくとも30日間与えます。また、皆さんからの声をもとに、追加のプログラムやプランを提供するかもしれません。
2022年9月に基準を変更しました。過去の応募で却下された場合でも、全てのオープンソースプロジェクトが応募されるのを推奨します。スタッフは全ての申請を直ちに審査します。
Docker 公式イメージ (DOI) や Docker Verified Publishe (DVP) の場合はどうしたらいいですか？
DOI や DVP に影響はありません。
Free Team のプライベートリポジトリを使い続けるには？
organization のプライベートリポジトリは有料サブスクリプション機能です。過去の Free Team のプライベートリポジトリは 2023 年 4 月 13 日で停止となります。複数のサブスクリプションプランによって、プライベートリポジトリを利用し続けられます。詳細は料金表を参照ください。
（廃止された場合）他人に namespace を不法占有(squat)されますか？
organization が停止されたり、削除したり、自主的に離れたとしても、使っていた organization の namespace は解放されません。つまり、イメージは不法占有できません。
（解説：もし名前空間が解放されれば、有名な Free Team だった organization を第三者が再取得し、中身が改竄されたり悪意を持って工作される Docker イメージが配布されるのではという懸念がありました。その批判に対する回答と思われます。）
個人のアカウントにダウングレードできますか？
Free Team organization から Personal アカウントへのダウングレードは、現時点ではできません。新しい Personal アカウントを作成し、データのコピーはできますが、異なる名前空間を作成します。
Docker 以外のリポジトリを使っています。私のアカウントからデータを出力できますか？
はい、2023年 4 月 13 日までであれば、いつでも Docker レジストリのプライベートリポジトリからイメージを出力し、任意の別のレジストリにイメージを送信できます。
Docker サブスクリプション料金はいくらですか？
Docker Pro プランから始まる3つの有料サブスクリプションを提供しています。料金表をご覧ください。
Docker 有料サブスクリプションの利点は何ですか？
- Docker Pro は、生産性を向上したい個人の開発者に最適です。
- Docker Team は、生産的な共同作業をしたい小規模チームに最適です。
- Docker Business は、集中管理と高度なセキュリティ機能が必要な企業に最適です。
有料サブスクリプションにアップグレードするには？
- docker.com に自分のアカウントでサインインします。
- バナーの「Upgrade」を選びます。
- アップグレードしたいプランを選び、利用者数を指定します。
- 支払手続きをします。
自分の Docker イメージは自動で有料サブスクリプションに移行しますか？
はい、Docker 有料サブスクリプションにアップグレードすると、自分のアカウントと関連するすべての設定、イメージ、リポジトリは、同じ名前と設定が 100% 維持されます。
他にも、追加情報等あれば、更新します。間違い等御座いましたら、ご指摘いただけますと幸いです。
参考情報
- Free Team Organizations FAQ | Docker
- What to know about the end of Docker Free Teams | Docker
- We’re no longer sunsetting the Free Team plan | Docker
- Free Team Organizations FAQ
- Free team being sunset, no way to convert to a regular account · Issue #2314 · docker/hub-feedback
The post Docker Free Team の organization プラン廃止・撤回に関する情報 first appeared on Pocketstudio.Net.
本投稿は、さくらインターネットアドベントカレンダー2022の4日目の投稿です。5日目は@naomin…
The post Rocky Linux の現状把握（2022年12月版） first appeared on Pocketstudio.Net.
]]>
本投稿は、さくらインターネットアドベントカレンダー2022の4日目の投稿です。5日目は@naominix@github さんの記事です、楽しみですね。
さて、私からは先日オープンソースカンファレンス2022/Onlineで発表した「忙しい人のための Rocky Linux 入門」を、現状にあわせてご紹介します。
Rocky Linux とは？
Rocky Linux（ロッキーリナックス）は CentOS Linux の後継を目指す Linux ディストリビューションの1つです。公式サイト https://rockylinux.org の説明では「Rocky Linux is an open-source enterprise operating system designated to be 100% bug-for-bug compatible with Red Hat Enterprise Linux」（RHELとバグまで含めて100%互換性を意図するオープンソースのエンタープライズオペレーティングシステム）とあります。
私が Rocky Linux を知ったきっかけは 2020 年 12 月 8 日の「RHEL 8 の再構築としての CentOS 8 」開発終了アナウンス1です。これは CentOS Stream に今後注力するという内容でしたが、事実上 RHEL と1対1で対応してきた CentOS 8 系の終了であり、（当時）以降に出るであろう CentOS 9 以降のシリーズが提供されなくなるのを意味しました（実際、その後に提供された RHEL 9.0 は CentOS Stream 9 をベースとする位置づけであり、CentOS 9.0 は存在していません）。
そして、単に従来型 CentOS 開発が終わるだけでなく、CentOS 8 の EoL が 2029 年 5 月 31 日から 2021 年 12 月 31 日へと変更になったのです。CentOS 8.x 利用者は、ほぼ1年以内に CentOS Stream 8 など他のディストリビューションへの転換を迫られることになりました。
私の個人的な利用環境では CentOS Stream への移行でも問題なかったのですが、長年ディストリビューションの隆盛をウォッチしてきた身としては、行く末が気になっていました。当初気にかけていたのは AlmaLinux です。CloudLinux 社がオープンソースの「魂」を意味する「alma」を掲げたディストリビューション構想を発表し、 CentOS の後継者に名乗りを挙げました 2。
その後、私が AlmaLinux と似たようなプロジェクトとして Rocky Linux が動いていると明確に認識したのは、2021 年 4 月 30 日の Rocky Linux 8.3 RC1 版のリリースでした。しかし、オリジナルの CentOS 創設者であるカーツァー氏（Gregory M. Kurtzer）は、CentOS の開発終了アナウンス記事に対し、12 月 8 日の当日のうちに「他の RHEL の再構築を考えている」とコメントを残されていた3のです。
その後、Rocky Linux のサイトが公開され、RC （リリース候補）版を経て、2021 年 6 月 21 日に Rocky Linux 8.4 が GA （一般提供開始）となります。 Rocky Linux の開発は Rocky Enterprise Software Foundation（RESF）という非営利法人を土台とした、個人と企業によるオープンなコミュニティ主導の開発体制となり、RESF を支援するスポンサーやパートナー企業によるサポートも行われています。2022年12月の現時点では、Rocky Linux 8.7 および 9.1 がリリースされています。
CentOS Stream は RHEL に先行する存在
Rocky Linux の立ち位置を知るには、CentOS とCentOS Stream が別々のディストリビューションであるという、その関係性の理解が大切です。
CentOS Stream は、CentOS 8 の EoL によって登場したかのようにも見えますが、実は 2019 年 9 月 24 日から存在していました。 CentOS 8.0 (1905) がリリースされると同時に、RHEL 開発用ディストリビューションとして CentOS Stream 1905（現在 CentOS Stream 8 と呼ばれる系統）が同時にリリースされていたのです（参考：[CentOS-announce] Release for CentOS Linux 8 and CentOS Streams）。
CentOS 8.x は従来の CentOS シリーズと同様、Red Hat 社が提供するソースコードを元に構築されたものです。そのため、RHEL 8.x と RHEL 8.x の各バージョンごとにポイントリリース（point-release）があり、各バージョン番号が一対一で対応していました。
一方の CentOS Stream はローリングリリース（rolling-release）のため、常にパッケージの更新が行われ日々リリースされている状況となりました。CentOS と異なり明確なポイントリリースがありません。
そして重要なのは、関係するディストリビューション間の関係性が変わった点です。従来は、Fedora がアップストリーム（上流）であり、そこから RHEL → CentOS という流れがありました。CentOS Stream が登場したことにより、Fedora がアップストリームに変わりませんが、CentOS Stream がミッドストリーム（中流）→ RHEL がダウンストリーム（下流）であると明確に位置づけられた4のです。
このように、CentOS 8 が Stream に集中すると宣言する以前から、CentOS Stream 8 の登場によって、CentOS 7 までのリリース形態と、 RHEL の関係性は既に変わっていたのでした。
このようにバージョンごとの対応付けを見ると、CentOS 8.x と CentOS Stream 8 が双子のような存在に見えますが、位置づけ・役割は明確に異なっていたのです。
そして、その後に提供されている RHEL 9 も、同様に CentOS Stream 9 をミッドストリームとして利用するスタイルを踏襲しています。
このように、CentOS シリーズとしては CentOS Stream が残り続けることとなりました。CentOS 8 から CentOS Steram へ変更するにはパッケージ更新をする方法が提供されていますので、改めてディストリビューションをインストールし直す必要はありません。
しかしながら、ポイントリリースという概念がなくなるため「RHEL の各バージョンに対応する CentOS」という概念が消滅することとなりました。なお、 CentOS 8 は 2021 年 12 月 31 日で EoL となりましたが、CentOS 7 は 2024 年 6 月 30 日までのサポート（更新は 2020 年で終了し、現在メンテナンスアップデートのみ）が続いています。
Rocky Linux の始動
2020 年 12 月 8 日の発表直後から、CentOS 共同創業者のカーツァー氏はリポジトリを作成し、 GItHub に初めてのコミットをします。その README.md には「# centosng」という見出しが1行あるだけ。
私が初めて見たとき、「centos」が「ng」=「no good」（良くないね）的な深い意図を感じてしまいましたが、もしかしたら「next generation」（次世代）なのかもしれませんねと、OSC でセッション参加者の方に指摘され、なるほどと感じました。いずれにしろ、CentOS を変える意思を感じる見出しです。
そして、翌 9 日には「Rocky Linux」の文字が登場します。そして、かつての CentOS がそうだったように、コミュニティによるエンタープライズ OS として、バグをも含む RHEL 100% 互換性を持つディストリビューションを目指すプロジェクトが始動します。
「Rocky」の由来・意味は？
ところで、Rocky の名前とは、CentOS 共同創設者の Jason Dale Rocky McGaugh （ジェイソン・デイル・ロッキー・マクガフ）氏の名前に由来すると公式サイトに説明があります。ロッキー氏はカーツァー氏と一緒に CentOS を立ち上げていたのです5。ロッキー氏は、カーツァー氏にとっては同僚でありメンターでしたが、2004年12月、CentOS の完成を前に30歳で亡くなられていたとのことです。かつての師の名前をディストリビューションに刻むことで、また CentOS のようなコミュニティ主導のディストリビューションを作るのだという、カーツァー氏の並々ならぬ想いが馳せられます。
Rocky Linux の独立性を担保するための RESF 設立
カーツァー氏はディストリビューション開発準備を進めるにあたり、GitHub 上で開発およびユーザーのコミュニティとしての「Rocky Linux Project」 https://github.com/rocky-linux/ を始動します。中心となるソースコードのライセンスは BSD 3-Clause License です。
これと並行してカーツァー氏は、2020年12月、 Rocky Enterprise Software Foundation (RESF) を設立します。米国デラウェア州で公益法人（PBC=Public Benefit Corporation）です。このあたりの説明は公式 FAQ にもありますように、真にコミュニティのエンタープライズOSを維持するためとあります。組織構造もしっかりしており、コミュニティに対する説明責任、透明性や、持続性を担保する事務局的な機能だけではありません。加えて、Rocky Linux という名前を保護するための法務面のほか、財務やスポンサー対応も RESF が担います。
これは、Linux カーネルと Linux Foundation の関係に近いと言えるのではないでしょうか。Linus Torvalds 氏らが Linux カーネルを開発する一方、Linux Foundation は資金援助や知的財産の保護や啓蒙などを担って6いますが、Linux を支配しているわけではありません。
Rocky Linux Project はディストリビューションの開発プロジェクトであり、RESF は Linux Foundation のように資金や知財などを管理していると考えると、関係性をイメージしやすいでしょう。
このように、Rocky Linux の組織体制をカーツァー氏は構築していきますが、第三者からすると本当に信じて良いだろうかという疑念は当然生まれるでしょう。様々なインタビュー記事や Reddit の投稿に対する返信でも、繰り返し Rocky Linux の独立性を担保するためとカーツァー氏は主張しています。
Rocky Linux 商用サポートを担う CIQ 社
カーツァー氏は RESF を準備する一方、CIQ 社 ( https://ciq.co ) を設立、 2021 年 1 月 28 日に資金調達をしています。
CIQ はRocky Linux の商用サポートを担い、Rocky Linux 専任開発者を雇うためです。CIQ 社は Rocky Linux や RESF の親会社でもなければ、支配している状況でもありません。あくまでも RESF のパートナーであり、資金援助している企業の1つです。
このように、あくまでも Rocky Linux はコミュニティによるものですが、プロジェクトの継続性という意味で、パートナーやスポンサーを拡大しつつ、カーツァー氏が自らも Rocky Linux を支援・サポートできる体制が整えられてきています。
Rocky Linux 8 の初動が遅かった理由
AlmaLinux が非常に早い初期リリースをしたのに比べると、Rocky Linux は動きが遅かったように見えます。動き出してから Rocky Linux 8.4 の GA まで半年を要しました。これは、取材記事7によると、完全にゼロからのスタートだったからとあります。開発者や貢献者が安全に参加できるインフラを構築するために4ヶ月。OSの構築に2ヶ月、そして、RC 版を出しつつ検証しての1ヶ月。全く何も無いところから、人も環境も整えたのです。
Rocky Linux 9 には独自のビルドシステム Peridot を構築した
Rocky Linux の Reddit フォーラムには、一時期「do it right, don’t just do it fast」というキーワードがよく出てきていました。早くやるんじゃない、正しくやるんだと。
RHEL 9.0 が 2022 年 5 月 17 日にリリースされましたが、対応する Rocky Linux 9.0 の提供は 6 月 14 日と一ヶ月近くを要しました。これは Peridot と呼ばれるクラウドネイティブなディストリビューション構築およびリリース用のツールの開発に時間がかかったからです。
Rocky Linux 8 までは CentOS と同じ koji を採用していましたが、Rocky Linux 9 からは Peridot をベースとしたビルドシステム https://peridot.build.resf.org/ に移行しています。ドキュメントによりますと、Kubernetes + Istio の環境で、2,500 以上のパッケージを並列ビルド可能とあります。そのため、Peridot さえ動作がうまくいけば、従来よりも素早いリリースができるようになることを目指していました。
実際、RHEL 9.1 は 2022 年 11 月 15 日にリリースされ、Rocky Linux 9.1 は 11 月 26 日と、ほんの 11 日遅れでリリースできるようになってきています。
バージョンとサポート期間の考えが RHEL と Rocky Linux は少し異なる
Rocky Linux は従来の CentOS のようにポイントリリースですが、サポート期間（EoL）の考え方は RHEL とは異なるので、少し注意が必要です。RHEL はポイントリリースごとに、Extended Update Support や Update Service for SAP Solutions が提供されている場合があります。そのため、マイナーバージョンをサポートが続く限り利用できる体制があります。
一方、Rocky Linux は、基本的に新しいポイントリリースが提供されると、古いバージョンは直ちに EoL となります8。そのため、古いバージョンの Rocky Linux を使い続けられません。「dnf update」コマンドを実行するたけで、新しいポイントリリースがあれば、自動的にバージョンアップするからです。
もし、カーネルのバージョンなどを固定する必要があれば、パッケージの更新を除外するなど対策を打てますが、サポート外となる可能性もあります。この点は RHEL とは異なりますので、利用開始前に長期的な運用方針の検討や、パッケージ更新のルール作り、影響範囲の事前確認は欠かせなくなります。
このように、見かけ上の RHEL 9 と Rocky Linux 9 はバージョンが対応しますが、ポイントリリースごとにメンテナンスが続く RHEL と、継続的な更新が続く Rocky Linux では、考え方が少し違うのだと理解が必要です。
Rocky Linux の今後
以上が 2022 年 12 月現在の Rocky Linux を取り巻く現状です。前述の通り、Rocky Linux は開発体制がコミュニティ主導であり、かつ、 CentOS 協働創設者が立ち上げたディストリビューションという位置づけから、当初の CentOS の思想を受け継ぐ後継者の1つと言えるでしょう。
懸念点を敢えて挙げるのであれば、リリースの遅さとやサポート面や継続性でした。
当初は AlmaLinux に比較すると反応が遅かったため（むしろ逆で、AlmaLinux のリリースがとてつもなく早いと認識すべき）、かつての CentOS がそうだったように、Rocky Linux もリリース間隔が遅れる懸念はありました。ですが、現在の Rocky Linux は開発体制が整っています。さらに、独自開発のパッケージビルドシステム Peridot の稼働が功を奏した模様で、Rocky Linux 9.1 のリリースは、RHEL 9.1 に遅れること11日でのリリースとなりました。
また、オープンなコミュニティ主導の場合は、サポート体制や組織・資金面での懸念も出てきます。その点も、RESF という公益法人がプロジェクトの法務・財務・資金面を支援し、CIQ 社などがサポートを提供できる体制も整いつつあります。CIQ を通してクラウド事業者の支援も広がりつつあり、Rocky Linux を選べるようになったクラウドも増えました。
一方、独自のビルドシステム Peridot は Rocky Linux プロジェクトのみならず、誰もが自由にディストリビューションを構築できうる土台として開発されているとされています。そのため、 Peridot のソースコードは GitHub で公開されていますが、まだ使い方のドキュメントは提供されていないため、Rocky Linux をベースとして、誰でも自分用のディストリビューションが作れる環境には至っていないのが気になる点はあります。しかし、これまでの Rocky Linux の真摯な開発体制をみれば、いずれはドキュメントも整うものと期待しています。
このように Rocky Linux を取り巻く状況は動き続けています。引き続き、Rocky Linux の動きを追っていきたいと思います。
The post Rocky Linux の現状把握（2022年12月版） first appeared on Pocketstudio.Net.
さくらのレンタルサーバで、ドメイン管理がさくら以外の場合や、サブドメインだけをレンタルサーバに向けている場合でも、Let's Encrypt設定ができます。その手順をまとめました。
The post さくら以外のネームサーバを使いながらLet’s EncryptのSSL証明書をサブドメインに設定する方法｜さくらのレンタルサーバ first appeared on Pocketstudio.Net.
]]>
概要
さくらのレンタルサーバには、コントロールパネル上の操作でLet’s EncryptのSSL証明書を有効にする機能があります。初期ドメインやさくらのサブドメイン（*.sakura.ne.jp）だけでなく、さくら以外でドメイン名を管理したり、ネームサーバを運用している場合でも、Let’s EncryptのSSL設定を利用できます。
（*.sakura.ne.jp）を使う場合か、さくらインターネットで申し込んだ独自ドメインをSNI SSLとして使う場合であれば、コントロールパネルの操作やサポート情報の手順どおり、スムーズに進みやすいでしょう。
一方、以下で紹介する手順は、さくら以外で管理しているドメイン名を使う場合です。そのサブドメイン名でLet’S Encryptを設定する手順と、迷いやすいポイントを整理しました。
ただし、このページで掲載している手順は、正式な手順とは一部異なります。そのため、場合によってはサポートを受けられなくなる可能性もありますので、ご注意願います。
設定手順
設定作業の流れは、まずコントロールパネルで「ドメイン新規追加」をします。それからSSL設定をするために、いくつかの設定を確認した後、SSL設定を有効化します。
ここでの前提は、ネームサーバがさくらのレンタルサーバ以外
さくらのレンタルサーバでSSLを使うにあたり、さくら以外でドメインを取得し、ネームサーバを設定している前提での手順です。
さくらのレンタルサーバでドメインを取得している場合は、通常の設定手順を見ながら進められます。
「ドメイン新規追加」から対象ドメインを設定
レンタルサーバのコントロールパネルのメニュー「ドメイン/SSL」から、「ドメイン/SSL」を選びます。画面上に『ドメイン新規追加』ボタンがありますので、これをクリックします。
そして、次の「ドメインを新規追加」画面では、画面を下にスクロールし、一番下にある「他社で取得したドメインを移管せずに使う」の『追加』ボタンをクリックします。
次の「他社で取得したドメインを移管せずに使う」の画面では、2つの選択肢がありますが、「他社で取得した独自ドメインの追加」は選択しません。この項目は、ネームサーバの設定を「さくらインターネット」に変更したい場合です。コントロールパネルで登録するのとあわせ、ネームサーバ設定をさくらインターネット側に変更する必要があります。
そうではなく、ドメインを移管せず、ネームサーバ設定も変更しない場合は、画面を下にスクロールして出てくる「他社で取得された独自ドメインのサブドメインを追加」に「サブドメイン名」（ホスト名）と「ドメイン名」を入力し、『追加』をクリックします。
あとは、画面の指示が出ているように、サブドメインのネームサーバを権限委譲（NSレコード）を追加します。
あるいは、レンタルサーバのAレコードを自分で調べ、自分でドメイン名のゾーン情報を編集し、対象となるホスト名のAレコードを追加します。先の図では「pocketstudio.net」というドメイン名は、さくらのレンタルサーバではネームサーバを動かしていません。別のネームサーバ上のゾーン設定で、「sakura.pocketstudio.net.」というホスト名に対するAレコードを追加しました。
ドメイン設定が完了すると、「ドメイン/SSL」のメニュー上に追加したサブドメインの情報が出てきます。
サブドメインの場合は「wwwが付与されたサブドメインも利用する」の設定を解除
さて、コントロールパネルにサブドメイン情報が表示されれば、あとは簡単に SSL 設定が出来るように見えます。先ほど追加したドメイン名の『設定』をクリックします。
それから、「wwwが付与されたサブドメインも利用する」は、初期状態ではチェックが入っています。ここをクリックし、次の画面のようにチェックを外す必要があります。
それから画面を下にスクロールし、『保存する』をクリックして設定を保存します。
この設定を行わないと、以降の手順でLet’s Encrypt設定を行おうとしても、「サブドメイン(www.~)のIPアドレスが利用中のサーバと異なるIPアドレスに設定されているため無料SSL機能はご利用いただけません」と警告が出るため、注意が必要です。
いざSSL設定を有効化しようと思っても……？
ちなみに、ドメイン設定画面で SSL を有効化しようとしても、『SNI SSL』を選べなかったり、画面上にも「初期ドメイン、さくらのサブドメイン（省略）ではSNI SSL をご利用いただけません」と表示されているため、一見すると SSL が設定できないように見えますが、実際には設定できます。
この画面からは設定できませんので、「保存する」ボタンをクリックするか、画面右上の「キャンセル」をクリックして、元のドメイン一覧画面に戻ります。
ドメイン一覧画面から、改めて『 SSL 』をクリックします。
そして、次の画面では「証明書設定なし」や「有償SSL証明書一覧」といった項目が画面上にありますが、これらは無視します。
Let’s Encrypt の設定を行うには、『登録設定を始める SSL証明書の選択』をクリックします。
その次の画面でも、いくつか証明書の選択肢が出てきますが、他の選択肢はすべて無視し、一番上にある「Let’s Encrypt（無料SSL）」の『利用する』ボタンをクリックします。
あとは、画面の指示に従い、Let’s Encrypt の利用ポリシーの確認、同意のチェックを入れ、『無料SSLを設定する』ボタンをクリックします。
もし、この画面のような画像ではなく「サブドメイン(www.~)のIPアドレスが利用中のサーバと異なるIPアドレスに設定されているため無料SSL機能はご利用いただけません」と出る場合は、「www」でも接続できるような初期設定が残っています。このページの手順を確認し、設定を変更して再度画面を開けば設定できます。
「無料SSLを設定する」ボタンを押した後、画面が切り替わり、「ただいま無料SSL証明書の発行手続き中です」との画面が表示されます。
設定としては、以上となります。あとは完了メールが届くまで少し時間があります。画面上では「発行には数十分～数時間かかる場合があります」と出ていますので、ここでコーヒーを飲むなりして一休みです。
設定から少し待つと有効化
少し待つと（今回は10分後でした）『[さくらインターネット]SSLサーバ証明書発行のお知らせ』という件名のメールが届きます。
そして、コントロールパネルを確認すると「SNI SSL」の表示が追加されて、SSL設定が有効になっていることが分かります。
ブラウザでも https:// を付けてアクセスすると、「この接続は保護されています」と表示されました。
ちなみに、常に「https://」として SSL 通信を有効にしたい場合には、ドメン設定画面から「HTTPS転送設定」で『HTTPSに転送する』にチェックを入れて保存するだけです。そうすると、http://~でブラウザで入力した場合も、自動的に https://~として表示（リダイレクト）されます。
関連情報
- 【無料SSL】Let’s Encrypt 設定手順 – さくらのサポート情報
- [無料SSL]設定時に表示されるエラーの対処方法を知りたい – よくあるご質問 – さくらのサポート情報
The post さくら以外のネームサーバを使いながらLet’s EncryptのSSL証明書をサブドメインに設定する方法｜さくらのレンタルサーバ first appeared on Pocketstudio.Net.
]]>Linux ディストリビューション “AlmaLinux OS” （http…
The post AlmaLinux の公式ロゴや背景画像入手先 first appeared on Pocketstudio.Net.
]]>
Linux ディストリビューション “AlmaLinux OS” （https://almalinux.org/）の公式ロゴ画像や使い方（ブランドブック）に辿り着いたメモです。ロゴ画像を使う必要に迫られたのですが、公式サイト上では見つからず。検索したところ Reddit の投稿に辿り着きました。
AlmaLinux ロゴの入手先
AlmaLinux は2021年1月のリリース以来、情報提供の手段として Reddit を活用しています。この Reddit の投稿のなかで、 ロゴや背景画像に関する投稿がありました。
Due to the recent number of requests for graphics and logos and since we do not yet have a graphics page or logo usage guidelines, we have uploaded them to a dropbox folder and you can find them here. You can also grab the wallpapers from the release here.
このように、画像やロゴのガイドラインが定まっていないものの、dropbox のリンク先から直接ダウンロードできると書かれています。
- ロゴのダウンロード先 (logos.zip)
- 背景画像のダウンロード先 (backgrounds.zip)
それぞれ、ダウンロードした ZIP ファイルを展開すると、PNG や SVG や PDF 形式としてのロゴ画像や、背景の JPEG 画像があります。また、 logoz.zip には ブランドブック ( AlmaLinux BrandBook.pdf ) も同梱されています。適切に画像を使いたい場合には、参考になるでしょう。
The post AlmaLinux の公式ロゴや背景画像入手先 first appeared on Pocketstudio.Net.
]]>ちょっとハマって、PowerToolsリポジトリを使えるようにするまで、調査に時間がかかってしまった…
The post CentOS Stream 8 で変わった PowerTools リポジトリを有効化する手順 first appeared on Pocketstudio.Net.
]]>ちょっとハマって、PowerToolsリポジトリを使えるようにするまで、調査に時間がかかってしまったので、振り返りのためのメモです。
「PowerTools」が見つからない？
あるパッケージをリビルドしようとしてたのですが、画面には libedit-devel が見つからないというエラーが。
一致した引数がありません: libedit-devel
ネット上で情報を検索していると、PowerToolsリポジトリにパッケージが入っているとのこと。なるほど、そうであれば、単に PowerTools を有効化したらいいのか、とコマンドを実行するのですが……
[zem@stream ~]$ sudo dnf config-manager --set-enabled PowerTools エラー: 修正用の一致する repo はありません: PowerTools.
残念、「PowerTools」が無いとの表示。おやおや。
「PowerTools」は「powertools」に名前が変わったのが原因
ここで確認のため、リポジトリ一覧を表示するコマンド dnf repolist --all を実行。
[zem@stream ~]$ dnf repolist --all | grep PowerTools
powertools CentOS Stream 8 - PowerTools 無効化
このように PowerTools のリポジトリはあるものの「無効化」に。そして、よくよく行頭のリポジトリ名を見てみると、 powertools と全て小文字になっています。なるほど、これだ。どうやら、リポジトリ名称の変更1があった模様です。
というわけで、改めて正しく入力し、リポジトリを有効化するコマンドを実行。そして再度確認すると――
[zem@stream ~]$ sudo dnf config-manager --set-enabled powertools
[zem@stream ~]$ dnf repolist --all | grep PowerTools
powertools CentOS Stream 8 - PowerTools 有効化
やりました、成功です。「有効化」を確認できました。
ここまで来ると、あとはパッケージを普通に dnf で入れるだけ。 dnf install libedit-devel を実行します。
[zem@stream ~]$ sudo dnf install libedit-devel
最速のミラーを確定しています (10 hosts).. done.===================] 1.1 kB/s | 647 B 00:00 ETA
CentOS Stream 8 - PowerTools 1.2 MB/s | 4.0 MB 00:03
メタデータの期限切れの最終確認: 0:00:03 時間前の 2022年01月28日 22時04分55秒 に実施しました。
依存関係が解決しました。
====================================================================================================
パッケージ Arch バージョン リポジトリー サイズ
====================================================================================================
インストール:
libedit-devel x86_64 3.1-23.20170329cvs.el8 powertools 44 k
依存関係のインストール:
ncurses-c++-libs x86_64 6.1-7.20180224.el8 baseos 58 k
ncurses-devel x86_64 6.1-7.20180224.el8 baseos 527 k
トランザクションの概要
====================================================================================================
インストール 3 パッケージ
ダウンロードサイズの合計: 629 k
インストール後のサイズ: 1.0 M
これでよろしいですか? [y/N]: y
パッケージのダウンロード:
(1/3): ncurses-c++-libs-6.1-7.20180224.el8.x86_64.rpm 528 kB/s | 58 kB 00:00
(2/3): ncurses-devel-6.1-7.20180224.el8.x86_64.rpm 3.0 MB/s | 527 kB 00:00
(3/3): libedit-devel-3.1-23.20170329cvs.el8.x86_64.rpm 123 kB/s | 44 kB 00:00
----------------------------------------------------------------------------------------------------
合計 69 kB/s | 629 kB 00:09
トランザクションの確認を実行中
トランザクションの確認に成功しました。
トランザクションのテストを実行中
トランザクションのテストに成功しました。
トランザクションを実行中
準備 : 1/1
インストール中 : ncurses-c++-libs-6.1-7.20180224.el8.x86_64 1/3
インストール中 : ncurses-devel-6.1-7.20180224.el8.x86_64 2/3
インストール中 : libedit-devel-3.1-23.20170329cvs.el8.x86_64 3/3
scriptletの実行中: libedit-devel-3.1-23.20170329cvs.el8.x86_64 3/3
検証 : ncurses-c++-libs-6.1-7.20180224.el8.x86_64 1/3
検証 : ncurses-devel-6.1-7.20180224.el8.x86_64 2/3
検証 : libedit-devel-3.1-23.20170329cvs.el8.x86_64 3/3
Installed products updated.
インストール済み:
libedit-devel-3.1-23.20170329cvs.el8.x86_64 ncurses-c++-libs-6.1-7.20180224.el8.x86_64
ncurses-devel-6.1-7.20180224.el8.x86_64
完了しました!このように無事入りました。
Librepo version: 1.12.0 with CURL_GLOBAL_ACK_EINTR… のエラー
ちなみに、CentOS Stream 8 で、 dnf update をかけていないと、このようなエラーが出ます。
[zem@stream ~]$ sudo dnf config-manager --set-enabled PowerTools Librepo version: 1.12.0 with CURL_GLOBAL_ACK_EINTR support (libcurl/7.61.1 OpenSSL/1.1.1g zlib/1.2.11 brotli/1.0.6 libidn2/2.2.0 libpsl/0.20.2 (+libidn2/2.2.0) libssh/0.9.4/openssl/zlib nghttp2/1.33.0) エラー: 修正用の一致する repo はありません: PowerTools.
これは dnf パッケージが古いのが原因です。 dnf update dnf を実行しておけば回避できます。もしエラーが出たら、環境が古くないかどうか確認し、問題なければバージョンアップしておきましょう。
The post CentOS Stream 8 で変わった PowerTools リポジトリを有効化する手順 first appeared on Pocketstudio.Net.