タグ: Linux Page 1 of 16

Nextcloud 29.0アップグレード後の処理。(テーブルインデックス追加)

概要

Nextcloudを29.0にアップデート後、管理画面で以下のエラーが出てきました。

データベースにいくつかのインデックスがありません。 大きなテーブルにインデックスを追加すると、自動的に追加されないまでに時間がかかる可能性があるためです。 "occ db:add-missing-indices"を実行することによって、インスタンスが実行し続けている間にそれらの欠けているインデックスを手動で追加することができます。 インデックスが追加されると、それらのテーブルへのクエリは通常はるかに速くなります。 オプションのインデックス "oc_npushhash_di" がテーブル "notifications_pushhash"にありません

この問題に対処していきます。

Nextcloudが実行されているサーバにSSHログインして作業を行います。

環境

  • Ubuntu 20.04 または Ubuntu 22.04
  • PHP 8.1
  • Apache 2.4
  • MySQL
  • Nextcloud 28.x→29.0にアップグレード

ディレクトリ移動

cd /var/www/html/nextcloud/ && pwd

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

occ実行

  • 管理画面で出てきたコマンドを実行
sudo -u www-data php occ db:add-missing-indices
  • 実行結果
Adding additional oc_npushhash_di index to the oc_notifications_pushhash table, this can take some time...
oc_notifications_pushhash table updated successfully.

エラー解消確認

  1. 上記対処を行ったNextcloudサイトに管理者権限でログインします。
  2. 管理画面で、このエラーが解消されていれば完了です。

アカウントファイルを用いたDBログインとバックアップ。

概要

バックアップスクリプトなどでMySQLにログインして処理を行う場合のTIPSです。

何かと使うのでメモに残します。

さっくりとした手順

  1. アカウントファイルを作ります。
  2. ログインできることを確認します。
  3. アカウントファイルを用いたコマンドでバックアップできることを確認します。

アカウントファイル作成

  • ディレクトリ作成
sudo mkdir -p /home/hoge/db_password

運用に合わせて指定ください。

cd /home/hoge/db_password && pwd

指定したディレクトリに移動します

  • アカウントファイル作成

以下の内容を教義・信仰に沿ったエディタで作成します。(【】内は取り除き、自分の設定に合わせます)

  • アカウントファイル内容
  • ファイル例:account.txt
[client]
user = 【RedmineのDBユーザ】
password = "【RedmineのDBユーザ用パスワード】"

password は""で囲みます。

  • アカウントファイルのパーミッション変更
chmod 400 account.txt
ls -l account.txt

パーミッションが400であることを確認します。

ファイルを用いてのログインを確認

mysql --defaults-extra-file=/path/to/directory/account.txt

--defaults-extra-file=は、アカウントファイルの絶対パスです。

ログインできることを確認します。

SHOW DATABASES;

アカウントの権限で指定されたDBの表示を確認します。

EXIT

MySQLから抜けます。

SQL Dumpの取得

  • SQL Dump
mysqldump --defaults-extra-file=/path/to/directory/account.txt --no-tablespaces -h [DBサーバ] [DB名] > backup.sql
  • --no-tablespacesはPROCESS特権がないユーザでもダンプできるようにするためです。
  • バックアップ先も必要に応じて絶対パスで指定できます。
  • ファイル確認
ls -l backup.sql

ファイルの内容にDBがあれば成功です。取り扱いには慎重を期してください。

Ubuntu 22.04にmkcertをインストール。

これを使わずとも、Ubuntu 22.04にはapt(aptitude)からインストール可能でした。

概要

  • ローカルDNSで証明書を作りたい
  • 或いはローカルホスト(127.0.0.1)をhttps化したい

場合に役立つコマンド、mkcertをインストールします。

インストール方法

aptitude (apt)によるインストール

sudo aptitude install mkcert

ローカルルート証明書を作成

  • ルート証明書の作成
mkcert -install
  • ローカルのルート証明書作成確認
ls -l ~/.local/share/mkcert/
  • rootCA-key.pem → 秘密鍵
  • rootCA.pem → ルート証明書

ホスト名に追記・修正

ファイル /etc/hosts をルート顕現で、以下のように修正します。

127.0.0.1  agnes-luce

※ Ubuntu系はホスト名に指定したIPがなぜか127.0.1.1になっています。

証明書作成

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

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

  • 証明書作成
mkcert -key-file ドメイン名.key.$(date +%Y%m) -cert-file ドメイン名.crt.$(date +%Y%m) ドメイン名
  • 作成例
mkcert -key-file agnes-luce.key.$(date +%Y%m) -cert-file agnes-luce.crt.$(date +%Y%m) agnes-luce
Created a new certificate valid for the following names 📜
 - "agnes-luce"

The certificate is at "agnes-luce.crt.202404" and the key at "agnes-luce.key.202404" ✅

It will expire on 14 July 2026 🗓

証明書の整合性を確認

  • 証明書から公開鍵のハッシュ値を取り出す
openssl x509 -pubkey -in 証明書ファイル -noout | openssl md5
  • 秘密鍵から公開鍵のハッシュ値を取り出す
openssl pkey -pubout -in 秘密鍵ファイル | openssl md5

それぞれのハッシュ値が同じであることを確認します。

こうしてできた一式は2年半有効です。

Ubuntu 20.04 / 22.04で稼働しているApache HTTP Server 2.4の脆弱性対応。

2024年4月に発表された脆弱性への対処を行います。

脆弱性内容

  • Apache HTTP Serverのコア機能におけるHTTPレスポンス分割の問題(CVE-2023-38709)
  • 複数のモジュールにおけるHTTPレスポンス分割の問題(CVE-2024-24795)
  • HTTP/2 CONTINUATIONフレームの検証不備に起因したメモリ枯渇の問題(CVE-2024-27316)

https://jvn.jp/vu/JVNVU99032532

環境

  • Ubuntu 20.04 および Ubuntu 22.04
  • Apache 2.4系を利用

Apacheのレポジトリを追加します。

sudo add-apt-repository ppa:ondrej/apache2

Apacheのバージョンアップを行います。

  • パッケージ全体のアップデート
sudo aptitude update
  • パッケージのアップグレード
sudo aptitude upgrade

このリストの中にapache2とapache2関連パッケージが更新される(2024/04/10現在)ため、それぞれアップグレードを行います。

バージョンアップを確認します。

apache2ctl -v

Apache/2.4.59以降であることを確認します。2.4.58には、http/2プロトコルへの脆弱性があるので、左記のバージョンであることを確認します。

対応を行った日付

2024/04/10

ビルトインの自動アップデート機能を使って、Snipe-ITをv6.3.3からv6.3.4にアップグレード。

概要

プログラムに備わっている自動アップデートスクリプトを使い、Snipe-ITのアップグレードを行いました。

  • アップグレード前:v6.3.3
  • アップグレード後:v6.3.4

前提

以下の環境で動いています。

  • Ubuntu 22.04
  • Apache 2.4
  • MySQL 8.0.36
  • PHP 8.1.27
  • Composer 2.6.6

参考手順

https://snipe-it.readme.io/docs/upgrading

さっくりとした手順

Snipe-ITがインストールされているサーバでコマンド操作を行います。

  1. Snipe-ITのインストールディレクトリに移動します。
  2. バックアップ用の仮ファイルを作成します。
  3. アップグレードスクリプトを実行します。
  4. ブラウザでアップグレードを確認します。

Snipe-ITのインストールディレクトリに移動

cd /home/www-data/snipe-it

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

仮ファイル作成

sudo -u www-data touch ./storage/app/backup-temp
  • これを作っておかないと、後のスクリプトでエラーとなりました。
  • Snipe-ITはApacheで実行しているので、仮ファイルは所有者権限で作成します。

アップグレード

sudo -u www-data php upgrade.php
スクリプト例
--------------------------------------------------------
WELCOME TO THE SNIPE-IT UPGRADER! 
--------------------------------------------------------

This script will attempt to: 

- validate some very basic .env file settings 
- check your PHP version and extension requirements 
- check directory permissions 
- do a git pull to bring you to the latest version 
- run composer install to get your vendors up to date 
- run migrations to get your schema up to date 
- clear out old cache settings

Launching using branch: master
Found PHP requirements, will check for PHP > 7.4.0 and < 8.2.0
Proceed with upgrade? [Y/n]: 

確認はこの部分だけです。PHPのバージョンを確認した上で「y」を入力します。

(中略)

--------------------------------------------------------
STEP 9: Migrating database:
--------------------------------------------------------

Migrating: 2024_03_18_221612_update_legacy_locale
Migrated:  2024_03_18_221612_update_legacy_locale (154.60ms)

--------------------------------------------------------
STEP 10: Checking for OAuth keys:
--------------------------------------------------------

√ OAuth keys detected. Skipping passport install.

--------------------------------------------------------
STEP 11: Taking application out of maintenance mode:
--------------------------------------------------------

-- Application is now live.

---------------------- FINISHED! -----------------------
All done! Clear your browser cookies and re-login to use 
your upgraded Snipe-IT!
--------------------------------------------------------

ここまで進めばスクリプトは完了です。

アップグレード確認

  1. ブラウザからSnipe-ITにログインし直します。(一度ログアウトします)
  2. Web画面の右下のバージョンが上がっていれば成功です。

ソースコードからインストールしたOpenSSHを9.6.1p→9.7.1にアップデート(Ubuntu 20.04)

この記事の続きです。

概要

ソースコードからインストールしたOpenSSH9.6p1を、更にOpenSSH9.7p1にバージョンアップします。

前提

Ubuntu 20.04での動作確認です。

上記手順を用いて、ソースコードからOpenSSHをインストールしています。

さっくりとした手順

  1. 作業用ディレクトリに移動します。
  2. ソースをダウンロードします。
  3. OpenSSHをソースからビルドします。
  4. バージョンアップを確認します。

バージョンアップ前の確認

ssh -V
OpenSSH_9.6p1, OpenSSL 3.2.1 30 Jan 2024

作業用ディレクトリ移動

cd /hoge && pwd

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

ソースのダウンロードと展開

  • ソース取得
wget -c http://mirror.exonetric.net/pub/OpenBSD/OpenSSH/portable/openssh-9.7p1.tar.gz

2024/04/04現在の最新版を指定しています。

  • ソース展開
tar -xzf openssh-9.7p1.tar.gz
  • ディレクトリ移動
cd openssh-9.7p1

コンフィグ

  • OpenSSLの位置を確認
which openssl
  • 結果確認
/usr/local/ssl/bin/openssl

筆者の環境です。

  • コンフィグ
./configure --with-kerberos5 --with-md5-passwords --with-pam --with-selinux --with-privsep-path=/var/lib/sshd/ --sysconfdir=/etc/ssh --with-ssl-dir=/usr/local/ssl

--with-ssl-dir=/usr/local/sslは、opensslのヘッドディレクトリを指定します。

  • make
make
  • インストール
sudo make install

バージョンアップ確認

※別にターミナルを開いて確認します。

  • バージョン確認
ssh -V
OpenSSH_9.7p1, OpenSSL 3.2.1 30 Jan 2024

バージョンアップされていることを確認します。

  • SSHサービス再起動
sudo systemctl restart ssh.service
  • サービス再起動確認
sudo systemctl status ssh.service

active(running)を確認します

必要に応じてサーバの再起動を行ってください。

補足:Growiバージョンアップ→切り戻し時に行ったこと。(nodeのダウングレード)

Growi v6.3.2→v7.0.0にアップグレード後、アイコンが非表示になる状況を更に確かめるため、以下の作業を行いました。

環境

  • Ubuntu 22.04
  • node.js 18.20.0
  • npm 10.5.0
  • yarn 1.22.21
  • growi v6.3.2

nodeをアップグレード後に再アップグレード

https://docs.growi.org/ja/admin-guide/upgrading/70x.html

こちらのドキュメントで、サポートしているnodeが20にアップデートされています。

なので、一度、nodeのバージョンを上げます。

node 20 にアップグレード

  • リポジトリ追加
sudo curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash
  • パッケージのアップデート
sudo aptitude update
  • node 20にアップグレード
sudo aptitude upgrade

更新対象にnodeが出てくるので更新を行います

  • アップグレード確認
node -v
v20.12.0

再びGrowiアップデート

手順はこちら。

https://atelier.reisalin.com/projects/zettel/knowledgebase/articles/28

ですが、アイコンが非表示になる状況は変わりません。

Growiダウングレード(切り戻し) → 失敗

前回のエントリーを元にGrowiのバージョンダウンを行いましたが、Growi v6.3.2はnode 20をサポートしていません。なので、yarn通らず。nodeのバージョンダウンを行います。

nodeのダウングレード

こちらを参考にしました。

https://qiita.com/kbys7367/items/0db8d98ef31a12028970

  • node管理(n)のインストール
sudo npm install -g n
  • nodeのバージョン確認
sudo n ls-remote --all

18系の最新版が18.20.0だったのを確認しました。

  • nodeダウングレード
sudo n 18.20.0
  • nodeダウングレード確認
 node -v
v18.20.0

再びのGrowiダウングレード(切り戻し) → 成功

前回のエントリーを元にもう一度Growiのバージョンダウンを行い、yarmも通ることを確認。

取り急ぎ:原因がnodeではないことが判明しました。

Growiのバージョンダウン(システム切り戻し)。

環境

  • Ubuntu 22.04
  • node.js 18.20.0
  • npm 10.5.0
  • yarn 1.22.21
  • growi v6.3.2

の状況下で、growiのバージョンアップをしたら、以下の事象が発生したので、対応したときのメモです。

行ったこと

https://atelier.reisalin.com/projects/zettel/knowledgebase/articles/28

上記の通り、growiをv7.0.0にアップグレード。

発生した事象

左ツールバーや上部に表示されるアイコン全てが文字とリンクだけとなりました。

対処

視認性も操作もしづらいので、元のバージョンに戻します。

growiサービスを停止します

systemctl status growi.service
# サービススクリプトを[growi]にしている場合
# active (running)を確認します

sudo systemctl stop growi.service

systemctl status growi.service
# inactive (dead)を確認します

growiディレクトリに移動します

cd /opt/growi
# 自分の環境に合わせます。

最新版がリリースされていることを確認します。

sudo git fetch --tags

sudo git tag -l
# スペースで確認していき、以前のバージョンに戻します。
# 2023/03/28 利用していたバージョンはでv6.3.2

チェックアウトして切り戻しを行います。

sudo git stash

sudo git checkout 【以前のバージョン】

sudo yarn
# マシンスペックによっては相当時間がかかります
# Done in 【時間】と書かれていたらアップグレード完了です

growiサービスを起動します。

systemctl status growi.service
# inactive (dead)を確認します

sudo systemctl start growi.service

systemctl status growi.service
# サービススクリプトを[growi]にしている場合
# active (running)を確認します

切り戻しを確認します。

  1. ブラウザから設定したgrowiのドメイン/IPにアクセスします。
  2. 画面下部にあるバージョンがチェックアウトしたバージョンであることを確認します。

アイコンが元に戻りました。

要検証

今回はあくまで切り戻し。新規バージョンのgrowiは使いたいので、

  • 新規にv7.0.0をインストールしたらどうなるか?
  • 他に再現するか?

の検証が必要です。

Nextcloud、PHPのアップロードファイルサイズを変更。

概要

Nextcloudの管理画面から出てくるPHPの最大アップロードファイルサイズを変更します。

環境

2024/03/26現在

  • Ubuntu 20.04
  • Apache 2.4.58
  • Nextcloud 28.0.3
  • PHP 8.1.27

手順

現在のファイルサイズを確認

  • upload_max_filesize
cat /etc/php/8.1/apache2/php.ini |grep max_filesize
upload_max_filesize = 2M
  • post_max_size
cat /etc/php/8.1/apache2/php.ini |grep max_size
post_max_size = 8M

それぞれ、筆者の環境です。

バックアップ取得

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

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

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

エラーが出なければ(差分がなければ)バックアップはできています。

ファイル書き換え

  • ファイル書き換え
sudo sed -i 's/upload_max_filesize = 2M/upload_max_filesize = 100M/; s/post_max_size = 8M/post_max_size = 120M/' /etc/php/8.1/apache2/php.ini

※upload_max_filesize = 2Mとpost_max_size = 8Mは、自分の設定を入れてください。

  • ファイル書き換えの差分表示
diff -u /path/to/backup/directory/php.ini.$(date +%Y%m%d) /etc/php/8.1/apache2/php.ini

先ほどバックアップしたファイルを指定します。

 ; https://php.net/post-max-size
-post_max_size = 8M
+post_max_size = 120M

 ; Automatically add files before PHP document.
 ; https://php.net/auto-prepend-file
@@ -847,7 +847,7 @@

 ; Maximum allowed size for uploaded files.
 ; https://php.net/upload-max-filesize
-upload_max_filesize = 2M
+upload_max_filesize = 100M

設定反映

  • apacheのステータス確認
systemctl status apache2.service

active(running)を確認します

  • apache再起動
sudo systemctl restart apache2.service
  • apacheのステータス確認
systemctl status apache2.service

active(running)を確認します

設定反映確認

先ほど修正を行ったNextcloudに管理者権限でアクセスします。

管理>システムに進みます。

最大アップロードファイルサイズが修正した値になっていれば設定完了です。

RHEL(Red Hat Enterprise Linux)のライセンスとサーバを紐付け。(サブスクリプション更新)

概要

Redhatのサブスクリプション更新、忘れがちになるのでメモっておきます。

前提

  • Red Hat Enterprise Linuxのライセンスを所有している。
  • RedHatのアカウントから、サブスクリプション番号が参照できる。
  • サブスクリプション更新の有効期限を過ぎている
    • 更新日前は付け替えできません

手順

※全て管理者権限で実施します。※

RedHatサーバにSSHログインします。

  • OS確認
cat /etc/redhat-release 
Red Hat Enterprise Linux release 8.3 (Ootpa)

割り当て済みのプールIDを確認します。

  • subscription-manager確認
subscription-manager list --consumed

ここに出てくるContractとPool ID:を控えておきます。

控えた後はサーバから抜けます。

  • 現在のプールIDとの割り当て確認
  1. RedHatのサイト>サブスクリプション管理から、現在割り当てられているコントラクト番号とプールIDが一致するか確認します。
  2. RedHatのサイト>サブスクリプション管理から、新しく割り当てられたサブスクリプションを探します。
  3. 新しく有効になったサブスクリプションを開き、プールIDを控えておきます。

※このプールIDは、有効化されるまで出てきません。

新しいプールIDを有効化します。

  • 古いプールIDをデタッチ
subscription-manager remove --pool=[現在のプールID]
  • 新しいプールIDをアタッチ(有効化)
subscription-manager attach --pool=[新しいプールID]

有効化を確認します。

  • subscription-manager確認
subscription-manager list --consumed

以下を確認します。

  • 先ほどアタッチしたプールIDとなっていること。
  • 有効期限が一致していること。
  • dnf updateできること。

Page 1 of 16

Powered by WordPress & Theme by Anders Norén