わんこ日記 YouTubeも始めました→

■ Debianパッケージのupgradeの後にCPU利用率が高く100%近い。

よく調べてみると

Jul  8 07:03:59 mirara squid[1533]: WARNING: redirector #Hlpr187879 exited
Jul  8 07:03:59 mirara squid[1533]: Too few redirector processes are running (need 1/5)
Jul  8 07:03:59 mirara squid[1533]: Starting new helpers
Jul  8 07:03:59 mirara squid[1533]: helperOpenServers: Starting 1/5 'squidGuard' processes
Jul  8 07:03:59 mirara squid[9206]: ipcCreate: /usr/bin/squidGuard: (13) Permission denied

と、squidの中で危険なサイトの中継をするSquidGuardが起動できていない。

url_rewrite_program /usr/bin/squidGuard -c /etc/squidguard/squidGuard.conf

と、/etc/squid/squid.confで設定しているのだけど…

なかなか思いあたらなかったが、squidバッケージのインストール時にapparmorの設定ファイルが入れ替えられた事を思い出し、新旧ファイルを比較しているがどちらもSquidGuardの設定はなく???だったが、

# aa-genprof /usr/sbin/squid
# aa-logprof

で、ログからapparmor設定に追加を入れたら、動くようになった。

このときに、バックアップ取り忘れて/etc/apparmor.d/usr.sbin.namedとusr.sbin.squidが書き換えられてオリジナルの設定ファイルが無くなってしまった。

バッケージの設定ファイルは、普通にreinstallするとユーザ設定が優先されて出てこないので、

# aptitude reinstall -o Dpkg::Options::="--force-confask" squid

として、設定ファイルの変更について聞いてくるようにして、「N」と答えて、.dpkg-distが残るようにする。

■ [Debian] で、ゲームコントローラーGamesir T1sを使う

ミニドローンのTelloのコントール用に買ったゲームコントローラーのGamesir T1sだけど、Telloが何故か充電できなくなってから使わなくなってしまっていたのだけど、mameをやってみたくなり、使ってみることにした。

Windows 10では、USBケーブルでつないで、Gamesir T1sを「home」+「X」で起動すると、自動的にドライバーが入って、Windows 10の設定では、なぜかマウスと並んでBloutooth一覧に出てくるけど、Joystickとして認識されて、普通にmameからも使えた。

Debianでは、 「ゲームパッド - ArchWiki」を参考にして、「mame」「xdoxdrv」パッケージを入れて、Windows 10と同様に、USBケーブルでつないで、Gamesir T1sを「home」+「X」で起動すると

usb 1-1.2.1: new full-speed USB device number 80 using xhci_hcd
usb 1-1.2.1: New USB device found, idVendor=045e, idProduct=028e, bcdDevice= 1.10
usb 1-1.2.1: New USB device strings: Mfr=6, Product=7, SerialNumber=8
usb 1-1.2.1: Product: Controller
usb 1-1.2.1: Manufacturer: xiaoji
usb 1-1.2.1: SerialNumber: 0152793
input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.2/1-1.2.1/1-1.2.1:1.0/input/input154
usbcore: registered new interface driver xpad

と、XBoxのコントローラーとしてエミュレートされて認識されて、mameでも普通につかえた。

JoystickとかゲームコントローラーもDebianで簡単に認識される時代なんだなぁ

■ GitLabは、OmnibusパッケージのDocker imageにしてから、upgradeに失敗することは無かったのだけど、12.4に上げたら

itlab-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  |               Multiple indexes found on ci_trigger_requests columns [:trigger_id]. Specify an index name from ci_trigger_requests_trigger_id_idx, fk_rails_b8ec8b7245, index_ci_trigger_requests_on_trigger_id
gitlab-ce_1  |               /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database/migration_helpers.rb:121:in `block in remove_concurrent_index'

で再起動を繰り返していた。

どうも「12.2.5 -> 12.3.1 Database migration failed: Multiple indexes found (#33084) · Issues · GitLab.org / GitLabの現象に近そうなので、インデックスを削除したらうまく行った。

$ docker-compose exec gitlab-ce bash
oot@gitlab-ce:/# gitlab-psql 
psql (10.9)
Type "help" for help.
gitlabhq_production=# /d ci_trigger_requests
                                      Table "public.ci_trigger_requests"
  Column   |           Type           | Collation | Nullable |                     Default                     
------------+--------------------------+-----------+----------+-------------------------------------------------
id         | integer                  |           | not null | nextval('ci_trigger_requests_id_seq'::regclass)
trigger_id | integer                  |           | not null | 
variables  | text                     |           |          | 
created_at | timestamp with time zone |           |          | 
updated_at | timestamp with time zone |           |          | 
commit_id  | integer                  |           |          | 
Indexes:
   "ci_trigger_requests_pkey" PRIMARY KEY, btree (id)
   "ci_trigger_requests_trigger_id_idx" btree (trigger_id)
   "fk_rails_b8ec8b7245" btree (trigger_id)
   "index_ci_trigger_requests_on_commit_id" btree (commit_id)
   "index_ci_trigger_requests_on_trigger_id" btree (trigger_id)
   "index_ci_trigger_requests_on_trigger_id_and_id" btree (trigger_id, id DESC)
Foreign-key constraints:
   "fk_rails_b8ec8b7245" FOREIGN KEY (trigger_id) REFERENCES ci_triggers(id) ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED
gitlabhq_production=# drop index ci_trigger_requests_trigger_id_idx;
DROP INDEX
gitlabhq_production=# drop index index_ci_trigger_requests_on_trigger_id;
DROP INDEX

MySQLから無理くりPostgreSQLにデータをコンバートした弊害か?

■ TT-RSSのプラグインには1280pxという添付の画像を大きくするものはあるけど、JBpressとか東洋経済オンラインのRSSに付いてくる画像は大きすぎ、defaultではmax-width: 98%だけど、設定のカスタムRSSで

div.content > div.content-inner img {
   max-width: 50%;
}
div.content > div.intermediate img {
   max-width: 50%;
}

を追加して、画像を小さくした。

■ Debian Packetのupgradeに伴い tt-rssを17.4から18.12にupgradeしたら、phpmailerは使わなくなり、Debian Pakcege依存での問題はなくなったのだけど、Webアクセスに行くと500エラーとなる。

というエラー。

「1406 Data too long for column 'context'」ということでどうやらLogを記録するために error_log に書き込む時にログメッセージであるcontextが長すぎたようなのでsubstr()で、MySQL text型の最長の65536文字に制限するバッチを/usr/share/tt-rss/www/classes/logger/sql.phpに当てた

■ Apache2でHTTP/2が止まっていた

一度有効にしたはずなApache2のHTTP/2なのだけど、

という警告が出て、mpm_preforkでは使えなくなっていた。

mpmの切替は以前(って10年近く前?)に挑戦して余り印象が良くないのだけど、重要なサービスはDockerコンテナに移行していて、PHP CGIが変わる以外は影響が少なさそうなのでmpm_eventに移行してHTTP/2を有効にする。

mod_php7.3は、mpm_preforkが前提なのでPHP CGIをfcgidとphp7.3-fpmに変える。

途中、proxy_fcgiをenableにしていず、

というエラーが出て嵌ったけれど、php7.3-fpm.confでproxy_fcgiが無いと有効にならないことに気がついて見つけた。

■ Apache2でHTTP/2が止まっていた

一度有効にしたはずなApache2のHTTP/2なのだけど、

という警告が出て、mpm_preforkでは使えなくなっていた。

mpmの切替は以前(って10年近く前?)に挑戦して余り印象が良くないのだけど、重要なサービスはDockerコンテナに移行していて、PHP CGIが変わる以外は影響が少なさそうなのでmpm_eventに移行してHTTP/2を有効にする。

mod_php7.3は、mpm_preforkが前提なのでPHP CGIをfcgidとphp7.3-fpmに変える。

途中、proxy_fcgiをenableにしていず、

というエラーが出て嵌ったけれど、php7.3-fpm.confでproxy_fcgiが無いと有効にならないことに気がついて見つけた。

■ 長らく1TB HDDだったおうちサーバのDebianシステムの入っているルートディスクをSSD 500GBに換装した。

HDD: WD Caviar Green 2 TB SATAハードドライブ ( WD20EARS )だったけ?

SSD: WDS500G2B0A 500GB SATA III 6Gb s 2.5” 7mm

■ [ZFS][HDD] 結果

昨日のZFSミラーのリビルドは無事に終わって、最大値は1023IOPS Throughput 123.14Mbype/secだった。

■ [ZFS][HDD] ディスク交換 3TB→8TB

先日の日記のようにHDDが壊れたようで8セクターが読めなくなったのでHDD交換をする。

従来は、3TBと4TBのzfs mirrorで、生き残った4TBを最大容量使っていないので、ミラーの生きている方を最大容量使え切るようにpartedで1MiB単位でzfs poolを最大化してからHDDを物理的に入れ替えた。

マルチユーザでブートしてから、gpartedでパテーションテーブル作ったりパティーションを未フォーマットで切った。

このへんは、昔と違ってサーバをマルチユーザで完全に起動した状態になってからGUIベースでできるので助かる。

で、zfsの玉のリプレース。リプレースするとミラーのリビルドも自動的に走る。

# zpool replace tank 2189429116797733421 ata-TOSHIBA_MD05ACA800_ZZRCK0MSZZZZ-part1
# 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 Tue Nov 13 23:50:17 2018
	19.2G scanned out of 1.79T at 16.1M/s, 32h10m to go
	19.2G resilvered, 1.04% done
config:
	NAME                                             STATE     READ WRITE CKSUM
	tank                                             DEGRADED     0     0     0
	  mirror-0                                       DEGRADED     0     0     0
	    ata-ST4000DM000-1F2168_Z307V2E2-part1        ONLINE       0     0     0
	    replacing-1                                  DEGRADED     0     0     0
	      2189429116797733421                        UNAVAIL      0     0     0  was /dev/disk/by-id/ata-TOSHIBA_DT01ACA300_66SWYX9FS-part1
	      ata-TOSHIBA_MD05ACA800_ZZRCK0MSZZZZ-part1  ONLINE       0     0     0  (resilvering)
errors: No known data errors

ってわけで、ミラーのリビルドには一日かかる模様。

■ [ZFS][HDD] HDDやはり壊れた

ZFSからエラーのメールを頂いていたのを、昨日の日記で書いたけど、今日はSMARTからもメールが来た。

# smartctl -l error /dev/sdb
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.18.0-2-amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF READ SMART DATA SECTION ===
SMART Error Log Version: 1
ATA Error Count: 2
       CR = Command Register [HEX]
       FR = Features Register [HEX]
       SC = Sector Count Register [HEX]
       SN = Sector Number Register [HEX]
       CL = Cylinder Low Register [HEX]
       CH = Cylinder High Register [HEX]
       DH = Device/Head Register [HEX]
       DC = Device Command Register [HEX]
       ER = Error register [HEX]
       ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 2 occurred at disk power-on lifetime: 42730 hours (1780 days + 10 hours)
 When the command that caused the error occurred, the device was active or idle.
 After command completion occurred, registers were:
 ER ST SC SN CL CH DH
 -- -- -- -- -- -- --
 40 51 d8 a0 a2 d4 0f  Error: UNC 216 sectors at LBA = 0x0fd4a2a0 = 265593504
 Commands leading to the command that caused the error were:
 CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
 -- -- -- -- -- -- -- --  ----------------  --------------------
 25 00 00 78 a2 d4 e0 08   3d+14:16:29.677  READ DMA EXT
 35 00 58 50 e7 79 e0 08   3d+14:16:29.677  WRITE DMA EXT
 b0 d0 01 00 4f c2 00 08   3d+14:16:29.489  SMART READ DATA
 35 00 90 e0 75 48 e0 08   3d+14:16:29.489  WRITE DMA EXT
 ef 10 02 00 00 00 a0 08   3d+14:16:29.489  SET FEATURES [Enable SATA feature]

Error 1 occurred at disk power-on lifetime: 42722 hours (1780 days + 2 hours)
 When the command that caused the error occurred, the device was active or idle.
 After command completion occurred, registers were:
 ER ST SC SN CL CH DH
 -- -- -- -- -- -- --
 84 51 ba 46 83 61 08  Error: ICRC, ABRT at LBA = 0x08618346 = 140608326
 Commands leading to the command that caused the error were:
 CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
 -- -- -- -- -- -- -- --  ----------------  --------------------
 61 00 80 00 83 61 40 08   3d+06:13:43.240  WRITE FPDMA QUEUED
 61 00 50 00 82 61 40 08   3d+06:13:43.240  WRITE FPDMA QUEUED
 61 00 78 00 81 61 40 08   3d+06:13:43.239  WRITE FPDMA QUEUED
 61 a0 d8 10 d8 35 40 08   3d+06:13:43.239  WRITE FPDMA QUEUED
 61 80 48 50 73 10 40 08   3d+06:13:43.239  WRITE FPDMA QUEUED

というとこなので、2013年12月の日記から、5年近く使ったHDDも交換だね。3TB→8TBにする。