ブログ

作業事例の紹介です。
CentOS5上で動作していた社内システム(他社様で開発したもの)の更新作業を行いました。

かなり以前(2009年頃?)に構築された社内システムが構築当初からのCentOS5サーバー上で動作していたのですが、CentOS5もだいぶ前にEOL(End of Life)になっており、今後の機能開発やメンテナンスのためにもOS類を新しいものに更新したいということでお問い合わせをいただきました。

いつもはPHPのシステムを扱うことが多いのですが、今回はめずらしくPerlを使ったシステムでした。

私は普段の開発作業はmacOS上のFedora仮想マシンでやることが多い。 今まではVMware Fusion上の仮想マシン(VM)にFedoraをインストールして作業していたのだが、訳あって最近Parallels Desktop26を購入してそちらに新たに環境を構築した。 ただ、Parallels Desktopは料金体系がサブスクモデルなので、VMWare Fusionに簡単に戻すことができるのか確認しておきたかった。

これは、Parallels Desktop の Fedora仮想マシンをVMware Fusionに変換する雑な手順メモだ。

「Apple ContainerでLAMP環境を作る」の記事でコンテナにコンテナ(ホスト)名でアクセスできるようにするにはDNSドメインの設定が必要と書きました。

以下のように設定します。

% sudo container system dns create box
% container system property set dns.domain box

公式のチュートリアルにもさらっと説明されています。 上記コマンドをおまじないとして実行しておくだけでも問題なく使えるのですが、 なぜドメインを作成する必要があるのか？どういう仕組みで名前解決されているのかを理解しておくと応用が効きます。

今回はDNSドメインの作成とはなにか、デフォルトドメインを設定するとどうなるのか、どういった仕組みでコンテナの名前解決がされているのかを解説します。

先日リリースされたmacOS TahoeからContainer機能が正式に使えるようになったので、ちょこちょこと遊んでいました。

OCI（Open Container Initiative）準拠ということで既存のコンテナイメージも使えるし、Dockerfileもdockerと同じように記述してイメージを作成できます。 CLIもdockerと似たようなインターフェースになっているので、戸惑わずに使えるのがいい感じです。

以前、ネストしたlocation設定があった場合、どのようにlocationが選択されるのかを解説しました(こちら)。 今回は、あるlocationが選択された場合、その親のlocationのconfigが子のlocationにどのように継承されていくのかを解説します。

Laravelのフォームビルダー(*1)は、これまで何度か変わってきました。

• 初期の頃(～laravel4?)はLaravel内に存在した
• Laravel5からはLaravel本体から削除され、別パッケージのlaravelcollective/htmlとして分離された
• laravelcollective/htmlも2023年秋頃にサポート終了を迎えた
• 後継としてspatie/laravel-htmlがあるが、laravelcollective/htmlとは全く互換性はない

少し前からAnthropicのAPIを使って簡単なものを作りちょこちょこと遊んでいたのだが、最近はMCP(Model Context Protocol)が話題になることが多い。 VS CodeからMCPサーバーの呼び出しができるようになったことで一気に広まったようだ。

Nginxでは特定URIへの設定を行うのにlocationディレクティブを使います。 locationはぱっとみ簡単そうですが、実のところどの設定が適用されるのかルールが結構分かりづらかったりします。

さらに、このlocationはネストして指定することができ、ネストしてlocationをグループ化することで、 設定の重複記述を排除したり、URLのマッチングを減らしパフォーマンス劣化の懸念を回避できます。

年末あたりから仕事で使っているMacBookやらWindows PCを少しずつ入れ替えていました。 最新のMacBook ProだとCPUはM4になっているのですが、去年購入したMac StudioのM2 Maxに比べてどの程度速くなっているのかなど気になっていたので、手持ちのホスト間で雑に性能を測ってみました。

2024年2月にGoogleが迷惑メール対策を強化してから、メール送信に関してSPFの他にDKIMにも対応をした/し始めているところも多いのではないかと思います。

DKIMはメールヘッダーに電子署名を行い、受信側でメールヘッダーが改ざんされていないこと確認できるようにします。 これにより、受信者はメールがFromヘッダーを書き換えたなりすましメールではなく、正当な送信者から送信されたものであることを確認できます。