コンテナイメージなのにブート可能な新技術による「Image mode for Red Hat Enterprise Linux」、Red Hatが発表。レジストリなどのコンテナ関連ツールがそのまま利用可能
コンテナイメージなのにブート可能な新技術による「Image mode for Red Hat Enterprise Linux」、Red Hatが発表。レジストリなどのコンテナ関連ツールがそのまま利用可能 Dockerコンテナで使われるコンテナイメージは、そもそもOSのカーネルなどが含まれていないためそれ単体で実行することはできず、コンテナに対応したOSの上にデプロイすることで実行されます。 このコンテナイメージのフォーマットは業界標準の「OCIコンテナ」（Open Container Initiativeコンテナ）として標準化されていますが、このOCIコンテナのフォーマットを守りつつ、ベアメタルサーバ上でブート可能な「ブータブルコンテナイメージ」の開発が進められています。 ブータブルコンテナイメージとは？ ブータブルコンテナイメージは、カーネルやデーモンなどの単独で実行可能なOSとしての
Fedora 41ではX.Orgセッションをデフォルトから削除へ ―加速するX.Orgからの脱却 | gihyo.jp
Linux Daily Topics Fedora 41ではX.Orgセッションをデフォルトから削除へ ―加速するX.Orgからの脱却 GNOMEのウィンドウマネージャとしてWaylandコンポジタのMutterが普及するにしたがい、長くディスプレイサーバのデフォルトであったX.Orgが使われるケースは徐々に少なくなっている。2022年4月にリリースされた「Ubuntu 22.04 LTS」でWaylandがデフォルトとなってからはその流れがさらに加速しており、これまでWaylandとX.Orgの両方をサポートしていたディストリビューションも次々とWaylandオンリーにサポート方針を変更している。 2023年4月に「Fedora Linux 40」のリリースを予定しているFedoraプロジェクトもまた、X.Orgからの脱却をより進めていく姿勢を明らかにしている。Ferora Workst
第55回 コンテナと仮想マシンのマネージャ"Incus" | gihyo.jp
この連載は、「LXCで学ぶコンテナ入門」というタイトルです。序盤を除くと、LXC自身を紹介するというよりは、Linuxカーネルに実装されているコンテナ関連の機能を紹介をすることが多く、カーネルの機能を紹介する際に、実行例でLXCを使ってきました。その後、LXCを開発しているLinuxContainersプロジェクトからは、コンテナマネージャとしてLXDの開発がスタートし、この連載でもLXDを使ってカーネルの機能を説明することがありました。 LXDは、コンテナと仮想マシンの両方を管理できるマネージャソフトウェアです。LXCもLXDも、OS環境を起動させるシステムコンテナを扱うことを主眼に開発されています。 gihyo.jpでは、LXDについては本連載ではなく、Ubuntu Weekly Recipeで柴田充也さんが頻繁に取り上げており、基本的な操作から応用まで幅広い話題が紹介されています。
第54回 Linuxカーネルのコンテナ機能 ―cgroup v2から使うCPUの帯域幅制限（2） | gihyo.jp
前回は、CPUコントローラでの帯域幅制限がどのように行われるのかについて簡単に説明しました。 前回の最後に、説明のために挙げた例がかなり理想的な状況であると書きました。今回は、帯域幅制限の機能を詳しく見ていくために、前回よりはもう少し複雑な状況について説明していきましょう。 未使用クォータの返却 前回説明で示した例では、CPUは割り当てられたスライスをすべて使いきっていました。しかし、複数のCPUがある環境で、タスクが終了したり、I/O待ちなどにより、クォータが割り当たったCPUで実行可能なタスクがなくなった場合はどうなるでしょう? 図1 割り当てられたスライスが使われない場合 図1のように、クォータプールに10msクォータが残っているとします。 ①でCPU1でCPUを使用するタスクから要求がありスライスが転送され、クォータの残りが5msとなりました ②で再度CPU1でCPUを使用するタス
Linuxを再起動することなくカーネルにパッチを当てる「ライブパッチ」の技術的な仕組みと、その種類とは［PR］
Linuxを再起動することなくカーネルにパッチを当てる「ライブパッチ」の技術的な仕組みと、その種類とは［PR］ Linuxのアップデートパッチは脆弱性の大小にかかわらず、ほぼ毎月のように登場しているのが現状です。 パッチの適用を放置することは脆弱性を放置することにつながるため、脆弱性対策のパッチが公開されたならば、迅速なパッチの適用が望まれます。特に最近ではセキュリティの脆弱性を突かれたことで深刻な被害を被る企業などの事例が社会的な注目を集めるようになっており、迅速なパッチ適用の重要性は高まってきています。 一方で、ビジネス上の要請としては計画停止であってもサーバの停止は最低限で済ませることが望ましいとされています。計画停止であっても、数分から長いときには数十分かかるLinuxサーバの再起動を伴うアップデート作業を可能な限り回避したいという要望は変わらないでしょう。 ITの現場はこの、セキ
LXDから新コンテナプロジェクト「Incus」がフォーク | gihyo.jp
Linux Containersプロジェクトは8月7日、LXDからフォークした新たなLinuxコンテナプロジェクト「Incus」をローンチしたことを発表した。2023年7月にそれまでLinux Containersプロジェクトの管理下にあったLXDプロジェクトをCanonicalが直接管理するようになったことを受けてのフォークで、openSUSEでLXDのパッケージングを行ってきたAleksa Sarai（SUSE所属）が作成したプロダクトをベースに開発が行われることになる。 Introducing Incus -linuxcontainers.org lxc/incus : Powerful system container and virtual machine manager -GitHub IncusはLXDがCanonicalの管理下に移った直後（LXD 5.16リリース直後）に
InferでLinuxカーネルのメモリ関連エラーを検出してみる - VA Linux エンジニアブログ
1. 静的コード解析 2. Infer 3. 調査環境 4. Inferのビルド 5. Inferで解析できるようにLinuxカーネルソースコードに少し修正を加える 6. LinuxカーネルソースコードをInferで検証 7. 解析結果に対する精査の一例 7.1. 真のバグの例 7.2. フォールスポジティブの例 7.3. 真のバグか判断に困るものの例 8. 結論とこれから 執筆者 : 岡部 究 1. 静的コード解析 普段の開発で品質向上させるためにどのような手法を採用されているでしょうか。おそらくユニットテストや結合テストを代表するテストを使っているのではないでしょうか。 このテスト手法は現実的ですがざっと挙げるだけでも以下の課題があります: 入力と出力をテストケースと呼ばれる例として与えるので全ての場合を網羅することは不可能 テストの網羅率を上げるにはユニットテストのような小さい単位で
Debian、RISC-Vを正式なアーキテクチャとしてサポートへ | gihyo.jp
Debian開発者のAurelien Jarnoは7月23日、DebianプロジェクトのRISC-V開発者向けメーリングリストに「riscv64 is now an official architecture」と題したメッセージを投稿、次期リリースの「Debian 13 "Trixie"」ではRISC-Vが正式なCPUアーキテクチャ（riscv64）としてサポートされることを明らかにした。 riscv64 is now an official architecture -lists.debian.org この決定に従い、RISC-VチームはRISC-Vパッケージのビルド作業を進めていくことになる。現時点ではまだパッケージングの初期段階であるため、RISC-V用のSidやExperimentalのアーカイブはほとんど空の状態だが、開発チームのManuel Fernandez Montecel
Linux 6.4がリリース、Apple M2シリコンをイニシャルサポート | gihyo.jp
Linux Daily Topics Linux 6.4がリリース、Apple M2シリコンをイニシャルサポート Linus Torvaldsは2023年6月25日（米国時間）、「Linux 6.4」の正式リリースを発表した。開発期間は約2ヵ月、通常のスケジュール通りに7本のリリース候補（RC）版を経ての公開となる。 Linux 6.4 -Linus Torvalds Linux 6.4ではAsahi Linuxプロジェクトの貢献により、Apple M2シリコンを搭載したMacBook Air、MacBook Pro、Mac miniが新たにサポートされた。ただし、現状ではM2 Mac miniのディスプレイ出力に問題があるなどいくつかの不具合が生じており、Linux 6.5以降での改善が予定されている。 Rustのサポートも強化されており、ピン留めされたデータの安全な初期化を実現
第52回 Linuxカーネルのコンテナ機能 ― cgroupを使ったI/O制限 | gihyo.jp
第37回で説明した通り、cgroup v1には様々な問題点が指摘されており、その問題を解決すべくcgroup v2が実装されました。 cgroup v1では、各コントローラがバラバラに実装されており、コントローラ間の連携が取れませんでした。これが原因で、リソースを制限するにあたって一番表面化していた問題が、ディスクI/Oに対して制限をかける際の問題でした。cgroup v1ではblkioコントローラでI/Oに対する制限をかけられましたが、限定的な制限しかかけられませんでした。 LinuxでのI/O コントローラ間で連携ができないため、blkioコントローラを使ったI/O制限が限定的になってしまう理由を説明するために、Linuxでディスクへファイル入出力する際の仕組みを簡単に説明しておきましょう。もう少し詳しい仕組みが知りたい方は『［試して理解］Linuxのしくみ』など、関連する書籍や文書を
第51回 Linuxの非特権コンテナで利用するID mappedマウント（2） | gihyo.jp
前回は、ユーザ名前空間を使った一般ユーザ権限で起動するコンテナ（非特権コンテナ）から、コンテナのファイルシステムを使用する際の問題と、その問題を解決するためにID mappedマウントが利用できることを説明しました。そして、ID mappedマウントの簡単な動きを説明しました。 今回は、ひきつづきmount-idmappedコマンドを使いながら、実際のユースケースに近い動きを見ていきましょう。 コンテナから利用するID mappedマウント まずは一般ユーザ権限で起動するコンテナから、ID mappedマウントを利用した際の動きを見てみましょう。 一般ユーザ権限で起動するコンテナから、ID mappedマウントを利用する際に確認する動きは図1のようになります。前回説明したID mappedマウントの動きに、さらにユーザ名前空間が使うマッピングが適用されますので、方向が逆の変換が2度行われる
第50回 Linuxの非特権コンテナで利用するID mappedマウント（1） | gihyo.jp
2014年に始めたこの連載もついに50回になりました。この連載は当初12回の予定で、LXCの機能を中心に紹介するつもりでした。しかし、書いているうちに予定の回数には収まらないほど書きたいことが出てきて、結局予定していた内容を書き終えたのは第26回でした。 内容についてはLXCの機能について書いたあとは、Linuxカーネルに実装されるコンテナ関連機能の紹介が中心になりました。ここ数年はLinuxカーネルに実装されるコンテナ関連の大きな機能の追加が少なくなったことと、それ以上に筆者が新しい機能を勉強する時間が少なくなり、記事として書ける内容を取得するスピードが減速したので、新しい記事を書く頻度は減りました。 このようなマイペースな連載に長くお付き合いいただきありがとうございます。スピードが減速したとはいえ、まだ書きたいネタがなくなったわけではないので引き続きお付き合いいただければと思います。
PyTorch strengthens its governance by joining the Linux Foundation
by Soumith Chintala Today, I am proud to announce that PyTorch is moving to the Linux Foundation (LF) as a top-level project under the name PyTorch Foundation. The core mission of the Linux Foundation is the collaborative development of open source software. With a governing board of leaders from AMD, Amazon Web Services (AWS), Google Cloud, Meta, Microsoft Azure and NVIDIA, this model aligns with
Nvidia takes first step toward open source Linux GPU drivers
After years of hinting, Nvidia announced yesterday that it would be open-sourcing part of its Linux GPU driver, as both Intel and AMD have done for years now. Previously, Linux users who wanted to avoid Nvidia's proprietary driver had to rely on reverse-engineered software like the Nouveau project, which worked best on older hardware and offered incomplete support at best for all of Nvidia's GPU f
2022年4月12日 Fedora、レガシーBIOSのサポートを段階的に終了へ | gihyo.jp
Fedoraプロジェクトは4月8日、2022年秋にリリース予定の「Fedora Linux 37」で新規インストールにおけるハードウェア要件を変更する方針を明らかにした。新規インストールを実施するハードウェア（x86_64）はUEFIサポートであることが必須となり、レガシーBIOSサポートは継続されるものの、非UEFIハードウェアに新たにFedoraをインストールすることははできなくなる。 Changes/DeprecateLegacyBIOS -Fedora Project Wiki Fedoraプロジェクトでは2020年にレガシーBIOSのサポート終了に関して議論が行われたが、「BIOSしかサポートしないマシンも多い」「レガシーBIOSからUEFIへの移行方法がない」などの理由からサポート終了の判断は見送られてきた。一方で現在のFedoraでは2GHzのデュアルコアCPUが最小ハー
2022年3月1日 古いコードはコストがかかる ―LKML、ReiserFSの削除について議論 | gihyo.jp
Linux Daily Topics 2022年3月1日古いコードはコストがかかる ―LKML、ReiserFSの削除について議論 2001年の「Linux 2.4.1」でマージされたReiserFSは、Linuxカーネルがサポートするジャーナリングファイルシステムの中でも最も古いものである。これまで20年以上に渡ってサポートされてきたReiserFSだが、Btrfsやext4といったメジャーなジャーナリングファイルシステムと比較すると、本番環境で使われているケースは非常に少なくなっている。この現状に対し、古参メンテナーのひとりであるMatthew Wilcox（Oracle）がLinux開発者のメーリングリスト「LKML.org」に「Is it time to remove reiserfs? （ReiserFSを取り除くときが来たんじゃないか）」と2月20日に投稿、開発者の間で議
2022年2月1日 Qualys、主要Linuxディストリビューションに「Polkit」の脆弱性を警告 | gihyo.jp
Linux Daily Topics 2022年2月1日Qualys、主要Linuxディストリビューションに「Polkit」の脆弱性を警告 クラウドセキュリティベンダのQualysは1月25日（米国時間）、LinuxやUNIX系OSのほとんどに含まれるコンポーネント「Polkit」（旧PolicyKit）の脆弱性「PwnKit」に関するブログを公開した。同ブログによれば、Ubuntu、Debian、Fedora、CentOSなどメジャーなLinuxディストリビューションのほとんどが本脆弱性の影響を受けることから、早急な対応が求められている。 PwnKit: Local Privilege Escalation Vulnerability Discovered in polkit’s pkexec (CVE-2021-4034) | Qualys Security Blog Polki
2022年1月21日 SUSE、RHELやCentOSも対象にしたサポートプログラム「SUSE Liberty Linux」を発表 | gihyo.jp
Linux Daily Topics 2022年1月21日SUSE、RHELやCentOSも対象にしたサポートプログラム「SUSE Liberty Linux」を発表 SUSEは1月19日、同社が開発する「openSUSE」や「SUSE Linux Enterprise Server（SLES）」だけではなく「Red Hat Enterprise Linux（RHEL）」や「CentOS」など複数のLinuxディストリビューションが混在したエンタープライズ環境をサポートする「SUSE Liberty Linux」プログラムを発表した。 SUSE Liberty Linux – Securing your Linux future without vendor lock in -SUSE Communities SUSE Liberty LinuxはSUSEを含む複数のベンダから構成
第48回 cgroup v2から使うコントローラとmiscコントローラ | gihyo.jp
5.13カーネルを使っており、デフォルトでcgroup v2のみがマウントされているUbuntu 21.10の環境では、root cgroup配下のcgroup.controllersは次のようになっています。 $ uname -r 5.13.0-21-generic $ grep cgroup /proc/self/mountinfo 35 25 0:30 / /sys/fs/cgroup rw,nosuid,nodev,noexec,relatime shared:9 - cgroup2 cgroup2 rw,nsdelegate,memory_recursiveprot $ cat /sys/fs/cgroup/cgroup.controllers cpuset cpu io memory hugetlb pids rdma misc Ubuntu 21.10のような新しい環境では、
2021年12月15日 Fedora、来春リリースのFedora 36でlocateコマンドに「plocate」を実装へ | gihyo.jp
Linux Daily Topics 2021年12月15日Fedora、来春リリースのFedora 36でlocateコマンドに「plocate」を実装へ Fedoraプロジェクトは12月9日、2022年4月にリリースを予定している次期バージョン「Fedora 36」において、ファイルの高速検索を行うlocateコマンドを、現在の「mlocate」から「plocate」にリプレースする方針を明らかにした。 Changes/Plocate as the default locate implementation -Fedora Wiki plocate, a much faster locate plocateはすでにDebianなどでもデフォルト採用されているlocateコマンドの実装で、mlocateよりも高速なファイル検索が実行でき、さらにディスク上に生成されるデータベースがmloc
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
