Manualmaton's Laboratory

タグ: Linux Page 26 of 36

Linux:シェルスクリプトで天気表示。

By

オン 2023年9月27日

カテゴリー: Linux

概要

Linuxのコマンドラインで天気を知りたい状況があったので、簡単なスクリプトを書きました。

前提

  • Linux機がインターネットに繋がっていること。
  • ansiweatherがインストールされていること。

Ubuntuでのansiweatherインストール方法

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

sudo aptitude install ansiweather
# 筆者の好みでaptitudeを用いています。必要に応じてaptを使ってください。

スクリプト

  • getweather.sh

以下の内容を教義・信仰に沿ったエディタで記載します。

#!/bin/bash

# ユーザーに都市名を尋ねる
echo "都市名を入力してください:"
read city

# ansiweatherコマンドを実行して天気情報を表示
echo "ansiweatherの情報:"
ansiweather -l "$city"

# curlコマンドを使用してwttr.inから天気情報を表示
echo "wttr.inの情報:"
curl wttr.in/"$city?lang=ja"
  • 実行権限付与
chmod +x getweather.sh

スクリプトの動き

  • スクリプト実行
./getweather.sh
  • 実行結果

都市名を入力します。（Tokyo, Londonなど)

入力後、以下のように1行で現在の天気の概要、アスキーアートで3日の予報が出てきます。

Ubuntuでプロンプトの挙動を変更(ちょいハマり-1-)。

By

オン 2023年9月26日

カテゴリー: Linux

ちょっとハマっていること

LinuxのCUI操作で、

  1. プロンプトの内容を「ユーザ名@ホスト名 カレントディレクトリ」に変更する。
  2. 一般ユーザの場合はプロンプトを緑にして\&で表記。
  3. rootに昇格した場合はプロンプトを赤にして#で表記。

という挙動にしています。

RockyLinuxの場合：OK

以下の内容を /etc/bashrc に組み込めばOKでした。

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

Ubuntuの場合：NG

ところが、Ubuntu系は

  1. 上記の設定を/etc/bash.bashrcに追記してもプロンプトの動きが想定通りとならない。
  2. source /etc/bash.bashrcと実行すると、設定が反映される。

これは相当面倒です。ログイン時に別のスクリプトか何かでこれを実行すればいいのでしょうが、新しいユーザを作成した場合など不都合が生じます。

Ubuntuでのワークアラウンド

取り急ぎ、当初の目的である「一般ユーザと特権ユーザでプロンプトの色や記号を変える」を優先させます。

ログインユーザ（一般ユーザ）の設定ファイル

  • ~.bashrc

末尾に以下を追記します。

# 一般ユーザ向けのプロンプト設定
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

rootの設定ファイル

  • /root/.bashrc

末尾に以下を追記します。

# rootユーザ向けのプロンプト設定
if [ "$PS1" ]; then
  PS1='\[\e[0;31m\][\u@\H \W]#\[\e[0m\] '
fi

これで当面の問題は回避できましたが、根本的な解決には至らず。

もう少し調査が必要です。

Torの出口ノードリストからのWebアクセスを遮断する設定。(Mod_Securityとの連携)

By

オン 2023年9月23日

カテゴリー: Linux, PC

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

IPアドレス抽出スクリプト。(Torの出口リスト)

Torの出口ノードリストを抽出するスクリプトと、既に稼働済みの不審なIPアドレスをブロックするスクリプトを連携させます。

前提

こちらにあるように、

Mod_Securityが検知したIPアドレスの自動遮断スクリプト・修正。
  • Mod_Security導入済み
  • エラー検知時にブロックする設定をバーチャルサイトに設定済み

となります。

また、先日の記事である、

  • Tor出口ノードリストを抽出スクリプトがCron化されているものとします。

スクリプト

  • negativelist.sh
#!/bin/bash

# 読み込むログのディレクトリとファイル名を変数指定
log_dir="/var/lib/redmine/log"
log_file="error.log"

# シェルスクリプトから抽出したTorの出口ノードリストを指定
tor_list_dir="/path/to/directory"  # tor_list.txtのディレクトリを指定
tor_list_file="sorted_ip_addresses$(date +%Y%m%d).txt"

# 除外するIPアドレスをファイルで指定
# 自分のNWなど、偽陽性を防ぐために記載したアドレスのリストです。
exclude_ips_file="/path/to/directory/exclude_ips.txt"

# ログファイルからIPアドレスを抽出して重複を排除し、ファイルに保存します。
cd "$log_dir"
awk 'match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/) { print substr($0, RSTART, RLENGTH) }' "$log_file" | sort -u > "$log_dir/suspicious_ip/suspicious_ip.$(date +%Y%m%d)"
chown www-data:www-data "$log_dir/suspicious_ip/suspicious_ip.$(date +%Y%m%d)"

# 過去のIPアドレスを読み込んで重複を排除し、ファイルに保存します。
cat "$log_dir/suspicious_ip/suspicious_ip."2* | sort -u > "$log_dir/suspicious_ip_all.txt"
chown www-data:www-data "$log_dir/suspicious_ip_all.txt"

# 新たにリストに書き起こすと同時にTorの出口ノードリストを読み込んで重複を排除し、negativelist.txtに追加します。
cat "$log_dir/suspicious_ip_all.txt" "$tor_list_dir/$tor_list_file" | sort -u > /etc/apache2/sites-available/negativelist.txt

# 除外するIPアドレスをファイルから削除します。
while IFS= read -r exclude_ip; do
  sed -i "/$exclude_ip/d" /etc/apache2/sites-available/negativelist.txt
done < "$exclude_ips_file"

# Apacheを再起動します。
systemctl restart apache2.service

あとはこちらをroot権限でCron登録。

設定後の動き

以下のように動きます。

  1. 指定のログファイルからエラーとなったIPアドレスのみを抽出します。
  2. 全てのIPアドレスを統合し、重複を排除してsuspicous_ip_all.txtとして抽出します。
  3. suspicous_ip_all.txtとtor_list_fileを統合し、negativelist.txtとして作成します。(これらのIPアドレスからのアクセスに対しては全て403を返します）
  4. negativelist.txtから除外IPアドレスを取り除きます。
  5. Webサービスを再起動します。

ひとまず、WAFとの連携ができました。

IPアドレス抽出スクリプト。(Torの出口リスト)

By

オン 2023年9月22日

カテゴリー: Linux, PC

必要があったので、スクリプトを書きました。

スクリプトの動き

  1. 公開されているTor出口リストをダウンロード。
  2. IPアドレスのみを抽出。
  3. 重複を排除してソート。

スクリプト内容

  • tor_exit_hodes.sh
#!/bin/bash

# 出口ノードリストのURL
TOR_EXIT_LIST_URL="https://check.torproject.org/exit-addresses"

# ダウンロード先ファイル名
OUTPUT_FILE="exit_nodes.$(date +%Y%m%d).txt"

# curlを使用してリストをダウンロード
curl -o "$OUTPUT_FILE" "$TOR_EXIT_LIST_URL" 

##curl -o "$OUTPUT_FILE" "$TOR_EXIT_LIST_URL" >/dev/null 2>&1
##cron処理などを行う場合はこちらを使います。

# ダウンロードが成功したかどうかを確認
if [ $? -eq 0 ]; then
  echo "Tor出口ノードリストをダウンロードしました。ファイル: $OUTPUT_FILE"
else
  echo "ダウンロード中にエラーが発生しました。"
  exit 1
fi

# IPアドレスのみを抽出し、ソートして出力
awk '/^ExitAddress/ {print $2}' "$OUTPUT_FILE" | sort | uniq | tee sorted_ip_addresses$(date +%Y%m%d).txt 

##awk '/^ExitAddress/ {print $2}' "$OUTPUT_FILE" | sort | uniq > sorted_ip_addresses$(date +%Y%m%d).txt >/dev/null 2>&1
##cron処理などを行う場合はこちらを使います。

これで、IPアドレスのみが抽出されますので、apache/nginxやFiwawall/WAFとの連携が容易になります。

今後の動き

  1. Cron化
  2. Mod_Securityとの連携

などやっていきます。

Linuxサーバでの失敗と切り戻しと心構え。

By

オン 2023年9月2日

カテゴリー: Linux, PC, ガジェット

当サイトに残しているLinuxの設定について。

多くのケースで

sudo cp -pi /etc/apache/sites-available/hoge.example.conf /path/to/backup/hoge.example.conf.$(date +%Y%m%d)
# 任意のバックアップディレクトリを指定します。

diff -u /etc/apache/sites-available/hoge.example.conf /path/to/backup/hoge.example.conf.$(date +%Y%m%d)
# バックアップが保存されたか、差分がないことで確認します。

と、バックアップを取っています。その重要性を書こうとしましたが、ChatGPTの方がうまく説明してくれるのではと思いプロンプトを叩いてみると、物の見事に答えてくれました。

設定変更作業を行う際に設定ファイルをバックアップし、失敗した場合にバックアップファイルから切り戻すことは非常に重要です。以下にその重要性をいくつか説明します：

  1. システムの安全性と信頼性の確保：
    サーバーの設定ファイルに誤った変更を加えると、サーバーの正常な動作に影響を及ぼす可能性があります。バックアップを取らない場合、問題が発生したときに元の状態に戻す手段がなくなり、システムの安全性と信頼性が損なわれる可能性が高まります。
  2. トラブルシューティングの助け：
    設定変更による問題が発生した場合、バックアップファイルを使用して元の設定に戻すことで、問題を解決する手助けとなります。バックアップがない場合、問題の特定や修正が難しく、システムの停止時間が延長される可能性があります。
  3. 変更履歴の記録：
    バックアップファイルを保存することにより、設定変更の履歴を確認できます。特定の変更が問題を引き起こす場合、どの変更が原因かを特定しやすくなります。これにより、同じ問題が将来的に再発するのを防ぐのに役立ちます。
  4. 開発とテストのサポート：
    バックアップファイルは、新しい機能や設定変更をテストする際にも役立ちます。変更前の設定ファイルを使用して、新しい設定が期待どおりに機能するかどうかを確認できます。
  5. バージョン管理とチーム協力：
    プロジェクトが複数の開発者や管理者によって共同管理される場合、バックアップファイルを使用することで、異なるバージョンの設定ファイルを比較し、変更を調整するのに役立ちます。

バックアップを取る際には、タイムスタンプを含む有効なファイル名を使用し、適切な場所に保存することをお勧めします。また、定期的にバックアップを更新し、システムの変更が行われるたびに新しいバックアップを作成することが重要です。バックアップと適切な設定管理は、システムの安全性と信頼性を確保するために欠かせないプラクティスです。

この事態が発生したので、設定ファイルを切り戻す際の心構え的なことを書いていきます。

エラーの事象を確認します。

  1. 本来とは意図しない動きが発生した。
  2. サイトそのものが見られなくなった。

など、設定変更時にはトラブルはつきものです。その際、まず、すぐ修正しようとせず

「今起きている現象は何か」

を記録しておきます。

  • システムログ
  • スクリーンショット
  • 概要

何でも構いません。「今の現象をありのまま記録する」が重要です。

切り戻しを実施します。

ある程度の記録が発生した後、「元の状態に戻す（切り戻し）」を行います。

冒頭の「hoge.example.conf」設定ファイルの変更中に不具合が発生した場合の切り戻し手順を示します。

  • 問題を起こした設定ファイルをコピーする

この作業は原因追及のために必要です。

sudo cp -pi /etc/apache/sites-available/hoge.example.conf /path/to/backup/ERROR_hoge.example.conf.$(date +%Y%m%d)
# バックアップしたファイルとは別の名前にしておきます。
  • 切り戻しを実施する

cp バックアップファイル 元のファイル

の順番を間違えると二次災害を生みます。

sudo cp -pi /path/to/backup/hoge.example.conf.$(date +%Y%m%d) /etc/apache/sites-available/hoge.example.conf
  • サービスを再起動する

ここではWebサービス(apache)の再起動を行います。

sudo systemctl restart apache2.service

sudo systemctl status apache2.service
# サービス稼働を確認します。

修正前の状態であることを確認します。

証明書の更新作業だったら、「有効期限が延びていないこと」など、明確な指標があると楽です。

失敗を悔やむより

  1. どんな失敗があったかを記録する
  2. 元の状態に戻す
  3. その後で原因を考える
  4. 原因をフィードバックする

の方が、自分にとっても利用者にとっても建設的です。

GrowiのDB格納先を変更。(mongod.conf編集)

By

オン 2023年8月26日

カテゴリー: Linux, PC

GrowiのDB保存先を、冗長性を持たせたディスクに移設したときのメモです。

動作を確認した環境

  • Ubuntu 20.04
  • MongoDB v4.4.13
  • Growi 6.1.14

さっくりとした手順

  1. MongoDBサービスを停止します。
  2. DBの格納ディレクトリを作成します。
  3. MongoDBの設定ファイルを編集します。
  4. MongoDBサービスを再開します。
  5. 格納ディレクトリが変わったことを確認します。

MongoDBの停止

これは確実に行ってください。でないと、作業中にDBが書き換えられ不具合が発生する可能性があります。
（共有Wikiであればなおさらです）

sudo systemctl stop mongodb

systemctl status mongodb
# inactive(dead)を確認します

新規格納ディレクトリの作成

sudo mkdir /home/mongodb
# 任意の保存ディレクトリを作成します

sudo chown -R mongodb:mongodb /home/mongodb

ls -ld /home/mongodb
# ディレクトリの所有者がmongodbであることを確認します

既存データのコピー

  • ディレクトリ移動
cd /var/lib/mongodb && pwd

ll
# .wtで終わるファイルがあることを確認します
  • ファイルコピー
sudo cp -pir * /home/mongodb
# 先ほど作成したディレクトリにコピーします
  • ファイルコピー確認
cd /home/mongodb && pwd

ll
# コピーしたファイル一式があることを確認します

設定ファイル修正

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

diff -u /etc/mongod.conf /path/to/backup/mongod.conf.$(date +%Y%m%d)
# バックアップが保存されたか、差分がないことで確認します。
  • 設定ファイル編集

/etc/mongod.conf を教義・信仰に沿ったエディタで修正します。

  • 編集内容
  dbPath: /home/mongodb
  • 差分内容
-  dbPath: /var/lib/mongodb
+  dbPath: /home/mongodb

設定反映 (MongoDB再開)

sudo systemctl start mongod.service

systemctl status mongod.service
# active(running)を確認します

設定反映確認

  • ブラウザでの確認
  1. MongoDBを利用しているアプリ（Growi）にアクセスします。
  2. 正常にアクセスできて、Wikiの閲覧や編集、作成ができることを確認します。
  • サーバでの確認
cd /home/mongodb && pwd

ls -lart
# .wtファイルの更新時刻がブラウザで編集した時と同じであることを確認します。

cd /var/lib/mongodb && pwd

ls -lart
# .wtファイルの更新時刻が操作前と同じことを確認します。

事後作業（必要に応じて）

問題なく稼働することが確認されたら、元の保存ファイルを削除（退避）させます。

NFSマウントによるサーバディレクトリのマウント。

By

オン 2023年8月25日

カテゴリー: Linux, PC

予備で使っているUbuntuサーバ。ディスク容量が余っているのでバックアップサーバとして用いてみました。

前提

  • サーバA(メイン)とサーバB(バックアップ)が同一NW上につながっている。
  • 両方ともサーバはUbuntu。
  • サーバBの/home/backupディレクトリをバックアップとして用いる。

さっくりとした手順

  1. サーバBでNFSサーバをインストールします。
  2. サーバBでサーバAの許可設定を行います。
  3. サーバAでサーバBのディスクをマウントします。
  4. 再起動時、自動マウントできるように設定します。

NFSサーバインストール （サーバB）

sudo aptitude update
sudo aptitude install nfs-kernel-server

NFSサーバアクセス許可設定 （サーバB）

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

  • 編集するファイル
/etc/exports
  • 追記する内容
/home/backup <サーバAのIPアドレス>(rw,sync,no_root_squash,no_subtree_check)

NFSサーバの設定反映

sudo systemctl restart nfs-kernel-server

NFSクライアントのインストール（サーバA）

sudo aptitude update
sudo aptitude install nfs-common

マウントするディレクトリの作成（サーバA）

sudo mkdir /mnt/backup

サーバのマウント確認（サーバA）

  • NFSマウント
sudo mount <サーバBのIPアドレス>:/home/backup /mnt/backup
  • マウント確認
df -h
# サーバBのIPアドレス:/home/backup  と見えていれば成功です
  • ファイルの読み書きを行えるか確認
sudo mkdir test

sudo chown -R hoge:hoge test
# hogeは任意のユーザ名を指定します

cd test

touch test.txt

ls test.txt
# ファイルが表示されることを確認します

rm test.txt
ls test.txt
# ファイルが表示されないことを確認します
  • マウント解除
cd
#/mnt/backupにいるとマウント解除できません

sudo umount /mnt/backup
  • マウント解除確認
df -h
# サーバBのIPアドレス:/home/backup が消えていればマウント解除できています

fstab編集（サーバA）

サーバAを再起動しても自動的にサーバBのディレクトリをマウントできるようにします。

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

  • 編集するファイル
/etc/fstab
  • 追記する内容
<サーバBのIPアドレス>:/backup /mnt/backup nfs rw,sync 0 0

自動マウント確認（サーバA）

※サーバの再起動を行うので、作業時は注意してください。

sudo reboot
df -h
# サーバBのIPアドレス:/home/backup  と見えていれば成功です

rsyncやlsyncと違って、あたかもそのディスクがサーバ上にあるかのように扱えるのがポイントです。

もちろん、NW越しにデータの読み書きをするので、速度はNWの帯域や処理速度に依拠します。過信は禁物です。

Nextcloudのインストール後の対応：ログローテーションの設定

By

オン 2023年8月23日

カテゴリー: Linux, nextcloud, PC, ガジェット

Nextcloudは多層的なWebアプリスイートであるため、ログがたちまち肥大化します。

そのため、設定後、ログローテーションの設定を行います。

動作確認環境

  • Ubuntu 20.04
  • Nextcloud 27.02
  • Apache2.4経由で稼働
  • PHP 8.1

さっくりとした手順

  1. logrotate.dにファイルを追加します。
  2. 動作を確認します。
  3. logrotateサービスを再起動します。

ファイルの追加

以下の通り、ファイルを追加します。【】内は設定したログファイルの格納ディレクトリにしてください。

cat <<- __EOF__ | sudo tee -a /etc/logrotate.d/nextcloud
【/var/log/nextcloud/】*.log {
    daily
    dateext
    dateformat -%Y%m%d
    rotate 10
    missingok
    notifempty
    su www-data www-data
    create 640 www-data www-data
    sharedscripts
    compress
    delaycompress
        postrotate
                if invoke-rc.d apache2 status > /dev/null 2>&1; then \
                    invoke-rc.d apache2 reload > /dev/null 2>&1; \
                fi;
        endscript
}
__EOF__
それぞれの内容
  1. /var/log/nextcloud/*.log: /var/log/nextcloud/ ディレクトリ内の全ての .log ファイルを対象にしてログローテーションが行われます。
  2. daily: 日ごとにログをローテートします。
  3. dateext: ログファイル名に日付が追加されます。
  4. dateformat -%Y%m%d: 日付のフォーマットが "年4桁月2桁日2桁" の形式で指定されます。
  5. rotate 10: ログファイルは10世代まで保持され、古いファイルは削除されます。
  6. missingok: ログファイルが存在しない場合でもエラーを出さずに処理を続行します。
  7. notifempty: ログファイルが空の場合、ローテーションを行わずにスキップします。
  8. su www-data www-data: ローテーション操作時にログファイルの所有者とグループを www-data ユーザーに変更します。
  9. create 640 www-data www-data: 新しいログファイルが作成される際、所有者 www-data とグループ www-data、パーミッション 640 で作成されます。
  10. sharedscripts: ローテーションの前後に prerotate および postrotate セクション内のコマンドを共有します。
  11. compress および delaycompress: ローテート後にログファイルを圧縮し、以前のファイルを圧縮しないようにします。
  12. postrotate: ローテーションが完了した後、Apache2サーバーが起動している場合にApache2をリロードします。

設定確認

sudo logrotate -v /etc/logrotate.d/nextcloud

エラーがないことを確認します。

設定反映

sudo systemctl restart logrotate.service

これで設定は完了です。後日、アクセスログが圧縮されていることを確認します。

すぐ確認したい場合は

sudo logrotate -f /etc/logrotate.d/nextcloud

で、強制的にローテートさせます。

Nextcloudのインストール後の対応：cron設定

By

オン 2023年8月19日

カテゴリー: Linux, nextcloud, PC

Nextcloudのインストール後の設定で概要でのセキュリティチェックがパスしましたが、

管理＞基本設定で

最終ジョブ実行は %s です。何か問題が発生しています。

と出ていますので、これの設定を行います。

動作を確認した環境

  • Ubuntu 20.04
  • Apache 2.4系
  • PHP8.1
  • Nextcloud 27.0.2

さっくりとした手順

  1. Nextcloud上で設定を変えます。
  2. 一度Cronを走らせます。
  3. Cron設定を行います。
  4. 動作を確認します。

Nextcloud設定変更

  1. Nextcloud＞管理＞基本設定に進みます。
  2. バックグラウンドジョブをCronに設定します。

Cron作動

NextcloudがインストールされたサーバにSSHログインし、以下を実行します。

sudo -u www-data /usr/bin/php /var/www/html/nextcloud/cron.php

# 自分がnextcloudをインストールした環境に合わせます。
# 筆者環境
# sudo -u www-data /usr/bin/php /home/www-data/nextcloud/cron.php

Cron実行確認

  1. Nextcloud＞管理＞基本設定に進みます。
  2. 以下のように「最終ジョブ実行は○分前です」が表示されることを確認します。

Cronログ設定

Ubuntu 20.04の初期設定はcronログの出力が無効になっているので、修正します。

cd /etc/rsyslog.d

sudo cp -pi 50-default.conf /path/to/backup/50-default.conf.$(date +%Y%m%d)
# 任意のバックアップディレクトリを指定します。

diff -u 50-default.conf /path/to/backup/50-default.conf.$(date +%Y%m%d)
# 差分がないことでバックアップされていることを確認します。
  • ファイル修正

教義・信仰に合わせたエディタで以下を修正します。

  • 修正前
#cron.*                         /var/log/cron.log
  • 修正後
cron.*                         /var/log/cron.log
  • 設定反映
sudo systemctl restart rsyslog.service

Cron登録

  • crontab起動
sudo -u www-data crontab -e
  • 追記内容
*/5 * * * * /usr/bin/php -f /var/www/nextcloud/cron.php
# 自分の環境に合わせます。
# 筆者環境
# */5 * * * * /usr/bin/php -f /home/www-data/nextcloud/cron.php
  • Cron登録確認
tail -50 /var/log/cron.log
  • BEGIN EDIT (www-data)
  • REPLACE EDIT (www-data)
  • END EDIT (www-data)

と表示されていれば、Cron登録は確認されています。

  • メール設定
  • config.phpの設定
  • メモリキャッシュの設定
  • redis-serverの組み込み
  • cron設定

が終われば、一応、初期準備は済んだと思います。

Nextcloudのインストール後の対応：config.php修正とredis-server組み込み

By

オン 2023年8月18日

カテゴリー: Linux, nextcloud, PC

本記事はNextcloudに関する記事を再構成して2023年8月現在の安定版27.0．2に合わせた設定となっています。

メール設定後、Nextcloudのセキュリティ&セットアップ警告をまとめて対応します。

  • データベースは取引ファイルを見ることに使われています。パフォーマンスをあげるには、可能であればメモリーのキャッシュを設定してください。
  • ご使用のシステムには、デフォルトの電話地域が設定されていません。
    メモリーキャッシュが構成されていません。

動作を確認した環境

  • Ubuntu 20.04
  • Apache 2.4系
  • PHP8.1
  • Nextcloud 27.0.2

さっくりとした手順

  1. 追加パッケージ(redis-server)をインストールします。
  2. config.phpを追記・修正します。
  3. Apacheを再起動します。

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

※Nextcloud 27系からキャッシュサーバの組み込みは推奨となりました。

  • redisインストール
sudo aptitude install redis-server php8.1-redis
# 必要に応じてaptを用いてください。
# 自分のPHPバージョンを付与することを忘れないようにしてください。(でないと、最新のPHPもインストールされます）
  • redisインストール確認
systemctl status redis-server.service
# active (running)を確認します
  • hosts確認
cat /etc/hosts

を実行し、

127.0.1.1       localhost

と表示されていれば、

127.0.0.1       localhost

に修正します。Ubuntu20.04系はなぜかlocalhostを127.0.1.1と設定されるケースがありました。

コンフィグ追記

  • ディレクトリ移動
cd /var/www/html/nextcloud/config && pwd
# 移動先は自身の環境に合わせます。
# そのディレクトリにいることを確認します。
  • バックアップ
sudo cp -pi config.php /path/to/backup/config.php.$(date +%Y%m%d)
# バックアップ先は任意のディレクトリを指定してください。
  • バックアップ取得確認
sudo diff -u config.php /path/to/backup/config.php.$(date +%Y%m%d)
# エラーなく実行され、差分が表示されなければバックアップはできています。
  • ファイル追記

教義、信仰に合わせたエディタで以下を追記して保存します。

注意点：最下行の);直上に追記します。

  'default_phone_region' => 'JP',
  'memcache.local' => '\OC\Memcache\APCu',
  'filelocking.enabled' => true,
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' => 
   array (
     'host' => 'localhost',
     'port' => 6379,
     'timeout' => 3,
   ),
  • ファイル差分確認
sudo diff -u /path/to/backup/config.php.$(date +%Y%m%d) config.php 
# 先程保存したバックアップを指定します。
  • 差分内容
+  'default_phone_region' => 'JP',
+  'memcache.local' => '\OC\Memcache\APCu',
+  'filelocking.enabled' => true,
+  'memcache.locking' => '\\OC\\Memcache\\Redis',
+  'redis' => 
+   array (
+     'host' => 'localhost',
+     'port' => 6379,
+     'timeout' => 3,
+   ),
 );

Webサービス再起動

  • サービス再起動
sudo systemctl restart apache2.service
  • 再起動確認
systemctl status apache2.service
# active (running)を確認します。

設定反映確認

  1. Nextcloudに管理者権限でログインします。
  2. 管理＞概要で以下の画面が表示されれば、設定は反映されています。

Page 26 of 36

前

次

Powered by WordPress & Theme by Anders Norén