カテゴリ:OES Linux( 63 )

Open Enterprise Server 2015 OES2015sp1 で iSCSI NASのNSSマウント

OES 2015sp1 の既存ツリーへのインストール の続き


ここでは SLES11sp4 に導入された OES2015sp1 に iSCSI デバイスを NSS ボリュームを作成する手順を説明します。
なお、ここで使った iSCSI ターゲット NAS はゴミ箱から拾ってきたような qnap TS-110 NAS です。そこそこ使いやすいのですが、古さが露呈して、性能は想像の通りですが、こういった手順を確認するにはちょうどいいモノなので今でも愛用しています。

- iSCSI マウント -

iSCSIイニシエーター で iSCSIターゲットに作成された LUN をマウントします。

# yast2

> network Service > SCSI Initiator

Service Start > "When Booting"

a0056607_18001469.jpg

”Discovered Target ”

> Discovery から IP Address もしくは DNS 名でスキャン

a0056607_18011526.jpg


見つけた、作成済の iSCSI ターゲットを選び ”Login”

a0056607_18020605.jpg


Start up > ON Boot か Automatic にトグル(Automaticが良いみたい)

a0056607_18023065.jpg

Discovery Summary >Connected : "True" になっていることを確認

a0056607_18024906.jpg


iSCSI Initiator > Connected Target > Sutartup が Onboot に(Automatic が良いみたい)

a0056607_18030685.jpg

yast > System > Partitioner で NAS が /dev/sda デバイスとして認識されていることを確認

a0056607_18034195.jpg


iManager (http://server-ip/nps)

から Storage > Device を選び、サーバーをブラウズして、”sda” が出てきたら、まず ”Initialize Disk”(当たり前ですが初期化されます)

a0056607_18040231.jpg


Storage > Pool メニューから "New" Pool" を作成、アクティブ化します。

a0056607_18043434.jpg


Storage > Volume > "New" ボリュームを作成して、マウント。オプションとして、ファイル圧縮、ディレクトリ容量制限、ボリューム容量制限、Salvage などをチェック。

a0056607_18050427.jpg

a0056607_18055342.jpg


マウントされました。

a0056607_18053111.jpg

実際にボリュームにアクセスできるかか確認します。

a0056607_18061237.jpg

NSSプール、NSSボリュームが作成されると、 eDirectory オブジェクトに server_name_POOLーNAME_POOLserver_name_VOLname オブジェクトが作成されます。時々 server_name_SYS が作られない場合がありますが、動作には支障ないのですが、気味が悪いので、 Create Object で作成しても問題ありませんでした。

a0056607_18063335.jpg

ちなみに SYS: ボリュームは /usr/novell の下に LOGIN と PUBLIC のみ作成されます。

oes2015x1:~ # ls /usr/novell/sys
._NETWARE LOGIN PUBLIC
oes2015x1:~ #

もし Native NetWare から移行した場合、 GroupWise で ConsoleOne を使いたいとか nwadminを使いたいとか、public 以下は必要最低限のものしかないため、バックアップを取って Native NetWare のものからコピーして移植すると良いでしょう。動かないことはないのですが、最新の OES Client では ConsoleOne はサポート外なのでご了承ください。
もっとも、Native NetWare にある xxxx.EXE は 16 ビット版のものが多いし OES Linux は ipx をサポートしないので、 Windows 7/8 以降では動きませんが、中には未だ Windows XP を使っているケースもありますので、一応、覚えておいて損はありません。








[PR]
by islandcenter | 2017-11-14 18:08 | OES Linux | Trackback | Comments(0)

OES 2015sp1 の既存ツリーへのインストール

OES(Microfocus Open Enterprise Server) OES2015sp1 は SUSE Linux Enterprise Server 11 SP4 をベースとした、アドオン製品です。SLES の基本バージョンと、OES spX のバージョンが適合しないと、いろいろややこしい問題が起こるので、 http://download.novell.com/index.jsp のサイトからは、SLES11sp4, SLES11sp4+add-on, Add-on のみの3種類の ISO がありますが、この3つともダウンロードして、確保しておくことをお勧めします。

ここでは、まず SLES11sp4 をインストールして、その後、Add-on プロダクトとして OES を導入してみました。なれれば、SLES をインストールしながら、Add-on を導入しても構いませんが、ベースのOSに Add-On をインストールして失敗すると、最初からやり直しになるので、最初にベースOSを入れて、追加で Add-on をインストールする方法をご提案します。

SLESのバージョンミスを避けるため SLES11sp4 + Add-on の DVD イメージから、SLES11のインストールをするのが無難なようです。

- SLES11 SP4 のインストール -

SLES11sp4+add-on DVD(ISO)を使って、OESのアドオンを追加せず、SLES のみインストールします。 詳細はここでは説明しません。古い内容ですが詳細は

SUSE Enterprise Server 11 のインストール

をご参考ください。ポイントとしては

- 導入するホストのネーム情報を DNS サーバーに登録しておくこと
- 時刻同期をしっかり設定すること、時刻同期は eDirectory には必須の機能なので、プライマリ側と同じ設定にすると良いでしょう。
- ホスト名、固定IPを設定すること、特にホスト名はのちに変更できないので要注意です。
- ルートパーティションは最低6Gあれば十分ですが、余裕をもって12G程度用意します。 eDirectory の DB は /opt/novell/....... の下につくられるので、ディレクトリレプリカが大きな場合、ルートパーティションが圧迫されます。

インストールしたら、 SLES のバージョンを確認しておきます。

oes2015sp1:~ # cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 4
oes2015sp1:~ #


- SLESをインストールしたら、仮想イメージはバックアップしておく。Add-on の導入に失敗したときは問題を修正してここから再度導入しなおします。

- OES アドオンのインストール -

yast2 > Software > Add-On Products から、ダウンロードした ISO ファイルを指定します。ISO ファイルはあらかじめ、インストールする SLES の任意の場所にコピーを作っておきます。



EULAに Accept

NSS と iManager をチェック

NSS と iManager をチェックすると、最低限の eDirectory と関連ツールがインストールされます。それ以外の機能も、OES 2015 の追加機能ですが、ここでは説明しませんし、あまり使うこともないと思います。



インストール方法は Custom にします。 Typical を選ぶと後が大変です。




SLP はデフォルトの Multicast 警告が出ますが OK



追加の NTP サーバーがあれば add、すでに NTP が設定されていれば、そのままOKします。くどいようですが、時刻同期の設定がおかしいと eDirectory のインストール時に致命的なトラブルが出る場合があります。




すでにあるツリーなので Existing Tree で ツリー名をセット



既存のツリーを保持しているサーバーの IP 名、もしくは DNS名をセットして Validate,

確認できたら、cn=admin,o=company 区切りは(.) ドットではなく (,) カンマです。



Enter Server Context で "Browse" ボタンで、インストールする先の OU を選択します。事前にOUが必要な場合、OU をあらかじめ作成しておきます。

- OU=system など、インフラ系担当者のコンテナ
- OU=Users など、ヘルプデスク単位のユーザコンテナ

を分けておく事が私の好みですが、もちろん OU=Sales, OU=Engineer などに分ける場合もあるでしょう。OUのユーザ数はダンパー数である150名前後を一つの単位として設定するのが良いでしょう。もっとも、企業組織も、ダンパー数に応じて部署分けされているケースが多いので、それほど困ることはないと思います。

ツリーをブラウズして、サーバーコンテナをセット



NMASの設定、デフォルト



代理ユーザの設定、そのまま



- eDirectory と NSS の設定 -

サマリを確認して次へ、ここから、ディレクトリの同期と NSS の設定が始まるので、レプリカのサイズに応じて時間がかかります。最低30分程度かかると考えてください。

a0056607_14200237.jpg




同期元の eDirectory サーバーで

# ndstrace モニタを起動して

DNSTrace: ndstrace=on
DNSTrace: ndstrace=+sync

を実行すると、同期状態が確認できます。はじめは -601 などの赤文字のエラーが出まくりますが、そのうちに同期が収束すると、緑色の項目が増えてきます。

※ ndstrace は実行中に CTRL+DEL キーで中止したり、リモートセッションを切断させないでください。ゾンビ化します。必ず ndstrace は exit で終了させてください。

ndstrace causes ndsd to hang when left running from a terminated putty session




かなり時間がかかります。




終わりました。

※ この時点までで、何等かのトラブルが出た場合、基本OSの状態から、出来てしまった新しいサーバーの関連するオブジェクトをiManager で eDirectory Tree から削除して、時刻同期など、問題となりそうな項目をチェックして、再インストールした方が良いでしょう。LUM(Linux User Management) の設定で失敗し、NSSが設定できないトラブルが頻発するようです。

a0056607_14203893.jpg



カスタマセンターへの登録は後で


この後

# ndsrepair -T

を実行し、Time is in Sync のステータスを確認し

oes2015x1:~ # ndsrepair -T
[1] Instance at /etc/opt/novell/eDirectory/conf/nds.conf: oes2015x1.OU=system.OU=tokyo.O=ace.ACE-NET
Repair utility for NetIQ eDirectory 8.8 - 8.8 SP8 v20807.08
DS Version 20808.03 Tree name: ACE-NET
Server name: .oes2015x1.system.tokyo.ace
Size of /var/opt/novell/eDirectory/log/ndsrepair.log = 5971 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: Monday, November 13, 2017 14:04:52 Local Time
---------------------------+---------+---------+-----------+--------+-------
DS Replica Time Time is Time
Server name Version Depth Source in sync +/-
---------------------------+---------+---------+-----------+--------+-------
Processing server: .oes2015sp1ace2.system.tokyo.ace
.oes2015sp1ace2.system... 20808.03 0 Non-NetWare Yes 0
Processing server: .oes2015x1.system.tokyo.ace
.oes2015x1.system... 20808.03 0 Non-NetWare Yes 0
---------------------------+---------+---------+-----------+--------+-------
Total errors: 0
NDSRepair process completed.
oes2015x1:~ #

また # ndsrepair -R と ndsrepair -U を実行して、"Total errors 0" を確認します。

oes2015x1:~ # ndsrepair -R
[1] Instance at /etc/opt/novell/eDirectory/conf/nds.conf: oes2015x1.OU=system.OU=tokyo.O=ace.ACE-NET
Repair utility for NetIQ eDirectory 8.8 - 8.8 SP8 v20807.08
DS Version 20808.03 Tree name: ACE-NET
Server name: .oes2015x1.system.tokyo.ace
Size of /var/opt/novell/eDirectory/log/ndsrepair.log = 6772 bytes.
Preparing Log File "/var/opt/novell/eDirectory/log/ndsrepair.log"
Please Wait...

: 中略

Total objects in partition - T=ACE-NET : 65
Repairing objects - done(65)
Total Objects = 65, UNKNOWN class objects = 0, Total Values = 1741
[Pseudo Server]
Total Objects = 1, UNKNOWN class objects = 0, Total Values = 34
Finish: Monday, November 13, 2017 14:09:28 Local Time
Total repair time: 0:00:01
Checking stream syntax files
Repair process completed, total errors found = 0
Total errors: 0
NDSRepair process completed.
oes2015x1:~ #

- この後の作業 -

iSCSI マウントした iSCSI ターゲットボリュームに NSS ボリュームを作成します。

Open Enterprise Server 2015 OES2015sp1 で iSCSI NASのNSSマウント









[PR]
by islandcenter | 2017-11-14 14:25 | OES Linux | Trackback | Comments(0)

- 目的 -

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

- 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)