おのたく日記
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時頃に止まってる
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-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;
言うのを見つけて、14.3で、gitlab-psqlを立ち上げて、このSQLで、index_issue_metrics_first_mentioned_in_commitを作ったら無事にGitLab 14.4.1が立ち上がった。
よかった。
|