投稿者: manualmaton Page 114 of 273

ZENタイルとPENケース。

話は少し遡り、

先月の末に旅行をしていたときのこと。

旅行中でも日々の記録を行うために

  • ほぼ日手帳(日記)
  • 筆記具
  • Chromebook
  • iPad mini

は持ち歩いています。その筆記具の中に

ZENタイル Soloを入れておいたのが、かなり助かりました。

ペンケースを忘れることはかなり考えにくい習慣を続けているので、どんなときでも勘定の整理を行えるの安心感は相当のものです。

また、タイルの小ささも幸いし、ペンケースのポケットに入れられるのもお気に入りです。

そのおかげで旅先でも、

オフィスでも記録可能。

記録をする時間がかなりフレキシブルになりました。

二面打ち、追加。

  • 繰り返し遊ぶものなのでコンポーネントの劣化を防ぐために持っておきたい
  • オーガナイザーが魅力的なので買ってしまった
  • 記念版が出たのでそれと差し替えた

などの理由で複数買いしたボードゲーム。

『アグリコラ』や『ブルゴーニュの城』などがその範疇に含まれておりました。

そして、その仲間に新たにこちらが加わりました。

『ガイアプロジェクト』です。

  • 銀河を惑星改良して入植し
  • 技術ツリーを上げていき
  • 各種建物の改良によって資源を変換し
  • 種族の繁栄を目指す

中毒性が極めて高いボードゲーム。こちらが再販されたので、この度入手したという次第です。

飾る場所とか整理とかどうしようという状況がすでに発生しているものの、まぁ、そこは少しずつ解決してこうと思います。

ボードゲーム『ぬくみ温泉開拓記』対人戦雑感。

ボードゲーム『ナナイロアジサイ』を遊んだ日――

念願の『ぬくみ温泉開拓記』の対人戦を行ってきました。

相手は湯もみ、こちらは麦酒売。

相手の性質上、スタートプレイヤーでのアドを取るためにこちらは逆に「空いているところに施設を建てる」の戦略を取りました。

当然のように

  • より多い資金
  • 多く引けるチップ
  • 充実の施設

などで負けがほぼ確定した中での第4ラウンド。

助っ人「托鉢僧」で楽しさトラックがマックスになったことでダイスボーナス×3のチャンスが生まれます。そこでの結果が

  • 黄金
  • 黄金
  • 2金

と、強烈なもの。この時点での残り資源は3。すかさず金鉱掘りのアクションを取って次のラウンドに備えます。

最終ラウンド、しっかりと黄金×3をバッグから引けて40勝利点の施設《ぬくみ御殿》を建てることができて、一気に巻き返しました。

この逆転劇がなければ確実に負けていただけに、最終的に運に救われました。

そして、このゲームで思ったことは以下のとおりです。

  • 動き回るべし
  • スタプレと喧嘩しない方が伸び伸びと開拓できる
  • 「○○のあと移動してもよい」系の助っ人は神
  • 追加アクションは何をおいても移動系を取る
  • 終盤における工芸品店の爆発力は異様
  • ぬく丸を追いかけまわすプレイング強い
  • 悩む前に移動

「コンスタントに移動する手段をどう確保するか」がこのゲームの肝でした。

ボードゲーム『ナナイロアジサイ』感想。

コンポーネントやアートワーク、そしてシステムまで含めて「紫陽花」を体現したボードゲームです。

【ゲームシステム】

完全なアブストラクト。「6色オセロ」と思っていただければ分かりやすいです。

プレイヤーは3色(3人の場合は2人)の花コマを持ち、手番ごとに花コマをプレイシートに置いていきます。

両端を同じ色ではさむことで間の色が変わるのは通常のオセロと同じ。そこに紫陽花らしく色移ろいなるフィーチャーが加わります。

花コマを置いた後、隣接するコマの色が

  • 桃の隣に赤を置いた:隣接する桃の花が赤に変わる
  • 赤の隣に橙を置いた:隣接する赤の花が橙に変わる

と言った具合にグラデーションのように変化。

こうして全てのマスをシートに置ききったらゲーム終了。シート内の花の数を数え、一番多い花を担当しているプレイヤーの勝利となります。

【素晴らしいと思ったところ】

[完全一致のアートとシステム]

  • ゲームシステム
  • コンポーネント
  • アートワーク
  • ルール

のどれをとっても「紫陽花」。局面によって移りゆく花の色も、完成した盤面も紫陽花。

[角を取っても安心できないルール]

オセロと異なり、隣接する花の色が伝播。これによって一つの角をとっても取り返されて逆転されるケースが多々発生しました。

[有限の花の色]

担当する花の色はそれぞれ13個で固定。この花の色を使い切ったとしても「オセロのように挟まないと変わらない白の花」に置換されることで、逆に置きすぎるリスクが発生。 そして、色に強弱が存在するので

「こっちを置きすぎたから他の色を活かすには」 「その上で担当する花が一番多くなるには」

といったリソース管理が悩ましいものになります。

[変化を見越したジレンマ]

上述するルールによって、

「今置けば確実にこの場は支配できるけど次にこれを打たれるからビッグアクションはできない」 「逆転されそうだけどここに花を置いておけば後々取り返せる」

といったジレンマに終始悩まされます。

【やや残念だと思ったところ】

[アブストラクト特有の実力差]

運が絡まないゲームの宿命です。明らかに実力差があるという場合は勧められません。

【まとめ】

  • とても映える盤面
  • イメージしやすいルール
  • サクサク終わるのにジレンマ満載

と、花言葉「移り気」を含めて紫陽花を再現した見事なゲームです。

AWS LightsailとLet’s Encryptによるワイルドカード証明書発行。

ひょんな事から無料でドメインを取得。このドメインを軸に「mkcertではなくLet's Encryptでもワイルドカード証明書が発行できないか」と思って試してみました。

やりたいこと

  • せっかく手に入れたドメインなので、自宅でそれを用いる。
  • mkcertを用いている自宅内サーバのgrowiをLet's Encryptに差し替える。

前提

以下は準備済みです。

  • AWS Lightsailで運用しているUbuntu 20系サーバがある
  • ドメインを取得している
  • certbotを運用している

手順

作業対象が手順によって異なります。

手順 -1- ドメイン設定

  1. lightsailのDNS設定で取得したドメインを有効にします。
  2. お名前.comのDNSサーバの向き先をlightsailのものに設定します。
  3. lightsailのAレコードに「自分が運用しているローカルサーバのIPと適当な名前」を設定して紐付けます。

手順 -2- ワイルドカード証明書発行コマンド入力 (lightsail側サーバ)

sudo certbot certonly --manual \
    --preferred-challenges dns-01 \
    --server https://acme-v02.api.letsencrypt.org/directory \
    -m 自分のメールアドレス \
    -d *.ドメイン名

入力後、以下のようにTXTレコードを登録するように求められます。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name
_acme-challenge.ドメイン名 with the following value:

DNSに登録するレコードの値

Before continuing, verify the record is deployed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue

ここではまだEnterは押しません。

手順 -3- TXTレコード追加 (AWS Lightsail管理画面)

lightsailのDNS設定で

  • TXTのレコード
  • サブドメイン:_acme-challenge
  • 「以下で応答します」にDNSに登録するレコードの値

をそれぞれ設定して反映させます。

反映後、別のターミナルで以下を実行します。

nslookup -type=TXT _acme-challenge.登録したドメイン名 8.8.8.8

結果が返ってきたら次のステップに進みます。

手順 -4- ワイルドカード証明書発行 (lightsail側サーバ)

手順-2-で押していなかったEnterを押します。

以下のようにパスとファイルが明示されているので、そのパスの内容を控えておきます。(外部に公開しないよう注意します)

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/ドメイン名/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/ドメイン名/privkey.pem
   Your certificate will expire on 2023-01-09. To obtain a new or
   tweaked version of this certificate in the future, simply run
   certbot again. To non-interactively renew *all* of your
   certificates, run "certbot renew"

hostsファイル書き換え(growiサーバ側)

/etc/hostsファイルを

IPアドレス lightsailで設定したフルドメイン サブドメイン

で修正します。

証明書差し替え

こちらを元に、証明書を差し替えます。

動作確認

証明書差し替え → nginx再起動後、「AWS Lightsailで設定したドメイン名」でアクセスします。

DNS情報がインターネット上に公開されているので

  • 同じNWにつながっていれば、DNSを明示していなくともアクセスできる
  • mkcertのように端末に証明書をインポートせずに済む

のがLet's Encrypのいいところです。

袋、差し替え。(ボードゲーム『ぬくみ温泉開拓記』コンポーネント)

コンポーネントのアップグレードもまた、ボードゲームの楽しみの一つです。

資源チップを入れる布袋を

手作りの巾着へと差し替えです。しかも、作品のモチーフとなっている猫柄。

リバーシブルとなっているので、プレイヤーの区別もつけやすくなります。

サイズもピッタリのマスターピースでした。

ボードゲーム『ぬくみ温泉開拓記』ソロプレイ、パートナー(A面)雑感。

ボードゲーム『ぬくみ温泉開拓記』のソロプレイ、全てのパートナー(A面)で一通りこなしましたので、使ってみた感想です。

湯もみ

猫(ぬく丸)を捕まえることで追加ボーナス。ただ、ソロプレイは対人プレイ以上にNPCがぬく丸を捕まえてしまうので自由に動けませんでした。

麦酒売

ダイスボーナスをどう使っていくか。また、助っ人を多く引ける可能性が高いので、それらを用いながらのアクションが印象的です。

板前

「強い」と思った職業1。連動して上がっていく美味しさトラックと楽しさトラック。これによって資金と資源に不足することなく、最高レベルの料亭が何軒も建ちました。

詐欺師

「強い」と思った職業2。毎ターンほぼ確実に黄金チップを得られ、40勝利点の建物やワイルドカードになっていく様は文字通り詐欺くさい動きでした。その分デメリットは強烈(ゲーム終了時に資金を半分失う)ですけれど、それはプレイングで補えます。

貿易商

乱戦・混戦で強さを発揮します。移動系のアクションスペース(木材で移動2なら最高です)を得れば圧倒的な資金力で得点を稼げます。

あんま師

変則的なチップ上昇。なので、資源集めに集中するターンと一気に施設を建設するターンのメリハリが重要でした。

まとめ

個人的に

板前 ≧ 詐欺師 > 貿易商 = あんま師 > 麦酒売 ≧ 湯もみ

って感じの強さでした。

こちらはあくまでも自分のプレイスタイルと合致しているかどうかなので、もう少し研究すれば強さが変わる余地は十二分にあります。

growiサーバのログローテーション。

この記事で設定していたgrowiサーバ、ログの設定が漏れていたので追加しました。

手順

すべて管理者権限で実施しています。

ローテート設定追加

vi /etc/logrotate.d/growi

 ファイル内容

/var/log/nginx/chisataki.lyco.reco/*.log {
    daily
    rotate 10
    missingok
    notifempty
    sharedscripts
    compress
    delaycompress
    postrotate
        /usr/sbin/nginx -s reopen >/dev/null 2>&1 || true
    endscript
}

今回は

  • 日毎にログを取る
  • ローカルなので保存期間は10日

としています。

動作確認

logrotate -d /etc/logrotate.d/growi

でエラーが出ないことを確認しました。

ボードゲーム『ぬくみ温泉開拓記』ソロプレイで見過ごしやすいこと。

ここのところ、平日の夜でも本作のソロプレイを行っています。

そんな中、見落としやすいポイントが2つあったのでメモを残します。

NPCの最短距離

ソロプレイではNPCがぬく丸スポットを目指し「最短距離」で歩いていきます。

この「最短距離」というのがポイントであり、

普通に歩くのではなく馬車を用いたほうが歩数が少ないのであれば、NPCはその手段を執ります。(そして、どの距離が近いかはプレイヤーが知っているはずです)

NPCの足跡の扱い

NPCはダイスに沿って移動します。そして、その移動した「足跡」全てにキューブを置きます。

このキューブの上にプレイヤーは施設を建てることはできません。そして、これらのキューブは「施設」として扱います。したがって

土産物屋や工芸品の店といった周囲の施設によってボーナスが見込める施設の恩恵に預かることができます。

この、貿易商のように得られる資金の数で追加の勝利点を得るパートナーでは特に注意が必要でした。

nginxとapache連携。(リバースプロキシー&SSLアクセラレータ)

自室のサーバに専用redmineを運用するようになって半年ほど。一つの課題が浮かび上がりました。

課題

現状、

  • redmine
  • フォトアルバム
  • growi

を自宅サーバ群で運用中。Webサービスが増えるたびに「証明書更新をサーバ毎に行うのが面倒」です。ワイルドカード証明書を用いて、シンボリックリンクの張り替えで済むようにしてもなお各サーバに同じ設定を行うのは手間がかかる上にミスが生じる温床となります。

施策

そこで、既にgrowiサーバで運用しているnginxのリバースプロキシーをredmineにも拡張するようにしました。

やりたいことは以下です。(IPアドレスとドメインは便宜上です)

sequenceDiagram participant クライアント participant nginx as nginxサーバ<br> 192.168.1.30<br>abc .local participant redmine as redmine<br> 192.168.1.99<br>xyz.local クライアント->> nginx: abc.localにhttpアクセス par クライアント~nginxはhttps通信 note over nginx: httpsにリライト nginx -->> クライアント: httpsでの接続要求 and nginx~redmineはhttp通信 クライアント ->> nginx: redmineにhttpsアクセス note over nginx: SSLデコード nginx -->>+ redmine: クライアントからの要求を<br>redmine(xyz.local)に送信 redmine -->>- nginx: redmineのデータを送信 end nginx ->> クライアント:redmineからのデータを<br>abc.localとしてhttpsで送信

サクッとまとめると

  • redmineサーバのリバースプロキシーとしてnginxを利用
  • クライアント~nginxは常時SSL通信
  • nginx ~ redmineはhttp通信

これにより、SSLを導入する箇所をnginxサーバのみとします。

前提

以下を用意しています。

  1. nginxサーバ (仮IP: 192.168.1.30)
  • mkcertでローカル証明書を導入済み
  1. redmineサーバ(apacheで稼働)(仮IP: 192.168.1.99)
  2. ローカルDNSに以下を登録します。(自分の環境に読み替えます)
  3. abc.local - 192.168.1.30
  4. xyz.local - 192.168.1.99

環境

ともにUbuntu Linux 20.04系で動いています。

手順

全て管理者権限で実施します

redmineサーバでの設定(apache)

以下、ファイルを編集します。

vi /etc/apache2/sites-available/redmine.conf
ファイル内容
<Location /redmine>
PassengerBaseURI /redmine
PassengerAppRoot /var/lib/redmine
Require all granted
</Location>

Alias /redmine /var/lib/redmine/public

<VirtualHost 192.168.1.99:80>
    ServerName  abc.local
    ErrorLog /var/log/redmine/error.log
    CustomLog /var/log/redmine/access.log combined

        RewriteEngine On
        RewriteCond %{HTTP_HOST} ^abc\.local
        RewriteRule ^/$ http://abc.local/redmine/ [R]
</VirtualHost>

設定反映

a2ensite redmine.conf
apache2ctl configtest
#Syntax OKを確認
systemctl restart apache2

nginxサーバでの設定

hostsファイル追記

vi /etc/hosts
追記内容
192.168.1.30 abc.local

nginx confファイル作成

vi /etc/nginx/sites-available/redmine.conf
ファイル内容
upstream abc {
       server 192.168.1.99:80;
}

server {
        listen 80;
        server_name abc.local;
        server_tokens off;
        return  301 https://$host$request_uri;
        access_log /var/log/nginx/redmine/access.log;
        error_log /var/log/nginx/redmine/error.log warn;
}

server {
        listen 443 ssl http2;
        server_name abc.local;
        server_tokens off;
        ssl_session_timeout 1d;
        ssl_session_cache shared:SSL:50m;
        ssl_session_tickets off;
        ssl_dhparam /etc/nginx/dhparam.pem;
    #openssl dhparam -out /etc/nginx/dhparam.pem 2048 として作成します(環境によっては5分以上かかります)
        ssl_ciphers 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;
        ssl_prefer_server_ciphers off;
        add_header Strict-Transport-Security 'max-age=63072000';

        ssl_certificate /etc/certs/local.crt;
       # 証明書のパスに読み替えます
        ssl_certificate_key /etc/private/local.key;
      # 秘密鍵のパスに読み替えます

        access_log /var/log/nginx/redmine/ssl_access.log;
        error_log /var/log/nginx/redmine/ssl_error.log warn;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_max_temp_file_size 10240m;
        client_max_body_size 10240m;
        proxy_buffer_size 10240m;
        proxy_buffers 10 10240m;
        proxy_busy_buffers_size 10240m;
        proxy_redirect off;

       set $proxy_target  'abc';

       location / {
          proxy_pass http://$proxy_target;
       }
}

設定反映

ln -s /etc/nginx/sites-available/redmine.conf /etc/nginx/site-enabled/redmine.conf
nginx -t
# syntax is ok と test is successfulを確認します
systemctl restart nginx -t

確認

ローカルNWに接続されているクライアントのブラウザから

http://abc.local

にアクセスし、

  • https://abc.local/redmine の内容が出てくること
  • SSL通信ができていること

を確認します。

Page 114 of 273

Powered by WordPress & Theme by Anders Norén