ChatGPTによるシェルスクリプト。(続:Ubuntuサーバのパッケージ全体の更新とサービス再起動の有無) 

こちらのスクリプトを修正しました。(正確にはChatGPTに修正してもらいました)

修正版スクリプト

#!/bin/bash

# インストールされているパッケージの一覧を取得して別ファイルに出力します。
now=$(date +%Y%m%d)
dpkg-query -W > installed_packages_$now.txt

# aptitude updateを行います。
aptitude update

# updateの結果:
if aptitude search '~U' | grep -q '^i'; then
    # 対象パッケージ,変更前バージョン,変更後のバージョン を記入した日付付きのファイルを作成。
    now=$(date +%Y%m%d)
    upgraded_packages=$(mktemp)

    # パッケージのキャッシュをクリアした上でパッケージアップグレードを実施。
    aptitude clean
    aptitude -y full-upgrade | tee $upgraded_packages >/dev/null

    # パッケージ一覧からの差分を別ファイルで作成。(実行日の日付を付与)
    new_packages=$(mktemp)
    dpkg-query -W > $new_packages
    diff -u installed_packages_$now.txt $new_packages > package_diff_$now.txt

   # 新しいパッケージ名を取得
   DIFF_FILE="package_diff_$now.txt"
   NEW_PACKAGES=$(grep -E "^\+[^+]" $DIFF_FILE | awk '{print $1}' | cut -c 2-)

   # 変更されたパッケージの数と、新しいバージョンのパッケージ名のリストを表示
   UPDATED_PACKAGES=$(echo "$NEW_PACKAGES" | wc -l)
   echo "$UPDATED_PACKAGES 件のパッケージに変更がありました。以下のパッケージが更新されました:"
   echo "$NEW_PACKAGES"

    # checkrestartを実行して結果を取得
    now=$(date +%Y%m%d)
    checkrestart_output=$(checkrestart)

    # サービスを再起動する必要のあるプロセスを抽出してファイルに出力
    restart_services=$(echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | awk '{print $NF}' | sort -u)

    if [[ -n "$restart_services" ]]; then
        # ファイル名に日付を追加
        now=$(date +%Y%m%d)
        filename="restart_services_$now.txt"

        echo "以下のサービスを再起動してください:" >> "$filename"
        echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | grep -v "restart$" >> "$filename"
        echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | grep "restart$" >> "$filename"

        echo "以下のサービスを再起動してください:"
        echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | grep -v "restart$"
        echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | grep "restart$"


    else
        echo "再起動するサービスはありません"
    fi
fi

差分

+   # 新しいパッケージ名を取得
+   DIFF_FILE="package_diff_$now.txt"
+   NEW_PACKAGES=$(grep -E "^\+[^+]" $DIFF_FILE | awk '{print $1}' | cut -c 2-)
+
+   # 変更されたパッケージの数と、新しいバージョンのパッケージ名のリストを表示
+   UPDATED_PACKAGES=$(echo "$NEW_PACKAGES" | wc -l)
+   echo "$UPDATED_PACKAGES 件のパッケージに変更がありました。以下のパッケージが更新されました:"
+   echo "$NEW_PACKAGES"

これによって、アップグレードするパッケージを明確化させました。

次の展望

「どこまで自動化できるか」が課題となります。パッケージによっては設定ファイルを残すかどうかのウィザードが表示されるので、それに対する自動実行までいけたらと思います。

ChatGPTによるシェルスクリプト。(Ubuntuサーバのパッケージ全体の更新とサービス再起動の有無)

脆弱性などに対応するため、Linuxサーバのパッケージを最新に保つことは重要です。

ですが、どこかでトラブルが発生した際に「どのパッケージを更新してから異常が発生したか」の履歴を追うことも必要。

そこで、以下のシェルスクリプトをChatGPTに尋ねながら作ってみました。

動作確認環境

  • Ubuntu 20.04で動作を確認しました。
  • 筆者の好みの関係上、パッケージ管理はaptitudeを用いています。
  • また、サービス再起動の有無を確認するため、checkrestartをインストールします。(debian-goodiesをインストール)

要件

ChatGPTに要求した要件は以下の通りです。

  • パッケージ一覧のリストを作成する。
  • パッケージ全体のupdateを行う。
  • そのupdateで差異があった場合はファイルに出力して更新を行う。
  • サービス再起動があったらそれを標準出力とファイルに出力する。

かなりの試行を重ねて以下のスクリプトができあがりました。

スクリプト内容

  • update-packages.sh
#!/bin/bash

# インストールされているパッケージの一覧を取得して別ファイルに出力します。
now=$(date +%Y%m%d)
dpkg-query -W > installed_packages_$now.txt

# aptitude updateを行います。
aptitude update

# updateの結果:
if aptitude search '~U' | grep -q '^i'; then
    # 対象パッケージ,変更前バージョン,変更後のバージョン を記入した日付付きのファイルを作成。
    now=$(date +%Y%m%d)
    upgraded_packages=$(mktemp)

    # パッケージのキャッシュをクリアした上でパッケージアップグレードを実施。
    aptitude clean
    aptitude -y full-upgrade | tee $upgraded_packages >/dev/null

    # パッケージ一覧からの差分を別ファイルで作成。(実行日の日付を付与)
    new_packages=$(mktemp)
    dpkg-query -W > $new_packages
    diff -u installed_packages_$now.txt $new_packages > package_diff_$now.txt

    # checkrestartを実行して結果を取得
    now=$(date +%Y%m%d)
    checkrestart_output=$(checkrestart)

    # サービスを再起動する必要のあるプロセスを抽出してファイルに出力
    restart_services=$(echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | awk '{print $NF}' | sort -u)

    if [[ -n "$restart_services" ]]; then
        # ファイル名に日付を追加
        now=$(date +%Y%m%d)
        filename="restart_services_$now.txt"

        echo "以下のサービスを再起動してください:" >> "$filename"
        echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | grep -v "restart$" >> "$filename"
        echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | grep "restart$" >> "$filename"

        echo "以下のサービスを再起動してください:"
        echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | grep -v "restart$"
        echo "$checkrestart_output" | awk '/^(These are the systemd services|These are the initd scripts)/{flag=1;next}/^$/{flag=0}flag' | grep "restart$"


    else
        echo "再起動するサービスはありません"
    fi
fi

記入後、以下を実施します。

sudo chown root:root update-packages.sh
# root権限で実施するため

sudo chmod 744 update-packages.sh

確認結果

sudo bash update-packages.sh

を実行後、

  • 現在インストールされているパッケージのバージョンを別ファイルに出力
  • パッケージのアップデート
  • その際に差分があればアップグレード
  • サービス再起動の有無を判断し、あればそのサービスを表示

という結果が出ました。

今後の展望

  • 可読性を高くする
  • 自動実行を行う
  • ログ化してローテーションを行う

等は実施したいです。

ゲーム『ライザのアトリエ3』最初の感想。

続編が出ると想像すらしていなかった「3」がいよいよ現実のものとなりました。

はやる気持ちを抑えてダウンロードしてインストールし、起動して数時間ほど遊んだ感想をネタバレあまりなしで書きます。

キャラクターがとかく動く。

表情がとても豊か。ガストが2021年にリリースした『BLUE REFLECTION TIE/帝』や2022年の『ソフィーのアトリエ2』で培った技術をフルに活かしているという印象です。

コンテナ倍加。

以前の5,000から10,000へと倍増。(ただ、これでも足りなくなりそうです)

戦闘時の声の掛け合い

個人的にとても気に入ったところです。この掛け合いがやたらと発生するので、戦闘時がまるで一つのセッションのようです。

調整された調合。

「バランス調整」といったところでしょうか。1と2でできていた「レシピ変化による武器の強化」は実質的に封じられていますし、アイテムリビルドもまだ解放されていません。

とはいえ、

  • 中和剤ループ
  • 中和剤やゼッテルを介した特性の移し替え

などは建材ですし、新システムの調合も悪くありません。

ゲームはまだ序盤なので、これからが凄く楽しみです。

備考

ネタバレありの感想はRedmineのコメントに記しています。

https://atelier.reisalin.com/issues/37

多目的スコアシート。(電卓付き電子メモパッド)

百均で見つけ思わず購入です。

700円商品と結構高額。ですが、

  • ソーラー電卓
  • 電子メモ

が一緒になったもの。

広げたときのサイズはiPad miniより少し小さいかなという程度です。

「ボードゲームのスコア計算と記録を一緒にやってくれる」と思いました。早速、この使い勝手を確かめるために『アグリコラ』を広げます。

思った通り、右側のメモの所に得点源をかき、左の電卓で計算。最終スコアを記入する余白もありました。

また、iPadと比べて断然安価なのでボードゲームカフェやオープン会で広げても大丈夫ですし、各人がスマートフォンの電卓を立ち上げる必要も減ります。

何のかんので便利なので職場用にも持っておきたいやつでした。

ソロゲーと背景。(2023年3月)

集中してボードゲームソロを行う気分となったので、そのときの簡単な記録と「それを用いた撮影」です。

アルルの丘

準備やプレイ時間の兼ね合いなどで稼働率は低いながらも充実感が強い作品。

今回は割とオーソドックスに「15点建物を3軒建てる」を目標にして120点を取ることができました。

アンダーウォーターシティーズ

コンポーネントが綺麗でフレーバーも大好きなのにゲームシステムが難解な『アンダーウォーターシティーズ』。今度こそクリア(7つの都市をつなげて100点を取る)を目標にしていたものの、90点とあと10点届かず。

コツは飲み込んできたのでもう少しやりこんでみたいです。

アグリコラ

こちらは別項で取り上げるサプライの使い勝手を確かめるために遊んだもの。

職業がかみ合って60点を超えることができました。

コンポーネントをしっかり手に取って動かしながら考えるという行為そのものが好きなので、もう少し時間を作らないとと感じます。

ボードゲーム『旅のあと』感想。

チップドラフトとセットコレクションが程よくまとまり、プレイ中の会話も盛り上がる中量級の良作です。

【概要】

プレイヤーたちは旅行先(京都/シンガポール)から帰ってきたばかり。

「何をしたっけ」
「この観光名所はどこだったか」
「ホテルはここだったはず」

とおのおのの記憶が微妙に食い違っています。そこで、各人は断片的な記憶を頼りに旅の詳細を思い出そうとしています。

【ゲームシステム】

ぱっと見はタイル配置ですが、その実はチップドラフト。

各手番、規定の枚数のチップのかたまりを個人ボードに条件に従って配置。これを繰り返していき、タイルと同じ形にチップが並んだら得点が発生。

このとき、

  • 共通ボードにタイルが置かれていない場合:個人ボードと同じ箇所にタイルを配置。完成ボーナスと記憶ボーナスを入手
  • 共通ボードに先にタイルが置かれていて完全に一致:完成ボーナスと記憶ボーナスを入手
  • 共通ボードに先にタイルが置かれていて一部が一致:完成ボーナスと記憶ボーナスの一部を入手
  • 共通ボードに先にタイルが置かれていて一致せず:完成ボーナスのみ入手

となっているため

何も置かれていない場合は先行しての配置を目指し、置かれている場合はそれに合わせるという協力と競合が生まれます。

全てのチップが配布されたらゲーム終了。共通目標や個人目標に合わせて最終得点計算となります。

【このゲームの好きなところ】

○ドラフトがもたらすインタラクション

先にお伝えしたように、「チップを配置してからタイルの形が決まる」システム。
そこにランダムに加わる記憶のチップ(名所や公園などの色が書かれています)のドラフトが加わることで

「後一手で完成するけど上家に完成されそう」
「配置したいけどこの指示通りに置けるか?」

といった読み合いが生まれます。

○共通ボードかセットコレクションか

上述した共通ボードを目指す他の得点源として、レストランやショッピングエリアの大量配置ボーナスやゲーム開始時に配られる個人目標があります。
そのため、既にある共通ボードの得点を無視してでも完成を目指す余地は残されています。なので、ゲーム中は

「私の記憶が確かなら京都タワーはここにあった」
「そこにレストランなんてなかった。いいね?」

など、各人の“記憶の捏造”で盛り上がります。

○厚手でしっかりしたコンポーネント

『パッチワーク』と同じぐらいの箱の大きさでありながらぎっしりと詰まったコンポーネントはどれもしっかりとしていて、遊びごたえは充分。

各ランドマークを立てて配置できるスタンドなども心憎い演出です。

【このゲームの難点】

●実質的に4人専用ゲーム

3人では余剰のチップが生まれ、2人ルールは準備がちょっと大変です。個人ボードを東西南北に設置することからも、人数を選ばず遊べるというわけではありません。

●終盤の巻き返しが難しい

この手のゲームの常として、先行して走っている人を差しきるのは大変です。序盤のミスが終盤、致命的に響いてしまうのも難点です。
ライトに見えて一手が重いゲームと言えます。

【まとめ】

インスト合わせて1時間ほどで終わるゲームながらもインタラクションや合間の会話で盛り上がることができる良作。

個人的には、配置ゲームでありながらスペースが固定されているのでテーブルが広がらずに済むというのも好感です。

  • 4人揃っている
  • 変則的なタイル(?)配置を行いたい

という方に手に取っていただきたいゲームです。

『ライザのアトリエ2』DLC『陽炎の島』ボス難易度LEGEND / 2人体制 / ノーダメージクリア。

『ライザのアトリエ3』の発売を前にして、ある種の最終目標を成し遂げました。

メンバーとステータス

ライザ:ステータス

項目数値
Lv.100
HP1577
攻撃力3010
防御力2330
素早さ3345
器用さ99

ライザ:コアアイテム

※リンク先は公開用Redmineのコメント欄です。

最早バフアイテムすら不要になりました。全てを攻撃アイテムにして、戦術も「コアアイテム連打」一本に絞ります。

クラウディア: ステータス

バフとヴィアベールルフトでの牽制役。他にタオ/クリフォードでも可能です。(初期CCが3まで伸びるので、時空の天文時計→ヴィアベールルフトへとつなげられます)

項目数値
Lv.100
HP1577
攻撃力3010
防御力2330
素早さ3345
器用さ99

エリキシル剤はしくじったときの保険です。(検証時、これは使いませんでした)

実施した手順

さっくりとした手順

  1. 開幕:ライザのヴィアベールルフトでボスの行動順を後ろに戻します。
  2. キャラクターをクラウディアに変えて時空の天文時計→ヴィアベールルフト
  3. キャラクターを随時切り替えてヴィアベールルフトで行動順を後ろに戻しつつAPを稼ぎ
  4. 途中で時空の逆さ時計→時空の天文時計でバフをかけます。
  5. ライザはコアアイテム連打とCC不足時のスキル連打のみ。
  6. ライザの行動順が遅れたら時空の天文時計で早めます。

最終的に、こんな形で500万を難なく詰めることができました。

特に「デバフ用」として用意した「達人の烙印」EVの効果は相当のもの。

おかげで相対的にこちらの行動順を早め、2人での戦いを楽にしてくれました。

検証

こちらのツリーにぶら下げておきます。

変形版キャンディス。

こちらのレシピから少し変えてみました。

材料

今回の主眼となるものはヒャッキンで購入した天津甘栗とレーズン。ともに糖分との相性は抜群です。

  • 刻んだ甘栗
  • レーズン
  • グラニュー糖
  • 氷砂糖
  • ラム酒

分量はすべて目分量。形になるように作っていきます。

調理

  1. 鍋に水を張り、グラニュー糖をたっぷり入れます。
  2. 中火で沸騰させたらレーズンとラム酒を入れて煮詰めていきます。
  3. 煮詰まってきたら刻んだ甘栗を入れます。
  4. 更に煮詰めたら火からおろします。

最後によく洗った容器に入れて

完成。

栗のほっこりとした甘みがレーズンをきりっと締める形になりました。

Redmine脆弱性対応。(4.2.x→4.2.10へのバージョンアップ)

これを行うきっかけ

こちらの記事:

https://blog.redmine.jp/articles/redmine-security-scanner/

で運用中のRedmineに既知の脆弱性がないかをチェックできるWebサービスの存在を知ったからでした。

で、現在のRedmineのURLを調べてみたら

E。

何度見てもEです。多少自信はあったので、この結果はその鼻っ柱を打ち砕くものでした。

そこで、現在運用中のRedmineのバージョンアップを図り脆弱性に対応します。

環境

  • Ubuntu 20.04 (AWS Lightsailで稼働中)
  • 動かしていたRedmine:4.2.9
  • Apache 2.4 / mod-passangerでRubyアプリを使用(Ruby 2.7系)
  • MySQL 8.0.3

作業に備えての前提

  • 本手順では「使用するDBの削除」を伴います。作業の際には慎重に行って下さい。
  • Webサービスを止める/何も入っていないRedmineが途中でできるため、ユーザアクセスができない状況が発生します。
  • また、筆者環境はfiles配下をクラウドストレージにマウントしています。手順は自身の環境に合わせてください。

さっくりとした手順

  1. スナップショットのバックアップ
  2. DBのバックアップ
  3. redmineのディレクトリを一度mvでリネームしてバックアップ。
  4. apache停止
  5. redmineのDBを消す。
  6. redmineのDBを新たに作る。(ユーザは全て権限があるので問題なし)
  7. apache再開
  8. ディレクトリを再作成し、新しい空のRedmineを作る。
  9. themesとpluginを再配置。filesのシンボリックリンクを貼り替える。
  10. themesとpluginを再配置した状態でDBマイグレーション。
  11. DBリストア。

データバックアップ

万一に備え、AWSからインスタンスのスナップショットを取得します。

mysqlによるDBバックアップ

mysqldump -h localhost -u redmine -p --no-tablespaces --single-transaction redmine > redmine_backup.$(date +%Y%m%d).sql
# DB名やDBユーザは自信の環境に合わせます

データ退避

cd /var/lib
# Redmineが格納されているディレクトリの親ディレクトリに移動します

ls -ld redmine
# 退避対象のディレクトリがあることを確認します

sudo mv redmine redmine_$(date +%Y%m%d)

ls -ld redmine_$(date +%Y%m%d)

apache停止

ここでWebサービスを停止するのは、DBを削除するためです。

systemctl status apache2.service

sudo systemctl stop apache2.service

systemctl status apache2.service

DB削除

慎重に行って下さい。

sudo mysql -u root -p
show databases;
/* redmineのDBがあることを確認 */

drop database redmine;

show databases;
/* redmineのDBがないことを確認 */

CREATE DATABASE redmine character set utf8mb4;

show databases;
/* redmineのDBがあることを確認 */

exit

Redmine再インストール

ソースダウンロード

sudo mkdir /var/lib/redmine

sudo chown -R www-data:www-data /var/lib/redmine

sudo -u www-data svn co https://svn.redmine.org/redmine/branches/4.2-stable /var/lib/redmine
# 4.2系の最新安定版をダウンロードします

退避させたディレクトリからconfigファイルコピー

sudo cp -pi /var/lib/redmine_$(date +%Y%m%d)/config/database.yml /var/lib/redmine/config/database.yml

cat /var/lib/redmine/config/database.yml
#中身確認

sudo cp -pi /var/lib/redmine_$(date +%Y%m%d)/config/configuration.yml /var/lib/redmine/config/configuration.yml

cat /var/lib/redmine/config/configuration.yml
#中身確認

Redmineインストール

cd /var/lib/redmine

sudo -u www-data bundle install --without development test --path vendor/bundle

sudo -u www-data bundle exec rake generate_secret_token

sudo -u www-data RAILS_ENV=production bundle exec rake db:migrate

sudo -u www-data RAILS_ENV=production REDMINE_LANG=ja bundle exec rake redmine:load_default_data

apache再開

systemctl status apache2.service

sudo systemctl start apache2.service

systemctl status apache2.service

再開後の仮パスワード作成

対象のRedmineにアクセスします。

IDとパスワードがadmin / admin に戻っている状態のため、仮パスワードを発行します。

退避したディレクトリからデータを再配置

cd /var/lib/redmine_$(date +%Y%m%d)/plugins

sudo cp -pir ./* /var/lib/redmine/plugins/
# プラグイン一式をコピーします

cd /var/lib/redmine_$(date +%Y%m%d)/public/themes

sudo cp -pir ./* /var/lib/redmine/public/themes/
# テーマ一式をコピーします

シンボリックリンク貼り替え

これは筆者の環境が

  • logディレクトリとfilesディレクトリを別の場所にリンクを張っているための措置です。
  • それ以外の場合は上述した /var/lib/redmine_$(date +%Y%m%d)からfilesやlogをコピーして下さい。
cd /var/lib/redmine

sudo rm -rf files

sudo rm -rf log

sudo ln -sf /mnt/wasabi/redmine/files files
# wasabiクラウドストレージを利用しています。

sudo chown -h www-data:www-data files

sudo ln -sf /var/log/redmine log
# ログは/var/log配下で一括管理しています。

sudo chown -h www-data:www-data log

データ再マイグレーション

プラグイン再マイグレーション

cd /var/lib/redmine

sudo -u www-data bundle install

sudo -u www-data bundle exec rake redmine:plugins:migrate RAILS_ENV=production

apacheリスタート

systemctl status apache2.service

sudo systemctl restart apache2.service

systemctl status apache2.service

DBリストア

cd /hoge
# mysqldumpを行ったディレクトリ

mysql -h localhost -u redmine -p redmine < redmine_backup.$(date +%Y%m%d).sql
# パスワードはredmineインストール時に設定したDBユーザのものです

apacheリスタート

systemctl status apache2.service

sudo systemctl restart apache2.service

systemctl status apache2.service

動作確認

この状態でRedmineに管理者権限でログインします。手順通りなら

  • テーマ
  • 添付ファイル
  • プラグイン

などが正常に動いていると思います。

バージョンアップ後の診断

2023/03/18現在のRedmine4.2系の最新安定版:4.2.10がインストールされ、A+ と診断されました。

AWS LightsailからNextcloudをアンインストール。

AWS Lightsailで検証したNextcloudをアンインストールします。

導入していた環境

以下の環境で動かしていたNextcloudをアンインストールします。

  • Ubuntu 20.04
  • Apache 2.4
  • PHP 8.1
  • MySQL 8.0.3

そもそも:なぜアンインストールを行ったか?

スペック不足。

外部公開を目指しAWSのLightsailインスタンスで立ち上げましたが、

  • 表示速度
  • 処理能力

その他が納得いくものではありませんでした。

機能が被っている

  1. タスク管理/文書管理としてRedmine
  2. フォトアルバムとしてPiwigo

をインストールしているため、これらと機能が被るものを同一サーバにインストールするには望ましくありません。

ローカル環境との混同

これが一番の問題でした。ローカル(自宅環境)で既に運用しているNextcloudにはかなりのセンシティブ情報が含まれています。これが外部環境に誤ってアップロードされてしまうのはセキュリティポリシー上問題があると判断。

実施した手順

さっくりとした手順

  1. 本当にアンインストールしていいかいったん深呼吸します。
  2. クライアントからアカウントを削除します。(PCを利用している場合)
  3. バーチャルファイルを無効にします。
  4. DBを削除します。
  5. バーチャルファイルを削除します。
  6. ファイルを削除します。

アンインストールでも残すもの

  • PHPは既に他のサービスで動かしているので残します。
  • MySQL/Apacheについても同様です。

削除対象の確認

  1. 深呼吸する
  2. お茶を入れて飲みながらじっくり考え

削除を決意。

重要なファイルがあるかを確認

もう一度確認します。

PCクライアントから設定削除

WindowsなどでNextcloudのアカウントを設定していたので、こちらを削除します。

バーチャルファイル無効化

  • バーチャルファイル無効化
cd /etc/apache2/sites-available && pwd

sudo a2dissite nextcloud.conf
# 自分が設定した環境に合わせます。
  • 無効化反映
sudo systemctl restart apache2.service

この時点でアクセスできないことを確認です。

DB削除

mysql -u root -p
# mysqlのrootパスワードでログイン
SHOW DATABASES;
/* 削除対象を確認します */

DROP DATABASE nextcloud;
/* DB名を再度確認します */
/* 容赦なく削除されるので慎重に行ってください */

SHOW DATABASES;
/* DBがないことを確認します */

EXIT

プログラム一式を削除

  • nextcloud配置ディレクトリ削除
cd /var/www/html && pwd
# nextcloudが格納しているディレクトリ

ls -ld nextcloud
# ディレクトリがあることを確認します

sudo rm -rf nextcloud

ls -ld nextcloud
# ディレクトリがないことを確認します
  • nextcloudバーチャルファイル削除
cd /etc/apache2/sites-available && pwd
# 対象ディレクトリにいることを確認します

sudo rm nextcloud.conf 

後始末

  • 独自ドメインで運用していたのであれば、Nextcloudのために設定していたDNS情報を削除します。
  • 削除されたことを確認します。

最後に

スペックや機能の面でほぼほぼ「こうなるだろうな」という予感はありました。
ですが、一応、やってみるだけの価値はありました。(ローカル環境と比べ著しく遅いと体感でき、後の未練を断つことができました)

Page 1 of 177

Powered by WordPress & Theme by Anders Norén