一定の条件で一番多いのは分割で購入された製品が最後まで支払いされなかった場合で、他にもキャリアの判断によって通信不可にされることがあるようです。その場合、ネットワーク利用制限☓となり、別称、赤ロムとも呼ばれます。一度赤ロムになったらそれが解除されることは無いようです（私の知る限りでは）。

ここで覚えておきたいのはまず、

1. ネットワーク利用制限▲の状態では何も問題なく利用できること
2. ネットワーク利用制限がかかるのは販売されたキャリアに対してのみ

です。

２．についてですが例えばドコモで販売されたスマホが赤ロム状態になったとします。そしてそのスマホはドコモのSIMを使っての通信が出来なくなりますが、SIMロック解除がされていれば他社の au 、ソフトバンク、楽天では使えると言うことです。また、SIMロック解除されていない時も Wifi を使っての通信は可能で全く使えない訳ではありません。

さてこのネットワーク利用制限はスマホやタブレットを中古で購入するときやオークションなどで他人（個人）から譲り受ける時に必ずチェックすべきものです。なお現在ヤフオクやメルカリなどではネットワーク利用制限▲の状態のものは出品禁止になっています（以前はシリアル番号の表示することで可能だった）ので現実的には親しい友人間、親戚などを除けば第３者からスマホやタブレットを購入する機会はスマホ中古販売店などに限られていると言ってもよいでしょう。

で、ここにネットワーク利用制限が◯（今後利用制限される可能性がない）と▲（利用制限される可能性がある）の（その他の条件が一緒の）中古スマホがあるとしたら当然ですが▲のほうが安価に販売されることになります。例えばスマホ中古販売大手のイオシスでは概ね５０００円程度安くなっています。

ここで重要なのが▲がネットワーク利用制限☓になる可能性、頻度です。イオシスの2年分(2021、2022年)の集計結果によるとそれはわずか０．１５％だそうです。

世の中、極端にリスクを嫌う人がいらっしゃいますが、たった、０．１５％の確率を犠牲にすれば５０００円安くなるってとてもお得だと私は思います。

そしてそして、運悪くその０．１５％の確率を引いてしまったとしてもイオシスの場合は

赤ロム永久保証つき　万が一当店で購入された端末がネットワーク利用制限×（赤ロム）となってしまった場合は、保証期間の有無に関わらず同等商品との交換、または全額返金させて頂きますのでご安心ください。

となっており交換、返金の手間はありますが全く心配が無いと言っても過言ではありません。

この赤ロム保証、イオシス以外のじゃんぱら他スマホ中古販売業者はかなりの確率で保証しています（していない業者もありますので購入時には必ずチェックしましょう）。

というわけで、ネットワーク利用制限▲のスマホ・タブレット、赤ロム保証のある販売店という条件付きで狙い目です。

ではでは

P41 Plus

QLCのSSDと言うだけで無条件に拒否反応を示す風潮が一部にあると思います。
昔、SSDがSLC -> MLC -> TLCと移行していた時期、TLCと言うだけで拒否反応を示す人がいらっしゃったことを思い出します。その後TLC自体や残り容量をSLCキャッシュとして活用するなどさまざまな改良をたどり、現在ではTLC SSDを選ぶことに異論を唱える人はほとんどいないでしょう。
同様にQLCも改良が続けられ、個人的にはCrucial P2あたりからQLC SSDは十分に実用性、汎用性のある製品になってきたと考えています。

それでも現在QLCに対して拒否反応がある為かSSDのスペックにNANDがQLC、TLCと明記せず「3D NAND」などとだけ表記されているのをよく見かけます。これによってユーザーは自分で或いはレビュー等で求めるSSDがTLCかQLCかを調べる手間暇を課せられています。ユーザーの立場からすれば困ったものです。まぁ明確に記載していない場合はQLCのケースが多い様に見受けられますが。

単に性能のことを比べると一般的にはTLC>QLCですが、出来の良いQLC もあれば、出来の悪いTLC もあります。
更にSSDの性能はNAND以外に、コントローラーチップ、DRAM搭載かなどにも大きく左右され、その結果、出来の良いQLC SSD が出来の悪いTLC SSD より高性能であっても不思議ではなくなっていると思います。

長い前書きでしたがP41 plus は144層QLC NANDです。QLCだからと毛嫌いせず実際に使用してみるとSLCキャッシュが効いている状態では十分な性能です。
QLCが嫌われる一つの要素に素の書き込み性能が低い事があげられ、10−20MB/sec程度(HDDより遅い)まで落ち込むものもあります。
P41 Plus の個人的な検証結果ですが概ね次の様になりました。

1TBは使用容量0%の状態でSLCキャッシュは約140GB
SLCキャッシュが切れると平均175MB/sec前後の書き込み速度

2TBは使用容量0%の状態でSLCキャッシュは約280GB
SLCキャッシュが切れると平均350MB/sec前後の書き込み速度

なかなか出来の良いQLC NAND で素の書き込み性能はQLCとしては上々で、大容量の連続書き込みや残り容量が少ない状態など、SSDにとって厳しい状況下でその威力を発揮します。
なお、大容量のファイルを頻繁に読み書きするユーザーは2TBを選んだ方が幸せになれるでしょう。
TBWは

1TB 400TBW
2TB 800TBW

と十分です。
P41 Plus はいわゆるエントリー、ミドル帯をターゲットにしたSSDと思われますが以上の性能は必要十分と思います。

私がP41 Plus に一番求めるのはもう一段の低価格化です。現在より2−3割の低価格が実現したらそれを武器にしてTLC SSDに対し強力な競争力を持ち、一般用途SSD の定番、主製品になりうると思っています。企業努力に期待します。

FreeBSD で db5 -> db18 にしたお話。

FreeBSD の daily security run output に

Checking for packages with security vulnerabilities:
Database fetched: Sun Oct 30 03:18:04 JST 2022
db5-5.3.28_8: Tag: expiration_date Value: 2022-06-30
db5-5.3.28_8: Tag: deprecated Value: EOLd, potential security issues, maybe use db18 instead

と警告が出ていたのですが、その内 ports/UPDATING にアップデート方法が載るだろうとほったらかしにしていました。本日 UPDATING を見ても特に記載がないので自力で db18 に移行方法を調べました。
db5 の依存関係を調べると私の環境では

ruby30-bdb
cyrus-sasl2

が依存している事が分かりました。
で、/etc/make.conf に

DEFAULT_VERSIONS+= bdb=18

と記述して、試しに

cd /usr/ports/security/cyrus-sasl2
make deinstall reinstall clean

したのですが db18 依存になってくれません。
適当にググったら

DEFAULT_VERSIONS+= bdb=18
WITH_BDB6_PERMITTED=yes

との情報があったので試すと db18 依存になってくれました。
両方を再 make した後

pkg delete db5

すると db5 だけ削除できました。
めでたし、めでたしw

ED25519 の勧め

ssh で接続してサーバー管理をする。サーバー管理の現場ではごく一般的に行われている風景だが普通の人から見ると暗いディスプレイの中に文字が飛び交う、映画なんかで出てくるコンピュータを操る悪いハッカーそのものだろう。w
ssh 接続するにはその経路を暗号化する為の暗号方式が必要だ。現在の主流は rsa 2048 bit と言う暗号方式で、現在の最速スーパーコンピュータを使用しても現実的な時間で解析出来ないとされている。暗号の性能を示す指標として暗号強度と言うものがあるがこれは暗号化するためのキーが何通りあるかで示される。rsa 2048 bit は 112 bit の暗号強度を持つが、これは 2 の 112 乗のキーがあると言う意味になる。そのうちのの一つが正解の暗号キーとなる訳で、暗号強度を高めるにはすぐ想像がつく様に bit 数を増やせば良いのだが bit 数を増やすと暗号化・復号化の時間が増えるため実用性の観点から無闇矢鱈に増やせば良いと言うものではなくバランスを取らなければならない。暗号化にはそのやり方、アルゴリズムも重要だ。rsa 方式は大きな数字の素因数分解に効率的な方法が無いため基本的に総当たりでしか暗号キーを見つける事ができない事を利用しているのだが、開発が進められている量子コンピュータを使用すると効率的な素因数分解解析アルゴリズムが発見されており、量子コンピュータが実用化されると rsa 暗号は破られてしまう危険性が指摘されていてアメリカの NIST と言う研究機関が 2031 年以降は rsa 2048 bit の使用を禁止する声明を出している。そんな事もあって rsa 方式に代わる暗号アルゴリズムが幾つか提案されている。そのうちのひとつに暗号強度は 128 bit さらに暗号キーの大きさが rsa より短く、暗号化・復号化の時間も大差ないエドワーズ曲線デジタル署名アルゴリズム(EdDSA)の ED25519 がある。つまり、ED25519 がサポートされていれば置き換えない理由はあなたのやる気だけなのだ。という訳で皆さん ED25519 を使いましょう。ではでは

私が初めて FreeBSD を触ったのは FreeBSD 2.0 からだ。wiki を見ると FreeBSD 2.0 のリリースは1994年11月22日となっているのでもう30年弱のお付き合いとなる。Linux と言うチョイスも有ったのだが、現在と同様に多数のディストリビューターがありそれに迷うのを避けたのと、Unix の正統派 BSD like のオープンソースな事がポッと出の Linux に比べてこちらを選ぶのが通と言う思い込みがあった。当時勤めていた会社には 64kbps の専用線が引かれていたのだが(64kbps でも月１０万円近くしていた様に記憶している) FreeBSD をダウンロードするのに一晩かかった事を覚えている。右も左も分からないままメールサーバーを立ち上げ、会社のドメインを取って運用したのだが大変苦労した。それ以降 Linux に1−2年浮気した以外は FreeBSD で自分のサーバーを運用している。その頃は Linux と FreeBSD はライバル関係と言っても語弊はなかったのだが、最近の調査結果 を見ると、Web サーバーにおいて Unix が80%余りだが、FreeBSD のシェアは 0.2% と余りに寂しい状況だ。対して Linux は 37% と比較するのもおこがましいのが現実である。とは言うものの、Apple の Mac OS は FreeBSD を土台に作られていたり、Sony PS シリーズ、Yahoo のメインサーバー、さくらインターネットのレンタルサーバーなども FreeBSD だったりして決して Linux に劣ることのない性能を持っている。そんな FreeBSD の魅力を私の視線から述べるとすると

• 保守的だが高負荷時にも安定した動作性能
• ports 管理による柔軟なアプリ管理
• カーネルと OS 全体が一体となって開発されている(極端に言うと Linux はカーネルに各ディストリビューターが勝手に機能を付け加えて OS として成立させている)

あたりだろうか。uptime が3000日を超えている FreeBSD を見た事があるが、実際30年近く FreeBSD を触ってきた感想として少々手荒な事をしても FreeBSD は安定した動作が期待できる信頼感がある。ソースからコンパイルする port によるアプリ管理は細かいオプション制御が出来て私は重宝している。ただ、 FreeBSD は GUI 周りの整備が Linux に比べると差がある様に見える。単なる CUI 制御のサーバー性能比較では Linux に劣らぬどころか一部は優っていると思うのだが、やはり GUI でポチポチやれるのは一般受けが良いんだろうと想像している。まぁ、私の推察が正しいのかどうかは置いておいて、現実はシェア的には Linux の圧倒的勝利と行っても良いだろう。でも、世の中必ずニッチな勢力に目を向けてくれる人もいる。そこのあなた、一度 FreeBSD を触ってみませんか？ Linux との文化の違いを垣間見るだけでも結構面白いですよ。と、つぶやいてみますw。ではでは

CAPTCHA

CAPTCHA と言われてすぐにそれが何か分かる人はそう多く無いだろうが、上の「私はロボットではありません」やひん曲がったあるいはノイズの入った文字列の入力、信号機や横断歩道、バスの入ったパネルをチェックするなど、入力しているのが人間である事を認証するシステムを見たことのある人は多いだろう。CAPTCHA が使われ始めた初期の頃はほんのちょっと斜めになっていればコンピュータ(bot)は認識できなかったのが、AI 機械学習の進歩によりどんどん読める様になってきて、その為文字の加工具合やノイズの量が増えてきて人間にも判読できないまでになってきているんだそうだ。私も信号機のパネルを選ぶ時、ほんのちょっとだけ引っ掛かっているのは含めるのか否か、消火栓を選べと言われても国によって消火栓の形状が様々だったりして何度も繰り返しチェックを受けさせられてイライラした事が何度もある。Cloudflare によると CAPTCHA 認証に平均32秒かかっていて世界的にみると毎日500年間分の時間が無駄に費やされているんだとか。で、まぁ普通の人にはここまでの知識を「ふーん」で終わりにして、ちょっとした知識の見せびらかしや酒のつまみにすればいいんだけど、Wordpress でブログやホームページをやっている人はコメントやお問い合わせフォームに bot から spam を投稿される事への対策をする必要がある。うんで wordpress には最初からAkismet Spam Protection と言う対策プラグインが入っていてとても評判が良いのだがこれ無料で使う条件に営利を伴うサイトでない、アフェリエイトリンクを張っていないなどがある。つまり営利目的が含まれる場合は有料なのだ。私はケチなのでそんなの払いたく無い。でも spam 対策はしなければならないので出てくるのは無料で使える Google の reCAPTCHAでこれには v2 と v3 があり、皆さんがよくご覧になるのは上に表示されている v2 の「私はロボットではありません」だ。v3 では出ない。無料、Google 謹製である事、認証の難易度が高く無い初期の頃は使い勝手が良かったなどがおそらく理由で、2022年10月の段階では相当のシェアを持ちあちこちで見かける。勿論、Worpress 様にも多数のプラグインが用意されていてよりどりみどりだ。
そこへ2022年9月末に発表されたのが

Cloudflare Turnstile

Cloudflare Turnstile で、CAPTCHA に代わる認証方式としている。先に述べた様に Cloudflare によると、現在の CAPTCHA は認証に平均32秒かかっているのが Turnstile では1秒になるとのこと。これでいままでと認証精度が変わらないのなら大進歩だ。そしてすでに WordPress のプラグインも用意されている。Easy Cloudflare Turnstile がそれだ。私がお勧めするのだから勿論無料だ。ここから手順に従ってkeyを取得すればあっという間に WordPress に実装できる。導入動画が有ったのでリンクを貼っておく。

Turnstile 導入動画

2022年9月末発表なので実績が全然足りないが、この私のブログに早速導入した。皆さんも如何ですか？
何らかの原因で Tuenstile に人間判定してもらえなくてログインできなくなることがあるらしい。w
そのときは

Keep on mind, that in case of emergency, you can disable this plugin via FTP access, just rename the plugin folder.

の指示に従い wp-content/plugins/ 下にある wppool-turnstile-captcha-spam-filter をリネームすればプラグインが無効になるそうだ。万一の為に覚えておこう。
ではでは

gmail に於ける spf と転送の問題解決

独自ドメインのメール管理に gmail を使用しています。まず独自ドメイン用のメールサーバーを立ち上げます。普通このメールサーバーに対しメールクライアントでアクセスしますが、私の場合 gmail のインタフェース、機能を使ってメール管理・運用をしたいので、メールサーバーからgmail にメールを転送して読み書き、保存をして、メールを出す時は gmail からメールサーバーを経由、リレーしています。
なんでこんなことをしているかと言うと、gmail の優れた UI 、迷惑メールフィルタなどを使いたいからです。
ここで問題となるのが、単に転送するだけでは gmail で spf エラーが出る事です。その為、最初は gmail にメールを持ってくるのに pop3 を使っていたんですが、gmail の pop3 って最長1時間に1回位の頻度でしかチェックしてくれません。私同様これを不便と思う人がいる様で chrome の拡張機能で

• Gmail POP3 Auto Refresh
• Gmail POP Sync

などがあり、1分間隔でメールチェックをしてくれます。
が、これは gmail サーバーに負荷を与えますし、イリーガルな感が拭えません。下手するとアカウント ban されるかもしれません(まぁ、大丈夫だと思うけど)。なので、転送しても spf エラーにならない方法を調べてみると

• SPFと転送の相性問題に対する解決策の紹介

に大変参考になる記事が見つかりました。
ここに記述されている

• 単純方式（SPFと転送の相性問題に対する解決案の2つの方式）
• SRS（Sender Rewriting Scheme）

それぞれについて postfix での解決方法を記述しておく。
最初の解決方法は、Envelope from の書き換えで、postfix の main.cf に

sender_canonical_classes = envelope_sender
sender_canonical_maps = regexp:/usr/local/etc/postfix/sender_canonical

を加えて、sender_canonical に正規表現で

/@([a-zA-Z0-9_+\-\.]+)$/ @example.net

などと記述して転送サーバーが spf 対応しているドメインに書き換える事で問題を解決する。
但し、参照した記事にあるとおりエラーメールなどを本当の発信者に返すことが出来ない。

そこで2番目の登場となる。これは

• センダー・リライティング・スキーム（Sender Rewriting Scheme,SRS)

を使用した技術で、上の単に spf の認証が通るドメインに書き換えるのではなく、spf の認証を通り尚且つ元の差出人の情報も保持したまま転送できる。postfix 用に

• postsrsd

が開発されており私もこれを使用している。ソースを github からダウンロードして make して出来た postsrsd を /usr/local/sbin などに install(make install すると default でここに入る) して
postfix の main.cf に

sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes= envelope_recipient,header_recipient

を追加して、postsrsd を

postsrsd -D -u mailnull -p /var/run/postsrsd/postsrsd.pid -d mail.example.com -s /usr/local/etc/postsrsd.secret -f 10001 -r 10002 -t 1800

などとして起動。postfix も reload ないし再起動すれば

Oct 16 16:12:44 mail postsrsd[54963]: srs_forward: <example@example.com> rewritten as <SRS0=rQK4=2R=example.com=example@example.net>

の様に example.com -> example.net に元の情報を維持しつつ且つ spf 認証を通るアドレスに変換される様になる。以上、ご参考になると幸いです。ではでは

postfix + spf-engine + opendmarc + opendkim

定番の組み合わせに spf-engine https://launchpad.net/spf-engine を追加しました。spf-engine は以前よく使われていた pypolicyd-spf(開発終了) の後継であり更に spfmilter の機能も引き継いで現在も開発が続けられている spf ユーティリティです。
dmarc は spf か dkim のどちらかの認証に成功するとメールを pass を返します。
逆に言うと、spf, dkim 両方の認証に失敗した時 fail を返し、メールの受信者は送信者の dmarc 設定を参照、参考にしてそのメールの処遇を決めます。
実際に認証の可否を受け持つのは　dkim については opendkim が、spf-engine が無い場合は spf については opendmarc が担当します。その場合、dmarc は spf の認証について成功か失敗の二つしか返しません。そこでspf の認証についてより細かく制御する為に、spf 認証ユーティリティとして spf-engine を追加します。
spf-engine 以外にも spf ユーティリティとして以下の物が見つかりましたが

p5-Mail-SPF
postfix-policyd-spf-perl

spf-engine が最終更新が2022年2月と一番新しく現在も開発が続けられていて、またかつて広く使用されていた pypolicyd-spf の後継であることなどから2022年10月の段階では一番高機能で信頼できるユーティリティと私は判断しました。

spf 認証結果についておさらいしておきましょう。

spf-engine の主なパラメータとして次の様な物があります。

• HELO/EHLO コマンドから得た from 送信ドメインについて spf 認証

#  HELO check rejection policy. Options are:
#  HELO_reject = SPF_Not_Pass (default) - Reject if result not Pass/None/Tempfail.
#  HELO_reject = Softfail - Reject if result Softfail and Fail
#  HELO_reject = Fail - Reject on HELO Fail
#  HELO_reject = Null - Only reject HELO Fail for Null sender (SPF Classic)
#  HELO_reject = False - Never reject/defer on HELO, append header only. 
#  HELO_reject = No_Check - Never check HELO.

• SMTP の MAIL FROM (envelope From)の spf 認証

#  Mail From rejection policy.  Options are:
#  Mail_From_reject = SPF_Not_Pass - Reject if result not Pass/None/Tempfail.
#  Mail_From_reject = Softfail - Reject if result Softfail and Fail
#  Mail_From_reject = Fail - Reject on Mail From Fail (default)
#  Mail_From_reject = False - Never reject/defer on Mail From, append header only
#  Mail_From_reject = No_Check - Never check Mail From/Return Path.

• spf レコードが不正の場合

#  Policy for rejecting due to SPF PermError.  Options are:
#  PermError_reject = True
#  PermError_reject = False

• spf レコードが一時的に不正(dns サーバーが落ちているとかかな？)

#  Policy for deferring messages due to SPF TempError.  Options are:
#  TempError_Defer = True
#  TempError_Defer = False

その他、特定のドメインで Netural/Softfail が出た場合とか FQDN や IP アドレスでのホワイト・ブラックリストなど、dmarc では出来ない細かな spf 認証についての処理が出来ます。
実はよく使い方が分からない、理解出来ないパラメータもあります。w
自分のサーバーですので、万一正しいメールを弾いてしまっても自己責任と言う事で色々実験中ですのでその内おすすめ設定をアップできる様に頑張っている最中です。生暖かい目でご期待ください。
ではでは

FreeBSD certbot error ImportError: cannot import name ‘x509’ from ‘cryptography.hazmat.bindings._rust’ (unknown location)

FreeBSD で、2022/10/10 頃にアップデートされた py39-cryptography-38.0.1 が原因で certbot が動かなくなっています。一つ前の py39-cryptography-3.4.8 に戻せば動きます。
38.0.1 を削除してpkg install py39-cryptography とかすれば3.4.8 に戻せます。
portdowngrade-1.7 を使うのも良いでしょう。3.4.8 に戻したら取り敢えず

pkg lock py39-cryptography

としておくのが吉かもしれない。

Let’s encryptのコミュニティ

や

FreeBSD のバグレポート

で既に論議されているので近い内に修正されると思われますが、毎日 cron で certbot renew している人もいるでしょうから情報として共有しておきます。

Conoha VPS が2022年11月7日迄の期間限定で最大75%引きのキャンペーンを開催しています。これはお得です。普段は最大23%割引だから割引率が大幅に上がっている。
75%引きになるのは VPS割引きっぷ 36ヶ月契約の

– 3 CPU 2GBRAM 100GBSSD の通常、月 1,848 円が 460 円
– 4 CPU 4GBRAM 100GBSSD の通常、月 3,608 円が 879 円

の場合だ。36ヶ月分の先払いが必要だが、思わずグラっとくる人も多いのでは無いだろうか？
36ヶ月契約でなくても良い。VPS割引きっぷ 3ヶ月契約でも

– 3 CPU 2GBRAM 100GBSSD の通常、月 1,848 円が 660 円
– 4 CPU 4GBRAM 100GBSSD の通常、月 3,608 円が 1,190 円

になる。1ヶ月しか使わなくても、3 CPU の場合は 660 x 3 = 1,980 円なので、通常の 1,848 円に 132 円上乗せすれば3ヶ月使える。4CPU に至っては 1,190 x 3 = 3,570 円だから3ヶ月契約をした方が安い事になる。

何故、こんな大盤振る舞いをしているのか。
これは想像なのだが、レンタルサーバー大手のエックスサーバーが 2922年9月に VPS に参入してきた事が影響しているのではないかと私は考えている。Xserver VPS をご覧になるとわかるが、Xserver VPS はリリース記念キャンペーンをやっていてその価格が今回の Conoha VPS の割引価格と実に酷似している。つまり、Conoha がエックスサーバーに喧嘩をふっかけたのではないかと言うのが私の妄想ですw。
本当の理由は闇の中ですがユーザーにとっては嬉しい競争で、VPS を今使っている人も、これから使おうと思っている人も注目です。
私は 3CPU 2GB プランを来月11月の頭に契約するつもりです。みなさんも如何ですか？
なお、ここのバナーを経由して契約すると７００円のクーポンがプレゼントされますので宜しければお使いください。
ではでは