Manualmaton's Laboratory

タグ: Ubuntu Page 2 of 17

Redmineサイトのセキュリティヘッダー修正。（脆弱性サイトの評価をA→A+に引き上げ）

By

オン 2025年2月12日

カテゴリー: Linux, redmine

外部に公開しているRedmineサイト。

https://plan.io/redmine-security-scanner

で確認したところ、評価はA。

X-Content-Type-Options header not set Content sniffing may enable cross-site scripting attacks. Since your Redmine server is not properly sending the X-Content-Type-Options header, your users are vulnerable to this attack vector.

の診断が出てA+に至りませんでした。

そこで、設定を修正し、脆弱性評価をA+に引き上げます。

環境

  • Ubuntu 24.04
  • Apache 2.4
  • Redmine 5.1
  • mod_headers モジュール有効化済み

現状のセキュリティヘッダー確認

  • /etc/apache2/sites-available/redmine.conf

で以下の箇所を確認。

    Header always set Strict-Transport-Security "max-age=63072000"
    Header set X-Content-Type-Options "nosniff"
    Header always append X-Frame-Options "SAMEORIGIN"
    Header set X-XSS-Protection "1; mode=block"

セキュリティヘッダーの適用方法を見直し、適切に設定されるよう修正します。

設定修正

  • ファイルのバックアップ
sudo cp -pi /etc/apache2/sites-available/redmine.conf /path/to/backup/directory/redmine.conf.$(date +%Y%m%d)

※自分のRedmineサイトの設定ファイルを指定します。

任意のバックアップディレクトリを指定します。(筆者環境 /etc/apache2/old/redmine.conf.$(date +%Y%m%d)

  • diffによるファイルバックアップ確認
diff -u /path/to/backup/directory/redmine.conf.$(date +%Y%m%d) /etc/apache2/sites-available/redmine.conf

差分がなければ（エラーがなければ）バックアップ成功です。

  • ファイルの修正

上記のredmine.confを、以下の差分になるように修正します。（管理者権限が必要）

-    Header set X-Content-Type-Options "nosniff"
-    Header always append X-Frame-Options "SAMEORIGIN"
-    Header set X-XSS-Protection "1; mode=block"
+    Header always set X-Content-Type-Options "nosniff"
+    Header always set X-Frame-Options "SAMEORIGIN"
+    Header always set X-XSS-Protection "1; mode=block"
​
  • ファイル修正確認
diff -u /path/to/backup/directory/redmine.conf.$(date +%Y%m%d) /etc/apache2/sites-available/redmine.conf

上記の差分が出てくればOKです。

設定反映

  • 構文確認
sudo apache2ctl configtest

→ Syntax OKを確認します。

  • Apacheステータス確認（反映前）
systemctl status apache2.service

→ active (running)を確認します。

  • Apache再起動
sudo systemctl restart apache2.service && echo $?

→ 成功時は 0 が出力されます。

  • Apacheステータス確認（反映後）
systemctl status apache2.service

→ active (running)を確認します。

修正確認

  • curlによる確認
curl -I https://redmineサイト

以下のような表示を確認します。

X-Permitted-Cross-Domain-Policies: none
X-XSS-Protection: 1; mode=block
X-Request-Id: ***********
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Runtime: 0.615862
X-Content-Type-Options: nosniff
  • 脆弱性診断サイトによる確認

https://plan.io/redmine-security-scanner

でURLを入力します。

過去の診断結果が表示されるため、『Re-Scan』をクリックして最新の診断結果を取得します。

「A+」の評価と、以下のような表示が出れば修正できています。

It looks like you are running Redmine 5.1.4. That's a version without any known security issues. Your Redmine is protected by properly configured TLS/SSL. All security relevant headers are configured properly. It appears that you have 3 or more Redmine plugins installed.

Firefly-iii 6.1.5→6.2.5アップグレード失敗と切り戻し

By

オン 2025年2月11日

カテゴリー: Firefly III, Linux

firefly-iiiのアップグレードを試みたところ、失敗。その記録と原因についてメモを残します。

環境

  • Ubuntu 24.04
  • Apache 2.4
  • MySQL 8.0.39
  • PHP 8.3.16
  • Composer 2.7.9
  • firefly-iii 6.1.5
  • → 6.2.5にアップグレードを試みた

試した手順

  1. DBのバックアップを取得します。
  2. 最新版のパッケージをダウンロードして展開します。
  3. 利用中のfirefly-iiiを待避させます。
  4. 待避させたfirefly-iiiからファイル/ディレクトリをコピーします。
  5. アップグレードを行います。（失敗）

DBのバックアップ

  • 作業ディレクトリに移動
cd /hoge && pwd

任意の作業ディレクトリに移動します。

  • DBバックアップ
mysqldump --no-tablespaces --single-transaction -u username -h localhost -p database_name > DB_Backup.$(date +%Y%m%d).sql

usename、database_name、及びDB_Backupは自分の環境に合わせます。

  • バックアップ確認
head -100 DB_Backup.$(date +%Y%m%d).sql

バックアップができていること、平文でSQLが読めることを確認します。

パッケージ取得

  • 作業ディレクトリに移動
cd /hoge && pwd

任意の作業ディレクトリに移動します。

  • wget
wget https://github.com/firefly-iii/firefly-iii/releases/download/v6.2.5/FireflyIII-v6.2.5.zip
  • ファイル所有者変更
sudo chown www-data:www-data FireflyIII-v6.2.5.zip
  • ファイル確認
ls -l FireflyIII-v6.2.5.zip

ファイルがあること、所有者がWebアプリ実行ユーザ(www-data)であることを確認します。

アップデート前のfirefly-iiiを待避

  • ディレクトリごと待避
sudo mv /home/www-data/firefly-iii /home/www-data/firefly-iii.$(date +%Y%m%d)

自分の環境に合わせます。firefly-iiiがインストールされているディレクトリをまるごと移動します。

  • 待避確認
ls -ld /home/www-data/firefly-iii

→ ディレクトリが無いこと

ls -ld /home/www-data/firefly-iii.$(date +%Y%m%d)

→ ディレクトリがあること

アップデートパッケージの解凍と配置

  • 解凍
sudo -u www-data unzip -o /hoge/FireflyIII-v6.2.5.zip -x "storage/*" -d /home/www-data/firefly-iii

/hogeは先ほど取得したパッケージがある場所です。アップデート前と同じ位置、名前に解凍します。

  • 解凍・配置確認
ls -l /home/www-data/firefly-iii

ファイル一式があり、www-dataが所有者になっていること

アップデート前のファイル・ディレクトリをコピー

  • 待避させたディレクトリに移動
cd /home/www-data/firefly-iii.$(date +%Y%m%d) && pwd

自分の環境に合わせます。

  • .envファイルをコピー
sudo -u www-data cp -pi .env /home/www-data/firefly-iii/.env

コピー先のディレクトリは自分の環境に合わせます。

  • .envファイルコピー確認
ls -l /home/www-data/firefly-iii/.env

ファイルがあることを確認します。

  • storageディレクトリのコピー
sudo -u www-data cp -pir storage /home/www-data/firefly-iii/
  • storageディレクトリのコピー確認
ls -l /home/www-data/firefly-iii/storage

ファイルやディレクトリがあることを確認します。

アップグレード → 失敗

  • アップグレード後のディレクトリに移動
cd /home/www-data/firefly-iii && pwd

先ほど展開したディレクトリに移動します。

  • DBマイグレーション
sudo -u www-data php artisan migrate --seed

ここで失敗。以下のエラーが出ました。

Composer detected issues in your platform:

Your Composer dependencies require a PHP version ">= 8.4.0". You are running 8.3.16.

PHP Fatal error: Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.4.0". You are running 8.3.16. in /home/www-data/firefly-iii/vendor/composer/platform_check.php on line 22

そのため、切り戻しを行います。

失敗したため切り戻し

  • Webコンテンツ配置ディレクトリに移動
cd /home/www-data && pwd

自分の環境に合わせます。

  • 展開したディレクトリ削除
sudo rm -rf /home/www-data/firefly-iii
  • ディレクトリ退避から復旧
sudo mv /home/www-data/firefly-iii.$(date +%Y%m%d) /home/www-data/firefly-iii
  • ディレクトリ復旧確認
ls -l /home/www-data/firefly-iii

ファイル一式があり、www-dataが所有者になっていること

切り戻し反映・確認

  • Webサービス再起動
sudo systemctl restart apache2.service
  • Webサービス再起動確認
systemctl status apache2.service
  • 霧もろし確認
  1. アップデートを行ったfirefly-iiiサイトにブラウザでアクセスします。
  2. ログインできることを確認します。
  3. バージョンが上がっていることを確認します。
  4. 登録操作などができることを確認します。

失敗の要因

これは明白にして単純です。

リリースノートを確認していなかった

に尽きます。LAMP環境で動くからこそ、ミドルウェアのバージョン(この場合はPHP)の必要とするバージョンを確認していなかった自分の落ち度です。

v6.2.0のリリースノートに

Firefly III requires PHP 8.4.

と書かれていることを見落としていました。

切り戻しが迅速だった要因

「切り戻しを前提としていた手順」に助けられました。

  • 作業前にDBのバックアップ
  • 動いていた環境を退避

させる二段構えにより、迅速な切り戻しが可能になりました。

結局のところ、

「自分の確認不足」から来るミスを「自分の確認不足を想定した手順」でカバーした形です。

Ubuntu 22.04でのNextcloudのPHPを8.1→8.2にバージョンアップ。

By

オン 2025年2月7日

カテゴリー: Linux, nextcloud

概要

  • Ubuntu 22.04
  • PHP 8.1
  • Apache 2.4
  • MySQL

環境でNextcloudを30.xの最新版にアップデート後、以下の警告が出ました。

One or more mimetype migrations are available. Occasionally new mimetypes are added to better handle certain file types. Migrating the mimetypes take a long time on larger instances so this is not done automatically during upgrades. Use the command occ maintenance:repair --include-expensive to perform the migrations.

現在、あなたは PHP 8.1.31 を実行しています。PHP 8.1 は Nextcloud 30 では非推奨となっています。Nextcloud 31 では少なくとも PHP 8.2 が必要になる可能性があります。できるだけ早く、PHP グループが提供する公式にサポートされている PHP のバージョンにアップグレードしてください。 詳細については、ドキュメント↗を参照してください。


いくつかの欠落しているオプションのインデックスを検出しました。データベースのパフォーマンスを向上させるために、（Nextcloudまたはインストールされたアプリケーションによって）新しいインデックスが追加されることがあります。インデックスの追加には時間がかかり、一時的にパフォーマンスが低下することがあるため、アップグレード時には自動的には行われません。インデックスが追加されると、それらのテーブルへのクエリが速くなるはずです。インデックスを追加するには、occ db:add-missing-indices コマンドを使用してください。インデックスが不足: "fs_name_hash" テーブル内の "filecache". 詳細については、ドキュメント↗を参照してください。

これに対して対応を行います。

備考

Webサーバの全体的な変更を伴います。作業は慎重に、可能な限り検証環境で試してからの反映を強く推奨します。

ややさっくりしない手順

  1. Nextcloudのメンテナンスモードを有効化します。
  2. Nextcloudで用いているDBのバックアップを取ります。
  3. PHP8.2をインストールします。
  4. PHP8.2の設定を行います。
  5. PHP8.1の無効化とPHP8.2の有効化を行います。
  6. 警告に対する対処を行います。
  7. Nextcloudのメンテナンスモードを無効化します。
  8. 復旧を確認します。

メンテナンスモードを有効化

  • Nextcloudのルートディレクトリ移動
cd /path/to/nextcloud/root/directory && pwd

自分の環境に合わせます。(筆者環境/home/www-data/nextcloud)

  • メンテナンスモード有効化
sudo -u www-data php occ maintenance:mode --on
  • メンテナンスモード確認

運用中のNextcloudのURLにアクセスし、メンテナンスモードであることを確認します。

mysqldumpでバックアップを取得する

  • 作業ディレクトリに移動
cd /hoge && pwd

任意のディレクトリを指定します。

  • DBバックアップ作成
mysqldump -h localhost -u nextcloud -p --no-tablespaces --single-transaction nextcloud > nextcloud_backup.$(date +%Y%m%d).sql

DB名やユーザーは自分の環境に合わせます。

  • DBバックアップ作成確認
ls -la nextcloud_backup.$(date +%Y%m%d).sql

ファイルがあることを確認します。

必要パッケージをインストールします。

  • PHP8.2インストール
sudo aptitude install php8.2

→ 好みでaptitudeを用いています。aptでもOKです。

  • PHPモジュールインストール
sudo aptitude install php8.2-{opcache,pdo,bcmath,calendar,ctype,fileinfo,ftp,gd,intl,json,ldap,mbstring,mysql,posix,readline,sockets,bz2,tokenizer,zip,curl,iconv,phar,xml,dev,imagick,gmp}
  • PHP8.2対応
sudo aptitude install libapache2-mod-php8.2
  • PHP8.1無効化
sudo a2dismod php8.1
  • PHP8.2有効化
sudo a2enmod php8.2
  • Apache再起動
sudo systemctl reload apache2.service
  • PHPアップグレード確認
php -v

表示例PHP 8.2.27 (cli) (built: Jan 2 2025 15:36:15) (NTS)

Nextcloudに併せたPHPの設定を行います。

  • memcacheとAPCuの有効化
cd /etc/php/8.2/cli/conf.d
cat <<- __EOF__ | sudo tee -a /etc/php/8.2/cli/conf.d/10-opcache.ini
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
__EOF__
cat <<- __EOF__ | sudo tee -a /etc/php/8.2/cli/conf.d/20-apcu.ini
[apcu]
apc.enabled=1
apc.shm_size=32M
apc.ttl=7200
apc.enable_cli=1
apc.serializer=php
__EOF__

php.iniバックアップ

sudo cp -pi /etc/php/8.2/apache2/php.ini /path/to/backup/php.ini.$(date +%Y%m%d)

任意のバックアップディレクトリを指定します。(筆者環境/etc/old/)

  • バックアップ確認
diff -u /etc/php/8.2/apache2/php.ini /path/to/backup/php.ini.$(date +%Y%m%d)

差分が存在しないことにより、バックアップが取れていることを確認します。

  • sedによるファイル書き換え
sudo sed -i 's/memory_limit = 128M/memory_limit = 512M/g' /etc/php/8.2/apache2/php.ini

memory_limitを推奨値の512Mに置き換えます。

  • 書き換え後の差分確認
diff -u  /path/to/backup/php.ini.$(date +%Y%m%d) /etc/php/8.2/apache2/php.ini
  • 差分
-memory_limit = 128M
+memory_limit = 512M
  • apache 再起動
sudo systemctl restart apache2.service

Nextcloudの警告解消

  • Nextcloudのディレクトリに移動
cd /path/to/nextcloud/root/directory && pwd

自分の環境に合わせます。

  • DBリペア
sudo -u www-data php8.2 occ maintenance:repair --include-expensive
  • DB追記
sudo -u www-data php8.2 occ db:add-missing-indices
  • メンテナンスモード無効化
sudo -u www-data php8.2 occ maintenance:mode --off

復旧確認

  1. 設定を行ったNextcloudにアクセスします。
  2. メンテナンスモードが解除されていることを確認します。
  3. 管理者権限でアクセスし、管理者設定から上記のエラーやワーニングがないことを確認します。

備考：切り戻し

何か不具合があった場合の切り戻し手順です。上記、メンテナンスモードを有効化してから行ってください。

  • PHP8.2無効化
sudo a2dismod php8.2
  • PHP8.1有効化
sudo a2enmod php8.1
  • Apache再起動
sudo systemctl restart apache2.service
  • PHP切り戻し確認
php -v

→ 8.1に戻っていることを確認します。

  • バックアップしたDBがあることを再確認する
ls -l /hoge/nextcloud_backup.$(date +%Y%m%d).sql

バックアップを行ったディレクトリを指定します。

head -100 /hoge/nextcloud_backup.$(date +%Y%m%d).sql

ファイルがあること、平文で読めることを確認します。

  • 管理者権限でMySQLにログインする
mysql -u root -p
  • 対象のDBを確認する
SHOW DATABASES;

nextcloudが動いているDBであることを再確認してください。

  • 本当に削除すべきDBかを確認する
SELECT COUNT(*) FROM nextcloud.oc_users;
  • 不具合が発生したDBを削除する

二回ほど深呼吸して、落ち着いて作業しましょう。

DROP DATABASE nextcloud;
  • DBを再作成する
CREATE DATABASE IF NOT EXISTS nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
  • MySQLから抜ける
EXIT
  • DB復元
mysql -h localhost -u nextcloud -p nextcloud < /hoge/nextcloud_backup.$(date +%Y%m%d).sql

この後、メンテナンスモードを解除して、以前と同じ状態か確認します。

作業後：バックアップDBの削除

平文でSQLがサーバ上にあるのは危険な状態なので、以下の措置を執ります。

  • 作業ディレクトリに移動
cd /hoge && pwd

バックアップを行ったディレクトリを指定します。

  • DBバックアップ確認
ls -la nextcloud_backup.$(date +%Y%m%d).sql

ファイルがあることを確認します。

  • バックアップしたDBの削除
shred -u nextcloud_backup.$(date +%Y%m%d).sql
  • DBバックアップ削除確認
ls -la nextcloud_backup.$(date +%Y%m%d).sql

ファイルが無いことを確認します。

Webサーバに複数のWebサイトを運用する際の確認・Apache再起動スクリプト。

By

オン 2025年2月6日

カテゴリー: Linux

Webサーバ1つに複数のサイトを運用している場合、

「バーチャルホストでどんなWebサービスが動いているか？」「設定変更後の構文は正しいか？」「Webサービス再起動後、ステータスは正常か？」

を確認したい場合は多々あります。

それを解決するためのスクリプトがこちらです。

環境

  • Ubuntu 24.04
  • Apache 2.4
  • バーチャルホストはデフォルトの/etc/apache2/site-enabledを踏襲

スクリプト内容

  • apache2-check.sh
#!/bin/bash

# サイト設定ディレクトリ
SITES_DIR="/etc/apache2/sites-enabled"

# スクリプトを root ユーザーで実行しているかチェック
if [ "$EUID" -ne 0 ]; then
    echo "このスクリプトは root 権限で実行する必要があります。"
    exit 1
fi

# 1. /etc/apache2/sites-enabled 配下のファイルとURL表示
echo "==== 有効なサイト設定ファイル ===="
if [ -z "$(ls -A "$SITES_DIR")" ]; then
    echo "サイト設定が存在しません。"
else
    for site in "$SITES_DIR"/*; do
        echo "設定ファイル: $(basename "$site")"

        # ServerNameとServerAliasを正規化して抽出
        entries=$(grep -hi -E "ServerName|ServerAlias" "$site" | sed -E 's/^[[:blank:]]+//;s/[[:blank:]]*#.*//' | awk '{
            original_directive = $1
            directive = tolower(original_directive)
            proper_directive = (directive == "servername") ? "ServerName" : 
                              (directive == "serveralias") ? "ServerAlias" : original_directive

            for (i=2; i<=NF; i++) {
                domain = tolower($i)
                sub(/[;,]*$/, "", domain)
                gsub(/^[[:blank:]]+|[[:blank:]]+$/, "", domain)
                if (domain) {
                    printf "%s %s\n", proper_directive, domain
                }
            }
        }' | sort -u)

        if [ -z "$entries" ]; then
            echo "  ※ ServerName/ServerAliasが定義されていません"
        else
            echo "$entries" | sed 's/^/  /'
        fi
        echo
    done
fi

echo "=================================="

# 2. Apache構文チェック
echo "構文チェック中..."
if ! apachectl configtest; then
    echo "構文エラーが検出されました。Apacheを再起動できません。"
    exit 1
fi
echo "構文チェック完了: 問題ありません。"

# 3. Apache再起動の確認
read -p "Apacheを再起動しますか？ (y/n): " CONFIRM
if [[ "$CONFIRM" =~ ^[Yy]$ ]]; then
    echo "Apacheを再起動します..."
    if ! systemctl restart apache2; then
        echo "Apacheの再起動に失敗しました。"
        exit 1
    fi
    echo "Apacheが正常に再起動されました。"

    # 4. Apacheステータス確認
    echo "==== Apacheステータス ===="
    systemctl status apache2 --no-pager
else
    echo "Apacheの再起動はキャンセルされました。"

保存後、

sudo chmod +x apache2-check.sh

として、

sudo bash apache2-check.sh

を実行することで、

  • /etc/apache2/site-enabled/ 配下のコンフィグからWebサイト名を表示
  • 設定ファイルの構文を確認
  • Webサービス再起動の確認
  • Webサービス再起動後のステータスの表示

を一括で行うことができます。

使った後

このスクリプトを使うことで、Apacheの設定確認と再起動作業が大幅に効率化されました。

  • 設定ファイルの一覧表示: どのサイトが有効になっているか一目で確認できるため、サイト管理がしやすくなりました。
  • ServerName/ServerAliasの抽出: 各サイトの設定内容を簡単に確認できるため、設定ミスを防ぐのに役立ちました。
  • 構文チェック: 設定変更後の構文エラーチェックを確実に行えるため、Webサイトの停止時間を減らすことができました。
  • 再起動手順の簡略化: 再起動時の確認メッセージがあるため、誤操作を防ぐことができます。

シェルスクリプト天気予報ツールの改良：機能追加とエラー処理の強化

By

オン 2025年1月25日

カテゴリー: Linux

以前作成したコマンドラインでの天気予報ツールについて改良を行いました。

修正前のスクリプト

まず、修正前のスクリプトはこちらです。

#!/bin/bash

# 都市名をコマンドライン引数から取得するか、ユーザーに尋ねる
city=$1
if [[ -z "$city" ]]; then
  echo "都市名を入力してください:"
  read city
  if [[ -z "$city" ]]; then
    echo "都市名が入力されませんでした。"
    exit 1
  fi
fi

# ansiweatherコマンドを実行して天気情報を表示
echo "ansiweatherの情報:"
if ! ansiweather -l "$city"; then
  echo "ansiweatherから情報を取得できませんでした。"
fi

# curlコマンドを使用してwttr.inから天気情報を表示
echo "wttr.inの情報:"
if ! curl -s "wttr.in/${city}?lang=ja"; then
  echo "wttr.inから情報を取得できませんでした。"
fi

このスクリプトは、コマンドライン引数で都市名を受け取るか、引数がなければユーザーに都市名の入力を求め、ansiweatherとcurlを使って天気情報を取得し表示します。

問題点

  • エラー処理が不十分: 都市名が入力されない場合のエラー処理はありますが、ansiweatherやcurlコマンドが失敗した場合の処理は警告メッセージを表示するだけです。
  • 入力検証がない: 空白のみの入力など、不正な入力に対する検証が行われていません。
  • 複数都市に対応していない: コマンドライン引数で複数の都市を指定することができません。
  • コードの再利用性がない: 処理がまとまっていないため、コードの再利用が難しいです。

修正後のスクリプト

そこで、以下のように修正です。

#!/bin/bash

# 都市名を取得する関数
get_city() {
  if [[ -z "$1" ]]; then
    read -p "都市名を入力してください: " city
    if [[ -z "$city" ]]; then
      echo "エラー: 都市名が入力されていません。" >&2
      return 1
    fi
  else
    city="$1"
  fi

  # 入力値の検証
  if [[ "$city" =~ ^[[:space:]]+$ ]]; then
    echo "エラー: 都市名に空白のみが入力されています。" >&2
    return 1
  fi
  return 0
}

# 天気情報を表示する関数
show_weather() {
  local city="$1"

  echo "--------------------"
  echo "ansiweatherの情報 (${city}):"
  if ! ansiweather -l "$city"; then
    echo "警告: ansiweatherから情報を取得できませんでした。" >&2
  fi

  echo "--------------------"
  echo "wttr.inの情報 (${city}):"
  if ! curl -fs --connect-timeout 5 "wttr.in/${city}?lang=ja"; then
    echo "警告: wttr.inから情報を取得できませんでした。" >&2
  fi
}

# メイン処理
if [[ $# -eq 0 ]]; then
    if ! get_city; then
        exit 1
    fi
    show_weather "$city"
elif [[ $# -gt 0 ]]; then
    for city in "$@"; do
        if ! get_city "$city"; then
            echo "$city の処理をスキップします。" >&2
            continue
        fi
        show_weather "$city"
    done
fi

exit 0

修正の意図と変更点

  • 関数化: get_city()関数とshow_weather()関数に処理を分割し、コードの可読性と再利用性を向上させました。
  • エラー処理の改善:
  • get_city()関数内で都市名が入力されない場合や空白のみが入力された場合にエラーメッセージを出力し、終了ステータスを返しています。エラーメッセージは標準エラー出力(>&2)に出力することで、通常の出力と区別しています。
  • show_weather()関数内でansiweatherやcurlコマンドが失敗した場合に警告メッセージを標準エラー出力に出力するように変更しました。
  • 入力検証の追加: get_city()関数内で空白のみの入力に対する検証を追加しました。
  • 複数都市への対応: コマンドライン引数で複数の都市を指定できるように変更しました。forループを使って、それぞれの都市に対して天気情報を取得し表示します。
    ./script Narita Londonとすることで、出発地と目的地の天気を同時に示すことができます。
  • curlコマンドのオプション変更: curl -sに加えて-f（エラー時にHTTPステータスコードを返す）と--connect-timeout 5（接続タイムアウトを5秒に設定）を追加し、より堅牢な処理を実現しました。

修正後に加わった挙動。

  • コマンドライン引数で複数の都市を指定して実行できるようになりました。例：./script.sh Osaka Kyoto
  • 都市名が入力されない場合や空白のみが入力された場合、エラーメッセージが表示されるようになりました。
  • ansiweatherやcurlコマンドが失敗した場合、警告メッセージが標準エラー出力に出力されるようになりました。
  • curlコマンドのタイムアウトが設定されたため、ネットワークの問題などで応答がない場合に処理が止まるのを防ぐことができます。

Redmineのかんばんプラグインの差し替えメモ。

By

オン 2025年1月23日

カテゴリー: Linux, redmine

概要

Redmineのプラグインをかんばんからダッシュボードプラグインに差し替えたときのメモです。

環境

  • Ubuntu 24.04
  • Redmine 5.1
  • MySQL 8
  • Ruby 3.2
  • Apache 2.4

さっくりとした手順

  1. DBのバックアップ
  2. 既存のかんばんプラグイン削除
  3. ダッシュボードプラグインインストール
  4. 動作確認

DBバックアップ

  • 作業ディレクトリ移動
cd /hoge && pwd

任意の作業ディレクトリに移動

  • DBバックアップ
mysqldump -h localhost -u redmine -p --no-tablespaces --single-transaction redmine > redmine_backup.$(date +%Y%m%d).sql
  • バックアップ確認
view redmine_backup.$(date +%Y%m%d).sql

Redmine kanbanのアンインストール (退避)

  • ディレクトリ移動
cd /path/to/redmine/root/directory/plugins && pwd
  • kanbanプラグインの退避
sudo mv kanban /path/to/backup/directory/kanban_org_$(date +%Y%m%d)
  • 退避確認
ls -ld /path/to/backup/directory/kanban_org_$(date +%Y%m%d)
  • Webサービス再起動
sudo systemctl restart apache2.service && echo $?

→ 0を確認

Dashboardプラグインのインストール

  • git clone
sudo -u www-data git clone https://github.com/jgraichen/redmine_dashboard
  • clone 確認
ls -ld redmine_dashboard
  • Redmineルートディレクトリに移動
cd /path/to/redmine/root/directory && pwd
  • bundle install
sudo -u www-data bundle install --without development test
  • DBマイグレーション
sudo -u www-data bundle exec rake redmine:plugins:migrate RAILS_ENV=production
  • Webサービス再起動
sudo systemctl restart apache2.service && echo $?

→ 0を確認

確認

  1. Redmineに管理者権限でログイン
  2. 管理>プラグインにRedmine Dashboard pluginがあることを確認
  3. 任意のプロジェクト＞設定で「ダッシュボード」を有効化して保存。
  4. プロジェクトのタブにダッシュボードが表示されること、自分が担当するチケットをドラッグアンドドロップで表示されることを確認

Railsのハマり案件。状況収束。

By

オン 2025年1月18日

カテゴリー: Linux

昨日のこの案件は無事に解決。

対処

原因が自分のRails/Rubyによるものが明らかだったので、それぞれの入れ直しです。

Rubyアンインストール

sudo apt remove --purge ruby ruby-dev rubygems
apt autoremove

として、関連のパッケージを全て削除。設定は特にしていなかったのが幸いしました。

Ruby 再インストール

sudo aptitude install ruby libruby ruby-dev libmysqlclient-dev
sudo aptitude install libapache2-mod-passenger

gemで関連パッケージインストール

sudo gem install bundler racc mysql2

apache再起動

sudo systemctl restart apache2.service && echo $?

→ 0が返ってきたので反映もOK。

後はbundle installもDBマイグレーションも無事に通るようになりました。

Railsのハマり案件。状況発生。

By

オン 2025年1月17日

カテゴリー: Linux, redmine

前に見たことがないエラーにとっ捕まったため、状況をメモしておきます。

環境

  • Ubuntu 24.04
  • Ruby 3.2

何が起きているか

Redmineの検証のため、新たに5.1を立てています。

  1. SVNでチェックアウト
  2. DBなどを作成
  3. database.ymlにDB情報を追記
 sudo -u www-data bundle exec rake generate_secret_token

実行後、

rake aborted!
NameError: uninitialized constant ActiveSupport::LoggerThreadSafeLevel::Logger (NameError)

    Logger::Severity.constants.each do |severity|
          ^^^^^^^^^^
/home/www-data/hideout/vendor/bundle/ruby/3.2.0/gems/activesupport-6.1.7.10/lib/active_support/logger_thread_safe_level.rb:16:in `<module:LoggerThreadSafeLevel>'
/home/www-data/hideout/vendor/bundle/ruby/3.2.0/gems/activesupport-6.1.7.10/lib/active_support/logger_thread_safe_level.rb:9:in `<module:ActiveSupport>'
/home/www-data/hideout/vendor/bundle/ruby/3.2.0/gems/activesupport-6.1.7.10/lib/active_support/logger_thread_safe_level.rb:8:in `<top (required)>'
<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:38:in `require'
<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:38:in `require'
/home/www-data/hideout/vendor/bundle/ruby/3.2.0/gems/activesupport-6.1.7.10/lib/active_support/logger_silence.rb:5:in `<top (required)>'
<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:38:in `require'
<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:38:in `require'
/home/www-data/hideout/vendor/bundle/ruby/3.2.0/gems/activesupport-6.1.7.10/lib/active_support/logger.rb:3:in `<top (required)>'
<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:38:in `require'
<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:38:in `require'
/home/www-data/hideout/vendor/bundle/ruby/3.2.0/gems/activesupport-6.1.7.10/lib/active_support.rb:29:in `<top (required)>'
<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:38:in `require'
<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:38:in `require'
/home/www-data/hideout/vendor/bundle/ruby/3.2.0/gems/railties-6.1.7.10/lib/rails.rb:7:in `<top (required)>'
<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:38:in `require'
<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:38:in `require'
/home/www-data/hideout/config/application.rb:5:in `<top (required)>'
<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:38:in `require'
<internal:/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb>:38:in `require'
/home/www-data/hideout/Rakefile:5:in `<top (required)>'
/home/www-data/hideout/vendor/bundle/ruby/3.2.0/gems/rake-13.2.1/exe/rake:27:in `<top (required)>'
(See full trace by running task with --trace)

が発生。そのため、DBマイグレーションも通らないという状況。

この問題はやっかいそうなので、まずは事象が発生したという事実だけメモをします。

RedmineにLightbox2プラグインをインストール。

By

オン 2024年12月29日

カテゴリー: Linux, PC

それなりに読まれていると自負している『ライザのアトリエ3』の攻略記事「有料DLC：ロスカ島」の文献探しの記事にも使われているLightbox2プラグインのインストール方法です。

メールアドレスの登録が必要なものの無料で利用できます。

  • 画像を拡大表示できるライトボックス機能。
  • スライドショー形式で画像を順に閲覧可能。

の2つが強力なため、Remdineで画像を多用する際にも大いに役立ちます。

動作環境

  • Ubuntu 24.04
  • Apache 2.4
  • Ruby 3.2

手順

Redmine Xでのパッケージ取得

公式サイトよりメールアドレスを登録します。

登録後、送られてくるメール内に記載されているURLからパッケージを取得。

任意の方法でサーバ内にアップロードします。

パッケージの展開

  • アップロードしたファイルがあるディレクトリに移動
cd /hoge && pwd
  • パッケージの所有者変更
sudo chown www-data:www-data redmine_x_lightbox2.zip

Redmineの実行ユーザーに合わせます。

パッケージの展開と配置

  • パッケージ配置
sudo -u www-data unzip redmine_x_lightbox2.zip -d /path/to/redmine/plugins

自分のRedmine環境に合わせます。

  • パッケージ配置確認
ls -ld /path/to/redmine/plugins/redmine_x_lightbox2

ディレクトリがあることを確認します。

プラグインインストール

  • Redmineルートディレクトリに移動
cd /path/to/redmine && pwd

自分の環境に合わせます。

  • bundle install
sudo -u www-data bundle install
  • DBマイグレーション
sudo -u www-data bundle exec rake redmine:plugins:migrate RAILS_ENV=production
  • Apache再起動
sudo systemctl restart apache2.service && echo $?

返値が0であることを確認します。

  • Apache再起動後のステータス確認
systemctl status apache2.service

active(running)を確認します。

動作確認

  1. 画像を添付 任意のチケットまたはWikiに画像を添付します。
  2. 画像をクリック 添付された画像をクリックし、ポップアップ表示が正常に動作することを確認します。
  3. ナビゲーションの確認 表示された画像を左右に切り替え、スライドショー機能が動作していることを確認します。

Firefly-III 1年間の検証結果と運用レビュー

By

オン 2024年12月28日

カテゴリー: Firefly III, Linux

オープンソースの家計管理システム「Firefly-III」を使い始めてから1年が経過しました。この1年間の運用を通じて、得られた知見や感想をまとめました。最初に導入した環境や特徴的なポイントについて、振り返ってみます。

環境の構築

最初にインストールした環境は、Ubuntu 20.04にPHP 8.1を使用していましたが、その後、Ubuntu 24.04とPHP 8.3にアップグレードしました。

(インストールのメモはこちら)

構築自体はWordpressの構築実績があれば理解可能で、公式ドキュメントに従うことでスムーズに進みました。特に専門的な知識がなくても、簡単に運用を開始できる点は大きな魅力でした。

入力の簡便さ

家計簿の管理で最も重要なのは、入力の手間をいかに減らすかです。Firefly-IIIでは、サブスクリプションや保険料など、毎月定期的に発生する費用を簡単にコピーして入力できる機能があり、手間を大幅に削減できました。これにより、月ごとの出金管理が非常に楽になりました。

直感的なインターフェース

「Firefly-III」のインターフェースは非常に直感的で、出金、入金、送金というシンプルな3つの取引項目で構成されています。このシンプルさにより、簿記などの知識に乏しくても迷うことなく運用できるようになりました。

視覚的な管理: グラフの活用

「Firefly-III」では、家計の動きをグラフで視覚化できるため、特に大きな支出がある場合に、どのくらいの金額が減るのかが一目で分かります。また、クレジットカードのような未来の引き落としもグラフに表示されるため、前もって支出を把握することができます。

予算管理とモチベーションの向上

予算を設定することで、趣味や娯楽に使うお金の限度を決めることができ、(ある程度の)無駄遣いを防げました。デジタルガジェットの購入やフィギュアの予約などに備えて出費を抑えられるようにもなりました。

また、「Firefly-III」では予算管理以外にもカテゴリー分けができ、食費や日用品などを細かく把握することができました。これにより、家計全体のバランスをよりよく理解できるようになりました。

入出金は極めて有用なライフログ

家計簿をつけることで、いつ、どこで、何に、どれくらい使ったかという行動の記録が残ります。この記録は、単なる金銭的な管理にとどまらず、ライフログとしても非常に有用です。例えば、病院での支出を記録することで、いつ、どの病気にかかったかがわかり、過去の体調管理にも役立ちました。

また、突発的な出来事の際に、どのような出金が発生したかも目の当たりにできました。

旅行時の支出記録

旅行中も「Firefly-III」は大いに役立ちました。どんな店で何を食べたのか、お土産を買ったのかなど、旅行の詳細を記録しておくことで、後から振り返って思い出に浸ることができました。

すべての支出を記録するのは大変

一方で、全ての支出を記録するのはやはり大変です。LINEなどのトークアプリで自分自身にメモを送ることで忘れずに記録していますが、入力ミスや記録漏れが発生することもあり、後で差分をチェックすることが課題として残っています。

とはいえ、自分自身の予算管理のために多少の誤差は許容できる範囲であり、精度向上のための改善は引き続き行っています。

運用に関する課題

「Firefly-III」をサーバーで管理するため、サーバー運用に関する一定の知識が必要です。また、お金の流れという非常にセンシティブな情報を扱うため、慎重な運用が求められます。

データのセキュリティやバックアップについても配慮が必要です。

今後の目標

今後は、「Firefly-III」のタグ機能を活用して、さらに細かく支出のカテゴリーを分けて管理していく予定です。

また、自動的に支出が登録される仕組み（例えばAPIやスマートフォンアプリを活用）を導入することで、手間をさらに減らすことを目指しています。最終的には、資産の流れをより明確に把握し、効果的な予算の策定を行いたいと考えています。

1年間の運用を通じて、Firefly-IIIは家計管理を効率的に行うための強力なツールであることが実感できました。今後も継続して使いながら、より精度の高い予算管理を目指していきたいと思います。

Page 2 of 17

前

次

Powered by WordPress & Theme by Anders Norén