[PC] ubuntu24.04から26.04.1へのアップグレードその2 (サーバー編)

26.04.1のリリースから遅れること1ヶ月強、ようやく24.04から26.04.1へのアップグレードパスが正式にopenされました。

しかしながら、予備PCでのテスト時のアップグレード失敗と、その後の各所での不具合報告の数々を見れば、安心してアップグレードに踏み切れる状況ではない事は明らかでした。

とはいえ、少々時間を空けたところで劇的に改善する見込みもない以上、多少の不具合とそれへの対処は必要な手間として許容せざるを得ないでしょうから、その時間を確保してサーバーのアップグレードに踏み切ったわけです。

結果から言うと、予想通りというかなんというか、準備段階の設定で1件、途中の設定ファイル更新確認が多数、加えて完了間際のサービスの再起動エラー1件。といった感じで、辛くもバックアップの出番はなく完了したもののやたらと時間も手間もかかりました。

以下、その概略メモです。 

まずはいつものようにバックアップを取り、updateをかけてからdo-release-upgrade。

そして程なく、アップグレードが始まる前のチェック段階で1件目のトラブルで中断。

［1件目のトラブル(mysqlの認証方式設定) ］

ここで問題になったのはmysqlです。エラーメッセージ等から確認すると、mysqlのバージョン変更に伴い、24.04用のバージョンでユーザー認証に用いていたモジュールが廃止になり、認証方式を切り替えるか旧認証方式を引き続き使うように事前に設定するかしなければアップグレード後にmysqlでログイン等が出来なくなるらしいのです。rootも含めて。なので、アップグレードを進めるにはどちらか対応しろというわけですね。

思うに後者の旧認証方式を使う方法なら、アップグレード後に設定する事が出来る筈なので必ずしも詰むわけではないのかもしれません。とはいえ、更新後は認証に失敗しても多分その辺のメッセージは出ないだろうし方式の変更に気づかないでしょうから事実上詰む可能性が高く、後回しにする意味もない。だからこのタイミングで設定を強制しているんでしょうね。

簡単なのは旧認証方式を使うようにオプションを設定する方ですが、今後の事も考えれば新方式に切り替えた方がいいだろう、というわけで切り替え作業へ。

切り替えはmysqlのコンソールから行います。まずroot(mysqlの管理者アカウント)でコンソールを立ち上げます。

$ mysql -u root -p

切り替え対象となる、すなわち旧方式(mysql_native_password)を使っているユーザーの一覧を取得します。

> SELECT user, host, plugin from mysql.user WHERE plugin='mysql_native_password';

表示されたユーザー毎に、下記コマンドで認証方式の指定付きで新規パスワードを設定して切り替えます。ユーザー名とホストは一覧に表示されているものを入力し、新規パスワードにはそのユーザーのパスワードを入力します。

> ALTER USER 'ユーザー名'@'ホスト名' IDENTIFIED WITH caching_sha2_password BY '新規パスワード'; 

 なお、パスワードの形式に制限がかかっている場合は、その形式に合わせたパスワードを設定する必要があります。何文字以上とか、大文字小文字混合とか、数字入りとか、特殊文字入りとかそういうやつです。どういう制限がかかっているのかわからない場合は、下記コマンドで制限の一覧が表示されるのでそこから確認します。

> SHOW VARIABLES LIKE 'validate_password%'; 

ユーザー分上記ALTERコマンドを繰り返せばOK。ユーザーが多数の場合はスクリプト等でする必要があるでしょう。というかあまりに面倒な場合には旧認証方式を使う事になるんだと思いますが。全ユーザーのパスワードリセットとか大変すぎますしね。

切り替え・設定後はアップグレードを実行可能になります。(他に問題がなければ。)

［大幅に増えた設定上書きの確認等］

後は基本的にいつもと同じです。設定ファイルを入れ替えるか、とか色々聞かれる度に差分等を確認してyes/noを選択するだけです。

ただ、今回は設定ファイルの入れ替えをするかどうか聞かれる回数がいつもより格段に多かったように思います。adduser.confの更新をするか聞かれたのは多分初めてだと思いますし、メール関連(postfixとdovecot)でかなり仕様変更があったらしく、大量に設定ファイルの更新可否を問われました。コメントアウト程度しか手を入れていないファイルまで。postfixは予備PCでのエラーを出した箇所な事もあり、嫌な予感がよぎります。

あと、今回は1つ見慣れないダイアログが出ました。何かというと、(debianの)popularity-contestモジュールを有効にするか？と聞いてくるものです。説明文を読むと、週一回どんなパッケージを使っているかのレポートをdebian projectに送信するモジュールだそうで。そんな余計かつ明らかに脆弱性に直結しそうなものをサーバーに入れる人なんているの？と疑問を感じると共に、よく確認せずにうっかりyesで入れてしまっていたらと思うと冷や汗が出ました。後からはなかなか気づけないと思いますし、気づいた時の事とか考えると本気で怖いので、こういうのをデフォルトにはしないでほしいですね。

後は概ね順調に進みました。このまま終われ、と半ば祈りながら待つ事しばし、しかしやはりというかそうすんなりとは終わらせてくれませんでした。エラー発生。問題になったのはdovecotです。

［dovecotの仕様変更対応］

エラーを吐いたのはアップグレードが一通り完了し、各サービスを再起動する段階での事でした。dovecotが再起動に失敗したのですね。

ここから設定の修正作業が始まったわけですが、修正箇所は結構多く、おそらくdovecotの設定によって異なるだろう割に長過ぎるでしょうから以下は概略だけ。  

そもそも何故そんなに修正が必要なのかというと、dovecotのバージョン2.3と2.4の間で設定ファイルに大幅な仕様変更が加えられているからです。重要な変数が廃止・置き換えになっていたり、書式に変更があったり。しかも後方互換性がない(下記の設定ファイルバージョン変数dovecot_config_version等では2.4.0以降しか設定出来ない)ので、新様式に合わせて手動で修正するより他にないのです。(これは設定ファイルに何かしら変更を加えている場合の話です。何も手を入れていない場合はファイルごと新しいバージョンのものに置き換えれば特に問題はありません。)

この仕様変更は例によってセキュリティ強化に伴うものなんでしょうけれど、dovecotレベルの重要なモジュールには後方互換性は確保して欲しかったですね。せめて移行用の手順書の類が準備してあればだいぶ違ったんでしょうけれどそれもなかったですし、何が起こっているのか、何が問題なのかを調べて、設定ファイルの修正で片が付く事がわかるまでが結構な手間でしたからね。

いや改めて見ると本当に酷い。LTS版の更新にこれが被るとか、多少なりと設定をいじってるdovecotユーザーはほぼ全員が遭遇するじゃないの。どうにかならんかったのか。

ともあれ。修正作業は、起動コマンドを試してみて、エラーが出る度に下記コマンドでサービスの状況をチェックしてどこの設定でエラー引っかかっているのか特定しつつ、エラーの出ている箇所を１つずつ修正していく、というやり方で進めました。

$ sudo systemctl status dovecot.service 

私の場合に重要だっただろう修正箇所は、

・/etc/dovecot/dovecot.conf

　1. 冒頭(有効な設定の先頭)に下記2行挿入(dovecotのバージョンが2.4.2の場合)

　dovecot_config_version = 2.4.2

　dovecot_storage_version = 2.4.2

　2. ファイル下部のdict{}をコメントアウト

・/etc/dovecot/conf.d/10-auth.conf

　disable_plaintext_authをauth_allow_cleartextに変更(yes/noは反転)

・/etc/dovecot/conf.d/10-mail.conf

　mail_location = maildir:~/Maildirを下記2行に置き換え

　mail_driver = maildir

　mail_path = ~/Maildir

の3件です。

以上でdovecotのエラーは解消。幸いエラーが出る前にアップグレード自体は完了していたので、残るは後始末だけです。

[後始末]

といっても、予備PCの時と同様に、aptの修復コマンド等を一通り走らせてから、不要になったパッケージを削除して完了。特に問題もありませんでした。

以上で作業終了。お疲れ様でした。

最も懸念していたpostfixで問題が起きなかったのは良かったのですが、その相方たるdovecotがやらかしてくれました。とはいえ本当に不具合と言えるのはそれだけで、ssl周りとかのここ数年で色々変化が激しかったその他の重要モジュールでは問題は出ませんでしたし、ネットワーク周りもすんなり移行出来ましたから、予想よりは穏当に収まったのかな、と思います。

しかし精神的にとても疲れました。毎度の事ではあるのですが、どうにかならんのかなあと。ならんのでしょうね。AI任せに出来るような作業でもないでしょうし。やれやれです。

[PC] ubuntu24.04から26.04.1へのアップグレードその1 

[PC] ubuntu24.04から26.04.1へのアップグレードその1

予定通りubuntu26.04LTSのfix版26.04.1が8月下旬にリリースされました。

これに伴い一つ前のLTS版である24.04LTSから26.04.1への直接のアップグレードパスも開放されています。しかしいきなりサーバーに適用するのは流石に危険が過ぎる、ということで、まず実験台として普段は使っていない予備PCにアップグレードを適用してみました。

サーバーに適用する時は当然ながらコマンドラインからするので、それに合わせて当該PCでもターミナルから実行。

いつものようにまずパッケージを最新にして、 

$ sudo apt update

$ sudo apt upgrade

必要に応じて再起動もしてから、下記コマンド。

$ sudo do-release-upgrade -d

なお、本来なら開発版へのアップグレードを許容する-dオプションは不要な筈なんですが、なぜかこれなしだとアップグレードが始まらないので付けています。ずっと以前から大体このオプションを付けているような気がするんですが、何故なんでしょうね？

それはともかく、時々設定ファイルの上書き許可等に応答しつつ、待つ事数十分。無事完了・・・とはいかず、不具合が発生して止まってしまいました。ぐえー。

今回問題になっていたのはpostfixパッケージでした。その更新が出来ない旨エラーが出て、直後自動でpostfixパッケージを元に戻そうとしていたようですがこれにも失敗。そのままupgrade処理が終了してしまったのです。

不幸中の幸いというか、主要パッケージのアップグレードは終わっていたようで、ディストリビューションのバージョンは26.04.1になっていました。ので、apt周りの修復と後始末(不要になったパッケージの削除等)をすることに。

前にもこんな事があったなあ・・・その時ひっかかったのはpostgresqlだったっけ、等と遠い目をしつつ、その当時を思い出して、まず元凶らしきpostfixを完全削除。というのもこれを削除しないと、aptの処理がことごとく止まってしまい、修復もままならないのです。

$ sudo apt remove --purge postfix

しかる後に、aptの修復を試みます。

$ sudo apt update --fix-missing

$ sudo apt install -f

$ sudo apt update

そしてパッケージ類のアップグレード漏れがあればそれをやって、

$ sudo apt upgrade

不要になったパッケージ類を削除。 

$ sudo apt autoremove 

この時点で見た感じ問題はなくなったように見えましたが、さらに一応パッケージの修復も試しておきます。

$ sudo dpkg --configure -a

以上で後始末完了。

あと、必要ならpostfixを入れ直します。当該PCにも一応入れ直しましたが、前述の通りそのPCは普段使っていない予備PCなので入れる必要はなかったんですけれども。

しかし困ったものです。postfixは当然ながらサーバーでは最も重要なプログラムの一つで、不具合など許されないパッケージです。上記と同様の対応をするとして、一旦完全削除していますから、また一から設定する事になるわけですけれども、それを考えるだけで気が遠くなるくらい手を入れてますし。

なお、軽く調べてみたところでは、本件と同様に24.04から26.04.1へのアップグレード時にpostfixが動かなくなった、という報告をしているユーザーもいました。

これは怖い。迂闊にサーバーには適用出来ません。というわけで、サーバーへの適用は一旦見送ります。色々調べて、回避の目処が立ったてからにしようと思います。どうしてもやってみなければわからない、という事であれば、問題が発生した場合に対処するための時間も確保しないと。。。しかしテストしておいてよかった。

なので今回は一旦これでおしまい。やれやれです。 

<追記>

do-release-upgradeに-dオプションが必要な点が気になったので調べてみたんですが。

24.04から26.04へのアップグレードパスは26.04.1のリリースと同時にopenになる筈だったところ、これが延期された状態なんだそうで。rustベースになったcoreutils関連のアップデートの統合に手間取っているとかなんとか。だから24.04から見ると26.04.1へのアップグレードパスは開発版扱いという事なわけです。

当初予定されていた延期の期間は数週間程度を見込んでいる、との事だったので、2026年9月中には開放されるものと解されていたのが、およそ4週間が過ぎ、9月末近くになってもまだ開放されていない、というのが現状のようです。

遅れている理由は非公表ですが、何であれcanonicalの見通しの甘さ、開発・管理プロセスの杜撰さがその根本原因であろうと思われます。そんな状態なら、そもそも26.04.1のリリース自体延期するべきでしたね。ユーザーを混乱させるだけですから。ほんと困ったものです。

当然サーバーのアップグレード適用なんて出来るわけもありません。いつになるのやら。

<追記2>

ようやく24.04から26.04(26.04.1)へのアップグレードパスがopenになったそうです。アナウンスがされたのは9/29でギリギリ9月中。いかにも無理やり数週間に収めた感があって、深刻な不具合が残っていないか、等とどうしても懐疑的にならざるを得ません。とはいえアップグレードしないわけにもいかないので覚悟を決めなければ。 

<追記3>

というわけで、サーバーのアップグレードに踏み切りました。当然のようにすんなりとは行きませんでしたが、何とか完了。疲れた。

[PC] ubuntu24.04から26.04.1へのアップグレードその2 (サーバー編) 

[note] メール送信サーバーの各種認証方式について(DKIM,SPF,DMARC)

今更？な話なんですが。

昨今のスパムやフィッシング等の不正メールの増大を受けて、大手IT事業者が主導する形で、メールの送受信時のDNS経由でのサーバーと個々のメールの認証が事実上必須になっていますが、今回はその仕組みについてまとめたメモです。

認証の手段はDKIM,SPF,DMARCの3つの要素から構成されます。概要をは次のような感じです。

DKIM(DomainKeys Identified Mail): RSA暗号ペア(送信側秘密鍵とDNSに登録された公開鍵)による個々のメールへの署名付与・検証による送信元の認証及びメールデータの検証

SPF(Sender Policy Framework): メール送信サーバーのDNSレコードへの登録による検証

DMARC(Doain-based Message Authentication, Reporting and Conformance): 送信側DNSへのDKIM,SPFの失敗時の処理方法及び集計結果の送付先等の登録

一般的な表現に言い直すと、DKIMは送信側が個別のメールについて電子署名を施し、受信側がそれを検証して正しい送信元から送られてきたものかどうか及び改竄の有無をチェックするもの、SPFはメールの送信元サーバーが正規のものかどうかを受信側でDNSを参照して確認出来るようにするもの、DMARCはDKIMもしくはSPFでのチェックが失敗した時にどういう処理をすべきか、送信側が推奨する処理を提示するもの、という感じでしょうか。

DKIMとSPFはメール及び送信サーバーの真正をチェックするための仕組みで、DMARCはそれらとは毛色が違い、チェックの結果や失敗時の処理の方針を送信元と送信先で共有するための仕組みです。

DKIMとSPFは比較的わかりやすいと思います。メールや送信サーバーをチェックするだけの話ですから。

これに対して、DMARCは初見だとその意味というか意義というか、何故そんな仕組みを使うのかがわかりにくいかもしれません。認証に失敗した場合に送信元側がメールをどう扱って欲しいかを提示する、というのはどういう事なのかと。認証に失敗するというのは不正の可能性が高いんだから排除して終わりじゃないのか、と疑問に思うかもしれませんね。

なぜ送信元が失敗した時の事を想定するのか？というと、DKIMやSPFの認証失敗は、必ずしも不正が原因で起こるとは限らないからです。

DKIMやSPFでは、DNS上に登録された送信元が提供する情報とメールのメタデータ等を突き合わせてその真正を検証するわけですが、メールの送信経路が複雑な場合等には、DNS上の登録情報と実際の送信経路上のサーバーとが齟齬を来す事故も起こります。そうすると、正規の送信元から送信しているにも関わらず、認証に失敗してしまう。でも不正ではないのだから、弾かれるとシステム障害になってしまう。それは困るわけです。実際障害ではあるのですが、メールの送信経路が複雑な場合、必ずしも個々のメールサーバーの管理者が管理し切れるものではなく、万全な予防が困難なケースもあるのです。そういう場合にプロバイダー等でいちいち事故・障害事案になったりすると顧客との関係では信用問題になるし、事業が立ち行かなくなります。

特にシステムの変更等をする場合には一時的にせよ認証に失敗する状況が避けられない事もあるわけで、そういう場合には送信元が認証に失敗するかもしれないけど必ずしも不正によるものというわけではない(ので弾かないでほしい)といった情報を伝える必要があり、その手段としてDMARCが使用されている、というわけです。

ちなみに、DMARCには失敗の頻度等をまとめたレポートメールを送信先のサーバーから送信元のサーバーに送付するためのメールアドレスを登録する事も出来ます。送信元はそのフィードバックを見て、正常に認証が出来ているのか、不具合が起きているならどの経路で起きているのか、といった状況を知ることが出来、不具合等がある場合にはその是正の契機に出来るのです。

上記のいずれも、それらのチェックを実際に行うかどうか、またチェック後に個々のメールを具体的にどう処理するかは、全て受信側の自由です。不都合がなければ、全て無視しても構いません。受信側がチェックしないのであれば、当然送信側が対応する必要もありません。

なんですが、googleやmicrosoftのような大手事業者だとそれはもう山ほど偽装メールの類が届くわけで、もはやこれらのチェックなしではサービスが立ち行かない。なので、一定規模のメールを送信するような場合には送信側にこれらの検証手段への対応を義務付けているのですね。

となると、ごく小規模なサーバー以外は事実上対応が必須という事になるわけです。対応しなければ利用者の多いgmail宛等のメールが全部届かなくなってメールシステムが成立しませんから。

ただ、これらのチェック手段も万能ではありません。攻撃手段はいくつも確立されていますし、法人等で外部のグループウェアを利用してそこから自社ドメインのメールを送信する場合等、複雑な経路を辿ってメールを送信する場合には特にdkimの認証に失敗するケースが多発していたりもします。(大手でもその割合は10%を超えるところも多数あるとか。これがDMARCの存在する所以です)

なので、今現在、それらの現状への対策を施したdkim2の検討・策定が進められている、という話もあります。もっとも、こちらはまだドラフトにすらなっておらず、その実現は早くとも数年後以降になるだろうという見込みだそうですが。そもそもdkimでカバーし切れないようなケースを十全にカバーする仕組みの構築はそう簡単ではないだろうとも思われます。

しかしその辺が問題になるのは一定以上の複雑なシステムの場合です。サブドメインがない、またリレーをしない等の単純なケースについてはdkimで十分でもあるので、零細サイト等は当面気にする必要はないでしょう。ただ、将来的に大手がdkim2へ移行した場合はそれに対応すべく移行を迫られることになる可能性はあります。面倒ですね。

なお、具体的な設定の方法は至るところで情報が公開されているし、もとよりシステムの構成によって手順も設定の内容も様々に異なるのだから、ここに詳細を記載する事は控えようと思います。あまりに膨大になるでしょうし。

一応私のサーバー(ubuntu server+postfix+外部DNSサービス)の場合について概要を書くと、

・DKIM: opendkimによる鍵ペア生成とpostfixの設定とDNSへのレコード登録

・SPF: DNSへのレコード登録(送信については送信サーバー上でやることはありません。なお、受信時にSPFチェックをする場合は受信サーバー上でpostfixの設定が必要)

・DMARC: DNSへのレコード登録

がそれぞれ必要になります。

まとめると、メール送信サーバーとして3方式に対応するには、DNSレコードの登録設定は共通で必須、DKIMのみサーバー上の設定が必要になるわけです。これらとは別に受信時のSPFチェックにはサーバー上の設定が必要になりますが、送信時には関係ありません。

やってみればわかりますが、作業自体は意外と簡単です。ただ、仕組みを理解するまでが結構かかるんですよね。なにせあらゆるシステム構成に対応出来るように作られているので、方式全体を把握しないと自分の場合にどう設定するのが適切なのか判断出来ないのです。まとめてあるサイトは沢山あるのですが、どれも特定のシステム構成に依存していたり色々端折っていたりで今ひとつ分かりにくかったりして。これから挑まれる方におかれましては、健闘を祈ります。

なお、3方式は通常セットで運用されますし、多くの解説ではセットでないとあまり意味がない、というような説明もされますが、各々の方式は仕組みとしては独立していて、DKIM,SPF,DMARCの内一部のみを導入する事も全く差し支えありません。実際私はまずSPFを導入し、次いでDKIM、最後にDMARCという形で段階的に導入しました。もっとも、仕組み上DMARCだけを導入する事に意味はないでしょうけれども。 

今回は以上で。それでは。

[note] SSL/TLS証明書の有効期限大幅短縮への対応

久しぶりにサーバーの設定と運用プロセスの大幅な変更をやる羽目になっててんやわんや、な話です。

何かというと、この前、自前のサーバーのSSL/TLS証明書の期限切れが近づいたので、いつものように更新をしようとしたんです。httpsの認証に必要なアレです。

そしたら、なんかSSL/TLS証明書の有効期限が年単位ではなくなっていて。現状、新規発行の証明書の有効期限は200日が上限なんだとか。

どういう事なのかと調べてみると、世界共通のSSL/TLS証明書の仕様として、段階的に有効期限を短縮する事になっているんだそうで。

従来(2020年以降)は398日だったのが、2026年3月15日から200日になり、2027年3月15日に100日、最終的に2029年3月15日には47日まで短縮される事が決まっていると。今はその第一段階目というわけですね。

何それ困る。

いや思い返してみれば、数年前から複数年の証明書が発行不可能になっていたり、認証用サーバーの所在地域やベースの認証局そのものが変更になってたりと色々変化が起きている様子はあったのですが、運用の仕方自体を見直さなければならない程まで短縮されるとは認識していませんでした。半分くらい寝耳に水です。

ちなみに私のところでは、年に1回、メール認証で証明書を取得して、手動でサーバーに設置するやり方を採用していました。ルーチン化されているとはいえ相応に手間もかかるわけで、それが1.5ヶ月に1回となると、完全に破綻してしまいます。何より証明書の更新契約なんてそんな頻繁にやってられません。 

いや、情報収集が出来ていない自分の落ち度と言われればその通りではあるんですが。

でもですね、実際問題として、サーバー管理を生業としているわけでもなく、普段はIT業界の外で仕事をしている個人に、こういう一般に広報周知されない特定の専門的技術領域の仕様変更のロードマップまで把握して抜かりなく事前に対応しろ、というのは無理があると思うし、把握出来てない人や対応が出来ない・遅れた人の事なんぞ知らん、というのは流石に酷いと思うのですよ。社会基盤の維持管理の進め方としてそのやり方はないんじゃないの、と。

そもそも期限を短縮する理由は、セキュリティ面の強化が主目的で、インシデント発生時の証明書差し替えの範囲限定・迅速化等が副次的な目的らしいですが、その説明では全ての証明書の有効期限短縮を強行する必要性を十分に立証出来ているとは言えないように思うのです。

セキュリティ強化が必要な理由であるところの暗号解読可能性については、量子コンピューティングが現実に脅威となる水準に達する見込みは依然として立っていないのだから理由にならないでしょう。というか量子コンピューティングが暗号解読を現実に実行出来るレベルになるなら、そもそも既存の計算困難性に拠って立つ暗号方式自体が原則無力化されるのだから、証明書(暗号鍵)の更新期間を短縮したところで無意味です。

証明書差し替えの範囲限定云々についても、インシデントの発生如何に関わらず全ての証明書を頻繁に差し替えさせるというのではどう見ても管理コストは逆に激増するし、本末転倒で対策になっていないと言うべきです。

とはいえ、愚痴を吐いても嘆いても仕方ない話だし、不満を抱えつつも対応する他ありません。というわけで慌てて情報収集。

まず世間一般の対応、その中心となる有料の証明書プロバイダーがどう対応しているのかというと、契約自体は年単位で、証明書のサーバーへの設置・更新を自動で行うヘルパープログラムに対応しているプラン等を用意している様子。概ね更新手続きを代行する形になるんでしょうか。しかし当然ながら想定する顧客は法人につき相応に高価であまりにオーバースペック、細々と運用している個人のサーバーにはとても採用出来ません。

どうしたものか、いっそwebサイトは廃止するか？等と思案しつつ色々調べてみると、私のような個人等への救済措置がありました。無償の認証機関がいつの間にか標準的な地位を確立していており、世の小規模サイトの大半はその証明書を利用しているそうで。

その名もLet's Encrypt。少々怪しげな名称とは裏腹に、多数の大手IT企業から支援を受けて標準の地位を確立しつつある、自由でセキュアなインターネットを支える一大組織です。

有料の認証機関発行の証明書と暗号等も含めた方式上は全く同じで、信頼性も十分。違いはただ一点、シール(アイコン)がない事だけです。サイトに貼れる**signとかいうマークです。どうでもいいですね。元々何の意味があるのか理解し難い要素でしたし。

ざっと調べて機能的には特に問題もなく、もうこれは大人しく世の流れに流されて、Let's Encryptに乗り換えるしかない、という判断の下、乗り換えてしまいました。

その作業は、全世界に広く普及させる事を主眼に置いているだけあって、基本的には簡単なものです。Let's Encryptは当然ながらおよそ想定される全てのサーバー構成に対応してもいます。

私のところでは単一ドメインで運用していて、OSにはubuntu server, webサーバーにはnginxを採用していますが、その場合の推奨される要件は以下の2点です。 

1.  snapが使える

2. 証明書取得時の認証用にport80(http)を開放する(全世界のIPからアクセス可)

これを満たせば、証明書取得・設定ツールをインストールして、コマンドを打つだけで証明書の取得及びwebサーバーへの証明書登録が出来るようになっています。なお認証にはDNSレコードを使用する方式等もありますが、あえてその方法を選ぶ理由は通常はないかと思います。

以下、私のところで使った方法、すなわちubuntuでnginxに証明書を設置する場合について記述します。

取得・設定ツールには複数ありますが、certbotが最もよく使われていて事実上標準的な地位にあるので、特殊な事情があるというのでなければこれを使う事が推奨されています。certbotは下記コマンドでsnapから取得します。(1の要件はこのためです。なんでもsnapでないと適切な管理が困難なのだとか。多分にセキュリティ面の都合でしょうか)

$ sudo snap install certbot

なお、apt版のcertbotがインストールされている場合は競合して不具合が出る可能性があるので事前にアンインストールしておく必要があるようです。 

そして、ファイアウォール等でport80へのアクセスが制限されている場合はそれを解除します。特定の国や地域からのアクセスを遮断するgeoblock系のフィルタを導入している場合はこれも解除します。(特定の地域等をフィルタから外す、というような設定では対応出来ません。Let's Encryptでは複数の国・地域に分散設置されている認証用サーバーのIPや所在地等を一切公開しておらず、予告なく変更もする方針を明らかにしているからです。)

例えば、iptablesで設定するなら、次のようなコマンドでルールの1番目にport80へのアクセスは(地域等を問わず)無条件で通すよう設定すればよいでしょう。

$ sudo iptables -I INPUT -p tcp --dport 80 -j ACCEPT

ufwしか使っていないのなら、

$ sudo ufw allow to any port 80

とか。

その上で、 

 $ sudo certbot --nginx

等として、プロンプトで対象ドメインの選択等の応答をすれば、証明書の取得及びnginxへのSSL証明書の設定(/etc/nginx/sites-available以下の更新)が実行されます。簡単ですね。

なおドメインを引数で指定する場合は、-dオプションを使います。

$ sudo certbot -d [ドメイン名(example.com等)] --nginx  

なお、私の所ではこのコマンドは使っていません。というのも、対象のサーバーは元々nginxを使ってウェブサーバーとして運用していたので、当然SSL関連も含め設定には色々と手を入れていたのですが、certbotの自動設定でそれらが都合よくマージされるとは考えづらかったのです。仮に現状では良くても、将来的に問題が生じるかもしれませんしね。

なので、certbotでの処理は証明書を取得するだけに留め、取得した証明書のnginxへの設定については手動で設定ファイル(nginx.conf等)を書き換える方法を取りました。要するに、従来の認証局からの証明書取得からサーバーへの設置までの手続きをcertbotに入れ替えただけという事です。思うに、初めてwebサーバーを立ち上げるようなケース以外は、基本このやり方を採用するんじゃないでしょうか。

その(証明書だけを取得する)場合はcertonlyオプションを指定します。

$ sudo certbot certonly --nginx

取得された証明書は、(2026年9月現在のところ)以下の通りに保存されます。

証明書: /etc/letsencrypt/live/[ドメイン名]/fullchain.pem

秘密鍵: /etc/letsencrypt/live/[ドメイン名]/privkey.pem

nginxの設定を手動でする場合は、/etc/nginx/sites-available/以下の設定ファイルに上記証明書及び鍵ファイルのパスを書き込みます。(ssl_certificate及びssl_certificate_keyをそれぞれ書き換え)

証明書の取得・設置を終えたら、nginxを再起動します。

$ sudo systemctl restart nginx 

以上で完了。

ufwやiptable等でportを開放した場合は、元に戻しておきます。

上記のiptablesコマンドでルール1を追加したのなら、次のようなコマンドでそのルール1を削除します。(iptablesを使うような人には釈迦に説法だろうとは思いますが、iptableの操作、特にルールの削除は間違えると大変な事になる可能性があるので、事前にsudo iptables -L --line-numbers等で削除するルール番号等が正しいかよく確認した上で実行すべきでしょう。)

$ sudo iptables -D INPUT 1 

ufwなら開放したポートを閉じます。

$ sudo ufw deny to any port 80

これで後始末も終わり。

取得した証明書の有効期限は、現在のところ90日です。有効期限が近づいたらまたcertbotを動かして証明書を更新します。(portを閉じている場合はその都度開ける必要があります)

面倒ならcron等で自動起動するようスケジューリングしておけばいいのですが、port管理の問題等もあるので私のところではそこは手動でやる事にしています。面倒ですが仕方ない。常時全世界からアクセスOKにしてしまうとbotや不正アクセス試行の類が酷いことになるのでここは譲れないのです。

有効期限短縮のスケジュールに変わりがなければ、2029年3月15日までは90日サイクルでの更新でいい、という事になる筈ですが、全世界ほぼ全てのサーバーが対応を迫られる、しかもかなりドラスティックな変更なので、個々の証明書の有効期限は準備期間を設ける意味で2029年3月15日よりかなり前に短縮されるのではないかと思われます。またその時には更新プロセスを修正する必要があるでしょう。

そんな感じで。私のところは単一のサーバーの設定だけですが、それでも情報収集から既存プロセスへの適用可否等の検討やらはそれなりに手間で、疲れました。世の中のサーバー管理者の皆様の中には大規模なサーバー群のドメインと証明書の管理プロセスの見直しに頭を抱えている人も多数いるんでしょうね。ご愁傷さまです。

もっとも、それを専門とする事業者にとってはいい仕事の種になるのだろうし、むしろ歓迎している向きもそれなりにいるのかもしれませんが。零細個人としては、そういう業界の都合に巻き込まないで欲しいと思う次第です。やれやれ。

[PC] ubuntu26.04LTSアップグレード

やってしまいました。LTS版の最新リリース26.04LTSの導入を。25.10からのアップグレードです。

いつもなら8月のfix版リリースまで待つところなのですが、coreutilsのrust移行やwayland完全移行等、今回のアップグレードの目玉的な部分が25.10の時点で概ね導入済だった事と、その他の部分も私が使用していない機能に関するものが大半のようだった事から、致命的な不具合が起こる可能性は低く、仮に問題があっても自力でなんとかなる範囲だろうと思われたので。

ただ、serverの方は流石にfix版でないとまずいし、それ以前に24.04LTSからのアップグレードにつき、そのLTS版からの直接のパスはfix版まで開放されないので今回は対象外です。

なお、26.04LTSから要求スペックが上がり、RAMの下限が6GBに引き上げられた事は割とショッキングなニュースとして各所で取り上げられていましたが、私は元々OSに余計な機能は要らない派につきLubuntu環境(LXQt)を使っているのでその辺は関係ありません。

今回は長らくやっていないserver版のアップグレードの予行演習も兼ねてコマンドラインから実行しました。 aptのupdate等をして最新状態にしてから下記コマンド。

$ sudo do-release-upgrade -d

-dオプションは、開発版(リリース版ではない)へのアップグレードをする際のオプションです。もちろん26.04はリリース版なのですが、リリース直後は開発版扱いになる事があります。その期間は通常数日程度のようですが、その経過後は-dオプションは不要になります。まずは-dオプションなしもしくは-cオプション(チェックのみ)で実行してみて、開発版扱いになっているか確認してから必要なら付ければよいでしょう。

プロセス自体はいつもと同じ。途中でconfigファイル数点を保持するかどうかと、最後にサポート終了になったパッケージを削除するかを聞かれるのでそれに応答して、あとは待つだけで終了。予想通り特に目立ったエラーはなし。

ただ、何も問題がなかった、というわけではありませんでした。一通り必要な機能等をチェックしたところ、私の使用する範囲だけでも下記のような問題がありました。自力で修正可能か、運用の変更で対処可能な範囲なので問題ないといえばそうなんですが、すんなりとはいかないのが相変わらず敷居の高いOSだなあと。もっともIM周りはLXQtを使っている事が主要因でしょうからそこは自業自得に近いと言えなくもないのでしょうけれど。

・不具合その1　日本語入力が出来ない

久々に遭遇です。アップグレード直後はIMが起動すらしません。昔はむしろアップグレード直後は日本語が使えないのが当たり前だったなあと懐かしさすら覚える不具合ですが、実際問題どうにかしないと話にならないので、最優先で修正しました。

im-configやLXQtの言語設定等から調べてみると、デフォルトがibusになっていて、元々使っていたfcitx-mozcはインストールはされているものの無効になっているようでした。

fcitxを有効にしようとしてもなかなかうまく行かなかったので、いっその事fcitxも最新版のfcitx5にしてしまおう、というわけでsudo apt install fcitx5-mozc等としてインストールし、環境変数を設定の上、ログイン時にfcitx5が自動起動するようセッション設定に追加。また、fcitx5-configから起動キー等を調整(デフォルトだと何故かハングルキーとかが起動キーに設定されているので削除したり)した後、再起動or再ログインで解決。

・不具合その2　apparmor周りの設定厳格化でアプリが動作しなくなる

これは25.10の時点で既に発生していたものの再発です。apparmorがアプリのファイルアクセス権限を厳格化したために幾つかのアプリでファイルの読み書きが出来なくなるケースが生じる、というものですが、前回同様、/etc/apparmor.d/以下の該当するアプリの設定ファイルを25.04以前のバージョンと同じレベルの制限になるよう修正すれば解決しました。

・不具合その3　firefox等ブラウザから外部アプリを開けない

特定のファイル等をダウンロードして外部アプリで開く設定が機能しない場合がありました。これ自体は解決出来ていません。そもそも関連付け設定のところで特定のアプリを指定するところから問題があり、候補一覧に何も表示されなかったりします。

仕方がないので修正は一旦諦め、直接開くのではなく、一旦ファイルを保存して、別途アプリ側から開くようにして対処しています。致命的ではないものの、正直面倒なのでどうにかしたいとは思うのですが、さてどうすれば。不具合その2と同様アプリの実行権限の問題のようにも見えますし、であればプラウザのapparmor設定とかを見直せばいいのでしょうか。。。 

・不具合その4　 削除されたライブラリに依存するアプリがあった

これは大半の人は関係ないでしょう。どころか、ディストリビューションの問題ですらありません。個々のアプリの側の問題です。

企業等の提供するアプリの中にはAppImage形式のものがありますが、私の使っているものの中には特定のライブラリ(so)に依存するものがあり、26.04ではそのライブラリが削除されてしまったために、実行しようとするとそれがない、とエラーが出てしまうものがあったのです。外部環境に依存しない事が売り、の筈なのに。。。

これについては、もちろん当該ライブラリを再インストールするというのも解決法ではあるのでしょうが、削除されたという事はサポート外になったという事なので、あまり推奨される対処ではないと思われます。幸いというか、私の場合は当該アプリの最新版が発行されており、そちらは問題なく動作したので解決しましたが、更新が遅いアプリ等、アプリ側での対処が困難な場合にはライブラリの方を再インストールする必要があるでしょう。 

aptやsnap等から提供されるアプリのみを使っているなら、依存性関連は基本インストール時に解決済みの筈なので気にする必要はないでしょう。外部のdebやAppImage等でのみ問題になる話と思われます。

その他は特に問題はありませんでした。アップグレードでよく問題が起きるサウンド等のメディア関連では何も問題なし。wayland関連についても、UIや表示周りでは何も問題なし。 

そんなところで。 おつかれです。

<追記>

しばらく使っていると、当初は気づかなかった不具合も色々と見つかりました。

特に致命的だったのは、アプリが起動に失敗するというものですね。主にSnap版のアプリで発生しましたが、AppImage形式のものでも起こりました。

共通するのは、コンソールで起動してみると、Failed to connect to Wayland display: とかなんとか表示される点です。つまるところWayland環境との齟齬が問題なのでしょう。

なお実行環境側としては、環境変数その他を確認してもwayland環境になってはいるので、おそらくはアプリ側の問題と思われます。Wayland完全移行を謳うバージョンにつき個々のアプリ側もXから移行したバージョンを採用したところ、それが不完全だった、という事なのでしょう。

具体的な例でいうと、chromiumでこれが起こります。他にもAppImageのアプリでも同様のメッセージが出て起動に失敗するものがあるので、共通するライブラリの問題なのかもしれませんね。

何にせよ、とりあえずはアプリ側で個別に対応する他ない模様です。

chromiumの場合は、起動オプションでX11環境モードにすると起動する、という情報があったのでとりあえずそれで対応しています。 具体的には、--ozone-platform=x11とつければ起動しました。wayland環境はXサーバとの互換レイヤーが整備されているので、アプリ側で対応せずともその機能のお世話になればいい、というわけですね。別に個別にwaylandネイティブにしなくとも従来のXサーバ対応仕様で問題なく動くのです。しかるに、アプリの開発側も焦って杜撰な実装をしてこんな不具合を出す位ならしばらく様子を見た方がよかったのでは？と思います。

この手のオプションがない、あるいはあるかもしれないけれどわからないアプリはとりあえず使えないので放置しています。困ったものです。

<追記>

26.04.1がリリースされたので24.04からのアップグレードをテストしてみました。が、coreutils周りの脆弱性対応等のため24.04からのアップグレードはまだリリースレベルに達していないようです。ご注意を。 

[PC] ubuntu24.04から26.04.1へのアップグレードその1

<追記2>

26.04.1のリリースから遅れること1ヶ月強、24.04から26.04(26.04.1)へのアップグレードが正式リリースされました。

なお、上記のアプリ起動失敗については、いつのまにか解消されていました。解消されたタイミングは不明ですが、updateで治ったという事なのでしょう。一方ブラウザからダウンロードファイルを直接外部アプリで開けない点は変わっていません。これはもう仕様ということでしょうか。

<追記3>

サーバーについてもアップグレードしました。例によってトラブルに遭遇しつつなんとか完遂。 

[PC] ubuntu24.04から26.04.1へのアップグレードその2 (サーバー編) 

[IT law] ネット中毒等についてSNS事業者の消費者保護責任を認定

する判決が米で出されました。

対象はMetaとGoogle。LAの地裁での判決です。

その趣旨は、Instagram等のSNSサイトのデザインについて、際限なく情報を表示し、ユーザーの興味を引き続ける構造になっており、若年者にネット中毒に陥らせる危険が高いにも関わらず、その旨の注意喚起等を全くしておらず、消費者保護の責任を果たしていない、との事。

賠償金は二社合計で6m$(Meta7割、Google3割)と米国のこの手の裁判にしては控えめですが、同種の係争が多数提起されている中、それらへの波及は避けられないだろう事から両社は無論、SNS業界全体について構造的な転換を迫るものになると見られています。

MetaについてはNew Mexicoで提起されていた別の裁判で児童に対する性加害についての責任が認定されたとの報道もあります。安全だと誤認させ、かつ防止措置を怠ったとの事です。こちらは児童への性犯罪という事で賠償額が300m$と高額。

如何な巨大企業と言えども積み重なればその事業の存亡にも関わるでしょう。米ではタバコへの規制になぞらえる向きも多数見られます。いわゆるデジタルドラッグに認定された、という見方も出来るでしょう。

タバコの例を見ても明らかな通り、この種の社会的な認定は、その対象が継続的に被害者を生む性質のものであって、とりわけネガティブなものである場合、ほぼ半永久的に継続します。ほとぼりが冷めれば忘れられる、というような事業者にとって都合のいい事は起こりません。

自社サービスへのユーザーの依存をそのビジネスの生命線とするSNS事業者は、しかし過剰な依存は防がなければならない、という根本的に背反する制約の下、極めて困難な舵取りを余儀なくされる事になるでしょう。

あるいはAustraliaのように若年者のSNS利用制限に踏み切らなければならなくなるかもしれません。事業者にとっては極めて厳しいシナリオですが、仮にそうなったとしても、これまで何の配慮も対策もせず、各ユーザーの自己責任として問題を放置し続けて来た事業者側の自業自得なので諦めて従う他ないでしょうね。

ネットの有用性、社会インフラとしての重要性等がどれほどあろうとも、個人の人権はそれに優越します。それが子供達についてのものであればなおさらです。

若年者がネットに依存する事は健全とは到底言い難いし、依存性も含めて有害な情報が溢れるネットに触れるのは精神がそれなりに成熟して情報の選別や自制が出来るようになってからにすべき、という主張には一理も二理もあります。事業者側の事情や建前を持ち出したところで、到底太刀打ちできないでしょう。

もっとも、大人になれば必ずしも自制等が出来るというわけではなく、単に年齢制限や年齢によるゾーニング等をすれば済む、とは言えないのが悩ましいところではあります。本来なら、年齢によらず依存に陥らせないように律せられるべきだろうし、性犯罪者等の悪意、依存すれば社会生活に問題が生じる違法行為への誘引、またデマや陰謀論、扇動のような明らかに悪性の情報は排除されるべきなのでしょうが、そんな事が出来るとも思えません。

その辺りの議論はこれから嫌が応にもせざるを得ないだろうし、その中である種の基準が形成されていくのでしょう。それが巨大企業、産業の利益を優先させるものではなく、子供達にとってあるべきものとなる事を願います。

[IT] OpenAIの動画生成サービスSoraが突如として終了、高コスト低収益という現実

OpenAIの動画生成サービスSoraが突然終了する旨発表されたそうで。

サービス開始からわずか数ヶ月。議論は様々あれど、技術的な評価は低くはなかっただけに、あまりにも早い打ち切りに、ユーザーはじめ各所には驚きをもって受け止められています。

理由は定かではありませんが、大方の推測するところでは必要とする計算リソースがあまりに大きく、採算の見込みが立たないためだと言われています。

今後はより収益の見込めるコード生成等の他のサービスにそのリソースを振り分けるつもりなのだろう、とも。

生成AIサービスの火付け役として、集まった莫大な投資資金を元に多方面にほとんど無差別的に手を出していた同社ですが、コード生成等の将来性の高い分野では後発のAnthropicに先行を許してしまい、収益化の見込みについても疑義が付く状態でした。

動画生成はどんなモデルを用いるにせよとにかくデータ量が半端でなく、当然計算量もテキスト生成とは比較にならない膨大なコストがかかる一方、それに見合う収入をどうやって得るのかは全く見込みが立たない状態でしたので、今回の決定は致し方ないというか当然の帰結であるように思います。著作権の問題も解決出来そうにありませんでしたしね。

やっぱり現状のLLMベースの生成AIはコスト(と収益性の低さ)が問題ですよねぇ。。。特に画像関連は結果が一目瞭然なので素人にも訴求しやすく多くの人が夢を見るのも当然だろうとは思うのですが、そのコストに見合う高い料金を払う理由、ニーズが見いだせない、という根本的なビジネス上の欠陥を解決出来ない事にはどうにもなりません。

Google系のGeminiも利用者増で計算機リソースが不足した結果、無料版の使用制限がきつくなって突然使い物にならなくなったと嘆くユーザーが多数出ているとも聞きます。中には、ワークフローの見直しを余儀なくされて、こんな事ならはじめから無料版のサービスなどない方がよかったと言う人もいるとか。

ユーザーとしては、ある日突然サービスが使えなくなるようでは危なくて業務等では使えないし、今後はその辺のリスクを警戒し、信用出来ないサービスを敬遠する向きも増えるでしょう。

ただでさえ高コストなのに、競合が増えればそれだけユーザーの獲得も難しくなるわけで。未だ採算化のロードマップも確立出来ていない各サービスが、ユーザーを獲得しつつ収益も飛躍的に上げるというのは極めて困難なミッションです。

初期の熱狂が冷め、その莫大な計算コストという現実と向き合う事を余儀なくされる生成AI業界ですが、さてどこがどの程度生き残る事が出来るのやら。

なお、数ヶ月前から行われていたDisneyとの協業もこれでご破産だそうです。こっちはもし進めていたとしても莫大な著作権料を要求される事は必至だったでしょうし、どう転んでも採算的には詰んでいたのかもしれませんね。

[PC] pdfの編集コマンドpdftkでファイルが開けない問題

この間、pdfファイルのページの順番を入れ替えようとしたんです。Linux環境で。

問題のpdfファイルは、スキャン時に設定を怠ったのか、見開き2ページの順番が逆になっていたものでした。本来p1,p2,p3,p4,p5,p6,p7...とページが並ぶべきところが、p1,p3,p2,p5,p4,p7,p6...となっていたんです。見開きで表示する分には問題ないんでしょうけれど、1ページずつ見るとなると行ったり来たりしなければならないので鬱陶しく、当然修正したくなったのです。ただ、ページ数が多く、libreoffice等のGUIアプリで手動でちまちま編集するのは流石に厳しかったのですね。

で、コマンドラインから実行出来るユーティリティpdftkを使おうとしたんですが。そのsnap版を入れて使ってみたら、pdfファイルが存在しないとエラーが出る。

具体的には下記のような感じです。入力ファイル名がaaa.pdf、800ページまでを入れ替えてaaa_fix.pdfに保存するコマンドです。コマンドに並べたい順番にページを入力するんですが、多すぎるので途中(p8からp799まで)は省略しています。(なお実際のコマンドはスクリプトで出力、実行しています。)

 $ pdftk A=aaa.pdf cat A1 A3 A2 A5 A4 A7 A6 (中略) A800-end output aaa_fix.pdf
     Error: Unable to find file.
     Error: Failed to open PDF file: 
        aaa.pdf
     Done.  Input errors, so no output created.

もちろんファイルはカレントに存在します。だけど見つからない、開けないという。どうにもなりません。

調べてみると、同様の問題に遭遇した例はいくつか見受けられました。あまり例が多くなく、状況もまちまちで原因がいまいちはっきりしなかったのですが、それらを総合した結果としては、どうもsnapの実行ファイルのファイルアクセス権限が制限されている事が原因のように思われました。私の使っているubuntuの現行であるところの25.10ではapparmor周り等でセキュリティ権限の厳格化が行われ、幾つかのアプリでファイルが開けない問題が発生したりしましたが、その関連とかかな、と。

ので、 調べた中にあった解決法の一つ、snapの実行ファイルから/usr/binにシンボリックリンクを貼る、というのをやってみました。下記コマンドです。

$ sudo ln -s /snap/pdftk/current/usr/bin/pdftk /usr/bin/pdftk

すると上記エラーが解消され、正常に変換されるようになったのです。

これで直ったという事は、snapの実行ファイルディレクトリからの実行と/usr/bin/以下からの実行では権限が違う、という話だったのでしょうか。そうだとして、セキュリティの面からはそういう区別をするポリシーもわからなくはないのですが、ユーザー側からすれば不具合でしかないし、そういう齟齬は生じないようにして欲しかったですね。snapは環境によらず動作出来るのが売りの筈なのですし。

なおpdftkにはaptからインストール出来るjava版があって、試してはいませんがこちらなら今回のような問題は起こらないでしょう。私はjavaは処理のオーバーヘッドがきついし実行環境周りでよく問題が起きる(起きていた)のがトラウマになっているので基本使わないのですが、その辺を気にしない方であればこちらの方が無難かもしれません。

ともあれ、そういう事で。やれやれです。 

[note] IsraelとUSがIranのKhameneiを殺害

Iranの最高指導者、Ali Hosseini Khameneiが殺害されたとの事です。

勿論IsraelとUSの犯行です。Khameneiが指導者としての執務をしていた建物を多数の親族らもろとも破壊したそうです。

Iranは当然ながらミサイル等でIsraelや周辺国の米軍関連施設に報復を行い、Hormuz海峡も封鎖しました。事実上IranとIsrael及びUSは戦争に突入したと言えるでしょう。

Israelの目的は前回と同じく自国に対するIranの脅威の排除、USはそのサポートをしつつ、敵国Iranを潰して壊滅的になったUS国内の政権支持率の改善を狙う、といったところでしょう。

まあ、そんなこと出来るわけがないんですが。正直何がしたいのか、何が出来ると思っているのか、理解し難いところです。どうするつもりなんでしょう。まさか何も考えていないのでしょうか。Trumpとその取り巻きの事ですから、まさかではないんでしょうね。

周知の通り、Iranは古来から国民のほぼ全員が生まれながらのイスラム教徒の国です。それも厳格で原理主義に近いShia派の。そしてIranの指導者は強い権限こそあるものの、独裁者ではありません。文字通り国民を指導する代表者であり、国民の支持も相応に得ている、むしろ教皇や大統領に近い性質のものです。

当然、体制の実質も、強権的な独裁者が君臨していたかつてのイラクやリビア、シリア等とはわけが違います。指導者を排除したところで、国民の意識がイスラムの教義に支配されている以上、Israelへの敵対的な姿勢は変わる筈もないし、誰に代わろうと指導者は敬虔で厳格、原理主義的なイスラム教徒のままです。

また、KhameneiはIsraelとの敵対的な姿勢、そしてIsraelやUSからの攻撃への反撃も辞さない姿勢から穏健派とまでは言えなかったものの、ISISやAl-Qaeda、タリバンといったイスラム過激派とは一線を画し、自国の側からの武力行使には抑制的でした。実際、9/11の同時多発テロの際には、Al-Qaedaを非難する声明を出してもいました。そのKhameneiの排除は、Iranの穏健化をもたらすどころか、逆に積極的な武力行使を引き起こす可能性があります。

加えて、Khameneiは既に86歳と高齢で、当然ながら死去に備えて後継者の選定も進められていました。排除したところで、多少スタンスが違うだけの似たような指導者に代わるだけの話でしょう。実際Iranでは混乱は生じておらず、まして民主化の動きなどは全く見られません。

つまり、Khameneiの排除には意味がない。少なくとも、IsraelやUSの意図しているだろうような、IsraelやUSに友好的なIranに変わる事などありえないのです。イラクにはあったような抵抗勢力、対立勢力というのが存在しない以上、傀儡政権というのも作り得ないでしょう。

なお、先日のIran国内での大規模デモの際には、Iran革命で滅んだPahlavi朝の復活を叫んだ者もそれなりにいたと言われていますが、その崩壊から既に50年近く、今更そんな求心力はないでしょう。また、そもそも王朝の復活は独裁体制への回帰にほかならないわけで、国民に広く受け入れられるとは考えられないし、その復活を望む者も少なくとも現体制周りには皆無でしょうから、なおさら現実的ではないでしょう。

すなわち、IranがKhameneiの死を契機として、親Israel、親US的な国へと自発的に変化する事など考えられないのです。本当にそのような変化を求めるというのなら、それこそIranと全面戦争をした上で征服し、IsraelかUSの完全な支配下に置く必要があるでしょう。

しかしそれは主にリソースの面で物理的に不可能です。

Iranは人口9000万を超える大国なのです。国土も広大で、日本と比較すれば4倍超。この規模の国が完全に他国の支配下に置かれた例は第二次世界大戦の終結以降は存在しません。USとの距離も考えれば尚更でしょう。やはりIranの体制は変わり得ないのです。

そして、体制が変わらないのならば、Iranを攻撃し、Khameneiをはじめとした上層部を中心に多数を殺害したIsraelとUSに対する報復は嫌が応にも激化するでしょう。IsraelとUSの側としても、指導者を殺してしまった以上、もう後戻りも出来ません。双方がやめどころを見失い、際限なく応酬がエスカレートする可能性も決して低くはありません。

少なくとも、Hormuz海峡近辺の情勢は相当の長期に渡って極めて厳しいものになるだろう事が予想されます。当然ながら、その見通しに従って、石油価格等は既に大きく動いてもいます。

IsraelとUSは、取り返しのつかない、出口のない泥沼の戦争に踏み出してしまったのではないか。そのように思えてならないのです。Israelは言うに及ばず、Trump政権下のUSが後先考えない危険な国になってしまった事はわかり切っていた話ですが、第一次Trump政権での唯一の美徳であった武力行使への抑制的な姿勢も失った今、もはや最悪の人的災害と化してしまいました。

その被害を受けるIranはじめ関係各国の方々には誠にご愁傷様です。おそらくその後でTrump周りが大量に弾劾を受け、大幅に権限が抑制されるだろう中間選挙まであと半年余り、あまりにも長いその苦難の時期を、どうか被害を抑制して生き延びられるよう祈ります。

<追記>

US側にも死者が確認されました。Iranの報復は、その継続が困難になるまで続くものと予想されます。そしてその攻撃範囲は広く、早くも迎撃ミサイル等のリソース枯渇が懸念されているUS側の死者は今後も増えるものと見込まれます。あるいは防空が満足に出来なくなれば、加速度的に増える可能性も否定できません。そうすれば当然、USはますます抜け出せなくなるでしょう。無論Iran側の死者はそれ以上に増える。双方死者が増えれば、それだけ応酬が激化する。しかし自ら対話の道を閉ざしたUSに止める術はない。

こうなるだろう事はわかり切っていたでしょうに、USはなぜこの戦争を始めてしまったのでしょうか。Israel以外の誰も望まなかっただろうこの愚かな殺し合いを。

[PC] 多数の中華Androidタブレットでファームウェアへのマルウェア感染発覚

AlldocubeやHeadwolf等の格安中華タブレットの多数機種について、ファームウェアにKeenaduと呼ばれるマルウェアが感染した状態で出荷されていた事が発覚したんだそうで。

該当するモデルは現時点で確認されている限り、MediatekのHelio G99を積んだものの一部のようです。人気の機種が多数該当していますね。格安帯では最もポピュラーなSoCだけに、被害に遭ったユーザーもかなり多いでしょう。

問題のKeenaduは遠隔操作を可能にする最悪なバックドア系のもので、ファームウェアに仕込まれていた事からユーザー側ではどうする事も出来ず、使用中止を余儀なくされたユーザーの嘆きの声が溢れています。

これぐらいメーカーが開発段階か遅くともリリース前にチェックしておけば簡単に防げた筈でしょうに、そんな手間すら惜しかったんでしょうか。安かろう悪かろうにも程があるというものです。

該当する各機種については、アップデートの配信が各社で計画されているとのこと。中華タブレットではOSやファームウェアのアップデートは原則なされないのが通常なのですが、流石にこれはリコールというか返品・返金ものなので、放置するわけにもいかなかったという事なのでしょう。

しかし、その修正もすぐ配信出来るわけではなく、暫く時間もかかるとの事。アップデート自体普段していない事なので手間取っているのかもしれませんが、それを待たずに返品・返金を求めるユーザーも多いのではないでしょうか。

中華製タブレットはただでさえ信頼性の薄かったところ、今後は敬遠する人もさらに増えるでしょう。

なお私もAlldocube製のタブレットは幾つか持っているものの、どれも数年以上前のモデルなので本件とは関係は無かったのですが、alldocube製は中華タブレットの中では割と品質が良い部類だと思っていたので残念です。

[biz] iRobot倒産

円盤型掃除ロボットの元祖的なRoombaのメーカーiRobotがChapter11を申請して倒産したそうです。

後発の中国メーカー製に押されつつあったとはいえ、米国や日本では同型ロボットのシェアではトップを維持していた同社ですが、元々赤字体質だったところに、ブームが去って需要そのものが落ち込んだ事、またインフレや関税の大幅な増税等のコスト上昇に耐えられず、近年は継続に疑義が付く状態でした。

頼みの綱になる筈だったAmazonへの身売りも、EUの当局からNGが出されて万事休す。あえなく今回の申請に至ったというわけです。ご愁傷さまですね。

新製品でブームを起こした新興企業が、そのブームの終わりと共に潰れた。よくある話ではあるのですが、残念な事です。せめて赤字体質だけでも改善しておけば、縮小しつつも継続する事も出来たでしょうに。もっとも言うは易し、諸々のジレンマ等もあったのでしょう。

そもそもコンシューマ向けのロボット事業は、これまで数多くの企業が挑み、その殆どが夢破れて来た、非常に困難な事業です。むしろあのような限定的な機能しかない掃除用ロボットをここまで広め、事業を成立させる事が出来ただけ、よくやったものと評して良いのかもしれません。お疲れ様です。

ところで、ブームと言えば、今まさにブームの真っ只中なAI関連事業が連想されるわけですが。その先行きについては強気な人が大勢を占める一方で疑念を持つ人も増えつつある同事業ですが、その中には今ひとつ実用性に乏しく、詐欺同然のものも多数含まれているのが現状です。それらの怪しい事業はおそらく今回の件と同様の道を辿る、というかそこまで行く事も出来ず潰れるものと予想されますが、その膨れ上がった期待とそれに応じて流れ込んだ資金の規模は掃除用ロボットの比ではないですからね。。。さてどうなることやら。 

Roomba vacuum cleaner firm files for bankruptcy

[PC] Ubuntu25.10アップグレード

半期に1度の恒例行事、ubuntuアップグレードの季節がやってきました。

25.04から25.10へ。25.10のコードネームはQuesting Quokka、探求するクオッカ(ワラビー)です。

25.10ではsudoが従来のCからRustベース(sudo-rs)になる等、割とコアな部分の変更が加えられています。しかも25.10のリリース直後のsudo-rsには致命的な脆弱性が複数確認されていたりして、やばい雰囲気がそこはかとなく漂っていました。なおその脆弱性は既に修正済です。

とはいえ、変更点は基本的なシステム回りに集中していて、UIやアプリの挙動等の互換性という意味では特段問題ないように見えるものでした。ので、デスクトップとして使うのならさほど深刻な問題はないだろうと判断し、更新に踏み切ったというわけです。

いつものようにupdate-managerから更新。特段問題なく完了。

これまたいつもの動作確認を実施すると、予想通りデスクトップ等の見た目も挙動もほぼ変更なし、従って日本語入力・サウンド・ビデオその他諸々の基本的な動作についても問題なし。

ただ、問題がなかったわけではありません。 OS全体の話ではないのですが、下記のようなトラブル(?)に遭遇しました。

1.一部のアプリの動作がおかしくなる

2.一部のアプリが消滅 

1は、どうもアプリのファイルアクセス権限が制限されているようで、ファイルやディレクトリが開けずエラーを吐くケースが見られたというものです。

調べてみたところ、Apparmorの設定が変更され、ファイル等へのアクセス制限が強化されていたのが原因のようで、/etc/apparmor.d以下にある問題の生じたアプリの設定ファイルを以前のバージョンのものに修正する事で解決されました。(差分を見ると、25.10では基本のアクセス権限がリードオンリーになる旨の記述が追加されていました。)

Apparmorが原因の不具合というのは久しぶりな気がします。 昔はよくあってとても苦しめられましたけれども、近年は問題を起こす事は稀になっていましたから。しかし調査の過程で目にした情報からすると、今でもちょくちょく問題を起こしているようです。私は運良く遭遇しなかっただけという事でしょうか。

この辺は安全性とのトレードオフの話なので、ある程度この種の問題が生じるのは仕方がない事ではあるのですが、警告もなく唐突に規制を強めて、アプリが動かなくなってユーザーが困っても知らん、というやり方はあまりに配慮に欠けるというか、無責任だと言わざるを得ません。短期サポートとはいえ建前上はベータではない正式版なのに。。。こういうところがLinuxが一般に広まらない所以だろうわけですが、一向に改善されませんね。困ったものです。

2の方は、これまでもよくあった話ではあるのですが、今回は私がよく使っていた電子ブックのビューアーが後継が追加される事もなく消えていたりして、個人的に困りました。ビューアーとして複数のアプリを併用していたので、残った他のアプリに移行する事になる、だろうのですが、データによってはアプリ毎にエラーが出るものと出ないものがまちまちで、消えたアプリでしか開いていなかったものがあるので、ちょっとどうしようかなと。また新しいアプリを探すのかと思うとげんなりです。

まあでも、そのくらいです。 過去にアップグレードで発生した深刻な不具合の数々に比べれば大した話ではありません。所詮短期サポート版ですし。ただ、次の26.04はLTSなので、それは万全の状態でリリースされるよう願いたいものですね。前回の24.04LTSの時のような惨事だけは勘弁です。

しかし26.04LTSでは今回不具合を起こしたシステムツールのRust移行が全面的に進められる予定なんですよね。。。予定通りになるにせよ、不具合の発生状況から取りやめになるにしろ、トラブルになる可能性は高そうで憂鬱です。ともあれ、今回はこれでおしまい。

[note] 情報の偏りがもたらすdiscommunication

どうにも話が通じない、というか。

話の前提となる事実や状況についての認識がかけ離れていて、コミュニケーションを取るのに困る事がなんだか増えたような気がするんです。

それ自体は、もとより立場も来歴も知識も異なる人同士であれば起こって当然の事ではあるんですが、基本的にそういう齟齬はパーソナルな事柄を中心に起こるもの、な筈です。そうであれば別に困りません。むしろそういう齟齬があるからこそ人同士のコミュニケーションに意味が生じるとも言えるでしょう。

困るのは、それ以外の場合、殊に客観的な事実や状況について深刻な齟齬がある場合です。

単純な勘違いや記憶違い位なら指摘すればそれで済むのですが、何がどうしたのか、明らかに事実と異なる認識を、しかも強固に持っているようなケースが以前より増えたように思うのです。

そのような場合は、訂正は極めて困難、あるいは不可能です。宗教における教義とまでは行かずとも、それに近い困難さを感じる事もあります。

以下、国際的な話の場合を例に取って述べます。

国際的な話題の場合、当然ながら国や地域、またそれらの関係についての知識・認識が前提として必要になるわけですが、これがどうにもおかしい事があります。

とりわけ、他国と日本との関係については、天動説的というか、まるで日本が常にその中心かその付近にいるかのように考えている、としか思えないような言動をしばしば耳にします。

具体例で言えば、最近の日本と中国の台湾を巡る関係悪化についての話で、中国の総領事が高市総理に対して過激な発言をした件について、"世界が見ている中であのような暴言、恥ずかしくないのか"、とかそういった言葉が出てくるのです。

こちらは、世界が見ている？何を言ってるの？と困惑する他ないわけです。

本来言うまでもない話だと思うんですが、どの国の人も、自分達に直接関係しない他国の話など気にも留めません。日本のメディアや一般市民にしても、例えばインドとパキスタン、あるいはイギリスとフランス、またイスラエルとイラン、近々ではタイとカンボジア、そういった他国同士が多少関係を悪化させた時に、それに興味を持って注目する人、注目した人がどれほどいるでしょうか。

ああそう、大変だね、と一応事実を認識した上で聞き流すならまだ関心を持っている方で、大半はそもそも気にも留めなかったでしょう。まして詳細な経緯、具体的なやり取りに関心を持つはずもありません。

当然です。他人事なのですから。 そしてそれは、そのまま他国の人が日本について取る態度でもあるのです。ああそう、大変そうだね。私達に関係ないなら、どうぞご勝手に。

他国間の事に関心を持ち、注目するのは、自分達に直接関係する、それも現に関わる必要がある場合のみです。米国で言えば、Ukraine-Russia、Israel-Arab諸国のような場合ですね。実際に戦争をやっている地域が幾つもあるのに、口喧嘩や貿易規制程度に一々注目する意味もないでしょう。

実際、件の日中の関係悪化についての米国での報道での扱いは微々たるものでした。"日本が中国を怒らせ、制裁を課されている"、という記事がworldカテゴリの中で取り上げられただけです。トップニュースはEpstein filesの公開に関する話題やICEの不法移民摘発等、国内のニュースが大半を占め、そこに時折IsraelやUkraine-Russiaの話題が入り込む位でした。日中の問題自体、注目などされていない。関係記事を漁れば詳細も知ることも出来なくはないでしょうが、わざわざそんな事をする物好きはほとんどいません。

米国は台湾問題については当事者に次ぐ、比較的関係の深い立場の国ですが、その米国ですらそのような扱いです。世界が見ている、などとはとても言えないでしょう。

いわんや総領事の発言をや。そんな事は日中両国内のローカルな話でしかないのです。

しかるに、上記の世界が見ている云々の発言は、世界に恥を晒している、という視点から、すなわち欧米各国等の他国も含めた国際世論という、ありもしない立場を仮想し、その存在を前提にして発せられているように聞こえました。そして、国際世論の観点から間違っているのは中国の対応であり、従って諸国は日本の味方な筈だから、各国の協力も得られるだろう、というような想定で話していたのではないかと思うのです。

そんな想定は成り立たないのですけれども。この状況であえて日本の味方をする、すなわち中国の敵に回るメリットはありません。しかるに中国との関係悪化がもたらすリスクを考えれば、中国との関係を徒に悪化させようとする国などないでしょう。欧米各国ですらその例外ではありません。仮にそれができるとすれば、中国との利害関係がない国に限られるでしょうけれども、そんな国が現実にあるのかも疑わしいところですし、そんな国があったとしてもそのような国は日本とも利害関係はないでしょう。

この辺りは私の推測ですが、"世界が見ている・・・"という発言は、そういう、ありえない想定を前提としているものと解釈しなければ理解し難いように思われたのです。その人は、おそらくは、中国に強硬な態度を取るべきだ、という意見を持っていたのでしょう。国際世論の趨勢を根拠にして。

私としてはそんな事は不可能だ、というかそんな事は他国にとっては関係ないし、今回の件はもっぱら日中間の問題だから、現状の日中双方の立場と関係を踏まえて日本は中国に対してどう対処すべきか、今後の関係はどのような形を目指すべきか、とかそういう話をするべきだと思うのだけれど、相手の寄って立つ前提、問題に対する視点からして噛み合わないものになってしまっていて、発言に窮してしまった、というわけです。

話を続けるのは困難だと思ったので、その時の会話はそこで打ち切りにしました。コミュニケーション失敗です。

話を戻します。このところ、上記と似たような、ありもしない前提からされる発言を聞く機会が増えたように思います。これが偶然なのか、必然なのかは判然としません。

ただ、こと上記の、日本が各国から常に注目され、重視されている、という認識については、国内メディアというかネットも含めた日本人向け報道の傾向が影響しているのではないか、と思う事はあります。

元より日本の国内メディアはとにかく日本が関係する事しか報道しない、という傾向が非常に強い性質があります。自国の関係する話題を優先する事自体は万国共通ではありますが、日本のメディアは特にその傾向が強いという事はしばしば指摘される所です。

その傾向は、海外の事柄についても貫徹されています。日本が関係した事しか報道しない。すなわち、世界中の国々が営む膨大な活動のほんの一部しか取り上げない。その数少ない取り上げられる事柄についても、基本的に日本の視点からしか見ないし、見せない。相手の視点が取り上げられるとしても、それは日本に対するアクションがあった時、すなわち日本に注目した時の事しか取り上げられず、その他の事は最低限に留める。加えて、ポジティブなアクションがされた場合は殊更に取り上げる、と万事そんな調子です。第三者的な視点など皆無です。

するとどうなるか。 

結果として、日本向けの報道・記事に載る海外各国とその人々と関係する事柄は、およそ全て日本がその中心にいるか、重要で密接な関係を持ち、あるいは特別視される、"常に承認されている"姿ばかりが取り上げられ、報じられる事になるでしょう。実際には、その出来事の内のほんの一部、一時、一側面に過ぎない事であっても。

それに晒された人が、当然の結果として、海外各国、またその日本との関係はそういうものなのだ、と錯覚するようになる。一方でそれ以外の、日本とは関係ないところで営まれる各国の通常は全て捨象されてしまう。あるいは、そのような姿が主たるものと思い込む。

そういう、日本語メディアのもたらす弊害、言ってしまえば一種の洗脳こそが、認識の齟齬の根本的な原因なのではないか。

各国の実態を知っていれば無論ありえないし、そうでなくとも、日本向けでない各国の報道を多少なりとでも見ていれば起こり得ない話です。私自身、本当にそんな事が起こるのか、との疑念を禁じ得ないところではあります。しかし、考えれば考えるほど、そういう事が起こっているのではないか、という思いを否定出来ないのです。ほとんどの人は各国の実態なんて知らないし、日本向けでない各国の報道なんて見ないのですから。

そしてそのような現象は、日本と海外の関係に対する認識だけではなく、その他の、あらゆる事柄で起こりうるでしょう。溢れ返る情報に溺れ、そこで取り上げられた部分や側面だけが全てとされて、捨象された事柄・部分・側面等は存在しないものとして扱われてしまう。恐ろしくも病的。SFホラーのような話です。

まあ、実際にそうなっているのだとしても、どうする事も出来ないのですけれども。メディアは受け手が見たい情報を報じるものなのだし、多くの人がそういう情報を求めているというのなら、誰がわざわざそれに逆らって、求められてもいない情報を流せるというのでしょう。まさしく求められていない情報が駆逐された結果が現状なのでしょうし。

誰も逆らえないし、そもそも逆らう気にもなれない。無意味だから。

表現の自由の行き着く先が、そのようなディストピア染みた、人々(の多数派)が求める情報に支配される世界だと言うのなら、それは皮肉な話ですね。

そこでは、情報に流されない、従って錯覚に溺れる事が出来ない人は、理不尽な疎外感を抱えて生きる他ないのでしょう。嫌な世の中になっていく、と一人で嘆くのがせいぜいでしょうか。残念なことです。

[PC] M.2 NVMe SSDのバックアップで四苦八苦

もうすぐWindows10のサポート終了ですね。

Microsoftは言うまでもなく、サポートを生業にしている向きや、PCの製造・販売に携わる人たちにとっては書き入れ時ではあるんでしょうが、ユーザーにとっては迷惑千万。対応が面倒で仕方ないです。しかし放置するわけにも行きません。というわけで、私の周りでもWindows10を積んだPCのリプレースやアップグレードを順次進めていたのです。

と言っても、アップグレードについて言えば、手間はかかるとは言え、以前のメジャーバージョンアップのようなドラスティックな変更を伴うものではないわけで、基本的に特段の問題もなくWindows11へ移行出来ていたのです。

が、1台だけ非常に手間取ったものがありまして。

そいつは比較的新しい、従ってリプレースの必要がない、DELLのInspironシリーズのノートPCだったんですが、そのアップグレードの準備としてバックアップを作成しようとしたら、これが上手く行かないのです。

私は、バックアップを作る時は、ストレージを取り出して、作業用のデスクトップ(Linux)に接続して、sgdiskやpartclone,dd等でGPTとパーティションのイメージを吸い出す方法でやっているのです。当該PCについても同様にやろうとしたんですね。つまずいたのはここでした。

ストレージはSKHynix社製のM.2 NVMeのSSD(256GB)が採用されていたのですけれども、その規格が2230と短く、作業用PCのM.2ポートが対応していなかったのがケチの付き始めでした。2242以降しか対応するネジ穴がなく、そのままでは取り付けられなかったのです。

仕方がないので、まずPCIeの変換カードを調達して接続してみました。なお使ったカードはAINEX製のAIF-09、SATAにも対応するコンボカードです。しかし認識されない。変換カードの不良か？ と思うも、別のNVMe SSD(2280規格)を繋いでみるとこれは認識したので、そういうわけでもないようでした。どうもMBとSSDの相性の問題のようで、であればもうどうしようもないので断念。

次にUSB接続のアダプタを調達して接続してみました。UGREEN製の、NVMe専用のモデルです。すると一応認識しました。しかし、接続が安定しません。数秒から数十秒置きにブツブツと切れます。

これについては、Troubleshootingを色々調べてみると、ケーブルの相性が良くない可能性が高い、との情報がありました。これに従い、別のケーブルに繋ぐと一応安定しました。

なので、ようやくイメージを吸い出す作業に入れた・・・のですが、さらにいくつか問題が発生します。

まず、速度が非常に遅い。2GB/min位しか出ません。とはいえこれは致命的ではありません。たかが数十分から1時間程度、じっと待てば良いだけの事です。

しかし、次に起きた事は致命的でした。ただでさえ遅い速度がさらに徐々に低下していき、10分もしない内に遂にはエラーを起こして止まってしまうのです。partclone上ではエラーセクタが出た旨表示されていましたが、エラーが出てもスキップして継続するモードでやっても、一度エラーが出ると復帰出来ず、全てエラー扱いになってしまうのです。dmesg等を見ると、デバイス自体がエラーを起こして接続が完全に切れてしまっていました。SSDのセクタエラーが原因ではない事は明らかです。

これは熱暴走か、と思い、アダプタのカバーを取り外してみればやはりというか超高熱。とても手で触れるような状態ではありませんでした。一般にNVMe SSDの動作温度は60度位が目安とされていますが、明らかにそれ以上です。カバーは一応金属製だったのですが、あの発熱では焼け石に水にもならなかったでしょう。

もうこれはちゃんと冷やすしかない、という事で、カバーは取り外したままにして、発熱部の周辺に台を作って保冷剤等を接触しないように設置して冷えるようにして再トライ。

すると速度の低下も起こらず、2GB/min程度のまま安定して読み出しが出来るようになったのです。読み出しが2GB/minなのはどういう事なのだろうという疑問は残りますが、今回はそこは問題ではないのでスルー。途中保冷剤を交換しつつ待つこと数十分、エラーもなくバックアップが完了しました。なおその後のWindows11へのアップグレードも問題なし。やれやれです。

後で調べてみたのですが、USB接続のNVMe変換アダプタの類は大体熱問題を抱える事になるそうですね。 勿論SSDの発熱量にもよるのでしょうけれど、今回の感じだと大体アウトなんだろうと思います。中には冷却ファン付きのアダプタすらあるんだとか。正直欠陥品では？と思わざるを得ません。

今回の私に限って言えば、最低限の目的は果たせたのだから、まあいいかとギリギリ言えなくもないとも思いますが、あそこまでしないとまともに動かない(事がある)、というのでは、大半の人にとってはやはり欠陥品だろうと思います。

一応、今回問題になったSSDの規格が2230と小さく、従ってチップの密集度が高いために熱暴走が起こりやすかった可能性も考えられますが、もしそうだったとしても、アダプタ側で対応を謳っている以上はちゃんと対応していて然るべきでしょうし。

ともあれ、今回はこれでおしまい。お疲れ。 

[pol] 溺れる政府はそのまま沈む

選挙が近づくこの頃。石破政権発足時からこの方、もはや全てを諦めたものとしか思えない破れかぶれの醜態を晒し続けていた政府与党ですが、まだ未練があるようで。

一時しのぎでしかない備蓄米の放出が好意的に受け取られた、その一事のみをもって、衆院の解散総選挙を画策しているそうです。

米の価格高騰だけを見ても、問題は何も解決していないというのに。備蓄米の残りは既に3割程度にまで減り、補充のあてもなく、後一回でほぼ使い切るだろうその後はどうするのか。関税撤廃等の根本的な解決策には検討に着手すらしていません。である以上、あと一月もすれば元の木阿弥になるだろう事は明らかです。

そもそも、備蓄米放出で政府への支持が上向いたと言ってもその程度はごくわずかです。政権発足以来、数々の失政を経て下落を続けた支持率は、内閣・政党支持率共に惨敗した昨年の選挙時のそれにも到底及びません。

当たり前です。当時からこれまで、政府は一貫して国民の負担を増やしただけで、経済環境も社会問題も対外関係も、何一つとして改善された事などないのですから。支持が集まるわけもありません。

にも関わらず、誰が見ても一時しのぎでしかない、いわゆるバラマキ政策が受け入れられたからと言って、安直にもそれに縋り、選挙に打って出ようとしてしまう。

正気ではない、と言わざるを得ません。今になって右往左往したところでどうにもならないでしょうに。溺れる者は藁をも掴む、とは言いますが、彼らが掴んでいるのは藁ですらなく、海の底で海藻を掴んでいるようなものではないでしょうか。正直見るに堪えませんね。