mrwk update

2019年7月17日

blog移転してます

なにかの誤検出でブログをまるっと消されたり、申請して回復したと思ったらまた消されたりしてうんざりしてしまったのでbloggerの利用をやめてはてなブログに移転することにしました。

移転先はこちら → https://mrwk.hateblo.jp/

2018年11月7日

Fedora Modularity雑感

Fedora 29でデフォルトmodularityが入ってきたのでちょっと触った感触をメモ。30分くらいしかいじってないので間違いがあったら教えてください。

dnf module list でモジュール一覧がでてくる

# dnf module list
firmware for qemu, built by jenkins, fresh from git repos                                             2.4 kB/s | 2.9 kB     00:01    
Fedora Modular 29 - x86_64
Name             Stream         Profiles                                   Summary                                                    
ant              1.10           default [d]                                Java build tool                                            
avocado          latest         minimal, default                           Framework with tools and libraries for Automated Testing   
avocado          stable         minimal, default                           Framework with tools and libraries for Automated Testing   
container-tools  2017.0         default                                    Common tools and dependencies for container runtimes       
container-tools  2018.0         default                                    Common tools and dependencies for container runtimes       
cri-o            1.11           default                                    Kubernetes Container Runtime Interface for OCI-based contai
                                                                           ners
cri-o            2017.0         default                                    Kubernetes Container Runtime Interface for OCI-based contai
                                                                           ners
cri-o            2018.0         default                                    Kubernetes Container Runtime Interface for OCI-based contai
                                                                           ners
django           1.6            python2_development, default [d]           A high-level Python Web framework                          
docker           2017.0         default                                    Module for docker runtime and docker-distribution          
dwm              6.0            user, default [d]                          Dynamic window manager for X                               
dwm              6.1 [d]        user, default [d]                          Dynamic window manager for X                               
dwm              latest         user, default [d]                          Dynamic window manager for X

moduleは実際上小さなリポジトリ。ただしmoduleを有効にしないとパッケージを取得できない。
dnf module enable dwm:6.0 のようにmodule を有効にする

リポジトリからmoduleへweak referenceが貼られて、インストール時の解決に使われるようになるイメージ

dnf module disable をしてもweak refがかわるだけで今はいっているパッケージに影響はない
dnf module enable をしてもweak refがかわるだけで今はいっているパッケージと競合するとしても特に警告などはない
dnf module remove をすると指定したmoduleに属するパッケージを削除できる。
moduleのenable/disableがrpmパッケージ群の状態と独立しているので……

moduleを切り替えながらいろいろやるとバージョンが混在して依存関係解決がむずかしい

rpmの別バージョンを同時にはインストールできない制約は有効なので致命的に壊れることはない
実用上はmoduleのバージョン切り替えをしたい場合はremoveするしかなさそう。

良い点: 今のRHSCLよりはまともな仕組みなのでhackyなshell scriptsが排除される。

悪い点: 同時にインストールできないからSoftware Collectionsより能力としては劣化してる。modularityの人はそういうときはコンテナ使えばいいと言っている。

予想されるまずいケース: rpmfindなりISV提供なりでmodularityを考慮していないrpm入れる→しばらくしたあとmoduleを使おうとする→moduleと競合する→わけがわからなくなる

2018年6月22日

/proc/1/io を見るとsystemdがすごくI/Oしてそうに見える件メモ

/proc/1/io を見ると systemdがI/O大量にやっている(ように見える)のが腑におちなくてちょっとしらべました。

task_io_accounting_add という関数があってioの集計情報を足すのですが
その関数がexit時によばれて子プロセスのio統計が親プロセスに加算されるようです。

linux-3.10.0-862.fc24.x86_64/kernel/exit.c
内で、
release_task → __exit_signal → task_io_accounting_add という順に呼ばれています。

動作を確認するため簡単に実験しました。bashからddを実行するとそのあとにwrite_bytesが100MiBくらい増えて統計情報だけみるとbashがI/Oしたかのようにみえるのがわかります。

snake:~$ cat /proc/$$/io
rchar: 4569105
wchar: 4335
syscr: 2875
syscw: 60
read_bytes: 0
write_bytes: 4096
cancelled_write_bytes: 0

snake:~$ dd if=/dev/zero of=/var/tmp/foo bs=1MiB count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0.0308119 s, 3.4 GB/s

snake:~$ cat /proc/$$/io
rchar: 109501412
wchar: 104862679
syscr: 3095
syscw: 249
read_bytes: 8192
write_bytes: 104861696
cancelled_write_bytes: 0

Red Hat Identity Management or FreeIPA 利用前にチェックするべき項目

クライアントについて:

OSは何で何台か?
- クライアント側がサポートされるのはRHELの場合のみ

SSSDが利用できるOS

→ SSSDのバージョンにより利用できる機能がかわるので要確認

SSSDが利用できないOS

→ LDAP、Kerberosで接続できるがあまりスケールしないので要注意

サーバについて:

必要サーバ数について
- 最低2システムは必要
  - IdMが壊れると全システムに影響するため可用性対策として必要
  - ネットワーク的にとても近い場合をのぞけば 2 × データセンタ数あるとよい
  - マルチマスタレプリケーションによるActive-Active構成が基本
- 1サーバあたり目安としてはクライアント2000〜3000台程度
- サポート上限は60台

サーバ構成について
- 物理サーバ・仮想サーバのどちらでもよい
- メモリ量の目安
  - For 10,000 users and 100 groups: at least 3 GB of RAM and 1 GB swap space
  - For 100,000 users and 50,000 groups: at least 16 GB of RAM and 4 GB of swap space
- IPv6を有効にすることが必須
- サーバはFQDN必須
- サーバはDNSの正引き逆引きが可能であること
- RHEL 7の最新での構築を推奨
- SELinuxをenforcingで利用することを推奨
- ※ コンテナ対応は現在のところtechnology preview

利用したい機能を決める:

DNS
- IdM内蔵のDNSを利用するか、外部のDNSを利用するか
- 内蔵DNSを使う場合、root zoneをもたせるかどうか
- クライアントからIdMの自動検出・自動冗長化、ドメイン参加による自動登録が可能

OTP
- IdM内蔵のHOTP/TOTPか、サードパーティOTPソリューションをRADIUSで統合か

スマートカード認証
- ドキュメントに動作確認済みスマートカード一覧があるので確認する

パスワードポリシー設定

DNS
- 自動ディスカバリ、負荷分散に必要
- 利用を推奨

CA局
- サービスとユーザ用
- 外部CA局から発行された証明書を利用するか?
- CA局は必ず2つ以上作成する

SSH公開鍵配布
- ホストのfinterprintをDNSで配るかLDAPで配るか決める

sudoer配布
- SSSDによるキャッシュが必須(RHEL 7.0+, 6.6+)

NFS automount mapping

HBAC

Active Directory とのCross realm trustによるWindowsからのSSO
- ADとIdMは別のドメインである必要がある

Webアプリケーションの認証統合
- 同一ドメインのみ
- 別ドメインの場合はRed Hat SSOなどを利用したOpenID ConnectやSAMLでの接続を検討する

NG:

ロードバランサによる負荷分散はしない(サポート対象外)
- 通常はDNSで行うので不要。DNS利用できない場合はクライアント側SSSDにサーバを列挙

1台だけで構築しない

ADや既存の他Kerberosと同じドメインにしない

一部のパッケージだけを更新しない。更新するときは全てを更新する。

2018年6月13日

深夜systemd雑談

深夜に某IRCでsystemdの話してたのをちょっと編集したログ

コマンドオプション順序

ar*******> sudo systemctl hogehoge start にしてほしかった
moriwaka> sudo service hogehoge start とすればいいんじゃないかな
moriwaka> LSBにserviceがある限りたぶん永遠に残るよ
ar*******> なるほど
ar*******> service 使えばいいのはわかるんだけど、systemctl が service と記述順を違えたのはなんでかしら
ca***> command subcommand ... という書式で統一したかったとか?
moriwaka> command subcommand object にしたかったんでしょうなあ
moriwaka> shellの補完と相性よさそうだし
ar*******> stop して start してとかやるときの編集がめんどい
pl*****> コマンド順はあんまり気にならないんだけど、
pl*****> systemctl start hogehoge してから systemctl status hogehogeするのがたまにダルイ
ar*******> それ
moriwaka> わかる
ar*******> history 編集するときカーソル移動だるい
moriwaka> 僕もctrl-w で1 word消すのが癖になってるから今でも編集ミスるわ
pl*****> unit自分で書いてると頻繁にそれやるからつかれる
ar*******> カーソル移動の時間が積もり積もって過重労働に
moriwaka> Alt-Bとか使えばいいんだけど手癖がなあ……

Restartの契機

pl*****> 最近はまったのはRestart=(OnFailure=だったかな？)がType=simpleじゃないと機能しないこと
pl*****> simpleだと機能してoneshotだとダメなんだったっけ
pl*****> 忘れっちった
pl*****> コマンドをサービス化してるのでなるべくoneshot使ってるんだけど、typeによって使えない機能があったりするのは知らなかった・・・
moriwaka> oneshotだとprocessがexitするの想定された動作だから
moriwaka> processがexitしててもserviceとしてはactiveでrestart動かないのはまあそうかなという気持ち
pl*****> うむー
pl*****> 確かにそう言われるとそういうもんか

Conditionほげほげが好き

moriwaka> Conditionalなんとかが割と好きで、どの条件で失敗したかstatusで見えると「おお…… 進歩してる……」って感じになる
pl*****> conditionalって何？
moriwaka> Conditionなんとかか。ConditionPathExists= とか
pl*****> ConditionPathExistsとかか
pl*****> あれ便利なので多様してる〜

バイナリログつらい

ts******> systemdのユニットファイルなどは使いやすいけど、何故バイナリログにしてやがったのか・・・
pl*****> 並列起動だから出力されるログの順序が決定的じゃないってのもたまに騙される
ts******> "SYSTEMD_PAGER="を設定すると使い勝手が良くなる＞systemd

WantedBy=multi-user.targetの動き

pl*****> 未だにちょっと理解できてないのが、
pl*****> WantedBy=multi-user.targetしてるユニットは、
pl*****> Reached target Multi-User System.ってログに出てたらキックされてるってことでいいのかな
pl*****> Reached target Multi-User System.って出た後にwants/wantedbyしてるユニットが起動されるのかな
moriwaka> それ[install]セクションにかくので
moriwaka> enableするとmulti-user.targetのWantsに追加される
moriwaka> Wantsなだけなので、前後関係は決まらない
moriwaka> systemdの「起動したいリスト」にはのってるはず
pl*****> あーーーっていうことは
pl*****> Reached target Multi-User System.って出てるから、サービスがキックされてるって保証はないのか・・・
pl*****> systemdは何をもってReached target 〜を出力してるんだろ・・・
moriwaka> そのtargetをactivateしたらじゃないの。
moriwaka> Before=multi-user.target とか書けばいいのでは(targetについた時点で起動がはじまってると保証してほしいときは
pl*****> だとするとbefore=multi-user.target必要になるのか・・・
pl*****> ふむ
pl*****> ぁーそーかーかなり勘違いしてたなぁ
moriwaka> わりとそのへんごちゃっとするよね……
pl*****> wants/requireは順序関係ないから、WantedBy=Xしてても「Reached target Xって出てるからサービスはキックされてるはず」とは鳴らないのか・・・
moriwaka> はい
pl*****> ぐへぇ。勉強になりました・・・
moriwaka> 「必要なんだから先に起動してるじゃろ」と思うのはすごくよくあると思うのでみんなハマるところだとおもう
pl*****> むずかしー
pl*****> ぜひmastering systemdを書いてほしい・・・
moriwaka> 本はしらないんだけどpacktとかにないのかな

Conflicts=shutdown.target

pl*****> あと、Conflicts=shutdown.targetって何の意味があるんだろう
moriwaka> shutdownコマンドとかでshutdown.target を呼びにいくときには俺を終了してくれよなという意味では>conflicts
pl*****> ぁーーーそうか。終了するときに shutdown.targetに遷移するから、その時に殺してくれるのか・・・
pl*****> conflicts=にサービスが設定されてると、このサービスはあのサービスと競合するんだなって分かるけど、
pl*****> shutdown.targetと競合する？どういうことだ？ってなってた・・・

moriwaka>
------------------------------------------------------------------------
shutdown.target
          A special target unit that terminates the services on system shutdown.

          Services that shall be terminated on system shutdown shall add Conflicts= and Before= dependencies to
          this unit for their service unit, which is implicitly done when DefaultDependencies=yes is set (the
          default).
------------------------------------------------------------------------
systemd.special(7)に↑の記載があったよ
pl*****> DefaultDependencies=noにしてる場合のみ必ず書く必要があるって感じか

systemdのドキュメント

pl*****> ぁー systemd.specialなんてあるのか・・・読んでませんでした
moriwaka> systemd組込みのunitは Documentation=man:systemd.special(7) みたいな感じでどこ読めばいいかも書いてくれてるからそこから辿っていくとやりやすいです
pl*****> ProtectSystem=とかすごい安心感ある・・・こんなのあるんだ
pl*****> ドキュメント辿ってるだけで時間が無限に過ぎそう
moriwaka> dpkg -L systemd|grep /man|wc -l → 198
多すぎてさすがにびびった。まあだいたい7章から辿れるはず……
pl*****> 片手間で鯖缶してる人なんかは、たしかにsystemd勉強するのは辛いかもね
pl*****> 読むもの大杉ってなりそう
moriwaka> おおざっぱには、systemd-* はあんまりユーザが叩かないコマンドとかなので
systemd.*(5) でunitの設定読んで、必要に応じて*.conf読んで、あとなんとかctl のman pagesを読んでおけばだいたい日常の用は足りるはず
systemd.directives.7.gz というのがunitで書けるディレクティブの辞書的になってて
こっから記載があるman pageがたどれる
pl*****> ふむ
moriwaka> unitファイル見たら知らないディレクティブがでたときむけ(だいたいsectionでわかるけど

コマンド分け……てるよ

ar*******> journalctl とか、わけるのかくっつけるのか、一貫性がないな。
ar*******> それわけるなら、systemctl をもう少し細かく分けたらいいのに。
aa**> systemdってなんでしょうか？サービスを管理するなにか？
moriwaka> linuxユーザーランドの基盤をととのえるプロジェクトの名前兼、initをやるデーモンの名前
pl*****> 個人的にユーザーランドに頭出してる第二のカーネルと思ってる
moriwaka>
------------------------------------------------------------------------
$ dpkg -L systemd | grep bin/
/bin/journalctl
/bin/loginctl
/bin/networkctl
/bin/systemctl
/bin/systemd-ask-password
/bin/systemd-escape
/bin/systemd-inhibit
/bin/systemd-machine-id-setup
/bin/systemd-notify
/bin/systemd-sysusers
/bin/systemd-tmpfiles
/bin/systemd-tty-ask-password-agent
/usr/bin/bootctl
/usr/bin/busctl
/usr/bin/hostnamectl
/usr/bin/kernel-install
/usr/bin/localectl
/usr/bin/systemd-analyze
/usr/bin/systemd-cat
/usr/bin/systemd-cgls
/usr/bin/systemd-cgtop
/usr/bin/systemd-delta
/usr/bin/systemd-detect-virt
/usr/bin/systemd-mount
/usr/bin/systemd-path
/usr/bin/systemd-resolve
/usr/bin/systemd-run
/usr/bin/systemd-socket-activate
/usr/bin/systemd-stdio-bridge
/usr/bin/timedatectl
/bin/systemd
/usr/bin/systemd-umount
------------------------------------------------------------------------
実行ファイルだけでこんだけある
まあsystemctl, journalctl, loginctlくらいしか日常叩かないけど

このへんのソフトウェア群がサービスが起動したりログインセッションはじまったりするための環境をととのえるために色々な仕事をします
aa**> あーそれなのか、systemctl, journalctl,はよくお世話になってます

timedatectlつかう?

pl*****> timedatectl、新し目のrhelだとtimesynd使うようになったり？
pl*****> 7系はchrony固定なのかな
moriwaka> 7はchronyかntpdですね。timesyncdは自分でつかったことがないからよく知らない
pl*****> なるほど

2018年6月11日

systemdのめっちゃ嬉しい機能をダラダラと説明する

2018/06/07〜2018/06/08 あたりにtwitterでつぶやいたsystemdのうれしいシーンまとめ

Package管理と相性がよい

sysvinitのスクリプトちょっといじってulimit文足したあとにパッケージupdateしたら消えたりしたことがある人はsystemdならその不幸はもう起きない
systemdは設定ファイルが /usr, /etc, /run くらいにバラけて配置されるのでパッケージが提供するのをカスタマイズで変更するのは簡単にできるしパッケージシステムの更新などと相性もいい。
バラバラだと作業が煩雑になりがちなので関連コマンドが充実

パッケージのデフォルト、/etc/での設定、/run/の自動生成された設定などをまとめてunitを表示してくれる systemctl cat

unitをカスタマイズするときに適切なファイルを編集してくれる systemctl edit などのコマンドも便利
現在の設定を評価してデフォルトからどう変更されたかをまとめて表示してくれる systemd-delta コマンドもあるよ。

sysvinit等でありがちだった罠にハマりにくい

/etc/init.d/hoge を直接実行してserviceコマンド経由での起動時と環境変数やらが違うからハマった人、systemdならその不幸はもう起きない
同じサービスを1システム内で複数インスタンス構築してpidファイル被ったりログがどれがどれやら混乱したり、そういうことはsystemdをちゃんと使えば回避できる(残念ながら対応したパッケージは少ない)

設定ファイルのunit名を @で終わらせると複数インスタンスに対応。たとえばgetty@tty1.service というunitはtty1用のgettyで、仮想端末にあわせてgettyをいくつも作成する。この場合設定ファイルはgetty@.serviceになる。

/etc/init.d以下のスクリプトがしれっとタイムアウトしてるくせにexit 0してて「フザケンナ」ってなったことがある人、残念ながらsystemdでも敢えてやればできちゃうけど普通の使い方ならちゃんと失敗したらnon zeroなexit code返すよ

systemctl status で指定したunit(のどこかで)失敗が発生しているとexit codeがnon zeroになる

systemdのunitではサービス実行前のチェック、サービス実行直前の準備コマンド、サービスそのもの、サービス実行直後に実行するコマンドなど細かくフェーズを分けてコマンドを記述できる。設定は面倒かもしれないが実際にどこかで失敗が発生したときにどのコマンドで問題が発生したか、exit codeは何かなどを細かくレポートしてくれて素敵。

Linuxの新しい機能などを上手くサポートしてくれる

一時ファイルを/tmpに作って置き換え可能なタイミングが発生する典型的なセキュリティホール作っちゃった人、systemdならそのサービス専用の/tmpをbind mountして分離する緩和策が1行書くだけで実施できるよ

PrivateTmp=true と指定するだけ
mount namespaceとbind mountを使ってunitに特有の/tmp を作ってくれる
他にもいろいろ制限をかける仕組みがあるので systemd.exec(5) のSandboxingを見るとよい

「linuxはcgroupでリソース制限かけてメモリ+swapの上限とか設定できる」それどうやって使うんだろうと思った人、systemdならサービス毎にcgroup作ってるから設定1行書くだけでできるよ

MemoryMax=10G とか書く
詳しくは systemd.resource-control(5) にある

サービスの管理や追跡の機能が豊富 (いくつかはcgroup統合のおかげ)

なぜか時々死ぬサービスを再起動するためにdaemontools入れたことある人、systemdならそれ最初からあるよ

Restart=always とか。どういう条件でプロセス終了した場合に再起動するかなどをRestart=の設定で細かく指定できたり、再起動前の待ち時間をRestartSec=で指定できたりするよ。

「ん、このサービスいつ起動したっけ、先週月曜だっけ……?」ってログ漁ったことある人、systemdなら各サービス毎にいつ起動したかちゃんと覚えてるよ
謎のbashが動いてて「え、これ何から呼ばれてるの」と思ったけどpstreeで見たらinitの子になってて「なんだろー」ってなったことある人、systemdならどのサービスか、それともユーザーセッションから出てきたプロセスか即わかるよ

"systemctl status" だけ打つと各サービスやユーザセッションとの関係もでてきます

libvirtが起動するdnsmasqがサービス終了しても継続して動作してて、killall -9 dnsmasqしてNetworkManagerが呼んでる関係ないdnsmasqまで殺したことがある人、systemdならlibvirt関連の全プロセスだけを一発でkillできるよ

"systemctl kill <サービス名>" で、サービスに関連した全プロセスにkillを送れる

systemdはサービス毎にcgroupで追跡してるから、「このサービスどのくらいメモリやCPUつかってるのかな」って思ったらsystemctl statusやるだけでわかるよ

systemctl statusの例。起動時刻、CPUおよびメモリ消費、関連プロセス、最近のログ10行などがまとめて表示される

bus activationなどが素敵

systemdは「ooがされたらxxを起動する」みたいな奴に色々(dbus, mount, デバイス, ファイル, socket等)対応してるから、cockpitみたいな「どこでも使えてほしいけど使わないときはリソース節約のため落ちていてほしい」サービスとかを設定しておくとリソースあまり使わずに待ちうけできるよ

cupsが駆使してる。job queue(/var/spool/cups)にjob fileがあれば起動、dbus経由でアクセスがあれば起動、tcp port631にアクセスがあれば起動

udevがsystemdと連携して動作するので検出されたデバイスを依存関係に簡単に書ける。特定のデバイスが存在する場合にだけ有益なbluetoothdとか、lvmで必要なサービスを非同期で起動させるとか、ストレージの暗号化などで大活躍。

systemdの管理と統合されたsystemd-journaldによるログ管理素敵

複数台の/var/log/messagesを見比べて「何で時間が秒単位なん!どっちが先か後かわからん! (>_<)」ってなったことがある人、systemd-journaldならマイクロ秒まで保持してるよ

journalctl -o short-precise で時刻を細かくした出力が得られる

トラブルシューティングでsyslogでためてるメッセージを解析する時に"warning"とかで検索してcriticalなメッセージ見逃したことがある人、systemd-journaldならログレベル保持してるからあらかじめ分けておかなくても「warn以上」とかですぐ絞りこめるよ

journalctl -p 3 で error以上、など。

全然ログらしいの吐かないデーモンについて詳しい人に聞いたら「daemonizeさせずにforegroundで動かしてstderr見ればいいんだよ」とか言われて「そんなん知らんがな」と思ったことがある人、systemd + systemd-journaldならサービスのstdout,stderrもきっちりログに収集するよ
systemdはサービス管理とロギングが統合されてるから journalctl -u サービス名で特定のサービスに関連するプロセスが出したログだけ出してくれて便利。特に子プロセスの名前がメインのプロセスと違う時に見逃しがない。
journaldはtimestampをUTCで保持しているのでシステムのTZに依存せず簡単にログを比較できるよ
各システムにユニークなmachine-idがついて、そのmachine-idのディレクトリにログが保存されるので複数システムのログを同じところにまとめやすいし、まとめたログファイル群をマージして読めるよ

/var/log/journal/b1cb7fb826fe490da1e256a4300f4c2f/system.journal みたいなファイルになります
machine-idは /etc/machine-id に保存されている。このファイルを削除して再起動するか systemd-machine-id-setup コマンドで作り直しされる。

こまかい便利機能

systemdは競合するサービスをConflict=で明示的に定義できるからntpd動いてるのにchrony動かそうとすると実際に競合する前に検出して失敗してくれるよ
systemd、電源断や再起動だけでなくサスペンドやハイバネートもやるよ

systemdに興味を持った人むけリンク

systemd - Arch wiki
#きょうのsystemd: (翻訳)PID 1 を考え直す systemdの作者Lennert のblog翻訳

http://popopopoon.hatenadiary.jp/search?q=systemd 他にもいくつか翻訳なさっています

systemd によるサービス管理
- RHELのドキュメントです。意外(?)に包括的にまとまっています。

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日にて通常サポートが終了するように変更されました。

最新のライフサイクルについては以下をご確認ください。

https://access.redhat.com/support/policy/updates/errata/

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へのアップデートによってアプリケーションの動作に影響が出ないよう努力しているという件について文章化されたものはありますか。

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

互換性維持のポリシー文書が以下から辿れます.

https://access.redhat.com/solutions/5154

少し古いですが以下に上ページの和訳もあります。

https://access.redhat.com/ja/solutions/746483

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

-----------------------------------------------------------

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への移行については以下をご確認ください。

Red Hat Network クラシック (ホスト型) の Red Hat サブスクリプション管理への移行 http://red.ht/2agx5BP
Red Hat Subscription Management の概要 http://red.ht/2b6p0oB

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

https://access.redhat.com/security/cve/CVE-2015-0235 glibcの問題の修正

https://access.redhat.com/security/cve/CVE-2014-8626 phpの問題の修正

https://access.redhat.com/security/cve/CVE-2014-6271 bashの問題の修正

https://access.redhat.com/security/cve/CVE-2014-1544 nssの問題の修正

https://access.redhat.com/security/cve/CVE-2013-6420 phpの問題の修正

https://access.redhat.com/security/cve/CVE-2013-4113 phpの問題の修正

https://access.redhat.com/security/cve/CVE-2012-1182 sambaの問題の修正

完全な一覧は以下でご確認ください: 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: 各種資料がございます。

必要リソースの制限・上限についての比較表 http://red.ht/1FTcW20
4→5の差分 http://red.ht/2dnGDRN
5→6の差分 http://red.ht/2dnF0DF
6→7の差分 http://red.ht/1H4civp
5→7の大きな差分のナレッジ(要サブスクリプション) http://red.ht/2czp1kG

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

A: OpenJDKのサポート期間は通常のパッケージとことなり個別に設定されています(OpenJDKのみで他のソフトウェアにはこのような例外はないです)

https://access.redhat.com/articles/1299013

をごらんください。OpenJDK 6 (1.6)のサポートは December 2016 で終了します。

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

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

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

登録: 投稿 (Atom)