動的ライブラリをリンクしたシェルをログインシェルにしてはいけない

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をログインシェルとするリモートアクセス可能な緊急回復用ユーザー¹⁾を作っておくと良いだろう。

¹⁾

rootとtoorの関係が近いが、well-knownなユーザーをssh可にするのは流石に怖い

permalink · 2023-01-21 21:57 · Decomo · 0 Comments · Tags:

家鯖の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しとくか…

permalink · 2021-11-09 22:15 · Decomo · 0 Comments · Tags:

複数の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マシン²⁾hostname.example.comで作られた4台構成のRAID-Zプールzdata」の構成デバイスだった、ということが推測できる。

²⁾

pathのadaXから推定

permalink · 2021-02-13 13:42 · Decomo · 0 Comments · Tags:

WordPressマルチサイトのネットワーク管理者のパスワードは元より、アカウント名すらも忘れ途方に暮れたので、データベースを直接弄ってどうにかしたメモ。

WordPress 4.8.15で確認。試行錯誤の結果なので間違ってたらごめんちゃい。

テーブル名やmeta_key名にはwp-config.phpで指定したプレフィックスが付いてたりするので、いい塩梅で読み替えてください。

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	これは書き換えなくても大丈夫かも

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の部分とユーザー名。

正しくない値を入れた場合、ネットワーク管理者に反映されないだけで然程危険性はなさそうだけど、書き換えは自己責任でオナシャス。

permalink · 2020-12-22 07:02 · Decomo · 0 Comments · Tags:

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>	字面のとおり