isLandcenter 非番中

SUSE Linux Enterprise Server 12 リリースされました

SUSE Linux Enterprise Server 12 リリースされました。

評価版は既にダウンロードできる状態です。
https://download.suse.com/index.jsp

SUSE Linux Enterprise 12」がリリース--ジオクラスタリングなどの新機能
http://japan.zdnet.com/os/analysis/35055734/

ファーストインプレッションは後ほどに。

メールで送る圧縮ファイルのパスワード、そのセキュリティポリシー正しいの？

メールに送付するドキュメントを圧縮してパスワードをかけろ、というポリシーをよく聞きます。

そういうポリシーで運用し、ユーザに励行するよう定めているところも多いでしょうね。

私もそれが、最善だと思っていました。

あまり意味がないなという事にある日気が付いてしまったのです。

メールの盗聴には確かに効果はあるでしょう。
しかし、その対策だけの効果しかありません。

メールに添付ファイル付けて、別便でパスワードを送る。人によっては、ほぼ同時にメールを送ってきます。メールの盗聴はタイミングでエイヤでやる訳ではなく、特定のユーザや送信相手。あるいは一網打尽方式でスニッフィングする訳ですから、あまり効果はありません。

「添付ファイルはパスワード付です、パスワードは××です」と同じメールに書くこととあまり違いはありません。

もっともスニッフィングでどれだけのメールの盗聴が可能かは私は知りませんが、現代のスイッチングネットワークではスニッフィングして、メールの中身を読む事はできません。昔のノンスイッチのＨＵＢならスニッファーで読み放題でしたが。もっともスイッチングＨＵＢでも、専用のスニッフィングっポートを使えば、全てのパケットをキャプチャできますが、一般的なＩＳＰの場合、通信の秘密がある訳ですから、システムトラブルでもない限り、一般人のメールがスニッフィングされることは、「基本的にない」筈です。

むしろ、送信ボックスを含むメールストレージ全体がごっそり被害にあった場合などが怖いわけです。とは言っても、その場合はもっと大事な内容のメールが全部被害を受ける訳ですから、これもあまり意味がない。

ということで、送信途中のスニッフィングが怖いなら、ファイルとは別な方法でパスワードを伝えた方が安全だということになります。例えば、フリーメールで圧縮ファイルを送って、パスワードは正規のメールアドレスを使うとかですね。これなら経路が違うから安全性は高いのです。

どうせ圧縮ファイルですから、相手に届いて、相手の記憶媒体に圧縮ファイルとして保存されていれば、パスワードを同便で送ろうが別便で送ろうが変わりはないのです。


さて、重要なファイルがパスワード付で届きました。受け取ったあなたは何をするのでしょう。

まず解凍します。解凍する前に、ウィルスチェックをすべきです。

ちゃんとチェックできましたか？　できるわけない。取引先を名乗る不審な送信者から送られたフィッシングメールの場合だってあるのです。鉄壁のセキュリティ対策でも、パスワード付添付ファイルは、セキュリティシステムの突破は容易です。

いや、まぁ解凍できたとしましょう。

解凍したら、元のパスワード付ファイルはいらないわけですから、削除するかもしれません。そうすると生身のデータがそのまま受取人の記憶メディアの中にある訳です。これでは何のセキュリティ対策にもなりません。受け取った側のセキュリティポリシーの自由にされてしまいます。

少なくとも重要なファイルであるならば、取扱い注意の上、パスワード付で保管すべしと送信者はアドバイスすべきです。これは受け取った側にもかなりな労苦を生み出すものです。まぁそれだけの極秘情報であると受取るべきでしょう。

パスワード付圧縮ファイルを受け取る場合、別途、業務契約とは別に、取引上に詳細な守秘義務励行に関する覚書程度は交しておくべきです。

私はそんな世界転覆計画のような書面を受け取ることはまずないので、対策はしません。

勿論、受取人にとっては重要なファイルなわけですから、パスワードは「自分が使っているパスワード」にリセットしなければなりません。受け取ったまま、パスワード付の圧縮ファイルである場合、解凍が必要な都度、そのメールを探して解凍しなければならない訳ですね。

煩雑なことです。

ということで、パスワード付圧縮ファイルは送信側の自己満足を満たすセキュリティ対策であって、受け取った側のポリシーに従って扱われる可能性が高いわけですから、ほとんど意味ないじゃないか、と最近私は考えています。

islandcenter.jp

Novell OES でファイルサーバーのボリューム全体を読み取り専用にする方法

ファイルサーバーのメンテナンスや移行などで、ボリューム全体を読み込み専用にしたい場合があります。

ファイルサーバーのマイグレーションはほとんどの場合、ボリューム全体のアクセス権限をそっくり新しいサーバーに移行することです。

しかし「ファイルの棚卸」も重要なことで、これはシステム管理者の仕事ではなく利用部門が行うべきことです。つまり

「新しいボリュームにはデータは入っていないから、古いボリュームから『必要な』データだけ新しいサーバーに移行して欲しい」と宣言し、利用部門にデータの移行をおこなわせれば、どれほど「ゴミデータ」を抱え込んでいたのかを彼らも実際に実感するでしょう。実際に１Ｔバイトのファイルを保有していても、実際に業務に必要なファイルの棚卸をしてみると１００Ｇバイトも必要なかった、という事に気が付いてくれると有難いものです。

また「とりあえず全部コピーしちゃえ」ということでは、莫大な時間が掛かることにきがつくわけで、やっぱりファイルの棚卸は重要なのです。

となると、古いサーバは読み込み専用にしてしまうのが一番効果があります。

Windows サーバーでは、ボリュームのプロパティから全体を「読み込み専用」にして

「サブフォルダにも適用する」

をチェックして実行するとディスクアクセスの嵐。
終わるまで、今日は帰って寝ようか、ということで翌日変なエラーで止まってショボーン、という事がある訳です。

また解除するためには、「読み取り専用」のフラグをリセットして「明日の朝の結果」を待つことになります。

--
Novell Openenterprise Server では NCPcon コマンド一発でボリューム全体を読み込み専用ボリュームに変更することができます。

How to mount an NCP volume as read-only.
https://www.netiq.com/support/kb/doc.php?id=7014969

マニュアルはこちら

https://www.novell.com/documentation/oes2/file_ncp_lx/data/ncpvol.html

実際に RW 可能なディスクがあります。


これを読み込み専用に変更します。
oes11x1:/media/nss/VOL1 # ncpcon disable write VOL1
... Executing "disable write VOL1"
Volume write disabled.
... completed OK [elapsed time = 4 msecs 609 usecs]


ユーザはファイルを書き込むことができません。


読み込み専用を解除するには ncpcon enable write を実行します。
oes11x1:/media/nss/VOL1 # ncpcon enable write VOL1
... Executing "enable write VOL1"
Volume write enabled.

... completed OK [elapsed time = 419 usecs]
oes11x1:/media/nss/VOL1 #


ファイルの書き込みが許可されました。


ちなみにこれは NCP の機能ですので、直接サーバーコンソールから mkdir などをしても効果はありません。


一般には、システム管理部門は、バックオフィスの経理や総務のデータには詳しくても、業務部門でどの情報が重要化までは判断できないものです。

この様に古いファイルサーバーのボリューム全体を読み込み専用にしておけば、ファイルサーバー移行から例えば「１か月の猶予」を置いて、事業部門のファイルの棚卸をさせます。

テープで古いサーバーのバックアップを取り、例えば「５年間だけ保管しておく」と宣言してしまえば、膨れ上がったサーバーのディスク容量がスリムになります。物理的なスリムさだけではありません。部門ユーザにとっても、必要、不要が判断できないファイルが多すぎると業務自体のボリュームが増えるのです。

その後古いサーバーを停止、破棄すればよいのです。

-Keyword-
Windows Novell OES Openenterprise Server ボリューム全体　ドライブ全体　読み込み専用　書き込み禁止


そのほかの情報は
islandcenter.jp

Novell Openenterprise Server(OES) ボリューム名の変更

古いサーバーから新しいサーバーに移行する場合、ユーザの使い勝手が最大限変わらないことは大変重要な事です。

実際には HA クラスタなどを導入すれば良い、という事でもありますが、よほど大規模なネットワークや未停止システムでもなければ、短いメンテナンス時間で、サクッとサーバーを入れ替えるテクニックで、最小のダウンタイムでサーバーや、ディスク装置を入れ替えることが出来ます。

現実的には、iSCSI デバイスのリース、償却期間切れ、ディスク容量の圧迫による装置全体のスケールアップなどのタイミングで、サクッと入れ替えてしまう事が現実的な作業となります。

例えば、サーバー本体の / (ルート)パーティションは仮想マシン上で動作しており、ディスク装置が外付けの iSCSI デバイスである場合、iSCSI デバイスを別な筐体に移行してやれば、以前の環境をそのまま移行することは、Novell Openenterprise Server では簡単な事です。

手順としては新しい iSCSI デバイスをマウントした状態で

1) 新しいボリュームを新しい筐体上に New_VOL: として作成する。
2) 古いVOL: の中身を New_VOL: に nwcopy コマンドなどでコピー同期する。

- この間移行期間-

- 移行-

3) VOL: を VOL_Old: にリネーム
4) VOL_New: を VOL: に変更
5) ユーザに解放
6) 問題がなければ VOL_Old: を削除/撤去

という手順となります。

ここでは、ボリューム名の変更手順を説明します。ここから逆に古いサーバーの入れ替えテクニックを考えてみましょう。

まず、 iManager の Role(役割) から Storage > Volume を選び、サーバーの VOLUME を Rename します。


これでボリューム自体は VOL_New に変更できます。しかし、実際には /media/nss/VOL にマウントされています。


実際に名前を変える場合は、警告がでるので Continue


実際の mount コマンドで確認すると VOL_New は /media/nss/VOL にマウントされています。

oes11x1:/media/nss # ls -al

total 8

drwxr-xr-x 3 root root 4096 Jun 16 13:02 .

drwxr-xr-x 3 root root 4096 Jun 15 09:17 ..

drwxrwxrwx 1 root root 4096 Jun 16 13:04 VOL1

oes11x1:/media/nss # mount

/dev/xvda2 on / type ext3 (rw,acl,user_xattr)

proc on /proc type proc (rw)

sysfs on /sys type sysfs (rw)

debugfs on /sys/kernel/debug type debugfs (rw)

udev on /dev type tmpfs (rw,mode=0755)

tmpfs on /dev/shm type tmpfs (rw,mode=1777)

devpts on /dev/pts type devpts (rw,mode=0620,gid=5)

fusectl on /sys/fs/fuse/connections type fusectl (rw)

securityfs on /sys/kernel/security type securityfs (rw)

none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

none on /var/lib/ntp/proc type proc (ro,nosuid,nodev)

admin on /_admin type nssadmin (rw)

novfs on /var/opt/novell/nclmnt type novfs (rw)

/dev/pool/P1 on /opt/novell/nss/mnt/.pools/P1 pype nsspool (rw,name=P1)

VOL1_NEW on /media/nss/VOL1 type nssvol (rw,name=VOL1_NEW,norename)

oes11x1:/media/nss #

ログインスクリプト上では server\VOL: はなくなってしまったのでドライブマップは失敗します。


そこでログインスクリプトを書き換えてしまいます。


無事スクリプトで map できます。


逆に、マウントポイントを変えてしまえばいいので iManager > Role > Storage > Volume より Mount Point を変更してしまいます。/media/nss/new を作り、

oes11x1:/media/nss # mkdir new

iManager からマウントポイントを変更します。

これで、VOL: は別なマウントポイントにマウントできます。

oes11x1:/media/nss # mount

/dev/xvda2 on / type ext3 (rw,acl,user_xattr)

proc on /proc type proc (rw)

sysfs on /sys type sysfs (rw)

debugfs on /sys/kernel/debug type debugfs (rw)

udev on /dev type tmpfs (rw,mode=0755)

tmpfs on /dev/shm type tmpfs (rw,mode=1777)

devpts on /dev/pts type devpts (rw,mode=0620,gid=5)

fusectl on /sys/fs/fuse/connections type fusectl (rw)

securityfs on /sys/kernel/security type securityfs (rw)

none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

none on /var/lib/ntp/proc type proc (ro,nosuid,nodev)

admin on /_admin type nssadmin (rw)

novfs on /var/opt/novell/nclmnt type novfs (rw)

/dev/pool/P1 on /opt/novell/nss/mnt/.pools/P1 type nsspool (rw,name=P1)

VOL1_NEW on /media/nss/new/VOL1 type nssvol (rw,name=VOL1_NEW,norename)

oes11x1:/media/nss #

ということで、Novell Openenterprise Server のボリューム名の変更とマウントポイントの変更は容易に数分で完了します。

ここで説明した手順はあくまでも、順序が逆で、新しい革袋に古い葡萄酒を詰める方法ではないじゃないか、という事になります。

そこで実際に想定する、新しい革袋に古い葡萄酒を詰め込む方法としては、

1) 新しい iSCSI デバイスを iSCSI イニシエーターで接続
2) 新しい iSCSI デバイスに対して iManager から VOL_NEW を作成して定義、/media/nss/new/VOL にマウント
3) nwcopy などでアクセス権などをまとめてcron などで VOL: -> VOL_NEW: に定時コピー

- ここは移行期間中 -

4) 使用禁止の宣言(ここからが本番移行の始まり)最終同期を行う
5) server/VOL: の名前を iManager から server/VOL_Old に変更
6) /media/nss/VOL のマウントポイントを　/media/nss/OLD/VOLに変更
7) /media/nss/NEW/VOL のマウントポイントを /media/nss に変更

これでログインスクリプトの変更も必要なく、ユーザが server/VOL: にアクセスする場合は新しい革袋の中の葡萄酒となります。

8) ncpcon で disable write VOL_OLD をセットして、古いボリュームを書き込み禁止に
9) ユーザに解放、もし、コピーされていないファイルがあったり、おかしな現象が出た場合のために、 VOL_OLD の中身は DLT メディアやＨＤＤメディアにバックアップコピーを取り、半永久保存のアーカイブを取る。
10) VOL_OLD:を eDirectory 上から削除して、iSCSI Ｉｎｉｔｉａｔｏｒから 古い iSCSI デバイスをデタッチして撤去。

という手順となるでしょう。

--
Novell Openenterprise Server を仮想化した状態で iSCSI と併せて運用すると、容易に、しかも慎重に計画したプラン通り移行すれば、わずか数分から数十分の停止時間で、古い革袋から新しい革袋にデータを移行させることができます。

-Keyword-
Novell Openenterprise Server ファイルサーバー移行、ファイルサーバーマイグレーション、Windows ダウンタイムの削減


問い合わせ
islandcenter.jp

時そばWindows10 を XEN on SUSE にインストールしてみた。

取り急ぎ Windows 10 のプレビュー版(32bit) を XEN on SUSE の仮想環境にインストールしてみました。なぜ今さら 32Bit 版なのかというと、仮想サーバーにそれほどメモリも余裕ないですし、32Bitと 64Bit ではＤＶＤのバイナリサイズが１Ｇ程度の差があります。ダウンロードの負荷も考えて、とりあえず、32Bit 版を落としてみました。

「ひぃ、ふぅ、みぃ、よ、イツ、むぅ、ヒチ、ハチ、オイ蕎麦屋、今何時だ」

「へぃココノツでぇ」

ってなわけで、落語で９を飛ばした時そば Windows10 です。

Virt Manager のサマリです。

- 2G メモリ
- 20Gb 仮想ディスク
- 2 vcpu
- テンプレートは Windows7'(32bit)

の構成です。64ビット版の場合、この1.5倍から２倍程度のリソースが必要でしょう。なぜか SLES11sp3 では、ハードウェアのトラブルなのか、インストール中にサーバの動作が怪しくなったので、 SLES11sp2 の SSD 上に仮想ディスクを確保しました。


キーボードとＩＭＥは Japanese が選択できました。


カスタムインストールを選択しても、大して設定する事はありません。精々ディスクパーティションを分けるくらい。


ファイルのコピーが終わると、再起動です。ＳＳＤなので１０分もかかりませんでした。


Express Setting だと何されるかわからないので Custom を選択


ネットワークがセキュアな内部ネットワークなのかパブリックなのかの確認


Update Your PC and Apps：ON を選ぶととんでもないことになりました。


Microsoft にデータを送るかどうかの確認、一応ＯＮのまま


Microsoft アカウントで同期させるかどうかの確認：ＯＮ これも敗因になるかも


Microsoft のアカウントにサインイン


しつこく Microsoft アカウントの確認です。


どうも Microsoft からコードが送られてくるようですが、まだメールも使えない状態でどう確認するのでしょうか。メールも来ませんでした。


仕方がないので I can't do this right now を選択


手持ちのＰＣとの同期を取ろうとしているようです。どうせなら新しい環境で


なのに何故か OneDrive と同期しているようです。


「え”！」 Windows ストアアプリとの同期を取り始めたようです。


何故か私の好みのタスクバーを上に上げた状態で起動しました。デフォルトで拡大鏡が起動するのですが、その設定も引き継いでいます。


ＤＯＳ窓を開くと Windows のバージョンは 6.4 に..... どこも変わってない。


SUSE の Virtual Machine Driver Pack 2.1 を当てると、初めて見たブルースクリーン。 SUSE の VMDP 準仮想化ドライバは使えません。


日本語の IME をインストールしたので、一応日本語入力ができます。


Ｃ：ドライブは32Bit 版で８Ｇ弱使いました。64ビット版では１０Ｇ程度は必要でしょう。2 in 1 PC やタブレットではちょっと64ビット版は辛いかも。


--
企業向けに Windows10 を選択する場合は Microsoft アカウントをどうするか、という問題がありそうです。やっぱりドメインで管理したいのでしょうが、Microsoft の戦略として、ドメインやプライベートなパーソナライズも全てクラウドに任せてしまえ、というちょっと怖さを感じました。

この後、OneDrive に保存したデータが次々と送り付けられてきます。どうせ保存容量なんて５Ｇｂなのですが、こうも無邪気に同期してくれると、ネットワークのアップストリーム側の帯域の心配が出てきます。

また、タブレットなどの場合、あっという間に月内の通信制限を使い果たしてしまうでしょう。インストールは Wifi で、ブロードバンドにつながる状態でやるべきです。もっとも途中にプロクシがあっても、固定ＩＰにしたくても、ARP ポイズンを使った、デバイスブロッカーがあっても、できないものはできない。その内何か解決策は出てくるのでしょうが。

オフラインでのインストール手順を確認しておく必要があるでしょう。

--
実際に、エンドユーザが使い始めると、ヘルプデスクや運用管理者には大きな負担がかかります。実際にエンドユーザが利用を始める前に、このボタンを押すと何が出てくるかを確認しておくことも重要な仕事でしょう。

マイナーチェンジに近いので、ＵＩさえ慣れてしまえば、それほど大きな問題はありません。逆に言うと Windows 8 の問題もそのまま引きずることになります。

搭載メモリが２Ｇの時代は32bit で導入したケースが多い Windows7 です。これを 64ビット化するチャンスでもあるし、そのまま Windows7 を 64bit 化して導入する方が負担が低いという事もあります。そうは言っても来年はこの画面に嫌でも付き合わなければなりませんね。逃げていては、いつか社内のシステムがレガシー化してしまいます。今さら Windows7 という訳にも行かないでしょうから、このスクリーンにまず慣れること。これが第一歩です。

islandcenter.jp

openSUSE 13.2 bata リリース中

世間は Windows10 で話題になっていますが、openSUSE 13.2 bata の配布が始まっています。

openSUSE 12.3 のダウンロード
http://software.opensuse.org/123/ja

Windows8.1 の次は Windows10 ? これじゃ落語の時蕎麦だ。

そういう手があったのかと。

Microsoft、Windows 10プレビュー版を公開―次世代OSは“Windows 9”ではなかった
http://jp.techcrunch.com/2014/10/01/20140930microsoft-announces-windows-10/

じゃ９はどこ行った？ はい、Windows ときそば9は飛ばされました。

という突っ込みは置いておいて、どこも喧伝するのはUIの変更だけ。つまり化粧直し。ひょっとすると、Windows8x を Windows10 風にするＵＩのフリーウェアなんかが出てくるのでしょう。

何にも「画期的」な機能や素晴らしいテクノロジーが増えたわけじゃなさそうですね。おそらく現状の Windows7 系のソフトウェアや周辺機器なんかはそのまま動くでしょう。 Windows8 発表以後 Microsoft は何をやってきたのか。その成果がただの化粧直しだとがっかりです。

SUSE Linux での bash 脆弱性パッチ

bash の脆弱性に関する SUSE での対応、パッチなど。

CVE-2014-6271 & CVE-2014-7169 - Shellshock
https://www.suse.com/support/kb/doc.php?id=7015702
サブスクリプション登録している場合はアップデートします。

それ以外の場合は個別ダウンロード、パッチ適用します。
SLE, Bash CVE-2014-7169, CVE-2014-6271 patch
https://download.suse.com/Download?buildid=nNXClbWqawg~
なお、このダウンロードリンクは Attachmate/SUSE アカウントが必要です。’（登録無料）


islandcenter.jp