カテゴリー: 未分類 Page 1 of 18

カレーの戦略。

美味しいお店のメニューの狙いを見るのが好きです。

ある日にいただいたカレーの戦略性をこっちで勝手に推理してみます。

見た目は本当に日本の家のカレー。

  • ジャガイモ
  • にんじん
  • タマネギ

違いがあるとすれば福神漬けの代わりに細切り唐辛子。まずは食べてみます。

「肉」

でした。それも普通にお目にかかれないような圧倒的な牛肉の旨味と歯ごたえ、筋の柔らかさがこれでもかと出てきます。

そして飛び込んでくるほくほくのジャガイモとにんじん、ジャガイモの甘みがご飯と一体化。

そして、やや辛のスパイスが刺激し、全てを平らげてくれます。

この店の狙い、推測

ここで、一つ謎が出てきました。なぜこの店は、この牛肉で勝負ができるカレーを

  • おしゃれなカレーポットに入れず
  • 奇をてらわない平皿盛りで
  • 日本のカレーの見た目にしたのか

です。それは、この「圧倒的な牛肉」を強烈に意識させるためではないかという仮説。

どうしたって人はバイアスに捕らわれます。そこで高級店のカレーのスタイルで出てくれば「さすがは高級店」と、比較対象が別のものになります。

しかし、店のカレーが、こちらのように家庭的な見た目ならば、どうしたって「家のカレーとどう違うのか」の確固たる評価軸が出てきます。

その上で「肉が違う。この肉の出し方は自分には難しい」と思わせる戦略。

正直、普段の手作りカレーが一歩下がるような感覚でした。つまりこれは、味の美味しさで勝負するのはもちろん

「あなたの普段食べているカレーとは素材が違います」

をすり込むための擬態、とも取れそうです。実際問題、もう一度このカレーを食べたいという気持ちにあふれていますので。

『メリー・ポピンズ リターンズ』

Cover is not the book / 心が目に見えないように本も
So open it up and take a look / 表紙の美しさに騙されちゃダメ
'Cause under the covers one discovers / 中身読んだらやさしい王様
That the king may be a crook / 詐欺師だとわかるかも

を地で行くカレーでした。

食事と海鮮。

素晴らしい食事を戴きました。

お作り

季節の盛り合わせ。特にしめさばに感動。

豚の角煮

クリアなあく取りと、しっかりと染みこんだ豚肉、とろけるような脂身。

鮎の塩焼き

この焼き色はもちろん、頭も骨もしっかり食べられて詰まらない絶技です。

厚揚げ

一番感動したのは実はこちら。「その場で揚げた」真に出来たての厚揚げ。なので、普通に口にした瞬間に熱々の豆腐が飛び出てきて火傷寸前でした。

なので、その香ばしさが更に薬味とひき立て合います。

ジャガイモの素揚げ

好物だからと挙げてくれました。バターと塩のみという潔さがジャガイモのほくほく感を引き立てます。

稲庭うどんと野菜点

食事の締め。正義の取り合わせという感じ。

手まり寿司

感動したというしめさばのフィードバックをそのまま手まりにするという技術と心配り。

と、実に素晴らしい食事をいただけました。

『IDEA SPHERE』3つのバイアス

『黄色い顔(シャーロック・ホームズの思い出)』の象徴的な言葉。

「ワトソン」ホームズは言った。「もし僕がちょっと自分の能力に自信過剰になっていると気付いたり、事件に対して必要なだけの努力をしていないようだったら、僕の耳元で『ノーベリ』とささやいてもらえないだろうか。そうすれば僕は大いに君に感謝するだろう」

これ、

  • 探偵とは言え失敗する
  • キャラクター造形の中でのウィークポイントを晒すことで更なる魅力を生む(ギャップ萌え)

だと思っていましたが:まさに、これと同じような状況が起きたので自戒3割、言い訳7割でこのテキストを残します。

起きたこと

私が過去に初期設定を案内してアカウントまで譲渡したWordpressサイトに話は遡ります。

そのサイトの持ち主から「急にWebサイトに繋がらなくなった」というヘルプ要請。「アプリには入れるが更新はできない」ということ。

取り急ぎ「情報を集めるだけ集めて伺う」と返して状況確認です。

初動

  • Webブラウザでの挙動

そのサイトのURLを入力。403エラーが出ます。

  • curlでの挙動
curl -I https://hoge.example.com
HTTP/2 403 
server: nginx 
date: Fri, 19 Jun 2026 05:28:52 GMT

間違いなく403エラーです。

更に

  • index.php
  • /wp-login.php
  • /wp-admin

も同様に403エラーになりました。

考えられる可能性と却下していった理由

料金未払い

これはないと考えていました。なぜなら、クレジットカードの自動更新です。洗い替えなどもあるだろうと真っ先に却下。

それ以上に、そのドメインでWHOIS検索したところ2027年まで有効。しかも、そのネームサーバは仮想サーバを向いています。

ドキュメントルートが読めない。

  • ディレクトリのパーミッション
  • 所有者
  • ドキュメントルートの設定

例えばpublic_htmlが何らかの操作で700になってしまうと、nginxが403を返します。

WAF偽陽性による.htaccessの書き換え。

「アプリを起動したら更新ができなくなった」から来る推察。

であれば、WAFによってアクセスが遮断された。偽陽性です。(筆者も散々経験がありますが)

WAFが下手に.htaccessを書き換えることでアクセス制限を喰らった

つまり、更新の時に何かしらの操作ミスがあって一斉に403を返したのではないか。

だとすれば

  • 仮想サーバの管理画面に入る
  • 下手をすればサイトの再構築

あたりも考慮に入れて、その持ち主のところを訪れます。

原因と復旧

訪れるやいなや、

「料金督促メール来てました!」

という連絡。つまり、「私が最初に斬って捨てた」原因だったのです。

この落とし穴は、ドメインとサーバーの契約期間が異なっていたことでした。

  • ドメイン:
    • 数年単位で契約済み
  • サーバー:
    • 単年契約で更新漏れ

その結果、

  • WHOISは正常
  • DNSも正常
  • ドメインも生きている
  • しかしWebサーバーは契約停止状態のため403を返す

という、一見するとWordPress障害にも見える状況が出来上がっていた次第。そして、決済を確認後、

curl hoge.example.com
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://hoge.example.com/">here</a>.</p>
</body></html>

が返ってきましたし、サイトも完全復旧です。

真っ先に外した「なぜ支払いが行われなかったか」

これも実に単純でした。

「クレジットカードを紛失して再発行した」

という、極めて人間らしいミスでした。この督促メールも

「大量のメールに紛れて見落としていた」

種が分かってしまえば実に単純。これを忘れて

  • htaccess
  • WAF

などを疑ったのが私の技術バイアスであり真の問題は

「サーバー契約は本当に有効か?」

というチェックが抜けていたことでした。そして、その契約切れと自動更新がオフになって苛理由は

クレジットカード再発行

だったという物理的な問題に抜けていました。

  • 「自動更新の設定」
  • 「決済手段が現在も有効か」

は別問題です。ところが、人間は

自動更新 = 更新される

と無意識に補完してしまいます。

実際には、自動更新は「決済に成功すれば更新される」であって、

  • カード期限切れ
  • カード再発行
  • 利用停止
  • 限度額超過

などで、静かに失敗することがあります。

技術スタックの落とし穴

利用者
↓
WordPress
↓
PHP
↓
Apache/nginx
↓
サーバー契約
↓
DNS
↓
ドメイン契約

という技術的な例で解釈をしていましたが、実際の原因は「サーバー契約」というアプリケーションより一段下の状況だったのです。

デブリーフィングという名の言い訳。

今回の一件で唯一良かったと思ったところは、

この事態を重く受け止め、どういう結果でもいの一番に駆けつけるという「速度は誠意」を見せられたこと。

しかし、問題はそれ以前にあります。

バイアス1:技術バイアス

ここのところ私は

  • Webサーバ周りのチューニング
  • AIクローラーとの戦い
  • セキュリティ

といった技術バイアスに溺れていました。ですから、この問題も同じに違いないという利用可能性ヒューリスティック(Availability Heuristic)に捕らわれていたこと。

これが第一の問題。

バイアス2:心理的バイアス

実写版『カイジ 人生逆転ゲーム』での好きな言葉があります。

「利根川‥‥
 俺がヘビに見えたか‥‥‥?」
 「ああ‥‥‥
  ヘビだろうが‥‥‥‥!」
「そうか‥‥‥
 なら お前こそヘビなんだ‥‥‥‥
 こんなふうな物言わぬ心理戦は
 鏡を見るようなもの‥‥‥
 相手の心を読もうと‥‥
 必死に考えるつもりが‥‥‥
 気がつけば自分だったらどうするかと考えている‥‥‥
 つまり俺がヘビに見えたなら‥‥‥
 お前こそヘビなんだ‥‥‥」

つまり、相手の初歩的な設定漏れや状況の変更という前提を忘れ、技術に溺れていました。これが深刻です。

上記でも述べたように、私は「請求忘れ」という一度は正解に導いていたのに「自動更新設定はしているはず」として、真っ先に切り捨てたこと。しかし、よくよく考えれば

  • カードの有効期限切れ(洗い替えをしていなければ)
  • 今回のカードの再発行
  • 残高不足(支払い能力)

というのは容易に起こりえます。こういう人間的な問題を「そんなことはまずないだろう」とした心理的なバイアス。このカイジの言葉で言うのなら「このサーバで何をしたのか」と鏡を見るように考え込み、自分が起こしがちなミス=相手のミスと考えていたこと。

バイアス3:生存バイアス。

最後に、「今までも解決してきた。だからこれもすぐに解決できる」という生存バイアスです。それこそ、私がメモとして利用しているGrowiのトップページの

Those who survive a long time on the battlefield start to think they are invincible.
I bet you do too, buddy.

"不死身のエースってのは戦場に長く居たものの過信だ"
"お前のことだよ相棒"

という、『ACE COMBAT ZERO』の言葉を真に噛みしめた、が今日の結論ですね。

ビタースイートな結末

と、上記、最初に述べたような言い訳の方が多い失敗談となりましたが、

成功体験が積み重なると、人は「今回もきっと高度な技術的原因だ」という思考になりやすいです。そして、そこが一番の慢心の結果です。

そして今回の真相はカード再発行で自動更新が止まっていた。あまりにも「人間的」でした。

余談、と言うか警句

この出来事が起きた日、夢枕に亡父が立ったのです。生前、父は

いかなる敵にも敬意を払え。その上で全力で叩き潰せ

とよく言っていて、没後10年目に夢枕に立ち

この言葉の真意は、「敬意を払わないとどこかに油断・慢心が生まれる。それが敗因に繋がる」という意味だからな

と但し書きをしました。なので、今回の物言わぬ夢枕は

この言葉を理解しているのか?

を問うものだったかと思います。即ち、この、技術的に物事を解決したため、その本質を見失っているぞという警告の予言めいた出来事だったのかな、と改めて思いました。

Apacheモジュール「mod_alias」解説。

筆者がWebサイトの防衛に、そして過剰にクロールをするボットを他の場所へとご案内するために用いているmod_aliasのご紹介です。

というのも、筆者がこれから述べる対クローラー迎撃システム「Jailhouse Lock」には、このモジュールが必要だからです。

1. mod_aliasとは何か?

mod_aliasは、リクエストされたURLをファイルシステム上の特定の場所にマッピング(転送・代替)したり、別のURLへリダイレクトしたりするための、Apacheの標準モジュールです。(そのため、多くのディストリビューションではインストールと同時に機能が有効化されています)

主な役割は以下の2つです。

  • エイリアス(別名)の設定:
    • ドキュメントルート(公開ディレクトリ)の外側にあるフォルダを、あたかも内側にあるかのようにURLに紐付けます。
  • 単純なリダイレクト:
    • 特定のURLに来たアクセスを、別のURL(別ドメインなど)へ転送します。

代表的なディレクティブ

  • Alias /images /var/www/shared/images (URLの/imagesを特定のフォルダに対応付ける)
  • Redirect permanent /old.html http://example.com/new.html (永続的な301リダイレクト)

2. mod_rewrite との違い

どちらも「URLを操作する」という意味では同じですが、そのアプローチと内部処理の複雑さに大きな違いがあります。

項目mod_aliasmod_rewrite
コンセプト単純なマッピングとリダイレクト強力なURLカスタマイズと書き換え
判定基準単純な前方一致(接頭辞マッチ)正規表現、Cookie、環境変数、時間など
処理速度非常に高速(軽量)やや低速(ルール毎に正規表現エンジンが動く)
設定の難易度簡単(初心者向け)複雑(記述ミスで無限ループが起きやすい)
主な用途フォルダの共通化、単純なサイト引っ越し綺麗に整形されたURL(Smart URL)の実現、複雑な条件分岐

最大の違い:正規表現と条件分岐の有無

mod_aliasは、URLの「先頭が一致しているか」という単純な比較しか行いません。

一方、mod_rewriteは「リクエストがGoogle Chromeから来たら」「平日の昼間なら」「Cookieに特定の文字が含まれていたら」といった、高度な条件分岐(RewriteCond)や、正規表現を使った自由自在なURLの作り替え(RewriteRule)が可能です。

3. mod_aliasが「優れているパターン」

「mod_rewriteがあれば、mod_aliasはいらないのでは?」と思われがちですが、Apache公式も「単純なタスクであれば、mod_rewriteではなくmod_aliasを使うべき」と推奨しています。

mod_aliasを選ぶべき(優れている)具体的なパターンは以下の3つです。

① サーバーのパフォーマンス(速度)を最優先したいとき

mod_rewriteは、リクエストが来るたびに複雑な正規表現エンジンを動かすため、CPUリソースを消費します。

大規模サイトやアクセスが集中する環境で、単なるURLの転送やフォルダの紐付けを行う場合、mod_aliasの方が圧倒的に処理が軽く、サーバーの負荷を抑えられます。

② ドメイン全体の引っ越しや、単純なURL変更(リダイレクト)

サイトのリニューアルで、古いページから新しいページへ1対1で転送したい場合や、古いドメインから新ドメインへ丸ごと転送したい場合は、mod_aliasの Redirect で十分対応できます。

  • サイト全体を新ドメインへリダイレクト(mod_alias)
Redirect permanent / https://new-example.com/

これをmod_rewriteで書くと記述が複雑になり、設定ミスのリスク(無限ループなど)が高まります。

③ 複数サイトで画像やアセット用のフォルダを安全に共有したいとき

例えば、サーバー内の /var/www/common_assets/ というフォルダを、複数のWebサイトで /assets というURLで共通利用したい場合です。

  • 安全かつ高速に共通フォルダをマッピング(mod_alias)
Alias /assets /var/www/common_assets

mod_aliasは設定がシンプルなため、ヒューマンエラーによるセキュリティホールの発生(意図しないシステムファイルの公開など)を防ぎやすいというメリットもあります。

それぞれのイメージ

1. mod_alias のシーケンス(単純・高速)

URLの書き換えは行わず、リクエストされたURLの先頭(接頭辞)だけをチェックして、即座にファイルパスへマッピングするか、リダイレクトを返すシンプルな流れです。

sequenceDiagram autonumber participant Client as クライアント (ブラウザ) participant Core as Apache コア (リクエスト受付) participant Alias as mod_alias participant FS as ファイルシステム Client->>Core: HTTPリクエスト (例: /images/logo.png) Core->>Alias: URLの評価を依頼 Note over Alias: URLの先頭(接頭辞)が<br>設定と一致するか単純比較 Alias-->>Core: マッピング先を返却<br>(例: /var/www/shared/images/logo.png) Core->>FS: 指定されたパスのファイルを読み込み FS-->>Core: ファイルデータ Core-->>Client: HTTP 200 OK (レスポンス返却)

2. mod_rewrite のシーケンス(複雑・高機能)

リクエスト受付後、内部でループ(再エントリー)が発生する可能性や、条件判定(RewriteCond)のステップが挟まるため、柔軟ですが処理の工程が多くなります。

sequenceDiagram autonumber participant Client as クライアント (ブラウザ) participant Core as Apache コア (リクエスト受付) participant Rewrite as mod_rewrite participant FS as ファイルシステム Client->>Core: HTTPリクエスト (例: /user/profile) rect rgb(240, 245, 255) Note over Core, Rewrite: [書き換えループの開始] Core->>Rewrite: URLの評価を依頼 Note over Rewrite: 1. 正規表現でURLパターンをマッチング Note over Rewrite: 2. RewriteCondの条件をチェック<br>(Cookie、ブラウザ、環境変数など) Rewrite->>Rewrite: 3. URLの書き換え処理を実行<br>(例: /index.php?mod=user&act=profile) Rewrite-->>Core: 書き換え後の内部URLを返却 end Core->>Core: 内部リダイレクト(新しいURLで再処理) Core->>FS: 最終的なスクリプトやファイルを呼び出し FS-->>Core: 実行結果・データ Core-->>Client: HTTP 200 OK (レスポンス返却)
  • mod_alias(図1):
    • 判定が「前方一致のみ」の一方通行であるため、ステップ数が少なく、非常に高速に処理が終わります。
  • mod_rewrite(図2):
    • 条件チェックのフェーズ(薄い青枠の部分)が多く、さらに書き換えたURLでApache内部で「もう一度リクエストを処理し直す(内部リダイレクト)」という挙動が発生するため、機能性と引き換えに処理が重くなる構造が見て取れます。

まとめ:使い分けの基準

それぞれの使い分けです。

  1. まずは mod_alias で実現できないか考える。(単なる転送、単なるフォルダの紐付けなど)
  2. 「クエリストリング(?id=123など)を判定したい」「特定のブラウザだけ除外したい」「正規表現でURLを激しく書き換えたい」といった複雑な要件が出てきたとき初めて mod_rewrite を導入する。

どちらが優れているか、否かという問題ではなく、これは速度の問題です。

漫画『MASTERキートン』に以下のやりとりがあります。

「やめておけ」
「…………」
「拳銃の方が、ナイフよりも速いと思っているんだろう。
 だが、拳銃はデリケートな道具だ。
 弾が出ないかもしれないし、
思い通り的に当たるとは限らん。
おまけに拳銃は、
抜き、構え、引き金を引くまでに三動作(スリーアクション)……
 その点ナイフは、一動作(ワンアクション)で終わる。
この距離なら、絶対に俺が勝つ!!
どうする? それでもやってみるかね?」

これは「至近距離でのナイフの有用性」を示したものであり、実際にその通りだという説得力があるものです。(調査結果はこの記事です

つまり、mod_alias は「できることが少ないから速い」のではなく、「役割を絞っているから速い」のです。

mod_aliasはナイフの速度。mod_rewriteは拳銃のような強力さがあります。「適切な距離感」でこれらのツールの利用、併用を行いましょうというお話しです。

卵焼きメモ2026年6月版。

一時的に今まで使っていたスープジャー(汁物)の運用を一時的に止めました。

そんな中で美味しい卵が手に入ったので、また卵焼きの熱が高まりました。

今回着目したのはこちら。

チーズです。そもそもチーズオムレツがスタンダードになるぐらい、チーズと卵の相性は抜群です。

醤油系とも相性がいいのは想像に難くないでしょう。

反面、焼くのにコツがいりますが

しっかりきれいに焼けました。

できあがったのはこちら。一段弁当は「これぞ弁当」な見た目になるのもお気に入りです。

2026年の紫陽花。

最も好きな花の一つである紫陽花。名所を2つほど。

飛鳥山公園

王子公園、飛鳥山。

こちらは電車沿線との無機質な取り合わせが素晴らしいです。

本土寺

千葉北西部の名刹、本土寺。

今度は寺の広い境内を活かした密度が魅力。

曇り空だからこそ似合う花があるから梅雨は楽しみまで見えます。

RHEL9系LinuxにMySQLを導入

RHEL9系ディストリビューション(Rocky Linux 9.7)にMySQLを導入したときのメモです。

そもそもDB(データベース)とは何なのか?

一言で言えば、「特定のルールに従って、整理整頓されたデータの集まり」です。

言うなれば「超高性能な図書館」のようなものです。
閲覧者、借りている人の帳簿を司り、膨大な本から一瞬で目的の1ページを探し出し、同時に何百人もの人が本を借りようとしても混乱が起きないように管理されています。

MySQLなどの「RDBMS」

MySQLは正確には「リレーショナルデータベース管理システム(RDBMS)」と呼ばれます。

  • リレーショナル(関係性): データを「表(テーブル)」の形式で管理し、複数の表を関連付けることができます。
  • 管理システム: データそのものではなく、データを操作・管理するためのソフトウェアのことです。

何を司るのか(役割と機能)

MySQLが担っている主な役割は、大きく分けて以下の4つです。

  • データの格納と検索(CRUD)
    • データの登録(Create)、参照(Read)、更新(Update)、削除(Delete)の4つを、膨大な量の中から高速に行います。
  • 整合性の維持(つじつまを合わせる)
    • 「注文データはあるのに、注文したユーザーのデータがない」といった矛盾(バグの元)が起きないよう、データの整合性を厳しく見張ります。
  • 同時実行の制御(排他制御)
    • 例えば、残り1つの商品を2人が同時にクリックした際、どちらか一方が確実に買えるように調整し、「1つしかないのに2人に売れてしまった」という事故を防ぎます。
  • セキュリティと権限管理
    • 「この人は閲覧だけ」「この人は編集もOK」といった具合に、大切なデータへのアクセスをコントロールします。

なぜ大事なのか(存在理由)

なぜExcelファイルやテキストファイルで管理するのではダメなのでしょうか?

データの爆発に対応するため

テキストファイルだと、100万件のデータから1件を探すのに上から順に読み込む必要があり、時間がかかりすぎます。DBは「インデックス(索引)」という仕組みを持ち、瞬時にデータを見つけ出せます。

データの「信頼性」を保証するため(ACID特性)

銀行振込を想像してみましょう。

  1. Aさんの口座から1万円引く
  2. Bさんの口座に1万円足す

もし「1」の直後にシステムがダウンしたら、1万円が消えてしまいます。

こうならないよう、DBには「トランザクション」という仕組みがあり、「すべて成功するか、すべてなかったことにするか」のどちらかしか認めません。これが社会インフラを支える信頼性の正体です。

複数のプログラムから共有できるため

Linuxサーバー上で動く

  • Webサイト
  • スマホアプリ
  • 管理画面

など、バラバラな入り口から入ってくる要求を、一つの窓口(MySQL)が交通整理して処理してくれます。

まとめ

MySQLは、システムにおける「記憶の番人」です。

  • DBとは: 整理されたデータの基地。
  • 司るもの: データの出し入れ、矛盾の防止、アクセスの交通整理。
  • 大事な理由: 膨大なデータを「速く」「正確に」「安全に」扱うため。

LinuxにDBを入れるということは、そのサーバーに「確かな記憶力」と「厳格な管理能力」を持たせるということに他なりません。

ここまで踏まえ、LinuxにDBを入れていきましょう。

インストールとディレクトリ準備

MySQLサーバーのパッケージを導入し、MySQLサービスが利用するディレクトリの権限をあらかじめ適正化。

  • MySQLサーバのインストール
sudo dnf install -y mysql-server

サービスの起動と初期ログイン

MySQLサービスを有効化し、初期状態でのログインを確認。

  • サービスの有効化と起動
sudo systemctl enable --now mysqld
  • 初期ログイン(MySQL 8.0では初期状態はパスワードなし)
mysql -u root

rootパスワードの確定

ログイン直後にMySQLのroot顕現のパスワードを設定します。

※先ほどのDBの話に戻ります。DBは「システムのデータそのもの」を管理します。先ほどの図書館の例で言うと

  1. 利用者
  2. 所蔵されている本
  3. その本がどこにあるか(貸し出し中か、書架か)
  4. どのようなジャンルか、作者は?

まで全て記録されている状態です。ここで、例えば、悪意ある者が「『ハムレット』の作者は『クリストファー・マーロウ』である」としたい場合、悪意ある者はそのような行為ができてしまいます。

そのため、攻撃者はDBのroot権限を真っ先に奪います。それを防ぐためにも最初にrootパスワードを設定します。

  • rootユーザーに対して新パスワードを適用
ALTER USER 'root'@'localhost' IDENTIFIED BY 'Your_Strong_Password';

パスワードは自分の環境に合わせます。パスワード設定後、そのデータを適切な方法・手段・保管場所に格納してください。

  • 権限設定
FLUSH PRIVILEGES;
  • コンソールから抜ける
EXIT
  • パスワードで入れるかを確認
mysql -u root -p

設定したパスワードでログインできることを確認します。確認後、EXITで抜けます。

セキュリティの堅牢化 (mysql_secure_installation)

対話型スクリプトを用い、商用・本番環境に耐えうるセキュリティ設定を一括で適用します。 以下のように行ってください。

Enter password for user root:

で、先ほどのrootパスワードが聞かれます。

その後、いくつかの確認事項があるのでYで答えます。

設定項目内容理由
Remove anonymous usersYes誰でも接続できる穴を塞ぐため
Disallow root login remotely?Yesローカル管理に限定し攻撃経路を遮断するため
Remove test database and access to it?Yes不要なオブジェクトの排除
Reload privilege tables now?Yes設定内容を有効化するため

海鮮の昼食。

毎年恒例、この時期の食事会に参加しました。

まず運ばれたのが山菜の天ぷら。

  • タラの芽
  • しそ
  • タケノコ

などの春の味覚。

岩牡蠣のグリル。焼いてなおこの大きさに驚愕でした。

メインの海鮮丼。丼と言うよりは刺身の盛り合わせであり、中トロのキッツケの鋭さも料理人の技量を窺えるものです。

ご飯が足りないという嬉しい悲鳴もあったほど。

吸い物も春の味覚たるタケノコに海老しんじょう入り。

その他デザートもあり、非常に満足いくものでした。

Node.jsの混在環境の解消。

Ubuntu24.04サーバでGrowiを運用していた際に、2系統のNode.jsが独立して存在していた状況が発生しました。

環境

通常ユーザー環境

  • パス: /usr/local/bin/node
  • バージョン: v20.18.0(Nodesource経由のシステムインストール)
  • 状況: pnpmなどの最新ツールが利用不可、または古いバージョンを参照。

rootユーザー環境

  • パス: /root/.nvm/versions/node/v24.14.1/bin/node
  • バージョン: v24.14.1(nvm経由)
  • 状況: 最新版がインストールされているが、systemdなどのサービスから正しく参照できていない可能性があった。

そもそも論として

「各ユーザーにnvmをインストールすればいいのでは?」は確かにその通りですが、筆者サーバーはWebサーバ。つまり、nodeを主に用いるのはGrowi環境であり、

  • rootに最新Node.jsを使わせたい。
  • そして、sudo配下できちんとroot環境でのNode.jsを使いたい

という状況。これを直していきます。

さっくりとした手順

  1. 元々のNode.jsをアンインストールします。
  2. root環境の一本化と最新化を行います。
  3. ついでにGrowi起動スクリプトの動的かを行います。

Node.jsをアンインストール

※これを用いるまでに

sudo su -

の後、

which node

を実行し、

/root/.nvm/versions/node/v24.14.1/bin/node

rootが参照しているNode.jsが.nvm経由であることを確認し、

exit

でroot環境から抜けます。

  • 一般ユーザーが持つNode.jsをアンインストール
sudo apt-get purge -y nodejs
sudo rm -rf /usr/local/bin/node
sudo rm -rf /usr/local/bin/npm
sudo rm -rf /usr/local/bin/npx
sudo rm -rf /usr/local/bin/pnpm
  • hashをクリア
hash -r

一般ユーザーのNode.js系のプログラムの向き先を合わせる

  • Node.jsの向き先変更
sudo ln -sf /root/.nvm/versions/node/v24.14.1/bin/node /usr/local/bin/node
which node

/usr/local/bin/nodeを確認。

node -v

v24.14.1などを確認。

  • npmの向き先変更
sudo ln -sf /root/.nvm/versions/node/v24.14.1/bin/npm /usr/local/bin/npm
which npm

/usr/local/bin/npmを確認。

npm -v

11.13.0などを確認。

  • pnpmの向き先変更
sudo ln -sf /root/.nvm/versions/node/v24.14.1/bin/pnpm /usr/local/bin/pnpm
which pnpm

/usr/local/bin/pnpmを確認。

pnpm -v

10.33.2などを確認。

Growiの起動スクリプト修正

Growi起動スクリプト(growi-start.sh)を修正し、rootが見ているデフォルトバージョンを参照するように修正しました。

DEFAULT_NODE_VER=$(cat "$NVM_DIR/alias/default")
export PATH="$NVM_DIR/versions/node/$DEFAULT_NODE_VER/bin:$PATH"

この修正により、同じ場所を見るような運用が可能になります。

それでも残る問題点

将来的にnodeのバージョンを上げた場合、一般ユーザーでも

sudo ln -sf /root/.nvm/versions/node/v25.xx.yy/bin/node /usr/local/bin/node

のように帰る必要がありますが、そこは割り切りましょう。

Cockpitを用いたVMインストールメモ。

機会があったのでメモです。

前提

  • LinuxサーバにKVMがインストールされていること。
  • ISOイメージをサーバ内に格納していること。
  • Cockpit(Webブラウザ経由でLinux各種操作が行えるサービス)がインストールされていること。

1. ホスト側での事前準備(ターミナル操作)

仮想マシン用の論理ボリューム(LV)を作成します。

  • ボリュームグループ(VM)内に500GBのLV(ホスト名)を作成
sudo lvcreate -L 500G -n vm_host VMdisk

2. Cockpit ストレージプールの作成

予め作成されていたcockpitにブラウザからログインします。

  1. 「仮想マシン」 > 「ストレージプール」 を開く。
  2. 「ストレージプールの作成」 をクリック。
    • 名前: VM
    • タイプ: LVM ボリュームグループ
    • ターゲットパス: VM (※/dev/を含まないVG名のみを入力)
  3. 「作成」 をクリック。

3. 仮想マシンの作成と詳細設定

  1. 「仮想マシン」 > 「VMの作成」 をクリック。
  2. 基本情報: 名前、インストールタイプ、メモリ(8GB)を入力し、一旦作成する。
  3. CPUの編集:
    • vCPU最大値: 4 / vCPU数: 4
    • ソケット: 2 / ソケットごとのコア: 2 / コアあたりのスレッド: 1
  4. ディスク(LVM)の割り当て:
    • 既存のディスクがあれば編集、または追加。
    • ソース: 既存のストレージ
    • パス: /dev/VMdisk/vm_host を選択。
  5. インストールメディア(ISO)の追加:
    • 「ディスクの追加」 でホスト上のISOファイルを選択。
  6. ブート順序の変更:
    • cdrom を追加し、最上位(1番目)にドラッグして移動。
  7. ネットワークの設定:
    • インターフェース: Bridge to LAN を選択。

4. インストールの実行

  1. 「インストール開始」 をクリック。
  2. 「コンソール」 タブを開き、OSのセットアップを進める。

Page 1 of 18

Powered by WordPress & Theme by Anders Norén