変奏現実

パソコンやMMORPGのことなどを思いつくまま・・・記載されている会社名・製品名・システム名などは、各社の商標、または登録商標です。

この画面は、簡易表示です

使用上の制限が多いF-35

接近戦で死角が存在しないとも云われるF-35のHMD。
だがF-35の機体は、『長距離から敵機をキルすること』を念頭に開発が進められていたので、接近戦とくにドックファイトなぞ眼中に無く、実際ドックファイト専用機のF-16との模擬戦であっさり撃墜されている。
そのドックファイトの結果、低速で緊急脱出シートを使用することになると、パラシュートが開いた時にHMDごと首を強く後ろに引っ張られるそうで、首を折るなどの大けがまでしてしまう可能性があるらしい。
このため、パラシュート展開時にパイロットの頸椎部分が後方に折れ曲がれないようにパイロットの首の後方部分に支持材を入れるなどの対応策を講じることを検討しているようだが・・・
そうなると、後方の敵機を視認するのはとても難しそう(現状でも振り向くのはかなり難しいらしい)で、さらにドックファイトには向かない戦闘機になりそうだ。
という訳で、
F-35に出会ったら、とにかくスピードを上げ、距離を狭めつつ、右へ左へと大きく逃げ、相手のパイロットが重いHMDをめーいっぱい振り回させ、首を疲れさせるのが一番の様だ。
そして、君が強引な右旋回で回り込もうとすると、F35のパイロットはハイスピードヨーヨーでサッと後ろを突こうとして首を痛め、引き分けに持ち込めるかもしれない。
もっとも、
ゲームの中でなら緊急脱出シートを使用してもGはかからないし、HMDも軽量で多少振り回してもそうそう首を痛めることは無いので、
F-35は無敵なんだろうね。
しかしCGの描画ラグによる3D酔いにかかると、しばらく安静にするしかないので気を付けよう。
妙な脂汗が出てきたら要注意である。
某国のステルス戦闘機J-20は「F-22やF-35より性能が上」という情報もあるが・・・
いづれの第5世代の戦闘機に

  • 自分が優位な状況ではいつでも優位だと思いこんでいる。
  • 不利な条件では前世代の戦闘機にすら不利なのにキニシナイ。

という自己中的な特性が強く、

  • 対F-35専用という感じで的を絞ればJ-20の性能の調整もしやすい

のと同様に

  • 対J-20専用にリファインした安価なF-16やF-16XLを引っ張り出してくるだけで十分かもしれない。

つまり、

  • 遠距離:J-20 >> F-35 >> F-16
  • 接近戦:F-16 >> F-35  >> J-20

なのだから、
某国の十八番の人海戦術で
接近戦に持ち込んでしまえばF-16が一番強いので、
本当に戦闘がはじまったら「旧式の戦闘機の大量投入」が主軸になるんだろう。
それでも、おんぼろのF-4が乱入することはないと思うが、どこかの国のF-15が割って入ることはあるのかもしれない。
ま、いづれの第5世代の戦闘機も無駄な出費でしかないのだな。



ソリティア

ある記事を読み
最近ソリティアをやっていないことを思い出した。
20160204-1
完全に忘れていた。
そして1年の稼働日数の平均は243日だそう。
だから、昼休みの1時間をソリティアに費やすと243時間にもなる。
もっと他のことに費やした方がよさそうな気がした。



スティック型PCの次はACアダプタ型PCの次はACタップ型PC?

小さいデスクトップPCの代表格はLIVAやNUCだが、今はスティックPCの方が圧倒的に小さい。
しかし、いくら本体が小さくても付属のACアダプタは結構大きい。
去年の6月ごろにACアダプタにPCの本体機能を入れたACアダプタ型PCの記事があり、Windows10の発表と同時に発売の予定だったらしいのだが、その後、全く音沙汰がない。
色々想像してみると・・・

  1. ACコネクタの形状が国によってマチマチ、日本版ならそのまま日本のACコンセントで使えないと様にならない。
  2. 大容量の電源を供給できるUSBのC-Type(だったかな?)も出て、micro-USBで電源供給する方法からUSB-C-Typeへの終わりの見えない移行期に入りつつあるから、今まで通りのmicro-USBや青いUSB-3だけ付いているといつかは急に売れなくなる日がやってくる可能性があるのだ。なので、本格的にUSB-C-Typeに移行しだした後に出した方が安心だと思うが、USB-C-Typeのコネクタが付いたスマホが出だした後なら、「1つUSB-C-Typeのコネクタ」を付けて売り出すのも悪くない気がする。
  3. CPUや電源部は、どうしても温かくなりがちだ。スマホを充電するときのACアダプタは結構暖かいので、ACアダプタ型PCにスマホを充電させると、ポッカポカになりそうだ。
  4. 見えないところに隠してある電源タップにACアダプタ型PCを挿すとLANやHDMIやキーボードなどのケーブルがにょきにょきといっぱい生えてくること。それならいっそスティック型PCをUSBハブに見立ててモニターの脇に配置した方がすっきりするかもしれないので、WIFI経由でできるだけ無線方式で繋ぐ様にした方がよさそうだ。HDMIも無線式にできるならその方がいいだろう。

と、コンセプト自体はいいけど、実際使うとなると、意外な不都合な点がポロポロと露見したのかもしれない。
また、ACアダプタ自体、かなり小さいものも出回っているので、今はこれにスティック型PCを挿すだけで十分かもしれない。
そしてどうしても逃れられない問題点が1つある。
一見するとACアダプタとACアダプタ型PCが見分けが付きにくいのだ。
デザインが気に入った新しいACアダプタを買ってきたときに、完全な無線接続を実現したACアダプタ型PCをうっかりゴミ箱に捨ててしまったボクが・・・そのうち自然発生しそうな気がした。(大笑
そうならないためには、ACタップとACアダプタ型PCをケンジントン・ロックで繋いでおかないといけないかもしれない。
もちろんロック・ケーブルにはPCと書いたシールを付けた方がいいだろう。
しかし、そこまでしても
何かのイタズラだと思うような気がする。
そして、もしACアダプタ型PCにサービス用のACコンセントが付いていたら・・・
目についたそのACコンセントに

  1. 掃除機を繋いで、部屋の掃除をしようとする気もする。
  2. タコ足配線をしてしまうかもしれない。
  3. ・・・

そう考えると
サービス用のACコンセントをつけるなら・・・
ACタップ型PCの方がいいのかな?
タップの使用電力も計測してくれそうだし・・・
外付けUSB-HDDやプリンタやモニターの電源も一挙に解決しそうな気がする。
だがしかし、ACタップとACタップ型PCはもっと見分けが付きにくいような気がする。
デザインが気に入った新しいACタップを買ってきたときに、完全な無線接続を実現したACタップ型PCをうっかりゴミ箱に捨ててしまったボクが・・・そのうち自然発生する確率はもっと高そうな気がした。(大笑



yum uptate, reboot, Kernel halt

この前の3.10.0-327.4.5.el7は、ちょっと不調だった。
virsh console で覗いても login: が出てこない。
virsh start の後、すぐに virsh consoleでコンソールに起動ログを流してみると
最後に
[+] xxxxxxxxxxxxxxxxxxxx
[+] xxxxxxxxxxxxxxxxxxxx
[+] xxxxxxxxxxxxxxxxxxxx
で終わっていた。
カーネルがフォルトしているようだった。
何度リブートしても同じ。
こういう時には
いつも頼りにしているCentOS系のサイトがつながらなくなっていた。
同じオチに引っかかっているのかもしれない。
なので、適当に・・・

  • GRUB(ブートローダ)らしき文字が映っている間に
  • ↓を押して、1つ前の4.4.el7で起動してみたら
  • うまく起動できた。

しかし、こんな時にも遥々中東からログイン画面を周回している奴が来て、コンソール画面は、あっと云う間に[IPTABLES INPUT] : IN=eth0 OUT= MAC=xxxxのログで埋まってしまう。ルータからの接続を切ってから調整した方が良いだろう。
一旦、4.4.el7でゴミ掃除をしてもらうため、1分ほど経ってからreboot したら
メデタク4.5.el7で起動できた。
メデタシメデタシ?
こんな時にはいつもお世話になっているサイトが「安全ではない接続」のページになっていた。
ここのBLOGはどんな風に観えているのだろう?
「怪しいサイト」かな?
んー
それは年中そうなっている気がする。
数分後、いつもお世話になっているサイトはいつも通り見ることができるようになった。
メデタシメデタシ
いやそうではない。
大体 両方のサーバーが 同時に yum update やってハマルということが起きる訳がないのだ。
おそらく0時0分に偶然再起動したのだろう。
偶然その時に覗いたので、偶然同じような不調な画面になっていたのだろう。
起動直後はSSLサービスも起動中で「安全ではない接続」かのように見える状況も起きうるのかもしれない。
だから、安定した今ならちゃんとサイトのページが見えるのだ。
メデタシメデタシ
んん。サイトの地球マークは灰色だ。
マウスでなぞると「このWebサイトには運営者を証明する証明書はありません。」
ではさっきの「安全ではない接続」ページへリダイレクトしたのは何だったんだろう?
 
謎は深まるだけだった。
(この項、終了



MVNOに変えたその後

去年の年末に長らく(15年ぐらい)使用していたDOCOMOをIIJに変えました。
一気に月額料金が下がったものの、12時~13時の間や夕方6時頃にアンテナマークが消える様になりました。
SO-04EのWifiテザリングはバッテリーの消耗が激しく、アンテナマークが消えると電波を必死に探すのだろうか?もっとひどくなるので、ASUSのME572CLは別回線。
2回線にしたせいか、2月1日時点での残量はSO-04Eが8GB、ME572CLが6GBと、契約の2倍。1月分がすべて引き継がれているかっこうだ。
さっぱり使っていない訳ではない、動画はまず見ないが、ゲームは(ほぼAUTOだけど)1日数時間くらいやっている。
もっとも、12時~13時の間や夕方6時頃に通信できないのが通信量が少ない主原因かもしれない。(大笑
一方で、2月からDOCOMOの0円携帯が消えるらしい。つまり割引額が減るのだそうだ。
見逃したのか?継続中のスマホの通信料金が安くなるという文字は見当たらなかった。
ま、新規やMNPの割引額が減るから・・・これからは値段が高いiPhoneには逆風?・・・それとも元々人気も高いiPhoneだから影響が少ない?
とりあえず、ボクのように値段が高いのでiPhoneが買えない人はいつまで経っても買えないが、好きな人は多少高くても毎年新iPhoneを買うだろう。だって、楽しみなのだから・・・
で、重要なのは、その比率。
 
で、どうなんだろうね?興味深々?んー
スポーツは観戦するもの。
でも、スマホのコレは、
iPhoneかAndroidかその他(WindowsMobileなど)のどれかを買って参加できるゲームになっている様な気がする。
ほどほどに一方が勝って、ほどほどに一方が負ける分には
自分は困らないので
勝敗はどうでもいいのだ。(大笑



Logitec LBD-PMK6U3VRDで録画BD鑑賞

ポータブルBDドライブ(USB-3)、上面が赤。
手持ちのLDR-PME8U2LRD(ポータブルDVD)とほぼ同じ形状、AmazonでWinDVD付きモデルが7Kぐらいだったので購入。
手持ちのDVDはUSB2、届いたBDはUSB3なせいか、コネクタの形状が違っていたので、物理的にケーブルの使いまわしはできない。
先月購入したUSB-HDD(3TB)もUSBコネクタがこのBDと同じ形状だったから、USB3同士は使いまわしができるのかもしれない。
で、そのBDに添付のWinDVDの再生ボタンを押すと
現在のディスプレイドライバを使用した再生はサポートされていません。
適切なディスプレイドライバにアップデートしてください。
とエラーメッセージを出し始めることがあり・・・一旦表示すると、何度再生ボタンを押しても同じ。アプリを起動しなおしても無駄。
再起動やUSBコネクタの切り替えをしていると・・・なんとか観れる時もある程度かな?
メディアのせいか?
25GBなら大丈夫?
50GBは無理?
そう思ったが、あれこれ入れ替えてみたが、同じメディアを入れ直しても、観れたり観れなかったりするのでメディアとの相性は確認できなかった。
しかし、これでは使い物にならないので、
「エラーメッセージの内容」に一番近いものを探してみる。
モニターの陰に、
ずーっと繋げっぱなしになっていた
ELECOM製モニター切替機KVM-DVHDU2
があった。
PC2台でマウス・キーボード・モニター一式を切替える装置だ。
この切替機は両方のPCからは接続中のままに観える(エミュレート)様になっている。但し、マウス・エミュレートはLogicoolのマウスと相性が悪かったのでOFFってあった。
今回は切替機経由でモニターのDHCPの信号を送り出していることをWinDVDが見破ったのかもしれない。WinDVDからすればPCとモニターのケーブルの間にある装置ば「怪しいモノである」という風に考えても致し方ないだろう。
だが、切替機のモニターのエミュレート機能を外す方法は見当たらないし・・・
それに、他のPCは皆HDMI接続に切り替えているので、切替機自体がもう不要になっていた。
重いケーブルをゴソっと音を立てて外してみると
なんとなく安定してきた。
が・・・
もう少し様子を観た方がよさそうな気がする。
しばらくすると
また
現在のディスプレイドライバを使用した再生はサポートされていません。
適切なディスプレイドライバにアップデートしてください。
と呟きだした。
どうやら、
WinDVDが再生を開始する時に
モニターが複数繋がっていると
機嫌が悪い・・・
 
らしい。
 
ここまでくると
本当にディスプレイドライバの問題なのかもしれない。
RADEON  ドライバ: Crimson   15.11
もっと新しい15.12もあるが、
インストーラーの発行元: 不明な発行元
ということで、Windows SmartScreenで弾かれてしまうが、
Windows SmartScreenの画面に【実行】ボタンが出てくる時もあり、このチャンスにインスト。
しかし、これでもダメ。
ついにBIOSでiGPUつまりCPU内臓のGPUをOFFからON!
マザボの内臓GPUのHDMI出力をHDMIの切替機に接続しモニターに表示した状態でWinDVDでBDを再生させてみたらBDが観れるようになった。
その後、HDMIの切替機はRADEONの方に変え再起動した後でも観れる。
もしかしてiGPUをOFFにしてると不調なのかもしれない。
しかし、それではGPUを内蔵していない一部のINTEL製CPUは残念なことになりそうな気がする。
ただ、Windows10ならデュアルモニター接続でも、DHCP対応ならメイン、サブどっちのモニターでもOKなのは地味に嬉しい。
【総括】
BDの利用者が少ないとか複層のBDメディアが高いとかの前に
「BDドライブをつないで視聴アプリを入れればすぐにみられる。」
とお手軽にBDを視聴できる訳では無い事がことが今回で判明した。
そう、ボクの場合、BIOSでiGPU-【ON】で済んだが、
誰もが同じ方法でメデタシメデタシとなるとは限らない!
ボク自身も・・・
「最初はNoPloblem」⇒暫くしたら例のメッセージが出る
⇒「再起動すればOK」⇒暫くしたら例のメッセージが出る⇒「再起動してもNG」
⇒「USBを挿し替えればOK」⇒暫くしたら例のメッセージが出る⇒「USBを挿し替えてもNG」
⇒「モニターを1つにすればOK」⇒暫くしたら例のメッセージが出る⇒「モニターを1つにしてもNG」
⇒「CPU内臓のGPUを使えばOK」⇒例のメッセージが出ない
⇒「iGPUを有効にしてアプリがCPU内臓のGPUを使えるだけでOK」⇒例のメッセージが出ない
と数日かけて手順を踏んだ結果なのだ。
第一、PCでBD観るのにこんなに試行錯誤するなんて面倒すぎ!
第二、後何日か経たら「iGPUを有効にしてもNG」にならないとも限らない。
だから
WindowsでBD視聴アプリを見送ったんじゃないかな?
と思った。
だって「観れない!」「観れない!」「観れない!」ってクレームが出ても、ざーっとチェック項目がアチコチに散らばり過ぎ。
CPU、マザボのBIOS設定、ディスプレイドライバーという名前のビデオカードのドライバーのアップデート、モニターのドライバー、設定 etc   etc
一般ユーザにこれらチェック項目を全部見直させるなんて・・・
無理に決まっている!
部屋で溜まった録画BDをお手軽に観たいなら、安定のPS4もいいですが、同じHDDレコーダをもう一台なら操作方法も同じなのでもっとお勧めですね。
それでも部屋のPCで観たい?
そうですか・・・(汗
御幸運をお祈りいたします!
ps. 2016/1/28 とりあえず問題無く視聴できている



【svn】sync sync sync

svnadmin hotcopy で自動ロック付きで最新版をコピるのもいいけど、
リポジトリィを作ってから数年も経ったらsvnsync コマンドで、日々リポジトリィの差分アップデートする方がいいだろう。
hotcopyの処理時間が年月と共に大きくなりすぎた頃に思い知らされるだろう。
リポジトリィの2重化と同期が手早くできるなら、スタンバイ側をsvnadmin  dump で履歴をしっかり取ればもっと安心だろう。
世の中は既にsvnからGitに移り変わっている。
Gitは、いくつものリポジトリィを繋いで運用するのが前提になっているので、コーディング中、テスト中、αやβのリリース、最後にRCとフォークし、別々の担当者がバラバラに履歴を運用しやすくなっているのだろう。
これに対してsvnは基本は1リポジトリィで、リポジトリィ間の操作と云えばバックアップや負荷分散などでリポジトリィを一気にコピートする程度の機能しかないから、複数のリポジトリィを運用するには、十分に注意が必要で、プロジェクトの各担当者に仕事を割り振り、自主的にコミットさせてしまう・・・と、スケジュールの遅延次第では、新旧未来の状態が混在し、容易にはリポジトリィにタグを付けられなくなるから、バブルフローな仕事のやり方をしなければいけない。
こう書いてしまうと、忙しいご時世だからsvnはもう終わってると思えるだろう。
しかし、Gitも所詮は履歴管理システムであり、マメにリリースを管理できる人が必須な要員であり、ザルでソロな管理人には無用な長物。Gitに毛の生えた程度のEclipseのローカル履歴とsvnの組合せで十分だったりする。(大笑
 
 
 
 
 
 
 



LC_CTYPE: cannot change locale (ja_JP.UTF-8): No such file or directory

yum で update 中に落ちた。
起動後にupdateしなおしたものの

-bash: warning: setlocale: LC_CTYPE: cannot change locale (ja_JP.UTF-8): No such file or directory
-bash: warning: setlocale: LC_COLLATE: cannot change locale (ja_JP.UTF-8): No such file or directory
-bash: warning: setlocale: LC_MESSAGES: cannot change locale (ja_JP.UTF-8): No such file or directory
-bash: warning: setlocale: LC_NUMERIC: cannot change locale (ja_JP.UTF-8): No such file or directory
-bash: warning: setlocale: LC_TIME: cannot change locale (ja_JP.UTF-8): No such file or directory

運悪くLC系のアップデート中だったらしい。
CentOS6の様に i18n でゴニョしようとしても
# cat /etc/sysconfig/i18n
cat: /etc/sysconfig/i18n: そのようなファイルやディレクトリはありません
なので、そうすれば古い仕組みで見かけ上うまくいくかもしれないけど・・・
# locale -a  や # grep ja_JP はそれなりに動作するが
# locale -a | grep ja_JP などとすると
LC_CTYPEが使えないせいで、上のメッセージだけ表示して中止。
同じ理由なのだろう。
poweroff しても
電源が落ちない。
コレではマズいので
/usr/share/i18n/locales に ja_JPなどが多数あったので
# localedef -f UTF-8 -i ja_JP /usr/lib/locale/ja_JP.UTF-8
してsetlocaleを使っているプログラムなら大丈夫のハズだが・・・
SSHで接続すると、まだwarningが2つ出てしまう。
ググってみると、glibcのリンクがまだイカレている可能性があるようだ。
yum install glibc-common してリンクを修正させた後に
localedef -f UTF-8 -i ja_JP ja_JP
するとやっとwarningが消えた。
poweroff
で電源も落ちた。
これでいいハズ。
なぜシェルからコマンドがうまく動作しなくなったのか?
原因はLC_CTYPEなどを使ってメッセージを日本語にできる仕組みを組み込んでいるプログラムの場合、自分のプログラムミスでLC_CTYPEでエラーが出た場合を想定して上のエラーメッセージを出し throw させているんじゃないかな?
なので、トリアエズ日本語にするのはいいけど、
どんな仕組み(実装)なのか判っていないと、
何気に見えないところでコマンドが通らなくなっていたりすると、ヤバすぎだね!(汗
 
 
 
 



【subversion】リポジトリィ操作

svnadmin  –help を参考。

  • 空のリポジトリィを作る
    • 使用方法: svnadmin create  <リポジトリパス>
    • 例: svnadmin  create  /var/www/RepoA
    • ※リポジトリィパスの自分のディレクトリィは作成してくれるが、その親ディレクトリィは作成しない。
    • –bdb-log-keep ログファイルの自動削除を無効 を付けると吉(らしい
  • リポジトリィのバックアップを取る
    • 使用方法: svnadmin dump  REPOS_PATH
    • 通例: svnadmin dump  /var/www/RepoA > backupRepoARevNNN
    • –incremental 直前のrevからの増分をダンプ
    • -r LOWER  –incremental   rev.LOWERからの増分をダンプ
    • -r LOWER:UPPER  –incremental   rev.LOWERからrev.UPPERまでの増分をダンプ
  • リポジトリィにdumpイメージを追記する
    • 使用方法: svnadmin load  <リポジトリパス>
    • 通例: svnadmin load  /var/www/RepoA  < backupRepoARevNNN
  • 応用例: リポジトリィを合併する
    • svnadmin dump /var/www/RepoA | svnadmin load /var/www/RepoB
    • ※似たようなプロジェクト構造の場合、ごった煮になる。
  • 応用例: リポジトリィを空にする
    • rm -rf <リポジトリパス>
    • svnadmin create  <リポジトリパス>

・・・以下、動作未確認・・・

  • リポジトリィの高速コピー
    • 使用方法: svnadmin hotcopy  <リポジトリパス> <新しいリポジトリパス>
    • 例: svnadmin hotcopy  /var/www/RepoA  backupRepoARevNNN
    • ※バージョンやOSで実装の差があるのでデイリーバックアップ向け
  • リポジトリィの修復
    • 使用方法: svnadmin recover <リポジトリパス>
  • リポジトリィのコミットメッセージの誤字脱字などを修正する(ファイルから読む)
    • 使用方法: svnadmin setlog <リポジトリパス> -r <REV> <ファイル>
    • 例: svnadmin setlog /var/www/RepoA  -r 1234  msg.txt
    • –bypass-hooks オプションで、リポジトリィにhooks/pre-revprop-change.batの配置が不要らしい。
    • -r REVは範囲指定(-r LOWER:UPPER)可。
    • ※復元不能につき上書き注意!
  • リポジトリィのコミットメッセージの誤字脱字などを修正する(1行以内)
    • 使用方法: svn propset –revprop -r <REV> svn:log <訂正文> <リポジトリパス>
    • 例: svn propset –revprop -r 24 svn:log 誤字脱字 /var/www/RepoA
    • ※復元不能につき上書き注意!
  • リポジトリィのアップグレード
    • 使用方法: svnadmin upgrade <リポジトリパス>
    • 新しい Subversion の機能を利用できるようにするもので、最も最適化されたリポジトリ状態になる訳では無いらしい。
  • リポジトリィの圧縮
    • usage: svnadmin pack REPOS_PATH
    • Possibly compact the repository into a more efficient storage model.
      This may not apply to all repositories, in which case, exit.
  • リポジトリィの中断
    • 使用方法: svnadmin crashtest <リポジトリパス>
    • リポジトリを開いて中断するだけ。デバッグ用かな?

 



【Apache-2.4】配布はソースのみ!なぜならば・・・

いつのまにかApacheはソースの配布になっていた。
Binaryのページには、
バイナリーのダウンロード負荷が物凄いので諦めたと書いてあり、

Download from your nearest mirror site!

とダメ出しをしていた。
しかし一般にミラーサイトは、『そのままミラーするのが通』なので
勿論、同じ文面が載っている。
このリンクをたどってもWindowsのバイナリー(EXEとかMSI)の入手は不可能だ。
だが、最初のページの下の方には

Downloading Apache for Windows

があり、
Apacheのバイナリーモジュール(EXEファイル等)の配置しているサイトのリストが掲載されていた。

  • ApacheHaus
  • Apache Lounge
  • BitNami WAMP Stack
  • WampServer
  • XAMPP

自分でコンパイルできないなら、この中から選んでDLしてね!と書いてある。
※だが、最後まで読めば「試しに自分でコンパイルすること」自体が罠なんじゃないかな?と、貴方は気が付くことになるだろう。
今回は、Apache Loungeを選択し、Apache 2.4.18 Win64 こと httpd-2.4.18-win64-VC14.zip をGETした。
同ページで、Apache 2.4.18 Win32 もGETできるハズだ。
残念ながらパッケージのインストーラではなく、
インストール後のフォルダ構成をアーカイブしたものであった。
なので、設定の見直しや、必要に応じて、vc_redist_x64/86.exeなどのランタイムも入れなければいけないだろう。
テスト・アンド・エラーを繰り返すしかない様だ。
そもそも、EXEをダブルクリックするだけでApacheサービスを起動するような作りにはなっていないのだから仕方が無いのだ。
諦めずコツコツと少しづつ調整が必要だ。
まずは、直下のReadMe.txtを読み必要な設定を行わなければならない。
Install
——-
ドコかにunzipして中のApache24フォルダをc:/Apache24フォルダにコピーし、DOSプロンプトから httpd.exeを実行せよ!
勿論、

‘httpd.exe’ は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。

となるので、

> cd C:\Apache24\bin の後に
> httpd.exe
(OS 10013)アクセス許可で禁じられた方法でソケットにアクセスしようとしました。 : AH00072: make_sock: could not bind to address [::]:80
(OS 10013)アクセス許可で禁じられた方法でソケットにアクセスしようとしました。 : AH00072: make_sock: could not bind to address 0.0.0.0:80
 AH00451: no listening sockets available, shutting down
 AH00015: Unable to open logs
> httpd.exe -k install
Installing the 'Apache2.4' service
(OS 5)アクセスが拒否されました。 : AH00369: Failed to open the Windows service manager, perhaps you forgot to log in as Adminstrator?

となってしまった。
cdでディレクトリィを移動したもののサービスに登録するなら・・・
コントロールパネルからシステム環境変数にC:\Apache24\binを登録する必要があるだろう。
久しぶりに設定してみたら、Windows-10ではこんな画面に変わっていた。
20151218-1
これなら「:」の付け忘れや「;」ミスの心配もないし、上、下ボタンで入れ替えも簡単だ。
そして、サービスを登録するにはやはり「管理者:コマンド プロンプト」が必要だろう。

召喚方法1:

Windowsキーを押す

「すべてのアプリ」をクリック

WのWindows システムツールをクリック。※Wまでスクロールするのがとてもダルい。

展開したメニューの「コマンド プロンプト」を右クリック。

ポップアップしたメニューの上をマウスで「その他」まで移動。

「管理者として実行」をクリックする。

召喚方法2:

Windowsバーに登録しておいた「コマンド プロンプト」のアイコンを右クリック。

ポップアップしたメニューを「コマンド プロンプト」の場所までマウスポインタを移動し右クリック。

さらにポップアップしたメニューの「管理者として実行(A)」をクリックして

「管理者:コマンド プロンプト」を呼び出す。

しかし、それでも、

(OS 10013)アクセス許可で禁じられた方法でソケットにアクセスしようとしました。 : AH00072: make_sock: could not bind to address [::]:80
(OS 10013)アクセス許可で禁じられた方法でソケットにアクセスしようとしました。 : AH00072: make_sock: could not bind to address 0.0.0.0:80
 AH00451: no listening sockets available, shutting down
 AH00015: Unable to open logs
C:\Apache24\bin>httpd.exe -k install
 Installing the 'Apache2.4' service
 The 'Apache2.4' service is successfully installed.
 Testing httpd.conf....
 Errors reported here must be corrected before the service can be started.
(OS 10013)アクセス許可で禁じられた方法でソケットにアクセスしようとしました。 : AH00072: make_sock: could not bind to address [::]:80
(OS 10013)アクセス許可で禁じられた方法でソケットにアクセスしようとしました。 : AH00072: make_sock: could not bind to address 0.0.0.0:80
 AH00451: no listening sockets available, shutting down
 AH00015: Unable to open logs

と少しマシになったダケだった。
-K オプションでサービスは登録できたようだが、
20151217-1
設定した中身がhttpd.exe -k runservice とは・・・恐れ入る。
20151218-4
それに0.0.0.0:80でエラるのだから、80ポートに先約がいるようだ。
20151217-2
VisualStudio Community 2015 が入っているせいらしいので、諦めてアンスコ。
だが、IISはアンスコされず、直にアンスコ。
20151217-3
さて、再起動したもののサービスを起動するとエラー1
Windowsのイベントログを読んでいくと
The Apache service named  reported the following error:
>>> (OS 10013)アクセス許可で禁じられた方法でソケットにアクセスしようとしました。  : AH00072: make_sock: could not bind to address 0.0.0.0:80
The Apache service named  reported the following error:
>>> AH00451: no listening sockets available, shutting down
The Apache service named  reported the following error:
>>> AH00015: Unable to open logs
The Apache service named  reported the following error:
>>> (OS 10013)アクセス許可で禁じられた方法でソケットにアクセスしようとしました。  : AH00072: make_sock: could not bind to address 0.0.0.0:80
The Apache service named  reported the following error:
>>> (OS 10013)アクセス許可で禁じられた方法でソケットにアクセスしようとしました。  : AH00072: make_sock: could not bind to address [::]:80
色々調べたけど、どこかで80ポートを占有しているらしいのだが何が占有しているのかが判らない。
Visual Studio 2015 のランタイム(VC_redist.x64.exe)を放り込んだ後に
— httpd.conf を修正。
Listen 8080
Apache Service サービスを起動。
エラーメッセージは出てこない。
ブラウザからhttp://127.0.0.1:8080/を見る

It works!

80ポートが使えないことを除けばApacheは調子が良さそうだ。
※TLSは何か調整しないとダメっぽいけど・・・
ApacheMonitorをコピーし、
C:\Users\ユーザー名\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup を開き
ここにショートカットを貼り付ける。
これで任務完了。
ps.
と思った。
しかし執念深くググってみると、
skypeが怪しいという記事を見つけたが・・・
http://nusoft.jp/blog/archives/110 によると

  • Web Deployment Agent Service
  • SQL Server Reporting Service
  • Windows Remote Management
  • BranchCache

あたりがWindows7のポート80を奪っていたらしい。

どれも心あたりあり過ぎて困るw

skypeなど共々アンスコしてもコマンドプロンプトでnetstat -naoすると
アクティブな接続
プロトコル  ローカル アドレス      外部アドレス           状態            PID
TCP         0.0.0.0:80             0.0.0.0:0              LISTENING       4
消えてない!
http://worktoolsmith.com/2013/01/windows-port80-pid4/ に Microsoft Web Deploy が怪しいと書いてあった。
Microsoft Web Deploy 3.6 があった。インストの日付を見るとVS2015 Community の一部らしいのでアンスコ。
しかしダメだった。
敵を知るにはまず・・・
真正面から向かい合った方がいいだろう。
http://127.0.0.1 を開く。
真っ白な画面。
ソースの窓も真っ白。
そう!サイズが0バイト。
前世期に・・・
デスクトップのスクリーンショットを盗み撮りし80ポートを乗っ取ってブラウザを起動して暴露し、使っている人をびっくりさせる
そんな変なのがあったのを思い出した。
しかし、画面も真っ白だ。
自白を得られる様な気配は全くない。
http://127.0.0.1?aaaaaaaaaaaaaaaaaaaa
と揺さぶりをかけても真っ白。シラを切ったままだ。どうやら口が堅い奴らしい。
このまま黙秘権を行使されても進展が無いので、
仕方なく裏口に回ってみる。
カギはかかっていないが立て付けが悪くなっている。
Windowsマークを右クリックし、Windows-10では禁断のコントロールパネルを開き、アプリケーションの【Windowsの機能の有効化または無効化】を見てみた。
「インターネット インフォメーション サービス」
⇒「World Wide Web サービス」
⇒「セキュリティ」
の中に見るから怪しい【要求のフィルタリング】を発見!
20151218-3
ツールチップには「ルールを構成し、指定のクライアント要求をブロックします」と書いてある。
80ポートを塞いでいる実行犯の0バイトと雰囲気がよく似ている。
試にこのチェックを外すと
再起動を促される。
いくつかのメッセージが表示され
パーセントの数字が少しづつ増えていく
再ログイン。
そして、http://127.0.0.1 を見ると

It works!

Apacheが偉そうにガッツポーズを決めていた。




top