ハトネコエ Web がくしゅうちょう

プログラミングやサーバー・Web制作、チームマネジメントなど得た技術のまとめ

http2 設定で cert renew に失敗

プログラミング系 設定 サーバー Web制作 gRPC SSL/TLS 
sudo cert renew --dry-run

に失敗。

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/xx.yy.com.conf
-------------------------------------------------------------------------------
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for xx.yy.com
Waiting for verification...
Cleaning up challenges

Attempting to renew cert (xx.yy.com) from /etc/letsencrypt/renewal/xx.yy.com.conf produced an unexpected error: 
Failed authorization procedure. xx.yy.com (http-01): 
urn:ietf:params:acme:error:connection :: 
The server could not connect to the client to verify the domain :: 
Fetching http://xx.yy.com/.well-known/acme-challenge/2vTuPTMugzS_MiYSwr_zycQahYwUOjIb3JngrZ2D46I: 
Error getting validation data. Skipping.

今まで何度見たことか……。

nginx のアクセスログにアクセス履歴が残ってなかったので、
「ファイルの作成に失敗……？ 権限周り……？」と疑ったのですが、そうではなく、
結論としては、gRPC用に 80 番ポートにも http2 設定を付けていたこと。

つまり

server {
    listen 80 http2;
    listen [::]:80 http2;
    server_name xx.yy.com;

となっているのを

server {
    listen 80;
    listen [::]:80;
    server_name xx.yy.com;

に戻してあげたら上手くいきました。

謎なのが、この xx.yy.com の認証だけでなくて yy.com や zz.yy.com なども失敗していたのですが、
この xx.yy.com 用の設定を直してあげただけで他も成功するようになったこと。

なんなの？ 連帯責任なの・・・？？

http2 設定を消したことによって 80 番での gRPC の通信ができなくなったけど、
まあ 443 番の方を使うのでそんなに問題は無しですね。

ところで、HTTP/2 って SSL/TLS 通信*1が必須だと思っていたので、
80 番ポートに http2 設定、というのを見て最初は「？」と思ったのですが、
平文（非TLS）の HTTP/2 通信も存在するんですね。

ただ、クライアント側（受け取り手）のサポートがあまりないので、
実質的には SSL/TLS 必須と。そういうことのようです。

基本的にサポートされているのはTLSを使用するh2のみで、多くのWebブラウザでは平文でやり取りを行うh2cについては未サポートとなっている。

（ https://knowledge.sakura.ad.jp/7734/ より引用 ）

逆に言えば、送信側はなにも制限がないので、nginx の80番ポートに http2 設定を書けるのは何もおかしくはないし、
gRPC 用のクライアントが平文の HTTP/2 通信に対応しているのなら、そことやり取りできるわけですね。

*1:厳密にはTLS通信だが、SSL通信という言い方も歴史的に残っているのでこのように書いている

Makefile の変数は大文字を使う？ 小文字を使う？

プログラミング系 Makefile チーム開発 shell

Makefile の変数って、大文字のスネークケース(Screaming snake case)が使われているのをよく見ます。
しかし、公式ドキュメントを読んでいると小文字のスネークケース(Snake case)のパターンもあり、
果たしてどちらを使うべきかわからないでいました。

例えばここのドキュメント では、
foo, bar, include_dirs は小文字で、 CFLAGS や最後の方に出てくる FOO は大文字です。

その答えはちゃんとドキュメントにありました。

答え

https://www.gnu.org/software/make/manual/html_node/Using-Variables.html より引用

It is traditional to use upper case letters in variable names, but we recommend using lower case letters for variable names that serve internal purposes in the makefile, and reserving upper case for parameters that control implicit rules or for parameters that the user should override with command options (see Overriding Variables).

簡単に訳すと、

『伝統的には大文字の変数名が使われてきましたが、
Makefile 内で内部的に使用される変数には小文字の変数名を使い 、また、
Implict Rules を操作するパラメーターや、ユーザーが上書きすべきパラメーターには大文字を予約すること を推奨します』

ということが書いてあります。

Implict Rules （暗黙のルール）についてはここのドキュメントに書かれています。
CFLAGS や LDFLAGS などの、組み込みの変数があたりますね。

あとはユーザーが make 実行時に上書きすることを想定する変数は大文字、
そうでない変数は小文字、ということを意識すれば良さそうです。

例

例えば以下のような使い分けですね。

FILE_NAME := test_001.txt

kernel_info := $(shell uname -a)

.PHONY: dump clean

dump:
   @echo '$(kernel_info)' > $(FILE_NAME)

clean:
  rm $(FILE_NAME)

FILE_NAME はユーザーが実行時に

make dump FILE_NAME=info.txt

などと、好きな値で上書きすることを想定しているとします。

kernel_info はユーザーが実行時に上書きしない想定です。

おわりに

以上、Makefile の変数名の規則でした。
たぶん、すべて大文字で書いている人も多いと思うので、
そういう人を見かけたら、「公式ドキュメントでこう書いてあるので」と案内してあげると、
統一した書き方が社会に広がっていってみんながハッピーだと思います！

（ちなみにこの前も Makefile の変数の話題を書きました。合わせてどうぞ！ ↓）

nekonenene.hatenablog.com

DNSサーバ引っ越し時のメモ

プログラミング系 サーバー Web制作 設定

また忘れそうなのでメモ書き。

基本的に引っ越しは、NS レコードを書き換えて
移行先のDNSサーバに誘導するようにするんだけど、ConoHa はトップドメインの NS レコードを変更できない。

でもそもそも、ドメイン取得サービスの DNS サーバが起点となっているようなのでそこを変更させる。

ドメイン取得サービスの DNS サーバ → ConoHa の DNS サーバ

の設定を変更しない限り、
ConoHa の DNS レコードを削除して、DigitalOcean 側に DNS レコードを設定しても、
1週間たっても名前解決はされるようにならなかったので注意。

ドメイン取得サービスの DNS サーバ → DigitalOcean の DNS サーバ

に経路変更されるよう、ドメイン取得サービスの DNS の NS レコードを変更。
これで移行できる。

移行先の DNS サーバに、サブドメインの CNAME レコードをなにか設定してあげとけば、
NS レコードの変更が反映されたかわかりやすい。