カテゴリ:OES Linux( 61 )

- 目的 -

全社、あるいは多くの部署で読み書き可能だったファイルサーバーのフォルダのアクセス権を特定の部署、あるいはグループに特定できるように変更したい。

- OES Linux での操作 -

次の OES ファイルサーバーのフォルダ VOL:test には O=ACE(組織全部)と Yoiko.Uses.Osaka.Ace(グループ)に権限が与えられています。

既に O=ACE に [ RWCEFM ] の権限が与えられているため、全社 O=ACE がこのファイルサーバーのフォルダを読み書きできる状態です。グループオブジェクト Yoiko.Osaka.Ace にもトラスティが与えられていますが、この権限はこの場合は余分です。
a0056607_11070253.jpg
したがって、OES ファイルサーバーの VOL:test には グループに関係なくすべてのユーザに権限が与えられています。

これを Users.Tokyo.ACE の OU にのみ解放したい場合 ....

いったんすべてのファイルサーバーの権限を削除して、
a0056607_11072836.jpg

特定の部門、グループにだけ権限を与えます。ここでは Users.Tokyo.Ace に権限が与えられ、Osaka.Ace には与えられていません。全社からではなく、一部の部署がファイルサーバーの特定のフォルダにアクセスできるようになります。

a0056607_11075388.jpg
これで Osaka.ACE のユーザには権限が与えられなくなります。

※ただし、ログインスクリプトで map f:=VOL: などの記述があると、全くボリュームに権限がないと、マップエラーになります。本来であれば、権限がない時点で map のスクリプトを削除するのがベストですが、何か理由があって、ログインスクリプトに手を加えたくない場合は、dummy ファイルを置いて、[ F ] 権だけを与えたファイルを作っておくと良いでしょう。

試しに VOL:dummy.txt のユーザに [ F ] 権のみ与えてみると、東京では見えるフォルダは見えませんし、F権のみなのでフォルダを見ることはできても中身を確認することができません。

a0056607_11081955.jpg
Windows のファイル共有と違って、OES のファイルサーバーのアクセス権(トラスティ)の割り当ては、一か所変えるだけで、メタファイルを一か所変えるだけなので、一瞬で終わります。フォルダの中にどれほどサブフォルダやファイルがあっても、ディレクトリとファイル全体の権限をスキャンして変更しませんので、ファイルサーバーの負荷はほとんど0%です。Windows ファイルサーバーでは数分から数時間かかり、ほとんどその間は、ファイルサーバが利用できない激重状態になります。

次のデモビデオでは、数万ファイルの大量のデータのアクセス権を変える操作を Novell OESでは一瞬、 Windows ファイルサーバーでは30分以上かかり、その間、ほとんどサーバーが使えなくなっている様子を比較したビデオクリップです。

Novell versus Microsoft: Granting Access Rights



また、権限のない不可視のフォルダ共有はエクスプローラにも表示されないため、共有サーバー上に数百、数千の読み書き不可の共有ディレクトリがあっても、ファイルサーバーが返すディレクトリ情報のポケットは「権限のある」ディレクトリだけなので、ネットワークの負荷が少なく高速に表示されます。



- keyword -

ファイルサーバー アクセス権限 変更 共有フォルダを見せない フォルダのアクセス権限を変える 遅い 重い ファイルサーバーの負荷100%

[PR]
by islandcenter | 2017-07-19 11:23 | OES Linux | Trackback | Comments(0)

共有ファイルサーバーというのは、便利な物なのですが、多人数で使っていると、自動的に「要らないファイルのゴミ箱化」、「将来性のないファイルの墓場化」「ファイルのゴミ屋敷化」されてしまう事になります。その「ファイルサーバーのゴミ箱」をセッセとお金と暇を掛けてバックアップを取るというのは実に愚かしい行為です。Windows ファイルサーバーは、一般的に使いづらく、「データのアーカイブ」には便利ですが、「アーカイブ」の条件は個々のユーザが判断するため、一般ユーザは、「とりあえずバックアップしておきたい」ファイルを丸ごとコピーしてしまう傾向があるようです。特に C:\Mydocument なんてのは、丸ごと2世代バックアップを取る、なんて事はユーザさんは平気でやっちゃってくれます。

管理者は、こうした「行儀の悪い」ユーザにメールを送って削除を依頼したりするわけですが、この警告から実際にユーザがファイルを削除するかどうかの判断はユーザの勝手な判断でもあり、何のルールもありません。共用部分でも、退職したユーザが残したゴミファイルで一杯。部署の担当者にとっても所有者不明で削除していいものなのかの判断もできません。

Windows ファイルサーバーは特に「ファイルのゴミ箱」として使われるケースが多いようです。

しかし、この様な状況は、例え、Linux + Samba であっても、Novell OES NetWare でも変わりがありません。しかし、Novell Openenterprise Server (OES Linux) では Linux で使える様々なツールを使い回すことで、無秩序なファイルサーバーの運用ルールに一定の「決まり」を作ってしまえば、ファイルサーバーを「ゴミ箱」化してしまう運用に決定的な方法を作り出すことができます。年金機構の情報漏えいにしても、本来一時的に利用して消してしまえば良いデータを、いつまでも共有サーバーに保管しておいた、という運用上の不適切なルールが徹底されていなかったからなのですね。

要らないファイルはサッサと消してしまえ。

という提案です。

ファイルサーバーをゴミ箱にしないために何をすべきでしょうか。

1) クォータをかける

残念ながら、Windows2012 以前 と Linux+samba ではボリューム単位、ユーザ、グループでしかクォータ管理ができません。Novell Open Enterprise Server ならば、ユーザ+ボリューム単位、ユーザを無視したディレクトリ単位でクォータ管理ができます。例えば VOL1:Share\Sales などに Sales グループのトラスティを与えて、ディレクトリクォータをかける、という設定が容易にできます。これで Sales グループが利用できる全体量を10Gバイトに制限をかける事ができます。この機能は、NetWare 時代から当たり前に揃っていた機能です。

a0056607_12393973.jpg


実際に、ボリューム(パーティション)単位、ユーザ単位でクォータを掛けてたとしても、社内常駐で、例えば Sales フォルダのファイルの作成や更新をセッセとやっている営業アシスタントと、そのファイルを参照するセールスマンの仕事のスタイルに違いがあるわけです。一般的に、ユーザ+ボリューム(パーティション)単位でクォータを掛けても、社内業務を主に行うユーザと、更新より参照系の業務が多いユーザを区別することはありません。

そもそも、それ以前に Linux + Samba では、パーティションの設計が非常に難しくなります。

したがって、あまりユーザ、グループをボリューム単位でクォータをかけるのは良い事ではありませんし、ほとんど意味がなく、まず実際には使われていないように思えます。したがって、トラスティがある「営業部のフォルダは10G、開発部は20Gですね。ホームディレクトリは5Gに制限します」とディレクトリクォータをかけた方が良いわけです。これで、ユーザは自然に「大事なファイル」だけをセッセと共有フォルダに保存するように心がけ、無駄なファイルを置かない習慣ができるのです。Linux + Samba ではこの機能はありませんし、 Windows では 2012 以降に利用できる様になったようです。残念ながら、Windows でディレクトリクォータを使うケースを紹介している記事はあまり見ません。つまり、Windows 2012 でも、Windows ファイルサーバーは単なる「ファイルのゴミ箱」なのです。

2) アクセスのないファイルを削除してしまう。

それでも、ファイルサーバーは一つ間違えると「ファイルのゴミ箱」となってしまいます。重要なアーカイブであるならまだしも「生きていない」ファイル「死んでいるファイル」を片付けるには、実際にアクセスのないファイルを探して削除してしまう方法が一番でしょう。 Novell Open Enterprise Server は SUSE Linux ベースなので、NSSボリュームに対しても、一般的は find コマンドを使って "find -exec rm" でアクセスのないファイルを自動削除する事ができます。 NetWare が Linux に移植されて、使い勝手が良くなった点の一つです。

これが今回の主題です。

ファイルの更新日時を変えてみる

oes11x1:/media/nss/VOL2 # touch -d "2010/1/1" test/old-text.txt

oes11x1:/media/nss/VOL2 # ls test -alu
total 1384
drwxrwxrwx 1 root root 4096 May 29 15:55 .
drwxrwxrwx 1 root root 4096 May 29 15:43 ..
-rw-rw-rw- 1 root root 707395 May 29 15:53 old-butnew_text.txt
-rw-rw-rw- 1 nobody root 707395 Jan 1 2010 old-text.txt

a0056607_1251628.jpg



oes11x1:/media/nss/VOL2 # ls test -l
total 1384
-rw-rw-rw- 1 root root 707395 May 29 15:53 old-butnew_text.txt
-rw-rw-rw- 1 nobody root 707395 Jan 1 2010 old-text.txt

30 日以上アクセスがないファイルを探してみる
oes11x1:/media/nss/VOL2 # find test -atime +30

.. 見当たらない..

一日以上アクセスのないファイルを探してみる
oes11x1:/media/nss/VOL2 # find test -atime +1
test/old-butnew_text.txt
test/old-text.txt

..あった..

一日以上変更のないファイルを探してみる

oes11x1:/media/nss/VOL2 # find test -mtime +1
test
test/old-butnew_text.txt
test/old-text.txt

.. 二つあった ..

そのうちの一つを開いてみる(保存はしない vi で開いて :q! で逃げる)

oes11x1:/media/nss/VOL2 # vi test/old-butnew_text.txt

一日以上アクセスのないファイルを探してみる

oes11x1:/media/nss/VOL2 # find test -atime +1
test/old-text.txt

.. さっき開いたファイルがリストされなくなった ..

それでは「1日以上アクセスがないファイルを削除」してみます。

oes11x1:/media/nss/VOL2 # find test -atime +1 -exec rm -f {} \;
oes11x1:/media/nss/VOL2 # ls test -lu
total 692
-rw-rw-rw- 1 root root 707395 Jun 1 09:00 old-butnew_text.txt

... アクセスしなかった old-text.txt だけ消えた ....

今度は「更新されていないファイルを削除」してみる
oes11x1:/media/nss/VOL2 # find test -mtime +1 -exec rm -f {} \;

今度は mtime を使ってみる

oes11x1:/media/nss/VOL2 # ls test -lu
total 0

.. 変更されていないため、削除 ..

oes11x1:/media/nss/VOL2 # vi test/newfile

.. 新しいファイルをつくって保存してみる ..

oes11x1:/media/nss/VOL2 # ls test -lu
total 4
-rw-rw-rw- 1 root root 19 Jun 1 09:43 newfile

1日以上更新がないファイルを削除してみる。
oes11x1:/media/nss/VOL2 # find test -mtime +1 -exec rm -f {} \;

... -mtime ... で一日以上更新のないファイルを探して削除

oes11x1:/media/nss/VOL2 # ls test -lu
total 4
-rw-rw-rw- 1 root root 19 Jun 1 09:43 newfile

.. 作成したばかりで消えない ..

oes11x1:/media/nss/VOL2 # touch test/newfile -d "2000/1/1"

.. touch して更新日付を変えてみた ..

oes11x1:/media/nss/VOL2 # ls test -lu
total 4
-rw-rw-rw- 1 root root 19 Jan 1 2000 newfile

.. 変わっている ..

oes11x1:/media/nss/VOL2 # find test -mtime +1 -exec rm -f {} \;

.. -mtime で削除できるか ...

oes11x1:/media/nss/VOL2 # ls test -lu
total 0

... 削除された ...

oes11x1:/media/nss/VOL2 #

... ファイルを作ってみる ....

oes11x1:/media/nss/VOL2 # touch test/newfile
oes11x1:/media/nss/VOL2 # ls test -alu
total 0
drwxrwxrwx 1 root root 4096 Jun 1 10:11 .
drwxrwxrwx 1 root root 4096 Jun 1 10:10 ..
-rw-rw-rw- 1 root root 0 Jun 1 10:11 newfile

... rmdir ... で一日以上古いディレクトリを削除してみる

oes11x1:/media/nss/VOL2 # find . -mtime +1 -exec rmdir {} \;
rmdir: failed to remove `./test': Directory not empty

..ファイルあるので rmdir では削除されない..


※もっとも、ファイルを削除するという事はディレクトリエントリの更新が入るため、ディレクトリの更新時間もアップデートされてしまいます。という事で一日待ってみました。

- 一日後 -

oes11x1:/media/nss/VOL2 # date
Tue Jun 2 11:15:13 JST 2015
oes11x1:/media/nss/VOL2 # ls -alu
total 16
drwxrwxrwx 1 root root 4096 Jun 2 11:15 .
drwxr-xr-x 4 root root 4096 Jun 1 08:46 ..
d--x--x--x 1 root root 4096 Jun 1 10:17 ._NETWARE
drwxrwxrwx 1 root root 4096 Jun 2 11:14 test <-- これ
drwxrwxrwx 1 root root 4096 Jun 2 11:14 test2
drwxrwxrwx 1 root root 4096 Jun 1 17:14 test3

oes11x1:/media/nss/VOL2 # find . -mtime +1 -exec rmdir {} \;
  <-- 一日以上アクセスがないディレクトリを削除
find: `./test': No such file or directory

oes11x1:/media/nss/VOL2 # ls -alu
total 16
drwxrwxrwx 1 root root 4096 Jun 2 11:15 .
drwxr-xr-x 4 root root 4096 Jun 1 08:46 ..
d--x--x--x 1 root root 4096 Jun 2 11:15 ._NETWARE
-rw-rw-rw- 1 root root 87 Jun 1 17:20 rmoldfile.sh
-rw-rw-rw- 1 root root 49 Jun 1 17:20 rmoldfile.sh~
drwxrwxrwx 1 root root 4096 Jun 2 11:15 test2 <-- なくなりました
drwxrwxrwx 1 root root 4096 Jun 2 11:15 test3

-r--r--r-- 1 root root 24 Jun 1 17:20 ~DFSINFO.8-P
oes11x1:/media/nss/VOL2 #

ただし find コマンドでディレクトリサーチを行うと、「ディレクトリにアクセスされた」と判断される様で、タイムスタンプが変わってしまいます。それならば、もっとシンプルな方法で、「空のディレクトリは無条件で削除」してみる事にします。

-空のディレクトリを削除-

oes11x1:/media/nss/VOL2 # ls -alu
total 12
drwxrwxrwx 1 root root 4096 Jun 2 12:08 .
drwxr-xr-x 4 root root 4096 Jun 1 08:46 ..
d--x--x--x 1 root root 4096 Jun 2 12:05 ._NETWARE
-rw-rw-rw- 1 root root 87 Jun 1 17:20 rmoldfile.sh
-rw-rw-rw- 1 root root 49 Jun 1 17:20 rmoldfile.sh~
drwxrwxrwx 1 root root 4096 Jun 2 12:05 test2
drwxrwxrwx 1 root root 4096 Jun 2 12:05 test3
oes11x1:/media/nss/VOL2 # find . -type d -empty -delete
oes11x1:/media/nss/VOL2 # ls -alu
total 12
drwxrwxrwx 1 root root 4096 Jun 2 12:09 .
drwxr-xr-x 4 root root 4096 Jun 1 08:46 ..
d--x--x--x 1 root root 4096 Jun 2 12:09 ._NETWARE
-rw-rw-rw- 1 root root 87 Jun 1 17:20 rmoldfile.sh
-rw-rw-rw- 1 root root 49 Jun 1 17:20 rmoldfile.sh~
drwxrwxrwx 1 root root 4096 Jun 2 12:09 test3 <-- 空ディレクトリが消えた
oes11x1:/media/nss/VOL2 #

-サイズの大きなファイルを削除-
最近はあまり見なくなりましたが、ネットでダウンロードした「同僚に言えないファイル」をセッセと職場のファイルサーバーに保存する不届きなユーザも居ます。管理者からするとバレバレなんですけど、バックアップログを見ていると、こんな無駄なファイルの為にバックアップを毎日取っていると虚しくなります。

そこで、一定以上のファイルサイズのファイル(特にビデオファイルなんか)を削除してみます。

oes11x1:/media/nss/VOL2 # ls test -l
total 278016
-rw-rw-rw- 1 root root 284673464 Jun 2 14:15 Himitsu.AVI
<--- なんじゃこの巨大ファイルは.....
--w--w--w- 1 nobody root 7168 Jun 2 13:59 Thumbs.db
-rw-rw-rw- 1 root root 22 Jun 2 14:05 small.file
oes11x1:/media/nss/VOL2 # find . -size +10000k
  <-- 10M以上のサイズのファイルを探す。
./test/Himitsu.AVI
oes11x1:/media/nss/VOL2 # find . -size +10000k -exec rm -f {} \;
<--- 削除する。
oes11x1:/media/nss/VOL2 # ls test -l
total 12
--w--w--w- 1 nobody root 7168 Jun 2 13:59 Thumbs.db
-rw-rw-rw- 1 root root 22 Jun 2 14:05 small.file
 <--- 巨大なファイルだけ消された。

※ -size は k(バイト) M(バイト) G(バイト) の指定もできます。

 
まとめ

実運用では、テープバックアップなどの作業を行う前に実行されているように、定期的に cron 実行する形式になるでしょう。

また、厳しくクォータをかけたディレクトリと「一定の条件で削除される」フォルダとの違いをユーザに説明しておくことは重要です。ここでは( . ) カレントディレクトリを指定していますが、実際の運用では絶対パスを指定するようなスクリプトを作った方が良いでしょう。

- カレントディレクトリ( . )以下の1日以上アクセスがないファイルを削除 -
find . -atime +1 -exec rm -f {} \;
find . -name "*.*" -atime +1 -exec rm -f {} \;
※ スペースが入っているファイルや漢字ファイルがあるとうまく動かないので -name "*.*" を付けてみました

これでも十分なのですが、空ディレクトリが残ってしまうため

- カレントディレクトリ( . )以下のファイルのない空のディレクトリを削除 -
# find . -type d -empty -delete

事例では1日としていますが、当然90日とか365日とか指定できるため、これは現状に合わせて適度に調整する事になるでしょう。

一定のサイズ以上のファイルを削除
# find . -size +10000k -exec rm -f {} \;
ここでは +10000k 以上、つまり10Mとしてみました。

※ ヒント:実際には "Thumbs.db" などが残ってしまうケースもあり、これを find スキャンするとタイムスタンプが更新されてしまうため、ディレクトリは空にはならない様です。エクスプローラから見てファイルがないのに、ディレクトリが削除できません。が、実際には Thumbs.DB が残っているためです。明示的に削除しないとダメな様です。実際の運用の現場で find を使いこなして、うまく”古くて消したいファイル”を削除する必要があります。

-オマケ-
oes11x1:/media/nss/VOL2/test4 # touch -at 0511121213 file-a
oes11x1:/media/nss/VOL2/test4 # ls -alu
total 0
drwxrwxrwx 1 root root 4096 Jun 4 11:17 .
drwxrwxrwx 1 root root 4096 Jun 4 11:01 ..
-rw-rw-rw- 1 root root 0 Nov 12 2005 file-a


touch -at YYYYYMMDDHHMM file-name.txt (月日年時分年々月日時分) 形式でファイルの最終アクセス時刻を意図的に変更できます。


islandcenter.jp

- Key Word -
Novell Openenterprise Server クォータ管理、容量管理、古いファイルの自動削除、ファイルサーバー管理
[PR]
by islandcenter | 2015-06-02 13:08 | OES Linux | Trackback | Comments(0)

次の OES は 2015

Join the OES 2015 Authorized Beta!
[PR]
by islandcenter | 2015-05-03 23:37 | OES Linux | Trackback | Comments(0)

ファイルサーバーのメンテナンスや移行などで、ボリューム全体を読み込み専用にしたい場合があります。

ファイルサーバーのマイグレーションはほとんどの場合、ボリューム全体のアクセス権限をそっくり新しいサーバーに移行することです。

しかし「ファイルの棚卸」も重要なことで、これはシステム管理者の仕事ではなく利用部門が行うべきことです。つまり

「新しいボリュームにはデータは入っていないから、古いボリュームから『必要な』データだけ新しいサーバーに移行して欲しい」と宣言し、利用部門にデータの移行をおこなわせれば、どれほど「ゴミデータ」を抱え込んでいたのかを彼らも実際に実感するでしょう。実際に1Tバイトのファイルを保有していても、実際に業務に必要なファイルの棚卸をしてみると100Gバイトも必要なかった、という事に気が付いてくれると有難いものです。

また「とりあえず全部コピーしちゃえ」ということでは、莫大な時間が掛かることにきがつくわけで、やっぱりファイルの棚卸は重要なのです。

となると、古いサーバは読み込み専用にしてしまうのが一番効果があります。

Windows サーバーでは、ボリュームのプロパティから全体を「読み込み専用」にして

「サブフォルダにも適用する」

をチェックして実行するとディスクアクセスの嵐。
終わるまで、今日は帰って寝ようか、ということで翌日変なエラーで止まってショボーン、という事がある訳です。

また解除するためには、「読み取り専用」のフラグをリセットして「明日の朝の結果」を待つことになります。

--
Novell Openenterprise Server では NCPcon コマンド一発でボリューム全体を読み込み専用ボリュームに変更することができます。

How to mount an NCP volume as read-only.
https://www.netiq.com/support/kb/doc.php?id=7014969

マニュアルはこちら

https://www.novell.com/documentation/oes2/file_ncp_lx/data/ncpvol.html

実際に RW 可能なディスクがあります。
a0056607_12135850.jpg


これを読み込み専用に変更します。
oes11x1:/media/nss/VOL1 # ncpcon disable write VOL1
... Executing "disable write VOL1"
Volume write disabled.
... completed OK [elapsed time = 4 msecs 609 usecs]
a0056607_12142215.jpg


ユーザはファイルを書き込むことができません。
a0056607_12146100.jpg


読み込み専用を解除するには ncpcon enable write を実行します。
oes11x1:/media/nss/VOL1 # ncpcon enable write VOL1
... Executing "enable write VOL1"
Volume write enabled.

... completed OK [elapsed time = 419 usecs]
oes11x1:/media/nss/VOL1 #
a0056607_12172190.jpg


ファイルの書き込みが許可されました。
a0056607_12172022.jpg


ちなみにこれは NCP の機能ですので、直接サーバーコンソールから mkdir などをしても効果はありません。
a0056607_12312362.jpg


一般には、システム管理部門は、バックオフィスの経理や総務のデータには詳しくても、業務部門でどの情報が重要化までは判断できないものです。

この様に古いファイルサーバーのボリューム全体を読み込み専用にしておけば、ファイルサーバー移行から例えば「1か月の猶予」を置いて、事業部門のファイルの棚卸をさせます。

テープで古いサーバーのバックアップを取り、例えば「5年間だけ保管しておく」と宣言してしまえば、膨れ上がったサーバーのディスク容量がスリムになります。物理的なスリムさだけではありません。部門ユーザにとっても、必要、不要が判断できないファイルが多すぎると業務自体のボリュームが増えるのです。

その後古いサーバーを停止、破棄すればよいのです。

-Keyword-
Windows Novell OES Openenterprise Server ボリューム全体 ドライブ全体 読み込み専用 書き込み禁止


そのほかの情報は
islandcenter.jp
[PR]
by islandcenter | 2014-10-08 10:48 | OES Linux | Trackback | Comments(0)

古いサーバーから新しいサーバーに移行する場合、ユーザの使い勝手が最大限変わらないことは大変重要な事です。

実際には HA クラスタなどを導入すれば良い、という事でもありますが、よほど大規模なネットワークや未停止システムでもなければ、短いメンテナンス時間で、サクッとサーバーを入れ替えるテクニックで、最小のダウンタイムでサーバーや、ディスク装置を入れ替えることが出来ます。

現実的には、iSCSI デバイスのリース、償却期間切れ、ディスク容量の圧迫による装置全体のスケールアップなどのタイミングで、サクッと入れ替えてしまう事が現実的な作業となります。

例えば、サーバー本体の / (ルート)パーティションは仮想マシン上で動作しており、ディスク装置が外付けの iSCSI デバイスである場合、iSCSI デバイスを別な筐体に移行してやれば、以前の環境をそのまま移行することは、Novell Openenterprise Server では簡単な事です。

手順としては新しい iSCSI デバイスをマウントした状態で

1) 新しいボリュームを新しい筐体上に New_VOL: として作成する。
2) 古いVOL: の中身を New_VOL: に nwcopy コマンドなどでコピー同期する。

- この間移行期間-

- 移行-

3) VOL: を VOL_Old: にリネーム
4) VOL_New: を VOL: に変更
5) ユーザに解放
6) 問題がなければ VOL_Old: を削除/撤去

という手順となります。

ここでは、ボリューム名の変更手順を説明します。ここから逆に古いサーバーの入れ替えテクニックを考えてみましょう。

まず、 iManager の Role(役割) から Storage > Volume を選び、サーバーの VOLUME を Rename します。
a0056607_12572532.jpg


これでボリューム自体は VOL_New に変更できます。しかし、実際には /media/nss/VOL にマウントされています。
a0056607_1301574.jpg


実際に名前を変える場合は、警告がでるので Continue
a0056607_1313515.jpg


実際の mount コマンドで確認すると VOL_New は /media/nss/VOL にマウントされています。

oes11x1:/media/nss # ls -al
total 8
drwxr-xr-x 3 root root 4096 Jun 16 13:02 .
drwxr-xr-x 3 root root 4096 Jun 15 09:17 ..
drwxrwxrwx 1 root root 4096 Jun 16 13:04 VOL1
oes11x1:/media/nss # mount
/dev/xvda2 on / type ext3 (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,mode=1777)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
securityfs on /sys/kernel/security type securityfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
none on /var/lib/ntp/proc type proc (ro,nosuid,nodev)
admin on /_admin type nssadmin (rw)
novfs on /var/opt/novell/nclmnt type novfs (rw)
/dev/pool/P1 on /opt/novell/nss/mnt/.pools/P1 pype nsspool (rw,name=P1)
VOL1_NEW on /media/nss/VOL1 type nssvol (rw,name=VOL1_NEW,norename)
oes11x1:/media/nss #


ログインスクリプト上では server\VOL: はなくなってしまったのでドライブマップは失敗します。
a0056607_1375528.jpg


そこでログインスクリプトを書き換えてしまいます。
a0056607_1394813.jpg


無事スクリプトで map できます。
a0056607_1311336.jpg


逆に、マウントポイントを変えてしまえばいいので iManager > Role > Storage > Volume より Mount Point を変更してしまいます。/media/nss/new を作り、

oes11x1:/media/nss # mkdir new

iManager からマウントポイントを変更します。
a0056607_131523100.jpg

これで、VOL: は別なマウントポイントにマウントできます。

oes11x1:/media/nss # mount
/dev/xvda2 on / type ext3 (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,mode=1777)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
securityfs on /sys/kernel/security type securityfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
none on /var/lib/ntp/proc type proc (ro,nosuid,nodev)
admin on /_admin type nssadmin (rw)
novfs on /var/opt/novell/nclmnt type novfs (rw)
/dev/pool/P1 on /opt/novell/nss/mnt/.pools/P1 type nsspool (rw,name=P1)
VOL1_NEW on /media/nss/new/VOL1 type nssvol (rw,name=VOL1_NEW,norename)
oes11x1:/media/nss #


ということで、Novell Openenterprise Server のボリューム名の変更とマウントポイントの変更は容易に数分で完了します。

ここで説明した手順はあくまでも、順序が逆で、新しい革袋に古い葡萄酒を詰める方法ではないじゃないか、という事になります。

そこで実際に想定する、新しい革袋に古い葡萄酒を詰め込む方法としては、

1) 新しい iSCSI デバイスを iSCSI イニシエーターで接続
2) 新しい iSCSI デバイスに対して iManager から VOL_NEW を作成して定義、/media/nss/new/VOL にマウント
3) nwcopy などでアクセス権などをまとめてcron などで VOL: -> VOL_NEW: に定時コピー

- ここは移行期間中 -

4) 使用禁止の宣言(ここからが本番移行の始まり)最終同期を行う
5) server/VOL: の名前を iManager から server/VOL_Old に変更
6) /media/nss/VOL のマウントポイントを /media/nss/OLD/VOLに変更
7) /media/nss/NEW/VOL のマウントポイントを /media/nss に変更

これでログインスクリプトの変更も必要なく、ユーザが server/VOL: にアクセスする場合は新しい革袋の中の葡萄酒となります。

8) ncpcon で disable write VOL_OLD をセットして、古いボリュームを書き込み禁止に
9) ユーザに解放、もし、コピーされていないファイルがあったり、おかしな現象が出た場合のために、 VOL_OLD の中身は DLT メディアやHDDメディアにバックアップコピーを取り、半永久保存のアーカイブを取る。
10) VOL_OLD:を eDirectory 上から削除して、iSCSI Initiatorから 古い iSCSI デバイスをデタッチして撤去。

という手順となるでしょう。

--
Novell Openenterprise Server を仮想化した状態で iSCSI と併せて運用すると、容易に、しかも慎重に計画したプラン通り移行すれば、わずか数分から数十分の停止時間で、古い革袋から新しい革袋にデータを移行させることができます。

-Keyword-
Novell Openenterprise Server ファイルサーバー移行、ファイルサーバーマイグレーション、Windows ダウンタイムの削減


問い合わせ
islandcenter.jp
[PR]
by islandcenter | 2014-10-05 13:41 | OES Linux | Trackback | Comments(0)

ここでは Novell Open Enterprise Server (OES11sp1) を使った Novell Samba の導入方法を説明します。

マニュアルはこちら
http://www.novell.com/documentation/oes11/

file_samba_cifs_lx.pdf に従い作業を行います。

こちらの方が詳しいかも
Installing and Configuring Samba on Open Enterprise Server 2

この文書も親切です
Troubleshooting Samba On Open Enterprise Server (OES)

-前提-
-
SUSE Linux 11 上に仮想ディスクを3台定義しました。一つは / パーティション、他は NSS ボリューム用と ext3 用です。

※ iManager と YaST2 の表示は英語にしています。iManager は初期設定画面で Japanese にローカライズすることができます。

- Novell Open Enterprise Server (OES11sp1) をインストールします。ここではいきなり全てをインストールせず、NTP などの設定を終わらせてから Novell OES コンポーネントを導入しました。 yast2 の Novell OES Configuration アイコンを実行し、 明示的に NSS と iManager を選択します。自動的に関連する eDirectory パッケージがインストールされます。

この時点では Novell Samba はインストールしていません。
a0056607_14551023.jpg


ユーザとグループを作りました。
a0056607_10501918.jpg


ユーザのホームディレクトリと、各グループの共有ディレクトリがあります。
a0056607_10521981.jpg


-インストール-

yast2 > OES Configuration

Novell Samba を選択すると LUM(Novell User Management) も同時にインストールされます。このコンポーネントは eDirectory と UNIX ユーザとを関連付けるコンポーネントです。

a0056607_110438.jpg

Accept > インストールが開始されます.


a0056607_1134137.jpg


Novell Samba を有効にするためには更に設定項目があります。 >  Novell Samba の行をクリックして Admin のパスワードをセットしてログイン。

デフォルトで "servername_W" が NetBios 名となります。他に Novell Samba のプロクシユーザの設定などの項目があります。サーバ名は NetBios の制限で最大15文字なので、はみ出した部分は削除する必要があります。
a0056607_132690.jpg


ここではそのまま Next > 前の画面に戻って Next, インストールが終わりました Finish.

Organization Unit (o=company) 直下に MyServerName-W.company オブジェクトが作成されます。このオブジェクトは任意の場所に作成できます。ポリシーにより、 O=company 直下に作らず、Ou=MyLocation.O=MyCompany などに作成することも検討します。
a0056607_11201757.jpg


もう一つ、サーバーコンテナに UNIX Workstation - MyServerName.system.tokyo.company オブジェクトが作成されます。

この時点で Client 側には MyServer_W の Samba サーバが表示されます。
a0056607_1132372.jpg


-ここからが難問、ユーザとパスワード-

LUM(Linux User Management) より利用する Linux ユーザを選択して追加します。
a0056607_11374458.jpg


ユーザを選択した後、ユーザが所属するグループを指定します。
ここでは新規に LinuxUsers というグループを作成していますが、既に存在する eDirectory のグループも選択することができます。
a0056607_11403998.jpg


Password > Password Policies > "Samba Default Password Policy" を確認し、
a0056607_11534066.jpg


このポリシーに適合させるユーザを指定します。
a0056607_11584090.jpg


このユニバーサルパスワードのポリシーは、「パスワードを忘れた時のリセット方法」「大文字小文字を区別する」「長さの制限」などさまざまな設定が行えます。
a0056607_1225718.jpg


例えば、グループを指定して「マル秘情報」にアクセスできるグループは厳しいパスワードを設定したり、一般的なオペレータであれば、3ヶ月に一度8文字以上のパスワードを設定するなどですね。

次に File Protocol > Samba より、サーバを選択肢、Samba のユーザを指定します。
a0056607_12810100.jpg

おっ、エラーが出てしまいました。

User_name_xxxx: Could not Samba enable the user for group, MyOes11-W-SambaUserGroup. Received an error when checking for a universal password. Error: Cannot continue because the user does not appear to have a universal password.

See help for possible causes.

と出てしまいました。

もう一度この文書で確認しましょう。この文書も親切です
Troubleshooting Samba On Open Enterprise Server (OES)

As an administrator you have the option of setting the password manually for individual users by going to Passwords and clicking on Set Universal Password, but it is not necessary. Once the policy has been assigned to a user or container, all the user(s) should have to do is to login though through NCP (example: Novell Client) or using LDAP (example: iManager) and it will automatically attempt to synchronize the eDirectory password to the Universal Password. If the Universal Password doesn't exist but the eDirectory password does exist, then they system will synchronize the two passwords to be the same as the eDirectory password. If the Universal Password does exist, but it doesn't match the eDirectory password or if the eDirectory password doesn't match the new policy assignment then the password will expire and the user will be prompted to enter in a new password.
Note: You will not be able to add any users to the Samba configuration until their Universal Password has been set.


ここに書かれていることを簡単に説明すると

- Administrator はユーザの Universal Password を明示的に設定できる。(初期値が必要)
- Universal Password が設定されていない場合、NCP か LDAP を使って変更(Novell Client で設定できる、逆に言えば Novell Client が必要)
- 設定されていない場合は eDirectory のパスワードと同期する。(これはこれで便利)
- Universal Password と eDirectory のパスワードが同期していない場合、お互いのポリシーが異なれば一致させることはできない。(非常に当たり前なこと、どんなシステムでも使えるパスワードポリシーを考慮すべきである)

と、こんなところです。

ということで、既に Novell Client でログインしたユーザを追加してみます。
a0056607_122189.jpg

無事 Samba ユーザとして登録できました。

ついでに Share タブで「共有フォルダ」を作ってみます。
a0056607_12261713.jpg

この「共有」は NSS ボリューム上にユーザからは Read Only で作成しました。従って Novell Samba で R/W の設定を行ってもユーザは書き込みができません。
a0056607_12312256.jpg

設定を変更した場合、 General Tab にある Restart リンクをクリックします。忘れやすいのでご注意ください。
a0056607_14295517.jpg


通常の Linux ファイルシステム上の Samba の共有も iManager から設定します。
a0056607_17161163.jpg


File Protocol > Samba > Share から NSS ボリュームに「共有」を設定した場合、 NSS で与えられたトラスティが適用されるため、[SRWCEFMA] のF権のないディレクトリは表示されません。
a0056607_13294921.jpg

表示されないのは Novell Samba 自体が表示を行わないからで、 /home を開いたときに「ズラーリ」と表示される各ユーザのホームディレクトリの参照のための余分なパケットロスもないということです。


-大変よくできました-

- パスワードの変更が容易である。
これは重要なことです。
a0056607_13392681.jpg

通常の samba であれば、 smbpasswd コマンドで定期的にパスワードを変更するよう「管理者は指導」できますが、強制はできません。何らかのUIを工夫している方もいらしゃるでしょう。パスワードの変更のルールは明文化できても強制させるためにはさまざまなテクニックが必要です。まして SSH で入ってコマンドで変更しろというのでは、まずユーザが自主的にパスワード管理を行うことはないと言って良いでしょう。

しかし、この機能は NCP 接続を要求された時に実施されることであって、Novell Samba が要求するところではないのが残念です。

-必要のないフォルダは見えなくてもよろしい
これも NSS ボリューム上に作成した Novell Samba の優れた点です。ユーザのアクセサビリティからも、見えても関係ないよというフォルダが見えないことは、余計な詮索もなく、非常に便利なことです。また、ディレクトリの一覧を取得する場合、CIFS の悪いマナーの一つである問い合わせのパケットが大幅に削減できます。

-右ボタンで共有設定
NCP で利用している場合、右ボタン > Novell 権限で容易に他人にアクセス権を設定できます。自分の作品を他人に「公開」するため、 chown や chmod などのコマンドを使う必要はありません。あくまでも NCP (Novell Client for Windows)の中での話しですが、NCP で設定した内容はそのまま Samba の利用者にも適用されます。

-ファイルの圧縮とシュレッディング
Novell Open Enterprise Server 上の NSS ボリュームには、ディスクのクォータ、ファイル圧縮、データシュレッディング(乱数での自動上書き)などの機能が備わっています。 ext3 などで作成したボリューム上でユーザの利用制限をかけたり、自動的に圧縮させるような機能は知りません。

-大変がっかりしました-

これは、Novell Samba の仕様というより CIFS と Windows の仕様そのものの問題でしょう。パスワードを変更するためには NCP (ポート 524) での接続が必要だということです。Novell Samba を使うことで eDirectory との連携、パスワード管理は容易になりますが、そもそも Samba のパスワードを管理するためのツールというもの自体が Windows にはありません。

ということで、多少の手間(と言っても難しいことではないのですが) Novell Client for Windows は必要なものです。しかし、 Novell Client for Windows を導入してしまえば、なぜそこまで Samba を使うのか、という理由が見つかりません。

考えられるケースとしては、通常は NCP 接続をしているユーザが、「持ち込みPC」を使って情報にアクセスできないこともない、というケースです。もちろんそれが許されるポリシーであることが前提です。

OES ファイルサーバーを Samba 主体で利用するべきではないと考えています。単純に「高価なだけの」Samba サーバーとなってしまいます。その「高性能さ」を生かしきることはできません。

もともと閉じた LAN 内での利用を前提とした CIFS と WAN を考慮した NCP (Novell Core Protocol) との違いもあり、CIFS での利用は限定的にすべきだと私は考えます。

--
システムはシンプルであるべきです。CIFS の効率の悪さは色々悪評が多く、WAN越しのアクセスが遅いとか、使い物にならないといった話はよく聞きます。仕方がないので高価なCIFSアクセラレータを導入してみたけど、100ユーザ程度でも全然効率は上がらず、諦めたというケースもよく聞きます。何しろ 「CIFS + 効率」で検索すると Cisco などの WAFS アプライアンス製品がずらりと紹介されるのもその証拠でしょうか。これらのアプライアンスも内部に故障しやすいキャッシュ用のHDDやSSDなどの「消耗品」を抱えている以上、「ファイルサーバー」そのものに近い存在です。サーバーの集約化を目的として逆にサーバーを増やしているのが、SIビジネスということです。

シンプルで使いやすいプロトコルを選ぶなら NCP (Port 524) を選ぶべきなのですが、残念ながら Windows やLinux では標準サポートされていません単純に Novell Client を導入し Port 524 の通信を行えば問題は解決できるのですが、どうもそういった動きはお客様にないようで残念です。


islandcenter.jp
[PR]
by islandcenter | 2013-09-19 08:00 | OES Linux | Trackback | Comments(0)

eDirectory の基本は 1990 年代に開発された NetWare 4x シリーズから基本的な構造、コンセプトは変わりません。この基本設計の優れた点が eDirectory 8.x に継承されています。

この巨大なディレクトリシステムが(おそらく世界最大の)フランス国税局が管理する4000万人とも言われる納税者のプロファイル管理に利用されています。

何をいまさらなのですが、eDirectory は Novell/NetIQ のID管理システムの根幹なので、そのメカニズムを「知ったかぶり」で Windows Active Directory と比較して説明します。

-パーティションとレプリカ-

eDirectory の最大の特徴がこのパーティションとレプリカの概念です。

単一の「ディレクトリツリー」空間は、ツリーのブランチ(O/OU:組織/部門オブジェクト)ごとに複数のパーティションデータベースに「分割」して連続した単一のツリー空間の一部を構築することができます。

Windows の Active Directory はこのように「単一の"ドメイン空間"」を「ドメインツリー」としてトラスティドされた連続空間として管理できるだけです。ドメインを「分割」することはできません。

eDirectory のパーティション化(分割)され、分散化されたデータベースは「レプリカ」と呼ばれます。

また、各 eDirectory サーバーは複数のレプリカデータベースを保持することができます。

a0056607_1552912.jpg


データベースはパーティション化して分割(レプリカ)を作成できる



Windows の単一の Active Directory サーバーは同じ「ドメインツリー」内部であっても複数のドメインデータベースを保持することができません。たとえ同一のドメインツリーであっても複数のドメインに所属することができないからですね。従って同じドメインツリーであってもユーザなどのオブジェクトを「移動」することはできません。「削除」と「再作成」が必要です。

各 eDirectory データベースは、パーティション化して細分化されます。極端な例かも知れませんが、各 OU (部門)オブジェクト単位でパーティション化して複数の複数拠点に配置した eDirectory サーバーに分割して同期コストとを削減させ、DR(耐障害性)を保つことができます。そのため、巨大なディレクトリであっても、少ないサーバー資源に有効に LDAP オブジェクトを分割配置することができます。

a0056607_15193840.jpg

少ないサーバーで耐障害性、冗長性が確保できる


パーティションのレプリカデータベースは一般に単一の Master レプリカと複数の Read Write (RW) レプリカによって構成されます。耐障害性と同期コストを考慮して、最低3台から、数台以内のサーバーにレプリカデータベースを持たせることが推奨されます。パフォーマンスを考慮しないとして、3台のサーバーで3拠点以上のパーティションを保持することができます。拠点数とサーバ数が増えれば、更にそれだけ少ないサーバーで細分化されたレプリカデータベースを分散配置できます。

一般には Master レプリカと RW レプリカは一般ユーザや管理者が行う同じ役割(ログイン認証、オブジェクトの新規追加、更新、削除)を実行します。 Master レプリカは、サーバーの追加や削除、レプリカデータベースの分割などのレプリカベースの操作を行うときの操作元となります。

Master レプリカが障害を起して取り除き、RWレプリカから Master に変更する必要がある場合、ndsrepair -P コマンド(NetWare では dsrepair) で "Designate this server as the new master replica"を「選択して実行」するだけです。

a0056607_15223971.jpg


ntdsutil ツールで難解なコマンドラインを駆使して「"FSMO"の切り替え」の複雑な操作を行う必要はありません。


-同期コスト-

eDirectory の特徴として、同期コストの低さがあります。

例えば LDAP の属性として cn=user : UID のようにオブジェクト毎に含まれる item/Attribute がありますが、eDirectory はこれらの Object の Item ごとにタイムスタンプが設定されており、オブジェクトの変更は変更されたオブジェクト内部の Item ごとに行われます。例えば、cn=myuser の電話番号を変更しても同期にかかるコストは「電話番号」という Item であり、 cn=myuser 全てのオブジェクトがコピーされるわけではありません。

a0056607_15162729.jpg

オブジェクトの同期は Object.item 単位で行われ同期コストを下げている


意外なことなのですが、ユーザなどのディレクトリのオブジェクトは一つあたり割と大きなサイズがあるものなのです。

例えば大量のオブジェクトのパスワードをリセットしても、eDirectory ではリセットされるのはパスワードの情報だけで、オブジェクト全てが同期されるわけではありません。最小の Item だけが限定されたレプリカリング内だけでリセットされるだけです。

一方で、 Windows の Active Directory の場合、「全オブジェクト」の情報がドメインDBを持つサーバ全体に同期しようとするため、「ログインできない」「アクセスできない」などのトラブルが大量のドメインコントローラに伝えられ、収束して同期が完全に完了するまで障害として残ります。

eDirectory ではこの「同期状態」を確認するための ndstrace というコマンドインターフェースがあり、「まだ同期中だな」というのが「見て解る」のですが、残念ながら Windows Active Directory ではこういう「今何してるの?」という確認に必要なツールがありません。(というか知らないのは私だけなのかもしれないけれど)

a0056607_152738100.jpg


つまり、Windows の Active Directory の管理者は「この操作が正しいかどうか」の確認を「待つのも仕事」「クレームを聞くのも仕事」として諦めて待つしかありません。

これらのディレクトリツリーの障害が発生した場合、ほとんどの場合、細分されたレプリカリング内での問題で、ツリー全体で発生することは非常にまれです。 Windows ドメインであれば、ドメイン全体の修復が必要となる場合があります。、

これらの同期情報のうち、「ログインした」などの情報は即時に同期されます。Immidiate Sync (即時同期)と呼ばれます。一方、郵便番号だとかの情報は即時に同期する必要がないため Slow Sync とか Heart Beat などと呼ばれ、一定時間に数台に分割されたレプリカリング内の提示情報としてまとめて定時同期(Heart Beat Sync)されます。

ここで重要なのは、他のディレクトリ製品でも同様に、時刻が一定のタイミングで同期しているということです。

eDirectory の言わば「最終手段」として行う作業は Decrea Epoch (エポックの宣言)です。この操作は、最終同期した時刻をレプリカリング内で強制的に時刻をリセットして同期する作業です。巨大なレプリカリング内では全てのサーバーに対してこの操作が受け付けられ、大量のパケットと同期コストがかかりますが、ディレクトリーツリーを細分化したレプリカで管理している場合は、その小さなレプリカリング内だけで実行されるため、規模にもよりますが、タイムスタンプのリセットと同期は数十秒から数秒以内で完了します。例えば10台のサーバーでeDirectory を保持していた内の3台のサーバーが管理するパーティションで Decrea Epoch を実施すると3台のサーバーだけで処理が完了します。また、パーティション自体がブランチごとに細分化されている場合、そのブランチ単位のレプリカで実施されるため、他の OU 単位には少ない影響で完了することができます。

Active Directory のように大量の「オブジェクト全体の強制リセットと同期」が発生しないため、少ない同期コストでオブジェクトの同期が完了します。


-ディレクトリサービスで重要な時刻同期-

Novell eDirectory は NetWare ベースでは NCP(TCPIP Port 524)あるいはipx を使った時刻同期を行っていましたが、Novell Open Enterprise Server 以降、Linux/Unix ベースのシステムでは一般的な NTP プロトコルを使います。標準的な NTP プロトコルは、時刻ずれが発生した場合、Step Mode という「時間寄せ」のプロセスで、数秒ごとから数分ごと、最終的にはデフォルトの10分ごと(600秒)の時間確認のプロセスに移行します。これを Slow Mode と言います。Slow モードはNTP の設定でデフォルトの600秒から、1時間とか24時間とかに自由に設定できます。

一方 Windows システムは w32tm プロセスで時刻同期を行います。このプロセスはデフォルトで8時間(!)ごとに時刻同期を確認し、大幅な同期エラーが発生すると、単に「エラー」を記録して同期は行えなかった事を報告するだけです。このパラメータを変更するためには Windows のレジストリの変更が必要です。Active Directory システムでは、大幅に時刻同期に問題が発生している事を確認するツールがないため、各ドメインコントローラを保持するサーバーに「リモートデスクトップ」ログインを行って、時刻を確認する必要があります。

eDirectory では ndsrepair -T コマンドをいくつかのサーバー上で実行するだけで、時刻同期に問題のあるサーバーを容易に特定することができます。

a0056607_15245151.jpg


-権利継承-

eDirectory の特徴として「権利継承(Inherit Right)」の概念があります。[root]管理者 cn=admin が全ての管理を行うのではなく、特定の OU(部門オブジェクト)レベルで管理者権限を与えることにより、この低いレベルでのサーバーの追加、削除、ユーザなどのオブジェクト管理を実施することができます。

a0056607_15343097.jpg

admintokyo ユーザはこの内部で自由にサーバやユーザを追加、削除できる。


-eDirectory の最大の欠点:コスト-

Windows サーバーを購入すると CAL が必要となります。同じように eDirectory を購入すると、ユーザごとにライセンスが必要となります。AD のように数百から数千ライセンス程度で十分な場合はCALは必要悪として受け入れるべきものですが、eDirectory のライセンスは利用者の桁違うため、ライセンス料金自体もそこそこかかります。

また Windows ドメインでは無償で「グループポリシーの管理」が行うことができますが、eDirectory では Novell ZENworks という追加製品でグループポリシーの管理を行います。ポリシー管理だけで Active Directory を巨大なツリーに実装すると、手痛い失敗をすることがあるということです。またポリシーの管理ベースがOU単位であると言う点も大きな問題を生み出します。

もっとも、「認証」だけに必要なライセンス料金は低価格で提供されているようですが、サーバーのサービスを受け入れる必要がある場合、 Windows の ユーザCAL のような形態のライセンス料金が発生します。NetWare 6.5 までは「同時接続ライセンス」として厳密に管理されていましたが、OES Linux に移行してからはペーパーライセンスに変わっています。が、実際に契約したライセンス以上のユーザ利用はライセンス違反となるため、「認証だけ」必要なライセンスが必要なのか、サーバーを利用するためのライセンスが必要なのかは厳密に計画して予算化する必要があります。もちろん、共有ファイル、プリントサーバーとして Windows を使わず、Novell Open Enterprise Server (OES) を使う場合は Windows のユーザ CAL は不要です。

また、公共機関などの認証システム向けに専用の特別に安価な認証のみのライセンスが用意されているため、この場合は特別な価格交渉を行うことができます。


-レプリカごとに異なるソルト-

Windows システムではユーザIDは SID という名前で管理されます。この SID はどのドメインコントローラでも共通です。これはユーザに限らず、オブジェクトそのものを「丸ごとコピー」するメカニズム上仕方の無いことです。

一方、eDirectory は UID ごとに異なるオブジェクトIDが保持されます。レプリカAでは cn=user1 が 11223344 なのに レプリカBでは 66778855 となるわけです。このオブジェクトIDは認証での solt (塩) となるわけなのですが、レプリカごとに異なるオブジェクトID、ソルトを認証に使うため、一つのセッションをハッキングされても、他のサーバーへのいわゆる「なりすまし」「セッションの乗っ取り」が難しくなります。

Active Directory ではオブジェクトのSIDが共通で、ドメインコントローラに「コピー」されるため、SIDという共通の「鍵」でなりすましが可能です。もっとも今はもう少し賢い方法を使っているのでしょうが。

eDirectory の同期プロセスに続く
[PR]
by islandcenter | 2013-09-13 14:44 | OES Linux | Trackback | Comments(0)

ここでは Novell Openenterprise Server 11 (OES11)を使っていた iSCSI デバイス上の NSSボリュームを他の OES11 システムに切り替える作業を行ってみました。

実は元サーバーがどうしても復旧できなくてLDAP も NSS も正常に動かなくなってしまいましたので....

-オリジナルサーバー-

元サーバーの iSCSI を解除します。

yast2 > iSCSI Initiator > Connect > "Logout"
a0056607_16424781.jpg


また、必ず使わないサーバーの iSCSI Initiator は onboot -> Manual に変更します
a0056607_1645013.jpg

ここだけ CUI 版 yast を使っているのはこれが後に敗因となったからです...

-移行先サーバー-
YaST(YaST2) Network Service iSCSI Initiator を設定します。 iSCSI ターゲットのアドレスを指定して Login
a0056607_16481276.jpg


Status が Fail > True になります。
a0056607_16511518.jpg


起動方法を Manual > Automatic に変更します。(onboot ではマウントできない場合がありました:敗因2)
a0056607_16535183.jpg


-iManagerよりマウント-

※ ここではブラウザを英語環境で使用しています。ブラウザ環境を日本語に変更しても全く問題なくメニューなどの表示は日本語になります。

Role > Storage > "Server"を Brows > Device
sda がマウントされていることを確認します。
a0056607_16564769.jpg

くれぐれも "Initialize" ボタンを押してしまわないように、「押しちゃった」人からのアドバイスです。もっとも確認ボタンは出ますが。

Volume > Mount を確認します。 "Not Mounted" なので "Mount" ボタンを押します。
a0056607_1711156.jpg


Mounted, Active になりました。
a0056607_1731489.jpg


ストレージプールを確認します。引き継がれています。
a0056607_1752154.jpg


クライアントから見てみます。
a0056607_1771175.jpg



トラスティも引き継がれています。
a0056607_1785090.jpg


サーバーが変わってしまったためログインスクリプトは書き換えが必要です。
a0056607_17104681.jpg


--
このテクニックは、筐体内に NSS ボリュームを仮想イメージとした場合にも応用が利くかも知れません。

islandcenter.jp

-Keyword-

Novell OES Openenterprise Server iSCSI Device Replace Volume another Server How to
[PR]
by islandcenter | 2013-04-16 17:18 | OES Linux | Trackback | Comments(0)

NDSTRACE の使い方

NDSTRACE の使い方

ndstrace は複雑なコマンドなので、よく利用方法を忘れてしまいます。LDAP Wiki にある
http://ldapwiki.willeke.com/wiki/Ndstrace から、意訳してみました。誤訳があったらご指摘ください。

※重要 ndstrace を putty などのターミナルソフトで実行する場合は必ず quit コマンドで終了させてください。 ndstrace -u ではアンロードできなくなくなる不具合があります。
ndstrace causes ndsd to hang when left running from a terminated putty session

[eDirectory メンテナンス・コマンド ndstrace]

ndstrace -サーバーを表示するユーティリティ、メッセージをデバッグします。


[パスとオプション]
/opt/novell/eDirectory/bin/ndstracendstrace[-l|-u|-c「command1......"|[version][-h];[thrd<スレッドID>][svty][接続 ]

内容

ndstraceユーティリティは、ノベル eDirectoryの内部動作と関係するメッセージを表示します。ndstraceユーティリティは多くのコマンドを使用します。また、情報量を操作するフィルタがあります。さらに、その中には特定の同期プロセスを始めるコマンド、およびサーバ上のあるeDirectoryパラメーターを変更するその他のものがあります。

ndstrace は2つのモード、UIモードおよびコマンドライン・モードにでロードできます。オプションなしでの ndstraceコマンドは、UIモードでロードします。アンロードするには quit コマンドで終了しす。UIモードは単一のセッションでのみロードできます。他のセッションから終了させる場合は -u オプションで終了させます。

※特に意識しない場合は # ndstrace でUIを起動し操作します。 UI を終了する際は quit するか、他のターミナルから -u オプションで終了します。ただし、リモート端末から、 -u 出来ない不具合があるバージョンがあるため、必ず quit するよう習慣付けてください。

a0056607_1575840.jpg


[オプション]

様々なndstraceオプションは下のようにリストされます:

-l コマンドライン・モードにおけるndstraceユーティリティをロードします。背景のファイルへの出力メッセージを転送することができます。
-u ndstraceユーティリティをアンロードします。
-cコマンド-ndstraceコマンドはセミコロン(;)によって区切られたアイテムを備えたリストとしてコマンドラインによって与えることができます。
-- バージョン-バージョン情報をプリントします。
-hは、サーバが聞いているインターフェースおよびポートを指定します。
-- コンフィグファイルしてください - nds.conf設定ファイルの位置を指定します。

thread ID

スレッドIDに基づいたトレースメッセージをフィルターします。例えば、スレッドID 35のためのフィルタリングを可能にするためには、次のようにします。

# dstrace thrd 35

スレッドIDに基づいて、フィルタリングを停止するには、次のようにします。

# dstrace thrd

[severity_level]

重要度レベルに基づいたトレースメッセージをフィルターします。重要度レベルはFATAL、WARN、ERR、INFOおよびDEBUGです。重要度レベルのフィルタリングを可能にするために例えば、FATAL、の場合

# dstrace svty fatal

重要度レベルに基づいての、フィルタリングを停止する場合

# dstrace svty

[Connection_ID]

接続IDに基づいたトレースメッセージをフィルターします。例えば、接続ID 21のためのフィルタリングを可能にするためには、下記を入力してください:

dstrace conn 21

接続IDに基づいて、フィルタリングを不能にするためには、下記を入力してください:

dstrace conn




[基礎的なコマンド]

※ ここでは基本的な UI インターフェースを使った ndstrace コマンドの使い方を説明します。


シンタックス

ndstrace: set ndstrace= [flag]

flag

ONはndstraceを可能にします、スクリーンをデバッグするが、フィルタをセットしないし、リセットしない。


OFFはndstraceを不能にします、スクリーンをデバッグするが、フィルタをリセットしない。


ALLはすべてを可能にします、トレースメッセージ・フィルタをデバッグします。バッファーはこのコマンドでつけられます。


DEBUGは、次のフィルタを可能にすることにより一般的なデバッグするメッセージのあらかじめ定められたセットをつけます:TAGS、FRAG、JNTR、SPKT、BEMU、INIT、LMBK、RECM、SCMA、SKLK、BLNK、INSP、MISC、PART、VEC


AGENTは、次のフィルタを可能にすることによりDSのエージェント関連のデバッグするメッセージのあらかじめ定められたセットをつけます:TAGS、JNTR、AREQ、BLNK、RSLVおよびTVEC。


NODEBUGはフィルタをすべて切ります。

[ FILTERS ]

シンタックス

ndstrace: set ndstrace=[+|-]<フィルタ>ndstrace[+|-]<フィルタ> [[+|-<フィルタ]>]....


フィルタ値

ABUF -受け取られているデータを含んでいる、インバウンド・あおうとバウンドのパケット・バッファを可能にする、あるいは eDirectoryリクエスト。
ALOC -可能にする、デバッグする、またメモリアロケーションの詳細を示すエラーメッセージ。
AREQ - 他のサーバあるいはクライアントからのインバウンドのリクエストに関する、ステータスおよびエラー・レポートを可能にします。
AUTH - 認証メッセージおよびエラー・レポートを可能にします。
BASE - レベルをデバッグする最小でエラーメッセージをデバッグします。
BLNK - リンクおよびインバウンドのオビチュアリ(削除通知)メッセージおよびエラー・レポートをバック可能にします。
CBUF - アウトバウンドのDSクライアント・リクエストを表示するためにエラーメッセージをデバッグします。
CHNG - 変更キャッシュ・メッセージを可能にします。
COLL - オブジェクトの最新版情報に関する(最新版が以前に受け取られた場合)、ステータスおよびエラー・レポートを可能にします。
CONN - サーバが接続しようとしているサーバに関する情報を示し、サーバを接続させていないかもしれないエラーおよびタイムアウトを見るためのエラーメッセージをデバッグします。
DNS - eDirectoryを統合されたDNSサーバー・プロセスに関するエラーメッセージをデバッグします。
DRLK - 各サーバに分配された参照リンク・メッセージを-可能にします。
DVRS - eDirectoryが影響を与えているかもしれないDirXMLドライバ特殊分野を示すためにエラーメッセージをデバッグします。
DXML - DirXMLのイベントの詳細を示すエラーメッセージ。
FRAG - NCPに分類されたメッセージへeDirectoryメッセージを壊そうとする NCP* fraggerからのメッセージを表示します。
IN - インバウンドのリクエストおよびプロセスに関する、ステータス・メッセージおよびエラー・レポートを表示します。
INIT -可能にする、eDirectoryの初期化と関係するエラーメッセージをデバッグします。
INSP - 出所サーバのローカル・データベース中のオブジェクトの完全に関する、ステータス・メッセージおよびエラー・レポートを可能にします。

重要:このフラグの使用は、ソースサーバのディスク記憶システム、メモリおよびプロセッサーに関するリクエストを大量に使用します。問題なければフラグをイネーブルにして放置しないこと。

JNTR - 次のバックグラウンド・プロセスに関する、ステータス・メッセージおよびエラー・レポートを可能にします:管理人、複製同期およびフラット・クリーナ。
LDAP - LDAPサーバ・メッセージを可能にします。

ex) LDAP のデバックには ndstrace: set ndstrace=+LDAP を使います。
a0056607_1593123.jpg


※ LDAP のデバックには LDAP サーバーオブジェクトの Tracing の項目のいくつかをチェックします。
a0056607_15112178.jpg


LMBR - リンバー(準備)ステータス・メッセージおよびエラー・レポートを可能にします。
LOCK - 出所サーバのローカル・データベース・ロックの使用および操作に関する、ステータス・メッセージおよびエラー・レポートを可能にします。
LOST - 失われたエントリー・メッセージを可能にします。
MISC - eDirectoryの中の異なる出所からの様々なメッセージおよびエラー。
MOVE - 動きパーティションか動きサブ木オペレーションからのメッセージを可能にします。
NCPE -可能にする、NCPレベルにリクエストを受け取るサーバを示すためにエラーメッセージをデバッグします。
NMON -可能にする、デバッグする、またiMonitorに関するエラーメッセージ。
OBIT - オビチュアリ(削除通知)プロセスからのメッセージを可能にします。
PART - バックグラウンド・プロセス、およびリクエスト処理からのパーティション・オペレーションに関する、ステータス・メッセージおよびエラー・レポートを可能にします。
PURG - パージ工程に関するエラーメッセージをデバッグします。
RECM - ソースサーバのデータベースの操作に関する、ステータス・メッセージおよびエラー・レポートを可能にします。
RSLV - 名前解決リクエストの処理に関する、ステータス・メッセージおよびエラー・レポートを可能にします。
SADV - サービスロケーションプロトコル(SLP)を備えた、ツリー名およびパーティションの登録用エラーメッセージをデバッグします。
SCMA - スキーマ(DB構造)同期プロセスに関する、ステータス・メッセージおよびエラー・レポートを可能にします。
SCMD - スキーマ(DB構造)関連のオペレーションの詳細を示すエラーメッセージ。それはインバウンド・アウトバウンドの同期について詳細を示します。
SKLK - 複製同期プロセスに関する、ステータス・メッセージおよびエラー・レポートを可能にします。
SPKT - eDirectory NCPサーバ・レベル情報に関するエラーメッセージをデバッグします。
STRM - ストリームシンタックスを備えた属性の処理に関する、ステータス・メッセージおよびエラー・レポートを可能にします。
SYDL - 応答プロセスの間に、より多くの詳細を示すためにエラーメッセージをデバッグします。
SYNC - インバウンドの同期交通(このサーバによって受け取られているもの)のエラーメッセージをデバッグします。
TAGS - トレースプロセスによる各ライン出力に関する出来事を生成したトレースオプションを識別するタグ・ストリングを可能にします。
THRD - いずれかのバックグラウンド・プロセス(スレッド)がいつ始まるか示すエラーメッセージおよび終了をデバッグします。
TIME - 同期プロセスの間に使用される過渡的なベクトルに関するエラーメッセージをデバッグします。
TVEC - 次の属性に関係する様々なメッセージを可能にします :同期、レプリカ、また過渡的なベクトル。
VCLN - 他のサーバとの接続の確立か削除に関する、ステータス・メッセージおよびエラー・レポートを可能にします。
WANM - ほとんど接続層で、青白い商品輸送責任者によって記録されたメッセージを可能にします。



[PROCESSES - 実行コマンド]

シンタックス

ndstrace: set ndstrace=*<フラグ>


フラグ値

A - ソースサーバ上のアドレス・キャッシュをリセットします。
AD - ソースサーバ上のアドレス・キャッシュを不能にします。
AE - ソースサーバ上のアドレス・キャッシュを可能にします。
B - 1秒でソースサーバ上の実行を始めるためにバック・リンク・プロセスを予定します。
CT - ソースサーバの外国行きの接続表およびテーブル用の現在の統計資料を表示します。これらの統計は、他のサーバあるいはクライアントからソースサーバまでの着信接続に関する情報を与えません。
CTD - テーブルのためのカンマ区切りのフォーマット、ソースサーバの外国行きの接続表および現在の統計資料でのディスプレイ。これらの統計は、他のサーバあるいはクライアントからソースサーバまでの着信接続に関する情報を与えません。
D - ソースサーバーから指定された地方のエントリーIDを撤去する、オブジェクト・リストをすべて送ります。エントリーIDは、サーバーのローカル・データベースに特有の分割根オブジェクトを指定するに違いありません。このコマンドは通常使用されます、いつ(だけ)Send、アップデートはすべて際限なくつらく、サーバーがアクセス不能であるので完成することができません。
E - ソースサーバーのエントリーキャッシュを再初期化します。
F - 5秒でソースサーバーの実行を始めるためにフラット・クリーナ・プロセス(それはジャニター(junitor管理)プロセスの一部である)を予定します。
G - 指定されたルートパーティションIDの変更貯蔵所を再建します。
H - ソースサーバー上で実行を直ちに始めるために複製同期(ハートビート-定期更新)プロセスを予定します。
HR - インメモリの最後の送られたベクトルをクリアーします。
I -指定された地方のエントリーIDをソースサーバーに加える、オブジェクト・リストをすべて送ります。エントリーIDは、サーバーのローカル・データベースに特有の分割根オブジェクトを指定するに違いありません。複製同期工程監査、Send、すべてのオブジェクト・リスト。分割の根オブジェクトのエントリーIDがリストに載っている場合、eDirectoryは属性までのシンクロナイズされたものの値にかかわらず、分割でのオブジェクトおよび属性をすべて同期させます。
J - ソースサーバーの実行を始めるためにパージ工程(それは複製同期プロセスの一部である)を予定します。
L - 5秒でソースサーバーの実行を始めるためにリンバー(準備)プロセスを予定します。
M<バイト-> - ソースサーバーのndstrace.logファイルによって使用される最大のファイル・サイズを変更します。コマンドは、debugファイルの状態にかかわらず使用することができます。指定された<バイト>は10000バイトと100MBの間の値です。指定された値が指定範囲より高いかより低い場合、変更は生じません。
P - eDirectory調整可能なパラメーターの現在値を表示します。
R - ndstrace.logファイルを0バイトにリセットします。
S - 3秒でソースサーバーの実行を始めるためにeDirectory複製同期プロセスを予定します。既に同期される予定である複製だけが同期されるでしょう。

ex) 強制同期プロセスを実行します。 ndstrace: set ndstrace=*S
a0056607_15223947.jpg


SS - ソースサーバー上で直ちに始める、スキーマ(DB構造)同期プロセスを予定します。最後の24時間で成功裡に同期されていないターゲット・サーバだけが同期されるでしょう。
SSA - それらが最後の24時間で同期されたとしても、直ちに始めるスキーマ(DB構造)同期プロセスおよびすべてのターゲット・サーバを備えた強制スキーマ(DB構造)同期を予定します。
SSD - ソースサーバのターゲット・スキーマ(DB構造)同期リストをリセットします。このリストは、ソースサーバがスキーマ(DB構造)同期プロセスの間にどのサーバを同期しなければならないか識別します。どんな複製も保持しないサーバは、そのサーバ・オブジェクトを備えた複製を含んでいるサーバの目標リストに含められるリクエストを送信します。
SSL - ターゲット・サーバのスキーマ(DB構造)同期リストをプリントします。
ST - ソースサーバにバックグラウンド・プロセス用の状況情報を表示します。
STX - ソースサーバにバック・リンク・プロセス(外部参照)用の状況情報を表示します。
STS - ソースサーバにスキーマ(DB構造)同期プロセス用の状況情報を表示します。
STO - ソースサーバにバック・リンク・プロセス(オビチュアリ(削除通知))用の状況情報を表示します。
STL - ソースサーバにリンバー(準備)プロセス用の状況情報を表示します。
U - コマンドがエントリーIDを含んでいない場合、ラベルが以前に付けられたあらゆるサーバのステータスを変更します。コマンドが地方のエントリーIDを含んでいる場合、指定されたサーバのステータスを変更します。エントリーIDはソースサーバのデータベースに特有で、サーバを表わすオブジェクトを指します。
Z - 現在予定されたタスクを表示します。


[チューニング]

シンタックス

ndstrace: set ndstrace=! flag value

チューニング・フラグ

B - バック・リンク・プロセスのために、数分で、間隔をセットします。デフォルト間隔は1500分(25時間)です。範囲は2~10080分(168時間)です。
D - インバウンド・アウトバウンドの同期間隔を分の指定された数にセットします。デフォルト間隔は24分です。範囲は2~10080分(168時間)です。
DI - インバウンドの同期間隔を分の指定された数にセットします。デフォルト間隔は24分です。範囲は2~10080分(168時間)です。
DO - アウトバウンドの同期間隔を分の指定された数にセットします。デフォルト間隔は24分です。範囲は2~10080分(168時間)です。
E - 実行を始めるためにインバウンド・アウトバウンドの同期プロセスを予定します。
EI - 実行を始めるためにインバウンドの同期プロセスを予定します。
EO - 実行を始めるためにアウトバウンドの同期プロセスを予定します。
F - フラット・クリーナ・プロセスのために、数分で、間隔をセットします。デフォルト間隔は240分(4時間)です。範囲は2~10080分(168時間)です。
H - ハートビート(定期更新)プロセスのために、数分で、間隔をセットします。デフォルト間隔は30分です。範囲は2~1440分(24時間)です。

ex) ndstrace: set ndstrace=!H ハートビートプロセスを強制実行します。
a0056607_1540487.jpg


I - ハートビート(定期更新)プロセスのために、数分で、間隔をセットします。デフォルト間隔は30分です。範囲は2~1440分(24時間)です。
J - ジャニター(junitor管理)プロセスのために、数分で、間隔をセットします。デフォルト間隔は2分です。範囲は1~10080分(168時間)です。
M - eDirectoryによって使用される最大のメモリを報告します。
N[0] - 名前形式をセットします:0(0)がhexのみを指定します。また、1(1)は十分なドット形式を指定します。
SI - インバウンドのスキーマ(DB構造)同期プロセスのために、数分で、間隔をセットします。デフォルト間隔は24分です。範囲は2~10080分(168時間)です。
SO - アウトバウンドのスキーマ(DB構造)同期プロセスのために、数分で、間隔をセットします。デフォルト間隔は24分です。範囲は2~10080分(168時間)です。
SI0 - 分の指定された数のインバウンドのスキーマ(DB構造)同期プロセスを不能にします。デフォルト間隔は24分です。範囲は2~10080分(168時間)です。
SO0 - 分の指定された数のアウトバウンドのスキーマ(DB構造)同期プロセスを不能にします。デフォルト間隔は24分です。範囲は2~10080分(168時間)です。
T - サーバのUP状態のチェックのために、数分で、間隔をセットします。デフォルト間隔は30分です。範囲は1~720分(12時間)です。
V -制限されたeDirectoryバージョンをリストします。バージョンがリストされない場合、制限はありません。バージョンはそれぞれコンマによって区切られます。



[ログ(補足)]

ログのリセット
ndstrace : set ndstrace=*R

ログの開始
ndstrace: ndstrace file on

ログの終了
ndstrace: ndstrace file off

ログの位置
/var/opt/novell/eDirectory/log/ndstrace.log

-Keyword-

Novell eDirectory 修復 管理 コマンド ndstrace ndsrepair

islandcenter.jp
[PR]
by islandcenter | 2012-10-10 15:04 | OES Linux | Trackback | Comments(0)

Novell eDirectory 8.6/8.7 UNIX NDSREPAIR GuideおよびWiki LDAPNdsrepairより抜粋、意訳です。


ローカルデータベースの修復

# ndsrepair -R

※一番よく使います。

標準修復(無人修復) unattended repair

# ndsrepair -U

※ unattended と言え、あまり不在状態では使いません。データベースをロックするため完全修復する際に使います。

[サンプル]
oes11x1:~ # ndsrepair -U

[1] Instance at /etc/opt/novell/eDirectory/conf/nds.conf: oes11x1.OU=system.OU=tokyo.O=ace.ACE-TREE
Repair utility for Novell eDirectory 8.8 - 8.8 SP6 v20604.10
DS Version 20605.00 Tree name: ACE-TREE
Server name: .oes11x1.system.tokyo.ace

Size of /var/opt/novell/eDirectory/log/ndsrepair.log = 40032 bytes.

Preparing Log File "/var/opt/novell/eDirectory/log/ndsrepair.log"
Please Wait...
Repairing Directory On Server oes11x1
Start: Friday, October 05, 2012 10:58:03 Local Time
** All disk amounts are approximations **
Disk space currently available: 7618 MB
->DSRepair may need to use: 32 MB
->Disk space remaining after operation: 7618 MB

Current transaction ID is 380537 (0x5ce79). Allowed limit of transaction is 4294959104 (0xffffe000)
Waiting for Directory Services to release the local database files
Please Wait...
DS Files Are Locked
Repairing Directory On Server
Action
Physical Check
Repairing Directory On Server
Action
Creating Temporary Files
Repairing Directory On Server
Action
Repair Trees - Scan Values
Repair Trees - Scanning Values (0)
Repair Trees - Scanning Values (12)
Repair Trees - Scanning Values (34)
Repair Trees - Scanning Values (187)
Repair Trees - Scanning Values (202)
Repair Trees - Scanning Values (225)
Repair Trees - Scanning Values (235)
Repair Trees - Scanning Values (735)
Repair Trees - Scanning Values (1235)
Repair Trees - Scanning Values (1660)
Repair Trees - Scanning Values (1813)
Repair Trees - Scanning Values (1834)
Repair Trees - Scanning Values (1861)
Repair Trees - Scanning Values (1906)
Repair Trees - Scanning Values (1908)
Repair Trees - Scanning Values (1911)
Repair Trees - Scanning Values (1914)
Repair Trees - Scanning Values (2414)
Repair Trees - Scanning Values (2506)
Repair Trees - Scanning Values (3006)
Repair Trees - Scanning Values (3122)
Repair Trees - Scanning Values (3128)
Repair Trees - Scanning Values (3129)
Repair Trees - Scanning Values (3130)
Action
Repair Trees - Sorting Values
Action
Repair Trees - Scan Entries
Repair Trees - Scanning Entries (0)
Repair Trees - Scanning Entries (999)
Action
Repair Trees - Sorting Entries
Action
Repair Trees - Check Values
Repair Trees - Check Entries
Total Objects in Database: 2799
Total Objects in Schema : 1370
Total External References: 1
Total Objects in Replicas: 1425
Repairing Directory On Server
Action
Schema Check
Repairing objects in a replica
Start: Friday, October 05, 2012 10:58:07 Local Time

Total objects in partition - T=ACE-TREE : 1425
Repairing objects - done(1000)
Repairing objects - done(1425)

Total Objects = 1425, UNKNOWN class objects = 0, Total Values = 20714
[Pseudo Server]

Total Objects = 1, UNKNOWN class objects = 0, Total Values = 62
Repairing Directory On Server
Action
Temporary DIB set replacing NDS working DIB set.
Unlocking local database files
Please Wait...
Checking stream syntax files
Repair process completed, total errors found = 0
Repairing Server Network Addresses
Start: Friday, October 05, 2012 10:58:29 Local Time
****************************************************************
This operation searches IPX, SLP, and DNS tables, if
available, to validate network address attributes of
NCP_SERVERS, and the referrals on replica objects.
If the information on DNS/DHCP tables or the /etc/hosts file is
incorrect, then we can neither guarantee proper validation of network
addresses, nor replica referral updates. This is particularly true
if the system uses unregistered DHCP addresses or the information
in the HOSTS file is incorrect or outdated
****************************************************************


Checking server: .oes11sp1x1.system.tokyo.ace
ERROR: Adding a Network Address Property :
Address Type = TCP, data[6] = 192.168.1.227:524
Address Type = UDP, data[6] = 192.168.1.227:524
Checking server address in Replica ID : 4, .[Root].
Address Type = TCP, data[6] = 192.168.1.229:524
Address Type = UDP, data[6] = 192.168.1.229:524
The Replica Property for this server has been updated
ERROR: Could not connect. Error : -626

Checking server: .oes11x2.system.tokyo.ace
Address Type = TCP, data[6] = 192.168.1.228:524
Address Type = UDP, data[6] = 192.168.1.228:524
Checking server address in Replica ID : 2, .[Root].

Checking server: .oes11x1.system.tokyo.ace
Checking server address in Replica ID : 1, .[Root].
Repairing replica ring
Start: Friday, October 05, 2012 10:58:50 Local Time

Replica Ring for replica: .[Root].
Remote server's local ID: 0000805c
Remote server's replica root ID: 00008058
Remote server name is: .oes11x1.system.tokyo.ace
OK - Authenticated to server
Remote server's local ID: 00008081
Remote server's replica root ID: 00008040
Remote server name is: .oes11x2.system.tokyo.ace
OK - Authenticated to server
Remote server's local ID: 000085fc
Remote server's replica root ID: 0000805c
Remote server name is: .oes11sp1x1.system.tokyo.ace
ERROR: Could not connect to server by name, Error: -626
The server's object is in local replica: T=ACE-TREE
Finish: Friday, October 05, 2012 10:58:56 Local Time
Total repair time: 0:00:53
Total errors: 3
NDSRepair process completed.
oes11x1:~ #


パーティションの修復
# ndsrepair -P

オプション

1. Repair all replicas
2. Repair selected replica
3. Schedule immediate synchronization
4. Cancel partition operation
5. Designate this server as the new master replica
6. Report Synchronization status of all servers
7. Synchronize the replica on all servers
8. Repair Ring, all replicas
9. Repair Ring, selected replica
10. View Replica Ring
11. View entire partition name
12. Return to Replica List


[サンプル]
oes11x1:~ # ndsrepair -P

[1] Instance at /etc/opt/novell/eDirectory/conf/nds.conf: oes11x1.OU=system.OU=tokyo.O=ace.ACE-TREE
Repair utility for Novell eDirectory 8.8 - 8.8 SP6 v20604.10
DS Version 20605.00 Tree name: ACE-TREE
Server name: .oes11x1.system.tokyo.ace

Size of /var/opt/novell/eDirectory/log/ndsrepair.log = 40032 bytes.

This list shows information for each replica stored on this server. Select a replica to display an options menu.
Finding all replicas on this server
Please Wait...
Total number of replicas = 1

PARTITION NAME REPLICA TYPE REPLICA STATE
(1).[Root]. Master On

Enter 'q' to escape the operation.
Enter a replica number(1-1)?1 <--- パーティションの選択

REPLICA OPTIONS
1. Repair all replicas
2. Repair selected replica
3. Schedule immediate synchronization
4. Cancel partition operation
5. Designate this server as the new master replica
6. Report Synchronization status of all servers
7. Synchronize the replica on all servers
8. Repair Ring, all replicas
9. Repair Ring, selected replica
10. View Replica Ring
11. View entire partition name
12. Return to Replica List


Enter 'q' to escape the operation.
Enter a replica option(1-12)?q <--- オプションを選ぶか quit

Total errors: 0
NDSRepair process completed.
oes11x1:~ #


共通する ndsrepair のスイッチ

-R -ローカル・データベースを修理する
-A no ndsrepair.logファイルリセットする
-l yes ndsrepair 中 eDirectoryデータベースをロックする。
-d 全データベースを再構築する。
-t ツリー構造チェックを行なう。
-i eDirectoryデータベース構造およびインデックスをチェックする。
-r 全てのローカルレプリカを修復する
-v ストリーム・ファイルを確認する
-c ローカル参照をチェックする

オビチュアリ(Obituaries)をチェックする

ndsrepairを使用して、NDSオビチュアリステータスを調べることができます:
ndsrepair -C -Ad -A

注)オビチュアリ(Obituaries)とは直訳すると「死亡広告」、つまり「削除されたオブジェクト通知」の意味です。

[サンプル]
oes11x1:~ # ndsrepair -C -Ad -A

[1] Instance at /etc/opt/novell/eDirectory/conf/nds.conf: oes11x1.OU=system.OU=tokyo.O=ace.ACE-TREE
Repair utility for Novell eDirectory 8.8 - 8.8 SP6 v20604.10
DS Version 20605.00 Tree name: ACE-TREE
Server name: .oes11x1.system.tokyo.ace

Size of /var/opt/novell/eDirectory/log/ndsrepair.log = 38202 bytes.

Preparing Log File "/var/opt/novell/eDirectory/log/ndsrepair.log"
Please Wait...
External Reference Check
External Reference Check
Start: Friday, October 05, 2012 09:52:46 Local Time

Checked 0 external references
Found: 0 total obituaries in this DIB,
0 Unprocessed obits, 0 Purgeable obits,
0 OK_To_Purge obits, 0 Notified obits
Total errors: 0
NDSRepair process completed.
oes11x1:~ #


同期状態とVersionsのチェック
# ndsrepair -E

[サンプル]

oes11x1:~ # ndsrepair -E

[1] Instance at /etc/opt/novell/eDirectory/conf/nds.conf: oes11x1.OU=system.OU=tokyo.O=ace.ACE-TREE
Repair utility for Novell eDirectory 8.8 - 8.8 SP6 v20604.10
DS Version 20605.00 Tree name: ACE-TREE
Server name: .oes11x1.system.tokyo.ace

Size of /var/opt/novell/eDirectory/log/ndsrepair.log = 38590 bytes.

Preparing Log File "/var/opt/novell/eDirectory/log/ndsrepair.log"
Please Wait...
Collecting replica synchronization status
Start: Friday, October 05, 2012 10:15:48 Local Time
Retrieve replica status

Partition: .[Root].
Replica on server: .oes11sp1x1.system.tokyo.ace
Replica: .oes11sp1x1.system.tokyo.ace 10-05-2012 10:06:50
Replica on server: .oes11x2.system.tokyo.ace
Replica: .oes11x2.system.tokyo.ace 10-05-2012 10:06:21
Replica on server: .oes11x1.system.tokyo.ace
Replica: .oes11x1.system.tokyo.ace 10-05-2012 10:06:20
All servers synchronized up to time: 10-05-2012 10:06:20
Finish: Friday, October 05, 2012 10:15:48 Local Time

Total errors: 0
NDSRepair process completed.
oes11x1:~ #


時刻同期およびすべてのサーバーバージョンのチェック

# ndsrepair -T

[サンプル]
oes11x1:~ # ndsrepair -T

[1] Instance at /etc/opt/novell/eDirectory/conf/nds.conf: oes11x1.OU=system.OU=tokyo.O=ace.ACE-TREE
Repair utility for Novell eDirectory 8.8 - 8.8 SP6 v20604.10
DS Version 20605.00 Tree name: ACE-TREE
Server name: .oes11x1.system.tokyo.ace

Size of /var/opt/novell/eDirectory/log/ndsrepair.log = 39154 bytes.

Building server list
Please Wait...
Preparing Log File "/var/opt/novell/eDirectory/log/ndsrepair.log"
Please Wait...
Collecting time synchronization and server status
Time synchronization and server status information
Start: Friday, October 05, 2012 10:17:19 Local Time

---------------------------+---------+---------+-----------+--------+-------
DS Replica Time Time is Time
Server name Version Depth Source in sync +/-
---------------------------+---------+---------+-----------+--------+-------
Processing server: .oes11sp1x1.system.tokyo.ace
.oes11sp1x1.system.tok... 20702.02 0 Non-NetWare Yes 0
Processing server: .oes11x2.system.tokyo.ace
.oes11x2.system.tokyo.ace 20605.00 0 Non-NetWare Yes 0
Processing server: .oes11x1.system.tokyo.ace
.oes11x1.system.tokyo.ace 20605.00 0 Non-NetWare Yes 0
---------------------------+---------+---------+-----------+--------+-------
Total errors: 0
NDSRepair process completed.
oes11x1:~ #



単一オブジェクトの修復

# ndsrepair -J[entry_id]

他のスイッチ

-R -Ad -Xk3 目的:サーバーから外部参照(External Reference)をすべて取り除きます。
-R -Ad -Xk2 サーバーからのすべてのレプリカの削除 - 要注意
-R -Ad -OT -タイムスタンプにしたがって、オビチュアリの再削除
-S -Ad いくつかの拡張オプションがあります。操作には[root]権限のIDとパスワードが必要です。

1. Request schema from Master Server(スキーマがコピーされない場合、マスタからスキーマを取得します)
2. Reset local schema
3. Post Netware 5 Schema Update
4. Optional Schema Enchancements
5. Import schema from Tree (他のツリーからのスキーマのインポート)
6. Declare a new epoch (エポックの宣言 - 時刻同期に失敗したときに使用します)


[サンプル]

oes11x1:~ # ndsrepair -S -Ad

[1] Instance at /etc/opt/novell/eDirectory/conf/nds.conf: oes11x1.OU=system.OU=tokyo.O=ace.ACE-TREE
Repair utility for Novell eDirectory 8.8 - 8.8 SP6 v20604.10
DS Version 20605.00 Tree name: ACE-TREE
Server name: .oes11x1.system.tokyo.ace

Size of /var/opt/novell/eDirectory/log/ndsrepair.log = 40032 bytes.

Administrator name: .admin.ace
Password:******
Logging In To Server
Please Wait...

GLOBAL SCHEMA OPERATIONS
1. Request schema from Master Server
2. Reset local schema
3. Post Netware 5 Schema Update
4. Optional Schema Enchancements
5. Import schema from Tree
6. Declare a new epoch


Enter 'q' to escape the operation.
Enter a schema option(1-6)?q <--- 数字を選ぶかquit

Total errors: 0
NDSRepair process completed.
oes11x1:~ #


-Keyword-

Novell Open Enterprise Server OES Linux eDirectry ndsrepair dsrepair

islandcenter.jp
[PR]
by islandcenter | 2012-10-05 11:06 | OES Linux | Trackback | Comments(0)