カテゴリー「パソコン・インターネット」の151件の記事

2015/07/09

Qiitaって何なのさ

最近Androidプログラミングを始めまして、色々ひっかかったところをWeb検索して調べています。

そうしていると、qiita.comに投稿された記事がヒットすることも多く、それらを見ているうちに気になったことが何点かでてきました。


1. Qiitaへ記事を投稿することについてのモチベーション/メリットはなんだろうか
私の場合ですと、自分が調査した/実行した結果、他の人にも役立ちそうだと思われればここ自分のblogに投稿するわけなんですけども、そうではなく、qiitaに投稿しようと考えるのはどういう理由があるのだろうか、と。
これについては、こちらがまとまっていました。
ただ、上記のエントリやそのリンク先では、Qiitaを使うことは前提としてあり、その上でblogとどう住み分けるかが大きな関心ごとになっていますね(Qiitaの用途として挙げられていることは、別にQiitaを使用しなくともblogでも満たせる)。
SEOが強力、すなわち検索結果の上位に来やすい、ということを重要事項であると考えるのであればQiitaを利用するメリットはある、が回答になるでしょうか。


2. 私自身はあまりQiitaサービス利用者になりたいと思わないのだろうが、なぜだろうか
考えてみたところ、以下の理由が思い浮かびました。
  • 自分のblogに投稿することと比較してQiitaに投稿するメリットが感じられない
  • 例えばGitHubやStackOverflowだと、サービス機能自身に対しても感謝しており、自分もコミュニティの一員として貢献したいと感じ、ユーザになっている
    • 逆に言うと、Qiitaが提供しているサービスについてはそのようには感じないのでアカウントを作りたいとは思わない(Qiitaの場合、感謝の対象はあくまで記事投稿者)


3. obsolatedな記事に対してQiitaは何をするのか
これが今一番気になっていることなんですが、
  • 検索上位に来やすく目立つが、古くて役に立たないことも少なくない
  • しかし非ユーザがコメントを残すことができない(そしてコメントするためだけにアカウントを作りたいとも思っていない)
特に後者は、blogで実現できていたことをサボタージュしていて、このことが調べものをしている今の私にとって非常にストレスを感じさせる要因になっています。
で、こんなエントリを書くものだから余計に計画通り進まなくなる、と…

2015/07/05

UbuntuでXが固まった時に安全に再起動できるようにしておくための設定

Ubutuのバージョンを上げたのが原因か、最近Xが固まってしまう事象がたまに発生します。

この状態で放置していると、 /var/log/kern.log や /var/log/syslog に nouveau 関連のエラーが吐かれ続けてハードディスクも大変なことになってしまいました(基本的にスリープ設定に任せているので、それまでは就寝前等でもPCは起動したままだった)。
official wikiの「フリーズしたUbuntuを安全に再起動するには」の項の通り、

フリーズした場合、Alt+PrintScreen+R+S+E+I+U+Bと押していく

とやれば再起動できるんですが、このMagic Sysreq機能、デフォルトでは無効化されてるようでした。

フリーズしてからでは遅いので、予め有効化しておく必要があります。
/etc/sysctl.d/10-magic-sysrq.conf を開き

kernel.sysrq = 1

と書き換えておきましょう。
参考:

Android Studioで整形しようとするとスクリーンロックがかかる

UbuntuとAndroid Studioでショートカットキーがかぶっているからなのですが。

システム設定 > キーボード > ショートカット > システム の「画面をロック」設定を変更することで解消しました。

Keyboardsetting

2014/12/07

CentOS6 Dockerイメージを--privilegedモードで動かすとinitが途中で止まる

CentOS6上にgitlabのdockerコンテナを作成して動作させる: 発火後忘失 に記載した通りセットアップを行った後、

$ docker run -d --privileged centos:centos6 /sbin/init

で動作させてこのコンテナに入りpstree -aを実行してみると、

sh-4.1# pstree -a
init
  |-rc.sysinit /etc/rc.d/rc.sysinit
  |   `-start_udev /sbin/start_udev
  |       `-udevadm settle
  `-udevd -d

の表示のまま動かないんですよね。udevadm settleで止まったまま。

私の知識では原因の想像もつかないので、前回の記事では--privilegedオプションを付けないようにしました。

再起動するとsshで入れなくなって、init使えないのかなあ?なんて思ってたらこんなオチでした。

--privilegedオプションも何のために必要なのか実はよくわかってないんですけれども…(ドキュメント読んでもさっぱりなのでした…)

 

 

以下余談。

centos:centos6 とかで指定した際に取得できるイメージ、これはいつでも同じものが取得できるとは限らないんですよね…

例えば今取得するとCentOS6.6のイメージが落ちてくるが、3ヶ月後にコマンドを打つとCentOS6.7のイメージだったり。

Dockerfile がgithubなんかで公開されてたりしますが、作成者と同じ環境で実行したとしても異なる結果になる可能性があるわけで。

 

DokerってよくImmutable Infrastructureの顔みたいな感じで紹介されたりしてますが、その第1行目からimmutableさをぶっ壊してるのがちょっと笑えた、というお話でした…

CentOS6上にgitlabのdockerコンテナを作成して動作させる

昨日CentOS7上で環境構築したのですが、実際に使用するのはCentOS6だということが今日分かり、再度構築手順を見直しました。

CentOS 6.5 (x86_64) - Release Media 上で行っています(yum updateしたのでバージョンはCentOS6.6になりました)。

昨日のCentOS7と合わせてcentosというユーザを作っています。余談ですが、紹介される手順だと作成したユーザでsshログインできないですね。authorized_keysファイルをコピーした後、

# chmod -R og-wrx /home/ec2-user/.ssh

をする必要があります。

 

CentOS7の時と異なり、SELinuxを無効化して、--privileged オプションを使用しないようにしています。理由は別のエントリで記載します。

また、postgresqlの使用するメモリ(shared_buffer)設定値をかなり小さくしています。デフォルト値だとpostgresがエラーとなり初期設定を完了させられないためです。

 

以降、本題です。

Dockerのインストールと初期設定

取り敢えずupdate。

$ sudo yum update -y

 

EPELからdockerパッケージを取得してインストール。

$ sudo yum install -y epel-release

$ sudo yum install -y docker-io

(バージョン1.3なので、docker execが使用できます!)

 

SELinuxを無効化。

$ sudo setenforce 0

またその他、 /etc/selinux/config 開き、SELINUXの値をpermissiveに変更する。

 

dockerサービスの起動。及び、OS起動時の自動起動設定。

$ sudo service docker start

$ sudo chkconfig dokcer on

 

CentOS7のときと同様、dockerグループにcentosユーザを所属させ、ログインし直し。

 

gitlabのインストール

CentOS7と違ってオフィシャルイメージからすぐgitlabコンテナを作成できます。

 

コンテナを起動。

$ mkdir /home/centos/gitlabdata

$ docker run -d -p 80:80 -p 44:44 -v /home/centos/gitlabdata:/var/opt/gitlab --name gitlab centos:centos6 /sbin/init

 

起動したコンテナに入る。

$ docker exec -i -t gitlab /bin/sh

 

言語設定(参考)。

# localedef -vc -i ja_JP -f UTF-8 ja_JP.UTF-8

 

公式に記載されている通り追加のパッケージを導入。

# yum install -y openssh-server postfix cronie

 

/etc/ssh/sshd_conf を編集し、44番ポートで待ち受けるように変更。

 

/etc/pam.d/sshd を編集します(参考: ubuntu - Why is it needed to set `pam_loginuid` to its `optional` value with docker? - Stack Overflow)。

session    required     pam_loginuid.so

という行のrequiredをoptionalに変更し、下記のようにします。

session    optional     pam_loginuid.so

 

サービスを起動。

# service postfix start

# chkconfig postfix on

# service sshd start

# chkconfig sshd on

 

gitlibパッケージをインストール(最新版のURLは公式ページを参照してください)。

# curl -O https://downloads-packages.s3.amazonaws.com/centos-6.6/gitlab-7.5.1_omnibus.5.2.0.ci-1.el6.x86_64.rpm

# rpm -ivh gitlab-7.5.1_omnibus.5.2.0.ci-1.el6.x86_64.rpm

 

/etc/gitlab/gitlab.rb を開き、external_urlの値を 'http://<IPアドレス>' とでもしておきます。

また、44番ポートを使用するようにするため、下記を追記します(参考: GitLab で使用する SSH のポート番号を変更する | バシャログ。)。

gitlab_rails['gitlab_shell_ssh_port'] = 44

同じく/etc/gitlab/gitlab.rb ファイルに、postgresの仕様メモリ量設定を小さい値にします(参考。実際に使用する際にはこの設定は小さすぎるかもしれませんが、大きくしても問題が発生しないようにする方法をまだ調べられていません[文末に追記有])。

postgresql['shared_buffers'] = "16MB"

 

gitlabの設定を実行。

# gitlab-ctl reconfigure

 

以上で完了。webブラウザでec2インスタンスにhttpアクセスすればgitlabスタートページが表示されるはず。

初期id,passwordは公式サイトに記載がある通りそれぞれ root と 5iveL!fe 。

 

追記:

Dockerコンテナ内でPostgreSQLを動かす場合のshared_buffers設定について、やはりよくぶち当たる問題のようで、検索するといくつか対処方法が書いてありました。

Docker 1.0 でDBを動かすときの共有メモリの設定 - 技術野郎の復習

こちらのページでは2つの方法が記載されています。

  • kernel.shmmaxを変更する。そのために/procを書き込み可能にして再マウントする。
  • lxcドライバを使用する

 

まず前者の/procの再マウントなのですが、permission deniedと言われてできませんでした… --privileged オプションを付けてコンテナを起動すれば可能なのですが、CentOS6 Dockerイメージを--privilegedモードで動かすとinitが途中で止まる: 発火後忘失 で書いた通り、なぜかinitが途中で止まるので今回は採れない手段なのです。

 

次に後者なんですが、こちらもinitが途中で止まってしまいました。なのでshmmaxの値が変更できるのかどうかは確認していません。

ちなみにCentOSでlxcドライバを使用したい場合は、 /etc/sysconfig/docker を開き、other_argsに --exec-driver=lxcを設定し

other_args=--exec-driver=lxc

と編集した後dockerサービスを再起動すれば良いです(リンク先解説の通りdocker info コマンドで実行ドライバは確認できます)。

 

従って、結局、16MBのまま運用しております。

2014/12/02

CentOS7上にgitlabのdockerコンテナを作成して動作させる

OfficicialのCentOS7用RPMを用いてgitlabコンテナを作成する手順です。

EC2のCentOS 7 (x86_64) with Updates HVMで試しています。

先の記事を読まれるとわかる通り、私はdockerのことほとんど知らないので、あまりここの記述を鵜呑みにしないようにご注意ください。

 

Dockerインストールと初期設定

取り敢えずupdate。

$ sudo yum update -y

 

dockerのinstall。

$ sudo yum install -y docker

 

dockerサービスの起動。及び、OS起動時の自動起動設定。

$ sudo systemctl start docker.service

$ sudo systemctl enable docker.service

 

vigrコマンドで自分(ユーザ名: centos)をdockerグループに所属させます。dockerグループに所属しているとdockerコマンド使用時にsudoしなくて良くなるそうです。
(※vigrでなくusermod -Gで編集するように解説しているページも多いです。)

 

グループ編集を反映させるため一旦ログアウトしてログインし直し。

 

dockerコマンドを実行してみて正常動作することを確認。

$ docker info

 

systemdが動作するCentOS7イメージの作成

gitlabのRPMがsystemd関連を要求するので予め導入しておきます。

参考: CentOS 7のDockerコンテナ内でsystemdを使ってサービスを起動する - Qiita

 

officialのcentos7イメージにはfakesystemdとやらが入っている。これを本物のsystemdに入れ替え、今回用いるイメージを作成する。

$ docker run -it --name temp centos:centos7 /bin/bash

# yum swap -y fakesystemd systemd

# exit

$ docker commit temp yukihane/centos7-systemd

 

コンテナ内作業のための準備

nsenter(及びdocker-enter)コマンドを導入。

$ docker run --privileged --rm -v /usr/local/bin:/target jpetazzo/nsenter

/usr/local/bin に上記2コマンドがインストールされます。ちなみにdocker1.3からはdocker execという標準コマンドで同等機能が実現できるようです(ので近い将来この作業は不要になるでしょう)。

 

コンテナを起動。sshdはホストOSの使用ポートとかぶらないよう44番を使用する前提です。

$ mkdir /home/centos/gitlabdata

$ docker run --privileged -d -p 80:80 -p 44:44 -v /home/centos/gitlabdata:/var/opt/gitlab --name gitlab yukihane/centos7-systemd /sbin/init

 

起動したコンテナに入る。

$ docker-enter gitlab /bin/sh

 

言語設定。

# localedef -vc -i ja_JP -f UTF-8 ja_JP.UTF-8

 

gitlabのインストール

公式に書いてある通りopenssh-serverとpostfix、そしてその他必要になるパッケージを導入します。

# yum install -y openssh-server postfix hostname cronie

 

/etc/ssh/sshd_config で44番ポートを使用するように設定変更します。

 

起動設定。

# systemctl enable sshd

# systemctl start sshd

# systemctl enable postfix

# systemctl start postfix


gitlibパッケージをインストールします。(URLは公式ページを参照してください。)

# curl -O https://downloads-packages.s3.amazonaws.com/centos-7.0.1406/gitlab-7.5.1_omnibus.5.2.0.ci-1.el7.x86_64.rpm

# rpm -ivh gitlab-7.5.1_omnibus.5.2.0.ci-1.el7.x86_64.rpm

 

/etc/gitlab/gitlab.rb を開き、external_urlの値を 'http://<IPアドレス>' とでもしておきます。

また、44番ポートを使用するようにするため、下記を追記します(参考: GitLab で使用する SSH のポート番号を変更する | バシャログ。)。

gitlab_rails['gitlab_shell_ssh_port'] = 44

 

/opt/gitlab/embedded/cookbooks/gitlab/recipes/selinux.rb を開き、すべてコメントアウトします。(SELinuxの設定のようですが、centos7イメージではSELinuxは無効に設定されているようなので。)

 

gitlabの設定を実行。

# gitlab-ctl reconfigure

 

以上で完了。webブラウザでec2インスタンスにhttpアクセスすればgitlabスタートページが表示されるはず。

初期id,passwordは公式サイトに記載がある通りそれぞれ root5iveL!fe

 

最終イメージ作成

次回から起動するためのイメージを作成しておく。

# exit

$ docker stop gitlab

$ docker commit gitlab yukihane/centos7-gitlab

(ここで作成したイメージって、gitlabのデータベースなどが含まれていないので不完全なんですよね。作法的にこれで良いのかは分かりません。)

gitlabを5秒で試そうとしたができなかった(dockerの入門解説が欲しい…)

gitlabの導入は結構面倒、という噂だけは聞いていて、そしてdockerを利用すれば楽に導入できる、なんてのもちらと聞いた記憶があったのです。

そんなわけでググってみたところ、

Dockerで5分くらいでGitLabを試す - Qiita

なんていうまさに私が望んでいたことが書かれていそうなページを見つけました。

で、sameersbn/docker-gitlabを試したわけなんですよ、CentOS7上で。

するとさっぱり動作しないのです。エラーログも全く出ないので何が原因か見当もつきません。

 

仕方が無いのでDockerfileなぞを眺めていると、どうもubuntu上にgitlabやpostgresを構築するようだ、というのが分かりました。

CentOSの上でubuntuを動かそうとしているのか、それってどういう仕組み(どこまでの(ソフトウェア)リソースをホストOSとゲストOSで共有してるのだろうか、等)なんだろう、と思いつつ、一抹の不安が。

そんなこんなで/dev/nullにログを捨ててる箇所なんかを直しつつ実行していると、やっとエラーが見つかりました。

error while loading shared libraries: libdevmapper.so.1.02: cannot open shared object file: No such file or directory

うーむ、わからん。共有オブジェクトって、ホストOSとコンテナ内で共有してたりするんだろうか(OS違うのに?それが原因?)などと思いつつググってみると、パッケージングのバグっぽい…?

Bug 1026545 – dockerinit fails with "libdevmapper.so.1.02: cannot open shared object file"

何が悪いんだかさっぱり分からないのですが、外の環境の設定が中の環境に影響を与えている…?

 

どうやらコンテナ内のOSをホストOSと同じものに合わせれば発生しないようなので、ubuntuをCentOSに変えれば!と思ってDockerfile見てみたら、ubuntu依存の記述なんですね…というわけで挫折。

 

 

ということでまとまりが無いのですが、何が言いたいかと言いますと…

世にあるDocker入門の記事や書籍って、コンテナ型とスーパバイザ/ハイパーバイザの違いを説明した後、いきなりdockerコマンドの使い方とかに入っちゃって、全然概観がつかめないのですよ。

コンテナ型はホストOSとリソース共有してるから軽い、ってそれどこまで共有してんの?ってのが上の事象に出会った時の疑問なんですが、その辺の解説がもっと欲しいなあ、と。(公式ドキュメントもイマイチですよね)

検索しても同じ内容ばっかりなんですよ、すごく不毛です…今気付いたのですが、もしかするとLXCやらlibcontainer辺りをキーワードにした方が良いんでしょうかね。

2013/05/25

Windows8で画面の色を設定する

前回「Windows8の色設定がひどい」で記載した通り、設定画面からできる色の変更は限定的なものに留まり、Windows7以前のような文字色、背景色、選択色などの変更はできなくなっていました。

しかしながら、Windows8では前回示した例のように、全体的に色基調が淡い感じになっとており、エクスプローラーの非アクティブ時選択色以外でもわかりづらいところが複数あることに気付いたため、これを何とかしたいと考えました。

 

Webを検索したり試行錯誤した結果、以下の手順でWindows7相当の色設定が可能であるようです。

 

  1. デスクトップを右クリック > 個人設定 を選択し、表示された設定画面上でハイコントラストテーマのいずれか(4種類あると思いますがどれでも構いません)を選択する。
  2. レジストリエディタを開き、 HKEY_CURRENT_USER\Control Panel\Colors にアクセスする。
  3. ここに色設定を行う箇所とその箇所のRGB値が保存されているので、必要に応じてRGB値を変更する。
  4. レジストリを保存した後、デスクトップを右クリック > > 個人設定 > 色 を選択し、表示されたダイアログ上の「変更の保存」ボタンを押す(何も変更する必要はありません)。
  5. 一度サインアウトすると設定が反映される。

 

レジストリを編集する前にはバックアップを取っておいた方がよいでしょう。また、上記レジストリ値の一部は、4.で表示した設定ダイアログから変更することが可能です。

4.の手順を踏まない場合、一部の箇所(サインイン画面など)に設定値が反映されないようです。

 

レジストリ項目の意味は、私が調べた限りでは以下の表のように予想されます。「対応するコントロールパネル項目名」に記述があるものは、前述した設定ダイアログから編集が行える項目です。

これらのレジストリ項目名を検索するといくつかのページがヒットするので、Windows8で新たに導入された項目ではないようです。それらのサイトの説明も参考にできると思いますが、Windows8で新しく意味が追加されたり意味が変わっているようなものもあります(たとえば”Window”はウィンドウの背景色だけでなく、サインイン画面やモダンUI背景色も兼ねる。また、Scrollbarは名前に反してスクロールバーの色に影響を与えない。など)ので注意が必要です。

前回のエントリの最後に「あまり期待する結果になりません」と記載したのもこれが原因で、予期しない箇所同士の色設定がひとつの項目にまとめられているため、どうしても妥協せざるを得ない箇所が出てくると予想されるからです。例えば「ウィンドウの背景は白色に近い色にしたいが、モダンUIの背景色は白色だと明るすぎるので変更したい」といったことが不可能です。

 

レジストリ項目名 対応するコントロールパネル項目名 補足
ActiveBorder (無し) Active Border(使用されていない?)
ActiveTitle アクティブウィンドウのタイトル・背景  
AppWorkspace (無し) Background of older MDI apps and no document open ButtonFace
Background (無し) デスクトップ背景色
ButtonAlternateFace (無し)
ButtonDkShadow (無し) 3Dコントロールベベルの影の色
ButtonFace ボタン・背景  
ButtonHilight (無し) 3Dコントロールベベルのハイライト色
ButtonLight (無し) 3Dコントロールのハイライト色
ButtonShadow (無し) 3Dコントロールの影の色
ButtonText ボタン・前景  
GradientActiveTitle (無し) Active Title Bar Gradient(Win8ではタイトルにグラデーションがかかっていないので使用されない?)
GradientInactiveTitle (無し) Inactive Title Bar Gradient(同上)
GrayText 淡色表示のテキスト  
Hilight 選択されたテキスト・背景  
HilightText 選択されたテキスト・前景  
HotTrackingColor ハイパーリンク  
InactiveBorder (無し) Inactive Border(使用されていない?)
InactiveTitle 非アクティブウィンドウのタイトル・背景  
InactiveTitleText 非アクティブウィンドウのタイトル・前景  
InfoText (無し) ツールチップ文字色
InfoWindow (無し) ツールチップ背景色
Menu (無し) メニュー背景色
MenuBar (無し) メニューバー色
MenuHilight (無し) メニューハイライト色
MenuText (無し) メニューテキスト色
Scrollbar (無し) (メニューの中のチェックボックス背景色に使われていた)
TitleText アクティブウィンドウのタイトル・前景  
Window ウィンドウの背景  
WindowFrame (無し)  
WindowText テキスト  

参考として、比較的デフォルトの基調に近いレジストリ設定をこちらにおいておきます。前述の手順2.の代わりにこれを適用してみてください(再度記載しておきますが、事前にレジストリのバックアップは取っておいた方が良いでしょう)。適用後は下記のような感じになります。

win8colorizing

 

(このエントリを記載している最中に気付いたのですが、Windows Live Writerは作成中のコンテンツが今回行った色設定にひきずられてしまいますね…黒文字で書いているつもりの箇所に、画面表示色通りの黄色fontタグが埋め込まれたり。OSのせいなのかアプリ固有の問題なのか分かりませんが、アクセシビリティ用の機能としても不十分ですね。)

参考:

Windows8の色設定がひどい

 

世間では、モダンUIがマウス+キーボード向けではない、とか、スタートメニューを復活させるべきだ、といった向きでWindows8が批判されているのをよく目にします。

個人的にはその辺のことは慣れの問題であって、Windows8を拒否する理由には全くならず、従来のバージョンと比較して特に不便になったとは感じていません。

しかしながら、自分の他に不満を挙げている人をほとんど見かけたことがないのですが、表題に挙げた色の設定だけは許容範囲を超えていると感じています。

 

こちらはWindows8のエクスプローラーの一部をキャプチャしたものです(がぞクリックで拡大)。”ユーザーフォルダ”が選択状態になっているのはおそらくわかると思いますが、その他に”ローカルディスク(C:)”も選択状態であるのがわかるでしょうか。

win8explorer

…私の環境ではほとんど区別がつきません。こうして部分的に切り取るとさすがに目立ちやすくなるのですが、より広いデスクトップの中でこのような表示が為されても気づかないのです。

ディスプレイのコントラストを高めに設定しているとより一層区別がつきにくくなります。私のディスプレイでは、コントラストを68%まで上げると全くわからなくなりました(通常は初期設定の50%で使用していました)。

 

そんなわけでOSの設定で選択色を変更しようと思い、設定をを探したのですが、Windows8では色の設定に関しては次のダイアログの中で設定できるものしかありません。

win8color

ウィンドウの枠など、一部にのみ影響する1種類の設定だけです。ちなみにWindows7以前ではこちらの”ウィンドウの色とデザイン”のように、選択項目の色を含めて複数種類に関する設定が行えていました。

 

設定は1種類、と書きましたが、正確にはもうひとつ、視覚色覚障碍者向けのモード設定があり、そちらであればちゃんと区別がつく配色になります。

こんな感じになりますが。

win8contrast

これはこれでドギツ過ぎて困ります…(ちなみにハイコントラストテーマ使用時には、一部のデザイン設定に関する機能が無効化されるようです)

なんでこんな両極端な設定しか選べなくなっているんでしょうね。

 

Windows8では本当にこんな設定しかできないのかと調べたところ、ハイコントラストテーマの色を、レジストリを直接編集することで変更し、もう少しまともな色遣いにできることがわかりました。次回はそちらについて記載しようと思います(先に記載しておきますが、あまり期待する結果にはなりません)。

2012/10/09

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切り替えるようなものではないと思いますが、留意を。

 

参考:

より以前の記事一覧

other sites

  • follow us in feedly
  • github
  • stackoverflow

ソフトウェアエンジニアとして影響を受けた書籍

  • Christain Bauer: HIBERNATE イン アクション

    Christain Bauer: HIBERNATE イン アクション
    理論と実践が双方とも素晴らしい製品であるHibernate。本書はそのプロダクトを書名に冠していますが、Hibernateを使うつもりがなく、ORマッピングの解説書として読むにしても十分な良書です。Second EditionとしてJava Persistence With Hibernateという書籍も出版されていますが、残念ながら現在のところ 和訳はされていません。-インアクションは2.xの、Java Persistence-は3.1の頃のものなので、最新版とはちょっと違うところもあることに注意。 (★★★★★)

  • アンドリュー・S・タネンバウム: 分散システム 原理とパラダイム 第2版

    アンドリュー・S・タネンバウム: 分散システム 原理とパラダイム 第2版
    クライアント/サーバシステムを構築する上で必要となる知識が総論されてます。Web技術者も、フレームワーク部分を開発するのであれば必読。 (★★★★★)

  • Joel Spolsky∥著: ジョエル・オン・ソフトウェア

    Joel Spolsky∥著: ジョエル・オン・ソフトウェア
    前述の書籍「ソフトウエア開発プロフェッショナル」をより砕いたもの、という感じでしょうか。 前書きではプログラマでなくSE向けの本のように書かれているが、プログラマが読んでも面白い本であると思われます。 SEになった新人(あるいはそういう会社に入る/入りたての人)にとっては、これからどういったことが仕事を遂行していく上で起こりえるのか、どのように考えて行なっていけばいいのか決定する助けになると思います。 元は″Joel on Software″というブログの記事で、web上でも一部日本語で読めます。 http://japanese.joelonsoftware.com/ (★★★)

  • ドナルド・C・ゴース,ジェラルド・M・ワインバーグ: ライト、ついてますか

    ドナルド・C・ゴース,ジェラルド・M・ワインバーグ: ライト、ついてますか
    問題解決(一昔前のの流行語で言うところの『ソリューション』)能力は、システムエンジニアのスキルとして備えるべきもののうちのひとつです。しかし、これは難しい。学校で出されるテストと違い、唯一の、(問題提出者が想定している)解を求めるだけが「問題解決」では無いからです。そもそも、何が問題なのか、それは本当に問題なのか、それは本当に解決すべき問題なのか、その問題解決方法は正しいのか、などを解決しなければ、「その解は正しいのか」に辿りつくことができません。この本の最も良いところのひとつは、本があまり厚くないこと。すぐに読めるし、何回も読み返す気になるでしょう。 (★★★★★)

  • スティーブ・マコネル: ソフトウエア開発プロフェッショナル

    スティーブ・マコネル: ソフトウエア開発プロフェッショナル
    コードコンプリートで有名なスティーブマコネルの著書。新人SEに読んで欲しい。個人として業界の中でどうあるべきか、組織としてどうあるべきか、SEのプロ意識とは?SEの心構え概論、といったところでしょうか。また、業界における資格の重要性についても説かれています。この業界では資格が特に軽んじられる傾向がありますが、この傾向はどんな弊害をもたらすのか、将来的にこの業界は資格に対してどのような姿勢で臨んでいくべきなのか。日経BP社では(他の出版社もだが)最近、似たような類いのあまり面白くない書籍が乱出版されていますが、この本は別格だと思うので安心して購入して欲しいと思います。 (★★★★★)

無料ブログはココログ