2017年11月24日

3週間ほどGoogle Homeを使ったまとめ 小技編

サードパーティアプリの強制終了は「キャンセル」

サードパーティアプリそのものは玉石混交でまあどんどん変わっていくと思うので詳細には触れない。音声対話をしているときにサードパーティアプリが想定しているコマンドがわからなくなると「すみません、もう一回言ってください」「最後のコマンドを言い替えてください」などのループに簡単に陥って脱出の方法がわからなくなる。そんなときは「キャンセル」と言えば強制終了できる。

https://developers.google.com/actions/assistant/app-exits Actions on Googleのドキュメントを見ていると、英語では以下5コマンドで止められるらしい。僕は日本語で「終了」「終わり」「もういいです」「ストップ」「さようなら」くらいをためしたが全滅だった。困ったら「キャンセル」を覚えておくだけで全然違うとおもう。
  • "exit"
  • "cancel"
  • "stop"
  • "nevermind"
  • "goodbye"

ショートカット作成はアクティビティログを見ながら

Google homeへのコマンド入力は、音声も含めてアクティビティログ  に記録されている。
Google homeアプリの「マイ アクティビティ」のほうが省略されないので見易い。

ショートカットを作成するときは、このマイアクティビティを見ると、どう認識したか、ショートカットをどう展開したか、その反応は何かがわかる。

たとえば「リアを再生」→「Liaを再生」というショートカットを作ってテストをすると以下のようなログが残ってちゃんと期待通り展開されていることがわかる。



3週間ほどGoogle Homeを使ったまとめ ラジオ・podcast編

radiko

まんまradikoです。
http://radiko.jp で自分の地域で聞けるラジオ局を確認して、「ねえGoogle、○○を聞きたい」というとかけてくれます。プレミアム会員じゃないけどアカウント関連の何もないのでプレミアムの機能はたぶん使えない。

  • やりたくてできてないこと1: 特定の時間や番組を予約して再生をはじめさせること。「毎週火曜午前1:00から午前3:00までTBSラジオを聞きたい」とか指定したい。
  • やりたくてできてないこと2: 「あと2時間で終了」みたいにタイマーを設定して再生を終了させること。「2時間後に停止」と言うと「2時間後にリビングを消します」というような若干物騒なメッセージとともにスリープタイマーを設定できる。

まあ言うほど困ってないんですが、コンピュータなら余裕でできるやろというところができていないので惜しい感がある。

「ねえGoogle TBSラジオ」だと通じないのでよく使う局はショートカットを作るといいかな。

ニュースのpodcast

これも普通の「ニュース」コマンド。「ねえGoogle、ニュース」と言うとあらかじめGoogle Homeアプリで指定したPodcastを再生してくれます。任意の音声読みあげとかカスタムURLとかは今のところなさげ。あればいいのに。
Google Play MusicがPodcast対応してるからか海外のPodcastはびっくりするくらい数がありますね。

「Google Homeアプリ」→「その他の設定」→「ニュース」→「ニュース提供元」→「ニュース提供元を追加」で出てくるところで言語をEnglish (United States)にするともう十分やろというくらいどっさりでてきます。

tuneinの再生

あんまり使っていないので謎が多い。そしてあまりうまく使えてもいない。でもISC Stormcast(セキュリティネタで平日に5-6分くらいやってるpodcast)とか聞きたい。
とりあえずわかっていること:
  • 現状、日本語モードで英語タイトルの認識はびっくりするくらいできない。jazz fmは「じゃずえふえむ」ではまったく通じず「じぇーえーぜっとぜっとえふえむ」なら通じる。ショートカット設定して、文字列で「jazzfm」と書けば認識してくれるのでgoogle homeが素直に音声認識してくれる「ねえGoogle、ジャズ」とかのワードで呼びだすようにする。
  • Google homeを英語モードにさえすれば"Play ISC stormcast podcast"であっさり再生できる。なのでリージョンの問題とかではなく日本語音声認識を使っているときのコマンド入力の問題っぽい
  • ショートカットのコマンドで「tuneinでjazzfmを再生」は使えるのに「tuneinでISC stormcastを再生」は失敗する。何が失敗する原因かは不明。
  • ショートカットのコマンドに他の言語は使えない。つまり「セキュリティ」とかで認識させて「play ISC stormcast podcast」を英語で評価してもらうということはできない。その結果、なんとか日本語モードで実行が成功できるコマンドをみつけないといけないという謎のゲームになっている。。
  • 日本のローカルFMのストリーミングを再生させることにまだ一回も成功していない。ひょっとして地域か言語絞られてるのかな??

今のところ「海外のラジオやpodcastをききたかったら英語モードにすればtuneinが普通に使えるよ」というところまでしか知見がない。

3週間ほどGoogle Homeを使ったまとめ 音楽再生編

音楽再生をお金を使わずにやる


各種音楽サービスの課金をめっちゃ勧められるけどお金つかいたくないよね……。

自分でアーカイブをもっていない場合は、Spotifyの無料プランくらいしかないかも。
僕はアーカイブをもっているので以下におちつきました。

Google Play Musicの無料プランを使う
  • Google Homeアプリの表示とかを見ると有料プランの購読が必須のように見えるけど別にそんなことない。(2017年11月時点)単に音楽のプロバイダにGoogle Play Musicを選択するだけ。
  • 無料プランで最大50000曲保存できるロッカー機能があるのでそれを利用して自分のアーカイブを登録(PCでGoogle play musicのページにドラッグ&ドロップするだけ。アップロートにはめっちゃ時間がかかる)

音楽再生関連のコマンド

いろいろ受けつけてくれるけど、以下におちつきました
  • ねえGoogle、BGM → ライブラリからランダム(?)に再生。「ねえGoogle、何か音楽を再生」と同様だけど短いのでこれにしてる
  • ねえGoogle、次 → 再生中に次の曲へスキップ。
  • ねえGoogle、この曲好き → google play musicでThumb upプレイリストに登録。
  • ねえGoogle、シャッフル → 次の曲からシャッフル再生
  • ねえGoogle、お気に入りを再生 → google play musicで"Thumb upプレイリスト"を再生
  • ねえGoogle、<プレイリスト名>を再生 → google play musicで指定したプレイリストを再生
  • ねえGoogle、この曲何? → 再生中の曲のアーティストと曲名を答えてくれる
  • ねえGoogle、停止 → 曲の再生を停止
  • ねえGoogle、再開 → 停止していた曲再生を再開。停止したあと他のchromecastに関連するコマンド(?)をつかっているとだめ
これにおちつくまでちょっとしたトラブルあり。「ねえGoogle、音楽を再生」って言うとKalafinaの「音楽」という曲が再生されるという……。

プレイリストや曲、アーティストの名前にアルファベットが使われていると検索に失敗することがよくある。「Liaを再生」のつもりで「りあを再生」と言っても受けつけず。「える、あい、えーを再生」ならコマンドが通る。そのとき「リアを再生します」と回答してくれてるのでgoogleが頑張れば逆変換もそのうちできるようになりそう。

環境音

Alexaのスキルみてて滝の音とかあったので試したらあったという……。
  • ねえGoogle、環境音 → 「リラックスできる音を再生します」といって波の音や暖炉の音を再生してくれます
  • ねえGoogle、<名前>の音 → 「海の音」「風の音(扇風機の音)」「雷雨の音」「雨の音」川の音」「森の音」「暖炉の音」 で個別指定できる。環境音のほうで再生されるけど名前があたらないものがあるのでもうすこしコマンドありそう。
  • ねえGoogle、ホワイトノイズ → ホワイトノイズを再生。寝るときに良いといわれるピンクノイズはなかった。

ちょっとだけ工夫

Google homeアプリのショートカットを使ってプレイリスト再生 

ラジオ体操をしたいのでこんなことしました
  • ラジオ体操動画をダウンロード
  • mp3に変換してGoogle Play Musicに登録。「ラジオ体操」プレイリストを作って登録
  • 「Google homeアプリ」→「その他の設定」→「ショートカット」でショートカットを追加。「ラジオ体操」で「ラジオ体操を再生」とする。
  • 「ねえGoogle、ラジオ体操」というとラジオ体操ができる(‥)v

2017年8月30日

Ansible 2.3.2のモジュール サポート状況

(2017年9月11日追記)http://docs.ansible.com/ansible/latest/modules_support.html 内のモジュールの分類にNetworkとCertifiedが追加された。あとcoreモジュールの一覧へのリンクも追加された。この記事じゃなくて更新された上記ページをみるといいです。

http://docs.ansible.com/ansible/latest/modules_support.html を見ると、AnsibleのモジュールにはCore, Curated, Community の3種類がある。Coreは core ansible team(= Red Hat内のエンジニア)がサポート、Curatedはパートナーに依頼を投げる(=投げる先がある)、Community は基本的に能動的にサポートされなくてコミュニティ次第。

ということでどれがcoreでどれがcommunityなのかを把握しておくのはサポートをうけるときには大事。

ワンライナーで以下みたいにすると、metadataハッシュの'supported_by' キーにひもづいてサポートの状態が入っているのでモジュールのサポート状況が一覧できる。

$ grep supported_by `rpm -ql ansible|grep py$` |grep core

というわけで適当にパスとか削ってつくったcoreモジュールの一覧が以下。

commands/command
commands/raw
commands/script
commands/shell
files/acl
files/assemble
files/blockinfile
files/copy
files/fetch
files/file
files/find
files/iso_extract
files/lineinfile
files/stat
files/synchronize
files/template
files/unarchive
inventory/add_host
inventory/group_by
network/basics/get_url
network/basics/slurp
network/basics/uri
network/eos/eos_command
network/eos/eos_config
network/eos/eos_eapi
network/eos/eos_facts
network/eos/eos_system
network/ios/ios_command
network/ios/ios_config
network/ios/ios_facts
network/ios/ios_system
network/ios/ios_vrf
network/iosxr/iosxr_command
network/iosxr/iosxr_config
network/iosxr/iosxr_facts
network/iosxr/iosxr_system
network/junos/junos_command
network/junos/junos_config
network/junos/junos_facts
network/junos/junos_netconf
network/junos/junos_rpc
network/junos/junos_user
network/nxos/nxos_system
network/nxos/nxos_command
network/nxos/nxos_config
network/nxos/nxos_user
network/nxos/nxos_nxapi
network/vyos/vyos_config
network/vyos/vyos_facts
packaging/os/apt
packaging/os/apt_key
packaging/os/apt_repository
packaging/os/dnf
packaging/os/package
packaging/os/rhn_channel
packaging/os/rhn_register
packaging/os/rpm_key
packaging/os/yum
packaging/os/yum_repository
source_control/git
source_control/subversion
system/at
system/authorized_key
system/debconf
system/getent
system/group
system/iptables
system/mount
system/ping
system/seboolean
system/selinux
system/service
system/setup
system/sysctl
system/systemd
system/user
utilities/helper/meta
utilities/logic/assert
utilities/logic/async_status
utilities/logic/debug
utilities/logic/fail
utilities/logic/include
utilities/logic/include_role
utilities/logic/include_vars
utilities/logic/pause
utilities/logic/set_fact
utilities/logic/wait_for
utilities/logic/wait_for_connection
windows/win_reboot
windows/win_template
windows/win_acl
windows/win_acl_inheritance
windows/win_regedit
windows/win_command
windows/win_copy
windows/win_disk_image
windows/win_dns_client
windows/win_domain
windows/win_domain_controller
windows/win_owner
windows/win_domain_membership
windows/win_service
windows/win_updates
windows/win_file
windows/win_share
windows/win_shell
windows/win_get_url
windows/win_user
windows/win_group
windows/win_package
windows/win_path
windows/win_ping
windows/win_stat

2017年3月29日

RHEL 5 ELS inclusion listでてた

Red Hat Enterprise Linux 5 ELS Inclusion List https://access.redhat.com/articles/2901071  が公開されてた。
なかなか範囲が狭くて厳しい。あとインターネットに直接晒されるようなプログラムがのきなみ無いように見える(http, bind, sendmail, squid, openssh-server)。厳しい……。

2016年12月8日

RHEL4 ELS終了&RHEL5 ELS開始 想定問答

------------ 基本的なものはナレッジベースにあります:

ナレッジベース「Red Hat Enterprise Linux 延長ライフサイクルサポートアドオン (ELS) と、サポートのライフサイクルは何を示していますか? 」https://access.redhat.com/ja/node/1190613  -- より抜き書き

Red Hat Enterprise Linux 延長ライフサイクルサポートアドオンとは何ですか?

Red Hat Enterprise Linux (RHEL) 延長ライフサイクルサポートアドオン (ELS) は、ライフサイクルの延長を提供するサービスです。これにより、正規のライフサイクルが終了した後も一定期間、Red Hat Enterprise Linux の特定のメジャーバージョンのサポートを継続して受けることができます。Red Hat Enterprise Linux 延長ライフサイクルサポートアドオンは、Red Hat Enterprise Linux 5 では 2020 年 11 月 30 日まで提供されます。

Red Hat Enterprise Linux 延長ライフサイクルサポートアドオンは、どのバージョンで利用できますか?

ELS は、Red Hat Enterprise Linux 4 では 2017 年 3 月 31 日まで、Red Hat Enterprise Linux 5 では サポート終了( 2017 年 3 月 31 日)後から 2020 年 11 月 30 日まで利用できます。

ELS の詳細情報

以下のドキュメントを参照してください。

延長ライフサイクルのサポートアドオンのパッケージ化と販売方法

ELS はオプションのアドオンサブスクリプションで、有料サポートを一度に 1 年間延長できます。ELS は、単年サブスクリプションだけが利用できます。 一度に複数年分を購入することはできません。ELS アドオンサブスクリプションを購入する前に、既存の Red Hat Enterprise Linux サブスクリプションを購入する必要があります。

ELS が有効なリリースをお持ちのお客様に送られるエラータ通知のアーカイブはどこで取得できますか?

RHEL 4: https://rhn.redhat.com/errata/rhel4els-errata.html

RHEL 5: https://rhn.redhat.com/errata/rhel5els-errata.html

将来の通知を選択する方法は?

https://access.redhat.com/site/security/updates/advisory/ で自由に選択できます。

ELS アドオンは、Red Hat KVM、Red Hat Enterprise Virtualization、またはその他の Red Hat でサポートされているハイパーバイザー上で実行している仮想化ゲストに利用できますか?

はい。延長ライフサイクルサポート期間の Red Hat Enterprise Linux はどのバーションも、正規のライフサイクルと ELS に相当する期間中のホストバーションのゲストとしてサポートされます。ゲストに対する ELS アドオンの価格は、インスタンスベースで決められています。

延長ライフサイクルサポートは、延長期間に何を提供しますか?

このサポートをお持ちのお客様は、Red Hat の公式サポートにアクセスし、通常では利用できない、正規のサポート期間後にリリースされた一部の緊急優先度の不具合修正や、重要な影響を与えるセキュリティ修正の配信を利用できます。各メジャーリリースのすべてのパッケージが、上述の重要な修正サポートを受け取れる資格があるわけではありません。 したがって、詳細については、パッケージ除外リストを参照する必要があります。このサービスを購入されないと、以前にリリースされたエラータ、ドキュメント、およびナレッジベースの情報へのアクセスに限定されます。

除外されるパッケージの詳細については、http://www.redhat.com/rhel/server/extended_lifecycle_support/exclusions/ の一覧を参照してください。

RHEL 5については除外リストではなくinclusion listが公開されました https://access.redhat.com/articles/2901071  (※ 2017-03-29追記)

通常、どのようなコンポーネントまたはパッケージがこのサポート提供に含まれませんか?

デスクトップアプリケーション、Extras チャンネルのコンテンツや、Red Hat Directory Server、Red Hat Satellite、または JBoss Enterprise Middleware などの異なるサブスクリプションの対象である製品は、Red Hat Enterprise Linux ELS の対象外になります。Red Hat Enterprise Linux 4 の場合は、Red Hat Cluster Suite と Global File System が対象外となります。Red Hat には、追加パッケージを除外する権利があります。

RHEL バージョンから別の RHEL バージョンに ELS サブスクリプションを移行することはできますか?

はい。ELS サブスクリプションはバージョン固有のものではありません。

Red Hat ライフサイクルポリシーと、このサービスとの関連性については、どのドキュメントを参照できますか?

詳細については、http://www.redhat.com/security/updates/errata を参照してください。

Extended Life Cycle Phase と Extended Life Cycle Support アドオンとの違いは?

Extended Life Cycle Phase (ELP) は、正規のサポート期間が終了した後の期間を指しています。お客様が正規のサポート期間が終了した後も Red Hat Enterprise Linux 製品を引き続き使用する場合にその利点を享受するには、有効なサブスクリプションが必要となります。

サブスクリプションを購入せずに Red Hat Enterprise Linux 3 を実行できますか?

はい。Red Hat Enterprise Agreement の契約内容により、製品がライフサイクルのどの時期であるかに関わらず、Red Hat Enterprise Linux がインストールされ、実行しているすべてのシステムにはサブスクリプションが必要となります。この要件については常にアグリーメントに含まれていましたが、RHEL 3 に関しては表現に一貫性がありませんでした。したがって、Red Hat は、このポリシーから Red Hat Enterprise Linux 3 を除外しました。ただし、Red Hat Enterprise Linux がインストールされ、実行しているすべてのシステムにサブスクリプションの購入を求める要件については、Red Hat Enterprise Linux 4 と以降のすべてのリリースに適用されます。

------------ 以下は私の作文

Q: RHEL5の通常サポートが2017年3月31日に終了することはいつ決まったのかおしえてください

A: RHEL5は2007年に7年間のライフサイクルを定義してリリースされました。その時点では2014年3月31日までの通常サポートが予定されていました。
その後2012年に通常ライフサイクルが7年から10年に延長され2017年3月31日にて通常サポートが終了するように変更されました。
最新のライフサイクルについては以下をご確認ください。

Q: 現在あるRHEL4を2017年3月31日より後もそのまま利用を継続できますか?

A: 利用すること自体は可能です。ただし以下の点にご注意ください。
  • 修正の提供が行われないソフトウェアを利用することはセキュリティ上・運用上の大きな問題となります。ソフトウェアに問題が発見されても一切修正は提供されませんので、何かソフトウェアの修正が必要な問題が発生した場合には多くの場合現実的な対策がありません。
  • ひきつづきサブスクリプションのご購入が必要である点をご注意ください。

Q: ELSを購入せずに現在あるRHEL5を2017年3月31日より後もそのまま利用を継続できますか?

A: 利用すること自体は可能です。ただし以下の点にご注意ください。
  • 修正の提供が行われないソフトウェアを利用することはセキュリティ上・運用上の大きな問題となります。ソフトウェアに問題が発見されても一切修正は提供されませんので、何かソフトウェアの修正が必要な問題が発生した場合には多くの場合現実的な対策がありません。
  • ひきつづきサブスクリプションのご購入が必要である点をご注意ください。

Q: ELSを購入せずに現在あるRHEL5をそのまま利用して2017年3月31日になるとどうなりますか?

A: お客様の手元では特に何もイベントは起きません。新規に修正が提供されないだけで、現在ご利用のシステムをそのまま利用しつづけるすること自体は可能です。

Q: RHEL5のELSを利用するにはどうしたらいいですか?

A: ELSを利用する具体的な手順については、提供前で未確定につき正確な回答ができません。

おおまかな手順については以下のとおりとなります。
1. subscription-manager list --availableコマンドで、利用可能な製品一覧を確認する。ELSが含まれるサブスクリプションのPool IDを確認する。
2. subscription-manager attach --pool=<2で確認したID> としてサブスクリプションとシステムを対応づける。
3. subscription-manager repos で利用可能なリポジトリ一覧を確認する。この中でELSのパッケージを含むリポジトリ名を確認する。
4. subscription-manager repos --enable="3で確認したリポジトリ名"  としてyum リポジトリを有効化する。

ELS提供後に実際に操作する際にはサポートにてご対応可能です。

Q: RHEL5むけELSでサポートされる範囲を教えてください

A: ELSでは特定のアーキテクチャおよびパッケージがサポート範囲から除外されますが、具体的な内容は現時点では未定です。特定のパッケージやアーキテクチャについてELSでのサポート対象としてほしいというご希望があればサポート窓口までおしらせください。

Q: 私はRHEL5.{0〜10}を使っています。RHEL5のELSの対象が5.11だけだと聞きました。5.11にアップデートしない場合には何が起きますか?

A: お客様の手元では特に何もイベントは起きません。RHEL5についてのあらゆる修正は、現在すでにRHEL5.11むけにのみ提供されています。ELSでもその状態が継続します。レッドハットはお客様に最新のマイナーリリースへのアップデートをお勧めいたします。

例としてRHEL5.6で構築されたシステムがあり、2016年9月28日にRHEL5に対して提供された bind の脆弱性への対応 RHSA-2016:1944-1 (https://rhn.redhat.com/errata/RHSA-2016-1944.html) を適用する場合を考えます。
この場合、提供されたパッケージ bind-9.3.6-25.P1.el5_11.9.i386.rpm は、RHEL5.6時点のbindパッケージではなく RHEL5.11までbindパッケージに行われた全ての修正を累積したパッケージを元にして作成されています。

RHELの過去のマイナーリリースに対してのサポートポリシーについては、ナレッジベース「RHEL の特定リリースに関するサポート状況」 https://access.redhat.com/ja/articles/2710221 をご確認ください。

Q: 私はRHEL5.{0〜10}を使っています。どのような場合でも一切マイナーリリースを変更できません。ELSを買って意味がありますか?

お客様のシステムによっては「RHEL5.6提供からRHEL5.7が出るより前の期間に提供されたパッケージしか利用してはいけない。5.7以降で導入された機能拡張や修正は一切導入できない」というような制限があるかもしれません。このような場合にはELSで提供される修正は全て最新のパッケージ(RHEL5.11)を対象としたものですので、ELS add-onをご購入されても提供パッケージという点では特にメリットはございません。
サポート窓口での根本原因調査の可否について、サービス内容の違いが存在します。

Q: RHEL5.{0〜10}を使っています。ELS利用時に5.11へのアップデートによってアプリケーションの動作に影響が出ないよう努力しているという件について文章化されたものはありますか。

A:
ELSに限らずレッドハットではマイナーバージョンアップによって互換性を壊さないことを非常に高い優先度の目標としております。過去のバージョンで動作したアプリケーションが更新により動作しなくなる場合にはリグレッションとよばれるバグとして扱われます。

互換性維持のポリシー文書が以下から辿れます.
少し古いですが以下に上ページの和訳もあります。

マイナーバージョン間で互換性を維持するという内容は以下の部分です。

-----------------------------------------------------------
Compatibility Within A Major Release

One of the core goals of the Red Hat Enterprise Linux family of
products is to provide a stable, consistent runtime environment for
thirdparty applications. To support this goal, Red Hat seeks to
preserve application binary compatibility, configuration file
compatibility, and data file compatibility for all package updates
issued within a major release. For example, a package update from Red
Hat Enterprise Linux 6.1 to Red Hat Enterprise Linux 6.2, or a package
update that fixes an identified security vulnerability, should not
break the functionality of deployed applications as long as they
adhere to standard Application Binary Interfaces (ABIs).
-----------------------------------------------------------

Q: RHEL for SAP HANAには通常型番のELSが利用できますか?

A: RHEL for SAP HANAには RHEL6と7ベースのものしかないので現在のところELSやそのSAP HANA版は存在していません。

Q: RHEL for SAP Applicationsには通常型番のELSが利用できますか?

A: RHEL for SAPにはELSは存在していません。

Q: RHEL for HPC, RHEL WorkstationにELSはありますか?

A: RHEL Server以外にはELSは提供されません

Q: RHEL 4 や RHEL 5 を使っていく上でELS以外に気にするべきことがありますか?

A: はい、あります。現在up2dateやyumで更新をおこなうために利用されているRed Hat Network Classic のサービス終了が2017年7月31日に近づいています。
RHEL4には(Red Hat Satellite 5を購入する以外に)対応できる方法がありません。RHEL5ではRed Hat Subscription Management(RHSM)とよばれる新しい方式で登録しなおすことで、引き続きyumをつかった更新が可能になります。RHSMを利用することができるのはRHEL5.7以降のバージョンです。

RHN ClassicからRHSMへの移行については以下をご確認ください。    


Q: 過去にRHEL4のELSで修正された重大なセキュリティ上の問題の実績をおしえてください

A:

完全な一覧は以下でご確認ください: https://rhn.redhat.com/errata/rhel4els-errata.html

Q: RHEL4やRHEL5からRHEL7への更新方法をおしえてください

A: まず、レッドハットからサポートされるアップグレード方法は存在しません。メジャーバージョン間のin-place upgradeは「RHEL6からRHEL7」という組み合わせで初めてサポートされました。

基本的な方針としては、現行のRHEL4やRHEL5のシステムと同等のシステムを別にRHEL7(または他社製品やサービス)をベースとして作成し、現行のシステムから新しいシステムに移行することをお勧めします。

パートナー各社にて移行支援のサービスなどが提供されています。詳しくはhttps://jp-redhat.com/rhel4-eol/ をご確認ください。

Q: RHEL4やRHEL5からRHEL7の更新差分をおしえてください

A: 各種資料がございます。

Q: Java6(RHバンドルのもの)を利用しているが、ELSの範囲にJavaも入るのでしょうか?

A: OpenJDKのサポート期間は通常のパッケージとことなり個別に設定されています(OpenJDKのみで他のソフトウェアにはこのような例外はないです)
をごらんください。OpenJDK 6 (1.6)のサポートは December 2016 で終了します。

ELSにOpenJDK7はふくまれるかと思われます(制限が明確になっていませんが過去の事例から推定しています)。しかしOpenJDK 6については上記のとおり今年の年末でサポートが終了しますのでELSで新規の修正が提供されることはありません。

Q:「ELS特設ページ(http://jp-redhat.com/rhel4-eol/)」はいつ作成され公表されたのでしょうか?

A: 2016年9月30日に公開いたしました。

2016年12月3日

元号の処理がどこで行われているか探してみる

この記事はLinux Advent Calendar 2016の4日目の記事です。

わりとマイナーな機能ですが、linuxでja_JP.utf8のlocaleで以下のようにコマンドを叩くと、元号をちゃんと処理して表示してくれたりします。
$ LC_TIME=C date +'%EY'
2016
$ LC_TIME=ja_JP.utf8 date +'%EY'
平成28年
ちょっと前に国の象徴のおじいさん(82)が「退位したい」みたいなこと言ってましたし、いいかげん年なのでしんどかろうと思います。法律の要件とかはわかりませんが退位が行われれば元号が変わるでしょうから、庶民の我々も少なくともこのコードを修正しないといけないわけです。 

これはどこからきているのかを探りましょう。
 $ ldd `which date`
    linux-vdso.so.1 (0x00007ffd14593000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fea550ed000)
    /lib64/ld-linux-x86-64.so.2 (0x000056070c37e000)
シンプル。linux kernel, dateコマンドの中身, libcのどれかに絞られました。
kernelはありえないので候補から外します。心配な人はstraceでもして安心してください。
date本体もないと思っているのですが念の為確認します。
$ LC_TIME=ja_JP.utf8 ltrace date +'%EY'
(中略)
strftime(" \345\271\263\346\210\22028\345\271\264", 1024, " %EY", 0x7f8f5c1464a0)                                                   = 12
fwrite("\345\271\263\346\210\22028\345\271\264", 11, 1, 0x7f8f5c142600)                                                             = 1
(以下略)
libcのstrftimeがやっているようです。man 3 strftime を見ます。
(ー略ー)
        %E     Modifier: use alternative format, see below. (SU)
(ー略ー)
(SU) The Single UNIX Specification mentions %Ec, %EC, %Ex, %EX, 
       %Ey,  %EY,  %Od,  %Oe, %OH, %OI, %Om, %OM, %OS, %Ou,
       %OU, %OV, %Ow, %OW, %Oy, where the effect of the O modifier
       is to use alternative  numeric  symbols  (say,  roman numerals),  and 
       that  of  the  E modifier is to use a locale-dependent alternative
       representation.
あ、Single UNIX Specificationで決まってたのか。ってことはきっとAppleのOS Xとかでもつかえるんだろうな。。持ってないので知らないけど。

さて、libcでlocale-dependentだということがわかりました。ソースコードとってきましょう。
$ find glibc-2.24 |grep ja
./localedata/locales/ja_JP
./benchtests/strcoll-inputs/lorem_ipsum#ja_JP.UTF-8
./po/ja.po
./debian/po/ja.po
ということで以下のファイルに含まれてそうです。
glibc-2.24/localedata/locales/ja_JP
いかにもそれらしい「era」というエントリがあります。きっとこれなんですが……

era     "<U002B><U003A><U0032><U003A><U0031><U0039><U0039><U0030><U002F><U0030><U0031><U002F><U0030><U0031><U003A><U002B><U002A><U003A><U5E73><U6210><U003A><U0025><U0045><U0043><U0025><U0045><U0079><U5E74>";/
        "<U002B><U003A><U0031><U003A><U0031><U0039><U0038><U0039><U002F><U0030><U0031><U002F><U0030><U0038><U003A><U0031><U0039><U0038><U0039><U002F><U0031><U0032><U002F><U0033><U0031><U003A><U5E73><U6210><U003A><U0025><U0045><U0043><U5143><U5E74>";/
        "<U002B><U003A><U0032><U003A><U0031><U0039><U0032><U0037><U002F><U0030><U0031><U002F><U0030><U0031><U003A><U0031><U0039><U0038><U0039><U002F><U0030><U0031><U002F><U0030><U0037><U003A><U662D><U548C><U003A><U0025><U0045><U0043><U0025><U0045><U0079><U5E74>";/
        "<U002B><U003A><U0031><U003A><U0031><U0039><U0032><U0036><U002F><U0031><U0032><U002F><U0032><U0035><U003A><U0031><U0039><U0032><U0036><U002F><U0031><U0032><U002F><U0033><U0031><U003A><U662D><U548C><U003A><U0025><U0045><U0043><U5143><U5E74>";/
        "<U002B><U003A><U0032><U003A><U0031><U0039><U0031><U0033><U002F><U0030><U0031><U002F><U0030><U0031><U003A><U0031><U0039><U0032><U0036><U002F><U0031><U0032><U002F><U0032><U0034><U003A><U5927><U6B63><U003A><U0025><U0045><U0043><U0025><U0045><U0079><U5E74>";/
        "<U002B><U003A><U0032><U003A><U0031><U0039><U0031><U0032><U002F><U0030><U0037><U002F><U0033><U0030><U003A><U0031><U0039><U0031><U0032><U002F><U0031><U0032><U002F><U0033><U0031><U003A><U5927><U6B63><U003A><U0025><U0045><U0043><U5143><U5E74>";/
        "<U002B><U003A><U0036><U003A><U0031><U0038><U0037><U0033><U002F><U0030><U0031><U002F><U0030><U0031><U003A><U0031><U0039><U0031><U0032><U002F><U0030><U0037><U002F><U0032><U0039><U003A><U660E><U6CBB><U003A><U0025><U0045><U0043><U0025><U0045><U0079><U5E74>";/
        "<U002B><U003A><U0031><U003A><U0030><U0030><U0030><U0031><U002F><U0030><U0031><U002F><U0030><U0031><U003A><U0031><U0038><U0037><U0032><U002F><U0031><U0032><U002F><U0033><U0031><U003A><U897F><U66A6><U003A><U0025><U0045><U0043><U0025><U0045><U0079><U5E74>";/
        "<U002B><U003A><U0031><U003A><U002D><U0030><U0030><U0030><U0031><U002F><U0031><U0032><U002F><U0033><U0031><U003A><U002D><U002A><U003A><U7D00><U5143><U524D><U003A><U0025><U0045><U0043><U0025><U0045><U0079><U5E74>"

ソースコードのくせに謎エンコードされてて読めないよ! >_<

きっとunicodeの表が頭に全部はいっててデコードできる人は心の目で読めるんですがそんなハンドアセンブルの100倍くらいしんどそうなスキルは持っていません。ちなみにハンドアセンブルも表がないとできません。

しょうがないので<Uxxxx>; みたいなのが来たらxxxx部分にあたるunicode文字に置換する使い捨てスクリプトをシコシコ書きます。

import os, re

def main():
    for line in file('ja_JP'):
        out = ""
        while 1:
            m = re.search('(<U([0-9a-fA-F]+)>;?)', line)
            if m:
                out = out + line[:m.start()] + unichr(int(m.group(2), base=16))
                line = line[m.end():]
            else:
                out = out + line
                break
        print out.encode('utf8'),

main()
 これを実行すると.. でました
era     "+:2:1990/01/01:+*:平成:%EC%Ey年";/
        "+:1:1989/01/08:1989/12/31:平成:%EC元年";/
        "+:2:1927/01/01:1989/01/07:昭和:%EC%Ey年";/
        "+:1:1926/12/25:1926/12/31:昭和:%EC元年";/
        "+:2:1913/01/01:1926/12/24:大正:%EC%Ey年";/
        "+:2:1912/07/30:1912/12/31:大正:%EC元年";/
        "+:6:1873/01/01:1912/07/29:明治:%EC%Ey年";/
        "+:1:0001/01/01:1872/12/31:西暦:%EC%Ey年";/
        "+:1:-0001/12/31:-*:紀元前:%EC%Ey年"
元年だけ別の行になってるんですね…… 明治は6年からなので旧暦のごちゃっとしたあたりは気にしないと。

というわけで元号の場所はわかりました。おじいさんが退位したらここを直してみんなでglibcをアップデートしよう。

ではでは。


追記

「別ファイルになってないの?」と聞かれたので追記 。
たとえば /usr/share/i18n/locales/ja_JP のように別ファイルになっていて、localedefを使うことで独自のlocaleを定義することもできる。
でもlocaleの設定がおこなわれるのはプロセスの最初のほうで setlocale() されるタイミングだから結局元号の処理更新を反映したいプロセスの再起動が必要なのは変わらないのでした……。

3週間ほどGoogle Homeを使ったまとめ 小技編

サードパーティアプリの強制終了は「キャンセル」 サードパーティアプリそのものは玉石混交でまあどんどん変わっていくと思うので詳細には触れない。音声対話をしているときにサードパーティアプリが想定しているコマンドがわからなくなると「すみません、もう一回言ってください」「最後のコマン...