月別アーカイブ:2019年7月

ONVIF

コメントを残す

Network Interface Specifications

 

recording Control = recording.wsdl

 

http://www.onvif.org/ver10/recording/wsdl

がある。

https://www.onvif.org/member-portal/wp-content/uploads/sites/2/2017/08/ONVIF_FeatureList_VB-H651V_Ver.-1.1.0_2017-02-25_23h48m9s.xml

 

https://www.atmarkit.co.jp/ait/articles/0303/18/news003.html

を見ながら。

https://www.onvif.org/ver10/recording.wsdl

を確認。

 

recording_service は何？

 

test specification

https://www.onvif.org/wp-content/uploads/2019/01/ONVIF_Base_Device_Test_Specification_18.12.pdf

見た

https://www.onvif.org/wp-content/uploads/2018/07/ONVIF_Recording_Control_Test_Specification_18.06.pdf

 

https://www.onvif.org/wp-content/uploads/2017/01/ONVIF_Profile_G_Specification_v1-0.pdf

にExport～が無い。

git-svn branches

コメントを残す

stdlayoutでは、

svn でブランチ作成後

git svn fatch でリモートブランチが作成される。

最初の記事にまとめた

 

git-svn Unable to extract revision information from commit

コメントを残す

該当の修正は、そんな大した修正ではないのだが・・。

https://github.com/nilesflow/git-svn-test2019/commit/51512d9d9fdddd4239f000f822b58e8a668293cf

https://github.com/nilesflow/git-svn-test2019/commit/d8f5f6d5c2ee6e84ac7b0c43cfb5f28f03113dce

rebase すると、git svn dcommit 後に、コミットIDを書き換えないために行った、git pull によるコミットがマージされてしまう。

この状態で、dcommit すると成功した。

・dcommitでコミットIDが変わった事に対して、git origin から pull すると、svn 側が上記エラー状態に

・dcommitでコミットIDが変わった事を正とすると、git push -f で歴史書き換えになってしまう。

うーん。

git svn rebase すると、マージコミットなりが rebase されまくるので、

オプション見てもこれを防ぐことは不可能。

git svn の操作対象ブランチはおとなしく、rebase を受け入れるしかない、と考えた。

svn/trunk と git側の master は共存できない、という結論。

こんなエラーも

git-svn Cannot accept non-LF line endings in ‘svn:log’ property

コメントを残す

ちょっとはまった。

ローカルSVNサーバ

github

という構成でgit-svnを使用。

svn1.6だと発生する旨の記事が多い。

 

環境

 

windowsでgithubでpullreqをmergeすると、発生していた。

git svn dcommit すると

git-svn Cannot accept non-LF line endings in ‘svn:log’ property

 

恐らく、コミットログにcrlfが混じる。

git commit --amend

git rebase -i -p HEAD~3

-pしないとマージコミットが表示されない。

git pull 後に、git merge、git commit 等でも発生しなくなる。

何らかの操作でgit log に modify が入ればよい模様。

git-svn setup

コメントを残す

 

--stdlayout

trunk, branches, tags の構成

 

--prefix svn/

git の リモートリポジトリが衝突しないように。

--localtime

git ログ等の時間がデフォルトUTCなので日本時間に合わせる。

表示上だけで、SVN側ではJSTになっている等、問題はなかった。

 

変則的な構成

・turnkは直接指定

・branches/tagsはディレクトリ指定

・–ignore-refs で無視するパターンをうまく指定する

 

master ができる。

現在のリポジトリから svn/trunk へ

masterに入れば、masterから。

develop に入れば、developから。

基本的には、materだけで行う運用が無難そう。

★別記事で。

 

dcommit すると、git のcommitIDが変わる。

git の masterへマージ後、git svn dcommit

で変わってしまうので、git側へは -f push が必要。と思う。

また何らかのエラーでcommitツリーを変えてしまった時も問題。

master使わないほうがいいのか？

 

svn リポジトリから取得

チェックアウトしているローカルリポジトリにマージされる。

master に入れば、masterに。

develop に入れば、developに。

どこにいるかわからないまま実行すると危なそう。

基本的には、master だけで行う運用が無難そう。

★別記事で

 

git 側に開発ブランチを作成

 

githubのリモートにpush

 

参考

https://qiita.com/hidekuro/items/4727715fbda8f10b6b11#svn-%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E3%82%92%E5%8C%BA%E5%88%A5%E3%81%99%E3%82%8B

等

svnserve install

コメントを残す

svnserve install

git-svn 使用にあたって

等
trunk, branches, tags で commit

Azure：VM／非管理ディスク／管理ディスク／スナップショット等のまとめ

コメントを残す

VM×非管理ディスク

2019/7/8現時点では、非管理ディスクではなく、Microsoft自身も推奨する管理ディスクを利用する方が一般的だと思うので、非管理ディスクでVMを作成することは余り無いのだと思う。

次のような場合に。

・過去に作成したVMの停止／削除を行いたい場合、

・何らかの理由があって、非管理ディスクでVMを作成しようとする場合

 

VMの作成

VMを非管理ディスクで作成した場合。

ストレージアカウントのBLOBに、1BLOBとしてVHDファイルが保存される。

ディスク30GBなら、30GBのファイル。

「vhds」というコンテナの中に、次のファイル名でBLOB単位で保存される。

{VM名}yyyymmddhhiiss.vhd

 

VM作成画面では、デフォルト「管理ディスク」となっているので、

明示的に「非管理ディスク（及び保存対象のストレージアカウント）」を指定する必要がある。

 

料金は、¥5.04/GB～

https://azure.microsoft.com/ja-jp/pricing/details/storage/page-blobs/

＝\150.12/月～

 

非管理ディスクの場合、既存のディスクから作成することはできなかった。

（※portal上の操作を確認する限り）

（後の復元手順に影響）

 

VMの停止

VMが暫く不要になった場合、金額的には、VMを停止して放っておく、でも良いのだろうと思われる。

 

VMの削除

VMを削除しても次のリソースは残るので注意

・IPアドレス

・セキュリティグループ

・ネットワークインタフェース

 

新規で作成していれば、

・ストレージアカウント（ディスク用）

・ストレージアカウント（診断用）

・仮想ネットワーク

※作成の仕方によっては他にも発生する

 

パブリックIP

静的IPアドレスは、

¥0.896/時間　=\666.624/月

動的IPアドレスは、リソースが解放されるので問題なし。

 

ディスク

VMを削除しても、対象のストレージアカウントの中に、ページBLOBのVHDファイルが残る。

削除対象のBLOBファイルは、VMの名前から判断する。

また、状態が「リース解除」になっている。

対象のディスクは、リソースグループ → [対象のリソースグループ] → デプロイ から、

VM作成時のディスク名を確認することができる。

※が、VM削除後にディスクリソースを開いても、読み込み待ちのまま、情報が表示されなかった。

 

VMの復元

非管理ディスクのVMを復元する場合は、VMイメージを作成する必要があるため、VMを削除してしまうと、イメージを作成できず、復元がしにくい、ということになるのだと思われる。

次の記事中に、「PowerShell から仮想マシンを作成する」方法の記載がある。

https://blogs.technet.microsoft.com/jpaztech/2018/09/21/arm-vm-replication-part-1/

後に示すように、VHDファイルから管理ディスクへの移行が行えるため、管理ディスク利用のVMへの移行が現実的と思われる。

 

VMのイメージを作成

コスト面からVHDファイルを保持せずにどうにかしようという事は余り無いと思うが、

VHDファイルを削除して、後から復元しようとする場合は、下記の方法？

・VHDファイルのダウンロード／アップロード

・VMのイメージを作成

※イメージにした場合、30GB（元のVHDファイル）からどの程度小さくなるのか？

非管理ディスクのVMを作成する方法は下記。

https://blogs.technet.microsoft.com/jpaztech/2018/09/21/arm-vm-replication-part-1/

下記が面倒。

・Azure VM エージェントでVMを汎用化する必要がある

・そのVMは利用できなくなる

・VMのイメージ作成はportalで行えず、PowerShellを利用する必要がある

 

管理ディスクへ移行する

幾つかの方法が考えられる。

・既存のVM（非管理ディスク）を新VMへ移行

・既存のVM（非管理ディスク）を残したまま、新VM（管理ディスク）を作成

・VHDファイルから管理ディスクを作成して、VMを作成

・VHDファイルからスナップショット→管理ディスクを作成、VMを作成

 

既存のVM（非管理ディスク）を新VMへ移行

既存のVM自体をそのまま移行したい場合はこの手順

非管理ディスクのVHDファイルはBLOBストレージ上に残るので、不要な場合は、別途削除処理等を行う必要がある。

 

・次の方法で、「マネージド ディスクに移行」に画面遷移

・VM画面上の「～、Managed Disks に移行してください。」案内から

・VM「ディスク」画面の「マネージド ディスクに移行」から

 

・VMが起動中の場合は、停止→開始の動きになる

・VMが停止中の場合は、開始される

 

管理ディスクが作成され、自動的にVMの既存（非管理ディスク）がデタッチされ、

作成された管理ディスクがアタッチされる。

既存（非管理ディスク）のBLOBのリース状態は「利用可能」になる。

 

★「管理ディスク」名称のprefix に自動でハッシュキーが付くため、綺麗に管理するなら嫌かも

 

VHDファイルから管理ディスクを作成して、VMを作成

「ディスク」から「追加」を選択

「マネージドディスクの作成」画面で下記を選択して作成する。

ソースの種類：ストレージBLOB

ソースBLOB：既存（非管理ディスク）のBLOBを

 

作成した管理ディスクで、「VMの作成」を選択して作成する。

この場合、幾つかの情報は管理ディスクに含まれているため、新規にVMを作成する場合と比べて、入力する必要がない。

・地域は固定

・管理者アカウント、SSH接続情報は求められない

 

・起動中のVMに紐づく状態が「リース中」のVHDも選択可能

※ファイル整合性は未確認

 

スナップショット

非管理ディスクにも「スナップショット」があるが、管理ディスクのそれとは異なる。

（コンソール上で確認した限りだと）

これはあくまで、対象のVHDファイルであるページBLOB内に閉じた機能で、

ページBLOBを取得したスナップショット状態に変更（「昇格」と表現）する等が行える。

取得したスナップショットから管理ディスクを作成したり、を行うものではなさそう。

※上述した管理ディスク作成で、スナップショットのURLを指定できるか等は未確認

 

VM×管理ディスク

今後一般的と思われる管理ディスクの場合。

 

VMの作成

非管理ディスクの場合とほぼ同様。

VM作成画面では、デフォルト「管理ディスク」となっているので、そのまま作成する。

 

VMの停止

管理ディスクは、Standard HDD S4 32GiB で、¥172.04/月～ かかる。

スナップショットは、¥5.6/GB なので、実データサイズが 10GBの場合、\56/月～ なので、

多少コストメリットはある。

VMの復元もそれほど手間ではないので、スナップショットにしておくのが良いだろうと思われる。

※イメージにすると、汎用化されるのでVMが使用できなくなる

 

VMの削除

非管理ディスクの場合は、削除してしまうと復元が多少面倒になるが、

管理ディスクの場合は、また「VMの作成」を行えば良い。

 

（無題）

コメントを残す

『windows 10 virtual desktop enhancer』の使い方

『windows 10 virtual desktop enhancer』の主な機能としては以下の通りです。

  • タスクトレイに表示されている数字は、現在の仮想デスクトップ番号を表示
  • 仮想デスクトップ毎に壁紙設定が可能
  • 「Alt」＋「0〜9」で、仮想デスクトップを切り替える
  • 「Alt」＋「←」「→」で、仮想デスクトップの前後に切り替える
  • 「Alt」＋「Shift」＋「Ctrl」＋「0〜9」で、現在のウインドウを指定した仮想デスクトップに移動する
  • 「Alt」＋「Shift」＋「Ctrl」＋「←」「→」で、現在のウインドウを前後の仮想デスクトップに移動する
  • 「Alt」＋「Shift」＋「0〜9」で、現在のウインドウを指定した仮想デスクトップに移動＆切り替え
  • 「Alt」＋「Shift」＋「Ctrl」＋「←」「→」で、現在のウインドウを前後の仮想デスクトップに移動＆切り替え
  • アイコンをクリックすることにより、仮想デスクトップの切り替え画面の呼び出し

 

 

【Windows 10】仮想デスクトップをさらに使いやすくカスタマイズ！『windows 10 virtual desktop enhancer』

AWS Batch コンピューティング環境の終了タイミング

コメントを残す

実動作では何もジョブが実行されない場合に、10分で terminated されていた。

 

コンピューティング環境一つに対して、Auto  Scalingグループが作成されており、

次のログが出ていた。

Terminating EC2 instance: i-0a0d23067827fb809
2019 July 5 03:17:14 UTC+9
2019 July 5 03:18:19 UTC+9
説明:説明Terminating EC2 instance: i-0a0d23067827fb809
原因:原因At 2019-07-04T18:17:14Z instance i-0a0d23067827fb809 was taken out of service in response to a user request, shrinking the capacity from 1 to 0.

 

下記だろうか。外部が指定している？AWS Batchが指定している？

https://docs.aws.amazon.com/ja_jp/autoscaling/ec2/APIReference/API_TerminateInstanceInAutoScalingGroup.html

 

クールダウンの300秒が関係している？

 

他、

AWS Batchを使って5分以上かかる処理を実行してみる

調査中。