-Symptom-

私はいつもこの問題に困らせられます。小さなスクリーンで 1 Click インストールすると GpuPG キーをインポートできない。というかダイアログが無駄に大きすぎてボタンが現れません。このダイアログはリサイズできません。

Dueling install OSS Software into openSUSE 12.x by 1 click install, how to push 'import' button for importing GpuPG key ? Because my environment 800*600 screen as like XEN virt-manager, I can not find 'Import' button anywhere on my screen.

I can suppose 'ALT+N' should be mean 'N_ext' button on this screen.
a0056607_1450973.jpg


この画面でどうやってNext やインポートボタンを押せると言うのだ? How can I push 'Next' button or 'Import' button ?

-Answer-

Hit 'ESC' key to cancel to install software at this time. Later I can import GpuPG Key from YaST CUI console, at a time yast > Software Repositories, This screen was appeared !
a0056607_14555343.jpg


実は、ここで一度、ESCでキャンセルして、コンソールから yast > Software Management を選んだらこんな画面が出てきました!

The answer mey be 'ALT+T' to 'T_rust', mey be.... たぶん ALT+T だと思う。

この後は、もう一度 1 Click インストールするとうまく行った。というより、ダイアログスクリーンのデザインが悪すぎます。必要以上に大きすぎます。彼らは 17 Inch のディスプレーしか使ったことがないのでしょうか? それとも私のラップトップの 13 Inch のスクリーンが小さすぎるのでしょうか。

How do you think this design ? I have to abandon my tiny LapTop with 13 inch screen and only 2 pound light weight machine, and purchase the other LapTop with 17 Inch Screen heavy 6 pounds weight, and bring with Metoro in awfully rush time in Tokyo for commuting, don't me ?
[PR]
by islandcenter | 2013-09-27 15:23 | SUSE | Trackback | Comments(0)

openSUSE で作る Thin Client

最近の話題と言えば

「Windows XP のサポート切れからどうやって Windows 7/8 に入れ替えるか」

ということに尽きるわけですが、ここで一つのご提案です。Thin Client にしちゃいましょ。

ということで openSUSE を使ったシン・クライアント端末の作成方法です。

-想定-

ある過疎地の公立学校では 35 台の 5年前のPCが Windows XP で動いているとします。HDDは良く壊れるし、大体この規模のPC教室ではハードウェア、ソフトウェアのライセンス費用を考えるととてもじゃありませんが町の教育委員会から、予算なんて出そうもありません。メモリも僅か 512Mb バイトです。

また、この町の役場にも何台もの Windows XP 端末があり、HDDもよく故障するし、その保守費用も馬鹿にはなりません。

ということで、役場や図書館、町立の病院なんかではどうやって Windows XP を入れ替えるかが悩みの種です。

そこで 今、マザーボードとディスプレーだけはまだまだ元気な機材を USB や フラッシュSSDで起動できるシンクライアント化してしまおうというものです。

最低 openSUSE 12.x が動作すれば良い訳なので、USB メモリやフラッシュメモリの容量は 8G バイトもあれば十分です。別に古い Celeron や atom のマシンでも構いません。

ただしシンクライアントのためのホストサーバーは約 50~70台程度が動作するサーバーがほしいので4Way の 最新の XEON E5 サーバーとします。12コア24スレッド×4Way なので1台のサーバーで最大96スレッド(!)が動作します。これくらいの規模であれば、どうせ実稼動しているクライアントは平均 40 台程度と考えて、2~4 vcpu を与えても十分機能するでしょう。

(かな?自信ないな)

仮に最大60台のシンクライアントを動かすのであれば、 256Gb あれば1台あたり 2G のメモリが積めますので、 Windows 7 の 32 ビット版を使うことにしましょう。これだけあれば、一般的なオフィス製品やブラウザ程度であれば十分軽快に動作します。

あるいは Windows のターミナルサーバーを使うということも考えて見ましょう。

あまり詳しく Windows のライセンスは詳しく知らないので、皆様の突っ込みコメントお願いします。

1台あたり 50G バイトのC:ドライブが必要であると仮定して、3Tバイト以上の SAS ストレージを準備します。

-susestudio.com-

まず、susestudio.com にアクセスして、Live USB イメージを作ります。gnome か KDE の X 環境で rdesktop さえ動作すればよいわけですから、ここでは 32 bit 版で rdesktop と yast の Users & Group 作成のためのパッケージを追加し、シンクライアントのアプライアンスのベースとします。

a0056607_10385831.jpg


-openSUSE 12.3 の設定-

まず、各人のUSBメモリに、 suseStudio で作ったアプライアンスイメージを展開します。

openSUSE の Live CD をUSBメモリに作成する。

次に古い PC から HDD を取り外して USB 起動するようファームウェアを設定します。
USB またはフラッシュメモリから起動した openSUSE に root でログインして、yast の「ユーザとグループ」 から Guest でも構わないし、普段固定された環境で使うユーザ "TankTar" がいる場合は、そのユーザを作成して、適当なパスワードを設定しておきます。別にこのパスワードは厳密に管理しなくても構いません。yast のユーザ管理メニューから Advanced > ユーザの自動ログインと「パスワードを必要としない」をチェックします。

a0056607_10514291.jpg


作成したユーザのプロファイル /home/TanakTar/.profile に

rdesktop -f xx.xx.xx.xx

を記述します。
a0056607_10531984.jpg

xx.xx.xx.xx は接続する先の仮想ホスト、ターミナルサーバーや Windows 7 のシンクライアントホストの IP アドレス、または DNS 名です。

※ RedHat 系の場合は .bash_profile ファイルを書き換えるらしい。

PCはUSBかフラッシュメモリで32bit版 openSUSE を起動します。どうせ gnome と rdesktop が動くだけなので、 512Mb メモリの PC でも十分に起動できます。

起動したら /home/user_name/.profile に書かれた rdesktop を -f で Remote Desktop がフルスクリーン起動します。

仮想ホスト側では「切断」を許可しないポリシーで RDP プロトコルで接続できるように設定しておけば、エンドユーザ側端末は、作業が終われば「ログオフ」して、端末の電源を切るだけです。どうせフラッシュメモリはほとんど読み出しだけなので、電源をそのままオフにしても問題はHDDほど発生しないでしょう。

あるいは Reboot できるようにバッチファイルを用意しておけば Reboot のタイミングでセッションが切れるので、そこでシンクライアント側はログオフして電源が切れる状態になります。
a0056607_1172080.jpg


-いくつかの問題点-

rdesktop のパッケージは RDP セッションのバージョンが古いため、16ビットしか色が出ません。ちょっと寂しい画面かも知れません。

また、シンクライアント側のUSBなどの周辺機器の接続に都合が悪い(セキュリティ上逆に都合がいいとも言えますが)とことがあります。

また USB メモリで起動する場合、起動に時間がちょっとかかること、また BIOS の起動設定をいちいち変更しないといけないケースがあります。もっともHDDを抜いて PXE ブートも無効にしておけるようであれば、起動メディアはUSBメモリだけなので、その点は工夫が必要かも知れません。

あと、ここでは過疎地の町役場を想定してみましたが、役場の人達って、なぜか月末になると俄然ヤル気システムが起動して猛烈に働いて5時には終わるという人種です。この集中をどう避けるかがポイントかも知れません。

しかし、5時を過ぎるときっちり帰る人達なので、サーバーの仮想マシンイメージ3Tバイトは週末にたっぷり時間をかけてNASなどにバックアップをとっておけば良いということになります。

また過疎地の場合、通信環境が劣悪で、「100Mbps 光」どころかADSLさえ使えない地区」があります。その点も十分注意が必要でしょう。

また、同じ「役場」の人たちでも「現業」の方と「事務」の人たちは求めるスペックや働く時間帯が違います。例えば公立学校の先生とか、町立病院のお医者さんなどはいつも遅くまで働きますが、事務員の皆さんは8時出勤、5時からは絶対に残業しない、という明確なルールがあるようです。(学校向けのシステムではずいぶんやられました)

こうした現業職の皆さんには優先的に最新のワークステーションを配置すべきでしょう。

役場の中には「わが町の将来のために」一流の大学を出たのに安月給にもかかわらず本当に真剣に仕事をされる方もいらっしゃいます。私など全く頭が上がらない思いなのですが、彼らはUSBメモリだけを持たせて、役場>学校>病院>図書館と移動しながらUSBメモリで端末を起動すれば良い訳です。もしVPNが許されるなら、ご自宅や出張先で「USB起動に変える方法」さえ訓練して覚えておけば、どこでも仕事ができるわけです。たとえUSBメモリを紛失しても、起動だけのメモリなので、安全です。

また、Thin Cleint なので、 iPad や Android のタブレットにワイヤレスキーボードを繋げてしまえば、 Wifi で iPad 用の Remote Desktop アプリケーションが使えるので、ノートPCを職員に配布するくらいなら 激安 Android タブレットを使わせるというのも一つのアイディアですね。

また、マイクロソフトには Windows RT の在庫がたっぷりあるそうなので、格安にまとめて何十台と購入すれば喜んで格安にマケてくれるかもしれません。


islandcenter.jp
[PR]
by islandcenter | 2013-09-24 07:06 | SUSE | Trackback | Comments(0)

eDirectory の同期プロセス

eDirectory 同期のメカニズムの続きで、Novell の eDirectory を説明する試みです。


-外部参照(External Referrence)-

まず、外部参照 - External Referrence - について理解しておく必要があります。

外部参照(X-Ref)はパーティション化(分割)されたツリーのレプリカデーターベースにはないオブジェクト(ユーザなど)の情報です。

言わば「社内で出張してきた(ユーザなどの)オブジェクト」です。

例えばOU=Osaka が OU=Tokyo とは分割されたパーティション(オフィス)で OU=Osaka には CN=Maido.OU=Osaka さんがいるとします。OU=Tokyo にあるAsakusa サーバの、とあるファイルだとか「コピー機」にアクセス権限があったとします。Maido さんがこのリソースに接続しようとすると、このユーザの一時的な外部IDが作成されます。Asakusa オフィスでの、いわゆる「ゲスト入館カード」のようなものです。Maido さんはこのカードで出張中の必要な Asakusa オフィスの資源にアクセスできます。「コピー機を使うならその機械を使ってもいいよ」というような情報です。もちろん Maido さんが正規のユーザかどうかの認証は OU=Osaka パーティションに入館時にチェックされます。

eDirectory は「一枚のカードがあれば全てのどこのオフィスビルにでも自由に入館管理ができる」Windows Directory とは異なり、「オフィスビルごとに身分を確認して入館申請管理が必要」なディレクトリサービスなのです。この時に Maido さんが手に入れるIDカードが External Referrence というIDなのです。

多くの eDirectory の同期障害はこの X-Ref に関する情報交換の失敗によるものです。


-Flat Cleaner プロセス-

このプロセスは、External Referrence などの「無用になった」オブジェクトをクリーンアップするプロセスです。cn=Maido.OU=Osaka さんが退職したら、その情報は OU=Osaka パーティションデータベースの中で「即時」に削除されます。しかし、Asakusa オフィスではそのことは誰も知りません。「そういや大阪の Maido さんって元気かなぁ」みたいな状態ですね。
Maido さんに「コピー機を使ってもいいよ」という権限を与えたとしても、その権限を与えた「記憶」は Asakusa のオフィスにはそのまま残っています。

Flat Cleaner プロセスは 「Maido さんという人が Osaka オフィスから出張してコピー機を使う権限を与えた」という記録を消去するプロセスです。

-Janitor プロセス-

Janitor とは「門番」を意味します。

この同期プロセスは「各オフィス」が抱えているサーバーの最終同期状態などをチェックするもので、簡単に言うと「全社コンプライアンス委員会」の確認の為のプロセスのようなものでしょうか。このプロセスの中で、正しく情報のレプリケーションなどが行われているかをチェックします。関連子会社の誰が今度社長になった(マスターレプリカになったか)と言った情報を交換しあうわけです。

Slow Sync で定期的(Heart Beat)に実行されます。


-Replica Sync プロセス-

このプロセスは一番よく発行されるプロセスです。「ゴリさーん、電話だよ」「あ、ゴリさんなら今、トイレに出かけたよ」というような内容の会話がオフィス(パーティション)の中でよく交わされるわけですが、これが Replica Sync のプロセスです。ここで重要なのは、eDirectory によって同期される内容は「ゴリさんに電話があった」「ゴリさんはトイレにいる」という情報だけがサーバー間で交換されるということです。

Windows の Directory では cn=Gori さんのオブジェクト情報は全て筒抜けに全てのサーバに同期されます。「ゴリさんに電話があった」だけの情報に加えて、ゴリさんの本日の出社時間から、アクセス権限、ゴリさんの内線番号、メールアドレス、今朝食べたゆで卵が原因でお腹を壊したという下世話な話題まで全部の情報を同期します。

ちょっと想像しても解りますね、Active Directory を使っているネットワークはひどく「ウルサイ職場」です。しかもデータベースはパーティション化されないため、「ロケーションを超えて、全社で共有」されるという恐ろしいことをやっているわけです。

eDirecotry では最低限の情報交換だけを行い、ゴリさんの腹具合まで社内では交換しません。そんなことは別なオフィス(パーティションデータベース)では話題にすらならないのです。

また、総務部が3Fの大部屋から4Fに引っ越したとしましょう。これがいわゆる「ディレクトリのパーティション化」なのですが、その時、ぞろぞろと什器備品が移動します。この時、「総務部にプロジェクタがあったよなぁ」という情報や「営業部に新しい派遣社員が入った」などの情報はも Replica SYnc で同期されます。

即時同期 (Immedate Sync) です。


-Replica Purger プロセス-

このプロセスは、削除したオブジェクトの最終確認に使われる通信プロセスです。

あるオブジェクト OU=Maido さんが退職したためどこかのレプリカリングから「削除」した場合、Obituary (オビチュアリ:死亡通知)としてマークされます。このオビチュアリをレプリカリングから一斉に削除するために Replica Purger の通信が発生します。まず、オビチュアリは全てのパーティション内で共有されます。つまり Maido さんのIDカードは使えなくなった、という情報が共有されます。その後 Replica Purger は Maido さんが使っていたカードIDを全て破棄します。

即時同期(Immedate Sync)します。



-Limber プロセス-

この意味不明な通信プロセスは、Janitor プロセスに似ています。似ている作業をするために別な言葉 Limber プロセスと言われるのでしょうか。この通信プロセスも、それぞれのサーバー間、パーティションの整合性、レプリカリングのIP アドレスなどの整合性をチェックするプロセスです。東京本社では、別に関連子会社でオフィスのレイアウトが変更になって、内線番号(IPアドレス)が変更されたということはすぐに必要な情報ではありませんが、常に連絡先だけは確認しておく必要があるということです。

Limber Process は、お互いのIP情報の確認などを行います。

Slow Sync で定期的(Heart Beat)に実行されます。

そこで、あるサーバーの内戦番号(IPアドレス)を変更した場合、 DStrace コマンドで Limber Process を強制発行して、IP アドレスの変更を各サーバーに通知します。



-BackLinker プロセス-

このプロセスも External Referrence に関する情報交換です。まだ Maido さんというIDが OU=Osaka に居るかどうか、このX-Ref はまだ使われる必要があるかどうか、つまり「Maido さんは Asakusa オフィスのコピー機を使う権限を与えた」ことがまだ継続して必要かどうかを確認するプロセスです。



-Schema Sync プロセス-

ディレクトリスキーマというのは、データベースの「構造体」に関する情報です。C言語を習った方なら Structure/Union の宣言のようなものと理解するとわかり易いでしょう。

eDirectory のスキーマは「初期状態の基本情報で固定」されているわけではありません。eDirectory に新しい「属性」が加わることがあります。例えば、基本情報に加えて。「携帯電話も社内で管理しよう」というポリシーになった場合、ユーザオブジェクトの項目に「携帯電話番号」という属性が付け加わります。この情報は ディレクトリ[root] に権限がない限り変更は許可されません。

Schema プロセスは、このディレクトリスキーマが正しく同期されているか、あるいは項目や属性が追加されたり、削除する通信プロセスで、[root] の Master パーティションから下位へと行われます。

スキーマはデータベースの構造そのものですからスキーマの変更は大きな負担がかかります。スキーマの変更に不具合が発生した場合 reset schema を行ってデータベースの再構築を行います。

大抵大きな外資系企業でし連休明けに eDirectory の障害が発生した場合は、なんらかのスキーマの変更(例えば新しいディレクトリアプリケーションの導入)が行われたことによります。


-Time Sync プロセス-

このプロセスは NetWare 4/5/6x 時代のもので、OES Linux では NTP に取って代わりました。ただし、ディレクトリ同士が同期しているかどうかはタイムスタンプで管理されているため、OES Linux ではNTP サーバとの同期が取れているかをお互いに監視するために使われます。極端に時刻がズレている場合は同期エラーとなります。

また、オブジェクトのタイムスタンプが「遠い未来」の時間だった場合、 - これは date コマンドを間違って実行してタイムスタンプを「来年」にしてしまった、など - 同期は長時間の間、失敗します。

そこで、タイムスタンプをリセットするために「エポックの宣言(Declere Epoch)」を明示的に実行します。


-Sub Ordinate Referrence は叔母さんの連絡先-

eDirectory の同期プロセスと密接な関係ですが、プロセスとは違う情報の一つにサブオーディネートレプリカ(Sub-Ref)という機能があります。

Windows のディレクトリは「ドメイン」という巨大な一軒家に徳川一族の郎党が一つ屋根の下で暮らしているようなものです。ハトコが今トイレに居るとか、会ったこともない従兄弟の子が巨大な一軒家の裏庭今剣術の修行をしているという情報も全て知っています。というか強制的に知らされます。

一方、eDirectory のシステムは、徳川一族が「紀州」「名古屋」「水戸」に分家している様な形態だと考えれば良いでしょう。

私は独立して、貧乏長屋に両親と離れて暮らしています。両親はまた祖父母とは別な家に住んでいます。これが分割されたパーティションです。

ある日、私は従兄弟が家を新築し、叔母の家から独立したと新年の祝いの日に(Janitor のハートビートプロセスで)聞きました。これが叔母の一族(OU)でのパーティションの分割です。しかし、私は従兄弟がどこに家を新築して、新しい電話番号を使い始めたという情報を知りません。そこで、従兄弟に新築祝いも贈ることもできません。

しかし、両親を経由して、祖父母に連絡すると、おばの家に連絡が届き、従兄弟の新築した家(パーティション)の連絡先を知ることができます。これがディレクトリのツリーウォークです。

しかし私は叔母の家がどこにあって、叔母の家を訪れたこともなく、叔母の誕生日に花束を贈ることもない無精者です。ただ連絡先だけを知っています。それは私の両親も同じことです。

このように一族郎党の中に「知り合い」(ここでは叔母さんの家)はがあっても、その実情を知らない家(パーティションのレプリカ)があります。これをサブオーディネート(Sub Ordinate Referrence) Sub-Ref レプリカと言います。

私は従兄弟の家を訪れて、彼の家の間取りや家族構成をいつも連絡し合います。つまりこれは私が従兄弟の家の Read/Write レプリカを持っているということです。また、叔母さんは従兄弟の家族構成や家の間取り、果ては台所のどこに何があるかまで知っています。つまり叔母さんも従兄弟の家の R/W レプリカを持っているということです。

私は従兄弟の新築の家(パーティション)を訪問し、お茶をご馳走になり、新築祝いで花束をあげました。この情報は彼の家で X-Ref(外部参照)として彼の家庭の皆なが知っていることです。従兄弟の子供が挨拶に来て、私は彼に恥ずかしいほど少ない小遣い(ファイル)を残します。

しかし、私が東京に戻り、コーヒーカップが洗われ食器棚に片付けられ、花束が枯れてゴミ箱に捨てられると Flat Clear プロセスによってその記録(X-Ref)も消去されますが、私が渡したお小遣い(ファイル)には記録が残ります。

しかし、私の両親は叔母さんの家の実態を知りません。(まぁウチの一族の実際はそんな薄情な事はないのですがそう仮定しましょう)私の両親の家(パーティションのデータベース)は叔母の連絡先だけは知っているということです。これが「実体のないレプリカ」Sub Ordinate Referrenceです。私の両親はボクが従兄弟の家に行ってヨッパらってトイレを汚したとか、従兄弟の子供に小遣いを渡したという事実を知りません。また知る必要もありません。

もし叔母が引っ越した(IPアドレスが変わった)としたら、その情報は Limber Process で知ることができます。

このように、たとえ徳川一族のような巨大な郎党であっても、隅々まで家族構成だとか、(あればのことですが)抱えている家庭内の問題だとかを共有しあうことができます。巨大な組織であっても、途中の連絡先さえわかれば、一族の中のパーティション(家庭)内部の少ない情報量の交換だけで、全て「親戚である」という信頼(トラスティ)を得ることができますし、地の遠いハトコであっても「東京に下宿先を探してくれ」と言われれば紹介することができるのです。

※ eDirectory の実態では「親子」間でレプリカを共有しない場合は Sub-Ref が必要です。兄弟間でレプリカを共有しない場合は Sub-Ref は作られません。私は本家を知らなくて、両親の家の間取りや、食器棚のどこに醤油瓶があるかは知らなく(RWレプリカを持たない状態)ても、両親の住所は知っている( Sub Ordinate Referrence) を持っていなければなりません。

-eDirectory の同期状態を調べる-

eDirectory の同期状態を調べるコマンドは ndstrace と ndsrepair コマンドです。 

ndsrepair コマンドは、同期状態を調べ、修復を実行します。

ndstrace コマンドは同期プロセスをリアルタイムに表示し、必要に応じてプロセスを強制実行します。

Novell Open Enterprise Server の eDirectory 8.8 では現在 iMonitor によってブラウザから操作することができます。iMonitor の Trace コマンドで必要なプロセスだけをフィルターし
a0056607_2303059.jpg


トレースを実行します。
a0056607_2314577.jpg


これによってサーバー上での eDirectory の通信プロセスを確認することができます。


islandcenter.jp
[PR]
by islandcenter | 2013-09-24 05:45 | Identity Management | Trackback | Comments(0)

ユーザ管理とダンパー数

ダンパー数というものがあります。

社会学者ロビン・ダンパー (Wikipedia)が提唱したもので、

「霊長類は大体150人前後の人間関係が限度」

というものです。おおよそ150人以上の人間関係は、お互いを認知できないというものなのだそうです。

例として

- 従業員150人程度が中小企業の限界:これ以上社員がいると、社長は従業員一人ひとりを面倒見れない。企業が急激にこれ以上成長するには、優秀な「中間管理職」が必要となる。

- 歩兵部隊はおおよそ中隊規模が基本、これ私が大好きな戦争ドラマ「バンド・オブ・ブラザース」でもそうでしたが、ウィンタース中隊長が大隊長になった途端に書類仕事に忙殺されます。ウィンタース大尉は、中隊長時代に優秀な「現場指揮官」でした。

- 軍艦でもコルベット艦や小型駆逐艦などの艦艇の乗組員は150人程度。この程度であれば、艦長は水兵たちのことをよく把握している。私は英国の冒険小説が大好きなのですが、コルベット艦の面倒見がいい指揮官が出世して大型フリゲート艦の艦長などになると、途端に「冷酷な指揮官」になってしまいます。

- 古代ローマ軍では「100人隊長」という隊長が現場指揮官だったことが強さの秘訣だった。

- SNS で「友人」が何百人いても、本当の「知り合い」は200人程度らしい。
 「ダンバー数」にFacebookで挑戦 Wired.jp
--

なぜ私がダンパー数の事を思い出したかというと、どんな大企業でも多くの組織では、大体150人から250人程度を一つのユニットと見なして、ヘルプデスクを配置していた組織が多かったということです。また、ディレクトリサービスの設計でも、およそそのくらいの人数で OU が構成されていました。

こではヘルプデスクのための数字であるというより、組織そのものが「ダンパー数」に支配されていたことでもあるからなのかも知れません。

ここに eDirectory などのディレクトリサービスで管理する OU (部門オブジェクト)の設計のポイントがあると思います。1拠点に1、000人のユーザがいたとしても、実際にチームワークとして機能するのは200から250人程度が限界なのですね。それをシステム的に1,000ユーザをひとくくりに管理することには無理がありそうに思います。じゃぁ4、5人で面倒みれば良いじゃないか、というご意見もありそうですが、チーム内部で1,000人を4,5個のユニットに分けて分担し、管理したほうが良いのかもしれません。


ということでダンパー数のお話と、ID管理のお話でした。
[PR]
by islandcenter | 2013-09-23 14:08 | Identity Management | Trackback | Comments(0)

ここでは Novell Open Enterprise Server (OES11sp1) を使った Novell Samba の導入方法を説明します。

マニュアルはこちら
http://www.novell.com/documentation/oes11/

file_samba_cifs_lx.pdf に従い作業を行います。

こちらの方が詳しいかも
Installing and Configuring Samba on Open Enterprise Server 2

この文書も親切です
Troubleshooting Samba On Open Enterprise Server (OES)

-前提-
-
SUSE Linux 11 上に仮想ディスクを3台定義しました。一つは / パーティション、他は NSS ボリューム用と ext3 用です。

※ iManager と YaST2 の表示は英語にしています。iManager は初期設定画面で Japanese にローカライズすることができます。

- Novell Open Enterprise Server (OES11sp1) をインストールします。ここではいきなり全てをインストールせず、NTP などの設定を終わらせてから Novell OES コンポーネントを導入しました。 yast2 の Novell OES Configuration アイコンを実行し、 明示的に NSS と iManager を選択します。自動的に関連する eDirectory パッケージがインストールされます。

この時点では Novell Samba はインストールしていません。
a0056607_14551023.jpg


ユーザとグループを作りました。
a0056607_10501918.jpg


ユーザのホームディレクトリと、各グループの共有ディレクトリがあります。
a0056607_10521981.jpg


-インストール-

yast2 > OES Configuration

Novell Samba を選択すると LUM(Novell User Management) も同時にインストールされます。このコンポーネントは eDirectory と UNIX ユーザとを関連付けるコンポーネントです。

a0056607_110438.jpg

Accept > インストールが開始されます.


a0056607_1134137.jpg


Novell Samba を有効にするためには更に設定項目があります。 >  Novell Samba の行をクリックして Admin のパスワードをセットしてログイン。

デフォルトで "servername_W" が NetBios 名となります。他に Novell Samba のプロクシユーザの設定などの項目があります。サーバ名は NetBios の制限で最大15文字なので、はみ出した部分は削除する必要があります。
a0056607_132690.jpg


ここではそのまま Next > 前の画面に戻って Next, インストールが終わりました Finish.

Organization Unit (o=company) 直下に MyServerName-W.company オブジェクトが作成されます。このオブジェクトは任意の場所に作成できます。ポリシーにより、 O=company 直下に作らず、Ou=MyLocation.O=MyCompany などに作成することも検討します。
a0056607_11201757.jpg


もう一つ、サーバーコンテナに UNIX Workstation - MyServerName.system.tokyo.company オブジェクトが作成されます。

この時点で Client 側には MyServer_W の Samba サーバが表示されます。
a0056607_1132372.jpg


-ここからが難問、ユーザとパスワード-

LUM(Linux User Management) より利用する Linux ユーザを選択して追加します。
a0056607_11374458.jpg


ユーザを選択した後、ユーザが所属するグループを指定します。
ここでは新規に LinuxUsers というグループを作成していますが、既に存在する eDirectory のグループも選択することができます。
a0056607_11403998.jpg


Password > Password Policies > "Samba Default Password Policy" を確認し、
a0056607_11534066.jpg


このポリシーに適合させるユーザを指定します。
a0056607_11584090.jpg


このユニバーサルパスワードのポリシーは、「パスワードを忘れた時のリセット方法」「大文字小文字を区別する」「長さの制限」などさまざまな設定が行えます。
a0056607_1225718.jpg


例えば、グループを指定して「マル秘情報」にアクセスできるグループは厳しいパスワードを設定したり、一般的なオペレータであれば、3ヶ月に一度8文字以上のパスワードを設定するなどですね。

次に File Protocol > Samba より、サーバを選択肢、Samba のユーザを指定します。
a0056607_12810100.jpg

おっ、エラーが出てしまいました。

User_name_xxxx: Could not Samba enable the user for group, MyOes11-W-SambaUserGroup. Received an error when checking for a universal password. Error: Cannot continue because the user does not appear to have a universal password.

See help for possible causes.

と出てしまいました。

もう一度この文書で確認しましょう。この文書も親切です
Troubleshooting Samba On Open Enterprise Server (OES)

As an administrator you have the option of setting the password manually for individual users by going to Passwords and clicking on Set Universal Password, but it is not necessary. Once the policy has been assigned to a user or container, all the user(s) should have to do is to login though through NCP (example: Novell Client) or using LDAP (example: iManager) and it will automatically attempt to synchronize the eDirectory password to the Universal Password. If the Universal Password doesn't exist but the eDirectory password does exist, then they system will synchronize the two passwords to be the same as the eDirectory password. If the Universal Password does exist, but it doesn't match the eDirectory password or if the eDirectory password doesn't match the new policy assignment then the password will expire and the user will be prompted to enter in a new password.
Note: You will not be able to add any users to the Samba configuration until their Universal Password has been set.


ここに書かれていることを簡単に説明すると

- Administrator はユーザの Universal Password を明示的に設定できる。(初期値が必要)
- Universal Password が設定されていない場合、NCP か LDAP を使って変更(Novell Client で設定できる、逆に言えば Novell Client が必要)
- 設定されていない場合は eDirectory のパスワードと同期する。(これはこれで便利)
- Universal Password と eDirectory のパスワードが同期していない場合、お互いのポリシーが異なれば一致させることはできない。(非常に当たり前なこと、どんなシステムでも使えるパスワードポリシーを考慮すべきである)

と、こんなところです。

ということで、既に Novell Client でログインしたユーザを追加してみます。
a0056607_122189.jpg

無事 Samba ユーザとして登録できました。

ついでに Share タブで「共有フォルダ」を作ってみます。
a0056607_12261713.jpg

この「共有」は NSS ボリューム上にユーザからは Read Only で作成しました。従って Novell Samba で R/W の設定を行ってもユーザは書き込みができません。
a0056607_12312256.jpg

設定を変更した場合、 General Tab にある Restart リンクをクリックします。忘れやすいのでご注意ください。
a0056607_14295517.jpg


通常の Linux ファイルシステム上の Samba の共有も iManager から設定します。
a0056607_17161163.jpg


File Protocol > Samba > Share から NSS ボリュームに「共有」を設定した場合、 NSS で与えられたトラスティが適用されるため、[SRWCEFMA] のF権のないディレクトリは表示されません。
a0056607_13294921.jpg

表示されないのは Novell Samba 自体が表示を行わないからで、 /home を開いたときに「ズラーリ」と表示される各ユーザのホームディレクトリの参照のための余分なパケットロスもないということです。


-大変よくできました-

- パスワードの変更が容易である。
これは重要なことです。
a0056607_13392681.jpg

通常の samba であれば、 smbpasswd コマンドで定期的にパスワードを変更するよう「管理者は指導」できますが、強制はできません。何らかのUIを工夫している方もいらしゃるでしょう。パスワードの変更のルールは明文化できても強制させるためにはさまざまなテクニックが必要です。まして SSH で入ってコマンドで変更しろというのでは、まずユーザが自主的にパスワード管理を行うことはないと言って良いでしょう。

しかし、この機能は NCP 接続を要求された時に実施されることであって、Novell Samba が要求するところではないのが残念です。

-必要のないフォルダは見えなくてもよろしい
これも NSS ボリューム上に作成した Novell Samba の優れた点です。ユーザのアクセサビリティからも、見えても関係ないよというフォルダが見えないことは、余計な詮索もなく、非常に便利なことです。また、ディレクトリの一覧を取得する場合、CIFS の悪いマナーの一つである問い合わせのパケットが大幅に削減できます。

-右ボタンで共有設定
NCP で利用している場合、右ボタン > Novell 権限で容易に他人にアクセス権を設定できます。自分の作品を他人に「公開」するため、 chown や chmod などのコマンドを使う必要はありません。あくまでも NCP (Novell Client for Windows)の中での話しですが、NCP で設定した内容はそのまま Samba の利用者にも適用されます。

-ファイルの圧縮とシュレッディング
Novell Open Enterprise Server 上の NSS ボリュームには、ディスクのクォータ、ファイル圧縮、データシュレッディング(乱数での自動上書き)などの機能が備わっています。 ext3 などで作成したボリューム上でユーザの利用制限をかけたり、自動的に圧縮させるような機能は知りません。

-大変がっかりしました-

これは、Novell Samba の仕様というより CIFS と Windows の仕様そのものの問題でしょう。パスワードを変更するためには NCP (ポート 524) での接続が必要だということです。Novell Samba を使うことで eDirectory との連携、パスワード管理は容易になりますが、そもそも Samba のパスワードを管理するためのツールというもの自体が Windows にはありません。

ということで、多少の手間(と言っても難しいことではないのですが) Novell Client for Windows は必要なものです。しかし、 Novell Client for Windows を導入してしまえば、なぜそこまで Samba を使うのか、という理由が見つかりません。

考えられるケースとしては、通常は NCP 接続をしているユーザが、「持ち込みPC」を使って情報にアクセスできないこともない、というケースです。もちろんそれが許されるポリシーであることが前提です。

OES ファイルサーバーを Samba 主体で利用するべきではないと考えています。単純に「高価なだけの」Samba サーバーとなってしまいます。その「高性能さ」を生かしきることはできません。

もともと閉じた LAN 内での利用を前提とした CIFS と WAN を考慮した NCP (Novell Core Protocol) との違いもあり、CIFS での利用は限定的にすべきだと私は考えます。

--
システムはシンプルであるべきです。CIFS の効率の悪さは色々悪評が多く、WAN越しのアクセスが遅いとか、使い物にならないといった話はよく聞きます。仕方がないので高価なCIFSアクセラレータを導入してみたけど、100ユーザ程度でも全然効率は上がらず、諦めたというケースもよく聞きます。何しろ 「CIFS + 効率」で検索すると Cisco などの WAFS アプライアンス製品がずらりと紹介されるのもその証拠でしょうか。これらのアプライアンスも内部に故障しやすいキャッシュ用のHDDやSSDなどの「消耗品」を抱えている以上、「ファイルサーバー」そのものに近い存在です。サーバーの集約化を目的として逆にサーバーを増やしているのが、SIビジネスということです。

シンプルで使いやすいプロトコルを選ぶなら NCP (Port 524) を選ぶべきなのですが、残念ながら Windows やLinux では標準サポートされていません単純に Novell Client を導入し Port 524 の通信を行えば問題は解決できるのですが、どうもそういった動きはお客様にないようで残念です。


islandcenter.jp
[PR]
by islandcenter | 2013-09-19 08:00 | OES Linux | Trackback | Comments(0)

eDirectory の基本は 1990 年代に開発された NetWare 4x シリーズから基本的な構造、コンセプトは変わりません。この基本設計の優れた点が eDirectory 8.x に継承されています。

この巨大なディレクトリシステムが(おそらく世界最大の)フランス国税局が管理する4000万人とも言われる納税者のプロファイル管理に利用されています。

何をいまさらなのですが、eDirectory は Novell/NetIQ のID管理システムの根幹なので、そのメカニズムを「知ったかぶり」で Windows Active Directory と比較して説明します。

-パーティションとレプリカ-

eDirectory の最大の特徴がこのパーティションとレプリカの概念です。

単一の「ディレクトリツリー」空間は、ツリーのブランチ(O/OU:組織/部門オブジェクト)ごとに複数のパーティションデータベースに「分割」して連続した単一のツリー空間の一部を構築することができます。

Windows の Active Directory はこのように「単一の"ドメイン空間"」を「ドメインツリー」としてトラスティドされた連続空間として管理できるだけです。ドメインを「分割」することはできません。

eDirectory のパーティション化(分割)され、分散化されたデータベースは「レプリカ」と呼ばれます。

また、各 eDirectory サーバーは複数のレプリカデータベースを保持することができます。

a0056607_1552912.jpg


データベースはパーティション化して分割(レプリカ)を作成できる



Windows の単一の Active Directory サーバーは同じ「ドメインツリー」内部であっても複数のドメインデータベースを保持することができません。たとえ同一のドメインツリーであっても複数のドメインに所属することができないからですね。従って同じドメインツリーであってもユーザなどのオブジェクトを「移動」することはできません。「削除」と「再作成」が必要です。

各 eDirectory データベースは、パーティション化して細分化されます。極端な例かも知れませんが、各 OU (部門)オブジェクト単位でパーティション化して複数の複数拠点に配置した eDirectory サーバーに分割して同期コストとを削減させ、DR(耐障害性)を保つことができます。そのため、巨大なディレクトリであっても、少ないサーバー資源に有効に LDAP オブジェクトを分割配置することができます。

a0056607_15193840.jpg

少ないサーバーで耐障害性、冗長性が確保できる


パーティションのレプリカデータベースは一般に単一の Master レプリカと複数の Read Write (RW) レプリカによって構成されます。耐障害性と同期コストを考慮して、最低3台から、数台以内のサーバーにレプリカデータベースを持たせることが推奨されます。パフォーマンスを考慮しないとして、3台のサーバーで3拠点以上のパーティションを保持することができます。拠点数とサーバ数が増えれば、更にそれだけ少ないサーバーで細分化されたレプリカデータベースを分散配置できます。

一般には Master レプリカと RW レプリカは一般ユーザや管理者が行う同じ役割(ログイン認証、オブジェクトの新規追加、更新、削除)を実行します。 Master レプリカは、サーバーの追加や削除、レプリカデータベースの分割などのレプリカベースの操作を行うときの操作元となります。

Master レプリカが障害を起して取り除き、RWレプリカから Master に変更する必要がある場合、ndsrepair -P コマンド(NetWare では dsrepair) で "Designate this server as the new master replica"を「選択して実行」するだけです。

a0056607_15223971.jpg


ntdsutil ツールで難解なコマンドラインを駆使して「"FSMO"の切り替え」の複雑な操作を行う必要はありません。


-同期コスト-

eDirectory の特徴として、同期コストの低さがあります。

例えば LDAP の属性として cn=user : UID のようにオブジェクト毎に含まれる item/Attribute がありますが、eDirectory はこれらの Object の Item ごとにタイムスタンプが設定されており、オブジェクトの変更は変更されたオブジェクト内部の Item ごとに行われます。例えば、cn=myuser の電話番号を変更しても同期にかかるコストは「電話番号」という Item であり、 cn=myuser 全てのオブジェクトがコピーされるわけではありません。

a0056607_15162729.jpg

オブジェクトの同期は Object.item 単位で行われ同期コストを下げている


意外なことなのですが、ユーザなどのディレクトリのオブジェクトは一つあたり割と大きなサイズがあるものなのです。

例えば大量のオブジェクトのパスワードをリセットしても、eDirectory ではリセットされるのはパスワードの情報だけで、オブジェクト全てが同期されるわけではありません。最小の Item だけが限定されたレプリカリング内だけでリセットされるだけです。

一方で、 Windows の Active Directory の場合、「全オブジェクト」の情報がドメインDBを持つサーバ全体に同期しようとするため、「ログインできない」「アクセスできない」などのトラブルが大量のドメインコントローラに伝えられ、収束して同期が完全に完了するまで障害として残ります。

eDirectory ではこの「同期状態」を確認するための ndstrace というコマンドインターフェースがあり、「まだ同期中だな」というのが「見て解る」のですが、残念ながら Windows Active Directory ではこういう「今何してるの?」という確認に必要なツールがありません。(というか知らないのは私だけなのかもしれないけれど)

a0056607_152738100.jpg


つまり、Windows の Active Directory の管理者は「この操作が正しいかどうか」の確認を「待つのも仕事」「クレームを聞くのも仕事」として諦めて待つしかありません。

これらのディレクトリツリーの障害が発生した場合、ほとんどの場合、細分されたレプリカリング内での問題で、ツリー全体で発生することは非常にまれです。 Windows ドメインであれば、ドメイン全体の修復が必要となる場合があります。、

これらの同期情報のうち、「ログインした」などの情報は即時に同期されます。Immidiate Sync (即時同期)と呼ばれます。一方、郵便番号だとかの情報は即時に同期する必要がないため Slow Sync とか Heart Beat などと呼ばれ、一定時間に数台に分割されたレプリカリング内の提示情報としてまとめて定時同期(Heart Beat Sync)されます。

ここで重要なのは、他のディレクトリ製品でも同様に、時刻が一定のタイミングで同期しているということです。

eDirectory の言わば「最終手段」として行う作業は Decrea Epoch (エポックの宣言)です。この操作は、最終同期した時刻をレプリカリング内で強制的に時刻をリセットして同期する作業です。巨大なレプリカリング内では全てのサーバーに対してこの操作が受け付けられ、大量のパケットと同期コストがかかりますが、ディレクトリーツリーを細分化したレプリカで管理している場合は、その小さなレプリカリング内だけで実行されるため、規模にもよりますが、タイムスタンプのリセットと同期は数十秒から数秒以内で完了します。例えば10台のサーバーでeDirectory を保持していた内の3台のサーバーが管理するパーティションで Decrea Epoch を実施すると3台のサーバーだけで処理が完了します。また、パーティション自体がブランチごとに細分化されている場合、そのブランチ単位のレプリカで実施されるため、他の OU 単位には少ない影響で完了することができます。

Active Directory のように大量の「オブジェクト全体の強制リセットと同期」が発生しないため、少ない同期コストでオブジェクトの同期が完了します。


-ディレクトリサービスで重要な時刻同期-

Novell eDirectory は NetWare ベースでは NCP(TCPIP Port 524)あるいはipx を使った時刻同期を行っていましたが、Novell Open Enterprise Server 以降、Linux/Unix ベースのシステムでは一般的な NTP プロトコルを使います。標準的な NTP プロトコルは、時刻ずれが発生した場合、Step Mode という「時間寄せ」のプロセスで、数秒ごとから数分ごと、最終的にはデフォルトの10分ごと(600秒)の時間確認のプロセスに移行します。これを Slow Mode と言います。Slow モードはNTP の設定でデフォルトの600秒から、1時間とか24時間とかに自由に設定できます。

一方 Windows システムは w32tm プロセスで時刻同期を行います。このプロセスはデフォルトで8時間(!)ごとに時刻同期を確認し、大幅な同期エラーが発生すると、単に「エラー」を記録して同期は行えなかった事を報告するだけです。このパラメータを変更するためには Windows のレジストリの変更が必要です。Active Directory システムでは、大幅に時刻同期に問題が発生している事を確認するツールがないため、各ドメインコントローラを保持するサーバーに「リモートデスクトップ」ログインを行って、時刻を確認する必要があります。

eDirectory では ndsrepair -T コマンドをいくつかのサーバー上で実行するだけで、時刻同期に問題のあるサーバーを容易に特定することができます。

a0056607_15245151.jpg


-権利継承-

eDirectory の特徴として「権利継承(Inherit Right)」の概念があります。[root]管理者 cn=admin が全ての管理を行うのではなく、特定の OU(部門オブジェクト)レベルで管理者権限を与えることにより、この低いレベルでのサーバーの追加、削除、ユーザなどのオブジェクト管理を実施することができます。

a0056607_15343097.jpg

admintokyo ユーザはこの内部で自由にサーバやユーザを追加、削除できる。


-eDirectory の最大の欠点:コスト-

Windows サーバーを購入すると CAL が必要となります。同じように eDirectory を購入すると、ユーザごとにライセンスが必要となります。AD のように数百から数千ライセンス程度で十分な場合はCALは必要悪として受け入れるべきものですが、eDirectory のライセンスは利用者の桁違うため、ライセンス料金自体もそこそこかかります。

また Windows ドメインでは無償で「グループポリシーの管理」が行うことができますが、eDirectory では Novell ZENworks という追加製品でグループポリシーの管理を行います。ポリシー管理だけで Active Directory を巨大なツリーに実装すると、手痛い失敗をすることがあるということです。またポリシーの管理ベースがOU単位であると言う点も大きな問題を生み出します。

もっとも、「認証」だけに必要なライセンス料金は低価格で提供されているようですが、サーバーのサービスを受け入れる必要がある場合、 Windows の ユーザCAL のような形態のライセンス料金が発生します。NetWare 6.5 までは「同時接続ライセンス」として厳密に管理されていましたが、OES Linux に移行してからはペーパーライセンスに変わっています。が、実際に契約したライセンス以上のユーザ利用はライセンス違反となるため、「認証だけ」必要なライセンスが必要なのか、サーバーを利用するためのライセンスが必要なのかは厳密に計画して予算化する必要があります。もちろん、共有ファイル、プリントサーバーとして Windows を使わず、Novell Open Enterprise Server (OES) を使う場合は Windows のユーザ CAL は不要です。

また、公共機関などの認証システム向けに専用の特別に安価な認証のみのライセンスが用意されているため、この場合は特別な価格交渉を行うことができます。


-レプリカごとに異なるソルト-

Windows システムではユーザIDは SID という名前で管理されます。この SID はどのドメインコントローラでも共通です。これはユーザに限らず、オブジェクトそのものを「丸ごとコピー」するメカニズム上仕方の無いことです。

一方、eDirectory は UID ごとに異なるオブジェクトIDが保持されます。レプリカAでは cn=user1 が 11223344 なのに レプリカBでは 66778855 となるわけです。このオブジェクトIDは認証での solt (塩) となるわけなのですが、レプリカごとに異なるオブジェクトID、ソルトを認証に使うため、一つのセッションをハッキングされても、他のサーバーへのいわゆる「なりすまし」「セッションの乗っ取り」が難しくなります。

Active Directory ではオブジェクトのSIDが共通で、ドメインコントローラに「コピー」されるため、SIDという共通の「鍵」でなりすましが可能です。もっとも今はもう少し賢い方法を使っているのでしょうが。

eDirectory の同期プロセスに続く
[PR]
by islandcenter | 2013-09-13 14:44 | OES Linux | Trackback | Comments(0)

自分のホストがどのコンピュータと通信しているかを調べるツールとして darkstat があります。

本家
http://unix4lyfe.org/darkstat/

SUSE/Opensuse 用のパッケージは
http://software.opensuse.org/package/darkstat
より1クリックインストールできます。

a0056607_15395637.jpg


別途 libcap ライブラリが必要なので、1click インストールが、一番楽でしょう。必要なlibcap ライブラリも自動インストールしてくれました。Yast > Software Management で確認してください。
a0056607_1541549.jpg


起動は darkstat -i eth0 で起動します。細かいオプションは本家のマニュアル等をご覧ください。常駐解除するには kill,killall コマンドを使います。

起動中はブラウザの URL から http;//myserver:667 で監視できます。ポート 667 はファイアウォールからポート開放しておく必要があります。ブラウザでポート667に接続するとグラフが表示されます。

a0056607_15442160.jpg


実際の操作はこのようになります。

sles11:~ # ps ax | grep darkstat <-- 停止中
28072 pts/1 S+ 0:00 grep darkstat
sles11:~ # darkstat -i eth0 <-- 起動してみた
sles11:~ # ps ax | grep darkstat
28074 ? Ss 0:00 darkstat -i eth0
28075 ? Ss 0:00 darkstat -i eth0
28077 pts/1 S+ 0:00 grep darkstat
sles11:~ # killall darkstat <--- 停止させる
sles11:~ # ps ax | grep darkstat
28080 pts/1 S+ 0:00 grep darkstat
sles11:~ #


-接続ホスト-
host ボタンを押すと、接続中のホスト IP と引ける場合はホスト名も出てきます。

a0056607_15501941.jpg


-使用感-

重い。常駐はさせないほうがいいだろうな。という感想です。何しろパケットを全部キャプチャするわけですから当然ですね。

ただし、どのIPとのトラフィックが多いかを一瞥できるので非常に便利なツールだと思います。例えば連続して同じアドレスからアクセスがあれば、「何かが起きている」わけでその「何か」はまた別なツールで調べて、悪意のあるアクセスであれば、遮断するなどの措置が取れます。(実際ブラウザ機能を内蔵しているので、その点はセキュリティ上の注意が必要でしょう)

あわてぬ先の不正アクセス、大量アクセスの準備としては、なかなか心強いツールだと思います。


islandcenter.jp
[PR]
by islandcenter | 2013-09-09 02:04 | SUSE | Trackback | Comments(0)