| Bottom | Home | Article | Bookshelf | Keyword | Author | Oxymoron |

How to track OSS

- A Guide to OSS & Linux -

Cat: ICT
PUb: 2006
#:0612a

OSDL-Japan, SI-Forum

up: 06405

Title

How to track OSS

OSSの歩き方

Subtitle
A Guide to OSS & Linux OSSおよびLinux導入ガイド
Compiler
SI Forum of OSDL-Japan

OSDL-Japan SIフォーラム

Published

Apri. 5, 2006

2006年4月5日
Index
Index
  • This thesis is compiled by SI-Forum of OSDL (Open Source Development Labs). Takashi Kunai, former Fujitsu engineer, one of the leaders of OSDL-Japan mostly proposed this idea.
  • SI-Forum (led by Atsuo Suzuki, NEC Soft) of OSDL-Japan adopted this article as an output of the activity. I was a member of this SI-Forum, and particularly contributed to tranlate into English.
  • In Japanese IT market, the initiative of SIers is particularly important in proposing OSS systems. We do hope that the message this article would be helpful in promoting IT solutions using OSS/Linux.
  • 本書はOSDLのSI-Forumがまとめた。OSDL-Japanのリーダであり、元富士通のエンジニア工内隆がほとんどのアイデアを提供した。
  • OSDL-JapanのサブグループであるSI-Forum (NECソフトの鈴木敦夫)は、この文章を活動の成果の一つに採用した。小生はこのSI-Forumのメンバーであり、特に英訳を担当した。
  • 日本のIT市場では、OSSの提案におけるSIのイニシアティブは特に重要である。本趣旨がOSS/Linuxの活用によるITソリューション推進の一助になることを念願している。
English
Japanese
>Top

0. Prologue:

  • Everyone feels to get lonely out new culture, or new platform. Linux/OSS is not an exception in this feeling. However, there will be the ropes of handling, or some know-how to make full use of fast-growing and ever-changing information.
  • We believe that such tips or know-how will be useful in understanding and safer or more effective use of OSS/Linux. Here is an easy-to-follow explanation about the common sense advice as a Linux/OSS engineer, in the form of a dialogue between Lucky who is an assumed expert of OSS/Linux and Will who is an assumed three-year experience of Windows engineer.

0.プロローグ:

  • どんなことでも、誰しも新しい文化にはなじめないものです。Linux/OSSにおいても、例外ではなく、日々進歩、変化し、多様化された情報を使いこなし、活用していくには、いくつかの前提やちょっとしたコツがあります。
  • 事前にコツを知ることで、理解が早まり、安全で効率的に活用できると考え、いわばコツであるLinux/OSS技術者にとっての常識について、Windows経験3年目の技術者を想定読者と仮定し、対話形式でわかりやすい解説をしています。
>Top

CHAPTER-1: OSS IS REALLY USABLE! (Ver.4)

1. Information of OSS:

  • Will:
    Mr. Lucky, I have three-year experience in making Windows systems. I have believed that MS (Microsoft) could well take good care of giving us flood of data by MSDN (Microsoft Developers Network), etc. But what about the case of Linux or OSS ? How can we get access to such information?

  • Lucky:
    If you intend to become a professional engineer as a system integrator, you can't live long only depending on the information supplied by commercial vendors. In OSS world, all kinds of information are open to public and shared in the world. Only if you know how to take a proper step of OSS, you can skill up yourself much better than living within Windows world. You need to work your way to find useful information by yourself.

 第一章: 納得、OSSは使えるぞ!(第4版)

1.OSSの情報:

  • W君:
    先輩、僕は入社して3年間、Windowsでシステム構築の経験を積みました。Windowsはマイクロソフトさんの面倒見が良くて、MSDN (Microsoft Developers Network)なんかでは、読みきれないくらい情報が来ました。LinuxとかOSSでは情報はどのように集めればいいんですか?
  • L氏:
    SIの世界でプロを目指すのなら、商用ベンダの情報だけに依存していてはいけないよ。全ての情報が公開されていて、世界中で情報が共有できるOSSは、歩き方さえ分かれば、Windowsの世界以上に、広く、深く情報を集めることができて、スキルの向上ができるんだ。自分で情報を探す努力が必要だよ。
>Top

2. Merit of OSS:

  • Will:
    But I think customers do not necessarily dare to select Linux or OSS. How can I explain to our customers when I recommend them to make their systems by OSS?
  • Lucky:
    Do you want to know the merit of OSS? OK, there are too much! You had better to point out only several merits depending on the circumstances of the customers. OSS has such merits that:
    1. users are not locked in the particular products or vendors, which enables to maintain competition among products and services. You can expect big difference in cost-effectiveness in the long run;
      ("locked-in" means: if a certain system is adopted, then the following system necessarily result in the same one.)
    2. all technologies including source code are shared worldwide, which is going to be a common sense, i.e., common basic technology among engineers including new graduates. This also means it is easier to secure engineers withou bearing a heavy burden for additional education.
    3. It is also easier to secure mutual connectivity or portability between the systems installed Linux with same source code, or between OSS middlewares.
    4. recent engineers mostly tend to utilize Linux or OSS environment to develop both hardware and software, which means new technology will be developed based on Linux/OSS platform from now on, just like the former situation of UNIX;
    5. rapid growth of Linux and OSS in the world encourages corporate customers to consider their investment in using Linux/OSS as the first priority, particularly in the field of human resources, hardware, or software.
  • You can easily find out various information in the Web sites of such organizations as OSDL, Japan OSS Promotion Forum*1 , Linux distributors, or platform vendors, why they promote Linux/OSS platform in their own words and reasons. Also Japanese government proclaims their policy intending to promote Linux/OSS*2, aiming to eliminate locked-in situation in the particular products and to boost software industry regarding OSS as a spring board.

2.OSSのメリット:

  • W君:
    でも、お客様は必ずしもLinuxとかOSSの方がいいと思っている訳ではないでしょう。お客様にOSSを勧めたり、OSSでシステムを構築する時、どんな説明をするのがいいんですか?
  • L氏:
    OSSのメリットかい、沢山ありすぎて困るくらいだよ。お客様の様子を見て、2~3点を挙げるんだぞ。
    1. 特定製品、特定ベンダへのロックイン(囲い込み。あるシステムを採用した結果、後継システムも同様システムを採用せざるを得なくなること。)がない、そのために長期的に製品・サービスの競争状態が維持され、投資対効果の大きなシステムが期待できる。
    2. ソースコードまで含めて世界中で技術共有できることから、新卒技術者まで含めて、世界中の技術者の常識(共通基礎技術)になりつつある。今後、技術者確保が容易になり、教育に対する負担が軽減できる。
    3. 同一ソースコードを使ったLinuxシステムやOSSミドルウェア同士では、システム間の相互接続性やアプリの移植性が容易に確保できる。
    4. かつてUNIXがそうだったんだけれど、今日、ハード、ソフトで技術開発しようとすると、多くがLinuxやOSSの環境を利用する。つまり、これからの新技術は、Linux/OSS上で展開すると考えられる。
    5. 世界中でLinuxやOSSの採用が広がっているので、今後お客様企業がITに投資するなら、人材にせよ、ハードにせよ、ソフトにせよ、Linux/OSSを第一選択肢とする、などなど。
  • OSDLや日本OSS推進フォーラム*1 、Linuxディストリビュータ各社、あるいは、プラットフォームベンダのWebサイトには、それぞれの言葉でLinux/OSSを推進する理由を説明しているから参考になるよ。
    また、政府施策としてもOSS推進の方針が出てきているけれども*2 、その狙いは、政府調達における特定製品へのロックイン排除とOSSを起点としたソフト産業育成にあるんだ。
*1: http://www.ipa.go.jp/software/open/forum/
*2: http://www.kantei.go.jp/jp/singi/it2/kettei/050224/050224pac.html
>Top

3. Reduce of TCO (Total Cost of Ownership):

  • Will:
    Have you forgotten the merit of reducing TCO? You don't think customers seem to be particularly interested in the direct cost rather than long-term advantages, do you?
  • Lucky:
    Of course, in a simple system such as Web server or mail server with comparatively small applications, an IA (Intel Architecture) server with Linux is much cheaper than a RISC server with UNIX, and it is even cheaper than the Windows server properly considering CALs (Client Access Licensing). But according to the importance by increase of business application software, the criterion shifts from TCO to ROI (Return On Investment), i.e., what services or jobs the system can do for the client. You can also refer to "the TCO guide of open source software" compiled by Japan OSS Promotion Forum
    *3, which describes how to maintain higher operating ratio of the system, or to utilize business applications as long as possible.

3.TCO (Total Cost of Ownership) の軽減:

  • W君:
    あれっ、TCOの軽減がメリットに入っていませんが?お客様には、遠い先の話をするよりも、目の前のシステムのお金の話をする方がいいんじゃないですか?
  • L氏:
    そりゃ、業務アプリの比重が少ないWebサーバやメールサーバのようなシンプルなシステムなら、Linuxが載るIA(Intel Architecture)サーバは、UNIXが載るRISCサーバに比べて格段に安い。また、CALs(Client Access Licensing)をちゃんと計算するとWindowsに比べても断然安くなる。
    でも、業務アプリの比重が大きくなるにつれて、お客様の選択基準はTCOじゃなくなって、そのシステムで何ができて、どんな投資価値(ROI= Return on Investment)があるかという点の方が重要になって来るんだ。そのシステムの稼働率をいかに高く保つことができるか、とか、開発した業務アプリが長期的に利用できるかとか。日本OSS推進フォーラムが纏めた次の資料が参考になるよ:「オープンソースソフトウェアのTCOガイド」*3
*3: http://www.ipa.go.jp/software/open/forum/business/download/oss_tcoguide.pdf
>Top

4. Security of OSS:

  • Will:
    Is it true that Linux is stronger in security? I think it seems natural that crackers tend to attack Windows more, because they are used much more in the world. Does it sound reasonable that less attack to Linux does not necessarily mean that Linux is securer than Windows?
  • Lucky:
    By the way, guys who attack security of the system are usually called 'cracker', while people who contribute to OSS community are favorably called 'hacker.'
    Even when limiting the discussion to computer vulnerability (virus infection and illegal entry), Regarding to security level, it is not so easy to compare such judgement that which platform is securer or not in terms of infection by virus or easiness of illegal entry. In 1990s when Microsoft products prevailed in the Internet world, there
    occurred various problems in the quality of products as well as various network functions which were enable as default, but these problems have been improved now. Also, business model of Microsoft may cause crackers in the world to attack Windows systems.
  • On the other hand, Linux community shows great enthusiasm for debugging of Linux; if any security bugs in Linux were found, systematic measures would be taken at once by the activities of worldwide engineers trying to find the best way to solve. To be modest, we could say that Linux would be less frequently attacked by crackers at the moment. It is quite sure in Linux that no virus exists misusing Outlook mailing system. Obviously, crackers may attack any weak points existing in the computer system functions such as in mailing system or file exchange. Thus, less number of security holes do not necessarily means it is securer system. Security issues continue endlessly according to expansion of computer applications. We could not say that even Linux/OSS system would be absolutely safe.

4.OSSのセキュリティ:

  • W君:
    Linuxの方がセキュリティの面でより安全だっていうのは本当なんですか?Windowsの方が世界中でたくさん使われている分、クラッカーのセキュリティアタックが多いのは当然ですよねぇ、アタックが少ないからといって、Linuxのセキュリティが強いなんてならないでしょ?
  • L氏:
    そうそう、最近ではセキュリティアタックするような輩はクラッカーと言い、ハッカーはOSSコミュニティに貢献するような善意の人々を言うんだってねぇ。
    それでぇ、ウイルス感染とか不法侵入とかに限定して見ても、セキュリティの比較は単純じゃないだ。確かに、マイクロソフトさんの製品がインタネットの世界に急展開した1990年代には、製品の品質の問題、デフォルトでいろいろなネットワーク機能がイネーブルになっていた問題なんかもあったけれど、改善は進んでいるね。また、マイクロソフトさんのビジネスモデルの成功が世界中のクラッカーのやっかみを招いている面もあるかもしれない。
  • 一方で、Linuxコミュニティのバグ潰しに賭ける熱意はすごいものがあって、セキュリティバグが見つかった時に世界中の技術者が知恵を絞って即座に修正するシステムができているんだ。控えめに見ても、現時点でLinuxの方が、クラッカーのアタックは少ないのは事実だし、Linuxの世界にOutlookメールシステムを悪用したW君スが存在しないのは事実だろう。でも、クラッカー達は、メール機能、ファイル交換機能、などなど、あらゆるほころびをアタックするので、セキュリティホールが少なければ安全というものでもなく、コンピュータの適用分野の拡大とともに、セキュリティ問題は永遠に続くし、Linux/OSSでも安全なんてことはありえないんだ。
>Top

5. Is publication of source code weak point?:

  • Will:
    Conversely, is it plausible that openness of Linux code may help crackers can study security holes, which may cause more frequent security attack in Linux? Is there such risk as crackers might embed harmful code into Linux?
  • Linux:
    There may be such a discussion as worrying about openness of source code might cause security risk. But compared to dependence on the black box tests in the proprietary software through crackers, the method of open approach by publicizing source code and getting worldwide engineers' reviews and tests in proving security is much quicker and effective in solving security bug problems.
  • Furthermore, the source code of Linux or any other OSS, nobody can revise source code freely, but only authorized specialists named source code maintainers are to review code strictly, and there is no way questionable code is embedded in OSS.
    Regarding this issue, you can refer a good article in IBM System Journal: "Open-source versus proprietary software: Is one more reliable and secure than the other?"*4

5.ソースコードの公開はセキュリティの弱点?:

  • W君:
    逆に、Linuxはソースコードが公開されているんで、クラッカーから研究されて、セキュリティアタックの危険が大きいんじゃないですか?クラッカーが有害なコードをOSSに組み込む危険もあるでしょ?
  • L氏:
    Linux/OSSのソースコード公開をセキュリティの観点で心配する議論は確かにあるけれど、ソースコードを公開し、世界中の技術者のレビューとテストによって安全性を証明して行くやりかたは、Windowsのようにソースコード非公開で、クラッカーの、いわばブラックボックステストに任せるやりかたよりも、セキュリティバグの収束の速さの点で優れているんだ。
    また、Linuxを初めとしたOSSの開発コミュニティでは、誰でも勝手にソースコードを公式のOSSソースコードツリーに登録できる訳じゃなく、ソースコードメンテナーと呼ばれるソース管理者が厳格にコードレビューするので、怪しいコードがOSSに組み込まれるなんて事は有り得ないよ。IBM System Journalに良い記事があるので勉強するといいよ;"Open-source versus proprietary software: Is one more reliable and secure than the other ? "*4
*4: http://www.research.ibm.com/journal/sj/442/boulanger.pdf
>Top

6. Intellectual property of OSS:

  • Will:
    I think that OSS development community consists of various people who might infringe intellectual property such as copyright or patent right. What if corporate users or government were brought a lawsuit, their social credit might have fallen down?
  • Lucky:
    Such campaign seems to be propagated by the people who want to prevent diffusion of OSS, doesn't it? Regarding this issue, I would mention followings:
    1. It is true that if OSS contains any infringement of intellectual property right, it may cause troubles to users, but the situation is same with the case of proprietary software. License holders usually resort legal action to the upstream vendors rather than to each downstream end-user, because the legal action will not be effective if they want to sue one by one. In US, it is widely known that SCO filed a suit against users (Daimler-Chrysler and AutoZone), but the reason of the suit was not the use of Linux itself, but the management of UNIX source code, or the usage of converting tool of UNIX-Linux and so forth. Even if there were infringement of intellectual property in OSS, it could highly unlikely that the end-users would be filed a suit.
    2. Developers and source code maintainers of the development communities of famous OSS used worldwide keep a close watch on infringement of intellectual property right. Moreover various technical specialists contribute the communities and discuss the legal issues more frequently than ordinary corporations. You need not worry about legal issues about such well-known OSS not less than ordinary proprietary software.
    3. If infringement of intellectual property right occurred, the well-known OSS widely used in the world could immediately respond by revising the code in question getting full support of technical specialists. Nowadays, owing to various corporations are involved in OSS, and if such situation happened, they would take collaborative actions with development community, trying to revise code quickly in proactive manners.
    4. But even though, users of OSS need to understand that they cannot lay the responsibility of infringement of intellectual property right on OSS development community. It is the condition that users of certain OSS must approve such ways of development by the OSS community if and when they want to become users of said OSS. If the users could not approve it, they would have no means of using OSS. And if OSS or OSS community were exposed to the menace of such infringement of intellectual property right, users could be expected to support the stance of OSS community. Even if you suffered from any peculiar suit, which would be nothing of eclipse of your honor, but you could expect various supports from all over the world as long as you are a fair user of OSS. Linux Legal Defense Fund*5 of OSDL was established on the occasion that SCO had sued Linux users. Similar safety net will be prepared from now onward.
  • Regarding to the intellectual property right issues surrounding OSS, you can refer various information compiled by Japan OSS Promotion Forum: "Research report of legal risks related to business use of open source software." *6

6.OSSの知的財産権:

  • W君:
    OSS開発コミュニティと言うのは、いろいろな人の集まりで、他者の知的財産権(著作権とか特許権のような)を侵害していないとも限らないでしょ?企業や政府機関がOSSを使って、万一、誰かから訴訟でも起こされたら、社会的名誉の失墜は大変なんじゃないですか?
  • L氏:
    OSSの普及を邪魔しようとする人たちがそんなキャンペーンをしているようだね。
    1. もしも、OSSに他者の知的財産権侵害があると、利用者に迷惑がかかるのは事実だけど、よく考えるとその点は商用ソフトも同様だよ。OSSに限らず、ソフトに知的財産権侵害の問題があると、権利保有者は、最下流の利用者を一人一人、提訴すると効率が悪いので、普通、上流ベンダを対象にするんだ。米国で、SCO社が、利用者(Daimler-Chrysler社、AutoZone社)を提訴したことは有名だけど、その提訴の内容は、UNIXソースコードの管理方法だったり、UNIX-Linux移行ツールの使い方の問題だったりで、Linuxの利用自体を問題にした訳じゃないんだ。もしも、OSSに知的財産権侵害があったとしても、利用者が提訴される可能性はすごく低いよ。
    2. 世界中で良く使われている有名なOSSの開発コミュニティでは、その開発技術者やソースコードメンテナーは、知的財産権侵害の問題に対しても注意しているんだ。また、当該技術分野の専門家で構成されている開発コミュニティでは、特許の情報なんか普通の会社以上によく議論されているんだ。これらのOSSでは、通常の商用ソフトと同じ程度、知的財産権侵害の心配はないと言えるよ。
    • 万一、OSSに知的財産権侵害の問題があったとしても、世界中で良く使われている有名なOSSなら、十分な開発技術者の協力があるので、速やかに問題のコードを改修するよ。最近では、いろいろな企業がOSSに関与しているけれど、そのような事態になれば、これらの企業は、開発コミュニティと一致団結して、すすんでコード改修に取り組むと期待できるんだ。
    1. それでも、OSSの利用者には、知的財産権侵害の責任をOSS開発コミュニティに問うことは出来ないことを理解してもらう必要はあるよ。OSSの利用者になるということは、そのようなコミュニティの開発方法を是認していることが条件で、それができないなら、利用者は商用ソフトを使うしかないということだ。さらに、知的財産権侵害の問題でOSSやOSSコミュニティが脅威にさらされた時、利用者は、出来ることならOSSコミュニティ寄りの立場を取ってもらいたいものだよね。OSSを正しく使っていれば、おかしな提訴に遭ったとしても、名誉失墜なんかなくて、むしろ世界中からいろいろなサポートが来ることが期待できるんだ。OSDLのLinux Legal Defense Fund*5 は、SCOがLinux利用者を提訴したことを契機にできたものだけど、今後、同じようなセーフティネットが必要な局面で出来るんじゃないかな。
  • OSSにまつわる知的財産権の問題については、日本OSS推進フォーラムの、「ビジネスユースにおけるオープンソースソフトウェアの法的リスクに関する調査」 *6が纏まった資料になっているので参考になるよ。
*5: http://www.osdl.org/about_osdl/legal/lldf
*6: http://www.ipa.go.jp/software/open/forum/business/download/oss_risk.pdf
>Top

7. Intellectual proper and points of concern:

  • Will:
    I am making a remarkable tool using OSS related to my own project. But I am worrying about whether we should sell it to our customer. Someone advises me it may be too risky because of difficult rule called GPL.
  • Lucky:
    There is no problem as long as you use it in your office, but if you consider to give it or sell it commercially to the third party, you must consult your legal department about what to do, including warranty condition. Also you should familiarize yourself with the basic rules of GPL, etc. which would not be so difficult to understand as a aiming real professional engineer.
  • Regarding to the tool you mentioned, you should know the difference of license terms according to the particular OSS such as Tomcat, JBoss, PHP, or Eclipse. Generally speaking, commercial usages are allowed. But it is also responsible for you to check and comply with the license terms of particular OSS you used. You must be always sensitive about violation of rules which might cause social responsibility to the corporation you belong to.
  • In particular, GPL is referred to as a 'propagating' license (because the GPL of one product propagate a second and make it GPL.) as mentioned in the report of OSS Promotion Forum. This is important in the case of calling OS functions of Linux in C language program; the license terms of the called OS functions (=Library functions) are applicable to the whole tools.
  • FSF (Free Software Foundation) views that this propagating characteristic of GPL is applicable not only to static linkage, but also to dynamic linkage. This means we must be more explicit about all license terms of library functions to which the tool refers, by checking which is GPL (General Public License), or LGPL (Lesser GPL), or BSD (Berkley Software Distribution). You must be more careful about GPL library when you want to use them.
  • But most of the function libraries such as glibc are based on the licenses of LGPL or BSD, which does not require to publicize the source code. There are still other rules of LGPL or BSD, to which you must pay attention when you intend to transfer to the third party. I have checked so far the following category:
    1. LGPL: glibc, gnome-libs, and mostly others,
    2. BSD or similar to BSD: X11, tiff, etc.,
    3. GPL or similar to GPL: Qt.

7.OSSの知的財産権、留意点:

  • W君:
    今、僕のプロジェクトでOSSを使った優れものツールを作ってるんですけど、お客様に販売していいかどうかで悩んでます。GPLとかいう難しいルールがあって、危ないから止めとけという人もいるんですが。
  • L氏:
    自分で開発したものを社内で使っている分にはいいけど、第三者に引き渡す時には、ましてや、お金まで頂戴するのなら、瑕疵責任なんかもあるし、法務チェックは必須だよ。それと、君自身もOSSを使ってプロとして喰って行くんだから、GPLを初めとした基本ルールは、そんな難しいものじゃないし、十分に知っておく必要がある。
  • 君達のツールの場合なんだけど、先ず、Tomcatとか、JBossとか、PHPとか、Eclipseとか、利用するOSSによって使用許諾条件が違うんだ。一般論として、そのツールでお金を頂戴することも許されているはずだけど、利用するミドルウェアごとのルールをチェックし、それを遵守するのは君達の責任だし、ルール違反は、それこそ会社の社会的名誉の問題になり得るんだ。
  • 次に、GPLの件は、OSS推進フォーラムの報告書で、「伝播性」と言っているもので、C言語プログラムでLinuxのOS機能を呼び出すときに重要なんだ。つまり、呼び出されたOS機能(ライブラリ関数群)の使用許諾条件がツール全体に波及するんだ。
  • GPLの元締めであるFSF(Free Software Foundation)の見解では、静的リンクだけじゃなく、動的リンクでも「伝播性」は及ぶということだ。ということは、そのツールが使用するライブラリ関数群の使用許諾条件のチェックが肝心で、GPL(General Public License)とか、LGPL(Lesser GPL)とか、BSD (Berkley Software Distribution)とか明示されているのを確認しなければいけない。特に、GPLライブラリには気をつけなきゃいけなくて、これを使っていると、ツールのソースコードの開示が必要になるんだ。
  • でも、glibcを始めとした大多数の関数ライブラリは、LGPLやBSDになっていて、ソースコード開示は不要なんだ。それでも、LGPLやBSDが規定したルールがあるから、第三者に引き渡すときにはそれぞれのルールを認識することは必要だよ。僕が以前チェックしたところでは、次のようだったね。
    1. LGPL:glibc, gnome-libs等大多数
    2. BSD(ないしは、その類型):X11, tiff等
    3. GPL(ないしは、その類型):Qt
 

 

>Top

CHAPTER-2: SURE UTILIZATION AND CONFIDENT PROPOSAL (Ver.2)

8. : Hardware used for OSS:

  • Will:
    Mr.Lucky, I am considering to propose Linux/OSS based system to my customer. How many choices are there of hardware? What is your recommendation for the hardware installed Linux?
  • Lucky:
    As Linux is basically usable of IA (Intel Architecture) server on which it is originally developed, the same hardware for Windows is also available. Some vendors chose RISC server or mainframe server with Linux. So, customers are guaranteed to use quite wide range of options of hardware just like those for Windows server, or even more than that. You can choose any hardware from worldwide vendors and you are free to change to other vendors at any time. The points of criterion of hardware are, I would say, price, performance, quality, and support. IA servers which many vendors supply are always in highly competitive situation. To use Linux means to make no-vender-lock-in. SIers' Forum (SI-Forum) *7 of OSDL just published the list of Linux supporting status quo, but it is also necessary for you to check the hardware by yourselves.

第二章:OSS活用、提案のコツ(第2版)

8.Linuxが使えるハード:

  • W君:
    先輩、いよいよLinux・OSSでお客様に提案するんですけど、Linuxが載るハードって、どんな選択肢があるんですか?Linuxで提案するときどんなハードを選ぶといいんですか?
  • L氏:
    Linuxは基本的にIA(Intel Architecture)サーバなのでWindowsと同じハードが使えるんだ。RISCサーバとかメインフレームサーバに載せているベンダもいるくらいだ。お客様は、Windowsサーバと同等、あるいは、それ以上に幅広い選択肢が保証されており、世界中どこででもいろんなハードの中から選べるし、また、いつでも別のベンダに乗り換えることができるんだ。ハードの選択基準は、価格・性能・品質・サポートがポイント。従って、ベンダ各社が出揃うIAサーバでは常に激しい競争があって、このためにLinuxを使うと「ベンダロックインがない」と言えるんだ。OSDLのSIerフォーラム*7 でも各ベンダのLinuxサポート状況を掲載しているけど、君自身が、ハードをチェックすることが必要だよ。
*7: http://www.osdl.jp/
>Top

9. Distribution of Linux:

  • Will:
    I found there are many Linux distributors. Can you recommend to me preferable distributors?
  • Lucky:
    There is a list of server models and Linux distribution, mentioning feasible combinations with yes/no matrix, which you can choose best matching of hardware and distributor.
    For business use, I would recommend to you such Linux distributions suitable for mission-critical systems as RHEL (Red Hat Enterprise Linux), SLES (SUSE Linux Enterprise Server), or ML (Miracle Linux). These distributors provide customers with cost effective fee-paying support services corresponding to their Linux distribution. The features of such distribution are:
    1. They are using more stable Linux kernel which Linux community published half or one year ago. They dare to avoid installing challengeable the latest version of Linux kernel.
    2. Linux they commit has relatively long cyclic period version up with one or one and half year cycle, and the long support period continues 5-7 year.
    3. Binary compatibility of applications is guaranteed within the same version.
    4. Therefore, various worldwide commercial middlewares are guaranteed to be ported to such stable Linux distributions.
  • In my company, we usually select a certain Linux distribution which has variety of middlewares in order that our engineers can share technical information of the distribution, unless the client specifies other distribution.
  • Linux distributions which the community packaged like Debian or Fedora are cheaper in price but would be difficult because users must prepare upper applications together with preparing enough number of Linux experts.

9.Linuxのディストリビューション:

  • W君:
    Linuxのディストリビューションも、いろいろあるようですけど、どんなディストリビューションがいいんですか?
  • L氏:各ベンダのLinuxディストリビューションサポート状況は、サーバモデル名とLinuxディストリビューションの組み合わせの○×表になっているから、どのハードを使うと、どのディストリビューションが適用できるかすぐにわかるよ。
    ビジネスユースのお客様には、基本的に、RHEL、SLESあるいは、MLのような、基幹システム対応型Linuxディストリビューションを使うのがいいだろう。これらは、みなLinuxディストリビューションに対する有償サポートサービスの形をとっているんだが、これらのディストリビューションの特徴は;
    1. Linuxコミュニティがリリースして0.5~1年位の安定したカーネルを採用している(敢えて最新カーネルを避けている)
    2. 版数アップのサイクルが1~1.5年程度と長く、サポートサービス提供期間が5~7年
    3. 同一版数内で、原則、アプリのバイナリ互換性がある
    4. そのために、世界中の商用ミドルウェアもこれらの安定したLinuxディストリビューション上での動作保証を行っており、ミドルウェアの選択肢が広くなる
  • 基幹システム対応型ディストリビューションにも何種類かあるけれども、うちの会社では、お客様が指定してこない限り、ミドルウェアが出揃った○○○ディストリビューションを使い、技術者同士の技術情報の共有が深まるようにしている。
  • DebianやFedoraのようなコミュニティがパッケージしたLinuxディストリビューションは、安価だけれど、上位アプリをお客様が作り、お客様側にLinuxを扱える人がいる状況じゃなきゃ難しいな。
>Top

10. Function of Linux Distribution:

  • Will:
    Is it possible to make systems without using a Linux distributor? In other words, what is the meaning or function of Linux distribution?
  • Lucky:
    Of course it is theoretically possible to make Linux system if you compile source code, because it is publicized. In order to make such system, you need to do all such things as;
    1. to make binary by compiling source code;
    2. to collect upper software like Apache, Sendmail, etc. , then compile and test them;
    3. to install binary of Linux system and upper software to the target server, and then test them;
    4. to test the function of commercial middleware on the Linux system;
    5. to collect and apply (select, compile and test) patch programs prepared for security bugs, system bugs, etc.
  • Linux distributors usually collect the latest information about Linux kernel and bug fix programs and others through close communication with Linux/OSS development communities. They also collaborate with middleware developers and server vendors, and perform thorough prior testing of validity of using various middleware and hardwares. They even prepare tools for installation and documents for operation. Actually because the above 1) to 2) may be possible by users who have the knowledge of Linux and OSS, getting from free download sites or free attachment to the Linux journals. But regarding to the above 3) to 4) could not be done without cooperation of and information from server and middleware vendors. In particular, the above 5) requires to retain capable engineers during life cycle of the system.
  • But in case of embedded system, the users can manage by themselves without using distributors, because the above 3) may be the user's own hardware, and the above 4) and 5) may not be so important.

10.Linuxディストリビューションが果たす役割:

  • W君:
    Linuxディストリビューションを使わないシステムって考えられるんですか?結局、ディストリビューションの意味・役割って何ですか?
  • L氏:
    もちろん、Linuxはソースコードが公開されているので、ソースコンパイルすれば、理論的にはLinuxシステムを作ることは可能だよ。でも、そんなことをするには;
    1. ソースコンパイルを実施してバイナリを作成
    2. Apache、Sendmailといった上位のソフトの収集(コンパイルとテスト)
    3. Linuxシステム・上位ソフトのバイナリをターゲットサーバにインストール、さらには、サーバが問題なく動作するかどうかテスト(特に、周辺機器ドライバの収集が問題)
    4. 商用ミドルウェアベンダと協力し、Linuxシステム上でのミドルウェアの動作検証、
    5. セキュリティバグ、システムバグ等の修正パッチの収集と適用(選別、コンパイル、および、テスト)が必要になるんだ。
  • Linuxディストリビュータは、Linuxコミュニティ・OSS コミュニティとの太いパイプを使って、常に、Linuxカーネル・OSS ミドルウェアの開発の状況や障害修正情報を収集している。また、ミドルウェアベンダやサーバベンダと協力してハード・ミドルウェアの事前テストを実施し、さらに、インストールツールやドキュメントをくっつけて、先ほどの1)~5)を行うんだ。1)~2)までならLinux・OSSの知識があればできるし、無償ダウンロードサイトや、雑誌のオマケパッケージもよくあるんだが、3)~4)はサーバベンダやミドルウェアベンダの協力と情報提供がなきゃ大変だ。特に、5)をやるには、有能な技術者をシステムのライフサイクルに渡って確保することが必要になり、基幹システム向け商用ディストリビューションの有償サポートサービスは、この部分を狙ったサブスクリプションビジネスなんだ。
  • 通常のサーバシステムじゃなく、組み込みシステムなら、3)は自前ハードだし、4)や5)が重要じゃないケースもあるので、ディストリビューションを使わないこともあるようだね。
>Top

11. OSS middleware and Commercial middleware:

  • Will:
    What type of OSS middlewares are usable? Or how can we properly choose between commercial middleware and OSS middleware?
  • Lucky:
    Well actually, various types of OSS middleware are included in each Linux distribution package, and you can use these freely which cover wide range of areas such as DNS, Mail, Web server, database, and application server. Their functions are increasing almost as much as the same level of other major commercial middlewares.
  • But of course it is important to select OSS middleware which is supported by the reliable community in order that you may avoid the worst case that could not be supported due to the collapse of the supporting community. If there is a development community (as a local community) or the user forum of the software in Japan, you can expect various responses to your questions which could be helpful and be relieved. But please keep in mind such responses could be given on voluntary basis. If there are commercial services of such software, then you can buy surer support from them. You can refer to the guidance of Japan OSS Promotion Forum describing about "the mechanism of support of OSS software from development community to the end-user".*8
  • Regarding to the evaluation of OSS middleware how those are useful, you can also refer to "Database of the cases"*9 compiled by the SIers' Forum of OSDL-Japan, which containes a number of successful cases installed by various corporations. The information in the database are all success stories, but you had better to check other unsuccessful or painstaking stories through engineers and experts of the certain companies involved, particularly when you want to use unfamiliar middleware.
  • It is true commercial middleware is costly, but you can get surer and more accurate information from the middleware vendor in order to install the system securely. Though the famous commercial middlewares are already ported to Linux, you had better to check instructions and tips from Linux distribution at Web sites of the vendors and the ISVs.

11.OSSミドルウェアと商用ミドルウェア:

  • W君:
    OSSミドルウェアは、どんなものが使えるんですか?商用ミドルウェアとOSSミドルウェア、どう使い分けるといいのでしょうか?
  • L氏:
    Linuxディストリビューションには、いろいろなOSSミドルウェアが添付されていて、タダのように使えるし、OSSミドルウェアのカバーする領域もDNS、Mail、Webサーバから、DB、アプリサーバまで、どんどん広がり、機能強化も主要ミドルウェアをキャッチアップする勢いがある。
  • でも、OSSミドルウェアを使うときには、しっかりとした開発コミュニティがついたものがいい。新しいものに飛びついたが、コミュニティが崩壊したなんてことにならないためにね。日本に開発コミュニティ(支部)やユーザー会があるものは、トラブルがあったときに質問に答えてくれるなど(あくまでも、ボランティアとしての活動であることを理解する必要あり)安心材料になるし、また、そのミドルウェアの商用サポートベンダが存在するようなケースでは、いざという時に頼りになる。日本OSS推進フォーラムの「オープンソース ソフトウェアが開発コミュニティからユーザーに届くまでの仕組み」*8 がいいガイダンスになっているので参考になるよ。
  • 次に、そのOSSミドルウェアがどれくらい使えるかの評価が必要なんだけれど、OSDL SIerフォーラムが収集した事例DB*9 は、いろいろな会社が実施した成功事例で、すごく参考になる。もちろん、事例として登録された情報はキレイな話になっている可能性もあるので、慣れないソフトを使うときは、失敗経験まで含めたドロドロした話をウチの会社の他の技術者・先輩達に直接、聞かなきゃなるまい。
  • 商用ミドルウェアは、当然、お金がかかるけれど、大規模なシステムや、高い信頼性を求められるケースで、ミドルウェアベンダ側が正確な情報を供給してくれるので、安心してシステム構築に利用できる。有名な商用ミドルウェアは当然、Linux上に移植されてるけど、各ベンダ、あるいは、独立ソフトベンダ(ISV)のサイトでLinuxディストリビューションの対応や注意事項をチェックすることは必要だ。
*8: http://www.ipa.go.jp/software/open/forum/support/index.html#Siryo
*9: http://www.osdl.jp/
>Top

12. Sizing information of Linux-OSS:

  • Will:
    Do you know where is the sizing information of systems using Linux and OSS middleware?
  • Lucky:
    In 1980s, capacity of mini-computers can be evaluated only by Dhrystone benchmark*10, but no more such simple and happy years will come. You have already known that capacity of server system firstly depends on each particular application; DNS, Mail server, Web server, scientific and technical calculations, application server, database server, and so forth, which varies not only number of CPUs and MHz but also other hardware capacities of network or storage system, as well as operating conditions. Furthermore, if it is database server, it depends on such so many parameters of combination of database (retrieval-centric or transactions included) or frequency of check points, etc.
  • You can also refer to the released information about benchmark method and certain of capacity data*11 of application servers and database servers by the Development of Infrastructure WG of Japan OSS Promotion Forum. But it is essential for you to make benchmark test by yourself when you offer the system according to the customer's requirement. Of course you can utilize the result of the benchmark done by colleagues of your company, but the result of your own benchmark could be flexibly applicable if the user's condition varied. Anyway you should have the basic stance of collecting current information of OSS middleware from the community and the users group, and more importantly check those by yourself based on self-supporting efforts, which is fundamentally different from the case of using commercial middleware.

12.Linux-OSSのサイジング情報:

  • W君:
    Linuxシステムだとか、OSSミドルウェアを含めたシステムのサイジング情報、どこかにありませんか?
  • L氏:1980年代のミニコンの性能はDhrystoneベンチマーク*10 で済んでいたらしいが、そんな時代は再来しない。サーバシステムの性能っていうのは、その用途(すなわち、DNS、メールサーバ、Webサーバ、科学技術計算、アプリサーバ、DBサーバ等など)によって、CPUの数やMHzだけじゃなく、ネットワークやストレージシステムなどのハードの要因、および、その用途を実現するソフトの動きに大きく影響されることは、君達も充分経験しているだろ。さらに、それぞれの用途の中でも、運用条件によって、例えば、DBサーバなら、DBの構成、検索中心かトランザクション混在か、さらには、チェックポイントの頻度等など、ものすごくたくさんのパラメータに依存してる。
  • 最近、日本OSS推進フォーラムの開発基盤WGが、アプリサーバとDBサーバのベンチマーク手法と一部性能データを公表*11しているので参考にするといいけど、お客様への提案の際には、お客様の利用条件に合わせて、自らベンチマークするのが基本だよ。もちろん、ウチの会社の誰かが実施したベンチマークの結果を聴きに行くのも手だけど、君がベンチマークしておくと、利用条件に多少の変化があっても応用が利くだろ。とにかく、OSSミドルウェアは、商用ミドルウェアと違って、自助努力が基本、ユーザ会などで流通する情報はもちろん参考になるけれど、その情報を確認する責任はある。
*10: http://en.wikipedia.org/wiki/Dhrystone
*11:http://www.ipa.go.jp/software/open/forum/development/index.html
>Top

13. Operation management tool of Linux system and backup software:

  • Will:
    What about operation management tool of Linux?
  • Lucky:
    Linux is the same situation as Windows for which platform venders and ISVs provide operation management software and backup software. Each software may have the same function in Windows and in Linux, but you should confirm this to each vender.

13.Linuxシステムの運用管理ソフト、バックアップソフト:

  • W君:
    Linuxの運用管理ツールはどうなんですか?
  • L氏:
    プラットフォームベンダや独立ソフトベンダ(ISV)が運用管理ソフトやバックアップソフトを提供している状況は、Windowsと同じだね。どのソフトもWindows上と同じ機能がLinuxでも実現されているはずだが、詳細は各ベンダに情報提供してもらう必要があるな。
>Top

14. Security of Linux system:

  • Will:
    What attention should we pay to security of Linux system?
  • Lucky:
    If you say security issue, which includes wide range of factors;
    1. security function as the basic of OS,
    2. anti-virus patches and illegal hacking to computer systems,
    3. disaster contingency planning.
  • The above 2) and 3) are realized by various tools including commercial products, and the situation of Linux attains the similar level of Windows system.
  • Regarding to the above 1), Linux can be operated basically same as UNIX. Windows has enhanced security function such as ACL (Access Control List), and Linux also has realized similar function using SELinux (Security Enhanced Linux) of Kernel 2.6, which is available in each Linux distribution. But It is a problem that there is not a full lineup of middlewares corresponding to this SELinux. Before talking about SELinux, you should know well about this situation.

14.Linuxシステムセキュリティ状況:

  • W君:
    Linuxシステムのセキュリティ、どんな配慮が必要でしょうか?
  • L氏:セキュリティというと、いろいろな要素が混じっていることがあるね;
    1. OS基本機能としてのセキュリティ機能
    2. W君ス対策や不正侵入対策、
    3. 災害対策まで含んでいるケースもある。
  • 上記の2と3は商用製品を含むツールで実現されており、その状況はWindowsの環境と変わりないレベルになっている。
  • 上記1については、基本は旧来のUNIXと同じ運用だと考えたらいい。あまり使われてはいないが、WindowsではACL(Access Control List)など、高度なセキュリティ機能が具わっているんだけど、Linuxでもカーネル2.6のSELinux (Security Enhanced Linux)で同等機能が完成し、各Linuxディストリビューションで使えるようになったんだ。ただし、このSELinuxに対応したミドルウェアがあまり揃っていないのが課題なんだ。お客様とSELinuxの話をする時は、この点を十分に理解しておかなきゃならない。
>Top

15. Development environment of Linux:

  • Will:
    As development environment of Linux, what kind of tools are available on what situation?
  • Linux:
    Regarding to C and C++ linguistic environment and debugging tool are almost same with Windows. Regarding to library functions, there is a big difference between Windows and Linux in the library functions called by C and C++. The concept of basic OS functions such as process creation or termination, and file operation, etc. are basically same. But regarding to function name, and result of function call, you need to check those differences one by one. Actually in Windows, there is subsystem of POSIX which corresponds to the function of UNIX OS. This is rarely used in Windows, and probably you may not have known yet. If you use this on Windows, you can make common source code of the application both on Windows and Linux, but unfortunately this is limited within OS basic functions defined by POSIX standard.
  • Enhanced development environment recently used are particularly different. In case of Windows, Visual Studio or .NET are recommended by MS and often used, but which are not applicable to Linux. Instead, script languages such as Java, PHP, Perl , or integrated development tool like Eclipse are used for Linux. These tools are also applicable to Windows. Thus in order to develop application in the hybrid environment of Windows, UNIX, and Linux, these tools which are not vender locked-in are quite useful.

15.Linuxの開発環境:

  • W君:
    Linuxの開発環境、どんなツールがどんな時に使えるんですか?
  • L氏:
    CおよびC++の言語環境、デバッグツールはWindowsと同じと考えていいだろう。ライブラリ関数については、CおよびC++で呼び出すライブラリ関数については、はWindowsとLinuxのOSの違いが大きい。プロセスの生成・消滅とか、ファイル操作とか、OS基本機能に関する概念は共通性が大きいが、関数名とか、関数呼び出しの結果とかは一つ一つ、違いを確認する必要がある。実はWindowsには、POSIXサブシステムといって、UNIXのOS機能に準拠した環境があるんだが、Windowsの世界でそんなに使われてないようだし、君も知らなかっただろ。LinuxとUNIXはOS機能が同一なので、Windows上でこれを使えば、WindowsとLinuxで、アプリのソースコードを一つにすることができるんだが、POSIXの標準に定義されたOS基本機能に限定されている。
  • 最近よく使われる高度な開発環境は特に差が大きいな。Windowsならマイクロソフトさんお勧めのVisual Studioや.NET(ドットネット)が多用されているけど、Linuxの世界には対応できてない。代りに、JavaやPHP、Perlのようなスクリプト言語、さらにはEclipseのような統合開発環境が多用されている。これらのツールはWindowsでも使えるので、Windows、UNIX、Linuxの混在した環境でアプリを作ろうと思うなら、こちらの方が「ベンダロックイン」が無いということになるんだ。
>Top

16. SI agreement of Linux-OSS:

  • Will:
    Is there any other notandum in making contract?
  • Linux:
    Agreement between a SIer and a client usually constitues a package contract, which could be amended due to the reason of using of Linux-OSS. But it is important to make your client understand the features of Linux-OSS as mentioned before. That is, it needs your customer to understood and become familiar with benefit of Linux-OSS, and hopefully to become a supporter of it.
    JISA (Japan Information technology Services industry Association) proposes a model of SIer's agreement*12, particularly the article 20 of which is very useful.

16.Linux-OSSのSI契約:

  • W君:
    契約で注意しなければいけないことは?
  • L氏:
    SIerの契約は、お客様との関係で包括契約になっていることもあり、Linux・OSSが入るからといって変更できないこともある。でもね、提案の際にLinux・OSSを利用することはお客様にご理解いただくことが重要だよ。第一章でも言ったように、お客様にLinux・OSSの良さをご理解頂き、できればOSSの支持者になってもらうことが必要なんだ。社団法人 情報サービス産業協会(JISA)は、SIer契約のモデルを提案しているが、その第20条は大いに参考になるよ*12 。
*12: http://www.jisa.or.jp/legal/contract_model2002.html
>Top

CHAPTER-3: HOW TO BUILD AN OSS-BASED SYSTEM (Ver.1)

17. Concept and terminology of Linux and Windows:

  • Will:
    Mr. Lucky, Linux-OSS has been adopted in my project. I will start the system installation from now on, but I wonder the terminology of Linux may differ from that of Windows.
  • Lucky:
    Though Linux OS is different from Windows, but as long as you use IA (Intel Architecture) server, hardware, peripheral, and network are basically same. As to commercial middleware like DB software, which supports both Linux and Windows, the operation and tuning know-how are same. But if you use OSS middleware you must recognize the difference from MS product. SIers' Forum of OSDL-Japan published the reference of terminology between Windows and Linux*13, which will be also helpful.

第三章 OSSをベースとしたシステム、構築の勘所 (第1版)

17.Linux-Windowsの概念・用語の対応:

  • W君:
    先輩、僕のプロジェクトのLinux・OSS提案が採用されました。これからシステム構築に入るんですけど、Windowsとはずいぶん言葉が違うんでしょう?
  • L氏:
    OSはWindowsとLinuxの違いがあるけれど、IA(Intel Architecture)サーバを使っていれば、ハード、周辺装置、ネットワークなど、基本は同じだ。DBソフトのような商用ミドルウェアでも、LinuxとWindowsに同じ製品が移植されている場合、その運用やチューニングノウハウも含めて、同じだよ。OSSミドルウェアを使うとマイクロソフト製品との違いが出るのはいたし方ないなぁ。OSDL SIerフォーラムが、WindowsとLinuxの概念・用語の対応を調べてくれたので、一度見ておくと安心なんじゃないか*13 。
*13: http://www.osdl.jp/
>Top

18. Installation of Linux:

  • Will:
    What should we do when we install Linux?
  • Lucky:
    Platform vendors sell Linux installed servers. If you use these products, you need not to worry about delicate connectability issue of hardware and internal peripherals of the server, which will relieve you from burden of installation works. But if your client requires such a change as RAID composition or disk partition, you must do the work which is same with Windows. The install tool of middleware varies according to the distribution, but you need not be worried about because the document and the GUI-based guide will help you.

18.Linuxのインストール作業:

  • W君:
    Linuxのインストール作業はどうなんですか?
  • L氏:プラットフォームベンダがLinuxインストール済みのサーバを作っているので、それを使うと、サーバハードや内蔵周辺装置との相性の問題を心配しなくて、インストール作業の苦労を省くことができるよ。でも、RAID構成やディスクパーティションの変更が必要なお客様では、作業が必要になるんだが、この辺り、Windowsも同じだね。ミドルウェアのインストールツールはディストリビューションによって違いがあったりするけど、ドキュメントもあるし、GUIのガイドもあるので心配は要らない。
>Top

19. Copy of Linux distribution:

  • Will:
    Our customer will purchase lots of systems which have exactly same configuration. In that case I heard that there is no restriction of making copies of the GPL software used in a corporation. Could we make necessary copies of the software if we bought one package from Linux distribution?
  • Lucky:
    No, you couldn't. You are free to make copy if we get from download or free gift of a magazine, but if you buy software from commercial distribution with pay support, you must buy as many as the number of servers to be installed. It is sure that GPL allows free copy, but support service of a distributor is a different story, which requires to buy as many as the number of servers.
    By the way, a pre-installed server with Linux supplied by a platform vender includes pay support service of one year or three years per server as the case may be.

19.Linuxディストリビューションのコピー:

  • W君:
    お客様は同じ構成のシステムを大量に導入するんですよ。Linuxの利用条件を決めたGPLでは、社内でのコピーに制約ないって聞いたことがあるんですけど、Linuxディストリビューションのパッケージを1つだけ購入して、あとはコピーしてもいいんじゃないですか?
  • L氏:
    だめだね。ウェブダウンロード版とか、雑誌のオマケパッケージならどこにコピーするのも自由だけど、有償サポートサービスのついた商用ディストリビューションでは、各サーバ毎に有償サポート契約のついたパッケージを購入する必要がある。確かにGPLはコピーの自由を保障しているけど、ディストリビュータのサポートサービスは1台毎に必要なんだ。
    プラットフォームベンダのLinuxインストール済みのサーバは、1台毎に、一年間とか、三年間の有償サポートサービスがついているんだ。
>Top

20. Reason for pay support service:

  • Will:
    I wonder why download of patch program of Windows is free, while I wonder why it costs money in Linux distribution.
  • Lucky:
    MS covers the cost of development and gains more by the sales of Windows package they developed.
    On the other hand, Linux-OSS has been developed by the communities. So the distributor needs not to cover the development cost. But actually the distributors themselves are contributing very much at voluntary basis as members of the community.
    A distributor performs the function as explained it at "10. Function of Linux Distribution" of Chapter-2, and such cost is regarded as the cost to cover those functions.

20.有償サポートの理由:

  • W君:
    Windowsのパッチダウンロードは無償ですけど、Linuxディストリビューションでは、なぜ有償なんですか?
  • L氏:
    マイクロソフトさんは、彼らが開発したWindowsのパッケージ販売でその開発費をカバーし、さらに大きな収益を挙げているんだ。
    一方、LinuxとかOSSの場合、コミュニティが開発したものなので、ディストリビュータは開発費をカバーする必要ないんだ。もっとも、実はディストリビュータもコミュニティの一員として無償で開発に大きく貢献しているんだけどね。ディストリビュータは、第2章の[Linuxディストリビューションが果たす役割]に説明したような仕事をしているんだけど、あんな仕事をカバーするためのコストだと考えられるね。
>Top

21. Hint for Linux support:

  • Will:
    What will be a hint for troubles during installation?
  • Lucky:
    Any OS requires the same attention to console messages and log description, checking with the documents. It is an advantage in Linux-OSS that you can get the information based on the message text on the Web retrieving various hints or advices from worldwide community sites, etc. But as the last resort, you had better to make your customer contract with commercial support service of Linux-OSS during the installation stage. In the case of our company, we have overall partner contract with xxxx, any troubles regarding to our activities caused before the delivery date can be covered by the commercial support, regardless of our customer has support contract or not.

21.Linuxサポートの心得:

  • W君:構築中にトラブルが起きた時の勘所は?
  • L氏:
    コンソールメッセージやログに注意し、ドキュメントと突きあわせるのは、どんなOSでも同じ。Linux・OSSのいいところとして、メッセージのテキストをもとに、コミュニティのサイトやインタネットの検索で世界中のヒントが見つかることがあるので、やってみるのもいいだろう。でも、いざとういう時のために、構築の段階からお客様にLinux・OSSの商用サポートサービス契約をしてもらう方がいい。ウチの会社の場合、xxxxとは、パートナー契約しているので、お客様への引渡し前のトラブルで、お客様が商用サポートサービスを結べないケースでも、ウチの作業に対して商用サポートがカバーされているんだ。
>Top

22. Request of commercial support:

  • Will:
    What should we do when we get support service?
  • Lucky:
    To make the supporting staff understand the situation, you should inform correctly about the work procedure and situation of the system, including the messages and the contents of log. If it is repeatable, please inform as the repeatable procedure.
    Former Linux could not get the memory dump in case of system hang-up or panic, but the recent commercial distribution for mission critical system can get such memory dump. But it requires proper configuration, so you have to explain it to your customer to prepare dump file.
    Furthermore, you can refer to explanatory materia in such distrbution how to get log or memory dump, version of system, record of installed patch programs as well as script to get such information automatically.

22.商用サポートの依頼:

  • W君:
    サポートサービスを受ける時はどのようにすればいいのですか?
  • L氏:
    作業の手順やシステムの状況、メッセージやログの内容を正しく伝えるのが基本。再現性があるようなら、再現手順として伝える方が、サポートする側の理解が早まることが多い。Linux・OSSの版数やパッチの適用状況を把握して説明するのも当然だね。
    以前のLinuxでは、システムハングやパニックのときのメモリダンプが採れなかったんだけど、最近の基幹システム向けの商用ディストリビューションでは、ちゃんと採れるようになった。でも、環境設定が必要なので、お客様に説明してダンプファイルの用意なんかしなきゃだめだよ。
    また、ログやメモリダンプの採取手順の説明資料とか、システムの版数やパッチの適用状況の記録を自動的に採取するようなスクリプトを一緒に提供しているケースもあるので、それに従うのがいいだろう。
>Top

23. Troubles of application development and/or system performance:

  • Will:
    During installation of a system or development of an application for your customer, what should we do if any trouble in movements or in performance happens related to the application or the system?
  • Lucky:
    Performance tool or debug tool of Linux has inherited the ways of UNIX command, which may feel some unfamiliar senses, but actually there are variety of tools than those of Windows environment. I advise you to understand and, if possible, to utilize in-depth features of each tool so as to challenge to learn Linux source code, which would be much more reliable tool than the level of that for Windows.
    You can also refer to the chapter-1 of "OS layer - procedure of trouble analysis and evaluation of tools" *14in the description of "Evaluation of OSS performance and reliability and development of trouble analysis tool" which are complied by Japan OSS Promotion Forum, where overview of various tools and detailed procedure of trouble analysis are described. But you should remind there are some tools which depends on particular Linux distribution or version thereof; you had better check with the distributor if you feel uncertain.

23.アプリ開発時のトラブルやシステムの性能トラブル:

  • W君:
    お客様のシステム構築やアプリ開発の途中で、アプリやシステムの動作トラブルや性能トラブルがあったらどういう対応すればいいんですか?
  • L氏:
    Linuxの性能ツールやデバグツールはUNIXコマンドの流れを継承しているので、多少違和感があるかもしれないけど、Windowsの環境以上にいろいろなツールがあるんだ。多少、機能の重複もあるようだけど、それぞれのツールの特徴を充分に理解し、できたらLinuxのソースコードも少しは勉強するつもりで使うと、Windowsでできていたレベルとは比べ物にならないくらい確実に問題の解決ができる。
    日本OSS推進フォーラムがまとめた「OSS性能・信頼性評価/障害解析ツール開発」の中の「OS層~障害解析の手順・ツール評価編~」*14 の第1章は、いろいろなツールの概観になっているし、さらに詳しいトラブルの解析手順が説明されている。ただし、Linuxディストリビューションやその版数に依存したツールもあるので、不確かなものは、ディストリビュータに確認する必要がある。
*14: http://www.ipa.go.jp/software/open/forum/development/download/051115/OS-Tools.pdf
>Top

CHAPTER-4: OPEATION OF OSS (Ver.1)

24. How to solve troubles of Linux system:

  • Will:
    Now we have come to the stage of delivery of the Linux-OSS system to our customer. Any troubles during operation at the customer's site will be very serious, so we must concentrate to solve any single trouble if happens. In Windows system, there were many unknown causes of troubles, or if we knew the cause, it would take long time to revise it. What about Linux?
  • Lucky:
    First, the action to troubles during operation by your customer is same as mentioned in the above "23. Troubles of application development and/or system performance" of Chapter-3. You need to explain in detail to the customer's administrator about system operation manual including application procedure. In addition, you had better to explain about operation of various tools, if the customer has the knowledge of UNIX, there would be no difficulty to understand how to operate such tools. Recently younger engineers who know well Linux are increasing.
    It is a clear difference between Linux and Windows that the source code is publicized; due to this openness, all players such as customer, SIer, platform vendor, and distributors have equal position in terms of information and are able to share the problems worldwide. The problems and those solutions found in any place can be circulated as bug information. Linux distributors are watching these information and are ready to provide revised patch programs. And if any difficult problem happens, you can explain properly to your customer getting such information.

第四章 どんと来い、OSSの運用 (第1版)

24.Linuxシステムのトラブル解決方法:

  • W君:
    先輩、僕のプロジェクトのLinux・OSSシステムがいよいよお客様に引き渡されます。お客様先での運用中のトラブルは、再発するととっても困るんで、一つ一つのトラブルを確実に解決しきゃいけないんですよ。Windowsでは原因の究明ができないことが多かったし、原因が分かっても、修正作成に時間がかかってたんですが、Linuxだとどうなんですか?
  • L氏:
    先ず、お客様の運用中のトラブルに対する対策は、第三章の[アプリ開発時のトラブルやシステムの性能トラブル] と同じなんだけど、お客様の運用担当の方には、アプリの運用手順も含めて、整理してキチンと説明しておく必要がある。いろいろなツールの使い方については、お客様にも勉強してもらう必要があるんだけど、UNIXの知識をお持ちなら全く問題なく受け入れてくれるだろうし、最近ではLinuxのことをよく知ってる若い技術者も多くなったようだよ。
    LinuxがWindowsと違うところは、ソースコードが公開されているおかげで、お客様・SIer・プラットフォームベンダ・ディストリビュータが対等の立場で、かつ、世界共通に問題を共有できることなんだ。よそで起きた問題やその解決状況はバグ情報として流通しているし、Linuxディストリビュータはその情報に精通して、的確に修正パッチを提供することが売りなんだ。逆に、解決の難しい問題については、お客様のご理解も戴きやすいと言える。
>Top

25. Maintenance activity of your customer's system:

  • Will:
    What type of maintenance activities of our customer's system?
  • Lucky:
    In order to avoid malfunctions of business application of your customer after your maintenance activity, you should well understand the mechanism of provision of revised program by the distributor. You can check the support policy declared on the Web by the commercial distributor. The support policy may be a little bit different according to the distributor, but commonly contains following categories:
    1. Errata:
      systems bug and security bug, etc to solve particular problem, which are sometimes called 'fix' or 'patch', but are almost synonymous. There are sequential ID number to control these as per each distributor.
    2. Update/SP (Service Pack):
      aggregation of errata. It is called 'Update' or 'SP' as per each distributor. It is provided usually four times a year, and is numbered such as Update1, Update2, or SP1, SP2, and so forth. These updates decrease according to elapsed years.
    3. Version-up:
      Linux distributor usually publishes new version with one and half year period. Many new functions are provided to synchronize all components including Linux kernel, C language, glibc library with the latest developed product by OSS community, together with accumulated revision of bug fixed programs.

25.お客様システムの保守作業:

  • W君:
    お客様システムの保守作業、どんなのがあるんですか?
  • L氏:
    保守作業の結果、お客様の業務アプリの動作がおかしくなるなんてことを避けためには、ディストリビュータの修正提供の仕組みを十分に理解しなきゃならない。有償サポートサービスを提供している商用ディストリビューションのサポートポリシーは、それぞれのウェブサイトで公開しているので、一度は確認すること。ディストリビュータによって多少の違いはあるけど、共通的に次のような3つのカテゴリのサービスで構成されている;
    1. Errata:
      システムバグやセキュリティバグなど、特定の問題を解決する。フィックスとか、パッチとか呼ぶこともあるけど、同義と考えていいだろう。ディストリビュータ毎に一連の識別番号によって管理される。
    2. Update/SP(Service Pack):
      Errataを集約したもの。ディストリビュータによって、UpdateとかSPと呼ぶこともある。年4回くらい提供され、各ディストリビューション版数の出荷から通番(Update1、Update2、、とか、SP1、SP2、、)を振られるが、経過年数に依存して提供頻度は少なくなることもある。
    3. Version-up:
      Linuxディストリビュータは、1.5年程度の周期で新版を提供するんだ。Linuxカーネル、C言語、glibcライブラリ等、全てのコンポネントをOSSコミュニティの最新開発物に同期させるために、累積されたバグ修正とともに、多くの新機能が提供される。
>Top

26. Utilization of Errata:

  • Will:
    Could you give us any caution in applying 'Errata'?
  • Lucky:
    Linux distributor is usually paying attention not to make adverse effect in applying Errata in relation to the application, due to enough internal test by the distributor. And if Errata is given by a platform vendor, who is expected to have performed necessary test before delivering to customers. However, as such Errata is applied to the system in operation at your customer's site, you need to be more careful in taking backup, and then in performing test.

26.Errataの適応:

  • W君:
    Errataの適用にはどんな注意がいるのですか?
  • L氏:
    Linuxディストリビュータは、一般に、Errataではアプリへの影響がでないように気をつけているし、ディストリビュータ内で十分なテストも行われている。また、プラットフォームベンダ経由でErrataを入手したのなら、そのプラットフォームでの検証も行われていると期待できる。でも、お客様の運用中システムに適用するんだから、お客様先での適用には、システムのバックアップを取った上、慎重なテストは必要だよ。
>Top

27. Possible customization of Linux:

  • Will:
    As long as source code is available, could we solve the problem by customizing the source code according to the requirement of our customer?
  • Lucky:
    Of course you could revise the source code by yourself. But you should consider possible risk which may cause another trouble of your customer's system by doing such revision, which includes;
    1. Linux distributor who provides support service may reject to support the system installed of such revised Linux.
    2. There could be adverse effect to the upper application software.
    3. If the official revision of Errata or Update/SP are publicized, then consequent revision of OS may be required, which may increase maintenance and management cost.
  • As I explained at "9. Distribution of Linux" of Chapter-2, Linux distributor for mission critical system dares to avoid the latest kernel trying to minimize bug problem. Thus, it could not or very rarely occurs that new bug which are not reported worldwide appears during operation of customer's system.

27.お客様固有の修正:

  • W君:
    ソースコードがあるということは、お客様固有の修正によって問題を解決することもできるということですか?
  • L氏:
    もちろん、ソースコードの修正を作ることはできる。でもねぇ、そんな修正をお客様のシステムに適用した時の弊害もよく理解することが必要だよ;
    1. サポートサービスを提供しているLinuxディストリビュータは、そんな修正が適用されたシステムのサポートを拒否する可能性がある、
    2. 上位アプリへの副作用の恐れがある、
    3. ErrataやUpdate/SPなど、正規の修正が出てくると、当該修正の再作成が必要となり、維持・管理のコストが大きい。
  • 第二章の[Linuxのディストリビューション]でも説明したけど、基幹システム対応型のLinuxディストリビューションは、敢えて最新カーネルを避けてバグの収束を見ているんだ。お客様の運用中に、世界中でまだ報告されていない新規のバグが出るということは、本当に少ないようだよ。
>Top

28. Utilization of Update/SP:

  • Will:
    How would we be cautious of applying 'Update/SP'?
  • Lucky:
    Update/SP are said that they do not include additional Linux function in principle, except additional support to new hardware such as CPU and peripherals, etc. But as they include lots of revision, you need to perform more cautious test than the case of Errata.
  • Furthermore in general, as Errata provided by a distributor tends not to support old Update/SP, you should utilize the latest Update/SP which include revised Errata including latest security bug or system bug. Getting necessary contact with your customer, and considering impact of utilizing Update/SP, you need to promote how to systematically utilize Update/SP.

28.Update/SPの適用:

  • W君:
    Update/SPの適用にはどんな注意がいるのですか?
  • L氏:
    Update/SPでは、新規ハードウェア(CPU、周辺装置など)のサポート追加を除いて、原則、Linuxの機能追加は含まず、アプリへの影響(非互換)は無いとされているんだが、大量の修正を含むために、Errataよりももっと慎重なテストが必要だよ。
  • それから、ディストリビュータのErrataは、古いUpdate/SP向けに提供されない傾向にあるんで、最新のUpdate/SPを適用した方がセキュリティバグやシステムバグのErrata修正の入手が容易になるんだ。お客様と相談したうえで、Update/SP適用による影響の大きさを考えながら、計画的にUpdate/SPの適用を進める必要があるよ。
>Top

29. Implementation of Version-up:

  • Will:
    When should we perform the version-up?
  • Lucky:
    When you performed version-up, there would be no guarantee that the application had worked in the former version will continue to work. Therefore, in case of version-up, in principle, you should prepare enough time for recompiling of the application and testing of it. Also as new hardware of server exceeding cost performance is usually installed of adopting the latest version, you are often enforced to make version-up according to such hardware migration.

29.Version-upの実施:

  • W君:
    Version-upはどんなときに実施するのですか?
  • L氏:
    Version-upを実施すると、旧版で動作していたアプリは、新版で動作する保証は無いんだ。だから、Version-upでは、原則、アプリケーションの再コンパイル、検証の時間が必要となる。コストパフォーマンスに優る新規サーバハードには最新版が適用されるのが普通なので、ハードの移行とともにVersion-upが必要となることが多いんだ。

| Top | Home | Article | Bookshelf | Keyword | Author | Oxymoron |