俺の、って書いておかないとマサカリ飛んできそうなので。
続きを読む再帰的にディレクトリ内のファイルのハッシュ (md5 値) を取得する
はーなるほどね、あたまいい、と感心していた。 見るまで「ls かなんかでリスト作ってそれをシェルスクリプトで読み込んで md5 通して……」と考えていたのだった。 頭が、頭が固い！
ちなみに僕は macOS 環境で find . -name "*" -exec openssl md5 {} \; とかしてやったんですが、以下のようにディレクトリに対して md5 値を求めるとエラーになるので、そういう出力(*error* とかそんなん) をエディタなり sed なりでガッと消せばきれいになると思います。
❯ openssl md5 ./ColdFusion/bundles/repo Read error in ./ColdFusion/bundles/repo 80A0C0E401000000:error:80000015:system library:file_read:Is a directory:crypto/bio/bss_file.c:148:calling fread() 80A0C0E401000000:error:10080002:BIO routines:file_read:system lib:crypto/bio/bss_file.c:150:
certbot で route53 を利用する際のありがちなエラー
いわゆる --dns-route53 的なオプションつけた時のヤツ。
クレデンシャルがない
Unable to locate credentials To use certbot-dns-route53, configure credentials as described at https://boto3.readthedocs.io/en/latest/guide/configuration.html#best-practices-for-configuring-credentials and add the necessary permissions for Route53 access.
AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY が無くてアクセスできない、というエラー。 とりあえず動かすだけなら、 export で直接値を指定すれば動く。
~/.aws/credentials に複数書いてあって、別のプロファイルを指定したいとかであれば export AWS_PROFILE=プロファイル名; certbot ... などでワンライナーにしてしまうと良い。
クレデンシャルが一致しない
An error occurred (SignatureDoesNotMatch) when calling the ListHostedZones operation: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details. To use certbot-dns-route53, configure credentials as described at https://boto3.readthedocs.io/en/latest/guide/configuration.html#best-practices-for-configuring-credentials and add the necessary permissions for Route53 access.
does not match the signature
そんな馬鹿な、先日このクレデンシャル利用したぞ……と思ってググったら、どうも特殊文字がダメらしい。
問題が出たクレデンシャルを確認したところ、シークレットアクセスキーに / が含まれていた。 他環境のクレデンシャルでは記号が含まれていても / が存在するのは、問題が起きたこれのみだったので、たぶんこれだと思われる。
結局、ManagementConsole からアクセスキー (ユースケース： AWS CLI) を作り直したら無事通った。
boto3
ちなみにエラー出力に含まれる boto3 の best-practices-for-configuring-credentials だけど、見てもあんまり役に立たないのであった。
AWS Fargate Task Maintenance Process Update
なんか物々しいお知らせがきてりゅ！ と思ったら、単純に「AWS が責務を負う Fargate (ECS タスク) インフラ側のセキュリティアップデートが発生したら、0, 7, 14 日の範囲で適用するためのタスクリタイアの期間を選べるよ！」という話だった。 今すぐなにかしろ、という警告ではなかったので、実際に発動するまで様子見の構え。
Lima から DockerDesktop に戻した
あくまで僕の場合ですが。
参加している案件で、 docker-compose.yml にアプリケーション本体と spring を別コンテナで動作させて、 sock ファイルを mount して読む、みたいな実装をしており。
こちらで書いた通り、 Lima+Docker ではこの方法だと実装差異で動かない。
ので、結局 DockerDesktop に戻しましたというお話。
DokcerDesktop から Lima に移行していた理由
変更されたライセンスの問題も多少ありますが一番大きいのは、以前 MacBookPro 2019(Intel) を使っている際に DockerDesktop 環境だとめちゃくちゃ重くて他人の数倍くらい起動に時間がかかるとか、いわゆるコンテナイメージとログファイルが肥大化する (ファクトリーリセットが必要)、みたいな対応に疲れていたという。
M1 にするからちょうどいいや〜、と思って移行したら、今度はプロジェクト側からどえれえ compose ファイルが飛んできてこれもう override で対応できる範囲こえとるな、という風情でした。
一人親方なので、まあ大きい案件に参加するなら自前で課金すればいいし、そうじゃないならちゃんと参加先のトコに払ってもらえばいいだけですね、カァネの話だよォー！
Lima 削除後のお作法
Lima は公式ページで記載ある通り、 macOS 環境なら Applications から削除するだけで消せますが、 VM イメージなどは残ります。
以下の海外兄貴のコメント通りのパスに残っているので、ｼｭｯと rm してください。 ちなみに半角スペースに \ 付与するの忘れて not found が返却され「ナンデ？」となったので一敗です。
リポジトリの移転 (transfer)
基本的に公式のドキュメント通りで大丈夫。
今回は organization 所属のリポジトリを、別の organization に移転した。
危険なゾーンセクション
最初、手順のうち以下の記述が「？」みたいになっていたのだけど、全部日本語翻訳されているせいですね。 DangerZone ……。
ページの下部にある [危険なゾーン] セクションで、 [転送] をクリックします。
チームの選択
移転先の organization でチームを作成している場合、作業時にチームを選択する画面が表示されます。 前述の公式ドキュメントには書いてないですね……。
初回表示される際はなにかチームを選ぶのが必須に見えるんですが、「よくみるとチェックボックスだし、 collaborator と member は移行されるよな」と思って選択しないで Transfer ボタンを押すと次のようになりました。
Do not give any teams access to {移転後の organization/リポジトリ名} という感じで、新しい選択肢が増えました。 最初から表示しといてくれ。
チームにあえて権限付与する必要はないので、こちら選択しておけば大丈夫です。
移転後の注意
移転後に確認していて気付いたのですが、 project が移行されませんでした。
あとから調べた所、大正義クラスメソッドくんでの記述では移転されているのですがウーン？と思っていた所、以下の記述を見つけました。
リポジトリに紐づくタイプのプロジェクトボードでは、別Organizationにリポジトリを移動させたとき、プロジェクトボードに紐づくIssueもリポジトリと一緒に移動するので紐付けに関する問題は特に発生しません。一方で、Organizationに紐づくタイプのプロジェクトボードの場合、プロジェクトボードは移動前のOrganizationに残されるので、プロジェクトボードとIssueの結びつきが切れてしまいます。
はえー、 project にも種類があるんすか？
と思ったけど、リポジトリの Project ページから Link a project, New project どちらを選択しても organization 配下に作成されるからなんか違うのか……？ とここまで考えて気付いた。
このリポジトリ Private だった
このリポジトリ Private だった。
Make a copy
結局、取り残された project を Make a copy 利用して organization またいで copy したあとに、移転したリポジトリから Link a project で関連付けすることで解決できました。
issue が歯抜けになってる……？ かもしれないけど、ワイがハンドリングしているわけでもないのでよくわからんのだった。
collaborators and teams
あとは移転元移転先でユーザ揃えてれば権限も大丈夫なんだけど、たとえば以下みたいな時に Mixed role と警告される。
| 移転元 (Org A) | 移転先 (Org B) |
|---|---|
| Org B からコラボレータとして Write 権限付与して参加 | 生え抜きのユーザ |
自分の所属している organization では、参加したリポジトリ内で付与される権限が Admin が基本なので、移転元の Write がついたままだと Role が混在するよ、という話らしい。
Settings の Collaborators and teams から、 Mixed role になってる人 (基本的に移転先の organization に所属している人だけのはず) の role を Admin にしてやれば解決する。
推測するな憶測するな
事実を元にすればいいんだけど、事実の証明をしないとダメだな？ という風情に。
全般的に「ｳｸﾞｰｯ!!」となったのだけど、個人的には追記の内容、特に沼ったあたりのアレソレが「ありますあります！ (食い気味)」という感じで似た経験ありますあります。
続きを読む