サーバーとかの認証条件にパスワードに加えて、逆引きDNSを設定していたのだが、本日なんとそれがOCNのものに変わっていた。OCNに契約したつもりはないのだが!
んで、IPは以前から変わっていないので、おそらく契約プロバイダが独自IP網をあきらめてOCNを利用するようになったのだろう。かれこれ20年近くお世話になっているのに・・・
てなわけで今後どうするかはちょっと考えないといけないなー。
サーバーとかの認証条件にパスワードに加えて、逆引きDNSを設定していたのだが、本日なんとそれがOCNのものに変わっていた。OCNに契約したつもりはないのだが!
んで、IPは以前から変わっていないので、おそらく契約プロバイダが独自IP網をあきらめてOCNを利用するようになったのだろう。かれこれ20年近くお世話になっているのに・・・
てなわけで今後どうするかはちょっと考えないといけないなー。
注意:この設定を入れるとセキュリティ上好ましくないのできちんと理解したうえで入れること!
サーバーバックアップで固定IPの接続先からSSH経由でrsyncを実行しているのだが、時折発生するサーバー再構築時にホスト公開鍵が変わってバックアップが3ヶ月取れてないという自体が判明。
根本原因はホストの公開鍵が変わって、接続先が前回と違うので警告出して落ちていたということなのだが、どうにかならないものかとしばし考える。
結論としてはシェルのバックアップ作業なのでプロンプトが発生するようなことがないようにしたいというわけで.ssh/configに以下の設定を入れることにして公開鍵チェックを外した。
StrictHostKeyChecking no
ちなみに相手先が信頼できるサーバーであることが上記設定を入れるための最低条件であることはいうまでもない。
久々に寒い冬になりそうで、そんなときはバッテリーの残量表示も当てにならないという話。
基本的に%表示は相対表示なのでもちろん信じてはいないのだが、冬場はそのブレが激しくなる。例えば30%からいきなりシャットダウンとか、電源入れなおすと幾分か回復したり。
リチウムイオン電池の常用温度は0度から30度ぐらいかな?
なので寒い朝に外で使うと常用温度外というわけで、バッテリー能力が落ちるのはしょうがない。できれば冬場はなるべく外気にさらさずに内ポケットに入れて歩くなどすると長持ちするのである!
AuroraだとIOPS課金が発生するのだが、RDS (Mariadb)だとボリュームに応じたクレジットを消化していく形となる。
1.6G程度のimoprtであればクレジットの範囲内で収まるのだが、90Gのデータをimportしたときは全然importが終わらないのでなんかおかしいと調べてみたら開始1時間ほどでIOPSが下がっていたという。
これを防ぐにはprovisionedのEBSを使えばよいのだが、初回Importだけだしなぁ。悩む!
当然といえば当然なのだが、EC2 AutoScalingとはEC2を一定数に保つ仕組みである。
しかし0からの状態でスタートすると、EC2を増やそうとして課金が発生する。
約2日後に0.40$の課金が発生したので気がついたという!
実験としてEC2を消してもすぐ新しいEC2が上がってくる。AutoScalingが効いているためである!
AutoScalingの設定で無効にするとEC2を消した後、立ち上がってくることはない!・・・はずなのだが、相変わらず立ち上がってくるので仕方なくAutoScalingを削除!!
EC2にアタッチするIAMロールは作成時にしかアタッチできない。
しかし信頼関係でec2を設定しているロールを作成したにもかかわらず出てこない!!
Webで探すと、その場でIAM roleを作成した場合は出てくるそうだが、なんかふに落ちない。一応作成したら、その新規作成ロールとともに、以前作成したのに出てこなかったロールが一緒に出てきた!
謎いけど、AWSコンソールのバグなのだろう。
CloudFrontではApacheの時と違い、/の時にindex.htmlをみに行くというDirectoryIndex的な動きはデフォルトではできない。
そのためLambda@Edgeを利用してリクエストのURLを書き換えるのだが、その時に紐づけるARNは通常のARNを使うとエラーで設定できない。
画面上のドロップダウンより、特定のバージョンを選択して、右上のARNをコピーする。
設定可能なARN
arn:aws:lambda:us-east-1:999999999:function:redirect:1
エラーとなるARN
arn:aws:lambda:us-east-1:999999999:function:redirect
自宅だと起きないのだが、出先でWIFIを使うとどうしても不安定になることがある。そんなときは別のマシンで試してみて、そちらで問題なければ相性問題ということにしている。
普通の人は一台しか持ってないだろうからなかなか交換するのは難しいかもしれないが、短時間であれば普段使っているスマホのテザリングで凌ぐといいだろう。
大したことに利用していないのだが、従量制課金なので毎日明細をチェックするようにしている。以前はAPIで自動化しようとしたのだが、料金APIをコールするたびに0.01$かかってしまうのでやめた(月平均0.5$なので!チェックするために料金が増えたら意味がない)
そして利用料金の割合を見ているとS3からのダウンロードが一番の割合を締めているという。VPSだとデータ転送量を気にしたことはないのだが、AWSだとこれが結構効いてくる。
もちろんEC2とかRDSとか使っている場合はその影に隠れて、データ転送料金など大したことないのだろうけど、我が家のようにバックアップとしてS3を利用している場合はどうしてもデータ転送料金がかさんでくるのである。
今月も0.5$の8割程度がデータ転送料金だ!
さすがにYahoo砲がくると一般の企業のHPではなかなか耐えることは難しい。
只今公式サイトを見ていると403になっているので、つながらないわけではなく、アクセス拒否になることが多い。
この場合は一時的な負荷なので、403の閲覧禁止よりは、503のサーバーが一時的に利用不可能のほうがいいかなと思われる。