ひな人形の並び方は、関東と関西で違う——。

しかもその違いは、単なる地域差ではなく、明治維新や西洋化、さらには天皇の婚礼儀式にまで関係しているというのです。

「右がお内裏様？ それとも左？」

子どもの頃から当たり前に見てきた雛飾りに、そんな歴史的背景があるとは考えたこともありませんでした。

調べてみると、そこには京都の古式礼法と、近代国家として歩み始めた日本の象徴的な変化が重なっていました。ひな祭りという穏やかな年中行事の中に、日本の伝統と近代化の物語が隠れていたのです。

今回は、関東と関西で異なるひな人形の並びについて、その由来を少し掘り下げてみたいと思います。

① もともとの日本古来の並び（京都中心）

日本の古い礼法では

• 「左が上位」（＝向かって右側が上位）

という考え方がありました。

天皇から見て左（＝観客から見ると右）が上位です。京都でも天皇のいた内裏から見て左(東側)に左京、右(西側)に右京区がありました。

そのため、

• 向かって 右に男雛（お内裏様）
• 向かって 左に女雛（お雛様）

という並びが京都を中心に続いていました。

これが「京雛（きょうびな）」の並びです。

② 明治以降の変化（東京中心）

明治維新で東京に遷都すると、西洋式の礼法が宮中儀礼に取り入れられます。

西洋では

• 向かって左が上位（右手が剣を持つ側になるため）

という配置が一般的でした。

そしてよく言われるのが、

1924年（大正天皇の即位礼・皇太子ご成婚などの宮中儀式）

天皇が向かって左、皇后が右に立たれた

という事例が大きく報道され、これが全国に広まったという説です。

その結果、

• 向かって 左に男雛
• 向かって 右に女雛

という並びが東京で主流になり、やがて全国に普及しました。

これがいわゆる「関東雛」です。

③ 今はどうなっている？

現在は：

• 東日本：男雛が向かって左（関東式）
• 京都・関西の老舗：男雛が向かって右（京雛）

という傾向があります。

ただし、

• 全国的には「関東式」が主流
• 量販店の雛人形はほぼ関東式
• 京都の人形店は今も古式を守ることが多い

という状況です。

面白いポイント

「右か左か」は単なる飾り方ではなく、

• 古代中国由来の左上位思想
• 武家礼法
• 西洋礼法
• 明治国家の象徴制度

などが全部絡んでいます。

単なるひな祭りの話に見えて、実は近代日本史の縮図なんですね。

と言う話をchatgptに書いてもらった

24inchもあってモバイルモニタ?という感想を持たれがちだとは思うが、まあ一応そういう触れ込みのモニタ。

そもそも今のワークスペースにも24inchのモニタは壁付けしておいてあるが、解像度がHDなので、拡張ディスプレイとして繋いでもだいぶ見劣りがするので、早晩もっと解像度の高いモニタが欲しいと思っていた。

現在のモニタにかかわらず、一般に液晶ディスプレイ、液晶テレビというのは本体はそれなりに薄型でも結局据えつけるとスタンドだったり、大袈裟な壁掛け装置だったりして設置してみると壁からはそれなりに距離があるものである。このディスプレイに使っているのは「壁美人」という石膏ボードにステープラーで固定器具を据えつけるものだが、壁に据えつけるプレートは薄型でも、ディスプレイのVESAにつける器具はチルトさせる機能がついていることもあって結構分厚いものである。壁につけた後でも上にダイソーの液晶ディスプレイ上部棚見たいのをおいてスピーカを置けるほどの厚みがある。

そんなわけで、モバイルモニタがいいのではないかと目論みつつあった。この頃のは結構薄くなっており、うまくすれば絵画くらいの厚みで壁につけられるのではないかと思っていた。ただ、一般にモバイルモニタはモバイルというだけあって可搬して使うのが前提になっているので、大型化しつつあるとはいえ、大体15.6inch、17inchくらいあるとおお結構でかいなどという感じだったが、Amazonを見ているとなんと23.8inchで4Kなんてものがあってびっくり。

23.8inch 4Kというのはコロナ禍の時に当時の勤め先から在宅勤務用に借りてきたモニタと同じスペック。もちろんこれは通常の液晶ディスプレイなので、サイズ感はだいぶ違うものの、この時に普通の人はちょっと小さくね？と思うサイズが近眼で老眼で比較的ディスプレイに近づいて見る自分にはちょうどいい大きさだった。その後あまり通常のディスプレイでこのサイズでこの解像度のものはなかったの(4Kだと大体下限は27inch)だが、モバイルディスプレイで出てきてくれたことはありがたい。

AmazonではおそらくOEM元は一箇所だと思うのだが、別ブランド3社から発売されている。最初に見つけたInnoViewのものをしばらくカートに入れておいたのだが、今回はその中の一つUPerfectのものが39999円という価格をつけていたので、買ってしまった。前記の通常ディスプレイ23.8inch 4KはLGのものが一番安くて3.1万円だった頃もあったが、この頃はそういうものもすっかり消えてしまった。それと比べると39999円は安いとはいえないものの、同スペックのものがほぼ消えIT機器も値上がりが激しい今日この頃では結構妥当な方であろう。

UPERFECT 23.8インチ 4K モバイルモニター

実物は期待通り薄くて綺麗に映った。一応MBA本体からUSB-C一本で映るには映るが、やはり電力が足りないせいかバックライトが最低限になって暗い。付属のUSB電源アダプタ利用が必須のようだ。

ただやはり壁に固定する方法が今ひとつ思い浮かばない。ディスプレイにはスタンドにもなるハンドルがついているが、今はそれを上側に畳んだ状態で壁美人のプレートに引っ掛けている。それなりの重量もあるので一見固定はされている様だが、ちょっと大きめの地震があると容易に落ちてしまうことは想像に難くない。なんとかしないと。ただ、やはり自身の重量が3kgあるので百均からホームセンターまでいろんなところを探しているが、それを支えられる器具がなかなかないというのが目下の最大の悩み。

さて最初は十分綺麗な映像に満足はしていたのだが、会社支給macでzoom会議をしていると時々電源が切れたように画面が消えることがあった。不思議なことに自分macで繋いでnetflixで映画などを見ていると切れることはなかったので、amazon経由で版元に問い合わせるとまずはその症状をビデオに撮って送れとか言われた。でもこういうのはいつ起こるかわからんのでその旨を伝えるとでは交換するので現物をこちらに送れと言われた。大抵の中華製機器は現物は送り返さずにすぐ代替品を送ってくるのだが、これだけ高価だとそういうわけにもいかないのだろう。幸いまだ箱はとっておいたのでそれを使って送り返した。

ものが送られてきた時はすでに年末に入っていてあまりzoomを使う機会もなくてすぐには確認できなかったが、使うようになるとやはりブラックアウト現象は観測された。のみならず、背景が真っ白だと第４象限のあたりが少し暗くなるムラが観測された。これは意外と気になるので、やはり不具合ではないかと写真付きでサポートに連絡。今回もビデオに撮って送れとか言われたので撮って送り返す。

新しく来たものは今までと微妙にバージョン(ロット？)が違う感じ。USBC電源も違うし、ケーブルも電源用は少し違うタイプで「電源用」というタグが付いている。本体も見た目はあまりわからないが中は違うのかもしれない。今回は色ムラもほぼなく(全くないかというと全体的にあるような気もするが、24inch 4K mobile monitorというチャレンジングな商品ならこんなもんだろうという許容範囲)現在までブラックアウトは起こっていない。

少し不具合があると報告するとすかさず新品に交換してくれるフットワークの軽さはさすが中国企業という感じはするが、それ以前に出荷時の品質管理をしっかりしてほしいと思ってしまうのもまた事実である。

十五で姐やは　嫁に行き
お里の便りも　絶えはてた

童謡『赤とんぼ』の三番。この二行には、何とも言えない寂しさが漂います。
「十五で嫁に行った」とは、誰のことを指しているのか？
単純な子守娘の別れと読むだけでは、どうも深すぎる余韻が残ります。

■ 通説：姐やは子守娘だった

もっとも一般的な解釈では、「姐や」とは奉公に出ていた子守娘を意味します。
昔の日本では、貧しい家の少女が十歳前後でよその家に奉公し、幼い子どもの世話をすることがありました。
やがて十五歳ほどになると、結婚してその家を離れるのが普通でした。

この歌では、幼いころ慕っていた姐やが十五で嫁に行き、
それ以後、里からの便り（手紙）も途絶えてしまった――。
つまりこれは、**幼少期に体験した「別れ」と「喪失」**の記憶を詩にしたものです。
赤とんぼが飛ぶ夕暮れの空は、過ぎ去った日々を映す「郷愁の色」となります。

出典：http://同志社女子大学 教員コラム「童謡『赤とんぼ』について」

■ 第二の読み：語り手が十五だった/

一方で、「十五で嫁に行き」の「十五」は語り手自身の年齢だとする説もあります。
つまり「自分が十五歳のころ、姐やが嫁に行った」という意味です。

この読みでは、姐やは年上の子守娘ではなく、
かつて慕っていた年上の女性、あるいは初恋のような存在として描かれます。

十五歳の少年が、淡い恋心を抱いた人が結婚してしまい、
それ以後便りも絶えてしまった――。
同じ歌詞でも、そこに滲むのは郷愁よりも恋慕と青春の痛みです。

童謡というより、ひとつの恋愛詩としての味わいを持つ読み方です。

出典：NPO法人北海道総合福祉研究センター「『十五でねえやは嫁に行き』を誤解していた」

■ 第三の読み：姐やは「母」だった

さらに深い読みとして、「姐や＝母」説があります。
作詞者・三木露風は幼少期に両親が離婚し、母と離れて育ちました。
彼の詩には生涯を通じて「母の不在」への想いが流れています。

この背景から読むと、「十五で姐やは嫁に行き」は
母が家を去った、あるいは別の家庭へ行ったことの象徴的な表現に見えてきます。

「負われて見たのはいつの日か」
──母の背に負われた記憶。

「お里の便りも絶えはてた」
──母からの手紙も途絶えた。

つまり、姐やという言葉の背後に“母”の影を重ねているのです。

出典：note「三木露風『赤とんぼ』を読み解く ― “ねえや”とは誰か 母の喪失が…」

■ その中間説：「母の代わりとしての姐や」

もうひとつの興味深い見方は、

「母が子を思い、郷里の娘を子守として送った」
という実際の三木露風の境遇を踏まえる説です。

この場合、姐やは実母そのものではなく、
母と子をつなぐ象徴的な存在。
姐やが嫁に行ったことで、そのつながりも絶えてしまい、
母の消息も途絶えた――という構図になります。

これは「母の代わりに愛してくれた人をも失う」という、
非常に個人的で痛切な物語です。

出典：Ameba OWND「童謡『赤とんぼ』に秘められた思い」

■ なぜこの詩は人を惹きつけるのか

どの解釈を取るにしても、『赤とんぼ』の中心には「失われたもの」があります。
子守娘でも、初恋でも、母でも――それは「もう戻らない過去」です。

赤とんぼが飛ぶ夕暮れの空は、
人が誰しも持つ「取り戻せない時間」そのものを象徴しています。

三木露風は、曖昧な言葉をあえて選び、
聴く人それぞれが自分の“喪失”を投影できる余白を残しました。
それが、この詩が100年近く経った今も読み継がれる理由でしょう。

■ 結び

「十五で姐やは嫁に行き」
その短い一行の中に、
幼年の記憶、恋の痛み、母への慕情――
それぞれの人生の“夕焼け”が重なっています。

だからこそ、『赤とんぼ』は童謡でありながら、
大人の心にこそ響く詩なのです。

ということをChatGPTに書いてもらった。

ただ赤とんぼ・三木露風　（二） – 東川寺 Homepageによると、三木露風本人は

『赤とんぼ』の中に姐やとあるのは、子守娘のことである。

私の子守娘が、私を背に負ふて廣場で遊んでゐた。

その時、私が背の上で見たのが赤とんぼである。

と言っているようだ。里の便りが絶え果てた理由については本人からの言及はないようだが。

もともと実話に基づいた作品が好きだが、この映画は特に印象に残った。華やかな宇宙開発の裏側で、ロケットの軌道を“手計算”していた黒人女性たちの物語。彼女たちはNASAの一員でありながら、当時は「colored computers（有色人種の計算手）」と呼ばれていた。

このエントリのタイトルにある“コンピュータ”とは、機械ではなく、人間そのもののことだったのだ。

人間のコンピュータたち

いまや「コンピュータ」といえば機械を指す。けれど1950年代までは、それは立派な職業名だった。

“ヒューマン・コンピュータ”――つまり、計算を職業とする人々。彼女たちは手で積分を解き、近似式を求め、膨大な数の軌道データを紙と鉛筆で処理していた。ロケットが飛ぶかどうかは、彼女たちの数字の正確さにかかっていた。「コンピュータがまだ人間だった頃」という副題を思いついたのは、そんな時代への敬意からだ。人間が、数字の世界で機械のように正確に働いていた時代。その姿に、どこか温かさと切なさを感じる。

IBM7090がやってきた日

映画の中盤、巨大なIBM 7090がNASAに搬入されるシーンがある。それまで人の手で行われていた計算が、これからは機械に置き換わっていく――。人間のコンピュータたちにとって、それは恐るべき“ライバルの登場”だった。

だが実際の彼女たちは、ただ怯えていたわけではない。ドロシー・ヴォーンという女性は、いち早くFORTRANを学び、仲間たちに教えた。そして新しい時代の「プログラマ」へと転身していった。機械に仕事を奪われるどころか、機械を使いこなす側になったのだ。

このエピソードを見ていると、いまのAI時代にも重なって見える。「AIが人間の仕事を奪う」と言われるたびに、“人間が機械を使いこなす”という選択肢を、私たちはもう一度思い出すべきなのかもしれない。

技術の進歩と、人間の進歩

1960年代初期、NASAはまだ人種分離と性差別の時代にあった。同じ職場で働いていても、黒人女性は白人用のトイレを使えなかった。映画の中でキャサリン・ジョンソンが、

「どうしてトイレに行くのに800メートルも走らなきゃいけないの！」

と訴える場面は、心に刺さる。電子計算機は人種を区別せずに数字を処理する。しかし、それを使う人間の社会は、まだ偏見から自由ではなかった。技術の進歩と社会の進歩――どちらが速かったのか、考えさせられる。

そして今

いま私たちは、AIという「新しいコンピュータの時代」にいる。数字を操るのはもう人間ではなく、機械でもなく、学習するソフトウェアだ。けれどその出発点に、紙と鉛筆で軌道を求めた女性たちがいたことを忘れてはいけない。

“コンピュータがまだ人間だった頃”

それは、人間が最も信頼される計算機だった時代だ。冷静で、正確で、そして誰よりも情熱的だった彼女たち。その努力の積み重ねの先に、今の私たちのテクノロジーがある。

終わりに

『ドリーム』は、ロケットの話ではなく、「人間の知恵と尊厳」の話だ。計算という、一見地味な行為の中に、こんなにも誇りが宿るとは思わなかった。彼女たちが紙の上に描いた軌道は、いまも私たちの社会のどこかに続いている気がする。

まあこのエントリもChatGPTが書いたんですけどね。

特に使い途もないうちのラズパイ4、新しいイメージを入れたら何か使えるようにもなるのかもと、バージョンアップしてみた。

この頃は自宅のリビングのテレビのセットトップボックスがわりにしてみようと思っていて、時々テレビに繋いで動かしてたりしたものだが、ブラウザでフルスクリーンで動画を見ようとすると再生がカクカクになってしまうという問題が度々起きていた。

他の機能ならいざ知らず、セットトップボックスがわりなので、動画の再生が酷いと如何ともし難い。ということで試みるたびに頓挫していたのだが、今回たまたまDLしたRaspberry PI OSが意外と調子が良かった。

DLしたのは公式ページにあるRaspberry PI OS (64bit) (https://downloads.raspberrypi.com/raspios_arm64/images/raspios_arm64-2025-05-13/2025-05-13-raspios-bookworm-arm64.img.xz) 手元のMBAにunxzが入っていないとかmini SD cardに焼くのに時間がかかったりとかそういう細かい紆余曲折はあったものの(これはおそらく純正のimagerを使えばあまり問題にはならないはず)、いつも通りインストールして起動させた。

前述のように以前のバージョンだと動画を4K画面でフルスクリーンで表示させるとカクカクでしょうがなかった(面白いことに、フルスクリーンにしたブラウザの中で動画をブラウザ内フルスクリーンにするといくらかはスムーズになっていた)のだが、今回はスムーズにいっている。再生しはじめにはリップシンクしないところも見受けられるが、時間が経つとそれも解消しているように見える。

余っていたwebカメラをUSB3.0ポートに繋ぐと特に何することもなく認識されたようで、webブラウザ内からgoogle meetに接続するとこちら側の画面は綺麗に表示されるので、ビデオ他通話的なのにも使えそうである。zoomも試してはいないがwebで使えるそうなのでなんとかいけるかもしれない。

立ち上げるたびに有線のキーボードとマウスをいそいそと繋ぐのは面倒なので、bluetoothキーボードとマウスも設定してみた。案の定電池切れとかになっていたので、今後は定期的に立ち上げて様子を見ないといかん。

細かい字と小さいマウスカーソルなので、セットトップボックスというには無理があるが、とりあえずは使えるようにはなった。あとはおいおい10feet UIとかを入れてみようか。

表向きは“キャリアを投げ打って夢を追う女性と恋の行方”という軽快なラブコメですが、実際に観てみると、ただの恋愛映画ではありませんでした。

なぜならこの作品、随所に流れるオペラの名曲が物語を動かしているのです。

マックスが歌う「フィガロ」は本当に《フィガロの結婚》なのか？　ラストで選ばれた《ドン・ジョバンニ》の二重唱にはどんな意味があるのか？

──この選曲をたどると、実は映画の裏に“オペラ史の縮図”が隠れていました。

ここから先は、フィガロ三部作やモーツァルトのダ・ポンテ三部作と絡めて、この映画をもう少し深く見ていきます。

映画とオペラ──「フィガロに恋して」で架かる橋

この前「フィガロに恋して」を観ました。

ストーリー自体は軽やかなロマンスですが、何より印象的だったのは選曲の妙と、それを支えるスコットランドの雄大な風景です。映画の筋以上に、流れるオペラ曲が作品を語っているとさえ言えるでしょう。

特にマックスが歌ったのはロッシーニの《セビリャの理髪師》。これを「フィガロの結婚」と誤解する人もいましたが、どちらも“フィガロ”を中心人物とした作品で、むしろ並べて考えるべきものです。

ここにこそ、映画タイトルの二重の意味が仕込まれているように思えます。

フィガロ三部作とオペラの連続性

“フィガロ”をめぐる物語は、じつは三部作で語られる長いドラマです。

《セビリャの理髪師》（ロッシーニ作曲） 若き理髪師フィガロが伯爵を助け、ロジーナを妻に迎える物語。軽快な喜劇。

《フィガロの結婚》（モーツァルト作曲） 数年後、結婚したフィガロとスザンナが主人を出し抜く。風刺的でより社会的な喜劇。

《罪ある母》（ボーマルシェ原作） 老境に入った人物たちの愛憎を描き、軽喜劇から一転してシリアスな人間ドラマへ。

映画が引用したのはこの最初の「入口」とも言える《セビリャの理髪師》の有名なアリア。つまり「夢を追う若者」の姿とリンクしているわけです。

そしてクライマックスで歌われるのはモーツァルト《ドン・ジョバンニ》の二重唱「Là ci darem la mano」。誘惑のデュエットでありながら、映画では未来へ進む二人の象徴になっていました。

この“選曲の飛躍”が、単なる恋愛映画以上の奥行きを与えています。

また他にも『恋とはどんなものかしら』『きらきら星』『夜の女王のアリア』『パパゲーノとパパゲーナのデュエット』などのモーツァルトの名曲も効果的に使われていて、オペラ好きにはたまらない演出の数々でした。

モーツァルトと「音楽ドラマ」の革命性

モーツァルトは《フィガロの結婚》《ドン・ジョバンニ》《コジ・ファン・トゥッテ》を「ダ・ポンテ三部作」として残しました。どれも人間関係の機微を巧みに描き、当時のオペラを単なる見せ物から心理劇へと変貌させた重要な作品群です。

映画の中でこれらの曲が要所要所に配置されることは、偶然ではありません。観客は無意識のうちに「人間の欲望」「愛と欺瞞」「若さと老い」といった普遍的なテーマに触れているのです。オペラを知らない人でも、劇伴として聴くことでそのエッセンスを体感できる──これが映画最大の功績だと思います。

ツェルリーナを「主役級」に扱う違和感

一点だけ気になったのは、ツェルリーナという役の扱い。『ドン・ジョバンニ』において彼女は確かに印象的ですが、あくまで脇を固める役柄。ところが映画の宣材では彼女が大きく扱われ、ポスターでも主役級に並べられていました。これは純粋にオペラ的な視点からすると違和感があります。

ただし映画の物語構造を考えれば、ツェルリーナ役＝ミリーの「未熟だが可能性ある存在」として象徴的に据えた、と読むこともできます。つまり、宣伝の“誇張”は映画のテーマと響き合っているのかもしれません。

まとめ：オペラを知る人ほど楽しめる映画

「フィガロに恋して」は単なるロマコメではなく、フィガロ三部作やダ・ポンテ三部作との接続を意識すると、ぐっと味わいが深まります。ロッシーニからモーツァルトへ、そして“誘惑の二重唱”で幕を閉じる流れは、まるでオペラ史のダイジェストのよう。

オペラに親しんでいる人なら、曲の選択やキャラクターの扱いをめぐってあれこれ語りたくなるでしょう。逆に初心者にとっては、名曲を入口にオペラの世界へ足を踏み入れる格好のチャンス。まさに「映画とオペラの架け橋」と呼べる作品でした。

まあ全部ChatGPTに書いてもらったんですけどね。

このblogをホストしているubuntuにloginしたら色々updateが溜まっていたようなので、気楽にupdateしてみた。するとここのwordpressが動かなくなった。どうも無理やりroutedで動かしていたのが動かなくなっていた。

今まではNATをしないためにiptablesをdisableにして、host側にrouting設定を入れておけばcontainerに対してもL3 routingしてくれてたのだが、どう設定してもそれがうまくいかなくなっていた。NATしない時はiptableやめちゃえって書いてあったはずの公式ドキュメントもない。いつの頃からかよく見るとiptablesのchain項目に’DOCKER xxx’というのが増えている。ここに設定している内容はiptables -Fとかでは全部消えないようで、iptables=falseとかしてもうまく動かない。chatgptが

どうやら新たに独自にrouted typeのbridge(network)を作ると、iptables他の設定はいじらずに通常のL3 networkはしてくれるっぽい。ただ、現在動いているコンテナのネットワーク設定は変えられないので、改めてcontainerを作るところから始めなきゃ行けないようだ。

とりあえず現在稼働中のやつのimageをとっておかねばというところで、mysql、wordpressのimageをcommitしておく

$ sudo docker commit momose-wordpress miscmemo-wordpress-latest:20240818
sha256:495adc56fa9dbd1cda8c969f7ab82d6f474d2871698e1d426f99523dd25efa04
$ sudo docker commit wp-mysql mysql:5.7.21-my20240818
sha256:4fb2a23c3b0016c3087e39be1453c01ce81a18df897a517a253d54a7f6f87bca

routedになるnetworkを作る。v6 prefixも指定し、gateway_mode_ipv4をroutedにし enable_ip_masqueradeをfalseにするのがポイント。

$ sudo docker network create --driver bridge --subnet 172.18.0.0/16 --ipv6 --subnet 2001:2c0:cc17:c302::/64  --opt com.docker.network.bridge.gateway_mode_ipv4=routed   --opt com.docker.network.bridge.enable_ip_masquerade=false   routed-net
e8df9d66c9e9b68d22eddd0464451b1e955f14df0d51fc14d24bfee383c1a30b

退避させた(というかcommitした)imageを使ってこのnetwork上にcontainerを作る。前のやつは止めたままにしておく。今までアドレスはhost起動直後に各コンテナを手動で起動させることでIP address固定にするという原始的とも言えないほど原始的なことをしていたが、今回からは専用bridgeを作ってそこでIPアドレスを固定にする。

$ sudo docker run -d --name miscmemo-wp-mysql --network routed-net --ip 172.18.0.2 -v /var/lib/mysql -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=mysql -e MYSQL_USER=wordpress -e MYSQL_PASSWORD=wordpress -p 3306:3306   mysql:5.7.21-my20240818
3abb3d2c34be91cbf8f0d48bee9491d84117713efaef12b371376e8502c02893
sudo docker run --network routed-net --ip 172.18.0.3 -v /var/www/html/:/var/www/html --name miscmemo-wordpress -d miscmemo-wordpress-latest:20240818
31ee2c1176cc7258b09fdf82b3c61d95e4762b6040c32b62c3c309ff743b4c17

ごちゃごちゃいじりすぎたので、docker本体をrestart。miscmemo-wordpress (wordpress本体; 172.18.0.3からmiscmemo-wp-mysql (wordpress用のmysql; 172.18.0.2)へのpingは通る。が、外(10.0.0.1とか)からは通らない。もちろん10.0.0.1には172.16.0.0/14宛のrouteはこのubuntu本体がnexthopになるようなrouteを設定してある。

これは例によってiptablesの設定が足りていなかろうということで、miscmemo-wordpress tcp:80宛は通るようにしておく。port限定しなくてもip全部通せばいいんじゃないかとも思うが、どうせ80以外は空いていないからとりあえずこれで。

$ sudo iptables -L
[sudo] momose のパスワード: 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy DROP)
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere            
DOCKER-FORWARD  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain DOCKER (2 references)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             172.18.0.2           tcp dpt:mysql
ACCEPT     icmp --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain DOCKER-BRIDGE (1 references)
target     prot opt source               destination         
DOCKER     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            

Chain DOCKER-CT (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED

Chain DOCKER-FORWARD (1 references)
target     prot opt source               destination         
DOCKER-CT  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere            
DOCKER-BRIDGE  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
RETURN     all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain DOCKER-USER (1 references)
target     prot opt source               destination         
momose@peso:~$ sudo iptables -I DOCKER 1 -d 172.18.0.3 -p tcp --dport 80 -j ACCEPT
momose@peso:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy DROP)
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere            
DOCKER-FORWARD  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain DOCKER (2 references)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             172.18.0.3           tcp dpt:http
ACCEPT     tcp  --  anywhere             172.18.0.2           tcp dpt:mysql
ACCEPT     icmp --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain DOCKER-BRIDGE (1 references)
target     prot opt source               destination         
DOCKER     all  --  anywhere             anywhere            
DOCKER     all  --  anywhere             anywhere            

Chain DOCKER-CT (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED

Chain DOCKER-FORWARD (1 references)
target     prot opt source               destination         
DOCKER-CT  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere            
DOCKER-BRIDGE  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
RETURN     all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            

Chain DOCKER-USER (1 references)
target     prot opt source               destination         

この状態でもmiscmemo.momose.orgまたは172.18.0.3にwebで繋いでも’Error establishing database connection’になる。DBにloginできないということか?

db containerを作るときは-p 3306:3306してあるので、localhostに繋げばいけるはずだが、やはりいけない(これは謎)ので、172.18.0.2にmysql clientで繋いでみる。

docker runしたときにMYSQL_USERとかMYSQL_PASSWORD設定したせいか、それらのユーザは設定されているが、databaseとしてwordpressは定義されていない。

mysql> select User from mysql.user;
+---------------+
| User          |
+---------------+
| root          |
| wordpress     |
| mysql.session |
| mysql.sys     |
| root          |
+---------------+
5 rows in set (0.01 sec)
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
+--------------------+
2 rows in set (0.00 sec)

結論から言えば、これはvolumeの設定の仕方(-v option)の設定の仕方が悪い。上記例では ‘-v /var/lib/mysql’としてしか設定していないが、これはcontainer内部の/var/lib/mysqlをホスト側の匿名ボリュームを使え、ということしか指定していない。今回は新たに匿名ボリュームを作ってそれを内部で使おうとしているのに過ぎないので、今までのmysqlのデータは見れなくなっている。

今まで使っていたmysqlコンテナはdocker inspectすると

        "Mounts": [
            {
                "Type": "volume",
                "Name": "437162831f28b01734805001401217d94ae83d2c2ba91df5121bf27b1ec582c2",
                "Source": "/var/lib/docker/volumes/437162831f28b01734805001401217d94ae83d2c2ba91df5121bf27b1ec582c2/_data",
                 "Destination": "/var/lib/mysql",

で、hostの437…というvolumeを使っていたが、新しい方だと

        "Mounts": [
            {
                "Type": "volume",
                "Name": "ffbcf68f7e10fe79b6252f374094d4fd9ed61e0ac884ece61966cbdb7595b7cb",
                "Source": "/var/lib/docker/volumes/ffbcf68f7e10fe79b6252f374094d4fd9ed61e0ac884ece61966cbdb7595b7cb/_data",
                "Destination": "/var/lib/mysql",
 

となっていて、全く別のffbcという匿名ボリュームを指している。なので、旧データが復活できていない。

というわけで、mysqlデータが入っているはずの匿名ボリュームを指してコンテナを作り直す。

$ sudo docker run -d --name miscmemo-wp-mysql --network routed-net --ip 172.18.0.2 -v 437162831f28b01734805001401217d94ae83d2c2ba91df5121bf27b1ec582c2:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=mysql -e MYSQL_USER=wordpress -e MYSQL_PASSWORD=wordpress -p 3306:3306   mysql:5.7.21
434a61c30c7b967c440adbd8c3b518825da99e9b1be1b7e7463eb6f867a71c7f

一応これで旧mysqlデータも読み込めて、接続できるようになった。

が、なんかのはずみですぐこのmysqlコンテナが落ちる。通常の閲覧画面は見えるが、admin画面にアクセスしたら落ちる(画面的にはしばらく待たせられる状態になる。その後切れる)、loginしようとしたら落ちる、などなど。

原因はよくわからないので、この際旧データを吸い上げて新しいコンテナを設置の上、そのデータを読み込ませて復旧させることにした。

$ mysqldump -h 127.0.0.1 -u root --ssl-mode=DISABLED -p wordpress > miscmemo-wp.sql
Enter password: 
-- Warning: column statistics not supported by the server.

ここで読み込んだファイルの先頭に、CREATE DATABASE wordpress;USE wordpress;を入れる。

$ mysql -h 172.18.0.2 -P 3306 -u root -p < miscmemo-wp.sql
$ mysql -h 172.18.0.2 -P 3306 -u root -p 
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 19
Server version: 9.4.0 MySQL Community Server - GPL

Copyright (c) 2000, 2025, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show databases
    -> ;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| wordpress          |
+--------------------+
5 rows in set (0.01 sec)

mysql> use wordpress;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+-----------------------+
| Tables_in_wordpress   |
+-----------------------+
| wp_aal_products       |
| wp_aal_request_cache  |
| wp_aal_tasks          |
| wp_commentmeta        |
| wp_comments           |
| wp_links              |
| wp_options            |
| wp_postmeta           |
| wp_posts              |
| wp_pz_linkcard        |
| wp_term_relationships |
| wp_term_taxonomy      |
| wp_termmeta           |
| wp_terms              |
| wp_usermeta           |
| wp_users              |
+-----------------------+
16 rows in set (0.01 sec)

mysql> ^DBye

rootユーザでセットアップしてしまったためか、wordpress dbにアクセスできるのがwordpressユーザではなくrootユーザになってしまったので、wordpressコンテナの/var/www/wp-config.phpのUSERとPASSWORDをroot用のに変更、起動し直すと今度はうまくいった。adminアクセスとかも問題なさそう。

ただ、adminダッシュボード画面ではwordpress.orgにアクセスできないとか言っている。どうも外にうまく繋がっていないようだ。iptableで外向きもいけるように設定。

$ sudo iptables -I DOCKER 1 -s 172.18.0.3 -p tcp -j ACCEPT

実は外向けルータでnatのルールに172.18.0.3が入っていないことがわかったので、そっちも設定。FreeBSDの/etc/ipnat.rules、172.16.0.0/16だったのを172.16..0.0/14に。今までも172.17.x.xだったからいけなかったはずなんだがいけていたのはちょっと不思議ではある。

map ng0 172.16.0.0/14 -> 0.0.0.0/32 portmap tcp/udp 60000:65000
#map ng0 172.16.0.0/46 -> 0.0.0.0/32 icmpidmap icmp
map ng0 172.16.0.0/14 -> 0.0.0.0/32 proxy port ftp ftp/tcp
map ng0 172.16.0.0/14 -> 0.0.0.0/32
#

これで一通り復活はできた。途中作りまくった匿名ボリュームとか今後使わないだろうimageとかは決しておく。今のところこのエントリをかける程度までは安定して動いている。

iptablesを次のreboot前までには安定させないといけない。

ipv6を復活させよう。

前回のMac更新が2019年、爾来6年、未だintelアーキテクチャ、OSの最新バージョンサポートもなくなってしばらく経つが、手元不如意でなかなかアップデートもできなかったのが、ようやく(US株式相場の復活もあり?)更新できた。

プライベート機としては初めてのApple Silicon機。が故のあるいはあまりにも古い機種からの移行故の移行時のトラブルもいくつか。

購入まで

いい加減古くなってきた前機、時々チャタリングを起こすようになってきた。よくおきたのが[r]キー(世間で言うところの[o])と[.](世間で言うところの[e])。このせいで’.org’と入れたつもりが’..orrg’とかになってしまったりしていた。

新しいのが欲しくなってきたが、何せ安いものではない。子供にも金がかかる。使えないわけでもないから買い直すのもどうか、と思っていたが、遂に Sonoma(macOS14)あたりからバージョンアップ対象にもならなくなった。 それでもセキュリティパッチは出続けているし、使うのに支障はないと自らに言い聞かせていた。

また、買うなら広い画面の15inchがいいだろうと思っていたが、やはり価格は相当高い。

結局、その時kakaku.comとか見ていて、一番安い13inch 512GBで170000円弱が相場っぽいので、その辺りのレンジを狙う。ざっくり18万円以下が目標。AmazonとかBicとかだとポイント還元があるので、それを加味するとこれらの最安価格よりはやや高めで買えそうで、正規のApple Store価格よりは1万円程度安い。安売り屋だと色によって価格が安くなる。一番安いのはどうやらスターライト。gold系だけど、どの程度goldなのかはわからないので、Apple Store実店舗に言ってみた。

Apple Store丸の内に全色揃ってはいたものの、暖色系の灯りなので特にスターライトは色味がわからない。窓際が自然光なのでそっちでみてみたかったが、盗難防止の綱がついていて動かせなさそうだった。ただどの色もそれほど濃いわけではないので、まあスターライトでもいいかなと思いかけていたところに店員さんが、「指輪がゴールドの方などにはこの色がお似合いです」などと言うからゴールドの指輪なんてしたことない自分としては一気に萎えてしまった。

そうこうしているうちにAmazon Primeセールが近づいてきて、どうやらApple製品も安くなるらしいことがわかったので、この価格をポイント込みで比べてみることにする。実際にMacBook Airがプライム価格になったのはプリセール期間中。

MacBook Air 13inch 2025 M4 10core GPU/16GB/512GB SSD スカイブルーで 171800円。額面上は最安値ではないが、ここにAmazonポイントは1869ポイントがつく。さらに今回はこの機にAmazonクレカを作ったのでそのご褒美ポイントで7811円分安くなる。たまたま入っていたギフト券300円を合わせて、支払額163689円となった。(pointは後でつく)さらに色も選べる。尤も、色は購入後数日してみてみたらシルバーが既に売り切れていた。やはり色による人気のあるなしはあるので、安売り屋が色によって価格差をつけるのはむべなるかなと言う感じである。

Amazonにしろ安売り屋にしろ、Apple以外から直接買う時の唯一の問題は、US配列キーボードを選べないこと。

届いてから

いつもの開封の儀。

セットアップもいつも通り。Wifiに繋いで旧機種で「移行アシスタント」を起動。移行アシスタントは他のアプリを終了させるが、色々終了できないアプリもあって少しだけ難儀した。

移行ファイル数のカウントに時間がかかるのか、「準備中」のステータスが長い。１時間以上はこのステータスだったと思う。実移行時は420万のファイルを移行するんだそうだ。残り時間14時間と出た。数十分後にみたら3時間と出ていて、結局移行は2-3時間程度で完了した。

再起動後、ログインするとさっきまで旧機種で使っていたのと同じwebブラウザの散らかり具合で再開した。さすがだ。

しかし、ターミナルが起動しない。という困った問題が。アプリ自体は上がり、何らかのターミナルらしきウィンドウが一瞬現れるがすぐに消える。ターミナルアイコンを右クリックして現れるメニューから「新規コマンド」を選んで明示的に’tcsh’を指定すると立ち上がる。これは面妖な、とターミナルの「設定」「一般」の「開くシェル」のデフォルトをコマンドの方を選択してshellのfull pathを入れるときちんと開いた。つまりデフォルトのログインシェルがいけない。この開いている状態で、chshで/bin/tcshを選ぶと、以降デフォルトのログインシェルでも正常にターミナルウィンドウが開くようになった。つまりこれは以前に自分用にtcshを改造しかけて/usr/local/bin/に置いておいたtcshをデフォルトログインシェルにしていたが、それが正常に動作しないために起こった問題であった。正常動作しないのはterminalを開くときだけで、一度上がってしまえばそこから/usr/local/bin/tcshとやっても普通に動作する。これはこれで面妖である。

動作が確認できたもの

• ScanSnap Home
• EasyRes
  • 動くけど、今時のmacOSは設定可能な解像度全部出してくれるからいらねえなと思って消すことにした

結局ホスト機のマザーとかの不調というよりも、どうもmiscmemo blogを運用していた何でもubuntu VMの一部コンテナであるこのblogのコンテナのどれかが触られると固まるような気がしてきた。他のVM動かしても止まらないし。

そんなこんなでストレージも取り替え、ようやくこのblogをホストしているwordpress containerが復活したのでその顛末。

ESXi機不調

昨年(2024年)末ごろ、ESXi機に不調になり、突然反応がなくなる、突然リブートしてたり(ESXiコントロール画面で見ると、全VMが落ちている)といった事象が頻発していた。

熱暴走かな？と思ってある日本体を開けてみると、CPUファン近辺にホコリがみっしり。辛うじてファンは回っていたもののあまりの驚きに写真を撮るさえ忘れてしまった。これはエアダスターなどを駆使して除去し、一安心。

しかしその後も同じような不具合は頻発する。

• ACアダプタにはおそらく通電時には光るであろうLEDがついているが、全く光っていない。が、通常通り通電はしているように見える。もし不具合があるのだとしたら、出力が足りないのかもしれない
• ハードウェアの不具合だとすると、メモリが壊れている可能性もある。memtest86という世間でよく使われているらしいメモリテストソフトを使ってみた。これは特定のOSの上で動くアプリではなくこれごとbootしてメモリテストだけを行う。64GBに対して8時間ほどかかった。が、特に異常なし。
• 負荷がかかったに落ちるのかと、FreeBSD VMでyesをbackgroundで実行。このHWでこんなにファンが回るのかというくらいまで周り、消費電力も増えていることを確認したが、落ちなかった。

これらをやってもやはり数日で落ちる。

しばらくして分かったことは、しばらく落ちてなくても、どうやらubuntuを立ち上げて、この日記用コンテナをあげると、翌日くらいには落ちてるパターンが多かった、ということだ。

特定のVMがストレージの特定の場所(ここはきっとこの特定のVMに占有されているだろう)にアクセスするとハードウェア的に不安定になって落ちたりリセットがかかるのかもしれない。通常ストレージの一部が読めなくなったとしても、動いているVMにはエラーで読めなかったというステータスが返ってきてそのVMが不安定になるだけだが、今回の場合は何かハードウェア的な秘孔を突いた、ということなのかもしれぬ。

その傍証として、ホストハードウェアの交換も視野に入れてVMのイメージを別の場所にコピーしていた時、他のVMのイメージは時間はかかったとしても比較的リーズナブルな時間でコピーまたは移動は完了するのだが、ubuntu imageだけはなかなか終わらず、最後にはホストのUIも反応しなくなったということがあった。

このホスト機を導入した経緯はESXi機アップデートにあり。

Ununtuの必要データをサルベージ

ubuntuをはじめとするいくつかのVMは本体内のM.2 SSDに入っていたのだが、ubuntu以外は正常に外部のストレージに引越できた。

ubuntuはセッション繋ぎっぱなし用デスクトップとして使ったり、何も入っていないgitlabやkernel build専用のコンテナをホストしたりしていたが、これらはともかく、このブログは個人的に有用かもしれないメモとかあるので、何とかして救いたかった。救うべきものは三つ

• wordpress コンテナ
• wordpressコンテナが永続化ファイルとしてマウントしているwordpress用の各種ファイル
• mysqlコンテナ
• mysqlが持っている永続化されたデータ

コンテナ系はdocker saveで保存。復帰後にdocker loadでイメージを戻す。

永続ファイルとしてあるホストにあるファイルは、wordpressの方は単純にtarで固める。mysqlはデータファイルを復活できるかが自信なかったので、mysql dumpで全データをmysqlのコマンドとして吐き出す。

$ mysqldump -h localhost -u root --ssl-mode=DISABLE -p<password> wordpress > mysql-backup.sql

これらの過程でシステム不安定化させている秘孔をつかないとも限らないが、今回は何とか乗り切ったようだった。

VMホスト機再構築へ

ストレージ調達

とりあえずストレージが怪しいということで、新しいのを調達することとした。今使っているのはCrucialのやつだが、結構安めのものを選んでいた。もしかしてTBWの値も小さかったのかもしれない。

この反省を生かして、もっとよさそうなデータセンタークオリティということになっているWestern DigitalのWD Redにすることとした。(あれ、データセンタークオリティを謳っているのはWD Red Proだったかな)

買ったのはこれ。WDS100T1R0C [WD Red SN700 NVMe SSD（1TB M.2(2280) PCIe Gen3 x4 NVMe 2000TBW 5年保証）] [Amazon]

OS選定とインストール

何とか掬い上げたVM達を何とかそのまま使いたいということで、できればESXiを使いたいところだが、ESXiは去年のbroadcomの方針により無料バージョンがなくなった。

今使っていたESXi7のインストールメディアを探し出してそれを使うかと思っていたがそういえば一時期の不用品大パージのおりに使わないCD-ROMとか纏めて捨てたんだった。せめてイメージだけでも残っていないかとそれっぽいところも探したが、intel NIC対応インストールメディアを作る時の残骸があっただけだった。これでESXiの目はなくなった。Proxmoxにするかなあと思っていたところへESXi8.0u3が派手なアナウンスもなく、さらっと無料化復活へ、という情報が。

これはbroadcomで会員アカウントを作ればあとは無料でDLできるらしい。しかもIntel 226vドライバも対応。早速インストールしてみる。ちゃんとNICも認識した。webのデザインもだいぶフラット化というのかそんな感じだ。外部NASのiscsiも認識した。iscsiまたはNFSに置いたVMもあらかた復活できた。

ただ、今回も突然ホストごと固まるという事象が何回か散見された。ディスプレイが繋がっていないため、固まるとどうにもわからないので、ディスプレイは繋ぎっぱなしにしておく。

何回かはESXiの待機画面のまま固まっていた。後はいわゆるPSOD(Purple Screen Of Damage)の画面。

これをよくみると、PCPU 11: no heartbeatとある。何だかよくわからないが、PCPU(Performance CPU?)11が死んでるということのようにもみえる。もしかしたらC-StateとかでCPUが一旦寝てしまうと起きてこないのかもしれない。

BIOS設定画面でP-StateとかC-Stateっぽい設定があったので、それらをdisableしてみる。ただ同じ筐体のデフォルト設定でESXi7は何年も動いていたのに？

ただ、これらの設定で、とりあえずは今はまだ理不尽なリセットは起きていない。

最悪この理不尽リセットが続くようであれば、機種移行も検討しなければならない。今考えているのがhttps://amzn.to/4dF8tTO 8C16T AMD Ryzen 7 PRO 6850H。amazonでは度々セールをしていて5万円弱。AliExpressだとベアボーンでもっと安く売っている。

ubuntu復活

前述のように他のVMはvmx右クリックですぐ復活できたが、ubuntu imageはサルベージできなかったので、OSインストールからやり直す必要がある。

desktopの設定、dockerのインストールは通常通り。

その先の設定、実はこのblogの最初の記事に書いてあるので、このblogを復活させないと設定方法がわからないという実に缶切りは缶詰の中状態。サルベージしたsqlファイルの中身を見たり、何とか思い出して設定を行なった。

ここのdockerホストはcontainer networkに対してNATではなくL3 networkを提供するようにしているので、このdockerdに対してはiptablesを無効化し、提供するIPv6のprefixを指定する。

ExecStart=/usr/bin/dockerd --iptables=FALSE --ipv6 --fixed-cidr-v6="2001:2c0:cc17:c301::/64" -H fd://

各コンテナはまずバックアップしたファイルからimageをrestoreする。

sudo docker load < mysql5.7.21.tar.gz
sudo docker load < miscmemo-wordpress-latest.tar.gz

これでimageは入った。

$ sudo docker images
[sudo] momose のパスワード:
REPOSITORY                  TAG       IMAGE ID       CREATED        SIZE
miscmemo-wordpress-latest   latest    40af751e8d84   2 months ago   725MB
hello-world                 latest    74cc54e27dc4   4 months ago   10.1kB
mysql                       5.7.21    5195076672a7   7 years ago    371MB

mysql containerを作成、DBを復旧させる。

sudo docker run -d --name wp-mysql -v /var/lib/mysql -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=mysql -e MYSQL_USER=wordpress -e MYSQL_PASSWORD=wordpress -p 3306:3306 mysql:5.7.21
mysql -h 127.0.0.1 -P 3306 -u root -p --ssl-mode=DISABLED < miscmemo-wordpress.backup/mysql-backup.sql

WordPressの永続化部分を展開。いろいろわかってなくて変なところに展開する

cd /var/www/html
tar xfz <somewhere>/wordpress-data.tar.gz
cd wp-content/wp-uploads
tar xfz <somewhere>/wordpresss-uploads.tar.gv

しかたないので、そこ(/var/www/html)を永続化のvolumeとしてマウントすることにする。でもその前に、どうやらWordpressに登録してあるDBの接続情報が違っていたようなのでwp_config.php内のdefine( ‘DB_NAME’, ‘wordpress’ ), define( ‘DB_USER’, ‘root’ ), define( ‘DB_PASSWORD’, ‘root’ ); define( ‘DB_HOST’, ‘172.17.0.1’ ); を修正する。

で、wordpress containerを立ち上げる。

sudo docker run -v /var/www/html/:/var/www/html --name momose-wordpress -d miscmemo-wordpress-latest

ここにhttp://172.17.0.3/で繋げられればめでたしめでたし。

今後

• ここらへんのcontainerをdocker compose対応にする
• 定期的に止めて、中の埃を掃除する

今回のベッド脇ワイヤレス充電スマホホルダ導入の要求は以下のような感じ

• この頃のiOSで使える充電時にロック画面で横向きにすると時計とかが出てくるスタンバイモードを夜通し使いたい。ふと目覚めた時に時間確認しやすい

これをするために以下のような詳細要求

• 寝ぼけてコードに引っかけると嫌なのでMagSafeで充電。横向け充電
• 幅6cmほどのヘッドボードに固定して設置できること。置くだけだと寝ぼけて隙間にiPhone落としたりスタンドを落としたりするかもしれない。

これだけだとそれほど奇妙な要求事項でもないと思うのだが、こういう製品が意外とない。

Magsafe充電するスタンドはもちろんたくさんある。だが大体置くタイプで、幅(この場合は奥行きか)6cm程度に置けるものはほぼない。ただ固定となると粘着マットなどをつけても十分かどうかが怪しい。

クリップで固定するMagsafeスマホスタンドというのもある。が、この場合のMagsafeは磁石で保持するだけで充電機能はないものがほとんど。Amazonでは最後までこのタイプで充電機能がついているものは見つけられなかった。

これらを満たした製品は見つかっていなかったが、Seriaで百円のクリップ式で自在アームのついたスマホスタンドを見つけた。価格的にもこれならダメもとでも試せるととりあえず購入。スマホを固定する部分もクリップ式。最近のiPhoneはサイドにもボタンがたくさんあるので何も考えずに挟んでしまうと変なところを押して緊急通報モードとかになってしまうので、挟むのにも少し気を使いあまりお手軽ではないが、とりあえずのソリューションとしてしばらく使ってみた。

相変わらずAmazonや実店舗ビックでは要求を満たす製品は見つけられなかったのだが、そういえばセリアのスタンドのスマホ固定部はジョイントボールでアームと繋がっていることを思い出した。Amazonで特に車載を意識したMagSafe充電付きスタンドを見てみるとジョインとボールで繋がっているものも時々ある。これはボールの径が合えば意外とつくんじゃないかということで、ある製品のレビューとかを見てみたら17mmの標準的なボールということだった。セリアのスタンドのボールもざっくり定規で測ってみると大体17mmくらいに見える。

ということであまり高くもないのでこれを買ってみた。

早速もともと車のエアコン吹き出し口に装着するアタッチメントをはずし、セリアのスタンドのジョイントボールにつけて見るとピッタリであった。ベッドのヘッドボードにスタンドのクリップで挟み、magsafe充電器に通電させれば、横置きスタンバイモードとなり、まさに望んでいたソリューションが実現できた。

想定通りのものができて大満足だが、使い始めるといくつか気になることもある。

• 通電中はいつも充電器のリングが白く光っている。車で使う用途の時はこれでいいのかもしれないが、ベッド脇にあると全く使わない昼間でも光っている。なんか電気が勿体無い気がしてしまうので、毎朝iPhoneを外すと同時に充電器に刺さっているUSBコネクタも外してしまう
• MagSafeへの磁力の強さ。裸でくっつけると結構丈夫で両手でないと外せないくらい強い。一方Daisoだかワッツだかで買った110円ケースをつけたままだと落ちはしないがだいぶ磁力が弱まっている。充電もできるし落ちるわけではないし、むしろ外すときは片手でも行けるのでこれの方がいいような気もするが、大地震の時は簡単に落ちるような気もする。どっちにすべきは実は悩ましい。

まあとりあえず今は満足ということで。