コマンドプロンプトから時刻合わせを試みたけれども狙い通りの挙動にならない

OS: Windows 10 Pro version 1809

主として使用しているパソコンの時刻が日本標準時から1.2秒も進んでいたからコマンドプロンプトからチャッと時刻を同期して精密に時計を合わせようと試みたけれどもWindowsの時刻同期は挙動が掴み切れず生半可な知見で臨んだところ忽ち返り討ちである。

w32tmコマンド一度きりの実施で時刻が確り同期される場合もあれば何遍繰り返してもちっとも同期されないケースもあったから困る。まずはコマンドプロンプトを管理者として実行するところから始めねばならない。一先ず時刻同期の様子を確認しようと次のコマンドを流すとこういう有様である。

>w32tm /query /status
次のエラーが発生しました。 そのサービスを開始できませんでした。 (0x80070426)

Windows Time サービス(w32time)が実行されていないとw32tmコマンドの主たる機能が取り扱えないようである。w32timeを開始するにはこうである。

>net start w32time
Windows Time サービスを開始します.
Windows Time サービスは正常に開始されました。

改めて w32tm /query /status を実行すると時刻の同期にCMOS Clockを使うことを発見した。おおかたマザーボードに搭載されているCMOSの時計を照らし合わせに用いるという設定であるとおもうからこれをNICTが公開しているNTPサーバ ntp.nict.jp に切り替える。

>w32tm /query /status
閏インジケーター: 3 (同期未実行)
階層: 0 (未指定)
精度: -23 (ティックごとに 119.209ns)
ルート遅延: 0.0000000s
ルート分散: 0.0000000s
参照 ID: 0x00000000 (未指定)
最終正常同期時刻: 未指定
ソース: Local CMOS Clock
ポーリング間隔: 10 (1024s)

NTPサーバの指定に続けてカンマを配して同期モードを16進数でセットできる風情である。1,2,4はSymmetric ActiveとかいうNTPサーバ同士でやり取りを交わすためのモードであったからクライアントとして使うPCには相応しくないとおもってClientモードを用いる0x8を記述した。

>w32tm /config /update /manualpeerlist:ntp.nict.jp,0x8 /syncfromflags:manual
コマンドは正しく完了しました。

>w32tm /query /status | find "ntp.nict.jp"
ソース: ntp.nict.jp,0x8

そうしたら /resync オプションで以って手づから時刻を同期させる。

>w32tm /resync
再同期コマンドをローカル コンピューターに送信しています
コマンドは正しく完了しました。

ズレが解消されたか確認をすると何ら効果を齎していない風情であった。幾度か実施を繰り返して見たけれどもほとんど動きが見られない。此は如何にとおもって調べるとじわじわと時刻を調整してゆくslewモードと一息に時刻を同期させるstepモードが用意されていて、諸条件を満たすとslewモードになりそうでなければstepモードになるという仕組みである。

>w32tm /monitor /computers:ntp.nict.jp /nowarn
ntp.nict.jp[133.243.238.163:123]:
ICMP: 25ms 遅延
NTP: -1.1755319s ローカル コンピューターの時刻からのオフセット
RefID: 'NICT' [0x5443494E]
階層: 1

slewモードの条件を満たしたから時計がすぐに合わないのだといっときは納得したけれども腰を据えて条件式を計算したところぜんぜん要件を満足しないからstepモードでパッとずれが解消されることが期待される筈であるのにどうも挙動がわからない。

>w32tm /debug /enable /file:"%userprofile%\desktop\w32tm.txt" /size:0 /entries:0-300
プライベート ログを有効にするコマンドをローカル コンピューターに送信しています...
コマンドは正しく完了しました。

>w32tm /resync
再同期コマンドをローカル コンピューターに送信しています
コマンドは正しく完了しました。

>w32tm /debug /disable
プライベート ログを無効にするコマンドをローカル コンピューターに送信しています...コマンドは正しく完了しました。

デバッグログを出力するよう設定して時刻同期を実施した際の内容を眺めたけれどもなんだかむつかしくてslewモードで時計を合わせようとしている情勢で或ることくらいしか掴めない。

もうすっかり厭になってしまって捨て鉢で時刻の自動設定をオフにしてから時刻を徒に大きくずらして改めて時刻を自動的に設定する設定をオンに切り替えたところ、何がどう作用したかは知れないけれども期せずしてstepモードのような働きによって時刻のぶれが慎ましい値へ落ち着いた。

>w32tm /stripchart /computer:ntp.nict.jp /period:5

たいへん強引なやり方であるから決して常用できないけれども退っ引きならない情勢であるときは不承不承この方法を選択せざるを得ない。

参考:
第3回 w32tmコマンドとレジストリによるWindows Timeサービスの制御 (1/4)

HTTPSによる暗号化された通信のやり取りをWiresharkで復号して内容を読み取る

OS: Windows 10 pro version 1809
Wireshark 2.6.6 64-bit
Google Chrome 72.0.3626.96

或るサイトから取得されるファイルのURLを探ろうとしてWiresharkを立ち上げ通信を捕えても近頃はすっかりHTTPSでやり取りがなされるから、中身を覗き見ようとしてもEncrypted Application Dataという具合に暗号化されて出鱈目な文字がおどるだけであって具体的な内容は確認できない。そうするとリクエストヘッダであるとかレスポンスヘッダが全く定かでなくなるから一寸内容を知りたいときにこまる。

Google Chromeのショートカットアイコンを右クリックしてプロパティを開くと「リンク先」の欄にGoogle Chromeのexeファイルを示すパスが記載されているからその後にひとつ、半角スペースを付け加えてから --ssl-key-log-file オプションと値を続けて記す。値は、暗号化にまつわる情報を書き出してゆくファイルのパスを指定するのである。デスクトップへssl.txtとして情報をダンプするならこういう具合でよかった。

--ssl-key-log-file=%userprofile%\desktop\ssl.txt

Google Chromeをすっかり終了させ改めて起動するとデスクトップへssl.txtがひとりでに作成され暗号化に使われている各種の情報が詳らかに記載されてゆく。悪いやつの手に落ちると大変危ないファイルであるから厳重な管理のもとに扱わねばならない。

今度はWiresharkを起動して「編集」の「設定」を開く。

「Protocols」の項目を展開するとおびただしい数のプロトコルがずらりと並ぶからそのうち「SSL」を見つけて「(Pre)-Master-Secret log filename」という設定項目に、先に作成された暗号化にかかわる情報が溢れているファイルのパスを指定する。

そうして改めてWiresharkで以ってHTTPSの通信内容をキャプチャして中身を確認するとこういった具合である。

目論見通り暗号化された情報が復号されて具体的な内容が確認できる。

ショートカットのプロパティを編集する方法であると、のちに復号の必要がなくなったというのに設定を消し忘れて痛い目を見る恐れもあるから、一時的に利用する手立てとしてコマンドプロンプトを開いて SSLKEYLOGFILE という環境変数を定めてからGoogle Chromeを起動してやればのちに禍根を残す蓋然性が低くなって良いとおもう。

>set sslkeylogfile=%userprofile%\desktop\ssl.txt
>start "" "%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe"

参考:
NSS Key Log Format

Windows Driver Kitをインストールすることなしにdevcon.exeを用意する

OS: Windows 10 Pro version 1809 64bit

devcon.exeによるデバイスの操作を企てたのであるけれども、其れ単独でインターネットからダウンロードすることが叶わない。Windows Driver Kit(WDK) for Windows 10, version 1809を手近なパソコンへ導入しさえすれば %programfiles(x86)%\Windows Kits\10\Tools\x64 にdevcon.exeの準備は整うけれども概ね2GBものディスク容量を消費するうえインストールに暇もかかって誠に遺憾である。

も少し手軽な手段を探ると、WDKを構成するCABファイルの一つをダウンロードしてdevcon.exeを取り出すという手立てがあるようである。まずは787bee96dbd26371076b37b13c405890.cabをダウンロードする。

そうしたらダブルクリックをしてCABファイル内に格納されているファイルの一群を覗く。

filbad6e2cce5ebc45a401e19c613d0a28fというファイルがdevcon.exeそのものであるから適当な場所へコピーしてdevcon.exeにリネームしてやれば終いである。

>move filbad6e2cce5ebc45a401e19c613d0a28f devcon.exe
1 個のファイルを移動しました。

>devcon.exe
devcon.exe Usage: devcon.exe [-r] [-m:\\<machine> ] <command> [<arg>...]
For more information, type: devcon.exe help

参考:
Quick Method to install DevCon.exe?
Where to find DevCon.exe

名前に:(コロン)が含まれているファイルをscpコマンドで以ってコピーする

Ubuntuでウィンドウのスクリーンショットを撮影し其れをscpで他のホストへ転送を試みたところこうである。

$ scp Screenshot\ from\ 2019-01-18\ 16\:44\:48.png guro@192.168.0.100:/home/guro
ssh: Could not resolve hostname screenshot from 2019-01-18 16: Name or service not known

或いは Temporary failure in name resolution のようなメッセージも見られた。どうもファイル名に含まれる最初のコロンの直前までがホスト名と看做されている風情を感ずる。ファイル名をクオートで囲い込めばエラーを迂回できると考えたけれども案に相違して結果は同じであった。scpのオンラインマニュアルを繰るとこうである。

File names may contain a user and host specification to indicate that the file is to be copied to/from that host. Local file names can be made explicit using absolute or relative pathnames to avoid scp treating file names containing ‘:’ as host specifiers.

man 1 scp

相対パスか絶対パスでファイル名を定めればホスト名として解釈されずに済むというものである。

$ scp ./Screenshot\ from\ 2019-01-18\ 16\:44\:48.png guro@192.168.0.100:/home/guro

Ubuntu Desktop 18.04 LTSにKVMを導入しCentOS7を試験的にインストールする

OS: Ubuntu Desktop 18.04 LTS 日本語 Remix
CPU: Intel Core i7-4790 processor

仮想化技術の一であるKVM(Kernel-based Virtual Machine)もLPIC-3 304 Virtualization and High Availabilityの出題範囲でまことに大きな比重を占めており微塵も軽んずること能わず導入が急がれる情勢である。KVMの導入には仮想化支援機能を有したCPUがマシンに搭載されていなければならない。仮想化支援機能のあるやなしやを掴むにはこうである。

$ grep -cE '(vmx|smv)' /proc/cpuinfo

0よりも大きな自然数が返ればKVMの導入が叶うけれども0の場合は仮想化支援機能のあるCPUを買い求めに店頭へ走らねばならない。また、仮想化支援機能がBIOSの設定で無効にされている場合もあるから詳らかに探るなら $ sudo apt install cpu-checker でcpu-checkerパッケージを導入して $ sudo kvm-ok を実行すると宜しいようである。

$ sudo kvm-ok
INFO: /dev/kvm does not exist
HINT: sudo modprobe kvm_intel
INFO: Your CPU supports KVM extensions
INFO: KVM (vmx) is disabled by your BIOS
HINT: Enter your BIOS setup and enable Virtualization Technology (VT),
and then hard poweroff/poweron your system
KVM acceleration can NOT be used

加えてVMware Workstation上で動作するOSに対してKVMを導入するのであれば仮想マシンの設定にも気を配らねばならない。「Processors」の設定にある「Virtualize Intel VT-x/EPT or AMD-V/RVI」にチェックを入れておかねば折角の仮想化支援機能が台無しである。

あとはKVMをインストールして終いである。必要になるパッケージはUbuntuのバージョンによって異なる風情であるけれども、Ubuntu 18.10で求められるパッケージをUbuntu 18.04に導入してもなんとなく動いているようである。

Ubuntu 10.04以降
$ sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils

Ubuntu 18.10以降
$ sudo apt install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils

試験的にKVMで以ってCentOS7の導入に取り組む。まずはディスクイメージを作成する。centos7.imgという名の10GBの容量を持つqcow2(QEMU Copy On Write version 2)形式のディスクイメージを生みだすならこういった具合で間に合う。

$ qemu-img create -f qcow2 centos7.img 10G
Formatting 'centos7.img', fmt=qcow2 size=10737418240 cluster_size=65536 lazy_refcounts=off refcount_bits=16

予めCentOS7のISOファイルをダウンロードして手元に用意しておく。

$ wget -c http://isoredirect.centos.org/centos/7/isos/x86_64/CentOS-7-x86_64-DVD-1810.iso

先に作成したディスクイメージcentos7.imgにCentOS7をインストールする。インストールのために一度だけCD-ROMから起動するよう指定するなら -boot once=dである。

また特段の指定がなければ仮想マシンのメモリ容量は128MBにセットされるけれども十分でないのかインストーラがカーネルパニックで打ち切りの憂き目に遭うから -m 512 として512MBを割り当てるのが良さそうである。

$ sudo kvm -hda centos7.img -cdrom CentOS-7-x86_64-DVD-1810.iso -boot once=d -m 512

インストールを済ませたらあとはCentOS7を起動するばかりである。

$ sudo kvm -hda centos7.img -m 512 -monitor stdio 

参考:
KVM/Installation
KVM