読者です 読者をやめる 読者になる 読者になる

渡米生活。(日記)

渡米生活。本家から切り離しました。あまり渡米生活に関係のないプログラムネタや音楽ネタなど。

Scientific Linux 6.3インストールログ3:software raid の設定とnfs mount

Linux設定の続き。

HDD5台でsoftware raid 5を組む

まず、5台のHDDをsoftware raid用にフォーマットする。fdiskを使う。
最初の1台目のデバイスが/dev/sdbとする。

fdisk /dev/sdb

...何か英語でいってくるかも

コマンド (m でヘルプ): m
コマンドの動作
   a   ブート可能フラグをつける
   b   bsd ディスクラベルを編集する
   c   dos 互換フラグをつける
   d   領域を削除する
   l   既知の領域タイプをリスト表示する
   m   このメニューを表示する
   n   新たに領域を作成する
   o   新たに空の DOS 領域テーブルを作成する
   p   領域テーブルを表示する
   q   変更を保存せずに終了する
   s   空の Sun ディスクラベルを作成する
   t   領域のシステム ID を変更する
   u   表示/項目ユニットを変更する
   v   領域テーブルを照合する
   w   テーブルをディスクに書き込み、終了する
   x   特別な機能 (エキスパート専用)

コマンド (m でヘルプ): p
領域番号 (1-4): 1
最初 シリンダ (1-17365, default 1): < enterを押す
Using default value 1
終点 シリンダ または +サイズ または +サイズM または +サイズK (1-17365, default 17365): < enterを押す
Using default value 17365

コマンド (m でヘルプ): t
Selected partition 1
16進数コード (L コマンドでコードリスト表示): fd
領域のシステムタイプを 1 から fd (Linux raid 自動検出) に変更しました

コマンド (m でヘルプ): w
領域テーブルは交換されました!

ioctl() を呼び出して領域テーブルを再読込みします。
ディスクを同期させます。

大体こんな感じで完了。同じ作業を他の4つのHDD(sdc, sdd, sde, sdf)でも繰り返す。

mdadmを使ってRaid 5 にまとめ、マウントする

mdadm -C /dev/md0 -l5 -n5 -f /dev/sd[bcdef]1

とやると、デバイス名/dev/md0 で1つのディスクとして見える。

ところで、このRAIDの設定というのは、一度書き込まれると残っているものらしい。
システムをクリーンインストールでアップデートして、RAID5のデータも書き直しかな、と思ったが、元と同じ配置でHDDをセットしたら、何もしなくても勝手に1つのデバイスとして認識した。ただし、デバイス名は何故か/dev/md127になっていた。

ここまでできたら、自動マウントの設定。/dataにマウントするものとする。
/etc/mdadm.confというファイルを作り、以下の情報を記入。

# vi /etc/mdadm.conf
DEVICE /dev/sd[bcdef]1
ARRAY /dev/md0 devices=/dev/sdb1,/dev/sdc1,/dev/sdd1,/dev/sde1,/dev/sdf1

更に、/etc/fstabに以下の情報を追加。

# vi /etc/fstab
/dev/md0     /data     ext4     defaults   1   2

初回は自分の手でマウントする。

# mkdir /data
# mount -a

ファイルサーバでnfsサーバの設定。

rootで作業。
/etc/exportsを変更。以下の行を加えると、ファイルサーバ上の/dataディレクトリにアクセス可能になる。(XXX.XX.XX.XXXはマウントを許すIP)
IPとカッコの間にスペースをあけないこと(違う意味になる)

/data XXX.XX.XX.XXX(rw,sync) XXX.XXX.XX.XXX(rw,sync)

他のマシンから見たときにrootによるアクセスを許す場合は、no_root_squashオプションをつける。

見せる相手が沢山の場合は、たとえば

/data 192.168.1.0/24(rw,sync,no_root_squash)

のようにも書ける。
ただしこれは、自分の(ローカル)IPが192.168.1.1等で、ぶら下がっているマシンが192.168.1.2, 192.168.1.3...といった場合。


サービスの再起動

# service nfs restart

クライアント側の設定

nfs4を動かすと、何をやっても(no_all_squashをサーバー側でたてていても)マウント側でnobodyの持ち物になってしまうので、nfs3を動かす設定にする。
(nfs4はuidとは異なったファイルで所有者を判断しているらしいが、その設定方法がわからない。ndf3でも、サーバーごとにuidやgidが異なっていたら正しいユーザの持ち物としてマウントされないので注意。)

# vi /etc/nfsmount.conf

Defaultvers=4 のコメントアウトを外し、
Defaultvers=3  に変更

autofsのダイレクトマップを使う。

/etc/auto.masterに以下の行を追加

# vi /etc/auto.master

# mount data dir
/-       /etc/auto.data    -rw,intr

# 以下の行はコメントアウト(NIS, NIS+を使わない場合)
#+auto.master

/etc/auto.dataを作成し、以下の1行を記入して保存。

# vi /etc/auto.data
/data -ftype=nfs,rw 192.168.1.1:/data

192.168.1.1はこの場合ファイルサーバのIP.

最後にデーモンを再起動。

# /etc/rc.d/init.d/autofs restart

以上

qTranslateをとりあえずwordpress 3.9対応にするパッチ

wordpressの多言語プラグイン、やはりqTranslateが圧倒的に便利なので、ほとんどの管理サイトで使っています。

以前はwpの新バージョンが出て2週間ほどですぐにアップデートが出ていたのですが、最近開発者様がお忙しいのか、なかなかwp3.9対応版が出ません。

で、無理矢理wordpress 3.9.1 でqTranslate 2.5.39を使うと、編集画面でこんなエラーがでちゃうんですね。。


The qTranslate Editor has disabled itself because it hasn't been tested with your Wordpress version yet. This is done to prevent Wordpress from malfunctioning. You can reenable it by clicking here (may cause data loss! Use at own risk!). To remove this message permanently, please update qTranslate to the corresponding version.


バージョンが合わないからエディタはオフにした、もう一回オンにしてもいいけど、データ消えるかもしれないよ、やるなら自己責任で!
といったところでしょうか。

無理矢理エディタ使ってデータ消されてはかなわんので、まあ、エディタは別に使えなくてもいいか、と思っていたら、表示の方にもこんなエラーがでてしまいました。

PHP Catchable fatal error: Object of class WP_Post could not be converted to string in ../wp-content/plugins/qtranslate/qtranslate_core.php on line 455

さすがにこれはまずいので、どうすべ、と解決策を探したらこんなのがでてきました。

Fix qTranslate with WordPress 3.9

要するに、qtranslate_core.phpのqtranslate_core.phpのqtrans_dateFromPostForCurrentLanguage関数を以下のように変更してしまえば良い、ということらしい。

-function qtrans_dateFromPostForCurrentLanguage($old_date, $format ='', $before = '', $after = '') {
+function qtrans_dateFromPostForCurrentLanguage($old_date, $format ='') {
  global $post;
- return qtrans_strftime(qtrans_convertDateFormat($format), mysql2date('U',$post->post_date), $old_date, $before, $after);
+ return qtrans_strftime(qtrans_convertDateFormat($format), mysql2date('U',$post->post_date), $old_date);
}

先頭に-が書いてあるラインがもとのコード、+が書いてあるラインが変更。
つまり、-のラインを+のラインで置き換えれば良い、ということです。

WP3.9からget_the_date関数の引数が変わっちゃったのが問題で、qtrans_dateFromPostForCurrentLanguage関数はフックとして使われているのだけど、3.9以降はオプション引数ひとつしか取れないんだそうな。

これで、表示の方の問題は治ります。
エディタをオンにしても安全かどうかは知りませんので、トライする方は、バックアップをとった上で自己責任で♪


……とここまでやったら、既にqTranslationにパッチをあてたmqTranslationなるものが出ているらしいと判明(笑)

Wordpress多言語化プラグインmqTranslate

mqTranslateをインストールして、qTranslateを無効化し、mqTranslateの言語設定をして有効化するだけで良いらしい。
(Language Switcherのウィジェットを使っている場合は、その設定も必要)


早速入れてみたら、エディタのバグも治ってました。
というわけで、一番簡単なのは、本家qTranslateのアップデートが出るまで、このプラグインを使うことの模様。
なんだかタイトルと違った結論になってしまった。。(笑)

Scientific Linux 6.3インストールログ4:Condorのインストール

ジョブ管理システムのCondorをインストール。
面倒なので全部rootで作業。
「condorのコンパイル」までは共用ディスクの上でやっても良い(ただしクラスタのシステムが全部同じ場合)。

user condorを作成.ログインを禁止するため、invalidなシェルを指定。

$ su
# groupadd -g 1000 condor
# useradd -u 1000 -g condor condor
# usermod -s /bin/false condor

足りないファイルをとってくる

必要なファイルは以下を参照。
https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=BuildingHtcondorOnUnix

# yum install uuid-devel
# yum install uuid-c++-devel
# yum install pcre-devel
# yum install libuuid-devel
# yum install libtool-ltdl-devel
# yum install glibc-static
# yum install expat-devel.x86_64

cmakeは2.8以上でないと駄目らしいので、別にとってきてインストール。

# wget http://koji-hub.batlab.org/mnt/koji/packages/cmake/2.8.4/2.osg.el6/x86_64/cmake-2.8.4-2.osg.el6.x86_64.rpm

# rpm -ivh cmake-2.8.4-2.osg.el6.x86_64.rpm

condorのソースをとってきてコンパイル

standard makeはとことんコケたので、もうuwセットでインストールすることにする。

# cd <somewhere>
# tar -zxvf condor_src-8.1.4-all-all.tar.gz 
# cd condor-8.1.4
# ./configure_uw
# make install

これで、condor-8.1.4/release_dirができる。

condorのインストール

condorのインストールは、release_dirの下にバイナリをどこか別の場所にコピーする作業になるが、スクリプトを動かすには、あらかじめcondor_configファイルとcondor_config.localファイルが用意されている必要があるらしい。

というわけで、この2つを手動で作成。
ここでは、condor_configファイルは/home/condor/の下(defaultで探してくれるパスのうちの一つ。CONDOR_CONFIG環境変数で指定する場合はどこに置いてもよい)、condor_config.localファイルは/opt/condor/localの下に置くものとする。

※/opt/condor/localの下には一時ファイルが置かれるので、/optがネットワーク上にある場合はここにlocalディレクトリを置くのはよくない。
できれば、別パーティション上にある/varや/scratchのような場所がベストだが、うちの環境では/varなどに別パーティションを切っていないので、とりあえずoptの下に固めることにした。

更に、インストール先は/opt/condor/8.1.4とし、コレを/opt/condor/proにリンクする。

# mkdir -p /opt/condor/8.1.4
# pushd /opt/condor
# chmod 777 8.1.4
# ln -s 8.1.4 pro
# popd
# cp condor-8.1.4/release_dir/etc/examples/condor_config /home/condor/
# vi /home/condor/condor_config

# 以下のパラメタを書き換える
# your.condor.host.jpはセントラルマネージャーになるマシンのアドレスを入力
CONDOR_HOST    = your.condor.host.jp
RELEASE_DIR    = /opt/condor/pro
LOCAL_DIR      = /opt/condor/local
ALLOW_WRITE    = local01.my.domain, local02.my.domain, local03.my.domain

ALLOW_WRITEにはクラスタに参加する全てのマシンのアドレスが書かれている必要がある。
これを忘れるとcondor_status等のコマンドで全てのノードが見えない。
いちいち書くのが面倒なら*.my.domainとすれば同じドメインの全てのマシンに許可を出せる。

次に、ローカルマシン設定ファイルを定義する。
マスターになるマシンはcondor_config.local.central.managerを、それ以外はcondor_config.localをコピーする。

# mkdir -p /opt/condor/local
# cp condor-8.1.4/release_dir/etc/examples/condor_config.local.central.manager /opt/condor/local/condor_config.local
または
# cp condor-8.1.4/release_dir/etc/examples/condor_config.local /opt/condor/local/

以下のパラメタを変更(または追加)
YOUTPOOLは自分のマシンだけで運用する場合は定義しなくてよい

# vi /opt/condor/local/condor_config.local
CONDOR_HOST    = your.condor.host.jp
COLLECTOR_NAME = YOURPOOL

以下のコマンドをcondor-8.1.4/release_dirの下でtype

#./condor_install --install=. --prefix=/opt/condor/pro --local-dir=/opt/condor/local --type=manager,submit,execute

type=mamager,submit,executeはセントラルマネージャやサブミットマシンの設定。計算するだけでjobのマネージメントをやらないマシンはexecuteだけで良い。

condorのデーモンを走らせる

# export PATH=/opt/condor/pro/bin:/opt/condor/pro/sbin:$PATH
# condor_init
# condor_master

# デーモンが走っているか確かめる
# ps aux | grep condor

condor_master, condor_procd, condor_collector, condor_negotiator, condor_startd, condor_scheddなどが動いていればOK.

ここまでくれば、rootを抜けてもOK

# exit
$ export PATH=/opt/condor/pro/bin:$PATH
$ condor_status

複数台マシンへのインストール

まず、セントラルマネージャとなるマシンにcondorをインストールし、condor_masterを走らせておく。
次に、セントラルマネージャにぶら下がるマシンにcondorをインストールし、condor_masterを走らせる。
(逆の順番では駄目、と昔きいたが、今はどうか知らない)

この状態でcondor_statusを打つと、以下のようなエラーが出る。

Error: communication error
CEDAR:6001:Failed to connect to <XXX.XX.XXX.XXX:9618>

要するに、セントラルマネージャのポート9618が開いていない、という話。
というわけで、CONDORが使用するポートをあける。
CONDORはtcpとupdの9618と、1024番より後ろのポートを自動的にアサインして使う。この設定は変えることも出来るらしいが、面倒なのでクラスター内部の通信は全許可にした(勿論全てのマシンにそれなりのファイヤーウォールをたてておく必要があるけど)。
以下の例はこちらの記事の設定に付け足す場合。

my01 = 'xxx.xx.xxx.xx'
my02 = 'xxx.xx.xxx.xx'

/sbin/iptables -A INPUT -s $my01 -j ACCEPT
/sbin/iptables -A OUTPUT -d $my01 -j ACCEPT

/sbin/iptables -A INPUT -s $my02 -j ACCEPT
/sbin/iptables -A OUTPUT -d $my02 -j ACCEPT

ちなみに、my01、などとおいている変数名がホスト名と重なっていたりすると、まともに動かないので注意。

その他

condor_masterを一度実行すると、condor_offを実行してもデーモンしかストップできない。
面倒なので、condor関係のプログラムを全部殺すスクリプトを作る。

#!/bin/sh
for i in `ps aux | grep condor | grep -v 'grep condor' | awk '{print $2}'`; do eval kill -9 $i; done

ただし、condor_masterが殺せないのには理由があるわけで、ひとたびジョブを投入した後は、このコマンドを実行すると実行中のジョブやどこまで完了したかなどの情報も含め全て消えるので、最初のインストール時のテスト等などの限られた機会以外使用はおすすめしません。

sshログインの応答がやたら遅いとき

現在使っているサーバー2台のうち、一方だけが、やたらsshログインの応答が遅い問題に、随分長い間悩まされてきました。
2台とも同じマシン、同じ設定なのに何故?!!

で、本日、こちらの記事を拝見して、いろいろ試してみたんですが、、、

sshの接続確立が遅い場合の対処方法

確かに、遅いマシンの/etc/hostsにクライアントのIPを登録すると、早くなるのです。しかし、接続する全部のクライアントを登録するわけにもいかんし、、、

と思いつつ、/etc/resolv.confをあけてみて仰天、、、

プライマリDNSのアドレス、打ち間違ってるやん……(大汗)

というわけで、プライマリのDNS設定が間違っていたために、そいつがタイムアウトするまで時間がかかっていたのでした……(汗)

正しいアドレスにしたら、さくっと早くなりましたm(_~_)m

ローカルのDNSサーバがまともに動いてないと、うまく接続できんだろう、というのは最初から分かっていたのですが、サーバー側もSSH接続確立するまでに、DNSとやりとりするんですね(汗) しらんかった。

案外、こんなアホなミスで遅い場合もあるかもしれない、という話。

Updraft Plusで設定ファイルも保存する

この記事は、

Wordpressの便利なバックアップ/リストアプラグイン - UpdraftPlus リストア編

の追記です。

さて、実際にリストアをやってみて、UpdraftPlusの威力を実感したのですが、こうなると、wp-content以下以外の場所に保存してある設定ファイルなども自動バックアップしたくなります(笑)。

殆どの方はホスティングサーバにsshログインして作業はしないでしょうから、そういう方には使えない手なのですが、もしsshログインが出来るサーバーだったら試してみてはいかがでしょうか。

wordpress/wp-contentの下に、miscディレクトリを作成。

shellから以下のように入力($はプロンプト)。ただし、wordpressはpublic_html直下のwpという名前のディレクトリにインストールされている、と仮定。
#以降はコメントです。

$ pwd  # public_html直下にいることを確認
$ cd wp/wp-content
$ mkdir misc

設定ファイルをコピー

$ cd misc
$ cp -rp ../../wp-config.php .
$ cp -rp ../../.htaccess .htaccess_wp
$ cp -rp ../../wp-admin/.htaccess .htaccess_wp_admin
$ cp -rp ../../../index.php .
$ cp -rp ../../../.htaccess .htaccess_top
$ ls -a  # 全てのファイルがコピーされているか確認する。
$ chmod 604 .htaccess* # .htaccessからグループのアクセス権を消去

このうち、.htaccess関係は、存在していないものもあると思います。
(xrea, coreserverユーザの方は多分wp-adminの下の.htaccessを弄っているはず)
また、5,6行目は、wp以下にwordpressをインストールしているが、アクセスしたときにはwpの文字をURLから抜く設定をしている人向けです(つまり、wpのインストールディレクトリと、公開ディレクトリが異なる人向け)

要するに、wordpressを動かすのに必要なものは、wordpressのソースファイル以外全てmiscにコピーしてしまえ、ということです。

設定ファイルをシンボリックリンクに変更

こうやっておいて、現存する設定ファイルをmisc以下のファイルへのシンボリックリンクに置き換えます。

$ cd (行き先を指定しなければ、ホームディレクトリに移動します)
$ cd public_html/wp
$ rm wp-config.php; ln -s wp-content/misc/wp-config.php .
$ rm .htaccess; ln -s wp-content/misc/.htaccess_wp .htaccess
$ cd wp-admin
$ rm .htaccess; ln -s ../wp-content/misc/.htaccess_wp_admin .htaccess
$ cd ../../
$ rm index.php; ln -s wp/wp-content/misc/index.php .
$ rm .htaccess; ln -s wp/wp-content/misc/.htaccess_top .htaccess

以上で、設定ファイルその他が全てシンボリックリンクに置き換わりました。

今後は、これらのファイルの設定を変更するときにmisc以下のファイルを変更するようにすれば、あとはUpdraftPlusが自動でバックアップしてくれるので、いきなりwebアカウントが消去されても、「リストア編」の要領でwordpressを新規インストールして復旧したあと、miscディレクトリからシンボリックリンクを張り直すだけで完全復活します。


……なんでこんな記事書いたかというと、Coreserverからの更新時期メールがこの1ヶ月でまったく届かなくなり、更新わすれてさくっとアカウント消されたから、なんですけどね……(-_-);;
(サポートに泣きついて復活してもらったが。)

サポートとのやりとりの結果、ValueDomain側はメールを送信していたと判明。で、iCloudメールが怪しいと、連絡メールアドレスをniftyに変えてみたら届きました……

mac.com→mobilemeiCloudと使ってきましたが、iCloudになってからホント最悪です。突然勝手にいままで迷惑判定していなかったメールを迷惑フォルダに突っ込むようになるわ、今回に至っては、どうやら特定単語が含まれるメールは自動的に破棄して送信側にも受信側にも連絡しない、というとんでもない仕様にひっかかった模様
このフィルターは、ユーザの受信箱に届く前に行われるので、ユーザ側がいくら迷惑メール設定をオフにしても無駄なのです。
特定単語といったって、ホスティングサーバからの更新お知らせメールに一体どんな危険な単語が隠れてるっていうのさ?!

メインアドレスとして使ってきたので残念ではありますが、今後はもうiCloudメールは信用できないものとして、別サービスに重心を移す必要がありそうです。

タダメールだからって言われてもさ、、あたしゃ、mac.comからの使い手で、そのころはちゃんと金払って使ってたんだよ!!
フリーメールは信用できないから、わざわざそうしてたのに、勝手にフリーに移行して不都合は我慢しろってのはあんまりじゃないかApple
だったら、フィルター通す前に他アドレスに転送する機能つけろ、とマジ思います。

大体、これが実際の郵便なら、他人への郵便物開けて検閲するのも、勝手に消すのも犯罪なんだよ。。
ネット上では、スパム撃退、犯罪防止の名目のもと、そのへんがどんどん何でもアリになっている印象を受けますが、そのへん、どこの会社ももうちょっと慎重になった方がいいんじゃないですかね? と思う今日このごろ。

しかし、度々SPAM判定されるValueServerもどうかと思うので、ValueDomainのサービスを使っている方は、更新通知用メールアカウントをもう一つ登録しておくことを強くおすすめします。(更新通知のみ、2カ所に送る設定ができます)

JASRAC管理曲の楽譜をダウンロード販売する(ついでに紙の楽譜もオンデマンド印刷)

ヴィオラ3本とピアノのための小曲、をウン十年前におねだりして身近な作曲家に書いてもらいました。なにしろ初心者でも弾けるように、ということで難易度は低いのだけど、アンサンブルはとても綺麗な曲。是非皆さんに楽しんでいただきたい曲です。

2014/12/9追記:
結局ヴィオラ版はタダで公開。こちらからダウンロードできます

ところが、演奏の機会がなく、出版の機会もないので、このままでは埋もれてしまって勿体ない。
だったら、(例によって)自費出版してしまえ、という話になるのですが……
しかし、アンサンブル楽譜というのは、短いくせに各パートに1部ずつ楽譜が必要になって、印刷すると大変コストがかかるのです。。

というわけで、ダウンロード販売にしようと思い、どこに委託するか迷って色々調査した記録です。
ダウンロード販売したいのはJASRAC管理曲だから、まずはそこのところの手続きを代理でやってくれる、というのが必要条件。

ヤマハの「ぷりんと楽譜

ここは、一番大手でサポートも厚そうだけど、残念ながら個人からの楽譜投稿は受け付けていないっぽい。

@ELISE

ここも楽譜の量ではかなりいい感じなんだけど、やっぱり個人からの投稿は受け付けてないっぽい。というわけで、パス。

同人音楽の森

ここはアカウント作れば誰でも投稿できる。
しかし、手数料40%って……!!!(JASRAC申請料10%含む)
Amazonのe託と同じだよ!! Amazonは、実際に商品を受け取って、在庫を抱えて、発送して(しかもほとんどの場合送料無料)ってやってるから、40%でも、まあそんなもんだろう、と思うけど、データのダウンロード販売なんて空気みたいなもんじゃないですか!!
(芸術的内容のことを言っているのではなく、紙の楽譜を出版・保管するのに比べたら断然コストがかからない、という意味)
クレジット手数料は精々5%、JASRACに10%で、残り25%がシステム利用料って、どう考えても高すぎ。

あと、プロの作曲家の曲なので、「同人」音楽の森、というサイトに委託するのはやはり申し訳ない、、、ので、パス。

オケ専♪

オーケストラやってる人は多分知っている「オケ専♪」というSNSみたいなのがあるのですが、このなかに、アンサンブル楽譜だけを扱っている「アンサンブルの楽譜マーケット」なるものがあります。
ここは、メンバーからアレンジャーを募って販売する形式だから、やはり登録すれば販売可能。
しかも、今回の場合、ターゲットはオーケストラを趣味でやっている人だから、場所的にも問題なし!

…と思いきや、ここも手数料が40%!

あと、値段が500円、1000円、1500円と500円単位でしか決められないのが厳しい。趣味のアレンジャーも募ってるみたいだけど、趣味のアレンジにいきなり500円って壁が高すぎないか。
検索機能もないしなあ。
(ん? アレンジャー募集、ってことは、オリジナル曲は扱わない? そんな縛りはないよな、普通、、、)

DLmarket

今回初めてみつけたところ。
結論をいうと、ここが一番だと思う。

何がいいって、

1)手数料は15〜20%(購入者がどの決済方法を用いるかによる)
2)JASRAC管理曲を使うときは、手数料に10.8%上乗せ。更に四半期ごとに売上げ数の報告義務あり
3)楽譜を買う人が、紙の楽譜で欲しいと思ったら、オンデマンド印刷された冊子が同時に注文できる(!)
4)国際化対応

上記2件と比べて、手数料がリーズナブルなのは勿論ですが、3)と4)が非常に素晴らしい!
つまり、曲を提供する側が冊子を作らなくても、買う側が欲しいといえば、DLmarket側が勝手に製本して販売してくれるのです! 勿論、楽譜発送の手間もナシ。
(ただし、製本されてしまうので、パート譜が必要な楽譜は注意が必要? スコアとパート譜をそれぞれ別売りして、セット販売すればよさそうだけど、その場合JASRAC認可番号はどうつけるのか、とかちょっと考える必要アリ。)

これをやるには、別途「製本直送.com」にアカウントを作り、DLmarketのアカウントとリンクする必要があります。
また、製本楽譜分のJASRAC許諾は自分でやらなければならないみたいです。
どうするかというと、発行部数を報告してお金を払ってJASRAC許諾番号をもらうんですが、オンデマンド出版の場合、最初に部数が決まっていないので、適当に少部数を報告するのかな?
それで、その部数枠使い切ったら、また報告する、という感じだと思います(昔楽譜にJASRACシール貼ってた頃そんな感じだったから、多分同じだろう)。

以前こちらの記事で楽譜の自費出版について書きましたが、このシステムなら、100部も売れないよ、って楽譜でも簡単に1部から出版できますよね。
しかも、よくあるオンデマンド楽譜出版サイトみたいなお仕着せの表紙じゃなくて、自分で表紙から何から作って入稿すればいいわけですから、かなりオリジナリティの高いものが作れると思います。

国際化標準対応なのも素晴らしいです。楽譜なんて、言語関係ありませんから、できれば全世界で売りたい。
英語の紹介文は自分で書かねばなりませんが、購入ボタンなどちゃんと英語用のものが用意されているのは大変有り難いです。


更に、こちらではこんな機能もついてきます。

  • PDF保護機能(PDFファイルに購入者情報を書き込み。閲覧パスワードを設定して不正コピーを防止。)
  • セット販売機能(単品商品を自由に組み合わせてセット販売できます。組み合わせは自由!)
  • 今すぐ購入リンク(サイトから商品ページを介することなく直接DLmarketのカートに商品を入れられます)
  • 購入ページにYouTubeなどの音源をはりつけて宣伝できる

などなど。どうも楽天傘下らしく、購入には楽天ポイントも使えるらしい。

PDF保護機能はスグレモノです。pdfをアップロードして、簡単な設定をするだけで、PDFの全ページのヘッダかフッタに購入者情報を書き込むことができるのです!
更に、購入者専用のパスワードをかけることも出来ます。

これは、購入者のe-mailをパスワードに設定するものです。
これは非常に賢い方法だと思います。PDFを誰かにあげちゃうにしても、パスワードとして自分のメールアドレスを教えなければならないからです。
知人ならいいですが、それ以外の人にメアド教えるのは躊躇しますよね。
勿論、やろうと思えばPDFのパスワード制限を外すのはわけないんですが、それでもフッタに購入者名が書いてあるファイルを、たとえばインターネット上で不特定多数にばらまくのはちょっと躊躇すると思いますし、PDFに「記載された購入者以外の使用はお断り」と書いておけば、不正コピーは一見して不正コピーであることが分かります。

唯一難点があるとすれば、楽譜に特化したサイトではないので、ゲームやらソフトやら何でもアリ状態、更に楽譜についていえば、現在の利用者のジャンルが非常に偏っているように見受けられるので(やたらギター譜が多い)、たとえば弦楽アンサンブル譜なんてのは置くだけではお客は絶対来ないだろう、ということでしょうか。
宣伝は別の部分でやる、と割り切る必要がありそうです。
しかし、決済システム利用手数料としてはかなり安いと思います。


で、結局どうするの、って話なんですが。。

今のところ、DLmarketとオケ専♪に登録してみようかと思います。
というのは、どっちも、売れない限り手数料かからないから。

で、オケ専♪の方はヴィオラ3本+ピアノ版とヴァイオリン・ヴィオラ・チェロ+ピアノ版の両方をつけて500円で販売し、紹介のところに「ヴィオラ版だけ、もしくはヴァイオリン・ヴィオラ・チェロ版だけが欲しいひとはDLmarketに行ってくれ、楽天ポイントでも買えるよ♪」とか書いておけば、多分殆どの人はDLmarketにいってくれるんじゃないかなー、と思います。
両方とも欲しいひとはそんなにおらんでしょう。
買ってくれそうな人の目に触れる率という意味では、やはりオケ専♪の方に軍配があがりそうなので。


というわけで、楽譜の個人ダウンロード販売(+オンデマンド出版)もかなり現実的になってきたなー、と思った、という話でした。
また結果はそのうち追記します。


2014/4/15 追記:

DLmarketに登録してみました(3本のヴィオラのためのカプリスじゃなくて別の曲ですが)。
以下のボタンをクリックすると、商品詳細ページに飛びます(このボタンを押しただけでは、まだ購入にはなりません)。
45秒のサンプル音源もつけてみました♪

DLmarketで購入

すばらしいです。DLmarket!
非常に痒いところに手が届く仕様です。
作曲家の皆様、出版出来ずに眠っている楽譜、是非公表されてはいかがでしょう?

Wordpressの便利なバックアップ/リストアプラグイン - UpdraftPlus リストア編

以前、「Wordpressの便利なバックアップ/リストアプラグイン - UpdraftPlus」という記事を書いたのですが、本日リストアの方を試してみましたので、その記録です。

リストアの状況として、サーバー引っ越し(A)、またはwordpressクリーンインストール(B)を仮定しています。それぞれの場合の手順に(A)、(B)の記号がついていますので、ご参照下さい。

通常はサーバー引っ越しの方法で殆ど対応できますが、たとえばwpをハックされた、サーバーが死んでバックアップファイルしか残っていない、などの場合は、クリーンインストールを行います。
文字コードが設定した覚えがないのにUTF-7になっていた、などの現象があったら、まず間違いなく既に管理パスワード破られてハックされていますので、危険ですからwordpressクリーンインストールしましょう!

※今回、リストア先はvalueserverを使っています。これは、セーフモードがないサーバなので、特に問題ありませんでしたが、xrea/coreserverではもしかしたら問題が発生するかも知れません。
その際は、一時的に、トップディレクトリの.htaccess

AddHandler application/x-httpd-phpcgi .php

を足して、全てのファイルをcgiモードで動かしてしまえば良いと思います。
どうせ一回だけの作業ですので……
(作業が済んだら、消しておくのを忘れないように!)

最新バックアップをとる。(A、B共通)

※(B)クリーンインストールを行う場合は、wordpress本体及びUpdraftPlusを最新にアップデートするか、バージョンを確かめて同じバージョンのファイルが入手出来ることを確認しておくこと。

旧サーバのwordpressにログイン。プラグインからUpdraftPlusの「設定」をクリックし、「今すぐバックアップ」ボタンを押します。
更に、外部サーバにバックアップファイルを保存する設定にしている人は、その設定をメモ帳にでもコピーしておきます。

(B)クリーンインストールを行う場合は、wp-config.phpもローカルにダウンロードしておきます。

wordpressのアップロード

(A) 旧サーバ上のwordpressディレクトリをまるごと新サーバへコピー

ファイル数が多くて面倒なら、シェルが使えればログインしてtarで固めれば早い。だめなら、仕方がないので、ちまちま1ファイルずつコピーします。

(B) 新サーバへ新しいwordpressファイルをコピー

アップロードが完了したら、展開しておきます。

※エックスサーバへの引っ越しの場合:
ここまでやっておいたら、サーバーパネルから ドメインの「動作確認URL」をクリックして、動作確認URLを追加しておきます。

データベースを作成(A,B共通)

xrea/coreserver/valueserverなら、管理画面の「データベース」から作成可能。このデータベース名及びパスワードは、旧サーバのものと同じでなくても良い。データベースの文字コードを旧サーバのものと揃えておくこと!
エックスサーバの場合はこちらのページを参考にしてください。

wp-config.phpを変更(A,B共通)

wp-config.phpの以下の部分を変更。
(旧サーバと全く同じデータベース名、パスワードの場合は、変更しなくて良い)

/** WordPress のためのデータベース名 */
define('DB_NAME', 'データベース名');

/** MySQL データベースのユーザー名 */
define('DB_USER', 'ユーザー名');

/** MySQL データベースのパスワード */
define('DB_PASSWORD', 'パスワード');

/** MySQL データベースのあるサーバ。通常はlocalhostのままでよい。*/
/** エックスサーバはmysqlXXXX.xserver.jpなどの指定サーバに変更する */
define('DB_HOST', 'localhost');

更に、以下の二行を追加。
これは、サイト引っ越し中に、旧サイトにリダイレクトされてしまうのを一時的に防ぐための設定です。

define('WP_HOME','http://新サーバのドメイン名/wp');
define('WP_SITEURL','http://新サーバのドメイン名/wp');

WP_HOMEは公開アドレス、WP_SITEURLはwordpress本体が置かれているアドレスを書きます。最後の'/'は書かないこと。公開アドレスに'/wp'を含めない設定にしている場合は以下のとおり。

define('WP_HOME','http://新サーバのドメイン名');
define('WP_SITEURL','http://新サーバのドメイン名/wp');

ひとたび引っ越しが完了し、データベースに埋め込まれている全てのドメイン名を新サーバのものに変更するか、独自ドメインを利用しているならDNSを変更して独自ドメインから新サーバへアドレスを向けた後は、コメントアウトします。

引っ越しではなく、同じサーバ上で再インストールを行う場合は、これらの行は書かないこと。

wordpressのインストール(A,B共通)

新サーバのwordpressの管理画面にアクセス。

http://サーバー名/wordpress/wp-admin/

アクセスしたら、ユーザー名とパスワードに、旧サーバのwordpressで一番最初に作成した管理用のユーザー名とパスワードを入力する。多分、こうしないと、idの重複が起きるような…?

UpdraftPlusのインストール

(A)サーバー引っ越しの場合

この場合は、既にwp-contents/pluginにUpdraftPlusが存在するはずなので、新サーバでwordpressにログインし、プラグインからUpdraftPlusだけを有効化するだけで良い。

(B)クリーンインストールの場合

UpdraftPlusを新規インストールし、有効化しておく。

バックアップファイルのコピー(A,B共通)

UpdraftPlusの設定画面へ行き、

バックアップログ & 復元: 	可能な設定 

となっているところの「可能な設定」をクリック。すると、以下のような設定窓が開く。

ここで、保存先設定を弄っていなかった人は、「新しいバックアップ設定のフォルダを再スキャン」を押す。

一方、別のサーバにバックアップを保存していた人は、「バックアップファイルをアップロード」をクリックし、最初に保存しておいた旧サーバのバックアップファイルをアップロードする。

バックアップファイルのリストア

ファイルのアップロードが済んだら、「復元」ボタンを押す。新しい小ウィンドウが開く。



(A)サーバー引っ越しの場合

「データベース」のみにチェックを入れて、「復元」ボタンを押す。(テーマファイルなどは既にコピーされているはずなので、復元するのはデータベースのみで良い)

(B)クリーンインストール

全てにチェックを入れて、「復元」ボタンを押す。

別のサーバにバックアップを保存していた場合、しばらくすると、「これはリストアではなく、マイグレーションになります」みたいな忠告メッセージが出てくる(こんなの↓)

どのみちデータベースは空なので、もう一度「復元」を押す。
(プラグインが有料のオプションを勧めてくるが、必要ない)

(B)クリーンインストールの場合、wp-content以下に、xxx-oldという名前のディレクトリやファイルが出来ている。これらは、中身が空であることを確かめて消してしまって良い。
(language-oldのみ空ではないけれど、これはwordpressがインストールしたものなので、再インストールしたwordpressが同じバージョンなら消してしまって問題ない。より新しいバージョンをインストールしてしまった場合は、language-oldの中身をlanguageディレクトリに移動。)

UpdraftPlusの設定(A,B共通)

UpdraftPlusの保存設定を行う。旧サーバは廃止して新サーバに完全移行するのであれば、旧サーバの設定をそのままコピーすれば良い。


以上!

結論を言うと、めちゃくちゃ簡単です!!
お金を払えば複数のサーバにバックアップも出来るようですが、無料版でも十分だと思います。