自堕落な技術者の日記

手持ちのRedHat7.3のイメージでVMwareのホスト側のバージョンアップをしたらバージョンの不一致のようでフォルダ共有機能が使えなくなってしまった。このままだと面倒臭いので、入れなおすことにした。忘れっぽいのでメモを残す。

1. VMwareアプリのメニューで「VM＞VMware Toolsのアップグレード」を選択。
2. % mount /dev/cdrom /mnt/cdrom
3. 適当な場所で解凍

   % cd /tmp
   % tar xvfz /mnt/cdrom/VMware-*.tar.gz
   % cd vmware-tools-distrib
   % cd vmware-install.pl
   

   RedHat7.3ならば、カーネルが古すぎて対応できない1つを除きバイナリが入っているのでコンパイルの必要はなかった。
4. 以降、デフォルトでOK
5. インストーラ終了後、vmxnetドライバを設定。

   % /etc/init.d/networking stop
   % rmmod pcnet32
   % rmmod vmxnet
   % modprobe vmxnet
   % /etc/init.d/networking start
   

これでちゃんと、/mnt/hgfsでフォルダ共有が戻ってきた。よかった。

前回は、cygwinにGoogleで開発している関数型並行プログラミング言語"Go"をインストールしようとして失敗してしまった話をしました。

今回は、VMware上のUbuntuでインストールに再挑戦してみたいと思います。

ビルドまでの準備

Goにはgccを利用したものとネイティブなものがあるそうですが、今回はネイティブな方インストールします。

まず最初にmercurialというパッケージが必要になるそうで黙ってインストール。その他、環境変数を設定して、ソースをダウンロードします。

% sudo apt-get install mercurial
% mkdir ~/src/go
% export GOROOT=$HOME/src
% export GOOS=linux
% export GOARCH=386
% export GOBIN=$HOME/bin
% hg clone -r release https://go.googlecode.com/hg/ $GOROOT
requesting all changes (ソース取得の所要時間3分程)
:

ソースの取得はサックリ行きました。

Goのビルド

% cd $GOROOT/src
% ./all.bash (ビルトの所要時間10分程)
　：
--- cd ../test
N known bugs; 0 unexpected bugs

とエラーメッセージも出ずビルドも簡単にできました。

Hello Worldでコンパイルと実行を試す

サンプルのコードをviで書きます。

% vi hello.go

package main
import "fmt"
func main() {
fmt.Printf("hello world\n");
}

インポートするパッケージにはダブルクオートがあるのに、なんでパッケージ宣言にはクオートが無いのか意味がわかりません。

で、コンパイルとリンクです。

% 8g hello.go
% 8l -o hello hello.8
% ./hello
hello world

おお、動いた。

パッケージを使った例を書いてみる

パッケージの使い方を知るために、execパッケージのテストコードから"who"のプログラムをフォークして標準出力に出すようなプログラムを書いてみます。

package main
import ("io"; "exec"; "fmt";)

func main() {
　cmd, err1 :=
　　exec.Run("/usr/bin/who", []string{},
　　　 nil, exec.DevNull, exec.Pipe, exec.DevNull);
　if err1 != null {
fmt.Printf("err1\n");
}
　buf, err2 := io.ReadAll(cmd.Stdout);
　if err2 != nil {
　　fmt.Printf("err1\n");
　}
　fmt.Printf(string(buf));
}

例題その(2)としてencoding/base64の例題で、文字列"aaa"をBase64で円コーディングして表示してみる。

package main
import ("fmt"; "encoding/base64"; "strings";);
func main() {
　s := "aaa";
　buf := make([]byte, base64.StdEncoding.EncodedLen(len(s)));
　base64.StdEncoding.Encode(buf, strings.Bytes(s));
　fmt.Printf(string(buf) + "\n");
}

実行してみると

% 8g t_base64.go
% 8l -o t_base64 t_base64.8
% ./t_base64
YWFh

うん、ちゃんとうまくいってる。

さてと、セキュリティ関係で遊べそうなパッケージは無いか？

Goのパッケージの説明はココにあるんですが、自分が(暗号、PKI、セキュリティ関係で)使いそうなのは

- asn1
- bignum
- crypto/{aes,hmac,md5,rsa,sha1,x509}
- encoding/base64

といったところでしょうか。例えば(crypto/x509はほぼカラッぽなので)encoding/base64の例でも書いてみるかと思い、マニュアルを開いてみるとパッケージのソースコードはココにあります。

で、パッケージのテストコードは一つ上のこちらのURLにあるわけです。

で、使ってみるかと思ったところで、今日はタイムオーバー、、、

プログラミング言語Goの感想をぶっちゃけちゃうに、、、

プログラミング言語Goを昨日よりはまともに見てみたんですが、正直「つかえね〜〜」っていう気がしてきました。

C#, Java, JavaScript、(J)Ruby, (J)Python, Perlなどのモダンなプログラミング言語の必須要素って

• 組み込み、サードパーティを含めて豊富なクラスライブラリが利用できること


• 文字列の扱いに優れていること。部分文字列や検索、一致、置換、正規表現などが提供されていること。


• リストやタプルなどが簡単に表現できやスライス、繰り返し処理がシンプルに書けること。


• オブジェクト指向、または、オブジェクト指向っぽく書けること


• 例外処理を記述できること

かなぁと思っています。そう考えると"Go"には、モダンなプログラミング言語として以下は致命的かと思えてくるわけです。(上の2つは言語設計のところなので今後多分良くなりようがありません。)

• オブジェクト指向っぽくは書けず純粋な関数型言語


• 例外処理が書けない


• 文字列を扱う関数が弱く、正規表現が使えない

昔から並行(concurrent)プログラミングには興味があって、Concurrent-C、Concurrent Prolog、GHC(KL/1)など見てきましたが、確かこれらが作られて結局あまり実用にはならなかった後、POSIX ThreadやJavaのThreadが出てきたような気がします。もうそろそろ、Threadをうまく活用しながらThreadを意識せず書けるような並行プログラミング言語が出てきてもいい頃かなぁと思っていました。

"Go"にはそういう意味で、ちょっと期待してしまったんですが、モダンなプログラミング言語の必須要件と思われるような仕様を無くしてまでメモリリークとかが発生しない安全な並行プログラミングが必要かと思うわけです。

今はまだ、仕様もクラスライブラリも小さいので問題になりませんが、システムが膨れてくると破綻して、いずれ消え行く運命なんだろうなぁ、、、と思ってます。

＜追記2009.11.16＞
コンパイル時間が速いのがメリットと書かれた記事を見たんですが、そもそも大規模システムの開発に向かないので、コンパイル時間の遅さに閉口するようなことは無いのでは？と思いました。

電源アダプタ型Linuxサーバ「SheevaPlug」 - Engadget Japanese

写真はちょっと大きめの電源アダプタという見た目ですが、その実はMarvell社のれっきとしたLinuxサーバ「SheevaPlug」。コンセントに直接挿しておける小型・省電力サーバで、デスクトップ型ホームサーバを置き換える「プラグ・コンピューティング」のための開発キットという位置づけです。先日お伝えしたなんでもNAS化アダプタ「Pogoplug」もこれをベースにしています。

おおっ、これはそそる。欲しい、、、、
開発キットは結構安い。

この紹介記事のコメント欄で「サービスコンセントがあると良かった」って書いてありますがその通りですね。タコ足配線できると最高です。さらに無線LANもあるとよいかも。最近、電源コンセントのところに盗聴器をつけるなんていう事件がありますが、ゲリラ的に勝手にLinuxサーバーが立っていたなんていう事件も出てくるかもしれません。

1234567890 Day

What is this all about anyway?
It's time to party like it's 1234567890 ? 'cause it is! On this Friday, Feb 13 at exactly 3:31:30 PM (PST), Unix time (WTF is Unix time?) will equal '1234567890'.

うぅむ、今日は飲みに行ってグダグダになりそうですが、朝はちゃんと起きてスクリーンキャプチャを取れるといいなぁ、、、と思います。

＜追記 2009.02.14 10:00＞
いやぁ〜〜、ひどく二日酔いですが、ちゃんと起きて待ち構えちゃいましたよ。




新年カウントダウンみたいな気分になりますね、、、









うぉ〜〜〜、1234567890 だぁ〜〜、まぢで、、、、
ＨＡＰＰＹ １２３４５６７８９０！！！

私の管理しているわけではないサーバーであるサービスが動かないトラブルがあってポート8080が競合しているとわかり、なんじゃらほいと調べていたら心当たりのないopenfireが起動されていることが原因だったそうです。openfireって何と思ってしらべていたらJavaで書かれたJabberというインスタントメッセージングおよび最近ではVoIPにも対応しているサービスなんだそうです、、、、

誰だ？、サービス上げたの、、、、、(*´Д｀*)

OpenSSL/Debian脆弱性/dowkdとopenssl-blacklistのブラックリスト生成の違い

乱数ファイルの状態による違いについて、少し調べて別館で説明しています。

CAcert NEWS Blog ? Recent Debian private key generation vulnerability

証明書を無償で発行しているサービスである
CAcertでは、Debian・OpenSSLを使っていたそうですが
以下の2つのWebサーバーのSSLサーバー証明書の鍵が
今回のDebian・OpenSSL問題の弱い鍵を使っており
鍵と証明書を更新したことをアナウンスしました。

- https://www.cacert.org
- https://secure.cacert.org

ルート証明書に関しては古いDebianを使っていたので
影響がなかったそうです。

確かに2008年5月20日に証明書が更新されています。
昔の脆弱な時の証明書をゲットしておけばよかった（＾＾；

しかしながら、悪意があろうが無かろうが誰に対しても
発行してしまうCAcert.orgは、信頼のしようが無いので
変にCAcert.orgのルートを信頼してしまわないほうが
良いと思います。
もし入っていたとしても削除することをオススメします。

CAcert.orgでは、今回のDebian問題に関して、
証明書や証明書発行要求が脆弱な鍵で作られていないか
確認するサービスをやっています。
- http://wiki.cacert.org/wiki/DebianVulnerabilityHandling
- http://hashserver.cacert.org/
PEM形式の証明書や証明書発行要求をペースとして
テストすると、その鍵が脆弱がどうか判断できるようです。
しかしながら、ブラックリストが弱いのか
手持ちの脆弱な鍵を使ったものやopenssl-blacklist-0.3.2の
脆弱な証明書でテストしても
「脆弱である」とは表示はされませんでした。

がっくし、、、、

kurushima @ 自堕落な技術者のヰキ(公開版) - OpenSSL/Debian脆弱性/DebianのOpenSSLはどのように修正されたか

今回のDebianのOpenSSL脆弱性の発端となったソースコードの部分に
ついて調べてみました。

1. メモリ初期化の誤りが疑われる箇所があったから乱数生成の主要部分をコメントアウトしてしまった
   
2. その結果、乱数にはならなくなってしまった
   
3. コメントアウトした部分を元にもどし今回の問題は解決した
   

ということのようです。

詳しくはリンクのページをご覧ください。

kurushima @ 自堕落な技術者のヰキ(公開版) - OpenSSL/Debian脆弱性

Debian OpenSSL問題のまとめ

別館にある自分のウィキでDebian OpenSSL問題についてまとめてみました。
よかったらご覧ください。