2008/06/03(火)shoutcast の ID3タグ表示
2017/10/11 8:11
これは、Tristate社 開発の Shoutcast 再生専用モジュール BB-SHOUT です。
液晶表示の下の行に アーティスト名 - 曲名 のように流れてくる曲の簡単な情報が表示されます。
shoutcast は、基本的に mp3 形式のファイルを HTTP を独自拡張したストリーミングプロトコルで流れてきます。
アーティスト名や曲名は、mp3 形式ファイルの中に含まれる ID3 タグ情報を拾って取得するような仕組みになっています。
アーティスト名と曲名を表示させるためには、ID3 タグを設定すれば良いのですが、ID3タグを設定したのに拾ってくれない・・・と悩んでいた方も結構おられるように思います。
FreeBSD 6.xや 7.0で shoutcast をsc_trans で流すことを検討している場合、先ずは sc_trans を捨てること を考えましょう。 sc_trans は基本的な部分は機能しますが、ID3タ グを活用する場合、 FreeBSD では使い物になりません。(Linux 用の sc_trans も駄目っぽいです)
sc_trans の代わりに ices0.4 を使ってください。FreeBSD の場合は、Packages になっています。カテゴリは audio です。
また、ID3 タグは v3.2 で設定する必要があります。
ID3 タグには 互換性が高いと言われる v1.0 から v1.1/v2.2/v2.3/v2.4/v3.2 と６種類あるようです。
ところがこの世に出回っている ID3タグ設定ソフトウェアは v2.4 までの対応で、 v3.2 に対応しているものはなかなか見られません。
v3.2 に対応しているのは audacity 程度しか見当たりません。（要 lame ライブラリ)
sc_trans を ices0.4 に変更し、ID3 タグを v3.2 で定義しなおすことで、このようにめでたく ID3タグを拾ってくれるようになります。
2008/06/01(日)Co.,Ltd. という略語
2017/10/11 8:12
Ltd. は Limited の略だから、「有限会社」の略語なんだろう、と３０年近く思い込んでいました。
ところが、英和辞書で改めて調べると、、、
有限責任会社
と書かれています。
事業やっている人ならピンとくると思います。
これは日本でいうところの「合同会社」「株式会社」ですね。もちろん、旧来の「有限会社」も含みます。
まぁ、確かに「株式会社」名乗る会社でも英訳では Co.,Ltd. と書かれているので、
違和感感じていましたが、殆ど気にしていなかったのです。
恥かく原因をひとつ減らすことができました（爆）
2008/05/11(日)PostgreSQL－32bit CPU環境から 64bit CPU環境への移行
2017/10/11 8:13
amd64 環境へ移行したサーバは、まる４年稼動。もう１台は約10年稼動していました。
蛇足ですが、昔のハードウェアの方が発熱量も消費電力も少なく、長持ちします。
FreeBSD の場合、amd64 環境でも 32bit アプリケーションは一応動作するものもありますが、基本的には再構築した方が無難に決まっています。
PostgreSQL は、本体バイナリは 32bit ものでも lib32 互換ライブラリのお陰で動作するようですが、やはり起動しません。
「checksum error」
これが出てしまって起動しません。
データベース自体がクラッシュしていると、この表示になりますが、32bit環境で構築したデータベースをそのまま 64bit 環境で動作させようとしてもこの表示が出て使えないです。
いくつか検索してみると、同じようなことで、填まっている管理者が結構多いようです。
いったん、32bit 環境にて SQL 形式でdb_dump を行ってから、64bit 環境構築後にリストアする形を取るのが最も確実な手段と言えます。
2008/04/28(月)桜が満開
2017/10/11 8:14
いずれも昨日の撮影です。北海道神宮境内にて。
本州の方々にとっては、もう過去の話題なんでしょうけれどね。
北海道の桜は、函館付近以外は５月です。この時期に満開になるのは、やはり地球温暖化に起因する異常気象ではないかと。
今年の北海道は、２月がやや厳しい寒さだったものの、３月と４月が記録に残る異常高温で、
５月も高温傾向が予測されている始末で、近い将来、北海道でみかんの栽培ができちゃったりする日も近いかもしれません。
2008/04/27(日)桜が満開
2017/10/12 17:59
この１年いろいろあって、このシリーズの更新が全くできませんでした。。
2008/ 4/27 撮影。観測史上で最も早い記録です。
札幌でも桜の名所のひとつである、北海道神宮にて。
札幌付近の桜の見ごろは、５月上旬の連休明け直後くらいの時期ですが、今年は３月から４月にかけて
観測史上の上位記録になるほど暖かい日が連続していたので、平年より２週間ほど早く満開になりました。
4月27日といえば、函館付近で開花するかどうか、というのが北海道の気候標準です。
今年は、北海道では札幌が最も早い開花宣言でした。南の函館から北へ、東へというのが普通ですが、たまにこういうことがあるようです。
ちなみに札幌の開花宣言は 4/21 でした。
まぁ、本州では過去の出来事なんでしょうが、北海道では桜は５月と相場が決まっており、この時期の桜見物はやはり異常気象だと感じるわけです。
2008/03/30(日)「ＬＡＭＰ環境が一般的」と思い込む日本人偽技術者
2017/10/11 8:16
西欧、特に米国あたりでは「ＬＡＭＰ環境」が一番普及しており、それ以外は商用ベースにならないかのような扱いに言われてることも珍しくない。
これは経験の浅いソフトウェアしか知らない技術屋か、商売勘定にしか興味が無いような商業市場主義者が現状を知らずに言いふらしているだけである。だが、発言の影響は大きいので間違った現状が認識されているのです。
「ＬＡＭＰ環境」とは、 Linux、Apache、MySQL、PHP で構成した、主にＷｅｂサーバのことを指す。
この環境は、アメリカあたりでは一般的な安価（今風にいうと、サブプライムな）レンタルサーバでの構成。ところが、日本ではアホとしか言いようが無いくらい何でも「アメリカに右に倣え」で、とにかく「LAMP環境」といって過言ではない。
＃Java にも同じことが言える。
そういうことは、我々のようなサーバ運用に永年関わっている人種には知れ渡っているようなもので、レンタルではない業務用サーバ、となると、やはり FreeBSD か Solaris が使われることが多い。それは、「他でも使っているから」ではなく、「高負荷に強いから」「メンテナンスの自由が利くから」「ライセンスが利用環境に適するから」というような積極的な理由の方が多いわけで。
当方は、「ＬＡＭＰ環境」に関しては否定的な方で、特にライセンスやメンテナンスに責任を持つことが困難であれば、「ＬＡＭＰ環境」は選択肢から外した方が懸命。特にメンテナンス環境とライセンス問題はこの構成ではかなり不安です。
先ず、Linux だが、色々なディストリビューションが乱立しており、更にディストリビューション同士で考え方が全く違うので、どれが良い？なんて質問されても答えようが無いか、自分が使っているディストリビューションをとりあえず使ってみたら？程度の回答しか出来ない。加えて独自の改良が仇となって、メンテナンスがバイナリ更新で簡単な一方で、ソースコードからのインストールなど、細かいことがすぐにできないことが結構あるので、運用には今ひとつかな、という感じです、
Apache は特に問題は無い。
次に、MySQL。これがなかなか曲者で、ライセンスがころころ変わり良く判らない。知らず知らずのうちにライセンス違反を犯してしまうと、システムとして使えなくなるので、「ライセンスに責任持つ」（そして、そういう顧客は少ない）という顧客でないと使わせることは怖くて出来ない。更に日本語環境を含めたマルチバイト文字環境は使えるとはいっても、正直今ひとつである。使ったことあるが正直言って「かなり使いにくい」。ただ、西欧圏のような１バイト文字圏を想定すると、確かに手っ取り早い感はある。
MySQLに関しては、他にも技術的な問題があるが、ここでは割愛。
最後に、PHP。日本語ドキュメントが早くから整備されていたこともあって、大きな欠点はあるが、今でも結構多用されている。当方も当初は PHP メインで開発案件をこなしていたが、PHP3 から PHP4 へ移行しだした数年前の時点で、この路線は危険だと見切ってPerl に移行した。
それは以下の理由が大きい：
・下位互換性を考慮しないため、バージョン上がる度に検証、テスト、修正といった膨大なメンテナンス工数がかかる。この工数にかかる費用（金銭的なものだけではありません）を誰が負担するのか？ サーバ運用だけにしわ寄せ行く現状なら使えない。
・文字列操作が弱い。
・メモリを大量に食う。だから、はっきり言って高負荷なサイト運用に向かない。潤沢な設備を用意できる大手業者ならたいした問題でもないのだろうが・・・
上記のような考え(遭遇した欠点を克服する手段の選定)もあって、当方は「ＢＡＰＰ環境」である。
FreeBSD、Apache、PostgreSQL、Perl で「ＢＡＰＰ」。
（勝手に作った造語です）
ところで、最近は FreeBSD とか PostgreSQL とか Perl とか判る技術者がいない、という話を聞く。
それは、絶対的な数が減っているというよりは、まともな技術者が他へ取られていることの証そのもの。
絶対的な数もそう増えていないのも事実でしょう。FreeBSD や PostgreSQL や Perl を色眼鏡で見るからです。
資金を出す方々はいつも正しい判断をするとは限りません。
むしろ、この業界の特徴でもあるが、周囲に流されて間違った判断をすることが多い。それが実態であることを認識することだけで、だいぶ違うと思うのですけれどね。
「ＬＡＭＰ環境」にこだわる技術者が近くにいたら、その技術者はスキル的に要注意です。
早いはなし、FreeBSD をいじれる技術者は Linux もなんとかいじれるのですが、逆は大抵当てはまりません。
2008/03/29(土)2038年問題
2017/10/11 8:19
Webブラウザである操作をすると、'500 Internal Server Error' で以後の操作が不能になるというので、どこでそうなるか追いかけている最中に、「ある操作」をすると、
Day too big - 47482 > 24855
Sec too big - 47482 > 44047
のメッセージを吐いて Internal Server Error になる、というものでした。
メッセージからして時刻や日付に関する部分であることが類推できるので、それを中心に検証していたら、、
データベース上に 2100年x月x日 のデータを発見。これが原因です。
2038年問題は、どういう問題かというと、現在多用されている Unix / Linux のシステムクロックが 1970年1月1日 AM 0:00:00 からの累積秒数で表現されており、これが 32bit 長のため、このまま何も対策しないと、2038年1月19日 AM 03:47:07 でフルカウントになり、次の１秒で桁溢れになるため、あらゆる誤動作を引き起こす、という問題。2000年問題より深刻とも言われます。
＃ちなみにMacOS ではファイルシステムについて同様の問題である 2040年問題があります。
該当システムは、日付部分だけが問題だったので、Unix のシステムクロック（しばしば epoch とも言う）を使わずに、西暦元年１月１日を起算日とする日付（これはユリウス日と呼ばれる）に変換した上で処理することで回避。
ただ、最近のＯＳは、Unix のシステムクロックを 64bit 長にしているものも出てきているので、流通しているUnix系ＯＳが64bit 長システムクロックになれば、オーバフローは更に2900億年ほど先になるので、その方向で対策はされる模様。
少なくとも FreeBSD 6.x においては システムクロックは 32bit 長表現みたいです。(gcc のバージョンも 3.4 だし。。）
gcc のバージョンがあがった FreeBSD 7.0R ではどうでしょうか。(gcc のバージョンは 4.2.1)
※追記：
簡単に確認できるようなので、早速試してみることに・・・
FreeBSD 7.0R i386版
[1]% date -u -r 2147483647
2038年 1月19日 火曜日 03時14分07秒 UTC
[2]% date -u -r 2147483648
1901年 12月13日 金曜日 20時45分52秒 UTC
FreeBSD 7.0R amd64 版
[1]% date -u -r 2147483647
2038年 1月19日 火曜日 03時14分07秒 UTC
[2]% date -u -r 2147483648
2038年 1月19日 火曜日 03時14分08秒 UTC
少なくともプラットフォームが 64bit だと64bit長システムクロックに対応している模様。。
2008/03/19(水)余計なつまらない設定はしない方が、、( /etc/ttys の設定 )
2017/10/11 8:21
これは、以下のような感じで、現在ログインしているリアルユーザのアカウント一覧を表示するものだったりします：
1:19AM up 4 mins, 1 user, load averages: 0.06, 0.20, 0.10 USER TTY FROM LOGIN@ IDLE WHAT lifekrnl p0 northwall 1:18AM - w
主に一番最初の行の右側にある小数点2桁の３つの数字を見るのに使っています。
上記の例だと 0.06 0.20 0.10 とある数字列です。
順に1分間,5分間,15分間の平均実行プロセス数。
数値が 1を超えなければ、このサーバはそんなに忙しい状態ではないことを意味します。
とあるサーバを FreeBSD 7.0 にしたら、このコマンドが機能しなくなってしまって、
代わりに /var/log/messages に以下のメッセージを延々と吐いていた模様：
Mar 19 01:02:05 **** init: can't exec getty 'none' for port /dev/ttyp1: No such file or directory
Mar 19 01:02:35 **** init: can't exec getty 'none' for port /dev/ttyp0: No such file or directory
原因は /etc/ttys の以下の赤い文字の部分：
# Pseudo terminals ttyp0 none network on secure ttyp1 none network on secure ttyp2 none network
赤い文字の部分を削除して再起動したら、あっさりと解決。。orz
どうも設定間違えたみたいです。
下手すると、場合によってはリモートログインが出来なくなったりする可能性あるので、注意するにこしたことありません。
2008/03/16(日)FreeBSD 7.0R で csh が segmantation fault(SEGV)
2017/10/11 8:24
ログインが全く出来なくなってしまった..orz
シングルユーザモードにしたら何とかシェル(csh)を使うことが出来たので、ログを見てみると、
kiew kernel: pid 13642 (csh), uid 1001: exited on signal 11 (core dumped)
のようなメッセージが出ている。
共有ライブラリ回りだというのは何となく判るが、何が問題なのか判らないので、先ずはＯＳをバイナリインストールしなおしてみる。。
上手く行かない。
試しにシェルを sh に変えてみると、core dump は出ない（使用できる）。
この現象は libiconv をソースコードからコンパイルにてインストールしてからでたので、libiconv と csh の関係を調べる。
ここしか有用な情報に突き当たらなかったが、やはり libiconv が問題の可能性が高いことに確信を得ました。
それでわ、、ということで、強引に /usr/local/lib 配下の libiconv.so.3,libiconvso.6 とそのリンクを削除し、その上で csh を起動してみる。そうすると正常に起動しました。これで libiconv.so の問題ということは判りました。
ここで、libiconv-1.12 をインストールしてみます。そうすると、 libiconv.so.6 がインストールされます。
こうすると、csh は再び segmantation fault を出し、ライブラリ依存する gmake を叩いてみると、'llbiconv.so.3 が 要ります' のようなメッセージを出す。
ということは、 csh は libiconv.so.3 を前提にしたバイナリパッケージ、ということが簡単に予測できます。
実際、packages にて libiconv-1.11_1 をインストールすると、 libiconv.so.3 がインストールされました。
この状態で csh を起動すると、segmantation fault は出ません。
原因は判ったのですが、今度は samba が上手く使えないのでないか？という疑問が、、
packages にて libiconv-1.11_1 をインストールした状態で、
$ iconv -l | grep MS
とすると、
kiew-lifekrnl% iconv -l | grep MS 40:CP1250 MS-EE WINDOWS-1250 41:CP1251 MS-CYRL WINDOWS-1251 42:CP1252 MS-ANSI WINDOWS-1252 43:CP1253 MS-GREEK WINDOWS-1253 44:CP1254 MS-TURK WINDOWS-1254 45:CP1255 MS-HEBR WINDOWS-1255 46:CP1256 MS-ARAB WINDOWS-1256 66:ARMSCII-8 85:MS_KANJI SHIFT-JIS SHIFT_JIS SJIS CSSHIFTJIS 92:CP936 MS936 WINDOWS-936
となり、使えそうな感じ。
わざわざソースコードから最新の libiconv 入れる行為が却って仇になる模様。。
pakages/ports 使うと、セキュリティバージョンアップの対応の遅さや、インストールディレクトリなどが環境に微妙に合わなかったりすることが結構多かったりして、使いにくいので、出来るだけ使わない方向でいるんですが、、
いまのところ、packages の libiconv-1.11_1 で samba 3.0.28a が一応利用出来ているみたいです。
2008/03/15(土)安全なサイトの作り方
2017/10/11 8:27
いつもＷｅｂサイトを利用したシステム構築を行う際は、セキュリティ対策には充分に検討して手抜かりの無い様にしているつもりだが、それでも想定外のことは起きるもので。。
上記資料では、９種類の主な脆弱性を挙げて対策手法の注意点などを挙げています：
１）ＳＱＬインジェクション（ＩＰＡに報告された全体の３割がこれらしい）
２）ＯＳコマンドインジェクション
３）パス名パラメータ未チェック／ディレクトリトラバーサル
４）セッション管理の不備（セッションハイジャック）
５）クロスサイトスクリプティング（ＸＳＳ、ＩＰＡに報告された全体の４割がこれらしい）
６）ＣＳＲＦ
７）ＨＴＴＰヘッダインジェクション
８）メールの第３者中継
９）アクセス制御や認可制御の欠落
現状で注意が必要なのは、５）のクロスサイトスクリプティングですかね。
これははっきり言って、ＣＧＩなりで対処するだけでは不十分で、不審な振る舞いをしていないかどうか、偽サイトの有無のチェックとかにも目を光らせる必要があり、クライアントにも協力をしてもらわないといけません。
当方では過去に８）の脆弱性で 1999年に作成したCGI に関して一度外部から報告を受けて対処しただけです。このときは、 spam メールの発信基地になってしまっていたのでした。根本的原因の対処をしまし た。
他の脆弱性で報告を受けたことはありません。
特に１）、３）、４）、９）は、当方が 1998年に営利事業としてＷｅｂアプリケーション構築を始めてから注意している点で、今までに問題は起きていません。2003年以降は、１）～９）全て網羅の上で、構築を手がけているつもりです。
９）は、オペレート（運用）する人が全くの素人だと、いくら仕組みを作っても管理がずさんになりがちで、問題が起きる確率は高いのですが、幸いにも情報漏えいの事故の報告は無く、これはクライアントの皆さんが危険をそれなりに認知してもらっているのだろうと考えています。