私はほとんど無意識にですが、

「ユーザIDは8文字以内の英数字にすべし」

というのが暗黙の考え方としてありました。

--
実際、海外の数万人規模の巨大企業でも、単一のディレクトリサービスでその様な ユーザアカウントの Naming Standard (命名規則) で運用している所をよく見ました。近年は、ユーザIDもパスワードも管理方法が複雑で、そのポリシーも複雑で統一性がないのでID管理に複雑な機能が要求されます。

- UNIX系 OS の場合 -

UNIX 系 OS のネーミングスタンダードでは、POSIX 準拠した場合、ユーザ ID は 9 バイトで、お尻の1バイトは NULL 文字で、実質8バイト、というのがヘッダファイルのソースでは宣言されており、一応それが「暗黙の決まり」となっているようです。

limits.h

{_POSIX_LOGIN_NAME_MAX}
The size of the storage required for a login name, in bytes (including the terminating null).
Value: 9

一応の決まりですが実際には、今のディストリビューションやメーカー独自の UNIX 系システムは、独自拡張されており、現在、販売もしくは配布されている多くの Linux ディストリビューションや Unix 系 OS では多くの場合 32 バイトです。ただし、 UID とユーザ名を関連付けるライブラリにバグがあったりすると、表示上 8文字以上のユーザ名が UID に化けてしまうと言った問題もでてきます。

アカウントと連動するアプリケーション側が、古い標準に従って8文字に制限している場合もあるので

「システム的には管理運用上ユーザアカウント名は8文字以内」が無難

であると考えます。

ps doesn't display usernames > 8 characters

ちなみに MySQL は 16 バイトでハードコードされているようで、デフォルトでは、ホストのユーザアカウントを参照するのですが、ユーザ名とパスワード自体が別に管理されているので、システムにログインしなくても使えるわけです。

6.3.1 ユーザー名とパスワード


- Windows の場合 -

Windows (2000/XP) のユーザアカウント文字数の最大長は20文字でした。

ユーザーアカウントとログオンパスワードの最大文字数について(Windows(R)2000/XP)

Windows10 に関しては情報がみつかりませんでしたが、Windows7 も20文字なので、恐らく最大20文字の制限は引きずっているでしょう。AD の場合も20バイトの様です。

Windows 10でユーザーアカウント名に使用できる文字の制限について


それにしても CON とか LPT とかの文字列が使えないってのもなんだか笑わせられます。こんな制限は、DOS 時代を知らない、若い方々には訳が分からないでしょう。俗にいう「CONCONバグ」 の残骸です。こんな制限は古いシステムでも、最新のシステムにも制限があるのですね。

特殊文字はハイフンやアンダースコアは OK の様です。文字間にドットが入っても問題ない様です。カンマは不可。

ちなみに、マイクロソフトアカウントでユーザ作成した際の文字数が5文字を超えると、\Users\xxxxx のユーザフォルダ名は5文字にトランケート(丸めて短くされる)されます。そのため、5文字を超えるユーザアカウントのホームフォルダに何かアプリケーションでアクションを行う場合、ユーザアカウントを参照するソフトウェアが5文字を超えると「色々と楽しくて痛ましい事故?」が起こるようです。例えば

robocopy c:\users\%login_name\*.* \\nas\backup

などとバックアップ用のバッチファイルを書いてユーザに配布すると失敗する訳です。困ったものです。

User folder name truncated

[Windows 10] ユーザー フォルダーの名前が Microsoft アカウントのアドレスの最初の 5 文字になっているのですが、なぜなのか分かりません。



- メールアドレス -

メールアドレスは、ドメイン名も含めた最大長 256 文字、@以前の、いわゆるローカルアカウント部分は最大64文字です。これに@以下のドメインを含めて最大 256 文字という事です。
ローカルなアカウントの部分はドット、ハイフン、アンダースコアは利用可、ただし一番先頭と末尾、連続する事はできません。RFCでは他の特殊文字も使える様ですが、契約先のISPや携帯メールとか、レンタルしたメールサーバー、メーラー(クライアント側)の制限により、その限りではありません。もっと制限がかかっている場合があります。

https://ja.wikipedia.org/wiki/メールアドレス

一般的なマルチユーザのシステム単体(Unix だの VAX だの)では、ローカルホスト内でメールが使えればよかったので「ログイン名=メールアドレス」です。今時はホスト外にメールを送るのが当然です。エイリアスを使っているので、ほとんど問題にはならないでしょう。管理上面倒と言えば面倒です。

- NetIQ eDirectory/LDAP の場合 -

ちなみに NetIQ eDirectory の CN (Common Name : UserID) は64 バイトまで許容しています。と言うより AD や Notes の認証のために LDAP 自体が x.500 の標準として 64 バイトに制限されているようで、eDirectory そのもの自体に制限は無いようです。


しかし、NetIQ のドキュメントではスタンダードな命名規則の事例として、8バイトの英数小文字と ”-” ( ハイフン ) を推奨しています。万物共用の命名規則として通用するわけです。

そこで eDirectory や LDAP でユーザアカウントを管理して、長いオブジェクト名や特殊文字を使用すると、マルチベンダーシステムで Windows や Linux のログインや動作で問題が起こります。LDAP との互換性のため、特殊文字にドットは使えません。ドットは、 eDirectory のコンテナ区切り文字です。特殊文字はハイフンだけ許可されます。LDAP サーチする場合は CN にカンマや@が入っているとURLと間違えられ問題があるからでしょう。

Sample Standards Document#

Tip: Valid Characters in eDirectory

GroupWise はデフォルトで eDirectory の CN (common name) がメールアドレスのローカル部分になります。

- という事で -

また、Unix 系システムであれば、大文字小文字はケースセンシティブなので、アカウント名に大文字小文字を混在させるのは好ましいものではありません。Windows 系システムではケースセンシティブではありません。

レガシーなホストコンピュータなどのプリケーションの一部では、やっぱり8バイトが最長ユーザアカウントというケースもあり、

どうも「ユーザアカウント長、文字制限は8文字以内の英数小文字とハイフン

というのが ID 管理を一般化した場合、一番確実なユーザ名を決めるネーミングスタンダード(命名規則)構築方法でしょう。

セキュリティ上、ユーザ名もパスワード同様に長ければ良いというご意見もありそうですが、、まずアカウント名を解析してからのパスワード解析はクラックするにはちょっと実際の現実感がありません。手元にアカウントリストとハッシュ化されたパスワードリストがあってこそクラックし甲斐があるでしょう。


- 文字数を8文字以内にする法則 -

- アカウントの長さは6~7文字の英数字 -

後に述べる「同姓同名問題」を解決させるため、8文字目は丸めて最大7文字とします。8文字使う場合は特例とします。もちろん、ユーザ名が"津・浦子"さんの場合 "tsuu" と短くなるのは構わないとは思いますが、必要に応じて文字を追加して6文字以上(tsuurrk)にする、と言った方法も良いと思います。8文字以上のIDを要求する場合、長ければトランケートして8文字に抑え、短すぎる場合、規則に従った文字列を加えると良いでしょう。

もちろん2バイト文字や特殊記号の利用は厳禁、特別に許されても”-”ハイフン位にしておきます。ただ ”-” 文字も検索のスクリプト条件で使われる可能性があるため、好ましいとは言えないという意見もあります。


- ファミリーネーム+ファーストネームイニシャル -

大規模な組織では、エンドユーザは相手のファーストネームを知らない事がほとんどです。したがって、ファミリーネームに識別子としてファーストネームのイニシャルを添付します。ファーストネームのイニシャルを1文字加えて「同姓異名」を区別します。

よく、イニシャル+ファミリーネームを使うところがありますが、本人や周囲の人には暗黙の了解ですが、初めて会ったあなたにメールで返事を書きたいと言った場合、ファーストネームを思い出せる人は少ないものです。ファミリーネームを優先的に使った方が良いでしょう。

- 同姓異名、同姓同名の区別 -

同姓同名、同姓異名で、ファーストネーム+イニシャルがダブる場合、後で追加するユーザは、ファミリーネームを一文字削除して、イニシャルの次の子音を一文字加えるのが一つのアイディアです。

Nakajima Kenji : nakajik
Nakajima Kensaku : nakajkn
Nakajima Kenichi : nakajkc
Nakajima Kenji(2): nakaknj

という感じです。

- 回避できない場合は8文字目を数値にする -

Nakakjik と nakajik2 ですね。これで例外があっても8文字に収まります。

- 表記はヘボン式 -

普段あまり意識しないのですが、日本語のユーザ名をローマ字化するための方法として、ヘボン式ローマ字と訓令式(日本式)ローマ字の二種類があります。一般的にパスポートなどの人名表記はヘボン式を基本としているので、ヘボン式に統一すべきでしょう。

ヘボン式ローマ字

東京都生活文化局 - ヘボン式ローマ字綴方表

- 使ってはいけない文字(列)がある -

一般的にOSでファイル名として利用できない特殊記号や文字列、システム間で互換性のない文字(列)などは、or 条件の最大公倍数で禁忌とすべきです。

Unix 系OSでは "0","/" などが禁忌文字ですし、mac の場合は "/" だけ。":"や "|" とか "<>" もパイプに相当するためやめた方がいい。おそらく "Null" などの特殊なデバイスを意味するユーザIDもやめるべきでしょう。 Windows 系OSでは前述したように、特殊文字と "CON" とか "LPT1" とかのファイル名は使えません。ユーザアカウントはバッチやシェルで処理する場合もあるので、これらの全システムで禁忌文字は最大公約数として、使用してはいけないと思います。モノによっては "-" も文字列一括変換などのプログラムやシェル、バッチ処理で問題になるようです。たしかに「特殊文字が使えるシェルの書き方」というのがありますが、メンドクサイので禁忌文字とした方が無難でしょう。

また、当たり前ですが機種依存文字(○付数字やカッコつきの「株」「〒」)とかを含め、「ソ」「申」「表」などのシステム依存のいわゆる「5C文字」を含む。

つまりはすべての漢字を含め2バイトの文字は使うべきではありません

正しい日本語処理を行わないと想定外の動作をするアプリケーションやシェル、バッチファイルがあり得ます。
「英数小文字6~8バイト以内」とするのが && 条件で絞り込んだ最小公約数として命名規則に加えるべきです。

- 重要なのは文書化しておく事 -

忘れてならない事は、このような運用ルールを文書化し、担当課長のハンコを貰って、オーソライズしてもらう事です。後任者が誤って8文字以上のユーザアカウントを作ってトラブルって、後で仕様変更するような目にあっても、それはルールを超えた例外処理として余分な出費を認めてもらう十分なりゆうになるからです。

--
とまぁ、書いてみた訳ですが、実際に古くから運用しているディレクトリサービスで暗黙に8文字運用している現場で、たまたま9文字のユーザアカウントを作ってみると、システム全体に影響がでる現行システムの古い仕様上の互換性との問題点というのが見つかりました。新規登録のルーキーユーザなので、8文字に短くして問題が解決しています。

NetIQ の eDirectory を使ったID管理システム自体が、&& 条件で最小公倍数の 「8 文字英数子文字」をネーミングスタンダードのサンプルにしているので、どのシステムアカウントもこの文字数に従う事が無難です。

もっともこう言った問題点は社内システムでは問題になりますが、今時 google のアカウントを8バイトで確保するのは難しいので、一般的なインターネットサービスではあまり問題にならないかも知れません。ただウェブサービスの一部では、やはり文字数の制限がある訳でして、最低限8文字以上が必須だったりしますし。”8文字”(以下)が無難だ、というのはどこでもあり得る話なのです。

ログインIDが短いと、セキュリティ上問題があるんじゃないかとも思われますが、IDもパスワードもブランクで不明なアカウントをブルーフォートアタックかける場合、組み合わせは事実上無限なので、総当たり戦ではあまり関係ない、と思うのは私だけでしょうか。

ユーザのログインIDの文字数を調べてみると色々なことが解って勉強になりました。最低の「短過ぎるユーザIDは何文字が許されるか」も併せて調べるともっと面白いかも知れません。





[PR]
by islandcenter | 2018-10-08 16:42 | Identity Management | Trackback | Comments(0)

今回は openSUSE と有償版の SUSE Linux Enterprise (SLE) とどこが違うの? という良くある疑問に対して、あくまでも個人的な主観で感じる違いを書いてみます。

- openSUSE は無償, SUSE Enterprise Linux (SLES/SLED) は有償 -

SUSE Linux は openSUSE Leap 15 と SUSE Linux Enterprise(SLE) のコアが共通化されましたが、チューニングは微妙に異なります。 SLE も SLE Server (SLES) と SLE Desktop (SLED) が共通パッケージ化されたため、 SLES/SLED と言う表現より、今後は SLE (SUSE Linux Enterprise) と呼ぶのが適切でしょう。

一番分かりやすい違いが、有償か無償かの違いです。SLE が有償なのは、サポートの有無、パッチ提供の有無もありますが、かつて Novell と SCO の同じ株主の兄弟企業の喧嘩のように、Linux は一部の UNIX と異なりオープンソース、フリーだとは言え、知的財産権の侵害がありパテントトロール企業により訴訟を起こされる可能性があるのでは、という危機感が顧客側にあります。何しろ、欧米での裁判費用は日本とは二けた違います。有償 SUSE Enterprise Linux には、プロプラエタリな有償パッケージや、オープンソースの部分にも有償の知的財産が含まれているようです。知財侵害の訴訟からオープンソースを利用する顧客を守る責任を果たすためにも有償であるわけです。

一方、openSUSE は基本的にSLE からオープンソースのパッケージだけを取り出して作成されたディストリビューションと言えます。無償とは言え、オープンソースやフリーウェアの中に誤って知的財産侵害があった場合、もし訴えられたらその責任は全て、利用者が訴訟費用などを負担しなければなりません。

漠とした法的なリスクを利用者が抱えるか、ベンダーが抱えるかの違いがあるわけです。


- SUSE Linux Enterprise をサブスクリプションが切れた状態で使う? -

SLE はアカウント登録をするだけで無償で電子メディアのダウンロードができます。2018 年の今でも SUSE のカスタマセンターにユーザ登録すると、電子メディアを入手して無償で利用する事はできてしまいます。

SUSE Linux アカウントの取得から評価版のダウンロードまで

ただし、サブスクリプションを登録していないでインストールすると、インストールDVD以外のリポジトリは利用できません。最新のリポジトリを利用するには、最低限60日間有効の評価版サブスクリプション登録が必要です。

アクティベーションコードの有効化について

以前はサブスクリプションポリシーのFAQの中に

「サブスクリプションの購読を止めてしまってから再びサブスクリプションの購読を行った場合、何等かのペナルティはあるのか」

という質問に対して

「サブスクリプションの購読の中断期間のペナルティは要求しない」

との回答がありました。この理由として、 SUSE では、オープンソースの精神にコミットしており、オープンソースに対して、自己責任でソースコードにパッチを当てたり改変する事は基本的に自由なのだから、自分のリスクで勝手に変更するのは問題ない。

ただし、ウチとしてはサブスクリプションの価値を理解して継続して購読してくれるなら喜んでお手伝いできるよ、という内容でした。このページは現在は削除されています。具体的なサブスクリプションのよくある質問が記載されたページは、セールスと法務担当者が理解できるもの以外は無いようです。

実際問題として、サブスクリプションの継続を促す請求は、英文メールで来たりするわけで、誤って見過ごしてしまっても、特に督促されることはないので、そのまま使ってしまっているケースは SUSE に限らず、他のディストリビューションの利用客でも良くあると思います。最近流行りのクラウドサービスと違って、サブスクリプションが切れると、起動すらできないと言ったこともなく使えてしまうのも事実です。

もっとも、サブスクリプションが切れた間のセキュリティや特許に関するリスクはすべて顧客が責任を持つことになりますので、読み流すべき事ではありません。多くのオープンソースを利用するユーザが、陥りやすいエラーなので、キチンとサブスクリプション購読継続の処理をすべきでしょう。パッチを当てる必要があるとか、サーバーをアップデートする必要があるとかとはまた別問題です。

また、世間によくあるオペレーティングシステム(俗にWindows とかいう奴)のように一つでも脆弱性があるとパニックになったようにパッチを当てまくるシステムとは違って、Unix 系OSは明確に利用しているサービスに脆弱性がない限り、運用者が脆弱性のあるパッケージ以外、サービスに影響がなければパッチを当てたがらない傾向にあります。これもサブスクリプションの購読継続がなかなか浸透しない理由の一つかなと思います。

尤も、イントラの軽目的の利用ならそれでも構わないかな、と思いますが、インターネットにむき出しになっているサービスの場合は、キチンとサブスクリプションを継続購読して YOU (YaST Online Update) すべきでしょう。

openSUSE Leap と SUSE Linux Enterprise の一番のコンセプトの違いはサブスクリプションにより、すべての面で顧客が保護されるかどうかの違いがあります。

- 一番の違いはインストーラ -

openSUSE Leap 15 と SUSE Linux Enterprise 15 の実感する差は、インストーラとインストールメディアにあります。 一面一層DVD1枚で収まる openSUSE Leap 15 と比べて SLE 15 は SLES(Server) SLED(Desktop) 他、HA運用のための全てのバリエーションを含め、全部で 20Gb近い容量があります。

openSUSE Leap 15 Install

SUSE Linux Enterprise 15 (SLE15) のインストール

インストーラの構成や手順が違うのも仕方ありませんね。

SLEの場合、サブスクリプション登録からインストールが始まるので、購入したリポジトリからインストールされますが、openSUSE の場合はオフラインでもDVDインストールができる様です。もっとも SLE もオフラインインストールができますが、前提としては正しいリポジトリからインストールしてね、という事になります。

- ミニマムで万能なメルセデスのAクラスと満貫飾りのSクラス -

openSUSE Leap 15 と SLE 15 を隔てるちょっと分かりづらい違いの一つとして、精度の違いが一桁違うほどの安心感、安定感の違いがあります。メルセデスのAクラスでスーパーに買い物へ行くなら小回りが利く openSUSE でもいいけれど、アウトバーンを250Kmでかっ飛ばすならやっぱりSクラス、 SUSE Enterprise Linux に乗りたいよね、という違いでしょうか。

このあたりの安定感は、ルート 66をゆったり55 mph でしか実力を出せないダッジのスーパーチャージャ付き HEMI V8 の様に、海外事情を考慮しないアメリカ製ディストリビューションや、渋滞している高速道路と名のついた駐車場をまったり利用する国産ディストリビューションとの違いがあります。

間違えても、誰も SAP HANA を openSUSE で運用しようという事は考えないでしょう。大量のトランザクションを瞬時に処理する金融機関向けシステムなど、SUSE Linux Enterprise の独壇場です。汎用性が高い openSUSE に対して、専門性が強い SUSE Linux Enterprise と言った差があります。

しかし、ちょっと試したい、古いPCで動かしたい。カジュアルに使いたいという簡易な目的であれば、openSUSE は良い選択です。

また、openSUSE と SLE のコアの共通化が行われているので、openSUSEの開発環境から、SLE への移行も敷居が低くなった様です。

- サポートの違い -

SLE のサブスクリプションを購入すると、リポジトリからのパッチのダウンロード以外にビジネスアワーの標準テクニカルサポートと、ビジネスアワー+α、4時間対応のプレミアムサポートがあります。以前は。パッチだけのサブスクリプション(年間4万円程度)がありましたが、残念ながら廃止されてしまいました。ビジネスアワーと言っても、JSTなのか本家のドイツ時間なのか、米国のサポート拠点、ユタ州プロボのアメリカ山岳時間なのか、サポート言語の記述もありません。SLE のライブパッチングに関してはプレミアムサポート必須なのですが、日本語のライブパッチングをサポートできるの高度なエンジニアが、朝から24時間交代で対応できるとはおもえません。JSTで電話で問い合わせて拒否られて米国山岳時間帯まで待って電話して応答というのは聞きたくないですよね。

さて、問題は、テクニカルサポートの問題なのですが、よくある出荷版の初期不良など、低品質な私のブログ程度でしか日本語で解説した記事がありません。SLE はせいぜいマニュアルが日本語化されている程度の日本語サポートです。役に立たない日本語サポートを頼りにするくらいなら openSUSE のフォーラムや SUSE 本家の Knowlege Base の方がよほど役に立ちます。

今までは日本で Novell K.K. SUSE事業部が SUSE のテクニカルサポートを行ってきたのですが、Novell とは株主が変わって SUSE は Micro Focus からスピンアウトしたので、SUSE 事業部もスピンアウトしても、これ以上サポートが充実するという事は期待したいのですが、考えにくいところです。

もちろん openSUSE は有償サポートはありません。その点、SLE も openSUSE も「自分で情報を集めて何とかしろ」のサポートポリシーは大して変わりません。つくづく、テクニカルサポートなしの、「パッチだけアクティベーション4万円」がなくなったのが残念です。


- 専門化するSLEと汎用化する openSUSE -

SUSE Linux Enterprise 15 (SLES15/SLED15) は単一のパッケージから必要なバリエーション、パッケージをインストールする方式です。逆にSCC(SUSE Customer Center)に登録されたサブスクリプションに応じていないバリエーションはリポジトリからインストールできません。

一方、openSUSE は単一のバリエーションしか存在しません。

つまり SLE 15 は SUSE Linux の単一のメディアセットのパッケージ全てがデパートの様に各種のサービスを提供します。openSUSE はその一部分を切り出したオープンソースのみで構成されたディストリビューションです。openSUSE には SAP application も SUSE HAもありません。SLES と SLED の一部分を選別したディストリビューションです。

よく RedHatEL と Fedora の違いだ、と言われる SLE と openSUSE の違いなのですが、システムコアが同一になったため、openSUSE は Fedra ほど尖ったところがない。むしろ RedHat を元にしたクローンに近い存在になったとも言えるでしょう。openSUSE Tumbleweed が Fedora に相当しそうです。

- 個人ユーザ向けの openSUSE 法人向けの SUSE Enterprise -

名前のままと言えばそのままですが、企業や法人向けには openSUSE はお勧めできません。テクニカルサポートはじめ、サブスクリプションによる保護がないためです。しかし、安定した周辺機器の認識能力の高さから、openSUSE は一般ユーザのデスクトップ向けには、人気が高いディストリビューションです。

完全にデスクトップ向けの SUSE Enterprise Linux Desktop の人気を奪っています。 また、組織内部でも、比較的軽度な部門用 Web サービスや DNS/DHCP と言った軽度で枯れた単発サービスには軽量な openSUSE は向いていると思います。一方電子メールやエンタープライズ向けアプリケーション、仮想ハイパーバイザーと言ったサービスには、SUSE Enterprise Linux Server (SLES)を選ぶべきでしょう。これらの一部は openSUSE では動作しない場合がありえます。

SLE Server (SLES) はリモートコンソールでの使い勝手はいいのですが、openSUSE はリモートで管理運用しようとすると、時折、隔靴掻痒な使い勝手の悪さを感じます。そういう点も、openSUSE がコンソール志向、パーソナル向けな利用が多いのかなと思います。

- openSUSE と SUSE Linux Enterprise どちらが使いやすいか -

多分に好みの問題ですが、サーバー運用するには、細かいところで SLE Server (SLES) が使いやすいと思います。あくまでも好みと慣れの問題ですが、コンソールを外して SSH でリモート利用するときのトラブルの少なさは SLE の方が好きですね。

openSUSE は、どこかに落ちていた古いPCに、ベアメタルで入れて日本語環境で使う分には必要充分で使いやすいディスとリビューションだと思います。どこかに落ちていたような古いPCが手元にないので私は openSUSE や SLED のデスクトップ日本語環境を使う機会がありません。openSUSE は SSH で管理するようなサーバー向けにはちょっと向かないというか、なんか違うなぁ、コンソールが欲しいなぁという感じがあります。その代わり KDE でも gnome でもコンソールでデスクトップを使うには良い選択だと思います。あくまでも個人的な感想です。空いているPCがないので SLE Desktop(SLED) は一度しか利用したことがありません。SUSE が Novell 傘下にあったころは色々面白い仕掛けがあったようですが、SLE Desktop 15 にはあまりそういったトピックスが無いようです。


SUSE Linux 15, openSUSE 15 Leap, 違い, インストール, Install, 無料


[PR]
by islandcenter | 2018-09-11 13:32 | SUSE | Trackback | Comments(0)

コントロールパネルが消えた Windows 1709 Windows10 がモバイルOSへともがき続ける日々

1706 Creators Update から、異常にアクセスしにくくなった、Windows のコントロールパネル、まぁ、デスクトップの”テーマ”
の"デスクトップアイコンの設定"をひらけば、デスクトップにアイコンがでてきますが、思わず God モードなんか作りたくなる。

a0056607_11094758.jpg


ご存知 God モードは GodMode.{ED7BA470-8E54-465E-825C-99712043E01C というフォルダをつくれば、ほぼコントロールパネルでできる事が大体できるようになるので便利なのですが、コントロールパネルを隠す方向に進んでいるところに Windows10 の未完成な進化の方向性を感じさせてくれます。


a0056607_11100988.jpg


- PDAサイズとして諦めた Windows, タブレットとしての復権は? -

既報の通り Windows Mobile は、どうやら、"ディスコン (Discontinue)" となりそうだし、PDAサイズのWindows スマートフォン化は先が亡くなりました。Windows タブレット専用機も GPSなしの 10 インチクラスが主流で、それも通信機能は Wifi だけ、つまり携帯とのテザリングなどをしないと使えないし、激安中華タブレットではGPSも付いていない。"歩きスマホ" で地図で現在地を確認しながらウロウロする目的には合致せず、公園やレストランのような、固定した環境で使うしかない。でも Instagram は写真のアップには使えない。どうしても GPS付き LTE モデルを買うとなると、重量級のサイズとPCそのものの価格でなければ使えない、もちろん歩きタブレットではキーボードも使えない。タブレットでは Android と iPad が完全に地位を確立していて、Windows10 の出番はない。そもそも5インチクラスで "Office のドキュメントが読み書きできる" 事に99%のユーザにとっては重要なニーズはないのですね。

大体、モバイルOSと言っても、 Instgram の Windows 版では、カメラが付いているデバイスでも写真のアップもできない所に、今の "Windows10 の置かれた立場" というものが端的にあらわれています。Windows Store を開けば、トップページはゲームと天気予報アプリばかり。他にもありそうでも全然ないのが Windows アプリの今の立場なのです。

だから、ますます Widows10 アプリは増えない。という事で Windows10 はやっぱり ”パソコンOS” であり、PC用アプリケーション以のストアアプリはマインスィーパー位しか使い物にならないのですね。

それに、Windows10用アプリは、わざわざ全画面で表示する必要のないものばかり、メールを読みながらカレンダーでスケジュールを調整できないのは致命的ですね。無視して Windows Live 使えよ、Google カレンダーと Evernote を使っていて、Windows Live 何それ、な使わない人には、ウマに説教。豚に真珠。となると、一般ユーザはますます”パソコン”とPDAサイズのスマートフォンの二丁拳銃、現代のサムライビジネスマンナなら、大小二刀が向いている。2台持ちには WindowsPCと Windows タブレットは、大口径ライフルと自動サブマシンガンを持たされた空挺隊員みたいに、無駄に重いので、PCとスマートフォンという、自動ライフル小銃と自衛用35口径拳銃の二丁持ちでしょうね。

かと言ってタブレットサイズで、老眼鏡が必要なスタイラスでの操作なんかしたくないし。タブレットは、ディジタル生産ツールではなく、ディジタルコンシューマツールなのです。ディジタル生産性ツールには最低でも 2 in 1 タブレットは必要。それでもケツを座るべきところに落ち着けて、二―トップの設置場所は確保する必要があります。

Windowsのソフトウェア開発者は、やはり Java だとか CSS、 Visual xx のような従来のUIで開発したがるだろうし、ストアアプリの開発者は、1に iOS, 2 に Android, 3,4がなくて、5 に Windows も手が回ればな、って程度でしょう。

こんなトレンドの中で、必死に Windows10 は"パソコン" というデバイスで、タブレット、スマートフォンのUIに近づけようと、”進化” という名の無駄な"あがき", "劣化"、"悪化" を続けているわけです。Windows のコントロールパネルは、たぶん、圧倒的に使いやすかった。これから、コントロールパネル一つを開けば、大体の設定ができたものが、徐々に、各機能に分散される方向にあるため、「この設定変えたいんだけどどうすればいいのか」と、ユーザは困惑するばかりなのですね。

Windows10 が本当に使えるOSになる日はくるのでしょうか。Windows10 が最後の Windows である以上、その日は、Windows が亡くなる日になるでしょう。それまで Windows は永遠に "劣化" し続けるのでしょう。









[PR]
by islandcenter | 2017-10-29 11:10 | Windows | Trackback | Comments(4)

モバイルファースト(働き方改革時代)の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)

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

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

- XEN の Domain_U のカーネルを弄ってまで、他のハイパーバイザーに移行させたくない(これ結構大きい)
- BSD 系 Uinux や 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)

このブログで「如何にして 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)


どうも世の中、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 を通じて必要な設定を行う事ができるため、手元に「コマンドリファレンス」の様なアンチョコ本を頼りに、正確な綴りのコマンドラインを操作する必要はありません。

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

YaST でパッケージのインストール

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

- SUSE Linux のパッケージ -

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

というか、YaST では、インストールされたパッケージのデータベースを管理しているため、パッケージバージョンや設定ファイルの不整合を避けるため、基本的には "YaST でパッケージをインストール・管理すべし" という事になります。もっとも、ソース配布されているアプリケーションの場合は仕方がないのですが.... YaST パッケージにあるアプリケーションは、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章 インターネットからのパッケージのインストール

SUSE Linux 15 YaSTの基本 (openSUSE Leap, SLE)

ユーザアカウント名は8文字以内にすべきか?ユーザの命名規則の理由と対策

計画停電時の対策 SUSE (SLES11, SLES12,15) XEN/KVM 遮断マニュアル

サブスクリプション購入はこちら








-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)