カテゴリー: ガジェット Page 1 of 88

Ubuntu 24.04 aptitude updateエラー対応メモ(aptコマンドのLabel変更にによるパッケージリストの変更)

ちょっとハマったのでメモです。

環境

  • OS: Ubuntu 24.04

発生した問題

sudo aptitude update を実行した際に、特定のPPA (PHPリポジトリ) でエラーが発生し、パッケージリストの更新に失敗しました。
(※筆者の好みでaptitudeを用いています)

エラーメッセージの抜粋:

E: Repository 'https://ppa.launchpadcontent.net/ondrej/php/ubuntu noble InRelease' changed its 'Label' value from '***** The main PPA for supported PHP versions with many PECL extensions *****' to 'PPA for PHP'
E: Failed to download some files
W: https://ppa.launchpadcontent.net/ondrej/php/ubuntu/dists/noble/InRelease を取得できませんでした:
E: 一部のインデックスファイルのダウンロードに失敗しました。無視されたか古いものを代わりに利用しています。

Ubuntu24.04をインストールしたばかりの頃に追加したリポジトリが古くなり、アップグレードができないという状態でした。

対処方法

以下の通りに実施しました。

リポジトリの Label 変更を許可

sudo apt update --allow-releaseinfo-change

変更許可後のupdate

sudo aptitude update

これにより、上記のエラーが解消され、正常にパッケージのアップグレードが成功しました。

Ubuntu 20.04環境でGrowi アップデート (v7.0.11 → v7.2.2) 失敗と MongoDB 切り戻しのメモ。

概要

以下の環境でGrowi v7.0.11 から v7.2.2 へのアップデートを試みたものの、サーバーのCPUハードウェア制約により断念し、データベース (MongoDB) を元の安定バージョンへ切り戻しました。

その時のメモです。

作業前の環境

  • OS: Ubuntu 20.04 LTS (Focal Fossa)
  • Growi: v7.0.11
  • Node.js: v18.20.8
  • MongoDB: v4.4.9

目指したこと

  • まずはMongoDB を Growi v7.2.2 が要求する v6.0 以上へアップデートする。

詰まったところ

Growi v7.2.2 の要求事項確認

  • Node.js: v18 以上のためOK。
  • MongoDB: v6.0 以上が必要だったため、現在の v4.4.9 アップデートが必要。

MongoDB段階的アップデート計画

MongoDB v4.4 から v6.0 へは、段階的なアップグレード (4.4 → 5.0 → 6.0 の順) が推奨されるため、まず MongoDB v5.0 へのアップデートに着手しました。

MongoDB 5.0 のGPGキー追加:

wget -qO - https://www.mongodb.org/static/pgp/server-5.0.asc | sudo apt-key add -

MongoDB 5.0 のリポジトリリストファイル作成:

echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/5.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-5.0.list

パッケージリストの更新:

sudo aptitude update
sudo aptitude upgrade

CPUのAVX命令セット非対応問題の発覚

バージョンアップを確認するため

mongod --version

を実施しましたが、Illegal instruction (コアダンプ) というエラーが発生しました。

調査の結果、MongoDB v5.0 以降ではCPUがAVX (Advanced Vector Extensions) 命令セットをサポートしていることが必須要件となっていることが判明。

grep -q avx /proc/cpuinfo && echo "AVX supported" || echo "AVX not supported"

AVX not supportedと表示されたため、現在のサーバーでは MongoDB v5.0 及びそれ以降のバージョン (v6.0を含む) を動作させることが不可能であると結論。

そのため、目指したMongoDBのアップデートもGrowiのバージョンアップも断念。

MongoDB の切り戻し作業 (v4.4.x へ)

なので、切り戻しを行います。単にバージョンを指定してのインストールはうまくいきませんでした。

というのも依存関係の解決時に libc6 >= 2.34libssl3 (Ubuntu 22.04 Jammy のライブラリ) を要求するエラーが発生したからです。

これは、

/etc/apt/sources.list.d/

ディレクトリに最初のMongoDBのアップデート時のリポジトリが残っていたためです。

不要なMongoDBリポジトリ設定の削除

sudo rm /etc/apt/sources.list.d/mongodb-org-5.0.list
sudo rm /etc/apt/sources.list.d/mongodb-org-6.0.list

インストール済みパッケージのクリーンアップ

sudo aptitude purge mongodb-org mongodb-org-database mongodb-org-database-tools-extra mongodb-org-mongos mongodb-org-server mongodb-org-shell mongodb-org-tools mongodb-database-tools mongodb-mongosh

MongoDB v4.4 用GPGキーの再設定

wget https://www.mongodb.org/static/pgp/server-4.4.asc &&  sudo apt-key add server-4.4.asc
sudo aptitude update

MongoDB v4.4.x のインストール

apt-cache policy mongodb-org-server

インストール候補がMongoDB v4.4系であることを確認。

sudo aptitude install mongodb-org-server=4.4.29 mongodb-org-shell=4.4.29 mongodb-org-tools=4.4.29` 

動作確認

mongod --version

以下を確認。

db version v4.4.29
Build Info: {
    "version": "4.4.29",
    "gitVersion": "f4dda329a99811c707eb06d05ad023599f9be263",
    "openSSLVersion": "OpenSSL 1.1.1f  31 Mar 2020",
    "modules": [],
    "allocator": "tcmalloc",
    "environment": {
        "distmod": "ubuntu2004",
        "distarch": "x86_64",
        "target_arch": "x86_64"
    }
}
systemctl status mongod

active(running)を確認。

この切り戻しにより、Growi が正常に動作することを確認しました。

MongoDB パッケージの固定 (Hold)

sudo aptitude hold mongodb-org-server mongodb-org-shell mongodb-org-tools

として、不要なアップデートを防ぐ措置を執りました。

結論

そもそもの問題として、いくらローカル環境とは言え、既にEOLを迎えているUbuntu20.04の延命措置を執ろうとしたことが誤りです。

また、OSのバージョンアップをしたとしてもCPUが対応していないと言うことが判明したことは、ハードウェアのリプレースも必要だという現実も突きつけられました。

いい機会なので、自宅のローカル環境の見直しを図ります。

Nextcloudのアプリ、Memoriesの警告に対処。(ffmpegインストール)

Nextcloudのアルバムアプリ、Memoriesのエラーに対処します。

環境

  • Nextcloud 31.0.4
    • Memories 7.5.2
  • Ubuntu 22.04
  • Apache 2.4
  • php 8.2
  • MySQL 8

事象

Nextcloudの管理画面、Memoriesの項目で、

ffmpeg preview binary not found. Thumbnail generation may not work for videos.

と出たので、この警告メッセージに対処します。

意味としては

  • Nextcloudがサムネイルを作成する際にffmpegを利用するが見つからなかった。
  • 特に、動画のサムネイルがうまく表示されない。

対処

Nextcloudがインストールされているサーバのターミナル(SSH接続)で実施します。

  • ffmpegインストール

※筆者の好みでaptitudeを用いています。

sudo aptitude update
sudo aptitude install ffmpeg
  • インストール確認
which ffmpeg

→ 上記方法であれば、/usr/bin/ffmpegと表示されます。

対処後の確認

再度、Nextcloudの管理画面からMemoriesへと進み、上記の警告が消えていることを確認します。

そこで、その下にあるトグルを変更していきます。以下、オンにした方がいい項目です。

  • Images (JPEG, PNG, GIF, BMP):一般的なイメージ画像
  • HEIC (Imagick): Appleデバイスで利用するイメージ画像
  • Videos (ffmpeg): 動画(サーバ上にこれが無いために警告が出ていたため)

これらを設定後、Memoriesアプリでサムネイルが作成されているかを確認します。

手動でのサムネイル生成

※ファイル数によっては時間がかかり、サーバのリソースをそれなりに消費するため、負荷が少ない時間帯で行った方が望ましいです。

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

※筆者環境 /home/www-data/nextcloud

  • occによるサムネイル生成
sudo -u www-data php occ preview:generate-all

sudo -u www-dataの実行権限については自分の環境に合わせます。(RockyLinux等のRHEL系ディストリビューションはapachehttpdなどです)

NextcloudのWebからのアップデート失敗時の対処。(コマンドラインによるNextcloudのアップデート)

NextcloudはWebからアップデートが行えますが、

  • バックアップ
  • ダウンロード
  • 整合性チェック

等で失敗し、リトライをしてもまた同じところで詰まるというケースが非常に多いです。

(例ではDownloading)で失敗しています。

そこで、その回避策(というかより安定している手段)として、コマンドラインによるアップデートを実施します。

作業確認環境

筆者環境です。マイナーバージョンなどは実施環境に合わせます。

  • Ubuntu 22.04
  • Nextcloud 31.03 → 31.04へのアップグレード
  • Apache (ユーザwww-dataで実行)
  • MySQL
  • php 8.2.28

さっくりとした手順

  1. メンテナンスモードを有効化します。
  2. Nextcloud一式のバックアップを行います。
  3. Nextcloudで用いているDBのバックアップを取ります。
  4. コマンドラインでアップデートがあるかのチェックを行います。
  5. コマンドラインでNextcloudのアップグレードを行います。
  6. バージョンアップを確認します。

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

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

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

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

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

Nextcloudのバックアップ

  • Nextcloudの一式バックアップ
sudo -u www-data cp -pir /home/www-data/nextcloud /path/to/backup/directory/nextcloud.$(date +%Y%m%d)
  • 退避前、退避先、バックアップ先のアクセス権限などはそれぞれ自分の環境に合わせます。
  • このバックアップ方法はあくまでも例です。
  • ※プログラムによっては非常に膨大なファイル数が予想されます。適切なバックアップ手段を考慮してください。
  • vpsなどで動かしている場合は、スナップショットを撮っておいて、後から復元した方が確実です。

  • バックアップ確認
ls -l /path/to/backup/directory/nextcloud.$(date +%Y%m%d)

退避先にディレクトリファイル一式があることを確認します。

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

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

Nextcloudのアップグレードチェック

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

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

  • occコマンドによるアップグレード確認
sudo -u www-data php occ update:check

表示例

Nextcloud 31.0.4 is available. Get more information on how to update at https://docs.nextcloud.com/server/31/admin_manual/maintenance/upgrade.html.
Update for side_menu to version 5.1.0 is available.
Update for spreed to version 21.0.4 is available.

と出たので、アップグレードはコマンドラインでも有効です。

コマンドラインによるアップグレード

sudo -u www-data php occ upgrade
  • 新しいバージョンのダウンロード
  • コードの展開
  • データベーススキーマの更新
  • アプリの更新

を一括で行ってくれるコマンドです。

Keep maintenance mode active? [y/N] 

nでメンテナンス画面から抜けます。

Webでのアップグレード確認

管理者権限でNextcloudにブラウザでアクセスし、

  1. 管理画面からアップグレードされていること
  2. 他の機能が使えること

を確認できれば成功です。


切り戻し

失敗したときの手順です。再度、バックアップ一式があることを確認してください。なお、失敗したことを前提にしているため、再度の切り戻しは一切考慮しません。

  • アップグレードに失敗したファイル一式の削除
sudo rm -rf /home/www-data/nextcloud 
  • バックアップからの切り戻し
sudo mv /path/to/backup/directory/nextcloud.$(date +%Y%m%d) /home/www-data/nextcloud
  • 管理者権限で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

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

sudo -u www-data php occ maintenance:mode --off

作業後:バックアップ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

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

DBのデータ容量を確認するSQL文

概要

MySQLの運用時、「このDBはどのぐらいのディスク容量を消費しているのか?」は日々のメンテナンスのみならずバックアップや移行などにも気になるところ。

そんな確認方法についてのTIPSです。

環境

以下のサーバで動作を確認しました。

  • Ubuntu 22.04 / Ubuntu 24.04
  • MySQL 8.0.x

前提

  • MySQLターミナルで操作します。
  • そのDBへのSELECT権限を持っていなければ操作できません。

操作

  • MySQLログイン
mysql -u user -p

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

  • DB確認
SHOW DATABASES;

ここで、参照したいDB名を確認します。

  • SQL実行
SELECT
    table_schema AS 'データベース名',
    SUM(data_length + index_length) AS '合計サイズ(バイト)',
    SUM(data_length) AS 'データサイズ(バイト)',
    SUM(index_length) AS 'インデックスサイズ(バイト)',
    -- 人が読みやすいようにメガバイト(MB)やギガバイト(GB)でも表示
    ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS '合計サイズ(MB)',
    ROUND(SUM(data_length) / 1024 / 1024 / 1024, 2) AS '合計サイズ(GB)'
FROM
    information_schema.TABLES
WHERE
    table_schema = '調べたいデータベース名' -- ここにサイズを知りたいデータベース名を入力してください
GROUP BY
    table_schema;
  • 表示例
+-----------------------+----------------------------+-------------------------------+----------------------------------------+---------------------+---------------------+
| データベース名        | 合計サイズ(バイト)         | データサイズ(バイト)          | インデックスサイズ(バイト)             | 合計サイズ(MB)      | 合計サイズ(GB)      |
+-----------------------+----------------------------+-------------------------------+----------------------------------------+---------------------+---------------------+
| nextcloud             |                  432685056 |                     163741696 |                              268943360 |              412.64 |                0.15 |
+-----------------------+----------------------------+-------------------------------+----------------------------------------+---------------------+---------------------+
1 row in set (0.01 sec)

この例では、DB「nextcloud」に対して412MBのデータを消費していることが明らかになりました。

Ubuntu 24.04にNextcloudをインストール

Ubuntu 20.04もEOLを迎えたため、こちらのバージョンでのインストールを確認です。

前提

以下が稼働済みです。

  • OS: Ubuntu 24.04 LTS
  • データベース: MySQL 8.0 (Ubuntu 24.04 の標準リポジトリで利用可能)
  • Webサーバー: Apache 2.4 (Ubuntu 24.04 の標準リポジトリで利用可能)
  • ドメインと証明書: Nextcloud を設定するドメイン名と、それに対応する有効なSSL/TLSサーバー証明書(例: Let's Encrypt などで取得したもの)が準備されていること。

さっくりとした手順

※SSHログインし、ターミナルでの操作を行います。

  1. 必要なPHPパッケージ(PHP 8.3 と関連モジュール)をインストールします。
  2. PHPの設定(メモリ制限、OPcache、APCu)を行います。
  3. Nextcloud用のデータベースとユーザーを作成します。
  4. Nextcloudの最新版プログラムをダウンロードし、適切な場所に配置します。
  5. Nextcloudを動かすためのApache設定ファイルを設定します。
  6. Webブラウザで設定を行います。

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

  • PHP・モジュールインストール
sudo aptitude install php8.3 php8.3-fpm php8.3-opcache php8.3-pdo php8.3-bcmath php8.3-calendar php8.3-ctype php8.3-fileinfo php8.3-ftp php8.3-gd php8.3-intl php8.3-json php8.3-mbstring php8.3-mysql php8.3-posix php8.3-readline php8.3-sockets php8.3-bz2 php8.3-tokenizer php8.3-zip php8.3-curl php8.3-iconv php8.3-xml php8.3-imagick php8.3-gmp php8.3-apcu libapache2-mod-php8.3
補足
  • php8.3-fpm: Apache で mod_php の代わりに PHP-FPM を使用する場合にインストールします。(今回は libapache2-mod-php8.3 を使っていますが、FPMの方がパフォーマンスや分離の点で推奨される場合もあります)。もしFPMを使う場合はApacheの設定も変わります。この手順ではlibapache2-mod-php8.3(mod_php)を前提とします。
  • php8.3-ldap: LDAP/AD連携を使用する場合にインストールしてください。
  • php8.3-dev: 通常の運用には不要ですが、PECLなどで拡張機能をコンパイルする場合に必要です。
  • Apache再起動
sudo systemctl restart apache2.service
  • PHPインストール確認
php -v

表示例:PHP 8.3.n

PHPの設定を行います。

Nextcloud のパフォーマンスと安定性のために、PHPの設定を調整します。

  • memcacheとAPCuの有効化
cd /etc/php/8.3/cli/conf.d

以下のファイルのように修正します。ない場合は、以下のように追記します。

cat <<- __EOF__ | sudo tee -a /etc/php/8.3/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.3/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.3/apache2/php.ini /path/to/backup/php.ini.$(date +%Y%m%d)

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

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

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

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

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

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

NextcloudのDBを作成します。

  • MySQLにroot権限でログイン
mysql -u root -p
  • MySQLユーザ追加
CREATE DATABASE IF NOT EXISTS nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER 'nextcloud'@'localhost' IDENTIFIED WITH mysql_native_password BY 'YOUR_STRONG_PASSWORD';
GRANT ALL PRIVILEGES ON nextcloud.* TO 'nextcloud'@'localhost';
FLUSH PRIVILEGES;
EXIT;

★重要: YOUR_STRONG_PASSWORD は必ず推測されにくい強固なパスワードに変更してください。

IDENTIFIED WITH mysql_native_password BY は MySQL 8.0 で推奨される認証方式の一つです。

  • 追加したNextcloud用ユーザでログイン
mysql -u nextcloud -p

設定したパスワードでログインできることを確認します

  • DB作成確認
SHOW DATABASES;

作成したデータベースnextcloudがあることを確認します

EXIT;

Nextcoludのプログラムを配置します。

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

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

  • ファイル取得
wget https://download.nextcloud.com/server/releases/latest.zip
unzip latest
  • Web公開用ディレクトリにファイル一式を移動
sudo mv nextcloud /home/www-data/

自分の環境に合わせます。(筆者はファイルサーバとして運用するので、/home領域に設置しました)

  • 所有者変更
sudo chown -R www-data:www-data /home/www-data/nextcloud

Apacheの設定ファイルを作成します。

  • ログディレクトリの作成
sudo mkdir /var/log/nextcloud

環境に合わせます。

  • ディレクトリの所有者変更
sudo chown www-data:www-data /var/log/nextcloud
  • nextcloud用の設定ファイル作成
  • 【】部分は自分の環境に合わせます。
cat <<- __EOF__ | sudo tee -a /etc/apache2/sites-available/nextcloud.conf
<VirtualHost *:80>
    servername 【hoge.example.com】
    # ドメイン名を指定します
    RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# HTTPアクセスを強制的にHTTPSにリダイレクトします
</VirtualHost>

<VirtualHost *:443>
    ServerName 【hoge.example.com】
    # ドメイン名を指定します
    CustomLog /var/log/nextcloud/nextcloud_access.log combined
    ErrorLog /var/log/nextcloud/nextcloud_error.log
    DocumentRoot 【/home/www-data/nextcloud】
    # 上記手順で指定したディレクトリです
    <Directory 【/home/www-data/nextcloud】>
    # 上記手順で指定したディレクトリです
        Options -MultiViews
        AllowOverride All
        Require all granted
    </Directory>

#SSL設定
  SSLEngine on
    Protocols h2 http/1.1
  # SSLを有効化します

SSLCertificateFile 【/etc/certs/hoge.example.com.crt】
# SSL証明書を指定します
SSLCertificateKeyFile 【/etc/private/hoge.example.com.key】
# 秘密鍵を指定します

# SSLCACertificateFile 【/etc/certs/hoge.example.com.CA.crt】
# 中間証明書が発行元から別ファイルで提供されている場合は、この直上をコメントアウトして中間証明書を指定します

    # 推奨されるSSL/TLS設定 (Mozilla Intermediate Compatibility)
    SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
    SSLHonorCipherOrder     on
    SSLCompression          off
    SSLSessionTickets       off # PFSを強化する場合

    # OCSP Stapling (パフォーマンス向上)
    SSLUseStapling On
    SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

    # セキュリティヘッダー
    Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
    Header always set Referrer-Policy "no-referrer"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Permitted-Cross-Domain-Policies "none"

</VirtualHost>
__EOF__
  • Apache設定ファイル反映
sudo a2ensite nextcloud.conf
  • 設定ファイルのコンフィグ確認
sudo apache2ctl configtest

Syntax OKを確認します

  • Apache再起動
sudo systemctl restart apache2.service

ブラウザ上でNextcloudのセットアップを行います。

  • ブラウザでアクセス

ブラウザで、

http://設定したドメイン

にアクセスし、以下を確認してください。

  • 以下のセットアップ画面が出ること。
  • httpがhttpsとなっていること。

以下を入力して「インストール」をクリックします。

  • ユーザ名:
  • 管理者のユーザ名
  • パスワード:
  • 管理者パスワード
  • データベースのユーザー名
  • 作成したユーザー名(nextcloud)
  • データベースのパスワード
  • 設定したデータベースのパスワード
  • データベース名
  • 作成したデータベース(nextcloud)
  • データベースのホスト名
  • localhost:3306
    • (MySQLのポート番号)

推奨アプリのインストールに関しては、好みでスキップかインストールを行ってください。

インストールが完了したら、以下のような画面が出ます。

『150日の亡霊』顛末記-Wasabiクラウドストレージの理解不足による重課金の罠-(長文)

概要

筆者は

  • AWS Lightsail → Web Arena Indigo
  • Wasabiクラウドストレージ

で、各種Webサービスを個人的に運用しています。これまで両者は安価で性能も満足いくものだったのですが
2024年11月~2025年3月に至るまで、Wasabiクラウドストレージの高額請求がありました。(解決は2025年4月)

今回、この失敗を記すことで自分と同じような状況に陥りそうな人への注意喚起並びに「こういう落とし穴もあるんだ」という参考にしていただければ幸いです。

時間がない人向けの要約

  1. Wasabiクラウドストレージの仕様を理解していなかったため通常の20倍以上の請求が届いた。
  2. 原因はクラウドストレージの超・超高頻度のファイル書き換え(削除&作成)が発生したため。
  3. この原因を作ったのはGrowi(MongoDB)とNextcloud
  4. これらサービスを停止したものの「最低保持期間ポリシー」の存在により、自動的に発生したファイル書き換えの分の課金が発生した。
  5. 完全解決に至るまでの合計請求額は5ヶ月で544.93$!(2025/04/16でのレート換算で77624.73円)
  6. 教訓
  • クラウドストレージの仕様(特に料金体系)は見ておくこと。
  • クラウドストレージはネットにあるSSDではない。
  • 相性のいい運用方法と相性最悪の運用方法がある。
  • 新しいWebサービスを稼働したらきちんと請求を見ること。
  • 「今まで大丈夫だったからと言って次も大丈夫」ではない。
  1. ビジネスでこれをやってたら請求額はこの数十倍も普通にあった。個人での失敗だからこそ「笑えない笑い話」で済んだ。

Ubuntu oneアカウントの紐付けとESM Apps(個人利用)の適用

概要

Ubuntuサーバにログインすると、以下のようなメッセージが出てきます。

11 additional security updates can be applied with ESM Apps.
Learn more about enabling ESM Apps service at https://ubuntu.com/esm

これはUbuntu Pro (以前のExtended Security Maintenance, ESM) に関連するメッセージです。

Ubuntu Proは、UbuntuのLTS (Long Term Support) リリースに対して、標準のサポート期間(通常5年)を超えて、さらに5年間のセキュリティアップデートを提供する有償サービスです。

ですが、個人利用であれば、最大5台までのマシンで Ubuntu Pro を無償で利用できます。

筆者が公開しているRedmineやBookStackは

  • 非商用利用
  • 広告無し

なので、上記、個人利用に適用。このESM Appsを有効化していきます。

前提

ESM AppsはLTSバージョンのUbuntuに適用されます。

cat /etc/lsb-release

として、

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=24.04
DISTRIB_CODENAME=noble
DISTRIB_DESCRIPTION="Ubuntu 24.04.2 LTS"

が表示されることを確認します。

手順

  1. Ubuntu Oneアカウントの作成/ログイン
  2. Ubuntu Proのサイトでトークンを取得
  3. トークンをサーバに適用

Ubuntu Oneへのアクセス

https://login.ubuntu.com/ にアクセスします。

必要事項を入力して、アカウントを作成します。

トークンの取得

https://ubuntu.com/pro にアクセスします。

「Get Ubuntu Pro now」をクリックします。

「Myself」をクリック後、「Register」をクリックします。

確認後、「Yes, log me in」をクリックします。

上記の画面に切り替わるので、Tokenを控えておきます。

トークンをサーバに適用

  • ※推奨※インスタンスのバックアップ

VPSやAWSのインスタンスの場合は、スナップショットなどでシステム全体のバックアップを取っておきます。

対象のUbuntuサーバにログインし、以下のコマンドを実行します。

sudo pro attach [取得したトークン]
Enabling Ubuntu Pro: ESM Apps
Ubuntu Pro: ESM Apps enabled
Enabling Ubuntu Pro: ESM Infra
Ubuntu Pro: ESM Infra enabled
Enabling Livepatch
Failed to enable default services, check: sudo pro status

Live Patchは有効にはならないようですが、ESM appが有効なので今回はよしとします。

適用後のサーバアップデート

  • パッケージ全体の更新
sudo aptitude update && sudo aptitude upgrade
  • システム再起動

ESMを適用すると、カーネル全体もアップデートされるケースが多いので、システム全体の再起動を行います。

sudo reboot

ESM適用確認

ログイン後、以下のようなメッセージが出ることを確認します。

Expanded Security Maintenance for Applications is enabled.

再度、https://ubuntu.com/pro にアクセスし、Acvie Machinesが繰り上がっていることを確認します。

Apache、特定のユーザーエージェントからのアクセスを404で返す。

こちらの記事の応用編。

Bot・クローラーへとアクセストラフィックを「特定のユーザーエージェントを弾く」

方法は「403エラーを返すため、柄の悪いBOTが繰り返し狙い続ける」弱点がありました。

また、confファイルに禁止するエージェントやIPを指定するため、メンテナンスが悪い難点もありました。

そこで、以下のような措置を執ります。

  1. 排除するクローラー(Bot)ならびにIPを別のファイルで管理する。
  2. Rewriteルールで「403」ではなく「404」を返すようにする。

環境

  • Ubuntu 24.04
  • Apache 2.4
  • 要:Rewriteモジュール

リライトモジュールのインストール確認

sudo apache2ctl -M |grep rewrite

rewrite_module (shared)と有効化を確認します。

有効化されていない場合は

sudo a2enmod rewrite
sudo systemctl restart apache2.service

で有効化します。

特定のユーザーエージェントを弾くためのファイルを作成

/etc/apache2/site-enabled/spam-clawler.txt として、以下のようなファイルを作成。

RewriteCond %{HTTP_USER_AGENT} (facebookexternalhit/1\.1) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (SemrushBot/7~bl) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (AhrefsBot) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (MJ12bot) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (DotBot) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (Baiduspider) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (YandexBot) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (Sogou\ web\ spider) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (Exabot) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (MegaIndex\.ru) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (SeznamBot) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (BLEXBot) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (Bytespider) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (DataForSeoBot) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (serpstatbot) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (SeekportBot) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (index\.community\ crawler) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (PetalBot) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (BacklinksExtendedBot) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (GPTBot/1\.2) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (ICC-Crawler) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (ImagesiftBot) [NC]

正規表現などがある場合は注意してください。

特定のIPアドレスを弾くためのファイルを作成

/etc/apache2/site-enabled/spam-ips.txt として、以下のようなファイルを作成。

RewriteCond %{REMOTE_ADDR} ^190\.92\.
RewriteCond %{REMOTE_ADDR} ^159\.138\.
RewriteCond %{REMOTE_ADDR} ^166\.108\.
RewriteCond %{REMOTE_ADDR} ^124\.243\.
RewriteCond %{REMOTE_ADDR} ^114\.119\.
RewriteCond %{REMOTE_ADDR} ^119\.8\.
RewriteCond %{REMOTE_ADDR} ^110\.238\.
RewriteCond %{REMOTE_ADDR} ^217\.113\.194\.
RewriteCond %{REMOTE_ADDR} ^34\.123\.
RewriteCond %{REMOTE_ADDR} ^119\.13\.

confファイルの修正

  • バックアップ
sudo cp -pi /etc/apache2/sites-availables/sites.conf /path/to/backup/directory/sites.conf.$(date +%Y%m%d)

任意のバックアップファイル、利用しているサイトを用います。

  • バックアップ確認
diff -u /path/to/backup/directory/sites.conf.$(date +%Y%m%d) /etc/apache2/sites-availables/sites.conf

差分がないことを確認します。DocumentRoot等は修正します。

ファイル修正

  • /etc/apache2/sites-availables/sites.conf

以下のように修正していきます。

DocumentRoot /home/www-data/atelier/public
    <Directory /home/www-data/atelier/public>
        Options -MultiViews
        AllowOverride All
    <IfModule mod_rewrite.c>
    RewriteEngine On
    # 2025/03/21追加
    # 読み込まれたUser-Agentに基づき、Clawlerに対して404を返す
    Include /etc/apache2/sites-enabled/spam-clawler.txt
    RewriteRule .* - [R=404,L]

    # 2025/03/21追加
    # 読み込まれたIPアドレスに基づき、偽装エージェントのIPに対して404を返す
    Include /etc/apache2/sites-enabled/spam-ips.txt
    RewriteRule .* - [R=404,L]
   </IfModule>
     <RequireAll>
      Require all granted
     </RequireAll>
    </Directory>

この時、ディレクトリやパスファイルが合っていることを確認します。

整合性確認

sudo apache2ctl configtest

Syntax OKを確認します。

Webサービス再起動

sudo systemctl restart apache2.service && echo $?

0を確認

systemctl status apache2.service

tatus(running)を確認します。

設定後の確認

sudo tail -f /path/to/web/access_log 

等として、ログを流し続けて、
指定したBOTからのアクセスが404になっていることを確認できればOKです。

『ユミアのアトリエ』発売に向けての準備。

アトリエシリーズ(コンシューマー向け)最新作、『ユミアのアトリエ』発売日と言うことで準備を行いました。

公開用Redmineにプロジェクトを追加

https://atelier.reisalin.com/projects/yumia

新規プロジェクトの作成。

ライザのアトリエ3ほどの熱量があるかは不明ですが、記録には遺そうと思っています。

プレイ中の水分と糖分補給の準備

『ライザのアトリエ3』立て続けにプレイした際、脳のエネルギー源が著しく消費した反省から、今回は過剰と言えるものにしています。

アウトレットでキャラメルポップコーンがあったのはある種の救いでした。

こちらを携えつつ、集中してプレイに臨めればと思っています。

Page 1 of 88

Powered by WordPress & Theme by Anders Norén