Linux

この記事を作った動機 最近 Mailcow によるメールサーバを使っているが、SOGo という内蔵されたフロントエンドがあり、メール送受信だけでなく、カレンダー機能もついている。これについてタスク管理機能を試したところ、分かりづらいところや不具合があったのでそれに対してどうできるか一例を記録する。 タスクが登録できない件について 問題の様子 対処 SOGo の設定において、短い日付形式が空だと、日本語の言語設定のとき、フロントエンドのJSがクラッシュしタスクの日付を正しく設定できないことがあることが分かった。そのため、そこを明示することで対処した。 完了したタスクを表示する フィルター設定の中に、日付だけではなく、完了したタスクを表示するかの項目もひとまとまりになっている。その中の項目をスクロールして完了タスクを表示するように選択する。 使った画像とか mailcow: dockerized documentation https://docs.mailcow.email/ (2026年8月4日) SOGo | Free Open Source Webmail https://www.sogo.nu/ (2026年9月14日) 関連する記事とか Mailcow を使いたい 参考にしたサイトとか 特になし。

この記事を作った動機 簡易的に GTX 1080 Ti と Linux 環境において、Virtio(OpenGL) や Venus(Vulkan) による GPU アクセラレーションを利用する方法について、今まで諦めていた。それでも諦めきれずに定期的に調べていたところ、対処方法が見つかった。それについて、簡易的に症状とやったことを記録したい。 デモ 以下の動画は、RDP 経由で Venus による 仮想 GPU を利用して Vulkan や OpenGL のアプリが動作している事を示している。マインクラフトの操作については、今回の RDP セットアップの仕様上、絶対座標しか送られておらず視点を動かすことができていなかったり、VPN など遠隔地から RDP 接続をして動かしているため、ラグが大きくぎこちないものとなっている。 前座 Virtio における GPU 加速 Virt-Manager において標準で利用できる仮想 GPU である。AMD や Intel の GPU 環境では特別なことをしなくても、私個人の体験としては利用できたが、Nvidia 環境ではそうならなかった。 Venus における GPU 加速 最近あたらしい GPU 加速手段の一つとして実装されたもので、デフォルトでは Virt−Manager などからはまだ利用できるようにはなっていない模様である。これについては直接 QEMU をコマンドラインから起動することが私が現在できていることであり、Virt-Manager からは XML の設定をいじってみたものの成功していない。 今回犠牲になっている事 今回提示する解決策は、最低限 仮想 GPU が Nvidia の GTX1080Ti において動作するようにする事を目的としており、以下の負担や犠牲がある。 ...

この記事を作った動機 libvirt の仕様を理解していなかった結果、大量の時間を溶かすことがあったので記録したい。具体的には、仮想マシンに対してRDPのためにポート転送を設定しようとしたが、libvirtが作成する、defaultネットワークに属している、virbr0ブリッジはnftablesをいじっても言うことを聞かないほど、ガチガチに守られていて使うべきではないという結論に至った。 今回はそこに至るまでの経緯と、実際に機能する事を確かめた対処方法について記録する。機能する対処方法の概要としては、libvirt以外に、手動でブリッジを専用に作成し、それに対してfirewalldでNATやDNATを構成し、仮想マシンにそのブリッジを使うように設定する事をする。 機能した対処方法 仮定 仮想マシンを動かしているホストマシンは、firewalldのpublicゾーンを使用している ホストマシンは、ブリッジに対して192.168.150.1/24のIPを持つ 仮想マシンのIPは手動で192.168.150.25/24を割り当て、ゲートウェイにはホストマシンに向けて192.168.150.1と設定する sysctl -w net.ipv4.ip_forward=1が設定されており、カーネルが異なるインタフェース間のパケットの行き来を許可していること ブリッジを作成 sudo brctl addbr virt sudo ip link set virt up sudo ip addr add 192.168.150.1/24 dev virt 仮想マシンを作成したブリッジを使うように設定 firewalld でNATとDNATを構成する # ゾーンとポリシー(NAT用)を作成 sudo firewall-cmd --new-zone=virt --permanent sudo firewall-cmd --zone=virt --add-interface=virt --permanent sudo firewall-cmd --zone=virt --new-policy=nat --permanent sudo firewall-cmd --policy=nat --add-ingress-zone=virt --permanent sudo firewall-cmd --policy=nat --add-egress-zone=public --permanent sudo firewall-cmd --policy=nat --add-masquerade --permanent # ポート転送設定(DNAT) sudo firewall-cmd --zone=public --add-forward-port=port=33890:proto=tcp:toport=3389:toaddr=192.168.150.25 --permanent sudo firewall-cmd --zone=public --add-forward-port=port=33890:proto=udp:toport=3389:toaddr=192.168.150.25 --permanent # NATが機能するようにマスカレードと転送を設定 sudo firewall-cmd --zone=public --add-masquerade --permanent sudo firewall-cmd --zone=virt --add-forward --permanent sudo systemctl restart firewalld 問題至るまでの経緯 今までの構成を見直す 今まで仮想マシンへのRDPアクセスは、無理やりVPN経路を通じて同じLAN内に仮想マシンを参加させることで動かしていた。接続が不安定であり定期的にVPNが接続できなくなったり、ネットワークトポロジ的にも循環経路を形成しかねないように見受けられた。VPNを介さずにホストマシンを直接介させることで、仮想マシンに対してRDPを行うために、今回は仮想マシンのRDPポートである、3389に対してポート転送を行う事を考えた。 ...

この記事を作った動機 Linux 環境にて簡単に Web アプリを作ろうとしたところ、以下のようになって開発サーバを立ち上げられない事態になり、開発が続行できなくなったということがあって、だいぶ時間を溶かしたので記録を取る。 npm create vite@latest # ... # npx でも症状は同じ npm run dev # npm notice run rss-listing@0.0.0 dev # npm notice run vite # sh: 行 1: vite: command not found 簡単な結論 npm を使ったプロジェクトを立ち上げる際は、フォルダのパスに特殊文字が含まれていないか注意する。:がパスに含まれていた場合、npm はそれを自動的にエスケープするなどの処理をせずに、PATHを登録してしまう。npm の機構によって動的にPATHが正しく登録できないと、npm でインストールされたパッケージのバイナリやスクリプトが必要なタイミングで実行できず、開発を続行できない。BASH の PATH の解釈が不正なところで途切れて、npm の動作に必要なバイナリやスクリプトへのパスが通らず、動作が破綻する。問題の具体例は以下のとおりである。 問題のパスの例 # /home/useName/work/free/2026-08-18-09:16:14-1787012174/ProjectName/node_modules/.bin 問題のパスが npm(npx) によって、PATH に登録される例 # /home/useName/work/free/2026-08-18-09:16:14-1787012174/ProjectName/node_modules/.bin:/home/linuxbrew/.linuxbrew/bin:/home/linuxbrew/.linuxbrew/sbin:/opt/miniconda3/condabin:/usr/local/bin # 実際にはもっと長く続くが例として途中でちょん切っている。 BASH での解釈のされ方の例 # /home/useName/work/free/2026-08-18-09 # 意図しないところでパスがちょん切れる # 16 # 意図しないところでパスがちょん切れる # 14-1787012174/ProjectName/node_modules/.bin # /home/linuxbrew/.linuxbrew/bin # /home/linuxbrew/.linuxbrew/sbin # /opt/miniconda3/condabin # /usr/local/bin # ... なおこのような問題は、Windows など最初から、":" の文字がフォルダ名などに特殊文字として登録できないファイルシステムを使う環境では起こらないかもしれない。私が、普段の環境で使っているのは、Ext4 というファイルシステムであり、":“がファイル名やフォルダ名に含めることができ、問題が起こったものだと思われる。npm 関連のリポジトリにこれについて Issue を作ったり Pull Request を作るべきかは謎であるが、私はその点に関して自信は何もないので、結局何もしないだろう。 ...

この記事を作った動機 最近、なんか公開鍵認証で鍵を登録したのにパスワードを求められたり、あるいは完全に特定のPCにおいて、SSH ログインが動作しているPCと設定が同じであるにもかかわらずログインできなかったりと、色々振り回されていることについて、いい加減対応しようと思い調べた。それで色々手こずったので、記録を残したい。 結論としては、SSH クライアントなど OpenSSL 周りはどんどん新しくなっていき、古い認証用バイナリは削除され、使えなくなることが時間の問題であることが分かった。SSH ログインによる ILO4 制御を諦めたほうが良いという結論になった。今まで SSH で管理してきたという背景からは、CLI で動く SSH であることが望ましかった。しかし、現実的な妥協点が、Selenium を使って ILO4 の Web インターフェースを自動化するか、RESTfulAPI を使って curl コマンドで ILO を HTTP により操作するということに至った。 環境 HPE Proliant Gen9 シリーズに搭載されている、ILO4 について。 ILO4 のバージョン iLO Feb 06 2023 2.82 ILO4 は LAN 内で動作しており、グローバル空間に直接つながっていない閉鎖的な環境下であり、SSH の暗号化がそれほど重要でない場面を想定 具体的な経緯など 組み込み機器にある SSH サーバはその用途に最適化されており、新しい規格についていけないところがある。いくらオプションを指定してももはや私が常用している Linux 環境の SSH クライアントではログイン不能であった。今までは、SSH クライアントに以下のオプションをつけることでゴリ押ししてログインできていたが、最近のアップデートの影響かできなくなったぽいことも、問題に本格的に取り組もうと思った動機であった。 KexAlgorithms=+diffie-hellman-group14-sha1 HostKeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa 上記設定が通用した OpenSSL のバージョンと、通用しなくなったと思われるバージョンを以下に示す。 通用するとき openssl -v OpenSSL 3.5.2 5 Aug 2025 (Library: OpenSSL 3.5.2 5 Aug 2025) 通用しないとき openssl -v OpenSSL 3.6.3 9 Jun 2026 (Library: OpenSSL 3.6.3 9 Jun 2026) 試したことについて RESTfulAPI と Curl コマンドを使う方法 (今回採用した手法) 結局のところ、HTTP を介して行われる、RESTfulAPI を直接 curl コマンドで叩くのが現実的であるということになったが、自分でスクリプトを書いたわけではない。とにかく ILO4 経由でサーバの電源をリモートで気軽に入れたいだけだったため、ローカルLLM (Gemma4-12B-qat) に直接書かせた。最初はまあ動かない物を出してきたが、ネットから ILO4 RESTful API Reference のドキュメントを引っ張り出して、全部ではなくAuthentication and Sessionsあたりのセッションの文字列をヒントとして与えたところで、動作するスクリプトを手に入れることができた。パスワードなどの認証情報(機密情報)も与えて、とりあえず簡単に動くスクリプトを作るように指示できるのは、学習データに入力内容が使われるおそれも心配しなくていいローカル LLM 環境ならではであるようにも思う。 ...

このページは、まだ未完成です。。。 nicotalk＆キャラ素材配布所 http://www.nicotalk.com/charasozai_kt.html （2024年5月16日） この記事を作った動機 最近、Google (Gmail) とかに深く関係があるのは嫌であることや、中央集権的な SAAS サービスへの不信がある。そこで、自前のメールサーバを持ちたいと思い、Mailcow を使おうとしたので不完全でいいので作業過程の記録を取りたい。 前提条件 Arch Linux 環境で作業を行い、Mailcow 公式サポートはない状態である 専用の物理 PC を割り当てる クリーンインストールで、Gnome デスクトップ環境や最低限のパッケージが入った、Arch Linux 環境 スリープを無効化している。-> gnomeの設定のメモ ⚙ firewalld は導入していないこと -> Prepare your system - mailcow: dockerized documentation できれば yayコマンド を導入する NetworkManager を使っている。 DNS サーバにクラウドフレアを使っている。 設定要件 自分の LAN (VPN) 環境のみからメールの送信を受け付け、グローバル IP 空間からはメールの送信を受け付けない メールの受信についての対策は、Mailcow 標準に頼りたい 利用者は自分や自分が許可した少数の身内のみ メールサーバ自体は直接グローバル IP 空間には晒さず、VPN や LAN のネットワーク空間を転送するようにして利用する。 ネットワーク構成 ネットワーク構成としては、通常のメールサーバではグローバル空間に配置してファイヤウォールに必要な分だけ慎重に穴を開けるなどのスタンスを取ると考えられるが、今回のはセキュリティーの観点から、そうはしなかった。 基本的には、メールサーバは直接グローバル空間には晒さず、かつNAT環境下にある自宅の専用に用意したサーバを使うという観点から、別の専用にグローバル空間とつながっていて固定IP持っている中継サーバ(VPS)で、ポート転送などを行うという形態を取った。また、セキュリティの観点から メールを送受信したり、サーバを管理できるユーザは、VPNによって自宅のLAN内にアクセスできる人間のみとし、グローバル空間からは、SMTPポートだけ、晒して、メールは送受信できるようにしつつ、外部の人間は今回構築するメールサーバに対して、リレーとして使ったり、送信を命令することはできないようにしている。メールを送信できる人は、メールサーバと同じLANに属しているユーザだけであり、メールの受信はどこからでもスパムでないこと、不正でないことを前提に、スパムフィルターで弾かれなかったものが受け付けられるという形態を取る。 中継には VPS を使い、メールサーバとVPS間は専用に用意したVPNネットワークで接続される。これにより、NAT超えも実現しながら、メールサーバを直接グローバル空間に晒さずに済むというものである。注意点としてはメールサーバ側のルーティングや、VPS側のファイヤウォール、転送設定がを間違っていると、セキュリティリスクになる点を留意する。 イメージ用の図いろいろ ネットワーク構成の概要 大まかなルート構成 VPSにおけるポート転送と特別なルーティング(nftables)で成立 通常のSMTPとして成立するルート 外部のメールサーバからの見え方 メール送受信のためのフロントエンドアクセスが出来る範囲 SMTP 関連パケットのルーティングについて メール受信時の経路 メール送信、SMTP における応答通信時における経路 不正な SMTP パケットの経路 ネットワーク設定 VPS プロバイダの設定 VPS の設定 メールサーバ本体の設定 説明用の仮定 メールアドレス xxxx@your.domain.comのようにする。 メールサーバについて mx.your.domain.comにホストすることにする。 IPアドレスを160.251.xxx.xxxとして仮定する。 Mailcow のインストール docker 環境の導入 # 必要なパッケージのインストール (jq は mailcow の依存関係) yay -Sy docker docker-compose jq # sudo pacman -Sy docker docker-compose jq # サービスの有効化 sudo systemctl enable --now docker # 必要であれば管理用ユーザを docker グループに追加し、権限を付与する sudo usermod -aG docker [targetUser] # 念のため再起動 sudo systemctl reboot IP アドレスの固定 今回は、NetworkManager を Gnome 環境に組み合わせた状態なので、Gnome の GUI から設定を行った。 ...

この記事を作った動機 最近、XPS 13 2in1 (intel 8th) を使っていて、バッテリーが完全に放電しきった状態で放置していることがあった。それで、通常であれば、CMOS 電池が設定内容を保持していて、UEFI の変数などのデータを保持しているはずだが、今回は違った。PC を充電器に繋ぎ、起動すると CMOS リセット時に見られる挙動である何度か再起動をするということになった。ようやく動いたかと思ったら、普段の設定とは異なって、Dual Boot 構成にしていた Windows がのそのそと起動し始めた。あまりのストレスに PC を投げ出したくなったが、結局色々調べて振り回されたことがあったので、記録したい。 経緯 PC が完全に2日程度放置していて、放電しきっていることに気づく。 Windows が起動しようとしてイライラする Linux 環境を立ち上げようとして、UEFI の設定画面でエントリを作成し起動を試みるも、“no resume device found"と言われ起動しない GURB の設定を編集しresume=と書かれているところを消すも、症状が改善せず。 起動するために USB を用意するもDD コマンドによる起動可能な USB 作成において説明される問題により、一度失敗する ローカルLLM である Gemma4 に投げるも、通常のターミナル環境を起動できないから困っているにもかかわらず、ターミナルを使えだの的はずれなことばっか出力してきて爆発しそうになる。例えばresume=noneにしたら上手くいくと出力してくるが、機能しなかった。 DD コマンドによる起動可能な USB 作成により、最終的に正しく起動する USB メモリを作成し、ようやくライブ環境の端末が起動する ドライブモードが RAID になっていることに気づき、AHCIに設定する しかし奇妙なことに最初ライブ環境を起動したとき、肝心の Linux 環境が入っている NVME SSD が見えず、もう一度 CMOS がリセットされた状態にして、再トライすることになる もう一回 AHCI に設定する ようやくライブ環境から SSD が見えるようになり、initramfs から resume の hooks を吹き飛ばすことと、GRUB の resume 設定をなしにして起動設定を再生成させる ようやく PC が正常に Linux 環境に起動するようになる。 今回の問題を起こした主犯であると思われる、CMOS 電池について調べる。 ポイント “no resume device found” で Linux 環境が起動しない 完全には確かめられていないが、どうも AHCI でもともと動かしていた物を、CMOS リセットが起こった時点で、RAIDになっていたために、それで起動しようとした結果起動できなかったということっぽい？しかし、USB のライブ環境に入れるようになってから、AHCI にドライブのモードを設定することは試したため、本当にそれが問題かは謎である。Linux 環境なら元からドライバは入っていそうなものだし、考えられることとしては、RAID モードであるときと、AHCI モードであるときで、パティーションの UUID が異なってしまうのかな？とは考えた。 ...

この記事を作った動機 最近 Linux 環境を使っていると、noto-fonts-cjk をインストールしているにもかかわらず、それが機能しないことがあった。具体的には、中華系フォントが日本語フォントとして優先されて表示され、読めないことはないが、地味に見慣れない文字になってしまう。今までは、Linux 環境のフォントは読めればいい、映ればいいで放置していたが、流石にそれはないなと思ったので、設定をしていた。 当然いちいち設定するときに調べるのはしんどいので、まとめが欲しいと思い記録を取ることにした。今回は、GNOME に関する設定と、fontconfig に関する設定の 2 つについて記録を取る。 前提 Linux 環境 GNOME を使っている GNOME-Tweaks の項目のみにおける制限 設定後は再起動する。 システム全体の変更の反映は管理者権限を使うことを前提としている。(sudo) フォントの配置場所と更新 システム全体 通常はこのフォルダは標準で何もしなくてもあるはずである。ない場合は、別の場所にフォントが保存されているか、インストールした OS が崩壊している可能性がある。 /usr/share/fonts ユーザ単体 ない場合はフォルダを新規作成する。 ~/.local/share/fonts 新しく配置したフォントの反映 sudo fc-cache -fv GNOME-Tweaks gnome-tweaks をインストールし、単に GUI を開いてポチポチするだけである。GNOME 環境ではすでにフォントがある程度デフォルトで固定されており基本的に崩れにくいため、デフォルトで満足しているならそのままでも良いと思われる。その場合は特別な設定が少なくとも GNOME に関しては、必要ないということである。 yay -Sy gnome-tweaks # sudo pacman -Sy gnome-tweaks Fontconfig 設定配置場所 システム全体 ない場合は、テキストファイルとして新規作成する。 ...

この記事を作った動機 CMOS リセット時に GRUB インストール時にデフォルトで作成される UEFI 設定が一緒に消えてしまう。結果として、はじめから Linux 環境を起動してほしいときに、意図した通りに起動しないことがあった。 そこでしばらくは BIOS から直接 Linux 環境がインストールされた環境をわざわざ選択して起動したり、UEFI設定から直接エントリを作成して、Linux を起動するようにするなど、面倒くさい事を繰り返していた。 今回は、それに対してefibootmgrというコマンドを使い、systemd によって一度起動したら自動でエントリがない場合に起動エントリを追加するようにした。その内容について記録を取りたい。 efibootmgr の使い方 インストール yay -Sy efibootmgr # sudo pacman -Sy efibootmgr エントリを追加する例 ブートローダである UEFI アプリケーションのパスを指定するとき注意が必要である。Linux 環境側から見て、/bootに EFI パティーションをマウントしていて、/boot/EFI/arch/grubx64.efi に対象のアプリファイルが配置されている場合の例について考える。この場合、efibootmgr で指定すべきパスは、/boot/EFI/arch/grubx64.efi ではなく /EFI/arch/grubx64.efi である。もしここで間違ったパスを指定していると、UEFI アプリケーションの起動に失敗し、UEFI の設定画面に飛ばされるなどの症状になる。 sudo efibootmgr -c -L ArchLinux -l /EFI/arch/grubx64.efi -d /dev/nvme0n1p1 fdisk で Linux 環境がインストールされたディスクを確認 sudo fdisk -l # Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors # Disk model: SAMSUNG MZVKW512HMJP-000H1 # Units: sectors of 1 * 512 = 512 bytes # Sector size (logical/physical): 512 bytes / 512 bytes # I/O size (minimum/optimal): 512 bytes / 512 bytes # Disklabel type: gpt # Disk identifier: # # Device Start End Sectors Size Type # /dev/nvme0n1p1 2048 2097152 2095105 1023M EFI System # /dev/nvme0n1p2 2099200 964689920 962590721 459G Linux filesystem # /dev/nvme0n1p3 964691968 1000214527 35522560 16.9G Linux swap ...

この記事を作った動機 Intel Arc で音声からの文字起こしができる Whisper を動かせることが分かったので記録したい。Whisper は PyTorch を使っているが、それを XPU に対応したものに差し替えることで動作が確認できたことに関して、具体的に作業内容を記録したい。 Whisper を使った文字起こしでは、Vibe を使うことでもできるが、Nvidia の CUDA 環境で無い限り、Intel Arc 環境においては、Vulkan を使ってしまう。PyTorch 環境においては XPU を使わなければ、Intel Arc の GPU 性能を使い切れていない気がすると思ったのもある。 ただ実際に試してみると、今のところそこまで早いとは言えず、むしろ Vulkan で動かしているときより遅い気もした。設定次第なのかもしれないが、そこまでは詳しく試していない。 環境の前提 Intel Arc を使っている Conda 環境を導入済み Linux 環境 記事の作業内容のまとめ conda create -n whisper conda activate whisper conda install pip pip install -U openai-whisper pip uninstall torch pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/xpu Whisper のインストール conda 環境を専用に作る conda create -n whisper conda activate whisper conda install pip whisper を pip でインストール 一旦 Nvidia 環境用の pytorch などがインストールされてしまうが、一旦はインストールを終わらせる。 ...