1
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,ファイルサーバー認証, セキュリティ
■
[PR]
▲
by islandcenter
| 2018-03-21 13:26
| OES Linux
|
Trackback
|
Comments(0)
2018年 03月 19日
ログオフなしでファイルサーバーとのセッションを切断するには
まるでセキュリティホールの様な Windows の困ったちゃんの仕様に悩まされました。
- 現象 -
いくつかの NAS や Samba などの CIFS サーバーから、特定のサーバーだけ、サインオフせずにセッションを切断したい。Windows からログオフせずに、NAS からログオフできないか。
> net use
> net use \\server /delete
して、セッションがなくなったにもかかわらず、認証情報がキャッシュされていて、セッションを切断できない。セッションが残る。
関連記事
OES 2018 Linux eDirectory＋NSS で CIFS フォルダ容量制限(ディレクトリクォータ)付きファイルサーバーOES Linux でフォルダの容量制限付きアーカイブ専用ファイルサーバー：サーバーをゴミ箱にしない工夫クライアントPCのBCP対策 D:ドライブにドキュメントを保管・バックアップ
例えば NAS などに user-a でログインしたあと、ログアウトして、user-b でログインし直そうとすると、user-a のセッション情報がキャッシュされていて、無認証で接続できてしまう。しかもそのセッションは > net use コマンドで表示されてもいないので、削除すらできない。サーバーが繋がったままではトイレもコーヒー買いにも行けない。かといってログオフしたくない。
サインオフして、再ログインしないとセッションがクリアされない。
- 対策 -
ネットワークに接続している全てのファイルを閉じて、エクスプローラも（出来れば）閉じておく。
> net use \\server\share /delete
を実行した後
> klist purge
を行い、エクスプローラからネットワークの "\\server" をクリックすると、ログイン認証画面が出てきた。
klist Kerberosチケットの表示/削除
- リスト -
C:\>net use
新しい接続は記憶されます。
ステータス ローカル名 リモート名 ネットワーク名
-------------------------------------------------------------------------------
OK M: \\NAS_A\data Microsoft Windows Network
OK Q: \\NAS_B\Public Microsoft Windows Network
OK \\SERVER\IPC$ Microsoft Windows Network
コマンドは正常に終了しました。
C:\>net use \\SERVER /delete
\\SERVER が削除されました。
C:\>klist purge
現在のログオン ID: 0:0x2c8eb3ac
すべてのチケットを削除しています:
チケットが削除されました。
C:\>
ファイルサーバーのフォルダ容量制限(ディレクトリクォータ)
-Keyword -
ファイルサーバー,NAS,CIFS,Samba,Windows10, サインオフ,ログオフできない, セッションが切断できない,
■
[PR]
▲
by islandcenter
| 2018-03-19 13:50
| Windows
|
Trackback
|
Comments(0)
2018年 03月 10日
OES 2018 が出荷されたようなので、評価版 ファーストインプレッション。
全体の流れは従来の SLES12 ＋ OES アドオンのインストールと同じ流れです。ここでは全体の流れと雰囲気をお伝えする目的なので、詳細は Micro Focus/Novell のマニュアル、ドキュメント等をご参考ください。
What’s New or Changed in OES 2018
このバージョンから Novell -> Micro Forcus へとブランド名が変わっています。
そこで、従来の様に SLES+OES addon 形式で配布されていた電子メディアイメージが OES(IncludeSLES12) の１枚もののDVDイメージで取得できます。
前のバージョンから Mac 用に AFP もサポートされ、連携強化のため Micro Focus Kanaka for Mac 3.0.1 も同時にリリースされています。
今度 Mac を買ったときにでも評価してみたいと思います。
評価用電子メディアのダウンロードはこちら
無料登録の Novell ID が必要です。
--
インストール
今回は、細かな内容を追わず、全体のデザインの違いや流れを追ってみます。
事前に DNS に
- サーバー名 : A:サーバーIPアドレス
- CNAME: ツリー名: サーバー名
を定義しておきました。
DVD ブート
ブートスクリーンから Novell と SUSE のブランドロゴがなくなり Micro Focus ロゴです。
デフォルトファイルシステムは SLES12 ベースですが、 EXT4 です。
Expert Partition Setting で / に１０Gバイト、残りはNSS用に空けておきます。(敗因) - NSS は /(ルート)と swap がある物理ディスクとは別なデバイスでしか作れません。最小限で / ( ルート)パーティションは最低４Gバイト必要な様ですが、何かと必要なので１０Gから１６G程度あれば十分でしょう。NSSボリュームは別な物理ディスクや iSCSI SAN を使うのがベターです。通常、今時は仮想化運用でしょうから / パーティションに使うディスクイメージは１０G程度から１６G程度与えます。
Install Summary から "Software" を開きます。Open Enterprise Server のコンポーネントは未チェックです。
Domain Service for Windows や AFP などが追加されてます。後からインストールします。
インストーラの画面にもちょっと Microforcus アレンジが入っています。インストール手順は SLES12 のインストール手順そのままです。
SUSE Linux Enterprise 12 SP3 (SLES12sp3) のインストール
ただしこの時点で SLES12 base をインストールする場合の XNE/KVM/virtual の選択がないので、基本的にはベアメタルサーバーか、仮想化環境下で動作させることになります。つまり HyperVisor OS は別に用意するという事ですね。
再起動後、CUI 版 yast が起動します。ネットワークの設定とホスト名、DNS名を固定します。
今回は systemd の起動は text モードにしましたが、startx を実行すると、デスクトップスクリーンが確認できます。
思いっきり Micro Focus の壁紙ですね。
yast のデザインはそのままです。中に OES Installation と Configuration ユーティリティのアイコンがあります。
SUSE のベースバージョンは 12sp2 です。
一度再起動して、 HOSTNAME を書き換えます。
OES Install & Configuration を開きます。YaST > Software Configuration のままですね。
今回は基本的な機能として Novell Storage Service(NSS) と iManager を選びます。
OES のインストールが開始されます。
インストール方法は "Custom" を選択します。
SLP の設定、デフォルトのまま、警告を無視して accept
NTP の設定です。何も設定がない場合はここで設定できますが、できればOES アドオンをインストールする前に設定すべきでしょう。
SUSE Linux (SLES12) を YaST で NTP の設定
ディレクトリツリーの設定：
本来であれば既存のツリーに接続させますが、ここではテスト環境なので New tree : "ACE-tree” を作成します。
ツリーに追加する場合はこちらを参考にしてください。
OES 2015sp1 の既存ツリーへのインストール
管理者 admin の設定です。ここで o=xxxx は最初の 組織オブジェクト(Organization) です。.admin,o=ace の間はドットではなくカンマで区切ります。パスワードは忘れないようにしましょう。テキスト端末を開いて、NUMロックや CAPSロックが押されていない事を確認しておくと良いでしょう。
サーバーコンテナを設定します。デフォルトだと、o=xxxx 直下に作られるので、最初のディレクトリ設計に重要なポイントとなります。ここでは ou=System.ou=tokyo.o=ace を設定しました。サーバーやシステム関連のオブジェクトはツリー上のこのコンテナに作成されます。
NMAS メソドはデフォルトのままOK
代理ユーザの設定、サーバーコンテナそのままでOK、パスワードはデフォルトのままです。
サマリを確認します。
eDirectory の構築が始まります。
このプロセスはいつも時間がかかり、ヒヤヒヤします。大体２０分から３０分程度かかると思ってよいでしょう。
無事終わったようです。
# ndsrepair -T
# ndsrepair -R
を実行して、エラーがないことを確認します。
eDirectory Version は 9.0 です。8.x とは変わっていませんが細かなチューニングに変化があったのでしょうか。１５年ぶりくらいのメジャーアップデートという事になります。
oes2018a:~ # ndsrepair -T[1] Instance at /etc/opt/novell/eDirectory/conf/nds.conf: oes2018a.OU=system.OU=tokyo.O=ace.ACE-TREERepair utility for NetIQ eDirectory 9.0 - 9.0.3 v40005.13DS Version 40005.13 Tree name: ACE-TREEServer name: .oes2018a.system.tokyo.aceSize of /var/opt/novell/eDirectory/log/ndsrepair.log = 3528 bytes.Building server listPlease Wait...Preparing Log File "/var/opt/novell/eDirectory/log/ndsrepair.log"Please Wait...Collecting time synchronization and server statusTime synchronization and server status informationStart: Friday, March 09, 2018 12:35:31 Local Time---------------------------+---------+---------+-----------+--------+-------DS Replica Time Time is TimeServer name Version Depth Source in sync +/----------------------------+---------+---------+-----------+--------+-------Processing server: .oes2018a.system.tokyo.ace.oes2018a.system.tokyo... 40005.13 0 Non-NetWare Yes 0---------------------------+---------+---------+-----------+--------+-------Total errors: 0NDSRepair process completed.oes2018a:~ #
http://ip-address (http://ip-address/nps)を開き、imanager が使えることを確認します。
ブラウザの言語を "Japanese" にすると日本語表記が出てきます。
NSS ボリュームの作成
OESの基本インストールが出来上がったら、NSSボリュームを作成します。NSSボリュームは仕様上、ルートパーティションを持たない物理ディスクに作成します。仮想環境では、別なディスクイメージを使うか iSCSI - SAN に割り当てられた仮想ディスクを使うのがベストでしょう。今回は仮想環境なのでディスクイメージを増設して使いましたが、実運用では iSCSI NAS を使って、データボリュームとするなどのケースが実用的だと思います。
iSCSI 上に仮想イメージを導入し、ついでに Live Migration してみる。Open Enterprise Server 2015 OES2015sp1 で iSCSI NASのNSSマウント
iManager > Storage > Device より、NSSに割り当てた物理ディスクを Initialize Disk
次に pools, Volumes でNSSボリュームを作成します。
iManager ではなく、テキスト端末から # nssmu ユーティリティで作成することもできます。
ボリュームが作成されました。
--
全体としては特に変わったところはないな、という感想です。ルートパーティションが BTrFs ではなかったり、すっかりロゴを含めて Micro Focus スタイルになってしまったのは寂しさも感じます。バージョンが変わるたびにUIやツールの使い勝手が変わる Windows と違って、変わらぬ機能と確実に不具合がなくなり、より必要な機能だけにフォーカスして、バージョンアップしていればよろしいわけで、変わらぬ安心感を感じます。
続き
OES 2018 Linux eDirectory＋NSS での CIFS ファイルサーバーOES 2018 Linux でフォルダ容量制限付き AFP Mac 用ファイルサーバーOES Linux でフォルダの容量制限付きアーカイブ専用ファイルサーバー：サーバーをゴミ箱にしない工夫
Novell Openenterprise Server, Linux, SUSE, NSS, ファイルサーバー,
■
[PR]
▲
by islandcenter
| 2018-03-10 14:43
| OES Linux
|
Trackback
|
Comments(0)
2018年 03月 05日
OES Linux でフォルダの容量制限付きアーカイブ専用ファイルサーバー：サーバーをゴミ箱にしない工夫
あわせて読みたい
Novell OES Linux ファイルサーバーをファイルのゴミ箱にしない工夫OES 2018 Linux で SMB ファイルサーバーのフォルダ容量制限(ディレクトリクォータ)OES 2018 Linux でフォルダ容量制限付き Mac 向けファイルサーバーOES 2018 が出荷されたようなので、評価版 ファーストインプレッション。
ファイルサーバーが常に抱える問題-ファイルサーバーはファイルのゴミ箱
部屋の中は、不要なもので一杯、ここで断捨離しなければ、と思いつつ、つい要るもの要らないものがブックシェルフに混在しているのが、私たちの暮らしなのですね。これが大家族なら、オカぁちゃんが「これ捨てるよ」と言っても、「いやぁだぁー」と子供に泣かれると困ってしまう。間違って捨ててしまうと晩飯も「食べたくねぇ」とゴネられます。
という事で、本棚にはよく読む本を置いておき、押し入れには、読むことはないけれど、時々必要になって引っ張り出してくる捨てられないデータというモノがあるんですね。子供のころのアルバムだとか、学校の卒業写真、人生でたった一度だけ取った英語の１００点満点のテスト、先祖が残した貴重な資料。まそんなところでしょうか。
同じ事が、企業の中のファイルサーバーにも当てはまるわけです。ある調査では、サーバーの中の３０％のファイルは「死んでるデータ」だそうです。
機械的に、「生きているデータ」「取っておきたいデータ」「死んでるデータ」「不要なデータ」と区分けして断捨離するのはシステム管理者としてできない事。実際のファイルの重要性の判断は、エンドユーザがある程度行わなければいけないわけです。目に見える倉庫の棚や、本棚と違って、目に見えないファイルサーバーのストレージは「醜い」「汚い」「乱雑だ」という事には気が付かず、ファイル整理の判断は難しいものです。
ファイルの断捨離は、利用者が行うべきであり、管理者はそのテンプレートを作ってやることが仕事となります。エンドユーザには中々嫌われる業務になるかも知れませんが、机の中や目に見える限られたスペースしかない物理的なファイルキャビネットの整理と同じく、利用価値のないファイルの整理もユーザの仕事なのです。
Linux 管理者なら、「アーカイブ」というのは tar とかのコマンドでファイルを圧縮してしまう事なのですが、業務の中でどのデータが重要でアーカイブして保存しておくことが重要かの判断はなかなか付かないものです。しかもいったん圧縮した内容は解凍しないと利用できないのですから、ユーザ側からすると、「アーカイブしたの忘れてた」という事になります。ましてやテープなどの外部メディアにアーカイブとっても、実際にその中のアーカイブデータが利用できるまでの道のりは低いわけですね。外部メディアにアーカイブするのはあくまでも「アーカイブのバックアップ」を目的とすべきでしょう。
ファイルサーバーはつねに増大するストレージにより、永遠に問題を抱えています。
何しろ、最近ではPCはノートブックやタブレットが主流になり、１２８GbのSSDとかしか記憶容量がないのです。しこに２０Tbもの巨大なファイルサーバーがあると、たとえそいつは１００人で共用している事にも気が付かず、「じゃぁディスクを増設して C:ドライブ丸ごとバックアップ」なんて無法な事をするエンドユーザもいるのです。
エンドユーザには気にならないものですが、ファイル共有用ファイルサーバーというのは、単にディスク一つを追加増設するだけでも大変な作業で、バックアップとリストア、バックアップに必要なメディアの確保、という膨大な作業が必要となります。
そこで、契約書や保存期間が法令や社内基準で定められているファイルを保管し、アーカイブとすることで、通常の「読み書き可能な共有フォルダ」「読み出し専用のフォルダ」「特定のユーザは書き込みや削除、移動はできるが読み込みと書き換えのできないアーカイブフォルダ」を作る事を考えてみましょう。
OES Linux のNSSファイルシステム
他のファイル共有システムのように「読み込み専用」「読み書き自由」の２種類の属性しかないファイルシステムと違い、Microforcus/Novell Open Enterprise Server(OES Linux) の NSS (Novell Storage Service)では[SRWCEMFA] のファイル・ディレクトリのトラスティやフォルダの属性が豊富で、フォルダのディスク容量クオータ（ディレクトリ単位の容量制限）ができるので、豊富なトラスティと属性を合わせて容量制限が利いたアーカイブ専用のフォルダ・ディレクトリを簡単に作ることができます
iManager からの Archive フォルダのアクセス権限
まず、Archive 専用のディレクトリを作り、このフォルダの読み込みだけのユーザと、読み込み、書き込みはできないが、ファイルの移動や削除ができるユーザ、グループを作ります。
エクスプローラのフォルダのプロパティから見た場合
Sales グループユーザはファイルの読み込み[ R F ]はできますが、移動、作成、削除[ WCE M ]が許可されていません。
ArchiveManager のグループユーザは、ファイルの読み込み、書き換え[ RW ]は許可されていませんが、ファイルの削除、作成（コピーや移動、上書き）[ CEFM ]は許可されています。
Sales グループのユーザはファイルの読み出しだけは許可されています。もし、Sales グループのメンバーは、普段使いのフォルダに作った「消さないでフォルダ」をアーカイブに移動させてもよいとするならば [ R C F ] の( create )権限を与えます。これにより、メンバーは「消さないでフォルダ」を「アーカイブに移動」させて、ArchiveManager グループメンバー以外は、削除したりアップデートできないようになります。
ただし、「ファイルの作成」はできても「削除、名前の変更」はできないので、誤ってこのフォルダで「新しいフォルダの作成」などを右クリックしてしまうと、当人には「削除できないフォルダ、ファイル」ができてしまいます。
一方、ArchiveManager グループのユーザはファイルやフォルダの作成、削除、移動は許可されますが、ファイルの閲覧、書き換えは許可されません。
条件は論理和ですから、両方のグループに所属している場合、[ w ] (書き込み)権がないだけなのでファイルの作成、コピー、削除、閲覧はできますが、ファイルの更新は許可されません。
ディレクトリ（フォルダ）のクォータ管理（容量制限）
ワークグループのディレクトリ（フォルダ）にはクオータ（容量制限）がかけられます。いくらファイルのセキュリティ機能があっても、フォルダのクォータ管理ができないと、狭い部屋（限られたリソース）にある、本棚はすぐに一杯になってしまいます。そこで、フォルダにクォータ（容量制限）をかけます。この作業は簡単で、システムが稼働中でも数クリックで設定され、即時有効になります。ある特定のユーザが大量のデータを作り、残りのメンバーはあまり使わない、というケースでもフォルダ容量制限が利いている限り、ユーザには関係なく、フォルダの容量制限が有効になります。
例えば、Sales フォルダには、外歩きであまりファイルを作らないユーザと、見積書の清書を行うアシスタントでは、作るファイルの量というのは違うという事です。ユーザクォータではこの様な気の利いた小回りができません。
例えば、普段使いのグループフォルダには１０Gb、アーカイブフォルダには２０Gbのクォータをかけておき、グループ作業用フォルダがクォータで満杯になった場合は、ArchiveManager グループに所属するユーザがグループフォルダから、アーカイブ専用のフォルダにファイルを移動させて、容量を開ける事ができます。
また、クォータが利いているアーカイブ専用フォルダがいっぱいになれば、まずファイルサーバーの中で参照されることがないだろうと思われるファイルは、光メディアやテープバックアップを行い、アーカイブの整理を行います。
また、容量制限がかかったアーカイブ専用フォルダは、普段あまり使われないファイルが多いという前提で、フォルダを作った時に「即時圧縮」の属性をつけておけば、ファイルの内容にもよりますが、 2～30% 程度は圧縮されるため、わざわざ ZIP 化したり tar.gz にする必要もありません。ファイルによっては、「ちょっと開くために時間がかかる」程度でユーザはファイルを開くことができます。
「部外秘」のフォルダからは「権利継承」を削除する
「部外秘フォルダ」からは「権利継承」( Inherited Rights Filter ) から全ての権限を Revoke （はく奪）する事で、部外者からは表示されないようにします。
明示的に「部外秘フォルダ」に Trustee を与えない限り、ユーザやグループにはフォルダすら見えなくなります。
このような感じでReadOnly フォルダ内の「部外秘フォルダ」自体が他部署では不可視になります。
おまけ ポスト用フォルダ
Microforcus/Novell OES の NSS ファイルシステムでは、[ c ] 権だけのフォルダを作ることができます。このフォルダは、私は「ドロップボックスフォルダ」と呼んで位います。C権を与えられたユーザは、このフォルダにドラック＆ドロップでファイルを保存する事だけはできます。しかし、フォルダを開いてファイルの読み書き、削除、変更どころか、フォルダを開く操作さえ拒否されます。つまり郵便箱( PostBox )のような使い方ができるわけですね。もちろんこの郵便箱を開いて中のファイルを収集するポストマンが必要なわけで、彼らにはファイルの移動、削除は許可されても、封筒を開封する（読み出し書き込み）権利はありません。
例えば、健康診断などのセンシチブなデータのポスト場所や、学校の宿題の投函場所として使うことができます。一般ユーザは「春の健康診断」のPDF ファイルをポストして、ポストマンは、例えば「田中の健康診断データ.pdf」を「総務の投函場所に移動」させることはできるが、内容は読むことができない、という事になります。この場合、ファイルを読み書き可能なディレクトリにコピーしてしまえば読み書き可能なので、PostManager のアカウントは厳重に利用してもらう事になります。
--
ファイルサーバーは企業のシステムとしては実に原始的で、古くから利用されているシステムです。過去も未来も、「ファイルサーバーのゴミ箱化」は避けて通れない問題で、システムコストの数十％を無駄に投資しています。
OES Linux は NetWare 時代からの「専用ファイルサーバーOS」です。はるか昔から、ファイルのトラスティ、ディレクトリクォータなど、豊富なファイル管理機能を備えています。
ディレクトリクォータを厳しく設定し、フォルダの管理を「生きているファイル」「あまり使われないファイル」「ほとんど使わないが保管すべきファイル」「死んでるファイル」とランク付けし、フォルダのアクセス制限を設計してしまえば、後は利用者側が限られたリソースを有効に利用できるのですね。
ファイルサーバーゴミ箱化,ファイルのゴミ箱化,ディスク容量制限,フォルダ容量制限,フォルダクォータ,ファイルサーバーのゴミ箱化,死んでるファイル,必要なファイル,アーカイブが必要なファイル,Linux, Windows,ファイルサーバー
■
[PR]
▲
by islandcenter
| 2018-03-05 12:09
| OES Linux
|
Trackback
|
Comments(0)
1
