各ブラウザ(IE,Google Chrome,Firefox)でのCookie確認・編集の方法
今回は、各種ブラウザでのCookieの内容確認の方法、編集の方法をまとめておく。
■IE
■方法1:デフォルトの機能でCookieデータをエクスポート・インポート
IEにはデフォルトでCookieの内容をエクスポート・インポートする機能がある。
「Alt+F」でファイルメニューを表示後、「インポートおよびエクスポート」を選択すればよい。
対象に「Cookies」を選択すれば、テキストファイルとして内容を取得可能。
また、変更したテキストファイルを同様にインポートも可能。
■方法2:専用のアプリケーションを利用
専用のアプリケーションを利用して、IEのCookieを確認できる。
おすすめは、「IECookiesView」。起動して確認と編集が簡単に可能。
www.nirsoft.net
■Google Chrome
■方法1:拡張機能「Edit This Cookie」を利用
この拡張機能を入れれば、訪問中のサイトのCookieを表示・編集可能
chrome.google.com
■方法2:Cookieファイルを直接参照
Firefoxでもだが、CookieファイルをSQLite形式で保存している。
よって、SQLiteのDBを操作できるアプリケーションから参照可能。
自分は、下記を利用している。
SQLite Studio
SQLiteStudio
参考:SQLiteの開発ツール
SQLiteの開発ツール - 流れ着いたら。。。
■Firefox
■方法1:アドオン「Firebug」を利用
非常に有名なアドオン「Firebug」でもCookieを参照可能
addons.mozilla.org
■方法2:Cookieファイルを直接参照
これはGoogle Chromeと同様。
セキュリティが強化されたWindows FW 「接続セキュリティの規則」について
WindwosのFW機能の内、接続セキュリティの規則に関して簡単なメモ。
WindowsのFW機能は、たくさんあってわかりずらい。
WindwosのFW(正確には、セキュリティが強化されたWindows FW)には
「接続セキュリティの規則」というものが存在する。
通常FWとは、その機器上で単体で稼働して、
届いた通信に対してポート指定、パケットの内容などで通信許可の判断を下す。
※セキュリティが強化されたWindows FWでは「受信規則」、「送信規則」に当たる
「接続セキュリティの規則」は少し異なり、通信相手と、自分自身それぞれで
相応の許可設定が入っている必要がある。
本機能は、通信開始前にお互いのPCを認証して、IPsecで暗号化した通信を行うことができる。
「接続セキュリティの規則」では、規則の種類が下記4つから選択できる。
・分類 ・・・ドメイン参加のコンピュータのみ接続可能
・認証の除外・・・指定したPCを認証対象から除外
・サーバ間 ・・・指定したPC間の接続を認証
・トンネル ・・・外部ネットワークを介する、PC間の接続を認証
・カスタム ・・・カスタムの規則を作成可能
参考:
接続セキュリティの規則の作成
そんなにたくさんあるFWの規則だが、どのような順番で適用されるのかに関しては、
TecNetに記載があった。
【未確定】フラッシュドライブ利用時のフォーマット形式はexFatにすべき？
WindowsでUSBメモリや、SDカードを利用する際のフォーマットに関して。
既定では「exFat」になっているはず。
調べてみると、いろいろ記事がある通りUSBメモリに向いているのはexFatみたい。
特に、速度がNTFSと比較するといいらしいのだけれども、
実際に試してみるとそれほどの有意な差はなかった。
ドライバも最新なはずだしなー。
USBメモリーを高速書き込みフォーマットに変換（exFATに変換）
USBメモリのフォーマットと速度 | いまと違うところへ
利用したメモリは、Team社製の「TFXC128UHS01TG」というモデル。
余談だけど、TSUKUMOで4,600円くらいで128GBを購入できた。
これをSurface Pro3のmicroSDカードスロットに刺して利用している。
今回はこの1モデルだけの検証になるが、下記のようにNTFSのほうが若干良いくらい。
他にも機会があれば試してみようかな。
■NTFS
Windowsの高速スタートアップ(ハイブリッドブート)に関して
Surface Pro3を使っていて感じるのは非常に起動が早いということ。
元々利用していたMacbook Airも起動がはやかったけれどそれ以上に早いかもしれないと感じている。
SSDの恩恵もあるのでしょうが、ほかにも秘密がありそうだなと思って調べてみたらありました。
Windows8以降に搭載されている技術で、高速スタートアップというものみたいです。
どういうものかというと、
単純ではあるが前回のシャットダウン時にOSの情報を一部分保存しておき、
次回起動時にはその情報をロードして処理の短縮をしているとのこと。
もう少し細かくいうと、Windowsが起動する際にはまずOSのカーネルをロードする。
その次に、デバイスドライバをロードするんですが、
この情報を前回のシャットダウン時に保存しておくとのこと。
要は一番時間のかかるであろう、デバイス周りの処理をスキップしてしまうという方法で短縮している。
確かに、頻繁にHWの構成が変更されるわけではないし理に適っているかもしれない。
当然、HW構成が変更した際には通常の起動処理をしないといけないけど。
では、どのようにしたら通常の起動になるのか？という話だが、
高速スタートアップを無効にするか、再起動を実施すれば通常の起動処理になるようです。
自分が利用しているSurface Pro3はデフォルトだと高速スタートアップが有効。
その状態で「シャットダウン」で停止させると、ドライバ情報を書き出して停止、
次回起動時に、書き出した情報をロードして高速スタートアップが動作する。
一方で、「再起動」の場合はドライバ情報を書き出さず、通常の起動処理で立ち上がるようです。
普段そんなに「再起動」なんてしないから、知らずに「シャットダウン」運用をしていたら
ある時から不安定に、、なんてことが起きるかもしれない。
(特にデバイスの追加とか削除があった場合)
ちなみに、高速スタートアップの有効化・無効化は
「電源オプション」＞「システム設定」から変更可能。
最後に、デバイス情報を保存しておくという処理に関してだが、
Cドライブ配下にある、hiberfil.sysがそのファイルらしい。(不可視ファイル)
どこかで聞いたことある気がすると思ったら、
このファイル「休止状態」でシステムを停止する際に情報を保存するファイルじゃん。
参考URL:
Windows10の高速スタートアップって何？速いけど危ない？無効にする方法は？ | ligamap
ハイバネーション（hiberfil.sys）を無効にする･削除する]
pagefile.sysとhiberfil.sysの解説ページ
InstantGO(旧Connected Standby)について
半年前に4年間共にしたMacbook Airが調子が悪くなったのでSurface Pro3を購入。
モバイルPCはもっぱらMacだったので、新鮮な感じです。
実際のところ、非常に便利でWindows10で快適に利用できています。
で、モバイル機器はほぼMacだったのでWindowsをモバイル環境で利用するにあたり
いろいろと発見があるわけです。
例えばWindowsには「スリープ」、「休止状態」というのが元々あったかと思います。
※Windows8以降では「休止状態」はデフォルトでは表示されないらしい。
また、「休止状態」が利用できる端末かどうかというのもあるらしい。
Tips:電源オプションをcmdからいじるには、powercfg.exeを利用する
www.atmarkit.co.jp
そして、「スリープ」の挙動も変わってきているらしい。
現在InstantGOと呼ばれているが、
「従来のスリープ」は完全にOSデータをメモリに保存して停止していたのに対し、
InstantGOが有効状態の「スリープ」は、ネットワーク機能は有効のままになるらしい。
いわゆるスマホのアプリケーションみたいに、
アプリケーションが通信を行い機能を提供できるようにという配慮から生まれた技術とのこと。
InstantGOに対応していない端末の「スリープ」はいわゆる「従来のスリープ」と同様になる。
InstantGOに対応しているかの確認方法は下記で可能。
「powercfg /a」を実行して、
「スタンバイ (S0 低電力アイドル) ネットワークに接続されています」
と出力されれば対応している端末と判断できる。
C:\Windows\System32>powercfg /a
以下のスリープ状態がこのシステムで利用可能です:
スタンバイ (S0 低電力アイドル) ネットワークに接続されています
休止状態
高速スタートアップ
以下のスリープ状態はこのシステムでは利用できません:
スタンバイ (S1)
システム ファームウェアはこのスタンバイ状態をサポートしていません。
S0 低消費電力アイドルがサポートされている場合、このスタンバイ状態は無効です。
スタンバイ (S2)
システム ファームウェアはこのスタンバイ状態をサポートしていません。
S0 低消費電力アイドルがサポートされている場合、このスタンバイ状態は無効です。
スタンバイ (S3)
システム ファームウェアはこのスタンバイ状態をサポートしていません。
S0 低消費電力アイドルがサポートされている場合、このスタンバイ状態は無効です。
ハイブリッド スリープ
スタンバイ (S3) は使用できません。
参考URL:
Microsoft Surface の電源状態
Windows 8 & 8.1はダメOSなのか - 第2回 | マイナビニュース
Windows TIPS：Windows 8／8.1で休止状態設定を有効にする - ＠IT
データストアへのアクセスが遅い on ESXi6.0
少し前にESXi5.1からESXi6.0u1へアップデートしました。
(インストールの方法としては、新規インストールというかたちで）
アップデート後に気になった点として、データストアへのアクセスが遅く感じました。
特に書き込みの面で顕著な気がします。
ESXi6.0がリリースされてから、しばらく時間がたっていますので
事例がないかなと調べてみたらありました。
結論としては、HPのドライバに問題がありそうとのこと。
自宅ではHP製のサーバを利用しているということもあり、
ESXiインストール時には、HPのカスタムイメージを利用しています。
※ちなみに下記からダウンロードしています。
HP製サーバに必要なドライバが組み込まれているので楽です。
HP and VMware’s infrastructure as a service solution | Hewlett Packard Enterprise
どうも、最近のバージョンのカスタムイメージに含まれている
アレイコントローラドライバが良くないようです。
自分が利用した「vSphere 6.0 U1 Nov 2015」というカスタムイメージには
HP製の下記ドライバが組み込まれています。
[XXXX@XXXX:~] esxcli software vib list | grep He char-hpcru 6.0.6.14-1OEM.600.0.0.2159203 Hewlett-Packard PartnerSupported 2016-01-02 char-hpilo 600.9.0.2.8-1OEM.600.0.0.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hp-ams 600.10.3.0-15.2494585 Hewlett-Packard PartnerSupported 2016-01-02 hp-build 600.9.4.34-2494585 Hewlett-Packard PartnerSupported 2016-01-02 hp-conrep 6.0.0.1-0.0.13.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hp-esxi-fc-enablement 600.2.4.6-2494585 Hewlett-Packard PartnerSupported 2016-01-02 hp-smx-provider 600.03.09.00.15-2768847 Hewlett-Packard VMwareAccepted 2016-01-02 hpbootcfg 6.0.0.02-01.00.11.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hpnmi 600.2.3.14-2159203 Hewlett-Packard PartnerSupported 2016-01-02 hponcfg 6.0.0.04-00.13.17.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hpssacli 2.30.6.0-6.0.0.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hptestevent 6.0.0.01-00.00.8.2159203 Hewlett-Packard PartnerSupported 2016-01-02 scsi-hpdsa 5.5.0.46-1OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2016-01-02 scsi-hpsa 6.0.0.114-1OEM.600.0.0.2494585 Hewlett-Packard VMwareCertified 2016-01-02 scsi-hpvsa 5.5.0.100-1OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2016-01-02 <<ここ!
上記のドライバ中、scsi-hpvsaの「5.5.0.100-1OEM.550.0.0.1331820」というバージョンが良くないようです。
そこで、ドライバをダウングレードして実績のあるものに差し替えました。
Very slow acces to datastores on HP MIcroserver... | VMware Communities
既に海外の有志の方々が検証してくれており、上記のサイトを参考にドライバを入れ替えています。
Before:scsi-hpvsa 5.5.0.100-1OEM.550.0.0.1331820
After: scsi-hpvsa 5.5.0-88OEM.550.0.0.1331820
#適用するパッチを格納 cp scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib /var/log/vmware/ #ESXiをメンテナンスモードへ esxcli system maintenanceMode set --enable true #既存のドライバを削除 esxcli software vib remove -n scsi-hpvsa -f #対象のドライバをインストール esxcli software vib install -v file:scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib --force --no-sig-check --maintenance-mode #再起動して反映 reboot #再起動後、変更されているのを確認 [XXXX@XXXX:~] esxcli software vib list | grep He char-hpcru 6.0.6.14-1OEM.600.0.0.2159203 Hewlett-Packard PartnerSupported 2016-01-02 char-hpilo 600.9.0.2.8-1OEM.600.0.0.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hp-ams 600.10.3.0-15.2494585 Hewlett-Packard PartnerSupported 2016-01-02 hp-build 600.9.4.34-2494585 Hewlett-Packard PartnerSupported 2016-01-02 hp-conrep 6.0.0.1-0.0.13.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hp-esxi-fc-enablement 600.2.4.6-2494585 Hewlett-Packard PartnerSupported 2016-01-02 hp-smx-provider 600.03.09.00.15-2768847 Hewlett-Packard VMwareAccepted 2016-01-02 hpbootcfg 6.0.0.02-01.00.11.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hpnmi 600.2.3.14-2159203 Hewlett-Packard PartnerSupported 2016-01-02 hponcfg 6.0.0.04-00.13.17.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hpssacli 2.30.6.0-6.0.0.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hptestevent 6.0.0.01-00.00.8.2159203 Hewlett-Packard PartnerSupported 2016-01-02 scsi-hpdsa 5.5.0.46-1OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2016-01-02 scsi-hpsa 6.0.0.114-1OEM.600.0.0.2494585 Hewlett-Packard VMwareCertified 2016-01-02 scsi-hpvsa 5.5.0-88OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2016-01-02 <<ここ!
これで改善されました。
ESXiをUSBブートで利用時の、パススルー設定に注意。
ESXiをはじめ、最近の仮想化製品はデバイスを仮想マシンにアタッチできるので便利ですよね。
仮想マシンだからという制約がかなり低減されていると思います。
ESXiだとパススルーと呼ばれてまして、
その名のとおりESXiホストに接続されているデバイスを仮想マシンに直接接続させることが可能。
で少し前に、ふとUSBを仮想マシンに接続させようとした際にトラブリました。
何気なくUSBを仮想マシンに接続させるために
パススルーの設定をして、設定適用のために再起動しました。
普通にESXiが起動して、USBデバイスも
仮想マシンから見てるようになりめでたしめでたしと思ったのですが、
その後幾つか気になることが発生しました。
設定を変更した内容が、再起動したら消える。
→これは定期的にESXiはバックアップ処理を入れているから
そのタイミングに合わなかったのかな？と思って
自分を納得させました。（気付けよ。。というはなしなんですが）
ESXiのvib(パッチ)を適用したら、下記エラーがでて怒られる。
(このタイミングでブートデバイスである、USBデバイスになにか問題がある？と思った）
「The transaction is not supported : ・・・略・・・ cannot be removed live.」
で、ESXiのコンソールに接続してデバイス一覧を確認したら、
Bootデバイスが一覧にありませんでした。。(trueが一つもない)
[XXXX@XXXX:~] esxcli storage core device list | grep Boot Is Boot USB Device: false Is Boot Device: false Is Boot USB Device: false Is Boot Device: false Is Boot USB Device: false Is Boot Device: false Is Boot USB Device: false Is Boot Device: false
こうなるとESXiがUSBメモリを認識できていないのは確実。
最近の設定変更を思い出してみると、タイトルになるのですがUSBのパススルー設定をしたなと。
ここで、USBのコントローラ毎パススルー設定をしているのが発覚。
ESXiが起動するまでは、BIOSからブートメディアとして見えているが、
ESXiがメモリにロードされて完全に起動するとパススルー設定が有効化させて、
ブート用USBメモリがESXiから見えなくなるという。。
なので、設定もメモリ上では保持しているが、
再起動等する際には保存されないので先祖返りするということに。
じゃあ、どうやって設定を戻すの？ということになるわけです。
設定変更しても、ブート用USBメモリに設定が反映されないのでしょと。
はい、こうなると再インストールした後に設定を戻すしかありません。
それは、、うん、そうだよね。ということになるのですが。
ちなみにVMWareのKnowledge Baseにご丁寧に説明もあります。
ESXiがUSBからブートしているのを検知できるんだから、設定時に警告だしてくれないかなぁ。
ちょっと求めすぎかなぁ。
