明日から4月と。まぁ身近なところで言うと、駐輪場の主体が変わるもので。
しかし本当に主体が変わるのか疑問なのだが。
明日マークが貼り替えられてたらすばらしいな。
さて、今日ちょっとこんなニュースをみた。
近鉄の上本町と難波の駅名が変わるらしい。阪神なんば線開通と同時に。
上本町 → 大阪上本町
近鉄難波 → 大阪難波
まぁある意味ありがたい話かもしれん。
難波はいいんだが、上本町ってねぇ。大阪のターミナルだとわかりにくい気もしないことはない。そりゃ我々は上本町行きと言われて、ああ大阪に行くなと思うけど。
今でも伊勢への特急は上本町から出るのが多いんだ。難波から出るのも多いけど。
だから上本町は重要なターミナルなんですよ。そりゃ大阪線の特急以外は全部ここからだが。
しかし、難波はここまでせなあかんかったのかな。まぁわかりやすくはなるだろうけど。
南海は「難波駅」、近鉄・阪神は「大阪難波駅」…なんか微妙に説得力がないな。
あと、知らんかったのだが、阿部野橋駅は大阪阿部野橋駅なんだね。
そういえば随分前の話になるのだが、京阪の京都の駅名が変わると告知があったな。
五条 → 清水五条
四条 → 祇園四条
丸太町 → 神宮丸太町
まだ変わってませんよ。中之島線の開通まで変わりませんから。
「京都観光5,000 万人キャンペーン推進に協力」のためらしい。
確かに路線図を見るだけで見えてくるものがあるのかもしれない。
しかし、ここのところ本当に駅名が変わるよって話多いね。
そういえば最近JRでも変わったよな。
よっぽど複雑な駅名じゃなきゃどんな名前でもあんまり関係ないんですよね。
さっきの、大阪上本町にしてもそうだが、遠方では今までも大阪上本町行きと言ってたそうだ。
まぁそれでも路線図にはっきり書かれるのと書かれないのでは大きく違うもんかね。
いや、駅名ってへんな地名が抜き出されてること多いよ。
けど、不思議なもので、それで定着してしまうんだよね。電車はすごいもんだな。
月: 2008年3月
電話を見直してSkypeを使ってみるといいことある
さて、かの有名な、Skype、
あれは非常に優秀で、声は美しく伝わるし、IM機能・ファイル転送機能というコミュニケーションに便利な機能がある。
もちろんWebカメラを使ってテレビ電話もできる。これはやらないけど。
最近便利につかえるIP電話として注目されてますね。
まぁちょっと普通思うIP電話と違うけど、こういうのが根底にあるのでは?
で、SkypeはSkype間であれば、P2Pで通信する。
すなわちSkypeははじめの接続の音頭を取るだけで、それ以上はしない。
そういうものなのでSkypeは無料。Skypeのサーバーの負荷は少ないし、それにSkypeも儲かるものだし。
特にポート開放不要、UPnP?そんなものもいらない。
UDPホール・パンチングという技法を使ってやってるそうだ。
UDPというと、届いたか届かないかわからないという方式でTCPの届いたかはっきり管理するものと対照的。
TCPが向くのはメールとかだな。
メールは歯抜けになるとこまるし、きちんとしたものが届いて欲しい。
そういう意図があるので、送り直してくれとか、そういうことができる。
それに対してUDPはそのような親切機能を省いて投げるだけ。
何の役に立つのかというと、
DHCPのように誰かに届けたいとき。そしてラジオのように、遅れた信号は意味をもたないものに向く。
電話というのも遅れた信号は意味を持たないので、それなら投げるだけ投げてくれと。そういうことです。
そして、このUDPのいい加減さは、コネクションが成立していることすら管理しない。
TCPの場合、たとえばwww.yahoo.co.jpにつないだ、そのつないでる間にindex.htmlくれといって、送ってくる。
つないでいることを確認できるから、もしここでwww.yahoo.co.jpが関係ないパケットを発射しても無視できるはず。
ところがTCPにはこのようなものがないので、たとえば、
192.168.1.100でグローバルIPが127.10.7.3がルーター経由で10.101.102.103に自分の声を送ります、
その一方10.101.102.103は自分の声を127.10.7.3に送りつけてきます。
このとき、127.10.7.3はこのパケットを10.101.102.103に送ったものの返事と考えます。
だから192.168.1.100へ返してあげる。
そう、これこそがUDPホール・パンチング。これを使えばルーターをくぐり抜けられる。
自分の信号の返事であるとだまさせて、アドレス変換をしてもらうというもの。
このようにして、特にUDP全遮断とかしない限り多分この技法は使える。
まぁその対策としてTCPでスーパーノード経由で行う方法はあるけど、音質落ちるよ。
さて、実際そんなことを考えなくてもきれいに通信できるのがSkypeのよいところ。
盗聴の心配はありません。
P2Pだから、PCとPCの間、特にSkypeのサーバーを通すわけでもない。
とはいってもプロバイダーとかは経由するので、やはりそれだけで盗聴の不安はなくならない。
さらにその信号を暗号化してある。まぁだから残念ながらSkypeの動作は重いですよ。だけど現代のPCでは十分。
もちろんそのための鍵の交換もRSAを使ってるからね。
秘密鍵暗号で共通鍵暗号の鍵を持って行くと。まぁこれなら盗聴は無理だろうね。
さて、それで実際に話してみたりすると、URLを相手に伝えたいことが出てきます。
そんなときにIMは便利で、IMがURLだらけになったり。
そして、参考になるデータをファイル転送で送ってきたり。非常に便利ですね。
音声通話はIMに比べると、キーボードで打たなくてよいと。
だからいうことはすぐに言えるし、他の作業とある程度平行してできる。
画面のフォーカスもあわせなくていい。すなわち画面にFirefoxがあるときにもマイクに話しかければいい。
共同作業にはもってこいだな。
最近本当に電話を使うことは減りましたね。
というのもe-Mailへの反応がかなり速いし受け取れる場所も選ばない。
電話は受けとる場所を選んでしまいますから。携帯電話は違うか。
けど僕は携帯電話は家にいたら使わないからな。e-Mailのほうがよっぽど速い。
しかし、それでも電話は反応がすぐに返ってくるのがよいことで、たくさんいうこといわれることがあるときには有利。
ただ金がかかる。それがSkype同士なら特にかからない。
そういうのがよいところなんですよね。
出先機関って結構多いよね…ああそういうことか
真偽のほどはわからないのだが、大阪市と大阪府が両方金がないと言っているのは、
都市に必要な施設がないから、これを作るに金がたくさん必要だったと。
確かに、大阪港は市営港湾だな、大阪市が作ったすばらしい港だ。
堺泉北港は大阪府の港だな。実は関空もこの一部で、何かと重要な港だったりする。
まぁ関西には神戸港が国の建造した港としてあったな。今は神戸市営だけど。
そういえば神戸市も。彼らは自分たちで空港を作ったからな。
なんとも意地っ張りで、身の丈に合わない仕事をするが、わからないこともない。
まぁまだ伊丹が国の空港として残ってるからいいが、このままいくと府の空港になりかねんな。
大阪府が金欠でいやがってるけどな。まぁもともと関空の完成で廃港になる予定だったのだけどな。
多分この様子を打開するために道州制とかいう話が出てくるんだろうな。
で、レポートが出たらしく新聞に載ってましたね。
それを見ると
基礎自治体(多分市町村)は消防・教育・福祉・保健・都市計画(道路・水道etc)・戸籍・地域振興をすると。
これだけなら何も変わらないように見えるのだが、どうもこんなことが書いてあったらしい。
保健所、飲食店と狂犬病の印象しかないが…、あれが市の保健部門にするべきじゃないかとか。
そういえば市の保健センターというと、こちらは検診と予防接種と、保健所よりよっぽど保健してる気がしてならない。
まぁこのへんと統一的に保健部門になるんじゃないのかな?
あと、道路の維持も幹線道路以外は市がやることになるんじゃないかな。
確かに県道って微妙な道多いからね。崖崩れが起きて、県が復旧工事をすると聞いて、えっ?と思うこと多いからな。
まぁこの辺も他の市道と同じように統一的に管理することになると。これは都合が良さそうだな。
教育も高校は県立というよりも市立にするべきとか。
まぁ広く門戸を開くならいいんじゃないかな。いくつかの市町村で高校組合みたいなのが出来てやるかもしれないな。
あと、県営水道というのも結構あるけど、もしかすると全部市町村の責任でやることになるのかな。
県営水道が水道組合になるかもしれない。まぁこれは予想しただけだが。
それで新しくできるだろう、道は、
幹線道路・主要河川・空港・大学・林業・農業・労働・環境・電波・警察・市町村のマネージメント
ってところでしょうかね。どうもこのレポートを読むと高速道路みたいな超幹線道路みたいなのも道の管理になりそう。
多分、国の出先機関の仕事は道でやれという意味だろうな。
だから空港とか電波とかはその加減で入ってるのだろう。
このあたりが道州制の目玉なんだろうね。
中心でマネージメントするんじゃなくて、道が勝手にやれと。できるかは知らんが。
国のやることはこれ以外の今までやってたことで、
外交・皇室・防衛・通貨・司法ぐらいか。まぁもうちょっとあるだろうけど。
裁判所とか検察とか入国管理局とかの出先機関以外は消えますよということでしょう。
この辺見ると、アメリカの州と国の関係に似てるけど、州は憲法はあるし、司法までしてるからな。
あくまでも1つの日本でやっていくということなんでしょう。
まぁそれにしても、心配なのは金欠にならんのかということだな。
いまのところだと、関東が大もうけする計算だからな。
それを無理に全部使い切れば、大都市はやることが多いから金も多いのは当然だと言えてしまう。
うーん…そこのところどうするんだろうね。
その結果、道路に穴が開くわ、水道から赤い水が出てくるわとかなったら悲しいからな。
そこんとこどうなんでしょうかね?
ログを読んで整理してくれる小人さん
SSHの操作ミスして部のサーバーからアクセス禁止食らった。
たしか2分間に10回連続失敗で10時間アク禁だったかな。ちょっとしょんぼり。
なんでこんなことをしたのかというと、SSHのブルートフォースアタック防止のために。
たとえばですが、smithユーザーがあると知っていて、
このユーザーのパスワードがわからないので、総当たりしてくるけしからんやつがおると。
鍵必須だから全く無駄な話なのだが、こんな風にアクセスされるのは気分が悪い。
まぁしゃあないけど。アホなことしたのが悪いわけで。
さて、ディストリビューションをCentOS 5.1に変えていろいろ感じることはありますね。
といっても基本的にRedHat系のディストリビューションには違いがないので言うほど違いませんが…
ここでDebian系だったら結構変わってただろうな。
これはchkconfigがないのがつらいな。あとパッケージ管理のdebに慣れないな。
ましてLinuxから離れてBSDとかだったら…まぁそれはそれでおもしろいかもしれんが。
そんな中おもしろいものが動いてくれることがわかった。Logwatch。
cronで毎日動かしてくれるようです。
しかしすぐには気付きませんでした、ただcrondからのエラーメールが届くのでそれを読んでて気付いた。
UNIXではrootにe-Mailを送ってくる。あの世界ではごく普通のことです。
どういうエラーメールかというと
/var/cache/logwatch No such file or directory at /etc/cron.daily/0logwatch line 747.
で、テンポラリファイルがないから文句を言うだけだった。
# mkdir /var/cache/logwatch
まぁ自分でフォルダを作るほど強力ではないよということです。よくあるエラーです。
で、logwatchと聞いて、ログファイルの整理でもしてくれるのかと思ったが、それはsyslogだな。
すると翌日、メールが届いた、Logwatchから…
読むと一日のログファイルを集計してくれてある。
Apacheで404が出てる場所を集計したり、suを使った人を集計したり、SSHのログイン状況を集計したり、
あとディスク容量の状況も送ってくれる。
これは穴があったら発見しやすくなったり有用だな。助かるな。
ログなんて確認するのは大変だしね。
ところで、部の本の原稿でいろいろ書いたのだがいくつか気になってること。
FTP over SSLって使ってる人いるのか?
聞く話では、FTPのセキュア化にはSFTPが使われることが多くて、SCPを使う人もいると。
どちらもSSHのサブセットだよね。で、僕は以前FTPを廃してSSHdでSFTPをすることにした。
それはよいのだが、セキュア化する話でFTP over SSLが出てきた例は見たことがない。
あまり必要性がないのかな。ちょっとした疑問。
Postfixとqmailはどちらも人気だけど、まぁこれはPostfixの方が人気なのは確かだと思うんだ。
まぁもちろんこれよりもSendmailの方がね。あれは真祖だよな。
それはよいのだけど、POP・IMAPのためにつかってるDovecotだが、微妙に人気が悪い。
RedHat系ディストリビューションでだいたい標準なんだけどね。
どっちかというとCourier-IMAPの方が人気あるけど実のところどうなんだろ?
だからどうしたという話なのですが。
たまに用事がある市役所一階
さて、今日はちょっと用事で住民票を取らないといけないと言う。
どうも銀行口座を作るためだそうで。メールオーダーで作るみたいだが。
でも僕は銀行にパスポートに住所を書いたものを持って行っただけで作れたけどな。
ただ、住所は手書きだしね。これで問題なかった。まぁ確かに住所の確認という意味では不十分。
で、今回運転免許証を出すつもりで、これはきちんと住所は書いてある。
ただ問題はあるけど、住所が変更したあとしばらく放置しておいても咎められない気はする。
まぁそんなわけで実際に住所がそこにあることを示す証拠として、
電気・ガス・水道・NTTの固定電話の領収書の原本とか出せとかいてあるわけだ。
で、その中に住民票の写しがあるからこれでいいねというわけ。
ところで、住民票の写しは300円なのですが、一人分でも世帯全部でも値段は同じ。
で、せっかくなので全部を取りました。
で、本籍・筆頭人と世帯主・続柄は省略できると。
別にどっちでもいいと思うのだが両方省略すると書いたようだ。
本籍・筆頭人は住民票と戸籍を結びつけるものだな。
戸籍には生まれた事実などが書かれていて、住民票には住んでる事実が書いてあると。
逆に戸籍には附票があって、住所の履歴が書いてあると。これもまた戸籍と住民票を結びつけるもの。
で、世帯主・続柄は、確か僕のやつには父の名前と子と書かれているはず。
まぁこれこそ省略する意味のないことだと思うけどね。
さて、窓口に出すと受付番号の書いた紙をわたされてしばらく待つことに。
それでしばらくしたら出てきた。まぁレーザープリンタでやれば終わりだしね。
全部の方がお得感はあるのだけど、ちょっと問題が…
最後のページにしか「この写しは、世帯全員の住民票の原本と相違ないことを証明する。 ○○市長 ○○○○」
という文言がない。
4人の世帯の全部は4枚になってるのだが、4枚を切り離すことはできないということ。
えらくかさばるな。まぁ特に問題ではないが。
ちなみに、同じ世帯の人なら誰の個人の住民票でもとれますよ。まさにムダなことをしたということ。
ただ、これだけ省略しても、住民となった日と前住所は書かれてた。まぁ確かに使うことだからな。
しかし、コンピュータとレーザープリンタでできるので便利ですね。
今は戸籍もコンピュータ化されたのでね。それでか証明コーナーがスマートになってた。
ただコンピュータ化前の戸籍は紙のままらしいけど。
これが必要な場合は結構限られる気はする。
最近まで知らなかったのだが、死人の戸籍抄本は多分簡単にとれる。
というのも、筆頭人が死人の戸籍というのもけっこうあるらしいのですよ。
本籍地が大阪府大阪市中央区大阪城1番、筆頭人が山本孝の戸籍があって、
その人の子の山本仁が同じ戸籍にいましたと。ついでにおなじ世帯でもありましたと。世帯主は山本孝。
それで孝さんがなくなられた後、仁さんが住民票を取りに行ったら
本籍:大阪府大阪市中央区大阪城1番 筆頭人:山本孝と書いてあると。
不思議な話だね、自然に筆頭人は変わらないものらしい。
その一方、世帯主は変わってるだろうね、もしかすると彼の姉の山本奈緒子になってるかもしれない。それで続柄も弟になってると。
世帯主はここにいる人じゃないといけないから。
と、どうも戸籍に載ってる人全員が戸籍から消えるか、転籍しない限り、たとえ死人でも残ってるらしい。
当然だけど仁さんが自分について書いた戸籍抄本がほしいときは筆頭人には山本孝と書くわけだけど、
このとき孝さんの戸籍抄本もとれると。当然戸籍謄本を取れば全員載ってる。
ところが、コンピューター化のとき、その時点で戸籍から消えてる人は書き写されてない場合があるらしい。
だからこれより前に山本蓮が結婚したので違う戸籍に移ってたら、その人はもしかするとコンピューターの戸籍にはないかもしれない。
実際は残ってしまってる場合もあるらしい。筆頭人は絶対に残るらしい。
さすがに消えてたら、1ページ目にないのに筆頭人になってしまうからな。
ただコンピューター化以後に消えたひとは「除籍」と書かれて残ってるらしい。
ちなみに戸籍謄本も戸籍謄本もさっき言ったのと事情は同じで、
値段は一緒、切り離し不可。家族でまとめてパスポートを取るときに便利ですよ。
といってもパスポートの切替のためには戸籍はいらないんだけどね。
それと住民票は基本的に住民基本台帳ネットワークで証明できるので不要。これは便利だな。
もともとは切替のときにも必要だったはず。
ん?コンピューター化されてどういうわけか改名しておるな。
戸籍全部事項証明書・戸籍一部事項証明書…謄本・抄本には写しの意味があったけど、これは写しじゃなくて中身を書いてるだけか。
でも何も違わないと思うのだが…
まぁしかし住民票が必要な事態はすごく少ないですね。
昔は役所への届出のたびに必要な印象さえあったけど、住民基本台帳ネットワークでほとんどいらんようになった。
いや、住民票はめんどくさいよ。市役所平日しか開いてないし、そりゃカードがあれば自動交付機がつかえるけど。
だから今回住所を示すために必要だったけど、こんなときにたまに必要なぐらいだ。
それにこれも電気・ガス・水道・NTTの固定電話の領収書の原本を提出できれば不要。
そういうもんです。
というか住民票の写しも厳密には提出時点の住所を証明するものではないしね。
住民票の写しを受け取ったあと、住所を移せば…そういうこと。
まぁそれに手紙が届かないで損するのは自分だから自己申告でもたいした問題はないしね。
その程度のものですわ。
Ajax+PHPという組み合わせは何かといい
機関誌(?)を製本してたのだが、うーん分厚い。
ちなみにB5で僕の原稿は10ページ。ただ文章ばっかで黒い。
挿絵がないのは、挿絵を入れても説明しやすくなるわけじゃないしとか。
ただ多い人だと22ページも書いてた。挿絵が多いので…
さて、部のページにカウンターをつけることに。アクセス解析が主な目的です。
いろいろ考えたのだが、洒落たものではないが、fdiaryで使ってるものを改造して作ることにした。
あれは古い機能がたくさん残ってるので整理して、気付いたところのセキュリティーを強化しておいた。
ところであれはAjaxで表示をさせてるが、こんな仕様なのはかつて、Javascriptの外部スクリプトの読み込みから始まったから。
その昔NAVA21のサーバーのカウンターをLibserverが提供するにはこの方法しかなかったと思ってた。
サンプルのカウンターは表示するところでPHPのinclude()を使う例ばっかりでね。
当時はPHPを自由自在に扱うところまで行ってなくて、人様のスクリプトを調整するだけだった。
多分初めて大部分を自作したスクリプトだと思う。
その後NAVA21のサーバーを廃止したつもりになった以後も改善をして、
Ajaxを使って表示させるようにして現在に至る。
今回もカウンターをPHPで作り、Ajaxで表示させることにしました。
やはりコンテンツの幅が広がるので。どうしてもPHPでinclude()するとね。
ただクライアントは選びますが。それでも多くのブラウザでうまく見えるようにprototype.js使ってるけどね。
Ajaxを使うメリットは読み込み中も画面が固まらないこと。非同期通信とはこのこと。
うまいこと行った。うん大成功。
ところで、prototype.jsは何かと便利なものです。
これを使っていろいろ勉強したいと思うけどね。実用的なページを作れるかはあれだが。
ただページの移動なしに画面の中身を切り替えられるのはおもしろいと思う。
シンプルなものを考えるなら。
function change(url){
$('main').innerHTML = "Now Loading...";
new Ajax.Request(url,{method:'get',onComplete: displayData });
}
function displayData(httpObj){
$('main').innerHTML = httpObj;
}
こんなもんでいいんですね。うん、prototype.jsは便利ですね。
Ajaxは非同期通信を中心に据えて、画面を動的に書き換えることが多いけど、
prototype.jsの$(‘id’)の記述法だけでも便利さが感じられる。
これを使わなければdocument.getElementById(‘id’)を使えばいいんだけどさ。
まぁただAjaxはJavaScript・CSS・XMLを中心に据えてるわけだけど、
これに対応するクライアントじゃないといけないわけで。
そりゃMozilla Firefox・Internet Explorer・Operaとかは対応してるよ。
ただw3mは対応してない。
w3mで来た人をガッカリさせないページを作ること、これは大切なことだよ。
まぁなんかおもしろいものが出来たらそんなことも話したいなと。
本当に燃やさないゴミは少ないみたい
さて、ゴミの回収に手数料を取る日までもうすぐ。
えーっと、もう燃やすごみ1回しか残ってないのか。
ところで、背景として資源ゴミというのがあって、
ビン・カンなど 月一回
ビンは色で4つに分類・カンはアルミ・スチール・スプレー缶(アルミ缶は自治会でも回収してるなぁ)
ペットボトル・白色トレーもあるけど、これはスーパーの回収箱に入れてるからこの際無視
月替わりで、廃食油、蛍光灯・電球・水銀温度計、小型の金属(フライパンなど)・乾電池
資源ステーションのカゴに入れる
紙・繊維類 月一回
新聞、雑誌・雑紙、段ボール、紙パック、古着・古布
くくって資源ステーションに出す、ただ紙パックはスーパーに、それ以外は自治会の回収に出してるので無視
容器包装プラスチック 月三回
出し方は燃やさないゴミと一緒で普通のゴミステーションに、適当なゴミ袋に入れて出すことになる
ただ、ペットボトル・白色トレーは容器包装プラスチックでもあるけど、今まで通りらしい
勝手に資源ステーションと言ってみたが、カゴを配置しないといけないから、
普通のゴミステーションよりも数が少ないのよね。特に問題ではないが。
で、それ以外のゴミを燃やすゴミ・燃やさないゴミに分別して出しなさいということ。
燃やすゴミは週2回、燃やさないゴミは月1回。もともと月3回だったけど、容器包装プラスチックの回収開始以後これ。
ところが、最近ゴミの分別の方法の資料を見ると、何か違った。
汚れた容器包装プラスチックが燃やすゴミになっとる。
…あれ?確かいままでプラスチックは全部燃やさないゴミだったよね?
どうもこれが新ルールらしいです。
確かに製品プラスチックは燃やさないゴミのままだしね。
そんな観点で最近一週間を過ごしてたのですが、驚くべきことが起きた。
燃やさないゴミが少なすぎる。それこそ一ヶ月貯めても袋がいっぱいにならないぐらいに。
中に入ってるものは、金属を含むものがほとんど。アルミホイルやその仲間ぐらい。
金属は燃やすのに適当じゃないから燃やさないゴミにするからね。
余談なのだが、いつぞに燃えるゴミから燃やすゴミに名前が変わったんですよね。
たとえば塩ビパイプ、これは燃える、ただ不完全燃焼を起こして有害ガスを発生させやすい。
だから燃やしちゃいけないと、そういうことを考えろという意味で名前を変えたそうだ。1文字変えて人の心が変わればすばらしいもんだ。
まぁ少しは影響はあったのではないかな。もっとも、そのときに透明か半透明の袋で出すようになったというのが大きいけど。
まぁ、製品プラスチックはたまにしか出ないのでね。容器包装で出なければほとんど出ないわけだ。
ところで、回収したプラスチックのリサイクルというのがどういうものなのか、
まぁ一番簡単なのはその樹脂を加工し直して使うと。
回収したPET樹脂を、フレーク状にして衣類にするとか。
ボトルに戻せないのは衛生的な問題らしい。ちょっと納得いかないがこれはありだ。
あと、熱分解してコークスの代わりに使うとかいうやり方もあるらしい。
これはただプラスチックばっかり集めれば話にはなるものらしい。
あと、油にしたりして、それを利用していろいろ使うと。
うーん、この方法ならきれいに洗って出さなくてもいいんじゃないのか?
あと、最終手段として、焼却して熱を利用するという方法もある。
ただ、これはちょっと厄介で、焼却炉が耐えられるかとか、燃えにくいプラスチックは困るとか。
あと、熱というのはどうしても効率が悪いのでね。
なのでもっとも適切なものを選んでリサイクルするんでしょう。
まぁ見てもわかるとおり、ペットボトルをリサイクルに出してもペットボトルになるわけじゃなくて、
鉄になってたり、電気になってたりするということ。
なので、まぁ実感しにくいわな。
このあたりは紙のリサイクルと違うわけで。紙は曲がりなりにも紙に戻るからな。
ところで、今日、ゴミの回収に来たのは2時ごろ。実は結構早い。燃やすゴミの日だからね。
遅いときだと夕方の5時まで回収してたりするからな。
市内全域を1日で集めて回らないといけない日もあるから、そんな日はひどい。
まぁそれにしても朝8:30までに出せとか言っておいて、遅いとそんな時間まで放置されるのはちょっと気分が悪い話だな。
多分朝から回ってるんだろうが…早く集めてくれることにあまり注目しないからね。
ご苦労なことです。多分人やパッカーの資源を有効利用するためなんだろうけどね。
まぁええけどさ。
人の作った土地は地図を見ると気味が悪いね
昔見つけたのだが、人力検索に次のような問題があった。
「天保山から咲洲に自転車で行きたいけど、どうするのがよいのだろうか」
難しい問題だ。
歩きなら、大阪港からコスモスクエアまで階段を上がって地下鉄に乗れと、
車なら、大阪港咲洲トンネルを走れと、有料だけどね。200円なり。
ところが自転車・原付は通行不可。
目の前に見えてるのに走っていけない、どうもそうらしいです。
そこで解決法が載ってました。
なみはや大橋を渡り大正区に入り、新木津川大橋を通り南港通に出て走っていけばよいと。
えらい遠回りだな。
ところが、よく考えてみると、たとえばWTCコスモタワーの所在は大阪市住之江区南港北一丁目…
ああなるほど。そりゃ、住之江区の本州部分から回ってくるのが正攻法やわな。
埋め立て地の所在というのは難しいもので、埋め立て始めたところからどんどん伸びていくことになるのだろうね。
毎日バス停を少し家の前に近づけていく話があったが、それに近いかもしれない。
ちなみに、咲洲には何度か行ったことがあるが、一度の帰りをのぞいて、天保山のほうから渡ってるはず。
その一度の帰りというのは、鶴橋〜中ふ頭と乗るとき、コスモスクエア経由で行ってえらい運賃が高くて悲しかったので、
住之江公園経由で帰った話。ニュートラムはのろいな。その後運賃体系は統一されて現在にいたるが。
しかし、ちょっと地図を見てて気づいたのだが、東京湾の13号地は変だな。
13号地言うのも変な言い方なのだが、複雑すぎて一言で言えない、
現在の町名で言うと、江東区青海1〜2丁目・港区台場1〜2丁目・品川区東八潮、
1つの島が3つの区に割れているという気持ち悪い状態。これ人工島ですよ。
江東区はさっきの住之江区と似てて、どんどん伸びていったらここにたどり着いたと。
区の中心にあるであろう区役所からは離れているけど、橋を渡り続ければつきますね。
交通の便は随分悪そうだな。
港区は、埋め立てのときに埋まってしまった、台場やらの元々の所属だから。
まぁわからないことはないんだけど、港区の中心部との接続ってレインボーブリッジなんだよね。
首都高速と無料の車道と遊歩道はある。遊歩道は自転車を押すことすら禁止。
あと、新交通が走ってるから、まぁなんとかなるのかもしれない。
港区の本州から台場まで自転車でどうやって行けますかという質問もあったのだが、
答えは、中央区に入り晴海通を通って橋を渡りつつ江東区に入って、さらに橋を渡れと。
結局つながってないのと一緒のような気もしないことはない。
極めつけは品川区東八潮、ここは首都高速でしかつながってない。
しかも東八潮の中にインターチェンジはない。これは明らかな飛び地だ。
ただ、救いは、全域が公園で人は住んでないということ。
それぞれ思惑はいろいろあったんだろうが、全部江東区ならば13号地の不気味さはなかっただろうな。
そして、実はあの近所に新しい埋め立て地が出来てるらしい。中央防波堤、
ここは今のところ、車道でかつながってない。さっき出てきた江東区青海と大田区とそれぞれトンネルで。
あと、橋で江東区若洲とつながる予定。まぁ車道だけかなと予想したけど。
人工島というのは、急に出来るので、どこの所属かというのはもめるところではありますね。
この中央防波堤でも13号地のようなことになったら、それはどうかと思うしかないね。
大阪港の埋め立て地はシンプルで、南港は住之江区・北港は此花区、まぁその程度で済むということです。
しかし、東京湾というのは江戸時代にはすでに埋め立てということをしてたんですね。
だから、埋め立て地がなければと考えてはいけないぐらい埋め立て地だらけ。
しかし、海に面した都市というのはゴミを海に埋めると言うことをするのだな。
豪快な話だ。
地元では、埋め立て地の残量がまずいので、まずかさばる容器包装は協会に押しつけて、
現在の炉でも安全に燃やせるものは極力燃やして、容積を減らせ減らせとやってるわけですがね。
思うところはあるのだろうが、埋め立て地を使う港湾施設があるということだ。
うーん、都市というのは何かと違うね。だからいいとは言わないけど。
ところで、夢洲はどうなったんだろ?オリンピックの選手村にして、その後団地にするとか言ってたが…
HTTPSを強制的に使わせるBLOGを作る
昨日・おとといの記事を編集して印刷した。
これで資料として便利に使えると考えて、帳面につけておいた。
ところで、HTTPSを使えるようにしただけでは意味はなくて、
これを使って貰わないといけない。
そのためにBlogを改造してました。
まず、1つはログインフォームの書き換え、httpからhttpsに変えるだけ。
ところがこれだけでは不十分であることがわかった。
実はこのBlog、ログイン情報の保持のためにセッションを使ってました。
セッションというのは、クライアントにキーのCookieを与えて、値を保存しておくと。
このキーをSessionIDというのだけどね。
それで送られてきたCookieのキーから値を引っ張り出してくるというもの。
普通にCookieを使うのとの違いは、値を管理するのはあくまでもサーバーだということ。
ただセッションはサーバーが管理するので、サーバーの手間が増える。
僕はCookieでやる分が多いけどね。
改ざんしても何の得にもならないカウンター用のCookie、
MD5ハッシュを応用して、改ざんできないはずのログイン保持のCookieとか。
この話は後でするとして、SessionIDの流出防止のためには、SessionIDも含めてすべてHTTPSで取り扱えばいいと。
そのためにやることは、
・HTTPSが有効でなければSessionIDを発行する動作を行わない
・SessionIDを保存するCookieをセキュア専用にする
PHPのSessionを使う部分をこの要領で変更
if($_SERVER["HTTPS"] == "on"){
session_set_cookie_params(0, "/foo/","",TRUE);
session_start();
}else{
header("Location: https://foo.example.com/foo/");
exit;
}
まぁこんな感じかな。これはHTTPSなしではHTTPSで出直してこいということになってるな。
さすがにここまでしなくてもよければ、Sessionに関する処理をsession_start();の後ろに納めて、
それで、else部分を消せばいいよ。
あと、session_set_cookie_params()の第四引数をTRUEとしているが、これがSessionIDを格納するCookieをセキュアにすると。
これによってSessionIDのCookieはHTTPSでなければ送信されなくなる。
これでとりあえずいいでしょう。少なくともSessionIDはHTTPSを用いることになるし。
さて、これでとりあえず1つ問題は解決したのですが、
今度BLOG全体で認証をかけたいという要望なんてのがありまして、
ちょっと研究してみることにした。
まず、一番に思いつくのはBasic認証だけど、まぁこれは却下だな。
・ログイン画面がブラウザの用意したので不細工
・ログアウトという考えがなくてブラウザが勝手にパスワードを送り直してくれるのに期待するしかない
・ブラウザが勝手に送り直す範囲がはっきりしないので、予想がつかない
まぁ結局そうなると、自分で認証機構を取り付けるしかないよな。
で、管理ページは改めて制限をかけないことにしたので閲覧ページだけすることにした。
こんな感じに取り付けることにした。
if($_SERVER["HTTPS"] == "on"){
if ($_POST['passwd']){
$cookie= auth($_POST['passwd'] , $_SERVER['REMOTE_ADDR']);
if(!$cookie_key){
loginform("パスワードが間違っている");
exit;
}else{
setcookie("authed",$cookie,time()+3600*24*30,"/foo","",TRUE);
}
}else{
if(!authed_check($_COOKIE["authed"],$_SERVER['REMOTE_ADDR'])){
loginform("");
exit;
}
}
}else{
header("Location: https://foo.example.com/foo/");
exit;
}
まず、HTTPSでなければ出直してこいというのはさっきと一緒。Redirectされる。
で、パスワードが送られてきたらこれを審査すると。後で説明するがauth()に審査してもらう。
返り値はCookieの値にするべきもの。これが入ってなければパスワードが違うと言うことなので、
ログイン画面をエラーと共に再表示。exit;となってるのはここでスクリプト終了という意味だな。
入ってればこれをCookieの値にすると。第六引数がTRUEなのはHTTPS専用ということ。
で、パスワードが送られなければCookieを読み取ってこれを審査。authed_check()で審査する。
で、これが通らなければログイン画面を表示と。
次だが、審査用の関数を作る。それぞれのページがincludeするスクリプトに書いておいた。
function auth($passwd , $addr){
$addition = "hoge";
$separator = "hage";
$hash = "713b3a9ec658284f93c8167ed652dbd4";
$passwd_hash = md5($addition.$passwd);
if ($hash == $passwd_hash){
$rnd = md5(rand());
$cookie = $rnd .",". md5($rnd.$separator.$addr);
return $cookie ;
}else{
return NULL;
}
}
function authed_check($cookie , $addr){
$separator = "hage";
list($rnd,$cookiehash)=explode(",",$cookie);
$addrhash = md5($rnd.$separator.$addr);
return ($cookiehash == $addrhash);
}
長いな。
まずauth()、送られてきたパスワードの前に$addtionalを取り付ける。
パスワードが1234567890であればhoge1234567890のハッシュを取ると。
で、この要領で作成した正解のハッシュを$hashに入れてあるから比較する。
こうすると、ハッシュが盗まれても、まぁ解読できんだろうな。
MD5のハッシュから、パスワードと異なる元の文字列を得るのでもむずかしいのに、
hoge〜となるものはまぁ見つからんやろうね。
これはUNIXのパスワードなどでSALTというのをつけて管理するけど、理屈は似ているはず。くわしいのは知らない。
それで次にCookieの中身。
ランダムな文字列・$separator・IPアドレスの順にくっつけた文字列のハッシュを取ると。
だからCookieを削除しなければIPアドレスが違わなければ有効ということ。
この$separatorが肝だな。これは漏れてはいけない。
ここでIPアドレスの違うものを作りたいと考えて、方法も知ってても、$separatorがばれない限り大丈夫。
さっきと同じ理屈で、〜IPアドレス となる元の文字列は見つからんだろうし。
まぁ実際さらに現実的じゃないように工夫してあるんですけどね。
ランダムな文字列とハッシュをカンマで区切って連結させたものをCookieに登録すると。
あと、loginform()の中に
setcookie("authed",FALSE);
を入れておく。loginform()が実行されたらCookieが消えると。
ログアウトもこれを開くだけでいいので、なかなかおもしろいと思ったので他のスクリプトから勉強させてもらった。
しかし、人様の作ったBLOGのシステムを改造するというのは一見難儀そうだが、
随分と見通しのよいスクリプトで驚いた。おかげで作業がはかどった。
完璧とは言えないが、ほとんどの希望には応えられるものができたのじゃないかなと。
SPAMメールでないかはっきりさせるSMTP-AUTH
昨日の鍵を活用していろいろ作業をしてました。
ところで、なにげにPostfixにも鍵を使うと書きましたが、本当に使いますよ。
SMTP-AUTHという認証のためにね。
しかしSMTP-AUTHはあまり使われていないですね。
SMTP-AUTHはオープンリレー対策に重要だと思うけどな。
まぁ実際多くのプロバイダーではPOP before SMTPでやってるからな。
SMTP-AUTHは個人が自分のところのメールエージェントを強固にするのに使われてるところが多いな。
実際の効力は、POP before SMTPを遙かに上回る。
だってPOP before SMTPはSMTPのアクセスしてきたIPで最近POPの認証を通ってたらリレーを許可するということ。
ということはある人が連続的に@niftyのPOPにアクセスしてて、
そこで悪意が忍び込んで同じグローバルIPからSPAMを送る、こうするとそのSPAMを受け取ってしまう。
あまり問題ではないと思うかも知れないけど、ケーブルテレビの一部には1つのグローバルIPを共有するものがありますからね。
悪意は近所に住んでてCATVに加入しているだけかもしれない。
さて、SMTP-AUTHは確かにすべてのメールクライアントで対応しているとは言えませんが、
Mozilla Thuderbird、Microsoft Outlook、Windowsメール と Outlook Express、Becky!ぐらいは対応してる。
すなわちほとんど問題ないと言えないことはない。
ここで認証のために/etc/shadowを読みながらすると、Linuxのユーザー名・パスワードを再利用できて便利なのだが、
このためにはCRAM-MD5などは使えなくて、plainなどの平文の認証を使わないといけない。
そうなると暗号化しないと危険。このために鍵が必要だったんですね。
SMTPS、セキュアなSMTP、SMTP over SSL。
しかし何かとめんどくさいな。そりゃPOP before SMTPを構築するよりは楽だろうが。
まず、/etc/postfix/main.cf
smtpd_tls_cert_file = /etc/pki/tls/certs/newcert.pem
smtpd_tls_key_file = /etc/pki/tls/certs/newkey2.pem
smtpd_use_tls = no
smtpd_sasl_auth_enable = yes
smtpd_tls_auth_only = yes
smtpd_recipient_restrictions = permit_mynetworks , permit_sasl_authenticated , reject_unauth_destination
ここでsmtpd_use_tls=noなのに違和感があるかもしれないけど、
SMTPSのPort 465に専用にするため、同様にSubmissionのPort 587専用にする例もある。
まぁなんのことやねんというのはあるけど、Port 465はSMTP over SSL専用。
実際はSSLを強化したTLSだからSMTP over TLSだが、細かいことは気にしない。
Submissionは利用者専用以上の意味はない。そして、SMTP over TLSはPort 80でもPort 587でも何でも使える。
Port 25以外のPortを用いてメールを送信できることは利用者にとってありがたい話だったりする。
OP25Bをしいているプロバイダは多いからね。
部のLANではこの規制を敷いてるよ。だって、ウイルス怖いからね。
ちなみにうちは違うよ。だってそんなことしてたらLibserverでメールサーバーできませんから。
OP25Bは自社のメールサーバー以外のPort 25の接続を遮断すること。
これによってそのプロバイダの人は任意のメールサーバーにメールを直接送れない。
以前手動でメールを送ることについて記事にしたな。http://libserver.ddo.jp/fdiary/read.php/1179492026
この記事を見ればわかるが、直接先方のメールサーバーにつないでる。これを不可にするということです。
その結果、他のプロバイダーのメールサーバーに送信してもらうことが出来なくなる。
その対案がSubmissionだったりする。Submissionは利用者専用のポートでここに流し込めばどんなところにも送信してあげると。
もちろん利用者専用と言うのだから、POP before SMTPで認証をかけてるところが多いけど。
で、うちは、SMTPSでSMTP-AUTHをすると。
その後で認証を有効にするための記述があるが、
smtpd_tls_auth_only = yesとなっているのは暗号化必須という意味。だからTLSをONにしたときだけ、AUTHが使えると、
次、認証につかうSASL2の設定、/usr/lib/sasl2/smtpd.conf
wcheck_method: saslauthd
mech_list: plain login
で、次に/etc/shadowを使って認証するようにSASL2を設定しないといけない。標準はPAMなもので。
/etc/sysconfig/saslauthdを一箇所変更、
MECH=shadow
これであとは、saslauthdを起動させて、chkconfigで自動起動するようにしておく。
最後にSMTPSを使えるように仕上げ、/etc/postfix/master.cf
smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=yes
という風にコメントを外すだけでOKなはず。
これで、SMTPSに限り、TLSが有効になる。それどころか強制される。
これで完了、restartさせて、CA証明書をクライアントに登録して、
それでSMTPの設定で、ユーザー名とパスワードを使用にチェックを入れて、保護された接続を使用でSSLを選択。
ポート番号が465になってることを確認して完了。これで認証して送れるよ。
SPAMの加担者とならないために、こういうことは大切ですよ。
もし、認証もなしでどこへでも送信できたら、中継したところもグルだと疑われる。そういうもんらしいです。
そのための情報網がRBLだったりするのだけどね。オープンリレーできるメールサーバーからのメールは拒否するための道具です。
あと、SPAMをよけるための工夫としてDKIMがあるな。
これはDNSのTXTレコードにRSAの公開鍵と指示を入れておいて、
メールの本文・一部のヘッダの内容のSHA1ハッシュを秘密鍵で暗号化したものをヘッダにつけて、
受け取った人が、暗号化されたものの暗号を公開鍵で解いて、本文・指定されたヘッダの内容のSHA1ハッシュと一致するか確認すると。
ところで送信元のメールアドレスのドメインのDKIM用のTXTレコードを確認すると公開鍵と指示が書いてある。
この指示の中には、うちからのメールは全部DKIMを使ってるとか使ってないとか書いてある。
これに従って破棄するなりすればよいというわけ。
まぁ特に意味はなさそうだが、今後普及すれば役に立ちますよ。まだあまり普及してないがな。
あと、導入してみるのもおもしろそうだが、DNSの管理は自分でやってないので…