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

カテゴリー: ITめいたこと (16ページ目 (31ページ中))

さくらインターネットのレンタルサーバのディスク増量

そういえば、さくらインターネットからメールが来ていて、今度、借りているレンタルサーバのディスクの容量が増えるらしい…が、よーく見ると、OSバージョンパップとも書いてある。

OS : FreeBSD 7.1 32bit → FreeBSD 9.1 64bit

…OSのバージョンが激しく上がるなぁ…とは思ったものの、OSを64bitするあたりからして、サーバのハードウェアをリプレース(つまり、新サーバは4GB以上のメモリを搭載)するんじゃないかって気がするんだけど、どうなんだろう。90分くらいあれば、旧サーバからHDDを取り外して新サーバに繋げばデータを吸い出せそうな気がするし。いや、RAID組んでるとそう簡単にもいかないから、例えば、NFSで繋ぐなんていう選択肢を採るんだろうけど。

仮に、もし、仮にこの度のディスク増量とOSアップデートが実態としてサーバのハードウェアのリプレースだとすると、メモリの増量やCPUの増強といったスペックアップも兼ねるから個人的にはありがたい。ちょっと楽しみな気がする…が、先日、勢い余ってレンタルサーバを契約し直してしまったんだけどなぁ(遠い目)

果たして実態はどうなるんだろう。

Amazon Cloud Driveが直らない…

先日、「Amazon Cloud Driveがなんだか切ない。」って記事を書いたのが、6月。それも、6月のアタマ。んで、今が9月中旬。

なんとなく3ヶ月くらい経過したモノの、私のPCで動いているAmazon Cloud Driveのデスクトップアプリ(Windows版)は、ローカルに.lockってロックファイルだけ作って、同期終了してしまう、と。この問題はAmazonのBTSみたいなものに載ってはいるらしく、思い出したようなタイミングでサポートからメールがやってくる。「担当部署で調査中」「問題が修正されるまでもちっと待ってくれ」みたいな趣旨のテンプレを貼り付けたメールが届く。AWSのサービスのリリースのスピード感を前提にすれば、恐ろしく時間がかかっているようにも見えるので、優先度が低い問題ってことなんだろう。

Amazon.comと、Amazon.co.jpでアカウントが別管理になってたのに、Kindleを日本でもリリースするくらいのタイミングで、なんとか2つのアカウントを連携させようとしたのか、統合しようとしたあたりが、やっぱりイケてなかったんだろうなぁ。

これ、日経コンピュータの「動かないコンピュータ」に載るくらいアレなことだと思うんだけど、とはいえ、Amazon.comに取材は不可能か(笑)

iPhoneの充電が完了したら速やかにケーブルを外すべきか。

こんな記事を見つけた。

iPhoneの充電率が100%を超えたあとも電流は流れている? – いまさら聞けないiPhone

iPhone 5の電源をオフにして30分経過したたあとも0.2A前後の電流を測定できたので、電気的に接続された状態にあることは確かです。やはり、満充電後はすみやかにケーブルを外したほうが、バッテリーの早期劣化防止にはプラスだといえます。

ふむ、どうやら「充電完了後にiPhoneに電力が流れている」から、充電完了後に、すみやかにケーブルを抜いた方が「バッテリーの早期劣化防止」につながるらしい。

例えば、AppleのWebサイトにはこんなことが書いてある。

リチウムイオンバッテリー

大部分のリチウムイオンポリマーバッテリーの充電は、デバイスのバッテリー容量の80%まで高速充電した後、トリクル充電に切り替わります。

どうやら、80%以降は「トリクル充電」になっているらしい。

「トリクル充電」についてWikipediaには、こんな記載がある。

トリクル充電

トリクル充電(とりくるじゅうでん) は二次電池の自然放電を補うために、絶えず微小電流により充電する方法である。

いかなる状態であろうが、二次電池に充電することが電池の劣化に繋がるというのは確かだろうけどなぁ…。さくっと抜いて実際に使うまでに自然放電、ないし、スリープ時の消費電力でバッテリーの残容量が減るわけだから、それを考慮するとトリクル充電させてバッテリーの残容量を維持しといた方がいいような気がしないでもない。要するに、バッテリーの劣化を気にしてさっさと抜いて置いておいて、いざ使うって時に残容量が減ってたら、それはそれで切ないのではないか、と。

ただし、(Androidだとそうもいかないような気がするものの)iPhoneはスリープ時にほとんど電力を消費しない、自然放電も充分に少ないというのなら、それはそうなんだろうけど。

SSDを使ってみたものの…

たまたま職場でノートPCが1台余っていたのでHDDを外してSSD(TOSHIBAの「THNSNH128GCST」)に換装した。CentOS6をインストールしてディスクI/Oが頻繁に発生するような重いバッチ処理を回してみれば速く処理が終わるに違いない!と意気込んでもろもろのインストールと初期設定をやってみた。

んで、CentOSのインストールが終わって、hdparmで読み込みのスループットを測ってみた。

/dev/sda:
Timing cached reads: 6524 MB in 2.00 seconds = 3265.55 MB/sec
Timing buffered disk reads: 946 MB in 3.00 seconds = 315.03 MB/sec

従来通りのHDDを積んだ開発マシンで測ってみたら、こんな感じだったので、やっぱり速い。

/dev/sda:
Timing cached reads: 4656 MB in 2.00 seconds = 2328.52 MB/sec
Timing buffered disk reads: 276 MB in 3.01 seconds = 91.61 MB/sec

簡単なベンチマークではあるけれど、結果は上々ということで、重いバッチを走らせてみたら、思ったよりも速くない。で、topを見ていて気づいたのは、OSはSSDとしては読み書きで待っていないようで、結局はCPUがボトルネックになってしまっているようだった。確かに、今回使ったノートPCはThinkPad X121eなので、CPU「Core i3-2367M」。廉価なノートPC向けのCore i3だからなぁ…(遠い目)

SSDに換装することで、ディスクのI/Oは速くなったけれど、結局は、ディスクがボトルネックだった状況から、CPUがボトルネックな状況に移行しただけの話か。SSDに換装するだけでは、システム全体としての劇的な性能向上までは見込めないという、当たり前の話(多少は速くなったとは思うけど)だったようだ。まぁ、SSDを使うことで、速いCPUを活かせるようになったという理解ができるのも確かなんだけど。

MariaDBとMySQL-libs。

今更ながら、MySQL互換のMariaDBを使ってみようと思いついた。サーバのOSはCentOS6.4のx86_64版。

で、MariaDBのサイトでyum向けのレポジトリの設定が取得できるので、ささっと設定ファイルを/etc/yum.repo.d/に置いてみた。

ただ、MariaDBを入れる前にMySQL関連のRPMを削除しようと思ったら、「mysql-libs」がやっかいな依存関係を持っていた。例えば、crontabsとかPostfixと依存関係があって、MySQL-libsをアンインストールしようとすると、crontabsとかpostfixも一緒に削除されてしまうようだった。なんか重要なモジュールとの依存関係って微妙だなぁと思っていたところ、試しにyumから「MariaDB-compat」を入れてみたら、MariaDBのモジュールでmysql-libsがリプレースされることがわかった。

これによって、PostfixなどのMySQL-libsに依存関係を持ったアプリケーションを維持しつつ、MariaDBを導入することができそうだ。さすがにこの辺の依存関係の解決が難しいようなら、しばらくMySQLを使っていようかという気になりそうで、(いつ頃に解決されたのかよくわからないけれど)yumレポジトリで依存関係を解決できたら楽だな、確かに。

カゴヤ・クラウド/VPSの「最大メモリー容量」って何だ。

さくらのVPSからの…

さて、そろそろ、さくらのVPS*1からどっかにお引っ越ししようかなぁと思って、VPSサービスを物色していたら、たまたま見つけたのがカゴヤジャパンのVPSサービス。

メモリーの表記の仕方

ざっと、カゴヤジャパンのVPSのサービスサイトを眺めてみたら、どうやらOpenVZを使った仮想化を使っているらしく。VPSの基盤にはKVMとかOpenVZが使われるが、どうせたいしたことをやるわけじゃないので、仮想化の基盤によってどうにかなるようなことは想定しづらい。ま、どっちでもいいだろう。

ただまぁ、結局のところ、この手のVPSのサービスは、メインメモリとHDDのサイズといったスペックと、その価格で比較するわけだが、カゴヤジャパンのVPSのメモリの表記の仕方がなんかちょっと気になった。

例えば、このページに書いてある「タイプA」のメモリに関する表記は以下のような感じだ。

保証メモリ 1GB

最大メモリー容量 2GB

「保証メモリー」と「最大メモリー容量」の意味がなんとなくわからない。いろんなVPSサービスを比較してみての感覚にすぎないが、月額870円くらいだとするとメインメモリは1GBがせいぜいだろう。だから、「保証メモリー」ってのは実際に、VPS上のOSから見えるメインメモリの容量で、それに、スワップを加えて「最大メモリー容量」と表記してる感じではないだろうか*2

確かに、スワップが使えないVPSサービスもあって、そういうサービスでメモリを使いすぎると、LinuxにおっけるOOM Killerがプロセスをなぎ倒していくみたいな惨事が起こるわけで、そういう意味ではSwapを利用可能にしているのであれば、その領域もメモリーとして書いちゃうことは嘘じゃないとは思うんだけど、なんかちょっとわかりにくい表記だなぁ、と。わかりやすいところに、最大メモリー容量ってのは…って説明を書いておいてもらえたらありがたいのだが…。

うーむ、さて引っ越し先のVPS、どうしよう。

*1:さくらインターネットがVPSを始めた辺りから使ってるので…そろそろ新しいハードウェアにお引っ越ししようかと

*2:一応、カゴヤジャパンのVPSのウリの1つにスワップが使えるってことって書いてあるし

WordPressに対するブルートフォース攻撃とか。

WordPressへの攻撃と、その防御

最近、WordPressへのブルートフォース攻撃が流行しているらしい。ま、WordPressが動いていれば、管理画面のURLはわかるわけだし、ブルートフォース攻撃はやりやすいだろうなぁ。しかも、デフォルトで「admin」アカウントが作成されるわけで、何にも考えていなければ「admin」ユーザーに対してパスワードを辞書式に当たればというわけで、クラッカーのみなさまに目を付けられやすいような気は確かにする。

ま、そのまま、攻撃を受け続けるというのも気持ちが悪いので、試しに「Login LockDown」というプラグインを入れてみることにした。このプラグインは、ログイン失敗の履歴を保存しておいて、一定期間における試行回数を超えたら、ブルートフォース攻撃(要するに、同じIPアドレスから何回もログイン試行する)と見なして、ログインを受け付けなくするらしい。

意外と…攻撃来てた

とりあえず、プラグインを入れてほったらかしにしていたら、ログインに失敗したアクセスを記録するテーブルにわらわらとレコードが出来ていた。たいしたPVがないブログに入れてみたけれど、2週間くらいの期間の間に、ログインに失敗した記録が500レコードほど出来ていた。思ったより多いなぁ…。うーむ。

もちろん、絶対にヤラれない自信がある人はともかくとしても、世の中の注目度とは裏腹に普通にWordPressのブルートフォース対策のためのプラグインとか入れておいた方がいいのかもしれない。もちろん、ブルートフォースを受けている間は、無駄にサーバのリソースが使われるわけで、それを防ぐということも多少意味があるかもしれないし。

Microsoft SQL Server 2008 Express R2のインストールが「Error code -2068578304」でコケる

HPのSystem Insight Managerをインストールしようとしたら、Microsoft SQL Server 2008 Express R2のインストールが始まったまでは良かったものの…該当サーバのWindows Installerのバージョンが古いままだったのでインストールに失敗してしまった。

で、Windows Installerのバージョンを更新して、再度、System Insight Managerを開始してみたところ、Microsoft SQL Server 2008 Express R2のインストールが再び走った。んで、一通り、インストールのためのHDDアクセスが行われた後、「Error code -2068578304」が出力されて、Microsoft SQL Server 2008 Expressのインストールに失敗。で、インストールを何回繰り返しても失敗し続けるので、インストールのリトライ以外の何か対処を行わないといけなさそう…だけど、このエラーメッセージではどう対処して良いのか、まったくわかんない。

…と途方に暮れて、Microsoft SQL Server 2008 Expressのインストール失敗事例を探していたところ、興味深いケースを見つけた。どうやら、Microsoft SQL Server 2008 Expressはインストールに失敗したら、そのまま資材を残してしまうらしく、それが次回インストール時に邪魔になってインストールに失敗するという…なんともアレなことが起こるらしい。…てか、どうなのよ、その仕様(汗)

SQL Server 2008 を再度インストールすると SQL Server のインストールが失敗する:
http://support.microsoft.com/kb/955404/ja

というわけで、コントロールパネルの「プログラムの追加と削除」を見たら、確かにインストールに失敗したはずのSQL Serverが残っていた(汗)というわけで、躊躇せずにアンインストール。再び、System Insight Managerからやり直してみたら、試行錯誤している中でWindows Updateでパッチを導入したのが原因で、一度、サーバを再起動しないとMicrosoft SQL Server 2008 Expressのインストールが進めない…(遠い目)

これだからWindowsはキライだ(汗)

[amazonjs asin=”B019O1F5TG” locale=”JP” title=”ASUS ZenPad7 TABLET / ホワイト ( Android 5.1.1 / 7inch touch / Snapdragon 210 / 2G / 16G ) Z370KL-WH16″]

さくらのVPSのSSDプランがメモリ増量…

なんと、さくらのVPSのSSDプランのメモリーが、お値段据え置きで増量されるらしい。ソースは、さくらインターネットのWebサイトの『「さくらのVPS SSDプラン」スペック改定実施のお知らせ』。

これまでは、HDDプランと、SSDプランでメモリーではメモリーの量が違っていた。そのため、SSDプランとHDDプランで差額が300円くらいのよく似たプランがあるけれど、SSDプランは、ストレージのアクセスが速いけれど、メモリーがHDDプランの半分の1GBだし、HDDプランはメモリーが多いけれど、ストレージがHDD…みたいな、なかなか悩ましいチョイスを迫られていることになる。

つまり、SSDプランとHDDプランのメモリーの量が同じになる(フツーのWebサイトに使うのであれば、SSDプランでも十分な容量なので、ストレージの容量の違いは気にしない)ので、プランの値段の差がSSDにすることのオプション料金と見なせるわけで、その差額がわずか300円ということになる。…こういうことであれば、フツーにSSDプランを選択するだろうなぁ。私も悩んだ末に(やっぱりメモリーが足りないのは辛いってことで)HDDプランのVPSを契約したのが、2週間前くらい。そこで、このタイミングでSSDプランがお値段据え置きでメモリーを増量するということで…orz なんで1ヶ月早くリリースしてくれなかったんだという切ない気持ちになる(汗)

Amazon Cloud Driveがなんだか切ない。

GoogleのストレージとAmazon Cloud Drive

そろそろGoogleもストレージを値上げ…というか、細かく書くと、今契約しているプランが廃止になるが、保存してあるデータを消すのが面倒なので、結果的には上位プランに移行せざるを得ない。ま、それって結局のところ、値上げと同じ事になりますなぁということで、似たようなサービスにデータを移動することができれば、Googleストレージを下位プランに移行できるなんてことにならないだろうか、と思って代替サービスの物色を始めた。

DropboxやSugarSyncの裏側は、Amazon Web Services(AWS)のS3じゃなかったかなぁ…ということで、いっそ、S3をそのまま使ってみようかとも思ったけれど、まぁ、開発用のツールはいくつかあれど、S3クライアントの使い勝手がいいような気もしないのでどうしようかなぁと思ったら、Amazonが「Amazon Cloud Drive」っていうDropboxみたいなサービスを提供しており、かつ、5GBまで無料なので、ちょっと使ってみることにした。

クライアントソフト、大事。

とりあえず、Amazon.co.jpのアカウントがあるから、それを使って試してみることにした。ログインもさくさくと進んだ。ついでなので、デスクトップに転がってた写真をブラウザ経由でアップするところは、すんなり完了。

あとはdropboxっぽく、デスクトップアプリで、ローカルのドライブと、クラウドのストレージが同期されたら…と、思ったが同期されない。さっき、写真をアップしたのに、デスクトップアプリは使用中のデータサイズが0だと表示していた。改めて、Webから写真が消えてないことを確認したら、当然、消えてない。

…え、どうしたんだ(汗)ってことで、考えて思い当たったのが、amazon.comのアカウント。kindleが始まったときに、洋書をちらっと読むためにアカウントを作っていたことを思い出した。amazon.co.jpでkindleのサービスが始まったとき、kindleで買った本をamazon.co.jpのアカウントに付け替えるみたいなことをやったことから、お互いが全く別物のアカウントであることはなんとなく知っていた。

で、その辺を踏まえてAmazonに問い合わせをしてみたら、IDとパスワードが同じ状態で、Amazon.co.jpと、Amazon.comにアカウントが存在すると、Amazon Cloud Driveのデスクトップアプリケーションは、Amazon.comの方に接続してしまうらしく…というわけで、Amazon.comのパスワードを変えてた。…が、やっぱり同期できない。さらに問い合わせしてみることにした。

« Older posts Newer posts »