Command

このページは、まだ未完成です。。。 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 を使っている。 設定要件 自分の LAN (VPN) 環境のみからメールの送信を受け付け、グローバル IP 空間からはメールの送信を受け付けない メールの受信についての対策は、Mailcow 標準に頼りたい 利用者は自分や自分が許可した少数の身内のみ メールサーバ自体は直接グローバル IP 空間には晒さず、VPN や LAN のネットワーク空間を転送するようにして利用する。 Mailcow のインストール docker 環境の導入 # 必要なパッケージのインストール (jq は mailcow の依存関係) yay -Sy docker docker-compose # 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 などがインストールされてしまうが、一旦はインストールを終わらせる。 ...

このページは、まだ未完成です。。。 nicotalk＆キャラ素材配布所 http://www.nicotalk.com/charasozai_kt.html （2024年5月16日） この記事を作った動機 Intel Arc A770 LE を使っているが、NVIDIA の RTX や H100 などと異なり、標準でのサポートが薄い。そのため、フルで性能を引き出したい場合は、自分で LLM なら llama.cpp などを OneAPI を使ってコンパイルする必要がある。 LLM に関しては、当初は Intel Arc の環境において LM Studio を利用していたが、Vulkan でしか少なくとも現状では動作させることができなかった。Ollama についても試したが、どう頑張っても Apple の メタルプラットフォーム向けにしかコンパイルが動作せず、どうしよもない感じであった。そこでそれらのバックエンドである、llama.cpp を直接コンパイルして動かすことが考えられ、フロントは別に LibreChat を独立して用意する事が考えられた。 標準でも Vulkan の互換モードで動作し、使えないということはないが、多少性能が失われる。ただ、SYCL など向けに、Intel Arc を最大限使えるようにしようとすると、自分でコンパイルする必要がある。専用に用意しなければ現状では llama.cpp などは CPU しか利用できないとして Intel Arc をそもそも認識しないという挙動になった。またコンパイル自体や、コンパイル後のバイナリの扱いについて、特別な扱いが必要である。 Intel が公式で llama.cpp などのバイナリを配布していたりするが、バージョンが古く新しいモデルが動かないなど、弊害が生じる場合があった。 これらのことから、Intel Arc 向けに今回は、llama.cpp を SYCL を使えるようにコンパイルすることにした。また、PKGBUILD も作成し、手動で手順を踏まなくても、ある程度自動で Arch Linux や同じ系列の OS を使っていれば、環境が整うように工夫した。 Gemini Fast 3 を作業補助として使い、動くか確認しながら作業をした。ただそれだけだと、情報が十分まとまっておらず、環境を再構築する必要が生じたときなどに困難が想像されたため、記録を残して現状を整理したい。 なお、特にコンパイルや SYCL 周りの環境変数などは、LLM が吐き出したものをそのまま使っているだけの部分が多く色々間違っていたりする可能性がある。あくまで私の環境でやってみて動くかというのを基準にして書いている。 ...

この記事を作った動機 Android 端末において SoftEther VPN で稼働しているサーバに接続しようとすると、L2TP/IPsec を使った方法と、OpenVPN を使った方法の2つの接続方法がある。しかし、新しいバージョンの Android (12以降) において標準的に利用できる VPN には既に L2TP/IPsec は含まれておらず接続できない。また、OpenVPN を使った方法では、接続には成功するものの、そこに至るまでの設定が分かりづらかったり、技術的に一筋縄では行かないところが多々あった。これら経緯から、やったことについて記録を残したい。 ネットワーク構成 全体像 今回は、192.168.x.0/24 として描かれているネットワークに属するクライアントを Android スマホに見立てる。 今回問題になった特徴について 私の環境では通常のVPNネットワークと異なり、VPNに接続した先にあるネットワークを介して、更に別のネットワークにパケットを転送するPCがあって、そこを介してやり取りするという特徴があり、今回問題になった。 記録 VPN 接続したときのスマホのルーティングテーブルの様子 基本的に OpenVPN 関連で特別なルーティング設定をしても Android OS 側は直接制御を持っていないように見受けられる。以下のように192.168.1.0/24へのルーティングは、OpenVPN 側で正しく動作していても以下のように直接は確認できない。 adb shell cofud:/ $ ip route 10.0.0.0/8 dev ccmni1 proto kernel scope link src 10.150.92.221 192.168.30.12/30 dev tun0 proto kernel scope link src 192.168.30.13 cofud:/ $ exit 使うべきアプリ OpenVPN Connect ではなく、OpenVPN for Android を使うべき。 Android ではアプリを介してしか詳細な制御ができず、OpenVPN Connect は限られた設定項目しか利用できない問題があった。ルーティングや MTU、MSS、DNSなどについて細かく設定したい場合は、OpenVPN for Android などの別のアプリが必要であった。OpenVPN Connect などのアプリは、基本的に詳細な設定ができず、かつどのように読み込ませた".ovpn"などの設定が実際反映されているか確認が難しかったり色々困難があった。 ...

この記事を作った動機 Linux 環境において、VPN 環境についてトラブルシュートしていたところ、設定ミスが発生した。その原因として、viaという単語を正しく解釈できておらず、VPN クライアントの設定ミスでパケットをクライアント内のネットワークでループさせていたということがあった。今回の記事では、そのことについて軽くまとめたい。 説明 簡易的な解釈 iproute2 における via というキーワードは、ゲートウェイ設定(静的ルーティング、Next Hop)を表す。ルーティングされる対象のネットワーク via ゲートウェイ のような書き方になる。ゲートウェイとして、クライアント自身を設定してしまうとローカルでループしてパケットが期待どうりにネットワークに排出されない通信障害になる。 例えば、クライアントが VPN 接続先以外のネットワークから VPN 接続をすることを想定する。VPN クライアントは仮想インターフェース(vpn_vps)に、192.168.30.100/24 を持っていると仮定し、VPN サーバの仮想ハブが 192.168.30.2 をL3仮想スイッチルーティング用に持っている場合を想定する。この場合、192.168.30.0/24 のネットワークを経由して、192.168.0.0/24 にパケットを送りたい場合は、192.168.30.2 をゲートウェイを設定する。192.168.30.100/24 などクライアント自身を指定すると、通信がローカルでループし、VPN クライアントはそもそもパケットを外部のネットワークに排出せず、通信障害になる。 一見すると 192.168.0.0/24 via [VPNクライアント自身のIP] とかくと、VPNクライアント自身のIPを経由して外部に 192.168.0.0/24 宛てのパケットをルーティングするという解釈もできそうだが、少なくとも Linux 環境の iproute2 の設定においては、その解釈は間違っていそうである。あくまで via というキーワードが示しているのは、次にパケットをどのコンピュータに送るべきか、外部のルーティングが可能なコンピュータの IP を指定するという意味合いなようである。クライアント自身を設定してしまうと、クライアント自身にルーティングしてしまうようである。 また、Linux 環境の iproute2 における設定では、明確に外部のゲートウェイとなる PC の IP を指定しなくても、パケットを送り出したいインターフェースだけ指定するという、曖昧な設定もできるようである。192.168.0.0/24 dev vpn_vps のようにして、192.168.0.0/24 宛てのパケットを、vpn_vps という NIC からとにかく送り出すという設定はできるようである。 # いろんな書き方の例 # VPNクライアントとして接続されているルータPCにルーティングする仮想L3スイッチのIPを 192.168.30.2/24 として仮定している ip route add 192.168.0.0/24 via 192.168.30.2 dev vpn_vps ip route add 192.168.0.0/24 dev vpn_vps ip route add defalt via 192.168.30.2 dev vpn_vps 前提とするネットワーク構成図に関する説明 単語の説明 Home Network 自宅のネットワークなど私的に運用される LAN Foreign Network 大学や仕事場所、コンビニやファミレスなどにある公共の場所にある LAN 各ネットワークに関する説明 192.168.0.0/24 家庭用ルータではなく、主に nftables によって転送が管理されていて、カーネルで転送許可をしてある Linux ルータPCで管理されている自宅のネットワーク 192.168.30.0/24 固定 IP を持った VPS 上で動いている SoftEther VPN Server (DHCP サーバが有効) における仮想ハブのネットワーク 192.168.x.0/24 大学や仕事場所、コンビニやファミレスなどにある公共の場所のネットワーク 192.168.0.1/24 192.168.30.2/24 192.168.x.1/24 各ネットワークにおけるデフォルトゲートウェイ や DHCP、場合によっては DNS サーバーなど一通りのルーティングなどのネットワークに必要な機能を備えた装置の IP やルーティングを行う仮想L3スイッチの IP 192.168.30.13/24 SoftEther VPN Server を動かしている VPS がクライアントとして仮想ハブのネットワークに参加しているときの IP 192.168.30.100/24 Foreign Network から VPN 接続して仮想ハブに参加している VPN クライアントの仮想 NIC における IP NIC 名の説明 vpn_vps Foreign Network から VPS 上にある VPN の仮想ハブにアクセスする際に、VPN クライアントが使う仮想インターフェース名 その他説明 ルータPC Home Network で使われている、家庭用ルータの代わりに、スイッチとセットで nftables で転送や NAT を構成し、ip-hole や kea で DNS や DHCP サーバとしても機能するようにした Linux PC のこと。VPS 上で動いている VPN サーバのネットワークにもクライアントとして参加し、192.168.30.0/24 と 192.168.0.0/24 の間を転送する。異なるネットワーク間を転送する際、ARPプロキシ(L2ルーティング)は有効にしていない。 VPN サーバー 今回登場する VPN サーバーは直接 Home Network からは動作せず、VPS 上に専用に用意したものである。192.168.30.0/24 のネットワークを接続した VPN クライアントに提供する。仮想 L3 スイッチの設定により、192.168.0.0/24 宛てへのパケットを、192.168.30.0/24 に接続していてネットワークの越境が可能な転送設定をしてある VPN クライアントであるルータPCに仕向けるように設定してある。 説明の図 各ルーティング状況に関する説明 パケットがクライアント内部でループするイメージ 上記の図のような状況において、トラブルシュートでは以下のような厄介な挙動が見受けられた。 ...

この記事を作った動機 単に地味にしんどかった設定についてその手順をブログに記録したいだけ。今回は CapsLock キーを ESC キーに割り当てることについて、記事を記録する。環境については、以下の項目を前提としている。 Linux GNOME Wayland やり方 パッケージのインストール yay -S keyd # sudo pacman -S keyd 設定を書く (/etc/keyd/default.conf) [ids]の項目がないと一切設定が効かない。以下では*を指定することですべての入力デバイスを Keyd の対象として扱っている。再割当てには、[main]セクションを作り、そこに再割当て対象のキー名 = 割り当てたい役割のキー名という形で記述しただけである。 [ids] * [main] capslock = escape 明示的に Keyd 管理対象の入力デバイスを指定する 明示的に、Keyd の影響が及ぶキーボードなどのデバイスを指定するには、lsplug コマンドなど、何かしら接続された USB 機器の ID をリスト表示できるプログラムを使い、ID をたしかめ、そのうえで Keyd の設定項目の [ids] に対象のデバイスを指定する。 yay -S lsplug lsplug # ... # USB 4-11.4.2 [046d:c52b] Logitech, Inc. Unifying Receiver # USB 4-11.4.3 [046d:c52b] Logitech, Inc. Unifying Receiver # USB 4-11.4.4 [046d:c548] Logitech, Inc. Logi Bolt Receiver # ... [ids] 046d:c548 ; 除外する場合は "-"を先頭につける -046d:c52b [main] capslock = escape ...

この記事を作った動機 単に Git で間違ったリモートを設定してしまったときの修正方法の記録をする。 やり方 # 必要に応じて変更したリモートリポジトリにあるブランチ名を確認すること # リモート先に origin と指定した場合自動選択される。 git branch -a # * main # remotes/origin/main # Remote URL を間違える例 git remote add origin https://url.to.repo/userName/Receipt-OCR-to-CSV-with-PDF.git git remote -v # origin https://url.to.repo/userName/Receipt-OCR-to-CSV-with-PDF.git (fetch) # origin https://url.to.repo/userName/Receipt-OCR-to-CSV-with-PDF.git (push) # 正しい Remote URL に設定する例 git remote set-url origin gitea@192.168.1.9:userName/Receipt-OCR-to-CSV-with-PDF.git git remote -v # origin gitea@192.168.x.x:userName/Receipt-OCR-to-CSV-with-PDF.git (fetch) # rigin gitea@192.168.x.x:userName/Receipt-OCR-to-CSV-with-PDF.git (push) 参考にしたサイトとか Google Gemini https://gemini.google.com/app (2026年4月19日) Git - git-remote Documentation https://git-scm.com/docs/git-remote#Documentation/git-remote.txt-add (2026年4月19日) Git - git-remote Documentation https://git-scm.com/docs/git-remote#Documentation/git-remote.txt-set-url (2026年4月19日) Git - user-manual Documentation https://git-scm.com/docs/user-manual#managing-branches (2026年4月19日) Git - git-remote Documentation https://git-scm.com/docs/git-remote#Documentation/git-remote.txt-set-head (2026年4月19日) Git - git-branch Documentation https://git-scm.com/docs/git-branch#Documentation/git-branch.txt--a (2026年4月19日)