2018年 03月 21日
OES 2018 Linux で SMB ファイルサーバーのフォルダ容量制限(ディレクトリクォータ)
関連記事
OES 2018 が出荷されたようなので、評価版 ファーストインプレッションOES 2018 Linux でフォルダ容量制限付き AFP Mac 用ファイルサーバーOES Linux でフォルダの容量制限付きアーカイブ専用ファイルサーバー：サーバーをゴミ箱にしない工夫
SUSE Linux を使った Novell の従来の Open Enterprise Server (OES Linux) には samba による CIFS プロトコルが実装されてきました。Novell samba は OSSの samba を OES Linux に強引に実装したため、LUM(Linux User Management) を意識した接続を経由することにより Ldap 互換の eDirectory 認証、Linux/samba 認証経由のセキュリティポリシーが必要です。スケーラビリティも Linux/samba に制限されていました。User/Password から --> LUM(Linux User) --> eDirectory と NSS ファイルアクセスという複雑な実装です。複雑な構造なので、Novell OES + samba という組み合わせは、躊躇していました。
一方、すでに OES 11 より実装された Novell Native CIFS は、パスワードを直接 eDirectory のパスワードポリシーを経由して NSS ファイルシステムのセキュリティ構造に単純接続します。オーバーヘッドも少なく、実装もシンプルです。もちろん、Linux の認証を経由しないため、管理方法も Linux を意識せず、eDirectory と NSS の管理に集中できます。ユーザはシンプルで高機能、高性能で高い天文学的なスケーラビリティを持つ Novell Storage Service (NSS) に簡単にアクセスできます。
結果としては
「意外といけるな」
というものでした。
Comparing Novell CIFS and Novell samba
- インストール -
OES と eDirectory, NSS ファイルシステムは導入済です。
OES 2018 が出荷されたようなので、評価版 ファーストインプレッション。OES 2018: Novell CIFS for Linux Administration GuideInstalling CIFS after the OES Installation
- Novell CIFSの実装 -
yast2 > OES Configuration から CIFS をチェックして Accept.
Novell CIFS Services の行に未設定の項目があるのでクリック
admin.org のパスワードをセット、これによりスキーマの拡張が行われます。
サーバーコンテナだけ選択されているので、O=MyOrg を Add して、” Enable Subtree Search” をチェック
Next
赤線が消えたので Next
Next
５分待つ
インストールできました。
※ "Clone ..... AutoYaST" のチェックは外しても構わない。というより AutoYaST は滅多に使わないので、チェックを外すべきでした(敗因)
AutoYaST のクローニングをする場合は５分くらいかかります。Finish
- iManager より -
http://server/nps で iManager を開き admin.org でログインします。 "Configureアイコン" > Installed Novel Plug-in Modules に CIFS Management Plug-In がインストールされていることを確認します。マニュアルには自動的にインストールされる、とは書いていませんでしたが....
※ インストールされていない場合 Configureアイコン > "Avilable Novell Plug-in Modules" から CIFS プラグインをインストールします。
iManager > File Protocol > CIFS を選び、plug-in が動いていることを確認。
デフォルトで CIFS 名＝ホスト名になっています。OES_CIFS とか WorkGroup_NAS とか任意に名前を変えてアナウンスを流すと良いでしょう。
この画面から Stop/Start して再起動もできますが
＃ rcnovell-cifs restart
でもリスタートできます。
ユーザーコンテキスト > O=org からサブツリー全体に割り当てられています。
CIFS アクセスには Universal Password(デフォルト無効)が必要です。
CIFS and Universal PasswordUniversal Password helps in management of password-based authentication schemes. Each CIFS eDirectory user in native and domain mode must be Universal Password enabled in order to be allowed to log in to the CIFS server. The Universal Password is not enabled by default.
iManager > Role & Tasks >Password > Password Policies > Assignments に、 [New Password Policy] を add してユーザ、もしくはユーザコンテナを追加します。e.g にもあるようにパスワードポリシーはユーザのタイプによって "Enginner_PW_Policy" とか "VIP_PW_Policy" など複数のポリシーを定義して、センシティブなデータにアクセスする場合は、厳しいパスワードポリシーを、一般ユーザは単純なポリシーを、と区別してユニバーサルパスワードのポリシーを個別に与える事ができるわけですね。Active Directory の様に、OU 単位でしかポリシーを定義できない製品と違い、複雑な組織によって、ポリシーを使い分ける事ができます。
Universal Password
ウィザードに従い新しいパスワードポリシーを作ります。
※ Password Policy は [root] の "Security" コンテナに作成されます。
"Would you like to enable Universal Password" はデフォルトのまま Yes
特にパスワードポリシーを変更しなければ、デフォルトで構いませんが、パスワードポリシーとして、複雑なパスワードを要求したり、定期的なパスワード変更を求めるパスワードポリシーが必要であれば、カスタマイズできます。
パスワードポリシーを使用したパスワードの管理
そのままウィザードを進め Finish したら、"Assignment" にユーザーオブジェクトそのもの、もしくはユーザのコンテナを指定します。ただし、指定したオブジェクトのサーバーは eDirectory のコンテナ R/W レプリカ を保持している必要があるようです。NetWare3 互換の Bindery Connection と同じです。
※ もっとも、ここで新しいポリシーを作らなくても、既にある "Common Proxy Policy" にユーザを割り当てても構いませんでした。（敗因）
これで、一応、OES 2018 CIFS は設定完了です。
ネットワークに見えました
ここでサーバーをクリックして、認証ダイアログが出ない場合、あるいは eDirectory パスワードが受け付けられない、ログイン認証できない場合は、パスワードポリシーがユーザに適用されていないことによります。
※ このダイアログでは "CN=user_name,OU=Users,OU=Tokyo,O=ACE" と言った、パス付の FDN ( Fully Distinguished Name ) のユーザ名がログインに使えないので、ユーザオブジェクト、またはユーザが存在する、ユーザコンテナをパスワードポリシーに直接アサインしておく必要があるわけです。また、サーバー自身に eDirectory のユーザコンテナのマスターか、Ｒ／Ｗレプリカデータベースが必要です。
Synchronizing NMAS Login Methods Is Required to Avoid Login Failures
ボリュームを開くと NSS のトラスティが利いています。
サーバーをゴミ箱にしない工夫
OES のディレクトリ容量制限、クォータ機能の注目すべき点は特別に複雑な操作も行わずに、どれだけ複雑なディレクトリ構造、ファイル容量であっても、 OES Client のプロパティか、iManager のフォルダプロパティから、運用中、稼働中に一瞬で数クリックで制限ができる事です。
net use
で確認して
> net use /delete \\server\share
しても繋がっている？
これが CIFS/SMB のおせっかいなユーザにもハッキングにも優しい余計なお世話。
ログオフなしでファイルサーバーとのセッションを切断するには
CIFS のテストで、ログイン、ログアウトを繰り返す場合は
C:\> klist purge
によって Kerberos チケットを削除します。 また CIFS の怪しい仕様で、NSSボリュームに与えた、ファイル／フォルダのトラスティが安定するまで、かなり不安定な動きをします。トラスティを与えたフォルダアクセス権限をネットワークにアナウンスするまで、変なタイムラグや、クライアントやサービスをリブートするなどの「ひと変化」が必要なんですね。このような CIFS の "仕様上の問題点" は解決できません。やっぱり OES の NSS ファイルシステムをクレームなしで使うには、OES Client for Windows を使った NCP プロトコルによる接続を推奨するしかありません。
- インプレッション -
OES Linux に共通の課題として、インストールに時間がかかる点が挙げられます。インストール作業そのものはシンプルで単純ですが、非常に時間がかかります。また、デフォルトで、Universal Password ポリシーが適用されないため、インストール後の最初の接続まで、随分つまづきました。また Windows の Kerberos 認証がキャッシュされるのは困ったものです。
その代わり、コンセプトは samba よりシンプルで理解しやすいので実装そのものは単純に行う事ができました。以前 Novell samba でハマった事があったので、身構えていましたが、割と単純に問題を解決できました。「意外とイケる」というのが感想です。
また、ユーザ管理、ファイルアクセス権限の管理も、複雑で面倒な Linux の管理方法よりも単純で、理解しやすくなっています。もっとも eDirectory と NSS ファイルシステムを理解した上での事なので、Linux ”しか”知らない管理者には難しいと思えるでしょう。逆に NetWare 5 以降を経験した管理者ならば、 NCP (Novell Core Protocol) を使わずに どこにでもある CIFS がそのまま使える点は大きな助けになります。
何かというと数万ファイルのフォルダを「変更をこのフォルダー、サブフォルダーおよびファイルに適用する」を間違ってチェックして数時間利用不可能になる Windows のファイルセキュリティシステムより、一瞬でトラスティが機能する NCP+NSS のファイルアクセスは強力です。
ただし、CIFSの固有の NAS や samba、Windows 共有に関するセキュリティのや接続のトラブルは固有のものなので（俗に言う仕様という奴）これだけは困ったものです。BYOD 端末では CIFS 接続でも構いませんが、社内利用の Windows 端末は OES Client for Windows を使った NCP 接続の方が安定して、セキュリティ的にも安心感があります。構内LANで使うには、私は「NCP 接続を強く推奨」します。
Windows "しか" 知らない管理者にとっては、eDirectory + NSS ファイルシステムは難解そのものなのですが、Windows 自体が難解そのものなので、OES Linux の管理は理解が進むとシンプルです。そもそも、Microsoft 自体が自社製品しかサポートしていないにもかかわらず、自社製品自体のサポートが当てにならないのに対し、サードパーティベンダーは、"自社製品オンリー村社会” の中に "住み着いた異分子"であることを理解しているので、割と「閉鎖的な村の常識」に対する適切なサポートを訪問者に提供してくれるものなんですね。
- Keyword -
Novell CIFS, eDirectory, LDAP, samba,ファイルサーバー認証, セキュリティ
by islandcenter
| 2018-03-21 13:26
| OES Linux
|
Comments(0)
