
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Chaos and Order</title>
      <link>https://www.youngju.dev/blog</link>
      <description>천천히 올바르게. AI Researcher &amp; DevOps Engineer Youngju&#39;s blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, and data engineering — plus mindset essays on confidence, routines, health, and sport psychology.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Fri, 14 Aug 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/dnf/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-build-local-repo.en</guid>
    <title>Building a Local Repository Inside an Air-Gapped Network — createrepo_c, repodata, .repo Files, and GPG Keys</title>
    <link>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-build-local-repo.en</link>
    <description>Covers the whole process of turning a transferred bundle of rpms into a working dnf repository inside an air-gapped network. It walks through the structure of the repodata directory that createrepo_c produces and the role of repomd.xml, how to refresh incrementally with --update after adding packages, and the checksum type and metadata compression options as defined by the official man page. It then writes out both a single-server setup that uses the file scheme in baseurl and a setup that serves multiple servers over an internal HTTP mirror, each as a .repo file, explains the difference between gpgcheck and repo_gpgcheck, and describes the procedure for carrying a GPG public key into the air-gapped network and registering it, in both the rpm and rpmkeys spellings. Finally it untangles the dnf metadata cache problem that catches people more often than anything else in an air-gapped network, using the per-subcommand behaviour of dnf clean and the metadata_expire setting.</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>linux</category><category>rhel</category><category>air-gap</category><category>dnf</category><category>createrepo</category><category>rpm</category><category>package-management</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-build-local-repo.ja</guid>
    <title>閉域網の中にローカルリポジトリを作る — createrepo_c、repodata、.repo ファイルと GPG キー</title>
    <link>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-build-local-repo.ja</link>
    <description>持ち込んだ rpm の束を閉域網の中で正常な dnf リポジトリに仕立てるまでの全工程を扱います。createrepo_c が生成する repodata ディレクトリの構造と repomd.xml の役割、パッケージを追加したときに --update で増分更新する方法、そしてチェックサムタイプとメタデータ圧縮オプションを公式 man ページ基準で整理します。続いて baseurl に file スキームを使う単一サーバー構成と、社内 HTTP で複数サーバーへ配布する構成をそれぞれ .repo ファイルとして書き、gpgcheck と repo_gpgcheck の違い、GPG 公開鍵を閉域網へ持ち込んで登録する手順を rpm と rpmkeys の両方の表記で説明します。最後に、閉域網でもっとも頻繁に人を捕まえる dnf メタデータキャッシュの問題を、dnf clean のサブコマンドごとの動作と metadata_expire 設定で解きほぐします。</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>linux</category><category>rhel</category><category>air-gap</category><category>dnf</category><category>createrepo</category><category>rpm</category><category>package-management</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-build-local-repo</guid>
    <title>폐쇄망 안에 로컬 저장소 만들기 — createrepo_c, repodata, .repo 파일과 GPG 키</title>
    <link>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-build-local-repo</link>
    <description>반입한 rpm 묶음을 폐쇄망 안에서 정상적인 dnf 저장소로 만드는 전 과정을 다룹니다. createrepo_c가 만들어 내는 repodata 디렉터리의 구조와 repomd.xml의 역할, 패키지를 추가했을 때 --update로 증분 갱신하는 법, 그리고 체크섬 타입과 메타데이터 압축 옵션을 공식 man 페이지 기준으로 정리합니다. 이어서 baseurl에 file 스킴을 쓰는 단일 서버 구성과 사내 HTTP로 여러 서버에 배포하는 구성을 각각 .repo 파일로 작성하고, gpgcheck와 repo_gpgcheck의 차이, GPG 공개키를 폐쇄망에 반입해 등록하는 절차를 rpm과 rpmkeys 양쪽 표기로 설명합니다. 마지막으로 폐쇄망에서 가장 자주 사람을 잡는 dnf 메타데이터 캐시 문제를 dnf clean의 하위 명령별 동작과 metadata_expire 설정으로 풀어냅니다.</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>linux</category><category>rhel</category><category>air-gap</category><category>dnf</category><category>createrepo</category><category>rpm</category><category>package-management</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-download-with-dependencies.en</guid>
    <title>Downloading on the Outside for an Air-Gapped Transfer — dnf download, reposync, and yumdownloader Solve Different Problems</title>
    <link>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-download-with-dependencies.en</link>
    <description>A command-by-command walkthrough of the real procedure for pulling RHEL packages, dependencies and all, on an internet-connected machine so the result can be carried into an air-gapped network. It covers exactly what --resolve and --alldeps do differently in dnf download, why dependencies quietly go missing because of packages that are already installed on the download host, and how creating an empty root with --installroot removes that trap, quoting the official documentation directly. It also covers the fact that in an empty installroot the release version is not derived from the rpmdb, so the transaction fails unless --releasever is passed, and that modular systems additionally need module_platform_id set. It then organises the options of dnf reposync, which clones a repository wholesale, around --download-metadata, --newest-only, --gpgcheck, and --delete, explains when yumdownloader is the right call, and finishes with how to verify that what you downloaded is dependency-complete using dnf repoclosure. A table compares the option names that change under dnf5 on RHEL 10.</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>linux</category><category>rhel</category><category>air-gap</category><category>dnf</category><category>rpm</category><category>reposync</category><category>package-management</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-download-with-dependencies.ja</guid>
    <title>閉域網への持ち込みのために外側で受け取る — dnf download、reposync、yumdownloader はそれぞれ別の問題を解きます</title>
    <link>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-download-with-dependencies.ja</link>
    <description>インターネットに接続された機材で RHEL パッケージを依存関係ごとまとめて受け取り、閉域網へ持ち込むための実際の手順をコマンド単位で整理します。dnf download の --resolve と --alldeps が正確に何を変えるのか、なぜすでにインストール済みのパッケージのせいで依存関係が静かに抜け落ちるのか、そして --installroot で空のルートを作ってその落とし穴をなくす方法を、公式ドキュメントの文章とともに扱います。空の installroot では releasever が rpmdb から導出されずトランザクションが失敗するため --releasever を必ず渡さなければならないこと、モジュラーシステムでは module_platform_id まで指定しなければならないことも押さえます。続いてリポジトリ全体を複製する dnf reposync のオプションを --download-metadata、--newest-only、--gpgcheck、--delete を中心に整理し、yumdownloader をいつ使うのか、受け取った結果が依存関係の面で完全かどうかを dnf repoclosure でどう検証するのかまでつなげます。RHEL 10 の dnf5 でオプション名が変わる部分も表で比較します。</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>linux</category><category>rhel</category><category>air-gap</category><category>dnf</category><category>rpm</category><category>reposync</category><category>package-management</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-download-with-dependencies</guid>
    <title>폐쇄망 반입을 위해 밖에서 받기 — dnf download, reposync, yumdownloader는 서로 다른 문제를 풉니다</title>
    <link>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-download-with-dependencies</link>
    <description>인터넷이 연결된 장비에서 RHEL 패키지를 의존성까지 통째로 받아 폐쇄망에 반입하는 실제 절차를 명령 단위로 정리합니다. dnf download의 --resolve와 --alldeps가 정확히 무엇을 다르게 하는지, 왜 이미 설치된 패키지 때문에 의존성이 조용히 빠지는지, 그리고 --installroot로 빈 루트를 만들어 그 함정을 없애는 방법을 공식 문서 문장과 함께 다룹니다. 빈 installroot에서는 releasever가 rpmdb에서 유도되지 않아 트랜잭션이 실패하므로 --releasever를 반드시 넘겨야 한다는 점, 모듈러 시스템에서는 module_platform_id까지 지정해야 한다는 점도 함께 짚습니다. 이어서 저장소 전체를 복제하는 dnf reposync의 옵션을 --download-metadata, --newest-only, --gpgcheck, --delete 중심으로 정리하고, yumdownloader를 언제 쓰는지, 받은 결과가 의존성 측면에서 완전한지 dnf repoclosure로 어떻게 검증하는지까지 이어갑니다. RHEL 10의 dnf5에서 옵션 이름이 달라지는 부분도 표로 비교합니다.</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>linux</category><category>rhel</category><category>air-gap</category><category>dnf</category><category>rpm</category><category>reposync</category><category>package-management</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-modularity-and-versions.en</guid>
    <title>Modules and Version Pinning in an Air-Gapped Network — RHEL 8, 9, and 10 Tell Different Stories</title>
    <link>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-modularity-and-versions.en</link>
    <description>Separates out, against the official documentation, exactly where RHEL 8 modularity goes wrong in an air-gapped network and how that story changes in RHEL 9 and RHEL 10. The key point is that in a local repository built by simply copying modular RPMs, those packages quietly become invisible. It happens because dnf filters RPMs using module metadata, and there are three routes out: add --download-metadata to reposync so the module metadata comes along, use dnf modulesync to generate an entire repository that already contains the module data, or as a last resort turn on module_hotfixes to disable the filtering itself. It also covers the warning in the dnf documentation that module content is excluded when module_platform_id is not specified for an empty installroot. The second half moves on to the problem of reproduction, laying out three ways to pin the minor version with releasever, then versionlock, and finally a procedure for recording the installed state and reproducing it exactly on other servers.</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>linux</category><category>rhel</category><category>air-gap</category><category>dnf</category><category>modularity</category><category>appstream</category><category>package-management</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-modularity-and-versions.ja</guid>
    <title>閉域網でのモジュールとバージョン固定 — RHEL 8・9・10 はそれぞれ違う話をします</title>
    <link>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-modularity-and-versions.ja</link>
    <description>RHEL 8 のモジュラリティが閉域網でどこでどう詰まるのか、そして RHEL 9 と RHEL 10 でその話がどう変わるのかを、公式ドキュメント基準で分けて整理します。核心は、モジュラー RPM をただコピーして作ったローカルリポジトリでは、それらのパッケージが静かに見えなくなるという点です。dnf がモジュールメタデータを使って RPM をフィルタリングするためで、解決策は reposync に --download-metadata を付けてモジュールメタデータも一緒に取得するか、dnf modulesync でモジュールデータを含んだリポジトリを丸ごと生成するか、最後の手段として module_hotfixes を有効にしてフィルタリング自体を止めるかの 3 通りです。空の installroot で module_platform_id を指定しないとモジュールコンテンツが除外される、という dnf ドキュメントの警告もあわせて扱います。後半は再現の問題に移り、releasever でマイナーバージョンを固定する 3 つの方法と versionlock、そしてインストール済みの状態を記録して他のサーバーにそのまま再現する手順を整理します。</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>linux</category><category>rhel</category><category>air-gap</category><category>dnf</category><category>modularity</category><category>appstream</category><category>package-management</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-modularity-and-versions</guid>
    <title>폐쇄망에서 모듈과 버전 고정 — RHEL 8·9·10이 서로 다른 이야기를 합니다</title>
    <link>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-modularity-and-versions</link>
    <description>RHEL 8의 모듈러리티가 폐쇄망에서 정확히 어디서 꼬이는지, 그리고 RHEL 9와 RHEL 10에서 그 이야기가 어떻게 달라지는지를 공식 문서 기준으로 갈라 정리합니다. 핵심은 모듈러 RPM을 그냥 복사해서 만든 로컬 저장소에서는 그 패키지들이 조용히 보이지 않게 된다는 점입니다. dnf가 모듈 메타데이터로 RPM을 필터링하기 때문인데, 해법은 reposync에 --download-metadata를 붙여 모듈 메타데이터를 함께 가져오거나, dnf modulesync로 모듈 데이터를 포함한 저장소를 통째로 생성하거나, 마지막 수단으로 module_hotfixes를 켜 필터링 자체를 끄는 세 갈래입니다. 빈 installroot에서 module_platform_id를 지정하지 않으면 모듈 콘텐츠가 제외된다는 dnf 문서의 경고도 함께 다룹니다. 후반부는 재현의 문제로 넘어가 releasever로 마이너 버전을 고정하는 세 가지 방법과 versionlock, 그리고 설치된 상태를 기록해 다른 서버에 그대로 재현하는 절차를 정리합니다.</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>linux</category><category>rhel</category><category>air-gap</category><category>dnf</category><category>modularity</category><category>appstream</category><category>package-management</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-operations-playbook.en</guid>
    <title>The Air-Gapped Operations Playbook — Keeping Up with Security Patches, Rolling Back, and Managing CVE Lag</title>
    <link>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-operations-playbook.en</link>
    <description>The story that begins after the transfer procedure is finished — the operations chapter, about running an air-gapped network for years. It first makes clear that slow CVE response inside an air-gapped network is not team laziness but a structural consequence of the transfer cadence, and then covers how to measure and manage that lag once you accept you cannot remove it. It lays out, against the official documentation, how to count what is backed up using dnf updateinfo and the --security family of options, but it starts with the common trap where those commands print nothing at all against a transferred repository — the problem of updateinfo metadata vanishing during the transfer. It then explains how to extract the difference between two transfer snapshots with dnf repodiff as review material, how to manage mirror capacity with repomanage, and how to roll back with dnf history while telling apart the things that must never be rolled back, such as the kernel and glibc. It closes with a cadence design that carries both a scheduled and an emergency transfer path, plus an operations checklist.</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>linux</category><category>rhel</category><category>air-gap</category><category>dnf</category><category>security</category><category>cve</category><category>operations</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-operations-playbook.ja</guid>
    <title>閉域網の運用プレイブック — セキュリティパッチに追随し、ロールバックし、CVE 遅延を管理する</title>
    <link>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-operations-playbook.ja</link>
    <description>持ち込み手順が完成したあとの話、つまり閉域網を何年も回していく運用編です。まず閉域網で CVE 対応が遅れるのはチームの怠慢ではなく持ち込み周期という構造のせいであることをはっきりさせ、その遅延をなくせないのなら、どう測定して管理するかを扱います。dnf updateinfo と --security 系のオプションで何が滞留しているかを数える方法を公式ドキュメント基準で整理しつつ、持ち込みリポジトリでこれらのコマンドが何も出力しないという頻出の罠 — updateinfo メタデータが持ち込みの過程で消える問題 — を先に押さえます。続いて dnf repodiff で 2 つの持ち込みスナップショットの差分を審査資料として取り出す方法、repomanage でミラー容量を管理する方法、dnf history でロールバックしつつ、カーネルや glibc のようにロールバックしてはいけないものを見分ける方法を説明します。最後は定期持ち込みと緊急持ち込みという 2 つの経路を備えた周期設計と、運用チェックリストです。</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>linux</category><category>rhel</category><category>air-gap</category><category>dnf</category><category>security</category><category>cve</category><category>operations</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-operations-playbook</guid>
    <title>폐쇄망 운영 플레이북 — 보안 패치를 따라가고, 롤백하고, CVE 지연을 관리하기</title>
    <link>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-operations-playbook</link>
    <description>반입 절차가 완성된 다음의 이야기, 즉 폐쇄망을 몇 년간 굴리는 운영 편입니다. 먼저 폐쇄망에서 CVE 대응이 늦어지는 것이 팀의 게으름이 아니라 반입 주기라는 구조 때문임을 분명히 하고, 그 지연을 없앨 수 없다면 어떻게 측정하고 관리할지를 다룹니다. dnf updateinfo와 --security 계열 옵션으로 무엇이 밀려 있는지 세는 방법을 공식 문서 기준으로 정리하되, 반입 저장소에서 이 명령들이 아무것도 출력하지 않는 흔한 함정 — updateinfo 메타데이터가 반입 과정에서 사라지는 문제 — 을 먼저 짚습니다. 이어서 dnf repodiff로 두 반입 스냅샷의 차이를 심의 자료로 뽑아내는 법, repomanage로 미러 용량을 관리하는 법, dnf history로 롤백하되 커널과 glibc처럼 롤백하면 안 되는 것을 구분하는 법을 설명합니다. 마지막은 정기 반입과 긴급 반입 두 경로를 갖춘 주기 설계와 운영 체크리스트입니다.</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>linux</category><category>rhel</category><category>air-gap</category><category>dnf</category><category>security</category><category>cve</category><category>operations</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-why-its-hard.en</guid>
    <title>Why Installing RHEL Packages in an Air-Gapped Network Is Genuinely Hard — Dependencies Are a Graph, and You Cannot Solve It from the Inside</title>
    <link>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-why-its-hard.en</link>
    <description>Explains from first principles why bringing RHEL packages into a locked-down network for finance, government, or defense never ends at &quot;just copy one rpm file&quot;. It covers the fact that RPM dependencies are a symbol-level graph rather than a flat list, that the depsolver which resolves that graph needs full repository metadata that does not exist inside the air-gapped side, and that the real problem is therefore moving a resolved transaction rather than moving files. It then walks through how Red Hat content is distributed across BaseOS and AppStream, the role of subscriptions and entitlements, the version drift that comes from repositories being a moving target, and how RHEL 8 modularity changed in RHEL 9 and RHEL 10 according to the official documentation. For readers without a subscription it also covers how far CentOS Stream, Rocky, and Alma can reproduce the same behaviour.</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>linux</category><category>rhel</category><category>air-gap</category><category>dnf</category><category>rpm</category><category>package-management</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-why-its-hard.ja</guid>
    <title>RHEL 閉域網インストールが本当に難しい理由 — 依存関係はグラフであり、内側からは解けません</title>
    <link>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-why-its-hard.ja</link>
    <description>金融・公共・防衛の閉域網に RHEL パッケージを持ち込んでインストールするとき、なぜ「rpm ファイルを 1 つコピーする」で終わらないのかを構造から整理します。RPM の依存関係がリストではなくシンボル単位のグラフであること、そのグラフを解く depsolver がリポジトリメタデータ全体を必要とするのに閉域網の内側にはそれが存在しないこと、したがって問題は「ファイルを移すこと」ではなく「解決済みのトランザクションをまるごと移すこと」になることを押さえます。続いて BaseOS と AppStream に分かれた Red Hat コンテンツの配信構造とサブスクリプション・エンタイトルメントの役割、リポジトリが動き続けるために生じるバージョンドリフト、そして RHEL 8 のモジュラリティが RHEL 9 と RHEL 10 でどう変わったのかを公式ドキュメント基準で比較します。サブスクリプションがない読者のために、CentOS Stream・Rocky・Alma でどこまで再現できるのかも書きました。</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>linux</category><category>rhel</category><category>air-gap</category><category>dnf</category><category>rpm</category><category>package-management</category>
  </item>

  <item>
    <guid>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-why-its-hard</guid>
    <title>RHEL 폐쇄망 설치가 어려운 진짜 이유 — 의존성은 그래프이고, 그 그래프는 안쪽에서 풀 수 없습니다</title>
    <link>https://www.youngju.dev/blog/linux/2026-08-14-rhel-airgap-why-its-hard</link>
    <description>금융·공공·국방 폐쇄망에 RHEL 패키지를 반입해 설치할 때 왜 &quot;rpm 파일 하나 복사&quot;로 끝나지 않는지를 구조부터 정리합니다. RPM 의존성이 목록이 아니라 심볼 단위 그래프라는 점, 그 그래프를 푸는 depsolver가 저장소 메타데이터를 필요로 하는데 폐쇄망 안에는 그 메타데이터가 없다는 점, 그래서 문제가 &quot;파일 옮기기&quot;가 아니라 &quot;해결된 트랜잭션을 통째로 옮기기&quot;가 된다는 점을 짚습니다. 이어서 BaseOS와 AppStream으로 나뉜 Red Hat 콘텐츠 배포 구조와 서브스크립션·엔타이틀먼트의 역할, 저장소가 계속 움직이기 때문에 발생하는 버전 드리프트, 그리고 RHEL 8의 모듈러리티가 RHEL 9와 RHEL 10에서 어떻게 달라졌는지를 공식 문서 기준으로 비교합니다. 서브스크립션이 없는 독자를 위해 CentOS Stream·Rocky·Alma로 무엇까지 재현할 수 있는지도 함께 적었습니다.</description>
    <pubDate>Fri, 14 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>linux</category><category>rhel</category><category>air-gap</category><category>dnf</category><category>rpm</category><category>package-management</category>
  </item>

    </channel>
  </rss>
