Lycolog

このオプションはGoogle Chrome 112.0.5615.49にはありませんが、116.0.5845.188, 117.0.5938.88, 120.0.6099.225では表示されていました

Windows 11でGoogle Chromeを利用しているケースで正確な位置情報が取得できない場合の対処方法の紹介です。KING OF TIMEとかUberEatsの位置情報取得が上手く行かないときに使えると思います。

確認環境

手順

1. Windowsの設定を開く
2. プライバシーとセキュリティ＞位置情報を開く
3. デスクトップアプリに位置情報へのアクセスを許可するをON

   1. 

4. 以下のアドレスを開き設定をEnabledに変更
   1. chrome://flags/#enable-winrt-geolocation-implementation

   2. 

5. Google Mapsなど適当な位置利用サイトを開き、位置情報取得操作を行う
6. 位置情報の利用を許可
7. Windows側の位置情報が反映されればOK

関連記事

• Windows 11で既定の位置を設定出来ないのを解決する

この記事では設定のプライバシーとセキュリティ＞位置情報にある「既定の位置」の「既定値に設定」が動かない場合の解決法を紹介します。

確認環境

問題事象

「既定値に設定」ボタンを押しても何も起きない

解決方法

1. Microsoft Storeを開く
2. Mapsで検索
3. Windowsマップというアプリを入手する

   1. 

4. 設定のプライバシーとセキュリティ＞位置情報を開く
5. 「既定の位置」の「既定値に設定」をクリックする

   1. 

6. マップアプリが開き座標を選択できれば解決です

あとがき

せめてマップアプリが入ってませんとかエラーくらい出してほしい
問題が起きてるときはボタン押しても何も起きないので意味不明すぎる…

keychainというパスフレーズを記憶させるツールを使って記憶させます
shellの初回起動時にパスフレーズを入力させられ、以降多分再起動するまで記憶しておいてくれる気がします

確認環境

手順

1. keychainのインストール
   1. sudo apt install keychain
2. keychainの設定
   1. .zshrcとかに次の行を追加
   2. keychain -q --nogui --agents gpg --quick <GPGのkeyid>
      1. GPGのkeyidはgpg --list-secret-keys --keyid-format=longで取得可能

トラブルシュート

ssh と gpg 両方記憶させたい

こんな感じで書くと行ける。shell起動時にSSHのPW -> GPGのPWの順で入力ダイアログが出てくる

keychain -q --nogui --agents ssh,gpg --quick $HOME/.ssh/id_ed25519 <GPGのkeyid>

GPG のキーが見つからないエラーが出る

• Warning: can't find DEADBEEF; skipping

上記が出た場合
~/.gnupg/gpg.confに対して以下の記述をすることで改善する可能性がある（この対策は不完全かもしれない

keyid-format LONG

IPv6のOCNバーチャルコネクト環境ではwell-known portsが利用出来ずWebサーバーを公開するのに支障がありますが、今回はそれを乗り越えるための手法を紹介します。

自宅サーバーにhttps://service.example.com/のようにポート指定なしのサブドメインでアクセスできるようにするのがゴールです。

構成

自宅サーバーの手前にCDNを挟み、CDNを経由して接続させるようにします。要するに手前にリバプロを生やしておくわけです。

前提

• Google Domainsを利用している
• ルートドメインを保有している
• AWSのアカウントがある
  • ない場合はこっから作りましょう

前準備

DNS レコードに次のドメインを作っておく

自宅サーバーを公開可能な状態にする

叩き台程度ならserveを使うのが手っ取り早いですが、Node.jsでサーバー立てるのもありだと思います。今回は叩きなのでHTTPにしていますが本番運用するときはHTTPSにしましょう。

以下サンプル

const http = require('http');

const port = 12345;

const server = http.createServer((req, res) => {
    res.writeHead(200, { 'Content-Type': 'text/plain' });
    res.end('Hello world!');
    console.log(req.headers.host, req.socket.remoteAddress);
});

server.listen(port, () => {
    console.log(`Running at http://localhost:${port}`);
});

手順

1. CloudFrontを開く
2. 「ディストリビューションを作成」
3. 「オリジンドメイン」にcdn.example.comを設定
4. 「プロトコル」を選ぶ
5. cdn.example.comの「ポート」を設定する
6. 設定までスクロール
7. 「代替ドメイン名 (CNAME) - オプション」で「項目を追加」しservice.example.comを入力
8. 「カスタムSSL証明書 - オプション」で「証明書をリクエスト」
9. 「パブリック証明書をリクエスト」
10. 「完全修飾ドメイン名」にservice.example.comを入力し「リクエスト」
11. 「証明書を表示」
12. DNSレコードに「CNAME名」で「CNAME値」を追加
13. 「保留中の検証」が終わるのを待つ
14. 「カスタムSSL証明書 - オプション」で作成した「ACM証明書」を選択
15. 「ディストリビューションを作成」
16. service.example.comのDNSレコードをCNAMEにし、データを「ディストリビューションドメイン名」に変更
17. https://service.example.com/にアクセスできればOK

参考資料

• 代替ドメイン名 (CNAME) を追加することによるカスタム URL の使用 (docs.aws.amazon.com)

トラブルシュート

ディストリビューションを削除したい

1. ディストリビューションの一覧で消したいのにチェック入れて無効化
2. しばらく待つ
3. 消したいのにチェック入れて削除

参考：ディストリビューションを削除する (docs.aws.amazon.com)

後書き

副次的効果ですがCDN挟んでキャッシュされてるお陰で連続アクセスしてもサーバーまでリクエスト来ないので感動しました。

CloudFrontには他にも様々な機能があるみたいなので活用できれば便利そうです。

公式のドキュメントには書かれていない気がするがDockerだけあればセットアップ可能。WSL2でのセットアップが面倒なVargantは不要

本記事ではWSL2内のUbuntuの中でDockerとDocker Composeを使った構築法について記述する。Windows向けのDocker Desktopは使用しない

前提

• WSL2のUbuntuにVSCodeで接続して作業
• 起動してログイン、トゥート、設定と言った最低限の画面操作が可能な程度まで

確認環境

手順

1. git clone https://github.com/mastodon/mastodon.git
   1. 最新版などバージョン指定が必要な場合は追加でtagをチェックアウトする
2. VSCodeでClone先を開く
3. Reopen Containerする
4. セットアップが走るので暫く待つ
5. foreman startを流す
6. http://localhost:3000/ へアクセス

操作方法

ユーザーを作ったりしたい場合、Using the admin CLIが参考になる

一例としてユーザー作成は次の書式で行ける

./bin/tootctl accounts create foo --emaill foo@example.com --confirmed

トラブルシュート

DB接続エラーが出る

ActiveRecord::ConnectionNotEstablished at /
could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql//.s.PGSQL.5432"?

上記のエラーが出る場合、ビルドしたDockerイメージが壊れてるので以下のコマンドで全て消して作り直すとうまく行く

docker rm -f `docker ps -a -q`
docker rmi `docker images -q`
docker system prune

他のMastodonインスタンスが動かない

複数のMastodonインスタンスのDocker環境を同居させると多分コンフリクトする