ソースの表示以前のリビジョンバックリンク全て展開する/折り畳む文書の先頭へ Share via Share via... Twitter LinkedIn Facebook Pinterest Telegram WhatsApp Yammer Reddit Teams最近の変更Send via e-Mail印刷パーマリンク × 動的ライブラリをリンクしたシェルをログインシェルにしてはいけない freebsd-updateなどでシステム更新の際、手順ミスでライブラリに不整合が生じることがある。Shared object “libxyzw.so.8” not found的なアレ。 これがログインシェルで起きると悲劇で、シェルの起動に失敗しシステムにログインできなくなってしまう。マシンに物理アクセス可能ならシングルユーザーモードなりで復旧可能だが、アクセス手段がsshとかしかなかったりすると詰むんですわ。お察しの通り、記事にしてるくらいだから実際に詰んだんですけどね。 実家サーバをfreebsd-updateが中途半端な状態で再起動したら、以下のような状態でsshログイン不可になってしまった。 $ ssh Decomo@192.168.0.1 Password for Decomo@: Last login: Sun Nov 6 13:06:52 2022 from 192.168.0.2 FreeBSD 13.1-RELEASE-p1 GENERIC Welcome to FreeBSD! Release Notes, Errata: https://www.FreeBSD.org/releases/ Security Advisories: https://www.FreeBSD.org/security/ FreeBSD Handbook: https://www.FreeBSD.org/handbook/ FreeBSD FAQ: https://www.FreeBSD.org/faq/ Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/ FreeBSD Forums: https://forums.FreeBSD.org/ Documents installed with the system are in the /usr/local/share/doc/freebsd/ directory, or can be installed later with: pkg install en-freebsd-doc For other languages, replace "en" with a language code like de or fr. Show the version of FreeBSD installed: freebsd-version ; uname -a Please include that output and any error messages when posting questions. Introduction to manual pages: man man FreeBSD directory layout: man hier To change this login announcement, see motd(5). ld-elf.so.1: Shared object "libncurses.so.8" not found, required by "fish" Connection to 192.168.0.1 closed. ログインシェルの変更さえできればリモートアクセスできそうなものの、ssh経由で実現する方法はついぞ見つけられなかった。実のところ作業自体は11月の実家帰省中に行っており、目の前にマシンも液晶モニタもあるのに、D-Sub→DVI-Iのケーブルがなく、手も足も出なかったという。この度、ケーブル持参でようやく復旧できたというわけ。 そもそも、リモートアクセス手段しかない状態でシステム更新すんなよって話だが…静的リンクなbashであるbash-staticがPortsに存在する理由を“わからせ”られた。 というわけで、動的リンクなシェルをログインシェルにしてはいけない。どうしても設定する場合は、/bin/shをログインシェルとするリモートアクセス可能な緊急回復用ユーザー1)を作っておくと良いだろう。 1) rootとtoorの関係が近いが、well-knownなユーザーをssh可にするのは流石に怖い FreeBSDのSambaのビルドでncurses not availableが出てた 家鯖のFreeBSDのnet/samba413をビルドしようとすると、configureでncursesが見つからんと言われてコケるようになっていた。 ncurses not available, cannot build regedit ncurses not available, but --with-regedit was specified ncursesってbaseに含まれてたような…なんでエラーになんの?と思いつつ、念のためdevel/ncursesを入れても効果なし。Sambaの依存パッケージじゃないし、そりゃそうだ。 portsのバグを疑いしばらく放置&再試行してみたものの、一向に直る気配がない。そもそもエラーでググってもそれらしい結果が出てこないので、自分の環境の問題なのだろう。 では、どうやってシステムのncursesを直すか? base.txzあたりでシステムを上書きすれば良さそうではあるものの、ncursesがどのtarballに含まれているのかが分からない。かといって、なんも考えずにtxz一式を展開した結果、設定ファイルなどがデフォルトに戻るのは避けたい。 そんな感じでモニョってたんだけど、たまたま目にしたFreeBSD-SA-00:68.ncursesに解決策があった。/usr/src/lib/libncursesでmake installするだけで良かったのだ。 # cd /usr/src/lib/libncurses # make && make install そしてSamba 4.13が無事ビルドできて一件落着。 # portmaster net/samba413 システムを飛ばしたときの復旧が不十分だったんだろうなぁ、たぶん。近いうちにbuildworldしとくか… ディスクがどのzpoolに所属していたか調べる 複数のHDDを抜き差ししてると、どのHDDがどのzpoolの構成員か分からなくなる事がある。ちゃんと管理しとけって話だが、そんな時はzdb -lでZFSのラベル情報を表示すればよい。 ProxmoxVE (ZFS on Linux)での実行なので、デバイス名はsdXになっている。 # zdb -l /dev/sdh1 ------------------------------------ LABEL 0 ------------------------------------ version: 5000 name: 'zdata' ★これ state: 0 txg: 23527188 pool_guid: 15920220212014191793 hostid: 1525007054 hostname: 'hostname.example.com' top_guid: 1118325231086088749 guid: 9773797371878116701 vdev_children: 1 vdev_tree: type: 'raidz' id: 0 guid: 1118325231086088749 nparity: 1 metaslab_array: 34 metaslab_shift: 37 ashift: 12 asize: 31989740601344 is_log: 0 create_txg: 4 children[0]: type: 'disk' id: 0 guid: 3334618698730764157 path: '/dev/ada5p1' phys_path: 'id1,enc@n3061686369656d31/type@0/slot@3/elmdesc@Slot_02/p1' whole_disk: 1 DTL: 291 create_txg: 4 children[1]: type: 'disk' id: 1 guid: 4503436449772901953 path: '/dev/ada3p1' phys_path: 'id1,enc@n3061686369656d31/type@0/slot@1/elmdesc@Slot_00/p1' whole_disk: 1 DTL: 290 create_txg: 4 children[2]: type: 'disk' id: 2 guid: 9773797371878116701 path: '/dev/ada2p1' phys_path: 'id1,enc@n3061686369656d30/type@0/slot@3/elmdesc@Slot_02/p1' whole_disk: 1 DTL: 289 create_txg: 4 children[3]: type: 'disk' id: 3 guid: 1033141966906037929 path: '/dev/ada4p1' phys_path: 'id1,enc@n3061686369656d31/type@0/slot@2/elmdesc@Slot_01/p1' whole_disk: 1 DTL: 288 create_txg: 4 features_for_read: com.delphix:hole_birth com.delphix:embedded_data labels = 0 1 2 3 注目すべきはnameの項目で、プール名がそのまんま入っている。さらに他の項目からプールの詳細がわかる。 name: プール名 hostname プールを作成したホスト名 vdev_tree: type プールの構成方法 vdev_tree: children vdevを構成するストレージの数 vdev_tree: children: path プール構成ストレージとして最後に認識された時のデバイスパス これらを読み解くと、/dev/sdh1は「FreeBSDマシン2)hostname.example.comで作られた4台構成のRAID-Zプールzdata」の構成デバイスだった、ということが推測できる。 2) pathのadaXから推定 MySQL上でWordPressのネットワーク管理者を変更 WordPressマルチサイトのネットワーク管理者のパスワードは元より、アカウント名すらも忘れ途方に暮れたので、データベースを直接弄ってどうにかしたメモ。 WordPress 4.8.15で確認。試行錯誤の結果なので間違ってたらごめんちゃい。 テーブル名やmeta_key名にはwp-config.phpで指定したプレフィックスが付いてたりするので、いい塩梅で読み替えてください。 wp_usermetaテーブル wp_usermetaテーブルで、ネットワーク管理者にしたいユーザーの情報を書き換える。全ユーザーのメタデータが直列に格納されているので、nicknameあたりを目印にする。 meta_key meta_value 備考 wp_capabilities a:1:{s:13:”administrator”;s:1:”1″;} wp_user_level 10 wp_user-settings hidetb=1&editor=html&libraryContent=browse&mfold=o これは書き換えなくても大丈夫かも wp_sitemetaテーブル site_adminsの値を書き換えるわけだが、一見すると意味不明な値である。 例えば a:1:{i:0;s:7:“nwadmin”;} こんな値が入ってた場合、それぞれの意味は下表のようになる。 a:1 要素が1つの配列(array) i:0;s:7:“nwadmin”; これが要素の一塊 i:0 1番目の要素(index = 0) s:7 後続のユーザー名の文字数 “nwadmin” ユーザー名 よって、書き換える箇所はs:7の部分とユーザー名。 正しくない値を入れた場合、ネットワーク管理者に反映されないだけで然程危険性はなさそうだけど、書き換えは自己責任でオナシャス。 XigmaNASの設定XMLで無理やりマウントポイントを指定する XigmaNASの設定XMLファイルを書き換えて、無理やりマウントポイントの設定を行っちゃおうっていう、完全なるバッドノウハウ記事。 WebGUIの「ディスク > マウントポイント > マネージメント」で追加しろよって話なんだが、XigmaNAS 12.1.0.4 (Ingva/revision 7743)ではバグってるようで、マウント対象のディスクに何も表示されないのよ…。 過去のバージョンで設定したものは問題のバージョンに更新後も正常に動いている。となれば、どうにか設定を流し込んで永続化できれば動くハズ。で、苦肉の策で思いついたのが、設定のバックアップ&リストアを使えば行けるんじゃね?っていう。 試してみたら上手くできたので、記録として残しておく。 1. XigmaNASのWebGUIの「システム > 設定のバックアップ」から設定XMLを書き出す。 2. 設定XMLのmounts要素の中にマウントポイント情報を書く。 <mounts> <mount> <uuid>fe8974cf-548c-4aa9-91bf-80bb542cf153</uuid> <type>disk</type> <mdisk>/dev/da0</mdisk> <partition>p4</partition> <fstype>ufs</fstype> <gpt type="bool">1</gpt> <rawuuid>781bae78-8c56-11e7-b005-000c29de16ba</rawuuid> <devicespecialfile>/dev/ufsid/59a4be63ab3efa3e</devicespecialfile> <fsck type="bool">1</fsck> <sharename>sys</sharename> <desc>usb</desc> <accessrestrictions> <owner>root</owner> <group>wheel</group> <mode>0777</mode> </accessrestrictions> </mount> </mounts> タグ 意味 備考 <uuid> たぶんXigmaNASがマウントポイントを管理するのに使うUUID <type> デバイスの種類 <mdisk> マウント対象のデバイスファイル <partition> デバイファイルのパーティション識別文字列 <fstype> ファイルシステムの種類 <gpt> たぶん対象のディスクがGPTであることを表す <rawuuid> デバイスのUUID。gpart list デバイスで表示されるマウント対象のrawuuidを指定する。 <devicespecialfile> UFSの場合はdumpfs -l デバイスで表示されるパスを指定する。 <fsck> たぶん起動時にfsckするかどうかのフラグ <sharename> /mntのマウント先ディレクトリ名 <desc> XigmaNASのマウントポイントの詳細情報 <accessrestrictions> アクセス制御 <owner> <group> <mode> 字面のとおり 4.「システム > 設定のリストア」で書き換えた設定XMLでリストアする。 とりあえず、目先の回避だけできればいいので、各要素の詳細は調べてない。重要なのはmdisk, partition, fstype, rawuuid, sharenameかな?devicespecialfileは指定しなくても動きそうな気もするけど、わかんにゃい。 早くバグが直りますように。 参考サイト how to get/create ufsid's | The FreeBSD Forums start.txt 最終更新: 2022-07-27 15:26by Decomo