2013年8月27日

Androidのメディアストレージによるキャッシュを更新する

Androidに.oggや.mp3ファイルを転送して、そのあと適当に違うフォルダに移動したりすると再生ができなくなる問題にハマったのでメモ。

この問題の原因は、Androidの「メディアストレージ」というプロセスがファイル転送直後にファイルをスキャンして「xxというアーティストの、yyという曲は、ファイルシステムのzzにあるよ」とキャッシュに記録するのですが、この情報がファイル移動時に更新されないために、キャッシュと実際のファイルの位置がずれてしまうことです。

対策としては以下の2パターン:
  • メディアストレージに「キャッシュを更新して!」とお願いする
    • Force Media Scan というこれだけを行うアプリがあるのでインストールしてボタンを押す
  • メディアストレージのキャッシュを消して作り直させる
    • 「設定→アプリ→すべて→メディアストレージ」を探してデータを削除したあと、再起動する

XFSの想定Q&A

RHEL 7のデフォルトファイルシステムがXFSになるので想定FAQを twitterでつぶやいた まとめ
  •  ext3/ext4からフォーマットせずにxfsへ移行できますか?
    • →できません。バックアップのリストアによる移行をおねがいします
  • RHEL7でext3/ext4はつかえますか?
    • →引き続き利用可能です
  • XFSで十分でかいとこまでいけるけどRHS買う必要あるの?
    • →パフォーマンスや冗長性の要件にあわせてお選びください
  • XFSって実績あるの?
    • →はい。RHEL5に対する追加製品、RHEL6のAdd-onとして過去数年販売しており実績がございます。もし何か問題があればサポートにご確認ください。
  • XFSってX font serverとまぎらわしい
    • →そうですね
  • XFSって16EBまでいけるってwikipediaに書いてるよ
    • →サポート上限は実際に検証したサイズなので論理的な上限より小さいです
  • XFSって何の略?
    • →すいませんわかりません
  • XFSって縮小できないけどどうしたらいいの
    • →ストレージかLVMのthin provisioningでご対応ください
  • XFSってスタック食い潰してカーネルごと死ぬんじゃね?
    • →2010年くらいに知られた問題は既に解決していますが、なにかあればサポートまでご連絡ください
  • xfs_repairってメモリ食い潰すんじゃね?
    • →2010年1月の3.1.0で消費メモリ量は縮小したそうですがやはり何かあればサポートまでご連絡ください

2013年8月26日

RHEL5 AP を更新したいが何を買えばよいか?

RHEL5 APを利用していた場合、RHEL Server, High Availability Add-on, Resilient Storage Add-on, Load Balancer Add-on のチャネルが使えるはずです。 この中で必要なものを選択して更新をおこなうことになります。

RHNの情報があまり役に立たない話

RHEL AP 5 をinstallation numberを利用してRHNへ登録した場合、関連するadd-onのチャネル全てを購読するよう設定されます。
一方RHEL AP 5 をinstallation numberを利用*せずに*RHNへ登録した場合、関連するadd-onは設定されず、Serverチャネルのみ設定されます。
そのためRHN上では実際の利用状況ではなく、どのように登録したかということだけがわかる状況です。

実際の利用状況を確認する方法

実際の利用状況から必要有無を判断する必要があります。幸い各add-onは比較的「知らない内に使っていた」ということが起きにくい製品群です。簡単な識別方法について以下に記します。

用途に該当して、関連パッケージを利用していれば add-on が必要です。
  • load balancer add-on
    • 用途: サーバをIPロードバランサとして利用している
    • 関連パッケージ: piranha, ipvsadm
  • resilient storage add-on
    • 用途: クラスタを構築していて、共有ディスクを利用しGFS・CLVMのいずれかを利用している。iSCSIターゲットとして利用している
    • 関連パッケージ: kmod-gfs, lvm2-cluster, scsi-target-utils
  • high availability add-on
    • 用途: フェイルオーバクラスタを構築している
    • 関連パッケージ: rgmanager

RHEL6に含まれるruby 1.8.7はいつまでサポートされますか?

RHEL6に含まれるrubyパッケージは、RHEL6のライフサイクルに従いサポートが提供されます。rpmパッケージであってもRHELに含まれないものや、お客様自身で再ビルドしたもの等はサポート対象外となりますのでご注意ください。

ライフサイクルは期間によってフェーズが分かれ、段階的にサポートレベルが変わります。脆弱性およびバグの修正については運用3フェーズまで提供され、2020年11月30日まで提供されます。

ライフサイクルの詳細については以下のwebページにてご案内しておりますのでご確認ください。
https://access.redhat.com/support/policy/updates/errata/

Red Hat Enterprise Linux 6のEOL日程はいつ公開されましたか?

RHEL6発表当時はライフサイクルの運用フェーズは7年間と定義されておりました。そのためお客様の利用開始時期(2011年末)にはRHEL6の運用フェーズ終了を2017年11月までと宣言しておりました。

その後2012年1月31日にサポートポリシーを変更いたしまして、10年間のライフサイクルとし、運用フェーズの終了は2020年11月としております。

ライフサイクル変更当時のプレスリリースは以下でごらんいただけます。
http://jp.redhat.com/about/news/press-archive/2012/1/red-hat-enterprise-linux-stability-drives-demand-for-more-flexibility-in-long-term-operating-system-deployments

RHEL HA Add-onのハードウェア要件について

HA Add-onを利用する場合、通常のRHELがサポートされている環境だけでなく、それに加えてfence deviceと呼ばれる追加のハードウェアが必要となります。

典型的に利用されるfence deviceは、IPMI規格による電源管理、各ベンダー規格による電源管理(iLO, DRAC, RSA)、外部電源スイッチ(WTC, APC)などです。多くのサーバ向けハードウェアでは対応する機能を内蔵または別売で利用できます。

fence deviceを利用しない構成は、HA Add-onのサポート対象から外れてしまうのでご注意ください。

fence deviceについては、以下のページにてご案内しております。

フェンス設定ガイド フェンシング
https://access.redhat.com/site/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/Fence_Configuration_Guide/ch-fencing.html
Cluster Administration 互換性のあるハードウェア
https://access.redhat.com/site/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/Cluster_Administration/s1-hw-compat-CA.html
ハードウェア種別毎のサポート状況一覧表
http://www.redhat.com/cluster_suite/hardware/

RHELでのセキュリティイベントをログに保管したい

認証についてはPAMに pam_warn モジュールがあり、認証の成功・失敗、認証を要求したプログラム、端末、ユーザ名、接続元の情報をsyslogに出力します。

pam_warnモジュールについては弊社ナレッジベースの以下の記事でご案内しております。
https://access.redhat.com/site/solutions/58736


またSELinuxのポリシーで定義されたイベントは、/var/log/audit/ 以下にログとして記録されます。SElinuxのポリシーで許可されていないアクセスがあった場合にこのログを検出してアラートを出力する機能を提供しております。

以下のドキュメントでこの機能についての概要をご案内しております。
https://access.redhat.com/site/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html-single/Security-Enhanced_Linux/index.html#sect-Security-Enhanced_Linux-Working_with_SELinux-Which_Log_File_is_Used


最後にRHELのセキュリティ関連ドキュメントをご紹介します。

セキュリティガイド
https://access.redhat.com/site/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html-single/Security_Guide/index.html
SELinuxユーザーガイド
https://access.redhat.com/site/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html-single/Security-Enhanced_Linux/index.html
Managing Single Sign-On and Smart Cards(英語)
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Managing_Smart_Cards/index.html

RHELのアップデートをオフラインでおこないたい

RHELサーバをインターネットに接続せず、オフラインでアップデートを行いたい場合、以下のような関連製品が存在します。

完全にオフラインで運用できるものとしては Red Hat Network Satellite を、
プロキシとして動作するものとして Red Hat Network Proxy, Subscription
Asset Manager を提供しております。

Subscription Asset ManagerはRHEL Serverをご購入であれば追加費用なしで利用できますのでご検討ください。

RHELでのブロックデバイスの名前を固定したい

RHELでのブロックデバイスの名前には、複数の種類があります。

よく見る /dev/sda1 などのデバイス名は安定していません。Linuxカーネルがデバイスを検出した順番にa,b,c,d,e... と名付けるため、デバイスの初期化順序がなんらかの理由で異なると、再起動時に異なる名前が付与される可能性があります。


RHEL5.3以降であれば、/dev/disk/by-id/ 以下に、ディスクのIDに由来して生成される永続的な名前のシンボリックリンクが生成されます。このファイル名は再起動により変わることはありません。


ストレージ管理ガイドに詳細が記載されておりますので参照ください。

RHEL6.4はHaswell世代のCPUに対応していますか?

対応しておりません。
RHEL6.5で対応予定です。

2013年8月23日

プログラマ格言(2006)

2006年くらいに書いたプログラマ格言が発掘されたのでおいとく。おおむねダジャレです。

 * PHPを笑うものはPHPに泣く
   * 意味: 「PHPなんてまともなプログラミング言語じゃないよ」と笑っていたら仕事でPHPを触るはめになってしかも既存のソースが汚かったりして泣く。
   * 教訓: 好き嫌いを通せるようにえらくなれ。

 * ソースが知れる
   * 意味: 変な挙動をするソフトをさわっていると、動き方から間違ってるパターンと作った人のレベルがなんとなく透けて見える。
   * 教訓: どうやったらうまく動くか探すのも仕事のうちらしい。

 * ひいきのwiki倒し
   * 意味: 「wikiはすばらしいツールですよ!」 と、とにかくwikiを導入してメンテ不良のページを大量につくってしまう。
   * 教訓: 情報共有ツールは使う人のメンテナンス能力が一番のネック。

 * ライブラリからボタ餅
   * 意味: 延々ぐぐってみつからなかった情報がライブラリのソースであっさりみつかった。
   * 教訓: ライブラリのソースは貴重な情報源。

 * UMLの大木
   * 意味: やたら継承ばっかりしていてすごい大木になっているクラス図を見てげっぷがでる。
   * 教訓: 実装の再利用は依存関係の拡大に注意。

 * 要求仕様と秋の空
   * 意味: 要求仕様は秋の空のようにかわりやすい。
   * 教訓: わかってるつもりの人が一番の危険人物。

 * KnuthもTeXの誤り
   * 意味: あのKnuth大先生ですらTeXで何個かバグを作り込んでしまったように完璧ではない。
   * 教訓: 我々はプログラムにバグを必ず作り込んでしまう。

 * とりつくcoreもない
   * 意味: 反応なくなったから再起動したよ、とか運用してる人に言われたけどログは正常処理しかでてないしcoreはないしどうにもしようがない。
   * 教訓: 何もないとこまるときは、backtrace吐いてくれるようにしとくだけでもだいぶしあわせ。

 * 臭いバグに蓋をする
   * 意味: バグっぽい挙動の原因を追及せずにとりあえずのworkaroundなパッチを書いてごまかす。
   * 教訓: 「発現しなければバグではない」が通用{する|しない}世界もある。

 * IDE屋のvi使い
   * 意味: 客にはIDEを売るけど自分はviでソースを書く。
   * 教訓: 使いやすそうなものと使いやすいものは別

 * コードは一日にして成らず
   * 意味: まともなコードは何年もかけて細かいノウハウや互換性対策などが積み重なっている。読んですぐ書けそうな気がしてもなかなかすぐには同等のものはできない。
   * 教訓: 「既存のコードを全部捨ててやりなおし」はけっこう大変。

 * 大山鳴動して虫が一匹
   * 意味: 大騒ぎになる酷い障害も、原因はくだらないバグ1個だけだったりする。
   * 教訓: 騒がなくていいからまず原因を調査。

 * コピペも山のにぎわい
   * 意味: 行数で単価が決まる案件では長いだけで無意味なコピペコードが良いということになってしまう。
   * 教訓: 行単価という評価基準はヤバスギ。

 * デザパタ読みのデザパタ知らず
   * 意味: GoF本を読んだひとが「デザインパターン使うぜ!」と、設計に無理矢理デザインパターンを盛り込んで変な設計になってしまう。
   * 教訓: 自然な適用をするためにはそれなりの修行が必要。

 * 犬も歩けばバグに当る
   * 意味: あんまり期待せずにウォークスルーをすると意外にバグがどんどんみつかって効率よかったりする。
   * 教訓: 時には無心にコードを読むのもアリ。

 * 一寸のバグにも五分の魂
   * 意味: ちょっとしたバグにもそれを作り込んだプログラマの勘違いや仕様の誤解など、幅広く影響しそうな背景がある。
   * 教訓: 「なんで?」を5回繰り返そう。

 * デバガとハサミは使いよう
   * 意味: デバッガに意外な便利コマンドがあったり、ソースを印刷した紙をハサミで切って並べてみるなど、プログラムを改良する方法にはさまざまなテクニックがある。
   * 教訓: 既に知っている道具もちゃんと調べるといいことがあるかも。

 * 地震,雷,火事,停電
   * 意味: 人間以外にも怖いものはある。
   * 教訓: このへんはマシンをデータセンターに置けばある程度避けられる。しかし人間は…!!

 * バグぶつかるも他生の縁
   * 意味: たまたまバグにぶつかっただけといっても、何かの縁なのだからバグレポートをしてあげよう。
   * 教訓: バグからはじまる恋もある(ねーよ

 * docを食らわばソースまで
   * 意味: ドキュメントを調べだしたらついでとばかりにソースまでよんでしまう。しかも本題と関係ないコードが理解できなくてなやんだりする。
   * 教訓: まずはFAQよんどこう。

 * ソースに入ってはソースに従え
   * 意味: 人のソースを変更するときはその人のコーディングスタイルに従って変更しよう。
   * 教訓: コーディングスタイルへの過度のこだわりはよくない。

 * 馬子にもGUI
   * 意味: つまんないプログラムでもGUIをつけるとそれっぽくみえるらしい。
   * 教訓: それっぽいだけかも。

 * 溺れるものは2chをも捕む
   * 意味: ハマってどうにもならないとき、2chの質問スレに頼る。
   * 教訓: とりあえず情報の裏はとっとけ。

 * 虎穴に入らずんばバグを得ず
   * 意味: (よくわからなくて怖い)フレームワークやlibcやカーネルの中まで読みこまないとバグを完全につきとめることはできないこともある。
   * 教訓: ソースさえ読めばそれなりにわかったりする。きにせずよんじゃえ。

 * 書いたコードに手をかまれる
   * 意味: ライブラリがおかしいのかとおもって延々調べても悪くなさそう。サンプルコードはちゃんと動く。まさかと思ってよくよく見ると自分が書いて大丈夫だと思ってたコードが間違えていた。
   * 教訓: それがバグ。

 * LL三年Web八年
   * 意味: どんなにLLを覚えても結局はWeb技術そのものに明るくなるために何年もかかってしまうということ。
   * 教訓: Webとブラウザ周辺は魔窟。

 * 能あるプログラマは爪を隠す
   * 意味: 有能なプログラマは、ほとんど「凄い」コードを書かないものである。
   * 教訓: 平易なコードの作者を甘く見るな。

 * 芸は身をHaskell
   * 意味: Haskell みたいなマイナー言語を使えるとかえって職にあぶれない。
   * 教訓: いろいろなプログラミング言語さわるとよい。

 * 多言語は無言語
   * 意味: いろんな言語にとりあえず手をだしてどれも中途半端にしかできないこと。
   * 教訓: 言語の深いところはあまりかわらないので、一つを極めてから他に手をだすとよい。

 * 案ずるより書くが易し
   * 意味: どの実装方針がいいかなあ、と迷うより書いてしまうほうが簡単。
   * 教訓: 迷ったら全部実装して比較。

 * 悪設計は百年の不作
   * 意味: 悪い設計を許してしまうとあらゆる場面で無駄な苦労をしてしまう。
   * 教訓: 設計は経験と能力の両方がある人にお願いしよう。

 * abで鯛を釣る
   * 意味: 「ab(apache bench)で性能測定」のような仕事のほうが意外に金をとれたりする。
   * 教訓: 自分的にたいしたことないスキルでも相手にとって価値があれば金になる。

 * makeるが勝ち
   * 意味: make一発でいろいろできるように自動化するとかなり便利
   * 教訓: 客の仕事だけでなく自分の仕事も自動化しよう

 * 転ばぬ先のテストケース
   * 意味: 先にテストを書いておけば防げるバグは多い。
   * 教訓: サボらずテストケースを書こう。