chibiegg日誌

Seagete ST32000542ASのファームウエアアップデート

chibiegg — Fri, 06 Jan 2012 01:45:19 +0000

自宅のファイルサーバーのHDDのチェックをしていて、たまたま気づいたのですが。

うちで8台利用しているSeagateのST32000542ASのファームウエアが、「突然電源が切れる」「電源が入らなくなる」など、不具合のあるバージョンCC34でした。

恐ろしいので、アップデートすることに。

アップデータのダウンロード

http://seagate.custkb.com/seagate/crm/selfservice/search.jsp?DocId=213915&NewLang=en

このサイトからアップデータCDのISOイメージをダウンロードします。これをCDに焼いて使います。

アップデート

アップデートに利用するPCにアップデート対象のHDDだけを接続し、CDを入れた状態で起動します。この時、USB変換とか使ってはいけません。SATAで直接接続してください。

無事CDから起動すると、READMEが表示されるのでESCを押すと、次のようなメニューが表示されます。

メニュー

Lを押すとこのCDが対象としているHDDの型番とバージョンのリストが閲覧できます。

まず、HDDが正しく認識されているか、Sでチェックします。

HDD Scan

Sを入力してしばらくすると、写真の様に認識されたHDDの一覧が表示されるので型番とバージョンが対象のものである事を確認します。確認できたらESCでメニューに戻ります。

で、メニューからアップデートできれば良いのですが、できないらしいので、「Ctl+C」「y」と入力して、メニューを終了するとプロンプトが表示されます。

コマンド入力

ここに、写真のように、

FDL486A.EXE -m Hepburn -f HECC358H.LOD -s -x -b -v -a 20

と入力しEnterを入力すると、ファームウエアのアップデートが始まります。ここから完了するまで、電源を切ったり、キーの入力はしないでください。

下のように、プロンプトが表示されれば完了です。

アップデート完了

「FLASH-M.BAT」と入力すると、メニューに戻れるのでZでシャットダウンしました。

Can you crack it?

chibiegg — Sun, 11 Dec 2011 13:42:08 +0000

イギリスの政府通信本部(GCHQ)が現在採用活動の一環として、「Can you crack it?」と題して暗号解読クイズページを公開しています。

イギリス人であればこれをクリアするとエントリーフォームからエントリーできるみたいです。

Can you crack it?

で、先日大学の友達と相談しながらクリアしました。

Can you crack it? クリア

実はこれ、表示されてる問題をクリアしたと思ったらstage 2 of 3が出て来ます(笑)。

面白かったので、解答までの流れをブログに書きたいのですが、期日まであと1日ちょっとあるので、その後にします。

stm32f10x_can.c のバグについて

chibiegg — Sun, 27 Nov 2011 05:25:44 +0000

前回の投稿と打って変わって組込系の話題を。

最近STM32でCANとか使っているのですが、時々送信に失敗してしまうという問題がありました。

たまになので問題ないのですが、気になったので調べてみるとSTMicroが用意しているSTM32F10x standard peripheral libraryのバグでした。バージョンは04/16/2010 のV3.3.0と古いやつですが。

具体的に言うと、現在送信しようとしているメッセージの状態を確認する関数

CAN_TransmitStatus にあります。

ここでは CANxのTSRレジスタのTSS_RQCP0、TSR_TXOK0、およびTSR_TME0ビットの値を見て、

CANTXPENDING(送信中)、CANTXFAILED(失敗)、CANTXOK(成功)を返しています。

が、こんな風にレジスタにアクセスするようなコードになってます。

switch (TransmitMailbox)

  {

    case (0): state |= (uint8_t)((CANx->TSR & TSR_RQCP0) << 2);

      state |= (uint8_t)((CANx->TSR & TSR_TXOK0) >> 0);

      state |= (uint8_t)((CANx->TSR & TSR_TME0) >> 26);

      break;

    case (1): state |= (uint8_t)((CANx->TSR & TSR_RQCP1) >> 6);

      state |= (uint8_t)((CANx->TSR & TSR_TXOK1) >> 8);

      state |= (uint8_t)((CANx->TSR & TSR_TME1) >> 27);

      break;

    case (2): state |= (uint8_t)((CANx->TSR & TSR_RQCP2) >> 14);

      state |= (uint8_t)((CANx->TSR & TSR_TXOK2) >> 16);

      state |= (uint8_t)((CANx->TSR & TSR_TME2) >> 28);

      break;

    default:

      state = CANTXFAILED;

      break;

  }[/sourcecode]

これでは、レジスタに3回アクセスしてしまっており、アクセスとアクセスの間でレジスタの値が変わってしまうと変なstatusになってしまいます。その結果 default で CANTXFAILED がセットされてしまうというのが送信失敗の原因です(実際にはこの瞬間に成功しているが、失敗したと判断してしまう)。
最も修正量の少ない解決策は簡単で、CANx->TSRの値を一旦変数に入れてやればいいのです。
uint32_t _tsr =  CANx->TSR;

switch (TransmitMailbox)

  {

    case (0): state |= (uint8_t)((_tsr & TSR_RQCP0) << 2);

      state |= (uint8_t)((_tsr & TSR_TXOK0) >> 0);

      state |= (uint8_t)((_tsr & TSR_TME0) >> 26);

      break;

    case (1): state |= (uint8_t)((_tsr & TSR_RQCP1) >> 6);

      state |= (uint8_t)((_tsr & TSR_TXOK1) >> 8);

      state |= (uint8_t)((_tsr & TSR_TME1) >> 27);

      break;

    case (2): state |= (uint8_t)((_tsr & TSR_RQCP2) >> 14);

      state |= (uint8_t)((_tsr & TSR_TXOK2) >> 16);

      state |= (uint8_t)((_tsr & TSR_TME2) >> 28);

      break;

    default:

      state = CANTXFAILED;

      break;

  }[/sourcecode]

こんな風に。
で、最新のV3.5.0ではちゃんと修正されてました。
  switch (TransmitMailbox)

  {

    case (CAN_TXMAILBOX_0):

      state =   CANx->TSR &  (CAN_TSR_RQCP0 | CAN_TSR_TXOK0 | CAN_TSR_TME0);

      break;

    case (CAN_TXMAILBOX_1):

      state =   CANx->TSR &  (CAN_TSR_RQCP1 | CAN_TSR_TXOK1 | CAN_TSR_TME1);

      break;

    case (CAN_TXMAILBOX_2):

      state =   CANx->TSR &  (CAN_TSR_RQCP2 | CAN_TSR_TXOK2 | CAN_TSR_TME2);

      break;

    default:

      state = CAN_TxStatus_Failed;

      break;

  }[/sourcecode]

一度でアクセスするようになってます。でも返値変わってて、最新版に置き換えるのは大変そう...

nginxでSSL/TLSを使う

chibiegg — Tue, 22 Nov 2011 00:51:40 +0000

今回はSSL(https)を使えるようにするような設定をnginxにしてみようと思います。

証明書の取得

本来はSECOMやVeriSign等に有料で証明してもらうのですが、今回は以前にも紹介したCACertを載せときます。

ということで、証明書の取得は省略します。とりあえず、サーバーの秘密鍵 server.key とサーバーの証明書 server.cer が手に入った事にします。

nginxに設定

nginxでの設定は簡単で、既存の設定をコピーして、80番ではなく443番に変更し、SSLを有効にしてサーバーの鍵・証明書のファイルを指定してあげるだけです。

ちょっとその部分だけ書いてみます。

server {
	listen   443 default_server ssl;
	server_name	_;
	ssl_certificate /keys/server.cer;
	ssl_certificate_key /keys/server.key;

	location / {
		この辺は適当に
	}
}

リバースプロキシとしてnginxとして使っている場合も同様です。

名前ベースのバーチャルホストを使っている場合

ドメイン名を複数つかってバーチャルホストを使っている場合もあると思います。SSLではアクセスされたサーバー名がわかる前に証明書を渡さなければならないので、名前ベースのバーチャルホストでSSLは利用できませんでした。

が、SNI(Server Name Indication)というプロトコル拡張ができたので、名前ベースのバーチャルホストでも可能になりました。(ブラウザによっては対応してません)

設定は簡単で、httpと同じくserver_nameを設定するだけです。

リバースプロキシとして使っている場合は、証明書を変えるために、バーチャルホストの数だけServerディレクティブを作ってあげてください。

nginxでプロキシ&キャッシュサーバー

chibiegg — Thu, 17 Nov 2011 01:17:21 +0000

(多分)一般的なWebサーバーであるApacheは複雑な設定も可能で便利なのですが、その分重いのです。

どう重いのかというと、Apacheは一つのプロセスが一つのHTTPリクエストを同期処理で裁いてるのでその間は他の処理をしません。なので、同時アクセス数が増えるとApacheはプロセスをどんどん生成します。(あるいは後からきたリクエストを待たせる)

なので、アクセス数が増えると急激にパフォーマンスが落ちるという問題を抱えてます。(ほかにもプロセスIDが足りなくなってどんなにリソースがあっても最大プロセスIDで制限されてしまう)

で、最近話題のハイパフォーマンスWebサーバーがnginx(えんじんえっくす)です。

nginxは一つのプロセスで複数のリクエストを非同期で同時に処理します。なので、アクセス数が増えてもパフォーマンスが落ちにくいという特性があります。特に静的ファイルの場合は処理のほとんどがI/O待ちなので効果が大きいです。

そこで、PHPとかSVNとか設定がめんどくさいものはApacheに任せておいて、静的なファイルだけをnginxに処理させてみると、Apacheへのリクエスト数は激減するはずです。

例えば、このブログのトップページの場合PHPで生成されるHTMLが一個にたいして、CSSや画像等の静的ファイルが20個近くあります。単純計算で21個のリクエストのうち1個だけがApacheで処理されるのでApacheへのリクエストは約95%削減されます。

では設定してみましょう。OSはUbuntu Server 10.04(64bit)です。Apacheは既にインストール済みで運用されているとします。設定後はnginxがポート80で待ち受けて、Apacheはポート8080で待ち受けるということにします。

(記事の最後でキャッシュファイルをRAMに置くというのもやってみます)

nginxのインストール

そのままaptitudeでインストールすると0.7.65がインストールされてしまうので、nginxのPPAを追加してからインストールします。

$ sudo add-apt-repository ppa:nginx/stable
$ sudo apt-get update
$ sudo install nginx

設定ファイルは /etc/nginx/ にあります。sites-enableとかApacheに似た構造になっています。

リバースプロキシの設定

ではこの sites-enabled/default をこのように設定しましょう。

upstream backend {
    server 127.0.0.1:8080;
}

server {
    listen   80;
    server_name _;
    location / {
        proxy_redirect                         off;
        proxy_set_header Host                $host;
        proxy_set_header X-Real-IP            $remote_addr;
        proxy_set_header X-Forwarded-Host    $host;
        proxy_set_header X-Forwarded-Server    $host;
        proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;
        proxy_pass http://backend;

    }
}

これはリバースプロキシに必要な設定だけです。すべてのアクセスをローカルのApacheに引き渡してます。

Apacheの方はports.confでリッスンポートを80から8080に変更し、各サイトの設定も80から8080に変更してください。そして、Apacheとnginxを再起動させます。(Apacheを先に8080にしてからnginxを起動させる)

$ sudo /etc/init.d/apache restart
$ sudo /etc/init.d/nginx restart

これでブラウザからアクセスすると、nginxを経由してApacheが処理します。ので、今までとかわらないはずです。

ところが、問題があって、Apacheのアクセスログを見るとアクセス元が127.0.0.1になっちゃってるはずです。これを解消するためにmod_rpafをインストールします。

$ sudo apt-get install libapache2-mod-rpaf

これでApacheを再起動すると正しくアクセス元が扱われているはずです。実はこのためにnginxの設定に X-Real-IP をHTTPヘッダに追加する設定やらを書いているのです。mod_rpafはプロキシサーバーが追加した X-Real-IP ヘッダをアクセス元として扱うモジュールです。

mod_rpafは127.0.0.1からのアクセスだけに対して処理をするのでもし、リバースプロキシが他のホストにあるのであれば /etc/apache2/mods-enabled/rpaf.conf の RPAFproxy_ips をリバースプロキシサーバーのIPアドレスに変更してください。(すべてのX-Real-IPを信用するとアクセス元の偽装ができてしまうためです)

プロキシキャッシュ

では、元々の目標であった静的ファイルをnginxでホストする設定をしましょう。本来はnginxが静的ファイルを直接ディスクから取ってくるのがいいのですが、nginxがApacheと違うホストにある場合も考えられますのでその場合でも対応できるように、静的ファイルへのアクセスをキャッシュしておき、2回目以降の同じファイルへのアクセスはApacheに引き渡さないように設定してみます。

defaultをこのように編集してみます。

proxy_cache_path /var/cache/nginx/static_file_cache levels=1:2 keys_zone=cache_static_file:128m inactive=7d max_size=512m;
proxy_temp_path /var/cache/nginx/temp;

upstream backend {
    server 127.0.0.1:8080;
}

server {
    listen   80;
    server_name _;
    location / {
        proxy_redirect                         off;

        set $do_not_cache 0;
        if ($request_method != GET) {
            set $do_not_cache 1;
        }
        if ($uri !~* ".(jpg|png|gif|jpeg|css|js|swf|pdf|html|htm)$") {
            set $do_not_cache 1;
        }
        proxy_no_cache     $do_not_cache;
        proxy_cache_bypass $do_not_cache;
        proxy_cache cache_static_file;
        proxy_cache_key $scheme$host$uri$is_args$args;
        proxy_cache_valid  200 2h;
        proxy_cache_valid  any 1m;

        proxy_set_header Host                $host;
        proxy_set_header X-Real-IP            $remote_addr;
        proxy_set_header X-Forwarded-Host    $host;
        proxy_set_header X-Forwarded-Server    $host;
        proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;
        proxy_pass http://backend;
    }
}

この設定ではメモリ128M,ファイル最大512Mで、7日間キャッシュするファイルを /var/cache/nginx/static_file_cache に作成してます。

そして、do_not_cache 変数を用意して、0にしておき、GETでのアクセスでない場合と、静的ファイルでは無い場合にキャッシュしないようにその場合は do_not_cache を1にして、proxy_no_cacheを有効にしてます。静的ファイルの判断は正規表現でURLの拡張子を見ています。(注意しなければいけないのが、WordPressのページをパーマネントリンクで.htmlにしている場合です。その場合はキャッシュされないように外しておく必要があります。)

つまり、静的ファイルにGETでアクセスしたものだけキャッシュされます。

proxy_cache_valid はどのステータスのレスポンスをどの期間キャッシュするかを設定する項目で、この場合200なら2
時間、それ以外なら1分キャッシュすることになります。

あとは /var/cache/nginx/ ディレクトリを作成し nginx を再起動するだけです。

$ sudo mkdir /var/cache/nginx
$ sudo /etc/init.d/nginx restart

それでしばらくブラウザからアクセスしてみると、キャッシュディレクトリの容量が増えているはずです。

$ sudo du -ch /var/cache/nginx/static_file_cache
(中略)
91M	/var/cache/nginx/static_file_cache
91M	合計

本当にApacheへのアクセスが減っているのかは、Apacheのアクセスログをみてみてください。

さらに一歩

もう一歩高速化してみましょう。いまキャッシュファイルは/var/cache/nginxに置かれているので、結局キャッシュからの呼び出しのためにHDDアクセスすることになります。こいつを全部メモリ上においてしまいましょう。

間違えたり、問題が発生するとシステムに問題が起きるかもしれないのでわからないor不安ならやらないほうがいいです。

tmpfsを使えば、メモリ上の領域をファイルシステムにマウントすることができます。

/etc/fstab に次の一行を追加してOSを再起動します。

tmpfs	/var/cache/nginx	tmpfs	defaults,noatime,mode=1777	0	0

そうすると、/var/cache/nginx ディレクトリはRAM上に配置されます。

が、うちのサーバーはSSDにしてあったので効果はわかりませんでした。が、SSDの寿命を延ばす効果はあると思います。

WordPressを速くするにはキャッシュしかない！

chibiegg — Wed, 16 Nov 2011 14:44:48 +0000

漸くわかりました。PHPを速くするのは限界があるみたいで、生成したHTMLをキャッシュしとくしかないみたいです。

で、Quick Cacheプラグインをインストールして有効にすると改善しました。

WordPress with Quick Cache

レイテンシ12ms、転送4msです。

ハードウエアのスペックでごり押しはだめですね。ちゃんとキャッシュできるところはしましょうってことです。

WordPressはどうすれば速くなるのか、検証実験

chibiegg — Wed, 16 Nov 2011 13:52:36 +0000

さっきの投稿でWordPressが遅い事を書きました。で、先輩のさくらのVPS(nginx+fastcgi)では速いってことも書きました。

ということで、僕も借りてるさくらのVPSで一からセットアップして実験してみました。OSはデフォルトではなくUbuntu 10.04が入ってます。

今回検証したのは、WebサーバーはApache/2.2.14とnginx/1.0.9、RDBMはMySQL(Ver 14.14 Distrib 5.1.41, for debian-linux-gnu (x86_64) using readline 6.1)とPostgreSQL/8.4.9です。なので、合計4通りですね。

Apacheではmod_phpで、nginxでは後ろでspawn-fcgiが動いてます。

で、試してみた結果です。今回検証したいのは静的ファイルではなくPHPの出力なので、画像とかCSSがブラウザでキャッシュされてたりするのは気にしないでください。

Apache + MySQL + WordPress

Apache + PostgreSQL + WordPress

nginx + MySQL + WordPress

nginx + PostgreSQL + WordPress

平均もとってない1回こっきりのアクセスの結果なので互いの比較はそんなに意味がないです。

が、どれもレイテンシが数百ミリ秒あります。これは何回試しても同じでした。

あれ？…

先輩のVPSと同じ環境のはずなのになんでこんなに違うの？

WordPressが遅い…なぜ？

chibiegg — Wed, 16 Nov 2011 11:10:42 +0000

最近サーバーの設定を変えたり、リバースプロキシをしてる、HTTPのフロントをApacheからnginxに変えたり高速化を試みています。

が、どうしてもこのブログ(にかぎらず、稼働しているWordPress全部)が重い、というより遅いのです。
Memcachedでオブジェクトをキャッシュしてみたりしても改善されず…

で、Safariで開発ツールの「ネットワーク」をつかって取得の時間を見てみました。

Apache(mod_php) + WordPress ネットワーク時間

ここでPHPのファイルへのアクセスのレイテンシが334msもあることに気づきました。稼働しているどのWordPressもです。

で、WordPressはそうなのかと、さくらのVPSで運用してる先輩のWordPressを見てみると…

さくらのVPS nginx + WordPress(fast-cgi)

速い….レイテンシ45msです。静的ファイルはうちのサーバーのほうがレイテンシ含め速いので(どちらも304なので比較していいかな)、ネットワーク等の問題ではないみたい。

(あと、向こうはnginx+fastcgi(swanかな？)+WordPressですが、うちでもnginx+fastcgiにしてみたけど改善せず…)

なんで？

とりあえず、僕も借りてるさくらのVPSでDBをMySQLからPostgreSQLにしてみたり、いろいろ実験してみます。

Ubuntuでレンタルサーバその2

chibiegg — Fri, 31 Dec 2010 05:01:04 +0000

前回に引き続き、今回はProFTPdをセットアップし、MySQLのテーブルに記録されたユーザー情報で認証できるようにします。

まずはProFTPdのセットアップから。proftpdをapt-getでinstallするとproftpdの設定画面が出ます。

ProFTPd セットアップ

固定IPではないのでIPマスカレードを利用しないといけませんが、そのためにもスタンダードアローンではなくinetd経由にします。

それでは /etc/proftpd/proftpd.conf を書き換えていきます。

ServerName を好きな文字列に
ListOptions を “-l” に “-la” に
PassivePorts をコメントアウトしてポート範囲を決定(デフォルトは49152 65534)
MasqueradeAddress をコメントアウトして hogehoge.net(ドメイン名)に
ServerIdent を off で追加
RootLogin を off に
DefaultRoot を ~ に
RequireValidShell を off に

ここまではMySQLによる認証は関係ありません。これからMySQLで認証するための設定を追記します。この部分は「にわか鯖管のメモ – ProFTPD　～ MySQL + quota 編～」をもとにというかそのまま。

注意点はmodule.confをいじったときは sudo /etc/init.d/proftpd reload をしないとだめってとこです。

Ubuntuでレンタルサーバその1

chibiegg — Thu, 30 Dec 2010 14:12:39 +0000

今日からUbuntuでレンタルサーバを構築するまでの記録を載せようと思います。まぁ気力が続けばですけど。

それと、メモみたいなもので解説はたぶんしないとおもいます。LinuxをCUIで使えるぐらいの知識がないともしかすると読めないかもしれないです。解説でなく日記ですね。

レンタルサーバといっても身内、友人、後輩などに貸してるだけですのであまりセキュリティ、特にユーザー間のセキュリティはよろしくない設定をしていくかもしれませんのでそういう意味でもあまり当てにはしないでくださいね。

で、なぜいまさらサーバー構築なのかということなのです。普段はMac OSX Serverの上でこのページ含め個人のサーバと上記のレンタル部分とを稼動させているのですが、いわゆる公私混同の部分の管理がめんどくさくなってきた(なんとなくしんどくなってきた)ので他人の分は仮想環境のUbuntuに移動させてしまおうと思い立ったわけです。

で現状は、Ubuntu 10.04 ServerをLAMP + SSHのみでインストールしたまでです。

このあとユーザー情報をMySQLで管理してユーザーごとにApacheのバーチャルホストを設定し、proftpdはMySQL上の情報で認証できるようにしていくことが目標です。

chibiegg日誌

Seagete ST32000542ASのファームウエアアップデート

アップデータのダウンロード

アップデート

Can you crack it?

stm32f10x_can.c のバグについて

nginxでSSL/TLSを使う

証明書の取得

nginxに設定

名前ベースのバーチャルホストを使っている場合

nginxでプロキシ&キャッシュサーバー

nginxのインストール

リバースプロキシの設定

プロキシキャッシュ

さらに一歩

WordPressを速くするにはキャッシュしかない！

WordPressはどうすれば速くなるのか、検証実験

WordPressが遅い…なぜ？

Ubuntuでレンタルサーバ その2

Ubuntuでレンタルサーバ その1

Ubuntuでレンタルサーバその2

Ubuntuでレンタルサーバその1