Vagrant 経由で作成した VirtualBox をグルーピングすると認識されない!?

Vagrant経由で作成したVirtualBoxの仮想マシンを「VirtualBox マネージャー」の
グループでグルーピングするとVagrantで認識されなくなりました。
具体的には vagrant status を実行すると saved (virtualbox) を返していたのが
グループ化した後 vagrant status を実行すると not created (virtualbox) となりました。

not created となっているので、vagrant up を実行すると新規作成の動作になり
今まで認識していた仮想マシンは参照されなくなりました。
確認してみると、VirtualBoxの仮想マシンを保存するフォルダ内でグループ名を
親ディレクトリにグルーピングした仮想マシンのディレクトリをサブディレクトリに
再配置されていました。
ディレクトリ構造が変わったため、別物として扱われ認識しなくなったと思われます。

vagrantでは参照されなくなったので「VirtualBox マネージャー」から除去を行うと
下記のエラーメッセージが表示されました。

仮想マシン"[vagrant server name]"の除去に失敗しました。
Could not delete file '/to/path' (VERR_PATH_NOT_FOUND).

終了コード : VBOX_E_IPRT_ERROR (0x80BB0005)
コンポーネント: Machine
インターフェース: IMachine {...}

グループ名のディレクトリが存在するのを確認できたのでエクスプローラから削除。
 「VirtualBox マネージャー」のグループを利用するとVagrantから認識されなくなる
事象をissueで挙がっているか探しましたが、似たような内容は見つかりませんでした。

Vagrant経由なら簡単に仮想マシンの作成ができるので、次々と作成していたら
一覧が大変なことになったので、整理しようとグループを使ったのが始まりでした。
グループを解除すれば元に戻るかもしれませんが、確認していません。
今のところ対策としては、グループを使うほど仮想マシンが多くなるのであれば
「Dockerを利用してコンテナで管理する」ぐらいでしょうか。

Adobe Reader X と Acrobat X のサポートが終了したのでバージョンアップ

PDFソフトのAdobe Reader X と Acrobat Xが11月にサポートを

終了するとアナウンスがあったので、最新のバージョンに切り替えました。

利用していたのはAdobe Readerだけだったのでダウンロードページから

インストーラをダウンロードしてインストールしました。

利用しているOS Windows7

言語は Japanese

バージョンは Reader DC 2015.009.20069 Japanese for Windows

(利用しているパソコンの環境によって選択するOSや言語は変更します)

私の場合、オプションのプログラムのチェックを外します。

このオプションはいつも使うことが無いので。

今すぐダウンロードをクリックしてインストーラをダウンロードし、インストールします。

インストールが終わればAdobe Reader XからAdobe Acrobat Reader DCに

バージョンアップされています。

Adobe Acrobat Reader DCに自動的にアップデートされる環境とアップデート

されない環境を偶然にも持っていたので、片方は今回のように手動で行いました。

Windows VistaとMac OS X 10.5に対応するソフトは以降のバージョンでは

対応OSとして無くなるため、サポート終了により別のソフトを探す必要があると思います。

探してみるとAdobe以外にも色々とあるみたいですね。

CubePDF Viewer

http://www.cube-soft.jp/cubepdfviewer/

PDF-XChange Viewer

http://www.tracker-software.com/

Adobe Reader、Acrobatのサポート期間はリリース日から5年間となっているようです。

OSのサポート期間は注意していますが、利用しているソフトのサポート期間も同様に

注意して対応しないといけないですね。セキュリティも危なくなりますし。

cURL で自己署名証明書の SSL が通らないとき

コマンドラインでWebにアクセスすることができるcURLを利用して
自己署名証明書を設定したHTTPS環境にアクセスすると失敗します。

curl https://example.com/

実行すると次のメッセージが表示されてアクセスできません。

curl: (60) SSL certificate problem: self signed certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

自己署名証明書を利用しないのが最善ですが、やむを得ず使う場合
--cacert でcrtファイル(SSL証明書)を指定すればアクセスできます。

curl --cacert server.crt https://example.com/

-k または --insecure は証明書の検証をオフにしてアクセスするため
下手すると悪いことが起きるかもしれないので、気をつけます。

curl -k https://example.com/

失敗したときに表示されるメッセージを落ち着いて読めば良いのですが
英語は慣れるしかないですね。

SSH の公開鍵をサーバに送るには ssh-copy-id を利用しよう

SSHの公開鍵認証を利用してリモートにアクセスする場合、公開鍵をリモートに設置します。
リモート側では公開鍵情報をユーザのホーム直下の .ssh/authorized_keys に保存します。

.ssh/authorized_keys を設置するとき

ファイルが無ければ作成→公開鍵情報の書き込み→ファイルの権限を設定
の手順が必要ですが ssh-copy-id コマンドを利用すれば1操作で済みます。

コマンド書式

ssh-copy-id -i 公開鍵ファイル user@ipアドレス

コマンド例

ssh-copy-id -i .ssh/id_rsa.pub user@192.168.1.1

Windows の Jenkinsでジョブ実行中に一時停止する

WindowsでJenkinsのジョブを実行中にsleepのような一時停止を行う方法です。
「Windowsバッチコマンドの実行」で下記のコマンドを実行することで一時停止ができます。

ping localhost -n [待機する秒数+1] > nil 

[待機する秒数+1]は待機する秒数の値に置き換えます。
例
60秒なら 61
30秒なら 31
pingを利用した方法の実行結果のキャプチャ

このキャプチャでは61を設定しているので、60秒後に次のコマンドが実行されています。
Windowsのpingは1秒間隔で実行する仕様のため、これを利用して実現しています。
待機する秒数+1は1回目の処理は即座に実行されるので、+1が必要なのだと思います。

TIMEOUTというコマンドもありますが、Jenkinsのジョブで実行すると
エラー: 入力のリダイレクトはサポートされていません。今すぐプロセスを終了します。
と表示されジョブが失敗してしまいます。
これは約1年前に投稿したWindowsのJenkinsでジョブ実行中に一時停止したいのにで
躓いたまま、そのままにしていた現象の現時点での解決策です。

マクドナルドの新CMおてごろマックでマックとマクドの表記を発見

最近放送されているマクドナルドの新CMおてごろマック篇。
200円、150円、100円と切りの良い価格帯の商品が流れていましたが、それよりも
気になったのは最後に現れるマクドナルドのロゴの背景に表示される文字でした。
文字には「マック」が大部分を占めていましたが、ロゴの真ん中の右辺りに「マクド」の
文字を発見したのです。
表示されている時間とエリアが小さいので気付き辛かったですが見つけたときは
喜んでしまいました。

1年前の内容ですが、ぐるなびの記事を参考にしました。
【マックVSマクド】定説に変化あり!? 都道府県別「マック」「マクド」使用率を調べてみた！【2014年版】
「マック」、「マクド」の呼び方の割合は場所によって異なるようです。
「マック」が大部分を占めていたので「マクド」の呼び方はマイナーになるのかも知れません。
ぐるなびの記事でも「マクド」がメインなのは関西のようです。

その文字が表示されるのは29秒あたりになります。

場所によって呼び方が異なるので、勝手に関西バージョンとその他バージョンの動画が
あるのかなと思っていましたが、1バージョンだけでした。
呼び方は自然に生まれたものということらしいですが、動画の中身を見る限り「マック」が
公式のデファクトスタンダードの呼び方ではないか？なんて勝手に想像したりしてます。

そういえば、マクドナルド前に食べたのは何時だったけ？
たまーに食べたくなるんですよね。
食べたくなるけどカロリーと相談しないと、デスクワークは消費カロリーが少ないので。

仕様がマズイならノーといえるんでスカ

機能の追加や変更で仕様がマズイ

・影響する範囲が大きい
・チカラ技で切り抜けようとしている
・今回限りの対応ではなく、バージョンアップのたびに手を加える必要がある
・付け焼刃的な対応でどう見ても焦げ臭いにおいしかしない

そのとき浮かんだ内容を挙げただけでも、黄信号ではなく真っ赤な赤信号。
利用中のユーザーに影響する範囲は少ないので、スケジュールを見直して
次のバージョンで対応することも考えられたので、懸念事項も含め開発中の
バージョンで対応するのはノーと返したが「既に決まったことなので」の一点張り。

で、結果は散々。
ユーザーへのメリットは少ないうえに、開発にはメリットよりもデメリットのほうが目立つ。
しかも「仕様がマズイならそのときに発信しないとダメだし、発信しないほうが問題」
みたいなこと言ってる。

ノー といっても貴方のさじ加減で決まってしまうのに、言っても無駄でしょうが。
そもそも旗を振る人間に対して「言っても無駄」と思われている時点でお先真っ暗に思う。

悪いケースを経験できたと思うしかないかな。
このようなときに懸念事項や考えられるケース、影響範囲をどれだけ挙げられて
優先度を付けられるか。
今後も考えなくてはいけないことだけど、悪いケースにはならないように気をつけなくては。