目次
つぶやき
技術系や雑感等は再編集して本文の記事にする事を前提としているので、こっちにLinkを張らないでください。
NextcloudでFileが削除できなくなった
いつの間にか2年動かしているNextCloudだが、なんか一部のファイルが削除できなくなるなどの症状が出てきた。 ちょっとググると、どうやら file が lock されているらしい。というわけで、取り急ぎの対処方法
作業手順だけ書くので、中身は各自で調べてください。
www$ sudo -u www-data php occ maintenance:mode --on www$ psql -U user nextcloud-db-name xxxx> DELETE FROM oc_file_locks; xxxx> \q www$ sudo -u www-data php occ maintenance:mode --off
要するに、oc_file_locks tableに登録されているレコードがlockされているファイルを示しているので、これを消さないと操作ができないということらしい。
[FreeBSD] ZFS/XCP-ng Disk増加
XCP-ng上で動かしているFreeBSDのVMにおいて、zrootの容量を増やす方法
なお、FreeBSD 11.2-RELEASEとFreeBSD 13.0-RELEASE-p4で動作確認した。
- FreeBSD VM(以下VM)をshutdownする
- しなくてもいいのかもしれないが、block deviceを扱うので、止めておいた方が無難だろう
- XCP-ng側で、Storageの容量を増やす
- 今回は20G追加して40Gにした
- VMを起動する
- dmesgなどで、xvbdの容量を確認し容量が増えていることを確認する
- 今回の対象Diskはada0に割り当てられている
- 以下の作業を実行
# dmesg (snip) xbd0: 40960MB <Virtual Block Device> at device/vbd/768 on xenbusb_front0 xbd0: attaching as ada0 (snip) GEOM: ada0: the secondary GPT header is not in the last LBA. (snip) # zpool set autoexpand=on zroot # gpart show => 40 41942960 ada0 GPT (40G) [CORRUPT] 40 1024 1 freebsd-boot (512K) 1064 984 - free - (492K) 2048 4194304 2 freebsd-swap (2.0G) 4196352 37744640 3 freebsd-zfs (18G) 41940992 2008 - free - (1.0M) # gpart recover ada0 ada0 recovered # gpart show => 40 83886000 ada0 GPT (40G) 40 1024 1 freebsd-boot (512K) 1064 984 - free - (492K) 2048 4194304 2 freebsd-swap (2.0G) 4196352 37744640 3 freebsd-zfs (18G) 41940992 41945048 - free - (20G) # gpart resize -i 3 ada0 ada0p3 resized # gpart show ada0 => 40 83886000 ada0 GPT (40G) 40 1024 1 freebsd-boot (512K) 1064 984 - free - (492K) 2048 4194304 2 freebsd-swap (2.0G) 4196352 79689688 3 freebsd-zfs (38G) # zpool list NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT zroot 37.5G 708M 36.8G - - 0% 1% 1.00x ONLINE - # zpool status pool: zroot state: ONLINE config: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 ada0p3 ONLINE 0 0 0 errors: No known data errors # zpool set autoexpand=off zroot # zpool get autoexpand zroot NAME PROPERTY VALUE SOURCE zroot autoexpand off default #
これで終わり。
WireGuard for FreeBSD の(おそらく)BUG
大したBUGではないけど、見つけてしまったのだから仕方がない。
minira# diff -c wg-quick /usr/local/bin/wg-quick
*** wg-quick Thu Aug 5 03:28:13 2021
--- /usr/local/bin/wg-quick Mon Jul 5 06:18:56 2021
***************
*** 97,103 ****
SaveConfig) read_bool SAVE_CONFIG "$value"; continue ;;
esac
fi
! WG_CONFIG+="$stripped"$'\n'
done < "$CONFIG_FILE"
shopt -u nocasematch
}
--- 97,103 ----
SaveConfig) read_bool SAVE_CONFIG "$value"; continue ;;
esac
fi
! WG_CONFIG+="$line"$'\n'
done < "$CONFIG_FILE"
shopt -u nocasematch
}
見ればわかるけど、本当に大した話じゃない…
# しかし、空行を削除してもいい気はするし、しなくてもいい気もするなぁ。単にuniq通すだけだからまぁ、どっちでもいいんだけど。
FreeBSDのMulti-Fibとpacket送出について(駄文)
FreeBSDのMulti-FIBとIPパケット送出について、なんとなく色々考えていたら、少し問題がありそうなことに気がついたので考えてみた。 なお、実際のcodeは見ていないので、もしかすると大勘違いをしている可能性があります。
そこそこ長いかもしれないので、興味のない人はスルーでお願いします。
FreeBSD EtherIP でトラブル(未解決)
FreeBSD 12-RELEASE を利用して以下の環境を構築したところうまくいかなかった。
以下は、症状を再現するための必要設定のみ記載している。
試験環境: FreeBSD rt12 12.2-RELEASE-p6 FreeBSD 12.2-RELEASE-p6 GENERIC amd64
基盤：VMware 5.5 及び、XCP-ng 8.2.0
Bridge0 -- gif0 -- em0 -- (network) -- em0 -- gif0 -- Bridge0 Node A FreeBSD 12 ->| |<- FreeBSD 12 Node B
なお、試験環境は、VMware上で構築している。また、自明だと思うが、kernel側でv4 forwarding/v6 forwardingを1にして、Routerモードにしてある
- NodeAで設定したのは以下の通り
ifconfig em0 10.0.0.1/24 ifconfig gif0 create ifconfig gif0 mtu 1500 # 記述ミス。追記 ifconfig gif0 tunnel inet 10.0.0.1 10.0.0.2 ifconfig gif0 inet 172.16.0.1/24 alias route add -net 172.16.1.0/24 -iface gif0 ifconfig bridge0 create ifconfig bridge0 mtu 1500 # 記述ミス。追記 ifconfig bridge0 addm gif0 -stp gif0
- NodeBで設定したのは以下の通り
ifconfig em0 10.0.0.2/24 ifconfig gif0 create ifconfig gif0 mtu 1500 # 記述ミス。追記 ifconfig gif0 tunnel inet 10.0.0.2 10.0.0.1 ifconfig gif0 inet 172.16.1.1/24 alias route add -net 172.16.0.0/24 -iface gif0 ifconfig bridge0 create ifconfig bridge0 mtu 1500 # 記述ミス。追記 ifconfig bridge0 addm gif0 -stp gif0
以上のように設定したところ、通信ができなかった。(NodeAでping 172.16.1.1を実行した)
tcpdumpでgif0の通信内容を見る(tcpdump -ni gif0) と、AF Unknown (18), length 46:が表示される。また、この時にtcpdump -ni em0を見ると、IP 10.0.0.1 > 10.0.0.2: ip-proto-97 86 のように、Packetは出て行っており、IPのProtocol番号97で通信しているようだが、pingは届かない。(parameter errorが出る)
この問題は、IP AddressをIPv4からIPv6に置き換えても変わらなかった
追記(記載忘れ。20210530)
- いくつかのWeb Pageに、sysctlでkernelパラメータをいじるという記事があるので、実行したが変化なし
sysctl net.link.bridge.ipfw=0 sysctl net.link.bridge.pfil_bridge=0 sysctl net.link.bridge.pfil_member=0
- bridge0 に物理I/Fを追加してみたが、これも効果なし
ifconfig bridge0 addm em1 -stf em1
問題を切り分けようと、bridge I/Fを削除すると、問題なくICMPが届くところを見ると、gifでの通信は正常にできていると考えられる。
とすると、FreeBSDのbridge deviceがEtherIP関連でものすごく変なことをしているとしか考えられない…
と思って、ifconfig bridge0 deletem gif0 をNodeA/NodeBの両方で実行すると、問題なく通信できるようになる。
よく見る（症状1）と、
- bridge0にgif0が所属していない時は、gif経由でいわゆるIPv4/IPv6パケットが流れた
- bridge0にgif0が所属している時(addmした時)は、protocol number 97(EtherIP/on em0)/(parameter error/on gif0)の通信のように見える (tcpdumpのBinaryを解析する根性はなかった)。
追記(20210530)
以前、佐藤先生から、中を解析するには、Protocol number=97を追いかけるしかない、というお話をいただいている。
問題は、同一のFreeBSD同士でのgif+bridgeを用いたEtherIP通信が、IPv4でもIPv6でも失敗するところ。なお、NECのIX2000シリーズのEtherIPと繋ごうとしてもつなげないので、流石にFreeBSD側のBUGと考えるしかないが、問題はそのBUGが bridge(if_bridge.c) にあるのか gif(if_gif.c)にあるのかわからない…
なお、いくつか試験するにあたって、
- gifのみにIP Address(172.16.0.1/172.16.1.1)を割り当てた場合
- bridgeのみにIP Address(172.16.0.1/172.16.0.2)を割り当てた場合 (BridgeはBridgeをDirectに繋いでいるので、同一Segmentである必要がある)
- lo9を作成してそこのみにIP Address(172.16.0.1/172.16.1.1)を割り当てた場合
の3パターンを試験したが、全て、上記の症状１が観測された。
FreeBSD 9系列では動いているという報告はあるのだが、それもどこまで信用すれば…(いまさらFreeBSD 9-RELEASEを作る気にならなかった) そして、FreeBSD 13で動くかわからないしなぁ。
なんで俺はこんなに罠にハマるんだろう… しかも、なんで6時間もDebugにはまったんだろう… さて、どうすれば解決できることやら…