人気ブログランキング |

どこのニュースサイトにも取り上げられず、ひっそりと Micro Focus Open Enterprise Server (OES) 2018 SP1 (俗に NetWare の最新版)が出荷されていました。まだOESの事を NetWare だと信じている顧客や、SIベンダーがいる事が信じられない。あの青い管理ツール類や IPX なんてプロトコルはもう完全に過去のものです。

評価版を入手したので密やかにインストールしてみました。

リリースノートはこちら

OES 2018 SP1: Release Notes

インストール全体は SUSE Linux Enterprise 12 の流れに準じています。この記事を参考にしてください。ここでは SUSE のインストール作業を基に、異なる点を主に取り上げてみます。

SUSE Linux Enterprise 12 SP3 (SLES12sp3) のインストール

先代の OES2018 SPなしと、ほぼ同じ流れですが、コスメティックなデザインがかなり変わってしまったので、なんだか違うシステムをインストールしている気分になります。

OES2018 既存 eDirectory へのインストール


ここでは、OES2018 のインストールのポイントとなる点を説明します。全体的なインストールの流れは動画で6分半ほどにまとめました(盛大に音出ます)




Boot ロゴから完全に Novell 色がなくなり、全面的に「デザインは青」です。カメレオンの様に良く色が変わるもんですね。

a0056607_11534063.png


SUSE と同居していた時代からの Customer Configuration Center です。ここでは評価版なので、"Configure Later" で。
もう NCC とは呼ばないのでしょう。

a0056607_11540854.png



SLES12 をベースにしていますが、/ (ルート) ファイルシステムは Ext4 を使っています。eDirectory データベースだけは /opt の下に作られます。SUSE 15 の KVM テンプレートでは12Gバイトが指定されていました。ルートパーティションは最低でも10Gb、多少考えて多めに 16Gb 程度あれば困ることはないでしょう。

a0056607_11543424.png

インストールサマリから "Software" リンクを開くと、OES の各コンポーネントがあるのが分かります。ここではまだチェックしないで、後でインストールします。

a0056607_11572057.png

後は、 SUSE Linux Enterprise 12 とほぼ同じ手順でインストールが行われます。ウィザードに従ってインストールします。



- 再起動後 -

さて、再起動後

インストールサマリで、起動時の systemd ターゲットに Text Mode を選んだので、再起動後はテキスト版 YaST が起動してきました。

ここでまずは eDirectory の固定IPを設定し、ホスト名を確定させます。ホスト名は、eDirectory オブジェクトになるため、命名基準に従って、 HOSTNAME をセットします。

SUSE Linux (SLES12)  YaST で固定 IP アドレスの設定をする

a0056607_11575891.png

自動起動した YaST で IPを固定し、ホスト名を決めたら、基本のセットアップは終わりです。

後に何十台もインストールするのであれば AutoYast のクローンを作りますが、普通は考えられないので、Auto YaST の Clone チェックは外しておきます。

YaST が終わると、HOSTNAME がテンポラリーなものから、指定したものに変わっています。

a0056607_12010942.png

# startx して、GUIを起動してみました。全面的にデザインが真っ青です。

a0056607_12025457.png



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

まずはNTPの準備をしておくと良いでしょう。

eDirectory では時刻同期がシビアなので YaST > NTP Server で事前に NTP の環境を設定します。eDirectory をインストールする途中でも設定できますが、途中確認ができないので、事前に確実に設定しておくことをおすすめします。


ここから eDirectory をインストールするのですが、事前に、eDirectory のヘルスチェックをします。特に時刻同期に問題があると、後でややこしいことになります。

# ndsrepair -T

で時刻同期 "Time is in Sync" の状態が Yes であること。

# ndsrepair -R

でエラーがなくなるまで、各サーバーのディレクトリサービスを修復しておきます。

a0056607_12031792.png

YaST2 > Software > View > Pattern から、OES のパッケージをチェックしてインストールします。通常ファイルサーバーだけであれば、 NSS のみチェックすれば、後は必要な eDirectory 関連のパッケージもインストールされます。

それでも iManager だけは最新のものを使いたいので、ディレクトリツリーの中で、できればディレクトリパーティションの3台程度のサーバーに iManager をインストールする事をお勧めします。"iManager" もチェックしておきました。

a0056607_12035165.png
これで、OES 2018 関連のパッケージは最低限インストールされます。

- eDirectory のインストール -

YaSTの "OES" グループの中の ”OES Installation and Configuration” を起動して、セットアップを行います。

a0056607_12070330.png

インストールは必ず "Custom" で、

a0056607_12054622.png
はじめの1台目ではないので ”Existing Tree” を選び、ツリー名をセットします。

a0056607_12074720.png
レプリカがあるサーバーの IP アドレスか DNS 名をセットし、既存のツリーの Admin 名とパスワードをセットします。レプリカサーバーは R/W レプリカでも構いませんが、マスターレプリカを保持するサーバーを指定するのが定石です。

cn=admin,o=MyOrg の区切り文字は、ピリオド(.)ではなくカンマ(,)です。

a0056607_12081151.png

次の画面でサーバーをインストールするコンテナを "Browse" して、セットします。デフォルトのままだと、o=MyOrg が小間物屋の様にオブジェクトが並ぶ、お祭り状態になるので、必ず下位の OU のどこか適切なコンテナを選んで設定します。ユーザ管理と、インフラ管理が異なる担当である場合、サーバーオブジェクトをインストールするコンテナは、ユーザコンテナと別コンテナの方が、役割分担の上で重要になります。

a0056607_12083800.png


サマリを確認してインストールを開始します。綴りが間違っているとか、インストール先コンテナが適切か、他のサーバーの eDirectory のヘルスチェックは問題ないか、よく確認して "Next"

a0056607_12091069.png


eDirectory サービスのインストールが開始されます。レプリカサイズにもよりますが最低10分以上かかります。

a0056607_12095188.png



インストール中に ndstrace コンソールで dstrace の sync 同期進捗状態を確認すると良いでしょう。

# ndstrace

NDStrace : set dstrace=+sync

a0056607_12102158.png

最初は、オブジェクトがないため、エラーが出てきますが、赤いエラー状態から、だんだんと同期が完了して、内容に緑が増えてきたら、大体終わりに近づいてきます。

ndstrace を実行したコンソールは必ず

NDStrace : exit

してシェルプロンプトにもどしておきます。NDStrace 起動中に ×ボタンで閉じてはいけません。ndstrace がゾンビ化して、最悪再起動が必要になります。

a0056607_12102158.png

終わったようです。 Auto YaST の Clone のチェックは外しても構いません。

a0056607_12134817.png

- iManager のデザインが変わった -

それでは、ブラウザから、サーバーの IP or DNS 名を URL に設定して、セキュリティ例外を受け付けて iManager を開きます。

早速ログイン画面のデザインが大きく変わりました。一瞬「間違ったか!」「新手のエラーか?」と心臓に悪いと思える位にドラスティックに変わってしまいました。

a0056607_12153200.png

以前のバージョンでは "NetIQ iManager" だったのに、"Micro Focus iManager" に名前が変わりました。デザインの変更はコスメティックですが、あまりの印象の違いにかなり戸惑います。

a0056607_12160266.png

"Object"タブからサーバーをインストールしたコンテナを開き、サーバーが見えるかどうか確認してみました。

ユーザ、グループのアイコンが真っ白です。インストールに失敗したか、と思った位ですが、どうもこのデザインで正常なようです。どうも新手のバグかという位に心臓に良くない。お客さんから「iManager のアイコンが変だ!」とクレームがきそうですが、これで一応正常です。

a0056607_12163721.png
設定言語を Japanese にすると、日本語化されています。怪しい中華製品によくあるような、不自然な日本語ではありません。

a0056607_12183082.png
一応、バージョンを確認します。 SLES12 SP3 ベースです。

a0056607_12184979.png



- インプレッション -

Micro Focus から SUSE がスピンアウトして、最初のバージョンという事もあり、デザインの大幅な変更には驚かされました。ある意味、完全に Novell 色(赤) から、青を主体にすっかりデザインが変わってしまったことは、何ともなぁ、時代だなぁという寂しさを感じました。

ただインストール作業そのものは別に違和感がなく、デザインの変化というコスメティックな変化ばかりが目立ちます。

また、SLES のバージョンが現行 15 なのに、なぜ SLES12 SP3 なのかというのも気になります。正直、SLES12 より SLES15 の YaST の方が使いやすいしデザインもフレンドリーなので、ちょっと残念。まぁ、 SLE 15 はかなりインストーラが変わったので、OESのインストーラをフィットさせるのは面倒だったのでしょう。デザイン変更という安易な更に走った点は、「変化」を痛感させてくれますが、基本機能が変わるものでもないし、機能アップした、という点もないのでまぁこれで正解なのでしょうね。

インストール作業中に微妙にバグっぽい不安定な部分があったことも報告しておきます。

リリースノートを見る限り、Business Continuity Cluster (BCC) や Cloud Integrated Storage (CIS) と言った謎の機能が追加されたり、CIFS,NSSといった基本コンポーネントの機能、性能アップが書かれていますが、主要機能の変更は少ない様です。基本的に OES はファイルサーバー、プリントサーバー、ディレクトリサービスが主要な機能ですから、こう言った目に見えない部分のチューンアップは行われているのでしょう。新しい機能に飛びついていた平成前期と違い、今は令和の時代。顧客はバカではないですから、取ってつけた様な機能は、どうせ iFolder の様にスピンアウトした後は消滅してしまうので私には食指が動きません。

むしろ、eDirectory を使ったクラウドサービスや、iFolder を使ったスマートフォン、タブレット等との連携。サブスクリプション購入客は GroupWise のクラウドサービスを無償で使えるとか、そう言ったビジネス的な変更とマイグレーションの方が顧客受けするのではないのかな、と思います。製品一つのバージョンアップだけでは顧客は喜びません。もっと OES ファイルサービスという知的財産をクラウドと連携して、サービス化すべきではないでしょうか。

OES はサーバー数、CPUやソケット単位のサブスクリプション、販売単価ではありません。

サーバー数無関係な eDirectory のユーザオブジェクト単位のサブスクリプションなので、(結構高いけど)購読中は追加投資なく台数無制限でサーバーの追加ができるので、ファイルサーバーの台数が必要な大規模顧客には有利でお得な料金体系です。










by islandcenter | 2019-05-24 12:39 | OES Linux | Comments(0)

Kanaka for Mac は Microfocus/Novell の OES ファイルサーバーを Mac に最適化されたファイル共有サービスを提供するアドオン製品です。OES のサブスクリプションを購入した場合、kanaka for Mac もサブスクリプションの対象となります。

ここでは kanaka for Mac の kanaka client.app アプリケーションを中心に導入方法をチェックしてみます。
ちなみに、kanaka client.app は動いたのですが、マニュアル通りに機能を発揮しなかったので、参考までにしてください。
必ずしも Mac ユーザのファイル共有サービスだけのためには不要です。

マニュアルはこちら

Micro Focus Kanaka for Mac 3.0.1 Installation and Administration Guide

前回までの作業

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

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

kanaka for Macintosh 3.0.1 を Microfocus OES Linux ファイルサーバーへ導入

- Kanaka Client.app と Kanaka Plug-in -

- Kanaka Client.app は、eDirectory で管理された複数の OES ファイルサーバーの認証を一元化します。
- Kanaka Client.app は、eDirectory ユーザのパスワードポリシーに従って、ログインパスワードを管理する手段を提供します。
- Kanaka Client.app は、eDirectory Login Script を処理し、必要な共有ボリュームをデスクトップにマウント(するらしい、出来なかった .... )

- Kanaka Plug-in は、Mac のログオンと同時に eDirectory ログインを処理します。ただし、この機能はモバイルユーザには不都合があると思いますので、Mac Book には導入を避けた方が無難なようです。 Mac Pro や iMac など、常時構内 Lan 接続を行う場合は、慎重に検討したうえで導入します。この記事では、省略しています。

- Kanaka Client.app の導入 -

Microforcus Kanaka.iso の中の Client > Microfocus_kanaka_XXX.dmg ファイルを開き Kanaka Client.app をアプリケーションフォルダにドラック&ドロップします。

a0056607_14593132.jpg

- Kanaka Client.app の起動と使い方 -

アプリケーションフォルダのKanaka Client.app を開きます。

”Login" ボタンからログインします。

サーバー IP とPort No. 3089 をセットしログイン

a0056607_15004980.jpg

できませんでした。"Failed to connect to server xx.xx.xx.xx on port 3089. Result=1" SSL の証明書エラーです。

a0056607_15011467.jpg

さてマニュアルを見ると、更に面倒な作業を行わなければならないようです。

Generating Certificates

つまり、サーバーにあるCA 認証局のサーバー証明書をインポートしなければならないのです。Kanaka Engine をインストールする際にexport した cert.pfx ファイルが必要です。

kanaka for Macintosh 3.0.1 を Microfocus OES Linux ファイルサーバーへ導入

Keychain access.app を立ち上げてcert.pfx をドラッグ&ドロップします。

a0056607_15021520.jpg

この状態では、まだサーバー証明書が信頼されていないため、Organization CA とサーバーIPの表記がある証明書の右ボタン「情報を見る」から「信頼」の「この証明書を使用する時」 > 「すべて信頼(always trust)」に変更します。

a0056607_15025264.jpg

※このキーチェイン.app の一連の作業で、cert.pfx をエクスポートしたパスワードMac 側の管理者パスワードが必要です。本来、管理を厳重にすべきサーバー証明書なので、安易にエンドユーザに渡すモノとは思えません。ご意見があればコメント下さい。

無事ログインできました。パスワード変更アイコンを開けば、ユーザはMac 側からeDirectory パスワードを変更できます。

a0056607_15032713.jpg

ただし、ここでは、eDirectory ログインスクリプトは動作せず、ボリュームステータスをチェックすることもできませんでした。(負けた....)

ここまでの作業では、一応、ユーザパスワードの変更が、Kanaka for Mac で出来る、という事までは確認できました。

--

ということで、この記事は書き換える可能性があります。

Kanaka Client.app 自体のインストールは Mac おなじみのドラック&ドロップで済みましたが、サーバー証明書をインポートする時に、エクスポートしたサーバー証明書ファイルとパスワードが必要になるなど、パッと配ってお終い、と言う訳には行かない様です。まだ未成熟なところを感じました。

また、マニュアルにあるようなボリューム管理、ボリュームマウントが出来なかったため、これはまた機会を改めて報告したいと思います。

















by islandcenter | 2018-04-18 15:05 | OES Linux | Comments(0)

前の記事

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

OES 2018 Linux eDirectory+NSS での CIFS ファイルサーバー

前回は、Microforcus/Novell Open Enterprise Server (OES Linux) を使った CIFS/AFP による、Windows/Mac 用、「ファイルのゴミ箱化」させないファイルサーバーの構築手順を説明しました。

ここでは、 OES 2018 に付属の kanaka for mac 3.0.1 を使った、Macintosh ファイルサーバーのバックエンドの導入方法を説明します。

- kanaka for Mac 3.0.1 -

kanaka for Mac は

- バックエンド、サーバー側で動作し、 Mac クライアントに最適なサービスを提供するkanaka engine]
- Mac フロントエンドで動作し、macOS のログインからedirectory へログオンさせるkanaka plugin.
=Mac フロントエンドで動作し、macOS デスクトップから eDirectory ユーザのパスワード管理, OES ボリュームをチェックする kanaka Desktop

の3つのコンポーネントから構成されます。ここでは kanaka engine の構成方法を説明します。

マニュアル、概要、入手先はこちらです。。

Micro Focus Kanaka for Mac

Manual

Download

なお、ドキュメントにあるように、kanaka for Macintosh は OES 2018 のコンポーネントの一部として OES のサブスクリプションを購入することで Novell のテクニカルサポートを受ける事ができるようです。

ダウンロードしたファイルは ISO 形式です。中身から kanaka-engine の rpm を取り出します。

MicroFocus-Kanaka_3_0_1.iso microfocus-kanaka-engine-3.0.1-3.x86_64.rpm

- Engine のインストール -
oes2018a:~/ISO/kanaka # rpm -i microfocus-kanaka-engine-3.0.1-3.x86_64.rpm
Adding microfocus-kanakaengined to the list of services at startup...done.
Micro Focus Kanaka for Mac Engine successfully installed.

To configure the Micro Focus Kanaka for Mac Engine, run the microfocus-kanakaengine-config utility.
Refreshing microfocus-kanakaengined for systemd...done.

- エンジンの設定 -
oes2018a:~/ISO/kanaka # microfocus-kanakaengine-config
Resolving current hostname...
Micro Focus Kanaka for Mac Engine Configuration
Please fill in the following required fields:

Current Data Path: /var/opt/microfocus/kanaka/engine/data
New Path-> [Enter]
Current Address: [Enter]
Select new Engine address:
[0] 192.168.1.211
Selection->
Invalid selection.
Selection->0 <-- そのままでいいので"0"
Engine HTTP Port [0] : 0
Engine HTTPS Port [3089] : [Enter]

[S] Set Server Address
[C] Clear Server Address
Hit [Enter] to accept current address
[oes2018a]:
The service cannot be started before a certificate is copied to /etc/opt/microfocus/kanaka/engine/config/server.pem
------------------------------------------------------------------------
Micro Focus Kanaka for Mac Engine Service Config
------------------------------------------------------------------------------
Data Path: /var/opt/microfocus/kanaka/engine/data
Engine Address: 192.168.1.211
HTTP Port: 0
HTTPS Port: 3089
Default NCP Server Address: oes2018a
Debug Level: 5

------------------------------------------------------------------------------
[D] Data Path [E] Engine Service
[N] Default NCP Server Address [O] Debug Options
[S] Service Management [Q] Quit

-----------------------------------------------------------------------------
Micro Focus Kanaka for Mac Engine Service Config
------------------------------------------------------------------------------
Data Path: /var/opt/microfocus/kanaka/engine/data
Engine Address: 192.168.1.211
HTTP Port: 0
HTTPS Port: 3089
Default NCP Server Address: oes2018a
Debug Level: 5

------------------------------------------------------------------------------
[D] Data Path [E] Engine Service
[N] Default NCP Server Address [O] Debug Options
[S] Service Management [Q] Quit


サービス管理をしようと[S]を押してみました。

Selection->S

NOTICE: The certificate file does not exist, and the microfocus-kanakaengined cannot be managed.
Please refer to the documentation for instructions.
Press any key to continue.
怒られたので仕方なくquit
Selection->q

NOTICE: The certificate file does not exist, and the microfocus-kanakaengined cannot be started.
Please refer to the documentation for instructions.

oes2018a:~/ISO/kanaka #


マニュアルによると


When are asked if you want to restart the service, do not do so until completing Step 13.
Copy the PEM file that you created in Step 9 to the following location:
/etc/opt/microfocus/kanaka/engine/config
Restart the service by selecting Y.


次の手順で cert.pfx を取り出して、 server.pem に変換する必要があるようです。

Generating Certificates

Exporting an eDirectory Server Certificate#
Depending on usage, choose to export the DNS or IP certificate for the Open Enterprise Server that hosts the Kanaka Engine. If Kanaka clients are configured with the DNS hostname of the OES server, you should export the DNS AG <server DNS hostname> certificate. If Kanaka clients are configured with the IP address of the OES server, you should export the IP AG <server IP address> certificate.

Log in to iManager.
From Roles and Tasks, click NetIQ Certificate Access.
Click Server Certificates.
Select the certificate for the OES server hosting the Kanaka Engine.

iManager >Role & Tasks > NetIQ Certificate Access > Server Certificates > IP_AG_IP-Address をチェック。絵では、違うものをクリックしていますが... ご愛敬

a0056607_13304145.jpg

Click Export.

From the Certificates drop-down menu, select the certificate that you checked in Step 4.
Leave Export private key selected.
Leave Include all certificates in the certification path if available selected.


Certificate の右横のトグルボタンを押して

Certificate private Key > IP AG xx.xx.xx.xx にトグル

a0056607_13314183.jpg

Enter a password to protect the private key.(後で使います。任意です。覚えておくこと)
This is required when Export private key is selected.
Click Next.
Click Save the exported certificate.

a0056607_13320817.jpg

The file is saved to your Downloads folder with the name cert.pfx.

3.5.3 Convert a PKCS#12 Certificate to a PEM Certificate#

iManager exports server certificates in the PKCS#12 or PFX format. This format needs to be converted to PEM format for the Kanaka Engine. You can use one of the following two methods to do so:

microfocus-kanakaengine-convertcert#
Copy the cert.pfx file to the OES server hosting the Kanaka Engine.


- サーバー証明書を kanaka Engine に登録 -

- List -

oes2018a:~ # cd kanaka
oes2018a:~/kanaka # ls
cert.pfx
oes2018a:~/kanaka #

--

In a terminal session on the OES server hosting the Kanaka Engine type:
microfocus-kanakaengine-convertcert
When prompted, enter the name of the certificate cert.pfx.
When prompted, enter the pass phrase that was used when the certificate was exported.
In this case, the pass phrase from Step 9 from Section 3.5.2, Exporting an eDirectory Server Certificate.
You are then prompted twice to enter a new pass phrase for the temporary key.
When prompted, re-enter the pass phrase you used for the temporary key in Step 4.

- List -

oes2018a:~/kanaka # microfocus-kanakaengine-convertcert
Enter path of certificate file in PKCS12 format and press [ENTER]: ./cert.pfx
Enter pass phrase for ./cert.pfx and press [ENTER]: password <- エクスポートした時のパスワード
Converting ./cert.pfx to PEM format...
Creating temporary certificate...
Creating temporary private key (/tmp/private.key)
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
Removing passphrase from temporary private key...
Enter pass phrase for /tmp/private.key:
Converted ./cert.pfx to server.pem
oes2018a:~/kanaka # ls -l
合計 16
-rw-r--r-- 1 root root 4915 4月 12 13:47 cert.pfx
-rw-r--r-- 1 root root 4308 4月 12 13:54 server.pem <--- 変換できました。
oes2018a:~/kanaka #
--

Stop the Kanaka Engine:
rcmicrofocus-kanakaengine stop
Copy the server.pem file:
cp server.pem /etc/opt/microfocus/kanaka/engine/config
Start the Kanaka Engine:
rcmicrofocus-kanakaengine start

- List server.pem のコピー -
oes2018a:~/kanaka # rcmicrofocus-kanakaengined stop
redirecting to systemctl stop microfocus-kanakaengined.service
oes2018a:~/kanaka # cp server.pem /etc/opt/microfocus/kanaka/engine/config/
oes2018a:~/kanaka # ls /etc/opt/microfocus/kanaka/engine/config/*.pem
/etc/opt/microfocus/kanaka/engine/config/server.pem
oes2018a:~/kanaka # rcmicrofocus-kanakaengined start
redirecting to systemctl start microfocus-kanakaengined.service
oes2018a:~/kanaka #
--

- List kanaka engine の再起動 -
oes2018a:~ # microfocus-kanakaengine-config
Resolving current hostname...
------------------------------------------------------------------------------
Micro Focus Kanaka for Mac Engine Service Config
------------------------------------------------------------------------------
Data Path: /var/opt/microfocus/kanaka/engine/data
Engine Address: 192.168.1.211
HTTP Port: 0
HTTPS Port: 3089
Default NCP Server Address: oes2018a
Debug Level: 5

------------------------------------------------------------------------------
[D] Data Path [E] Engine Service
[N] Default NCP Server Address [O] Debug Options
[S] Service Management [Q] Quit
Selection->q
If changes have been made to the configuration a restart maybe required.
(Re)start the service at this time? [Y/N]: Y
Unknown Status
Unknown Status
Checking for service Micro Focus Kanaka for Mac Engine ..running
● microfocus-kanakaengined.service - LSB: Micro Focus Kanaka for Mac Engine
Loaded: loaded (/etc/init.d/microfocus-kanakaengined; bad; vendor preset: disabled)
Active: active (running) since 木 2018-04-12 14:02:12 JST; 61ms ago
Docs: man:systemd-sysv-generator(8)
Process: 102300 ExecStop=/etc/init.d/microfocus-kanakaengined stop (code=exited, status=0/SUCCESS)
Process: 102318 ExecStart=/etc/init.d/microfocus-kanakaengined start (code=exited, status=0/SUCCESS)
Tasks: 15 (limit: 512)
CGroup: /system.slice/microfocus-kanakaengined.service
└─102328 /opt/microfocus/kanaka/engine/bin/microfocus-kanakaengined --daemon
Press [Enter] to continue
oes2018a:~ #
oes2018a:~ # ps ax | grep kanaka
102328 ? Sl 0:00 /opt/microfocus/kanaka/engine/bin/microfocus-kanakaengined --daemon
102416 pts/0 S+ 0:00 grep --color=auto kanaka
oes2018a:~ #

Configuring the Engine


https://kanaka_engine_IP:3089/ をブラウザで開きます

a0056607_13334362.jpg


スキーマを拡張します。

Click Next to extend the eDirectory schema.

a0056607_13340123.jpg

kanaka Proxy オブジェクト、Kanaka Administrator オブジェクトを作ります。

a0056607_13342733.jpg

ユーザインデックスを作るユーザコンテナを指定します。O=ORG を選び、"Serch All Subcontainers ...." を選ぶと、サブツリー全体のユーザインデックスを構築します。

a0056607_13345510.jpg

この下にインデックスリビルドを実行する時間のチェックリストが出てきます。デフォルトで午前1時がチェックされています。ネットワークの負荷が少ない時間帯を選べという事なので、未明の時間が良いでしょう。

In the Rebuild Times region, specify the hours when you want Micro Focus Kanaka for Mac to rebuild the index.
You should choose an hour when there is minimal network activity
kanaka engine をリスタートします。
oes2018a:~ # rcmicrofocus-kanakaengined stop
redirecting to systemctl stop microfocus-kanakaengined.service
oes2018a:~ # rcmicrofocus-kanakaengined start
redirecting to systemctl start microfocus-kanakaengined.service
oes2018a:~ # rcmicrofocus-kanakaengined status
Checking for service Micro Focus Kanaka for Mac Engine running
● microfocus-kanakaengined.service - LSB: Micro Focus Kanaka for Mac Engine
Loaded: loaded (/etc/init.d/microfocus-kanakaengined; bad; vendor preset: disabled)
Active: active (running) since 木 2018-04-12 15:01:37 JST; 8s ago
Docs: man:systemd-sysv-generator(8)
Process: 103809 ExecStop=/etc/init.d/microfocus-kanakaengined stop (code=exited, status=1/FAILURE)
Process: 103833 ExecStart=/etc/init.d/microfocus-kanakaengined start (code=exited, status=0/SUCCESS)
Tasks: 28 (limit: 512)
CGroup: /system.slice/microfocus-kanakaengined.service
└─102328 /opt/microfocus/kanaka/engine/bin/microfocus-kanakaengined --daemon
oes2018a:~ #

一旦ブラウザを閉じて、開きなおすと kanaka Console が起動しました。

a0056607_13351946.jpg



"User Index" より "rebuild Time" の指定ができます。デフォルトでは午前0時に自動実行されます。

a0056607_13353808.jpg

kanaka によってDesktop.Afp (隠しファイル)がrebuild されます。

a0056607_13355677.jpg



by islandcenter | 2018-04-16 14:34 | OES Linux | Comments(0)

このテーマの続きです。

OES 2018 SP1 Install ファーストインプレッション

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

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

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

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 時代から標準で付いてくる機能なので、20年以上の長い歴史と実績があるファイルシステムです。

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版c YaST2 を起動します。

# yast2 &

"OES Install and Configuration"

"Novell AFP" をチェック

a0056607_14362794.jpg

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

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

a0056607_14391449.jpg

Novell AFP Services をクリック

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

a0056607_14414497.jpg
赤線が消えました。Next

a0056607_14433235.jpg


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

a0056607_14441152.jpg

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

a0056607_14445507.jpg

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

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

a0056607_14464990.jpg

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

a0056607_14482921.jpg

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

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

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

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

a0056607_14595051.jpg

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

a0056607_15005095.jpg


eDirectory のユーザ名:パスワードでログインします。

※ macOS X の場合 Microfocus/Novell CIFS の設定を行った場合、 smb://~ でも cifs://~ でもボリュームをマウントできます。

共有ボリュームをマウントすると、[SRWCEFMA] のトラスティの、最低"F" 権があるディレクトリ、フォルダのみ表示されます。 他のユーザの "HOME" ディレクトリは見えません。(隠しフォルダではなく、クライアント側からは全く見えないのです)

a0056607_15013546.jpg

フォルダに容量制限(ディレクトリクォータ)がかかっているため

a0056607_15041224.jpg

大きなファイルはコピーできません。

a0056607_15053661.jpg

”別名で接続"ボタンを押してセッションを切り

a0056607_15465987.jpg


別なアカウントで接続します。

a0056607_15474675.jpg


これで、Microforcus/Novell の OES 2018 Linux の AFP サービスの設定は終わりです。

この後 Kanaka Engine を設定します。

続き

kanaka for Macintosh 3.0.1 を Microfocus OES Linux ファイルサーバーへ導入


- Key Word -

Linux,Mac,フォルダ容量制限,利用制限,ディレクトリクォータ,共有ファイルサーバー

by islandcenter | 2018-04-13 15:23 | OES Linux | Comments(0)

関連記事

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 Guide

Installing CIFS after the OES Installation

- Novell CIFSの実装 -

yast2 > OES Configuration から CIFS をチェックして Accept.

a0056607_13031180.jpg
Novell CIFS Services の行に未設定の項目があるのでクリック

a0056607_13042762.jpg

admin.org のパスワードをセット、これによりスキーマの拡張が行われます。

a0056607_13065030.jpg

サーバーコンテナだけ選択されているので、O=MyOrg を Add して、” Enable Subtree Search” をチェック

a0056607_13071189.jpg
Next

赤線が消えたので Next

a0056607_13073027.jpg

Next

5分待つ

インストールできました。

※ "Clone ..... AutoYaST" のチェックは外しても構わない。というより AutoYaST は滅多に使わないので、チェックを外すべきでした(敗因)

a0056607_13080250.jpg
AutoYaST のクローニングをする場合は5分くらいかかります。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 プラグインをインストールします。

a0056607_13082813.jpg

iManager > File Protocol > CIFS を選び、plug-in が動いていることを確認。

デフォルトで CIFS 名=ホスト名になっています。OES_CIFS とか WorkGroup_NAS とか任意に名前を変えてアナウンスを流すと良いでしょう。

この画面から Stop/Start して再起動もできますが

# rcnovell-cifs restart

でもリスタートできます。

a0056607_13091113.jpg
ユーザーコンテキスト > O=org からサブツリー全体に割り当てられています。

a0056607_13094033.jpg
CIFS アクセスには Universal Password(デフォルト無効)が必要です。

CIFS and Universal Password

Universal 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 単位でしかポリシーを定義できない製品と違い、複雑な組織によって、ポリシーを使い分ける事ができます。


ウィザードに従い新しいパスワードポリシーを作ります。

※ Password Policy は [root] の "Security" コンテナに作成されます。

a0056607_13102031.jpg

"Would you like to enable Universal Password" はデフォルトのまま Yes

a0056607_13111127.jpg
特にパスワードポリシーを変更しなければ、デフォルトで構いませんが、パスワードポリシーとして、複雑なパスワードを要求したり、定期的なパスワード変更を求めるパスワードポリシーが必要であれば、カスタマイズできます。

パスワードポリシーを使用したパスワードの管理

a0056607_17014493.jpg

そのままウィザードを進め Finish したら、"Assignment" にユーザーオブジェクトそのもの、もしくはユーザのコンテナを指定します。ただし、指定したオブジェクトのサーバーは eDirectory のコンテナ R/W レプリカ を保持している必要があるようです。NetWare3 互換の Bindery Connection と同じです。

a0056607_13115485.jpg

※ もっとも、ここで新しいポリシーを作らなくても、既にある "Common Proxy Policy" にユーザを割り当てても構いませんでした。(敗因)

これで、一応、OES 2018 CIFS は設定完了です。

ネットワークに見えました

a0056607_13123490.jpg

ここでサーバーをクリックして、認証ダイアログが出ない場合、あるいは eDirectory パスワードが受け付けられない、ログイン認証できない場合は、パスワードポリシーがユーザに適用されていないことによります。

※ このダイアログでは "CN=user_name,OU=Users,OU=Tokyo,O=ACE" と言った、パス付の FDN ( Fully Distinguished Name ) のユーザ名がログインに使えないので、ユーザオブジェクト、またはユーザが存在する、ユーザコンテナをパスワードポリシーに直接アサインしておく必要があるわけです。また、サーバー自身に eDirectory のユーザコンテナのマスターか、R/Wレプリカデータベースが必要です。

Synchronizing NMAS Login Methods Is Required to Avoid Login Failures

ボリュームを開くと NSS のトラスティが利いています。

a0056607_13125748.jpg

フォルダに容量制限(ディレクトリクオータ)をかけてみました。

サーバーをゴミ箱にしない工夫


OES のディレクトリ容量制限、クォータ機能の注目すべき点は特別に複雑な操作も行わずに、どれだけ複雑なディレクトリ構造、ファイル容量であっても、 OES Client のプロパティか、iManager のフォルダプロパティから、運用中、稼働中に一瞬で数クリックで制限ができる事です。

a0056607_12033560.jpg



net use

で確認して

> net use /delete \\server\share

しても繋がっている?

これが CIFS/SMB のおせっかいなユーザにもハッキングにも優しい余計なお世話。

ログオフなしでファイルサーバーとのセッションを切断するには

CIFS のテストで、ログイン、ログアウトを繰り返す場合

C:\> klist purge

によって Kerberos チケットを削除します。 また CIFS の怪しい仕様で、NSSボリュームに与えた、ファイル/フォルダのトラスティが安定するまで、かなり不安定な動きをします。トラスティを与えたフォルダアクセス権限をネットワークにアナウンスするまで、変なタイムラグや、クライアントやサービスをリブートするなどの「ひと変化」が必要なんですね。このような CIFS の "仕様上の問題点" は解決できません。やっぱり OES の NSS ファイルシステムをクレームなしで使うには、OES Client for Windows を使った NCP プロトコルによる接続を推奨するしかありません。

a0056607_13133842.jpg

- インプレッション -

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)

OES 2018 が出荷されたようなので、評価版を使ってみました。

全体の流れは従来の SLES12 + OES アドオンのインストールと同じ流れです。ここでは全体の流れと雰囲気をお伝えする目的なので、詳細は Micro Focus/Novell のマニュアル、ドキュメント等をご参考ください。

What’s New or Changed in OES 2018

このバージョンから Novell -> Micro Forcus へとブランド名が変わっています。
そこで、従来の様に SLES+OES addon 形式で配布されていた電子メディアイメージが OES(IncludeSLES12) の1枚もののDVDイメージで取得できます。

前のバージョンから Mac 用に AFP もサポートされ、連携強化のため Micro Focus Kanaka for Mac 3.0.1 も同時にリリースされています。

今度 Mac を買ったときにでも評価してみたいと思います。


評価用電子メディアのダウンロードはこちら

無料登録の Novell ID が必要です。

--

インストール

今回は、細かな内容を追わず、全体のデザインの違いや流れを追ってみます。

事前に DNS に

- サーバー名 : A:サーバーIPアドレス
- CNAME: ツリー名: サーバー名

を定義しておきました。

DVD ブート

ブートスクリーンから Novell と SUSE のブランドロゴがなくなり Micro Focus ロゴです。
a0056607_14093737.jpg

デフォルトファイルシステムは SLES12 ベースですが、 EXT4 です。

a0056607_14095645.jpg

Expert Partition Setting で / に10Gバイト、残りはNSS用に空けておきます。(敗因) - NSS は /(ルート)と swap がある物理ディスクとは別なデバイスでしか作れません。最小限で / ( ルート)パーティションは最低4Gバイト必要な様ですが、何かと必要なので10Gから16G程度あれば十分でしょう。NSSボリュームは別な物理ディスクや iSCSI SAN を使うのがベターです。通常、今時は仮想化運用でしょうから / パーティションに使うディスクイメージは10G程度から16G程度与えます。

a0056607_14101296.jpg

Install Summary から "Software" を開きます。Open Enterprise Server のコンポーネントは未チェックです。

a0056607_14111905.jpg

Domain Service for Windows や AFP などが追加されてます。後からインストールします。


インストーラの画面にもちょっと Microforcus アレンジが入っています。インストール手順は SLES12 のインストール手順そのままです。

SUSE Linux Enterprise 12 SP3 (SLES12sp3) のインストール


a0056607_14121843.jpg
ただしこの時点で SLES12 base をインストールする場合の XNE/KVM/virtual の選択がないので、基本的にはベアメタルサーバーか、仮想化環境下で動作させることになります。つまり HyperVisor OS は別に用意するという事ですね。

再起動後、CUI 版 yast が起動します。ネットワークの設定とホスト名、DNS名を固定します。

a0056607_14132775.jpg

今回は systemd の起動は text モードにしましたが、startx を実行すると、デスクトップスクリーンが確認できます。

a0056607_14134697.jpg

思いっきり Micro Focus の壁紙ですね。


yast のデザインはそのままです。中に OES Installation と Configuration ユーティリティのアイコンがあります。

a0056607_14140561.jpg

SUSE のベースバージョンは 12sp2 です。

a0056607_14142530.jpg

一度再起動して、 HOSTNAME を書き換えます。

OES Install & Configuration を開きます。YaST > Software Configuration のままですね。

a0056607_14144413.jpg

今回は基本的な機能として Novell Storage Service(NSS) と iManager を選びます。

a0056607_14153310.jpg

OES のインストールが開始されます。

インストール方法は "Custom" を選択します。

a0056607_14155803.jpg

SLP の設定、デフォルトのまま、警告を無視して accept

a0056607_14324971.jpg

NTP の設定です。何も設定がない場合はここで設定できますが、できればOES アドオンをインストールする前に設定すべきでしょう。

SUSE Linux (SLES12) を YaST で NTP の設定

a0056607_14514090.jpg

ディレクトリツリーの設定:

本来であれば既存のツリーに接続させますが、ここではテスト環境なので New tree : "ACE-tree” を作成します。

ツリーに追加する場合はこちらを参考にしてください。
OES 2015sp1 の既存ツリーへのインストール
a0056607_14172466.jpg
管理者 admin の設定です。ここで o=xxxx は最初の 組織オブジェクト(Organization) です。.admin,o=ace の間はドットではなくカンマで区切ります。パスワードは忘れないようにしましょう。テキスト端末を開いて、NUMロックや CAPSロックが押されていない事を確認しておくと良いでしょう。

a0056607_14180271.jpg

サーバーコンテナを設定します。デフォルトだと、o=xxxx 直下に作られるので、最初のディレクトリ設計に重要なポイントとなります。ここでは ou=System.ou=tokyo.o=ace を設定しました。サーバーやシステム関連のオブジェクトはツリー上のこのコンテナに作成されます。

a0056607_14183149.jpg
実際に作られた system.tokyo.ace のオブジェクトはこんな感じです。

a0056607_14414528.jpg
NMAS メソドはデフォルトのままOK

代理ユーザの設定、サーバーコンテナそのままでOK、パスワードはデフォルトのままです。

a0056607_14185546.jpg

サマリを確認します。

a0056607_14192728.jpg

eDirectory の構築が始まります。

a0056607_14194495.jpg

このプロセスはいつも時間がかかり、ヒヤヒヤします。大体20分から30分程度かかると思ってよいでしょう。


無事終わったようです。

a0056607_14203348.jpg


# ndsrepair -T
# ndsrepair -R

を実行して、エラーがないことを確認します。

a0056607_14210122.jpg

eDirectory Version は 9.0 です。8.x とは変わっていませんが細かなチューニングに変化があったのでしょうか。15年ぶりくらいのメジャーアップデートという事になります。

oes2018a:~ # ndsrepair -T
[1] Instance at /etc/opt/novell/eDirectory/conf/nds.conf: oes2018a.OU=system.OU=tokyo.O=ace.ACE-TREE
Repair utility for NetIQ eDirectory 9.0 - 9.0.3 v40005.13
DS Version 40005.13 Tree name: ACE-TREE
Server name: .oes2018a.system.tokyo.ace
Size of /var/opt/novell/eDirectory/log/ndsrepair.log = 3528 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, March 09, 2018 12:35:31 Local Time
---------------------------+---------+---------+-----------+--------+-------
DS Replica Time Time is Time
Server name Version Depth Source in sync +/-
---------------------------+---------+---------+-----------+--------+-------
Processing server: .oes2018a.system.tokyo.ace
.oes2018a.system.tokyo... 40005.13 0 Non-NetWare Yes 0
---------------------------+---------+---------+-----------+--------+-------
Total errors: 0
NDSRepair process completed.
oes2018a:~ #

http://ip-address (http://ip-address/nps)を開き、imanager が使えることを確認します。

a0056607_14220823.jpg

ブラウザの言語を "Japanese" にすると日本語表記が出てきます。

a0056607_14223143.jpg

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

a0056607_14231062.jpg

次に pools, Volumes でNSSボリュームを作成します。

iManager ではなく、テキスト端末から # nssmu ユーティリティで作成することもできます。

a0056607_14232659.jpg

ボリュームが作成されました。

a0056607_14234773.jpg

--
全体としては特に変わったところはないな、という感想です。ルートパーティションが BTrFs ではなかったり、すっかりロゴを含めて Micro Focus スタイルになってしまったのは寂しさも感じます。バージョンが変わるたびにUIやツールの使い勝手が変わる Windows と違って、変わらぬ機能と確実に不具合がなくなり、より必要な機能だけにフォーカスして、バージョンアップしていればよろしいわけで、変わらぬ安心感を感じます。

続き

OES 2018 Linux eDirectory+NSS での CIFS ファイルサーバー

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

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


Novell Openenterprise Server, Linux, SUSE, NSS, ファイルサーバー,



by islandcenter | 2018-03-10 14:43 | OES Linux | Comments(0)

あわせて読みたい

Novell OES Linux ファイルサーバーをファイルのゴミ箱にしない工夫

OES 2018 Linux で SMB ファイルサーバーのフォルダ容量制限(ディレクトリクォータ)

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

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


ファイルサーバーが常に抱える問題-ファイルサーバーはファイルのゴミ箱

部屋の中は、不要なもので一杯、ここで断捨離しなければ、と思いつつ、つい要るもの要らないものがブックシェルフに混在しているのが、私たちの暮らしなのですね。これが大家族なら、オカぁちゃんが「これ捨てるよ」と言っても、「いやぁだぁー」と子供に泣かれると困ってしまう。間違って捨ててしまうと晩飯も「食べたくねぇ」とゴネられます。

という事で、本棚にはよく読む本を置いておき、押し入れには、読むことはないけれど、時々必要になって引っ張り出してくる捨てられないデータというモノがあるんですね。子供のころのアルバムだとか、学校の卒業写真、人生でたった一度だけ取った英語の100点満点のテスト、先祖が残した貴重な資料。まそんなところでしょうか。

同じ事が、企業の中のファイルサーバーにも当てはまるわけです。ある調査では、サーバーの中の30%のファイルは「死んでるデータ」だそうです。

機械的に、「生きているデータ」「取っておきたいデータ」「死んでるデータ」「不要なデータ」と区分けして断捨離するのはシステム管理者としてできない事。実際のファイルの重要性の判断は、エンドユーザがある程度行わなければいけないわけです。目に見える倉庫の棚や、本棚と違って、目に見えないファイルサーバーのストレージは「醜い」「汚い」「乱雑だ」という事には気が付かず、ファイル整理の判断は難しいものです。

ファイルの断捨離は、利用者が行うべきであり、管理者はそのテンプレートを作ってやることが仕事となります。エンドユーザには中々嫌われる業務になるかも知れませんが、机の中や目に見える限られたスペースしかない物理的なファイルキャビネットの整理と同じく、利用価値のないファイルの整理もユーザの仕事なのです。

Linux 管理者なら、「アーカイブ」というのは tar とかのコマンドでファイルを圧縮してしまう事なのですが、業務の中でどのデータが重要でアーカイブして保存しておくことが重要かの判断はなかなか付かないものです。しかもいったん圧縮した内容は解凍しないと利用できないのですから、ユーザ側からすると、「アーカイブしたの忘れてた」という事になります。ましてやテープなどの外部メディアにアーカイブとっても、実際にその中のアーカイブデータが利用できるまでの道のりは低いわけですね。外部メディアにアーカイブするのはあくまでも「アーカイブのバックアップ」を目的とすべきでしょう。

ファイルサーバーはつねに増大するストレージにより、永遠に問題を抱えています。
何しろ、最近ではPCはノートブックやタブレットが主流になり、128GbのSSDとかしか記憶容量がないのです。しこに20Tbもの巨大なファイルサーバーがあると、たとえそいつは100人で共用している事にも気が付かず、「じゃぁディスクを増設して C:ドライブ丸ごとバックアップ」なんて無法な事をするエンドユーザもいるのです。

エンドユーザには気にならないものですが、ファイル共有用ファイルサーバーというのは、単にディスク一つを追加増設するだけでも大変な作業で、バックアップとリストア、バックアップに必要なメディアの確保、という膨大な作業が必要となります。

そこで、契約書や保存期間が法令や社内基準で定められているファイルを保管し、アーカイブとすることで、通常の「読み書き可能な共有フォルダ」「読み出し専用のフォルダ」「特定のユーザは書き込みや削除、移動はできるが読み込みと書き換えのできないアーカイブフォルダ」を作る事を考えてみましょう。

OES Linux のNSSファイルシステム

他のファイル共有システムのように「読み込み専用」「読み書き自由」の2種類の属性しかないファイルシステムと違い、Microforcus/Novell Open Enterprise Server(OES Linux) の NSS (Novell Storage Service)では[SRWCEMFA] のファイル・ディレクトリのトラスティやフォルダの属性が豊富で、フォルダのディスク容量クオータ(ディレクトリ単位の容量制限)ができるので、豊富なトラスティと属性を合わせて容量制限が利いたアーカイブ専用のフォルダ・ディレクトリを簡単に作ることができます


iManager からの Archive フォルダのアクセス権限

まず、Archive 専用のディレクトリを作り、このフォルダの読み込みだけのユーザと、読み込み、書き込みはできないが、ファイルの移動や削除ができるユーザ、グループを作ります。

a0056607_11583794.jpg



エクスプローラのフォルダのプロパティから見た場合

a0056607_11591487.jpg


Sales グループユーザはファイルの読み込み[ R F ]はできますが、移動、作成、削除[ WCE M ]が許可されていません。

ArchiveManager のグループユーザは、ファイルの読み込み、書き換え[ RW ]は許可されていませんが、ファイルの削除、作成(コピーや移動、上書き)[ CEFM ]は許可されています

a0056607_12020591.jpg

a0056607_12175114.jpg



Sales グループのユーザはファイルの読み出しだけは許可されています。もし、Sales グループのメンバーは、普段使いのフォルダに作った「消さないでフォルダ」をアーカイブに移動させてもよいとするならば [ R C F ] の( create )権限を与えます。これにより、メンバーは「消さないでフォルダ」を「アーカイブに移動」させて、ArchiveManager グループメンバー以外は、削除したりアップデートできないようになります。

ただし、「ファイルの作成」はできても「削除、名前の変更」はできないので、誤ってこのフォルダで「新しいフォルダの作成」などを右クリックしてしまうと、当人には「削除できないフォルダ、ファイル」ができてしまいます。


一方、ArchiveManager グループのユーザはファイルやフォルダの作成、削除、移動は許可されますが、ファイルの閲覧、書き換えは許可されません。

条件は論理和ですから、両方のグループに所属している場合、[ w ] (書き込み)権がないだけなのでファイルの作成、コピー、削除、閲覧はできますが、ファイルの更新は許可されません。

ディレクトリ(フォルダ)のクォータ管理(容量制限)

ワークグループのディレクトリ(フォルダ)にはクオータ(容量制限)がかけられます。いくらファイルのセキュリティ機能があっても、フォルダのクォータ管理ができないと、狭い部屋(限られたリソース)にある、本棚はすぐに一杯になってしまいます。そこで、フォルダにクォータ(容量制限)をかけます。この作業は簡単で、システムが稼働中でも数クリックで設定され、即時有効になります。ある特定のユーザが大量のデータを作り、残りのメンバーはあまり使わない、というケースでもフォルダ容量制限が利いている限り、ユーザには関係なく、フォルダの容量制限が有効になります。

例えば、Sales フォルダには、外歩きであまりファイルを作らないユーザと、見積書の清書を行うアシスタントでは、作るファイルの量というのは違うという事です。ユーザクォータではこの様な気の利いた小回りができません。




OES Linux ファイルサーバーのディレクトリクォータ(フォルダの容量制限)

a0056607_12033560.jpg


例えば、普段使いのグループフォルダには10Gb、アーカイブフォルダには20Gbのクォータをかけておき、グループ作業用フォルダがクォータで満杯になった場合は、ArchiveManager グループに所属するユーザがグループフォルダから、アーカイブ専用のフォルダにファイルを移動させて、容量を開ける事ができます。

また、クォータが利いているアーカイブ専用フォルダがいっぱいになれば、まずファイルサーバーの中で参照されることがないだろうと思われるファイルは、光メディアやテープバックアップを行い、アーカイブの整理を行います。

また、容量制限がかかったアーカイブ専用フォルダは、普段あまり使われないファイルが多いという前提で、フォルダを作った時に「即時圧縮」の属性をつけておけば、ファイルの内容にもよりますが、 2~30% 程度は圧縮されるため、わざわざ ZIP 化したり tar.gz にする必要もありません。ファイルによっては、「ちょっと開くために時間がかかる」程度でユーザはファイルを開くことができます。

a0056607_12040924.jpg




「部外秘」のフォルダからは「権利継承」を削除する

「部外秘フォルダ」からは「権利継承」( Inherited Rights Filter ) から全ての権限を Revoke (はく奪)する事で、部外者からは表示されないようにします。
明示的に「部外秘フォルダ」に Trustee を与えない限り、ユーザやグループにはフォルダすら見えなくなります。

a0056607_12043162.jpg



このような感じでReadOnly フォルダ内の「部外秘フォルダ」自体が他部署では不可視になります。

a0056607_12044897.jpg


おまけ ポスト用フォルダ

Microforcus/Novell OES の NSS ファイルシステムでは、[ c ] 権だけのフォルダを作ることができます。このフォルダは、私は「ドロップボックスフォルダ」と呼んで位います。C権を与えられたユーザは、このフォルダにドラック&ドロップでファイルを保存する事だけはできます。しかし、フォルダを開いてファイルの読み書き、削除、変更どころか、フォルダを開く操作さえ拒否されます。つまり郵便箱( PostBox )のような使い方ができるわけですね。もちろんこの郵便箱を開いて中のファイルを収集するポストマンが必要なわけで、彼らにはファイルの移動、削除は許可されても、封筒を開封する(読み出し書き込み)権利はありません。

a0056607_12050356.jpg



例えば、健康診断などのセンシチブなデータのポスト場所や、学校の宿題の投函場所として使うことができます。一般ユーザは「春の健康診断」のPDF ファイルをポストして、ポストマンは、例えば「田中の健康診断データ.pdf」を「総務の投函場所に移動」させることはできるが、内容は読むことができない、という事になります。この場合、ファイルを読み書き可能なディレクトリにコピーしてしまえば読み書き可能なので、PostManager のアカウントは厳重に利用してもらう事になります。

--
ファイルサーバーは企業のシステムとしては実に原始的で、古くから利用されているシステムです。過去も未来も、「ファイルサーバーのゴミ箱化」は避けて通れない問題で、システムコストの数十%を無駄に投資しています。

OES Linux は NetWare 時代からの「専用ファイルサーバーOS」です。はるか昔から、ファイルのトラスティ、ディレクトリクォータなど、豊富なファイル管理機能を備えています。

ディレクトリクォータを厳しく設定し、フォルダの管理を「生きているファイル」「あまり使われないファイル」「ほとんど使わないが保管すべきファイル」「死んでるファイル」とランク付けし、フォルダのアクセス制限を設計してしまえば、後は利用者側が限られたリソースを有効に利用できるのですね。



ファイルサーバーゴミ箱化,ファイルのゴミ箱化,ディスク容量制限,フォルダ容量制限,フォルダクォータ,ファイルサーバーのゴミ箱化,死んでるファイル,必要なファイル,アーカイブが必要なファイル,Linux, Windows,ファイルサーバー

by islandcenter | 2018-03-05 12:09 | OES Linux | 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マウント









by islandcenter | 2017-11-14 14:25 | OES Linux | Comments(0)

ここでは Microforcus/Novell/NetIQ の Client for OES(Open Enterprise Server) のインストール手順と注意点を説明しています。

Client for Open Enterprise Server Readme


- ローカルアカウント -

OES eDirectory へのシングルサインオンは、 Windows のローカルアカウントが適しています。Client for OES では、ローカルアカウントのパスワードを制御して、シングルサインオンができますが、Microsoft アカウントでは、パスワード同期ができません。事前にユーザのローカルアカウントを作成します。


a0056607_20102051.jpg

Windows10 Microsoft アカウント<-->ローカルアカウントの変更

ローカルアカウントで OneDrive のリンクの解除と設定

Client for OES はこちらからダウンロードできます。無料で取得できる Microforcus/Novell/NetIQ/SUSE のアカウントを事前に取得してください。

Micro Focus Downloads

SUSE Linux アカウントの取得から評価版のダウンロードまで

a0056607_20114919.jpg

ダウンロードしたファイルを開きます。"Unzip" > 自己解凍方式で解凍後、インストーラが起動します。


a0056607_20120517.jpg


"Windows の言語設定を使用" > 次へ

a0056607_20121766.jpg

EULA に同意


a0056607_20123658.jpg

お約束で「カスタム」を選び、インストールされる内容を確認します。


a0056607_20125347.jpg

お約束で、中身を確認したら


a0056607_20134987.jpg


インストールします。(約5分)


a0056607_20131501.jpg

そのまま再起動しても構いませんが、ここでは「閉じる」を押します。

a0056607_20142506.jpg

ネットワークのプロパティを開いてClient for OES がインストールされていることを確認します。


a0056607_20212904.jpg

再起動します。

初回だけ"ネットワークログオン"します。


a0056607_20150323.jpg


「詳細オプション」を開き、ツリー名、コンテキスト、優先サーバー(空欄でも構わない)をセットします。初回はツリー名が見当たらない場合があるので、「ツリー欄」に OES サーバーの IP アドレス、もしくは DNS 名を入れて、右の「ツリー」ボタンを押すとツリー名がリストアップされます。「コンテキスト」ボタンを押して、このユーザがログインする OU コンテナをセットします。サーバー名は空欄でも構いませんが、確実に接続させたい場合は、サーバーがあるコンテナを選んで、優先サーバーをセットします。


a0056607_20152969.jpg

eDirectory のユーザ名とパスワードをセットして、ログインします。

eDirecotory のユーザ名と Windows のローカルアカウントを一致させ、シングルサインオンできるよう、「ログインに成功した後.... パスワードを一致....」 をチェックします。

a0056607_20160060.jpg

eDirectory に接続した後、ローカルログインが求められます。ローカルアカウント名と、一時的に割り当てられた、デフォルトのパスワードをセットしてください。


eDirectory パスワードと、一時的なローカルアカウントのパスワードでログオンすると、ローカルパスワードは eDirectory のパスワードと同じものにセットされ、ネットワークログインとローカルログオンが一つのパスワードでシングルサインオンします。

※ パスワードが同期が反映されるまで、数十秒かかります。

一旦、ネットワークにログインできた後は、そのプロファイルは保存され、次回からは設定する必要はありません。

オフラインの時

ノートPCなどで、オフラインで利用する場合、「コンピュータのみにログオン」をチェックして、ローカルアカウントだけでログオンします。


a0056607_20165424.jpg

その後、ローカルネットワークに接続した場合、タスクバーの「^」マークからClient for Open Enterprise Server アイコンを右クリックして”OESログイン”します。


a0056607_20171040.jpg
a0056607_20172529.jpg




- Keyword -

Client for OES, Novell Client, NetWare Client, How to Install, Windows10, ローカルアカウント, Microsoft アカウント, インストール, ノベル


by islandcenter | 2017-11-08 20:17 | Windows | Comments(0)

あわせて読みたい

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

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

OES 2018 Linux で SMB ファイルサーバーのフォルダ容量制限(ディレクトリクォータ)

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

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

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

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

もともとマンションの住民にとっては自分の部屋しか見えません。見えない共用部分の廊下やエレベーターホールが「ゴミ屋敷化」してもそれは管理者が勝手に片づけてくれるもの、という意識があります。

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

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

という提案です。

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

1) フォルダにクォータ(ディレクトリ容量制限)をかける

残念ながら、Windows2012 以前 と Linux+samba ではボリューム単位、ユーザ、グループでしかクォータ管理ができません。iSCSI で割り当てる容量や、Linux ではdd コマンドで作った指定した容量を仮ストレージとしてユーザボリュームにマウントするとか、そもそもパーティションを細かく分けるとか、強引な方法はいくつかあるようです。

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

ちなみにこの操作はオンラインで Novell Client がインストールされた Windows のフォルダのプロパティや iManager ツールで稼働中にオンライン一発で簡単に変更できます。いったん広げたディレクトリクォータも、簡単に制限を厳しくすることもできます。容量をオーバーしたときはフォルダがリードオンリーになります。ユーザはセッセと不要なファイルを削除しなければなりません。

a0056607_12393973.jpg

容量制限(クォータ)はフォルダ単位で与えることができるので、グループ、ユーザごとのボリュームクォータはほとんど OES 環境では使いません。(一度ユーザのボリュームクォータは使った事がありますが、運用上では非常に使いづらいですね。この設定は運用を停止してパーティションの切り直しも必要とせず、 OES Client Windows や iManager といったツールで1クリックで設定でき、運用中に即時反映されます。

これは、共用サーバーを運用する側にとっても重要で、年間の運用にかかるコスト(管理にかかる人日、バックアップメディアの購入費用、サーバー本体の償却費用)をそれぞれのグループに割り当てたフォルダの容量で頭割りする事で、この共用ファイルサーバーにかかる部門単位のコストを割り出す原資になります。

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

そもそも、それ以前に Linux + Samba では、パーティションの設計が非常に難しくなります。したがって本格的、大規模に利用されているケースが、検索してもあまり見当たらないのは、公開もできない何らかの理由があるからでしょうか。

したがって、あまりユーザ、グループをボリューム単位でクォータをかけるのは良い事ではありませんし、ほとんど意味がなく、まず実際には使われていないように思えます。したがって、トラスティがある「営業部のフォルダは10G、開発部は20Gですね。ホームディレクトリは5Gに制限します」とディレクトリクォータをかけた方が良いわけです。これで、ユーザは自然に「大事なファイル」だけをセッセと共有フォルダに保存するように心がけ、無駄なファイルを置かない習慣ができるのです。Linux + Samba ではこの機能はありませんし、 Windows では 2012 以降に利用できる様になったようですがサクセスストーリーが見当たりません。残念ながら、Windows でディレクトリクォータを使うケースを紹介している記事はあまり見ません。つまり、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 (月日年時分年々月日時分) 形式でファイルの最終アクセス時刻を意図的に変更できます。

ファイルサーバーのフォルダ容量制限


- Key Word -
Novell Open Enterprise Server クォータ管理、容量管理、古いファイルの自動削除、ファイルサーバー管理

by islandcenter | 2015-06-02 13:08 | OES Linux | Comments(0)