コアテクの路地

vim: ed コマンドを使う

こんにちは。 転職して 2 ヶ月になる kyagi です。梅雨も明けていよいよ本格的な夏到来ですね。弊社の技術部は私服で勤務オーケーなので、このごろはgraniphでまとめ買いしたTシャツを着て通勤しています。

vi の使用法が好評を博しているということで、私も一席。ネタは「vi で ed コマンドを使う」です。

さっそくはじめましょう。

shell, perl スクリプトを書いている時に、ある範囲の行をコメントアウトしたくなる時がありませんか？そんなときいちいち、移動と削除を繰り返し入力するのは面倒くさいですよね。この操作を楽チンに実現する方法をお伝えします。

ed の基本的な構文は「ある範囲の行(パターン)」を「なになにする(アクション)」というものです。まず set nu で行番号を表示します。

:set nu

コメントアウトする部分を特定した後、置換を実行します。例えば 20 行目から 30 行目をコメントアウトしたいなら以下を実行します。

:20,30s/^/#/

元の状態に戻す（コメントを付けていない状態）には以下を実行します。

:20,30s/^#//

この「ある範囲の行(パターン)」を「なになにする(アクション)」という考え方は ed だけでなく sed, awk といった言語を理解するキモであり、 perl でのフィルタ作成にも通じるものです 。「ある範囲の行」というのを、ここでは 20-30 行目という具体的な行数をあげていますが、正規表現 を使用してパターンとして指定することも可能です。

前回の「ですくとっぷLinux」で弊社岡野が /etc/ssh/sshd_config に対して行った編集をed を使ってスクリプト化することも可能です。

このような ed スクリプトがもっとも真価を発揮するのは大量のファイルに変更を加えたい場合です。

たとえば CVS の最初のチェックインに際してすべての C ソースの末尾に $Id$ キーワードなどを挿入するような ed スクリプト(add_cvs_keyword.sh) を作成し、find などと組み合わせると何百とあるソースすべての一括編集が可能となります。

find . -name "*.[ch]" -exec add_cvs_keyword.sh {} \;

他にも html ソース内の用語の一括置換（たとえばメールアドレスや社名の変更）など、いろいろな場面で活用できると思います。ただし、webmaster のみなさん、試す前にバックアップとテストは忘れないでくださいね。:-)

差分解析その1

カテゴリ”カーネル勉強”の初回の投稿なので、簡単な説明をします。

ミラクル社内で、定期的にカーネル勉強会を行っています。
現在は、毎週金曜日にRHEL4U2->U3に加わったパッチの解析
を行っています。
(なので、毎週金曜日には、ここのblogに投稿があるはず。)

本日は自分が担当でした。
解析パッチは、下のです。
　linux-2.6.9-CVE-2005-3858-ip6-input-finish-dos.patch 

まず、パッチの中身を見てみます。
=============================================================
--- linux-2.6.9.orig/net/ipv6/ip6_input.c       2004-10-18 23:54:40.000000000 +0
200
+++ linux-2.6.9/net/ipv6/ip6_input.c    2005-12-18 10:32:35.000000000 +0100
@@ -198,12 +198,13 @@
                if (!raw_sk) {
                        if (xfrm6_policy_check(NULL, XFRM_POLICY_IN, skb)) {
                                IP6_INC_STATS_BH(IPSTATS_MIB_INUNKNOWNPROTOS);
-                               icmpv6_param_prob(skb, ICMPV6_UNK_NEXTHDR, nhoff);
+                               icmpv6_send(skb, ICMPV6_PARAMPROB,
+                                           ICMPV6_UNK_NEXTHDR, nhoff,
+                                           skb->dev);
                        }
-               } else {
+               } else
                        IP6_INC_STATS_BH(IPSTATS_MIB_INDELIVERS);
-                       kfree_skb(skb);
-               }
+               kfree_skb(skb);
        }
        rcu_read_unlock();
        return 0;
=============================================================

大雑把にいうと、下記が変更内容
　icmpv6_param_prob関数　->  icmpv6_send関数に変更
　elseの外にkfree_skb(skb)関数　移動

目をしっかり開いてみると
　if (xfrm6_policy_check(NULL, XFRM_POLICY_IN, skb)) {
のelseのときにskbの解放処理がない。。。
if文の中はicmpv6_param_prob関数内で解放。なるほど。
    109 /*
    110  * Slightly more convenient version of icmpv6_send.
    111  */
    112 void icmpv6_param_prob(struct sk_buff *skb, int code, int pos)
    113 {
    114         icmpv6_send(skb, ICMPV6_PARAMPROB, code, pos, skb->dev);
    115         kfree_skb(skb);
    116 }

ここで簡単にまとめると、
　linux-2.6.9-CVE-2005-3858-ip6-input-finish-dos.patch　は
　バッファ解放漏れ対処パッチ
ってかな。

ちょっと横道にそれて、一回の解放洩れがどのくらいかぁ?!調査。
やりかたは簡単
　1　debuginfoが入っているマシンにログイン。
　2　crashコマンド実施。
　3　crash> struct sk_buff
　　 結果
　　crash> struct sk_buff
　　　struct sk_buff {
　　　　　:
　　　}
　　　SIZE: 176
おぉぉ。

次に、どんなときに解放漏れルートに入るのか調査。
　xfrm6_policy_check　がポイント
この関数が0を返すときにバッファ解放洩れが発生。

ルートを追ってみる。
xfrm6_policy_check(include/net/xfrm.h)
　+-> xfrm_policy_check(xfrm_policy_check)
　　+ -> __xfrm_policy_check(net/xfrm/xfrm_policy.c)

__xfrm_policy_checkのリターン値がそのまま、返却されている。
ってことで、__xfrm_policy_checkの関数が0を返すところを調査。

net/xfrm/xfrm_policy.c
    912 int __xfrm_policy_check(struct sock *sk, int dir, struct sk_buff *skb,
    913                         unsigned short family)
    914 {
    915         struct xfrm_policy *pol;
    916         struct flowi fl;
    917
    918         if (_decode_session(skb, &fl, family) < 0)
    919                 return 0;
    920
　　：　　　　　：
    927                         if (!xfrm_selector_match(&xvec->xvec->sel, &fl, family))
    928                                 return 0;
　　：　　　　　：

発見。おぉ見ていくと結構あるなぁ。。
ここでグーグルしてちょっと検索。
xfrm_policy_checkが何をやっているのか検索。
難しい。。。

って検索しているうちに本問題の報告を発見。
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3858

ここに
Memory leak in the ip6_input_finish function in ip6_input.c in Linux kernel 2.6.12
and earlier might allow attackers to cause a denial of service via malformed IPv6 packets　with unspecified parameter problems, which prevents the
SKB from being freed.

情報集まったので、パッチ差分解析結果です。
=======================================================
1. 該当パッチ
　linux-2.6.9-CVE-2005-3858-ip6-input-finish-dos.patch

2. 現象
　メモリリークのため、システムのサービスに影響を及ぼす。

3. 発生条件
　IPv6のDos攻撃を受けた時。

4. 修正情報   
　(1)修正前
     解放処理がなし。
　 (2)修正後
     解放処理があり。

5. 影響度調査
　本件はセキュリティレベルの問題のため、影響度が高い
　と考えられる。
=======================================================

けっこう毛だらけ

最近、海外でも紛争のニュースが多いですが、私の自宅近辺でも外敵の侵略をうけてしまいました。…というのも野良猫軍団の侵略を受け、私の車のボンネットが敵に占領されてしまったのです。

自軍(?)の索敵班の観測によると敵の数は最低６匹。黒くて大きな体躯の偉そうなのを大将として、雑兵とおぼしき４匹の子を持つ親子軍団です。
今年の春頃までは、たまぁ～に足跡が残っている程度で「ま、仕方ないか。」と思うくらいでそれほど気にしていなかったのですが、最近、近所の開発(?)がすすみ、となりにあった林が切り開かれた為、朝方にちょうど車に日が当るようになったのです。さらに敵の軍増強(子猫が生まれたらしい。。)により、毎朝、数匹で蹂躙されるようになってしまいました。

ボンネットの上は土足(!)で蹂躙され、足跡を隙間無くつけられ、しかも毛だらけ。。もう耐えられん！∑(￣皿￣；； ﾝｶﾞｧｰｰｰ!!!さすがに堪忍の限度を超え、小市民として健全なゲリラ的な反抗を試みることにしました。

第一弾、木酢液作戦!!

対策を練る中で、まずは世間の情報を漁り、効果があり、周りに迷惑をかけずにでき、且つ、お金のあまりかからない(^^;)方法をさがしました。
まず目に付いたのが敵の嫌がる臭いを出すとモノ。奴らは柑橘系や酢の臭いを嫌うらしい。
とりあえず反抗の狼煙を上げるべく、木酢液バラマキ作戦を決行する事にしました。近所のホームセンターの園芸コーナーで数百円で買ってきたのがこれです。 ううん、効きそう。なんといっても熟成ですから。

こいつを水で薄めて車の周りに週に二度ほど撒くのです。人間の嗅覚的には、撒いた直後だけうっすらとした香りが漂う程度なので実害は無いはず。

ところが、結果はあえなく失敗。

駐車場が舗装されているので、効果が残りにくいのと、梅雨のせいで流されてしまい撒いてもすぐに効果がなくなる上、奴らは飛ぶんです！(隣の車からね。)さすがに空軍まで動員されてはこの作戦は失敗！しかも居なくなるどころか、隣数台分のボンネットまで侵略を広げる結果となってしまいました。周りの方々ごめんなさい。。

く、悔しい。o(TﾍTo) ｸｩ

これでは敵の思うつぼ、泣き寝入りはできん！！と言うことで、新兵器を導入して雪辱を期すべく、作戦会議は今夜も続くのでした。

RPM APIから見たRPMの動き

つい前まで、RPMのAPIと格闘していた新人mamanoです。入社してもうすぐ4ヶ月目になろうとしています。作業はまだまだ慣れていない状態が続いていますが、会社の雰囲気にはすっかり慣れました。

RPM API、C言語と約1ヶ月ほど格闘していたので、学んだことを少し披露していきたいと思います。RPMはデータベース管理されており、各RPMコマンドをたたくとRPMのデータベースにアクセスすることになります。インストールや、アップデートなどを行うときは同様に、トランザクションを生成し、作業を行います。

APIから見た、簡単な流れとしては

1. データベースを開く...rpmdbOpen()
2. トランザクションを生成...rpmtsCreate()
3. トランザクションを先ほど開いたデータベースに割り当てる...rpmtsOpenDB()
4. 各処理を実行(今回は省略)
5. トランザクション開放...rpmtsFree()
6. データベースを閉じるrpmdbClose()

以上のように、一般的なDBと同じ手順で実行しています。また、実際にパッケージをインストールする場合、依存関係の解決をしなければいけません。処理はトランザクションの中で行われますので、トランザクションを生成した後「rpmtsCheck()」によって依存問題を探します。問題があれば「rpmtsProbs()」によって問題を取り出すことができます。

APIを学習していくと、RPMコマンドを実行して、警告や、エラーを出力した時、どの処理タイミングで吐いたのか分かるようになってきます。詳しい内容はRPM API Document 4.4.2を参照してください。

もうすぐドキュメント作成の作業も始まるので、次回も(できたら)rpmについて解説していきたいと思います。でも本当は雑談を書きたいけど仕事を覚えるのに精一杯で、心の余裕がないんですけどね(汗)。

鳴かぬカラスはなんと鳴く？

自分はミラクルに入る前の前職で、某社にてDBMSの開発をやっていました。
大学の学科ではコンピュータやプログラミングのことを体系だてて勉強したわけではなく、畑違いの分野からこの業界に飛び込んできました。
部署に配属され半年くらいは、一人でデバグできなかったのを覚えています。デバッガ起動していろいろやってみても何が何だか分からなかった…。
デバグの仕方は先輩に教わったわけではなく、ある日突然、ある瞬間に分かりました。
ある変数がNULLポインタを参照していたおかげでした。
０から１０までを徐々に知っていった…、という感じではなく、０から突然１０までを知ってしまった。という感覚です。なぜその瞬間にわかったのか、今でもうまく説明できないです。

その時、目の前のもやが急に晴れたような感覚を味わい感動したのを覚えています。烏の鳴き声を聞いて悟りを開いた一休さんのような心境でした(おおげさかw)。
けどこの感動が今まで自分をこの業界で仕事させ続けてきた一つの要因にもなっています(冒頭で述べたように畑違いの分野からこの業界に飛び込んで来ただけで、取り立ててコンピュータ関連のことが好きというわけでもなかった)。

弊社吉岡の 本日の記事 のように、デバグプロセスのログや先輩の指導から学習することも非常に手助けになると思うし、作業を加速させる手助けになるはず。けど、あの感動をこの業界に飛び込んでくる若い人たちにも味わってほしいなぁ。と思ったりもします。

っと、デバグプロセスのログを残し、共有し、研究していくことに対して反対しているわけではないので念のため。

AAAプロジェクト始動

こんにちは。asianux開発担当のoishiです。
大激白です。
linuxデスクトップの話題も出ていますが。実は弊社のOA用PCのメインプラットフォームは某窓系OSなのでした。。。ああ、言っちゃった。大丈夫なのかな？
というのもね、オフィス製品の利用がさ、いろいろあってさ、社外との業務上の支障があっちゃ困るじゃん。相手に迷惑かけちゃうし。だからね、仕方なくね、そうなっちったのよ。。。なんていうのは言い訳にしかならないですね。単に努力不足としか言い様がありません。MIRACLE LINUXはサーバ向けOSなんだ、というのも言い訳のひとつでした。こういったことの反省をこめての大激白です。
そこで今期第一目標としてOA用PC、つまりデスクトップPCのlinux化を積極的に実施することにしました。サーバ向けではそろそろ地位を確立したといえるlinuxですが、デスクトップは依然各linuxベンダの健闘空しく・・という状況は否めません。当面デスクトップ向け製品のリリースなどがあるわけではないですが、linuxベンダがlinuxを使わずどうする？という基本的なスタンスに立ち返り、ここ2～3ヶ月で社内PCをジャンジャンをlinux化します。
弊社でlinuxディストリビューションといえばAsianux。サーバだけでなく全ての用途をAsianuxでやってやろうというスローガンの下、名づけたこの計画は"make Available All with Asianux"。

すなわち"AAAプロジェクト"の開始宣言です。
と大げさにはいうものの、エンジニアの多くは当然デスクトップlinuxを利用してるわけでして、移行上の問題解決も余裕なわけですよ。。。ねぇ、ミラクルエンジニアの皆さん？
このブログでも、linuxデスクトップPC利用における技術的問題の解説を順次載せていきますので、ご覧のlinux好き皆さんもコメントなどあればご参加くださいねー！！

ミラクルフットサル2

予告どおり、7/19に同じビルの某社とフットサルの試合を行いました。
ちなみに私は、その数日前にスポーツジムに行って、
心肺機能を鍛えて試合に臨んじゃったりしちゃいました。(苦笑)
＃うーん、我ながら若いなあ。。。

ではでは、お互いの会社の名誉（？）をかけた)壮絶な戦いの結果は以下。

• 1ゲーム目 ミラクル 5 - 1 某社
• 2ゲーム目 ミラクル 1 - 0 某社
• 3ゲーム目 ミラクル 0 - 1 某社
• 4ゲーム目 ミラクル 0 - 1 某社
• 5ゲーム目 ミラクル 1 - 2 某社
• 6ゲーム目 ミラクル 0 - 2 某社
• 7ゲーム目 ミラクル 1 - 0 某社

この場合、どっちが勝ったと言えばいいんだろう。
ええい、いいや。
総合計 8 - 7 でミラクルの勝利ということにしておこう。
＃うーん、なんて、自己に都合の良い解釈なんだろう。
   もしかすると、某社は自分とこが勝利したと確信しているかも。。。

特に最後の試合はお互い負けたくないモードいっぱいで、
あたかもW杯の決勝戦のような雰囲気でした。
＃本当ですよぉ～！！

ちなみに試合後の雄姿がこれです。

メンバ若干、疲れぎみのようです。
みんな足がつりそうで、祝勝会（？）会場までの足どりが
めっちゃ重かったっす。。。

ということで、こんな我々と対戦がしたいというチーム、連絡下さい。
＃ちなみに実力はエントリーレベルなので、同等レベル希望です。（苦笑)

Linuxの成長と、ミラクルのそれ

こんにちは。SC担当のyosuzukiです。

先週の金曜日にOracleパートナー様向けにLinux市場動向などを紹介するセミナーを行いました。今日はそこでも紹介したLinuxマーケティングデータをネタに、ミラクルついて考えてみます。

[2005年のLinuxサーバの売上]データ。
2005年のLinuxサーバの売上台数は約12万サーバで前年と比べ約100%成長を示しています。やはり130%の伸びを記録したRed Hatの大きなシェアが目に付きます。
ミラクルは製品的にRed Hatとの差別化の訴求と、大手HW/SWの対応状況に難があり、２００５年の成長は若干足踏み状態ではありました。反面、現場のSCとしては、昨年から今年にかけてミラクルのOS、サービスを必要としているユーザが確実に増えつつあることを感じています。＃おかげさまで多忙な毎日です
HWベンダーの推奨OS(Red Hat)から外れるOSを採用するリスク以上に、ミラクルの技術力、サポート力を理解し、支持をしてくれる有難いパートナー様、ユーザ様であります。

次に[2005年Linux/OSS採用、不採用理由]のデータ。
採用理由の１位はやはり「コストメリット」(TCO,ROI云々)ですが、上位で目に付くのがシステムの｢安定性、信頼性｣と「セキュリティ」です。セキュリティに関しては、確かにWindowsレベルの緊急パッチがここ数年、Linuxで出た記憶がありません。
逆に、Linux/OSSの不採用理由の１位は、「OSS/Linux良くわからん」です。「管理できる人がいない」、「サポートに不安がある」などOSS/Linuxの技術者不足に関連する内容が後に続いています。Unix、汎用機のサポートは別にしてWindowsサポートはどうなんだっ！ という話はありますが、どちらにしてもまだまだミラクルがお手伝いできる潜在ユーザが多くいると感じたしだいです。

世界的にはIAサーバ(特に1U,2U)は今後もしばらく大きな売上が予想されています。2005年ほどのLinuxサーバの劇的な成長までは及びませんが、それでも2006年からは13%ぐらいの成長率で推移するとIDCは予想しています。確かに、今年のLinux Worldからして時代はLinuxOSから上位ミドルのサービスへと注目先が変わりつつあるようでした。

ミラクルも今年は転換期です。今後ミラクルOS(Asianux)の開発の中心はAsianux.com(その中の中心は当然ミラクル技術者だが)になり、Domesticミラクルはより個性的(技術的に真似できない)なサービス/サポートに注力していきます。今年はOSのシェア以上にミラクルが注目されますのでこうご期待です！

ノートPCにLinux(1)

みなさん、こんにちは、moriyama です。

今回は、Linux のデスクトップ(GUI)環境を、本格的に使うために、会社で使っているノートPCに、MIRACLE LINUX V4.0 (以降 ML40  と省略します) をインストールしてみましたので、その事について書いてみます。

今回、既にインストールされている WindowsXP は、そのまま残して ML40 とのデュアルブートを実現し、なおかつハードディスク上に領域確保されているリカバリー領域からの Windows の再インストールを可能なようにしてみました。

ポイントとなる点は次の2つです。

1. Windows のパーティションサイズを縮小し Linux 用の空き領域を確保する。
2. ハードディスクのMBR(Master Boot Record)にインストールされているブートローダを上書きしない。

まず1点目につてですが、パーティションコマンダーという商用のツールを使って Windows のパーティションを小さくしました。そして、同ツールを用いて空き領域に Linux 用の3つのパーティション /boot (ext3)、/ (ext3)、swap と Windows とのファイル受渡し用の FAT パーティションを作成しました。

FAT パーティションを用意したのは、/boot パーティションにLinux のブートローダ GRUB をインストールした後、/boot パーティションのブートセクターの内容をファイル化して Windows パーティションに持っていくための領域として使うためです。フロッピーディスクがある場合は、フロッピーディスクを使うことも可能です。

次に2点目ですが、MBRを上書きしないで、Linux をインストールした場合、どうやって Linux をブートさせるかが問題になります。この点については、WindowsXP の起動用の NTLDR というブートローダで、WindowsXP と ML40 を選択して起動できるように設定する事がわかっていたので、google で検索して次の Web ページを参考に設定を行ないました。

Win NT/2000 のOS-Loaderでのデュアルブート

これだけの情報では、具体的にどうすれば良いのかわからない人も多いかと思いますので、次回、私の番が回ってきたときに、具体的にどうやって、デュアルブートの設定までたどり着いたのか披露したいと思います。

ご当地名産

ミラクルのサービス業務の一つにコンサルティングサービスがあります。幸いにミラクルのコンサルティングも盛況でご利用して頂けるユーザ様が多数いらっしゃいます。私は元々出無精なせいか国内をあまり旅行したことがありませんでした。しかし、コンサルを実施していくことでこれまでいろいろなところへ出張する機会に恵まれました

（名古屋、広島、鹿児島、大阪、和歌山、北九州、帯広・・・）

実際には空港や駅から現地との往復であり、その方面方面の有名どこには行ってはいません。楽しみといえば食事となります。昼食や夕食など極力その方面の美味しい物を食べてやろうと思っています。今までも広島のお好み焼きや大阪、和歌山でのたこ焼きなどなど、食べてきました。

その中でもおいしかったと思うのがまずこれ！！

鹿児島の黒豚しゃぶしゃぶです。出無精の人間ががんばってひとりで豪勢なしゃぶしゃぶ屋に入るなんて想像できますか？（ましてや男1人で）そこを一念発起して店に入りました。これはほんとおいしかった～。（しゃぶしゃぶは皆でわいわいしながら食べる方がおいしいということも実感できたし）鹿児島ではきびなごのお刺身など東京では食べれないもの（私が知らないだけで東京でも食べれるかも！？唐揚は食べたことはありますが）を食べれたりといい思い出がたくさんあります。実は今日も鹿児島に行ってました。現在は岡山へ移動済みですが。

次はこれです。

帯広で食した豚丼です。元々帯広の有名を知らずにいたので、これを教えてもらい食しました。帯広では豚丼ように豚を改良しているとのことです。

今後もコンサルを実施し各方面へ行く時は進んで名産を食すつもりです。なんたって一人でしゃぶしゃぶ屋に入れるんですから怖いものなしです。昨日も居酒屋で一人で焼酎呑んでましたし

弊社コンサルティングサービスをご依頼頂ける方は、是非その場所の名産も一緒にご連絡下さい。それによってサービスが変わるかもしれません（うそです、すいません）

また、このようにコンサルティングサービスを一緒に実施し、全国を回りたいという方、是非一度弊社の募集に応募してみては？

温室栽培のモヤシじゃないですぞ！

どうもdtonokiです。
またまた、穴埋めで私の番が回ってきました。技術的な話を期待されている方すいません。
私は日ごろMIRACLE LINUXのサポートを主業務としております。
今日は、そのサポートの一環としてというか、コンサルに近いのですが、朝からお客様を訪問しシステムアップグレードの話をしてきました。
越後湯沢で新幹線を降りたところ↓のような在来線運転見合わせな状況です。

東京都内なら別の路線を使えますが、越後湯沢では在来線が止まっては目的地に到達できません。
駅のアナウンスでは在来線の復旧の目処が立ってないので、新幹線で引き返せと言っていました。
まあ、私はパートナー様が借りたレンタカーで無事お客様を訪問することが出来ました。
閑話休題

私の前職はハードウェアベンダーのサポート業務の後、顧客先の常駐SEとしてNotesや全国拠点のサーバー管理をしておりましたので、カーネルハッカーというよりは、ハードベンダー、O.S.ベンダー、顧客、それぞれの立場に立って親身にサポートが出来るのが売りだと思っております。
また、本日のようにコンサルタントとしてシステム構築を行うなど、常に実戦で培った経験と「勘」を駆使してサポートしております。
クローズ率にしか関心のない人や、コールセンターにしか勤務したことの無いサポート要員は弊社にはおりません。

Linuxで困ったときはミラクルに声をかけていただければと思います。期待は裏切りません。

追伸、コアな物欲はMacBook購入というところで落ち着いてしまいました。＜カミさんには内緒です。

エンジニアの働き甲斐を支えるもの

弊社は、外から見ると外資系と勘違いされている人もいるが、実はわりと普通の(?)日本の会社だ。ただし、ベンチャー企業には間違いない。私がこの会社に移ったときに「ミラクル(の仕事の仕方や雰囲気)は日(本)系ですか外資系ですか」と質問したのに対し、面談した武田氏の「私はベンチャー企業だと思ってこの会社に来た」という回答は今でも覚えている。
実際、ほとんどの社員は転職組であり、前職に様々なマイナス要因があったにせよ、あえてこの会社を選んだ理由に、ベンチャー特有の働き甲斐を含めていないわけがないだろう。

とはいえ、ベンチャーであれば常に働き甲斐があるわけではない。
私の失敗経験によると、働き甲斐があっても下記の場合にはうまくいかないようである。はじめに断っておくが、弊社においては下記のような事態には遭遇していないので、安心(?)して欲しい。

・人に魅かれるエンジニアがカリスマの無い人に出会ってしまった場合

カリスマ創業社長の弁舌に惚れてしまい入社したのだが、直属の上司にカリスマが無かったとしたら...。師弟関係で育ててもらった人が、どうしても師と仰げない人に出会ってしまうと大変不幸である。Linuxには特にこういう人が多いと思うので注意が必要ではなかろうか。話術に優れないエンジニアが下の立場から上を云々することは本質的に難しい。

・技術を選り好みするエンジニアが選り好みしない会社に入ってしまった場合

技術を選り好みしてはいけないなどと就職／転職情報に書かれていると不安になるものだ。確かに何でもできる人は重宝される傾向にあるし、ある程度広い範囲のことができることを証明するために資格を取ったりすることもある。しかし例えば、Linuxが好きでたまらない(というかWindowsが嫌いでたまらない)人がWindowsの開発部門しかない会社に入ってしまうと大変な不幸を見る。どこにも明確に書いていないために陥穽にはまりやすいのではなかろうか。
※そういうわけで弊社には角張った人も多い。活気のある会社には凸凹した人材・人脈も必要だと感じる次第である。凸凹していると総合力を保ちつつも相互に畏敬を持って接することができるという効果もある。

・会社が潰れたか潰れそうな場合

どんなに幸せを感じる内容で働いていても、潰れてしまっては仕方が無い。給料が滞ってはや一月、ある日出勤すると自分のデスクトップPCが借金の形になくなっていた...なんてことを経験したら、ものを売る技術の無いエンジニアでは、わが身の不幸を呪っている心理的余裕すらなくなる。幸せすぎる毎日は奈落への道であることも考えられる。

・なりかと理由をつけて売る気がない営業に出会ってしまった場合

いくら良い(と思われる)製品をエンジニアが開発しても、いくらも中身を見ないで投げてしまう営業しかいない会社にいては報われない。話術巧みに場を切り抜けることが得意な営業に捲かれてしまいがちなエンジニアだが、何年たっても効果が無ければ化けの皮は剥がれてくる。そのような時は自らの境遇をただ不幸と思わず、豁然として理想との乖離を認識する必要がある。
※この点、弊社の営業はエンジニアから見て頼みに足りると感じている。いくら話術に長けていても、エンジニアを騙して働かせようとするようでは、外に対してもそのようにしているのではないかと考えてしまうが、率直で熱意を持っている人が多い。

ある人材開発会社の人が「職は内容で選ぶな人で選べ」と言っていた。私は内容を選ぶなといわれても困ってしまうが、エンジニアが自ら人を選ぶことも必要なのではないかと思っている。よき隣人こそがエンジニアの働き甲斐を支えるのではないだろうか。意見・異見があればコメントいただければ幸いです。

ですくとっぷLinux

私が最初に触れたPCは大学に入ってからのことでOSはLinuxでした。その後所属した研究室でもLinuxマシンが与えられ先輩に教わりながらデスクトップ環境を強化し論文作成まで行いました。
それ以来ず〜っとデスクトップLinuxで生活していますので生粋のLinuxerと言ってもよいか知れません。(kernelの方は詳しくないですけど)

弊社はLinuxの会社だけあってOA環境もLinuxを使用することが可能なので私としては快適です。ただ社外とのやり取りでは、.zipや.lzh、.exeという拡張しが付いたファイルで圧縮され送られてくる場合があります。
そこで、ここではその対処法をご案内します。
.zip: unzipコマンドで展開します。
  $ unzip file.zip
.lzh: lhaコマンドで展開します。
  $ lha x file.lzh
.exe: wineコマンドで展開します。
  $ wine file.exe
なお最近のGNU/Linuxではそれらのコマンドがインストールされていればファイルブラウザからワンクリックで展開可能ですので覚える必要もないでしょう。勿論パスワードでロックされているファイルにも対応しています。

Linuxは習うより慣れろだと思います。皆さんもデスクトップ環境をLinuxにしては如何がでしょうか。ちなみに私は自宅ではマルチメディアOSとして活用しています。

と、これだけではちょっと短いので最後にクイズを。ここのblogではviネタが多いので私も便乗しちゃいます。
題して、何手で出来るでしょう？
以下は/etc/ssh/sshd_configの抜粋です。Miracle Linuxではデフォルトでrootユーザのsshログインは許可されていません。rootユーザも許すには右側のように「yes」の行のコメントアウトをはずし「no」の行をコメントアウトします。その後sshdの再起動も忘れずに。
------------------------------------------------------------
#PermitRootLogin yes        →        PermitRootLogin yes
PermitRootLogin no                    #PermitRootLogin no

------------------------------------------------------------

そこでviエディタで上記のように編集するには何手で出来るでしょう？
ヒント: /etc/ssh/sshd_config内の対象行(yesの行)に移動するには「/Ro」で可能です。カーソルは「Root」の「R」上に移ります。

答え:  ↓の括弧内をマウスでハイライトしてください。
  (/Ro[Enter]0xjPZZ)

もっと簡単な方法があったら教えてくださいな。

コアテクな方の物欲は？

私の回は技術的な話ではないですが、どうぞご容赦を。
こういう仕事をしていると回りのコアな方々は、やれ「W-ZERO3」だ、やれ「MacBook(IntelコアがG4コアの5倍とか書いてありますが、旧機種ユーザの心情は大丈夫なんでしょうか)」だと新しいガジェットを見る機会が多いです。
まあ、人のガジェットを見ても自分の物欲なんてものは、そうやすやすとは湧き上がってこないのですが、最近はスケジュールの管理を携帯でしたくなってきてスマートフォンにするか！？いくか！？買っちまうか！？な状態です。
でも、私のキャリアではスマートフォンにろくなものがありません。と、他のキャリアを見ると、705NKII が1円！804NK が今月末発売！W-ZERO3[es] がっ！！うーん、キャリア乗り換えようかなー、でも何ツーかやっぱ番号変わっちゃうのはメンドクサイですねー。と、買わない理由を考えてみたりしてます。
番号ポータビリティも10月には始まりますので（なんだか手数料が怖いですが)キャリアの変更が進むのではないでしょうか。あ、コアなひとは機能別に携帯電話を3個くらいもつのは普通でしたね。。。ホホホホー

Linuxエンジニア≒はてなユーザ？

ブログのアクセス解析をしていたときに気づいたことですが、はてなRSSやはてなダイアリー、はてなブックマークからのアクセスが結構あることがわかりました。もちろん他のRSSリーダを経由しての訪問もありますが、一番人気があるのは、やはり「はてな」のサービスからです。そこで気になったのですが、Linuxを使っている方々はどれくらい「はてな」を使っているのでしょうか？私の予想では、結構いるのではないかと思います。

弊社の吉岡も個人ブログをはてなに持っているようですし、社内でもはてなを使っている人を見かけます。かくいう私も、始めてアクセスしたときはとっつきにくい印象を受けましたが、使い続けていくうちにその機能性の高さがわかり、今でははてなRSSを毎日使っています。

もし私の仮説のとおり「はてな」にたくさんのLinuxエンジニアがいるのなら、特にうちのようなLinux企業の場合、はてなのサービスを使うことが有効なマーケティング手段になりうるわけですよね。例えば、はてな人力検索で「どのような情報をLinuxエンジニアが求めているか」、という質問をしてこのブログへのインプットを増やすことが考えられます。もちろん、フィードバックに対してしっかりフォローしていくことが読者定着に繋がるとは思いますが、ネタふりとしてはおもしろいかなと。

もちろんこのブログでもおもしそうなネタは常時受け付けていますので、気軽にコメントしていただけたら思います。

vim: 見えない文字を見えるようにする

こんにちは、ここの blog は初登場で両刀使いの さとうふみやす です。 両刀と言ってもエディタの話で、vi, Emacs の事です。 皆さんはどちらがお好みですか? 私はテキストの編集は vi (vim)、 メーラーと辞書索き (全然エディタ用途じゃないですが) は Emacs (XEmacs + Wanderlust + lookup) と使いわけています。

今回のお題は vim で見えない文字を見えるようにする としました。 ここでの 見えない文字 とは、スペースやタブ文字のことです。 スペース文字といえば ASCII のスペース (U+0020) やいわゆる「全角」のスペース (U+3000) がありますが、 これらを見た目で区別できたら便利じゃありませんか? また、テキスト行の末尾に無駄なスペース文字がないか気になりませんか? この Tips は、そんな人に役立ちます。

前置きが長くなりましたが本題に入りましょう。 以下 vim 向けのお話ですが、MIRACLE LINUX V4.0 付属の vim (vim-*-6.3.046-0.40E.4.2AX) と、 Debian GNU/Linux unstable (sid) 付属の vim (vim 7.0-017+8) でのみ確認してあります。 ディストリビューションに依らず、vim 6 以降であれば問題ないと思います。

今回の Tips は、vim のシンタックスハイライティング機能 (syntax highlighting) を利用します。 シンタックスハイライティングを有効にすると、vim は表示・編集しているテキストの構造を解析し、 構文やブロックごとに色やフォントを変えて表示してくれる便利な機能です。 これを利用して全角スペースや行末尾のスペースを可視化します。

まずは、vim を起動して次のコマンドを実行してみてください。 これがエラーになるようであれば、残念ながらあなたがお使いの vim はシンタックスハイライティングに対応していません。 (見た目が) 特に変化ないようであれば問題ありません:

:syntax on

次にハイライトさせたいパターンを構文 (syntax) として定義します。 全角スペースに一致させる場合、次のようなコマンドになります。 display キーワードは画面に表示される場合だけ処理させるための指示です。 containedin=ALL キーワードはどんなコンテキストでも一致させるための指示です:

:syntax match InvisibleJISX0208Space "　" display containedin=ALL

次に、定義した構文に一致するテキストをどのように表示するか (ハイライト) を定義します。 全角スペースに対し白黒端末ではアンダーラインを、色対応端末と GUI (gvim) では青で表示させるには、 次のように定義します:

:highlight InvisibleJISX0208Space term=underline ctermbg=Blue guibg=Blue

さあ、準備ができました! ASCII スペースと全角スペースを適当に入力してみてください。 うまい具合に ASCII スペースと全角スペースが見た目で区別できるようになったでしょうか?

同様に、行末のスペース文字を可視化するコマンドを紹介しましょう。 ついでにタブも可視化してみます (タブの可視化は画面がごちゃごちゃになるのでお薦めしません) :

:syntax match InvisibleTrailedSpace "[ \t]\+$" display containedin=ALL
:highlight InvisibleTrailedSpace term=underline ctermbg=Red guibg=Red
:syntax match InvisibleTab "\t" display containedin=ALL
:highlight InvisibleTab term=underline ctermbg=Cyan guibg=Cyan

以上、いまくいったでしょうか。 うまくいったなら、vim の設定ファイルに追加しておきましょう。 ~/.vimrc ファイルに次のような設定を記述します:

syntax on
syntax match InvisibleJISX0208Space "　" display containedin=ALL
highlight InvisibleJISX0208Space term=underline ctermbg=Blue guibg=Blue
syntax match InvisibleTrailedSpace "[ \t]\+$" display containedin=ALL
highlight InvisibleTrailedSpace term=underline ctermbg=Red guibg=Red
syntax match InvisibleTab "\t" display containedin=ALL
highlight InvisibleTab term=underline ctermbg=Cyan guibg=Cyan

以上です…と言いたいところですが、問題が一つ。 vim はファイル種別ごとにシンタックスハイライティングの定義を切り替える機能があるのですが、 .vimrc によるシンタックスハイライティング定義よりもそちらが優先されてしまうため、 上記の設定が有効にならないことがあります。 この問題の回避に加え、 シンタックスハイライティング機能の有無のチェックと .vimrc ファイルの再読み込みに対応させると、次のような設定になります:

if has("syntax")
    syntax on
    function! ActivateInvisibleIndicator()
        syntax match InvisibleJISX0208Space "　" display containedin=ALL
        highlight InvisibleJISX0208Space term=underline ctermbg=Blue guibg=Blue
        syntax match InvisibleTrailedSpace "[ \t]\+$" display containedin=ALL
        highlight InvisibleTrailedSpace term=underline ctermbg=Red guibg=Red
        syntax match InvisibleTab "\t" display containedin=ALL
        highlight InvisibleTab term=underline ctermbg=Cyan guibg=Cyan
    endf

    augroup invisible
        autocmd! invisible
        autocmd BufNew,BufRead * call ActivateInvisibleIndicator()
    augroup END
endif

申し訳ありませんがここで時間切れのため、最終版の詳細な解説は割愛させていただきます。 :help キーワード で vim のヘルプが参照できるので、 そちらを参考にしてください。

ミラクルフットサル

ミラクルでは様々な社内イベントがあるのですが、
その中にフットサル同好会？のようなものもあったりします。
素人から元サッカー部まで、レベルはいろいろ。

7/19に同じビルお某社とフットサルの試合をすることになっています。
というわけで、その準備ということで、先週(7/5)社内練習を
某体育館でやってきました。
普段、長時間の練習なんかやったことがないので、みんなバテバテ。
足もパンパン。う～ん、こんなことで19日は勝つことができるのでしょうか。
社長からは、「勝ってきてね！！」 という、さりげないプレッシャーが。。。

練習後の飲み会は、もちろん実施。
フットサルよりも、こっちの方が重要？
みんな、ボールのパスよりも、トークのパスの方がうまいんじゃない。
それにしても、汗を大量にかいた後のビールは、やっぱうまいなぁ～。。。

tito

スピンロックその３

前回に続き、スピンロック取得処理の定義を追います。今回は(b)のケースです。

(a) CONFIG_SMP と CONFIG_DEBUG_SPINLOCK がともに未定義の場合、すなわちデバッグ無しのユニプロセッサ・カーネルの場合。

(b) CONFIG_PREEMP と CONFIG_SMP がともに定義されている場合、すなわちプリエンプションなマルチプロセッサ・カーネルの場合。

(c) それ以外の場合。

(b) が定義されているのは kernel/spinlock.c の中央付近です。ここでは _spin_lock() だけでなく、

/*
*         _[spin|read|write]_lock()
*         _[spin|read|write]_lock_irq()
*         _[spin|read|write]_lock_irqsave()
*         _[spin|read|write]_lock_bh()
*/

の計12個の関数がマクロを駆使して一括定義されています。
BUILD_LOCK_OPS(spin, spinlock) によって定義される _spin_lock() はマクロを置換すると以下の関数になります。

void __lockfunc _spin_lock(spinlock_t *lock)
{
        preempt_disable();
        for (;;) {
                if (likely(_raw_spin_trylock(lock)))
                        break;
                preempt_enable();
                if (!(lock)->break_lock)
                        (lock)->break_lock = 1;
                while (!spin_can_lock(lock) && (lock)->break_lock)
                        cpu_relax();
                preempt_disable();
        }
        (lock)->break_lock = 0;
}

EXPORT_SYMBOL(_spin_lock);

始めに preempt_disable() でプリエンプションを禁止しているのは (a) のケースと同様ですね。実際にロックの取得を試みる処理は、その次の for ループです。_raw_spin_trylock() でロック取得に成功したら真を返してループから抜け出します。ロックできなかったらプリエンプションを許可し、次のチャンスを待ちます。すぐに _raw_spin_trylock() を再実行したりせず、while ループで cpu_relax() を実行するというわけです。cpu_relax() はアーキテクチャによって実装は違いますが、ビジーウェイトでの CPU 負荷を下げるための関数です。i386 だと HT テクノロジの環境で効果がありそうなところですね。
cpu_relax() をやめて _raw_spin_trylock() を再実行するための条件は、以下のいずれかが満たされた時です。

(i) spin_can_lock(lock) が真である。
(ii) (lock)->break_lock が 0 になった。

まず (i) の定義を確認してみましょう。
include/linux/spinlock.h

#define spin_can_lock(lock)     (!spin_is_locked(lock))
#define spin_is_locked(lock)    __raw_spin_is_locked(&(lock)->raw_lock)

include/asm-i386/spinlock.h

#define __raw_spin_is_locked(x) \
                (*(volatile signed char *)(&(x)->slock) <= 0)

これらをまとめると、 (i) が満たされるのは

*(volatile signed char *)(&(&(lock)->raw_lock)->slock) > 0

すなわち、その１で確認した slock 変数の値が 1 以上の時になります。UNLOCKED 状態が 1 ですから、ここで 0 (以下) ならばロックされている状態であろうことが推測できますね。なお slock のアドレスを (volatile signed char *) でキャストしていますが、slock の型はそもそも volatile unsigned int です。この不一致はどのような意味があるのでしょうか。signed は 0 を下回る時 (これは実際に起こるのでしょうか？) に備えたのでしょうけれど、char とした理由はわかりません。

次は (ii) が満たされる場合ですが、ここは自分自身では直前に break_lock を 1 に設定しているため、自力では満たされません。ということは、同じロックを狙って競合していた他のカーネルスレッドが先にロックを獲得して _spin_lock() を終了した時になります。

まとめると (i),(ii) は次のように言い替えることができます。

(i) ロックが解放されたタイミング。ロックが解放されていないのにロック取得を試みる無駄を防ぐためのもの。
(ii) ロックが解放されたが、他のカーネルスレッドが先にロックを獲得してしまった。

条件 (ii) で使用されている break_lock 変数は、SMP カーネルでロックを取得したスレッドのスケジューリングを改良するために http://linux.bkbits.net:8080/linux-2.6/cset@1.1966.39.47 で導入されたものです。ちょっと難しいかもしれませんが、頑張って読んでみて下さい。

次回は _raw_spin_trylock() を確認します。

さくら？自社ブログにもコメントを

おもしろいブログ、人の集まるブログ。ブログの存在がメジャーになり、個人に限らずいろいろな企業でもブログが始まっていますが、当初の目論見どおりに読者を増やせていないケースも多いかと思われます。実際にこの「コアテクの路地」ブログも、公開時からアクセス数が伸び悩んでいます。ではどうやったらブログがおもしろくなるのでしょうか。私はコメントなど、フィードバックの部分がキーになるのでは、と思います。

トラックバック先の吉岡のブログでもいくつかの方法が書かれていますが、最初から完全な文書を書く必要はありません。むしろ、コメントのようなフィードバックをベースに話を展開していく読者参加型ブログに育てることが、リピータを増やすために必要なのではないでしょうか。逆にフィードバックがないブログは、

• 記事を書く
• フィードバックがない
• フィードバックがないため、独りよがりの記事を書く
• さらにフィードバックがない

という悪循環に陥ります。これではブログの発展は望めません。

私がブログの人気度を判断するには、そのブログに対するコメント数やトラックバック数をみています。個人的に、コメント数が少ないブログにコメントを書くのは、ついつい躊躇してしまいます。例えると、お客の全くいないレストランに入るのは勇気がいりますよね。逆に、人気のあるラーメン店は行列ができますし、「行列ができる人気店」という事実がさらなる行列を呼ぶという要素もあります。よって、人を集めるブログになるには、いかにして定期的なフィードバックをもらえるコアなファンを作るかが大切になってきます。

それでは、どうすればフィードバックを得られるのでしょうか。そもそも人気のないブログは母体となる読者の絶対数が少ないため、わざわざ一歩踏み込んでコメントを書く人はほとんどいないでしょう。これでは読者も増えない、つまらないままの堂々巡りです。

ここで発想の転換です。

ないのならば、「さくら」を使って人為的にでも作ってしまいましょう。

具体的に言えば、会社の人間が自社ブログにコメントを書くことで、ブログ執筆とそれに対するフィードバックのサイクルを作ってしまいます。社内ブログを外部に公開してしまうイメージです。ある程度社内の人間で場を賑やかしておくことで、第三者にとってもより発言しやすい雰囲気を作ることができるのではないでしょうか。ブログ執筆者にとっても最低限社内からは確実にフィードバックが期待できるわけで、記事を書くことに対する精神的なインセンティブを与えることもできますよね。

また、管理職がしっかりと部下のブログにコメントを残すことで、部下に対して関心を持っていることをアピールできます。従来日本人は欧米人に比べ「会社の従業員に対する関心」を重要視しなかったのですが（最近そのようなデータが雑誌に出てました）、終身雇用制度が崩壊し従業員の会社への依存度が低下してきています。会社が「いかにして従業員と向き合っているか」を形で示し、その結果従業員の士気が上がるという、副次的な効果が望めるかもしれません。

以上、ブログによる情報発信を促進するために会社ができるひとつの方法として、思いついたことを文章にしてみました。

スピンロックその２

もうすっかり忘れられているかもしれませんが、スピンロックその１の続編です。

今回はロックの取得処理を追っていきましょう。前回に続き、プロセス・スケジューラ kernel/sched.c を徘徊してみます。。。

/*
* task_rq_lock - lock the runqueue a given task resides on and disable
* interrupts.  Note the ordering: we can safely lookup the task_rq without
* explicitly disabling preemption.
*/
static inline runqueue_t *task_rq_lock(task_t *p, unsigned long *flags)
        __acquires(rq->lock)
{
        struct runqueue *rq;

repeat_lock_task:
        local_irq_save(*flags);
        rq = task_rq(p);
        spin_lock(&rq->lock);

指定されたタスクが所属しているランキューをロックする関数 task_rq_lock() がありました。この関数は、例えばタスクを別なランキューに移動させる前などに実行してランキューをロックします。ロックの中心処理は、そのものずばり spin_lock() です。この実装を追ってみましょう。

spin_lock() の定義を遡っていくと、カーネルのオプションに応じて、大きく分けて以下の 3通りの定義がありました。

(a) CONFIG_SMP と CONFIG_DEBUG_SPINLOCK がともに未定義の場合、すなわちデバッグ無しのユニプロセッサ・カーネルの場合。

(b) CONFIG_PREEMP と CONFIG_SMP がともに定義されている場合、すなわちプリエンプションなマルチプロセッサ・カーネルの場合。

(c) それ以外の場合。

プロセッサが単一なのかそれとも複数なのかでも実装が異なるということですね。
まずは一番シンプルな (a) の場合を見ていきましょう。

include/linux/spinlock.h

#define spin_lock(lock)                 _spin_lock(lock)

include/linux/spinlock_api_up.h

#define _spin_lock(lock)                        __LOCK(lock)
#define __LOCK(lock) \
  do { preempt_disable(); __acquire(lock); (void)(lock); } while (0)

さらに __LOCK(lock) の定義の直前にはこんなコメントが。

/*
* In the UP-nondebug case there's no real locking going on, so the
* only thing we have to do is to keep the preempt counts and irq
* flags straight, to supress compiler warnings of unused lock
* variables, and to add the proper checker annotations:
*/

ということで実際のロック処理は行っていないとのこと。定義も preempt_disable() でプリエンプション禁止しているだけですね。__acquire() は普通のカーネル (__CHECKER__ マクロは未定義ですよね？) なら空定義です。ユニプロセッサで割り込まれることが無い状態ならば、ロックが不要という扱いのようです。逆に、spin_lock() でロックを獲得したまま schedule() で処理を明け渡すようなコードがあったら排他処理にはならないということでしょうか。

次回は(b)を追ってみることにします。