2007年11月8日木曜日

Fedora 8 リリース間近

ついこの前、Fedora 7ってウルトラ7を意識しているのかな?なんて思っていたのですが、もう次期バージョン8が明日(現地時間)リリースですね。

今度はどんな機能が追加されているんだろう?って、7すらダウンロードしてインストールメディア作っただけで、実際にインストールしてないんですけど・・・

8はプロジェクト名werewolfとなっています。

日本語では狼男の事ですね。

オフィシャルサイト見てみると、それらしくなんか怪しげです。

やっぱり気になるのはSeLinuxの設定ですね。

OS自体、セキュアなのは当然要求される事なんですけど、設定が面倒なのは閉口してしまう。

で、せっかくの機能をオフにして使う、と。

実際自分もそうしてます。

過去のリリースでは、バージョンごとに設定が異なっているので、これまたややこしい。

アップグレードしづらくなっているわけですね。

あ、あとデスクトップスクリーンはどうなるのかな?

7では空と言うか気球がメインみたいになってますが、8はwerewolfと呼ばれるくらいなので、満月がメインかな?

2007年11月2日金曜日

Netscape Navigator 9 リリース

自分にとってFirefoxがメインのブラウザになっていますので、すっかり忘れかけていましたが、Netscapeの開発は続いていたんですね。

アメリカでは10/15にNetscape Navigator 9の正式版がリリースされました。

Firefox 2をベースに機能拡張されているようです。

ん?

以前はMozillaプロジェクトでMozillaの開発をNetscapeに生かしていたような気がしますが、今はFirefoxが開発版扱いですか?

新機能として、URLのタイプミスを自動修正する「URL Correction」機能、後で読みたいページをサイドバーに一覧として保存しておける「Link Pad」機能、サイドバーにブックマークだけでなくWebページを表示するミニブラウザ機能「Sidebar Mini Browser」などが搭載されているようです。

また、表示しているタブの状態を保ったまま再起動できるようになるのだとか。これはFirefoxを落とさずにパソコンをシャットダウンしたりログオフすると、次回の起動時に前回の状態で起動しますか?と聞いてきます。この機能の事かな?

ここ数日ダウンロードサイトをチェックしていますが、まだ日本語版はリリースされていません。と、言うか日本語版はリリースされるのだろうか?心待ちにしている日本のユーザーはいるのだろうか?

Firefoxでフォクすけぬいぐるみとかストラップ作って盛り上がっていますからねぇ ・・・

2007年7月21日土曜日

CentOS 書籍情報

このサイトでLAMPの肝心な部分、Linuxについて、どのディストリビューションで話を進めていくかまだ決めていないのですが(CentOSもしくはFedoraです)、先日CentOSについて書籍が発売になりましたので、紹介をさせて頂きます。


新刊「CentOS入門――Linux・サーバ構築徹底活用

Redhatクローンではどれを選ぶべきか悩んでいた時があった事は以前の記事に書きました。

利用者数としてもCentOSが一番で続いてWhiteBoxと言う感じだったと思いますが(サイトで検索した結果数などからの体感で、特に何かの事実に基づくものではありません)、利用者数やサポートフォーラム、ミラーサイトの数、アップデートの頻度からCentOSをチョイスしました。

この本の著者も同じ事を感じられていたようです。

CentOSはRedhatのクローンだけあって、バージョンアップは比較的スローなものの、Redhatの正規版のクローンなのでそれはそれで良いのでしょう。

ただ、Fedora CoreもおそらくCentOS以上にシェアがあると思うのですが、SELinux対応をはじめとして、バージョンアップで機能が一転することも珍しくなく、新し物好きにはたまらないOSですが、一旦運用を始めてしまうと、うかつにバージョンアップできないな、と言うのが正直な感想です。

なので、ワークステーションとか実験環境には良いのではないでしょうか。

時折ドドッと関係書籍が発売されますが、なかなかこれ!と言うものがありません。

以前のRedhat 9やFedora Core 3の時には良い本がありました。

どうも初心者向けの書籍が多いように見受けられます。

DVDは書籍に付属で直ぐにインストールを始められるものの、いざ設定が終わったらどうやってサーバを運営するか、これについて非常に弱い。と、言うか殆ど書かれていないものが多すぎます。

WebとかMailとかはまぁ、使わないことは無いかな、サービス提供してもある程度運営は可能かな、と思うのですが、DNSとかNFSとかここまでのサービスを、果たして超初心者向けの内容をチョイスしたユーザーが利用する可能性はあるのかな?と考えてしまいます。

それ以前にルーターの設定とかセキュリティ、自宅サーバを公開するならもっと大切な内容があるように思われます。

CentOSは商用となったRedhatのクローンOSなので、ワークステーションと言うよりサーバOSですので、サーバ管理に特化した内容になっていると、期待しています。

近所の本屋ではまだ見かけていないのですが、見つけたら買う予定です。

2007年7月20日金曜日

~番外編~ Mailer、Mailサーバについて

先のMailerには書かなかったのですが、RedhatやFedoraで(デフォルトで?)インストールされるEvolutionと言う製品があるのですが、これはMSのOutlookそっくりです。

GUI画面もこれまたOutlookをパクッたとしか思えないほどそっくりです。

Outlookがバージョンアップを何度か繰り返していますので、最近の両者の違いはあるのか良く知りませんが、Linuxデスクトップ上でパーソナル管理を行うにはこのEvolutionで可能です。

さて、Evolutionだけでなく、OutlookのサーバであるExchangeまでもをオープンソース化しようと言う動きがありました。以前。

Openexchangeと言う名称だったと思うのですが、まだベータ版でしかなく、対応言語も英語以外はドイツ語だけだったように記憶しています。

アイデア自体面白そうなのでインストールにチャレンジしてみましたが、成功しませんでした。

その後どうなっているか、ふと気になって調べたところ、Open-Xchangeと言うコミュニティで、引き続き開発を行っていたようで、今年の3月に正式版リリースまでこぎつけたようです。

結構期待されているようですね。

使用出来るメーラーも特に制限されていないようなので、可能であればこのようなデスクトップエンタープライズ製品を、全てOSSで揃える事も可能かと思います。

今家にはテスト環境を構築するマシンが無いのですが、近々会社の余ったマシンで試してみたいと思います。

2007年7月19日木曜日

~番外編~ Officeについて

LAMPというより、オープンソースソフトウェア(OSS)の話題になってしまいますが、MS-Officeと互換性を持つOSSについて。

OpenOfficeと言う製品があります。結構昔、2005年頃から注目しており、OfficeがLinuxで動けば、Microsoft OSのパソコンは要らなくなるのでは?とまで期待していましたが、ま、それはそれで若干問題があります。

このOpenOfficeですが、MS-Officeで言うところのWord、Excel、PowerPoint、それとドローイングソフトの4つがセットになっています。

テンプレートも公開されており、ほぼMS-Office感覚で使えます。GUI画面もパクリ?と言って良いほどMS-Officeとそっくりです。Microsoft側としては問題ないのでしょうか?

OpenOfficeは名前どおりOSSで無料で使用できるのですが、ほぼ同じ内容で有償の製品があります。

Sun Microsystemsから出しているStarOfficeと言う製品です。(と言うより、StarOfficeを無料版にして配っているのがOpenOfficeのような感じです)

ほ~っ、あのSunがね!と言うのが最初の印象でした。

実際に使っている人を最近見ました。Windows上で。なんか変な感じでした。

LinuxなどUNIX系ならいざ知らず、WindowsのパソコンになんでわざわざStarOffice?まだOpenOfficeならお金をセーブしたいと言う気持ちもわかるのですけど。



さて、これらのOffice互換製品ですが、問題が全く無いわけではないです。

これはインストールされているOS環境に依存されてしまうのかも知れませんが、MS-OfficeのPowerPointで資料を作り、OpenOfficeで開いてみて解ったのですが、あまり凝ったフォントを使うと文字化けしてしまったり、位置ズレが起こります。

フォントに関しては、要はLinuxOSで持っていない、もしくはサポートされていないフォントを使ってPowerPointで資料を作ると、OpenOfficeで開く際にフォントを変換して開くのですが、フォントによっても大きさが異なったりしますので、結果左右の開き具合とか改行位置がズレていってしまいます。

標準フォントのみ使用していれば、問題ありません。

もしくはTrueTypeのフォントを購入してLinuxにインストールしておくかですね。

なので、フォントや凝ったスタイルのファイルを作らなければ、さほど問題はないように思います。

2007年7月18日水曜日

~番外編~ Mailer

昨日の続きで、今日はメーラーについて。

BrowserがFirefoxなら、MailerはThunderbirdって事になりますかね。

ただ、以前はMozillaのツール、使いまくっていてNetscapeも2つのバージョン、Mozailaに日本語パッチをあてたもの、日本語版MozillaのWazilla、など実に様々使っていました。

当時はメーラーもブラウザーもNetscapeを使っていました。

会社の中では別のイントラツールを使っていましたが、私の部署では結構何でもあり、と言うわけではありませんが、社外とのやりとりが多い部署だったので、会社とは違うツールを薦めていました。

一つがNetscapeです。

やみくもにMicrosoftが好きじゃないから、と言う理由ではなく、他のメーラーではHTMLメールをじゅしんして、クリックで開くとHTMLのまま開いてしまうものが多くありました。

???何が問題なの?と思われるかもしれません。

当時ウィルスと言えば、メールに添付されてくるのが当たり前でしたが、差し出しを偽ったり、このケースのようにHTMLメールでウィルスにリンクが張ってあって、開くとウィルスをダウンロードするようになっていたり、手が込むようになってきていました。

なので、HTMLメールが即開かれてしまうのは非常に問題があったわけです。

メールにウィルスが付いてくる場合、自分でその添付プログラムをクリックしなければ感染の恐れはなかったですが(本当はWindows OS及びOEのセキュリティ上感染の恐れは十分ありました)、HTMLを開くと言う行為はブラウザーで危ないサイトを自ら閲覧している事と同じ状態になるので、能動的に危ないサイトにアクセスしているのと同じ事なのです。

上記カッコ内のセキュリティホールは、どちらかと言うとバグというか、仕様なので、メールを開くと言う作業で添付ファイルが実行されてしまい、どちらかと言うと受動的です。

が、HTMLメールの閲覧はそうとも言い切れないので非常に注意が必要でした。

ではこぞってNetscapeのメーラーを推奨していたか、と言うとそうでもなく、Netscape社やMozilla Foundationのお家事情があったのかもしれませんが、メジャーバージョンアップするとがらりと仕様が変わる事があり、HTMLメールの表示・非表示も旧バージョンにはあったのに、新バージョンではなくなってしまった、と言った事がありました。

セキュリティ面でもあまり古いバージョンを使うのは好ましくないと思い、Firefox、Thunderbirdの検討を始めたのもそんな経緯がありました。

2007年7月17日火曜日

~番外編~ Browser

LAMP環境ではないのですが、オススメのツールを紹介しようと思います。

と、言っても既にあちこちで見かけられているであろう、フリーのツールです。

オープンソースベースだけとは限りませんが、インターネットに接続する際のツールです。

~~~

先ずbrowserはFirefoxを推します。

個人的にMicrosoftの製品は、インターネットに接続するツールとしてあまり使いません。

IEやOutlook、Outlook Expressの類です

Office関連は使いますけど。

IEはずっと昔から、セキュリティ面で取り沙汰されてきています。

問題はそれだけでなく、OSと直結的に絡んだ仕様になっているので、IE経由でウィルスに感染すると、被害は簡単にOSレベルにまで達してしまうと言う事です。

IE7はまだ使っていません。

会社で動作確認を行ってから使うかもしれません。でもちょっと先の話になるかもしれないですね。

Mozillaというのは旧Netscapeのメンバーが、汎用的なツール作りに取り組んでいるFoundationです。

当初は重かったり、機能もNetscapeとどこが違うの?と言った感じでしたが、2.0前後からけっこうしっかりしてきたように思います。

ただ、Firefoxではきちんと表示されないサイトが幾つもあるのは事実です。

ちなみにfirefoxとはアイコンにあるような火をまとった狐の事かと思っていたら、風太くんでおなじみのれっサーパンだの事だそうです。

なので、自宅のパソコンのデスクトップ画面では、アイコンの名前を”ふうたくん”と変えています。

2007年7月16日月曜日

~番外編~ イントラツール

LAMP環境ではないのですが、イントラツールについて少し述べてみたいと思います。

実際にユーザーがツールを使うにあたり、開発環境、実行環境がどうだろうと関係ありません。

それよりもGUIとか、使い易さの方が重要です。

ひところWeb2.0と大騒ぎされていまして、技術の一つでもあるAjaxが取り上げられる機会がよくありました。

なにか面白いところで使えないかな?と調査していたところ、オープンソースのグループウェアでZimbraというメーラーを中心にしたAjaxのグループウェアがありました。

結構面白かったのですが、何せ日本語対応はまだされておらず、いつになったら国内でリリースされるのかとずっと待っていました。

忘れた頃に、feedpath社からリリースされる事を知りました。

名称はZebraと変わってしまいましたが、機能などは一緒です。

ただ、当面はSaaS運用で、社内サーバで構築もそのうち検討、と言う事でした。

以前Zimbraのβ版をインストールしてみたことがあるので、何もイントラツールをSaaSやASPで利用する事もないのではないか、と考えていました。

最近サイトに訪れてみたら、自社サーバ構築プランも出来たみたいです。

Microsoft社のOutlookを脅かす、ととある方が評していましたので、これから導入されてくる企業も増えてくるかと思います。

2007年7月15日日曜日

イントラSNSで情報共有#2

OpenPNE自体の説明・感想・インストール方法その他は後日にするとして、今回は何故SNSをイントラツールとして取り上げたかを説明していきます。

グループウェア的なツールはあることはあるのですが、実際社内での利用は上手く行っているとは言えず、かつ機能としても乏しい感があります。

行動予定表や、行き先予定など、部内、グループ内で共有できるツールがないため、これは以前から使用している別のWebシステムを利用しています。

業務の運用範囲や形態が変わるにつれ、足りないと思われる機能もまた変わってきます。

たとえば貸し出し用に保管している備品の管理。

誰がいつ、どこで使ったのか、これから使いたいのか、また自分が使いたい時に空いているのかいないのか。

このような機能も不足しています。

通常はこれらの機能はグループウェアで十分まかなえますが、現在私たちが使用しているグループウェアではそのような機能はありません。かと言って既にあるのに他のシステム導入を提案するわけにもいきません。導入者のメンツもありますし。

私の部署は、研究開発をしている部門です。私たちの部門はどちらかと言うとサポート部門ですが、他のグループでは様々な調査・研究をしており、それが製品製造に直結したりしています。

時折その内容の発表会があるのですが、聞いていて思うのは、同じ部署内でありながら、異なるグループ毎に協力し合って行っている業務が幾つかあり、その情報共有システムってどうしているのかな?と言う疑問。また、全てのユーザが同様の知識・経験を持っているわけではないので、たとえ業務と直結しなくても、発表しあう場所があれば、そこで議論が活発になって、担当者の目に留まれば独立した研究・開発に繋がるのではないかな?と言う事。

今回書いているイントラSNSでは、そのような事を目標として提案しようと考えています。

まず、現状の業務についての報告・情報共有は他のシステムで行えるため現状のシステムで行うとして(無ければもちろん、このイントラSNSを使ってもらって良いのですが)、これからの研究課題になりそうなトピック、もしくは自分の知識内容、もしくは今こんな業務を行っているので、これについて疑問に思うことは自分に聞いてください的な自己紹介とオープンな場を自由に作ります。

多くのSNSは紹介制、もしくは登録制をとっていますが、社内ツールなのでそこまで厳しくしなくても良いかと思われます。ただし、なんとなくの登録では意見交換の場としては困るので、最低限誰がコミュニティに参加しているのか判る程度にしておく必要はあると思います。

あとは自分の知識を存分に披瀝して、キャリアアップや昇給、給与アップの材料としてもらうのも良いでしょうし、後継者に知識・経験を伝えるために体系化して業務内容を記述しておくのも良いでしょうし、他の全く異なる部門の方からの質疑応答を受け付けるのも良いでしょうし、とにかく活発な意見交換の場として利用してもらいたいと思います。

とかく今携わっている業務で一杯一杯になりがちですが、これからの企業の先を見据えての研究開発というのも非常に重要ですので、どんなちっぽけなアイデアでも、人の手をかりると大化けする可能性もあります。

とにかく情報発信することがまず第一歩だと思います。

イントラSNSで情報共有#1

このところ、情報共有システムについてばかり説明していますが、今回もその延長です。

XOOPSと言うCMSを自分でサーバにインストールした時にも思いましたが、今までユーザー側としてしか利用する事の無かったサービスを、自分で構築して提供できるようになるとは夢にも思いませんでした。

同様に、巷で大騒ぎされていたmixiをはじめとするSNS(ソーシャル・ネットワーク・サービス)のシステムを自分で構築できるなど、思いもしませんでした。

事のきっかけは、社内の情報共有システムのみなおし、と言うかファイルサーバやポータルサイトなどは存在するものの、部を超えて共有したい情報がある場合、それがどこにあるのか、どうやって保存すると共有しやすいのか、などを提案しようと考えていました。

そこでいろいろ書物を購入し、調査していたところ、幾つか個人の方が作成されたSNSがあるとか。えぇ~っ、そんなの個人で作れるの?と言うのが正直な感想でした。さらに調べてゆくと、オープンソースベースのものもあるとか。

これは是非試してみなくては!

と飛びついてみたのがOpenPNEというオープンソースのSNSです。

既に実績として、So-netなどにシステムを提供している、との事でした。

先日説明したように、一つのサーバに複数のシステムを構築しようとすると、PHPの設定で文字化けしてしまうので、実際どのようなものか、自分のプロバイダでもあるso-netで体験してみました。

ふむふむふむ。

SNSは初体験でしたが、使い方によってはグループウェアでもあり、Blogでもあり、一方的な情報配信だけでなくクローズドな情報共有も出来そうです。

ログインユーザーレベルでのカスタマイズなども出来るようなので、ログイン後の画面設定など、こだわりがある人はいじってみるといいでしょうね。

2007年7月14日土曜日

CMSで社内情報共有

連休が明けた頃、今まで紹介してきたツールの数々について、過去どのように設定を行ったかコマンドや画像なども含め、具体的に紹介していきたいと思います。

それまでは概要的な話を、今しばらく続けさせて頂きます。

~~~

さて、前回イントラBlogと言うツールについて話しました。

Blogは週報や、日々の業務内容を記述し、日報、月報、時系列の業務報告書として利用可能ではないか、と提案しました。

他には、通常社内であればオープンに内容を公開するため、情報発信、検索、などを通じ、専門知識や専門業務知識を共有できるのではないかと思います。

しかし、提案しているBlogの利用方法が、日々の業務内容に基づいているので、内容によってはもっとしっかり内容を練ってまとめたほうが良い場合もあるでしょうし、逆に何かトラブルが発生し、誰に聞いたらよいか判らない場合、Q&A的な掲示板があると良いかもしれません。

そこで以前紹介したXOOPSのようなCMSを利用する事により、該当の掲示板に質問を書けば、担当の方、他の方から返答を書き込んで頂けるわけです。

XOOPSの機能として残念なのは、このように質疑応答をフォーラムで行えるのですが、その中から特に質問回数の多かった内容をFAQなどにまとめるには、担当者が手作業で行わなければならないと言う事です。

FAQのモジュールも存在しますが、あくまでも1から手入力で内容を書き込んでゆくため、フォーラムに書き込まれた内容をそのまま移行して元記事を生かしたりするような事は出来ません。

ある意味2度手間になってしまいます。

次回はフォーラムを少し発展させ、巷で話題のmixiのようなSNSを社内で利用できないか、考えてみたいと思います。

2007年7月13日金曜日

イントラBlogで情報共有#2

Blogを社内インフラツールとして使用するにはどうするか?

これをしばらく考えていました。

私の部署では、週報を書いて提出する事が義務付けられています。

書式は特に決まっておらず、グループ内でも各自それぞれ変わっています。

自分は毎半期毎に業務目標を立てるようになっているため、その業務内容について何をどのように行ったか記述するようにしています。

何を行ったか、だけを記述していますが、他のメンバーは以前からの流れと言うか先週、もしくは先々週に行ったこともそのまま引用記述し、ブラス最新で行ったことを追記するような書き方をしている人がいます。

理由があって、以前全ての彼の過去の週報を読ませてもらった事があるのですが、自分と書き方が違うと言う事もあり、かなり判りづらかった。ある特定の週の週報を読むのであれば、彼の書き方のほうが前後のつながりと言うか、過去どのような事を行ったので先週どういうことを行ったのか、わかり易いといえるでしょう。しかし週報として続けて読むと、何度も同じ記述内容が出てくるし、彼の場合、その中で専修行ったことがどこなのか、を明確になされていないのが判りづらい要因でもあったかもしれない。

と、考えてみると単に今行えていない週報機能を実現させるだけでなく、業務ごとにアーカイブとしてまとめる機能も必要となってきます。

これは以前書いたように、一つの週報として一つのBlogの記事にしてしまうのではなく、業務ごとにカテゴリーを作成し、それぞれの業務について行ったことを一つの記事として記述していけば、日報、週報、月報としてのみならず、業務毎の一連の報告書としても利用可能になる、と言えそうです。

2007年7月12日木曜日

イントラBlogで情報共有#1

せっかくEnterprise版Movable Typeがリリースされているのに、機能について判らない。

”イントラBlog”なんて甘いキャッチフレーズがあるくらいだから、何か通常版とは違う、企業内向けに使えるに違いない!そう信じて疑いませんでした。

機能の違いについて、判らない、判らない、とただモンモンとしていても仕方ないので日本のSix Apartに問い合わせました。

”週報を作りたいのですが、どうしたらよいでしょう?”

返答を頂くまで、かなり時間がかかりました。

それと平行して、試用版を使えないか申請してみたり、他の作業に忙殺している頃、返答を頂きました。

”現状の機能ではそのような事は出来かねます”

えぇ~っ!出来ないの?

単にアーカイブを週毎にやるだけなのに?

やっぱり社長Blogを作って社長に取り入るくらいしか使い方はないのでしょうか?(誰も読まないと思うけど ・・・)

2007年7月11日水曜日

Movable TypeでBlogサイト構築#2

Movable Typeのカスタマイズ、と言っても何もアイデアはありません。

サイトで調べても、う~ん、いまいち。

書店で本を買ってきましたが、機能のカスタマイズと言うよりは、テンプレートのカスタマイズが主でした。

会社で画像ヒラヒラのサイトを作るわけに行かないし、花畑のようにカラフルな色彩にするわけにもいかない。

先ずは、基本的な構造について知る必要がありそうです。

~~~

今までは過去の作業についての書き込みがメインでしたが、ここからは現在進行形の記事とさせていただきます。

~~~

個人的にドメインを取得し、サイトを作るようになると、今度は必然的にデフォルトのテンプレートでは味気なさ過ぎるので自分で手を加える必要に迫られました。

アーカイブ設定の項目を見ると、日毎、週毎、月毎のアーカイブの選択が出来るようになっています。

な~ぁんだ、会社の週報も週毎のアーカイブを作れば、自動的に週報になるじゃん!と思ったのも塚野も間。

デフォルトでの月のアーカイブを週に設定しても、表示は変わりません。

おかしい。これはおかしい。

バグ?何か設定間違えている?

せっかく会社でBlogシステムを週報に、情報共有ツールに、と提案しようと思っていたのにしょっぱなからつまづきました。

最近Enterprise版のMovable Typeがリリースされました。

でも通常版と異なり、個人使用と言う目的でダウンロード出来ないので、機能を試してみることが出来ません。

Enterprise版Movable Typeのサイトで製品紹介を見ても、良く判りません。

社長やマネージャーのBlog配信 ・・・

イヤな予感がします。

ま、そんなところには目をつぶって、通常版とEnterprise版の違いは何か探ってみました。

判りません。さっぱり判りません。

上記のように、会社の役員の人のBlog作りの紹介が目に付いて仕方ありません。そんな事したくないのに ・・・

Movable TypeでBlogサイト構築#1

さて、職場のテストサーバにMovable Typeをインストールしてみましたが、基本的な使い方しかいまいち判らず、かと言ってカスタマイズする必要性も時間も無いように思われたので、デフォルトのまま使用していました。

例のブルーのテンプレートです。

最初のうちは、コンテンツの書き込み以外の機能に目を向けていられなかったので、とにかくBlogとしてではなく、週報や報告書の類の書き込みツールとして使い始めました。

ようやくタグをつけたり、カテゴリー分けをしたりするようになってくるとだんだんとこのツールの便利さが判ってきました。

週報と言っても、なにも一つの書き込みに全て書かなくても、業務ごとに分けてカテゴリーにし、日報の細分化みたいにすると、後で見易くなる事がわかりました。

一応書き込み順でソートしたりその逆でソートしたり出来るので、日報として重宝して使えそうでした。

ただ、テンプレートにあるトラックバックやコメント欄、その他が非常に邪魔に思えました。

コメントはともかく、トラックバックなんて社内の週報に使えるかな?と思いましたが、皆が使い出すとそれはそれで重宝しそうなので、機能は残しておきました。でもその空間が気になる。

さて、日報としては上手く使えそうですが、じゃあこれをどうすれば週報になるの?

ここからカスタマイズへの挑戦が始まりました。

2007年7月10日火曜日

Blogサイト構築への道#3

サイトでMovable Typeのインストール方法を調査したのですが、これがまた問題でした。

何故か?

Webで「Movable Type」と検索すると、Movable Typeについてのサイトと言うよりも、Movable Typeで作成されたサイトがずらりと検索結果に現れてくるからです。Movable Typeに限らず、今のフリーのBlogでもホームページスペースでも同様でしょうが、必ずサイト内のページに、そのサイトを作成したツール名が署名として記述されているからでしょう。

他にも考えられる点として、当時はちょうどネットビジネスが急速に伸びてきた頃で、アフィリエイトやらなにやら訳のわからない広告のみのサイトやらが雨後のたけのこのようにぞろぞろ作られていた時期ではなかったかと思います。

Movable Typeに限らず、仕事上で検索してもBlogサイトばかり上位に現れてきて、利用者としては迷惑この上ない状態でした。なかにはBlogと言えど、自分が欲している技術的な情報をコツコツと書き込んで溜めてあったサイトもありましたが、他は概して言えばあまりにも酷かった。

SEOが成功していたともいえるのでしょうが、利用者を全く無視したサイト郡には辟易としていました。とは言っても検索しないと、自分の仕事に差し障るし ・・・

GoogleやYahooも悲鳴を上げていた頃ではなかったでしょうか。後になってみると、検索アルゴリズムが変わった!と大騒ぎされているのをあちこちで目にしましたから。

話が逸れました。

検索エンジンが落ち着いてくると、ようやくMovable Typeそのものに関する記事について調べられるようになり、インストール方法もなんとか取得できました。

Blogサイト構築への道#2

Movable Typeからファイルをダウンロードし、解凍してWebサーバにアップロードしましたが???だらけでした。

当時からバージョンアップを幾つか重ね、今では比較的簡単にサイトの初期設定が出来るようになりましたが、当時はそうではありませんでした。

以前あれほど絶賛したPHPで書かれているシステムですが、スクリプト言語と言う性質のためか、非常にファイル数が多いのに加え、基本的な設定ファイルにあたりをつけて、中身を確認して問題点の解決をする、と言うわけにはいかなかったのです。

ファイル数の多さに加え、インストールで苦労したのは、システムの構造がいまいち良く理解できなかった事です。現状のバージョンでは、ある一つのディレクトリーにファイル全てをアップロードすればそれで初期設定の準備がほとんど済んでしまいますが、当時のバージョンでは、サイト作りのcgiの部分と、際とコンテンツに繋がるスタティックなコンテンツを別の場所に保存するようになっていました。

いや、なっていたのか敢えて自分でそうしたのか良く覚えていないのですが、サイトの雛形となるファイルをcgi-binディレクトリ以下に置くのはおかしいぞ、と考え、そのようにしたのかもしれません。

上記に書いたようにファイル数が多いので、どれがcgiプログラムに付随するパーツで、どれがコンテンツの雛形に関係するパーツか良く判りませんでした。

仕方ないので、cgi-bin以下とhtmlディレクトリ以下の両方に同じコンテンツを丸々コピーして、それぞれから必要なさそうなものを伺いつつ、削除したりしていました。とても非効率ですね。

Blogサイト構築への道#1

新しモノ好き、と言うだけでなく、当時は仕事がさほど忙しくなかったので、XOOPSのメインテナンスを行いながら、どうしてXOOPSの良さが理解してもらえないのか?と不満を抱えつつ、Blogシステムを調査してみることにしました。

当初はどうしても会社でのBlog利用の理由づけが見当たらなかったので、先ずは個人情報を配信するために使ってみようか、と本屋へ行ってBlog関連の本を3冊ほど買ってみました。

どのBlogシステムが良いんだろう?検討がつきませんでした。

やはり日本語対応である事と、シェアがある事、これを念頭においてツール選択していったところMovalbe Typeが無難な選択であるように思えました。他のシステムでは当時から携帯電話からの記事のアップロードなどがあり、後ろ髪を引かれていましたが。

全く別件で購入してあったWebシステム関連の雑誌に、Movable Typeの創始者のインタビュー記事が載っており、たまたま時期を同じくして目にしていた事も理由の一つであったと思います。なかなか優れた先見の目と、エンジニア魂を感じたからです。

さて、Movable Typeにシステムを絞ってみたのですが、やはりインストールでつまづきました。

2007年7月9日月曜日

CMSからBlogへ

昨日説明したPloneですが、XOOPSを知る以前に「これは画期的!」と衝撃を受けたCMSシステムでありながら、実際導入には至りませんでした。

と、言うか自分で下準備までは作っておいたのですが、これからこれを使いましょう、と提案するには躊躇していました。

先ず一つ目の問題として、まだ十分に日本語対応されておらず、インターフェイス画面がほとんど、いや全部が英語。パッチをあて、日本語のコンテンツを記述しても文字化けしないと言う程度までにしか出来ませんでした。

二つ目の問題として、このPloneシステムがpythonと言う言語で書かれており、あまりなじみが無いため自分以外のメンバーがメインテナンス出来ないと言う事がありました。

先週あれだけPHPの利点について力説したのも、このPloneでの経験があったからです。

コンセプトは非常に面白いのだけれど、使いづらい、そんな印象でした。

その後XOOPSに出会ったわけですが、Ploneがどちらかと言うと、サイトのページのコンテンツ管理用とすると、XOOPSはモジュールの管理用と言う意味合いで、CMSと言うジャンルにおいて、全く異なるものです。

XOOPSでは一つのモジュール自体が昔のサイトのようなものですから、一つのサイトの中で複数の異なるコンテンツを複数の担当者が管理できる、と言うようなシステムです。

さて、XOOP対応のモジュールをいろいろ調査していると、Blogモジュールの要望があちこちのフォーラムに書かれていました。

そもそもXOOPSその他CMSなど、自分にとっては会社の中での情報共有システムですから、Blogのような個人情報発信ツールがどうしてそんなに求められているか、良く判りませんでした。

それでもまあなんだか良く判らないけど、Web検索するとやたらにBlogの記事がひっかかってくるので、これは一体なんだろう?と言った素朴な疑問から、Blogシステムの調査を兼ねてテストサーバにBlogシステムを作ってみることにしました。

もしかしたらPloneで出来なかった事が出来るかも?そんな期待を抱きつつ。

2007年7月8日日曜日

CMSでサイト作りに挑戦

最近では猫も杓子も誰もがBlogで個人的な情報を発信するのが当たり前のようになってきていますが、以前は通常のホームページが主流でした。

自分も、ごく限られた友人向けに無料のホームページサイトで個人的な情報を発信していました。

内容としては、皆さんがBlogで配信しているような個人的な与太話ばかりでした。

無料スペースなので、いくらホームページビルダーで原稿を作っておいても、広告が入ってレイアウトは崩れるし、HTTPで1ページ1ページアップロードするので時間はかかるし、とこらえ性の無い自分にとっては記事を書くことよりも、体裁を整える事が非常に苦痛に感じていました。

会社では各自週報で業務内容を報告しているのですが、最初の頃はメールに書いていました。

そのうち部内でWebサーバを導入すると、HTMLで作成して各自のサイトにアップロードするようになりました。まだ社内でもそのように情報を電子化する事はまれで、結構画期的だったと思います。

各メンバーの週報と別に、業務内容をまとめたものや、その他紙面で回覧していた内容もHTMLで作成するようになりました。

仕事の内容ですから、あまりレイアウトにこだわる必要はなかったのですが、サイトの構造的な部分は年に1度画像を変えて気分を一新させたり、必要な情報に辿りやすくするためにフレームを使ったりといろいろ頭を悩ませていました。

そんな時に目にしたのがPloneというCMSでした。

これはサイトの構造やページの構造を決めておくと、パーツ毎に編集が可能なのでWebデザイナー的な役割の人材が複数いる場合、非常に重宝します。

どういうことかと言うと、たとえば、あるページをヘッダー、フッター、コンテンツ部のボディ、メニュー的なサイドバー、その他会社のロゴなど、便宜上幾つかのパーツに分けておきます。

通常でしたら、1人の専任のユーザーが1ページ丸ごと担当してメインテナンスを行いますが、パーツ毎に担当者を分けておく事が可能なのです。

なので大幅にページ構造を変えたほうが良い事態が発生したとしても担当のユーザーが休みだった場合、他のユーザーが手を付けたり出来ません。

が、Ploneのようにパーツ毎に担当者を割り振り出来ると、少なくとも休んでいない担当者が自分の担当パーツのアップデートは可能なわけです。

2007年7月7日土曜日

XOOPSその後

その後、と言うといかにも廃れてしまったような響きですが、これができないの?あれができないの?と言う厳しい意見もたくさんあったので、何とか皆さんに使っていただけるように、要望に対処しようと格闘しました。

たとえば、フォーラム内で自社製品に関する画像をアップしたい。わざわざクリックして画像ファイルを開いたり、逆に画像が実寸で表示されてしまうのは、システムが重くなってしまうので、普段は、画像が付いていますよ、と視覚的に判るようにサムネイル表示して欲しい、と言ったリクエストがありました。

XOOPSに同梱されているBBSでは画像ファイルの添付が出来ないので、いろいろ調べたら、上記の要望にバッチリマッチしていたBBSモジュールがありました。

他にも言い機能は無いかな?と探していた時に見かけたのがBlogモジュールでした。

当時Blogとは何の事か良く判らず、とりあえず追加はしてみたものの、自分の日記的な個人情報を会社のCMSで発信するのは恥ずかしいので、システム管理者からのお知らせ、みたいな感じで使用していました。

2007年7月6日金曜日

XOOPSについて 追記#2

ユーザーIDを作る画面を見て”おぉ!”と驚きました。

今から思うと、ただ単にシステムを使用するに当たっての契約内容が表記されているだけなのですが、オープンソースのシステムで、そんなにかしこまった内容が表示されたので、「これって本格的なのかも!!!」と思ったのですね。

フォーラム機能が充実しているので、昨今のBlog炎上のように人の中傷・悪口やユーザーIDを悪用したり、フォーラム掲示板で物品販売+(アフィリエイト)しないように、などの内容なのですが、とにかくそんな画面を予期していなかったので、度肝を抜かれました。

自分が担当するフォーラムだけでなく、興味のあるフォーラムに新着通信機能を設定しておくと、そのフォーラムに誰かが書き込むと、その内容がメールで送られてくるのです。

これは超クール!!!

で、業務にあわせてフォーラムを幾つか作り、それぞれにモデレータも決めて準備万全!

上司はじめ、気に入ってくださった方は結構いたのですが、自分の業務には向かない、書くことがない、とかメールで書き込みできないとわざわざログインするのが面倒、などなどネガティブな意見も結構出て、結局そんなに日の目を見ることなく埋もれてしまいました。

XOOPSについて 追記

昨日書ききれなかった事について補足です。

何故こんなにXOOPSを推しているかと言うと、最初に使った時の感激が大きかったからです。

オープンソースのシステムと言うと、どうも軽く見られていた傾向にありました。

当時、少なくとも私の会社の中では。

でもQ&Aシステムや情報発信のシステムが必要、と言われて調べてみたところ、お金もかけずに出来そうなシステムは他にそんなになかったのです。後はせいぜい、これも前に書いたphpBBくらいです。

MySQLの件で書いたように、最初のインストールではすごく苦労しました。

何故インストールが上手く行かないのか、何故説明に書いてあるように出来ないのか。

で、先にDBを作ってしまうと言う裏技を実行してみたのは前述したとおり。

インストール直後のログイン画面はお世辞にも、それまでの苦労を吹き飛ばしてくれるほど見栄えの良いものではありませんでした。

モジュール機能が使えるようになっていないので、とても殺風景なのです。

で、とりあえずアドミニストレーター権限でログインし、必要最低限のモジュールを使えるようにして、自分の名前でログインIDを作るために再度ログインしてみました。

さらに続く

2007年7月5日木曜日

LAMP環境でのアプリケーション

既に具体例は述べてしまいましたが、苦労しつつ何度も何度もインストールを繰り返したシステムについて紹介させて頂きます。

CMS編:

やはりイチオシはXOOPSです。

XOOPSはCMSにカテゴライズされがちですが、どちらかと言うと、コミュニティ向けのフォーラムに特化した機能に強いシステムです。

CMSとは、コンテンツ管理システムの事で、と言っても何の事だか判りづらいかもしれませんが、コンテンツとは以前であれば、HTML言語で書かれたWebサイトの内容が主流でしたが、最近は音声にしろ、Blogにしろ、画像にしろ、動画にしろ、いろいろ考えられますね。

XOOPSではここまで最近のメディア処理には長けていませんが、クローズドなコミュニティだけでなく、全くのオープンなコミュニティに向けるプレーンテキストの情報発信に向いていると思います。

ではBlog etc.には向いていないのか、と言うとそうでもないです。

有志によるモジュールもたくさん作られており、これらを組み合わせる事によって、実に様々な情報発信が行えます。

2007年7月4日水曜日

PHPが鍵#2

昨今LAMPなどといわれるようになりましたが、それでもPHPの知名度はさほど高いわけではなく、かつPHPを駆使してプログラムを作れる人はそんなにいないのではないかと思われます。

かく言う私も、LAMP環境のシステムはいくつkが構築しましたが、単にオープンソースのアプリケーションをダウンロードして、解凍してインストール、と言った程度で、自分でプログラムを作った事があるわけではありません。

でもこんな、と言っては語弊がありますが、スクリプト言語一つでDBまで巻き込んだシステムが作れるなんてスゴイな、と言うのが正直な感想です。

さて、実際に上記のようなシステム構築の際に経験したトラブルですが、一つのシステム、たとえばXOOPSを一つのサーバー上に構築し、やれやれ、と思っても、他のLAMP環境のシステムも一緒にインストールしてしまえ、とすると文字化けが発生したりします。

XOOPSとMovable Typeを一緒にインストールした時がそうでした。

これはphp.iniと言うPHPの設定ファイルに入力、処理、出力時の言語にどのキャラクターセットを使うか指定する箇所があるのですが、ここで衝突してしまうからです。

最善策としては、PHPに絡むシステムは別々のサーバーに構築したほうが良い、と言う事になります。

PHPが鍵#1

さて、LAMPの最後の紹介はPHPです。

PHPって何の略ですか?って聞かれた事があります。

え~っと・・・ 最初のPは何だったかな? hyperなんとかとprocessor?

あ、オフィシャルサイトによると、Hypertext Preprocessorだそうです。

あれ、やっぱり最初のPが抜けている。

簡単に特徴を説明すると、Webアプリケーション作りに特化した機能を持つオブジェクト指向のスクリプト言語です。

Webアプリケーションに特化した、と言うのは大げさな表現かもしれませんが、セッション管理やWeb+DBを円滑に行うコマンド、その他HTTPプロトコールのやり取りに対応したコマンドも持ち合わせていると言う事です。

たとえば、Javaでも当初はそんなにWebサーバ対応は考えていなかったのか、メールに特化したコマンド類を後でjavaxと言うクラスにまとめています。そこにはPHPのコマンドみたいにHTTPに対応したコマンドも含まれています。

Webアプリケーション作りの言語と言うと、以前はperlなどによるcgiプログラムが有名でした。

でも、昨今のようにユーザー情報をバックエンドのDBに格納したり、一度のアクセス数が多くなるととてもperlのcgiでは対応しきれなくなってしまいます。レスポンスやプログラム作成時の品質にも関わってきてしまいます。

PHPはスレッド対応なので、このような心配は無く、Web+DB形式のアプリケーションにも十分対応できるわけですね。

それにJavaによるServletよりもレスポンスや処理能力は高いようです。

ただ、スクリプト言語なので、Javaなどに比べると品質と言う面で確立されたIDEがあまりありませんので、デバッグをいかに上手くこなすかが重要になってくるかもしれません。

2007年7月3日火曜日

MySQLを使う#4

その際使ったSQLコマンドを今ではすっかり覚えてしまって、先日はIBMのDB2を始めて使ってみて、同じようにつまづいたので同じコマンドを使ってみたほどです。

mysql> create database databasename;

mysql> grant all on databasename.* to databaseuser@localhost identified by 'password':

mysql> flush privileges;

mysql> quit;

コマンドの一連はこんな感じです。

名前をつけてデータベースを作成し、データベースにアクセスするユーザーとパスワードを設定しつつアクセス権を指定。設定内容を反映。終わり。

grant allでこのdatabaseuserがdatabaseに対し、全ての権限を与えています。

もっと具体的にmodifyとかdeleteとか権限を制限する事ももちろん可能です。

本当は必要な権限だけ与えるのが安全なのかもしれません。

見ると判るように、これらの一連のコマンドでは単にデータベースの器を作ってそのデータベースにアクセスするユーザーの権限を指定しているに過ぎません。

実際にデータベースを使う下準備としては、Webアプリケーション固有のテーブル群を作成する必要があるはずです。

大抵これらは先のWebアプリケーション設定工程内でSQLを発行し、作成しているはずです。

これは調べればすぐわかりますし、sqlコマンド、もしくはデータファイルをチェックしてもわかります。

MySQLを使う#3

ユーザーも結構多く、フォーラムも比較的充実していたXOOPSでしたが、何故かインストールでつまづいてしまう。

ファイルを削除して、サーバにアップロードし直しても同じ。

古いバージョンを使っても同じ。

途方に暮れました。

つまづく場所と言うのが、データベースへの接続でした。

データベースサーバ名、データベース名、データベースアクセスユーザー名、パスワード、など全て入力し、問題なく次の画面に移ると接続エラー。

困りました。

困り果てました。

それならいっそ、まずデータベースを作ってから設定画面に映ってはどうだろう?とやってみました。

”既にこの名前のデータベースが存在します”とワーニングが出るはずです、普通。

でも、すんなり先へ進めました。何故か。

で、最後まで進んで設定完了!

それまでの苦労は何だったのでしょう?

MySQLを使う#2

MySQLをメインに使用するきっかけとなったのは、会社の仕事でCMSの導入・検討を始めるようになってからでした。

それまではどちらかと言うと、WebMailシステムのようなキラーアプリに関係したシステムが多かったのですが、CMSのように提案型のシステムとなるとなかなか一筋縄にはいかず、サポートやサイトなど調べられる内容もがくっと減りました。

最初に検討したのはXOOPSだったと思います。

XOOPSはphpBBの後継版というか、かなり機能的に似通った部分があります。

どちらを選ぶか迷いましたが、拡張性を考慮してXOOPSを選びました。

これがMySQLと本格的に格闘するようになった第一歩でした。

MySQLを使う#1

LAMPシステムの要となってくるSQLサーバですが、MySQLを使う事が多くなってきています。

シェアとしては他にPostgreSQLがあると思います。

自分も最初はもっぱらPostgreSQLを使用していました。

わざわざLinuxのセミナーで、石井達夫さんの講義にも出席したりしていました。

シーラカンス本も買ったりしていたほどなので、著者のセミナーに実際立ち会えるなんてなんだか不思議な感じでしたね。

まだまだ当時としては、日本語はじめ2バイト文字をきちんと扱えるRDMSが少なかったように思います。

PostgreSQLの技術的な話だけでなく、インストールの仕方みたいな初歩的な内容から説明してくださっていたのが印象的でした。

日本にPostgreSQLを根付かせようと努力されていたのでしょう。

自分自身もLinuxベースのWebアプリケーションではどちらかと言うとPostgreSQLベースのものが多かったです。

大抵は、PostgreSQLかMySQLか選択出来ましたが、知識と経験からPostgreSQLを選んでいました。

が、これもある頃を境にMySQLに移行しました。

いや、移行せざるを得なくなりました。

選択肢がMySQLしかないシステムが増えてきたからです。

2007年7月2日月曜日

ApacheでWebサーバを構築#4

この頃はtar ballの設定ファイルを修正すると、インストール先を変えられることが判っていたので、たとえばrpmパッケージでインストールされているApacheに新しいバージョンを上書きする際、tar ballを解凍し、設定ファイル内のインストール先ルートを修正してバージョンアップに対応していました。

しかし、このような事を何度か続けると、いちいち設定ファイルを書き換えるのが大変になってきました。

たまに修正するのを忘れてしまい、以前のように別の場所に異なるバージョンが存在するような状況に陥った事もありました。

で、OSの選択の時にも説明しましたが、こういった状況を機にRedhatのディストリビューションへと移行したのでした。

で、感じたのは、rpmはとっても賢い!

Apacheなどのアプリケーションの実態だけでなく、ライブラリなどもちゃんと上書きしてくれるし、古い設定ファイルがあった場合はそれを上書きせず、稼動しているアプリケーションが参照しているままの状態でいてくれるのです。

これはとても助かりました。

ただ、ここにもちょっと問題があって、メジャーなバージョンアップの場合、設定ファイル内の項目が増えたり変わったりする事があります。

そうすると、旧バージョンの設定ファイルを新バージョンのアプリケーションが参照するので、エラーになってしまうケースがあります。

これを防ぐためには、バージョンアップする前に現状使用している設定ファイルの名前を変えて、新しいバージョンをインストール。その後新しいバージョンと古いバージョンの設定ファイルの中身を比較し、変化が無ければ古いバージョンの設定ファイルを元の名前に戻して使う、と言う事を行うようにしました。

つまり、頻繁に設定ファイルはバックアップを取るようになったのです。

ApacheでWebサーバを構築#3

さて、Apacheの2.xを使用するようになると、インストール先は:

$ /usr/local/apache2

となりました。

先の1.xとほぼ同じですね。

これらはtar ballのソースコードをダウンロードしてきてコンパイル、インストールした時にもたいていこの場所でした。

が、困ったのは大幅なバージョンアップがあり、rpmを持ってきたときです。

インストール先は:

$ /var/www/

になりました。

ドキュメントルートが:

$ /var/www/html

cgiのルートが:

$ /var/www/cgi-bin

です。

設定ファイルも:

$ /etc/http.conf

となり、1.xの

$ /usr/local/apache/conf/http.conf

と異なってしまいます。

異なるバージョンのApacheをインストールされても、上書きされないため、Apacheの再起動を明示的に行わないと旧バージョンが動いたままの状態になってしまいます。

あれ、おかしいな?と思ってhttp.confファイルを修正するのですが、いかんせん旧バージョンは別の設定ファイルを見ているわけですから、何にも変わりません。

ApacheでWebサーバを構築#2

個人的には新しいもの好きなので、Apache2の安定版が出るや否や、Apache2.xに飛びついたと記憶しています。

1.xと2.xの大きな違いは、2.xではスレッドでApacheが稼動されると言う事です。

2.xでももちろんなのですが、1.xではWebアプリケーションには比較的多くのユーザーがアクセスしてくるだろうとの見解から、最初から5つとか10とかのApacheプロセスを起動させておきます。

すると、複数ユーザーから同時にアクセスを受けても、後のユーザーへのプロセスをアクセスがあってから立ち上げると言うタイムラグが減るわけです。

最初に立ち上げているプロセス数を超えたアクセスがあっても大丈夫なように、アクセスがあると随時空きというかアイドルのプロセスが立ち上がります。

メモリーリソース的に考えると、無駄な事をしているようにも思えますが、ユーザーの立場になってみると、Webサーバにアクセスしたら、すぐにでもレスポンスが欲しいわけです。

ただ、一つ問題は、いつも複数のApacheプロセスが立ち上がっているため、psコマンドなどでプロセスの稼働状況を調べても、果たしてユーザーがアクセスしているからプロセスが動いているのか、アイドル状態のプロセスなのか、以前ユーザーがアクセスし、その後セッションが切れたプロセスなのか、判断しかねると言う事です。

会社のWebサーバの運用を行っていたときは、Apacheのみならずそこで動いている他のアプリケーションのメインテナンスを行い、必要があればリブートしていました。

なので、誰かがWebサーバにアクセスしているのかそうでないのか、判断しかねるのはリブートのタイミングを計る上で、ちょっと難しかったのです。

ApacheでWebサーバを構築#1

オープンソースのWebサーバと言えば、Apacheを置いて他ありません。

公式サイトのデザインでは、インディアンの羽の画像があり、Apacheの名称の由来はインディアンのアパッチ族なのかと思ってしまいますが、実際はさにあらず。

A patch パッチだらけ、と言うのが本来の由来だそうです。

バグ修正でパッチだらけです、とはずいぶん謙虚だな、と思ったりします。

Webサーバを構築しようと言うのであれば、通常OSのインストール時に一緒にインストールしてしまうものです。

なので、設定を変えたりモジュールを追加したり、Webサイトやcgiを使ったWebアプリケーション作りのために後から修正しようとすると、果たしてそれらをどこのディレクトリで行えばよいのか、困ったりします。

Apacheのバージョンは現在2.xですが、1.xの最後の安定版1.3.xをまだ使用していたり、レガシーな技術が好みの方は、いまだに1.3.xを使用したりしています。

公式サイトからも今でもこの古いバージョンをダウンロード出来ます。

1.xを私がインストールしたのは結構昔なのでうろ覚えですが、OSと一緒にインストールすると確かインストール先は:

$ /usr/local/apache

になったと思います。

ドキュメント(Webコンテンツ)のルートは:

$ /usr/local/apache/htdocs

です。

2007年7月1日日曜日

OSの選択 #4

~そして現在に至る~

そうしてしばらくはRedhatばかり使用していましたが、ある時Redhatがサーバー版に力を入れ、有料化になると言う事になり、それからはFedora Coreへと以降しました。

Fedora CoreはRedhatの開発版とでも言うべきディストリビューションなので面白いのですが、不安定なディストリビューションをサーバOSとして使用するには多少抵抗がありました。

その頃なにげにサイトを見ていたら、Redhatサーバー版(有料)のクローン版(無料)が幾つかあるのを知りました。

CentOSやWhiteBoxなどですね。

どれでも良かったのですが、実際にダウンロードしてみて回線の太さやミラーサイトの数、などからCentOSをもっぱら使っています。

Redhatではアップデートコマンドがあったのですが、これは有料のサーバー版でしか使えなくなり、CentOSとFedoraではyumと言うアップデートコマンドを使うようになりました。

会社ではプロキシサーバ経由でLANからインターネットに繋がっているのですが、NATでポート番号まで変えられているためか、上手く行かないことが多いです。

Fedora Coreではつながるものの、タイムアウトして落ちてしまいます。

連続してコマンドを実行すると、一度目はアップデートがあるか、二度目でアップデートのあったファイルをダウンロード、となります。効率が悪いです。

その点、CentOSでは問題なくyumコマンドが使えています。

特にミラーサイトが奈良大学だとスピードが速く快適です。

OSの選択 #3

刷り込みではないですが、最初に触ったディストリビューションの良さを手放す事が出来ず、しばらく悪戦苦闘していました。

もちろん、Redhatが嫌いなわけではないのです。

Vineの親系統ですからね。

ただ、容量が多い(CD2~3枚)のが気になっていたのですね。

当時のマシンはまだまだHDD容量が少なかったですし、Vineはあれだけ日本語環境が強化されていながらCD1枚なのに、Redhatはたるんでる!みたいな気持ちもありました。

しかしまぁ、Vineにも上記のような問題があったわけですし、マイナーなディストリビューションと言う事もあり、サポート面では不安が残りました。


と言った行き先で、ある機会にOSを一掃してRedhatに変えました。

rpmについても少し勉強し、rpmのソースコード版って何かも判ってきました。

このソースコードがあったから、全体で枚数が多かった部分もあるのですね。

ただどうやって使うのか、何に使えば良いのか、いつ使う必要があるのか、良く判っていませんでした。

インストールの仕方がわかると、馬鹿の一つ覚えみたいにソースコード版でインストールしてました。

バイナリー版のrpmがあるのだから、そちらを使えば問題ないのに。

でもそのおかげでコマンドにも強くなりましたし、どういう時に使うのか判りました。

また、自分で一部ソースコードをいじった時に、逆にrpmを作ってみたりもしました。

チャレンジャーでしたね (^ ^);

OSの選択 #2

引き続きOSの選択について

と、まあ前回はVine Linuxについて少し触れましたが、Vine Linuxを管理していく上で、多少困った事がたまに起こっていました。

それはディストリビューションならではのディレクトリ構造です。

Linuxのディストリビューションは、Redhat系、Debian系、など元を辿っていくと幾つかに集約されるのですが、このVineはRedhat系です。

が、しかし、Redhat系でありながら、ディレクトリ構造は本家のRedhatのディストリビューションとは若干異なっていたのです。

なので、インストールCDに入っていないアプリケーションを後から追加しようと、サイトからrpmファイルをダウンロードし、インストールしようとしてもエラーになってしまったり、思いがけないディレクトリの場所にコマンドが作成されてしまったりしていました。

まぁ、当時はrpmって何の事だか良く判っていませんでしたから、tarコマンドで圧縮されたいわゆるtar ballをダウンロードして、コンパイルしていました。

gccやcp、gzipなどへのパスはソフトリンクで何とか問題なく使用できていたものの、ライブラリの場所や肝心のファイルのインストール先へのパスが存在しないなど、ワーニングやエラーがたびたび発生していました。

う~ん、こりゃちょっと問題だぞ・・・

そう思いはじめるようになりました。

OSの選択 #1

LAMP(Linux・Apache・MySQL・PHP)でシステムを構築する場合、先ずはOSをインストールする必要がありますね。

LAMP環境に限った事ではありませんが。

一概にLinuxと言ってもさまざまなディストリビューションがあり、特徴もさまざまです。

個人的に一番最初に触れたのは、VineLinuxでした。

現在はほとんどのディストリビューションがUTF-8対応になってきており、最初から多言語かされているのでインストール時に画面の英語に悩まされる事はほとんど無いのですが、数年前まではまだまだ日本語環境は貧弱でした。

そんな中、Vineだけは日本語表示に力を入れており、インストール時から画面が日本語表示だったので特に困惑する事も無く、作業が行えました。

インストール後もヘルプはNamazuからの検索となっており、こちらは100%とは言いませんが、結構日本語に翻訳されていましたから、インストール後にもコマンドの使い方などを調べる事が出来ました。

また、驚いた事にそれだけ日本語対応していながら、インストールCDは1枚で済んでいたのです。

今では、例えば Fedora Coreでも5~6枚分の容量がありますし、当時でも他のディストリビューションでも2~3枚ほどであったように記憶しています。

いかに優れたディストリビューションなのか、良く判りますね。