Failed authorization procedure.

ErogameScapeではLet's EncryptのSSL証明書を更新する際に以下のコマンドを実行しています。

# letsencrypt-auto renew --force-renew

今まで問題なかったのですが、本日以下のようなエラーを吐いて更新出来ませんでした。

/root/.local/share/letsencrypt/lib/python2.6/site-packages/cryptography/__init__.py:26: DeprecationWarning: Python 2.6 is no longer supported by the Python core team, please upgrade your Python. A future version of cryptography will drop support for Python 2.6
  DeprecationWarning
Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/erogamescape.dyndns.org.conf
-------------------------------------------------------------------------------
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for erogamescape.dyndns.org
Waiting for verification...
Cleaning up challenges
Attempting to renew cert from /etc/letsencrypt/renewal/erogamescape.dyndns.org.conf produced an unexpected error: Failed authorization procedure. erogamescape.dyndns.org (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout. Skipping.

All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/erogamescape.dyndns.org/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: erogamescape.dyndns.org
   Type:   connection
   Detail: Timeout

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

NOTEに該当する部分はまったく問題ないので、何をどうすれば直るかさっぱり分かりませんでした。
いつもはサブコマンドに「renew」を指定しているのですが「run」を指定してみたら、なぜか更新できました…
※renewとrunの違いは、途中で何かを聞かれるか否かの違い…だと思っています。

# letsencrypt-auto run --force-renew -d erogamescape.dyndns.org
/root/.local/share/letsencrypt/lib/python2.6/site-packages/cryptography/__init__.py:26: DeprecationWarning: Python 2.6 is no longer supported by the Python core team, please upgrade your Python. A future version of cryptography will drop support for Python 2.6
  DeprecationWarning
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for erogamescape.dyndns.org
Waiting for verification...
Cleaning up challenges
Deploying Certificate for erogamescape.dyndns.org to VirtualHost /etc/httpd/conf.d/ssl.conf

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
-------------------------------------------------------------------------------
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
-------------------------------------------------------------------------------
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1

-------------------------------------------------------------------------------
Your existing certificate has been successfully renewed, and the new certificate
has been installed.

The new certificate covers the following domains:
https://erogamescape.dyndns.org

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=erogamescape.dyndns.org
-------------------------------------------------------------------------------

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/erogamescape.dyndns.org/fullchain.pem. Your
   cert will expire on 2017-10-12. To obtain a new or tweaked version
   of this certificate in the future, simply run letsencrypt-auto
   again with the "certonly" option. To non-interactively renew *all*
   of your certificates, run "letsencrypt-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

再度、オプションを「renew」にしたら、更新できました。

# letsencrypt-auto renew --force-renew
/root/.local/share/letsencrypt/lib/python2.6/site-packages/cryptography/__init__.py:26: DeprecationWarning: Python 2.6 is no longer supported by the Python core team, please upgrade your Python. A future version of cryptography will drop support for Python 2.6
  DeprecationWarning
Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/erogamescape.dyndns.org.conf
-------------------------------------------------------------------------------
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for erogamescape.dyndns.org
Waiting for verification...
Cleaning up challenges

-------------------------------------------------------------------------------
new certificate deployed with reload of apache server; fullchain is
/etc/letsencrypt/live/erogamescape.dyndns.org/fullchain.pem
-------------------------------------------------------------------------------

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/erogamescape.dyndns.org/fullchain.pem (success)

何がいけなかったのでしょうか…

インフラエンジニアのスキル(ErogameScape構築/運用の場合)

インフラエンジニアのスキルチェックリストを書き出してみたよを見て、このチェックリストの項目において、ErogameScapeを構築/運用する場合を書いてみます。
※チェックリストにないスキルもいろいろ必要だと思います。一番必要なのはErogameScapeを構築/運用しても苦にならないことじゃないかな…

DB設計

  • 必須 : 要件からDB定義を作成できる
  • 必須 : ER図を作成できる
  • 必須 : 第3正規化まで正規化できる
  • 必須 : パフォーマンスを意識したインデックス設定ができる

パッケージ管理

  • 不要

Webサーバー構築

  • Apacheは必須 : Apache・NginxでWebサーバーを構築できる
  • 不要 : リバースプロキシを設定できる
  • 不要 : エラーログが読める
  • 必須 : バーチャルホストが設定できる
  • たまに必要 : Rewriteのルールが記述できる
  • 必須 : HTTPSのWebサーバーを立てられる
  • 不要 : HTTP/2化できる
  • 不要 : 負荷分散計画が立てられる

DBサーバー構築

  • PostgreSQLは必須 : MySQL / PostgreSQLでDBサーバーを構築できる
  • たまに必要 : DBサーバーのパフォーマンスチューニングができる
  • 必須 : ボトルネックとなっているクエリを特定し改善案が立てられる
  • 必須 : DBレプリケーションが構築できる
  • 必須 : DB MasterのHA化ができる
  • 不要 : DBの水平分割・垂直分割を組める
  • 必須 : 準同期レプリケーションが組める
  • 必須 : レプリケーションが停止した場合に原因対処と復旧ができる

DNSサーバー構築

  • 必須 : DNSの仕組みを理解している
  • 不要 : BINDでDNSサーバーを構築できる
  • たまに必要 : ゾーンファイルを記述できる
  • 不要 : DNSスレーブサーバーを構築できる

メールサーバー構築

  • 不要

キャッシュサーバー

  • 不要

ロードバランサー

  • 必須 : ipvsadm + keepalivedでLVSを構築できる
  • 不要 : PacemakerでHAIPを構成できる
  • 不要 : HAProxyでプロキシサーバーを構築できる
  • 不要 : ヘルスチェックスクリプトを記述できる
  • 知らない : BIG-IPの設定ができる

監視サーバー

  • 必須 : Muninでリソース監視ができる
  • 他は不要

ログ管理

  • 不要

AWS

  • 不要

仮想化

  • 不要

Docker

  • 不要

Ansible

  • 知らない

ストレージ

  • たまに必要 : CUIでパーティション操作ができる
  • 不要 : 各ファイルシステムの特性を理解している
  • 知らない : 誤って削除したファイルの救出方法を知っている
  • 必須 : 容量が肥大化しているファイルを特定できる
  • 必須 : ディスクI/Oを計測しボトルネックを特定できる
  • 必須 : ファイルマスクを理解している
  • たまに必要 : ファイルのタイムスタンプを変更できる
  • RAID1が必須 : RAID0〜RAID10までのRAID構成が組める
  • 必須 : ソフトウェアRAIDとハードウェアRAIDの特性の違いを理解している
  • 不要 : NFS環境が構築できる
  • 不要 : Samba環境を構築できる
  • 知らない : lsyncdを使ってファイル同期環境が構築できる
  • 知らない : テープドライブのCUI操作ができる

ネットワーク

  • 必須 : ネットワークレイヤーの違いを理解している
  • 必須 : ルーターとL3スイッチ、ネットワークハブとL2スイッチの違いを説明できる
  • 不要 : NICの特性を理解している
  • 不要 : BGPを理解している
  • 不要 : DHCPのルールを設定できる
  • 不要 : オートネゴシエーションの特性を理解しオン・オフともに設定できる
  • たまに必要 : WireSharkなどのパケットキャプチャツールを使用することができる
  • 知らない : iperfなどでネットワーク速度を計測できる
  • 不要 : Cisco IOSをCLIで設定できる
  • 不要 : OpenFlowを理解している
  • たまに必要 : ネットワークのボトルネックを特定できる
  • 必要 Luaは知らない: YAMAHA RTXシリーズをCLIで設定できる。Luaで拡張できる
  • 不要 : タグベースVLANやポートベースVLANを構築できる
  • 必要 : PPTP / IPsecのVPNを構築できる

メモリ

  • 不要

ラック

  • 不要


unable to read data from frontend

ErogameScapeではpgpoolを使って冗長構成をとっています。
2つのサーバーマシンのそれぞれにApache、pgpool、PostgreSQLを動かしています。

構成

通常は192.168.0.14に接続するようにしています。
pgpoolを使い始めたころから原因不明で、192.168.0.13がちょいちょい切り離される事象が発生していました。
192.168.0.013のPostgreSQLは問題なく動いていて、keepalivedも切れていないので、pgpoolの問題だと思っていたのですが、切り離された場合のログを見ても、いきなり切れたようにしか見えませんでした。
pgpoolのVerがあがって、PostgreSQLからの応答がない…と判断するまでの時間をかえることができるようになったので、そのパラメータを十分大きくしてみたのですが、NGでした。

切り離される際のpgpoolのログは以下の通りです。

2016-12-27 03:31:33: pid 28889: LOG:  received degenerate backend request for node_id: 1 from pid [28889]
2016-12-27 03:31:33: pid 28889: WARNING:  write on backend 1 failed with error :"Success"
2016-12-27 03:31:33: pid 28889: DETAIL:  while trying to write data from offset: 0 wlen: 5
2016-12-27 03:31:33: pid 13031: LOG:  starting degeneration. shutdown host erogamescape13(5432)
2016-12-27 03:31:33: pid 19938: ERROR:  unable to read data from frontend
2016-12-27 03:31:33: pid 19938: DETAIL:  socket read failed with an error "Connection reset by peer"
2016-12-27 03:31:33: pid 30138: ERROR:  unable to read data from frontend
2016-12-27 03:31:33: pid 30138: DETAIL:  EOF encountered with frontend
2016-12-27 03:31:34: pid 13031: LOG:  Restart all children
2016-12-27 03:31:34: pid 16765: LOG:  child process received shutdown request signal 3
2016-12-27 03:31:34: pid 18712: LOG:  child process received shutdown request signal 3
2016-12-27 03:31:34: pid 18047: LOG:  child process received shutdown request signal 3
2016-12-27 03:31:34: pid 19036: LOG:  child process received shutdown request signal 3
2016-12-27 03:31:34: pid 13031: LOG:  failover: set new primary node: -1
2016-12-27 03:31:34: pid 13031: LOG:  failover: set new master node: 0
たいていこの時間あたりに切り離されるので、朝起きた時に気がついて、復帰させるということをしていました。
この3時30分頃、何が起こっているのか?と思って調べたところ、ログのローテーションの時間なことが分かりました。
そのログの中でもapacheのログのローテートの時間であることも分かりました。
ErogameScapeのApacheのログは1日で350MBくらいなのですが、このログを切り替えてapacheを再起動する際に、pgpoolが他のサーバーマシンで動いているPostgreSQLを切り離すようでした。
※単純にapacheを再起動するだけでは切り離されることはありませんでした。

そこで、Apacheのログが350MBの1/3くらいになるような時間にApacheのログをローテーションすることにしました。
それから2週間…pgpoolが他のサーバーマシンで動いているPostgreSQLを切り離すことはなくなりました…

なぜpgpoolがApacheの350MB程度のログをローテーションする際に、gpoolが他のサーバーマシンで動いているPostgreSQLを作成させて切り離すことがあるのか分からないのが、もやっとしますが、とりあえず切り離されなくなってよかったかなと…





2017年の年始からErogameScapeに接続しづらくなった件の原因について

2016の年末から2017年の年始にかけてPHPを7.1にあげました。
そのタイミングと同時にErogameScapeに接続しづらくなる事象が発生しました。
結論から書くと、PHPのVerUPは関係なく、サーバーを収容しているスイッチのPPPoE向けポートの障害だったことが分かりました。
最終的な切り分け結果を以下に示します。

被疑箇所図
悩まされたのが、開発用から現用系へのpingはOKですが、http接続はOKだったりNGだったりすることでした。
http接続が完全にOKでしたら、スイッチのPPPoE向けポートが悪いと断言できるのですが、微妙にNGになるのです…

被疑箇所のポートに刺さっていたLANケーブルを別のポートに接続したところ事象が発生しなくなったので、おそらくこのポートが被疑だと思います。

PHPのVerを7.1にあげた際に事象が発生したことと、サーバーへのpingはOKとなることから、PHPとApacheを被疑として調査していたのですが、当たり前ですが悪い箇所は見当たらず、しかしApacheを再起動すると直ることが多く(直らないこともありました)、現象は5分程度で自然回復するため、切り分けに時間がかかってしまいました。

調査の対象に「サーバーからPPPoEルータ向けにping」を追加していれば、もっと早く分かった気がいたします。ここの区間は疑っていませんでした。

大きなデータの転送に失敗する

ある日、何回やってもpg_basebackupが失敗する事象が発生しました。
結論から書くと、PPPoEルータの再起動で回復しました。

pg_basebackupは-Pと-vのオプションをつけると、今、どのファイルを送っているのかを見ることができます。
今回の事象は、途中でファイルの転送が止まる…というものでした。

転送が止まった時のメッセージは以下のとおりです。
トランザクションログの開始ポイント: タイムライン18上の35/CE053750
  617773/12835829 kB (4%), 0/1 テーブル空間 (...ive_log/0000001200000035000000B4)
トランザクションログの開始ポイント: タイムライン18上の35/C9000028
3803779/12753907 kB (29%), 0/1 テーブル空間 (...gsql/9.6/data/base/16390/18342.1)
何回かpg_basebackupを試してみたのですが、同じファイルで転送が失敗するわけではありませんでした。
最初は快調にデータを送るのですが、ピタッと転送が止まります。

ErogameScapeは自宅サーバーなので、いつもそこそこの量のパケットをPPPoEルータは処理をしています。
サービス影響は見えなかったので、バックアップ先を疑ってみたり、バックアップ先までのネットワークで大量のデータを送ったときにパケットを阻止している…可能性を疑って、別のサーバーにバックアップを試したり、プロバイダを変更したりしましたがNGでした。

pg_basebackupは-X sオプションをつけると、トランザクションログをストリームするのですが、面白いことにselect * from pg_stat_replicationを見ると、backupの接続は切れるのに、streamの接続は切れずに、淡々と送り続けていました。
これを見て、ネットワークは繋がっいてデータは転送できるのに、backupの接続だけ切れるようにみえて…実際にそうなのですが…pg_basebackupだけを疑って切り分けをしていました。

ちなみにpg_basebackupに-X sオプションをつけて実行した際の、select * from pg_stat_replicationは以下のようになります。2つ接続が開かれているのが分かります。
# select * from pg_stat_replication;
  pid  | usesysid |     usename      | application_name |  client_addr    | client_hostname | client_port |         backend_st
art         | backend_xmin |   state   | sent_location | write_location   | flush_location | replay_location | sync_priority |
 sync_state
-------+----------+------------------+------------------+-----------------+-----------------+-------------+-------------------
------------+--------------+-----------+---------------+----------------+----------------+-----------------+---------------+
------------
 12737 |    16389 | replication_user | pg_basebackup    | ***.***.***.*** |                 |       36151 | 2017-02-12 21:28:1
9.644764+09 |              | backup    |               |                |                |                 |             0 |
 async
 12836 |    16389 | replication_user | pg_basebackup    | ***.***.***.*** |                 |       36152 | 2017-02-12 21:29:2
4.968719+09 |              | streaming | 35/C022FB60   | 35/C022E9C0    | 35/C0000000    |                 |             0 |
 async
(2 行)



その後、大量データをインターネットの向こうにあるサーバーに送ると途中で転送が止まることが分かり、pg_basebackupの問題ではないことが分かりました。

ErogameScapeに使用しているPPPoEルータとは別のPPPoEルータを介してバックアップ先にデータを転送するとOKだったので、ErogameScapeに使用しているPPPoEルータを疑って再起動したところ回復しました。

ああ…こういう不具合が起きることもあるんだなあ…と思った次第です。
ネットワーク機器は、思いもよらない壊れ方をします…
記事検索