ISUCON6で予選敗退した

ISUCON6の予選にチームWCDIとして出てきました。
スコアは6,000ちょいでした。

別のメンバーが詳しく書いてるので感想的なものだけ。

blog.acqn.xyz

ISUCONは前々から興味があって出たいなーとか思っていたのですが
なかなか一緒に出てくれるメンバーが集まらなかったりで参加できずじまいでした。
今回は運良くメンバーが見つかったので念願の初参加です。

事前準備する時間がほとんどなかったのでとりあえず全員が書ける言語でってことでPythonを選択しました。
(ただ今までの予選の結果や本戦の言語選択を見ると若干Python不利なんじゃないかなーとか思ってたのはここだけの秘密。)

私の担当はRedisまわりやキャッシング的な部分でした。
とりあえずRedisを使うのは初めてだったので一週間ぐらいで突貫工事しました。
ただ本番でDBをRedisに乗せようってことになったのですが普段やってないことはやっぱり出来ないものですね...結局実装が間に合わないだろうと判断して断念してしまいました。(くやしい

ISUCONは事前準備が大事だと言う話をちらほら見かけたのですが
まさにそのとおりだなと感じました。

でもチームメンバーとあーだこーだ言いながらチューニングしていくのはやっぱり楽しかったです。 次回は本戦行けるといいなあ。

第6回ICTSCトラブルシューティングコンテストで優秀賞をもらった&writeupのようなもの

2016-09-15 "感想とか" の下辺りに成績表やメンバーのブログなどを追記しました

8月27,28日に大阪で開催された第6回トラブルシューティングコンテストにチームWCDIとして参加してきました。
今回もひっそりと記録を書き残しておきたいと思います。

icttoracon.net

今回で4回目の参加です。前回と同じくサーバサイドを担当しました。

ちなみに第5回の記事↓
blog.hnron.net

今見たら前回の記事があまりにも適当だったので今回は割と真面目に書きます。

今年のメンバー

前回のメンバーから3年生が1人抜けて代わりに1年生が1人入りました。
3年2人、2年2人、1年1人の構成です。

役割分担ですが、今回はサーバサイド2人、ネットワークサイド2人、フルスタック1人にし、
サーバとネットワークでどちらかに問題が偏った場合に、片方に負荷がかかりすぎないような構成にしました。

戦略とか色々

前回までの反省から戦略は色々と考えていました。

役割分担とか

(今年は色々と事情が変わりましたが、)
例年通りなら問題は、「1日目午前、1日目午後、2日目午前、2日目午後」の4つの区切りに分けて出題されます。
基本的には午前から午後、1日目から2日目とまたいで問題が出題されることはなく、制限時間はからなず各区切り内で終わるように設定されていました。
また、問題はだいたい3問ずつ出題され、サーバとネットワークの比率が 2:1 or 1:2 になるように出題されています。

前回まではサーバ3人ネットワーク2人のように分けていたため、人数が少ない方に高難易度の問題が集中すると負荷が偏ってしまうことがありました。
これを踏まえ今回の役割分担ではフルスタック枠を1人分用意しました。

結果として2日目午前までは安定して問題を解くことが出来ました。
しかし、2日目の午後は例年とは違った形で出題されました。午前からまたいで出題された問題が1問 + 午後新たに出題された問題が5問の計6問を2時間で解くことになりました。
かなり異例の問題ラッシュでしたが、問題が解けたかは置いておいて1人フルスタック構成がいい感じに機能し1人1問を上手く割り振れました。
(問題を解いている最中はサーバ問題4問ネットワーク問題2問だと思っていた)

範囲とか

いままでの反省から全員が同じ範囲を勉強するよりも、手分けして出来るだけ広範囲をカバーしたほうが安定するような気がしたので勉強内容がかぶらないよう担当範囲を調整しました。

また当日のタスク振りをスムーズにするために、勉強会ごとにどの技術をどのくらい学習したか(構築してトラブル事例を調べた、ドキュメント読んだだけなど)をslackにあげて共有しました。

slackといえば当日の情報共有は今までownCloudなどを用意していたのですが、slackだけでよくね?となったので今回はslackのみです。

問題の解き方とか(サーバサイド)

結構前からこのスタイルだったのですが、一番最初にトラブルの原因を見つけた人がそのまま解答提出まで一人で行うという感じで問題を解いています。

もう少し詳しく説明すると
問題が出題されたら誰がどの問題を解くかを割り振ります。(基本的にはその人が解きたい問題)
問題に割り振られた人が一人なら問題ないのですが、もし複数人が割り振られた場合は原因究明までは協力して行います。
ただし、トラブルの解決と報告は基本的に誰か一人だけで行うという感じです。

これは複数人でトラブルシュートしている際の「あれ?誰か今何かした?」などの "やらかした" 系を出来る限り防ぐためです。
本来であればコミュニケーションや情報共有をしっかり行っていれば "やらかした" は起こらないはずですが、 当日緊張していたりテンパったりするとわりと "やらかす" 場合が結構あったりするので自然とこのスタイルで問題を解くようになっていました。

気になってること

他のチームが2日目午後でどんな感じにメンバーにタスクを振ったのかが気になってます。
他には、さっき書いた問題の解き方で「トラブルの解決と報告は一人で行う」という方法ですが、他のチームはどういうふうに問題を解いてるかも気になっています。

結果

結果は優秀賞(2位)でした。
430点中、1位は219点、私達は175点でした。

2日目午前までの段階で9問中7問ぐらい解けていたのでそれなりに自信があったのですが、
2日目午後を6問中5問ほど落としてしまっているはずなので、そこができていたらと思うと結構悔しいです。

感想とか

今回も楽しかったです。
スコアサーバや出題パターンの変更など、新要素がいくつかあって新鮮味がありました。
個人的には2日目午後がいい感じに緊張感と絶望感があって楽しかったです。
また、いくつか新たな反省点も出てきたので次回はこれを踏まえて戦略を立てたいと思います。

チーム的には結構安定してきたように思います。 第3回大会ではボロ負けでしたが、第4回で最優秀賞、第5回で5位、第6回で優秀賞と安定して上位を取れるようになってきました。
サーバ問題は大体解けるようになってきたのでネットワーク側で確実に点が取れるように強化したいです。

次回は最優秀賞取ります (でも次回運営募集してたら運営もやってみたかったり)


2016-09-15 【追記】
追記その1
成績表が送られてきたので公開しておきます。
2日目午後、落とした問題が6問中5問だと思ってたら全問落としてた
あとやっぱり運営OBつよい

追記その2
最優秀賞のチームの方がブログでこの記事を紹介してくれてました。(ありがとうございます)

biraprog.hatenablog.jp

追記その3
あと後輩が残りのwritewpを書いてくれました。

blog.acqn.xyz


writeup的な

以下writeupです
自分が触った問題だけです
答えがあってるかは保証できません
多分今年も公式で解答を出すと思うのでそんなに詳しくは書きません

Q3(1日目午前) 移行したアプリケーションが動かない!

アプリケーションはエラーログが表示されない仕様だったのでMySQLの設定とかログとか見てました。
書き込みが文字化けしていたので文字コードかなと思い色々探ってましたが特に問題はなし。(今考えたら文字化けはわざとでミスリードを狙ってたのかも)

後輩がおもむろにループバックアドレスに対してtcpdumpしたところ、MySQLのパケットを拾えたのでそこからエラーメッセージを拾ってきて原因を突き止めました。

ちなみにそのエラーメッセージ↓

In aggregated query without GROUP BY, expression #1 of SELECT list contains nonaggregated column 'dengon.message.id'; this is incompatible with sql_mode=only_full_group_by  

後は後輩がやってくれました。

ちなみに提出した解答

ご依頼にありました件につきまして、サーバの更新によりMySQLのバージョンが変わってしまったのが原因でした。  
新しいバージョンのMySQLは、「sql_mode」によるSQL文の判定条件が変わっており、以前より厳密に判定されるようになっていました。  
tcpdumpでパケットを見て確認したところ、今回の伝言板アプリケーションはこの厳密な規格にそぐわない形式でgroup by句が使われているため、SQLでエラーが発生して投稿に失敗しておりました。  
今回のプログラムはELFファイル(実行ファイル)だったため、ソースコードの変更は不可能だと判断し、MySQLサーバの設定の変更を行いました。そのため、以下のファイルを追加したしました。  
  
/etc/mysql/conf.d/mysqld.cnf  
> [mysqld]  
> sqlmode=NOENGINE_SUBSTITUTION  
  
以上の操作により正常に投稿が出来ることを確認いたしました。  
以上、よろしくお願いいたします。  

Q6(1日目午後) VMがネットワークにつながらない!

片方のVMにはアクセス出来るがもう片方にはアクセスできないという現象が発生してました。
arpingしたところ、どうやらmacアドレスが被っていたようなので、それをそのまま報告しました。
また、つながらない方のVMと同じIPアドレスを使用しているコンピュータがもう1台いるみたいだったのでそれも報告しておきました。

正式な解答?はVMをコピーしたらmacアドレスがそのままコピーされてしまってmacアドレスがコンフリクトした、だそうです。

最初はGARPでイタズラされてるのかなとも思い判断に悩みましたが、tcpdumpの結果や、
1年の後輩が勉強会中にVirtualBoxで同じことをやらかしていたのを思い出し、macアドレスが被っただけかなぁと判断しました。

Q7(1日目午後) 自動マウントをしてくれない!

/etc/security/pam_mount.conf.xml ファイルを見てみたら普通にRead-Onlyの設定になっていました。

他にトラブルになりそうなものだと /etc/skel/private ファイルが作成されていました。
ディレクトリに作成し直そうとしたのですが、root権限で消せなかったので lsattr したところ、案の定「i」フラグが設定されていたので chattr でフラクを削除、ファイルをディレクトリに作成し直しました。

あとは pam_mount.conf.xml 内の mountpoint を修正しました。

mountpoint="home"
↓
mountpoint="/home"

その後 test01〜test05 ユーザを作成し、privateディレクトリがちゃんと配布されていることと、自動マウントが正常に出来ていることを確認しました。

解答文は長いので原文は載せませんが、

  • /etc/skel/ディレクトリにprivateディレクトリを作成
    • /etc/skel/private ファイルを chattr -i して削除したあと、privateディレクトリを作成した。
  • ユーザを作成
  • pam_mount.conf.xmlの編集
  • ファイルが作成できるか確認テスト

をやったことをコマンド付きで解答に書いて送りました

Q9(2日目午前) レプリケーションが出来ない!

一瞬NoSQLを期待しましたが普通にMySQLでした。(そろそろNoSQL系の問題が出てもいい気がする

$ show slave status\G コマンドから得た情報と、MySQLのエラーログから原因を突き止めていきました。

MySQLのログとか
接続先が無いと怒ってるっぽい

# MySQLのログファイル  
160828  7:40:50 [ERROR] Slave I/O: error connecting to master 'repl@192.168.5.5:3306' - retry-time: 60  retries: 86400, Error_code: 2013  
  
# show slave status\G の結果  
error connecting to master 'repl@192.168.5.5:3306' - retry-time: 60  retries: 86400  

レプリケーションの設定情報
なんかmasterのIPが間違ってる

mysql> show slave status\G  
    *************************** 1. row ***************************  
            Slave_IO_State: Connecting to master  
                Master_Host: 192.168.5.5 ← !!! masterのIPが間違ってる !!!  
                Master_User: repl  
                Master_Port: 3306  

masterのIP修正

mysql> STOP SLAVE;  
mysql> change master to MASTER_HOST='192.168.11.3';  
mysql> start slave;  

記憶が正しければこの時点でiptablesの tcp/3306 が空いていないことに気づいて開けたはずです。

MySQLのエラーログを確認する。
まだどこかが間違っているみたい

160828 11:19:14 [ERROR] Slave I/O: error connecting to master 'repl@192.168.11.3:3306' - retry-time: 60  retries: 86400, Error_code: 1130  

ユーザ情報を確認してみたらreplユーザのHostの設定が間違ってました。

$ mysql -u root --password=password -e "select Host, User, Password from mysql.user;"  
+--------------------+------+-------------------------------------------+  
| Host               | User | Password                                  |  
+--------------------+------+-------------------------------------------+  
| localhost          | root | *139..................................... |  
| problem11-template | root | *139..................................... |  
| 127.0.0.1          | root | *139..................................... |  
| 192.168.5.%        | repl | *22F..................................... |  
+--------------------+------+-------------------------------------------+  

replユーザの設定を修正

mysql> rename user 'repl'@'192.168.5.%' to 'repl'@'192.168.11.%';  

この後MySQLのログかなんかで server-id が被っていると怒られたので修正しときました。

server-id=100  
この行を以下のように変更  
server-id=101  

とりあえず分かった原因は

  1. tcp/3306 が空いていない
  2. slaveのMySQLの設定で、指定されたmasterのIPアドレスが間違っている
  3. master側のMySQLのユーザ設定で、replユーザのログイン可能Hostが「192.168.5.%」(正しくは192.168.11.%)と誤った設定がされている
  4. masterとslaveでserver-idが被っていたため、slaveが止まってしまう

解決方法

  1. master側のiptablesで tcp/3306 を開ける
  2. slaveのMySQLの設定で、masterのIPを正しく変更する
  3. masterのMySQLで、replユーザの設定を正しく変更する
  4. slaveのserver-idを変更する
  5. 一度DBを削除し、レプリケーションし直した

これに叩いたコマンドの詳細を添付してレプリケーションが出来ることを確認したと運営に報告しました。

他の問題(自分が触ってないやつで覚えているもの)

前回運営がIP電話でトラブっていたので今回SIPが出そう!と予想して対策してましたがダメでした...
IPv6問題は対策でv6のルーティングプロトコルや相互運用について調べたり構築したりしていて、指定された機材にNAT64の機能が無いことを知っていたので騙されずに済みました。
ここら辺の話はきっと後輩が書いてくれるはず

ArchLinux上で運用していたRedmineをDockerコンテナに移行したときのメモ

移行するにあたっての経緯

RedmineをArchLinux上で運用していたのですが、Redmine絡みのパッケージをアップデートするたびに問題が発生して運用が辛かった
やっぱ時代はDockerでしょ(適当

と言うことでdockerに移行しました。
その時の作業内容を残しておこうと思います。

そういえば...全く更新していなかったのですがRedmineって今バージョン3.2.0なんですね(アップデートほったらかしにしてた)
(RubyやOpenSSLを最新のパッケージにアップデートすると動作しなくなってたのこいつのせいなんじゃ...)

まずRedmineを最新バージョンに上げ、動作確認してからDockerに移行しました。
(せっかくArchLinuxで運用していたんだし、素直にaur/redmineのパッケージ使っておけばアップデート楽だったなと今更後悔)

ちなみにDockerに移行するとこの前やったowncloudとかの連携が全部出来なくなりますが、正直使ってなかったので無かったことにします。


現在のRedmineの環境

  • ArchLinux
  • Apache: 2.4.18-2
  • Redmine: 3.0.3
  • postgresql: 9.5.1-2

Dockerへ移行する前にRedmineのアップデート

Dockerに移行する前に、Redmineを最新バージョンに上げて動作確認したので一応手順を残しておこうと思います。

Redmineの公式ドキュメントを参考にアップデートしました。

バックアップ

まずPostgresqlをまるごとバックアップします。
身内用なので問答無用で落として物理&オフラインバックアップしました。(Postgres止めてディレクトリごとコピー)
その後Redmineもディレクトリごとコピーしてバックアップしておきました。

$ sudo systemctl stop httpd.service
$ sudo systemctl stop postgresql.service
$ sudo cp -a /srv/redmine-3.0.3 /srv/redmine-3.0.3-
$ sudo cp -a /var/lib/postgres/data /var/lib/postgres/data-
新しいバージョンのRedmineと入れ替える

では早速アップデートします。

Redmineの公式から最新バージョンのtarファイルを落として展開

$ wget http://www.redmine.org/releases/redmine-3.2.0.tar.gz
$ sudo tar fvxz redmine-3.2.0.tar.gz -C /srv/
設定ファイルやその他のファイルの移動

各設定ファイルを新しいconfigディレクトリにコピー

$ sudo cp redmine-3.0.3/config/database.yml redmine-3.2.0/config/database.yml
$ sudo cp redmine-3.0.3/config/configuration.yml redmine-3.2.0/config/configuration.yml

filesディレクトリを新しいRedmineにコピー

$ sudo cp -r redmine-3.0.3/files/* redmine-3.2.0/files/

pluginsディレクトリを新しいRedmineにコピー

$ sudo cp -r redmine-3.0.3/plugins/* redmine-3.2.0/plugins/
gemとかbundleとか(rubyワカラナイ

Redmineの実行に必要なgemをインストール

$ cd redmine-3.2.0/
$ bundle install --without development test
$ bundle exec rake generate_secret_token
パーミッションの設定
$ sudo chown root:root redmine-3.2.0/ -R
$ cd redmine-3.2.0
$ sudo chown -R http:http files log tmp public/plugin_assets
$ sudo chmod -R 755 files log tmp public/plugin_assets
データベースの更新
$ sudo systemctl start postgresql.service
$ sudo bundle exec rake db:migrate RAILS_ENV=production
$ sudo bundle exec rake redmine:plugins:migrate RAILS_ENV=production
クリーンナップ
$ sudo bundle exec rake tmp:cache:clear tmp:sessions:clear
Apacheの設定
#新しいRedmineのディレクトリに変更する
DocumentRoot "/srv/redmine-3.2.0/public"
トラブルシュート

エラーその1

There was an error parsing `Gemfile`: Permission denied @ rb_sysopen - /srv/redmine-3.2.0/config/database.yml. Bundler cannot continue.

https://wiki.blue-it.org/Redmine#Website_won.27t_come_up
ここを参考にしました

config/database.ymlのパーミッションを修正

$ sudo chmod 644 config/database.yml

エラーその2

App 8703 stderr: Rails Error: Unable to access log file. Please ensure that /srv/redmine-3.2.0/log/production.log exists and is writable (ie, make it writable for user and group: chmod 0664 /srv/redmine-3.2.0/log/production.log). The log level has been raised to WARN and the output directed to STDERR until the problem is fixed.

production.logのパーミッションを修正。
他にもあるかもしれないので以下をもう一度実行しておきました。

$ sudo chown -R http:http files log tmp public/plugin_assets
$ sudo chmod -R 755 files log tmp public/plugin_assets
新機能の追加

管理 -> ロールと権限
ここで新しく追加された機能を有効にしておきます。

動作確認

redmineにアクセスしてちゃんと動作するか確認します。


Dockerコンテナにマイグレーション

と、言うことでアップデートと動作確認が終了しました。
これをDockerコンテナ(別サーバ)に移行します。

今回本番環境はdocker-composeを使います。

kubernetesとかで管理出来たらいいのですが今回は時間が無いのでそのうちやります(たぶん

本番環境にマイグレーションする前に、ローカルのdockerで移行手順や動作確認などのテストをしたのですがそこは割愛します。

ということで、以下の方法でマイグレーションしました。

  1. redmineサーバからDBとfilesをコピーしてくる
  2. docker-composeの用意
  3. DBのマイグレーション
  4. filesディレクトリのマイグレーション

移行先の環境と使用するdockerイメージ

環境

  • ArchLinux
  • docker:1.10.3
  • docker-compose:1.6.2

使用するdockerイメージ(全部オフィシャル

  • redmine:latest
  • postgres:9.5
  • busybox:latest

移行先のdockerサーバは、別コンテナで複数のwebサービスが動いているのでそれらをリバースプロキシ(dmp1ce/nginx-proxy-letsencrypt)で振り分けています。

1. redmineサーバからDBとfilesをコピーしてくる

Redmineサーバで以下のコマンドを使用してDBデータとfiles内をdockerサーバにコピーします。

redmine_server$ sudo -u postgres pg_dumpall -c > pg_redmine.dump

redmine_server$ cd /srv/redmine-3.2.0/
redmine_server$ tar fvcz ~/redmine_files.tar.gz files

# (私は一度ローカルに持ってきてから移行先サーバにコピーしました)
redmine_server$ scp pg_redmine.dump redmine_files.tar.gz docker-server:distination

2. docker-composeの用意

ディレクトリ構成
redmine-compose
├── containers
│   ├── postgres-datastore
│   │   └── Dockerfile
│   └── redmine-files-datastore
│       └── Dockerfile
└── docker-compose.yml
containers/redmine-files-datastore/Dockerfile
FROM busybox
VOLUME /usr/src/redmine/files
CMD tail -f /dev/null
containers/postgres-datastore/Dockerfile
FROM busybox
VOLUME /var/lib/postgresql/data
CMD tail -f /dev/null
docker-compose.yml
postgres-datastore:
    build: containers/postgres-datastore

redmine-files-datastore:
    build: containers/redmine-files-datastore

some-postgres:
    image: postgres:9.5
    volumes_from:
        - postgres-datastore
    environment:
        POSTGRES_PASSWORD: PASSWORD
        POSTGRES_USER: redmine

some-redmine:
    image: redmine
    volumes_from:
        - redmine-files-datastore
    links:
        - some-postgres:postgres
    environment:
        VIRTUAL_HOST: redmine.example.org
        VIRTUAL_PORT: 3000
        LETSENCRYPT_HOST: redmine.example.org
        LETSENCRYPT_EMAIL: example@example.org

some-redmineのenvironmentは、リバースプロキシにdmp1ce/nginx-proxy-letsencryptを使用しているのでそっちで使用する環境変数です。
一応そのプロキシのdocker-composeを載せておきます。

#nginx-proxy-compose/containers/certs-datastore/Dockerfile
FROM busybox
VOLUME /etc/nginx/certs/
CMD tail -f /dev/null

#nginx-proxy-compose/docker-compose.yml
certs-datastore:
    build: containers/certs-datastore
some-proxy:
    image: dmp1ce/nginx-proxy-letsencrypt:latest
    ports:
        - "80:80"
        - "443:443"
    volumes_from:
        - certs-datastore
    volumes:
        - /var/run/docker.sock:/tmp/docker.sock:ro
    environment:
        DEFAULT_HOST: example.org

3. DBのマイグレーション

まずpostgresとpostgresのデータ用コンテナのみを建ち上げます。

docker_server$ docker-compose up -d postgres-datastore some-postgres

postgresコンテナにredmineデータベースのリストアをします。

docker_server$ cat pg_redmine.dump | docker exec -i redminecompose_some-postgres psql -U postgres

postgresのRedmineロールのパスワードを設定しなおします。
(Dockerに移行する際にRedmineロールのパスワードを変更していなければやらなくて大丈夫)

# docker exec -i -t redminecompose_some-postgres psql -U redmine
postgres=# \password
postgres=# \q

4. filesディレクトリのマイグレーション

残りのコンテナの建ち上げます。

# docker-compose up -d

redmineのfilesディレクトリをdocker側に移行

# docker run -i -t --rm \
            --volumes-from=redminecompose_redmine-files-datastore_1 \
            -v /path/to/redmine_file.tar.gz:/tmp/redmine_file.tar.gz \
            busybox sh

# tar fvxz redmine_files.tar.gz -C /usr/src/redmine/
(tarの仕方によっては/usr/src/redmine/files)

しばらく動かしてみて問題なかったので上手くdockerに移行できたみたいです。

メールの設定は必要になった時に行う予定です。

これからはRedmineの新しいバージョンがリリースされてもRedmineのコンテナだけを入れ替えれば済むので管理が楽になりそうです。
やっぱDocker良いですね

参考サイト

http://redmine.jp/guide/RedmineUpgrade/

第5回トラブルシューティングコンテストに参加して来ました

ブログが三日坊主状態だったので、2/27,28に開催された 第5回トラブルシューティングコンテスト Cloudpack杯 にチームWCDIとして出場してきた話をひっそりと書き残しておこうと思います。

icttoracon.net

このトラブルシューティングコンテストですが、私個人としては3回目の出場でした。

普段は開発ばかりなのでルータやスイッチをさわれるはずもなく、毎回サーバ関連の問題を担当しています。

また、前回リーダーをやってくれていた4年生が出れなくなってしまい、私がリーダーを務めることになりました。
チームをまとめるのが、結構... というか かなーり 大変でした。

チームのはなし

チーム的には1,2年生のチームで、ネットワーク担当が2人(2年2人)、サーバ担当が3人(2年1人,1年2人)でした。
一応、メンバー的には(解けたかどうかは別として)どんな問題が出題されても手を出せるような構成にはなっていたので、割とバランスが取れたチームだったと思います。
(ちなみに前回は NW3人(2年3人) 鯖2人(2年1人,4年1人)でした)

結果とか色々

結果ですが、順位は16チーム中5位(2チーム同率)でした。
2連覇できなかった。残念!

せっかくなので次回の戒めのために主に自分がやらかした問題の記録を残しておこうと思いますw

#15 webページが見れない…

ディレクトリのパーミッションと、.htaccessのRedirect permanentの書き方がミスってたので修正。
キャッシュを消すと見れるようにはなっていたのですが 0点でした。悲しい。
(誰か正しい解答教えて)

#7 管理画面が見えない!

slaveサーバの構築自体は出来ていたので部分点は入ったかな?と思ってたけど0点でした。
ちなみにviewなんて機能があったことを初めて知りました。

よくよく考えてみると、10.0.0.0/8のアドレス全てに管理ページのAレーコードを返すように設定してしまいましたが

  • "よくわからないサイト" に、"なんとか部" って書いてあった
  • もしかしたら他の部署が使っていた可能性が...
  • 他の部署からしたら今までつながっていた "よくわからないサイト" に繋がらなくなった。
  • 激おこぷんぷん丸

こんな感じでだめだったのかも(圧倒的文章力不足

あと、日付を間違えたっていうのはシリアルのことかなぁと思って修正しました。
1000年ほど未来にタイムスリップしていたので今日の日付に修正。
slaveサーバの構築前に修正しておいたのと、構築後ちゃんとslave側に転送されてAレコードを引けていたのでおkかな?と思ったけど、 問題的にはちゃんとシリアルを巻き戻す方法使って戻さないとだめだったPOI?

あと時間が足りなくてTSIGとかの設定は出来ませんでした。

#11 弊社の変わった環境

結局解くことは出来ませんでしたが、なんだかんだで一番楽しかった問題です。

ネットワーク担当のトラブルメーカーが、解く問題が無いからと気がついたら勝手に解き初めていたのですが、
コンテナの構築は終わっていて(一応部分点も入ってた)、後は外側とサーバ内のコンテナをどうやってルーティングさせるかというところで、Bridgeを利用しようとしてIPアドレスを消してしまい、再起動。
本人曰く「GNS3を使っていたときの癖でやった。これは仕方ない。」などと意味不明な供述をしており...

結局bridge以外の方法を思いつかなかったので、Bridgeを作成してIPアドレスを再割り当てするスクリプトを書いて実行したのですが、
実行した3秒後にデフォゲの設定を書くことを忘れていたことに気づき、皆で「あっ!」(一番笑った
あえなく轟沈しました。(でも楽しかった

さいごに

今回も最高に楽しかったです。(小並感

回数を重ねるたびに問題の質と難易度が上がってきている気がしました。
次回も楽しみ!

懇親会ではあまり喋れなかったので次はもっと色んな人と喋れるといいなぁ

他のメンバーの記事

同じサーバ担当だったメンバーの記事

https://blog.acqn.xyz/2016/03/17

トラブルメーカーじゃない方のネットワーク担当だったメンバーの記事

sakurazaka-shin.hateblo.jp

user_sqlを使ってownCloudとRedmineを連携してみた

user_sqlというownCloudのプラギンを使うと、RedmineのアカウントでownCloudにログイン出来るように連携できるらしい
ということで試してみた。

2015/12/12 追記

  • Redmine側でログインIDに大文字が入っていると、user_sqlで連携しているユーザがowncloudでログイン出来ない問題ですが、原因が分かりました。
  • user_sql.phpの137行目、355行目にstrtolower($uid)があるのですが、これのstrtolower($uid)strtolowerを消して$uidだけにするとログイン出来るようになります。
  • ただstrtolowerを外すことによってどんな問題が発生するかはまだ分かりません。
  • とりあえず今のところは問題なく使えています。

2015/08/30 追記

  • この方法でユーザの連携を行うと、一部のユーザがログイン出来ないことがわかった。原因はRedmine側のログインIDに大文字アルファベットが入っているとownCloudにログイン出来ないみたい。
  • ownCloud側でユーザを確認するとログインIDがすべて小文字に変換されていて、その小文字に変換されているIDを使用してもログインすることは出来なかった。
  • 一応Redmine側のログインIDをすべて小文字アルファベットで登録すれば連携に関しては問題ないと思う。 対策を考え中...

パッケージのダウンロードと展開

https://apps.owncloud.com/content/show.php/user_sql?content=155512

ここからuser_sqlをダウンロード

展開してコピー
$ sudo -u http tar fvxz user_sql-388830cefba7.tar.gz -C /usr/share/webapps/owncloud/apps/
$ sudo -u http mv /usr/share/webapps/owncloud/apps/user_sql-388830cefba7 /usr/share/webapps/owncloud/apps/user_sql

/usr/share/webapps/owncloud/appsディレクトリにぶっこむだけ
後はowncloudが勝手に認識してくれるわーい

ownCloudでの設定

左上のプルダウンから「アプリ」を選択
無効のタブの下の方に「SQL user backend」があるので有効に。
なかったらApacheを再起動すると出てくるかも

有効にしたら右上のプルダウンから「管理」
設定項目に「SQL」というのが追加されてるはず。

後は設定項目を入力していく。
分からないところはpsqlでRedmineのテーブルを見てそれっぽいのを選択

Connection settings
SQL Driver : PostgreSQL
Host : localhost
Username : redmine
Database : redmine
Password : my_password
Advanced Settings
Table : users
Username Column : login
Password Column : hashed_password
Real Name Column : firstname
Encryption Type : Redmine

とりあえずこれだけ設定すればRedmineのアカウントでログイン出来た。

注意点

/usr/share/webapps/owncloud/apps にぶっこむディレクトリ名は、user_sql/appinfo/info.xml

<id>user_sql</id>

と同じにしなければownCloud側で認識はするけどアプリを有効にしようとすると No app name specified って怒られる
http://stackoverflow.com/questions/21700112/no-app-name-specified-in-owncloud

ちなみにinfo.xmlファイルの

<name>SQL user backend</name>

がownCloudのappsに表示されるアプリ名

最初これを知らずにuser_sqlが無い無いと探しまわってしまった

参考 公式ドキュメント

yaml_dbを使ってMySQLからPostgreSQLにRedmineを移行した

MySQLからPostgreSQLに移行したのでその時のメモ

移行ツール

yaml_dbを使用する
適当にググっているといくつかのサイトで、本家?のyaml_dbは4.x系のRailsに対応していないという記事がいくつかあったのだが、
https://github.com/yamldb/yaml_db https://rubygems.org/gems/yaml_db
githubとここを見る限り4.x系も対応したみたいなのでそのまま本家のyaml_dbを使うことにする。


Postgresqlに新しいDBを作成

ここを参考に作成
http://www.redmine.org/projects/redmine/wiki/RedmineInstall#PostgreSQL

$ sudo -upostgres psql
psql$ CREATE ROLE redmine LOGIN ENCRYPTED PASSWORD 'my_password' NOINHERIT VALID UNTIL 'infinity';
psql$ CREATE DATABASE redmine WITH ENCODING='UTF8' OWNER=redmine;

config/database.ymlの編集

production:
    adapter: postgresql
    database: redmine
    host: localhost
    username: redmine
    password: "my_password"
    encoding: utf8

こんな感じで変更
これを先にやらずにbundleするとpostgresqlのgemが入らなかった

yaml_dbとgemのインストール&アップデート

yaml_dbをGemfileに追加

/srv/redmine/Gemfile の、gemが並んでいる場所に「gem "yaml_db"」を追加する

$ sudo vim /srv/redmine-3.0.3/Gemfile

それっぽい場所に

gem "yaml_db"

を追加

gemのインストールとアップデート
$ sudo bundle update
$ sudo bundle install --without development test sqlite

前回インストールした時は

$ bundle install --without development test postgresql sqlite

ってやったけど、今回はpostgresqlのアダプタをインストールするためpostgresqlを含めない

データのダンプ

$ cd /srv/redmine-3.0.3
$ sudo RAILS_ENV=production bundle exec rake db:data:dump

これでdb/data.ymlにdata.ymlファイルが作成される

マイグレーションしてデータの書き込み

sudo RAILS_ENV=production bundle exec rake db:migrate
sudo RAILS_ENV=production bundle exec rake db:data:load

後はApacheを起動してちゃんと移行できているか確認して終了。
今のとこちゃんと動いてるので上手く移行できたみたい。

参考サイト

ArchLinuxにownCloudを構築した

ArchLinuxにownCloudを構築したのでメモ

ファイル共有をするのにRedmine上でのファイル共有だと何かと不便なのでownCloudを構築してみた

ownCloudを選択した理由はプラギンでRedmineと連携でユーザ管理が出来るっぽかったので
肝心の連携云々はまだやってないです(そのうちやります&書きます)

ということでRedmineを構築してあるサーバと同じサーバに構築します
一応本番環境鯖なので、作業は一度ローカルのコンテナでシミュレートしてから本番環境を構築しました

環境とか

  • ArchLinux
  • ownCloud 8.1.0-1
  • Apache 2.4.16-1
  • postgresql 9.4.4-2 最近Postgresqlに乗り換えました(Redmineの方もMySQLからPostgresqlにマイグレーションしたい...)

phpの設定

まず、phpのインストール

$ sudo pacman -S php php-apache

mpmの変更。これをしないとphpが上手く動作してくれない。

LoadModule mpm_event_module modules/mod_mpm_event.so #コメントアウト
LoadModule mpm_prefork_module modules/mod_mpm_prefork.so #アンコメント or 追加

以下の2行を追加する

LoadModule php5_module modules/libphp5.so #Loadmoduleリストの最後に追加
Include conf/extra/php5_module.conf #Includeリストの最後に追加

そしてapacheを再起動

$ sudo systemctl restart httpd

owncloudのインストールと設定

owncloudのインストール

$ sudo pacman -S owncloud
phpのエクステンションを入れる
$ sudo pacman -S php-intl php-mcrypt
DB用のパッケージもインストール

今回はPostgresqlを使用するので、php-pgsqlをインストールする。
MySQLの場合は違うパッケージなので注意

$ sudo pacman -S php-pgsql

/etc/php/php.iniの編集

以下をアンコメント

gd.so
iconv.so
xmlrpc.so
zip.so
bz2.so
curl.so
intl.so
mcrypt.so
openssl.so
# 以下DBにpostgresを使用する場合
pdo_pgsql.so
pgsql.so

Apacheにowncloudの設定を記入

owncloudの設定をApacheのextraディレクトリにcp

$ sudo cp /etc/webapps/owncloud/apache.example.conf /etc/httpd/conf/extra/owncloud.conf

httpd.confのファイルの最後に以下の1行を追加

Include conf/extra/owncloud.conf

このままではRedmineと競合してしまうのでownCloudをサブディレクトリで動くように変更しておく。 VirtualHostの部分をコメントアウト

$ sudo vim /etc/httpd/conf/extra/owncloud.conf
#<VirtualHost *:80>
#    ServerAdmin foo@foofarm.com
#    DocumentRoot /usr/share/webapps/owncloud
#    ServerName owncloud.foo.com
#    ErrorLog /var/log/httpd/owncloud.foo.info-error_log
#    CustomLog /var/log/httpd/owncloud.foo.info-access_log common
#</VirtualHost>

また、httpd.confで、mod_dav と mod_dav_fs がLoadされている場合、コメントアウトしておかないとownCloudの実装と衝突する可能性があるらしい。

owncloudディレクトリの所有者の変更

$ sudo chown -R http:http /usr/share/webapps/owncloud/

postgresqlのインストールと設定

postgresqlのインストール
$ sudo pacman -S postgresql
Postgresqlの初期設定

まず、

$ sudo su - postgres

でpostgresユーザにsuして、

postgres$ initdb --locale en_US.UTF-8 -E UTF8 -D '/var/lib/postgres/data'

を実行。postgresqlをstart&enable。

$ sudo systemctl start postgresql.service
$ sudo systemctl enable postgresql.service
/etc/php/php.ini

一応/etc/php/php.iniの確認

# さっきアンコメントした
extension=pdo_pgsql.so
extension=pgsql.so

# 以下のように変更。Archはデフォルトでこの設定になっているはず。
[PostgresSQL]
pgsql.allow_persistent = On
pgsql.auto_reset_persistent = Off
pgsql.max_persistent = -1
pgsql.max_links = -1
pgsql.ignore_notice = 0
pgsql.log_notice = 0
ownCloud用のユーザとDBの作成

postgresqlに接続

$ psql -hlocalhost -Upostgres

以下のSQLを実行

CREATE USER username WITH PASSWORD 'password';
CREATE DATABASE owncloud TEMPLATE template0 ENCODING 'UNICODE';
ALTER DATABASE owncloud OWNER TO username;
GRANT ALL PRIVILEGES ON DATABASE owncloud TO username;
\q

ここで作成するユーザは、ownCloudがDBに接続するために使用するユーザ。
ユーザ名は何でもおk。ユーザ名やデータベース名はこの次にブラウザ上で設定する。

apacheを再起動して接続出来るか確認
$ sudo systemctl restart httpd.service

アクセスしてみる

http(s)://example.org/owncloud/
もしくは
http(s)://example.org/owncloud/index.php

...org/owncloud/ ← ここの「/」をつけないと開けないので注意

セットアップ画面が表示されたらさっき作成したユーザ名とDB名を入力して完了!

ログのtimezoneを変更する

デフォルトだとログに記録される時間がUTCになっている
ので、変更。

/etc/webapps/owncloud/config/config.php

'logtimezone' => 'UTC',
を
'logtimezone' => 'Asia/Tokyo',

に変更

セキュリティ&セットアップ警告

ログインに成功したら、右上のプルダウンから設定を開く。
設定画面の一番上に「セキュリティ&セットアップ警告」という項目があるのでその部分を解決していく。

「/dev/urandom は PHP から読み取ることができず、この状態はセキュリティの観点からおすすめできません。より詳しい情報については、documentation を参照ください。」

英語版のArchWikiのowncloudのページにphp.iniファイルのopen_basedir:/dev/urandomを追加しろと書いてあったので

open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/:/dev/urandom

こんな感じに変更してみたはいいけど警告が消えない。
四苦八苦しているとgithubに似たような警告メッセージが出ている人がいた。

https://github.com/owncloud/core/issues/17465

The addition of /dev/urandom needed to be in php_admin_value open_basedir within the vhost file, and not within /etc/php/php.ini

どうやら/etc/php/php.iniではなく、/etc/httpd/conf/extra/owncloud.confの方に書いてあげなきゃいけなかったみたい

確かに /etc/httpd/conf/extra/owncloud.conf を見てみると

<Directory /usr/share/webapps/owncloud/>
    Options FollowSymlinks
    AllowOverride all
    Require all granted

    # ↓これ
    php_admin_value open_basedir "/srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/owncloud/:/etc/webapps/owncloud"
</Directory>

確かにこっちにもopen_basedirがある
ので、ここを

    php_admin_value open_basedir "/srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/owncloud/:/etc/webapps/owncloud:/dev/urandom"

に変更してapacheを再起動すると警告が消えているはず
/etc/php/php.iniの方には追加しなくてもおk。

「The "Strict-Transport-Security" HTTP header is not configured to least "15768000" seconds. For enhanced security we recommend enabling HSTS as described in our security tips.」

The "Strict-Transport-Security" HTTP header is not configured to least "15768000" seconds. For enhanced security we recommend enabling HSTS as described in our security tips.

って怒られる場合は公式ドキュメントを参考に、

<VirtualHost *:443>
    ServerName cloud.owncloud.com
    Header always add Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
</VirtualHost>

こんな感じで変更。
自分の環境だと、/etc/httpd/conf/extra/httpd-ssl.conf

<VirtualHost _default_:443>
    Header always add Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
</VirtualHost>

というような感じで変更。
もしRedmineとownCloudでVirtualhostを分けるなら

<VirtualHost redmine.mydomain.net:443>
    ...
    Header always add Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
</VirtualHost>
<VirtualHost owncloud.mydomain.net:443>
    ...
    Header always add Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
</VirtualHost>

みたいにすれば行けると思う

このStrict-Transport-Securityは、httpでアクセスしてきたら強制的にhttps通信にするものらしい

Archだとmod_headersがデフォルトでLoadされているけどそれ以外の環境だったらLoadmoduleされているか確認

「メモリキャッシュが設定されていません。パフォーマンスを向上するために、可能であれば memcache を設定してください。 より詳しい情報については、documentation を参照してください。」

そのうち書きます

その他logとかエラーなど

ログの Array 関連

「Array to string conversion at /usr/share/webapps/owncloud/lib/private/template/functions.php#36」

設定画面のログを見ると、

Array to string conversion at /usr/share/webapps/owncloud/lib/private/template/functions.php#36

と表示されていて、ググってたらgithubで見つけた
https://github.com/owncloud/core/issues/17468
https://github.com/owncloud/core/issues/17782

ownCloudの8.1でのバグっぽい?

「array_key_exists() expects parameter 2 to be array, null given at /usr/share/webapps/owncloud/settings/controller/appsettingscontroller.php#192 」

こっちは8.1のバグみたい
https://github.com/owncloud/core/issues/17433
https://github.com/owncloud/core/pull/17606
github上では修正されているみたいだから、Archのパッケージが更新されるまで待つしか無いっぽいかな

ログの is_file()... 関連

こんな感じのエラーが何個か出るかも

is_file(): open_basedir restriction in effect. File(/usr/share/webapps/owncloud/apps/build.xml/appinfo/info.xml) is not within the allowed path(s): (/srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps/owncloud/:/etc/webapps/owncloud:/dev/urandom) at /usr/share/webapps/owncloud/lib/private/app.php#782

https://github.com/owncloud/core/issues/17400
https://github.com/owncloud/core/pull/17472
github見たら修正されていたのでこっちもArchのパッケージが更新されるまで待つ

TODO

そのうちやりますor書きます

  • メモリキャッシュ(memcache)の設定
  • RedmineのPostgresへのマイグレーション
  • ownCloudとRedmineの連携(ユーザ)
  • 現在はSSL証明書的な問題でRedmineのサーバのサブディレクトリ内にownCloudがある状態なので、ワイルドカード署名的なのを取得してvirtualhost、もしくは別サーバで運用したい

参考

php関連
ownCloudの設定
Postgreの設定
Log
トラブル関連