ct state related,established counter acceptの位置

iptables、nftablesの設定は「すでに確立した通信(established)および関連したパケット(related)を許可する」ルールを必ずいれます。
nftablesの場合は
add rule ip filter INPUT ct state related,established  counter accept
iptablesの場合は
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
のようになります。
いろいろな書き方がありますが、Webサーバーの場合は
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT
-A INPUT -m state –state NEW -m tcp -p tcp –dport 443 -j ACCEPT
と書いて、このあとすべてDROPのルールをいれるか、INPUTのpolicyをDROPにしておくかして、ルールにマッチしないパケットはDROPします。

さて、上記のルールにWebサーバーにアクセスしてほしくないネットワークを追加したいと思ったとき、次の①と②のどちらに追加した方がいいでしょうか。
①
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
②
-A INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT
-A INPUT -m state –state NEW -m tcp -p tcp –dport 443 -j ACCEPT
ErogameScapeでは…理由はすでに覚えていないのですが(理由はなかったのかもしれません…)①の位置にDROPするルールを追加していました。
-A INPUT -s XXX.XXX.XXX.XXX/24 -j DROP
-A INPUT -s YYY.YYY.YYY.YYY/24 -j DROP
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT -A INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT -A INPUT -m state –state NEW -m tcp -p tcp –dport 443 -j ACCEPT
おかしなアクセスを発見するたびに、DROPするルールを追加しており、今では3000行程度になっています。
①の位置にDROP追加すると困ったことがあります。
それは、内側からのパケットの応答をDROPしてしまうことです。
例えば、yum updateしようとしたら、リポジトリがブロックしたネットワークに存在していたため、パッケージをupdateできない…というようなことが起きます。
※ちなみにいちいちiptablesを外す…ということをしていました。

おそらく②の位置でも問題ない…と思ったので、②の位置に変更しました。
※何か問題があったら教えてほしいです。

10年以上、①の位置で運用していて、②の位置に変更したら、CPU使用率が劇的に下がりました。
以下のmuninのCPU usageのグラフのとおり、systemとsoftirqの値が劇的に下がっています。
cpu_usage

softirqの値が大きいのはなぜだろう…と思ってsoftirqについて調べるも全然わからなかったのですが、パケットを受信するたびに3000程度のルールとのマッチングをしていたので、CPUを酷使していたようでした。

pgpool + PostgreSQLの構成においてテーブルをロックしているPostgreSQLのSQLをキャンセルしたい

この文書はPostgreSQL11.7とpgpool4.1.1の話題です。

なんらかの理由でテーブルをロックしたままのPostgreSQLのSQLをキャンセルしてロックを開放したい場合以下の関数を使います。


この関数は成功するとtrueを返すのですが、trueが返ってきたからといって、キャンセルできる(プロセスを終了できる)わけではありません。
以下に例を示します。
ap2=# select l.pid , a.backend_start from (select pid from pg_locks group by pid) l,pg_stat_activity a where l.pid=a.pid order by query_start;
  pid  |         backend_start
-------+-------------------------------
 10673 | 2020-05-06 14:06:57.721961+09
 18222 | 2020-05-06 15:52:12.091632+09
 28546 | 2020-05-06 16:30:04.77062+09
(3 rows)

ap2=# SELECT pg_cancel_backend(10673);
 pg_cancel_backend
-------------------
 t
(1 row)

ap2=# SELECT pg_cancel_backend(18222);
 pg_cancel_backend
-------------------
 t
(1 row)

ap2=# select l.pid , a.backend_start from (select pid from pg_locks group by pid) l,pg_stat_activity a where l.pid=a.pid order by query_start;
  pid  |         backend_start
-------+-------------------------------
 10673 | 2020-05-06 14:06:57.721961+09
 18222 | 2020-05-06 15:52:12.091632+09
 28546 | 2020-05-06 16:30:04.77062+09
(3 rows)
10673と18222のプロセスを終了したいのですが、終了できません。
pg_terminate_backend(pid int)を使うと終了できるのですが、pgpoolを使っている場合、pg_terminate_backendを使うとpgpoolがPostgreSQLを切り離すので、サービスが中断します。

ErogameScapeにおいて、上記のようにpg_cancel_backendがきかないのは以下のような状況のときのようでした。

Apacheにアクセス
php-fpmがpgpoolにクエリを発行
pgpoolがPostgreSQLにクエリを発行
クエリの実行に時間がかかる
一定時間たってもphp-fpmから応答がないのでApacheがtimeoutとしてユーザーに504を返す
このあとpsコマンドで確認すると
pgpoolはidleもしくはidle in transaction
PostgreSQLはSELECTだったりUPDATEだったりpgpoolが発行したSQLを実行している状態

以下、例を示します。
[root@sakura ap2]# cat /var/log/httpd/access_log | grep update
127.0.0.1 - - [08/May/2020:04:40:01 +0900] "GET /~ap2/ero/toukei_kaiseki/update_userreview_display_log.php HTTP/1.1" 504 247 "-" "Wget/1.19.5 (linux-gnu)" 60027802
127.0.0.1 - - [08/May/2020:04:41:02 +0900] "GET /~ap2/ero/toukei_kaiseki/update_userreview_display_log.php HTTP/1.1" 504 247 "-" "Wget/1.19.5 (linux-gnu)" 60060326
127.0.0.1 - - [08/May/2020:04:42:04 +0900] "GET /~ap2/ero/toukei_kaiseki/update_userreview_display_log.php HTTP/1.1" 200 462 "-" "Wget/1.19.5 (linux-gnu)" 6428
[root@sakura ap2]# cat /var/lib/pgsql/11/log/postgresql-Fri.log
2020-05-08 04:41:10.718 JST [28908] [ap2] LOG:  duration: 8271.792 ms  execute : UPDATE userreview SET display_unique_count = coalesce( display_unique_count , 0 ) + $1 WHERE uid = $2 AND game = $3 ;
ap2=# select * from (select pid from pg_locks group by pid) l,pg_stat_activity a where l.pid=a.pid order by query_start;
  pid  |  datid   | datname |  pid  | usesysid | usename | application_name | client_addr | client_hostname | client_port |
        backend_start         |          xact_start           |          query_start          |         state_change
  | wait_event_type | wait_event | state  | backend_xid | backend_xmin |
     query                                                         |  backend_type
-------+----------+---------+-------+----------+---------+------------------+-------------+-----------------+-------------+-
------------------------------+-------------------------------+-------------------------------+-----------------------------
--+-----------------+------------+--------+-------------+--------------+----------------------------------------------------
-------------------------------------------------------------------+----------------
 28908 | 10934808 | ap2     | 28908 |    16385 | ap2     |                  | 127.0.0.1   |                 |       55878 |
2020-05-08 04:41:01.103872+09 | 2020-05-08 04:41:02.407331+09 | 2020-05-08 04:41:02.446477+09 | 2020-05-08 04:41:02.446478+0
9 | Client          | ClientRead | active |    17877103 |              | UPDATE userreview SET display_unique_count = coales
ce( display_unique_count , 0 ) + $1 WHERE uid = $2 AND game = $3 ; | client backend
この状態で
SELECT pg_cancel_backend(28908);
しても、28908を終了させることができません。

28908を使っているpgpoolのプロセスを殺したところ、28908を終了させることができました。
pcp_proc_infoコマンドで28908を使っているpgpoolのプロセスIDを確認します。
[ap2@sakura ~]$ pcp_proc_info -h /var/run/postgresql/ -U pgpool | grep 28908
Password:
ap2 ap2 2020-05-08 04:36:00 2020-05-08 04:41:01 3 0 2 28908 1 27546 0
28908と27546のプロセスを確認します。
[ap2@sakura ~]$ ps ax | grep 27546
 8121 pts/0    S+     0:00 grep --color=auto 27546
27546 ?        S      0:00 pgpool: ap2 ap2 127.0.0.1(58634) idle in transaction
[ap2@sakura ~]$ ps ax | grep 28908
 8134 pts/0    S+     0:00 grep --color=auto 28908
28908 ?        Ss     0:00 postgres: ap2 ap2 127.0.0.1(55878) UPDATE
27546をkillします。
※確か、kill 27546では殺せなくて、kill -KILL 27546で殺しました。
これで、28908のプロセスも開放されて、ロックされていたテーブルもロックが解除されました。

※そもそも、なぜpostgresがSELECTやUPDATEのまま止まってしまうのかの原因は未だ分かりません…

nothing provides module(perl:5.26) needed by module perl-DBD-Pg:3.7:8010020200204214655:0d1d6681-0.x86_64

契機はわかりませんが、以下のとおりModular dependency problemsが発生していました。
[root@localhost ap2]# yum list installed
モジュラーの依存に関する問題:

 問題 1: conflicting requests
  - nothing provides module(perl:5.26) needed by module perl-DBD-Pg:3.7:8010020200204214655:0d1d6681-0.x86_64
 問題 2: conflicting requests
  - nothing provides module(perl:5.26) needed by module perl-DBI:1.641:8010020191113222731:16b3ab4d-0.x86_64
 問題 3: conflicting requests
  - nothing provides module(perl:5.26) needed by module perl-FCGI:0.78:8010020191114031513:16b3ab4d-0.x86_64

以下略
結論から書くと、CentOS 8 conflicting requestsのと同じで、dnf module enable perl:5.26で回復しました。
[root@localhost ap2]# dnf module enable perl:5.26
メタデータの期限切れの最終確認: 0:15:24 時間前の 2020年05月05日 12時03分44秒 に実施しました。
依存関係が解決しました。
============================================================================================================================
 パッケージ                   アーキテクチャー            バージョン                     リポジトリー                 サイズ
============================================================================================================================
モジュールストリームの有効化:
 perl                                                     5.26

トランザクションの概要
============================================================================================================================

これでよろしいですか? [y/N]: y
完了しました!
[root@localhost ap2]# yum list installed | more
インストール済みパッケージ
ModemManager-glib.x86_64                   1.10.4-1.el8                                      @BaseOS
NetworkManager.x86_64                      1:1.20.0-5.el8_1                                  @BaseOS
以下略
dnf module enable perl:5.26の前の状態は以下
[root@localhost ap2]# dnf module list perl
CentOS-8 - AppStream
Name             Stream                  Profiles                        Summary
perl             5.24                    common [d], minimal             Practical Extraction and Report Language
perl             5.26 [d]                common [d], minimal             Practical Extraction and Report Language

ヒント: [d]efault, [e]nabled, [x]disabled, [i]nstalled
dnf module enable perl:5.26の後の状態は以下です。
[root@localhost ap2]# dnf module list perl
CentOS-8 - AppStream
Name             Stream                  Profiles                        Summary
perl             5.24                    common [d], minimal             Practical Extraction and Report Language
perl             5.26 [d][e]             common [d], minimal             Practical Extraction and Report Language

ヒント: [d]efault, [e]nabled, [x]disabled, [i]nstalled
なぜdnf module enable perl:5.26で依存関係の問題が解消されるのか分かりませんでした。

SSLProtocolの書き方

ApacheでSSLの通信をする際は、SSLProtocolのディレクティブの設定が必要です。
2020/05/04現在では以下のように書きます。
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
ErogameScapeでは、TLSv1.2だけにするために以下のように書いていました。
SSLProtocol TLSv1.2
TLS1.3にも対応するため、誤って以下のように書いてしまいました。
SSLProtocol TLSv1.3 TLSv1.2
この書き方だと、TLS1.3だけ適用されて、TLS1.2は無視されます。
apachectl configtestも通り、Apacheは問題なく起動してしまいます。
TLS1.3とTLS1.2の両方を許容したい場合は以下のように「+」をつける必要があります。
SSLProtocol +TLSv1.3 +TLSv1.
もしくは、
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
のように書きます。
※2020/05/04時点で、IE11はTLS1.3に対応していないので、IE11を使ってErogameScapeにアクセスしているユーザーさんからの申告で気がつきました。

pg_basebackup: ベースバックアップの初期化中 - チェックポイントの完了を待機中です

pg_basebackupを実行しても、pg_basebackupがはじまらない場合は、チェックポイントの完了を待っている可能性があります。
-bash-4.1$ pg_basebackup -r 10M -X s -S replication_slot -h erogamescape.dyndns.org -p 5432 -U replication_user -D /var/lib/pgsql/11/data --write-recovery-conf -P -v
pg_basebackup: ベースバックアップの初期化中 - チェックポイントの完了を待機中です
チェックポイントの完了を待てない場合は、チェックポイントを実施すれば、すぐにpg_basebackupが開始されます。
ap2=# CHECKPOINT;
LOG:  duration: 5910.506 ms  statement: CHECKPOINT;
CHECKPOINT

pg_basebackup: チェックポイントが完了しました
pg_basebackup: 先行書き込みログの開始ポイント: タイムライン26上の55/363790E8
ただし、チェックポンイトの処理は負荷がかかるので、業務との兼ね合いでCHECKPOINTするかしないかになります。
ちなみにpg_basebackupのオプションに「--checkpoint=fast」をつけると、pg_basebackupを実行した際にすぐにCHECKPOINTを実行します。

以下参考文書です。
記事検索