JDK7では署名アルゴリズムが変更になっているためINSTALL_PARSE_FAILED_NO_CERTIFICATE エラーが発生してapkがインストールできない

JDK7ではデフォルト署名アルゴリズムが変更になったそうです。このため、Androidアプリ(.apk)署名時に、昔に書かれたblogエントリなどを参考にコマンドを叩いて署名しても、表題のエラーが発生して端末にインストールできません。

jarsignerコマンドのオプションに -sigalg MD5withRSA -digestalg SHA1 を追加する必要があります。

いや、何回も書いていますがちゃんと1次ドキュメントに当たらないといけないですね…

参考：

• Signing Your Applications | Android Developers

Caution: As of JDK 7, the default signing algorithim has changed, requiring you to specify the signature and digest algorithims (-sigalg and -digestalg) when you sign an APK.

[追記 2015/07/18]
(今となっては)古いAndroid SDKを用いてビルドする場合にも同じ問題が発生するそうで、その場合の対策はこちらに書かれています。

• JDK7でAndroidアプリをリリースビルドする方法 — KaoriYa

ReadyNAS Duo v2のrsync速度を改善する

[追記]以下に書いたような方法でSSHでわざわざリモートアクセスして設定ファイル書き換えなくても、WebUIの共有＞RSYNCで、GUIから設定できますね…

前回、rsyncがsshdのせいで遅い、と書きました。これについての対策です。

タイトルにはDuo v2と書きましたが、おそらく同一ファームウェア/アーキテクチャを採用しているNV+v2を始め、公式フォーラムを見る限り、その他のReadyNASでもCPUがボトルネックになっているのであれば同様の方法で改善できるのではないかと思います(適用するAddOnやWebUIにはもちろん差異があるはずですが)。

あまりまともにrsyncを使用したことが無かったので知らなかったのですが、rsyncはデーモン経由で転送を行うことができ、この場合sshを通らないので暗号化/復号コストがかからないのでCPU使用率を下げられるようです。

以下、ReadyNASでの設定手順です。なお、以降ReadyNASのIPアドレスを192.168.11.10として記載していますが、適宜自身の環境に合わせて読み替えてください。

注意: 下記記述の実行は自己責任の下で行ってください。

1. https://192.168.11.10/admin/index.html にアクセスし、RsyncをONにする。(これを行うことでrsyncdが立ち上がる設定になる、はずです。私はセットアップ完了直後にONにしたので確証はないのですが…)
2. こちらにある”Enable Root SSH Access”のARM版EnableRootSSH_1.0-arm.bin(Duo v2/NV+ v2の場合)をダウンロードする。
3. Web管理画面の「アドオン」のページ右上にある「アドオンの追加」ボタンを押して、先程ダウンロードしたアドオンを選択する。なお、ダウンロードページに書かれている通り、このアドオンをインストールした場合サポートを受けられなくなる場合があることを認識してください。
4. アドオンをインストールすると再起動を促されるのでそれに従う。
5. 再起動完了後、sshでReadyNASにログインする。IDはroot, passwordは初期設定時に登録したadminのものと同一。
6. ps aux | grep rsync コマンドでrsyncデーモンが起動していることを確認する。また、引数に指定されている設定ファイルの場所も確認( /etc/frontview/rsync/Shares.conf のはず)。
7. 上記で確認した設定ファイルを編集し、デーモン経由で転送できるようにする。設定方法の詳細はmanや後述参考URL先を参照。
8. 下記コマンドでrsyncdを再起動する。
   /etc/init.d/rsync restart

これでデーモン経由の転送が行えるようになりました。実行コマンドについても後述参考URL先を参照してください。

私の環境では

rsync –auv . hoge@192.168.11.10/c/backup/

とした場合は8MB/s程度なのに対し、

rsync –auv . rsync://192.168.11.10/backup

だと16MB/s程度と、2倍の差が出ました。(しかしこれでもWindowsよりずいぶん遅い…ソースファイルみたいな細かいファイルが大量にあるので、そういったファイルの性質が原因かも。要調査。)

参考URLにあるとおり、デーモン経由の転送はNFS+rsyncより負荷が軽いそうなので、ファイル転送はこれでいこうかと思います。

[追記]WebUIで一旦rsyncをoffにした後再度ONにすると、設定ファイルが書き換わるようです(具体的にはread only = no の記述が消えていました)。あまり頻繁にON/OFF切り替えるようなものではないと思いますが、留意を。

参考:

• rsync でディレクトリの同期（バックアップ） - maruko2 Note.
• NETGEAR ReadyNAS • View topic - Trouble when using Rsync on the i86 platform

データバックアップ用にNASボックスを購入した

HDDが壊れかかって初めて気づいたのですが、自炊の電子書籍って容量当たりの価格、そして自分にとっての価値が他のコンテンツと比べてずいぶん高いんですよね…

そんなわけで、既に多くの自炊電子書籍を抱えている私にとってバックアップ機器にそれなりのお金を払う価値はあるかな、と思い立ち、NASボックスの購入に至りました。

購入したのはネットギア社のReadyNAS Duo v2(Amazon)と、Seagate社3TB(2.7TiB)のHDD ST3000DM001(Amazon)。NAS用HDDとしては Western Digital社のWD Redブランドが人気のようですが、以前書いた通り、今回WD社のHDDは避けた結果こうなりました。RAID1構成にするためHDDは2台購入したので合計3万円とちょっとです。

(少し本題とはずれるのですが)今回初めてAmazonでHDDを購入したのですが、やっぱりあの書籍を購入したときと同じあまり厚みのない箱で送られてくるんですね…運搬中の衝撃とか大丈夫なのか少し心配になります。

あまり時間に猶予が無さそうだったのでそんなに詳しく調べたわけではないのですが、NASボックスの価格以下のような部分に効いてくるようです。

• ベイ数。つまり取り付けられるHDD最大数。
• 低価格のものはRAID0/1のみ対応のものが多いですが、値段が上がるとRAID5/6対応のものも。
• CPUアーキテクチャ。低価格のものはARM、それより上のレンジに入るとAtom、といった具合。
  • AtomのものであればPC向けバイナリが流用できたりして、多機能性にも影響するようです(？)
  • 個人向けはソフトウェアRAIDのものが多く、RAID5などの誤り訂正符号計算時間、ひいては転送性能に影響する、らしいです。
• 付加的インタフェース。iSCSIが付いてたり。

セットアップ完了直後にベンチマークを取ったところ、Sequential Writeが11.5MB/sほどで予想よりずいぶん遅く冷や汗をかきましたが、どうやらケーブルがカテゴリー5のものだったようで、ケーブル交換することで62MB/s程度、その他の転送速度もこちらで記載されている数値とほぼ同様になりました。(11.5MB/sでバックアップ取ろうとするとかなり時間がかかるので、ギガビットイーサネット環境は必要かな、と思います。)

一方、Linuxからrsyncすると(主にsshdが原因で)CPU使用率が100%に張り付いており、おそらくWindows(Samba)程は速度が出ていないのでは無いかと思います(※正確に計測したわけではないです)。ちなみにNFSも利用できますが、そちらは試していません。

外部のクラウド環境にバックアップを保存する、というのも少し考えたのですが、(制限つきだが)かなり低価格(参考)のAmazon Clacierでも1TB借りると1年で120ドル程度、これと手元にデータがある利便性を比較すると…、というわけです。もちろん障害耐性などクラウドサービスの方が良い面も多くあると思うので、要件次第では個人でもこのようなクラウドサービスに軍配が上がることはあると思いますが。

「エラー 0x80070091: ディレクトリが空ではありません。」のエラーが出てディレクトリ削除できない

おそらく他の原因の場合もあるのでしょうが、上記のエラーが出てフォルダが削除できないのは大抵そのHDDが壊れかかっています。読み取りすらできなくなる前にバックアップを取りましょう。

他の予兆として、HDDの読み書きに著しく時間がかかるようになる、それに伴って起動/終了に時間がかかるようになる、といったものもあります。

chkdskコマンドを実行すれば削除できるようになる、といったことが書かれている方も検索するといらっしゃるようですが、この状態でchkdskをかけると、最悪、今読み取れているファイルも読み取り不能になります(経験あり)。chkdskかけるにしても重要なファイルのバックアップを取ってからにしましょう。

ちなみに、このディスクのS.M.A.R.T.情報は以下のようになっていました。

恐ろしいですね…

(ちなみにこのディスク、ここで書いていた低速病のものです。今までよく持った、というべきでなんでしょうか…？)