↑日記で日々積み重ねた情報をトップの「わんこのページ」にまとめています。

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


2022-05-10(Tue) [tt-rss]既読にならない [長年日記] この日を編集

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より引用]


2022-04-17(Sun) [PHP][Pukiwiki] PHP7.4さようなら [長年日記] この日を編集

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

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

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

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

$ git clone git://git.osdn.jp/gitroot/pukiwiki/pukiwiki.git

としたところにファイルを上書きして、自分で修正していない部分は、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になった。


2022-04-03(Sun) [長年日記] この日を編集

[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より引用]


2022-01-27(Thu) [PHP] おうちさーば php8.1に上げる [長年日記] この日を編集

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を使わせて対応。


2022-01-21(Fri) というわけでHDDリプレイス [長年日記] この日を編集

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

# zpool replace tank 7497183223150294317 /dev/sdc1

# zpool status -v

pool: tank

state: DEGRADED

status: One or more devices is currently being resilvered. The pool will

continue to function, possibly in a degraded state.

action: Wait for the resilver to complete.

scan: resilver in progress since Fri Jan 21 15:59:19 2022

860G scanned at 278M/s, 364G issued at 118M/s, 2.79T total

364G resilvered, 12.75% done, 06:01:32 to go

config:

NAME STATE READ WRITE CKSUM

tank DEGRADED 0 0 0

mirror-0 DEGRADED 0 0 0

replacing-0 DEGRADED 0 0 0

7497183223150294317 UNAVAIL 0 0 0 was /dev/sdc1/old

sdc1 ONLINE 0 0 0 (resilvering)

sdb1 ONLINE 0 0 0

cache

sda3 ONLINE 0 0 0

errors: No known data errors

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

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


2022-01-20(Thu) [長年日記] この日を編集

ついにHDD故障

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

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

SMART

ZFSも当然フェイルしてる

# zpool status -v

pool: tank

state: DEGRADED

status: One or more devices are faulted in response to persistent errors.

Sufficient replicas exist for the pool to continue functioning in a

degraded state.

action: Replace the faulted device, or use 'zpool clear' to mark the device

repaired.

scan: scrub repaired 0B in 07:44:17 with 0 errors on Sun Jan 9 08:08:18 2022

config:

NAME STATE READ WRITE CKSUM

tank DEGRADED 0 0 0

mirror-0 DEGRADED 0 0 0

sdc1 FAULTED 3 385 0 too many errors

sdb1 ONLINE 0 0 0

cache

sda3 ONLINE 0 0 0

errors: No known data errors


2022-01-03(Mon) [長年日記] この日を編集

先日の日記で、性能が良くなったように見ていた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の一覧が取れる。


2021-12-20(Mon) ZFS 2.1でHDD SMR瓦書きの弱点消える? [長年日記] この日を編集

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

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

DISKレイテンシー

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

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

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


2021-12-18(Sat) 2021年11月6日より「おのたく日記」動いてなかった [長年日記] この日を編集

久しぶりに日記を書こうと思って、開こうとしてら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


2021-11-02(Tue) GitLab 14.4へのupgradeでエラー [長年日記] この日を編集

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が立ち上がった。

よかった。


Google Web検索 on-o.com内を検索