『Aqua Garden』などをリリースしているショップで注文しました。ボードゲーム『アグリコラ』の資源トークンです。
- 木材
- レンガ
- 葦
- 石材
- 麦
- 野菜
の6品目。特に、
「形が同じだった葦と麦」「色が同じの石と猪」の判別がつきやすくなっています。
オーガナイザーにもしっかりフィット。
また、資源そのものも撮影に併せられるクォリティです。
投稿者: manualmaton Page 112 of 273
前提
Linux Mint 20.3でGrowiを運用しています。
現象
aptによるアップデート後、Growiで全文検索ができない現象が発生しました。
状況把握
[root@chisato.lyco.reco ~]# systemctl status elasticsearch.service
● elasticsearch.service - Elasticsearch
Loaded: loaded (/lib/systemd/system/elasticsearch.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2022-10-30 19:06:41 JST; 1 day 1h ago
Docs: https://www.elastic.co
Process: 983 ExecStart=/usr/share/elasticsearch/bin/systemd-entrypoint -p ${PID_DIR}/elasticsearch.pid --quiet (code=exited, status=1/FAILURE)
Main PID: 983 (code=exited, status=1/FAILURE)
10月 30 19:06:41 chisato.lyco.reco systemd-entrypoint[983]: at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.<init>(ThreadPoolExecutor.java:637)
10月 30 19:06:41 chisato.lyco.reco systemd-entrypoint[983]: at java.base/java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:928)
10月 30 19:06:41 chisato.lyco.reco systemd-entrypoint[983]: at java.base/java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java>
10月 30 19:06:41 chisato.lyco.reco systemd-entrypoint[983]: at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1158)
10月 30 19:06:41 chisato.lyco.reco systemd-entrypoint[983]: at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
10月 30 19:06:41 chisato.lyco.reco systemd-entrypoint[983]: at java.base/java.lang.Thread.run(Thread.java:1589)
10月 30 19:06:41 chisato.lyco.reco systemd-entrypoint[983]: at java.base/jdk.internal.misc.InnocuousThread.run(InnocuousThread.java:186)
10月 30 19:06:41 chisato.lyco.reco systemd[1]: elasticsearch.service: Main process exited, code=exited, status=1/FAILURE
10月 30 19:06:41 chisato.lyco.reco systemd[1]: elasticsearch.service: Failed with result 'exit-code'.
10月 30 19:06:41 chisato.lyco.reco systemd[1]: Failed to start Elasticsearch.→ この後、
systemctl restart elasticsearch.service を行っても起動しません。この事象を解決したときのメモです。
原因調査
cat /var/log/elasticsearch/elasticsearch.log
(中略)
java.lang.IllegalArgumentException: Plugin [analysis-icu] was built for Elasticsearch version 7.17.6 but version 7.17.7 is runningを発見しました。ElasticSearchをバージョンアップしたのに、動いてるプラグインが対応しきれなかったためエラーになったようです。
対処
以下のコマンドを実行しました。
/usr/share/elasticsearch/bin/elasticsearch-plugin remove analysis-icu
/usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-icu
/usr/share/elasticsearch/bin/elasticsearch-plugin remove analysis-kuromoji
/usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-kuromoji
# 問題を起こしているプラグインの削除→再インストールを実施
systemctl restart elasticsearch.service対処確認
systemctl status elasticsearch.service
● elasticsearch.service - Elasticsearch
Loaded: loaded (/lib/systemd/system/elasticsearch.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2022-10-31 21:23:02 JST; 23s ago
Docs: https://www.elastic.co
Main PID: 5424 (java)
Tasks: 94 (limit: 9199)
Memory: 768.5M
CGroup: /system.slice/elasticsearch.service
├─5424 /usr/share/elasticsearch/jdk/bin/java -Xshare:auto -Des.networkaddress.cache.ttl=60 -Des.networkaddress.cache.negative.ttl=10 -XX:+AlwaysPreTouch -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true>
└─5617 /usr/share/elasticsearch/modules/x-pack-ml/platform/linux-x86_64/bin/controller
10月 31 21:22:38 chisato.lyco.reco systemd[1]: Starting Elasticsearch...
10月 31 21:23:02 chisato.lyco.reco systemd[1]: Started Elasticsearch.
で、正常に起動したことを確認できました。
再導入：ジブン手帳
様々なケースを懸案していた結果、これに落ち着きました。
ジブン手帳。
実は9年も前に使っていたものだったりします。
切り替えた理由
ほぼ日手帳を完全に日記帳として運用している。
この理由が最大のもので、スケジュールをオフラインで確認したいケースが多々生まれてきました。
手書きの機会を増やしたい。
LAMYを揃えたことで、「手書きの楽しさ」がいや増していき、それならいっそのことと思った次第です。
一週間の情報が一瞥できる機能。
- 一週間バーチカル
- 起床時間と睡眠時間を記録できる24時間のタイムライン
- 天気、食べたもの、気分の記入欄
と、かゆいものに手が届きます。これらの利点はなぜやめてしまったかレベルです。
革のカバーとの再会
この革のカバー、当時、すごく奮発したことを思い出しました。ずっと放置していて傷が目立ち、手入れもおざなりでしたのにしっかり形が残ってくれていたことに感謝。
まずは保護のため、ツバメノートのマルチケースに収納することにしました。
手入れを復活させたり、本格的に運用していくためのルールを定めたりとやることが色々です。
LAMYを一本購入したことで
- 比較的安価
- 書きやすい
- スクリュー式でないためすぐに書き始められる
の利点がある上に「カラフルで併せやすい」長所があります。
ここで新たに積み上げました。
- テラレッド
- バイオレッド
- ヴァイブラント ピンク
の3つ。この3色をチョイスしたのは
いわゆる「戦隊カラー」に合うからだったりします。
ペンケースを広げると彩りが広がっている光景もまた日々の気分を高めてくれます。
これと同時に手に入れていました。
造花のバリエーションかと思ったら、ぶら下げられるように輪がついているのがポイント。
早速、試してみます。以前百均で入手していたワイヤーライトに輪を通して
撮影スペースにぶら下げるように固定します。
ぶら下げることで（トレリスのように）枠にとらわれることがなく、横に広く奥行きのある背景を使えるようになりました。
以前紹介したボードゲーム『宝石の煌めき』のソロバリアント(出典:BBG[Board Game Geek])を元に、よりマイルドな難易度のバリアントとして調整しました。
ゲームの目的
プレイヤーは、擬似的な対戦相手「ボット」と対峙し、宝石商としてより多くの威信を得ることを目的とします。
BGGバリアントとの違い
- ボットは通常の宝石トークンを獲得します。
- ボットは発展カードを正規の手段で購入します。
- ボットのカード確保条件とその扱いが異なります。
なぜこのルールを作ったか
バリアントは難易度が高すぎる
これにつきます。こちらが2～3手番でようやくカード1枚購入できるのに対し、ボットは1手番でカードを手に入れます。この圧倒的速度はゲームに慣れていない人の心を折るには十分です。
トークンの取り合いを行いたい
程よい重量感もあって質感が素晴らしい宝石トークンのやりとりは最序盤～中盤にかけてのゲームの華。このやりとりもまたゲームの一部なので、こちらのバリアントに取り入れました。
また、ソロバリアントは宝石を各1枚しか取れないのも不満が残りました。
カウンティングとカッティングの習慣を学ぶ
「威信ポイント15点以上」がゲーム終了のトリガーである本ゲームにおいて、
- 相手はどのようなカード/トークンを持っているのか
- 得点はどのぐらいか
- どちらが優勢か
- 場で一番高いカードとそれを買うのに必要な宝石
- どうすれば得点行動に結びつけることができるか
- あるいは相手の得点行動を邪魔することができるのか
を一瞥することは重要です。そして、その鍵となるカードの確保をどのタイミングで行えばいいのかをトレーニングできるようなルールにチューニングしました。
事前準備
2人戦と同じようにセットアップします。
- 各4枚の宝石トークン
- 5枚の黄金トークン
- 3枚の貴族タイル
まで同じですが、ボット用に6面体ダイスを1つ用意します。
- 適当な場所に「1」～「6」の場所を作ります。
- 「1」の場所に黄金トークンを置きます。
- 黄金トークン以外の各4枚5種類の宝石トークンは「2」～「6」の位置に順番が分かるように適当に並べておきます。この場所を便宜的に「ストック」と呼びます。
- 例）「2」の位置：サファイア 「3」の位置：エメラルド …… 「6」の位置：オニキス
- 「2」～「6」の順番は、ゲームの進行中に変わることがあります。
ゲーム開始前
ボットは黄金トークンを1つ受け取ります。
Lv.1の発展カードの山札の一番上にあるカードを表向きにして、それを受け取ります。
つまり、ボットはLv.1の発展カード1枚と黄金トークン1つのアドバンテージを得た上でゲームを開始します。
ゲームの進行
ボットの先攻でスタートします。
ボットの手番の前に
ボットが確保している
- 宝石と黄金トークンの数
- 持っている発展カードの種類と枚数
- 威信ポイント
を数えます。(このカウントは、対人戦でも癖にしておきましょう）
ボットの行動パターン -1- カードの獲得
ボットは以下の行動パターンに沿ってカードを獲得していきます。
- 公開されている発展カード群を確認します。
- ボットは公開されているカード群から一番高い威信ポイントを持つカードを購入します。
- カードの購入に宝石/黄金トークンが必要であれば、その分だけストックに戻して購入します。
- ボットは宝石＞黄金の優先順位でトークンを消費します。
ボットがカードを獲得する基準
- 購入できる中から一番高い威信ポイントを持つカードを購入します。
- 同じ得点を持つ発展カードが複数ある場合は支払うトークンが一番少ないものを選びます。
- Lv.3の発展カードとLv.2の発展カードに同じ3点のカードがある場合は、大概はLv.2の3点のカードが選ばれるでしょう。
上記に従ってカードが買えない場合、ボットは以下の条件に沿ってトークンを獲得します。
ボットの行動パターン -2- 宝石トークンの獲得
条件1:ボットが保有するトークンが0～7個の場合
6面体ダイスを1つ振ります。
- 1が出た：ボットは黄金トークンを獲得します。(カードの確保は行いません)
- 2～6のいずれかが出て、その出目に4枚の宝石トークンがある → 2枚の宝石トークンを獲得します。
- 2～6のいずれかが出て、その出目に3枚以下の宝石トークンがある → その出目から降順に宝石トークンを1枚ずつ獲得します。
- 5や6の場合は、2、3と進みます。（例：6が出たので6、2、3の位置にある宝石を1枚ずつ取得）
- 宝石トークンがなくなった場合は後述するルールに従って全体の場所を詰めていきます。
- 場所が詰められた場合、「6」は「2」として扱います。
条件2:ボットが保有するトークンが8～9個あり、場のカードを購入できない
ボットは黄金トークンを受け取ります。(カードの確保は行いません)
条件3:ボットが保有するトークンが10個あり、場のカードを購入できない
- Lv.3の発展カードの山札の一番上にあるカードをボットは「確保」します。
- この確保されたカードをボットは購入することはありませんが、威信ポイント1点分として扱います。
- もちろん、この威信ポイント1点分はゲーム終了のトリガーの一部として計算されます。
- あくまでも威信ポイント1点分として扱うだけなので、カードを保有しているとは見なしません。（つまり、貴族タイルの条件を満たしません）
この「確保されたカード」は横に置くなどして区別しておきましょう。
条件4:ストックから黄金トークンがなくなり、ダイスで「1」が出た
- 条件3と同じようにLv.3の発展カードの山札の一番上にあるカードをボットは「確保」します。
- 条件3と同じく、確保されたカードは威信ポイント1点分として扱います。
補足: 宝石トークン1種類がストックからなくなった場合
- その場所を詰めます。
- 黄金トークン以外のトークン群を詰めたところからずらしていきます。
- 例) 2の場所にダイヤ / 3にサファイア / 4にルビー…… と並んでいて3のサファイアがストックからなくなった場合は、「2：ダイヤ 3:ルビー……」として全体をずらします。
- プレイヤー、ボットいずれかがそのなくなった宝石トークンをストックに戻した場合は、「6」の位置に並べます。
- 「1」に位置するのは常に黄金トークンです。
- 「1」に位置する黄金トークンがなくなるケースが発生します。その場合は「1」は空白にしておきます。
手番終了時
プレイヤー、ボットともに通常のゲームと同じです。
- カードを購入したのであれば、補充する。
- 宝石トークンが11個以上あれば10枚になるまで捨てる（ただし、このルールではボットは10枚までしか持ちませんので、プレイヤー用のルールです)
- 貴族タイルの条件に従い、貴族が訪問する
- ゲーム終了のトリガーとなる15点以上を獲得しているかを確認する
ゲーム終了
通常のゲームと同じです。ボットが先攻なので
- 手番の最後にボットより先に15点以上を獲得した → プレイヤーの勝利
- ボットが15点以上を獲得した次の手番の最後で同点以上となった → プレイヤーの勝利
- ボットが15点以上を獲得した次の手番の最後でボットより威信ポイントが低い → ボットの勝利
となります。同点だった場合は、カードの少ない方が勝利です。(このカードにはボットが『確保』した威信ポイント1点分のカードは含まれません)
難易度調整
- より簡単なものにしたい場合:
- ボットの最初の手番を飛ばします。（依然として1枚の黄金トークンとLv.1の発展カードは持ったままです）
- より難しくしたい場合：
- 威信ポイント1点分となるカードを増やしていきます。
こんなものまで売られるようになったとは驚きでした。
そのままズバリのリングライト。撮影時、照明は多様性があったほうが助かります。
そして、今回はこれをこのように用いました。
- リングの大きさ
- 撮影対象(figma)がちょうどいいサイズだった
ために可能だった前面からの光。
これにより
こういった撮影ができるようになったのは大きな収穫でした。
ここから更に改良を加えました。
やりたいこと
- 上記抜き出したIPアドレスのリストを日々統合する。
- 自動的にmod_securityのnegativeリストに入れる。
- その上で普段アクセスしているIPアドレスを除外して偽陽性から逃れる。
前提
以下を導入済みです。
- Mod_security
- Apache 2.4.1
- Redmine 4.2
- ログの格納先は /var/lib/redmine/log/
手順
全て管理者権限で実施しました。
ログを格納するディレクトリを作成します。
mkdir /var/lib/redmine/log/suspicious_ip自動実行するスクリプトを作成します。
cd /hoge/
vi negativelist_add.shスクリプト内容
#!/bin/sh
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
cd /var/lib/redmine/log
cat error.log | awk 'match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/) { print substr($0, RSTART, RLENGTH) }' | sort | uniq > /var/lib/redmine/log/suspicious_ip/suspicious_ip.`date +%Y%m%d`
chown www-data:www-data /var/lib/redmine/log/suspicious_ip/suspicious_ip.`date +%Y%m%d`
cat /var/lib/redmine/log/suspicious_ip/suspicious_ip.2* |sort |uniq > /var/lib/redmine/log/suspicious_ip_all.txt
cat suspicious_ip_all.txt > /etc/apache2/sites-available/negativelist.txt
chown www-data:www-data suspicious_ip_all.txt
sed -i /除外したいIPアドレス/d /etc/apache2/sites-available/negativelist.txt
スクリプトに実行権限を設定します。
chmod +x negativelist_add.shApacheの設定ファイルを編集します。
ここでは/etc/apache2/sites-available/redmine-le-ssl.conf にコンフィグを作成済みです。
cd /etc/apache2/sites-available
cp -pi redmine-le-ssl.conf redmine-le-ssl.conf.bak
vi redmine-le-ssl.conf設定ファイル内容
<VirtualHost _default_:80>
servername [redmineのドメイン名]
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
<VirtualHost _default_:443>
servername [redmineのドメイン名]
CustomLog /var/log/redmine/access.log combined
ErrorLog /var/log/redmine/error.log
Alias /redmine /var/lib/redmine/public
# Mod Security
SecRuleEngine On
## ModSecurity有効化
SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000
## ファイルのアップロードをできるようにします。
SecRuleRemoveById 949110
SecRuleRemoveById 941310
SecRuleRemoveById 980130
SecRuleRemoveById 911100
SecRuleRemoveById 200002
SecRuleRemoveById 200003
SecRuleRemoveById 200004
SecRuleRemoveById 959100
## 上記を無効化しないとチケット更新時にエラーとなりました(偽陽性)ため、上記ルールを除外します。
SecRule ARGS:modsecparam "@contains test" "id:4321,deny,status:403,msg:'ModSecurity test rule has triggered'"
## テスト用の検知パラメータを付け加えます。
## Negativelist
SecRule REMOTE_ADDR "@pmFromFile negativelist.txt" "phase:1,id:2,deny,msg:'Negativelisted IP address'"
# /etc/apache2/sites-available/negativelist.txt に記載されたIPアドレスを自動的に遮断します。
<Location /redmine>
PassengerBaseURI /redmine
PassengerAppRoot /var/lib/redmine
Require all granted
<RequireAll>
Require all granted
</RequireAll>
</Location>
SSLEngine on
Protocols h2 http/1.1
Header always set Strict-Transport-Security "max-age=63072000"
SSLCertificateFile [let's encryptが指定した証明書ファイルのパス]
SSLCertificateKeyFile [let's encryptが指定した秘密鍵ファイルのパス]
#Include /etc/letsencrypt/options-ssl-apache.conf
RewriteEngine On
RewriteCond %{HTTP_HOST} ^samplehoge\.hogehoge
RewriteRule ^/$ https://samplehoge.hogehoge/redmine/ [R]
</VirtualHost>
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off
SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"設定を反映します。
apache2ctl configtest
# Syntax OKを確認します
systemctl restart apache2crontabで自動実行できるようにします。
crontab -e追記内容
0 8 * * * /hoge/negativelist.sh
これで、以下の動きができるようになります。
- アクセスログ（エラーログ）に従ってIPアドレスの抜き出し
- 重複を抜き出し、その日にアクセスされた不審なIPアドレスを記載する。
- 蓄積されたIPアドレスを全て統合。重複を抜き出しネガティブリストに上書きする。
- そこから普段アクセスしているIPアドレスを削除する。
昨年から、丸一年経っての出来事です。
ふと思い立ち、丸善の文具コーナーに訪れたら幸運が待っていました。
レモンのチャーム付きLAMY万年筆。
しかも、一番好きなこの明るい緑で彩られています。
昨年のものとは異なり、二つ切りのレモンとまるごとをあしらった形です。
今回のペン先は極細を選びました。
- 割と気に入っているブランドの
- 一番好きな色
- そして書きやすい極細
と、三拍子が揃った道具を入手しました。
発生した事象
Nextcloudにアップロードされた画像をタグ付けしてくれる「recognize」アプリを使っています。
それを用いて運用したところ、以下のエラーに出くわしました。
発生画面
メニュー ＞ Administration settings ＞ 概要
- PHP OPcacheモジュールが正しく設定されていません。詳細はドキュメントを参照してください。
- 「OPcacheのインターン文字列バッファーがまもなく一杯になります。全てのスクリプトをキャッシュに保管できるようにするには、opcahe,interned_strings_bufferの値を8より多い値で、PHP設定に適用することを推奨します。
これを放置していったところ、Webサービスが止まり、SSHにも接続できなくなりました。そのため、以下の対処を施しました。
前提:環境
以下の環境で動いています。
- Ubuntu 20.04
- Apache 2.4.54
- PHP 7.4.32
※snapは使わず、オンプレで構築しました。
また、Opcacheモジュールは設定済みです。
対処
以下、管理者権限で実施しています。
mkdir /etc/old
cd /etc/php/7.4/mods-available
cp -pi opcache.ini /etc/old/opcache.ini.`date +%Y%m%d`
vi opcache.ini設定内容
opcache.interned_strings_buffer=16
; 8 → 16に修正設定反映
apache2ctl configtest
# Syntax OK を確認します
systemctl restart apache2反映確認
メニュー ＞ Administration settings ＞ 概要
へと進みます。
「全てのチェックに合格しました。」
を確認します。
余談:recognizeアプリの注意点
万単位のファイルを既にインポートしたため、画像認識とタグ付けのためにかなりのCPUリソースを消費します。（平均オーバーロードが7を超えるときもありました）
そのため、zabbix等で負荷を監視している場合は認識中は閾値を上げておく等の対処が必要です。