2021/01/12 現在
基本的にはここ見ればOKです
ポイント
- Railsはセマンティックバージョニング
- バグ修正は最新バージョンのみ (2021/01/12 現在、
6.1.Z) - セキュリティFIXは、メジャーシリーズ全てと、1つ前のメジャーの一番最後のマイナーリリースに適用
- 2021/01/12 現在、
6.1.Z、6.0.Z、5.2.Z
- 2021/01/12 現在、
Linuxの時計まわりのおぼえがき
対象OS
設定ファイル周りについては、Amazon Linux AMI や CentOS6系以前のお話
ただし、クロックそのもの話は各Linuxでもだいたいおんなじなはず
クロック周りのはなし
時計。Linuxは2種類のクロックをもつ
- ハードウェアクロック
- システムクロック
ハードウェアクロック
RTC(リアルタイムクロック)とも呼ばれる。マザーボードが持つ物理的な時計
ボタン電池で電力供給され、電源OFF時にも時刻が維持され続ける
システムクロック
OSのソフトウェアで管理するクロック
OS起動時に、ハードウェアクロックの値を元に設定される
1970年01月01日00時00分00秒 からの経過秒数(UNIX時間) の形式で管理されている
インターバルタイマー
マザーボードの機能の1つ。定期的に割り込みをかけて、システムクロックの時刻を進める
タイムゾーン周りの話
用語
- UTC: 世界標準時
- タイムゾーン: 地球上で同一の標準時を採用している地域の集合。UTC±時差 で表記される。日本標準時ならば UTC+9
- ローカルタイム: タイムゾーンで示される現地時刻
Linuxでのタイムゾーンの設定方法
/usr/share/zoneinfo に各タイムゾーンの設定ファイルが格納されている
- 東京ならば、
/usr/share/zoneinfo/Asia/Tokyo
/etc/localtime に上記のタイムゾーンの設定ファイルと同様のものをおけば、それがシステムのタイムゾーンとなる
ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
date コマンドなどの時刻を表示するコマンドは、/etc/localtime の設定を見て、システムクロックからローカルタイムを計算する
ハードウェアクロックのタイムゾーン
ハードウェアクロック自体はタイムゾーンを持たないが、ハードウェアクロックの値の解釈を設定することが可能
/etc/sysconfig/clock で設定可能
ZONE="Asia/Tokyo" UTC=true
- UTC: ハードウェアクロックの値の解釈
true: UTCとして解釈するtrue: ローカルタイムとして解釈する
- ZONE:
/etc/localtimeの参照元を設定
マシンを再起動したり、glibcのupdateなどで /etc/localtime の参照元は、ZONEで指定した値に置きかわる
参考
Amazon Linux AMI でのタイムゾーンの変更方法
Amazon Linux AMI でのタイムゾーンの変更方法
先に結論
/etc/localtime だけを変更しても、マシンの再起動やglibcの更新でタイムゾーンがUTCに戻る
そうならないために、 /etc/sysconfig/clock の設定も必要
手順
公式ドキュメントを参照
/etc/sysconfig/clock
タイムゾーンを "Asia/Tokyo" に変える場合
ZONE="Asia/Tokyo" UTC=true
/etc/localtime
sudo ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
その後、各アプリのタイムゾーンの認識を更新するために、マシンの再起動を行う
reboot now
Red Hat系Linuxディストリビューションの歴史とCentOS Streamについて調べた
2020年LCLアドベントカレンダーの10日目です!
経緯
2020/12/08 に CentOS から「今後は CentOS Stream に開発リソースを集中し、CentOS 8 のEOLを2021年末とする」という発表がありました
twitterなどではいろいろな意見が出ていたのですが、私がそもそも RedHat系Linuxディストリビューションがこれまでどのように開発されていたのかキチンと把握していなかったので CentOS Stream と一緒に調べてみることにしました
そもそものはじまり Red Hat Linux
Red Hat Linux は 1995年にRed Hat社から配布されました。当時は企業がサポートするLinuxディストリビューションの草分け的存在だったそうです。また、サポートが限定された無償版も配布されていました
特徴は、パッケージ管理システムに RPM (RPM Package Manager) を使用していることです。RPM はもともとは Red Hat Package Managerという名前で、Red Hat社が開発したものでした
RPMは、Red Hat 系以外のディストリビューション (SUSE Linux や Vine Linux) にも採用されており、それらをまとめて、 RPM系ディストリビューション と呼ぶこともあるそうです
エンタープライズ専門の Red Hat Enterprise Linux(RHEL) と コミュニティ主導の Fedora
2003年、Red Hat社は Red Hat Linux の開発を中止し、今後はエンタープライズ専門の Red Hat Enterprise Linux を開発すると発表しました (当時、Red Hat Linux はマイナーアップデートでもカーネルやライブラリの互換性が失なわれるなど、商用利用には少々難があったそうです。そのための方針転換のようですね)
その際、無償版 Red Hat Linux は Red Hat社が支援するコミュニティ Fedora Project が提供するLinuxディストリビューション。 Fedora に引き継がれました
Fedoraが最新の技術を積極的に取り込み、その成果が RHEL に反映される という流れがここから生まれました
Fedora と RHELのリリースサイクルと保守期間
余談ですが、Fedora と RHEL のバージョンは直接対応していません
Fedoraは、半年に一度メジャーバージョンがupされ、おおよそ13ヶ月そのパッケージが保守されます
RHELは、RHEL 8 以降、メジャーバージョンを3年毎にupし、マイナーバージョンを半年毎にupします
また、メジャーバージョンは5年間サポートされ、その後も5年間はメンテナンスサポート(新機能の追加が無い更新)されます。さらに、その後任意の数年間「延長ライフサポート」が行われます
サポートが長いのが、RHELのウリです
RHELの無償版クローン(と認識されている) CentOS
RHELはエンタープライズ向けのOSとなりましたが、ソースコード自体はOSSのため公開されていました。そこから 商標や商用パッケージを除いてビルドしたものが CentOS です
CentOS 自体はRed Hat社とは関係ないコミュニティ主導のプロジェクトでしたが、2014年にRed Hat社が支援を表明。CentOSのコアメンバーがRed Hat社に入社したそうです
CentOS は RHELの無償版クローンと認識されていますが、公式は「CentOS Linux is NOT a clone of Red Hat® Enterprise Linux」と否定しており、CentOSの独自機能repositoryもあります。ただし、RHEL由来のコードは変更されないようにしているらしいです
そういった経緯があるため、CentOS を使っていて Fedora や RHEL 由来の不具合があった場合、上流プロジェクトでの修正を待つ必要であります。そのため、CentOSには、 変更の反映が遅い という欠点があります。そして、これが CentOS Stream 誕生の伏線となります...
Fedora と RHEL の橋渡しをする CentOS Stream
ついに CentOS Stream です。2019年に CentOS Stream 8 が発表されました
CentOS Stream は、これまでの RHEL のクローンではなく、RHELの開発サイクルに組み込まれ、 Fedora の内容を RHEL に組み込む前段階 としての役割を持っています
つまり、これまでは Fedora -> RHEL -> CentOS という流れだったものが、 Fedora -> CentOS Stream -> RHEL という流れになります
今後は、RHELのマイナーリリースは、CentOS Stream を噛ませて、OSSコミュニティの開発者やユーザの意見を取り入れて行われるとのことです
なお、CentOS Stream は開発者用プラットフォームという位置づけのため、本番環境での利用する性質のものではありません
そもそも CentOS の時点でも商用利用でしたら RHEL を使ったほうが良いとは思いますが...セキュリティアップデートとかもRHELの後になりますし...
CentOS Stream のメリット
開発方法の変更により、CentOSと比べて、以下のようなメリットが生まれました
Fedora由来の不具合やセキュリティfixの高速化
今までは、RHELの修正を待つ必要がありましたが、それを待つ必要がなくなりました
OSSのコミュニティがRHELのマイナーリリースに貢献できるようになった
これまでは、OSSコミュニティが CentOS の RHELのコードベース部分に手を入れたい場合は、Fedora を介する必要がありました。(そのための Fedora ELNというプロジェクトがあるそうです)
ただし、RHEL が Fedora のコードベースを持ってくるのは、メジャーバージョンアップの時だけなので、RHELのマイナーバージョンアップにOSSコミュニティが介入する方法はありませんでした
しかし、今後は RHEL のマイナーバージョンアップの前に CentOS Stream を介するため、このタイミングでOSSコミュニティが、RHELのマイナーバージョンアップに対して、PRや意見を出すことができるようになりました
これにより、RHELのマイナーバージョンアップに対して、意見が出せるようになったのですが、反面、RHELのベータテストをCentOSユーザにやらせるのか という意見も上がっているようです
👇 こちらのコメント欄で意見が色々出ています
Red Hat社のQAでは「CentOS Streamの方がRHELよりも先に変更が行われるため、RHELよりバグは少なく、機能は多い」と回答しています
👇 こちらの 「Q5: Does this mean that CentOS Stream is the RHEL BETA test platform now?」
CentOS と CentOS Stream の今後
CentOSは、 CentOS Stream に開発を注力するため、以下のようにするとのことです
- CentOS 9: リリースしない。CentOS Stream 9 がリリースされる
- CentOS 8: 2021年末でEOL。CentOS Stream 8 への移行を推奨
- CentOS 7: 以前からの予定通り、2024/6末でEOL
まとめ
「無償版RHEL」という認識で、CentOS を本番環境で使用していたユーザからは大きく不安の声が出ているようですね...
私も前社のオンプレ環境で使用していました。ちょっとしたオンプレのプロジェクトや社内サーバはRHELではなく、CentOSという方も多いのでは無いでしょうか
このあたりが今後どこに移行されていくか注目ですね
おまけ
CentOSを本番環境で使う是非が議論されているフォーラム
(やはりセキュリティとサポートの有無について議論されていました)
「CentOSは死んだ」というやや過激な記事。こちらではCentOSの代替が議論されていました
- Oracle Linux (こちらも RHELベースなんですね) や Ubuntu LTS という意見が出ていました
2020/12/16 追記
👇 Fedora、CentOS Stream、RHEL のデリバリーの流れについて分かりやすく説明してくれています
👇 CentOSのプロジェクトの創始者がCentOS代替プロジェクト、Rocky Linuxを立ち上げ
👇 RHELのソリューションアーキテクトの人のツイート「そもそもCentOSだって定期的にupdateしないといけないし、安定した問題がない状態なんて幻想」というお話
「CentOSが他の無料ディストロより固い(or 慣れてる etc.)から使っててしょっちゅうyum update -yしてるよー」って人はCentOS Stream使ってもおおむね事故らないと思う。そうじゃない人はRockyその他に期待して……。
— Kazuo Moriwaka (@moriwaka) December 16, 2020
「バグは事実上無限にあり安定した問題がない状態など幻想の中にしかないのだ」から会話するのしんどい……
— Kazuo Moriwaka (@moriwaka) December 16, 2020
OpenSSLのリリースストラテジを調べた
OpenSSLの最新バージョンはいくつ? 今サポートされているバージョンはどれ? いつまで? とかわからなかったのでまとめる
先に結論
2020/12/10 現在
- 最新版: OpenSSL 1.1.1 (LTS)
- サポートされているバージョン
- 1.1.1 〜 2023/09/11
- 1.0.2 サポート切れだが、セキュリティfix については有料サポートで対応
- それ以外はサポート終了
リリースストラテジについて
詳しくは公式を読んでください
- 最新は1.1.1(LTS)。次のリリース予定は3.0.0
- 3.0.0 から、セマンティックバージョニング になる予定(
MAJOR.MINOR.PATCH) - LTS(Long Term Support)は、最低5年サポート、4年に1回LTSが指定される
- 通常バージョンは、最低2年サポート
- サポート終了年は、セキュリティfixのみ提供
- プレミアムサポート を受けることで、EOLになった最後のTLSのセキュリティfixを受けることができる
root権限を持たないユーザで 80番ポートを開放しようとすると選ぶと怒られる理由
Dockerfileをベストプラクティスに沿って作るとそうなりがち
理由
0〜1023 までのポートは well known port と呼ばれ、開放にroot権限が必要なため
そういう場合に8080を選ぶ理由
8080は、非rootユーザがwebサーバを立てる時の使うポートと、IANAで定義されているため
ローカルでAWS Lambda ランタイムと(ほぼ)同様の環境でserverlessを動作確認する方法
先に結論
--docker オプションを使う
serverless invoke local --docker --function hoge
解説
--docker オプションを使うと、AWS lambda が公式に配信しているDocker でシミュレートされた Lambda 環境 ( lambci/lambda ) をつかって、serverlessをローカルで実行してくれる
オプションの解説
lambci/lambda の解説
この lambci/lambda イメージは Lambda 環境の完全なコピーではなく、一部のファイルが欠落している可能性があることにご注意ください。