Ruby on Railsのルーティングがうまく動かなかったのはどう考えても俺が悪い

サーバメンテナンスの管理ツールとして久々にRailsで組んでみた。

が、前にもハマった気がする点にまたハマる程度には忘れていたので、
忘れないように備忘録エントリを作成する。

けど多分また忘れるんだろうな。。。



コントローラーアクションに単純なCRUDからちょい離れる作業を
GETメソッドでトリガーされるように追加しました。

routesにも書きました。

が、うまく動かずRuntime Errorになります。
各アイテムの状態変化（shanaiok, shanaing）を行なったあと、
一覧に戻るようにredirect_toを指定しているにも関わらず動かない。

routes.rbの内容：

OreApp::Application.routes.draw do
  resources :services

  get 'services/:id/normal' => 'services#normal'
  get 'services/:id/maint' => 'services#maint'

  get 'services/shanaiok' => 'services#shanaiok'
  get 'services/shanaing' => 'services#shanaing'

  root 'services#index'
end

rake routesの結果：

$ rake routes
           Prefix Verb   URI Pattern                    Controller#Action
         services GET    /services(.:format)            services#index
                  POST   /services(.:format)            services#create
      new_service GET    /services/new(.:format)        services#new
     edit_service GET    /services/:id/edit(.:format)   services#edit
          service GET    /services/:id(.:format)        services#show
                  PATCH  /services/:id(.:format)        services#update
                  PUT    /services/:id(.:format)        services#update
                  DELETE /services/:id(.:format)        services#destroy
                  GET    /services/:id/normal(.:format) services#normal
                  GET    /services/:id/maint(.:format)  services#maint
services_shanaiok GET    /services/shanaiok(.:format)   services#shanaiok
services_shanaing GET    /services/shanaing(.:format)   services#shanaing
             root GET    /                              services#index

なんで言うこときかねーんだー！
…と悩むこと30分ほど。

• なぜかredirect_toを指定しているのに#showアクションに渡される。
• :idに"shanaiok"とか渡される。

routesを見比べてからふと気づく。
あ、優先順位じゃん、と。

アクションで渡したいのに"shanaiok"自体が:idに渡されているのは
上の方にあるservices#showが拾っているからですね。
ルーティングは上から解釈され分岐していくものなのです。


修正後のroutes.rb：

OreApp::Application.routes.draw do

  get 'services/shanaiok' => 'services#shanaiok'
  get 'services/shanaing' => 'services#shanaing'

  resources :services
  get 'services/:id/normal' => 'services#normal'
  get 'services/:id/maint' => 'services#maint'

  root 'services#index'
end

rake routesの結果：

$ rake routes
           Prefix Verb   URI Pattern                    Controller#Action
services_shanaiok GET    /services/shanaiok(.:format)   services#shanaiok
services_shanaing GET    /services/shanaing(.:format)   services#shanaing
         services GET    /services(.:format)            services#index
                  POST   /services(.:format)            services#create
      new_service GET    /services/new(.:format)        services#new
     edit_service GET    /services/:id/edit(.:format)   services#edit
          service GET    /services/:id(.:format)        services#show
                  PATCH  /services/:id(.:format)        services#update
                  PUT    /services/:id(.:format)        services#update
                  DELETE /services/:id(.:format)        services#destroy
                  GET    /services/:id/normal(.:format) services#normal
                  GET    /services/:id/maint(.:format)  services#maint
             root GET    /                              services#index

前にも引っかかったことがあり、学習能力がないようです俺。。　orz


そして極めつけには、routes.rbの初期ファイル内コメントに

# The priority is based upon order of creation: first created -> highest priority.
# See how all your routes lay out with "rake routes". 

…って書いてあるわけで、読まずにコメント捨てた俺はもっとダメ。

WindowsServer 2008 のタスクスケジューラで 2147943645 エラーでタスク起動不良

ここんとこ、Windowsサーバと格闘しておりました。

デイリーのバックアップ用のジョブをタスクスケジューラ上で作成して、
テスト実行すると問題なく起動するくせに、いざとなったらエラーが出ている。

タスクスケジューラは、ユーザー "<ユーザ名>" の "\<タスク名>" タスクを開始できませんでした。追加データ エラー値: 2147943645

なんじゃこれー。

…と思ったら、ユーザがログインしていない場合にジョブが実行できないとのこと。

ということで、ジョブのプロパティ内にある

• ユーザがログオンしているかどうかにかかわらず実行する

にチェックを入れればOKというお話でした。


勝手に入れられたタスクジョブの実行回避というセキュリティ上の話からだと思うけど、
ログインしっぱなしというのは逆にセキュリティ的におかしくないすかね。

「タスクの実行時に使うユーザアカウント」情報を保持している割に
ログオン時のみ実行がデフォルトってのもなんだかなぁ、と思うのですが。。。

さらにはコンフィグミスで発生しうる内容なんだからコード返答じゃなくて
ちゃんと発生した事由を喋ってくれよー……と。


75%ほど愚痴でしたｗ

ntpdに気をつけれ、と さくらVPSからメールが来た の巻。

一応JPCERT/CCから1/15にメールが来てて個人的には対策済みなんですが、
念の為のチェック＆啓蒙ということで。

■問題の概要

詳細は下記の情報を見ると良いですが、
ntpdの一部バージョンには状況確認用コマンド（monlist）が用意されていて、
これが外部から呼ばれると、かなりのトラフィックを発生させるので
DDoSに使われるよ、という話。

ふだん利用している さくらインターネット 様からも注意喚起メールが今日届きました。

• JPCERT/CC「ntpd の monlist 機能を使った DDoS 攻撃に関する注意喚起」 
• さくらインターネット「【重要】NTPの脆弱性について」 

■何が問題なのか

monlistの機能的には、対象ntpサーバが最近通信をした相手をリストアップする機能。

試しにmonlistを有効にした状態で以下のようなコマンドを叩いてみる。

# ntpdc -c monlist

remote address          port local address      count m ver rstr avgint  lstint
===============================================================================
ntp-b3.nict.go.jp        123 4x.xxx.xx.xx3          6 4 4    180      1       1
ntp-b2.nict.go.jp        123 4x.xxx.xx.xx3          6 4 4    180      2       2
ntp-a3.nict.go.jp        123 4x.xxx.xx.xx3          6 4 4    180      2       3
ntp-a2.nict.go.jp        123 4x.xxx.xx.xx3          6 4 4    180      2       4

うちのVPSではNICTのNTPサーバを見ているのでリストアップされます。
ntpdのrestrict設定（＋Firewall）で他には通信しないようにしているので、
これ以外はリストされないようになってます。

ここで問題なのは、

• 1コマンド＆小さい通信量で簡単に取り出せる
• 通信履歴がまるまる大公開
• さらにリスト作成時にDNSで名前解決が走る（ntpdc -nなら抑制できるけど）

ということで、増幅率（きっかけコマンドに対して発生する無駄な通信量）が半端ねえ。

ぱないの！
…どころの話じゃないのです。忍ちゃんもびっくり。

■対策方法

ntpdのバージョンアップなんですが、影響を受けないバージョンは「4.2.7p26」。
しかし安定版は4.2.6であり、各distroでもまだ落ちてきてないバージョンかと。

そこで、monlist自体をストップしましょう。
ntpdの設定ファイルに「disable monitor」と1行追記。

※私の環境はDebian Wheezyです。

# vi /etc/ntp.conf
disable monitor　　　　←ファイル末尾にでも追記する

# /etc/init.d/ntp restart

 これで再度monlistを叩いてみると…

# ntpdc -c monlist
***Server reports data not found

問い合わせを無視するようになりました。これでOK。
外から確認したい場合は、 OpenNTPProject.org などを使用するといいかもです。


…というか、単発サーバで自前時刻合わせだったらntpd使わずntpdateを
slewモードを使ってcronで回すのも手です。


久々に奇声が漏れるレベルの増幅率ですので、早急に対処を。

裸族を修理に出したら戻ってきた。

結局のところ、週末までやっても症状再現しなかったとの事。

こうなるともう自宅の電源周りの問題か…

ということで接続の見直しをしてシンプルにしてみた。

また様子見の状態が続いてしまうのがなんとも気持ち悪いのだが、

エラーが出ないなら仕方なし。

次に発生したら有償で部品交換してもらおう。

センチュリーのサポート様、ご対応ありがとうございました。

裸族を修理に出す。

どんなタイトルやねん。

去年の夏に購入して自宅で使用しているRAIDケージが、
今年に入ってから謎な動きをしだしたのが発端。


去年末ぐらいまでは特に問題なかったのが、
タイミングがよく判らないが使用中に勝手にUSB disconnectになってしまう。
ふつーならばUSBの抜き差しで再認識しようものなのだが、
一度disconnectしてしまうとそのまま電源入れ直すまで逝きっぱなしという挙動。

ディスクを全部新しいのにしてもNGで、ケーブルも交換したが治らない。

ので、現在サポートセンターにチェックを依頼している。
 …が、向こうでも数日動かしてても再現しないらしい。

ACの品質の問題？
常時インバータのUPSとか突っ込まないとダメかなー。

一応サポート様には「今週いっぱい様子見てもらう」ということで
お願いをしているが、リプロデュースしない障害は使ってて
気持ちが悪いんだよなぁ。

ケージ側のRAID機能だとログも詳細には出ないので、
もしかしたらRAID機能のない単発複数ドライブとかで
ソフトウェアRAID組んだ方が判りやすいのかもしれん…
…などと悶々としながら待つ日々でございます。


さっさとエラー出てくんないかなｗ

またすこしまがあいたのでうめあわせのえんとりです。

作業プライオリティがえらいことになっとって
年内にZabbixへの移行決着はなさそうです。

てへぺろ(・ω<)


つーかですね、こないだのMSCの社内報告書も書いてない罠…
本年最終営業日は作文でがんばりたい。

てへぺろ(・ω<)



来週はコミケに年末のご挨拶周り（＋買えたら薄い本もｗ）をする週。
昼過ぎにちょろっと出没アド街予定です。

てへぺろ(・ω<)



良いお年をお迎えくださいませorz

Ubuntu ログイン時のMotDを止める

Ubuntuのログイン時に出るMotD（Message of the Day）。
現在のステータスやaptパッケージのアップデート告知が出るようになってる。
便利なんだと思いますが、ちょっと重いのです。

マシンのステータスは別のリソースで監視してるし、
パッケージはapticronとかで監視してるしログインのたびに見てもらっても…という方用。


/etc/motd がその実体なわけだけれども、 /run/motd へのsymlink。
/etc/motdをrmすればとりあえずは出なくなりますが、
motdを作るプロセスは走ってしまうのでリソースの無駄。

探したところ、PAMに居ました。
sshdの認証が通ると pam_motd.so を呼んで、ここで/run/motdを作っている模様。

ので、コメントアウトさせていただきました。

/etc/pam.d/sshd

# Print the message of the day upon successful login.
#session    optional     pam_motd.so # [1]

【追記】
ツッコミいただきましたー。
部分的にカットしたい場合などは、 /etc/update-motd.d の下を見ると幸せになれるかも。
動的に出力する内容がスクリプトとして置いてあります。

パッケージアップデートがあるかどうかだけログイン時に知りたい時は
90-updates-available だけ有効にしておくとか、色々潰し効きますね。