もうJava8が出てからかなりたつのに、既存で動いているシステムはすぐには最新バージョンでは動かせない悲しさ。
しかし中には容赦なくJDK8でコンパイルされているライブラリもあり、そのようなクラスを対象バージョン以下のJDKで動かした場合には、「java.lang.UnsupportedClassVersionError:」が出てしまう。
未然に防ぐためにjarの中身のクラスファイルをチェックしてみるべし。
jar xvf xxx.jar javap -v xxx.class #出力結果抜粋 minor version: 0 major version: 48
majar versionに注目！これが48であれば、JDK1.4でコンパイルされたということである！
しかしこのmajarバージョンとJDKのバージョンの不一致にも困ったもんだな。
JDK1.2が46でそこから0.1ずつ上がるたびに1ずつ増えて、1.6では50となる。
AWSのシークレットキーをgithubで公開して、不正利用されて数十万などという話を聞く。
自分もAWSの操作をAnsibleで行っているので、Ansibleで利用するシークレットキーやパスワードなどの情報をどのように管理するか悩みどころである。
幸いにしてansibleには設定ファイルに書かれた情報を暗号化するansible-vaultというコマンドがある。
これは暗号化に使ったときと同じキー（文字列）を実行時に打ち込むことで、セキュリティを確保しようという仕組みである。
まずは普通の設定ファイルを用意する。ansible-vault encrypt を実行すると元のファイルを上書きしてしまうので注意。普段は暗号化した状態でコミットしておくのがよいだろう。
aws_access_key: HOGEHOGE aws_secret_key: FUGAFUGAFUGAFUGA # 暗号化する ansible-vault encrypt secret.vault # 編集するときは複合化する ansible-vault decrypt vars/secret.vault # 実行時に複合化キーを聞くようにansible.cfgを以下のように設定 [defaults] ask_vault_pass = True
Cronをセットしたのにどうも時間がずれているようだ。
4時にセットしたタスクが日本時間の13時に実行されている。これは9時間のずれなのでcronが動くタイムゾーンがUTCとなっているのでは？
というわけで解決策を
/etc/crontabでタイムゾーンを設定してcrontabを再起動すればよい。
vi /etc/crontab # ファイルの先頭あたりに以下の記述を追記する TZ="Japan" # crond再起動 /etc/init.d/crond restart
2015/12月時点での情報なので今後変更される可能性が大いにあるが、現時点ではt2.microのみが無料枠の対象となり、t2.nanoにはきちんと課金が発生する。
先週土曜日にt2.nanoがでたというのでボコボコたてていたら、ちょっと無料枠に関して記載が全くないのに気がついてあわてて停止した。
そして今日料金を確認したところ12円が課金されていた。
9時間起動していたらしい。安いと言えば安いけど、無料枠で抑えたい人はt2.nanoは使わないほうがよい。
先日東横イン町田に宿泊したときにSSHがつながらない事態になった。
考えてみると一般利用者のほとんどはWeb閲覧だろうから80/443とかメールぐらいのポートしか開けていないのかも？
東横イン全部でSSHが使えないのか、それともこの町田だけなのかはわからないが、結構大きなホテルチェーンなので不要なポートは開けないというセキュリティポリシーは統一されてそうだな。
今後いろいろなビジネスホテルで突撃体当たり取材をして明らかにしていこう！
Cygwinで過去コマンドを検索したくて、いつものhistory + grepの合わせ技コマンドを実行したら
「バイナリファイル (標準入力) に一致しました」と出るのみで、肝心の結果が出ない。
history | grep core バイナリファイル (標準入力) に一致しました
どうもバイナリファイルと勘違いしているようなので、-textオプションを付けてやる
history | grep core --text
今度はテキストと認識されて無事検索できましたとさ。
Ansibleのplaybookは一度作ってしまうと、それを再利用することが中心なので簡単なコマンドでも忘れてしまう！
今回は単にregisterした変数の中身を表示させるというもの。
debug モジュールは単に文字列を表示させることもできるし、変数の中身を展開させることもできる。
- name: register IP shell: echo "test" register: debugstr - name: display debugstr debug: var=debugstr
本日iPhone6がまったく通信できない状況に陥った。
もう一台のAndroidマシンpriori2では通信ができているため、端末の問題と思われる。
こういう時はいったん機内モードにしてから戻すことで回復する可能性があるが、
それもだめ！
そんな時は最終手段で再起動！そしたら通信が復活した。
スマートフォンはWindowsと同様長期起動していたら、不具合に遭遇しやすいので
このような現象を防ぐために定期的に再起動するようにしておくのが良いだろう。
AzureとAWSはいろいろ勝手が違うので戸惑うことが多いが、本日は昨夜停止したマシンなのに「引き続きコンピューティングの料金は発生」なる表示がでて課金が継続されていた。
よくよく調べると
管理コンソールから停止した場合は、停止後料金は発生しないのだが、
SSHなどで内部からshutdownした場合は、停止扱いにならないらしい（ログインもできないのに！）
というわけで完全に課金停止にするにはクソ重いコンソールから停止をしなければならないのだ。
停止済みには二つの種類があって、
コンソールから停止した場合には
停止済み(割り当て解除済み)となる。
割り当て解除済みという文言がポイントで、この割り当てにはパブリックIPも含まれるため再起動するとIPが変わっている。一方SSHなどでシャットダウンした場合は停止済みだけの表示となり、再起動してもIPは変わらないかわりに課金は継続している。
昨今の不正アクセス対策として、二段階認証が導入されているが、
万が一スマートフォンが壊れたらどうすりゃーいいの？
システム(google,Slack)によってはバックアップコードなどを用意してあり、それを利用することで
通常のパスワード認証のあとバックアップコードを入れることで認証することができる。
壊れた時の代替手段が用意されていないのが、AWSのコンソールである。
AWSコンソールに二段階認証を必須としている状態で、スマートフォンが壊れた場合はコールセンターに電話して、英語でのやり取りをして本人確認後利用再開できるらしいが結構大変らしい。
なのでバックアップ用として同じQRを読み取るスマートフォンを用意することをお勧めする。
乱数も同じものがでるので、普段はどちらを使ってもよい。
