Ubuntu 無人セキュリティアップグレード を 適切に設定
無人セキュリティアップグレードコマンド unattended-upgrades 使ってますか?
聞き慣れないかもしれませんが、Ubuntuをデフォルトで使ってる場合、ほぼ100%の方が自動で使ってます。
Server用途で使う場合、想定してないサーバー動作につながるので、確認しておくと良いかと。
確認環境 : Ubuntu 20.04 LTS
unattended-upgrades
apt の Daily Service
Ubuntu の パッケージ管理コマンド apt を導入すると、次の2つの 日次実行サービスが 登録されます。
1つ目は、毎日 apt update かけてくれるサービスで、2つ目は、毎日(特定リポジトリの) apt upgrade かけてくれるサービスです。
- apt-daily : Daily apt download activities
- apt-daily.timer
- apt-daily.service
- apt-daily-upgrade : Daily apt upgrade and clean activities
- apt-daily-upgrade.timer
- apt-daily-upgrade.service
いずれも Service に登録されてるは ExecStart=/usr/lib/apt/apt.systemd.daily で、この中から unattended-upgrades が呼び出されていました。
Djangoベースの Wagtail さわってみた
ブログ・CMSっていうと Wordpress というイメージもってます。
個人的に悩ましいのは、(いまは)普段使いじゃないPHPベースなこと。
あと一度見たテンプレートに、がしがしコードが書いてあったので、扱いづらそうなイメージ持ってしまったこと。
そこで見つけたのが Django ベースの Wagtail 。
イギリスの Torchbox社が主となり、GitHub上でBSDライセンスで開発しているCMS。
Wordpressと違うの?
(相互に誤解あるかもだけど)結構違うという感触です。
Wordpressが、ブログをベースのCMSで、投稿+固定ページから構成されており、フロントテーマもデフォルトが用意されてる。
Wagtailは、CMSの基本的な骨組み(Wagtail管理画面等)をDjango上に構成して用意。投稿や固定ページという型からすべて自分で組み上げれる作り。
具体的には Django の Model を定義して、ページ構成を作り、Djangoの Template でデザインを作る形になってます。
Wagtailの事例にもあるのですが、ヘッドレスCMSとかやるときにはスッキリ当てはまりそう (WagtailをAPIサーバーとして使う)。
OAuth2.0 関連読む時のチェックポイント
OAuth2.0 難しいなぁ。。。って思ってみてたら、実装方法の幅があり、前提としてる条件を抑えておかないと読みきれない事に気づきました。
自分なりにまとめてみたものは、次の表です。
ポイントと思うところ
いろんな用語が出てくるので、悩ましかったのですが、まず自身が理解しようとしてる OAuth の次のあたりの実装を押させると早いと思います
関連
なんとなーく、流れを把握してくのにオススメ
1挙動1画像で、わかりやすくかいてくれています。
しっかり理解していくときには、こちらがいい。
上記の著者の 川崎 貴彦さん が書いてる、次の記事もオススメ
識別子型、内包型のメリット・デメリットなど体型的な情報が得れるかと思います
MySQL 8.0 意識しておきたい 5.xとの違い : デフォルト設定各種
いまごろですが、以前は my.cnf での必須設定だったパラメーターが変わったなーって思ったので、まとめました。
最初 : 5.x って書いたのですが、心のなかで 5.6 あたりと比べてます。 (5.7 運用してなかったので)
Ubuntu 20.04 + MySQL 8.0.23 での経験ベースです。
- ver8.0.0 で設定の削除
- ver8.0.0 でデフォルトON
- ver8.0.0 でのデフォルト値の変更点
- expire_logs_days
- 文字セット と 照合順序
- ver8.0.0 で追加されてたパラメーター
- innodb_default_row_format=DYNAMIC
- その他
- 確認方法
- その他