タグ:システム管理 ( 77 ) タグの人気記事


Windows10 GPOでドライブを非表示にする。

10年前にこんな記事を書いたのですが、未だにご覧になられる方がいらっしゃるようで気になっていました。

グループポリシーでドライブを非表示にする。

という事で、 Windows10 でも、エクスプローラからドライブが非表示にできるかどうかを試してみました。


Windows のドライブは勿論、アルファベットのA~Zまであるのですが、意図的に見せたくないドライブもあります。例えばC:ドライブに勝手にディレクトリを掘って、そこに重要なデータを保管されたりすると、いざ、PCがご臨終になった場合に、データが無くなったとウルサいエンドユーザさんもいるわけですね。できれば、C:とD: は別なパーティションにわけて、D:ドライブは自由に使ってもいいけどC:ドライブは、システムを復旧した時に保証されないよ、という事もあるわけです。ついでに、ドキュメントフォルダなんかはD:ドライブに割り当ててあげて、タスクスケジューラなんかでD:ドライブだけをNASなどの隠しドライブに Robocopy してあげれば、最低限ユーザのデータのバックアップは為せば成る。

また、USB記憶装置なんかをつないだ時に、ドライブレターが、エクスプローラに表示されなければ、コピーすることもできません。「なぜコピーできないんだ」と言われれば、それは「セキュリティポリシーだから」で済むわけです。そこで、例えばネットワークに割り当てたP:とかS: とか以外は見せたくないという事も考えられるわけです。

という事で、エクスプローラから、見せたくないドライブを隠してしまおう Windows10 版です。もっとも、エクスプローラからは見えないだけで、コマンドプロンプトや、保存したり開く時のアドレスバーに直接ドライブ名を入れてしまえば、見えてしまうのですが、おおよそ9割のエンドユーザさんはそんなことお構いなしに「見えないものは無いもの」と考えてくれるわけですから、それなりに便利だともいえます。



- 基本編 -

さて、グループポリシーエディタ gpedit のドライブを隠す設定は

  1. [ユーザーの構成]、[管理用テンプレート]、[Windows コンポーネント]、[エクスプローラー]
  2. [指定したドライブを [マイ コンピューター] 内で非表示にする] を開く
  3. [指定したドライブを [マイ コンピューター] 内で非表示にする] ダイアログ ボックスで [有効]
  4. ドロップダウン ボックスで該当するオプションをトグルして設定

という手順になるのですが、

a0056607_10500340.jpg


ただ、この gpedit のテンプレートでは、決め打ちのドライブを隠す設定だけなので D: とネットワークに割り当てた P: と S: だけは見せたいとかのカスタマイズができません。という事で、この「隠しドライブ」をカスタマイズしてみましょう、というのがテーマです。



- 不可視ドライブをカスタマイズする -

C:\Windows\PolicyDefinitions の下に WindowsExplorer.adml というファイルがあります。C:\Windows\PolicyDefinitions が本体で、さらに ..\ja-JP\ に翻訳した内容が記述されています。

C:\Windows\PolicyDefinitions\ja-JP>dir WindowsExplorer.adml
ドライブ C のボリューム ラベルは WindowsC です
ボリューム シリアル番号は 1856-98D7 です
C:\Windows\PolicyDefinitions\ja-JP のディレクトリ
2016/07/17 07:15 80,922 WindowsExplorer.adml
1 個のファイル 80,922 バイト
0 個のディレクトリ 25,201,598,464 バイトの空き領域
C:\Windows\PolicyDefinitions\ja-JP>

翻訳はメモ帳で開くとこんな設定が書かれています。gpedit に出てくる内容そのまんまですね。

: 略

<policyDefinitionResources xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; revision="1.0" schemaVersion="1.0" xmlns="http://schemas.microsoft.com/GroupPolicy/2006/07/PolicyDefinitions">;
<displayName>表示名をここに入力する</displayName>
<description>説明をここに入力する</description>
<resources>
<stringTable>
<string id="ABCDOnly">A、B、C および D ドライブのみを制限する</string>
<string id="ABConly">A、B および C ドライブのみを制限する</string>
<string id="ABOnly">A および B ドライブのみを制限する</string>
<string id="ALLDrives">すべてのドライブを制限する</string>
<string id="ClassicShell">クラシック表示のシェルをオンにする</string>
<string id="ClassicShell_Help">この設定を使用すると、管理者は特定の Windows シェルの動作をクラシック表示のシェルの動作に戻すことができます。

: 略

実体を開くと

C:\Windows\PolicyDefinitions>dir WindowsExplorer.admx
ドライブ C のボリューム ラベルは WindowsC です
ボリューム シリアル番号は 1856-98D7 です
C:\Windows\PolicyDefinitions のディレクトリ
2016/07/17 07:20 41,886 WindowsExplorer.admx
1 個のファイル 41,886 バイト
0 個のディレクトリ 25,188,646,912 バイトの空き領域
C:\Windows\PolicyDefinitions>

例えば翻訳では 「AB のみを制限する」内容がこのように記述されています。翻訳版の ja-JP の "string id=" の部分を "item displayName=" で定義しています。

: 略

<item displayName="$(string.ABOnly)">
<value>
<decimal value="3" />
</value>
</item>

: 略

ここで問題となるのが "decimal valu=" の部分です。





- 不可視ドライブの値を決定する -

ここで Decimal Value は Z~A をビットに見立てて、0 は見せるドライブ、1 は見せないドライブです。
Dex:3 は 0011b: 0x03 ですから "D:C:B:A: ドライブの B: と A: はビットが立って、制限して見せない"という事になります。

右からZ:Y:X: .... C:B:A: とビットで制限して、内容を10進数で表記しているわけです。実に面倒くさい。

例えば D:E:F:P:S: ドライブだけ見せて、他のドライブをエクスプローラーに表示させたくない場合、次の様なバイナリデータが、7桁の十六進数 0x3FB7FC7 となり、 Decimal 十進数では 66812895 となります。


**ZW|XWVU|TSRQ|PONM|LKJI|HGFE|DCBA <<-- Drive Letter
0011|1111|1011|0111|1111|1100|0111 <<-- Binary 1:Hide, 0:Show
0x03|0x0F|0x0B|0x07|0x0F|0x0C|0x07 <<-- Hex
66812895 <<-- Decimal

という事で、ドライブの見せ方を決定するには面倒で使えない Windows10 の「電卓アプリ」を使って、二進、十進の計算するわけです。

しかし電卓アプリよりこの面倒な数値を求めるサイトが、まだあるのでご紹介しておきます。とても便利です。


Drives to show/hide

不要なデフォルトの Show Only を Delete して、表示したいドライブレターをチェックします。"New" ボタンを押すと、必要最低限の情報だけを作ってくれます。

a0056607_10505797.jpg




Export すると、この様な hidedrive.adm が作成されてダウンロードできるので、参考にすると良いでしょう。 D:E:F:P:S: を表示する値は 66813895 になりました。0 は全部ビットが落ちて "ShowAll" で 67108863 は全部にビットが立って "HideAll" になります。

  : 略

CATEGORY !!WindowsComponents
CATEGORY !!WindowsExplorer
KEYNAME "Software\Microsoft\Windows\CurrentVersion\Policies\Explorer"
POLICY !!NoDrives
EXPLAIN !!NoDrives_Help
PART !!NoDrivesDropdown DROPDOWNLIST NOSORT REQUIRED
VALUENAME "NoDrives"
ITEMLIST
NAME !!ShowAll VALUE NUMERIC 0
NAME !!HideAll VALUE NUMERIC 67108863 DEFAULT
NAME !!DEFPS VALUE NUMERIC 66813895
END ITEMLIST
END PART
END POLICY
POLICY !!NoViewOnDrive
EXPLAIN !!NoViewOnDrive_Help
PART !!NoViewOnDriveDropdown DROPDOWNLIST NOSORT REQUIRED
VALUENAME "NoViewOnDrive"
ITEMLIST
NAME !!ShowAll VALUE NUMERIC 0
NAME !!HideAll VALUE NUMERIC 67108863 DEFAULT
NAME !!DEFPS VALUE NUMERIC 66813895
END ITEMLIST
END PART
END POLICY
END CATEGORY ; WindowsExplorer
END CATEGORY ;; WindowsComponents

: 略




- 実装してみる -

メモ帳などのテキストエディタで、 C:\Windows\PolycyDefinitions の中身を書き換えて追加する隠しドライブのポリシーを追加します。上書きできないのでいったん保存して、ファイルのバックアップを取ってから、ファイルを PolicyDefinicions にコピーして実装します。

C:\Windows\PolicyDefinitions>type WindowsExplorer.admx

: 略

<item displayName="$(string.DEFPSonly)">
<value>
<decimal value="66813895" />
</value>
</item>

: 略

C:\Windows\PolicyDefinitions\WindowsExplorer.admx は所有者が Administrator でなければ上書きできません。ファイルのセキュリティの詳細から所有者を Administrator グループなどに変更する必要があります。一応バックアップをとってから書き換えることができました。

C:\Windows\PolicyDefinitions\ja-JP>type WindowsExplorer.adml

: 略

<stringTable>
<string id="ABCDOnly">A、B、C および D ドライブのみを制限する</string>
<string id="ABConly">A、B および C ドライブのみを制限する</string>
<string id="ABOnly">A および B ドライブのみを制限する</string>
<string id="ALLDrives">すべてのドライブを制限する</string>
<string id="DEFPSonly">DEFPSのみ見せる</string>
<string id="ClassicShell">クラシック表示のシェルをオンにする</string>
<string id="ClassicShell_Help">この設定を使用すると、管理者は特定の Windows シェルの動作をクラシック表示のシェルの動作に戻すことができます。

: 略

この様な感じで、追加したポリシーを書き換えて保存します。

このC:\Windows\PolicyDefinitions\ja-JP\WindowsExplorer.adml ファイルはいったん別なディレクトリに保管して管理者として上書きします。

実装前

G: I: が見えています。

a0056607_10542889.jpg




"DEFPS のみ見せる"が出てきました。「有効」にポリシーを設定して「適用」します。

a0056607_10562741.jpg


グループポリシーを即座に適用します。

C:\WINDOWS\system32>gpupdate.exe
ポリシーを最新の情報に更新しています...
コンピューター ポリシーの更新が正常に完了しました。
ユーザー ポリシーの更新が正常に完了しました。
C:\WINDOWS\system32>

エクスプローラからC: H: I: ドライブが消えました。

a0056607_10552891.jpg



S:にネットワークの共有記憶領域を割り当てます。S:は見えるようです。



--


今回は、単体PCで実施しましたが、 ZENworks Configuration Management では、変更したPCで iManager から設定し、サーバーにアップすれば良いかと思います。 Windows ドメインを使う場合は、たぶんどこぞの隠し共有フォルダにこのファイルがあるので、書き換えて管理できるでしょう。

このグループポリシー自体をカスタマイズする方法は、他で紹介されているような、直接レジストリを書き換える方法より安全でしょうし、また、他にいくつかの Hide Drive Policy を作っておけば、ドメインユーザや ZENworks ユーザによって、管理者、ヘルプデスク、一般パワーユーザ、一般ユーザ、先生、生徒の様に様々なパターンが二つのファイルのカスタマイズでできるので便利です。





-Keyword-

Windows, Windows10 特定のドライブ, ドライブが見えない, ドライブを不可視, ドライブを隠す, 特定のドライブを非表示, グループポリシー, How to Hide Drive letter from Explorer,

[PR]
by islandcenter | 2017-10-19 11:14 | ZENworks | Trackback | Comments(0)

モバイルファースト(働き方改革時代)のIDS/IPS(不正侵入検出、排除)とIT資産管理

ipv6 は殺してしてしまえ。検疫システムの限界 - 今後のIT資産管理

というブログを数年前に書いて、不正端末検出システム(IDS/IPS)の限界を探ってみました。

ま、大した反響もなかったンですが、最近、普段持ち運び用のPCがご臨終になったので、色々物色していました。何しろPCというのはスマートフォンやタブレット端末に向く「デジタルコンシューマー」のツールではなく、その中身を作る「デジタルクリエーター」のツールなのですね。少なくともオフィスにおいてはです。という事で何とか 13.3 Inch の「ちょっと重いけど」フルスペックの安物ノートを手に入れました。ところで、この種の「カバンPC」を探すうえで色々物色して問題となるのが、薄さと軽量化を求めるとオンボードで RJ45 のポートが標準装備というPCが中々手ごろなのがない、という事です。

- 脱着可能な Ethernet アダプタ -

でも「やっぱりNASの中に大量にある、馬鹿みたいにデカい映像や画像、資料からデジタルコンテンツとして、資料見ながら、文書から簡単な映像、プレゼンテーション資料、プログラミングまで、一つのコンテンツを作るなら有線接続だよね」という事になると、多くの 11.1 ~ 13.3 Inch モバイル系PCの多くは、有線LANポートを持っていません。無線アダプタはIDSなどの不正端末検出システムに正規の物として登録しても、速度面ではやっぱり 802.11ac 規格より、有利な有線で 1Gb ネットワークを使いたい、という事で USB TypeC 用の RJ45 変換プラグとかをホワイトリストに登録して使うわけですね。これ、簡単に脱着できるし、簡単に無くすし、別なPCに繋いでも、同じ MAC アドレス使っているのでDHCP環境では同じIP振られる可能性が高く、単に「未登録のPC」に不正使用していただく事もできるわけです。IPS の Arp Poisoning による不正端末検出、切断なんて全然使えません。

「あれ、オレのこのノート、ゲストは繋がんないねぇな」
じゃぁこのアダプタで繋いでみたら?」
「あ、繋がるねぇ」

という事になります。何しろMACアドレスによる arp poisoning は PC 本体の情報ではなく、PCに半永久に実装されている Ethernet Port の MAC アドレスを登録することで、未登録のデバイスにアタックを与えて接続拒否をするからです。「脱着可能な Ethernet Adapter」なんて、「アウトオブ眼中」なのですね。

- テザリング端末 -

まぁ最近のスマートフォンってのは、普通にテザリング機能があるわけですね。当然 IDS にはスマートフォンが社内ネットワークにつながる時は Wireless デバイスの接続の許可/非許可を、システム担当者は IDS 内部に設定できるのですが、テザリングを有効にした後の、その先のタブレットだとか無許可ノートPCなんてのはチェックできない。

勿論、普段使いの BYOD スマートフォンは許可とって、従来型のエージェントレスの IDS/IPS に登録していたとしても、テザリングで「オレんちで使っていたオレのノートPC」も同じ手段で社内に接続ができてしまうのです。現在の普通のIDSシステムではこれを拒否る機能はまずなさそうです。そこで「My持ち込み無許可PC」を「許可付きスマートフォン」のテザリング機能で繋いでしまえば、いくらでもデータコピーができて風呂敷残業ができてしまいます。

- VPN接続 -

何やら「働き方改革」というのがキーワードになる近年、経営側だけのメリットを考えると無駄な残業代をカットしたり、オフィススペースの賃料を節約するために、狭いフリーアクセスフロアにして、経営側は成果、結果ではなく、時間でしか成果を評価できないクセに「ウチで仕事してもいいよ」という事が、どうもぶっ飛んだ企業では流行りになりそうです。当然、これも、IDS/IPS では検出できない。当然VPNで繋ぐにはそれなりの設定というのが必要なんだろうけど、普通は、VPN ゲートウェイのユーザIDとパスワードなんで、自宅で悪い事しているPCでもIDとパスワードを登録すれば、接続できてしまいます。

何しろ「働き方改革」は、与党の民衆への人気取り政策であり、「働くオフィスドレイの為の政策」ではないのです。何しろ多くのIDSで検知できるのはVPNサーバーの MAC アドレスだけ。当然、VPNの向こうの平和だったり、平和でもない家庭のネットワークなんぞ、知らんぞな、もし。という事なのですね。もし、そんなユーザにとっては当たり前の環境を検出できずに、繋がっちゃった場合、責任を取るのは結局「現場のネットワーク管理者の減点5」になるわけです。

-これからのIDS(不正侵入者検出、ブロック)の機能は-

やっぱり、接続可能なデバイスの「システム内部」の全てに何等かのエージェントをインストールして「マーキング」をして、マーキングがないデバイスは接続は許さんぞ、というシステムが必要なような気がします。これらは Windows, MacOS, iOS, Android, Linux など全てのシステムソフトウェアに対応している必要があり、システム管理者に対して「お前働くドレイなんだから、それインストールするのに八王子の山奥に住んでいるオレんちまで来て仕事しろ」というユーザがいるかも知れませんが、黙って高尾山の蕎麦屋のレシート確保してでもやるべき仕事かもしれません。

- やっぱりはびこるセキュリティ根性論 -

私はパスワード管理もウィルス対策も、基本は「根性論」であると考えています。システムとしていくつかの障壁を作ってみても、今あるIDSによる不正接続検出に限界がある以上、「やっていい事」「悪い事」はそれぞれユーザに教科する根性論が重要になります。「悪い事」を教えるのはシステムの穴を教えるようなモノなのですが、「やってもいい事」だけのリストではそれ以外は、グレーリストになるため、ブラックルールも明示し、それなりのペナルティを用意しておくことも必要だろうな、という根性論なのです。またグレーゾーンをどう探し出して、運用基準を定期的にアップデートするかのシステム運用側の「根性論」も重要でしょう。

--
という事で、「今考えられる働き方改革の障害となる不正アクセス検出方法」のホワイトリストに俄然と存在するブラックホールを幾つか考えてみました。単純な IP Poisoning によるIDS/IPS にはもう限界があり、それなりのシステム側の対策には様々な方法が見当たるのでしょうが、その都度、新たな投資を考えなければならないのです。









[PR]
by islandcenter | 2017-10-13 10:41 | プライベートクラウド | Trackback | Comments(0)

Windows10 デスクトップにコントロールパネルを表示させるには

Windows10 初期版では「田(デン)」アイコンを右クリックすると「コントロールパネル」のメニューが出てきたのですが Creators Update 以降、「アレ? 無いぞ」と慌ててしまいます。メニューから無くなってしまいました。コントロールパネルは、だんだん「設定」メニューに取り込まれるようですが、やはりまだ使いたい。

Creators Update で「コントロールパネル」を出すには、「田(デン)」ボタンの横の「〇(マル)」のCortana ボタンから「コントロールパネル」をキーボードを叩いて検索して、アイコンを出すのが一番、初歩的な方法です。でも私の様に、キーボード叩くのが面倒なモノグザ人間が頻繁に「コントロールパネル」を使いたい場合は面倒です。

一度「コントロールパネル」が立ち上がってしまえば、タスクバーにピン止めしてしまうのがいいでしょう。

a0056607_15082200.jpg


まぁ、Microsoft としては、できるだけ Cortana を使わせたいのでしょうが、所詮 iOS や Android と違って PC 用OSですから、マイクロフォン内蔵のPCなんて珍しいでしょうし、「マイクロフォン内蔵のデスクトップPC」なんかがあって、机の下の足元にPCを設置しているような場合、オフィスのみんなが机の下に潜り込んで「モゴモゴ」言っている光景なんて珍妙な事この上ない。それにウルサイ。PCにスピーカーが付いていてもほとんど利用できないようにしているのが普通ですから、やっぱりPC用システムに Cortana は使い物にはならない無用の長物でしょうね。やっぱり 「Cortana 小僧」を呼び出して、町のご隠居こと「 Google 大先生を呼んでもらう」程度の使いっパシリにはそれなりに便利でしょう。

他に簡単にコントロールパネルにアクセスするには、デスクトップにアイコン表示をさせる事です。これは Windows10 Creators Update の物ですので、そのうちに「お亡くなり」になる可能性がありますので 2017/10 現在の情報です。

C:\>ver
Microsoft Windows [Version 10.0.15063]
C:\>winver

a0056607_15032658.jpg

デスクトップの壁紙を「右ボタン」> 「個人用設定」を開きます。

a0056607_15084354.jpg

「テーマ」の一番下に「関連設定、デスクトップアイコン」というメニューがあります。このメニューの中はデスクトップに「ごみ箱」しかチェックが入っていないのですが、「コントロールパネル」にチェックを入れると「コントロールパネル」アイコンがデスクトップに表示されます。

a0056607_15085700.jpg

「コントロールパネル」が大好きな人には、簡単にアクセスする方法としては一番簡単かもしれません。






-Keyword-

Windows10, Creators Update, コントロールパネル, コントロールパネルが表示されない, コントロールパネルの表示, ごみ箱, ごみ箱が表示されない。

[PR]
by islandcenter | 2017-10-11 15:14 | Windows | Trackback | Comments(0)

How to Prevent or Disable to "REBOOT" with "Ctrl+Alt+Del" by accidentally miss hit key on SLES12, openSUSE.
SUSE Linux Enterprise Server 12, openSUSE で Ctrl+Alt+Del キーで誤ってリブートさせないようにするには

誤って、"Ctrl+Alt+Del” という萬金丹の様な万能の薬が PC 用 OS には付いてきます。大抵の Linux のディストリビューションでは、この操作は Reboot に割り当てられます。でも、サーバーで運用して、"間違ってやっちゃった" ら大変な事になるでしょう。構内電話は鳴るわ、ナイフとフォークは飛び交うわ、愚痴の連続と誰かの首が飛ぶわ、ではたまったものではありません。そこで、通常はサーバー運用では、無効にするケースが多いと思います。

SLES12 より initd から systemd にサービス管理が変わった事で、 /etc/inittab が無くなりました。
SLES11 までは inittab の ctrlaltdel の行を comment out して再起動すればよかったのですが

SLES11:/etc # cat inittab | grep ctrl
# ca::ctrlaltdel:/sbin/shutdown -r -t 4 now
SLES11:/etc #

SLES12 では、inittab 自体がありません。その代わり、 reboot.target ファイルにエイリアス ctrl-alt-del.target が記述されています。


SLES12SP3:~ # cat /usr/lib/systemd/system/reboot.target
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Reboot
Documentation=man:systemd.special(7)
DefaultDependencies=no
Requires=systemd-reboot.service
After=systemd-reboot.service
AllowIsolate=yes
JobTimeoutSec=30min
JobTimeoutAction=reboot-force
[Install]
Alias=ctrl-alt-del.target
SLES12SP3:~ #

- 対策 -

Ctrl+Alt+Del を無効にする方法について opensuse のフォーラムにそのものズバリの回答がありました。

Thread: Alt + Ctrl + Del again

- Default -

初期値では ctrl-alt-del.target ファイルはありません。

SLES12SP3:~ # ls /etc/systemd/system/ctrl-alt-del.target -al
ls: cannot access '/etc/systemd/system/ctrl-alt-del.target': No such file or directory
SLES12SP3:~ #

そこで yast から Ctrl+Alt+Del を無視するように変更します。

# yast2 &
> Security and Users > Security Center and Hardening > "Boot Settings" > "Interpretation of CtrL+Alt+Del " : "Reboot" --toggle--> "Ignore"

a0056607_18251220.jpg


set to "Ignore" > "OK"

a0056607_18254112.jpg

# yast (from text console)
> Security and Users > Security Center and Hardening > "Boot Settings" set to "Ignore" > "OK"

a0056607_18261915.jpg

デバイス /dev/null へのリンクが作成されます。

SLES12SP3:~ # ls /etc/systemd/system/ctrl-alt-del.target -al
lrwxrwxrwx 1 root root 9 Oct 9 16:57 /etc/systemd/system/ctrl-alt-del.target -> /dev/null
SLES12SP3:~ #



再起動は必要ありません。結果は即座に反映されます。Reboot is NOT needed. The results are immediately reflected.

単に、このリンクがあるかないかで判断するようです。試しにこの ctrl-alt-del.target ファイルを削除してみると、YaST でもデフォルトの ”Reboot" に戻っていました。





-Keyword-
SUSE Linux, SLES12, opensuse, Ctrl+Alt+Del, disable to reboot, prevent to reboot, 誤って再起動させてしまう, How to, YaST,ctrl-alt-del.target ,Ctrl+Alt+Del を無効, 無視,




SLES12SP3:~ #

[PR]
by islandcenter | 2017-10-09 18:30 | SUSE | Trackback | Comments(0)

ここでは Linux, Windows のシャットダウン、リブートの方法について説明します。

1) .Linux のシステムを停止、電源遮断する

Linux システムのシャットダウン、再起動コマンドは shutdown コマンドを
実行します。

- 参考ページ -

シャットダウンして、電源遮断(Halt)をするには

# shutdown -h 0 または
# shutdown -h now

シャットダウンして、再起動(Reboot)をするには

# shutdown -r 0 または
# shutdown -r now

-h は halt, -r はリブートの意味です。0 は「0分後」つまり今すぐの意味です。

SLES11の場合

SLES11sp4:~ # shutdown --help
shutdown: invalid option -- '-'
Usage: shutdown [-akrhHPfnc] [-t secs] time [warning message]
-a: use /etc/shutdown.allow
-k: don't really shutdown, only warn.
-r: reboot after shutdown.
-h: halt after shutdown.
-P: halt action is to turn off power.
-H: halt action is to just halt.
-f: do a 'fast' reboot (skip fsck).
-F: Force fsck on reboot.
-n: do not go through "init" but go down real fast.
-c: cancel a running shutdown.
-t secs: delay between warning and kill signal.
** the "time" argument is mandatory! (try "now") **

SLES12 の場合

sles12sp3:~ # shutdown --help
shutdown [OPTIONS...] [TIME] [WALL...]

Shut down the system.

--help Show this help
-H --halt Halt the machine
-P --poweroff Power-off the machine
-r --reboot Reboot the machine
-h Equivalent to --poweroff, overridden by --halt
-k Don't halt/power-off/reboot, just send warnings
--no-wall Don't send wall message before halt/power-off/reboot
-c Cancel a pending shutdown
sles12sp3:~ #



2). Windows のシステムを停止、電源遮断する(特にリモートデスクトップ)

通常にスタートボタン(田ボタン)からシャットダウン、リブートします。

Windows Server 系ならリモートデスクトップでも「田ボタン」から、シャットダウン、再起動のメニューが使えますが、Windowsクライアント系(VDIデスクトップ)の場合、リモートデスクトップから、再起動のメニューが出ません

もしWindows のリモートデスクトップを使ってシャットダウンする場合はDOS プロンプトを開いて

> shutdown /s /t 0 (シャットダウン)
> shutdown /r /t 0 (再起動)

か、

必ずフルスクリーンモード alt+f4 キーでシャットダウンのダイアログが出ます。

a0056607_13562995.jpg

こちらをご参考ください。



Windows2008 系を KVM/XEN で仮想化している場合、「シャットダウンしています...」が60秒以上かかる場合、あるいは、シャットダウンし切れない場合があります。

動きがない場合 virt-manager & から Force Off しても構いません。

あるいはコマンドラインで

# virsh(あるいは xm or xl ) destroy my-vmachine-Name_or_vmID_num

で強制終了させます。


3).仮想化ハイパーバイザホストで fsck する場合がある

なお、長期連続運用後、再起動させた場合、fsck プロセスが走る場合があります。

これは長期間 fsck をしていない場合に必ず行う checkdisk の様な物なので、進捗具合を見ながら放置してください。

数分から数十分かかる場合がありますので、慌てて電源を切らない事です

OS起動時のfsckのチェック間隔 (※SLES11の場合)

Superblock があるパーティションで

sles11sp4:~ # tune2fs -l /dev/sda9 | grep interval
Check interval: 15552000 (6 months)
sles11sp4:~ #
sles11sp4:~ # tune2fs -l /dev/sda8 | grep -i mount
Last mounted on: <not available>
Default mount options: (none)
Last mount time: Fri Sep 29 13:39:19 2017
Mount count: 44
Maximum mount count: -1

デフォルトでは6か月以上 fsck をしない ext3 パーティションは強制的に fsck されるようです。マウント回数は -1 なので無限大の様です。強制的に fsck させない場合は shutdown コマンドで

-f: do a 'fast' reboot (skip fsck).

オプションを使います。

※ このケースは SLES11 の ext3 フォーマットでのデフォルトです。SLES12 では BtrFS と XFS をデフォルト使用しませんのでこの限りにあらずです。



SUSE SLES11, ハイパーバイザーのメンテナンス、Linux, Windows, シャットダウン、再起動



[PR]
by islandcenter | 2017-10-03 14:00 | SUSE | Trackback | Comments(0)

地味で意味不明のKSKロールオーバー

総務省の「勧告」があり始めて知りました。


※ DNSについては「知っている」程度の知識なので、このブログの内容は内容は丸のみしないように.....関連文書はごっちょり出ています。

ネット史上初めての「KSKロールオーバー」が始まる、名前解決できなくなる前にDNSサーバーなど設定確認を! 今年9月は特に注意

影響があるのは、DNSサーバーを運用しているネットワークで、管理者は「何それ」と言って「朝日新聞」以外の大手メディアは「狼が来た」程度で、騒いでもいないので、突然の対策に苦慮しているようですね。

企業LAN、ネット遮断のおそれ 総務省が確認呼びかけ

詳細はこちら

KSKロールオーバーについて(JPNIC)

-まず DNSSEC-

大抵、一般企業のゾーン mycompany.com には www, mail, mydns など自社の社外向けサービスが、ISP の DNS マスターに記載されていて、企業の mydns は、ISP のマスターからゾーン転送を受けるスレーブとなって、もし、ISP の DNS が停止する場合のバックアップになります。逆に自社オンプレミスのDNSサーバーがゾーンマスターのケースもあります。

しかし、この二つは、お互い IP アドレスだけで信頼関係があるので、万が一、相手が「なりすましIP」を使うと、DNSのゾーン転送がうまく行かなくなり、メールの誤転送や、フィッシングサイトへ引き込まれたりします。そこで DNSSEC という鍵交換方式で相手のDNSが正しいかどうかを検証するのがDNSSEC という事らしいです。

. (ドット)のルートゾーンから、.jp -> .co.jp -> mycompany.co.jp までそれぞれゾーンを管理する団体が違うので、その間、どのような経路を通るのか分からないので DNSSEC を使ってお互いを確認しあう仕様になって7年目。本来、5年でルートゾーンのKSK 電子鍵 "Key Signing Key" を更新する予定だったのが、色々調整に手間取り、いよいよルートの鍵更新をするのがこの秋ということなのです。そもそも DNSSEC 自体、実装され始めて10年と経っていないDNSの保護対策なので、ワタシのように「古いエンジニア」には何がなんだかさっぱり。そもそも閉じた環境では 古いDNSサーバーをそのまま使っている場合、DNSSEC自体実装していないケースも多いようです。最新の Bind DNS では、 DNSSEC 自体デフォルトで Auto となっているケースがあるようなので、それぞれのディストリビューションに問い合わせて対策する必要がありそうです。

で、SUSE のマニュアルしらべてみましたが、named.conf の ”dnssec-validation” のパラメータの記述さえありません。勿論 YaST のオプションにも設定項目なし。逆に、dnssec の validation 機能の脆弱性情報に載っていたくらいなので、一つの脆弱性があれば、また次にも見つかる機能なので、無理して使わないのが、無難なのでしょうかね。

もともと私が愛用している Bind の教科書にも DNSSEC については、ほとんど記述がないほどの機能ですから、大多数意見では DNSSEC 自体は設定する必要はまず無いようです。上位 ISP にも問い合わせてみたら、「DNSSEC は無効にしている」という回答。そもそも資料も少ないですから。というか DNSSEC 無用(悪機能)論もあるくらいだから、ほとんど一般の管理者にとっては無視するのも仕方ないのかなと思います。DNSSEC は日本では 2017 年現在 10% 前後しか普及していないらしい論もあります。そもそもそれほど通信事業者間、公共団体で普及していないものを、取り出して「ああ、こう」言っても、聞く耳がないのも仕方がない事です。

- それでも起こるDNSのトラブル -

それでも上位ISP同志で鍵交換をする、この秋に、一般的なDNSクエリ以上のパケットサイズの通信が起こり、通常 1280 バイトのDNS更新情報が、1424 バイト程度まで膨らんでオーバーフローして情報が正しく伝わらない現象が「KSKロールオーバー」という現象です。この影響は全インターネットユーザの1/4程度が影響される可能性があるということなんですね。これほどの大袈裟な影響なのに、一般に認知されていないところは、ずいぶん疑問符が出てきます。

これによって、相手のウェブサイトの名前解決ができない。名前解決ができないため、メールが転送できない、という現象が大本営発表によると発生する(らしい)のですね。

実際に、SOHO向けルータのDNSサーバーを使っているワタシの様な零細事業者とか、スレーブDNSを自社にオンプレミスで運用しているとか、DNSについてはド素人なワタシのようなSI業者なんかがiDC の中の顧客のサーバーの面倒を見ているような場合は、「KSKロールオーバー? 何それ?」という事になり、ろくな知識もないまま慌ててしまう事になるわけです。

1) 確認方法

1-1) bind dig コマンドで dns の reply size limit の値をチェック

reply size limitの値が1424より大きいこと

sles11:~ # dig @dns2 +bufsize=4096 +short rs.dns-oarc.net txt
rst.x1008.rs.dns-oarc.net.
rst.x1968.x1008.rs.dns-oarc.net.
rst.x2454.x1968.x1008.rs.dns-oarc.net.
"173.194.171.12 sent EDNS buffer size 4096"
"173.194.171.12 DNS reply size limit is at least 2454"
"Tested at 2017-09-05 03:27:22 UTC"
sles11:~ #

※一発で答えが返らない場合もあるので2、3度繰り返してみてください。

1-2) DNSSEC Key Size Testのサイトでテストする。

にアクセスして、Result の 1~4が Pass していること、5は(This should fail なので) パスしないはず。
a0056607_13383419.jpg
以上で問題がなければ、一応、KSK ロールオーバー対策は「準備OK」という事になるそうです。

問題がある場合、上位ISPの DNS のプロに問い合わせて対策するのが一番のようですね。もっとも、「影響なし」と公表しているISPも少ないので、みんな知らないのも当たり前なのかも知れません。

2) DNS は最新版を

DNS サーバーはいったん設定を済ますと、中々中身をイジリたくないシステムです。でも Bind というソフトウェアはバグや脆弱性が多い事でも有名なソフトウェアなので、Bind を最新版に更新した方がいい。という事になります。

それにしても、この問題があまり大きく IT 関連のメディアにすら載らないし、ほとんど JPNIC と大本営総務省発表のコピペ記事で、具体性に欠けるのが最大の謎だったりします。

ご意見ある方のコメント期待しています。


KSKロールオーバー, DNSSEC, dnssec-validation, 無効化, 有効化




[PR]
by islandcenter | 2017-09-05 13:40 | SUSE | Trackback | Comments(0)

もう10年以上 XEN ハイパーバイザーと付き合ってきて、つくづく思うのは「あぁ、もうx86_64 のXENは終わったなぁ」ということです。別にLinux + x86_64 なら KVM でもいいんじゃん。

今でも考えられるケースで XEN を使うとしたら、

- XEN の Domain_U のカーネルを弄ってまで、他のハイパーバイザーに移行させたくない(これ結構大きい)
- BSD 系 Linux や Soralis と言った、非 Linux カーネルの UNIX OSをハイパーバイザーやゲストOSでも使っている(トモダチになりたくないな)
- ハードウェアに仮想化支援機能(VT機能) がない機器とか i386 ベースのx86ハードウェアでも仮想環境を使いたい(エラク古いPCだ)
- Intel x86 系の CPUを使っていない(PPCやIA64)とか (見たことないけど、もっとトモダチにもなりたくないな) )

こういった「今更な理由」がない限り Linux に限れば XEN による準仮想化を積極的に選ぶ理由がなくなってしまったのです。

まぁ、もともと10数年前に XEN 3.0 の登場とともに Intel=VT や AMD-V などの仮想化支援機能がハードウェアに実装されたと同時に XEN に「完全仮想化」というキラーな機能がついて、火が付いたと云えます。

と同時にこれらのVT機能の強化が続く中、普及と共にライバルの完全仮想化、64ビット版のみの KVM ハイパーバイザーが台頭してきたわけです。何しろ完全仮想化は QEMU にオーバーヘッドを渡すわけで、同じ QEMU を使う KVM ハイパーバイザーとの共通化が進んでいるわけですね。

ただし KVM ハイパーバイザーは当時としては主流だった VT 機能非搭載のPCサーバーや XEN を積極的に導入してきた非Linux 系の ISP やBSD系 Unix が主流の iDC の積極的な導入がなく、実績も少なかったので、まだまだ「開発中」といったイメージしかありませんでした。また、ハードウェアも仮想化を強く意識しないデュアルコアやクアッドコアがせいぜいでした。

しかし、VT機能というハードウェアの援護を受けて、KVM は一挙に広まっていった、という感じがあります。実際、XENで完全仮想化された Domain_U であれば、ほとんど仮想イメージを変更しないで KVM へ移植できてしまいます。何しろハイパーバイザーの補助をする QEMU という共通基盤があるため、XEN の完全仮想化はほとんど KVM との共通ワードとなっているわけですね。だから、 Linux On Linux の仮想化でも Full Virtual には、特に目立った機能の低下、スループットの低下はあまり感じなくなってきました。さらにはオクタコアやヘキサゴンコアなんていうハードウェアが、松竹梅の「竹程度」のサーバーに実装されると、ボトルネックはディスクI/O程度の問題になります。

SUSE 11.x の時代は XEN の全盛時代だったのですが、 SUSE では SLES12 以降、Libvirt の共通化により、オペレータは、自分が操作するハイパーバイザーが XEN なのか KVM なのか、強く意識しなくなりました。この原因は OpenStack の影響もあるでしょう。 SUSE は openstack に重点が移っているし、親会社の Microfocus も HPE のソフトウェア部門の買収に伴い、益々マルチベンダークラウドに力が入っていきそうです。

顧客も専用のハイパーバイザーと管理ツールによるベンダーロックインは避けたいところ。オンプレミスなクラウドと、iDC のプライバートクラウドと、AWS のようなパブリッククラウドとの間にあるマイグレーションを試みたい所です。まぁ日本のIT業界ではベンダーロックインというよりSI屋にロックインされているのですけどね。
SLES の仮想化コマンド自体も Libvirt の共用化によって、virsh コマンドにオプションの違いはあるにせよ、ほとんど xm, xl コマンドと同じ操作ができるようになってしまいました。こうなると、自分の操作するハイパーバイザーが XEN なのか KVM なのか、ほとんどオペレーターは意識する必要がなくなってしまいます。こうなると Citrix や VMware 専門のエンジニアのある種の閉鎖性が邪魔になってしまいそうです。

また openstack による統合管理を考えると、事業者におけるハイパーバイザーの一本化というのは避けて通れない(のかな)という事もあり、Linux + x86_64 主体のデータセンターでのハイパーバイザー運用は XEN ではなく KVM の一本化に進んでいくことになりそうです。

伝統的に XEN on BSD Unix などを使っていた iSP や iDC 事業者はさておき、数年後の新興サービスベンダーの若い技術者にとっては「XEN?何それ」化しそうな気がします。

--
こうなると "XENserver" を名乗る CItrix の戦略はどうなるのよ、という疑問がふつふつとわいてきます。世の中、完全仮想化に向いている中、Linux や BSD 系の「サーバー」OSを XEN ハイパーバイザーで管理する、という商品イメージはだんだんとネガティブに見えてきます。いまや XEN というブランドが、重しとして Citrix に乗りかかっているのですね。「あぁ Citrix, 昔 XEN でブイブイ言っていたベンダーね」と「聞いたことあるよ」という日がいつか来るでしょう。いや、その頃はもうXEN app というプロプラエタリなアプリケーションの仮想化ベンダーとして特化する中,早まって XENsource を買収したCitrix も XEN というブランド名を捨ててしまうのかも知れません。

もともと、Windows NTx 系のオペレーティングシステムをマルチユーザ化した Windows Remote Desktop も Cytrix が開発に関わった機能であり、Metaframe や XEN App といった、Citrix 得意のシンクライアント機能に特化した企業として存続していくのだろうけれど、サーバー集約化を目指す Xenserver といった製品の他社ベンダーや openstack や docker との差別化できない機能は、よほどのことがない限り、「世界のクラウドの Citrix 」化することはなさそうです。











[PR]
by islandcenter | 2017-08-08 15:19 | プライベートクラウド | Trackback | Comments(0)

お客さんのトコロで、フリーアクセスのオフィスに移転するという話と、併せて社員にノートPCをばら撒き、無線接続という話がありまして.....

うーむ。

じゃ私が求める仕事用ノートPCとは

1) Corei5 以上
2) 8Gb 以上のメモリ
3) 500Gb のハードディスク(SSDなら 256Gb 以上)
4) 有線用 RJ-45 コネクタ付き
5) 11 ~ 13 インチのスクリーンで縦は 1024 ドット以上
6) クルリポンの 2in1 でも USBメモリなど外部メディアで Linux が起動できる事 ,やっぱりクラムシェルがいい。
7) フットプリント A4以下で重さ 1.5Kg 以下
8) USB ポート3個程度
9) 外部 HDMI もしくは VGA ポート
10) 価格は 10万円を超えない程度(目標)
11) USB 外付けのポータブル光メディアデバイスは持っているし滅多に使わないからイラネ
12) 金属筐体と、ほぼ問題なく満足なブラインドタッチができる厚みのあるキーボード
13) 当たり前の BIOS パスワード ロック

と言ったところが、ITインフラエンジニアである「私が欲しいビジネスに必要なノートブックPC」です。

ところが、最近はあまりこのような仕様のPCが見当たらないンですね。

モバイル主体なら13インチ、A4モデルというと、紙っぺらみたいな1cm厚のノートが主流。勿論この厚さでは RJ-45 モジュラや、VGA ポートは問題外、しかも HDD ではなく 128Gb のSSD と4Gbのメモリという選択しか中々出てこないのですね。メモリとSSDはマザー直付けで固定。カスタマイズなし。割とこのテのPCは筐体の作りがしっかりしているようですが、ちょっと物足りないスペック。薄さは魅力だけれど、重要じゃない。外部I/Oは USB Type-C のみ。これはあまりお客さんにもお勧めしませんね。持ち帰り自宅仕事を増やすだけ。

結局、「ノートPCの厚み」というのは、アダプタ類を実装し、大容量低価格のハードディスクを内蔵するためのメリットじゃないかと思います。その分、フットプリントは犠牲になっても構わない。

Type-C用のネットワークとかUSB増設アダプタあるじゃん、と思った貴方は鋭い。しかし、エンドユーザという「彼ら」の仕事はそう言った「小物を紛失する」のも仕事なのです。小物だけじゃなくって、PC本体だって、自宅の鍵すらヨッパラって3件目の飲み屋とか電車に置き忘れる。これは上からも、下からも IT部門へのブツブツ不満となって帰ってくるわけですね。

そう言った「カッチョええ」PCは、自前でBYODして、混んだ電車のシルバーシートにハードボイルドに気取ってバキッと大股おっ開げて座り込み、意味のない無線信号飛ばしまくって、キーボードをバシバシ叩いて、じーっと目をつぶっている両隣のジジババを起こしてクソ餓鬼の写真でも見せびらかすためにあるのですね。とてもじゃないけど、ビデオ編集なんてできない。

私はエンジニアですから、フリーの技術ライターがお勧めする様なPCでは物足りません。客先で Hyper-V 仮想化とか、SUSE Linux の USB 起動+仮想化ハイパーバイザーブートが必要なので、ディスクの中身は仮想イメージだとか ISO なんかがごっちゃり入っています。必要であれば、出先の仮想環境でオペレーションマニュアル書いたりするので8Gbのメモリは必須です。そこまで酷使しなくても、8Gメモリは悲鳴を上げている。固定デスクトップは無条件に Linux サーバー化するので、ノートPCとは Windows のメインPCなのですね。

今のところ使っているのはマウスコンピューター製の 11.1 インチノートなのですが、ほぼこのスペックを満たしており、まぁは満足しています。が悲しいかな安物の二流国内メーカーで、プラ筐体なので、格安航空会社の格安チケットで出張中、モニタをゆっくり開いたらヒンジがバキリと音を立ててヒビが入りました。当然保証外。そこでほとんど自宅では、外部モニタが必須です。客先でもお借りすることがあります。電車の中でも安心して持ち運べる金属筐体が欲しい。やっぱりちょっと高いけど Dell とかレノボかな。パナとか東芝はちょっとお高く止まっている。VAIO はちょっと魅力。でもほぼコレというのは完全に20万円台の竹コースです。

ノートPCはキーボードもポインティングデバイスもモニタも「替えが利かない」ので、できるだけ長期保証が欲しい所ですが、このあたりも M-PC さん、ノートPCのキーボードもモニタもポインティングデバイスも消耗品扱いするので、ちょっと保証がモノ頼りない。以前 DELLの「像が踏んでも無償交換修理」という無敵の Dell Inspiron か何か使っていた事があったのですが、ベッドで使っている最中、眠ってしまい、夢の中でエルボーアタックでモニタにピキッとヒビが入った時は、2~3日で無償修理してくれました。結局5年間使えました。 結局お得でしたね。

電池の持ちはあまり気にしません。せいぜいUPS替わりに2時間も使えれば結構。その代わりACアダプタは必携です。どうせカタログで7時間と言っても1年もしないうちに半分くらいまでヘタります。

なぜ、ビジネス用PCに有線LANが必要かと言うと、「無線ほど信用できないモノはない」からです。接続の信頼性、スループット、スニッフィングの危険、気が付いたら「隣の家の無線を拝借していた事故」の防止。

この間もありましたけどね。有線無線両用している時にファイルサーバーとの接続がプチ切れる、ンで調べたら、隣のビルのコンビニからの電波がお客様が「拝借」して「お邪魔でぇーす」していたそうです。どうもゲスト用のパスワードなしのSSIDを捕まえてしまい、というトラブルです。勿論セキュリティもダダ漏れ状態。

ウチでも「激安アウトレット品」の Wifi ルータにヤラレタ事があります。DNS/DHCP は止められないし、デフォルトG/Wがインターネットルータになるので、ローカルLANのDNSを参照してくれないケースですね。こういったおバカ仕様だと当たり前ですが、無線/有線混在仕様だと、内部のシステムにアクセスできない事があり、ひどく怪しい動きをしてくれます。トンデモケースですが安物買いの銭失いですな。

それに最近はテザリングできるスマートフォンなんかあるわけで、カイシャにもどったら、さっき出先でテザリングしていたのを忘れて、ひたすら天井のアクセスポイントより全然近い、PCの隣で USB 充電中のスマートフォンとひたすら通信してたなんて話もよくあります、ってか私もよくやっちゃいます。

まぁ、昔、聞いたまじめな話。無線対応のプリンタが流行った頃、コンフィデンシャルな会議用ドキュメントをバキバキと印刷していたら、あれ、おかしい。ジャムったか、トナー切れか。とおもってトラブルを調べていたら、見知らぬカイシャから「おタクのカイシャのロゴが入った印刷物がゴッチョリ大量に出てきてウチのプリンタトナー使い切ったんだけど何とかしろ」とクレームが来たという。どうやら距離は結構そこそこに離れているんだが印刷した本人の席と問題のカイシャとの間にはガラス窓以外に遮蔽物がなく、「極秘文書」をジャンジャン他社に送り付けたらしい。総務が赤っ恥かいて謝罪にいったらしいけど、その後、その会社では無線の使用は厳禁になったとかならなかったとか。

ウソかホントか知らんけど似たトラブルはよく聞きます。「だからオフィスでは無線は使うなぁ、スイッチ切れぇ!」とお灸をすえてやりましたが.....

これから無料 Wifi スポットが増えるとそんなトラブルも良く出るんだろうなぁ。

有線が使えるなら、厚みやディスプレーのサイズにはこだわりません。まぁ肩が凝るほどの重量級ノートは遠慮しますが、かつては毎日、大型ノート2台持ちもしたくらいですからモニタサイズと重量はあまり気にしない。できれば電源は二個持ち、一個は固定使用、予備は持ち歩き用。AC電源アダプタとかディスプレーでも壊れりゃ、ただのウエイトトレーニングの用途にしかならないのがノートPCです。

確かにスマートフォンや、容量の少ない記憶装置は、クラウド主体のビジネスモバイルとしては充分かも知れません。が、この使い方はあくまでも、あくまでもシャドウIT。IT部門の管理から外れた利用方法になるため、余分な機密データの持ち出しや、大量かつ巨大データの加工、生産には向いていません。例え、リアルタイムに常時接続したい、というニーズはタブレットやスマートフォンではお分かりの通り少ないンです。だからこれらのデバイスでは無線でも充分。しかしプロの生産活動にはやはり有線接続のPCは必要なのです。

また、多くのフリーランスやITメディア編集部のITライターさんが書くインプレッション記事は、新品状態の細かなスペックだとか、自宅兼オフィスの深夜の丑三つ時、静的環境で数台のPCやタブレットを使ってみての夏休みの感想文なのです。彼らフリーランスのITライターは数百台のPCが存在し、巨大な画像ファイルや図面を使う、不動産業や金融業の資産調査に使うデジタルカメラのデータ、建設現場などの航空写真、書籍を作るための大量の図形や文書、巨大なビデオデータなど共有データを必要とする、現場の激務の中で仕事をするプロフェッショナルに必要なファイルサーバーなどの存在を気にする事はありません。

せいぜい「オフィス兼自宅」のNASと一対一で転送してスペックを記事にするだけです。そもそも 802.11ac ったって、チャネルあたり 443Mbps しか出ないのです。4チャンネル束ねて 1.6Gbps とかド派手にパッケージにコンジキでド派手に書かれているけど、普通は端末側は対1チャネルしかないのですね。無線だと、普通カタログスペックの3割しか出ないというし、輻輳したり、「1チャネルを皆ンなで共有」なんて事すると、ひと昔の3G回線並みのが普通になります。まぁ YouTube で「昨日の大相撲のこの一番」を見るのには困りませんがね。5分の動画ストリーミングでも、5分間ゆっくり転送しても困りません
a0056607_07341480.jpg
早朝6時、たったあ2Gでえ9分とかありえない。
他はブチブチ切れるな。こりゃ朝飯の時間だ。

a0056607_07345371.jpg
802.11n 54Mbs でこれだ。 32Mbitps = 8bit(1Bit) * 4MByte/S うーむ納得できる数字だ
条件いい時間帯なんだけどね。


a0056607_07450859.jpg
無線じゃやっておれんぞ。
RJ-45のモジュラが壊れているのでUSB 2.0 アダプタ経由でやってみる。
それでも帯域はフルに使っている。そこそこだ。


そもそも端末側が 2.4Ghz 帯の 802.11n しか対応していなければ、まぁ「つながった!良かったね」そんな程度です。

ITメディアが提供する記事は鵜呑みにすべきではない、これが現場が必要とするプロのエンドユーザ環境なのです。

実際のエンドユーザさんは私たちの様なITバカではありません。業務の「その道に関してはプロ」なのです。ヘビーユーザーなんですね。60分の映像データでも10秒で共有ストレージにアップロードしなければならない。400枚の高解像度のカメラの映像から使える画像をピックアップする。そんなプロのオフィスユースには、とてもじゃありませんが、無線はお勧めできない。みんな昼飯食いに行くしかない。

これもまた聞きなのですが、生産現場の ITエンジニアに、せいぜいオフィスとブラウザ程度しか使えないペラペラのノートPC配ってドメインのポリシーでロックダウンかけたという事でエラそーに言っていた営業出身の某経営者がいました。これでどーやって Linux のサポートするのよ、って渡された本人怒っていましたけどね。これなら紙とエンピツの方がよっぽどましだぞって。

環境は統一したいけど、現場にいかに適合した環境もまた検討できるかが勝負なのです。




無線LAN トラブル 有線接続 インターネット 接続できる LANに接続できない 


[PR]
by islandcenter | 2017-07-22 12:58 | プライベートクラウド | Trackback | Comments(0)

すっかり落ち着いてしまったようですが、世間が wannacry ランサムウェアで大騒ぎしていた頃、気になる記事を Gigazine に見つけました。

Gigazine

Windows XPでランサムウェア「WannaCry」の被害が少なかった一因は「ブルースクリーン・オブ・デス」

"WannaCryは「MS17-010」で報告されている、Microsoft Windows SMB サーバーというWindowsのファイル共有システムの脆弱性を利用して広がりましたが"

Gigazine のこの記事によると、 wannacry については Windows XP に感染する前にブルースクリーンになり拡散に失敗するケースが多く、 Windows10 では比較的被害が少ないし、Windows8x 系はそもそもサンプルが少ないので、実際に感染したコンピューターは Windows7 の SMB なんだろうなぁ、という事がぼんやりと気になっていました。

そこで SMB のバージョンについて調べてみました。まぁまぁ良く整理されている記事がこちら。

第7回 ファイル共有プロトコルSMBの概要

そこで wannacry に関する情報を探ると出てくる出てくる。Windows サーバーから、おなじみの samba も影響があるのですね。


- 一番初めに試した対策 -

ほとんどどこでも言及している「SMB 1.0/CIFS のファイル共有のサポート」 デフォルト・イネーブルを削除してみました。

ランサムウェア WannaCrypt 攻撃に関するお客様ガイダンス

「コントロールパネル」>「プログラムと機能」> 「Windows の機能の有効化または無効化」から "SMB 1.0/CIFS ファイル共有のサポート"のチェックを外します。後は「再起動しろ」と言ってくるので、再起動します。すごく再起動に時間がかかります。

a0056607_17592725.jpg
再起動すると見事に samba サーバーが「ネットワーク」から消えました。\\IP\Share_name でアクセスもできません。

全滅

です。

という事でこいつ(SMB1.0/CIFS .....)は元にもどす事になりました。つまりはこれも拡散を防ぐための一時的な対策に過ぎません。

- samba サーバー側で対応してみる -

==========
Workaround
==========

Add the parameter:

nt pipe support = no

to the [global] section of your smb.conf and restart smbd. This
prevents clients from accessing any named pipe endpoints. Note this
can disable some expected functionality for Windows clients.

という事だそうです。

smb.conf — Samba の設定ファイル
によると

nt pipe support (G)

この真偽値パラメーターにより、 smbd(8) が Windows NT のクライアントに対して、 Windows NT の SMB 固有の IPC$ パイプへの接続を許可するかどうかが制御される。 これは開発者のデバッグオプションであり、意識する必要はない。

既定値: nt pipe support = yes


意識する必要はないとはありますので、とりあえず 手元の SUSE Linux SLES11 で設定してみます。

yast(or yast2) > Network Service > Samba の Identity タブ Advanced Setting からこの Expert Global Settings を書き換えます。

a0056607_18000345.jpg

Add ボタンで "nt pipe support" にチェック(デフォルト)が入っているので、このチェックを外すと smb.conf が書き換えられます。この状態で yast でOKすると samba が再起動します。

a0056607_18003739.jpg

ところが

a0056607_18010151.jpg

見事にアクセスが拒否られます。また Windows7 とサンドボックスの Windows XP も見事アクセスが拒否されました。
つまり

nt pipe support = no

パラメータはあくまでも一時的なものであり、根本解決には至りません。

という事で SUSE から出ているパッチを探してみました。これの様です。

- SUSE のパッチ -

CVE-2017-7494

結構メンド臭そう。やっぱり公式リポジトリからセキュリティ系のアップデートを全部パッチするのが正解の様です。

怖いのは、Linux のディストリビューション各社はパッチをだしているのですが、よく国道沿いのディスカウントショップで「家族計画用品」の隣で売られているご家庭製品専門のメーカーで出しているような、「なんちゃって我が家のNAS」みたいなものがパッチを出していなかったり、当てるのも面倒だったり、そもそも wannacry に対策しているかどうかもわからないところですね。


ということで

第一段階

SMB1.1/CIFS の利用をやめて Samba や NAS の使用を停止して、エンドユーザに総スカンを食らう
その間にパッチを全部確認する。

第二段階

手に入る限りの Windows パッチ、Samba パッチを当てまくり、リブートしまくり、ついでにあちこちでトラブルが出て、みんなに総スカンを食らう。

第三段階

PCを「安全性が高い」とマイクロソフトが豪語する Windows10 と Windows 2016 Server にリプレースして、SMB3.11 にアップデートして samba も 4.x にアップデートして SMB3.x のみサポートして、動かないアプリケーション続出しまくり、繋がらない古いPCユーザから総スカンを食らい、金をかけた効果はあったのかと経営者に詰問されて、辞表を書く。

というのが対策の手順となりそうです。




- Keyword-

wannacry, 対策, Windows10, Windows7, samba, SMB, CIFS, Linux, 脆弱性



[PR]
by islandcenter | 2017-07-10 18:08 | プライベートクラウド | Trackback | Comments(0)

従来とは違い、使えないとばかり思っていた


Windows10 の Guest ユーザを作る、いやビルトインアカウントを有効にする方法です。こういう大嘘記事を書いて、ずーっと気が付かなかった私もそろそろもうダメポと思ってしまいます....

- Windows7 の場合 -

コントロールパネルのユーザとグループから Guest アカウントを ON にすると、パスワードなしの Guest アカウントが有効になります。が....

a0056607_15450426.jpg
がしかし、Windows10 にはそんなユーザはいません。

a0056607_15454112.jpg

要するに、なるべく Microsoft 様としては、なるべく「ウチのアカウント作ってね、ンでもって使い物になるものほとんどないけどストアアプリたくさん買ってチョ!」という訳です。

- そこで Windows10 の Guest アカウントを作ってみる -

試しに無理して "Guest" アカウントを「作成」して「次へ」を押すと「別なユーザ名にしろ」と怒られました。つまりどこかにいるわけですね。

a0056607_15460767.jpg
という事で 「タマ」とか「ポチ」とか「赤の他人」とかのアカウントを作るわけですが、しっかり、ビルトインアカウントで Guest って存在するわけです。

- Guest ユーザを有効にする -

「たんぼタン(田)」の右クリックから「コンピュータの管理」を選んで「ローカルユーザーとグループ」「ユーザ」を選ぶと

a0056607_15464522.jpg
「こんなところに隠れていたのか」という所に、冷蔵庫の裏側の標準装備の×キブリみたいにビルトインアカウント Guest 様がひっそりと隠れていらっしゃいました。「アカウントを無効にする」のチェックを外すと Guest 様が飛び出てきます。

a0056607_15470908.jpg
まるで、×キジェットでワラワラ出てきた、「×キブリ」のように這い出てきましたね。

- ついでに Administrator を有効化してみる -

a0056607_15473484.jpg
ちゃんといるじゃないか .....
a0056607_15475214.jpg
ということで Guest も Administrator も Windows10 ではちゃんと存在するわけですね。


- Keyword -

Windows10, パスワードなし, Guest ユーザ、 ADMINISTRATOR ビルトインアカウント、 有効化




[PR]
by islandcenter | 2017-07-09 15:52 | Windows | Trackback | Comments(0)