月: 2023年8月 Page 1 of 4

Steam保存場所の変更とNextcloudの連携。

Steamが稼働しているPCの保存領域を少し減らすため、スクリーンショットの保存場所を変更しました。

Steamツールバーから「表示→スクリーンショット」へと進みます。

ゲーム中タブから「スクリーンショットの非圧縮コピーを保存する」を有効にします。

非圧縮スクリーンショットフォルダーをNextcloudの共有フォルダーに変更します。

後はゲームを立ち上げてスクリーンショットを撮影するだけ。
Nextcloudの画像ファイルに勝手に登録してくれます。

登録日時やシステムタグも登録するので便利です。

Piwigo, Webからのアップデート。

Webでのフォトアルバムアプリ、Piwigo。

https://hideout.reisalin.com/

WordPressやNewxtcloudと同じようにWeb画面上でアップデートができました。

管理者アカウントでログインし、管理>ダッシュボードにアクセスします。

「新しいバージョンのPiwigoが利用可能です」とでるのでこちらをクリック。

アップグレードをクリックします。

しばらく待ちます。

「アップデート完了」のメッセージが出たら作業は完了です。

合間のボードゲーム。

統率者戦の前後にボードゲームを回す機会にも恵まれました。

カム・セイル・アウェイ!

初の対人戦。(そしてスリーブつけてのプレイ)

大差で敗北したものの、ソロプレイ時の参考になりました。

宝石の煌めき

別のゲームを提案していたのですが、「4人で行う宝石の煌めき」は抗えない魅力がありました。

ほぼ2年ぶりの4人戦ができるという感動の方が大きくてプレイが甘く、3着に終わったのが残念です。

統率者メモ16:2回目の4人戦。

機会をいただき統率者:4人戦を実施しました。

今回持ち込んだ統率者は

  1. 音速のスパイ、サウンドウェーブ
  2. 工匠の主任、ウルザ
  3. 高名な者、ミシュラ
  4. グレムリンの神童、ジンバル

の4つ。ほぼ唯一「勝てた」統率者は最初から使っている《グレムリンの神童、ジンバル》でした。

2023/08/26現在のリスト

// 統率者

1 グレムリンの神童、ジンバル

// クリーチャー

1 搭載歩行機械
1 歩行バリスタ
1 極楽鳥
1 金のガチョウ
1 第三の道の偶像破壊者
1 桜族の長老
1 金属の徒党の種子鮫
1 エーテリウムの達人
1 ハンウィアー守備隊
1 氷刻み、スヴェラ
1 ゴブリンの武器職人、トッゴ
1 永遠の証人
1 不屈の補給兵
1 不屈の追跡者
1 アカデミーの整備士
1 双子唱者、アドリックスとネヴ
1 つむじ風のならず者
1 ピア・ナラーとキラン・ナラー
1 真面目な身代わり
1 黄金架のドラゴン
1 テルカーの技師、ブルーディクラッド
1 フラクタルの花、エシックス
1 河童の砲手
1 破片撒きのスフィンクス
1 煌めくドラゴン
1 鋼のヘルカイト
1 ワームとぐろエンジン
1 ガラクタ這い
1 作業場の古老

// 呪文

1 サイクロンの裂け目
1 天才のひらめき
1 精神壊しの罠
1 意志の力
1 難解な試験
1 手慣れた複製
1 いざ動け
1 ホビット庄の復興
1 耕作
1 根から絶つ
1 焦熱の合流点
1 残響の嵐
1 原初の命令
1 サヒーリの芸術
1 月への封印
1 鏡割りの寓話
1 殺しのサービス
1 奇妙な森
1 機械化製法
1 飛行機械の諜報網
1 太陽の指輪
1 連合の蛹
1 打ち砕かれた尖塔、オゾリス
1 グルールの印鑑
1 シミックの印鑑
1 共同魂の刃
1 複製する指輪
1 スカイクレイブの秘宝
1 エシカの戦車
1 王冠泥棒、オーコ
1 崇高な工匠、サヒーリ
1 ウルザの後継、カーン

// 土地

1 ハンウィアーの要塞
1 植物の聖域
1 繁殖池
1 燃えがらの林間地
1 統率の塔
1 銅線の地溝
1 焦熱島嶼域
1 火の灯る茂み
4 森
1 凍沸の交錯
1 獲物道
1 内陸の湾港
4 島
1 ケトリアのトライオーム
1 モリアの坑道
1 霧深い雨林
1 苔汁の橋
1 無限地帯
1 遊牧民の前哨地
1 怒り狂う山峡
1 ホビット庄の段々畑
1 シヴの浅瀬
2 山
1 尖塔断の運河
1 蒸気孔
1 踏み鳴らされる地
1 硫黄の滝
1 ホビット庄
1 蔦明の交錯
1 樹木茂る山麓
1 ヤヴィマヤの沿岸

本人が面で戦うデッキなので、それを重視。より確実を期すためにマナ加速も更に追加しています。

強かったカード

フラクタルの花、エシックス

何らかの効果で自分が生成したトークンが出た場合、自分以外のクリーチャーのコピーにする豪快なクリーチャー。

これで戦場の強力なフライヤーやシステムクリーチャーを次々にコピーしていきました。

双子唱者、アドリックスとネヴ

《似通った生命》内蔵のクリーチャーが弱いはずがなく。

テルカーの技師、ブルーディクラッド

今回のフィニッシュムーブです。量産したトークンを一律同じものに書き換えることで、

《ウルザの後継、カーン》から出て来た構築物が一気に対戦相手全員に襲いかかりました。(速攻・トランプルを持つ17/17が14体ほど)

焦熱の合流点

これは裏の主役。横並べのトークン群を焼き払い、厄介なアーティファクトを割ることで上記のフィニッシュの下準備としてくれました。

このデッキ、色と戦略が好きだからということでベースデッキを買ったわけですけれども、手に馴染んできました。

参考情報:『ライザのアトリエ3』最速タイミングでの「賢者の石」錬成・更新。

このタイミングを更に更新しました。更に、手順も確定しているわけではないので参考程度にとどめておいて下さい。

タイミング

  • クレリア地方到着後、サルドニカについた後
  • かつ、クレリア地方にアトリエを構えていない

前提

上記のタイミングまでに

  1. 品質上限999解放済み。
  2. 投入回数もほぼ上限まで解放済み。
  3. ハンマーや斧の採取ランクが3になっている。

と、序盤からかなりのSPが必要です。調合に次ぐ調合でどうにかしました。

また、性質上、超純度による無限ジェム稼ぎをやっておくとよいでしょう。

前提補足-1

ハンマーの上位、斧の上位の原料となる

  • クリミネア
  • ゴルドテリオン

の必須素材、創世の逆さ石とゴルドテリオンはリーゼ峡谷にいるゴーレム系からドロップできます。

前提補足-2

賢者の石へ中間素材「カラフルオイル」に必要な虹翼の欠片はランドマーク「虹の魔力結晶」からハンマーのランク3で入手できます。

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

手順

リーゼ峡谷、

  • 石巨人塚の北
  • 峡谷の門南西

巨岩の兵士が出てくることがあります。確定ではないので、何度かファストトラベルを繰り返します。

この敵を倒すことで

  • 七煌原石
  • エーテルコア
  • ゴーレムのコア
  • セプトリエン

をドロップできます。条件はかなり厳しめなので、根気よく倒していきます。

調合

  1. 中間材料:カラフルオイルを調合します。(ミックスオイルからのレシピ変化)
  2. 精霊の小瓶を調合します。(必須素材はカラフルオイル)
  3. 精霊の小瓶からのレシピ変化でクリスタルエレメントを調合します。
    • このクリスタルエレメントは後々の調合で多用するので、複製しておきます。
  4. 精霊の小瓶からレシピ変化で賢者の石を調合します。この時、素材「花」あたりに超純度を持つ素材をいれておくと、ジェム稼ぎが更に楽になります。
  • 無垢の鍵を解放していないので「属性追加」が手に入ってない
  • 一部の効果が未解放(作成個数が+2止まり)

ではありますが、しっかり超純度でジェム稼ぎにも対応した賢者の石が錬成できました。

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

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マウントによるサーバディレクトリのマウント。

予備で使っている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 画像認識「Recognize」の自動タグ付けが行われない問題の解決。(occ 実行)

Ubuntu 20.04に新規インストールすることになったNextcloud。

各種設定を済ませ、アプリの動作を確認中に「Recognize(画像自動認識・タグ付けツール)で以下の警告が出ていました。また、自動タグ付けも行われていなかったので、問題の解決を行います。

参考にしたURL

https://help.nextcloud.com/t/machine-learning-models-still-need-to-be-downloaded/151566

さっくりとした手順

  1. Nextcloudの格納ディレクトリに移動します。
  2. Nextcloudのコマンドラインツール(occ)を実行します。
  3. 動作を確認します。

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分程かかります)

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

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

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

アイスミルクと炭酸レモン。

この暑さのため、茶葉の消費量が加速的。

そのたびに新しいフレーバーティーを試していますが、そんな中で「これは」と自分に刺さったものが2つほどありました。

オペラ

フランス発のケーキ、オペラをイメージしたフレーバーティー。

その名に恥じず、コーヒーとチョコレートの風味が足されています。

かなり鮮やかな琥珀色をしていて、香りも上々。ですが、その真価を発揮するのはアイスミルクティーにしたとき。

カフェオレに近いアイスミルクティーとなり、どっしりとした味わいが広がります。

アラビアンナイト

オペラとは打って変わってザクロとジャスミンの華やかな香りが特徴的でした。こちらは炭酸水出しでいただくと美味しいお茶。特に、抽出の際にカットレモンを入れると眠気を吹き飛ばすような酸味と茶葉の風味、そしてのどごしが素敵でした。

夏のお茶として

  1. 水出し
  2. 炭酸水出し
  3. アイスミルクティー

のどれか(またはいずれかの組み合わせ)に合うお茶があるというのは水分補給的な意味でも安心に繋がります。

Page 1 of 4

Powered by WordPress & Theme by Anders Norén