2016/06/26

ハッカーズチャンプルー2016 に行ってきた

2016/06/25(Sat) に ハッカーズチャンプルー2016 に行ってきました。

カンファレンスの部懇親会に参加。
なんだかんだ4年連続で参加していますね。時が経つのは早い。


カンファレンスは Go と Perl 成分が多かった感触。
Mackerel や Infrastructure as a Code の話は「おー所謂モダンな開発って感じかねー」とか思いながら聞いてた。
最近 Go の話を良く聞きますね。 okinawa-go とか。
@CodeHex さんの LT では「Go を始めて触ったけれどここがわかんない」という声も。
分からない部分をきちんと共有するのは重要だと思います。
一番印象に残っている発表は負荷分散の話。
DBの水平分散時にサーバを倍々で増やしていくのはいろいろと都合が良さそう。
キャッシュの話も聞きたかった。
実際巨大なキャッシュや分散が必要になる規模はどのくらいなのだろうか。


懇親会は @tompng さんの minecraft で computer を作った話のインパクトが強力でした。
minecraft やったこと無いですけれど、フラクタルを計算して3Dプリントできるらしい。
なにそれ聞いたことある話と違う、といった感じ。
2時間あっという間でご飯食べる暇がほとんどなかったくらいでした。
今までの懇親会で一番人と話した気がします。
あとおもしろTシャツは印象に残りやすいですし話かけやすくて良いですね。
次は何かおもしろTシャツ着ていこうかな。
学生料金は非常にうれしかったです。ありがとうございました。
それもあってかカンファレンスも懇親会もちらほら学生を見た気がする。
場所がKBCだったことも関係あったりするのかな。


来年はどうなりますかねー。
今年も運営の方々お疲れさまでした + ありがとうございました。

2016/05/22

akatsuki 読み会をした

2016/05/15(Sun) に akatsuki 読み会を開催しました。

akatsuki とは私の所属する琉球大学情報工学科で運用しているユーザ用 Web コンソールです。
IP/VMの申請や作成といった学科のシステム運用に必要な様々な機能が入っている Rails Application です。
2015/09 辺りに学科サーバの更新があり、それに伴い学科新システムの一部として開発しました。
学科のユーザ向けの説明会の資料はこちら
特定の人々向けなのでかなり情報を省いています。
なお、この記事を書いている段階ではソースが学科内限定公開になっています。


読み会について

読み会を行なったのは主に後輩への引き継ぎのためです。
akatsuki の機能は学科向けの機能も多く、学科システムを把握しておかないとメンテナンスがつらいかなという懸念もあったので、各機能の実装箇所の概観を把握のために読み会を開催しました。
システム管理するメンバー向け資料はこちら。さらに情報が省かれています。


この記事について

読み会の補足用です。やっぱり特定の人用になっています。
実は akatsuki で使っているノウハウを切り出してこのブログにまとめていて、


勝手にFAQ

  • どうして名前が akatsuki なの?
    • システム管理チームのメンバーのイニシャルをまとめると作れたから。
    • 名付けの時にいた人達の趣味であるという説もある。一人前のレディ的な。
  • デザインは?
    • ちゃんと bootstrap 当ててるじゃないですか。
    • それはさておきデザイン担当の人がいたのでその人が当ててくれるかも。
  • LocalRecord ってなに? Localしか無くない?
    • 元は外向けのDNSも akatsuki で管理しようかという考えもあったので
    • GlobalRecord とか SakuraRecord とか作るつもりだった名残です。
  • さくらクラウドの管理は?
    • fog-sakuracloud とかあるのでその辺でどうにかなるかも

まとめ

ということで特定の人達向けの資料を充実させるための記事でした。

2016/05/04

Agda 2.5.1 でライブラリのパスを設定する

Agda のバージョンを上げたらライブラリのパスの指定方法が変わったらしいので再設定したログ。


環境

  • Mac OSX Yosemite 10.10.5
  • GHC 7.10.3
  • cabal-install 1.22.9.0
  • Agda 2.5.1
  • agda-stdlib 0.12.0 (84ad2bf993e8256e8989f5466c0db0817473b2d6)


設定方法

前までは init.el 辺りで agda2-include-dirs に library の path を list で設定する方法だったのですが、 2.5.1 からは agda2-program-args に入れるか library mamangement を使えとのこと

library management は特定のフォーマットでライブラリのパスや依存が書けるものらしいですが、使ってるライブラリもそんなに無いので agda2-program-args を指定する方法でやってみます。
-iDIR か -lLIB 辺りのフォーマットにして設定しろとのことです。

私は使うライブラリを ~/Library/Agda2 の下に symlink を貼る形にしてるので、 ~/Library/Agda2/* を展開してフルパスにして -i を付けて設定してます。

具体的にはこんな感じ。
(setq agda2-program-args (mapcar (lambda (path) (concat "-i" (expand-file-name path))) (file-expand-wildcards "~/library/Agda2/*")))
ちなみに前まではこんな感じ。
(setq agda2-include-dirs (mapcar (lambda (path) (expand-file-name path)) (file-expand-wildcards "~/Library/Agda2/*")))
(add-to-list 'agda2-include-dirs ".")
設定したら無事動いてめでたしめでたし。


参考

2016/04/30

NFS と intr オプション

CentOS 7 で NFS を mount しているとたまに kernel がハングする時があったのでそのログとか対処法とか。


環境


  • CentOS : 7.1.1503
  • kernel : 3.10.0-327.4.5.el7.x86_64 (だったと思う)
  • nfs-utils : 1.3.0-0.21.el7.x86_64


状況

/var/log/messages を見ると
hogehoge kernel: nfs: server 10.20.30.40 not responding, still tryinghogehoge kernel: nfs: server 10.20.30.40 not responding, timed out
とか出てる。どうやら nfs までのネットワークか nfs 本体が不安定な時があるらしい。

最悪の場合のログがこれ。 ssh すらできなくなる。
INFO: task kworker/u289:1:113889 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/u289:1  D ffff885eff613680     0 113889      2 0x00000080
Workqueue: writeback bdi_writeback_workfn (flush-0:36)
ffff885c819e7c88 0000000000000046 ffff885e59db0000 ffff885c819e7fd8
ffff885c819e7fd8 ffff885c819e7fd8 ffff885e59db0000 ffff885ca53efd90
ffff88607ff66220 0000000000000080 0000000000000000 ffff885e64f15268
Call Trace:
[<ffffffff816098d9>] schedule+0x29/0x70
[<ffffffff811f066a>] inode_sleep_on_writeback+0x9a/0xd0
[<ffffffff81098240>] ? wake_up_bit+0x30/0x30
[<ffffffff811f1aa0>] wb_writeback+0x170/0x2f0
[<ffffffff811f31cb>] bdi_writeback_workfn+0x2cb/0x460
[<ffffffff8108f0cb>] process_one_work+0x17b/0x470
[<ffffffff8108fe9b>] worker_thread+0x11b/0x400
[<ffffffff8108fd80>] ? rescuer_thread+0x400/0x400
[<ffffffff8109727f>] kthread+0xcf/0xe0
[<ffffffff810971b0>] ? kthread_create_on_node+0x140/0x140
[<ffffffff81614358>] ret_from_fork+0x58/0x90
[<ffffffff810971b0>] ? kthread_create_on_node+0x140/0x140
INFO: task scp:114899 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
scp             D ffff885eff533680     0 114899      1 0x00000080
ffff885d75dafb78 0000000000000082 ffff88bce8d14fa0 ffff885d75daffd8
ffff885d75daffd8 ffff885d75daffd8 ffff88bce8d14fa0 ffff885eff533f48
ffff88607ff624e8 0000000000000002 ffffffff811562e0 ffff885d75dafbf0
Call Trace:
[<ffffffff811562e0>] ? wait_on_page_read+0x60/0x60
[<ffffffff81609bdd>] io_schedule+0x9d/0x130
[<ffffffff811562ee>] sleep_on_page+0xe/0x20
[<ffffffff816079b0>] __wait_on_bit+0x60/0x90
[<ffffffff81156076>] wait_on_page_bit+0x86/0xb0
[<ffffffff81098280>] ? autoremove_wake_function+0x40/0x40
[<ffffffff811561b1>] filemap_fdatawait_range+0x111/0x1b0
[<ffffffff81156277>] filemap_fdatawait+0x27/0x30
[<ffffffff811f0568>] __writeback_single_inode+0x1b8/0x220
[<ffffffff811f1467>] writeback_single_inode+0xe7/0x1b0
[<ffffffff811f156e>] sync_inode+0x3e/0x60
[<ffffffffa06ea1bc>] nfs_wb_all+0x5c/0x100 [nfs]
[<ffffffffa06df410>] nfs_setattr+0x1e0/0x1f0 [nfs]
[<ffffffff811e3739>] notify_change+0x279/0x3d0
[<ffffffff811c4b13>] do_truncate+0x73/0xc0
[<ffffffff811c9168>] ? __sb_start_write+0x58/0x110
[<ffffffff811c4ea4>] do_sys_ftruncate.constprop.17+0x114/0x170
[<ffffffff811c4f3e>] SyS_ftruncate+0xe/0x10
[<ffffffff81614409>] system_call_fastpath+0x16/0x1b
/home を nfs の上に置いてるからかもしれないけれど何もできなくなるので、だいたい再起動することになる。
負荷が高い時に発生するのかと思って再現させようとしても耐える時は耐える。
特に私が見てない時に他の人が使って止まってしまったことがほとんどなので、原因も対処方も若干憶測が入ってるのがちょっとつらい。


対処

クライアント側で intr オプション付けると良さそう。 mount コマンドなら
$ mount --verbose -t nfs -o intr 10.20.30.40:/path/to/mount-target /path/to/mount-point
とか。 /etc/fstab だと hard/soft の部分を hard,intr にする。
nfs のマウントには soft と hard の二種類があって、soft は NFS サーバが応答しなくなった時にエラーを返すらしい。
でも帰ってきたエラーをアプリケーション側が上手くハンドルしないとファイル壊れちゃうので hard が推奨。
hard はサーバが応答しなくなっても待ち続ける。soft のようにファイルが壊れることもないらしいし、一時的にサーバが落ちても大丈夫なのでNFSサーバの再起動とかしても問題無い。
けれど待ち続けてる間で kernel task が 120 秒とかを越えると kernel panic しちゃうみたい。
hard を付けた状態で panic するんじゃなくて kernel が task を止められるように intr を付けておくと panic しなくなった。
設定後4ヶ月くらい様子を見ているけれど再現はしていないっぽい。


まとめ

NFS の mount option に hard を指定する場合は intr も一緒に付けておいた方が良さそう。


参考

2015/12/23

FreeRADIUS を使って複数のインターフェースで DHCP サーバを動かす

FreeRADIUS を使って DHCP サーバを提供している時に複数の interface を使って DHCP を提供する必要があったのでその方法とか。

前回の記事にも書いたのですが、FreeRADIUS で DHCPサービスを提供する場合は
/etc/raddb/sites-available にあるサービスを /etc/raddb/sites-enabled にリンクを貼ることで有効化する様子。

ということでまずは /etc/raddb/sites-available にある dhcp をコピーして listen する interface を変更。
そのリンクを /etc/raddb/sites-enabled に貼ると複数のインターフェースにも対応できます。

例えば /etc/raddb/sites-available/dhcp.private と /etc/raddb/sites-available/dhcp.global みたいな感じ。


これで個別の interface ごとに違う設定を適用した複数の DHCP サーバを提供することできます。