Logical Rabbit.

さくらのVPS

Linux

Vagrant+Ansible+VirsualBox on CentOS。

CentOS 7.5上でVagrantとAnsibleを使ってVirsualBoxを操作しようとしたら環境設定に色々ハマった記録。バグトラップな上にグーグル先生が的確な情報出してくれない!!

問題山積み

  1. VirsualBoxのインストールで失敗する (modprobe vboxdrv が云々)
    • secure bootの影響で、署名がないモジュールをロードできないのが原因。署名すればよい。
  2. だがしかし、署名に使った公開鍵がenrollできない
    • mokutilのバグ。1つ前のバージョンに戻す。
  3. Mac OS X用のVagrantfileとCentOS(Linux)用のVagrantfileではansible providerの名前が異なる
  4. なんかVagrantfileからは実行できないのに、ansible-playbookでは実行できるんですが… (これは秘密鍵のパスとか、そういう問題かも)
  5. NFSマウントが失敗する
    • firewalldがお仕事してた。vboxnet0をtrusted zoneへ叩き込む(いいのかそれで?)
  6. "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コンソールが起動しないとのこと。 以下にその説明があります。

0014050: Failed to Enter Shim UEFI key management screen while rebooting on CentOS7 if upgrade to 7-4.1708

元々問題に気付いたのはこのあたりの記事。 "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/ から mokutilshim のRPMをダウンロードして、最新版を yum remove で削除後にインストールします。

成功すれば、ブート時にきっちり止まりますので確実に分かります。

この作業前に mokutil へ鍵を登録したりパスワードをセットしていた場合、その作業からやり直しになるので注意してください。

Mac OS X用とCentOS(Linux)用とのVagrantfile差異

一覧に書いた通りです。Mac OS X 用は ansible 。CentOS用は ansible_local 。このあからさまな違いから見て、CentOS用は何か使い方を変えると ansible になるのかもしれませんが。

参考記事は以下。

Ansible Local Provisioner

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かな、と。

  1. firewall-cmd --add-interface vboxnet0 --zone=trusted
  2. firewall-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ベースでNAS構築(Windows用)

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環境を作るまで。

遅ればせながら「さくらのクラウド」にアカウントを作って、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を使うための環境が概ね整いました。

ConoHa VPS(1GB)で構築したOwnCloudサーバーをVPS(512MB)へ移設した。

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オブジェクトストレージ

手順

  1. ownCloudとの同期アプリを全て終了(自動起動もOFFにしておくとなお安心)
  2. 現サーバーでmysqlのフルダンプを取得
    $ mysqldump -u root -p owncloud_db |gzip -c > owncloud_db.dump.gz
  3. 新サーバー構築
    1. ConoHaコントロールパネルへログイン
    2. [サーバー追加]タブ
      • タイプ=VPS
      • メモリ=512MB
      • イメージタイプ=アプリケーション
      • アプリケーション=[その他] – ownCloud
      • ディスク容量=SSD20GB
      • その他の設定=適宜
    3. サーバー起動後、OSアップデート、作業ユーザー追加等々のセキュリティ対策は適宜。
  4. 現サーバーから新サーバーへmysqlのフルダンプをコピー
    $ scp owncloud_db.dump.gz  <新サーバーIP>:
  5. 現サーバーの /var/www/html/owncloud/config/config.php を新サーバーへコピー (注: このファイルはapacheオーナーのみ参照可になっているので、適当にセキュリティ突破すること)
    $ scp /var/www/html/owncloud/config/config.php <新サーバーIP>:
  6. 新サーバーへログイン
  7. mysqlのダンプを新サーバー上mysqlへロード
    $ zcat owncloud_db.dump.gz |mysql -u root -p -D owncloud_db
  8. config.php を /var/www/html/owncloud/config/ へ配置 (注: 既にファイルが存在するので、適宜バックアップ)
    $ sudo cp config.php /var/www/html/owncloud/config/config.php
  9. /var/www/html/owncloud/config/config.php の内容を編集
    1. trusted_domainsの配列内に現サーバーのhostname, IPアドレス等があるので、これを新サーバーのものへ変更
    2. overwrite.cli.url のドメイン名部分を現サーバーから新サーバーのものへ変更
    3. version を 現サーバー(8.1.5.2)から新サーバー(9.1.1.3)へ変更
    4. dbpasswordを新サーバーのmysqlサーバー、owncloud_userアカウントのものへ変更
  10. /var/www/html/owncloud/config/config.php のオーナーを user=apache, group=apacheに変更(なお、SELinuxはDisabledになっていました)
    $ sudo chown apache.apache  /var/www/html/owncloud/config/config.php
  11. apache2をリスタート
    $ sudo systemctl restart httpd
  12. 新サーバーのOwncloudへWebアクセスしてみる (成功していれば、セットアップ画面ではなく通常のログイン画面が表示されるはず)
    • このあたり、初回はプラグインのアップデートが始まる場合も
  13. 新サーバーのOwnCloud上にあるべきファイルがあることを確認
  14. 各OwnCloud同期アプリを起動
    1. 現サーバーの設定を削除し、新サーバーの設定を追加
    2. 同期が成功することをConoHaたんに祈る
  15. 現サーバーはこれにてお役御免ですので、最後にバックアップするなり、きれいに削除するなり、お好きに。

新サーバーへの残項目

  1. HTTPS化
  2. SELinuxがDisabledなので有効化したい
  3. PHPが5.6系なので7.x系にしたい
  4. ていうかこの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リポジトリへのアクセスが遅いように感じました。メモリでしょうか…?



ConoHaの既存プラン(メモリ1GB)のイメージを512MBプランでロードできなかった話。

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 7でBB無線ルータを組んだ時、無線LANから有線LANへWoL信号を飛ばしたい。

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は同一セグメント

方法

  1. /etc/dhcp/dhcpd.conf にて、DHCPにおいてMACアドレスとIPアドレスを固定で紐づける
  2. arp -s <IP address> <MAC address> としてARPテーブルにおいてMACアドレスとIPアドレスを固定で紐づける
  3. firewall-cmd --add-port=9/udpとしてWake on LANが使用するポート番号9(UDP)を解放する
  4. Wake on LANするときは対象マシンのIPアドレスとポート番号を指定して送信する(同一ポート上で実行する場合はブロードキャストモードで送信するか、IPアドレスとしてブロードキャストアドレスを指定して送信している筈)。

firewalldでMACアドレス指定の信号をポート間で通すとか、ブロードキャストを通すとかできれば済むような気はしていたのだけど、私の実力じゃ調べきれず、結局この方法で解決できたのでまあ良しとしたい。ポート9(UDP)がフル解放されている気がしないでもないが…うぅむ?

arpテーブルに気付いたのは、対象マシンを止めた直後であればWOLが通るので、もしかしてIPアドレスが誰に割り振られているのか分からなくて迷子になってるんぢゃね? と。マシン停止直後だとDHCPのリースとか生きてるだろうから、その辺を固定化してやればいいんぢゃね? という具合。

なおCentOS 7だとarpではなくip neighを使うべきらしいのだけど、Blogに纏めるにあたり試してみたもののこちらのコマンドでテーブルに追加する方法がうまくできず断念したなど。

本当はWake on LANのマジックパケットの仕組みとかから調べ始めていたのだけど(うまく通過できないから専用のサーバ立ててしまえばいいんじゃね、とか思った)、この辺りって軽くググった程度だとうまく見つかりませんね…? まあ結局無駄なこと調べていたっぽいけど。

さくらのVPSをOS更新したい…という話。

現状この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をそこそこ長く使っているとこの手の問題は出て来る筈なので、何か便利なサービスがあっても良いと思う今日この頃。

CentOS 7 でコマンドラインからBluetooth接続を操作する

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 キーボードを接続すると以下のような感じ。MACアドレスは各々XXとYYの羅列にマスク、hostnameはログインしている機体のホスト名が出ますが、一応マスクで。

$ 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のペアリングが消える? ので面倒くさかったのですが、これならまずsshでログインしてキーボードをペアリング、その後コンソールログインすれば良さげな感じ。

と言うわけでキーボード的にはミヨシのTK-BT01がおススメです。テンキーの無いコンパクトキーボードながら、トラックボールとホイールまで付いており、PC、Mac、Android、iOSのフルサポートという逸品。前機種にあたる専用ワイヤレスアダプタのときは不可能だった、トラックボールの取り外し掃除も簡単になりました…っ(これは嬉しい)

PRIMERGY MX130 S2にCentOS 7を入れたらハマった。

AMD CPUのPRIMERGY MX130 S2 にCentOS 7をいれてyum upgradeしたら microcode: failed to load file amd-ucode/microcode_amd.bin などと言う謎のエラーを吐いて起動しなくなっているお話(現在進行形) (解決したのでオチを追記)。

古の激安サーバー()であるPRIMERGY MX130 S2が職場に2台あるわけですが、うち1代のHDDがS.M.A.R.T.エラーを噴いて撃沈したのをいいことに、CentOS 7で再構築を始めたわけですよ。とりま、 yum upgrade でまるっと更新かけたわけですよ。 kernel が更新リストに入っていたから、何も考えずリブートしたわけですよ。

…カーネルパニックみたいな状態になって起動どころかCTRL+ALT+DELすら受け付けない状態になったわけですよ(汗)

電源断して起動時に1つ前のkernelを指定したところ無事起動したので、dmesg.oldを見たところ、最後のメッセージが冒頭の “microcode: failed to load file amd-ucode/microcode_amd.bin”。

で、このメッセージでGoogle検索してみると、以下のバグトラックが出てきた。どうも同じ現象っぽい。

0007331: Failed to load file microcode_amd.bin

実際、 /lib/firmware/ の中に amd-ucode/ というディレクトリ自体が存在しないのでそりゃファイルのロードもできないよね、という状態ではあるのだけど、今一つ分からないのが、今回の現象が意図的に行われたのか誰かのミスなのか、というところ。

英文なんで斜め読みで取り敢えず解決方法だけ探してる状況なのですが、解決方法自体はまあ、バグトラックに言及があるURLからmicrocode一式をダウンロードして入れてしまえば良さげです。

ただ仮に今回の現象が意図的なもので、今後kernelにはこのファイル群が入らないとなると、このサーバー機はCentOS 6止まりにしておくとか、運用終了も考えたほうが良い気がします。ただ、意図的な足きりならば、この手のバグトラックは割と早い段階で開発当事者の人が出てきて「そいつはもうサポート外だ」で 終わると思うんですよね。なにやら話題は継続している様子だし、足りないファイル入れておしまいなら早々にバグフィックス版が出てもよさそうなのに、1年以上もスレッドが続いている。

そして何より気にかかるのが、PRIMERGY MX130 S2を買った、CentOS入れたという日本語記事はわりとGoogle検索にひっかかるのに、このバグに遭遇したという日本語記事が出てこない。みなさんなんで大丈夫なの??

ともあれ、明日(というか今日)出勤したら、問題のファイル群を押し込んで経過観察する予定。

[2015.12.29 追記]

いや本当は12/17に解決していたのだけど、記録する暇が無くて…。

結論。microcodeは関係なかった。つか然るべきファイルを置いてみても「ファイルが無い」というエラーは出ていないもののフリーズする現象は止まらず。再度ググったところ、以下と同じ現象だった模様。

Kernel 3.10.0-327 issue on AMD Neo processor

同じ方法で対策してみたところ、安定稼働するようになりました。その後本格的なシステム構築を始めて仕事納めの12/25まで24時間動作続けています。

しかしclocksource_done_bootingってなんだろう…。名前から察してタイマー割り込み系かしら。

ConoHaのownCloudとオブジェクトストレージでオンラインストレージを作る(後編)

ConoHaのownCloudとオブジェクトストレージでオンラインストレージを作る(前編)の続き。いよいよオブジェクトストレージと連結し、Windowsの同期バックアップストレージとして運用しますよ。

ownCloudのデータ保存領域をオブジェクトストレージにする

ownCloud のドキュメントに設定のサンプルがあります。ただ、一部項目の入れ替えが必要となりますので注意。

ConoHaオブジェクトストレージを契約する

  1. ConoHa管理画面の「オブジェクトストレージ設定」 を開く
  2. 「ディスク容量」バーの右端にある設定アイコンをクリック
  3. お好みでディスク容量をセット。最低100GBからなので、予め使う容量が分かっているのでなければ、とりま100GBでよろしいかと。容量セット後から課金スタートです。

ConoHaオブジェクトストレージのAPI情報を確認する

APIユーザーにパスワードを設定します。既にある場合はテナント名、パスワード、エンドポイントURLを確認。

  1. 左側グローバルメニューの上から7つめ「API」をクリック
  2. 「APIユーザー」の右側「+ユーザー」ボタンをクリック
  3. 適宜パスワードをセット。ConoHaアカウント自体、ownCloud管理者、ownCloud運用VPSのroot(権限を持つ)アカウント等とはパスワードを変えておいたほうがより安全かと思われ。
  4. パスワードの他、画面上段の「テナント情報」内「テナントID」と「エンドポイント」内「Identity Service」の情報も確認。

ownCloudにオブジェクトストレージの情報をセットする

/var/www/htmi/owncloud/config/config.php に以下の内容を追加します。’dboassword’等と同じ階層になるよう注意。

'objectstore' => array(
  'class' => 'OC\\Files\\ObjectStore\\Swift',
  'arguments' => array(
    'username' => ←APIユーザー名
    'password' => ←APIパスワード
    'container' => 'owncloud', ←任意のコンテナ名(別途作成が必要)
    'region' => ← Identity Service URLの identity と conoha.io の間にあるサブドメインを指定。認証情報の endpoints.region としても得られます
    'url' => ← Identity Service のURL
    'tenantId' => ←テナントIDをセット
    'serviceName' => 'Object Storage Service' ←ConoHa APIのエンドポイント名
  ),
),

ハマった点としては tenantIdがありました。ownCloudのサンプルコードでは tenantName を使用しており、ConoHaのAPI情報にも「テナント名」があるのでてっきりコレかと思ったのですが、「テナントID」のほうを渡してやらないとConoHaの認証エンドポイントから他のエンドポイント一覧が提供されないという罠。しかも tenantName があると tenantId を書いてあっても無視される。…というのを ownCloud のソースコードを追いかけまわしてようやく見つけましたよ…。

ConoHaオブジェクトストレージにコンテナを作成する

コンテナは自動では作成されない模様。 autocreate オプションは true にしてみても反応しないし、ソースコード中には「テスト用」的なコメントがあったのでどこかで無効化されているんだろうな。ともあれ、仕方ないので node.js でコンテナ生成だけ実行するスクリプトを書きました。gistにテンプレートがありますので宜しければどうぞ(以下)。こちらでの注意としては、認証URL(AuthURL)にバージョン番号が入らない点があります。node.jsは v5.2.0-linux-x64 を使用していますが、ほぼ同一の JavaScript を他のサーバーでかなり前に入れた v0.12.7 で動かしていたりしますので、概ね動くかと思われ。しかし node.js のバージョン番号はよく分からん。なんで1年も経たないうちにこんなに上がるんだ。

Windows 7 との同期

できれば WebDAV でスマートにいきたいのですが、HTTPS にしないといけないようです(レジストリをいじればいけるっぽい)。後々ちゃんとしたSSL証明書を取得する方向でいきたいので、今回はひとまず ownCloudの公式デスクトップアプリを使うことにします。

  1. owncloud.org の ダウンロード画面 から「Desktop Clients」をクリック、Windows用インストーラをダウンロード
  2. さくさくとインストール(これといった選択肢もありませぬ)
  3. さくさくと起動すると、サーバーアドレスを入力する画面が現れますので、http:///owncloud/ を入力(結局ここでもHTTPS問題が発生…致し方なし)
  4. ユーザ名とパスワードを入力
  5. サーバー側の同期対象フォルダ、ローカル側の同期対象フォルダを選択

あとはローカル側に作成された同期フォルダにがつがつとモノを入れていけば同期されるようデス。

ファイルの行先を確認など。

本当にちゃんとConoHaオブジェクトストレージに収まっているんでしょうか…?

  • owncloud をインストールした VPS の /var/www/html/owncloud/data/administraotr/files/ にはファイルが作成されていません
  • ConoHaオブジェクトストレージのディスク使用量を確認すると、イイ感じに増加しております

ということで、まあオブジェクトストレージには収まったかな、と。次の疑問は、具体的にどういうオブジェクトになっているのか、とか、メタデータとかどうなんですかね?といった点ですが。

あと、HTTPSは早めに対応しないとなぁ…。