検索条件
タグで絞り込み
Hardware(3)
Hardware::NetworkSwitch(1)
Hardware::Raspberry Pi(1)
Hardware::ThinkPad(1)
Software::Linux(68)
Software::Macintosh(5)
Software::VM/ESXi(6)
Software::Windows(94)
2008/10/12(Sun)Vistaの管理共有にアクセスする
2008/10/12 3:20
Sambaネットワークでは、共有名の末尾に$を付けると隠し共有となって、一覧に現れないのだが、管理目的のためデフォルトでドライブレター＋$という名前で、全固定ディスクのルートディレクトリが共有されている。
つまり、コンピュータ名をワークグループで見つけられれば、\\ComputerName\C$でCドライブが丸見えと言うわけだ。
勿論、セキュリティ的には保護されていて、管理者権限がないとアクセスできない。
Administratorのパスワードが空だとドライブ丸ごとがそのまま見えたりということもあり*1、やはりセキュリティ上の観点からか、Vistaではローカル以外からは、たとえ管理権限を持っていたとしても参照できなくなったようだ。
というわけで、再度自分でドライブごとに共有を作る*2しかないかと思っていたのだが、やはり面倒。
閉じた家庭内LANなどでファイルをやり取りする場合は、やっぱりドライブごと共有していた方が楽ということもある。
そういうときには、このレジストリエントリを追加すれば良い。
手早くやりたい人は、share_policy.regをどうぞ。
- キー名
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
- 名前
- LocalAccountTokenFilterPolicy
- 種類
- DWORD(32ビット)
- 値
- 1
2008/09/24(Wed)MTPモードのトラブル
2008/09/24 16:18
MTPはMicrosoftが開発した技術仕様で、それぞれのデバイスドライバを必要することなく、マルチメディアデータを標準インストールされているWindows Media Playerで転送することが出来る。DRMもサポートしていることから、マスストレージモードを搭載していない物などにもこのモードがあることが多い。（パナソニック等の製品にはSD-Audioという規格があり、これとは別。）
非常に便利なMTPモードであるが、Windows Media Player絡みのアップデートでうまく動作しなくなることがあるようで、実際に私がハマったので、そのトラブルシュートをご紹介。
現象
Windows Media Playerからは同期デバイスとして認識せず、デバイスドライバでは！マークが表示されている。（IEEEコントローラが×になってるのは、ノートPCの消費電力削減のため、給電を停止しているからであり、本題とは関係ない。）
「ドライバの再インストール」を選んでみると、一見インストールが成功したように見えるのだが、最後に「このINFのサービスインストールセクションは無効です。」と難しいエラーメッセージが表示される。
解決方法
先ほどもちらっと書いたように、これはWindows Media Playerをアップグレードしてしまうと問題が起こる模様。色々とググってみたところでは「XPの修復インストールで直った」という情報が出てきたが、さまざまな部分が元に戻ってしまうのでこれは避けたい。
半ば勘に頼ってだが、私の場合は、WMAのエンコーダーに同梱されていた「Windows Media Format 11 runtime」をインストールしてしまったのが原因らしい。
Windows Media Player 10を使っているのに、11用のランタイムを間違えてインストールされてしまったのが原因かな？
Windows Media Player 11を使ってる人はこれをアンインストールしていいのか良く分からないが…。
▼これをアンインストール
メッセージに従って、どんどん進む。
チェックをつけて続行。ここのメッセージによると、保護されたファイルのライセンスは削除されるので再度取得せよ、とのこと。私はDRM保護されたファイルは管理していないので問題なし。
ここで再起動
仕上げ
この段階ではトラブルを起こしているドライバが読み込まれているので、デバイスマネージャから一旦問題のデバイスを削除する。それから、USBケーブルを挿しなおし、今度は認識されることを確認。
2008/09/14(Sun)screenでデタッチできない 解決編
2008/09/14 21:21
デタッチできないというよりも、むしろアタッチできないという方が正しい表現だったようだ。
これはscreenの問題ではなく、回線が切れたときにsshセッションが切れず、sshdプロセスが生きたままで、その応答待ちでscreenがattachedから変化しない模様。
以下、対処法。
$ ps x | grep pts | grep sshd
13819 ? S 0:00 sshd: kero@pts/2
13985 ? S 0:00 sshd: kero@pts/8
14595 pts/2 S+ 0:00 grep sshd
grepが走っているpts/2が現在操作中のポートなので、pts/8を落とす。
$ kill -KILL 13985
$ screen -ls
There is a screen on:
9120.pts-0.spinel (Multi, detached)
1 Socket in /var/run/screen/S-kero.
$ screen -r
これで自動的にdetatchされ（autodetatchがonの場合）再アタッチ可能になる。が、いちいちこんな事やるのが面倒なので、自分以外のsshセッションを片っ端から強制終了するスクリプトを書いてみた。
最近Perlの正規表現にハマってたりなので…。/bin/sh+sedかawk…と思いつつも、慣れてる方が書きやすい。
screenの内側から実行しないように注意。
#!/usr/bin/perl
use strict;
(my $tty = `echo -n \$SSH_TTY`) =~ s/\/dev\///;
my $dead = `ps x | grep pts | grep sshd | grep -v $tty | grep -v grep`;
foreach(split(/\n/, $dead)){
$_ =~ s/^\s*(\d+).+$/$1/;
print qq|Kill pid=$_...\n|;
`kill -KILL $_`;
}
参考元:http://subtech.g.hatena.ne.jp/cho45/20070517/1179373075
2008/09/13(Sat)バッチファイルで時計表示
2008/09/13 17:56
とまぁこれが、結構面倒で^^;
time /Tコマンドでは、秒まで出てきません。
秒は%time%という変数を使うことまで1/100秒単位までご丁寧に出てくれるのですが、
で、これを使わざるをえないことに。
結構XPだったり2000だったりで出力に差があるらしいのですが、ここはXP x64 SP2ベースで書きます。
自分の場合は、24時間制で0補完済みの2桁ごとで区切られた数が得られたので、「あぁ、substringかけるだけじゃん～」と思ったら……
実は厄介でした。0の扱いが。
先頭に0がついた、06といった数字は、8進数の6を表すような解釈をするらしく、秒の部分だけを切りだして変数に入れる(set /aでは式の評価が行われる)と、システムの時計が8秒と9秒のとき、"無効な数字です"と文句を言われます。
というわけで、結構苦肉の策。
@echo off set n=-1 :LOOP set /a t=%time:~6,1% if %t% == 0 (set /a s=%time:~7,1%) else (set /a s=%time:~6,2%) if %s% == %n% goto LOOP set /a n=%s% echo %time:~0,8% goto LOOP実行結果
17:53:40 17:53:41 17:53:42 17:53:43 17:53:44 17:53:45 17:53:46 17:53:47 17:53:48 17:53:49 …もっとスマートに書けるのかもしれんが……。あぁ、とりあえず外部アプリのsleep.exeとか、JSを開く手はナシで。
ちなみに、ping -n [止めたい秒数] localhost >NULという書き方も紹介されてましたが、なんか1秒置きにうまく動いてくれませんでした。
まったくもって、Linuxのbashは賢すぎる。
あっちなら
echo -e "`date "+%Y/%m/%d %H:%M:%S"`"なんて手軽に書ける。曜日や"1日前"、なんてのもお茶の子さいさい。
あぁ、こんな表現使うの久々…（笑）
2008/09/12(Fri)BSOD 0x35 NO_MORE_IRP_STACK_LOCATIONS with KIS 解決法
2008/09/12 21:20
この話がマイナーな事を考えると、Windows XP x64 SP2限定の話で、x86には全く関係ないのかもしれない。
MSKBを探し回った結果
0x35エラーが引っかかったが、ドメイン参加ではないのでドメインにログオンしようとすると、「 STOP 0x00000035 NO_MORE_IRP_STACK_LOCATIONS」エラー メッセージを表示することがあります。は関係ない。SP2も適応済みであり、mup.sysのバージョンは公開されているパッチよりもずっと新しかった。
Kaspersky Laboを探しまわった結果
このエントリが引っかかって、I should also mention, I tried changing HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Klif Start key to 2 (currently still set that way), and that did not help. I then added to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters an IRPStackSize key, started at 15, ran it up to 50, but that also did nothing.というのがあったので、ダメ元で、
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\KLIF] "Start"=dword:00000002に変更。元々は、
"Start"=dword:00000001でした。
このStartの値が何を示すかというのは、MSKBによると0x01の方が0x02よりローレベルな段階で起動する模様。
ゆえに、エラーが起こった時はKernel Panic=BSODとなるわけですか…。ふむ。
とりあえず、結果からいえば、これで直った。
この変更を加えても、一応Firewallは正常に動作しているようで、未定義のルールについてはちゃんと警告出してきているし、Sambaのやり取りも問題なくなった。
一件落着。
今回はBSOD系のエラーでも、すごくマイナーな物だったから余計に苦労したな…。
追記
x86にKIS7をインストールしている場合でもStart=0x01だが、こちらはBSODにならない。ということは、x64環境の場合だけの問題のようですね。
追記
しばらく使ってたら、また青くなった。今度は、ここを変更してみた。
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kl1] "Start"=dword:00000002現状とりあえず安定しているようなので、↑でダメだった人はやってみてください。