Google 停用了大量與中國與俄羅斯相關的帳號

在「Google Takes Down Influence Campaigns Tied to China, Indonesia, and Russia」這邊看到的,Google 的說明則是在「TAG Bulletin: Q2 2024」這邊,看起來像是例行性的更新?

與台灣有關的當然就是跟中國相關的影響,也是被停最多帳號的,在報告的最後提到 YouTubeBlogger 上面有掃到上千個與中國政府相關的宣傳帳號:

We terminated 1,320 YouTube channels and 1,177 Blogger blogs as part of our ongoing investigation into coordinated influence operations linked to the People’s Republic of China (PRC). The coordinated inauthentic network uploaded content in Chinese and English about China and U.S. foreign affairs. These findings are consistent with our previous reports.

第二多的則是俄羅斯:

We terminated 378 YouTube channels as part of our investigation into coordinated influence operations linked to Russia. The campaign was linked to a Russian consulting firm and was sharing content in Russian that was supportive of Russia and critical of Ukraine and the West.

其他的就比較零頭了...

WordPress 要放掉 PHP 7.0 與 PHP 7.1 的支援了

WordPress 說要放掉舊版的 PHP,本來看到標題在想是 PHP 8.0 與 PHP 8.1,仔細看才發現是 PHP 7.0 與 PHP 7.1:「Dropping support for PHP 7.0 and 7.1」。

從「PHP 7 ChangeLog」這邊可以看到 PHP 7.0.0 與 7.1.0 分別是 2015 年十二月與 2016 年十二月的事情了... 印象中這是 PHP 效能飛越性提升的年代,從 7.0、7.1、7.2、7.3 到 7.4 都有顯著的改善:「PHP Benchmarks 7.4 vs 7.3 vs 7.2 vs 7.1 vs 7.0 (php-fpm)」。

Internet Archive 上面的「Supported Versions」可以看到 7.0 與 7.1 分別在 2019 年初與 2019 年年底終止維護,離現在差不多是 5 年與 4 年了。

沒注意到 WordPress 還有支援這麼舊的版本,大概是為了一些八百年沒更新的 PHP hosting...

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...

在 Fediverse 上訂閱 X (Twitter) 的內容

Mastodon 上面看到有 bridge service 可以接 X (Twitter) 的內容:

像是 elonmusk 的 X (Twitter) 可以用 @elonmusk@bird.makeup 這個位置訂閱。

程式本身是 AGPLv3,但是是用 .NET Core 寫的,如果要 self-hosted 的話得研究一下了:「bird.makeup」。

然後從 README.md 看起來是用 X (Twitter) 自家的 undocumented API,避免了正式 API 的 rate limit 問題:

Twitter API calls are not rate-limited

Tumblr 的 ActivityPub 進度

先前在「Threads 要放 ActivityPub 了?」這篇提到 Threads 要放行 ActivityPub,剛剛想到 Tumblr 這邊不知道在 re-org 後有什麼新消息,然後翻到 Matt Mullenweg 在 Tumblr 寫了 這篇

主要是交代有指派人做這件事情,但也先舖了一些理由... 所以看看 2024Q1 有沒有機會看到些東西?

Automattic 重整 Tumblr 團隊的內部消息

waxpancake這邊看到的,是一個從內部洩漏的 screenshot,後來 Automattic 的 CEO,Matt Mullenweg,在 Tumblr 上面把完整的內容都放出來,並且加上他的一些說明 (包括了一些內部的 team name 以及他的想法):「Translation of Internalspeak to Externalspeak」。

官方的說法主要就是不賺錢,所以除了客服團隊 (下面提到的 Happiness) 與 Trust & Safety 團隊 (下面提到的 T&S) 外,其他的成員將會被轉移到內部其他的計畫上:

This plan is happening now: the majority of the 139 people in Bumblr will switch to other divisions. No plans for any switches in Happiness or T&S.

"Happiness" is our term for customer support, and "T&S" means trust and safety, which is the team that works on fighting bots, spam, dealing with illegal stuff, etc.

接著有大致提到轉移的過程會是怎麼樣,另外後面提到時間表:

The switchovers will happen on December 31, so we start 2024 completely fresh.

另外在 The Verge 上面的「What is going on with Tumblr?」有另外的說法,不是所有人都有換團隊的權利,很多就直接 layoff 了:

"The majority of the 139 people in Bumblr will switch to other divisions"

This is not what is happening. Many people have been let go (under the guise of performance) and in the past week the pace picked up from individuals to entire teams. Automattic seems adamant these are not layoffs, but people dissapear instantly without being offered alternative teams.

先回到 Tumblr 的情況來看,之後應該就是維護模式了。

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 都清掉就正常了。

拿許久沒用的 abpe.org 出來架 Mastodon

前幾天 Twitter 在搞事情,把未登入的存取方式都擋住了,所以本來透過 RSS-Bridge 的方式也被擋掉了,只好趕快研究 Mastodon 要怎麼架。

https://abpe.org/@gslin 這邊。

要先注意硬體需求,好像沒有文章特別獎,但實際測試後發現 2GB RAM 的 VPS 只是超級低標,光是跑起來就把 2GB 吃乾了,我測試的時候開 VPS (2GB RAM + 512MB swap) 才勉強撐住,swap 都已經吃到 400MB 左右。一開始開 1GB RAM 的時候直接 OOM 給你看...

現在是跑在家裡的機器上,8GB RAM 的機器上面跑個 Sentry + Mastodon 就差不多了。

文件的部分因為想要用 Docker Compose 跑,是參考「How to take advantage of Docker to install Mastodon」這篇跑起來的,把裡面 docker-compose.yml 使用的版本換新再跑,基本上沒有問題。

接下來就是找有誰已經在 Mastodon 上,要花時間訂起來...