[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が動かなくなった、という報告をしているユーザーもいました。

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

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

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

ただ、これらのチェック手段も万能ではありません。攻撃手段はいくつも確立されていますし、法人等で外部のグループウェアを利用してそこから自社ドメインのメールを送信する場合等、複雑な経路を辿ってメールを送信する場合には特に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はリリース版なのですが、LTSの場合は8月のfix版がリリース版扱いとされ、初期バージョンはupgradeに関しては開発版扱いなのでこのオプションが必要なのです。

プロセス自体はいつもと同じ。途中で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サーバ対応仕様で問題なく動くのです。しかるに、アプリの開発側も焦って杜撰な実装をしてこんな不具合を出す位ならしばらく様子を見た方がよかったのでは？と思います。

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

[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製は中華タブレットの中では割と品質が良い部類だと思っていたので残念です。