Blender に Flamenco を導入して分散コンピューティング?を試す

このページは、まだ未完成です。。。 nicotalk&キャラ素材配布所 http://www.nicotalk.com/charasozai_kt.html (2024年5月16日) この記事を作った動機 最近 Gemini Fast 3 を使っていると、Blender において分散コンピューティングみたいなレンダリングの仕方ができることが分かり、気になった。それで、最初は Gemini Fast 3 が提案してきて、Blender - ArchWiki にも掲載されている、BlendNetを試そうと思った。 しかし、BlendNet のリポジトリを見てみると、実際のところは Blender 2.x.x の古い Blender にしか対応してなさそうな感じであった。私が使っている Blender のバージョンは 5.x.x 以降であったことから、別の物がないか Gemini Fast 3 に提案させてみると、Blender 公式の Flamenco が出てきたため試した。 そして、とりあえず動くようになるところまで、設定して確かめることができたため、そのことについて記録したい。まだ完全ではなく、途中でレンダリングに失敗したりと、成果物を得られている状態ではない。現状では Flamenco Manager と Flamenco Worker が実際に疎通を取り、Manager 側のクライアントの Blender からジョブを投げると、Worker 側がレンダリングを開始し負荷がかかるところまで確認した。 細かい説明(序章) 全体的な Flamenco 運用イメージ 以下に構築する環境のイメージを示す。今回はファイル共有サーバと Worker となる PC は物理的に1つに全部がまとまっている事を想定しているが、以下の画像ではわかりやすさのために、ファイル共有サーバやレンダリングを行う Worker farm の PC は物理的に分けている前提で表現している。 前提について 以下の点については、すでに設定されているものまたは前提として取り扱う。 Manager 側と Worker 側の間の設定 LAN で物理的に同じネットワークに繋がっているか、VPNによって実質的に同じネットワークに繋がっている。 SSH の設定が済ませてあり、LAN で物理的に同じネットワークに繋がっているときに疎通が取れる。 ping によって物理的に同じネットワークに繋がっているときに疎通が取れる。 Worker 側は GNOME RDP の設定が済ませてあり、Remmina クライアントにより LAN で物理的に同じネットワークに繋がっているときに疎通が取れる。 SFTP によるファイル共有が可能な状態になっている。 どちらも Linux 環境がセットアップされてあり、インターネットへの接続が確認できている。 firewalld をファイアウォールとして使っている。 VPN での接続がある場合について SMB ではなく SFTP によってファイルのやり取りを行う。 MTU サイズが十分小さく設定されており、ネットワーク障害が発生しないように設定されている。(MTUサイズ1000にするなど) 高遅延を前提とする。 Manager 側の視点から設定作業などを行い、Flamenco Manager と Blender を立ち上げた状態で作業する。 Manager 側と Worker 側は VPN によって遠隔地で通信を行う。 単語の解釈 Worker Flamenco において実際にレンダリング処理をする端末を、Flamenco公式ドキュメントなどを見た結果、Workerと呼ぶと私は現時点(2026/3/22)では解釈している。 ...

March 22, 2026

Blender で RDP において、カメラやオブジェクトを動かせない

この記事を作った動機 普段常駐させているサーバがあり GPU を載せているが、それを使って Blender でレンダリングをしたいとか、RDP 経由で直接その環境を使いたいとなったときに問題が起こっていた。 具体的には、RDP 経由で Blender 自体のウィンドウやその他アプリにおいてもドラックアンドドロップなどはでき、Google Chrome においてもタブを掴んで動かしたりすることはできるが、Blender 内の 3D Viewport において、視点を回転させようとしたり、オブジェクトを G キーを押してマウスで任意の場所に移動させたりすると、ちょっとだけ動くだけで、ほとんど動かせないということがあった。 今回はその背景や機能することが確認できた対処について記録したい。 対処方法 Continuous Grabを無効化する。(Edit -> Preference -> Input -> Mouse -> Continuous Grab) 問題の様子と解決の様子 背景情報 問題としては、Continuous Grab という項目が、FPSゲームとかであるように、マウスカーソルを画面中央などにロックして、一定フレームごとのカーソルの移動量を計測することで、視点を移動させたりする仕組みが、Blender の Continuous Grab の機能で採用されていて、RDP 環境下ではうまく動作しないのではないかということは、Google Gemini 3 Fastに問題について投げてみると理屈として出てきたが、実際のところ技術的詳細がどうなっているのかは私はわかっていない。 通常のウィンドウ操作や、Blender の UI 自体の操作ではこの問題は起こらず、ドラックして動かしたりすることができており、それについては、画面の絶対座標から導き出されるカーソルの位置を利用してカーソルの移動量が計算されていて、カーソルがロックされていないので問題が起こらないということも、Google Gemini 3 Fastに問題について投げてみると理屈として出てきたが、実際のところ技術的詳細がどうなっているのかは私はわかっていない。 現状わかっていることとしては、Continuous Grabの機能を無効化しなければ、Blender において、3D Viewport が RDP 経由ではまともに動かせないということであった。今回の問題は直接 RDP を経由せずに操作した場合には起こらないことが確認できている。Windows 11 24H2 の RDP クライアントでも、Liunx 環境の Remmina RDP クライアントにおいても、Continuous Grab有効時において、今回の問題が再現することも確認している。 ...

March 20, 2026

dhcpcd が特定のインターフェースに対して DHCP するのをやめるように指定してもやめない

この記事を作った動機 dhcpcd を使って管理している PC があるが、最近その挙動について何度も DHCP して IP を取得しては、新しいものを取得するという動作をして、他の PC が接続できなくなるほど、IP プールを勝手に枯渇させるということがあった。 特定インターフェースについて、そもそも DHCP とかで勝手に設定しないように指定したつもりであったが、機能していないことが分かった。動くまで調べ、機能しているように見えるところまで持ってきたのでそれについて記録する。ただしばらく動かしてみないと実際機能しているかわからないので、すぐわかる範囲での暫定的な記録となる。 設定方法 /etc/dhcpcd.confの最上位に、denyinterfaces [DHCPしないインターフェース名1] [DHCPしないインターフェース名2] ...というように記述する。基本的に DHCP したり静的に IP などを取得し設定するインターフェースの設定より上に書かないといけないっぽいことが今回調べて分かった。denyinterface getting ignored - Raspberry Pi Forums に書かれているように、dhcpcd は設定ファイル内の順次自体が大事なように見受けられる。設定例はブログに乗せるために...として省略している部分がある。 機能しているっぽい設定例 # cat /etc/dhcpcd.conf # A sample configuration for dhcpcd. # See dhcpcd.conf(5) for details. denyinterfaces eno2 enp0s20u11 ... interface eno1 static ip_address=192.168.1.x static routers=192.168.1.x static domain_name_servers=8.8.8.8 機能していないっぽい設定例 # cat /etc/dhcpcd.conf # A sample configuration for dhcpcd. # See dhcpcd.conf(5) for details. ... interface eno1 static ip_address=192.168.1.x static routers=192.168.1.x static domain_name_servers=8.8.8.8 ... denyinterfaces eno2 enp0s20u11 問題となっているPCなどの構成情報 関係のありそうな構成情報の列挙 Arch Linux Firewalld dhcpcd nftables SoftEther VPN 今回登場するPCの説明 ルータPC 家庭用ルータに置き換えて、nftables と kea によってルータ化した PC である。基本的な機能性は家庭用ルータと変わらないように意識し、USB NIC と内蔵 NIC の2つからなる。今回説明に出てくる、具体的なインターフェース名に紐づく物理 NIC とは関係ない。 ...

March 3, 2026

UEFI 変数を書き込む (ReSizebleBar)

この記事を作った動機 最近GitHub - xCuri0/ReBarUEFI: Resizable BAR for (almost) any UEFI systemを使って、Intel Arc A770 を Windows 11 で運用していたが Linux 環境を使うようになって、新たに対応が必要なことが分かった。 具体的には、Windows 利用時は、GitHub - xCuri0/ReBarUEFI: Resizable BAR for (almost) any UEFI systemで提供されている、ReBarState.exeを使うことで Bar サイズを自分で指定すれば勝手に UEFI 変数が必要な分設定されたが、Linux 環境にそのような専用ツールはないと思っていたので、自分で UEFI 変数を書こうとしていた。 その過程で、UEFI 変数を書き込むことに苦戦したんのでその記録を取る。またあとから気づいた ReSizebleBar の UEFI ドライバが使う変数を書き込む専用ツールをソースコードからコンパイルすることについても記録する。基本的にGitHub - xCuri0/ReBarUEFI: Resizable BAR for (almost) any UEFI system関して UEFI 変数を設定する必要がある場合は、ツールを使う方法を推奨する。 環境 System Details Report Report details Date generated: 2026-03-01 13:39:42 Hardware Information: Hardware Model: HP ProLiant ML150 Gen9 Memory: 80.0 GiB Processor: Intel® Xeon® E5-2667 v4 × 32 Graphics: Intel® Arc™ A770 Graphics (DG2) Disk Capacity: 1.5 TB Software Information: Firmware Version: P95 OS Name: Arch Linux OS Build: (null) OS Type: 64-bit GNOME Version: 49 Windowing System: Wayland Kernel Version: Linux 6.18.6-arch1-1 ツールを使う GitHub - xCuri0/ReBarUEFI: Resizable BAR for (almost) any UEFI systemでReSizebleBar のためにUEFIの設定が必要な場合について記録する。すでに作業ディレクトリを作成し、移動していることを前提として想定している。 ...

March 1, 2026

BIND (named) 自体のクエリ先に DoH (DNS-over-HTTPS) を反映する

この記事を作った動機 named が名前解決時に参照する上流の DNS サーバのアクセスについて、SSL/TLSの暗号化を適用する設定をしたので、それについて記録したい。前提としてすでに named の設定が済んでいて通常の非暗号化状態の8.8.8.8#53などにおいて、動作していることを想定する。 設定方法 /etc/named.confを編集する tls tls-forwarder optionsブロックの外に記述するtls [設定名]からなる、TLS 設定である。 ca-file デフォルトでインストールされている証明書を使っている。 remote-hostname DoH 先の DNS サーバのホスト名を設定する。今回は Google DNS を使うので、dns.googleとした。 forwarders [DNSサーバのIP] port [DoH先のポート番号] tls [tls設定名]という形で設定する。通常の DoH ポート番号は853であり、HTTPSの443ではない。 設定例 tls tls-forwarder { ca-file "/etc/ssl/certs/ca-certificates.crt"; remote-hostname "dns.google"; }; ... options { ... forwarders { 8.8.8.8 port 853 tls tls-forwarder; 8.8.4.4 port 853 tls tls-forwarder; }; ... }; ... 動作確認 tcpdumpを使って確認する。以下は Google DNS が動いている様子を確認するために、8.8.8.8 の IP のホストの 853 番にアクセスしているか確認する例である。 ...

February 28, 2026

Linux PC に DHCP サーバを立てる

この記事を作った動機 Linux PC をルータ化するの話が長くなりすぎたので分けた。ここでは、簡易的にDHCPサーバを Linux 上で立てる方法について、簡易的にまとめることにする。難しいことはせず簡単に設定したので、不十分である可能性がある。今回は以下の項目について、今回立てるDHCPサーバでできることを目指した。 IPv4 で動作し、IPv6は今回取り扱わない デフォルトゲートウェイを設定する DNS サーバを設定する IPを新しく接続されたコンピュータに対して割り当てる また、Linux PC をルータ化する でマスカレードやらの設定が終わっていてすでにネットワークが機能している状態を想定している。ネットワークの構成については、今回テストに使ったものは以下のような構成である。192.168.0.0/24のネットワークについて、DHCPサーバを構成することを目指す。 手順 パッケージのインストール yay -Sy kea # sudo pacman -Sy kea /etc/kea/kea-dhcp4.conf設定をする # commentで示されるコメント部分は以下の例から取り除かないと多分動かない。また以下はほとんど Kea - ArchWiki の設定をコピーして私のテスト環境用に設定をちょっといじっただけである。 { "Dhcp4": { "interfaces-config": { "interfaces": [ "eno1" ], # DHCPサーバを動かしたい LAN 側のインターフェースを指定する "dhcp-socket-type": "raw" }, "subnet4": [ { "id": 1, "subnet": "192.168.0.0/24", # 管理するネットワークを指定する "pools": [ { "pool": "192.168.0.10 - 192.168.0.199" } ], # あたらしく接続されたクライアントに割り当てるIPの範囲を指定する "option-data": [ { "name": "routers", "data": "192.168.0.3" # デフォルトゲートウェイにしたいサーバを指定する }, { "name": "domain-name-servers", "data": "192.168.0.3" # DNS サーバを指定する } ] } ] } } kea-dhcp4サービスを有効化、起動する sudo systemctl enable --now kea-dhcp4 DHCPでネットワーク設定を自動取得できるか試す スイッチ越しにクライアントを接続し設定なしでインターネットなどが利用できることを確認する。 ...

February 26, 2026

Pi-hole をインストールする

このページは、まだ未完成です。。。 nicotalk&キャラ素材配布所 http://www.nicotalk.com/charasozai_kt.html (2024年5月16日) この記事を作った動機 まだ書いていない。 関連のある記事 Linux PC をルータ化する 使った画像とか File:Tux.svg - Wikimedia Commons (lewing@isc.tamu.edu Larry Ewing and The GIMP, CC0, via Wikimedia Commons) https://commons.wikimedia.org/wiki/File:Tux.svg (2026年2月26日) Windows 7(Vista) デフォルトのアイコン ルーター PCのアイコン Pi-hole – Network-wide Ad Blocking のロゴ https://pi-hole.net/ (2026年2月26日) 参考にしたサイトとか Pi-hole – Network-wide Ad Blocking https://pi-hole.net/ (2026年2月26日)

February 26, 2026

Linux PC をルータ化する

この記事を作った動機 私が使っている家庭用ルータの挙動が怪しく、時々特定 IP にアクセスできなくなったり、NAT 越えして VPN 接続する際に接続ができなかったりするときがあるなど、安定性に欠けることがあることが分かった。 そこで、使っていないミニ PC に Linux 環境をインストールし、そこで何かしら設定をすれば、ルータ化できるのではないかという話が、Gemini にいろいろ投げつけると出てきたので、実際にそれができるのか検証も兼ねて、自分で設定し試してみた。 そもそも私自身がネットワークについて授業でレポートを作るためなど、単位を取るために軽く触った程度で、実際に自分で使うために運用して体験してみたり、試す実戦経験に疎いところがある。その点も兼ねて今回実際に検証してみて、難しいと思うことに関しては自分なりにノートを取ってみることにしたというのが、この記事を書いた動機である。 今回の設定がうまくいかない場合、再起動後にルータとして機能しない に書いているように、nftables自体がFirewalldの動作に干渉しているかもしれないので確認する。 設定のまとめ 今回の話のネットワーク構成の前提 いきなり本番環境で動かすのはリスクが高すぎるので、既存の家庭用ルータが形成するLANをWANとして見立てて、そこにぶら下げるようにして今回ルータ化するPCを配置し、実際に動作するか検証する形にした。 設定の全体像 sudo firewall-cmd --list-all --zone=LAN; sudo firewall-cmd --list-all --zone=WAN # LAN (active) # target: ACCEPT # ingress-priority: 0 # egress-priority: 0 # icmp-block-inversion: no # interfaces: [LAN側のインターフェース名] # sources: # services: mdns ssh # ports: 3389/tcp 3389/udp # protocols: # forward: yes # masquerade: no # forward-ports: # source-ports: # icmp-blocks: # rich rules: # WAN (active) # target: DROP # ingress-priority: 0 # egress-priority: 0 # icmp-block-inversion: no # interfaces: [WAN側のインターフェース名] # sources: # services: # ports: # protocols: # forward: no # masquerade: yes # forward-ports: # source-ports: # icmp-blocks: # rich rules: sudo sysctl net.ipv4.ip_forward # net.ipv4.ip_forward = 1 ip a # 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 # link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 # inet 127.0.0.1/8 scope host lo # valid_lft forever preferred_lft forever # inet6 ::1/128 scope host noprefixroute # valid_lft forever preferred_lft forever # # 2: [LAN側のインターフェース名]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 # link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff # inet 192.168.0.3/24 scope global [LAN側のインターフェース名] # valid_lft forever preferred_lft forever # inet6 fe80::725a:fff:fe3f:8c93/64 scope link proto kernel_ll # valid_lft forever preferred_lft forever # ... # 4: [WAN側のインターフェース名]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default # qlen 1000 # link/ether yy:yy:yy:yy:yy:yy brd ff:ff:ff:ff:ff:ff # inet 192.168.1.19/24 brd 192.168.1.255 scope global [WAN側のインターフェース名] # valid_lft forever preferred_lft forever # inet6 fe80::3695:dbff:fe2b:1a6d/64 scope link proto kernel_ll # valid_lft forever preferred_lft forever インストールするパッケージ yay -S firewalld net-tools dhclient 具体的なコマンド操作 # 起動時にfirewalldが起動するようにする sudo systemctl enable --now firewalld # すでに有効化していたり、一時的に立ち上げた状態にしたい場合 # sudo systemctl start firewalld # NetworkManagerは手動でfirewalldに設定した項目を上書きする可能性があるので使わない # sudo systemctl disable NetworkManager # public ゾーンに紐づけられているインターフェースを確認し引きはがす sudo firewall-cmd --list-all sudo firewall-cmd --remove-interface=[publicに紐づけられているインターフェース名] --permanent # 新しいゾーン LAN と WAN を作成し、 # LAN側にしてスイッチに接続するインターフェースと、WAN側にして上流の外部ネットワークに接続するインターフェースを紐づける sudo firewall-cmd --new-zone=LAN --permanent sudo firewall-cmd --new-zone=WAN --permanent sudo firewall-cmd --zone=LAN --add-interface=[LAN側のインターフェース名] --permanent sudo firewall-cmd --zone=WAN --add-interface=[WAN側のインターフェース名] --permanent # 各ゾーンのパケットの扱いを設定 sudo firewall-cmd --zone=LAN --set-target=ACCEPT --permanent sudo firewall-cmd --zone=WAN --set-target=DROP --permanent # LANゾーンにおいて転送、WANゾーンにおいてマスカレード設定の有効化 firewall-cmd --zone=LAN --add-forward --permanent firewall-cmd --zone=WAN --add-masquerade --permanent # 設定を反映 sudo systemctl restart firewalld Systemd で起動時に実行する内容 (root,initRouter.sh) ※ 保存してスクリプトを作成し終わったら、chmod +x [filename]で実行権限を付与することを忘れないこと。 ...

February 25, 2026

mDNSでwindowsに対してlinuxクライアントから名前解決をしたい

この記事を作った動機 LinuxクライアントからWindows側にRDP接続などをするとき、いちいちIPアドレスを直接入力しているのは気持ち悪いと思っていた。今まではそれでいいやと放置していたが、最近いい加減どうにかしようということで、具体的な解決を試みようと思って、案の定手間取ったので記録する。 具体的には、mDNSを使って、Linuxクライアント側から、WindowsクライアントのプライベートIPアドレスを割り出したいということをしていた。基本的には以下のポイントがあった。 ファイアウォールの設定で、mDNSを受け付けるようになっているか? Linuxクライアントに必要なパッケージがインストールされ、必要なデーモンが動いているか? 接続先対象としてのWindows側のホスト名は間違っていないか? Linux側から名前解決を試みるとき、.localのTLDをつけ忘れていないか? 環境 前提としては、個人的なLAN内での利用を想定している。今回は、パブリックネットワーク向けのセキュリティー重視という観点では書いていない。 また重要な前提として、接続先と接続元は、同じプライベートネットワークに属していることとする。 接続先 (Windows) Windows 11 24H2 を使っている 接続元 (Linux) NetworkManger を使っている systemd-resolved を使っていない、無効にしている GNOME 環境 arch linux 環境 仮定 今回は説明のために以下の仮定をしている。Linux側に関しては、/etc/hostnameにすでに適切なホスト名が設定されているという前提である。 Windows側 ホスト名: WinHost IPアドレス 192.168.1.33 Linux側 ホスト名: LinuxHost IPアドレス 192.168.1.55 設定手順 Windows側 (接続される側、mDNSで名前解決される側) ファイアウォールの設定を確認する 今回はmDNSだけでなく、そもそも接続されているか確認するために、pingも通るように設定する。 ネットワーク探索が無効になっていないか確認する Linux側 (接続を試みる側、mDNSで名前解決をしようとする側) パッケージのインストール yay -S avahi nss-mdns # pacman -S avahi nss-mdns デーモンの有効化 sudo systemctl enable --now avahi-daemon.service /etc/nsswitch.confを設定する 以下はAvahi - ArchWikiを参考に設定した一部の例である。今回は IPv4 を対象として、mdns4_minimalを指定した。試してはいないが、mdns_minimal、mdns、mdns6_minimal(IPv6)としても、Avahi - ArchWikiを見る限り設定できる模様である。 ...

January 18, 2026

Nvidia のドライバを導入する

この記事を作った動機 最近元々 Windows が入っていたPCに対しても、linux環境に乗り換えるようになった過程で、Nvidia 製の GPU である Quadro M620 に対して、プロプライエタリな Nvidia社が提供しているドライバをインストールしようとしたところ問題が発生したため、具体的に何をしたか記録を取る。 基本的に今回起こった問題としては、aur から Nvidia のプロプライエタリなドライバを導入しただけでは設定不足で、正しく起動できず、カーネルなどを読み込み終わったあとに、画面が切り替わろうとするとき、解像度がおかしくなったり、画面が映らなくなったり、ケーブルを抜き差しすることで突然映るようになったりという挙動になった。 問題が何なのか調べたりLLM(Gemini)に投げつけたりしたところ、initramfsで起動する段階で Nvidiaのドライバを読み込んでないと、その後の起動後にディスプレイの EDID の情報が正しく読み込めないのではないかということが分かった。これは、起動時には画面が映らなかったり解像度がおかしい状態になることと、ケーブルを抜き差しすると映るようになることからも、起動時に Nvidia のモジュールがロードされていなかった場合に、その後の初期化フェーズで Nvidia のドライバが読み込まれても提携できてないということで、説明がつくように思われる。 ちなみに設定不足のときに、dmesgでカーネルのメッセージを見ると以下のようなエラーが出ていた。 dmesg | grep nvidia ... R* [nvidia-drm] [GPU ID 0x00000100] Failed to add encoder for NvKmsKapiDisplay 0x00000001 ... 環境 環境 System Details Report Report details Date generated: 2026-01-17 20:53:19 Hardware Information: Hardware Model: HP HP Z2 Mini G3 Workstation Memory: 16.0 GiB Processor: Intel® Xeon® E3-1225 v5 × 4 Graphics: Quadro M620 Disk Capacity: 512.1 GB Software Information: Firmware Version: N53 Ver. 01.91 OS Name: Arch Linux OS Build: (null) OS Type: 64-bit GNOME Version: 49 Windowing System: Wayland Kernel Version: Linux 6.18.5-arch1-1 ...

January 18, 2026