2007/02/26(月)オホーツク海の流氷

2017/10/12 18:01 北海道の生活情報サイト連携
seaice.jpg

　2007/ 2/18 撮影。
　ここ数年、流氷の画像を掲載していないことに気づき、一応掲載してみました。
　サロマ湖から知床半島にかけて、所々で接岸しました。

　サハリン付近は例年以上の寒さですが、北海道付近の今シーズンは暖冬の影響で流氷の接岸も遅れ、接岸してもそれが長続きしません。
　この日は既に、流氷本体は沖の方へ後退しています。

　今シーズンは、完全に海が流氷で閉ざされる期間が続くことなく、数回海岸に押し寄せては沖に遠さがる状況を繰り返して流氷シーズンを終えるかもしれません。

　今年(2007年)の沿岸漁業への悪影響が心配されるところです。
　網走市北浜の釧網線北浜駅から撮影。
コメント（0件）

2007/02/26(月)北海道新幹線　札幌延伸活動などの状況

2017/10/11 9:25 地元(札幌)・北海道の話題
久々にネタ探してました。
今回は、駅が設置される予定の一部自治体でにわかに活動が盛んになっているという面ですかね。。。

知内町：特に動きなし
木古内町：いつものように、建設進捗状況を町民向け広報誌で伝えています。
北斗市：北海道新幹線建設促進期成会 北斗支部の会員募集を始めたようです。
函館市：特に動きなし
七飯町：新函館駅予定地に近接する地域で、流通関係向けの土地分譲を始めたようです。
八雲町：特に動きなし
長万部町：大変気合の入った駅周辺の都市計画の一般公開を始めたようです。→ 北海道新幹線長万部駅周辺整備構想 〔長万部町〕
倶知安町：特に動きなし
小樽市：こちらも駅周辺の都市計画概要の一般公開を始めたようです → 新小樽（仮称）駅周辺整備構想 〔小樽市〕
札幌市：特に動きなし

長万部町は、行くと判りますが、現状でも鉄道で市街地が東西に分断されている感じです。
新幹線の開通に関係なく、鉄道の高架化とかしたほうがいいかも、という気がします。

新小樽駅（仮称）は、かなり山の方ですね。駅周辺は谷間です。
トンネルとトンネルの間に駅舎があるという様相です。
ちょうど、奥沢水源池のすぐそばです。国道5号線　奥沢十字街から 2km はありそうです。
コメント（0件）

2007/02/16(金)混沌気味で判りにくい MySQL

2017/10/11 9:26 サーバ運営・管理
ご存知の方も多いと思いますが、 MySQL は、PostgreSQL と同様、リレーショナルデータベースソフトウェアです。
日本では今ひとつですが、欧米圏ではユーザシェアの６割とも７割とも言われている代物です。
当サイトの管理人は、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固有の技術を習得するためにもインストール＆テスト運用しています。
今日の未明にテスト運用まで出来ました
コメント（0件）

2007/02/05(月)老舗の有名ジンギスカン店が脱税容疑らしい。。

2017/10/11 9:28 地元(札幌)・北海道の話題
σ(^^) も食いに行った事がある店なんですが・・・
総連北海道本部など所得税法違反で捜索 〔gooニュース/読売新聞〕

北朝鮮系だったのね、、この店の社長。知らんかったなぁ。。
この店、札幌では有名なジンギスカンの老舗なんです。
マトン肉なのですが、美味しいのでいつも行列が出来る人気の店なんですが。

経営実態は、地元の人間ですらよく知られていないです。
朝鮮総連は犯罪集団らしいね・・・　
法治国家の下で法律違反やったのだから、政治的弾圧でもなんでもないですつーか。

〔追記 2007/02/06〕
どうやら、昨夜このジンギスカン店の経営者ら３人と、無資格で帳簿作成に関わった１人（全員　北朝鮮国籍らしい）
が逮捕に至った模様。今朝には全国ニュースになっていました。
コメント（0件）

2007/01/29(月)FreeBSD 6.2R アップグレードの注意点　― DNS

2017/10/11 9:29 サーバ運営・管理
順次 FreeBSD 5.5R/6.1R から 6.2R へのアップグレードを進めています。
現在３分の１のサーバについてアップグレード完了しています。

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
コメント（0件）

2007/01/15(月)国道の除雪区分

2017/10/11 9:31 地元(札幌)・北海道の話題
北海道の国道には、３種類の除雪区分があります。
第１種区間：昼夜の区別無く交通を完全に確保する
第２種区間：夜間除雪は通常は行わない。昼間の２車線以上の交通を確保する。
第３種区間：夜間除雪は基本的に行わない。１車線確保を基本とし、適切な待避所を設けて交通を確保する。

20070115.jpg
この図は、国土交通省　北海道局の現場機関でもある北海道開発局の資料。
「平成17年度」となっているですが、今年度も同じ内容の模様。

以前の北海道道路地図には、必ずといっていいほど、この国道の除雪区分図が掲載されていたのですが、最近の北海道道路地図にはこの除雪区分図が載っているものを探す方が困難です。
そのため、この区分があることすら知らない人も多い（特に若いの）んではないかと。

自分自身もこのような図を見たのは数年ぶりですが、特に夜間ドライブの際は注意しないと、酷い目に合う場合があります。

コメント（0件）

2007/01/10(水)spam メール対策

2017/10/11 9:33 サーバ運営・管理
昨日・今日と spam メール対策に追われていました orz　
某所から、「あんたのとこのＷｅｂサーバから 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 の作者に聞くか、実際に実験して確認するかしてみる事をお願いします。
コメント（0件）