GitHubは12月9日（現地時間）、npmのクラシックトークンの廃止と新しい認証システムの導入を発表した。これにより、従来のクラシックトークンはこの日をもってすべて無効となり、再利用や再作成はできなくなった。
今後npm loginによる認証では2時間限定のセッショントークンが発行され、認証を継続する場合は再認証が必要となる。加えて、npmは新たなCLIツールを提供し、開発者はコマンドライン上で細かな権限トークンの作成・確認・無効化を行えるようになった。
⇧ う～む、「npm」の「クラシックトークン」ということで、「personal access tokens (classic)」所謂、「PAT」とは別物ということですかね、分かり辛い...
本当に、「GitHub」における「トークン」について、整理して欲しいよね...
pg_basebackupの物理バックアップの取得の際にnohup（no hang up）と&を利用する
同じチームのメンバーに連携してもらったので、備忘録として。
バックアップ対象のデータのサイズが大きかったりすると、処理に時間がかかることあるあるだと思います。
長時間の処理になると、何某かのタイミングで「接続」が「切断」されることあるあるだと思います。
そんな時に、
nohup- 実行したいコマンド、または、スクリプト
&
を組み合わせることで幸せになれるかもしれないという話。
「nohup」については、
⇧ 上記のドキュメントの内容を参考。
以下の3つの項目を組み合わせることで、「ネットワーク」の「接続断」などが発生して、「シェル」の「セッション」が途切れた場合も処理を継続してくれますと。
| No | 項目 | タイプ | 内容 |
|---|---|---|---|
| 1 | nohup |
GNU版 | nohup（no hung up）とあるように、ハングアップ信号を無視するが、&と併用しないとバックグラウンド実行されない。 |
| 2 | コマンド、または、スクリプト | - | 実際に実行したいコマンド、または、スクリプト。 |
| 3 | & |
- | バックグラウンドのプロセスとして実行されるようにする。 |
ちなみに、「バックグラウンド」で実行された処理については、
⇧ 上記サイト様によりますと、
『じつはさっきのプロセスはLinuxのカーネル(OSの中核部分に位置するソフトウェア)さんから見た時の処理の単位だった。これに対しシェル(ターミナル)から見た時の単位をジョブという。』
『コマンドライン1行に対して、１つのジョブになる。』
とのこと。
ややこしいですな...
話を元に戻すと、「nohup」については、
⇧ 上記サイト様が詳しいです。
なのだが、参考サイト様の「MySQL」の例だと「パスワード」を指定できるようなのだが、「PostgreSQL」の「pg_basebackup」コマンドについては、
⇧ 公式のドキュメントにあるように、「パスワード」を指定する「オプション」が無いのである...
では、どうするのか？
33.14. 環境変数
-
PGPASSWORDはpassword接続パラメータと同様に動作します。 この環境変数は、一部のオペレーティングシステムではroot以外のユーザがpsコマンド経由で環境変数を見ることができるなど、セキュリティ上の理由から現在では推奨されていません。 代わりにパスワードファイル(33.15を参照してください)を使用することを検討してください。
https://www.postgresql.jp/document/12/html/libpq-envars.html
33.15. パスワードファイル
ユーザのホームディレクトリの.pgpassは、接続にパスワードが必要な場合(かつ、他に指定されたパスワードが無かった場合)に使用するパスワードを格納するファイルです。 Microsoft Windowsでは、このファイルの名前は%APPDATA%\postgresql\pgpass.conf(ここで%APPDATA%はユーザのプロファイル内のアプリケーションデータディレクトリ)です。 他に、接続パラメータpassfileを利用するか、環境変数PGPASSFILEで、パスワードファイルを指定できます。
https://www.postgresql.jp/document/12/html/libpq-pgpass.html
Unixシステムにおいて、パスワードファイルの権限はグループ、他者へのアクセスをすべて拒否しなければなりません。 これはchmod 0600 ~/.pgpassといったコマンドによって行います。 権限をこれよりも緩くすると、このファイルは無視されます。 Microsoft Windowsにおいては、このファイルが安全なディレクトリに格納されていることを前提としていますので、特別に行われる権限の検査はありません。
https://www.postgresql.jp/document/12/html/libpq-pgpass.html
⇧ 上記にあるように、
- PostgreSQLの環境変数
PGPASSWORD - ユーザのホームディレクトリの
.pgpass - 接続パラメータ
passfile - 環境変数
PGPASSFILEで、パスワードファイルを指定
といった方法の内のいずれかを「pg_basebackup」コマンドを実行する前に、事前に行っておく必要がある模様。
勿論、「バックグラウンド」で実行する必要が無いのであれば、「パスワード」の入力を促す「プロンプト」が出力された時に、手動で「パスワード」を入力すれば良いので、上記のような対応は必要なくなるのだが。
ちなみに、「pg_basebackup」コマンドは、
- postgresql.conf
- pg_hba.conf
の設定なども必要になって来るので要注意ですかね。
あとは、
⇧ 上記サイト様にあるような罠もありますと...
2025年12月11日（木）18:00 追記：↓ ここから
チームのメンバーの方に連携してもらい、
-v--verbose-
冗長モードを有効にします。 開始時および終了段階でいくつか追加の段階が出力されます。 また進行状況報告も有効な場合、現在処理中のファイル名も正しく出力されます。
https://www.postgresql.jp/document/12/html/app-pgbasebackup.html
⇧ 上記の「-v」オプションが無いと、「バックアップ処理」が完了したかどうかがハッキリ確認することができない罠があることが分かった。
PostgreSQL 13からは、確認するクエリー（SQL文）が用意されているらしいが...
罠が多過ぎるんだよな～...
2025年12月11日（木）18:00 追記：↑ ここまで
毎度モヤモヤ感が半端ない…
今回はこのへんで。
