isLandcenter 非番中

ブログトップ | ログイン

タグ:Windows ( 69 ) タグの人気記事

202x 年 Windows 最期の日

※ あくまでフィクションです....

『米国 Microsoft 社は 202x 年 x月 x日 、Windows10 の今後の開発スケジュールとサポートについて、Windows の開発は終了し、202z 年 z 月末をもって、セキュリティパッチなどのサポートも終了することを発表した。あわせてWindows 関連の従業員3万人の解雇と、 付随した Windows 関連の他社への売却も含めた分社化を検討している事も発表した』

Windows の「最期の日」が発表されたのだ。

202x 年 Windows 最期の日_a0056607_12254843.png

Microsoft Windows は 1985 年に発表され、ごく初期のバージョンは全く注目されなかった。1991 年に発表された Windows 3.1 は成功をおさめ、1995 年に発表された Winsoqa 95 は大ヒットした。その後、Internet Exploroer が Windows に標準搭載されると、「インターネットに繋がる全てのデバイスは Windows」と言われるようになった。

202x 年 Windows 最期の日_a0056607_11453879.png

その後、Windows は DOS ベースのカーネルから、Windows NT のカーネルに移行し、 2001 年に発表された Windows XP でその頂点を迎えた。

しかし、Windows Vista の失敗、登場が早すぎたタッチパネル風の Windows 8 の失敗の後、「最後の Windows」 と言われた Windows 10 が 2014年の登場でひとまず盛り返したものの、再びその勢いをITビジネスで取り戻すことはなかった。

Windows の最大のライバルは、他のPC用システムソフトウェアではなく、言うまでもなく、スマートフォンや低価格タブレットなど、異なるプラットフォームの普及である。

Instagram の様に、Windows 用アプリケーションはあっても投稿の機能がないなど、既に、ネットサービスの主流は、Windows ではなく、スマートフォン、タブレット向けサービスに移行しており、Windows は天井桟敷に居場所を見つけていた。

Windows 8 の MetoroUI は一般的な PC ユーザにとって「早すぎた登場」であった。が、デジタルコンシューマにとっては魅力がなかった。また Windows 10 ベースの Windows Mobile の失敗と撤退、すなわち Symbian も Nokia の買収も含めてスマートフォンビジネス上の買収戦略の失敗も致命的だった。「タッチパネル風」を謳った Windows 10 S Edition も、一定の操作で通常の Windows として使えるなど、中途半端に終わった。Microsoft の Windows マーケティング部門は Windows RT の失敗を忘れていた。

デザインはタッチパネル風であっても、ほとんどのモバイル PC のディスプレイがタッチ対応していなかった事に Microsoft Windows のチームメンバーは誰も気が付かなかった。

さらに、Windows 10 をモバイル化して、十分なパフォーマンスを出すためには、最低でも Intel Core i5 以上、メモリ8Gb、128Gb のストレージが必要だった。この仕様を満たすには、最低でも10万円程度の出費が求められ、他社の低価格タブレット端末の倍以上の費用がかかったことが 「Windows 10 は果たして出費に見合うか」という疑問が、IT マネージャや、ネットを駆使することに慣れてしまった消費者離れを呼んだ。PC メーカーも Celeron などの低価格の CPU と 32Gb のストレージを搭載したタブレットやクラムシェル PC をラインアップに加えたが、32Gb のストレージでできる事はブラウザでテキストページを読む程度の事しかできず、動画視聴どころか Windows Update すらできないケースが多かった。

キーボードのない Surface RT の CM を見て惹かれた消費者はいても、使い慣れたアプリケーションと本当に毎日の生活には使えないアプリしかない高価なタブレットであることを知ると、Surface RT には誰も見向きをしなかった。

更に 2020 年、世界を震撼させた「コロナ禍」が、 Windows 10 の将来に暗い影を投げかけた。多くのオフィスワーカーのみならず、子供の教育からパートタイマーの主婦の副業まで、オンライン化を要求された。この惨禍の時期、どこの家庭でも 「家族全員の Windows10 を快適に動かす環境」の出費はあり得ず、多くの消費者の興味は、他の低価格なプラットフォームのタブレット環境へと移った。

Windows10 の目玉の一つであるオンラインストレージの OneDrive も、Google や Apple, Dropbox などの強力なライバルの後塵を浴びた。

コロナ禍の最中、Windows10 で一番問題となったのは、重く、しかも頻繁に行われた 「Windows Update の問題」が挙げられる。Windows Update はあまりに頻繁に行われ、かつ仕事やオンライン授業を中断するための時間がかかり、インターネットに大量のパケットを要求した。「PCとインターネット接続サービスへのパケット代の投資は Windows Update の為にある」という奇妙な囁きが、消費者同士の SNSで拡散された。

あまりに Windows Update の重さと、通信コストの高さ、時間のかかりすぎに呆れたモバイルワーカーやオンライン授業を受ける子供たちは、時間がかかりイライラするアップデートの間に低価格の Chrome OS や Android タブレットで、Youtube を見たり、 Twitter のサービスで時間をつぶしていたのである。そして消費者は学んだのである。「Windowsは使えない」と。

「午後からは天気が良くてベランダで PC の Wifi のスィッチを入れたらいきなりアップデートが始まったのよ。おかげで日が沈むまで、何も仕事ができなかった。iPad でオンライン会議には参加できたけど、結局その日は Windows Updateで何もできなかったの。何のための PC なの? iOSなら10分で終わるのに...」

「アップデートが終わるまで3時間待ったけど、何度も再起動した最後に『元に戻しています....』って? 頭に来たわ!」

「コロナ禍で分かったのは、Apple Store や Google Play には大抵、銀行振り込みから毎日の資源ごみ回収まで、日常の生活で使えるアプリケーションがあった。なのに Microsoft Store には人込みを避けるためのリモートで使える大手銀行の振り込みのアプリケーションすらなかった事だ。これには驚いた。Windows10では、銀行の残高を調べるだけでも、スマートフォンが必要なのだ。 Android タブレットがあればいい。手元の Microsoft Store には、ゲームとニュースと天気予報のアプリしか使えるものはないからね」

「水曜の午前中にコンピューターの電源入れてアップデートが始まったら、ラッキーぃって思っちゃう。おかげで、一日仕事さぼってタブレットでSNSチェック。マネージャの顔見て『あ、あいつも始まったな』って気が付いちゃうし。5時半に『お先にぃ』って言っても誰も文句言えない雰囲気だなってミンナ解ってるンだ」

「パソコン? 一応あるよ、普段使わないけど、プリンタと一緒にクローゼットに仕舞ってる。5年くらい前の機種かな。年賀状印刷の時に便利だよね。親戚でも遠いところだったり、付き合いの薄い親戚や世話になった先生には紙の年賀状送るし。後は スマホから SNSで『あけおめ!』で終わりでっしょ、普通...」








最大のライバル Apple は手ごろな価格の iPhone SE や、iPad の低価格版を販売し、モバイル、テレワーカー、教育関係者から大きな支持を得ていた。これらは、軽量で低価格でも快適に作業ができた。

かつて "Wintel" と呼ばれた Windows の最大のパートナーであったインテルは、既に Windows プラットフォームに見切りを付けて、高収益が得られるサーバー用プロセッサの販売に力を入れている。一方で、汎用PC用環境では成長の余地がある Linux デスクトップ関連の企業や、Android のx86 化での Google との提携、Apple のハイエンド Mac への協力など、他のプラットフォームへの積極的な投資や支援を始めている。ただ Intel の x86 ビジネスがサーバー向けにしか将来性を感じない。 Intel は先手を打って、英 ARM 社との技術提携を表明している。

ただ、これらの いわゆる "GAFa" 企業も、プロセッサやサーバーハードウェアを自社開発しているので、Intel にとっては浮かれている相手ではない。

一方で PC を開発、販売するハードウェアベンダーにとっては、薄利多売でも PC が売れればよいのであり、上に Windows が載っていようといまいと関係ないと、しばらくは静観するだろう。CPUは別に intel x86 でも ARM64 でも構わない。タブレットやクラムシェルPCで、Android が動こうが、ChromeOS が動こうが、台数が掃ければよいのだが、ハイエンドの高額なPCの売れ行きに影響するうまい汁は吸えなくなるところが出てくるだろう。

さて、Windows をスピンアウトさせるマイクロソフトにとって Windows10 は何を意味するのだろう。一言でいえば、既に「Windows は莫大に金がかかるだけで卵を産まない老いた雌鶏」である。Windows10 には、様々なメジャーアップデートバージョンが存在していたが、既に消費者にとって全てメジャーアップグレードは無料だ。

かつては Windows のメジャーアップデートがある度に「有償のアップデート版」が存在していたが、Windows10 より「アップデートバージョン」の開発コストに対して、膨大な数の利用者への見合わないセキュリティパッチや互換性の検証が発生するだけだった。

また、21 世紀の Microsoft にとって最大の収益源は、Microsoft Azure と Office 356 のサブスクリプション収入である。Microsoft は .Net 開発環境の mono xamarinをや GitHub を買収し、Windows Azure を Microsoft Azure と名称を変更し、一般コンシューマーが気が付かない分野では、既に堂々たるオープンソース企業である。また、Office 356 も、Linux や Android 、iOS などの他のプラットフォームに移植されて、サブスクリプション購買も順調だ。ただ、長年のプロプラエタリの宿敵のライバルだった Microsoft がオープンソースエンジニアの『心を買う』事ができるかどうかは未知数だ。

Microsoft は、「ユーザは Windows を使いたいのではない。アプリケーションなのだ」

という、創業時の発想に戻ろうとしている。Microsoft が Windows をスピンアウトさせる日がいよいよやってくる。ユーザにも見放された Windows10 , その最期の日はやってくる。

※ あくまでフィクションです....







タグ:
by islandcenter | 2020-06-05 12:14 | 雑文 | Comments(0)

- はじめに -

MovaXterm で Mac の VNC 接続を始めたら、やめられなくてもう一度、 vncserver の事を、復習してみます。

参考ドキュメント

8 VNCによるリモートアクセス
https://documentation.suse.com/ja-jp/sles/15-SP1/html/SLES-all/cha-vnc.html



- vncserver のインストール -

tigervnc がインストールされているか。YaST > Software Manegement で確認して、なければチェックしてインストールします。

SUSE Linux 15 (openSUSE Leap 15)の vncserver,VNC接続をする。_a0056607_13282884.png


opensuse151:~ # vncserver --help

usage: vncserver [:<number>] [-name <desktop-name>] [-depth <depth>]
[-geometry <width>x<height>]
[-pixelformat rgbNNN|bgrNNN]
[-fp <font-path>]
[-fg]
[-autokill]
[-noxstartup]
[-xstartup <file>]
<Xvnc-options>...

vncserver -kill <X-display>

vncserver -list



上の SLE15 のマニュアルにはこんな簡単な説明がありました。

手順 8.2: vncserverを使用した永続的VNCセッションの開始 REPORT DOCUMENTATION BUG#

1. シェルを開き、VNCセッションを所有するユーザとしてログインしていることを確認します。

2. VNCセッションで使用されるネットワークインタフェースがファイアウォールで保護されている場合は、ファイアウォール内でセッションによって使用されるポートを手動で開く必要があります。複数のセッションを開始する場合は、一連のポートを開くことができます。ファイアウォールの設定方法の詳細については、Chapter 16, Masquerading and Firewallsを参照してください。
vncserverは、ディスプレイ:1にはポート5901、ディスプレイ:2にはポート5902という順序でポートを使用します。永続的セッションの場合、VNCディスプレイとXディスプレイは、通常、同じ番号です。

3. 1024x768ピクセルの解像度と16ビットの色数でセッションを開始するには、次のコマンドを入力します。

vncserver -alwaysshared -geometry 1024x768 -depth 16

vncserverコマンドは、何も指定されない場合、未使用のディスプレイ番号を選択し、その選択内容を出力します。追加オプションについては、man 1 vncserverを参照してください。



opensuse151:~ # vncserver :0

You will require a password to access your desktops.

Password:12345678
Verify:12345678
Would you like to enter a view-only password (y/n)? n

New 'opensuse151:0 (root)' desktop is opensuse151:0

Creating default startup script /root/.vnc/xstartup
Creating default config /root/.vnc/config
Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/opensuse151:0.log

opensuse151:~ #


※ desktop is opensuse151:0":0" に注意

- 仮想ホストの制限 -

※ 因みに SLES11, 以降の XEN/KVN の仮想 HVM を使っている場合、 lib-virt が使っているので vncserver :0 などの低いディスプレー番号は使えないようです。二桁以上のディスプレイ番号を使うと上手く動きました。

あるいは、単にディスプレー番号を指定せず vncserver .... を実行すると、最初に空きがある番号に自動的に割り当てられます。


sle15:~ # vncserver :10 <-- 怒られた
A VNC server is already running as :10
sle15:~ # vncserver :11 <-- 11 番は使えた

New 'corsair:11 (knakaj)' desktop is corsair:11

Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/corsair:11.log

sle15:~ #
sle15:~ # vncserver <-- 番号を指定しないで単純起動

New 'corsair:6 (root)' desktop is corsair:6 <-- :6 が割り当てられた

Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/corsair:6.log

sle15:~ #



- MobaXtermにより接続 -

MobaXterm
https://mobaxterm.mobatek.net

Session > VNC (必要に応じて "network settings" タブで SSH gateway 経由をチェック) で VNC 接続できました。

SUSE Linux 15 (openSUSE Leap 15)の vncserver,VNC接続をする。_a0056607_13290893.png

接続を切ります。

opensuse151:~ # ps ax | grep vnc*
14306 pts/0 Sl 0:01 /usr/bin/Xvnc :0 -auth /root/.Xauthority -desktop opensuse151:0 (root) -fp /usr/share/fonts/misc,/usr/share/fonts/75dpi,/usr/share/fonts/100dpi,/usr/share/fonts/Type1 -geometry 1024x768 -pn -rfbauth /root/.vn /passwd -rfbport 5900 -rfbwait 30000
15198 pts/0 S+ 0:00 grep --color=auto vnc*
opensuse151:~ #
opensuse151:~ # vncserver -kill :0
Killing Xvnc process ID 14306
opensuse151:~ #



- MacOS から VNC 接続 -

Finder > 移動 > サーバーに接続 > URL に

vnc://IP_Address:590n

(n は vncserver を立ち上げた時に指定した :0 のディスプレイ番号のパラメータ)

SUSE Linux 15 (openSUSE Leap 15)の vncserver,VNC接続をする。_a0056607_13333603.png


- セキュリティ -

- デフォルトポートの変更

デフォルトでは 5900 番台のポートが使われるので、いたずら対策にこのポートを変えておく事です。

/usr/bin/vncserver スクリプトの

$vncPort = 5900 + $displayNumber;


の行を任意の違うポートに変えておくと良い。

SUSE Linux 15 (openSUSE Leap 15)の vncserver,VNC接続をする。_a0056607_13365237.png


あるいは "vncserver :1000" の様に、一桁多いディスプレイ番号を割り当てる。

- ファイアウォール

ファイアウォールはポート 5900 から開けておくこと。勿論、 vncserver のポートを変えた場合ほそのポートを開ける事になります。

- パスワード

接続するパスワードは vncpasswd コマンドで変更され。 ~: .vnc に保管される。もし動作が妖しければ、このディレクトリの中を削除すればリセットされる。vnc パスワードは最長8バイトであり脆弱である事に注意します。頻繁に変えるか、使う予定がなければ vncserver を立ち上げっぱなしにしない事をお勧めします。(そういう時に使いたくなるんですけど....)


opensuse151:~/.vnc # vncpasswd
Password:
Verify:
Would you like to enter a view-only password (y/n)? n
opensuse151:~/.vnc # ls -l
total 64
-rw-r--r-- 1 root root 332 Feb 27 14:56 config
-rw------- 1 root root 8 Feb 28 13:24 passwd
-rwxr-xr-x 1 root root 639 Feb 27 14:56 xstartup
-rw-r--r-- 1 root root 34652 Feb 28 11:12 opensuse151:0.log
-rw-r--r-- 1 root root 6 Feb 28 11:09 opensuse151:0.pid
-rw-r--r-- 1 root root 8788 Feb 27 18:10 opensuse151:1.log


- 暗号化

vnc プロトコルは、telnet 同様、暗号化されない平文通信なので、デリケートなケースでは安易に使わない事。 SSH によるポート転送との組み合わせを勧めます。少なくとも MovaXterm には VNC 接続の中に SSH ゲートウェイの設定があるのは単純にすごい。

Mac の ”画面共有” は暗号化されないので注意。SSH トンネリングする方法があるので "mac vnc ssh トンネル" などで検索してください。


- まとめ -

一つしかないモニタに複数のホストを扱う事は、システム管理にとっては便利な機能です。しかし、vncserver を改めて研究してみると、そこには大きな脆弱性や欠陥が見えてきました。便利な反面、セキュリティホールでもあるんですね。

今回は Windows の RDP については説明はしませんが、やっぱり RDP 接続も脆弱性があるので、何だかなぁ、という気分です。事業所内のプライベートネットワークであればまだしも、「働き方改革」なんかで、自宅からリモート接続したい、などの要求は高まるばかり。利便さと脆弱性との両立って難しいのです。

ますますインフラ系の技術者にとっては厳しい要求があるのですね。









by islandcenter | 2020-02-29 13:30 | SUSE | Comments(0)

狭い机の上に、モニタ何台も置けないよ、という事で、Windows から、Mac をリモートデスクトップの様に接続して使う方法です。

あまり使わない Mac mini が、ほとんど iTunes マシンとなっているのですが、ライブラリを切り替えるのが面倒くさくて、つい同じライブラリを聞き続けています。

ライブラリ切り替える度にキーボード引っ張り出して、モニタをHDMIに切り換えて、ってやっていたのですが面倒です。Mac の画面キャプチャも、撮っては、NASに保存して、GIMP で加工してって面倒だし、いい方法がないかと考えていました。

という事で、MovaXterm を使って VNC 画面転送をしします。

- Mac 側の設定 -

Mac 側は「システム環境設定」から「共有」の画面共有を有効にします。

また、Mac 側の IP は固定するか、事前に ifconfig で、IP アドレスを調べておく必要があります。 ip a コマンドじゃないのね...

Windows から Mac へ MobaXterm で VNC デスクトップ共有接続_a0056607_11045223.png

「画面共有」を有効にするユーザに「アクセスを許可」させて、VNC接続するパスワードをセットします。

Windows から Mac へ MobaXterm で VNC デスクトップ共有接続_a0056607_11052356.png


         


- Windows側の操作 -

mobaXterm はこちらからダウンロードしてインストールします。

openSUSE のアプリケーションをWindows からGUI操作する。MobaXterm

mobaXterm がを起動したら、"Session" を開き、"VNC" 接続します。その時、Mac 側の「画面共有」パスワードをセットすると VNC 接続ができます。

- ちょっと感動した -

どーんと Mac のデスクトップが Windows 側の MobaXterm のウィンドウ内にフルサイズで表示されます。サイズの変更も簡単だし "Fullscreen" 表示にも切り替えられます。

Windows から Mac へ MobaXterm で VNC デスクトップ共有接続_a0056607_11055366.png

Dock が四角いのは、ご愛敬ですが、iTunes の操作程度では、何のストレスも感じません。iMovie とか Quick Time とかはさすがに VNC では無理がありますが、ちょっとした操作であれば、「大体使える」レベルです。

こらなら、普段使いは Windows のヒトでも、「Mac もたまには使う」ヒトにとっては作業スペースの節約にもなります。勿論、Macのための SSH のテキストターミナルも使えます。

普段、SUSE Linux を操作するために MobaXterm を使って Linux のための X サーバー(端末)、 SSH ターミナル便利だなと思って使っていました。色々ひっくり返して突きまわると、こんなに強力、多機能だったとは気が付きませんでした。すまぬ MobaXterm よ。これなら Pro 版買ってもいいくらいです。もうWSLもいらないくらいです。







by islandcenter | 2020-02-26 11:44 | MacOS | Comments(0)

ファイル名とファイルパスの最大長について。

Samba にファイルを保存しようとしたら、「ファイル名が長すぎる」と怒られたので、ファイルサーバーで保存するファイル名の長さ、トータルのパスの長さを調べてみました。
ここでは Samba だけではなく、Windowsや macOS のファイル名、パスの長さ制限についても調べました。


- SUSE Linux(openSUSE Leap 15.1)-

SUSE に限らず多くの Linux ディストリビューションや UNIX 系では getconf コマンドで NAME_MAX を調べてみると良いでしょう。 255 バイトで、最後の一文字は NULL なので、実質 254 バイトになるはずです。誤っていたらコメントください。これは posix 準拠のためなんでしょうね。

sle15:~ # getconf -a | grep NAME
NAME_MAX                           255
_POSIX_NAME_MAX                    255
LOGNAME_MAX                        256
TTY_NAME_MAX                       32
TZNAME_MAX
_POSIX_TZNAME_MAX
CHARCLASS_NAME_MAX                 2048
HOST_NAME_MAX                      64
LOGIN_NAME_MAX                     256
sle15:~ #

IBM の資料ですが、getconf の詳細はこちらをご参考ください。
getconf — 構成値を取得する

Samba や NAS などでは 255 「バイト」、Windows では260「文字」。長いファイル名は Samba では使えないわけです。

長いファイル名を扱うことができない

ただし、これは「ファイル名の制限」で、limits.h によるとパスも含める 4096 バイトの様です。これはファイルシステムフォーマットの問題ではなくシステムAPIによる制限です。


最大パスサイズは「バイト」で日本語でパスを作成する場合、UTF8 では3~4バイト使うため、「日本語の文字数」に注意が必要です。

opensuse151:~ # cat /usr/include/linux/limits.h | grep PATH
#define PATH_MAX        4096    /* # chars in a path name including nul */

opensuse151:~ # getconf -a |grep PATH
PATH_MAX                           4096
_POSIX_PATH_MAX                    4096
PATH                               /bin:/usr/bin
CS_PATH                            /bin:/usr/bin
opensuse151:~ #


実際にプログラムを書いて試したヒトがいました。中々面白いプログラムです。

Check File Systems maximum path depth

Now run it:
$ time ./createDirectories

return code     : -1
Created sub-directories : 1018
length of pathname  : 4096

real    0m0.281s
user    0m0.004s
sys 0m0.180s


私の openSESE Leap 15.1 の環境では若干違いがありました。

opensuse151:~/test # ./ptest
return code             : -1
Created sub-directories : 1022
length of pathname      : 4098

1023 バイト説もありますが、その根拠が分かりませんでした。コメントいただけると幸いです。

- Novell NSS はパスも含めて 1023の Unicode 文字 - 

ファイルサーバー専用OSの Novell Open Enterprise Server (OES)では、ファイル名そのものは16ビット Unicode で 255 文字、フルパスは 1023 文字です。

6.4 Naming NSS Storage Objects

6.4.2 Number of Characters Allowed
For the NSS file system, the maximum length supported for a filename (the name and file extension) is 255 16-bit Unicode characters. The maximum length supported for the full path name (which includes the volume name, directories, filename, extension, and delimiters in the path) is 1023 16-bit Unicode characters.

However, different tools, applications, and file systems place different limits on filenames and path lengths, some of which can be more or less restrictive than these limits.

16bit Unicode でパスも含めて 1023 文字です。もっとも、それだけの長さを扱えるソフトウェアやアプリケーションがあるとは限らないのでマウントしたシステムによる、という事です。標準的なシステムより、長いパスを作ってマルチベンダー対応、という事なのですが、良くある話でマルチベンダー固有のトラブルも抱えます。

なお、上の記事は、OES2018 のNSSなので OES2 以前のバージョンや NetWare カーネルでは 255 文字という記述もありました。多分ファイル名だけの制限でしょう。

- Windows NTFS -

NTFS の概要

拡張パスのサポート: 多くの Windows API 関数には、MAX_PATH 設定で定義された 260 文字のパスの上限を超える約 32,767 文字の拡張パスを許可する Unicode バージョンがあります。
 
最大 32,767 文字が MAX_PATH 変数によって 260 文字(パスも含む)に制限されています。この数値は Win32 の制限によるもので、グループポリシーで変更できます。

> gpedit > コンピュータの構成 > 管理用テンプレート > システム > ファイルシステムに "Win32の長いパスを有効にする" を有効にして > gpupdate を実行します。

ファイル名とパスの最大長の色々_a0056607_13581623.png

例えば、サーバー上の "D:\(フルパス含めて全部で260文字).txt" をネットワーク共有で "\\server\my-long-share\(共有名を含めると260文字超えちゃった).txt" でアクセスする場合などにはこの制限を撤廃すべきでしょうか。やはり「255文字前後が一般的な壁」なので、濫用は要注意です。

バックアップからのリカバリなどでも、このファイル名の長さ制限でリストアできないファイルがある場合も考えられます。
Windows Server -> Samba でバックアップエラーが起こるとややこしい事になりそうですね。 

Linux側では、4096(NULL含) のパスの長さなので、 Unix 系OSや macOS とファイル共有すると、ファイル名の長さで Windows からアクセスできないケースも出てくるわけです。

- MacOS HFS+ -

Wikipedia によると

最大ファイル名長
255文字(UTF-16での文字数。Appleが改変したUnicode正規化形式Dに正規化される)
https://ja.wikipedia.org/wiki/HFS_Plus

残念ながら、パスを含んだ最大の数字は見つからなかった...ので getconf してみました。 

etesian-mini:etc uhoge$ uname -a
Darwin etesian-mini.local 19.0.0 Darwin Kernel Version 19.0.0: Thu Oct 17 16:17:15 PDT 2019; root:xnu-6153.41.3~29/RELEASE_X86_64 x86_64
etesian-mini:etc uhoge$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.15.1
BuildVersion: 19B88
etesian-mini:etc uhoge$ getconf NAME_MAX /
255
etesian-mini:etc uhoge$ getconf PATH_MAX /
1024
etesian-mini:etc uhoge$

ファイル名とパスの最大長の色々_a0056607_12410148.png

どうも macOS X 10.15.1 では、ファイル名の長さは 255(NULLを除いて254)バイト、最大パスは 1024 ということになりそうです。

古いHFSの場合は31文字です。また、AFP を使う時も 31 文字のよう。








- まとめ -

色々調べてわかったのは....

- 大体のシステムでは2020 年現在 255 文字前後のUTF16、またはバイトが、ファイル、ディレクトリ名で使える
- バイトの場合と UTF16 の場合がある。
- Unix 系システムでは、ディレクトリパスも含めて、4095(+null) で 全部で4096バイトのようだ
- Unix 系システムで Samba を使う場合、長いパスは Windows からアクセスできない場合がある。
- ただし OS が扱うファイル名の文字コードが UTF16 であるとは限らない。最近は大抵 UTF8 だったりする
- Windows10 系は 260 文字だが、「初期の Windows は 254" バイト"」だったりでバージョンによってはバラバラ。
- Windows10 系のパスの長さ制限は「拡張パス」という秘密の扉を開けると32,767 文字まで使える
- システムが使う文字コードが Shift-JIS だったり、Unicode だったり、UTF-8 だったり EUC だったりするとどうなるか不明
- 日本語コードに慣れたプログラマとはトモダチにになっておくべきだ。
- バイト数と UTF16、UTF8、の「文字数」とは違う事をエンドユーザに説明するのはインド人にウナギを食わせるくらい難しい
- 特に文字数とバイト数の違いに注意。chars が、いわゆる char 変数なのか、文字通りの「非アルファベット」の複数バイトの文字数(letter数)なのか
- 職場を辞めたヤツが、Mac からファイルサーバーの日本語フォルダの深さをチャレンジ、しかも読み込み専用のフラグを立てて退職したことを思い出した。頭にきた。
- 長くて深いディレクトリ名、ファイル名をユーザは使わないで欲しい。ってか、よくそんな面倒なことするなよ。
- ファイルシステムに制限がなくても(no limit) OS の API 制限に引っかかることが多い。Windows のエクスプローラは「アプリケーション」である。
- アプリケーションからアクセスできないファイルは夜作られる。
- ファイル名とパスの長さは、誰か Wikipedia に記事を書いてまとめて欲しいくらい、面倒である。





他にも文字コードの違いや機種依存文字、使えない記号符号特殊文字などもあります。これはまた別の機会に調べてみます。





by islandcenter | 2020-02-24 14:12 | SUSE | Comments(0)

IT運用系の技術者としてショッキングな事件がありました。


日経の記事によると

神奈川県、行政情報に大量流出懸念 廃棄機器転売され

"県のサーバーを更新した際、取り外されたHDの廃棄を委託された事業者の社員がデータ消去の不十分な状態で一部を持ち出し、ネットオークションで販売した。データ量は最大54テラバイトに上る可能性があるという。"

まず総データ量は54Tbであること

"出品されたHD18個の半数は県が回収したが9個は未回収という。"

ここで鯖屋が考えるのは、

全部で18個の半分回収済み、半分の9個行方不明、合計18個、ここに 54Tbなら 54Tb/18玉=3TbのHDD

という計算になる訳です。18個の3TbのHDD。

朝日のこの記事では

「なんだこれは…」と絶句 HDD落札男性が見た中身

恐らく、ディスク1個をPCにつなげて、データ復旧したら、やばいデータがぞろぞろ出てきたわけですね。
で、私は思うのですよ。

「SAS Raidじゃないな」

ここで3Tbの18玉という数字を想像して、あ、これなら日時バックアップ+週次に使えば大体ひと月分のウィークデーのバックアップに相当するわけです。普通Raid が壊れると、まず私程度の一般的なスキルの持ち主では修復できません。それに SASなら、一般的なPCでは動かないし、高価なHBAアダプタが必要だし。Raid HBA が変わると Raid はまず再構成が始まります。もうこの時点でほぼ復旧できません。Raidの玉一個だけなら、「バラバラ殺人事件」の体の一部です。全体は復旧できない。

2019年の今ならわかるけど、たぶんサーバベンダー製3TbのSAS HDD なんて、あっても高価だし、おそらく数年前の導入時にはかなり希少だと思います。中古品でも、サポート切れHWの修理用として高価に取引されます
ただし、Raid が壊れた場合、私のようなパンピーな技術者や「愉快犯」程度では無理でも、その筋の「玉筋金太郎」のような、専門家ならゴルゴ13並みに不可能ではありません。Linux+XFSの様なセキュリティが強そうファイルシステムならまだしも、Windows+NTFS だと「なんちゃってエンジニア」でも簡単に使えるフリーソフトはたくさんありますからね。

怖いのはクラウドサービスを使っていて、使い終わった後のデータ処理ポリシーがブラックボックス。データ消去が顧客側のポリシーでコントロールできません。oneDrive なんて使って、オフィスデータをごっちょりため込んでいる運用者にとっては悪夢ですね。

私も経験ありますが、 Raid が壊れたケースでは、 Raid が壊れて完全データ復旧まで、玉筋金太郎に頼んで海外の提供先に出して二か月かかったそうです。メチャマイナーなNSSファイルシステムで、復旧にはン百Gbで、費用はン百万単位。でもすごいものですが、いるんですね。そんな玉筋金太郎な技術者って。

空中分解したスペースシャトルから地上にたたきつけられたハードディスクのデータを復元

Novell Storage Service

恐らくサーバーのシステム構成は、普通に SAS Raid6とかで、オークションで流れたのは、日時バックアップ用の外付けSATA HDDで、実データは3Tb程度+差分18個なのかもしれません。

ま、ここまでは推測ですけど...
--

- 顧客としてやるべき事 -

今回の事件は、神奈川県庁が被害者のように見られそうですが、一番の被害者は納税者であり、個人情報が危険にさらされている神奈川県民なのですね。

多くの企業でサーバを固定資産にせず、経費処理しています。リース会社に返却する場合は、データの抹消はリース元に安易に任せず、ユーザ自身が責任をもってすべきなのです。

でもHDDはリース品なので、無傷で欠品なくリース会社に返却しなければならないわけです。とは言っても中のファイルとソフトウェア資産を残したまま返却するわけにはいかないので、利用するユーザ側としてはできる範囲で、データのシュレッドを行うべきだった、という事です。

データの完全消去

一般的にはアメリカ国防省がスタンダードとしている

1. 乱数書き込み3回
2. 最後に Null 書き


が一般的だと言われます。本来ならLinux のライブUSBで起動して

1. # dd if=/dev/urandom of=/dev/sda
2. # dd if=/dev/urandom of=/dev/sda
3. # dd if=/dev/urandom of=/dev/sda
4. # dd if=/dev/zero of=/dev/sda

を実行するわけです。今回の場合、27玉の HDD に全てにすべきだったのでしょう。ランダム書きは恐ろしく時間がかかるのですが、これを顧客側でやっておけ、という事です。たぶんひと玉当たり一日仕事です。全部でひと月かかるでしょう。


時間がなければ、デバイスの Null 書きだけでもすべきです。これなら数時間で終わります。ここまででもやっておけば、よっぽどその筋の玉筋金太郎でなければ、まず復旧できないのです。

openSUSE Leap 15.1 の Live USB で「初めてのどこでも Linux」の作り方

そんな面倒な事やってられないよ、と言われそうですが、データ消去にかかる費用もシステム移行にかかるコストとして計算すべきだったのかもしれません。




逆に今一番信用できる業界は普通の「PCリサイクル業者なのかもしれません。

何しろこういったインシデントがあった後は、業界自体が体制の見直しだとか、廃棄ルールの徹底をチェックしますからね。ひょっとしたら今が狙い時かも知れませんが、謳っている広告と実際の作業内容の乖離が大きかった事は、業界のダメージでしょう。

いわば「IT業界の最下流」である、データ破棄業者が信用できなければ、たとえ上流のデータセンターの厳しいセキュリティチェックがある、入退室管理システムも信用できない。クラウド次第の激震、クラウド契約終了後の、残ったデータの破棄はどうするのか。おそらく契約書にはなにも書かれていない。

何しろ持ち込み禁止の「入退室管理ができている隔離された部屋から、リュックに詰め込んだHDDが運び出された」わけです。同じことが、iDCやクラウド運用ビジネスで行われることも「あり得るな」という印象を与えた事は大きな事件です。




BSE騒動直後、品川港南口付近の「焼肉屋」はずいぶん安い価格でうまい肉食わせてもらった覚えがあります。業界が岐路にある時は、真摯に対応してくれるものかもしれません。今、一番信用できるのは他のPC破棄業者かもしれませんね。






by islandcenter | 2019-12-07 16:45 | 雑文 | Comments(0)

- ホスト名は「花鳥風月」 -

数十年前に初めて、お客さんのネットワークシステムを構築したとき

「コンピューター名どうしましょ」

となった時に

「ま、花鳥風月でいいんじゃないっすか?」

と申し上げた事がありました。コンピュータ、ホスト名の命名規則のお話です。

英国軍艦の装甲艦コルベットには「フラワー級コルベット」というのがあり、「立派な海軍の男がパンジー(三色スミレ、男色者の隠語)なんかぁで戦えるか」というくだりが、よく英国の海洋冒険小説に出てきます。でもこの「花の名前」のフラワー級コルベット。使い勝手の悪さと居住性の悪さにも関わらず、構造が簡素で大量生産できたため、大戦中の大西洋でのドイツの潜水艦との地味で退屈で危険な戦いでは大活躍したんです。

※ちなみに英国海軍の場合は、必ず正式名に HMS が付きます。

そこで戦後に初めてアメリカの GM が作った小型スポーツカーにつけられた名前が「コルベット」。

旧日本海軍では軍艦の命名規則は、律令時代の「国名」が戦艦、「河川名」が巡洋艦。空母は「喜ばしい架空の鳥の名前」駆逐艦は「洋上の自然現象」と決まっていたようです。

ま、余談はここまで。「花」はこんなものですが、「鳥」は何だかメンド臭そう。「月」は moon 以外に見つからず、じゃ「風」の名前はどうなんだろうと調べたら、結構、コンパクトで魅力的な風の名前(地方風)の語には蠱惑的な単語が結構あるんですね。

List of local winds

特にヨーロッパ古代から中世史に興味があったので、地中海の船乗りに関する「風の名前」「船乗り用語」「船乗りが嫌がるもの」など地中海の船乗りが使う語彙が豊富になりました。という事で、ウチのコンピュータや Wifi の SSID なんかには、いいも悪いも含めて地中海の船乗りになじみのある自然現象などの名詞が使われています。

ちなみにSSIDの文字列の最大長は32バイトだそうです。そういえば、電車の中でスマートフォンのSSIDを変えて、見知らぬ他人と会話する、という話が一時期話題になったように、2バイト文字も使えますが、お勧めはできません。


WifiのSSIDで隣人とコミュニケーションしよう

軍艦の命名規則には、それぞれお国柄があるようです。特に海軍国である英国艦艇の補助艦には、フラワー級だけではなくリバー級とかタウン級なんて命名規則がありました。アメリカ海軍の場合 USS で始まり、州の名前とか政治家とか、頑張って戦死した二等水兵の名前とか。

ま、そのうち風の名前のセンスに苦しんで、コンピューターのホスト名には北欧の物語に出てくる妖精の名前をかたっぱしから付ける様になりました。英国空軍の機種名やエンジンの名前によく使われています。英国人のセンスですね。名前を見るとユニークでインパクトがあるものをよく見ます。


- あわせて読みたい -

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


- よくある命名規則 -

社内ネットワークが構築され始めたころ、良く客先で見かけた命名規則が「星の名前」や「ギリシャ神話の神」をルールにしているところが多かった。これは単純に使いやすいのと、ゲームの主人公なんかによく使われるんですね。どうも、「天体名」は人気があるそうです。

でもその名前の由来を調べたら、縁起の悪いものもあるので、気を付けたいところです。こういった命名規則を作った趣味人の命名規則。

例えば、片っ端から「ガンダム名」にしてしまうと、

「シャーが死んだ」とか「ザクにバグがある」「ホワイトベースが堕ちた」

なんていう楽しい会話ができます。私にはそんな趣味ありませんけどね。まぁ”ウルトラマンに出てくる怪獣の名前”とか、ま、やめときましょう。最後には倒されるンですから...

フォネティックコードを使うのも一つのアイディアです。短くて誤読、認識性が高い。さすが軍隊の通信に使われるだけあってよく考えてある。

ですが、欠点はアルファベットの26種類しかない事。


明確で単純ですがあまり人気はありません。

自社の製品名、自社のサービス名を使うケースもあるのですが「xxx(自社製品名)が死んでいる」とか「xxxがおかしい」なんて会話が飛び交うと、社内で変な誤解を生んでしまいます。あまり流行らないようですね。

また、プロジェクト名などを付けると、後でそのプロジェクトがポシャって、プロジェクト名が付いたホストが残ると淋しいものです。

また、いくら花鳥風月でも "chrysanthemum" (菊)なんて言うような、舌を噛むような難読名は命名規則には避けるべきでしょう。私なら「薔薇」って書けません。

植物の名前は豊富ですが、微妙な花言葉だと、使う側もビミョーな気持ちになります。でも語彙は豊富です。鶏の名前は英語だとピンときませんね。

List of garden plants

List of birds of Japan

- Mnemonic Word listによる命名規則 -


ここでリストアップされた単語は、アクセントや綴りに重複や読み間違えを生みにくい4~7文字の単語のリストです。1626語ありますから選択は自由です。命名規則に関わらず、任意にコンピュータ名に付けたい時には参考になるリストです。

- ガチガチの命名規則 -

これは、どこの現場でも良く見る命名規則です。通し番号は最低2桁、できれば3桁の通し番号を付けます。この方法のメリットは、 # grep | sort した時に見やすい事です。

例えば

  • PRNnnn - プリンタ
  • WPCnnn - Windows 端末
  • DNSnnn - DNS サーバー
  • APSnnn - アプリケーションサーバ
  • FSVnnn - ファイルサーバー

ただ、これだとユーザや管理者から即時認識できないので、[SRV+nnn+PANSY]の様な、機能+機械的な数字+愛称はいいアイディアだと思います。愛称があると判りやすいし、Nattou とか Umeboshi なんてミヤビな名前があれば愛着も沸くものです。でも、自分のPC名が「鶏レバー」だったら愛着は湧きませんが....

実際、意味のない文字列+数字の場合は担当者はさておき、協力会社の担当者さんやエンドユーザは即座に識別できないので、何等かの愛称があると識別性が高いという事になります。

ホスト名は「記号化」してしまうと、認識度が低くなり、伝達性を損ないミスタイプを誘います。一意にするための"記号+理解可能な単語"の組み合わせが良いだろうと思いますけどね。

まぁ Linux の場合、ホスト名が影響するのは Samba の Netbios 名程度(設定でホスト名とは違う名前を付けられる)で、後は DNS 名ですから、 DNS 名の命名規則と異なる機械的な命名方法でも構わないでしょう。

- PC端末の命名規則 -

「NetBiosの都合」というややこしい制限があるので、それぞれエンドユーザさんが使うPC一台一台には工夫が必要でしょうね。クライアントPCはネットワーク上では、将棋の「歩」です。それぞれの足軽は「姓」を名乗らない「歩」なので「貫太郎」とか「強右衛門」の様なユニークな名前を与得る場合もある訳です。私も自分のコンピュータ名を「タマちゃん」と呼んでいた時期がありました。

英米の海軍でもこれらの「歩」の様な哨戒艇などには PT-109 とか MTBnnn の様な、記号+通し番号が正式名称だったのですが、実部隊の現場ではお互いを「愛称」や「コールサイン」で識別していたようです。

所詮「足軽」なので、端末は3~4年で入れ替わってしまいます。永続的にホスト名やIPアドレスが使われる、DNSやメールサーバーの様に厳密にする必要はありません。

端末のホスト名は、アセット管理とヘルプデスク、ワークグループの使い勝手を優先目的とします。

「PC+導入年度下二けた+シリアル番号(SKU)下4けた+数バイトの認識名」とかも良いでしょうか。

認識名としては、3バイトの空港コードのように短くて聞き間違えがなく認識性が高いものが良いでしょう。「WPC+3桁の通し番号+3桁の空港コード(HND-羽田,CTS-千歳,NRT-成田)」などです。桁が揃った一意の綴り3文字なので、応用が利きそうです。


修理でマザーボードを交換したとか、USBドングルアダプタで有線化した場合はMACアドレスが変わります。IP や MACアドレス、利用者名などを使うと何れ破綻します。

ー 数字は16進数を使う ー

例えば通し番号を数字二けたとすると 00から99 までの 100 個の個体を識別できるわけですが、これを16進数にすれば 00 ~ FF まで二けたで 256 個の個体を識別できます。 256 はクラスCのひとセグメントですから、大体の中小組織では十分な数です。

3桁 000 ~ FFF を使うと全部で 4096 の識別個体を作れます。中堅企業以上では、これで十分ですね。

ただし3桁の先頭文字にアルファベットはつかわないのがいいでしょう。000 ~ 9FF までです。 

- OS、機種、機能、設置部署、場所、企業名は使わない -

OS 種別を命名規則に取り入れると、例えばWindows で動いていたサービスを Linux に置き換えた場合はちょっと面倒なことになります。

また機器のベンダー名や型番を命名規則に使うと機器のリプレースの時に面倒な事になります。

設置したオフィスや部門の所在地を使うと、オフィスが移転したときに問題となります。

nnnn の通し番号に IP アドレスを指定している所がありました。リーズナブルなようで、後でハードウェアのリプレースで問題となります。あまり IP や Mac アドレスをコンピュータのホスト名に使うべきではないと思います。仮想化時代なのでいずれ破綻します。

また、「会社名」も避けるべきです。会社名なんてしょっちゅう変わるものなんですね。Windows ドメイン名に「会社名」を付けてすぐに買収されて、泣く泣くドメインを再構築したお客さんがありました。

- 社内向けドメイン名、アクティブディレクトリ(AD)の命名規則 -

「社内向けドメイン?」何ンか変だな。まぁ Microsoft Active Directory を始めとして、イントラネット向けのドメイン名なんですが、

".local" は禁忌ドメイン名です。絶対に使ってはいけません。間違っても AD では ”mycompany.local” で作ると問題がありそうです。Google 大魔神の投票結果なので、探してみてください。

そもそも、"mycompany" という、アナタの所属する組織名は移ろいやすいのですね。ローカルネットワークで使うFQDNに含まれる、ドメイン名、ホスト名はもう少し真面目に考えてもいいのではないのかなと思います。

例えばですよ、あくまでも例えば。

社内向けのDNSのADのローカルドメイン名に local.google.com なんてオレオレドメイン付けてしまって、prn01.local.google.com に印刷してしまった場合、オレオレじゃない本物の Google さんの prn01.local.google.com から極秘文書がジーコジーコとプリントアウトされる可能性があるのですね。ま、考えにくいけど。

だから、社内向けのドメイン名は、インターネットにおいてユニークで唯一無二で、しかも将来においては他人に使われない、変更される可能性がないドメイン名を指定すべきでしょう。会社名.com なんかはよした方がいい。どうせ会社名なんて、いつCIされて変わってしまうかわからないのです。その後 Windows ドメイン名を変えてしまうのは恐ろしく手間がかかる作業になってしまうでしょう。これは社内ドメインの工夫。アクティブディレクトリの命名規則のポイントですね。

だから、Active Directory のドメイン名に組織名はつかうべきではないと思うのですが、唯一無二という事なら、思い切って”花鳥風月”の一般名で公式な名詞をオレオレなインターネットドメインを取ってしまい、そのサブドメインをイントラネット用ドメイン名にしてしまえば、社名が変わっても将来にわたって使えるわけですね。.NET とか .SITE とかはかなり安く取得できるので、例えば pansy.site なんかを1円で取得して fsv001plum.ad01.pansy.site というドメインやFQDNを AD や社内向けサービスの名称にするというのも思い切った手段です。これなら会社名が変わろうが、組織が改変されたり、引っ越しても使い続けられます。
zzzzzzzz.com みたいな単純なドメインでも格安です。



オレオレドメインがもたらす当たり前な問題


- ドメイン名の命名規則からの HOSTNAME の制限 -

FQDNではゾーン名を含め1バイトから最大253文字です。FQDN は hostname.mydomain.com となりますが、ドットの間の「ラベル」に使われる最大文字数は63文字です。従って、「コンピュータのホスト名」の公約数は

1から63文字以内で、かつFQDNも含めて253文字に収まること」

がまず条件になります。SUSE Linux では getconf コマンドで確認できます。Linux のホスト名は最大で64バイトですが、最後は Null なので63バイトという事です。

suse15:~ # getconf -a | grep HOST
HOST_NAME_MAX 64
suse15:~ #

ラベルに使われる文字は、英数字とハイフン、ただしハイフンは「ラベルの先頭と末尾」には使えません。基本的には使わないのが無難。 Windows では "_"(アンダースコア)も利用可能ですが、他との公約数として"_"も Windows では使わない方が無難でしょう。

この63文字の文字制限は hostname コマンドのマニュアルには記載がないのですが、 limit.h に定義されているそうです。

63文字以内です。

ドメイン名の構成

ただし、いくら 253 文字使えるとは言え、長すぎる FQDN 名は避けるべきでしょう。解りやすく、短くが原則です。そもそも文字列が長いと、タイプミスしやすいし、メンドクサイものです。


重要なのは、命名規則で使える文字種、最大、最小文字数などは、&&条件で最小公約数で決める事です。Windows や Netbios で許されても、FQDN の条件に合わない命名規則は、好ましいことではありません。Windows から、他のシステムに移行した場合に問題となる可能性があります。逆に 63 文字のホスト名が付いたシステムを Windows に移植したら、これも問題が出てきます。



- Windows におけるコンピュータ名の規則 -

Windows におけるコンピュータ名も同じく63文字の様です。

Enter your computer name

ただし15バイト以上の「コンピュータ名」はトランケート(丸められる)ようなので、15バイト以内が無難なようです。

なぜなら、"Netbios" という20世紀に作られたDOS時代のレガシーなシステムの残骸を引きずっていて、 FQDN での制限である63バイトより、短い「Windows は15バイトのコンピュータ名」をつけた方が良い様ですね。

しかもNetbios では特殊文字のドットも可能。

勿論、ドット(ピリオド)はFQDNのラベルの区切りになるので、NetBiosでは許されてもコンピュータ名で使うべきではありません。だからADの命名規則では禁止されているという矛盾。また RFC では "_" (アンダースコア)は積極的に推奨されていないようなので、Windows では認められても使うべきではないようです。
 
Active Directory におけるコンピューター、ドメイン、サイト、および OU の名前付け規則

この Netbios 名の制限は、当然 Linux/Unix 系OSで使われる Samba にも影響しますから、 Linux で SMB/CIFS を使う場合は Linux のホスト名とは別に Netbios 名も英数字 15 バイトに収めるのが無難である、ということになります。もっとも BIND なんかで名前解決するなら問題ありませんが、Windows ガチガチなネットワークの場合、制限は

「NetBiosに従え」

ということになりそうです。


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

大体、コンピュータのホスト名の命名規則というのは、管理している人間の趣味で作られるものです。まぁほとんどはその場の思い付きなんですね。

例えば、先頭6バイトの文字規則(ナンバリング規)+愛称名の利用可能なリスト

命名規則の原則は、文書化と認証。必ず文書化して、担当マネージャーのハンコをもらっておく事です。

- まとめ -

  • grep | sort したり、正規表現での検索、スプレッドシートでソートしやすい様、先頭 4 ~ 6 バイトには特殊記号のない規則性を持たせる
  • 基本は英数字のみ15バイト以内に抑える。もっとも短い方がいいのは勿論。
  • 特殊文字は "-" ハイフン以外使わない、と言うより正規表現で特殊処理が必要な文字なので "-" , ”_” の利用も控える。
  • 後半部には規則性のある任意のニンゲンが認識可能な文字を付け加えても構わないが、長い文字列は避ける。
  • 数字で始まるホスト名は避ける。
  • オフィスのストリート名、部署名、社名など、将来も使い続ける可能性がない略字、語句は使わない。
  • 恥ずかしい名前や、難読性なもの、「そういう面白い趣味か」といった名前は避ける。
  • IP アドレスや Mac アドレスの様な変化する可能性のある命名規則はそのうち破綻する。
  • 愛称のストックは常にためておく事。空港コード、フォネティックコードの様なリストを決めておく。

まぁ、RFC1178 に、べき論べからず論があるので、一読しておくことです。

Choosing a Name for Your Computer

202x 年 Windows 最期の日






by islandcenter | 2019-11-04 13:16 | プライベートクラウド | Comments(0)

Windows Store の終焉:Microsoft に見捨てられた Windows、Surface Duo は Android に

【速報】Microsoft、Androidが動作する2画面スマホ「Surface Duo」

Windows Store の終焉:Microsoft に見捨てられた Surface Duo は Android に_a0056607_11312281.png
PC Watch

どうやら、Microsoft は、単なる携帯電話、スマートフォンのハードウェアサプライになるらしい。

ディスコンになった Windows Phone に代わり、スマートフォンのOSに Android をマイクロソフトは遂に選択した。

これでは、単に中国製のスマートフォンと変わりがない。

どうせハードウェアは中国生産だろうし、ロゴに "Microsoft Surface" とロゴが入った、

「なんちゃって Microsoft スマートフォン」

である。


たとえ、アカウントが Microsoft に紐づいていても、ダウンロードするアプリケーションは、Gmail や Google カレンダーであり、Youtube の視聴ソフトウェアだろう。検索エンジンは Being ではなく Google がデフォルトだろう。

使われるアプリケーションは、Facebook だったり、Twitter や Instgram であり、Linkedin は入っていても真っ先に削除されるアプリだろう。

Windows Store より豊富な Apple Music や Amazon Prime, Amazon の電子ブックビューワ、が利用されるだけで Microsoft Windows Store からのダウンロードして何かアプリを使うことってできるのかな。m、ないだろう。

もう Windows Phone がディスコンになった時点で Windows Store はその役割を終えたのですね。

Surface Duo...... Microsoft に存在する意味ないね。

Windows Store よ、さらば..........


タグ:
by islandcenter | 2019-10-03 11:39 | Windows | Comments(0)

終った技術: Windows 10 S mode

Windows 10 にある不思議なバージョン、Sモード。この技術はもう終わっている。

なんでも、「セキュリティとパフォーマンス」のために Microsoft Store のアプリケーションと Edge + Bing 検索しか使えないモードなんだそうですが、今では

「お前、そんなところで何してるんだ?」

と言う微妙な立ち位置にいるのが Windows S mode なのですね。

そもそも、教育機関向け、企業のタブレット向けに販売を開始したものなのだそうですが、天気予報とゲーム位しか魅力的なアプリしかない、Microsoft Store から、いったい何をダウンロードして使えと言うのでしょう。

大手都市銀行の銀行の振込用アプリさえない。何しろ iOS ならウチの近所の農協の口座だって振込できる時代なのにです。
しかも、S mode から Pro や Home エディションには簡単に切り替えられるという。逆は非なりだそう。



PR




- ことごとく失敗してきたモバイル戦略 -

Windows RT そういやありましたねぇ」と完全に過去完了形。「Windows 10 Mobile ってなくなるんだって?」と現在進行中の既に過去表現。そう、Microsoft のモバイル、あるいはタブレット用システムは、過去に何度も失敗しています。買って後悔した人も多いでしょう。大体ライバルに対してSKUが大きすぎる。重くて電池が持たないのです。ライバルのスマートフォン、タブレットOSが軽いシステムから、重量化したのと違い、もともとの重戦車から、主砲を取り除いたような、意味のない軽量化でフットプリントばかりでかくて、誤魔化した作りなのです。

Windows 10 Mobileのサポート終了、移行先についての身も蓋もないアナウンスが話題に

後継製品のアナウンスもなく iPhone だとか Amdroid に乗り換えろ、って何なんだ。電話帳は引き継げるのか?



だが Windows S mode は「Pro版や Home版に切り替えられる」という「逃げ道」を作っているのが失敗前提の設計のミソなのですよ。

つまり「Windows S Modeは失敗することを前提に設計してるもんね」という「もんね」的な誤魔化しがごっちょり入っているのです。

なぁーに、使えなければ Pro 版に切り換えちゃえばいい、そんな匂いがプンプンしているのが Windows S Mode なんですね。

もう出た時から既に終わった技術なのです。



by islandcenter | 2019-07-01 13:40 | Windows | Comments(0)

Linux は使ってみたいけど、どれを選べばいい? という悩みの中で、openSUSE Leapを初めて使ってみようかという方に、Hyper-V 環境で簡単に構築する手順を説明します。

まずは仮想環境で「やってみて」、「何だか分かってきた」ら、ちょっと古いノートブックだとか、ホワイトボックスのBTOマシンで、本格的なベアメタルPCで自宅サーバーや、 Web LAMP のスキルアップのための自己学習用の開発環境を構築できるようになるでしょう。

自宅サーバーや、小規模なプロジェクトでの開発環境で Linux が必要であれば openSUSE Leap 15.1 は手ごろな一つの選択です。


PR 働き方、減るのは給与増える暇、ドメイン取って副業か? PR

openSUSE が使えるVPS


- SUSE とは -

ドイツの SUSE 社は、米 RedHat が IBM 傘下に入ってしまったため、 2019 年現在、世界最大の独立系のオープンソースソフトウェア企業となりました。

かつては Novell 傘下だったり、Attachemate, Micro Focus などから出資を受けていましたが、現在はヨーロッパ・スウェーデンの投資組合、EQTのまとまった出資を受けた世界最大の独立系 OSS ソフトウェア企業です。SUSE Enterprise は有償 Linux のディストリビューションの中では世界で約 30% 程度のシェアがあるようです。openSUSE Leapは、主力製品、SUSE Linux Enterprise のいわゆるデチューン版のようなものです。

- SUSE Linux -

SUSE Linux という言い方は誤解を呼ぶかも知れません。

SUSE が関連する Linux のディストリビューションには SUSE が後援する openSUSE と呼ばれるシンプルで無償のコミュニティ版と、エンタープライズ向けのバリエーションが豊富な SUSE Linux Enterprise (SLE) と呼ばれる有償版の二つのディストリビューションがあります。

SLEは、SLES(Server)はじめ SLED(Desktop)から、SAP専用、大手クラウド事業者用など、数々のバリエーションに分かれています。

SLE 15 より、openSUSE は SLE のコードを基に、テクニカルサポートやプロプラエタリなパッケージ、エンタープライズ向けのハイエンドな機能を削除して、インストーラをコンパクトに、無償化したディストリビューションが openSUSE です。

  • アウトバーンの国、ドイツ製という事もあり、堅牢性安定性はずば抜けている点。
  • YaST という Linux 知らずの初心者にもベテランにも取っ掛かりの良い設定・管理ツール
  • モバイル環境から一般的なビジネス用途、サーバー用途にも使える高い汎用性

に特徴があります。

また、「比較的新しいハードウェアでも問題なく動く」と割と評判はいいようです。

2019 年5月現在、 openSUSE Leap は 15.1 が最新版です。

SUSE Linux Enterprise は 15.1 がリリースノートで発表されていますが、まだ公式に入手できるのは SLE 15.0 が最新版の様です。

openSUSE には openSUSE Tumbleweed と呼ばれるローリングリリース版と、安定版の Leap の二の種類があります。Tumbleweed は openSUSE/SLE の開発用テスト版の様なもので、初心者には向いていません。初心者がちょっと入門で Linux を触ってみたいのであれば openSUSE Leap 版を使ってください。

わざわざ初めての Linux に、openSUSE Tumbleweed を選んでチャレンジして、Quita なんかで「openSUSE はバグだらけで使い物にならない」とボヤいて諦めるチャレンジャーさんが大勢います。そういう方は、是非バグ情報を openSUSE の開発者向けコミュニティで元気よくボヤいてください。自らソースコードを弄って改良すれば Leap 版にいずれ反映されるでしょう。

初めての openSUSE は openSUSE Leap を選ぶのが定石です。

--
ちなみに SLE (SUSE Linux Enterprise)については、無料アカウント登録すれば、60日間の評価用サブスクリプションコードとインストール用のメディアを入手できます。SUSE 15 より openSUSE Leap 15 --> SLE15 へのアップデートがサポートされました。



ここでは、コンパクトで無料、手軽に利用しやすい、2019/6 現在、最新の openSUSE Leap 15.1 について説明します。


- SUSE の管理は YaST で始まり YaST で終わる -

openSUSE/SLE を特徴づけている機能が YaST(Yet another Setup Tool) です。そもそも openSUSE/SLE のインストーラ自体が YaST の機能の一部です。

初めての Linux, openSUSE Leap を Hyper-V で動かす。_a0056607_15194076.png

ほとんどの Linux の管理を、このツールで行う事ができます。おかげで古本屋で買った時代遅れの Linux/Unix 管理者向けのアンチョコ本とはオサラバできます。

まず、SUSE Linux では、YaST で80%の管理、運用を行えるため、他のディストリビューションの様に、コマンドラインのヘルプや vi エディタと闘う事がありません。ある意味では Linux エンジニアのスキルキラーの様な高度なツールです。

おそらく Windows ユーザが初めて YaST に触れれば、驚くほど、キーボードタイプが少なく、マウス操作だけで多くの作業ができる事に気が付くでしょう。他のディストリビューションから乗り換えてみると、こんなに便利なツールはないのか、と思うはずです。

YaST自体はオープンソースなので、Oracle Linux などでもオプションとして用意されており、互換性がある CentOS の管理者さんが、強引に突っ込んだら「動いた」そうです。海外の Ubuntsu のフォーラムに "Ubuntsu で YaST を動かす方法はないのか" という書き込みも見たことがあります。

SUSE Linux 15 YaSTの基本 (openSUSE Leap, SLE)
https://islandcnt.exblog.jp/238758768/

また、GUIが使えない、貧弱なWANのネットワーク越しでも、同じ機能をメニュー形式で使える CUI 版 yast コマンドもあります。ほとんどの操作を TAB, やカーソルキーで操作できる優れものです。

軽量なので、ちょっとした変更をしたい場合によく使います。

初めての Linux, openSUSE Leap を Hyper-V で動かす。_a0056607_15270644.png

Windows は知っているけど、初めてだけど、少しは Linux も知っておきたいという程度からの、入門者には実に便利で「使えるツール」です。


- openSUSE Leap インストール ISO のダウンロード -

openSUSE Leap 15.1

ダウンロードリンクには、DVDの ISO イメージ版と、ネットワークインストール用の二つのメディアがあります。ネットワークインストール版は、最新のパッケージがインストールされる事。ダウンロードサイズが小さい事がメリットですが、インストールがオンラインで行われるので、私の環境の様にインターネット回線が弱い場合、インストールに却って時間がかかったり、途中で止まってしまい、やり直す事も良くあります。

ネットワーク版は、私は使ったことがありません。
という事もあり、何度も練習するには、DVD版の ISO ファイルを一つ、ダウンロードしておく事をお勧めします。

- Hyper-V にインストール -

手元のノートPCには Windows 10 Pro x64 には Hyper-V が用意されているので、ここでは Hyper-V を使って openSUSE Leap 15.1 をインストールしてみました。

SUSE は Novell 傘下の時に、Windows と Linux の相互運用について協力体制を取りました。そのため、多くの Linux ディストリビューションの中で Hyper-V 上での認証された Linux の最初のディストリビューションです。
という事で Hyper-V はもちろん、Asure 上で最も最適化されたバリエーションを用意しています。


ここでは Hyper-V そのものの詳しい説明は割愛します。

Hyper-Vは有効化しておきます。

初めての Linux, openSUSE Leap を Hyper-V で動かす。_a0056607_14062169.png

Hyper-V Manager から「新しい仮想マシン」を作成します。

1G バイトの仮想メモリ、 16Gb の仮想ディスクがあればとりあえずインストールできます。ウィザードの中で数値を適当に設定して進めます。

初めての Linux, openSUSE Leap を Hyper-V で動かす。_a0056607_14064410.png

作成が終わったら、仮想マシンに接続して、「起動」します。

インストールソースに DVD ISO を指定したので、インストーラが起動します。F2キーを押すと、言語設定リストが出てくるので、どうしても「ブート画面からニホンゴじゃなきゃ嫌だ」という場合は、F2キーから「日本語」を選んでください。

openSUSE でサーバー運用する場合、日本語のドキュメントや、詳しい情報が少ないため、私の場合、英語でインストールしてから、第二追加言語を日本語にしています。

SUSE Linux Enterprise Server (SLES) の場合、基本的にサーバー運用で、ヘルプ情報がほとんど英語になってしまうので、私は第二外国語で日本語フォントを入れる以外は殆ど英語版で運用をお勧めします。変に日本語のメッセージやログ、ダイアログが出ても、意味わかりませんからね。

デスクトップを使ってみたいのであれば、日本語でインストールすると良いでしょう。

初めての Linux, openSUSE Leap を Hyper-V で動かす。_a0056607_14090351.png


- インストール -

ここでは、初めてインストールする方に向けてポイントだけを説明します。

実際のインストールの流れは、別記事にまとめてあります。そちらをご参考下さい。

openSUSE Leap 15 Install

15.0 > 15.1の差分として参考にしてください。

openSUSE Leap 15.1 インストール

openSUSE 15.1 のインストールの全体の基本的な流れはこちらの動画(音出ます)




Web LAMP を使いたい場合のインストール手順はこちら(音出ます)。 パーティションは分けてみました。



実際、OSのインストールから、Web Server の立ち上げまでのほとんどの作業を、マウスクリックで行える事に気づかれたでしょうか。

DVD.iso のフルインストール版(3.7GB)を使ってインストールする場合、私はオンラインのリポジトリは使いません。すごく時間がかかるし途中で止まってしまう場合があります。

※ ファイルコピーの途中で止まってしまう場合があります。単に時間がかかっている場合もありますが2~3分待っても進捗しない場合があります。もう一度やり直せばいいだけなのですが、パーティションをフォーマットするので、本番環境の場合は、大事なデータは事前にバックアップしておきます。


- デスクトップの選択 -

openSUSE Leap のデスクトップは KDE を選ぶ人が多い様です。

SUSE Enterprise Linux Server(SLES) は gnome のみです。

私は SLES に合わせて使うので openSUSE をインストールする場合も gnome デスクトップを使います。

どちらがいいのかは好みの問題です。

「サーバー」を選んだ場合はデスクトップ環境がインストールされません。YaST の GUI 版を使うため、初めて SUSE Linux を使う場合も、本格的にサーバー化したい時も、 KDE か gnome デスクトップを選んだ方が良いでしょう。
初めての Linux, openSUSE Leap を Hyper-V で動かす。_a0056607_14093942.png



- ネットワークの設定とホスト名 -

インストールの途中で、ネットワークの設定はできません。デフォルトで DHCP です。

また、コンピュータ名はランダムな名前が与えられるため、この二点を最初に修正します。YaST > System > Network Settings の中で、ホスト名、固定IP/DHCPの設定ができます。

※ openSUSE Leap 15.1 よりネットワーク管理が YaST(Wicked) ではなく、モバイル環境を考慮してデフォルトでデスクトップのアプレット(Network Manager)から設定する様に変更されました。もちろん従来の YaST でも設定できます。

私はモバイル環境で使うつもりがないので Wicked に変更して使っています。

openSUSE Leap 15.1:ネットワークの設定はYaSTではなくアプレットで

openSUSE Leap 15.1 では 15.0 とはネットワーク設定のデフォルトが異なります。(音でます)



YaSTによるネットワーク接続の設定


YaST のネットワーク設定で、 hostname を設定する箇所があるので、ホスト名を任意に変更するには YaST のシステム > ネットワーク設定から変更します。

こちらの動画では、一つ古いバージョン、 openSUSE Leap 15 のインストールから、HOSTNAME の設定、ネットワークやNTPの初期設定を説明しています。(うるさい音出ます)後半1/3あたりから、初期インストールの「その後」の作業の様子をキャプチャしました。




- まずは YaST から始めよう -

さて、そうこうしているうちに openSUSE Leap 15.1 がインストールされました。(やっぱり Hyper-V は KVM に比べて遅いなぁ)

ここでは gnome デスクトップですが、検索ボックスから "yast" で検索すると、YaST アイコンが出てきます。一般ユーザでログオンした場合は、root パスワードが必要になります。

それでは始めましょう。

初めての Linux, openSUSE Leap を Hyper-V で動かす。_a0056607_14113473.png

LibreOffice もインストールされます。日本語入力もできました。Windows でも Mac でも Linux でも使える無料のオープンソース、LibreOfficce と GIMP は最強の組み合わせです。

初めての Linux, openSUSE Leap を Hyper-V で動かす。_a0056607_14132148.png
- Windows からの管理ツール -

今回は 「Hyper-V で使ってみよう」の提案なのですが、実際にはベアメタル環境やコンソールを繋がないサーバー運用もあるでしょう。 Windows 環境から openSUSE/SLE を管理するのに便利なツールを紹介しておきます。

Linux 管理者が持ってると便利な Windows 用ツールとは

個人的には movaXtermwinSCP があれば、おおよその作業は問題ありません。タマに puttyxLaunch を使う程度です。

これらを手元の Windows ノートブックに用意すれば、どこでも困ることは殆どないでしょう。

- VPS での対応は -

レンタルVPSでは、さくらインターネットが openSUSE Leap 15.0 を提供しています。他の ISV ではまだまだです。

この点が日本市場での弱さです・

さくらのVPS カスタムOS「openSUSE Leap 15.0」「FreeBSD 12」提供開始のお知らせ

一般的ではないのですが、ビジネス・エンタープライズ向け Microsoft Azure などの海外の ISV では、普通に SUSE Linux Enterprise が対応しているようです。SLES の場合は、専用のバリエーションがあるので、それを使う事になります。

もし、openSUSE についてもっと情報が欲しい方は、コメント残してください。今後のネタにしてみます。


最後まで読んでくれてありがとうございます









by islandcenter | 2019-06-04 14:46 | SUSE | Comments(0)

Windows 2019 試用版を入手したので、SUSE(SLE15)+KVM 環境下で、仮想マシンドライバパック、VMDP(Virtual Machine Driver Pack, virtio) と一緒に導入してみました。

SUSE Linux Enterprise Virtual Machine Driver Pack

FAQに
"有効なSUSE Linux Enterprise Serverサブスクリプションをお持ちのお客様には、これらの並行仮想化ドライバの保守およびサポートの使用権が自動的に付与されます。ドライバのサポート契約は、お客様が契約しているSUSE Linux Enterprise Serverサブスクリプションから継承されます。"

とあるので SLE のサブスクリプションに含まれている、と考えていいでしょう。

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

最新の VMDP 2.5 はこちらから無料登録済み SUSE アカウント でダウンロードができます。

SUSE Linux Enterprise Virtual Machine Driver Pack 2.5


Windows では xen 環境からの移行も簡単です。

SUSE Linux で XEN から KVM へ移行、VMDP はこんなに簡単

全体の流れは動画にまとめました(9分、盛大に音出ます)

Windows Server 2019 on SUSE Linux 15 with VMDP + KVM install (仮想化インストール)





今回は iso 版を仮想マシンにマウントしてインストールしました。

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15192426.jpg


- virt-manager からインストール -

SLE15より virt-manager のアイコンが yast2 の GUI から消えてしまったので、XのGUI 環境からテキストターミナルを開いて

# virt-manager &

をコマンドライン実行して仮想マシンマネージャを起動します。起動したら”not connected” のラインから右ボタンで "connect" します。

左上の Create ボタンを押して、新しいVMを作成します。

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15202167.jpg


インストールソース iso イメージを指定するため、 Browse ボタンを押して、メディアパスを探してセットします。

インストールソースをセットすると、自動的にインストールするVMのOSタイプを認識します。 SLE15 より Windows 2019 の方が後に出たため、ここでは Windows 2016 と認識されています。 他のOSの場合"unknown" などと出てきた場合は "Automatically detect ......." のチェックを外して、最も近いシステムを選択することができます。

> Forward

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15204710.jpg

Windows Server 2016 と認識したため、VM イメージは 40 Gb と認識されました。 Windows でこれより大きな C: システムイメージを作りたい場合は、任意の数字をセットします。

デフォルトでは /var/lib/libvirt/images の下に qcow 形式の仮想イメージを作ります。
今回は、SSD をマウントしたディレクトリに、RAW フォーマットのイメージを作りたいので、"Select or create ......" を選び "Manage" ボタンを押して、任意の場所、任意のファイル名で仮想イメージを作ります。

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15214328.jpg

メモリとCPU数を、デフォルト状態から任意の数値にセットします。

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15212259.jpg


仮想イメージを作成するディレクトリをブラウズして決定し、ファイル名を任意にセットします。ここでは SSD ドライブをマウントした下のディレクトリに"仮想VM名.disk0.raw" としました。

※ なお、ディレクトリはこのダイアログでは作成できないため、事前に

# mkdir "仮想VM名"

しておくと良いでしょう。

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15223969.jpg



仮想ディスクイメージがセットできたら "Forward"

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15231082.jpg



最後のダイアログです。ここでは必ず決め打ちされた仮想VM名: "Name" のボックスに、運用上の命名規則に則った Name をセットします。

次に、必ず "Customize configuration before install" のチェックを入れて、インストールのサマリダイアログを開くようにしてください。

> "Finish"

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15233941.jpg



"Customize configuration before install" のチェックを入れると、インストールのサマリスクリーンに移動します。

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15243416.jpg


IDE Disk を選んで "Advanced options" ドロップダウンを開くと "Storage format" が qcow2 で決め打ちされています。この欄を "raw" 形式に変更します。

※ qcow2 形式は、指定したディスク容量より小さく、容量を節約できますが、一般に書き込み動作が低速で重い、と言われています。また、データの使い方によっては、それほど、効率が良くないようです。例えば一発デフラグすると、あっという間に容量を使い切ってしまうという事が起こりえます。
 
 システムドライブイメージでは初めから容量確保されて安定して高速な "raw" フォーマットの方が良いと思います。
データドライブ、パーティションは qcow2 形式を選択する場合もありますが、データドライブは別メディア、例えば iSCSI SAN ストレージを使った方がベターです。

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15250315.jpg




VMDP(Virtual Machine Driver Pack) を使う場合、NIC の形式は "Hypervisor Default" から”virtio” に変更します。
ハイパーバイザーデフォルトを後で変更しても構いませんが、手順がややこしいので、インストール時点で "virtio" にしておくのが良いでしょう。

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15263103.jpg


"Apply" を押して、左上にある "Begin installation" を押すとインストールが開始されます。

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15271901.jpg

インストールが始まります。

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15273937.jpg

二度ほど再起動したら、インストール完了です。(この環境では約10分....)さすが Linux ベースの仮想化は早い!...



- VMDP のインストール -

virtio をNICドライバとして設定したため、NICが見当たらない状態になっています。

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15275800.jpg



仮想コンソールからVMのサマリ編集画面のボタンを押して移動し、 IDE CDROM に認識されているインストールソースを"Disconnect" して、”Connect” ボタンから、 VMDP の ISO ファイルをファイルシステムからブラウズしてマウントします。

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15281902.jpg

仮想コンソールに戻り、VMDP の ISO ファイルがマウントされている事を確認します。

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15300798.jpg

※VMDP はアンインストールしたり再インストールする場合があるので、C: ドライブの任意のフォルダにコピーしておくと良いでしょう。

VMDP の setup.exe を実行します。

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15303216.jpg



EULAに同意

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15304667.jpg

インストールが始まります。(この環境で1分弱)

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15310514.jpg

VMDPのインストールが終わると、再起動が要求されます。でもその前にネットワークが検出されたようです。

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15312356.jpg

再起動後のネットワークのプロパティです。ネットワークが認識されているようです。

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15313802.jpg


イーサネットのプロパティを開くと "SUSE Network Driver for Windows" がインストールされている事が分かります。「構成」ボタンを押してドライバのパラメータを確認します。

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15320010.jpg



「詳細設定」タブにドライバのパラメータが設定されています。VMDP2.5 では、デフォルトで問題ないようですが、一応 "xxxx Offload" 系のパラメータは全て "Disabled" になっている事を確認します。 これらが Disable にセットされて問題になったことはありませんが、Enable で問題になったことは何度もありました。


Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15322063.jpg


デバイスマネージャーを開いて、 BUS ドライバや SUSE NIC ドライバがインストールされている事を確認します。

Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15323781.jpg


VMのサマリ画面に戻り "Boot Options" にある "Autostart" にチェックを入れ、ハイパーバイザー筐体が起動したときに同時にVMも起動できるようにします。また、Boot Menu が出ないよう、マウントした CDROM のチェックを外しておきます。


Windows 2019 Server を SUSE Linux 15 (SLES15)+KVM で仮想ドライバを使って最適な仮想化_a0056607_15325246.jpg





How to install samba on SUSE Linux Enterprise 15 (SLES15) インストール

初めての Linux, openSUSE Leap を Hyper-V で動かす

openSUSE Leap 15.1 で始める KVM, 無料のハイパーバイザー


SUSE Linux 15, openSUSE 15, SLES15, KVM, Windows サーバー仮想化、virtio, Linux, 仮想サーバーの最適化, 仮想マシンが重い,






by islandcenter | 2019-02-24 15:33 | SUSE | Comments(0)