先日本屋さんで見つけちゃいました。Fedora Core7。言うまでもなく、Fedora Coreの最新リリース版です。
さっそく弊社の検証用サーバーで試してみることにしました。
同じ系列のディストリビューションでも、バージョンによって癖やハードウェアとの相性、アプリケーションを動作させるための最適な環境設定方法が微妙に異なってきますので、社内での検証作業は欠かせません。
Fedora Core1から6までのなかでも、好きなもの・嫌いなもの、思い入れの強いもの・思い入れのないもの、痛い目にあったもの・助けてもらったもの・・・やはり個性というか私個人との相性みたいなものがあります。
さて今回のFedora Core7はどうでしょうか？期待しています。ラッキーセブンですからね。
思えば・・・
弊社設立して1年目に、それまで使用していたRedHatから、全てのサーバーをFedora Core1に乗り換えるというビッグイベントがありました。
本当にあの時は辛かった。肉体的に。
Fedora Coreとはそれ以来のお付き合い。
Fedora Coreももうリビジョン7。随分時がたったなぁと思っていたら、弊社も同じ歴史を歩んでいたんですね。
さて
これから数週間、様々なテストを繰り返して、OKが出ればお客様のサーバーにもご利用いただくこととなります。
結果はまた当BLOGにてご報告予定です。
私がたまたまサーバールームで作業中に、お客様からお預かりしているハウジングサーバーの一台が、異音を発し始めました。
こういうときは、結構アナログ的な触診が威力を発揮します。
コンピューターを触ってみて、振動や熱の発生源を特定します。
あわせて、耳を近づけて異音の発生源を特定します。
サービス停止時間を極力短くする為には、分解修理前に故障箇所を特定しておき、リペアパーツを先に準備しておくことが大切です。
さて、今回は、
電源ユニットの故障でした。
何はともあれ、ハードディスクの故障ではなくて一安心です。
さっそく予備の部品と交換後、パワーオン。
異常検知から10分、サービス停止はおよそ5分間ですみました。
たまたま私がその場に居合わせたのが良かったのですが、コンピュータ技術者たるもの、常に野生の勘を研ぎ澄ましておかなければならないと痛感しました。
お客様が新規にご購入されたパソコンのインストール＆設定。
こういった作業は日常業務の邪魔にならないよう、休日にさせていただくことが多いのです。
インストール自体は難しくもなく、単調な手順なのですが、難しいのは古いパソコンの環境を移植する作業。
これは大変です。ハードディスクをそのまま内蔵移植するのであれば楽勝ですが、同じようなお仕事環境をお引越しするのは本当に大変なんです。
データやメールの履歴などはコピーしてしまえばOK。単に時間との戦いです。
各アプリケーションの設定を、すぐにでもお仕事を始めていただけるように構築するのは至難の業。しかも完全に行うことは無理です。
ここで大切なのが、お客様のクセや好みを熟知していること。
ツボを抑えていれば、設定のポイントもおのずと見えてきます。
それと、もうひとつ。
弊社の推奨する標準的な環境に慣れていただくよう、さりげなく誘導すること。
理想は、全てのお客様が同一の設定であることなのですがこれは現実的に不可能。とはいえ、ある程度の指針をもっておけば作業の標準化もできますし、担当引継ぎの際も楽になります。
たかがパソコン一台の設定ですが、されど・・・
お金をいただく以上はお客様にご満足いただき、
作業や管理をを効率化する
ことが大切です。
通販サイト構築のお打合せでお取引先を訪問しました。
商品の写真を撮影したり、出荷までの業務フローや伝票や出荷ラベルの印字などの業務に関してヒアリング。
話はしばしば本題から逸れて、お仕事のグチをお聞きする時間が多かったりするのですが、実はこれが大事な時間だったりします。
このお客様は、通信販売のご商売とは別のご本業を営まれています。
複数の部門の会計処理がわずらわしいというお話から始まり、話は販売管理について。
おうかがいしてみると、ご本業の販売管理、商品の業務用卸の販売管理、今回ご導入された個人様向け通販用販売管理と、3種類の販売管理をお一人で使い分けされていることが判明しました。
しかも、それぞれのシステムごとにパソコンは別、LANで接続もされていません。
当然、販売管理間のデータ連動や、会計処理とのデータ連動もなされていません。
これは弊社にはビジネスチャンス、お客様にとっても業務を大幅に改善するいい機会。
問題は、まだ償却されていないOA機器やソフトウェア資産をいかに無駄にしないか？
これは難しい問題ですが、ご提案の大事なポイントです。
当然本日に片付くような問題でもなく、また本題のお打合せや写真撮影の作業で手一杯だったため、後日改めてご訪問させていただくことにしました。
既にご購入されているハード・ソフト資産を活用しつつ、業務をスリム化する今回のようなタイプのご提案は、実現できれば、お客様にとっては大きな経費削減につながります。
しかしながら、新たにご購入いただくものがほとんどないわけですから、正直弊社が手にする利益はごくわずか、あるいは事実上赤字となります。
さて、今回はどうすべきか？我々もボランティアではなくビジネスですから、単に感情や綺麗ごとでは済ませられません。
結局、
・このお客様は、失礼ながらまだまだシステム化の発展途上であること。
・通信販売で今後大きく売上をのばされる可能性を秘めていること。
・弊社の作業に対してこれまで毎回、正当な価値を認めていただき、お支払いいただけること。
そして何よりも決め手になったのが、
・弊社の提案スタイルに非常にご信頼をいただき、頼りにしていただいていること。
こうなると、SEとしてはプライドにかけても引き下がるわけにはいきません。
お客様の経費をなんとしても削減する方法を実現化しなければ。
削減が成功すれば、将来的に必ずや弊社への投資を増やしていただけるはずです。
あるいは、あらたなお客様をご紹介いただけるかもしれません。
今回も
ふとした世間話から始まったビジネスチャンスでした。
システム屋といえども、お客様との人間的なお付き合いはとても大事なことです。
あるお客様の社内に設置してあるターミナルサーバーに対して久しぶりに更新作業を実施しました。
Windows UpdateでSP2とその他もろもろの更新プログラムをダウンロードしてインストール。
サーバーを再起動し、他拠点からのMETA FRAME接続も問題なし！と思った矢先・・・
印刷をかけると文字化けが発生する現象が発覚！
まずは状況の調査
通常のログオン、業務アプリケーションの動作は問題なし。
自拠点でMETA FRAMEサーバーにログオンし印刷をかけても問題なし。
んんー困りました。パッチを消すわけにもいかず、
ターミナルやCitrixの設定をいろいろ変更しても状況は変わらず。
サーバーやクライアント、プリンタやプリントサーバーまでをも再起動しても状況は変わりません。
対処方法を検討
とりあえず、サーバー・クライアント双方のプリンタドライバを最新のものに更新することにしてみました。アップデート時に、DLLが書き換えられてしまい、サーバー側とクライアント側のアンマッチが文字化けの原因になったと推測したからです。
(実は知人にTELでアドバイス貰ったのですが・・・)
クライアント側は問題なく更新できますが、ターミナル側のプリンタは、コネクションの先のプリンタを見ているだけで、設定変更できません。
一寸考えましたが、すぐに解決。
DLLのバージョンを更新してやるだけでいいのですから、ターミナルサーバーに仮のローカルプリンタをインストールし、すぐに削除する。
これでDLLは書き換わってくれるはず！
結果は！？
見事復旧。月末の伝票印字が多い時期だけにちょっと冷や汗ものでしたがなんとか大事には至りませんでした。
10年ほど昔の私がCEを専門で担当していた時期には、『触らぬ神に祟りなし』で、正常に動いている環境は触らない・更新しない というスタイルだったのですが、
ここ最近は積極的に設定変更やバージョンアップをする技術者になってきました。
インターネットのおかげでトラブルに関する情報が簡単に、しかも即座に手に入るようになったことと、古い状態のOSを使い続けることによるセキュリティの問題に対しシビアになってきたからでしょうね。
とはいえ
いいお勉強になりました。
今日の教訓：月末にはアップデート作業を実施しないこと！
弊社内にある1台のサーバーがくたびれてきたので、思い切ってハードウェアを買い換えました。
それに併せてFedora Coreのバージョンアップ。本番稼動するサーバーでは初めてFedora Core6を入れてみました。
もうひとつ初めての試みを。SATAでのハードウェアミラー装置にチャレンジ。
まずはハードウェアミラー装置について。
使用したのは、ACCORD MIRROR2000。ディスクレスタイプを購入して、手持ちのHDDを利用しました。
本格的なSCSIのサーバー機でディスクアレイを組むと結構お値段がかかるので、できる限りIDEにこだわって機器選定をしてきました。
時代はやはりシリアルATA。従来のパラレルATAは部品調達も徐々に困難になってきましたし、速度にも不満を感じるようになってきました。
ソフトウェアミラーでは心許ない場合もあります。
これまでフリーのLINUXで動作する、よいハードウェアミラーリング装置に出会わなかったのですが、今回思い切ってチャレンジしてみました。
結果は今のところ大満足です。操作性、状態の確認のしやすさ、速度共に充分なレベルといえるでしょう。
肝心なディスク故障時のパフォーマンスについては残念ながら(？)試せていません。最後まで試さず仕舞いであることを強く望みます。
そして、Fedora Core6。
インストールと設定変更は無事完了。弊社の利用目的ではFedora Core5の場合とほとんど変わりませんでした。
最新の状態に更新し、退避しておいたデータを復元し、データベースをリストア。
無事本番開始。
と思いきや、なぜか2時間に1回程度の間隔でOSがフリーズするようです。さて、これから調査＆トライ開始です。
"soft lockup detected"で完全にフリーズしている模様。
いろいろ調べた結果、デバイスとカーネルの相性の問題？あるいはカーネル単体の問題と判断しました。
この結論に至るまでに一晩かかりましたが・・・
とはいえ、原因がわかれば何とかなります。起動時のカーネルを一つ落として様子見。
結局、今日現在で4日間問題なく動作しています。これでOKと判断して大丈夫でしょう。
その他にも
ネットワークのドライバがうまく認識しないとか、named.confの名前がなぜかnamed.caching-nameserver.confに変わっていてちょっとあせりましたが、いい経験になりました。
もうすぐFedora Core7も出てくるでしょうし、戦いはこれからも永遠に続きそうです。フリーのOSを利用してサーバー構築をする以上、予期せぬトラブルとの戦いは避けては通れない道でしょうから、また一つ勉強になったと前向きに考えています。
とあるお客様からご依頼があり、他社のサーバーで使用していたCGIのシステムを、お客様の自社内に設置してあるサーバーに入れることになりました。
実は私、Webアプリを手がけてから10年近く経ちますが、CGIはほとんど初めてと言ってもいい位に経験がないのです。
ずっとPHPオンリーだったもので。
これまで(おそらくこれからも)一般的なPerl、CGIのWebアプリケーションに手を出さなかったのは、Web公開しているフォルダにアカウント情報やテキストデータなどをファイルとして保存するという方式に馴染めなかったから。
もちろん、httpd.confや.forwardの設定をキッチリとやればセキュリティはかなりのレベルで確保できるのですが、どうしても不安で仕方が無いんです。
何か探せば穴があるんじゃないかと気が気でない。
一応お断りしておきますが、PerlやCGIがダメだといっているわけじゃないんですよ。私個人の好みの問題なんです。
テキストファイルでアカウント情報やパスワードを保存する方式が不安。
Webディレクトリに見られると困る情報が存在するのは不安。
基本的に情報は全てデータベースに記録し、特に重要なパスワード情報などは暗号化するのがマイルールとして長年やってきたのでなかなか自分の頭が言うことを聞かないんです。
とはいえ、
お客様のご要望を満たすためには、一時的にせよCGIを動かさねばならないのでお仕事をお受けしました。
途中で何度か投げ出したくなるような状況に追い込まれながらも、なんとか環境構築の作業が終了。すでに本番で動作中です。
作業してみて気づいたのは、自分以外の技術者の思想やテクニックを学ぶのも悪くないなということ。
たまにはいつもの土俵以外で戦うのも必要ですね。技術力や思考の幅が広がるのは勿論ですが、なにせ技術者に不可欠な度胸が鍛えられますよ。
