Dockerfile の ARG に対する値入力

--build-arg <変数名>=<値>

--build-arg <変数名1>=<値> --build-arg <変数名2>=<値>

--build-arg USER_ID=`id -u` --build-arg USER_GROUP_ID=`id -g` --build-arg USER_NAME=`id -un`

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

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

オンラインの参考資料 (Docker ドキュメント日本語化プロジェクト)

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の構築
• Sambaの導入
• Windows PCから接続確認
• 各種ヘルスチェックの設定

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)に接続できないとき

1. Socketが見つかっていない可能性を疑う
2. php --ri mysqli とか php --ri pdo_mysql でパラメータをチェック
3. Socketが設定されていない、もしくは正しくない場合は php.ini を確認
4. そもそも何処の php.ini を見ているのか、と言う点を疑う
5. 何処の 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 を見るようになりました

1GBプランのバックアップイメージを512MBプランへ展開することはできない ようなので、結局手動で移設したなど。同期に失敗してデータ欠損しないかと動悸が止まりませぬ。

前提条件

手順

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リポジトリへのアクセスが遅いように感じました。メモリでしょうか…？

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

方法

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

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

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

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は早めに対応しないとなぁ…。

ConoHa VPSに標準で用意されているownCloudアプリケーションサーバーとConoHaオブジェクトストレージを組み合わせて、Windows PCから同期可能なオンラインストレージを作る試み。まずはowncloudを起動するまで。

[2015.12.10] 追記

後編 も書きました。

レシピ

• ConoHa VPS (ownCloudパッケージ)
• ConoHa オブジェクトストレージ
• ownCloudのリファレンス
• このはへの愛(ん？)

VPSとオブジェクトストレージを契約

1. 清楚可愛いこのはちゃんと契約する
2. 言語モードを「このは」にする(重要!)
3. ConoHaチャージ(月額で最低金額1500円くらいかな)またはクレジットカードを登録する
4. ConoHa VPSは次の仕様で組んでみた
   • vCPU 1個
   • メモリ1GB
   • 東京リージョン
   • イメージタイプは「アプリケーション」を選択(初期値)
   • アプリケーションは「その他」から「ownCloud」を選択、バージョンは8-x64固定
     • なお、ベースになっているOSは CentOS release 6.7 (Final) カーネルは 2.6.32-573.7.1.el6.x86_64 でした (2015.12.06現在)
     • owncloud自体は 8.1.3 がinstalled、yumで 8.1.4 が来ていますね(後程アップデートしませぅ)
   • rootパスワードをセット
   • 自動バックアップはお好みで。今回はアプリケーションサーバーとしてのみ使用するので、変更した設定さえ別途保管しておけば全体バックアップは不要かも。
   • ディスク容量は最低のSSD50GBで十分。これでも多いかも？
     • インストール後の空き容量は / が 51GB割り当て、47GB空きなのでがら空き…
   • 準備が整うまでは色々危ないので、取り敢えず接続許可ポートはすべてOff(コントロールパネルのブラウザコンソールで作業する)。なお、ここのポートはConoHa VPS外部のファイアウォールらしく、VPS側でSSHポートを22番以外にした場合は「すべて許可」一択となる。
   • SSHキーはお好みで新規作成するなり、手持ちをセットするなり
   • ネームタグもお好みで

あとは料金を確認して「追加」ボタンを押し、準備が整うまでこのはちゃんのお姿を堪能して待ちませぅ。

コンソールを開いてVPSの初期設定

1. 左側「サーバー」から目的のサーバーを見つけ、ネームタグをクリック
2. 「コンソール」アイコンをクリック(新しいWebブラウザ画面で仮想コンソールが開く)
3. 画面が真っ暗ならEnterとか押してみる
4. 作業アカウントを作る
   • rootで作業すると失敗が致命的になるし、rootでのSSHログインは拒否しておきたいので、通常作業するための作業アカウントを作り、sudo権限を与える
   • [注意！] ConoHaのコントロールパネルでセットした公開鍵は、rootアカウントに紐付けられています(/root/.ssh/authorized_keysに書き込まれる)。作業アカウントは別途キーを準備するなり、rootからキーを奪ってくるなりしましょう(rootのキーを移動した場合はパーミッションとオーナーに注意)。
5. /etc/ssh/sshd_config を開いて編集
   • 「Port 22」のコメントアウトを外し、22番以外の未使用ポートに変更 (ポート22狙いのアタッカーが回避できます)
   • 「PermitRootLogin」を「no」に変更 (SSH経由でのrootログイン不可)
6. /etc/sysconfig/iptables を開いて編集 (空だった)
   • -A INPUT -m state --state NEW -m tcp -p tcp --dport <SSH port> -j ACCEPT を追記
   • (owncloudのWeb画面を開くために)-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT を追記
   • あとはお好みで。基本的に全部 REJECT してホワイトリストのポートだけ ACCEPT すれば良いかと。
   • この辺りのことは覚えたところで、どうせ CentOS 7になればfirewalldに代わって役に立たなくなりますよ… (今回firewalldを探して10分くらい彷徨った…)
7. sshdとiptablesを(再)起動
   • $ sudo service sshd restart
   • $ sudo service iptables restart
8. ConoHaのコントロールパネルの「ネットワーク情報」をプルダウンさせ、「接続許可ポート」で「すべて許可」を選択(以後、ポートアクセス制御はVPS側のiptablesに委任)
9. お好みのターミナルエミュレーターから接続できることを確認 (以降はターミナルエミュレーターから作業)
   • 念のため、rootでログインできないことも確認しませぅ
   • さらに念のため、ConoHaコントロールパネルのWebブラウザコンソールからはrootでログインできることを確認しませぅ
10. 適当なタイミングで sudo yum upgrade でも打って最新環境にするべし

ownCloudの設定

1. コンソールにログインするとwelcomeメッセージとして URLやらMySQLのパスワードやらが表示されるので、URLにアクセスする。
2. 管理者アカウントを作成する
3. 試しに適当なファイルをアップロードしてみる

たぶん通常アカウントを作って、そっちで使ったほうが良い…いや所詮プライベートストレージだからこのままでもいいか…な？

なおアップロードしたファイルは /var/www/html/owncloud/data/<アカウント名>/files/ に収まる様子。 (/var/www/html/owncloud/data/ 以下はapacheユーザー/グループ管轄、otherにアクセス権無し)

残項目

• HTTPSアクセスにしたほうが良い気がするぞ
• ポートをガチガチに塞ぎ過ぎてメールアラートも出なくなってるので、必要なポートを開けたい
• ていうかちゃんとドメイン割り当ててメールサーバーも設定しておこう
• 本題であるWindowsとの同期とオブジェクトストレージの使用はどうした

[2015.12.08] 追記

yum upgrade したのち reboot してそのまま気持ちよく作業を終えたところ、数日経ってからアクセスしたら owncloud がメンテナンスモードに入ってしまっているという仕打ちが発生。モード解除自体は /var/www/html/owncloud/config/config.php 内の　’maintenance’ を false にすればOKだったのだけど、なんでメンテナンスになったんだ…。しかも画面には「owncloudを再起動すれば解除されます」とある割に、 httpd をリスタートしても何も変わらんかったし。

もしかして yum upgrade で owncloud 自体が 8.1.3 から 8.1.4 にアップデートされたので、このタイミングで自動的にメンテナンスモードになるんですかね…？

あと数日放置してたら、案の定 httpd にアタッカーの皆さんからご訪問を受けておりました。幸い突破された様子は無かったけど、一度アクセス範囲を見直したほうが良さげ。

[2015.12.10] 追記

後編 に続く…！

ざっくり言うと、pfsenseのSSHログインを有効化+ProxyCommand+nc、といった具合。

[localhost(on the Internet)] -->[pfsense server] -->[target server(on the private network)]

参考にしたサイト

• HOWTO enable SSH access

  …しかしここの説明だとWAN側からのログインを有効にする方法が分からず手間取ったさ。

• How to Access pfSense Remotely Using SSH

  上記サイトと説明がかぶるのだけど、ここでFirewallのRule設定に言及があったので。まぁpfsenseの説明をよく読めば分かったことかも知れんけど。

• ２段階SSH接続を，ProxyCommandを使って一度のsshコマンドで接続する

• 多段 ssh / rsync するために ProxyCommand を使ってみる

• SSH_CONFIG (5)

やりかた

pfsenseの設定

1. pfsenseの管理画面にログイン、System >Advanced >Admin Access >Secure Shellに移動
2. [Enable Secure Shell]をOnに
3. 安全のため[Disable password login for Secure Shell (RSA/DSA key only)]をOnに
4. [SSH port]を適当に指定(仮に114114とでもしておこうか)
5. 以上でSave
6. System >User Managerへ移動、Add Userを実行
7. 冒頭のイメージ図で[localhost(on the Internet)]から[prsense server]へ接続するためのユーザを作成、Save
8. 作成したユーザの編集画面を開き、[Effective Privileges]に[User - System - Shell account access]を追加
9. [Authorized keys]にの公開鍵を追記
10. 以上でSave
11. Firewall >Rulesに移動、Rule追加を実行
12. [Destination]を[WAN]に、[Destination port range]に114114を指定
13. 以上をSaveし、さらにApply change実行

pfsenseの設定は以上で完了。必要に応じ[localhost(on the Internet)]から[pfsense server]にsshログインできることを確認。

クライアント・サーバー(接続先)の設定

1. [localhost(on the Internet)]の公開鍵を[target server(on the private network)]の.ssh/authorized_keysに登録
2. .ssh/configを以下のように記述

   Host gateway
   HostName pfsense_server
   Port 114114
   Host target
   HostName target_server
   ProxyCommand /usr/bin/ssh gateway /usr/bin/nc %h %p
   

.ssh/authorized_keys、.ssh/configのパーミッションには注意すること。

以上を実施のうえ、次のようにsshコマンドを実行することで[pfsense server]を介して[target server(on the private network)]に接続できるようになる。sshの他scp、sftpも使用可能。

[localhost(on the Internet)]$ ssh target_server