update-mot.dに仕込むスクリプト(SSL証明書の有効期限確認)

概要

2023年10月現在、自分のサイトの証明書はLet's Encryptのワイルドカード証明書を利用しています。
性質上、有効期限が90日のため「いつ頃が有効期限か」を確認するためのスクリプトをChatGPTに書いてもらいました。

スクリプトが動く要件

  • サーバがインターネットに接続されていること。
  • Rubyがインストールされていること。
  • Opensslがインストールされていること。

指示した内容

  1. 変数で指定したURLにopensslで接続
  2. 証明書の有効期限を読み取る
  3. 「サイト ○○ の有効期限はyyyy/mm/dd です。残り○日です」と表示する

返ってきたスクリプト

  • ssl_cecker.rb
  • URLは必要に応じて変更してください。
require 'openssl'
require 'socket'
require 'date'
require 'uri'  # URIモジュールを追加

# 変数で指定したURL
url = "https://hoge.example.com"

# 変数で指定したURLに接続して証明書の有効期限を取得するメソッド
def get_certificate_expiry_date(url)
  uri = URI.parse(url)
  hostname = uri.host

  begin
    # SSL接続を確立
    tcp_client = TCPSocket.new(hostname, 443)
    ssl_context = OpenSSL::SSL::SSLContext.new
    ssl_socket = OpenSSL::SSL::SSLSocket.new(tcp_client, ssl_context)
    ssl_socket.hostname = hostname
    ssl_socket.connect

    # 証明書の有効期限を取得
    cert = ssl_socket.peer_cert
    expiration_date = DateTime.parse(cert.not_after.to_s)
    days_remaining = (expiration_date - DateTime.now).to_i

    return expiration_date, days_remaining
  rescue => e
    return nil, e.to_s
  ensure
    ssl_socket&.close
    tcp_client&.close
  end
end

# メイン処理
def main(url)
  expiration_date, days_remaining = get_certificate_expiry_date(url)

  if expiration_date
    formatted_date = expiration_date.strftime("%Y/%m/%d")
    puts "サイト #{url} の有効期限は #{formatted_date} です。残り #{days_remaining} 日です。"
  else
    puts "証明書の取得に失敗しました: #{days_remaining}"
  end
end

# メイン処理を呼び出し
main(url)

スクリプト実行例

ruby ssl_checker.rb

サイト https://hoge.example.com の有効期限は 2024/01/12 です。残り 88 日です。

motodへの登録

これはサーバ管理の度に確認したいので、motdに以下のスクリプトを管理者権限で配置します。

  • ファイル名
/etc/update-motd.d/99-custom-motd
  • スクリプト内容
#!/bin/bash
ruby /path/to/directory/ssl_cecker.rb
  • 実行権付与
sudo chmod +x /etc/update-motd.d/99-custom-motd

motd登録確認

任意のターミナルクライアントでSSH接続後、

サイト https://hoge.example.com の有効期限は 2024/01/12 です。残り 88 日です。

と表示されればうまくいっています。

備考

  • 今回のChatGPTへの伺いはほぼ一発でした。
  • 対話型やテキストを読み込むなども機を見て実装させたいです。

情報カードによる構図の振り返り。

第一印象は「サイズが多くて手に余る」思っていたB6サイズの情報カード(いわゆる京大式カード)。

その別の使い方をちょっと試します。

写真添付

フィギュア撮影の際、ふとした弾みで「また撮りたい構図」が出て来ます。

それらをデジタルのフォトアルバムでお気に入り登録するのはしているものの、割と手に余ります。

また、構図は組み合わせて参考にしたいため、物理的に出力してアルバムに収納するのも出し入れが面倒です。

そこで、情報カードに貼り付けてみることにしました。

  • L判を縦にギリギリ貼れる
  • 周辺に書き込めるだけの余白がある
  • サイズが統一されているから取り回しがしやすい

の特徴あり。

収納

収納は、既存の情報カード収納ボックスにそのまま入れるだけ。インデックスもあるので分類は非常に簡単です。

一番の利点は

「他の情報カードと組み合わせられる」こと。

おかげで、メモとメモのつながりが見えるようになってきます。

デブリーフィングを受けて:サイクリング用カメラを発掘。

こちらの記事の続きになります。

ここで、今の自分にとって「サイクリング時にはミラーレスですら重く感じる」を受け、

  • コンパクトで
  • ある程度の撮影が期待できて
  • 使いやすい

カメラはないだろうかとしばし思案していたら、条件に沿うものを使っていました。

OLYMPUS SH-3

ストレージから取り出したのはこちら、7年も前のモデル、OLYMPUSのSH-3です。

いわゆるコンパクトデジカメに位置するものですが、かつての愛機であり、使用感は慣れています。

改めて、このカメラの使用感を再検証です。

近接撮影での比較

引っ張り出したばかりなので、まずは、今の自分のメイン分野である近接撮影(フィギュア撮影)を検証。

ボケ感にクッキリとした違いがあるものの、ピントが全面に合うのは評価点です。

強み:分割撮影

これはストロングポイントです。一枚の写真に複数の被写体を合わせられるこの機能は、サイクリング時に役立ちます。

再考時の判断

明るさが気になったのですが、本機が想定する撮影条件は屋外のため、そこは大丈夫だろうという判断。

あとは、サイクリング時に本当に役立つかを検証します。

Ansible検証:簡単なplaybookとコマンドのエイリアス

概要

検証の続き。

  • Ansibleサーバのインストール
  • Ansibleサーバにクライアントを設定

まで完了したので、Playbookを書いてみます。

Playbookサンプル

単純に、Webサーバ(apache2)を再起動するためのymlを書きます。

  • WebRestart.yml
---
- name: Restart Apache2 Service
  hosts: clients
  become: yes  
  tasks:
    - name: Restart Apache2
      service:
        name: apache2
        state: restarted

Playbook実行失敗

  • Playbook実行
ansible-playbook WebRestart.yml
  • 実行結果抜粋
fatal: [IP]: FAILED! => {"ansible_facts": {}, "changed": false, "failed_modules": {"setup": {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"}, "failed": true, "module_stderr": "Shared connection to IP closed.\r\n", "module_stdout": "sudo: パスワードが必要です\r\n", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1, "warnings": ["Platform linux on host IP is using the discovered Python interpreter at /us
  • サービス再起動のためには管理者権限が必要
  • 管理者権限への昇格のためのパスワードが書かれていない

ため、この結果となりました。

回避策

  • Ansibleのクライアントにrootログインする
  • sudoの昇格時にパスワードを不要とする

の2つはセキュリティ的によろしくありません。

  • Ansible Vaultで暗号化

は、暗号化→複合化の手間を伴います。そこで、単純に

ansible-playbook --ask-become-pass WebRestart.yml 

とすることで、Playbook実行時にリモートホストのSudoパスワードを尋ねられるようになり、上記Playbookも正常に実行できました。

回避策の更に回避策

効率化を図るとはいえ、Playbook実行時に

ansible-playbook --ask-become-pass 

とオプションをつけるのは面倒です。更に回避策を考えます。

Case1. セッション時のみ有効なエイリアスをつける

alias ansible-playbook='ansible-playbook --ask-become-pass'

を作業前に実行。これで、

ansible-playbook

と実行するだけで

ansible-playbook --ask-become-pass

が得られます。この方法は一回限り有効な手段。サーバの設定を余り変えたくないときに有効な手段です。

Case2. .bashrcにエイリアスを付与する。

echo "alias ansible-playbook='ansible-playbook --ask-become-pass'" | tee -a ~/.bashrc

source ~/.bashrc

Case1を永続的に付与する手法です。運用者での合意が取られているなら、メンテナンス的にも楽だと言うことでこの方法を採ります。

Ansible検証:ローカルNWでのAnsibleサーバ設定

概要

複数のサーバー管理を効率化するため、Ansibleサーバをインストールします。

前提・概要

今回は検証のため、単純構成。

  1. Ansibleのホスト
  2. Ansibleのクライアント

の2台構成であり、両方とも同じネットワークに属しています。

また、OSは共にUbuntu20.04です。

本項では、「Ansibleのホストサーバ」の設定を行います。

Ansibleホストの設定 (Ubuntu20.04)

Ansibleをインストールします。

sudo aptitude update
sudo aptitude install ansible
# 筆者はapitudeの方が好みです。必要に応じてaptを利用してください。

ホスト~クライアント間のSSH鍵を生成します。

Ansibleホスト~クライアント間はSSHで通信を行うので、鍵のペアを作成します。また、ローカルネットワークのためパスワードは省きます。

  • 鍵作成
ssh-keygen -t ecdsa -b 521
# 後続のプロンプトは全て空Enterにします。

ssh-copy-id [Ansibleホストのユーザ名]@[AnsibleクライアントのIPアドレス]
# Ansibleホストのユーザ名のパスワードを入力して鍵を登録します。
  • SSH通信確認
ssh [Ansibleホストのユーザ名]@[AnsibleクライアントのIPアドレス]
# SSHログインを確認します。

exit
# ログアウトします。

Ansibleホスト側の設定

  • 設定ファイルのコピー(ansible.cfg)
sudo cp -pi /etc/ansible/ansible.cfg /path/to/backup/directory/ansible.cfg.$(date +%Y%m%d)
# 任意のバックアップディレクトリを指定します。

diff -u /etc/ansible/ansible.cfg /path/to/backup/directory/ansible.cfg.$(date +%Y%m%d)
# 差分がないことでバックアップを確認します。
  • 設定ファイル修正

以下のファイルを、教義・信仰に沿ったエディタで編集します。

/etc/ansible/ansible.cfg
  • 編集内容
[defaults]
inventory      = /etc/ansible/hosts
remote_user    = your_username
private_key_file = /home/your_username/.ssh/id_ecdsa
# 上述した鍵ペアの「秘密鍵」の方を指定します。your_usernameはそれを作成したユーザ名です。

Ansibleホストインベントリの編集

  • 設定ファイルのコピー(ホストインベントリ)
sudo cp -pi /etc/ansible/hosts /path/to/backup/directory/ansible_host.$(date +%Y%m%d)
# 任意のバックアップディレクトリを指定します。

diff -u /etc/ansible/hosts /path/to/backup/directory/ansible_host.$(date +%Y%m%d)
# 差分がないことでバックアップを確認します。
  • 設定ファイル修正

以下のファイルを、教義・信仰に沿ったエディタで編集します。

/etc/ansible/hosts
  • 編集内容
[clients]
[クライアントのIPアドレス] ansible_ssh_user=[ホストのユーザ名]

Ansibleの設定確認

以下のコマンドを実行します。

ansible clients -m ping

次の結果が返ってくれば成功です。

(クライアントのIP)  | SUCCESS => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python3"
    },
    "changed": false,
    "ping": "pong"
}

※以下のようなメッセージは今のところ無視して大丈夫です。

discovered Python interpreter at /usr/bin/python3, but future
installation of another Python interpreter could change this. See
https://docs.ansible.com/ansible/2.9/reference_appendices/interpreter_discovery.html for more information.

これで、Ansibleサーバの簡単な検証が行えました。

クライアント側の設定やplaybookの作成は今後、実施していきます。

秩父サイクリングのデブリーフィング。

久しぶりの秩父にて

足繁く通っていた頃よりも増えた習慣/趣味。それらが今回のサイクリングでどのように作用したかを軽く触れてみます。

手書きの習慣:○

  • ほぼ日手帳
  • ジブン手帳
  • ダイアログノート

など、様々なアナログツールで書く習慣が大いに役立ちました。これによって、細かな気づきや思ったことを即座に書いて、その場は忘れることができました。

その後、こうして思い起こすことができるようになったのです。

特に、情報カードはマスターピースと言うべきもの。

  • 取り出しやすく
  • 書きやすく
  • 紙自体に適度な腰があり
  • 後から見やすい

と、当初は「こんなに大きいのか」と不安だったのですが、そこはやはり先人の知恵でした。

スマートウォッチ:○

予想通りというか、予想以上の活躍でした。

  • 走った距離
  • そのマッピング
  • 体調にどんな変化が起きたか

をつぶさに記録。「この道をどのぐらいの速度で走ることができた」は特に収穫。もう一度その道を走るときの参考になります。

ミラーレスカメラ:×

逆に、足かせとなりました。理由は単純。ある程度の平滑部を走る都内と異なり、アップダウンとあれた道がある所でカメラを持ち運ぶだけでも大変です。

衝撃に備えてカメラバッグに入れていましたが、そうなると水筒や食料のスペースを阻害します。

また、体を使った後、「カメラを構えて集中して撮影する」ための集中力を使い切るパターンがあったので、これは再考の余地ありです。

というよりも、もっと気軽に撮れてある程度の撮影が担保されるコンパクトデジカメでいいのではと本気で検討しました。

おまけ:食べたもの

サイクリングの途上の栄養補給的なものだったので、レストランには立ち寄らず。

道の駅で惣菜パンを戴きました。

これが疲れた体に染み渡る味。折しも秋風が心地よく、絶好のロケーションで食べることができたわけで。

まとめ

  • 途上の記録は何よりも大事
  • ただし、重視すべきは即時性と可搬性
  • 特に、カメラは敢えてコンデジにする

ってところです。

ChatGPTによるシェルスクリプト。(DNSレコード問い合わせ-2-)

続・DNSレコードを問い合わせるシェルスクリプト

このスクリプトを発展させました。

スクリプト内容

  • dns.sh
#!/bin/bash

# ドメイン名の入力を求める
read -p "ドメイン名を入力してください: " query

# 入力が未設定の場合の処理
if [ -z "$query" ]; then
    # デフォルトのDNSで問い合わせを行う
    default_dns=$(dig +short A +short myip.opendns.com @resolver1.opendns.com)
    echo "デフォルトのDNS: $default_dns"
else
    # ユーザーが指定したDNSで問い合わせを行う
    read -p "問い合わせるDNSを指定してください(空白Enterの場合はデフォルトのDNSを使用します): " dns_server

    if [ -z "$dns_server" ]; then
        dns_server="@resolver1.opendns.com"
    else
        dns_server="@$dns_server"
    fi

    # Aレコードの問い合わせ
    a_record=$(dig +short A $query $dns_server)
    if [ -z "$a_record" ]; then
        a_record="未設定です"
    fi

    # TXTレコードの問い合わせ
    txt_record=$(dig +short TXT $query $dns_server)
    if [ -z "$txt_record" ]; then
        txt_record="未設定です"
    fi

    # MXレコードの問い合わせ
    mx_record=$(dig +short MX $query $dns_server)
    if [ -z "$mx_record" ]; then
        mx_record="未設定です"
    fi

    # レコードの問い合わせの種類を選択するプロンプトを表示
    echo "問い合わせるレコードの種類を選んでください:"
    echo "1. Aレコード"
    echo "2. TXTレコード"
    echo "3. MXレコード"
    echo "4. すべてのレコード"

    # レコードの種類をユーザーに選択させる
    read -p "選択してください (1, 2, 3, または 4): " record_type

    # ユーザーの選択に応じて問い合わせ結果を表示
    case $record_type in
        1)
            # Aレコードの問い合わせ結果を表示
            echo "Aレコード: $a_record"
            ;;
        2)
            # TXTレコードの問い合わせ結果を表示
            echo "TXTレコード: $txt_record"
            ;;
        3)
            # MXレコードの問い合わせ結果を表示
            echo "MXレコード: $mx_record"
            ;;
        4)
            # すべてのレコードを表示
            echo "Aレコード: $a_record"
            echo "TXTレコード: $txt_record"
            echo "MXレコード: $mx_record"
            ;;
        *)
            # 無効な選択が入力された場合のエラーメッセージ
            echo "無効な選択です。1, 2, 3, または 4 を入力してください。"
            ;;
    esac
fi

追加した内容

「どこのDNSサーバに問い合わせを行うか」です。

  • ローカルDNSに問い合わせたい場合
  • 冗長化を組んでいるDNSのセカンダリーに反映されているかを確認したい場合
  • 世界的なDNSでもレコードが引けるか

を確認するケースが多々あったので、これを追加です。今回ChatGPTが指定したのはopendnsなので、

DNSサーバ名主なIPアドレス
Google Public DNS8.8.8.8
Cloudflare DNS1.1.1.1
Quad99.9.9.9
Level 3 DNS4.2.2.1

といったDNSサービスを変数に入れればデフォルトを変えてくれます。

道の駅で買ったもの。

今回のサイクリングでの収穫は、普段の撮影に使えるものでした。

樽入りクッキー

ポテくまくんがプリントされた樽。

水上を訪れた際にも売られていた同型でした。

自分としては:複数購入したとしてもしっかり背景に使えるので別バージョンを見かけるたびに買ってみようと思います。

ミニチュアハウス

これが今回最大の収穫ではありました。

ハンドメイドのミニチュアハウスです。

棚で区切られ、これでもかとお菓子が飾られています。彩りも構図も自分好み。

早速、figmaと合わせたら完璧。

ある程度の広さもあるし、背景に説得力が生まれました。

他にもこのミニチュアハウスのバリエーションはあるようなので、ここに訪れる理由ができました。

秩父方面・サイクリング記録。(2023年10月)

ここを最後に訪れたのは2017年以来でした。

スタート:道の駅あらかわ

ブロンプトンを改修して一年弱なので、足回りは十分です。

秩父市街~秩父神社

いくつかの峠を越えて秩父市街へと近づきます。澄み切った青空の下でこぐペダルは快調そのものでした。

そうして秩父神社に到着。

ミストの演出がフィルターに反応していました。

長瀞周辺

今年はタイミング的に間に合わないと諦めていたのに、彼岸花が群生しているところが見つかったのが収穫。

そうして長瀞駅へと到着。

ブランクが長いため、ここまでの距離でも結構な疲労感。ですが、それ以上の充実感がありました。

ボードゲーム対人記録『テラフォーミング・マーズ』2人戦。

初の対人戦記録

ソロプレイやCPU戦は数え切れないレベルでプレイしていたボードゲーム『テラフォーミング・マーズ』、ようやく、対人戦を行うことができました。

プレイ概略

相手は最初のプレイであるものの、ゲーム巧者のために初心者用のバリアントは使いません。

ドラフトはプレイ時間を短祝すためにオミット。

  • 自分:エコライン
  • 相手:ヘリオン

と、強い企業同士で戦いました。

結果

-エコラインヘリオン
TR4742
称号105
報奨912
緑地2312
都市2524
カード勝利点830
ボーナス2912
合計151137

得点で勝ちはしました。勝ちはしましたが、「こちらが一日の長がある」という勝ち方でした。

  • 上記で分かるように、カード勝利点は大きく水をあけられた。
  • 資源産出は相手が遙かなアドバンテージを持っていた。

のが2点です。特に科学タグを固め引きされ、《反重力技術》のようなロマンカードもプレイされた時はかなり血の気が引きました。

対してこっちは早々とストロングポイントにのみ絞り、盤面を抑えていく戦略が功を奏しました。

  • 草食動物
  • クマムシ(!)

が主なボーナスであり、この3枚がなければ負けは確定でした。

備考

  • インスト含めての総時間は4時間ほど。
  • 強い企業でアドバンテージを取り合うとほぼ拮抗でした。
  • さすが、重いゲームで候補に挙がるだけはあります。

Page 42 of 238

Powered by WordPress & Theme by Anders Norén