Linux
Docker の mysql でMySQLサーバを起動して、Rails環境のほうが既存コードで開発環境でも一般ユーザを作ってDBアクセスする仕組みにしていたので、 MYSQL_DATABASE, MYSQL_USER, MYSQL_PASSWORD を使ってDBとユーザを自動で作らせようとしたのだけど…ハマった。
Rails側が app、DB側が db と思いなせぇ。
取り敢えずMigrationエラー出るのは承知でRails側を起動させ、アクセスしてみたところ、以下のエラーが発生。
app_1 | Mysql2::Error::ConnectionError (Access denied for user 'user'@'test_app_1.test_default' (using password: YES)):
もちろんパスワードとかは合ってる。アクセス拒否されたユーザ名のホスト名部分が test_app_1.test_default となっているのだけど、当初ここを「アクセス先」と誤認してしまい、 DBコンテナのホスト名がどこかで混線してる？？？ と考えてあちこち弄ったりデバッグコード仕込んでみたりして調べること、約1日。
ちがうよねー
これはアクセス元(app)のホスト名が、MySQL側に登録されていないので拒否られているのよねー。
で。気付いたので MYSQL_USER を user@test_app_1.test_default にしてみたり(これだと docker-compose run するたびにホスト名が変わるのでよろしくない)、 user@% にしてみたり(というか元々こうなる気がするんだが…)したのだけど、結局うまく行かず、面倒くさいので Rails 側のDBユーザ名を root に変えてしまいましたとさ。
どっとはらい。
…まあ、後々必要になりそうな気もするので、今度どのように書くのが良いのか、ちゃんと調べようかと(今はただRailsアプリの動作環境を作ってコーディングをせねばならぬ)
そんな平成最後の年度末。
Dockerfile の ARG に対する値入力
--build-arg <変数名>=<値>
複数の場合は1つずつ。
--build-arg <変数名1>=<値> --build-arg <変数名2>=<値>
Docker外とDoker内で作業ユーザを一致させたい
この方法が本当に最適解なのかは分からないが。Doker内に既存の一般ユーザが居ない前提。
docker buildへの指定:
--build-arg USER_ID=`id -u` --build-arg USER_GROUP_ID=`id -g` --build-arg USER_NAME=`id -un`
Dockerfile内:
ARG USER_ID ARG USER_GROUP_ID ARG USER_NAME RUN groupadd -g $USER_GROUP_ID $USER_NAME \ && useradd -u $USER_ID -g $USER_NAME -m $USER_NAME
さらに作業ディレクトリVOLUMEを作業ユーザで使えるようにする
Dockerfile内:
RUN mkdir -p /mnt/work_dir_root/workarea && chown -R $USER_NAME:$USER_NAME /mnt/work_dir_root/workarea VOLUME /mnt/work_dir_root USER $USER_NAME
VOLUMEに書いたディレクトリ直接だと(マウントポイントなので)chownが使えないので、さらに一段掘って作業エリアとする。
オンラインの参考資料 (Docker ドキュメント日本語化プロジェクト)
CentOS 7.5上でVagrantとAnsibleを使ってVirsualBoxを操作しようとしたら環境設定に色々ハマった記録。バグトラップな上にグーグル先生が的確な情報出してくれない!!
問題山積み
- VirsualBoxのインストールで失敗する (modprobe vboxdrv が云々)
- secure bootの影響で、署名がないモジュールをロードできないのが原因。署名すればよい。
- だがしかし、署名に使った公開鍵がenrollできない
- mokutilのバグ。1つ前のバージョンに戻す。
- Mac OS X用のVagrantfileとCentOS(Linux)用のVagrantfileではansible providerの名前が異なる
- Mac OS X 用は
ansible。CentOS用はansible_local。冪等性とは。 - 参考: Ansible Not Found during Post Provision Task
- Mac OS X 用は
- なんかVagrantfileからは実行できないのに、ansible-playbookでは実行できるんですが… (これは秘密鍵のパスとか、そういう問題かも)
- NFSマウントが失敗する
- firewalldがお仕事してた。vboxnet0をtrusted zoneへ叩き込む(いいのかそれで？)
- "CentOS VirtualBox Vagrant"とかでググると「Vagrantで(WIndowsの)VirtualBoxにCentOSを入れようず」いう話ばかりが出てくるんですよね…。しかし他に適当なキーワードもなく。
各々の対策記録
VirsualBoxのインストールで失敗する
CentOSのおそらく7.4以降～バグ修正版が出るまでは、先に「署名に使った公開鍵がenrollできない」を読んでください。二度手間になります。
RedHatの 26.8. セキュアブート用のカーネルモジュールの署名 が日本語ですし、「何をやっているのか」まで分かってよいです。
単にやるべきことを知りたいだけならば Signing VirtualBox & VMware modules 等があります。 なお、CN=以降はcommon nameを入れるところなので各自考えて置き換えることになります。
例に出ているのは「vboxdrv」だけなのですが、実際は同じディレクトリ内の全ファイルに署名しないとダメでした(全ファイル必要なのかは組み合わせテストが面倒なので確認していません)。
modinfo -n vboxdrv でこのモジュールファイルのフルパスが出てくるので、そこでパス名から必要なファイルを見つけてください。ちょっとイイ感じにやりたければ ls $(dirname $(modinfo -n vboxdrv) )/* |xargs -l1とかすればイケるんじゃないかとは思う。
署名に使った公開鍵がenrollできない
問題は、上記でモジュールに署名したあと、その公開鍵を mokutil へ登録した後で、再起動するとUEFI コンソールで mokutil にセットしたパスワードを聞かれ、パスすれば以後は公開鍵がOSへ永続登録される、という部分です。何度再起動してもそんな画面出てこないのです…っ
原因は、最新版の mokutil にバグがあり、肝心のUEFIコンソールが起動しないとのこと。
以下にその説明があります。
元々問題に気付いたのはこのあたりの記事。 "The uefi secure boot bug" の文言を読んだ時の脱力感がハンパない。
Red Hat Bugzilla – Bug 1477735 Shim was unable to measure state into the TPM
対策ですが、バグのない1つ前の mokutil はCentOSの場合7.3にあります。 http://vault.centos.org/7.3.1611/os/x86_64/Packages/ から mokutilと shim のRPMをダウンロードして、最新版を yum remove で削除後にインストールします。
成功すれば、ブート時にきっちり止まりますので確実に分かります。
この作業前に mokutil へ鍵を登録したりパスワードをセットしていた場合、その作業からやり直しになるので注意してください。
Mac OS X用とCentOS(Linux)用とのVagrantfile差異
一覧に書いた通りです。Mac OS X 用は ansible 。CentOS用は ansible_local 。このあからさまな違いから見て、CentOS用は何か使い方を変えると ansible になるのかもしれませんが。
参考記事は以下。
NFSマウントが失敗する
原因がわからないときは、 vagrant ssh でゲストOSに入ったのち、おそらく画面に表示されているであろうコマンド( mount -o vers=3,udp <ホスト側IP>:<ホスト側Path> /vagrant 等)を実行してみるのがよいです。この際、mount コマンドに --verbose を追加することで、ある程度情報が増えます。
私のケースの場合 mount.nfs: portmap query failed: RPC: Unable to receive - No route to host
が出ていたので、これは経路が切れてるな…と考えた次第。その後sshでゲスト→ホスト接続を試してみて、接続できたのでfirewallかな、と。
firewall-cmd --add-interface vboxnet0 --zone=trustedfirewall-cmd --list-all --zone=trusted(確認)
trusted (active)
target: ACCEPT
icmp-block-inversion: no
interfaces: vboxnet0
sources:
services:
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
のような結果になればOK。
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.監視
あとで。
遅ればせながら「さくらのクラウド」にアカウントを作って、php7環境を構築して見たなど。
…そしてこの記事を下書きのまま3ヶ月ほど寝かせる事案… orz
「さくらのクラウド」のセットアップ
アカウントの作成
既にさくらインターネットの会員IDは取得済みです。そこから「さくらのクラウド」の利用を開始 →「さくらのクラウド」内にアカウントを作成 →「さくらのクラウド」内アカウント内にユーザーを作成、までやってようやくサーバーインスタンスが作れるようになります。何なんだこの多重構造(汗) 組織内で大規模に使うときは必要そうだけど、個人で使うには過剰ですね…。
「さくらのクラウド」の利用を開始するにあたっては電話認証も必要なので、ここは電話を掛けられる環境で作業する必要があります。
サーバーインスタンスの作成
まずデータセンターを選択します。同一スペックなら石狩のほうが安いっぽいです。都心部からの通信速度をシビアに要求するとか欲しい機能がリリースされているとかの理由で選択することになるでしょう。
次にサーバーインスタンスを…といきたいのですが、先にパケットフィルタを定義しておいたほうが手順的に楽です。
取り敢えずテンプレートを使用して、SSHは自宅IP(固定契約)、NTPはさくらインターネット提供のNTPサーバーのIPでフィルタを定義。私の場合自宅のほかもう1箇所よく使うIPがあるので、フィルタ定義後に[ルール] →[追加]でSSHの開放を１つ追加。この際追加位置に気をつけないと、最終行の「その他は全部拒否」の下に追加してしまい、つながらなくて首を捻ることになります(360°ほど捻った)。
本当はSSHポートも変更したほうがいいけど、IPのほうをガチガチに絞ったから、まぁ、いいかな、と。
そしてようやくサーバーインスタンスの定義です。「シンプルモード」だとパケットフィルタを選択できない様子？ 「非シンプルモード」は１台だけちょっと作るには設定項目が過剰で面倒だけど。
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リポジトリへのアクセスが遅いように感じました。メモリでしょうか…？
Twitterのほうで呟いていたものを整理しました。「諦めて手動で移行しろ」←結論。
問題
ConoHaでメモリ512MB、SSD20GBプランが新設されました。既存の最安プラン(メモリ1GB、SSD50GB)より300円弱お安くなります。
以前からConoHaの1GBプランでOwnCloudのアプリケーションイメージをロードし、データ格納先としては同じくConoHaのオブジェクトストレージを使用していたのですが、この場合フロントエンドとなるVPS側はほとんどディスクを使用しません。ルートディレクトリからの実測で9GBくらいです。
これで50GBはもったいないし、とはいえリアルタイム同期させている都合上開発サーバー等にするのは扱いが面倒になるので、新プランのSSD20GBに縮小移行しようと思ったわけです。
で、VPS上で通常シャットダウン→ConoHaコントロールパネルで手動バックアップ→新しいVPSを512MBプランで選択、イメージタイプ:「保存イメージ」で作成しようと思ったのですが…イメージのリストに出てきません。
1GBプランで選択すると出てくるので、モノとしては存在する様子。というか以前別の目的でバックアップした開発環境VPSのイメージもリストに出てこない。
調査
挙動からして何かフィルタリングされているように見えたので、 ConoHa API 側からつつけば理由が分かるかと調査を開始。
以前開発した ConoHaでメール送信するツール でAPIアクセスの基本部分は出来ていたので、これを改造して利用しました。…というかこのアクセスライブラリ部分は切り分けて公開しましょうかね。OpenStackクライアントライブラリだとConoHa独自(?)のメールサーバー機能とか、使えない様子だし。
以前作ったコード に機能を追加。
def list_image( self ):
try:
response = urlopen( urllib2.Request(
urljoin( self.imageservice_endpoint(), '/v2/images' ),
None,
self.auth_headers
) )
self.http_status = response.getcode()
if self.success():
infos = json.loads( response.read() )
image_info = {}
for info in infos['images']:
image_info[info['name']] = info
response.close()
return image_info
else:
response.close()
return self.http_status
except HTTPError as err:
self.http_status = err.code
return self.http_status
else:
response.close()
さらに呼び出し側も改造。
from conoha import ConoHa
import sys
import json
def exit_if_failure( conoha ):
if not conoha.success():
print( 'HTTP_STATUS: ' + str( conoha.http_status() ) )
exit( 1 )
with open( sys.argv[1], 'r' ) as config_reader:
config = json.loads( config_reader.read() )
conoha = ConoHa( config['identity_url'], config['user_agent'] )
connect_response = conoha.connect(
config['username'], config['password'], config['tenant_id']
)
exit_if_failure( conoha )
image_list = conoha.list_image()
for name,image_info in image_list.items():
if 'private' == image_info['visibility']:
for key in image_info.keys():
print( key + ':' + str(image_info[key]) )
print( "\n" )
結果(だめでしたー)
APIの「 イメージ一覧を取得 」でチェックしてみると、「min_disk:50」となっています。
$ python list_image.py config.json container_format:ovf min_ram:0 updated_at:2016-11-02T01:13:15Z file:/v2/images/XXXXXXXXXX/file owner:YYYYYYYYYY id:XXXXXXXXXX size:35246112768 self:/v2/images/XXXXXXXXXX disk_format:qcow2 direct_url:file:///var/lib/glance/images/YYYYYYYYYY/XXXXXXXXXX app:ownCloud-8-64bit schema:/v2/schemas/image status:active tags:[] hw_qemu_guest_agent:yes visibility:private min_disk:50 instance_uuid:ZZZZZZZZZZ name:owncloud checksum:ed2798eb07530bc79aa073c6e26f6e76 display_order:280 protected:False os_type:lin created_at:2016-11-02T01:08:03Z
(他のバックアップ情報は割愛、IDの類はマスク)
同じAPIから取得できる、ConoHa提供の既存OSテンプレートは概ね「min_disk:20」、一部のみ「min_disk:50」となっているので、どうやらこれが、イメージをロードするVPSが最低限持つべきディスク容量のようです。
…ただ、メモリ512MBプランでディスク容量を「SSD 220GB」にしても表示できないので、微妙に別の問題が絡んでいそうな気もします。
あと何故か実測9GBしか使用していないOwnCloudフロントエンドを手動バックアップすると32.83GBになるので、どちらにしてもこのままではSSD 20GBにロードすることはできないのですが。
min_diskを20に出来れば、あとはsizeが20GB以下ならロードできそうな気もするのですが、APIを見る限りこの情報を書き換える機能は無い様子なので、まあ詰みましたかね、と。
後はAPI側のVPS構築機能でメモリ512MBプラン+min_disk:50 のイメージを指定した場合にどこかでチェックされているか否か、というポイントがあるのですが…さて。
CentOSでイチからBB無線ルータを構築した際、ポートを越えてWoL(Wake on LAN)信号を飛ばす方法がようやく分かったのでメモ。…これでいいんだよ…ね？
前提条件
- CentOS 7を2ポート有線LAN+無線LANのマザーボード(MSI製 Z97I AC)にインストールしてBBルータを構築
- 有線LANの1つ目をインターネット側光ケーブルのOSUに接続、有線LANの2つ目と無線LANはイントラネットとして設定
- イントラネットは基本的にdhcpdによるIP払い出し、主要なマシンのみIP固定
- 有線LAN(イントラ)と無線LANは同一セグメント
方法
- /etc/dhcp/dhcpd.conf にて、DHCPにおいてMACアドレスとIPアドレスを固定で紐づける
arp -s <IP address> <MAC address>としてARPテーブルにおいてMACアドレスとIPアドレスを固定で紐づけるfirewall-cmd --add-port=9/udpとしてWake on LANが使用するポート番号9(UDP)を解放する- Wake on LANするときは対象マシンのIPアドレスとポート番号を指定して送信する(同一ポート上で実行する場合はブロードキャストモードで送信するか、IPアドレスとしてブロードキャストアドレスを指定して送信している筈)。
firewalldでMACアドレス指定の信号をポート間で通すとか、ブロードキャストを通すとかできれば済むような気はしていたのだけど、私の実力じゃ調べきれず、結局この方法で解決できたのでまあ良しとしたい。ポート9(UDP)がフル解放されている気がしないでもないが…うぅむ？
arpテーブルに気付いたのは、対象マシンを止めた直後であればWOLが通るので、もしかしてIPアドレスが誰に割り振られているのか分からなくて迷子になってるんぢゃね？ と。マシン停止直後だとDHCPのリースとか生きてるだろうから、その辺を固定化してやればいいんぢゃね？ という具合。
なおCentOS 7だとarpではなくip neighを使うべきらしいのだけど、Blogに纏めるにあたり試してみたもののこちらのコマンドでテーブルに追加する方法がうまくできず断念したなど。
本当はWake on LANのマジックパケットの仕組みとかから調べ始めていたのだけど(うまく通過できないから専用のサーバ立ててしまえばいいんじゃね、とか思った)、この辺りって軽くググった程度だとうまく見つかりませんね…？ まあ結局無駄なこと調べていたっぽいけど。
現状このWebサイト等を公開運用している「さくらのVPS」は、OSがCentOS6.x系。そろそろCentOS7.xにしたい。あとリバースプロキシとかも一度再設定したいところ。
OS更新は面倒くさいし、どうせ6.xから7.xは色々変わるのでOS再インストールからやってしまいたいのだけど、いかんせんWebサイトを公開運用しているので長いこと止めるわけにもいかない。どこかに仮サーバーを設置しないと。
で、仮サーバーとして「さくらのVPS」を使うか「さくらのクラウド」を使うか、はたまた「ConoHa」に逃げるか。できれば同じさくらインターネット上のサービスを使ったほうが、仮移設時の問題が少ないように思う。「さくらのクラウド」にはVPSのイメージを元にクラウド側を構築する機能があるので、先ずこれで仮移設してしまえばよさげ。あとはDNS切り替えの問題とか。
問題は料金。
- 「さくらのVPS」は初期費用がそこそこかかる。現在と同一プランだと月額972円+初期費用1,620円(合計2,592円)
- 「さくらのクラウド」は初期費用は無いけど利用料金がそこそこかかる。VPSと同等で試算すると、14日利用で2,478円、月額3,132円…の筈。これ単一サーバー稼動の場合はネットワーク等のオプション要らなかったよな…？
- 参考までに「ConoHa」は初期費用なし、月額900円または時間あたり1.3円。14日利用だと1.3円×24時間×14日=436.8円。このはたんサイキョー。
なお「さくらのVPS」は現在「2週間無料お試し」があり、まあ今回用途だと2週間もあれば用は済むので「お試し」だと言い張れば無料で使うこともできる。が、お試しではないし色々お世話になっているところなので、きちんと支払いをしておきたい。
無料お試し期間中でも決済をすれば支払いはできる筈なのだけど、"お試し期間中であっても、会員メニューより「本登録（決済）」いただくと、すぐに本サービスを開始することができます。なお、すぐに本サービスを開始いただいた場合でも、2週間は無料でご利用いただけます。"とあり、これ決済して2週間以内に解約するとどうなるんだろう…的な疑問も。
また"さくらのVPSの最低利用期間は3ヶ月"なので、2週間程度の利用目的でも3ヶ月分費用が発生してしまう。3ヶ月＋初期費用だと4,536円。これを考えると「さくらのクラウド」で1ヶ月利用したほうが良いか。
「さくらのVPS」をもう1台契約、新契約のほうに移設後DNS切り替え、旧契約を解約という方法もあるのだけど、現契約は年間契約にしているため次の更新は2017年5月末…。今解約するのはもったいない。
結論としては、「さくらのクラウド」を試しに使いつつ1ヶ月以内でVPS側を再セットアップ、というところかな。VPSをそこそこ長く使っているとこの手の問題は出て来る筈なので、何か便利なサービスがあっても良いと思う今日この頃。
bluetoothctl を使えばイイっぽい。root権限が必要っぽい？
コマンド自体はbluezパッケージに入っています。特にインストール指定した記憶は無いので、X Windowとか入れてやれば入ってくるもの、かも。ところでこのパッケージ名、なんかトイレに置くだけのアレを連想するのはあたしだけですかね…？(ヤメロ)
$ yum info bluez
インストール済みパッケージ
名前 : bluez
アーキテクチャー : x86_64
バージョン : 5.23
リリース : 4.el7
容量 : 3.7 M
リポジトリー : installed
提供元リポジトリー : base
要約 : Bluetooth utilities
URL : http://www.bluez.org/
ライセンス : GPLv2+
説明 : Utilities for use in Bluetooth applications:
: - hcitool
: - hciattach
: - hciconfig
: - bluetoothd
: - l2ping
: - rfcomm
: - sdptool
: - bccmd
: - bluetoothctl
: - btmon
: - hcidump
: - l2test
: - rctest
: - start scripts (Red Hat)
: - pcmcia configuration files
:
: The BLUETOOTH trademarks are owned by Bluetooth SIG, Inc.,
: U.S.A.
例えば
MCO TK-BT01
$ sudo bluetoothctl [NEW] Controller XX:XX:XX:XX:XX:XX hostname-0 [default] [NEW] Device YY:YY:YY:YY:YY:YY MCO TK-BT01 [bluetooth]# [bluetooth]# devices Device YY:YY:YY:YY:YY:YY MCO TK-BT01 [bluetooth]# connect YY:YY:YY:YY:YY:YY (ここでBluetooth機器側も接続待機にしませぅ) Attempting to connect to YY:YY:YY:YY:YY:YY [CHG] Device YY:YY:YY:YY:YY:YY Connected: yes Connection successful [bluetooth]#
connect <MAC ADDRESS> の時点でBluetooth機器側が接続待機になっていないと、以下のような感じになります。
[bluetooth]# connect YY:YY:YY:YY:YY:YY Attempting to connect to YY:YY:YY:YY:YY:YY Failed to connect: org.bluez.Error.Failed [CHG] Device YY:YY:YY:YY:YY:YY Connected: yes [CHG] Device YY:YY:YY:YY:YY:YY Connected: no (以下yesとnoの繰り返し)
このコマンドmanがインストールされてないし --help してもろくな内容が出てこないのだけど、基本コマンド名だけで起動、対話的に操作するものっぽい。取り合えず [bluetooth]# help とやればサブコマンド一覧が出るので、それを見ながらやれば良さげ。
[bluetooth]# help Available commands: list List available controllers show [ctrl] Controller information select <ctrl> Select default controller devices List available devices paired-devices List paired devices power <on off=""> Set controller power pairable <on off=""> Set controller pairable mode discoverable <on off=""> Set controller discoverable mode agent <on off="" capability=""> Enable/disable agent with given capability default-agent Set agent as the default one scan <on off=""> Scan for devices info <dev> Device information pair <dev> Pair with device trust <dev> Trust device untrust <dev> Untrust device block <dev> Block device unblock <dev> Unblock device remove <dev> Remove device connect <dev> Connect device disconnect <dev> Disconnect device version Display version quit Quit program [bluetooth]#
無線LANの感度を上げるために部屋の天井近くに配置した機体、基本はssh操作なのだけどたまーにコンソール(X Window)ログインする必要があって、BluetoothがあるからBluetoothキーボードで操作すればいいいや…と思っていたら再起動するとBluetoothのペアリングが消える？ ので面倒くさかったのですが、これならまずｓｓｈでログインしてキーボードをペアリング、その後コンソールログインすれば良さげな感じ。
と言うわけでキーボード的にはミヨシのTK-BT01がおススメです。テンキーの無いコンパクトキーボードながら、トラックボールとホイールまで付いており、PC、Mac、Android、iOSのフルサポートという逸品。前機種にあたる専用ワイヤレスアダプタのときは不可能だった、トラックボールの取り外し掃除も簡単になりました…っ(これは嬉しい)