投稿

ubuntu serverをminimized構成で導入、良い感触です

記事の更新日:2026/09/28 評価を加筆、タイトルを短く更新 1.概要 ubuntu desktopはWaylandなど様々な問題が発生して、LinuxMintに移行しました。しかし、LinuxMintにはsever版がありません。Docker環境や仮想マシンに導入する場合、ubuntu serverを利用すると良いのではないかと考えて調べてみました。 ubuntu serverにはGUIがありません。つまり、Waylandは搭載されていません。X-windowsもありませんが、serverなのでsshで接続して利用するので問題ありません。snapは標準でインストールされていますが、purgeできます。Docker環境や仮想マシン環境ではマルチブートをすることがないので、PBR bootも必要がありません。 上記条件を踏まえて、ubuntu server 24.04.4をminimized構成で導入しました。ubuntu desktop環境はLinuxMintに移行したので、Docker環境や仮想環境での試験にはubuntu serverはとても良い感じです。この内容を記述します。 私の評価は以下の通りです。 (1) ubuntu desktop 24.04を諦めてLinuxMintへ移行、ubuntu serverは使えます (2) 仮想環境(KVM)やDockerのimageとしてubuntu serverは最適です (3) LinuxMintにはserverがありません、この代わりにubuntu serverが選択できます (4) snapのpurgeをして、aptによるモジュールの追加を選択しました (5) ubuntu server 24.04 と26.04が対象です 2.詳細 ubuntu serverもmicroVM作成の対象になると思いました。 試験をするのであれば最新版が出ていたので24.04.4を選択。 良い感触です。 ubuntu server 24.04.4をDownloadして、KVM仮想環境にminimized構成で導入をしました。 ディスク使用量は4.3GB 起動時のメモリ使用量は271MB kernel-6.8で15MB ubuntu server 24.04.4にはGUI(Wayland)がありません。 df -hで参照した範...

LinuxMintでFirecrackerでmicroVMを試してみた

記事の更新日:2026/09/28 評価を追記 1.概要 microVMのFirecrackerを試しました。AWS Fargateで利用されている技術です。 loginできないDocker Container環境だと認識していましたが、 正しい内容とその仕組みを知る機会となりました。この内容を記述します。 私の評価は以下の通りです。 (1) AWS Fargateの技術をFirecrackerを試すことで理解できます (2) Firecrackerはコンテナではなく、microVMを管理する仕組みでした (3) Fargateはコンテナベースであるので、Firecrackerとの相違点はわかっていません (4) kernel, root-fsを準備して、Firecrackerに組込んで起動します、案外難しい 2.詳細 (1) ネット情報で基礎知識を取得 下記資料がすべてを示しています。 Firecracker https://firecracker-microvm.github.io/ KVM環境の上に、microVMを複数動作させ、そこでContainerを動かす仕組みのようです。 実際にmicroVMを起動すると100MB程度のメモリで動作しています。 試験環境はIntel i3, Memory 16GB, SSD 256GB, LinuxMint 22.3を利用しました。 手順は上記URLの下の方の下記部分にあります。 Announcing the Firecracker Open Source Technology 手順の記述内容に一部誤り(curl -L => curl -L -Oなど)があり、 下記参考資料を参照して実行します。 私はhome dicrectoryにfirecracker directryを作成して作業しました Firecrackerをさわって大量のmicroVMを立ち上げてみた https://dev.classmethod.jp/articles/reinvent2018-try-firecracker/ また、LinuxMint 22.3は/dev/kvmの権限設定は既定値で設定済みでした。 (a) firecrackerのdownload curl -L -O https://github.com/firecracker-...

話題のOpenClawを試してみました

記事の更新日:2026/09/29 評価を加筆 1.概要 パーソナルAIアシスタントのOpenClawが注目されています。 どのような物であるか調べてみましたが、実際に動作させるところまでは実施していません。 理由は、良く知らない製品で、セキュリティ対策を取れる自信が持てなかったためです。 この点に関して、下記参考資料をネットで見つけました。良く整理されています。 OpenClawを取り巻く脅威を踏まえた「安全な」運用はあり得るのか? そこで、私が感じたこと、その内容を記述します。 (1) OpenClawは良くわかりません、まず、学ぶことが必要です (2) 行動を起こす前に、行動を起こした方の結果を良く学習して理解を深めます (3) 良くわからないものに権限を与えて、費用が必要な処理はしてはいけません (4) AIは個人の意思に反する行動もありえます。慎重さが大切です  2.詳細 (1)感じたこと まず、何であるかに関して、下記ネット記事の文面がぴったりな気がします。 OpenClawは一言でいうと、「AIエージェントのためのマルチチャネルGateway」です 【2026年最新】OpenClawとは? AIエージェントを自分のPCで動かせるオープンソースツールの導入ガイド 次に、利用する上で何が問題になるかは、 PCにAIを利用して様々なことをさせてしまうことだと思います。 自分で管理制御できる範囲とそれ以外の境界線が不明瞭になるので、 セキュリティ上の問題が発生しそうな気がします。 技術的な点では、AIに接続するためのTokenを登録してしまうので、 OpenClawに制御権を渡すことだと思います。 OpenClawもProgramなので、どのようなロジックが存在するかはブラックボックスです。 (2)導入のこと LinuxMint-22.3を利用して、導入作業を実施しました。 下記記事があり、今回はネットワークを分離して、1台のPC環境で試してみました。 普段使いPCを汚さずに OpenClawを試す方法【Google Cloud Platform】 私はAIに接続するためのTokenの準備をするステップで中止しました。 手順はGithubの情報ですが、詳細を理解するには、SourceからのBuildが良い気がします。 OpenClaw パーソナルAIア...

N3450環境でLinuxMint 22.3を利用するとサウンドデバイスがDummy Outputになる

記事の更新日:2026/09/29 評価を加筆 1.概要 古いNotePC(Intel N3450)でLinuxMint-21.3からLinuxMint-22.3へ移行した時に、Sound DeviceがDummy Outputになり、音が鳴らなくなりました。Intel N3450(jumper)にLinuxMint 22.3を導入すると音がなりません。Sound DeviceがDummy Outputになっていたので、それを修正する手順を示します。 私の評価は以下の通りです。 (1) LinuxMint 21から22の移行でサウンド関連が変わったと思います (2) Intel N3450は少電力CPUですが、core-iのシリーズと異なり、標準と違うのでしょう (3) 最新のSOFドライバーをmodprobe.dに設定して改善しました (4) この情報はネットで見つけることが難しく、AIに頼りました 2.詳細 Ubuntu 20.04, Ubuntu-22.04, LinuxMint-21.3で問題なく動作していたので、音が鳴らないなど考えもせず、LinuxMint-22.3移行時にテストもしていませんでした。ふと、サウンドテストをすると何も鳴らない。Sound DeviceがDummy Outputになっているのに気が付きました。 ネット検索すると求めると、Dummy OutputになるのはIntelの10世代CPUで起きるようです。修正方法は下記内容でsound driverを適用するように設定することでした。 ネット上にも参考資料があり、dsp_driverの指定には、1,2,3の3つが選択できるようです。 適用したdsp_drive=3は、最新のSOF(Sound Open Firmware)ドライバーを強制適用するようです。この適用で改善しました。 sudo -i echo "options snd-intel-dspcfg dsp_driver=3" > /etc/modprobe.d/inteldsp.conf reboot 3.所見 最近のPCはコア数が多く、また、コアは機能別に用途が異なるものもあります。コア数が多くなると制御するのが難しくなります。最近はBIOSでCPU関連の問題点調整をしているらしいので、Firmwa...

LinuxMintで高解像度NotePCでdisplay resolutionの変更をしました

記事の更新日:2026/09/22 評価の記述、誤字の修正 1.概要 新しいPCは性能向上が著しく、CPU性能だけでなくディスプレイの解像度も高度化しています。以前はVGA,SVGAを利用して、1024x768のディスプレイが利用できるようになると、「すごい」と思ったものです。更に、1920x1080の横長のハイビジョン対応のディスプレイを利用できるようになって、操作性が著しく良くなりました。 linux起動時のkernel paramaterに参考資料に記載があるvgaパラメータを以前は設定していました。いつ頃からわすれましたが、vgaパラメータでは解像度は変更できなくなってしまいました。ディスプレイの解像度は、HWの進歩により非常に高密度になってしまい既定値(最高の解像度)では文字を読むことがとても辛くなりました。 新しいkernelパラメータとして、video=1024x768があるとの記事を見つけて試したのですが、思ったようには解像度は変わりません。efi環境で解像度変更をGoogleAIに助けてもらって実現できたので、その内容を記述します。 私の評価は以下の通りです。 (1) kernel parameterに、nomodeset video=efifb:1024x768を設定できます (2) uefiBIOS上のframebuffer設定で解像度を下げる設定です (3) 標準のvideo=1024x768ではuefiBIOSでの設定変更はできないようです (4) 理由はわかりませんが、nomodesetの組合せが使えました 2.詳細 利用したのはディスプレイが3:2の表示可能なNotePCです。解像度は2160x1440です。これでは文字が小さくてテキストモードで読むのはとても辛いのですが、仕方なく利用していました。色々過去に解像度設定を試したのですが、nomodesetを指定しても解像度を下げることができず、半分諦めていました。 GoogleAIが提案したkernelパラメータは、video=efifb:1024x768です。 しかし、この設定でも解像度を下げることができません。 ダメ元で、nomodeset video=efifb:1024x768と設定すると表示解像度を1024x768に変更できました。何でも試してみるののです。以前は無理な設定をす...

MQTTをmosquittoで試しました

記事の更新日:2026/09/12 1.概要 IoTデバイス向け通信方式としてMQTTが広く利用されています。Queueと聞くと待ち行列で駅に人が到着するモデルが浮かびます。また、汎用機のジョブ管理(JES2等)のジョブキューや出力キュー、オンライントランザクション処理のインプットキュー等の方が私にはわかりやすく感じます。ネットで調べると、MQTTのmosquittoが簡単で一般的とのことなので、試してみました。その内容を記述します。 私の評価は以下の通りです。 (1) MQTTはランダムに発生するデータを一列に並べて同期処理に変えることができます (2) 一列に並ぶので整合性が取れる形でデータベースなどを更新できます (3) MQTTのmosquittoが簡単で一般的で学習する上で最適です (4) Dockerを利用して簡単に試験できます 2.詳細 参考資料のdocker-hubの記述に従って実施します。 MQTTの環境構築はDockerコンテナを利用することで非常に簡単です。それよりも試験の仕組みを理解して試験するほうが難しい。今回はterminalを3個利用します。1個めはmosquitto本体が稼働している環境です、2個めは受信環境、3個めが送信環境です。 (1) 1個めのterminalを起動 まず、ディレクトリを作成 mkdir ~/mosquitto/config cd ~/mosquitto/config vi mosquitto.conf エディットする中身は下記内容です persistence true persistence_location /mosquitto/data/ log_dest file /mosquitto/log/mosquitto.log 起動 docker run -it -p 1883:1883 -v "$PWD/mosquitto/config:/mosquitto/config" eclipse-mosquitto 下記メッセージが表示されるとOKです。 Status: Downloaded newer image for eclipse-mosquitto:latest 操作方法はdocker-hubに記載はありません。別の参考資料を参照します。 (2) 2個めのterminalを起動 doc...

SynologyでRAID1 RecoveryでDisk交換を試しました

記事の更新日:2026/09/29 評価を加筆 1.概要 SynologyのNAS( DS216J )でディスクでエラーが発生しました。RAID1(ミラー構成)であったので代替NASへデータを移行していたのですが、ディスクを入替えて復活させることに挑戦しました。新品のディスクに交換して初期設定すると良いのですが、せっかくのチャンスなのでRAIDのリカバリで復旧することに挑戦しました。 SynologyのNASでディスクのRAID修復は初めてです。大型のストレージ装置でRAIDのリカバリ経験はあるので、手順書を参照しながら実施できると考えました。RAID1のリカバリ手順を利用して、RAID1構成の2台のディスクを新しいディスクへ入れ替えるた手順となっています。 私の評価は以下の通りです。 (1) RAID1構成はデータ消失リスクは低いのですが、ディスクエラー管理は必須です (2) 機種に依存ですが、容量が多ければ異なるディスク間のRAID1も実現できました (3) RAID1同期時間短縮と考えて、ディスク上のデータ削除は無意味でした (4) 同じ型番のディスクでRAID1同期は時間短縮になりました 2.詳細 SynologyはToshibaの2TBディスクが2台でRAID1構成です。ディスクが1台クラッシュしたので、既に代替NASへ移行していたのですが、2TBのディスクを2台購入して、Synologyの復旧をしてみました。ディスクが値上になり、同じ製品でなく、手頃な値段のディスクを購入しました。1台を交換してRAIDを修復すると利用できるのですが、異なる製品で性能も違うので、もう1台もこのタイミングで交換することにしました。OS部分の再導入は実施せずにRAIDの修復を行いました。 手順は以下のとおりです。 (1)故障ドライブの確認 Synologyを起動するとRAID構成が片系になり、ストレージマネージャが起動します。 まず、故障したドライブを見つける機能で探します。Disk1が故障であることを確認します。 (2)SynologyからDisk1の取外し 分解するので掃除もします。Disk1の取付位置はディスク取付金具に記載されています。 (3)Synology起動 Disk2だけで起動することを確認します。OS部分を再利用するので、不要なデータ部分は削除して、RAID...