製品ニュース|2004年07年28日

記憶容量　23.3GB
最大転送速度 11MB/s
定価395,000円

意外と安く登場しました。
早いうちに安くなりそうです。

今はバックアップにDLT1を使っているのですが、
いよいよ円盤に移るときが来るかも。

Konesa
オージス総研の提供するUMLツール。（開発は米CanyonBlue社）

「次世代UMLモデリングツール」だそうです。
　でも対応UMLが1.4です。
　Eclipse,JBuilderとの連携機能があります。でも、Eclipseって、
フリーのUMLプラグインありましたよね。
　Java, C++のコードジェネレート／リバース機能があります。
C++対応なのは嬉しいです。Javaは多くのツールでサポートされている
ので特に優位性は無いでしょう。
　サーバによるバージョン管理的なものがあるらしく、複数ユーザに
よる作業が可能だそうです。この辺が次世代の所以らしいです。
コンフリクト問題についてはどう解決するのかわかりませんが、
人的な解決方法が一番だと思っているので、どうでもいいです。
まぁ、リソース管理の一元化ができるっていうことは良いことです。

　クライアントは、Javaで動作します。見た目は、ほかのJavaを使った
UMLデザインツールと同じような感じなのですが、動作は軽いです
（StandAlone版で評価しています）。Javaということで、
動作は緩慢なのだろうと覚悟して使い始めてみましたが、
予想外の快適さに驚いています。基本的にはネイティブコードで
動いているようです。（他のツールが遅すぎ？）
　ツールの使用感は、よくあるコードジェネレート付きのUMLツールと
だいたい同じです。クラスやノードを作って、仕様を設定して、
図に配置してという感じで描いていきます。
　UMLとして、クラスの仕様との整合性などをきちんと見るので、
クラスをちゃんと作っておかないと図が描けなかったりします。
この辺は良いところでもあり悪いところでもあるのですが、
いい加減な描き方は許さないという方針は、個人的には好きです。
その時は「後で直そう」と思っていても、いつまでも直さないままで
いるということは良くありますから。
　レポート機能があるのですが、図入りで見やすいレポートを
HTMLファイルで出力してくれます。そのままオンラインで
閲覧できるようにして共有する資料としても十分に使えそうです。
個人的には、このレポート機能に一番興味を惹かれました。

　サーバ(SelfHosted版)は、データベースにOracleを使うようです。
Oracleのライセンスは別途用意しろ、とのことです。このツールの売りらしい
サーバ・クライアントシステム(SelfHosted)を使おうとすると、
結構な出費になりそうですね。

価格体系
・SelfHosted 約100万～
・StandAlone 20万
・Basic 3万（サポートなし）

　最初にニュースを見たときは、もっとローエンドな普及に向けた
ツールを提供してくれるのかと思いましたが、どうもそうでは無かった
ようで残念です。
　このような（SelfHosted版）価格帯・ターゲット層の場合、
単にUMLを描ければいいというだけではなく、プロジェクト管理から
テスト、解析等までを一括して管理したいと思うので、
そう考えるとkonesaでは少し機能が弱いかな、と感じてしまいます。
RationalRoseと比べて値段などで優位性があれば良いのですが、
そうではない以上、無難にRationalRoseを選んでしまうと思います。

　Basicに関しては、コード生成機能が無いので、いわゆるお絵かき
ツールです。ただし、お絵かきツールとしては、図を描くときのマナーに
うるさ過ぎて融通が利かないので、あまり使い勝手は良くないでしょう。
十分なサポートも無いようですので、これならばvisio standard に、
フリーのVisio Stencil and Template for UML2.0を組み込んで
使ったほうが良さそうです。この組み合わせは、最近使い始めたのですが、
単にUMLを描くだけならばとても優れています。

　個人的には、UMLツールは開発ソフトに統合されてこそ使いやすい
ものだと思うので、Eclipse上のUMLプラグインや、Microsoftの
VS2005のモデリングツールに期待したいところです。

--- 2004/07/28
2004/07/29 StandAlone版v2.1を試用して修正

　ホスティングや専用サーバサービスなどで、セキュリティパッチを
当てるための方法についてです。

　簡単なパッチと少数のファイルの更新だけならば、躊躇することなく
更新することができるのですが、要make world、カーネル更新となると
気軽に更新することはできません。
　しかし、ネットワークに繋がっている以上、パッチ等について放置するという
選択肢はありえないので、なんとかして更新しなければなりません。
（致命的でない場合や、回避策がある場合は、パッチを当てないことも
よくあります）
　コンソールからログインできるローカルマシンでの更新では、
ソースから make world したり、場合によっては HDD の
追加・入れ替え等をすることもできます。
　しかし、遠隔の場合にはハードウェアの直接の操作ができませんし、
再起動後に正しくブートできないと、リモート操作では復旧できなくなる
可能性もあります。ちなみに、私の利用しているサービスでは、
無料で行ってもらえるのはHWリセットくらいなので、最悪のケースでも
リセットで復旧できないと困るのです。

　そこで、HDDの別領域にもう１つの新しいシステムを構築して、
そこからブートする方法を試してみました。
　この場合でも、ブートに失敗する可能性はありますが、復旧は容易です。

　FreeBSDでのHDDの領域作成には２つの方法があります。

1)スライスで分ける
2)パーティションで分ける

　スライスで分けたほうが、ブートの処理で綺麗に分けられるのですが、
既に存在しているスライスの容量の変更は出来ないようです。
　試しにdisklabel,fdiskなどで強引に変えてみましたが、残念ながら
論理的に壊れてしまいました。何か良い方法があるのかもしれませんが、
かなり危険を伴う作業のようなので、今回は見送ることにしました。

　パーティションの切り分けは、うまくやりくりすれば好きな切り方に
変更できます。今回は、ほとんど使用していなかった領域を使うことに
しました。

　領域は以下のような構成になっています。

  a:   524288        0    4.2BSD     1024  8192    16   # (Cyl.    0 - 520*)

  b:   524288   524288      swap                        # (Cyl.  520*- 1040*)

  c: 40031649        0    unused        0     0         # (Cyl.    0 - 39713*)

  e:   524288  1048576    4.2BSD     1024  8192    16   # (Cyl. 1040*- 1560*)

  f: 12582912  1572864    4.2BSD     1024  8192    16   # (Cyl. 1560*- 14043*)

  g: 12582912 14155776    4.2BSD     1024  8192    16   # (Cyl. 14043*- 26526*)

  h: 13292961 26738688    4.2BSD     1024  8192    16   # (Cyl. 26526*- 39713*)

　ここでは、ad0s1g（以下、g）にインストールします。homeなどは
複数のシステムで共有することもできますが、swap以外は使いまわさない
ことにしました。
　遠隔マシンへのインストールなので、インストール作業はローカルの
別マシンで行い、設定等が全て完了した状態のイメージファイルを
転送します。
　まず、ローカルに同じパーティションで切り分けたHDDを用意します。
これは、動作の検証のために必要です。次にインストールですが、
gに直接インストールしても良いのですが、標準のインストーラでは
この方法はとれないようなので、別HDDに一旦インストールしてから、
gに丸ごとコピーすることにしました。
　ちなみに、私はこのような作業をVirtualPC上で行っています。
　
　さて、インストールが完了したらtarなどで固めてから
遠隔マシンに転送します。FTPでもいいですが、セキュアではないので
SCPとかが良いでしょう。
　転送したら、gをマウントして展開します。
　gが新しいシステムのrootになります。面倒なので、/usrとか/varも
分けずに全て集約させてしまいました。

注意：gの/etc/fstabを書き換えるのを忘れないように

　コンソールであれば、起動時に、

boot: 0:ad(0,g):/boot/loader

として、ローダーの選択が出来るところですが、遠隔ではそういう
わけにはいきません。

　代わりに、ad0s1aの/boot/loader.confに

currdev="disk1s1g"

とかくことで、gから起動できます。ただし、これは上記のローダー
選択とは、処理が異なります。
　bootプロンプトからローダー(0:ad(0,g):/boot/loader)を選択すると、
boot2（ブートの第2段階）はad0s1gのローダーを使用するようになりますが、
loader.confで currdevにdisk1s1gを設定すると、
boot2がad0s1aのローダーを読んだあとに、そのローダーがad0s1gの
カーネルを読み込み、rootファイルシステムにad0s1gを使うように
なります。
　つまり、この方法では、必ずad0s1aのローダーを使い、
その後のカーネル・ルートファイルシステムを切り替えるということです。
そのため、既存のad0s1aがFreeBSD4.9の場合には、新しくインストールする
システムにUFS2のFreeBSD5を使うことはできません。

　この設定で新しいシステムから起動できるようになるのですが、
ブートできなかったときに、リセット一発では復旧できなくなって
しまいます。

　/boot/nextboot.confという設定ファイルがあり、通常は
これが1回きりの設定として使えます。
　しかし、このファイルが削除されるのは、/etc/rcが実行された
ときなので、カーネルの不都合などでブートが出来なかったときには
いつまでもこの設定を使ってしまします。

　そこで、/boot/loader.4thをちょっといじりました。

:start ( -- ) ( throws: abort & user-defined )

  s" /boot/default/loader.conf" initialize

  include_conf_files

とあるところを

:start ( -- ) ( throws: abort & user-defined )

  s" /boot/default/loader.conf" initialize

  seconds 32400 < if

    include_conf_files

  then

としました。これで、0時00分～9時00分の間にブートした時だけ
loader.conf等が読み込まれ、結果としてad0s1gのシステムが
使われるようになります。9時以降では、loader.conf等が
読み込まれないので、リセットしただけでad0s1aのシステムが
使われます。

　ここで、32400 は 0時からの秒数で、9時のことです。
（9 * 60 * 60 = 32400）

　つまり、8時50分くらいに試しにリブートしてみて、
ダメなら9時以降にリモート側でリセットをしてもらえば
たとえ失敗してもリスクは低く抑えられるわけです。

　FORTHはよくわからないので、この程度しか出来ませんでしたが、
FORTH使いなら、もっとスマートな方法をとれることでしょう。
ただ、長くなるとバグのリスクも増えるので、この程度の変更が
実は良いのかなと思ったりもします。

--- 2004/07/23

　boot loaderで使われる時間は、FreeBSD上の時間ではなく
RTCの時間です。
　UTCになっていると日本時間-9時間なので要注意です。

　環境構築、面倒です・・・。で、ネタ追加。
---

　パーミッション等を維持したままコピーするときに、
tarを使う方法で、昔からよく使う方法です。
　他には、ddとかdumpを使う方法もあります。
ddやdumpは、よりrawレベルな方法です。

　/usr を丸ごと /mnt にコピーする場合。

cd /mnt
(cd /usr; tar cf - .) | tar xvpf -

　展開時にpオプションでパーミッションを復元するので、
rootで実行する必要があります。

　デバイスファイルとか特殊なファイルでは上手くいかないようです。
そんな場合は、dump/restoreがおすすめです。
ちなみに、ddは本当にrawレベルの転送なのでHDD丸ごとコピーとか
そういう時に使います。FreeBSDの管理外の領域でも使えます。
ただし、かなり危険なので要注意。

　ddといえば、0で埋められたファイルや、乱数で埋め尽くされた
ファイルを作るときにも使えます。
　乱数で埋めた10kBのファイルの作り方。
dd if=/dev/urandom of=/foo/bar/random.dat bs=1024 count=10
圧縮が効かないので、ファイルの転送テストをするとき等に使えます。
　ちなみに、0で埋められたファイルは、/dev/zeroで作れます。
もちろん0パディングを利用しても作れます。
　ストレージに依存しない性能を測定するために、入力に/dev/urandomや
/dev/zeroを使い、出力に/dev/nullを使ったりします。

　せっせと移行作業中です。で、ネタを１個。

　割と常識で、紹介してるページも結構あるのですが、折角書いたので
アップしちゃいます。
---

　最近は、FTPのrangeを使った複数コネクションでのダウンロードや
レジューム機能がありますが、昔ながらの方法としてsplitを使う方法が
あります。

split
　指定したバイト単位か行数単位でファイルを区切っていくツール
です。分割ファイルは、name + "aa", name + "ab" ... という名前が
つけられます。OSのインストール時にbin.aa, bin.ab とか出るアレ
です。
　結合は、catを使います。この感覚がUNIXの醍醐味ですね。
というか、conCATenateの略なので、これが本来の使い方なのですが。
　使用例は、
cat name.?? > name.tgz
とか。

　たとえば、100MB単位で分割する場合、
split -b 100m foo.tgz foo.
のようにします。

　転送は、ftpよりssh を使う方がセキュリティ的に好ましいですね。

　転送したら、md5あたりで壊れていないか確認します。
md5 filename
です。
　昔は、sumコマンドとかを使いました。
　md5は大きいファイルだと結構時間がかかるので、今でもsumは
有効なコマンドかもしれません。

スパム対策で、smtpd_client_restrictionsを設定しました。

smtpd_client_restrictions =
permit_mynetworks
check_client_access hash:/usr/local/etc/postfix/bad_sender
permit

permit_mynetworks は無くても大丈夫だと思う。

bad_senderをテキストで編集。

foo.bar REJECT
172.16.1.1 REJECT

などと書いて、
データベース作成
# postmap bad_sender
設定読み込み
# postfix reload

以上。
でも、ヘッダのFROMでキックした方がいいかも。

参考
http://www.kozupon.com/mail/postfix2.html

--- 2004/07/13

やっぱりFROMでないと使い物にならないみたいなので変更しました。

前回の設定も、変なホストが接続してきたときのために、
そのままにしておきます。

header_checks = regexp:/usr/local/etc/postfix/header_checks

ファイルの内容

/^From:.*@\.foo\.bar/   REJECT

など。

正規表現でマッチングを行います。
便利で良いのですが、CPU食いそうですね。

　電波利用料の支払期限が7/19までなので、
Pay-easyを使ってインターネット上で支払ってみました。
　思った以上に便利でした。やっぱり、これからは電子政府ですね。

Pay-easy（ペイジー）　http://www.pay-easy.jp/

　本当は郵便局に行く予定だったけど、寝過ごして時間が取れなかった、
というわけではありませんよ・・・。

　りそな銀行のインターネットバンキングで支払いましたが、
数字の入力のみで名前等を入力しなくていいので、普通の振込みよりも
簡単でした。もちろん手数料もかかりません。これなら、銀行や郵便局に
行く必要はもう無いですね。

　所得税とかも支払えるみたいですけど、e-Taxシステムの中で行われる
ので、e-Taxも使えるようにしておかないといけないようです。
　今年は還付になる見込みで、それは現状でも銀行振り込みで
行われるので、別にe-Taxは要らないんですけどね。
　でも、面白そうなので、e-Taxを使ってみるつもりです。

以前はオージス総研が無料で実施していたのですが、今は行われていません。
その代わりにUMTPのモデリング技能認定試験というのが出来ました。
あとは、OMG認定UML技術試験(OCUP)というのもあります。

ちなみに、前者は15,750円、後者は31,500円もします。レベルがいくつかあって、下から順に取らないといけないので、上位の認定を受けるには結構大変です。しかも、これって役に立つのでしょうか・・・。

実際に使えれば、別に認定なんてどうでも良い気がしてきました。
でも、オージスの試験の移行で、L1-T1が免除なので、L1ぐらいは受けるかも。もしかして、騙されてますか？

でも、UMTPは交通費で９千円くらいかかるのが痛い。
OCUPは会社から会場まで徒歩１分なんだけど。

--- 2004/07/15

UMTPは、モデリング能力を見るもので、
OCUPは、UMLの理解を見るものだそうです。

どちらが重要かといえば、モデリング能力だと思うのですが、
それはできて当たり前なので、むしろ正しいUMLが使えることを
証明することのほうが、認定試験としては有用かもしれません。

「私はUMTPの認定を受けているから、モデリングの技術があるんだ」

と言われても、実務で能力を示してくれないとちょっと信用できませんが、

「私はOCUPの認定を受けているから、正しいUMLを使うことができます」

というのは、ある程度信用できるのではないでしょうか。
もちろん、正しく書けたところで内容がダメなら意味が無いですけどね。

やっぱり有料化されました。
ただし、月５回までは無料なので、まぁ問題ないです。

ちなみに私の振込み回数は、
１月2回
２月7回
３月６回
４月１３回
５月１０回
６月７回
７月３回

あれ？意外と多い・・・。

各銀行口座への配分のための軸には、今まで通り新生を使うとして、
通販振込み用はeBankにしようかな。口座あるし。

7/7の官報（号外 第148号）で告示されています。
ついでに、この号には春の情報処理の合格者発表もあります。

最近、脆弱性を発見した場合の対応が問題になることが多かったのですが、それらの対策として、ソフトウェアの脆弱性を発見したときの届出窓口の一本化が図られました。

IPA http://www.ipa.go.jp
から届け出ることができます。今のところWEBフォームでの届出は準備中で、メールでの受付のみになっています。

基本的に、発見者はIPAに届け出て、IPAが開発者等に報告するという形になるようです。発見者が直接情報を開示することは禁止されています。ただし、必ずこの制度を使わなくてはいけないとか、法的な拘束力があるかということについては、詳しくは知りませんが、多分ありません。

今までは、発見者が開発者等に報告するということが多く、また、報告しても全然動いてくれないことも多く、それで発見者が痺れを切らして開示するということもありました。今回の制度では、IPAが取り次いでくれるので、発見者の負担も減りますし、開発者等もより積極的に行動してくれる可能性があります。発見者自身による開示は訴訟になることもあるので、開示の指針が統一されるのも良い点でしょう。
エンドユーザとしては、開発者に対する圧力が高くなり、より修正が早くなることを期待したいです。もし、こういう状況になっても対応しない会社が多いようだと、結局は裁判の判例や具体的な法規制に繋がって自分で自分の首を絞めることになるので、そうなる前に自主的に努力して欲しいです。というか、脆弱性の対応に関する業界団体の方針というのも聞いたことが無いような現状はどうかと思います。

本当に上手く機能するかどうかはやってみなくては分からないかもしれませんが、少なくとも「発見者が訴えられる→発見しても報告しない→ウイルス・情報漏洩」とかいう最悪のパターンだけは避けられるといいですね。