資料：LS4361-2 カクダイ 洗濯機用排水延長ホース 2m [ KAKUDAI JAN:4972353499588]

 切断により外径(と内径)を調整できる継手部分に、
■34■、■31■、■26■と読める凸凹が存在した。
2m以外の商品としては
- LS4361-1 1m
- LS4361-1.5 1.5m
- LS4361-3 3m
があるようだが、同じかどうかは確認していない。

申請用総合ソフト(7.6A(R4.3.5))でマイナンバーカードによる署名付与

＜登記・供託オンライン申請システム＞の＜申請用総合ソフト バージョン7.6A(R4.3.5)＞を
利用していたところ、
＜マイナンバーカード＞+＜ICカードリーダ USB接続＞+＜Windows10 64bit PC＞
という環境で、＜署名付与＞だけが上手くいかない問題が生じた。

酷い解決策だが、＜署名付与＞を処理するとき、
＜ICカードリーダの初期化に失敗しました。＞
というエラーメッセージを半ば無視して、繰り返し試行すると解決できた。
具体的には、[署名付与(1回目)]→
＜[ICカードで署名]→[OK]→アクセスパスワードを入力[確定]＞
を3回繰り返す→[閉じる]→[署名付与(2回目)]→...
というキーボード(+マウス)操作を繰り返すと、
稀に処理が進行し、署名付与を完了できた。
※アクセスパスワードは＜マイナンバーカードの署名用パスワード(6～16桁)＞

なお、＜申請用総合ソフト＞の起動毎に再設定する必要は無いようだが、

ＩＣカード格納型電子証明書を利用する際の留意事項
https://www.touki-kyoutaku-online.moj.go.jp/cautions/security/ic_syoumei.html

にある、

マイナンバーカード（個人番号カード）を電子署名で利用する方法
http://www.touki-kyoutaku-online.moj.go.jp/static/kojinbangocard_151211663.pdf

の事前準備は必要なので、この設定について確認を忘れてはいけない。



以下、オマケです。

JPKI利用者ソフト(公的個人認証サービス 利用者クライアントソフト)
e-Tax、eLTAX(PCdesk)等では、マイナンバーカードによる署名付与は
一切問題なく実行できる環境だった。
Web検索すると、同様の問題への対策情報が見つかったが、どれもうまくいかず困った。

標準ユーザ(非管理者ユーザ)なのがダメなのだろうかとか、
JPKI利用者ソフトのバージョン(現在最新の3.4)がダメなのだろうかとか、
カードリーダやマイナンバーカードの抜き差しがコツなのだろうかとか、
いろいろ探ったが、私の環境では関係なかったようだ。

Win10_1909_Japanese_x64.iso を USBメモリー(GPT + NTFS) で UEFI 起動

発売日 Q1'18 の Intel NCU (BOXNUC7PJYH) に対し、
Win10_1909_Japanese_x64.isoを元にした
USBメモリーのインストーラーで
Windows10を新規インストールした。

2020-01-01時点で最新のWindows10インストーラーisoファイルとなる
Win10_1909_Japanese_x64.iso 内の \sources\install.wim が
fat32ファイルサイズ上限4GBを超えているので、
fat32パーティションによるUSBメモリーでは収まりきらない。
いろいろ調べて試した結果、インストール対象のNUCにおいては
GPT + NTFS 利用のUSBメモリーをUEFI起動でとりあえずインストールできた。

重要事項は、NTFSパーティションのフラグ設定で、
bootを指定した場合はインストールできなかったが、
msftdataというのを設定するとできた事だと思う。
アヤフヤな記憶をもとにした大まかなエエカゲンな手順は次の通りです。


データ一が消滅してかまわない
8GB超のUSBメモリー(/dev/sdXXX)に対し作業をしていきます。

# parted /dev/sdXXX

(parted)p

(parted)unit s

(parted)mktable
gpt

(parted)mkpart
(名無し)
ntfs
2048s
100%

(parted)set 1 msftdata
on

(parted)p

(parted)q

# mkfs.ntfs -Q /dev/sdXXX1

# mount -o ro Win10_1909_Japanese_x64.iso /mnt/iso

# mount -o rw /dev/sdXXX1 /mnt/usb8gb

# cd /mnt/iso

# cp -p -r * /mnt/usb8gb/

# cd $HOME

# umount /mnt/usb8gb

# umount /mnt/iso

# sync

資料：AXW280-7 AXW245-5320 エルボ ホースバンドB

2017年頃販売されていたパナソニック製ドラム式洗濯機
(NA-VX9700Lとかのシリーズ品)の排水ホースに、
90度(実際は70度程)曲げられるエルボの取り付けが必要だった。
施工説明書(設置用の説明書)に
[エルボ][ホースバンドB]と記載されている物だが、
■型番■が不明だった。
■N-MH2■真下排水ユニット は、余計な物が多すぎて買いたくなかった。
それなりに何とか調べて、
[エルボ]■AXW280-7■ エルボ7
[ホースバンドB]■AXW245-5320■ ホースバンド
を購入し、取り付けられたようだ。

あくまで自己責任で。



参考:
洗濯機を快適に使うための別売部品 - Panasonic
https://panasonic.jp/wash/pdf/fullauto_benri_20170519.pdf

iPXEでWindows10(1703 Creators Update)のインストーラをディスクレスブートし、iSCSIターゲット内ストレージにインストール

Windows7以降のiSCSIディスクレスブートを実現したことがある方向けの情報です。
インストーラDVDをディスクレスで済ます為の情報です。


[手順]
重要なポイントはiPXE公式サイトの通りです。
http://www.ipxe.org/wimboot


[検証環境]
Legacy BIOSブート(UEFIのセキュアブートブートではない)
iPXE (undionly.kpxe 数年前にソースからmake)
wimboot-2.6.0-signed
tgt (iSCSI target)
lighttpd (HTTPサーバ)
dnsmasq (DHCPサーバ+TFTPサーバ)
Realtek 8111E (マザーボード ASUS P8H61-M LE オンボード)
　ドライバのVersion 10.021 2017/8/25(RealtekのWebサイト)
Win10_1703_Japanese_x64.iso

以上の環境でインストールを完了し、Windows10のsanbootができることを確認した。


[tgtの設定(一部)]
<target iqn.2003-01.org.linux-iscsi.hogeserver.x8664:win10pc>
    <backing-store /home/hogeuser1/opt/win10pc/win10pc_120gb-raw.img>
        lun 1
        device-type disk
    </backing-store>
    <backing-store /home/hogeuser1/opt/iso/Win10_1703_japanese_x64.iso>
        lun 6
        device-type cd
        readonly 1
        allow-in-use yes
    </backing-store>
....
</target>


[Win10_1703_Japanese_x64.isoをマウント(例)]
# mount -t udf -o ro,loop Win10_1703_Japanese_x64.iso /media/iso/Win10_1703_Japanese_x64


[iPXEスクリプト(例、一部)]
sanhook --drive 0x80 iscsi:192.168.1.101:::1:iqn.2003-01.org.linux-iscsi.hogeserver.x8664:win10pc

set base-url http://hogeserver/hoge/

kernel ${base-url}ipxetool/wimboot-2.6.0-signed/wimboot pause

initrd ${base-url}mnt/win10/boot/bcd         BCD
initrd ${base-url}mnt/win10/boot/boot.sdi    boot.sdi
initrd ${base-url}mnt/win10/sources/boot.wim boot.wim
boot


[その他]
Win10_1607_Japanese_x64.iso
Win8.1_Japanese_x64.iso
も同様の手順でインストーラー起動までは確認した。
※インストール作業、インストール後のsanbootは検証していない。


[UEFIセキュアブートについて]
マザーボードがセキュアブートブート非対応なので検証できないが、
iPXEはUEFI対応版(undionly.efi等)をmake可能

iPXEでWindows8(8.0)のインストーラをディスクレスブートし、iSCSIターゲット内ストレージにインストール

※wimboot-2.1.0以前を使用した場合の情報です。

[手順]
重要なポイントはiPXE公式サイトの通りです。
http://www.ipxe.org/wimboot

Windows7とほとんど同じです。
http://xn--2qq87f54j6n1b.blogspot.com/2012/11/ipxewindows7iscsi.html

違いは、wimbootをbootする前のiPXEのスクリプトで、以下の部分です。

[Windows7の場合]
sanhook --drive 0x80 ${iSCSI-DD用root-path}
sanhook --drive 0x81 ${iSCSIでのwin7.iso用root-path}

set base-url http://tgt.or.some.server/hoge/

kernel ${base-url}ipxetool/wimboot
initrd ${base-url}mnt/win7/bootmgr          bootmgr
initrd ${base-url}mnt/win7/boot/bcd         BCD
initrd ${base-url}mnt/win7/boot/boot.sdi    boot.sdi
initrd ${base-url}mnt/win7/sources/boot.wim boot.wim
boot

[Windows8の場合]
sanhook --drive 0x80 ${iSCSI-DD用root-path}
sanhook --drive 0x81 ${iSCSIでのwin8.iso用root-path}

set base-url http://tgt.or.some.server/hoge/

kernel ${base-url}ipxetool/wimboot
initrd ${base-url}mnt/win8/bootmgr          bootmgr
initrd ${base-url}mnt/win8/boot/bcd         BCD
initrd ${base-url}mnt/win8/boot/fonts/segmono_boot.ttf segmono_boot.ttf
initrd ${base-url}mnt/win8/boot/fonts/segoe_slboot.ttf segoe_slboot.ttf
initrd ${base-url}mnt/win8/boot/fonts/wgl4_boot.ttf    wgl4_boot.ttf
initrd ${base-url}mnt/win8/boot/fonts/jpn_boot.ttf    jpn_boot.ttf
initrd ${base-url}mnt/win8/boot/boot.sdi    boot.sdi
initrd ${base-url}mnt/win8/sources/boot.wim boot.wim
boot

[検証環境]
NIC
 マザーボード ASUS P8H61-M LE オンボード
 Realtek 8111E 
ドライバ
 ASUS の Webサイト
 Realtek LAN Driver V8.19.726.2013 for Windows Win8.1 32bit & Win8.1 64bit---(WHQL).
 Realtek_LAN_Win8-1_VER819.zip 

[検証実績]
iPXEのメーリングリストやWeb情報では、

RealtekのNICを使った場合、Windows8インストールの過程で、
・isoイメージからWindows8のインストーラ起動、
・iSCSIターゲット内ストレージへのファイルコピー、
・一回目のPC再起動開始、
ココまでは進むが、iSCSIターゲット内ストレージからの初回起動で
INACCESSIBLE_BOOT_DEVICE エラーが発生してしまう。IntelのNICだと大丈夫だけど・・・

という感じだった。自分もWindows8発売(2012年10月)直後にWindows8内蔵のドライバを使うと
同じようにINACCESSIBLE_BOOT_DEVICE エラーが発生していた。
以後、4ヶ月に一度ぐらいのペースで断続的にRealtekのWebサイトから最新ドライバを取ってきて、
インストール先ディスクを選択する段階のところで、このドライバを読み込ませる手順により、
Windows8のインストールを再試行するものの、やはりINACCESSIBLE_BOOT_DEVICE エラーが発生していた。

先日(2014年1月)、上記環境で試したところ、
ドライバ更新のおかげか、なんらかのオンラインアップデートの影響かわからないが、
INACCESSIBLE_BOOT_DEVICE は発生しなくなり、インストールが完了した。

ちなみに、今日現在、RealtekのWebサイトにある最新のバージョン8.020は、
Windows8のインストーラで使えず、iSCSIターゲット内ストレージへのファイルコピー、の前でつまずいた。。。

Debian wheezy ：postgresql (9.1) で EUC-JP エンコードのデータベースを作成

debianのパッケージ postgresql-9.1 (9.1.11-0wheezy1) を通常インストールした状態で、
EUC-JPエンコードのデータベースを作成しようとしたら、

$ createdb -E EUC_JP -T template0 MyDB
createdb: データベースの生成に失敗しました：ERROR:  符号化方式 EUC_JP がロケール ja_JP.UTF-8 に合いません
DETAIL:  選択された LC_CTYPE を設定するには、符号化方式 UTF8 である必要があります。

という結果に。

$ createdb -E EUC_JP -l C -T template0 MyDB

とすれば、とりあえずデータベースを作成できるが、
ソート順が辞書順にならないなど、日本語関係の処理に違和感があるかもしれない。
その場合は、EUC-JP用の日本語ロケール(ja_JP.eucjp)を用意すればよいらしい。
具体的には、

$ locale -a

で、ja_JP.eucjpロケールがないのを確認し、

$ sudo vi /etc/locale.gen

で、ja_JP.EUC-JP EUC-JP の行をアンコメントし、

$  sudo locale-gen

で、ja_JP.eucjpロケールを追加し、

$ locale -a

で、ja_JP.eucjpロケールを用意できたのを確認し、

$ createdb -E EUC_JP -l ja_JP.eucjp -T template0 MyDB

で、データベースを作成できた。

[参考]
Ubuntuでja_JP.EUC-JPを使用する - World Wide Wonderful
http://d.hatena.ne.jp/orangehat/20090421

ロケール(国際化と地域化) — Let's Postgres
http://lets.postgresql.jp/documents/technical/text-processing/2/

Linux ソフトウェア RAID1の障害復旧記録(Ubuntu12.04)

おおよそ、以下の環境での記録です。
・ubuntu 12.04 (ブートローダはGRUB2)
・/dev/sdOK のHDDは正常
・/dev/sdFAILED のHDDは不具合
・/dev/sdNEW は新規・新品HDD
・sdOK sdFAILED sdNEWは、全て同じ容量、同じパーティション構成
・/dev/md0は sdOK1 と sdFAILED1 で構成
・/dev/md1は sdOK2 と sdFAILED2 で構成

まず、データのバックアップをとった。

下の[復旧作業]を他の(仮想)PCで予行演習し、自己責任で作業を実行した。

[役立ちそうな情報確認・表示コマンド]
RAIDの状態を表示
# cat /proc/mdstat

/dev/sdX の製品名・シリアル番号・容量等を表示
(要 smartmontools パッケージ)
# smartctl -i /dev/sdX

/dev/sdX のパーティション情報をs(sector)単位で表示
# parted /dev/sdX unit s print


[復旧作業]
sdFAILED が Fail(F)状態ではない場合、Fail状態に変更。
# mdadm --manage /dev/md0 --fail /dev/sdFAILED1
# mdadm --manage /dev/md1 --fail /dev/sdFAILED2

sdFAILEDをRAIDから除去。
# mdadm --manage /dev/md0 --remove /dev/sdFAILED1
# mdadm --manage /dev/md1 --remove /dev/sdFAILED2

sdOKにGRUBが入っているか確認。
# dpkg-reconfigure grub-pc

sdOK,sdFAILED の仕様を確認し、後の作業での取り間違えを回避。
# smartctl -i /dev/sdOK
# smartctl -i /dev/sdFAILED

PCをシャットダウン、sdFAILEDを除去、sdNEW を接続、PCを起動。

自分の環境では、/etc/grub/defaultの
GRUB_TERMINAL=console
これを無効に(コメントに)していた事などから、
GRUBのブートメニューでrecovery modeを選択しないと、
degraded状態でのUbuntu起動ができなかった。

とりあえず起動できたので、普通にlogin。

sdOK sdNEW が /dev/sda か /dev/sdb か、何なのかを確認、特定。
(あるいは /dev/disk/by-id/ とかを使えば良いのかもしれない)
# ls /dev/sd? 
# smartctl -i /dev/sda
# smartctl -i /dev/sdb
# cat /proc/mdstat

sdOKのパーティション情報を表示。
# parted /dev/sdOK unit s print

/dev/sdNEW のパーティションを以下の条件で作成。
・パーティションテーブルはMBR(GPTではない)
・パーティション1: 基本(primary)パーティション Start 2048s End 999423s 
・パーティション2: 基本(primary)パーティション Start 999424s End 1953523711s
・パーティション1、2は、ともにLinux ソフトウェア raid 用
# parted /dev/sdNEW
(parted) unit s
(parted) print
(parted) mklabel msdos
(parted) print
(parted) mkpart primary 2048s 999423s
(parted) print
(parted) mkpart primary 999424s 1953523711s
(parted) print
(parted) set 1 raid on
(parted) set 2 raid on
(parted) print
(parted) quit

/dev/sdNEWをRAIDに追加。
# mdadm --manage /dev/md0 --add /dev/sdNEW1
# mdadm --manage /dev/md1 --add /dev/sdNEW2

RAIDの状態表示で、追加作業の開始を確認し、完了するまで放置。
# cat /proc/mdstat

念のため、initrdを更新。要らないかもしれないが、なんとなく。
# update-initramfs -u

GRUBを/dev/sdOK と /dev/sdNEWに(再)インストール。
# dpkg-reconfigure grub-pc

PCを再起動し、RAID1障害復旧の完了を確認。

[参考]
ソフトウェアRAID１障害時のHDD交換（Parted編） | クラウド備忘録
http://www.cloud-memo.com/2013/04/raidhddparted.html

Ubuntu Manpage: GNU Parted - a partition manipulation program
http://manpages.ubuntu.com/manpages/precise/man8/parted.8.html




[おまけ作業：RAID1 --raid-devices=3]
HDD2台(2重)構成のRAID1では、なんとなく心配になってきたので、
HDD(/dev/sdTHIRD)を追加し、HDD3台(3重)構成のRAID1に変更した。

パーティションを作成するところまでは sdNEWと同じなので省略。

spareとしてsdTHIRDを登録。
# mdadm --manage /dev/md0 --add /dev/sdTHIRD1
# mdadm --manage /dev/md1 --add /dev/sdTHIRD2
3台構成に変更。
# mdadm --grow /dev/md0 --raid-devices=3
# mdadm --grow /dev/md1 --raid-devices=3

RAIDの状態表示で、追加作業の開始を確認し、完了するまで放置。
# cat /proc/mdstat

initrdの更新と、GRUBをsdTHIRDにもインストール。
# update-initramfs -u
# dpkg-reconfigure grub-pc

以上で完了。

ちなみに、2台に戻す場合のmdadm処理は、以下の要領。
# mdadm --manage /dev/md0 --fail /dev/sdTHIRD1
# mdadm --manage /dev/md0 --remove /dev/sdTHIRD1
# mdadm --grow /dev/md0 --raid-devices=2



[おまけ：気になった点]
「initrd.img の更新は必要なのか？」
と思ったが、今回の作業では不要だったかもしれない。
UUIDの変化は、blkid コマンドにて、以下の通りいくつか確認した。
・構成ディスクが変わっただけなので、md0 md1 のUUIDは変化無し
・sdFAILED[12] と sdNEW[12] のUUIDは同じなので、実質的にUUIDの変化無し
・sdFAILED[12] と sdNEW[12] のUUID_SUBは異なるので、UUID_SUBは変化あり
・mdadm.confには、UUID_SUBの記述は見当たらない
・ついでに、grub.cfgには、UUID_SUBの記述は見当たらない
よって、更新は要らないかもしれない。ただし、

# update-initramfs -u
# dpkg-reconfigure grub-pc

このあたりの処理で、UUID_SUBを検出して利用している可能性はあるので、
これらを実行しておいたほうが無難だとは思う。

Linux ソフトウェア RAID1の障害復旧作業では起こらないかもしれないが、
何らかの理由か、何か別の処理で /dev/md や /dev/sd の UUIDが変われば、
設定の更新処理をしてからGRUBのインストールやinitrd.imgの更新等が必ず必要になるだろう。
処理内容は、おそらく以下のような感じ。※これは予想※

# echo mdを構成するsdのUUIDが変更されたら・・・
# cd /etc/mdadm
# mv -i mdadm.conf mdadm.conf--backup
# /usr/share/mdadm/mkconf generate
#
# echo mdのUUIDが変更されたら・・・
# cd /etc
# mv -i fstab fstab--backup
# vi fstab
#
# update-initramfs -u
# dpkg-reconfigure grub-pc


[おまけ:発見したこと]
Ubuntu新規インストール時にRAIDの作成処理をした後ぐらいの所で、
「OSブート時、もしもRAIDがdegrade状態だった場合の通常処理は、
　そのまま起動か？中止か？」
という選択を求められたが、その変更方法が気になっていた。

# dpkg-reconfigure mdadm

これで、変更できるっぽい事を知った。

資料:HDD,SSD 容量・セクタ数 一覧表

製造元あるいは型番が異なると、大雑把な容量表示(○GB, ○TB)に対応するセクタ数が違う場合があります。そのため、あまり意味がありません。

[WesternDigital]

Capacity	User Sectors	Model
40GB	78165360	WD400JD
80GB	156301488	WD800JD
120GB	234441648	WD1200AAJS
160GB	312581808	WD1600AAJS
250GB	488397168	WD2500AAKX
320GB	625142448	WD3200AAKX
500GB	976773168	WD5000AZRX
750GB	1465149168	WD7500AALX
1TB	1953525168	WD10EZRX
1.5TB	2930277168	WD15EARX
2TB	3907029168	WD20EZRX
3TB	5860533168	WD30EZRX
4TB	7814037168	WD40EZRX

[Intel]

Capacity	User Sectors	Model
60GB	117231408	SSD330,SSD520Series
120GB	234441648	SSD330,SSD520Series
180GB	351651888	SSD330,SSD520Series
240GB	468862128	SSD330,SSD520Series
480GB	937703088	SSD520Series

仮想ストレージを作る時、なるべく存在する物理HDD/SSDと同一容量で作りたい気がしたので調べてみました。

iPXEでWindows7のインストーラをディスクレスブートし、iSCSIターゲット内ストレージにインストール

※wimboot-2.1.0以前を使用した場合の情報です。 重要なポイントはiPXE公式サイトの通りです。
http://www.ipxe.org/wimboot

iPXEを使ってiSCSIターゲット内ディスクにWindows7をインストールする方法は知っていました。 具体的には、iPXEでiSCSIターゲット内ディスクをsanhook(あるいは gpxeでkeep-san+sanboot失敗)し、 物理DVDドライブ(あるいはUSBフラッシュメモリー)を使ってWindows7のインストーラを起動する方法です。

インストーラもネットワークブートできればいいなと思い、やってみました。 iPXE、iSCSIターゲットとしてtgt、httpサーバとしてlighttpdを使いました。

以下
iSCSIターゲット内ストレージを iSCSI-DD
Windows7のDVDイメージを win7.iso
と呼ぶ事にします。

ちなみに、win7.isoをsanbootしても、インストールはできませんでした。 sanhook/sanboot の --driveについて iSCSI-DDを0x80、win7.isoを0x81等にするとインストーラが起動せず、 win7.isoを0x80、iSCSI-DDを0x81等にするとインストーラは起動するが、 インストール先にiSCSI-DDを選択したところで、 「それは無理、BIOSから見えてないから(要約)」というエラーが出てインストールできませんでした。 その他、色々やりましたorz

1.
win7.isoを用意した。ちなみに、マウント方法は

 mount -t udf -o loop /tgt/iso/win7.iso /tgt/iso/mnt/win7

といった具合です。

2.
win7.isoをiSCSI-DDと同じターゲット内の別lunに登録した。

<target iqn.2012-11.hoge.hoge:hoge>
#...
    <backing-store /tgt/iso/win7.iso>
        lun 2
        device-type cd
        readonly 1
    </backing-store>
#...
</target>

といった具合です。iSCSI-DDと別のターゲットだと、(iPXEかtgtかwin7か何かの仕様の影響で)インストール不可でした。

3.
iPXEでiSCSI-DDをsanhookし、物理DVDドライブを使ってWindows7のインストーラを起動するiPXEスクリプトを元に、 iPXEでiSCSI-DDとwin7.isoをsanhookし、wimbootを使ってWindows7のインストーラを起動するiPXEスクリプトを用意した。具体的には

 sanhook --drive 0x80 ${iSCSI-DD用root-path}
 exit

といったところを

 sanhook --drive 0x80 ${iSCSI-DD用root-path}
 sanhook --drive 0x81 ${iSCSIでのwin7.iso用root-path}

 set base-url http://tgt.or.some.server/hoge/

 kernel ${base-url}ipxetool/wimboot
 initrd ${base-url}mnt/win7/bootmgr          bootmgr
 initrd ${base-url}mnt/win7/boot/bcd         BCD
 initrd ${base-url}mnt/win7/boot/boot.sdi    boot.sdi
 initrd ${base-url}mnt/win7/sources/boot.wim boot.wim
 boot

に変更した。
wimbootの取得は
http://www.ipxe.org/wimboot こちらから。
bootmgr等、win7.iso内のファイルは、win7.isoをマウントしてアクセス可能にした。

 ちなみに、win7.isoもsanhookしているのは、インストーラは途中からiPXE経由のアクセスを止めるために一応。
 iSCSI-DDと同じターゲットなので、要らないと思いますけど。
 httpを使うのは、公式サイトの説明がhttpになってるのと、その理由はおそらく
 tftpではファイルサイズの上限が16MBか32MBで、boot.wimをとってこれないためだと思われる。

なお、http://www.ipxe.org/wimbootにあるとおり、 Windows8でも同様にして実現可能な模様。試してません。

savecredを使えない環境でパスワード入力を自動化したrunasをpowershellで実現

※2013-12-19更新

PsExec を使えばよいみたいです
http://technet.microsoft.com/ja-jp/sysinternals/bb897553.aspx
> コンピューター名を省略すると、PsExec では
> ローカル システムでアプリケーションを実行します。
ということなので、基本的な使い方は、以下の通りのようです。
psexec -u <ユーザー> -p <パスワード> <コマンド名> <引数>


[Powershellを使う方法]
標準ユーザーAが標準ユーザーBの権限でコマンドを実行したい時、
runas.exeを使えば良いが、savecredを使えない環境だと毎回パスワードの入力が必要。
以前は、runas.exeのパスワード入力を、Windows Script Hostで自動化していたが、
この方法でパスワード入力を実行している時、runas.exeが動いているウィンドウのフォーカスを
うっかり奪ってしまうと、うまくいかない。
そこで、Windows PowerShellを使ってみたところ、うまくいった。
検証環境は、Vista Home Premium 64bitで、具体的な方法は以下の通りです。

まず、次のバッチファイルを、メモ帳にコピペして、標準ユーザーAで作成した。
ただし、userb_idとuserb_pwの部分を、目的とする標準ユーザーBの実際の値に変更すること。 
パスワードを平文で保存するのが不都合なら、この手は使えません。
== as_userb_run.bat ======================================================================
@echo off
REM ####################################################################
REM ## 
REM ## 基本機能(用途)は、PowerShellを使って、
REM ## バッチファイルを別ユーザで実行すること。
REM ## ※エスケープや特殊文字の使用は非対応
REM ##
REM ## 例:
REM ##  as_userb_run.bat "C:\Users\userb\opt\mybatch.bat"
REM ##
REM ####################################################################

set id='userb_id'
set pw='userb_pw'

REM ####################################################################
REM ## [For文メモ]
REM ## For文内での環境変数が扱いにくいので、あえてifとgotoで処理
REM ## [変数メモ]
REM ##  %1: "ho ge" の時、 %~1: ho ge となり、引用符「"」があれば削除
REM ####################################################################

set arglist="'&'"
:arglist_append_start
 if x%1 == x goto arglist_append_end
  set arglist=%arglist%,"'''%~1'''"
  shift
 goto arglist_append_start
:arglist_append_end

REM ####################################################################
REM ## [powershellを2回使う理由]
REM ## 1回目: Start-Processの-Credentialで、ユーザをかえるため
REM ## 2回目: 実行演算子「&」を使い、通常の手順でコマンドを実行するため
REM ## [debugメモ]
REM ## powershellが-Commandの文字列を処理したあとも終了しないようにする
REM ## powershell -NoExit -Command ...
REM ## 
REM ## powershell 1回目でエラーをあえて起させて、コマンドラインを見る
REM ## ... Start-Process powershell errarg -ArgumentList ...
REM ##
REM ## powershell 2回目でエラーをあえて起させて、コマンドラインを見る
REM ## ... @("'-Command'","'errarg'",%arglist%) ...
REM ####################################################################

REM ## 通常
powershell -Command Start-Process powershell -ArgumentList @("'-Command'",%arglist%) -LoadUserProfile -NoNewWindow -Credential (New-Object System.Management.Automation.PSCredential(%id%, (ConvertTo-SecureString -AsPlainText -Force %pw%))) -WorkingDirectory '%SystemRoot%'

REM ## powershell 1回目でエラー
REM #powershell -NoExit -Command Start-Process powershell errarg -ArgumentList @("'-Command'",%arglist%) -LoadUserProfile -NoNewWindow -Credential (New-Object System.Management.Automation.PSCredential(%id%, (ConvertTo-SecureString -AsPlainText -Force %pw%))) -WorkingDirectory '%SystemRoot%'

REM ## powershell 2回目でエラー
REM #powershell -Command Start-Process powershell -ArgumentList @("'-NoExit'","'-Command'","'errarg'",%arglist%) -LoadUserProfile -NoNewWindow -Credential (New-Object System.Management.Automation.PSCredential(%id%, (ConvertTo-SecureString -AsPlainText -Force %pw%))) -WorkingDirectory '%SystemRoot%'

exit /B
=======================================================================================

as_userb_run.batの使い方は、例えば、

c:\> as_userb_run.bat "C:\Program Files (x86)\Mozilla Firefox\firefox.exe" -no-remote 

あるいは、

c:\> as_userb_run.bat notepad "C:\Users\userb\hoge hoge\fuga.txt"

あるいは、次のバッチファイル

as_userb_run.bat notepad "C:\Users\userb\hoge hoge\fuga.txt"

を作成し、実行する方法がある。
このようにすれば、 標準ユーザーAが標準ユーザーBの権限でコマンドを実行できるはず。

[参考]
「別のユーザーとして実行」して「管理者として実行」する。: Windows Script Programming
http://scripting.cocolog-nifty.com/blog/2010/01/post-a567.html

製作: 十字キー(ジョイパッド)付きキーボード

PCでゲーム(特にアクションゲーム)をする時、
普段使っているキーボードでだいたいこなせるが、移動操作だけは

　↑
←↓→

あるいは

 E
SDF

などによる入力では、個人的にはキツイ。
移動操作だけは、十字キー(ジョイパッド)を使って左手でやりたい。
あと、PC用ソフトでキーボード非対応は珍しいが、ジョイパッド非対応はありえる。

そこで、十字キー搭載でキーピッチ19mm(一般的な大きさ)のキーボードを
探したが、見つからないので作ってみた。
具体的には、手持ちのキーボードにプレステ(PS1)のコントローラSCPH-1080を接続し、
SCPH-1080の十字キーを操作した時も、↑←↓→が入力されるキーボードに改造しました。

主な注意事項は、以下のとおり。
・NumLockオフの時、テンキーの8426も↑←↓→なので間違えないようにする
・ハンダゴテで面実装IC等を外すとき、強引にひっぱらず、工夫する
・追加配線が、キーボード、コントローラの外枠と干渉しないか確認する




ちなみに、ジョイパッド+JoyToKeyで方向キーの入力をし、
あとは通常のキーボードを使えば同等の環境になるが、
「ジョイパッド+JoyToKey」と「キーボード」の間で
入力遅延の差が発生する可能性がある。
一方、キーボードでゲームをする場合の注意点は、
ゲーム用や高級なキーボードを除いて、複数ボタンを
同時に押すことに対応していない可能性が高いので、
こちらのHTML等でテストしてみたほうがよい。

パソコンなどのキーボードで複数のキーが同時に押打されたときに、
そのキー全てを読取れる機能をNキーロールオーバーと呼ぶそうだ。
Nキーロールオーバーではないキーボード、あるいは、
同時押しできる組み合わせに制限があるキーボードの構造は、
こちらが参考になる。

資料: SCPH-1080の基盤

プレイステーション(1)のコントローラSCPH-1080を分解した写真です。
同一型番でも、中身は違うかもしれません。

資料: SCPH-1010の基盤

プレイステーション(1)のコントローラSCPH-1010を分解した写真です。
同一型番でも、中身は違うかもしれません。

qemu-kvm: Windows VistaゲストにVNCで接続して半角全角キーを使う

qemu-kvmで仮想化したWindows Vistaのゲスト(以下、Vista)へ、qemu-kvmの -vnc オプションで有効になるVNCディスプレイ経由で接続した時、半角全角キーを使えなかった。
もちろん、VNCクライアントは半角/全角対応のVNCクライアントを使ったのに。

それどころか、CTRLキーが効かなかった。何故かCTRLキーが半角/全角キー扱い。
物理PCで動かしていたVistaなので、レジストリでCTRLとCapsLockを入れ替える設定をしてた。
この入れ替え設定が、何故か影響していた。当該レジストリ設定(Scancode Map)を消せば、CTRLキーは使えるようになった。

調べてみた所、半角/全角キーを押すと、Vistaは不明(あるいは無効)なキーが押されたと認識しているようだった。qemu-kvmの -k (keyboard layout)オプションで ja(日本語) を選択していた分もあるのか、半角/全角を除くキーは問題なく認識されていたので、不明なキーを半角/全角キー扱いしてもらうことにした。
具体的には、レジストリ設定ファイル(.reg)で表現すると、

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,02,00,00,00,29,00,00,00,00,00,00,00

という内容で、レジストリエディタのスクリーンショットで表現すると、

この通り。設定後、Vistaを再起動すれば、半角/全角を使えるようになった。

UltraVNCは公式版で半角/全角キーと日本語に対応

Windows XP以降で動作する無料VNC クライアントを使ってみた

・UltraVNC 1.0.9.6.2 (2012年2月16日リリース)
http://www.uvnc.com/downloads/ultravnc.html
公式版で半角/全角キーに対応(※4年以上前から)
インストーラを使わないZip配布もあり、管理者権限が無くても使い始めやすい。

日本語メニュー表示も可能

コマンドラインでも使える。例えば以下のとおり

> vncviewer.exe -JapKeyboard -notoolbar -nostatus -password NAISYO 192.168.0.1:1

・TightVNC Version 2.5 (2012年4月19日リリース)
http://www.tightvnc.com/
半角/全角キーに非対応

・RealVNC
VNCの本家みたいなので使ってみたかったが、ダウンロードが面倒そうなので試していない。

P2V: 物理PC(Vista 64bit) を QEMU-KVMで仮想化

P2Vツールを使わずに物理PC(Vista Home Premium 64bit)のHDDをQEMU-KVMのゲストに移してみた。

[物理PC]
マザーボード:
 M2NPV-VM (NVIDIA GeForce 6150 + nForce 430)
CPU:
 AMD Athlon 64 3500+ (コア数1)
HDD:
 SATA HDD 320GB 1台
OS:
 Windows Vista Home Premium (64bit版)

[QEMU-KVMのホストPC]
CPU:
 Intel Celeron G530(VT対応, コア数2)
OS:
 Ubuntu 12.04 LTS (64bit版)
QEMU-KVM:
 QEMU emulator version 1.0
 
最初、Vistaの設定をいじらずにHDDをゲストに移すとどうなるか試してみた。
ただし、Vista起動中にエラーが発生した場合、自動再起動す設定だとエラー表示を見れないので、物理PCでVistaを起動して、
コントロールパネル-システムの詳細設定  > 起動と回復-設定 > システムエラー にある
[v]自動的に再起動する
を
[ ]自動的に再起動する に変更してからHDDをddでHDDイメージを作成した。
QEMU-KVM ゲストの設定は、virt-managerのウィザードに頼った。(OS:Vista, CPU:2個, Arch:x86_x64)

QEMU-KVM ゲスト上のIDEにHDDイメージを接続し、ゲストを起動してみた。

(10行ぐらいエラーメッセージ)

*** STOP: 0x0000007B (以下略)

というエラー表示で固まった。私の物理PCでは、Vista上での準備が必要みたい。
 
QEMU-KVMがシミュレートするIDEコントローラは、通常、Intelの82371SB PIIX3らしい。
このコントローラ用のドライバのようなもの(Service)について設定変更したところ、起動できた。
具体的には、レジストリの編集(regedit)で
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\intelide にある
Start の値が
4
だったので
0
に変更してからddでHDDイメージを作成し、QEMU-KVM上のIDEに接続してゲストを起動したところ、Vistaを起動できた。
初回起動は5分ぐらいかかりました。2回目以降は2分程度でした。
CPUを指定したりvirtioドライバをインストールしたりしてるうちに30秒程度で起動できるようになりました。
virt-managerのウィザード設定どまりだと、遅いみたいです。

Web情報*によりますと、CPUのコア数がシングル(1)<=>マルチ(2以上)の間で変更する場合、 XPではHALについて何か設定がひつようみたいですが、 少なくともVista 64bitでは不要みたいです。 ただし、Home Premiumエディションだからだと思いますけど、 ソケット数ではなく、コア数でゲストへのCPU割り当てを増やす必要がありました。

検証内容
・ゲストのCPU:2個(sockets=1,cores=2,threads=1)に設定し、Vista起動
  CrystalMark2004R3:ALU=24773,FPU＝22409
  シャットダウン
・ゲストのCPU:1個(sockets=1,cores=1,threads=1)に変更し、Vista起動
  CrystalMark2004R3:ALU=13005,FPU＝11644
  シャットダウン
・ゲストのCPU:2個(sockets=2,cores=1,threads=1)に変更し、Vista起動
  CrystalMark2004R3:ALU=12863,FPU＝11206

 参考：
 http://stakasaki.at.webry.info/200702/article_2.html
 [Vista] OS再インストールなしにマザーボード交換Vista編　速報版 ハマる生活/ウェブリブログ

 http://d.hatena.ne.jp/moriyoshi/20091116/1258368163
 VMware Server 上で利用している Windows XP のイメージを KVM に移行する際、ブルースクリーン (0x0000007B) が出てしまう問題への対処法 - muddy brown thang

 http://wwwwayanwww.blog100.fc2.com/blog-entry-91.html
 永久無料のWeb日記★ミ  VISTAｽｹﾞｪw(ｼﾝｸﾞﾙｺｱからﾃﾞｭｱﾙｺｱへのCPU交換)

 http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers
 Windows VirtIO Drivers

TikiTiki ADSLコースACプランからeAプランに変更

TikiTikiインターネットのADSL(プラン1・固定電話あり)サービスで、
ACプラン12M(SP)から、eAプラン12Mへ移行した記録です。
最大6ヶ月(実質5ヶ月)割引のキャンペーンは適用されました。

2011年
8/31 Webでコース変更(実質はプラン変更)を申し込み
9/1 メールで「【TikiTikiインターネット】TikiTikiADSLコース申込受付のお知らせ」到着
9/5 郵便で詳細な連絡到着
9/6 メールでイー・アクセスから「【イー・アクセス】お申込受付のお知らせ」到着
9/7 メールでイー・アクセスから「ADSLサービスNTT工事予定日のお知らせ」到着
　・NTT工事予定日：平成23年9月16日　在宅不要
　・ADSL利用可能日：上記NTT工事予定日の翌営業日
9/9 郵便でイー・アクセスから9/7と同じ連絡到着
9/9 郵便で年払いの請求書到着
9/14 eAプラン用のモデム到着
9/16 9:30頃 ACプランの接続はまだ使えた
9/16 10:10頃 ACプランの接続が途切れていた。eAプラン用のモデム交換したら接続できた。
　　 ACプランのレンタルモデムを指定の場所へ元払いで返送した。

M2NPV-VM の NVIDIAドライバを更新したら、サーバソフトが接続を受け付けなくなった問題の解決事例

http://www.nvidia.co.jp/object/nforce_vista_win7_64bit_15.49_jp.html
nForce Driver / 15.49 WHQL
2009.10.01 Windows Vista 64-bit

こちらの(現行)最新ドライバーを標準設定でインストールしたら、
スリープ/休止 からの復帰に失敗しなくなった気がするが、
「ローカルPC→ローカルPC」TCP/IP接続で利用していたサーバへの接続が不可になってしまった。


コントロールパネルから、
「NVIDIA ForceWare Network Access Manager」
を削除したら、接続可能になった。

家電リサイクル大阪方式でエコポイントの申請を実行

エコポイント半減が発表された直後に通販でテレビを買い、
古いテレビをリサイクルに出してのエコポイント申請をした。

http://www.pref.osaka.jp/shigenjunkan/recycle/riyou.html
大阪府(自治体)のWebサイトに、最も一般的な「RKC(財)家電製品協会」の家電リサイクルとは異なる、
「家電リサイクル大阪方式」という家電リサイクル方法が案内されており使ってみた。

結果としての利点は、

• リサイクル料金が安い(テレビの場合、1155円差/台)が、エコポイントの額は同じ
• リサイクル料金を郵便局で前もって支払ってから、収集運搬申し込み or 指定場所に捨てに行くという二度手間が不要

と言う事だった。

http://www.orbc.jp/kaden-OSK.html
こちらの申込専用電話にかけて申し込むと、申込者が少ないのか、その当日にこちらが指定した時刻に回収しにきてくれた。
その場で収集運搬代(私の場合、1500円/台でした)＋リサイクル料金(テレビ1680円/台)を
現金で支払って、伝票(エコポイント申請に必要な「排出者控え」を含む)に署名をして完了でした。

先日、この「家電リサイクル大阪方式による排出者控え」を利用してのエコポイントが発行された。
大阪府が案内しているぐらいだから、大丈夫だとは思っていたがマイナーっぽかったので少し心配でした。