おのたく日記 YouTubeも始めました→

■ RSSリーダは、Blogline, Google Reader, Fresh Readerと移り変わってきたけど、いまはDebianのパッケージにあるTiny Tiny RSSを使っている。

おうちさーばを、PHP 8に上げたら読んだはずの記事が既読にならなくなってしまった。

Debianパッケージは、

tt-rss (21~git20210204.b4cbc79+dfsg-1) unstable; urgency=medium [ Sunil Mohan Adapa ]

* New upstream snapshot

* Add self to list of uploaders.

-途中略-

-- Sebastian Reichel Sat, 06 Feb 2021 00:54:20 +0100

[tt-rss (21~git20210204.b4cbc79+dfsg-1)より引用]

が最新版で、upstreamに入っているphp 8対応で入ってないので、とりあえず、以下だけ当てたら、正しく既読になるようになった。

diff --git a/classes/feeds.php b/classes/feeds.php

index 2c37d659a..cc78b498c 100755

--- a/classes/feeds.php

+++ b/classes/feeds.php

@@ -195,7 +195,11 @@ class Feeds extends Handler_Protected {

// frontend doesn't expect pdo returning booleans as strings on mysql

if (Config::get(Config::DB_TYPE) == "mysql") {

foreach (["unread", "marked", "published"] as $k) {

- $line[$k] = $line[$k] === "1";

+ if (is_integer($line[$k])) {

+ $line[$k] = $line[$k] === 1;

+ } else {

+ $line[$k] = $line[$k] === "1";

+ }

}

}

[tt-rss.git - Add workaround for boolean values being intergers with MySQL/PHP 8.1より引用]

■ PHP8が出てきた時に、Scuttleは自分で対応できたのだけど、Pukiwikiは結構修正する場所が多くて、PHP8に対応した1.5.4のリリースを待っていた。

3月27日には出ていたみたいなんだけど、年度末と年度始めで忙しくてやっと対応できた。

ついでに、1.5.3の時にトライしたけどうまく行かなかったUTF-8化もやってみた。対応ツールが2になっていて、今度はコマンドを実行するだけで、うまく行った。

まず、Wikiに書いてあるとおりのコマンドで、1.5.3をutf-8にして、その後、

としたところにファイルを上書きして、自分で修正していない部分は、VSCodeのgit viewで差分を見ながら、CTRL-K CTRL-Rで修正破棄をして、1.5.4に対応させた。lib/ plugin/ のファイルの殆どは、ファイルごと修正破棄なので、pukiwiki.ini.phpとスキン周りだけ注意深くすればOK。wiki/以下で変更を加えていたのは、サイドバーメニューなどの2つだけだったので楽勝。1.5.3に上げたときにはEUC-JPだったので、gitが使えず、emacsでのcompare-windowだったので、今回はずっと楽。

gitが使えるようになったから次のバージョンからは、upstreameブランチのpullと、ワークブランチへのmargeで出来るようになって楽になるはず。20年近く使っているPukiwikiも無事にUTF-8化され最新版の1.5.4にバージョンアッブできた。

これで、php7.4-fpmなどが要らなくなったので、php7.4関係のDebianバッケージをアンインストール。今後は、PHP8.1になった。

■ [Asterisk] upgradeで留守電が使えなくなる

Debian Package testing (13 bookworm)にAsterisk 18が落ちてきたのでupgradeしたら、留守電機能が使えなくなってしまった。

良く分からなかったのだけど、調べてみたらupstreamが18になったときのDebianパッケージのチェンジログで

asterisk (1:18.9.0~dfsg+~cs6.10.40431411-1) experimental; urgency=medium

--中略--

* package asterisk-modules now include modules

app_voicemail app_voicemail_imap app_voicemail_odbc;

drop packages asterisk-voicemail

asterisk-voicemail-imapstorage asterisk-voicemail-odbcstorage;

add NEWS entry that users of imap or odbc variant

need to adjust configuration

--中略--

-- Jonas Smedegaard Fri, 04 Feb 2022 21:59:09 +0100

[Changelogより引用]

どうやら、astersik-voicemailパッケージの内容がasterisk-modulesパッケージに組み込まれたらしい。

それなら、そのまま動くはずだけど

[options]

verbose = 3

[/etc/asterisk.confから抜粋より引用]

としてログを確認すると

2022-04-03 02:48:30] ERROR[1444808] app_voicemail_odbc.c: Failure registering applications, functions or tests

[2022-04-03 02:48:31] ERROR[1444808] loader.c: app_voicemail declined to load.

[2022-04-03 02:48:31] ERROR[1444808] loader.c: app_voicemail_odbc declined to load.

[/var/log/asterisk/messagesより引用]

ということで、app_voicemailのロードでエラー、Asteriskコンソールで'module show'すると

app_voicemail.so Comedian Mail (Voicemail System) 0 Not Running core

app_voicemail_imap.so Comedian Mail (Voicemail System) with IM 0 Running core

app_voicemail_odbc.so Comedian Mail (Voicemail System) with OD 0 Not Running core

[module showの出力から抜粋より引用]

ということで、今までは入れていなかったasterisk-voicemail-imapや-odbcパッケージに入っていたapp_voicemail_imapが先にロードされてapp_voicemailが走っていない。

そこで、moudle.confにnoloadを書いたらAsteriskの留守電が動くようになった。

noload => app_voicemail_imap

noload => app_voicemail_odbc

[/etc/asterisk/modules.confより引用]

■ Debian Bookworm (testing 12)にphp8.1が入ってきたので、php7.4を消してphp8.1に統一したら、Debianパッケージでインストールしたものは動くけど、自分でインストールしたものは、あちこち動かない。

scuttleは、php8での変更点、コンストラクタの名称変更(クラス名ではなく__construct()になった)や、未定義変数のアクセスでエラーになることにより、動かなかった。もうgithub上では10年以上メンテナンスされていないので自分でバッチした。

pukiwiki 1.5.3は最新版だけどphp8には未対応。1.5.4で対応予定で、まだリリースされていないので、php7.4-fpmパッケージをインストールしなおして、

<IfModule !mod_php7.c>

<IfModule proxy_fcgi_module>

<FilesMatch ".+\.ph(ar|p|tml)$">

SetHandler "proxy:unix:/run/php/php7.4-fpm.sock|fcgi://localhost"

</FilesMatch>

</IfModule>

</IfModule>

[.htaccessより引用より引用]

で、pukiwikiだけphp7.4を使わせて対応。

■ 1月20日の日記で壊れたSMR瓦書きのHDD Seagate Barracuda ST8000DM004を、CMRだけど安いとニュースにあったWD80EAZZにリプレイス。

2021年1月16日の日記に書いたように、四日間かかったSMRとは違い、6時間程度で終わりそう。

後、外した壊れたHDD Seagateの保証のページで調べたら、保証期間中のようなので、郵送して交換してもらうことにした。

■ ついにHDD故障

1月3日の日記に書いていたBADセクターを潰しながら使っていたSMR瓦書きのHDD Seagate Barracuda ST8000DM004だけど、昨日8セクターをhddparamでwirteして、しばし動いていたようだけど、ついに故障

SMARTを見ると夜の10時頃に止まってる

ZFSも当然フェイルしてる

■ 先日の日記で、性能が良くなったように見ていたSMR瓦書きのHDD Seagate Barracuda ST8000DM004だけど、一年も立たないうちに、

This message was generated by the smartd daemon running on:
  host name:  server
  DNS domain: on-o.com
The following warning/error was logged by the smartd daemon:
Device: /dev/sdc [SAT], 32 Offline uncorrectable sectors (changed +8)

や

ZFS has finished a scrub:
  eid: 19
class: scrub_finish
 host: server
 time: 2021-12-27 08:43:51+0900
 pool: tank
state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
   attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
   using 'zpool clear' or replace the device with 'zpool replace'.
  see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-9P
 scan: scrub repaired 308K in 08:06:18 with 0 errors on Mon Dec 27 08:43:51 2021
config:
   NAME        STATE     READ WRITE CKSUM
   tank        ONLINE       0     0     0
     mirror-0  ONLINE       0     0     0
       sdc1    ONLINE       0     0     9
       sdb1    ONLINE       0     0     0
   cache
     sda3      ONLINE       0     0     0
errors: No known data errors

と、smartctlやzfsからエラー通知が来るようになってしまった。

そこで、smartctl -t long /dev/sdc してみると、

# smartctl -l xselftest /dev/sdc
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.0-2-amd64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART Extended Self-test Log Version: 1 (1 sectors)
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       60%      8459         7482677584
# 2  Extended offline    Interrupted (host reset)      00%      8442         -
# 3  Short offline       Completed without error       00%      8427         -

ってなったので、まずはread errorってことで、代替セクターになることを期待してセクター書き込み

# hdparm --write-sector 7482677584  --yes-i-know-what-i-am-doing /dev/sdc

全部で32セクターあるらしいので、何回か繰り返し、最後にzfs scubして様子を見ることにした。

■ 新たにGoogleって見ると、セクター単位ではなくパティーション全部にddとか、ファイル上書きとかをみんなやっているね

上のやり方でひとつづセクターを上書きしていくの面倒くさいけど、パティーション全部とかになるとzfsの再構築に4日とか掛かるので、1セクターづつ書いていく。

■ ちなみに

# smartctrl -x /dev/sdc
-中略-
Pending Defects log (GP Log 0x0c)
Index                LBA    Hours
   0         7482677593     8556
   1         7482677594     8556
   2         7482677595     8556
   3         7482677596     8556
   4         7482677597     8556
   5         7482677598     8556
   6         7482677599     8556
   7         7482677601     8556
   8         7482677602     8556
   9         7482677603     8556
  10         7482677604     8556
  11         7482677605     8556
  12         7482677606     8556
  13         7482677607     8556

と、Pending Sectorの一覧が取れる。

■ 1月16日の日記で書いているように、おうちの8TBのZFSミラーの片側は、SMR瓦書きのHDDで遅かった。

数日前に、ZFS 2.1のDKMSパッケージが出たので、upgradeしてみると・・・

あら不思議、upgradeした後、いつも遅かったSMR HDD(オレンジ)が、CMR HDD(青)はおろか、SSD(緑)より早くなっている!?

今まで、80GBほどSSDにZFSのL2ARC cacheを取っていたのだけど、「効果ないなぁ」と思っていたのだけど、多分それがSMR HDDに優先的に効くようになったのではないかと推測。

単にバグで、「ミラーなのに書いていない」とかだとイヤだけど。

■ 久しぶりに日記を書こうと思って、開こうとしてらHTTP 500エラー。

「サーバエラーって何よ?」と調べるとsuexec.logに

[2021-12-18 23:51:41]: uid: (9000/takuya) gid: (9000/takuya) cmd: index.rb
[2021-12-18 23:51:41]: failed to setgid/initgroups (9000: index.rb): Operation not permitted

とか出まくっている。よく調べると前回日記を更新した11月2日の4日後の11月6日から。

発生開始の原因は不明。他のMediawikiやpukiwikiなどは正常に動いてる。

ログを見るとaudit.logに

type=AVC msg=audit(1639753525.733:232873): apparmor="DENIED" operation="capable" profile="apache2//DEFAULT_URI" pid=1140731 comm="suexec" capability=6  capname="setgid"

なんてあり、apparmerでsuexecのsetgidが禁止されてしまっている模様。

suexecやapache2の該当リクエストをcomplainモードにしようと/etc/apparmer.d/localや、同じく/apache.d/あたりに追記してみても状況変わらず500エラー。

切羽詰まって、すべてのURIでsetgid許す駄目な設定と分かりつつ

^DEFAULT_URI flags=(attach_disconnected) {

include

include

capability setgid,

/ rw,

/** mrwlkix,

}

[/etc/apparmor.d/usr.sbin.apache2より引用]

と書くと、update.rbだけうまく行く。 (後で見てみると、この途中で、index.rbのgroupをwww-dataに変えたミスでindex.rbが動かなかったのだけど・・・)

なんか、aa-statusで、妙にたくさん登録されているのに気が付き、結局、

# aa-teardown
# systemctrl reload apparomer

として、aa-tearmdownで、きれいにして設定ファイルをreloadしたら、問題なく動いた・・・(なんてこった)

参考にした資料: AppArmor - ArchWiki

■ GitLab 14.3から一ヶ月経って、14.4が出たのでupgradeしようとしたら14.3のときと同じくデータベースマイグレーションでエラー

gitlab-ce_1    | Recipe: gitlab::database_migrations
gitlab-ce_1    |   * ruby_block[check remote PG version] action nothing (skipped due to action :nothing)
gitlab-ce_1    |   * rails_migration[gitlab-rails] action run
gitlab-ce_1    |     * bash[migrate gitlab-rails database] action run
gitlab-ce_1    |       [execute] rake aborted!
gitlab-ce_1    |                 StandardError: An error has occurred, all later migrations canceled:
gitlab-ce_1    |
gitlab-ce_1    |                 PG::InvalidObjectDefinition: ERROR:  functions in index predicate must be marked IMMUTABLE
gitlab-ce_1    |                 /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database/migration_helpers.rb:155:in `block in add_concurrent_index'
gitlab-ce_1    |                 /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database/migration_helpers.rb:359:in `disable_statement_timeout'
gitlab-ce_1    |                 /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database/migration_helpers.rb:154:in `add_concurrent_index'
gitlab-ce_1    |                 /opt/gitlab/embedded/service/gitlab-rails/db/post_migrate/20211004110500_add_temporary_index_to_issue_metrics.rb:9:in `up'
gitlab-ce_1    |                 /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database/migrations/lock_retry_mixin.rb:31:in `ddl_transaction'
gitlab-ce_1    |                 /opt/gitlab/embedded/service/gitlab-rails/lib/tasks/gitlab/db.rake:61:in `block (3 levels) in '
gitlab-ce_1    |                 /opt/gitlab/embedded/bin/bundle:23:in `load'
gitlab-ce_1    |                 /opt/gitlab/embedded/bin/bundle:23:in `
'

10月3日の日記での14.3での直し方が良くなかったのかと焦ったけど、違うエラー。

14.4が出た直後には無かったけど、14.4.1でもうまくいかないので、今日調べたら

CREATE INDEX CONCURRENTLY index_issue_metrics_first_mentioned_in_commit ON issue_metrics

USING btree (issue_id)

WHERE EXTRACT(YEAR FROM first_mentioned_in_commit_at at time zone 'UTC') > 2019;

[ERROR: functions in index predicate must be marked IMMUTABLE while running 14.4 PostgreSQL migrations (#343724) · Issues · GitLab.org / GitLab · GitLabより引用]

言うのを見つけて、14.3で、gitlab-psqlを立ち上げて、このSQLで、index_issue_metrics_first_mentioned_in_commitを作ったら無事にGitLab 14.4.1が立ち上がった。

よかった。