Jenkinsのapt GPGキーを更新する

$ sudo apt update Err:9 https://pkg.jenkins.io/debian-stable binary/ Release.gpg The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 5BA31D57EF5975CA W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://pkg.jenkins.io/debian-stable binary/ Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 5BA31D57EF5975CA W: Failed to fetch https://pkg.jenkins.io/debian-stable/binary/Release.gpg The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 5BA31D57EF5975CA W: Some index files failed to download. They have been ignored, or old ones used instead. ...

2023年4月17日 · aoirint

自宅サーバのDocker NetworkのIPアドレスプールが枯渇した

https://twitter.com/aoirint/status/1617993934625722368 弊自宅サーバでは、サーバソフトウェアや定期実行プログラムのデプロイに、基本的にDocker Composeを使用しています。 先日、新しいソフトウェアをDocker Composeでデプロイしようとして、以下のエラーが発生しました。 Error response from daemon: could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network Docker Networkが使用するIPアドレスプールが枯渇し、新しいIPアドレスブロックを確保できなかったという内容のエラーです。 環境 Ubuntu 20.04 $ docker -v Docker version 20.10.23, build 7155243 $ docker compose version Docker Compose version v2.15.1 原因 このエラーは、30個程度のDocker Networkを作成すると発生するようです。 Docker Composeでは通常、プロジェクト1つあたり、1つのDocker Networkが作成されます(複雑なプロジェクトでは、2つ以上使用することがあるかもしれません)。 手元の環境では、Docker Composeのプロジェクトが27個稼働しており、28個目のプロジェクトを起動したときにエラーが発生しました。 Docker Networkの一覧は、以下のコマンドで確認できます。 docker network ls Docker NetworkのIPアドレスには、いわゆるプライベートIPアドレスの範囲が使用されます。 プライベートIPアドレスの範囲は、以下のようになります(CIDR表記)。 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 作成されたDocker Networkに割り当てられたIPレンジはdocker network inspectコマンドで確認できます。 以下の記事で紹介されているコマンドが便利です。 ...

2023年1月26日 · aoirint

HashiCorpのapt GPGキーを更新する

$ sudo apt update Err:2 https://apt.releases.hashicorp.com focal InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY AA16FCBCA621E701 W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://apt.releases.hashicorp.com focal InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY AA16FCBCA621E701 W: Failed to fetch https://apt.releases.hashicorp.com/dists/focal/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY AA16FCBCA621E701 W: Some index files failed to download. They have been ignored, or old ones used instead. https://developer.hashicorp.com/terraform/cli/install/apt wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor | sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg gpg --no-default-keyring --keyring /usr/share/keyrings/hashicorp-archive-keyring.gpg --fingerprint echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list

2023年1月25日 · aoirint

自宅ネットワークのbind9をdocker composeに移行した

自宅ネットワークのbind9をdocker compose化したので記録。 これまでホストで直接動かしていたけれど、OOM Killerか何かに3,4日に1度くらいでキルされていたので不便だった これでdocker composeのrestart機構で再起動がかかるようになる systemdのrestart機構ワカラナイ Dockerイメージ: https://hub.docker.com/r/ubuntu/bind9 コード docker-compose.yml services: bind9: image: ubuntu/bind9:9.18-22.04_beta restart: always ports: - "0.0.0.0:53:53/udp" volumes: - "./volumes/bind_etc/named.conf.local:/etc/bind/named.conf.local:ro" - "./volumes/bind_etc/named.conf.options:/etc/bind/named.conf.options:ro" - "./volumes/bind_var_cache:/var/cache/bind:rw" - "./volumes/bind_var_lib:/var/lib/bind:rw" environment: - "TZ=Asia/Tokyo" - "BIND9_USER=bind" # UID=101 volumes/bind_etc/named.conf.options acl my-network { 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; localhost; }; options { directory "/var/cache/bind"; response-policy { zone "rpz"; }; allow-query { any; }; allow-recursion { my-network; }; allow-query-cache { my-network; }; dnssec-validation auto; forward only; forwarders { # ISP DNS1; # ISP DNS2; 8.8.8.8; 8.8.4.4; 1.1.1.1; }; } volumes/bind_etc/named.conf.local zone "example.com" IN { type master; file "example.com.zone"; }; zone "rpz" { type master; file "rpz.zone"; allow-query { none; }; }; volumes/bind_var_cache/example.com.zone $ORIGIN example.com. $TTL 3600 @ IN SOA ns.example.com. root.example.com ( 2023012500 ; Serial 3600 ; Refresh 900 ; Retry 604800 ; Expire 86400 ; Minimum ) IN NS ns.example.com. ns IN A 127.0.0.1 @ IN A 127.0.0.1 sub IN CNAME example.com. volumes/bind_var_cache/rpz.zone $TTL 3600 @ IN SOA localhost. root.localhost. ( 2023012500 ; Serial 3600 ; Refresh 900 ; Retry 604800 ; Expire 86400 ; Minimum ) IN NS localhost. ; block malicious domains malicious.example.com A 0.0.0.0 既知の問題 libvirt dnsmasqが53/udpを先に取ると動かなくなりそう? ホストのbind9をアンインストール sudo apt purge bind9 sudo rm -rf /var/cache/bind/

2023年1月25日 · aoirint

OpenVPNとnginxをOpenVPNのPort Share機能で共存させる

TCP 443番ポートは、一般にHTTPSの通信に使われ、ファイアウォールやプロキシによる制限の強いネットワークでも通過できることが多い。 一方、WebサーバをホストしたいIPアドレスと、443番ポートでVPNをホストしたいIPアドレスが同一の場合、443番ポートの取り合い(ポート番号の重複)が起きてしまう。 OpenVPNには、OpenVPNが待ち受けるポートへの通信が、 VPNのパケットか、VPN以外のパケット(例えばnginxへのHTTPS通信)かを自動で判別して、 VPN以外のパケットを中継してくれるPort Share機能がある。 つまり、OpenVPNが443番(0.0.0.0:443)で待ち受け、 nginxは他の適当なポート(例えば127.0.0.1:4443)で待ち受けるようにして、 Port Share機能の転送先をnginxに設定すれば、443番で待ち受けるOpenVPNと、本来443番で待ち受けたいnginxとが共存できる。 UbuntuサーバへのOpenVPNの導入は、以下のDigitalOceanの記事が有用なので、参照されたい。 OpenVPNで使用するサーバー証明書・クライアント証明書を発行するCAサーバをセットアップする記事: https://www.digitalocean.com/community/tutorials/how-to-set-up-and-configure-a-certificate-authority-ca-on-ubuntu-20-04 OpenVPNをセットアップする記事: https://www.digitalocean.com/community/tutorials/how-to-set-up-and-configure-an-openvpn-server-on-ubuntu-20-04-ja OpenVPNのインストールにあたっての重要な点として、 ステップ7 — OpenVPNの設定の(オプション)DNSの変更をプッシュして、VPNを介してすべてのトラフィックをリダイレクトするを実行した上で、 ステップ9 — ファイアウォールの設定を手順通り実行することがある。 NAT下にあるなどの理由でufwの設定をしていなかったサーバーでも、新たにufwの設定をすることで、トラブルなくOpenVPNのインストールができる。 このステップを行わないと、VPN外へのパケットの転送が動作せず、VPN接続中のクライアントがインターネットに接続できない状況に陥る。 また、(オプション)ポートとプロトコルの調整で、待ち受けポートを443番、プロトコルをTCPにしておく。 OpenVPNの起動の際には、nginxとポート番号を取り合って起動に失敗しないように、nginxをあらかじめ停止し、ポート番号を書き換えておく。 nginx 設定ファイル /etc/nginx/sites-enabled/などにあるnginxの設定ファイルを書き換え、 4443番で待ち受けるようにする。 server { listen 4443 http2 ssl; } 大量にサイトをホストしている場合、コマンドやVSCodeなどでまとめて書き換えるとよい。 /etc/openvpn/server/server.conf OpenVPNのサーバー設定ファイルにport-shareを追記する。 port 443 port-share 127.0.0.1 4443 proto tcp OpenVPNからnginxへのパケット転送の許可(ufw) ufw allow from 10.8.0.0/24 to any port 4443 nginx, OpenVPNの再起動 nginxおよびOpenVPNを再起動し、443番ポート宛てのHTTPS通信(nginx宛て)、443番ポート宛てのVPN接続(OpenVPN宛て)が正常に動作することを確認する。

2022年10月19日 · aoirint

nginx, リバースプロキシからのReferrer-Policyヘッダを置換する

add_header Referrer-Policy no-referrer; # add_header Referrer-Policy same-origin; proxy_hide_header Referrer-Policy; # remove Referrer-Policy from original response https://takuya-1st.hatenablog.jp/entry/2018/11/01/040000 https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Referrer-Policy https://stackoverflow.com/a/55692346 Mastodon Mastodonでリファラを送らないようにしたかった。 HTMLタグのmetaタグを使う方法をよく使うのだけれど、 ブログとかによくあるheadタグへの任意HTML追加機能のようなものは Mastodon v3.5.3にはなさそうだった。 https://github.com/mastodon/mastodon/issues/9183 同一オリジンでもリファラを送らないようにする(no-referrer)とMastodonの一部の設定が更新できなくなくなるようなので、 MastodonではReferrer-Policy: same-originに設定した。 単純にadd_headerするだけだと、Mastodonが返すReferrer-Policyとnginxが追加するReferrer-Policyで2つのヘッダになってしまった。 referrer-policy: origin referrer-policy: no-referrer そこで、 proxy_hide_header Referrer-Policy; でMastodonから返ってきたReferrer-Policyを削除するようにした。 あとは、 add_header Referrer-Policy same-origin; するだけ。 https://mstdn.aoirint.com/@aoirint/108569086590516035

2022年7月1日 · aoirint

Let's Encrypt Failure Rate Limit

設定に自信がないときは、Rate limitが緩いLet’s EncryptのStaging環境で試してから本番環境でやり直す Staging環境を使うには、certbotのオプションに --test-cert をつける 本番環境の場合、1時間内に5回失敗すると一時的に弾かれるようになる(too many failed authorizations recently) Staging環境の場合、1時間内に60回失敗まで緩められている 本番環境 https://letsencrypt.org/docs/rate-limits/ Staging環境 https://letsencrypt.org/docs/staging-environment/

2022年6月16日 · aoirint

Use MinIO with AWS CLI

AWS S3互換を意識して、設定にあたってMinIOに依存しすぎないようにしたい (それはそれとしてMinIO ClientはAWS S3互換クライアントとして便利らしい) https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html aws-cli version: 2.7.7 curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" unzip awscliv2.zip sudo ./aws/install https://awscli.amazonaws.com/v2/documentation/api/latest/reference/index.html --endpoint-urlで操作対象をAWS S3からMinIOに変更できる https://awscli.amazonaws.com/v2/documentation/api/latest/topic/config-vars.html AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS以外の認証情報を~/.aws/credentialsに保持するのもいまいちな感があるので、環境変数に設定することにする (AWSのIAM?がどうなってるのかよくわからんけど、本来マニュアルオペレーションするときはAWSのアカウントで認証するのかな?) https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-services-s3-commands.html まずは特権アクセスでBucketを作る MinIOのrootユーザのユーザ名・パスワードを設定する(MINIO_ROOT_USER、MINIO_ROOT_PASSWORD) export AWS_ACCESS_KEY_ID=minioadmin export AWS_SECRET_ACCESS_KEY=minioadmin Bucket一覧 aws --endpoint-url http://127.0.0.1:9000 s3 ls Bucket作成(create-bucketも大して変わらんと思うので、あえて高レベルAPIのs3 mbを使わなくていい気もするけどまあいいでしょう) aws --endpoint-url http://127.0.0.1:9000 s3 mb s3://mybucket アクセス制御(Policy)周りはS3と一部互換性がない Policyの構文自体はほぼ同じに作られているけれど、仕様が違うように思われる(AWS S3の仕様をよく知らんけど) https://github.com/minio/minio/issues/9530#issuecomment-625883667 Bucket policyはパブリックアクセスのルール、User/ServiceAccount Policyは認証付きルールと使い分ければいいと思われる Bucket policyはAWS S3互換APIから設定できる User/ServiceAccount PolicyはAWS互換APIから設定できないのでWeb UIまたはMinIO Clientから設定する Bucket policy: allow anonymous user (public) to read mybucket/* { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "*" ] }, "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::mybucket/*" ] } ] } PrincipalはMinIO上のBucketとしては意味がないと思うが、Web Consoleでいじると必要だといわれるので付けておく ...

2022年6月10日 · aoirint

PIDから対応するdockerコンテナを見つける

docker-pidパッケージが便利 https://www.glia-computing.com/blog/listing-process-ids-on-docker-containers/ https://github.com/masatanish/docker-pid pip3 install docker==5.0.3 docker-pid==0.0.3

2022年5月22日 · aoirint

Self-hosted GitLab Runnerで安全にdockerを扱えるようにするためにどうしたらいいかわからない

適当に検索すると、ホストへの特権昇格を許す設定ばかり見かける。 自分だけしか使わないならば構わないかもしれないけれど、なんらかのCIを実行する権限さえあれば、ホストのroot権限をとれるというのは危険だと思う。 (コードレビュー必須でPRではマージ済みのCIが実行されるならいいのか…?) GitLabの公式Shared Runnerがやっているように、docker-machineを使うのがいいはず。 おそらくdocker入りの仮想マシンをCIジョブごとに立てて、privilegedなコンテナからブレイクアウトしても仮想マシンの外に出られないようになっていると思う。 GitLabはいろいろオープンなので、実際のShared Runnerの構成・設定が公開されている。たいへん助かる。 https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html のだけれども、GCPでこれを稼働させるのはちょっと費用面がよくわからない…。 ツリー https://twitter.com/aoirint/status/1523826104343343105 https://twitter.com/aoirint/status/1524426103615500288

2022年5月10日 · aoirint