ただのにっき。

ただつらつらと日記が書かれていくようです。

15ページ目 (40ページ中)

aws-cliで東京のS3バケットにファイルをアップロードしようとするとエラーが出る件

ECで動いている、CentOS6のマシンにaws-cliをインストールして、

aws s3 mv (とあるファイル) s3://xxxxx/xxxx/

とかやろうとすると、なんかエラー出た(汗)なんとなくこんなエラー。

HTTPSConnectionPool(host='(バケット名).s3.amazonaws.com’, port=443): Max retries exceeded with url

で、よーく見ると、ホスト名がおかしい。東京リージョンならエンドポイントはs3-ap-northeast-1.amazonaws.comだと思うんだけども。で、仕方ないのでdebugオプションを付けて実行してみたら、実行している途中で、Checking for DNS compatible bucketをやった後、 URI updated toで間違ったエンドポイントに書き換えられてるし…たぶん、これはaws-cliのバグじゃないのかなぁ…と思って探してみたら、githubにそれっぽいissueを見つけた。

Uploading files to S3 from EC2 instances fails on some instance types:
https://github.com/aws/aws-cli/issues/634

うーむ。なんかworkaroundっぽい何かが出てるけども…。ま、URLの書き換えられ方的に、東京リージョンじゃ無くて、US Standardリージョンでバケット作ればアップロード出来そうな気がしたので試してみたら、アップロードできた。どうせ、バックアップデータをs3に置いておくだけなので、ま、US Standardでもいっかという気がしてきた。

[amazonjs asin=”4822237443″ locale=”JP” title=”Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版”]

m1.smallのswap領域にエフェメラルストレージ。

EC2でm1.smallなインスタンスを起動してみた(本当はm3.mediumがいいんだけど、予算が足りない…。m3.smallとか用意してくれないだろうかって無理か)。AmazonLinuxを使ってたら、swapをどうするか心配しなくていいんだろうけど、やはりお金がない状況下なのでCentOS6を選択。

そしたら、swapが存在しない。EBSの上にファイルを作ってswapにしてもいいけど、データの出し入れで課金されるタイプのストレージを使ってたら(ま、たいした金額にはならないような気はするけど)、なかなか切ないことになりそうだけど、インスタンスストアというか、エフェメラルストレージを使ってswap領域を作ることにした。

…とはいえ、インスタンスストアを起動時に割り当てておいて、後は、/etc/rc.d/rc.localに対して、

mkswap /dev/xvdf
swapon /dev/xvdf

を追記しただけなんだけど。そしたら、m1.smallは、エフェメラルストレージとして160GBのHDDのストレージが使えるので、160GBのスワップ領域ができた(汗)なんかでかい。

起動時に/dev/xvdfに対してext4あたりのファイルシステムを作って、そこにファイルを置いて、それをswapに使ってもいいような気がしたのでちょっと試してみた。HDDの160GBの領域にファイルシステムを構築するのに時間がかかるのが…ちょっとなぁ。再起動がかかった後、(ファイルシステム作ってて)立ち上がってくるのに時間かかるのが実に微妙。うーむ。

DigitalOceanのSingaporeリージョンでIPv6

さっき、DigitalOceanから下記のようなメールが来てた。どうやらSingaporeリージョンでIPv6が使えるようになったらしい。手許でIPv6を使える環境というか端末がないので試しようもないんだけど(汗)シンガポールで動かしてるサイトのドメインにAAAAレコードでも設定してみようかな。

Since our launch, IPv6 has been one of the most requested features by our community. Today we are excited to announce that public IPv6 addresses are now available for all Droplets in our Singapore region.

DigitalOceanでNTPサーバを参照できない件。

DigitalOceanでVPSを起動してセットアップしているものの…なんかNTPサーバに時刻を参照しにいけてない様な気がするけど、ntp.pool.orgで公開されている、シンガポール国内のものと思しき、特定のNTPサーバにはアクセスできているという不思議な感じはなんだろう。

…と思って調べてみたら、DigitalOceanのサポートコミュニティのページにこんな記事(「Droplet in Singapore can’t sync NTP server.」)があった。どうやら、DigitalOceanのシンガポールのデータセンターでは、NTP reflection攻撃を食らっているらしく、とりあえず、NTPのパケットをブロックしているらしい。解決に向けて作業しているけど、いつまでに解決するというメドが立たないらしい。で、これはシンガポールのデータセンターだけの現象で、もし、どうしても時間を同期しなきゃいけないようなら他のリージョンにインスタンスを立ててくれって…ことらしい。

書き込まれたのが5月末くらいで6月の中旬でもまだNTPを使ったDDoSか…ま、タチが悪い。

EBSのVolumeTypeにSSD登場。

EC2でインスタンスを起動しようとしたら、VolumeTypeのところが「Maginetic」「General Purpose(SSD)」「Provisioned IOPS(SSD)」に拡張されていることに気がついた。例の如く、日本語のドキュメントは間に合っていない雰囲気だけど、英語のドキュメントは用意されている。→「Amazon EBS Product Details」を開いて、英語に切り替えると、それぞれのVolumeTypeの詳細が表示された。

端的には、SSD-backedなEBSが使えるようなったらしい。で、これまでのstandardのEBSはMagneticと改称された(ま、SSDじゃないってことはHDDなんだろう)。んで、そのIOPSは、Magneticが平均すると100IOPSくらいで、General Purpose(SSD)が使う容量の3倍のIOPSらしい。つまり、20GB使うと、60IOPS。Magneticより少ないじゃないか…と思いがちだけど、30分の間、3000IOPSまでバーストすることができるらしい。うーむ。30分ってどういうことだろう。3000IOPSが30分続くと制限される(制限されて、使っている容量の3倍のIOPSになるのかな)ってことかな、と勝手に理解しておこうかと思うけど、…なんか違うような気もするな(汗)

んで、料金体系を眺めると、東京リージョンで、「General Purpose(SSD)」が$0.12/GBで、「Maginetic」が$0.080/GB。だいたいSSDの方が1.5倍くらいの値段か。ただ、これに加えて、「Maginetic」の方はI/O requestの課金が加わるが、「General Purpose(SSD)」にはそれがないっぽい(「Provisioned IOPS(SSD)」にはありそうだけど)これまでのEBSのbillを見る限り、割とI/O requestの課金で課金されている雰囲気なので、GB単価で1.5倍の価格差はあれども、意外とと「General Purpose(SSD)」がお得なのかもしれない。

ま、LinodeやDigital OeceanがSSDを積んで、それなりに安いVPSをリリースしているので、業界のリーダーのAWSとしては無視できないってことなんだろうか。

追記:
AWSのブログに、「General Purpose(SSD)」のIOPSに関する解説を見つけた。うーむ、難しい。。。

【AWS発表】新しいSSDベースのElastic Block Storage
http://aws.typepad.com/aws_japan/2014/06/new-ssd-backed-elastic-block-storage.html

GooglePlayでアプリを更新しようとすると「容量不足」

近頃、Androidのアプリの更新頻度が上がってる気がするのは気のせいか。ま、アップデートってのはユーザの関心を引きつけるいい機会なので、大してバグフィックスしなくてもアップデートをかけてみるのはありだろうな。特に、アップデートするからってGoogleから課金されるわけでもないし。

そんなわけで、ぱらぱら出てくるアップデートを適用しようとしたら、「容量不足」って怒られた。本体内のメモリ(いわゆる、機器メモリー)が埋まってしまっているらしい。うーむ。で、どのアプリがどれくらいのストレージを使っているか調べてみたら、Chromeが185MBとか…。私のXperiaの機器メモリーは2GBしかないから、結局、Chromeで10%近くが埋まっていることになる。

とりあえず、ブラウザのキャッシュなどが溜まってることが疑われたので、設定からプライバシーを開いて、キャッシュなどをごそっと消してみたけど、ストレージが空かない。うーむ。で、Google Playで表示されているChromeのアップデートは30MB近く。Androidのアプリは差分更新とかしないから、ダウンロードするサイズ=アプリのサイズのはずだ。で、そのapkを機器メモリーに展開したら185MBにもなるもんだろうか。

一旦、キャッシュと一緒にcookieなども消しちゃったのでChromeに消えちゃまずい情報は残っていない。そこで、一旦、Chromeをアンインストールしようと思ったけど、アンインストールはできないのでアップデートを削除してみた。その後、もう一回、アップデートを適用し直して見たら、機器メモリーの使用サイズが70MBちょっとになった。

Androidのアプリアップデートの仕組みに明るくないけど、要らなくなったapkとか、保存してあるんだろうか。ま、とりあえず、機器メモリーの無駄遣いは解消できたっぽい。

[amazonjs asin=”B012SXM6XU” locale=”JP” title=”エイスース SIMフリースマートフォン ZenFone 2 Laser(Qualcomm Snapdragon 410/メモリ 2GB)16GB ホワイト ZE500KL-WH16″]

MariaDB 10.0系がいつの間にかGAに

ふと、MariaDBのWebサイトを見てみたら、2014年3月31日にリリースされた、Ver 10.0.10からGA(Stable)でリリースされていた。うーむ、ぜんぜん気付いていなかった。そして、そのバグフィックス版であるVer.10.0.11が2014年5月12日にリリースされているではないか。

ま、これまではMariaDB 5.5を使っていたけれど、これからはMariaDB10.0を使うことにしてみようか。とりあえず、WordPress向けのデータベースとして、簡単に使ってみようと思う。

What is MariaDB 10.0?
https://mariadb.com/kb/en/what-is-mariadb-100/

さくらのVPSの初回起動時に応答が無くなるように見えるけど、気長に待つ

最近、さくらのVPSを契約する機会があったんだけど、初回起動時にちょっと戸惑ったのでメモ。

どうやら、さくらのVPSは既にCentOS6がインストールされていて、初回起動時に、インストールされているRPMを一気に更新する(もしくは、その時点で細々としたRPMがインストールされるのかな)仕様らしい。つまり、ユーザーがSSHで初めてログインするときには、最新版になっているという仕掛けなのだろう。

ただ、最初にディスクイメージに載っているCentOS6が古いバージョンのままになっているせいか、初期起動時のRPMの更新量が多いようだ。起動した後、ユーザーが使えるようになるのに、結構な時間がかかる。一応、リモートコンソールを覗いてみるもののプロンプトが返ってこないので、不安になるのだが、VNCコンソールを開いてみると

Updating RPMS on system:

って出力されたまま、固まっているのが見える。インストールした後、自動で再起動がかかって、やっとユーザーがログインできるようになるんだけど、なんかちょっとさぁ…と思ってみたが、よく考えてみると、まだrootパスワードを送ってくるメールが届いていないのであった。起動してもログインする術がない(汗)

というわけで、さくらのVPSは、申し込んだ後、さくっと起動だけかけておいて、後はrootパスワードのメールが届くのを気長に待つというのがお約束のようだ(最初からインストールされているディスクイメージを破棄して、OS再インストールすればrootパスワードを決められるのでメールを待つ必要が無いけども…そこまでがっつく必要もないか)

ちなみに、Webから申し込んでrootパスワードのメールが届くまで20分かかった。

[amazonjs asin=”4797380942″ locale=”JP” title=”新しいLinuxの教科書”]

Gmailから、さくらインターネットのレンタルサーバ経由でメールが送れなくなった。

仕事でさくらインターネットのレンタルサーバを使っている。それも、メールサーバとして使っていて、POPでメールを取りに行くし、SMTPでメールを送っている。ただ、さくらインターネットのレンタルサーバのサービスとして用意されているWebメールは使い勝手がいまいちなので、Gmailと連携させて使っていて、特に、Gmailからメールを送る際には、借りているさくらインターネットのサーバを経由して送信する設定にしていた。

んで、昨日。社内から「Gmailからメールを送れない」という調査依頼がやってきた。昨日まで、普通にGmailからさくらインターネットのレンタルサーバ経由でメールを遅れていたのに、突然、メールが送れなくなったらしい。Gmailに帰って来たエラーメッセージはこんな感じ。

The error that the other server returned was:

550 5.7.1 <XXXX.XXXX.co.jp(送信先のメールアドレス)>… Command rejected

…Command rejectedって…。レンタルサーバのコントロールパネルから調べてみたら、「国外IPアドレスフィルタ」って設定項目が増えていて、それがOnになっていることに気がついた。要は、国外のIPアドレスをブロックする新機能が追加され、デフォルトでOnらしい。

で、「国外IPアドレスフィルタ」について調べてみたら、SMTPも対象になっているらしいので、とりあえず、Offにしたら、正常な状態に復旧した。

つまり、Gmailのサーバがどこにあるかはよくわからないとしても、国内にはない可能性が高く、この「国外IPアドレスフィルタ」に引っかかっていたようだ。

さくらインターネットが海外からのDDoSに悩まされている雰囲気はあって、ユーザーとして協力したい気もするけど、こういう形で影響が出るとなると、ユーザーとしてはOffにせざるを得ない…うーむ。

iOSアプリ開発のためのOTAでSSL必須ですとな。

Appleが突然何か仕様や設定を変えたことで、悲鳴が上がるというのは珍しいことでもないと思うけど、今度は、iOSアプリの開発現場で悲鳴が上がったらしい。

iOS7アプリ開発者の悲鳴にGMOが神対応、SSL無償提供開始 【@maskin】より

事の発端は、iOS7.1アップデートにより、開発中のアプリの配布方法に制限が出たことによるもの。

 開発者は、開発中のアプリをテストするための(AdHoc版の)ファイルを、ケーブルで端末に転送したり、サーバーに配置してインターネット経由で配布(Over the Air=OTA)するのが常。

 特に後者のOTAは、チーム全員や関係者に配布するために必須の方法だった。

 ところが、iOS7.1をインストール/アップデートした端末からは、SSL証明書を使用したサーバーからでないとダウンロードできない仕様に変更され、それまでのOTAの方法が使えなくなってしまった。

iOS7.1にアップデートしたら、開発用に使えなくなるなんてなかなかシビれるなぁ。事前に「iOS7.1にアップデートしたら、OTAするのにSSL証明書が必要ですよー!」ってアナウンスをして欲しいような気がするが…ま、Appleに期待しても無駄なんだろうけど。

それで、GMOのGlobalSignがSSL証明書を無償発行して神対応らしいけど…ま、そんな開発用の端末でしか使わないSSL証明書なんて、安物で十分な気がする。例えば、RapidSSL*1なんて年額2,100円で証明書を発行してくれるから、無償だけど短期間なGlobalSignを使うよりもいいかもしれない。で、RapidSSLの証明書はこちらで日本語のUIで買える。

しかしまぁ、iOS7.1以前に共用型のレンタルサーバとかを開発用に使ってたりすると、SSL証明書は安く手に入っても証明書をインストールできなかったりするから、iOS7.1以降は、さくらインターネットのVPSとかを使って開発用のサーバを立てて、そこに激安SSL証明書を入れてOTAするって感じだろうか。

…ふと、思い出したけど、OTAするだけなら、さくらインターネットのレンタルサーバなら利用できる、ワイルドカードな共用SSLでも充分なのか…(遠い目)

*1:一応、ジオトラストがやってる格安SSL証明書発行サービス

«過去の 投稿 新しい 投稿 »