2018年 06月 13日
KVM on SUSE(SLES12) で仮想インスタンスの作成
ここでは SUSE Linux Enterprise Server(SLES12) で仮想マシンを作成する手順を説明します。
SLES12 より virt-manager の使い方がウィザード方式になり、簡単になった反面、細かなカスタマイズが出来にくくなりました。ここでは、 カスタマイズしたインスタンスの作成方法を説明します。
-はじまりはじまり-
全体の流れはこちら
SLES VM install on KVM/SLES12
まず仮想インスタンスイメージを作成するディレクトリを作成します。
virt-manager では、仮想イメージを作成するディレクトリを作成する機能がないので、予め、仮想イメージを作るディレクトリを掘っておく必要があります。
/var/lib/libvirt/images
# mkdir /var/lib/libvirt/images/myvm
virt-manager の起動
# virt-manager &
で起動するか yast2 & > Virtualization > Virtual Machine Manager を選びます。ここで左上の Create ボタンを押して、新しい仮想インスタンスを作成します。
Local Install Media(ISO or CDROM) > "Foreword" > Use ISO Image > "Browse" > Browse Local > Other Locations から、ディレクトリをブラウズして ISO ファイルを指定して "Open"
"Automatically Detect ........ " にチェックが入っているので、インストールOSのテンプレートが自動的に選択されます。もし、"Detect" されない場合は、チェックを外して、適切なOSを選ぶ事ができます。若い方には「こんなのシラン」という、年寄りには”懐かしい”と叫びたくなる古いシステムも選択できます。（OS/2 Warp はなかった.....）
Forward で、vcpu 数、メモリを設定します。
イメージを作成するディレクトリを指定するために "Manage" ボタンを押して、作成済みのディレクトリに作成する仮想インスタンスのイメージファイル名を指定します。
Manage > "Brows Local " > "Computer" から、予め作成したディレクトリを指定(Open)します。まだファイルがないので、ファイル名を分かりやすい名前（仮想VM名＋ディスク番号＋フォーマット形式：など）で作成します。
- 仮想マシンのカスタマイズ -
”Finish” ボタンを押す前に「ちょっと待った！」
仮想VM名が決め打ちなので、運用上のインスタンスの命名規則に従って設定、
”Customize Configuration .....” をチェックして選択、仮想VMをカスタマイズします。インストールサマリの詳細画面が出ます。
仮想ディスクイメージの ”Advanced Option” を開くと、デフォルトフォーマットが "qcow2" なので ”raw" に変更
※ 一般的には qcow2 より固定容量の raw フォーマットの方が高速で安定していると言われます。ただし、使い勝手やディスクの予備容量では qcow2 の方が良いそうです。運用上、あまりファイルが増えない小さなシステムでは raw フォーマットが向いているでしょうし、ファイルの増減が大きな場合やスナップショットを使うには、qcow2 の方が使い勝手がよいようです。
- 二台目の仮想ディスクの追加 -
Add Hardware で二台目の仮想ディスクイメージを作成、一台目と同じ要領で、任意のディレクトリパスに仮想ディスクのイメージファイルを指定します。"Advance Options" を開き、適当なパラメータを指定します。
二台目のディスクも raw フォーマットにしましたが、システムディスクは raw フォーマット、二台目のデータディスクや、/var, /home や /data などのファイル増減が多い仮想ディスクは qcow2 にするか、外部の iSCSI デバイスに分けるのが良いでしょう。
スピード重視の開発環境や、フルイメージのバックアップから再起動が高速で会った方がいい、という場合は、SSD上にイメージを作るとか、システムパーティションは SSD 上に作り、大容量の仮想ディスクが必要な場合は HDD のパーティションに作りたい、という選択ができます。
- いよいよ作成開始 -
左上の Begin Installation を押してインストール開始（このボタンの位置がわかりずらいンですね）
インスタンスが実行状態となり、インストーラが起動します。
かなり端折りましたが、全体的なイメージはこんな感じでした。
より詳細な情報はマニュアルをご参考ください。
マニュアルはこちらSUSE Linux Enterprise Server 12 SP3 Virtualization Guideサブスクリプション購入はこちら
SUSE Linux, SLES12, KVM, Create VM virt-manager, KVM 仮想マシンのインストール,
#
by islandcenter
| 2018-06-13 15:17
| SUSE
|
Trackback
|
Comments(0)
2018年 06月 11日
KVM on SUSE Linux(SLES12) virsh console が起動/接続できない。
- 現象 -
SUSE Linux Enterprise Server 12 の KVM 環境で virsh console コマンドでテキスト端末から仮想ドメインのコンソールに接続できない。
sles12kvm:~ # virsh listId Name State----------------------------------------------------9 opensuse-Leap151 running17 salamandra running20 wsus running21 dns4 running31 sles12sp3 running36 sles11sp4 runningsles12kvm:~ # virsh console sles12sp3Connected to domain sles12sp3Escape character is ^] (<--- Enter を押してもここから先に進めない)
- 対策 -
マニュアルの記載があります。SLES の仮想ドメインのブートローダーのカーネルパラメータに YaST で console=tty0 を記述します。SLES11 の場合、更に /etc/inittab でコメントアウトされている行を一か所、有効にします。
Accessing the VM Guest via Console
SLES 12 / openSUSE
Launch the YaST Boot Loader module and switch to the Kernel Parameters tab. Add console=ttyS0 to the field Optional Kernel Command Line Parameter.
SLES 11
Launch the YaST Boot Loader module and select the boot entry for which to activate serial console access. Choose Edit and add console=ttyS0 to the field Optional Kernel Command Line Parameter. Additionally, edit /etc/inittab and uncomment the line with the following content:#S0:12345:respawn:/sbin/agetty -L 9600 ttyS0 vt102
とっても重要
当たり前ですが、 テキストコンソールではない Windows の仮想マシンには virsh console は利きません。
SLES11の場合
# yast2 > System > Boot Loader から、ブートセクション行を選択して Kernel Option に " console=ttyS0" を加え修正します。
テキストエディタで /etc/inittab から "S0:12345:respawn:/sbin/agetty -L 9600 ttyS0 vt102" の行のコメントアウトを解除します。
sles12kvm:~ # virsh console sles11sp4Connected to domain sles11sp4Escape character is ^] (Enter)Welcome to SUSE Linux Enterprise Server 11 SP4 (x86_64) - Kernel 3.0.101-63-default (ttyS0).sles11sp4 login:
SLES12の場合
SLES12 の場合、YaST の System > Boot Loader > Kernel Parameters に " console=ttyS0" を加え修正します。
sles12kvm:~ # virsh console sles12sp3Connected to domain sles12sp3Escape character is ^] (ENTER)Welcome to SUSE Linux Enterprise Server 12 SP3 (x86_64) - Kernel 4.4.73-5-default (ttyS0).sles12sp3 login:
これで、テキストコンソールから、virsh console が利用できます。
サブスクリプション購入はこちら
SUSE, SLES12, KVM, XEN, Virsh Console が起動できない
#
by islandcenter
| 2018-06-11 13:06
| SUSE
|
Trackback
|
Comments(0)
2018年 06月 05日
速攻 1分で DNS on SUSE12 by YaST(YaST で DNS のインストール)
SUSE Linux で、YaSTによるDNSサーバーのインストールから設定（スレーブ）まで、二分弱の動画でまとめてみました。
Bind Install on SUSE 12 by YaST(2分でできるYaST でBind DNS のインストール)
こちらはテキスト版の yast
Network Service > DNS サーバーをえらんで run させます。
GUI版 yast2 の場合、Search ボックスから "dns" のキーワードで DNS server のアイコンが絞り込まれるので、これをシングルクリックします。なお、yast2 の仕様により gnome の設定をダブルクリックオープンにしても、yast2 では常にシングルクリックです。
なるべく右ボタンから open を選ぶのですが、動画では間違ってダブルクリックしてしまいました。
まだインストールされていないので "Install" します。
フォワーダのリストは /etc/resolv.conf から引っ張ってきます。そのまま Next
マスタのDNSから引っ張ってくるゾーン名を設定して Type:Slave で "Add" > Next
ゾーンのマスタDNSの IP アドレスを追加して OK
Start-up が Manually (手動) なので "Now and When Booting" をチェック > Finish
# dig @localhost hostname.mydomain のホストが正しく Answer Section に出てきました。
SUSE Linux では、この様に、YaST ツールで簡単にパッケージの導入からデフォルトの設定、スタートアップの指定までできました。
後は、サブスクリプションを購入してアクティベートします。サブスクリプション購入はこちら
SUSE Linux, YaST, DNSインストール, DNS設定, パッケージインストール,
#
by islandcenter
| 2018-06-05 14:54
| SUSE
|
Trackback
|
Comments(0)
2018年 05月 28日
openSUSE Leap 15 Install : インストールファーストインプレッション
この５月に openSUSE Leap 15 がリリースされたので、ファーストインプレッションです。
ダウンロードはこちらから
バージョンは 42.3 から 15 になります。合わせて SUSE Linux Enterprise 15 (SLE15) のリポジトリも用意されているようなので、SLES15 のリリースも近い様です。
※ 有償版 SLES/SLED15 のインストールとファーストインプレッションはこちら、大きな違いがあります。
用意するもの
1. インターネット接続環境 : インストールの時に、リポジトリと NTP の参照を行う様です。
2. DHCP 環境 : 上の理由と同じです。
3. 有線接続 ? : Wifi 環境では、どうやって Wifi につながるのかは、適当なノートブック環境がなくテストできませんでした。RJ45 のポートがないノートPCの場合、USB ドングル経由の接続環境は用意しておいた方が良いでしょう。
インストールの全作業
インストール後、HOSTNAME の変更、固定IP(Statical IP)の設定、NTPの日本国内、Local Lan 向け修正まで、約２0分でした。このブログではポイントだけキャプチャを載せています。
お時間があれば動画をご参考ください。２０分程度の作業を７分程度に端折っています。（音出ます！）ここでは日本語を使っています。
今回は英語キーボードなので、キーボードタイプは英語のまま、画面キャプチャはインストール言語も英語です。キーボードを選んだら、NUM Lock だとか Caps が押されていないか、特殊記号キーは正しいか、テストエリアでテストしてみてください。
お手軽サーバーが目的だと仮定して、インターネット回線が細いのであえて日本語は選択していません。ちなみに、フォントはリポジトリからダウンロードしてインストールするようです。時間がかかりますが後からインストールもできるので、ここでは言語: English(US) を使っています。
※ 本番用の高額なサポート付き SUSE Enterprise (SLE) も、日本国内での販売店のサポート体制が十分ではありません。man やメッセージが日本語だと、情報が少ないので、私はSUSE本社のドキュメントや英語でのコミュニティのサポート体制を考慮して英語を選択する事をお勧めしています。どうせ、日本のサポート拠点も、日本語だとサポート丸投げできないので、英語を使って丸投げサポートを受けるのが、やさしさ、というモノです。
後で、日本語フォントを追加インストールできるので、サーバー用途を前提とするなら、英語が無難です。
デスクトップは SLES と同じ gnome を選びました。
パーティションは Proposal が /home が別パーティションなので Expert オプションから、削除して
Add ボタンで別なパーティションを作ってマウントするように変更しています。
SLES12 と同じく、/ （ルート）パーティションは BtrFS でデータパーティションは XFS が標準です。
個人的なお約束ですがこのシステムを JST+9 の日本ローカルタイム運用の場合 "Hardware Clock set to UTC" のチェックは外します。このチェックが入ると CMOS クロックも UTC に設定しておく必要があります。他のシステム〈たとえば Windows などと〉とデュアルブートしていると、別システム側にとても楽しい事故が起こります。ハードウェアクロックと切り離された仮想環境や、通常運用では NTP 調整なのであまり意味はありません。警告に注意事項が出てくるようなサマータイムは日本にはありません。
オペレータアカウントを作ったら、root のパスワード設定です。キーボードのテストエリアがあるので、Caps キーが押されているとか、NUM Lock されているとか、特殊キーが正しく認識されているのか、確認する事ができます。
ファイアウォールは、×有効 > 〇無効にして、SSH は、×無効 > 〇有効にしておきました。後で運用開始する前にそれぞれのポリシーを設定するのが良いでしょう。
systemd のスタートアップターゲットは、サーバー目的であれば Graphical mode > Text mode に変更しても良いでしょう。
標準で gmome 環境がインストールされるので # startx で、X環境が使えるし、リモートのXサーバー端末から yast2 GUI や nautilus ファイルマネージャが使えます。もちろんデフォルトの Graphical mode でも構いません。
ここから、ファイルのコピー、リポジトリから補足ファイルのダウンロード、NTPの設定など基本的な設定まで、 SSD 環境だと大体５，６分でした。恨めしいのはウチの回線の細さです。
ファイルコピーと環境設定が終わると、リブートされます。
テキストモードの場合はログインして
# startx
を起動すると gnome デスクトップが起動します。ちなみにXを終了させるには、Logoff でテキストコンソールに戻ります。
Text モードの yast と GUI モードの yast2 を起動してみました。SLES12 の yast2 のデザインは使いにくく、あまりいいとは思えなかったので、この yast のメインメニューは使いやすそうです。ただ、本番の SLES15 でやっぱり違うデザインになるのでしょうか。できればこのママのデザインの方がいいな。
yast (yast2) > system > Network Settings より、Edit して DHCP > Statically IP、サブネットマスク、HOSTNAME を設定します。> Next
後は、 Hostname/DNS、Routing で、DNSの設定と、デフォルトゲートウェイの設定を行います。
yast (yast2) > Network Services > NTP Configuration から、インストールの際に自動設定された、opensuse の ntp pool を削除して、ローカルLANの NTP サーバーや、国内の NTP プール、公開 NTP などに変更しました。IPを設定しなおしてすぐなので NICT のNTPとは接続できなかったようですが、LAN内のNTPサーバーとは問題なく接続できているようです。
yast (yast2) で NTP の設定を保存したら、自動的にNTP参照先が変更されます。
後は、サーバーをリブートして、 HOSTNAME のプロンプトが変更されれば、OKです。
必要に応じて yast (yast2) から追加言語で Japanese をインストールすれば、日本語フォントや gimp のヘルプなどがダウンロードされインストールされます。（回線が細いと時間がかかる）
SUSE 15 (openSUSE15 , SLE15)には ifconfig コマンドが無くなりました
- インプレッション -
openSUSE Leap15 は、もうすぐ出てくるであろう SLE 15 のプレリリースの様なものです。SLES (SLE Server) と SLED (SLE Desktop)が混在しているので、汎用性が高いディストリビューションですが、汎用性が高いため、それだけパッケージの量も大きくなってしまいました。
無償ディストリビューションとしては、ヘビー級かもしれませんが、１Gb程度のメモリと Pentium クラスの十分なスペックがあれは Windows10 なんかより全然軽快（だと思う）です。ただ、この手の無償ディストリビューションの宿命として、サポートライフサイクルが短い、という欠点があるのでその点は覚悟が必要です。openSUSE の特徴として、デスクトップの派手さより堅実さ、確実さ、サーバーとしても使える堅牢さ、そしてやっぱり SUSE ならではの YaST の使いやすさが評価できます。
OES 2018 Linux で SMB ファイルサーバーのフォルダ容量制限(ディレクトリクォータ)SUSE Linux 15 YaSTの基本 (openSUSE Leap, SLE)
openSUSE Leap 15 Install, インストール, yast, リリース
#
by islandcenter
| 2018-05-28 13:18
| SUSE
|
Trackback
|
Comments(0)
2018年 04月 18日
OES2018 Kanaka for mac Desktop (mac側) のインストールと設定
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 をアプリケーションフォルダにドラック＆ドロップします。
- Kanaka Client.app の起動と使い方 -
アプリケーションフォルダのKanaka Client.app を開きます。
”Login" ボタンからログインします。
サーバー IP とPort No. 3089 をセットしログイン
できませんでした。"Failed to connect to server xx.xx.xx.xx on port 3089. Result=1" SSL の証明書エラーです。
さてマニュアルを見ると、更に面倒な作業を行わなければならないようです。
Generating Certificates
つまり、サーバーにあるCA 認証局のサーバー証明書をインポートしなければならないのです。Kanaka Engine をインストールする際にexport した cert.pfx ファイルが必要です。
kanaka for Macintosh 3.0.1 を Microfocus OES Linux ファイルサーバーへ導入
Keychain access.app を立ち上げてcert.pfx をドラッグ＆ドロップします。
この状態では、まだサーバー証明書が信頼されていないため、Organization CA とサーバーIPの表記がある証明書の右ボタン「情報を見る」から「信頼」の「この証明書を使用する時」 > 「すべて信頼(always trust)」に変更します。
※このキーチェイン.app の一連の作業で、cert.pfx をエクスポートしたパスワードと Mac 側の管理者パスワードが必要です。本来、管理を厳重にすべきサーバー証明書なので、安易にエンドユーザに渡すモノとは思えません。ご意見があればコメント下さい。
無事ログインできました。パスワード変更アイコンを開けば、ユーザはMac 側からeDirectory パスワードを変更できます。
ただし、ここでは、eDirectory ログインスクリプトは動作せず、ボリュームステータスをチェックすることもできませんでした。（負けた....）
ここまでの作業では、一応、ユーザパスワードの変更が、Kanaka for Mac で出来る、という事までは確認できました。
--
ということで、この記事は書き換える可能性があります。
Kanaka Client.app 自体のインストールは Mac おなじみのドラック＆ドロップで済みましたが、サーバー証明書をインポートする時に、エクスポートしたサーバー証明書ファイルとパスワードが必要になるなど、パッと配ってお終い、と言う訳には行かない様です。まだ未成熟なところを感じました。
また、マニュアルにあるようなボリューム管理、ボリュームマウントが出来なかったため、これはまた機会を改めて報告したいと思います。
#
by islandcenter
| 2018-04-18 15:05
| OES Linux
|
Trackback
|
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
の３つのコンポーネントから構成されます。ここでは 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 をチェック。絵では、違うものをクリックしていますが... ご愛敬
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 にトグル
Enter a password to protect the private key.(後で使います。任意です。覚えておくこと)This is required when Export private key is selected.Click Next.Click Save the exported certificate.
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/ をブラウザで開きます
スキーマを拡張します。
Click Next to extend the eDirectory schema.
kanaka Proxy オブジェクト、Kanaka Administrator オブジェクトを作ります。
ユーザインデックスを作るユーザコンテナを指定します。O=ORG を選び、"Serch All Subcontainers ...." を選ぶと、サブツリー全体のユーザインデックスを構築します。
この下にインデックスリビルドを実行する時間のチェックリストが出てきます。デフォルトで午前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 が起動しました。
"User Index" より "rebuild Time" の指定ができます。デフォルトでは午前０時に自動実行されます。
kanaka によってDesktop.Afp (隠しファイル)がrebuild されます。
#
by islandcenter
| 2018-04-16 14:34
| OES Linux
|
Trackback
|
Comments(0)
2018年 04月 13日
OES 2018 Linux でフォルダ容量制限付き Mac 向けファイルサーバー
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 時代から標準で付いてくる機能なので、２０年以上の長い歴史と実績があるファイルシステムです。
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://～ を付けるのが無難な様です。
eDirectory のユーザ名：パスワードでログインします。
※ macOS X の場合 Microfocus/Novell CIFS の設定を行った場合、 smb://～ でも cifs://～ でもボリュームをマウントできます。
共有ボリュームをマウントすると、[SRWCEFMA] のトラスティの、最低"F" 権があるディレクトリ、フォルダのみ表示されます。 他のユーザの "HOME" ディレクトリは見えません。（隠しフォルダではなく、クライアント側からは全く見えないのです）
フォルダに容量制限(ディレクトリクォータ)がかかっているため
大きなファイルはコピーできません。
”別名で接続"ボタンを押してセッションを切り
別なアカウントで接続します。
これで、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
|
Trackback
|
Comments(0)
2018年 04月 10日
Mac から Linux にファイル転送 : Filezilla を使う
Mac <---> Linux/Unix へのファイルコピーは、当然 scp コマンドをポチポチと叩く標準があります。まぁコンソールを使って、単一のファイルを転送するなら scp でも構いませんが、複数のファイルをコピーしたりするにはやっぱりGUIが欲しい。Windows であれば WinSCP という、ま、割と使いやすいソフトウェアを愛用しています。
という事で調べたら "Cyberduck", "Filezilla" などが良く使われているようでした。そこで Filezilla を使ってみました。
左の "FileZilla" > Download > "OSx" の小さなアイコンを開くと OS X 用ダウンロードのボタンが出てきます。
ダウンロードして、インストールしてみました。
起動した後、「ホスト:IP-Address」 「ユーザ名: xxxx」 「パスワード: ******」 「ポート: 22」(SSH) を指定して接続すると sftp のプロトコルでセッションを開きます。
#
by islandcenter
| 2018-04-10 16:05
| MacOS
|
Trackback
|
Comments(0)
2018年 04月 10日
Mac からSUSE Linux のX アプリケーションを使う
エラく久しぶりにMac を購入したのでMacintosh macOS からSUSE Linux を管理するためにX アプリケーション（特にYaST）を使う方法を探しました。何しろ YaST2 コントローラと FireFox がないと、アクティベーションや管理、アプリケーション登録なんかもできません。最低限 Mac から Linux の X アプリケーションを操作できる環境が必要です。
Mac 用の X11 についてX11 は Mac に付属しなくなりましたが、X11 のサーバとクライアントのライブラリは、XQuartz プロジェクトから入手できます。
--
macOS 用の X11 のサーバ／クライアントライブラリは、XQuartz プロジェクト (www.xquartz.org) から入手できます。提供されている最新バージョンをダウンロードしてください。
色々検索すると、古い macOS X にはx11 が標準だったのですが、macOS sierra にはついてこないらしい、ということで Apple さんお勧めの XQuartz を使ってみます。
XQuartz
よりダウンロード、インストールします。
Xquartz を起動して、「アプリケーション」から「ターミナル」を起動
$ ssh -Y user_name@Your_SUSE_host_ip_or_DNS
で接続します。
bash-3.2$ ssh -Y root@192.168.1.239Password:Last login: Mon Apr 9 09:41:50 2018 from 192.168.1.11sles11:~ ˙# yast2 &[1] 27936sles11:~ # firefox &[2] 27978sles11:~ # gedit &[3] 28016sles11:~ #
おお！
とこんな感じです。
macOS, HighSierra, 10.13.3, Linux 管理, X サーバー, X 端末, GUI アプリケーション起動
#
by islandcenter
| 2018-04-10 14:35
| MacOS
|
Trackback
|
Comments(0)
2018年 04月 10日
Mac で隠しファイル.フォルダを表示／非表示を切り替える方法
Windows を使っている身から Mac をいじり始めると、隠しファイルが見えない事です。まぁ動作には不具合があるので、あまり隠しファイルを見せたくないし、見る必要がないのですが、外付けのHDDなんかに隠しファイル・フォルダを作っておいたら見えないので、非常に困った。
という事で Mac 上で隠しファイルの表示／非表示を切り替える方法です。
- まずはコマンドを叩く -
mac-mini:~ myme$ defaults write com.apple.finder AppleShowAllFiles TRUEmac-mini:~ myme$ killall Finder
この後Finder を起動します。
隠しファイルが表示されました。
- 表示/非表示の切り替え -
この後、Finder で "command(win)+shift+.(ドット)" のキー３つを同時に押して、表示／非表示を切り替えることができます。
私の Mac mini は US キーボードなので、command キーが印字されていません。中々慣れないですね。
macOS, HighSierra, 10.13.3 隠しフォルダ表示, 非表示
#
by islandcenter
| 2018-04-10 14:20
| MacOS
|
Trackback
|
Comments(0)
2018年 04月 10日
MacOS を英語に切り替える方法
また、海外製ソフトウェアのマニュアルを読んで、インストールや操作をするときに Finder のメニューの意味が日本語ではわからない事もあります。英語を母語とする、ソフトウェアのサポートデスクに症状を伝えるときに、日本語で説明する訳には行きません。
英語の画面のハードコピーなどが必要なわけですね。
という事で、Macを英語にしてしまうにはどうすればいいのか、というお話です。
- インターフェースを英語化するには -
「林檎」 > 「システム環境設定」 > 「言語と地域」 で左のペインに + キーで ”English” を追加します。英語が一番上に来るようにドラックして、この画面を閉じます。閉じる際に再起動を要求しますが。ログオフ、ログインで言語の変更は有効になります。
別に英語に変えても、日本語表示はおかしくないですし、IMEも使えます。
どうやらシステムのロケールも英語になるので、ターミナルからSSH で接続したLinux のロケールも「怪しいニホンゴ」から「正しい英語」になりました。おかげで SUSE Linux の YaST ツールも意味不明の日本語版から、ナチュラルな英語版になりました。ヨカッタ....
macOS, HighSierra, 10.13.3, 英語, 日本語, 切り替え
#
by islandcenter
| 2018-04-10 14:07
| MacOS
|
Trackback
|
Comments(0)
2018年 04月 10日
MacOS sierra で時刻同期先をLAN内や国内の任意のNTPサーバーに変更する
macOS では、デフォルトでは設定した地域内（日本では time.asia.apple.com.）のNTP サーバーに同期します。
しかし、これは、アドレスを調べるとアジアではなく実体はアメリカのApple にあるサーバーです。時刻のネットワークの経路によっては揺れが多く、何十台、何百台とある内部ネットワークコンピューターがバラバラな経路で外部に問い合わせる事は好ましいとは思いませんし、それぞれの端末が同じ時刻ソースにアクセスしないと微妙なタイムラグが起こります。
できれば、社内に ntp.nict.jp などの国内のパブリックntp サービスと既に同期をしている代表の構内 LAN 専用のNTP サーバーや、国内の近い経路にあるパブリックntp サービスに変更したいものです。
macOS の場合、「林檎」 > 「システム環境設定」 > 「日付と時刻」から「日付と時刻の自動設定」を変更することで、構内NTP に変更できます。
まずこの「日付と時刻」の左下にある「鍵」アイコンをクリックして、管理者用パスワードで鍵を解除します。 「日付と時刻の自動設定」がグレーアウトから、編集可能になるので
同期先 NTP サーバーのIP アドレスかDNS 名を設定して「鍵」をかけます。
これでNTP サービスはより近い、よりWAN回線や無料で提供されているパブリックntp の運営者に迷惑をかけない方法で、LAN内のコンピューターの時刻を同期させることができます。
SOHO 環境ならまだしも、ある程度以上の規模のネットワークであれば、内部のNTP サーバーを参照したほうが、それぞれのコンピュータが勝手に外部からバラバラに時刻同期を取るより、最短の経路で単一のNTP ソースを使うのがベターだと思います。
時刻同期は、文字通り「同期」です。NTTの１１７と全く同じである事よりも、構内ネットワークのそれぞれのデバイスが「ほぼ同じ時間」に同期していることが重要なのです。
macOS, HighSierra, 10.13.3, 時刻同期, NTPサービス
#
by islandcenter
| 2018-04-10 13:30
| MacOS
|
Trackback
|
Comments(0)
2018年 04月 10日
Mac の恥ずかしい「最近使った項目」を表示させない方法
近年、 BYOD だとか「働き方改革」などと言うキーワードで、モバイルノートの配布だとか、「仕事で自分のPCの持ち込み」なんかがOKになったりします。
まぁ、自宅持ち帰りPCで、プライベートな目的で使う事ってあまりないでしょうが、ついつい、仕事中にプライベートなデータにアクセスしちゃうという事は頻繁にあるわけですね。
そこで Mac で問題となるのは「最近使った項目」です。
Mac で「林檎」マークから、スクロールダウンすると、その途中で出てくるのが、この「最近使った項目」
これメッチャ恥ずかしいンですね。
昨日の夜に「妖しいデータを見ていた」
「下ネタサイト」みてて「キャハハ」と盛り上がった。
ナンてこと忘れて、いきなり朝から客先直行でプレゼンなんかすると
「最近使った項目」
にズラズラと、昨夜の「昨夜の妖しい」ファイルがリストされるわけですね。
何しろ、昨日の夜、黄表紙だとか枕本を見ていたとか、そういった「アンタは昨日何見てたのよ」という履歴がズラズラと、林檎マークの下にリストされるわけです。
つまりあなたのネクタイの下の品格、と言ったものまで疑われるわけです。
まぁ、仕事用であれば当然ミットモナイ事でも笑って誤魔化すって事になるんですが、自宅でコンピュータの前を離れたときに、同居人なんかに「林檎マークの下半身」を見られると、鍵かけずにトイレに入ってケツ拭いている時に、いきなり家族にドアを開けられた位に
「スマン、恥ずかしい」
と反省する訳ですね。
となると
「最近使った項目」は恥ずかしい。
という事で、Mac 版「最近使った項目」を表示させない方法です。
関連記事 Windows 版はこちらWindows10 の恥ずかしいクイックアクセスを表示しない
「林檎」 > 「システム環境設定」> 「一般設定」にある「最近使った項目」を "0" に設定します。
「最近使った項目」が消えました。
これで、あなたのネクタイの下の品格は保護され、コッパズカシイ想いをしなくて済むのです。
Linux でフォルダ容量制限付き Mac 向けファイルサーバー
macOS, HighSierra, 10.13.3 最近使った項目を非表示, 隠しフォルダ表示, 非表示, 過去の履歴を表示しない。mac 最近使った項目 保存場所,最近使った項目 履歴 削除,finder 最近使った項目 非表示, high sierra 最近使った項目 削除. 最近使ったフォルダ 削除, 最近使った項目 削除, 最近使った項目 編集, 最近使った項目 フォルダ 削除, 最近使った項目 表示
#
by islandcenter
| 2018-04-10 13:13
| MacOS
|
Trackback
|
Comments(0)
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
|
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, サインオフ,ログオフできない, セッションが切断できない,
#
by islandcenter
| 2018-03-19 13:50
| Windows
|
Trackback
|
Comments(0)
