じいじの勘違い(BLOG版)

はてな日記から移動してみました。はてさて、どちらが使いやすいのかな?

Mageia(Mandriva派生)を入れてみました。

ふと思い立って、Mageiaと言うMandrivaから派生したディストリを、VirtualBoxの仮想環境へ入れてみました。


「mageia- dvd-1-x86_64.iso」ファイルは、最初の公式リリース版とかで、最初は山形大学の公開FTPからダウンロードを試みると、日頃よくお世話に なるJAISTとは異なり、非常に遅い(ダウンロード開始時点で3時間以上!)ため、15分程度でダンロードの完了予想が表示された台湾のサイトから落と しました。
ミラーサイトは、Mageia公式から選択して下さい。時々、更新されている模様です)

⇒インストール関連の情報は、下記URLで入手できます。
  

Mageia 1(Mandriva Linuxの派生ディストリビューション)に関する幾つかのメモ


インストールで特に悩むような事はなく、VirtualBox仮想環境を認識して、正常に実行が可能なようです。
UBUNTU関連と同様の操作性を維持するため、rootと自分用アカウントのパスワードを同じにしています。

但 し、私の環境(Windows7-64bit、SP1適用済み)では、インストール時にマウスの動作が少しおかしく、右側画面単付近ではホスト側の Windows7にマウスカーソルが遷移してしまうため、マウスで選択できなかったため、タブキーによる項目の移動を行って、インストール・オプション変 更時などの項目選択を行って回避しています。
#まぁ、取り立てて書くほどの、重大なバグではありませんが・・・(汗

過 去にMandrivaを興味本位でインストールした程度の自分には、広く使われているAPTやYUMとは関係のない、(ヨーロッパ圏では有名らしい)独自 ディストリのMageiaで、追加パッケージINSTALLや、既存パッケージのUPDATE用に該当するコマンドが全く不明でした。
#初期インストール時に限っては、インストール時にUPDATEするかどうか聞かれるので、「はい」を選択するとOKです。

色々な方のサイトをググッてみると、どうやらアップデートに関しては、下記の例のようなコマンドで行う模様です。

 ⇒ http://www12.atwiki.jp/linux2ch/pages/33.html#id_cf1d6180
 urpmi.update -a
 urpmi --update --auto-select

  なお、UPDATE元は、元記事の手順でアップデートを行なうことで、山形大学のサイトへ接続されている
  ような感じでした。(まだ詳しく調べていません)

何やこれ、訳分からへんわー、とか関西弁で黄昏ていると、次のような神の声を、Mandriva関係情報で入手。
  

Mandriva Linuxのパッケージマネージャ(Rpmdrake)について

  お気楽なメニューが有るのかと思って、下部のパネルにある「KDEシステム設定」を起動すると・・・ありません。orz

  落ち着いてメニュー構造を調べてみると、「メニュー」⇒「ツール」⇒「システムツール」⇒「Mageia Control Center」
  から起動が可能な模様で、パッケージ管理タブから、ようやっとお目当てのRPM管理メニューに辿り着きました。

  この辺、初心者にはちょっと分かり難くて、1時間以上悩んでしまいました。(^_^;)
  ⇒逆に、慣れた方には、当たり前の常識化も知れませんが・・・


取り敢えず、初心者なインストール編は、これで終わりです。


Windows移動プロファイル保管用ファイルサーバの移行

今回の顛末


  移動プロファイルを保管しているかなり古いWin2000Advancedサーバに不具合が
  発生し、移動プロファイルを新規に構築した仮想サーバへ移行する事になりました。

  移行元のサーバはかなりハードが劣化したWindows2000 Advanced Serverを
  運用中であり、移行先はWindows2003 R2 Standard、単なるファイルの移行
  だし、同一ADドメイン内の作業だから簡単〜〜とか考えていたら、これまたびっくりの
  泥沼にはまってしまいました。

普段からお世話になっている「RichCopy」では、管理者権限でも移行元のProfiles
フォルダを簡単には読み取れない(個別のユーザが所有している)ため、RUNASとか、
Backup権限のある別アカウントによるログインや、スケジュール起動などを試みても、
やっぱりダメでした。

移動プロファイルの移行に関して、MSから公開されたわかりやすい情報がありました。

  上記によりますと、アカウント毎のアクセス権などを取り扱えるソフトが必要という
  事で、WindowsBackupの利用が推奨されていましたが、如何せん古いサーバ
  なだけにバックアップ処理だけで8時間もかかってしまい、このままリストアを
  実行すると10時間を越えそうな勢い
なので、早々にWindowsBackupに見切り
  をつけ、他の手段を探しました。

移動ユーザープロファイルのデータを Windows Vista または Windows Server
2008 に移行するためのサポート ガイドラインが有り、少し調べてみた結果、
  USMT(ユーザ状態移行ツール)を利用して、各ユーザ毎に移行を行う方式のよう
  ですが、個別のユーザではなく、複数ユーザを一括して行いたい、今回の目的には
  合致しない
ようです。
  
  その意味でADMTを利用するような、ドメイン移行時のやり方も参考にはなりません

DFSによるサーバ間のフォルダ同期も試みました。
  しかし、残念ながらWindows2000とWindows2003R2間では、レプリケーション
  パートナーを構築できない(仕様?)ようで、Windows2003R2側のレプリケーション
  ウィザードが常に失敗
します。
  残念なことに、Windows2000側サーバはハード劣化が激しいため、Windows
  2000 側からのDFSレプリケーション設定は見送りました。
   →時間的な制約もあり、こちらは詳しく調べていません。

ファイルサーバ移行ツール(FSMT)の評価は、下記のような情報を参考に行いました。
  Microsoft File Server Migration Toolkit 1.2
  FSMT移行ツールでファイルサーバを移行する(基本編)

  DFS統合は、フォルダ同期に失敗している事もあり見送って、単純にフォルダ移行
  のみを実施。
  時間はかかるものの、FSMTはメニュー形式で実行できてよい感じですし、更新分
  のコピーも、コピー処理を何度か繰り返すことでデータ更新にも対応できました。

  ・・・しかし、Profilesフォルダの、ユーザ毎のセキュリティ情報を、FSMTで正しく
    復旧できません
でした。orz

  移動プロファイルはユーザ毎のセキュリティ情報が必須なので、これがないと移動
  プロファイルによるログイン時にエラーが生じてしまい、利用出来なくなります。

  結果的に、ファイルサーバ移行ツールによる移行方法もダメでした。


その他、下記の情報等を参考にSyncToyなどの、フォルダ同期関連ツールの評価も
試みましたが、全て失敗しました。
サーバ運用の基本に戻り、コマンドベースでRoboCopyによるProfilesの移行を
実施しました。
  robocopyでフォルダをバックアップ/同期させる
  ROBOCOPY のヘルプ

  アクセス制限を回避するため、バックアップモードで少し試してみると、アカウント
  毎のセキュリティ情報の設定複写も含めて、本来の要望に沿った、移動プロ
  ファイルの移行が実現できました。

  ⇒ こんな感じで実行。
    robocopy \\source-svr\profiles \\dist-svr\profiles /MIR /B
           /COPYALL
/LOG:C:\work\log001.log

  現環境でRoboCopyによる移行は、初期データ移行に約6.5時間、日次更新分
  移行には約0.5時間と、ほぼ納得できる実行結果を手にしていました。

  ★ところが、robocopyでも、ファイルサーバ移行ツール(FSMT)と同様に、
   ユーザ毎のセキュリティ情報を正しく復元出来ないケースが一部に見られた
   ため、時間的な制約からrobocopyによる移行を断念しました。orz

  →既存ファイルのセキュリティ情報書き換えなどに難?があるようで、
   Windows2003R2環境では、おそらく不可能なのかも知れません・・・
   (時間が無いので未検証です)

最終的に成功した手段は、冒頭に記載した「WindowsBackupの利用」でした。
  時間はかかりましたが、きっちりと動作します。
  しかし、復元スピードは凄く遅くて、移行作業時間が長引いている関係で焦りました。

  けれど、上記WindowsBackup以外の既知の手段すべてに失敗していたため、
  成功した時の喜びもかなり大きなものでした。
  (が、この時点で、お客さんにはタップリ嫌味を言われて、魂がしばらく抜けた・・・)


取りあえず、今回の難題も足掻きまくって何とか乗り切りました。(汗)

教訓:迷った時は、基本に立ち戻ろう。

何日間か、orzな日々を過ごしたのであります・・・(涙)


Hyper-V2.0配下の、ゲストOSにおけるADドメイン時刻同期

比較的廉価なサーバを3台以上使用し、Windows2008R2 でクラスタを構築し、Hyper-V2.0による仮想サーバでドメインを構築しておられる方は、本番環境以外にも、MSDN や Technet の評価用ライセンスを利用した、自己研鑽のための評価用環境を含めれば結構多いかと思います。

ここで、ドメイン認証サーバに関しては、下記URLにある通り、MSのサジェスチョンに従って、Hyper-V2.0の統合機能から、「時刻同期」機能を「OFF」にして運用していられると思いますが、Guest OS に関しては如何でしょうか?

私が構築した、お客様へ納入した仮想サーバの評価用環境では、5台の廉価版サーバを用いて、認証サーバ2台、Windows2008R2 DataCenter x64 クラスタノード用物理ホスト3台として構築し、認証サーバは敢えてWindows2008 Enterprise SP2 x64 を導入して、Microsoft iSCSI を例の方法で修正して認証サーバへ導入し、iSCSIサーバと兼用しています。

で、2台の物理認証サーバはクラスタ構築専用に特化して構築しており、業務評価用の認証サーバは全て仮想環境へ構築してしています。
先ず、最初は、認証サーバの時刻同期が、必ず失敗する原因が不明でしたが、下記URL??のサジェスチョンに従って、仮想ゲストOS側の設定で Hyper-V2.0統合機能から、「時刻同期」を「OFF」にする事で、外部のNTPサーバ(MFEEDやNICT)などと同期が行えました。

? http://technet.microsoft.com/ja-jp/virtualization/gg491389
? http://support.microsoft.com/kb/976924/ja
? http://technet.microsoft.com/ja-jp/library/dd348449(WS.10).aspx

ところが、今度は、Windows2003R2SP2で構築した、仮想メンバサーバ側で認証サーバと時刻同期が不可能となります。

1.サーバ再起動後または、W32TIMEサービス再起動後は、時刻同期に必ず成功する。
?正副何れかの認証サーバへ、正常に同期する。
?「VM IC Time Synchronization Provider」と、正常に同期する。

2.しかし、翌日以降は時刻同期に連続して失敗し、イベントログへ以下のログが記録される。
?イベントID:24 ソース:W32TIME
タイム プロバイダ NtpClient: ドメイン コントローラ
xxxxx.hogehoge.local へのアクセスを 8 回試行しましたが、
有効な応答が得られませんでした。このドメイン コントローラは、
タイム ソースとしては破棄され、NtpClient は同期先となる新しい
ドメイン コントローラの 発見を開始します。
?イベントID:29 ソース:W32TIME
1つまたは複数のタイムソースから時間を取得するようにタイム
プロバイダ NtpClient は 構成されていますが、どのソースも
現在アクセスすることはできません。 ソースへのアクセスの試行は、
あと 15 分間実行されません。
NtpClient が正しい時間を 参照できるソースがありません。

そうです。見事に失敗します。しかも、延々と・・・

お客様環境でも同様の状態であり、彷徨い続けること数ヶ月ほど・・・そうすると、上の啓示を得たのです。(大げさですね)

http://serverfault.com/questions/24298/w32time-sync-problems-for-hyper-v-guests-w32time-event-ids-38-24-29-35
http://social.technet.microsoft.com/Forums/ja-JP/hypervja/thread/a04f9b1c-4ad3-4881-a66b-8899e0a80944/
http://ja.w3support.net/index.php?db=sf&id=24298

はい、認証サーバと同様に、仮想ゲストOS側の設定でHyper-V2.0統合機能から、「時刻同期」を「OFF」にする事で、仮想メンバサーバも無事に認証サーバと時刻同期ができました。

それにしても、URL?で、次のような記述があり「ドメイン環境で時刻遅れは不味いよね」と思って、統合機能側の「時刻同期=ON」にしていたと言うのに・・・

ヒント: Hyper-V 仮想化環境におけるゲスト OS の時刻同期について
Hyper-V では、ゲスト OS の時刻を進めるためのClock tick を Hypervisor 内で
>エミュレートしております。
>このため、Hypervisor の負荷が高い場合など、ゲスト OS が Clock tick を失う
>可能性があります。
>Clock tick を失うことによってゲスト OS は時々時刻を進められ
>なくなるため、Hypervisor 型の仮想化環境におけるゲスト OS は
>総じて時刻が遅れやすい状態にあります。

普通、上記のように書いてあれば、時刻同期をONにしますって・・・
結局、Standalone 環境限定で、時刻同期をHyper-Vサーバ側にお任せする、とかの補記が欲しいと思うのは、私だけなんでしょうかね?

Sidux(Debian-Unstable)でAvast4-Home(Linux)導入

Windowsでいつもお世話になっているAvast4-Homeですが、今日何気なしに同社のダウンロードページを見たら、Linux版もWorkstationはFreeのものを発見しました。

.debパッケージがあるので、今日弄っていたSidux環境へ導入しました。
インストール自体は、dkpgで一発導入できるのですが、使い方が分かりません???

英語版フォーラムとか見たのですが全く要領を得られず、ふと思いついてTarballを落としたら、すごく簡単なドキュメントが同梱されていたので、一発で判明!!

実行ユーザ毎に、レジストレーションキーの登録が必要なので煩わしいが、キー自体はWindows版で取得したものを流用可能、コマンドラインスキャナーの実行は、昔からお世話になったClamAVの何倍も早くVirtualBoxの仮想環境下にも関わらず、ごく標準的なデスクトップPCで、約400MBデータの完全スキャンを、だいたい10秒で完了しました。

恐るべし、Avast-Home。。。です。

製品版のページ

 →すごい、Linuxだけじゃなく、FreeBSDでも動くようですね。。。

AmaVISd-Newとか、PostfixやQmailのフィルター、そしてSendmailのmilterなどでも使えるので、次の案件から乗り換えを検討するのも良いなぁ。。。

Linuxでも利用可能ですが、FreeBSDでZabbixは優秀

もう2年くらい、Zabbixを運用しています。

Nagiosとか、Zitherとか、色々比較したんだけど、Zabbixが便利です。
PostgreSQL使えって強制もされないし・・・(汗
 この辺分かり易い → http://www.thinkit.co.jp/free/article/0706/21/1/

途中、諸般の事情(FreeBSD後継者がいないとか・・)で、FreeBSD6.1から、Debian4.0etchを再インストールして動作させましたが、同一マシンでこんなにも処理能力が落ちるのかと、驚きを覚えました。

僅か4〜5台のクライアントを監視しただけで、Debianがハングアップしたり、MySQLがエラー吐いたり、目も当てられないような、大変な結果になりました・・・

そうです。やはりFreeBSDはサーバ向きです。
Zabbix1.1.6か、PostgreSQL7.xのPortinngに不具合があるのか、長期間稼働させると、Zabbix Server が勝手に死ぬと言う不具合がありましたが、数十台レベルのサーバ監視に機嫌良く働いてくれました。

それがまぁ、Debian4.0インストール直後の設定では、たった4〜5台の監視でTCP/IPとかのネットワーク関連リソースが枯渇して、SSHでログインする事すら不可能になる始末です。

まぁ、/etc/sysctl.conf にNET4関連の修正をたくさん入れました。
何とか、FreeBSD運用時代と、同レベルで動作しています。。。

そんな不利な点はあるものの、FreeBSDと異なって、セキュリティパッチの適用が、Debian楽ちんです。
性能では一歩劣るとはいえ、Gnomeさえ入れておけば、画面の更新アイコンが光ったら、アップデートして下さい・・・ってオペレータに引き継げます。あぁ・・・簡単、感激!!

そうです。FreeBSDから、Debianに転んでしまった私は、もうFreeBSDには戻れない(ウソ

Windows2003R2SP2、ページプール、非ページプール改善

単一インスタンス記憶域 (SIS⇒Single Instance Storage)とは・・・

「Windows2003 Storage Server R2」で提供された、重複ファイルを排除して
データを保存する技術らしい。。。

ただし、クォータを利用した、DISK領域管理と共存できません。

また、SIS機能を削除すると、重複データに対するリンクが失われ、データが消失
して復旧不可能となります。(何らかのDISK不具合で、SIS領域が消えても同様)

その他、SISを適用したサーバ高負荷時に、意図しないサーバ再起動が発生するなど、
種々の不具合があり、また実機評価を十二分に行わなければ、安定した運用を
提供し難い面があるため、利用しない事を推奨します。

★不具合発生時事例のURL

参考まで、MSサイトで「2003 SIS」で検索すると、山のような不具合が表示され・・・orz

悪夢の定番、IndexServiceとか、DesktopSearchとか、VSSとか、BackupExec(CPS)とか、ArcServとか、、、記憶域や、ページプール領域で不具合起こすサービスなんか要らないよね(−−〆)
#Backupなら、Robocopyか、BunBackupが、高額の商業製品より安定してて便利だよね・・・(汗

長らくサボってたから、もうひとつネタを追加(^^)v

主流の32ビット版Windows2003サーバの負荷低減や、仕様(バグ)改善となるHotFixを適用してみました。

実際の利用時には、下記KB〓をもとに、以下のURLから入手して、十二分に評価してご使用下さい。
  http://support.microsoft.com/kb/該当するKB〓/

1.KB928006 Windows Server 2003 で [STOP-0x0000007f] エラー メッセージが表示される、またはコンピュータが自動的に再起動する(必須)

  リモートデスクトップ不具合に関するHotFixで、リモートデスクトップ接続時に、意図しない
  サーバ再起動が発生する問題を修正します。
  ⇒実際には、非ページプール、ページプールを無限に消費するバグの対策です。

2.KB932755 Win2k3-SP2用Storport更新(必須)

  HBA(HostBusAdpter)用ドライバの不具合を修正します。
  なお、HP社製サーバに関しては、SmartStart7.90以降の適用が事前に必要です。
  ★MSより、HP社製サーバのPSP最新版適用必須と、アナウンスが変更されました。
   ★2008/08/29現在の留意点★
    SmartStart8.00以降がリリースされているが、SmartStart7.9xまでと動作が異なるため、
    動作検証が完全に終了していない。
    サーバ納入時にSmartStart8.20A以降が導入されていない限り、SmartStart7.9xまでが安全。
  ⇒実際には、非ページプール、ページプールを無限に消費するバグの対策です。


3.KB936357 Intel プロセッサ用の信頼性向上マイクロコード更新(必須)

  Intel製プロセッサの不具合(バグ)を、Windows起動時に訂正するHotFixです。
  全てのサーバに対して、適用が必要となります。
  ⇒Intel系プロセッサのハード設計ミスに対するバグ修正です。
   LinuxFreeBSDでも、利用者が知らない所で、OS起動時に自動適用しています。

4.KB940349 Win2k3-SP2用VSS更新(必須)

  VSS(ボリュームシャドウコピー)不具合を修正する、MS推奨の一括修正Moduleとアナウンスが
  変更されました。
  BackuupExecやCPSなど、バックアップソフトなどの利用時は、必須適用となります。
 
  ⇒実際には、非ページプール、ページプールを無限に消費するバグの対策です。
   VSSはまだまだバグが多いので、大量のバックアップ実行時など、
   すぐにリソースを食い尽くし、意図しない再起動などを招きます。

5.KB937455 NTFSドライバの不具合修正モジュール(必須)

  とあるWindows2003サーバにて、本件不具合により、
  DISK上のデータやOS部分が破損する障害が発生した。

  ⇒負荷の多いサーバで、発生する傾向が多いようです。
   低負荷のサーバには、特に適用する必要はありません。

6.KB931311 Winsockメモリ枯渇対応パッチ

  ネットワーク負荷が高いサーバで、Winsock(Windowsソケットモジュール)が非ページプール領域を
  大量に消費する不具合(バグ)を解消するためのパッチ。

  ⇒負荷の多いサーバで、発生する傾向が多いようです。
   低負荷のサーバには、特に適用する必要はありません。

7.KB943295 iSCSIなどサポート用StorPort機能拡張(選択適用)

  iSCSIファイバーチャネル使用時に、StorPort.sysを使用せず、仮想ミニポートドライバを
  使用するようWindows2003の仕様を変更します。
   結果的に、iSCSIファイバーチャネルへのアクセスが効率化され、レスポンスが改善されます。

   ★適用対象:iSCSIファイバーチャネル(FC)を使用するWindows2003サーバ


などです。

PoolMon.Exeで、HotFix適用前後を比較して頂ければすぐに分かりますが、大体50%以下にまでリソース消費量が提言すると共に、サーバの安定度が飛躍的に向上します。

Mailgraph −− Postfix用のメール処理状況

FreeBSDPostfixメールサーバの運用を行っている場合、現在のメール処理状況をWebベースで監視できて非常にラクチン、24時間、一週間、一ヶ月、一年の単位でメールの送受信処理処理状況を表示してくれるだけでなく、運用管理者様な方には非常に気になる、バウンス、リジェクト、スパム、ウィルスの発生状況も同様に表示します。

メールログ(FreeBSDでは/var/log/maillog)からメール処理状況を取得し、Webサーバ側表示スクリプトにはPHPを使用して、負荷データの累積はRRD-Tool使用しているので無闇に負荷監視用データが増えず、初回導入時以外にDISK容量を気にする必要もありませんので、お気楽なサーバ運用には向いていると思います。

また、1年という比較的長期のデータを扱ってくれるので、サーバの更新計画を上司に提示するのが便利になるかも知れませんねww