勉強会向けサーバを作ってみる2 / Rasbian jessieを試す/ Google Authenticatorのパスコードを作るKenichiro MATOHARA
![SSH Tips & Tricks](https://cdn-ak-scissors.b.st-hatena.com/image/square/bcef8d729d12aeed2ffdb1a69032456ed4e24b7c/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fsshtipsandtricks-120326073513-phpapp02-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
勉強会向けサーバを作ってみる2 / Rasbian jessieを試す/ Google Authenticatorのパスコードを作るKenichiro MATOHARA
ChefとCapistranoの境界線 (Chef Casual Talks Vol.1) #eytokyo #opschef_ja 大きく分けて二つの話をしました。 Chefを導入する時の「考え方」 Chefのような構成管理ツールは万能でやり方もたくさんある(TMTOWTDI)ので、最初にどういうポリシーで組み立てるかが重要になります。今回「本気で使う」にあたり、以下のようなポリシーを設定しました。 原則サーバ上で作業せず、Chefで環境設定を実装する 公開されたcookbooksを再利用する opscode-cookbooksにあればそれを探す communityやgithubにあるcookbookを使う あきらめの心を持つ 必要ならばopscode-cookbook�sなど既存のcookbookをforkして手を入れる 半日調べて難しそうなことはあきらめる(自前Chef recip
Crucial M500 の write endurance が 75TB しか無いというのが話題になっていて、同じく 75TB である m4 をわざと虐待していたホストはどうなったのか気になって調べて見たところ、面白い結果が観測されたという話。 石橋を叩いて壊し障害時の挙動を見るべく「自社全サービスのアクセスログを受け止める syslog サーバ」という、どう見ても書き込み中心で SSD にやさしくないホストをあえて動かしていた。具体的には下記のようなノリのホストである。 iostat の一行目なので uptime 数百日における平均値であることに注意。 [root@touge ~]# iostat -k -x -d sda | sed -n '3,4p' Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await
d:id:halfrack:20130417:1366193468 を見た同僚が教えてくれた X25-M G2 のホストについて、古い SSD はマージンたっぷりだったという話。 このホストは DB サーバだが、メッセージングサービス的なものに使われているので、更新ヘビーで辛い DB になる。 [root@nantokagoe smartmontools-6.1]# uptime 19:29:02 up 1028 days, 2:49, 2 users, load average: 0.00, 0.05, 0.04 [root@nantokagoe smartmontools-6.1]# iostat -k -x -d sda | sed -n '3,4p' Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await
http://www.songmu.jp/riji/archives/2013/02/2013getoptlong.htmlhttp://d.hatena.ne.jp/tagomoris/20120918/1347991165my $p = Getopt::Long::Parser->new( config => [qw(posix_default no_ignore_case auto_help)] ); $p->getoptions( 'version!' => \$version, );オプションのこまかいところはsongmuさんとtagomorisさんの記事をみてもらうとして、なにがいいたいかというと、Getopt::Long は OO インターフェイスがあるので、OOインターフェイスをつかった方がゆとり教育をうけている世代のみなさんにも理解しやすいとおもいます。
MySQL 5.6.5の新機能GTIDを試してみる 2012-04-23 4月10日にリリースされたMySQL 5.6.5 DMRに、GTID(Global Transaction ID)という機能が搭載された。これは、トランザクションにID(GTID)を持たせることによって、レプリケーションの進行具合を、従来の「マスタのbinlogファイル名 + ポジション」という情報ではなく、GTIDで管理できるようになるという機能である。従来のバージョンと比べた時に一番分かりやすい点としては、「change masterする時にポジションを指定しなくてよくなる」ということだろう。 MySQLのレプリケーション機能開発者Luis Soares氏のブログを参考に、GTIDの機能を試してみた。 MySQL 5.6.5のインストール MySQLのダウンロードサイトからDevelopment Releaseを
日本語ファイル使ったことなかったけど、レガシー改善でsvnからgitへ移行したら日本語ファイル沢山。 Command Line Toolsで入ってるgitは若干古い。 % git version git version 1.7.10.2 (Apple Git-33) 1.7.12から日本語ファイル名(UTF-8-MAC)が扱えるようになってるのでbrewで入れる。 % brew info git git: stable 1.7.12.1, HEAD % brew install git 実験的な機能という位置付けらしいのでデフォルトではオフになってる。オンにする。 % git config --local core.precomposeunicode true マシン全体でオンにしたい場合は下記。 % git config --global core.precomposeunicode t
svn最新だけをclone 職場はsvnで個人的にgitを使うときなど、全部持ってくると死ぬほど時間がかかるので最新のtrunkだけ持ってくる。 % git svn clone -rHEAD https://svn.example.com/unk/trunk unk svnから更新分を持ってくる % git svn rebase svnへ更新分を反映する % git svn dcommit 空ディレクトリの削除をsvnにお伝えする % git svn dcommit --rmdir svnをgitに変換 -sは--stdlayoutでtrunk/, branches/, tags/構成を想定してブランチに変換してくれるそうです。 % git svn clone -s http://foo.com/repos/project ブランチ一覧 % git branch ブランチ作成 % git
普通リモートブランチって、 $ git branch -r origin/master origin/br_1 upstream/master upstream/br_1 こういう風に表示されて欲しいじゃないですか。 "リモート名/ブランチ名"となって欲しいのです。 git svn cloneするときに--prefixを付け忘れたときの対処法 レポジトリが巨大すぎて(数万コミットある)、cloneをやりなおしたくない。 そこで、.gitの中身を直接いじったらうまくいきました。 (ただしこれはドキュメントには書いてない非公式かつ強引なやり方なので、作業するときは十分注意して行ってください) 調査 .git の中に入って、"trunk"という名前のディレクトリ・ファイルを探します。 $ cd .git $ find . -name 'trunk' ./refs/remotes/trunk (
'cpanm -Lextlib' requires Module::CoreList, but Module::CoreList was first released with perl v5.8.9. So we should install Module::CoreList at first. Do as below (be careful with -l and -I (el and ai)): curl -s -L http://cpanmin.us/ | /usr/bin/perl -- - -l/tmp/module-corelist Module::CoreList curl -s -L http://cpanmin.us/ | /usr/bin/perl -I/tmp/module-corelist/lib/perl5 -- - -Lextlib Module::CoreL
寝れないので変な時間にブログを書いたりする。 時折思い立ったように Emacs Lisp を見直して色々導入を試みたりするも、結局割り当てたキーバインドを忘れてたりして定着しない、というものは多い。そんな中でもここ1, 2ヶ月くらいで定着したのが git-gutter.el。 このように緑のプラス記号なんかが出て git で管理しているファイルを編集した場合の差分がどこかが一目でわかる。 多くの elisp がそうなんだけど、導入する前までは便利そうだけどそこまで必要かな? と思いつつ入れてみたらもう手放せなくなった、そういう類です。ぼーっとしながらコード書いてる時でも、あそことあそことあそこを編集したんだなってのが git diff とかしなくても分かる。 これを入れるとちょっと動きがモッサリするみたいな話もあるけど、作者の id:syohex さんが鋭意改善中 (http://d.ha
UkigumoでCI環境を構築します。 今回構築した環境では、 proveでテスト実行 Ikachanでテスト通知 を行うことにしています。 Ukigumo-Serverの設置 gitでcloneしてきます。 $ git clone git://github.com/ukigumo/Ukigumo-Server.gitREADMEに従って依存モジュールをインストールします。 $ curl -L http://cpanmin.us | perl - Carton $ carton installサーバの実行もREADME通りです。 $ carton exec perl -- local/bin/plackup -- port 5555 app.psgi Ikachanの設置 cpanmでインストールします。 $ cpanm App::Ikachan 以下のコマンドでikachanを起動します
StarmanとStarletの違いはいくつかありますが、Starletにいくつか手を加えたあと、速度はどうなっているのか比較してみた。 なお、以下の記事はHello Worldのベンチマークなので、実際のアプリケーションのパフォーマンスにはあまり影響がないと思われます。 各ソフトウェアのバージョンは以下。 Plack-1.0023 Starman-0.3008 Starlet-0.18 Starletのベンチマークとほぼ同じアプリケーションを書いてサーバを起動した use Plack::Builder; use Plack::Request; my $length = 12; my $body = 'x'x$length; builder { enable 'AccessLog', logger => sub { }; sub { my $env = shift; my $req = P
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く