お客さんのトコロで、フリーアクセスのオフィスに移転するという話と、併せて社員にノート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)

- 目的 -

全社、あるいは多くの部署で読み書き可能だったファイルサーバーのフォルダのアクセス権を特定の部署、あるいはグループに特定できるように変更したい。

- OES Linux での操作 -

次の OES ファイルサーバーのフォルダ VOL:test には O=ACE(組織全部)と Yoiko.Uses.Osaka.Ace(グループ)に権限が与えられています。

既に O=ACE に [ RWCEFM ] の権限が与えられているため、全社 O=ACE がこのファイルサーバーのフォルダを読み書きできる状態です。グループオブジェクト Yoiko.Osaka.Ace にもトラスティが与えられていますが、この権限はこの場合は余分です。
a0056607_11070253.jpg
したがって、OES ファイルサーバーの VOL:test には グループに関係なくすべてのユーザに権限が与えられています。

これを Users.Tokyo.ACE の OU にのみ解放したい場合 ....

いったんすべてのファイルサーバーの権限を削除して、
a0056607_11072836.jpg

特定の部門、グループにだけ権限を与えます。ここでは Users.Tokyo.Ace に権限が与えられ、Osaka.Ace には与えられていません。全社からではなく、一部の部署がファイルサーバーの特定のフォルダにアクセスできるようになります。

a0056607_11075388.jpg
これで Osaka.ACE のユーザには権限が与えられなくなります。

※ただし、ログインスクリプトで map f:=VOL: などの記述があると、全くボリュームに権限がないと、マップエラーになります。本来であれば、権限がない時点で map のスクリプトを削除するのがベストですが、何か理由があって、ログインスクリプトに手を加えたくない場合は、dummy ファイルを置いて、[ F ] 権だけを与えたファイルを作っておくと良いでしょう。

試しに VOL:dummy.txt のユーザに [ F ] 権のみ与えてみると、東京では見えるフォルダは見えませんし、F権のみなのでフォルダを見ることはできても中身を確認することができません。

a0056607_11081955.jpg
Windows のファイル共有と違って、OES のファイルサーバーのアクセス権(トラスティ)の割り当ては、一か所変えるだけで、メタファイルを一か所変えるだけなので、一瞬で終わります。フォルダの中にどれほどサブフォルダやファイルがあっても、ディレクトリとファイル全体の権限をスキャンして変更しませんので、ファイルサーバーの負荷はほとんど0%です。Windows ファイルサーバーでは数分から数時間かかり、ほとんどその間は、ファイルサーバが利用できない激重状態になります。

次のデモビデオでは、数万ファイルの大量のデータのアクセス権を変える操作を Novell OESでは一瞬、 Windows ファイルサーバーでは30分以上かかり、その間、ほとんどサーバーが使えなくなっている様子を比較したビデオクリップです。

Novell versus Microsoft: Granting Access Rights



また、権限のない不可視のフォルダ共有はエクスプローラにも表示されないため、共有サーバー上に数百、数千の読み書き不可の共有ディレクトリがあっても、ファイルサーバーが返すディレクトリ情報のポケットは「権限のある」ディレクトリだけなので、ネットワークの負荷が少なく高速に表示されます。



- keyword -

ファイルサーバー アクセス権限 変更 共有フォルダを見せない フォルダのアクセス権限を変える 遅い 重い ファイルサーバーの負荷100%

[PR]
# by islandcenter | 2017-07-19 11:23 | OES Linux | Trackback | Comments(0)

Zabbix 3.2 のアプライアンス版が出ていましたので、SUSE バカに陥らないためにも、ubuntu と格闘してみました。というか、2.2 のアプライアンスが壊れてしまったので(あぁーバックアップ取ってないし .... )

zabbix 2.x の導入はこんな感じでした。
SUSE Studio から Zabbix 管理ツールの導入

※ ソフトウェアアプライアンス版は、評価目的のチューニングですが、中小規模の数台のサーバーやルータ、スイッチなどのトラフィック管理など数十台のデバイス管理には、そこそこ使えます。より深く学び、システム管理が複雑で規模や問題が大きくなれば、それなりに Zabbux L.L.C の有償サポートを受けたパッケージの導入とトレーニングを受けてください。私としては、デバイスの異常なトラフィック増大を時系列で見えればよい程度なので、導入の敷居が低いzabbix のソフトウェアアプライアンス版は初めての方にはお勧めです。なお、 3.2 は LTS 版ではないのでそのつもりでトレーニングだと覚悟してください。

- ハイパーバイザーへの実装 -

Zabbix のダウンロードページから、 "KVM, Parallels, QEMU, USB stick, VirtualBox, Xen" 用イメージ (.raw1.6Gb) をダウンロードします。

Download

Zabbix appliance Documets

*****.tar.gz を解凍すると 10Gb の仮想アプライアンスイメージが出来上がります。ubuntu のバージョンは /etc/os-release によると 14.04 でした。

これを virt-manager から Create Virtual Machine で実装します。機材の都合で XEN4.4 on SUSE SLES11sp4 です。
a0056607_14293162.jpg

このバージョンは、 Ubuntu 14 は対応していないようですが、 Ubuntu(Other) で実装できました。
- Virtual : Full Virtual
- Name of VM :
- Hardware : 512Mb, 1Vcpu
- MAC : XEN source のヘッダに任意の3桁


a0056607_14300292.jpg

これで OK を押すと、Zabbix 3.2 アプライアンスが起動できました。

Ubuntu のいやらしいroot でログインできないログインプロンプトです。

a0056607_14303447.jpg

ダウンロードページにあるパスワードでログインします。

login : appliance
Password : zabbix

a0056607_14310483.jpg

DHCPで IP をもらうので一応 ifconfig で IP を確認します。

a0056607_14312728.jpg
これで SSH テキスト端末からログインできます。

ssh xx.xx.xx.xx -l appliance

sles11:/var/lib/xen/images/zabbix32 # ssh 192.168.1.xx -l appliance
Zabbix server Appliance (mysql)
appliance@192.168.1.55's password: **********
Last login: Fri Jul 14 10:30:35 2017
######## ### ######## ######## #### ## ##
## ## ## ## ## ## ## ## ## ##
## ## ## ## ## ## ## ## ## ##
## ## ## ######## ######## ## ###
## ######### ## ## ## ## ## ## ##
## ## ## ## ## ## ## ## ## ##
######## ## ## ######## ######## #### ## ##
appliance@zabbix:~$

IPを固定します。 /etc/network/interface を sudo vi で DHCPから Static に編集します。(メンド臭い)
IP を指定して DNS, Default Gateway の設定をします。

appliance@zabbix:/etc$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
#iface eth0 inet dhcp <--- コメントアウト
iface eth0 inet static <--- 追加

address 192.168.1.220 <--- 追加
netmask 255.255.255.0 <--- 追加
gateway 192.168.1.1 <--- 追加
dns-nameservers 192.168.1.2 <--- 追加

/etc/resolv.conf を書き換えます。(メンド臭い)

appliance@zabbix:/etc$ cat resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.1.2 <--- 追加
nameserver 192.168.1.3 <--- 追加
search intra <--- 追加

でネットワークの再起動(メンド臭いしミスタイプしやすい)

appliance@zabbix:/etc$ sudo ifdown eth0 && sudo ifup eth0
[sudo] password for appliance: *********
appliance@zabbix:/etc$ ping www.yahoo.co.jp
PING edge.g.yimg.jp (183.79.248.252) 56(84) bytes of data.
64 bytes from 183.79.248.252: icmp_seq=1 ttl=52 time=90.6 ms
64 bytes from 183.79.248.252: icmp_seq=2 ttl=52 time=97.3 ms

--- edge.g.yimg.jp ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 90.698/94.024/97.350/3.326 ms
appliance@zabbix:/etc$


a0056607_14320955.jpg


という事でブラウザから http://ip_or_DNS_address/zabbix へ Admin/zabbix のデフォルトでログインします。

a0056607_14420950.jpg

で、色々弄って、date すると UTC 表示でした...... ubuntu の場合、謎のオマジナイがあるのでシステム時刻を JSTに変更します。

appliance@zabbix:/etc$ sudo dpkg-reconfigure tzdata
[sudo] password for appliance: *********

こんな UI が出てくるので Asia > Tokyo を選び OK します。

a0056607_14323301.jpg


appliance@zabbix:~$ date
Sat Jul 15 00:29:36 JST 2017
appliance@zabbix:~$

無事、システムの時刻表示は UTC から JST になりました。しかし、Zabbix の UI で表示される、グラフやイベントは UTC のままです。一体どこで変えるんでしょうね。

/etc/php5/apache/php.ini を sudo vi で変更しました。

appliance@zabbix:/etc/php5/apache2$ sudo vi php.ini
appliance@zabbix:/etc/php5/apache2$ ....: 編集中 .....
appliance@zabbix:/etc/php5/apache2$ cat php.ini | grep timezone
; Defines the default timezone used by the date functions
; http://php.net/date.timezone
;date.timezone =
date.timezone = Asia/Tokyo
appliance@zabbix:/etc/php5/apache2$

zabbix-server と apache2 をリスタートさせましたが
何故か6時間、表示が遅れています(謎)

※謎解決 タイムゾーンを JST に

/etc/apache2/conf-available/zabbix.conf に Timezone の設定があるのでこれを突いたら治りました。

appliance@zabbix:/etc/apache2/conf-available$ ls -al
total 36
drwxr-xr-x 2 root root 4096 Aug 7 17:53 .
drwxr-xr-x 8 root root 4096 Jul 28 06:43 ..
-rw-r--r-- 1 root root 315 Jan 3 2014 charset.conf
-rw-r--r-- 1 root root 3224 Jan 3 2014 localized-error-pages.conf
-rw-r--r-- 1 root root 189 Jan 3 2014 other-vhosts-access-log.conf
-rw-r--r-- 1 root root 2190 Jan 3 2014 security.conf
-rw-r--r-- 1 root root 455 Jan 7 2014 serve-cgi-bin.conf
-rw-r--r-- 1 root root 1582 Aug 7 17:53 zabbix.conf
-rw-r--r-- 1 root root 1583 Aug 7 17:52 zabbix.conf.org
appliance@zabbix:/etc/apache2/conf-available$ cat zabbix.conf | grep timezone
php_value date.timezone Asia/Tokyo
php_value date.timezone Asia/Tokyo
appliance@zabbix:/etc/apache2/conf-available$

マニュアルはちゃんと読めよという事ですね。

- NTP をインストールして設定 -

NTP が入っていないので、インストールします。ハードウェアクロックは仮想環境では時刻狂いを起こします。

sudo apt-get で ntp を Install します。

appliance@zabbix:/etc$ sudo apt-get install ntp
[sudo] password for appliance:
Sorry, try again. あちゃーメンドクサイ
[sudo] password for appliance:
Reading package lists... Done
Building dependency tree
Reading state information... Done

 : 中略して誤魔かしの美....

appliance@zabbix:/etc$


/etc/ntp.conf を外部ソースから、LAN内の NTP ソースに変更します。

# Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
# on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for
# more information.
#server 0.ubuntu.pool.ntp.org <--- コメントアウト
#server 1.ubuntu.pool.ntp.org <--- コメントアウト
#server 2.ubuntu.pool.ntp.org <--- コメントアウト
#server 3.ubuntu.pool.ntp.org <--- コメントアウト
server ntp1.intra <--- 追加
server ntp2.intra <--- 追加

とここまで3時間の作業でした。SUSE なら、yast 一発で20分で終わるんだけどなぁ。

Install on openSUSE / SLES

あとは Configuration > Hosts から、smnp エージェントを実装したデバイスを登録して行くだけです。

- 対象ホストが snmp を返すか調べる snmpwalk -

監視対象ホストが SNMP に反応するかどうかは snmpwalk を使いますが、このアプライアンスにはデフォルトでは入っていないので、SUSE なら YaST で一発の所、Ubuntu 版では、テキストコンソールからキーボードと闘いオマジナイを唱える必要があります。くれぐれも綴りを間違えないように..... アチャーなトラップが待っています。

appliance@zabbix:~$ sudo apt-get install snmpd
Reading package lists... Done
Building dependency tree
Reading state information... Done
snmpd is already the newest version.
snmpd set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 19 not upgraded.
appliance@zabbix:~$ snmpwalk <---- snmpd だけじゃダメポ.......
-bash: snmpwalk: command not found
appliance@zabbix:~$ sudo apt-get install snmp <--- このパッケージが必要なようです。
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
snmp
0 upgraded, 1 newly installed, 0 to remove and 19 not upgraded.
Need to get 146 kB of archives.
After this operation, 554 kB of additional disk space will be used.
Get:1 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/main snmp amd64 5.7.2~dfsg-8.1ubuntu3.2 [146 kB]
Fetched 146 kB in 3s (41.1 kB/s)
Selecting previously unselected package snmp.
(Reading database ... 52441 files and directories currently installed.)
Preparing to unpack .../snmp_5.7.2~dfsg-8.1ubuntu3.2_amd64.deb ...
Unpacking snmp (5.7.2~dfsg-8.1ubuntu3.2) ...
Setting up snmp (5.7.2~dfsg-8.1ubuntu3.2) ...
appliance@zabbix:~$
appliance@zabbix:~$
appliance@zabbix:~$ snmpwalk -v2c -c public 192.168.1.239 .1.3.6.1.2.1.1
iso.3.6.1.2.1.1.1.0 = STRING: "Linux abianca 3.0.101-63-xen #1 SMP Tue Jun 23 16:02:31 UTC 2015 (4b89d0c) x86_64"
iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.8072.3.2.10
iso.3.6.1.2.1.1.3.0 = Timeticks: (44081742) 5 days, 2:26:57.42
iso.3.6.1.2.1.1.4.0 = STRING: "Administrator <postmaster@example.com>"
iso.3.6.1.2.1.1.5.0 = STRING: "abianca"
iso.3.6.1.2.1.1.6.0 = STRING: "Right here, right now."
iso.3.6.1.2.1.1.7.0 = INTEGER: 76
iso.3.6.1.2.1.1.8.0 = Timeticks: (47) 0:00:00.47
iso.3.6.1.2.1.1.9.1.2.1 = OID: iso.3.6.1.6.3.10.3.1.1
iso.3.6.1.2.1.1.9.1.2.2 = OID: iso.3.6.1.6.3.11.3.1.1
iso.3.6.1.2.1.1.9.1.2.3 = OID: iso.3.6.1.6.3.15.2.1.1
iso.3.6.1.2.1.1.9.1.2.4 = OID: iso.3.6.1.6.3.1
iso.3.6.1.2.1.1.9.1.2.5 = OID: iso.3.6.1.2.1.49
iso.3.6.1.2.1.1.9.1.2.6 = OID: iso.3.6.1.2.1.4
iso.3.6.1.2.1.1.9.1.2.7 = OID: iso.3.6.1.2.1.50
iso.3.6.1.2.1.1.9.1.2.8 = OID: iso.3.6.1.6.3.16.2.2.1
iso.3.6.1.2.1.1.9.1.3.1 = STRING: "The SNMP Management Architecture MIB."

 : 中略

iso.3.6.1.2.1.1.9.1.4.8 = Timeticks: (47) 0:00:00.47
appliance@zabbix:~$ <----- うまく帰ってきたようです。

こんなに使いづらい Ubuntu 大好きって人はよっぽどマゾなんだろうなぁ。





-Key Word-

Zabbbix 3.2 仮想アプライアンス XEN KVM 評価 導入 練習台 無償で始めるネットワーク管理


[PR]
# by islandcenter | 2017-07-15 14:45 | プライベートクラウド | 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)

このブログで「如何にして Linux は SUSE Linux の事しか書かないのか」という疑問を読者の方がお持ちだと思います。私は、「他人と違う事をやらねばITエンジニアとして生きていけない」というのが、ほとんど人生のコンセプトみたいなものでして、流石に Novell の Uniux Ware には手が出なかったけれど(後にひと悶着した SCO UNIXですね)、やっぱり若いころ使った UNIX 系 OS をやりたかったし、PC用に(当時は高価だった)C言語コンパイラもついてくるという、入門用の Linux ディストリビューションを探していました。 Live Door が販売した Lindows(後のLinspire) を使ってみてなんじゃこれと挫折し、Cardela Open Linux を突っ込んでGUI見て「だからこれは何じゃ?」と3日で諦めた、90年代後半。そして2000年以降、いよいよ Linux がどこでも使えるようになった頃、 RedHat に苦しみました。


一応ベテランとなっていた当時、ヒマそうにしていると、後輩から「そんなにヒマならRedHat をインストールを手伝って欲しい、ベテランで高い給料もらってるんだから働け」と言われ、ま、いい暇つぶし、と思って入れてみたけれど、もう大変。SCSI のディスクドライバが認識できない。おまけにインストーラはテキストだし、途中でハングアップしたりするしで、どうもハードベンダーではテスト済のモデルなですが、ドライバーは別に入れなければならないわけです。正直、昔の Lindows より面倒くさい。しかも配布されているのはフロッピーのイメージのみ。「ヲイ、このモデルどう見てもFDD付いてないンだけどなァ」「いやぁ RedHat ならよくあることですよ」と若者に馬鹿にされたのは言うまでもありません。

納品までヒマがかなりあったので、試しに 評価用の SLES9 を入れてみると、ドンピシャで、何のトラブルもなくYaST の GUI インストーラが立ち上がり、インストールが出来ました。それ以来、 Linux と言えば SUSE Linux なんですね。RedHat と SUSE を比較すると、圧倒的にトラブルの少ない SUSE の方が入門するには敷居が低い。

ところで 「SUSEは日本語のドキュメントが少ない」とか「ドマイナーな Linux 」という印象がありますが、もともとが企業向けのミッションクリティカルなサーバーOSとして人気があるので、比較すると RedHat のように「誰でもお気軽」に情報を出せないところがデメリットなのかも知れません。

= Google Trend による認知度傾向 = 

Google Trends によると、過去、近年の日本での検索ワードのレート 6:45 なので、SUSE Linux は RedHat の 1/7 以下の認知度、という感じでしょうか。

過去1年の日本でのトレンド
a0056607_00412819.jpg

ところが、海外も含むトレンドを見ると RedHat が 100弱に対して SUSE は 50 弱のレートですから、「商用 Linux では第二の人気のディストリビューション」と言っても、まず誤解ではなさそうです。1:2 程度の認知度であるわけですね。

ワールドワイドの過去1年のトレンド
a0056607_00425212.jpg
※もっともこれは「商用 Linux」としての認知度で、これに CentOS とか Ubuntu なんかの無償ディストリビューションを加えると全然違う数字になります。ってか、(Ubuntu って商用なの?)


ちなみに、RedHat の過去5年の都市別人気度を見ると、一位は「千代田区」です。3位に中央区が入っています。他にも、渋谷区、新宿区、東京じゃないけど横浜市などがベスト20位以内に入って行って、「首都圏」というざっくばらんな地域でみると、「RedHat というアメリカ製品だけが大好きな異常な東京人」という構図が見えてきます。何故か日の丸ディストリビューションはほとんど人気がありません。他には、シンガポールやインドの各都市、ソウル、香港などがランク入りしています。「東アジアで大人気の RedHat」なのですね。


過去5年の都市別のトレンド
a0056607_00434014.jpg
もっとも、逆に Google Trend では、SUSE の人気都市の上位はズラリと「ドイツの都市」が並ぶのも、まぁ当たり前なんですけどね。

国別でみると、ドイツはもちろんですが、チェコ、ロシア、ポーランドなどの東欧諸国、何故かブラジルなどのポルトガル語圏など、非・米英語圏での認知度が高いようです。私のサイトを訪れる海外言語は、英語がもちろんですが、en_gb やチェコ、ポルトガル語(ブラジル)などのアクセスがたまにあります。たまに Google Trends を見てみると、Novell 傘下になって以降、年を追うごとに en_us での認知度は上がり続けており、米国からオフショアで仕事をするインドなどでの認知度も年々上がってきているような気がします。

= SUSE Linux のメリット =

本題に入る前にずいぶん寄り道しました。SUSE のここが嫌いという前にどこにメリットがあるのかまずは並べてみます。

- 圧倒的に使い易い YaST

SUSEは YaST に始まり、YaST に終わる、というくらい、Linux の管理者にとっては萬金丹のような万能ツールです。これがある意味では最悪のデメリットになります。

- 比較的新しいハードウェアでもまず動く

一度だけ、10Gb NIC にはまったことがありましたが、他のサーバーに合わせて古いバージョンの SLES を入れたので、コンパイルする必要がありました。
それ以外、まずドライバ問題でインストールで戸惑うことはほとんどありません。新しい機種の場合は、できるだけ新しい SLES のバージョンを入れた方が無難ですね。
これもある意味 SUSE のデメリットになります。

- 落ちたことがない

もう10年以上 SLES を扱ってきて、まず、本番環境で「落ちた」「再起動できない」という経験に当たった事がありません。もっともテスト環境だと、古いハードディスクが御昇天して起動できなくなったという経験はよくあるのですが、まずハードウェアのトラブルがなければ、運用中のトラブルはまず皆無でした。あくまでも自分の経験ですが、システムがトラブると、エンジニアとしては必死に原因探しをするので、スキルも上がります。本番環境で滅多にトラブルが出ない、 SLES の安定感は、安心感は絶大なのですが、逆にこれもエンジニアのスキルとしてはデメリットになります。

= SUSE Linux のデメリット =

- 何でもYaST 頼りになる

SLES,SLED, openSUSE いずれも YaST があれば、ほとんどの管理作業は自動化されるので、Linux の基本的な設定を行うコマンドをほとんど覚えません。LPICなどの公認資格を取ろうにも、YaST で何でもできてしまう SUSE のエンジニアは不利ですね。逆にCLP (Certified Linux Professional)というマイナーでSUSE ローカルな資格制度があります。残念ですが、現在日本では行われていないようです。所詮ノベルさんの製品資格ですからね。

コマンドラインで yum や apt-get に相当する zypper というパッケージ管理ツールもありますが、まず、zypper は使いません。綴り間違えると面倒だし。

初心者にもお勧めな SUSE Linux ですが、レベルを上げるためには、やっぱり vi の基本操作ができるとか、サービスのリスタートができるとか grep でログの見方を知っているとか、簡単なシェルスクリプトが書けるとか、その手の技術に達するにはやっぱり Linux の知識は必要なんです。でもYaST にもログビューワなんかが付いていると、ついつい YaST 頼りになってしまいます。このテの操作は、Debian 系を除く他のディストリビューションとほとんど同じなので、基本的なアンチョコ本を持っている必要はあります。正直に白状すると私は YaST なしでは Static IP の変更ですら方法を知りません。一応できるようですが、マニュアルを見て5秒で諦めてしまいました。

~.conf なんてどこにあるのか知らないし、ついつい「httpd.conf ってどこにあるんだっけ?」と find を使ってしまいます。YaST で細かいチューニングはほぼできます。この程度の知識は欲しいのに、その知識自体が身につかないことが多いです。サービス関連はもっぱらアンチョコ本が頼りであることには変わりありません。もっともディストリビューションが違ったり、ソースからインストールする場合は探すことになるんですね。それは何を選んでも同じです。

逆に SUSE から他のディストリビューションに乗り換えた方は、よく海外のフォーラムなんかに「Ubuntu 版の YaST に相当するツールはないのか」という投稿が見当たります。一応 YaST も OSS なので、ディストリビューターが実装する事はできるのですが、非公式にサポートしているのは Oracle くらいの様です。CentOS に Oracle 版の YaST を入れた猛者がいらっしゃるようですが、慣れって怖いものです。

テキスト端末でも簡単なUIで管理作業ができる YaST の恐ろしさは、ベテラン Linux の管理者にとっては仕事を奪うほどのキラーツールです。

- インストールの敷居が低すぎる

これもエンジニアとしてのスキル向上の問題になります。何しろほとんど SUSE Linux ではシステムやパッケージのインストールでは躓かないので、「あの手この手」を使わなければならないシーンに滅多にお目にかからないのはいいことなのですが、いざ「あの手この手」をつかわなければならない時の、「技術の陳列棚」が身に付きません。だから「SUSE で困っています」という Yahoo 知恵袋の質問なんか探しても、情報が少ないのです。Apache を入れようとして「# yum install httpd とやったら拒否られた」」とかそんなレベルなのです。

- 日本語の情報の少なさ

これは、日本総販売元のノベル株式会社のリソースの問題もありますが、日本での利用者が少ないため、日本語情報が少なすぎる、とよく言われます。もっとも英語で検索すると、ゴロゴロ出てくるのですが、英語アレルギーなニッポン・ガラパゴスなエンジニアにとってはつらい事かも知れません。これは、 SUSE Linux を利用している顧客の多くがベンダーのサポートを適切に受けたヒミツのハイエンドプロジェクトのシステムなどが多く、最新の SLES12 では Live Patch などと言う怖い機能がサポートされるなど、話題にもならないけれど、深刻な問題が表面に出てこない事も考えられます。

幸いな事に openSUSE を含めマニュアルは、そこそことニホンゴでも充実しています。また、openSUSE と SLES, SLED は共通点が多く、openSUSE である程度トレーニングしておけば、まず SLES, SLED の商用版でも応用が利きます。openSUSE のサイトには、SUSE Enterprise の公式リポジトリにない、SUSE 非公認の OSSパッケージも見つかるので、ブラウザから自己責任で1クリックでインストールできます。まず、はじめてトライする Linux の無償ディストリビューションとしては openSUSE は良い一つの選択肢です。

よほどマイナーなパッケージでなければ、まず openSUSE ≒ SLES/SLED というケースが多いでしょう。RedHat における Fedora との違いほどの差はありませんし、openSUSE は GUI や最新のハードウェアにトライが多く新鮮さを感じても、サーバーとして割り切った場合でも、そこそこ安定して利用できます。それほどクリティカルな目的でなければ、openSUSE でもいいやという場合もあります。ただしサポートがない、LTSが短いという点は心得ておくべきでしょう。ハードウェアのライフサイクルを考えると、企業ユーザさんには openSUSE はトレーニング目的以上にはお勧めしません。Fedora や Ubuntu ではないデスクトップ向けの Linux を、重要でもなく、低コストで古いPCに入れたいというのなら、お勧めできるディストリビューションの一つです。

また、手軽になった Windows10 の Hyper-V にも初めから対応しているので、Hyper-V 環境下で仮想ドライバは Microsoft 標準のドライバが自動認識されてインストールされます。

ただ openSUSE や SLED (SuSE Enterprise Desktop) をデスクトップとして利用する場合は、日本語を優先言語にしますが、私が SLES を使う場合は、優先言語を英語にして、まず使わない日本語は追加言語としています。メッセージが日本語だと、探しても全然ヒットしない。英語のマニュアルを見ながら操作する場合も、日本語では非常に面倒くさい事になります。

まぁ、英語に強くなりたいITエンジニアには、日本語情報が少ない事も英語のトレーニングにはメリットかもしれません。

- 国内サードパーティで未対応

これは、非常に困った問題で、これだけメジャーなディストリビューションでも、Linux ≒ RedHat と考えるガラパゴス・サードパーティ・ソフトウェアビジネスでは、まず 「SUSE Linux 何それ?」という困ったIT企業が非常に多い所が問題です。何しろ、少子化や先の経済発展が見込めない日本国内ビジネスだけでも当面は食っていけるので、コストを考えるとサポートどころかマニュアルさえ、英語化しないし、海外向けの会社案内のページさえ作らないのが普通ですから、Google Trends でも見たように、RedHat 大好きな、首都圏ビジネス主義、地方無視のニッポンのIT産業では、まぁ当然です。

だから、日本企業でも中規模企業が海外に進出する時は、現地担当者が当たり前のように、先進的で世界スタンダードな情報システムを使っているのに、日本では、海外グループ企業との情報化の一本化ができないのですね。こういうところから日本の斜陽化が始まっています。もっとも、これは顧客のシステムの首根っこを押さえている日本のSI屋ではパスポート持っているエンジニアやセールスマンがいないのか、顧客が海外進出しても「そっちは知らんぷり」なので止むを得ないのです。

そもそも、海外のIT業界では「日本市場参入の高い壁は世界の常識」という事で、東京をパスして、シンガポールやソウルに極東地区のビジネス展開した方が、成長性の高い中国ビジネスに参入しやすい。

まぁ SUSE と RedHat を比較してどっちがいいか、と思っている方、そうこのブログを読んでいる貴方です。グローバルで活躍できる人材になるか、それとも先が見えない、英語嫌いなガラパゴスエンジニア、ガラパゴス経営者で会社が潰れるまで働きたい、という方にはもうお分かりかも知れません。

どうせサードパアーティ製品なんて、ソフトウェアそのもののサポートをやればいいのであり、「インストールができるか否か」のチェックすら主だったディストリビューションで行わないので、まったく困ったものです。

- チューニングのスキがない

普通、デフォルト状態でインストールしてほとんど最高の性能がでるようで「それからチューニングするのが楽しみウッフン!」という方には物足りないのかも知れません。SAP なら SAP 用のパッケージにカーネルパラメータが用意されています。もしかしたらハイエンドのシステムではカーネルチューンしているのかも知れませんが、カーネルを直接つつく様な作業はほとんどやりません。

また SAP や Oracle と言った、ベンダーと、積極的に "Enterprise" な商売をやってきたせいか、オープンソースにコミットした「オープン性」の強い RedHat と違い、ダンマリと守秘性が高い「企業向けの SUSE Linux」というスタイルが企業には安心感を作っています。

- あまりに良すぎる安定性

まず、ハードウェアのトラブルでもなければ、リセットボタンに手を出す機会がないという、超安定性は、逆に言うとデメリットになります。まぁ、Windows なんか使っているとパッチを当てては毎月再起動、そのうちレスポンスも帰らず「またか...」という感じで、おまじないを唱えつつハードリセットをかけるMTBFの短さが当たり前なのですが、 SuSE Linux Enterprise の場合、まずハードリセットする機会がありません。もっともそんなことした後の fsck の怖さ(とにかく MTTR に時間がかかる)がありますから、やりません。というより「松竹梅」の「松竹」クラスの信頼性が高いハードウェアの運用環境ではやった経験がないのです。ラッキーな事に、お客様の責任感にも感謝しています。勿論、私のように「梅以下」の安物PCを酷使しているテスト環境では日常茶飯事ですが、これはそれなりに勉強になります。他のディストリビューションは知りませんが、ベンツでアウトバーンを安心して 250Km/h でかっ飛ばすような安定感は、V8 のコルベットでバンピーな Route 66 を 55Ml/h 出してパンクする怖さと違い、何とも言えません。

だから、事故った時が怖い。

これが SUSE Linux の怖さであり、デメリットなのです。

--
とまぁ、思いっきり悪口羅列したいと思って書き始めたのですが、結局は、SUSE Linux の安定感、管理の容易さという良い面が、デメリットとして相反するような書き方になってしまいました。



--
商用, Linux, SUSE, RedHat, 比較, メリット, デメリット




[PR]
# by islandcenter | 2017-07-03 00:54 | SUSE | Trackback | Comments(0)

またもや、Windows10 の「お節介な機能」に悩まされています。

-現象-

WIndows10 (1607) で、ディスクアクセスが100%になる。全く処理を受け付けなくなる。アプリケーションを全部強制終了させてもダメ。

1) どうもこの現象は、Windows Update をやった後に起こりやすい(やる前にも時々あるので、だからってわけでもないな)
2) FTP や Bit torrent で Linux のディストリビューションのような、数Gbのデータをダウンロードしている最中に発生しやすい(ような気がする)
特に FTP や Windows Store からダウンロードしながら、ヒマこいて YouTube なんか見ていると、あぼん。(痛いなぁ...やり直しか)
3) 大きなファイルを別なメディアにコピー、移動、削除などの処理をした後に陥る(ような気がする)
4) こういう時間がかかる処理でヒマこいている時に、暇つぶしに何かぼーっとしている時に大抵こういう状態に陥る。
5) ディスクの空き容量が少ないPCに出やすい現象(のようだ)
6) リブートすらできない。そもそも、リブートボタンまでたどり着けない。仕方がないので DOS 窓から > shutdown /r /t 0 してものろのろお帰りのお仕度を初めて、エラク反応が遅い。
7) そういう時にかぎって、急な用事を思い出して、こなさなければならない。で、トラブルシューティングを始めたら、「急いでやるべきこと」を忘れてしまうというオマケ付き。
8) ディスクの空きが余裕のヨッちゃんなPCでは現象出ず。
9) Windows Update Service を無効にしてみる。ただし手動アップデートもエラーになるし、やっぱりHDD 100% 病は治らない。 (確かになぁあり得るんだよな)
a0056607_17024038.jpg
「田(田圃アイコン)」の右クリック > コンピュータの管理 > サービスとアプリケーション > サービスから、
"Windows Update Service" を無効にしてみた。



でもねぇ......

a0056607_15325339.jpg

こんなのが何時間も続くと、イライラが募って、もう昼間っから酒飲んじゃうぞって気分になるのですよ。

- 色々な対策 -

でも日曜日の昼間っから酒飲んでも問題は片付かないわけですね。という事で色々調べてみたのですが、皆様つぎのようなご苦労を色々しているようです。

1) 極悪の OneDrive を殺す (既に無効にしてるんだが)

極悪 Windows10 の OneDrive を無効にする

2) タスクマネージャでディスクに必死こいて、アクセスしまくるサービスを止めてみる(と言っても一番しつこいサービス停止は拒否されることが多いし...)

3) IPv6 を無効にしてみる(インストールしたら、即時そうしていますよ....)

Windows7 からWindows10 にアップデートしたらまずするべき事。

4) リソースモニタ > 「ディスクタブ」を開くと、ページファイルに必死に書き込んでいるので、ページファイルのサイズをいじってみた(効果なし)
当然、ファイルがジャンスカ書かれるので、アンチウィルス系のソフトウェアもビンビンで大忙しの様だ。

5) 仕方なく、物理的な電源ボタンから「強制終了」して、あるいはコンセントを引っこ抜いて、お祈りしながら起動できるかナぁ...

6) サービスの中の Superfetch を無効にする(とっくにしている)

Windows10 の停止しておきたいサービスとタスク

という事で前後の状況から、どうも「システムディスクに余裕がないときに大きなファイル操作をしている時に、ヒマこいて 「YouTube なんか」をぼーっと見ていると現象が出るわけなで、そういう時にこそ、急な調べものなんかをしたくなるのですね。

そこでアイドリングプロセス中にやっていそうな、一番アヤシいプロセス。「自爆(あ自動だ)メンテナンス」を止めてみました。

コントロールパネル > セキュリティとメンテナンス > 「メンテナンス」を開くと「自爆メンテナンス」「進行中」です。思わず007のロジャームーアになった気分。

a0056607_15361924.jpg
で、「自動メンテナンス」を「停止」したら、あれれ。

a0056607_15395644.jpg
2,30秒後に見事に嵐が止みはじめました。

もっとも、アイドリング状態から、いきなり使い始めても、すぐには戻りません。
これも「停止」させようにも、激重中に「停止」すら押せない事もあるので、もう致命的です。まるでオシッコが止まらないアル中患者のようにしつこく動き続けることがあります。

そういう時は、電源スイッチを長押しして「南無阿弥陀仏」を唱えながら、もう一度電源を投入するしか方法がありません。
無事お祈りが利いて起動できたら、「自爆....」あ、いや「自動メンテナンス」を「停止」させます。

もう一度「自動メンテナンス」を「開始」すると

a0056607_15425939.jpg
あらら、やっぱりこうだったか、とまた HDD 100% 状態です。逃げろロジャームーア。

a0056607_15450673.jpg

ただ、この「メンテナンス」ってヤツは「自動」で、アイドリング状態になると、ノラ猫のようにゴミ箱あさりを始めるので、また「停止」させなければなりません。しかも、この設定を弄れるのは、管理者アイコンが示す通り、「管理者のみ」です。
ユーザに「一般ユーザ」でログオンさせて使わせています、という様な、一般企業の環境では大変な大騒ぎとなるわけですね。

デフォルトでは、夜中の3時に、スリープ中のPCをたたき起こして「働かせる」という、プアなPCだったら「過酷な仕様」ですし、ほおーっておくと、また「勝手に開始」されてしまうようです。タスクスケジューラから「無効」にしても効き目はないようです。

ノートPCの Bios パスワードをかけて、「帰宅や外出で離席する時は、コンセントとネットワークケーブルを外してPCを机の中にしまっておく事」なんて、企業の運用ルールなんか無視しまくりです。

朝いちばんにノートPCを引き出しから出したら、奇妙に本体があったかいンだからぁ~、おまけにバッテリーは消耗しまくっているし。

となると、また朝いちばんからヘルプデスクの電話は鳴りっぱなしになるわけです。

試しにタスクスケジューラを止めてみてもだめでした。
a0056607_15475570.jpg
全くお節介で厄介な仕様なんですね。しかもコントロールできない、無敵の Microsoft 仕様なのです。

レジストリをツツけば「自動メンテナンス」を無効にできるようですが

How to disable Automatic Maintenance in Windows 10 and 7

によると

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Maintenance]

に " MaintenanceDisabled" という DWORD のキーを作って、値に 1 を設定してリブートすると、この「自動運転の嵐」は止むようなのです。ただし一応「システムメンテナンス」は、あの悪名高い NFTS のフラグメンテーションの補正だとか、あまり役に立つとはおもえないけれど Windows Defender のスキャン、いらなくなったシステムファイルやパッチなどのクリーンアップをするようなので、止めておくことは決して勧められるものではないようです。

だからシステムの変更があった時や大きなファイルを操作した時に、大幅な「席替え」をせっせとやるわけですね。もっとも、こんな事できるのは「管理者」だけなので、一般ユーザにこんなフクザツな作業をやらせたくない。

そもそもそんなのUIに常備しろよと言いたくなるのですが、あまり公にはしたくない、かなり怪しい機能なんですね。

だから、もし上のレジストリを弄ったら、もう一度 Value を 0 にして、メンテナンスをして放置プレーするしかないようです。お勧めはしませんよ。

つまり、「Windows10 に於る HDD 100% アクセス激重シンドローム」には「萬金丹」のような万能の薬はないと言ってもいいのです。
a0056607_17123739.jpg
伊勢の萬金丹
鼻くそ丸めて萬金丹」



- まず一番効果的と思われるのは-

とにかく、エンドユーザさんには「ローカルディスクの空きを沢山空けておけ」空きに余裕があれば、そう滅多に自動メンテナンスはしない(ような気がする)。何しろフラグメントの起こりやすい事で有名で、25年以上昔に開発されて厚化粧を繰り返してきた Windows の NTFS だ。重くなって仕方がない。またデカいファイルなんか、特に Hyper-V とか動かすと、4Gの ISO だとか 40Gb の VHD 仮想ディスクイメージなんかが、ごっちょりあるので少しは整理して、放置プレーということでしょうかね。

まぁ、除虫剤のように「お出かけ前に」メンテナンスモードにして「帰ったら窓開け換気」じゃないな、メンテナンスモードを解除するのが、この暴れ馬を乗りこなす一つの方法かも知れません。

それにしても、こんな現象ってやっぱり Windows サーバーでも起こるのでしょうか。だから Windows (Storage 版の NAS も含む)のファイルサーバーって信用できないンですけどね。Hyper-V なんぞで、ディスクの容量ギリギリでスナップショットなんか取ったら、悲惨そう....

それから Windows のログも見てチョウダイネ、という事です。

- 結局そういうことだったのか -

やっぱり Windows Log はみるべきだった。ディスクエラー出てるんじゃん!

a0056607_14593478.jpg
という事で、ディスクエラーがでているので、バックグラウンドタスクが何度もリトライするわけですね。という事で、このPCもうダメじゃんということが判りました。

PS:その後見事に昇天し、最後を遂げましたトサ。南無南無............





--
Windows10 HDD 100% 重い、遅い、Hyper-V Windows 制御不能 メンテナンスモード

[PR]
# by islandcenter | 2017-06-19 15:29 | Windows | Trackback | Comments(0)

-現象-

ローカルネットワークから、Squid プロクシ経由でインターネット接続している場合、 Windows Update Service 3.0 (WSUS) サーバからアップデートできない。この現象は Windows7 環境では発生せず Windows10 以降(具体的には 1607以降)のバージョンで発生する。

Windows 10 / Windows Server 2016 を含め、プロキシ サーバーを介して Windows Update サイトへアクセスした際に、更新プログラムの検出が通信エラー (0x80240030 / 0x80072efe / 0x80244022 / 0x80072EFD / 0x80072EE2 等) でうまくいかない、あるいは更新プログラムのダウンロードが通信エラー (0x80072ee7 / 0x8024402c 等) で進まないといったお問い合わせをいただくことがございます。

プロキシ サーバー経由での Windows Update へのアクセスについて

また、WinHTTP に対してプロキシ サーバーが適切に設定されているかをご確認ください。

-------

「ナヌ! WinHTTP って聞いたことないぞな?」

と、どうやらインターネットマーケットで一般的な Squid などのプロクシ経由では、「WinHTTP という、我等大変困惑独善非標準的詳細非公開的謎通信網」はエラーになってしまうようですね。つまり、WSUS は HTTP(s) 80,443 ポートを使うにも関わらず、一般的な HTTP(s) ではなく WinHTTP というレッドチャイナ並の特殊で非公開な極秘な通信するという事なのですね。(はじめて知った......)

「うちは、ほぼ世界標準の Squid プロクシなんだけどなぁ.....」

という場合、例外リストに明示的にプロクシの設定から WSUS サーバーを除外する必要があるようです。

- 対策 -

ローカルLAN内に Squid などの Proxy がある場合、コントロールパネル > インターネットオプション > 「接続」タブ > プロシサーバー > 「詳細設定」ボタンから「例外」リストに

"*.mylocalzone.mycompany.com;" のローカルゾーンか WSUS の、生IP アドレス(192.168.1.xx;)などをセミコロン区切りで明示的に追加します。
a0056607_15232155.jpg

どうも Windows10 Version 1607 あたりから、WSUS の挙動がおかしくなったナとは思っていました。この場合、単純なLAN内部のプロキシキャッシュなので、月のモノのWindows Update をする場合、一時的にプロクシを外せばいいのですが、Windows10 1607 以降、Windows Update ってやたらと時間がかかるじゃないですか。その間、色々モンダイがあるわけですよ。まぁ、このケースではこれで「一応」解決できていますが。

例えば、 Windows Update の「更新プログラムのチェック」をしても、全部アップデートできない。その様なときは "オンラインで Microsoft Update から更新プログラムを確認します"をクリックすると "ご本尊" からのアップデートを更新して、 WSUS にアップデートがキャッシュされるようです。最初の1台目でキャッシュすると、以降はイントラネットの WSUS からアップデートを "ダウンロード"だけはしてくれるので、2台目以降は、 WSUS から、文字通り "Windows Update Service" のキャッシュが参照されて、ピピッと、"ダウンロードだけは" 行われます。もっともその後の「更新のインストール」だけは、ユーザさんには、朝のコーヒー飲んで、ついでにトイレにでも行ってPCの性能次第で「まったり待つ」必要があります。
a0056607_23382112.jpg
もっとも、Windows Update の”状態の更新”は、深夜に行われるようスケジュールされるので、実際の現場では "朝イチバン"に、パッチの適用と、 WSUS への通知が行くようです。月モノによっては二度のリブートが必要なケースもあるので、翌日もう一度"リブートしろ"と出るケースもあります。ユーザさんは待ち時間でゆっくりトイレで××コ「していても、インフラ担当者は、漏れそうでも「そんなヒマねぇよ」という我慢の時間帯です。

まぁこれも給料の一部だとおもって、諦めてください。あらかじめ総務にお願いして Windows Update を 「承認」した、翌数日間は、役員用トイレも解放しておくようお願いするのもイイかも。

a0056607_23400558.jpg
でも、同時にWSUS 上にも正しく更新された情報が伝わるようで、WSUS の登録されたPCの全てが数日後に 100% パッチ完了となります。やれやれ......

山市良のうぃんどうず日記(97):進まないWindows Update、やっぱり止まっていなかった

--

でセキュリティアプライアンスや、チャイニーズ製グレートファイアウォールなどが導入されている環境の場合、

Windows Update / Microsoft Update の接続先 URL について

によると、2017/2 現在....

http://download.windowsupdate.com
http://*.download.windowsupdate.com
http://download.microsoft.com
https://*.update.microsoft.com
http://*.update.microsoft.com
https://update.microsoft.com
http://update.microsoft.com
http://*.windowsupdate.com
http://*.windowsupdate.microsoft.com
http://windowsupdate.microsoft.com
https://*.windowsupdate.microsoft.com
http://ntservicepack.microsoft.com
http://wustat.windows.com
—————————-
※Windows 10 の配信の最適化を使用するためには以下の URL も併せて通信を許可するように設定ください。
—————————-
*.download.windowsupdate.com
*.au.windowsupdate.com
*.tlu.dl.delivery.mp.microsoft.com

の全てを、プロクシキャッシュなどの、セキュリティアプライアンスを使う経路から除外しろ、という事になりますね。これらを除外リストにズラズラと Windows10 の場合(;) セミコロンで区切って羅列します。(それも全部)

コピペ用に書いてみましたが、プロクシがある環境では、例外リストを「こうしろ」という事ですかね。間違っていたらご指摘下さい。
------ここから
*.download.windowsupdate.com;*.download.windowsupdate.com;*.download.microsoft.com;*.update.microsoft.com;*.windowsupdate.com;*.windowsupdate.microsoft.com;*.ntservicepack.microsoft.com;*.wustat.windows.com;*.download.windowsupdate.com;*.au.windowsupdate.com;*.tlu.dl.delivery.mp.microsoft.com;
ここまで-----

ちなみに

Windows Update / Microsoft Update サイトへの接続先 URL は不定期に変更されることがございますので変更が生じた際は本ブログも更新いたします。

とあるので要チェックです。(つまり予期なく変更ということで.... はぁ?)

セキュリティアプライアンスなどの設定も要注意ということになります。あるいは "WinHTTP という謎” を克服するか。

どうも

netsh winhttp set proxy proxy-server=

というインディジョーンズも解読できない呪文を管理者モードで実行せよというのもありです。

これで謎の WinHTTP も強制的に、システムプロクシの設定に合わせてしまうようです。世間一般および新華社通信によると、どうもこのコマンドはプロクシを使う環境では香港土産の謎の萬金丹のように良く効くようです。

プロキシ サーバーを使用する環境にて Windows Update を実行すると通信エラーが発生する

じゃ、トランスペアレントプロクシだとかセキュリティアプライアンスがインターネット接続のトポロジのグレートファイアウォールにある場合はどーなるンでしょうね。ウチの環境の場合 WSUS サーバーも LAN内にあるので、WSUS 自体も Squid Proxy を使う事(なぜか問題ない)になるので、とりあえずは問題解決ですが、トランスペアレントプロクシがグレートファイアウォールを作って、そこから経由して WSUS がローカルで構築していない環境では、ちょっと困ったモンダイになりそうな悪寒です。

また必ずしも、全て WSUS 3.0 経由では当たらない「累積パッチ」もあるようです。この問題は Windows2012r2 標準の WSUS 4.0 で解決しているかどうかはわかりませんが....やっぱりこれも謎の呪文を唱える必要があるようです。

Windows Update で通信系のエラーが出た場合、近所のセブンイレブンとかの無料、暗号化なし Wifi フリースポットへ走って(あるいはPCをかついで)アップデートし、ついでにウィルスクサいメールをかたっぱしから開きまくって、アンチウィルスが正しく動作しているかどうかテストしたり、銀行振込してパスワードダダ漏れさせてみる、のもヒマつぶしには面白いかもしれません。

Squid 本家の次の文書も見つけましたが、情報が古くて全然アテにならないようです。どうやら "Windows そのものの問題” と捉えているようなので、あの謎の萬金丹のコマンドを使え、という見解のようです。

How do I make Windows Updates cache?

全く、Windows10 anniversary Update 以降の Windows Update はどうも問題が謎な部分が多くあります。中国製かと思われるぐらい不可思議.....
Windows7 時代に構築して問題なかった WSUS の運用方法も Windows10 時代では適応できないようです。


-その他の記事-

Windows 2008R2 で作る WSUS 3.0 sp2 Windows Update Server

WSUS のディスク容量がピンチ!空き容量を一挙に増やすには

Windows Update Service(WSUS) の日常の運用

Windows10の Windows Update はデフォルトで使ってはいけない。



※言い訳:すみません、いつも「串」って言ってるんで「風呂串=プロクシ」と読ンじゃう私はやっぱり古いタイプなのです。世間では「風呂岸」なんですね。




Windows10 WSUS 3.0 Windows Update Error Squid Proxy キャッシュ、キャッシュアプライアンス、プロクシ、プロキシ、



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


どうも世の中、Linux のサービスの、リストアップ、起動、停止を行うために chkconfig、service というコマンドがあるそうなのですが、 SUSE Linux を使う場合、まずお世話になることがありません。勿論、これらのコマンドは実装されているのですが、ほとんどのサービスの管理は # yast (or yast2) > System > System Service(SLES12 では Servie Manager) の中で行います。

SLES11 の System Servie
a0056607_13281346.jpg

この使い勝手よ良さは systemd を採用した SLES12 でも引き継がれ、Servie manager となりよりシンプルになりました・

SLES12 の Service Manager
a0056607_13284102.jpg

SLES12 の Service Manager , CUI 版
a0056607_13290645.jpg


勿論テキスト端末から、慣れた Service の再起動には # rcXXXX" コマンドや "#/etc/init.d/xxxx restart" を使いお世話になることもあります。その程度なら、何しろお手軽ですからね。

でも YaST で、インストールし、During boot をアクティブ設定をして、その他、必要な設定をすませば、ほとんどサービスマネージャを使う事もありません。もしサービスが安定していなくて「よく分からんぞ」という時は、YaST のサービスマネージャで、サービスのステータスチェックから、起動、再起動、chckconfig, inittab, fstab の書き換えまで行えます。
画面をスクロールしたり、難しそうに「うーむ」と唸りだしそうに眉間にシワを寄せて、非番の殺し屋が、突然ゴルゴ13の様なムズカシイ顔に変身して、綴りを間違ってキーボードを乱打しないので、非常に楽なのです。

何しろ、本棚の中から「誰でもカンタン Linux コマンドリファレンス」なんてアンチョコ本を取り出してページをピロリピロリと探すヒマがあれば、さっさと YaST を立ち上げればいい。まぁ私の場合、それほど難しい事をやっていないということもあるのですけどね。

※ ちなみに SLES12 では service/usr/sbin/rcXXXXX は service コマンドのシンボリックリンクになりました。

「難しいを簡単にできる」事が SUSE Linux の YaST なんですね。

でも、「自宅のXXサーバー」なんて記事を見ると、いかにもコマンドがズラズラで、これで「やっぱ Linux サーバーは使い易いや」なんて思っている人ってどれくらいいるのでしょうか。Linux の入り口で本当にその通りにやって途中で綴りミスなんかでエラーが出てしまって「挫折する」ヒトもいるわけだから、chkconfig だとか、yum や apt-get のマニュアルページをひたすらじーっと眺めて、YaST なら数クリックでできる作業も、Apache のインストールごときに、ごっちょりページを割いて「俺は Linuxの 使い手なのだ。タッチタイプのプロだぞ。スゴイだろ」という感じのコムズカシイドキュメントを作っているヒトってやっぱり、私よりは賢いけれど平均的なヒトから見ると、ちょっと特殊に思えてしまい、「やっぱり Linux では HTTPサーバーのインストールすら難しそう」となってしまいます。

YaSTは、昔、映画で見た、良く設計されたドイツの潜水艦の司令室みたいなもので、一つ人のコマンドを別個に使うのではなく、各種パラメータを一つのコントロールパネルで設定して最後にレバーを下すと、YaST に設定されたパラメータを次々と処理して「魚雷発射!ズシン!」となるわけですね。例えは悪いかも知れませんがいかにも SUSE Linux に標準の YaST はドイツ製、質実剛健、合理的な設計なのです。






- Keyword -

Linux サービス管理、chkconfig rcコマンド SUSE SLES openSUSE


[PR]
# by islandcenter | 2017-06-06 13:20 | SUSE | Trackback | Comments(0)

SUSE Linux の YaST Partitioner によるパーティション管理を説明します。

SuSE Linux (SLES, SLED, openSUSE) のパーティション管理は、通常 YaST の "Partitioner" によって行います。勿論、「fdisk や fstab の直接編集の方が慣れている」のであれば、その通りで、SUSE Linux でも基本的なコマンドラインを使ったパーティション操作は、他のディストリビューションと同じです。ただ、アンチョコ本に書かれている様なパーティション操作に、不慣れな管理者にとっては YaST の "Partitioner" は心強い味方となるでしょう。

また私の様に「コマンド叩きには疲れたよ、老眼鏡ほしい」と言うような年寄管理者にとっても、一度 YaSTの"Partitiner" に慣れてしまえば、もう「コマンド叩きはいいや」と思うかもしれません。資料の少ない GParted の様なGUIを後で自己責任で導入するより、YaST Partitioner はSUSE によってサポートされる標準装備なので、安心して使う事ができます。

不用意な操作で、データがそっくり喪失されるパーティション管理は、事前にバックアップを取っておきたいくらい、わかり易い手順と確認が重要です。

- 起動 -

YaST の Partitioner は CUI 版 yast コマンドと、GUI 版 yast2 の両方に実装されています。

どちらかと言うと、[TAB][SPACE]{+][-] などを多用する CUI 版より、1クリックでダイアログが遷移する GUI 版の方が、誤操作は少ないかもしれません。やむを得ない場合を除いて、GUI 版 yast2 の Partitioner を使う方をお勧めします。何しろパーティション操作は、データロスを伴うエキスパートでもやりたくない非常に危険なタスクです。
という事でここでは SUSE Linux のGUI 版 yast2 の Partitioner からのパーティション操作を見てみましょう。

# yast2 & (またはyast) > System > Partitioner を選ぶと、一応「非常にキケンを伴う作業でデータを失うかも知んないけん熟練者だけやってケロね(意訳)」という警告のダイアログが出ます。 "Continue" します。

※なお、ここでは基本言語は English に設定しています。YaST は ALT+キーのショートカットは英語版の方が便利なんですね。勿論、言語を "Japanese" にすれば一応おおよそ理解できるニホンゴ表記になります

GUI版
a0056607_09390380.jpg
CUI版
a0056607_09404875.jpg
- 参考文献 -
Using the YaST Partitioner

- パーティションの作成 -

※今回は機材の都合により SLES11sp4 を使っています。

たまたまわずかばかりの空き領域が /dev/sdc にあったので、"Hard Disks" > "sdc" を選んで "Add" ボタンを押してみました。
a0056607_09431411.jpg

まずは、空きディスクを、プライマリパーティションにするか、拡張パーティションにするかどうかです。一般的なPC/AT アキテクチャでは、OSに関わらず一つの物理ディスクにはプライマリパーティションは4つまで作成できます。なぜそうなのかはここでは聞かないでください。もし間違っていれば、コメントください。

ここでは "Primary Partition"を作り、次に拡張パーティションを作ってみます。

サイズを最大サイズにするか、指定サイズに控えておくか、ここでは "Custom Size" を選んでみました。最大サイズ以下の数値を与えます。
a0056607_09445862.jpg

※ これば「アナタの趣味だ」とご批判あるかも知れませんが。ディスク容量を物理ディスクの "Maximum Size” にせず、数10Gb 程度、空けておくのがいいと思います。 dd で同じサイズ、モデルの別ディスクにフルバックアップコピーを確実に取れるし、いざとなれば、別な Linux のシステムをインストールして、 Rescue 用にも使えるかな、という、あくまでも「趣味」かも知れませんが。

"Extend" パーティションが用意されます。 > Next

a0056607_09464506.jpg

今度は拡張パーティションの中に Logical Partition を作ります。> Next

a0056607_09483507.jpg

さて、ここがキモなのですが、パーティションをフォーマットするかしないか、フォーマットするならどのファイルシステムなのか、同時に、マウントしてしまうのか、あるいは、手動でマウントするのかの指定を行います。

a0056607_09502831.jpg

SLES9 では RaiserFS が標準でしたが、SLES10/11 では Ext3、SLES12 以降は、ロールバックできるように "/(ルート)" に BtrFS、別に分けたデータ用のパーティションに XFS がデフォルトとなっています。ただし SLES12 でも、スナップショット、ロールバックがが必要であれば記憶には BtrFS も使います。/database だとかのデータベース領域だとか、仮想化システムのスナップショットを取りたい場合などですね。
SLES では Ext4 の読み取りだけをサポートしています。ひと昔前の openSuSEでは Ext4 が採用されていました。

"Do not Format partition" を選ぶと、パーティションは初期化されないので、例えば、他のシステムから取り外したディスクのデータをそのまま使いたい場合はこちらを選びます。

"Mount partition" をチェックすると、Mount Point も同時に指定します。例えば /var を別パーティションにするとか、独自のディレクトリ、/database を別な専用パーティションにするなどの場合です。"Do not mount partiton" をチェックすると /etc/fstab に書き込まれないため、mount コマンドでマウントする必要があります。iSCSI デバイスなどでは、まれにマウントできない場合があったり、外付けディスクの電源が入っていない場合や二台目のディスクが「ご不幸」になられた場合、"fstab のご指定のディスクが見つからないよ"となります。正常起動できないので、起動時に mount するかしないかはそれぞれの目的次第です。

まず、システムをインストールする時の1台目のディスク(Raidの仮想物理ドライブも)は、特に意識しない限り "Mount partition" です。
a0056607_09542069.jpg
さて、拡張パーティションの用意がスケジュールされました。

"F" のマークが付いているパーティションは"フォーマットするぞするぞ!" の予定フラグです。 "Mount Point" のところが "*" となっているのは「起動時にマウントする予定なし」あるいは、「まだマウントしない予定」というシルシです。"?" が付いているのは、fstab に書き込まれていない、手動マウントが必要なパーティションです。
a0056607_09563232.jpg

次の画面のサマリで内容を確認します。"赤字" で書かれているのは、「フォーマットしちゃうぞ、消えちゃうぞ、ホントにいいのか?」という警告です。 "Do not format" を選べば別な記述がなされるでしょう。
a0056607_10021526.jpg

"Finish" ボタンを押すと「執行」されます。ここまでの操作はあくまで予定で、コマンドライン操作のように、生きたまま皮を剥ぎ、指先を折るような、後戻りできない拷問ではありません。

指定された内容でパーティションはフォーマットされ、fstab が書き換えられます。

"Finish" すると計画されたジョブ通りにフォーマットや fstab の書き換えが執行され、 Partitioner は終了します。

ではもう一度 Partitioner で確認してみましょう。
a0056607_11302425.jpg

実際にテストしてみます。

sles11:/mnt # mount /dev/sdc5 /mnt/test
mount: wrong fs type, bad option, bad superblock on /dev/sdc5,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try <--- おっと、失敗したみたい。
dmesg | tail or so
sles11:/mnt # cd test
sles11:/mnt/test # ls <---- 今の所何もない
sles11:/mnt/test # touch myfile
sles11:/mnt # umount /dev/sdc5
sles11:/mnt/test # ls -al
total 8
drwxr-xr-x 2 root root 4096 Jun 1 15:40 .
drwxr-xr-x 4 root root 4096 Jun 1 15:39 ..
-rw-r--r-- 1 root root 0 Jun 1 15:40 myfile <--- umount してもファイルが残っている
sles11:/mnt/test #

どうもうまく行かなかったようです。これは SLES11 で公式なサポートがない XFS を使ったことが原因です。

- パーティション削除 -

そこで、間違えてつくってしまったパーティションの削除をやってみます。物理デバイスからパーティションを選び右ボタン、あるいは Delete ボタンから "Delete"します。

確認して Next
a0056607_11374107.jpg
リストから消えました > Next

ここまでは、「作業の予定」が定義されただけです。 "Finish" ボタンで「執行」され後戻りできなくなります。不安があれば "Abort"してください。

実際には "Finish" によりパーティションのフォーマットが開始され、データが削除されます。
ここで不安があって、中止したい場合、最後のチャンスです。
"Abort" できます。

サマリ画面で、削除される予定であることが「赤字」で表示されることを確認して > Finish

a0056607_11403871.jpg
- 再度チャレンジ -

XFS パーティションのマウントに失敗したので SLES11 デフォルトの Ext3 フォーマットしてみます。後は同じ操作です。
a0056607_11434644.jpg

実際にマウントしてファイルが書き込めるか確認してみましょう。

sles11:/mnt # mount /dev/sdc5 /mnt/test <---- 問題ないみたい。
sles11:/mnt # touch /mnt/test/My-Test-File <---- ファイルを作ってみる
sles11:/mnt # ls -al /mnt/test/
total 24
drwxr-xr-x 3 root root 4096 Jun 1 16:39 .
drwxr-xr-x 4 root root 4096 Jun 1 15:39 ..
-rw-r--r-- 1 root root 0 Jun 1 16:39 My-Test-File <--- 作られたファイル
drwx------ 2 root root 16384 Jun 1 16:38 lost+found <--- パーティションのルートに必ず作られるディレクトリがある
sles11:/mnt # umount /dev/sdc5 <--- umount してみた。
sles11:/mnt # ls -al /mnt/test/
total 8
drwxr-xr-x 2 root root 4096 Jun 1 16:23 .
drwxr-xr-x 4 root root 4096 Jun 1 15:39 ..
sles11:/mnt # <--- 別パーティションのファイルは見えなくなった。

どうやらうまく行った様です。

マウントしてもう一度 Partitioner で確認してみます。
a0056607_11481185.jpg
"Mount By" に "?" が付いているパーティションは、fstab にかきこまれていない、手動でマウントされたものです。パーティション作成の時に "Mounting Opttion" > "Mount Partition" をチェックしてマウントポイントを指定しておけば、fstab に書き込まれ、起動時に自動的にマウントされます。

※ これはテスト環境なので、起動ディスク以外のパーティション以外は手動マウントしています。物理ディスクをデータ用に追加した場合、もしディスクに障害があると、fstab にマウント指定されていると起動できなくなります。仕方がないので Rescue 状態から、皆さんの大好きな vi エディタで fstab の該当の行を削除(コメントアウト)する必要があります。


- いかがでしたか -

SUSE Linux でのパーティション管理は、熟練エンジニアにとっても手軽だし、「まだ未熟」な Linux オペレータさんにとっても、割と理解しやすいインターフェースが YaST の中に用意されています。Linux の"キホン"さえ知っていれば、「パーティション操作」という、データロスにつながり易いクリティカルな作業も、fdisk の難解なコマンドオプションと表示内容を理解して、闘う必要もなく、何とかなるものです。

他のディストリビューションでは、これほど使いやすいパーティション管理ツールが「標準装備」されているわけでもなさそうですし、たとえ 「GParted の様なGUIツールがあるじゃん」と言っても、GParted パッケージそのものが一般的なディストリビューションにデフォルトで付属されてインストールされていないようですし、インストールで挫折するくらいなら、ハジメから「Linuxを知りたいし安定して使いたい」事を目的としては SUSE Linux の敷居の低さが理解できるでしょう。



- Key Word -

Linux パーティション管理、パーティション作成と削除の方法、SUSE Linux、SLES、SLED、openSuSE、yast、


[PR]
# by islandcenter | 2017-06-02 11:52 | SUSE | Trackback | Comments(0)

SUSE Linux (SLES,SLED,openSUSE) のパッケージ管理、インストールと削除のほとんどの作業は YaST(Yet another Setup Tool) というオープンソースの統合管理ツールで行います。

YaST は単なるパッケージ管理ツール(コマンド)ではなく、Linux のセットアップに必要な作業を組み合わせた、言わば「セットアップツールの集合体」のようなものです。Linux のシステム管理者は、初心者から、熟練した技術者まで、全て YaST を通じて必要な設定を行う事ができるため、手元に「コマンドリファレンス」の様なアンチョコ本を頼りに、正確な綴りのコマンドラインを操作する必要はありません。

ここで説明するようなパッケージ管理をはじめ、「最低限の作業」を直感的に行えます。


第3章 テキストモードのYaST

- SUSE Linux のパッケージ -

パッケージの提供方式は rpm なので、必要であれば、rpm コマンドもつかいますが、GUI版 yast2 で、rpm パッケージを open すると yast のインストーラが立ち上がります。もちろん、単体で動くような、依存性のないアプリケーションをテキストコンソールからインストールする場合は、rpm コマンドも使いますが、SUSE Linux では依存性の多い複雑なアプリケーションをインストールするには、通常 YaST を使います。

他にも zypper コマンドラインツールもありますが、これは CUI で Man & Machine の対話形式で使うもので、SUSE Linux のオペレータは特殊な目的でなければ、基本的には滅多に使わないでしょう。他のディストリビューションでは yum や apt に相当するコマンドです。
詳細にパッケージをコントロールしたり、シェルで一括変更したい場合などの場合は利用することがあります。

まず、およその流れとして、SUSE Linux のパッケージのインストールは YaST > zypper > rpm がそれぞれ入れ子になったような構造だと考えても良いでしょう。

- パッケージ管理だけではない YaST の機能 -

YaST は単にパッケージ管理を行うだけの機能ではありません。YaST では、ネットワークの設定からパッケージ管理、ネットワークのアプリケーションの細かな設定、ユーザ管理、仮想化ハイパーバイザーの管理、サービスの起動から停止まで、ほぼあらゆるオペレータの管理タスクを自動化するツールです。

さらに SUSE のインストーラ自体が yast によるものです。したがって SUSE(SLES, openSUSE) Linux のインストールで最初に触れる I/F は YaST インストーラなのです。インストール作業自体をスクリプト化して、大量のコンピュータをセットアップするための Auto YaST 機能もあります。

第21章 自動インストール

「SUSE Linux で何か困ったことがあれば YaST を使え」が基本です。

パッケージのインストールを zypper や rpm で行い、手動で .conf などのファイルを書き換えると、YaST で整合性が保たれない場合があります。

依存性の大きな作業は全て YaST を使う事をお勧めします。
ただし、yast に実装されていない詳細なチューニングはダイレクトに .conf などのファイルを直接編集する必要があります。 squid proxy などがそうです。また、一般的なディストリビューション問題のないものがあるのに、わざわざソースからコンパイル、インストールする事も、独自機能を組み込んでカスタマイズしたいなど、よほどやむを得ない場合を除いて避けるべきでしょう。YaST のアップデート機能でアップデートすべきです。

もっとも YaST でインストールできないモノもあります。プロプラエタリなソフトウェアやデバイスドライバ、オープンソースでもメールソフトや Chrome などのブラウザ、ハードウェアに依存したドライバ類ですね。これらは、別途コンパイルしてインストールするためのインストーラがあったりします。

-YaST によるパッケージのインストール -

YaST を使った、パッケージのインストールは

# yast

または

# yast2 &

を実行します。"yast" はCUI版、"yast2" はX環境での GUI 版です。yast2 は、コマンドラインから起動できるだけではなく、gnome デスクトップのバーにある "Computer" アイコンに登録されています。よく使う機能なので、"Desktop"にショートカットを作っておくと良いでしょう。nautilus ファイルマネージャが使える環境であれば、xming や movaXterm などからクリックして実行できます。直接コンソールでGUI版を使いたい場合は systemd(SLES12) initd(SLES11まで) が Text モード(runlevel:3)の場合は # startx を使います。 Graphical モード(runlevel:5)で起動している場合は、そのまま Computer のアイコンにある "YaST Control Center" を開くだけです。なお、一般ユーザが yast2 を起動する場合は、root パスワードが要求されます。

putty や teraterm と言った Windows 用のテキスト端末からは CUI 版 yast を、movaXterm や xming と言ったXサーバーアプリケーションからは yast も yast2 も利用できます。

パッケージをインストールするには YaST のメインメニューから Software[TAB] > Software Management[ENTER] を選びます。

a0056607_16070011.jpg
※ここでは優先言語を "English" に設定してあるため、英語表記ですが、SUSE Linux Enterprise Desktop(SLED) や openSuSE をデスクトップ目的で利用する場合は日本語を優先言語にするケースが多いでしょう。その場合、メニュー表記は勿論日本語です。

"Filter" で "Search" ボックスから、ヒントとなるキーワードをセットして [Enter] ここでは "apache" を検索してみます。

a0056607_16073426.jpg
既に、このサーバーには "Apache2 Web Server" が [i] インストールされている事が判ります。GUI版ではこんな感じです。

a0056607_19515576.jpg
Filter を "Pasterns" 検索してみます。試しに DNS/DHCP を選ぶと、まだインストールされていない様です。[Space] キーで DNS/DHCP をチェックすると、依存性のある全てのパッケージが [a+] 追加インストール予定のステータスになりました。ここで [TAB] キーで "Accept"[Enter] すると、パッケージ名を知らなくても、 DNS/DHCP に必要なパッケージがインストールされます。

a0056607_16111312.jpg
パッケージをインストールしたら、YaST のメインメニューから"Network Service" の DNS を選んでみます。デフォルトでは、起動オプションが "Manually" になっているので、これを "When Booting" に変えます。DNS のゾーン設定や、よく使う DNS のオプションや Forwarder の設定などは全て、このメニュー画面から、TAB, 矢印キー, Space キーなどで設定し "Accept" すると、設定内容が反映されて、自動的にサービスが有効になります。この様に詳細設定をする際にこそアンチョコ本が役立つときでしょう。

a0056607_19251175.jpg

また、YaST のメインメニューから "Network Services" を選ぶと、例えば DNS という項目があります。これを選択して[Enter] すると、

a0056607_20300632.jpg
"Yet another Setup" なパッケージをインストールするかどうかの確認ダイアログが出てくるので、ここで "Install" [Enter] すると、自動的にインストールされ、続いて設定画面が出てきます。


- パッケージの削除 -

パッケージを削除するには、削除するパッケージを選んで[Space]キーをトグルします。"i" から "-" になり、"Accept" すると、パッケージの削除が始まります。

しかし、削除するパッケージに依存性がある場合、どのパッケージを残すか、削除するのかを確認"Space"キーでチェックして、中止(Cancel)するか、継続(Try Again)して削除するかを選びます。

a0056607_16133462.jpg
GUI 版 yast2 の場合も同様です。

a0056607_16142032.jpg
逆に、パッケージを追加でインストールする場合も、パッケージの追加を許すか、キャンセルするかを確認しながらインストールします。当たり前ですが Postfix が動いている環境では sendmail は動かないわけですから、パッケージの競合を確認しながら、作業する、という事です。


- 1 Click Install を使ったパッケージのインストール -

標準リポジトリに登録されていないプログラム、サービスを利用するには 1 Click Install の機能を使います。標準リポジトリ以外は、商用 SLE(S) SLED の公式なサポートはありません。また非商用の openSuSE の標準リポジトリにも含まれていない、オープンソースの類をどうしても利用したい場合に、自己リスクとして利用することができます。次の opensuse.org の Software 検索機能を使って目的のパッケージを Search します。


導入したいコンピューターに標準で含まれている FireFox ブラウザから

を開きます。そこで少なくとも GUI 環境は必要です。

openSuSE のソフトウェアページの "Search" ボックスからおおよそのパッケージ名をセットして Search すると、いくつかヒットするパッケージの一覧が出てきます。

"Direct Install" の下の "Show Other Version" > "Show unstable packages"を開くと、適応できる SLES と openSuSE の各バージョンと、RedHat などの他社ディストリビューションが出てくる場合もあります。

"1 Click Install" をクリックすると、自動的に YaST インストーラが起動するので、後はダイアログに従って操作すると、リポジトリの追加からパッケージのダウンロード、インストールまで全て自動で行われます。
a0056607_16150888.jpg
なお、 "YaST2 MetaPackages handler"がインストールされていない場合(たまにあります)、 1 Click Install を開くと ymp メタファイルがダウンロードされるだけなので、うまくいかない場合は標準リポジトリから "YaST2 MetaPackages handler" を search してインストールしてください。

ただし、常に最新のパッケージが用意されてるわけではないので、比較的、安定した枯れたパッケージを導入するには良いでしょう。

※ちなみに GUI 版 YaST はアイコンがシングルクリックで、それぞれのツールが起動してしまいます。ダブルクリックすると、ツールが二重に起動しますので、注意が必要です。これは gnome の設定に関わらず、"仕様" というワナなので、必ず「右クリック > Open」するように癖をつけておきましょう。そもそも管理権限で、何事もダブルクリックしたがるシステム管理者は、私は信用していません。

補足
SUSE で 1 Click インストールができない場合、YaSTにないメニューを追加

第7章 インターネットからのパッケージのインストール








-Keyword-

SUSE Linux, SUSE Linux Enterprise Server, SUSE Linux Enterprise Desktop, パッケージのインストール、パッケージのアップデート、パッケージの削除、パッケージの依存性, apt, yum, zypper, rpm コマンド


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

Windows10 に変えて、「さぁ昼休みだし、弁当食いながらソリティアでもやんべぇ、所詮Windows はPC用OSだし、モバイル用OSとしては。ド・マイナーなのよ。どうせ Windows Store のアプリで使えそうなのは、天気予報とゲームくらいだしなぁ」

と思ってアプリをクリックすると、アプリのタイトルは出てくるんですが、スコンと落ちる。再起動しても現象は変わらない。

という場合は、イベントビューワの Application ログを確認します。イベントビューワは、スタートボタン(別名:田圃ボタン)の右クリックで出てきます。
a0056607_16101603.jpg

こんな感じの良くわからないエラーが記録されていました。

障害が発生しているアプリケーション名: MyStore App
liction.exe、バージョン: 1.0.0.0、タイム スタンプ: 0x5762c9c2
障害が発生しているモジュール名: combase.dll、バージョン: 10.0.14393.1198、タイム スタンプ: 0x59028479
例外コード: 0xc000027b
障害オフセット: 0x001a5bb1
障害が発生しているプロセス ID: 0x28e0
障害が発生しているアプリケーションの開始時刻: 0x01d2cffcee24adb9
障害が発生しているアプリケーション パス: C:\Program Files\WindowsApps\0EB8BD08.MyStore Appliction_2.2.17.0_x86__erk4rrwmt7jyt\My Store Appliction.exe
障害が発生しているモジュール パス: C:\WINDOWS\System32\combase.dll
レポート ID: 738ea8f2-3402-4598-8a65-38abb3876ad0
障害が発生しているパッケージの完全な名前: 0EB8BD08.MyStore Appliction_2.2.17.0_x86__erk4rrwmt7jyt
障害が発生しているパッケージに関連するアプリケーション ID: App


- 様々な解決方法 -

- Store アプリのキャッシュを削除してみる -

"ストアアプリ"のキャッシュはここにありますが、これを全部消してしまいます。いくつかの破損キャッシュがあると問題が
あるようなのですね。

C:\Users\[[MyUserName.MyPC]]\AppData\Local\Packages\Microsoft.WindowsStore_8wekyb3d8bbwe

"MyName.MyPC" はログインユーザ名、または"ユーザ名.PC名"です。

a0056607_16123950.jpg

が、しかし、これは Windows Store からアプリをダウンロードするための、アプリ、つまり"「ストア」アプリ"そのもののキャッシュの様です。

例えばスタートボタンの「ストア」の表示が壊れている場合とか、「ストア」自体が起動できない場合にするものの様です。

試しに削除して、アプリを起動しても、この中身に変化はありません。「ストア」を起動すると上の様にいくつかのキャッシュが作られます。

-参考文書-

Windows10です。ストアアプリやマップ・フォト・カメラ等のアプリが「このアプリは開きません。」と表示され開けません。


- WSReset を実行してみる -

管理者権限でコマンドプロンプトを開いて、wsreset を実行してみる。コマンドプロンプトを管理者モードで開くのはスタートボタン(田ンボ)の右クリックが便利です。
a0056607_16152161.jpg

C:\WINDOWS\system32>dir wsreset*
ドライブ C のボリューム ラベルは Windows8 です
ボリューム シリアル番号は A2BC-1E52 です

C:\WINDOWS\system32 のディレクトリ

2016/07/16 20:43 91,136 WSReset.exe
1 個のファイル 91,136 バイト
0 個のディレクトリ 5,280,063,488 バイトの空き領域

C:\WINDOWS\system32>wsreset

> 以下「だんまり」全然終わらないので CTRL+C で止める

効果なし。

- Windows の再インストール -

 誰がやるもんですか、私なら絶対にやらないだろうなぁ。しかし、こういうサジェスチョンが多いのも事実なので、「暇と気の長いヒト」はチャレンジする価値はあるかもしれません。保証しませんが.....

-参考文献-

windows8 ストアが開けません

結局このコマンドも単に「ストア」のキャッシュをクリーンアップするだけなので、キャッシュのディレクトリのキャッシュを消すのと同じものの様です。

- 最後の手段、アプリの削除と再インストール -

 という事で最後の手段、アプリの削除と再インストールを行います。とりあえず、不具合はかなり解消されたのですが、昼休みに弁当食いながらのんびりマインスイーパーでもやろうか、という企みは、見事に Windows のワナにはまり込み、目を血走らせる無駄な昼休みとなりました。

- それでも動かないンですけど -

Storeアプリが起動しない

アプリの不具合であれば、しょうがないですよね

ご教示いただき、ありがとうございました。”

とフォーラムオペレータさんの回答に、諦めたご質問者様、ご愁傷様です。
結局、アプリケーションのバグ、という事で、アップデートされるまで待て、って事なんですが、アップデートが行われるかどうかはアプリの開発者次第なので、まぁ不幸としか言えないわけです。



[PR]
# by islandcenter | 2017-05-23 16:33 | Windows | Trackback | Comments(0)

==X端末から、nautilus ファイルマネージャの起動と終了。SUSE Linux(SLES11)==

DOS と UNIX のプログラマからスタートした仕事人生ですから、コマンド打ったりは別に苦でもないのですが、やっぱり Windows と過ごしてきたこの25年。やっぱりファイル操作はGUIでやった方がいい場合もあります。もっともコンソールからテキスト操作した方が便利な場合もありますが、テキスト操作だと、中々、老若男女、まぁ全てのオペレータさんが嫌がりますし、ファイル操作ごときにコマンドなんか覚えたくないと露骨に嫌な顔をされるとこちらも、困ってしまいます。

直接コンソールを操作しないで、できるだけリモートで操作するとなると、当然 Windows 端末から操作しますから、テキストコンソールは、今までハワイの海岸で流れ星を見ていたのに、いきなりフェアバンクス郊外のモーターストップで野宿しながらオーロラを見るような気分になるようです。

という事でやっぱり SUSE Linux ではオペレータさんに 「nautilus ファイルマネージャを使ってください」という事になります。そこで、 Windows から xming や movaXterm から nautilus を起動し、終了する方法です。

= X 端末から nautilus の起動と終了方法 =

- 起動 -

通常は、Xサーバのテキストターミナルのプロンプト # から "nautilus &" を実行します。"&" を付ければ、GUIはデーモン化して、 WIndows に常駐します。一度 "Enter" を押せばプロンプト "#" はテキストコンソールに戻ってきます。

"&" を付け忘れてもいいのですが、今度はほかの yast2 などの GUI アプリケーションが起動したりテキスト操作ができないので、一応、「付けといてね」とオペレータさんへの操作マニュアルなんかを使う時は記載して指導します。

sles11:~ # nautilus &
[1] 18820
sles11:~ # Initializing nautilus-open-terminal extension
Initializing nautilus-share extension

** (nautilus:18820): WARNING **: Can not calculate _NET_NUMBER_OF_DESKTOPS

: Nautilus のデスクトップが表示されます。以下中略


- 終了 -

もし"&"を付けずに # nautilus[Enter] してしまった場合、コンソールにはプロンプトが戻ってこないので、その際は CTRL+C を押せば nautilus が強制終了して、プロンプトが戻ってきます。それは裏のテクニックだと考えた方がいいでしょう。私の場合、通常は "&" を付けて起動します。あるいは X サーバーのアプリケーションを終了してしまえば、セッションも終わるので、nautilus も終了します。

しかし、nautilus で開いたフォルダは閉じる事ができても、"デスクトップ"だけは閉じるためのボタンがありません。そこで nautilus を終了させるため、X端末から、あるいは nautilus デスクトップ画面の、空いているスペースで右ボタンを使って テキストのterminal を開き

# nautilus -q

を実行します

sles11:~ # nautilus -q
sles11:~ # Shutting down nautilus-open-terminal extension

==SUSE Linux (SLES11)の、ファイルマネージャの表示をリスト表示にする。==

Linux を使い始めると、手元のアンチョコを見ながら、まずはファイル操作のコマンドを覚えようとするでしょう。しかし、不慣れなオペレータさんにとっては、コマンドをいちいち叩くのは苦痛そのもので、大抵は挫折してしまいます。また、私の様なメンドクサガリ屋も、テキストインターフェースで頑張らず、できるだけ省エネルギーで操作をしたいわけです。

そこで、GUI操作したい訳ですね。

SUSE Linux (SLES11の場合) nautilus デスクトップを開き、ディレクトリを開くと、デフォルトでは「Icon View」になります。右上の "Icon View" を "List View" に変えると、ファイル名やサイズと時刻、ファイル属性の概要が、コンパクトに表示され、ソートも簡単なのでグッと使いやすくなります。
a0056607_14473579.jpg
※ここでは私の好みで、どこかのメジャーなOSメーカのデスクトップシステムのような中途半端なローカライズで、意味不明な機械翻訳の誤訳が多い表示だと困るので、デフォルト言語を English に設定して説明しています。Default Language を"Japanese" にすれば、日本語のメニューになります。もちろん言語は English でも日本語の UTF ファイル名の操作には影響はありません。

という事で、Windows から xming や movaXterm を起動して # "nautilus &" を実行すると、SLES のデスクトップが開きます。ここでファイル操作をおこないます。

しかし、デフォルトの起動状態が Icon View なので、ファイルの情報量が少ないし、見つけにくい。そこでこのビュー画面を List View にするには、右上の Icon View をトグルして List View に変えます。とは言えディレクトリフォルダを開く度に List View にするのも面倒です。

しかし、いちいちディレクトリを開いて、ビューを変更するのは非常に面倒くさいので、デフォルトのアイコンビューを "List View" にしてしまうには、

Edit メニュー > "Preferences" より

a0056607_14490028.jpg

"Default View" の "View new folders using" を "List View" にして "Close" します。
a0056607_14493518.jpg
これで、ディレクトリアイコンを "Open" すると、全てリスト表示されます。ファイル名やサイズによるソート処理、日付のソートなども List View なら簡単に行う事ができます。

この他に nautilus から、ファイルの圧縮、解凍、テキストの編集や gedit のテキストを Windows 側のメモ帳などにペーストするなどの技が使えます。

参考元



SUSE Linux SLES SUSE enterprise server nautilus デスクトップ ファイルマネージャ nautilus 起動と終了 アイコン表示 リスト表示への切り替え

[PR]
# by islandcenter | 2017-05-23 14:53 | SUSE | Trackback | Comments(0)

SUSE より SLES12sp2 がリリースされて時間が経ってしまいましたが、インストーラから変わったところや、仮想化周りの印象について、実際のインストールをしてのファーストインプレッションです。インストールは仮想環境で行ったので、実際のベアハードウェアにインストールした時とはちょっと異なる点をご理解下さい。

-インストール開始-

CD/DVD から起動します。Installation を選択
a0056607_10475843.jpg

License Agreement の "I Agree" をチェック

言語の設定は English US, キーボードだけ Japanese を選び、106 キーボードの特殊キーが認識されていることを確認します。
SUSE にかぎらない事ですが、他国語をローカライズした場合、エラーメッセージが奇妙なニホンゴになって"意味不明"な場合って多いんですね。特に Windows のイベントビューワなんか意味不明なニホンゴの羅列で、日本語のエラーメッセージをまた英語に翻訳するという二度手間になりますから、メニューが英語になる程度であれば、基本言語は English を選ぶのが良いでしょう。後で日本語フォントをインストールすれば、アプリケーションは日本語で利用できます。

a0056607_10493440.jpg



ネットワークの設定画面です。"Edit" でIPの固定化や "Hostname/DNS" でリゾルバの設定、Routing でデフォルトゲートウェイの設定を行います。

a0056607_10524570.jpg
IP の設定画面ですね。Static IPと Subnet Mask, Hostname を設定します。

a0056607_10533784.jpg

これは、DNSとドメイン名の設定の画面、同様に Routing タブを開き、デフォルトゲートウェイを設定します。

a0056607_10540875.jpg

Registration は Skip します。カスタマセンターへの登録は後でもできるので、ここでは Skipします。 YOU(YaST Online Update) によってアップデートした後、動かないデバイスがコンパイルできず苦労したことがあるので、出荷時のそのまま”素”の状態で作業を進めて、後でパッケージやカーネルのアップデートを手動でやった方が良いでしょう。

a0056607_10581364.jpg

Add On Product は通常何もないのでそのまま Next

a0056607_10590527.jpg


システムの基本的なインストール方法は "Default", "KVMハイパーバイザー", "XEN ハイパーバイザー"の中から選びます。ただハイパーバイザーのみを選んだ場合は、GUI が使えませんので、後に GUI をインストールするのが良いでしょう。ここでは KVM ハイパーバイザーを選びました。

a0056607_10593877.jpg

パーティション作成の Suggestion です。デフォルトでは "Swap", "/" の2パーティションなのですが、ルートパーティションは Btrfs がデフォルトです。データ用のパーティションは XFS が推奨されています。 Expert Partitioner を開いてパーティションを必要に応じて変更します。


a0056607_12263735.jpg


デフォルトのパーティション設定です。 ルートパーティションが Btrfs になっています。

a0056607_12272660.jpg


ルートパーティションを選んで "Resize" ボタンを押すと、ルートパーティションの確保サイズを変更できます。

a0056607_12275884.jpg

あるいは、このメニューから "/" を削除(Delete)して、お好みのパーティション、ディスクフォーマットを "Add Partition" することができます。

a0056607_12282105.jpg


パーティションサイズをリサイズしたので、新しいパーティションを作ります。

a0056607_12285018.jpg

ここでは Maximum Size としましたが、好みのサイズに指定しても構いません。

a0056607_12300157.jpg
パーティションの利用目的です。オペレーティングシステムや Swap は指定済なので Data and Application を選びます。

a0056607_12303983.jpg
Mount Point "/home" に XFS フィーマットが標準ですが、ハイパーバイザーとして利用したい場合、DBサーバーとして / 以外のパーティション /databaseにしたい場合など、 Mount Point に任意のディレクトリを指定できます。

a0056607_12305798.jpg

これで、パーティション分割のサマリが決まりました。


a0056607_12311930.jpg


元の画面に戻ると、Suggestion とは異なるパーティション構成のサマリが出てきます。

a0056607_12313744.jpg


タイムゾーンの設定です。世界地図から”東京付近”をクリックすると Asia/Japan となります。 "Hardware Clock set to UTC" はハイパーバイザーで利用する場合はチェックを外すのが良いでしょう。どことは言えませんが。バカなゲストOSがハイパーバイザーの UTC のハードウェアクロックを拾ってきて、しっかりUTCで9時間遅れて JST と勘違いして起動することがあります。SUSE ではハードウェアクロックとの同期はあまり推奨していないようなので、このチェックは外します。

なお、UTCは夏時間のない絶対時刻なので、"UTC を使わないと夏時間の変更は困るよ" と言った内容の警告が出ますが、これはそのまま Continue します。


a0056607_12320348.jpg


オペレータのユーザ名(フルネーム)ログイン名、パスワードを設定します。


a0056607_12322222.jpg


root のパスワード設定です。特殊キーをパスワードに使った場合、キーボードの内容と実際の文字コードが一致しているかテストするフィールドがあるので、ここで、キーボードレイアウトを確認します。ちなみに Test Keyboard Layout に入れた文字と、設定したパスワードが一致するかどうかはチェックされません。もちろん root のパスワードの二度打ち内容はチェックされます。

a0056607_12324549.jpg


インストールのデフォルトサマリです。

a0056607_12330103.jpg


"Software" のリンクを開き、 "KVM", "XEN" ハイパーバイザーのみをチェックした場合、インストールされないパッケージをここでチェックします。ハイパーバイザーのツール、ユーザ登録に使う Firefox ブラウザなどを含む gnome 環境、万が一デバイスをソースからインストールするために必要となるコンパイラとカーネルソースなどです。これでコンソールを使わず X サーバーのターミナルから GUI が使えます。


a0056607_12333826.jpg

Firewall は Enable になっているので、Disable に変更します。後に Firewall を設定するのが良いでしょう。 SSH が Enable になっている事を確認します。必要に応じて SSH は後で停止させます。


a0056607_12335410.jpg


systemd のデフォルト起動画面は GUI か Text かを選択します。まず、コンソールのGUIは、まず使いませんから、Text にしておくのが良いでしょう。

a0056607_12341623.jpg


これでインストールサマリが出来ました。 "Install" ボタンからインストールを開始します。

a0056607_12343241.jpg


インストール中です。 Slide Show を見ててもつまらないので Detail タブを開いて、”いまパッケージをインストールしているよぉー”という状態をコーヒータイムにしてぼんやり眺めます。

a0056607_12345144.jpg


インストール中にトイレに行っていたら勝手にリブートして起動していました。

a0056607_12350810.jpg


# startx からGUI のスクリーンを見てみましょう。これは YaST の virt-manager から、VMの作成を選んだところです。ずいぶん種類が増えています。

a0056607_12352716.jpg


なんと、Virt-Manager から、新規VMの作成を選ぶと Windows 1.0 なんというものも出てきます。SUSE ではサポートしているのは NetWare 6.5 だけですが、 NetWare 4/5 のテンプレートも存在します。もっとも KVM で動いたOSと SUSE がサポート対象としているOSは異なることを承知してください。
http://manual.geeko.cpon.org/ja/cha.kvm.requires.html
http://www.linux-kvm.org/page/Guest_Support_Status

yast2 の中から Language を選び、第二外国語で "Japanese" をチェックして、日本語フォントをインストールします。


a0056607_12354702.jpg
SLES12 はたっぷり付き合って、ちょっとなぁーというところがあり、インストール後の手作業が多かったのですが、 SLES12sp2 では、事前にホスト名を決めて DHCP ではなく、最初から固定IPを設定できる点など、ずいぶんこなれたところがいい所です。また、 virt-manager のインターフェースが変わったので、virt-manager から、VMの管理を行う場合はちょっと慣れが必要でしょう。



SUSE SLES Sles12 KVM インストール手順


[PR]
# by islandcenter | 2017-04-06 14:32 | SUSE | Trackback | Comments(0)

この記事は書き換える可能性があります。

2016/10 より、Windows Update のポリシーが変わったせいでしょうか、急に WSUS の容量が爆発的にふえてしまったのです。

WSUSを長年運用していると、

1) インストール済のパッチの拒否
2) クリーンアップウィザード
3) WSUS 自身のアップデート
4) 同期
5) 世間のパッチの不具合の話題をチェックしてインストールの承認
6) パッチのダウンロードと配信

という流れが出来てきます。これで毎月運用していれば WSUS の使用ディスク容量なんて20Gから30G程度で落ち着いてくれます。

ところが、ある日、クリーンアップウィザードを実施しても、全然キャッシュが消えないという不思議な現象に出くわしました。WSUS ピンチです。40G確保したD:ドライブを dd コマンドで4Gほど増やしてみて(当然仮想化運用です)も、キャッシュドライブは、大泉洋が作るスパゲッティみたいに膨れ上がる一方です。
a0056607_10515734.jpg
ということで、WSUS の空き容量を緊急に確保する緊急手段です。

Windows Update Service > 「オプション」 > 「更新ファイルと更新言語」を開きます。


a0056607_13493085.jpg
更新ファイルをローカルに保存せず Microsoft Update からインストール」をチェックして「適用」します。

a0056607_13495876.jpg
これで、キャッシュされたアップデートが削除が指示されるので、(その間「OK」ボタンがグレーアウトします。5分待ってください)その後、クリーンアップウィザードを使って、キャッシュのクリーンアップを行います。

空き容量が増えたら「更新ファイルをローカルに保存する」のチェックを入れてOKボタンを押します。次のパッチ配信から、ローカルネットワークにキャッシュされます。

ギリギリだった容量が一挙に回復しました。

a0056607_13502123.jpg
Windows は 2016/10 より、パッチのリリース方法が変わりました。
2016 年 10 月からのロールアップ リリースに伴う WSUS 運用の注意点
これで、WSUS のキャッシュが「ふえるワカメ」になるという記述はありませんが、 WSUS の運用方法に影響が出ることは予測していました。やっぱり、運用は変わりますね。

-ただ今40Gbダウンロード中-

どこまで増えるんだ? 4G のOSパッチがその10倍もあるなんて .....! という事でこの話はまだ続きます。
やっと終わった40Gb、Windows 7, 10/ 10amv Upadte の三つのパッチだけで、本体の3倍のパッチ。これえ40Gbってどういう事よ。

-ダウンロードの取り消しと拒否-

それでもダウンロードが止まらない。という事で、「ダウンロードの取り消し」をやってみました。「全ての更新プログラム」の中で「タイトル」の左にある白の「!」アイコンを押して、ソートして、配信しなければならないパッチのみ黄色の「!」マークをリストします。

配布が不要な無印の更新プログラムの残骸が「拒否、未インストール」でゴッソリ残っています。

この黄色の「!」マーク以外の拒否したリストをShift キーを押しながら選択(やっちゃった後の「キャプチャ」なんでね....)、右ボタンから「ダウンロードの取り消し」「拒否」を行います。(下の図では!マークを選んでいますが...)
a0056607_11414788.jpg
その後、クリーンアップウィザードでディスクをクリーンアップすると、見事にダウンロードの嵐が止み、ディスク容量も回復することが出来ました。

Windows10 のKB3197356には気を付けろ。Edge のパッチだけで 700Mb あるぞ、という事らしいです。このパッチが配布された後は、小康状態です。
良かったみたいです。

isLandcenter.jp



-Keyword-

WSUS 3.0 ディスクが満杯 アップデートの削除 ディスクの節約 容量不足 空き容量 














[PR]
# by islandcenter | 2016-10-17 17:20 | プライベートクラウド | Trackback | Comments(0)