日曜エンジニア

仕事・趣味のメモ置き場です。皆様のお役に立てれば幸いです。

エセインフラエンジニアの焦り(訳 qpstudy 2016.04 響け！アラートコール！ の参加しました)

運用 勉強会

2016.04.23@西新宿ニフティさんで開催された、qpstudyの勉強会に参加しました。

f:id:ls-ltr:20160506110725j:plain

はじめに

勉強会のwarp upの通り、ブログを書くまでが勉強会！ということで、各セッションで感じたことを、私の焦りを書いてみます。覚書みたいになり、読み辛いかと思いますが、よろしくお願いします。
あーこういう残念なエンジニアもいるんだなと知っていただければ幸いです。

エセインフラエンジニアの背景

  • ２０代男性
  • 金融関係SIer
  • リリースしてドキュメント納品しておしまいではなく、保守まで一括して受託している会社で働いています
  • 社内ポジションはインフラ担当(Dev&保守運用)
  • Devでの自担当範囲は、要件定義から詳細設計までと試験から移行。インフラ担当のため、基本ベンダさんの進捗管理がメインとなっているのが実情
  • 保守運用範囲での自担当範囲は、顧客からの照会、定期的な各種リソース状況の評価、障害発生時の切り分け調査
  • 夜勤監視はしてません、夜に起こされる系男子
  • 業務でプログラミングしたことない(必要となればbashやDOSコマンドでbatを少々レベル)
  • 未だにベンダ営業に電話しちゃうタイプの人間
  • 懇親会は残念ながら不参加勢
  • ると (@karoot) | Twitterの人

発表を聴いて

その１「インフラ監視の今後を考える」
speakerdeck.com
その２「Re: 運用に自動化を求めるのは間違っているだろうか」

www.slideshare.net

勉強会の経験が浅い私には、全体的にモヤモヤしているなというのを感じました。(後に控えたグループディスカッションのためでしょうか)
「なぜ監視をするのか？」の問いかけに、「しないといけないから。お客さんの要望でしょ。」と反射的に思いましたが、後々のディスカッションの中で監視するコスト＜障害による損失だから監視をしているという当たり前のことに気づきました。自社内でもランニングコストを安くすませるために、監視をしていないシステム、松竹梅で監視のレベルを業務要件に応じて提案＆実装しているシステムが身近にもありました。(他の人もおっしゃっていましたが、監視レベルの松竹梅の段付は、システム担当のエンジニアやプロマネの経験則に依存していることが多いかもしれません)

運用自動化については、私の携わっている金融システムでも徐々にきています。最近だと、パニックからのOS自動再起動復旧→サービス稼働確認→商用利用開始などは自動化の仕組みを構築しました。(私達の説明が行き届いていないのもあり、お客様システム担当は自動より手堅い実績のある手動でというと流れが残っているのも事実です。）

脱・刺身タンポポ、脱・写経文化という中で、こんな*1
記事を書いてしまう、また要点をサラサラと書けてしまう自分の業務は、世の中から数十年遅れていると痛感しました。

グループディスカッション

・他の班にもちらほらいましたが、金融系って精神的にも物理的にも独自の進化を遂げているなと痛感しました。
・どこかのチームで前提として発表してましたが、話し合う前にお互いの監視対象のシステムの概要、規模だけ意識合わせすればよかったと。
・運用/開発の温度感の問題はどこも陥りがち。
・自動化は手段でしかない。目的の明確化、メリット感をアプローチできる人が社内にエバンジェリスト的存在？が必要

焦り

私が業務でしていることは開発メインだと思ってたけど、半分は世の中的に言う運用に片足を突っ込んでいて、物理的にも精神的にも現在閉ざされた環境だからこそ生きていけるエンジニアなのではと認識しました。
今後、金融業界のfintechによるオープン化、PaaSやdockerなどを活用したDevOpsという新しいアプローチ、インフラの家畜化（リソース仮想化に伴う死んだサービスは放置し新たに作る風潮）により、閉ざされた環境が崩壊。このままだと、私の領域は自動化され、お給料はなくなり死に絶える。私の会社が体制が（笑）とか、金融だから（笑）と飲み会の席で愚痴を言っている場合じゃない。

インフラが変革してきている今、オン/オフで惰性で吸収してきた様々な技術ノウハウを一度見つめ直し、早めに方向性を決めていかないといけない。

総括

拙い文章を最後まで読んでいただき、ありがとうございました。私にとって、社外の利害関係のない方との初グループディスカッションでしたが、上記の様な焦りを感じることができ、とても有意義半日でした。
またどこかでお会いする際・本Blogコメントで、ご指導のほどよろしくお願いします。

NextAction

  • デプロイを実際にしてみる
  • 人間でしかできないことを武器にする(メトリクス、予兆検知)
  • 得意なネットワーク範囲を深くする(SSL/TLS,SMTP,DNS)
  • AWS/Azureの環境構築
  • SlackAPIへ自宅のサーバやAWS/Azureから連携

ご参考

本記事を書く中で拝読させていただきました、素敵な記事の紹介をさせていただきます。中間管理職的なインフラエンジニア？な人、是非読んでみてください、とてもいい刺激になると思います:-))

インフラエンジニア(狭義)は死んだ - YAPC::Asia Tokyo 2014
インフラエンジニアの幸福論 · the world as code
[インフラ] インフラエンジニアの将来は明るいのか：その1 [アプリ] – oshiire*BLOG
[インフラ] インフラエンジニアの将来は明るいのか：その2 [アプリ] – oshiire*BLOG

*1:【新米SEさんへ】商用作業でココを気をつけて - 情緒不安定。

【新米SEさんへ】商用作業でココを気をつけて

Linux DOS Windows SEあるある
医療ミスでなくても、人は○せる。金で人は死ぬ。我々がやっていることはそういうことだ。by 課長
課長が先輩をしばいていた指導していた時のお言葉です
 

本題、私は入社してから4年間、金融関連システムの商用オペレーション*1に従事してました。

最近は指導もしてるのですが、後輩と話す時に、よく言っていることをまとめてみました。1〜2年目の新米SEさん、指導する方の参考に少しでもなれば幸いです。
 
金融ということで厳しいルールが多いので、読者の皆さまにフィットするか不安ですが、、、大は小を兼ねる。規則は後から締めるのは辛い、緩めるのは一瞬。ということで、ご一読いただければ幸いです！

 はじめに

本記事には、再起動やインストールなどを勧めるような記載がありますが、各自職場、商用環境の規則を必ず確認してください。あくまでも商用に挑む時の参考、チェック観点としてご覧ください。
また、他に観点があればコメント等いただければ追記いたしますのでご指摘・コメントお待ちしております。

f:id:ls-ltr:20160411204306j:plain

まずは考え方から！

心構え編

  • トラブルでも商用で自分の慣れてない操作は行わない

どんなに準備してもトラブルは起きます。トラブルが起きたときいつもは細かい上司が、なんでもいいから解決して！と手順外のオペレーションを上司に要求されるかもしれません。そんな時、なるべく知っているコマンドで、解決するようにしましょう。自信がない時は検証環境で試す時間をください。と頼む勇気も必要です。

  • 作業の証拠を残す(手順を作る時は残すことを明記する)

昨今、システム担当者による情報流出なども疑われる時代。自分が実施した内容が妥当であることを保証出来るようにしましょう。また、手順の作成する際、適当な場所にdateコマンド等を入れておくと、証跡から作業所要時間なども後から確認することができます。

  • 悪いニュースほど早く上げる

結果として大丈夫だろうなと思っとも、想定外のコマンド結果やメッセージは、悩んだり調査するよりまず報告。上司へ余計な心配をさせてしまうと思うかもしれませんが、その心配をするのが管理職の仕事、商用の障害の検知が遅れるよりマシです。

  • 作業は手順に従う

大前提ですが、手順に従いましょう。コマンド操作は、コピペの癖をつけましょう、せっかくの手順書も商用作業中の打ち損じでトラブルが起きたら元も子もありません。また、手順書作成の際、操作だけでなく想定結果を画像や標準出力を記載しましょう。

例)ディレクトリ移動手順

# cd /tmp/

# pwd

- pwdコマンドの結果、/tmpとターミナルへ標準出力で表示されること。

  • 手順は必ず検証環境で実施する

商用環境用の手順書を作る時は直接手順書を手打ちするのではなく、検証環境で実施したログからコピーして手順書を作りましょう。(コマンド練習などのお試しは検証環境等々で実施しましょう。）

 

f:id:ls-ltr:20160411205926j:plain

準備が全て！

商用作業前準備編

  • 作業用端末が別のチームにロックされてないか確認

(各自端末を商用環境に都度持ち込んでいる方は除く)既設共用端末を利用する際に、別作業とブッキングしており、端末がユーザロックされていて作業が開始できない。なんてことがないように事前に見に行きましょう。

  • 作業用端末は使い始める前に再起動

サーバルームが近くにない限り、windowsOSの端末を使ってssh、rdp、sftp等々を使って作業対象サーバへ接続を試みるのが一般的なのかなと思います。

もし、再起動をしてないで端末を酷使していると、エクセルやらエクスプローラが固まることも多いです。念のため、できることなら再起動してしまいましょう。

  • 手順書が開けるか確認する

実体験ですが、転送中にファイルが破損することはあります。いざ作業を開始となってエクセルがでファイルを開こうとしたら、”破損しています。開けません。”とか洒落になりません。破損だとエクスプローラで見ても容量は本物と同じだったりするので、面倒ですがエクセルで開いてみましょう。また、エクセルのバージョンが合わず開かないなどありえます。(エクセル以外のファイルでも同様です。)

  • 手順書で必要なそのソフトは商用端末にある？

この端末は〜〜ってソフトないのか！とか、当日作業中に気づくのはやめましょう。(事前確認しましょう。手順を引き継いだけだから、、、と言いたいのなら、依頼元にどの端末でやればいいのかまで指定を要求しましょう。)

  • 諸手続き、ファイル転送時間も考慮する

作業開始直前に、6Gbyte越えのインストーラを手元に用意しても、物理的にもネットワーク的にも遠方にあるサーバには、インストール作業は開始できません。ファイル転送は事前にやりましょう。*2また、商用環境へ入室、入館する時間は考慮し、行動してますか？

  • 個人情報の定義を理解する

採取した情報に個人情報が入ってないと言い切れますか？間違えてインシデント対応でベンダに渡してしまい、後から監査に刺されるとか、場合によっては取り返しがつかない時もあるのでしっかり理解して作業へ臨みましょう。

 

f:id:ls-ltr:20160411210232j:plain

いよいよ本番作業！！

商用作業編

  • GUIよりコマンドで

伝わりにくいので例を挙げると。

  1. スタートメニューを左クリック→左下電源→プルダウンから再起動を選択→実行
  2. ctrl+r→cmd→shutdown /r /t 0
上記は簡単にwindowsの再起動手順を示したものです。この場合、私であれば2.の手順を選びます。理由としては、コピペで作業ができる。作業証拠が簡単に残せる。(ターミナルのログ出力機能を利用)
一番大きいのは、誤操作をした時に致命傷になりにくい。という点です。もし、1.の手順の場合、プルダウンを1つずらしてしまうと、電源断となります。コマンドであれば、手打ちしてしまって打ち損じだとしても、ミスの大半はスペルミスとなり実行エラーとなるため影響はない少ないです。

  • ファイルコピーは中身以外も気をつけて

ファイル権限、タイムスタンプなどOS間で引き継がれない項目orコピー時に変わる項目が存在します。異なるサーバ等で資源を管理したりする場合は圧縮等の回避方法を検討ください。

  • 作業中の決定的な部分はしっかり

理想は手順書に従いコマンドやマウス操作を1コマンド、1クリック単位で確認したいです。が、往々にしてそんなに時間は与えられません。そのため、システム変更コマンドや操作の のタイミングの直前を特に意識してオペレーションしましょう。(システム変更のタイミングを理解するためにも、検証で事前のお試しをオススメします)

最後に

あたりまえですが、リリースした後は運用部門だけで回るように開発上流工程で運用設計するのが一番だと思います！開発部門目指せノータッチ！共に頑張りましょう。
応援中！！↓
#qpstudy 響け！アラートコール！

備考

ご参考にですが、私の環境は以下の通りです。

*1:開発から引継を受けた運用部門のモノホンオペレータさんではないです。緊急デプロイ作業、セキュリティインシデント、ミドルウェアの更新や突発のインシデント調査で開発部隊が商用対応をする事を指しています

*2:転送で使用回線の帯域切迫に留意してください

【追記有(2016.04.22)】Windowsが遂にSymantecG1ルートを捨てるらしい

Windows SSL/TLS 公開鍵証明書

f:id:ls-ltr:20160411204843j:plain
本記事は2016年3月28日23時(JST)時点で調べた情報です。(一部更新してます)
最新情報等については必要に応じ、各業者にお問い合わせください。

【2016.04.22 追記開始】
当初４月１９日に予定していたルート証明書更新プログラムですが、以下の通り延期となったみたいです。中止理由はわかりませんが、延期に関係なくクロスルートを使われている方は停止を引き続き検討すべきだと思います。

本日、マイクロソフト社より、日本時間4月19日または4月20日に予定されていたルート証明書情報の更新を延期する旨の通知を受領いたしました。延期後の実施日時などの詳細は、マイクロソフト社より情報を得られ次第、追加でご案内させていただきます。

Symantecサイトより抜粋
【2016.04.22 追記終了】


実は今年の1月にも同様の*1事象はあったのですが*2、Microsoftが有名なレガシーなルート証明書の利用停止に向けて乗り出した模様です。

今回Symantecが発表したG1ルート証明書は、かなり前のものなのですが、有名な企業サイトでも現在もなお利用しているクロスルート*3証明書のに影響を及ぼすものなので書いてみました。

下記Symantec社のリンクを読めば、より詳細な内容が書いてありますが、噛み砕いた感じで書いてみましたので暇な方はどうぞ。
(本文章には私の知識不足のため、誤解を招く表現があるかと思います、ご指摘のほどお願いいたします。)

knowledge.symantec.com

影響開始日*4

2016年4月19日(火) 米国時間
2016年4月19日(火) または20日(水)日本時間

G1ルート証明書とは

Symantec社の自己署名証明書です。正式な名前は以下の表の通りです。
所謂、ルート証明書として世界中の広いプラットフォームに工場出荷の時点で入っています。
また、G1ルート証明書は鍵長の短さなどのセキュリティ上の理由から、
2015年12月末をもって新しい証明書への署名を中止(retired)していました。
今回のMS社の本対応は、Symantec社のretiredを受けてってのもあるかもですね。

f:id:ls-ltr:20160329002647p:plain
https://www.jp.websecurity.symantec.com/developer/step01.htmlから抜粋

影響内容

上記Symantec社のリンクにある、以下のタイトルのPDFがわかりやすかったです。
[補足資料] 2016年4月(予定)のマイクロソフト社のルート証明書情報更新の影響と対策に関するご案内について.pdf

端的に言うと、WindowsOSに入っているG1ルート証明書のサーバ認証オプションをDisable(ブラウザとサーバ間のSSL通信の認証としては利用させない)にするそうです。
そのため、G1ルート証明書に連鎖(チェイン)するクロスルート証明書がサーバから落ちてきた際に、検証を行おうとしてもサーバ認証ではG1ルート証明書は使えないため、SSL通信(ブラウザのURLでhttps://で始まるもの)が失敗し、エラー画面が出てしまう可能性があります。

影響先

これもPDFがわかりやすいです。
一般的に一番利用されているサーバ認証はブラウザとインターネットを経由したWEBサーバとのhttps通信だと思い込んで、簡単に抜粋してみる。

サーバ側

クロスルート証明書を送出しているか確認してみてください。
個人的に推しているSSLLABSさんを利用させてもらって、G1にチェインしている証明書をクライアント側に送っているかを確認する流れを書いておきます。

https://www.ssllabs.com/index.htmlへアクセス
右上のTestYourSeverを選択
Hostname:欄に調べたいWEBサイトのFQDNを入力し、submit
(2〜3分待つと結果が表示されると思います)
Additional CertificatesにG1に証明されている証明書が落ちてきているかを確認
　こんな風にIssuerって欄に書かれていたらそうです。
　Issuer VeriSign, Inc. / Class 3 Public Primary Certification Authority

クライアント側

SymantecG5ルート証明書が入っていないパソコン。
つまり、レガシーなパソコンです。(WindowsXP以前、WindowsUpdateなどを定期的に行ってないと怪しいです。)

上記のサーバ側とクライアント側と書いた条件に対してANDでヒットしそうだと思った場合、
2016年4月19日を境に、ブラウザで警告が出る可能性がありますので、ユーザは最新のSymantecG5ルート証明書のインストールをお願いします。
また、企業の皆さんは案内の準備をしたほうがいいかもですね。

MS社側告知

現在ではまだないみたいですね。
aka.ms

*1:コメントにてご指摘いただき、類似→同様という表現に変更しました。ありがとうございます。

*2:SMIME署名機能をG1証明書のオプションから OFFにする設定を配布していた。https://knowledge.symantec.com/jp/support/securemail-id-support/index?page=content&id=ALERT1958&actp=LIST&viewlocale=ja_JP

*3:クロスルートとは https://jp.globalsign.com/support/faq/431.html

*4:インターネットを介しての配布なので影響が始まる時間と考えた方が良い。実際は、ユーザ次第。

OracleVMのホストOSと同一ネットワークに繋ぐ設定方法

OracleVM Linux

概要

OralceVM上のゲストOSを、
他物理サーバやPCと同一のセグメントに接続させる方法

手順

  1. 前提

対象ゲストOSのシャットダウンを実施

  1. OracleVM側設定変更

対象OS->設定->ネットワーク->割り当て
ブリッジアダプター
に設定
f:id:ls-ltr:20160319191250p:plain

  1. ゲストOS作業

対象ゲストOS起動
NIC設定*1

参考

ネットワーク設定 | VirtualBox Mania

*1:NIC設定は、各環境のNW設定(DHPC、DG、サブネットマスクetc)に合わせて設定

オープンソース全文検索サーバー Fess を導入してみた

Linux

f:id:ls-ltr:20150628124200p:plain

仕事で将来的に使えるかなと思い導入テストしてみた。
とりあえず、インストールの流れだけ書いておく。

公式サイト
オープンソース全文検索サーバー Fess (フェス) — Fess 9.4 ドキュメント

環境
ゲストOS:CentOS release 6.6 (Final)
ホストOS:CentOS Linux release 7.0.1406 (Core)
VirtualBox:4.3.22

ダウンロード
Fess
http://osdn.jp/projects/fess/releases/

JDK
http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html

手順

# rpm -ivh java-1.7.0-openjdk-devel-1.7.0.45-2.4.3.3.el6.x86_64.rpm
警告: java-1.7.0-openjdk-devel-1.7.0.45-2.4.3.3.el6.x86_64.rpm: ヘッダ V3 RSA/SHA1 Signature, key ID c105b9de: NOKEY
準備中...                ########################################### [100%]
   1:java-1.7.0-openjdk-deve########################################### [100%]
#unzip fess-server-9.X.X.zip
#cd /opt/fess-server-9.X.X/bin
#chmod +x *.sh
#/opt/fess-server-9.X.X/bin/startup.sh

セキュリティとクローラ周りの設定はこれから。
とりあえず、簡単に動いてびっくり。

VirtualBox上のCentOSの容量拡張した

Linux

久しぶりにGNOME経由でログインしたら
f:id:ls-ltr:20150607095841p:plain
どうやら、試しにインストールしたソフトウェアがでかかったみたいで、
/領域を圧迫したらしい。テストサーバでよかった。

ということで、ゲストOSのディスク容量を変更してみました、
滅多にやらないことなので忘れないように書いておきます。

環境は以下の通りです。
[環境]
ゲストOS:CentOS release 6.6 (Final)←拡張するサーバ
ホストOS:CentOS Linux release 7.0.1406 (Core)
VirtualBox:4.3.22

前提確認

f:id:ls-ltr:20150608022241p:plain

  • ゲストOSの電源がOFFになっていること
  • VirtualBoxマネージャを確認し、ゲストOSに割り当てているvdiが可変サイズのストレージになっていること
(ゲストOS)# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root          8.8G  8.6G     0 100% /
tmpfs                 499M   76K  499M   1% /dev/shm
/dev/sda1             477M   29M  424M   7% /boot
  • ゲストOS上の拡張したい論理領域がLVMで構成されていること

仮想ディスク(.vid)サイズの変更

10GB→20GBに変更するため、ホストOSのコンソールでVBoxMageコマンドを実行します。

(ホストOS)# VBoxManage modifyhd [対象仮想ディスク].vdi --resize 20480
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

！！一度拡張すると、縮小はできないので注意！！
以下の通り、仮想的なサイズが変わっていると思います。
※実際のサイズの項目は変わりません。
f:id:ls-ltr:20150608024133p:plain

仮想ディスク拡張用パーティションの作成

Gnome Partition Editorという、Gnome公式パーティションエディタを使ってパーティションサイズを変更します。
GParted -- A free application for graphically managing disk device partitions
(ちなみに、gparted-live-0.18.0-2-i486.isoを使いました。)

  • 1.VirtualBoxマネージャGUIよりゲストOSを選択し、ダウンロードしたisoファイルをマウントする。

(ゲストOS名が違うのは気にしないでください。)
f:id:ls-ltr:20150608213823p:plain

  • 2.ゲストの電源を入れると下記の通り、GPartedの起動選択画面が表示されると思います。

f:id:ls-ltr:20150608214028p:plain
※ゲストOS(ここではCentOS)の起動画面が出てしまった場合、BIOS設定からブートシーケンスを確認してみてください。

  • 3.下記の通りオペレーションすると、GPartedのデスクトップ画面が表示されるはずです。

GParted Live (Default settings)を選択(選択後チェックがかかるため暗転します。)
Dont't touch keymapを選択
15: Japanを選択
キーボードのEnterのみ押す(デフォルトで0が入ります)
以上の通り実施すると、筆者の環境だとこんな画面が出てます。
f:id:ls-ltr:20150608215247p:plain

f:id:ls-ltr:20150608221211p:plain

  • 5.Applyを実施後、以下の通り未割り当て領域がなくなればOKです。一旦OSの電源を落とします。

/dev/sda3が割り当たっているのがわかると思います。
f:id:ls-ltr:20150608223515p:plain

ゲストOS上でのLVM拡張

isoを取り除いてゲストOSを起動してください。
fdiskで見ると割り当てた/dev/sda3がゲストOSからもちゃんと認識されていました。

(ゲストOS)# fdisk -l
~~~~~~~~~~~~~~省略~~~~~~~~~~~~~~~~~~~~~~~~~~~
/dev/sda3            1382        2611     9876480   83  Linux
~~~~~~~~~~~~~~省略~~~~~~~~~~~~~~~~~~~~~~~~~~~

作成したパーティションをゲストOSに認識させます。

(ゲストOS)# pvcreate /dev/sda3 
  Physical volume "/dev/sda3" successfully created

vgdisplayでボリュームグループ名を確認します。

(ゲストOS)# vgdisplay
  --- Volume group ---
  VG Name               VolGroup
~~~~~~~~~~~~~~省略~~~~~~~~~~~~~~~~~~~~~~~~~~~

vgdisplayで確認したボリュームグループに対して、/dev/sda3を追加します。

(ゲストOS)# vgextend VolGroup /dev/sda3
  Volume group "VolGroup" successfully extended

VolGroupに追加した、領域を使えるようにします。

(ゲストOS)# lvextend -l +100%FREE /dev/VolGroup/lv_root
  Size of logical volume VolGroup/lv_root changed from 9.04 GiB (2313 extents) to 18.45 GiB (4724 extents).
  Logical volume lv_root successfully resized
(ゲストOS)# resize2fs /dev/VolGroup/lv_root
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/VolGroup/lv_root is mounted on /; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 2
Performing an on-line resize of /dev/VolGroup/lv_root to 4837376 (4k) blocks.
The filesystem on /dev/VolGroup/lv_root is now 4837376 blocks long.

以上で拡張完了です。dfコマンドで確認してください。

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root
                       19G  8.6G  8.6G  50% /
tmpfs                 499M     0  499M   0% /dev/shm
/dev/sda1             477M   29M  424M   7% /boot

今回参考にさせていただいたサイト

VirtualBox上のCentOSのディスク容量を拡張する #virtualbox #centos - nori3tsu's blog
VitualBoxのディスク拡張 - ぷよログ

cronでハマった

Linux

昨晩、サーバのcron.dにコマンドを仕込んで帰ってたら、翌朝に出社して動いてなくてショック。そんな覚え書き。

# cat /etc/cron.d/ls_chk
0 0-23/6 ＊ ＊ ＊ root /bin/ls />/tmp/`date '+%Y%m%d%H%M'`

うまくできない。。。

# cat /var/log/cron
(root) CMD (/bin/ls>/tmp/`date '+)

あれ？コマンド途中で千切れてる、、、？

cronは、%は誤認識するらしい。
crontabでは'%'をエスケープしなきゃいけない - 駄日記
 
こちらが正解でした。

# cat /etc/cron.d/ls_chk
0 0-23/6 ＊ ＊ ＊ root /bin/ls>/tmp/`date '+\%Y\%m\%d\%H\%M'`

それにしても、dateコマンドの引数ってよく忘れる。精進しないと。

2015/6/4 追記)
上記の正解で記載しているcronにエスケープ処理が入ってませんでした。