換成 t4g.small 後的一些整理

昨天在這邊提到因為 Amazon EC2t4g.small 提供了 free tier 方案 (到今年年底),blog 主機剛好從 t4g.micro 改成用 t4g.small,到年底前可以看看有沒有 t5g 或是類似的主機出來:「往上升級或是用 Unlimited mode 撐」。

除了換完後 CPU credit 給的量上升減緩了情況以外,我在檢查時才發現 PHPopcache 的 cache 使用量也超過預設值 128MB 了,改成 192MB 後看起來 CPU usage 也有下降一些:

這點算是先前沒注意到的,上面 PHP 跑兩個 WordPress 以及一個 MediaWiki (都掛了各式各樣的 plugin & extension),還有一個自己寫的小東西,這樣會超過 opcache 的 cache 大小...

現在換到 t4g.small 後總算又開始養的起 CPU credit 了:

另外也補上幾個 CloudWatch Alarms (看起來 free tier 是十個) 監控主機的 CPUCreditBalance,然後透過 AWS Chatbot 接到自己的 Slack 上,至少之後有狀況的時候會主動通知。

Jetpack 的備份功能失效

發現 1/13 後 Jetpack 就會一直發信通知備份功能失效,像是這樣:

連到 WordPress.com 上把語系改成英文,抓了一下問題發現錯誤訊息是:

We could not back up your site because it appears to be offline
Backup failed

用這個當關鍵字去找可以找到這篇:「13.0 and backups?」,照著裡面的方法把 Jetpack 降版到 12.9.3 後,隔天再看備份就正常了...

先把版本卡在 12.9.3,之後有新版再測試新版...

t4g 的 CPU credit 被吃完了

這個站 blog.gslin.org 掛了三個多小時:

先連機器 SSH 看起來是正常的,但習慣性的 w 看一下情況發現 CPU load 有 6.x,用 top 看一下就看到幾隻 php82-fpm 跑滿 CPU,心裡大概有底是被砍站了...

先把 nginx 停下來,瞄了一下 /var/log/nginx 下面的 log 就知道是 ClaudeBot 造成的,看起來都是從 AWSus-east-1 機器打過來的。

然後翻一下 log 看看什麼時候開始打的,先看 log 已經被 gzip 起來的這些:

$ echo /var/log/nginx/blog.gslin.org_ssl-access.log.{?,??}.gz | xargs -n1 | xargs -n1 -I% sh -c "echo %; zgrep ClaudeBot % | wc"
/var/log/nginx/blog.gslin.org_ssl-access.log.2.gz
  13031  169403 1986719
/var/log/nginx/blog.gslin.org_ssl-access.log.3.gz
    459    5967   85350
/var/log/nginx/blog.gslin.org_ssl-access.log.4.gz
  14533  188929 2219819
/var/log/nginx/blog.gslin.org_ssl-access.log.5.gz
   6502   84526 1026178
/var/log/nginx/blog.gslin.org_ssl-access.log.6.gz
  32483  422279 4905919
/var/log/nginx/blog.gslin.org_ssl-access.log.7.gz
  21304  276952 3221877
/var/log/nginx/blog.gslin.org_ssl-access.log.8.gz
   7921  102973 1199356
/var/log/nginx/blog.gslin.org_ssl-access.log.9.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.10.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.11.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.12.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.13.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.14.gz
      0       0       0

看起來是從 blog.gslin.org_ssl-access.log.8.gz 這邊開始的,大概是 1/25 開始 (機器上面是 UTC 時間):

-rw-r----- 1 www-data adm   1894325 Jan 26 00:00 /var/log/nginx/blog.gslin.org_ssl-access.log.8.gz

然後再來看一下最近的 log,看起來是這兩天打的特別重,到五萬多:

$ echo /var/log/nginx/blog.gslin.org_ssl-access.log{,.?} | xargs -n1 | xargs -n1 -I% sh -c "echo %; grep ClaudeBot % | wc"
/var/log/nginx/blog.gslin.org_ssl-access.log
  29436  382668 4387703
/var/log/nginx/blog.gslin.org_ssl-access.log.1
  51712  672256 7852345

拉了 AWS 的圖來看跟預期的差不多:

機器是 t4g.micro 而且沒開 burstable,先前差不多都是略低於 10% 的線在跑,剛好利用 CPU credit 的概念,這幾天看起來就是被打而跑上去。

好像該補一下 alarm,丟到我自己的 Slack 以及 Pushover...

WordPress.com 支援 ActivityPub

Hacker News 上看到「WordPress.com Now Supports ActivityPub (wordpress.com)」這則,在講 WordPress.com 宣佈支援 ActivityPub:「Engage a Wider Audience With ActivityPub on WordPress.com」。

Hacker News 上的 id=37849725 這篇的說明其實更清楚,其實是 plugin 被 Automattic 買走後包裝起來的行動:

It is more accurate to say that the ActivityPub plugin[1] which was acquired by Automattic has hit 1.0 and is available to be used on WordPress.com. Yes, Mastodon implements (most of) ActivityPub but it's hardly the only platform on the web that does.

[1] https://wordpress.org/plugins/activitypub/advanced/

Anyway 這是個不錯的發展... 之後 Mastodon 上可以直接訂這些 blog 了?

升級到 WordPress 6.3 遇到的問題

WordPress 6.3 出了:「WordPress 6.3 “Lionel”」,順手按了升級就爛掉了,發現是 admin 介面爛掉,網站本身還能瀏覽,先翻出 PHP 的錯誤訊息:

2023/08/09 04:52:32 [error] 845702#845702: *1350433 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught ArgumentCountError: Too few arguments to function W3TC\Util_Environment::is_dbcluster(), 0 passed in /srv/blog.gslin.org/public/wp-content/db.php on line 56 and exactly 1 expected in /srv/blog.gslin.org/public/wp-content/plugins/w3-total-cache/Util_Environment.php:176

順著這個訊息找到這個算新的討論:「Fatal error in Util_Environment」,看起來跟 W3 Total Cache 有關。

(話說這個錯誤訊息還比較新,Kagi 上面找不到,後來是在 DuckDuckGo 上找到)

解法就比較粗暴一點,先到 wp-content/plugins 下讓 W3 Total Cache 失效:

sudo chmod 000 w3-total-cache

跑完升級後會出現錯誤訊息提示 W3 Total Cache 沒有啟用,這時候再開回來:

sudo chmod 755 w3-total-cache

後續把 cache 都清掉就正常了。

WordPress 誕生 20 年

Matt Mullenweg 寫了一篇文章簡單提到 WordPress 誕生 20 年:「WP20 & Audrey Scholars」。

雖然 Matt Mullenweg 在文章裡都沒提到,但 WordPress 的興起其實跟當年 2004 年最大的 blog 軟體 Movable Type 自己出的包有很大的關係:

With the release of version 3.0 in 2004, there were marked changes in Movable Type's licensing, most notably placing greater restrictions on its use without paying a licensing fee. This sparked criticism from some users of the software, with some moving to the then-new open-source blogging tool WordPress. With the release of Movable Type 3.2, the ability to create an unlimited number of weblogs at all licensing levels was restored. In Movable Type 3.3, the product once again became completely free for personal users.

當年 hlb 在社團主機上用 Movable Type 架了服務讓大家寫,結果後來發生了 license 問題,大家就都順勢跑到 WordPress 上了;而等到 Movable Type 再次想放寬 license 的時候已經來不及了,大家都已經搬完了。

翻了一下最舊的文章 (在另外一個 WordPress 上) 是在 2004 年十月的時候寫的,就有提到當時從 Movable Type 換到 WordPress 的考量:「開場:為什麼用 WordPress」。

改用 IFTTT 分享到 Twitter

前面兩個月發文比較少,所以沒注意到 Jetpack 分享功能變成限制一個月只能分享 30 則,超過的部份要另外購買。這應該是 Twitter 之前在搞事的時候順勢推出來的專案?

看了一下應該是 Social 功能,Basic 版本就夠,但然後那個價錢應該是不太可能買 (年繳要 US$12/mo):

替代方案是把先前買的 IFTTT 拿出來用,透過 RSS feed 同步到 Twitter、LinkedInTumblr

本來的 PlurkFacebook 則是從 Twitter 同步過去,應該是不用動,來看一下效果怎麼樣...

新版 WordPress 預設的佈景主體將不會使用 Google Fonts

新版 WordPress 的預設佈景主體 (Theme) 出於隱私考量,將不會使用 Google Fonts:「Google Fonts are included locally in bundled themes」。

這邊講的是年份系列的 Theme,從 Twenty Twelve (2012) 到 Twenty Seventeen (2017):

再更後新的版本,首先是沒有 Twelve Eighteen (2018) (可以從「Themes by WordPress.org | WordPress.org」這邊翻),而從 Twelve Nineteen (2019) 後都沒有使用 Google Fonts 了,在 GitHub 上的 WordPress/twentynineteen 這邊可以 clone 下來確認:

$ git grep google    
classes/class-twentynineteen-svg-icons.php:         'google-plus' => array(
classes/class-twentynineteen-svg-icons.php:                 'plus.google.com',
classes/class-twentynineteen-svg-icons.php:         'google-plus' => '
classes/class-twentynineteen-svg-icons.php:         'google'      => '

官方還是有給繼續使用 Google Fonts 的方法,在「Continuing to use Google Fonts」這段有提到設定的方式。

WordPress 打算要支援 SQLite 作為後端資料庫

目前 WordPress 只有支援 MySQL,而昨天在 Hacker News 上看到 WordPress 有打算要支援 SQLite 作為後端資料庫的消息:「WordPress testing official SQLite Support (github.com/wordpress)」,原文在 GitHub 上:「Implement new experimental SQLite integration module」。

理論上對使用者會更方便,但對 extension 開發者會麻煩一些 (或是直接標不支援?),尤其是用到 MySQL 特有的語法就要注意了。

實質上 PHP + MySQL hosting 其實蠻常見的,這個作法有多少幫助就不知道了。

但突然想到,如果做一個 read-only 版本的 WordPress 站台,然後把 SQLite 的讀取部份改用 sql.js 之類的計畫,再把一堆 server side rendering 的部份變成 client side rendering,好像有機會可以整包直接上 GitHub Pages 之類的服務?雖然這樣有點拖褲子放屁...

WordPress 對 FLoC 的對抗計畫

Google 打算在 Google Chrome 裡面強推的 FLoC 最近有很多消息,但因為沒看完 spec 就一直丟著了... 可以先參考 iThome 的「繼Brave瀏覽器之後,DuckDuckGo、Vivaldi也要封鎖Google FLoC廣告投放技術」,雖然裡面提的很淺。

目前檯面上除了廣告產業以外,所有看到的人與組織都反對 FLoC。

EFF 的「Google’s FLoC Is a Terrible Idea」,之後 DuckDuckGo 也發表了「Use the DuckDuckGo Extension to Block FLoC, Google’s New Tracking Method in Chrome」,再來是 Brave 的「Why Brave Disables FLoC」與 Vivaldi 的「No, Google! Vivaldi users will not get FLoC’ed.」。

最新的進展是 WordPress 決定把 FLoC 當作 security concern 來看,打算直接推出 security hotfix 更新,預設關閉 FLoC:「Proposal: Treat FLoC as a security concern」,在 Hacker News 上也有討論:「Proposal: Treat FLoC as a security concern (make.wordpress.org)」。

主要的原因是正常的 WordPress 版本會在今年七月才出,會跟不上 FLoC 的進度:

Currently, 5.8. is only scheduled for July 2021. FLoC will likely be rolling out this month.

我自己也因為 FLoC 而又再次跳到 Brave,還遇到 imgur Uploader 套件不見 (可以參考「What Happen to the imgur uploader extension?」),以及有些套件無法運作的問題...