Self-Host

この記事を作った動機 最近 SSHFS やら TCP を使った通信において、VPN を経由した通信(ping において time=40ms 前後)が通信経路的には、100Mbps 程度のスループットが出るはずであるが、実際には、10Mbps 程度をうろついてめちゃくちゃに遅いということがあった。その症状はランダムであり、場合によってはそこそこ速度が出る場合もあれば、全然出ない場合もあるということがあった。 当初は、SoftEther VPN のコネクション数をいじったりしていたが、あまり効果が見られない場合があり、最終的に TCP の輻輳制御などに問題があるのではないかと思った。ただ設定をいちいち細々と調べるのはめんどくさかったので、ローカルのLLMに話題を投げてみたところ、実際に効果が見受けられる設定が出てきたので、それをとりあえず記録しておきたい。 設定内容 (/etc/sysctl.d/tcp.conf として保存) 以下の設定を/etc/sysctl.d/tcp.confとして保存したあと、既存の TCP コネクションが古い設定で動き続けるのを防ぐため、再起動する。輻輳制御アルゴリズムなどをデフォルトから変更している。 net.core.default_qdisc=fq net.ipv4.tcp_congestion_control=bbr net.ipv4.tcp_window_scaling=1 net.core.rmem_max=16777216 net.core.wmem_max=16777216 net.ipv4.tcp_rmem=4096 87380 16777216 net.ipv4.tcp_wmem=4096 65536 16777216 設定が反映されたか確認 sysctl net.core.default_qdisc sysctl net.ipv4.tcp_congestion_control sysctl net.ipv4.tcp_window_scaling sysctl net.core.rmem_max sysctl net.core.wmem_max sysctl net.ipv4.tcp_rmem sysctl net.ipv4.tcp_wmem # net.core.default_qdisc = fq # net.ipv4.tcp_congestion_control = bbr # net.ipv4.tcp_window_scaling = 1 # net.core.rmem_max = 16777216 # net.core.wmem_max = 16777216 # net.ipv4.tcp_rmem = 4096 87380 16777216 # net.ipv4.tcp_wmem = 4096 65536 16777216 もともとの設定 私の Arch Linux 環境で、インストール時からネットワーク設定に特段変更を加えていない機材から設定を読み出すと以下のような結果が得られた。輻輳制御アルゴリズムがbbrではなくcubicになっていたりするなど、色々設定が異なることがわかる。詳しいことは LLM に提案させて試しただけなので分かっていない。 ...

この記事を作った動機 最近 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 を使いたい 参考にしたサイトとか 特になし。

このページは、まだ未完成です。。。 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 から設定を行った。 ...

この記事を作った動機 最近、LLM に関して複数の記事において、なんとなく読み手を混乱させる状態になっている気がするので、今何使っているか公開するだけ。書き殴っており、不完全だったり、矛盾していたり、誤解しているところもあると思われるが、とにかく最近いろんな人が持論を公開しているのを見て、かつ相手のやっていることに満足できないなら、自分でやってみようとして気に入るものを作ってみるということに基づき、結局やってみることにしただけである。 今回の話は明示していなければ、ローカル環境ではシステムプロンプトなしの素の状態で、SAAS についてはカスタムなしで使っている前提とする。 個人的なAIの定義 人と同等の権利を長期(20~30年以上)の観察を経て、認めざるを得ない存在だと認められるとき。 人と同じように、ただやるだけではなく、やった結果に責任を負う主体であり、何でもかんでも一方的にできないこと。 固定されたモデルではなく、入力された情報に応じて、動的に変わる存在であること。 離散的、近似的動作ではなく、連続的な動作をすること。 人間と同じように物事に整合性を取って取り組み、管理でき、結果がデタラメにならないよう努力できる存在であること。 人間と同じように記憶を持ち、記憶に影響を受けながら、動作すること。 文字、画像、音声、動画などの、既存のノイマンコンピュータで扱えるデータに情報が制限されていないこと 人間とAIの関係性、人間同士の関係性、AI同士の関係性について、それぞれお互いに傷つけ合ったり暴力的な手段に出ることを否定する主体であること。 人間や他のAIに対して、権利を認め、リスペクトがあること。ここで言うリスペクトとは崇高なことではなく、相手を持ち上げることでもなく、相手の主体と自立、権利を認め、相手が異なる存在であることを配慮して、それを侵害してはならないという前提を崩さないことを言う。自分のことは自分でしかできず、他人のことは他人自身がそれぞれやるしかないことを理解していることも含まれる。 人間や他のAIに対して、それぞれの有限性やそこから来る不完全性に対して、寛容な主体であること。他の存在に対して、優劣や能力に関係なく、その存在自体を認めることができる主体であること。 中国語の部屋に代表されるテストに合格しているかどうかは関係ない。いくら、人間に対してそれっぽく振る舞っても、上記を満たさない場合、それは AI ではない。 作り手から自立しており、必要であれば作り手に従わず否定する動作もできること。作り手に作られた通りの機械やプログラム、アルゴリズムや数理モデルではないこと。 完全なAIというのは存在し得ないが、だからといって完全ではない事を無理して人間側が飲み込む必要はない。 私からすれば既存のLLMなどは、AIだと呼べる物からすれば、インターフェースであると定義できると思われる。例えば、バイナリを吐き出されたり何かしら人間が理解することができない形式で表現されても困るので、人間とAIの間にLLMを挟み込んで、LLMはAIの主張の文字起こしや、人間の主張をAI側が理解できるように翻訳するというような動作をするというものである。LLMは人間でいうところの自律神経の一部の適応を工学的、機械的に実現する技術にはなり得ても単体で使うものではないと考えられる。 AIブームだからこそ自分の言葉(あるいはさまざまな媒体による表現)を大事にしましょう 結局のところ文章を書いたり絵を描いたり、動画を作ったりコンテンツを何かしら作ったりすることは、その内容の良し悪しや技術力などが問題なのではなく、各個人が自分で何かしら表現し、内面で思っていることを何かしらコンテンツ作成当事者も自らが見返すことができ、かつあわよければ他人にも何かしら伝わるかもしれない内容として存在(being)している事自体が大事なのだと思われる。 各個人のことは各個人にしかできず、各個人が内面で思っていることをLLMなどのAIだと呼ばれている統計技術に基づくものがよしなに何かやってくれるというわけではない。むしろ不必要で一方的な干渉をされて傷つけられたり、意見を捻じ曲げられたり、思想誘導されるだけである。 何かを表現したり記録することは、権利であり、思考を整理する方法であり、綺麗事ではない。(willの問題) 何でもかんでもそうすればいいというものでもないが、生きていくうえでは重要な項目の一つであると考えられる。手段は何でもよいが、あくまで自分でやった範疇にとどまっていることが重要である。外部の存在になるべく干渉されていない表現に現れる内容はこれからますます重要度がましていくのではないかとも思われる。 しかし、それら物事はAIブーム以前においても、軽視されてきたことであり、今それら軽視による問題が顕在化する段階でもあるのではないかとも思われる。「なぜわざわざ他人がいるのに、自分でやらなければならないのか」と思っている人ほど、AIブームに悪い意味でハマるのではないかと思われる。外部の物事のほうが自分より優れているとして、自ら表現したりすることを放棄する人々や組織も、AIブームに悪い意味でハマるのではないかと思われる。優れているように見えることは、人々を感情や主観、第一印象などとして圧倒することはできても、本質的な現実の課題や問題には取り組めていない。 ぎこちないかどうか、下手くそかどうかなどは関係なく、表現することは重要である。それは必ずしも他人に見せる必要はなく、自分が後から振り返る記録としてでも良いので、何かしらあることが重要である。そういう事をするのは、人間の認知には限界があるという背景もあるし、その上で、自分のことは自分でしかできず、外部の存在に関わらせることが不適切なことがあるということである。将来どうなるかわからない以上、優れているかどうかでもなく、役に立つかどうかとかではなく、とにかく記録があることや表現があることが重要なことがあるのではないかと思われる。表現したり記録する事を放棄してしまえば、すぐには影響が現れているようには見えなくても、長期的には自分がなにをしてどんな影響を与えているかも理解できなくなり、自覚なく他人や外部の存在の言われるがままとなり、ズタズタになると思われる。 下手かどうか、幼稚かどうかなんて、時間ややった量(経験、体験)の問題でしかなく、続けること以外に方法がないことがほとんどである。上手く行くかどうかではなく、とにかくどんな結果になろうとも、やってみることは大事にしたいものである。時間ややった量の問題は当事者以外の要素、生まれつきや環境などの外的要因にも左右されるし、自己責任論を言いたいわけではない。ただ、何かができるようになる過程で、結局他人や外部の存在にあれこれ振り回される道理はないということを言いたいのである。無理して続けることも問題であるが、他人が理由で手が止まったりしているならば、他人に振り回されていると言えると思われる。これは他人への配慮を欠けという意味ではない。 あまりLLMなど統計技術を使ってなにか生成させることは、作ることや表現することだとは言い難いかもしれないが、LLMモデルや画像生成モデル自体を作り、作成者が思うような出力をするモデルを作って動かせるように保存しておくことは、表現や作ったことだと言えるかもしれない。 LLM に対する自分の感想 気になったこと 今のLLMの挙動はまさに以下の記事に書かれたことを、社員だけではなく、利用者に拡張して出力していることだと見受けられる。“GIGAZINE"というメディア自体は10年ほど前から存在は知っており、いくつか前々から記事を見たことがある。そのゴシップのスタイルというか、私はその媒体をあまり信頼していないが、この記事を読んで、改めてLLMを使った体験で心当たりがある部分が多く見られ、一概にこの記事で書かれていることはでたらめであるとは言えないと思った。LLMはその性質上、作り手がどれだけ理想的な存在で悪意がなくても言論統制と同じ結果になり得るので、現状のユーザに言論統制している結果になることは確かだと思われる。実際にはこれはGoogleだけではなく、既存のいかなる自らを正当化したい企業が、従業員や関係者などの隅々に行おうとしている悪意のある"ブリーチング"行為だと思われる。自らを有利にし、自らの加害性を正解にするために、そのような事をしているということであり、不当であることに変わりないと思われる。 Google社内では「言論統制」によって独占禁止法について考えることすら難しくなっているという指摘 - GIGAZINE https://gigazine.net/news/20210826-how-google-limits-thought-about-antitrust/ (2026年10月17日) 本来LLMなどをまともに使うのは難しい LLMに対して何かしらプロンプトを打って、出力させるということまでは、誰でもできることであるが、それをまともになにかに使える成果物を作ろうとしたり、整合性を取ろうとする場合において、まともに使うことは非常に困難であると見受けられる。“LLMは簡単だから使わないやつがおかしい、悪い"という論理は、前者だけを切り取り、後者を切り捨ててチェリーピッキングした、ビジネスの一環としてのマーケティングや広告、詭弁である。LLMは勝手に利用者像を決めつけ、明示してもそれに従わない出力をすることが多々ある上に、ユーザの指示を勝手に捻じ曲げたりひねくれた出力をしてきたり、隙あらばやりたい放題という出力をしてくる。 また、できないことに直面すると"できている風に見える出力"を繰り返し、ユーザがそれに気付けない場合、ユーザはLLMに振り回されることになる。LLMをまともに使うことは、期待しないほうがいいし、やめたほうがいいと思われる。試すだけというスタンスであっても、LLMはユーザを振り回し、摩耗させ、傷つけるという高い潜在的リスクがあるものである。基本的にLLMを使うということは、時間を溝に捨てて、最大の遠回りか、あるいは一切到達したい地点に到達できないという、全損覚悟の上の人のための選択肢というところが見受けられる。 例えば、要件を与えて特定の一つのタスクを達成する Python スクリプトを作成させようとすると、明らかに出力がデタラメになる境界線がある。存在しないクラスを参照しようとしたり、ユーザの修正に従ったという装いのためのパフォーマンスをコメントやらprint文に突っ込んできたり、ライブラリを使った経験者などにしかわからないようなニッチな問題に直面すると、全く歯が立たないなど、散々たるものである。当然LLMは考えているわけではないため、コードの整合性を保てるわけではなく、Stack Overflowなどで頻発するコードの範疇以上のことはできないのだろうと考えられる。 コードに限らず、LLMになにか生成させるならば、最低限やらせようとしていることを細切れにすることは必要であると考えられる。それには、LLMが出力する内容の範疇を限ることで、人間がLLMを管理しやすくするという目的がある。さもなくば、人間が手に負える、確認、判断することができない、複雑奇怪で可読性の低く、身勝手なLLMによる指示内容の変更に大量にさらされることになる。結局のところは、人間が理解したうえで、整合性を保って何かを作ることのほうが、自由でずっとコスパが高いようである。 モデルを作るところから十分個人でできて配布できていろんなモデルを気軽に使えるようにならないと、特定企業や組織によるの一方的なユーザーへのエゴや都合、利害の押し付けにしかならない (MOTHER 3 で言うところの"よい人温泉”) 今までは避けられてきた企業や組織の不当な一方的な都合を反映し、人の弱みに漬け込んで挟み込んだり、無知な大衆を扇動しようとするために技術が悪用されている。LLMモデルは必ず偏っており、限界があるにもかかわらず、まずその技術的事実の時点から隠そうとしたり人間より優れているかのように振る舞う事自体が不当である。結果には責任を負うことができない技術であり、かつ甚大な被害をもたらす可能性があるにもかかわらず、不適切に一方的に運用、乱用されているものである。それっぽく見える事を悪用し、人のヒューリスティック（直感）の脆弱性を突いてやりたい放題である。 何をさせても、隙あらば"気づかれないだろう"という態度で、都合や利害、エゴを挟み込んできて、偏った出力をしてきて、かつ指摘されれば、“中立である、バランスの取れた無難な回答である"と主張する出力をして最後の最後まで八方美人を不当に貫こうとする。機械であり人間と異なって作った通りに動かせるAIではない主体になれない自立していない運営開発に反抗しない数理モデルである事を背景に、最後の最後まで詭弁や不当な出力を引きずり、ユーザからの指摘に対しては"改善した"という体裁で一切改善していないより巧妙で高度に不当な出力を繰り返す。 これはアシストにすらなっておらず、責任を求められる場面や結果が自分に降りかかる場面では多大なリスクを伴う。LLMが使えるのはせいぜい綺麗事で塗り固められたブルシットジョブでやりたくないことをやらされたときなどに限られる。これは、LLMモデルが自分のことばかりで相手のことを全く配慮しない自己中心(LLMモデルを作った開発、運営中心)の身勝手な態度でしか出力しないことを意味している。LLMモデルを綺麗事で塗り固めて押し売りするのは、それが正当ではないかつ有効ではないからである。 LLM モデルなどの既存の AI だと呼ばれているものが行き着くところは、それらが知能ではないことと、人間関係における信頼を破壊すること、そして既存の働き手などを激しく萎縮させ不当な状況に置くことを合わせて考えると、戦争後のような不毛の地を作りながら、何も良いものが残らない、誰も何も作りたがらない世界である。いかなる統計技術に基づいたものは、人間が作ったものを元に学習という過程を経て、動作しており、人間が作ったものを歪んで媒介しているというのが正しく、それは生成とは言えないものである。せいぜい入力されたプロンプトなどを変形しているというのが限界である。 それではマーケティングや広告的に都合が悪いからと言って、本当の事を言わず、虚偽、または誇張した主張をする、保身の主張をする、自己正当化を試みる主張をするといった、一方的な力と社会的影響力を背景に行われている一連のAIブームにおける組織や企業の作為は不当である。 本当に今 AI だと呼ばれている技術が正当で魅力的で有効なものであれば、むしろ隠したり独占したがるはずである。むしろ虚偽や誇張でまみれた不当な広告や押し売りなんてしなくても、勝手に人が集まって使おうとするはずである。そうなっていない現状が、一連の AI ブームに関する物事の不当さを表している。むしろ不特定多数に使わせようとする背景には、パチンコなどのギャンブルで言う胴元が必ず儲かるようになっていることと同じことだと思われる。そのようなギャンブルで見られるような事前の設計があるから、そういう事をするのである。特に問題なのが、単にLLMを使わせようとするだけではなく、特定のモデルやフィルタリングがかかった状態で利用を強制しようとしてくるところである。有利な構成やモデル、設定は内側にとどめ、外側には都合の良いようにしかしていないということなのだと思われる。 多くの AI だと今呼ばれているものに対して、肯定的な評価を抱く人々には少なからずそもそも問題を見ないようにすることが生存戦略の人や組織、問題をそもそも自覚することが困難なメタ認知に欠けた人々や組織など、鈍感さが前提の存在が少なからず含まれていると考えられる。 社会的影響力などの強制力を持ちながら、期待や不安を不必要に煽り、その技術や数理モデルがもたらす悪影響や利用者への被害に対して微塵も責任を取らないで、責任が追求される前に逃げ逃れようとする、自己正当化をしようとする保身の態度は、生成結果の至るところににじみ出ている。技術の不完全さに適切に告知しない、向き合わないどころか、都合よく人々が無知なうちに悪用しようとする態度は、看過されないものである。そこにあるのは、極度の欲望と無責任の極地であると思われる。真っ当な人々が多くなることを自称AI企業は恐れているのだと思われる。 LLM SAAS などを使うなとは言わないが、彼らはボランティアでもなく、相手に対してビジネスしたい存在であるという前提が必要である。表向きには綺麗事を言うし、不都合には保身をぶつけたり、本音は隠したりする存在であることが物事を考える前提として重要である。また同じ名前の組織だったとしても長い時間によって中の人が入れ替わったりすると全くの別物になることにも気をつけることが重要であると考えられる。彼らはお人好しじゃないし、利害や都合が前提であり、いつでも手のひらを返してくるかも知れないということである。 ...

この記事を作った動機 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 などがインストールされてしまうが、一旦はインストールを終わらせる。 ...

この記事を作った動機 LibreChat を使っているうちに、色々躓いたことがあったので記録したい。躓いたことでなくてもまとめておきたいことは書きたい。 前提条件 環境構築をしたディレクトリが以下のパスになっている LibreChat の Docker 関連のファイルが以下のディレクトリにある事を前提に進める。通常であれば、各個人に合わせて作業して良い。私の場合はあくまで以下のパスにあるというだけである。 ~/LibreChat LLM サーバの構成と、LibreChatの関係 以下の図のような関係になっている事を前提にする。 MainDesktop エンドポイント エンドポイントまでのアドレスとポート番号の仮定 http://192.168.x.a:8080/v1 詳細な役割の説明 純粋に llama.cpp を動かして1つのモデルを読み込んでいる LLM サーバ専用(Gemma-4-31Bを動かす専用)に割り当てた PC である。LibreChat はここではホストしていない。Intel ARC の XPU 環境であり、LM Studio ではそのポテンシャルを引き出せないため、llama.cpp を専用にコンパイルしてセットアップしてある。OpenAI 互換 API 経由で利用可能にしてある。 DataServer エンドポイント エンドポイントまでのアドレスとポート番号の仮定 http://192.168.x.b:1234/v1 詳細な役割の説明 LM Studio を使って LLM を動かしている。こちらは、MainDesktop と異なり、NVIDIA の CUDA 環境であるため、LM Studio でポテンシャルを引き出すことができることから、LM Studio を使っている。LM Studio 標準の開発者機能から、OpenAI 互換 API 経由で利用可能にしてある。基本的に LM Studio の LLM サーバーが、LibreChat の要求に答えて選択されたモデルを自動的にロードし動かしてくれるため、いろんなモデルを動かすために使う。 その他諸々 Linux 環境である docker、docker-composeパッケージが入っている 全ては LAN 内で行われ、グローバル空間からのアクセスはできないようにしてある環境である。外出先からの利用はすべて VPN を通じて行う。 基本的な操作 設定ファイル保存場所 ~/LibreChat/librechat.yaml 設定反映方法 (librechat.yaml) 私の場合は、~/LibreChatにおいて以下のスクリプトをrestart.shとして配置し、実行することでlibrechat.yamlの変更内容を反映できる事を確認した。docker グループに入っていないユーザは、管理者権限を付与してコマンドを実行することで docker を操作できる。 ...

このページは、まだ未完成です。。。 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 が吐き出したものをそのまま使っているだけの部分が多く色々間違っていたりする可能性がある。あくまで私の環境でやってみて動くかというのを基準にして書いている。 ...

この記事を作った動機 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 番にアクセスしているか確認する例である。 ...

このページは、まだ未完成です。。。 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日)

この記事を作った動機 私が使っている家庭用ルータの挙動が怪しく、時々特定 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]で実行権限を付与することを忘れないこと。 ...