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