Android / iOS で shell を使いたい
はじめに
クライアント様から「サイトが表示されません」と連絡をもらいました。もしくは担当営業から「クライアントから電話が入った。助けて！」とヘルプが入りました。
「どーする、俺」という話。
私の場合、ドメインやDNSの問題を簡単に切り分けをしてから、必要な担当にエスカレーションをするのですが、切り分けのタイミングでPCを持ち合わせていないときにどうするか。
実は先日、PCを持たずに移動している電車の中で「ワイ氏、iPhone から 愛用のa-Shell（後述）をuninstallしてるぅぅ[1]」と苦境に立たされました。
また、iPhone が使えないとき[2]バックアップに Android でも同じ作業ができたほうがよい[3]と考えまして、勢いにまかせてセットアップしました。
本記事では↑というログ↑をささっと取って出ししています。
やりたいこと
「Webサイトが表示されない」という申告を受けた際、ドメイン/DNSの問題なのか、それ以外なのかをささっと切り分けたい。
PCを持っている際は、以下のコマンドを利用しています。
- whois
- dig
iOS
a-Shell はiOS上で動作するターミナルエミュレータです。
a-Shell は容量不足のワイ氏の iPhone では常時運用が厳しいサイズ(ver:1.12.6 で1.6GB)、a-shell mini は a-shellより利用できるコマンドが少ないですが、小さめサイズになっています(ver:1.12.6 で365.4MB。とはいえ小さくないですけど……)。
a-Shell mini には whois,dig,nslookup,ipconfig,ping,curl といったこの手の切り分けに必要となるコマンドがひととおり含まれているので、私の用途では a-Shell mini で十分でした。
インストール後、特に個別にインストールなどの作業なしに使えます。
Zenn.dev を調べてみました。
Android
今のところ以下を使っています。
起動するとLinuxディストリビューションを聞かれます。
この後CUI(Terminal)かGraphicalかの選択肢が出たと記憶してます。私はTernimalを選択してます。
私は Ubuntu を選びました。(この辺は好みによるでしょう)
初回起動時はもろもろインストールをするので、結構待たされます。セットアップは余裕のあるときに実施する必要がありそうです。
※時間がないときにはやらないほうがいいです。却って焦る。
Ubuntu を起動後、素の状態では whois , dig は使えないのでインストールする必要がありました。
sudo apt-get install -y whois
sudo apt-get install -y netbase
whois を入れただけの状態で whois しても
servname not supported for ai_socktype と言われて whois できません。あわせてnetbase もインストールしてください。
dig は以下の記事を参考に dnsutils でインストールできそうだと思ったのですが……
私が試したときはエラーになってしまったので、代わりに knot-dnsutils をインストールしてます。
sudo apt-get install -y knot-dnsutils
結果、こんな感じになります。
dig と kdig を間違えて、dig ほげほげしてエラーになりがち
Play Store で調べてたら、以下がひっかかってきたのでインストールしてみたのですが、私の環境 (Pixel8 Pro/Android 14) だと起動しませんでした。
ブラウザだけでどうにかする場合
ブラウザしか使えない！ というときは、以下のお世話になってます。
-
cman.jp
- めっちゃ老舗。物心ついたとき(年齢詐称)からお世話になってます。
- DNSレコードの状況を調べるのに便利です。
- whois は詳細調べにくくなっているので、別途 Whois 系のサイトで調べています。
-
Global DNS Propagation Checker
- これをブックマークに入れている環境の場合は、cman.jp よりこちらを先に使っています。
- NS切り替えて戻した、間違って切り替えたDNSのTTLが長かった……みたいなときにも使ってます。
-
JPRS WHOIS
- 検索可能なドメインは限られますが、JPドメインは全部いけます。
- 詳しくは JPRS WHOISをご確認ください。
- JPRS WHOISで調べられない場合は ICANN レジストリリスト：Registry Listings から検索先を探します。(めんどい)
特にWHOISの確認があちこち飛んでめんどくさいので、トラブルの切り分けなどで一刻を争う際は、ブラウザだけで戦う事態は極力避けたいのです。
参考: サイトが動いてません、と言われたときの初動の切り分け例
運用しているサイトやサービス・サーバー、そのときの状況などによって異なるとは思いますが、これまでの経験上、初動では以下を確認し「ドメイン・DNSの問題か、それ以外の可能性が高いか」を以下のポイントで切り分けすることが多いです。
以下で切り分けできないときは、さっさと然るべき方々へエスカレーションするのですが、トラブル発生中はエスカレーションの有無の切り分けにもスピード感が求められるので、この辺をスムーズに確認できるかどうかは結構大事かも。（なので 私はshellでささーっと確認したい派）
いままで動作していたものが、突然表示できなくなる
WHOIS でドメイン情報を確認します。
最終更新日が昨日・今日だったりするとドメイン関係の疑いが濃厚になります。
私がこれまでによく出会っているのは以下です。
- ドメイン更新費用の支払い漏れで、expire
- 英語のメールでお知らせが来たり、経理担当が受け取っているメールアドレスにお知らせがきて「よくわからない」と放置されるパターンを見たことがあります。
- 入金すればわりと早めに復旧できます。
- NSが他所を向いてしまった。
- ドメインを取得したサービスとDNS管理を別にしている場合にたまに起きちゃう。
- いまどきはドメイン取得+DNSサーバをセットで提供しているサービスさんが多いので、「利用中のDNSとは別のDNSにレコード設定→反映されないから、ドメインを取得したサービスさんのFAQを読んで、ドメイン側のNSも切り替え」的な作業をしちゃった、みたいなことが……結構ある……。
- 上記作業をしたときに「切り替えてしまった DNS サーバ側で TTL が長め(24時間)」に設定されていると、復旧までに時間がかかっちゃう。つらい。
- 【属性型JPドメイン（co.jp/or.jp/go.jp/ed.jp/ac.jp) の場合】必要情報の提出漏れによる expire
-
co.jpだと登記簿謄本や法人番号など。 - 必要な情報がなくてもドメイン登録し、利用開始できるのですが、期限内に提出しないとドメインが取り消されます。
-
上記で問題がない場合は、該当ドメインのAレコードを確認し、値が違うものになっていないかを確認してます。
Aレコードを確認して知らないIPアドレスが返ってきたら、WHOIS でそのIPアドレスの持ち主を調べて、なんとなくのあたりをつけることもしてます。
サーバー切り替え後のタイミングで、表示できなくなる・不安定になる。
この場合、DNS側に問題があるなら、経験上 NSを切り替えられた・ドメイン停止された……よりも、DNSの設定に問題がある可能性が高いです。
- A と AAAA で違うサーバが設定されている。
- 「会社からだと見えるけど、家からだと見えない/旧サイトが表示されている」「会社からだと見えるけど、会社のWIFIに繋がないスマホだと見えない/旧サイトが表示される」「(細かい切り分けはされずに)表示されたりされなかったり」的な申告のときに疑います。
- サーバ切り替えに伴い Aレコードをupdateする場合、同じドメイン名でAAAAが設定されている場合は注意が必要です。
- 切替後のサーバーがIPv6に対応している場合は、AAAAレコードの更新が必要です。IPv6に対応していない場合は、AAAAレコードは削除する必要があります。
- なので、AレコードとAAAAレコードの設定状況を確認します。
- Aレコードがなぜか知らない子になっている。
- 管理しているDNSサーバでうっかり更新してしまう。
- もしくは、ドメイン情報をうっかり更新してNSが切り替わってしまう(上述)
- 同じドメインに対して A と CNAME が一緒に設定されてる。
- 今どきのDNSサービスはこのような設定はエラーになるところが多いので、このケースが起きた記憶はほぼないです。(なので私は初動ではチェックしないです)
-
hoge.example.comに対して CNAME と Aが登録されているなど……
特定のページでのみ表示ができない or 遅い
この場合は、DNS/ドメイン関係の調査は飛ばしてしまいます。
ブラウザの検証ツール（Google Chrome のデベロッパーツールなど）や curl を利用して、そのページからのレスポンスや速度を確認します。
- サーバーからは普通に HTTP status 200 を返している。
- 表示に時間がかかっているパターン。
- タグ(GTMで配信してると見つけるのむずい)の影響とかもある。
- 特定のページのみめっちゃレスポンスに時間がかかっている。
- サーバー側で時間がかかってるので、調査が必要。
- 原因はシステム側にあったり、フロントの実装側にあったりとさまざまなことが多い。
おわりに
PCを持たない非エンジニアの私ができる初動切り分けはこんなものなので、なかなか非力ではあります。
とはいえ、
- 「お金払ってください」
- 「ドメイン設定修正してください」
- 「DNS設定直してください」
など、技術的なトラブルなのかそうじゃないのかをささっと切り分けられると、早く解決できる(場合もある) と実感はしています。
とはいえ、電車の中でスマホ2台を駆使(1台はSlack用)してあれこれ調査するのは人目を気にする必要があり、かつ、集中しすぎて降車駅を乗り過ごしてしまうリスクもあるので、なるべくそんな事態に陥らないことを常々祈っています。
Discussion