Let's encrypt standaloneをwebrootに変更

standaloneで取得した場合、一度apacheなりnginxを停止してcertbotを動かさないといけないのが面倒なので、standaloneの設定をwebrootに書き換えます

Problem binding to port 80: Could not bind to IPv4 or IPv6

 書き換えない場合は上記のようにエラーメッセージがでます

 

 

1.設定ファイルの変更

/etc/letsencrypt/renewal/exsample.com.conf
authenticator = standalone
を下記に変更
authenticator = webroot

下記[[webroot_map]]を追加(半角になおしてください)

[[webroot_map]]
exsample.com = /usr/share/nginx/html


2.nginx.confの変更
該当ドメインの「location /」より前に入れると良い

    location ^~ /.well-known/acme-challenge/ {
         root /usr/share/nginx/html;
    }
    location = /.well-known/acme-challenge/ {
         return 404;
    }

変更後は設定を反映
# systemctl reload nginx

 

3.certbotを起動 --no-self-upgradeはcertbotの自動更新を停止
# certbot --no-self-upgrade renew

 

4.root cronにも登録(日曜 3時3分にrenewを実行 有効期限が30日以内で更新)

3 3 * * 0 /usr/bin/certbot renew --no-self-upgrade --post-hook "/usr/bin/systemctl reload nginx"

 

Let's encrypt (certbot-auto)の任意バージョンダウンロード

2020年1月1日にPython2系のサポートが終了するので、その後certbot-autoがどうなるのかわかりませんが、ちょこちょこバージョンアップしています

 

最新版のダウンロード(現時点では 1.0)

$ wget https://dl.eff.org/certbot-auto

 

セルフアップデートせずに renew するには「--no-self-upgrade」を付けます

$sudo certbot-auto renew --no-self-upgrade

証明書の有効期限の確認方法

$sudo certbot-auto certificates --no-self-upgrade

certbotのバージョン確認

$sudo certbot-auto --version --no-self-upgrade

なにをするにも --no-self-upgrade を付けないと、アップデートされます

 

古いcertbot-autoはどこでダウンロードできると探してみたら (pipでも可)

https://pypi.org/project/certbot/0.40.1/#files pip install certbot==0.40.1

 https://pypi.org/project/certbot/0.39.0/#files pip install certbot==0.39.0

https://pypi.org/project/certbot/0.38.0/#files pip install certbot==0.38.0

https://pypi.org/project/certbot/0.37.2/#files pip install certbot==0.37.2

上記よりダウンロードできました。URLの数字を変更すると良いです

 

certbotの変更履歴は下記より表示できます(記事を書いた日に1.0リリース)

Dec 3,2019 https://community.letsencrypt.org/t/announcing-certbot-1-0/107756

  • certbot-auto has deprecated support for systems using OpenSSL 1.0.1 that are
    not running on x86-64. This primarily affects RHEL 6 based systems.
  • Certbot’s config_changes subcommand has been removed
  • certbot.plugins.common.TLSSNI01 has been removed.
  • Deprecated attributes related to the TLS-SNI-01 challenge in
    acme.challenges and acme.standalone
    have been removed.
  • The functions certbot.client.view_config_changes,
    certbot.main.config_changes,
    certbot.plugins.common.Installer.view_config_changes,
    certbot.reverter.Reverter.view_config_changes, and
    certbot.util.get_systemd_os_info have been removed
  • Certbot’s register --update-registration subcommand has been removed
  • When possible, default to automatically configuring the webserver so all requests
    redirect to secure HTTPS access. This is mostly relevant when running Certbot
    in non-interactive mode. Previously, the default was to not redirect all requests.

Nov 6, 2019 https://community.letsencrypt.org/t/certbot-0-40-1-release/105649

Nov 6, 2019 https://community.letsencrypt.org/t/certbot-0-40-0-release/105632

We deprecated support for Python 3.4 in Certbot and its ACME library. Support
for Python 3.4 will be removed in the next major release of Certbot.
certbot-auto users on RHEL 6 based systems will be asked to enable Software
Collections (SCL) repository so Python 3.6 can be installed. certbot-auto can
enable the SCL repo for you on CentOS 6 while users on other RHEL 6 based
systems will be asked to do this manually.

Oct 2, 2019 https://community.letsencrypt.org/t/certbot-0-39-0-release/103255

Sep 4, 2019 https://community.letsencrypt.org/t/certbot-0-38-0-release/101245

Aug 22, 2019 https://community.letsencrypt.org/t/certbot-0-37-2-release/100418

Aug 9, 2019 https://community.letsencrypt.org/t/certbot-0-37-1-release/99478

Aug 8, 2019 https://community.letsencrypt.org/t/certbot-0-37-0-release/99367

Jul 12, 2019 https://community.letsencrypt.org/t/certbot-0-36-0-release/97677

Jun 12, 2019 https://community.letsencrypt.org/t/certbot-0-35-1-release/95630

Jun 6, 2019 https://community.letsencrypt.org/t/certbot-0-35-0-release/95226

 

 

spfレコードの設定

spfレコードの設定例 (+は省略可能)

・「v=spf1 +mx -all」 Mail eXchangeのIPだけ認証する

・「v=spf1 +ip4:192.168.0.1 +ip4:192.168.1.1 -all」 記述されたIPアドレスだけ認証する

・「v=spf1  -all」 メールを送信しない場合

・「v=spf1 include:_spf.google.com ~allgmailを利用する場合

 

~all と -all の違い

”~all” と記述することは、メール受信者に対して、「受信時に認証が失敗したとしても、はっきりと認証失敗としては扱ってほしくない」と宣言することを意味しているため、”-all”で問題がなければ、できる限り避けるべきであるとされている。

https://www.nisc.go.jp/conference/suishin/adviser/dai5/pdf/sankou.pdf

 

 

設定したSPFの確認

dmarcian.commxtoolbox.com

SPFの設定例:

salt.iajapan.orgwww.naritai.jp

QNAP TS-231P firmware 4.3.6からアップデートできない

現象:4.3.6から4.4.1にあげるのに「firmware update error 4」とでて30%から進まない

 

なぜかQNAPのLiveUpdateでFirmwareが上がらなかったので覚書

4.3.6の最後2019年09月19日版をダウンロードして、Firmwareの更新が出来たらLiveUpdateが復活

 

4.3.6.0923 build 20190425 今ここ

4.3.6.1070 build 20190919 https://www.qnap.com/ja-jp/download?model=ts-231p&category=firmware よりダウンロード

↓ LiveUpdate

4.4.1.1117 build 20191109

 

めっちゃよく見たら答えがそのまま書いてあった

https://www.qnap.com/en-us/how-to/knowledge-base/article/what-to-do-if-ts-x31px31-meets-error-fw004-while-doing-firmware-upgrading

 
TS-231P

ファームウェアがアップデートできない』

https://bbs.kakaku.com/bbs/K0000925628/SortID=23014531/

 

nagios normal_check_interval retry_check_intervalが使えなくなっていた

nagios 4.4.3以降で

WARNING: The normal_check_interval attribute is deprecated and will be removed in future versions. Please use check_interval instead.
WARNING: The retry_check_interval attribute is deprecated and will be removed in future versions. Please use retry_interval instead.

とでていたので変更

 

各設定の所で

normal_check_interval → check_interval

retry_check_interval → retry_interval

に記述し直して

nagios -v nagios.cfg してWARNING が無くなるまで

systemctl reload nagios で設定反映(CentOS7)

 

dockerで管理していたLet's encryptの証明書(TLS-SNI-01)を最新に更新した

3/15に証明書の期限が切れるということで、dockerのことはよくわからない状態からスタート

利用していたのは

  • jwilder/nginx-proxy
  • jrcs/letsencrypt-nginx-proxy-companion

調べればよく出てくる構成。この下にSSLを使うドメインがぶら下がっている

 

現状の把握

  • docker ps -a 起動しているdockerの一覧の取得

  • docker network ls docker networkの取得
  • docker-compose ps docker-composeで起動している一覧

詳細を見たいなら

  • docker inspect name コンテナの詳細
  • docker network inspect name networkの詳細

色々調べていくと「jwilder/nginx-proxy」「jrcs/letsencrypt-nginx-proxy-companion」の組み合わせは「nginxproxy_default」networkをデフォルトで使うと理解

 

docker-compose.yml を見つけて内容を確認

version: '2'
services:
  nginx-proxy:
  image: jwilder/nginx-proxy
  container_name: nginx-proxy
    ports:
    - 80:80
    - 443:443
    volumes:
    - ./certs:/etc/nginx/certs:ro
    - /etc/nginx/vhost.d
    - /usr/share/nginx/html
    - /var/run/docker.sock:/tmp/docker.sock:ro
   restart: always

letsencrypt-nginx-proxy-companion:
   image: jrcs/letsencrypt-nginx-proxy-companion
   container_name: nginx-letsencrypt
   volumes:
   - ./certs:/etc/nginx/certs
   - /var/run/docker.sock:/var/run/docker.sock:ro
   volumes_from:
   - nginx-proxy
   restart: always

 

nginx-letsencryptのコンテナの中に入ってみる

docker exec -it nginx-letsencrypt bash

中を探しても、certbotはない、どうやらコンテナを新しくする必要がありそうと気付き

github.com起動した後からの履歴を見てみると、TLS-SNI-01の対応したのは1.10付近と推測(HTTP-01)

1.9 released this Aug 12, 2018
1.9.1 released this Sep 30
1.10 released this Jan 8, 2019

とりあえず、先にダウンロードしておいて問題ないから

docker pull jrcs/letsencrypt-nginx-proxy-companion

docker pull jwilder/nginx-proxy

最新を取得する

 

jrcs/letsencrypt-nginx-proxy-companionに気になることが書いてあったのでDNS CAAをあらかじめ設定しておく

「Your DNS provider must answers correctly to CAA record requests.」

blog.apar.jp

後は覚悟を決めて

docke-compose.ymlのあるディレクトリに移動

cd /path/to/dir

docker-composeで起動しているサービスを停止

docker-compose stop
Stopping nginx-letsencrypt ... done
Stopping nginx-proxy ... done

docke-compose 起動

docker-compose up -d
Recreating nginx-proxy ...
Recreating nginx-proxy ... done
Recreating nginx-letsencrypt ...
Recreating nginx-letsencrypt ... done

 無事起動。ぶら下がっているサイトにアクセスも可。証明書の期限は伸びていない!?

 

docker ps -aするとnginx-letsencryptが延々とrestartingと出ている

コンテナにログインしようとしても

docker exec -it nginx-letsencrypt bash

Error response from daemon: Container 6bd1ea10cb646c4236c28086ce4e807d7850f693fdbb6946874b53b6ed16bc0f is restarting, wait until the container is running

 

codenote.net

コマンドで確認

docker logs contena_id

2019/03/08 14:13:36, Error: can't get my container ID !
Error: can't get nginx-proxy container ID !
Check that you are doing one of the following :
- Use the --volumes-from option to mount volumes from the nginx-proxy container.
- Set the NGINX_PROXY_CONTAINER env var on the letsencrypt-companion container to the name of the nginx-proxy container.
- Label the nginx-proxy container to use with 'com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy'.

こんな感じで延々とでていたので、NGINX_PROXY_CONTAINERとは?と思いググると答えが

aroundthedistance.hatenadiary.jpdocker-compose.yml

docker-compose.yml
environment:
NGINX_PROXY_CONTAINER: rg-proxy

 なるほどと思い docker-compose.ymlを下記のように変更

version: '2'
services:
  nginx-proxy:
  image: jwilder/nginx-proxy
  container_name: nginx-proxy
    ports:
    - 80:80
    - 443:443
    volumes:
    - ./certs:/etc/nginx/certs:ro
    - /etc/nginx/vhost.d
    - /usr/share/nginx/html
    - /var/run/docker.sock:/tmp/docker.sock:ro
   restart: always

letsencrypt-nginx-proxy-companion:
   image: jrcs/letsencrypt-nginx-proxy-companion
   container_name: nginx-letsencrypt
   volumes:
   - ./certs:/etc/nginx/certs
   - /var/run/docker.sock:/var/run/docker.sock:ro
   volumes_from:
   - nginx-proxy

   environment:
     NGINX_PROXY_CONTAINER: nginx-proxy
   restart: always

docker-compose stop

docker-compose up -d

を実行

docker下のサイトにアクセスして証明書の期限が伸びているのを確認

 

理解するのに参考になったのが

tech.quartetcom.co.jp

morizyun.github.io

 

docs.docker.jp

nagiosとslackの連動設定 携帯メールの余分なデータを削除

利用する物 slack webhook URL https://api.slack.com/incoming-webhooks

nagios の commands.cfg への記述

define command {
     command_name notify-service-by-slack
     command_line $USER1$/slack_service_notify.sh "$NOTIFICATIONTYPE$" "$HOSTNAME$" "$HOSTADDRESS$" "$SERVICEDESC$" "$SERVICESTATE$" "$SERVICEOUTPUT$" "$LONGDATETIME$"
}

define command {
     command_name notify-host-by-slack
     command_line $USER1$/slack_host_notify.sh "$NOTIFICATIONTYPE$" "$HOSTNAME$" "$HOSTADDRESS$" "$HOSTSTATE$" "$HOSTOUTPUT$" "$LONGDATETIME$"
}

---

contacts.cfg に上記の追加 (notify-host-by-slack,notify-service-by-slak)
host_notification_commands notify-host-by-epager,notify-host-by-slack
service_notification_commands notify-service-by-epager,notify-service-by-slack

---

プログラム URL /usr/lib64/nagios/plugins/ に設置

https://github.com/obaarne/Nagios2Slack/blob/master/slack_host_notify.sh
https://github.com/obaarne/Nagios2Slack/blob/master/slack_service_notify.sh

vi等で開いて

SLACK_URL=

を自分のwebhook アドレスに変更して保存

 

動作確認:

slack_host_notify.sh

slack_service_notify.sh

を実行して該当チャンネルに書き込まれると成功

 

参考:

github.com 

exchange.nagios.org

 

携帯メール(notify-*-by-epager)で余分なデータを削除

notify-host-by-epager ホスト関連の通知

 define command{
     command_name notify-host-by-epager
     command_line /usr/bin/printf "%b" "Host '$HOSTALIAS$' is $HOSTSTATE$\nInfo: $HOSTOUTPUT$\nTime: $LONGDATETIME$" | /usr/bin/mail -s "$NOTIFICATIONTYPE$ alert - Host $HOSTNAME$ is $HOSTSTATE$" $CONTACTPAGER$
}

これを

define command{
     command_name notify-host-by-epager
     command_line /usr/bin/printf "%b" "'$HOSTALIAS$' is $HOSTSTATE$\n$HOSTOUTPUT$\n$LONGDATETIME$" | /usr/bin/mail -s "$NOTIFICATIONTYPE$ alert - Host $HOSTNAME$ is $HOSTSTATE$" $CONTACTPAGER$
}

削るデータは

Host

Time:

 

notify-service-by-epager サービス関連の通知

define command{
     command_name notify-service-by-epager
     command_line /usr/bin/printf "%b" "Service: $SERVICEDESC$\nHost: $HOSTNAME$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\nInfo: $SERVICEOUTPUT$\nDate: $LONGDATETIME$" | /usr/bin/mail -s "$NOTIFICATIONTYPE$: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$" $CONTACTPAGER$
}

これを

define command{
     command_name notify-service-by-epager
     command_line /usr/bin/printf "%b" "$SERVICEDESC$\n$HOSTNAME$\n$HOSTADDRESS$\n$SERVICESTATE$\n$SERVICEOUTPUT$\n$LONGDATETIME$" | /usr/bin/mail -s "$NOTIFICATIONTYPE$: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$" $CONTACTPAGER$
}

削るデータは先頭の

Service:

Host:

Address:

Info:

Date:

 

以上