linuxmirrors-os について
linuxmirrors-os は、GNU/Linux のソフトウェアソース変更を計画するスキルです。初心者、運用担当者、CI/CD の保守担当者向けに、事前確認から承認、検証、ロールバックまでを整理します。
主な機能
- 01ディストリビューションやネットワークの確認
- 02変更パラメーターと手順の計画
- 03バックアップと差分の作成
- 04リポジトリ検証とロールバック案内
活用シーン
- 01Ubuntu サーバーのソース変更計画
- 02EOL システムの vault と EPEL 対応
- 03CI/CD 用の非対話コマンド作成
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ full-stack-skills/ devops-skills --skill linuxmirrors-osインストール後、Claude Code で/linuxmirrors-osを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
evaluation-report.htmlLICENSE.txtagents/openai.yamlexamples/01-ubuntu-interactive.md02-ci-unattended.md03-centos7-eol.md04-custom-debian-security.md05-broken-original-source.mdreferences/official/command-options.mdscript-variants.mdsource-modes.mdsystem-matrix.mdreferences/operations/automation.mdpreflight.mdrollback.mdtroubleshooting.md詳細
LinuxMirrors システムソフトウェアソースの切り替え
クイックスタート
すぐにワンライナーのコマンドを提示しないでください。まず、システム、ネットワーク、権限、現在のソース、ロールバック条件を確認し、「事前確認 → 計画 → 確認 → 実行 → 検証 → ロールバック」の手順を作成してください。
次のように依頼できます。
- 「Ubuntu 24.04 サーバー向けに、LinuxMirrors でのソース切り替えとロールバックの計画を作成してください。」
- 「CI に適した、非対話型のシステムソース切り替えコマンドを生成してください。ただし、まだ実行しないでください。」
- 「CentOS 7 は EOL ですが、LinuxMirrors で vault と EPEL を扱うにはどうすればよいですか?」
使用する場面
ユーザーが GNU/Linux システムソフトウェアソースの切り替え、公式ソースの復元、EPEL/vault/EOL への対応、またはソース切り替えの自動化計画の作成を明確に求めている場合に使用します。Docker CE リポジトリ、Registry Mirror、Docker Desktop、コンテナーランタイムの設定には適しません。
対象ユーザー
- 初心者:対話型の手順とデフォルトのバックアップを使用し、カスタムの branch は避けます。
- 運用担当者:固定コミット、明示的なパラメーター、diff、メンテナンスウィンドウ、ロールバック検証を使用します。
- CI/CD メンテナー:無人実行パラメーター、停止条件、ビルドログの保存を使用します。
前提条件
ディストリビューション、バージョン、アーキテクチャ、ネットワーク地域、root/認可の状態、ロールバック手段を把握している必要があります。情報が不足している場合は、安全な想定に基づく計画のみを提示してください。
使用方法
Step 1:事前確認
事前確認チェックリストを読み、ディストリビューション、バージョン、アーキテクチャ、root、ネットワーク地域、パッケージマネージャーを確認します。
Step 2:モードを選択
ソースモードに基づき、中国大陸向け、--edu、--abroad、--use-official-source true のいずれかを選択します。
Step 3:パラメーターを決定
パラメーターリファレンスから必要最小限のパラメーターを選択し、存在しないオプションを作り出さないでください。
Step 4:計画を作成
変更対象のファイル、バックアップ先、パッケージインデックスの更新、検証、メンテナンスウィンドウを明確にします。
Step 5:事前に確認
コマンドを提示しますが、ユーザーの認可に代わって実行してはいけません。環境が不明な本番システムで直接実行することは禁止です。
Step 6:実行後に検証
ソースファイル、パッケージマネージャーの更新結果、宛先ドメインを確認します。スクリプトの終了コードだけで検証を済ませてはいけません。
Step 7:失敗時にロールバック
ロールバックガイドに従い、.bak またはディレクトリのバックアップから復元し、キャッシュを再更新します。
対応範囲と対象外の場面
✅ 得意な対応
- Debian/Ubuntu、Red Hat 系、openSUSE、Arch、Alpine、Gentoo、NixOS など、サポート対象システムのソース切り替え計画。
- 対話型の選択、無人実行パラメーター、EPEL、security、vault、基盤システムのソース、カスタムミラーパス。
- バックアップ、
--print-diff、検証、失敗の診断、公式ソースへの切り戻し。
⚠️ 条件が必要な対応
- 実際の実行には root シェル、変更の認可、ネットワーク接続、メンテナンスウィンドウが必要です。
- EOL または派生システムでは、バージョンコード、リポジトリパス、ミラーサイトで同期が継続しているかを確認する必要があります。
- カスタムの
--source/--branchを使用する場合は、完全な URL と Release/repodata などのメタデータが利用可能であることを先に検証する必要があります。
❌ 対応範囲外(代替案を案内)
- Docker CE ソフトウェアソースまたは Docker Hub の高速化 → Docker 専用のソース切り替え手順を使用してください。
- 現在のスクリプトで認識されない独立系ディストリビューション → ディストリビューションの公式リポジトリのドキュメントを参照し、手動で計画してください。
- 認可のない本番マシンでのソース切り替えの代行実行 → レビュー用の計画、コマンド、ロールバックチェックリストのみを提示してください。
資料の案内
- すべてのパラメーター:パラメーターリファレンスを参照してください。
- サポート対象システム:システムマトリックスを参照してください。
- 中国大陸/教育ネットワーク/海外/公式ソース:ソースモードを参照してください。
- メインスクリプトと Lite:スクリプトの選択を参照してください。
- 実行前:事前確認チェックリストを参照してください。
- CI/CD:自動化ガイドを参照してください。
- 設定の復元:ロールバックガイドを参照してください。
- エラーのトラブルシューティング:トラブルシューティングを参照してください。
セキュリティとプライバシー
このスキルはユーザーデータを収集またはアップロードしません。ホストのパスワード、SSH 秘密鍵、クラウドの認証情報を要求してはいけません。リモートスクリプトは、先にダウンロードして出所とハッシュ/内容を確認し、その後、ユーザーが root シェルで実行するようにしてください。sudo bash <(curl ...) の形式で実行するよう記述してはいけません。デフォルトではバックアップを保持し、--ignore-backup-tips を積極的に使用しないでください。
ルール
- パラメーター、バージョンコード、リポジトリパス、ミラーの利用可否を作り出してはいけません。
- デフォルトでバックアップを行い、すべてのソフトウェアパッケージのアップグレードとキャッシュの削除は行いません。
- パッケージインデックスの更新に失敗した場合は直ちに停止し、インストールやアップグレードを続けてはいけません。
- 複数のホストで作業する場合は、代表的なノードで先に検証してから、バッチごとに展開してください。
情報が不足している場合
まず「Ubuntu 24.04、x86_64、中国大陸、計画の作成のみで実行しない、バックアップを保持、ソフトウェアパッケージをアップグレードしない」という安全な例を提示してください。次の情報を補足してください:ディストリビューションとバージョン、アーキテクチャ、ネットワーク地域、現在のソースが利用可能か、EPEL/security/vault が必要か、ソフトウェアパッケージのアップグレードが許可されているか。
検証チェックリスト
cat /etc/os-releaseの内容はパッケージマネージャーと一致していますか?- コマンドパラメーターは現在の
ChangeMirrors.sh --helpにありますか? - バックアップ先と復元コマンドは明確ですか?
- すべてのソフトウェアパッケージのデフォルトでのアップグレードとキャッシュの削除を避けていますか?
- 対象リポジトリのメタデータとパッケージインデックスの更新を検証していますか?
注意点
sudo bash <(curl ...)はプロセス置換の権限やファイル記述子の動作によって失敗することがあります。先に root シェルに入ってください。--sourceにホスト部分のみを指定する場合も、正しい--branchが必要です。複数階層のパスは全体を検証してください。- Debian/Ubuntu の security ソースには、独立した
--source-securityと--branch-securityが必要な場合があります。 - CentOS/AlmaLinux の EOL リポジトリでは vault が必要な場合があります。通常のメインリポジトリのパスを使い続けてはいけません。
--ignore-backup-tipsは、上書きの警告を無視してバックアップを作成しないという意味です。自動化でデフォルトのパラメーターとして使うのには適していません。- パッケージインデックスの更新に失敗した場合、ソフトウェアパッケージのアップグレードを続けてはいけません。まずロールバックするか、DNS/TLS/バージョンコードを修正してください。
FAQ
Q1:スクリプトはバックアップを作成しますか? メインスクリプトはデフォルトでバックアップを作成し、一般的には元のパスに .bak を付けた形式で保存します。実行前に、ディスクの空き容量と既存のバックアップを確認してください。
Q2:ソフトウェアパッケージをアップグレードしないようにするには? 自動化計画で --upgrade-software false を明示的に使用し、現在のスクリプトがこのオプションに対応していることを確認してください。
Q3:公式ソースを復元するには? まず --use-official-source true を使用して再生成してください。失敗した場合はバックアップから復元してください。
Q4:curl すらインストールできない場合は? Python、wget、ブラウザー、または信頼できるローカルコピーを使ってスクリプトを取得し、先に内容を確認してから実行してください。
Q5:教育ネットワーク向けのソースはどのように選びますか? 中国大陸の教育ネットワークでは --edu を使用し、対象のミラーがそのシステムバージョンに対応していることを先に確認してください。
Q6:ソース切り替えの成功を確認するには? ソースファイルの宛先ドメインを確認し、該当するパッケージマネージャーの更新コマンドを実行して、Release/repodata、署名、TLS のエラーがないことを確認してください。