OES 2018 Linux でフォルダ容量制限付き Mac 向けファイルサーバー : isLandcenter 非番中

2018年 04月 13日

OES 2018 Linux でフォルダ容量制限付き Mac 向けファイルサーバー

このテーマの続きです。

OES 2018 が出荷されたようなので、評価版ファーストインプレッション

https://islandcnt.exblog.jp/238381712/

OES 2018 Linux eDirectory＋NSS での容量制限付き CIFS ファイルサーバー

https://islandcnt.exblog.jp/238412872/

OES Linux でフォルダの容量制限付きアーカイブ専用ファイルサーバー：サーバーをゴミ箱にしない工夫

https://islandcnt.exblog.jp/238371771/

OES 2018 は Microforcus/Novell がリリースした Open Enterprise Server の最新版です。この新しい機能の一つにAFP によるネィティブな　NSS ファイルシステムへのアクセスがあります。CIFSでは仕様の変動が多く、上手く動かない場合は AFP でも接続できるよう、Mac ユーザのために設定しておきます。AFPは今ではレガシーなプロトコルですが、macOS では一応今でもサポートされており、CIFSで上手くネゴシエーションできない場合、 AFP での接続が無難なようです。

OES for CIFS & AFP で作られたネットワーク上のファイルサーバーは NetIQ eDirectory によって、ユーザプロファイルが同期され、どの端末からどのサーバーのパスワードを変更しても、同じパスワードでのシングルサインオンができます。

また、単体の NAS を多数使うようなネットワークよりも、OES 2018 の統合されたディレクトリ、アクセス権限により、数百人、数千人規模でも、アクセス権限の管理が容易です。

OES Linux の NSS ファイルシステムは、現在確認する限りでは、ボリューム/ユーザ単位のクォータができるケースは沢山あれども、ほとんど唯一「フォルダ単位の容量制限（ディレクトリクォータ）」ができるリモートファイル共有システムです。

何しろ NetWare 時代から標準で付いてくる機能なので、２０年以上の長い歴史と実績があるファイルシステムです。

Windows ファイルサーバーでは、数千、数万ファイルのフォルダのアクセス権などのプロパティを変更する作業だけで数分から数時間かかります。

しかし、OES Linux の NSS ファイルシステムでは、メタファイルの書き換えにより、下位のフォルダに何億ファイルあっても、アクセス権の変更やフォルダの容量制限などの操作は一瞬で完了します。

ファイルサーバーは、利用方法に厳密なルールを設けないと、ただの「ローカルディスクの無意味で無限のバックアップ」のための存在対象となってしまい、本来の「情報共有」のためのスペースが確保できません。そのために、フォルダ単位でのクォータ設定は重要な機能です。

「無駄なファイルを削除しろ」という万年化したローテーションメールを送るよりも、厳しいフォルダ容量制限により、部門単位、個人単位のデータ保存コストが計算され、ITに必要な運用経費の分析と計画化ができます。

- Kanaka for Macintosh 3.0.1 -

kanaka for mac は

- kanaka Engine による、ファイルサーバー上のデスクトップの自動再構築

- eDirectory によるシングルサインオン

- eDirectory パスワードの変更

などの機能を Mac Client に提供するものです。設定は結構面倒なので、ここでは紹介だけしておきます。

- インストール -

このサーバーは SLES12sp2 ベースで動作しており、既に eDirectory, NSS, iManager, OES for CIFS と言った基本コンポーネントはインストール済です。

ここでは OES2018 側からインストールします。X 環境から　GUI版ｃ YaST2 を起動します。

# yast2 &

"OES Install and Configuration"

"Novell AFP" をチェック

Acceptしてインストール、時間がかかります。

終わると NovellAFP Services が未設定なので赤線です。eDirectory スキーマの拡張やプロクシオブジェクトが必要です。

Novell AFP Services をクリック

ログインダイアログからadmin パスワードをセットしてスキーマを拡張します。自動的にプロキシオブジェクトも作成されます。

赤線が消えました。Next

しばし時間がかかります。

時間がかかるので、"Clone ..... Auto YaST" のチェックは外した方がヨカッタ（ついチェック付けたままFinish してしまったのでその間お茶にする：敗因）

任意のクライアントのブラウザから、"https://latest_server_ip or DNS_name/nps/ " を開きiManager にログインします。

Role & tasks から "Protocol" > "AFP" を開きサーバーオブジェクトをブラウズして開きます。Status が既に running になっています。

Volume タブから Add ボタンを押して、共有するボリュームをeDirectory から選び、必要に応じて　Share 名を付けます。

context タブからAdd ボタンを押してeDirectory の中の　AFPアクセスを許可するユーザ、ユーザグループ、またはユーザコンテナを選びます。

※ ここで指定するコンテナは、実際にアクセスが必要なユーザが存在するコンテナです。eDirectory の Master か R/W レプリカが必要です。

- それではアクセスしてみましょう -

Finder から「移動」> 「サーバーへ移動」

「サーバーアドレス」”afp://server_Ip_or_DNS_Name” をセットしてログインします。macOS High Sierra の場合、プリフィクス afp://～を付けない場合、SMB 接続するそうです。プリフィクスは afp://～でも cifs://～でも smb://～のいずれでも構いません。古い macOS の場合は afp://～を付けるのが無難な様です。