第二種電気工事士の結果通知が届いた。
さっそく免状を申請しよう。
ホームページで申請手続きを調べたところ、電子申請できるらしい。
支払いもオンラインでできる。
いいね!これで県の証紙を買いに行かなくて済む。
面倒だったんだよね、買える時と場所が限られているから。
でも残念なことに、納付と申請が別システムになっていて、
申請時に納付番号を手入力しなければならない。
うまくやれば不正も可能かもしれない。
ちゃんと処理されるのか不安だな。
第二種電気工事士の結果通知が届いた。
さっそく免状を申請しよう。
ホームページで申請手続きを調べたところ、電子申請できるらしい。
支払いもオンラインでできる。
いいね!これで県の証紙を買いに行かなくて済む。
面倒だったんだよね、買える時と場所が限られているから。
でも残念なことに、納付と申請が別システムになっていて、
申請時に納付番号を手入力しなければならない。
うまくやれば不正も可能かもしれない。
ちゃんと処理されるのか不安だな。
仕事に少し余裕ができたので、不具合を直そう。
まずは、rocket.chatの新規チームを作れない問題だ。
試してみると確かに作れない。Bad Requestというエラーが出る。
何かヒントないかな?
Error: Bad Request when creating Channel/Team/Direct Messages/Discussions #25080
にEnabling the "Enable the App Framework" option solves the problem:
という書き込みがあったので試してみたけれど、効果はなかった。
他にBad Requestで検索しても情報は見つからなかった。
logを見てみよう。
apparmorにたくさん拒否されている。
chatsv kernel: [2112234.227098] audit: type=1400 audit(1675313623.000:6336613): apparmor="DENIED" operation="open" profile="snap.rocketchat-server.rocketchat-mongo" name="/proc/vmstat" pid=956 comm="ftdc" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
chatsv kernel: [2112234.227098] audit: type=1400 audit(1675313623.000:6336613): apparmor="DENIED" operation="open" profile="snap.rocketchat-server.rocketchat-mongo" name="/proc/956/net/netstat" pid=956 comm="ftdc" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
chatsv kernel: [2112234.227098] audit: type=1400 audit(1675313623.000:6336613): apparmor="DENIED" operation="open" profile="snap.rocketchat-server.rocketchat-mongo" name="/proc/956/net/snmp" pid=956 comm="ftdc" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
これについて検索してみたら、次の記事を見つけた
AppArmor errors after Snap Update #14562
関係があるのかどうかわからないけれど、このとおりやってみよう。
vi /var/lib/snapd/apparmor/profiles/snap.rocketchat-server.rocketchat-mongo
次の3行を追加した。
@{PROC}/@{pid}/net/snmp r,
@{PROC}/@{pid}/net/netstat r,
@{PROC}/vmstat r,
そして、プロファイルをリロードする。
apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.rocketchat-server.rocketchat-mongo
直ったかな?
ログにエラーは出なくなったけれど、チームの作成は相変わらずBad Requestだ。
関係なかったみたい。
もうネットで検索してもヒントが見つからないので、設定を触ってみよう。
まずはチーム作成権限のオン/オフを試そう。
設定がオンにしてあっても実際にはオフになっているということたまにあるもんね。
管理→権限→add-team-channel
パブリックChannelの作成
userのチェックを外し、再度チェックした。
・・直った!
よし、次だ。
最近fessのクローラーが止まっている。
こちらは検索キーワードが思いつかないので、まずログを見よう。
index [fess_config.thumbnail_queue], type [_doc], id [3VO4GoQBQij4i9lwC9CT], message [OpenSearchException[Opensearch exception [type=cluster_block_exception, reason=index [fess_config.thumbnail_queue] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceede flood-stage watermark, index has read-only-allow-delete block];]]]
ディスク容量が不足しているらしい。
dfで確認すると90%使用中。90%でエラーになるという仕様どおりだ。
[root@fess ~]# df -h
ファイルシス サイズ 使用 残り 使用% マウント位置
devtmpfs 7.7G 0 7.7G 0% /dev
tmpfs 7.8G 0 7.8G 0% /dev/shm
tmpfs 7.8G 17M 7.7G 1% /run
tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup
/dev/mapper/ml-root 168G 144G 17G 90% /
/dev/sda2 976M 217M 693M 24% /boot
/dev/mapper/ml-home 4.7G 33M 4.4G 1% /home
/dev/sda1 599M 5.8M 594M 1% /boot/efi
tmpfs 1.6G 0 1.6G 0% /run/user/0
HyperVのコンソールから仮想HDDを180GB→200GBに拡張した。
ディスクの状態を確認。
# fdisk -l
GPT PMBR のサイズが合致していません (377487359 != 419430399) が、w (書き込み) コマンドで修正されます。
The backup GPT table is not on the end of the device. This problem will be corrected by write.
ディスク /dev/sda: 200 GiB, 214748364800 バイト, 419430400 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O サイズ (最小 / 推奨): 4096 バイト / 4096 バイト
ディスクラベルのタイプ: gpt
ディスク識別子: 050EF96D-9BFE-47EC-AE1D-23D94AA2A6B9
デバイス 開始位置 終了位置 セクタ サイズ タイプ
/dev/sda1 2048 1230847 1228800 600M EFI システム
/dev/sda2 1230848 3327999 2097152 1G Linux ファイルシステム
/dev/sda3 3328000 266336255 263008256 125.4G Linux LVM
/dev/sda4 266336256 377487326 111151071 53G Linux LVM
新しいパーティションを作成。
# fdisk /dev/sda
コマンド (m でヘルプ): n
パーティション番号 (5-128, 既定値 5): 5
最初のセクタ (377487327-419430366, 既定値 377487360):
最終セクタ, +セクタ番号 または +サイズ{K,M,G,T,P} (377487360-419430366, 既定値 419430366):
新しいパーティション 5 をタイプ Linux filesystem、サイズ 20 GiB で作成しました。
新しいパーティションのタイプをLinux LVMに変更する。
コマンド (m でヘルプ): t
パーティション番号 (1-5, 既定値 5): 5
パーティションのタイプ (L で利用可能なタイプを一覧表示します): 31
パーティションのタイプを 'Linux filesystem' から 'Linux LVM' に変更しました。
コマンド (m でヘルプ): w
パーティション情報が変更されました。
ディスクを同期しています。
ボリューム情報を確認する。
[root@fess ~]# lvdisplay
--- Logical volume ---
LV Path /dev/ml/root
LV Name root
VG Name ml
LV UUID MnwWie-8W1J-ISem-0r2Z-TeHd-9ZqQ-TCq3F6
LV Write Access read/write
LV Creation host, time localhost, 2022-05-29 07:19:54 +0900
LV Status available
# open 1
LV Size <171.10 GiB
Current LE 43801
Segments 3
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0
ボリュームグループの名前はmlだった。
ボリュームグループにさっき作ったパーティションを追加する。
[root@fess ~]# pvcreate /dev/sda5
Physical volume "/dev/sda5" successfully created.
[root@fess ~]# vgextend ml /dev/sda5
Volume group "ml" successfully extended
rootの論理ボリュームを拡張する。
[root@fess ~]# lvextend -l +100%FREE /dev/ml/root
Size of logical volume ml/root changed from <171.10 GiB (43801 extents) to 191.09 GiB (48920 extents).
Logical volume ml/root successfully resized.
ファイルシステムのサイズを変更する。
[root@fess ~]# resize2fs /dev/ml/root
resize2fs 1.45.6 (20-Mar-2020)
Filesystem at /dev/ml/root is mounted on /; on-line resizing required
old_desc_blocks = 22, new_desc_blocks = 24
The filesystem on /dev/ml/root is now 50094080 (4k) blocks long.
状態を確認。
[root@fess ~]# df -h
ファイルシス サイズ 使用 残り 使用% マウント位置
/dev/mapper/ml-root 188G 144G 36G 81% /
使用率が81%になった。
これで起動できるだろう。