別売りのELPAの電源タップを取り付けて、複数の方法で固定可能なタップホルダー。
4種類の方法で固定可能です(互いの位置関係が合えば複数の方法で固定も可能)。
- フックで吊り下げ
- マグネットで鉄板に貼り付け
- バンドを巻きつけて固定
- 木ネジで固定
適合タップに制限があるので、そこだけは注意。また、ホルダーと言ってもがっちり固定ではなく、片手で外せる程度の強度です。何かがぶつかるとホルダーから外れてしまう程度。
ググってみると、大抵以下のようなコードが多数見つかる。
ruby -e 'p [*1..9, *"a".."z", *"A".."Z"].sample(8).join'
これ、
ruby -e 'p [*"!".."z"].sample(8).join'
でいいんぢゃねぇです? 文字コード的に半角スペース, "!" , …数字…大文字アルファベット…小文字アルファベット、と続くので。まあパスワードに半角スペース入れると入力が厄介なことになりそうだからその次の "!" から始めるとして。
あ、でも " とか ' とか ` あたりもパスワードに含めると扱いがアレ気になりそうだから、
ruby -e 'p [*"!".."z"].reject {|c| %w"\" '"'"' \`".include? c }.sample(8).join'
くらいで、どうですかね?
地図を表示したり、地図上のあれこれを検索したりする用途のAPIについて、使用条件などをまとめました。なお、2017年6月23日現在の状況ですので今後変わる可能性があります。利用規約等は最新版を確認のうえ、各人の判断にてご利用ください。解釈ミス、情報のもれについて当方は責任を負いません。
サービス名 | 提供される内容(概略) | 利用制限 | 商用利用 | クレジット表記 |
---|---|---|---|---|
https://developers.google.com/maps/documentation/api-picker?hl=ja
|
https://developers.google.com/maps/pricing-and-plans/?hl=ja Google Maps Android API、Google Maps SDK for iOSについては制限なし。ただし「標準プランの利用規約で許可されている」との表記があるので、こちらも要確認。 Google Maps Embed APIについては無制限の無料利用。 地図表示については「1 日あたり最大 25,000 回のマップロードが無料」、Google Places API Web Serviceは「1 日あたり 150,000 回のリクエストが無料(クレジット カードによる本人確認が必要)」。その他のサービスはAndroidおよびiOS向けが「1 日 1,000 件」、Web Serviceが「1 日あたり 2,500 回」までのリクエストが無料。 無料に該当するもの以外は、少ないほうの数(スマートフォン系は1,000、Web系は2,500)で判断したほうが無難と思います。 |
https://developers.google.com/maps/pricing-and-plans/?hl=ja 有料サイトの場合は無条件に有料プランが必要と解釈しています。無料サイトの場合Yahoo!の「~ユーザーから利益を得ていると認められる~」のような言い回しは無いので無料プランで利用可能と思われますが、リクエスト回数の制限が厳しいので実質的に有料プランを選択することになると思われます。 その他「非営利組織、危機対応組織、および報道機関」向けに特別扱いがあるようなので、該当する場合は申請することで無料のまま利用できる可能性があります。 |
地図を表示させた場合は、地図画像自体にクレジット表記が埋め込まれています。 API利用の場合、基本的には「Googleが提供する地図と併用」となっていますので実質的にクレジット表記を表示することになります。PlacesAPI Web Serviceは「Google Places API Web Service のデータを Google マップには表示させず、ページまたはビューに表示するアプリケーションでは、データと一緒に「Powered by Google」ロゴを表示させる必要があります。」とあります。(https://developers.google.com/places/web-service/policies?hl=ja) |
|
Yahoo! |
https://developer.yahoo.co.jp/webapi/map/
| 1アプリケーションIDごとに1日50000回 (https://developer.yahoo.co.jp/appendix/rate.html) |
Yahoo! Open Local Platformの利用方法; 2. YOLPでは、以下に列挙するもののいずれかに該当するとYahoo! JAPANが判断した場合、YOLPのライセンスを消滅させることがあります。 ; YOLPにより提供される情報の使用によりユーザーから利益を得ていると認められるサービス (https://developer.yahoo.co.jp/webapi/map/#policy) 商用利用不可、もしくは多少なりともビジネスで利用する意図があるならば一度Yahoo!へ問い合わせた方が無難と判断します。 有償プラン: YOLP Premier (https://map.yahoo.co.jp/promo/yolp/yolppremier.html) |
Yahoo! JAPANの提供するAPIを利用するすべてのサイトやアプリケーションには、クレジットを表示する必要があります (https://developer.yahoo.co.jp/attribution/) |
ぶっちゃけ技術検証で途中まで書いたのだけど、当面使いそうに無いのでココという蔵に「お蔵入り」です。
必要なもの
- AWS SDK for PHP
- AWSのアクセスコード
サンプルコード
- AWS SDK for PHPはComposer等を使用せずに直接展開、 lib/ 以下に配置しています。Composer使った方が楽ですが、シェルログインできない環境の場合は手作業で配置した方が状況把握できてよいので。
- バケット名は aws-test.logicalrabbit.jp 。予め作成しておきませぅ。
認証
<?php require 'lib/aws-autoloader.php'; use Aws\S3\S3Client; $s3client = new S3Client( [ 'region' => 'ap-northeast-1', 'version' => '2006-03-01', 'signature_version' => 'v4', 'credentials' => [ 'key' => [アクセスキー], 'secret' => [秘密鍵], ], ] ); ?>
オブジェクト一覧の取得
テーブル化して一覧にしています。
<table> <tr> <th>Key</th><th>Size</th><th>Last modified</th> </tr> <?php $result = $s3client->listObjects( [ 'Bucket' => 'aws-test.logicalrabbit.jp', ] ); foreach( $result['Contents'] as $content ) { echo '<tr><td>' . $content['Key'] . '</td><td>' , $content['Size'] . '</td><td>' . $content['LastModified'] . '</td></tr>'; } ?> </table>
オブジェクトの追加
取り敢えず lib/ 内に展開前のaws.zipがあったので、それをアップロードしてみるなど。アップロード成功の有無確認として、ETagを画面に表示します。
<?php $reader = fopen('lib/aws.zip', 'r'); $result = $s3client->putObject( [ 'Bucket' => 'aws-test.logicalrabbit.jp', 'Key' => 'aws.zip', 'Body' => $reader, ] ); fclose( $reader ); echo '<p>Uploaded a file. ETag = ' . $result['ETag'] . '</p>'; ?>
この後で再度オブジェクト一覧の取得を実行すれば、オブジェクトが増えているのが確認できる筈。
PHP_PEAR_PHP_BIN=/usr/local/bin/php
を設定すればOK。←結論
どっとはらい。
…いや備忘録として残しておきたかったので。なお、PHP本体のバージョンはさくらインターネットの「コントロールパネル」にて変更可能です。
% php -v PHP 7.1.4 (cli) (built: Apr 17 2017 11:51:56) ( NTS ) Copyright (c) 1997-2017 The PHP Group Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies with Zend OPcache v7.1.4, Copyright (c) 1999-2017, by Zend Technologies
PHPはv7.1になっています。
% pecl version PEAR Version: 1.10.1 PHP Version: 5.6.30 Zend Engine Version: 2.6.0 Running on: FreeBSD www251.sakura.ne.jp 9.1-RELEASE-p22 FreeBSD 9.1-RELEASE-p22 #0: Wed Dec 3 15:24:48 JST 2014 root@www3304.sakura.ne.jp:/usr/obj/usr/src/sys/SAKURA17 amd64
しかし、peclは相変わらずPHP v5.6のまま。おかげでphp 7.xを要求するパッケージがインストールできなかったりします。
まずはphpコマンドの場所を確認。
% which php /usr/local/bin/php
実際には /usr/local/bin/php-wrapper
へのシンボリックリンクのようではありますが。
ログイン時、phpコマンドの場所を環境変数PHP_PEAR_PHP_BINにセットするようにします。その後取り敢えず現ログイン環境に反映。
% echo "setenv PHP_PEAR_PHP_BIN /usr/local/bin/php" >> .cshrc % source .cshrc
再度peclが使用するPHPのバージョンを確認。
% pecl version PEAR Version: 1.10.1 PHP Version: 7.1.4 Zend Engine Version: 3.1.0 Running on: FreeBSD www251.sakura.ne.jp 9.1-RELEASE-p22 FreeBSD 9.1-RELEASE-p22 #0: Wed Dec 3 15:24:48 JST 2014 root@www3304.sakura.ne.jp:/usr/obj/usr/src/sys/SAKURA17 amd64
これにて解決。
…したんだけど、肝心のmailparseがコンパイルエラーになって… ぐぬぬ。
1) ペイントソフトで1枚の画像ファイルに複数のアイコンを描いて 2) Google Map JavaScript APIで画像ファイルから各々のアイコンを切り出し、マーカーアイコンとして適用して 3) 同時にHTMLでも各々のアイコンを切り出し、凡例を表示する までの手順メモです。
取り敢えずメモなので説明画像も何もないですが、そのうち追加すると思いますよ、えぇそのうち…
用意するもの
- お絵かきソフト (アンチエイリアシング、透過PNG画像作成ができるもの)
- アイコンデザイン画
- HTMLとJavaScriptソースを書くためのツール
- Google Map JavaScript APIのAPIキー
手順1. 画像ファイルの作成
アイコンをまとめた画像ファイルの作成については、古のスプライトとかビットマップ画像とかを見たことがある人なら何の説明も要らない気がします。要はアレです。
何はともあれ、画像ファイルにアイコン画像を描きこみます。この際、アイコンの形状に関わらず、四角形(正方形のほうが管理しやすいと思います)の中央に収まるようにします。
次に、アイコン形状的に余白となる部分をマジックワンド等で選択、透過部分となるように設定します。具体的には消去して透明にするとか、アルファチャネルいじるとか。
透過部分の指定が終わったら、透過PNG画像として保存します。ここでは marker_icons.png とします。たぶんGIFでもJPEGでも、透過できて一般的なWebブラウザで表示できる形式なら何でもOKと思います。まあJPEGは予想外のゴミが入りそうだから止めた方がいいと思うけど。
手順2. Google Mapで使用するマーカーへの適用
マーカー( google.maps.Markerクラス )へ任意の画像ファイルを指定する方法は、コンストラクタのmarkerOptionsに iconプロパティ を指定することで行います。iconプロパティへはSVGパスかオブジェクト( google.maps.Icon )を指定可能なので、今回は後者のオブジェクト指定を使用します。
iconオブジェクトでは画像ファイルのURL (url)、画像ファイル中でのアイコン開始位置 (origin)、アイコンの大きさ (size) を指定します。他にもアイコンに被せるラベル文字列の開始位置などを指定できるので、微調整が必要な場合はこれらで調整していきます。
origin プロパティは google.maps.Pointクラス、size プロパティは google.maps.Sizeクラスを指定します。
例: /images/makrer_icons.png を読み込み、画像左上から30×30ピクセルのアイコン画像を使用する場合
var pos = new google.maps.LatLng( lat, lng ); var markerOptions = { label: 'marker', position: pos, map: window.map, icon: { url: '/images/marker_icons.png', origin: new google.maps.Point( 0, 0 ), size: new google.maps.Size( 30, 30 ) } }; var marker = new google.maps.Marker( markerOptions );
手順3. HTMLによる凡例の表示
凡例を表示する際、先述の makrer_icons.png をそのまま表示してしまうと、複数のアイコン画像がずらずら並んだモノが出てしまいよろしくありません。このファイル自体に凡例としての説明部を書き込んでしまうという手もありそうですが、なんだか無駄が多いので止めておきましょう。うん、止めよう(ちょっと企んだ)
凡例の構成としては 1) アイコン、 2) 説明文 の列挙となりますので、 <ul> タグを使用して、リストのヘッダにアイコン画像を表示することにします。この際 <li> タグの list-item-image 属性では画像のクリッピングができないので、:before を使用して背景画像として表示することにします。
例: /images/makrer_icons.png を読み込み、画像左上から30×30ピクセルのアイコン画像について凡例を表示する場合
<style> .marker { list-style-type: none; /* デフォルトのリスト接頭辞は非表示にする */ } .marker:before { background: url('/images/marker_icons.png') no-repeat 0px 0px; /* 画像を読み込み、左上部分から表示 */ width: 30px; /* 画像の表示幅 = クリッピング領域 */ height: 30px; /* 画像の表示高さ = クリッピング領域 */ top: 0; left: 0; display: inline-block; /* 幅を指定するのでblock、<li>の本文に並べるのでinline */ vertical-align: middle; /* バランスを考えて<li>の本文が画像中央に来るようにする */ content: ' '; } </style> <ul> <li class="marker">これはアイコンの説明文です</li> </ul>
実際には複数のアイコンを説明することになるはずなので、クラス定義はアイコンの数だけ用意し、表示位置を変えていくことで切り出し位置を定義します。
CentOS 7でSambaサーバ立ち上げてNAS化して、突然壊れると困るので一通りの自動チェックを組み込むまで。
ConoHaたんサイコー! とオブジェクトストレージにぽいぽいとデータを放り込んで、調子に乗って巨大なファイルとかも突っ込んでいたらさすがに使用量がヤバい…というか使用料金がヤバいので、そこまで重要じゃないわりに容量のでかいファイル類はローカルストレージに置こうかと。でも一応RAID1くらいにはしておこうかと。
てな流れで。
なお、一通り稼働するようになったので一先ず重要度の低いデータをオブジェクトストレージからNASに退避して見たのですが、それでも101MBになってしまいぐぬぬ顔の状況デス。オブジェクトストレージ、100MB単位の課金なんだよ…。
- OSはCentOS 7.3、ミニマムインストールから始めてます
- SELINUXとFirewalldはOn
- NAS領域はHDD二本立てのSoftware RAID1
- /dev/sdb および /dev/sdc を使用
Software RAIDの構築 (mdadm)
HDDの初期化
$ sudo parted (parted) select /dev/sdb (parted) mklabel gpt (parted) mkpart パーティションの名前? []? (適当に)raid ファイルシステムの種類? [ext2]? 開始? 0% 終了? 100% (parted) set 1 raid on (parted) select /dev/sdc (parted) mklabel gpt (parted) mkpart パーティションの名前? []? (適当に)raid ファイルシステムの種類? [ext2]? 開始? 0% 終了? 100% (parted) set 1 raid on (parted) quit
mdadmの導入とRAID構築
$ sudo yum install mdadm $ sudo mdadm --create md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1
/proc/mdstat でも cat しながらしばし放置。その間に /etc/mdadm.conf を作成。
まずUUIDの確認(各UUIDは当然のことながら実行環境によって変わるので注意)。bklidの出力のうち、最初の「UUID="~"」部分を確認。
$ sudo blkid /dev/sdb1 /dev/sdb1: UUID="6a9a2635-edee-45c2-7ef4-78526beb2d8d" UUID_SUB="b735d74f-575e-b659-132d-833c247f2ebb" LABEL="md0" TYPE="linux_raid_member" PARTLABEL="raid" PARTUUID="8b0ed382-bd94-4f32-afed-8fc1f5a54922" $ sudo vi /etc/mdadm.conf (以下のように書き込む) DEVICE /dev/sdb1 /dev/sdc1 ARRAY /dev/md0 uuid=6a9a2635-edee-45c2-7ef4-78526beb2d8d
- DEVICE で使用するパーティションを指定
- ARRAY に続く /dev/md0 が作成したSoftware RAIDの名前
- uuid=の後に、先程blkidで調べたUUID=以降を記述
/proc/mdstat のほうではmd0になっていないこともあるけど(実行時はmd127になっていた)、RAID構築完了後mdadm.confを使用するようにしてやれば名前は固定化されるので問題なしかと。
/proc/mdstat のほうで構築完了となったら、OS起動時の動作確認も含めてリブート。これで自動的に/dev/md0が構築されないと、色々まずいので。
/dev/md0 を対象として改めてファイルシステム構築
$ sudo parted /dev/md0 (parted) mklabel gpt (parted) mkpart パーティションの名前? []? (適当に)data ファイルシステムの種類? [ext2]? xfs 開始? 0% 終了? 100% (parted) quit $ sudo mkfs -t xfs /dev/md0p1
/etc/fstabに追記
まずUUIDの確認。
$ sudo blkid /dev/md0p1 /dev/md0p1: UUID="4cd893d8-133d-4bc9-b9f5-2c679cf831cd" TYPE="xfs" PARTLABEL="data" PARTUUID="add820f3-5a35-4f87-a6b9-9c752668018e"
マウントポイントを作成して(/var/data とした)、/etc/fstabへ追記。
$ sudo vi /etc/fstab (以下のように書き込む) UUID=4cd893d8-133d-4bc9-b9f5-2c679cf831cd /var/data xfs defaults 0 0
マウントしてみる。OSリブートしてブート時の動作確認もやっておいた方が安心。
$ sudo mount /var/data
このままだと/var/dataはrootしか書き込めないし、かといって丸ごと一般ユーザー書き込み可にすると面倒くさいので、/var/data/NAS を作成、この下をNAS領域として一般ユーザー書き込み可とする。
「一般ユーザー」の定義は「usersグループに属する」としました。…といってもこれ自宅サーバだしアカウント自分しかいないからなんでも良いんだけどさ…。そして自分自身がusersグループに属していない罠。
$ sudo mkdir /var/data/NAS $ sudo chown root.users /var/data/NAS $ sudo chmod g+wrx /var/data/NAS (自分自身がusersに属していなかったので追加) $ sudo usermod -G wheel,users kmamiya (/var/data/NASへ書き込めることの確認) $ newgrp users $ touch /var/data/NAS/test
Sambaの導入
最近のLinux上で動かしてWindowsで共有するファイルシステムのトレンドって何なのかなーとひとしきり調べてみたけど、仕様バージョンは変わっているけど相変わらずSambaなのね、と。
$ sudo yum install samba
あとトラブルシューティングのために、結局samba-clientパッケージも入れた。トラブルっていっても、要はSELINUX設定忘れていたんだけど(汗)
続いて/etc/samba/smb.confの設定。今回はユーザーごとのHomeとか使わないし、プリンタも共有しないのでばっさり捨てる。ていうか一人サーバーだから全部 guest にしてしまうのも一手なんだけどさ。
[global] workgroup = (Windows環境に合わせる) security = user map to guest = bad user force group = users passdb backend = tdbsam [NAS] path = /var/data/NAS browsable = yes read only = no
十数年ぶりくらいにSambaの設定やったので、色々過不足があるような気もする…。
最後にアカウント情報の設定。この辺りも最近色々動きが激しいっぽい。が、どうも過渡期っぽいので最新は追わないことにした。
$ sudo pdbedit -a -u kmamiya $ sudo pdbedit -L -v (確認)
ファイアウォールの設定
$ sudo firewall-cmd --list-all (当然sambaは許可されていないので追加) $ sudo firewall-cmd --add-service samba $ sudo firewall-cmd --list-all (問題なかったので永続化) $ sudo firewall-cmd --add-service samba --permanent
SELINUXの設定
本当はこれを思い出すまでに四苦八苦しているけどそこは封殺で。怪しいと思ったら取り敢えず setenforce 0 で挙動確認、後で忘れず戻せ。
必要なツールのインストール。
$ sudo yum install policycoreutils-python
Sambaのデータ領域に設定すべきfcontextを探す。smbd_var_run_t が適当っぽい気がした。
$ sudo semanage fcontext --list |grep smbd $ sudo semanage fcontext --add -t smbd_var_run_t '/var/data(/.*)?' $ sudo semanage fcontext --list |grep smbd (追加されたことを確認)
/var/data に対して適用。
$ ls -lZ /var/data $ sudo restorecon -R -v /var/data $ ls -lZ /var/data (fcontextが変更されたことを確認)
Sambaサーバの起動
…ところでnmbはまだ起動する必要、あるんですかね…? (実はSELINUXが原因だった)トラブルシューティングの最中に、念のためとおもって起動してしまったけど。
$ sudo systemctl status smb (disableになってる) $ sudo systemctl enable smb $ sudo systemctl status nmb (disableになってる) $ sudo systemctl enable nmb $ sudo systemctl start nmb $ sudo systemctl start smb
各々statusを確認して、エラーになっていなければOKとする。
Windows PCから接続
\\<IPアドレス>\NAS で認証画面が出て、pdbeditでセットしたアカウント/パスワードで接続、書き込みなどできればOKです。
各種ヘルスチェックの設定
オブジェクトストレージに保管するほどでもないにせよ無くしたくないアレやコレやなので、稼働させているHDD等のヘルスチェックは大事なのです。…なのです!
ログ監視
… Swatch を試してみようとしたところでCPANのインストール先問題に引っかかって四苦八苦していたのだけど、よくよく考えるとこのサーバは外部公開しないし、使わないときは止めてしまうことも多いので定常的なログ監視は要らない気がしてきた。
常時起動するようになったら考えよう。
HDDのS.M.A.R.T.監視
あとで。
仕事でのメイン開発言語がPHPになったので。今までPHPをメインに使うことは無かったので(敢えて選択する理由が無かった)。お約束的な部分が色々分からんので自分用にメモ。
MySQL(MariaDB)に接続できないとき
- Socketが見つかっていない可能性を疑う
php --ri mysqli
とかphp --ri pdo_mysql
でパラメータをチェック- Socketが設定されていない、もしくは正しくない場合は php.ini を確認
- そもそも何処の php.ini を見ているのか、と言う点を疑う
- 何処の php.ini を見ているかは、
php -i | grep php.ini
とでもすれば分かる- 自分しか使わないマシンだったらとりま /etc/php.ini を設定していけば良いのだけど、ソースコンパイルしたPHP (php.7.1.1)だとそもそも <インストールディレクトリ>/lib/php.ini を見ていましたとさ。どっとはらい。
sudo ln -s /etc/php.ini <インストールディレクトリ>/lib/php.ini
としたところ、/etc/php.ini を見るようになりました
遅ればせながら「さくらのクラウド」にアカウントを作って、php7環境を構築して見たなど。
…そしてこの記事を下書きのまま3ヶ月ほど寝かせる事案… orz
「さくらのクラウド」のセットアップ
アカウントの作成
既にさくらインターネットの会員IDは取得済みです。そこから「さくらのクラウド」の利用を開始 →「さくらのクラウド」内にアカウントを作成 →「さくらのクラウド」内アカウント内にユーザーを作成、までやってようやくサーバーインスタンスが作れるようになります。何なんだこの多重構造(汗) 組織内で大規模に使うときは必要そうだけど、個人で使うには過剰ですね…。
「さくらのクラウド」の利用を開始するにあたっては電話認証も必要なので、ここは電話を掛けられる環境で作業する必要があります。
サーバーインスタンスの作成
まずデータセンターを選択します。同一スペックなら石狩のほうが安いっぽいです。都心部からの通信速度をシビアに要求するとか欲しい機能がリリースされているとかの理由で選択することになるでしょう。
次にサーバーインスタンスを…といきたいのですが、先にパケットフィルタを定義しておいたほうが手順的に楽です。
取り敢えずテンプレートを使用して、SSHは自宅IP(固定契約)、NTPはさくらインターネット提供のNTPサーバーのIPでフィルタを定義。私の場合自宅のほかもう1箇所よく使うIPがあるので、フィルタ定義後に[ルール] →[追加]でSSHの開放を1つ追加。この際追加位置に気をつけないと、最終行の「その他は全部拒否」の下に追加してしまい、つながらなくて首を捻ることになります(360°ほど捻った)。
本当はSSHポートも変更したほうがいいけど、IPのほうをガチガチに絞ったから、まぁ、いいかな、と。
そしてようやくサーバーインスタンスの定義です。「シンプルモード」だとパケットフィルタを選択できない様子? 「非シンプルモード」は1台だけちょっと作るには設定項目が過剰で面倒だけど。
OSはCentOS 7を選択。CPU/メモリはお試し環境ゆえ最小限で十分なのですが、最初はOSアップデートやコンパイルをやるので余裕を持たせておくと快適です。ただし後で戻すのを忘れると請求書が鬼と化しますが。フフフ、怖いか?
サーバー環境の構築
とりま、yum upgrade で最新環境にしておきます。あとsudoできる作業ユーザーを作ってrootは封印。
# useradd worker # passwd worker (パスワード入力) # visudo (worker をsudo可能ユーザーに) # su - worker [worker]$ ssh-keygen (パスフレーズの設定などはお好みで) [worker]$ vi .ssh/authorized_keys (作業PCの公開鍵を登録) [worker]$ chmod 600 .ssh/authorized_keys [worker]$ exit # vi /etc/ssh/sshd_config (PermitRootLogin no を追記) # systemctl restart sshd
以後はworkerユーザーで作業していきます。
php 7の導入
http://php.net/から最新版をダウンロード、適当な場所に展開します。
configureの設定は以下のようにしました。必要なライブラリの導入~configure実行~make test(+コメントアウトしているけどmake installとconfの配置)までをgistに記録してあります。実行前にprefixだけは確認してください。
ここまでで高負荷作業は終了するので、いったんサーバーをシャットダウン、プラン変更で実作業に必要な程度のCPU/メモリスペックへ変更しておくことをおススメします。
なお、4コアCPU+4GBメモリ+20GB SSDのセッティングでここまで約1時間といったところ。CPU使い切っていたようなので、もうちょいコア数増やした方が幸せかも(いや、コンパイラがちゃんとマルチコア対応しているなら、ですが…)。
php-fpmの設定
/etc/php-fpm.conf.default を /etc/php-fpm.conf へリネームし、設定を調整します。
- daemonize は no にする (systemctl用のファイルでも指定されているが念のため)
- include が /etc/php-fpm.d/*.conf となっていることを確認。
/etc/php-fpm.d/www.conf.default を www.conf または適当な *.conf にリネームします。
- [www] は適宜変更
- prefix は /var 等とする(ログが /var/log/ 直下に作成される)
- user および group は apache に変更
複数のphp-fpmを稼動させる場合は、[www] の括弧内と listen のポート番号を適切に変更しましょう。
前述のgist公開バッチファイルでsystemd用のファイルは配置・設定されている筈なので、php-fpmを登録・起動します。
$ sudo systemctl enable php-pfm $ sudo systemctl start php-fpm
Apache2の設定
さくらインターネット側のセキュリティ設定としてパケットフィルタを設定していますが、CentOS側にもfirewalldがあるので、ここでhttpを通すようにしておく必要があります。
$ firewall-cmd --list-all public (default, active) interfaces: eth0 sources: services: dhcpv6-client ssh ports: masquerade: no forward-ports: icmp-blocks: rich rules: $ sudo firewall-cmd --add-service http success $ sudo firewall-cmd --add-service http --permanent success $ firewall-cmd --list-all public (default, active) interfaces: eth0 sources: services: dhcpv6-client http ssh ports: masquerade: no forward-ports: icmp-blocks: rich rules:
これでphp7を使うための環境が概ね整いました。
1GBプランのバックアップイメージを512MBプランへ展開することはできない ようなので、結局手動で移設したなど。同期に失敗してデータ欠損しないかと動悸が止まりませぬ。
前提条件
現サーバー | 新サーバー | |
---|---|---|
ConoHaプラン(ともに東京リージョン) | 1GBプラン(月額900円) | 512MBプラン(月額630円) |
メモリ1GB+SSD50GB | メモリ512MB+SSD20GB | |
OwnCloud | 8.1.5.2 | 9.1.1.3 |
OS(ConoHa製アプリケーションサーバーイメージ | CentOS 6.7 (Final) | CentOS 7.2.1511 |
データ格納 | ConoHaオブジェクトストレージ |
- 現サーバー
- ConoHa 東京リージョン・メモリ1GB+SSD50GB
- OwnCloud 8.1.5.2
- OS (ConoHa製アプリケーションサーバーイメージ) CentOS 6.7 (Final)
- 新サーバー
- ConoHa 東京リージョン・メモリ512MB+SSD20GB
- OwnCloud 9.1.1.3
- OS (ConoHa製アプリケーションサーバーイメージ) CentOS 7.2.1511
データ格納先はともにConoHaオブジェクトストレージ
手順
- ownCloudとの同期アプリを全て終了(自動起動もOFFにしておくとなお安心)
- 現サーバーでmysqlのフルダンプを取得
$ mysqldump -u root -p owncloud_db |gzip -c > owncloud_db.dump.gz
- 新サーバー構築
- ConoHaコントロールパネルへログイン
- [サーバー追加]タブ
- タイプ=VPS
- メモリ=512MB
- イメージタイプ=アプリケーション
- アプリケーション=[その他] – ownCloud
- ディスク容量=SSD20GB
- その他の設定=適宜
- サーバー起動後、OSアップデート、作業ユーザー追加等々のセキュリティ対策は適宜。
- 現サーバーから新サーバーへmysqlのフルダンプをコピー
$ scp owncloud_db.dump.gz <新サーバーIP>:
- 現サーバーの /var/www/html/owncloud/config/config.php を新サーバーへコピー (注: このファイルはapacheオーナーのみ参照可になっているので、適当にセキュリティ突破すること)
$ scp /var/www/html/owncloud/config/config.php <新サーバーIP>:
- 新サーバーへログイン
- mysqlのダンプを新サーバー上mysqlへロード
$ zcat owncloud_db.dump.gz |mysql -u root -p -D owncloud_db
- config.php を /var/www/html/owncloud/config/ へ配置 (注: 既にファイルが存在するので、適宜バックアップ)
$ sudo cp config.php /var/www/html/owncloud/config/config.php
- /var/www/html/owncloud/config/config.php の内容を編集
- trusted_domainsの配列内に現サーバーのhostname, IPアドレス等があるので、これを新サーバーのものへ変更
- overwrite.cli.url のドメイン名部分を現サーバーから新サーバーのものへ変更
- version を 現サーバー(8.1.5.2)から新サーバー(9.1.1.3)へ変更
- dbpasswordを新サーバーのmysqlサーバー、owncloud_userアカウントのものへ変更
- /var/www/html/owncloud/config/config.php のオーナーを user=apache, group=apacheに変更(なお、SELinuxはDisabledになっていました)
$ sudo chown apache.apache /var/www/html/owncloud/config/config.php
- apache2をリスタート
$ sudo systemctl restart httpd
- 新サーバーのOwncloudへWebアクセスしてみる (成功していれば、セットアップ画面ではなく通常のログイン画面が表示されるはず)
- このあたり、初回はプラグインのアップデートが始まる場合も
- 新サーバーのOwnCloud上にあるべきファイルがあることを確認
- 各OwnCloud同期アプリを起動
- 現サーバーの設定を削除し、新サーバーの設定を追加
- 同期が成功することをConoHaたんに祈る
- 現サーバーはこれにてお役御免ですので、最後にバックアップするなり、きれいに削除するなり、お好きに。
新サーバーへの残項目
- HTTPS化
- SELinuxがDisabledなので有効化したい
- PHPが5.6系なので7.x系にしたい
- ていうかこのPHP、PHP-fpmになってないよね?
新サーバー(512MBプラン)の注意点
- やっぱりメモリに余裕ない感じ(以下は一通りの移設作業を終えた状態での計測)
$ free —mega
total used free shared buff/cache available
Mem: 489 386 10 1 91 75
Swap: 2047 121 1926
- yum upgradeしたら最初のyumリポジトリへのアクセスが遅いように感じました。メモリでしょうか…?