2007/10/30(火)FreeBSD 7.0R/6.3R
2017/10/11 9:04
早ければ年内(12/17) にも FreeBSD 7.0 がリリース予定らしい。。
いつものことだが、予定どおりに行った試しは記憶にある限り全く無く、常に１ヶ月単位で遅れるのであるが、
そうだとしても遅くても 2008年春までには FreeBSD 7.0 がこの世に出る模様です。
また、未だアナウンスは無いようですが、FreeBSD 6.3R もリリースに向けて動き始めているようです。
こちらはリリース時期は今のところ判りませんが、7.0R の直後か、同時くらいかもしれません。
FreeBSD 6系は、6.3R か 次版 6.4R でメンテナンスは終了すると思われます。
2007/10/23(火)wu-ftpd のインストール
2017/10/11 9:06
のようなものが出るようにして欲しいという要望が・・・
正直、途方に暮れたんですが、どうやら、
IE6 にて anonymous FTP でログインを試みる → 失敗したらこのプロンプトが出る。
という仕組みらしい。
ところが FreeBSD 標準の ftpd だと、どうも IE6 が想定していないエラーが返るので、
このプロンプトが出ないらしい。。
FrreBSD 標準の ftpd では、
「anonymous ログインなんでできません」というエラーを返すので、ftpd の挙動としては全く正しいんだが、、、
IE6 が想定している ftpd の挙動は、anonymous ログインのリトライを要求するというもの。
やはり造りはちょっとアマチュア入ってるね、、 ＜ IE6
解決には wu-ftpd が現実的。
ということで、 wu-ftpd をFreeBSD のパッケージからインストールして設定するが、、
ファイル一覧が表示できない
という現象に悩むこと数時間。
どうもパッケージのコンパイル済みバイナリファイルが、現状にあっていない模様・・・
proFTPD に変えても同じ結果。
ということで、wu-ftpd をソースコードからコンパイルです。
wu-ftpd は、ここで入手できます → http://www.wu-ftpd.org/
最新バージョンは 2.6.2 ですが、これが 2001年だったり、、セキュリティfix はパッチファイルという有様。
開発が停止しとる、、、
まずは、入手した wu-ftpd-2.6.2.tar.gz を gzip などで展開。同時にパッチも入手。
そして、作成されたディレクトリ に移動し、
./configure --prefix=/usr/local --enable-ls
とする。--enable-ls (chroot の場合の /bin/lsではなく、内部のlsコマンドを使う)が重要です。
（参考 http://unix-study.com/unix/sol8/install/wu-ftpd/idnex.html)
早速 make すると、エラーが出ます。
２つのファイルを手動で修正する必要あります。
１） src/proro.h
一番最後の行(295行目)
char *strcasestr(register char *s, register char *find);
↓
/* char *strcasestr(register char *s, register char *find); */
としてコメントアウト
２） src/ftpcmd.y
= {
となっている部分の = を削除。
= と { は、タブ文字で区切られています。
修正後 make を行い、
エラーが無くなったら make install
FreeBSD 6.2 の場合
/usr/local/sbin 配下に in.ftpd、ckconfig、ftprestart、ftpshut、privatepw
/usr/local/bin 配下に ftpcount、ftpwho
/etc 配下に ftpaccess、ftpconversions
はインストールされます。
ftpd は /usr/local/sbin/in.ftpd がその本体です。
あとはこの in.ftpd を inetd から in.ftpd -a -l として起動できるように設定して、インストール完了。
2007/10/14(日)FreeBSD 6.2 において、NVIDIA GeForce7050PV/nForce 630a なマザーボードへの対応
2017/10/11 9:07
ボードはこんな感じ。このサイズのものを採用するのは初めてだった
りするが、、 ^^;このマザーボードにて FreeBSD 6.2 を導入するのに実質まる２日かかってしまいました..orz
このマザーボードは、今年になってから発売されたものらしく、ハードウェアが新しいのです。
それ故、FreeBSD 6.2 をインストールして稼動させるには、致命的な問題が２つ。
インストールとＯＳの起動は難なくでき、普通に使えるのですが、 まず、「リブートが出来ない」 という現象に遭遇。
リブートの直前で、実質ハング状態になり、手動リセットしないとリブートしないのです。
これは通信回線経由で遠隔メンテナンスする時に致命的な問題になります。
色々調べると、提起の「NVIDIA GeForce7050PV/nForce 630a」マザーボード対応は、今年の７月か８月頃に安定版が提供された模様。FreeBSD 6.2-RELEASE では対応してなく、最新版の FreeBSD 6.2-STABLE にするといけそうなことが判りました。
早速、FreeBSD 6.2-STABLE へＯＳを更新してみる。。
起動成功。上手くリブートかかる。。見事に上手く行きました。
あと、もうひとつ。オンボードのＬＡＮが認識されません。FreeBSD でサポートされているLAN カードを装着することで一応回避される問題ですが、説明が面倒です。自分が使うわけでないので。。
これも、今年７月ころに 6.2-STABLE で対応したようなので、早速導入します。
手順は以下の通り：
０） device nve を無効にして、カーネル再構築。
１）FreeBSD Device Driver for NVIDIA nForce Network Adapter なるサイトから、nfe-20070918.tar.gz をダウンロード
２）他のパッチも必要に応じて入手。大抵の場合は他のパッチは必要無いと思われます。
３）ダウンロードしたパッチを tar で展開。
４） cd nfe-20070918
５） make
６） mv if-nfe.ko /boot/modules
７） cd /boot/modules
８） chown root:wheel if-nfe.ko
９） chmod 555 if-nfe.ko
10） cd /boot
11） vi loader.conf
として、if_nfe_load="YES" の１行追加
この一連の作業は、root アカウントで行います。
こうすることで、再リブート後、問題なくマザーボード AN-M2HD が使用できるようになります。
2007/07/15(日)PHP4 のサポートは年内まで
2017/10/11 9:09
PHP4のサポート終了は2007年12月31日 〔shashdot Japan〕
ついに告知がなされてしまいました。
2008年8月8日以降、PHP4 は完全に捨てられる運命にあります。（今のところ）
最近需要が増えだした著名な CMS ソフトウェアの多くは、PHP 4 対応で、PHP5 は対応していないものが多く、
システム運用としては最も懸念する事項であり、悩みの大きな種です。
というのも、PHP3 と PHP4 の時は互換性があったが、PHP4 と PHP5 は互換性が無いからです。
次期バージョン PHP6 も既に PHP5 と互換性が無い造りになると聞いています。
こういう問題が出ることはPHP3 から PHP4 に変わっていくときに、比較的安易に予測出来たことなので、
自分が直接手を出せる新規ものの請負業務は、さっさと PHP から Perl に変えたのでさして影響は殆ど無い
のですが、開発作業が別の人になっているものが幾つかあって、それらは１つ１つの案件毎に対応を考えない
といけません。
こうして、収益が全く無いけれど、重要且つ大きな作業が時々あるのが、システム運用です。
2007/02/16(金)混沌気味で判りにくい MySQL
2017/10/11 9:26
日本では今ひとつですが、欧米圏ではユーザシェアの６割とも７割とも言われている代物です。
当サイトの管理人は、MySQL は積極的に避けています。PostgreSQL が使えない組み合わせの時に止むを得ず採用するという姿勢です。
ライセンスだけでも何回か変わっているようだし、訳が判かりません。
例えば、知らずにライセンス条項違反をしでかして問題が発生したとしても、この業界では全てシステム屋へ責任転嫁されるのがオチです。
だから、この状況では 最初から積極的には使わない という自己保身を図るしかないわけです。
最初はGPLのみだったはず。
それが、事業で使う（インストール代行とかも含む）場合は、ライセンスを有料で買ってね、という話しになり、
さらに、改造しなければ GPL（無償）でいいけれど、そうでない場合で、ソースコード公開したくない／出来ない場合はライセンスを有料で買ってね、という話しになったり（この時点で解釈が複数あるようなので、政治的な安全策とるしかない）、
挙句の果てに、昨夜初めて知ったんですが、昨年の１０月には、「エンタープライズ（商用版）」と「コミュニティ（無償版？）」に分けるから、商用レベルのサポート欲しければ、ライセンスを有料で買ってね、という話しになったりで、金をケチるクライアントを抱えるシステム屋にとっては、ライセンス条項の度重なる変更はほんとに泣かせもの。
ライセンスを有償で買って貰ったほうがトラブルが少なくて余計な対応が減るのかな、と多くのシステム屋は考えるけれど、費用をケチられると、それが全く出来ないからです。
更に機能面ですが、正直、「何でこれが多くのユーザがいる優れものなんだべか？」という感じです。
先ず速度は、 PostgreSQL 8.x > MySQL 5.0 。
国際化対応も PostgreSQL 8.x > MySQL 5.0。何で euc-jp は MySQL ではujis となるんだろか？？
＃ MySQLより PostgreSQL が遅いというのは、当時は機能的に充実してた故の代償で、今となっては無意味な固定観念だとおもう。。。
確かに欧米のような１バイト文字圏だと、しっくり来る作りという気はします。
現在の MySQL は一応国際化対応ですが、PostgreSQL の方が扱いに柔軟性がある感じなのです。
相変わらず、日本語のドキュメント量も PostgreSQL > MySQL です。
整ってきたとはいい、英語が大の苦手な当サイト管理人のような者にとっては、この面でもまだとっつきにくさがあります。
取り急ぎ、とあるサイトで使うので、MySQL固有の技術を習得するためにもインストール＆テスト運用しています。
今日の未明にテスト運用まで出来ました
2007/01/29(月)FreeBSD 6.2R アップグレードの注意点 ― DNS
2017/10/11 9:29
現在３分の１のサーバについてアップグレード完了しています。
FreeBSD 6.2R は BIND 9.3.3 がベースシステムとして組み込まれています。
５台稼動させている内外の DNS で、うち３台の作業を終えましたが、致命的な被害になるかもと思われる点が１つ・・・
/var/named/etc/namedb/named.conf は上書きされるらしい.....
このファイルが上書きされると、アップグレード前の DNS設定が事実上クリーンアップされてしまいます。
FreeBSD 6.0R → 6.1R の時はこのようなことは無かったように記憶しているので、要注意というところでしょうか。
設定ファイル自体は、 BIND 9.3.2 で使用していたものがそのまま使えます。
当方ではこれに気づかず、プライマリＤＮＳの設定内容復旧に２時間ほどかかりましたorz
2007/01/15(月)FreeBSD 6.2R ようやく....
2017/10/11 9:30
３～４回延期（ま、いつものことだが）された上でのリリースで、一応それなりに満を持してという感じでしょうか。
リリース直前にもセキュリティ問題が発覚して、一応対処は入ったようだし。
2007/01/10(水)spam メール対策
2017/10/11 9:33
某所から、「あんたのとこのＷｅｂサーバから spam メールが発信されてると報告受けたから至急(撲滅の)対処するよーに」と業務命令が下ったからです。
一時はどうして良いものか見当がつかず、原因追及に雲を掴むような雰囲気が....
結局、左記のメールフォームが悪用されていたのでした。1999年頃に自作した CGIです。これは、実際に悪用されていたメールフォーム。これが spam 発信の拠点になってしまう訳です。
直接このメールフォームから spam を発信しているわけでなく、HTTP プロトコルを直接操作して,本来であればこのメールフォームから起動される CGI を直接アクセスしているのだと思います。
親切機能で、誰もが閲覧できる部分にメールフォームを安易に設置するのは危険だという訳です。
某所のテクニカルサポートに聞いてみたら、この手の spam 発信は常套手段の一つのようです。なので、Ｗｅｂサイトを運営している全ての善良な運営者は、spam 発信基地にならないように意識を高めていか ないといけません。
ですが、全てのメールフォームが危険という訳ではありません。
左記のメールフォームのように入力項目が複数あるものが危険度が高いです。
入力項目が本文しかないようなものは、spam 発信の道具にはされますが、大量発信の道具にはなりにくいです。
＃但し、集中攻撃を受ける可能性がある
電子メールは、最初の空行１行にてメールヘッダ部分と本文部分に区別され、メールヘッダが実際の配送記録や制御に使われます。
結果的にメールフォームから、メールヘッダに情報を埋め込む仕組みが備わっているものが危険です。
今回は、左記の「題名」の部分に、メールヘッダを埋め込まれたために、spam 発信の拠点になってしまった、
という状態でした。
今日(1/10) の AM 3:30頃にこのメールフォームは機能しないようにしました。
上記の例の場合、
-----
From: フォームで入力したメールアドレス
Subject: フォームで入力した題名
以下本文
-----
と電子メールデータを作成してメール送信処理していたため、Subject の部分にメールヘッダを埋め込めば
自由自在の場所に送ることが出来てしまいます。これが脆弱性だった訳です。
これは、
-----
From: CGI 固定のメールアドレス
Subject: CGI 固定の題名
以下本文
メールアドレス：フォームで入力したメールアドレス
題名：フォームで入力した題名
本文の続き
-----
のようにCGI の電子メールデータ生成処理をすることで、spam メール拠点になることが防止できた訳です。
つまり、メールヘッダ部分にフォームデータの内容をそのまま差し込まない が鉄則になります。
現在お使いのメールフォームがそのような脆弱性を有しているか否かは、CGI を見ないと判りません。
メールフォームCGI の作者に聞くか、実際に実験して確認するかしてみる事をお願いします。