なんか週末は酒に飲まれて撃沈しっぱなしだったなぁ。調子が出ないまま、サーバーの変更に備えて文字コードのチェックとか、Apache2のセッティングとか。

結局FreeBSD-6.1なので、面白い。ほんとWINDOWSじゃなくて良かった。地方の本番用と環境を同じにもう一台もセッティング。こっちは192.168のローカル。

一枚のNICに複数のIPを割り当ててみる。IPエイリアスというんだそうだ。これはローカルなら好きにIPアドレスを使えるから便利かもしれんぞ。

ifconfig_NIC_alias0などと、alias0から指定すればいいらしい（ネットマスクは0xffffffff）…でも、これって192.168.0.1 と 192.168.0.2ならいいけど192.168.1.1とかだとひとりNATなんてことになるのかな。

でもって、...と書き連ねるだけでOKだった。

次にportで分けてみようと。

Listen 80

Listen 8080

NameVirtualHost 192.168.1.1:80

NameVirtualHost 192.168.1.1:8080

...

てな感じでOKだった。ネームベースでやるにはbindの設定が面倒だったんでまた今度…ていうか、ネームベースは自宅サーバーで検証済みなのでいいのだ。DNSがどうなるかわかってないし。

今さら、なんだろうけど、１枚のNICに複数のIPアドレスが割り当てられるって不思議なような便利なような。うちのネットワークでなにか遊びに使えないもんか。

うううむ。サーバーで遊びだすとほんときりがないなあ。

[更新]2026-02-04 10:45:16

忘れないように

ssh2(FreeBSD) と putty(WINDOWS)

メモ

まず FreeBSD のログインユーザーのホームで

$ ssh-keygen2

とやって公開鍵と秘密鍵を作成。パスワードを要求されるので、適当なパスワードを入力する。

.ssh2/

id_dsa_2048_a 秘密鍵

id_dsa_2048_a.pub 公開鍵

（よくわからんのだけど）とりあえずテキトーな名前にrename

hohoho_a

hohoho_a.pub

にでも。

そしたらば。

vi .ssh2/authorization

Key hohoho_a.pub

以上はログインされる側の設定。

ログインする側は、上記で作成した秘密鍵を持ってくる。大切なものなので決してftpなどで安直にネット経由で移動するようなマネはしないで、フロッピーなどの物理メディアで移動することを、強く推奨します…と見かけるのだけど、メンドーなんでftpで持ってきた。

putty.exeというターミナルを使用。puttygen.exeという鍵生成ユーティリティがあるので、それを使って、先ほど持ってきたhohoho_aを読み込む。

パスフレーズを要求されるので、鍵を作った時のパスワードを入力する。

その後putty用に保存する。*.ppk

putty.exeを立ち上げてSSH→認証のところに保存したキーを指定する

てことでssh2でのログインはできるようになる。

FreeBSD 同士の場合は、ログインする側の.ssh2/に

vi .ssh2/identification

Idkey hohoho_a

[19:27:00]

ううむ。につけてもapache2に複数sslを設定するのが不安やなあ。むこうのプログラマがやるという話だったのがいつのまにかお鉢がまわってきた空模様。

今日向こうに着いた機械のrootのパスワードを教えたら、パソコンの名前だと思い込んでた上「ああ、ルートっていう名前なんですね」と妙な独り合点。えーっと。unix系を触ったこともないのか。愕然。その時点で、ただの元エロ本屋のわたしが設定しなきゃいけなくなったも同然。rootで妙なことされたら、と思うと恐ろしい。こっそりパスワードを変更しておくかなあ。「あれ？ルートになれないって？おかしいなあ、あ、そういや、unixではよくあることらしいんだよ、調べるからそれまで我慢してね」作戦決行か。

root権限で/etc とか /var のファイルを触ったらシステムが異常になりやすいからね、え？そうだよ、unixって古くさい規格なんですぐに壊れるもんだよ、と軽く念押ししておいた。まったくナイスガイだ、やれやれ。

そういや業界の風習因習に「人月」という言葉があるんだそうだ。このプログラムでしたらン人月でン十万です、と。単純な話、ひとひとり拘束する時間単位。

だけど、それで請求するのはどうなんだろう。なんでおめえんとこの人件費をこっちが持たなきゃいけないんだ、と。小説もマンガも作品に対して対価・ギャラ印税を払う、とてもわかりやすい図。委託販売とか流通は複雑怪奇でうっとーしーけど、出版の現場は単純な業界だったんだなあ。

そんなこんなの週末ですな

[更新]2026-02-04 10:46:22

サーバーのセッティングだ、打ち合わせだといちんち。ここんとこの気温の上下と同じく右往左往なもんで効率が悪くていかん。

んなもんで、昨日の続きの写メールもとっちらかりながら、だ。

.qmail に | hohoho.pl などと書いておけば標準入力がスクリプトに渡ることはわかった。

問題はどうやってapache配下のページに書き込むか、だ。.qmailで受け取るユーザーはただのユーザーだし、書き込みたいディレクトリのパーミッションを大股開きするわけにはいかんし、setuidなんてのも感心しないらしいし。諦めかけていたところに思いついたのが sudo 。さっそくportでインストールして visudo で設定してみた

user ALL=(www) NOPASSWD: ALL

んでもって、.qmail-user に

| sudo -u www hohoho.pl

とやれば書きこめる、はずだったのだが。書き込めてない。/var/log/messageにもエラーはなく/var/log/maillogもsuccessしてる。状況証拠は犯人はスクリプトだと言っているのだ。なんでやねん。と思いつつ、ぐーぐる様に物証を求めて検索の旅だ。…メールとして配信するのと、パイプで標準出力に出すのとでは、ヘッダ部分などが微妙に違うらしい。

なんの細工もなく受け取ったものをそのままファイルに書き込むスクリプトを試したところ、スクリプトでチェックに使ってるヘッダがなかった。そりゃ書き込まんわ。

あっさり書いたけど、ここにいたるまで、あれこれしながらいちんちがかり。おまけに途中チェックしてるときにデータを飛ばしてしまった。画像までは消してないので手作業で修復できないこともないけど…。

DHCPで、DDNSというインチキな環境なのでおおっぴらにするわけにはいかんけど、これで写メール投稿がラクちんになったなぁ。

ttp://holeinthewall.jp/~butch/cgi-bin/ktview.cgi

今までのように、環境に合わせてちまちまCGIを書いてたのとはまったく違って、うまく動かなきゃ動く環境にしてしまえ、という乱暴なやりくちに体が慣れるのもどうかと思わないでもないこともない。今回もまともにスクリプトなんて書いてなくて、メールサーバーの設定をしただけだもんなぁ。

[02/10 08:38:15]

qmailのメモ

http://program.station.ez-net.jp/special/network/mail/qmail.program.asp

↑ここが｜処理について簡潔にまとめてあって助かった

[更新]2026-02-05 09:21:04

メールを受信したらそれをスクリプトに渡す方法がわからず右往左往してたことは内緒だ。なんてことなかった。

.qmail に | hehehe.pl などと一行記入するだけぢゃん。

拍子抜けというか、灯台下暗しとか。きっとデーモンを監視してるんだろう、とdaemontoolsについて検索しまくってたり、crontabでダダダとチェックするのかと検索してみたり、qmail-qfilterってのが怪しいぞとか。ずいぶん探し回ってたのだ。

qmailの解説本一冊ちゃんと読めばすぐに解決することだった。うーむ。自宅サーバーにすると、写メール投稿も簡単に設定できるんだなぁ。DDNSであるとかセキュリティとかSPAM対策とか、考えることはたくさんあるけど、ちょっと試してみようかしらん。

うーん、サーバーを持つのは面白いやねぇ。

てなことを遊びでやってるうちに見えてくる業界値段の暴利アコギさ。仕事として・責任をもって、というのと、遊びは違うんだろうけど。ぬしもわるよのお、ぐふぉっふぉふぉふぉ。という図が見えてくるのは気のせいかしらん。

[更新]2026-02-04 10:47:05

ううむ。落とし穴だった。ていうか安直に考え過ぎていた。apacheで複数のサイトを立ち上げて各々SSLをどうする、というところで吐血喀血。

もっともお手軽な、ひとつのIPに名前ベースのヴァーチャルホストではSSLはひとつしか使えないのだ。びっくり。IPエイリアスして複数のIPをひとつのNICに割り当ててIPベースのヴァーチャルホストなら複数のSSLが使える。けど、IPをそのためだけに取るという選択肢はどうなんだろう。いんちきなportを開けてportベースでのヴァーチャルホストでいくことになるにしても情報が少ないから面倒だなあ。

ひとつのサーバーで複数のサイト、複数のSSLというお安い作りがいけないということか。

サイトを構築する時にSSL認証ページをひとつにまとめておけば良かったかもなあ。びんぼ臭いけど。

でも、なんかおもしろいんで、金さえあれば、ポンコツ自宅サーバーにSSLをインストールしてもいいかもしれんな。

と、サーバーのセッティングをやってたら、データベースがおかしいんじゃないかと指摘される。向こうのプログラマ設計運用なので、連絡。しばらくたってSQL文がエラーになっている、どこかこちらでいじったんではないかという電話。該当ASPのタイムスタンプも見ずになにをいってんだか。おかしいのはこの週末、該当ページのタイムスタンプは先月。なにごとも自分が正しいと信じて行動するナイスなヤツだ。しばらくして電話があって、どうやら入力されているデータがひとつ壊れているのが原因だった、と。

サニタイズしてる？不正な入力弾いてるよね？と聞いたら、MSACCESSで弾いてるはずだと。えーっと、SQL文をナマで渡すガッツに沈黙。Postgresになったらこんなことは起こりにくいはず、と追い打ちされてみる。マイクロソフトの製品を擁護するつもりはないけど、この言われ方はかわいそう。製品の問題じゃないぞ。

とまあいろいろ起こるので、昼間だけでおなかいっぱいになってしまい、夜うちで自宅サーバーをいじる気力・精神的体力がありません。とほほ。