20131215131446
Gitは"ギ"か"ジ"か
GitHub的な何かを使うようにしました。
- 近頃サーバのStruct&Destroyの機会が多い
- 機密を含まぬ形で設定ファイルを一か所で管理して、共通化したい
- 独自の情報を省いて他に設定を置く事で、安全性の向上とテンプレート化が進む
- 都度、自管理の類似のサーバから設定ファイルを持ってくるのに疲れた
- ある程度何処からでもアクセスできる環境に置いておきたい
- 作った設定ファイルを使用するDevOps的なもののレシピ管理もしておきたい
そんな欲求ばかりを挙げてたら、オンラインのリポジトリ管理ツールを本格的に使おうかと思いまして。設定ファイルの差分程度でRCSの代わりにGitを使ってはいましてたがGitHub的なものに置くまでは・・・って感じでした。ので、今回導入に踏み切りました。とりあえず BitBucketに。非公開リポジトリを標準で使えるのは良いですね・・・いや、GitHubの場合非公開リポジトリが有料だからどうこうって話ではありませんが、さっくり使うのに標準でサポートしているのはとても助かります。月々の費用もですが支払情報とか登録と管理するのも億劫でして。
あとは触った感じ操作インターフェイスであったり、ログイン情報をOAuth使用サービスに結びつけたりと便利であったり。あとは個人プロフィールで自アイコンが設定できることかも重要？です。自分はプログラマではないので使い方が変ではあるが、一気に楽になりました。・・・もっと早く動けばよかった。
20131212235709
突然の死
$sudo mount -t davfs https://www.box.net/dav /mnt/davfs /sbin/mount.davfs: Mounting failed. 404 Not Found
Σ (ﾟДﾟ）
追記1: なんとなく機能を確認したところ、文書は無いがFTPサーバ接続サービスがあるらしく接続先がftp.box.netであることを確認。ひょっとしてとdav.box.netでアクセスをしたらベーシック認証画面が出たので行けるかなと思った・・・がエラー(302)。諦めましょう。いつでもデータを退避できる場所って確保してたので、わりと余裕がなくなりました。
追記2: dav.box.net で302転送エラー。ブラウザでアクセスするとこれまでは自コンテンツ直で表示されていたが、変更後は /dav のサブディレクトリ配下へ移動している。試しに "https://dav.box.net/dav" にてアクセスを試みる。成功。あと3年は戦える。
20130826214717
おのれGoogle
先週末にわりと重要なメールを相手に送ろうとしたら、メールサーバがGoogleかこの様なメッセージが届く。
This is the mail system at host mail.uso8000k.net.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
: host xxxxx.google.com[IPv6 Address] said:
550-5.7.1 [IPv6 Address] The sender does not meet basic
ipv6 550-5.7.1 sending guidelines of authentication and rdns resolution of
sending 550-5.7.1 ip. Please review 550 5.7.1
https://support.google.com/mail/answer/81126for more information.
ea8si3107268bkc.295 - gsmtp (in reply to end of DATA command)
どうもGoogleさんのメールサーバは逆引きが出来ないIPv6アドレスについてはお断りを入れるようになったらしい。ワリと突然の変更なので困るところ。逆引きを出来ないアドレスにお断りを入れるのはSPAM等の不正な要求をはじくことが出来るし、IPv4ではわりとよく行う設定であるので、IPv6に対して行うのもの道理ではあるのだが・・・少々乱暴すぎやしないか。せめてTarpittingやGreylist等で猶予が欲しかった。
ということで、色々見て暫くは以下の感じでIPv4へ先祖返り。
$ less /etc/postfix/master.cf
smtp unix - - n - - smtp
-o inet_protocols=ipv4
IPv6のトンネリングであったり、VPSのIPv6サービスであったりは自分で正引きの調整は出来ても、逆引きの調整とかも出来ないので、ちゃんとしていないところはユーザはどうしようもなく蹴られてしまうのですよね・・・ちょっと面倒くさいです。IPv6を使う気もなくなるというものよ(言いがかり)
20130805214646
予想通り動かないSTP
root@localhost:~/pox # ./pox.py samples.spanning_tree POX 0.1.0 (betta) / Copyright 2011-2013 James McCauley, et al. [core ] POX 0.1.0 (betta) is up. [openflow.of_01 ] [00-ab-94-41-63-00 1] connected [openflow.of_01 ] [00-ab-7c-6d-c3-00 2] connected [openflow.of_01 ] [00-ab-8c-38-60-00 3] connected [openflow.discovery ] link detected: 00-ab-7c-6d-c3-00.2 -> 00-ab-8c-38-60-00.3 [openflow.discovery ] link detected: 00-ab-8c-38-60-00.3 -> 00-ab-7c-6d-c3-00.2 [openflow.spanning_tree] 6 ports changed [openflow.discovery ] link detected: 00-ab-94-41-63-00.2 -> 00-ab-7c-6d-c3-00.3 [openflow.spanning_tree] 1 ports changed [openflow.discovery ] link detected: 00-ab-94-41-63-00.3 -> 00-ab-8c-38-60-00.2 [openflow.spanning_tree] 1 ports changed [openflow.discovery ] link detected: 00-ab-7c-6d-c3-00.3 -> 00-ab-94-41-63-00.2 [openflow.spanning_tree] 4 ports changed [openflow.discovery ] link detected: 00-ab-8c-38-60-00.2 -> 00-ab-94-41-63-00.3 [openflow.discovery ] link timeout: 00-ab-94-41-63-00.2 -> 00-ab-7c-6d-c3-00.3 [openflow.spanning_tree] 4 ports changed [openflow.discovery ] link detected: 00-ab-94-41-63-00.2 -> 00-ab-7c-6d-c3-00.3 [openflow.spanning_tree] 4 ports changed // VyattaのインターフェイスをONにして環状に [forwarding.l2_learning] Same port for packet from 00:ab:71:13:2d:00 -> 00:ab:77:e3:4b:00 on 00-ab-8c-38-60-00.1. Drop. [openflow.discovery ] link detected: 00-ab-94-41-63-00.1 -> 00-ab-8c-38-60-00.1 [openflow.spanning_tree] 2 ports changed [openflow.discovery ] link detected: 00-ab-8c-38-60-00.1 -> 00-ab-94-41-63-00.1
VyattaのSTPは802.1Dで動いているわけですが、そのままOVS側で重複検出してポート閉じられてしまった。予想通りというかなんというか、それっぽく動くサンプルですし仕方なし。ただ、それっぽい動作をちゃんと検出できたのでよしとする。
Vyattaの中身
vyatta@vyatta# sh interfaces
bridge br0 {
stp true
}
ethernet eth0 {
bridge-group {
bridge br0
}
hw-id 52:54:00:12:34:56
}
ethernet eth1 {
bridge-group {
bridge br0
}
}
ethernet eth2 {
bridge-group {
bridge br0
}
}
ethernet eth4 {
bridge-group {
bridge br0
}
}
loopback lo {
}
これだけ。ところで8月1日のエントリでSPTと書いてしまっているわけですが、レイズナーの見すぎですね。
20130801004746
POX+SPT
迷走中故、暫くサンプルにて遊ぶ。
root@localhost:~/pox # ./pox.py samples.spanning_tree POX 0.1.0 (betta) / Copyright 2011-2013 James McCauley, et al. // 1. POX 起動 [core ] POX 0.1.0 (betta) is up. // 2. 各OVS の OFC接続確認 [openflow.of_01 ] [00-ab-76-94-69-00 1] connected [openflow.of_01 ] [00-ab-5e-70-a5-00 2] connected [openflow.of_01 ] [00-ab-f1-37-ae-00 3] connected // 3. OVS-1の eth2 を切断の状態で通常のスイッチとして動作 [openflow.discovery ] link detected: 00-ab-f1-37-ae-00.2 -> 00-ab-76-94-69-00.3 [openflow.discovery ] link detected: 00-ab-5e-70-a5-00.2 -> 00-ab-76-94-69-00.2 [openflow.discovery ] link detected: 00-ab-76-94-69-00.2 -> 00-ab-5e-70-a5-00.2 // 4. Spanning Tree が起動 [openflow.spanning_tree] 6 ports changed [openflow.discovery ] link detected: 00-ab-76-94-69-00.3 -> 00-ab-f1-37-ae-00.2 [openflow.spanning_tree] 4 ports changed [openflow.discovery ] link detected: 00-ab-f1-37-ae-00.3 -> 00-ab-5e-70-a5-00.3 // 5. OVS-1の eth2 を接続して環状へ (interfaceを復帰) [openflow.spanning_tree] 2 ports changed [openflow.discovery ] link detected: 00-ab-5e-70-a5-00.3 -> 00-ab-f1-37-ae-00.3 [openflow.spanning_tree] 4 ports changed
しっかり動いている。唯一気になったのはOFCに接続していインターフェイスのMACアドレスが違っていることくらい。インターフェイスをプチプチ切っても端末間の通信はある程度維持。ワリと楽なのだ・・・VyattaでのSpanningTreeとかと組み合わせてみるのも面白い・・・かな。隙があったらやってみようと思う。完璧な実装を期待してはいないけれど実は多ベンダでのSpanningTreeってのもあまりやったことないもので。やってみる価値はありますぜ、と。