10年以上利用している「どや文具ペンケース」。ゴムが切れかけていました。
この利用でこの程度で済んだというのはむしろ驚くべきコトですが…… 修繕をします。
幸い、ゴム紐を止めてるだけのシンプルな構造。やり方も簡単です。
百均で調達したヘアゴムに差し替えました。小物も少し足してアクセントとしました。
ゴム紐の強度を一新しつつ、差し色としての赤が全体を引き締めてくれました。
カテゴリー: ガジェット Page 26 of 85
今年もこの時期がやってきました。
『ほぼ日手帳』の来年のリフィル。
2年前に購入したほぼ日サファリデザイン、まだ使い続けたいと思ったので、
リフィルはこのままです。
これの他に小物も揃えました。
- 下敷き
- テンプレート×2
です。ボールペンはいつもの購入特典といった感じ。
日々の記録の基点となる日記なので、できる限り続けていきたいところです。
事情があったのでLAMPサーバにphp-fpmをインストールする機会があったのでメモ書きです。
動作を確認した環境
- Ubuntu 20.04
- php8.1
- Apache 2.4
さっくりとした手順
- 必要パッケージをインストールします。
- apacheモジュールの調整を行います。
- php-fpmの設定ファイルの編集を行います。
- サービスの有効化を行います。
php-fpmをインストールします。
- パッケージインストール
sudo aptitude install php-fpm- apacheモジュールの調整
sudo a2enconf php8.1-fpm
sudo a2dismod php8.1
sudo a2dismod mpm_prefork
sudo a2enmod mpm_event
# php-fpmと関連サービスを有効化します
sudo systemctl restart apache2php-fpmの設定ファイルを編集します。
- 設定ファイルバックアップ
sudo cp -pi /etc/php/8.1/fpm/php.ini /path/to/backup/php.ini.$(date +%Y%m%d)
# 任意のバックアップディレクトリを指定します。
diff -u /etc/php/8.1/fpm/php.ini /path/to/backup/php.ini.$(date +%Y%m%d)
# 差分がないことでバックアップを確認します。次のファイルを教義・信仰に沿ったエディタで編集します。
- /etc/php/8.1/fpm/php.ini
max_execution_time = 180
memory_limit = 512M
post_max_size = 200M
upload_max_filesize = 200M
# 環境に沿って合わせてください。設定を反映します。
sudo systemctl restart php8.1-fpm
sudo systemctl enable php8.1-fpm以上で設定は完了です。
ここにきて、ゲーム『ライザのアトリエ3』の
等をRedmineのチケットとして管理した異議が出てきました。
6周目の課題「ノーマルクエストの記録」
今回はノーマルクエストがどのタイミングで発生し、どこで受諾できるかを書いています。
ここで役立つのが、Redmineに標準で備わっている「関連するチケット」機能。
このように、「関連している」チケットに、発行済みの見聞録やらランドマークへのチケット番号を記載して追加するだけ。
こうすることで、ランドマーク（あるいはその周辺）で発生するクエスト/入手できる見聞録などを可視化。後の集会の効率化を図ります。しかも、どちらか片方に「関連している」を貼れば、もう片方へはしなくていいのも利点です。
当サイトに残している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の方がうまく説明してくれるのではと思いプロンプトを叩いてみると、物の見事に答えてくれました。
設定変更作業を行う際に設定ファイルをバックアップし、失敗した場合にバックアップファイルから切り戻すことは非常に重要です。以下にその重要性をいくつか説明します：
- システムの安全性と信頼性の確保：
サーバーの設定ファイルに誤った変更を加えると、サーバーの正常な動作に影響を及ぼす可能性があります。バックアップを取らない場合、問題が発生したときに元の状態に戻す手段がなくなり、システムの安全性と信頼性が損なわれる可能性が高まります。- トラブルシューティングの助け：
設定変更による問題が発生した場合、バックアップファイルを使用して元の設定に戻すことで、問題を解決する手助けとなります。バックアップがない場合、問題の特定や修正が難しく、システムの停止時間が延長される可能性があります。- 変更履歴の記録：
バックアップファイルを保存することにより、設定変更の履歴を確認できます。特定の変更が問題を引き起こす場合、どの変更が原因かを特定しやすくなります。これにより、同じ問題が将来的に再発するのを防ぐのに役立ちます。- 開発とテストのサポート：
バックアップファイルは、新しい機能や設定変更をテストする際にも役立ちます。変更前の設定ファイルを使用して、新しい設定が期待どおりに機能するかどうかを確認できます。- バージョン管理とチーム協力：
プロジェクトが複数の開発者や管理者によって共同管理される場合、バックアップファイルを使用することで、異なるバージョンの設定ファイルを比較し、変更を調整するのに役立ちます。バックアップを取る際には、タイムスタンプを含む有効なファイル名を使用し、適切な場所に保存することをお勧めします。また、定期的にバックアップを更新し、システムの変更が行われるたびに新しいバックアップを作成することが重要です。バックアップと適切な設定管理は、システムの安全性と信頼性を確保するために欠かせないプラクティスです。
この事態が発生したので、設定ファイルを切り戻す際の心構え的なことを書いていきます。
エラーの事象を確認します。
- 本来とは意図しない動きが発生した。
- サイトそのものが見られなくなった。
など、設定変更時にはトラブルはつきものです。その際、まず、すぐ修正しようとせず
「今起きている現象は何か」
を記録しておきます。
- システムログ
- スクリーンショット
- 概要
何でも構いません。「今の現象をありのまま記録する」が重要です。
切り戻しを実施します。
ある程度の記録が発生した後、「元の状態に戻す（切り戻し）」を行います。
冒頭の「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
# サービス稼働を確認します。修正前の状態であることを確認します。
証明書の更新作業だったら、「有効期限が延びていないこと」など、明確な指標があると楽です。
失敗を悔やむより
- どんな失敗があったかを記録する
- 元の状態に戻す
- その後で原因を考える
- 原因をフィードバックする
の方が、自分にとっても利用者にとっても建設的です。
Steamが稼働しているPCの保存領域を少し減らすため、スクリーンショットの保存場所を変更しました。
Steamツールバーから「表示→スクリーンショット」へと進みます。
ゲーム中タブから「スクリーンショットの非圧縮コピーを保存する」を有効にします。
非圧縮スクリーンショットフォルダーをNextcloudの共有フォルダーに変更します。
後はゲームを立ち上げてスクリーンショットを撮影するだけ。
Nextcloudの画像ファイルに勝手に登録してくれます。
登録日時やシステムタグも登録するので便利です。
Webでのフォトアルバムアプリ、Piwigo。
WordPressやNewxtcloudと同じようにWeb画面上でアップデートができました。
管理者アカウントでログインし、管理＞ダッシュボードにアクセスします。
「新しいバージョンのPiwigoが利用可能です」とでるのでこちらをクリック。
アップグレードをクリックします。
しばらく待ちます。
「アップデート完了」のメッセージが出たら作業は完了です。
GrowiのDB保存先を、冗長性を持たせたディスクに移設したときのメモです。
動作を確認した環境
- Ubuntu 20.04
- MongoDB v4.4.13
- Growi 6.1.14
さっくりとした手順
- MongoDBサービスを停止します。
- DBの格納ディレクトリを作成します。
- MongoDBの設定ファイルを編集します。
- MongoDBサービスを再開します。
- 格納ディレクトリが変わったことを確認します。
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)を確認します設定反映確認
- ブラウザでの確認
- MongoDBを利用しているアプリ（Growi）にアクセスします。
- 正常にアクセスできて、Wikiの閲覧や編集、作成ができることを確認します。
- サーバでの確認
cd /home/mongodb && pwd
ls -lart
# .wtファイルの更新時刻がブラウザで編集した時と同じであることを確認します。
cd /var/lib/mongodb && pwd
ls -lart
# .wtファイルの更新時刻が操作前と同じことを確認します。事後作業（必要に応じて）
問題なく稼働することが確認されたら、元の保存ファイルを削除（退避）させます。
予備で使っているUbuntuサーバ。ディスク容量が余っているのでバックアップサーバとして用いてみました。
前提
- サーバA(メイン)とサーバB(バックアップ)が同一NW上につながっている。
- 両方ともサーバはUbuntu。
- サーバBの/home/backupディレクトリをバックアップとして用いる。
さっくりとした手順
- サーバBでNFSサーバをインストールします。
- サーバBでサーバAの許可設定を行います。
- サーバAでサーバBのディスクをマウントします。
- 再起動時、自動マウントできるように設定します。
NFSサーバインストール （サーバB）
sudo aptitude update
sudo aptitude install nfs-kernel-serverNFSサーバアクセス許可設定 （サーバB）
教義・信仰に沿ったエディタで以下のファイルを編集・追記します。
- 編集するファイル
/etc/exports- 追記する内容
/home/backup <サーバAのIPアドレス>(rw,sync,no_root_squash,no_subtree_check)NFSサーバの設定反映
sudo systemctl restart nfs-kernel-serverNFSクライアントのインストール（サーバ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 rebootdf -h
# サーバBのIPアドレス:/home/backup と見えていれば成功ですrsyncやlsyncと違って、あたかもそのディスクがサーバ上にあるかのように扱えるのがポイントです。
もちろん、NW越しにデータの読み書きをするので、速度はNWの帯域や処理速度に依拠します。過信は禁物です。
Ubuntu 20.04に新規インストールすることになったNextcloud。
各種設定を済ませ、アプリの動作を確認中に「Recognize（画像自動認識・タグ付けツール）で以下の警告が出ていました。また、自動タグ付けも行われていなかったので、問題の解決を行います。
参考にしたURL
さっくりとした手順
- Nextcloudの格納ディレクトリに移動します。
- Nextcloudのコマンドラインツール(occ)を実行します。
- 動作を確認します。
Nextcloudがインストールされているサーバにターミナルでログインします。
任意のクライアントを用います。
格納ディレクトリに移動します。
# 例
cd /var/www/html/nextcloud
# 筆者環境
cd /home/www-data/nextcloudコマンドラインツールを実行します。
sudo -u www-data php occ recognize:download-models
# 環境によって時間がかかります
sudo -u www-data php occ recognize:recrawl動作確認を行います。
Nextcloudに管理者でログインし、管理メニュー＞Recognizeから以下の通り、警告が消えていることを確認します。
ダッシュボード＞アクティビティから、以下の通り、画像のタグ付けが行われていることを確認します。
(表示まで最大15分程かかります)