Nextcloud version 26~27のアップデートプログラムは不具合多数なので要注意 ※version28以降にアップデートすれば概ね解決する

概要

2023年の年末にNextcloudのメンテナンスを行った時に、version26~27のアップデートで難儀したので備忘録として対策をブログに残しておく。


発生した不具合一覧

  • version26にアップデートするとNextcloudが起動しなくなる
  • version26にアップデートするとブラウザのアップデートメニューが利用できなくなる
  • version26にアップデートするとブラウザに何も表示されない状態になる(真っ白になる)
  • version26にアップデートするとログインフォームが表示されない
  • version26にアップデートするとNextcloudメールが読込み中(ローディングGifの表示)から進まなくなる
  • version28にアップデートするとNextcloudのプラグインの一部が動作しなくなる(互換性に問題がある)

原因と対策

version26にアップデートするとNextcloudが起動しなくなる

  • 原因:
    Nextcloud version26からPHP8.xが必須になっていて、version25まで対応していたPHP7.x系では動作しなくなる。
  • 対策:
    Ubuntu18.04/20.04系を利用している場合はPHP8.1を標準リポジトリで導入するためにはUbuntu22.04へアップグレードする必要がある。Redhat/CentOSの場合もRedHat7系ではPHP8は対応していないのでRedhat8or9系にアップグレードする必要がある。

    更に注意が必要なのは、Nextcloud version25.x系ではPHP8.1までしか対応していないのでPHP8.2以降にアップグレードしてはいけない。
    PHP8.1にアップグレードした後、PHP7.x系でNextcloudを動作させるために設定した値を反映させる必要がある。(php.ini, php-fpm.conf, www.conf, nginx.confなど)

version26にアップデートするとブラウザのアップデートメニューが利用できない

version26にアップデートするとブラウザに何も表示されない状態になる(真っ白になる)

version26にアップデートするとログインフォームが表示されない

  • 原因:

    mysqlのinnodb_buffer_pool_size ,join_buffer_size, max_allowed_packetのキャッシュが足りない
  • 対策:

    mysqlのconfファイルで適切なキャッシュサイズを設定する。(以下は一例なので環境に適した値を設定する)
    innodb_buffer_pool_size=512MB ## 512M以上の値
    join_buffer_size=64M     ## 64M以上の値
    max_allowed_packet=256M  ## 256M以上の値
    
    phpのヒープ領域が足りない

    php.iniのmemory_limitを適切な値に設定する。
    公式では minimum 128MBで推奨512MB以上のメモリが必要と記述されているが、ヒープサイズは最低でも1GB確保できるようにした方がいい。
    可能であれば物理メモリの半分程度、PCのメモリが4GBなら2GB程度を割り当てた方が良い。

    memory_limit = 2000M
    
    古いバージョンのCookieが影響してWebフォームが正常に動作しない

    ログイン情報等がCookieにキャッシュされたままアップグレードするので、Webフォームが正常に動かない場合はCookieを削除して、ブラウザを全て閉じてから開きなおすと動作が改善する場合がある。

    Nextcloud version26以降ではマイナーブラウザでは正常に表示できないことがある。

    メジャーなChrome,Firefox,BraveやEdgeはOKだったが、Chrome系ブラウザであってもマイナーブラウザだとプラグインのインストールが求められる場合がある。
    (※プラグインをインストールしても動かないので、実行するブラウザを変更した方がいい)

version26にアップデートするとNextcloudメールがローディングGifの表示から進まなくなる

  • 原因:

    mysqlのtimeout設定が短いと、DBからデータ取得できず要求したまま進めなくなる現象が発生する
  • 対策:

    具体的には、wait_timeoutとinteractive_timeoutを適切な値に設定しなおす事で対策ができる。
    wait_timeout=600
    interactive_timeout=600
    

version28にアップデートするとNextcloudのプラグインの一部が動作しなくなる(互換性に問題がある)

  • 原因:
    プラグインが新しいバージョンに対応していない
  • 対策:

    残念ながら、プラグインが新しいバージョンに対応するまで待つか、自分で改造するなり対策するしかない。

    Nextcloud version26以降はPHP7.x系では動作しなくなっているので、プラグインもPHP7.xまでしか対応していないものは動作しなくなる。NextcloudMail周りはフロントエンドも刷新されてVue.js依存になったので、プラグインが新バージョンに対応していないと動作しなくなっている。


恒久対策

Nextcloud version26系~27系は問題が多くアップデート後の不具合が頻発するので、速やかに version28系までアップグレードすることをオススメします。
(※Nextcloud version28が最新なので、以降のバージョンが安全かどうかは各自で要確認)


脆弱性情報

Nextcloud version 27.x以前のバージョンには、悪意のある攻撃者によってファイルストレージのパスを書換えられる脆弱性が存在する。
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=nextcloud

PHP7.4で動作するNextcloud version27より古いバージョンで運用するのは脆弱性のリスクを抱えることになる。version27以前での運用は利用を限定して、早急にversion28へのアップグレードを検討することを推奨します。

まとめ

公式情報を網羅すれば情報は得られるのだが、公式の情報が雑

不具合の発端

不具合の発端になるのはNextcloud version25からversion26へアップグレードした時に問題が多発する。
公式の情報を注意深く確認していれば、Nextcloud 26以降からはphp8以上でなければ動作しない旨が書かれているのだが、肝心のアップグレード画面にそのような注意書きはないので「動作しなくなるアップグレード」を決行してしまうのだと推測できる。

公式サポートが貧弱な理由

本件で紹介しているNextcloudのCommunity版は自己責任で無料で提供されているのだが、有料版のNextcloudは提携社が有料サブスクへ誘導したい意図が見える。

商売なので、無料版から有料版へ移行したくなる施策は仕方がないとは思うのだが、不具合やユーザービリティの悪化はユーザー離脱に繋がるのでOSSコミュニティ版の品質は順守してほしい。

Enterprise版 有料サブスクをのサービスが微妙

ちなみに、日本公式のNextcloud代理店のサブスクサービスを契約してもアップグレードのサポートは年に1回しか受けられない。
Nextcloudでのアップグレードの問題点を考慮しても、Microsoft365(Teams)やGoogle(Gmail)に依存せずインフラを自社で確保する事に大きな意義がある。

大手のSaaSに依存しないソリューションとしてNextcloudは最良
代替できる機能 NextCloudの機能名 競合 利点
Webストレージ NextcloudFile GoogleDrive,OneDrive Googleに情報を盗まれない、検閲でのデータ消失を防ぐ、多重認証を無料で設定できる、コスト削減
オンライン通話 NextcloudTalk LINE,Zoom,Teams 情報を盗まれない、多重認証を無料で設定できる、コスト削減
Webメール NextcloudMail Gmail Googleに情報を盗まれない、検閲でのデータ消失を防ぐ、多重認証を無料で設定できる、コスト削減

mysqldumpの仕様変更で発生する権限の対応が面倒なのでmysqldumpを使わずクリーンなtsvデータを出力するCLIツールを作成した

mysqldumpの仕様変更で発生するエラー対応が面倒くさい

mysql5.7~mysql8.0あたりで、mysqldumpでも仕様変更があってエラーが発生することがある。

結論から言うとmysqldumpを使わずクリーンなtsvデータを出力するPythonのCLIツールを作成した

mysqldumpの仕様変更で発生するエラー対応が地味に面倒くさいので、secure-file-priv対策とneed the PROCESS privilege対策と根本対策を目的に、mysqldumpを使わずクリーンなtsvデータを出力するPythonのCLIツールを作成した。


発端はsecure-file-privエラー

現象と原因

ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option so it cannot execute this statement

バックアップ等の目的でmysqldumpを利用してデータベースをdumpした時にエラーが発生したときは、ファイル出力するディレクトリを定義しておく必要がある。

対策

my.confファイルにsecure-file-privを定義する。
secure-file-privには mysqldump を実行するディレクトリを指定するのだが、ディレクトリ指定が面倒な場合は""を指定すれば全てのディレクトリでmysqldumpでの出力が可能になる。

[mysqld]
secure-file-priv = ""

設定後にmysqlサービスの再起動が必要


need the PROCESS privilege対策(権限エラー)

現象と原因

need the PROCESS privilege
mysqldumpを実行するための権限が実行ユーザーに割り当てる必要がある。

mysqldump: Error: 'Access denied; you need (at least one of) the PROCESS privilege(s) for this operation' when trying to dump tablespaces

対策

例えば、実行するユーザー名が「dumpuser」
dumpしたいデータベース名が「mydbname」
の場合、以下の権限設定が必要になる

GRANT SELECT, LOCK TABLES, PROCESS  ON mysql.* TO 'dumpuser'@'localhost';
GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER, PROCESS ON mydbname.* TO 'dumpuser'@'localhost';

mysql. へGrant権限を割り当てられない場合(mysql.でのGrant権限がない場合)

ユーザーデータベースのみ権限を付与してmysqldumpを実行するには、該当のDB(同例だとmydbname)へのGrant権限付与を行う。

GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER, PROCESS ON mydbname.* TO 'dumpuser'@'localhost';

管理用データベースのmysql.*の権限を変更せずに、リスクを避けてmysqldumpを実行したい場合は、
「–no-tablespaces」オプションを付与することでmysqldumpを実行することができる。

mysqldump -u dumpuser -p'mypassword' -h localhost -B mydbname --no-tablespaces >mydumpfile.sql

実行時のコマンドライン

上と同じ、実行するユーザー名が「dumpuser」
dumpしたいデータベース名が「mydbname」として、
パスワードは「mypassword」、出力ファイル名は「mydumpfile.sql」と仮定すると、
以下の書式でDBをダンプする事ができる。

mysqldump -u dumpuser -p'mypassword' -h localhost -B mydbname --no-tablespaces >mydumpfile.sql

その他、おまけ

テーブル初期化を含めないdump

mysqldump -u dumpuser -p'mypassword' -h localhost -B mydbname --column-statistics=0 --set-gtid-purged=OFF --no-tablespaces  >mydumpfile.sql

出力ファイルをgz圧縮するdump

mysqldump -u dumpuser -p'mypassword' -h localhost -B mydbname --column-statistics=0 --set-gtid-purged=OFF --no-tablespaces | gzip >mydumpfile.sql.gz

テーブル初期化とANALYZE TABLE文を含めないdump

mysqldump -u dumpuser -p'mypassword' -h localhost -B mydbname --skip-column-statistics --column-statistics=0 --set-gtid-purged=OFF --no-tablespaces  | gzip >mydumpfile.sql.gz

根本的な対策としてmysqldumpを使わずにデータをexportする

そもそもデータ出力だけできれば良い場合はmysqldumpは不要でSELECT権限だけあればいい。
なのでdatabaseとtable名を指定してシンプルにtab区切りのデータを出力するツールを作成した。

https://github.com/kichijoji-cloud/simple-mysqlexport

python mysqlexport.py --user your_username --password your_password --host your_host --db your_db --table your_table --columns column1 column2 --output output_file.tsv

データ運用として使うにはシンプルなCLIツールが非常に便利に使える。
OSSで公開しているのでcsvやjsonの出力が必要な人はソースを改訂すれば活用できると思います。

スキーマを含めたバックアップ等はroot権限相当のユーザーでmysqldumpを実行した方が良いので、適材適所で柔軟に運用しましょう。

「certbotのエラーでSSL/TLSが更新できない」問題点と対策

はじめに

cronでcertbot(letsencrypt)を定期更新しているとcertbotがエラーで動かずに証明書期限切れになったことはありませんか?

certbotをバッチ処理させて証明書を更新することは難しくありませんが、
脆弱性対策としてパッケージを自動更新しているとpythonの依存関係が壊れることがあり、Webサイトのhttpsとして運用しているとサービス停止にもつながるため恒久的な対策を共有します。

前提条件

OSに寄与する依存関係への対策

  • 以下の条件を確認する
    • pipでインストールしたいパッケージが依存しているOSのパッケージがインストール済みである(例えばaptやdnfのpython3-xxxx パッケージ)
    • pythonをユーザー権限で管理している(pyenv or venv でpythonを管理している)
    • pyenvやvenvの環境で、pythonのバージョンやパッケージを自由にインストールできるようにする
    • pipを最新版に更新している
    • snapdを無効化している
    • python2.x系のパッケージが混在しないように必要なパッケージだけに整理している

問題点1:pipのエラーで更新ができない、実行してもエラーになる

エラーメッセージ「ModuleNotFoundError: No module named ‘pip’」

ModuleNotFoundError: No module named 'pip'

対策1-1:pipを最新版へ更新する

pip install pip -U

対策1-2:pipでpipを更新してもエラーになる場合はget-pip.pyを使う

curl -o get-pip.py https://bootstrap.pypa.io/get-pip.py
python ./get-pip.py

問題点2:certbotを実行するとエラーで動かない

対策2-1:certbotが動かない場合は "too many failed authorizations recently" が発生していないかどうかログを確認する

certbot / letsencrypt の規定では1時間に5回以上、同一ドメインから更新の要求が発生すると、利用上限を超えたと判別して最大48時間、certbotでの更新を拒否されることになる。
※2023年10月現在の規定なので、最新情報は以下URLを参照

https://letsencrypt.org/docs/failed-validation-limit/

対策2-2:certbotのプログラムが正常に動作していない(パッケージに問題がある)

certbotが更新できなくなる不具合はパッケージの再インストールで直る場合が多い

環境にも依存するのだが、certbot等のパッケージ依存のソフトウェアで、特定のPythonモジュールが原因で動作しなくなった場合は、パッケージ再インストールで直る場合が多い。

例えば、ubuntu22.04の環境でpython3.10系を利用している当方の環境だと、以下のパッケージがcertbotに関連していたので、これらを一括削除して一括で再インストールすれば最短で復旧させることができた。

certbotをパッケージの再インストールで復旧させる手順
  • certbotが依存するパッケージリストのテキストファイルを作成する
vim mycertbotpkgs.txt
pyopenssl
crypto
certbot
certbot-nginx
pyOpenSSL
acme
configargparse
parsedatetime
pyparsing
  • pipでrオプションを利用して一括でアンインストールする

    pip uninstall -r mycertbotpkgs.txt
    
  • pipでrオプションを利用して一括でインストールする

    pip install -r mycertbotpkgs.txt
    
  • 動作確認

    sudo certbot
    

パッケージ依存に問題があればエラーが表示される。
問題がなければ正しく動作するハズ。


雑感

こういったバッドノウハウはChatGPTやGoogleで検索しても良い回答が見つからない事が多いので、解決した状況を忘れないよう備忘録を残します。

AWSCLIv2を運用するにあたり注意点、パッケージマネージャがない=バージョンアップ毎にストレージを消費する

AWSCLIv2を運用するにあたり注意点、パッケージマネージャがない=バージョンアップ毎にストレージを消費する

詳細は後述しますが、AWSCLIv2を導入すると運用にpipが使えなくなったり、v1のプラグインが使えなくなったりS3互換ストレージに影響があるなど困った事が多発したので、備忘録として情報を残します。


なぜAWSCLIv2への更新が必要になったのか

AWSCLIv2がリリースされたばかりの頃は、不具合が多数報告されていて導入を見合わせていた。2022年末辺りからAWSCLIv1でIAM認証周りでのエラーが発生するようになってきたので、2023年2月頃にUnixシステム全般のAWSCLIをAWSCLIv2へ更新した。


AWSCLIv2はインストールと更新でpipが使えない

AWSCLIv1はPythonのpipコマンドで気軽に導入できていたのだが、
AWS側のコメントでは
「Pythonのコミュニティ側からアクセス負荷が大きすぎるのでpipに置くなと言われた」
とのことで、Pythonと別にインストールする必要がある。


AWSCLIv2のインストール手順

AWSCLIv2のインストール手順自体は簡単で、配布されているZipを解凍して指定のコマンドを実行すればよい。

https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

root権限のインストール

root権限のインストールは展開したZipのAWSディレクトリの installをsudoで実行する
sudo ./aws/install 
上のコマンドは下記と同等のデフォルトオプションが適用される。
sudo ./aws/install --bin-dir /usr/local/bin --install-dir /usr/local/aws-cli 
アップデートも "–update"のオプションをつけていれば適用される。
sudo ./aws/install --update
sudo ./aws/install --bin-dir /usr/local/bin --install-dir /usr/local/aws-cli --update
–bin-dir

/usr/local/bin
のディレクトリへ実行ファイルのエイリアスが配置される

–install-dir

実体ファイルは以下のようなディレクトリへ展開される。
/usr/local/aws-cli/v2/2.xx.xx/~
※ 2.xx.xxはバージョン番号

user権限のインストール

user権限でインストールしたい場合、良くある環境として例えば、
"$HOME/.local/bin"
にPATHが設定されている場合は下記のように指定すればよい。

./aws/install -b $HOME/.local/bin -i $HOME/.local/aws-cli --update
–bin-dir

$HOME/.local/bin
のディレクトリへ実行ファイルのエイリアスが配置される

–install-dir

実体ファイルは以下のようなディレクトリへ展開される。
$HOME/.local/aws-cli/v2/2.xx.xx/~
※ 2.xx.xxはバージョン番号

ユーザー権限で配置する場合は当然ながらsudoを付与してはいけない。


S3コマンドでの影響

AWSCLIv1までのプラグインが使えなくなっているものがあるようで、
awscli_plugin_endpoint
が使えなくなっていて困った。

対策として、CLIのコマンドオプションで"–endpoint-url"を指定できるのでプラグインで指定していたエイリアスをコマンドに毎回付与すればいい。

※AWSCLIv1のヘルプコマンドには掲載されていないが、v1でも最近のバージョンであれば機能する

頻繁にアップデートが発生する(ストレージを圧迫)

ここまでは些細な問題なのだが、
AWSCLIv2はPythonのコンポーネントも含まれるので最新版2.11.12で209MBの容量がある。(インストーラも209MBある)
そして実績値として2月から4月まで2ヵ月で20バージョンのアップデートが発生していた。
更にrootとユーザー権限用のパッケージを分けて管理していると、インストール対象のストレージが消費される。

2ヵ月で20バージョンのアップデートが発生した場合、root権限だけでAWSCLIv2をインストールしていた場合でもストレージを4GBを消費する。pyenvやvenvと併用してユーザー権限でAWSCLIv2をインストールしていると更に4GBずつストレージを消費する。
AWSのインスタンスやVPSで運用していると、ストレージの消費はコストの増加に繋がるため極力無駄を抑えたい。かといって、都度手作業で古いファイルを削除するのも手間が掛かる。


具体的な対策

AWSCLIv2をインストールしたディレクトリを指定することで、そのディレクトリ配下の古いバージョンを削除して最新版だけを残すシェルスクリプトを作成した。

root権限の場合

AWSCLIv2のインストーラを使ってインストール or アップデートをすると指定のディレクトリ、

/usr/local/aws-cli/v2

配下に各バージョンが格納されるので、ディレクトリを引数にバージョンをソートして削除するようにした。

簡単なシェルスクリプトをgithubに公開しているので、需要があれば自己責任でご利用ください。

https://github.com/kichijoji-cloud/autoremove-oldawscli2

使い方は日本語READMEを参照

https://github.com/kichijoji-cloud/autoremove-oldawscli2/blob/main/README-J.md

追記

「CLIツールなのだからPythonで作成すれば簡単ではないか?」という意見が出てくると思うのですが。
Pythonだと「バージョン依存」だとか「Python自体のバグ」だとか「pipしないと動かない場合がある」とか、
安定運用を阻害する要因になるのであえてbashスクリプトで作成しています。

以上、雑多な備忘録ですが役に立てば幸いです。

wp-cliで投稿するWordPressの記事にwp-cliでサムネイル(アイキャッチ)を登録する

今回の施策の発端(プラグインのXO Featured Imageが機能しなくなった)

現在、WordPressの運用にはコンソールからWordPressを制御できるwp-cliを利用している。そしてこれまではwp-cliで記事内で画像URLを定義していれば"XO Featured Image"がサムネイルを自動生成してくれたのだが、記事数が1万件を超えたあたりから画像ファイル名の処理が正常に機能しなくなって誤ったファイル名をサムネイルに抽出するようになってしまった。

※ 本稿の例は投稿データ(post)を対象としている。固定ページ(page)で同じ処理を実現したい場合は、post_typeをpageとすれば実現できる

  • wp-cliで記事を投稿するサンプル
wp post create --post_type=post --post_title=【タイトル文字列】 --post_content=【投稿記事(※画像URLを含める)】 --post_category=【カテゴリの指定】 --tags_input=【タグの指定】 --path=【WordPressのインストールディレクトリ】 --user=【投稿ユーザー名】  --porcelain --post_status=publish 

具体的な対策を検討

  • 【1案】 XO Featured Imageの不具合を調査して解決する(却下)
  • 【2案】 他のプラグインを使う(却下)
  • 【3案】 WordPressテーマのCocoonのサムネイル自動生成を使う(wp-cliの投稿ではCocoonの機能は動作せず)
  • 【4案】 自前で実装(手間は掛かるが最も確実に解決できる)

【1案】は「XO Featured Image」が正常に機能するように復旧できれば手軽なのだが、導入時に調査したときにもタグの位置によってプラグインが機能したりしなかったり、不明瞭な挙動が発生したので時間を割くのはリスクが高い、却下。

【2案】も自前の開発は不要なので手軽だが、「XO Featured Image」以外のサムネイル処理用のプラグインは殆ど全て有料版のアップグレードを要求する。そして有料で契約しても1案と同様の不具合が発生する恐れがあるので却下。

【3案】は「Cocoon」というWordPressテーマに標準で備わっている機能に「アイキャッチ自動設定を有効にする」というオプションがあり、有効にすると記事中に掲載された画像からサムネイルを自動生成してくれる。これが使えないか期待したのだが同機能は手作業で記事を登録するUIをクリックした場合のみ機能するようで、WP-cliのようにAPI経由で記事を登録した場合はサムネイルは自動登録されなかった。

【4案】はできれば避けたかったのだが、WordPressの機能としてphpで実装するとアップデートや脆弱性対策の度に見直しが必要になるので、wp-cliで実現することにした。

結論としては4案でサムネイル登録を実現することができた。
しかし、ネットで検索しても該当する情報が乏しくて、wp-cliのリファレンス通りに設定してもオプションの組み合わせによって動かない場合もあるので、備忘録としてブログに残すことにした。(※具体的な手順は後述)

wp-cliを利用する前提条件として、記事名と投稿内容はサニタイジングを事前処理してcliでクオート等を正しく囲っているか確認して、画像URLの情報も明確にしておくことも重要。


WordPressでプラグインを使わずにサムネイルを投稿する手順

手順1: 下書き(draft)で記事を投稿する

記事投稿後にサムネイルを設定する必要があるため、post_statusをdraft設定とする。
この後ですぐにサムネイル設定するので、publishで公開した

wp post create --post_type=post --post_title=【記事タイトル】 --post_content=【投稿記事(※画像URLを含める)】 --post_category=【カテゴリの指定】 --tags_input=【タグの指定】 --path=【WordPressのインストールディレクトリ】 --user=【投稿ユーザー名】  --porcelain --post_status=draft 

このとき、記事タイトルや記事本文の文字列はサニタイズとエスケープをして投稿エラーにならないように前準備しておく。

"wp post create"のコマンドでpost_idを取得する方法

"wp post create"の実行時にpost_idを取得したい場合は、標準出力から情報を得ることができる。

Success: Created post 【post_id】.

正常に取得できれば手順2でPOST_IDを取得する手間が省けるのだが、正常処理のメッセージがこれだけなのか不明瞭であり、結果をjsonで取得するオプションも指定できなかったので、エラー処理も考慮して後述の処理(手順2)でpost_idを取得することにした。

手順2: 投稿した記事のPOST_IDを取得する

「手順1」で設定した記事データを抽出するためには、SQLでwhere句を使えば確実なのだが、wp-cliでは「wp db query」というサブコマンドでSQLを呼び出すことでwhere句を指定できる。
しかし、SQLのエラー処理や0件だった時の処理が手間になるので、今回は投稿した記事を「wp post list」というサブコマンドで、「–orderby=desc」オプションを指定することでPOST_IDの降順からデータを出力してjsonフォーマットで取得した。

wp post list --posts_per_page=50 --post_status=draft --post_typ1 --post --orderby=desc --fields=ID,post_title --path=【WordPressのインストールディレクトリ】 --format=json

※ オプションのposts_per_pageについて
posts_per_pageはlimit句の代わりに抽出上限を制限するもので50件を取得している。WordPressの処理が1件だけで確定していれば"posts_per_page=1"でよいのだが、バッチ処理等で別の更新処理が発生しているとorder順が変わるので50件から抽出している。

上のコマンドで取得したjsonデータ処理

  • jsonの定義(参考)
    {
    {
    "ID": int,
    "post_title": string
    }[]
    }
    

手順3: 投稿した記事タイトルとjsonのpost_titleが合致するデータを検索

手順2で出力したjsonデータの中から記事タイトルが合致するID(=post_id)を抽出する。

  • bashやzshで処理する場合
    標準出力をjq等につっこんで、配列で格納されているIDとpost_titleを抽出する。

  • pythonやphp等のプログラムで処理する場合
    辞書型≒連想配列やjson型定義で標準出力を読み込んで、forループで展開すると辞書型keyを"ID"と"post_title"として値を取り出せる。

手順4: wp-cliからpost_idの記事へサムネイル画像を登録する

wp media import 【WordPressへ登録する画像URL or ディレクトリ】 --path=【WordPressのインストールディレクトリ】 --post_id=【取得したPOST_ID】 --title=【記事タイトル】 --featured_image 

手順5: 対象の記事を公開(publish)にする

wp-cliの"wp post update"を指定することで、draftの記事をpublish(公開)することができる。

wp post update 【取得したPOST_ID】 --post_status=publish --path=【WordPressのインストールディレクトリ】 

以上でwp-cliだけでdraftで記事を投稿、その記事にサムネイルを設定して、公開設定するまでの流れを処理することができようになります。

wp-cliはWordPressの構築から運用まで幅広く便利なのですが、具体的な事例になる資料が少ないので参考になれば幸いです。


参考記事

  • Useful WP-CLI commands and scripts

https://stefanbohacek.com/blog/useful-wp-cli-commands-and-scripts/

  • Managing WordPress posts using WP-CLI

https://www.34sp.com/kb/managing-wordpress-posts-using-wp-cli

  • wordpress.org公式 wp-cli コマンドリファレンス

https://developer.wordpress.org/cli/commands/

.jpドメイン についての主要ドメインレジストラのDNSSEC対応状況まとめ

DNSSECとは

DNS Security Extensions(略称 DNSSEC)は、インターネットプロトコル (IP) で使用される Domain Name System (DNS) における応答の正当性を保証するための Internet Engineering Task Force (IETF) による拡張仕様である。

https://ja.wikipedia.org/wiki/DNS_Security_Extensions

出典:wikipedia

DNSSECに対応させる目的

悪意のある攻撃者によって所有しているドメインを他者に乗っ取られてしまう危険性があり、具体的には以下のような攻撃にさらされるリスクがある。

  • DNSハイジャック
  • DNSキャッシュポイズニング
  • DNSスプーフィング
  • DNSリフレクション攻撃

これらをDNSSECに対応させることで防ぐことが目的。


各社JPドメインでのDNSSEC対応状況と価格一覧

事業者名 .JPの取扱い .jp DNSSEC対応 .JP WHOIS公開代行 .jp ドメイン料金 DNSSEC料金 WHOIS代行料金 スパム 管理画面
お名前.com※1 3,124円 月110円 年1078円※2 悪質 最悪
Value-Domain※3 3,124円 無料 無料 普通 普通
AWS Route53※4 90ドル 無料 無料 安全 良い
Google Domain※5 4,000円 無料 無料 普通 良い
JPDirect※6 5,181円※7 無料 無料 不明 普通
Gandi※8 4,950円 無料 無料 安全 良い
Cloudflare Registrar※9 無料 無料 普通 普通
名づけてねっと※10 7,920円 無料 不明 普通
Doレジ※11 6,800円 無料 不明 普通

※2022-07-25:「名づけてねっと」「Doレジ」を追加


注釈

※ お名前.com

GMOが運営する日本最大のドメインレジストラで、長所として数多くのTLDドメイン料金が最安値に近い価格で提供している点が強み。
お名前.comの短所としては、管理画面のUIが劣悪で、スパムメールが多くて、DNSハイジャック等の被害も頻繁に発生していて、運営ルールが突然変わり追加料金を請求されたり、運営会社の姿勢も酷い事で有名。同サービスでは管理画面でもメール案内でも利用者を騙して契約させようとする悪質なマーケティングが目立つ。
運営会社はアレですが、サポート対応等の中の人は頑張ってくれていたり、株主優待でキャッシュバックが利用できたり、うまく利用できれば使い続けるメリットもある。

※ お名前.comのWHOIS公開代行料金

お名前.comでのWHOIS公開代行は、ドメインの新規登録時に設定すれば無料で利用できる。
しかし、新規契約時に設定を外してしまった場合や、ドメイン移管で利用しているユーザーは、WHOIS公開代行だけで追加料金で年額1078円が必要になる。
このWHOIS公開代行料金設定は、2000年頃までは新規以外も無料で、いつでも設定できる仕様だったのだが、いつの間にか理由もなく新規以外は年額料金が発生するように改悪されていた。
ユーザー側で防ぐ手段がないので、こういう事業者だと警戒して、常に移行先のドメインレジストラを調べておいた方がいい。

※ Value-Domain

2011年にお名前.comと同じGMO系列に買収されたが、それまでは業界2~3位の地位で運営が続けられていた。
現在はGMO傘下=お名前.comの代理店になっている筈だが、DNSSECやWHOISが無料である事を見ればわかるのだが、良心的な価格でサービス提供が続けられている。しかし、DNSSECやWHOISが無料であることは何故かプロモーションされておらず、GMOグループからドメイン移管は無料での移管ができなかったり、GMOグループの闇がよくわかる。
尚、2011年以前にはクレジットカード番号の漏洩事故が発生しており、万全な漏洩対策をしたと表明した後にも2015年にアカウント乗っ取りが可能な脆弱性が判明するなど、決済の取り扱いには警戒した方がよい。
決済への警戒が必要なValue-Domainだが、GMOが買収する前に利用できていたPayPalの定期購入が利用できなくなっており、自動更新契約を登録するにはクレジットカード番号を登録するか、事前入金が必須になる。

※ AWS Route53

AWSを利用するユーザーであれば、Route53でドメイン管理できれば、UIも統合されてセキュリティも信頼できて非常に便利で有用なのですが。
.jpドメインに関しては利害関係の影響なのか、取り扱いが開始されたのも他のTLDよりも遅く価格も年90ドル(最安値の約3倍の価格)と高額なので、よほど予算に余裕がない限りはAWSを選択することは難しいように思える。
.jpドメイン以外であれば異常に高額ということはなく、.netであれば年額11ドルで登録することができる。

※ Google Domains

AWSと同様にGCPを利用するユーザーであれば、UIも統合されてセキュリティも信頼できて非常に便利で有用に利用できる。
AWSと違って価格が4000円に抑えられているので、日本の事業者と比較しても特別に高額な設定ということはない。そして.jpドメイン以外でも最安値に近い価格で提供されており、.netであれば年額1400円で登録することができる。
残念な点は、.JPドメインではWHOIS公開代行が提供されておらず、他のドメインでは「プライバシー保護」を強調しているのに .jpドメインのWHOIS公開代行は提供していない。

※ JPDirect

.jpの権利者であるJPRSという団体が運営する .jpドメイン公式のドメインレジストラ。
公式の卸元なのになぜかリセラーよりも価格が高い。
JPRSについては、FACTAが利権周りを暴露しているので、参考記事のURLも掲載しておきます。

  • 「暴利」ドメイン利権の寄生虫

    https://facta.co.jp/article/201208032.html

    初年度登録が4,015円で、更新料金が5,181円と、二重価格になっている点も問題があるのだが、他社の事例を真似たのだろうか。
    良い点もあり、DNSSECとWHOIS公開代行が無料で条件もなく提供されていて、DNSも安定している。UIもシンプルで使いやすい。中の技術者や運営の人はしっかりしているように見える。

※ JPDirect .jp料金表示

他社の表記と合わせるため、更新料金の5,181円を基準としました。
(条件によってはドメイン登録の初年度のみ1円や10円で販売されていることがあるため、新規の登録料金は除外した)

※ Gandi

フランスの大手ドメインレジストラのGandi社、企業理念として「No Bullshit」を掲げており、その意味は「邪悪なことはしない」。

https://www.gandi.net/ja/no-bullshit

これは設立当初のGoogleの企業理念「Don’t be evil.」と似ている。
※ Googleは2018年5月から「Don’t be evil.」の企業理念を削除している

同社はホスティングも提供しており、DNSSECやWHOIS公開代行、SSL証明書や2つのメールボックスも無料で提供している。ドメインの価格は.jpドメインが年額4950円で、.netドメインが$18.5、料金設定はやや高い。

※ Cloudflare Registrar

Cloudflare社のドメインレジストラで、取り扱いドメインを卸売り価格で販売すると公言している。
実際の価格を見ると .net が$9.77が提供されていて、日本と海外も含めて最安値クラスだとわかる。しかも、DNSSECやWHOIS公開代行といった必要不可欠なオプションも無料で提供されている。

長所ばかり目立つが、レジストラとして取り扱っているドメインに .jpドメインは含まれていない。その他にも取り扱っていないドメインとして .work や .cloud といった比較的メジャーなTLDにも使えないものが多い。
Cloudflare社はCDNの提供が基幹業務であり、同社でドメインを登録してCDNを利用してもらう前提で提供されている。そのためなのか、他社にないルールも存在しており、利用条件や規約はしっかりと確認してから契約した方が良い。

※ 名づけてねっと

NTT系列のWebArenaが提供するドメインレジストラの「名づけてねっと」サービス名が駄洒落でガラパゴス風味が強い。

まず、WHOIS公開代行は他社とは違って上から目線で提供する意思がない
「ドメイン管理の最上位団体、ICANNでは、正しいWhois情報の入力を求めております」

  • 名づけてねっとではWhois情報代行サービスの提供はございません

https://help.arena.ne.jp/hc/ja/articles/360038697214-Whois%E6%83%85%E5%A0%B1%E4%BB%A3%E8%A1%8C%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AF%E3%81%82%E3%82%8A%E3%81%BE%E3%81%99%E3%81%8B

そしてDNSSEC対応は .jpドメインだけDNSSECに対応しており、サービス提供が偏りすぎていて誰が使うのだろうか心配になる。

  • 「汎用JP」「属性・地域型JP」にて対応しております(※ .jpドメイン以外はDNSSEC非対応)

https://help.arena.ne.jp/hc/ja/articles/360038696714-DNSSEC%E3%81%AB%E5%AF%BE%E5%BF%9C%E3%81%97%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%81%8B

その .jp ドメインの価格だが、
更新料金が .jp 年間7,920円 と国内事業者としてはボッタクリのレベルで価格が高い。
そして、なぜか新規は最安値クラス年間3,080円(新規)で、NTT系列までGMOのような二重価格(景表法違反の疑い)を採用している点は残念に思える。
「名づけてねっと」での契約のメリットとして、日本企業が好む請求書払い・口座振替が可能である点は大きいかもしれない。但し、請求書・口座振替だと、新規手数料に2000円が上乗せされる。

  • 名づけてねっと・ドメインの料金

https://www.nadukete.net/spec/price.html

WHOIS公開代行が全く使えない時点で、大多数のドメイン管理者はこのレジストラを使う事を避けると思うのだが、
NTT系列を信頼していて「ICANNが正しいWhois情報の入力を求めている」というポリシーに賛同して個人情報を全世界に晒しても良い人や、どうしても請求書払い・口座振替で決済したい事業者には良いのかもしれない。

※ Doレジ

「Doレジ」は旧日本テレコム(現ソフトバンク)系列のサービス。

WHOIS公開代行は .com/.net ドメインのみ提供しているのだが、それ以外のドメインはWHOISを提供していない。
.jp ドメインの料金は更新料金6,800円とかなり高額で、新規は年間4,000円。(※二重価格表記の恐れあり)

  • DoレジのWhois公開代行 → .net/.com ドメインのみ提供

https://www.do-reg.jp/regist/info_comnetorg.html

  • Doレジ 料金表

https://www.do-reg.jp/price.html

「名づけてねっと」同様に、WHOIS公開代行に対応していなくても .jpドメインは取得できる。
更新料金が .jp 年間6,800円 と「名づけてねっと」と同レベルでボッタクリのレベルで価格が高い。しかも新規料金は「名づけてねっと」よりも高い。

  • Doレジ → .jp DNSSEC設定

「Doレジ」でのDNSSECは、レジストラでの設定は受け付けるが非サポートという意味不明な扱いで提供されている。
正常に機能するかどうかも不明で、サポートも受けられないDNSSECの設定のために契約するのは避けた方がいい。

  • DNSSECを利用するにはどうすればよいですか?

https://www.do-reg.jp/faq/?question=343&group=4

→ 管理画面にて、ドメインレジストラのDNSサーバに反映されるDSレコード等を登録することができる。しかし、正常に機能するかどうかはサポート対象外、障害が発生してもサポート対象外

  • Yahoo! BB顧客情報漏洩事件(2004年)
    YahooBB契約者660万人の個人情報・契約者情報が漏洩「実態は窃盗事件」「カルト宗教の幹部が流出事件に関与」

https://ja.wikipedia.org/wiki/Yahoo!_BB%E9%A1%A7%E5%AE%A2%E6%83%85%E5%A0%B1%E6%BC%8F%E6%B4%A9%E4%BA%8B%E4%BB%B6

  • ソフトバンク代理店、顧客に無断で携帯契約(2022年)

https://www.sankei.com/article/20220712-A5KWEIOGE5I2BDMCITXFRBKJHU/

また「doレジ」のトップページを見ると、悪名高い「Zenlogic=旧ファーストサーバー」の利用へ誘導する案内バナーが貼られている。価格も「Zenlogic」のほうが安いことがわかる。
そして、旧ファーストサーバーの前科も含めてソフトバンク系列の実態を知っているなら、使ってはいけないサービスだと分る筈。

  • Wikipedia ファーストサーバー・データ全消失事故

https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%83%BC%E3%82%B9%E3%83%88%E3%82%B5%E3%83%BC%E3%83%90#%E3%83%87%E3%83%BC%E3%82%BF%E5%85%A8%E6%B6%88%E5%A4%B1%E4%BA%8B%E6%95%85

サービス提供の基準も不明瞭で、価格は高額で、技術的にサービス提供できる事も提供せず、親会社が詐欺契約や行政指導の常習犯のソフトバンクという時点で契約しない方が良いと断言できる。
ソフトバンク系列との癒着があって、あちら系を使うしかない人は仕方なく使うのかもしれない。


おすすめのレジストラ

WHOISの代表者情報に公開される事に抵抗がなく、英語のサービスでドメインやサーバー運用ができる場合

  • Google Domains
    Googleなので突然サービス停止が告知されたり、漏洩や脆弱性が発生しても何も告知がなかったり、価格や仕様が全く違う方向性になる可能性もありますが、Google というブランドを信用して利用するなら「Google Domains」はコスパも良くて最適です

マイナーなTLDも含めて安価にDNSSECやWHOIS公開代行を運用したい場合

  • Value-Domain
    マイナーなTLDも使いたい、.jpドメインのDNSSECやWHOISを使いたい、事業者の評判に多少の不安があってもコスパよく運用がしたい場合は「Value-Domain」が最適です

AWSでの運用を重視

  • AWS Route53
    AWSを中心に利用していて、クライアントにも話を通しやすいので、とにかくAWSのサービスだと都合がよい場合は「AWS Route53」が最適です

コスパを重視して .jp ドメインは使わずに、問題の少ない .com や .net 等の主要TLDだけを利用する

  • Cloudflare Registrar
    どんなドメイン名を使うかよりも、コスパのよい運用のためにドメインを準備する。安全に使える .com や .net 等の主要ドメインだけで構築するなら「Cloudflare Registarar」が最適です

雑感

レジストラ側も商売でやっていることなので、開発費・運用費が嵩むのであらゆるセキュリティ対策に対応することは難しいと思うが、
レジストラ側のセキュリティ対策やNameServerの管理が不十分であるほどDNS乗っ取りの危険性が高くなるので、DNSSECは優先して対応してほしい。

以上、備忘録として纏めました。
ドメインレジストラやDNSSECについて調べている人の参考になれば幸いです。

話題のPlanetScaleを調査して、実際にWP-CLIからWordPress用のDBを構築してみた

Zennの記事でPlanetScaleを知る

以下、Twitterにも投稿した内容ですが、備忘録としてブログにも書きました。

話題のPlanetScaleをAWS Lambdaから使ってみた

https://zenn.dev/taroman_zenn/articles/3d03c3030e3bf2

SaaS提供のMySQLについての記事でAWSのRDSと比較すると十分に代替になりそう。

しかも破壊的な価格設定で、
フルマネージドでスケーラブルなMySQLが10GBまで無料。

https://planetscale.com/blog/introducing-new-planetscale-pricing

他社のDB事業を破壊したAWSが追われる立場になるかもしれない。

Zennの記事では分からない注意点

LambdaやコンテナからRDBへ接続した時の不整合対策について

注意点として、LambdaやコンテナからRDBへ接続した時の不整合対策について触れられていない点が気になるのだが。

別のブログによるとPlanetScaleのMySQLは外部キーが使えないらしい

https://crieit.net/posts/Prisma-PlanetScale

リレーションのないRDB=ほぼKVSですね。

リレーションの制限があるがWordPressにも対応している

PlanetScaleのMySQLはVitessという独自DBで、外部キーが必要な処理はアプリケーション単位で個別対応している。

  • 例えばWordPressは2020年に対応済み

https://planetscale.com/blog/announcing-vitess-8

コスパ重視でRDBを構築するなら

結局のところ、コスパ重視でRDBを構築するならSSDベースのVPSでMySQL専用のインスタンスを立ち上げるのがベストのように思える

MySQL5.7系のRDSをVPS上のMySQL8へリプレイスした備忘録

https://blog.hidenori.biz/1313

PlanetScaleはWordPressのような特定用途や、SPAでKVS的に使うには貴重なSaaSになりそう。

検証していないけれど組み合わせで出来そうなこと

Heroku + PlanetScale

どちらも無料プランの範囲であれば恒久的に無料で利用し続けることができる組み合わせ。
特にWordPressを構築した場合は、Heroku無料プランの弱点であるメモリの少なさをカバーしてCrearDBにも依存せずに運用できる。

HerokuはRDS等の外部のMySQLへ接続する情報も多数出ており、PlanetScaleをMySQL用のアダプタで接続するハードルは低いと思うのだが。無料のHerokuはメモリ512MBしか使えないことや、ClearDBを前提にしているので外部への接続に制限があるかもしれないので、構築する場合は自己責任でお願いいたします。

WordPress用のVitess設定例

PlanetScaleの事例は見つからなかったのだが、PlanetScaleの中身のVitessデータベースをWordPressで使う記事を見つけたので、参考にさせて頂きたいと思う

アプリケーション側(WordPress)のインスタンス側に以下の環境変数を設定すればVitessが対応することになっているらしい。

https://blog.1q77.com/2020/02/wordpress-with-vitess/

※例にあるVitessの仕様がPlanetScaleに反映されているのかどうかは不明


実際にPlanetScaleでWordPressが使えるのか検証してみる

  • planetscale.comでアカウントを作成し、Web画面からデータベースを作成する

    サインアップは無料で、以下のMySQLへの接続情報が手に入る

    • HOST
    • USERNAME
    • PASSWORD
    • DATABASE

mysqlclientとMySQLWorkbenchで接続できることを確認

mysql8のmysqlclientを使用してmy.cnf内で鍵交換を必須に設定して、
PlanetScaleで取得したホストとユーザーとパスワード、データベースを指定すれば容易に接続できる。

mysql -D database_name -h xxxxxxxxxxxx.us-west-2.psdb.cloud -u xxxxxxxxxxxx -p

wp-cliを使ってWordPressを構築する

PlanetScaleでWordPressを構築できるかどうか、wp-cliを使った一般的な手順で試してみた。
検証した環境はUbuntu20.04のVPS環境なので、WindowsのWSL環境やVirtualBoxのUbuntu環境でも同様に構築できる筈です。

※以降は参考までに、ubuntuを前提にwww-dataユーザーで実行する例

  • wp-cliのWordPressの"wp core download"でassetをダウンロードして配置する
export wpdir="myblog"
export dbname="dbname"
export sitename="blog.example.com"
sudo -u www-data wp core download --locale=ja --path="/var/www/$wpdir"
  • wp-cliの"wp core config"でWordPress設定の初期化
sudo -u www-data wp core config --dbname=$dbname --dbuser=xxxxxxxxxxxx --dbpass='pscale_pw_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' --dbhost=xxxxxxxxxxxx.us-west-2.psdb.cloud --dbprefix=wp_ --path=/var/www/$wpdir

以上の処理でwp-config.phpが生成される。

次の処理でPlanetScale上のDBに情報を書き込むのだが、wp-config.phpでSSL/TLS接続を強制する設定が必要になる。

  • wp-config.phpを編集して

    sudo vim /var/www/$wpdir/wp-config.php
    
  • 以下のオプションを追加する

    #define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);
    

PlanetScaleのDBへWordPressの情報を書き込む

  • wp-cliの"wp core install"でインストールする
sudo -u www-data wp core install --url=http://localhost/ --title=$sitename --admin_user=xxxxxxxx --admin_password=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --admin_email="xxxx@gmail.com" --path=/var/www/$wpdir 

ここまでは順調に進める事ができるのだが、PlanetScaleのWeb管理画面で作成したDBのCharsetはutf8がデフォルトで、utf8mb4へ変更することができないことに気付いた。


PlanetScale自体はutf8mb4に対応しているらしい

https://docs.planetscale.com/concepts/database-imports

PlanetScale supports the following charsets: utf8, utf8mb4, utf8mb3. If your table uses any other charset, please consult the official MySQL documentation about charsets.


Databaseをutf8mb4に変更する項目が見当たらない

  • Alter database でutf8mb4へ変更すると1235エラーになるが、内部的には変更できているように見える
    show create database database_name;
    
  • DBを作り直してもcharsetを設定する項目はない
  • 絵文字や特殊文字を無視するなら、utf8のままWordPressを運用しても問題はない
  • Alter tableで個別にutf8mb4に設定することはできるので、念のために設定した方がいいかも
  • PlanetScale専用のCLIツールを利用すれば設定できるかもしれないが、そこまでは検証していない



構築完了

前述のような文字コードの懸念はあったのだが、通常のWordPressと同じようにnginxやapacheを設定すればエラーもなく構築することができた。

そして、構築後にアプリケーション側(WordPress)から見たPlanetScaleのMySQLデータベースの文字コードは

utf8mb4_unicode_520_ci

として表示されている。


まとめ

  • 外部キーが使えないDBと聞いて身構えていたのだが、概ね普通のWordPressの構築手順で問題なく設定できる
  • 今回は検証用のWordPressを構築したのだが、高性能なので本番運用のDBに使わないと勿体ないかもしれない
  • ただ、WordPressを構築できる手順が明確化されていれば、そういう需要は大きいように思える
  • 接続情報はMySQL8相当のsha2化したTLS接続が必須なので最低限のセキュリティも担保できる
  • セキュリティを考慮すると、PlanetScale側でクライアントの接続制限ができると良いのだが、MySQL8用の独自鍵での認証やFirewall的なIP制限、MySQLのGrant設定はできなかった(※何らかの方法があるのかもしれない)
  • SPAアプリケーションからPlanetScaleをKVS的に利用する場合でも、MySQLの運用ノウハウやツールが利用できるのはコスト効果が高い
  • 保存容量が10GBを超えた場合の有料プランは月額$29(※25GBを超過すると1GBあたり$1.25)で、MySQLとしては高いとも安いとも言えない価格だが。フルマネージドでスケーラブルなSaaSでKVSとしても使えるMySQLだと考えると、AWSやAzure,GCPと比べて圧倒的に安価に運用できる。

SPAを安全で安価に構築するために、AWS Cognito, Azure AD B2C, Firebase Authentication, SuperTokens, Auth0, を比較する

JWTトークンでの認証をコストを最小化して安全に運用したい

SPAの構築でJWTでの認証をどのように構築するべきか、コストを最小化して運用上のリスクが少ないシステム設計を検証している。

Webで検索したところ、主要な認証サービスについてそれぞれの情報は豊富に見つかるのだが、コストを比較した情報が少なかったので一覧表を作成して備忘録に残します。


JWTトークンを発行する認証サービスを提供している主要サービスの一覧

サービス名 無料プラン 主な料金1 主な料金2 料金情報URL
AWS Cognito UserPool 50000MAUまで無料 10万MAUまで$0.0055/MAU 100万MAUまで$0.0046/MAU https://aws.amazon.com/jp/cognito/pricing/
Microsoft Azure AAD B2C 50000MAUまで無料 PREMIUM P1=$0.00325/MAU(AD登録が必要) PREMIUM P2=$0.01625/MAU(AD登録が必要) https://azure.microsoft.com/en-us/pricing/details/active-directory/external-identities/
Firebase Authentication 10000MAUまで無料 無料枠内でも電話SMS認証は有料$0.06/件 Firebaseの無料枠が利用可能だが、10000MAU内でも無料枠を超えると料金が発生 https://firebase.google.com/pricing
SuperTokens 5000MAUまで無料 5000MAU毎に月$29追加課金 ※OSS版をホスティングすれば継続して無料利用可能 https://supertokens.com/pricing
Auth0 試用期間22日間 ユーザDBなし・1000MAUまで$15/月~ ユーザDBあり・1000MAUまで$49/月~ https://auth0.com/pricing


コストを抑えて運用リスクも低減したい場合

SaaSでの構築運用はAWS CognitoとAzure ADB2Cのコスパが突出している

AWS CognitoとAzure ADB2Cどちらも50000アカウントまで無料利用できてコスパが突出している。但し、Cognitoを使うにはAWSを契約してIAMやSESの知識が必要になるし、AzureADを使う場合はAzureを契約してAD構築と管理の知識が必要になる。
大手クラウドの中ではFirebaseの無料枠はAWSやAzureの1/5しかなく、単位コストも割高なのだが、FirebaseでWebアプリケーションを構築する人はFirebase Authenticationが候補になるだろう。


コスト最小化を優先する場合

SuperTokensだけがOSSで自前でホスティングが可能

候補の中でSuperTokensだけがOSSで自前でもホスティングして構築運用できるので、万全に運用ができるなら、SuperTokensを構築することで無制限に無料でアカウント認証の運用が可能になる。SaaS版でも5000MAUまでなら継続的に無料利用が可能。
但し、SDKはJava,Node.js,Pythonの3種類しか提供されておらず、Node.js系はReactのサンプルが中心なのでOSSを扱うための制約も大きい。更に公開エンドポイントとデータストアも自前管理する必要があるのでリスクも大きくなる。


構築の容易さやSDKやサービスの情報の入手し易さを優先する場合

Auth0であれば大手クラウドサービスに依存せずSDKも殆どのプログラム言語に対応している

コストよりも、大手クラウドサービスに依存せずにJWT認証を簡単に構築したい場合はAuth0が適しているかもしれない。
但し、無料利用枠が実質的に存在しておらず、安価なプランでは1000MAUまでしかサポートされないので、不特定多数へ提供する公開サービスで利用するのはリスクが高い。


まとめ

既に大手のクラウドサービス、AWS Cognito・Azure ADB2C・Firebase Authentication、3社いずれかを使っている場合は利用中のプラットフォームを選択することが最もコスト対効果が高いと思われる。

  • AWS Cognito
    CognitoはAmplifyとIDプールを不自然に推していたので良い印象がないのだが、ユーザープール単体のサービス価格で考えるとコスパは非常に高い。そして全てのプログラム言語のSDKも揃っているしWebから参考情報も得やすい。

  • Azure AD
    AzureもCognitoと同レベルでコスパが高いのだが、AD構築のコストとADの特殊性を理解して導入する必要がある。

  • Firebase Authentication
    良くも悪くもFirebaseの作法に従う必要がある。GCPとの連携も他のサービスよりも有利だが、Google系のサービスでよくある「できそうに見えてできない」事があったり「Googleなのでサポートは一切なし」だったりする場合もある。

  • SuperTokens
    OSSなので独自ホスティングしてゼロコストで構築運用が可能で、OSSをCloneして解析して独自に改良してForkすることもできる。しかし、情報が少ないのでリスクは高い。(※Apache2.0ライセンス)

  • Auth0
    公式の情報が豊富でSaaSとして非常によいサービスなのだが、無料枠がなくて高額な料金と複雑な料金プランしかない点は契約前に確認したほうがいい。1000MAU未満で運用できるなら候補になるかも。

  • 独自実装も場合によって検討する価値はある
    主要なプログラミング言語であればJWTを構築できるパッケージは多数存在しているので、開発チームに余力があるなら独自実装をしてセキュリティの堅牢化や最適化をする選択肢もありえる。


AWS Cognitoで構築するシステム構成案

WordPressの管理画面から「ツール」→「サイトヘルス」を実行すると「cURL error 28」になってしまう不具合の原因と解決方法

今回の問題点

表題の通り、WordPressの管理画面から「ツール」→「サイトヘルス」を実行すると「cURL error 28: Connection timed out」になってしまう不具合が発生。

しかし、システム上はエラーになる要因が無かったので調査と解決に少し手間取ってしまった。
原因も解決方法も単純だったのですが、Webで検索しても該当する情報が少く解決するのに苦労したので備忘録としてブログに残します。

不具合の原因と解決方法

  • 解決方法

    ブラウザ履歴(キャッシュ)が影響していたので、ブラウザ履歴を削除すれば解決した。

TL;DR

  • 調査の手順

    • ログを確認する
    • ググる
    • 不具合が発生したブラウザと別のブラウザで同じ症状が発生するか確認する

    ※参考までにChrome系ブラウザで履歴を削除する手順を下記する

    • ChromeやFirefox等のブラウザを開く
    • 設定 ⇨ 左メニュー「プライバシーとセキュリティ」⇨ 「閲覧履歴データの削除」を開く
    • 「詳細設定」タブを選択
    • 「期間」プルダウンから「全期間」を選択
    • チェックボックスから以下3点を選択する
    • 閲覧履歴
    • Cookieと他のサイトデータ
    • キャッシュされた画像とファイル
    • 「データ削除」ボタンを実行

その他にも同じエラーが発生する要因があるので箇条書きで纏めておく

  • サイトヘルスのチェック用URLに疎通しているかどうか

  • Firewallやiptables,SELinux,nginxのIP制限等で外部への通信を接続制限している場合は、443ポートからwordpress.orgへ接続できるように設定しておく(※wordpress.orgからの内向き=inbound通信は必要ないので、通常はFirewall等の接続制限が原因である可能性は低い)

  • 公式資料では wordpress.orgへの接続が必要だとなっているが、実際には api.wordpress.orgに接続している

    • ブログ記載の時点で、
      wordpress.orgのIPアドレスは 198.143.164.252,
      api.wordpress.orgのIPアドレスは 198.143.164.251
      2点のGIP疎通が必要になるように見える(※公式情報ではないので各自で要確認)
  • 公式のアナウンスだと、プラグインやテーマの影響で、前述のURLへの接続に失敗する場合があるらしいので、通信を阻害する疑いのあるプラグインは無効化する(※実際には影響する可能性は低いので、プラグイン無効化よりも後述のブラウザ履歴削除から先に試した方がいい。信頼性を疑うプラグインは不具合の有無に関わらず無効化した方がいい)

  • 公式ではアナウンスされていないが、ブラウザの履歴(キャッシュしたファイルとCookie)を削除すると解決する場合がある

    • ブラウザのキャッシュが影響していると管理画面の/wp-admin/site-health.php にアクセスしてもphp-curlが実行されない場合があった
  • PWAやAMPの設定が影響して管理画面が正しく動作しない場合がある

    • PWAには便利そうな機能が多数公開されているが、実際には悪意のある攻撃者にとってのターゲットになるので、ユーザーとしても開発者としても無効化しておいた方がいい
    • Chromeを使うなら、必ずServiceWorkersを無効化しよう

      https://qiita.com/rana_kualu/items/52d8cb7b200d6fefddc8

調査に苦労した点

  • ググっても適切な回答が少ない

    • WordPressにありがちだが、曖昧な表現で「プラグインを全て無効化する」等の現実的ではない回答が目立つ

    • 「設定に問題がある」回答が前提なので、調査する方法等が殆ど見当たらない

      • 複数のWordPressを運用しているので設定に問題がない事は確認済
      • ログにも問題点が出力されないので、phpのコードを追ってパケットの通信を見張ることにした
    • 「キャッシュ全削除」や「別ブラウザで試す」のような調査手順の情報が少ない

    • 自前の開発だと真っ先にキャッシュを疑うのだが、Webで検索すると「キャッシュ全削除」のような回答が少ない

  • tcpdumpでの調査例

    • tcpdumpでパケットを見張ると、正常なブラウザでWordPress管理画面「サイトヘルス」を表示するとwordpress.orgへ接続する通信が発生する
    • 過去のページキャッシュが残っているブラウザで、履歴が問題の原因になっている場合は、wordpress.orgへのパケットが発生しない
      sudo tcpdump -v |grep "wordpress.org"
      
      sudo tcpdump -v |grep "198.143.164."
      

良くある事例だが、仕様上問題がある

今回は「サイトヘルス」診断で「問題がない」のに「問題あり」と判定されてしまったのだが、
解決方法のアドバイスに危険な内容が多く「ファイヤウォールを開ける」とか「プラグインを全て削除する」とか、原因の1つとしてはあり得るが、問題のないシステムを危険に晒すことになってしまう。
そして「問題がある」状態で「問題なし」と判断される可能性もある。

Webアプリケーションの管理画面が提供する診断機能として、設計を見直して改善した方がいいと思う。

AmazonLinux2で運用しているdotnet環境をアップデートするとまた502エラーになった‥

yum update適用後、また502エラーが発生

以前にブログに残した不具合で dotnet 実行ファイルが配置されるパスが変更されて、サービス化した起動ファイルが動かなくなっていたのだが。

今回も原因は同じだった。(※原因は最後の項目に後述)

アップデート後にdotnet実行ファイルのPATHが変更

  • AmazonLinux2での2021年11月(.NET6アップデート)以降の実行ファイルパス
/usr/share/dotnet/dotnet

share へ移動するなら、 /usr/share/dotnet/bin/dotnet の方が一般的なパスの規則にあうように思えるが。 share 直下にプログラムファイルが配置されている。

解決方法

  • エイリアスを作成して対応
    sudo ln -s /usr/share/dotnet/dotnet /usr/local/bin/dotnet
    

補足として、対象のインスタンスはWebフロント用で、直前のバージョンで/usr/local/bin/dotnetに配置していたので運用上問題ないものとしてエイリアス化している。

/usr/local/bin/dotnet だとPATH変数の環境になるためローカルユーザーでも実行できてしまうので、複数のユーザーで共有する環境の場合は適用しても良いかどうか確認したほうが良い。

※補足:原因は以前にブログに残した不具合と同じ

前回の不具合

https://blog.hidenori.biz/1400

yum update

適用後に、

/usr/bin/dotnet

の実行ファイルが

/usr/local/bin/dotnet

へ移動していて、systemdから呼び出すサービスで不具合になっていた。
不具合としては今回も同じ症状でした。

just simple dialy

モバイルバージョンを終了