面倒、死のう

すごくなんかネカマっぽいテーマがあったしこれにしとこう

bindのdnssec-validationは何を確認しているのか?(未解決)

事の始まり

VirtualBoxのホストオンリーアダプターでクローズド環境なテスト環境を構築した。
その際、DNSの名前解決ができない壁にぶち当たる。

やったこと

f:id:mendocino:20220210171006p:plain
作った環境の概略図
全てホストオンリーアダプターで接続、同一セグメントで接続。
Contents DNSにはexample.testドメインの権威サーバーとしてbindを設定。
Cache DNSはContents DNSフォワーダーとして、丸投げキャッシュDNSとして作成。

Clientから

dig @ContentsDNS example.test any

直接権威サーバーに問い合わせれば解決できるが

dig @CacheDNS example.test any

これがエラーになる。キャッシュサーバーは解決してくれない。

解決策(そして新たな謎)

Cache DNSの/etc/named.confにある”dnssec-validation”のパラメータを"no"にしてあげることで、”名前解決”はできるようになる。
DNSSECというDNSの回答が本当に正しい権威サーバーから返しているのか検証する機能だ。多分。
キャッシュ側でその検証を無効化したおかげで、権威サーバーからの回答を受け入れてくれた。
確かに今回の権威サーバーではそんなややこしい設定はしていない。zoneファイル作っただけだ。
そうか世のDNS権威サーバーはこんなややこしい設定されてるんだなぁすげぇや。と思いきや調べてみると
dnsviz.net
google.comってば署名されてないじゃん! (2022/2現在)
先の"dnssec-validation”は使ったCentOS8のbindでは初期設定で有効だ。消してもデフォルト有効になる。
これでクローズドではない社内キャッシュDNSとして設置したらググれないではないか!

そして迷宮入り

そんなことは無い。安心してほしい。
Cache DNSをNAT接続にし、フォワーダーをISPDNS書き換えたが、"dnssec-validation”が有効でも、何も問題なく名前解決してくれる。
ん?署名してないよ?ドメインの署名確認してくれるんじゃないの?んん?
いやじゃあクローズドで解決してくれなかったのはなぜ?
色々調べてみたが、解決していない。誰か答えを教えてほしい。

小学生並みの仮説

当然ながら、.(ルート)はDNSSEC署名がされている。トラストアンカーというものらしい。
トラストアンカーに対する公開鍵はbindに同梱されている。2017年にこれが変わるせいで大騒ぎになった、らしい。 comもTLDのせいか、署名されている。
このあたりの上位ドメインで解決がなされれば一応OK、という判断をしているのではないか。
それであればクローズドの(やっつけドメインの)環境ではルート、及び上位ドメインを管理するDNSまでは作成していないので
辻褄は合う。そうしないとDNS使えなくなっちゃうものね。大混乱だし、そんな危険な機能有効にできないわ。
しかしそれであれば、現実外部ネットワークでDNSSEC検証が機能すること、「このgoogle.comの回答は嘘だね!」ということは無い、ということか。

ちなみにクローズドの環境でContents DNSgoogle.comのゾーンも作ってみたが、結果は同じだった。
.testだとかそういうのが問題なわけでもなさそうだ。
ほんと、なんなん?

RHELのサブスクリプション認証はexpectで自動化できなさげ?

T/O
ほぼ嘘じゃない。

ココを参考に、対話入力を自動処理させる方法を知る。
Linuxの対話がめんどくさい?そんな時こそ自動化だ!-expect編- - Qiita
ほぼコピペで

expect -c "
set timeout 5
spawn env LANG=C subscription-manager register
expect \"Username:\"
send \"rhn-user\"
expect \"Password:\"
send \"foobar\n\"
exit 0"

とかやればライセンスのアタッチが自動でできて
仮想環境とか落としたり消したり便利なんじゃない?
と思って試してみたが、パスワードの入力でスルーされる。
対策をしている、と思ってあきらめたほうがいいのだろうか。
ンチッ

閉域環境でインストールするパッケージをまとめたオレオレレポジトリを作るもなぜか失敗

T/O
嘘。ただしいつものごとく答えは見つかっていない。助けて。

RHEL8での依存関係の矛盾。依存パッケージがdownloadできない。 とりま、依存パッケージを確認。

# dnf deplist python3-pywbem

 Updating Subscription Management repositories.
メタデータの期限切れの最終確認: 0:37:18 時間前の 20210810103859秒 に実施しました。
package: python3-pywbem-0.11.0-8.el8.noarch
dependency: /usr/libexec/platform-python
provider: platform-python-3.6.8-37.el8.i686
provider: platform-python-3.6.8-37.el8.x86_64
dependency: python(abi) = 3.6
provider: platform-python-3.6.8-37.el8.i686
provider: platform-python-3.6.8-37.el8.x86_64
dependency: python3-PyYAML
provider: python3-pyyaml-3.12-12.el8.x86_64
dependency: python3-ply
provider: python3-ply-3.9-9.el8.noarch
dependency: python3-six
provider: python3-six-1.11.0-8.el8.noarch

うん、結構あるね。まとめてダウンロードして俺のリポジトリーの一部となれ。

# dnf download --resolve python3-pywbem
Updating Subscription Management repositories.
Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)                                                                                        12 kB/s | 4.1 kB     00:00    
(1/2): python3-ply-3.9-9.el8.noarch.rpm                                                                                                     175 kB/s | 111 kB     00:00    
(2/2): python3-pywbem-0.11.0-8.el8.noarch.rpm                                                                                               418 kB/s | 289 kB     00:00    

1こ。python3-PyYAML他がダウンロードされない。なぜ?   こんな感じだと--resolveオプション信用できない->一個一個手作業で依存確認の上、RPM集めの苦行。
タダでさえ外部からの持ち込み不可ルールにより、メーカー提供の設計書テンプレを写経する謎業務をやっているのに
あんまりだ。(これが日本のSIerだ!)

FF7はどう煮込んでもクソゲーになるらしい

PS4を買った当時にフリープレイ目当てでPSPlusにも加入したんですが、余りにもなラインナップだった為最初の1年で辞めてしまったんですよね。

なんかいいの来たらまた入ろう位にその時は思ってたんですが、数年かかりました。ホントやる気ないよね。

で、FF7リメイクが来ると。

そもそもなんですがPS1時代のFF7に対しても自分としては1点すらあげたくないレベルの評価なんですね。100満点で。

時代的にしゃーないと言えばしゃーないんですけども稚拙なグラフィック、幼稚なキャラ設定・ストーリー、最低な操作性。

開始して10分で自キャラの位置が分からなくなり、あぁこれはクソゲーなんだな、と悟り、しかしながら当時はまだ子供だったので捨てゲーするほど裕福でもなく、貧乏性からPARでステータスマックスにして取り敢えずエンディングまではやる、ただただ苦行を味わわせていただいた次第です。

そんな感じで、さらにその後ライトニングさんにもやられてますのでとうだろうかね、と思っていたところ、直前のフリープレーがキャッスルヴァニアだった為加入を決意。こちらはマップ埋めまで楽しませていただきました。これは良いゲーム。

でFF7Rですが、控えめに言って産廃ですね。

CO2削減の為にも直ちにお蔵入りさせるべきです。

出来ってゆうか、なんか新人に勉強がてらやらせたら出てきた、みたいな。

テストプレイ一度でもしたのか疑問が浮かぶ次第です。

これが複数に分けて出す、更にはPS5(とか今後の6とか7とか)にまとめて移植されるウルティメイト商法を考えると、地獄ですね。

悪い点

  • デザイン性しか考えてないと思しきUI
  • 申し訳程度に分岐がある一本道マップ
  • そのくせウォールマーケットのごちゃごちゃっぷりはやり過ぎ(多分ここ作ってる時に一本道って言われたトラウマ思い出したんだろうね)
  • アクション性強くしたっぽいのに爽快感が無い戦闘
  • 「あーこのレベルじゃボス倒せないなー」って時にレベル上げする術がない(セーブからやり直し)
  • そもそも敵がエンカ位置固定でなかなか復活しないのでレベル上げやりづらい
  • etc
  • 良い点

  • ディスク交換が要らない
  • 以上です。 いやーこれフルプライスで売るって凄いよね。

Apple Configurator2 でiPhoneを復元しようとすると失敗する事象について

各位。
iPhoneを大量にキッティングする際に使用する場合、Apple Configurator 2を利用します。
WifiSSID/キーとかあらかじめ入れたり、言語設定すっ飛ばしたりできます。
また、MDMを入れる場合監視モードにすることが推奨されており
これをやる場合Apple Configurator 2が必須になるようです。
(なんか迂回方法あるんだろうか)

退職やら異動やらで返却されたiPhoneをリフレッシュする際は、
通常はAppleIDの解除とか「いやもう退職してっからわからねぇよ」、と
いうようなことを求められますが
監視モードにしている場合は面倒なことはすっ飛ばして復元できます。

しかし、復元をしようとすると何度やってもiPhoneが「PCに繋いでね」画面になり失敗してしまう事象にぶつかりました。
正直、高確率で復元は失敗しているように感じます。

今回、1つの原因がわかったので書き留めておきます。
最新のiOSにバージョンアップしたiPhoneを用意し、AppleConfigurator2の起動したMacに繋ぎます。
すると、「~~~~をダウンロードします」みたいなのが出て、追加ダウンロードが走るんですね。
これをやると、同一機種であれば復元ができるようになるようです。

PCに繋いでね状態のiPhoneだとダウンロードは開始しないようなので
何度も復元試したりして時間がかかったなぁ。
あとWindows版が配布されていないのはひどいと思います。
あとAppleのアップデートはダウンロードくそ遅いですね。なんなんでしょうね。

Outlook予定表の人・施設名が「予定表」とか「Calendar」になってしまう事象

 Me too.

実際、何のことは無いアプリの不具合らしく
手動更新することで解消する。

条件として(バージョンは失念)

  • グループ スケジュールで表示
  • 左ペインのチェックをグループ単位で選択

とすると、すべての表示名が「予定表」、「Calendar」になってしまう。
個別にチェックするとちゃんと表示名が表示される。

以上。

Command Updateが10%で止まる

 me too.
(宗教上の理由でTwitterはバンされたので)

Ver3.1.3にアップデートされて発生しているので多分バグ。

しかし、Command Updateの挙動は怪しい。
アップデートがあるとウィンドウ消す癖に復帰しないとか。せめてアップデート完了!くらい出てもいいと思うんだが。
Command UpdateなのかSupportAssistなのかどっちかに統合してもらえないもんだろうか。

2020/08/17追記
解決しておりません。が、サポートサイト上で配布されている3.1.2をインストールして
確認した後の更新一覧からDCUのアップデートを外せばその他Biosとかドライバー類は
更新できるようです。
たのむから早く3.1.3をリポジトリから消してくれ。>Dell

2020/09/02追記
ver3.1.3がリポジトリから消えたのか、
更新しても3.1.2が落ちてくるようになっている模様。
とりあえず何も考えず更新しても問題なくなっている状況になった。