カテゴリー: ガジェット Page 29 of 95

紙の補充と収納。(情報カード)

2024年初頭、諸々購入しました。その中の一つはこれです。

情報カード大補充

去年の秋頃から使い始めた情報カード。

書くものが予想以上にあり、また、その消費スピードも思った以上なので10束(つまり1000枚)を一気に補充です。

収納

用いたのは、100斤のワイドストッカー。B6を横にしたものがすっぽり入り、ある程度の隙間も確保されています。

当面はこれを使い切ることが目標になります。

クリアファイルを利用したブックカバー。

こちらで、久しぶりに紙の本を購入しました。

いわゆるペーパーバックなので、物理的なカバーを作ることにします。

作り方はネットで適当に検索したものです。

用意したもの

  • クリアファイル
  • マスキングテープ
  • ペーパーカッター
  • カッターナイフ
ノベルティでもらったこのクリアファイルを用います。

やってみた手順

本の高さに合わせてクリアファイルを切ります。

百均で購入したペーパーカッターが大いに役立ちました。

背表紙の厚さに併せて折り目を付けます。

高さをマスキングテープで測ったら、定規とカッターナイフで軽く筋を付けております。

表紙にも折り目を付けます。

実際に置きながら測りました

表紙、裏表紙共にカッターで筋を彫ってから折ります。

カバーを固定します。

原作に併せ、『ハリー・ポッター』の呪文が書かれたマスキングテープを用いています。

本の情報を足して、留めます。

本のタイトルは付箋とマステで貼り付け、本自体はお弁当用のシリコンバンドで留めました。

これにて完成。

作るのは少し手間ですけど

  • 紙より破れにくく汚れにくい
  • 少しの水は弾いてくれる
  • 揃えやすい材料

ということで重宝。「これを使って良かった」と思える程度には本の中身にも手を付けていきます。

2024年最初の買い物。

新年、週末のお買い物はこちらとなりました。

ボードゲーム

  • ワーリング・ウィッチクラフト
  • ニュースボーイ

の2つ。両方とも比較的短時間で遊べる作品です。後者に関してはソロプレイにも対応しているので、この後サラッとルールを確認してみます。

本とデッキ

続けてこちら。

  • 『ハリー・ポッターと賢者の石』原書のペーパーバック
  • ドクター・フー統率者デッキ

それぞれ英国由来のエンターテインメント2つです。

原書に関しては2章ほど読み終えています。英語の脳がさび付いているので、それを落としながらの読書となります。

Ubuntu 20.04インストール後に行うこと。

2025年にサポートされなくなるOSではありますが、まだ現役というパターンがあるため、メモに残しておきます。

SSH設定

Ubuntu系OSをメディアからインストールした場合、SSHがインストールされていないことがほとんどです。

sudo apt install ssh

SSH鍵ペア作成

鍵認証でログインできるようにします。

ssh-keygen -t ed25519

# 鍵の格納場所は空Enter。(/home/hoge/.ssh/
# パスワードを設定します。

SSH鍵ペア作成確認

  • 秘密鍵の管理は慎重に行ってください。
  • パスワードも可能な限り設定して安全性を保ってください。
cd .ssh
ls -l
# 以下のファイルを確認します
# └id_ed25519
# └id_ed25519.pub
# ※これらのファイルはscp等で自分のクライアントにコピーします

鍵の設定変更

  • 公開鍵をauthorized_keysに変更し、パーミッションを厳密にします
mv id_ed25519.pub authorized_keys
chmod 600 authorized_keys

接続確認

この後、ローカルにコピーしたid_ed25519をSSHターミナルクライアントに保存して設定し、接続確認を行います。

SSHのパスワード認証を禁止

  • バックアップディレクトリ作成
sudo mkdir /etc/old

任意のバックアップディレクトリを作成します。

  • SSH設定ファイルバックアップ
sudo cp -pi /etc/ssh/sshd_config /etc/old/sshd_config.$(date +%Y%m%d)
  • バックアップ確認
diff -u /etc/ssh/sshd_config /etc/old/sshd_config.$(date +%Y%m%d)

エラーがない(差分がない)ことでバックアップを確認します。

  • ファイル書き換え
sudo sed -i -e 's/^#PasswordAuthentication yes/PasswordAuthentication no/' -e 's/^#PermitEmptyPasswords no/PermitEmptyPasswords no/' /etc/ssh/sshd_config
  • 差分確認
diff -u /etc/old/sshd_config.$(date +%Y%m%d) /etc/ssh/sshd_config
  • 差分
-#PasswordAuthentication yes
-#PermitEmptyPasswords no
+PasswordAuthentication no
+PermitEmptyPasswords no
  • SSH再起動

※この作業の前に、必ず、SSH接続は別に開けておいてください。※

sudo systemctl restart ssh.service 

SSH設定反映確認

  1. 新しくターミナルを起動します。
  2. パスワードでSSHログインできないことを確認します。
  3. 事前に転送しておいた秘密鍵でログインできることを確認します。

最初のアップデートとアップグレード

パッケージ全体のアップグレードを行います。

sudo apt update && sudo apt upgrade

アップグレード後、再起動を行います。

sudo reboot

ホスト名をドメインつきにする

Ubuntu系OSはインストール時にhoge.example.comと設定しても、

uname -n

# hoge(インストール時に設定したホスト名のみ)となっています。

とホスト名だけになるパターンが多いです。そこで、

sudo hostnamectl set-hostname hoge.example.com

として、(ホスト名やドメインや設定に合わせます)

設定語、

uname -n

# hoge.example.comを確認します。

プロンプト設定

最初期のプロンプトは

hoge@hoge$

になっているので、好みに沿って設定していきます。

  • 一般ユーザの.bashrc設定
cat << ___EOF___ | tee -a ~/.bashrc
PS1="[\u@\H \W]\\$ "

# 一般ユーザ向けのプロンプト設定
if [ "\$PS1" ]; then
  if [ "\$(id -u)" -eq 0 ]; then # rootユーザの場合
    PS1='\[\e[0;31m\][\u@\H \W]#\[\e[0m\] '
  else # 一般ユーザの場合
    PS1='\[\e[0;32m\][\u@\H \W]\$\[\e[0m\] '
  fi
fi
___EOF___
  • root

Ubuntu系は.bashrcが統一されないので、やむなくこの方法をとります。

sudo su -
cat << ___EOF___ | tee -a ~/.bashrc
PS1="[\u@\H \W]\\$ "

# 一般ユーザ向けのプロンプト設定
if [ "\$PS1" ]; then
  if [ "\$(id -u)" -eq 0 ]; then # rootユーザの場合
    PS1='\[\e[0;31m\][\u@\H \W]#\[\e[0m\] '
  else # 一般ユーザの場合
    PS1='\[\e[0;32m\][\u@\H \W]\$\[\e[0m\] '
  fi
fi
___EOF___

設定後、SSHセッションを開き直します。以下を確認します。

  1. 緑文字で[hoge@hoge.example.com~]$のように表示される。(一般ユーザー)
  2. 赤文字で[root@hoge.example.com~]#のように表示される。(root)

aptitudeインストール

これは完全に筆者の好みです。パッケージ管理をaptではなくaptitudeに変えます。

sudo apt install aptitude

他にもありますので、改めて別に記事を上げます。

暦の刷新。

2024年最初の「作業」はこの2つでした。

ほぼ日の差し替え

2020年7月頃から再開し、そこからはほぼ休むことなく書き続けているほぼ日手帳。

こちらの分冊スタイルになったお陰で取り回しが良くなったのが特徴です。

今年は、これにどのようなことを綴っていくのかも楽しみですが、

「毎日続けられるだけのモチベーションを保てるのか」

は不安でもあり、それを維持するのも楽しみでもあり。

カレンダー刷新

また、カレンダーも張り込みました。今まで買わなかったのが不思議なぐらいの『ライザのアトリエ』カレンダーです。

壁を覆うかのような大判と、丁寧に描き込まれたイラストは、そこにあるだけでモチベーションを高めてくれます。

  • 毎日の移り変わり
  • 2ヶ月ごとの移り変わり

これらをしっかり記録していき、2024年を無事に振り替えら得るようにしていきたいです。

新たな手帳。

2023年もいよいよ終わり。そんな中で、新しく手帳を開封しました。

ほぼ日ウィークリー

この時購入したほぼ日ウィークリーです。

用途:お金のやり取り

ここで記すものは

  • 収入
  • 支出

の2つ。Firefly-iii を利用し始めたので、オフラインバックアップとしてこれを使っています。

情報カードを得たことで、オンラインの記録システムはそれぞれ異なる紙の記録システムを持つようになりました。

  • WordPress: ほぼ日デイリー / ジブン手帳
  • Redmine: 情報カード / BookStack

そして今回、新たにほぼ日ウィークリーが加わりました。

  • デイリーよりも軽いため、すぐに取り出せる
  • 直近や過去の記録を取り出せる

のが導入の決め手です。

Ubuntu22.04検証環境に最新版のnginxとphp8.3をインストール。

概要

Ubuntu 22.04を検証機にインストールしたので、nginx環境を構築します。

前提

  • OSインストール済み
  • 初期設定完了済み

さっくりとした手順

  1. 必要なパッケージをインストールします。
  2. nginxのレポジトリを追加します。
  3. aptitudeでnginxのインストールを行います。
  4. phpのレポジトリを追加します。
  5. aptitudeでphpのインストールを行います。
  6. apache2を停止し、nginxサービスを有効化します。
  7. php8.3用のfpmをインストールします。

パッケージのインストール

sudo aptitude install curl gnupg2 ca-certificates lsb-release ubuntu-keyring build-essential zlib1g-dev libssl-dev libreadline-dev libyaml-dev libcurl4-openssl-dev git

先を見据えてgit等もついでにインストールします。

レポジトリ追加

  • レポジトリ追加
cat <<- __EOF__ | sudo tee -a /etc/apt/sources.list.d/nginx.list
deb https://nginx.org/packages/ubuntu/ jammy nginx
deb-src https://nginx.org/packages/ubuntu/ jammy nginx
__EOF__
  • 鍵追加
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys ABF5BD827BD9BF62

nginxで統一されている鍵を利用します

nginxインストール

  • パッケージ更新
sudo aptitude update

実行時、W: https://nginx.org/packages/ubuntu/dists/jammy/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.の警告は無視して大丈夫です。

  • インストール
sudo aptitude install nginx
  • バージョン確認
nginx -v

2023/12/29時点ではnginx/1.24.0と表示されていました

php8.3インストール

  • レポジトリ追加
sudo add-apt-repository ppa:ondrej/php
  • パッケージアップグレード
sudo aptitude update
sudo aptitude install php8.3

sudo aptitude install php8.3-{opcache,pdo,bcmath,calendar,ctype,fileinfo,ftp,gd,intl,json,ldap,mbstring,mysql,posix,readline,sockets,bz2,tokenizer,zip,curl,iconv,phar,xml,dev}

sudo aptitude install php8.3-{imagick,gmp}
  • バージョン確認
php -v

2023/12/29時点では PHP 8.3.1と表示されていました

apache2の無効化とnginxの再開

依存関係で、apacheが同時にインストールされます。本検証ではnginxを用いるので、apache2を無効化します。

  • apache2停止
sudo systemctl stop apache2.service
  • apache2自動起動停止
sudo systemctl disable apache2.service
  • apache2停止確認
systemctl status apache2.service

inactive(dead)を確認します

  • nginx再開
sudo systemctl start nginx
  • nginx自動起動有効化
sudo systemctl enable apache2.service
  • nginx起動確認
sudo systemctl status nginx
  • curlによる起動確認
curl http://localhost

Welcome to nginx! を確認します。

php-fpmインストール

nginxとphpを連携させるfpmをインストールします。

  • インストール
sudo aptitude install php8.3-fpm
  • インストール確認
systemctl status php8.3-fpm

active(running)を確認します。

2023年の主な出来事-サーバ編-

概要

2023年もじきに終わるということで、今年のまとめ。趣味のサーバ運用という点では大きなものがいくつかありました。

新たにインターネット上に構築したサイト

公開用Redmine作成

これが一番大きいです。

推しの名前でドメインが取得できたことにより、「これでWebを公開しよう」と思い立ち、正月休みから行動スタート。

ゲーム『ライザのアトリエ3』リリースに間に合わせ、様々な攻略情報を載せることができました。

Redmine自身の各種情報も掲載できたのも満足です。

アクセス解析システム:matomo作成

  • 非公開

公開用サイトのアクセス状況を知りたくて、このシステムをインストール。

Redmineとの連携はView_Customize_Pluginでなんとかなりましたし、その際、本邦のRedmineメンテナ様自身直々のアドバイスをいただけたことが印象に残っています。

フォトアルバムサイト:piwigo作成

フォトアルバムもついでに作成。

写真の拡充を図っていくのが来年度の目標になりそうです。

ドキュメント保存システム:BookStack作成

Redmineのプラグイン「knowlegebase」に代わるシステムを探していたら見つけました。

  • 本棚や本という概念
  • Markdownフレンドリー
  • 見出しに合わせたスクロール

など、おおよその欲しかった機能が備わっていて、今後のメインウェポンとなる予感です。

ローカルに構築したサイト

Nextcloud

2022年から継続利用。

Growi

2022年から利用しているマークダウンエディタ、growi。

2023年はmermaid.jsにようやく対応したので、デジタルでのメモ残しに大きく貢献しました。

firefly-iii

つい先日ではありますが、この財務管理システムを知ったおかげで「お金関係のロギング」を始められるようになりました。

来年度の目標

Ubuntu 20.04リプレース。

LTSのEOL2025年に備えます。そのためのボトルネックとなっている

  • Redmineのメジャーバージョンアップ
  • およびknoledgebaseの代替システム(現状候補はBookStack)

と検証を進めます。

サーバのスペックアップ

これに関しては予算と相談しながら。

ChatGPTによるシェルスクリプト(SSL証明書の更新)

Let's Encryptで更新しているワイルドカード証明書。

他のサーバにも適用するのを更に簡便にするため、自動化するスクリプトを出力しました。

動作を確認した環境

  • Ubuntu 20.o4
  • Apache2.4

要件

1. 証明書と鍵ペアがあるディレクトリを引数にしてコマンドを実行
 → ファイルがなければエラーを返す
 → ファイルが次の形式でなくてもエラーを返す
 ・hoge.example.com.crt.$(date +%Y%m) ← hoge.example.com.crtの部分を変数化
 ・hoge.example.com.key.$(date +%Y%m) ← hoge.example.com.keyの部分を変数化
2. 引数内のディレクトリのcrt.$(date +%Y%m)を対象に、以下のコマンドを実行する
  2.1 次のハッシュ値をそれぞれ参照し合っていれば後続
  openssl x509 -pubkey -in hoge.example.com.crt.$(date +%Y%m) -noout | openssl md5
  openssl pkey -pubout -in hoge.example.com.key.$(date +%Y%m)  | openssl md5
  2.2 次のハッシュ値をそれぞれ参照し合っていれば後続
  openssl x509 -issuer_hash -noout -in hoge.example.com.crt.$(date +%Y%m)
  sed -n -e'1d' -e'/BEGIN/,$p' hoge.example.com.crt.$(date +%Y%m) | openssl x509 -subject_hash -noout
3. openssl x509 -noout -dates -subject -in hoge.example.com.crt.$(date +%Y%m)
 のnotAfterを参照し、
 「ドメイン『hoge.example.com』有効期限:notAfterで出力した値 で更新します。よろしいですか?」
 を出力。y/nで後続判断
4. 整合性を確認したファイルを以下のディレクトリにコピー
 ・hoge.example.com.crt.$(date +%Y%m) → /etc/certs
 ・hoge.example.com.key.$(date +%Y%m) → /etc/private
 コピー完了の出力をする
5. 証明書のシンボリックリンクを貼り替える
  5.1 cd /etc/certs
  5.2 sudo ln -sf hoge.sample.com.crt.$(date +%Y%m) hoge.sample.com.crt
  5.3 1のコピーとリンクしたファイルのハッシュ値が同じであることを確認
6. 秘密鍵のシンボリックリンクを貼り替える
  6.1 cd /etc/private
  6.2 sudo ln -sf hoge.sample.com.key.$(date +%Y%m) hoge.sample.com.key
  6.3 1のコピーとリンクしたファイルのハッシュ値が同じであることを確認
7. 「Webサービスを再起動しますか?」y/n
 → yの場合は systemctl restart apache2.serviceして後続
 → nの場合はスクリプトを抜ける
8. 「証明書更新が完了しました」のメッセージを出してスクリプト終了

結果

出て来たのはこちら。

ssl_update.sh

#!/bin/bash

# 変更するドメイン
domain="hoge.example.com"

# OpenSSLのパス
openssl_path="/usr/local/ssl/bin/openssl"

# 証明書ファイルの格納位置
cert_dir="/etc/certs"

# 秘密鍵ファイルの格納位置
private_dir="/etc/private"

# 引数の数を確認
if [ "$#" -ne 1 ]; then
  echo "Usage: $0 <directory>"
  exit 1
fi

# ディレクトリが存在するか確認
directory="$1"
if [ ! -d "$directory" ]; then
  echo "Error: Directory not found"
  exit 1
fi

# 証明書と鍵のファイルパスを設定
cert_file="$directory/$domain.crt.$(date +%Y%m)"
key_file="$directory/$domain.key.$(date +%Y%m)"

# ファイルの存在を確認
if [ ! -e "$cert_file" ] || [ ! -e "$key_file" ]; then
  echo "Error: Certificate or key file not found"
  exit 1
fi

# ハッシュの確認
cert_hash=$("$openssl_path" x509 -pubkey -in "$cert_file" -noout | "$openssl_path" md5)
key_hash=$("$openssl_path" pkey -pubout -in "$key_file" | "$openssl_path" md5)

if [ "$cert_hash" != "$key_hash" ]; then
  echo "Error: Certificate and key do not match"
  exit 1
fi

issuer_hash=$("$openssl_path" x509 -issuer_hash -noout -in "$cert_file")
subject_hash=$(sed -n -e '1d' -e '/BEGIN/,$p' "$cert_file" | "$openssl_path" x509 -subject_hash -noout)

if [ "$issuer_hash" != "$subject_hash" ]; then
  echo "Error: Issuer hash and subject hash do not match"
  exit 1
fi

# 有効期限の確認
expiration_date=$("$openssl_path" x509 -noout -dates -subject -in "$cert_file" | grep "notAfter" | cut -d "=" -f 2)

echo "ドメイン『$domain』有効期限:$expiration_date で更新します。よろしいですか? (y/n)"
read response

if [ "$response" != "y" ]; then
  echo "証明書更新がキャンセルされました"
  exit 1
fi

# ファイルをコピー
sudo cp "$cert_file" "$cert_dir"
sudo cp "$key_file" "$private_dir"

# シンボリックリンクを貼り替え
cd "$cert_dir"
sudo ln -sf "$(basename $cert_file)" "$domain.crt"
cd "$private_dir"
sudo ln -sf "$(basename $key_file)" "$domain.key"

# リンクとコピーのハッシュが一致しているか確認
if [ "$("$openssl_path" x509 -pubkey -in "$cert_dir/$domain.crt" -noout | "$openssl_path" md5)" != "$cert_hash" ]; then
  echo "Error: Certificate hash mismatch after linking"
  exit 1
fi

if [ "$("$openssl_path" pkey -pubout -in "$private_dir/$domain.key" | "$openssl_path" md5)" != "$key_hash" ]; then
  echo "Error: Key hash mismatch after linking"
  exit 1
fi

echo "Webサービスを再起動しますか? (y/n)"
read restart_response

if [ "$restart_response" == "y" ]; then
  sudo systemctl restart apache2.service
  echo "Webサービスが再起動しました"
fi

echo "証明書更新が完了しました"
exit 0

作成後、

sudo chmod 744 ssl_update.sh

使う前の準備

  1. 変数を適度に修正します。
  2. 任意のディレクトリにドメインの条件に沿った証明書を格納します。

使い方

sudo bash ssl_update.sh [証明書を格納したディレクトリへのパス]

この後、各種を確認して

証明書更新が完了しました

まで出してくれます。

サーバ:OSの入れ替えに向けて。

昨日のfirefly-iiiのインストール失敗を受けて、

計画の見直しを迫られました。

根本的原因

OSとミドルウェア(PHP)のミスマッチ。というよりも、Ubuntu 20.04 系の限界が見えてきます。

LTSバージョンのEOLが2025年4月。

猶予が1年ほどあるものの、見直しが必要なものが沢山です。

ミドルウェアがパッケージされなくなったのも問題です。

等の延命策を採ってきましたが、限界が来るのは否めません。

まずは

Ubuntuのバージョンアップ検証

が必要になってきます。現状のメインツールである

  • Redmine
  • Nextcloud

をはじめとして、スムーズに移行できるかが問われます。

取り急ぎ:

  1. 空いているデスクトップPCにUbuntu 22(23)を入れてみる
  2. そこに、現在稼働しているデータを移行する。
  3. それと同時に検証を行う。
  4. 問題が無かったら自宅内の運用環境に改めて移行する

という順番です。

Page 29 of 95

Powered by WordPress & Theme by Anders Norén