南関東最速!
どこよりも遅く、限りなく個人的な
Red Hat Summitセッションレポート'19 Boston

5月 7~9に掛けて米国ボストンで開催された Red Hat Summit 2019に参加してきましたので、今更ながら遅報させて頂きます。


 フィリップ K ディック原作の Impostorと云う映画を見ましたけど、私も自分が使っている OSが本当は何なのかよく分からない状況に陥いる事があります。単なる錯覚なのか自分が思っているのとは違う OSなのか判断ができなくなり、何度も #uname -aしたり /etc/redhat-releaesをしつこく #catしたりします。カプグラ症候群(Capgras delusion:入替わりや偽物だと思い込む)って IT業界にも蔓延している気がします...


 最初にお断りしておきますが、Red Hat Summitでは同時に複数のセッションやトレーニングセッションが開催される形式です。セッションとラボを合わせた数は約 360本です。当方の仕事柄 Red Hat Enterprise Linuxを中心にセッションの受講を行いましたので、本書での内容も Linuxを中心とした話となります。特に、OpenShift 4に興味のある方はこちらから直接資料等を参照してください。

 

 Red Hat Summitに参加するのは 2015年以来 5回目です。会場はボストンの中心に位置する Back Bayエリアのプルデンシャルセンターの Hynes Convention Centerではなく Bayエリアの Boston Convention and Exhibition Centerに戻りました。参加者は 8,300人と発表されています。今回の Red Hat Summitのテーマは「 EXPAND 」らしく EXPと ANDが二段に分けて表示されている事があり、Experience And...と云うダブルミーニングなのかと思われます。あと開催期間が以前とは異なり 4日間ではなく 3日間になっていたので、同じセッションが別の日に再度行われる率が減っており、Red Hat Enterprise Linux以外のセッションに参加するのが厳しかったのが残念ではあります。前日泊を含めると 5日もしくは 6日は米国内の参加者からすると長い(!)との判断なのでしょうかね。

 2015年の際は Red Hat Summit&JBoss Worldでしたが、今回 JBoss Worldの冠は外れていました。また、セッションを見ても JBossの文字は殆ど見受けられませんでした。勿論 JBossがなくなった訳ではありません。これは Red Hat社がテクノロジーを前面に出すのではなく製品名としてのフレームワークを前面に出す方針に変わったらしい事に由来しているのだと思われます。

 会場についてまっさきに違和感を感じました。「Red Hatロゴのフォントが変わった」と。Red Hat社はコミュニティにアンケートを取り Red Hatに必要なロゴは何であるかのアンケートを取ったところ、赤い帽子(Fedora)が圧倒的であり、Shadowmanは思ったよりも必要とされていないとの事で今回リストラされました。フォントも柔らかい感じのものに変更されています。このタイミングは IBM社に 340億ドルで買収された事での CI(コーポレートアイデンティティ)の変更だと思われます。ちなみに、Shadowmanは 1997年から採用されたとの事ですので、当 Linuxサイトの 1999年よりも古かったのは驚きです。

画像1

画像2

画像3

画像4

セッション

 

 従来、と云っても 4年前迄ですが... セッション内容は後日かなりのものが PDFで公開されてきましたが、2年ぐらい前から公開数が減っている感じがします。毎回公開されていた筈の Performance Tuning Iも非公開になっていました。参加したセッションのプレゼンは全て写真に収めましたが、一部をかいつまんでみたいと思います。前述の URLでリストされるタイトル名と実際の PDFのタイトルは厳密に一致していないものがあるため、本書では検索し易い様に前述の URLに表示されるタイトル名で記載しています。資料の検索はこちらから。
 

 A day in the life without Docker: A developers guide

 次世代のコンテナツールとして buildah, podman, skopeoが紹介されています。これらは一足先に Red Hat Enterprise Linux 7.6に取り込まれているものです。今後の Red Hat環境では #dockerコマンドを始めとしたツール群はこれらに変更置き換わり使われていく方向となります。その理由として挙げられたのは、オープンである事、そしてセキュリティへの取り組みが強力である事があげられていました。

 Demystifying systemd

 systemdが 10周年だそうです。私はこのセッションに参加していないので PDFを読んだだけですが、Red Hat Enterprise Linux 8.1から実装されるセキュリティ解析機能が気になります。cgourps v2についての cheat sheetが記載されています。


 Managing and using application stream content in Red Hat Enterprise Linux 8 ---> Apprecation Streamsについて

 Red Hat Enterprise Linux 8の ISOメディアを覗いてすぐに従来とは異なる事が分かります。レポジトリが従来の Packages配下にまとまっていたものが Packagesだけだったものが、AppStreamと BaseOSに分離しています。また、これらのサポート方針も大きく変更されています。従来までの Red Hat Enterprise Linuxでは基本として kernelは互換性を保つために同一バージョンを利用し、同梱されるアプリケーションも最初に同梱されたメジャーバージョンをサポートし続けられるという方針でした(OpenJDK等の例外はあります)が、今後アプリケーションは Red Hat Enterprise Linux 8の kernelとは別のタイムラインで新しいメジャーバージョンに変更される事がある事を意味しています。これはアプリケーションの upstream側での開発ベースのタイムラインに合わせていく事を意味します。最新のアプリケーションを使いたいユーザは歓迎しますが、同じバージョンのアプリケーションを使い続けたいユーザには多少面倒な事になります。今後は Red Hat Enterprise Linuxを長期で利用する場合には、アプリケーション個別のサポートタイムラインを意識していく必要があります。


 Managing Red Hat Enterprise Linux 8

 Apprecation Stream、Red Hat Insights等の Red Hat Enterprise Linux 8における新機能の紹介を主にしたセッションです。Insights自体は従来もありましたが、今回を機にサブスクリプション登録をしているシステムでは追加料金なしで利用が可能に変更されています。

セッション画像1

セッション画像2

セッション画像3

セッション画像4

 Red Hat Enterprise Linux 8 networking: The accelerator for bare metal, virtual, container, and hybrid clouds

 eBPF(extended Barkley packet filter)を利用した XDP(express data path)での DDOS攻撃を緩和する等の話が盛り込まれたセッションです。

 個人的には、今回の Red Hat Summitでの一番の目玉になるかと思っていた XDP(express data path)の説明が思ったよりもなかったのが意外でした。これは恐らく皆が使う機能ではない事もありますが、Red Hat Enterprise Linux 8.0のリリース時点では Tech. Previewだからなのかと思われます。この XDPを使う事により、ネットワークパケットの処理を kernel内部を通して行った後で dropさせるのではなく、パケットをかなり早い段階で eBPFからユーザランド側に引き渡して dropさせてしまう処理をさせている例が取り上げられていました。DPDK(data plane developer kit)に近い動きをしますが、DPDKは NICのポートが kernelから全く見えなくなるため DPDK対応のアプリが必要なだけではなく #dpdk-devbind -bで DPDKに割り当てた NICのポートは eth0/eno1等としても全く認識できないのに対して、XDPは通常使う eth0/eno1の中でも特定のパケットだけを eBPFがキャプチャして kernel側にパケットを流さない仕組みとなっています。この仕組みは SP(service provider)系とよばれるインターネットに直接サーバを大量に接続される顧客にはかなりメリットが大きい仕組みだと思われます。

セッション画像5

セッション画像6

 Red Hat Enterprise Linux roadmap

 従来の Red Hat Enterprise Linuxではメジャーバージョンとマイナーバージョンのリリース時期は未確定でしたが、Red Hat Enterprise Linux 8からは今後はそれぞれが 3年毎、半年毎にリリースされる事となります。運用側としてはアップデートの時期が予測しやすくなるかと思われます(名称も Predictable Releasesですし)。ですが、ハードウェアの更新時期、これは主にプロセッサーの変更とはずれてしまう事を意味するため厳しい面も予想されるかとは思いますが、逆にプロセッサーベンダーとの連携でなんとかなるのかもしれません。そもそもこのリリース時期を 5年から 3年にそして、半年毎のリリースとしているのは、セッション内では触れられていませんが、あきらかに Canonical社の Ubuntuに対抗していると思われます。Ubuntuの LTS(long-term support)は 2年ですが、それでも大きく短縮化が図られていますので、新しい kernelを利用したい HPC(high perforamance computing)をはじめとした顧客には刺さるのかと思われます。個人的に懸念なのは従来は kernelバージョンが固定された Red Hat Enterprise Linuxに対しても新機能の back-portが行われてきましたが、このモチベーションが 3年毎のメジャーバージョンリリースによって多かれ少なかれ削がれる事になる気がしないでもありません。エンタープライズサイドではなくユーザサイドから開発されてくる新しいソフトウェア技術が少なくない現状を考えると Ubuntuを無視する事はもはや無理なのだとも考えられるかと思われます。そう考えると個人的には 3年毎のメジャーバージョンリリースと云うのは長すぎず、短すぎずでありエンタープライズ市場にもいい選択だと思われます。恐らく SUSEも遅かれ早かれこれに追随してくるのではないでしょうか。あと、VDOや STRATIS等のストレージ側での新機能の紹介もありました。provider)系とよばれるインターネットに直接サーバを大量に接続される顧客にはかなりメリットが大きい仕組みだと思われます。

セッション画像7

セッション画像8

セッション画像9

セッション画像10

セッション画像11

セッション画像12

セッション画像13

セッション画像14

 で、話は戻って Red Hat Enterprise Linuxのサポート期間についてもう少し説明を行います。Red Hat Enterprise Linux 7では、MS1(maintenance support)ではソフトウェアの変更を行わなずに HW Enablementの追加が可能。MS2ではバグフィックス&セキュリティフィックスのみの提供でエンハンスメントはなし。ELSの購入で MS2の延長が可能でした。Red Hat Enterprise Linux 8になると、従来の MS1と MS2の区別がなくなっており、従来の MS2が Red Hat Enterprise Linux 8での MSに相当します。EUS(extended update support)は 8.1がリリースされた後は、偶数のマイナーバージョンでリリースされます(8.1の次は 8.2、8.4...)ので、ここら辺が予めはっきりしているのが運用面で計画が建てやすいのが非常に嬉しいところです。詳細はRed Hat Enterprise Linux Life Cycleをご覧ください。

 Red Hat security roadmap : It's a lifestyle, not a product

 Container Health Indexと CoreOS Vulnerability Scanner/Clairが簡単にされていましたが、メインは OpenSCAPな感じでした。

 Red Hat Ceph Storage for high-performance workloads in BBVA

 Ciscoベースですけどパフォーマンスが出てて興味深い資料です。

 Production-ready virtualization with Red Hat

 RHV-Mでの Tech. Previewとして html5コンソールが実装され、VMware, Xen上の Debian/Ubuntuの取込みも行えます。興味深い話としては Nested Virtualizationは未だに Tech. Previewだけど世界中で使われているし、俺たちのラボでも当たり前に使っているけど、皆のとこでもそうだろ? との事でした。あと、4K nativeディスクサポートもありますけど、性能的にどのぐらい向上するのか気になりますね。

 Rook: Automating Ceph for Kubernetes via Operators

 Rookで コンテナ化した Cephを kubenetes上の podとして稼働させるものです。OpenShiftに一極集中するのを嫌がる顧客もありますが、これが安定稼働してくると OpenShiftへの一極集中にならざるを得ない感じが高まりそうな気がします。これは便利そうですし。そもそも OpenShiftのお世話とストレージのお世話をする人の統合が可能になるのは結構大きいです。

 What’s new in Red Hat Enterprise Linux 8? 

 このセッションは参加したのですが、口頭での説明が多かったので後から PDFだけを見ると分かりづらいかもしれません。結構デモを用いた説明もされていました。タイトル通りの内容で Red Hat Enterprise Linux 8の基本である、in-placeアップグレード、Image Builder、Web Console(Cockpit)、脱 docker(podman/buildah/skopeo)、Universal Base Image、Insights、Session Recordingの紹介です。

 The road ahead for Red Hat OpenStack Platform

 正直に云います。Red Hat Summitに向かう前は、OpenStackってもう下火だよなぁと思っていましたが、Red Hat Summitでは OpenStack向けのセッションは以前(4年前)よりも数は少ないですが、盛況でした。参加者が AWS(amazon web service)からの脱却とか云う汎用的な話ではなく、NFV一択と云う感じのキャリア(telco)向けな感じの内容が多かったと思います。最終的には OpenStackベースと kubernetesベースとの選択が可能になるとの事。GPU passthrough、vGPUのサポートがあります。Red Hat OpenStack(RHOS)のロードマップとして 2026年迄のものが示されていました。このセッションで無知な私が一番驚いたのは、RHOS16では SR-IOVの warmマイグレーションがサポートされるとの事でした。SR-IOVでの MACアドレスの払い出し、そして回収。その払い出しをする際に面倒なのは MACアドレスの管理等があるかと思います(IIJ様のオープンなセッションで独自実装が大変な事を聞いた事があります)。これらを自動でやってくれるならかなりいいかと思います。あと、basic FPGAサポートが追加される予定との事でした。

 

 Performance analysis and tuning of Red Hat Enterprise Linux part 1(PDFなし)

 Red Hat Summitの名物セッションとも云うべき長年続いてきたセッションですが、PDFの資料提供がありませんでした。残念です。

セッション画像15

セッション画像16

セッション画像17

 Performance analysis and tuning of Red Hat Enterprise Linux part 2

 本セッションも前述に Part Iと共に名物セッションの筈でしたが、部屋に行くとラウンドテーブルがあるだけでした。これは狭い部屋に 10人程度の Red Hat社のエンジニアを雑談しながら質問できるコーナーです。当然 PDFも用意されていません。いつからこの形式になったんだ? と質問したところ、以前からだと云われました。少なくとも 4年前には通常のセッション形式でしたので、いつの間にか変わったのでしょうね。Ummmmm...

 A practical introduction to container security using CRI-O

 本セッションも PDFは提供されておりません。ですが、スピーカー 2人の掛け合い形式での話がちょっと面白かったです。Docker批判をはっきりする訳ではないですが、オープンじゃないからダメだと云う方向で力説されておりました。

 

 ちなみに、HPEもセッションを 2ヶ実施しておりましたが、両方共に PDFでの資料公開はありませんでした(凹...

EXPO/製品展示ブース

 

 Red Hat Summiでは ISV, IHVが独自ブースを展示する一角があります。久しぶりの参加で思いましたが「まさに ITの主役はハードウェアではなくなった」と云う感じを受けました(とっくに以前からですけど)。IBMは知る限り(2010~2015年迄のしか知りませんが)、巨大な System Zを展示していましたが今回は展示がありませんでしたし、Linux on Powerや PowerLinuxの文字も見当たりませんでした(OpenPowerのブースはありました)。これは、IBMに限らず、弊社もそうですし他もそうです。どこもハードウェア上で Linuxが動くのが当たり前だから展示をやめただけかもしれませんが寂しい限りです。正直なところ Linuxを動かす箱での他社との差別化が厳しいので展示してもしょうがないのはあるかと思います。ProLiantも iLO5を中心とした差別化ポイントはありますが、Linuxに特化したというより OSに非依存な部分での差別化ですので微妙なんでしょうかね(agent-lessなのでソコがいいのですけどね!)?

 HPEブースの展示コンセプトは FEAR NO CLOUDでした。基本 Pointnext部門主体の展示でハードウェアはやはり殆どありませんでした。大手は自社ブース内に独自プレゼンコーナーを持っており HPEにもありました。プレゼンのタイトルは下記でした。完全に OpenShiftありきの内容でした。これは HPEだけではなくどのハードウェアベンダーも同じでこれに自社の構築サービスと保守サービスを組み合わせた感じのプレゼンを行っているところが多かったと思います。あと、Red Hatが OpenShiftと云うか containerに全振りしている(個人的感想です)ためか、以前ほどには OpenStackへ注力している感じは見受けられませんでした。OpenStackは Teleco向けが OpenStack + DPDK + Open vSwitchでガッチリ嵌っていますので、ここだけは固いのだと思います。あと、Microsoft社の SQL Serverのプレゼンが挟まれているのが「そういう時代なんだなぁ~」と一老人として感慨深げに眺めておりました。

  • Disaster Recovery option for your Red Hat OpenShift environment
  • Running databases in production on Red Hat OpenShiftwith Portworxand HPE
  • Infrastracture as code with HPE OneView and Ansibleby Red Hat
  • Best practice for stateful workloads on Red Hat OpenShift using SAN storage
  • Data, data everywhere... How to connect the dots in a crazy, mixed up, Hybrid world!
  • Optimizing MS SQL Server on Red Hat Enterprise Linux
  • Introducing to HPE Nimble Storage with Red Hat OpenShift
  • OpenShifton HPE's composable infrastructure
  • Open HPE Telco NFV-Infrastructure platforms with Red Hat OpenStack

 HPEから分社した DXC社ブースです。何故か SEGAの Turbo OutRunの実機が展示されていました。特段 Red Hatとかに関連している訳ではない感じです。実は HPEの海外ブースには結構な確率でレースゲームの展示がいつもありましたが、これは DXC社に転籍した個人の思惑で展示していたんじゃないかと云う疑惑が確信に変わりました(もしかすると社内の娯楽ブースに設定されているのを持ってきただけかもしれませんが)。今回の Red Hat Summitのスポンサードも HPEと DXCは別々の会社として行っていますので、以前の Platinumスポンサーではなく今回は Goldスポンサーになっていました。正直、分社によってこの手の展示会場等での会社としてのプレゼンスが後退した印象は拭えません。

休憩&娯楽

 

 参加者は丸一日会場に居るため、休憩場所や娯楽スペースも多数用意されていました。Tシャツをその場で印刷してくれたり、3Dプリンターで `8`のキーホルダーを作ってくれたり、前面鏡張りのボックスの中でブルースリーの真似をするブースがあったり、大がかりな録音メッセージが再生される未来チックな電話ブースがあったりしました。中でも面白かったのが、Command Line Heroと云う腕試しゲームが設置されていました。60秒の間に bash, html, javascript, pythonのコマンドをいくつ入力できるかを競うものです。オンライン上でも遊べます。あと、子犬と戯れるコーナーがありました。後から聞いたところによると気に入ればそのまま里親になれたみたいです

 事前に Red Hatの社員から食事は美味しくない!と聞いていたのですが、2015年の事を思えば「そんな事はないだろぉ!」と思っていましたが、少なくとも 2015年に比べると食事はトーンダウン(笑)しておりました。Red Hat Summit開始前の前日の Welcomeディナーがなくなっており、セッション中の飲み物がホットコーヒーとホットティーだけでバイト系がなくなっていました。過去 2010年とか 2011年の様に昼に温かい食べ物が無かった時代に比べれば遥かにマシではあります(人の業は深い)。ただ、EXPO/製品展示ブースでもランチ等での食事の一部が提供されているので、移動時間がとられずにゆっくり EXPO/製品展示ブースを見る事ができたので非常に助かりました。

ランチ1

ランチ2

ランチ3

 セッション会場を行き交う通路の端に Red Hat社の歩みに関するものが展示されていました。Oracle社が独自ディストリビューションの Unbreakable Linuxを発表した際に Red Hat社が発したカウンターメッセージである Unfakable Linuxが記されたTシャツやグッズが展示されていました。ちなみに Oracle社も展示ブースを出展していましたが、普通に Oracle Linux推しでした(Kspliceいいですよね)。

休憩&娯楽1

休憩&娯楽2

トレーニングついて

 

 Red Hat Summitでは各種のトレーニングが可能な LABOコーナーもありました。当方は Breakoutセッションの参加がメインですので、過去参加した Red Hat Summitではトレーニングに機材に USB-keyを差し込んで必要な資料を入手だけしたり、印刷物を持ち帰ったりして帰国後に眺めていましたが、今回は自由に参加する事ができる LABOがなく全て事前登録が必須な感じで全くアクセスできませんでした。ただ、LABOブースはいつも人だかりで、当方とは逆に LABOメインで参加している人も多い様に思われます。

Japanセッション&ディナー

 

 今回の Red Hat Summitへの日本からの参加者は Red Hat社員合わせて 150名との事です。会場のレジストレーション脇には日本人参加者のための通訳用トランシーバの貸出しが行われていました。また、二日目の午後には Japanセッションとして日本でも展開できそうな事例の紹介があったとの事です。Red Hat Enterprise Linux 8を中心とした技術セッションのメインが 2日目午後に重なったため参加しておりませんが、殆どの日本からの参加者が赴いたとの事です。

 同日夜には近隣のシーフードレストランでの Japanディナーも開催されました。当方も参加しましたが、かなりの人数での異様な盛り上がりを見せ、Red Hat社へのロイヤリティの高さに圧倒されました(弊社とは全然違うなぁと)。

 帰り道ホテルまで歩いていた際に思ったのですが... 当方が以前勤めていた企業(DEC)の本社が Bostonの左上の方だったので Bayエリアも何度か足を運んだ事がありますが、ここでの再開発がものすごい事になっており、2015年とは比べものにならないぐらいの開発ラッシュが行われています。現在、シリコンバレーに鎮座しているコンピュータ博物館(Cray Iとか展示されていますが、その Crayもかつて親会社だった SGIも HPEになっているとは当時夢にも思いませんでしたけど、DECが Compaqに買収された事に比べれば大したことないですかね)はもともとはこのエリアにあり、20年前は「すごい寂れたところにあるなぁ」と云う感じでしたが、今は豊洲か武蔵小杉かと思うぐらいの再開発ラッシュが行われています。当時と云うか前回の 2015年当時もフリーウェイも電車も通っていなかった筈で、Red Hat社が用意したバスで来るしかありませんでした。そもそもこの会場脇の風景写真なんて Back Bayエリアの高級住宅地にしか見えないですよね。

Japanセッション&ディナー1

Japanセッション&ディナー2

Japanセッション&ディナー3

Red Hat Professional向けイベント

 

 2015年に参加した際には RHCE等の Red Hat社の資格を持っているメンバー向けに専用イベントが開かれていましたが、今回は見当たりませんでした。そもそも首からぶら下げるバッジに `RHCE`等のタグがありませんでしたので、やっていないと思われます。以前は夜に BARを貸し切ってTシャツが配られていました。


RHEL8について

 

 今回参加の目的は Red Hat Enterprise Linux 8についてまとめてみます(既に 9月終わりそうですけど)。

 Red Hat Enterprise Linux 7での Server, Workstation, ComputeNodeが撤廃されました。但し、インストーラで問われますが `Role`としての区別は行われます。

 ISOイメージも Server等の区別がありません。フル版の容量は 6.9GBとなっており、DVD-R/RWの single-layerでは収まらないため dual-layerが必要となります。このため DVDドライブ側でも dual-layer対応が必要となります。SUSE Linux Enterprise Server 15も容量が大きいのですが single-layer対応のままで 2枚組になっていますが、個人的には dual-layer対応の方が嬉しいです。何故なら UEFIの `Boot from URL`機能を利用して ISOからシステムを起動する場合には ISOメディアの途中入れ替えが行えないためです(iLO5の Virtual Mediaは勿論 ISOメディアの途中入れ替え可能です)。この Boot from URL機能自体が世間で殆ど使われていない機能(ProLiant Gen10でも Tech. Preview状態)だとは思いますが、便利な機能なので今回の dual-layer対応は非常に嬉しいです。地味に嬉しいのが ISOのボリュームラベルに半角スペースが含まれなくなった事でしょうかね。手で pathを記載する際に `%20`とかやらなくて済みます(ちなみに CentOSでは昔から ISOのボリューム名に半角スペースを使っていませんでした)。

 Fedora 28(kernel 4.16)をベースとして開発が行われ、kernelが Red Hat Enterprise Linux 7の 3.10から 4.18になっています。ハードウェアの観点から云うと、従来の Red Hat Enterprise Linux 7とは技術的な理論値は同じでも Red Hat社の正式サポートの限界値がいくつかあがっています。特にメモリの上限が 24TBとなっています。Red Hat Enterprise Linux 7の場合には Superdome Flexの様に特別要件を満たした場合にのみ 24TBのサポートを行っていましたが、この特別要件が外れています。

 kernelパッケージが空になっています。これは Fedoraで先行実装されていたものです。従来の kernelパッケージは kernel-core, kernel-modules, kernel-modules-extraに分離されています。kernelの config状況を見たい場合には /boot配下の .configファイルで確認できますが、もっときれいにみたい場合には #yum install kenrel-devel kernel-headers make gcc efiutils-libelf-devel ncursedeve bison flex ; cd /usr/src/kernel/`uname -r` ; make menuconfig でヘルプ付きの ncurse画面で確認可能です。

 DNF(dandified yum)は Fedora 22で実装されていた DNFの yumコンバート用 pluginでの実装ではなく /usr/bin/dnf-3への linkとなり、yum.confファイルも dnf.confへの linkとなっています。

 あと私が参加したセッションや PDFでの言及はなかったと思いますが、weak-dependencyが実装されている筈です。例えば、とある RPMパッケージの一部の機能だけを使いたい場合、従来はその RPMパッケージの依存関係の全てを満たさないといけませんでしたが、特定の機能だけを動かすための weak(弱い)依存関係の定義を満たせば、その RPMのインストールを許すみたいな使い方ができます。例えば、#lsや #cp等の基本機能だけを使いたい場合には busyboxとしてコマンドの塊みたいなのを実装しますが、それをせずとも weak-dependencyを利用する事で必要最低限のパッケージだけの導入で済む事になります。これが有効なのは恐らく minimumパッケージとして利用するケースが多いだろうクラウド環境でイミュータブル的なもので有効性を発揮するのだろうと思われます。

 gccが 8.2で今流行とも云える LLVMは 6.0が搭載されています(LLVM自体は Red Hat Enterprise Linux 7.3から搭載され 7.6で 6.0になっています)。

 以前からの宣言通り btrfsファイルシステムは kernelの configファイル上で完全に [N]扱いとなっています。XFSも reverse mapping(枯れているのだろうか)対応で copy-on-writeが可能になったとは云え、Grub2や #zypperへのプラグイン対応等で btrfsの方が使い安くやはり一日の長がある面が多いと思いますので個人的には残念です。但し、Grub2との連携は BOOMブートローダで手動での連携は可能ですので、自動でやりたいなら自分でスクリプトでも作成するしかないかと思います。ストレージの圧縮と重複排除を実現する VDO(virtual data optimizer)も搭載されています(Red Hat Enterprise Linux 7.6より)。ただ VODのチューニングは多岐にわたる項目があるので、将来 FPGAと連携して負荷をオフロードできれば使い勝手はかなりよくなると思ったのですが、それなら OSから見えないレベルで FPGAに任せてしまった方が楽な気がしないでもありません(Simplivityみたいに)が、今後はこのデータ圧縮と重複排除の注目度が更に高まってくると思われますので、ファイルシステムに特化しない方式も自由度があっていいかと思いますが、XFS側で実装する動きもありますので悩ましいところですね。あと Tech. Previewとして STRATISの説明が少しだけありました。私は知らなかったのですが thin-provisioning、snapshotが可能となる poolベースのストレージ管理機能だそうです。VDOもそうですが XFS側の将来の実装とかぶりそうな気がします。

 #dockerコマンドが #podman等に変わっていますが、これは Red Hat Enterprise Linux 7.6で一足先に正式サポートされています。

 Red Hat Enterprise Linux 7では Chronyと ntpが搭載されていましたが、8.0では Chronyのみとなっていますので注意が必要です。

 多分誰も使ってなかったと思いますが、Red Hat Enterprise Linux 7で実装と正式サポートが開始された OpenLMIは廃止されています。ベアメタル、KVM、クラウド等の違いを抽象化して操作できる様にするものでしたが、Ubuntu, SUSEがのってこなかったので仕方ないと云うか予想の範囲だったと思います。

 あと KDEも廃止されました。Gnome3は GDMでログインする際に Classicモードも簡単に選択可能だとは云え KDEがなくなるのは非常に残念です。Linusも Gnomeはクソだ!みたいな発言をしていましたが、どう考えても Gnome3の Nativeモードがマウスとキーボードで使いやすいものだとは私には思えないので個人的には残念です。Red Hat Enterprise Linux 3リリース時に「これは Gnomeではなく BlueCurveだ!」とした時点で今の状況は予測できていましたので、そう考えると結構長いこと KDEのサポートしていたのだなとも思えます。Ubuntuも Gnomeに戻ってきたしで仕方ないっちゃ仕方ないのですが、昔の Red Hat Enterprise Linuxの様に #system-config-***** みたいなツールがどんどん消えて、#gnomne-control-center経由での設定しか残されていない事を考えると、Red Hat Enterprise Linuxは本当に Enterprise方面にだけ向いているのだなとも思えます。Desktop Linux遠くになりけり、です。

 もしかして、と思いましたが kPatchは Premiumサブスクリプション(24x8)が必要のままとなっています。

 HA(high availavility)等の add-onレポジトリはフル版 ISOにも入っていませんので、別途入手する必要があります。

 誰も使っていないと思いますが、UEFIの boot from URLに ISOメディアが対応しています。UEFI Shellから ISOイメージをダウンロードしそのまま ISOから起動させる便利機能なのですが、他社サーバではあまり実装されていないと思いますし、staticな IPv4での利用が標準化されていないかな感じの状態なもので、ハードウェア側だけでなく ISO側での対応も必要なものです。実は ProLiant Gen9から実装はされていますが、現時点でも正式なサポート機能ではありませんが、前述した Nested Virtualizationなみに私は便利に利用させてもらっている機能です。ProLiant Gen10は Gen9での RBSUからの設定とは異なり UEFI Shellから操作を行う形式となり、フル版の ISOから起動が可能です。試しに UEFI Shellから #webclientと #bootのヘルプをご覧になってみてください。

 Red Hat Enterprise Linux 8は systemdや dockerのサポートが開始された Red Hat Enterprise Linux 7に比べれば機能差異はそれほど大きくないと云っても過言ではありません。しかし、一番大きく変わったのはセッションの方でも言及しましたがサポート期間の変更です。簡単に云うと「同じバージョンを 10年使い続ける事が確約されない」と云うのが Red Hat Enterprise Linux 8の最大の差異とも云えます。例えば、Red Hat Enterprise Linux 7では OpenJDKと云う例外を除けば、kernelは云うまでもなく httpdは 2.4.6系のまま 10年使えますし、mariadbも 5.5系のまま 10年使え、postgresqlも 9.2系が 10年、pythonも 2.7.5系が 10年使える事になっています。何等かのバグフィックスやセキュリティアップデートが upstrem側で掛かった場合には、Red Hat社が責任をもって Red Hat Enterprise Linux 7がサポートするアプリケーションに対して backportしてくれてましたので安心して 10年間システムを使い続ける事が可能でした。ただ、もともと kernelと様々なアプリケーションはそれぞれ別々のタイムラインで開発が進められていますので、正直かなり Red Hat社が頑張ってくれていた面が大きかったと思います(さすが Enterprise Linuxですね)。Red Hat Enterprise Linux 8はこのアプリケーション毎のサポートタイムラインを固定せずに分離する仕組みとして Modularityと云う考えを導入しています。簡単に云うとアプリケーションの複数バージョンを同時にサポートする事となります。従来からあった SCL(software collection)の様にインストール先を分けて複数バージョンを(無理やりに)同時稼働させるものではないため、インストールできるバージョンは 1バージョンのみとなります。この Modularityを操作するのは #yum(dnf)で可能となっています。Red Hat Enterprise Linux 8.0の 10年サポートに含まれないパッケージとしては下記 24ヶが Retirement Dateとして宣言されています。主にアップデートが早い WEB、言語処理、DB等が対象とされています。これらは EUSや ELSの延長保証の対象にも含まれませんので注意が必要です。UNIX程じゃないけど、Linuxも長く使える様になったよね! と云うガチガチの Enterprise視点をお持ちの方には時計の針が逆戻りしている様に見えるかもしれませんが、最新版が使えるので開発者には嬉しいと思います。Red Hat Enterprise Linux 8からは「塩漬けではなく、アプリを乗り換えつつ利用する」事になっていくのだと思います。クラウドな時代となり時間の流れも速くなっているって事ですかね。

 authd 1.4.4、container-tools 1、dotnet 2.1、git 2.18、httpd 2.4、Identity Management DL1

 mariadb 10.3、maven 3.5、maercurial 4.8、mysql 8、nginx 1.14、nodejs 10、openjdk 1.8.0

 openjdk 11、perl 5.24、php 7.2、postgresql 10、postgresql 9.6、python 2.7、redis 5

 ruby 2.5、scala 2.1、swig 3、varnish 6

 Red Hat Summitで肩書が MKTGっぽい人が推していた機能として Red Hat Insightsと Satelliteがあります。Insightsは従来から提供されている機能でしたが、利用するには別途サブスクリプションが必要でしたが、Red Hat Enterprise Linux 8のリリースを機に Red Hat Enterprise Linux 7を含めて通常のサブスクリプション登録があれば使える事になりました。使い方は非常に簡単で、#redhat-access-insight  --registerだけで Red Hat側で登録を行い、後はシステムの profileが送信されます。管理者は cloud.redhat.com/insights にアクセスする事でシステムのセキュリティやパフォーマンス劣化等の状況確認が可能となります。これらに対応するために Ansible用の playbookがサイト上で提供されます。但し、全てのインシデントに playbookが提供される訳ではなくかなり古いものには提供されていないっぽい感じです。Ansible Towerを購入していなくても無償の Ansible環境だけで実行が可能ですので、管理者は対象となるノードに対して playbookを実行するだけで対策を取る事が可能となります。登録と同時に Insights用のエージェントが裏で稼働して定期的な profileの更新内容が Red Hat社に送付されますので、問題が発生する前の継続的な分析にも利用が可能となります。ただ、日本国内では海外に比べると proxy経由でのアクセスが圧倒的に多く、さらには外へのアクセスすら許されないサーバが多いのが現状ですので、この場合には Satelliteを利用する事で更に便利に運用が可能になると云う話に MKTGの方は繋げていました。この Insightsは CentOSや Oracle Linuxに対するカウンターに繋げられるかと思われますし、Ansible Towerへの拡販にも繋がっていくいい施策だと思います。ただ、Satellite自体があまり売れている様には見えないので、まずは Satelliteの購入に繋がらないと流れが旨く回らないのかもしれません。ちなみに、Satelliteの Red Hat Enterprise Linux 8への対応は v6.5からとなり、Satellite自身を Red Hat Enterprise Linux 8の上で稼働させるには v6.6で対応予定で、Red Hat Enterprise Linux 7から 8へのマイグレーションも可能になる予定との事でした。また、v6.6以降の一部の機能は Red Hat Enterprise Linux 8でのみサポートするものが出てくるとの事ですが、この詳細については私が参加したセッションでは説明されませんでした。

 コンテナ環境の変化については、#dockerコマンドが廃止され OCI(open container initiative)ベースのツールである podman, skopeo, buildahにリプレースされています。skopeo以外は Red Hat Enterprise Linux 7.6から実装と正式サポートが行われています。リプレースした理由は前述した通りセキュリティとオープン性の担保のためとの事です。podmanは dockerコマンドのリプレースで #dockerの互換コマンドとして利用が可能となります。大きな違いとして daemonの稼働がありません。buildahは docker buildのリプレースで従来の dockerイメージと OCIイメージの両方をサポートします。やはり daemonは稼働しません。skopeoは docker pushのリプレースです。daemonが稼働しない事と root権限が不要になっています。ちなみに、podman-dockerを別途インストールすると従来どおりの #dockerが叩ける様になります(実際には裏で互換コマンドが動きます)ので既存のスクリプトも大半はそのまま動くと思われます。

 コンテナ環境のもう一つの変化として、UBI(universal base image)の提供がアナウンスされました。Red Hat Enterprise Linux 7と 8がベースとなっているもので、ユーザは自由に改変をする事ができ、再配布も可能です。Red Hat Enterprise Linuxもしくは OpenShift上で稼働させる場合には Red Hatがサポートを行います。OCI上での動作も可能で、#podmanから呼び出せます。

 実際に手を動かしてみた感じでは、インストーラは基本 Red Hat Enterprise Linux 7と同じです。但し、Server/Workstation/HPC Computeのどれかを指定する Roleの指定が可能になりました。/etc/os-releaseにも特段影響がないので Red Hat Network側での profile処理として利用されるのかと思われます。本項目は必須項目ではありません。ちなみに、/etc/os-releaseの VARIANT=と VARIANT_ID=は Fedoraでは UUIDをベースにしたユーザトラッキングを行うらしいので、Red Hat Enterprise Linuxでも同様の施策が行われるのかと思われます。日本語インストールを行っても `時刻と日付`は `US/東海岸`のままなので変更が必要となっています。日本語入力がデフォルトではできませんので、別途 ibus-kkcをインストールし一旦再起動(#systemctl isolateではダメ)してから #gnome-control-center regionから [日本語 かな漢字] を追加する必要があります。これってかなり面倒ですけど、インストール時にできたら嬉しいですよね。あと ibus-kkcだけじゃなく mozcも使いたいです(SUSE Linux Enterprise Server 15は mozcがメイン)。パッケージグループの選択として Serverと Workstationの選択が可能です。HPC Computeのパッケージグループはありませんので Red Hat Enterprise Linux 8ではパッケージ制限はなくなったものと思われますので X.orgや #numactlも使って問題ないと思われます。

 試していませんが、in-placeアップグレードを利用して Red Hat Enterprise Linux 7を 8にする場合の一番大きな注意点としては、/varを別パーティションとしているシステムはダメと云う事と、XFSを Red Hat Enterprise Linux 7.3未満で作成した ftype=0な XFSからのアップグレードには別途対処が必要となります。この対処方法は日本語版の Release Notes側には記載がなく英語版にのみ記載がありました。

 使うか分かりませんが、面白い機能としては prefixdevnameがあります。この機能を利用すると Ethernetのパーティション名を好きなものに設定する事ができます。例えば eno1が hoge0になります。注意が必要なのは persistent device namingとは異なり 1-originではなく 0-originとなる事です。Grubも 1から 2になり 1-originに変更されていますけど、1-originって不便ですよね。1-originの場合には常に「0から始まっているのではないだろうか?」と云う疑念が脳裏をよぎりますが、0-originならその疑念はありませんので、私は 0-origin派です。ちなみに HPEのストレージボックスは 1-originです。Compaqも DECも 0-originでした。

 Modularityの説明をしましたが、pythonがインストールされている筈なのに pythonはデフォルトでは使えません。これはシステム用として /usr/libexec/platoform-pythonとして v3.8がインストールされています。普通に python2を使いたい場合には、#yum install python2してから #alternate -config pythonで python2を /usr/bin/pythonに設定する事で利用が可能となります。これは ansibleでは困る事がありますが、将来の Ansible Engineでは自動判断してくれるらしいです。

 あと DPDK(data plane development kit)が最初から同梱されており public cloud用とされています。具体的には Open vSwitch一択ですね。いちいちビルドしなくて済みますし、dpdkのバージョンを気にする事が減って案件サポートが捗りそうな気がします。ちなみに、#dpdk-devbind -bすると指定した NICポートが kernelからは認識されなくなりますので link down検知が難しくなりますが、iLO5の場合には MCTP over NCSI機能により link statusを i2cとかではなく PCI-E上に直接流す事ができますので、DPDKへの bindを行っていようが #halt -pしていようが link down検知は可能です。本機能はかなりマイナーな機能ですのでファームウェアとのマッチングと云うか事前テストが必要となりますので気を付ける必要があります。DPDKを使っていないなら amsdエージェントを利用して OS上の link up/down情報を iLO5に伝えるのが確実かとも思います。ここら辺は私が生業としている分野なのですが、ProLiantの電源を投入せずとも WOLさえ有効になっていれば ACを抜いてある(20秒以上) ProLiantに再度 ACを接続した状態でも iLO5が起動しさえすれば MCTP over NCSIでの link down検知は可能です(POSTでの NICの初期化は不要で且つ WOL用の電力でも通信は可能)。これは OSが起動する前に NICの不良があった場合にクラスター環境に joinさせるのを防ぐのに有効かと思われます。

 あと、XDP(express data path)ですが、当初は Tech. Previewですが、将来的には DDOS攻撃を dropする等の簡単な外部モジュールを Red Hat社がサポートしれくれると嬉しいですね(サンプル提供ならアリでしょうかね)。あと、XDPを利用するにはドライバの対応が必要ですがてっとり早いのは kernelモジュールを #stringsして xdpとか bpf/ebpfあたりで #grepすればいいかと思います。

 個人的に嬉しいのは `Server(GUI)`パッケージグループの選択で #treeが入っている事でしょうかね。Red Hat Enterprise Linux史上初じゃないですかね、ありがとうございます(軟弱ですいません)。

 やはり Gnome3で一番利用する Terminalですが、Classicモードならマウスの右クリックで端末が開けない事でしょうかね。Red Hat Enterprise Linux 7もプラグインで実装していて途中からプラグインの形式が変わったりしましたけど、Gnome3の Nativeモードでもプラグインでの対応はできないんでしょうかね(Gnome3素人ですいません)。やはり Gnome3の Nativeモードは老人にはとっつきづらいです。

 Red Hat Enterprise Linux 8で一番目につきやすい変更点は Cockpit(Web Console)の実装です。Fedora 22で実装されたのが 4年前ですが、当時は Webminライクだけど使いづらいなぁと思ってましたが、かなり洗練されています。当時にはあった cockpit-containerがなくなっているのは dockerが podman等に変更された影響でしょうかね。KVMの実行は Cockpitから可能です。あと Topページにある `メトリクスの保存`は cockpit-pcp(performance co-pilot)ではリストされますが、Cockpit画面の `アプリケーション`にはリストされません。今後の改良に期待ですが、Cockpit内での端末は 1ヶしか開けません。では #screenをば! と思っても、実は Red Hat Enterprise Linux 8には #screenが搭載されていません。これは結構不便な感じがします。今後 Cockpitの端末に対応した #screenがリリースされるとかあるんでしょうかね? あとこの端末上ではマウスでの文字列の copyはできますが pasteはできません。pasteをするには WEBブラウザ側の paste機能を利用する必要がありますので、ちょっと戸惑いますね。セッション内のデモでよく行われていた tlog(terminal log)を利用した session recordingです。これはログインしたユーザのコマンド履歴を全て記録し再現するものです。同じ事を tlogなしでやろうとするとちょっとした仕掛けを自分で用意せねばならなかった事を考えればかなり便利です。tlog自体は rootのセッションも記録できそうな感じですが、実際には一般ユーザした記録できないみたいです。設定が簡単なので地味に便利だと思います。Red Hat Enterprise Linux 8の新機能として推していた Image Builderは Cockpitから利用可能です。Red Hat Enterprise Linux 7.6で Tech. Previewとして実装されていたもので qcow2/img, ext4/img, raw/iso,tarに加えて ami, vhd, vmdkにも対応しています。但し、Tech. Previewです。あと、Image Builderの元となるパッケージである loraxパッケージはシステムイメージを作成している際に潜在的に安全が確保されていないので、仮想マシン上で利用する必要があるとの但し書きがありました。

 

  ここからは ProLiantに特化した話をしたいと思います...

 

 Red Hat Enterprise Linux 8向けの SPP(service pack for ProLiant)は、6月初旬に Supplemental Bundleとして amsd/hp-ams, IMA/SMHの管理エージェント、smartpqi, hpsa, hpdsaのストレージドライバと Fibre向けドライバとツールがリリースされました。その後 9月半ばに 2019.09.0としてフル機能版がリリースされています。ProLiantをはじめとしたサーバマシンにはショッボイ Videoコントローラが搭載されています。

 Red Hat Enterprise Linux 8は従来の X.orgからとうとう Waylandに変更されており、従来よりも少しもっさりした動きに思えますが、Ubuntu 17.10の時の様に重くて X.orgが死んだ?と迄にはなりません。そもそも Ubuntu 17.10を Gen8上で Waylanを使うと Terminal上で key入力がチャタリングしっぱなしだった(Gen9, Gen10はそこまでではないがそれでも Firefox上ではチャタリングが発生する)事を思えば、Red Hat Enterprise Linux 8は従来と同じ感覚で利用が可能です。何故なら ProLiantはしょっぼい Matrox G200 eH3とかを積んでいるので、gnome-session-workerで Waylandが選択できなくなっているので強制的に X.orgを利用する事となるからです。ちなみに、Walandを最初にデフォルトにしてきた Ubutu 17.10では X.orgに戻した後に更に gnome-session-worker側も戻さないとログイン画面が止まっているかの様でしたので、Red Hat Enterprise Linux 8の closed betaを初めて触るまでは戦々恐々でしたが X.orgで、ありがとうございますと云いたいです。

 XDPに対応した NICのドライバですが、最近の kernel moduleは #xz圧縮されていますので、#xzcat ./lib/modules/`uname -r`/kernel/drivers/net/ethernet/intel/i40e/i40e.ko.xz | strings | grep -ie bpf -ie xdp とかで引っかかるかのでとりあえず実装状況は分かるかと思います。ざっと ProLiant対応 NICを確認したところ正式サポートかは置いておくとして、ixgbe, i40e, qede, mlx4_en, mlx5_coreには実装されている事が確認できました。bnx2x系は現時点では対応していません。今後の予定がどうなのかは不明ですが、XDPの利用を考慮するシステムでは別のコントローラを選択する必要があります。

 誰も気にしてないと思いますが、Red Hat Enterprise Linux 8は EDAC(error detection and correction)に対応しています。いち早く Ubuntu側と云うか upstream kernel側で実装を行っていましたが、EDACの利用は長年どこのベンダーも利用してきませんでした。BIOS側に問題が存在するシステムが少なくない事、そして EDACを利用するメリットがあまりなかった事があります。ProLiant上で Red Hat Enterprise Linux 8を稼働させた場合、システムが Gen10以降である事を確認すると EDACモジュールをロードします。ProLiantでも Gen9以下の場合には従来の GHES(generic hardware error source)を利用します。従来の Red Hat Summitでは RAS機能のセッションが必ずあったのですが、4年ぶりの参加では全くその手のタイトルがありませんでしたので誰も気にしていないのかもしれません。しかし、NVDIMMをはじめとした従来の hw-poison(メモリエラーが発生した場合にその領域を OSに通知し OSが対象となるアプリを殺す仕組み)環境とはくらべものにならない DIMMの代わりとなる Flash/Optaneのエラー比率を考えるとどこかで EDACに切り替える必要があると考え、HPE逸早く EDACの対応に取り組んでおります。但し、kernel側で hw-poisonを連携するのかについてのドキュメントがない事、そもそも Tech. Previewなのかすら明記されていない筈ですので、もうすこし機を待つ必要があるかと思います。ちなみに、edac_ghesは kernel built-inなので #lsmodでは見えませんので、前述の #make menuconfigで確認してください。

 UEFIの Boot from URL機能ですが、ハードウェア側と ISO側の両対応が必要となります。ProLiant Gen9, Gen10共に実装の度合は違えど Tech. Previewとして搭載されています。Gen10ではフル ISOからの起動も可能です。Red Hat Enterprise Linuxは 8.0では起動可能で Red Hat Enterprise Linux 7は少なくとも 7.6では起動を確認しています。ちなみに、Boot from URL対応の ISOを一旦 #cp -aしたものを #mkisofs -U -V "RHEL-7.6 Server.x86_64" -J -joliet-long -r -T -l -o ../rhel76lcc$(date +%s).iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot -e images/efiboot.img -no-emul-boot . しても再度起動します。Boot from URL自体が結構新らしめの機能で HPEが static IP v4での起動の標準化を推し進めている話でもありますので、あまり社外には資料が出ていないものですが、今後 OSベンダーもここら辺への対応情報の整備を期待したいところです。ちなみに、SPP(service pack for ProLiant)の 2019.06.0は Boot from URLには対応していません。これは offlineモードで起動した際に iLO5自体のファームウェアが flashされた際の特殊な処理に対応できないためではないかと個人的には思っています。iLO5の仮想メディア経由の場合に SPPを offlineブートした場合には iLO5の仮想メディアを利用していても iLO5のファームウェアアップデートができる仕組みを備えています。

雑感

 

 今回の目玉は Red Hat Enterprise Linux 8と OpenShift 4ですが、後者は若干リリースが遅れ気味な感じで今一つはっきりしない部分が多かった感じがします。買収した CoreOSの Kubernetes部分はがっちりと OpenShift 4の下に入り込みますが、CoreOSを baremetalで利用する場合に HCT(hardware compatibility list)は Red Hat Enterprise Linux 8と同等と考えていいのか等が公表されませんでした(後日、RHEL8の HCLに準ずるというknowledgeが公開されました)。実は当方にくる問い合わせでも CoreOSに関する問い合わせは少ないものの、案件規模が大きいので無視できないために手弁当で無理やり SmartArray設定用ツール(SSA: Smart Storage Administrator)を動かすとかいろいろアクロバティックな事をやっていたのですが、Red Hat Enterprise Linux 8ベースであるならば、動作自体が保証されている事だけでも案件提案での工数が大幅に減るので助かります(Red Hat Glusterも当初は DUD読み込めないとかで無理やり DUDを読ませる方法を考えたりしましたので、実際には確認必要だと思いますけど)。Red Hat社は Red Hat Enterprise Linux 8がクラウド上のどこででも稼働させる事ができる OSである!として居ますけど、この領域に於いては CoreOSは無視できないですよね。

 来年の Red Hat Summitはまた西海岸の San Franciscoに戻り、4月 27 ~ 4月 29日の開催となります。

 今回カナダのトロント経由で米国に入国しました。米国に入国するには ESTA(電子渡航証)が必要なのは今時あたりまえですが、日本出国の数日前にカナダはトランジットを行うだけでも eTA(電子渡航証)が必要な事に気づきました。カナダ経由で行かれる方はお気をつけください。どうでもいいですが、カナダエアの機内モニタの「ようこそ」は凄い崩し文字でした。

 会場がウォーターフロント側に戻ったので、ホテルが会場から離れたところに確保されている人の割合が多かったと思われ、疲れた顔をしている人の割合が多かった気がします。米国への入国は深夜で出国も早朝と今までで一番の強行軍を強いられましたが、やはり Red Hat Summitには参加した甲斐はありました。

雑感1

雑感2

雑感3

 ちなみに、Fedora 17のデフォルトのファイルシステムは btrfsになる方向で一度流れが固まっていた事があったとの話がありますけど、Fedora 16でも断念してましたけど、これが実現していたら Linuxは今と違っていたのでしょうかね。

では、では

Open Source & Linux

2015年11月1日付でHewlett-Packard CompanyをHewlett Packard Enterprise Company とHP Inc.に分社する以前に販売された製品については、現在のモデルと異なる、古い製品名およびモデル番号である場合があります。