いぶろぐのガジェット日記

いぶろぐのガジェット日記

ガジェットやOSS、その他興味のあるITニュースをぽつらぽつら投稿します。

CloudLinuxのCentOS代替ディストリの名称が「AlmaLinux」に決まりました

f:id:ibulog_iblog:20210113233915p:plain

「Project Lenix」のコードネームでちょっと前に報じられたCloudLinuxのRHEL代替ディストリですが、名称が「AlmaLinux」に決まったみたいです。

同じくCentOS代替を目指すRocky Linuxと競争ですね。

almalinux.org

CentOSをめぐる騒動

2020年12月、CentOSプロジェクトは突如「CentOS 8のサポート期限繰り上げ」と「CentOS Streamへの軸足移行」を発表しました。

ibulog-iblog.hateblo.jp

qiita.com

この発表はインフラ関係者に大きな衝撃を与え、当時はかなり騒動になっていました。

赤帽ブログには「素人目には、CentOS Streamはすでに RHEL と同じくらい安定しています」と書いてましたが、やはりRHELのアップストリームということには変わりないわけで、RHELのダウンストリームとしてのCentOSは死んでしまいました。

rheb.hatenablog.com


新たなRHELダウンストリーム

CentOS」の消滅に対しコミュニティは大きく反発したため、CentOSプロジェクト創始者のGregory Kurtzer氏は新しいRHELダウンストリームを発足させました。

それが「Rocky Linux」です。

rockylinux.org

開発進捗はいまのところほぼなく、GitHubのREADMEにも「There is not currently an ETA for release.」と書いてある状態です。

で、Rocky Linuxとほぼ時を同じくして発表されたのが、CloudLinuxによる「Project Lenix」でした。

www.projectlenix.org

こちらもRHELダウンストリームを目指すプロジェクトで、巨塔CloudLinuxによる盤石なアシストあり。ここはRocky Linuxとの大きな違いですね。

AlmaLinuxは、このProject LenixによるLinuxディストリビューションの名称となります。

Hello, AlmaLinux!

  • RHELとの1:1の互換性

  • Fedoraライクなディストリビューション

  • CentOSからコマンド一発でダウンタイムなしで移行可能(詳細不明)

  • 完全無料

  • CloudLinuxによる支援(2029年まで、ここ意外と大事かも)

と、特徴はこんな感じ。

気になるのは「CentOSからコマンド一発でダウンタイムなしで移行可能」というところ。ちょっとどういう仕組みになるのか謎。

あとは「Fedoraライクなディストリビューション」という点。これはRedHat系のLinuxという文脈なのか、それともRHELアップストリームという文脈なのか・・・?

よくよく読むとAlmaLinuxのウェブサイトには一言も「RHELダウンストリーム」とは書いてないんですよね。

RHELのフォーク」とは書いてあるんですが、はてさて。


のんびり待とう

AlmaLinuxは2021年第1四半期にリリース予定とのことなので、のんびり待ちましょう。

まあ当分は本意気で利用することはないと思いますが。

次世代のCentOSはRocky LinuxかAlmaLinuxか。今のところはAlmaLinuxが一歩リードという感じでしょうか。


P.S.

ユニクロのクルーネックシャツにワッペンを貼り付けるのにハマっています。

kindをZFS上で利用する場合はおまじないが必要なんです

f:id:ibulog_iblog:20201225005058p:plain

ローカルにKubernetesクラスタをお手軽に構築できるのが「kind」さんです。「Kubernetes in Docker」でkind。

仕組みとしてはDockerコンテナをNodeとし、その中にPodを構築しているみたい。Dockerとkubectlがあれば動きます。

ひょんなことで利用する機会があったのですが、どーもうちの環境ではControl Planeの起動に失敗するようで…

調べてみるとおまじないが必要だったので、備忘録。


rootディスクがZFSだとなんかダメみたい

とりあえずエラーメッセージでググる

OSはUbuntu 20.04。VirtualBoxクリーンインストールしたUbuntuではControl Planeの起動に成功するのに、ベアメタルで実行した場合はなぜか失敗する…

エラーメッセージで検索すると、同じエラーに悩まされている人を発見。

github.com

ここには解決策はありませんでしたが、ヒントを掴むことはできました。

using a filesystem that doesn't work out of the box with docker in docker #1416 (comment)

Dockerコンテナの中でDockerコンテナを動かせないファイルシステムが存在する…?


ZFSとbtrfsはちょっと前までkindで問題が生じていた模様

github.com

ZFS/btrfs上でDocker in Dockerすると、overlayfsに問題が生じるらしい。

ただ、「問題は解決した」とあるので、もう少し調べてみました。


ZFSでもkindを使える解決策を発見

github.com

上記のissueに解決策がありました。

具体的には、kind実行時に指定するconfigファイルを以下のように書けばOK。

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
containerdConfigPatches:
- |-
 [plugins."io.containerd.grpc.v1.cri".containerd]
 snapshotter = "native"

キモは「 snapshotter = "native"」で、ZFSを使ってsnapshotを取るようにしている点。これを指定しないとsnapshotを取得するストレージドライバーにoverlayfsが使われてしまい問題が発生する模様。

microk8sでも同じ問題が起こっていて、こちらが先に修正されていたようです。

github.com

てか、microk8sは自動でZFSを識別して挙動を変えるようになっているので、kindもそうすればよいのでは…


無事動いた

「kind create cluster --config config.yaml」で先ほどのオプションを読み込ませると、無事Control Planeが起動してClusterを構築できました。

めでたしめでたし。


P.S.

最近知ったLinuxのランチャー「Ulauncher」、かなりよい。

ulauncher.io

「CentOS」が終焉、今後は「CentOS Stream」に移行するみたい

寝る前に(個人的には)どデカいニュースがとびこんできました。

blog.centos.org

CentOS死ぬんかワレ…


RHEL/Fedora/CentOS/CentOS Stream の関係性

これについては以下のブログが詳しいです。

rheb.hatenablog.com

簡単にまとめると、以下のような感じ。

  • RHELRedHat謹製のド安定商用Linux
  • FedoraRHELの超ベータ的存在、開発者向け
  • CentOSRHELベースの安定志向非商用Linux、一昔前はサーバーといえばこれだった
  • CentOS Stream:CentOS 8とともにリリースされた新OS、位置づけとしてはRHELのプレビュー的存在か?


今回起こったこと

CentOS公式によると「CentOS 8は2021年で終了&CentOSプロジェクトはCentOS Streamへと移行します」とのこと。

CentOSプロジェクト全体として見れば、RHELのダウンストリームからアップストリームへ移行します、ということだと思われます。

CentOS 7は引き続きRHEL 7が終了するまではサポートするそうですが、古のインフラを管理している人にとっては注目のニュースですなあ。

いやほんと、Ubuntuに乗り換える時期かも。

FAQは以下にあるので、気になる人はぜひ。

centos.org

P.S.

CentOSプロジェクト創設者のGregory Kurtzerが、今回のエントリーのコメント欄で以下のように発言しているようです。

I am considering creating another rebuild of RHEL and may even be able to hire some people for this effort. If you are interested in helping, please join the HPCng slack (link on the website hpcng.org).

...新しいRHELベースのディストリができる?のか?

何はともあれ、今後の動向に注意ですね。

最近はFedoraが本家RHELとは逆方向のbtrfsを採用したりと、RedHat系のディストリに大きな変化が起こりそう。

CrowdSec - オンラインからブロックリストをフェッチできるFail2Banの代替OSS

crowdsec.net

LinuxでDDoSなんかをログからいい感じにブロックするソフトウェアといったらFail2Ban。

IPをアクセス回数と間隔で監視してアウトな子はiptablesでブロックというシンプルかつ強力なソフトです。

そんなF2Bを代替するOSS「CrowdSec」は、F2B的な機能に加えて、CrowdSecコミュニティが提供するブロックリストも利用できるみたいです。


インストール方法

・テスト環境:Ubuntu 20.04 LTS

下記のコマンド群を実行すればOK。

sudo apt install bash gettext whiptail curl wget
curl -s https://api.github.com/repos/crowdsecurity/crowdsec/releases/latest | grep browser_download_url| cut -d '"' -f 4  | wget -i -
tar xvzf crowdsec-release.tgz
cd crowdsec-v*
sudo ./wizard.sh -i

なにやらサービスを選択する画面が出てくる。デフォのLinuxログやらsshdやらnginxやら、インストールされているサービスを勝手に認識してここにリストアップしてくれるので、ログを監視したいサービスを選択する。

f:id:ibulog_iblog:20201129235717p:plain

apacheとかmysqlとかvsftpdとかも対応している。なかなか優秀。

f:id:ibulog_iblog:20201129235721p:plain

インストールを進めていると「CrowdSec単体ではIPをブロックできひんで、ブロッカーがいるで」という忠告が。

f:id:ibulog_iblog:20201129235726p:plain

ブロッカーは以下のページで公開。通常のNetfilterのほか、Cloudflareやnginx、WordPressと連携してブロックできるみたい。

hub.crowdsec.net

「cs-netfilter-blocker」でNetfilterを使ったブロックができる。インストールは以下コマンド。

wget https://github.com/crowdsecurity/cs-netfilter-blocker/releases/download/v0.1.0/cs-netfilter-blocker.tgz
tar xzvf cs-netfilter-blocker.tgz
cd cs-netfilter-blocker-v0.1.0
sudo ./install.sh
sudo systemctl status netfilter-blocker

これでCrowdSec経由でNetfilterを利用できるようになったみたい。


使い方

cscliというコマンドが用意されており、cscli listで有効化されている設定を確認可能。

f:id:ibulog_iblog:20201129230052p:plain

sudo ipset listすると、勝手にブロック対象のIPがリストに追加されているのがわかる。これはCrowdSec Hubというコミュニティからオンラインで取ってきたものみたい。逆にこちらのブロック情報もコミュニティに送信される。

f:id:ibulog_iblog:20201129230059p:plain

iptablesのINPUTチェインにも勝手にルールが追加されている。うーん楽ちん。

f:id:ibulog_iblog:20201129230105p:plain

基本的な使い方は以下。

cscli ban add/del IPアドレス:IPをブロック/ブロック解除

cscli ban flush:ブロック設定をDBに書き込み

cscli install collection:監視対象のサービスを新規設定

cscli update:CrowdSec Hub(これがCrowdSecのコミュニティ)から最新のブロック情報を取ってくる

なんとCrowdSecは6060ポートからPrometheusのメトリクスを出力してくれる。つよい。cscli metricsでメトリクス情報をまとめて表示してくれる。

f:id:ibulog_iblog:20201130000223p:plain

Dockerをインストールした状態でcscli dashboard setupすると、CrowdSecのダッシュボードを設定できる。

f:id:ibulog_iblog:20201130003142p:plain

テストで使っただけなのでブロック情報がたまらなかったため、公式から画像を拝借。こんな感じでmetabaseを使ってブロック情報を可視化してくれる。

f:id:ibulog_iblog:20201130003324p:plain

ブロックしているIP一覧なんかもダッシュボードで確認できる。こいつぁすげえや。

f:id:ibulog_iblog:20201130003510p:plain


感想

個人で使うなら全然F2Bから乗り換えですね。仕事で使う場合はブロック情報をコミュニティに送信するというのがネックか。

まあこういうのが必要なオンプレ環境を持っている人がどれくらいいるかという話なんですが…

P.S.

エントリ書いてる最中にグロージャンが大クラッシュしてビビりました。

LinuxのブラウザでYouTube 4K60fpsをヌルヌルで再生したい人生だった

f:id:ibulog_iblog:20201124235326p:plain

「みんなやってそうだけど意外と情報がなかった」シリーズ、始まりました。

記念すべき第一回は「YouTubeの4K60fpsムービーをLinux&ブラウザで視聴する」です。

意外と情報がなかったので、戦いの模様を書いておきます。


そろそろグラボ買い替えよか

Radeon RX480 限界に到達

YouTubeの4K60fpsは「VP9」コーデックなんですが、こいつのデコードに我が家のおじさんグラボ(Radeon RX480)は対応していないとのこと。

腐っても3年前のミドルハイなんですから、VP9くらいサクッと読み解いていただきたいものなんですが・・・

ちなみに同世代のGeforceはVP9デコードに対応しており、RadeonがVP9デコードにきちんと対応したのはRX5000シリーズから。

AMDさん、あんまり動画やる気ないんですかね(Fluid Motion廃止とか)。

日本橋になんか怪しいやつが売ってた

「最近シロッコファンのGTX1660Tiがパソコン工房に蔓延している」という情報を聞きつけ、日本橋に赴くとこんなものを拾うことができました。 f:id:ibulog_iblog:20201124234344j:plain

完全にノーブランドの謎グラボ。例のグラボとは違って映像出力はきちんとついています。 f:id:ibulog_iblog:20201124234445j:plain

私が使っているJonsbo RM2はけっこう小さいケースなんで、外排気のシロッコファンはありがたい。何回かベンチ回しましたが、とりあえず無事動いてるみたいです。 f:id:ibulog_iblog:20201124234355j:plain

こんな感じでめちゃくちゃ溢れてました。15000円台で10日保証は買いですね。


LinuxでVP9は一筋縄ではいかないみたい

我が家のCPUはおじいさんHaswell(Core i5 4570)なので、4K60fpsのVP9をCPUだけで再生するのは無理。

というわけでグラボに再生支援していただきたいのですが、これがどうも一筋縄ではいかないようで。

LinuxNvidiaとVP9を取り巻く現状

以下、適当まとめ。

・Geforce GTX1660TiはVP9デコードに対応している

NvidiaLinux向けプロプライエタリドライバもVDPAUによるVP9デコードに対応している

LinuxではChromiumのbeta/dev版とFirefoxでVAAPIによる再生支援を利用できる

・VAAPIのバックエンドにVDPAUを使える「vdpau-va-driver」というものが存在する

ここまで聞くとブラウザでもVP9を再生支援できそうなのですが、vdpau-va-driverがVP9に非対応。

あぁ〜夢敗れる・・・と思いきや、捨てる神あれば拾う神ありとはよく言ったもの。

vdpau-va-driver-vp9

なんと有志によってvdpau-va-driverにVP9デコード対応パッチを当てた「vdpau-va-driver-vp9」というものが公開されていました。

github.com

これを使うとVAAPIのバックエンドにVDPAUを使ってVP9を再生支援できる!!

というわけでセットアップやっていきましょう。


vdpau-va-driver-vp9セットアップ

まずは依存パッケージをインストール。ビルド時のエラーを見つつ調整していったので、もしかしたら無駄なパッケージがあるかもしれません。

sudo apt install \
git \
build-essential \
automake \
autoconf \
libtool \
pkg-config \
meson \
libx11-dev \
xtrans-dev \
x11proto-dri2-dev \
x11proto-dev \
libxext-dev \
x11proto-xext-dev \
libx11-xcb-dev  \
doxygen \
dot2tex  \
libva-dev

続いてVP9パッチ済みのVDPAUライブラリ(libvdpau)をビルド&インストール。

git clone https://gitlab.freedesktop.org/vdpau/libvdpau.git
cd libvdpau
meson --prefix=/usr build
ninja -C build
sudo ninja -C build install

今回のチャレンジの核となるvdpau-va-driver-vp9 をビルド&インストールします。インストールしたあとは念のため再起動。

git clone https://github.com/xtknight/vdpau-va-driver-vp9.git
cd vdpau-va-driver-vp9
./autogen.sh --prefix=/usr
make
sudo make install

Firefoxを使いたい場合はそのままでOK、Chromiumを使いたい場合はbeta/dev版をインストール。

sudo add-apt-repository ppa:saiarcot895/chromium-dev
sudo apt update
sudo apt install chromium-browser

Chromiumの場合はchrome://flagsで「Hardware-accelerated video decode」を有効に。

これで万事OKのはず!だったんですが・・・


結果

無念の敗北

嬉々としてYouTubeの4K60fps動画を再生してみると・・・カクカクなんですが。

vainfoを見るとnvidia_drv_video.soを読み込んでいるし、VAProfileVP9Profile0も認識している。 f:id:ibulog_iblog:20201124234918p:plain

でもFirefoxGPUのメモリを全然使ってない。 f:id:ibulog_iblog:20201124234948p:plain

何よりCPUが張り付いてしまっている。 f:id:ibulog_iblog:20201124235005p:plain

SMPlayerでハードウェアデコードに「VAAPI」を設定すると、きちんとSMPlayerバックエンドのmpvGPUのメモリを使う。動画自体もヌルヌルで再生できる。ハードウェアデコードに「VDPAU」を設定した場合も同じ。 f:id:ibulog_iblog:20201124235151p:plain

たぶん原因は「LinuxのブラウザでVAAPIの再生支援が使えなくなっている」

状況から見て、おそらくブラウザでVAAPIの再生支援が効かなくなってしまっていますね。なぜか。

これが直ればたぶん「LinuxでブラウザからYouTubeの4K60fpsをグラボの支援を使ってヌルヌルで再生する」という夢を叶えることができると思うのですが、今回は力及ばずここまで・・・

SMPlayerを使えば「LinuxYouTubeの4K60fpsをグラボの支援を使ってヌルヌルで再生する」ことは可能なので、しらばくこれで我慢します。

ブラウザのVAAPI再生支援はバグで死んでいるのか、こちらの不手際なのか、ちょっとわからないので追加で調査していきます。

YouTuber・瀬戸弘司の4K60fps実況をコメントと一緒に再生できる日は来るのか・・・


P.S.

RX480のリファレンス(左)と今回のGTX1660Ti(右)のサイズ比較。基板だけならGTX1660Tiのほうが短いのにケース含めるとRX480のほうが短くなるという。 f:id:ibulog_iblog:20201124234719j:plain

というわけでRX480さん、3年間お疲れ様でした。 f:id:ibulog_iblog:20201124234804j:plain

AWS ソリューションアーキテクトアソシエイト(AWS SAA)を一週間で取得した

f:id:ibulog_iblog:20201114214508p:plain

AWS SAA取得RTA、はっじまっるよー!

AWSを実際に触ることはあまりないのですが、AWS SAAを取得しました。

仕事柄、知識としてAWSを頭に入れておくのはいいことだと思いましたので。

今回は資格取得を目的としているため、ハンズオンなどを行わない最短ルートを突っ走り。


初期スペック


使ったもの

黒本

LPIC受験時にお世話になった黒本。

www.amazon.co.jp

これだけで受かることはまずありませんが、AWSにどんなサービスがあるのかを素早くざっくり把握するにはいい本です。

Udemy

これ。実戦形式の問題が6セット入っています。

www.udemy.com

難易度としては本番より少し難しいといったところ。 この問題セットを解きつつわからなかった問題を復習するというかたちで学習を進めていきます。


スケジュール

AWS SAAに一週間で合格するスケジュールをば。

日曜日

日曜日はさっと黒本に目を通します。

ElastiCache、DynamoDB、SQSなどなど、サービスの概要を把握していきます。

月曜日〜土曜日朝

Udemyの問題集を一日1セットこなします。

問題を解く→復習という流れ。

問題を解くのに1時間、復習に1時間半ほどかけていました。

問題集の消化フェーズでサービスとサービスの鉄板構成やオンプレ構成をAWSで再構築する場合のサービスの組み合わせなどを頭に入れていきます。

土曜日午後

テストセンターでいざ受験。身分証は2種類(ex 免許証&保険証)必要なのでお忘れなく。

試験時間は140分で、自分はめいっぱいまで使い切りました。

アンケートに答えた後、「合格」という文字が見えればクリアです。

日曜日

あそびましょう。


完走した感想

思ったよりも本番試験が難しくて焦りました。

Udemyの模擬試験が細かいサービス(ex AWS Lex)までカバーしているのに対し、本番試験はRDSやS3などの基本的なサービスの理解が深く問われたという印象です。

単語の暗記では合格できませんね…

ちなみにスコアはこんな感じでした。 f:id:ibulog_iblog:20201114214513p:plain

AWSなんもわからんけどとりあえずどんなもんか知りたい」なら、AWS クラウドラクティショナーを先に取得するのがおすすめ。

自分は金が惜しいので飛び級でSAAを取得しました。

なにはともあれ、ハンズオンを伴っていないので現場でAWSをゴリゴリ触っていく場合は非推奨な取得ルートです。


P.S.

金欠にもかかわらず、iPhone 12 miniを買ってしまった…

このサイズ感、本当にちょうどよくて優勝です。 f:id:ibulog_iblog:20201114215547j:plain

ユーノスロードスターにアジアンタイヤ「NANKANG NS-2」を履かせました

レッドブルホンダ、調子悪いですね…PUトラブル2連発は、よろしくない。

ロードスターが履いていたタイヤがカチコチ石頭の坊主頭だったので、これを機にアジアンタイヤを履かせてみました。


もうタイヤは限界でした

中古でロードスターを購入した当初から履かされていたのが「DUNLOP DIREZZA DZ102 205/50R15」。

車を購入した2年前はそこそこ残っていた山も、今となっては(ほぼ)つるつる坊主。 f:id:ibulog_iblog:20200923015328j:plain

ひび割れもひどく、かなりゴムの硬化が進んでいます。


アジアンタイヤ、使ってみよう

NANKANG Sportnex NS-2 205/50R15

というわけで新しいタイヤを選定。金欠だったのでネットで評判のいいアジアンタイヤ「NANKANG NS-2」を楽天市場オートスポーツで購入しました。 f:id:ibulog_iblog:20200923015343j:plain

トレッドパターンはスポーティ。ゴムも弾力あります。 f:id:ibulog_iblog:20200923015403j:plain

走ってみた感想

グリップ

とりあえず乾いた路面ではグリップは申し分ない。

ただ、バンクがかかった道路に進入すると、トレッドの剛性が足りないので「クニャ」という感覚が伝わってきます。 

雨の日はまだ走れていないので、またいずれ。

ノイズ

ロードスター自体がノイズの塊なのであまり気になりませんが、よく耳をすませると「ザー」という音が聞こえます。

静粛性の高い車だとおそらく気になると思います。

柔らかさ

前回のタイヤが完全に硬化していたので、感触はかなりソフトになりました。

そのせいかリアがばたつくようになったので、ダンパーの減衰力を調整する必要がありそう。


まとめ

1本6000円台で送料無料のタイヤとしてはコスパがよすぎますね。

タイヤの真価は限界時の制動性にも左右されますが、そのへんはテストできてないので判断できません。

そこそこ長持ちするようなら、リピ確定です。


P.S.

タイヤ交換時にまさかの事態が発覚。

なんと、ホイールナットの何本かに、テーパー型ではなくホンダ純正の球面型が使われていました…

中古で車両を買ってからタイヤを取り外したことがなかったので、丸2年ほど気づかず走行していたということになります。恐ろしすぎる。

すぐさまテーパーのホイールナットに交換しました…

あやうくオーストリアGPのキミになるところでした。